atak odmowy usługi

Atak odmowy usługi (denial of service, DoS) to działanie, przez które uprawnieni użytkownicy nie mogą korzystać z systemu, urządzenia albo zasobu sieciowego ^[1]. Atak nie musi niczego wykradać ani niszczyć. Sekurak podkreśla, że ataki z tej rodziny nie uszkadzają danych, tylko utrudniają albo uniemożliwiają dostęp do nich ^[4]. OWASP łączy je wprost z dostępnością, jednym z trzech filarów bezpieczeństwa informacji obok poufności i integralności ^[3]. Gdy atak prowadzi wiele maszyn naraz, mówi się o DDoS ^[1].

Jak działa

Każdy serwer ma skończone zasoby: pamięć, czas procesora, gniazda, deskryptory plików, połączenia z bazą danych i miejsce na dysku ^[2]. MITRE opisuje słabość CWE-400 jako brak kontroli nad przydzielaniem i utrzymywaniem ograniczonego zasobu ^[2]. Jeśli atakujący może zmusić aplikację do zajmowania zasobów bez limitu, skutkiem jest zwykle odmowa usługi dla pozostałych użytkowników, spowolnienie albo awaria ^[2].

Atak odmowy usługi może więc polegać na zalaniu celu ruchem albo na znalezieniu jednego żądania, które kosztuje serwer dużo pracy. Druga droga wymaga niewiele ruchu i często wystarcza jej jeden komputer.

RYS. 1Wyczerpanie zasobów serwera

Rodzaje

OWASP dzieli ataki odmowy usługi na trzy warstwy ^[3].

Powolne połączenia. Slowloris otwiera wiele połączeń i co pewien czas dosyła po jednym nagłówku, nie kończąc żądania; domyślnie co 100 sekund ^[5]. Serwer trzyma dla każdego połączenia proces albo wątek, aż zabraknie wolnych ^[5]. Według Sekuraka podatne były serwery Apache 1.x i 2.x, a nginx, lighttpd i IIS były odporne na klasyczną wersję tego ataku ^[5]. Narzędzie opublikował w 2009 roku badacz RSnake, choć na tę klasę problemów Michał Zalewski zwracał uwagę już w 2007 roku ^[5]. Atak zużywa mało pasma: według Sekuraka do sparaliżowania serwera wystarcza kilka tysięcy żądań GET, a więc jedna maszyna ^[5]. Nie potrzeba do tego botnetu, a ruch trudno odróżnić od wolnych, ale prawdziwych klientów.

Błędy w oprogramowaniu. Czasem wystarczy podatność, która powoduje awarię usługi albo nieproporcjonalne zużycie zasobów po jednym żądaniu. Taka podatność dostaje własny identyfikator CVE, jak w przykładzie z WordPressa niżej.

W WordPressie

WordPress generuje strony dynamicznie w PHP, więc każde żądanie, którego nie obsłuży pamięć podręczna, zajmuje proces PHP i połączenie z bazą. To czyni go wrażliwym na ataki warstwy aplikacji.

CVE-2018-6389. 5 lutego 2018 roku badacz Barak Tawily opisał atak na pliki load-scripts.php i load-styles.php ^[6]. Parametr load[] przyjmuje listę skryptów lub arkuszy do połączenia w jedną odpowiedź. Powtarzane żądania z bardzo długą listą, obejmującą 181 plików JavaScript, zmuszają serwer do przetwarzania dużej ilości danych, aż przestaje odpowiadać ^[6]. Według Impervy zespół WordPressa nie wydał poprawki, uznając to za atak na wyczerpanie zasobów, który należy powstrzymywać na poziomie sieci albo zapory aplikacyjnej ^[6]. Imperva zaleciła ograniczenie dostępu do tych plików do zaufanych adresów IP i limity liczby żądań ^[6].

Logowanie i XML-RPC. Dokumentacja WordPressa ostrzega, że nawet nieudany atak siłowy może zalać stronę żądaniami ^[7]. Częstym celem jest XML-RPC, zwłaszcza metoda system.multicall ^[7]. Wtyczki zabezpieczające działają w PHP, więc pod dużym obciążeniem same zużywają zasoby ^[7]. Na hostingu współdzielonym przeciążenie jednej strony może dotknąć sąsiednie.

Zagrożenia i skutki

• Niedostępność strony dla klientów i utrata sprzedaży w sklepie.
• Błędy przekroczenia czasu i przeciążenie bazy, które utrudniają też pracę w panelu.
• Obniżenie bezpieczeństwa. MITRE zauważa, że przy wyczerpaniu zasobów niektóre produkty przechodzą w stan otwarty i przestają egzekwować mechanizmy ochronne ^[2].

Jak się bronić

MITRE zaleca projektować mechanizmy dławienia ruchu, śledzić liczbę żądań od użytkowników i blokować te powyżej ustalonego progu, a także zapewnić, że każda nieudana alokacja zasobu zostawia system w bezpiecznym stanie ^[2]. To w praktyce rate limiting. MITRE wymienia też silne uwierzytelnianie i kontrolę dostępu, bo ograniczają krąg osób zdolnych wywołać kosztowne operacje, oraz buforowanie wyników zapytań, które zmniejsza obciążenie bazy ^[2]. OWASP zaczyna od analizy środowiska: bez dobrego zrozumienia własnej infrastruktury trudno dobrać właściwe mechanizmy obrony ^[3]. Zaleca też redundancję, unikanie pojedynczych punktów awarii i stosowanie komponentów bezstanowych ^[3].

OWASP dodaje zasady dla aplikacji i infrastruktury ^[3]:

• łagodną degradację, czyli zachowanie części funkcji pod obciążeniem ^[3];
• unikanie operacji mocno obciążających procesor i solidną obsługę wyjątków ^[3];
• limity rozmiaru żądań, przesyłanych plików i danych sesji ^[3];
• pamięć podręczną i limity czasu połączeń ^[3].

Na serwerze Apache przed powolnymi połączeniami chroni moduł mod_reqtimeout, który zamyka niedokończone żądania ^[5]. Dla WordPressa dokumentacja zaleca ograniczanie żądań do logowania i XML-RPC w serwerze WWW, a najlepiej na brzegu sieci lub w WAF-ie, bo wtedy ruch nie zużywa zasobów serwera ^[7]. Statyczne zasoby warto serwować przez CDN. CISA radzi też, by przy podejrzeniu ataku najpierw ustalić z administratorem i dostawcą internetu, czy przerwa to atak, czy awaria lub prace serwisowe ^[1].