DDoS Mitigation: Scrubbing, Anycast, and Responding to a Volumetric Attack

This article is about surviving a denial of service attack. The mechanics of how reflection and amplification generate the traffic are covered under distributed reflected denial of service — here the question is what you do when hundreds of gigabits per second arrive at a link that carries ten.

The three layers of attack

Mitigation depends on which kind you are facing, and the distinction is the most useful thing to hold.

Volumetric attacks saturate bandwidth, measured in gigabits or terabits per second. Reflection and amplification produce these, and the defining property is that the link is full before any of your equipment gets a say.

Protocol attacks exhaust state rather than bandwidth — SYN floods filling connection tables, fragmented packet attacks consuming reassembly resources. Measured in packets per second, and they kill firewalls and load balancers at traffic volumes the link handles comfortably.

Application layer attacks send small numbers of expensive requests: a search query that scans a database, a login that triggers a slow hash, a page that renders a report. Measured in requests per second, sometimes only hundreds, and they look almost exactly like legitimate traffic.

Why on-premises defence fails against volume

This is the point most often misunderstood. An appliance at your network edge can only filter traffic that reaches it, and volumetric traffic has already saturated the link upstream of that appliance. The best filter in the world behind a full pipe does nothing.

Volumetric mitigation therefore has to happen upstream, in networks large enough to absorb the traffic. On-premises equipment remains useful for protocol and application layer attacks, where volume is manageable and the problem is the nature of the requests rather than their quantity.

How upstream mitigation works

Scrubbing centres take your traffic, filter out attack traffic, and forward what is left. Traffic is redirected to them either by DNS change, which is slow because of caching, or by BGP announcement, which is fast — the scrubbing provider announces your prefix, traffic reroutes to them globally within minutes, and clean traffic returns to you over a tunnel or dedicated link.

Always-on scrubbing routes everything through the provider continuously, adding latency and cost but responding instantly. On-demand scrubbing engages when an attack is detected, which is cheaper and introduces a gap while redirection propagates. The choice is a risk decision, and a documented, rehearsed activation procedure is what shortens the gap.

Anycast announces the same address from many locations, so traffic goes to the nearest one and an attack is distributed across the whole footprint rather than concentrating on one site. This is why large content delivery networks absorb attacks that would destroy any single data centre, and it is the reason hosting behind a CDN is often the single most effective step available.

Upstream provider filtering is the blunt option. Remote triggered black hole filtering asks upstream providers to discard all traffic to the targeted address — which stops the attack and completes it, since the service is now unreachable. It protects everything else on your network, and it is a sacrifice rather than a mitigation. Flowspec allows more selective upstream filtering where providers support it.

What defends the other two layers

Protocol attacks are handled by SYN cookies, which avoid allocating state until a handshake completes, along with connection rate limits and properly sized state tables.

Application layer attacks need request-level intelligence: rate limiting per client and per endpoint, challenges applied selectively to suspicious sessions, caching so expensive operations are not recomputed, and a WAF with rules for the specific expensive endpoints. Distinguishing an attack from a traffic spike is the hard part, and it needs a baseline of what normal looks like.

Preparing before it happens

Know your provider's DDoS terms before you need them — many include basic protection and charge for the level that actually helps. Have contact details and account identifiers for your ISP and any scrubbing provider written down somewhere reachable when your network is down.

Reduce what is exposed: put public services behind a CDN or proxy so origin addresses are not published, and make sure the origin does not accept connections from anywhere except the proxy. An origin address that leaks through DNS history or an email header defeats the entire arrangement.

Write the runbook and rehearse it — who declares, who contacts the provider, what gets sacrificed first — and keep it with your other incident response playbooks. Set availability expectations honestly too; a mitigation that takes fifteen minutes to engage is incompatible with an objective of no downtime, which is the kind of mismatch the SLO conversation should surface in advance rather than during the attack.

Exam angles

Distinguish volumetric, protocol and application layer attacks by what they exhaust and how they are measured. Know that volumetric attacks must be mitigated upstream because on-premises equipment sits behind the saturated link. Name scrubbing centres with BGP redirection, anycast distribution, and upstream black hole filtering as the options, and recognize black-holing as sacrificing availability of the target to protect the rest.