Most IT pros have heard of CAM table overflow attacks or MAC address flooding attacks and understand at least the basic concept; send a ton of frames with different source MAC addresses to a switch, thereby causing the CAM table to fill and the switch begins to act more like a hub. While the basic idea is correct it’s not quite that simple. An important factor is how the switch manages the entries in the CAM table, Cisco switches maintain an entry until the aging timer for the entry expires. Even if the CAM table fills due to an attack the existing valid entries will continue to be honored and traffic for those addresses will not be flooded out all ports.

As an example I setup a 3750 switch with one computer and one router attached (the router could be a computer, it’s just what I had handy). The switches VLAN 1 was assigned 10.0.0.1/24 and the router 10.0.0.2/24. The computer was running Ubuntu with Wireshark and macof installed. Macof is a simple tool designed specifically to overflow a switches CAM table by rapidly generating thousands of packets with bogus source MAC addresses. I proceeded to test the switch’s reaction to a mac flooding attack as follows.

1. Started a ping from the router to the switch. As expected none of the unicast traffic was visible in Wireshark.

2. Started macof and verified that the CAM table filled. Still no unicast traffice in Wireshark.

(I’m not sure why the total mac address space available shows as 40 on my 3750, but the CAM table is indeed filled. Apparently it was a bug, an older IOS doesn’t exhibit the same issue.)

3. Cleared the MAC entry of the router from the switch’s CAM table. The replies from the switch to the router immediately showed up in Wireshark.

So what happened? As soon as the routers MAC address was removed from the CAM table the available slot was taken by one of the addresses spoofed by macof and when the next echo response was sent the switch no longer knew which port to send it to and had to send it out all ports in the VLAN. If I had not cleared the address I would have had to wait for the device to stop all communications for 5 minutes (the default aging time on Cisco switches), at which point the switch would automatically remove the entry.

It is also worth mentioning that filling the CAM table affects all VLANs on the switch. While traffic will still be confined to individual VLANs the switch will begin flooding traffic to all ports in each respective VLAN.

Mitigation

There are plenty of good guides for implementing port security to protect against CAN overflow attacks. I’m going to explain it again here primarily because I’m currently studying for the CCSP and explaining the topics is an excellent way to learn and ingrain the material in one’s head.

Port security is Cisco’s method of restricting which source MAC addresses can appear on frames entering a port. MAC addresses can be limited based on specific allowed addresses, the total number of MAC addresses seen on the port at any one time, or a combination of both. To stop a CAM table overflow attack in it’s tracks we only need to limit the total number of MAC addresses per port, I’ll discuss tying specific MAC addresses to a port in another post.

The ‘show port-security’ command will display an overview of all ports configured with port security, for more detail on a specific port use ‘show port-security <interface>’.

As you can see port security is not enabled on this port.

1. Port security only works on access ports, so we must first configure the port as such.

2. Now we can enable port security.

3. By default only one MAC address will be allowed on the port at a time. In some cases you may want to allow more than one, such as is you have a IP phone and computer attached to the port or if technical users have virtualization software installed on their computers. It takes thousands of MAC addresses to fill a CAM table so allowing a few per port doesn’t pose much of a risk. Here I’ve allowed 10 MAC address on the port.

You can see that the violation mode is shutdown, this means that the port will be shutdown in an err-disable state if more than 10 MAC addresses appear on the port. The two other options are protect and restrict. Restrict blocks any traffic from MAC addresses beyond the first 10 and logs a message to syslog. Protect is like restrict except that it doesn’t log any messages, and is useful if you want to make troubleshooting more difficult. We can change the violation mode like so.

Lets see how the switch reacts to a CAM table overflow attack with each the violation types.

Shutdown

To clear the err-disabled state the port must be shutdown then no shutdown.

Protect

Notice that nothing was logged to the console and the security violation count remains at zero. To clear the learned MAC addresses from port security use ‘clear port-security dynamic interface [interface]‘.

Restrict

In restrict mode messages are logged as the policy is violated and the violation count increments for each violating MAC address.

By default, once the maximum number of MAC addresses have been seen on a port no other devices may use that port until the MAC addresses are manually cleared. If you would like the allowed MAC addresses to be removed after a period of time aging can be configured on the port. There are two settings related to aging, one is the number of minutes until a MAC address is aged out, the other is the aging type. The aging type can be either absolute or inactivity. The default is absolute, which means that the aging timer starts as soon as the entry is added and will be removed once the specified number of of minutes elapses. The timer for inactivity starts when the MAC address is no longer communicating on the port and is reset if the MAC address start communicating again. Here’s how to configure the switch to age entries out after five minutes of inactivity.

After five minutes we can see that the total MAC addresses has changed from 10 to 0.

I hope this explanation of CAM overflow attacks and mitigations has been helpful. As always I welcome any questions, comments, or corrections.