15 – Private VLAN

Introduction

One of the key factors to building a successful network security design is to identify and enforce a proper trust model. The proper trust model defines who needs to talk to whom and what kind of traffic needs to be exchanged; all other traffic should be denied. Once the proper trust model has been identified, then the security designer should decide how to enforce the model. As more critical resources are globally available and new forms of network attacks evolve, the network security infrastructure tends to become more sophisticated, and more products are available. Firewalls, routers, LAN switches, intrusion detection systems, AAA servers, and VPNs are some of the technologies and products that can help enforce the model. Of course, each one of these products and technologies plays a particular role within the overall security implementation, and it is essential for the designer to understand how these elements can be deployed.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

This document describes PVLAN configurations on switches running CatOS only. For side-by-side configuration examples of PVLANs on switches running Cisco IOS and CatOS, refer to the document Configuring Isolated Private VLANs on Catalyst Switches.

Not all switches and software versions support PVLANs. Refer to Private VLAN Catalyst Switch Support Matrix to determine whether your platform and software version supports PVLANs.

Components Used

This document is not restricted to specific software and hardware versions.

Background Information

Identifying and enforcing a proper trust model seems to be a very basic task, but after several years of supporting security implementations, our experience indicates that security incidents are often related to poor security designs. Usually these poor designs are a direct consequence of not enforcing a proper trust model, sometimes because what is just necessary is not understood, other times just because the technologies involved are not fully understood or are misused.

This document explains in detail how two features available in our Catalyst switches, Private VLANs (PVLANs) and VLAN Access Control Lists (VACLs), can help ensure an adequate trust model in both enterprise as well as service provider environments.

Importance of Enforcing a Proper Trust Model

An immediate consequence of not enforcing an adequate trust model is that the overall security implementation becomes less immune to malicious activities. Demilitarized Zones (DMZs) are commonly implemented without enforcing the right policies, thus facilitating the activity of a potential intruder. This section analyzes how DMZs are often implemented and the consequences of a poor design. We will later explain how to mitigate, or in the best case avoid, these consequences.

Usually, DMZ servers are only supposed to process incoming requests from the Internet, and eventually initiate connections to some back-end servers located at an inside or other DMZ segment, such as a database server. At the same time, DMZ servers are not supposed to talk to each other or initiate any connections to the outside world. This clearly defines the necessary traffic flows in a simple trust model; however, we often see this kind of model not adequately enforced.

Designers usually tend to implement DMZs using a common segment for all servers without any control over the traffic between them. For example, all servers are located in a common VLAN. Since nothing is controlling the traffic within the same VLAN, if one of the servers is compromised, then the same server can be exploited to source an attack to any of the servers and hosts in the same segment. This clearly facilitates the activity of a potential intruder conducting a port redirection or Application Layer attack.

Typically, firewalls and packet filters are only used to control incoming connections, but nothing is usually done to restrict connections originated from the DMZ. Some time ago there was a well-known vulnerability in a cgi-bin script that allowed an intruder to begin an X-term session by just sending an HTTP stream; this is traffic that should be allowed by the firewall. If the intruder was lucky enough, he or she could use another treat to get a root prompt, typically some kind of buffer overflow attack. Most of the times these kinds of problems can be avoided by enforcing a proper trust model. First, servers are not supposed to talk to each other, and second no connections should be originated from these servers to the outside world.

The same comments apply to many other scenarios, going from any regular un-trusted segment up to server farms at application service providers.

PVLANs and VACLs on Catalyst switches can help ensure a proper trust model. PVLANs will help by restricting the traffic between hosts in a common segment, while VACLs will contribute by providing further control over any traffic flow originated or destined to a particular segment. These features are discussed in the following sections.

Private VLANs

PVLANs are available on the Catalyst 6000 running CatOS 5.4 or later, on the Catalyst 4000, 2980G, 2980G-A, 2948G, and 4912G running CatOS 6.2 or later.

From our perspective, PVLANs are a tool that allows segregating traffic at Layer 2 (L2) turning a broadcast segment into a non-broadcast multi-access-like segment. Traffic that comes to a switch from a promiscuous port (that is, a port that is capable of forwarding both primary and secondary VLANs) is able to go out on all the ports that belong to the same primary VLAN. Traffic that comes to a switch from a port mapped to a secondary VLAN (it can be either an isolated, a community, or a two-way community VLAN) can be forwarded to a promiscuous port or a port belonging to the same community VLAN. Multiple ports mapped to the same isolated VLAN cannot exchange any traffic.

The following image shows the concept.

Figure 1: Private VLANs