Destination-based Remotely Triggered Black-Hole routing (RTBH) is an incredibly effective and very cost-effective method of protecting your network during a DDoS attack. And with Kentik Detect’s new advanced Alerting system, automated RTBH is also relatively simple to configure. In this post, Kentik Customer Success Engineer Dan Rohan guides us through the process step by step.
Remotely Triggered Black-Hole routing (RTBH) is an extremely powerful technique that network operators can use to protect their network infrastructure and their customers against Distributed Denial of Service (DDoS) attacks. By automating the redirection of undesirable traffic at discrete points in a network, RTBH gives operators the ability to mitigate DDoS and to enforce blacklist/bogon routing policy from a centralized station.
While there are a variety of methods to implement RTBH, including RFC 5634 and source-based RTBH, most network engineers consider destination-based RTBH to be their best first-line defense against DDoS attacks. In a traditional, non-automated RTBH setup, a customer might call and say, “Help! I think I’m under attack.” An operator would then log into a route server and configure the mitigation, which is a /32 host “black hole” route. The route is then redistributed via BGP — along with a ‘no-export’ community and a next-hop address — to the routers where the attack traffic is entering the network. These routers then route the traffic to a destination that doesn’t exist (the black hole), for example a null interface.
Destination-based RTBH is not only incredibly effective at protecting network infrastructure, it’s also inexpensive and can be simple to implement, particularly with Kentik Detect, which makes it exceptionally easy and flexible to automate. You create policies that define any number of conditions that will trigger an alarm, and define as well as how the system should respond to an alarm depending on the specific situation. That response may be immediate, delayed, or manual, it may include notification and/or mitigation, and it may involve just a /32 host route or include an aggregate /24.
We’ve seen gung-ho customers who are using Kentik Detect as a detection and trigger mechanism configure effective destination-based RTBH policies in as little as 30 minutes. The basic steps outlined below explain how you can take advantage of Kentik Detect’s power and flexibility to implement RTBH protection on your network.
RTBH can be as simple or as complex as you want to make it. Here are the bare essentials that you’ll want to figure out ahead of actually configuring anything:
Most operators find that the real joy of Kentik Detect is its endless flexibility. Chances are excellent that Kentik Detect can be configured to reliably alarm on a given condition no matter how complex a signature or baseline is involved. Luckily for us, the conditions that indicate that a DDoS attack is underway are extremely well understood, and Kentik offers a robust library of alert policies to help our customers quickly protect themselves against DDoS events, from the most common to the most corner-case.
To take advantage of Kentik’s alert presets, choose Alerting from the alerts menu on the main navbar, then click the Kentik alert Library tab. Find an alert whose description matches your needs, then click the Duplicate icon in the Action column, which copies the preset to the list of policies on the Alert Policies tab. Click the policy name to open the Alert Policy Settings page, where you can spend a little time getting more familiar with the policy and tuning it to your specific needs (the payoff is well worth it).
This page is also where you can build a policy from scratch (access via the Create Alert Policy button on the Alert Policies tab), a process that is probably wisest to initially attempt with a Kentik sales engineer or customer success engineer. Either way, when you want to enable your new policy you’ll click the enabled/disabled icon in the right-most column of the policy list (the icon will switch to green when the policy is enabled).
Here’s where things get technical, but nothing too crazy. You’ll create a mitigation platform and method, link the two together, then associate them with an alert. To understand how configuration of the mitigation method differs from configuration of the mitigation platform, consider a scenario where RTBH policies are differentiated based on transit providers, interface capacities, or available peers. By creating multiple methods, operators can achieve all the flexibility they need to match nearly any RTBH deployment scenario.
Here’s an outline of the process:
So there you have it: you’ve just created an alert policy that is configured to trigger RTBH mitigation!
If you’d like help with RTBH setup, please reach out to us at firstname.lastname@example.org. If you’d like to learn more about how Kentik delivers big data-powered DDoS protection, you can read more about Kentik Detect and Kentik’s DDoS detection and mitigation solution. If you’re ready to experience big data-powered DDoS defense and network visibility, start your free trial today.