Border Gateway Protocol

Border Gateway Protocol:

Border Gateway Protocol is generally used when routing a very large interior network, binding multiple interior networks together or for interdomain routing across the Internet because of its robustness and scalability. Because of the size and importance of the networks generally interconnected with BGP securing the protocol from attacks is always a good idea. There are many ways of securing BGP on many different platforms. Because of the popularity of Cisco routers on the Internet, I will be using their command line for any configuration examples.

Port filtering: 

Since BGP peers communicate over TCP port 179 its always a good idea to filter communications over this port to your trusted peer addresses only over the interfaces they will be communicating across. The filtering can be done on a firewall or perimeter router.
Authenticating peers: One of the most basic forms of security with BGP is peer authentication. You can simply configure an MD5 key in your neighbor statement causing each segment sent on the TCP connection between the two peers to be verified.

        Example:
        router bgp 510
        neighbor 132.45.78.3 remote-as 320
        neighbor 132.45.78.3 password SecureMyBGP123

Hard code the BGP version: 

The most common version of BGP running today is BGP version 4, however by default BGP will negotiate BGP version with their peer. If you are already sure that the router(s) you will be peering with will be running BGP version 4 it's easy to set this option with a neighbor statement and it can save some network recovery time if your router did fall under attack.

        Example:
        router bgp 510
        neighbor 132.45.78.3 remote-as 320
        neighbor 132.45.78.3 password SecureMyBGP123
        neighbor 132.45.78.3 version 4

   

Route filtering: 

With the size of Internet routing tables it's particularly important to make use of route filtering on BGP speaking routers. Incoming routes on external BGP speaking routers are the most important but it can also be important to filter incoming routes on your internal BGP networks as well as outgoing routes on both. This can control the spread of any routing anomalies from one network to another. With BGP you can make use of both the distribute-list or prefix-list in your neighbor statement but not both for the same peer. You can also make use of both access control lists or prefix lists although the better alternative as far as CPU usage goes would be the prefix list. In this example, we will create a prefix-list that will only accept routes with a prefix greater than /8 and less than /16 and then apply this to our neighbor as an inbound distribute-list.

        Example:
        router bgp 510
        neighbor 132.45.78.3 remote-as 320
        neighbor 132.45.78.3 password SecureMyBGP123
        neighbor 132.45.78.3 version 4
        neighbor 132.45.78.3 distribute-list netpolicefilter in
        !
        !
        ip prefix-list netpolicefilter seq 10 permit 0.0.0.0/0 ge 8 le 16

Null0 (pit bucket) routes: 

Previously we showed an example of route filtering using neighbor statements and prefix lists but sometimes the same thing can be accomplished with a less CPU intensive process. Null0 routes will drop any traffic matching the route and not having a longer (more specific) match in the routing table into the pit bucket immediately. This process is called "Black Hole Filtering". The example below would ensure that any traffic destined for network 131.50.24.0/24 was sent directly to the pit bucket unless a longer match is found in the routing table.

        Example:
        router bgp 510
        neighbor 132.45.78.3 remote-as 320
        neighbor 132.45.78.3 password SecureMyBGP123
        neighbor 132.45.78.3 version 4
        neighbor 132.45.78.3 distribute-list netpolicefilter in
        !
        !
        ip prefix-list netpolicefilter seq 10 permit 0.0.0.0/0 ge 8 le 16
        !
        !
        ip route 131.50.24.0 255.255.255.0 null 0

Logging neighbor changes: 

Although things like connection, hardware, and bandwidth problems can cause frequent up/down conditions with a BGP peer it could also be a sign of a DoS attack on the network. Changes in BGP neighboring router status can be logged with a simple neighbor command if you have logging setup properly in your router. It's always a good idea to timestamp logs and check them frequently.

        Example:
        router bgp 510
        neighbor 132.45.78.3 remote-as 320
        neighbor 132.45.78.3 password SecureMyBGP123
        neighbor 132.45.78.3 version 4
        neighbor 132.45.78.3 distribute-list netpolicefilter in
        neighbor 132.45.78.3 log-neighbor-changes
        !
        !
        ip prefix-list netpolicefilter seq 10 permit 0.0.0.0/0 ge 8 le 16
        !
        !
        ip route 131.50.24.0 255.255.255.0 null 0