One of the more spectacular reasons not to consider switches as a security feature is the CAM overflow scenario. The CAM that stores MAC-to-port associations has a fixed and limited size and is generally constructed in a nondiscriminatory manner. Whenever a system cannot be located in CAM, the switch has but one way to deliver the packet—it must fall back to the hub mode, broadcasting the packet to all systems, hoping the recipient will recognize this traffic as addressed to himself and that other systems will be nice enough to disregard it altogether. Thus, a careful attacker can employ a tactic to generate a large number of bogus ARP requests and responses, or some other packets, impersonating a vast number of separate network devices, just to fill up the switch’s CAM. Once the CAM is full, the attack has effectively degraded the network security by disabling smart frame routing on the switch and forcing it to fall back to broadcasting all data. This, in turn, allows the attacker to snoop on all communications, as if the network was not switched at all. The attacker can do all this without impersonating the recipient or visibly affecting the operations of the network, so the victim might well remain completely unaware of this problem. This is a design issue; it is not a flaw in the intended purpose of these devices, but a serious misconception in the popular understanding of how switches work. And, rest assured, it is nearly impossible to fully address this problem in a typical environment. Some switches do implement port and time limits to prevent such attacks, but these are never 100 percent effective.

Other problems are usually easier to prevent and remain more evident (can be often detected by the victim), but still illustrate Ethernet-level security issues. For example, an attack on the aforementioned DTP mechanism is one interesting possibility. DTP autonegotiation is often enabled for all ports on a device in order to provide easier setup. The problem is that a clever attacker can hence pretend to be a trunk-enabled switch, rather than a mere end-user workstation or a humble server; once recognized by the switch it is connected to as a friendly device, he would start receiving 802.1Q tagged frames, including traffic in other virtual LANs served by the switch it is connected to, being able to intercept or inject malicious traffic to networks with which he is not supposed to be able to communicate. In many networks where the same switch handles both protected, “demilitarized” networks and common corporate LAN infrastructure, such an attack may be yield very useful data by enabling members of one of the networks to snoop on or interact with the other.

You can resolve this DTP problem on some devices by changing the default configuration and clearly defining a set of dedicated trunk-enabled ports on the switch. However, the problem does not end here—our other friend, STP, can be abused in a similar manner, allowing an attacker to choose self as the “root” switch and receive a cut of the network traffic. Disabling STP discovery might be even more difficult in a typical corporate environment.

Still another problem arises when any trunk originates or terminates at a nondedicated VLAN. (That is, the port used for trunking is placed in a VLAN also used by workstations.) By injecting already tagged frames, it is possible to inject traffic to a trunk. This is arguably a configuration flaw, and the problem is often overlooked, since many engineers assume the method for implementing trunks is far more advanced and magical than it really is.