Securing BGP on Cisco IOS

"The What?" - In this post I want to cover securing the BGP routing protocol on Cisco IOS.

"The Why?" - Securing BGP aides in deterring commonly known TCP threats. As a reminder BGP uses TCP port 179. Since BGP uses TCP it is vulnerable to any known TCP threats, specifically these major ones:

• DoS: a malicious attacker sends unnecessary traffic to saturate the device control plane resources in an attempt to deter the BGP service.

• Route Manipulation: an attacker modifies BGP route table, which affects legit traffic from reaching the legitimate destination.

• Route Hijacking: a rogue BGP neighbor advertises a victim's network to redirect some/all traffic to the rogue router.

"The How?" - There are several mechanisms that can be utilized in securing BGP on Cisco IOS. Some of the mechanisms include:

• BGP Neighbor Authentication

• Access Control Lists

• Control Plane Policing (CoPP)

• BGP Prefix Filtering

• Max BGP Prefix

• Time to Live Security Check

I will be using a recently used topology that specifically uses iBGP, the post/topology I am referring can be found here: Configuring & Verifying Dual Cloud & Dual Hub FlexVPN Failover Scenarios

So, in the topology we have 4 CSRs running Cisco IOS (CSR1, CSR12, CSR13, CSR14) with iBGP configured. I will primarily be using CSR1 & CSR13 for this post.

Configuring ACLs - allows us to permit authorized BGP traffic, deny unauthorized traffic, & allow all other types of traffic.

I start with configuring an ACL on CSR13:

ip access-list extended SECURE_BGP
 permit tcp host 10.0.10.1 any eq bgp
 permit tcp host 10.0.10.1 eq bgp any
 deny   tcp any any eq bgp
 deny   tcp any eq bgp any
 permit ip any any

Note that the topology I am using is running iBGP in a flexvpn overlay hence the any <locally assigned address>. In my lab the hubs are issuing an IP to spokes from a local pool upon establishing a security association (SA).

This access-list then gets assigned to the tunnel interface that is used to connect to CSR1.

interface Tunnel0
 ip address negotiated
 ip mtu 1400
 ip nhrp network-id 10
 ip nhrp shortcut virtual-template 1
 ip access-group SECURE_BGP in
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.254
 tunnel mode ipsec ipv4
 tunnel destination 192.168.254.1
 tunnel protection ipsec profile CIF_IPSEC_PROF
end

Note that technically this security feature would be better served on a non-tunnel interface that may be receiving traffic from multiple hosts. My goal for this post is to walkthrough how to secure and harden BGP. Also, I assigned the ACL to the tunnel interface connecting to hub2 (CSR12; 10.0.100.2 which is not allowed in the ACL to establish a BGP connection). We can now see the ACL working as expected:

Configuring BGP Authentication - BGP peer authentication allows us to prove neighbors are legit, trusted, & authorized. This aides in ensuring IPs are not spoofed by attackers & ensures that only legit routes from real peers are installed. Cisco supports MD5 authentication & the authentication password must be enabled on both sides of the BGP peering session.

In the lab I continued to work with CSR13 & CSR1. I enabled BGP authentication on both sides as shown:

csr13(config-router)#neighbor 10.0.10.1 password 0 CifelliP@$$
csr1(config-router)#neighbor SPOKES password 0 CifelliP@$$

The only difference is on the hub is that I used a peer-group for the other lab. After entering the unencrypted password you should enable (#service password-encryption) which will encrypt the password for added privacy. Viewing password afterwards:

neighbor SPOKES password 7 14341B0D0908262214087771

Should one peer have the wrong password you will see the following while debugging BGP:

Configuring CoPP - this security feature aides in protecting the device's control plane. This feature allows us to manage & rate-limit traffic flow to the control plane. CoPP protects the router processor via treating individual resources as unique objects with separate input interfaces. This way we can decide what we want to permit versus drop in regard to consuming resources via QoS policies.

A quick overview of steps needed to configure CoPP:

Step 1: Create an ACL to match the desired traffic

Extended IP access list BGP_COPP
    10 permit tcp host 10.0.10.1 any eq bgp
    20 permit tcp host 10.0.10.1 eq bgp any

Step 2: Create a class-map to utilize ACL from step1

class-map match-all BGP_COPP
 match access-group name BGP_COPP

Step 3: Create policy-map, assign class-map, & determine actions/policing

policy-map BGP_PMAP
 class BGP_COPP
  police 8000 4000 conform-action transmit exceed-action drop

The example above rate limits BGP traffic from the CSR1 peer. Packets are policed & allowed as long as the number of packets is below the threshold (8000 bps). If the number of packets exceeds then packets are dropped. Note that this is just an example and all COPP should be tested to best fit your environment.

Step 4: Apply policy-map to the device control plane

control-plane
 service-policy input BGP_PMAP

We can then verify via:

Configuring Max BGP Prefix - this BGP feature allows us to control the total number of prefixes we wish to receive from defined neighbors. Enabling this feature ensures that a single neighbor will not have the ability of consuming too many resources. When this feature is used the router will terminate neighbor peering if the number of received prefixes exceeds the number configured.

To test this feature I configured the following on CSR13:

csr13(config-router)#neighbor 10.0.10.1 maximum-prefix 1 100 restart 10

This configuration enables max-prefix of 1 for our CSR1 neighbor. Next is the configured threshold of 100% which will generate a warning. Then if CSR1 sends more than 1 prefix, on the 2nd received prefix BGP on CSR13 terminates & is configured to restart in 10 minutes. Note that this is an example in my lab and will vary based on environment needs.

CSR1 is configured already to redistribute OSPF into BGP with a prefix-list filter so the CSR13 table only depicts the one prefix before any modifications to CSR1 in regard to advertising an additional prefix.

Before additional prefixes (CSR13 table):

To trigger the restart I simply issued the following on CSR1 (10.0.10.1):

CSR1(config-router)#redistribute static

Then via debugging on CSR13 AFTER receiving the additional prefixes we can see that CSR13 terminates the session, after reset it sits idle, & the BGP table is empty (waiting to restart via configured 10 minutes):

Configuring BGP Prefix Filtering - this feature allows us to permit/deny specific prefixes for each BGP peer. This ensures that we do not accidentally advertise/accept unnecessary routes to/from peers. Using prefix filtering we can ensure that correct routes are accepted and/or advertised.

On CSR1 I have configured a prefix-list that is referenced via a route-map that is then assigned to my OSPF redistribution statement so that only 11.11.11.11 is advertised:

ip prefix-list OSPF_ROUTES seq 5 permit 11.11.11.11/32
!
router bgp 65001
 bgp log-neighbor-changes
 bgp listen range 10.0.10.0/24 peer-group SPOKES
 redistribute ospf 10 match internal external 2 route-map OSPF_ROUTES
 ...omitting rest of config...
 !
route-map OSPF_ROUTES permit 10 
 match ip address prefix-list OSPF_ROUTES

Note that we don't have to use a route-map. You can create a prefix-list and attach it to a neighbor via the following:

#neighbor <ipaddr> prefix-list <prefix-list name> <in|out>

Configuring Time to Live (TTL) Security Check - this BGP feature provides a security mechanism by checking the final TTL received in the packet to the expected TTL value for the respective BGP session. If the TTL is less than the expected TTL then the packet is dropped. Note that if the TTL is exact or greater than the configured value it passes & the BGP session establishes. Remember that TTL decrements once for each hop in the path. Lastly this feature is used for EBGP peers. Attempting to configure it with iBGP tosses the following error:

ttl-security only allowed for EBGP peers

One last important thing to note before wrapping up this blog: Make sure to enable logging. Enabling BGP logging can be done via #bgp log-neighbor-changes for each respective AS. This allows us to track neighbor status changes, resets, & aides in troubleshooting issues.

That wraps up this post covering several ways to secure BGP. Cheers!