Blackholing is the oldest defence against a DDoS attack, and the bluntest. You have all traffic to one address dropped, attack and legitimate traffic alike, so the attack no longer fills the connection the rest of your network runs over. DDoS attacks: how to protect your infrastructure explains where it fits among the other defences. This article is about practice with us: three ways to use the emergency brake, and what to watch out for.
An emergency brake, not a solution
The misconception is that a blackhole "fends off" the attack. For the attacked address it does the opposite: that address is unreachable for as long as the blackhole is in place, and for that one address the attacker has achieved exactly what they wanted. What you gain is the rest of your network.
Usually you do not have to think about it. During an attack our automatic measures take more targeted steps first, such as a rate limit on the attack traffic; what happens is shown per attack in the dashboard. Blackholing is for when you decide yourself that giving up one address is better than waiting.
1. The switch in the dashboard
Under Network → Routing → IP addresses you open an address and turn on Blackhole. The dashboard asks for confirmation first, because the effect is immediate: within seconds everything on that address is unreachable from the internet, until you turn the switch off again. Below the switch you see what our mitigation did with it and since when.
The switch works for IPv4 addresses. You decide who may use it: it falls under the Manage network right (see Giving colleagues access).
2. Through your own BGP session
If you have a BGP session with us, you can do the same from your own router, without the dashboard. You announce the address as a /32 with the blackhole community 65535:666 or 211588:0:666. That works within a few rules:
- Only an IPv4 /32 within your own prefix list — on a wider prefix the community has no effect, and an address outside your prefix list is refused.
- Your ROA stays as it is — the /32 is accepted on the basis of your prefix list.
- Withdrawing lifts it — as long as the /32 is announced, the address is unreachable.
- Other communities are dropped — when passing it on we keep only the blackhole community.
How communities work in general is covered in BGP communities. If you have only one session with us, bear in mind that we pass the request on from the router that session is on.
3. Automatically, for the edge addresses of your subnets
If you route a prefix yourself behind our connection, it contains subnets, each with a network address, a gateway and a broadcast address. During an attack that hits your whole /24, those are exactly the addresses that cause trouble: they receive attack traffic, but there is no service on them that anyone misses when they are briefly unreachable.
Under Network → Subnets you declare which subnets your prefix contains. If an attack targets the network, gateway or broadcast address of such a subnet, we may have that one address filtered for up to four hours. The other addresses stay reachable as normal.
That requires a declaration that is correct, because a wrongly declared subnet makes a live server unreachable during an attack. The dashboard therefore does three things:
- Suggestions — based on measured traffic it suggests subnets you adopt with one click. When in doubt it suggests nothing: if we see traffic from an edge address even once, the suggestion is dropped.
- Checking — declared subnets are measured again every night. If an edge address starts sending traffic itself, you get a warning on the page and in the reminder mail.
- Reconfirming — a declaration only counts while you confirm it every month or every quarter. Forget, and it lapses and we stop filtering those addresses.
One honest caveat, which the page itself makes too: traffic measurements are samples. A device that sends almost nothing, such as a quiet standby, can slip through. So check a suggestion before you adopt it.
Blackholing at Xyphen IT
All three routes come with IP transit on our network; the BGP route with transit over a session of your own. Unsure which route fits your set-up, or want a runbook for the next attack? Get in touch, or have a look at the BGP training, where we practise exactly that scenario with your team.