Hvordan vil du bygge en DDoS incident response runbook?

Question

Accepted Answer

En DDoS runbook gjør panikk om til en sjekkliste. Dens kjernprinsipp: **forberede før angrepet, ikke under det** — kontoer provisjonert, kontakter kjent, og dashboards bygget, slik at responsen er utførelse, ikke improvisasjon.

## Forbered på forhånd

- Ha en **CDN/scrubbing-provider allerede integrert** (DNS pekt gjennom den, en "under attack"-modus du kan aktivere).
- Hold **baseline dashboards og alerts** for trafikk, feilrate og cache-hit-forhold slik at anomalier dukker opp raskt.
- Skriv på forhånd **WAF-regler og rate-limit-nivåer** du kan stramme til øyeblikkelig.
- Vedlikehold en **kontaktliste**: on-call, CDN/ISP-support, ledelse, og en klar **status-page**-mal.

## Runbook-trinnene

1. **Oppdage og erklær** — en alert eller korrelert anomali (se DDoS-deteksjon) utløser en hendelse. Tildel en incident commander umiddelbart.
2. **Identifiser angreppstype og mål** — er det Layer 3/4 (volumetrisk) eller Layer 7 (HTTP flood)? Hvilket endepunkt, IP eller region? Typen avgjør hvilke kontroller du bruker.
3. **Iverksett forsvar** — slå på CDN "under attack"-modus / scrubbing, **stram WAF-regler**, og **senk rate limits**. Start med de billigste, bredeste kontrollene.
4. **Blokker / null-route kilder** — blokker problematiske IP-områder eller geolokasjoner ved kanten; som siste utvei, be ISP-en om å **null-route** målrettet IP for å spare resten av plattformen.
5. **Kommuniser** — post til **status page**, oppdater stakeholdere, og hold en tidslinje. Klar kommunikasjon forhindrer en andre krise av forvirring.
6. **Skaler hvis nødvendig** — autoskaler eller overprovsjoner origin-kapasitet for å absorbere trafikk som kommer gjennom mens filtre strammes.
7. **Post-incident review** — når det er stabilt, kjør en blameless retro: hva fungerte, hva var sakte, hvilke regler skal gjøres permanente, og hvilke gap skal lukkes.

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

## Hvorfor det betyr noe

Under et virkelig angrep gjør latens og adrenalin at folk hopper over trinn og gjør ting verre. En runbook gir en kjent sekvens, ferdigbygget verktøy, og klare roller, slik at teamet mitigerer på minutter i stedet for å debattere alternativer mens siden er nede. Den mest verdifulle linjen i en DDoS runbook er forberedelsen gjort på forhånd — du kan ikke integrere en scrubbing-provider eller finne ISP-ens nødnummer mens du blir oversvømt.