Názory k článku
Včerejší výpadek Cloudflare nezpůsobil útok, ale konfigurační chyba

Cloudflare vraj „nečelil útoku“ — len ich sieť položila vlastná neschopnosť spracovať trochu väčší súbor. Jedna zmena oprávnení, databáza vypľuje obézny config, polovica clustru vyrobí blud, druhá polovica sa snaží tváriť normálne, všetko sa prepíše, rozsype, ožije, znova umrie… a admini medzitým naháňajú neexistujúci DDoS. Na konci to opravili ručným nahratím starej verzie a reštartom proxy — globálny gigant zachránený metódou „vypnúť a zapnúť“. World-class service!

Gratuluji za nejzbytečnější komentář roku. Vy jste asi nikdy nic nepodělal, že...

Vis jakej je rozdil mezi tebou a profikem? Profik rozhone nikdy nic takhle epicky nepodela. Profik totiz predevsim nikdy nic nikde nemeni za behu bez jakyhokoli testu.

Takze nejzbytecnejsi komet tisicileti je ten tvuj.

To, že se konfigurace mění za běhu, je podstata cloudu.

To je tak maximalne podstatou jirsakova jcloudu. Ve slusny spolecnosti se jakakoli zmena nejdriv otestuje (coz muze trvat klidne i par mesicu), pak se stanovi termin kdy se nasadi, a pokud se to tyka zakazniku, tak se jim to s dostatecnym predstihem oznami.

Mimochodem jirsaku, mnou navrzeny infrastruktury fungujou tak, ze muzu jakoukou komponentu kdykoli vypnout, a nicemu to nevadi ... pak si ji muzu prenastavit/pat­chnout/... tomu se totiz dika distribuovana infrastruktura, kterou bych v cmoudech povazoval za zcela samozrejmou. A ne ze zmenim nekde jeden textak, a lehne to cely.

Navic se zmeny typicky delaji tak, ze se aplikuji na cast infra, a ne na celou najednou. Takze ja bych prisel mozna o par serveru, mozna by se trosku zhorsily latence, ale rozhodne by to nelehlo komplet.

"Profik totiz predevsim nikdy nic nikde nemeni za behu bez jakyhokoli testu."
Jestli jsem spravne pochopil vsechno to odstartovalo spatne opravneni u DB. Jak tohle chces otestovat jako profik?

Tak u kritických věcí bejvá celkem dobrým nápadem mít testovku shodnou s produkcí, přes kterou musej projít všechny změny, že ano.

Naopak velmi dobře zlvádnutý fuckup, lidské chyby se stávají.

Ale protože je to world-class service, tak to poměrně rychle identifikovali, vyřešili a transparentně zveřejinili hned druhý den. Chybí mi ještě nějaká opatření, aby se něco podobného nestalo, ale myslím, že i toto již mají dnes navrženo.

Kdyby to byla jakákoliv jiná společnost, mlžila by o tom ještě následující týdny nebo měsíce.

Jasne, kazda firma pak dela meeting, kde se navrhuje jak tomu predejit - btw ja jsme to predpokladal, nebot zverejnioli, ze delaji velke updaty vsech serveroven, viz seznam zmen a rikal jsme si, ze to bude spise souviset s tohle change.

Ale prijde mi to, ze neco nechali vygenerovat AI a ta to podelala, nebo nekym, naprosto nekompetentnim, kdo to nezkontroloval a neotestoval - nebo neco prehledl.

Za me je divne, ze neco selze jen proto, ze je soubor vetsi - co je to vetsi ? aby bylo jasno, nekolik MB velky textovy soubor nebo DB ma opravdu hodne zaznamu, takze ty soubory mohly mit max par desitek MB a rozhodne se nejednalo o GB - ale mohly tam byt duplicitni zaznamy a ty 1. mohly byt spatne - jak znamo, script muze najit, nastavit a skoncit ..

No to vi jen oni, realitu co presne se stalo samozrejme firma nikdy nepusti ven, proc by to delal, pusti neco co vypada profesionalne - vice mene managerum staci, hele nastala chyba na nasi strane kdyz jsme delali update - chybu jsme nasliu, opravili, pracujeme na tom, jak ji predchazet, opravujme nase automaticke scripty .... zbytek je tam jen pro rypavejsi managery - kdyby je nekdo hackl, tak to nepriznaji ;-)

To ze sem nekde neco zmenil a ono to potom chciplo, nezjistuju celej den, ale tak 2 minuty. Obnovit snap bude trvat maximalne dalsi 2. Takze si nejspis nikdo ani nevsimne, ze neco 5 minut (dojdu si pro kafe) nebezelo.

A ted si vezmi, ze to zamlzili a rekli jen co chteli rict, jsou na to odbornici, aby rekli neco, co vypada OK, zatajit to nelze, tak neco reknou v ramci krizoveho managementu - je to neco, co se tak jako tak obcas stava vsude.

Cloudflare je známo tím, že vždycky zveřejňují post mortem analýzy, včetně toho, jaké chyby oni sami udělali. Mám-li si vybrat mezi tvrzením Cloudflare a ničím nepodloženým tvrzením anonyma v diskusi, věřím Cloudflare.

Chyby se stávají, ale v poslední době se až moc ukazuje, jak moc jsou mnohé služby závislé na podobných globálních subjektech jako Cloudflare (nebo Google, Amazon, Microsoft, Apple... vyberte své oblíbence) :-/

Další žába na prameni informací, o které se příliš neuvažuje a jejíž technický a provozní stav se (vzhledem k rozsahu její působnosti) ukazuje stejně tristní jako další podobné služby. Marketingově se to ale prodává dobře, tak proč investovat do robustní technologie a řádné správy, když správné PR vyjde levněji a technický dluh se před zákazníky schová. No smutný to je, no...

Máš to podobné ako v akejkoľvek inej infraštruktúre.
Všade sa rieši rovnaký problém, či službu rozvíjať ďalšími fičúrami alebo upratať technický dlh.

Použitím cloudflare túto otázku prenechávaš dodávateľovi, a teda strácaš nad tým kontrolu. Ale zároveň šetríš náklady, ktoré by si musel investovať, aby si obdobnú infraštruktúru mal vo svojej správe. A taktiež (o tom veľa manažérov neuvažuje) namiesto infraštruktúry, ktorú vieš ovplyvniť a centralizovať-decentralizovať sa stávaš závislým od úzkeho hrdla pár poskytovateľov "cloudu".

"Ale zároveň šetríš náklady"

To je naprosty scifi, zadny naklady nesetris. Tak maximalne ziskavas nekoho (coz je samozrejme pro managorment zasadni vyhoda) na koho muzes ukazat a rict "za to muzou oni", ale financne te to bude stat klidne i radove vic.

Protoze narozdil od vlastni infra kterou si dimenzujes pro svoje potreby, a provozujes si ji za naklady, tak tady musis zaplatit mnohem vic za bizuterii (protoze pole pro 10 disku stoji radove min nez pole pro 10 000 disku PER DISK atd atd atd), a predevsim musis zaplatit marzi provozovatele.

Jako bonus je vse zcela mimo tvoji kontrolu a kdyz se neco podela, jako ze se 100% podela, tak sem muzes maximalne modlit.

To ze tvoje data budou verejne na netu je uz jen takovej malej a zcela jistej bonus.

Môžeš šetriť náklady, pretože "úspory z rozsahu". Do určitej veľkosti je (alebo môže byť) vlastná infraštruktúra a predovšetkým odborníci kompetentní ju správne navrhnúť a udržiavať drahšia než to zaplatiť od dodávateľa, ktorý ten návrh platí len raz, a náklady na údržbu nerastú s veľkosťou lineárne...

Zadny uspory z rosahu neexistuji. Ani jediny cent.

…to ne, to není možný, jak to že znají příčinu do 24h po události? Jinde to trvá týdny, v našem státním IT to trvá měsíce…

Design, kdy když složba má omezenou velikost konfiguračního souboru mi přijde ... zvláštní. Ale řekněme, že proto byly nějaké technickéí důvody. Nicméně pak bych si měl dát sakra majzla, abych nevygeneroval příliš velký soubor - je to vlastně stejný problém, jako kdyby ten soubor byl třeba syntakticky špatně.

Jasně, že po bitvě je každý generál a v praxi jsou věci složité a ne takhle jasné, ale stejně mi to přijde primárně jako problém SW architektury.

Technické dôvody sú dobré, pamäť je predalokovaná aby sa šetril výkon dokonca i na alokáciách.

Problém vznikol pri prepise kódu do Rustu, kde možnosť, že sa objekt nezmestí do pamäte bola síce ošetrená, ale len "korektným" pádom celého programu.

Design, kdy když složba má omezenou velikost konfiguračního souboru mi přijde ... zvláštní.
Já nechápu tohle divení se. Z podstaty věci je velikost souboru vždy omezená. Kdyby ničím jiným, tak dostupným místem. Rozdíl je jenom v tom, zda je to pevný limit, který je někde záměrně zadaný, validuje se a pokud možno je v dokumentaci. Nebo jestli je to limit, který plyne z okolností a může se v průběhu času měnit, třeba když ubyde místo na disku.

V tomhle případě to vypadá spíš na tu druhou variantu. Pokud je soubor vždy přibližně stejně velký, nebo třeba roste pomalu v čase s růstem sítě, dá se pochopit, že tam validace na vstupu není – protože správný soubor prostě bude vždy dostatečně malý na to, aby bylo možné jej zpracovat.

Ověřovat velikost souboru při generování samozřejmě může být jeden ze způsobů, jak validovat, že se generuje správně. Jenže když to budete navrhovat, nejspíš si řeknete „to by byla dost výjimečná chyba, že by se generování souboru pokazilo zrovna takovým způsobem, že by se soubor výrazně zvětšil“. Ostatně validace nějakého generátoru se budou zaměřovat spíš na to, že tam nějaká data nechybí nebo tam nejsou špatná data navíc. Validovat, že tam není něco duplicitně – co teď to asi Cloudflare do validací přidá, ale není to něco, s čím byste obvykle počítal hned od začátku. Zejména když by ty duplicitní záznamy nejspíš nevadily, kdyby jich nebylo moc.

Nejde o duplicitní záznamy, ty by samy o sobě ničemu nevadily. Šlo mi o to, že na straně konsumera byl nějaký constraint (velikost souboru), který nebyl kontrolovaný na straně producera.

Samozřejmě, když tam pošlu velký sobor (1 TB), tak to spadne tak jako tak, ale vygenerování tak velkého souboru je dost nepravděpodobné. Tady byl ale limit evidentně mnohem níž a jeho překročení časem pravděpodobné (a taky se to stalo).

Jenže na straně konzumenta nebyl záměrný limit. Na straně konzumenta to bylo řešené způsobem „do téhle paměti se to vždycky vejde“, protože se to tam vždy vešlo a velikost se neměnila. Překročení toho limitu nebylo pravděpodobné, a nestalo se to běžným růstem souboru (který snad běžně vůbec neroste). Ten soubor byl větší právě kvůli těm duplicitním záznamům.

Mimochodem, limit by měl v tomto případě stanovit producent, ten ví, jak mohou být data velká. Konzumenti se pak musí přizpůsobit.

Já souhlasím s tím, že nastavovat a kontrolovat limity je dobrá věc. Ale zrovna velikost souborů se omezuje málokdy, pokud to není z důvodu velikosti úložiště nebo to nejsou limity souborového systému. Zejména když jsou to interní soubory a ten soubor má nějakou svou přirozenou velikost, tj. nehrozí, že mi nějaký záškodník pošle obří soubor.

V článku dosť výrazne chýba informácia, že pád spôsobilo neošetrené pretečenie pamäte v Ruste, v kóde, ktorý predtým dlhé roky fungoval a potom bol prepísaný do Rustu.

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 (...) Again, the limit exists because for performance reasons we preallocate memory for the features.

When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below: (...)

This resulted in the following panic which in turn resulted in a 5xx error.

K žádnému přetečení paměti nedošlo. Daný kód vrátil validní Result type, který se Cloudflare rozhodl řešit přes explicitní panic při chybě. Což je věc která není u inicializace aplikace zas tak velké zlo, pokud ta chyba není recoverable. Správně by měli udělat rollback konfigurace a nahodit to znova.

19. 11. 2025, 14:58 editováno autorem komentáře

Souhlas, zjevně paměti bylo málo, kód detekoval chybu, se kterou kód vyšší úrovně nepočítal. Z hlediska Rust korektní chování.

Co mi tam chybí, je neschopnost identifikovat chybu poměrně dlouhou dobu. A tam nejspíš doplácí Rust na chybějící podporu vyjímek. U Java by se zpropagoval celý stacktrace a někde dole by bylo "file too big to fit into memory". U Rust a ostatních jazyků bez exception bude jenom Result-Err a hledej jehlu v kupce sena... Logování může samozřejmě pomoct, ale to se nedělá v low level funkcích, u kterých se ani neví, jestli chyba je běžná nebo neočekávaná.

Tohle nesouvisí s podporou nebo nepodporou výjimek. Pokud do svého programu dám log chyby "too many items in configuration", tak z jedné chybové hlášky je naprosto jasné, co je špatně.

"Pokud do svého programu dám log chyby"

Jenze to bys musel kontrolovat vstupy, a to dneska neni v mode.

- unwrap explicitně vrací stack trace.
- pokud by mohli něco zlepšit, bylo by to použití expect(), který by jim umožnil přidat důvod pro panic
- propagaci trace řeší snad každá knihovna pro zpracování chyb. Konkrétně třeba anyhow, eyre, miette, error_stack

Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)

Spekulace: Dalo by se tomu zabránit, kdyby to nepřepisovali?

Já jsem si ale celkem všiml, že v rustu toto lidi dělají - tak nějak předpokládají, že když se to zkompiluje, tak to nemá chyby - testů je většinou málo... ne všechny crates jsou kvalitní a často se mi stalo, že jsem něco jen zkoušel (nějaký rust program) a hitnul jsem panic prakticky hned. Možná se eliminovali memory-safety bugy, ale těch logických je mnohem víc? Stačí se podívat na uutils/coreutils, sudo-rs - všechno bylo způsobené ignorancí.

Asi opravdu záleží na kultuře - rust prostě není záruka bezchybnosti a je potřeba kultura testování, jinak sice přestaneme počítat memory bugy, ale začneme počítat logické bugy.

Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)
Memory safe neřeší všechny problémy světa a nikdo kromě odpůrců memory safe jazyků to netvrdí.

Dalo by se tomu zabránit, kdyby to nepřepisovali?
Přepis s tím nijak nesouvisí. Obě verze mají předalokaci (logicky) a obě verze selhávaly, akorát každá jiným způsobem.

To ví přece každý, že to neřeší všechny problémy světa - opět idiotská odpověď od vás.

Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy. Ono jestli těch bugů bude ve výsledku stejně, jen budou jiná kategorie, tak v čem si polepšíme :) ?

Já dělám běžně v memory safe jazycích a těch logických chyb se udělá strašně moc. Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.

To ví přece každý, že to neřeší všechny problémy světa
Pokud to ví každý, proč se tedy podivujete, že to nevyřešilo problém, který s memory-safe nesouvisí?

opět idiotská odpověď od vás.
Vždycky svou odpověď přizpůsobuju dotazu.

Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy.
Nebudou.

Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.
Prý všichni vědí, že memory-safe nevyřeší všechny problémy světa. Je tedy logické při použití memory safe jazyka mít pocit bezpečí, že v memory-safe kódu nebudou chyby v přístupu mimo platnou paměť. Ale bylo by nelogické mít pocit bezpečí v jiných oblastech, pokud nejsou chráněny jiným způsobem.

Podle toho co píšou měli ten limit nastavený uměle. Takže ano, v jiném jazyce by jim to spadlo stejně.

To je právě ta pravá otázka. Spadlo by to a nebo by to bylo ošetřené (jak to měli dřív nevím)? Ono v rustu je jednoduché to nechat tak nějak hitnout ten panic.

Stačí si přečíst post mortem od CF. Problém byl v obou verzích, jenom se to projevilo v každé verzi jinak.

Ve spoustě jiných jazyků je zas celkem triviální ignorovat tu chybu úplně, případně neošetřit výjimku a sestřelit celou službu na recoverable chybě.

Po praxi z C++, Pythonu a občasného příspěvku do software v Go u mě error handling Rustu jednoznačně vede.