Source: http://rikfarrow.com/Network/net0103.html
VLAN INSECURITY
VLANS WERE CREATED TO ISOLATE LANS,
BUT NOT FOR THE PURPOSES OF SECURITY
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