Como ataque de de­ne­ga­ción de servicio (DoS), el SYN flood tiene por objetivo dejar sin tráfico legítimo a un sistema en línea. Co­n­ce­p­tua­l­me­n­te, un ataque de de­ne­ga­ción de servicio puede co­m­pa­rar­se 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á pro­ce­sar­lo. El atacante habrá alcanzado su objetivo, es decir, impedir el fu­n­cio­na­mie­n­to normal del organismo.

¿En qué consiste un SYN flood attack?

Cuando hablamos de SYN flood o inu­n­da­ción SYN, nos referimos a un ataque de de­ne­ga­ción de servicio. En él, el atacante envía un flujo de paquetes de datos ma­li­cio­sos a un sistema de destino con la intención de so­bre­ca­r­gar el objetivo y evitar así su uso legítimo.

Al igual que el ping de la muerte, la inu­n­da­ción SYN es un ataque al protocolo. Estos ataques tienen como objetivo apro­ve­char una vu­l­ne­ra­bi­li­dad en las co­mu­ni­ca­cio­nes de red para poner a sus pies el sistema de destino. En esto se di­fe­re­n­cia de la mecánica de los ataques vo­lu­mé­tri­cos ping flood, UDP flood y HTTP flood. En estos, los atacantes se centran en saturar el ancho de banda del objetivo en la red.

Fu­n­cio­na­mie­n­to de los ataques SYN flood

También conocido como “ataque se­mi­abie­r­to”, el SYN flood es un ci­ber­ata­que dirigido contra la conexión de red. El atacante manipula la ne­go­cia­ción en tres pasos del protocolo de control de tra­n­s­mi­sió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 co­ne­xio­nes se­mi­abie­r­tas. Esto ocupa recursos del servidor que dejan de estar di­s­po­ni­bles para el uso real.

Echemos un vistazo a cómo se establece una conexión TCP normal y cómo in­te­r­fie­re en este principio un ataque SYN flood.

Es­ta­ble­ci­mie­n­to normal de la conexión TCP mediante ne­go­cia­ción en tres pasos

Junto con el protocolo de internet (IP), el protocolo de control de tra­n­s­mi­sió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 in­te­r­ca­m­biar datos. Para ello, se utiliza la ne­go­cia­ción en tres pasos:

  1. El cliente envía un paquete SYN (“si­n­cro­ni­zar”) al servidor: “Hola, me gustaría es­ta­ble­cer una conexión contigo”.
  2. El servidor responde con un paquete SYN/ACK (ACK = “re­co­no­ci­mie­n­to”) y crea en el backlog de SYN una es­tru­c­tu­ra de datos conocida como bloque de control de la tra­n­s­mi­sión (TCB, por sus siglas en inglés) para la conexión: “Vale, de acuerdo. Entonces, utiliza los si­guie­n­tes pa­rá­me­tros de conexión”.
  3. El cliente responde al paquete SYN/ACK con un paquete ACK y se completa la ne­go­cia­ción. En ese momento, se establece la conexión y se puede enviar datos en ambas di­re­c­cio­nes. En el lado del servidor se elimina el bloque de control de la tra­n­s­mi­sión de la lista SYN: “Estupendo, gracias. ¡Co­me­n­ce­mos!”

Este proceso se ejecuta en segundo plano cada vez que nos co­ne­c­ta­mos a un servidor para visitar una página web o revisar nuestros correos ele­c­tró­ni­cos.

Mecanismo del ataque de inu­n­da­ción SYN

Durante un ataque SYN flood se produce una in­te­rru­p­ción masiva de la conexión TCP:

  1. El atacante envía un paquete SYN al servidor con una dirección IP fa­l­si­fi­ca­da.
  2. El servidor crea un bloque de control de tra­n­s­mi­sión para la conexión se­mi­abie­r­ta en la cola SYN (cola de conexión in­co­m­ple­ta). El TCB ocupa al­ma­ce­na­mie­n­to en el servidor. Además, se limita el tamaño de la cola SYN.
  3. El servidor envía un paquete SYN/ACK a la dirección IP fa­l­si­fi­ca­da del atacante.
  4. Puesto que el atacante no recibe ningún paquete ACK que confirme la conexión, el servidor envía más paquetes SYN/ACK al supuesto cliente y mantiene la conexión se­mi­abie­r­ta.
  5. Mientras que el servidor todavía está esperando una respuesta, siguen entrando nuevos paquetes SYN del atacante que deben re­gi­s­trar­se en la cola SYN.
  6. A partir de un de­te­r­mi­na­do momento, en la cola SYN no queda espacio di­s­po­ni­ble para más co­ne­xio­nes in­co­m­ple­tas. Po­s­te­rio­r­me­n­te, el servidor rechaza los paquetes SYN entrantes y deja de ser accesible desde el exterior.

Para iniciar un SYN flood, el atacante se sirve de un software especial. Un ejemplo de ello es la conocida he­rra­mie­n­ta hping, utilizada para hacer pruebas de pe­ne­tra­ción, que permite simular di­fe­re­n­tes ataques a la red. Por razones de seguridad, solo mostramos un patrón apro­xi­ma­do del código hping para un SYN flood con dirección IP falsa:

hping --syn --flood --rand-source -p <Port> <IP-Adresse>

Las opciones de comando resultan in­te­re­sa­n­tes:

  • La opción --syn indica a la he­rra­mie­n­ta que utilice TCP como protocolo y que envíe paquetes SYN.
  • Es im­po­r­ta­n­te la opción --flood. De acuerdo con la do­cu­me­n­ta­ció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.

Variantes del ataque de inu­n­da­ción SYN

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 ase­gu­rar­se de que los paquetes SYN/ACK enviados por el servidor no obtienen respuesta. Si el ordenador del atacante responde con un paquete ACK, como co­n­se­cue­n­cia, la entrada co­rre­s­po­n­die­n­te 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 di­s­po­si­ti­vo envía un paquete RST (RST significa “reset”) y finaliza así la conexión. Esto es lo que un atacante in­te­li­ge­n­te también querría evitar para mantener el máximo número de co­ne­xio­nes a medio abrir en el servidor.

Ataques SYN flood directos

Un ataque directo se inicia desde la propia dirección IP del hacker. Para ase­gu­rar­se de que se descartan los paquetes SYN/ACK entrantes, configura un co­r­ta­fue­gos 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 re­la­ti­va­me­n­te sencillo ra­s­trear­le, este tipo de ataque se utiliza muy poco.

Ataques SYN flood con dirección IP fa­l­si­fi­ca­da

El ataque con una dirección IP falsa es más popular. En este caso, el atacante introduce una dirección IP fa­l­si­fi­ca­da en el campo del remitente del paquete SYN y oculta de esta manera su verdadero origen. En este caso, el atacante prefiere utilizar di­re­c­cio­nes IP que no estén ocupadas en el momento del ataque. Así se garantiza que los sistemas afectados al azar no reac­cio­nen a las re­s­pue­s­tas SYN/ACK del servidor atacado con un paquete RST y terminen así la conexión.

Ataques SYN flood con ataque de de­ne­ga­ción de servicio (DDoS)

En este método de ataque “di­s­tri­bui­do” de SYN flood, los ataques se producen si­mu­l­tá­nea­me­n­te desde varios equipos. Por lo general, se trata de un conjunto de or­de­na­do­res se­cue­s­tra­dos, es decir, lo que se denomina botnet o red de robots. El atacante controla los or­de­na­do­res “zombi” de la red de robots, a los que ordena que envíen paquetes SYN al objetivo.

Ataques SYN flood por reflejo

Un servidor suele responder no­r­ma­l­me­n­te a un solo paquete SYN con varios paquetes SYN/ACK. Un atacante puede apro­ve­char esta ci­r­cu­n­s­ta­n­cia 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 se­r­vi­do­res de terceras partes. Cada uno de los se­r­vi­do­res responde a cada paquete SYN entrante con varios paquetes SYN/ACK que se envían a la víctima. Se produce una mu­l­ti­pli­ca­ción del tráfico de red. El ordenador de la víctima recibe un bombardeo de paquetes SYN/ACK y termina co­la­p­sa­n­do.

Medidas de pro­te­c­ción contra los ataques por inu­n­da­ción SYN

El principio de fu­n­cio­na­mie­n­to general de los ataques SYN flood se conoce apro­xi­ma­da­me­n­te desde 1994. Por lo tanto, hoy en día existe una serie de medidas de­fe­n­si­vas muy eficaces. Sin embargo, algunas de ellas tienen efectos se­cu­n­da­rios negativos o solo funcionan en ciertas co­n­di­cio­nes. En general, no resulta fácil di­s­ti­n­guir los paquetes SYN ma­li­cio­sos de los legítimos. La mayoría de las medidas de­fe­n­si­vas más famosas se utilizan a nivel de servidor, aunque también hay so­lu­cio­nes basadas en la nube.

Aumento de la cola SYN

La cola de co­ne­xio­nes in­co­m­ple­tas SYN me­n­cio­na­da an­te­rio­r­me­n­te forma parte del sistema operativo. Podemos ima­gi­nár­no­s­la como una tabla de datos. Cada fila de dicha tabla contiene in­fo­r­ma­ción para es­ta­ble­cer una única conexión TCP. El sistema operativo se encarga de gestionar las co­ne­xio­nes ini­cia­l­me­n­te. Después de es­ta­ble­cer una conexión al concluir la ne­go­cia­ción en tres pasos, esta se tra­n­s­mi­ti­rá a la apli­ca­ció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 inu­n­da­ción SYN consiste en aumentar la cantidad máxima de co­ne­xio­nes se­mi­abie­r­tas 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 in­cre­me­n­tar fá­ci­l­me­n­te. En principio, la cola SYN puede contener miles de entradas. De este modo, se pueden amo­r­ti­guar los ataques SYN flood.

Reciclaje de la conexión TCP se­mi­abie­r­ta más antigua

Un método re­la­cio­na­do consiste en eliminar la conexión se­mi­abie­r­ta más antigua de la cola SYN cuando esté llena. De este modo, se genera espacio para una nueva conexión se­mi­abie­r­ta. Este método, en co­m­bi­na­ción con una cola SYN su­fi­cie­n­te­me­n­te grande, puede conseguir que se siga ac­ce­die­n­do al sistema durante una SYN flood. Sin embargo, se ha de­mo­s­tra­do que este método no es eficaz cuando el volumen del ataque es muy elevado.

Caché y cookies SYN

La idea de la caché SYN es sencilla: en lugar de guardar un bloque de control de tra­n­s­mi­sión completo (TCB) para cada conexión se­mi­abie­r­ta en la cola SYN, solo se almacena un TBC mínimo. La técnica utiliza funciones hash cri­p­to­grá­fi­cas para evitar que el atacante pueda adivinar la in­fo­r­ma­ción crítica sobre la conexión. La caché SYN ha de­mo­s­tra­do ser un método eficaz. Solo se pueden perder los datos de conexión en algunos casos ex­ce­p­cio­na­les.

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 tra­n­s­mi­sión como es­tru­c­tu­ra de datos. En cambio, los pa­rá­me­tros de conexión re­le­va­n­tes se codifican en el número de secuencia del paquete SYN/ACK. Las funciones hash cri­p­to­grá­fi­cas aseguran que el atacante no pueda adivinar el número de secuencia fá­ci­l­me­n­te.

Un cliente legítimo responde al paquete SYN/ACK con un paquete ACK y recurre al número de secuencia preparado es­pe­cia­l­me­n­te. El servidor utiliza el número de secuencia del paquete ACK para es­ta­ble­cer la conexión y ve­ri­fi­car­la cri­p­to­grá­fi­ca­me­n­te. El uso de cookies SYN pro­po­r­cio­na una pro­te­c­ción eficaz contra los ataques de SYN flood. Sin embargo, en algunas ci­r­cu­n­s­ta­n­cias, puede conducir a la pérdida de re­n­di­mie­n­to.

Ambas te­c­no­lo­gías también se utilizan co­m­bi­na­das. Durante el fu­n­cio­na­mie­n­to 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 te­c­no­lo­gías.

Servicio de mi­ti­ga­ción basado en la nube

La lucha contra los ataques de de­ne­ga­ció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 de­ne­ga­ción de servicio que des­en­ca­de­nan 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 pro­vee­do­res de seguridad globales basados en la nube.

La idea es que el flujo de datos DDoS entrante se di­s­tri­bu­ya a muchos sistemas in­di­vi­dua­les. 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 co­n­so­li­da­do la te­c­no­lo­gía Anycast, además del método de fi­l­tra­ción de paquetes. Las pe­ti­cio­nes a los sistemas co­ne­c­ta­dos a través de Anycast se dirigen au­to­má­ti­ca­me­n­te a un servidor más cercano geo­grá­fi­ca­me­n­te. De este modo, cuando el ataque de de­ne­ga­ción de servicio es de magnitud global, se le quita hierro a nivel local. Las redes Anycast como Clou­d­fla­re convencen por su elegancia y re­si­s­te­n­cia.

El blog Clou­d­fla­re pro­po­r­cio­na una visión muy in­te­re­sa­n­te sobre el progreso actual en la lucha contra los ataques SYN flood. Además de la es­tra­te­gia de mi­ti­ga­ción basada en bots, parece que las firmas de paquetes SYN tienen un futuro pro­me­te­dor. Este sistema consiste en generar huellas da­c­ti­la­res legibles de los paquetes SYN entrantes. A partir de la huella dactilar, se pueden sacar algunas co­n­clu­sio­nes sobre el sistema operativo del ordenador que envió ori­gi­na­l­me­n­te el paquete SYN. Durante un ataque SYN flood, cuando se realiza el análisis de las huellas da­c­ti­la­res, se filtran los paquetes enviados que no cumplen el patrón.

En resumen

25 años después de su de­s­cu­bri­mie­n­to como he­rra­mie­n­ta de ataque, la inu­n­da­ción SYN sigue siendo una amenaza para los pro­pie­ta­rios de sitios web. Afo­r­tu­na­da­me­n­te, existen medidas de pro­te­c­ción eficaces para ga­ra­n­ti­zar la seguridad del protocolo de control de tra­n­s­mi­sión frente a estos ataques.

Ir al menú principal