Comment construiriez-vous un runbook de réponse aux incidents DDoS ?

Question

Accepted Answer

Un runbook DDoS transforme la panique en checklist. Son principe fondamental : **préparer avant l'attaque, pas pendant** — comptes provisionné, contacts connus, et tableaux de bord construits, afin que la réponse soit une exécution, non une improvisation.

## Préparer à l'avance

- Avoir un **fournisseur CDN/scrubbing déjà intégré** (DNS pointé via celui-ci, un mode « sous attaque » que vous pouvez activer).
- Conserver des **tableaux de bord et des alertes de base** pour le trafic, le taux d'erreur et le ratio de hits de cache afin que les anomalies soient détectées rapidement.
- Pré-écrire les **règles WAF et les niveaux de limite de débit** que vous pouvez renforcer instantanément.
- Maintenir une **liste de contacts** : astreinte, support CDN/ISP, leadership, et un modèle de **page de statut** prêt.

## Les étapes du runbook

1. **Détecter et déclarer** — une alerte ou une anomalie corrélée (voir détection DDoS) déclenche un incident. Assignez immédiatement un responsable d'incident.
2. **Identifier le type d'attaque et la cible** — est-ce couche 3/4 (volumétrique) ou couche 7 (inondation HTTP) ? Quel endpoint, IP ou région ? Le type dicte quels contrôles vous engagez.
3. **Engager les défenses** — activez le mode « sous attaque » de la CDN / scrubbing, **renforcez les règles WAF**, et **abaissez les limites de débit**. Commencez par les contrôles les plus simples et les plus larges.
4. **Bloquer / null-router les sources** — bloquez les plages d'IP ou les géos offensantes à la limite ; en dernier recours, demandez à l'ISP de **null-router** l'IP ciblée pour sauver le reste de la plateforme.
5. **Communiquer** — postez sur la **page de statut**, mettez à jour les parties prenantes, et tenez une chronologie. Une communication claire évite une deuxième crise de confusion.
6. **Scaler si nécessaire** — auto-scaler ou sur-provisionner la capacité d'origine pour absorber le trafic qui passe au travers pendant que les filtres se renforcent.
7. **Examen post-incident** — une fois stable, menez une rétro blameless : qu'est-ce qui a fonctionné, qu'est-ce qui était lent, quelles règles rendre permanentes, et quels gaps à combler.

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

## Pourquoi c'est important

Dans une vraie attaque, la latence et l'adrénaline font que les gens sautent des étapes et empirent les choses. Un runbook fournit une séquence connue, des outils pré-construits, et des rôles clairs, afin que l'équipe atténue en minutes au lieu de débattre des options pendant que le site est hors ligne. La ligne la plus précieuse dans n'importe quel runbook DDoS est la préparation faite au préalable — vous ne pouvez pas intégrer un fournisseur de scrubbing ou trouver le numéro d'urgence de l'ISP pendant que vous êtes inondés.