Hoe zou je een DDoS incident response runbook bouwen?

Question

Accepted Answer

Een DDoS runbook verandert paniek in een checklist. Het kernprincipe: **voorbereiden voor de aanval, niet tijdens** — accounts ingericht, contacten bekend, en dashboards gebouwd, zodat de reactie uitvoering is, geen improvisatie.

## Voorbereiden van tevoren

- Zorg dat een **CDN/scrubbing provider al geïntegreerd is** (DNS ernaar gericht, een "onder aanval" modus die je kunt inschakelen).
- Hou **baseline dashboards en alerts** voor traffic, error rate en cache-hit ratio, zodat anomalieën snel zichtbaar worden.
- Schrijf vooraf **WAF rules en rate-limit tiers** die je onmiddellijk kunt aanscherpen.
- Onderhoud een **contactlijst**: on-call, CDN/ISP support, leiding en een klaar **status-page** template.

## De runbook stappen

1. **Detecteer en verklaar** — een alert of gecorreleerde anomalie (zie DDoS detection) triggert een incident. Wijs onmiddellijk een incident commander aan.
2. **Identificeer aanvaltype en doel** — is het Layer 3/4 (volumetrisch) of Layer 7 (HTTP flood)? Welk endpoint, IP of regio? Het type bepaalt welke controls je inschakelt.
3. **Activeer verdedigingen** — zet CDN "onder aanval" modus / scrubbing aan, **scherp WAF rules aan** en **verlaag rate limits**. Begin met de goedkoopste, breedste controls.
4. **Blokkeer / null-route bronnen** — blokkeer aanvallende IP ranges of geos aan de edge; als laatste redmiddel, vraag de ISP om **null-route** op het doelgerichte IP om de rest van het platform te sparen.
5. **Communiceer** — post op de **status page**, update stakeholders en hou een timeline bij. Duidelijke communicatie voorkomt een tweede crisis van verwarring.
6. **Schaal indien nodig** — autoscale of overprovision origin capacity om traffic op te vangen die doorkomt terwijl filters aanscherpen.
7. **Post-incident review** — eenmaal stabiel, voer een blameless retro uit: wat werkte, wat was traag, welke rules permanent maken en welke gaten opvullen.

```text
DETECT -> IDENTIFY -> ENGAGE (CDN/WAF/rate-limit) -> BLOCK/null-route
       -> COMMUNICATE -> SCALE -> POST-INCIDENT REVIEW
```

## Waarom het belangrijk is

Onder een echte aanval maken latency en adrenaline mensen stappen overslaan en dingen erger maken. Een runbook geeft een bekende volgorde, voorgebouwde tooling en duidelijke rollen, zodat het team in minuten kan beperken in plaats van opties te debatteren terwijl de site down is. De meest waardevolle regel in elke DDoS runbook is de voorbereiding die van tevoren is gedaan — je kunt een scrubbing provider niet integreren of het noodnummer van de ISP niet vinden terwijl je wordt overstroomd.