Switch vendors have worked hard to overcome these problems and reverse the perception that switches are poor security barriers. For example, Cisco Systems hired the consulting firm @stake (now a division of Symantec) to test its switches and attempt to cause VLAN leakage. The widely publicized results concluded that the tested switches didn't leak packets, even when under intentional attack.
Similar results have been noted in our testing of Hewlett-Packard and Extreme Networks switches. Nevertheless, this improved reliability is only applicable to new switches. Not every VLAN-capable switch is going to behave the same way. For example, older but very popular Cisco 2924-series switches have been shown in our lab to be poor choices as security devices because of their propensity to leak packets across VLANs.
A New Target
The real VLAN threats aren't from layer 2 (data link) attacks (see "Common VLAN Attacks," above), but from attacks on the control plane of the network. In effect, when a VLAN-capable switch is used as a security barrier, it becomes the "weak link" in your security infrastructure. Why would an attacker assail a hardened firewall appliance configured with security as its primary goal when he could attack a VLAN switch?
Switches aren't designed the same way as firewalls, and are likely to have more vulnerabilities and less security testing. Thus, as a class, they tend to fall to a dedicated attacker faster and with less effort than a firewall. Switches provide hackers with multiple avenues of attack. A network might have one or two firewalls between two security zones, but there may be dozens of VLAN-capable switches. And, it only takes one misconfigured device to open a hole between secure and insecure parts of your network.
A network may have one or two firewalls between security zones. But, there may be dozens or even hundreds of VLAN-capable switches crossing floors and buildings in your organization.
There's also a philosophical difference in most network teams. While firewalls are obviously seen as security barriers and treated with appropriate gravity, switches are often considered less important. Network teams aren't accustomed to treating each switch as if it were the most important firewall in the entire network--which is exactly what switches can become when you use them in a VLAN environment.
Harden VLANs
Even if you're not using VLANs as security barriers, but merely as a means for simplified net- work management, you need to ensure you have proper deployment and architecture to prevent simple mistakes that can lead to compromises.
The following best practices can help you maximize the effectiveness of VLANs and avoid introducing security holes.
Separate the data plane from the control plane as much as possible. When building networks, it's common to assign IP addresses to switches on all VLANs and use those for management and control--but, this opens up the switch to attack.
A better strategy is to create a separate management LAN and use only that VLAN for management. Switches shouldn't have IP addresses on any other VLAN. (See "Plane Language," opposite.)
Use switch features to enforce restricted control plane access. Even if you create a separate management network, you will want to use other switch features to make sure the control plane is thoroughly isolated. For example, most switches allow for basic ACLs that can be used to limit the IP addresses available for management. It's essential to make sure that you to use these ACLs to only allow management traffic from specific management station IP addresses, even if you are sure that only those management stations can be routed to that VLAN. A common technique by attackers is to find a weak point in the network and use that to jump deeper. Since your switches themselves now become suspect, they shouldn't be considered trusted devices.
Limit and control traffic. Many switches have the ability to block broad types of traffic. If your goal, for example, is to enable IP connectivity, then you want to use an ACL to allow IP and ARP Ethernet protocols only, blocking all other types. This will help eliminate low-level Ethernet attacks, such as those that attempt to fool the spanning tree protocol.
Restrict cross-port traffic. When a group of systems is placed into a single security zone, the mere presence of connectivity offers the opportunity for attack. Several switch vendors offer the option to mark ports within a VLAN as "private," meaning that, although they can communicate off-switch, they can't communicate with each other.
It's highly unlikely that users on a wireless network will want to send packets to each other, so blocking traffic between wireless access points can increase security without impacting use of the WLAN.
Disable unused features and ports. Most switches are willing to talk to internal control protocols, such as spanning trees, on any port. If you use ACLs to block such traffic, you should disable these protocols on any port where they are not explicitly needed. At the same time, any port that isn't in use should be shut down or placed in an unused VLAN.
Document your physical layer. When secure and untrusted traffic coexist on the same switch, a security problem is simply a mispatched cable away. Extensive physical-layer documentation and standardization is critical to avoid errors that can compromise your security. For instance, you can use color-coded patch cables to indicate different VLANs, and color-code switch ports using plastic tape. While having good documentation won't prevent errors, even the most careless technician will think twice about plugging a green patch cable into a red switch port