by Rik Farrow
Virtual LANs (VLANs) make it possible to isolate traffic that shares the same switch, and even groups of switches. The switch designers had something other than security in mind when they added this form of isolation. VLANs make it possible to share a switch among many LANs, by filtering and limiting broadcast traffic. But this form of isolation relies on software and configuration, not the physical isolation that security people like myself really like to see.
In the last couple of years, some firewalls have become VLAN aware, so that policies can be created that rely on the tags that identify a packet as belonging to a particular VLAN. While firewalls that are VLAN aware add a lot of flexibility useful to Web hosting sites, the tags that these firewalls rely on were not designed with security in mind. VLAN tags can be created by devices other than switches, and valid tags that will fool the firewall can easily be added to packets.
Let's take a look at VLANs, including how they work, why this has little to do with security, and failures of VLANs to maintain isolation. And, if you decide to use VLANs as part of your security architecture, what you should do to minimize the weaknesses involved.
The term "switch" today denotes a device that switches network traffic between interfaces, named ports. But not too long ago, switches were called bridges. Even today, if you read the IEEE standards used in switches, the term inevitably used is bridge. And if you are familiar with the way bridges work, you might want to skip ahead.
You use bridges to connect segments of the same LAN, that is,
a local network that does not require routing. The bridge
software learns which port that network devices have been
connected to by examining the source MAC (Medium Access
Control) addresses in the packets that the bridge passes.
At first, the bridge
knows nothing, and must distribute all the packets it
receives to every port. But over time, the bridge learns
how to send packets out the correct interface by building
spanning trees, an algorithm developed for choosing the
right interface and avoiding loops. By
sending packets out on a single port, the bridge reduces
overall network traffic. Think of the bridge in highway
terms, something that connects different roads, and only
passes necessary traffic between these roads.
Although the use of bridges does reduce overall network traffic, making networks more efficient, bridges still need to send broadcast packets to all ports. Just as in any LAN, broadcasts mean just that, a message broadcast to all systems. ARP (Address Resolution Protocol) packets provide an important example of broadcast messages.
As bridge hardware grew more capable, with increasing number of ports and the addition of management software, a new feature appeared. You could partition a bridge, split a single bridge into multiple, virtual bridges. When split this way, broadcasts, instead of going to all ports, get limited to only those ports associated with the virtual bridge, and its virtual LAN.
Limiting broadcasts to a VLAN does not seem by itself to prevent a system on one VLAN from hopping to another VLAN-- that is, contacting a system on the same bridge, but a different VLAN. But remember that broadcasts get used to acquire the MAC address that is associated with a particular IP address, using ARP, and without the MAC address, one system cannot communicate with another on the same network. Routers, or switches that support layer three, support passing traffic between VLANs.
Over time, people have begun to consider switches as security devices rather than networking devices. Switches do make sniffing traffic destined for other systems more difficult (but not impossible, as exploits exist for doing so). And switches do produce a software-based isolation between VLANs. But that isolation is imperfect at best.
In a document found on the Cisco web site (See Resources), two scenarios are described where packets can hop VLANs, that is, pass between two VLANs on the same switch. In the first example, systems have established TCP/IP communications on the same VLAN, then the switch gets configured so that one system's port now belongs to a different VLAN. Communications continues between the two systems because each has the MAC address of the other in its ARP cache, and the bridge knows which destination MAC address gets directed to which port. In the second example, someone wishing to hop VLANs manually enters a static ARP entry for the desired system. Doing so requires that the person somehow learns the MAC address of the target system, perhaps through physical access to the target system.
Each of these two examples can be blocked by using switch software that removes the information necessary for passing packets between VLANs. In higher end Cisco switches, separate spanning trees, the tables that map MAC addresses to ports, exist for each VLAN. Other switches either have similar features, or can use configuration to filter the bridging information available to members of each VLAN.
Given the relative dearth of information about hopping VLANs within a single switch, this issue does not appear to be a serious problem.
Multiple switches can share the same VLANs through configuration and tagging of the packets exchanged between switches. You can configure a switch so that a port acts as a trunk, an interface that can carry packets for any VLAN. When packets get sent between switches, each packet gets tagged, based on the IEEE standard for passing VLAN packets between bridges, 802.1Q. The receiving switch removes the tag and forwards the packet to the correct port or VLAN in the case of a broadcast packet.
802.1Q tags get added to Ethernet headers right after the source address and are four bytes long. The first two bytes contain 81 00, the 802.1Q Tag Protocol Type. The last two bytes contain a possible priority, a flag, and 12 bits for the VLAN Identifier (VID). VIDs can range from 0 to 4095, but both zero and 4095 are reserved values. The default value for the VID is one, and thus also the default value for unassigned ports in a switch configured with VLANs.
An administrator may configure a port to act as a trunk, although the default configuration for Cisco switches is that trunking is "desirable", and a port can negotiate trunking if it discovers that another switch is connected to that port. And, unless the administrator changes the configuration, a trunk port belongs to VLAN 1, which is called its native VLAN. Ports used for trunking can be assigned to any VLAN, and it turns out that putting trunk ports into a VLAN of their own is a good idea.
In 1999, David Taylor posted information to Bugtraq about tests he had run using Cisco switches, in attempts to force packets to hop VLANs. Taylor first attempted to use VLAN tagging to hop VLANs within a single switch, without success. The VLAN tags really have no purpose except for carrying VLAN information between switches, and get ignored if presented on non-trunk ports.
But when Taylor used two switches, he could force packets to hop VLANs under certain conditions. Just as in the early example from Cisco documentation, the MAC addresses of the target system had to be known in advance. The other key condition was that the initiating system, the "attacker", must belong to the same VLAN as the trunk used to connect the switches. In Taylor's first attempt, the attacker and the trunk were both in VLAN one, and the target in VLAN two.
Subsequent investigation by a Cisco employee (you can find this at http://online.securityfocus.com/archive/1/27062) pointed out that this behaviour was not only supported by the 802.1Q standard, but also worked on other, non-Cisco, switches as well.
You can easily prevent VLAN hopping by configuring trunk ports so that their native VLANs do not match the VID of any other VLANs that you have configured. Remember that by default, the native VLAN for a trunk will be VID one, the default for any VLAN. You can choose to set the native VLAN for trunks to be 1001, or any value that your switch supports and is not used for any other VLAN.
Now that I have discussed how switches share VLAN information, we can examine firewalls that support VLAN-related policy. Firewalls get packets from VLAN-supporting switches complete with 802.1Q tags in their headers. Although I have only mentioned Ethernet in examples, 802.1Q tagging also applies to other network media, such as ATM and FDDI. What the VLAN-aware firewall can do is extract the tags and use the information within the tags to make policy-based security decisions.
802.1Q tags do not provide authentication. Tags just provide a form of identification, added by switches, that a particular packet came from a particular VLAN. That a firewall would act on this information is no more ridiculous than acting on the source address of a packet, as IP source addresses are also an unauthenticated means of identification--and one that can be spoofed.
Spoofing IP source addresses has been done for many years, and spoofing VLAN tags can be done as well. The most recent Linux operating systems (kernels in the 2.4 vintage) include support for acting as VLAN switches, and can generate any VLAN tag that the local system administrator chooses. Other software exists for spoofing VLAN tags. Taylor used the Network Associates' Sniffer Pro v.2.0.01 to generate packets, and this can be done in software as well.
The key to safely using 802.1Q tags for policy decisions is to design a network where switch trunks get connected to the firewall interface where decisions will be made based on VLAN tags. If there are other routes to this firewall interface, the possibility that packets with spoofed VLAN tags increases. The switches themselves must be properly configured, with trunk ports specifically configured for trunking, and added to a non-default VID.
Implicit in any discussion of switches is protecting administrative access to the switches themselves. Switches and other network equipment typically expose three different means for administrative access: telnet, HTTP, and SNMP. You should always disable methods of administrative access that you don't use, as well as adding access control to the methods that you do use. While the firewall can control access to switches when the source of an attempt is external, the firewall can do nothing about an internal attacker--or one that has gained access to an internal system.
Switches were not designed as security devices. Their use as such simply evolved over time, and is ancillary to their main use as devices that improve network performance. If you use a switch for security reasons, you are relying on the correct configuration of the switch, including understanding not only the standards that the switch software is based upon, but also the correct implementation of those standards. The 802.1Q spec itself is 211 pages long, and is only one of a handful of standards that a compliant switch manufacturer must support.
Any time that you need to segregate networks for serious security purposes, I recommend that you not use a switch.
Cisco documentation explaining two ways that VLAN isolation may fail: http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v8x/eescg8x/aleakyv.htm
Bugtraq post in 1999 describes a trick for crossing VLANS: http://online.securityfocus.com/archive/1/26008
SANS document, similar to the original Bugtraq posting but with more details: http://www.sans.org/newlook/resources/IDFAQ/vlan.htm
IEEE standard on VLAN tagging (802.1Q): http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
Instructions for configuring VLAN tagging with Linux kernels: http://www.candelatech.com/~greear/vlan.html