Switches are somewhat easier to harden than routers because switches do not perform as many functions or have as many features as routers do. Whereas with routers we focus on securing traffic flowing through the router and the routing protocols themselves , with switches we focus more on securing the connectivity to the network and the various layer 2 protocols that are run by the switches. In this section, we are going to look at the following topics:
Harden services and features
Virtual LANs (VLANs) are used extensively in many environments. The primary benefit of VLANs is the ability to logically group systems regardless of their physical proximity to each other. As much as VLANs can assist us in providing a scalable and function network, they also introduce some security issues that we need to be aware of and implement measures to protect against.
One of the simplest things you can do is to ensure that you do not use the default VLAN (VLAN 1) anywhere in your production environment. This will ensure that, in conjunction with the other hardening steps in this section, any and all connections to network resource must come from systems that have the proper VLAN configuration.
The most significant security issue related to VLANs is the tendency for a switch to allow traffic from one VLAN to hop to a different VLAN without being routed. This would potentially allow an attacker to gain access to resources by circumventing any routers or firewalls that have been put in place to control access to the target VLAN.
Unfortunately, there isn t very much software-wise we can do to prevent this because in many cases the exploit functions by leveraging a bug or design flaw in how the switch process packets. In those cases, we are really at the mercy of the vendor to fix the issue. You can mitigate this, however, by designing and implementing your VLANs wisely. The cardinal rule in VLANs is that you should never have a single switch housing VLANs from different security-level networks. For example, the DMZ housing your Internet servers should never reside on a switch that also contains internal network VLANs and connections. This is because the DMZ is a much, much less secure network segment by virtue of the fact that it is designed to provide services to Internet hosts .
One type of VLAN-hopping technique we can protect against is what is known as a double encapsulated VLAN hopping attack. This attack relies on the attacker being able to connect to a trunk port, which allows the hacker to appear to be a member of all VLANs because the hacker s system is connected as a trunk device.
The first way to mitigate this is to ensure that auto-trunking is disabled on all interfaces. In fact, you should disable trunking on all interfaces and then go back and enable trunking on the specific interfaces that require it. Although it is convenient to be able to just connect two switches together and have them automatically negotiate the trunk, this allows the attacker to do the same thing. You can disable auto-trunking on IOS-based switches by running the following command on all interfaces that should not be trunk ports:
switch02(config-if)#switchport mode access switch02(config-if)#switchport nonegotiate
For your CatOS-based switches, you can run the following command:
Console> (enable) set trunk 3/1-24 off
For ports that must be configured as trunk ports, you should make sure you assign a native VLAN to the trunk port and that the native VLAN is not the default VLAN and is not the VLAN that the client systems connect to. You can do this on your IOS-based switches by running the following command at each interface that you want to configure as a trunk port:
switch02(config-if)#switchport trunk native vlan 777
For your CatOS-based devices, you can run the following command, specifying the port number of the trunk port:
Console> (enable) set vlan 10 3/2
You can only configure PVLANs if the switch is operating in VTP transparent mode.
Although traditional VLANs are used to provide layer 3 segmentation on your network, private VLANs take it one step further by providing layer 2 segmentation while allowing hosts to share a common subnet. You can configure three types of private VLAN ports:
Promiscuous These ports can communicate with all ports in a private VLAN.
Isolated These ports can only communicate with promiscuous ports.
Community These ports can communicate among themselves and any promiscuous ports.
To create PVLANs, you will create one of three types of VLANs:
Primary VLAN This VLAN is used to carry traffic from promiscuous ports to any other ports, including isolated and community ports.
Isolated VLAN Also known as a secondary VLAN, this VLAN can only carry traffic from isolated ports to promiscuous ports.
Community VLAN Also known as a secondary VLAN, this VLAN can carry traffic between community ports and promiscuous ports. Community VLANs are commonly used when you want some devices on a subnet to be able to communicate with each other, but not with devices that are not members of the community VLAN.
The primary VLAN is configured for all ports that need to communicate with all hosts on the VLAN (for example, switch uplink port and ports that servers are connected to). Isolated VLANs are configured for all other ports (for example, ports that a workstation connects to). Figure 6-1 illustrates a scenario where you might want to use PVLANs.
In this situation, you have two servers that do not need to talk to each other for any reason (perhaps they are on a DMZ
Console> (enable) set vlan 11 pvlan primary Console> (enable) set vlan 12 pvlan isolated Console> (enable) set pvlan 11 12 3/9-10 Console> (enable) set pvlan mapping 11 12 3/15 Console> (enable) set pvlan mapping 11 12 3/14
Your lower-end IOS-based devices support PVLANs through the use of protected ports. With a protected port, the hosts connected cannot communicate with another protected port without going through a layer 3 device, but they can communicate with any other nonprotected ports, as normal. The following command will configure a protected port:
VLAN ACLs are implemented for the same reason you would implement any other ACLs. There is one significant advantage to VACLs over traditional ACLs, however. VACLs are configured at layer 2 on Catalyst 6000 series switches, which allows them to be applied without a router, although the switch needs a Policy Feature Card (PFC). This also allows the switch to process packets and enforce the VACL at wire speeds in hardware so that there is no performance impact on the traffic. It doesn t matter how large the VACL is, the forwarding rate remains unchanged.
Although VACLs can be deployed in a standalone fashion to manage traffic, they can also be deployed to support PVLANs. This would allow you to define a VACL on the secondary VLAN while leaving the traffic on the primary VLAN unfiltered , for example.
Configuring a VACL on your CatOS-based switches is a three step process. First, you must create the VACL and add the access control entries (ACEs). The following commands demonstrate a VACL:
Console> (enable) set security acl ip vlan10acl permit tcp any host 172.20.10.4 smtp Console> (enable) set security acl ip vlan10acl permit tcp any host 172.20.10.4 www
In this case, I have configured the VACL to permit SMTP and HTTP traffic from any host to 172.20.10.4. Because there is an implicit deny at the end of the VACL, all other traffic will be denied . The next step is to commit the VACL by running the following command:
Console> enable) commit security acl all
The last step is to map the VACL to a VLAN. This can be performed by running the following command:
Console> (enable) set security acl map vlan10acl 10
As with your routers, a number of services and features on your switches should be hardened . These include the following:
VLAN Trunking Protocol (VTP)
Spanning Tree Protocol (STP)
Dynamic ARP inspection
VLAN Trunking Protocol (VTP) allows the configuration of trunk links to be made at a central location and propagated to the rest of the switches in the VTP domain. One of the problems with VTP is that a malicious attacker could connect to the network posing as a VTP server and delete all the VLANs on the trunk ports throughout the network. There are two methods of handling this.
The first method is to configure VTP to operate in transparent mode. This allows VTP traffic to pass through a switch but prevents the switch from automatically updating the VLANs on the trunk ports. The obvious drawback, however, is that you will need to manually configure every trunk port in your environment anytime there is a VLAN change. You can configure your CatOS to operate in transparent mode by running the following command:
Console> (enable) set vtp mode transparent
For your IOS-based devices the command is
switch02(config)#vtp mode transparent
Another option to implement is a password for the VTP domain. This ensures that any systems that connect must know the VTP password in order to exchange information. You can configure the VTP password on you CatOS-based devices by running the following commands:
Console> (enable) set vtp domain mainoffice Console> (enable) set vtp passwd <password>
For your IOS-based devices, the commands are
switch02(config)#vtp domain mainoffice switch02(config)#vtp password <password>
The final VTP security issue is really more of a misconfiguration issue. You should ensure that all new switches are configured either as clients or in transparent mode to ensure that they cannot update the VLAN information if they are not configured properly.
Although technically not a security issue, it is a good design recommendation to hard-code your port speeds and duplex. This allows you to scale your bandwidth accordingly , providing more bandwidth to users the further away from the access port the network segment is. You should configure your access ports as 100 Mbps half-duplex ports. All interconnection ports (that is, switch to switch or switch to router) should be configured at the maximum speed allowed and for full-duplex operation.
You can configure the port speed and duplex on your CatOS-based devices by running the following commands:
Console> (enable) set port duplex 3/1 full Console> (enable) set port speed 3/1 100
You can change the duplex syntax to half for half-duplex ports. In addition, like most other commands on the CatOS, you can specify a range of ports to configure with the single command. For your IOS-based devices, you will need to configure each interface individually by running the following commands:
switch02(config-if)#speed 1000 switch02(config-if)#duplex full
In this case, I have configured the interface to operate as gigabit full duplex.
As you saw with the VLAN-hopping attack, you should control which ports are trunk ports. Unfortunately, many switches default to allowing all ports to auto-trunk ”that is, ports will automatically negotiate to be trunk ports if the device connected is capable of being a trunk port. Because you should be planning each trunk port, there is no reason to allow ports to auto-trunk. You can disable auto-trunking as shown previously in the VLAN Hopping section of this chapter.
Spanning Tree Protocol (STP) is used to prevent layer 2 loops in the network. Although this is normally a good thing, attackers can force a root bridge to change, thus causing a DoS while the network converges on the new root. There are a couple of ways to prevent this from occurring. The first method is to simply disable STP. You can disable STP on your CatOS-based devices by running the following command:
Console> (enable) set spantree disable
For your IOS-based devices, you can disable STP by running the following command for each VLAN on which you want to disable STP:
switch02(config)#no spanning-tree vlan 10
In this example, I selected just VLAN 10. You can specify multiple VLANs by using a range, such as
The obvious problem with disabling STP is that if your network has loops, it could create the very problem you are trying to prevent. You can implement a couple features to protect the integrity of the STP root while still providing STP functionality on your network. These features are BPDU guard and root guard.
Implementing Root Guard
The root guard feature is used to configure ports to become designated ports so that no switch on the other end of the link can become a root switch. You can enable root guard on your CatOS-based devices by running the following command, specifying the ports on which you want to enable root guard:
Console> (enable) set spantree guard root 3/1
For your IOS-based devices, this can be done by running the following command on each interface on which you want to configure root guard:
switch02(config-if)#spanning-tree guard root
Implementing the BPDU Guard
The BPDU guard feature is used on ports that have been configured with portfast. portfast is typically implemented on access ports to allow a device to access the network without having to wait for the STP calculation to be performed. Unfortunately, portfast does not prevent hosts that connect from participating in STP, which can allow them to affect STP and the root placement. BPDU guard addresses this by disabling any port configured for portfast where a BPDU is detected . You can enable the BPDU guard feature by running the following command on your CatOS-based devices:
Console> (enable) set spantree portfast bpdu-guard 3/1 enable
For your IOS-based devices, you can enable BPDU guard by running the following command:
switch02(config-if)#spanning-tree bpduguard enable
Implementing BPDU Filtering
BPDU filtering prevents ports from sending or receiving BPDU packets. You have to be careful to ensure that you do not do this on trunk ports or any other port that may be looped. However, implementing BPDU filtering is an excellent prevention measure to ensure that a hacker cannot obtain a map of your network by processing the BPDU packets they receive. You can enable BPDU filtering on your CatOS-based switches by running the following command:
Console> (enable) set spantree portfast bpdu-filter 3/4 enable
For your IOS-based devices, you must configure the BPDU filter on each interface by running the following command:
switch02(config-if)#spanning-tree bpdufilter enable
Some devices are intentionally configured with blocking ports to provide redundancy to the STP root. For these switches, typically access switches, it is recommended that you enable UplinkFast. This allows the backup port to begin passing packets immediately in the event of a failure with the primary connection instead of needing to wait the extra 30 seconds of convergence delay. You should implement UplinkFast on all switches in your environment that have blocking ports.
You can implement UplinkFast on your CatOS-based switches by running the following command:
Console> (enable) set spantree uplinkfast enable
You can implement UplinkFast on your IOS-based switches by running the following command:
Like UplinkFast, BackboneFast is implemented to provide more rapid convergence times on STP networks. You should enable BackboneFast on all switches in your environment, unless your environment contains Catalyst 2900XL and Catalyst 3500 switches because they do not support BackboneFast.
You can enable BackboneFast on your CatOS-based switches by running the following command:
Console> (enable) set spantree backbonefast enable
For your IOS-based switches, the command is
Port security is one of the most fundamental security tasks that you can perform on your switches. Port security allows you to restrict the MAC addresses that can be associated with a switch. Port security should not be implemented on trunk ports because trunk ports potentially contain any number of MAC address associations; however, it is excellently suited for securing access ports.
You can configure port security to restrict MAC addresses in the following manners:
Restrict to learned MAC address This will configure the port to accept learned MAC addresses up to the limit of MAC addresses you have allowed.
Restrict to static MAC address This will configure the port to accept only packets with MAC addresses that you defined. Static port security should be implemented for all ports that connect to a router or to known servers that never move or change.
Restrict Using Learned MAC Address Implementing port security using learned MAC addresses requires less overhead than manually assigning MAC addresses; however, it is also less secure. You can configure port security for learned MAC addresses on your CatOS-based devices by running the following command:
Console> (enable) set port security 3/1 enable
This will configure interface 3/1 to accept the first learned MAC address. You can configure the port to accept more than one MAC address; for example, you can allow five MAC addresses by running the following command:
Console> (enable) set port security 3/1 maximum 5
For your IOS-based devices, you can configure port security by running the following commands for each interface on which you want to enable port security:
switch02(config-if)#switchport port-security switch02(config-if)#switchport port-security maximum 5
In both cases, if the port security is violated, the switch port will be shut down. Although this is the default behavior you can also configure the port to go into restrict mode. Restrict mode allows the port to continue to pass traffic, and only drops it from the offending MAC addresses. The following command will configure restrict mode on IOS based devices:
switch02(config-if)#switchport port-security violation restrict
Restrict to Static MAC Address In addition to dynamically learning MAC addresses, you can configure the port with statically assigned MAC addresses. Although this is probably an overly cumbersome task for every port in your environment, you should implement static MAC address port security for all ports that connect to static resources (for example, routers and critical servers).
Configuring static MAC addresses is very similar to configuring learned MAC addresses. For your CatOS-based devices, you can run the following commands to configure static MAC addresses:
Console> (enable) set port security 3/4 maximum 5 Console> (enable) set port security 3/4 enable 00-00-56-02-11-23 Console> (enable) set port security 3/4 enable 00-00-56-02-11-25
For your IOS-based devices, you can run the following commands to configure static MAC addresses:
switch02(config-if)#switchport port-security maximum 2 switch02(config-if)#switchport port-security mac-address 0000.5246.1234 switch02(config-if)#switchport port-security mac-address 0000.5246.1235
Dynamic ARP inspection (DAI) is a feature supported on certain Cisco switches, such as the Cisco Catalyst 4500 series of switches. DAI prevents MAC address spoofing and ARP cache poisoning by intercepting all ARP requests and comparing them against a known database that is obtained through DHCP snooping. Essentially, the switch will monitor DHCP broadcasts to see what MAC addresses and IP addresses are matched. Those addresses are added to the database of trusted MAC addresses. The following command will configure dynamic ARP inspection:
switch02(config)# ip arp inspection vlan 10
A more advanced form of port security is the use of 802.1x authentication for your switch ports. 802.1x port authentication is covered in more detail, including syntax examples, in Chapter 9.
If you connect multiple switches that support DAI together, you will need to configure trusted ports for the ports that connect the switches together. For example, if interface FastEthernet 1/3 is connected to another switch running DAI, you will configure FastEthernet 1/3 as well as the corresponding port on the other switch as trusted ports, as shown here:
switch02 (config)# interface fa1/3 switch02 (config-if)# ip arp inspection trust
If you do not do this, the switches will block ARP requests originating from the remote switch, thus preventing communications.
Traffic storms typically occur when excessive broadcast and multicast traffic is present and can result in severe network performance degradation and even a DoS in extreme cases. You can control traffic storms, however, by specifying the percentage of bandwidth a given traffic type is allowed to use. This is known as storm control or broadcast and multicast suppression. The percentage listed ranges from 100%, which means no storm control (the traffic can use all of the bandwidth), to 0%, which means that all traffic of that type will be blocked (the traffic can use none of the bandwidth).
You can configure broadcast/multicast suppression by running the following command on your CatOS-based devices:
Console> (enable) set port broadcast 3/10-15 50%
In this case, we are limiting broadcast/multicast to 50 percent of the bandwidth for ports 3/10 through 3/15. For your IOS-based devices, you can configure storm control on each interface by running the following commands:
switch02(config-if)#storm-control broadcast level 50 switch02(config-if)#storm-control multicast level 50
In this case, we are configuring both broadcast and multicast levels at 50 percent of the bandwidth.