Using Virtual LANs (VLANs) to Segment the Network

Coming off the heels of the previous chapter you might be thinking, VLANs must not be a good thing for security. Nothing could be further from the truth, however. Like many things, how something is used ultimately defines the value. If you are using VLANs to separate critical resources (such as internal resources) from highly insecure resources (such as the Internet or a DMZ), then VLANs are not a wise choice. When used to separate resources within a common security zone (for example, separating resources on the internal network), then VLANs can really excel at making your network more secure.

Trust Model Enforcement

A trust model simply defines who needs to talk to whom and what kind of traffic should be permitted. A flaw in many interior network designs is the fact that all systems can potentially communicate with each other. On the surface that sounds great, but when you look at it in more detail, there are a number of flaws in this design.

Most of the resources that a host needs to access are located on servers that are controlled and managed by IT. This creates a trust model that requires client systems to be able to communicate with the server systems. For example, if all of the servers are located in a server module, the trust model dictates that communication is required from the client systems to the server module, but not necessarily among client systems.

The first flaw then is that many interior network designs lack anything that prevents two clients from being able to communicate with each other directly, even though there is no valid business justification for such functionality. In addition, even in environments that subnet their server resources onto dedicated segments, traffic is still allowed to pass between subnets that do not contain resources that need to be accessed. For example, if you have a remote location in Austin and the enterprise campus in Houston, is there a need for the Austin users to be able to access the Houston client systems or just the Houston servers on the server subnet? These breaches in the trust model create an environment that is vulnerable to exploitation by things like worms that spread by infecting peer systems. VLANs can be used to effectively enforce a proper trust model in your network.

Using VLANs to Enforce Trust Model Among Subnets

Traditionally, VLANs can be used to enforce the trust model among subnets by requiring that all communications among subnets go through a layer 3 device, making that traffic susceptible to filtering and access control lists (ACLs). While you can achieve this same effect through the physical segmentation of your network, it is often a cost-prohibitive undertaking due to the requirements of so many different switches. In addition, through the use of VLANs, you can remove the physical limitation of requiring hosts that need to share a common subnet to maintain a physical proximity, giving you much greater flexibility in assigning hosts to a subnet.

The use of VLANs to enforce a trust model among subnets is very simple. At the layer 3 device, you implement an ACL that controls what traffic can pass to any given subnet. This allows you to be incredibly granular in determining the traffic that can enter and exit a subnet, for example, allowing a single host or range of hosts access while denying all other access. You can also implement restrictions based on source or destination port numbers , for example, preventing destination UDP port 1434 from entering any segments that do not contain SQL servers (an effective method of mitigating the SQL Slammer worm). For more information about how to implement ACLs, see Chapter 6.

As is always the case, all this additional security is not free. There is additional expense in providing the extra router ports needed to interconnect all the VLANs. Also, there will be expense in the form of administrative costs associated with properly configuring the VLANs.

Using Private VLANs (PVLANs) to Enforce Trust Model Among Hosts

A relatively new method of enforcing the trust model among hosts is through the use of PVLANs. As we saw in Chapter 6, PVLANs allow you to create a scenario by which hosts share the same subnet; however, they can communicate only with systems that are connected to promiscuous ports or are connected to common community ports. Figure 12-1 illustrates how this functions.

Figure 12-1: Private VLANs

In this example, the port that the router is connected to is a promiscuous port and a member of the primary VLAN. Hosts A and B are connected to the isolated VLAN (lightly shaded area). When hosts A and B communicate, the traffic goes on the isolated VLAN and is accepted only by hosts connected to promiscuous ports on the primary VLAN (for example, routers or servers). Host A and B cannot communicate with each other even though they are members of the same VLAN and are connected to the same subnet. Additionally, hosts A and B cannot communicate with hosts C and D, even though they are on the same subnet. Hosts C and D are connected to the community VLAN (darkly shaded area). They can communicate with all hosts on the primary VLAN and they can also communicate with each other since they share a common community VLAN with each other.

Effectively, the primary VLAN bundles one or more secondary VLANs, allowing promiscuous ports to communicate with hosts on any VLAN. Secondary community VLANs can communicate with promiscuous ports, as well as with other ports that share the same community VLAN. Isolated VLANs can communicate with any promiscuous ports but are prevented from communicating with any other ports, even if they share the same VLAN.

There is a limitation to the use of PVLANs, however, and that is the ability for a router to forward traffic back on the same interface that it was received on, effectively circumventing the purpose of implementing PVLANs. This can be mitigated, however, through the use of VLAN ACLs (VACLs) on the primary VLAN, configured to drop traffic originating from the same subnet and routed back to the same subnet.

Using VLANs to Isolate Systems

Another effective use of VLANs to segment your network is to isolate systems with administrative VLANs, particularly as an element of incident response. I like to refer to these VLANs as jail segments. When a system is suspect or believed to be compromised, it can be a tremendous undertaking to physically locate the system so that it can be patched or updated. However, if you have properly deployed NIDS throughout your environment, the odds are high that you know either the IP address or MAC address of the suspect system. You can use this address to rapidly locate the switch port that the system is located on, and then place that switch port in a VLAN that prevents it from being able to communicate anywhere else on your network. This buys you time in responding to an incident, enabling you to focus on preventing an expansion of an incident without needing to spend as much time worrying about whether compromised systems can infect the network. Once the system has been fixed by technical support, it can be quickly moved back onto an operational VLAN.