Globális szolgáltatáskiesést okozott a Cloudflare hibás konfigurációs frissítése

Segítséget kaptál? Szívesen töltöd itt az idődet? Visszajársz hozzánk? Támogasd a munkákat: Ko-fi és Paypal!

kami911 képe

2025. november 18-án világszerte akadozott az internetforgalom, miután a Cloudflare hálózata 11:20 UTC körül súlyos hibákat kezdett mutatni. A probléma miatt több millió felhasználó találkozott 5xx HTTP-hibaoldalakkal, számos weboldal és szolgáltatás pedig részben vagy teljesen elérhetetlenné vált. A vállalat közlése szerint a kimaradást nem kibertámadás, hanem egy adatbázis-jogosultságkezelési módosítás okozta. A hibás beállítás következtében a Bot Management rendszerhez tartozó úgynevezett „feature fájl” mérete a kétszeresére nőtt, ami már meghaladta a hálózati forgalomirányító szoftverek által elfogadható határértéket. A modul ezért összeomlott, és hibaválaszokat adott minden olyan kérésre, amely áthaladt rajta.

Egy hiba soha sem jó, de így felvállalva, lehet belőle másnak is tanulni.

A Bot Management konfigurációs fájlját minden néhány percben automatikusan generálja a rendszer, majd terjeszti a Cloudflare teljes infrastruktúrájára. Mivel a módosított adatbázis-cluster csak egy részén működött az új jogosultságkezelés, a rendszer időszakosan jó és rossz konfigurációkat küldött szét, ami rendkívül zavaró, hullámzó hibákat eredményezett. Ez téves irányba vitte a kezdeti vizsgálatot: a mérnökök egy része eleinte egy újabb hiperskálájú DDoS-támadást feltételezett.

A helyzetet tovább bonyolította, hogy a Cloudflare teljesen különálló infrastruktúrán működő státuszoldala is leállt, ami első ránézésre összehangolt támadás benyomását keltette. A vállalat később egyértelművé tette, hogy ez puszta egybeesés volt.

A hibát végül 14:24-kor sikerült elszigetelni, amikor a mérnökök leállították a hibás fájl generálását és terjesztését, majd egy korábbi, ismert jó verziót juttattak vissza a rendszerbe. A maghálózat forgalma 14:30-ra normalizálódott, a teljes szolgáltatás pedig 17:06-ra állt helyre.

Szolgáltatások széles körét érintette a hiba

A kimaradás kihatott többek között:

Core CDN és biztonsági szolgáltatások:
5xx HTTP hibák, a bejegyzés elején bemutatott tipikus hibaoldalakkal.

Turnstile:
A Turnstile nem töltődött be.

Workers KV:
A KV erősen megnövekedett 5xx hibaarányt mutatott, mert a front-end gateway kérései a hibás magproxy miatt kiestek.

Dashboard:
Többnyire működőképes volt, de a Turnstile kiesése miatt a felhasználók nagy része nem tudott bejelentkezni.

Email Security:
Az e-mailek feldolgozása és kézbesítése nem állt le, azonban ideiglenesen kiesett egy IP reputációs forrás, ami csökkentette a spamszűrés pontosságát.

Access:
Széleskörű hitelesítési hibák jelentkeztek, kivéve a már aktív munkameneteket.

A hibás hitelesítési kísérletek hibaoldalt eredményeztek, sikeres bejelentkezések pedig helyesen bekerültek a logokba. A Dashboard bejelentkezési felülete szintén részben elérhetetlenné vált, mivel a Turnstile működésképtelenné vált.

A cég bocsánatot kér: „2019 óta a legrosszabb formánkat hoztuk”

A Cloudflare vezetője, Matthew Prince nyilatkozatában hangsúlyozta: ilyen volumenű kiesés több mint hat év óta nem történt a vállalat történetében.

„Egy ilyen kimaradás elfogadhatatlan. Tudjuk, hogy cserbenhagytuk ügyfeleinket és az egész internetet” – írta Prince.

A vállalat már megkezdte azoknak a belső védelmi és ellenőrzési mechanizmusoknak a bevezetését, amelyek célja, hogy a jövőben egy konfigurációs hiba se okozhasson hálózatszintű leállást.

A kimaradás

Az alábbi ábra a Cloudflare által kiszolgált HTTP 5xx hibakódok számát mutatja. Ennek általában minimálisnak kellene lennie, és ez így is volt egészen a kimaradás kezdetéig.

A 11:20 előtti mennyiség a megszokott alapszint. A hirtelen kiugrás és az azt követő ingadozás a hibás feature fájl betöltéséből eredő rendszerhibákat jelzi. Szokatlan volt, hogy a rendszer időnként magától látszólag helyreállt. Ez belső hibánál ritka jelenség.

A magyarázat: a fájlt ötpercenként egy ClickHouse-adatbázis cluster futtatta, amelyet éppen jogosultságkezelési szempontból frissítettünk. Hibás adat csak akkor keletkezett, ha a lekérdezés a frissített részeken futott. Így minden öt percben esély volt jó vagy rossz konfiguráció létrejöttére, amely aztán gyorsan szétterjedt a hálózati gépekre. Ez az ingadozás bizonytalanná tette a diagnózist, és először támadást feltételeztünk. Később azonban a ClickHouse minden csomópontja már a hibás fájlt generálta, és a rendszer stabilan rossz állapotba került.

A hibák 14:30-ig folytatódtak, amikor is azonosítottuk a problémát, leállítottuk a hibás feature fájl generálását, és manuálisan egy ismert jó fájlt juttattunk be a terjesztési sorba. Ezután a magproxy újraindítására került sor.

A grafikon végén látható hosszú „farok” a különböző szolgáltatások újraindításából ered, ahol a 5xx hibák száma végül 17:06-ra állt vissza a normál szintre.

A Cloudflare szerepe miatt a hiba hatása globális volt

A Cloudflare infrastruktúráját világszerte több millió weboldal használja forgalomelosztásra, DDoS-védelemre és gyorsítótárazásra. Emiatt a vállalat hibái az internet jelentős részére közvetlen hatást gyakorolnak. A mostani incidens újra rámutat arra, mennyire kritikus szereplővé vált a Cloudflare az internet működésében — és milyen következményekkel jár, ha egy ilyen központi infrastruktúra hibát szenved.

További információk

Hogyan dolgozza fel a Cloudflare a kéréseket – és mi romlott el

A Cloudflare beérkező kérései egy meghatározott úton haladnak végig: HTTP/TLS → core proxy („FL” – Frontline) → Pingora → cache/origin.

A kliensoldali biztonsági funkciók, WAF, DDoS-szűrés mind itt működnek. A Bot Management egy olyan modul, amely minden kéréshez botpontszámot rendel. A modell bemenete egy „feature” fájl — a kimaradás kiváltó oka. Ez a fájl párpercenként frissül a ClickHouse cluster lekérdezése alapján. A jogosultságkezelés módosítása azonban duplikált sorokat eredményezett, ami megkétszerezte a fájl méretét. Ez meghaladta a Bot Management modul szoftveres limitjét, így az összeomlott, és a core proxy 5xx hibákat adott vissza.

Miért hitte a csapat, hogy támadás történhetett?

A Cloudflare státuszoldala leállt — pedig teljesen független infrastruktúrán fut. Bár csak véletlen egybeesés volt, ez félrevezette a diagnosztikát, és felmerült a lehetőség, hogy támadás éri mind a Cloudflare-t, mind a státuszoldalt. Eközben a csapatban felmerült, hogy ez a közelmúltbeli, nagy volumenű Aisuru DDoS-hullám folytatása lehet.

A lekérdezési viselkedés változása

A ClickHouse-disztribúciós lekérdezések felépítése kapcsán a jogosultsági módosítás miatt a rendszer olyan táblát is visszaadott, amelyhez a lekérdezés logikája korábban nem nyúlt hozzá. Ez duplikált sorokat eredményezett a feature fájlban, több mint kétszeresére növelve a jellemzők számát. A Bot Management modulnak 200 feature-re van memóriakerete, miközben kb. 60-at használunk. A több mint 200 sor túllépte ezt a limitet, és pánikot váltott ki a rendszerben.

További hatások

A Workers KV és az Access szolgáltatások szintén a core proxyra támaszkodnak, így érintettek voltak. A KV esetében 13:04-kor került bevezetésre egy ideiglenes proxy-kerülő megoldás, ami csökkentette az érintett rendszerek hibáit. A Cloudflare Dashboard a KV-re és a Turnstile-re is támaszkodik, ezért a bejelentkezési funkciók is hibásodtak.

A helyreállítás és a jövőbeni lépések

A rendszerek helyreállítása után a Cloudflare megkezdte az új védelmi intézkedések bevezetését:

  • A konfigurációs fájlok automatikus ellenőrzésének megerősítése
  • Globális kill switch funkciók bővítése
  • A hibajelentési rendszerek túlterhelésének megakadályozása
  • A core proxy moduljainak hibakezelési módszereinek felülvizsgálata

Ez a Cloudflare legsúlyosabb kimaradása volt 2019 óta.

Idővonal (UTC)

Idő Állapot Leírás
11:05 Normál működés Adatbázis-hozzáférési módosítás telepítése
11:28 Hatás kezdete Első hibák az ügyfélforgalomban
11:32–13:05 KV hibák vizsgálata A csapat a KV lassulását vizsgálja
13:05 KV és Access proxy-kerülő aktiválva Csökkent hatás
13:37 A hibás Bot Management fájl visszaállítása előkészítve Utolsó jó verzió visszatöltése
14:24 Hibás fájl generálása leállítva Automatikus terjesztés megszüntetve
14:30 Fő hatás megszűnik A helyes fájl globálisan terjesztve
17:06 Teljes helyreállítás Összes szolgáltatás normalizálódott

További részletek a cég blogbejegyzésében.