En esta página
Puntos clave
- TCP mantiene estadoCada sesión nueva puede consumir estado en el servidor, firewall o balanceador.
- PPS importa tanto como GbpsUn SYN flood puede romper una pila TCP con ancho de banda moderado pero muchos paquetes.
- El filtrado debe llegar tempranoUna regla en el servidor no basta si el puerto, router o firewall se satura antes.
- El objetivo es la disponibilidadLa mitigación debe preservar conexiones reales, no solo limpiar la gráfica.
Qué intenta agotar realmente un SYN flood
Un SYN flood apunta al mecanismo de apertura TCP. Normalmente, un cliente envía SYN, el servidor responde SYN-ACK y el cliente confirma con ACK. Durante el ataque, la víctima recibe un volumen anormal de SYN, a menudo desde fuentes suplantadas, distribuidas o inestables. El servidor o un equipo intermedio conserva estado para conexiones que nunca se completarán.
El resultado no es solo más tráfico. Es presión sobre recursos de conexión: tablas de estado, backlog TCP, CPU de firewall, colas, memoria, NAT, balanceadores, reverse proxies o servidores web. Aunque el volumen en Gbps sea inferior a la capacidad anunciada, los paquetes por segundo y los estados incompletos pueden dejar el servicio fuera de línea.
Los SYN floods modernos también pueden mezclarse con otros vectores. Una ola UDP puede saturar el enlace mientras el SYN flood agota componentes stateful. Una defensa basada solo en bitrate medio o bloqueo amplio de puertos no basta. Hay que entender dónde aparece la saturación y qué capa debe aliviarse primero.
- Agotamiento del backlog
- Demasiadas conexiones incompletas impiden que clientes reales entren en la cola TCP.
- Presión en equipos stateful
- Firewalls, NAT y balanceadores pueden fallar antes que el servidor de origen.
- Fuentes suplantadas o distribuidas
- Los paquetes pueden venir de muchas IPs, a veces falsificadas, y bloquear por fuente deja de ser fiable.
Por qué importa para una infraestructura que vende online
Para el usuario final, un SYN flood no parece un ataque de red. Parece una página que no carga, un panel que rechaza conexiones, una API con timeout, un servicio de juego inestable o un servicio profesional fuera de línea. Si el servicio genera leads, clientes o ingresos, unos minutos pueden bastar para perder ventas y confianza.
La dificultad es que TCP está en todas partes: sitios web, APIs, SSH, paneles, proxies, balanceadores, túneles y servicios de negocio. Una mitigación demasiado agresiva puede generar muchos falsos positivos. Bloquear un puerto TCP expuesto detiene la gráfica de ataque, pero también corta el servicio. El buen diseño mantiene capacidad y precisión para que clientes legítimos sigan abriendo sesiones.
Esto importa aún más para empresas que crecen con visibilidad online, LinkedIn o X. Un prospecto difícil de conseguir debe encontrar una infraestructura disponible. La protección DDoS protege conversión, credibilidad y continuidad.
| Síntoma | Interpretación simple | Prioridad real |
|---|---|---|
| Timeout TCP | El servidor web va lento | Revisar backlog, firewall, balanceador y saturación upstream |
| CPU alta en firewall | Solo falta más CPU | Filtrar antes del equipo stateful cuando el ataque supera su rol |
| Pocos Gbps pero servicio caído | El DDoS no es grande | Mirar paquetes por segundo y estados incompletos |
| Conexiones legítimas rechazadas | Bloquear más fuerte | Separar firmas de ataque de aperturas plausibles |
Soluciones posibles contra un SYN flood
La primera respuesta es activar protecciones TCP del sistema, como SYN cookies, ajuste del backlog y umbrales del kernel. Son mecanismos útiles, pero no resuelven todo. Ayudan al servidor a no reservar recursos demasiado pronto, pero no protegen el enlace, router, firewall o balanceador si el ataque ya entra demasiado profundo.
El rate limiting puede reducir ruido evidente. Pero es peligroso si el tráfico legítimo crece o si el ataque imita aperturas normales. Un umbral bajo bloquea usuarios reales; uno alto no protege. Debe contextualizarse por servicio, puerto, comportamiento esperado y capacidad real.
ACLs, filtrado stateless, tamaños de paquete, flags TCP y características de red funcionan muy bien si se aplican temprano. Pero deben ser precisas: una regla amplia corta usuarios o rompe servicios. Por eso el filtrado upstream, scrubbing y entrega de tráfico limpio son necesarios cuando la exposición es seria.
- SYN cookies y tuning kernel
- Útiles para reforzar el origen, insuficientes contra saturación upstream.
- Rate limiting contextual
- Eficaz si los umbrales coinciden con el servicio real.
- Filtrado stateless temprano
- Reduce presión antes de equipos que conservarían estado sobre ruido.
- Tránsito protegido o scrubbing
- Limpia el tráfico antes de producción y entrega solo flujos utilizables.
Filtrado TCP adaptado al servicio real, no una regla genérica
El tráfico puede entrar mediante tránsito IP protegido Anti-DDoS con BGP, IPs protegidas, túneles GRE/IPIP/VXLAN o cross-connect según la arquitectura. El valor está en colocar la mitigación antes de que el ataque alcance los equipos más frágiles del cliente. El tráfico limpio se devuelve después con un handoff legible y adaptado a sus restricciones.
Para olas muy volumétricas o high-PPS, el filtrado puede combinarse con alivio upstream cuando el objetivo es reducir ruido antes de consumir puerto o capacidad de procesamiento. Debe ser preciso, temporal y proporcionado: no se trata de blackholear al cliente, sino de recortar el ataque para que la mitigación fina conserve el control.
Según el cliente, la misma lógica puede proteger tránsito IP con BGP, un servidor dedicado expuesto, un panel web, una API o un servicio de juego que dependa de conexiones TCP estables como Minecraft. La clave es elegir el punto de filtrado y el modelo de entrega adecuados en lugar de aplicar una regla genérica a toda la infraestructura.
- identificar dónde aparece la presión: enlace, firewall, balanceador, kernel o aplicación
- filtrar lo claramente ilegítimo lo antes posible
- evitar lógica stateful costosa en el camino caliente
- mantener entrega limpia por cross-connect, GRE, IPIP, VXLAN o VM router
- adaptar el perfil al servicio, no copiar un modelo único
Servicio web y panel cliente bajo SYN flood
Imaginemos un hosting o una plataforma SaaS con web comercial, panel cliente y varios servicios TCP expuestos. El ataque empieza con Gbps moderados, pero muchísimos SYN por segundo. El enlace no está necesariamente lleno, pero los clientes ven timeouts. El firewall stateful consume CPU y el balanceador mantiene demasiados estados incompletos.
El resultado esperado no es magia: depende del servicio, volumen, ruta y comportamiento legítimo. Pero el diseño es más limpio. El cliente deja de intentar salvar solo un servidor ahogado y recibe tráfico reducido, legible y más cercano a lo que la aplicación puede procesar.
Baseline
Entender el tráfico TCP normal: puertos, ritmo de apertura, picos previstos y perfil de usuarios.
Detección
Identificar señales: desequilibrio SYN/ACK, fuentes inestables, PPS anormal o presión de backlog.
Filtrado
Descartar temprano tráfico incoherente y evitar trabajo stateful sobre ruido.
Entrega
Devolver tráfico limpio al cliente por el modelo de integración adecuado.
Errores frecuentes que hay que evitar
Un SYN flood parece simple, así que muchos equipos lo tratan con una sola regla. A menudo no basta. La pregunta real es qué recurso está fallando y en qué punto del camino debe tomarse la decisión.
El segundo error es confundir endurecimiento del servidor con protección de red. Reforzar Linux, Nginx o HAProxy ayuda, pero no protege un puerto saturado ni un firewall ya superado. El servidor no puede filtrar paquetes que ya no llegan o que rompieron una capa intermedia.
- mirar solo Gbps e ignorar paquetes por segundo
- activar un rate limit global sin conocer el tráfico legítimo
- poner la primera defensa real detrás de un firewall stateful frágil
- bloquear todas las nuevas conexiones y llamarlo mitigación
- no probar la entrega de tráfico limpio antes del ataque real
FAQ
¿Un SYN flood siempre es grande en Gbps?
No. Puede tener poco ancho de banda pero muchos paquetes por segundo o mucha presión sobre estados TCP.
¿SYN cookies es suficiente?
Ayuda en el servidor, pero no protege capacidad upstream, firewalls, balanceadores o puertos de tránsito.
¿Hay que bloquear todo TCP durante el ataque?
No. Los servicios críticos usan TCP. La mitigación debe preservar conexiones plausibles y bloquear tráfico incoherente.
¿SYN flood y TCP flood son lo mismo?
El SYN flood es un tipo de TCP flood centrado en la apertura de conexión. Otros TCP floods atacan sesiones establecidas, flags o aplicaciones detrás de TCP.
