netoops!

Remote Triggered Black Hole is a very useful Security Tool that can be extremely helpful during DDoS Attacks, it leverages on BGP Communities and help us drop tarffic before it reaches our Infrastructure.

Many could (understandably) argue that by blackholing it mens that the DDoS was successful and you lose, but thats not entirely true, there are many situations where its worth sacrificing one of your services in order to save all of the others, or perhaps the target of the attack is an IP that is not even in use, nonetheless, traffic still reaches your network and exhaust your resources, this would be another perfect candidate to be Blackholed.

Ideally you would implement RTBH with your ISP, most of the big players Support Blackhole Communities, if that is not an option, you could still implement it at your own Edge. Implementing it with your ISP means that traffic will be dropped all together before reaching your network, applying it at your Edge would protect the Backend Infrastructure, but could still Impact your Edge (eg: Volumetric attack).

On this example we will be spinning up 4 VMs: RTBH, Edge, ISP and Internet. The RTBH Instance will act as a BGP OOB Speaker, it will be running Ubuntu and BIRD as the BGP Daemon. The EDGE and ISP will be running JunOS, the “Internet” instance will be used to test the result of the Blackhole. More detail on each one to come.

VAGRANT

On this example I will be using Vagrant to spin up JunOS Routers and Ubuntu Instances. Vagrant is an interesting tool that helps you manage, build, destroy VMs, its is extremely powerful, you can spin up entirely Labs in minutes, its worth a look. I won’t be getting in details on how it works, but here’s a quick and very simple guide of how this Lab was setup:

vagrant plugin install vagrant-host-shell vagrant-junos
vagrant box add juniper/ffp-12.1X47-D15.4-packetmode
vagrant init

Considering that you already have Vagrant installed, this will add the Plugins needed to run the JunOS Instances, it will then download a vSRX in packet-mode (Meaning that Stateful is disabled, making it pretty much a pure Router). With that done, vagrant init should have added a Vagrantfile to your currently directory, by editing it and replacing the code by the following we should be good to go:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.define "edge" do |edge|
    edge.vm.box = "juniper/ffp-12.1X47-D15.4-packetmode"
    edge.vm.network "private_network", virtualbox__intnet: "edge_isp", auto_config: false
    edge.vm.network "private_network", virtualbox__intnet: "edge_rtbh", auto_config: false
  end

  config.vm.define "isp" do |isp|
    isp.vm.box = "juniper/ffp-12.1X47-D15.4-packetmode"
    isp.vm.network "private_network", virtualbox__intnet: "edge_isp", auto_config: false
    isp.vm.network "private_network", virtualbox__intnet: "isp_internet", auto_config: false
  end

  config.vm.define "rtbh" do |rtbh|
    rtbh.vm.box = "ubuntu/trusty64"
    rtbh.vm.network "private_network", virtualbox__intnet: "edge_rtbh", auto_config: false
  end

  config.vm.define "internet" do |internet|
    internet.vm.box = "ubuntu/trusty64"
    internet.vm.network "private_network", virtualbox__intnet: "isp_internet", auto_config: false
  end

end

All right, all we need to do now is run vagrant up and this will bring the 4 VMs up with the proper defined Network Interfaces.

BIRD
BIRD is a Linux Routing Daemon, as a RTBH Station, we will set it up as a OOB BGP Speaker, it will peer with our Edge Router, and its goal will be to Inject /32 Routes that we’d like to Blackhole.

Modern versions of the Linux Kernel let us create Multiple Routing Tables, we will use that feature and will create a RT dedicated to the Blackholed Routes, BIRD will then Sync its BGP Table with the RT that we created, whenever it see a new route it will Inject into BGP and advertise to Edge (Given that it match our Filter). Here’s a configuration example with comments. Using a dedicated RT for the Blackholed IPs helps with Management, Operation, Automation, etc. Checking what IPs you have blackholed is a matter of listing the RTBH Route Table.

# Setup eth1 IP address on same segment as our Edge Router
ifconfig eth1 10.0.0.100 netmask 255.255.255.0
#Create a new Route Table, call it RTBH with ID 100
echo "100   rtbh" >> /etc/iproute2/rt_tables
# Install BIRD
apt-get update
apt-get install bird

#Apply the BGP Configurations
cd /etc/bird
cp -p bird.conf bird.conf.bkp

BIRD will read the configuration from file /etc/bird/bird.conf, here’s the full configurations used with comments:

Here’s with will happen. we define a function called check_prefix(), we add to the function a List of the prefixes which we own and that contains IP that we may want to Blackhole at some point, we then make sure that only /32 IPs are advertised. This function will be called on our filter named EXPORT_BLACKHOLED_32. This filter will advertise only what is True from check_prefix(), and it will add a Community AS:666.

EDGE

Here at the Edge of our Network we will be running JunOS. This router will iBGP peer with our RTBH Instance, and will eBGP with our ISP. Here’s a simple configuration to illustrate our example:

#Interface configuration
set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.1/25
set interfaces ge-0/0/2 unit 0 family inet address 10.0.0.1/24

#Each one of these IP will be used to illustrate the Blackhole in operation
set interfaces lo0 unit 0 family inet address 203.0.113.130/32
set interfaces lo0 unit 0 family inet address 203.0.113.131/32
set interfaces lo0 unit 0 family inet address 203.0.113.132/32

#BGP Configuration
set protocols bgp advertise-inactive
set routing-options router-id 203.0.113.1
set routing-options autonomous-system 65001

#iBGP to BIRD (RTBH)
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.0.0.1
set protocols bgp group IBGP neighbor 10.0.0.100
set protocols bgp group IBGP import IMPORT-FROM-RTBH

# This import filter rule is to make sure that we don't receive anything other than /32 + blackhole community from the RTBH Station
set policy-options policy-statement IMPORT-FROM-RTBH term 1 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement IMPORT-FROM-RTBH term 1 from community BLACKHOLE
set policy-options policy-statement IMPORT-FROM-RTBH term 1 then accept
set policy-options policy-statement IMPORT-FROM-RTBH term 20 then reject

#EBGP to ISP
set protocols bgp group EBGP type external
set protocols bgp group EBGP local-address 203.0.113.1
set protocols bgp group EBGP neighbor 203.0.113.2 peer-as 65002
set protocols bgp group EBGP export EXPORT-TO-ISP

set policy-options community BLACKHOLE members 65001:666

#Define the Export Filter. Only our /25 prefix and the prefixes announced from BIRD, with the proper Community, will
# be advertised to our ISP.
set policy-options policy-statement EXPORT-TO-ISP term 1 from protocol static
set policy-options policy-statement EXPORT-TO-ISP term 1 from route-filter 203.0.113.128/25 exact
set policy-options policy-statement EXPORT-TO-ISP term 1 then accept
set policy-options policy-statement EXPORT-TO-ISP term 5 from community BLACKHOLE
set policy-options policy-statement EXPORT-TO-ISP term 5 then accept
set policy-options policy-statement EXPORT-TO-ISP term 20 then reject

set routing-options static route 203.0.113.128/25 reject

This configuration should be pretty straight forward. We should receive the routes advertised from the RTHB Station via BGP, the Import Filter will make sure that we only receive /32s that have the proper defined Blackhole Community set, this is to avoid a mistake on the BIRD Configuration and end-up announcing what it shouldn’t, which could be really bad :ˆ) The Edge Router will Advertise to the Internet our Service Prefix Range (203.0.113.128/25 in this example) + The Blackholed prefixes, anything else that we try to advertise to ISP will be dropped.

Note: In this example we are setting up RTBH with an Upstream ISP, and letting them drop the traffic. If your ISP does not support RTBH you can still use it on your own Edge Router, saving resources of your Backend Infrastructure, to do so it should be a matter of adapting the below ISP Configuration Section and apply it to your Edge Router.

ISP

Here we will simulate what the ISP would do with your traffic, each ISP will implement it on a different way, but the idea is the same, based on the Blackhole Community they should Drop traffic to the specified prefix/ip. Here’s an example of how I did it on our lab:

set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.2/25
set routing-options router-id 203.0.113.2
set routing-options autonomous-system 65002

set protocols bgp group EBGP type external
set protocols bgp group EBGP local-address 203.0.113.2
set protocols bgp group EBGP neighbor 203.0.113.1 peer-as 65001
set protocols bgp group EBGP import IMPORT-FROM-AS65001

set policy-options community BLACKHOLE members 65001:666
set policy-options community NO-EXPORT members no-export
set policy-options community NO-ADVERTISE members no-advertise

set policy-options policy-statement IMPORT-FROM-AS65001 term 1 from route-filter 203.0.113.128/25 exact
set policy-options policy-statement IMPORT-FROM-AS65001 term 1 then accept
set policy-options policy-statement IMPORT-FROM-AS65001 term 5 from community BLACKHOLE
set policy-options policy-statement IMPORT-FROM-AS65001 term 5 then community add NO-EXPORT
set policy-options policy-statement IMPORT-FROM-AS65001 term 5 then community add NO-ADVERTISE
set policy-options policy-statement IMPORT-FROM-AS65001 term 5 then next-hop reject
set policy-options policy-statement IMPORT-FROM-AS65001 term 5 then accept
set policy-options policy-statement IMPORT-FROM-AS65001 term 20 then reject

It should only accept our /25 prefix or the /32 with Blackhole Community, if the community 65001:666 is set, the Router will add the /32 with a next-hop Reject, meaning traffic to this IP will be dropped at the ISP Level, outside of your network, saving your network resources. The NO-EXPORT and NO-ADVERTISE communities is important to make sure that it won’t export the prefixes to be blackholed to any peer/upstream.

RESULT

Lets check it in practice. We will first show that we can reach all of our Service IPs (The ones on our Loopback interface). For that I will use the “Internet” instance, which is just an instance connected behind the ISP Router.

Now, lets go ahead and Trigger a Blackhole:

As you can see, 203.0.113.130/32 was added to the rtbh table, and to show as an example, I also added 203.0.113.131/32 into the Main Route Table, which should not be advertised Upstream as our configuration plan is to keep all blackholed IPs into a single rtbh namespace.

On the EDGE we can see that, as expected, we are learning a single /32 from BIRD, and it has the community 65001:666 set. So far so good. Now to the ISP Router:

We have our ISP Receiving our Service Prefix (/25), but also our Blackholed /32, which in turn it add a Next-Hop Type Reject, which will drop traffic to that IP before it reach us. Back to the Test Instance, lets check the results:

And Voilà. It works. Traceroute show traffic getting dropped at our ISP Router (198.51.100.1).

SUMMARY

I hope this can help someone looking to Implement a RTBH Solution in their Network, or even someone that’s trying to start with BIRD, which is a very powerful Solution. Bear in mind that this Post can be used as an example/idea, but each ISP implements RTBH in a different way, different Community Numbers, Single or Split BGP Sessions, etc..
RFC7999 tries to Standardise the Blackhole Community but not all ISP follows it yet, so Make sure to contact your ISP and see if they Support Blackhole and what kind of Setup they have.

Até a Proxima!