Use BGP to defend against a DDoS attack originating from remote AS

Question

I have a question regarding BGP and how to achieve this configuration.

My enterprise core router is connected to an ISP (single homed). This router has already exchanged the specific public ip prefixes to the ISP in BGP updates. Now lets says there is an AS several hops away that is flooding my local AS with a DDoS attack. There are multiple networks in that AS targeting the web servers in my local AS.

How can we stop this traffic on our router by using BGP?

Appreciate your response!! :)

Answer 1

There are two things you could do with BGP:

RTBH - Remotely-Triggered Black Hole

First option is the radical one: Blackhole (stop traffic) for the IP getting attacked. Downside: The IP being targeted is no longer reachable. Benefit: The rest of your network stays up. Packetlife has a nice explanation on how it work and how to do it. The second option builds on the first one:

Source-Based RTBH

RTBH can also be used (in certain configurations) to block traffic coming from specific IPs (in a real DDoS that wouldn't help much as traffic would come in from thousands of IPs). Again, Packetlife has an explanation.

In your case you could get all prefixes for the AS from a Routing Database like RADB and block these with Source-Based RTBH. Traffic would still hit your network at the border though.

When you use "simple" RTBH the advantage is that you can send these RTBH routes to your Upstream ISP (if they support it) who could then block the traffic in their network already so you don't have to handle it.

Answer 2

The RTBH method described by @Sebastian via Packetlife is helpful, but that method will only work if your uplink is not saturated by attack traffic. If your uplink is saturated, then the blackhole must be implemented at a point before the attack traffic reaches your network.

You can accomplish this with upstream blackhole communities.

Hurricane Electric offers a simple explanation/example of customer-triggered blackholing with a BGP community:

1. Attack Starts
2. Customer identifies ip or ip range under attack
3. Customer static routes the ip or ip range to Null0 and adds an announcement of the corresponding prefix with a route map that tags it with 6939:666.

Cisco configuration example (where X.X.X.X is the ip being attacked):

conf t
ip route X.X.X.X 255.255.255.255 Null0
router bgp YourAS
network X.X.X.X mask 255.255.255.255 route-map blackhole
route-map blackhole permit 10
set community 6939:666
end

Note that 6939:666 is the blackhole community specific to Hurricane Electric. You would modify this value to correspond with the blackhole community of your upstream provider.

There are of course multiple ways to configure this. On my Brocade gear, I use the following configuration:

router bgp
!
redistribute static route-map blackhole
!
!
route-map blackhole permit  5
 match tag  66
 set community  55555:666

Where 55555:666 is the blackhole community of your upstream provider. An upstream blackhole can then applied with a simple command:

ip route 123.123.123.123 255.255.255.255 null0 tag 66

Answer 3

From a BGP perspective, there is not much you can do. You could stop advertising your prefix but then you are just completing the DoS attack because noone will be able to access your service.

If you have multiple prefixes you could renumber but likely the attack will move to the new prefix as well.

What you need to do is to work with your upstream. Do they have a scrubbing service? If they have a system such as Arbor Peakflow, they could scrub the traffic and clean it before it enters your network. Such services are often very expensive.

There are also other options such as Cloudflare and similar companies where you setup BGP through a GRE tunnel to that company and your traffic gets handled by their "cloud" which can handle a lot more traffic than your local devices.

Answer 4

I work for CloudFlare, I'd like to share some of the knowledge I've developed about mitigating DDOS attacks over the last few months I've been here.

Firstly; a lot of people resort to network level measures to mitigate application layer DDOS attacks. Before diving to BGP Blackholing, consider whether it's something rate limiting or application layer protection could deal with. That said; it's now very cheap to launch very large capacity DDOS attacks (given how many Open DNS Recursors are around, and how they can amplify attacks).

As Elliot described in his answer, using BGP Communities to blackhole traffic can work well if your network is small; this mechanism is documented in RFC 3882. However, like us, if you instead you wish to absorb the attack traffic instead of blackhole (i.e. you want to collect DDOS attack data), then beware of collateral damage whereby intermediary network providers end up being congested. You can mitigate the collateral damage by peering directly with the ISPs of the networks who are launching the attacks. By doing so you have the shortest path from attacker to destination. Additionally you can implement an Anycast network design, this will effectively mean one IP address hits multiple datacenters (depending on whichever is closest).

Obviously it's not possible for every company to have the infrastructure to do Anycast and peering; that's why businesses are increasingly turning to cloud services to remove the bad traffic before it reaches their datacenters. Naturally CloudFlare is one such service.

Answer 5

If all the evidence you have collected is a flood of packets with source IP addresses from one particular AS, you have likely jumped to the wrong conclusion. A more likely explanation would be that those source IPs are spoofed.

A reflection/amplification attack involves sending lots of packets spoofing the source IP address of a victim. If this is actually what is happening, and you have servers in your network, that can amplify an attack, then the network you are accusing of an attack is actually the victim, and you are aiding the attacker.

In such a situation the solution is not to apply any sort of traffic engineering, but rather to configure your servers such that they cannot be used in an amplification attack. How to do this is not really a network engineering question.

It is of course possible, that all the packets are originating from one AS. With co-operation from the offending AS, you could get confirmation, that the packets do in fact originate from their AS. However with that level of co-operation, you could also get the attack blocked at the source.

If we assume you have through some method I haven't thought about gotten confirmation the packets are really originating from the AS you think, and that you cannot get it blocked at the source and instead want to block it through means of BGP, then I have read about a somewhat risky method to achieve this. The idea is that you prepend an AS path to the route you are announcing. In this prepended AS path you include the AS number of the source of those packets.

When the announcement reaches the BGP routers in the offending AS, they are going to detect a loop and drop the announcement. Meanwhile the rest of the world won't see a loop and accept the announcement.

That's the theory. Whether it will actually work in practice depends on a few different factors. For example it depends on actually using the AS number the packets are originating from, which could be different from the AS number announcing those IP addresses. (Such difference could be legitimate or due to spoofing.)

It also depends on your upstream not filtering the route if they find the AS path suspicious. Moreover networks further away from you may also drop your route for example if they also has had bad experiences with the offending AS and have decided to drop all routes from there.

It's your call whether this approach is worth the risk.

(I would have linked to the source for this approach, if I could find it again.)

Answer 6

You can blackhole their AS from your local network, so your BGP router creates null routes for any prefix they announce.

Pro:

• your AS will appear dead to them, which is their goal, while you still exchange data with everyone else normally.
• your local ingress filtering will automatically drop incoming packets from that AS

Contra:

• they can create blackhole routes on your router, so be sure to have appropriate rules in place to keep your most vital routes intact