Case study
DDoS defence with blackholing and FlowSpec
Summary
The problem
Attacks filled customer ports before the NOC could react, the only tool was a manual null route on one router, and downstream customers could not ask for a blackhole themselves.
What we did
Designed remote-triggered blackholing to RFC 7999, including the communities that push a blackhole to each upstream so attack traffic is dropped before it reaches the network. Wrote a guide so downstream customers can trigger it for their own prefixes. Added FlowSpec rules driven by flow analytics on the border routers, and a NOC runbook that says which tool to use when.
Outcome
Customers can now trigger blackholing themselves. FlowSpec runs at the border, and the NOC follows a runbook during an attack.
In more detail
- Legitimate traffic
- Attack traffic
- Dropped
Blackholing or FlowSpec
Blackholing is blunt: it drops everything to the attacked address, which ends the attack and the service at the same time. It is the right answer when an attack is bigger than the port, and the wrong one when the customer can still be kept online. FlowSpec is the finer tool: it matches the attack by protocol, port and packet shape and drops only that. The design gives the NOC both, with clear rules about which to reach for.
Dropping traffic upstream
A blackhole inside your own network still lets the attack fill the links that bring it in. The important part of the work was agreeing communities with each upstream so a blackhole announced by the carrier is honoured on the upstream’s side, and confirming with each upstream how it is applied.
Customers in control
Downstream networks can now tag a prefix with the blackhole community and have it dropped across the carrier’s network and its upstreams. The guide we wrote covers the configuration for the router platforms customers run, and the filter that only accepts a blackhole for a customer’s own prefixes.