Intencją osoby szukającej informacji o ataku DDoS jest zrozumienie, co dokładnie dzieje się w sieci podczas takiego incydentu i jakie kroki podjąć, aby jak najszybciej ograniczyć skutki dla użytkowników i biznesu. Chodzi o praktyczny schemat działania: rozpoznanie charakterystycznych objawów, potwierdzenie diagnozy, wykonanie natychmiastowych działań ratunkowych i wdrożenie trwalszych zabezpieczeń.
Frazy powiązane z tym tematem, które naturalnie przewijają się w kontekście ataku DDoS, to: rodzaje ataków DDoS, objawy ataku DDoS w sieci, analiza logów podczas DDoS, ochrona aplikacji przed DDoS, filtrowanie ruchu sieciowego, współpraca z ISP przy ataku DDoS, playbook reagowania na DDoS, testy odporności na DDoS, błędy przy obsłudze ataku DDoS, lista kontrolna bezpieczeństwa sieci.
Czym właściwie jest atak DDoS i dlaczego jest tak groźny
DoS a DDoS – kluczowa różnica
Atak DoS (Denial of Service) to działanie mające uniemożliwić poprawne funkcjonowanie usługi – strony WWW, API, serwera pocztowego czy VPN. Może polegać na zalewaniu serwera dużą liczbą zapytań, wysycaniu łącza lub wykorzystywaniu błędów w oprogramowaniu, by usługa przestała odpowiadać.
DDoS (Distributed Denial of Service) to ten sam cel, ale realizowany przez wiele rozproszonych źródeł. Zamiast jednego komputera wysyłającego ruch, atakują setki, tysiące, a czasem dziesiątki tysięcy maszyn – zwykle zainfekowanych i kontrolowanych w ramach botnetu. Atak może wyglądać jak normalny ruch od użytkowników z różnych krajów i autonomicznych systemów, co utrudnia proste blokowanie.
Jeśli ruch pochodzi z wielu rozproszonych adresów IP i podsieci, nie można go „wyciąć” jednym filtrem na firewallu. Trzeba odróżnić to, co jest legalnym ruchem klientów, od sztucznego, generowanego przez boty. To właśnie rozproszenie powoduje, że ataki DDoS są tak dotkliwe i trudne do całkowitego zablokowania.
Po co przeprowadza się atak DDoS
Intencje atakujących są różne, ale w praktyce najczęściej spotyka się kilka powtarzalnych scenariuszy:
Wymuszenie – wysyłany jest e-mail lub wiadomość z informacją: „Zapłać, inaczej Twoja strona/serwis będzie nieustannie wyłączany atakiem DDoS”. Niekiedy napastnik demonstruje swoje możliwości krótkim, kilkuminutowym atakiem, po czym żąda okupu.
Sabotaż biznesowy – atak podczas kluczowej kampanii marketingowej, premiery produktu, wyprzedaży lub wydarzenia online. Cel jest prosty: obniżyć sprzedaż, zniechęcić klientów, naruszyć wizerunek konkurencyjnej firmy.
Odwrócenie uwagi – DDoS może służyć za zasłonę dymną. W momencie, gdy dział IT jest skupiony na przywracaniu dostępności usług, równolegle może trwać bardziej precyzyjny atak: wyciek danych, próba włamania do panelu administracyjnego, instalacja backdoora.
Ideologiczne lub „hobbystyczne” motywacje – ataki z pobudek politycznych, aktywistycznych, a także zwykła „demonstracja siły” grupy hackerskiej.
Jeśli infrastruktura nie ma przygotowanego planu działania na atak DDoS, każdy z tych scenariuszy może zakończyć się długotrwałą niedostępnością kluczowych systemów.
Skutki biznesowe wykraczające poza samą niedostępność
Atak DDoS często kojarzy się głównie z „padem strony”. W praktyce konsekwencje są szersze i rozciągnięte w czasie:
Przestoje i utracone przychody – sklep internetowy, który nie działa przez kilka godzin w szczytowym okresie sprzedaży, realnie traci klientów. Część z nich nie wróci. W przypadku usług B2B przestój może oznaczać kary umowne za niedotrzymanie SLA.
Szkody wizerunkowe – klienci widzą „500 Internal Server Error” lub komunikat o niedostępności usługi. Pojawiają się komentarze w social mediach, rośnie frustracja, pojawia się wątpliwość co do jakości i bezpieczeństwa usługi.
Wzrost kosztów operacyjnych – nadgodziny zespołu IT, zaangażowanie zewnętrznych specjalistów, zakup awaryjnych rozwiązań w trybie pilnym, przepłacone licencje i usługi ochrony „na już”.
Ryzyko wtórnych incydentów – w chaosie łatwiej o błędy konfiguracyjne, nieprzemyślane wyłączenia zabezpieczeń albo wdrożenia „na szybko”, które zostają na stałe i po jakimś czasie stają się luką.
Dlatego obrona przed DDoS nie sprowadza się tylko do „przetrwania ataku”, ale też do utrzymania kontroli nad siecią, procesami i komunikacją z użytkownikami.
Głośne ataki vs „ciche” DDoS na mniejszą skalę
Media opisują zwykle spektakularne incydenty, gdzie ruch sięga setek gigabitów na sekundę. To jednak tylko fragment obrazu. Równie groźne bywają mniejsze, „ciche” ataki DDoS, wymierzone precyzyjnie w konkretną aplikację, bazę danych czy usługę logowania.
Taki atak może generować stosunkowo mały wolumen ruchu, ale wykonywać działania bardzo kosztowne dla aplikacji: złożone zapytania do bazy, wielokrotne próby logowania, tworzenie ciężkich raportów. Infrastruktura nie wysyca łącza, ale procesory i pamięć są zapchane, a usługa zwalnia do tego stopnia, że staje się praktycznie nieużywalna.
Ataki o małym wolumenie łatwo pomylić z błędami wydajnościowymi czy problemami z bazą danych. Jeśli nie ma monitoringu i przygotowanej procedury analizy, miesiącami można walczyć z „tajemniczym spowolnieniem”, zamiast uderzyć w źródło problemu.
Źródło: Pexels | Autor: Tima Miroshnichenko
Klasyfikacja i typowe scenariusze ataków DDoS
Trzy główne kategorie: wolumetryczne, L3/L4 i aplikacyjne
Większość ataków DDoS daje się sklasyfikować w jednym z trzech głównych typów. Często spotykane są też ich kombinacje.
Ataki wolumetryczne – celem jest wysycenie łącza lub zasobów sieciowych. Ruch bywa mierzony w Gbit/s lub liczbie pakietów na sekundę. Typowe przykłady to UDP flood czy ICMP flood.
Ataki na warstwę sieciową i transportową (L3/L4) – celują w zasoby routerów, firewalli, stosu TCP/IP na serwerach. Przykładem jest SYN flood, który zużywa pulę półotwartych połączeń TCP.
Ataki na warstwę aplikacji (L7) – atakujący symuluje „normalnych użytkowników”, ale w dużej liczbie i w sposób przeciążający aplikację: HTTP GET/POST flood, „low and slow” typu slowloris.
Rozpoznanie, z jakim typem ataku DDoS mamy do czynienia, jest kluczowe, bo inne będą skuteczne mechanizmy obrony: dla ataków wolumetrycznych często potrzebna jest pomoc ISP lub usługi scrubbingu, dla L7 – optymalizacja aplikacji i filtracja na poziomie WAF/CDN.
Przykładowe techniki: SYN flood, UDP flood, slowloris i inne
Znajomość podstawowych technik ułatwia analizę logów i objawów. Najczęstsze z nich:
SYN flood – atakujący wysyła ogromną liczbę pakietów TCP SYN do serwera, ale nie kończy trójfazowego handshake (brak ACK). Serwer trzyma półotwarte połączenia w kolejce, aż ta się zapełni i zacznie odrzucać legalne połączenia.
UDP flood – generowanie ruchu UDP (często na losowe lub konkretne porty) bez oczekiwania odpowiedzi. Celem jest wykorzystanie przepustowości i zasobów po stronie serwera, który próbuje obsługiwać lawinę pakietów.
ICMP flood – masowe wysyłanie pakietów ICMP (np. ping) w celu przeciążenia kanału lub urządzeń pośrednich. Dziś często mniej skuteczny, bo ICMP bywa ograniczany przez urządzenia brzegowe, ale w niektórych środowiskach wciąż sprawia kłopoty.
HTTP GET/POST flood – wiele równoległych zapytań HTTP do konkretnych zasobów serwisu. Uderzają np. w wyszukiwarkę, endpoint generujący raporty albo inne zasobożerne operacje, które w dużej liczbie obciążają CPU i bazę danych.
Slowloris i „low and slow” – atakujący otwiera połączenia HTTP do serwera i wysyła dane bardzo powoli, nigdy ich nie kończąc. Serwer trzyma te połączenia jako aktywne, przez co wyczerpuje pulę dostępnych gniazd i nie może obsługiwać nowych klientów.
Każdy z tych scenariuszy zostawia inne ślady w logach i metrykach. Na przykład przy SYN flood widać wysoki poziom półotwartych połączeń i gwałtowny wzrost liczby pakietów SYN, podczas gdy przy HTTP flood rośnie przede wszystkim liczba requestów na sekundę oraz obciążenie procesora i bazy.
Botnety, urządzenia IoT i ataki wzmacniane
Źródłem ataku DDoS rzadko jest pojedynczy silny serwer. Najczęściej ruch generują:
Botnety z komputerów użytkowników – maszyny zainfekowane malware, często bez wiedzy właścicieli. Mogą to być laptopy, PC, a także serwery w nieodpowiednio zabezpieczonych środowiskach.
Urządzenia IoT – kamery, routery, rejestratory, „inteligentne” sprzęty z domyślnymi hasłami. Po przejęciu tworzą ogromne botnety generujące ruch DDoS.
Serwery z otwartymi usługami UDP – DNS, NTP, memcached i inne usługi, które można wykorzystać do tzw. amplification attacks. Atakujący wysyła małe zapytania z podszytym adresem (Twoim), a serwer „odpowiada” dużą ilością danych na wskazany adres ofiary.
Ataki wzmacniane (amplification) są szczególnie niebezpieczne, bo niewielkim nakładem ruchu po stronie atakującego można wygenerować bardzo duży wolumen ruchu po stronie ofiary. Filtracja takich strumieni często wymaga współpracy z dostawcą łącza i wyspecjalizowanymi usługami scrubbingu.
Ataki mieszane, rozłożone w czasie i „niskie i powolne”
Coraz częściej atak DDoS nie ogranicza się do jednej metody. Napastnicy łączą różne wektory:
Multi-vector – np. równoczesny UDP flood na porty DNS, SYN flood na port 443 oraz HTTP flood w aplikacji webowej. Obrona musi wtedy działać na kilku poziomach: routerów, firewalli, serwerów WWW i samej aplikacji.
Ataki rozłożone w czasie – krótkie, intensywne piki co kilkanaście minut, albo długotrwały średni ruch utrzymujący obciążenie infrastruktury na granicy wydolności.
Niskie i powolne – atak celujący w warstwę aplikacyjną, gdzie ruch nie jest ogromny, ale dokładnie wymierzony w kosztowne operacje. Często trudniejsze do wykrycia w klasycznych systemach monitoringu, które patrzą głównie na wolumen.
Skuteczna obrona wymaga więc nie tylko filtrowania „wielkich fal”, ale też uwagi dla zmian wzorców zachowania użytkowników i anomalii na poziomie aplikacji.
Przykład wymuszenia na sklepie internetowym
Typowy scenariusz z praktyki: sklep internetowy planuje dużą promocję weekendową. Tydzień wcześniej ktoś wysyła wiadomość, że jeśli firma nie zapłaci określonej kwoty w kryptowalucie, strona zostanie wyłączona atakiem DDoS. Ostrzeżenie jest ignorowane. W dniu startu promocji, na kilka godzin przed startem, zaczyna się atak: najpierw wolumetryczny na port 80/443, następnie – gdy wdrożono podstawowe filtry – przechodzi w HTTP GET flood na stronę wyszukiwarki i listy produktów.
Bez przygotowanego planu (playbooka) zespół IT działa reakcjami ad hoc, ręcznie dopisuje reguły firewall, restartuje serwery. Atakujący zmienia wektory, wykorzystuje inne podsieci botnetu. Ostatecznie większość promocji przebiega przy mocno ograniczonej dostępności sklepu, pojawiają się skargi i ślady w mediach społecznościowych. Dopiero po incydencie zapada decyzja o wdrożeniu profesjonalnego rozwiązania anti-DDoS i zmianie architektury aplikacji.
Wczesne sygnały i objawy ataku DDoS w sieci
Typowe symptomy z perspektywy użytkownika i administratora
Atak DDoS najczęściej sygnalizują jednocześnie trzy źródła: użytkownicy (skargi), monitoring i same systemy (błędy, logi). Najbardziej charakterystyczne objawy to:
nagłe spowolnienie usług – strony WWW ładują się bardzo długo, logowanie trwa kilkadziesiąt sekund, proste akcje w panelu „zawieszają” przeglądarkę,
całkowity brak odpowiedzi – połączenia HTTP/HTTPS timeoutują, nie działa VPN, zrywane są sesje RDP lub SSH,
skoki wykorzystania łącza – gwałtowny wzrost zużycia pasma na interfejsie WAN, obserwowany w SNMP, NetFlow lub panelu routera,
Nieoczywiste oznaki: anomalie w logach, sesjach i zachowaniu aplikacji
Oprócz oczywistych objawów, takich jak brak odpowiedzi serwisu, pojawiają się subtelniejsze sygnały, które często są ignorowane lub przypisywane „chwilowym problemom”:
nietypowy rozkład ruchu po godzinach – nagły szczyt ruchu w porach, gdy zwykle jest cisza (np. 3:00 w nocy), przy czym nie ma żadnej kampanii marketingowej czy wdrożeń,
skupienie ruchu na jednym lub kilku endpointach – np. 70% zapytań trafia nagle na /search, /api/login lub /cart/checkout,
wzrost liczby błędów aplikacyjnych – HTTP 500, 502, 503, 504, przerwane zapytania do bazy, time-outy po stronie backendu,
dziwne wzorce w User-Agent i nagłówkach HTTP – setki tysięcy zapytań z takim samym lub bardzo podobnym UA, brak typowych nagłówków przeglądarkowych,
nagłe zwiększenie liczby otwartych połączeń przy jednocześnie niskim faktycznym ruchu danych (charakterystyczne dla „low and slow”).
W praktyce pomocny bywa prosty nawyk: przy każdym „tajemniczym” spowolnieniu serwisu admin zagląda do wykresów liczby requestów na endpoint, rozkładu kodów HTTP oraz listy najaktywniejszych IP. Jeśli cokolwiek odbiega od typowego obrazu, trzeba rozważyć scenariusz DDoS, a nie tylko „wolną bazę” czy problem z dyskiem.
Różnice między awarią infrastruktury a atakiem DDoS
Duża część objawów DDoS przypomina zwykłe awarie: przeciążenie serwera, błąd w konfiguracji, problemy po wdrożeniu nowej wersji. Kluczowe są szczegóły i korelacje w czasie.
Przy awariach wewnętrznych zwykle widać:
zmiany bezpośrednio po wdrożeniu, restarcie usług lub ingerencji w konfigurację,
problemy ograniczone do jednego komponentu (np. tylko bazy danych, tylko jednego mikroserwisu),
brak nietypowego wzrostu ruchu z zewnątrz – łącze i liczba sesji pozostają na normalnym poziomie.
Przy DDoS natomiast częściej pojawiają się:
problemy „znikąd”, bez zmian konfiguracyjnych po stronie zespołu,
korelacja z anomaliami w ruchu przychodzącym: więcej sesji, większe PPS (packets per second), wzrost liczby połączeń w stanie SYN-RECEIVED,
równoczesne zgłoszenia od użytkowników z różnych lokalizacji, różnych dostawców internetu.
Jeśli nie ma pewności, czy to awaria, czy atak, analiza kilku prostych wskaźników (ruch na WAN, liczba nowych połączeń, NetFlow) bardzo często rozstrzyga sytuację w kilka minut.
Jak odróżnić „sezonowy pik” od celowego przeciążenia
Dla usług B2C zagrożeniem są również w pełni „legalne” piki ruchu – świąteczne zakupy, kampania w TV, promocja wysłana newsletterem. Jeśli aplikacja i infrastruktura nie są skalowane na takie okazje, efekt bywa podobny do DDoS. Różnice widać w strukturze ruchu.
Przy naturalnym piku:
rośnie liczba requestów z typowymi przeglądarkami (różne User-Agent, różne wersje systemów),
w logach pojawia się zróżnicowanie ścieżek URL – użytkownicy odwiedzają wiele różnych stron, eksplorują serwis,
zwiększa się liczba transakcji biznesowych (zamówienia, rejestracje),
źródłami ruchu są kampanie marketingowe, social media, realne odnośniki.
Przy DDoS wolumetrycznym lub aplikacyjnym bardzo często:
ruch koncentruje się na jednym typie zapytania lub kilku endpointach,
widzimy wiele IP z tych samych podsieci, AS-ów lub krajów, wcześniej rzadko spotykanych,
brakuje przejścia do kolejnych kroków w ścieżkach użytkownika (np. masa wejść na /login bez prób dalszej aktywności).
Monitoring powinien więc nie tylko liczyć requesty, ale też agregować dane po ścieżkach, krajach, ASN, User-Agent i typach odpowiedzi. Dzięki temu odróżnienie „sukcesu marketingowego” od wrogiego ruchu jest znacznie łatwiejsze.
Źródło: Pexels | Autor: Markus Winkler
Diagnoza krok po kroku – jak potwierdzić, że to DDoS
Szybki przegląd metryk infrastruktury
Gdy pojawiają się pierwsze sygnały problemów z wydajnością, sensowny pierwszy krok to spojrzenie na podstawowe metryki. Minimalny zestaw to:
przepustowość interfejsów WAN – ruch RX/TX, PPS, błędy na portach,
liczba nowych połączeń na sekundę – na firewallu, load balancerze lub serwerze WWW,
stan tablic połączeń – ile połączeń jest „w toku” (SYN-RECEIVED, ESTABLISHED) i jakie porty dominują,
obciążenie CPU i pamięci na serwerach aplikacyjnych, bazodanowych i urządzeniach brzegowych.
Jeśli ruch na łączu nagle zbliżył się do maksymalnej przepustowości, a liczba połączeń rośnie wielokrotnie, to silna przesłanka, że mamy do czynienia z atakiem. Jeśli łącze jest jeszcze wolne, ale tablice połączeń są zapchane albo CPU serwerów osiąga 100%, problem może dotyczyć wyższych warstw (L4/L7) lub konkretnego komponentu.
Analiza NetFlow/sFlow i logów na brzegu sieci
Dane przepływowe (NetFlow, sFlow, IPFIX) są jednym z najskuteczniejszych narzędzi do szybkiej diagnozy. Dają odpowiedzi na kilka kluczowych pytań:
jakie protokoły dominują (UDP/TCP/ICMP),
jakie porty są celem (np. 53, 80, 443, porty aplikacji własnych),
z jakich podsieci, krajów, AS-ów pochodzi większość ruchu,
które adresy IP po stronie źródłowej są najbardziej aktywne.
W typowym ataku DDoS występuje jedno lub kilka zjawisk:
silna koncentracja na pojedynczym porcie docelowym – np. prawie cały ruch trafia na 443/TCP lub 53/UDP,
wzrost ilości krótkich przepływów – wiele krótkotrwałych „flows” z tym samym celem, ale różnymi źródłami,
nadreprezentacja określonych AS-ów lub krajów, których wcześniej prawie nie było,
burst pakietów – gwałtowne piki PPS, które nie są związane z realnymi zdarzeniami biznesowymi.
Jeśli infrastruktura nie ma wdrożonego NetFlow/sFlow, awaryjnie można posłużyć się nawet prostym tcpdumpem na interfejsie brzegowym i analizą w Wiresharku. Kilkusekundowy zrzut ruchu często wystarcza, aby rozpoznać np. klasyczny UDP flood na DNS.
Identyfikacja wektora: który poziom stosu jest atakowany
Pewne wzorce pozwalają szybko przypisać atak do warstwy, na której głównie działa:
L3/L4 (sieć/transport) – duża liczba pakietów, często z niekompletnym handshake (SYN flood), ruch kierowany na porty usług, ale bez „prawdziwych” zapytań wyższej warstwy,
L7 (aplikacja) – pełne połączenia TCP, poprawne handshake, a następnie lawina zapytań HTTP, DNS, gRPC czy innych protokołów aplikacyjnych,
atak mieszany – jednoczesne objawy na kilku poziomach: zapełnione łącze i wysokie CPU aplikacji.
Do rozpoznania warstwy aplikacyjnej przydają się logi serwera WWW (np. access.log w Nginx/Apache), logi WAF lub API gateway. Jeśli nagle widać tysiące żądań z tym samym parametrem zapytania albo odpytywanie wyłącznie jednego endpointu REST, to mocny sygnał L7 DDoS.
Prosty check-list diagnostyczny
W wielu zespołach sprawdza się krótka lista kroków, dzięki której nie traci się czasu na chaotyczne działania:
Sprawdź ruch na interfejsach WAN (SNMP/GUI routera) – czy jest niepokojący skok?
Zobacz liczbę nowych połączeń oraz stan tablic na firewallu/load balancerze.
Przejrzyj logi serwera WWW i WAF (nagły wzrost RPS, powtarzające się IP, ścieżki).
Przeanalizuj choćby krótkie dane NetFlow/tcpdump, aby poznać protokoły i porty.
Porównaj obserwacje z kalendarzem zmian (wdrożenia, kampanie marketingowe).
Jeśli na kilku z tych poziomów widać równoczesne anomalie, można z dużym prawdopodobieństwem mówić o DDoS. Następny krok to przejście z diagnozy do obrony.
Szybkie działania ratunkowe w trakcie trwającego ataku
Priorytety w pierwszych minutach
Gdy atak już trwa, liczy się czas. Nie chodzi o pełną, elegancką analizę, ale o odzyskanie minimum działania usług. Priorytety zwykle układają się tak:
ochrona łącza i urządzeń brzegowych – jeśli router, firewall czy łącze padną, reszta i tak przestaje mieć znaczenie,
zapewnienie dostępu do kluczowych usług – np. panelu zamówień, bramki płatności, API integracyjnego,
utrzymanie kanałów zarządzania – VPN, SSH, zdalny dostęp administracyjny, aby zespół miał jak działać.
Dlatego w pierwszych minutach często wykonuje się proste, ale skuteczne kroki: tymczasowe blokady na poziomie IP/podsieci, limitowanie wybranych protokołów, wyłączenie zbędnych usług narażonych na ruch z internetu.
Szybkie reguły filtracji na routerze i firewallu
Jeśli wektor ataku jest już wstępnie zidentyfikowany, można zastosować ograniczenia na brzegu sieci. Przykładowe działania:
blokowanie ruchu z oczywiście „śmieciowych” zakresów – np. setek IP z jednej mało wiarygodnej podsieci, które generują głównie UDP/ICMP,
rate limiting dla określonych protokołów/portów – np. ograniczenie liczby pakietów SYN na sekundę na IP,
zablokowanie nieużywanych protokołów – jeśli serwis nie musi odpowiadać na ICMP czy nietypowe porty UDP, lepiej je chwilowo odciąć,
reguły dropping TTL/fragmentacji – w przypadku specyficznych wektorów wykorzystujących fragmentację pakietów.
Warto unikać ręcznego wprowadzania dziesiątek losowych reguł. Każda zmiana powinna odpowiadać konkretnemu, zaobserwowanemu wzorcowi ruchu. Jeśli router/firewall zacznie sam być zapchany zbyt rozbudowanymi ACL, sytuacja się pogorszy.
Kontakt z dostawcą łącza i usługą scrubbingu
Przy silnych atakach wolumetrycznych filtracja lokalna nie wystarczy – łącze jest już zapełnione, zanim ruch dotrze do własnego routera. Wtedy jedyną realną opcją jest filtracja „przed” Twoją infrastrukturą:
zgłoszenie incydentu do ISP – większość operatorów ma procedury „blackholingu” (RTBH) oraz czasem podstawowych filtrów DDoS,
aktywacja usługi scrubbingu (on demand) – ruch do Twojej sieci jest przekierowywany przez centrum czyszczące, gdzie odfiltrowuje się „śmieci”,
stosowanie BGP blackhole w ostateczności – odcięcie konkretnych IP/zakresów od świata, aby uratować resztę infrastruktury.
Blackholing jest środkiem drastycznym – oznacza faktyczne odcięcie danej usługi od internetu. Czasem jednak lepiej na godzinę „poświęcić” atakowany adres IP niż doprowadzić do całkowitej niedostępności całej sieci firmowej.
Ograniczenie ekspozycji usług – tymczasowe wyłączenia i obejścia
Nie każda usługa musi być dostępna w trakcie ataku. Czasem właściwą reakcją jest świadome ograniczenie funkcji, tak aby najważniejsza część biznesu nadal działała. Przykłady:
przekierowanie ruchu z części domen na prostą stronę statyczną hostowaną u zewnętrznego dostawcy,
czasowe wyłączenie modułów, które są celem ataku (np. wyszukiwarki pełnotekstowej), i zastąpienie ich komunikatem o ograniczonej funkcjonalności,
odcięcie interfejsów administracyjnych z internetu (np. paneli zarządzania),
włączenie mechanizmów „read only” – np. blokady nowych rejestracji lub edycji danych, jeśli ich obsługa najbardziej obciąża backend.
Jedna z częstych praktyk w e-commerce: w trakcie silnego ataku aplikacja webowa przełącza się na tryb uproszczony – mniej obrazków, mniej dynamicznych elementów, brak rekomendacji i personalizacji. Z punktu widzenia klienta serwis jest uboższy, ale nadal pozwala złożyć zamówienie.
Komunikacja z biznesem i użytkownikami
Ustalenie kanałów informowania i prostych komunikatów
Podczas incydentu technologia to tylko połowa układanki. Druga to jasna komunikacja – wewnątrz organizacji i na zewnątrz. Chaos informacyjny potrafi wyrządzić tyle samo szkód, co sam atak.
Na poziomie operacyjnym zespół powinien od razu ustalić:
kto jest osobą kontaktową dla biznesu i zarządu (żeby reszta mogła spokojnie pracować technicznie),
jakimi kanałami informowane są zespoły – np. dedykowany kanał w komunikatorze firmowym + krótki raport e-mail po kluczowych działaniach,
jak często aktualizowany jest status – np. co 15–30 minut w pierwszej fazie, potem rzadziej.
Dobrą praktyką jest przygotowanie wcześniej kilku szablonów komunikatów – osobno dla:
użytkowników końcowych – krótko i bez detali technicznych („część usług jest niedostępna, pracujemy nad przywróceniem działania”),
kluczowych klientów/B2B – z informacją, które interfejsy API lub usługi są dotknięte i jakie są obejścia,
zarządu – z naciskiem na wpływ biznesowy, szacowany czas przywrócenia i działania ograniczające ryzyko na przyszłość.
Jeśli organizacja korzysta z publicznych kanałów (status page, social media), lepiej podać prostą, spójną informację, niż milczeć lub publikować niespójne komunikaty z kilku działów.
Decyzje biznesowe w trakcie ataku
Część decyzji technicznych ma bezpośredni wymiar biznesowy. Przykład: włączenie mocnej ochrony anty-DDoS na poziomie L7 może skutkować większą liczbą fałszywych blokad. Pojawia się dylemat: czy bardziej opłaca się przepuścić trochę niechcianego ruchu, czy zablokować część legalnych użytkowników.
Przydatny jest prosty podział trybów pracy:
tryb “business as usual” – standardowe reguły, minimalne ryzyko false positives,
tryb “degradowanej jakości” – akceptujemy pewne utrudnienia dla części klientów, w zamian chroniąc kluczowe procesy (np. transakcje),
tryb “ratunkowy” – celem jest utrzymanie przy życiu tylko najbardziej krytycznych funkcji, nawet jeśli reszta jest tymczasowo odcięta.
Jeśli wcześniej z góry uzgodniono, które procesy są najważniejsze, dział techniczny nie musi w trakcie incydentu eskalować każdej decyzji. Przykładowo, w bankowości internetowej priorytetem są przelewy i logowanie, a nie np. moduł historii ofert marketingowych.
Techniczne metody ograniczania skutków DDoS – od routera po aplikację
Segmentacja i architektura brzegowa
Podstawą rozsądnej obrony jest architektura, która nie pada „cała naraz”. Segmentacja oznacza oddzielenie od siebie różnych typów ruchu i usług, tak aby przeciążenie jednego segmentu nie paraliżowało innych.
Na poziomie sieci przydają się m.in.:
oddzielne interfejsy WAN lub VLAN-y dla różnych typów usług (WWW, VPN, usługi wewnętrzne publikowane na świat),
warstwa DMZ dla systemów wystawionych do internetu, z jasnymi regułami ruchu do sieci wewnętrznej,
osobne urządzenia brzegowe dla krytycznych systemów, jeśli skala na to pozwala.
Jeżeli wszystkie serwisy, VPN i panele administracyjne stoją za jednym adresem publicznym i jednym łączem, nawet dobry filtr nie zawsze uratuje przed skutkami dużego wolumenu ruchu.
Ochrona na poziomie L3/L4 – filtrowanie i ograniczanie ruchu
Na warstwie sieciowej i transportowej stosuje się metody, które mają możliwie tanio dla sprzętu „odrzucać śmieci”. Kluczowy jest tu balans – im prostsza reguła, tym szybciej ją przelicza router czy firewall.
Typowe techniki obejmują:
stateless ACL na routerze – odrzucanie znanych złych zakresów, nieużywanych protokołów, nietypowych portów; reguły jak najbliżej brzegu, aby nie obciążać firewalli stanowych,
protection filters na firewallach – mechanizmy typu SYN flood protection, connection limiting per IP, ochrona przed skanowaniem portów,
limity PPS/BPS na wybranych klasach ruchu – np. ograniczenie ICMP, nakładanie twardych limitów na ruch z internetu do paneli administracyjnych.
W niektórych platformach bezpieczeństwa dostępne są gotowe profile „DDoS protection”, jednak ich skuteczność zależy od poprawnego dostrojenia progów. Dobrym punktem startowym są rzeczywiste wartości z monitoringu historycznego – bez tego łatwo o ustawienie progów zbyt nisko lub zbyt wysoko.
Mechanizmy BGP: blackholing i odsyłanie ruchu
Jeśli sieć korzysta z BGP, dochodzą narzędzia dostępne w warstwie routingu. W praktyce używa się ich najczęściej w porozumieniu z operatorem.
Przykładowe techniki:
RTBH (Remotely Triggered Black Hole) – ogłoszenie trasy z odpowiednimi community, które powoduje, że ruch do wskazanego adresu jest „czarnodziurany” u operatora,
ograniczenie ogłaszanych prefiksów – w trakcie ataku część mniej krytycznych zakresów IP nie jest ogłaszana do internetu, co zmniejsza powierzchnię ataku,
przekierowanie ruchu przez scrubbing center – zmiana punktów styku BGP tak, aby cały ruch przechodził przez zewnętrzną infrastrukturę filtrującą.
Wymaga to wcześniejszego przygotowania: podpisanych umów z operatorem, skonfigurowanych community, procedur uruchomienia. Im więcej takich elementów jest „na półce”, tym krótszy czas reakcji.
Warstwa DNS i anycast – rozproszenie powierzchni ataku
DNS jest częstym celem i pośrednikiem w atakach DDoS (np. NXDOMAIN flood, zapytania o ciężkie rekordy). Jednocześnie odpowiednia konfiguracja serwerów DNS znacząco pomaga w rozpraszaniu ruchu.
Kilka praktycznych rozwiązań:
użycie zewnętrznych, rozproszonych providerów DNS zamiast pojedynczego serwera we własnej serwerowni,
anycast DNS – te same adresy IP obsługiwane z wielu punktów na świecie, co powoduje, że ruch ataku „rozlewa się” na wiele lokalizacji,
twarde limity na rekursję i rozmiar odpowiedzi DNS, jeśli hostujesz własne serwery autorytatywne i rekursywne,
duże TTL dla kluczowych rekordów, aby w razie problemów klienci korzystali jak najdłużej z odpowiedzi z cache.
W praktyce wiele organizacji łączy własne serwery DNS (np. dla stref wewnętrznych) z usługą zarządzanego DNS dla domen publicznych – co zmniejsza ryzyko, że pojedyncza awaria DNS wyłączy wszystkie serwisy.
Load balancing i redundancja centrów danych
Jeśli usługi działają w więcej niż jednej lokalizacji, pojawia się dodatkowa oś obrony – dystrybucja ruchu geograficznie. Atak skierowany w jedno centrum danych nie musi od razu obalić całego systemu.
Można zastosować m.in.:
GSLB (Global Server Load Balancing) – rozdzielanie ruchu między regiony na podstawie DNS, opóźnień czy dostępności,
aktywne/aktywne centra danych – oba obsługują produkcyjny ruch, co zwiększa bufor pojemności,
aktywne/pasywne – jedno centrum przejmuje ruch tylko w razie utraty dostępności pierwszego.
Przeniesienie części ruchu do innego regionu nie zawsze „zdejmie” z atakowanego miejsca cały uderzeniowy wolumen, ale daje cenne minuty i dodatkowe zasoby, które można wykorzystać na dostrajanie filtracji.
WAF, reverse proxy i ochrona L7
Na warstwie aplikacyjnej narzędziem pierwszego wyboru jest zwykle reverse proxy z funkcją WAF (Web Application Firewall). Pozwala ono filtrować i ograniczać żądania HTTP(S) zanim dotrą do właściwych serwerów aplikacyjnych.
Przy atakach DDoS na L7 przydają się zwłaszcza:
limity RPS na IP/klienta – np. maksymalna liczba zapytań na sekundę na adres IP albo nagłówek identyfikujący klienta (API key),
reguły oparte o ścieżki i parametry – np. mocne ograniczenie /search, /api/report, jeśli to one są celem ataku,
blokada znanych złych wzorców – user-agenty narzędzi, ścieżki typowe dla skanerów, automatyczne wycinanie zapytań bez nagłówków używanych w realnych przeglądarkach,
ochrona przed masowym otwieraniem długich połączeń – np. HTTP keep-alive z bardzo długim timeoutem, websockety bez limitów.
Najlepsze efekty daje połączenie prostych limitów ilościowych z logiką biznesową. Jeśli wiadomo, że przeciętny klient wykonuje kilka-kilkanaście żądań na minutę, to setki żądań z jednego IP w ciągu kilku sekund są silną przesłanką do zablokowania lub wprowadzenia dodatkowej weryfikacji.
CDN i cache jako „bufor” dla aplikacji
Sieci CDN świetnie nadają się do przejmowania na siebie znacznej części ruchu, zwłaszcza w serwisach webowych. Nawet jeśli atakujący generują duży ruch HTTP, statyczne treści mogą być obsługiwane z krawędzi CDN, a nie z Twojej aplikacji.
cache’owanie dynamicznych odpowiedzi tam, gdzie biznesowo jest to akceptowalne (np. strony kategorii e-commerce, listy produktów),
„stale-while-revalidate” – serwowanie z cache odpowiedzi nawet lekko przeterminowanych, podczas gdy backend odświeża dane w tle.
W trakcie ataku czasami tymczasowo zwiększa się agresywność cache, aby odciążyć backend. Po opanowaniu sytuacji konfigurację można stopniowo przywracać do stanu normalnego.
Rate limiting i mechanizmy „fair use”
Nawet bez dedykowanego WAF można wprowadzić w aplikacji proste mechanizmy chroniące przed nadużyciami. Chodzi o to, by każdy użytkownik otrzymywał „sprawiedliwy” przydział zasobów, a pojedyncze źródło nie zdominowało systemu.
Typowe podejścia to:
limity na endpoint – np. maksymalna liczba wywołań /login, /reset-password, /search w określonym oknie czasowym,
limity per użytkownik/API key – lepsze niż per IP w środowiskach, gdzie wielu użytkowników korzysta z jednego NAT,
Istotne jest monitorowanie odrzuconych żądań – aby odróżnić prawdziwy atak od np. błędu w integracji po stronie klienta, który zaczął generować lawinę nieudanych prób.
CAPTCHA, wyzwania i dodatkowa weryfikacja
Dla części serwisów – szczególnie publicznych formularzy webowych – skutecznym, choć czasem uciążliwym, środkiem są mechanizmy wyzwań: CAPTCHA, puzzle, dodatkowe potwierdzenia. Sprawdzają się zwłaszcza przy atakach z użyciem prostych botów HTTP.
Najrozsądniejsze podejście to stosowanie wyzwań warunkowo:
tylko dla żądań spełniających określone kryteria ryzyka (nowy kraj, nietypowy user-agent, bardzo wysoka częstotliwość),
tylko dla wrażliwych operacji, np. logowania, zakładania kont, wysyłania formularzy,
czasowo, w trakcie incydentu, z możliwością szybkiego wyłączenia.
Jeśli CAPTCHA jest włączona na stałe i zbyt inwazyjnie, użytkownicy zaczną jej unikać lub szukać alternatywnych rozwiązań. W trybie awaryjnym jest jednak często najszybszym sposobem na odcięcie prostych skryptów atakujących.
Optymalizacja aplikacji pod kątem odporności
Ochrona przed DDoS nie kończy się na firewallach i WAF. Architektura samej aplikacji może w znacznym stopniu zwiększyć lub zmniejszyć odporność na gwałtowne skoki ruchu. Dwa systemy o podobnej funkcjonalności mogą reagować zupełnie inaczej na ten sam atak.
Przykładowe kierunki optymalizacji:
odciążenie najdroższych operacji – np. indeksy w bazie danych, pre-kalkulowane agregaty, cache w pamięci dla popularnych zapytań,
asynchroniczne przetwarzanie – przesuwanie ciężkich zadań (generacja raportów, przeliczenia) do kolejek i workerów, a w interfejsie użytkownika prezentowanie statusu zadania,
twarde time-outy i limity rozmiaru zapytań – żeby pojedyncze „złośliwe” żądanie nie blokowało wątku aplikacji przez kilkadziesiąt sekund,
