| |
BGP protocol running on top of TCP, therefore, it inherits all the loopholes in the TCP connection. For example, in a BGP session, an attacker can impersonate a legitimate BGP neighbor, and then convince the other side of BGP routers share routing information to the attacker. When the attacker routes advertised to the neighbor inject bogus routing, this problem will occur. Unsuspecting neighbors will start sending the attackers live communication, in fact, this information does not whereabouts anywhere, just to be discarded. Back in 2008, YouTube actually victims of such poisoning BGP routes, and subjected to an hour-long video of a large number of service interruptions. A worse case, if the attacker is sufficiently knowledgeable people, they can be disguised as a transparent router, then sniffing through traffic for sensitive data. As you can imagine, this will have far-reaching impact.
Active BGP sessions to protect against attacks, many service providers using BGP session MD5 checksum and pre-shared key. In a protected BGP session, BGP router sends a packet generating MD5 hash value by using a pre-shared key, part of the IP and TCP header and payload. Then, MD5 hash as a TCP option field stores. After receiving the packet, the receiving router in the same way using a pre-shared key to generate its MD5 version. It places its MD5 hash value and received a package of comparison to decide whether to accept the package. For an attacker, it is almost impossible to guess a checksum or key. For BGP routers, they can ensure the legitimacy of each package before using the contents of the package.
In this tutorial, we'll show you how to use MD5 checksum and pre-shared key to strengthening security BGP session between two neighbors.
ready
Strengthening BGP session security is fairly simple and straightforward, we will use the following router.
AS IP address of the router name resolution
router-A 100 10.10.12.1/30
router-B 200 10.10.12.2/30
Common Linux kernel native support for IPv4 and IPv6 TCP MD5 option. So, if you are from a new Linux machine built a Quagga router, TCP's MD5 function is automatically enabled. Remaining things, simply to configure Quagga its functionality. However, if you are using FreeBSD machine to Quagga or build a custom kernel, make sure the kernel opens the TCP MD5 support (eg, Linux in CONFIGTCPMD5SIG option).
Configuring Router-A Verification
We will use Quagga the CLI Shell to configure the router, only one new command that we will use is 'password'.
[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-as200
router-a (config-router) # neighbor 10.10.12.2 password xmodulo
Pre-shared key used in this example is 'xmodulo'. Clearly, in a production environment, you need to choose a more robust key.
Note: In the Quagga, 'service password-encryption' command is used to encrypt all the plaintext password in the configuration file (eg, password). However, when I use the command, I noticed BGP configuration, pre-shared key is still the plaintext. I'm not sure if this is Quagga restrictions, or release their own problems.
Configuring Router-B Verification
We will be in a similar manner to configure router-B.
[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-as100
router-b (config-router) # neighbor 10.10.12.1 password xmodulo
Verify BGP sessions
If everything is properly configured, BGP session should be up, two routers should be able to exchange routing table. At this time, all outgoing packets TCP session will carry a MD5 digest of the package contents and a key, while the other end of the summary information is automatically verified.
We can as usual by looking BGP summary to verify the active BGP session. MD5 checksum verification Quagga inside is transparent, so you can not see the level of BGP.
If you want to test BGP authentication, you can configure a routing neighbor, set its password is blank, or deliberately using the wrong pre-shared key, and then see what happens. You can also use a packet sniffer like tcpdump or the like Wireshark, analyzed by BGP session package. For example, tcpdump with "-M" option to verify the MD5 digest TCP options field.
summary
In this tutorial, we demonstrate how simple reinforcement BGP session security between the two routes. Relative to other protocols, the configuration process is very simple. Highly recommended strengthening BGP session security, particularly if you use another AS configure BGP session time. Pre-shared key should be safely stored. |
|
|
|