Wczoraj, 18 listopada, miała miejsce globalna i długotrwała – w stosunku do skali usługi – awaria Cloudflare. Nikomu chyba nie trzeba od podstaw tłumaczyć, jakie jest możliwe użycie Cloudflare. To bardzo popularna, szczególnie wśród osób odpowiadających za bezpieczeństwo czy administrację IT, usługa umożliwiająca m.in. ochronę WAF, konfigurację SSL czy obsługę DNS domen. Jest w zasadzie standardowym rozwiązaniem, często rekomendowanym jako metoda na szybkie i niejednokrotnie w pełni bezpłatne, ale jednocześnie całkiem skuteczne zabezpieczenie ruchu do naszych serwisów.
Cloudflare obsługuje ogromną część ruchu internetowego, bo ponad 20%. Co więcej, zastosowanie Cloudflare nie jest ograniczone jedynie do największych serwisów, bo również mniejsze portale czy specyficzne narzędzia z powodzeniem korzystają z tej usługi. Pewnie dla większości osób pierwszym „objawem” problemów z działaniem Cloudflare były błędy w znanych serwisach, m.in. X. Również AVLab.pl pozostał niedostępny przez cały czas trwania awarii. A jeżeli ktoś chciał upewnić się, iż problem jest globalny, to nie mógł tego zrobić w znany sposób, ponieważ serwis Downdetector także został objęty zasięgiem awarii (nie działała obsługa CAPTCHA dostarczanego przez Cloudflare, więc adekwatna strona nie ładowała się). Próby pobrania zawartości różnych witryn kończyły się analogicznymi do poniższego komunikatami.
Pełne przywrócenie działania zajęło prawie 8 godzin, co widać w szczegółach incydentu. Przyczyną była błędna zmiana w uprawnieniach bazy danych powodująca nienormatywny (dwa razy większy) rozmiar „feature file” używanego z kolei przez system Bot Management. Plik został rozpropagowany w całej sieci Cloudflare, a próba jego odczytu skutkowała błędem w działaniu systemu – prawdopodobnie jego „wysypaniem”. W ten sposób sieć Cloudflare przestała funkcjonować. Mocno polecam zapoznać się z pełną analizą awarii zamieszczoną na blogu firmy.
Sporo osób zwraca uwagę na kiepskie praktyki programistyczne wdrożone przez Cloudflare w kodzie Rust. Mowa o funkcji unwrap, która zdaniem niektórych (odpowiedzi pod tym wątkiem) nie powinna znajdować się w środowisku produkcyjnym.
Tak długa przerwa w działaniu systemów – tym bardziej niezależna od osób zajmujących się ich utrzymaniem – jest po prostu problematyczna. „Hype” na Cloudflare od dawna był spory, więc nikogo nie zaskakuje, iż wpływ awarii objął wiele kluczowych środowisk, w największej mierze serwerów WWW. Cloudflare stanowi zabezpieczenie przed „odkryciem” prawdziwych adresów IP usług. Oznacza to, iż w DNS domena wskazuje na adresy IP zarządzane przez Cloudflare (dla avlab.pl są to 104.21.4.203 i 172.67.132.108 oraz dwa adresy IPv6) i dopiero reverse proxy Cloudflare przekierowuje i filtruje ruch do adekwatnych serwerów HTTP hostujących dane serwisy – zewnętrzna osoba nie pozna realnych adresów IP, zakładając, iż nie popełniono oczywistych błędów (przykładowo domena główna wskazuje na Cloudflare, ale subdomeny już na docelowy serwer).
Nie każdy mógł przeprowadzić szybką mitygację (usunięcie/ograniczenie skutków problemu). Dobrym podejściem wydawała się tymczasowa zmiana rekordów w DNS, aby wskazywały one na faktycznie zarządzane przez dostawcę serwery. jeżeli jednak obsługa DNS także była zarządzana z poziomu Cloudflare (strefa wskazywała na tę usługę, np. fred.ns.cloudflare.com), to nie było takiej możliwości, bo panel nie działał. Nie można zapomnieć o HTTPS – jeżeli obsługa SSL była wyłącznie po stronie Cloudflare, to nie w każdych okolicznościach była opcja sprawnej podmiany certyfikatu czy w ogóle wystawienia szyfrowanej wersji naszej usługi.
Jakakolwiek pełna zależność od pojedynczego dostawcy jest ryzykowna w wielu kontekstach. Cloudflare stanowi tzw. SPOF dla wielu usług, choćby jeżeli te „lokalnie” są zbudowane przy zastosowaniu podejścia high availibility. Powszechna jest opinia, iż ryzyko awarii data center Cloudflare jest mniejsze niż awarii serwerowni w biurze. To w wielu przypadkach prawda, natomiast nie zmienia faktu, iż przydane są plany pozwalające na sprawne przełączenie naszej usługi, aby w razie rozległej awarii można było zapewnić jej funkcjonowanie, choćby w ograniczonym zakresie.
Nie zawsze jest konieczność stosowania tak rozbudowanych systemów jak Cloudflare. Sama konfiguracja obsługi domeny przez Cloudflare z reguły nie stanowi skomplikowanego procesu, natomiast za każdym razem warto przypomnieć, iż realne korzyści tego podejścia widoczne są w głównej mierze dla naprawdę złożonych serwisów internetowych charakteryzujących się dużym obciążeniem – chociaż i tak Cloudflare w żadnym wypadku nie jest przysłowiowym „lekarstwem na wszystko”.
Jeśli zależy nam wyłącznie na ochronie aplikacji, to może sprawdzić się dowolne rozwiązanie self-hosted WAF, takie jak SafeLine. Po więcej informacji odsyłam do mojego artykułu.
Otrzymaliśmy również słuszne komentarze dwóch specjalistów z Check Point i ESET, które publikujemy poniżej.
Kiedy platforma tej skali się potyka, skutki rozchodzą się błyskawicznie, szeroko i wszyscy odczuwają je jednocześnie. To nie jest seria pojedynczych awarii po stronie organizacji, ale problem z jedną warstwą, z której wszyscy korzystają. Każda platforma, która przenosi tak dużą część światowego ruchu, staje się naturalnym celem. choćby niezamierzona awaria generuje niepewność, którą atakujący potrafią wykorzystać. Gdyby incydent tej skali został wywołany celowo, zakłócenia dotknęłyby państw, które opierają na takich platformach komunikację z obywatelami i świadczenie podstawowych usług. Wiele organizacji wciąż prowadzi cały ruch jedną trasą, bez realnego planu awaryjnego. Gdy ta trasa zawodzi, nie ma dokąd przełączyć usług. To powtarzająca się słabość, którą ciągle obserwujemy. Duże platformy przynoszą realne korzyści, ale takie wydarzenia pokazują cenę tej decyzji. Dopóki nie zbudujemy prawdziwej różnorodności i nadmiarowości w infrastrukturze, każda kolejna awaria będzie uderzać w użytkowników mocniej, niż powinna.
Awarie, których byliśmy świadkami w ostatnich miesiącach, po raz kolejny potwierdziły naszą zależność od sieci i usług cyfrowych. Firmy często zmuszone są w znacznym stopniu polegać i opierać swój biznes na rozwiązaniach takich gigantów technologicznych, jak Cloudflare czy Microsoft w zakresie hostingu swoich stron internetowych i usług, ponieważ na rynku brakuje alternatyw. Problemy powodujące awarię Cloudflare wynikały z błędów systemu DNS (Domain Name System), który najprawdopodobniej uległ przeciążeniu. Technologia ta opiera się na przestarzałej infrastrukturze, która tłumaczy słowa zawarte w adresach internetowych na ciągi cyfr odczytywane przez komputery. Gdy ten system zawodzi, dochodzi do katastrofalnego załamania, co skutkuje globalnymi awariami. Problem jednak w tym, iż tego systemu nie da się łatwo zastąpić. Główni dostawcy usług w chmurze dysponują wieloma zabezpieczeniami i systemami awaryjnymi i zwykle zapewniają lepszą ochronę niż mniej znani dostawcy, choć jak widzimy również zawodzą.
