VLAN Security Guidelines
by David M. Piscitello, President, Core Competence, Inc.
Virtual LAN (VLAN) technology is no longer new. Basic VLAN-capable switches are now affordable for many small to medium businesses. But as commonplace as VLANs seem to have become, organizations still struggle over whether VLANs are secure. How much of VLAN vulnerability is perception rather than reality? Under what circumstances are the most commonly mentioned VLAN vulnerabilities exploited? What measures can you take to eliminate them? This article addresses those questions.
Categories of VLAN Vulnerabilities
Do VLANs introduce security vulnerabilities to your network? They certainly used to. Some early VLAN products were poorly implemented. Intended as single-unit replacements for multiple, separate Layer 2 switches, early VLAN switches incorrectly or unexpectedly allowed Ethernet frames to cross from one Virtual LAN onto another, without passing through an intervening router process. This certainly could not happen if you had used separate switches: only traffic permitted to cross the LAN segment connecting the switches by routing or VLAN Trunking policy would travel from one switch to another. Several implementation flaws allowed this VLAN hopping behavior, which can be exploited to capture or redirect traffic to another VLAN or station.
Some VLAN switch implementations have been susceptible to a variety of Denial of Service attacks, including traffic flooding, MAC flooding and CAM table poisoning (CAM refers to the Content Addressable Memory used to list MAC addresses reachable through each switch port). These attacks could create a traffic overflow, and sometimes forced a switch to act like a shared hub.
VLAN switch configurations and deployments have been vulnerable to a number of spoofing and man-in-the-middle attacks. The most well known exploits include the following. (Links at the end of this article lead to detailed descriptions.)
- MAC address spoofing
- VLAN tag spoofing (where the attack computer falsely identifies itself as a member of a VLAN by spoofing the IEEE 802.1q tag )
- ARP cache poisoning
- Connection hijacking following a successful ARP attack (see HUNT)
Security systems, including firewalls, typically have secure forms of management access: SSL, proprietary encrypted tunnels, SSH. Many switches continue to use unsecured (e.g., plain text) protocols. This is largely because the network management systems commonly used to maintain network availability, connectivity, and performance only support these protocols. VLAN switches thus remain vulnerable through management interfaces, including SNMP, telnet, HTTP unprotected by SSL, and even rlogin protocols.
I hope my list of VLAN vulnerabilities hasn't frightened you away from using VLANs. The good news is that many of the early VLAN implementation problems have been corrected, and many of today's VLANs offer more security features than their predecessors. Some even provide secure management access. The result: VLANs can provide good security, if properly deployed and configured.
What else is in that box you call a VLAN switch?
VLAN is a Layer 2 (Data Link) function. You address hosts in VLANs the same way you configure hosts on a single physical LAN segment, i.e., with a common IP network and subnet mask. But passing traffic from a host in VLAN A to a host in VLAN B requires a router, which works at Layer 3 (Networking), or routing functionality in the VLAN switch. Why go through the trouble of incorporating multiple switch capability into a single piece of hardware, only to require router hardware to forward traffic across the many VLANs you create in the VLAN switch? Enter Layer 3 VLAN switches -- VLAN switches with a routing capability.
Integrating Ethernet frame forwarding (bridging) and IP routing is again not new, but the presence of a VLAN feature in a switch makes it much easier to overlook intended boundaries between VLANs (subnets). In fact, the root of the problem often lies in network diagramming. We tend to draw topologies based on equipment, not function. So when we draw a switch in a topology, we create opportunities for misinterpretation.
As if this complexity isn't enough to give administrators gray hairs, let's throw in access controls. Routing software incorporated into many early VLAN switches provided packet filtering. It was no great technology leap to extend this functionality to stateful packet inspection worthy of the label "firewall." The Watchguard Vclass is one example (among many such implementations) of a single device/appliance whose operation includes Layer 2 forwarding, Layer 3 routing, and security policies. (If you use a system that incorporates VLAN, Layer 3, and security policy in one box, it's always a good idea to choose one where the pedigree of the system is "security device," with VLAN and L3 added. That way, you know that security wasn't an afterthought -- and possibly incomplete.) Such multi-use devices are powerful, but hard to classify when you're diagramming topology.
Deployment and Configuration
If you've followed my reasoning, you can understand why I believe that poor network design and mis-configuration account for more intrusions than VLAN implementation flaws. To solve mis-configuration issues, here are some best practices to consider when using VLAN switches.
- When you introduce VLAN switching to your network topology, clearly identify the roles your switch will play. Is it switching frames or routing IP traffic? Are you applying security measures (MAC access controls, IP packet filtering policy) using switch software features? Document how these services are intended to interact. I find that a network diagram that uses separate switch icons for each VLAN, routing and firewall "function," all encompassed by a rectangle labeled "VLAN switch," allows me to illustrate how my topology would look if I had used separate switches, routers and firewalls instead of a single hardware device.
- Understand how your switch implements dynamic trunk (virtual trunk) and spanning tree protocols; in particular, learn whether these are by default "enabled." If yes, then you may want to disable this feature on all ports before configuring further. This may prevent you from overlooking an implied relationship between switch ports that would undermine your intended policy.
- Use MAC level security features where possible. Many VLAN switches provide administrative means to disable switch ports, limit the number of MAC addresses that can connect to a port, and lock down a specific MAC address (or addresses).
- Isolate switch ports so that no traffic from other ports can be delivered to an isolated or Private VLAN port. This is a particularly useful feature if you intend to operate a publicly accessible VLAN (e.g., a DMZ with Web servers) off a VLAN switch alongside trusted VLANs. If your switch doesn't offer such a feature, apply this simple rule: do not configure external (untrusted) and trusted VLANs off the same switch, to eliminate the possibility that an attacker would circumvent firewall and other security systems by exploiting VLAN implementation or configuration.
- Consider VLAN switches that provide IEEE 802.1x authentication. 802.1x is not exclusively for wireless networks. 802.1X can be used to deliver VLAN tags based on authenticated identity. The VLAN tags are then used to segment traffic in your wired network. A practical example of 802.1x use in this fashion is to segment wireless guests from employees.
- Use a secure method for management access (SSL, SSH). If you must use SNMP, apply industry best practices when doing so, and even then, monitor SNMP traffic carefully.
- Know your VLAN switch. Some vendors have had independent third parties assess their VLAN implementations (e.g., @stake's security assessment of the Cisco Catalyst family). Others may provide test results on request. You may also choose to test your switch for cross-VLAN traffic leak. In fact, you can reproduce many of the @stake tests using flooding, spoofing, and hijacking tools available at SourceForge and SecurityFocus.
Bottom line: with diligence, you can enjoy the benefits of VLANs while maintaining solid network security.
Resources
Cisco's Virtual LAN Security Best Practices
HUNT, a TCP Hijacking Tool
Taranis: Invisible Traffic Redirection on Ethernet Switches
Lessons learned through Sandia's Cyber Assessment Program
Security Considerations at the Data Link Layer
Secure Use of VLANs: An @stake Security Assessment
Copyright© 2004, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.