Inundación DDoS
La inundación DDoS es el primer incidente de SysAdmin Crisis: tráfico de direcciones que no son clientes y una barra de ancho de banda que se pone en rojo.
Última actualización:
Una inundación es el primer incidente que enseña el juego, y el único que puede aparecer en la noche uno. El tráfico llega desde direcciones que no son clientes, la barra de ancho de banda se llena y todo lo que hay detrás empieza a sufrir.
Qué hace
El ataque va creciendo a lo largo de unos quince segundos de tiempo real en lugar de llegar de golpe, así que tienes una ventana entre la primera línea extraña y la primera barra roja. En su punto máximo apunta justo por debajo de la capacidad total de ancho de banda de la flota. Eso significa que la capacidad importa, y que una flota más grande absorbe de verdad más.
Una vez que la demanda supera aproximadamente 1,35× la capacidad, las máquinas que hay detrás entran en saturación: la CPU sube al 99 %, la latencia aumenta y, más o menos cada quince segundos, un objetivo más pasa a DOWN.
La firma en el log
Una inundación no se anuncia por su nombre; ves el síntoma como líneas de kernel y de monit en las máquinas del borde. Las líneas de abajo son ejemplos, y los valores cambian cada noche:
03:11:42 web-02 kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
03:11:45 web-02 monit[612]: 'web-02' cpu usage of 94% matches resource limit [cpu usage > 90.0%]
03:11:49 web-02 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Estas líneas no te dicen el origen. netstat y el log de acceso web muestran quién envía las solicitudes; resumir el log con grep, awk y sort | uniq -c es el verdadero trabajo de este incidente. Todas las direcciones del juego provienen de los bloques de documentación del RFC 5737 —192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24—, así que una dirección fuera de esos bloques nunca es un atacante.
Si lo dejas
El ancho de banda se satura primero, luego la CPU, y después las máquinas empiezan a caerse una por una. Un servidor caído es persistente: no vuelve por sí solo. Y como un incidente sin resolver empieza a acumular deuda de SLA una vez que vence su periodo de gracia, una inundación que ignoras te cuesta disponibilidad dos veces: una por las máquinas que derriba, otra por el reloj. Consulta escalada y SLA.
Cómo distinguirlo
| Se parece a | Qué lo distingue |
|---|---|
| Proceso descontrolado | La presión de CPU de una inundación afecta a toda la flota y llega con advertencias SYN del kernel; un proceso descontrolado es un único proceso con nombre en una única máquina. |
| Fuga de memoria | Una fuga hace subir la RAM, no el ancho de banda, y no muestra ninguna firma de tráfico. |
| Sobrecalentamiento | El calor puede llegar después de una inundación como efecto secundario. Si los dos están en marcha, la temperatura es un síntoma, no la causa. |
Cuándo aparece
| Noche más temprana | 1; también es la segunda lección del tutorial |
| Necesita | al menos una máquina web en la flota |
| A la vez | una inundación, nunca dos |
| Variante | a partir de la noche 6 una inundación puede llegar distribuida: cinco orígenes repartidos entre los tres bloques del RFC 5737 en lugar de una sola dirección |
La variante distribuida la decide el PRNG con semilla, así que la misma semilla produce siempre la misma noche; consulta determinismo y semillas.