Remotely-Triggered Black Hole (RTBH) Routing
By stretch | Monday, July 6, 2009 at 5:05 a.m. UTC
Remotely-Triggered Black Hole (RTBH) routing is an interesting application of BGP as a security tool within service provider networks. One common use is mitigation of distributed denial of service (DDoS) attacks, as this article will explore.
Pictured below is a (very) simplified service provider architecture.
Routers 1 through 4 compose the network core, and router 9 functions as a standalone "management" router for route injection. OSPF is running across the core to exchange internal routes. Each router in this core square also maintains an iBGP adjacency with the other core routers, and with router 9. The server at 172.16.10.100 represents the target of a DDoS attack.
Assume a DDoS attack is launched from the public Internet toward the customer server at 172.16.10.100. The throughput consumed is so excessive that the attack is impacting the entire internal infrastructure and must be blocked at the edge. Due to the distributed nature of the attack, we must block at the edge all inbound traffic destined for the victim. Rather than resorting to laborious and error-prone access lists, we can utilize BGP and RTBH to quickly achieve the desired result.
Step 1: Null route preparation
The first two steps in configuring RTBH should ideally be completed prior to an attack.
RTBH works by injecting a specially-crafted BGP route into the network, forcing routers to drop all traffic with a specific next-hop -- effectively creating a "black hole." We create a static route on all BGP routers for this next-hop address:
R1(config)# ip route 192.0.2.1 255.255.255.255 Null0
This route forces any traffic destined for 192.0.2.1/32 to be immediately dropped by the router. This route is added to all edge routers (R1 and R2) in our example lab.
Note that any IP address can be used for this black hole route; we use an IP from the reserved Test-Net range (see RFC 3330) here out of convenience, as this IP should never appear on a routed network.
Step 2: Route-map preparation
As with the first step, this configuration should also be completed prior to an attack.
A route-map is created to redistribute certain tagged static routes into BGP with a modified next-hop value:
R9(config)# route-map RTBH R9(config-route-map)# match tag 666 R9(config-route-map)# set ip next-hop 192.0.2.1 R9(config-route-map)# set origin igp R9(config-route-map)# set community no-export
This is the key component to RTBH: any route advertised to an edge router with a next-hop of 192.0.2.1 will force recursion to the static Null0 route we implemented in the prior configuration, and any matching traffic will be dropped.
Enable static route redistribution into BGP for the route-map to take effect:
R9(config)# router bgp 65100 R9(config-router)# redistribute static route-map RTBH
Step 3: Create a victim route on the management router
Once an attack is detected and the decision is made to block traffic, a static route for the victim address is created on the management router (R9):
R9(config)# ip route 172.16.10.100 255.255.255.255 Null0 tag 666
Ideally, we would like to simply advertise this route to the edge BGP routers, but a route cannot be advertised as having an invalid next-hop. So, we've added a tag value to ensure that our RTBH route-map redistributes the route into BGP with a modified next-hop. Note that the no-export community has been appended here to avoid accidentally exporting the route beyond the local AS.
With our victim route injected, we can verify that the edge routers now drop all traffic bound for that prefix:
R1# show ip route 172.16.10.100 Routing entry for 172.16.10.100/32 Known via "bgp 65100", distance 200, metric 0, type internal Last update from 192.0.2.1 00:06:14 ago Routing Descriptor Blocks: * 192.0.2.1, from 10.0.99.9, 00:06:14 ago Route metric is 0, traffic share count is 1 AS Hops 0 R1# show ip route 192.0.2.1 Routing entry for 192.0.2.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1
Of course, the victim is now unreachable, and we've effectively assisted the DDoS in accomplishing its goal. However we have protected our internal infrastructure (and other customers) from the flood of traffic, affording us time to better investigate and more eloquently mitigate the attack. As you might imagine, there are more advanced implementations of this method which can be used, as future articles will cover.
Thanks to Steinthor Bjarnason and his BRKSEC-2204 presentation at Cisco Live for inspiring this article!
Posted in Security
July 6, 2009 at 5:27 a.m. UTC
Nice explanation Stretch! I was familiar with this from CCIE-Sec study , but i didn't know the fact that we use "tags" in our advertised routes to mask the null route that we add as the next hop... Thanks! :)
July 6, 2009 at 10:27 a.m. UTC
By combining the standard RTBH with uRPF loose-check on edge interfaces, the blackholing system can be utilized to block source IPs, which is far more operationally useful than mere destination-based blackholing, for the reason you mention above. This mechanism is called source-based remotely-triggered blackholing, or S/RTBH.
You're missing the iBGP statements on both the trigger and the edge routers, which should be configured in such a way that the blackholing edge router is a route-reflector client. Also, the communities should be 'no-advertise, no export, additive'.
Finally, note that the reason BGP is used for blackholing is because it's the only routing protocol which allows one to set an arbitrary, non-connected next-hop for any given prefix.
July 6, 2009 at 10:57 a.m. UTC
July 6, 2009 at 8:16 p.m. UTC
Initially I was confused by this method. But then I'm a network rookie.
It seems just as easy to put the static route 'ip route 172.16.10.100 255.255.255.255 Null0 ' on R1 & R2.
But I think what you are describing is setting up a method in advance to allow you to make a single change on the management router, and blackhole traffic to a specified IP. In other words, you are configuring a security method in advance to quickly deny traffic at the edge to a target server. That way, doesn't matter how many edge routers you have, will be denied at the edge for all your edge routers. And, a single change is less error-prone during an emergency.
July 7, 2009 at 9:06 a.m. UTC
Nice method. We have used it on our Juniper infrastructure. But anyway two notes. 1.Your external links are still heavily loaded, forwarding traffic to the victim. (Uplinks usually "thinner" than internal infrastructure). If possible write the abuse letter to the traffic originator or uplink providers. 2. Sometimes there is another method to stop the DDoS. It is shutting down the access port where the victim connected. That in some cases triggers the attack to stop.
July 7, 2009 at 3:57 p.m. UTC
Ken Johnson: I think when routers are under excessive attack it is hard to access them remotely by ssh/console because OS prioritizes ssh/console/telnet as the last, but on other hand routing updates have high priority even have reserved bandwidth in some cases.
Correct me if I am wrong please.
July 8, 2009 at 6:02 a.m. UTC
Hello, thanks for the writeup, I am planning to implement exactly this setup. The only difference is that I tried to avoid the extra router by setting it up on a Linux machine with Quagga, but with limited success this far, because Quagga does not understand route tags. Maybe we will just have to use one of our older Cisco routers for this purpose.
July 8, 2009 at 8:14 a.m. UTC
It is true that this is a method to protect for low value DDOS attacks. A more elegant solution for low value DDOS is to send the bad traffic not to null0 but rather to a cleaning system which performs traffic analysis and reinjects in the network the cleaned traffic.
If the uplinks are congested the only way to escape is to announce the /32 prefix with an aggread community with your SP in order to have the traffic filtered. Most SP have a community for which they will perform blackholing; This mechanism and the SP to SP aggreements can stop the DDOS close to the source.
July 8, 2009 at 9:33 a.m. UTC
Really nice explanation :)
Regarding Quagga/Zebra then it is correct that you cannot use tags to identify the static routes to be blackholed. Another way is to inject them directly into BGP and then use a prefix list in the route map to pick up the routes and tag them correctly
(might be slightly different syntax as I could not test this. Also, you might need to create a static route to null for the address in order for bgp to pick it up)
router bgp 65100 ! The network/host to block network 172.16.10.100/32 neighbor 10.0.99.x route-map RTBH out ! Match the network/host in the prefix list ip prefix-list PLIST permit 172.16.10.100/32 route-map RTBH match ip address prefix-list PLIST set ip next-hop 192.0.2.1 set origin igp set community no-export
July 23, 2009 at 6:41 p.m. UTC
chicken or the egg ?
August 14, 2009 at 6:11 a.m. UTC
Nice explanation. I agree with Roland and attaching uRPF loose with RTBH shall trigger source based black holing.
January 6, 2010 at 11:06 a.m. UTC
http://www.nanog.org/meetings/nanog23/presentations/greene.pdf slide 24 to slide 34
November 26, 2010 at 12:28 a.m. UTC
Is there a way to make it so that when you add the route to the trigger server it automatically handles sending the route with the proper blackhole community up to the upstream provider(s)?
December 28, 2011 at 8:50 a.m. UTC
Hi, what if I have already static routes to Null0, because they needed in order to be announced via eBGP. Will traffick for these networks be dropped?
August 29, 2012 at 7:59 p.m. UTC
How would the trigger device know if there is an DDoS attack to the customer's server (e.g. mail server)?
December 17, 2012 at 5:54 a.m. UTC
March 7, 2013 at 9:35 a.m. UTC
That was an amazing demonstration, thanks alot it really helped!
July 6, 2013 at 1:29 a.m. UTC
I am kinda new to this subject. So this is probably a dumb question but is the 192.0.2.1 ip address acting like a dummy address? I don't see it in the topology.
October 9, 2013 at 5:19 p.m. UTC
Nice writeup on RTBH approach and the other posters comments and ideas are excellent too. One thing to consider if used is the platform's capability for EEM applet and TCL - alias commandd and config snippet files works too, this way you can automate when to turn it on and off and "variable - ize" the victim address into the script easily.
October 25, 2013 at 5:18 p.m. UTC
Are you able to perform Source Based RTBH with uRPF in loose mode?
March 19, 2014 at 12:46 p.m. UTC
Sourced based blackhole filtering doesn't really help you on DDoS where there may be literally tens of thousands of sources. Destination based is really your only option.
June 8, 2016 at 3:53 p.m. UTC
Hi, Can you please describe why the IGP origin has been set under route-map? Thanks
August 27, 2016 at 6:50 p.m. UTC
Very nice explanation. Thanks a lot.