BPDU Guard, Root Guard + Port Security


I’m still using the topology above. I am going to setup the following security measures BPDU Guard, Root Guard and Port Security and use the Kali Linux box in my topology to launch attacks FUN TIMES!

BPDU Guard

So BPDU Guard is used to protect the switch from an attacker that connects into the network via a switch port. Host port (Access port) shouldn’t send in BPDU messages into the switch. Once you enable BPDU Guard on an access port and a BPDU message is received on that port the switch will disable the port. This could prevent manipulation of your current STP topology.


The port was already configured as an access port on VLAN 10. I have R1 acting as a DHCP Server handing out IP addresses in the range so the Kali Linux machine got the IP address of

To enable BPDU it is straight forward using the command #spanning-tree bpduguard enable

Now that BPDU Guard is enabled it is time to send in BPDU messages on the access port Gi1/1.

On the Kali Linux machine I’m using an attack tool called Yersinia. I used the interactive option which is:

root@kali:~# yersinia -I


I know I’m not showing much in the screen above but the second line in the output is the BPDU packet getting sent into the access port of the switch which results in the port getting shutdown.


Before I sent the BPDU packet in on Access port Gi1/1 I checked the status of the interface and you can see that it is connected meaning it’s up and on VLAN 10.

Next, the BPDU is sent on Gi1/1 from the Kali Linux machine causing the port to go err-disabled and it was shutdown automatically by the switch as you can see from the second interface status command.

To get the port back up you have to bring it back up manually (there is a way to do it automatically which I will show later). You need to go into the interface do a shutdown followed by a no shutdown, doing just a no shutdown will NOT bring it back up.


So as you can see I just did a no shutdown first and the port didn’t come back up, but after doing a shutdown followed by a no shutdown the port came back up.

As I mentioned above you can have the switch automatically bring the port back up after a period of time with no BPDU violations.

Enter the commands below in global configuration to enable errdisable recovery for BPDU Guard.


I’ll launch another attack on that port and let us see the port go down and back up automatically.


As you can see (just about) that the port went down at 20:35:01 due to a BPDU Guard violation and 30 seconds later the port came back up at 20:35:31.

Root Guard

I have removed BPDU Guard from interface Gi1/1 and now I’m going to configure Root Guard. Root Guard is useful if you have your switch connected to another switch you do not manage or have no control over, to prevent it claiming root for STP and causing problems with your STP topology or you may have a less powerful switch in your topology and you never want that less powerful switch becoming the root switch.


Go into the interface that is connected to the other switch in my case I am configuring it on the port that is connected to the Kali Linux machine so I can run an attack to try and claim that I am the root switch. Once I run the attack you can see that the switch puts the port in blocking mode.


The port is now in blocking mode. The port will unblock once the attack or the switch stops trying to claim that it’s the root switch.

Port Security

How many MAC addresses should a switch port have? One for the host that is connected to it? What about if that same user has an IP Phone? We might see two MAC addresses on that port. However, you do not want hundreds of MAC addresses on any given switch port and the main reason for that is the switch can only hold so many MAC addresses in its CAM table. If a switch is overloaded with too many MAC addresses than what it can’t hold in its CAM Table memory will be broadcast to all ports in the switch because it can’t add the MAC port mapping to its CAM table anymore.

This is where port security comes into play. We can use port security to restrict the number of MAC addresses allowed on a switch port. For example, if you set the limit to 2 MAC addresses and a 3rd MAC address showed up on that port the switch could shut the port down in doing so it is protecting itself from an attack such as the CAM table overflow attack where an attacker floods the switch with spoofed MAC addresses and filling up the CAM tables memory.

Before putting on port security on my access port I’m going to run a CAM table overflow attack using my Kali Linux machine and a tool called macof. This will send in thousands of spoofed MAC addresses and cause the CAM table to fill up.


At the moment I don’t have a lot of MAC addresses in my MAC table. Running the #show mac address-table count command shows me that I have one MAC addresses in VLAN 1 and another in VLAN 10.

I’ll now log into the Kali Linux machine and run the macof attack.


This is a screenshot of the macof attack in progress sending thousands of spoofed MAC addresses into the switch. My switch started to complain straight away about CPU load which isn’t surprising since I am running all of the nodes in VM as it is.


As you can see the number of MAC addresses on VLAN 10 is now at 11983 and I only ran the command for a few seconds as my switch wasn’t responding due to high CPU. This just shows how easy it is to cause damage to a network running a simple attack.

I’m going to configure port security on port Gi1/1 so it will shut the port down after it receives more than 5 MAC addresses. Again just like BPDU Guard you can configure the switch to automatically bring the port back up after a period of time, 30 seconds is the default and minimum time you can set the errdisable recovery command to.


Above shows how to configure port-security and setting the max allowed mac addresses to 5. Also, I set the port to shutdown if a violation happens. You can set a violation to take different actions depending on how you configure it. They are: Protect, Restrict or Shutdown.

Also included in the printout above is the current state of the ports with port-security configured on them. There is a mac address on each port and both of the max allowed set to 5 and there are no violations at the moment and lastly what action should be taken if a violation is triggered and that is to shutdown the port.

Time to run macof again and see what happens!


As you can see that port-security detected the attack and shutdown the port!

Layer 2 Best Practices


I am currently working Layer 2 best practices. To help reinforce this I am using the above lab setup. I’ll be mainly working on the switches you see in the topology although I might call in the Kali Linux machine and run some attacks on the switches after I have configured some of the security features to demonstrate how they work.

To get started lets see what the current state of the interfaces are, are they access ports or trunk ports and what vlan are they in? To do this use the command:

show interfaces status

int status

We can see that port Gi0/0 is a trunk port. This is the port connected to R1. Gi0/1 is an access port and in VLAN 10 this is the port connected to the PC1 and ports Gi3/2 and Gi3/3 are trunk ports connected to SW2.

Locking Down Ports

In the printout below I move ports Gi0/2 and Gi0/3 using the range command into VLAN 100. This VLAN is used as a placeholder for ports that haven’t been assigned to particular VLAN yet. I’ve also configured the port as an access port and disabled auto-negotiate which turns off DTP. To finish off I’ve ‘shutdown’ the ports instead of leaving them up.


Run #show interface status


As you can see ports (interfaces) Gi0/2 and Gi0/3 are now members of VLAN 100 and are also disabled i.e. shutdown. You would repeat this for all other unused ports on the switch to secure it. When a port is needed you just go into the interface and configure the VLAN it belongs to and do a ‘no shut’ to bring the port back up. Or you could change it over to a trunk port using the following commands:


Above shows how to configure a port (interface) as a trunk port. You first need to tell the port what encapsulation to use you can select dot1q or isl (cisco proprietary) or negotiate. I selected dot1q. I configured the port as a trunk and also told it to use the native vlan 99. Although not shown here you would also disable DTP on the port using the nonegotiate command.

So why disable DTP? Well if someone wanted to gain access to your network they could plug in their laptop to a switchport or a wall jack and run a piece of software that could run DTP and negotiate a trunk port tricking the switch into thinking it is connected to another switch. The attacker would have access to all the VLANs on that switch and could sniff the traffic to see what was on the network. By disabling DTP using the ‘nonegotiate’ command you prevent this from happening.

In my next couple of posts, I’ll be covering port security, BPDU Guard, Root Guard, DHCP snooping, and access lists and showing how to configure them and run some attacks against them.



How-To: ASA in GNS3 with ASDM

After struggling to get the ASDM to work in GNS3 I thought it would be a good idea to write a blog post on how to get the ASA and ASDM working within GNS3.

Below is the ASAv image I am using and also the version of GNS3. Note if you want to run an ASAv image you must run it in GNS3VM and not in the GNS3 local.

ASA image: asav952-204.qcow2 (VIRL image)

GNS3VM Version: 2.0.0b3 on Windows

The GNS3 team have a great video showing you how to import the ASAv image into GNS3.


I would strongly recommend that you view that video.

They also recommend that you use the ASAv directly from Cisco’s VIRL software. A google search will get you the image you need.

I had a few issues getting the ASDM GUI working initially, note that you do NOT have to import the ASDM .bin file onto the ASA it is already on there even if you can’t see it when you do a dir, trust me it is!

Below is the topology I am using. Drag your newly imported ASAv image onto the workspace along with the GNS3 Ethernet Switch and the Cloud object. Connect the ASA Management 0/0 interface to the switch and then using another port on the switch connect it to the Cloud and select eth1 as the interface on the cloud, the eth1 interface should be bridged from VMware to your local machine.


Next, you need to configure the ASAv to get an IP address via DHCP and also activate the http server on the ASA and allow the IP that you get from DHCP to access the http server on the ASA.


When you go into enable mode it will ask you for a password don’t panic as you just press enter and it will continue into enable mode this is the default behaviour of the ASA. Go into configuration mode and configure the management interface as shown above.

Wait a minute and then run the #show ip command. As you can see in my setup I’ve been given an IP address of

Next, we need to enable http servers on the ASA to allow us to access it via the ASDM GUI.


The commands to do this are #http server enable and #http 0 0 mgmt. I cheated a bit by using the http 0 0 mgmt command. I could have said only allow the IP address or subnet of access the ASA via the ASDM. The command I used above is basically allowing any IP to connect to the ASA because this is just a lab that is fine you wouldn’t want to do this on a production ASA.

So you are all set now to access the ASA via the ASDM GUI. Open a webpage and enter the IP address that was assigned to your management interface via DHCP. NOTE you must use HTTPS:// after all it is a security device we are accessing here.

webpageYou will get a warning message when you first try to connect to it saying that it isn’t secure as the certificate is a self-signed certificate from the ASA and your browser will not recognise it as a trusted site. Just click on Advanced and add exception.


At this stage, you should get the following screen. Note you’ll need to have java installed on your machine to be able to run the ASDM. Select Install ASDM Launcher this will install an icon on your desktop so you can run the ASDM directly from there which will save you having to go via a webpage each time. When you start the ASDM launcher you’ll be asked to put in the IP address which will be the IP address that was assigned to the management interface. I didn’t set a username or password just click on connect.

You should be now logged in 🙂




ASA Lab with ASDM


It has been too long since my last post. I’ve been very busy in work and also studying away working towards CCNA security. I just wanted to show what my latest topology looks like that I will be using to study with doing as many labs as possible. Hopefully, this will grow over time.

The topology as full access to the Internet which is great.

And also the most important piece is I have the ASDM running from my browser on my PC 🙂 as you can see below.


This is a big deal as I will be able to configure the ASA from the ASDM and practice using it as much as possible.

I will probably add a zone-based router to the topology at some stage as well. The switches are vIOS switches which will allow me to do Port Security and DHCP Snooping etc.

If you have any questions on the setup let me know.

Note: The lab has been built using GNS3 version 2.0b3



IPSec Site-to-Site VPN


In this post, I will show you how to setup a site-to-site VPN using IPSec. I read up on IPSec and its two tunnels IKE Phase 1 (Management) and IKE Phase 2 (Data) and thought the best way to understand this is to create a lab.

Lab Topology


Above is the lab that I set up. A few things to know.

I am using BGP between R1-R2-R3. R1 is Site1 and R3 is Site2. R2 is the Internet. I’m not going to through setting up the eBGP peerings but the main thing once configured is that you can ping from Site1’s public IP address to Sites2’s public IP address. If you would like the configuration files for the basic setup including eBGP let me know and I will share them with you.

Lab Objectives:

  1. Setup IKE Phase 1 Tunnel using the following parameters:
  • Hashing= SHA
  • Authentication= pre-shared key
  • DH Group= 5
  • Lifetime= Default
  • Encryption= AES-128

2. Setup IKE Phase 2 Tunnel using the following parameters:

  • Create a transform set using esp-des and esp-md5-hmac
  • Create a crypto map with the peer address, reference the transform set and access-list
  • Create an access-list to identify interesting traffic to encrypt using the IPSec tunnel

Lab Configuration

With connectivity already in place, we should be able to ping each sites public IP address across the Internet.

Site 1:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/24 ms

Site 2:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/40 ms

Also, we should try and ping each LAN PC. This is to show that at the moment we have no way of reaching each sites LAN but when we setup IPSec our data will be encapsulated and encrypted using the public addresses.

PC1 (Site 1)

No dice as expected!

PC1> ping icmp_seq=1 timeout icmp_seq=2 timeout icmp_seq=3 timeout icmp_seq=4 timeout icmp_seq=5 timeout

PC2 (Site 2)

Same result!

PC2> ping icmp_seq=1 timeout icmp_seq=2 timeout icmp_seq=3 timeout icmp_seq=4 timeout icmp_seq=5 timeout

IKE Phase 1

Keeping in mind the Lab Objectives lets set up each of the IKE Phase 1 requirements.

First, we need to setup a isakmp policy.

Site1(config)#crypto isakmp policy 1

A good way to remember what parameters can be set in IKE Phase 1 is the word HAGLE.



G=DH Group


Site1(config-isakmp)#hash sha
Site1(config-isakmp)#authentication pre-share
Site1(config-isakmp)#group 5
Site1(config-isakmp)#encryption aes 128

I left the lifetime of the tunnel to the default here for this lab. Note that the parameters need to match on each site for the IKE Phase 1 tunnel to come up.

Next step is to set the pre shared key that will be used between the two sites. Lets use mrrobot.

Site1(config)#crypto isakmp key mrrobot address

Here we have entered the shared key to use and also the peer address we want to use it within our case Site 2.

IKE Phase 2

This tunnel is the IPSec tunnel which will be used to encrypt user data.

Site1(config)#crypto ipsec transform-set myset esp-des esp-md5-hmac

Here we are using a transform-set with the name myset given to it and we are using esp-des for encryption (weak very weak but it will do for the lab)  and esp-md5-hmas for hashing and integrity.

Next, we will set up a crypto map

Site1(config)#crypto map mymap 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Site1(config-crypto-map)#set peer
Site1(config-crypto-map)#set transform-set myset
Site1(config-crypto-map)#match address 100

Here we are telling the crypto map called mymap what peer to setup the tunnel with, the transform set to use and what interesting traffic to match.

Next setup the access-list that the crypto map is using.

Site1(config)#access-list 100 permit ip

With this access-list we are telling it to match traffic from Site 1 LAN with a destination of Site 2 LAN any other traffic that does not match this access list will be sent unencrypted.

Lastly we need to apply the crypto map to the public facing interface.

Site1(config)#int fa0/0
Site1(config-if)#crypto map mymap
*Mar 1 01:12:06.375: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Ok that is everything we need to configure on Site 1 for IPSec. I am not going to go through the same for Site 2 as it is pretty much the same but in reverse.


So lets test this out to see if it works if it does traffic that we tried to send earlier from Site 1’s LAN should now be successful.

Ping from PC1 to PC2

PC1> ping icmp_seq=1 timeout icmp_seq=2 timeout
84 bytes from icmp_seq=3 ttl=62 time=36.000 ms
84 bytes from icmp_seq=4 ttl=62 time=39.000 ms
84 bytes from icmp_seq=5 ttl=62 time=43.000 ms

Success ! The first two packets that failed could be due to ARP and/or the time it took for the two Tunnels to be built.

And just to show the other side is also working.

PC2> ping
84 bytes from icmp_seq=1 ttl=62 time=36.000 ms
84 bytes from icmp_seq=2 ttl=62 time=42.000 ms
84 bytes from icmp_seq=3 ttl=62 time=50.000 ms
84 bytes from icmp_seq=4 ttl=62 time=49.000 ms
84 bytes from icmp_seq=5 ttl=62 time=46.000 ms

Show commands

IKE Phase 1 Tunnel

Site1#show crypto isakmp sa

dst          src                     state               conn-id    slot         status             QM_IDLE      1                  0             ACTIVE

Here we see that we have an IKE Phase Tunnel Active.

IKE Phase 2 Tunnel

Site1#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: mymap, local addr

protected vrf: (none)
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
current_peer port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.:, remote crypto endpt.:
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xD796A48B(3616973963)

A lot more information in the IPSec output. We can see what interface the crypto map is on. What is the local and remote addresses that are getting encrypted? The current peer. The number of packets sent and the number encrypted.

eBGP Configuration

As requested from by Muadiv here is the BGP configuration on each router for this lab.

Site 1:

router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor remote-as 2
no auto-summary

Internet Router:

router bgp 2
no synchronization
bgp log-neighbor-changes
network mask
network mask
neighbor remote-as 1
neighbor remote-as 3
no auto-summary

Site 2:

router bgp 3
no synchronization
bgp log-neighbor-changes
neighbor remote-as 2
no auto-summary


Labs Labs Labs…

For me labs are the most important part of my pursuit of certification. I am a visual learner more than anything else and I find doing labs is a great way to learn and it also helps you remember topics and commands. Another important part is troubleshooting your lab, when you first configure something chances are it wont work fist time round so you have to think about what steps you have taken in configuring the lab and start troubleshooting the issues. What a great way to learn.

So what is the best way to practice using labs? The lab rental model is good if you don’t have the physical hardware, it can be expensive to buy and run in your own home lab, the other option is to run virtual labs on your own PC at home and its the one I use.

I built my own PC which was another great learning experience. It has a i5 Intel processor, with 16G of RAM, 250G SSD, ASRock Motherboard….I wont bore you with all the details but its a powerful enough machine.

So what is the best software out there to run on your own PC? I use a combination of software depending on what I am doing. I use Packet Tracer for every quick and basic labs. I also run GNS3 which is for more complex labs which I used a lot for my CCNP R&S certification exams.

But the latest one I am using is Unified Networking Labs or UNL for short. To run the UNL software you must use VMWare or VirtualBox and need a powerful PC depending on the complexity of the lab you want to run. You can download the software from http://www.unetlab.com/ if you are interested in trying it out.

So why UNL? Well it supports a lot of the security appliances you need to use for the CCNA Security exam. ACS, ASA, ASAv, Cisco Switches IOU, Cisco Routers to name a few. It is really important to get some hands on experience on the ASA in particular and also its GUI interface the ASDM.

Unified Network Labs

Below I will show you what it looks like and also setup the ASA and a Virtual Windows Machine to access the ASDM from all within the UNL system.

I wont go into detail on how to install the software as the UNL website does a really good job of that and also provides videos as well.

UNL Login Screen

Once you start the VMWare for UNL you log onto the system via your browser. Username/Password is admin/unl.

Once logged in you’ll get the following screen.


To create a new lab click on Actions and ‘Add a new lab’

After naming your lab and saving it it will appear in your list, double click on the lab and then select Open.


On the left hand side click the plus button to add an object and select node. Select ASAv from the list to add it to the lab, do this again and select Windows to add a virtual Windows machine. Next select the link icon to add a link between the nodes. asdm

Next step is to Start the nodes by right clicking on them and selecting Start. Now the fun begins configuring the ASAv and Windows machine so we can not only configure the ASAv via the CLI but also using the ASDM GUI.

First thing we need to do is configure the ASAv node. I am using putty here.


First step, configure the management interface that is connected to the Windows machine. Here I gave it an IP address of

I then enable http server and also told the ASA what network is allowed to connect to it.

What isn’t shown in the screen capture above is configuring a username and password to use via the ASDM. The command for this is:

#username admin password admin123 privilege 15

You also need to tell the ASDM how to authenticate the user and what database to use. I’m just using the local ASA one.

#aaa authenticate http console LOCAL

That is it ! now save your configuration using wr command.

Next the Windows machine. I connect to it via Remote Desktop Viewer (I run Linux on my home PC)


Nothing special here apart from the fact that you need to have the Windows machine on the same network as the ASA. Open up Network Connections and enter in an IP address in the subnet. I used

Once configured run a quick ping test.



Double click on the ASDM icon to launch the ASDM and configure the IP address as the IP address you gave the management interface on the ASAv in my case and the username/password of admin/admin123.



Bingo ! I am now connected to the ASAv via the ASDM GUI.

I hope you find this useful. Any questions just ask in the comments section.

NOTE: You need to download and install the different images you want to use in the UNL system via the Cisco website just like you have to do with GNS3. The UNL website has a HOW-TO guide on how to import them into the system.


Both MAC and IP Addresses can be spoofed using different tools available to an attacker.

They might carry out a ARP poisoning attack creating a Man In The Middle so they can see all traffic going between host devices and the default gateway of the network. CAM table overflow attack is another were an attacker would send thousands of spoofed MAC addresses into a network to fill up the CAM table of a switch.

Attackers spoof IP Addresses when carrying out DDoS attacks particularly when using reflection attacks. The attacker would set the source address to the end point they want to attack so when they send a request to an open NTP server on the internet using the ‘monlist’ command (which requests the last 600 IP addresses that requested time from the NTP server) the reply will go to the end point that the attacker is targeting and not back to the attacker itself.

ISPs need to be part of the solution by deploying ingress filtering on their networks to stop attackers on their network spoofing IP addresses.




DoS (Denial Of Service) attack is aimed at making a network resource such as a website unavailable for valid use. These types of attacks are a major risk to a company’s infrastructure  and also their reputation. If a company offers a service available on the internet it can be targeted by an attack(s) for a number of reasons, they mightn’t agree with the companies policies, bought a service from them that didn’t meet their expectations, ex-employee and so on. Attackers can use known vulnerabilities in networking protocols to launch an attack with, such has a TCP SYN Attack. TCP is a reliable protocol which means it will keep track to see if all packets are delivered and if not it will resend the packets that were lost along the way. When a client (host) wants to communicate with a website it will first set up a TCP connection with the server. This is called the 3-way handshake as shown below.




With a TCP SYN Attack the attacker will keep sending SYN requests towards the target in our example the web server. In return the web server will send a SYN ACK back to the client but most likely the attacker is sending hundreds of requests from spoofed IP addresses and because of this the web server will never receive the ACK back. The web server is kind enough to wait for the ACK and in doing so ties up resources on the web server and the more SYN requests the more resources are used until all resources are used up. Now legitimate users traffic can’t establish a TCP connection with the web server as it cannot process the requests, the web server is now unavailable.

DDoS (Distributed Denial Of Service) uses botnets around the internet to attack its target. So what is a botnet? A botnet is a PC or even a smartphone that has been infected with malware. Once the malware is installed on the device it becomes part of a botnet network. These botnets are controlled by the attacker from a control and command server on the internet. The attacker can command the botnets to attack a target all at the same time. Examples of attacks used by attackers are Reflection attacks and Amplification attacks. A well-known reflection and amplification attack is using open NTP (Network Time Protocol) servers on the internet that are incorrectly configured and still respond to a monlist request.


Above is the NTP attack in action. The Attacker will send a request to the Botnets to target the Web Server. The Botnets will send a small request usually Kilobytes in size to the open NTP server(s) requesting a list (monlist) of the last 600 IP addresses that requested time from the NTP server but instead of the botnets receiving the reply the botnets spoof the source IP address to be that of the Web Servers (Reflection) address meaning all replies will go towards the Web Server. The NTP reply can be 10 times the size or more of the initial request (Amplification) meaning Gbps worth of data hitting the Web Server causing it to crash or using up all the available bandwidth. DNS servers can be used in a similar way.

With the explosing of IoT devices available on the internet has seen an increase in DDoS attacks. IoT devices have poor security with many of them having the same default username/password to access the devices. A recent IP CCTV DDoS attack was launched which was 620GBs in size. Thousands of IP CCTV cameras were taken over due to weak passwords and used to attack a website. When setting up IoT devices the manufacturer should force the user to change the default password using a minmum of 8-10 characters which should include uppercase, special characters and numbers which would be a start in stopping attackers from getting access to the IoT devices on the internet.

ARP Poisoning Lab

It has been a couple of weeks if not more since I last posted on my study blog. Life getting in the way as it does. But I hope to get back on track now.

In my last post I talked about ARP Poisoning and how it works as a Man In The Middle attack. So how do you stop this sort of an attack?

Does something called DHCP Spoofing ring a bell? I previously talked about it and how to stop it in the DHCP Spoofing post. So if you need a refresher click on the link and then come back here.

So we can use the DHCP Snooping database to help us also stop ARP poisoning after all the database keeps mappings of IP addresses to MAC addresses and what port they were learnt on. So for this to work you need to already have DHCP Snooping enabled. If you are on a non-DHCP network you can setup ARP ACL lists to do the mappings instead.

To enable ARP Inspection you need to enable it in Global Config mode  and it is done on a per vlan basis.

#config t

#ip arp inspection vlan 123

Just like with DHCP Snooping untrusted ports will DROP any traffic that does not match the IP address to MAC address mapping on that port. And just like with DHCP Snooping you can set ports (Interfaces) to be trusted. If a port is changed to a trust port it will not be subject to inspection and it will allow the traffic to flow. To change a port to a trusted port go into the interface.

#interface fa0/2

#ip arp inspection trust

And that is it.

To finish out you can enable ARP Inspection on Access, Trunk and EtherChannel ports.