Steven Z., pentester y cazador de recompensas por fallos de Colombia, ha publicado en GitHub Bulldosser, la herramienta que asegura usar en sus auditorías para hacer pruebas de denegación de servicio (DoS). Según explica en LinkedIn, despliega más de 500 contenedores Docker en distintas regiones de Azure, cada uno con su propia IP pública, para inundar de peticiones un servidor web, y afirma haber tumbado con ella servidores protegidos por Cloudflare, AWS, Sophos y Fortinet. Esas afirmaciones no están verificadas de forma independiente, y el uso que describe choca con las reglas de Microsoft para Azure.
Las claves de Bulldosser en 30 segundos
- Bulldosser usa Azure Container Instances para lanzar peticiones desde hasta 56 regiones a la vez.
- Reproduce una petición real de navegador, con cookies y cabeceras, para que el tráfico parezca legítimo.
- Incluye inundación HTTP y técnicas lentas conocidas como Slowloris, Slow POST y Slow Read.
- Las reglas de pruebas de Microsoft prohíben cualquier prueba de denegación de servicio lanzada desde Azure.
El repositorio se creó el 6 de noviembre de 2026, tiene licencia MIT y, cuando lo consultamos, aún no tenía estrellas ni bifurcaciones. Su README la describe como un marco de pruebas de estrés distribuidas pensado para pruebas de carga y de penetración autorizadas, y avisa de que usarla contra un sistema sin permiso por escrito es delito en la mayoría de países. El autor sostiene que no considera completo un pentest sin una prueba de denegación de servicio y que siempre pide al cliente fecha y hora para el ataque.
Qué hace, según su autor
La arquitectura que describe combina scripts de Python, el SDK de Azure y contenedores Docker repartidos por múltiples regiones, con la opción de anonimizar el tráfico con Tor. El punto que más preocupa a quien defiende una web es la técnica de partida: cada contenedor recibe una copia de una petición real capturada desde el navegador, con cookies de sesión y cabeceras que imitan la huella de un navegador. Según el README, eso hace que cortafuegos como el de Cloudflare dejen pasar el tráfico «dependiendo de la configuración», porque no parece el de un bot.
Junto a esa inundación HTTP, que el autor presenta como técnica propia, incorpora ataques lentos documentados desde hace años: Slowloris mantiene abiertas muchas conexiones enviando cabeceras a cuentagotas, Slow POST envía el cuerpo de una petición muy despacio y Slow Read lee la respuesta con lentitud para retener recursos del servidor. No hay nada nuevo en ellas; su eficacia depende sobre todo de cómo estén configurados los tiempos de espera y los límites de conexiones del servidor.
El choque con las reglas de Azure
Aunque el cliente autorice la prueba, la infraestructura desde la que se lanza también tiene normas. Las reglas de pruebas de penetración de Microsoft Cloud prohíben cualquier prueba de denegación de servicio, incluidas las que solo pretenden simularla, y califican los ataques distribuidos (DDoS) de estrictamente prohibidos en cualquier circunstancia. Microsoft también veta las pruebas automatizadas que generan tráfico excesivo. Para comprobar la resistencia a DDoS remite a socios aprobados, como BreakingPoint Cloud, Red Button o RedWolf, que hacen simulaciones controladas contra objetivos protegidos con Azure DDoS Protection. Azure, además, tiene detección automática de abusos en el tráfico saliente.
Hay otra objeción habitual entre profesionales: una prueba de DoS contra un servicio detrás de un CDN, un proveedor de alojamiento compartido o una nube pública afecta también a infraestructura de terceros que no ha dado permiso. Por eso la mayoría de proveedores exige coordinación previa. En España, obstaculizar o interrumpir sin autorización el funcionamiento de un sistema informático ajeno está castigado en el artículo 264 bis del Código Penal, así que la autorización por escrito y el alcance exacto de la prueba no son una formalidad.
Qué pueden hacer los defensores
Publicar la herramienta no cambia el tipo de ataque, pero sí lo pone al alcance de más gente. Para una web, las medidas son conocidas: limitar la tasa de peticiones por sesión y no solo por IP, porque aquí cada contenedor tiene su propia dirección; vigilar cookies de sesión reutilizadas desde muchas IP distintas a la vez; ajustar en el servidor o en el proxy los tiempos de espera de cabeceras y cuerpo y el número máximo de conexiones por cliente frente a los ataques lentos, y servir desde caché todo lo posible para que las peticiones no lleguen al origen. También conviene que el origen solo acepte tráfico del CDN o del WAF, para que nadie pueda saltarse la protección atacando su IP directamente.
Preguntas frecuentes
¿Qué es Bulldosser?
Una herramienta de código abierto que despliega contenedores en Azure para generar tráfico masivo contra una web, presentada por su autor para pruebas de denegación de servicio autorizadas.
¿Se pueden hacer pruebas de DoS desde Azure?
No por cuenta propia. Las reglas de Microsoft las prohíben y remiten a socios aprobados para simular ataques DDoS de forma controlada.
¿Está comprobado que tumba webs protegidas por Cloudflare?
No. Es una afirmación de su autor; el propio README dice que el resultado depende de la configuración de cada protección.
¿Cómo me protejo de ataques lentos como Slowloris?
Ajustando los tiempos de espera de cabeceras y cuerpo y limitando las conexiones por cliente en el servidor o en el proxy inverso.
Fuentes:
