Tipos de ataques DDoS

Cada año son más y más frecuentes. Por eso hemos decidido escribir este artículo, en el que explicamos muchos de los ataques DDoS con los que seguramente nunca te encontrarás, pero que, aun así, debes saber que existen. ¡Empecemos!

DDoS de día cero (Zero Day)

El acrónimo se inventó para describir los nuevos ataques DDoS que aprovechan determinadas vulnerabilidades de las que nunca se había oído hablar. Normalmente se pueden corregir con algunos parches aquí y allá. 

Tipos UDP

DNS Flood

Este es probablemente el ataque DDoS más famoso y popular con el que te puedes haber topado en la red. Es un ataque de inundación UDP dirigido a los servidores DNS. Se utiliza con tanta frecuencia porque es difícil de detectar, y no digamos de prevenir. ¿Cómo se ejecuta? El hacker envía una enorme cantidad de peticiones DNS falsificadas que son difíciles de distinguir de las reales. Ahora multiplícalo por miles de IP y ahí lo tienes.

Tu servidor no puede saber cuáles son legítimas y cuáles no, por lo que se queda sin recursos para procesar esas peticiones y se cae. 

UDP Flood

El nombre lo dice todo. Ataca un servidor utilizando paquetes UDP (obvio). Mientras que el DNS Flood agota el hardware, el UDP Flood agota el ancho de banda. El tráfico UDP es muy cómodo para los atacantes porque, a diferencia del TCP, no necesita ser verificado por el servidor y el cliente. Básicamente, se envía constantemente al servidor una gran cantidad de paquetes UDP falsificados o enmascarados. Se enmascaran para asegurarse de que los paquetes ICMP de respuesta no lleguen a su host y para anonimizar el ataque.

Direct UDP Flood

El Direct UDP Flood tiene un enfoque diferente. Mientras que el UDP Flood habitual suele estar falsificado, el directo no lo está. Esto tiene ciertas ventajas para los atacantes, porque el tráfico que pasa por la botnet puede marcarse como legítimo, lo que complica su detección por parte de la víctima. Al igual que con el UDP Flood, el objetivo principal es agotar por completo los recursos del servidor. 

UDP Fragmentation Flood

Una variante bastante interesante del UDP Flood es su versión fragmentada. Al igual que el Direct UDP Flood, imita el funcionamiento del tráfico legítimo, que se mantiene dentro de unos límites. Por eso es muy difícil de detectar: los paquetes son bastante grandes, pero a la vez están fragmentados. Agota el ancho de banda todavía más. Imagina que tienes piezas de tres tipos de puzles y recibes piezas distintas de cada uno, pero no puedes saber qué pieza pertenece a qué puzle. Ahora multiplícalo por mil puzles y entenderás cómo se siente tu servidor cuando sufre un ataque UDP Fragmentation Flood. Algo muy desagradable. 

VoIP Flood

Hemos decidido incluirlo en la sección de UDP porque utiliza paquetes UDP para inundar servidores VoIP. Las peticiones falsificadas, que normalmente se envían desde un enorme conjunto de IP, sobrecargan gravemente el servidor. El problema con VoIP es que resulta muy difícil saber qué tráfico es real y cuál no. Daña seriamente el rendimiento del servidor, lo que provoca un rendimiento deficiente o un reinicio del servidor. 

ICMP Flood y sus tipos

ICMP Flood

ICMP utiliza el mismo método que UDP. No tiene un proceso de extremo a extremo para el intercambio de datos, lo que lo convierte en una posible alternativa al UDP Flood. Igual que con UDP, el atacante envía una gran cantidad de paquetes ICMP desde numerosos bots con IP diferentes. Como resultado, el sistema no puede procesar todas esas peticiones, lo que provoca un reinicio del servidor o reduce considerablemente su rendimiento. 

ICMP Fragmentation Flood

Otra variante del ataque anterior es su versión fragmentada. Igual que en el caso de UDP, el atacante simplemente divide los paquetes ICMP en trozos pequeños y sobrecarga el servidor enviando partes inconexas de distintos paquetes sin ninguna relación entre sí. En condiciones normales, el servidor puede soportarlo, pero solo hasta cierta cantidad. Si se supera esa cantidad, el servidor se cae.

Ping Flood

La versión 2.0 del ICMP Flood se llama Ping Flood. Las mismas peticiones falsificadas dirigidas a la aplicación. Imagina que haces ping a cualquier servidor. Le preguntas al servidor: “¿Cuál es la latencia entre nosotros?” y el servidor responde, normalmente entre 5 y 10 veces. Pero imagina que 100000 personas preguntan lo mismo. Si el hardware tiene suficientes recursos, puede soportarlo, pero si no, el servidor se cae. El tráfico de un Ping Flood es muy difícil de distinguir porque también puede considerarse legítimo. 

Nivel de protocolo

NTP Flood

NTP, o Network Time Protocol (protocolo de tiempo de red), se diseñó originalmente para sincronizar la hora entre relojes y ordenadores. Básicamente, el ordenador pregunta al servidor principal qué hora es en ese momento y la sincroniza con su propio reloj mediante el sistema de paquetes. Es otra forma más en la que el atacante puede atacar tu servidor si ejecuta el protocolo NTP, que básicamente utilizan todos los servidores. Al final, estas peticiones falsificadas se utilizan para enviar inundaciones UDP al objetivo. Cuando el servidor intenta entender qué es cada cosa, acaba cayéndose por el exceso de datos.

CharGEN Flood

Este es un veterano. Lo incluimos solo por razones históricas. En 1984 se desarrolló este protocolo como Character Generator Protocol y se utilizaba como fuente de un flujo de bytes para depurar código de red TCP. Hoy en día está bloqueado por defecto en los sistemas modernos, así que si encuentras algún sistema que lo ejecute, ¡enhorabuena! Has encontrado una reliquia del pasado. En su día era bastante popular en impresoras de red, fotocopiadoras Xerox y otras máquinas, pero hoy esta brecha de seguridad ha sido erradicada. Inicialmente, el atacante simplemente atacaba su puerto 19 y enviaba una inundación UDP a través de él.

SNMP Flood

SNMP, o Simple Network Management Protocol (protocolo simple de administración de red), es un protocolo para gestionar, recopilar y modificar información sobre los dispositivos situados en redes IP. Es otro tipo de inundación que se puede amplificar, lo que significa que el atacante puede hacer más daño con menos recursos. Es una opción más atractiva porque el resultado de la amplificación es mucho mayor que el de los ataques DNS Flood o CharGEN Flood. Básicamente, el ataque se dirige a los dispositivos que ejecutan este protocolo y envía una inundación utilizándolo. 

SSDP Flood

El protocolo Simple Service Discovery Protocol, o SSDP, se utiliza para anunciar y descubrir servicios de red e información de presencia, pero sin utilizar DHCP ni DNS. Se usa habitualmente en oficinas pequeñas donde el hardware tiene acceso al protocolo UPnP (Universal Plug n’ Play). En 2014 dio lugar a un ataque DDoS dirigido a este tipo de dispositivos, a los que se enviaban paquetes con la IP falsificada del objetivo, lo que provocó caídas de servidores.

Nivel HTTP

HTTP Flood

Los atacantes que utilizan HTTP Flood sobrecargan el servidor con peticiones GET y POST. Las peticiones GET no consumen demasiados recursos del servidor: pueden ser la petición de mostrar ciertas imágenes o cualquier otro contenido estático. Las peticiones POST son otra cosa, ya que normalmente piden al servidor que procese algo, como buscar un valor concreto en la base de datos o realizar algún tipo de manipulación de la información. HTTP Flood no requiere falsificar la IP, por lo que los requisitos para iniciar un ataque son menores. 

Fragmented HTTP Flood

El HTTP Flood siempre se realiza con bots con IP válidas, porque han sido secuestrados por troyanos. Así que, antes del ataque, estaban dormidos y ni siquiera sabían que sus recursos se utilizarían en un ataque DDoS. La fragmentación permite al atacante alargar el ataque hasta el límite del tiempo de espera. Esto permite prolongar la conexión durante un tiempo considerable antes de que se pueda activar cualquier defensa. Por ejemplo, si utilizas Apache, no tiene mecanismos específicos de tiempo de espera que puedan ayudarte, por lo que los hackers lo explotan activamente.

Single Request HTTP Flood

Con el tiempo, los programadores y los sistemas de protección contra DDoS aprendieron a mitigar los ataques de múltiples paquetes entrantes, así que los hackers decidieron buscar una alternativa. Esto dio lugar a otra laguna, que explicaremos a continuación.

Todo se reduce a la manipulación de paquetes. ¿Y si pudieras crear varias peticiones GET/POST dentro de una sola sesión HTTP? Bueno, puedes, pero pueden contarse como varios paquetes. Los atacantes encontraron la forma de combinarlas en un solo paquete. Esto hace que el atacante parezca una persona legítima, por lo que es muy difícil rastrearlo.

Single Session HTTP Flood

Un método bastante antiguo que se puede llevar a cabo en HTTP 1.1 enviando peticiones desde una sola sesión HTTP. Ayuda a los atacantes a eludir los límites que imponen los mecanismos de defensa contra DDoS en cuanto al número de sesiones permitidas. 

Recursive HTTP GET Flood

Un ataque bastante interesante que utiliza peticiones GET. El hacker solicita unas cuantas páginas web y recibe información sobre ellas. Después, empieza a analizar cada objeto de la página y a enviar peticiones recursivas para cada objeto del sitio web. Es muy difícil de rastrear porque esas peticiones parecen legítimas. 

Random Recursive GET Flood

Una variante del ataque anterior que se dirige sobre todo a blogs, sitios web con páginas en secuencia o blogs. Igual que el HTTP GET Flood, recorre las páginas y después empieza a enviar peticiones aleatorias. La cuestión es que, para parecer un usuario legítimo, el atacante tiene que elegir páginas aleatorias y luego números aleatorios de la página para enviar cada vez una nueva petición GET. Al final, esto provoca un bajo rendimiento del servidor, que puede llegar a reiniciarse o caerse. 

ACK y SYN 

ACK & PUSH Flood

En primer lugar, veamos qué es ACK. ACK es un indicador (flag) que muestra al servidor o al cliente que los datos se han recibido correctamente. Por ejemplo, el cliente pregunta si el servidor ha recibido el envío de un formulario y el servidor da una respuesta ACK que le dice al cliente que todo está bien, que lo ha recibido. Ahora bien, ¿cómo funciona este ataque?

El atacante puede enviar información diversa al servidor y activar un indicador ACK para que el servidor diga que ha recibido la información. 

El indicador PUSH hace lo contrario. Mediante paquetes, pide al servidor que procese algún tipo de información para él. 

Este tipo de peticiones consume más recursos que los ataques anteriores y tiene prioridad sobre otras, ya que no forman parte de ninguna sesión de la lista de conexiones del servidor. Como resultado, el servidor procesa primero esas peticiones y en último lugar las de la lista de conexiones, lo que provoca la caída del servidor.

ACK Fragmentation Flood

Esta variante del ACK Flood utiliza un número reducido de paquetes de tamaño máximo, de aproximadamente unos 1500 bytes. El objetivo inicial es agotar el ancho de banda de la red del objetivo. Esta inundación es bastante astuta, ya que puede atravesar fácilmente tu equipo de red, como un router o un cortafuegos (firewall), si no se han aplicado filtros a nivel de aplicación, porque a ellos les pueden parecer legítimos. Estos paquetes suelen contener datos basura, porque el atacante no tiene ningún motivo para incluir información en ellos, ya que su objetivo es simplemente agotar el ancho de banda. 

SYN Flood

SYN es el nombre de una petición de conexión a través de TCP. Cuando un cliente intenta conectarse a un servidor mediante TCP (por ejemplo, al establecer una conexión HTTP o HTTPS), debe pasar inmediatamente por un protocolo de enlace de tres vías (three-way handshake) antes de que sea posible el intercambio de datos entre el cliente y el servidor. Como quien inicia el protocolo de enlace de tres vías de TCP es siempre el cliente, primero envía al servidor un paquete con el indicador SYN.

En un ataque TCP SYN Flood, los atacantes envían de forma intensiva una gran cantidad de paquetes SYN con direcciones IP falsificadas al servidor. Esto obliga al servidor a reaccionar enviando un paquete SYN-ACK en respuesta a cada una de esas peticiones falsas, reservando algunos recursos y dejando sus puertos "medio abiertos", a la espera de numerosas respuestas (paquetes con el indicador ACK) de hosts que en realidad no existen y que, por tanto, no enviarán ninguna confirmación.

SYN-ACK Flood

Ya hemos hablado del protocolo de enlace de tres vías. Este tipo de ataque se dirige al host. Cuando el atacante envía un paquete SYN, el host genera el paquete ACK correspondiente. El servidor no entiende por qué recibe esos paquetes fuera del orden del tráfico legítimo e intenta entenderlos y procesarlos. Todo esto acaba haciendo que el servidor esté demasiado ocupado para gestionar el tráfico que debería, lo que provoca un reinicio o una caída del servidor.

RST/FIN Flood

Ya hemos hablado de las inundaciones de tipo SYN y de cómo funcionan. Después de cerrar cada sesión TCP-SYN, debe producirse un intercambio de paquetes RST o FIN. Cuando empieza un RST o FIN Flood, el servidor comienza a recibir paquetes falsificados e ilegítimos que no están relacionados con ninguna de las sesiones que tiene en ese momento. Igual que con el SYN-ACK Flood, el servidor no puede saber de dónde vienen y dedica mucho tiempo a procesarlos, hasta que finalmente no lo consigue. 

Nivel IP

Fake Session Attack

Este tipo de ataque no utiliza IP falsificadas, sino las direcciones IP reales de los bots que realizan el ataque. Se crea una sesión TCP-SYN entre el servidor y el bot. El ataque se realiza de tal forma que la sesión agota su tiempo de espera debido al retraso de los paquetes ACK. Las sesiones vacías empiezan a agotar el servidor y, al final, este se cae o funciona bastante mal.

IP Null Attack

Según la terminología de los RFC, cada cabecera de IPv4 debe contener información sobre el protocolo de transporte que se utiliza. El ataque nulo debe su nombre al “cero” que los atacantes ponen en este campo. Esto significa que estos paquetes atravesarán los routers o cortafuegos porque no están definidos ni clasificados. Hoy en día, este valor está reservado para IPv6 Hop-by-Hop Option, pero eso no significa que todos los servidores actuales puedan procesar realmente este tipo de paquete. Ahora multiplícalo por miles y el servidor se cae.

Ataques a nivel de aplicación

Los ataques a nivel de aplicación son aquellos que aprovechan determinadas vulnerabilidades. Uno de los objetivos más populares son los servidores que ejecutan distintos CMS como WordPress, Drupal o  Joomla. Por supuesto, estas empresas siempre cierran las brechas de seguridad, pero los hackers suelen encontrar alguna vulnerabilidad de vez en cuando. La otra opción es atacar las bases de datos de la víctima con inyecciones SQL. Al final, el servidor no puede gestionar las peticiones falsas y se cae. Asegúrate de utilizar las últimas versiones de tu CMS y de que tu base de datos la administren profesionales. 

Ataque de uso indebido de aplicaciones (Application Misuse)

Este tipo de ataque no se puede ejecutar contra cualquier negocio. La víctima debe alojar algo que genere mucho tráfico y tener otro servidor al que pueda ir todo ese tráfico. Se parece a varios cauces de río que desvías manualmente hacia el servidor objetivo de la víctima para hacerlo caer. El método para tumbar el servidor sigue siendo el mismo: sobrecargarlo con un tráfico excesivo. El principal problema es que el tráfico es realmente legítimo, porque los servidores intentan establecer una conexión legítima. 

Conclusión

Hemos intentado cubrir la mayoría de los ataques DDoS con los que te puedes encontrar. Sin duda se nos habrá escapado alguno, pero creemos que ya tienes una idea general de qué tipos de ataques DDoS existen. ¡Gracias por tu tiempo!