In this article, we will consider Remotely Triggered Black Hole (RTBH), a technique that can be used to reduce the impact of Denial of Service attacks on networks. We will look at the two types of RTBH, destination-based and source-based.
There are various techniques that can be employed by network administrators to mitigate DoS attacks. One technique is to use access lists: when a DoS attack is taking place, add an access control entry to deny the attack. The problem with this technique is that it is not scalable.
Another technique is RTBH, which simply provides a means to black hole the traffic to a particular destination (destination-based) or from a source address/network (source-based).
In this first part of the article, we will be looking at how to configure destination-based RTBH on the Cisco IOS.
When you are dealing with a normal DoS attack, there is a higher chance that you will be able to determine the source of the attack than when you are dealing with a Distributed DoS (DDoS). In either case, the target of the attack is usually known and it is this target system that destination-based RTBH focuses on.
By using destination-based RTBH, instead of the DoS attack crippling the entire network and affecting other services, all traffic destined to the target is black holed. This means both the attacker’s traffic and other legitimate traffic to the target system are dropped.
The diagram below, which is available from Cisco, illustrates how destination-based RTBH works:
In the above diagram, the following devices are illustrated: the target system, the attackers, the edge routers (PE) and a trigger router. Destination-based RTBH can be explained in the following points:
- The trigger router and edge routers have iBGP peering relationships. If a route reflector is configured for the edge routers, then the trigger router only needs to peer with the route reflector.
- The edge routers have a static route for an unused IP address space (e.g. 192.0.2.1) pointing to the null0 interface.
- When an attack occurs, a network administrator configures a static route for the target address on the trigger router. This trigger router is then configured to advertise the static route, setting the next-hop of that route to the unused IP address configured on the edge routers.
- When the edge routers receive this route advertisement, the next-hop for that target address points to the unused IP address which is in turn configured to point to null0. Therefore, any traffic to the target address sent to the edge routers is effectively forwarded to null0, i.e. black holed.
- When the attack passes, the network administrator only has to remove the static route configured on the trigger router so that the route is withdrawn and traffic can be forwarded to the target system again.
To see this in action, we will use the following simplified lab setup:
In our scenario, we will assume the Edge router and the Trigger router are in AS1 and they will form an iBGP peering relationship.
Let’s start with the configuration on the trigger router. Apart from the BGP peering with edge routers, we also need to configure a “template” on the trigger router which will be used to forward traffic to the unused IP address. This template will be in the form of a route map which will match a certain criteria (e.g. route tag) and then set specific attributes like the next-hop, local preference, origin and community.
The local preference and origin attributes are set so that the route advertised by the trigger router can be preferred over other routes. The community attribute can be set to restrict how the recipient edge routers advertise that route.
The configuration on the trigger router is as follows:
interface Ethernet0/0 ip address 192.168.20.2 255.255.255.0 ! route-map TRIGGER permit 10 match tag 999 set ip next-hop 192.0.2.1 set local-preference 200 set origin igp set community no-export route-map TRIGGER deny 20 ! router bgp 1 neighbor EDGE-RTRS peer-group neighbor EDGE-RTRS remote-as 1 neighbor EDGE-RTRS send-community neighbor 192.168.20.1 peer-group EDGE-RTRS redistribute static route-map TRIGGER ! ip route 192.0.2.1 255.255.255.255 null0
In the above configuration, I have used the BGP peer-group feature so that I can group all edge routers together and apply similar policies to them. This will come in handy in a real scenario where there are multiple edge routers.
With this configuration on the trigger router, when a static route with tag 999 is advertised to other BGP peers, the next-hop will be set to 192.0.2.1, with a local preference of 200, origin of “IGP” and “no-export” community.
We can now configure the edge router as follows:
interface Ethernet0/0 ip address 192.168.20.1 255.255.255.0 ! interface Ethernet0/1 ip address 192.168.10.1 255.255.255.0 ! interface Ethernet0/2 ip address 10.0.0.1 255.255.255.0 ! router bgp 1 neighbor 192.168.20.2 remote-as 1 ! ip route 192.0.2.1 255.255.255.255 null0
The configuration on the attacker and target is just basic IP addressing configuration with the default gateway pointing to the edge router. The target has an IP address of 10.0.0.100 while the attacker has an IP address of 192.168.10.100.
Now let us test this configuration. First let us confirm that our BGP session is up between the edge router and the trigger router:
Next, we will simulate a DoS attack by sending large ping packets with a high repeat count from the attacker to the target.
As the administrator, we notice that the target is being attacked, so we then configure a static route on the trigger router for the target’s IP address with a tag of 999:
ip route 10.0.0.100 255.255.255.255 null0 tag 999
Because this route matches the TRIGGER route-map, it will be redistributed via BGP to the edge router with the BGP attributes we configured:
As shown above, 10.0.0.100 now points to 192.0.2.1. But based on the configuration on the edge router, 192.0.2.1 points to null0. In mathematical terms, if A=B and B=C, then A=C. This means that by recursive routing, the route for 10.0.0.100 will now point to null0 on the edge router. We can see this by looking at the CEF table for that route:
Once the edge router receives that route from the trigger router, it now replies with unreachable ICMP packets to the attacker informing it of the reason for the drop.
To save CPU resources on the edge routers, we can configure it not to send ICMP unreachable messages, i.e. silently drop the traffic.
interface Null0 no ip unreachables
Note: There may be instances when you don’t want to turn off ICMP unreachable messages, maybe for logging purposes, so you can just rate-limit those ICMP unreachable packets.
Now when we repeat the ping from the attacker to the target, notice that there are no ICMP unreachable messages:
When the attack has passed, all we have to do is remove the static route we configured on the trigger router and it will withdraw that route from the BGP process. Traffic to the target will once again be allowed.
In this article, we have looked at how to configure destination-based Remotely Triggered Black Hole on the Cisco IOS. The disadvantage of this form of RTBH is that it denies both malicious and legitimate traffic to a destination.
In the next article, we will look at source-based RTBH which, from a functional perspective, may be more suitable than destination-based RTBH, but which may not always be achievable.
I hope you have found this article insightful and I look forward to the next one in the series.
References and Further reading
- Remotely Triggered Black Hole Filtering – Destination Based and Source Based: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
- RFC 5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF): https://tools.ietf.org/html/rfc5635