SYN flood: variantes y medidas defensivas

Como ataque de denegación de servicio (DoS), el SYN flood tiene por objetivo dejar sin tráfico legítimo a un sistema en línea. Conceptualmente, un ataque de denegación de servicio puede compararse con el envío masivo de cartas falsas a un organismo. Cuando los buzones se saturan, el organismo no podrá recibir el correo legítimo o no podrá procesarlo. El atacante habrá alcanzado su objetivo, es decir, impedir el funcionamiento normal del organismo.

Cuando hablamos de SYN flood o inundación SYN, nos referimos a un ataque de denegación de servicio. En él, el atacante envía un flujo de paquetes de datos maliciosos a un sistema de destino con la intención de sobrecargar el objetivo y evitar así su uso legítimo.

Al igual que el ping de la muerte, la inundación SYN es un ataque al protocolo. Estos ataques tienen como objetivo aprovechar una vulnerabilidad en las comunicaciones de red para poner a sus pies el sistema de destino. En esto se diferencia de la mecánica de los ataques volumétricos ping flood, UDP flood y HTTP flood. En estos, los atacantes se centran en saturar el ancho de banda del objetivo en la red.

También conocido como “ataque semiabierto”, el SYN flood es un ciberataque dirigido contra la conexión de red. El atacante manipula la negociación en tres pasos del protocolo de control de transmisión (TCP) y, en lugar de negociar una conexión entre el cliente y el servidor, como está previsto, se crean en el servidor muchas conexiones semiabiertas. Esto ocupa recursos del servidor que dejan de estar disponibles para el uso real.

Echemos un vistazo a cómo se establece una conexión TCP normal y cómo interfiere en este principio un ataque SYN flood.

Junto con el protocolo de internet (IP), el protocolo de control de transmisión (TCP) es una de las piedras angulares de Internet. Puesto que TCP es un protocolo de conexión, tanto el cliente como el servidor deben negociar la conexión antes de intercambiar datos. Para ello, se utiliza la negociación en tres pasos:

1. El cliente envía un paquete SYN (“sincronizar”) al servidor: “Hola, me gustaría establecer una conexión contigo”.
2. El servidor responde con un paquete SYN/ACK (ACK = “reconocimiento”) y crea en el backlog de SYN una estructura de datos conocida como bloque de control de la transmisión (TCB, por sus siglas en inglés) para la conexión: “Vale, de acuerdo. Entonces, utiliza los siguientes parámetros de conexión”.
3. El cliente responde al paquete SYN/ACK con un paquete ACK y se completa la negociación. En ese momento, se establece la conexión y se puede enviar datos en ambas direcciones. En el lado del servidor se elimina el bloque de control de la transmisión de la lista SYN: “Estupendo, gracias. ¡Comencemos!”

Este proceso se ejecuta en segundo plano cada vez que nos conectamos a un servidor para visitar una página web o revisar nuestros correos electrónicos.

Para iniciar un SYN flood, el atacante se sirve de un software especial. Un ejemplo de ello es la conocida herramienta hping, utilizada para hacer pruebas de penetración, que permite simular diferentes ataques a la red. Por razones de seguridad, solo mostramos un patrón aproximado del código hping para un SYN flood con dirección IP falsa:

Las opciones de comando resultan interesantes:

• La opción --syn indica a la herramienta que utilice TCP como protocolo y que envíe paquetes SYN.
• Es importante la opción --flood. De acuerdo con la documentación, esta hace que el comando hping envíe los paquetes tan pronto como sea posible.
• Con la opción --rand-source, el atacante falsifica su dirección IP. En lugar de la dirección del remitente real, se introduce una dirección IP aleatoria.

Existen varios métodos para llevar a cabo un ataque SYN flood. Todos tienen en común el objetivo del atacante: mantener el servidor ocupado el mayor tiempo posible. Para ello, debe asegurarse de que los paquetes SYN/ACK enviados por el servidor no obtienen respuesta. Si el ordenador del atacante responde con un paquete ACK, como consecuencia, la entrada correspondiente se elimina del servidor de la lista SYN.

Si el atacante falsifica su dirección IP, los paquetes SYN/ACK del servidor nunca llegan. Si un ordenador recibe un paquete SYN/ACK de un servidor sin haber enviado primero un paquete SYN, el dispositivo envía un paquete RST (RST significa “reset”) y finaliza así la conexión. Esto es lo que un atacante inteligente también querría evitar para mantener el máximo número de conexiones a medio abrir en el servidor.

Un ataque directo se inicia desde la propia dirección IP del hacker. Para asegurarse de que se descartan los paquetes SYN/ACK entrantes, configura un cortafuegos en su ordenador. Otro método consiste en limitar el tráfico de la red a los paquetes SYN salientes.

Puesto que dirige el ataque desde su propia dirección IP y, por lo tanto, resulta relativamente sencillo rastrearle, este tipo de ataque se utiliza muy poco.

El ataque con una dirección IP falsa es más popular. En este caso, el atacante introduce una dirección IP falsificada en el campo del remitente del paquete SYN y oculta de esta manera su verdadero origen. En este caso, el atacante prefiere utilizar direcciones IP que no estén ocupadas en el momento del ataque. Así se garantiza que los sistemas afectados al azar no reaccionen a las respuestas SYN/ACK del servidor atacado con un paquete RST y terminen así la conexión.

En este método de ataque “distribuido” de SYN flood, los ataques se producen simultáneamente desde varios equipos. Por lo general, se trata de un conjunto de ordenadores secuestrados, es decir, lo que se denomina botnet o red de robots. El atacante controla los ordenadores “zombi” de la red de robots, a los que ordena que envíen paquetes SYN al objetivo.

Un servidor suele responder normalmente a un solo paquete SYN con varios paquetes SYN/ACK. Un atacante puede aprovechar esta circunstancia para lanzar un ataque SYN flood por reflejo. Así, el atacante falsifica la dirección IP de la víctima e inicia un ataque SYN flood DDoS contra uno o varios servidores de terceras partes. Cada uno de los servidores responde a cada paquete SYN entrante con varios paquetes SYN/ACK que se envían a la víctima. Se produce una multiplicación del tráfico de red. El ordenador de la víctima recibe un bombardeo de paquetes SYN/ACK y termina colapsando.

El principio de funcionamiento general de los ataques SYN flood se conoce aproximadamente desde 1994. Por lo tanto, hoy en día existe una serie de medidas defensivas muy eficaces. Sin embargo, algunas de ellas tienen efectos secundarios negativos o solo funcionan en ciertas condiciones. En general, no resulta fácil distinguir los paquetes SYN maliciosos de los legítimos. La mayoría de las medidas defensivas más famosas se utilizan a nivel de servidor, aunque también hay soluciones basadas en la nube.

La cola de conexiones incompletas SYN mencionada anteriormente forma parte del sistema operativo. Podemos imaginárnosla como una tabla de datos. Cada fila de dicha tabla contiene información para establecer una única conexión TCP. El sistema operativo se encarga de gestionar las conexiones inicialmente. Después de establecer una conexión al concluir la negociación en tres pasos, esta se transmitirá a la aplicación de escucha en el puerto y se retirará de la cola SYN.

Uno de los métodos más sencillos para aumentar la seguridad de un sistema contra los ataques de inundación SYN consiste en aumentar la cantidad máxima de conexiones semiabiertas que permitirá el sistema operativo. Cada entrada de la cola SYN consume una cierta cantidad de memoria, lo que hace que el número de entradas sea limitado. Por defecto, en Linux el límite es de varios cientos de entradas. No obstante, el valor se puede incrementar fácilmente. En principio, la cola SYN puede contener miles de entradas. De este modo, se pueden amortiguar los ataques SYN flood.

Un método relacionado consiste en eliminar la conexión semiabierta más antigua de la cola SYN cuando esté llena. De este modo, se genera espacio para una nueva conexión semiabierta. Este método, en combinación con una cola SYN suficientemente grande, puede conseguir que se siga accediendo al sistema durante una SYN flood. Sin embargo, se ha demostrado que este método no es eficaz cuando el volumen del ataque es muy elevado.

La idea de la caché SYN es sencilla: en lugar de guardar un bloque de control de transmisión completo (TCB) para cada conexión semiabierta en la cola SYN, solo se almacena un TBC mínimo. La técnica utiliza funciones hash criptográficas para evitar que el atacante pueda adivinar la información crítica sobre la conexión. La caché SYN ha demostrado ser un método eficaz. Solo se pueden perder los datos de conexión en algunos casos excepcionales.

Al invento de las cookies SYN en 1996 le siguió el concepto de caché SYN. En este caso, se renuncia al uso del bloque de control de transmisión como estructura de datos. En cambio, los parámetros de conexión relevantes se codifican en el número de secuencia del paquete SYN/ACK. Las funciones hash criptográficas aseguran que el atacante no pueda adivinar el número de secuencia fácilmente.

Un cliente legítimo responde al paquete SYN/ACK con un paquete ACK y recurre al número de secuencia preparado especialmente. El servidor utiliza el número de secuencia del paquete ACK para establecer la conexión y verificarla criptográficamente. El uso de cookies SYN proporciona una protección eficaz contra los ataques de SYN flood. Sin embargo, en algunas circunstancias, puede conducir a la pérdida de rendimiento.

Ambas tecnologías también se utilizan combinadas. Durante el funcionamiento normal, se utiliza el caché SYN. Si el caché SYN está lleno, se cambia a las cookies SYN. Así se combinan los aspectos positivos de ambas tecnologías.

La lucha contra los ataques de denegación de servicio es tan antigua como Internet. Sin embargo, los atacantes modernos tienen un poder de ataque mucho mayor debido a las redes de robots. Los ataques de denegación de servicio que desencadenan ponen a sus pies, con su enorme flujo de datos, incluso a los sistemas más seguros. Por lo tanto, cada vez se utilizan más los servicios de grandes proveedores de seguridad globales basados en la nube.

La idea es que el flujo de datos DDoS entrante se distribuya a muchos sistemas individuales. De este modo, la carga total del ataque se dispersa y disminuye la carga pico que afecta a cada uno de los sistemas. Por eso, la red puede llegar a soportar ataques graves.

A nivel de red, se ha consolidado la tecnología Anycast, además del método de filtración de paquetes. Las peticiones a los sistemas conectados a través de Anycast se dirigen automáticamente a un servidor más cercano geográficamente. De este modo, cuando el ataque de denegación de servicio es de magnitud global, se le quita hierro a nivel local. Las redes Anycast como Cloudflare convencen por su elegancia y resistencia.

El blog Cloudflare proporciona una visión muy interesante sobre el progreso actual en la lucha contra los ataques SYN flood. Además de la estrategia de mitigación basada en bots, parece que las firmas de paquetes SYN tienen un futuro prometedor. Este sistema consiste en generar huellas dactilares legibles de los paquetes SYN entrantes. A partir de la huella dactilar, se pueden sacar algunas conclusiones sobre el sistema operativo del ordenador que envió originalmente el paquete SYN. Durante un ataque SYN flood, cuando se realiza el análisis de las huellas dactilares, se filtran los paquetes enviados que no cumplen el patrón.