Quick answer
DDoS mitigation is the practice of identifying attack traffic and discarding it before it exhausts a target's resources, while allowing genuine users through with as little disruption as possible. It normally happens on a network with far more capacity than the attack, positioned upstream of the protected server. The two hard problems are telling attack traffic apart from real traffic quickly enough to matter, and doing so without blocking the customers the service exists to serve.
The four stages of mitigation
Every mitigation system, whatever the vendor calls it, does the same four things in sequence.
- Detection — noticing that current traffic differs from this service's normal baseline, not from some fixed universal threshold
- Diversion — getting the traffic to somewhere with the capacity and hardware to filter it, either permanently or when an attack starts
- Filtering — separating attack traffic from legitimate traffic and dropping the former
- Forwarding — passing the clean remainder to the origin, ideally over a path the attacker cannot see
Always-on vs. on-demand
On-demand mitigation only routes your traffic through the scrubbing network once an attack is detected — usually by a BGP announcement that redirects your prefix. It is cheaper, but there is a window between the attack starting and the diversion taking effect, and that window is often several minutes. For a short, sharp attack, the whole event can be over before mitigation engages.
Always-on mitigation keeps traffic flowing through the filtering path at all times, so there is nothing to detect, divert or activate — an attack simply meets a system already inspecting every packet. The cost is that all traffic, not just attack traffic, takes that path, so the provider's latency and reliability become yours.
How attack traffic is identified
At the network layers, filtering is mostly statistical: packet rates per source, malformed or impossible header combinations, protocols that have no business reaching this service, and reflection signatures such as large DNS responses nobody asked for.
At the application layer it is much harder, because each request is individually well-formed. Useful signals include the TLS handshake fingerprint (which reveals the client library rather than what the user-agent claims), header ordering and completeness, whether the client fetches the sub-resources a real browser would, and whether one identical signature appears across many unrelated addresses at once.
The last of those is the strongest, and the reason it works is simple: real users are diverse. Thousands of visitors produce thousands of slightly different fingerprints. A botnet running one tool produces one fingerprint repeated thousands of times.
Challenges: proving you are a browser
When traffic is ambiguous, the safest response is not to block it but to ask it a question that a browser can answer and a script cannot. The common form is a small proof-of-work: the page runs a short computation and submits the result, taking a fraction of a second and requiring no interaction.
This inverts the economics of the attack. A legitimate visitor pays milliseconds once and receives a token that lasts for the session. An attacker must run a full JavaScript engine for every one of the millions of requests they intended to send, which usually costs more than the attack is worth.
Interactive challenges — the ones with a checkbox — should be a later escalation, not the default. They cost every real visitor an interaction, so they are best reserved for clients that have already demonstrably failed the automatic check.
How mitigation is priced, and why it matters
Pricing models vary more than the technology does, and the difference shows up at the worst possible moment.
| Model | How it behaves during an attack |
|---|---|
| Flat / unmetered | Cost does not change; the attack is a technical event, not a billing one |
| Metered by traffic | Attack traffic is billed like real traffic, so a large attack produces a large invoice |
| Tiered with overage | Protection is capped at the plan level; exceeding it means an upgrade mid-incident |
Frequently asked questions
Last updated