VLAN-Based Separation

VLANs were created with the primary purpose of allowing network administrators to define broadcast domains flexibly across multiple switches. VLANs are a useful isolation tool, especially for the purpose of improving the network's performance. Using VLANs to implement security zones carries additional security risks that we will examine in this section.

From a performance perspective, it makes sense to place devices that frequently communicate with each other into the same broadcast domain, especially if the systems rely on broadcast-rich protocols such as NetBIOS or IPX's SAP advertisements. Often, systems that are physically separated from each other should logically belong to the same subnet; for example, your Accounting users might be sitting on different floors but accessing the same file and print servers. VLANs allow you to logically group devices into broadcast domains without tying the domain's boundaries to a particular switch, or in some cases to a single geographic location. Properly configured VLANs can also help you group resources according to their risk exposure and function, even if the systems in question are located on different floors of the building and cannot be interconnected using a single switch.

In server farm deployments, where servers tend to be in close proximity to each other, VLANs are increasingly used to define multiple virtual switches within a single high-end switch. A VLAN-enabled switch can host multiple VLANs, each representing a specific broadcast domain. Using VLANs to structure subnets is often enticing because it frees administrators from deploying dedicated switches for each subnet and allows them to add ports to VLANs by simply reconfiguring the master switch without purchasing additional hardware. Using only one physical switch to represent multiple subnets also minimizes the number of devices that need to be maintained and monitored. Also, hundreds of networks can get the benefit of hardware redundancy with as little as two switches. The flexible nature in which VLANs can be configured, as well as the slew of intra- and inter-VLAN communication options available in high-end VLAN implementations, makes VLANs an attractive tool for network administrators.

Unfortunately, virtual network divisions do not afford the comfort level that a physically disparate box does. Improperly configured VLANs can result in a vulnerability that would allow a savvy attacker to "jump" across VLAN boundaries. In the next few pages, we discuss the risks associated with VLAN deployments. Along with the potential dangers, we examine security-enhancing features of VLANs that could allow you to control how traffic travels within a single VLAN.

VLAN Boundaries

Even though subnets that are defined by VLANs might be considered virtual, they still require a router to forward network traffic from one VLAN to another. Intra-VLAN routing can be performed using a traditional router and can be controlled via ACLs, much like traffic that is crossing regular subnets. Vendors of high-end switches, notably Cisco, also offer hardware modules for their VLAN-enabled switches that can perform inter-VLAN routing at high speeds within the switch. For example, Cisco's high-end Catalyst switches support multilayer switching (MLS) through the use of add-on cards, which function like virtual routers within the switch and can route traffic across VLANs. MLS supports access lists that we can use to control how network traffic crosses VLAN boundaries.


The ability to perform routing within a switch is sometimes called Layer 3 switching. Cisco implements this using MLS-enabled cards such as the Multilayer Switch Feature Card (MSFC) for Catalyst 6500 switches.7 Practically, Layer 3 switching is different from traditional routing only in implementation; instructions to perform Layer 3 switching are hardwired into the dedicated module that is part of the switch, whereas traditional routing is implemented in software that runs using the router's CPU. Because Layer 3 switching is hardware assisted, it tends to be faster than traditional routing.

Because VLANs are meant to create isolated broadcast domains, we could use VLANs within a single switch to implement the security zone subnets shown in the network designs presented throughout this chapter. As with physical LANs, we would rely on routers (or their MLS equivalents) and firewalls to transport packets across subnet boundaries in a controlled manner. For this implementation to work, we would need to ensure that the switch that hosts the VLANs does not allow an attacker to "jump" across misconfigured VLANs and avoid the router or firewall.

Jumping Across VLANs

According to the IEEE 802.1q standard, Ethernet frames traversing through VLAN-enabled switches can be identified as belonging to a particular VLAN through the use of a tag header inserted into the frame immediately following the source MAC address field.8 Frame tagging is used when multiple switches are "trunked" together to function as a single switch that can host multiple VLANs. Tag headers defined in the 802.1q standard carry identifying VLAN information across trunked switches and identify a frame as belonging to a particular VLAN.


Switch trunking requires the configuration of trunking ports used when wiring participating switches together.

If the switch is not configured correctly, it might be possible to craft custom 802.1q frames that the switch will direct to the desired VLAN, thus avoiding the Layer 3 routing mechanism generally required for intra-VLAN communications. Specifically, Cisco Catalyst 2900 switches were found vulnerable to such attack when multiple VLAN switches were trunked together.9 For this attack to work, the attacker needs to have access to the VLAN that contains an active trunking port (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-1129). By connecting to a VLAN that contains a trunking port, the attacker could craft Ethernet frames destined for arbitrary VLANs on the other switch.


To decrease the risk of VLAN-hopping attacks in trunked environments, place trunking ports onto dedicated VLANs.

The vulnerability described in the previous paragraph has been carefully researched, and it resulted in a specific recommendation for mitigating the risk associated with trunking configuration options. If correctly configured using best practices, VLANs cannot be jumped. Independent security assessments by the highly respected security consulting firm @Stake "clearly demonstrate that VLANs on Cisco Catalyst switches, when configured according to best-practice guidelines, can be effectively deployed as security mechanisms."10

It is easy to understand why administrators would want to use VLANs to represent security zone subnets, especially in enterprise environments that have already deployed high-end switches and only require a configuration change to create a new "virtual" subnet. When deciding whether to use VLANs, consider the likelihood and the implications of a compromise to the VLAN boundary on Layer 1 or 2. For high-security environments, you may want to consider employing dedicated switches to represent each security zone. By not relying on VLANs, you physically ensure security. Though physical security can be compromised with something as simple as an improperly run network cable bridging dedicated switch security zones, with dedicated switches you do not have to worry about the configuration intricacies of trunking, or risk other misconfigurations that might result in the switch ignoring VLAN boundary restrictions.


You might be able to justify using VLAN-enabled switches to segment the internal network, where the convenience of VLANs outweighs the risk of deploying them in a relatively low-threat environment. You might then consider using dedicated switches for high-threat segments, such as the DMZ or the screened subnet.

It is a good rule of thumb to have sets of switches dedicated to a particular security zone (such as an internal zone, screened subnet, or DMZ) and then to use VLANs to segment networks that fall within that security zone. All networks on those switches should share a similar risk level. It is not recommended that you have security zones with disparate levels of risk (such as a DMZ and a Internal High-Security zone) sharing a physical switch. No matter how secure anything is today, there are always new vulnerabilities about to be discovered. However, a properly configured VLAN affords a good security boundary for segments with a similar risk level.

Firewalls and VLANs

As mentioned earlier in this chapter, VLANs need to be connected, like physical network segments, with a routing device. Security between VLANs can be quite a task. Typically the only security devices available for a router are access control lists. Though they are effective, managing access lists can be considerably more complicated and cumbersome than the interface of a commercial firewall solution. Also, logging and stateful handling of protocols may be missing or not as feature rich as a firewall solution. Recently, firewall vendors have started to offer solutions that take advantage of VLAN and trunking technologies. Both Cisco and Check Point currently have firewall solutions that allow the securing of communication between VLANs on the same switch.

Cisco's FWSM (mentioned in Chapter 3, "Stateful Firewalls") is a blade installed into 6500 series Catalyst switches. The Firewall Services Module (FWSM) uses the VLAN interfaces on the switch as its firewall interfaces. This way, policies can be created protecting hundreds of VLANS from each other with the full granularity of a PIX firewall.

Check Point has a solution called the Virtual System Extension (VSX). The VSX is a powerful Check Point FireWall-1 server with extras. A switch can be plugged in to it via a trunk, allowing multiple VLANs per trunk to appear as virtual interfaces on the firewall. The VSX can support as many trunks as it has available interfaces, so it can scale to handle the requirements of the most demanding environments. Up to 250 virtual firewalls can be created for the interfaces in question, allowing separate security policies (if required due to complexity or for management considerations) for the attached VLAN interfaces. Keep in mind that configuring the VSX as your VLAN's gateway means that it will be doing the routing for all VLANs so configured.

No matter what your need, advanced firewall technologies can be successfully employed to facilitate strong security between same-switch VLANs, making communications between your VLANs as secure as any physical LAN environment.

Private VLANs

The appeal of modern high-end switches makes it increasingly difficult to resist using VLANs to define subnet boundaries. VLAN implementations are becoming more robust, and network engineers are becoming more familiar with the configuration and maintenance of VLANs. Some Cisco switches support an attractive VLAN security feature called private VLANs (or PVLANs), which you should weigh against the risks associated with VLAN deployments. A private VLAN is a grouping of ports specially configured to be isolated from other ports on the same VLAN.

Private VLANs can help you restrict how hosts communicate with each other within the primary VLAN. As we discussed earlier in this chapter, firewalls and routers allow you to control network traffic only when it crosses subnet boundaries. Private VLANs are helpful for isolating systems within the subnet, without the lost addresses due to splitting the address range into multiple subnets. The ability to enforce such restrictions is most relevant in server farm deployments, where servers are frequently placed on the same subnet but rarely require unrestrained access to each other. If you are able to justify the use of VLANs in your environment, private VLANs will improve your design by adding another layer of security to the network's defenses.

When configuring ports that belong to a private VLAN, you can specify whether the device connected to a particular port can communicate with other ports of the private VLAN. Promiscuous ports have the ability to communicate with all other ports and are typically assigned to the gateway for the VLAN in question, such as a router or firewall. Isolated ports are completely shielded from all other ports of the private VLAN, except promiscuous ports. Community ports can communicate among themselves and with the promiscuous ports.11

Despite features that enhance Layer 2 security, private VLANs can be subverted if they are not properly secured. Private VLAN restrictions can be bypassed by passing intra-VLAN traffic up to the gateway router connected to the VLAN and back down to the target host. Normally, hosts located on the same VLAN communicate with each other directly because they are on the same subnet. An attacker with access to one host on the private VLAN could purposefully route packets to a neighboring system through the gateway. All he would have to do is send the traffic (via a static host route) to the gateway of the VLAN. Because the gateway needs to be a promiscuous port, it will also be able to communicate with the target host. When the router receives the packet, it will realize that it needs to go back to the target host and forward the packet on, despite the Layer 2 isolation the private VLAN creates. To prevent this from happening, you can configure Layer 2 ACLs (or VACLs) on the primary VLAN to deny traffic with the source and destination of the same subnet.12 This will not affect normal traffic because standard behavior dictates that any traffic between hosts on a subnet should never be forwarded to that subnet's gateway. However, it prevents the routing of traffic between PVLANs on the same subnet.

As you can see, VLANs offer numerous features that allow network designers to separate network resources in a very flexible manner. At the same time, VLAN-based subnet boundaries are more likely to be compromised due to misconfiguration than if they were implemented using simpler, physically separate switches. At this point, we hesitate to recommend using VLANs for defining disparate high-risk security zones in the same physical switch, especially those that are in close proximity to the Internet. However, administrative advantages that VLAN-capable switches offer might justify using VLANs to segment internal network segments and those with similar risk levels or those that are in the same security zone, depending on the security requirements and VLAN expertise of your organization.

    Inside Network Perimeter Security
    Inside Network Perimeter Security (2nd Edition)
    ISBN: 0672327376
    EAN: 2147483647
    Year: 2005
    Pages: 230

    Similar book on Amazon

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net