BGP-Targeted DoS Attacks

BGP-Targeted DoS Attack Can Disrupt Internet Routing

Border Gateway Protocol (BGP) is the protocol, which is designed to share routing, reachability and some other information among autonomous systems (AS). Border Gateway Protocol’s concepts and implementation were defined in RFC 1654. This RFC was made obsolete by RFC 1771 and RFC 4271. Autonomous System Numbers (ASNs) are assigned by Internet Assigned Numbers Authority (IANA) and creation, selection, and registration of an Autonomous System (AS) was defined in RFC 1930 and best current practice shown in BCP 6.

The modern routers is design to handle the traffic with respect to the destination of the packets. If the packet is coming to an IP which is assigned to one of the interfaces of the router, the packet is going to be handled by control plane. If it is not, it is going to be processed in forwarding plane. The best and simple explanation of the difference between forwarding and control plane is following.

After getting brightened about the topic, as predicted, BGP is also handled by control plane of the router. The other protocols those are handled by control plane are following; SSH, SNMP, eBGP, (iBGP), OSPF, EIGRP and so on.

Today, I am going to mention that “what if control plane of the router is flooded?”. We will try to stress the CPU of the router by using BGP. Fortunately, attackers haven’t realize about this weakness 🙂

Assume that we have a topology as follows:

Also assume that;

• We have single-homed Internet Service Provider (ISP) topology,
• BGP peering subnet is 10.20.30.0/30,
• Our ASN is 200,
• ISP1’s ASN is 100,
• Our public subnet, which is announced to ISP is 100.100.100.0/24.

Step 1: Being Familiar About The Protocol BGP

While configuring the BGP peer, it is need to specify some mandatory parameters such local AS, remote AS, remote IP, keepalive and hold time timers by sending open messages.

After BGP peering was established, the peers is sending keepalive messages periodically due to their configurations. If the peer does not receive a keepalive, update, or notification message within the specified hold time, the BGP connection to the peer is closed and routing devices through that peer become unavailable.

The default values of the brands are “30 secs Update Timer and 90 secs Hold timer for Juniper” and “60 secs Update Timer and 180 secs Hold timer for Cisco”.

Ok then, if we make the router to not send the update messages to the peer, what is going to be observed?

• BGP connection is going to be closed.
• All routes that is receiving from that peer is going to be unavailable.
• If BGP route flap dampening (defined in RFC2439) was configured on the ISP routers, it is going to suppress the routes that is received from the flapping peer for a time defined before.

As seen, if an attacker could succeed to break down our BGP peers,  our internet connectivity is also going to break down!

Step 2: Finding Suitable Packets to Break Down a BGP Peer

When an error condition is detected on the BGP peering, the router is going to generate a “Notification Message”. Notification message format is defined in RFC4271 section 4.5 as follows.

Lets have a look at RFC4271 section 6.5. It is said that “If a system does not receive successive KEEPALIVE, UPDATE, and/or   NOTIFICATION messages within the period specified in the Hold Time   field of the OPEN message, then the NOTIFICATION message with the   Hold Timer Expired Error Code is sent and the BGP connection is closed.”

So, What if we generate a hold timer expired packets and send it to the victim router?

Step 3: Generating a Hold Timer Expire Packet

In order to generate a fake packet, firstly, we need to capture a real packet.  To capture the packet, I constructed a topology below in GNS3 and I force the router to generate a NOTIFICATION message with the hold timer expired error code.

The output of the tcpdump is following,

Step 4: Lets Send Fake Packets to Real World and Observing The Results

As I explained in my previous posts, I am going to use MZ (Mausezahn) again. Basically, I am going to copy the payload of the packet that I generate in Step 3, and try to generate the same packet by using Mausezahn.

Victim is choosed from a Shodan with aid of  the query “port:”179″”.

By sending only 65535 packets to the router of an ISP in 0.44 seconds, the routes those are origated from that ISP is withdrawn as follows.

The results also can be observed from looking glass tools as follows.

Step 5: Defence! How Do We Protect Ourselves?

There are some trick to overcome a BGP-Targeted DoS Attack. Those are;

• Configure your EBGP peer to work as Single Hop mode.
• Most of the EBGP peers works on a directly connected links, so, using TTL (Time to Live) security as 1 will help us to protect the peer.
• Requesting from your ISP to not advertise your Peering IP to the World! This is the best solution. But, In Turkey, ISPs’ networkers don’t allow to do this!! (I don’t know why? If someone knows the reason, please inform me from the comment.)
• If you don’t make your ISP to confirm the previous trick, request from them to write an access list (ACL) to not allow the traffic to TCP port 179 except your neighbor.
• Also there are some other methods about protecting the router control plane, defined in RFC6192.

But, this time I am wondering about the result ; “what if we spoofed the BGP neighboor IP and adjust a suitable TTL to beat the TTL security?” 🙂

In my next blog post, I am going to talk abou it.

If you have a question, please do not hesitate to ask me by leaving a comment.

Best Regards.