Inzicht in de recente DDoS-aanval op Read the Docs

In het midden tot eind juni 2026 werd Read the Docs getroffen door de grootste en meest geavanceerde distributed denial-of-service (DDoS)-aanval in onze geschiedenis.

Op het hoogtepunt werd onze infrastructuur bestookt met meer dan 5,5 miljoen verzoeken per minuut, wat ongeveer 100 keer ons normale basisverkeer is. Het incident duurde bijna tien dagen en vormde een zware beproeving voor onze infrastructuur, onze edge-verdedigingen en onze processen voor incidentrespons.

In tegenstelling tot eenvoudigere verkeersvloeden die we in het verleden hebben gezien, was deze aanval meer gedistribueerd, paste hij zich snel aan onze verdedigingen aan en viel hij doelbewust gebieden aan die de caching omzeilden. Nu ons kleine ops-team weer op normale tijden kan slapen, willen we de anatomie van dit soort aanvallen toelichten, uitleggen waarom onze bestaande rate limiting slechts gedeeltelijk hielp, en welke strategieën ons hielpen om de beschikbaarheid tijdens de aanval (grotendeels) te behouden.

De evolutie van DDoS-aanvallen

Read the Docs is historisch gezien zeer tolerant geweest tegenover spiders en bots die de door ons gehoste documentatie scrapen; rate limiting op basis van IP-adressen loste de meeste misbruikproblemen op.

Ongeveer twee jaar geleden zagen we een significante toename nu AI-crawlers gebruikelijker werden. Het lijkt erop dat andere leden van de dev-infrastructure community met soortgelijke problemen kampen. Het werd eenvoudig om een AI-gegenereerde scraper aan te sluiten op een proxynetwerk. Onze verdedigingen pasten zich daar vrij gemakkelijk aan aan, maar de aanval in juni was meer dan 10 keer groter dan alles wat we tot dan toe hadden meegemaakt.

De belangrijkste kenmerken van deze aanval waren:

  • Massief volume: Op het hoogtepunt ontvingen we 5,5 miljoen verzoeken per minuut, vergeleken met onze normale dagelijkse piek van minder dan 100.000 verzoeken per minuut.
  • Wereldwijde distributie: We zagen kwaadaardige verzoeken afkomstig van miljoenen unieke IP-adressen verspreid over honderden netwerken (ASN's) wereldwijd. Dit omvatte zowel residentiële IP-blokken als grote en kleine hostingproviders.
  • Randomisatie van headers en TLS: De aanvallers randomiseerden systematisch de HTTP-verzoekheaders en TLS-verbindingsparameters om filters op basis van signaturen (JA3/JA4) te omzeilen.
  • Beperkingen van geautomatiseerde CDN-verdedigingen: Read the Docs maakt gebruik van Cloudflare. Hoewel de geautomatiseerde DDoS-bescherming van Cloudflare een deel van het verkeer uit zogenaamde "bekende botnets" mitigeerde, kwam een groot deel van de aanval door deze eerste controle heen en bereikte onze rate limiting en WAF-regels.
  • Omzeiling van de cache (Cache evasion): Aanvallers ontdekten en richtten zich doelbewust op URL's die resulteerden in cache-misses, zoals niet-bestaande pagina's met unieke paden (404's) en tijdelijke redirects (302's).
  • Adaptief gedrag: Wanneer we blokkades of rate limits implementeerden, paste het botnet de verzoeksnelheid aan, roteerde het door verschillende doelpaden en verspreidde het het verkeer over bredere IP-pools om onze verdedigingsgrenzen te testen.

Schaal en reikwijdte

Eerdere kleinere DDoS-aanvallen of grote gedistribueerde scrapers waren doorgaans op een bepaalde manier geconcentreerd. De verzoeken kwamen ofwel uit een klein aantal landen, een klein aantal IP-blokken, of ze hadden een beperkt aantal browser-signaturen.

Deze aanval was werkelijk mondiaal. Hij kwam uit elk land tegelijk, wat een nachtmerrie is wanneer rate limiting-regels per Cloudflare-colo worden toegepast. Het is moeilijk om regels op te stellen die een gedistribueerde aanval kunnen beperken zonder legitieme bots te raken die op een redelijk tempo vanaf één IP of subnet scrapen.

Op een gegeven moment, toen de aanvallers zich richtten op redirects, overspoelden ze een hardcoded Nginx-redirect (een eenvoudige rewrite regex-directive) met zoveel verkeer dat dit leidde tot gedropte verzoeken, zelfs op horizontaal schaalbare infrastructuur. Een Nginx-redirect als die kan normaal gesproken gemakkelijk duizenden verzoeken per seconde afhandelen.

Naast de wereldwijde verspreiding werden er meerdere Read the Docs-eigendommen aangevallen: zowel de publieke community-documentatie als onze commercieel gehoste documentatie. We zagen ook dat aanvallers probeerden onze dashboards voor auteurs, waarvoor inloggegevens vereist zijn, plat te leggen.

Hoewel het een optie was (via de "Under Attack Mode" van Cloudflare) om elke sitebezoeker, legitiem of niet, een JavaScript-challenge te geven, wilden we dat niet doen. Dit zou elke API-integratie verbreken en veel frictie veroorzaken voor de honderdduizenden echte lezers van de documentatie. In plaats daarvan vertrouwden we op rate limiting en gerichte challenges, gecombineerd met meer caching en het verplaatsen van meer functies naar de edge.

Aanpassing aan onze verdedigingen

Read the Docs maakt intensief gebruik van Cloudflare voor caching en rate limiting; er is geen manier waarop we deze aanval zonder Cloudflare hadden kunnen afhandelen. We hebben tientallen rate limiting-regels (beheerd via Terraform) om onze infrastructuur te beschermen op basis van IP's, de duizenden hostnames en honderdduizenden subdomeinen die Read the Docs host, ASN's, browser-fingerprints en combinaties hiervan.

De aanval begon op een klein aantal domeinen waar aanvallers tijdelijke redirects (302) ontdekten die niet aan de edge werden gecached en werden geserveerd door onze Python-backend in plaats van door bijvoorbeeld Nginx. Binnen enkele minuten werd ons operations-team gealarmeerd vanwege een korte storing (gebruikers merken onze storingen niet altijd omdat gecachte documentatie gewoon blijft worden geserveerd). Binnen een half uur hadden we deze redirects verplaatst zodat ze aan de edge door Cloudflare werden geserveerd in plaats van door onze servers.

We dachten dat dit het einde zou zijn, maar de aanvallers probeerden gedurende anderhalf jaar verschillende tactieken uit over diverse hosts en services.

Aanvallers zouden de snelheid opschalen om onze rate limit-drempels te ontdekken en vervolgens terugschakelen om de rate limit-vensters te laten verlopen. Dit wordt een "yo-yo-patroon" genoemd en is ontworpen om de financiële kosten van auto-scaled infrastructuur te maximaliseren en intermitterende service-degradatie te veroorzaken. De aanvallers wisten dat we een web app firewall (WAF) met rate limits gebruikten en wisten hoe ze ondanks dat zoveel mogelijk schade konden aanrichten.

Verdedigen tegen volumetrische DDoS-aanvallen

Het verdedigen tegen floods van miljoenen verzoeken per minuut vereist een defense-in-depth-benadering met edge-caching, web app firewalls, rate limiting, lokale caches en request fingerprinting. Het snelste verzoek is het verzoek dat wordt afgehandeld door de CDN of de web app firewall.

Edge-caching

De eerste verdedigingslinie is een goede CDN en het waarborgen dat zo min mogelijk verzoeken de origin-servers bereiken. Voor Read the Docs, waar documentatiepagina's zelden veranderen, cachen we vrij agressief, maar we legen de cache voor een specifieke site zodra nieuwe documentatie naar git wordt gepusht en opnieuw wordt gebouwd. CDN's maken het ophalen van documentatie bovendien veel sneller voor mensen die geografisch verder van onze origin-servers afliggen.

Aanvallers die onze verdedigingen verkenden, ontdekten echter snel welke verzoeken gecached waren en welke niet, aan de hand van de reactiesnelheid van de CDN. Dit betekent dat het vinden van slechts enkele niet-gecachede verzoeken de aanvallers een invalshoek geeft. We zijn nog steeds op zoek naar meer paden en endpoints die niet gecached zijn, maar zelfs zeer kortstondige gecachede responsen (via de Cache-Control header), voor zowel redirects als normale 200-responsen, helpen bij dit soort aanvallen.

Rate limiting en fingerprinting

Omdat we niet alle gebruikers een JavaScript-challenge wilden geven, gebruikten we gerichte rate limiting-regels. Hierbij combineerden we bot-waarschijnlijkheidsscores met per-IP rate limits om verdacht verkeer uit te dagen, terwijl legitieme gebruikers en goedbehaagde bots ongestoord konden browsen. We besloten dat het beter was om wat kwaadaardig verkeer door te laten dan om echte gebruikers onnodig te hinderen.

Toch hadden we rate limits nodig om onze infrastructuur te beschermen. In plaats van te focussen op waar het verzoek vandaan kwam (het IP, het land), moet de verdediging zich richten op hoe het verzoek eruitziet:

  • Cipher suite en TLS-anomalieën: Geautomatiseerde scrapers en bot-clients vertonen vaak abnormale TLS-verbindingen die verschillen van browsers. Cloudflare's bot-detectie heeft specifieke tools om deze te detecteren.
  • Te veel foutieve verzoeken: Legitieme gebruikers en goede bots krijgen bijna altijd succesvolle (200) responsen, geen redirects of 404's. Aangezien 200-responsen altijd worden gecached, vormen ze bijna nooit een probleem. Wanneer we te veel "dure" verzoeken zien, zoals redirects of 404's, beginnen we de browser-fingerprint, de ASN of mogelijk het specifieke domein als geheel te rate-limiten. Het toevoegen van deze regels, die we de "penalty box" noemen, maakte waarschijnlijk het grootste verschil in het automatisch mitigeren van de aanval naarmate deze in de loop van de tijd veranderde.
  • Protocol-inconsistenties: Kwaadaardige tools claimen vaak moderne User-Agent-strings terwijl ze oudere HTTP/1.1-verbindingen gebruiken. Helaas was deze inconsistentie niet erg nuttig bij deze aanval, die volledig via HTTP/2 en HTTP/3 verliep.
  • Client fingerprinting: Iedereen die de Golang HTTP-client of de Python requests-module gebruikt met dezelfde TLS-cipher suites, heeft dezelfde JA4-fingerprint. Deze fingerprinting is specifiek voor een browser of tool, niet voor een gebruiker. Deze fingerprints waren bij deze aanval ook niet erg nuttig, omdat de aanvallers hun TLS-parameters randomiseerden.
  • Classificatie van IP-blokken: Een punt waar we nog aan werken, is het classificeren van meer IP-blokken in verschillende categorieën met eigen limieten. Voor een service als Read the Docs, die veel geautomatiseerd verkeer ontvangt en bots wil toestaan, weten we dat we veel verkeer zullen krijgen van grote cloud-ASN's zoals Amazon, Google Cloud en Azure. Deze zouden hogere limieten moeten hebben dan de meeste residentiële providers of kleinere hostingproviders.

Gebruikers een uitweg bieden

Een beslissing die we hebben genomen, is om echte gebruikers altijd een uitweg te bieden. Read the Docs hanteert zeer zelden volledige blokkades of bans voor specifieke IP-adressen of user agents. In plaats daarvan is onze "strengste" maatregel een JavaScript-challenge. Als een gebruiker een challenge oplost, is de kans zeer klein dat ze de volgende dag opnieuw worden uitgedaagd.

Geleerde lessen en belangrijkste conclusies

De DDoS-aanval van juni 2026 heeft verschillende kritische lessen opgeleverd voor het beheren van high-traffic infrastructuur:

  1. IP-blokkeren is verouderd bij gedistribueerde aanvallen: Botnets of grote scrapers gebruiken proxydiensten, waardoor eenvoudige IP-blokkades nutteloos zijn. Verdedigingen moeten bredere rate limits hebben die verder gaan dan alleen IP's (bijv. ASN's, hostnames).
  2. Agressief cachen: Cache alles, of het nu een eenvoudig statisch bestand is, een 404 of een tijdelijke redirect. Zelfs een kort cache-venster van enkele minuten zorgt ervoor dat deze resources niet kunnen worden gebruikt om de infrastructuur aan te vallen. De standaardinstellingen van CDN's en webframeworks zijn vaak niet wat een service als Read the Docs nodig heeft.
  3. Bescherm "cache-miss" oppervlakken: Aanvallers zoeken actief naar paden die niet cachebaar zijn (bijv. dynamische redirects, zoek-endpoints en 404's). Cache waar mogelijk, en als dat niet haalbaar is, probeer dan zoveel mogelijk aan de edge af te handelen.
  4. Gerichte challenges zijn beter dan botte instrumenten: Het combineren van bot-management-heuristieken met rate limits stelde ons in staat de aanval te mitigeren met minimale impact op legitieme gebruikers.
  5. Infrastructure as Code is essentieel: Het beheren van edge- en WAF-regels via Terraform stelde ons in staat om complexe filterregels snel en veilig te reviewen, te testen, te versioneren en uit te rollen.

We zien nog steeds lage niveaus van achtergrondverkeer van de aanvals-IP-blokken, maar onze infrastructuur staat vandaag de dag in een veel sterkere positie dan vóór de aanval. Naarmate AI-tooling en proxynetwerken dit soort aanvallen goedkoper en toegankelijker maken, zijn ze niet langer voorbehouden aan grote enterprise-doelen. Ze worden de basisrealiteit voor elke prominente publieke service.

Ons ops-team slaapt weer een volledige nacht, maar we beschouwen dit eerder als een tijdelijke rustpauze dan als een teken dat aanvallen tot het verleden behoren.