Enhanced BGP routing protocol under Linux

The BGP protocol runs on top of TCP and, as a result, it inherits all vulnerabilities of TCP connections. For example, in a BGP session, an attacker could impersonate a legitimate BGP neighbor, and then persuade the BGP router on the other end to share routing information to the attacker. This problem occurs when an attacker informs and routes a spoofed route to a neighbor. The unsuspecting neighbor router begins to send a live communication to the attacker, and in fact the information does not go anywhere but is simply discarded. Back in 2008, YouTube was actually victimized by this BGP route poisoning and suffered a massive disruption of video services for up to one hours. In a worse case scenario, if an attacker is a knowledgeable person, they can disguise themselves as a transparent router and sniff through traffic to get sensitive data. As you can imagine, this will have a far-reaching impact.

To protect active BGP sessions from attack, many service providers use MD5 checksums and preshared keys in BGP sessions. In a protected BGP session, a packet-sending BGP router generates MD5 hash values, partial IP and TCP headers, and payloads by using preshared keys. The MD5 hash is then stored as a TCP option field. After the package is received, the receiving router uses the preshared key to generate its MD5 version in the same way. It compares its MD5 hash with the value of a packet received to decide whether to accept the package. It is almost impossible for an attacker to guess the checksum or its key. For BGP routers, they can ensure the legality of each package before using the contents of the package.

In this tutorial, we'll show you how to use the MD5 checksum and preshared key to secure a BGP session between two neighbors.

Get ready

Hardening BGP session security is fairly straightforward and straightforward, and we'll use the following routers.

The common Linux kernel natively supports the IPV4 and IPv6 TCP MD5 options. Therefore, if you build a Quagga router from a new Linux machine, the TCP MD5 feature is automatically enabled. The only thing left to do is to configure Quagga to use its functionality. However, if you are using a FreeBSD machine or build a custom kernel for quagga, make sure that the kernel has TCP MD5 support (for example, the CONFIGTCPMD5SIG option in Linux).

Configuring the ROUTER-A authentication feature

We will use the Quagga CLI shell to configure the router, and the only new command we will use is ' password '.

The code is as follows:

[Root@router-a ~]# Vtysh

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 in the configuration file (e.g., login password). However, when I used the command, I noticed that the preshared key in the BGP configuration was still plaintext. I'm not sure if this is a quagga or a version of the problem.

Configuring the Router-b authentication feature

We will configure router-b in a similar way.

The code is as follows:

[Root@router-b ~]# Vtysh

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

Verifying BGP Sessions

If everything is configured correctly, then the BGP session should be up and the two routers should be able to exchange routing tables. At this point, all outgoing packets in a TCP session carry a packet of a MD5 digest and a key, and the summary information is automatically validated by the other end.

We can verify an active BGP session as usual by looking at the BGP profile. The validation of the MD5 checksum is transparent within the quagga, so you cannot see it at the BGP level.

If you want to test BGP validation, 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 that pass through a BGP session. For example, tcpdump with the "-M" option validates the MD5 summary for the TCP option field.

Summary

In this tutorial, we demonstrate how to simply harden the BGP session security between two routes. The configuration process is concise relative to other protocols. It is highly recommended that you reinforce BGP session security, especially if you are configuring a BGP session with another as. Pre-shared keys should also be saved securely.