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 (63)

[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. In de overige reacties zie ik ook allerlei conclusies die zich niet echt laten staven door de officiële lezing van wat er aan de hand is.

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

Achtergrond
Binnen één database server kun je meerdere databases 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. Wat ze dus feitelijk gedaan hebben is "Geef user `database user` toegang tot database `Echt`, naast de rechten die hij al heeft op database `Distributed`".

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 heb 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 20 november 2025 12:09]

[shinigami-R]

Top uitleg!
Wel een kleine aanvulling: een database is niet hetzelfde als een schema (behalve bij MySQL, waar deze termen synoniem zijn).

De juiste hiërarchie is:
- Database Server: De instance van SQL Server (of een andere RDBMS).
- Database: Een container voor data en objecten. Elke database heeft zijn eigen beveiliging, transacties, etc.
- Schema: Een logische groepering van objecten binnen een database (tabellen, views, procedures). Het is géén database, maar een namespace binnen een database.
- Tabel/View/etc.: De daadwerkelijke data-objecten.

Voorbeeld:
SQL Server Instance ('Database server')
├── Database: SalesDB
│ ├── Schema: dbo
│ │ ├── Table: Customers
│ │ ├── Table: Orders
│ ├── Schema: reporting
│ │ ├── View: SalesSummary
├── Database: HRDB
│ ├── Schema: dbo
│ │ ├── Table: Employees

[Reactie gewijzigd door shinigami-R op 20 november 2025 10:17]

[multiplexer]

Haha, toen ik dit schreef dacht ik al "er zal vast iemand over vallen dat ik dit voor deze uitleg even op één hoop veeg". Je hebt uiteraard helemaal gelijk: afhankelijk van welk DBMS er gebruikt wordt kan dit onderscheid heel significant zijn.

Nou is het wel zo dat het hier om Clickhouse gaat - zij gebruiken hetzelfde wire protocol als MySQL, en hanteren dus dezelfde termininologie - dat was voor mij reden om het voor deze uitleg wel even prima te vinden - ik was al weer veel te breedsprakig

Om onduidelijkheid weg te nemen heb ik het bericht aangepast en de vermelding van schema's weggehaald. Geen idee waarom ik dat überhaupt wilde noemen bij het schrijven ervan :)

[Reactie gewijzigd door multiplexer op 20 november 2025 16:55]

[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.

[multiplexer]

Wat ik uit het officiële verhaal na een paar keer doorlezen nog niet heb gehaald is hoe 2 x ~60 = ~120 er voor zorgde dat ze boven de 200 uitkwamen.

Wellicht is het sleutelwoord "currently", en is die 200 dus na ophogingen die ze naar aanleiding van het incident hebben doorgevoerd... maar dat vind ik niet echt duidelijk.

[- 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.

[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.

[kr4t0s]

Je bent altijd afhankelijk van vele dienstverleners in de keten, als een kleine partij een storing heeft komt dat niet in het nieuws. Als je het zelf doet maak je soms ook fouten. Dus conclusie, soms is het stuk en dan moet je maar even iets anders doen.

[wiseger]

Er zijn genoeg concurrenten zoals Akami, AWS, Azure, Google Cloud, Fastly et cetera.

[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.

[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?

[Odie]

Reason for Outage, een document dat je als leverancier met je klanten deelt waarin je een beknopte rootcause analysis deelt samen met de tijdslijnen en acties en mogelijk de vervolgstappen.

[Djerro123]

Ah nooit van die term gehoord, wij hadden het altijd gewoon over de RCA (zowel als service verlener, als klant van andere service providers), maar zal vast per contract/partij verschillend zijn.

[Odie]

Het wordt beiden gebruikt, ik vind de rca meer het proces en de rfo het resultaat. maar anderen vinden de rfo meer de snelle status update die je kort na aanvang van de storing doet. Ligt denk ik aan de mores van de organisatie.

[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.

[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?

[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.

[SPee]

Diegene die de wijziging deed had niet de kennis dat het verdere impact zou hebben.

Diegene die het script heeft gemaakt had niet de kennis dat mogelijk uit meerdere databases info gehaald kon worden. (Of had bewust gemaakt dat het wel kon.)

Beide hebben hun werk niet in samenspraak gedaan of dit samen getest. Immers is dit vrij makkelijk in een kleine productie-like omgeving te testen. Twee schema's en een query uitvoeren is makkelijk te doen. Dus ergens in hun onderlinge communicatie en/of testen hebben ze steken laten vallen.

[Webgnome]

wat @LOTG en @Djerro123 dus eigenlijk zeggen..

[Reactie gewijzigd door Webgnome op 19 november 2025 17:52]

[Dylanleetje]

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

[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.

[HenkEisDS]

Wat me wel een beetje verbaasd is de afhankelijkheid van Cloudflare en ik denk dat dit komt door de manier waarop je Cloudflare moet opzetten. Je moet namelijk op DNS niveau zaken naar Cloudflare laten verwijzen, maar daarmee introduceer je een grote afhankelijkheid. Beter zou je aan je eigen kant ook iets inbouwen die standaard routeert naar Cloudflare, behalve als Cloudflare down is zoals gisteren.

Verder is een storing van 3 uur per jaar nog steeds een uptime van 99,96575342%. Niet slecht als je het mij vraagt. Het is niet alsof het hartbewakingssystemen of vliegtuigboordcomputers beschermt (toch?).

[William_H]

Precies, dat hele Cloudflare blijkt op zo'n moment een grote SPOF te zijn. Niet echt hoe het internet is opgezet.

[jep]

Dat kan middels CNAME's, maar daarvoor moet je minimaal het Business pakket afnemen van $200,- per maand. Je verliest dan wel wat functionaliteit, maar je kunt wel snel schakelen.

[HenkEisDS]

Hoe zou dat dan werken? Want een cname wijziging kost ook een uur voordat dit fatsoenlijk verspreid wordt toch?

[jep]

Nee, die kun je een hele lage TTL geven en dan binnen een minuut wijzigen. Bij een nameserverwijziging ben je afhankelijk van zonefile updates van de registrar.

[fuzzyIon]

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