Grote Cloudflare-storing werd niet door cyberaanval veroorzaakt maar door bug

Cloudflare benadrukt dat de recente wereldwijde storing van zijn diensten niet door een cyberaanval of 'kwaadwillende handelingen' werd veroorzaakt. Volgens de ceo en medeoprichter werd de storing door een bug in een van de databases van de dienst veroorzaakt.

Specifiek zou het probleem ontstaan zijn in het Bot Management-systeem: "Een verandering in de machtigingen van een van onze databases zorgde ervoor dat er meerdere entries in een 'featurefile'-configuratiebestand geplaatst zijn voor het Bot Management-systeem." Dit bestand, dat groter dan normaal was, werd gedeeld met alle systemen in het netwerk. Deze systemen hebben echter een maximale bestandsgrootte die zij kunnen verwerken en het bestand bleek te groot te zijn, waardoor de Cloudflare-diensten crashten.

Het Bot Management-systeem is een tool die op basis van machinelearning bepaalt hoe betrouwbaar een bot zoals een scraper is. Op basis van die score kunnen klanten bepalen of zij een bot toelaten of blokkeren. Het configuratiebestand bevat het aantal functies die Bot Management mag gebruiken. Dit is handmatig begrensd op 200 om overmatige invloed op de prestaties van het systeem te voorkomen. Normaal heeft dat bestand grofweg 60 'features', maar het foutieve bestand bevatte meer dan het maximum aantal functies, waardoor het systeem op momenten minder dan de helft van alle verzoeken kon verwerken.

Volgens de ceo was de recente storing de ergste sinds 2019. Naar eigen zeggen verloopt twintig procent van het wereldwijde internet via Cloudflare. Als het bedrijf een storing heeft, worden daarom talloze websites en diensten getroffen. Om toekomstige storingen te voorkomen belooft hij dat er maatregelen genomen worden, waaronder het verbeteren van het configuratiebestandsysteem en het implementeren van meer kill-switches.

Reacties (46)

[multiplexer]

Ik heb de post-mortem zojuist gelezen, maar haal daar toch een iets andere conclusie uit dan "Volgens de ceo en medeoprichter werd de storing door een bug in een van de databases van de dienst veroorzaakt." ... de database was prima. Clickhouse kun je dit m.i. niet aanrekenen.

Blow-by-blow is dit het verhaal, met wat vereenvoudiging:

Achtergrond
Binnen één database server kun je meerdere databases (ook wel: schemas genoemd) hebben. De "features" data voor Bot Management staat in twee databases: één heeft de echte data, en de andere is een transparant doorgeefluik naar die data, zodat ClickHouse queries over de andere database servers kan verspreiden. Laten we deze twee database "Distributed" en de "Echte" database noemen. Queries worden dus altijd tegen de Distributed database uitgevoerd.

De Wijziging
Via die Distributed database heb je dus ook toegang tot de "Echte" database. Dit was altijd impliciet. Ze wilden dit expliciet maken, vanuit een security-oogpunt: duidelijk maken dat de database-user toegang heeft tot die onderliggende tabellen. Een prima change, in principe.

De Root Cause
In de Bot Management applicatie gebruikte men een metadata query om de tabelstructuur van de database uit te lezen. In Jip-en-Janneke taal: "Hey database, welke kolommen ken je in tabellen met de naam "http_request_features" staan?". Let op het meervoud daar. Ze dachten dat ze vroegen "in de tabel binnen deze specifieke database". Metadata queries werken echter niet op één specifieke database, die werken op alles waar je toegang toe hebt. Dat kun je in de metadata-query afbakenen, maar dat moet je wel zelf doen. Omdat er nooit een tweede database was waar de query toegang toe had is dit nooit opgevallen, tot gisteren.

Direct Gevolg
Voor de volledigheid: de database engine geeft vervolgens een lijst met kolomnamen terug. Voor de change: (A, B) -- en daarna: (A, B, A, B). Want: "A-in-database-1", "A-in-database-2", "B-in-databae-1", "B-in-database-2". Het opbouwen van het config bestand op basis van dit queryresultaat had nu dus opeens 2x zoveel rijen. Dit bestand wordt vervolgens naar alle nodes van het netwerk gepushed als configuratie, die opeens iets defects krijgen.

Downstream Gevolgen
Van daaruit moeten we nog een paar stappen doorlopen voor we bij de crash komen, waarbij uiteindelijk gebrek aan validatie en foutafhandeling, en een performance-optimalisatie: van te voren één blok met geheugen reserveren met ruimte voor een fixed aantal elementen. Het uiteindelijke resultaat was catastrofaal, omdat de hele Cloudflare proxy server onderuit ging, en in een generieke foutafhandeling (de error page die iedereen zag) terecht kwam.

Interessant uit de post-mortem is dat de change in het rechtenmodel gefaseerd uitgerold wordt over de database servers. De Bot Management query liep om de 5 minuten, met elke keer dus een bepaalde kans (die steeds verder opliep) dat de query door een database server afgehandeld zou worden waar het probleem op van toepassing was. Dit is de oorzaak van het "klapperen"... en zette hem team op een dwaalspoor, omdat ze hierdoor dachten dat het een aanval van buitenaf was.

[Reactie gewijzigd door multiplexer op 19 november 2025 15:14]

[ShadLink]

Dus een fout in een configuratiedatabase, lijkt me een menselijke fout van een beheerder bij Cloudflare.

[PolarBear]

Nee, de code die de configuratiedatabase uitleest had, uit performance oogpunt, een gemaximeerde hoeveelheid geheugen wat gebruikt kon worden. Echter zonder verder foutafhandeling. Dus er de code probeerde meer config items in het geheugen te laden dan mogelijk en crashte zonder verdere afhandeling.

Each module running on our proxy service has a number of limits in place to avoid unbounded memory consumption and to preallocate memory as a performance optimization. In this specific instance, the Bot Management system has a limit on the number of machine learning features that can be used at runtime. Currently that limit is set to 200, well above our current use of ~60 features. Again, the limit exists because for performance reasons we preallocate memory for the features.

[Reactie gewijzigd door PolarBear op 19 november 2025 13:15]

[woutertje]

Er was natuurlijk wel foutafhandeling anders had je geen 500 error gezien, het was echter niet mogelijk om requests alsnog succesvol af te handelen (anders dan het teruggeven van een foutmelding aan de eindgebruiker).

Terzijde: er ligt vrij veel focus op het gebruik van unwrap(), maar mijns inziens doet dat er niet perse toe. Als er wel een Result<_> teruggegeven was is het maar de vraag of de ontwikkelaar dan had besloten dat er, na het zien van de expliciete error, nog een mogelijk pad naar succes was, of dat je toch nog was geconfronteerd met een 500 error. Dan had je geen unwrap gehad maar wel exact hetzelfde probleem.

[Z80]

Nee. dat was het gevolg van de wijziging. Niet de oorzaak.

[- peter -]

Volgens de ceo was de recente storing de rest sinds 2019.

Denk dat dit 'eerste' moet zijn. @YannickSpinner

[Kun]

Daar klopt niets van. Mijn geheugen is niet best, maar blijkbaar beter dan die CEO.

21-06-2022 nieuws: Cloudflare-storing kwam door fout, trof 19 datacenters en 50 procent van verkeer

[Luchtbakker]

Daar klopt niets van. Mijn geheugen is niet best, maar blijkbaar beter dan die CEO.

21-06-2022 nieuws: Cloudflare-storing kwam door fout, trof 19 datacenters en 50 procent van verkeer

50% van het verkeer is heel erg veel, maar niet niveau 100% wat het in dit geval was.
Deels heeft de CEO dus gelijk.

[SillieWous]

Als ik de grafiek in het artikel juist interpreteer (as labels zouden opzich wel handig zijn) ging het bij deze storing ook om ongeveer 50%. Dus dat is van dezelfde orde grote als je het mij vraagt.

[TheVivaldi]

100% zeker niet inderdaad, want sommige sites die Cloudflare gebruikten deden het bij mij prima (maar niet alle, dus er was wel degelijk *een* storing).

[TweakOverflow]

Dat is grappig, want zoals ik het interpreteer is het juist (hetzij een piek) 80% down geweest. Dus dan zou dit de grootste storing zijn.

[HachiPudi]

Niet de eerste maar de grootste/ergste sinds 2019. Uit hun eigen blogpost erover:

Today was Cloudflare's worst outage since 2019.

[YannickSpinner]

Dat moet ergste zijn! Eerste sinds 2019 zou wel heel knap zijn

[n0mn0m]

Ik denk dat een ieder dit kan impliceren uit dit bericht. Voor grammaticale- en spelfouten verwijs ik je naar het forum.

[Odie]

Wat je ook van de storing vindt, ik vind de manier waarop de Dane Knecht (de CTO) openheid van zaken geeft een pluim waard.

[Reactie gewijzigd door Odie op 19 november 2025 12:45]

[Luchtbakker]

Dat mag ook wel. Cloudflare heeft ook een behoorlijke reputatie te verliezen.

[Odie]

Veel bedrijven schuiven af of zijn een meester in “smoke and mirrors” en blijven in hun RFO ontzettend hangen in vaagheden en dat is bijzonder ergerlijk. Ik probeerde bij mijn klanten ook altijd transparant te zijn en merkte dat veel woede al wegzakte als je gewoon ruiterlijk je fouten toegeeft.

[Djerro123]

RFO?

[junkchaser]

Exact, een duidelijke uitleg en een een incentive voor een intern actieplan om het in de toekomst te voorkomen. Nu hopen dat het een goed actieplan is en daadwerkelijk uitgevoerd zal worden.

[Huib_Bloodstone]

Was best wel een grote storing en nu kan je ook zien hoe afhankelijk je toch bent van bepaalde services.

Dit was nog maar een "kleine" bug laat staat dat er echt wat gebeurt, iets om soms over na te denken.

[moonlander]

Maar die dienst levert ook iets zodat je snellere website hebt, en beschermt bent tegen ddos aanvallen. Je kan overal wat van vinden, maar deze storing in omvang is dus sinds 2019 niet meer gebeurt.. Alles in eigen beheer regelen? Grotere kans dat dat meer storing oplevert dan wat cloudflare aanbied.

[downtime]

Want het enige alternatief voor Cloudflare is het zelf doen? Is Cloudflare een monopolist zonder concurrenten?

[Croga]

Het enige alternatief om niet "afhankelijk (te) zijn van bepaalde services" is inderdaad het zelf te doen.

Als je cloudflare inlevert voor een andere, soortgelijke, dienst dan wordt je afhankelijkheid niet kleiner.

[watercoolertje]

Alles in eigen beheer regelen? Grotere kans dat dat meer storing oplevert dan wat cloudflare aanbied.

Maar minder kans dat diensten tegelijk down zijn.

[moonlander]

Maar ben je wel afhankelijk van of je het zelf kan oplossen of niet. En ben je ook afhankelijk van software van andere partijen, als die een verkeerde update doen hang je ook. En reken maar dat cloudflare het sneller oplost dan dat jij dat kunt.

[watercoolertje]

Dit was nog maar een "kleine" bug laat staat dat er echt wat gebeurt, iets om soms over na te denken.

Als alles plat gaat is het effect (voor gebruikers) toch precies hetzelfde? Ongeacht hoe 'groot' de bug is? Enige verschil zou de tijd kunnen zijn om het op te lossen.

[Dylanleetje]

Nooit gedacht dat een foutje in een configuratie bestand zo'n impact kan hebben

[LOTG]

Ben je crowdstrike al weer vergeten? Dat was eigenlijk ook een config file, alleen werd die naar clients gepushed.

Ik vraag mij hier wel het zelfde af, had dit niet gewoon vooraf getest moeten worden?

[Dylanleetje]

Inderdaad. Maar aan testen word sowiezo weinig aan gedacht de laaste tijd

[Keypunchie]

Wat had je willen testen? Dit is eerder een mismatch tussen productie en acceptatie-systemen. Op de non-prod werkte het vast prima.

Op zijn best kun je dit soort dingen gefaseerd uitrollen.

[LOTG]

Wat had je willen testen?

Of de configuratie werkt? Blijkbaar zijn er harde requirements over filesize dus dan neem ik aan dat je dit ook wilt testen. Dat is in elk geval wel hoe ik het doe.

Als er een mismatch tussen acceptatie en productie hier is heb je het dus niet getest en was dit gewoon een kwestie van tijd. En acceptatie is dus niet representatief dan, dus wat voor doelt dient het?

[Djerro123]

Ik moet bijna een beetje gniffelen van dit soort comments, zo heerlijk elitair.

Er werken echt ontzettend slimme mensen bij Cloudflare, denk je nou echt dat zij "testen in productie"? Heb je de RCA wel gelezen? Het is niet een configuratie bestandje wat ze zelf hebben aangepast; het is een geautomatiseerd samengestelde set. Door een wijziging in permissie structuur gaf een bepaalde query een ander resultaat dan destijds werd aangenomen toen de query werd geschreven. Dat zorgde ervoor dat een heel ander deel van de infrastructuur een configuratie kreeg aangeleverd welke incompatible was met wat het aankon.

Waar hadden ze dit moeten testen volgens jou? Alles werkte in principe naar behoren en volgens spec.

[Nijl]

Nou dan heb je de chaos bij RTV Noord nog niet gezien!

[NeFoRcE]

Grappig om te zien was dat x.com (Voorheen Twitter), óók plat lag doordat hun NS over die van Cloudflare liep. Later op de dag hebben ze alles gemigreerd naar twtrdns.net. En werkte alles weer doordat ze niet meer afhankelijk waren van CF.

[woutertje]

Hmm, ze hebben wel iets gedaan maar dat had niks met nameservers ansich te maken (dat is al twee jaar twtrdns.net).

[Stetsed]

Zoals ik all eerder heb gezegt, ik gebruik Cloudflare zelf niet, maar ik moet ze zeker een duimpje geven van hoe open ze zijn wanneer er iets fout gaat. Meeste andere bedrijven geven een generieke "Oeps" en gaan dan door, maar Cloudflare heeft altijd een redelijke diepe technisch rapport die normaal alleen intern bestaat. Altijd leuk om te lezen en die unwrap is inderdaad een significante fout, dat moet je zoiezo niet gebruiken, zelfs als je DENKT dat het nooit fout kan gaan, doe dan toch nog handeling, want het maakt het in de toekomst makelijker om het probleem te vinden.

[BadRespawn]

Zoals ik all eerder heb gezegt, ik gebruik Cloudflare zelf niet, maar ik moet ze zeker een duimpje geven van hoe open ze zijn wanneer er iets fout gaat.

Het feit dat we het bijzonder genoeg vinden om het een duimpje te geven is veelzeggend.

[fuzzyIon]

Tijd en consistentie zijn het belagrijkste voor cloudfare zo blijkt weer eens.

[arithcoder]

Ik ben nu Google DoH aan het testen in mijn MikroTik router. Mijn geheugen is niet best, maar als ik mij goed herriner heeft Google nog nooit een DNS storing gehad, of wel?

Toen gisteren de Cloudflare storing ontstond, dacht ik dat het bij mij was en maar in de router gaan kijken wat er mis loopt, haha.

Het is heel spijtig dat MikroTik niet Quad9 DoH support omdat ze (MikroTik) nog HTTP/1.1 gebruikt terwijl Quad9 alleen HTTP/2.0 support. Maybe in the future, MikroTik? :)

[Gizz]

Ik ben nu Google DoH aan het testen in mijn MikroTik router. Mijn geheugen is niet best, maar als ik mij goed herriner heeft Google nog nooit een DNS storing gehad, of wel?

Maar dat valt toch niet te vergelijken? Er was niks mis met de dns-servers van Cloudflare in dit geval. Het gaat om de beveilingslaag ertussen die ongewensten buiten de deur houdt, ddos-aanvallen probeert te voorkomen etc.

Je vergelijkt nu het gehele beveiligingssysteem van Cloudflare die tussen client en server zit met een simpele dns-server die aan de client het ip-adres geeft dat bij een domein hoort.

Of je gisteren nou Google DNS, Quad9, de dns-server van je provider of je eigen server (Pi-hole) gebruikte: je kon de websites die door Cloudflare beveiligd werden niet bezoeken.

[arithcoder]

Ik kreeg in mijn MikroTik logs tijdens de storing te zien, in het rood, DNS error, could not resolve. Dus er was wel iets met DNS te doen. M.a.w de router kon niet het DoH server van Cloudflare bereiken.

[Reactie gewijzigd door arithcoder op 19 november 2025 13:52]

[Gizz]

Je kunt thuis overstappen naar dns-server X Y of Z. Dat had de bereikbaarheid van servers achter de Cloudflare-beveiliging 0,0 beter gemaakt.

Daarom snap ik niet goed waarom je op dit nieuwsbericht reageert met dat je thuis een andere dns-server gaat instellen. Dat helpt in deze casus niks

[arithcoder]

Als je router aangeeft that het niet kan verbinden met het DoH server van Cloudflare, dan is er iets mis aan de kant van Cloudflare, en omdat de router geen DNS meer kan vertalen, dan kan je niet op het Internet geraken wat bij mij het geval was. Daarom heb ik (tijdelijk) Google DoH aangezet en off we go. Ja er waren sites die problemen toonden wegens de storing maar de rest werkte. Maar niet wanneer Cloudflare DoH aan stond.

Werk je misschien bij Cloudflare en weet je hoe de storing eruit zag en welke services getroffen waren?

[Gizz]

en omdat de router geen DNS meer kan vertalen, dan kan je niet op het Internet geraken wat bij mij het geval was.

Ah, maar dan beschrijf je volgens mij een ander probleem. Jij koos ervoor als consument om de dns-server van Cloudflare te gebruiken. Maar dat was niet waar 99% van de mensen last van had: de grote cloudflare-storing waarover dit nieuwsbericht gaat betreft dat servers die door Cloudflare werden beveiligd niet bereikbaar waren. Daar vallen hun eigen dns-servers ook onder. Ja, dan los je inderdaad op dat je compleet niet meer kan internetten als je naar een andere dns-server overstapt.

Het probleem waar iedereen het over heeft, dat alle sites die door Cloudflare beveiligd werden niet meer te benaderen waren, los je niet op met een switch naar een andere dns-server. Problemen zoals die in dit nieuwsbericht werden genoemd los je niet op door een specifieke dns-server in te stellen op je routertje:

Gebruikers van Gathering of Tweakers merken op dat diensten als ChatGPT, Allestoringen, de website van IKEA en de Home Assistant Community problemen ondervinden.

[Reactie gewijzigd door Gizz op 19 november 2025 14:49]

[Djerro123]

Er is een zeer uitgebreide RCA geplaatst door Cloudflare zelf, je kan hem hier lezen. @Gizz heeft eigenlijk gewoon gelijk; dit was geen DNS storing. Als je de Cloudflare DNS servers gebruikt kan het zijn dat die er óók uit lagen, maar de storing was niet DNS gerelateerd.