There seems to be a certain amount of FUD around about the security of VLANs for traffic-segregation. Some members of the information-security community will tell you that VLANs are not secure and cannot safely be used for traffic-segregation. When asked to elaborate they will respond with vague, hand-waving arguments along the lines that it is possible to get traffic to "hop" between VLANs as if no boundaries existed at all and they will tell you that they have seen this happen.
If this was true it would be a very serious matter indeed. Increasingly we live in a world dominated by Ethernet. It is almost universal on enterprise LANs and is fast becoming the medium of choice for carriers also and both camps make extensive use of 802.1q to segregate traffic. As adoption of Ethernet and 802.1q by carriers becomes more prevalant it would be very worrying if VLANs could easily be hopped.
So lets take a look. Based on a quick Google "poll", at least some of the fear seems to stem from the "802.1q and ISL Tagging Attack" section in this Cisco white paper. Sean Convery of Cisco gave this excellent presentation at the Black Hat USA 2002 conference which goes into much more detail. Both of these propose two mechanisms by which VLANs could potentially be hopped:-
Let's examine each of these in turn.
By default, when a switch port comes up a Cisco switch will use DTP to try to determine automatically whether the port should operate as a trunk port or as a plain old access port. Normally, end-hosts will not respond to DTP configuration packets and therefore the ports they are connected to will operate as regular access ports. If, however, an attacker has some way to inject DTP packets (such as Mausezahn or Yersinia, for example), he can (relatively) easily negotiate with the switch for his port to act as an 802.1q trunk. Having done so the attacker has full access to all VLANs (unless some VLANs are pruned off his interface but if the network admin doesn't have enough sense to disable DTP autonegotation it is unlikely he will think to prune VLANs either !): all he needs to do is apply appropriate 802.1q tags.
Let's see it in action. We start off with a very basic switch configuration:-
There's nothing there that will scare the children. There is a Linux box connected to that port. As you would expect, it is operating as an access port:-
Now I run Yersinia and tell it to use DTP to negotiate trunking on the port:-
On the switch I see the interface bounce. When I check the status of my trunks again, magically I have a new one:-
Sure enough, if I inject tagged packets into the newly-created trunk (I used Mausezahn for this), 30 seconds later (after Spanning Tree has gone through its "listening" and "learning" phases) the switch happily accepts them
This form of attack is pretty easy to defend against: all end-user ports should have DTP autonegotiation disabled. In my view all ports should have DTP autonegotiation disabled. If you want a port to be a trunk, explicitly set it to be a trunk. Really DTP shouldn't exist at all and it certainly shouldn't be enabled by default.
This form of attack is a little more subtle and is much less well described. The cynic in me will speculate about why this is a little later ;-). The idea is that if an attacker is connected to an access port which is in the 802.1q native VLAN (1, by default), that he can cause traffic to hop VLANs by injecting double-tagged packets. Consider this network configuration:
The theory is that the attacker can inject double-tagged packets. The switch will strip off only the first tag and will fail to "notice" the second tag. When the packet is transmitted to another switch over an 802.1q trunk, no VLAN tag is applied because the packet belongs to a VLAN which is the native VLAN for the trunk (because the access port on which the packet was received is a member of the native VLAN). The packet reaches the other switch which sees the remaining VLAN tag (i.e. the second tag which the attacker applied) and will forward the packet on the VLAN specified in that tag. Voila...the attacker has successfully caused a packet to hop into a different VLAN.
I did a little experimentation and it turns out that this attack does work. The trick is that the "outer" tag which the attacker applies must identify the packet as belonging to the attacker's VLAN (=the 802.1q native VLAN). In that case, the switch will accept the packet, even though it is arriving on an access port. The first tag is stripped off but the second tag is unaffected. When the packet is transmitted on the 802.1q trunk, no tag is applied because the packet belongs to the native VLAN. This means that when that packets reaches another switch the second tag applied by the attacker is still visible and this causes the second switch to place the packet in the wrong VLAN.
According to the Cisco white paper:-
This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases.
This is a poor attempt to cloud the true cause of this vulnerability and it is nonesense. The reason this attack succeeds is because the switch doesn't discard tagged packets received on an access port. If the switch simply discarded all 802.1q packets received on access ports then this problem wouldn't arise.
In fairness to Cisco, it looks like they are not alone. I happened to have a Dell PowerConnect switch sitting on a shelf which exhibits exactly the same behaviour.
So how do you defend against this weakness ? Cisco's recommendation is:-
As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packets.
The reference to "802.1q-all-tagged mode" is a little disingenuous because Cisco switches don't support such a mode (as far as I know). So the correct solution is to
With these simple precautions VLANs provide the same level of traffic-separation as MPLS, Frame Relay, or ATM. It is intuitively obvious that it should: all of these work by tagging packets with an identifier which defines their "membership". Whether that tag is an MPLS label, a Frame Relay DLCI, an ATM VPI/VCI or an 802.1q VLAN identifier is only a matter of sematics...all of them work in exactly the same way and it really doesn't make any sense to say that any of them are inherently more or less secure than any other. So there.
