Now when we're looking at what is important in terms of the different routers that you have to pre configure this diagram gives you an example here. So very important is that we look at provider edge routers and then also what's called the trigger router and in this particular example which we will show the configurations you'll see that the dotted lines show which routers have the BGP updates and the heavier lines, the red lines, show the attack traffic and where they are sourced from. So the configuration steps are really very very simple-- you have a preparation step and that entails configuring all the edge routers with a static route to null zero. And remember that null zero means that the next hop is the discard interface and the packet would get dropped. So you have to use a reserved network address space. Reserved address space means that it should not be seen in the global internet. And both for IPv4 and IPv6 there is a number of these that are defined. For remotely triggered black hole filtering it is very common to use for IPv4 the test network which is the 192.0.2.0 slash 24 prefix and then in IPv6 there is an IANA assigned prefix from RFC 6666 which is the network 100 a slash 64. After you've configured the edge routers with a static no route to null 0 you also have to configure a trigger router. Now the trigger router does not have to be a beefy device. It can just be a very simple BGP speaking device. It needs to be part of the iBGP mesh and it is recommended that it be a dedicated router. So a dedicated device that just acts as the remotely triggered black hole filtering trigger router. Once you've pre-configured both the edge routers and a trigger router, you then wait until a specific DDoS event happens. Once the DDoS event happens you then have to activate the black hole. So you end up redistributing a host route for the victim network or IP address into BGP with the next hop set to 192.0.2.6. This route then is propagated using BGP to all BGP speakers. Then the receiving BGP speaker installs a victim network reachability via the 192.0.2.6 route and this allows all the traffic to the victim now to be set to null 0 (i.e. it gets dropped at the routers). This here shows a picture of what I was just describing. So when we look at destination based remotely triggered black hole filtering which is the first instantiation when this technique was first created we see that there's three specific steps. One is the preparation. The number two is triggering the black hole. And then three is what I didn't yet describe which is that once the distributed denial-of-service attack has ceased you then want to manually remove the static route from the trigger router so that all of the provider edge routers can then install the new valid routes to the target so that all traffic goes back and legitimately again gets routed to the target that was previously the victim. Now with destination based remotely triggered black hole filtering it's really really important to note that all traffic to the target is dropped even legitimate traffic so initially when this technique was created I mean it did solve the problem of all of the DDoS traffic that was being sent to the victim and filtering it but the problem was that no legitimate traffic to the victim could get through. So a follow-up, an improvement to the remotely triggered black hole filtering technique, was to do what's called source based RTBH so as we saw while dropping packets to the destination victim is important you do want to avoid dropping legitimate traffic. You want to be able to also react to source IP addresses to provide added options. So you want to be able to stop an attack without taking the destination victim totally offline and you want to be able to filter on specific command and control server IP addresses and also any known compromised hosts. So with source based RTBH you can drop packets at the network edge based on specific source IP addresses and this very much depends on a technique called unicast reverse path forwarding, shortened to uRPF. Okay let's take a look at some details of uRPF. It was originally created to scale BCP38 ingress filtering at ISPs and BCP38, as we all know, was to filter out source traffic that had spoofed IP addresses. It basically checks the routers forwarding information base for matching source IP address entries. So the original mode was called strict mode and in strict mode uRPF there were two checks that needed to be done: one is there a matching entry for the source in the routers forwarding table? And two is the same interface used to reach the source as where the packet was received on? Both checks had to pass for the packet to be forwarded. Now as an enhancement to handle asymmetric routing issues you also added a mode called loose mode and only one check is required here and that is "Is there a matching entry for the source in the routers forwarding table?" The loose mode uRPF provided the ISPs with the means to trigger a network-wide source-based black hole filter. So for source based RTBH we now rely on three distinct components: the black hole filtering, the remote trigger and the uRPF loose check. So with the black hole filter and the uRPF loose check now either the destination address or the source address that equals null zero gets dropped and of course with a remote trigger you end up having a prefix that's set to null zero on all routers across the network at iBGP speeds. So together with these three components we have a tool to trigger drops for any packets coming into the network whose source or destination equals null zero. So it allows for much better granularity when we're doing RTBH. This here shows a picture of how this would work and it's very similar to the previous diagram that we showed with destination based RTBH with a specific distinction and that distinction is using uRPF. So when we're looking at the preparation step, the trigger router is exactly the same as in the destination based RTBH but the difference comes in with the provider edge configuration where you also use loose mode uRPF on external interfaces. So then when you have a DDoS event in the triggering phase when you then add the static route in the trigger router what happens in the provider edge router is that all traffic from the source IP will fail loose uRPF checks and will get dropped. So with source mode RTBH it's an enhancement because only traffic from the attack sources get dropped and so some legitimate traffic will still go to the target victim There is also another enhancement you know as in any anything else as a technique gets more widely used you keep looking at, you know, where can you improve upon. So you always want to have more finely tuned control of where you drop the packets because the intent is to always try and not to drop legitimate traffic. So with BGP communities there's three parts to this: one is you have the static routes to Null0 on all routers. The trigger router is the one that sets the community and then the reaction routers, the provider edge routers, matches the community and sets the next hop to the static route to Null0. And you can use multiple communities so for example community #1 could be used for all routers in the network. And you may also want to have a different community that can be for peering routers and this allows for, you know, no customer routers would allow for customers to talk to the DDoS customer within your AS. Utilizing communities you can have much better control over where packets get dropped and how. So this here is an example configuration. One of the things that's really important to note is that you want to ensure that the edge router does not leak prefixes out of the autonomous system number and you also want to make sure that no other static routes are affected by the black hole trigger route map. Know that there's many many configuration examples out there. This one happens to be for a Cisco router. There's also many available for different router types. Primary recommendations are to only take Internet transit from an operator who supports RTBH and also provide the RTBH filtering feature to all your customers and there are some very good materials out there that show specific configuration examples. There is the IETF standard RFC 5635 that documents step-by-step exactly what I've tried to show you here in this short video and there's also a detailed presentation on how to configure RTBH. So I would recommend that you look at those two pointers and good luck.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.