Monday, June 19, 2017

Remotely Triggered Black Hole (RTBH) Routing

The screen shot demonstrates real-time distributed denial of service (DDoS) mitigation. Automatic mitigation was disabled for the first simulated attack (shown on the left of the chart).  The attack reaches a sustained packet rate of 1000 packets per second for a period of 60 seconds. Next, automatic mitigation was enabled and a second attack launched. This time, as soon as the traffic crosses the threshold (the horizontal red line), a BGP remote trigger message is sent to router, which immediately drops the traffic.
The diagram shows the test setup. The network was built out of freely available components: CumulusVX switches and Ubuntu 16.04 servers running under VirtualBox.

The following configuration is installed on the ce-router:
router bgp 65140
 bgp router-id
 neighbor remote-as 65140
 neighbor port 1179
 neighbor remote-as 65141
 address-family ipv4 unicast
  neighbor allowas-in
  neighbor route-map blackhole-in in
ip community-list standard blackhole permit 65535:666
route-map blackhole-in permit 20
 match community blackhole
 match ip address prefix-len 32
 set ip next-hop
The ce-router peers with the upstream service provider router (sp-router as well as with sFlow-RT.  A route-map is used to filter updates from sFlow-RT (, matching the well-known blackhole community 65535:666, and setting the null route next-hop The route-map also ensures that only /32 prefixes are accepted. In production, the route-map should also filter out the addresses of critical infrastructure (router IP addresses etc.).

An additional route-map will typically be required to select the blackhole routes to propagate upstream, re-mapping the community to meet the upstream service provider's policy, e.g. Hurricane Electric uses community 6939:666.

In addition, the ce-router is configured to send sFlow to the controller (, see Switch configurations.

Run the DDoS mitigation application on server using docker:
docker run --net=host sflow/ddos-blackhole -Dddos_blackhole.router=
Alternatively, an RPM or DEB packaged version of sFlow-RT can be downloaded and installed on the server and the ddos-blackhole application can be installed. For example, on Ubuntu:
dpkg -i sflow-rt_3.0-1460.deb
/usr/local/sflow-rt/ sflow-rt ddos-blackhole
Edit the configuration file, /usr/local/sflow-rt/conf.d/sflow-rt.conf:
Next, start the daemon:
service sflow-rt start
In either case, the remainder of the configuration is handled through the web interface, accessible via

Click on the Settings tab and upload the following IP Address Groups file groups.json:
 "external": [
 "private": [
 "multicast": [
 "web": [
The groups identify addresses that are external (possible attackers) and local (possible targets). By default, traffic to the externalprivate, multicast and exclude groups will not trigger actions. Any additional group names, in this case web, are blackhole candidates.

Note: Only traffic from the external group to backhole candidate groups (web) is shown on the Charts tab (and considered for DDoS detection and mitigation).

The following command on sp-host simulates an ICMP flood attack on ce-host:
ping -f
The following messages should appear in the sFlow-RT logs:
2017-06-17T00:17:39+0000 INFO: Listening, BGP port 1179
2017-06-17T00:17:40+0000 INFO: Listening, sFlow port 6343
2017-06-17T00:17:40+0000 INFO: Listening, HTTP port 8008
2017-06-17T00:17:40+0000 INFO: app/ddos-blackhole/scripts/ddos.js started
2017-06-17T00:17:40+0000 INFO: app/ddos-blackhole/scripts/stats.js started
2017-06-17T00:17:46+0000 INFO: BGP open 41692
2017-06-17T00:18:13+0000 INFO: DDoS blocking
2017-06-17T00:20:25+0000 INFO: DDoS allowing
The screen capture at the top of this article shows that the time between the attack being launched and successfully blocked is just a few of seconds.