CAM Table Overflow – How to Run a CAM Table Overflow Attack in GNS3 Using Cisco 3725 Routers

cisco-iosgns3mitm

I am currently working on MiTM attacks and defenses in a virtual environment using GNS3 and an IOS c3725 (c3725-adventerprisek9-mz.124-15.T14) image to emulate some topology.

The current experiment regards CAM table overflow, and works great with a standard GNS3 switch, but when I use the c3725, the result is quite unexpected. I should be able to completely fill the CAM table on the device. However, as you can see from the following figure, it is not the case:

Attacked device: CAM table

There is always room "reserved", that I cannot fill. As I need STP and some other protocols, I cannot use the regular GNS3 switch. There is no security enabled on the device. Is there a native security feature, setting, or anything I am no aware of?

Thanks for your help!

Best Answer

Well, you're hitting that space where emulation and physical world interconnect.

First, let us cover the basics: 3725 is a router, and it has some limited switching capabilities, because it could (in real world) use switching modules, and the switching code was needed in IOS.

When you write 'standard GNS3 switch' I assume you mean NM-16ESW module emulated by the dynamips? If so, that's exactly the module and code you're using anyway with 3725.

For any security type of testing, including CAM exhaust attacks and even port security, I'd do testing only in real environment. Emulated/interpreted in run time setup doesn't always provide the same (or repetable) results for multiple of reasons, and it's plainly visible in any time-bound features, like QoS and some parts of security mechanisms (that count on proper timing and order of events triggering in IOS).

Now, going back to your question: there are two parts of answer:

  • First, the code that manages the CLI output for "software switching" IOS code that was added back when the NM-16ESW was introduced, underwent a lot of changes during the product lifetime. One of the extensions was to add 'backpressure' to allow faster MAC aging when there's flood of new addresses, the same code was also present in the standalone switches of that time (Catalyst 2950 and later models - 2960, 3560 and 3750). You may be hitting this exact feature, as you're using pretty new IOS (12.4(15)T). So, the switch may simply fast-age old MACs that it didn't saw any traffic to/from, and install new entries you're flooding - how fast BTW is your flood?
  • The other part of the answer is that this command was fixed multiple times as it wasn't always giving current situation, but some older, cached one gathered from the ASICs.

Again, doing that kind of testing with simulated environment just pushes it too far, I'd go back to some hardware setup and test/lab it to reflect real scenario. Even if you hit success, you may not be able to repeat it in predictable manner later on.