Dzień 18 listopada 2025 roku zapisał się w historii internetu jako dzień poważnej globalnej destabilizacji. Awaria Cloudflare – firmy obsługującej kluczowe usługi dla około jednej piątej światowego ruchu sieciowego – na kilka godzin sparaliżowała dostęp do milionów stron internetowych i usług, od globalnych platform (m.in.: X, ChatGPT, Spotify) po mniejsze aplikacje i systemy płatnicze. Chociaż początkowo podejrzewano cyberatak o dużej skali, oficjalne stanowisko Cloudflare, jasno wskazało na wewnętrzny błąd proceduralny jako główną przyczynę incydentu.
Główna przyczyna awarii nie była złośliwym działaniem, lecz kaskadowym efektem niezamierzonej zmiany wewnętrznej:
- Wewnętrzna zmiana uprawnień: Cloudflare prowadziło prace nad poprawą zarządzania uprawnieniami w swoim klastrze baz danych ClickHouse (używanych do generowania plików konfiguracyjnych). Wprowadzona zmiana dostępu sprawiła, że system zaczął zwracać metadane z dodatkowej, bazowej struktury.
- Podwojenie pliku funkcji: Zmiana uprawnień spowodowała, że zapytanie generujące krytyczny „plik funkcji” (feature file) dla systemu Bot Management zwróciło dużą liczbę zduplikowanych wierszy. W rezultacie rozmiar pliku konfiguracyjnego dla Bot Management niemal się podwoił.
- Zduplikowany plik został następnie rozesłany do wszystkich maszyn brzegowych Cloudflare. Oprogramowanie (core proxy, znane jako FL2) miało sztywny limit prealokowanej pamięci dla tego pliku (ustawiony na 200 cech, przy faktycznym użyciu ok. 60). Nowy, większy plik przekroczył ten limit, wywołując nieobsługiwany błąd (panic) w kodzie Rust.
- Krytyczny błąd HTTP 5xx: błąd systemu core proxy spowodował, że maszyny brzegowe zaczęły zwracać użytkownikom błędy HTTP 5xx, skutecznie odcinając dostęp do milionów stron internetowych korzystających z Cloudflare.
Ze względu na skalę awarii i nietypowe, cykliczne wahania błędów (system generował raz dobry, raz zły plik konfiguracyjny co 5 minut), zespół Cloudflare początkowo podejrzewał, że padł ofiarą ataku DDoS na hiperskalę, np. powiązany z niedawnymi atakami Aisuru. Podczas incydentu padła również strona statusowa Cloudflare. Strona ta jest hostowana całkowicie poza infrastrukturą Cloudflare, a jej awaria w tym samym czasie była jedynie zbiegiem okoliczności, który dodatkowo wprowadził w błąd zespół diagnostyczny, sugerując skoordynowany atak.
Awaria Cloudflare ponownie uwypukliła krytyczne słabości globalnego ekosystemu internetowego, które wykraczają poza samą firmę:
- Awaria jednego dostawcy usług chmurowych lub CDN (takich jak: Cloudflare, AWS, Azure) ma natychmiastowy, globalny i paraliżujący wpływ. Eksperci, np. z Check Point Software Technologies, podkreślają, że w coraz bardziej scentralizowanym świecie, pojedynczy błąd może sparaliżować tysiące firm i instytucji jednocześnie.
- Wiele organizacji, z racjonalnych powodów biznesowych (koszty, wydajność), opiera cały swój ruch na jednym dużym dostawcy. To powtarzająca się słabość. Incydent udowodnił, że posiadanie realnego planu awaryjnego lub strategii multi-cloud jest konieczne, aby w przypadku krytycznej awarii móc błyskawicznie przekierować ruch.
- Choć awaria nie była cyberatakiem, takie zdarzenia tworzą idealne „okno chaosu” dla przestępców. Nieprzewidziane przerwy w działaniu usług zwiększają podatność zespołów IT i użytkowników końcowych. W takim momencie rośnie ryzyko ataków phishingowych (np. fałszywych powiadomień o blokadzie konta z powodu awarii) i prób socjotechnicznych.
Zarówno Cloudflare, jak i użytkownicy jego usług (właściciele stron i aplikacji) powinni wyciągnąć z awarii konkretne wnioski proceduralne, takie jak:
- Pliki konfiguracyjne generowane wewnętrznie przez systemy (takie jak Bot Management) muszą być traktowane z tą samą ostrożnością i zabezpieczeniami co dane wprowadzane przez użytkownika. Należy walidować ich rozmiar i strukturę przed dystrybucją.
- Wdrożenie mechanizmów pozwalających na natychmiastowe i globalne wyłączenie problematycznej funkcji (lub jej modułu) w celu szybkiej stabilizacji sieci.
- Dokładny przegląd wszystkich modułów core proxy pod kątem niewłaściwej obsługi błędów i uniemożliwienie, by błąd w jednym module powodował globalną awarię systemu.
W przypadku użytkowników oraz Administratorów systemów informatycznych:
- Zamiast polegać na jednym dostawcy, należy rozważyć zastosowanie architektury, w której kluczowe usługi mogą być przełączone na zapasowego dostawcę (np. drugi CDN lub inny region chmurowy) w przypadku awarii.
- Opracowanie i przetestowanie procedury na wypadek awarii kluczowego dostawcy infrastruktury. Obejmuje to proces szybkiego przełączenia DNS oraz strategie komunikacji z klientami.
- Przypomnienie pracownikom i użytkownikom o wzmożonym ryzyku ataków socjotechnicznych i phishingowych w okresie dużych awarii sieciowych. Przestępcy często podszywają się pod helpdeski lub administrację, wykorzystując chaos do wyłudzenia danych logowania.
- Upewnienie się, że własna strona statusowa lub kanał komunikacji kryzysowej (np. na niezależnym koncie) jest hostowany w zupełnie innym, niezależnym ekosystemie, aby móc komunikować się z klientami nawet w przypadku całkowitej awarii Twojej głównej infrastruktury.