Come costruiresti un runbook di risposta agli incidenti DDoS?

Question

Accepted Answer

Un runbook DDoS trasforma il panico in una checklist. Il suo principio fondamentale: **preparati prima dell'attacco, non durante** — account provisioning eseguito, contatti noti e dashboard costruite, così la risposta è esecuzione, non improvvisazione.

## Prepararsi in anticipo

- Avere un **provider CDN/scrubbing già integrato** (DNS puntato attraverso di esso, una modalità "under attack" che puoi attivare).
- Mantenere **dashboard e avvisi di base** per il traffico, il tasso di errore e il rapporto di cache-hit in modo che le anomalie emergano rapidamente.
- Pre-scrivere **regole WAF e livelli di rate-limit** che puoi irrigidire istantaneamente.
- Mantenere una **lista di contatti**: on-call, supporto CDN/ISP, leadership e un **template di status-page** pronto.

## I passi del runbook

1. **Rilevare e dichiarare** — un avviso o un'anomalia correlata (vedi DDoS detection) attiva un incidente. Assegna subito un incident commander.
2. **Identificare il tipo di attacco e il target** — è Layer 3/4 (volumetrico) o Layer 7 (HTTP flood)? Quale endpoint, IP o regione? Il tipo determina quali controlli attivi.
3. **Attivare le difese** — accendi la modalità CDN "under attack" / scrubbing, **irrigidisci le regole WAF** e **abbassa i rate limit**. Inizia con i controlli più economici e ampi.
4. **Blocca / null-route le fonti** — blocca gli IP o le geo offensivi al bordo; come ultima risorsa, chiedi all'ISP di **null-route** l'IP targetizzato per salvare il resto della piattaforma.
5. **Comunica** — pubblica sulla **status page**, aggiorna gli stakeholder e mantieni una timeline. Comunicazioni chiare prevengono una seconda crisi di confusione.
6. **Scala se necessario** — autoscale o provisioning eccessivo della capacità di origine per assorbire il traffico che passa mentre i filtri si irrigidiscono.
7. **Revisione post-incidente** — una volta stabile, esegui una retrospettiva senza biasimi: cosa ha funzionato, cosa è stato lento, quali regole rendere permanenti e quali lacune chiudere.

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

## Perché è importante

Sotto un vero attacco, la latenza e l'adrenalina fanno saltare i passi alla gente e peggiorano le cose. Un runbook fornisce una sequenza nota, strumenti pre-costruiti e ruoli chiari, così il team attenua in minuti invece di discutere opzioni mentre il sito è down. La linea più preziosa in qualsiasi runbook DDoS è la preparazione fatta in anticipo — non puoi integrare un provider di scrubbing o trovare il numero di emergenza dell'ISP mentre sei inondato.