Introduction to BGP Blackhole and automating it for DDoS defense
In this article, we will discuss how the routing infrastructure, more specifically the BGP routing technique called “blackholing”, can provide efficient mitigation for DDoS attacks. We will go through some key concepts, and explain how to set up and manage a RTBH (Remotely Triggered Black Hole), and highlight the advantages and disadvantages of the technique.
What exactly is a BGP Black Hole?
A BGP BlackHole is a routing technique that serves as an effective and affordable method for mitigating DDoS attacks. As the name suggests, “blackholing” network traffic makes it disappear without a trace, which is a very desirable outcome to malicious traffic. Let’s discuss more into detail how this works.
To put it simply, BGP black hole works by discarding the traffic, by routing it to a Null 0 (aka Null Route) within your network. The Null Route acts as a “black hole” where packets are discarded – without transmitting a status notification to the sender about the failed delivery. From the attacker’s perspective, this “black hole” is virtually invisible within the network, making it highly efficient for DDoS mitigation.
Black Hole Automation, RTBH, sRTBH, what’s the difference?
Starting off with definitions: RTBH (Remote Triggered Black Hole) and Black Hole Automation, or Black Hole Routing are essentially the same methodology, and many vendors and operators use the terms interchangeably. For the ease of reading, we will use the term RTBH in this post.
When we refer to RTBH we mean that we block traffic to / from hosts in our own network. We basically unplug our own services from the Internet. It’s very important to remember it as many engineers expect that it will drop traffic from the attacker side which is not the case.
Slightly different, and much less commonly used methodology is sRTBH (Source-based Remote Triggered Black Hole). sRTBH is similarly a BGP based traffic filtering methodology, but instead of simply triggering a RTBH, sRTBH would involve blocking the source of the traffic.
The brief history BGP black hole filtering
BGP, which is the fundamental protocol that connects the Internet together, has been used for over 15 years as a core anti-DDoS tool. Up until the early 2000’s, DDoS attacks were fended of fairy manually: When a network anomaly was detected, the network engineer would first investigate and confirm whether the incident was in fact a DDoS attack. They would then manually trigger a black hole response, either by accessing the router, or by informing the ISP/network provider to start discarding the traffic. Finally, the engineer would resume the normal routing, or notify the ISP once again when the attack has ceased. Considering the current environment, this sounds hopelessly too slow and unreliable procedure, but it still is the standard approach in mitigating DDoS attacks in many organisations.
As the attacks grew more commonplace and network uptime requirements more critical in many services, this same process was automated for faster response times, which led to the development of RTBH automation. With automation, the network engineers can set up specific rules on when to trigger the black hole, what to do with the blackholed traffic and what happens after.
Why is RTBH so efficient?
The key advantage of using remotely triggered black hole in DDoS mitigation is the factor that it is implemented with the assistance from all your network upstreams and their upstreams. The implementation has the full filtering capabilities of larger Internet service providers, making it basically unlimited in volume.
Let’s look at a practical example how this typically unfolds in real attack situation. In this case, we have a sizable DDoS attack of 100G towards a network with three carriers and two IXPs:
Now let’s zoom in to one of the carriers and demonstrate how we’re triggering the RTBH. The 40 Gbits of malicious traffic are coming from their 3 ISPs:
The traffic is black-holed at the upstream, and this same mechanism happens on all of the carriers of the attacked network, and their ISPs. At some point of this propagation, the filtering gets close to the source of the attack itself, and will remove attack’s traffic from all intermediate ISPs as it will be dropped shortly after it was sent by attacker.
Key considerations before configuring RTBH
Now that we understand the background of the methodology, let’s discuss some of the key considerations on automating a RTBH. One of the advantages of RTBH is its flexibility, as you can configure it as simple or as complicated as you want. There are a few considerations you want to think of before configuring your RTBH:
First, you need to decide which routers will you apply your policies on. To set up a RTBH, it’s necessary to filter traffic at the key points within your infrastructure. You’ll probably want to establish RTBH policies for routers that maintain direct connections with your transit providers or peers, as it’s not desirable to let illegitimate or attack traffic through more than necessary on your network. And of course, for the use of RTBH, the routers you choose must be compatible with BGP and offer a basic implementation of routing policy.
Second, you’ll need to decide on the thresholds when you want to trigger the black hole automation, and how you want to deactivate the RTBH policy. For example, you can set up a certain volume based threshold when the policy is triggered, and time based rule to deactivate.
Finally, you need to decide what to do with the discarded traffic. There are several options to forward the traffic to a scrubbing center, or to block completely.
Configuring your RTBH
When choosing how to set up your RTBH configuration, most network engineers opt to use a software such as FastNetMon to avoid several manual steps to set up and maintain. FastNetMon provides a complete integration, email alert system and automated unblocking, and detects attacks in less than 5 seconds.
However, to understand how RTBH typically set up from scratch, here’s a comprehensive explanation:
Configuring Remote Triggered Black Hole (RTBH) involves setting up a trigger that sends iBGP updates to its peers, setting the next hop for a network or host to a predetermined unused IP address. The trigger can be any device that runs BGP, not necessarily a router. For redundancy, it’s recommended to have multiple regionalized triggering devices, each protected by dual power supplies.
To contain the iBGP routing updates used to trigger black holes at the network edge, there are three recommended methods: using BGP communities, setting an extra community for the prefix used in the trigger advertisement, and using an egress prefix filter with eBGP peers.
Once the trigger advertisement is sent to the iBGP peers, it’s important to ensure that the peers prefer this route to one that they already have for the destination network. This can be achieved by setting a local-preference value greater than the default value of 100 and setting the origin to igp.
The edge routers drop suspicious traffic by forwarding it to a Null0 interface. A static route is configured at the edge, and the next hop is set to Null0. The edge router receives an iBGP route update, which sets the next hop of the destination under attack to this static route. All future traffic to the destination is dropped at the edge because the next hop to the destination under attack is equated to Null0.
It’s recommended that when a Null0 interface is created at the edges, the ICMP unreachable message is disabled for this interface. If ICMP unreachable messages are not disabled, it’s strongly recommended that they be rate limited so they will not flood the network.
RTBH filtering is typically deployed by configuring iBGP on the provider edge and a new triggering device at the NOC. The trigger maintains an iBGP peering relationship with all the edge routers or with all the route reflectors in the ISP environment. Manual entry of the static route is done on the trigger as well as setting all the necessary characteristics such as the next hop, local preference, and BGP communities.
Final considerations
RTBH is a very efficient methodology to defend against volumetric attacks due to its capacity to use the filtering capacity of larger ISP’s. Setting up an functional RTBH implementation does require an in depth understanding in BGP implementations across different vendors, but this is where FastNetMon comes in. Read more how our black hole automation works here: https://fastnetmon.com/bgp-blackhole-automation/
Every DDoS mitigation methodology comes with its own set of advantages and drawbacks. For instance, a DDoS attack could be specifically engineered to compel an ISP to black hole a customer. The attack could be designed to inflict collateral damage on neighboring customers, forcing the network to respond with a remote-triggered black hole, thereby cutting off the legitimate customer’s traffic. The issue here is that the black hole is precisely what the attacker intended – to eliminate the customer’s ability to receive traffic.
Because of this limitation, it is essential to have a variety of mitigation tools at your disposal rather than relying solely on blackholing. Visit our website to learn more about the various techniques you have available on just one installation of FastNetMon: https://fastnetmon.com/
About FastNetMon
FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard.
Find out more: https://fastnetmon.com/