DDoS mitigation: what happens once an attack starts

How to prepare before any of this is on DDoS protection.

1. Detect. Notice that traffic or errors depart from normal, and that the cause is an attack; the first hour is on incidents.
2. Divert. Move traffic to capacity that can take it: an upstream provider, a scrubbing service or an edge network.
3. Filter. Drop what is clearly attack traffic and pass what is not, at the layer the attack uses.
4. Recover. Undo emergency changes, check what got through, and decide what to change before the next attack.

The steps overlap in practice. Diversion that is always on removes the delay of the second step; filtering that is too strict turns mitigation into a self-inflicted outage.

• Blackholing. Routing all traffic for the attacked address to nowhere. It protects the rest of the network and completes the attacker's goal for that address.
• Scrubbing. Diverting traffic through a service that removes attack packets and forwards the rest.
• Edge absorption. Serving from a network large enough to take the flood across many locations.
• Rate limiting. Capping requests per client or path at layer 7; see rate limiting.
• Request filtering. Refusing requests that match attack patterns, at layer 7.
• Source address validation. Networks dropping packets with forged sources (BCP 38), which reduces spoofed floods for everyone.

Always-on mitigation keeps traffic flowing through the filtering layer all the time. There is no switch to throw and no delay when an attack starts, and the filter learns what normal traffic looks like. The cost is paid every day, in fees or in latency added to every request.

On-demand mitigation diverts traffic only when an attack is detected, usually by changing routes or DNS. It costs less in quiet periods and adds nothing to normal traffic, but the first minutes of each attack reach you unfiltered, and DNS changes take as long as cached records live. For sites where minutes of outage matter, that delay decides the choice.

A strategy is the answer to three questions written down before the attack: which party mitigates which family, how traffic gets to them, and who decides to switch each measure on.

Write down the contacts and the switches, test the diversion path, and agree what signals trigger it. Standard signalling between a victim and its mitigation provider exists, in the DOTS architecture of RFC 8811, but a phone number that works is still the first item.

Application attacks arrive as complete, valid-looking requests, so they get past capacity and reach the application. Mitigation here is request filtering and rate limiting on the targeted paths, tightened deliberately and recorded so it can be undone. The boundary between what layer 7 can see and what it cannot is on layer 3, 4 and 7 attacks.

Mitigation that refuses customers is not a success. Watch error rates for real users while tightening, and loosen what does not help.