¿Cómo construirías un runbook de respuesta a incidentes DDoS?

Question

Accepted Answer

Un runbook de DDoS convierte el pánico en una lista de verificación. Su principio fundamental: **prepararse antes del ataque, no durante él** — cuentas aprovisionadas, contactos conocidos y dashboards construidos, de modo que la respuesta sea ejecución, no improvisación.

## Prepararse con anticipación

- Tener un **proveedor de CDN/scrubbing ya integrado** (DNS apuntando a través de él, un modo "bajo ataque" que puedas activar).
- Mantener **dashboards y alertas de línea base** para tráfico, tasa de error y hit-ratio de caché, de modo que las anomalías se detecten rápidamente.
- Pre-escribir **reglas de WAF y niveles de rate-limit** que puedas endurecer instantáneamente.
- Mantener una **lista de contactos**: on-call, soporte de CDN/ISP, liderazgo, y una **plantilla de status-page** lista.

## Los pasos del runbook

1. **Detectar y declarar** — una alerta o anomalía correlacionada (ver detección de DDoS) desencadena un incidente. Asigna un comandante de incidente inmediatamente.
2. **Identificar tipo de ataque y objetivo** — ¿es de Capa 3/4 (volumétrico) o Capa 7 (inundación HTTP)? ¿Cuál es el endpoint, IP o región? El tipo dicta qué controles activas.
3. **Activar defensas** — enciende el modo "bajo ataque" de CDN / scrubbing, **endurece las reglas de WAF**, y **reduce los límites de tasa**. Comienza con los controles más baratos y amplios.
4. **Bloquear / null-route de fuentes** — bloquea rangos de IP u geografías ofensivas en el edge; como último recurso, pide al ISP que haga **null-route** de la IP objetivo para salvar el resto de la plataforma.
5. **Comunicar** — publica en la **status page**, actualiza a los stakeholders, y mantén una línea de tiempo. Las comunicaciones claras previenen una segunda crisis de confusión.
6. **Escalar si es necesario** — autoscalea o sobreprovee capacidad de origen para absorber tráfico que atraviese los filtros mientras se endurecen.
7. **Revisión post-incidente** — una vez estable, ejecuta una retrospectiva sin culpas: qué funcionó, qué fue lento, qué reglas hacer permanentes, y qué brechas cerrar.

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

## Por qué es importante

Bajo un ataque real, la latencia y la adrenalina hacen que la gente salte pasos y empeore las cosas. Un runbook proporciona una secuencia conocida, herramientas pre-construidas, y roles claros, de modo que el equipo mitigue en minutos en lugar de debatir opciones mientras el sitio está caído. La línea más valiosa en cualquier runbook de DDoS es la preparación realizada de antemano — no puedes integrar un proveedor de scrubbing o encontrar el número de emergencia del ISP mientras estás siendo inundado.