Kali Linux :: CAM Table Overflow Attack Demonstration
As part of my on-going studying for the CCNA Security 210 – 260 certification I have been exploring different types of network attacks, one of which is CAM table overflow attacks. In this article I would like to share what I have learnt and provide a demonstration of the attack carried out in a lab environment.
To understand my demonstration, you first need to understand how a CAM table overflow attack works and what happens as a result of the attack.
Switches build Content Addressable Memory (CAM) tables based on mac-addresses and port numbers. When a switch receives a frame it checks the table to see if the source mac-address is already known, if the source mac-address is unknown the switch will add the mac-address to the table along with the port number. The switch then checks the destination layer two frame and if no entry exists the switch broadcasts the frame out of all ports except the port in which the frame was received. Presuming the destination mac-address wants to respond to the source, it would send a frame back towards the switch and the switch would then add the mac-address and port number of the destination to the CAM table before forwarding it to the target device.
Switches can only store so many mac-addresses in the CAM table, if the table becomes full we start to run into all sorts of issues, something we don’t want. If nothing is received on a port, Cisco switches store mac-addresses for a maximum of five minutes before erasing the entry. Although this helps to keep the CAM table populated with relevant entries, a CAM table overflow attack can soon populate the CAM table with illegitimate entries.
A CAM table overflow attack occurs when an attack runs tools that generate random mac-addresses to populate the CAM table. Once the capacity of the CAM table is consumed with random mac-addresses, no new mac-addresses can be learnt and the switch begins to flood traffic from new hosts out of all ports on the switch. In essence a CAM table overflow attack turns a switch into a hub, this allows a malicious attack the ability to eavesdrop on information and perform a man-in-the-middle attack.
We have a few options that exist to help us protect against CAM table overflow attacks but before I go over them let me demonstrate the attack.
Topology & Demonstration
To give you an idea of my lab demonstration test, below is the topology.
The demonstration lab consists of one client machine, a Kali Linux (Attacker) machine and a layer three switch. The Kali Linux machine will be used to generate the CAM overflow attack.
Step 1.
In order to populate the switches mac-address table I sent some frames from the client and attackers machine to the switch. Below is the output of the populated mac-address table on the switch. The attacker is connected to Et0/1.
Step 2.
Now that we have attacker communication verified we will access Kali Linux (attacker) and perform the CAM table overflow attack. To do this access Terminal and enter the following;
macof -n 1000
This command will tell the macof tool to send 1000 random frames to the switch. We could just keep sending random mac-addresses until stopped by typing ‘macof‘ and pressing enter but by doing so you could crash the switch.
Press enter and you should see a similar output to the one below.
The random frames have now been sent to the switch.
Step 3.
To verify the random frames have been stored in the switches CAM table, access the switch and enter the following;
#show mac address-table
You should be able to see all the random mac-addresses that have been stored in the CAM table. As mentioned earlier, if you continuously run macof you will exhaust the CAM table and cause the switch to crash or act as a hub and forward all packets.
As you can see, it’s not too hard to perform this attack given the switch has no security measures in place.
I will now demonstrate how we can protect against this type of attack by using port security features.
Cisco devices offer port security features that are used to help protect against layer two attacks such as the one I’ve just demonstrated. The continuation of this demonstration will now focus on securing the layer two network.
Step 4.
The random mac-addresses we generated will timeout after five minutes unless removed by using the following command;
#clear mac address-table dynamic int e0/1
We can then confirm that the mac-addresses have been removed successfully by entering the following command;
#show mac address-table dynamic int e0/1
Before moving onto the next step I also generated some legitimate traffic from the attacker to the switch to bind the device mac-address again.
Step 5.
I will now enable port security and only allow a maximum of five mac-addresses on port e0/1. I will also configure the switchport to shutdown if the maximum number of mac-addresses is reached. Enter the following commands;
#switchport port-security #switchport port-security maximum 5 #switchport port-security violation shutdown
and verify the configurations by entering the following;
#show run port-security
Note: Port security offers three different violations, protect, restrict and shutdown.
- Protect: allows all mac-addresses seen before but not new ones
- Restrict: similar to protect but also generates SNMP traps and syslog messages when a violation occurs
- Shutdown: When a violation occurs the port will shutdown and placed in an error-disabled state until recovered
Step 6.
Go back to the Kali Linux (attacker) machine and run the ‘macof‘ command from the terminal again.
Now return back to the switch, you should now see syslog messages indicating the port, in my case e0/1 has been shutdown.
As shown in the image above, the syslog messages indicate e0/1 has been placed into err-disable mode because a violation has occurred. To view the status of the interface enter the following command;
You should see similar outputs like the ones below.
I have now shown you how to stop a CAM overflow attack by using port security. To recover the err-disabled port we do this either automatically or manually by entering the following configurations;
#interface e0/1 #shutdown #no shutdown #show int e0/1 status
I hope you have found this article informative, thanks for reading.
