Sectum Blog

Cloudflare Leży: Dlaczego połowa internetu zniknęła 18 listopada? (Analiza Techniczna)

19 listopada, 2025

|

4 min czytania

Facebook
LinkedIn

18 listopada 2025 roku internet wstrzymał oddech. Jeśli tego dnia próbowałeś wejść na swoje ulubione serwisy i witały Cię błędy 502 lub „Cloudflare Error”, nie byłeś sam. To była największa awaria giganta CDN od 2019 roku.

Sectum Blog

Pierwsza myśl każdego admina? „To musi być gigantyczny atak DDoS”. Skala problemu była tak duża, że nawet inżynierowie Cloudflare początkowo podejrzewali atak wrogich grup. Prawda okazała się jednak zupełnie inna – i znacznie bardziej pouczająca dla każdego, kto zarządza infrastrukturą IT.

Oto anatomia katastrofy, która wydarzyła się 18 listopada.

To nie był cyberatak

Zacznijmy od najważniejszego: awaria nie została wywołana przez hakerów. Nie był to atak DDoS, ransomware ani sabotaż.

Przyczyną globalnego paraliżu była jedna zmiana w uprawnieniach bazy danych.

Techniczne „Mięso”: Co dokładnie się stało?

Cloudflare używa systemu do zarządzania botami (Bot Management), który ocenia, czy ruch na stronie jest „ludzki”. System ten opiera się na pliku konfiguracyjnym (tzw. feature file), który jest regularnie wysyłany do wszystkich serwerów w ich sieci.

O godzinie 11:05 UTC inżynierowie wprowadzili zmianę w uprawnieniach na klastrze bazy danych ClickHouse. Celem była poprawa bezpieczeństwa i zarządzania dostępem. Niestety, zmiana ta miała niezamierzony skutek uboczny.

  1. Błąd w zapytaniu: Nowe uprawnienia sprawiły, że zapytanie generujące plik konfiguracyjny zaczęło zwracać zduplikowane wiersze.
  2. Rozmiar pliku: W efekcie plik feature file, który normalnie ma stały, przewidywalny rozmiar, nagle urósł dwukrotnie.
  3. Propagacja: Ten „nadmuchany” plik został automatycznie rozesłany do tysięcy serwerów (proxy) Cloudflare na całym świecie.

Dlaczego serwery „spanikowały”?

Oprogramowanie proxy Cloudflare (napisane w języku Rust) miało zaszyty w kodzie sztywny limit wielkości tego pliku (memory allocation limit). Była to optymalizacja wydajnościowa – system rezerwował z góry określoną ilość pamięci.

Gdy serwery otrzymały plik przekraczający ten limit, kod nie był w stanie go obsłużyć. W języku Rust, w przypadku krytycznego błędu pamięci, następuje tzw. panic. Proces obsługujący ruch sieciowy po prostu „umarł”.

Komunikat błędu wyglądał tak: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Efekt? Serwery przestały procesować ruch HTTP/HTTPS. Zamiast stron www, użytkownicy widzieli błędy 5xx.

Timeline Awarii

  • 11:05 UTC: Wdrożenie zmiany w bazie ClickHouse.
  • 11:20 UTC: Poczatek problemów. Ruch sieciowy zaczyna drastycznie spadać, pojawiają się błędy 5xx.
  • 11:35 UTC: Cloudflare ogłasza incydent. Początkowo podejrzewają atak DDoS.
  • 13:05 UTC: Inżynierowie identyfikują problem i wyłączają wadliwy system Bot Management.
  • 14:30 UTC: Główny ruch wraca do normy po ręcznym wgraniu poprawnego pliku konfiguracyjnego.
  • 17:06 UTC: Pełne przywrócenie wszystkich usług.
Sectum Blog

Lekcja dla nas

Ta awaria to doskonałe przypomnienie o „efekcie motyla” w IT. Jedna, z pozoru rutynowa zmiana w uprawnieniach bazy danych, doprowadziła do kaskadowej awarii globalnej infrastruktury.

Wnioski dla Twojej firmy:

  1. Walidacja danych wejściowych: Nawet wewnętrzne pliki konfiguracyjne powinny być walidowane przed użyciem. Gdyby system sprawdził rozmiar pliku przed próbą jego załadowania, awarii można by uniknąć.
  2. Stopniowe wdrażanie (Canary Deployments): Zmiany globalne powinny być wdrażane falami. Tutaj wadliwy plik trafił wszędzie niemal jednocześnie.
  3. Obsługa błędów: „Hard fail” (panic) w systemie krytycznym to ostateczność. Systemy powinny być projektowane tak, by w przypadku błędu konfiguracji cofały się do ostatniej znanej dobrej wersji (last known good configuration), zamiast przestawać działać.

Cloudflare przeprosiło i opublikowało szczegółowy raport. To lekcja pokory dla każdego administratora i programisty.

Bezpieczeństwo to proces, a nie produkt

Analiza przypadku Cloudflare pokazuje, jak skomplikowane zależności rządzą nowoczesnym IT. Błąd w jednym pliku konfiguracyjnym położył globalną sieć. W mniejszej skali – w Twojej firmie – podobny błąd konfiguracji routera czy serwera może otworzyć drzwi hakerom lub zatrzymać sprzedaż na wiele godzin.

Nie musisz znać się na bazach ClickHouse ani języku Rust, żeby spać spokojnie. Od tego masz nas.

🛠️ Martwisz się o stabilność swojej infrastruktury? [Skontaktuj się z nami] i umów na niezobowiązującą rozmowę o bezpieczeństwie Twojej firmy.

Wybierz rozdział:

Udostępnij dalej:

Facebook
LinkedIn

Procent ukończenia czytania:

Przeglądaj nasze inne wpisy:

Awaria oraz Błąd 502 oraz Cloudflare
Sectum Blog

Cloudflare Leży: Dlaczego połowa internetu zniknęła 18 listopada? (Analiza Techniczna)

19 lis 2025
|

4 min czytania

fortinet oraz luki bezpieczeństwa
Sectum | Raport Fortinet

Fortinet pod ostrzałem: Krytyczne luki w FortiWeb i kontrowersyjne „ciche łatanie”

22 lis 2025
|

4 min czytania

Antywirus oraz Podejrzany załącznik oraz VirusTotal
VirusTotal | Sectum

Podejrzany załącznik w mailu? Nie otwieraj go! Zobacz, jak bezpiecznie sprawdzić plik (Darmowy sposób)

24 lis 2025
|

4 min czytania