A MAC flooding attack is a technique used to compromise the security of switches on a network. When this type of attack is attempted, the switch is fed thousands of frames from a different source MAC address with the hope to consume all of the memory that has been allocated for the MAC address table. Legitimate frames will then be flooded out all ports similar to how a hub operates.
So why should you be concerned about this? There are two primary reasons, with the second being the most severe. First a Denial-of-Service comes into play where valid entries can no longer be added to the CAM (Content Addressable Memory) table. Second, switches only send data to the ports that need it. Now that it is acting like a hub, the attacker can use a packet analyzer to capture data that would otherwise be unavailable if the switch were working correctly (since data is now going out all ports). It is also important to keep in mind that the attacker would still be confined to the VLAN that he/she is on and not see traffic from other VLANs.
For this post, we will be focusing on the following topology with one Cisco 3750 switch and two VLANs. Our attack will take place on VLAN 30 and we will consume all available address slots in the CAM table. We will be using the Linux macof tool to flood the switch which has the capacity to generate 150,000+ frames with different MAC addresses per minute. I suggest that you do not do this on production equipment as it creates a lot of traffic and can hinder application availability.
Before we get started, the CAM table aging timer on our switch is set to 300 seconds (default value). You can see this by running the show mac address-table aging-time command. If a flood occurs and stops, the invalid entries should be automatically flushed in 5 minutes. Also, it is import to know the maximum number of MAC addresses that the switch can still hold. The show mac address-table count command in our case shows that space for 2,844 addresses remains. Next, let’s first see how many dynamic entries currently exist in the switch’s CAM table.
Switch# show mac address-table dynamic Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 30 0014.c23e.1fd2 DYNAMIC Fa0/10 30 0018.717b.0d26 DYNAMIC Fa0/11 30 001c.c47d.bb76 DYNAMIC Fa0/12 40 0021.5aaa.ff92 DYNAMIC Fa0/20 40 0021.5aab.fa34 DYNAMIC Fa0/21 Total Mac Addresses for this criterion: 5
Launch the macof command to start the attack by sending thousands of bogus entries to the switch. You should see entries similar to the following. I have truncated the output to make it easier to read.
81:55:33:fc:ad:62 5a:51:37:a9:cc:d4 0.0.0.0.21076 > 0.0.0.0.4901: S 1212679823 ... a2:15:a3:c9:e1:1a 8b:cc:34:ff:14:16 0.0.0.0.11432 > 0.0.0.0.6678: S 7258763489 ...
Also, you should observe that the CAM table is now full. Keep in mind that CAM tables of adjacent switches can also fill up depending on the maximum address space and number of bogus addresses.
Switch# show mac address-table count Mac Entries for Vlan 30: --------------------------- Dynamic Address Count : 2847 Static Address Count : 0 Total Mac Addresses : 2847 Mac Entries for Vlan 40: --------------------------- Dynamic Address Count : 2 Static Address Count : 0 Total Mac Addresses : 2 Total Mac Address Space Available: 0
If you run the show mac address-table dynamic command, you’ll notice that everything is coming in on port Fa0/16 (where the attack was launched). We don’t know yet if the attack has stopped so clear the CAM table by typing clear mac address-table dynamic. Run the show mac address-table dynamic command and make sure that there is available address space. If the count has returned to the high number the attack is still going on. If so, it may be best at this point to shut off the port before we configure port security.
Check the switch port under the running configuration to make sure it is in access mode. From here, enable port security to protect against future floods. There may be some cases where you can simply shut off the port, but lets say the site is remote and you know that there is a second switch connected to Fa0/16 with a critical server. Simply disabling the port for long periods of time could cause applications to remain down. In the example below we will restrict the number of MAC addresses and leave the port enabled.
Switch# conf t Switch(config)# int Fa0/16 Switch(config-if)# switchport port-security violation restrict Switch(config-if)# switchport port-security maximum 20 Switch(config-if)# switchport port-security
Let’s launch the attack again with the macof tool and look at the CAM table by running show mac address-table dynamic. If you have console logging enabled you should see violations occurring while we are looking at the switch.
10:33:16 %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address a7ff.d651.7001 on port FastEthernet0/16.
We have now prevented the MAC flooding attack. The new configuration allows the port to remain active but has stopped the attack from filling the CAM table by limiting the number of entries allowed on that port. Going forward, there isn’t a good way to monitor the CAM table size via SNMP (such as with a counter) but you can receive traps when a violation occurs similar to the above message.