How To Secure Your Flat Network

Flat networks are a hot topic: They can be faster and perform better than conventional tiered networks because they enable more direct communication among devices. They're also well-suited for highly virtualized environments and can facilitate virtualization-specific features, such as VM mobility.

However, a shift to flatter networks brings a familiar security conundrum: how to balance performance against risk. In particular, a flat network removes the Layer 3 network segmentation boundaries that we've long used to segment traffic and provide defense in depth.

Most networks today have been carved into myriad virtual LANs, with each VLAN representing a subnet. VLANs are created to break up broadcast domains, logically group devices, and provide a point for implementing access controls between subnets--all valuable tools for security teams. In our practice, we see various methodologies for determining exactly which devices belong in a given VLAN; maybe IT wants to separate devices by type, putting all servers into one or more VLANs. Or maybe the goal is to separate devices by physical location, such as floors or buildings.

Once devices have been assigned to a VLAN, they can then be tied back together with Layer 3 routing devices, firewalls, or other mechanisms to allow them to communicate with approved systems on other subnets.

Another benefit of separating devices into various subnets/VLANs is that it provides network administrators with context clues as to the nature of the systems residing on that network. For instance, the operations team might know that all the devices on a given VLAN are wireless corporate users. This information can help with troubleshooting, network optimization, and other common activities. Moreover, basic firewalls and access control lists (ACLs), two of the most common network filtering controls, usually operate on Layer 3 network parameters, such as IP addresses. Data flows originate from and are delivered to particular IP addresses or groups of addresses. Security policies and system requirements dictate filtering rules that manage which IP-to-IP flows should be permitted or denied.

By removing this intersubnet role and putting more devices on the same subnet, we lose a security tier.

However, as we'll discuss, IT can maintain robust network traffic segmentation using Layer 2 controls, both for physical networks and in virtualized environments that rely on virtual network interfaces. These controls include VLAN access control lists, private VLANs, and Layer 2 firewalling. We'll also discuss the use of port profiles and security zones that can be applied to virtual machines.

Strategy: Securing Flat Networks

Our full report on securing flat networks is free with registration.

This report has action-oriented analysis and real-world insight on security and networking. What you'll find:

Get This And All Our Reports

InformationWeek: Mar. 12, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)

Layer Vs. Layer

Moving to a flatter network architecture may gain you speed, but be aware that it involves a very different design strategy. (For more on flat network design, see "Inside Flat Networks") For example, VLANs won't go away or be fully removed from the multitiered hierarchy. But their use will be limited as more diverse devices operate in the same subnet. For example, in a Layer 3 model, you might put Web servers and database systems in two different subnets and run the network traffic between those subnets through a firewall. In a flat Layer 2 model, you might now put those hosts into a single subnet but implement controls so only approved traffic flows through each system.

The first control in our toolkit is the VLAN access control list. VACLs are intended to be used in much the same way as conventional Layer 3/Layer 4 ACLs, with the added benefit that they are also applied at Layer 2 on a physical switching/routing device. This means that a VACL can filter traffic bridged between devices on the same VLAN and need not apply only to routed traffic going into or out of a VLAN. IT can define VACLs to block specific traffic types (for instance, UDP and TCP) or ports, and they may be applied directionally to and from various hosts. VACLs can be tied to specific interfaces or be more generally applied to a whole VLAN, depending on your needs. That means we can enforce least-privilege concepts--for instance, allowing traffic from one Web server to talk with its requisite database system on specific ports while blocking traffic going to a second, unrelated server on the same subnet.

However, correct implementation of VACLs requires a solid understanding of your hosts' data flows and network communication requirements. If your VACLs are not locked down properly, you may have unwanted communication occurring among devices. Conversely, if your VACLs are too strict, devices may be prevented from communicating with approved systems.

Traffic Cops

On a flat network, private VLANs, again implemented at the physical switch/router, can be used to group a system into one of three category types, each with its own traffic control properties: promiscuous port, community port, and isolated port.

A promiscuous-port PVLAN designation, typically used for the gateway of a given subnet, has unfettered access to other interfaces on the PVLAN. A community-port PVLAN designation allows communication with other members of the community and promiscuous ports on the PVLAN, making this a good choice for a group of servers that need to talk on a given segment, such as a group of Web servers and a database server. The isolated-port PVLAN applies the tightest controls, limiting the device to talking only with promiscuous ports on the PVLAN.

In general, PVLANs provide broad segmentation of L2 traffic rather than granular control. Still, they are useful to support defense in depth and break up subnet broadcast domains, plus, they work in tandem with VACLs if more specific access profiles are needed.

Layer 2 firewalling provides similar functionality as VACLs, but you can wrap it up in a nice user interface. Advanced firewalls, like those from Palo Alto Networks, support the ability to actually switch between two or more interfaces on the same VLAN and inspect traffic traversing this path. The upside to this approach is that it leverages the abilities of an enterprise-class firewall and provides a clean way of integrating controls into a consistent firewall policy. The downside? It's expensive to implement due to port-density requirements and the cost of each physical interface.

True Layer 2 firewalling (not transparent mode firewalling), while fairly uncommon, can make sense implemented as a filter between communicating devices on the same subnet that reside on different physical switches.

Keep in mind that the addition of any Layer 2 control introduces another level of filtering and, potentially, breakage. If a host becomes inaccessible, you'll have to look at all the usual suspects--firewall, host adapter, application processes, network--in addition to determining if Layer 2 filtering might be causing a problem.

Hey, we said it could make the network faster. We didn't say it would make your life easier.

Consider the operational impact particularly when you apply controls such as VACLs and PVLANs. Insist on excellent management and audit capabilities to streamline configuration tasks and ease troubleshooting. Typically, this means using a management tool or element manager that can monitor filtering rules; provide centralized, actionable audit logs; and help enforce consistency throughout your implementation. These concepts of manageability and consistency are essential as we move away from physical appliances and transition into our next topic: virtual L2 controls.

Virtual Security

As mentioned earlier, flat network architectures are well-suited to private clouds or highly virtualized data centers, where VMs often migrate among servers. But you still need Layer 2 networking controls in these architectures, and that means working with virtual interfaces and switches.

Fortunately, when you understand VACLs, PVLANs, and L2 firewall control options in the physical realm, you can transfer that know-how, because the VM-centric versions of these controls will not be radically different.

Let's look at some tenets of granular L2 segmentation for virtual systems. Bywords are strong auditing, scalability, and visibility into how traffic is being controlled.

Strong, low-level segmentation is still required in a virtualized network, and in fact becomes more important as the quantity of virtualized devices occupying a given subnet expands and the complexity of the design increases.

A key concept in securing flat, heavily virtualized networks is port and security profiles, collections of settings that dictate how VMs assigned to a specific group function. Once you create and assign profiles, the configurations stick with a VM even as it migrates to different physical hardware or changes state.

These profiles can be applied dynamically, as VMs are spun up. For example, a profile might be created to lock down administrative GUI access to a particular management subnet. Or a profile might explicitly deny network access from a less trusted group of systems to a more sensitive set of VMs. Profiles simplify administrative tasks and help enforce a consistent policy baseline for similar systems.

Beyond profiles, administrators can create security zones for network segmentation. A security zone is simply a grouping of devices that share some common characteristics, such as operational role, relative security value, or access requirements. These grouping will provide simplicity and time savings later on. Application servers can be put in an app-zone, Web servers in a web-zone, and so on.

Flatter networks, particularly in virtualized environments, can reduce network complexity (fewer VLANs and simpler subnets) and improve performance. While breaking down network boundaries isn't the right answer in all cases, it's an intriguing option for virtualized architectures or where you have a need for speed. With the right tools we have the ability to provide filtering controls very close to the source of the network traffic, on the virtual NIC, which helps reduce resource waste and improve performance as bad traffic is dropped close to the source. By using the tools at our disposal for both physical and virtual deployments, IT can implement strong controls at Layer 2 and enjoy the benefits of going flat.

Richard Dreger is president of WaveGard, a consulting firm. Write to us at [email protected].