Sé que hace tiempo que no publico nada en el blog, pero no quería terminar el año sin dejaros algo que os inspire y os sirva de cara a 2025. Hoy, en este último día del año, no sé si lograré terminar este post, porque llevo trabajándolo varios días y todavía tiene cosas por pulir. Sin embargo, quería aprovechar para compartirlo, aunque sea en parte, como un pequeño regalo para cerrar este 2024 y abrir las puertas a un nuevo año lleno de retos y aprendizajes.
Estos últimos meses he estado algo desconectado, necesitaba un respiro. Algunos motivos personales me han llevado a pausar mi actividad en el blog, pero creo que también era necesario para volver con energía renovada. Para este 2025, quiero retomar el ritmo poco a poco, pero con una propuesta clara: contenidos trabajados, originales y útiles.
Mi idea es que estos posts sirvan como un laboratorio, una ventana a experiencias reales, con información práctica que podamos aplicar en nuestro día a día en el mundo de la ciberseguridad. Me comprometo a traeros contenido de calidad, hecho con cariño y dedicación. Esa será mi intención y mi propósito para el próximo año.
Dicho esto, os dejo con este post que he estado desarrollando, y que espero os aporte valor y sea una fuente de inspiración para arrancar el año con fuerza. ¡Gracias por seguir ahí y feliz 2025!
2025 , el año en que deberemos evolucionar nuestros sistemas DDOS
A lo largo de 2024, hemos presenciado una evolución significativa en los ataques de denegación de servicio (DDoS), tal y como se refleja en informes recientes como los publicados por Cloudflare y otros líderes en la industria. Tradicionalmente, estos ataques eran mayormente volumétricos y se centraban en las capas 3 y 4 del modelo OSI, saturando la infraestructura de red y colapsando servicios. Sin embargo, en los últimos meses hemos observado un cambio hacia estrategias más sofisticadas que incluyen ataques a la capa 7, la capa de aplicación.
Este cambio ha puesto en evidencia las limitaciones de los sistemas tradicionales de mitigación de DDoS. Aunque siguen siendo efectivos para manejar los ataques en las capas 3-4, no están diseñados para enfrentar combinaciones de ataques que incluyen la capa 7 ( Por norma general ). Lo que ocurre en la práctica es que los atacantes lanzan una primera oleada en las capas inferiores, forzando a los sistemas de defensa a centrarse en mitigar esas capas, mientras simultáneamente dirigen ataques a la capa 7. Esta táctica logra sobrecargar sistemas como WAFs (Firewalls de Aplicaciones Web) o soluciones on-premise como el módulo ASM de F5 entre otros muchos, incluso provocando la saturación de firewalls perimetrales y otros componentes críticos de la infraestructura.
Para hacer frente a este panorama, necesitamos replantear nuestras estrategias de mitigación. No solo se trata de protegernos contra ataques volumétricos, sino también de gestionar eficazmente el tráfico malicioso en las capas superiores. Esto requerirá un enfoque integral que combine la defensa en capas (3, 4 y 7) y el uso coordinado de diferentes ISPs para distribuir y absorber el impacto.
Lo más preocupante es que, con los recursos actuales, incluso un atacante con capacidades limitadas puede lanzar ataques potentes. Por ejemplo, con un servidor modesto o una conexión de ancho de banda doméstico, es posible generar ataques de hasta 1 Gbps que podrían comprometer infraestructuras mal preparadas, incluyendo sitios web o VPNs.
Por ello, considero que la evolución en la defensa contra ataques de denegación de servicio será una de las tendencias clave para 2025. No podemos seguir dependiendo únicamente de las soluciones tradicionales, es necesario adaptarnos y mejorar nuestras estrategias de mitigación, haciendo énfasis en las capas de aplicación y en soluciones más dinámicas y escalables.
En este post, exploraremos cómo han cambiado estos ataques, cómo funcionan en detalle y qué herramientas o estrategias podemos implementar para estar mejor preparados. Además, desarrollaremos un pequeño laboratorio para ilustrar estos conceptos de manera práctica.
Quiero recalcar que este post tiene un propósito meramente educativo. Aunque discutiremos ciertos aspectos técnicos, evitaré proporcionar detalles que puedan ser utilizados de forma malintencionada. El objetivo es entender por qué los ataques DoS están cambiando y qué pasos debemos tomar para protegernos de manera eficaz. La seguridad es una responsabilidad compartida, y aprender a defendernos es el primer paso para garantizar un entorno digital más seguro para todos.
"El Laboratorio" DDOS
En este laboratorio, he configurado dos máquinas virtuales independientes para analizar la dinámica de los ataques de denegación de servicio (DDoS) en capas 3, 4 y 7, con el objetivo de comprender cómo evolucionan estos ataques y cómo podemos enfrentarlos con mejores estrategias. Ambas máquinas están desplegadas en un hosting propio, sin ninguna arquitectura compleja, para mantener el entorno sencillo y enfocado en los objetivos específicos del experimento.
NOTA: Esta imagen refleja mi "amor" por lo que hago ;) . Ya que este tipo de post , me cuestan hasta dinero. Por eso , y aunque tristemente me duela, necesito poner algo de publicidad para cubrir estos gastos o al menos , parte de ellos.
En la primera máquina, he instalado MHDDoS, una herramienta poderosa y versátil para realizar ataques DoS y DDoS. Esta herramienta, desarrollada en Python, destaca por ofrecer hasta 56 métodos diferentes de ataque, cubriendo tanto las capas de red (3 y 4) como la capa de aplicación (7). Su simplicidad y capacidad para ejecutar ataques distribuidos la han convertido en una opción ampliamente utilizada en conflictos cibernéticos recientes, como la ciberguerrilla ucraniana y operaciones rusas. MHDDoS permite configurar ataques volumétricos masivos, como TCP Flood o UDP Flood, y también ataques más sofisticados dirigidos a aplicaciones web, como HTTP GET Flood y otros muchos mas complejos . En este laboratorio, lo que más me interesaba era su capacidad para simular ataques multicapas y observar cómo afectan a un sistema objetivo con recursos limitados, algo que en la realidad puede ser devastador si no se está preparado. ( Muchos de vosotros ya lo estáis sufriendo )
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.
Lo interesante de este enfoque es que combina el análisis técnico con una simulación práctica. Por un lado, MHDDoS permite probar métodos de ataque en condiciones controladas, mientras que NetData me ofrece una ventana clara para entender las consecuencias en la infraestructura. Durante las pruebas, quedó claro cómo un atacante con recursos mínimos puede generar un impacto significativo, especialmente cuando combina ataques volumétricos en capas 3 y 4 con estrategias más específicas en la capa 7. Esto refleja la necesidad urgente de evolucionar nuestras estrategias de mitigación. Incluso, como podéis observar en MHDDOS, el numero de métodos de L7 respecto a L4 , es mucho mayor, prácticamente , dejando ancladas en el pasado las soluciones Legacy de L3-4 .
El objetivo de este laboratorio no es solo explorar cómo funcionan los ataques, sino también mostrar por qué es crucial adaptar nuestras defensas. Este post es, y lo repito de nuevo, una herramienta educativa para reflexionar sobre la importancia de proteger nuestras infraestructuras frente a una amenaza que está en constante evolución.
Como traca final, y para mostrar la importancia de nuestra tesis, intentaremos simular un ataque , lo mas grande que podamos "que no nos cueste mucho" , atacando nuestro propio blog que tenemos protegido con Cloudflare, una de las mejores opciones domesticas que podemos usar.
NOTA: Para minimizar posibles malos usos, y aunque esta publicado en su site, obviaremos la parte de instalación y configuración de MHDDOS, centrándonos en los métodos y resultado de los mismos, intentando buscar conclusiones que nos ayuden a mínimizar el impacto de estos ataques.
De DoS a DDoS con MHDDOS
Al trabajar con MHDDoS para lanzar las pruebas en el laboratorio, me encontré con una diferencia clave en la forma en que los ataques se comportan dependiendo de cómo se configuren los proxys. Si no se especificaban correctamente los proxys en los parámetros del ataque, todo el tráfico malicioso salía directamente desde la máquina que ejecutaba MHDDoS, es decir, desde una única IP: la del servidor configurado para el laboratorio ( 155.138.174.242 ) . Esto hacía que el ataque fuera fácilmente rastreable y mucho más sencillo de mitigar, ya que el origen del tráfico estaba centralizado. Sin embargo, al configurar los proxys correctamente, el comportamiento del ataque cambiaba radicalmente: el tráfico ahora parecía provenir de múltiples ubicaciones distribuidas, simulando un ataque DDoS (Distributed Denial of Service).
Esta diferencia no solo es técnica, sino que también refleja dos conceptos fundamentales en la ciberseguridad: un ataque DoS y un ataque DDoS. En un ataque DoS (Denial of Service), todo el tráfico malicioso proviene de una única fuente, como en nuestro caso cuando la máquina generadora no utiliza proxys. Esto lo hace más fácil de detectar y bloquear, ya que se pueden aplicar contramedidas, como el filtrado por IP, en los sistemas de defensa del objetivo. Sin embargo, su simplicidad no significa que no sea efectivo. Si el ataque tiene suficiente intensidad, aún puede colapsar los servicios si el objetivo no cuenta con recursos suficientes para manejar la carga.
Por otro lado, un ataque DDoS (Distributed Denial of Service), como el que se genera al utilizar proxys en MHDDoS, distribuye el tráfico entre múltiples fuentes, haciendo que parezca que proviene de diversas ubicaciones geográficas. Esto no solo aumenta la escala del ataque, sino que también complica significativamente su mitigación. Al dispersar las solicitudes maliciosas, el objetivo no puede identificar fácilmente una única fuente que bloquear, lo que exige el uso de soluciones más avanzadas, como sistemas de mitigación basados en inteligencia artificial o servicios externos especializados en defensa contra DDoS.
Durante las pruebas, estas diferencias fueron claramente visibles. En las capturas de tráfico realizadas, observamos que cuando no se configuraban los proxys, todos los paquetes maliciosos compartían la misma IP origen, lo que hacía que el ataque tuviera un patrón predecible. Por el contrario, al activar los proxys, el tráfico adquiría una distribución mucho más amplia, con múltiples direcciones IP en las cabeceras de origen, simulando una red de bots o una botnet distribuida.
Este ejercicio demuestra la importancia de entender cómo operan estas herramientas y sus configuraciones. Aunque el propósito de este laboratorio es puramente educativo, es evidente que, en manos malintencionadas, una configuración adecuada de proxys puede convertir un ataque relativamente sencillo en uno extremadamente difícil de manejar. Estas pruebas también subrayan la relevancia de contar con estrategias de mitigación modernas y adaptativas, capaces de identificar patrones anómalos incluso en ataques distribuidos.
DoS VS DDoS
Durante las primeras pruebas con MHDDoS, configuré un ataque TCP dirigido al puerto 80 de la máquina objetivo, convencido de que estaba utilizando correctamente una lista de proxys. Sin embargo, rápidamente me di cuenta de que no era así. Aunque el ataque parecía ejecutarse de manera funcional, todo el tráfico se originaba desde una única IP, la de nuestro servidor que ejecutaba MHDDoS. Esto sucedió porque la lista de proxys no estaba configurada adecuadamente, un error que destaca la importancia de entender cómo funcionan estos parámetros en herramientas avanzadas como esta.
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.
La captura de tráfico, realizada con herramientas como tcpdump, fue clave para identificar este problema. En la imagen, se puede observar cómo cada paquete del ataque comparte la misma IP de origen. Esto confirma que el ataque se comportó como un DoS convencional, en el que todo el tráfico proviene de una única fuente. Aunque el ataque fue funcional, este patrón lo hacía mucho más sencillo de mitigar, ya que la máquina objetivo podría simplemente bloquear esa IP.
Este error inicial me permitió profundizar en cómo MHDDoS maneja los proxys y cómo una configuración incorrecta puede limitar severamente su funcionalidad. Aprendí que no solo es crucial cargar una lista de proxys válida, sino también entender cómo y cuándo se aplican durante la ejecución del ataque. Esta experiencia resalta la importancia de realizar pruebas controladas y analizar cuidadosamente los resultados para identificar posibles errores de configuración antes de utilizarlos en un entorno más amplio.
La siguiente captura de pantalla muestra claramente la diferencia entre este ataque mal configurado y los posteriores ( Imagen de arriba ), donde corregí los parámetros y logré una distribución efectiva del tráfico a través de proxys.
Como se puede observar en la imagen, el comportamiento del ataque cambia completamente al corregir la configuración de los proxys. Mientras que inicialmente todo el tráfico provenía de una única IP (la del servidor que ejecuta MHDDoS), tras ajustar correctamente la lista de proxys, el tráfico se distribuyó a través de múltiples direcciones IP, simulando un ataque distribuido. Esto refleja claramente cómo una configuración adecuada puede transformar un ataque DoS básico en un ataque DDoS mucho más sofisticado y difícil de mitigar.
Lo más llamativo de estas pruebas es que ambos ataques, tanto el centralizado como el distribuido, resultaron sorprendentemente efectivos a pesar de las limitaciones de recursos de la máquina que ejecutaba MHDDoS. Estamos hablando de un entorno de laboratorio en el que el servidor atacante cuenta con apenas 4 GB de memoria RAM y 2 CPUs virtuales. Con esta configuración modesta, y sin llevar la máquina al límite, conseguimos generar un tráfico de ataque de hasta 700 Mbps, una cantidad significativa que sería suficiente para saturar infraestructuras mal preparadas.
En la imagen que acompaña esta explicación, se puede ver cómo el throughput generado alcanza picos altos, independientemente de si el tráfico provenía de una única IP o estaba distribuido a través de proxys. Esto demuestra lo eficiente que puede ser MHDDoS incluso en condiciones de hardware limitadas. Además, subraya la necesidad de contar con estrategias de mitigación robustas que puedan manejar tanto ataques centralizados como distribuidos, ya que ambos pueden causar daños considerables dependiendo de las circunstancias.
Ataques DDoS
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.
Mi 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:
Ataques DDoS Capa 4
TCP Flood
El ataque TCP Flood al puerto 80 fue el punto de partida de este laboratorio y, como mencioné anteriormente, incluso con una configuración básica, conseguimos generar hasta 700 Mbps de tráfico. Este ataque demuestra la potencia de herramientas como MHDDoS, y también sirve como una introducción para entender las diferencias clave entre los ataques centralizados y distribuidos.
En la primera prueba, ejecutamos el ataque sin configurar una lista de proxys. Como resultado, todo el tráfico generado provenía directamente desde la IP del servidor que ejecutaba MHDDoS. Esto queda claramente reflejado en la captura de tráfico, donde cada paquete malicioso tenía la misma dirección IP de origen.
NOTA: He tenido que subir los archivos a MEGA por el tamaño de los mismos
En la segunda prueba, configuramos correctamente una lista de proxys. Esta configuración transformó el ataque en un DDoS distribuido, donde el tráfico malicioso aparentaba venir de múltiples ubicaciones. En la captura de tráfico de esta prueba, podréis observar cómo las direcciones IP de origen son variadas, lo que dificulta considerablemente la mitigación. Este cambio convierte el ataque en una amenaza mucho más compleja, especialmente si la infraestructura objetivo no cuenta con soluciones avanzadas como WAFs distribuidos o servicios de mitigación DDoS en la nube.
Un punto crítico que quiero destacar es que estas capturas, aunque realizadas en un entorno controlado, generaron cientos de Mbps en cuestión de segundos. Si dejáis correr este tipo de pruebas durante un minuto, podríais estar generando más de 10 gigas. Por ello, si decidís replicar estos experimentos, es fundamental hacerlo en un entorno completamente aislado y con las precauciones necesarias para evitar cualquier impacto no deseado.
Análisis TCP Flood
A continuación, realizaré un análisis detallado de las capturas de tráfico obtenidas durante los ataques de TCP Flood al puerto 80. En este análisis, exploraremos patrones clave que nos permiten identificar este tipo de ataque, como la repetitividad de las solicitudes, el uso de proxys, y el impacto en la red objetivo. A través de las capturas, podremos observar cómo varía el comportamiento del tráfico según la configuración empleada, proporcionando una visión clara de las características distintivas de estos ataques. Las imágenes que se incluyen servirán como referencia para entender mejor estos patrones y cómo se reflejan en el tráfico capturado.Lo haremos de igual forma en el resto de ataques que iremos viendo.
- Conexiones masivas y cortas: Busca múltiples solicitudes entrantes (SYN) al puerto 80 sin la correspondiente finalización (ACK).
tcp.flags.syn == 1 and tcp.flags.ack == 0
- Fuentes sospechosas: Analiza si hay un número anormalmente alto de direcciones IP de origen (indicador de proxys o bots):
Ve al menú: Statistics > Endpoints, selecciona la pestaña IPv4 y verifica la columna de paquetes.
- Filtrado: Podríamos aislar el trafico sospechoso, combinado con paquetes duplicados.
tcp.flags.syn == 1 and tcp.dstport == 80 and frame.time_delta < 0.01
Esto muestra tráfico con muy poco tiempo entre paquetes, típico de ataques de inundación
También podéis ver la distribución geográfica de las IPs en Wireshark, con servicios tan conocidos como MaxMind y su Base de Datos GeoLite2 , añadiéndolo a Wireshark, algo que nos ahorrará mucho tiempo en muchos casos en los que no tengamos acceso a los sistemas como FW o ADDoS , o para ver si la concordancia de países es correcta, con el fin de bloquear por país.
Lo que nos dará mucha información en puntos como Endpoints
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.
Lo que quiero resaltar con esto es una tendencia clara que ya comenzó a manifestarse en 2024, pero que será aún más pronunciada en 2025: el aumento de ataques de denegación de servicio enfocados en la capa 7.
Este cambio representa un reto enorme para las infraestructuras actuales, ya que no solo son más difíciles de identificar y mitigar, sino que también permiten una distribución mucho más amplia con recursos mínimos. Por eso, es imperativo que empecemos a centrar nuestra atención en este tipo de amenazas, ya que serán uno de los principales desafíos en el panorama de la ciberseguridad el próximo año.
Con esto , solo nos quedaba por ver el de una forma distribuida, CPS | Open and close connections with proxy y CONNECTION | Open connection alive with proxy . Os traslado ciertas pinceladas, pero podeis ver y analizar todos en vuestros laboratorios ( Si no se haría infinito el post , sorry ).
Ataque DDoS CPS | Open and close connections with proxy
Sumado a los filtros anteriormente vistos , en este tipo de ataque, como su nombre indica, se basa en abrir y cerrar multiples conexiones mediante proxy. En el que el factor volumétricos no es tan significativo como el visto en TCP, basándose en intentar sobrecargar el servicio o los sistemas.
- Conexiones que terminan rápidamente : Con tráfico FIN o RST inmediatamente después del handshake.
Pudiendo filtrarlo facilmente :
tcp.flags.fin == 1 or tcp.flags.reset == 1
Os dejo la captura para el análisis:
Como dato curioso, al observar el gráfico generado por el ataque, se puede notar que, aunque volumétricamente no alcanza siquiera algunos megas, su característica más llamativa es su forma dentada. Esto se debe a los picos y cortes abruptos que se reflejan en el tráfico, causados por las conexiones intermitentes y las desconexiones propias del uso de proxys. Este patrón, que se asemeja a los dientes de una sierra, es un indicador claro del comportamiento de este tipo de ataques. Os dejo el gráfico para que podáis analizarlo, ya que representa de manera visual cómo las conexiones y los cortes configuran un tráfico tan particular.
Ataque DDoS CONNECTION | Open connection alive with proxy
Este tipo de ataques , es facilmente identificable, ya que se basa en dejar conexiones abiertas por un largo periodo de tiempo. Podríamos identificarlo en nuestros sistemas balanceadores , o también mediante una simple captura de tráfico, vamos al lio:
- Conexiones que no se han cerrado: Conexiones abiertas (sin FIN ni RST)
tcp.flags.fin == 0 and tcp.flags.rst == 0
- Identificar Keep-Alive : Filtra paquetes TCP con Keep-Alive
tcp.analysis.keep_alive
Al analizar el Flag keep_alive , no os asusteis , a nosotros solo nos venia de 5 IPs de todas, esto es debido a que el mecanismo Keep-Alive es opcional. No todos los sistemas o aplicaciones lo implementan, y puede ser que no todos los proxy sean capaces de retransmitirlo. También en los ataques, se evita enviarlo con el fin de que pase desapercibido, pero no esta de mas buscarlo:
El flag tcp.analysis.keep_alive es una interpretación de Wireshark, no un atributo inherente de los paquetes TCP, si los paquetes no cumplen los criterios específicos de Wireshark (e.g., carga útil específica o tiempo entre paquetes), no se marcarán como tcp.analysis.keep_alive, por lo que es recomendado buscar de más formas:
- Tráfico con bajo flujo de datos: Filtraremos las conexiones TCP que permanecen abiertas pero tienen poca o ninguna carga útil
tcp.len == 0
O también podemos revisar la duración de las conexiones en Statistics > Conversations y en la pestaña TCP, revisando la columna de Duration con el fin de buscar conexiones con tiempos extremadamente largos:
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.
Uno de los desafíos más evidentes de los ataques L7 es que los atacantes están evolucionando sus tácticas. En muchos casos, comienzan saturando las capas inferiores (L3-L4) para desviar la atención de los sistemas de mitigación y, cuando estos están enfocados en manejar el volumen de tráfico en esas capas, redirigen el ataque hacia L7. Aquí es donde los sistemas convencionales fallan, ya que no están diseñados para gestionar este tipo de tráfico malicioso orientado a la capa de aplicación. El resultado es que, incluso con medidas como el filtrado de tráfico por país o región, los atacantes encuentran formas de evadir estas barreras, utilizando IPs distribuidas de forma precisa, por ejemplo, únicamente de países como España o Estados Unidos, donde el negocio objetivo opera.
No podemos seguir confiando en sistemas antiDDoS que solo abordan un aspecto del problema, ni en estrategias que dependen de la colaboración fragmentada entre diferentes ISPs o equipos con capacidades limitadas para manejar ataques distribuidos en capas superiores.
La realidad es que, para 2025, debemos evolucionar hacia soluciones integrales capaces de mitigar en todas las capas de manera eficiente, sin necesidad de depender de múltiples contratos o infraestructuras especializadas que aumenten la complejidad y reduzcan la eficacia.
Por otro lado, los equipos encargados de gestionar la mitigación de DDoS en capas inferiores no suelen estar preparados para enfrentar L7. Esto subraya la importancia de unificar esfuerzos entre los sistemas de defensa existentes y nuevas soluciones enfocadas en la capa de aplicación. Solo de esta manera podremos enfrentar los retos que los ataques de denegación de servicio nos plantearán en los próximos años.
En mi opinión, los ataques L7 serán un punto clave en el panorama de ciberseguridad para 2025.
La capacidad de nuestras infraestructuras para mitigar este tipo de amenazas definirá su resiliencia. Este es el momento de centrar nuestros esfuerzos en esta tecnología, evolucionar nuestras estrategias y estar preparados para enfrentar este cambio inevitable en el mundo de la ciberseguridad.
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".
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 multiples "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 ningúna 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 envio:
Realice , distintas replica ( 1 - 2 ) en las que posteriormente amplifiquelo 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 Metodo 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 facilmente :
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.
2025 - El año en que cambiaras o deberías tus sistemas DDoS
A lo largo de este post, hemos explorado en profundidad cómo han evolucionado los ataques de denegación de servicio (DoS y DDoS) desde enfoques volumétricos en capas 3 y 4 hasta tácticas más sofisticadas y dirigidas en capa 7. Utilizando herramientas como MHDDoS, hemos visto cómo estas amenazas se han diversificado, y he dejado múltiples ejemplos y capturas para que podáis analizarlas en detalle. Los ataques ya no se tratan únicamente de saturar el ancho de banda con tráfico masivo, ahora, su verdadera eficacia reside en el uso estratégico de métodos complejos que explotan la capacidad de procesamiento y los recursos internos de los sistemas, llevando servidores, firewalls y balanceadores al límite sin necesidad de grandes volúmenes de datos. Este cambio nos obliga a replantearnos por completo cómo diseñamos y gestionamos nuestras estrategias de mitigación DDoS.
Uno de los puntos clave que quiero destacar es la necesidad de unificar la gestión de ataques de capas 3, 4 y 7. Hasta ahora, la mayoría de los sistemas de defensa estaban diseñados para lidiar con ataques volumétricos clásicos, pero como hemos demostrado en este análisis, este enfoque es insuficiente frente a las amenazas actuales. No basta con sistemas separados para diferentes capas, debemos buscar soluciones integrales o, en su defecto, asegurarnos de que nuestros equipos de mitigación puedan trabajar de manera coordinada.
Mi tendencia para 2025 es clara: debemos evolucionar hacia tecnologías que combinen capacidades de mitigación en todas las capas, ya sea a través de un único proveedor o mediante una integración eficiente de soluciones como WAFs, sistemas de capa 7 y defensa perimetral en 3 y 4. Además, para multinacionales o empresas con presencia global, esta unificación es aún más crítica, ya que contar con sistemas dispersos e independientes por región solo añade complejidad y reduce la eficacia frente a ataques distribuidos.
Quiero también resaltar que, aunque la inteligencia artificial parece ser una tendencia emergente, la clave real para 2025 no es depender de sistemas futuristas, sino mejorar y evolucionar nuestras tecnologías actuales para adaptarnos a estas nuevas tácticas. En este sentido, debemos priorizar inversiones en herramientas que no solo detecten, sino que también respondan de forma proactiva a las amenazas en todas las capas. Este enfoque garantizará una mayor resiliencia y optimización de recursos frente a un panorama de amenazas en constante cambio.
Finalmente, quiero agradeceros por acompañarnos en este extenso post que comenzó en 2024 y que concluye ahora en 2025. Este post me ha llevado días de trabajo, no solo escribiéndolo, sino también realizando los laboratorios y pruebas que respaldan cada punto expuesto. Mi propósito para este nuevo año es seguir creando contenido técnico y práctico como este, que no solo explique conceptos, sino que también los demuestre con ejemplos reales.
Os deseo a todos un fantástico 2025 lleno de aprendizajes y retos, y espero que este análisis os ayude a reflexionar sobre la importancia de evolucionar vuestras infraestructuras y estrategias de defensa. Si algo debe ser una prioridad para vuestros próximos presupuestos, es sin duda la adaptación a esta nueva generación de ataques de denegación de servicio. ¡Feliz año nuevo y sigamos construyendo juntos un futuro más seguro!