VLANs: Virtually Insecure?
http://www.itarchitect.com/article/NMG20030305S0007
Although many networkers have come to think of switches with Virtual LAN
(VLAN) capabilities as security mechanisms, this mindset can result in
serious security problems. It's true that VLANs make it possible to isolate
traffic sharing the same switch or even groups of switches. But switch
designers had something other than security in mind when they added this form
of isolation to their products. VLANs work by filtering and limiting
broadcast traffic. Unfortunately, they rely on software and configuration to
do this, not the physical isolation that security advocates like to see.
In the last couple of years, some firewalls have become VLAN-aware, meaning
that policies can be created to match a packet to a particular VLAN based on
its tags. While VLAN-aware firewalls add a lot of flexibility to Web hosting
sites, these tags that firewalls rely on aren't designed with security in
mind. Devices other than switches can create VLAN tags, which can easily be
added to packets to fool the firewall.
How exactly do VLANs work? What, if any, security advantages do VLANs hold?
And if you do decide to use VLANs as part of your security architecture, how
can you minimize their weaknesses? In this column, we'll examine these and
other questions related to VLAN security.
PARTITIONS
The term "switch" denotes a device that switches network traffic between
interfaces called ports. But not too long ago, LAN switches were called
bridges. Even today, IEEE standards pertaining to switches inevitably use the
term "bridge."
Bridges are used to connect segments of the same LAN-that is, a local network
that doesn't require routing. The bridge software learns which ports connect
to which network devices by examining the source Media Access Control (MAC)
addresses in the packets that it receives. At first, the bridge distributes
all the packets to every port. But over time, the bridge learns to send
packets out the correct interface by building spanning trees, tables that map
MAC addresses to ports, via an algorithm developed for choosing the right
interface and avoiding loops. By sending packets out on a single port, the
bridge reduces network traffic. Think of a bridge as a highway that connects
different roads but only passes necessary traffic between those roads.
Although bridges reduce overall network traffic, making networks more
efficient, they still need to send broadcast packets to all ports. Just as in
any LAN, broadcasts mean just that: a message broadcast to all systems.
Address Resolution Protocol (ARP) packets are an example of broadcast
messages.
As bridge hardware grew more capable, with an increasing number of ports and
the addition of management software, a new feature appeared: You could
partition a bridge, splitting it into multiple, virtual bridges. When split
in this manner, broadcasts are limited to only those ports associated with
the virtual bridge and its VLAN, as opposed to going to every port.
Limiting broadcasts to a VLAN doesn't, in itself, seem 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 ARP broadcasts are used
to acquire the MAC address associated with a particular IP address; without
the MAC address, systems can't communicate with one another on the same
network. Routers and layer-3 switches support passing traffic between VLANs.
Overtime, some began to consider switches as security devices rather than
networking devices. Switches do make sniffing traffic destined for other
systems more difficult (but not impossible). And they also produce a
software-based isolation between VLANs, though that isolation is imperfect at
best.
A document from Cisco Systems's Web site (see Resources) describes two
scenarios in which packets can hop VLANs-that is, pass between two VLANs on
the same switch. In the first scenario, systems establish TCP/IP
communications on the same VLAN; then the switch is configured so that one of
the switch's ports now belongs to a different VLAN. Communications continue
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 is directed to
which port.
In the second scenario, someone wishing to hop VLANs manually enters a static
ARP entry for the desired system. This requires that the person learn the MAC
address of the target system, perhaps through physical access to that system.
The problems described in these scenarios can be alleviated by using switch
software that removes the information necessary for passing packets between
VLANs. In higher-end Cisco switches, separate spanning trees exist for each
VLAN. Other switches either have similar features or can be configured to
filter the bridging information available to members of each VLAN.
Given the relative dearth of information about the issue, hopping VLANs
within a single switch doesn't seem to pose a serious problem.
TRUNKING
Multiple switches can share the same VLANs through configuration and the
tagging of 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 are sent between switches, each packet is tagged based on
802.1Q, the IEEE standard for passing VLAN packets between bridges. The
receiving switch removes the tag and forwards the packet to the correct port
or, in the case of a broadcast packet, the correct VLAN.
These four-byte 802.1Q tags are added to Ethernet headers right after the
source address. 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 0 and 4095
are reserved values. The default value for the VID is 1; this is also the
default value for unassigned ports in a switch configured with VLANs.
According to Cisco's default configuration for its switches, trunking is
designated as "desirable," and a port can negotiate trunking if it discovers
that another switch is connected to that port. By default, a trunk port
belongs to VLAN 1, which is called its native VLAN. But administrators can
assign trunk ports to any VLAN, and putting them into a VLAN of their own is
a good idea.
In 1999, David Taylor posted information to BugTraq about tests he'd run
using Cisco switches in an attempt to force packets to hop VLANs (see
Resources). Taylor first used 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 they're 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 previously mentioned example from Cisco
documentation, the MAC address 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 1, and the target in VLAN 2.
--
╴╴╴╴╴╴╴╴╴ ▕◣ telnet://ucd.twbbs.org ▕◣
▕ 無情谷 ▏ ▌ █ ▌ ▌ █ ▌
▕ 無情谷 ▏ ▃▃▃▃ ▃▇▃ ▃▇▃ ▃▇▃ ▃▃▃▃
￣￣￣￣￣￣￣￣￣ =====> [作者: liwei 來至 UCD.TWBBS.ORG]
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.111.84.233