Qué ocurre durante un evento DDoS

No se enciende nada

No hay botón. El filtrado se ejecuta permanentemente delante de cada sitio, desde cuatro terabits por segundo en las ubicaciones más pequeñas hasta doce en las más grandes, y la decisión de descartar un paquete se toma en hardware en el borde, a la entrada. Los primeros treinta segundos de un ataque se filtran exactamente igual que los últimos treinta, lo que no es cierto de ningún sistema que tenga que detectar un ataque, redirigir un prefijo y esperar a que el anuncio se propague.

Lo que se ve desde dentro

Normalmente nada en absoluto. UDP reflejado, una inundación SYN, un conjunto de respuestas DNS amplificadas: un ataque volumétrico de cualquier forma se descarta aguas arriba y nunca llega a su puerto. El gráfico en el panel lo muestra. Sus contadores de interfaz no.

Lo que puede llegarle es cualquier cosa indistinguible del tráfico real: una inundación HTTP lenta, una corriente de solicitudes a su endpoint más caro, una ejecución de relleno de credenciales. La capa 7 es donde el borde no puede ayudar sin conocer su aplicación, que es para lo que existe el complemento DDoS Pro: firmas personalizadas, límites de velocidad por ruta y una persona que las escriba con usted mientras ocurre.

Compruebe sus propios límites antes de concluir nada

Una buena mitad de los ataques que se nos reportan son una tabla conntrack que se llena o una cola de escucha que se desborda bajo tráfico normal de lunes.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50

nf_conntrack: table full, dropping packet en el registro del kernel es su firewall hablando de sí mismo, no la red informando de un ataque.

Lo que hacemos

La detección se basa en flujos y por destino. Una coincidencia de firma descarta el tráfico coincidente en cuestión de segundos y deja el resto del suyo en paz. Cuando el volumen excede lo que un sitio puede absorber, lo cual es raro y ha ocurrido, la dirección de destino se filtra por completo durante una ventana determinada en lugar de dejar que el sitio se degrade para todos los que están en él. Recibe un correo electrónico que nombra la ventana, y se mide en minutos.

El tráfico de ataque nunca se cuenta contra el uso justo. No es su tráfico y usted no lo pidió.

Lo que podemos contarle después

Vector, tasa de bits máxima, tasa de paquetes máxima, duración y la geografía aproximada de las fuentes. Eso es lo que contienen los contadores de flujo.

Lo que no podemos entregar es una captura de paquetes, porque no existe. No grabamos el tráfico que cruza su instancia, y esa política no tiene ninguna excepción que se active cuando el tráfico se vuelve hostil. El detalle está en lo que registramos. La gente ocasionalmente encuentra esto frustrante a mitad de un incidente, y es la misma propiedad que hace que el resto de la política valga algo.

Qué no hacer

• No cambie la dirección. El ataque la sigue en un minuto y ahora su DNS también está mal.
• No reinicie. Una instancia que se reinicia es una instancia más lenta, no una filtrada.
• No pegue una regla nftables de mil líneas en pánico. Todo lo que descarte en la instancia ya ha cruzado la parte cara de la red.
• Compruebe /status primero. Si el sitio en sí tiene un incidente, se publica allí antes de que se escriba su ticket.

Abra el ticket de todos modos

ID de instancia, marcas de tiempo con zona horaria, cuál fue el síntoma real y si el servicio era accesible desde una segunda red. La primera respuesta mediana es de once minutos a todas las horas del día, y durante un evento en vivo la respuesta viene de alguien que ya está mirando el gráfico.