Thursday, 24 August 2017

Confidentiality Integrity and Availability vs Techman X

CIA is the acronym that boils down the basics of security - and no, I don’t mean CIA as in the intelligence organization. In tech, it’s a standard acronym that is Confidentiality, Integrity and Availability. It is the measurements that determine security in an environment. If these measurements look good in your environment, you can feel good that the bad guys will do no harm. In this post I’ll give a briefer through examples with Techman X.
Confidentiality
A bad guy, Techman X, learns that Gym A puts their customers’ credit card information on one particular laptop. Techman X thinks, “Aha! My recon work is done. If I get my hands on that laptop, I can steal other people’s credit card information.” One evening, Techman X tip toes into the gym. While no one is looking he snatches the laptop, and sneaks out! “Success!” so he thinks.
Techman X is a pretty smart guy. He knows how tech stuff works. So later that evening, he grabs one of his fancy forensic tech tools. The tool should allow him to see what’s in the laptop without the password. But a surprise hits Techman X. When he attempts to pwn the laptop, he’s stunned at what he sees… Giberrish… The data in the laptop is jumbled up.
This is confidentiality. It is the idea that allows for credit card information to be kept secret for Gym A. Encryption falls into this category, and was the saving defense for Gym A – it made the data look like gibberish.
Other aspects to confidentiality, also include authentication. Users can access secret information if they have authorized credentials such as a username and password. Some companies also use smart cards to authenticate. This gives an extra layer of security by having a physical item as a prerequisite to access.
Integrity
This topic is based on reputation. Can the data that you have be trusted? Or has it morphed into something evil? Perhaps. Well, at least in the next scenario with Techman X it has.
Techman X decides to use an executable to steal credit card information. On a Saturday morning, he poses as a patching technician that corporate sent to Gym A. The local IT guy at Gym A is weary because he hasn’t been informed about this surprise visit. Techman X tries to ease the local IT guy’s nerves, “It’s all good, I don’t have to stay. You can perform the patching. Here’s the regular OS update from Big Company.” Techman X hands the local IT guy the usb with the patch from Big Company’s OS update. The patch is an executable and it looks legit.
When the surprise visitor leaves, local IT guy takes off his glasses and dons the blue cape. BlueTeamTech goes into action. He goes to Big Company’s website to see that the executable’s name is legitimate, patch.exe. That checks out. BlueTeamTech has abilities that are out of this planet, so he doesn’t stop there. He checks to see if there is a hash for the executable. Behold, Big Company has the hash.
BlueTeamTech goes to his isolated sandbox, and navigates to the terminal and types:
cd D:
certutil –hashfile patch.exe
The terminal spits out a hash. BlueTeamTech checks to see if it matches with Big Company’s hash. It doesn’t. BlueTeamTech immediately destroys the isolated sandbox and reports the usb incident to proper authorities.
Integrity checks beyond what seems reputable. In this case, the patch, looked legitimate. But at a closer look shows it wasn’t. The data couldn’t be trusted.
Availability
Backups and throughputs could sum up availability. These two components allow continuous use of data. Backups allows continuous use of data if previous data happens to become corrupt. Throughputs allows continuous use of data, by making sure there is no obstacles in the way to get to the data (ie network latency).
With this example with Techman X, I’ll explore the throughput side of availability.
Techman X is at it again. His plans keep getting foiled. But this time, he thinks, “If I make my attacks more sophisticated, I will eventually steal the credit card information.” So he devises.
On his white board he draw out what he’s going to do. On the left side of the board, he draws 10 computers representing 1,000,000 other computers. On the right, he draws Gym A’s infrastructure where website credit card payments are processed. In the middle is Gym A’s main website IP, and his Man-in-the-Middle Server. His plan is to unleash a full scale distributed denial of service attacks from his unaware cavalry of 1,000,000 computers against Gym A’s website IP. This should bring it down. Meanwhile, he will enable his MITM Server to go live to replicate Gym A’s website. With the MITM Server, users who enter credit card information will now be visible to Techman X.
The Zero Day DDOS attack approaches and is executed. 1,000,000 unwitting soldiers fire shots of ping, and syn flood messages towards the website IP. Techman X’s eyes are wide with malicious hope. One minute goes by, and the attack rages on. Two minutes… Three minutes… Four minutes… Nothing is happening. His MITM server isn’t online, and customers are still able to use Gym A’s website. Techman X is infuriated, “It must be that darn local IT guy!”

It was that darn local IT guy. With network visibility, BlueTeamTech laughed as he saw the attack being thwarted by his sophisticated fortress. The network perimeter was built with next generation equipment. Stacked with Intrusion Prevention Systems, and load balancers in mind, the website was impregnable. Availability prevailed.

Wednesday, 23 August 2017

Actually Finishing the Certificate You Started On

Success in finishing any certification depends on commitment. But sometimes you stop studying and you ask is the certificate worth committing to? Maybe not. Other times, certificates will play into the next promotion or job. It then becomes a matter of pressing on.

It's grueling work to become certified. I know, because as of this writing, I'm there with you trying to get my next certificate. I also know, like my previous certifications, it'll be worth it.

During my previous certificate study processes, I found some key points that helped remind me that it's worth it. I'm hoping these points maybe useful to someone else. 

Social Accountability

If your social circles cheer you on, that's your best guarantee. There are reasons others are recognized for self achievements - it's because they were needed to push on. Social circles are the giants to stand on, if anything is going to get done. Stand on them like you have before.

You can get creative in what this looks like. Just be consistent, even if it's brief. Just telling close family and friends about your updates will help. Social media can also be a place where this can happen. You can post your status updates with your progress. But only if you don't forget to #blueteamtechblog  :)

Set Reasonable and Specific Goals

This speaks for itself. 

It's easy to get carried away sometimes with planning. For me, I dream big. Nothing wrong with that, but my time line usually looks like zero to CCIE in 3 months. Impossible. Reasonable means, you've got a good idea on how long it'll take based on small steps in the past. You've got to set reasonable goals. 

Along with reasonable goals, being specific is helpful too. So that looks like this: finish the CCENT in 6 months by reading and annotating two chapters a month. You can make a check list out of that one. 

Study in Community

Go find people that are also studying. This also plays into the social accountability aspect, but this is more specific. It builds a lifestyle where you surround yourself with minds that are doing what you're doing. They understand your motivation and help you remember it.

These community groups can be local, like a school, workplace or Meetup. You can also develop community on line through forums, and Slack.




I hope these three tips help. Happy studies!

Tuesday, 22 August 2017

11 - Provisioning User Rights

Some scenarios require users to have console access but not complete console access. In these situations, configuring the router to grant limited access is helpful. This lab will review how users are granted rights, more specifically the extended ping.

Step 1 - Configuring Extended Ping for User, Elliot

User, Elliot is created with password, toor. Elliot doesn't need privilege 15 rights that could allow global mode access or the command, configure terminal. However, Elliot does need privilege level 7 and extended ping.  To do this the command will process from enabling privilege level 7 with extended ping, then create user, Elliot, and finally show run to see that Elliot is associated with level 7 and extended ping.

From the R-1 Router:

configure terminal
privilege exec level 7 ping
username elliot secret toor 
username elliot privilege 7
do show run | inc username


Step 2 - Showing the Autocommand Function 

The autocommand function limits Elliot to log into the router and only perform extended ping. Once ping is complete, Elliot is kicked out of the terminal. This requires Elliot to log back in after performing the extended ping. 

While still at global mode, the configurations will first enable autocommand. Then Elliot will telnet into the router's ASAv facing interface G0/1 10.1.0.1. Once telnet is a success, extended ping is available. The ping test will point to the inside ASAv interface with IP 10.1.0.250. Once completed, notice that Elliot is kicked immediately out due to autocommand. This is also verified via who. If Elliot were still logged into the terminal, Elliot's username would show under the who command. Then write is issued to save running the configuration.

username elliot autocommand ping
end
telnet 10.1.0.1
elliot
toor
[enter for protocol]
10.1.0.250
[enter for the rest of extended ping setup]
who
write


Step 3 - Introducing Nohangup

Nohangup allows Elliot to have a suspended session in the terminal without being completely booted after the extended ping. After Elliot finishes the extended ping, he can retype his username and password again, instead of having to telnet again.

Once nohangup is configured and exampled, notice how when the ping completes, the user prompt comes back.  

configure terminal
username elliot nohangup
end
telnet 10.1.0.1
elliot
toor
[enter for protocol]
10.1.0.250
[enter for the rest of extended ping setup]
[notice how username pops up, instead of going back to the R1# prompt]



Step 4 - Configuring Elliot for Privilege 7 Only

Elliot will no longer be limited to extended ping and the be kicked back out. The next commands will allow Elliot to access level 7 privilege - meaning Elliot will still be able to use extended ping (which can't be used with level 1 privilege) but level 7 will not allow Elliot to configure terminal. After this is configured the configured is saved.

do show run | inc elliot
no username elliot
[enter to confirm]
username elliot privilege 7 secret toor
end 
show run | inc elliot
telnet 10.1.0.1
elliot
toor
who
exit
write


Sunday, 20 August 2017

10 - Configuring SNMP Access

Router, R-1 will be configured to allow SNMP management coming from IP 192.168.14.132 - this is the SNMP management server (not shown in lab). 

The story for the commands below begins with allowing traffic from the SNMP management server. Then, group, evoolcorp is created for SNMP version 3 to allow read and write permissions. Next, user, admin is created into the evoolcorp group to authenticate using sha encryption, and privilege of aes 256 bit encrypiton with acl 1 applied. Show snmp is also shown to give a detail of what's going on with snmp such as bad packets. Lastly, these configurations are saved.

configure terminal
access-list 1 permit host 192.168.14.132
snmp-server group evoolcorp v3 priv read write
snmp-server user admin evoolcorp v3 auth sha toor priv aes 256 toor acc 1
end
show snmp

write


9 - Configuring Router Time and NTP Review

In this lab, the router time source will be configured to allow the authoritative and synchronized time to come directly from the local hardware. There will be a review of NTP configuration, but this will not be implemented in the lab.

STEP 1 - Configuring Router Time

Router time has three modes. 
  1. Asterisk is non-authoritative
  2. Period is authoritative but not synchronized
  3. No asterisk and no period shows the router is authoritative and synchronized to the NTP (else, it is set manually)

Initially, the lab router R-1 is non-authoritative as shown by 

show clock detail

The asterisk is the giveaway that the router time mode is non-authoritative. After manually configuring the router, it will be left without an asterisk or period.

Here's the total configuration

show clock detail
configure terminal
clock time zone utc -5
clock summer-time edt recurring
end 
clock set 21:04:00 Aug 17 2017
show clock detail
write

Notice with the final show clock detail command, the router is manually configured. 

STEP 2 - Reviewing NTP Source

The router will not be configured with NTP. But it's handy to underatand how to configure synchronization to an available NTP server.

In the configuration below, the NTP server IP is left blank. But there are plenty of public IP addresses that can be used for NTP servers if a little googling is done.

configure terminal
ntp server [NTP Address]
end
show clock detail
show ntp status

The last two commands are just to show more information about what's happening between the router and the NTP server. As mentioned earlier you can see what mode the router is in regards to time by show clock detail; using show ntp status will give further detail about what's going on between the router and NTP server.



Wednesday, 16 August 2017

8 - Building a DMZ for the ASAv and Enabling ICMP Inspection

This post will serve as a basic guide to creating a DMZ for a web server. Additionally, ICMP inspection will be enabled to allow the intern PC to ping outside. 

To begin, ASDM will be used to configure static NAT 192.168.14.55 (Faux Public IP Used for Lab) and associate it with web server (which will be built) IP 10.2.0.55. Port 80 will then be opened for web server traffic with the ACL on ASDM. Lastly, ICMP will be enabled for packet inspection - like some protocols this is disabled for packet inspect by default.

Like every other post, this post will serve as an expansion of previous; but can also serve as a standalone. For background, below is the summary of the current setup:

To recap, here is the summary of the lab configuration so far:
  • Cloud1 represents the WAN.
  • ASAv has an outside interface of 192.168.14.130 (pretending this is our public IP)
  • ASAv has an inside interface of 10.1.0.250
  • ASDM is successfully built with reachability using the outside interface 192.168.14.130
  • The network behind the ASAv is designed with 10.0.0.0/24 
  • The router is configured to route traffic with a default gateway to the ASAv
  • The virtual PC is configured with the router as the default gateway
  • The virtual PC can successfully the ASAv's inside IP 10.1.0.250.
  • The virtual PC is configured with 8.8.8.8 DNS Server
  • The ASAv is configured with dynamic PAT to allow internal IP address to translate to a public IP for communication
  • SSH is configured for outside traffic to manage the router.

STEP 1 - Creating a Router as the Web Server

Router, Web_Server, will be created to sit at the DMZ. It's configurations will allow it to be an http server. Web_Server will communicate from it's IP of 10.2.0.55 and route to the ASAv to be configured DMZ IP 10.2.0.66.

The router node is first added, named, connected and started before configuration. As noted in Post 2, the VIRL based nodes don't exactly match up with the GNS3 interface names. In this case the Gi0/0 matches the CLI.

enable
configure terminal
hostname Web_Server
interface gig0/0
ip address 10.2.0.55 255.255.255.0
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 10.2.0.66
ip http server 
ip http authentication local
username admin privilege 15 secret toor
end 
write


As an added touch, right click Web_Server and select 'change symbol.' Search 'server' and click okay.


Step 2 - Using ASDM to configure the ASAv DMZ

Post 2 shows the configuration of the ASAv using the command line. Alternatively, this post will show the ASAv configuration using the Application Specific Device Manager. To get the planned setup interface gig0/2 going out will be configured with the 10.2.0.66 IP, and security level 50. After which NAT will associate public IP 192.168.14.55 with the Web_Server. The Access Control List will then allow for the outside world to reach Web_Server.

Navigate to Configuration to Device Setup to Interface Settings to Interfaces. Double click GigabitEthernet0/2 to edit.


Edit Interface will open. Change the following settings:

Interface Name: DMZ
Security Level: 50
Enable Interface: Check
IP Address: 10.2.0.66
Subnet Mask: 255.255.255.0

Click OK twice and Apply


To check connection to Web_Server, navigate to Tools to Ping. Fill out ip 10.2.0.55 and click ping. The output should show success.


Now to the NAT configuration!

Navigate to Configuration to Firewall to Objects to Network/Objects/Groups. From the Add drop down, select Add Network Object. Fill out the information as shown:

Name: Web_Server
IP Address: 10.2.0.55

Click OK and Apply


Add another NAT object for Web_Global.

Name: Web_Global
Type: Network
IP Address: 192.168.14.55
Netmask: 255.255.255.255

Click OK and Apply


Navigate to Firewall to NAT Rules. Add 'Add NAT Rule Before "Network Object" NAT Rules..."

Fill out the NAT Rule with below:

Under Match Criteria: Original Packet
Source Interface: outside
Destination Interface: DMZ
Destination Address: Web_Global

Under Action: Translated Packet
Destination Address: Web_Server

Click OK, Yes, Apply, and Save


Navigate to Firewall to Access Rules. Add Access Rule. Fill out as shown:

Interface: outside
Destination: Web_Server
Service: tcp/http

Click OK and Apply and Save


Step 3 - Accessing Web_Server from the Outside Interface

This step mimics connection to the Web_Server behind the DMZ from the WAN.

Navigate to a browser and type the IP for Web_Global. Login with user name and password, admin and toor respectively.


Success! The server is now accessed through the WAN.

Step 4 - Enabling ICMP Inspection

As an added bonus, the virtual PC will be configured to ping into the internet. By default, ICMP replies are not inspected. 

Navigate to Configuration to Firewall to Service Policy Rules. Select inspection_default and click edit.


Go to the tab Rule Actions, Protocol Inspection and check ICMP.

Click OK, Apply and Save.


From the virtual PC, ping google.com.



Success!

Sunday, 13 August 2017

7 - Enabling Router SSH through ASAv ASDM over the WAN


Enabling Router SSH through ASAv ASDM over the WAN

This lab will allow remote administration for the router, R1. Static NAT to translate a one to one ASAv association addressing for the router and enabling SSH will be the primary methods of accomplishing this. 

To recap, here is the summary of the lab configuration so far:
  • Cloud1 represents the WAN.
  • ASAv has an outside interface of 192.168.14.130 (pretending this is our public IP)
  • ASAv has an inside interface of 10.1.0.250
  • ASDM is successfully built with reachability using the outside interface 192.168.14.130
  • The network behind the ASAv is designed with 10.0.0.0/24 
  • The router is configured to route traffic with a default gateway to the ASAv
  • The virtual PC is configured with the router as the default gateway
  • The virtual PC can successfully the ASAv's inside IP 10.1.0.250.
  • The virtual PC is configured with 8.8.8.8 DNS Server
  • The ASAv is configured with dynamic PAT to allow internal IP address to translate to a public IP for communication
STEP 1 - Enable Static NAT

Static NAT allows internal addressing to be assigned a public IP address. This allows for external users to a way to map and access internal services. The ASAv is the gateway for the internal and external network which the router belongs to. Thus the ASAv will be logically configured for Static NAT to match a public IP address to the internal IP of the router.

Enabling Static NAT begins with creating two network objects.

The first is R1. Navigate to Configuration to Firewall to Objects and Network Objects/Group. Then from the Add drop down select Add Network Object. Fill the object out as presented below:

Name: R1
Type: Host
IP Version: IPv4
IP Address: 10.1.0.1
Description: Router

Click OK.



The second object to be added will be Global-R1:
Name: Global-R1
Type: Host
IP Version: IPv4
IP Address: 192.168.14.131
Description: Public IP

Click OK.


STEP 2 - Configuring NAT Rule

The NAT Rule will allow the traffic to know how to get to a destination. It converts a known IP to the hidden IP. In this case we'll configure the Global IP address (192.168.14.131 I know this is a private IP for our scenario, but in production this would be Global) to associate with the internal router IP address (10.1.0.1).

To configure NAT Rules, navigate to Configuration to Firewall to NAT Rules. Then from the Add drop down select, Add NAT Rule.

We'll configure it as below:

Source Interface: outside
Destination Interface: inside
Source Address: any
Destination Address: Global-R1 (You need to click the 3 dots and select the object Global-R1 which was previously created)
Service: Any

Source NAT Type:Static
Source Address: Original
Destination Address: R1 (You need to click the 3 dots and select the object R1 which was previously created)
Enable Rule is checked

Click OK


Step 3 - Permitting the ACL for SSH traffic

While the NAT shows the traffic what path to take, the ACL gives permission on if the traffic is allowed to take the path. We'll allow the ACL to permit traffic to manage the router via SSH.

From Configuration to Firewall to Access Rule, select the Add Access Rule from the Add drop down.

Fill out the form as shown below:
Interface: outside
Action: Permit
Source: any
Destination: R1
Service: tcp/ssh

Click OK



Step 4 - Applying and Saving ASDM Configuration

Once we've configured ASDM as shown above, we'll go ahead and Apply and Save as shown in the screen shot.


Step 5 - Configuring Router for SSH

The ASAv is now configured to where NAT rules can provide location, and the ACL can permit SSH traffic to pass. Although if a user tried to SSH now, they would still not be able to since the router isn't configured for it. Our next step will allow for this.

From the router:
configure terminal
hostname R1
ip domain-name ecorp.com
crypto key generate rsa modulus 1024
username admin privilege 15 secret toor
line vty 0 4
login local
transport input telnet ssh
end
write


Step 6 - Testing SSH Connection through the WAN

Putty or any SSH terminal can be used for this next step. If you don't have Putty installed go ahead and do so now. It's a self explanatory and simple process. Once Putty is up, configure the Host Name with 192.168.14.131 and click okay. Make sure you're on a personal network. You don't want to be on someone else's network where you can access a machine of the same IP address.


A Security Alert Pops up for me. I clicked okay, you should be fine if you're on a personal network.


The command line will request credentials. Place admin and toor as the username and password respectively - and viola!



From the router, you can also see that there's an external connection.
show ssh
who


ASDM will also show the SSH connection.

Navigate to Monitoring to Properties to Connections.