Resumen

  • Un SYN flood explota una asimetría: el servidor reserva estado semiabierto antes de que el iniciador complete el saludo, por lo que solicitudes baratas pueden llenar una cola finita.
  • El RFC 4987 presenta dos defensas de extremo: guardar un registro menor en una caché SYN limitada o no guardar nada y reconstruir el estado desde una cookie devuelta con el ACK.

Cuando llega un SYN, el servidor que escucha toma una decisión aparentemente diminuta. Recuerda el intento, envía un SYN-ACK y espera. Para un cliente legítimo es una cortesía elemental. Para un atacante es crédito concedido por adelantado: el servidor paga memoria y temporizadores antes de que el supuesto cliente haya demostrado que puede escuchar la respuesta.

El RFC 4987 estudia cómo se explota ese crédito. Una implementación TCP convencional mantiene estado SYN-RECEIVED mientras el saludo queda incompleto. La cola de conexiones semiabiertas es finita. Si entran solicitudes más rápido de lo que se recuperan sus registros, los intentos legítimos dejan de encontrar sitio. El documento se ocupa del agotamiento del estado TCP del host y de la aplicación que escucha. No promete resolver el problema distinto en el que el volumen de paquetes consume primero la capacidad del enlace.

La falsificación de la dirección de origen facilita que nadie conteste al SYN-ACK, pero no define todos los ataques. Máquinas comprometidas pueden utilizar direcciones válidas y sostener la misma presión. Lo esencial es más simple: cada SYN provoca una asignación, el número de estados semiabiertos es limitado y la llegada supera la recuperación. En el mecanismo descrito por el RFC, el daño inmediato afecta a nuevas conexiones entrantes hacia el puerto atacado, no al estado de conexiones que ya se establecieron.

Varias respuestas intuitivas cambian el umbral sin corregir la ventaja. Ampliar la cola obliga al defensor a aportar más memoria y ofrece al atacante un número mayor que llenar. Acortar el temporizador SYN-RECEIVED libera antes las entradas, pero expulsa a clientes honestos demorados por la red; el agresor puede elevar su ritmo. Reciclar el bloque semiabierto más antiguo convierte la edad en criterio de sacrificio sin saber quién es legítimo. El filtrado de entrada ayuda cuando el ataque depende de origen falsificado, pero no está desplegado en todas partes y no elimina las peticiones de botnets con direcciones utilizables.

Recordar menos y ponerle límites

Una caché SYN reduce el precio del primer mensaje. En lugar de crear enseguida un bloque de control TCP completo, conserva un registro pequeño con lo necesario para terminar el saludo. La caché tiene un límite explícito. El RFC también describe la distribución entre cubetas mediante un hash con secreto. Una función pública permitiría concentrar todas las peticiones en una cubeta incluso si el resto estuviera libre. El secreto dificulta esa concentración dirigida, mientras el límite acota tanto la memoria como el trabajo de búsqueda.

La caché sigue siendo estado. Debe caducar y mantener la capacidad de retransmitir un SYN-ACK perdido. Enviar una única respuesta y olvidar la obligación de repetirla convertiría una pérdida ordinaria en un fallo de conexión. Su mérito no está en borrar el protocolo, sino en aplazar el objeto caro mientras conserva suficiente comportamiento para llegar al ACK final.

Llevar el recibo dentro de la respuesta

Las cookies SYN llevan la regla hasta una versión sin estado. El servidor no guarda un registro SYN-RECEIVED para el intento. Construye su número de secuencia inicial de modo que el ACK final devuelva información suficiente para validar el intercambio y reconstruir la conexión. Solo entonces asigna el bloque de control completo.

El apéndice A ilustra una construcción que combina el número de secuencia del iniciador, una codificación del tamaño máximo de segmento, un contador de tiempo, las direcciones y puertos, y una función secreta. Cuando vuelve el ACK, el servidor comprueba el valor contra su secreto y contra contadores recientes. Es el recibo compacto de un saludo concreto, no la autenticación de una persona o aplicación. Prueba que quien envía el ACK dispone de información derivada del SYN-ACK, dentro de la resistencia del cálculo a la adivinación; no establece una identidad duradera.

La ausencia de estado también tiene un precio. Entre SYN y ACK, TCP suele recordar opciones negociadas. El espacio codificable en una cookie es limitado, de modo que construcciones comunes pueden restringir el escalado de ventana, SACK o futuras opciones. El RFC también señala los datos enviados con el SYN. Si se pierde el ACK final y el servidor espera datos del cliente antes de hablar, puede faltar el estado desde el que retransmitir el SYN-ACK. La asignación se retrasó, pero parte de la memoria semántica del protocolo se retrasó con ella.

No hay obligación de elegir una sola técnica. El servidor puede usar la caché SYN mientras exista capacidad y activar cookies cuando se llene. El híbrido conserva una negociación más rica en condiciones normales y reserva el recibo sin estado para la sobrecarga. Un cortafuegos o proxy puede mediar el saludo, pero traslada la carga de estado y puede alterar la semántica extremo a extremo. La decisión de gasto no desaparece: cambia de dueño.

El RFC 4987, publicado en agosto de 2007, es Informativo y no una orden de Standards Track. Su análisis consideraba las cachés y cookies SYN como modificaciones viables del extremo y veía la caché como mejor opción ordinaria cuando fuese posible. Es una valoración histórica, no una prueba de la configuración actual de ningún sistema operativo.

La regla que perdura es no realizar un compromiso caro, escaso y dirigido por el adversario en el primer mensaje sin verificar cuando una representación más barata y reversible puede mantener vivo el intercambio. Esperar a que vuelva información de la respuesta aporta mejor evidencia de alcance por el camino de retorno. No autentica al interlocutor y puede perder contexto útil. Una defensa rigurosa debe mostrar tanto los recursos que ahorra como la semántica que deja atrás.

La única fuente es el RFC 4987, “TCP SYN Flooding Attacks and Common Mitigations”. Este texto se limita al estado TCP del extremo, las defensas que el RFC analiza y sus compromisos declarados; no afirma nada sobre valores predeterminados, despliegue o frecuencia actual de ataques.