Knowledge baseNetwork

DDoS attacks: how to protect your infrastructure

24 June 20267 min read

A DDoS attack is not a break-in — nothing is stolen or cracked. The goal is simpler and blunter: to make your service unreachable by drowning it in traffic. And because the attack comes from thousands of places at once (the first D stands for distributed), "block that one source" is not an option. Anyone who puts infrastructure on the internet will run into it sooner or later — the question is whether you have a plan by then.

Three kinds of attack

Volumetric — the blunt instrument: more bits than your link can handle. Often through amplification: the attacker sends small queries with your IP address as the sender to badly configured open servers (DNS, NTP), which then send large answers to you. That turns a small amount of attack capacity into hundreds of gigabits.

Protocol and state exhaustion — the target is not the line but the equipment. A SYN flood opens thousands of half-open TCP connections per second until the connection table of your firewall or load balancer is full. The line is nowhere near full, yet your service is unreachable all the same.

Application layer (L7) — the subtlest variant: seemingly legitimate requests, but a great many of them, aimed at your heaviest endpoints (search, login, shopping basket). Hard to distinguish from real users, and effective even at modest volumes.

The defence, layer by layer

There is no single product that "solves DDoS" — it is a stack of measures, each for a different type of attack.

1. Start with hygiene. Filter outbound traffic for spoofed sender addresses (BCP38/uRPF) and do not put open resolvers or unsecured NTP servers on the internet. This mainly protects others — amplification only works because there are networks that neglect this. Anyone who runs infrastructure themselves this is simply part of the job.

2. Blackholing (RTBH) — the emergency brake. Through a BGP community (well known: 65535:666, RFC 7999) you ask your transit provider to drop all traffic to the attacked IP address at their edge. Active within seconds, and the rest of your infrastructure is relieved — but the attacked address is then offline itself as well. Blackholing sacrifices one IP to save the rest.

3. FlowSpec (RFC 8955) — the scalpel next to the emergency brake: instead of dropping an entire IP address, you pass a filter rule over BGP — "drop UDP/123 to this prefix" — so that only the attack traffic is discarded. Powerful, but not every provider offers it and a wrong rule hits more than the attack.

4. Scrubbingkeeping the service online. During an attack you divert your traffic over BGP to a scrubbing centre that filters out the attack traffic and returns the clean traffic over a tunnel or a direct connection. In the Netherlands in the Netherlands the shared model is the NaWas (Nationale Wasstraat, the national scrubbing facility), run by the NBIP foundation; alongside it there are commercial (international) scrubbers. This is the approach for services that cannot go offline even briefly.

5. The application layer — L7 attacks are not solved in the network. What helps there is a CDN or anycast layer in front of your service, rate limiting on expensive endpoints, caching and a WAF.

What do you arrange in advance?

During an attack it is too late to start making phone calls. The difference between an annoying half hour and a lost day lies in the preparation:

  • Arrangements with your transit provider — which blackhole community applies, is FlowSpec possible, how quickly does the NOC respond? With our transit these arrangements are covered as standard during onboarding.
  • Detection — you want to see an attack in your monitoring (flow data, link utilisation) before your customers report it.
  • A runbook — who decides to blackhole, which IP address can be sacrificed, who communicates to customers? One side of A4 that everyone knows.
  • Multihoming — with your own AS and several upstreams you have more options per attack than with a single connection.

Keeping a level head

Most attacks are short, untargeted and volumetric — with the right agreement in place and an emergency brake that works, you get a long way. A sustained target? Then scrubbing belongs in the plan. We are glad to help you work out what suits your situation: from routing policy and blackholing on your transit session to the set-up behind it — get in touch or first read how IP transit works with us.

Frequently asked questions

Frequently asked questions

Does my firewall protect me against DDoS?

Against application-layer attacks a firewall or WAF can do something, but against a volumetric attack it cannot — the link in front of your firewall fills up before the device can act. Volumetric attacks have to be solved in the network, not behind it.

What is the downside of blackholing?

Blackholing throws away *all* traffic to the attacked IP address, the legitimate traffic included. For that one address you are effectively doing the attacker's job for them. It is an emergency brake that saves the rest of your infrastructure — not a solution that keeps the service itself online.

What is the NaWas?

The Nationale Wasstraat run by the NBIP foundation; a shared Dutch scrubbing facility. During an attack, participants divert their traffic to the NaWas over BGP, which filters out the attack traffic and returns the clean traffic.

Answer not found?

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