Bits & Bolts
Learn how to leverage the VLAN as a security tool.
The virtual LAN (VLAN) capabilities of all modern LAN switches allow savvy network managers to create and distribute VoIP, mobile wireless and management networks without expensive equipment and infrastructures. But, can VLANs be used as security tools, and is it a good idea to make the VLAN barrier part of your security infrastructure? The answer is yes--with reservations.
Although VLANs themselves may not introduce security exposures, they do present the opportunity for attackers to have unprecedented access to the control plane of the network.
When VLANs are used as security barriers, your security infrastructure's "weak link" moves from the firewall to the switch, and, because switches aren't generally configured with security in mind, opportunities for mischief abound.
For example, suppose you wanted to distribute a wireless guest network. You can place all wireless users outside a separate wireless firewall and, using VLANs, mark certain switch ports as being on the "outside VLAN." Plug wireless gear into that port, and, if you've wired it back to the firewall, it's now logically separated from the rest of your network.
Without VLANs, the most an attacker might do to exploit a misconfigured switch would be to cause a DoS attack by shutting off specific ports. VLANs give the attacker potential access to the switch fabric inside the firewall.
|Common VLAN Attacks|
DoS flood attacks
ARP spoofing attacks
Sealing Virtual Leaks
The most common fear in this environment is "VLAN hopping," where packets jump from the outside VLAN to other network segments. When packets leak, datagrams from one switch port appear on a port they shouldn't--either within the same or on a separate VLAN. While just getting packets to jump from one port to another doesn't necessarily offer unlimited access, it does open a hole in the network that gives the attacker the opportunity to wreak havoc. The goal of a VLAN attack is to control the switch's failure so that packets leak where the attacker directs them so he can exploit the weak spot.
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.
The terms "control plane" and "data plane" are commonly used in the world of networking, but may not be as familiar to infosecurity experts. Fundamentally, the signals that control the flows and behaviors of your network don't use the same path as the packets themselves. In all large networks, such as the public-switched telephone network, there is a distinction between the part of the network that moves the packets, or calls, and the part of the network that controls everything else. The data plane is where all the data is located, while the control plane is used to direct the oper-ation, management and maintenance of the network. In some networks, a further distinction is made between the control plane, used for routing and call control, and a management plane, used for network management.
In the world of enterprise IP networks, it's unusual to break routing and data into separate paths because of the way IP routing works. However, it's common to separate network management into a completely separate path, possibly even using different cabling and topology. Anyone who has attempted to diagnose and repair a network where the routing has broken down will appreciate the benefits of separating control and data planes.
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.
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
- How to Use ThreatConnect Playbooks to Manage Security APIs –ThreatConnect
- Smarter = Faster: Security Orchestration with Threat Intelligence –ThreatConnect
- More is Not More: Busting the Myth that More Threat Intel Feeds Lead to Better ... –ThreatConnect
- Private Cloud Computing Security Issues –SearchSecurity.com