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 my blog, 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 1. This example creates a class map for all BGP and SSH traffic.
Example 1 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 100Step 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 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 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 dropStep 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 3.
Example 3 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 article, 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 1 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 1 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.
Note The original STP was defined in the IEEE 802.1d standard and had a high convergence time. IEEE 802.1w was later introduced as Rapid STP, which has a much lower convergence 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 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 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 4 shows the configuration required on interfaces to disable DTP and manually configure it to be in the access mode.
Example 4 Disabling DTP and Trunking on an Interface
SW1(config)#interface Gi0/5
SW1(config-if)#switchport mode access
SW1(config-if)#switchport nonegotiateNote Disabling DTP on interfaces and statically configuring non-trunk interfaces as access ports are the most important security measures that you can take for your Layer 2 network. These measures alone mitigate risks associated with various protocols, such as LACP, VTP, and STP.
- 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 5 shows how BDPU Guard is enabled globally while Example 6 shows how it is enabled on a per-interface basis.
Example 5 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 defaultExample 6 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 enableNote In older switch codes, the edge keyword in PortFast commands is not used. Remove the edge keyword from the commands if you are practicing on older codes. Be sure of the proper command based on the IOS versions published in the CCIE blueprint.
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 7 shows the global configuration, and Example 8 shows how BPDU Filter is enabled on a per-interface basis.
Example 7 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 defaultExample 8 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 enableSecuring 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 8а shows the configuration required to secure VTP on a client.
Example 8а 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 vtpIn this section, we have covered multiple methods of securing the Layer 2 control plane. To summarize the section, Example 9 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 articles.
Example 9 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 vtpSecuring Layer 3 Control Plane Protocols
Earlier in this blog, 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 10 shows how BGP peering with authentication is enabled.
Example 10 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.
Note Cisco routers set a TTL of 1 for eBGP peers by default. The neighbor ebgp-multihop command was traditionally used to set a higher TTL value. The eBGP multihop feature expects the TTL to be 1 when the packet is received at the destination. This is fairly easy to spoof if the attacker knows how many hops exist to the target device. The TTL security feature is more secure because the TTL value is set to 255 by the source, and the receiving router checks the remaining value against the configured hop count. This truly limits the radius within which a valid BGP packet can originate. The eBGP multihop and TTL security features cannot be configured at the same time. If you have the eBGP multihop feature configured, you need to remove it before using the TTL security feature.
Example 11 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 11 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 2Securing 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 12 shows how to create a keychain.
Example 12 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)#exitA keychain can be used to configure authentication for RIPv2 on a per-interface basis, using the ip rip authentication command, as shown in Example 13. 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 13 Configuring Authentication for RIPv2
R1(config)#interface Gi1
R1(config-if)#ip rip authentication key-chain myRoutingKey
R1(config-if)#ip rip authentication mode md5Much as with RIPv2, authentication for EIGRP can be configured on a per-interface basis using the keychain, as shown in Example 14. 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 14 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 md5Note EIGRP for IPv6 can also be configured for authentication, using the same commands discussed previously, except with ipv6 replacing ip at the beginning.
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 15.
Example 15 Configuring OSPF A Pre-shared Key for MD5
R1(config)#Interface Gi1
R1(config-if)#ip ospf message-digest-key 1 md5 MyS3cur3R0ut1ngK3yAfter 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 16. 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 17.
Example 16 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-digestExample 17 Configuring OSPF Authentication for the Area
R1(config)#router ospf 1
R1(config-router)#area 1 authentication message-digestOSPFv3 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 18.
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 18 Enabling Authentication for OSPFv3 on an Interface
R1(config)#interface Gi1
R1(config-if)#ipv6 ospf authentication ipsec spi 300 md5 9b635903a7f9e11843aad6b20de9The command to enable authentication for an OSPFv3 area is very similar, as shown in Example 19, but is applied in the OSPF configuration mode.
Example 19 Enabling Authentication for OSPFv3 on an Interface
R1(config)#ipv6 router ospf 1
R1(config-rtr)#area 1 authentication ipsec spi 500 md5 9b635903a7f9e11843aad6b20de9e
