Dynamic ARP Inspection (DAI) Mitigates ARP Poisoning to Prevent Man in the Middle Attacks (MITM)

Address Resolution Protocol allows a device to resolve an IP address with a mac address. By example, assume PC A is connected to a switch which is connected to a router. PC A needs to send traffic to the router’s IP of 192.168.4.3 but the switch doesn’t know which mac address to send this traffic to. ARP allows the switch to learn the mac address by forwarding a frame received from PC A’s port and broadcasting it out on all the other ports in the switch. This frame is asking what is the mac address of the device that owns 192.168.4.3? Devices on the other ports will drop the frame if it doesn’t match its IP address. The router will do the opposite and will send replies back with its mac address information because it has the IP address the switch was looking for. This enables communication between PC A and the router.

This ARP process, can be exploited through ARP Poisoning also known as ARP spoofing to eavesdrop on the traffic. Let’s say PC B is the attacker PC that will conduct ARP spoofing and is plugged into this environment above. PC B will send what is called a gratuitous ARP – it is an ARP message that wasn’t requested, but it is sent on its own accord to update ARP information. PC B’s ARP message directed towards PC A will show that it’s IP is 192.168.4.3, so send traffic to PC B’s mac address. PC B also directs a gratuitous ARP to the router saying that it is PC A’s IP address, so send traffic to PC B’s mac address. If the switch believes this, PC B will have successfully conducted ARP poisoning. PC B can than forward the frames between the router and PC A after eavesdropping or manipulating the traffic. ARP spoofing then becomes a MITM attack.

To mitigate this attack, Dynamic ARP Inspection can be used. When configured on a VLAN, it defaults all ports on the VLAN as untrusted and requiring traffic inspection. (Trusted ports are placed for trunks since access ports are mostly where attacks will come from. These are limited to 15 packets per second for ARP traffic to prevent attacks like ping suite.) The inspection verifies a traffic’s mac and IP address have a source or destination is true. DHCP Snooping tables allow this verification to happen for matches between which IP addresses where actually allocated to which mac addresses. This means that PC B will not be able to exploit traffic confidentiality as a MITM server, because DHCP Snooping would know that PC B’s mac address wasn’t provided with the IP address it claims to be.

Some devices will not be on the DHCP Snooping table. In these cases, a static ARP ACL can be manually configured to train a switch what mac addresses to look for to resolve an IP.

Other ways to verify includes checking the mac address of the header, or an IP address inside of a payload.

Taking precautionary measures at the layer 2 level, can help prevent compromise or the integrity of the traffic. Dynamic ARP inspection is a good measure to place as a checklist in hardening network security.

Private VLAN

Big Picture

Private VLANs allows an IP subnet to be used among different subset VLANs. It is categorized by a primary VLAN which is a regular VLAN configured to hold the secondary VLAN subsets. PVLAN design is used mostly in ISPs to separate customers from each other as it helps save addressing space in the LAN.

Another scenario a private VLAN may be is that a branch office in City A is given one Subnet IP. Private VLAN can be used to take this subnet IP and provide addresses to the secondary VLAN subsets.

What makes up the Private VLAN?

The Private VLAN is made up of the primary VLAN and secondary VLAN. An IP subnet is given to the primary VLAN which is shared with the secondary VLAN (subsets of the primary VLAN). As it is divided with the secondary VLAN, depending on the configuration, ports of the same subnet may not be able to talk to ports.

In the secondary VLAN, there are three main ideas:

1.     Community Group – This group allows all ports within this group to communicate with each other. Many community groups can be made in a secondary VLAN. But one community group cannot crossover with other community groups to communicate. The only way to get outside communication is to go through the promiscuous port.

2.     Isolated Group – There is only one allowed isolated group in a secondary VLAN. All ports in this group are not allowed to communicate to each other. If it needs to talk to the outside world, it will go through the promiscuous port.

3.     Promiscuous Port – It is called such due to the willing nature of the port to communicate to all ports. That means it will talk to the Isolated, and Community Group, as well as the outside world. Usually the Promiscuous Port is connected to a default gateway, which will know how to send the traffic.

If the Private VLAN is configured correctly, this will allow a proper IP subnet addressing; additionally it’ll provide the functionality of privacy in a community, or for isolated individuals.

DHCP Snooping vs Raspberry PI (A beginner concept)

Elliot is a savvy techie that works at Price Wright Corporation. This morning, his routine seemed all too normal. He arrived at work at 9am sharp, filled his mug with coffee and started to chat with his colleagues. As he chatted away, the back of his mind was running with a technical sequence he planned to execute.

In Elliot’s backpack, he brought a specifically configured Raspberry PI that would do his bidding. The fifth floor of Price Wright Corporation was under construction. No one was on this floor. This is where he would find a port to plug in the router. He sneaks away from the conversation he was having, and proceeds to execute his plan.

At his cubicle, he remotely checks to see if his plan worked. The Raspberry PI should have already ran the necessary configurations.

1.     DHCP Starvation Attack – Kali is running on the Raspberry PI. A script on this OS would begin the process to flood Price Wright Corporation’s DHCP server with fake DHCP requests. The DHCP server would no longer be able to hand out IP addresses at this point.

2.     Rouge DHCP Server – Then the Kali box would supplant the DHCP server. All devices would then be requesting IP address information from Kali. That includes the DNS Server, and default gateway information.

3.     Man in the Middle – End clients would have their traffic rerouted because, IP addressing is owned. Traffic would be forwarded to a MITM Server as a proxy to the internet. All traffic would then be visible to Elliot. The network would be considered owned.

When Elliot logs into the remote server traffic is to be forwarded to, he finds no forwarded traffic. After troubleshooting, he finds out the Kali Box was denied of the DHCP server status.

In this scenario, the DHCP Starvation attack is thwarted by a concept called DHCP Snooping. When DHCP snooping is applied, switch ports are able to restrict the type of DHCP data that is forwarded to it.

DHCP negotiation is remembered by the acronym DORA – Discover, Request, Offer, and Acknowledgement. Discover and request traffic are made by machines requesting for IP address information, while the offer and acknowledgement traffic are DHCP server traffic. The DHCP server traffic should only come from the appropriate DHCP server. DHCP snooping restricts ports that should not have DHCP server traffic running through it. This was the case for Price Wright Corporation.

DHCP snooping was enabled for Price Wright Corporation which restricted the Kali Box from acting as the DHCP server. Their environment only allowed DHCP server traffic coming from the access port of the main DHCP server, the trunk link to the switch of the fault tolerant server, and the access port of the fault tolerant DHCP server.

Although there are malicious reasons rogue DHCP servers enter the environment, it is also very likely an accident by an employer. Sometimes employees bring in a router to have more accessible ports, and when it’s plugged into the company network, the router acts as a DHCP server. The intent isn’t malicious if done by accident. It was an unknowing mistake. Routers by default become a DHCP server when plugged into a network. If computers decide to use this DHCP server, they won’t be able to talk to the network. The accident would cause a denial of service, DoS.

Kali’s Macof for CAM Table Overflow Attack is Denied by Port Security

Kali OS, the one with the cool dragon logo on it is a great toolkit for the hacker’s arsenal. If you’ve ever seen Mr. Robot, you’ll see the dragon symbol on their computer to own Evil Corp. With this OS, networks can be owned, if they aren’t configured well.

Macof is a program that can run inside the Kali OS. If this is run against a port on a switch, it does what’s called a Content Addressable Memory Table Overflow Attack, or CAM Table Overflow Attack for short. The CAM Table is used to remember which port to reference a mac address to. Because, the table can only store so many mac addresses, older mac addresses start to be removed when the table reaches capacity. This is what begins to happen when the macof program is utilized, the program sends 1000s on 1000s mac addresses until CAM Table reaches capacity and the oldest mac addresses are removed.

So why is this an issue? Let’s say there’s a switch with CAM Table capacity of 2000 mac addresses. On this switch there are three ports occupied. One is a Windows computer, and one of them is an Ubuntu machine. These machines have been on the switch and have been able to send traffic as wanted. Until now. A Kali laptop is newly plugged into the switch. It runs the macof program. The CAM Table Overflow Attack makes the switch forget the mac addresses for the two other legitimate computers. Therefore once these computers try to talk with each other, the switch will not know which ports to send the traffic to, as the port reference for the mac addresses has been forgotten. Switch logic then dictates, to figure out who owns these addresses by sending out the traffic to all the ports (except for the one the traffic initiated from). When the traffic is sent, the Kali Laptop can then receive and interpret the traffic from the other devices on the switch.

The CAM Table Overflow attack is a huge risk. This attack leaves traffic exposed, and can make avenues for further risk escalation into the network ie DNS Poisoning via MITM. Luckily, switches have preventative measures to mitigate risks, and to specifically block the CAM Table Overflow attack.

Port security is the preventative measure that Cisco switches have for attacks from Kali’s macof program. It prevents CAM Table overflow attacks by three major actions:

1.     Protect – This is basic protection and rarely used. It simply doesn’t allow for traffic beyond what is configured for it. For instance if a port is configured to have 3 mac addresses only, it will not allow traffic beyond these 3 mac addresses. So when a machine with the 4^th mac addresses is plugged into it, the port simply just does not allow the traffic to continue. There are no messages that are sent to alert administrators of this 4^th mac addresses, the port simply just prevents the traffic.

2.     Restrict – This is like protect in that it stops traffic from mac addresses that isn’t configured for the port. It also does an additional action by telling someone if there is a violation. A violation would look like a machine with 4^th mac address plugged into the port, when that port is configured to have 3 mac addresses on it. As soon as this machine is plugged in and tries to communicate, the port will not recognize the mac address and will send an alert to the proper administrator of this violation. Additionally counters are incremented of the violation.

3.     Shutdown – This has the same principle as the previous two ports. With this mode, traffic is still denied if there’s a violation. However, greater measures are taken by completely shutting down the port for a violation. Like Restrict Mode, this will also send SNMP alerts and increment counters.

It may be helpful to note that I have also seen Shutdown VLAN added to this list if a violation occurs.

To differentiate the appropriate mac addresses to be allowed on a switch, there are also three primary modes that can be configured for this. By default, switches are configured to have one mac address per port. But this can also be configured with the help of three primary modes:

1.     Dynamic – Mac addresses are learned without any manually configuration. If a port is set to have 4 mac addresses, dynamic mode will learn and apply the first 4 machines that are plugged into the port. Beyond that, a violation occurs. This is the default mode.

2.     Static – This mode requires that mac addresses are applied manually. If port security allows to have 3 mac addresses on a port, then 1 mac address can be assigned manually, and also allow 2 more mac addresses allowed through dynamic mode.

3.     Sticky – Sticky is like dynamic and allows a direct save to the running configuration. So if the running configuration is saved to the startup configuration, when a switch is rebooted, the mac addresses remembered.

Port security can also be configured more specifically. Though any configuration of port security is only limited to access or trunk ports. So if a switch has a port that is dynamic and allows for either access or trunk ports, then port security cannot be configured here. If a port is either an access or a trunk port the configurations, and even more specific port security configurations can be made. More specific configuration include different capacities of mac addresses allowed on each vlan; what mode a vlan can have; and also aging the mac addresses out of the CAM Table.

The problem of the CAM Table Overflow attack can be defended with the proper implementation of port security. If the switch in our attack scenario was configured to have a violation of 2 before shutting down, and the CAM Table capacity was at 8000, when Kali executed macof, nothing would happen and the port would be shutdown. An alert would be sent to an administrator, and they would have to investigate this port before bringing it back up again.

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.

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!

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

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.

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.

ping google.com

Success!

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.

6 - Proving Why Trace Fails Using Wireshark

Proving Why Trace Fails Using Wireshark

Intro

With the current lab setup (review below), trace from the virtual PC to the internet will not. The ASAv works with stateful packet inspection by default to only allow incoming external traffic if it was first requested from an internal source. Lower security levels (Outside Interface Security-Level 0) will allow incoming traffic if the higher security level (Inside Interface Security-Level 100) has first requested for it. A trace from the virtual PC to the WAN, looks like this is the case. But, a deeper look of analyzing the traffic's protocol, ASAv denies the return traffic because it is unrecognizable - to the ASAv, it doesn't look like the traffic was internally requested.

Before continuing the proof, below is a summary of the current state of the lab environment:

• 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

Wireshark integrates with GNS3. It can be downloaded separately, if your initial GNS3 setup didn't. This tool will allow us to capture traffic to see what's going on with the trace failing from the virtual PC to the outside world.

Write click the line outside of the ASAv and click start capture.

A pop up will show that allows you to name your packet capture. I've named mine Proving Failed Traces.

Once you've named the file, Wireshark will open up and start capturing traffic.

STEP 2

Let's place some traffic to analyze with Wireshark by forcing the fail from PC1.

trace google.com

As you can see, the fail shows when tracing google.com

STEP 3

Let's analyze the traffic back in Wireshark. 

As seen, the traffic starts with querying the 8.8.8.8 DNS Server to resolve Google's IP address. Once we have that the trace begins with the PAT'd address of the virtual PC, which is the ASAv's outside interface (faux public IP 192.168.14.130). The protocol going out from the PC out to Google is UDP. When traffic returns from the router (faux public IP 192.168.14.2) the incoming protocol is ICMP. Because ASAv uses stateful packet inspection, ICMP is unrecognized since it was not a protocol initiated from a higher level security (or the internal network).