Ir al contenido 
Cookies TCP SYN En el núcleo de Linux, se mantiene baja la carga del handshake codificando criptográficamente la información de estado en el número de secuencia inicial (Initial Sequence Number) y estableciendo la conexión por completo solo tras recibir un ACK válido. De este modo, evito que las inundaciones de SYN saturen la cola de conexiones semiabiertas y bloqueen a los clientes legítimos.
Puntos centrales
- Funcionalidad: Cookie en el ISN, estado solo tras el ACK
- Control mediante Linux: net.ipv4.tcp_syncookies con los modos 0/1/2
- Beneficio: bajo consumo de memoria ante una carga de ataques
- Límites: no sirve para defenderse de los ataques a la ancho de banda o a las aplicaciones
- Sintonización: Configurar cuidadosamente los valores de backlog y retry
Cómo los ataques SYN-Flood ralentizan el protocolo de enlace TCP
Un atacante inunda el servidor con Paquetes SYN e ignora las respuestas SYN/ACK siguientes, lo que hace que las entradas semiabiertas ocupen espacio en la cola SYN. Entonces observo que las nuevas solicitudes legítimas no encuentran espacio y se acumulan los tiempos de espera agotados. Es precisamente aquí donde entran en juego Syncookies : El núcleo no almacena inicialmente ningún estado de conexión y traslada los datos necesarios al número de secuencia. Solo un ACK correcto confirma la existencia de un interlocutor real, de modo que el establecimiento de la conexión continúa con normalidad. LWN.net y la documentación de la TUM describen este principio como una protección contra el «handshake» consolidada y eficaz que no requiere un elevado consumo de memoria. Esta arquitectura mantiene la capacidad de respuesta del servidor incluso ante un tráfico masivo, ya que no crea los costosos estados hasta mucho más tarde.
Procedimiento técnico: una «cookie» en lugar del antiguo sistema de estado
El núcleo responde a un SYN con un SYN/ACK codificado especialmente, cuyo ISN se deriva de una clave secreta, opciones TCP y intervalos de tiempo. Si llega un ACK con el número correspondiente, reconstruyo los parámetros de la sesión a partir del ISN y abro el socket de forma normal. Si no llega la respuesta, tampoco existe un estado semiabierto ocupado, lo que ahorra memoria y recursos de la CPU. Este enfoque reduce drásticamente la vulnerabilidad de la fase de aceptación sin modificar de forma permanente la ruta habitual. Según la documentación de Ubuntu y Red Hat, esta técnica lleva funcionando de forma fiable desde hace muchas generaciones de kernel y solo se activa cuando la cola amenaza con desbordarse.
Activación y comprobación: tcp_syncookies en la práctica
Acerca del parámetro sysctl net.ipv4.tcp_syncookies Controlo el comportamiento: 0 = desactivado, 1 = solo en caso de sobrecarga, 2 = de forma permanente. En entornos de producción suelo configurar el modo 1, para que el protocolo de Handshake estándar se mantenga intacto y la protección solo se active cuando sea necesario. Puedo consultar rápidamente el estado en el shell; los cambios los aplico mediante sysctl o de forma permanente en /etc/sysctl.d/. Un artículo de fondo adecuado sobre el comportamiento de los sockets y los patrones de ataque ayuda a planificar todo el proceso; profundizo en los detalles en la entrada SYN protección contra inundaciones. Utilizo habitualmente los siguientes comandos:
Mostrar el estado de #
sysctl net.ipv4.tcp_syncookies
Activar # temporalmente (hasta el reinicio)
sudo sysctl -w net.ipv4.tcp_syncookies=1
Configurar # de forma permanente
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Límites: lo que las cookies SYN no pueden hacer
Las cookies SYN se dirigen principalmente a los Syn-Queue y evitan que los estados semiabertos ocupen memoria. Sin embargo, no son eficaces contra una línea sobrecargada, una lógica de aplicación desbordada o la saturación de la CPU. En caso de ataques volumétricos, necesito filtros previos, QoS y, si es necesario, scrubbing. Los ataques a nivel de aplicación, como las inundaciones HTTP-GET, también requieren controles, límites y cachés adicionales. Por ello, siempre integro las «syncookies» en una defensa de varias capas que aúna la red, el núcleo y el nivel de servicio.
Optimización: trabajo pendiente, colas y reintentos
Antes de que se produzca una emergencia, estoy de acuerdo con... atrasos y los reintentos, para que los picos legítimos no activen el modo de protección innecesariamente. tcp_max_syn_backlog influye en la cola de conexiones semiabiertas, mientras que somaxconn determina la longitud máxima de la cola de aceptación para las conexiones en espera de accept(). Con tcp_synack_retries determino cuántas veces el núcleo intenta repetir un SYN/ACK antes de darse por vencido. Un backlog mayor absorbe los picos de carga breves, pero consume memoria; un número menor de reintentos libera ranuras antes, aunque conlleva el riesgo de afectar demasiado a los clientes desconectados. Pruebo estas opciones bajo una carga realista con herramientas como hping3 o tcp_syn_flooder en una red aislada.
#: candidatos para picos de carga
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Comparación de modos de funcionamiento: efectos y aplicaciones
Para el día a día, elijo la Modos Hay que tenerlo en cuenta, ya que influyen en el diagnóstico, las métricas y el comportamiento bajo presión. Las cookies permanentes (2) evitan cualquier establecimiento precoz del estado, pero modifican los valores de medición para los reintentos y pueden influir en casos extremos poco frecuentes con opciones TCP. El modo adaptativo (1) permite que la pila funcione con normalidad e interviene cuando existe riesgo de desbordamiento. La opción «desactivado» (0) solo tiene sentido, como mucho, en entornos de laboratorio o en redes cerradas. La siguiente tabla lo resume de forma concisa:
| Modo | Descripción | Ventaja | Posibles efectos secundarios | Ejemplo |
|---|---|---|---|---|
| 0 | Desactivado, sin cookies | Comportamiento claro en la línea de base | El atacante llena la cola Syn | Red de pruebas aislada |
| 1 | Adaptativo, solo en caso de desbordamiento | TCP normal en reposo | Calibrar el punto de conmutación | Servicios públicos |
| 2 | Obligatorio, siempre activo | Alivio precoz | Los valores analíticos varían | Situación de ataque difícil |
Efectos cuantificables: latencias y tasa de éxito
A medida que aumenta la presión, el Memoria necesaria Esto se nota claramente al inicio de cada conexión, ya que no se produce ningún estado semiabierto. De este modo, las «SYN cookies» mantienen alta la tasa de aceptación, y las ráfagas cortas provocan menos interrupciones. Observo una recuperación más rápida ante el tráfico de avalancha en cuanto la fuente se agota. Las directrices de Ubuntu y Tenable recomiendan un uso adaptativo, para que los clientes normales sigan funcionando sin cambios. Para las pruebas de regresión, compruebo las retransmisiones, las tasas de pérdida y la latencia del servidor al pasar al modo de cookies.
Capas de protección adicionales: cortafuegos y límites
Las «syncookies» las elimino con Reglas de filtrado y establezco límites de velocidad para que la carga ni siquiera llegue a la pila TCP. En Linux, prefiero utilizar reglas de nftables para limitar o rechazar desde el principio a los usuarios que superen los límites de velocidad de conexión. La guía ofrece una visión general concisa de los filtros de paquetes modernos nftables frente a Netfilter. Además, los escenarios SYNPROXY en los cortafuegos perimetrales ayudan a finalizar el protocolo de enlace y a permitir únicamente las conexiones válidas. Para los puertos expuestos, defino aperturas estrictas, umbrales de registro y un número máximo de intentos de conexión por dirección de origen.
Enfoques de alto rendimiento: XDP y otros.
Cuando los ataques masivos... Tasa de PPS Para optimizar el rendimiento, traslado la lógica de filtrado mediante XDP al borde de la red de la tarjeta de red. De este modo, descarto los SYN sospechosos incluso antes de que lleguen a la capa de socket, lo que reduce la carga de la CPU y alivia la cola de recepción. Para iniciarse en esta técnica, resulta útil una introducción a la Procesamiento de paquetes XDP. En combinación con las cookies SYN, se crea un sistema de dos fases: primero, una selección aproximada en la tarjeta; después, una comprobación fiable del «handshake» en el núcleo. Esta cadena reduce notablemente la superficie de ataque y mantiene los servicios accesibles.
Diagnóstico: cómo interpretar correctamente las métricas y los mensajes de registro
En caso de que se observen Tiempos muertos Reviso las estadísticas de netstat/ss, los mensajes de dmesg y los paneles de Grafana con las tasas de conexión. Un aumento en la proporción de SYN-RECV, un elevado número de retransmisiones y de paquetes perdidos indican el cambio al modo de protección. Presto atención a los mensajes de desbordamiento de la cola de SYN y los correlaciono con la carga de la CPU y de las IRQ. Las capturas de paquetes con tcpdump corroboran la lógica de los números de secuencia y ayudan a detectar falsos positivos. Además, con los contadores de iptables/nftables mido el número de coincidencias con las reglas de limitación de velocidad.
Compatibilidad: opciones TCP y casos extremos
Programación de núcleos modernos Opciones como MSS, SACK o Timestamp, de modo que las cookies se transmitan de forma que puedan reconstruirse. Las pilas más antiguas o poco comunes pueden presentar peculiaridades, por lo que compruebo las rutas críticas antes del despliegue. Observo minuciosamente el comportamiento, especialmente en el caso de proxies, NAT y topologías anycast. LWN.net analiza detalles de diseño que explican por qué las implementaciones actuales funcionan de forma fiable. En escenarios muy específicos, el modo de funcionamiento forzado (2) sigue siendo una herramienta que solo utilizo de forma selectiva.
Ideas erróneas habituales: lo que suelo corregir a menudo
Las «syncookies» no sustituyen a Defensa DDoS en la periferia; protegen sobre todo la fase de establecimiento de la conexión. Un valor elevado de somaxconn por sí solo no evita los desbordamientos si nunca se responde a SYN/ACK. Del mismo modo, es errónea la suposición de que las cookies permanentes (2) sean siempre la mejor opción; los diagnósticos y los casos especiales se ven afectados por ello. Sin supervisión, carezco de señales para ajustar los puntos de conmutación y los límites. Las pruebas de carga siguen siendo indispensables para que la configuración y el hardware se adapten a la dinámica real de acceso.
Análisis práctico: pasos para llegar a una hipótesis sólida
Empiezo con Modo 1 para tcp_syncookies y compruebo el punto de intervención bajo carga. A continuación, aumento moderadamente tcp_max_syn_backlog y somaxconn, al tiempo que reduzco tcp_synack_retries y mido las tasas de éxito. Los límites de tasa del cortafuegos y los filtros geográficos/ASN eliminan el ruido antes de que llegue a la pila. Me reservo los filtros XDP o SmartNIC para situaciones de alto PPS, con el fin de utilizar los recursos de forma específica. Por último, documento las métricas para que los ajustes posteriores se basen en datos.
IPv6 y doble pila: mismo conmutador, misma lógica
En entornos de doble pila, se comportan IPv4 e IPv6 es coherente en el contexto de las cookies. El botón net.ipv4.tcp_syncookies controla la protección de forma global para TCP, es decir, también para los sockets v6. Por eso compruebo la transición al modo «cookie» en ambos protocolos, sobre todo cuando los dispositivos de upstream en IPv6 utilizan otras rutas de filtrado. Importante: las cookies SYN protegen exclusivamente el TCP. Los servicios UDP o QUIC requieren sus propios límites de tasa y políticas de borde para que el tráfico volumétrico no sature la CPU.
Métricas del núcleo: indicadores fiables
Para realizar un seguimiento fiable, utilizo contadores del núcleo que registran explícitamente las cookies. Además de ss -s Y, en cuanto a las distribuciones de estado, observo los contadores de cookies enviadas, aceptadas y fallidas. Así puedo detectar si la protección funciona, si los clientes legítimos logran pasar y si hay errores de configuración.
Resumen de #
ss -s
ss -ant state syn-recv | wc -l
Contador de cookies de # (kernel: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Vista en tiempo real
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Indicaciones en el registro (mensaje de ejemplo)
# dmesg muestra, entre otras cosas:
# TCP: Posible inundación de SYN en el puerto 443. Enviando cookies. Comprueba los contadores SNMP.
Subir Desbordamientos de listas y ListenDrops en paralelo a SyncookiesSent ajusto los backlogs, los reintentos y los filtros de upstream. Quedan SyncookiesRecv ... eso apunta a una auténtica avalancha de bots; en cambio, si se multiplican SyncookiesFailed, compruebo las rutas NAT/proxy y las posibles manipulaciones que puedan producirse en el trayecto.
Proxies, equilibradores de carga y Kubernetes
En Cadenas de proxy y de equilibrio de carga Determina la ubicación de la protección de cookies. Si un equilibrador de carga L4/L7 interrumpe el handshake TCP, una avalancha de paquetes SYN ni siquiera llega a los backends; en ese caso, activo las cookies en el borde. Si el equilibrador de carga solo funciona de forma pasiva (DSR, ECMP), los nodos backend deben protegerse por sí mismos. En Kubernetes, ajusto los sysctls en los nodos de trabajo, especialmente en cargas de trabajo con NodePort o HostNetwork. Para los controladores de Ingress con su propia defensa contra SYN (SYNPROXY, eBPF), ajusto las políticas para que no se frenen entre sí. Tengo en cuenta las comprobaciones de estado del equilibrador de carga en las pruebas, ya que, de lo contrario, las ventanas de prueba cortas con pocos reintentos pueden dar lugar a falsos indicios de inestabilidad.
Casos límite en detalle: opciones, intervalos de tiempo, NAT
Las cookies solo codifican parámetros limitados. Las implementaciones modernas de Linux suelen reconstruir MSS, SACK y el escalado de ventanas de forma fiable; sin embargo, las marcas de tiempo y algunas opciones poco habituales pueden presentar limitaciones dependiendo de la versión del núcleo. Por lo tanto, considero preferible el modo de funcionamiento (1), para que predomine la ruta estándar y las cookies solo se activen en caso de desbordamiento. La validez de una «cookie» está vinculada a intervalos de tiempo; en rutas muy asimétricas o con picos de retardo, un ACK legítimo puede quedar justo fuera de la ventana. Por eso, en escenarios de WAN y satélite, mido la varianza de ida y vuelta antes de reducir el número de reintentos. Los NAT y los dispositivos intermedios que modifican los números de secuencia u opciones son otros posibles casos extremos; mediante capturas específicas, determino dónde se pierden los bits.
Ataques de inundación de ACK/RST y variantes más allá de la «tormenta de SYN»
No todos los Ataque al transporte Se trata de una inundación pura de paquetes SYN. Las inundaciones de paquetes ACK o RST se dirigen a la CPU y a las rutas de los paquetes sin activar el handshake; las cookies apenas sirven de ayuda en este caso. En ese caso, utilizo filtros tempranos (nftables/XDP) con lógica de estado o una limitación mínima de la tasa de ACK. En concreto, las oleadas de RST contra conexiones establecidas las detengo mediante un conjunto de reglas que descarta los RST inesperados sin una ventana adecuada. También cubro los repetidores semiabiertos (SYN con suplantación de identidad más ACK tardíos) mediante límites de tasa por espacio de red de origen.
Otros ajustes: colas de lista/aceptación y errores rápidos
Además de los parámetros clásicos, utilizo interruptores complementarios que determinan el comportamiento en los límites:
- Backlog frente a somaxconn: El valor en listas (pendientes) por proceso se calcula mediante net.core.somaxconn limitado. Me encargo de que el software del servidor y el núcleo funcionen en armonía; de lo contrario, las optimizaciones no sirven de nada.
- tcp_abort_on_overflow: Si, cuando la cola de aceptación está llena, se descarta la solicitud sin aviso o se responde activamente con un RST. En las API de gran volumen, un error rápido puede permitir al cliente realizar un nuevo intento rápidamente; en el caso de clientes TLS o heredados, suelo preferir el descarte por defecto.
- Gestión de puertos y del estado TIME-WAIT: Las galletas no evitan que Cuello de botella del puerto efímero. Tengo pensado rango_de_puertos_locales_ip Sé generoso y utiliza las optimizaciones de TIME-WAIT con prudencia, para que la reutilización no provoque errores de Heisenbug.
- SO_REUSEPORT: Varias colas de aceptación por puerto distribuyen la carga entre los procesos de trabajo y reducen los desbordamientos en las CPU individuales.
Métodos de ensayo: reproducibles y fiables
Simulo una carga lo más cercana posible a la real y mido el punto de conmutación al modo «cookie», la tasa de éxito de las conexiones legítimas y el tiempo de recuperación tras el pico de carga. Para ello, combino inundaciones sintéticas de paquetes SYN con solicitudes reales de aplicaciones.
Generar tráfico de inundación # (¡en laboratorio!)
sudo hping3 -S -p 443 --flood --rand-source
Variar las condiciones de red #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Mezclar tráfico legítimo
wrk -t8 -c512 -d60s https:///
# Observación en paralelo
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Con estos pasos, puedo detectar si los reintentos se reducen de forma demasiado agresiva, si los cortafuegos de upstream filtran erróneamente las marcas de tiempo o si las colas de aceptación de determinados trabajadores se desbordan de forma desproporcionada. Documento los indicadores clave (aproximación a una tasa de éxito de 100% en conexiones legítimas, tasa de aciertos de cookies, comportamiento de la latencia) para poder realizar ajustes posteriores basados en datos.
Funcionamiento y mantenimiento: garantizar la estabilidad a lo largo de la vida útil
En funcionamiento continuo, tengo previsto Rotación secreta (automáticamente por parte del kernel) y observo si los cambios de intervalo de tiempo tienen efectos visibles en tramos con RTT muy largos. Mantengo actualizados el kernel y los controladores para que surtan efecto las mejoras en la implementación de cookies (mejor codificación de opciones, intervalos de tiempo robustos). Para las auditorías, anoto cuándo se activó el modo de protección, cuántas conexiones dejó pasar y si se activaron filtros adicionales. Cuando se producen cambios en el MTU, la descarga o las pilas NF (por ejemplo, nuevos conjuntos de nftables), repito pruebas breves para detectar a tiempo posibles interacciones erróneas.
Versión abreviada para los que tienen prisa
Las cookies de SYN almacenan la Carga del protocolo de enlace pequeña, ya que crean los estados solo tras recibir un ACK confirmado, protegiendo así la cola de SYN contra las inundaciones. Activo el modo 1, ajusto con cuidado los backlogs y los reintentos, y mido los efectos con métricas claras. Capas adicionales como los límites de tasa de nftables, SYNPROXY y XDP frenan el tráfico incluso antes de que llegue a la pila TCP. En resumen, de este modo protejo los servicios web, de correo electrónico, VPN y API contra las inundaciones SYN sin perjudicar a los clientes habituales. Quien aplique estos pasos de forma rigurosa refuerza la disponibilidad y reduce notablemente las interrupciones del servicio ante una carga de ataques.
