Awarie Cloudflare 18 listopada 2025 r.: co poszło nie tak, jak się bronić i czego się nauczyć

Wprowadzenie do problemu / definicja luki

18 listopada 2025 r., około 11:20 UTC (12:20 czasu polskiego), sieć Cloudflare zaczęła masowo zwracać błędy HTTP 5xx, co przełożyło się na niedostępność wielu serwisów na całym świecie (w tym X, ChatGPT, Uber, Spotify, Canva). Cloudflare potwierdził, że incydent nie był atakiem — źródłem problemu okazał się błąd operacyjno-konfiguracyjny skutkujący powstaniem nadmiernie dużego pliku cech („feature file”) używanego przez moduł Bot Management. Plik przekroczył limit obsługiwany przez oprogramowanie proxy, co spowodowało jego awarię i kaskadowe błędy w ruchu klientów. Główna przyczyna została usunięta, a ruch przywrócono ok. 14:30 UTC, pełna stabilizacja nastąpiła o 17:06 UTC.

W skrócie

• Kiedy: start degradacji 11:20 UTC, główne przywrócenie 14:30 UTC, koniec 17:06 UTC (18 listopada 2025).
• Co zawiodło: generowanie pliku „feature” dla Bot Management (duplikaty cech po zmianie uprawnień w ClickHouse), co przekroczyło limit liczby cech w module i wywołało błąd krytyczny w proxy (FL/FL2).
• Skala: globalna; zauważalny wpływ na popularne usługi internetowe (m.in. X, ChatGPT).
• Co to nie było: nie DDoS/atak, lecz wewnętrzna zmiana konfiguracji + błąd obsługi limitu.

Kontekst / historia / powiązania

Cloudflare określił zdarzenie jako najpoważniejszą awarię od 2019 r. — wcześniejsze incydenty dotyczyły zwykle panelu czy nowszych funkcji, nie zaś ogólnego przepływu ruchu. Incydent wpisuje się w serię ostatnich dużych awarii w ekosystemie chmury (AWS, Azure), co potwierdza rosnącą współzależność usług infrastrukturalnych.

Analiza techniczna / szczegóły luki

Łańcuch zdarzeń (high-level):

1. O 11:05 UTC wdrożono zmianę uprawnień w klastrze ClickHouse, która sprawiła, że zapytanie generujące plik cech („feature file”) zaczęło zwracać duplikaty kolumn (z powodu ujawnienia metadanych z dodatkowej bazy r0).
2. Wygenerowany co 5 minut plik z nadmiarowymi cechami był propagowany globalnie.
3. Moduł Bot Management posiada limit liczby cech (ok. 200) oraz prealokację pamięci — przekroczenie limitu spowodowało panic/unwrap error w implementacji FL2 (Rust) i błędy HTTP 5xx.
4. W starszym silniku FL nie widać było 5xx, ale bot score = 0, co mogło generować fałszywe pozytywy w regułach antybotowych.
5. Dodatkowo wystąpiły wtórne skutki: Workers KV, Access, Turnstile oraz Dashboard notowały problemy logowania i wzrost opóźnień; część z nich złagodzono dzięki bypassowi KV ok. 13:04 UTC.

Dlaczego diagnoza była trudna?

• System czasowo „sam się podnosił”, ponieważ jedne nody generowały „dobre”, a inne „złe” pliki — fluktuacja co ~5 min utrudniała identyfikację winowajcy.
• Zbieg okoliczności: niedostępność status page (hostowanej poza infrastrukturą Cloudflare) wprowadziła podejrzenie skoordynowanego ataku.

Ostateczna naprawa: zatrzymanie generacji i dystrybucji wadliwego pliku, wstawienie „last-known-good”, restart proxy i stopniowe restartowanie zależnych usług.

Praktyczne konsekwencje / ryzyko

• Ryzyko biznesowe: utrata przychodów, spadek konwersji, wizerunkowe koszty „internet stanął”. Dla spółek publicznych — wpływ na komunikację (przykład: zakłócone wydarzenia IR).
• Ryzyko bezpieczeństwa: reguły oparte na bot score mogły w starszym FL reagować nieprawidłowo (score=0 → blokady/obejścia). Potencjalny degradujący wpływ na detekcję spamu w Email Security (chwilowy brak źródła reputacji IP).
• Łańcuch dostaw (third-party risk): pojedyncza zmiana u dostawcy edge/CDN wpływa na dziesiątki krytycznych usług — konieczne plany obejścia i redundancja dostawców.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SRE/Architektów:

1. Redundancja na warstwie CDN/edge: projektuj polityki active-active lub graceful degradation (np. fallback DNS → origin / alternatywny CDN) dla kluczowych ścieżek (auth, płatności, API).
2. Feature-flag kill switch: lokalne przełączniki wyłączające zależne moduły (np. scoring botów) bez restartu całego proxy/aplikacji. Cloudflare zapowiedział poszerzenie globalnych „kill switches” — odzwierciedl to po stronie klienta.
3. Walidacja „wewnętrznych” artefaktów konfiguracyjnych jak danych użytkownika: schemy, limity rozmiaru/rekordów, detekcja duplikatów, testy kontraktowe (CI/CD) dla plików konfig generowanych automatycznie.
4. Observability budżetowane: zabezpiecz systemy debugowania przed „zajadaniem CPU” przy masowych błędach (rate-limit na trace/log/error-reports).
5. Runbooki fail-open/fail-closed: jasno zdefiniuj tryby awaryjne dla modułów bezpieczeństwa (antybot/WAF) i konsekwencje biznesowe obu trybów.

Dla SecOps:

1. Polityki antybotowe oparte na wielu sygnałach, nie tylko globalnym „bot score”.
2. Monitorowanie skutków ubocznych (np. gwałtowny wzrost odrzuceń/akceptacji sesji) i gotowe reguły tymczasowe na czas degradacji dostawcy.
3. Komunikacja kryzysowa: zespół IR/PR + strona statusowa off-platform (poza dostawcą, z wieloma regionami i DNS-em niezależnym). Przykład problemów z dostępem do statuspage to lekcja o separacji zależności.

Dla devów aplikacyjnych:

• Circuit breakers & timeouts na wywołaniach do usług edge.
• Backpressure i retry-policy z jitterem (zapobiega lawinie po powrocie ruchu).
• Tryb „read-only / degraded UI” zamiast pełnego 5xx dla krytycznych ścieżek.

Różnice / porównania z innymi przypadkami

• W przeciwieństwie do typowych outage’y spowodowanych DDoS lub błędami sieciowymi, tu mieliśmy błąd w danych konfiguracyjnych + granice (limits) w module proxy, co ujawniło brak „twardych” walidacji dla artefaktów wewnętrznie generowanych (nie tylko dostarczanych przez klientów).
• Od strony objawów incydent przypominał masowe ataki L7 (skok 5xx i fluktuacje), co utrudniło triage. Jednak root cause nie był security-atakiem, lecz regresją po zmianie uprawnień w ClickHouse.

Podsumowanie / kluczowe wnioski

• „Trust but verify” dla własnych artefaktów konfiguracyjnych: walidacja, limity, schemy, canary rollout i globalne kill-switche.
• Projektuj na awarie dostawcy edge: niezależna strona statusowa, multi-CDN, szybkie ścieżki bypass.
• Observability z ograniczeniami: mechanizmy, które pomagają w diagnozie, nie mogą „zjadać” zasobów podczas katastrofy.
• Ćwicz tryby degradacji: fail-open/fail-closed dla komponentów bezpieczeństwa i jasne runbooki.

Źródła / bibliografia

• Szczegółowy post-mortem Cloudflare z osi czasu, technikaliami (ClickHouse, limit cech, FL/FL2): Cloudflare Blog — “Cloudflare outage on November 18, 2025”. (The Cloudflare Blog)
• Relacja i wpływ na największe serwisy: Financial Times, Washington Post, The Verge, Reuters. (Financial Times)
• Historia i status incydentów Cloudflare: Cloudflare Status / Incident History. (cloudflarestatus.com)