Przekonaj się sam!
Pozostaw wiadomość, a skontaktuje się z Tobą nasz dedykowany doradca.
Wyślij nam wiadomość
0/10000
Anatomia Katastrofy: Dlaczego Cloudflare zamilkł? Techniczna analiza incydentu z 18 listopada
Opublikowano: 2025-11-19
Analizy
Cisza w eterze
18 listopada 2025 roku, dokładnie o godzinie 11:20 czasu UTC, inżynierowie sieciowi na całym świecie zamarli. Wykresy ruchu sieciowego, zazwyczaj pulsujące życiem, nagle zanurkowały lub – w przypadku kodów błędów – wystrzeliły pionowo w górę. Użytkownicy próbujący dostać się do swoich ulubionych serwisów, od platform e-commerce po proste blogi, napotykali na ścianę w postaci komunikatu "Internal Server Error" (Błąd 500). Nie działał Discord, problemy miał Shopify, a nawet sama strona statusowa Cloudflare wydawała się krztusić.
To wydarzenie, które wielu z nas obserwowało z rosnącym niepokojem, wpisuje się w ponurą serię awarii tej jesieni, o czym pisaliśmy już w naszym podsumowaniu: Déjà vu: Czy Internet Właśnie Przechodzi "Jesień Średniowiecza"?. Podobny paraliż obserwowaliśmy miesiąc wcześniej podczas wielkiej awarii Amazon Web Services.
Dziś, gdy kurz już opadł, a serwery znów mruczą (a raczej szumią wentylatorami) w normalnym rytmie, mamy okazję zajrzeć pod maskę tego incydentu. Dzięki transparentności zespołu Cloudflare wiemy dokładnie, co się stało. I nie, to nie był atak hakerów, choć początkowo wszystko na to wskazywało. To była lekcja pokory dla inżynierii oprogramowania – historia o tym, jak "bezpieczna" zmiana uprawnień w bazie danych i jeden niefortunny błąd logiczny w kodzie mogą zatrzymać internet.
Zapraszam Was na techniczną podróż do wnętrza "czarnej skrzynki" Cloudflare. Przygotujcie kawę, bo będzie długo i merytorycznie.
"To musi być atak!" – Mgła wojny
Każdy incydent o dużej skali w pierwszej fazie wygląda jak chaos. Kiedy o 11:20 systemy monitorowania zaczęły świecić na czerwono, pierwszą myślą w centrum operacyjnym Cloudflare (NOC) nie był "błąd w kodzie". Podejrzenie padło na zmasowany atak DDoS.
Dlaczego? Ponieważ objawy były mylące. Systemy nie padły całkowicie i natychmiastowo. Obserwowano dziwne fluktuacje – ruch spadał, potem wracał, potem znów spadał. To klasyczny obraz walki systemów obronnych z botnetem, który zmienia wektory ataku. Co więcej, w wewnętrznych czatach inżynierów pojawiły się obawy, że może to być kontynuacja aktywności botnetu "Aisuru", który w ostatnich tygodniach prężył muskuły. Nawet Matthew Prince, CEO Cloudflare, wyraził obawę: "Martwię się, że to ten wielki botnet pokazuje siłę".
Sytuację pogarszał fakt, że padła również strona statusowa Cloudflare (Cloudflare Status). Teoretycznie jest ona hostowana poza ich infrastrukturą, aby być dostępną w razie awarii. Jednak zbieg okoliczności sprawił, że inżynierowie zaczęli podejrzewać wyrafinowany atak celowany, uderzający w wiele punktów jednocześnie.
Dopiero głębsza analiza logów wykazała, że problem nie przychodzi z zewnątrz. Źródło biło w samym sercu systemu.
Zrozumieć ClickHouse: Architektura problemu
Aby zrozumieć, co naprawdę się stało, musimy zanurkować w architekturę baz danych używanych przez Cloudflare. Firma intensywnie korzysta z ClickHouse – kolumnowej bazy danych OLAP, idealnej do analizy ogromnych ilości danych w czasie rzeczywistym.
W architekturze ClickHouse klaster składa się z wielu "shardów" (fragmentów). Aby odpytać dane ze wszystkich fragmentów jednocześnie, używa się tzw. tabel rozproszonych (Distributed tables). Te tabele zazwyczaj znajdują się w bazie o nazwie domyślnej. Jednak fizyczne dane, przechowywane na poszczególnych węzłach, znajdują się w tabelach "pod spodem", często w bazie systemowej oznaczanej jako r0 (lub podobnie, zależnie od konwencji).
Do dnia awarii, użytkownicy (i systemy) odpytujący metadane tabel (np. listę kolumn) widzieli tylko to, co było w bazie domyślnej. Dostęp do bazy r0 był niejawny (implicit).
Zmiana, która zmieniła wszystko
O godzinie 11:05 UTC wdrożono zmianę, która miała na celu poprawę bezpieczeństwa i niezawodności. Ironia losu, prawda?
Inżynierowie chcieli, aby zapytania rozproszone działały w oparciu o bardziej precyzyjne uprawnienia użytkownika inicjującego zapytanie. W tym celu zmieniono konfigurację uprawnień tak, aby dostęp do tabel w r0 stał się jawny (explicit). Dzięki temu system mógł lepiej kontrolować limity zasobów i uprawnienia dla poszczególnych podzapytań. Na papierze – świetna, wręcz podręcznikowa zmiana w duchu "least privilege" i lepszej kontroli.
W praktyce, ta zmiana miała jeden, niezamierzony skutek uboczny.
Zapytanie, które zabiło system
System Cloudflare posiada moduł Bot Management. Odpowiada on za ocenę każdego żądania HTTP pod kątem tego, czy pochodzi od człowieka, czy od bota. Ten system opiera się na modelach uczenia maszynowego (ML). Modele te potrzebują "cech" (features) – czyli konkretnych atrybutów ruchu, na podstawie których dokonują oceny.
Konfiguracja tych cech nie jest statyczna. Jest generowana dynamicznie co 5 minut na podstawie analizy ruchu, co pozwala Cloudflare adaptować się do nowych zagrożeń niemal w czasie rzeczywistym.
Proces generowania tej konfiguracji (pliku z cechami) wykonuje zapytanie do bazy ClickHouse, aby pobrać listę dostępnych kolumn (cech).
Kluczowy błąd polegał na tym, że zapytanie to nie filtrowało wyników po nazwie bazy danych. Przed godziną 11:05, zapytanie to zwracało listę kolumn tylko dla tabeli w bazie domyślnej. Po godzinie 11:05, kiedy uprawnienia do r0 stały się jawne, to samo zapytanie zaczęło zwracać listę kolumn dwukrotnie: raz dla tabeli w bazie domyślnej, i drugi raz dla tabeli w bazie r0.
Zamiast listy unikalnych cech, system otrzymał listę pełną duplikatów.
Pamięć i feralna obsługa błędu
Teraz przenosimy się z warstwy bazy danych do warstwy aplikacji. Główny system proxy Cloudflare (nazywany wewnętrznie "FL" lub w nowszej wersji "FL2") jest napisany w języku Rust. Rust słynie z bezpieczeństwa pamięci i wydajności, ale jest też bardzo rygorystyczny, jeśli chodzi o obsługę błędów.
Dla celów optymalizacji wydajności, moduł Bot Management w proxy prealokuje pamięć na cechy. Inżynierowie ustalili "twardy" limit na liczbę cech, które mogą być obsłużone. Limit ten wynosił 200. Było to znacznie powyżej ówczesnego użycia, które oscylowało w granicach 60 cech. Wydawało się to bezpiecznym marginesem – ponad trzykrotny zapas.
Kiedy jednak zapytanie do bazy zaczęło zwracać zduplikowane wiersze, wynikowy plik konfiguracyjny "spuchł". Liczba zdefiniowanych cech (przez duplikaty) przekroczyła limit 200.
Tutaj dochodzimy do sedna problemu w kodzie. Programista użył konstrukcji, która zakładała, że operacja dodania cech do bufora zawsze się powiedzie. W świecie programowania, a szczególnie w języku Rust, istnieje instrukcja (często nazywana unwrap), która mówi kompilatorowi: "Zaufaj mi, tutaj nie będzie błędu, a jeśli będzie – zatrzymaj cały program".
Ponieważ plik konfiguracyjny był uszkodzony (zbyt duży), instrukcja ta powodowała tzw. panic. Wątek obsługujący ruch sieciowy po prostu "umierał".
Pętla śmierci i efekt domina
Gdyby to zdarzyło się raz, system by się zrestartował i wstał. Problem w tym, że uszkodzony plik konfiguracyjny był propagowany do wszystkich serwerów w sieci Cloudflare.
- Serwer pobiera nową konfigurację (z duplikatami).
- Proxy próbuje ją załadować.
- Kod uderza w limit 200 cech.
- Proces "panikuje" i kończy działanie.
- System nadzorczy restartuje proces proxy.
- Proces wstaje, pobiera konfigurację... i wracamy do punktu 1.
To spowodowało globalną pętlę restartów na tysiącach maszyn. Dla użytkownika końcowego wyglądało to jak błąd 500, 502 lub 504, ponieważ proxy nie było w stanie obsłużyć żądania.
Co ciekawe, starsza wersja proxy ("FL") nie "panikowała", ale z powodu błędnej konfiguracji po prostu przestawała działać poprawnie, nadając wszystkim ruchom wynik "bot score" równy zero. To oznaczało, że klienci polegający na blokowaniu botów mogli zostać zalani spamem, albo (jeśli mieli reguły blokujące niskie wyniki) zablokować prawdziwych użytkowników.
Dlaczego padł Dashboard i inne usługi?
Cloudflare to system naczyń połączonych. Awaria głównego proxy pociągnęła za sobą inne usługi:
- Workers KV: Usługa ta jest fundamentem wielu systemów Cloudflare. Ponieważ dostęp do niej odbywa się przez główny proxy, lawina błędów odcięła dostęp do danych.
- Cloudflare Access: Usługa ta polega na Workers KV. Brak KV oznaczał brak możliwości logowania i autoryzacji.
- Dashboard (Panel Klienta): Panel administracyjny Cloudflare korzysta z usługi Turnstile (ich alternatywa dla CAPTCHA) przy logowaniu. Ponieważ Turnstile nie ładowało się (bo proxy leżało), nikt nie mógł się zalogować, by sprawdzić, co się dzieje. Nawet sami pracownicy mieli problemy z narzędziami wewnętrznymi.
To klasyczny przykład zależności cyklicznej w sytuacji kryzysowej.
Droga do naprawy: Od chaosu do stabilizacji
Proces naprawy nie był trywialny. Pamiętajmy o "mgle wojny".
- 11:20 - 13:05: Zespół walczył z objawami, myśląc, że to problem z wydajnością KV lub atak. Próbowano przekierowywać ruch, limitować konta.
- 13:05: Przełom. Udało się wdrożyć obejście (bypass) dla Workers KV i Access, aby te usługi omijały główny, uszkodzony proxy. To pozwoliło inżynierom odzyskać kontrolę nad narzędziami i zmniejszyć wpływ awarii na kluczowe systemy wewnętrzne.
- 13:37: Zidentyfikowano winowajcę – plik konfiguracyjny Bot Management. Zrozumiano, że to on powoduje awarię w kodzie.
- 14:24: Zatrzymano automatyczne generowanie i propagację nowych (wadliwych) plików.
- 14:30: "Wstrzyknięto" ręcznie ostatnią znaną dobrą wersję pliku konfiguracyjnego do systemu dystrybucji.
- Restart: Wymuszono restart proxy. Ponieważ plik był już poprawny (mieścił się w limicie 200), procesy wstały poprawnie i przestały się restartować.
Do godziny 17:06 inżynierowie "sprzątali" po awarii, restartując pozostałe usługi, które wpadły w stan błędu podczas głównego incydentu.
Wnioski: Lekcja dla całej branży
Incydent Cloudflare to brutalne przypomnienie o kilku fundamentalnych zasadach inżynierii systemów rozproszonych, o których łatwo zapomnieć w pędzie za innowacjami.
Po pierwsze: Walidacja danych wejściowych to nie tylko ochrona przed użytkownikiem. Cloudflare potraktowało dane z własnej bazy danych jako "zaufane". Kod zakładał, że baza zwróci unikalne kolumny, bo "tak zawsze było". Zmiana w innej części systemu zburzyła to założenie. Traktuj dane z wewnętrznych systemów tak samo nieufnie, jak dane od użytkownika.
Po drugie: Błędy nie powinny zabijać procesu. W kodzie produkcyjnym panika w głównym wątku obsługującym żądania sieciowe jest niedopuszczalna. Błąd konfiguracji powinien skutkować zalogowaniem błędu i ewentualnie działaniem w trybie awaryjnym, ale nigdy całkowitym wyłączeniem usługi.
Po trzecie: Obserwowalność w warunkach skrajnych. Fakt, że systemy debugowania zużywały ogromne ilości zasobów podczas awarii (próbując raportować błędy), dodatkowo pogorszył sytuację, zwiększając opóźnienia. Systemy monitoringu nie mogą obciążać systemu, który próbują diagnozować.
Po czwarte: Stopniowe wdrażanie. Zmiana w bazie danych, która spowodowała problem, oraz propagacja wadliwego pliku miały skutki globalne. Brak mechanizmu stopniowego wdrażania (canary release) dla plików konfiguracyjnych sprawił, że błąd dotknął wszystkich naraz. Cloudflare zapowiedziało już, że wprowadzi procedury testowania plików konfiguracyjnych identyczne jak dla kodu.
Podsumowanie
Jesień 2025 roku zapisze się w historii internetu czarnymi zgłoskami. Po awarii AWS z października, teraz Cloudflare dołącza do niesławnego klubu "Totalny Paraliż". Pokazuje to, jak bardzo nasz cyfrowy świat polega na zaledwie kilku filarach. Gdy jeden z nich się chwieje – czy to przez złośliwy atak, czy przez jeden nadmiarowy wiersz w bazie danych – drży cała globalna gospodarka.
To, co wydarzyło się 18 listopada, nie było wynikiem działania hakerów. To był błąd ludzki, błąd procesowy i błąd w kodzie. I choć brzmi to banalnie, w skali, w jakiej operuje Cloudflare, banały zamieniają się w katastrofy.
Czy to się powtórzy? Z pewnością. Niekoniecznie w Cloudflare, niekoniecznie w ten sam sposób. Ale systemy o takiej złożoności są z natury podatne na błędy. Naszym zadaniem – jako specjalistów security i administratorów – jest budowanie systemów odpornych, które potrafią przetrwać upadek giganta. Lub przynajmniej mieć przygotowany plan B, gdy nagle zobaczymy błąd 500 na połowie odwiedzanych stron.
Więcej o kontekście tej awarii przeczytacie w naszym artykule: Déjà vu: Czy Internet Właśnie Przechodzi "Jesień Średniowiecza"?. Warto też zapoznać się z naszą analizą ryzyka związanego z chmurą w sektorach strategicznych.
Bądźcie bezpieczni i... sprawdzajcie swoje systemy obsługi błędów!
Źródło: Oficjalny blog Cloudflare.
Aleksander
Powiązane artykuły
Analizy
Internet na Kolanach: Cloudflare Pada Miesiąc po AWS. Kronika Czarnej Jesieni
18 listopada zapisze się jako dzień, w którym "Error 500" stał się najczęściej oglądaną stroną świata. Cloudflare dołączył do AWS, paraliżując X, ChatGPT i Zoom. Analizujemy przyczyny i skutki.
2025-11-18
7 min
Analizy
Chmura w Sektorach Strategicznych: Silnik Innowacji czy Systemowe Ryzyko?
Po niedawnej awarii AWS, która wstrząsnęła globalnym internetem, musimy zadać sobie fundamentalne pytanie: czy możemy powierzyć nasze wojsko, medycynę i infrastrukturę krytyczną chmurze?
2025-10-21
19 min
Analizy
Luki 0-Day: Niewidzialna Broń. Anatomia, Rynek i Obrona przed Nieznanym
Kompleksowa analiza fenomenu Zero-Day: od technicznych detali uszkodzeń pamięci, przez wielomilionowy czarny rynek i historię cyberbroni (Stuxnet, Pegasus), aż po polskie realia prawne i strategie obrony w dobie AI.
2025-11-18
39 min
Komentarze
Ładowanie komentarzy...