Packet Life has a great reminder why we shouldn’t automatically accept “conventional wisdom” and “best practices” in our work, using the long-held conventional nugget that VLAN 1 and user traffic don’t mix because it leaves the network vulnerable to VLAN hopping attacks as a prime example.
Specifically, network engineers have been preaching for years that allowing user traffic on VLAN 1 could lead to a scenario where a malicious attacker could send traffic to (or capture traffic from) VLANs he wasn’t supposed to have access to. We all know the evils of malicious traffic captures including: stolen passwords, personal information, and compnay secrets. Using his trusty Catalyst 3550, Wireshark, and a few other simple tools, Stretch shreds that chestnut:
If the VLAN hopping attack theory is valid, we should observe our frame exiting S1′s FastEthernet0/13 onto the trunk with an 802.1Q tag specifying VLAN 10. However, by monitoring eth1, we can observe that this frame is not switched out onto the trunk. Rather, because S1 detected an 802.1Q-tagged frame ingress on an access port, the frame was discarded. (Interestingly, though, the receipt of such a frame does not increase any interface error counters.)
I’ve tried crafting the malicious frame in several ways, including swapping the order of the headers and sending only one header, but none of my attempts were successful in getting a tagged frame onto the trunk in any VLAN, even the native (untagged) VLAN. Only by transmitting the frame without any 802.1Q header was it successfully switched onto the trunk (untagged). These observations suggest that VLAN hopping attacks are not effective against modern switches (or at least the Catalyst 3550 running 12.2(44)SE2), in contrast to the findings of an @stake security assessment (PDF link) performed in 2002.
As has been pointed out subsequently by others, this vulnerability is still present in older versions of IOS, but a good workaround would be to force tagging of all traffic on trunks using the command:
If your SmartNet has lapsed, this is a possible workaround. But if you have an active contract for your gear and you use trunks with VLAN 1 untagged (which includes “user” traffic) you need to upgrade as soon as possible.