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 0.0.0.140 neighbor 10.0.0.70 remote-as 65140 neighbor 10.0.0.70 port 1179 neighbor 172.16.141.2 remote-as 65141 ! address-family ipv4 unicast neighbor 10.0.0.70 allowas-in neighbor 10.0.0.70 route-map blackhole-in in exit-address-family ! 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 192.0.2.1The ce-router peers with the upstream service provider router (sp-router 172.16.141.2) as well as with sFlow-RT. A route-map is used to filter updates from sFlow-RT (10.0.0.70), matching the well-known blackhole community 65535:666, and setting the null route next-hop 192.0.2.1. 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 (10.0.0.70), see Switch configurations.
Run the DDoS mitigation application on server 10.0.0.70 using docker:
docker run --net=host sflow/ddos-blackhole -Dddos_blackhole.router=10.0.0.140 -Dddos_blackhole.as=65140Alternatively, 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:
wget https://inmon.com/products/sFlow-RT/sflow-rt_3.0-1460.deb dpkg -i sflow-rt_3.0-1460.deb /usr/local/sflow-rt/get-app.sh sflow-rt ddos-blackholeEdit the configuration file, /usr/local/sflow-rt/conf.d/sflow-rt.conf:
bgp.start=yes ddos_blackhole.router=10.0.0.140 ddos_blackhole.as=65141Next, start the daemon:
service sflow-rt startIn either case, the remainder of the configuration is handled through the web interface, accessible via http://10.0.0.70:8008/
Click on the Settings tab and upload the following IP Address Groups file groups.json:
{ "external": [ "0.0.0.0/0" ], "private": [ "10.0.0.0/8", "192.168.0.0/16" ], "multicast": [ "224.0.0.0/4" ], "exclude": "172.16.0.0/12" "web": [ "172.16.140.0/24" ] }The groups identify addresses that are external (possible attackers) and local (possible targets). By default, traffic to the external, private, 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 172.16.140.1The 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 10.0.0.140 41692 2017-06-17T00:18:13+0000 INFO: DDoS blocking 172.16.140.1 2017-06-17T00:20:25+0000 INFO: DDoS allowing 172.16.140.1The 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.