Przeciążenie strony, API albo całej infrastruktury potrafi zatrzymać biznes szybciej niż wiele innych incydentów, bo klient widzi po prostu niedostępną usługę. W przypadku ataków DDoS problem polega na tym, że ruch wygląda pozornie normalnie, a w praktyce zjada łącze, CPU albo zasoby aplikacji. W tym tekście pokazuję, jak rozpoznać taki scenariusz, czym różnią się jego odmiany i jak zbudować ochronę, która nie kończy się na jednym firewallu.
Najważniejsze informacje w skrócie
- DDoS uderza w dostępność, więc celem jest odcięcie użytkowników od strony, API lub usługi, a nie zawsze kradzież danych.
- Najczęściej spotyka się trzy klasy: wolumetryczną, protokołową i aplikacyjną; każda zostawia inny ślad w logach i na wykresach monitoringu.
- Nagły skok ruchu nie musi oznaczać ataku, ale alarmują powtarzalne żądania, błędy 502/503, wolne odpowiedzi i ruch z wielu źródeł bez konwersji.
- Najlepiej działa ochrona warstwowa: CDN, Anycast, WAF, rate limiting, redundancja DNS i procedura kontaktu z operatorem łącza.
- Na żywo liczy się szybkość reakcji, ale po incydencie ważniejsze jest usunięcie przyczyny, która pozwoliła atakowi się utrzymać.
Czym są ataki DDoS i dlaczego paraliżują usługę
DDoS to rozproszona odmowa usługi. Zamiast jednego komputera atakuje wiele przejętych urządzeń, czyli botnet, który zasypuje cel ruchem sieciowym albo żądaniami HTTP. Skutek jest prosty: legalni użytkownicy nie mogą wejść do sklepu, wysłać formularza, pobrać pliku czy połączyć się z API.
Nie mylę tego z klasycznym włamaniem. Atakujący zwykle nie próbują od razu kraść danych, tylko wyczerpać zasoby tak, by usługa przestała odpowiadać lub działała skrajnie wolno. Skala problemu jest dziś bardzo realna: w 2025 roku Cloudflare raportował 47,1 mln zmitigowanych ataków, a pojedyncze kampanie dochodziły do 31,4 Tbps. To pokazuje, że nawet krótki incydent może być odczuwalny także dla średniej firmy.
Z mojego punktu widzenia najważniejsze jest to, że zjawisko nie ma jednego obrazu. Czasem wygląda jak zwykły skok wejść z kampanii marketingowej, a czasem jak awaria łącza. Dlatego zamiast patrzeć wyłącznie na wolumen, trzeba rozumieć rodzaj ruchu i miejsce, w które celuje.
Jakie typy ataków spotyka się najczęściej
W praktyce rozróżniam cztery główne odmiany. Każda działa trochę inaczej, ale wszystkie mają ten sam efekt końcowy: przeciążenie zasobów po drodze między użytkownikiem a usługą.
| Typ ataku | Na czym polega | Co zwykle widać | Dlaczego jest groźny |
|---|---|---|---|
| Wolumetryczny | Zalewa łącze bardzo dużą ilością pakietów lub odpowiedzi z usług pośrednich. | Spowolnienie całej sieci, timeouty, niedostępność strony mimo sprawnego serwera aplikacji. | Uderza w przepustowość, więc potrafi zatrzymać ruch zanim dotrze do aplikacji. |
| Protokołowy | Wykorzystuje sposób zestawiania połączeń, na przykład SYN flood albo UDP flood. | Wysokie zużycie tabel połączeń, obciążony firewall, problemy z handshake. | Wykańcza urządzenia sieciowe i elementy pośrednie, które mają ograniczoną liczbę stanów. |
| Aplikacyjny | Zasypuje stronę lub API pozornie poprawnymi żądaniami, często do najcięższych endpointów. | Błędy 503, długie odpowiedzi, wyczerpanie CPU lub bazy danych. | Bywa trudniejszy do odróżnienia od legalnych użytkowników, bo ruch wygląda „normalnie”. |
| Wielowektorowy | Łączy kilka metod naraz i zmienia taktykę w trakcie kampanii. | Objawy migrują między warstwą sieci, aplikacji i DNS. | Wymaga obrony warstwowej, bo jeden filtr rzadko wystarcza. |
Warto zapamiętać jedną rzecz: amplifikacja polega na tym, że napastnik wykorzystuje usługi odpowiadające większym pakietem niż zapytanie. To właśnie dlatego taki ruch jest tak niebezpieczny przy małej inwestycji po stronie atakującego.
Znając typ kampanii, łatwiej ocenić, gdzie postawić obronę, ale samą klasyfikację trzeba jeszcze połączyć z obserwacją objawów po stronie serwisu.
Po czym odróżnić atak od zwykłego wzrostu ruchu
Największy błąd to automatyczne uznanie każdego skoku odwiedzin za atak albo, odwrotnie, zlekceważenie sygnałów tylko dlatego, że „strona jeszcze jakoś działa”. Patrzę przede wszystkim na powtarzalność, źródła i to, czy ruch tworzy realną interakcję.
| Objaw | Bardziej przypomina DDoS, gdy... | Bardziej przypomina legalny pik, gdy... |
|---|---|---|
| Źródła ruchu | Widać wiele krajów, ASN albo adresów, które zmieniają się bardzo szybko. | Ruch spływa z jednego kanału, kampanii albo konkretnego partnera. |
| Zachowanie użytkownika | Żądania są powtarzalne, bez sesji, bez koszyka i bez sensownej ścieżki na stronie. | Rośnie czas na stronie, liczba odsłon i faktyczne konwersje. |
| Objawy techniczne | Rosną 502, 503, timeouts, load balancer się dusi, a origin odpowiada coraz wolniej. | Serwis działa wolniej, ale nie pęka na poziomie infrastruktury. |
| Ślad w logach | Tysiące identycznych żądań trafia w jeden endpoint, często z tym samym user-agentem lub bez cookies. | Widać rozproszone wejścia i naturalne przejścia między podstronami. |
Jeśli w logach powtarzają się te same ścieżki, identyczne parametry i brak normalnej interakcji, to zwykle nie jest przypadek. Wtedy nie czekam, aż sytuacja „sama minie”, tylko przechodzę do reakcji operacyjnej.
To dobry moment, żeby uporządkować działania krok po kroku, bo przy DDoS improwizacja zwykle kosztuje najwięcej.
Co zrobić od razu, gdy strona przestaje odpowiadać
W pierwszych minutach liczy się nie heroizm, tylko dyscyplina. Najpierw potwierdzam zakres problemu, a dopiero potem zaostrzam reguły ochronne, bo chaotyczne blokowanie ruchu potrafi pogorszyć dostępność bardziej niż sam atak.
- Sprawdź, co dokładnie pada. Oddziel stronę, API, DNS, panel administracyjny i pocztę. Często awaria dotyczy tylko jednego elementu, a nie całej infrastruktury.
- Włącz ochronę na krawędzi. Jeśli masz CDN, WAF albo mechanizmy rate limiting, zaostrz je na najbardziej obciążonych endpointach.
- Przenieś filtrację wyżej. Poproś hosting lub operatora łącza o filtrowanie upstream, bo lokalny firewall nie zawsze wytrzyma zalew pakietów.
- Odciąż origin. Wyłącz kosztowne funkcje, które mocno obciążają bazę danych, wyszukiwanie czy generowanie plików, a jeśli możesz, pokaż statyczny fallback.
- Zachowaj logi i ślady. Nie kasuję danych z pośpiechu, bo później trudno ustalić źródło, wektor i czas trwania incydentu.
- Komunikuj status jasno. Krótka informacja o problemie i szacowanym czasie reakcji zwykle działa lepiej niż długie milczenie.
Warto też pamiętać, że DDoS może być zasłoną dymną dla innego incydentu. Jeśli jednocześnie widać nietypowe logowania, zmiany konfiguracji albo błędy uprawnień, traktuję to jak szerszy problem bezpieczeństwa.
Po opanowaniu pożaru trzeba zająć się architekturą, bo bez tego kolejny incydent wróci tą samą drogą.
Jak zbudować ochronę, która działa warstwowo
Jak przypomina NASK, klasyczne NGFW czy IPS nie rozróżniają dobrze rozległego zalewu wolumetrycznego od legalnego ruchu, dlatego obrona powinna zaczynać się możliwie blisko krawędzi sieci. Ja myślę o niej jak o systemie warstw: jedna technika ma zatrzymać ruch, druga go odfiltrować, trzecia ograniczyć kosztowne żądania.
| Warstwa ochrony | Co daje | Ograniczenie | Kiedy ma największy sens |
|---|---|---|---|
| CDN i Anycast | Rozpraszają ruch i buforują treści, więc origin nie dostaje wszystkiego na raz. | Nie uratują źle zoptymalizowanej aplikacji, jeśli każdy request i tak trafia do bazy. | Przy stronach publicznych, mediach, e-commerce i serwisach z dużą ilością statycznych treści. |
| WAF i bot management | Filtrują ruch HTTP, wykrywają automatyzację i blokują podejrzane wzorce. | Wymagają strojenia pod konkretną aplikację, bo zbyt sztywne reguły potrafią blokować klientów. | Przy logowaniu, formularzach, API i checkoutach. |
| Rate limiting | Ogranicza liczbę żądań na IP, token, sesję lub endpoint. | Przy złych progach może utrudnić życie także prawdziwym użytkownikom. | Na kosztownych operacjach, takich jak wyszukiwanie, reset hasła czy autoryzacja. |
| Redundancja DNS i origin | Zmniejsza ryzyko, że jeden punkt awarii odetnie cały serwis. | Nie zastępuje ochrony przed zalaniem łącza. | Gdy dostępność jest krytyczna i serwis nie może zależeć od jednego miejsca publikacji. |
| Usługa upstream lub scrubbing | Czyści ruch zanim dotrze do infrastruktury klienta. | Trzeba mieć ją uzgodnioną i przetestowaną wcześniej, a nie dopiero podczas kryzysu. | W firmach, które obsługują większy wolumen ruchu albo są narażone na kampanie wolumetryczne. |
Najlepiej działa zestaw, który łączy cache statycznych zasobów, limity na newralgicznych endpointach i prosty mechanizm przełączenia awaryjnego. Dla sklepu internetowego oznacza to zwykle ochronę checkoutu, logowania i wyszukiwania; dla API - osobne limity na klucze, metody i ścieżki.
Jeśli wszystko trzyma się jednego serwera i jednego łącza, ochrona jest tylko etykietą. Skoro tak, warto też wiedzieć, jakie błędy najczęściej psują nawet dobrą technicznie architekturę.
Jakich błędów unikać, żeby nie ułatwiać pracy napastnikom
Najdroższe w DDoS nie są same pakiety, tylko złe decyzje operacyjne. Widziałem zbyt wiele przypadków, w których problem eskalował nie przez siłę ataku, ale przez to, że obrona była spóźniona, zbyt szeroka albo po prostu nieprzetestowana.
- Ochrona uruchomiona dopiero po incydencie. Jeśli polityki, DNS i kontakt do operatora są przygotowane na gorąco, tracisz cenne minuty.
- Brak ukrycia origin za CDN. Publiczny adres serwera daje napastnikowi prosty cel i omija część filtracji.
- Zbyt agresywne blokady geograficzne. Czasem pomagają na chwilę, ale potrafią odciąć płacących klientów i partnerów.
- Za niskie limity na logowanie i API. Dobre do obrony, złe do sprzedaży, jeśli nie są dopasowane do realnego ruchu.
- Brak ćwiczenia procedury. Jeśli zespół pierwszy raz widzi playbook podczas awarii, to nie jest playbook, tylko dokument.
- Zakładanie, że DDoS niczego nie maskuje. To błąd szczególnie niebezpieczny w środowiskach z danymi wrażliwymi i panelem administracyjnym.
Każdy z tych błędów da się ograniczyć, ale tylko wtedy, gdy ktoś faktycznie odpowiada za dostępność, a nie tylko za samą konfigurację bezpieczeństwa. I właśnie od tego zależy, czy firma wyjdzie z incydentu po godzinie, czy po całym dniu przestoju.
To prowadzi do ostatniej rzeczy, którą warto zrobić jeszcze przed pierwszym uderzeniem: ustawić prosty, realny plan działania dla własnej organizacji.
Co wdrożyć zanim pierwszy incydent sparaliżuje usługę
Jeśli miałbym wybrać minimum dla firmy działającej w Polsce, zacząłbym od czterech rzeczy: warstwy CDN/WAF, limitów na najdroższych endpointach, monitoringu 5xx i czasu odpowiedzi oraz kontaktu eskalacyjnego do operatora łącza. To jest zestaw, który nie wygląda efektownie, ale właśnie on najczęściej robi różnicę między krótkim incydentem a wielogodzinnym przestojem.
- Ustal, które zasoby muszą działać zawsze. Dla e-commerce będą to zwykle strona główna, koszyk, logowanie i płatność.
- Przygotuj plan awaryjny publikacji. Statyczna strona statusowa i uproszczony komunikat potrafią utrzymać zaufanie lepiej niż chaos.
- Włącz monitoring na poziomie infrastruktury i aplikacji. Same liczby odsłon nie wystarczą, jeśli nie widzisz opóźnień, błędów 5xx i obciążenia origin.
- Przećwicz decyzje operacyjne. Kto może obniżyć limity, kto kontaktuje hosting, kto informuje klientów i kto decyduje o przełączeniu trybu awaryjnego.
- Oddziel to, co publiczne, od tego, co krytyczne. Panel administracyjny, API i front serwisu nie powinny mieć identycznej ekspozycji w sieci.
W praktyce najważniejsze jest to, by obrona była gotowa przed ruchem, a nie podczas niego. Gdy dostępność jest elementem przychodu albo reputacji, inwestycja w warstwy ochronne zwykle zwraca się szybciej niż rozbudowa samej mocy serwera.
