To nie był atak na Cloudflare: Jak wadliwy plik konfiguracyjny sparaliżował część internetu
We wtorek wielu użytkowników mogło zobaczyć słynny błąd 500 Cloudflare podczas surfowania po sieci. Między 11:30 a 14:30 UTC niezliczone strony i usługi były nieosiągalne. Wśród nich były Ikea, PayPal, ChatGPT, X (dawniej Twitter) i inne. Problem dotyczył również Notebookcheck.
Cloudflare oferuje różne usługi dla operatorów stron internetowych
Mówiąc o największych graczach w Internecie, Amazon, Google, Microsoft i Meta (Facebook) są zwykle wymieniane jako pierwsze. Jeśli coś pójdzie nie tak z nimi, duża część Internetu przestaje funkcjonować. Cloudflare, który działa głównie w celu ochrony stron internetowych przed atakami i przyspieszenia ich działania, jest najczęściej pomijany. Wiele stron internetowych i usług polega na usługach Cloudflare, aby skrócić czas ładowania i chronić swoje serwery.
Buforując dane ze stron internetowych i usług oraz działając jako proxy, Cloudflare pomaga w płynniejszym połączeniu między klientami a serwerami. Ponadto Cloudflare filtruje złośliwe żądania i zapewnia przechwytywanie skoków obciążenia. Jest on prawdopodobnie najbardziej znany ze swojej ochrony przed atakami DDoS. Dla operatorów stron internetowych optymalizacja czasu ładowania poprzez buforowanie stron na różnych serwerach na całym świecie jest często najważniejszym aspektem. Wiele stron internetowych polega na usługach Cloudflare, aby odciążyć własne serwery i jednocześnie zmniejszyć opóźnienia odwiedzających.
18 listopada doszło do rozległej awarii w Cloudflare
We wtorek poważny błąd dotknął sieć Cloudflare, powodując niedostępność stron internetowych i usług jej klientów. W poście na blogu https://blog.cloudflare.com/18-november-2025-outage/matthew Prince, dyrektor generalny Cloudflare, szczegółowo opisał wydarzenia prowadzące do największej awarii sieci Cloudflare od 2019 roku.
Około godziny 11:30 czasu UTC niezwykle wysoka liczba kodów błędów 5xx zaczęła zalewać Cloudflare z powodu błędu konfiguracji. Liczba błędów wahała się jednak znacząco do godziny 13:00 UTC, co początkowo doprowadziło Cloudflare do przekonania, że ma do czynienia z atakiem zewnętrznym. Założenie to zostało dodatkowo poparte faktem, że strona statusu samego Cloudflare stała się w tym czasie niedostępna. Po pewnym czasie wskaźnik błędów powrócił do oczekiwanego niskiego poziomu w ich sieci. Wcześniejsze dyskusje na wewnętrznych czatach spekulowały, że za awarię odpowiedzialny jest botnet.
Rzeczywisty problem powstał w sieci Cloudflare. Zmiana uprawnień w systemie bazodanowym doprowadziła do różnych błędów. Zostało to wprowadzone już około godziny 11:05 UTC. W rezultacie rozmiar pliku funkcji z systemu zarządzania botami został sztucznie zawyżony i prawie podwoił swój pierwotny rozmiar. Programy Cloudflare mają jednak ustalony rozmiar tego pliku, który jest również zarezerwowany w pamięci. Ponadwymiarowe pliki przepełniły zarezerwowaną pamięć, powodując awarię systemu. Ponieważ plik funkcji był aktualizowany co pięć minut i nie wszystkie klastry Cloudflare działały w nowej konfiguracji, stało się możliwe, że w pełni działający lub niedziałający plik mógł być dystrybuowany w sieci w dowolnym momencie. Wyjaśnia to wahania częstotliwości występowania błędów. Około godziny 13:37 zespół reagowania na incydenty Cloudflare zdał sobie sprawę, że przyczyną awarii były zmiany w systemie zarządzania botami. Godzinę później udało im się w końcu rozwiązać problem.
Auswirkungen des Cloudflare-Ausfalls zeigen deutlich die fragwürdige Abhängigkeit des Internets von wenigen Akteuren. Ein einziger Konfigurationsfehler an einem zentralen Schlüsselpunkt hat hier ausgereicht, dass unzählige Webseiten und Services nicht mehr erreichbar waren. W związku z tym pojawia się pytanie, jak bardzo Internet, tak jak wiemy, jest dobry.
