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