Para facilitar el análisis y el estudio de los distintos ataques realizados en este laboratorio, os voy a compartir las capturas de tráfico generadas directamente en el servidor durante cada uno de los ataques DDoS. Estas capturas muestran de manera clara cómo se comporta el tráfico en diferentes escenarios y en distintas capas.

Ataques DDoS

La  intención es que estas capturas os sirvan como material educativo para profundizar en el análisis de los ataques y entender sus implicaciones. Podréis observar aspectos como el patrón de tráfico, el tamaño de los paquetes, la frecuencia de las solicitudes y cómo estas características varían según el método de ataque empleado. Esto os permitirá llegar a vuestras propias conclusiones sobre la efectividad de cada tipo de ataque y cómo podrían ser mitigados.

El conocimiento es clave para fortalecer nuestras defensas de ciberseguridad , y el análisis de estos datos nos ayudará a estar mejor preparados frente a estas amenazas.

No me centrare en todos los ataques, ya que muchos son específicos , como RDP , Minecraft ... etc , sino en los imprescindibles (para no hacer un post enorme ) os dejo la lista:

MHDDoS requiere una configuración precisa de los proxys para distribuir el tráfico de forma efectiva. No basta con cargar una lista de proxys cualquiera; es fundamental asegurarse de que la lista sea válida y que el comando para cargarla esté correctamente estructurado. En este caso, el comando que utilicé permitió que el ataque se ejecutara, pero no habilitó la funcionalidad de distribución de proxys. Esto quedó claramente reflejado cuando capturé el tráfico generado por el ataque: todos los paquetes maliciosos tenían como IP de origen la dirección de nuestro servidor de pruebas, indicando que el tráfico no se estaba distribuyendo.

¿Qué es la capa 7 de Internet?

La capa 7 hace referencia a la capa superior en el modelo OSI de 7 capas de Internet. También se conoce como "capa de aplicación". Es la capa superior del procesamiento de datos que ocurre justo debajo de la superficie o tras las aplicaciones de software con las que interactúan los usuarios. Por ejemplo, las solicitudes y respuestas de HTTP utilizadas para cargar páginas web son eventos de la capa 7.

Los ataques DDoS que tienen lugar en este nivel se conocen como ataques de capa 7 o de capa de aplicación. Los ataques DDoS también pueden tener lugar en las capas 3 o 4 del Modelo OSI.

¿Qué es el modelo OSI?

El modelo OSI (interconexión de sistema abierto) divide las funciones de un sistema de red en 7 capas, cada una de las cuales se abstrae de la inferior. Dentro del modelo, cada capa solo interactúa con las capas superiores e inferiores a ella.

Merece la pena tener en cuenta que el Modelo OSI es puramente teórico, y está diseñado para ayudar a describir lo que ocurre en las comunicaciones de red, no para describir la tecnología real implicada. El hecho de que el Modelo OSI sea un marco conceptual no significa que no sea útil. Hacer referencia al modelo ayuda a los ingenieros, desarrolladores y profesionales de la informática a precisar lo que hace un producto o protocolo, y el lugar que ocupa en el proceso de comunicación de la red.

Ataques DDoS Capa 7

Llegamos finalmente a los ataques de capa 7 (Aplicación) de denegación de servicio. Este post, aunque extenso, refleja días de análisis y reflexión sobre cómo estos ataques están marcando un antes y un después en el panorama de la ciberseguridad. No analizaremos todos los tipos de ataques L7, pero sí algunos representativos para comprender su impacto real en los sistemas y por qué los enfoques tradicionales anti-DDoS no son suficientes para detenerlos.

Proxificación en los ataques DDoS

Cuando comencé a estudiar los protocolos UDP utilizando MHDDoS, me encontré con una realidad que me llevó a reflexionar sobre el objetivo principal de este post: la evolución de los ataques de denegación de servicio desde las capas 3-4 hacia la capa 7. En herramientas como MHDDoS, los protocolos que permiten ser proxificados para realizar ataques distribuidos en capa 4 son relativamente limitados. Aunque TCP, como ya exploramos anteriormente, es uno de los principales ejemplos, no se puede decir lo mismo de otros protocolos como UDP, que no presentan opciones de proxificación. Esto reduce las posibilidades de ejecutar ataques distribuidos en estas capas utilizando proxys.

Sin embargo, en capa 7, la historia cambia radicalmente. En este nivel, prácticamente todos los métodos de ataque disponibles en MHDDoS ( Trasladable casi al 100% al resto ) pueden ser proxificados, incluyendo tipos como SOCKS4, SOCKS5 o incluso HTTP. Esto significa que la capacidad de distribuir ataques en capa 7 es mucho mayor y, por ende, estos ataques son significativamente más complejos y difíciles de mitigar. Además, la facilidad con la que podemos configurar esta distribución amplifica el impacto potencial de estos ataques.

Ataque GET Flood

Es curioso ver como se comportan los sistemas en base a los distintos ataque, uno saturan la memoria , otros la red ... y en este caso , me dejo perplejo con la subida de CPU de más de 50% en una maquina relativamente grande:

Donde a nivel volumétrico , posiblemente pasaría desapercibido en un sistema ADDoS tradicional, y donde como podemos ver, con una pagina simplísima ( Solo tiene un H1 ) , es capaz de sobrecargar una CPU un 50%

No hablamos de Gb , si no de unos simples Mb , podríamos llegar a realizar un core dump a algún sistema

Como se puede apreciar a simple vista , la captura , incluso sin ningún tipo de filtro, cambia significativamente , mostrándonos un indicio claro del tipo de ataque que podemos estar recibiendo:

MHDDOS tiene la capacidad de modificar useragents o incluso trasladar distintos referrer. Luego si no me alargo mucho, intentaremos pasar por ello, pero dejando ver que podría ser un ataque GET, pasémos a filtrar directamente:

http.request.method == "GET"

 

o podríamos buscar User-Agents y así , intentar hacer un listado de filtros ( Podríamos hacerlo en ZUI , que me gusta mucho ), buscando los User-Agents que tienen configurados por defecto ( Aunque podria modificarse fácilmente ):

http.user_agent contains "Mozilla"

Esta parte nos valdría para prácticamente todos los ataque L7 , donde podríamos ver de una forma visual ciertas estadísticas, como los paths más solicitados ( En este caso es el inicio , pero podría ser otros , como vemos con NoName ):

De igual forma , podemos ver en estadística > http > métodos , el resultado de las peticiones y métodos utilizados:

Ataque DDOS POST Flood

No tengo configurado la web para aceptar métodos POST , siendo más efectivo en páginas con dicho método, o sistemas tipo API Gateway , pudiendo infringir "más dolor".

La segunda máquina se ha configurado para monitorizar el impacto de estos ataques en tiempo real. Aquí he utilizado NetData, una herramienta ligera pero increíblemente completa que permite visualizar métricas clave como el uso de CPU, memoria, tráfico de red y la carga general del sistema ( Y que dispone de 14 días de trail ). Esta máquina también alberga un servidor web básico Nginx, que sirve como objetivo de los ataques. Con NetData, pude observar cómo los ataques generan picos en el rendimiento de la máquina, afectando tanto al throughput como al tiempo de respuesta de las aplicaciones. Además, usaremos capturas de tráfico generadas con herramientas como tcpdump para analizar los paquetes en detalle, lo que nos permitirá estudiar cómo varía el comportamiento del ataque dependiendo de si se utilizan proxies o no, y las variaciones en ataques.

Como dato curioso, al ser POST , apreciamos la ausencia de datos en "enviado" por parte del servidor. El ataque a nivel de CPU , y posiblemente por la falta de posibilidad de usar metodos POST, no llego a incrementarse ni un 10% respecto a su uso normal. Al contrario que GET, en el que el ratio de respuesta de códigos 200 era casi de 100% , en este caso, vemos un incremento normal de errores 5xx.

Ataque DDOS Random HEX

Los ataques DDoS de Random Hexadecimal son una variante de los ataques de capa 7 diseñados para saturar aplicaciones web mediante la generación de solicitudes HTTP con datos aleatorios en los parámetros, encabezados o incluso en el cuerpo de las solicitudes. La clave de estos ataques está en que los valores aleatorios, usualmente representados en formato hexadecimal (por ejemplo, 0xABCDEF), dificultan que las contramedidas basadas en patrones predecibles (como WAFs) detecten o filtren el tráfico malicioso.

Un ejemplo seria hxxp://victima.com/page?param=0x1A3F5B

Dado que cada solicitud parece única debido al contenido aleatorio, es difícil implementar reglas basadas en patrones sin afectar el tráfico legítimo.

Con un simple vistazo , podemos ver y analizar que existen multitud de peticiones GET ( Ya vimos antes cómo buscarlas ) , y veremos ahora en estadísticas , y como hemos dicho, la multitud de peticiones únicas:

Entre los códigos de error , vemos múltiples "bad request" 4xx . Como dato reseñable también, la gráfica que nos deja. Si bien como en el método post, yo no tengo ninguna uri en la que pueda usar parámetro, la gráfica nos deja ver la cantidad de peticiones GET , pero al contrario que en el propio ataque GET , al ser paths distintos y no devolver 200, genera una sierra dentada en la que al terminar el ataque , remite en envío: 

Realice , distintas replica ( 1 - 2 ) en las que posteriormente amplifíquelo más jugando con el --rpc de MHDDOS , aun así , el echo de no tener variables o métodos, no infringe dolor en el servidor .

Podríamos buscar también indicios en Wireshark con:

http.request.uri contains "0x"
http.request.header contains "0x"

Ataque DDOS Paquetes gran tamaño

El método STRESS en MHDDoS es un tipo de ataque diseñado específicamente para saturar servidores mediante el envío de paquetes HTTP con un tamaño de bytes considerablemente grande. Este método apunta a sobrecargar no solo el ancho de banda del servidor, sino también sus recursos internos, como memoria y capacidad de procesamiento, al obligarlo a manejar solicitudes masivas con cargas de datos significativas. Es particularmente eficaz contra servidores web mal configurados o con capacidades limitadas para manejar grandes volúmenes de tráfico.

En esencia, el método STRESS combina características de ataques volumétricos (por el gran tamaño de los paquetes) con ataques de capa 7 (al usar protocolos HTTP), lo que lo convierte en una herramienta versátil para ataques de denegación de servicio distribuidos.

Para detectar el tráfico generado por el método STRESS en una captura de tráfico, podemos:

• Filtrar solicitudes HTTP grandes: Solicitudes HTTP cuyo tamaño sea mayor a lo esperado. ( El posible que no nos muestre la información el filtro , por lo que recomiendo verlo en estadísticas )

http.content_length > 100000

Siendo mejor buscar por tamaño de paquetes:

frame.len > 1500

Esto nos permitirá observar tráfico que pueda estar saturando el ancho de banda.

• Estadísticas de tamaño de paquetes: En Statistic > Packet Lengths , aplicando el filtro de tamaño grande, podremos ver una distribución mucho más clara.

Ataque DDOS Método HEAD

El uso de los métodos HTTP HEAD y CONNECT en los ataques recientes es un ejemplo claro de cómo los atacantes están utilizando estrategias menos comunes pero igualmente efectivas para explotar los sistemas. Estos métodos, aunque diseñados con propósitos legítimos, pueden ser manipulados para infligir un impacto desproporcionado en la infraestructura objetivo.

El método HEAD es una solicitud HTTP diseñada para obtener los encabezados de una respuesta sin incluir el cuerpo del contenido. Esto lo hace más ligero en términos de transferencia de datos, ya que no devuelve el contenido completo de la página solicitada. Sin embargo, el servidor aún procesa la solicitud como si fuera una petición completa, generando los mismos encabezados que una respuesta GET.

Durante nuestras pruebas, vimos que una máquina con amplios recursos pasó de un uso de CPU de menos del 1% a más del 50% en cuestión de segundos, simplemente gestionando un flujo constante de solicitudes HEAD. Lo más significativo es que, en términos de volumen de ancho de banda, apenas se notó un pico de 130 MB, lo que está lejos de ser alarmante para los sistemas tradicionales de detección de anomalías DDOS.

Este comportamiento pone de manifiesto una evolución en las tácticas de los atacantes.

Ya no se trata solo de saturar el ancho de banda con ataques volumétricos, ahora los ataques están diseñados para colapsar los recursos internos del sistema de manera más sutil pero igualmente devastadora.

Podemos localizarlo fácilmente :

http.request.method == "HEAD"

Ataque DDOS SlowLoris y Downloader

El ataque SLOWLORIS se centra en mantener abiertas múltiples conexiones HTTP al servidor objetivo, utilizando la menor cantidad de recursos posible por parte del atacante. El truco detrás de SLOWLORIS es enviar encabezados HTTP incompletos, lo que obliga al servidor a mantener las conexiones abiertas en espera de que se complete la solicitud. Esto puede saturar el pool de conexiones del servidor, dejando al resto de los clientes legítimos sin acceso.

El método DOWNLOADER en MHDDoS es muy similar a SLOWLORIS en su filosofía, pero agrega un enfoque adicional: el envío de solicitudes diseñadas para que el servidor descargue grandes cantidades de datos desde su propia infraestructura. Este ataque obliga al servidor a usar su ancho de banda y recursos internos para manejar solicitudes aparentemente legítimas, pero manipuladas para que se conviertan en herramientas de autoexplotación.

En los gráficos que hemos generado, se pueden observar claramente las diferencias entre los ataques Slowloris y Downloader en términos de su impacto en la infraestructura, tanto en CPU como en memoria. Los gráficos etiquetados como 1 y 3 representan el ataque de Slowloris, mientras que 2 y 4 corresponden al ataque de Downloader.

En términos de throughput, ambos ataques muestran un consumo de red prácticamente imperceptible, lo que los hace muy difíciles de detectar mediante sistemas tradicionales que monitorean el uso del ancho de banda. Sin embargo, es en los gráficos de CPU y memoria donde se aprecia la verdadera naturaleza de estos ataques.

• Slowloris: El ataque genera un patrón de uso muy distintivo, con picos pronunciados que llegan a consumir entre el 60% y el 70% de la CPU. Este comportamiento es curioso porque, a diferencia de otros ataques que suelen ser constantes en su impacto, Slowloris muestra un patrón irregular con momentos de alta intensidad seguidos de cierta recuperación. Este patrón irregular sugiere que el servidor está luchando por manejar las conexiones abiertas, probablemente debido a la naturaleza persistente de las solicitudes incompletas del ataque.
• Downloader: El ataque Downloader muestra un comportamiento más constante y predecible. Aunque también consume recursos de CPU y memoria, lo hace de manera menos agresiva en comparación con Slowloris. Esto es porque Downloader no fuerza al servidor a mantener conexiones abiertas, sino que lo obliga a gestionar solicitudes de descarga repetitivas, lo que genera una carga más uniforme.

Uno de los puntos claves de mitigación , es configurar límites estrictos en las conexiones y el tiempo de espera (Keep-Alive y timeout), algo que nos ahorrará muchos dolores de cabeza.

Fuentes:

https://ciberseguridad.blog/la-evolucion-de-los-ataques-ddos-y-por-que-debes-estar-preocupado-este-2025/