Implementing Sinkholes to Defend Against DDoS Attacks (Blackhole Routing) | Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)

Another novel use of sinkhole technology is as a defense tactic against (distributed) denial-of-service attacks. In the "Background and Function" section earlier in this chapter, the first example given was the simplest form of this blackhole routing technique. Once the exact target of an attack has been identified, traffic destined for the IP address being targeted was diverted to the discard interface at the edge of the network, before traversing the final link to the target. This freed the target network from total disruption through link saturation, but still likely impacted performance network-wide, especially for adjacent customers that shared some of the carrier's edge topology with the target network. Today, large telecom carriers have architected their networks and included sophisticated versions of this defense measure as part of their overall network design philosophy. In many cases, the carriers are now able to use a traceback technique in order to locate the ingress points of the attack and blackhole the malicious packets there (at the ingress points themselves ) instead of allowing the attack to clog the carrier backbone all the way downstream to the target network's link. However, this traceback technique is largely unnecessary because the carriers' blackhole routes are customarily announced network-wide among their edge routers using a BGP community, thereby blackholing the malicious traffic at each ingress point, allowing them to blackhole attacks as they enter and (in many cases) avoid backbone and edge congestion altogether. Some have even extended the control and automation of this capability to the end customer through what are known as customer-triggered real-time blackholes.

Triggered Blackhole Routing

As mentioned above, many large ISPs have implemented a distributed, automated system for "triggering" blackhole routing on targeted IP addresses. The trigger may be initiated by the ISP or by customers, either manually or automatically. Triggered blackhole routing utilizes the simple sinkhole described earlier in the section "Background and Function." The sinkhole may be configured on all ingress (edge) routers within the ISP network where the ISP exchanges traffic with other providers or customers. When an attack against a network target is identified, the ISP or the customer may announce the attacked prefix (or a more specific prefix) into the BGP routing table. The attacked prefix is tagged with a next hop that is statically routed to the discard interface on all edge routers, and propagated within the ISP's network via internal BGP (iBGP). Then, wherever the packets destined for the attacked prefix enter the ISP network (the ingress point), they are immediately sent to the discard interface on the closest router announcing the attacked prefix.

In order to implement the distributed blackhole mechanism, an ISP must complete the following steps:

Select a nonglobally routed prefix, such as the Test-Net (RFC 3330) 192.0.2.0/24, to use as the next hop of any attacked prefix to be blackholed. Using a prefix of length 24 allows you to use many different IP addresses for specific types of blackhole routing. You may wish to differentiate between customer, internal, and external blackhole routes.
Configure a static route on each ingress/peering router for 192.0.2.0/24, pointing to the discard interface. For example:
```
 ip route 192.0.2.0 255.255.255.0 Null0 
```

Configure BGP and policy route-maps to announce a prefix to be blackholed:

 router bgp XXX redistribute static route-map static-to-bgp # Route-map is a policy mechanism to allow modification of prefix # attributes, or special filtering policies route-map static-to-bgp permit 10 match tag 199 set ip next-hop 192.0.2.1 set local-preference 50 set community no-export set origin igp

In the example configuration, we are redistributing static routes into BGP that match "tag 199" (see below), setting the next hop to an IP address that is routed to the discard interface, setting the local preference to 50 (less preferred), and ensuring we do not leak these routes to any of our external peers (no-export).

Once this basic configuration is done, the trigger can be initiated by the ISP entering a static route for the attacked prefix (or host) to be blackholed, for example:

 ip route 172.16.0.1 255.255.255.255 192.0.2.1 Null0 tag 199

The static route above is the "trigger" that kicks off the blackhole routing process. The router on which this route is configured will announce the route through iBGP to all internal routers, including edge routers. Any router with a static route to the discard interface for 172.16.0.1/32 will immediately blackhole traffic locally.

The ISP may wish to set up automated triggering through BGP as well, so a BGP customer could trigger the blackhole route independent of ISP intervention. This is the most powerful aspect of triggered blackhole routing. The configuration on the ISP side is slightly different in that communities and ebgp- multihop are used to properly receive and tag the routes learned from the customers. The basic configuration on the ISP side looks like this:

 router bgp XXX # Route-map is simply a policy mechanism to massage routing information such # as setting the next hop neighbor < customer-ip > route-map customer-in in # prefix-list is a static list of customer prefixes and mask length that # are allowed. Customer should be allowed to announce down to a single host # in their prefix(es) such as 172.16.0.1/32 neighbor < customer-ip > prefix-list 10 in # ebgp-multihop is necessary to prevent continuous prefix announcement and # withdrawal neighbor < customer-ip > ebgp-multihop 2 # Now we define the route-map for policy match and setting the blackhole # next hop route-map in-customer permit 5 # the customer sets this community on their side, and the ISP matches on its # side. XXXX would likely be the customer ASN, and NNNN is an arbitrary number # agreed on by the ISP and the customer match ip community XXXX:NNNN set ip next-hop < blackhole-ip > set community additive no-export

The ISP already has the < blackhole-ip > statically routed to discard interfaces throughout the network, so as soon as the customer announces the prefix to blackhole, the ISP redistributes that internally and traffic to this prefix is blackholed at the edge of the ISP network.

The basic customer configuration looks like this:

 router bgp XXXX (customer's ASN) # the customer will install a static route, which is redistributed into BGP # here redistribute static route-map static-to-bgp # just like the ISP, use a route-map to set and match specific prefix # attributes route-map static-to-bgp permit 5 # match the arbitrary tag, agreed on by the customer and the ISP match tag NNNN set community additive XXX:NNNN

Once the BGP configuration is in place, the customer need only install a static route for the prefix being attacked.

 # NNNN is the tag, agreed on by the customer and the ISP ip route 192.168.0.1 255.255.255.255 Null0 tag NNNN

With some very basic configuration in BGP, and the help of your ISP, you now have a very fast method to respond to denial-of-service attacks against a single host, or an entire prefix.

Note	Be sure to check with your ISP's technical contact before implementing your blackhole-triggering solution as ISP implementations of this concept differ slightly.