Read the Docs wehrt sich gegen 5,5 Millionen Anfragen pro Minute
Understanding the recent DDoS attack against Read the Docs
Im Juni 2026 traf Read the Docs der größte DDoS-Angriff seiner Geschichte: 5,5 Millionen Anfragen pro Minute, das 100-Fache der normalen Last, aus Millionen von IP-Adressen weltweit. Die Angreifer randomisierten Header und TLS-Parameter, umgingen Caches und passten sich den Abwehrmaßnahmen an. Das Team erklärt, warum IP-Sperren nutzlos sind, wie Edge-Caching und gezielte Rate-Limits halfen und warum Terraform für die WAF-Regeln entscheidend war.
Angreifer rampten hoch, um unsere Rate-Limit-Schwellen zu entdecken, und zogen sich dann zurück, damit die Rate-Limit-Fenster abliefen. Das nennt man ein Yo-Yo-Muster, und es ist darauf ausgelegt, die finanziellen Kosten auto-skalierender Infrastruktur zu maximieren und intermittierende Serviceverschlechterungen zu verursachen.
- PinkSheep
Sorry für den Stress, den das Team bei der Abwehr dieses Angriffs hatte. Trotzdem freue ich mich immer, wenn ich Anzeichen von Kompetenz auf der Angreiferseite sehe: ein gezielter, anwendungsspezifischer und adaptiver Angriff auf L7? Wow!
Hier ist eine weitere Vermutung: Ein DDoS, um deine Aufmerksamkeit zu stehlen und andere Eindringversuche zu verschleiern.
> Abwehrmaßnahmen müssen breitere Rate Limits über mehr als nur IPs haben (ASNs, Hostnames, etc.).
Die Beschreibung/der Ansatz scheint statisch und begrenzt? Warum nicht einen Leaky Bucket pflegen, der jede Anfrage zählt (Tickets/Punkte) mit höheren Kosten für teure Anfragen (404, Redirects). Wenn sich die Reputation der IP verschlechtert (IPv4/32), beginnt sie auf ein breiteres Subnetz wie IPv4/31, dann /30 und so weiter überzuschwappen. Bekämpfe Adaptivität mit Adaptivität. // Vielleicht beschreibe ich etwas völlig Offensichtliches, ich bin nicht in der Web-DDoS-Schutz-Seite der Dinge involviert.
> Angreifer suchen aktiv nach nicht cachebaren Pfaden (z. B. dynamische Redirects, Such-Endpunkte und 404s).
Um mit meinem vorherigen Punkt fortzufahren. Solange die Ressourcen des einzelnen Servers es zulassen (Speicher, Socket-Limit), halte Anfragen zurück, bevor du sie verarbeitest. IPs mit niedriger Reputation werden länger zurückgehalten und die Anfragen, die die Warteschlange überschreiten, werden verworfen. Die Idee ist eine sanfte Degradierung:
Eine IP mit guter Reputation wird nicht durch sleep() aufgehalten. Eine IP mit schlechter Reputation wird aufgehalten, erhält aber schließlich ihre Antwort statt eines 429/403 (d. h. ein Benutzer, der viele Tabs auf einmal geöffnet hat). Eine IP mit sehr schlechter Reputation wird durch die Wartezeiten + Rate-Limits (Warteschlange überschritten) verlangsamt, bevor sie vollständig blockiert wird […]
- Animats
Ich würde mir eine stärkere rechtliche Reaktion wünschen.
Zuerst finde heraus, wer am anderen Ende von ein paar hundert IP-Adressen steht. Beginne mit denen in den USA. Verklage auf Schadensersatz. Nutze Discovery, um herauszufinden, was am anderen Ende ist. Verklage den Hersteller dieses Geräts. Wenn es sich um ein Gerät oder einen Smart-TV handelt, könnte es möglich sein, Fälle zu einem Fall gegen den Hersteller zusammenzufassen. Kriminelle Fahrlässigkeit, vorsätzliche Vertragsbeeinträchtigung, Belästigung, Verstoß gegen den Computer Fraud and Abuse Act...
Vielleicht eine einstweilige Verfügung, die den Verkauf von „Smart TVs“, die bekanntermaßen Angriffe hosten können, verbietet. Lass Importe vom Customs and Border Protection beschlagnahmen. Das würde die Aufmerksamkeit eines Herstellers erregen.
Die EULA des Herstellers wird dem Hersteller nicht helfen, weil der Kläger, die angegriffene Partei, überhaupt keine Partei der EULA ist.
- PinkSheep
> Sie überwältigten einen hartcodierten Nginx-Redirect (eine einfache Rewrite-Regex-Direktive)
1. Ich frage mich, wie viel Optimierung ngx_http_rewrite_module hat? Kompiliert es die Muster vor? LLM sagte ja, diese SO-Antwort [1] sagt, dass eine JIT-Konfigurationsoption aktiviert sein muss. Ich halte „Just in Time“ für eine halbe Maßnahme, wenn die Konfiguration selbst statisch ist.
2. Beim Blick in die NGINX-Dokumente scheint es mir einige Fallstricke beim Schreiben dieser Regeln zu geben. Zum Beispiel muss man manuell sicherstellen, dass die Rewrites kurzgeschlossen werden, um frühzeitig zu beenden?
3. Der Haken bei Regex ist, dass katastrophal backtrackende Regexes einfach aussehen. Ich sehe nicht, dass dieses Problem genug diskutiert wird. Siehe Links, falls du, der Leser, noch nichts davon gehört hast.
[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
Es gibt die Annahme, dass das Aktivieren von Cloudflares „Under Attack“-Modus den Angriff abmildern würde.
Angesichts der Tatsache, wie adaptiv der Rest des Angriffs war, wäre ich sehr neugierig herauszufinden, wie er dieses Hindernis angehen würde.
- bijowo1676
Dies könnte ein KI-gesteuerter Angriff sein und ReadTheDocs war nur ein Testziel.
Was mich überrascht hat, ist, wie einfach es war, die Cloudflare-Abwehr zu umgehen. Ich weiß, dass es einfach war, CF zu umgehen, aber ich hätte erwartet, dass CF einen besseren Job beim Blockieren von L7-DDoS macht.
CF ist wirklich gut darin, L4-DDoS abzuwehren, aber nicht L7.
Das bedeutet, dass Cloudflare im Zeitalter von agentischem DDoS, das von Tausenden von Agenten weltweit gesteuert wird, wirklich nicht viel nützt.