DDOS: duck and cover!
DDOS, the volumetric ones, can be a real pain. As soon as it hits, the links you have towards the rest of the world can become saturated and the entire company can come to a grinding halt. Here’s a tip on how to weather the storm: duck and cover.
Imagine a scenario where a company, that is located in three different datacenters, suffers from a DDOS:
In the example above, only one host in DC2 is under attack. The DDOS traffic that is inbound into the AS is coming from all IP transits and Internet exchanges. The combined amount of traffic is enough to clog several core links and wipe DC2 of the map.
So you've spotted the host that is under attack, now what? Log into every router and create a policer or something? Seriously, how nice would it be if you could log in to just one router, configure 1 thing, and instantaneously stop the problem of the links being saturated?
If there were such a knob, we could easily duck and cover. If we can stop all the traffic at our Internet edge, things would look like this:
In the picture above, all the routers facing the Internet drop the packets that are send to the host that is under attack. This way, even though the host is down, most of the business can continue. So, what the knob? How can we duck and cover?
How to make it so that you only have to issue one command during an attack? Juniper discard interface and a policy that changes the next-hop to the discard interface. Let's look at an example with two routers;
In the example above, the R1 router advertises a /32 route towards R2. The BGP policy alters the next-hop to another address. The next-hop is not changed to self, instead, the next-hop IP is changed to the destination address of the discard interface configured on R2.
R2 receives the route from R1 and checks its routing table. R2 sees that the next-hop of the received route corresponds to the discard interface destination. R2 will proceed to immediately install a discard route for the received prefix.
By configuring all the other Internet facing routers with the exact same discard interface, we can instantaneously (sort-of) raise a shield.
When you are running a big network, this can be a life saver. If you write it up in a procedure and distribute it to your colleagues, people around you will also start to feel more comfortable on what action to take when a DDOS hits.
So, where to start? Back to the example with two routers. First, we configure a discard interface on R2:
set interfaces dsc unit 0 description discard-interface set interfaces dsc unit 0 family inet address 10.0.0.1/32 destination 18.104.22.168
After this, we move over to R1 and create an additional BGP policy, or we extend an existing one with a blackhole term;
set policy-options policy-statement blackhole-stuff term blackhole-32 from protocol static set policy-options policy-statement blackhole-stuff term blackhole-32 from tag 635 set policy-options policy-statement blackhole-stuff term blackhole-32 then next-hop 22.214.171.124 set policy-options policy-statement blackhole-stuff term blackhole-32 then accept set policy-options policy-statement blackhole-stuff term accept-rest then accept
After the creation of the policy, we activate it for the relevant BGP group:
set protocols bgp group BGP export blackhole-stuff
As soon as you spot an incoming DDOS, all we have to do is create a static route on the R1 router. The static route will need to match the policy we created before;
set routing-options static route 126.96.36.199/32 discard set routing-options static route 188.8.131.52/32 tag 635
Right after the configuration of the static route, the following will happen:
Let's move over to the command line and see if we can verify this:
play@MX480-TEST-RE0:R1> show route advertising-protocol bgp 184.108.40.206 220.127.116.11 inet.0: 29 destinations, 29 routes (25 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 18.104.22.168/32 22.214.171.124 100 I
That was the advertisement from R1 towards R2. To see what R2 did with the route, we move over to R2:
play@MX480-TEST-RE0:R2> show route 126.96.36.199 inet.0: 29 destinations, 51 routes (27 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 188.8.131.52/32 *[BGP/170] 00:13:26, localpref 100, from 184.108.40.206 AS path: I, validation-state: unverified > to 220.127.116.11 via dsc.0
The route is installed to the discard interface, so all the traffic destined towards the 18.104.22.168/32 host will be dropped.
There is one more thing we can do. We can apply a firewall filter with the ‘count’ action to the discard interface. This way, we can see whether or not the router is actually using the discard interface to discard packets. To configure this:
set interfaces dsc unit 0 family inet filter output log-dsc-interface set firewall filter log-dsc-interface term 1 then count discard set firewall filter log-dsc-interface term 1 then log
Afterwards, we can see the firewall filter counting each packet that it has discarded:
play@MX480-TEST-RE0:R2> show firewall Filter: __R2/log-dsc-interface Counters: Name Bytes Packets discard 588 7
Copy paste the R2 configuration to all the routers with an Internet connection, and the creation of a static route on R1 will be enough to start filtering the DDOS traffic. Make sure that the discard interfaces will have the same destination on all the routers.
This is not the most optimal defense, but it’s something. If you combine it with a flow collector, gathering data from all your edge routers, you will be able to spot a DDOS extremely fast. Alternatively, you could create bandwidth sensors throughout your network with >95% warnings. This is not as elegant and informative, but to a certain degree it can be effective as well.
After setting this up, a next step could be figuring out if your IP transits allow you to control traffic using communities. Most IP transits can give you a list of communities, some of which will make their routers do something I just described in the above. The thing is, if you can make your IP transit drop the traffic for you, that traffic will not even hit your AS. Even though stopping traffic there is better, it will not work on Internet exchanges. Maybe more on this later!