How to configure Remotely Triggered Black Hole routing to protect from DDOS attacks (with bonus)

Remotely triggered black hole routing is a technique that can be used to protect from DDoS attacks. It has the ability to drop undesirable traffic before it enters the protected network. This article explains how it works and how it can be configured to protect your network.

[thrive_leads id=’12481′]

What is a DDoS attack?

In the Security field, there is something called the “CIA Triad” which refers to the three major principles/goals of Security including Confidentiality, Integrity and Availability:

• Confidentiality deals with privacy of information.
• Integrity means data is not altered either in transit or storage.
• Availability talks about information being accessible to legitimate users when required.

Most security attacks can be classified according to which part of the CIA Triad they affect. For example, a Man-in-the-Middle (MITM) attack can affect both confidentiality and integrity. Another example is a Denial of Service (DoS) attack which targets availability of information/resources.

In a DoS attack, the aim is to consume resources so much that the system/device being attacked does not have the capacity to respond to other legitimate requests. A Distributed Denial of Service (DDoS) is a type of DoS where multiple systems are used to launch an attack against a single target system. Sometimes, the systems involved in this attack do not participate  on purpose – they could have been compromised by malware which then ‘instructs’ them to launch the attack.

DDoS attacks are not just theoretical – there have been many real cases. One of the most recent attacks and probably the largest in history happened in October 2016 when Dyn, a company that provides Domain Name System (DNS) services, was attacked. This attack affected high-profile sites like Twitter, Netflix, CNN and The Guardian. You can read more about this attack and other 2016 DDoS attacks here.

Dealing with DDoS attacks

Having seen how severe DDoS attacks can be with that example of the attack on Dyn, how can we combat against such attacks? There are actually a couple of ways including:

• Application Layer Protection: Since many DDoS attacks are targeted at application layer services such as Web servers, DNS servers and so on, protection at the application layer can be effective.
• Network Layer Protection: For example, access control lists and black hole routing.
• Cloud-based solutions: In recent times, many cloud-based DDoS service providers have sprung up. Incapsula is an example. You can view a comparison of various cloud-based DDoS solutions here.

For this article, let us consider the case of an Internet Service Provider (ISP) that wants to prevent against DDoS attacks. From the list we have above, Network layer protection will be the most applicable to the ISP, while Application layer protection and cloud-based solutions will be more relevant to customers.

Examples of Network layer protection include using access control lists (ACLs) and enabling black hole routing. Both of these protection methods can be deployed at the edge of the ISP’s network which make them quite effective in defeating DDoS attacks. However, when using ACLs, the ISP can run into scalability issues based on managing the size of the ACL and also how quickly packets can be inspected and forwarded/dropped.

Therefore, in this article, we will focus on black hole routing, specifically Remotely Triggered Black Hole (RTBH) Routing.

Remotely Triggered Black Hole (RTBH) Routing

When you hear the term “black hole”, what comes to mind? You will probably think of an imaginary hole with no bottom – anything that falls into that hole isn’t come back out, ever. This is the same concept that applies to RTBH routing.

When RTBH routing is used to protect against DDoS attacks, all traffic to a destination (target) or from a source (attackers) will be routed to a “black hole” which is equivalent to dropping that traffic. On Cisco routers for example, the Null0 interface is used as this black hole.

Note: RTBH routing is not vendor-specific and in fact, there are a couple of Request for Comments (RFCs) that have been written on this topic, for example, RFC 3882 and RFC 5635.

Let’s use the following diagrams to explain how RTBH routing works to defeat DDoS attacks. Keep in mind that to implement RTBH routing, the Border Gateway Protocol (BGP) must be in use (in the ISP’s internal network from our scenario).

The diagram above shows an ISP core network that includes several routers. This ISP provides service to several customers but for explanation purposes, we will focus on one customer shown in the diagram. This customer has a web server on its network that is accessible to the public.

In this next diagram, several devices (e.g. computers, IoT devices) have launched a DDoS attack against that customer’s web server. If the ISP lets this attack continue, not only will it affect the customer under attack, it will also degrade service for their other customers.

The ISP decides (or on request from the customer) to act and has two options:

1. Black hole traffic from the source of the attack
2. Black hole traffic to the target of the attack

Source-based and Destination-based RTBH routing

The first method is preferable because the ISP is able to stop the attack traffic to the customer’s web server while allowing other legitimate traffic to go through. However, this is not always possible because the source addresses of the attack may not be known (or constantly changing). This method is known as Source-based RTBH routing.

On the other hand, if the ISP drops traffic to the target of the attack, both legitimate and attack traffic will be dropped to that web server. In a way, this means that the attacker has succeeded in making the web server unavailable; however, the ISP is able to save the customer’s other resources and also prevent service degradation to its other customers. This method is known as Destination based RTBH routing.

How to implement RTBH routing

From a technical point of view, how does the ISP implement this black hole? It does so in the following steps:

• Configure a “discard route” on its edge routers. A discard route is a route that points to a black hole (e.g. null0).
• On these edge router, configure the RTBH BGP policy such that if the router receives a route advertisement with a certain community or tag, the router will set the next hop of that route to the address configured in the discard route. Since the discard route points to a black hole, it means routes that match the configured BGP policy will be blackholed.
• Designate a router as the “trigger router”. This device will have iBGP peering relationships with the edge routers. It’s job is to advertise the route(s) that should be blackholed. Using our example, if an attack is taking place against the web server, the trigger router can advertise a route with the IP address of the web server (destination-based RTBH routing) or IP address(es) of the attackers (source-based RTBH routing) with the necessary community or tag.
• When the edge routers receive this advertisement, they will start dropping traffic to the target or from the attackers, depending on what type of RTBH routing is configured.
• When the attack has passed, the trigger router withdraws the route advertisement and everything goes back to normal.

Configuring Destination-based RTBH Routing

To drive home the concept, let’s look at a real example by configuring destination-based RTBH routing on Cisco routers.

Our lab setup for this example is as shown below (GNS3 screenshot):

ER1 and ER2 are edge routers belonging to an ISP. TR1 will serve as the trigger router. PE1 is the ISP router that connects Customer_X to the ISP’s network (via CE1). WS1 is a web server on the customer network that will serve as the target address of the DDoS attack.

Step 1: Configure discard route on edge routers

To configure a discard route, you need to pick an address that is not in use on the network. A good example is the 192.0.2.0/24 IP subnet which is a Special-Use IP address block. In our case, let’s use 192.0.2.254 as the address to use in the discard route.

Therefore, the configuration on ER1 and ER2 will be as follows:

ip route 192.0.2.254 255.255.255.255 null0

Step 2: Configure RTBH BGP policy on edge routers

Let’s assume that based on policy, any route that is advertised with a community of 999 should be discarded.

On the edge routers (ER1 and ER2), we will configure the following:

ip community-list 10 permit 999
!
route-map RTBH-POLICY permit 10
 match community 10
 set ip next-hop 192.0.2.254
!
router bgp 65535
 neighbor 192.168.123.254 remote-as 65535
 neighbor 192.168.123.254 route-map RTBH-POLICY in
!

In the above configuration, we created a community list (10) to match the community of 999. This community list is then used in a route map (RTBH-POLICY) so that the next hop of advertised routes with that community will be set to 192.0.2.254 (the address we used in the discard route). Finally, we created a BGP peering relationship with the trigger router (192.168.123.254) and applied the route map to that router.

Note: There should be full-mesh iBGP between ER1, ER2, and PE1 so you should configure other BGP neighbors as necessary. Also, the routers need to advertise their networks into the BGP network. ER1 should advertise 41.11.11.0/29, ER2 should advertise 41.12.12.0/29 and PE1 should advertise 41.14.14.0/29.

Step 3: Configure the trigger router

This is the router that will direct the edge routers to take action during an attack. The router will be the one that sets the community on routes that should be blackholed.

Therefore, the configuration to add on TR1 is as follows:

route-map RTBH-POLICY permit 10
 match tag 999
 set community 999 no-export
!
router bgp 65535
 neighbor 192.168.123.1 remote-as 65535
 neighbor 192.168.123.2 remote-as 65535
 neighbor 192.168.123.1 send-community
 neighbor 192.168.123.2 send-community
 redistribute static route-map RTBH-POLICY

In the configuration above, routes that have a tag of “999” will have their community set to 999 and “NO_EXPORT”. This route map is then applied to static routes redistributed into BGP.

Tip: Apart from setting the community to 999, we have also set the well-known community “NO_EXPORT” so that the routes that match the RTBH policy are never advertised beyond the ISP’s Autonomous System (AS).

Step 4: Test Scenarios

Step 4.1: No attack

In the first test case, there is no attack going on. We can ping from AT1 and AT2 to WS1 and we will see that the traffic is allowed.

We can also check the route to WS1 on the edge routers:

Step 4.2: Attack from AT1 and AT2 to WS1

Let’s assume AT1 and AT2 now launch an attack against WS1. To simulate this attack, we will issue a continuous ping to the web server from both hosts.

Now, the customer detects that they are under attack and they request help from the ISP. They don’t mind the web server going offline as long as other resources in their network are not affected.

In this case, an administrator on the ISP network, goes to the trigger router and creates the following route:

ip route 41.14.14.5 255.255.255.255 null0 tag 999

If we check the ping on AT1 and AT2, it will have started failing evident by the ICMP destination unreachable messages:

Note: You may want to stop the routers from sending ICMP destination unreachable messages and you can configure the “no ip unreachables” command under the Null0 interface.

When we check the route to WS1 on the edge routers, we will see that it is pointing to the discard address (192.0.2.254) which will be routed to the null0 interface.

The show ip cef command shows us that this route is eventually routed to the Null0 interface:

Since we were specific with our static route, other IP addresses in the 41.14.14.0/29 network (e.g. the IP address of CE1) should still be accessible:

Step 4.3: End of attack on web server

When it has been determined that the attack against WS1 has ended, the ISP administrator just needs to go to the trigger router and remove the static route configured:

no ip route 41.14.14.5 255.255.255.255 null0 tag 999

Testing again from any of the attack hosts, we see that the web server is reachable again:

Conclusion

This brings us to the end of this article where we have discussed what DDoS attacks are (attacks that aim to consume resources) and also highlighted some ways through which these kind of attacks can be defeated including application layer hardening, network layer protection and cloud-based DDoS solutions. We pointed out that application layer hardening and cloud-based DDoS solutions may be more suitable for end customers while ISPs should implement network layer protection.

We mentioned two ways through which Network layer protection can be implemented including ACLs and black hole routing. While both solutions are effective as they drop DDoS attack traffic at the edge of the network, ACLs may not be scalable.

We then focused on black hole routing, specifically RTBH routing which uses a trigger router to instruct edge routers to drop unwanted traffic. RTBH routing can be of two types: Source-based (drop attacker traffic) and Destination-based (drop all traffic to target). While source-based RTBH routing may be more effective because only the attacker’s traffic is dropped, it is not always feasible. As such, destination-based RTBH routing is more probable.

We concluded by looking at an example of configuring destination-based RTBH routing. The configuration for source-based RTBH routing is similar except that Unicast Reverse Path Forwarding (uRPF) also needs to be implemented on the edge routers.

I hope you have found this article insightful. Please feel free to add feedback or ask questions in the comment section below.

[thrive_leads id=’12481′]