Securing the Control Plane
The control plane is where a Cisco switch or router learns about its environment, using various protocols to talk to neighboring devices. The protocols operating on the control plane of a router are different from those of a switch. Therefore, the types of attacks and the intended results are also different, but they can be generalized into two broad sets:
Overwhelming the control plane: This is a DoS attack in which an attempt is made to overwhelm the CPU by sending a large number of control packets. When the CPU is busy handling this flood, it isn’t able to process normal traffic.
Corrupting control plane data: In this type of attack, malicious control plane protocol packets are used to inject rogue information to affect the actual flow of data. Typically, STP, VTP, and routing protocols are used in the control plane to create routing tables, forwarding tables, and other tables. An attacker managing to inject incorrect information in these tables can result in a DoS attack or, worse, the data can be redirected to a rogue device for a MITM attack.
There are two ways to protect the control plane. The first is to secure each protocol used on this plane, and the second is to police the traffic arriving at it. While the mechanisms used to secure various protocols differ, policing the traffic is done using a feature called Control Plane Policing (CoPP). The next section discusses CoPP, and the two sections after that discuss the security of the protocols most commonly used at this plane on switches and routers.
Control Plane Policing (CoPP)
The CoPP feature on a Cisco device does exactly what it sounds like: It polices the traffic coming to the control plane. For this purpose, the control plane is treated as a logical source and destination, with its own inbound and outbound interfaces. Only traffic that is destined for the control plane is policed as part of this feature. This is in addition to any policing, filtering, or any other processing done at the interface where the packet was received by the device.
Examples of packets that get routed to the control plane are routing protocol packets, STP and VTP packets, and packets destined to any of the IP addresses of the device, including those of management plane protocols.
CoPP is configured almost the same way as quality of service (QoS) on any interface, with the difference being that the service policy is applied to the control plane. A detailed discussion of QoS is beyond the scope of this book, but as a refresher, the Modular QoS CLI (MQC) is used to configure QoS, which can be divided into three steps:
Step 1. Defining the traffic: In the first step, the interesting traffic is defined in a class map. A common method of defining interesting traffic is to create an access list and reference it in a class map, as shown in Example 2-18. This example creates a class map for all BGP and SSH traffic.
Example 2-18 Defining a Class Map for QoS
R1(config)#access-list 100 permit tcp any any eq bgp R1(config)#access-list 100 permit tcp any any eq ssh R1(config)#class-map copp_class R1(config-cmap)#match access-group 100
Step 2. Defining a service policy: In this step, the actual QoS policy and associated actions are defined in a policy map. For CoPP, police is the only valid QoS option. Example 2-19 shows a policing policy applied to the CoPP class map created in the previous example. In this example, the QoS policy is configured to police all BGP and SSH traffic to 300 kbps and to drop any traffic that exceeds this rate.
Example 2-19 Defining a Service Policy
R1(config)#policy-map copp_policy R1(config-pmap)#class copp_class R1(config-pmap-c)#police 300000 conform-action transmit exceed-action drop
Step 3. Applying the service policy: The last step is to apply the service policy to the correct interface. Normally, the policy is applied to an interface, but in the case of CoPP, it is applied in the control plane configuration mode, as shown in Example 2-20.
Example 2-20 Applying CoPP Service Policy
R1(config)#control-plane R1(config-cp)#service-policy input copp_policy
Securing Layer 2 Control Plane Protocols
A Layer 2 network can be very complex and requires various protocols to run efficiently. Of these protocols, Spanning Tree Protocol (STP) and VLAN Trunking Protocol (VTP) are the most important. While an in-depth discussion of STP and VTP is beyond the scope of this book, this section examines the core functioning of the protocols, their inherent weaknesses, and how to secure them.
Securing Spanning Tree Protocol (STP)
While redundant links are a necessity for a Layer 2 network, they can cause broadcast frames to loop around the network. Since Ethernet frames do not have a time to live (TTL), the frames can loop forever and eventually bring down the network. STP was created to resolve this by allowing redundant links to be in a blocked state until they are needed.
To understand the inherent weakness in STP, it is important to know how it works. STP forms a tree-like topology with the root bridge at the base. The root bridge is elected based on data shared in bridge protocol data units (BPDUs). BPDU frames are sent to well-known multicast addresses and contain, among other information, the switch’s MAC address and a user-defined priority value. A combination of these values is called the bridge ID, and the switch with the lowest ID is elected the root bridge.
After a root bridge is elected, each switch in the domain finds the interface that leads to the best path toward the root bridge and designates it as the root port, while redundant links are placed in a blocked mode. All active interfaces on a switch will be in either forwarding mode or blocked mode at the end. This process is called convergence. Figure 2-2 shows a topology after normal STP convergence. In this figure, traffic from WS-1 to WS-2 will take the path from SW-A to the root bridge, SW-B, on the way to SW-D. Notice that the path between SW-A and SW-C is blocked because it is redundant to the path between SW-A and SW-B.
)
Figure 2-2 Network During Normal STP Operations
Changes to topology, addition of new switches, and other similar events can cause a new root bridge to be elected and the STP domain to go through convergence. The time it takes to finish the process is significant, and no traffic is forwarded during that time.
In addition to the forwarding disruption during convergence, STP has absolutely no security built into it. BPDUs are exchanged in plaintext, and there is no authentication mechanism. A switch trusts and uses whatever BPDU frames it receives. Given this information, it is easy to understand that STP can be exploited in multiple ways:
DoS attacks: By sending out crafted BPDUs, it is not difficult to assume a root bridge role in the STP domain, thereby causing a significant part of traffic to be switched to a rogue machine instead of the actual destinations. Even if the root bridge role is not assumed, sending out BPDUs with topology change notifications in short intervals can cause traffic disruption by forcing convergence repeatedly.
MITM attacks: In certain cases, a rogue device can advertise a low bridge ID and become the root bridge. This causes a significant part of traffic to be switched toward it, where it can be copied, modified, and forwarded to the actual destination. To illustrate this, Figure 2-3 shows what happens when a malicious user is able to form a trunk to SW-A and SW-C, in the previous example, and become the root bridge by advertising a lower bridge ID. Now the path between SW-A and SW-B is also blocked. All traffic between WS-1 and WS-2 will now flow through the malicious root bridge WS-R, where it can be intercepted and modified before being forwarded on.
Figure 2-3 Network After a MITM Attack with STP
)
STP itself does not have any security mechanism, but three methods can be used to mitigate the risk on Cisco switches:
Disabling Dynamic Trunking Protocol (DTP): Cisco switches use a proprietary protocol, DTP, to automatically negotiate trunking between two switches. It is enabled on all interfaces by default and can be easily exploited to create unauthorized trunk links. Trunk links are special because they can send traffic on multiple VLANs. Hence, DTP should be disabled on all interfaces, and trunking should be configured manually where required. To disable DTP use the switchport nonegotiate command on all interfaces. In addition, all interfaces where trunking is not required should be configured to be in the access mode with the command switchport mode access. Example 2-21 shows the configuration required on interfaces to disable DTP and manually configure it to be in the access mode.
Example 2-21 Disabling DTP and Trunking on an Interface
SW1(config)#interface Gi0/5 SW1(config-if)#switchport mode access SW1(config-if)#switchport nonegotiate
Enabling BPDU Guard: BPDUs are generated and consumed by network switches. They should never be accepted on interfaces that do not connect other switches. Unfortunately, by default, a switch consumes BPDUs received on any interface, including those that connect to end-user devices such as workstations and printers. This can be prevented with a security feature called BDPU Guard. Where enabled, it shuts down an interface if BPDUs are received on it. BPDU Guard can be configured globally or on a per-interface basis. When configured globally, it is only enabled on ports configured as PortFast edge (or simply PortFast on older switch codes). Example 2-22 shows how BDPU Guard is enabled globally while Example 2-23 shows how it is enabled on a per-interface basis.
Example 2-22 Enabling BPDU Guard Globally
SW1(config)#interface Gi0/5 SW1(config-if)#spanning-tree portfast edge SW1(config-if)#exit SW1(config)#spanning-tree portfast edge bpduguard default
Example 2-23 Enabling BPDU Guard on a Per-Interface Basis
SW1(config)#interface Gi0/5 SW1(config-if)#spanning-tree portfast edge SW1(config-if)#spanning-tree bpduguard enable
Enabling BPDU Filter: Whereas BPDU Guard is applied to incoming frames, BPDU Filter prevents BPDUs from being sent and received on an interface. This is useful in preventing users from gathering information about the network while also blocking unauthorized BPDUs. Much like BDPU Guard, this feature can be enabled globally on all PortFast-enabled interfaces or on a per-interface basis. Example 2-24 shows the global configuration, and Example 2-25 shows how BPDU Filter is enabled on a per-interface basis.
Example 2-24 Enabling BPDU Filter Globally
SW1(config)#interface Gi0/5 SW1(config-if)#spanning-tree portfast edge SW1(config-if)#exit SW1(config)#spanning-tree portfast edge bpdufilter default
Example 2-25 Enabling BPDU Filter on a Per-Interface Basis
SW1(config)#interface Gi0/5 SW1(config-if)#spanning-tree portfast edge SW1(config-if)#spanning-tree bpdufilter enable
Securing VLAN Trunking Protocol (VTP)
Using VLANs for segmentation of traffic is a common method for optimizing a network and security. For VLANs to work properly, they should be created consistently across the network. Incorrect VLAN configuration can result in undesired results, such as connectivity problems. VTP can be used to create and maintain a consistent VLAN database. When VTP is implemented, the switches participate as a server or a client. VLANs are created and modified on the VTP server, and replicated to VTP clients. All switches configured as VTP clients create and modify VLANs locally based on the received data. A VTP client does not allow manual local changes to the VLAN database.
Before looking at the security implications of VTP, it is important to understand some key definitions:
VTP domain: A VTP domain is a logical grouping of switches that share a VLAN database. The domain name in a VTP update should match the domain configured on the switch. The update will be dropped if the domain names do not match.
VTP server: A switch can operate in three VTP modes: server, client, and transparent. The server is the single source of truth, and all changes are made to it. Each change is replicated on the clients through an update sent by the server.
VTP client: Most switches participate as VTP clients. When they receive an update, they verify the domain name and make changes to the local VLAN database.
VTP transparent: A switch in the VTP transparent mode does not participate in a VTP domain but forwards all updates out its trunk interface. A switch in this mode maintains its own VLAN database and allows local manual changes.
Revision number: The VTP revision number allows you to maintain version information of the VLAN database. A client does not use an update unless it has a higher revision number than that of the current local database.
VTP version: VTP has three versions: 1, 2, and 3. While Versions 1 and 2 are fairly similar, Version 3 adds the ability to hide VTP passwords in configuration and to disable VTP on an interface, among other functions.
VTP password: An optional pre-shared key is used to generate an MD5 HMAC in the update packets. The HMAC is used to authenticate VTP updates from a server to prevent unauthorized updates.
When a client receives a VTP update, it matches the domain and revision number and updates the local VLAN database. Because VTP traffic is sent to a specific multicast address, it is not difficult to capture these packets and glean the correct domain and latest revision number. With this information, a malicious user can inject rogue VTP updates with the correct domain and higher revision numbers. A simple act of sending an update with most VLANs removed causes a DoS attack on the Layer 2 network.
Fortunately, VTP provides several methods to safeguard against unauthorized updates:
Using VTP passwords: While VTP passwords are optional, they should always be used. Without the pre-shared key, rogue updates do not have the correct HMAC, and the updates are dropped.
Disabling DTP: VTP updates are only sent to and received from trunk ports. As mentioned in the previous section, disabling DTP prevents a rogue device from establishing a trunk link. This prevents VTP updates from being received from unauthorized devices.
Selectively enabling VTP: VTP is enabled on all interfaces by default, and updates are sent out on and received from all trunk interfaces. VTP should be enabled only on the interfaces that connect toward the VTP server.
Example 2-26 shows the configuration required to secure VTP on a client.
Example 2-26 Securing VTP on a Client
SW1(config)#vtp mode client SW1(config)#vtp domain S3cur3MyVTP SW1(config)#vtp password Str0nGP@$$w0rD SW1(config)#interface range Gi0/2-48 SW1(config-if-range)#switchport mode access SW1(config-if-range)#switchport nonegotiate SW1(config-if-range)#no vtp
In this section, we have covered multiple methods of securing the Layer 2 control plane. To summarize the section, Example 2-27 shows what a secure Layer 2 access port configuration should start with. It is by no means complete, and we will continue to build on it in later sections and chapters.
Example 2-27 Secure Access Port Configuration
SW1(config)#interface Gi0/5 SW1(config-if)#switchport mode access SW1(config-if)#switchport nonegotiate SW1(config-if)#switchport access vlan 10 SW1(config-if)#spanning-tree portfast edge SW1(config-if)#spanning-tree bpdufilter enable SW1(config-if)#spanning-tree bpduguard enable SW1(config-if)#no vtp
Securing Layer 3 Control Plane Protocols
Earlier in this chapter, we discussed methods for general control plane security, including CoPP. Along with securing the control plane of the device, it is also important to secure the protocols used there. Layer 3 is where a router uses routing protocols such as BGP, EIGRP, and OSPF to learn about the network and create its routing table. If the routing protocol is compromised, the routing table can be changed to drop traffic for a DoS attack or route traffic toward a malicious endpoint for a MITM attack. The good news is that routing protocols have built-in mechanisms to secure routing protocols. This section looks at ways to secure some of the most commonly used routing protocols.
Securing Border Gateway Protocol (BGP)
BGP is the routing protocol of the Internet. A compromised BGP peering session can result in significant problems. The two major threats to BGP come from injection or manipulation of routes and CPU exhaustion attacks in the form of malicious BGP packets.
To protect against BGP peering hijacking and unauthorized route updates, you can use an MD5-based neighbor authentication mechanism with pre-shared keys. You enable authentication with the neighbor neighbor-address password password command in BGP configuration mode. Example 2-28 shows how BGP peering with authentication is enabled.
Example 2-28 Enabling Authentication with BGP Peering
R1(config)#router bgp 70000 R1(config)#neighbor 72.163.4.161 remote-as 70001 R1(config)#neighbor 72.163.4.161 password 1s1tS3cur3!
The second threat to BGP comes from CPU exhaustion attacks, which can be executed by sending large numbers of crafted packets. This is particularly concerning with external BGP (eBGP), where a router peers with another autonomous system (AS). With external peering, such as with your ISP, you are open to attacks from public networks such as the Internet. For example, an attacker could send large numbers of TCP SYN packets to a BGP router in hopes of overwhelming the BGP process. To prevent this, you can limit the acceptable hop count for a BGP packet by using the TTL Security feature. This is configured in the BGP configuration mode using the command neighbor neighbor-address ttl-security hops maximum-hop-count.
Example 2-29 shows how TTL security is configured for an eBGP peer. In this example, the hop count is set to 2. With this configuration, any eBGP packets with a TTL value lower than 253 will be discarded. (The number 253 is derived by deducting the configured hop count from 255, the maximum IP TTL value.)
Example 2-29 Configuring TTL Security with eBGP
R1(config)#router bgp 70000 R1(config)#neighbor 72.163.4.161 remote-as 70001 R1(config)#neighbor 72.163.4.161 password 1s1tS3cur3! R1(config)#neighbor 72.163.4.161 ttl-security hops 2
Securing RIPv2 and EIGRP
Routing Information Protocol Version 2 (RIPv2) and Enhanced Interior Gateway Routing Protocol (EIGRP) both support using an MD5 hash based on pre-shared keys for authentication; in addition, they have similar methods for configuration.
For both of these protocols, authentication is configured on a per-interface basis using keychains. A keychain is a repository of pre-shared keys configured on IOS. Example 2-30 shows how to create a keychain.
Example 2-30 Creating a Keychain in IOS
R1(config)#key chain myRoutingKey R1(config-keychain)#key 1 R1(config-keychain-key)#key-string MyS3cur3R0ut1ngK3y R1(config-keychain-key)#exit
A keychain can be used to configure authentication for RIPv2 on a per-interface basis, using the ip rip authentication command, as shown in Example 2-31. RIPv2 supports both plaintext and MD5-based authentication. The ip rip authentication mode md5 command is used to enable MD5-based authentication. Once it is configured, all RIPv2 updates out that interface contain the MD5 hash, and all updates received require the hash, too. Every interface that participates in RIPv2 needs this configured for authentication to be consistent across the network.
Example 2-31 Configuring Authentication for RIPv2
R1(config)#interface Gi1 R1(config-if)#ip rip authentication key-chain myRoutingKey R1(config-if)#ip rip authentication mode md5
Much as with RIPv2, authentication for EIGRP can be configured on a per-interface basis using the keychain, as shown in Example 2-32. The command needed to enable authentication for EIGRP is ip authentication key-chain eigrp AS-number keychain-name. The command to enable MD5-based authentication is ip authentication mode eigrp AS-number md5.
Example 2-32 Configuring Authentication for EIGRP
R1(config)#interface Gi1 R1(config-if)#ip authentication key-chain eigrp 10 myRoutingKey R1(config-if)#ip authentication mode eigrp 10 md5
Securing OSPF
Open Shortest Path First (OSPF) also supports plaintext or MD5-based authentication. The pre-shared key is configured on a per-interface basis, and authentication itself can be configured under OSPF configuration for the whole area or on the interface for a segment. The pre-shared key for MD5 authentication is configured using the ip ospf message-digest-key command, as shown in Example 2-33.
Example 2-33 Configuring OSPF A Pre-shared Key for MD5
R1(config)#Interface Gi1 R1(config-if)#ip ospf message-digest-key 1 md5 MyS3cur3R0ut1ngK3y
After the key is configured, authentication can be enabled on a per-interface basis, using the ip ospf authentication message-digest command, as shown in Example 2-34. The authentication can also be enabled for the whole OSPF area by using the area area-number authentication message-digest command in the OSPF configuration mode, as shown in Example 2-35.
Example 2-34 Configuring OSPF Authentication on the Interface
R1(config)#Interface Gi1 R1(config-if)#ip ospf message-digest-key 1 md5 MyS3cur3R0ut1ngK3y R1(config-if)#ip ospf authentication message-digest
Example 2-35 Configuring OSPF Authentication for the Area
R1(config)#router ospf 1 R1(config-router)#area 1 authentication message-digest
OSPFv3 or OSPF for IPv6 does not have an authentication mechanism of its own but uses IPsec to secure communication between OSPF peers. IPsec for OSPFv3 does not require crypto commands like normal IPsec on IOS. It uses a single command on the interface or under the OSPF configuration mode for the whole area. The command to enable OSPFv3 authentication on the interface is ipv6 ospf authentication ipsec spi spi-number {md5|sha1} key, as shown in Example 2-36.
In the previous command, spi-number is similar to a key ID in a chain but must match on both peers, while the key is written in hexadecimal.
Example 2-36 Enabling Authentication for OSPFv3 on an Interface
R1(config)#interface Gi1 R1(config-if)#ipv6 ospf authentication ipsec spi 300 md5 9b635903a7f9e11843aad6b20de9e2d2
The command to enable authentication for an OSPFv3 area is very similar, as shown in Example 2-37, but is applied in the OSPF configuration mode.
Example 2-37 Enabling Authentication for OSPFv3 on an Interface
R1(config)#ipv6 router ospf 1 R1(config-rtr)#area 1 authentication ipsec spi 500 md5 9b635903a7f9e11843aad6b20de9e2d2