Diseño de la mitigación de inundaciones de SYN para la Internet real

Visión general

La misión de Nexusguard es proteger a nuestros clientes de los ataques DDoS disruptivos y, al mismo tiempo, preservar el rendimiento de las aplicaciones. Una de las amenazas más comunes a las que nos enfrentamos es la Inundación TCP SYN. Este ataque tiene como objetivo la fase de apretón de manos del Protocolo de Control de Transmisión (TCP) y envía un aluvión de segmentos SYN en un intento de agotar los recursos del servidor. Los atacantes suelen falsificar las direcciones de origen, por lo que el servidor objetivo invierte recursos en conexiones semiabiertas con hosts que nunca responden. En casos extremos, estos SYNs también se pueden utilizar para enviar el tráfico a víctimas desprevenidas, aprovechando la disposición del servidor a responder a cada apretón de manos.

‍

Para contrarrestar estos ataques, nuestros bastiones locales son deliberados eliminar el primer SYN y solo aceptará conexiones cuando un cliente demuestre su legitimidad mediante la retransmisión. Este enfoque elimina el riesgo de que los bastiones se conviertan en reflectores y conserva la funcionalidad TCP completa para los usuarios legítimos. En las siguientes secciones se explica la naturaleza de las inundaciones de SYN, se compara la mitigación de las cookies SYN sin estado con la validación basada en la retransmisión y se explican las razones por las que preferimos esta última opción.

Cómo funcionan las inundaciones de SYN

El protocolo de enlace tripartito comienza cuando un cliente envía un SYN, avanza cuando el servidor responde con un SYN-ACK y finaliza cuando el cliente confirma con un ACK. En condiciones normales, este protocolo de enlace sincroniza los números de secuencia iniciales y negocia opciones como el tamaño máximo del segmento y el escalado de la ventana. Durante una inundación de SYN, el atacante envía una enorme cantidad de SYN, a menudo con direcciones falsas, para cerrar la cola de conexiones medio abierta del servidor. Como el servidor no tiene forma de verificar la fuente antes de responder, envía los paquetes SYN‑ACK de forma diligente y espera las confirmaciones que nunca llegan. El servidor retransmitirá el SYN‑ACK si no se recibe el ACK esperado, tal como exige la especificación TCP. Cuando las direcciones falsificadas pertenecen a un tercero, estos SYN-ACK repetidos se convierten en ataque de reflexión, lo que amplifica la inundación al obligar al servidor a retransmitir el tráfico hacia la víctima. Esta amplificación depende del número de veces que el servidor retransmita su SYN-ACK.

‍

El siguiente diagrama ilustra un reflejo de SYN-ACK: una botnet dirige SYN falsificados a un servidor público, lo que hace que ese servidor envíe SYN-ACK repetidos a la víctima desprevenida. Como la víctima nunca termina el apretón de manos, el servidor sigue retransmitiendo.

Cookies SYN: ventajas e inconvenientes

Una defensa ampliamente adoptada contra las inundaciones del SYN es la Cookie SYN algoritmo. Cuando la carga de trabajo de un servidor se agota, en lugar de asignar una conexión medio abierta, codifica los parámetros de conexión en el número de secuencia del SYN‑ACK, descarta su estado y espera el ACK del cliente. La cookie se crea a partir de un campo limitado de 32 bits; solo hay unos pocos bits disponibles para representar parámetros como el tamaño máximo del segmento y el tamaño de la ventana. Debido a esta limitación, el servidor no puede recordar muchas funciones TCP opcionales y negociará los valores predeterminados conservadores. Como resultado, las conexiones que se establecen mediante cookies SYN pueden tener ventanas más pequeñas, carecer de marcas de tiempo o compatibilidad con ECN, y no pueden usar opciones más nuevas. Además, cuando se pierde el SYN‑ACK en sí, el servidor que utiliza cookies SYN puras no retransmite; el cliente debe volver a enviar su SYN para reiniciar el protocolo de enlace. Por último, dado que el servidor responde a todos los SYNs (incluidos los falsificados) con un SYN‑ACK, puede utilizarse como reflector durante un ataque distribuido.

‍

A pesar de estas limitaciones, las cookies SYN proporcionan una apátridas mecanismo para mantener la disponibilidad durante una inundación. Como el servidor no asigna memoria para las conexiones medio abiertas, sus recursos no se pueden agotar. Para algunas implementaciones, este equilibrio es aceptable, especialmente cuando la memoria es escasa o el servidor está ubicado en un punto de tránsito ascendente. Sin embargo, en el caso de los Bastions de Nexusguard, que operan a las puertas del cliente con amplios recursos y la necesidad de preservar el rendimiento total del TCP, este compromiso no es deseable.

Validación basada en la retransmisión

Nuestra alternativa es eliminar intencionalmente el primer SYN y continuar con el apretón de manos solo cuando el cliente retransmita. Los clientes TCP están diseñados para volver a intentarlo cuando no se reciben confirmaciones; por lo tanto, los clientes legítimos enviarán un segundo SYN cuando se agote el tiempo de espera, mientras que las herramientas de suplantación de identidad no pueden hacerlo porque nunca ven la respuesta del servidor. Cuando Bastions observa el SYN retransmitido, reenvía la solicitud al servidor protegido y permite que el SYN-ACK regrese al cliente. Luego, el apretón de manos finaliza con normalidad, conservando todas las opciones negociadas. Esta técnica filtra los SYN falsificados sin enviar tráfico a la dirección falsa, lo que elimina la función de reflexión de los Bastions. Como el Bastion solo reenvía las conexiones que se han reintentado, la probabilidad de que se produzca un falso positivo es extremadamente baja y los usuarios legítimos solo experimentan un pequeño retraso.

‍

Visualizamos la diferencia a continuación. En el Cookie SYN En este enfoque, el servidor responde a cada SYN inmediatamente con un SYN-ACK codificado, sacrificando algunas funciones opcionales. En el retransmisión approach the Bastions elimina el primer SYN; solo cuando el cliente lo vuelve a intentar, pasa el SYN y permite que el apretón de manos continúe.

Por qué Nexusguard elige la retransmisión

Las elecciones de diseño de Nexusguard se guían por tres principios: rendimiento, confiabilidad y seguridad.

• Preservar la funcionalidad TCP completa. Muchas aplicaciones modernas se basan en las opciones de TCP, como las confirmaciones selectivas, las ventanas grandes y las marcas de tiempo para lograr un alto rendimiento. Al permitir que el protocolo de enlace nativo continúe después de que el cliente demuestre su valía, nuestros Bastions garantizan que estas funciones se negocien. Por el contrario, las cookies SYN aproximan los parámetros utilizando unos pocos bits y no pueden admitir valores de MSS ni escalas de ventana más grandes.
• Evitar la reflexión. Nuestras mitigaciones nunca deben convertirse en un arma en el ataque de otra persona. Como el Bastion no responde a las SYN iniciales, no devuelve tráfico a direcciones falsas y no puede aprovecharse para reflexionar.
• Aprovechar el comportamiento TCP inherente. La retransmisión forma parte de la especificación TCP. Los clientes legítimos ya implementan la lógica de reintento; al confiar en este mecanismo, separamos a los usuarios reales de las inundaciones automatizadas sin introducir protocolos propietarios ni requerir la cooperación del cliente.
• Operando a escala. Nuestros bastiones se despliegan en el extremo de la red donde hay ancho de banda disponible. Eliminar un gran número de SYN maliciosos es más económico que utilizar cookies criptográficas para cada solicitud. La experiencia con los ataques a gran escala demuestra que enviar incluso SYN-ACK sin estado a altas velocidades de paquetes puede saturar los enlaces ascendentes; nuestro enfoque evita este problema al suprimir por completo las respuestas.

Conclusión

Las inundaciones de TCP SYN siguen siendo una amenaza generalizada. Existen dos mitigaciones principales: codificar el estado en el número de secuencia mediante Cookies SYN, y validación basada en la retransmisión que filtra los SYNs falsificados al exigir a los clientes que lo vuelvan a intentar. Si bien las cookies SYN permiten mantener un servidor en línea sin estado, impiden la negociación de opciones TCP avanzadas, no retransmiten los SYN perdidos y pueden participar involuntariamente en ataques de reflexión. Los Bastions de Nexusguard emplean la retransmisión porque conserva la funcionalidad completa del protocolo, aprovecha el comportamiento TCP incorporado y garantiza que el dispositivo no amplifique los ataques. Esta estrategia nos permite ofrecer el nivel más alto de protección y rendimiento a nuestros clientes.