DDoS Stress: stress testy I symulacje ataków DdoS

DDoS stress, czyli stress testy i symulacje ataków DDoS, to kontrolowane przeciążanie własnej infrastruktury sieciowej za pomocą sztucznie wygenerowanego ruchu, aby sprawdzić skuteczność wdrożonych systemów obronnych. Administratorzy zlecają te testy, żeby zidentyfikować wąskie gardła w przepustowości serwerów i zweryfikować, czy dostawca usług mitygacji faktycznie filtruje złośliwe pakiety zgodnie z podpisaną umową SLA.

Zajmuję się sieciami od kilkunastu lat. Pamiętam wdrożenie u dużego klienta e-commerce tuż przed sezonem wyprzedaży. Odpaliliśmy testowy atak wolumetryczny o sile ledwie 20 Gbps. Cały routing padł w czternaście sekund. A dostawca chmury zapewniał nas wcześniej, że wytrzymają pięć razy tyle. Testowanie infrastruktury na sucho to absolutna podstawa. Inaczej kupujesz kota w worku. Większość firm zakłada, że skoro płacą za zaporę WAF i usługę anty-DDoS, to są bezpieczni. To bzdura. Zwykły, źle skonfigurowany limit połączeń na load balancerze potrafi położyć sieć szybciej niż sam botnet.

Co to jest DDoS Stress i dlaczego firmy wykonują symulacje ataków?

Symulacja ataku DDoS to kontrolowany pożar. Wynajmujesz zewnętrzną firmę lub używasz specjalistycznego oprogramowania, żeby uderzyć we własne serwery gigabajtami śmieciowych danych. Celem jest sprawdzenie, w którym momencie systemy przestaną odpowiadać. Prawda jest zresztą absolutnie taka, że każda sieć ma swój punkt krytyczny. Ty musisz tylko wiedzieć, gdzie on dokładnie leży.

Firmy robią to z prostego powodu. Chcą uniknąć strat finansowych. Kiedy prawdziwy atak odetnie sklep internetowy na cztery godziny w środku dnia, straty liczy się w setkach tysięcy złotych. Stress testy DDoS pozwalają przetestować procedury reagowania na incydenty przez zespół Security Operations Center (SOC). Oprogramowanie maszynowe często zakłada, że alarmy włączą się od razu. W praktyce systemy monitoringu potrafią milczeć przez pierwsze pięć minut ataku, bo same są zapchane ruchem z botnetu.

Mamy tu do czynienia z twardą weryfikacją obietnic. Dostawcy łącz internetowych sprzedają pakiety z ochroną, ale rzadko precyzują, jak szybko ich filtry, tak zwane scrubbing centers, przejmą brudny ruch. Symulacja wymusza ten proces sztucznie. Wtedy widzisz, czy przepięcie ruchu przez protokół BGP zajmuje minutę, czy kwadrans. To gigantyczna różnica w biznesie.

Jak legalnie przeprowadzić stress test DDoS na własnej infrastrukturze?

Najgorsza opcja to odpalenie testu bez powiadomienia kogokolwiek. Wielu początkujących administratorów instaluje narzędzia do generowania ruchu na kilku serwerach VPS i kieruje pakiety na własną domenę. Efekt? Operator telekomunikacyjny odcina im dostęp do sieci w ramach ochrony własnej infrastruktury szkieletowej. ISP nie wie, że to test. Widzi anomalię i nakłada tak zwany null routing.

Legalne testy obciążeniowe wymagają papierologii. Zaczynamy od uzyskania pisemnej zgody zarządu. Potem informujemy dostawcę hostingu, operatora centrum danych oraz firmę dostarczającą usługę anty-DDoS. Podajemy im dokładne okno czasowe. Na przykład od 2:00 do 4:00 w nocy z soboty na niedzielę. Przekazujemy im też źródłowe adresy IP, z których nastąpi uderzenie. Dzięki temu ich inżynierowie mogą obserwować zachowanie sieci z pierwszego rzędu, zamiast panikować.

Jakie narzędzia służą do symulacji ataków wolumetrycznych i aplikacyjnych?

Rynek profesjonalnych usług red teamingowych używa mocno wyspecjalizowanych skryptów. Nie korzysta się tu z amatorskich zabawek. Potrzebujesz wygenerować realny ruch z wielu różnych lokalizacji geograficznych, żeby naśladować rozproszony botnet.

• Komercyjne platformy do testów obciążeniowych. Mają własne klastry w chmurach AWS czy Azure. Pozwalają precyzyjnie kontrolować liczbę pakietów na sekundę (PPS) i przepustowość w gigabitach (Gbps). Są drogie, ale oferują pełne raportowanie post-factum.
• Skrypty typu Hping3 i zindywidualizowane pakiety Pythona. Używane do punktowego uderzania w specyficzne usługi. Pozwalają preparować flagi TCP, żeby badać reakcję systemów IDS.
• Narzędzia open-source do testowania warstwy aplikacji. Generują tysiące zapytań HTTP GET z rotacją nagłówków User-Agent i adresów IP przez proxy. Pozwalają sprawdzić, czy WAF prawidłowo rozpoznaje zachowanie maszynowe.

Kto odpowiada za testy obciążeniowe w zespole IT?

Zlecenie zawsze wychodzi od dyrektora do spraw bezpieczeństwa (CISO) lub szefa IT. Wykonawcą powinna być jednak zewnętrzna firma audytorska. To eliminuje konflikt interesów. Wewnętrzny zespół sieciowy przygotowywał tę infrastrukturę, więc podświadomie będzie unikał testowania jej słabych punktów. Zewnętrzny audytor wchodzi po to, by tę sieć zepsuć. Maciej, nasz główny inżynier od zabezpieczeń, zawsze na spotkaniach powtarza: “Jak sami sobie robimy testy, to zawsze wychodzą zielone paski na wykresach”. I ma rację.

Jakie są najczęstsze wektory ataków w testach DDoS?

Napastnicy rzadko używają dziś jednej metody. Współczesny DDoS to uderzenie wielowektorowe. Atakujący najpierw zapychają łącze surowymi danymi, a gdy systemy filtrujące zaczną działać, płynnie przełączają się na precyzyjne uderzenia w bazę danych. Dlatego symulacje DDoS również muszą naśladować tę dynamikę.

Zaczynamy od ataków wolumetrycznych. Celują w wysycenie dostępnego pasma. Używamy tu amplifikacji UDP. Wykorzystujemy otwarte serwery DNS lub NTP w sieci, wysyłając do nich małe zapytanie ze sfałszowanym adresem zwrotnym naszej ofiary. Serwer odpowiada ofierze pakietem kilkadziesiąt razy większym. To klasyczna dźwignia. Z jednego megabita ruchu robisz pięćdziesiąt. Łącze pęka w szwach.

Czym różni się atak SYN flood od ataku na warstwę aplikacji?

To dwa zupełnie inne światy. Atak SYN flood uderza w warstwę sieciową i transportową (L3/L4 w modelu OSI). Wykorzystuje sposób, w jaki maszyny nawiązują połączenia TCP. Atakujący wysyła tysiące żądań synchronizacji (SYN). Serwer ofiary odpowiada (SYN-ACK) i rezerwuje zasoby w pamięci, czekając na ostateczne potwierdzenie (ACK), które nigdy nie nadchodzi. Tabela stanów połączeń na serwerze szybko się zapełnia. Kiedy brakuje w niej miejsca, serwer odrzuca ruch od prawdziwych klientów. Użytkownik widzi błąd ładowania strony. Ten rodzaj ataku wymaga dużej liczby pakietów na sekundę.

Atak na warstwę aplikacji (L7) działa inaczej. Tu nie chodzi o zapchanie rury z internetem. Chodzi o zajechanie procesora i pamięci RAM na serwerze aplikacyjnym lub bazie danych. Atakujący nawiązuje w pełni poprawne połączenie TCP, omijając podstawowe filtry. Następnie wysyła proste zapytanie HTTP. Na przykład każe wygenerować skomplikowany raport w panelu, albo używa wyszukiwarki na stronie wpisując losowe znaki. Dla atakującego to kosztuje ułamek sekundy pracy procesora. Dla serwera ofiary, który musi przeszukać miliony rekordów w bazie MySQL, to potężny wysiłek. Kilkaset takich zapytań na sekundę i maszyna przestaje oddychać. W testach DDoS stress to właśnie ataki L7 są najtrudniejsze do odparcia, bo złośliwy ruch do złudzenia przypomina zachowanie prawdziwych klientów w sklepie.

Ile kosztuje profesjonalny stress test DDoS?

Nie ma tu sztywnego cennika. Widziałem oferty za pięć tysięcy złotych i widziałem wyceny dobijające do stu tysięcy. Wszystko zależy od skali przedsięwzięcia i czasu trwania symulacji. Tanie testy to zazwyczaj zautomatyzowane skrypty odpalane z jednej chmury na godzinę. Dają pogląd na to, czy firewall w ogóle działa. Nic więcej.

Rozbudowane symulacje, tak zwane Red Teaming DDoS, wymagają zaangażowania kilku inżynierów przez tydzień. Tworzą oni niestandardowe wektory ataku pod konkretną aplikację. Obserwują, jak zachowuje się zespół klienta i jak szybko eskaluje problem do zewnętrznych dostawców. Zazwyczaj trzeba zapłacić około trzydziestu tysięcy złotych za taki pełny audyt. To dużo. Z drugiej strony, godzina przestoju dużej platformy logistycznej kosztuje firmę milion. Matematyka jest tu brutalnie prosta.

Jak przygotować serwer i sieć przed symulacją ataku?

Zrobienie testu bez przygotowania to proszenie się o awarię sprzętową. Musisz zabezpieczyć środowisko. Zaczynamy od wydzielenia osobnego kanału komunikacji. Jeżeli do monitorowania serwerów używasz tego samego łącza, które będziesz atakować, to w sekundę po starcie testu stracisz podgląd na wykresy. Ruch zapcha interfejs zarządzający. Zawsze konfiguruj out-of-band management. Osobny interfejs sieciowy, najlepiej na innym fizycznym łączu, tylko do odczytu danych z nagiosa czy zabbixa.

Kolejne kroki to czysta mechanika wdrożeniowa:

• Wykonaj pełne zrzuty baz danych i konfiguracji urządzeń sieciowych na godzinę przed startem. Czasem routery potrafią uszkodzić tabelę routingu przy ekstremalnym obciążeniu procesora.
• Zdefiniuj twardy warunek przerwania testu (Stop Condition). Na przykład: przerywamy atak, jeśli opóźnienia do bazy danych przekroczą 5 sekund, albo gdy zużycie CPU na switchach rdzeniowych przebije 95%. Chcemy testować limity, a nie spalić sprzęt w serwerowni.
• Powiadom dział obsługi klienta. Nawet przy testach w nocy jacyś użytkownicy będą na stronie. Będą dzwonić i zgłaszać błędy. Support musi wiedzieć, że to kontrolowana akcja, i podawać spójny komunikat o przerwie technicznej.
• Miej pod ręką numery telefonów bezpośrednio do inżynierów w centrum operacyjnym (SOC) twojego dostawcy anty-DDoS. Zwykła infolinia pierwszej linii wsparcia nic ci nie da o trzeciej nad ranem.

Dlaczego systemy anty-DDoS zawodzą podczas prawdziwego uderzenia?

Zazwyczaj problem nie leży w samej technologii filtrowania. Urządzenia firm takich jak Cloudflare, Akamai czy Arbor Networks potrafią przyjąć terabity danych. Zrzucają brudny ruch bez mrugnięcia okiem. Sprzęt działa świetnie. Zawodzi konfiguracja na styku technologii i biznesu.

Najczęstszym błędem jest brak inspekcji ruchu szyfrowanego. Atakujący używają wektorów HTTPS flood. Zestawiają połączenia SSL z serwerem. System anty-DDoS dostawcy ISP widzi tylko zaszyfrowany strumień. Nie wie, czy w środku jest logowanie klienta do banku, czy skrypt próbujący zarżnąć bazę danych. Żeby firewall mógł to przefiltrować, musi zdekodować ruch. A to wymaga przekazania dostawcy kluczy SSL i ogromnej mocy obliczeniowej. Wiele firm z tego rezygnuje ze względów prywatności. W efekcie złośliwy ruch L7 przechodzi przez filtry jak przez masło prosto na serwer docelowy.

Druga sprawa to czas reakcji BGP. Kiedy wykrywamy atak na własną podsieć, musimy rozgłosić do internetu nową trasę. Zmieniamy routing tak, aby cały ruch do nas trafiał najpierw do scrubbing center dostawcy bezpieczeństwa. Propagacja takiego wpisu BGP w globalnej sieci potrafi zająć od dwóch do pięciu minut. Przez te pięć minut uderzenie idzie prosto w twoje niezabezpieczone łącze. Routery na brzegu sieci po prostu się poddają. Nawet jeśli ochrona w końcu się włączy, to infrastruktura wymaga ręcznego restartu, bo tablice ARP uległy zawieszeniu.

Czy usługi typu IP stresser i booter są legalne?

W internecie bez problemu znajdziesz strony oferujące usługi typu “IP stresser” lub “booter”. Reklamują się jako narzędzia do testowania własnych sieci. Wpisujesz adres IP, wybierasz siłę ataku, płacisz w kryptowalucie i klikasz start. To szara strefa, która płynnie przechodzi w zwykłe przestępstwo.

Różnica między profesjonalną platformą do testów a booterem z darknetu polega na infrastrukturze pod spodem. Legalne platformy generują ruch z własnych, opłaconych serwerów w autoryzowanych centrach danych. Bootery korzystają z botnetów. Wykorzystują zarażone wirusami kamery IP, domowe routery i przejęte komputery nieświadomych użytkowników. Kiedy odpalasz test z bootera, nawet na swój własny serwer, używasz kradzionych zasobów. Z punktu widzenia prawa bierzesz udział w nielegalnym procederze.

Co gorsza, takie serwisy nie dają żadnej gwarancji poufności. Zostawiasz im adresy IP swoich kluczowych systemów. Właściciele booterów często handlują tymi danymi. Za miesiąc możesz dostać maila z szantażem, że jeśli nie zapłacisz okupu, ten sam botnet uderzy w ciebie bez ostrzeżenia. Nigdy nie zlecaj testów obciążeniowych podmiotom, które nie mają osobowości prawnej, nie podpiszą umowy NDA i przyjmują płatności wyłącznie w Bitcoinach. Zlecanie audytu przestępcom to absurd korporacyjny.

Zbudowanie odpornej sieci wymaga potu i ciągłego podważania własnych założeń. Konfiguracja sprzętu to tylko połowa sukcesu. Prawdziwa weryfikacja następuje w momencie, gdy zamykasz terminal i patrzysz na wykresy obciążenia skaczące do maksimum. Zostawiam cię z jedną konkretną myślą. Zaloguj się jutro rano na swój główny load balancer, sprawdź jaki masz ustawiony limit rate-limitingu dla pojedynczego adresu IP. Jeśli nie wiesz, albo wartość wynosi domyślne “unlimited”, to twój system jest otwarty na najprostszy atak z pierwszego lepszego skryptu. Popraw to natychmiast.

FAQ: Najczęściej zadawane pytania o testy DDoS

• Czym jest DDoS stress test?
  To kontrolowana symulacja ataku na własną infrastrukturę sieciową, służąca do weryfikacji wydajności serwerów i skuteczności filtrów bezpieczeństwa.
• Czy mogę testować serwery bez wiedzy dostawcy hostingu?
  Nie. Zawsze musisz poinformować dostawcę łącza i usług chmurowych. Brak zgody skutkuje zablokowaniem usług i potencjalnym zerwaniem umowy.
• Jaka jest różnica między L3/L4 a L7 w atakach DDoS?
  L3/L4 celuje w przepustowość łącza i pakiety sieciowe (np. zapchanie rury). L7 uderza w warstwę aplikacji, wyczerpując zasoby procesora i bazy danych poprzez legalnie wyglądające zapytania.
• Ile trwa typowa symulacja ataku?
  Od kilkunastu minut do kilku godzin. Składa się z wielu krótkich, kilkuminutowych uderzeń różnymi wektorami, przerywanych analizą logów.
• Czy usługi typu “booter” są bezpieczne do testów?
  Absolutnie nie. Korzystają z nielegalnych botnetów i zarażonych urządzeń. Ich użycie jest ryzykowne prawnie i naraża twoją infrastrukturę na ujawnienie przestępcom.
• Dlaczego WAF nie chroni przed wszystkim?
  WAF analizuje głównie zapytania HTTP. Jest bezradny wobec potężnych ataków wolumetrycznych UDP, które zapychają fizyczne łącze na poziomie routera szkieletowego, zanim pakiety w ogóle dotrą do aplikacji.

Bibliografia

1. CERT Polska – https://cert.pl
2. Naukowa i Akademicka Sieć Komputerowa (NASK) – https://nask.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
5. Wydawnictwo Naukowe PWN – https://pwn.pl