Anatomia DDoS od strony wydajności: jak przygotować infrastrukturę, by przetrwać atak

Co właściwie zabija serwis podczas DDoS? Perspektywa wydajności

Warstwy, które padają jako pierwsze

DDoS z perspektywy wydajności rzadko jest jednorodnym zjawiskiem. Najczęściej wygląda jak sekwencja awarii: najpierw przestaje wyrabiać jedna warstwa, potem kolejne „pękają” kaskadowo. Z punktu widzenia architekta ważne jest precyzyjne wskazanie, która warstwa jest pierwszym punktem krytycznym – inaczej każda inwestycja w ochronę będzie częściowo losowa.

Typowy łańcuch wygląda tak: pasmo / urządzenia brzegowe → load balancer → serwery aplikacyjne → baza danych / cache. Atak volumetryczny potrafi zatrzymać ruch już na styku z operatorem (wyczerpanie pasma lub limitów PPS – packets per second). Z kolei atak protokołowy lub aplikacyjny zazwyczaj przechodzi przez sieć, ale dobija load balancer, pulę socketów lub wątki workerów aplikacji, zanim jeszcze dojdzie do bazy.

Punkt kontrolny: spróbuj odpowiedzieć jednym zdaniem, co w twojej architekturze padnie jako pierwsze przy 10x zwykłego ruchu. Jeśli odpowiedź brzmi „nie wiem”, to sygnał ostrzegawczy – obrona przed DDoS-em jest wtedy bardziej zgadywanką niż świadomą strategią.

Zasoby krytyczne: CPU, RAM, sockety, kolejki

Większość ataków DDoS z perspektywy wydajności sprowadza się do wyczerpania czterech grup zasobów: CPU, pamięci, socketów sieciowych i kolejek (na różnych poziomach). Każdy z nich ma swoje specyficzne objawy, a brak świadomości, który zasób jest realnym wąskim gardłem, prowadzi do błędnych decyzji – np. skalowania horyzontalnego, gdy ograniczeniem jest i tak liczba połączeń do bazy.

CPU pada zwykle przy ciężkich operacjach aplikacyjnych lub kryptograficznych (np. brak TLS offload, kosztowne serializacje, złożone zapytania). Objawy: stabilnie wysoki poziom użycia, rosnące czasy odpowiedzi dla wszystkich typów zapytań, thread pool na 100% zajętości.

RAM jest zabijany przez utrzymywanie dużej liczby otwartych połączeń (keep-alive bez limitów), duże obiekty w pamięci, brak limitów na request body, lub nieograniczone kolejki. Objawy: wzrost zużycia pamięci do maksimum, pojawienie się swapu, a w skrajnych przypadkach OOM killer zabijający procesy aplikacyjne albo bazy.

Sockety i porty efemeryczne to zasoby systemowe, które przy floodach TCP/HTTP mogą skończyć się szybciej niż CPU. Objawy: rosnąca liczba połączeń w stanach SYN-RECV, TIME-WAIT, FIN-WAIT, błędy „too many open files”, „connection refused”, spadek liczby nowych akceptowanych połączeń na sekundę.

Kolejki (w load balancerach, brokerach, workerach, wątkach aplikacyjnych) są ostatnią linią amortyzującą burst ruchu. Gdy są źle skonfigurowane (za długie lub bez limitów), skutkują gigantyczną latencją i wyczerpaniem pamięci; gdy są zbyt krótkie – szybkim odrzucaniem ruchu nawet przy umiarkowanym obciążeniu.

Jeśli wiadomo, czy ograniczeniem jest CPU, RAM, sockety czy kolejki, można świadomie dobierać obronę (np. agresywne timeouty i limity połączeń vs. caching i uproszczenie logiki). Jeśli brakuje tej wiedzy, typową reakcją jest „dodawanie serwerów”, co przy złym miejscu wąskiego gardła niczego nie rozwiązuje.

Jak przeciążenie wygląda na poziomie TCP/IP i aplikacji

Atak DDoS w metrykach sieciowych nie wygląda jak zwykły „wysoki ruch”. Na poziomie TCP/IP pojawiają się symptomy, które rzadko występują przy legalnych skokach obciążenia. To dobry materiał na checklistę diagnostyczną.

• SYN backlog – przy SYN flood backlog nasłuchującego gniazda zapełnia się, rośnie liczba niekompletnych handshake’ów, a nowe połączenia są odrzucane, mimo że CPU jeszcze „ma oddech”.
• TIME-WAIT / CLOSE-WAIT – przy dużej liczbie krótkich połączeń lub nadużywaniu keep-alive rośnie liczba socketów w stanach końcowych, blokując porty efemeryczne. To klasyczny sygnał ostrzegawczy dla ataków L4/L7.
• Kolejki w load balancerze – w metrics LB (np. ELB, Nginx, HAProxy) rośnie liczba connection queue / request queue, przy jednoczesnym utrzymaniu się części backendów w stanie „healthy”. To wskazuje, że LB jest już wąskim gardłem, a nie same serwery.

Na poziomie aplikacji przeciążenie widać jako rosnącą latencję (p95/p99), zwiększony odsetek błędów 5xx, wzrost liczby restartów procesów, oraz gwałtowne obniżenie throughputu (RPS przestaje rosnąć mimo zwiększania się liczby prób). Przy DDoS aplikacyjnym często widać, że tylko wybrane endpointy (np. logowanie, wyszukiwanie) mają dramatyczny wzrost obciążenia, a reszta pozostaje w normie.

Jeśli metryki TCP/IP i LB są monitorowane, a alerty zdefiniowane na stanach backlog/kolejek, łatwiej zatrzymać atak zanim dotrze do warstwy aplikacyjnej. Gdy obserwowane są wyłącznie błędy 5xx i CPU, reaguje się zbyt późno – na etapie już realnej niedostępności.

Różnica między „wysokim ruchem marketingowym” a DDoS

Silna kampania marketingowa i dobrze zorganizowany atak DDoS mogą w surowych liczbach wyglądać podobnie – gwałtowny wzrost RPS, wysoka liczba równoległych połączeń. Różnią się jednak wzorcem obciążenia i kosztu obsługi pojedynczego requestu. Rozdzielenie tych scenariuszy to podstawowy warunek, by nie blokować legalnych klientów.

Legalny ruch ma zwykle:

• wyraźne korelacje – np. więcej odsłon strony głównej, rozkład urządzeń i geolokalizacji zgodny z historią, naturalny rozkład referrerów,
• zróżnicowanie ścieżek – użytkownicy wchodzą na różne podstrony, wykonują różne akcje, liczba requestów na sesję jest relatywnie stała,
• maksymalny poziom RPS ograniczony przez realnych użytkowników – rośnie w granicach zdrowego rozsądku.

Atak DDoS (szczególnie aplikacyjny) charakteryzuje się natomiast:

• monotonią – ekstremalna koncentracja na kilku endpointach (np. /login, /search, /api/auth),
• nieproporcjonalnym kosztem – endpointy najbardziej obciążone są jednocześnie najdroższe w obsłudze (złożone zapytania do bazy, zewnętrzne integracje),
• brakiem sensownej korelacji z kanałami wejścia – np. gigantyczny ruch direct/unknown bez logicznych referrerów, nagłe skoki z nietypowych ASN.

Jeśli profil normalnego ruchu jest dobrze znany, anomalie typowe dla DDoS są szybko widoczne. Jeśli nie, każdy wzrost ruchu można pochopnie uznać za atak, ryzykując agresywne limity szkodzące sprzedaży lub obsłudze klientów.

Sygnały ostrzegawcze w logach i monitoringu

Systemy często „komunikują”, że są na granicy wytrzymałości długo przed faktycznym padnięciem. Problemem jest brak wyraźnych progów i interpretacji tych sygnałów. Z perspektywy wydajności DDoS ma typowe wczesne symptomy:

• nagłe zwiększenie liczby błędów typu connection reset by peer, connection timeout, przy wciąż akceptowalnym CPU serwerów,
• skokowa zmiana rozkładu kodów HTTP – więcej 429, 503, 504, przy stałym poziomie 4xx generowanych normalnie (np. 404),
• ekstremalny wzrost liczby zapytań do pojedynczych endpointów lub z jednego zakresu IP / AS,
• znacząco wyższy niż zwykle udział „pustych” user-agentów lub dziwnych kombinacji nagłówków.

Dodatkowo w logach systemowych można wychwycić: ostrzeżenia o zapełnieniu SYN backlog, ostrzeżenia kernela dotyczące „out of memory”, resetowanie połączeń przez load balancer lub reverse proxy. Każdy z tych sygnałów powinien mieć przypisany próg alertowania – brak alertu jest sam w sobie sygnałem ostrzegawczym dla procesu zarządzania incydentami.

Jeśli zespół ma listę konkretnych „symptomów DDoS” i progi alertów dla nich, reakcja może być oparta na faktach, a nie intuicji. Jeśli monitorowane są tylko „ogólne” metryki (CPU, uptime), problem zostaje zauważony dopiero wtedy, gdy klienci zgłoszą niedostępność.

Klasyfikacja DDoS pod kątem wpływu na wydajność systemu

Warstwa sieciowa (L3/L4) kontra warstwa aplikacyjna (L7)

Z punktu widzenia wydajności serwisu nie każdy DDoS jest równie groźny i nie każdy dotyka tego samego fragmentu architektury. Kluczem jest rozróżnienie, czy atak uderza głównie w warstwę sieciową (L3/L4), czy w logikę aplikacji (L7). Od tego zależy, gdzie inwestować w ochronę i jakie limity konfigurować.

Ataki volumetryczne (np. UDP flood, amplification) mają na celu zalanie pasma i urządzeń sieciowych. Głównym parametrem staje się przepustowość łącza oraz wydajność routerów/firewalli w PPS i Gbps. Aplikacja w takim scenariuszu często nawet nie „widzi” ataku – pakiety nie docierają do jej warstwy.

Ataki protokołowe (SYN flood, ACK flood) celują w implementację TCP, stany połączeń i tablice sesji. Zabijają głównie serwery brzegowe i load balancery, ewentualnie hosty zbyt słabo skonfigurowane pod kątem parametrów TCP (np. zbyt mały backlog, brak SYN cookies).

Ataki aplikacyjne (HTTP floods, slowloris, ataki na API) omijają typowe zabezpieczenia sieciowe, bo „udają” normalny ruch HTTP/HTTPS. Ich celem jest wyczerpanie zasobów interpretatorów, serwerów aplikacyjnych, baz danych i innych usług backendowych. Zwykle są mniej widoczne na poziomie czystej przepustowości, ale masakrują SLA.

Jeśli potrafisz z góry sklasyfikować, jakie typy ataków są dla twojej architektury najbardziej ryzykowne, możesz świadomie ustalić priorytety inwestycji (np. ochrona L3/L4 u operatora vs. rozbudowany WAF i rate limiting). Jeśli wszystko wrzucane jest do jednego worka „DDoS”, zwykle kończy się to przepłacaniem za rozbudowane usługi anty-DDoS przy wciąż niewydolnej aplikacji.

Volumetryczne i protokołowe ataki a metryki wydajności

Ataki volumetryczne przekładają się wprost na saturację pasma i urządzeń sieciowych. W metrykach widać:

• nagły wzrost bandwidth in/out na interfejsach, często do 100% dostępnej przepustowości,
• wzrost PPS (packets per second), przy możliwie „małym” ruchu w warstwie aplikacyjnej (mało requestów HTTP),
• zwiększoną liczbę błędów w urządzeniach brzegowych – dropowane pakiety, timeouty ustanawiania sesji.

W konsekwencji legalne pakiety nie docierają do load balancerów i originów – z perspektywy klientów usługa jest niedostępna, mimo że same serwery pozostają praktycznie bez obciążenia CPU. To charakterystyczny przypadek, gdy „aplikacja jest zdrowa, ale nikt nie może się do niej dostać”.

Ataki protokołowe (np. SYN flood) skupiają się na tablicach połączeń i mechanizmach handshake. W metrykach TCP widać:

• dużą liczbę połączeń w stanie SYN-RECV przy relatywnie małej liczbie established,
• wzrost odsetka nieudanych prób ustanowienia połączeń po stronie klienta,
• wykorzystanie maksymalnych wartości backlogów i parametrów typu max_syn_backlog, somaxconn.

Jeżeli u operatora lub w ramach usług anty-DDoS masz już ochronę L3/L4, głównym celem projektowania wydajności jest upewnienie się, że reszta infrastruktury (LB, reverse proxy) nie stanie się najsłabszym ogniwem. Jeśli nie masz takiej ochrony, minimum to jasne ustalenie, przy jakim poziomie PPS i Mb/s łącze i sprzęt przestają działać poprawnie.

Ataki aplikacyjne (L7): HTTP flood, slowloris, API

Ataki aplikacyjne są najbardziej „ekonomiczne” dla atakującego i jednocześnie najbardziej kosztowne dla ofiary. Zamiast wysyłać ogromne ilości śmieci, napastnik generuje stosunkowo niewielki ruch, ale celuje w operacje o wysokim koszcie przeliczeniowym lub I/O.

Przykłady:

• HTTP flood – setki tysięcy lub miliony żądań HTTP/HTTPS kierowanych na wybrane endpointy, często z poprawnymi nagłówkami, cookie i user-agentem; ruch przypomina zachowanie realnych użytkowników, ale intensywność i monotonia są nienaturalne.
• Slowloris / slow headers – wiele połączeń utrzymywanych możliwie jak najdłużej z bardzo wolnym wysyłaniem nagłówków lub body; blokują wątki, sockety i kolejki, nie generując dużego RPS.
• Ataki na API – intensywne wykorzystanie niektórych funkcji (np. /api/login, /api/search, /api/payment-status), szczególnie jeśli wykonują kosztowne zapytania lub wywołują zewnętrzne mikroserwisy.

W metrykach wydajności takie ataki widać jako:

• gwałtowny wzrost RPS dla konkretnych endpointów przy jednoczesnym spadku hit ratio cache,
• skok średniego czasu odpowiedzi i rosnący odsetek timeoutów przy jednoczesnym niewielkim wzroście całkowitego bandwidth,
• dużą liczbę aktywnych połączeń utrzymywanych długo w stanach READING/WRITING lub „idle” po stronie serwera HTTP,
• nienaturalnie wysoki udział ruchu z jednego typu klienta (np. jedna biblioteka HTTP, jeden framework botów) i powtarzalne wzorce w nagłówkach.

Punkt kontrolny: jeśli rośnie RPS i czasy odpowiedzi dla pojedynczych metod/endpointów, a zużycie łącza pozostaje dalekie od maksimum, problem jest niemal na pewno w warstwie aplikacyjnej i backendowej, a nie w przepustowości. W takiej sytuacji sama ochrona L3/L4 lub „większe łącze” nie rozwiążą problemu.

Przy atakach L7 kluczowe jest zderzenie trzech wykresów: ruchu HTTP per endpoint, obciążenia CPU/IO per serwer aplikacyjny i metryk bazodanowych (czas zapytań, liczba połączeń, blokady). Jeśli wzrost na konkretnym endpointzie przekłada się niemal liniowo na saturację bazy lub kolejki w systemie kolejkowym, to ten punkt staje się priorytetowym kandydatem do ograniczania, cache’owania lub przeniesienia za osobny, mocniej chroniony front.

Drugim krytycznym obszarem jest zarządzanie połączeniami. Slowloris i podobne techniki ujawniają się jako duża liczba otwartych socketów, rosnące wykorzystanie workerów i wątków przy zaskakująco niskim efektywnym RPS. Jeśli monitoring nie pokazuje stanów połączeń i liczby aktywnych workerów, takie ataki są „niewidzialne”, aż do chwili, gdy serwer HTTP przestaje przyjmować nowe sesje.

Jeżeli punktem kontrolnym staje się każdy wątek, worker lub connection slot, minimalnym wymaganiem jest twarde ograniczenie liczby równoległych połączeń per klient/AS oraz rozsądne limity czasu na wysyłanie nagłówków i body. Bez tego nawet bardzo umiarkowany ruch jest w stanie zablokować procesy serwera, mimo że z perspektywy sieci wszystko wygląda „normalnie”.

Kiedy spojrzeć na te wszystkie klasy ataków przez pryzmat wydajności, widać jeden wspólny mianownik: system pada nie dlatego, że ruch istnieje, tylko dlatego, że przekracza realne limity poszczególnych warstw – od pasma i tablic połączeń, przez wątki serwera HTTP, aż po najbardziej kosztowne zapytania do bazy. Jeśli te limity są znane, zmierzone i powiązane z konkretnymi progami alertów oraz procedurami reakcji, nawet duży DDoS staje się problemem operacyjnym do obsłużenia, a nie loterią, czy serwis „wytrzyma” kolejny szczyt ruchu.

Punkt wyjścia: pomiar bazowej wydajności i wyznaczenie „minimum” odporności

Definicja „minimum” odporności: ile ruchu musi realnie wytrzymać system

Zanim pojawi się dyskusja o DDoS, trzeba wiedzieć, jaką skalę legalnego ruchu serwis obsługuje i jakie rezerwy są faktycznie potrzebne. „Minimum odporności” nie jest liczbą z sufitu ani ofertą z prezentacji dostawcy, tylko wynikiem pomiaru i kilku prostych założeń biznesowych.

Podstawowy zestaw parametrów do wyznaczenia minimum to:

• szczytowy RPS (requests per second) dla HTTP/HTTPS oraz osobno dla najważniejszych API,
• typowy profil dobowy – ile razy rośnie ruch w piku wobec średniej dobowej,
• tolerowane opóźnienie (SLA) dla kluczowych operacji: logowanie, płatność, wyszukiwanie,
• obciążenie bazowej infrastruktury (CPU, pamięć, I/O) przy tym szczytowym ruchu,
• margines bezpieczeństwa – ile razy powyżej szczytu biznesowego chcesz zachować pełną funkcjonalność.

Prosty schemat wygląda tak: znany szczytowy ruch × współczynnik bezpieczeństwa (np. 3×) daje minimalny poziom, przy którym system nie powinien się załamać nawet przy „agresywnym marketingowo” dniu. To jeszcze nie jest pełna odporność na DDoS, ale bez tego punktu odniesienia każda rozmowa o atakach kończy się stwierdzeniem „weźmy większe maszyny”.

Jeśli szczytowy ruch nie jest znany, sygnałem ostrzegawczym jest brak elementarnej telemetrii lub brak jej wykorzystania przy decyzjach o pojemności. W takim przypadku pierwszy „projekt anty-DDoS” powinien zacząć się od tygodnia lub dwóch intensywnego zbierania danych, a nie od zakupu usługi ochrony.

Testy wydajnościowe jako symulator DDoS „kontrolowany”

Konkretny punkt kontrolny to testy wydajnościowe oparte na rzeczywistych scenariuszach użytkownika. Nie chodzi o sztuczne generowanie losowych żądań, tylko o odtworzenie realnego miksu ruchu: strona główna, logowanie, produkt, koszyk, płatność, API mobilne.

Przygotowując testy, dobrze jest zadać kilka pytań:

• czy scenariusze obejmują najdroższe operacje (raporty, eksporty, filtrowanie dużych list), a nie tylko „happy path” strony głównej,
• czy generowany ruch symuluje rozsądny rozkład endpointów, czy uderza w jeden URL, który w normalnych warunkach ma minimalne znaczenie,
• czy testowany jest zarówno ruch krótkotrwały (burst), jak i długotrwałe podwyższone obciążenie (np. 30–60 minut),
• czy mierzone są nie tylko czasy odpowiedzi, ale też wewnętrzne metryki: CPU, I/O dysku, połączenia do bazy, kolejki w serwerach aplikacyjnych.

Jeśli testy wydajnościowe nie wykazują żadnych problemów nawet przy kilkukrotnym zwiększeniu szczytowego ruchu, a jedyne zużycie rośnie liniowo, „minimum” odporności jest blisko. Jeśli przy niewielkim wzroście RPS pojawiają się skoki opóźnień, rosnące kolejki lub błędy 5xx, to limit leży znacznie poniżej teoretycznej przepustowości sprzętu i to tam DDoS trafi w pierwszej kolejności.

Kluczowe punkty nasycenia: CPU, I/O, połączenia, kolejki

Atak DDoS tylko przyspiesza mechanizmy, które i tak wystąpią przy wzroście ruchu. Dlatego warto zmapować punkt po punkcie, w którym system zaczyna się dławić. Typowe wąskie gardła to:

• CPU serwerów aplikacyjnych – przy jakim RPS średni i p95 czasu odpowiedzi zaczyna rosnąć szybciej niż ruch,
• liczba równoległych połączeń na warstwie HTTP/TCP – czy serwery osiągają maksymalne ustawione limity connection slots,
• kolejki w serwerze HTTP / application serverze – czy zaczyna rosnąć czas oczekiwania w kolejce przed obsługą żądania,
• połączenia do bazy danych – maksymalna liczba sesji, czasy zapytań, liczba blokad,
• I/O dyskowe – opóźnienia odczytu/zapisu dla logów, cache na dysku, plików statycznych.

Przykład z praktyki: w testach okazało się, że przy zaledwie dwukrotnym wzroście ruchu względem codziennego szczytu baza danych osiąga maksymalną liczbę połączeń, po czym kolejne zapytania są odrzucane. Sprzęt aplikacyjny miał jeszcze rezerwy CPU, sieć była daleka od saturacji, a mimo to serwis stawał się nieużywalny. Źródłem problemu był zbyt agresywny model „jeden request – jedno połączenie do bazy” bez poolingu i bez limitów per usługę.

Jeżeli choć jeden z tych punktów jest osiągany przy umiarkowanym ruchu, DDoS nie musi mieć astronomicznej skali, żeby wywołać awarię. Wystarczy kilkukrotne zwiększenie normalnej liczby żądań, często możliwe z poziomu jednego popularnego narzędzia do testów obciążeniowych.

Wyznaczenie progów: kiedy ruch jest jeszcze „legalnym pikiem”, a kiedy już incydentem

Znając punkty nasycenia, można przejść do definiowania progów ostrzegawczych i krytycznych. Celem jest stałe działanie poniżej progu, przy którym system wchodzi w nieliniowy wzrost opóźnień.

Dla każdej newralgicznej metryki warto zdefiniować trzy poziomy:

• normalny – zakres uznany za codzienny, nawet przy standardowych kampaniach marketingowych,
• ostrzeżenie – wartości zbliżające się do punktu, w którym metryka historycznie zaczynała się „rozjeżdżać” (np. CPU > 70%, occupancy puli połączeń do bazy > 60%),
• krytyczny – wartości, przy których SLA zaczyna być naruszane lub mechanizmy awaryjne (np. autoscaling) przestają nadążać.

Punktem kontrolnym jest korelacja tych progów z ruchem HTTP i konkretnymi funkcjami serwisu. Jeśli próg krytyczny CPU jest przekraczany przy dużej liczbie żądań do jednego endpointu, a inne pozostają w normie, mechanizmy ochronne powinny w pierwszej kolejności ograniczać ten konkretny ruch, a nie „dławić” wszystkich.

Jeśli progi są zdefiniowane jedynie na poziomie infrastruktury (CPU, RAM, uptime), bez odniesienia do endpointów i procesów biznesowych, zespół operacyjny widzi tylko „czerwone alarmy” bez jasnego kierunku działania. W warunkach DDoS skutkuje to chaotycznymi decyzjami: restartami, blokowaniem losowych adresów IP, wyłączaniem funkcji w aplikacji.

Projektowanie architektury pod odporność: od sieci po aplikację

Warstwa sieciowa: przepustowość, filtrowanie i punkty styku z operatorem

Na najniższej warstwie odporność zaczyna się od prostego pytania: gdzie kończy się twoja kontrola, a zaczyna infrastruktura operatora? Ataki volumetryczne są skuteczne głównie wtedy, gdy saturują łącze wcześniej, niż zaczną działać jakiekolwiek twoje mechanizmy.

Kluczowe decyzje po stronie sieci obejmują kilka obszarów:

• zapas przepustowości – ile procent pasma jest wykorzystywane w typowym i szczytowym ruchu; czy istnieje margines, który pozwala przechwycić i przeanalizować anomalię, zanim operator zacznie samodzielnie filtrować ruch,
• punkty styku z usługami anty-DDoS – czy ruch jest kierowany przez scrubbing center, czy filtracja odbywa się dopiero na twoich urządzeniach brzegowych,
• konfiguracja routerów i firewalli – limity PPS, tablice sesji, mechanizmy rate limit, ICMP/UDP filtering, blackhole routing,
• segmentacja – czy ruch do krytycznych systemów (np. panel administracyjny, strefa płatności) jest odseparowany od ruchu publicznego.

Jeżeli router brzegowy jest jednocześnie punktem koncentracji całego ruchu publicznego, VPN i ruchu administracyjnego, staje się pojedynczym punktem awarii. DDoS wymierzony w dowolny z tych obszarów może w praktyce odciąć całą organizację od sieci.

Punkt kontrolny: jeśli nie ma jasno udokumentowanej współpracy z operatorem w zakresie DDoS (progi, tryb aktywacji filtracji, kanał eskalacji), realne minimum odporności jest nieznane. W takim scenariuszu nawet dobrze przygotowane systemy aplikacyjne mogą być bezradne przy saturacji łącza.

Load balancery i reverse proxy: gdzie kończy się ruch, a zaczyna aplikacja

Warstwa równoważenia ruchu często staje się niewidzialnym bottleneckiem. Przy normalnym obciążeniu load balancer i reverse proxy wykorzystują ułamek swoich możliwości, ale przy DDoS zaduszają się tablicami połączeń i kolejkami, zanim aplikacja zdąży cokolwiek policzyć.

Przy audycie tej warstwy zwykle sprawdza się:

• maksymalną liczbę równoległych połączeń, które urządzenie lub usługa może obsłużyć i jak to się ma do realnego ruchu,
• mechanizmy rate limiting – czy istnieją limity per IP, per AS, per ścieżka URL i jak są skorelowane z obserwowanym ruchem,
• timeouty – ile czasu LB trzyma połączenie od klienta i od backendu; czy są asymetrycznie ustawione (często powinny być krótsze od strony klienta),
• strategie health-check – jak szybko LB „odcina” niesprawne instancje i czy nie pogarsza tym samym sytuacji w trakcie ataku (np. wyrzucając jeszcze zdrowe, ale przeciążone serwery).

Typowy sygnał ostrzegawczy: liczba aktywnych połączeń na LB rośnie wykładniczo, podczas gdy backendy raportują umiarkowane obciążenie CPU. W praktyce oznacza to, że zasoby są marnowane na utrzymywanie wielu półotwartych połączeń, a nie na realną obsługę żądań. Dla DDoS typu slowloris to idealny scenariusz.

Jeśli reverse proxy nie ma skonfigurowanych twardych limitów połączeń i spójnych timeoutów, nawet niewielki atak L7 może doprowadzić do wyczerpania workerów i pamięci, a następnie do efektu domina na backendach.

Serwer HTTP i warstwa aplikacyjna: kontrola nad kosztownymi operacjami

Na poziomie serwera HTTP i aplikacji DDoS przestaje być wyłącznie problemem ilości ruchu, a staje się problemem jego „składu jakościowego”. Dwa serwisy o identycznym RPS mogą zachowywać się zupełnie inaczej w zależności od tego, jak drogie są poszczególne operacje.

Kluczowe elementy po stronie serwera HTTP:

• model przetwarzania – procesowy, wątkowy, asynchroniczny; ile realnie równoległych żądań jest obsługiwanych, zanim pojawi się kolejka,
• limity workerów – maksymalna liczba procesów/wątków, po osiągnięciu której serwer przestaje przyjmować nowe połączenia,
• keep-alive – długość życia połączenia i maksymalna liczba żądań na jedno połączenie (przestrzeń do nadużyć w atakach powolnych),
• limity rozmiaru żądania – bufory nagłówków i body; duże wartości ułatwiają ataki typu slow headers i oversize payload.

Po stronie aplikacji najważniejszy jest koszt poszczególnych endpointów. Minimalny zestaw informacji dla każdego z nich to:

• czas wykonania (średni, p95, p99),
• liczba wywołań operacji zewnętrznych (baza, cache, mikroserwisy),
• typowy i maksymalny RPS,
• czy istnieje cache (lokalny, CDN, wewnętrzny) i jaki jest hit ratio.

Punkt kontrolny: jeśli nie ma wiedzy, które 3–5 endpointów generuje największe zużycie CPU i I/O, ochrona L7 będzie projektowana „w ciemno”. W rezultacie realnie atakowalne funkcje pozostaną bez ograniczeń, a łagodniejsze operacje zostaną niepotrzebnie „dławione” przy pierwszym podejrzeniu DDoS.

Baza danych i systemy składowania: ostatnia linia frontu

W większości systemów baza danych jest najbardziej wrażliwym zasobem. Nawet stosunkowo niewielki wzrost liczby zapytań, jeśli są źle zoptymalizowane, może skutecznie unieruchomić całą aplikację.

Przy projektowaniu odporności warto uporządkować kilka obszarów:

• limit połączeń – maksymalna liczba sesji i sposób, w jaki aplikacje zarządzają pulami (czy każdy serwis ma własną pulę, czy istnieje centralna kontrola),
• profil zapytań – które SQL/NoSQL queries są najczęściej wykonywane i które mają najdłuższy czas wykonania,
• indeksy i plany zapytań – czy kluczowe ścieżki krytyczne mają zapytania wykonujące się przewidywalnie, czy czasem wchodzą w skanowanie pełnych tabel,
• cache przed bazą – poziom cache (aplikacyjny, Redis/Memcached, materializowane widoki) i jego skuteczność przy podwyższonym ruchu.

Bezpośrednio pod DDoS-em ujawniają się również błędy w polityce retry po stronie aplikacji. Agresywne ponawianie nieudanych zapytań (np. przy błędach 5xx lub timeoutach) potrafi w ciągu kilku sekund zwielokrotnić presję na bazę. Jeśli każdy mikroserwis ma własne, niezsynchronizowane limity retry, rośnie ryzyko lawiny wewnętrznych wywołań, która zabija bazę szybciej niż sam atak z zewnątrz. Sygnał ostrzegawczy: w momentach spadku dostępności zewnętrznej ruch z warstwy aplikacyjnej do bazy nie maleje, tylko rośnie skokowo.

Drugim kryterium jest przewidywalność degradacji. Baza powinna mieć zdefiniowane twarde limity – połączeń, jednoczesnych zapytań, wykorzystania pamięci – przy których zaczyna odrzucać kolejne sesje lub przerwać drogie zapytania, zanim nastąpi pełna utrata responsywności. Jeśli mechanizmy typu query governor, limit czasu wykonania zapytań lub „killowanie” najcięższych operacji nie są skonfigurowane, baza przechodzi z trybu „działa wolno” w tryb „nie działa wcale” bez strefy buforowej.

Trzecia oś to izolacja obciążeń. Raportowanie, batch processing i eksporty danych powinny być oddzielone (inne repliki, osobne klastry, priorytety I/O) od ścieżek transakcyjnych. W trakcie DDoS każde zadanie analityczne konkurujące z logiką online o te same zasoby dyskowe lub pamięć przyspiesza krytyczny moment załamania. Punkt kontrolny: czy istnieje możliwość natychmiastowego wyłączenia obciążeń niekrytycznych na poziomie bazy lub systemu kolejkowego, bez modyfikowania aplikacji.

Jeśli baza nie ma jasno zdefiniowanych limitów, mechanizmów degradacji oraz izolacji obciążeń, cała poprzednia warstwa ochronna (cache, rate limiting, architektura L7) traci sens. Wtedy stosunkowo prosty atak na kilka drogich zapytań wystarczy, by system przeszedł w stan niekontrolowanej awarii kaskadowej.

Odporność na DDoS w praktyce nie sprowadza się do pojedynczego urządzenia czy „magicznej” usługi, lecz do spójnego zestawu decyzji na każdym poziomie – od łącza z operatorem, przez load balancer i serwery HTTP, po bazę danych i procesy biznesowe. Jeśli dla każdej z tych warstw istnieje zdefiniowane minimum: metryki, progi, sposób degradacji oraz ścieżka eskalacji, atak staje się sytuacją trudną, ale zarządząwalną. Jeśli brakuje któregoś z tych elementów, nawet umiarkowany skok ruchu potrafi przełożyć się na pełną utratę dostępności kluczowych usług.

Punkt wyjścia: pomiar bazowej wydajności i wyznaczenie „minimum” odporności

Bez twardych liczb dyskusja o DDoS sprowadza się do życzeń i deklaracji. Bazowa wydajność to nie teoretyczna moc serwerów, tylko weryfikowalna granica: ile realnego ruchu w typowych scenariuszach jest w stanie utrzymać cała ścieżka – od DNS po bazę danych – zanim zacznie się degradacja. To właśnie ten punkt staje się minimum odporności, które trzeba zestawić z profilami potencjalnych ataków.

Definicja scenariuszy obciążenia: ruch normalny, peak, awaryjny

Zanim pojawią się narzędzia i testy, potrzebne są scenariusze. Dla każdego serwisu krytycznego minimum to trzy kategorie:

• ruch normalny – typowe obciążenie w ciągu dnia roboczego, tydzień i miesiąc; z uwzględnieniem sezonowości,
• peak biznesowy – planowane skoki (kampanie marketingowe, Black Friday, okres rozliczeń, otwarcia naborów),
• scenariusz awaryjny – nieplanowany wzrost ruchu: awaria innego dostawcy, migracja klientów, wzmianka medialna.

Każdy z tych scenariuszy powinien mieć oszacowaną liczbę RPS, średni rozmiar odpowiedzi, udział cache/hit ratio oraz udział najdroższych endpointów. Jeśli nie ma choć przybliżonego modelu „jak wygląda dzień, gdy jest bardzo gorąco, ale jeszcze bez ataku”, trudno odróżnić odwiedziny realnych klientów od wstępnej fazy DDoS.

Punkt kontrolny: jeśli zespół nie jest w stanie w ciągu kilku minut podać orientacyjnych wartości dla peak biznesowego (RPS, p95, wykorzystanie CPU/DB), system działa bez wyznaczonej granicy bezpieczeństwa. W takiej sytuacji każda decyzja o odcięciu ruchu ryzykuje albo przedwczesne „zaduszenie” klientów, albo zbyt późną reakcję na atak.

Wybór metryk i źródeł: co liczyć, żeby miało sens

Do wyznaczenia minimum odporności nie wystarczy pojedynczy dashboard z CPU. Potrzebne są metryki, które opisują całą ścieżkę obsługi żądania. W praktyce przydaje się podział na trzy grupy:

• metryki infrastrukturalne – przepustowość łącza (Mbps), liczba pakietów (PPS), opóźnienia i utrata pakietów na granicy sieci, obciążenie interfejsów i routerów brzegowych,
• metryki platformowe – liczba aktywnych połączeń na load balancerach i reverse proxy, liczba otwartych plików, wykorzystanie workerów HTTP, długości kolejek (np. w Nginx/Envoy/HAProxy, kolejkach IPC, message brokerach),
• metryki aplikacyjne – RPS per endpoint, p95/p99 czasów odpowiedzi, liczba błędów 4xx/5xx per ścieżka, liczba zapytań do bazy i cache na jedno żądanie, ratio cache hit/miss.

Sygnał ostrzegawczy: monitoring pokazuje głównie wykresy CPU i ogólny „traffic in/out”, a brak jest widoku na liczby połączeń, kolejki i koszt per endpoint. W takim środowisku nawet poprawnie przeprowadzony test obciążeniowy niewiele powie o prawdziwej odporności.

Testy obciążeniowe: jak zbliżyć się do symptomu DDoS, nie powodując incydentu

Testy wydajnościowe dla potrzeb DDoS różnią się od klasycznych load testów. Ich celem nie jest „sprawdzenie, czy działa pod X RPS”, tylko zmapowanie ścieżki degradacji: przy jakim typie ruchu i jakim wolumenie zaczynają się problemy i w którym miejscu łańcucha.

Przy projektowaniu testów sensowne jest rozdzielenie kilku typów obciążeń:

• test wolumetryczny L7 – duży wolumen prostych żądań (np. statyczne zasoby z cache) w celu sprawdzenia limitów LB, reverse proxy i łącza,
• test „najdroższych” endpointów – skoncentrowany ruch na 3–5 najbardziej kosztownych ścieżkach, aby zidentyfikować granice bazy i logiki biznesowej,
• test mieszany – ruch zbliżony do produkcyjnego rozkładu ścieżek, z dołożeniem kontrolowanej ilości żądań „toksycznych” (np. raportów na żądanie, ciężkich eksportów),
• test powolnych połączeń – symulacja slowloris/slow POST: mała liczba klientów, którzy bardzo długo trzymają połączenia, aby sprawdzić politykę timeoutów i limity połączeń.

Kluczowy warunek: testy muszą być ułożone tak, by nie wchodzić w konflikt z systemami IPS/IDS i procesami biznesowymi. W praktyce oznacza to testy poza godzinami szczytu, uzgodnione z operatorem łącza, z wyraźną identyfikacją ruchu testowego i mechanizmem „panic button” – natychmiastowego przerwania testu, gdy przekroczone zostaną bezpieczne progi.

Punkt kontrolny: jeśli ostatni test obciążeniowy był jednorazowym „sprawdzeniem, ile RPS wytrzyma front”, bez analizy, gdzie i jak system zaczyna się sypać, bazowe minimum odporności jest czysto teoretyczne. Przy prawdziwym ataku pierwsze minuty będą poświęcone na zgadywanie, zamiast na świadome decyzje.

Wyznaczenie progów alarmowych i strefy buforowej

Same liczby z testów niewiele dadzą, jeśli nie zostaną przekształcone w konkretne progi: co jest uznawane za obciążenie wysokie, krytyczne i nienormalne. Każda warstwa powinna mieć własne progi, ale skoordynowane między sobą.

Przykładowy podział:

• strefa zielona – obciążenie do 60–70% zasobów: operujemy w normalnym trybie, alerty są jedynie informacyjne,
• strefa żółta – 70–85%: pojawiają się ostrzeżenia, włączane są pasywne mechanizmy ochronne (np. łagodniejszy rate limit, zwiększenie cache TTL),
• strefa czerwona – powyżej 85–90%: aktywne działania – twarde limity, zaostrzone rate limiting, odcinanie najmniej krytycznych funkcji, ruchu anonimowego lub wysokiego ryzyka.

Te wartości nie powinny być arbitralne; wynikają z testów. Jeżeli przy 80% wykorzystania CPU na serwerach aplikacyjnych p95 czasu odpowiedzi rośnie dwukrotnie, strefa żółta kończy się niżej. Jeśli baza danych zaczyna gwałtownie wydłużać czasy zapytań przy 70% I/O, logiczne jest ustawienie progu krytycznego poniżej tej wartości.

Sygnał ostrzegawczy: alerty są ustawione wyłącznie na twarde błędy (5xx, brak odpowiedzi) lub bardzo wysokie zużycie zasobów (np. 95–100% CPU), bez strefy „przedkrytycznej”. W takiej konfiguracji zespół dowiaduje się o problemie dopiero wtedy, gdy użytkownicy już tracą dostęp.

Mapa priorytetów biznesowych: co musi działać, gdy wszystko inne się pali

Odporność na DDoS ma sens tylko wtedy, gdy wiadomo, które funkcje systemu są absolutnie krytyczne. Przy wyznaczaniu „minimum” potrzeba nie tylko parametrów technicznych, ale także decyzji biznesowych.

Dla każdej większej aplikacji powinno powstać przynajmniej proste rozróżnienie:

• funkcje krytyczne – brak działania oznacza istotną stratę finansową lub wizerunkową (np. autoryzacja płatności, logowanie użytkownika, składanie zamówień),
• funkcje istotne, ale niekrytyczne – mogą działać wolniej lub być czasowo ograniczone (np. historia transakcji, niektóre raporty, wyszukiwarka z filtrami),
• funkcje pomocnicze – można je całkowicie wyłączyć w kryzysie (np. rekomendacje, sekcje „blogowe”, część API publicznych, rozbudowane raporty ad hoc).

Na tej podstawie definiuje się, jakie części ruchu mogą być agresywnie cięte w trakcie ataku, bez rozwalania core biznesu. Dopiero wtedy rate limiting, reguły WAF i scenariusze degradacji mają sens: zamiast przypadkowo dławić „co popadnie”, świadomie odcina się ścieżki najmniej ważne.

Punkt kontrolny: jeśli nikt nie potrafi jasno odpowiedzieć, czy w trakcie DDoS można odłączyć np. „historię zamówień starszą niż X” albo publiczne API raportowe, nie ma realnego planu działań kryzysowych. W efekcie broni się wszystkiego po trochu, aż padnie wszystko naraz.

Projektowanie architektury pod odporność: od sieci po aplikację

Architektura odporna na DDoS to w praktyce zestaw ograniczników, buforów i mechanizmów degradacji zorganizowanych w łańcuch: od punktu wejścia do danych. Każdy element ma swoje maksimum, a celem jest takie ustawienie progów, aby nigdy nie doprowadzić do niekontrolowanego przeciążenia najcenniejszych zasobów.

Redundancja i geograficzne rozproszenie punktów wejścia

Pierwszym poziomem projektowania jest zapewnienie, że atak nie zatrzyma ruchu jednym strzałem w pojedynczy punkt wejścia. Nawet bez dużych budżetów można wprowadzić proste mechanizmy:

• wielu operatorów – niezależne łącza do różnych dostawców, z jasno określoną polityką routingu (BGP) i filtracji,
• rozproszone punkty POP – wykorzystanie CDN/WAF z infrastrukturą anycast, aby przyjąć dużą część ruchu „na brzegu” sieci, zanim trafi do centrum danych,
• separacja usług – inne punkty wejścia (domeny, IP, ścieżki routingu) dla ruchu publicznego, paneli administracyjnych, interfejsów API partnerów.

Sygnalny problem: jedna domena i jedno IP obsługuje wszystko – stronę publiczną, panel klienta, API zewnętrzne i panel administracyjny. Przy takim układzie jakikolwiek atak na jakikolwiek komponent skutecznie przepełnia pojedynczy kanał dostępu.

Architektura warstwowa: filtry jak sita, nie jak mur

Odporna infrastruktura nie opiera się na jednym, „najsilniejszym” urządzeniu, lecz na kilku kolejnych poziomach filtracji. Każdy poziom ma przyjmować tylko część presji, a nie całość.

Typowa, zdrowa sekwencja wygląda tak:

1. warstwa operatora/CDN/WAF – odrzucanie ruchu oczywiście szumowego (np. source spoofing, stare botnety), podstawowy rate limiting per IP/ASN, filtrowanie znanych wzorców ataków,
2. warstwa load balancera – limity połączeń, zaawansowane algorytmy równoważenia, ograniczanie zbyt częstych żądań na rzadko używane ścieżki,
3. reverse proxy/serwer HTTP – szczegółowe reguły L7 (limity nagłówków, limity body, specyficzne rate limity per endpoint, podstawowe reguły WAF specyficzne dla aplikacji),
4. warstwa aplikacyjna – uwierzytelnianie, autoryzacja, limity per użytkownik/konto/klient, wewnętrzny cache odpowiedzi, kolejki asynchroniczne,
5. warstwa danych – limity połączeń, limity zapytań, mechanizmy odrzucania najcięższych operacji przy zbliżaniu się do limitów zasobów.

Kluczem jest to, aby możliwie jak najwięcej „złego” ruchu odciąć jak najbliżej punktu wejścia do sieci, a do aplikacji i bazy dopuszczać tylko to, czego nie da się odfiltrować prostymi kryteriami. Jeśli gros filtracji odbywa się w aplikacji, a WAF/CDN przepuszcza prawie wszystko, architektura jest z natury reaktywna, a nie defensywna.

Projektowanie limitów: od surowych metryk do polityk biznesowych

Limity to istota ochrony przed DDoS – technicznie sprowadzają się do powiedzenia: „przyjmuję tylko tyle, na ile mnie stać”. Problem zaczyna się wtedy, gdy są ustawiane arbitralnie albo tylko technicznie, bez powiązania z biznesem.

Przykład dobrej praktyki to trójstopniowe limity:

• limity globalne – ile maksymalnie równoległych połączeń i żądań może przyjąć cała platforma, zanim uruchomi się twarda degradacja,
• limity kontekstowe – per IP, per użytkownik, per token API, per AS; inne dla ruchu anonimowego, inne dla klientów premium czy wewnętrznych integracji,
• limity per funkcja – osobne dla operacji tanich (np. status systemu) i drogich (eksport, generowanie raportów, złożone wyszukiwanie).

Limity muszą być spójne w całej ścieżce. Jeżeli WAF pozwala na 10 tys. zapytań na minutę na endpoint raportowy, a baza jest w stanie obsłużyć tylko 500 takich zapytań w tym czasie, limit L7 jest źle skalibrowany. Zamiast chronić system, tylko przyspiesza moment awarii na bazie.

Punkt kontrolny: jeśli limity rate limiting są ustawione wyłącznie „per IP” i bez zróżnicowania per endpoint/klient, a do tego nie są powiązane z realnymi możliwościami bazy i aplikacji, atak z rozproszonych źródeł będzie praktycznie niewidoczny do czasu krytycznej awarii.

Cache jako bufor, nie jako jedyne lekarstwo

Cache często jest pierwszą odpowiedzią na pytanie „jak zwiększyć odporność?”. Odpowiednio użyty potrafi odciąć większość ruchu statycznego od aplikacji i bazy. Źle skonfigurowany staje się jednak kolejnym, bardzo bolesnym punktem awarii.

Podczas projektowania cache pod kątem DDoS istotne są:

• jasne kryteria cache’owania – które odpowiedzi mogą być współdzielone (public), a które muszą być per użytkownik (private), jakie są bezpieczne czasy życia (TTL) dla poszczególnych typów danych,
• kontrola rozmiaru i kluczy – ograniczenie maksymalnego rozmiaru obiektu, normalizacja parametrów w kluczu (np. sortowanie, usuwanie śmieciowych parametrów trackingowych), aby uniknąć „cache explosion” przy ataku na nietypowe kombinacje parametrów,
• warstwowość cache – oddzielenie cache na brzegu (CDN/reverse proxy), cache aplikacyjnego (np. Redis) i mechanizmów cache’owania po stronie bazy, z jasno zdefiniowaną odpowiedzialnością każdej warstwy,
• strategia failover – co ma się wydarzyć, gdy cache przestaje być dostępny lub nagle się „opróżnia”: czy aplikacja potrafi ograniczyć częstotliwość dogrywania danych z bazy, czy też ruszy pełną parą i zabije storage.

Dobrym testem dojrzałości konfiguracji cache jest odpowiedź na pytanie: „czy ruch 10× większy niż normalnie, ale głównie po zasobach statycznych i powtarzalnych, spowoduje istotny wzrost obciążenia aplikacji/bazy?”. Jeżeli tak – cache jest realnie tylko cienką warstwą wygody, a nie buforem bezpieczeństwa. Sygnał ostrzegawczy: brak metryk skuteczności cache (hit rate per endpoint, per typ danych) oraz brak limitów maksymalnej liczby missów kierowanych w jednostce czasu do backendu.

Drugi obszar, który często wychodzi dopiero podczas incydentu, to skoordynowanie polityk cache z mechanizmami anty-DDoS. Filtry WAF i reguły rate limiting potrafią przypadkowo „przestrzelić” w stronę cache, np. blokując nagłówki sterujące (Cache-Control) lub powodując zbyt częste omijanie cache przez niewłaściwą klasyfikację ruchu. Minimum to regularne testy scenariuszy: duży skok na endpointy cache’owane, symulacja miss storm (masowe wygaszenie popularnych kluczy) i obserwacja, czy system redukuje presję, czy raczej ją amplifikuje.

Jeśli cache jest traktowany jako magiczne przyspieszenie bez policzonych limitów, spójnych TTL i analizy „co się stanie, gdy przestanie działać”, to w kontekście DDoS pełni rolę pozornej tarczy. Dopiero gdy widać konkretny zysk w hit rate, zmierzony spadek obciążenia backendu i istnieją procedury na wypadek awarii cache, można mówić o rzeczywistym buforze, a nie tylko dodatkowym punkcie ryzyka.

Cała układanka – od pomiaru bazowej wydajności, przez polityki biznesowe, po architekturę i limity – sprowadza się do jednego pytania: „czy wiemy, gdzie świadomie odetniemy ruch, zanim system sam zacznie się bronić awarią?”. Jeśli odpowiedź jest niejasna, atak DDoS prędzej czy później sam wskaże najsłabsze miejsce, zwykle w najgorszym możliwym momencie. Jeśli jest konkretna, z policzonymi progami i scenariuszami degradacji, nawet silny atak stanie się przede wszystkim testem założeń, a nie początkiem kryzysu operacyjnego.

Najczęściej zadawane pytania (FAQ)

Jak rozpoznać, która warstwa mojej infrastruktury padnie jako pierwsza przy ataku DDoS?

Minimalne ćwiczenie to symulacja 10x typowego ruchu i odpowiedź na jedno zdanie: „co w tej architekturze padnie jako pierwsze?”. Jeśli nie potrafisz wskazać konkretu (np. „load balancer”, „baza danych”, „łączę do operatora”), to sygnał ostrzegawczy – nie masz zidentyfikowanego pierwszego punktu krytycznego.

Praktyczny sposób podejścia to przejście po typowym łańcuchu: pasmo / urządzenia brzegowe → load balancer → serwery aplikacyjne → baza danych / cache. Dla każdej warstwy wyznacz:

• maksymalny bezpieczny throughput (ruch, RPS, liczba połączeń),
• metryki, które zaczną się psuć jako pierwsze (latencja, error rate, kolejki),
• czy masz już twarde limity i alerty.

Jeśli jasne jest, że np. LB „dusi się” dużo wcześniej niż serwery aplikacyjne, inwestycje w nowe serwery nie poprawią odporności na DDoS.

Jakie zasoby systemowe najczęściej kończą się przy DDoS i po czym to poznać?

Z perspektywy wydajności większość DDoS-ów sprowadza się do wyczerpania CPU, RAM, socketów lub kolejek. Każdy z tych zasobów zostawia inne ślady. CPU zabijają ciężkie operacje (np. kryptografia, złożone zapytania), RAM – zbyt wiele otwartych połączeń i brak limitów na rozmiar żądań, sockety – flood połączeń TCP/HTTP, a kolejki – zbyt długie buforowanie ruchu bez limitu.

Praktyczna lista kontrolna:

• CPU: stabilnie 90–100%, czasy odpowiedzi rosną wszędzie, thread pool pełny.
• RAM: zużycie dochodzi do maksimum, pojawia się swap, logi OOM killera.
• Sockety: dużo SYN-RECV, TIME-WAIT, błędy „too many open files”, „connection refused”.
• Kolejki: rosnąca długość kolejek w LB/aplikacji przy wciąż „zdrowych” backendach.

Jeśli wiesz, który zasób kończy się pierwszy, możesz dobrać celowane środki (limity, timeouty, caching). Jeśli nie – każdy pomysł ochrony jest losowy.

Jak odróżnić legalny „wysoki ruch marketingowy” od ataku DDoS?

Legalny ruch zwykle ma korelacje z działaniami biznesowymi: kampania, push, mailing. W logach i analityce widać naturalny rozkład referrerów, geolokalizacji, urządzeń, a ścieżki użytkowników są zróżnicowane – różne podstrony, podobna liczba requestów na sesję. Ruch rośnie, ale w granicach rozsądku i „zachowuje się” podobnie jak historyczne piki.

Atak DDoS jest monotonny i nielogiczny z perspektywy biznesu. Typowe sygnały ostrzegawcze:

• ekstremalne skoncentrowanie ruchu na kilku drogich endpointach (np. /login, /search),
• nagły wysoki ruch „direct/unknown” bez referrerów i sensownych kampanii,
• nietypowe ASN / kraje, dużo pustych lub dziwnych user-agentów.

Jeśli profil normalnego ruchu jest zdefiniowany (metryki, dashboardy), anomalia DDoS jest wyraźna. Jeśli nie – łatwo zablokować klientów, myląc kampanię z atakiem.

Jakie metryki i logi monitorować, żeby wcześnie wykryć DDoS pod kątem wydajności?

Minimum to trzy warstwy: TCP/IP, load balancer i aplikacja. Na poziomie sieci kluczowe są: SYN backlog, liczba połączeń w stanach SYN-RECV, TIME-WAIT, CLOSE-WAIT, limity PPS/bandwidth u operatora. Na poziomie LB – długość kolejek połączeń i żądań oraz procent backendów „healthy” przy rosnącym ruchu.

Na poziomie aplikacji patrz na:

• skok p95/p99 latencji dla wybranych endpointów,
• nagły wzrost 5xx, 429, 503, 504 przy stabilnym poziomie „normalnych” 4xx,
• restarty procesów, OOM, „connection reset/timeout” w logach.

Jeśli alerty ustawione są tylko na CPU i „is alive”, to reagujesz dopiero przy faktycznej niedostępności. Jeśli masz progi na backlog, kolejki, stany socketów i rozkład kodów HTTP, możesz zatrzymać atak zanim dojdzie do logiki biznesowej.

Jak przygotować infrastrukturę, żeby przetrwała 10x ruch bez natychmiastowego padnięcia?

Podstawą jest świadome ustalenie limitów i back-pressure, zamiast „przyjmujemy wszystko, aż wybuchnie”. Każda warstwa – od edge po bazę – powinna mieć:

• twarde limity połączeń / requestów na klienta i globalnie,
• rozsądne timeouty (connect, read, idle),
• jasno określone zachowanie po przekroczeniu limitu (szybkie 429/503 zamiast zatykania kolejek).

Dodatkowo odciąż kosztowne ścieżki: cache’uj to, co się da, offloaduj TLS, upraszczaj najdroższe zapytania.

Punkt kontrolny: spróbuj zdefiniować dla każdej warstwy „maksimum kontrolowanego przeciążenia”, czyli poziom, przy którym system degraduje się łagodnie (więcej 429/503), ale nie zabija się całkowicie. Jeśli dziś przeciążenie oznacza kaskadę padniętych usług i restartów, architektura nie jest gotowa na 10x ruchu ani na DDoS.

Jakie są wczesne symptomy DDoS w logach i monitoringu, które często są ignorowane?

Bardzo często system „krzyczy”, że jest na granicy, ale nikt tego nie interpretuje. Typowe wczesne symptomy to:

• nagły wzrost „connection reset by peer”, „connection timeout” przy wciąż akceptowalnym CPU,
• przeskok w rozkładzie kodów HTTP – więcej 503/504 i 429 bez zmian w 404/400,
• skrajne obciążenie pojedynczych endpointów lub jednego zakresu IP / AS,
• wzrost liczby pustych user-agentów / nietypowych nagłówków.

W logach systemowych pojawiają się ostrzeżenia o zapełnieniu SYN backlog, out-of-memory, błędy „too many open files”.

Jeśli na te sygnały są zdefiniowane progi alertów z jasną procedurą reakcji, zespół ma szansę zareagować przy pierwszych objawach, a nie po zgłoszeniach klientów. Brak takich alertów sam w sobie jest sygnałem ostrzegawczym dla dojrzałości procesu reagowania na incydenty.

Co warto zapamiętać

• Pierwszy punkt krytyczny w łańcuchu infrastruktury (pasmo, urządzenia brzegowe, load balancer, aplikacja, baza/cache) trzeba mieć nazwany i zmierzony – jeśli przy 10x ruchu nie wiesz, co padnie jako pierwsze, to sygnał ostrzegawczy i dowód, że strategia anty-DDoS opiera się na zgadywaniu.
• Cztery kluczowe zasoby do ochrony to CPU, RAM, sockety i kolejki; bez jasnej identyfikacji, który z nich jest realnym wąskim gardłem, skalowanie poziome staje się drogą i mało skuteczną reakcją zamiast celowanego działania (np. TLS offload, limity keep-alive, ucięcie zbyt długich kolejek).
• Objawy na poziomie systemu są mierzalne i powinny mieć progi alarmowe: stabilnie wysoki CPU, pełna pamięć i swap, stany SYN-RECV / TIME-WAIT / CLOSE-WAIT, błędy „too many open files” oraz rosnące kolejki w LB to punkt kontrolny, że serwis jest już na granicy utraty dostępności.
• Dobrze ustawione backlogi i kolejki (w TCP, load balancerze, workerach) to amortyzator, ale bez limitów zamieniają się w generator gigantycznej latencji i zjadacza RAM; jeśli kolejki są „nieskończone”, to w praktyce akceptujesz scenariusz, w którym system umiera powoli zamiast jasno odrzucać nadmiar ruchu.
• Metryki TCP/IP i load balancera (SYN backlog, liczba połączeń w TIME-WAIT, długość kolejek połączeń i requestów) muszą być monitorowane z progami alertów – jeśli obserwujesz wyłącznie CPU i błędy 5xx, reagujesz dopiero wtedy, gdy DDoS przeszedł już wszystkie wcześniejsze warstwy obrony.