En esta página
Puntos clave
- Separar incidente de ataqueDetectar un DDoS significa correlacionar síntomas del servicio con evidencia de red.
- Vigilar PPS, Gbps y erroreseduce downtime y evita decisiones de pánico como reiniciar servidores, cambiar la aplicación o bloquear usuarios…
- Activar mitigación prontoPPS, flows, destinos, distribución de fuentes, mezcla de protocolos, SYN, UDP, tamaños de paquete…
Definición del problema
Detectar un DDoS significa correlacionar síntomas del servicio con evidencia de red. Una métrica no basta: mucho tráfico puede ser legítimo y poca banda con alta PPS puede romper infraestructura.
El tiempo es crítico. Si el equipo confirma la agresión solo después del blackhole o caída total, la disponibilidad ya se perdió.
Por qué importa detectar temprano
Detectar temprano reduce downtime y evita decisiones de pánico como reiniciar servidores, cambiar la aplicación o bloquear usuarios legítimos mientras el ataque sigue aguas arriba.
Para hosting protege otros clientes. Para gaming conserva confianza. Para empresas evita que un incidente técnico sea un problema comercial y reputacional.
Qué monitorizar
Monitoriza Gbps, PPS, flows, destinos, distribución de fuentes, mezcla de protocolos, SYN, UDP, tamaños de paquete, retransmisiones, handshakes fallidos y errores de aplicación.
Cada servicio necesita baseline propio. Web, DNS, Minecraft y FiveM no tienen el mismo comportamiento normal, por lo que una alerta única produce falsos positivos.
- detectar un DDoS exige correlacionar tráfico, errores de aplicación, PPS, saturación y quejas de usuarios.
Caso concreto
Una comunidad gaming ve timeouts mientras el proceso del servidor sigue vivo. Hay Gbps moderado, pero PPS anormal y consultas UDP repetidas: apunta a flood, no a bug simple.
Una plataforma B2B observa handshakes TLS fallidos y CPU alto en firewall. El cuello está en el edge TCP, no en la aplicación.
Para un proveedor de servicios, la detección debe generar una acción: abrir mitigación, avisar al cliente, cambiar ruta o escalar a soporte. Un gráfico sin procedimiento no reduce el downtime.
Errores frecuentes
Esperar la caída total es el error principal. Mirar solo ancho de banda e ignorar PPS, errores y pérdida también lo es.
También es un error llamar ataque a cualquier pico. Buena detección compara con baselines, actividad de clientes, despliegues y eventos conocidos.
Otro error es no guardar histórico. Sin comparativa con días normales, campañas, reinicios o picos comerciales, es difícil separar ataque, bug, mantenimiento y crecimiento real.
