Knowledge baseNetwork

Blackholing during a DDoS attack: the emergency brake, and how to use it

27 October 20266 min read

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.

Network → Routing → IP addresses: the blackhole switch per address, with its status below.

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.

Network → Subnets: per prefix an address map, your declared subnets and suggestions based on measured traffic.

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.

Frequently asked questions

Frequently asked questions

Does a blackhole stop the attack traffic everywhere?

With us, traffic to the address is always dropped. We ask internet exchanges and our transit to do the same, but not every party honours that. It keeps most of an attack away from your connection, but not guaranteed all of it.

Do I need to change my ROA to blackhole over BGP?

No, and do not. The /32 is accepted on the basis of your prefix list with us. A ROA that allows /32s actually makes it easier to hijack your address space.

Why do you ask me to confirm my subnets every month or quarter?

Because networks change. An address that was a broadcast address last year can be a server after a renumbering. A declaration nobody checks any more will sooner or later make an ordinary service unreachable during an attack.

Answer not found?

Ask an engineer directly — we usually respond within one business day.