Jak rozpoznać, że właśnie trwa atak DDoS na twoją infrastrukturę

Cel administratora: szybka diagnoza i oddzielenie szumu od ataku

Celem rozsądnego administratora nie jest zbudowanie idealnie odpornej infrastruktury, tylko jak najszybsze wychwycenie, że dzieje się coś nienormalnego, oraz podjęcie decyzji: „to DDoS” czy „zwykły problem u nas”. Im szybciej rozpoznasz symptomy ataku DDoS, tym mniej pieniędzy stracisz na przerwach w działaniu usług, nadgodzinach i gorączkowym gaszeniu pożaru.

Najtańsza i najbardziej efektywna strategia to wdrożenie prostych, powtarzalnych metod monitoringu i kilku jasnych progów alarmowych, które odróżniają typowe skoki ruchu od realnego ataku rozproszonego. Większość narzędzi, które do tego wystarczą, już masz: logi, panel hostingu, podstawowy monitoring i dostęp do routera lub firewalla.

Czym jest atak DDoS w praktyce administratora

Krótkie uporządkowanie pojęć: DoS vs DDoS

DoS (Denial of Service) to atak mający na celu uniemożliwienie działania usługi. Kluczowe jest tu przeciążenie zasobów: łącza, serwera, aplikacji lub bazy danych. W wersji klasycznej DoS ruch pochodzi z jednego źródła (jedna maszyna, jedna podsieć). W wersji DDoS (Distributed Denial of Service) atak realizowany jest równocześnie z wielu miejsc w internecie: botnetów, zainfekowanych urządzeń IoT, serwerów VPS, czasem z przejętych kont w chmurze.

Z punktu widzenia właściciela małej lub średniej infrastruktury rozróżnienie na DoS i DDoS ma mniejsze znaczenie niż mogłoby się wydawać. Dla biznesu liczy się efekt: usługa nie działa, użytkownicy nie mogą się zalogować, sklep nie przyjmuje zamówień. Sposób generowania ruchu (jeden host czy tysiące) wpływa głównie na to, jak trudno będzie atak odfiltrować, ale pierwsze symptomy w logach i monitoringu są bardzo podobne.

W codziennej pracy administracyjnej trafniejsze jest patrzenie na to, który zasób jest przyduszony i na jakim poziomie OSI jest problem:

• warstwa sieciowa (L3/L4) – duszone jest łącze, router, firewall,
• warstwa aplikacyjna (L7) – duszone są konkretne endpointy HTTP, logika aplikacji, baza danych.

Do reakcji na incydent kluczowe jest szybkie ustalenie, czy masz do czynienia z atakiem na łącze/protokół, czy z atakiem na aplikację. Od tego zależy, gdzie szukać pierwszych dowodów i jakich narzędzi dotknąć w pierwszej kolejności.

Najczęstsze cele atakujących w realnych incydentach

Atak DDoS nie zawsze ma na celu całkowite wyłączenie usługi. Z biznesowego punktu widzenia równie bolesne bywa mocne spowolnienie lub niestabilność, która odstrasza użytkowników i psuje reputację serwisu. Typowe intencje atakujących to:

• Pełne wyłączenie usługi – łącze lub serwer są tak obciążone, że nic nie odpowiada; monitoring zgłasza niedostępność, użytkownicy dostają timeouty.
• Degradacja jakości – strona otwiera się 10–30 sekund, część żądań zwraca błędy 5xx, koszyk nie przechodzi dalej, sesje się zrywają.
• Odciągnięcie uwagi od innego ataku – w tle ktoś próbuje włamać się do panelu administracyjnego, serwera baz danych lub przeprowadzić atak na aplikację (SQLi, RCE). Zespół skupia się na „gaszeniu DDoS”, a prawdziwy problem dzieje się obok.
• Szantaż lub „pokaz siły” – scenariusz „zapłać, bo inaczej włączymy większy wolumen”. W takich przypadkach DDoS bywa impulsowy, powtarzalny, często poprzedzony kontaktem mailowym.

W praktyce wiele incydentów zaczyna się od scenariusza degradacji: system jeszcze „jakoś działa”, ale UX jest koszmarny. W tej fazie masz największą szansę na szybką reakcję – jeżeli umiesz odróżnić zwykły peak od symptomów ataku DDoS.

Typowe wektory ataków: wolumen, protokół, aplikacja

Teoretycznych kategorii ataków jest wiele, ale dla szybkiej diagnozy wystarczy proste rozróżnienie na trzy typy, które generują różne symptomy.

Ataki wolumetryczne (na przepływność)

Atakujący próbuje „zatkać rurę”, czyli:

• generuje ogromne ilości ruchu (Mb/s–Gb/s) w kierunku twojego IP lub całej puli,
• wykorzystuje protokoły łatwe do amplifikacji (UDP, ICMP, DNS, NTP, SSDP),
• celuje w nasycenie łącza u ciebie lub u dostawcy.

W praktyce oznacza to, że nawet jeśli serwery mają jeszcze zasoby CPU/RAM, to ruch z internetu fizycznie się nie przebija, a użytkownicy widzą timeouty. W monitoringach sieciowych pojawiają się skoki ruchu o rząd wielkości ponad typową dzienną wartość.

Ataki na protokoły (L3/L4)

Tu ruch jest mniej masowy, ale skrojony tak, aby dusić infrastrukturę na poziomie stosu sieciowego:

• SYN flood – masa półotwartych połączeń TCP, które zjadają tablice stanów na firewallu i serwerach.
• UDP flood – mnóstwo pakietów UDP na konkretny port lub losowe porty, obciążające firewall i router.
• ICMP flood – nadmiar echo requestów i podobnych pakietów ICMP.

Objawem jest przede wszystkim wyczerpywanie się zasobów pośredniczących (routery, firewalle, load balancery), rośnie liczba stanów, CPU takich urządzeń skacze w górę, zaczynają pojawiać się opóźnienia i dropy.

Ataki aplikacyjne (L7)

W atakach na poziomie aplikacji atakujący nie musi generować gigantycznego ruchu. Wystarczy, że:

• uderzy w ciężkie endpointy (np. wyszukiwarka, raporty, eksporty),
• zainicjuje dużo pełnych sesji HTTP(S) z pozornie poprawnymi nagłówkami,
• będzie symulował zachowanie użytkownika, ale w nienaturalnie dużym wolumenie.

Z perspektywy hostingu ruch może wyglądać „normalnie”, za to aplikacja i baza danych są na granicy wytrzymałości. Logi HTTP rosną w tempie kilkukrotnie większym niż zwykle, rośnie czas odpowiedzi, kolejki w aplikacji przestają się opróżniać.

Co w praktyce „widzisz” jako administrator

Bez względu na techniczne niuanse ataku DDoS, w codziennym życiu administrator widzi głównie:

• Alarmy monitoringu – wzrost czasu odpowiedzi, niedostępność hostów, przekroczone progi CPU/RAM, utrata pakietów.
• Skargi użytkowników – support raportuje błędy 502/503, „strona mieli w nieskończoność”, „logowanie nie przechodzi”.
• Anomalie w ruchu – nagłe skoki przepustowości, liczby połączeń, nietypowe rozkłady ruchu na portach lub endpointach.
• Problemy z infrastrukturą pośrednią – tablice stanów firewalli dochodzą do limitu, router zaczyna dropować pakiety, WAF sygnalizuje przekroczenie limitów.

Rozpoznanie ataku DDoS to przede wszystkim wyłapanie tych anomalii i umiejętność powiązania ich z zachowaniem użytkowników oraz kalendarzem biznesowym (kampanie marketingowe, promocje, sezony). Tu zaczyna się praktyczna diagnostyka.

Typowe objawy trwającego ataku DDoS – obraz z lotu ptaka

Jak wygląda dzień, w którym „coś” zaczyna się sypać

Wiele ataków DDoS zaczyna się z pozoru niewinnie. Ktoś z obsługi klienta przekazuje informację, że kilku użytkowników ma problem z logowaniem. Ktoś inny zgłasza, że koszyk w e‑sklepie nie przechodzi do płatności. Ty sprawdzasz monitoring: wszystko lekko „na żółto”, ale jeszcze nie „na czerwono”.

Po kilkunastu minutach:

• czas odpowiedzi serwera wzrasta dwukrotnie lub trzykrotnie,
• procent błędów HTTP 5xx skacze w górę,
• liczba aktywnych sesji gwałtownie rośnie, choć nie ma planowanej kampanii ani wysyłki newslettera.

Równolegle w panelu hostingu lub na routerze widzisz nagły wzrost ruchu sieciowego. Niekoniecznie astronomiczny, ale wyraźnie odbiegający od codziennego „szumu”. Jeżeli Twoje narzędzia mają proste alerty, zaczynają sypać mailami lub powiadomieniami.

Ten moment jest kluczowy. Wtedy trzeba na chłodno odpowiedzieć na pytanie: czy to „zwykłe zwiększone obciążenie”, czy symptomy ataku DDoS? Później, kiedy wszystko już leży, wiele śladów będzie trudniejszych do analizy, a presja czasu większa.

Nagłe problemy użytkowników: błędy 502/503 i timeouty

Jednym z pierwszych sygnałów, że coś dzieje się nie tak, jest wzrost liczby błędów po stronie serwera widocznych z perspektywy użytkownika:

• błędy 502 Bad Gateway – problemy na poziomie reverse proxy lub load balancera,
• błędy 503 Service Unavailable – aplikacja lub backend nie wyrabiają z obsługą,
• długie czasy oczekiwania zakończone timeoutem przeglądarki lub klienta API.

Jeśli błędy 5xx pojawiają się masowo i nagle, bez wdrożeń, zmian w kodzie czy migracji baz danych w ostatnich minutach lub godzinach, jest to poważny kandydat na objaw ataku DDoS. Oczywiście 5xx mogą pojawić się też z powodu błędu w aplikacji, ale wtedy zwykle:

• liczba błędów rośnie bardziej stopniowo,
• pojawia się korelacja z konkretnym wdrożeniem,
• nie towarzyszy temu nienaturalny wzrost ruchu na poziomie sieci.

Dla szybkiej weryfikacji dobrze jest mieć pod ręką choćby prosty dashboard z informacją o:

• procentowym udziale błędów 5xx w ruchu,
• średnim czasie odpowiedzi,
• liczbie requestów na sekundę.

Nawet darmowe rozwiązania typu grafana z Prometheusem, darmowe plany zewnętrznych monitoringów HTTP czy proste skrypty zbierające metryki z Nginxa/Apacza są tu ogromnym ułatwieniem.

Duży spadek dostępności bez zmian w kodzie

Charakterystyczną cechą ataku DDoS jest brak logicznego powodu biznesowego lub technicznego dla nagłego spadku dostępności. Przykładowe symptomy:

• uptime serwisu spada z 99–100% do 80–90% w ciągu kilkudziesięciu minut,
• syntetyczne testy z kilku lokalizacji świata zaczynają zgłaszać losową niedostępność,
• nie ma w tym czasie żadnych wdrożeń, zmian DNS, aktualizacji systemu czy świadomych restartów.

Jeżeli równocześnie nie uruchomiono dużej kampanii marketingowej, nie otwarto zapisów na popularne wydarzenie i nie widać naturalnego źródła zwiększonego ruchu, scenariusz DDoS staje się bardzo prawdopodobny.

W takich sytuacjach dobrze działa prosta checklista „zdrowego rozsądku”:

• Czy było planowane wdrożenie w ostatnich 1–2 godzinach?
• Czy zespół marketingu uruchamiał coś dużego (kampania, promocja, mailing)?
• Czy były zmiany w DNS, certyfikatach SSL, konfiguracji reverse proxy?
• Czy dostawca hostingu lub ISP raportuje awarię po swojej stronie?

Jeśli na wszystkie pytania odpowiadasz „nie”, a obciążenie nagle rośnie – trzeba szukać symptomów ataku DDoS w logach i na urządzeniach sieciowych.

Wzrost ruchu w sieci bez proporcjonalnego wzrostu w aplikacji

Przy atakach na poziomie L3/L4 często widać specyficzną anomalię: ruch sieciowy rośnie, ale logi aplikacji nie rosną proporcjonalnie. Przykładowo:

• na routerze/hostingu widzisz podwojenie lub potrojenie ruchu przychodzącego,
• liczba pakietów na sekundę (PPS) rośnie znacząco,
• w logach HTTP ruch jest tylko nieznacznie większy niż zwykle.

Taki rozjazd oznacza, że znaczna część pakietów nie dociera do warstwy aplikacyjnej – jest dropowana na firewallu, w kernelu, w load balancerze lub wykorzystuje protokoły, których aplikacja w ogóle nie loguje (np. ICMP, niektóre typy UDP). To typowy objaw wolumetrycznego lub protokołowego DDoS.

Przykład e‑sklepu: promocja czy już DDoS?

Realistyczny scenariusz z życia małej firmy: e‑sklep ogłasza jednodniową promocję z darmową dostawą. Ruch naturalnie rośnie – spodziewane są 2–3 razy większe obciążenia. Administrator przygotował się: lekkie skalowanie, monitoring, trochę wyższe limity.

W pewnym momencie:

• ruch rośnie nie 2–3, a 10 razy,

Nietypowa struktura ruchu: dużo wejść, mało sensownych akcji

Przy atakach aplikacyjnych sytuacja często wygląda tak, jakby „wszyscy weszli na stronę i od razu wyszli” albo wykonywali tylko jedną, specyficzną akcję. W praktyce oznacza to, że:

• gwałtownie rośnie liczba żądań do jednego lub kilku endpointów (np. /search, /api/report, /wp-login.php),
• spada udział „zdrowych” ścieżek użytkownika – mniej jest przejść między typowymi podstronami,
• logi pokazują wiele requestów zakończonych przedwcześnie (np. brak dalszej nawigacji, brak dodania produktu do koszyka).

Naturalny ruch jest „szumiący”: użytkownicy klikają w różne miejsca, przewijają, wracają. W DDoS-ie aplikacyjnym widzisz tunel – ogromny ruch na jeden typ zapytania, często dodatkowo z powtarzalnymi parametrami. To ważny sygnał zwłaszcza wtedy, gdy kampanii marketingowej towarzyszy nienaturalnie wysoki odsetek przerwanych sesji.

Twarde wskaźniki z sieci – co sprawdzić jako pierwsze

Przepustowość (bps) kontra liczba pakietów (pps)

Większość paneli hostingu czy routerów pokazuje głównie megabity na sekundę. Przy DDoS-ie równie ważne – a czasem ważniejsze – jest to, ile pakietów na sekundę przechodzi przez interfejsy. Typowy schemat szybkiej weryfikacji:

• jeśli rosną bity i pakiety – najpewniej masz do czynienia z wolumetrycznym zalaniem (L3/L4 lub L7),
• jeśli bps jest średni, ale pps wystrzelił – ktoś może celować w tablice stanów, CPU routera lub firewalla małymi pakietami,
• jeśli bps skoczył ekstremalnie, a pps wygląda „normalnie” – możliwy jest atak dużymi pakietami (np. amplifikacja UDP).

Na routerach klasy SOHO czy tańszych firewallach podstawowe statystyki pokaże już prosty SNMP zebrany do Prometheusa lub Zabbixa. To jeden z najtańszych sposobów, żeby mieć podgląd, czy ruch jest „duży bo duży”, czy „duży bo rozdrobniony w pakietach i tłucze CPU”.

Wykorzystanie tablic stanów na firewallach

Każdy stateful firewall utrzymuje tablicę stanów połączeń. Przy SYN floodach i podobnych atakach zobaczysz tam gwałtowny wzrost liczby sesji. Praktyczne kroki:

• sprawdź liczbę aktywnych stanów i porównaj ją z typową wartością w godzinach szczytu,
• zobacz, czy nie pojawiają się komunikaty o osiąganiu limitu sesji lub odrzucaniu nowych połączeń,
• jeżeli sprzęt to umożliwia – zweryfikuj, z jakich adresów IP lub podsieci pochodzi większość nowych stanów.

Przy braku zaawansowanych narzędzi wystarczy nawet SSH na firewall i kilka komend pokazujących statystyki połączeń. W środowiskach z mniejszym budżetem to często najszybsze źródło prawdy, zanim support ISP odpowie na zgłoszenie.

Top talkers i top ports – kto i gdzie „mówi” najgłośniej

Kolejny krok to spojrzenie na to, kto generuje ruch i na jakie porty. Nawet proste narzędzia jak iftop, nethogs, statystyki Netflow/sFlow lub raporty z panelu hostingu dadzą podstawowy obraz:

• dominacja jednego kraju lub AS-a może wskazywać na botnet albo źle skonfigurowany scrapper,
• nagły wysyp ruchu na portach, które zwykle „świecą się” lekko (np. 53/UDP, 123/UDP), bywa oznaką ataku amplifikacyjnego,
• rozkład łączących się adresów: wiele IP z różnych krajów (klasyczny DDoS) vs setki IP z jednej chmury (np. nadużycie darmowych instancji w jednym regionie).

Nie trzeba od razu kupować drogiego systemu Netflow – na start wystarczy eksport z routera do darmowego analizatora, albo nawet jednorazowe odpalenie tcpdump i krótkiej analizy w Wiresharku. Celem jest szybka odpowiedź: czy ruch wygląda jak „prawdziwi ludzie z różnych miejsc”, czy jak „szum” z ograniczonej liczby źródeł.

Asymetria ruchu przychodzącego i wychodzącego

W normalnej pracy serwisu ruch przychodzący i wychodzący różnią się, ale jest między nimi pewna korelacja. Przy typowym DDoS-ie obserwujesz:

• gwałtowny wzrost ruchu przychodzącego przy niewielkiej zmianie ruchu wychodzącego,
• wysyłane są głównie krótkie odpowiedzi błędów (np. 502/503),
• czasem ruch wychodzący wręcz spada, bo infrastruktura przestaje odpowiadać na część żądań.

Taka asymetria jest jednym z prostszych wskaźników, że infrastruktura jest raczej „obijana” niż faktycznie używana. W przypadku całkowitego „zalania” łącza możesz widzieć też dramatyczny spadek ruchu wychodzącego – bo odpowiedzi po prostu się nie przebijają.

Logi firewalli, serwerów i WAF – ślady zostawione przez DDoS

Wzorce odrzucanych połączeń na firewallu

Firewall podczas ataku często krzyczy w logach, zanim jeszcze serwery zaczną się „topić”. Typowe wzorce:

• rosnąca liczba wpisów typu connection limit exceeded, syn proxy, state table full,
• masowe odrzucenia z tych samych podsieci (np. /24, /20),
• nagły wysyp jednego typu pakietów (SYN, UDP, ICMP) do określonych portów lub IP.

Jeżeli logi są rotowane często, opłaca się szybko skopiować ich fragment na bok – przy silnym ataku dzienniki potrafią rosnąć w takim tempie, że przy pierwszym resecie lub restarcie krytyczne informacje znikną.

Serwer WWW: skoki w access logach i dziwne user‑agenty

W logach HTTP widać DDoS aplikacyjny najczęściej po kilku cechach. W praktyce szukasz:

• nagłego wzrostu liczby linii w access logu w krótkim czasie,
• powtarzalnych, nienaturalnie szybkich sekwencji zapytań z jednego IP (lub małej puli IP),
• user‑agentów typu „python-requests”, „curl”, podejrzane biblioteki botów lub wręcz puste nagłówki UA,
• tej samej ścieżki z różnymi losowymi parametrami (omijanie cache).

Nie zawsze trzeba pełnego ELK-a. Na start wystarczy prosty grep lub goaccess odpalony na świeżym fragmencie logu. Chodzi o wyłapanie, czy ruch jest podobny do tego z realnych przeglądarek, czy przypomina ruch generowany skryptem.

Błędy w logach aplikacji: timeouty, blokady, zerwane połączenia

Jeżeli aplikacja ma sensownie ustawione logowanie błędów, w czasie ataku zauważysz tam m.in.:

• wzrost liczby wyjątków typu „timeout”, „connection refused”, „pool exhausted”,
• komunikaty o nieudanych próbach uzyskania połączenia do bazy lub kolejki,
• nagłe pojawienie się błędów limitów (throttling, rate limiting aplikacyjny).

Atak DDoS nie zawsze bezpośrednio generuje błąd w kodzie, ale powoduje, że wszystkie „słabe punkty” (za krótkie timeouty, za małe pule połączeń) wychodzą na wierzch jednocześnie. Jeśli w logach aplikacji widzisz lawinę podobnych błędów w krótkim przedziale czasu, a wcześniej pojawiały się tylko sporadycznie, jest to cenna poszlaka.

WAF: powtarzalne reguły i przekroczone limity

Jeżeli korzystasz z WAF-a (choćby w wersji chmurowej lub open source), podczas ataku aplikacyjnego zobaczysz:

• wyraźny przyrost liczby zadziałanych reguł w krótkim czasie,
• dominację kilku konkretnych ID reguł (np. przekroczenie limitu requestów z jednego IP),
• alarmy dotyczące anomalii w ruchu – nagła zmiana rozkładu metod HTTP, nagłówków, rozmiarów zapytań.

WAF bywa jednym z tańszych sposobów na wczesne wykrycie DDoS-a aplikacyjnego, bo i tak analizuje całość ruchu HTTP. Nawet darmowe plany potrafią pokazać, że liczba „podejrzanych” requestów skoczyła kilkukrotnie w ciągu kilku minut.

Zachowanie aplikacji i bazy danych – kiedy to nie jest „tylko zwykłe obciążenie”

Wyczerpywanie pul połączeń i blokujące się wątki

Przy prawdziwym ruchu użytkowników obciążenie rośnie zwykle płynnie, a pule połączeń (do bazy, cache, kolejki) mają chwile oddechu. W trakcie ataku DDoS aplikacyjnego często widzisz:

• pule połączeń użyte w 100% przez dłuższy czas, bez „zębów” wskazujących na okresowe zwolnienia,
• wątki serwera aplikacyjnego wiszące długo na tych samych operacjach (np. ciężkie zapytania do bazy),
• komunikaty o braku wolnych workerów, procesów PHP-FPM czy wątków serwera.

Nawet proste metryki z Javy (.NET, PHP-FPM) pokażą, że system „dochodzi do sufitu” i nie jest w stanie obsłużyć więcej żądań, mimo że w normalnym piku nigdy tak nie było. Jeśli jednocześnie nie wdrażałeś nowej wersji aplikacji ani nie zmieniałeś konfiguracji – to znak, że ktoś celowo pcha ruch w najbardziej kosztowne miejsca.

Baza danych: lawina podobnych zapytań i blokady

W logach bazy danych i jej metrykach widać DDoS jako:

• wzrost liczby aktywnych zapytań o podobnej strukturze, wywoływanych znacznie częściej niż zwykle,
• wiązanie się zapytań w długie kolejki, przekraczanie typowego czasu wykonania,
• wzrost liczby blokad (locks) i czekania na zasoby (I/O, logi transakcyjne).

Przykładowo, atakujący „mieli” endpoint wyszukiwarki, który wykonuje ciężkie JOIN-y. W normalnym ruchu takie zapytania pojawiają się raz na kilka sekund, a w czasie ataku – kilkadziesiąt razy na sekundę. Sam ruch HTTP może wyglądać umiarkowanie, ale baza „staje dęba”.

Ciepły cache vs zimna baza – czy cache w ogóle pomaga

Naturalne piki (kampanie, promocje) rzadko kompletnie omijają cache – dużo odpowiedzi jest podobnych (np. strona produktu, landing page). W DDoS-ie aplikacyjnym widzisz często:

• niski hit ratio w cache (Redis, Memcached, CDN),
• ciągłe generowanie dynamicznych odpowiedzi bez trafień z cache,
• duży ruch do bazy mimo pozornie ustawionego cachowania.

Atakujący specjalnie tak dobiera parametry zapytań (np. losowe ID, tokeny, unikalne stringi), żeby każdy request był „nowy” z punktu widzenia cache. Jeśli widzisz, że w momencie problemów hit ratio drastycznie spada, to mocna przesłanka, że ktoś próbuje obejść warstwę odciążającą.

Różnica między „więcej użytkowników” a „te same operacje w kółko”

Przy naturalnym ruchu rośnie nie tylko liczba requestów, ale też rozkład akcji: częściej ktoś się loguje, przegląda, kupuje. W DDoS-ie aplikacyjnym statystyki biznesowe często nie rosną proporcjonalnie. Widzisz np.:

• kilkukrotny wzrost liczby żądań przy niewielkiej zmianie liczby logowań czy zamówień,
• dużo żądań do stron logowania bez realnych udanych logowań,
• masowe „puste” wizyty – wejście i natychmiastowe wyjście z jednego endpointu.

To sygnał, że infrastruktura jest obciążana technicznie, ale nie przekłada się to na aktywność użytkowników. Nawet prosty podgląd w panelu analitycznym (GA, Matomo) w zestawieniu z metrykami serwerowymi może pokazać tę rozbieżność.

Jak odróżnić DDoS od „normalnych” problemów z infrastrukturą

Szybka ścieżka diagnostyczna: kilka prostych pytań

Zamiast od razu wchodzić w głęboką analizę pakietów, najpierw opłaca się przejść krótką ścieżkę decyzyjną. W praktyce sprowadza się to do czterech pytań:

1. Czy w ostatnim czasie były wdrożenia, zmiany konfiguracji lub migracje?
2. Czy marketing uruchomił coś, co mogło nagle zwiększyć ruch?
3. Czy monitoring sieci pokazuje wyraźny skok w bps/pps lub liczbie połączeń?
4. Czy objawy dotyczą głównie jednego serwisu/usługi, czy całej infrastruktury?

Interpretacja odpowiedzi na kluczowe pytania

Same odpowiedzi „tak/nie” jeszcze niczego nie rozstrzygają. Trzeba je zestawić z tym, co pokazuje monitoring i logi.

• Były wdrożenia lub zmiany konfiguracji i dokładnie po nich zaczęły się problemy – w pierwszej kolejności podejrzenie pada na regres w kodzie, złą konfigurację lub błąd w procedurze deployu. DDoS w tym samym momencie jest możliwy, ale mało prawdopodobny bez dodatkowych przesłanek.
• Marketing puścił kampanię, ale:
  • analityka (GA, Matomo) nie widzi adekwatnego wzrostu liczby sesji,
  • dominuje ruch z kilku /24 bez realnych konwersji,
  • większość żądań kończy się na jednym endpointcie (np. /search, /cart),

  wtedy kampania jest tylko zasłoną dymną – ruch wygląda bardziej jak automaty.

• Monitoring sieci pokazuje agresywny skok bps/pps, ale bez wdrożeń i kampanii w tle – to klasyczny scenariusz DDoS, zwłaszcza jeśli:
  • rośnie pps bardziej niż bps (małe pakiety),
  • widzisz szeroką paletę źródeł IP (botnet),
  • blokady na firewallu rosną szybciej niż liczba nowych sesji aplikacyjnych.
• Problem dotyczy jednego serwisu, a pozostałe usługi działają normalnie – tu bardziej podejrzany jest atak „szyty pod aplikację” lub błąd biznesowy (np. jedna z usług ma fatalnie zoptymalizowany endpoint). DDoS wolumetryczny zwykle „kładzie” większy fragment infrastruktury albo całe łącze.

Dopiero po tym szybkim „przesiewie” ma sens schodzić na poziom PCAP-ów i szczegółowej analizy ruchu. Bardzo często już te cztery pytania układają narrację: atak, błąd wewnętrzny albo „sam marketing zaskoczył własnym sukcesem”.

Sygnały wspierające hipotezę „to jednak DDoS”

Kilka cech w zestawieniu dosyć jednoznacznie przesuwa szalę w stronę ataku. Chodzi o charakterystykę ruchu, a nie pojedyncze, wyrwane z kontekstu metryki.

• Szybki start, szybka eskalacja – ruch nie rośnie płynnie przez godziny, tylko „ściana” pojawia się w ciągu minut. Zarówno liczba połączeń, jak i pps/bps idą mocno w górę niemal jednocześnie.
• Brak sezonowości – skok zjawia się w środku „martwego” okresu, gdy normalnie ruch jest niski (np. noc, weekend bez kampanii, nietypowa pora dla twojej branży).
• Dziwna geolokacja – nagle dominują kraje, z których prawie nie masz klientów, a pattern ASN-ów wskazuje na sieci serwerowe/hostingowe, nie konsumenckie.
• Mały wpływ na wskaźniki biznesowe – ruch techniczny rośnie kilkukrotnie, a rejestracje, logowania, transakcje stoją w miejscu lub rosną minimalnie.
• Powtarzalność ścieżek – ogromna część żądań kręci się wokół kilku endpointów, zwykle najcięższych, z setkami niemal identycznych requestów/minutę.
• Równoczesne „dławienie się” kilku warstw – łącze jest blisko saturacji, firewall raportuje limity, serwery aplikacyjne mają 100% CPU, a baza danych dławi się blokadami – wszystko dzieje się w tym samym oknie czasowym.

Im więcej takich sygnałów nakłada się na siebie, tym mniejsza szansa, że to „zbieg okoliczności” czy pojedynczy błąd konfiguracji. Nawet bez kosztownego systemu anty‑DDoS możesz wtedy z dużym prawdopodobieństwem stwierdzić, że jesteś właśnie „na celowniku”.

Wzorce wskazujące na problemy wewnętrzne, a nie atak

Po drugiej stronie są symptomy, które częściej sugerują zwykłe problemy z infrastrukturą, regres w kodzie albo źle oszacowaną pojemność systemu.

• Brak wzrostu ruchu sieciowego – użytkownicy zgłaszają wolne działanie lub błędy, ale:
  • bps/pps na routerach trzyma się w typowych widełkach,
  • liczba nowych połączeń TCP się nie wyróżnia,
  • zewnętrzny monitoring uptime (np. prosty ping/HTTP z zewnątrz) nadal ma dobre czasy odpowiedzi.

  Wtedy problem leży raczej w środku (np. blokująca się baza, uszkodzony storage, wyczerpane zasoby na jednym z serwerów).

• Ścisła korelacja z wdrożeniem – kilka minut po deployu:
  • skacze czas odpowiedzi dla części endpointów,
  • w logach pojawiają się nowe typy błędów,
  • ruch HTTP nadal wygląda normalnie (UA, referrery, kraje) – zmieniła się tylko „zdolność” aplikacji do jego obsługi.

  Tutaj statystycznie częściej winny jest kod niż botnet.

• Ograniczony zakres problemu – np. aplikacja przestaje poprawnie zapisywać dane, ale statyczne pliki serwują się bez zarzutu, API działa, tylko moduł raportowy leży. Atak DDoS rzadko wybiera tak specyficzny, wąski obszar, chyba że jest to precyzyjny atak aplikacyjny.
• Brak charakterystycznych sygnałów w firewallu/WAF‑ie – gdy te warstwy nie widzą anomalii, a problemy raportuje wyłącznie kod aplikacji (np. wyjątki biznesowe, problemy z logiką), bardziej prawdopodobne jest „własne” potknięcie.

Tu działa prosta zasada: jeżeli ruch z zewnątrz wygląda na stabilny, a problemy pojawiają się dopiero głęboko w środku stosu, pierwszy podejrzany to twoja konfiguracja lub nowe funkcje, nie napastnik.

Różne typy DDoS a różne objawy – nie każdy atak wygląda tak samo

Odróżnianie DDoS‑a od zwykłej awarii ułatwia zrozumienie, z jakim typem ataku możesz mieć do czynienia. Każdy z nich zostawia inny „odcisk palca” w infrastrukturze.

• Ataki wolumetryczne (L3/L4) – zalewają łącze lub firewalle:
  • drastyczny wzrost bps/pps, często z wielu krajów i wielu ASN‑ów,
  • routery i firewalle podnoszą CPU, rosną kolejki interfejsów,
  • usługi w środku mogą nawet działać poprawnie, ale świat zewnętrzny nie może się „przebić” przez zatyczone łącze.
• Ataki na protokół (SYN flood, UDP flood) – uderzają w stos TCP/IP:
  • widoczny bardzo wysoki pps przy relatywnie niewielkim bps,
  • mnóstwo niekompletnych sesji w tabeli stanów, komunikaty typu syn cache overflow,
  • serwery aplikacyjne mogą się nudzić, a mimo to dostęp z zewnątrz jest zrywany lub „pływa”.
• Ataki aplikacyjne (L7) – mniejszy wolumen, dużo większy koszt po stronie serwera:
  • ruch sieciowy nie musi bić rekordów,
  • CPU aplikacji i bazy „wystrzela” przy pozornie umiarkowanej liczbie requestów,
  • cache jest omijany, pojawiają się powtarzalne ciężkie operacje (np. raporty, wyszukiwarka, generowanie PDF).

Jeżeli objawy pasują do jednego z tych schematów, a ruch nie ma prostego wytłumaczenia biznesowego, szansa na DDoS rośnie. Z kolei gdy objawy są „rozmyte” i nie wpisują się w żaden typ, warto krytycznie spojrzeć na własną infrastrukturę i ostatnie zmiany.

Jak wykorzystać prosty monitoring do odróżnienia scenariuszy

Nie trzeba od razu kupować drogich rozwiązań, żeby mieć minimalną widoczność. Kilka niedrogich lub darmowych narzędzi daje wystarczający obraz do pierwszej diagnozy.

• Zewnętrzne checki HTTP/ping (np. darmowe plany UptimeRobot, StatusCake):
  • pokazują, czy problem jest globalny, czy dotyczy tylko części użytkowników (np. jednego ISP),
  • logują czasy odpowiedzi i błędy – przy DDoS‑ie wzrost RTT bywa bardzo nagły i powiązany z konkretnymi ścieżkami.
• Podstawowy NetFlow/sFlow (często darmowy w routerze lub switchu):
  • pozwala obejrzeć top rozmówców, top porty i protokoły,
  • widać, czy ruch rozkłada się „po ludzku” między wiele portów/usług, czy wali głównie w jeden kierunek.
• Proste dashboardy CPU/RAM/IO (Zabbix, Prometheus + Grafana, nawet `top` + `sar`):
  • CPU 100% razem z pustą tabelą połączeń i normalnym bps to raczej problem aplikacji niż DDoS,
  • wysokie IO wait bez dużego ruchu zewnętrznego częściej sugeruje problemy ze storage’em.
• Statystyki z CDN/WAF‑a (często w darmowych planach):
  • szybko pokazują nietypowe kraje i AS‑y,
  • widać nagły wzrost odrzuconych lub zrate‑limitowanych zapytań.

Połączenie tych kilku źródeł to „budżetowy SOC” – może nie wytnie automatycznie ataku, ale pozwala w ciągu kilku minut stwierdzić, czy walczysz z DDoS‑em, czy z własnym błędem konfiguracyjnym.

Typowe pułapki diagnostyczne – gdzie łatwo się pomylić

W panice łatwo dopisać atak do każdego incydentu, który jest głośny i nieprzyjemny. Kilka sytuacji szczególnie sprzyja błędnym wnioskom.

• Nowe kampanie bez wcześniejszego load testu – nagły napływ realnych użytkowników potrafi wyglądać jak DDoS. Różnica jest taka, że:
  • analityka pokazuje rosnące sesje i realne interakcje,
  • geolokacja i UA są „zdrowe” (przeglądarki, normalne kraje),
  • ruch nie jest tak powtarzalny jak w ataku skryptami.
• Awaria jednego elementu storage’u lub sieci wewnętrznej – z perspektywy użytkownika „nic nie działa”, więc pierwsze podejrzenie pada na zewnętrzny atak. Monitoring routerów brzegowych jednak nie widzi nietypowego ruchu – czerwone lampki palą się dopiero na poziomie SAN‑u lub hypervisora.
• Źle ustawione limity i throttling – agresywne limity (np. na API) mogą zacząć masowo odrzucać ruch przy naturalnym piku. W logach pojawia się „lawina 429/503”, co wygląda jak obrona przed DDoS‑em, choć w rzeczywistości to infrastruktura sama siebie „dusi”.
• Automatyzacja biznesowa – integracje, roboty RPA, skrypty partnerów. Gdy zaczynają się zapętlać lub działać z błędem, potrafią generować monotonne, wysokie obciążenie do jednego endpointu. Z zewnątrz przypomina to atak aplikacyjny, ale źródło siedzi w zaprzyjaźnionej integracji lub w twoim własnym cronie.

Dobra praktyka to zawsze pytanie: „czy coś po naszej stronie mogło wygenerować taki pattern ruchu?”. Dopiero po uczciwej odpowiedzi można z czystym sumieniem szukać winnego na zewnątrz.

Prosty „drzewkowy” schemat decyzji dla dyżuru nocnego

Gdy incydent łapie cię o 3:00 w nocy, przydaje się prosta procedura, którą da się przejść w kilka minut, nawet z ograniczoną liczbą osób.

1. Sprawdź monitoring łącza i routerów brzegowych:
   • jeśli bps/pps są w normie – szukaj problemów wewnątrz (aplikacja, baza, storage),
   • jeśli jest skok – idź do pkt 2.
2. Sprawdź top źródła i porty (NetFlow, `iftop`, statystyki firewalli):
   • wiele IP z całego świata, jeden/dwa porty – podejrzenie DDoS,
   • kilka konkretnych IP, znane ASN‑y/partnerzy – możliwe, że to błąd po stronie integracji lub robota.
3. Porównaj z analityką biznesową:
   • jeśli ruch techniczny rośnie, a sesje/konwersje nie – bliżej do DDoS,
   • jeśli sesje rosną proporcjonalnie – bardzo możliwe, że to „tylko” sukces marketingu i brak skalowania.
4. Zajrzyj do logów firewall/WAF:
   • masowe zadziałanie jednej reguły, limity, anomalia w metodach HTTP – wspiera hipotezę ataku,
   • cisza w tych warstwach, a problemy tylko w logach aplikacji – szukaj błędu w kodzie/konfiguracji.

Najczęściej zadawane pytania (FAQ)

Jak szybko rozpoznać, że to atak DDoS, a nie zwykły peak ruchu?

Najprostszy test to zestawienie trzech rzeczy naraz: wykresów ruchu, logów aplikacji i kalendarza biznesowego. Jeśli widzisz nagły skok liczby żądań lub przepustowości, jednocześnie rośnie czas odpowiedzi i pojawiają się błędy 5xx, a nie ma żadnej kampanii marketingowej ani „powodu zewnętrznego”, trzeba brać pod uwagę DDoS.

Przy zwykłym peaku (np. po newsletterze) ruch rośnie, ale struktura żądań i zachowanie użytkowników jest typowe: dużo wejść na stronę główną, normalna konwersja. Przy DDoS częściej widać nienaturalne obciążenie pojedynczych endpointów, powtarzalne wzorce IP, dziwne user-agenty lub ruch z nietypowych krajów.

Jakie są typowe objawy trwającego ataku DDoS z perspektywy administratora?

Najczęstsze symptomy to: nagły wzrost czasu odpowiedzi, skok błędów HTTP 5xx, rosnąca liczba aktywnych sesji i „żółte” lub „czerwone” alarmy w monitoringu (CPU, RAM, przepustowość, utrata pakietów). Do tego dochodzą zgłoszenia od supportu: „strona się mieli”, „logowanie nie przechodzi”, „koszyk się wysypuje”.

W narzędziach sieciowych często widać nienaturalny skok ruchu na konkretny port, przepełniające się tablice stanów na firewallu lub routerze i rosnące opóźnienia. Przy atakach aplikacyjnych wykres ruchu może wyglądać „normalnie”, ale logi HTTP rosną kilka razy szybciej niż zwykle, a ciężkie zapytania do bazy praktycznie się nie kończą.

Jak odróżnić atak na łącze (L3/L4) od ataku na aplikację (L7)?

Przy ataku na łącze/protokół typowo „duszą się” routery, firewalle i balansery. Widzisz bardzo wysoki wolumen ruchu (Mb/s, Gb/s), szybkie zapełnianie tablic stanów, CPU urządzeń sieciowych skacze do góry, a użytkownicy zgłaszają głównie timeouty. W logach aplikacji może nie dziać się nic spektakularnego, bo ruch nawet nie dochodzi do serwera WWW.

Przy atakach L7 przepustowość bywa zbliżona do normalnej, za to rośnie liczba żądań HTTP, czasy odpowiedzi i obciążenie bazy danych. Widać powtarzające się uderzenia w konkretne, „ciężkie” endpointy (np. wyszukiwarka, raporty), wiele pełnych sesji HTTPS i gwałtowne powiększanie logów aplikacyjnych.

Jakie progi i alerty ustawić, żeby tanio wykrywać DDoS na czas?

Na początek wystarczą proste, ale sensownie ustawione progi na tym, co już masz: monitoring (np. Zabbix, Prometheus, usługa hostingu), logi HTTP i panel serwera. Dobrym minimum są alerty dla: czasu odpowiedzi (np. 2–3x powyżej średniej), odsetka błędów 5xx, liczby aktywnych sesji, przepustowości łącza oraz liczby nowych połączeń na sekundę.

Żeby nie płacić za rozbudowane systemy, można zacząć od:

• prostych wykresów i alertów mailowych/SMS w narzędziu hostingu,
• skryptów zliczających żądania w logach (np. count IP/endpoint w ciągu 1–5 minut),
• podstawowych limitów na firewallu/WAF (rate limiting) z notyfikacją przy przekroczeniu.

To tani sposób, który w większości małych i średnich środowisk daje wystarczająco wczesny sygnał, że coś jest nie tak.

Czy każdy nagły wzrost ruchu to od razu atak DDoS?

Nie. W wielu firmach największe skoki ruchu pochodzą z własnych działań: kampanii reklamowych, wysyłek newslettera, premier produktów. Kluczowe jest porównanie wykresów z kalendarzem marketingu i sprzedaży. Jeśli wzrost da się wytłumaczyć konkretną akcją, a struktura ruchu wygląda naturalnie, to częściej jest to „legalny” peak.

Jeżeli jednak:

• nie ma żadnego planowanego wydarzenia,
• ruch rośnie skokowo w ciągu minut, a nie godzin,
• duża część żądań kończy się błędami lub timeoutami,
• duży procent ruchu to zapytania do jednego, „ciężkiego” endpointu,

to trzeba założyć scenariusz DDoS i zacząć diagnostykę od warstwy, która pierwsza się dławi (sieć albo aplikacja).

Jakie narzędzia „z pudełka” mogę wykorzystać do diagnozy DDoS bez dużych kosztów?

W większości przypadków wystarczą rzeczy, które już posiadasz. Po stronie systemu: logi serwera WWW (nginx, Apache), statystyki z narzędzi typu netstat/ss, podstawowy monitor zasobów (top, htop, vmstat). Po stronie sieci: panel routera lub firewalla, wykres wykorzystania łącza od operatora lub hostingu.

Dodatkowo przydają się:

• podstawowy monitoring (np. darmowy Zabbix na jednym serwerze, Prometheus + Grafana, albo prosty monitoring dostawcy hostingu),
• skrócone raporty z logów HTTP (np. GoAccess, awstats) do szybkiego podglądu, skąd i na co idzie ruch,
• prostego WAF-a lub moduły limitujące w serwerze WWW (rate limiting, connection limiting).

To wszystko są relatywnie tanie elementy, które da się wdrożyć w kilka godzin, a potrafią zaoszczędzić wiele dni nerwów przy pierwszym poważniejszym ataku.

Co zrobić w pierwszych minutach, gdy podejrzewam atak DDoS?

Najpierw sprawdź, co dokładnie nie działa dla użytkownika: tylko część funkcji (np. logowanie, płatności) czy całość usług. Równolegle rzuć okiem na wykresy: przepustowość łącza, liczbę połączeń, czas odpowiedzi, błędy 5xx. Na tej podstawie spróbuj ustalić, czy problem jest bliżej sieci (L3/L4), czy aplikacji (L7).

Następnie:

• zastosuj szybkie ograniczenia: proste reguły rate limiting na firewallu/serwerze WWW,
• zidentyfikuj najbardziej obciążone endpointy i czasowo je odchudź/wyłącz, jeśli to możliwe,
• skontaktuj się z operatorem/hostingiem, jeśli łącze wygląda na zapchane,
• zapisuj podstawowe obserwacje (godziny, typ ruchu, objawy) – to pomoże przy późniejszym tuningu i ewentualnym zgłaszaniu incydentu.

Te ruchy są szybkie, tanie i często pozwalają przynajmniej ustabilizować sytuację, zanim zaczniesz myśleć o cięższej artylerii typu zewnętrzne usługi anti-DDoS.

Najważniejsze wnioski

• Celem administratora nie jest pełna „niezniszczalność” infrastruktury, tylko szybkie rozpoznanie, czy problem to DDoS czy zwykła awaria – im szybciej zapadnie ta decyzja, tym mniej kosztów biznes poniesie.
• Niedrogi i skuteczny model obrony opiera się na prostym monitoringu, jasnych progach alarmowych i wykorzystaniu tego, co już jest pod ręką: logów, panelu hostingu, podstawowego monitoringu, routera/firewalla.
• Z perspektywy małej/średniej infrastruktury podział na DoS i DDoS ma drugorzędne znaczenie – kluczowe jest ustalenie, który zasób jest przyduszony (łącze, firewall, aplikacja, baza) i na jakiej warstwie OSI leży problem.
• Atak DDoS nie zawsze „wycina” usługę do zera – często tylko mocno ją spowalnia lub czyni niestabilną, co biznesowo bywa równie dotkliwe (np. koszyk w sklepie przestaje przechodzić dalej, choć strona jeszcze się otwiera).
• Najczęstsze wektory ataków to: wolumetryczne (zapchanie łącza dużym ruchem), na protokoły L3/L4 (SYN/UDP/ICMP flood duszący routery i firewalle) oraz aplikacyjne L7 (masowe, „normalne” żądania w ciężkie endpointy, zabijające aplikację i bazę).
• W atakach wolumetrycznych widać nagły skok transferu o rząd wielkości, w atakach na protokół – rosnącą liczbę stanów i CPU na firewallu/routerze, a przy atakach L7 – lawinowy przyrost logów HTTP, wydłużenie czasu odpowiedzi i zapychające się kolejki aplikacji.

Źródła informacji

• NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Zarządzanie incydentami, rozpoznawanie i obsługa ataków DoS/DDoS
• NIST Special Publication 800-184: Guide for Cybersecurity Event Recovery. National Institute of Standards and Technology (2016) – Reakcja i odzyskiwanie po incydentach, w tym atakach DDoS
• DDoS Quick Guide. European Union Agency for Cybersecurity ENISA (2017) – Przegląd typów ataków DDoS, skutków biznesowych i podstawowych środków obrony