HomeBlogThe Number of the Beast or the Practical usage of the Blackhole...

The Number of the Beast or the Practical usage of the Blackhole Community

Aug 1, 2017

BGP blackhole filtering is a routing technique used to drop unwanted traffic. Black holes are placed in the parts of a network where unwanted traffic should be dropped. For example, a customer can ask a provider to install black hole on its provider edge (PE) routers to prevent unwanted traffic from entering a customer’s network.

Unwanted traffic that floods networks and machines from many different sources is often intentionally generated by the distributed-denial-of-service (DDoS) attack. The goal of a DDoS attack is the depletion of resources (CPU, RAM, bandwidth) of a remote target so that the service becomes unavailable for legitimate users. Typical symptoms of a DDoS attack are excessive bandwidth utilization on a targeted network and services crashing on victim’s machines. At the time when the day-long DDoS attacks against a small organization are offered for as low as $100, with a 5-minute test DDoS attack free of charge (showing the attacker capabilities), the importance of having a reactive defense strategy against such attacks is hard to underestimate.

DDoS traffic should be blackholed (dropped) closest to the source of the attack. Blackholing is based on either the source or destination IP address. Remote black hole filtering based on the destination IP address is a commonly used technique. The ISP sets a permanent static route utilizing the unused prefix pointing to the null interface on its PE routers, e.g. 192.0.2.1/32. It is a precaution measure that ISP installs in advance along with building a trigger machine. The trigger machine is a router or Unix machine running BGP daemon that is a part of ISP infrastructure. It has established internal BGP (iBGP) sessions with PE routers.

Let’s say that a DDoS attack is launched against a customer web server with IP address 172.12.0.1. As soon as a customer asks an ISP to filter the currently running DDoS, the ISP creates a static route to the targeted prefix 172.12.0.1/32 on the trigger machine pointing to a null interface. The static route to 172.12.0.1/32 is then redistributed via iBGP sessions from the trigger to PE routers but with the next hop changed to the IP 192.0.2.1. As a result, all traffic to the IP address 172.12.0.1 is sent to the 192.0.2.1 thus is effectively being dropped by the null route on PE routers. When the DDoS attack is finished, the static route 172.12.0.1/32 is removed from the trigger machine and withdrawn via iBGP session from the PE routers.

The method mentioned above requires customers to send an email to a service provider, requesting manual configuration of the null static route for targeted prefix on a trigger machine when DDoS attack is launched. Subsequently, a customer needs to send an email requesting the removal of a static null route once the DDoS attack is finished. Although this method has been proven to work, it inserts a time delay into the attack mitigation process. Luckily, there is another, automated method for destination-based remote blackholing using Blackhole Community, which gives customers better control over the black holed prefixes.

The BGP blackhole transitive community is one of the well-known BGP communities defined in RFC 7999. The BGP blackhole community is attached to an announced prefix by an origin Autonomous System (AS) during a DDoS attack. Its purpose consists of signaling to a neighboring network that a neighbor router should discard all traffic destined for the received prefix with the attached BGP blackhole community. With this approach, customers can trigger blackholing of the targeted prefix by remote ISP routers, adding a simple configuration to their customer edge routers. In other words, blackholing can be initiated any time by customers requiring no cooperation with ISP during a DDoS attack. However according to RFC, accepting the blackhole community, or ignoring it, is a choice that is made by each operator. That is why accepting blackhole community must be agreed by both networks prior to advertising it.

The blackhole community is registered in the “BGP Well-known Communities” registry as 0xFFFF029A. The low-order two octets in decimal are 666. We can only speculate why the value 666 (the number of the beast from the Bible) was chosen for this purpose. Nevertheless, the value is commonly used with BGP blackholing by network operators. As for a length of the blackhole prefix, it should be as long as possible. This prevents discarding traffic sent to the IP addresses that are not under the DDoS attack. Typically the length of a blackhole prefix is /32 (a single IP address). In any case, the length of the announced blackhole prefix must be equal or longer than the length of the entire IP prefix assigned to a customer.

Below is a network topology that we use for testing of blackhole community usage. In our scenario, an attacker launched a DDoS attack against the customer web server (IP 198.51.100.2). If our configuration is correct as soon as the customer configures the commands below, DDoS traffic should be discarded on a router ISP. Traffic from the attacker to IP address 198.51.100.1 should not be discarded.

NOTE: Altering the next-hop for blackhole services requires multihop on the EBGP sessions otherwise the route 198.51.100.2/30 won’t be selected as a best route and inserted into the routing table of an ISP router.

3. Additional Configuration on ISP PE Router

3.1. Restrict Customer to Advertise Only Authorized Prefix with Length from /24 to /32

Customer should only announce a prefix that is authorized to advertise (198.51.100.0), with the length from /24 to /32. For this reason ISP needs to filter BGP announcements carrying the blackhole community that are not authorized.

ip prefix-list AS64501-in seq 5 permit 198.51.100.0/24 le 32

router bgp 64500neighbor 198.51.200.2 prefix-list AS64501-in in

3.2. Prevent ISP to send Blackhole Prefix to eBGP Peers

A BGP speaker receiving an announcement tagged with the blackhole community (ISP) should add no_export community as to prevent propagation of the blackhole prefixes to eBGP peers. We have already done it with the command under the route-map customer-in in the ISP configuration.

4. Testing

If the DDoS attack is not launched, the attacker can ping the IP address 198.51.100.2.

Once the DDoS attack is launched and detected by the customer, the customer adds the following lines to its router. Subsequently, once the attack is finished, the customer removes the lines from the configuration.

In this article we focused on the explanation of Destination-Based Remotely Triggered Blackhole Filtering using a trigger machine in an ISP infrastructure. We have gone further and practically configured and tested usage of blackhole community with destination IP address filtering. As a result, we have successfully stopped a DDoS attack against the customer web server, adding configuration only to a customer router.

We should note that there are some pros and cons associated with the use of the BLACKHOLE community. While this approach is widely supported by transit providers, accepting the blackhole community, or ignoring it, as mentioned above, is a choice that is made by each operator. The use of the community should be agreed by both networks.

While the approach allows to keep a network up during an attack, this is more of a mitigation technique, rather than protection. Although the use of the technique allows the wider network to stay up, ultimately the target machine is still going down.