BGP runs on top of TCP, so it inherits all the vulnerabilities of TCP connection. For example, in a BGP session, an attacker can impersonate a legitimate BGP neighbor, and then persuade the BGP router at the other end to share routing information with the attacker. This problem occurs when an attacker notifies and injects a fake route to a neighbor route. The unsuspecting neighbor router will start to send the attacker live communication. In fact, the information has not gone anywhere, it is just discarded. Back in 2008, YouTube actually suffered from such BGP routing poisoning, and suffered a massive interruption of video service for an hour. An even worse situation is that if the attacker is knowledgeable enough, they can disguise themselves as a transparent router and sniff the traffic to get sensitive data. As you can imagine, it will have a profound impact.
To protect an active BGP session from attack, many service providers use MD5 checksums and preshared keys in BGP sessions. In a protected BGP session, a BGP router sending packets generates MD5 hash values, some IP and TCP headers and payloads by using pre shared keys. The MD5 hash is then stored as a TCP option field. After receiving the packet, the receiving router uses the preshared key to generate its MD5 version in the same way. It will compare its MD5 hash with the value of a received packet to decide whether to accept the packet. It is almost impossible for an attacker to guess the check sum or its key. For BGP routers, they can ensure the legitimacy of each packet before using its contents.
In this tutorial, we will show you how to use MD5 checksums and preshared keys to secure BGP sessions between two neighbors.
Consolidating BGP session security is quite simple and straightforward. We will use the following routers.
The commonly used linux kernel natively supports the TCP MD5 option of IPv4 and IPv6. Therefore, if you build a quagga router from a brand new Linux machine, the MD5 function of TCP will be enabled automatically. All that’s left is to configure quagga to use its functionality. However, if you are using FreeBSD machine or building a custom kernel for quagga, please make sure that the kernel has enabled TCP MD5 support (for example, configtcpmd5sig option in Linux).
Configure router-a verification function
We will use quagga’s cli shell to configure the router. The only new command we will use is “password.”.
The code is as follows:
router-a# conf t
router-a(config)# router bgp 100
router-a(config-router)# network 192.168.100.0/24
router-a(config-router)# neighbor 10.10.12.2 remote-as 200
router-a(config-router)# neighbor 10.10.12.2 password xmodulo
The preshared key used in this example is’ xmodulo ‘. Obviously, in a production environment, you need to choose a more robust key.
Note: in quagga, the “service password encryption” command is used to encrypt all plaintext passwords (such as login password) in the configuration file. However, when I use this command, I notice that the preshared key in the BGP configuration is still plaintext. I’m not sure if it’s quagga’s limitation or the version itself.
Configure router-b verification function
We will configure router-b in a similar way.
The code is as follows:
router-b# conf t
router-b(config)# router bgp 200
router-b(config-router)# network 192.168.200.0/24
router-b(config-router)# neighbor 10.10.12.1 remote-as 100
router-b(config-router)# neighbor 10.10.12.1 password xmodulo
Verify BGP session
If everything is configured correctly, the BGP session should be up and the two routers should be able to exchange routing tables. At this time, all outgoing packets in the TCP session will carry an MD5 digest packet content and a key, and the digest information will be automatically verified by the other end.
We can verify the active BGP session by looking at the BGP profile as usual. The verification of MD5 checksums is transparent inside quagga, so you can’t see it at the BGP level.
If you want to test BGP authentication, you can configure a neighbor route, set its password to null, or deliberately use the wrong pre shared key, and then see what happens. You can also use packet sniffers, such as tcpdump or Wireshark, to analyze packets through BGP sessions. For example, tcpdump with the “- M” option will verify the MD5 digest of the TCP option field.
In this tutorial, we demonstrate how to simply secure BGP sessions between two routers. Compared with other protocols, the configuration process is very simple. It is highly recommended that you strengthen BGP session security, especially when you configure BGP session with another as. The pre shared key should also be kept securely.