5,5 millones de requests por minuto: el DDoS que puso a Read the Docs a prueba durante diez días

Read the Docs es de esos servicios que uno da por sentados. Cada librería de Python que abriste en tu vida probablemente estaba hosteada ahí, y nadie se acuerda de que detrás hay un equipo de operaciones chico manteniendo todo andando. A fines de junio de 2026 ese equipo dejó de dormir: sufrieron el ataque DDoS más grande y sofisticado de su historia, y hace poco publicaron el recuento completo. Vale la pena leerlo, porque es una clase gratis de cómo se ve un ataque moderno desde adentro.

Los números dan miedo

En su peak, la infraestructura recibió 5,5 millones de requests por minuto. Para dimensionar: su tráfico normal de punta diaria es de menos de 100 mil requests por minuto. Estamos hablando de unas 100 veces el baseline. El ataque duró casi diez días y no fue un flood de manual: venía de millones de IPs únicas repartidas en cientos de redes (ASNs), incluyendo bloques residenciales.

Lo interesante es que los atacantes sabían lo que hacían. Randomizaron headers HTTP y parámetros TLS para evadir firmas tipo JA3/JA4. Buscaron deliberadamente URLs que generaban cache misses: páginas inexistentes (404) y redirecciones temporales (302) que se servían desde el backend Python en vez del edge. Y aplicaron lo que llaman un patrón yo-yo: subir tráfico hasta descubrir los umbrales del rate limiting, retirarse para que la ventana expire, y volver. El objetivo no es solo tirar el servicio, es maximizar el costo de tu infraestructura auto-escalada. Si tu respuesta a la carga es escalar horizontalmente, estás pagando la factura del ataque tú mismo.

La lección incómoda: bloquear IPs no sirve

El take away más duro del post es que el bloqueo por IP está obsoleto para ataques distribuidos. Con proxies residenciales baratos (los mismos que usan los scrapers de IA, por cierto), la lista de bloqueo es una wea decorativa. Read the Docs terminó combinando decenas de reglas de rate limiting sobre IPs, ASNs, hostnames y fingerprints de navegador, todo gestionado con Terraform para poder versionar y revertir rápido.

Y cachear todo. Literalmente todo: incluso los 404 y las redirecciones con una ventana de unos minutos. Los atacantes detectaban qué rutas no estaban cacheadas midiendo tiempos de respuesta, y por ahí entraban. Un simple rewrite de Nginx que no está cacheado en el CDN puede ser tu punto de falla.

Mi opinión

Lo que más me gustó del manejo es una decisión de diseño: siempre dar una salida al usuario real. En vez de activar el modo Under Attack de Cloudflare (que rompe toda integración de API con challenges de JavaScript), optaron por challenges dirigidos combinando puntajes de probabilidad de bot con límites por IP. Si un humano resuelve el challenge, queda libre por un día. Fricción mínima para los legítimos, daño máximo para el botnet.

Hay algo que me resuena personalmente acá. Administro un par de VPS y servicios pequeños, y siempre pensé que un DDoS volumétrico era problema de los grandes. El post cierra con lo contrario: con las herramientas de IA y las redes de proxies abaratando todo, este tipo de ataques ya no son reservados para empresas, se están volviendo la línea base para cualquier servicio público con un mínimo de perfil. La defensa en profundidad (CDN, caché agresivo, WAF, rate limiting, fingerprinting) deja de ser lujo de enterprise y pasa a ser la pega de cualquiera que exponga algo a internet. Y ojo con el detail final: parte del tráfico malicioso venía de scrapers conectados a redes de proxies, la misma infraestructura de la fiebre del oro de la IA. Las facturas de esa carrera la estamos pagando todos.

Fuente de inspiración: Understanding the Recent DDoS Attack Against Read the Docs