HTTP flood

HTTP flood to atak DDoS w warstwie aplikacji (L7), w którym wiele maszyn wysyła do serwera ogromną liczbę żądań HTTP, aby wyczerpać jego zasoby. MITRE ATT&CK opisuje go jako technikę wyczerpania usługi: duża liczba żądań HTTP ma przeciążyć serwer WWW samą skalą ^[1]. Od zalewania pakietami w warstwie sieciowej różni się tym, że każde żądanie jest poprawne. Dokumentacja Microsoft podkreśla, że ataki w warstwie aplikacji są tanie w uruchomieniu i trudne do odróżnienia od prawdziwego ruchu, bo dopiero łączna szybkość, rozkład i skład klientów zdradzają atak ^[2].

Jak działa

Atakujący steruje zwykle botnetem, czyli siecią przejętych komputerów, serwerów albo urządzeń. Każdy bot wysyła żądania GET lub POST pod adres strony. Pojedyncze żądanie niczym się nie wyróżnia; problemem jest ich suma. Serwer musi dla każdego uruchomić obsługę, połączyć się z bazą, zbudować odpowiedź. Gdy zabraknie wątków roboczych, procesora albo pamięci, prawdziwi użytkownicy czekają lub dostają błąd.

MITRE jako sygnały wykrycia wymienia powtarzalne żądania z jednego albo małej grupy adresów IP, które wyczerpują procesor lub pamięć, nadmiar przychodzących połączeń HTTP i TLS prowadzący do wyczerpania wątków roboczych oraz zalewanie z instancji chmurowych ^[1].

RYS. 1Droga żądania w HTTP flood

Odmiany

HTTP flood jest jedną z odmian szerszej kategorii ataków odmowy usługi. Tabela zestawia go z pokrewnymi technikami.

Ataki L7 bywają łączone z wolumetrycznymi. Microsoft zwraca uwagę, że nawet dobrze dostrojone reguły zapory aplikacyjnej zostaną ominięte, jeśli publiczny adres IP nie jest chroniony przed atakiem wolumetrycznym L3/L4 ^[2].

W WordPressie

WordPress domyślnie generuje strony dynamicznie, więc każde żądanie, które nie trafi w pamięć podręczną, uruchamia PHP i zapytania do bazy. Dlatego szczególnie wrażliwe są adresy, których nie da się łatwo zbuforować: wyniki wyszukiwarki z parametrem ?s=, koszyk i kasa WooCommerce, strona logowania wp-login.php oraz XML-RPC. Ten sam ruch, który na statycznej stronie byłby obsłużony z pliku, na WordPressie angażuje cały stos aplikacji.

Dokumentacja WordPressa nazywa buforowanie najszybszym sposobem poprawy wydajności. Wtyczki takie jak W3 Total Cache, WP Super Cache czy Cache Enabler zapisują wpisy i strony jako pliki statyczne, co przy stronach o mało zmiennej treści może poprawić wydajność kilkusetkrotnie ^[5]. Bufor strony nie chroni jednak przed zalewaniem adresów dynamicznych, a atakujący może omijać go, doklejając do adresu losowe parametry.

Na hostingu współdzielonym HTTP flood wymierzony w jedną stronę obciąża serwer dzielony z innymi witrynami, więc jego skutki nie muszą ograniczać się do jednej strony.

Zagrożenia i skutki

• Niedostępność strony dla klientów, a w sklepie utracona sprzedaż.
• Przekroczenie limitów zasobów hostingu i koszty dodatkowej mocy w chmurze.
• Zaśmiecenie logów, w którym łatwiej ukryć równoległe próby ataku siłowego albo skanowania.
• Obciążenie bazy danych, które może wydłużyć czas odpowiedzi także po zakończeniu ataku.

Jak się bronić

Obrona przed HTTP flood jest warstwowa i powinna być skonfigurowana przed atakiem. Microsoft zaleca kolejno: ochronę wolumetryczną na poziomie platformy, automatyczne łagodzenie uczące się typowego ruchu, weryfikację klienta, ograniczanie szybkości, reguły celowane i ochronę serwera źródłowego ^[2].

Kilka zasad praktycznych:

• Próg ograniczenia Microsoft radzi ustawić powyżej 99. percentyla ruchu z normalnych warunków, a nie na wartości maksymalnej, bo maksimum zwykle tworzy robot indeksujący albo źle skonfigurowany klient ^[2].
• Wyzwanie zamiast blokady tam, gdzie ruch jest mieszany; CAPTCHA warto zarezerwować dla logowania, rejestracji i finalizacji zakupu ^[2].
• Odpowiedź 429. Serwer, który ogranicza liczbę żądań, może odpowiadać kodem 429 Too Many Requests, opcjonalnie z nagłówkiem Retry-After; takich odpowiedzi nie wolno buforować ^[4].
• Serwer źródłowy powinien przyjmować ruch wyłącznie od usługi ochronnej, bo chroniony front przed publicznie dostępnym źródłem nie daje ochrony ^[2].

HTTP/1.1 429 Too Many Requests
Retry-After: 3600

Historia i przykłady

HTTP flood to stały element oprogramowania botnetów. CERT Polska w analizie z 19 października 2017 roku opisał modułowe złośliwe oprogramowanie Tofsee, które poza rozsyłaniem poczty, kopaniem kryptowalut i kradzieżą danych miało moduł DDoS ^[3]. Moduł implementował zalewanie żądaniami, opisane jako „request spamming (HTTP Flood)”, oraz klasyczny SYN flood ^[3]. Badacze nie zaobserwowali jednak faktycznych ataków DDoS z tej sieci, co sugeruje, że operator nie korzystał z tej funkcji ^[3].