Read the Docs sufrió un DDoS de 5,5 millones de peticiones por minuto durante diez días
Understanding the recent DDoS attack against Read the Docs
En junio de 2026, Read the Docs enfrentó el mayor ataque DDoS de su historia: más de 5,5 millones de peticiones por minuto desde millones de IPs, con aleatorización de cabeceras y TLS y evasión de caché. El equipo detalla cómo el rate limiting por IP resultó insuficiente y cómo el cacheo agresivo, las reglas combinadas con puntuaciones de bots y el uso de Terraform les permitieron mantener la disponibilidad.
Los atacantes sabían que teníamos un firewall de aplicaciones web con límites de tasa y sabían cómo causar el mayor daño posible a pesar de ello.
- PinkSheep
Lamento el estrés que tuvo que soportar el equipo mitigando este ataque. Aun así, siempre me emociona ver señales de competencia en el lado atacante: ¿un ataque dirigido, específico de la aplicación y adaptativo en la capa L7? ¡Guau!
Aquí va otra conjetura: un DDoS para robar tu atención y enmascarar otros intentos de intrusión.
> Las defensas necesitan tener límites de tasa más amplios que abarquen más que solo IPs (ASNs, nombres de host, etc.).
¿La descripción/enfoque parece estático y limitado? ¿Por qué no mantener un leaky bucket que cuente cada petición (tickets/puntos) con un coste mayor para las peticiones costosas (404, redirecciones)? A medida que la reputación de la IP se deteriora (IPv4/32), empieza a desbordarse hacia una subred más amplia como IPv4/31, luego /30, y así sucesivamente. Combate la adaptabilidad con adaptabilidad. // quizá estoy describiendo algo totalmente obvio, no estoy involucrado en el lado de la protección DDoS web.
> Los atacantes buscan activamente rutas no cacheables (p. ej., redirecciones dinámicas, endpoints de búsqueda y 404s).
Para continuar con mi punto anterior. Siempre que los recursos de cada servidor lo permitan (memoria, límite de sockets), retén las peticiones antes de procesarlas. Las IPs de baja reputación se retienen durante más tiempo y las peticiones que exceden la cola se descartan. La idea es la degradación gradual:
Una IP con buena reputación no se retendrá por sleep(). Una IP con mala reputación se retendrá, pero eventualmente recibirá su respuesta en lugar de algún 429/403 (es decir, un usuario que abrió muchas pestañas a la vez). Una IP con pésima reputación se ralentizará por los tiempos de espera + los límites de tasa (cola excedida) antes de ser completamente blo […]
- Animats
Me gustaría ver más una respuesta legal.
Primero, averiguar quién está al otro lado de unos cientos de direcciones IP. Empezar por las de EE. UU. Demandar por daños. Usar el descubrimiento de pruebas para averiguar qué hay al otro lado. Demandar al fabricante de ese dispositivo. Si resulta ser un electrodoméstico o un smart TV, puede ser posible consolidar los casos en uno solo contra el fabricante. Negligencia criminal, interferencia torticera con contrato, acoso, violación de la Computer Fraud and Abuse Act...
Quizá una orden de restricción que prohíba la venta de "smart TVs" que se sepa que pueden alojar ataques. Hacer que la Aduana y Protección Fronteriza incaute las importaciones. Eso llamaría la atención de un fabricante.
El EULA del fabricante no ayudará al fabricante, porque el demandante, la parte atacada, no es parte del EULA en absoluto.
- PinkSheep
> estaban saturando una redirección de Nginx hardcodeada (una simple directiva de reescritura con regex)
1. Me pregunto cuánta optimización tiene ngx_http_rewrite_module. ¿Precompila los patrones? El LLM dijo que sí, esta respuesta de SO [1] dice que debe estar activada una opción de configuración JIT. Considero que "Just In Time" es una medida a medias cuando la configuración en sí es estática.
2. Al mirar la documentación de NGINX, me parece que hay algunas trampas al escribir estas reglas. ¿Como que debes asegurarte manualmente de cortocircuitar las reescrituras para salir antes de tiempo?
3. La advertencia de las regex es que las regex con backtracking catastrófico parecen simples. No veo que se hable lo suficiente de este problema. Ver los enlaces, por si tú, lector, aún no has oído hablar de ello.
[1] https://stackoverflow.com/questions/59284921/how-much-impact...
[3.1] https://joshua.hu/nginx-directives-regex-redos-denial-of-ser...
[3.2] https://en.wikipedia.org/wiki/ReDoS
[3.3] https://infrafolks.com/blog/regex-backtracking-devops/
[3.4] https://www.regular-expressions.info/catastrophic.html
- fn-mote
Existe la suposición de que activar el modo "under attack" de Cloudflare mitigaría el ataque.
Dado lo adaptativo que fue el resto del ataque, me daría mucha curiosidad descubrir cómo abordaría ese obstáculo.
- bijowo1676
esto podría ser un ataque impulsado por IA y readthedocs era solo un objetivo de prueba.
Lo que me sorprendió es lo fácil que fue evadir las defensas de Cloudflare. Sé que era fácil evadir CF, pero esperaba que CF hiciera un mejor trabajo bloqueando DDoS de capa L7.
CF es realmente bueno defendiendo contra DDoS de capa L4, pero no de L7.
esto significa que Cloudflare realmente no es muy útil en la era del DDoS agéntico impulsado por miles de agentes por todo el mundo