Most network engineers have been told at one point or another never to use VLAN 1 for user access. The motivation behind this warning is the result of fear concerning VLAN hopping attacks, wherein an attacker can send packets with a specially-crafted 802.1Q header(s) to "hop" from one VLAN to another. This theory relies on the assumption that a switch will happily forward 802.1Q-tagged frames ingressing an access port.
We can devise a simple scenario to test this by injecting crafted packets toward an access switch port on VLAN 1 and monitoring the traffic traversing the upstream trunk. If the attack succeeds, we will see our crafted packets appear on the trunk side of the switch with the VLAN ID of our choosing.
Both switches used for the lab are Catalyst 3550s running IOS 12.2(44)SE2. FastEthernet0/11 on S1 has been configured as a static access port in VLAN 1, and FastEthernet0/13 has been configured to trunk all VLANs, with VLAN 1 as the (default) native VLAN:
interface FastEthernet0/11 switchport mode access switchport nonegotiate ! interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate
We can use Scapy to craft arbitrary frames with the necessary 802.1Q headers. The following command within Scapy generates an ICMP echo request (ping) with two 802.1Q headers (VLAN 1 and VLAN 10):
Welcome to Scapy (188.8.131.52 beta) >>> sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='00:01:02:03:04:05')/Dot1Q(vlan=1)/Dot1Q(vlan=10)/ IP(dst='255.255.255.255', src='192.168.0.1')/ICMP()) . Sent 1 packets.
Monitoring eth0 with Wireshark, we can verify that the frame was sent out with two 801.Q headers with the desired VLAN IDs.
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.
Still, an engineer might wish to enable the vlan dot1q tag native feature on platforms which support it. This forces the tagging of all traffic traversing 802.1Q trunk links, including that belonging to the native VLAN. Note that it is important that this feature be enabled on both ends of a trunk.
Finally, I feel inclined to include a footnote here regarding DTP, as it will no doubt come up in the comments if I do not. Switchports configured as
switchport mode dynamic are left vulnerable to the unintended formation of trunks when an attacker spoofs DTP negotiation with the switch. This is not VLAN hopping; rather, it is a simple (yet very dangerous) misconfiguration issue. Note that DTP is enabled on Cisco switch ports by default.