Wewnątrz ataku DDoS na aplikację webową: co widzi admin, co widzi użytkownik, a co napastnik

Krótka scena ataku – jak wygląda „dzień z DDoS-em”

Poranek, który nie zapowiada niczego złego

O 9:02 dział sprzedaży zgłasza, że leady z formularza nie wpadają do CRM. O 9:07 support odbiera pierwsze telefony: „strona się nie ładuje”, „płatność nie przechodzi”, „czy macie awarię?”. W Slacku zaczyna się gorący kanał „#incident”. Biznes widzi jedno: aplikacja webowa praktycznie nie działa, a to oznacza utracone zamówienia, niezadowolonych klientów, presję z góry.

W tym samym czasie monitoring wysyła serię alertów: rosnące opóźnienia odpowiedzi HTTP, zwiększona liczba błędów 502/503, nagły skok liczby aktywnych połączeń. Z perspektywy „biznesu” to po prostu awaria. Z perspektywy administratora – coś znacznie bardziej specyficznego: podejrzenie ataku DDoS na aplikację webową.

Perspektywa administratora: alerty zamiast kawy

Administrator loguje się na panele monitoringu. Widzi wykresy: czas odpowiedzi API x3, użycie CPU na serwerach aplikacyjnych skacze z 30–40% do 90–100%. Load balancer raportuje tysiące nowych połączeń na sekundę, znacząco powyżej średniej. W logach serwera WWW wysyp żądań do jednego lub dwóch endpointów. Zaczyna się klasyczna gra: czy to awaria wewnętrzna, czy już symulacja ataku DDoS na www w wersji produkcyjnej.

Admin szybko sprawdza kanały marketingu: czy jest kampania, newsletter, akcja promocyjna? Ruch rośnie, ale patterny są „brudne”: mnóstwo podobnych User-Agent, dziwne nagłówki, powtarzalne IP z całego świata, brak cookie lub dziwne sekwencje zapytań. Coraz wyraźniej rysuje się scenariusz – atak DDoS na warstwę aplikacyjną.

Perspektywa użytkownika: „to chyba coś z moim internetem”

Kiedy użytkownik wchodzi na stronę, widzi pozornie zwykły ekran ładowania. Tyle że trwa to nie 1–2 sekundy, ale 10, 20, czasem 30 sekund, by w końcu zakończyć się komunikatem błędu. Przeglądarka zaczyna pokazywać: 502 Bad Gateway, 503 Service Unavailable albo po prostu „Strona nie odpowiada”. Formularze wysyłane są dwa razy, sesje wygasają, koszyk w sklepie „zapomina” produkty.

Nowy odwiedzający rezygnuje po kilku próbach. Stały klient spróbuje jeszcze raz za godzinę, ale jeśli to okres kampanii lub gorącej sprzedaży, traci cierpliwość. Integracje partnerów API zaczynają zwracać błędy, ich systemy przechodzą w tryb awaryjny. Na zewnątrz widać tylko tyle: serwis jest niestabilny. Nikt poza zespołem technicznym nie widzi, że to efekt świadomej, zorganizowanej akcji.

Perspektywa napastnika: panel, skrypty, testy skuteczności

Napastnik, który zainicjował atak, patrzy na sprawę chłodno i technicznie. Uruchomił botnet, usługę DDoS-as-a-Service albo własny zestaw skryptów, nakierowując ogromną liczbę zapytań HTTP na twoją aplikację webową. Na ekranie widzi wykres generowanego ruchu, listę celów, podstawowe statystyki odpowiedzi HTTP. Im więcej odpowiedzi 503 i im gorsze czasy odpowiedzi – tym „lepiej” z jego perspektywy.

Testuje różne warianty: zmiana endpointu (np. z / na /search lub /checkout), inne nagłówki, różne metody HTTP. Obserwuje, czy jakieś filtry WAF zaczynają odfiltrowywać ruch, czy pojawia się CAPTCHA, czy adres IP celu zmienia się na inny (przełączenie przez CDN lub scrubbing center). Dla niego to gra w kotka i myszkę z twoją infrastrukturą.

Jaką masz intencję, patrząc na tę scenę?

Zanim przejdziesz głębiej, zatrzymaj się na chwilę: jaki masz cel? Chcesz lepiej diagnozować symptomy ataku, nauczyć się o nim raportować w prosty sposób, przygotować playbook incydentu DDoS, czy może szkolić zespół (red team / blue team), korzystając z takiego scenariusza? Od odpowiedzi zależy, na czym skupisz się w praktyce: narzędziach monitoringu, komunikacji z biznesem czy wchodzeniu w buty napastnika.

Podstawy ataku DDoS na aplikację webową – co to właściwie jest

DoS vs DDoS – dlaczego rozproszenie robi różnicę

Atak typu DoS to sytuacja, w której jedno źródło (jeden host, jedna maszyna) próbuje przeciążyć twoją usługę. DDoS (Distributed Denial of Service) rozkłada tę aktywność na dziesiątki, setki lub tysiące źródeł. To może być botnet z zainfekowanych komputerów, sieć serwerów VPS albo usługa kupiona „na godziny” w podziemnym serwisie.

Rozproszenie powoduje kilka skutków:

• trudniej zablokować pojedyncze IP – bo są ich tysiące,
• ruch wygląda „naturalniej” – bo pochodzi z różnych krajów, AS-ów, a czasem nawet z legalnych sieci (np. zainfekowane IoT),
• trudniej odróżnić atak od prawdziwego „piku” – np. po kampanii marketingowej.

Dla administratora oznacza to, że proste reguły „zablokuj IP X” przestają być skuteczne. Potrzebne jest rozumienie wzorców ruchu i zachowania aplikacji na poziomie warstwy aplikacyjnej.

Warstwy ataków: L3/L4 kontra L7

Ataki DDoS często dzieli się na:

• L3/L4 (sieciowe/transportowe) – zalew pakietów ICMP, SYN flood, UDP flood; celem jest zajęcie łącza, routerów, firewalli.
• L7 (aplikacyjne) – ataki na poziomie protokołu HTTP/HTTPS; celem jest logika aplikacji webowej, jej endpointy, mechanizmy cache, bazy danych.

Skoro interesuje cię atak na aplikację webową, kluczowa jest warstwa L7. Ruch przechodzi przez sieć, load balancer, często przez CDN, czasem przez WAF. Dopiero na poziomie konkretnych żądań HTTP ujawnia się, że coś jest nie tak: ogromna liczba zapytań do jednego endpointu, brak normalnej nawigacji po stronie, zupełnie nienaturalne parametry zapytań.

Atak L7 bywa trudniejszy do wykrycia niż czyste zalanie łącza. Łącze może być w normie, a mimo to CPU aplikacji jest wyciśnięte do granic, baza danych dusi się na skomplikowanych zapytaniach, a w logach HTTP niby wszystko jest „200 OK”, ale użytkownicy i tak nic nie mogą zrobić.

Typowe scenariusze ataków na aplikację webową

Na poziomie aplikacji można zaobserwować kilka powtarzalnych wzorców ataków DDoS:

• HTTP GET/POST flood – wiele prostych zapytań do strony głównej lub innego, lekkiego endpointu, ale w takiej ilości, że serwery nie wyrabiają.
• Atak na ciężki endpoint – np. wyszukiwarka produktów, raport generujący duże zestawienia, koszyk z wieloma operacjami na bazie; tu liczy się nie tyle liczba zapytań, ile ich „ciężar” obliczeniowy.
• Atak na API – celowane w konkretne metody /api/, często bez frontu webowego, ale krytyczne dla działania aplikacji mobilnej lub partnerów.
• Ataki „low & slow” – np. powolne wysyłanie nagłówków, utrzymywanie połączeń maksymalnie długo, aby wyczerpać pulę workerów serwera WWW.

Czy w twojej aplikacji jest „ten jeden” endpoint, o którym każdy admin wie, że potrafi zabić serwery? Jeśli tak, to potencjalnie najlepszy cel dla napastnika.

Duży wolumen kontra inteligentnie dobrany ruch

Popularne wyobrażenie o DDoS to „gigantyczne ilości ruchu”. Rzeczywistość jest subtelniejsza. Czasami kilkanaście tysięcy dobrze dobranych zapytań na sekundę do jednego ciężkiego endpointu jest skuteczniejsze niż miliony lekkich żądań do strony głównej.

Jeśli masz np. zapytanie wyszukujące po wielu kolumnach w bazie, z licznymi joinami, a do tego generujące skomplikowany widok HTML, każde żądanie może kosztować znacznie więcej CPU i I/O niż zwykłe wyświetlenie statycznej podstrony. Napastnik, który rozumie logikę aplikacji, potrafi tak dobrać parametry (np. szerokie zakresy dat, sortowanie po ciężkich kolumnach), że stosunkowo niewielki ruch dusi cały backend.

Motywacje napastników – nie zawsze chodzi o ciebie

Dlaczego ktoś miałby inwestować czas, pieniądze i ryzyko w atak DDoS na twoją aplikację webową? Zwykle przewijają się cztery motywacje:

• Szantaż finansowy – „zapłać, inaczej sparaliżujemy ci biznes”.
• Konkurencja – mniej eleganckie zagranie, szczególnie w branżach o dużej presji (e-commerce, bukmacherka, gry online).
• „Sport” i ego – testowanie możliwości, chęć pochwalenia się w zamkniętych społecznościach.
• Zasłona dymna – DDoS jako odwrócenie uwagi od innego włamania (np. kradzież danych, ransomware).

Przy omawianiu incydentu w zespole technicznym i biznesowym opłaca się mieć przygotowane kilka realistycznych scenariuszy motywacji. Pomaga to w decyzjach: czy współpracować z policją, jak komunikować sprawę klientom, czy spodziewać się równoległych prób włamań.

Co widzi admin: sygnały ostrzegawcze, które pojawiają się jako pierwsze

Infrastruktura „krzyczy” pierwsza: CPU, RAM, I/O, połączenia

Z punktu widzenia administratora pierwsze, co rzuca się w oczy, to anomalia w metrykach. Na co patrzysz najczęściej, gdy coś zaczyna się dziać?

• CPU – skok do 80–100% na serwerach aplikacyjnych lub bazodanowych, utrzymujący się przez dłuższy czas.
• RAM – gwałtowny wzrost zużycia pamięci, rosnący cache, większa liczba procesów serwera WWW.
• I/O dysku – kolejki I/O, wzrost opóźnień zapisu/odczytu, szczególnie przy endpointach bazodanowych.
• Liczba aktywnych połączeń – NAT, load balancer i serwer WWW raportują nagły wzrost establishowanych i półotwartych połączeń.
• Czas odpowiedzi – średni i percentyle (p95, p99) przeskakują kilka razy ponad normę.

Jeśli korzystasz z APM (Application Performance Monitoring, np. New Relic, Datadog, Elastic APM), zauważysz gwałtowny skok w czasie odpowiedzi dla konkretnych endpointów albo klas metod. To właśnie tam warto zacząć śledzenie, które fragmenty aplikacji są wąskim gardłem w czasie ataku.

Wzorce na wykresach: nagłe skoki, „piła”, plateau

Atak DDoS na aplikację webową ma swoje charakterystyczne kształty na wykresach:

• Nagły pionowy skok – z relatywnie stabilnego poziomu na wysoki wolumen w ciągu minut (czasem sekund).
• „Piła” – napastnik włącza i wyłącza atak, testując reakcje, modulując intensywność (np. 5 minut ataku, 5 minut przerwy).
• Plateau – stały, bardzo wysoki poziom ruchu bez typowej dziennej krzywej (rano/południe/wieczór).

Przy atakach L7 ciekawe są też wykresy po stronie WAF lub CDN: nagły wzrost liczby odrzuconych żądań, większa liczba trafień w reguły bezpieczeństwa lub saturacja określonych tras sieciowych. Wiele systemów ma gotowe playbooki incydentu DDoS, które aktywują się po rozpoznaniu takiego wzorca.

Logi serwera WWW i aplikacji: ślady w User-Agent, URI, IP

Jeśli w trakcie incydentu zaglądasz do logów (a jeśli nie – co już próbowałeś zamiast tego?), szukaj nienaturalnych wzorców. Pojawiają się one w kilku miejscach:

• URI – powtarzalne żądania do jednego endpointu (np. /search, /login, /api/orders) z niewielkimi wariacjami parametrów.
• User-Agent – setki tysięcy żądań z tym samym lub bardzo podobnym UA, lub przeciwnie – losowe UA, ale o dziwnie podobnej strukturze.
• IP – IP z wielu krajów, ale z tych samych AS (te same dostawcy VPS), albo charakterystyczny „szum” z sieci znanych z botnetów.
• Metody HTTP – nadmiar POST, które są cięższe od GET, albo rzadko używane metody (PUT, PATCH) w dużych wolumenach.
• Nagłówki – brak nagłówków typowych dla przeglądarek (Accept-Language, Referer), dziwne kombinacje Content-Type, losowe wartości.

Analiza logów przy DDoS pozwala nie tylko zidentyfikować atak, ale też zaplanować reguły obronne: blokady IP, reguły WAF, filtrowanie według User-Agent czy ograniczanie częstotliwości dla wybranych URI.

Szczyt kampanii marketingowej czy DDoS? Jak odróżnić te scenariusze

Ruch biznesowy kontra atak: proste testy zdrowego rozsądku

Najpierw spójrz na podstawową rzecz: czy wzrost ruchu pasuje do kalendarza? Masz kampanię, mailing, premierę produktu, występ w mediach? Jeśli nie – już zapala się pierwsza lampka. Jeśli tak – zapytaj siebie: czy wykresy zachowują się jak przy wcześniejszych akcjach marketingowych?

Możesz przeprowadzić kilka szybkich testów:

• Konwersje – jeśli sesje rosną, ale liczba rejestracji, logowań czy transakcji stoi w miejscu lub spada, coś jest nie tak.
• Ścieżka użytkownika – normalny ruch „płynie” po stronie: strona główna → produkt → koszyk. Atak będzie przypominał setki tysięcy wejść w jedno miejsce bez dalszych kroków.
• Różnorodność źródeł – prawdziwa kampania daje ruch z wielu kanałów: social, direct, referral. Atak często jest skupiony w jednym typie (np. „direct / no referrer”).

Masz pod ręką analitykę (GA, Matomo, in-house)? Sprawdź, czy rosną również zdrowe wskaźniki biznesowe, czy tylko „puste” odsłony. Jeśli rosną tylko odsłony i błędy, prawdopodobieństwo DDoS właśnie wzrosło.

Sygnatura geograficzna i technologiczna ruchu

Rzut oka na geolokalizację i technologie użytkowników często mówi więcej niż 10 stron logów. Jak to wygląda w praktyce?

• Geografia – jeśli normalnie 90% ruchu masz z Polski, a nagle połowa pochodzi z kilkunastu egzotycznych krajów, coś tu nie gra.
• Przeglądarki i systemy – naturalny ruch to miks Chrome, Safari, Firefox, różne wersje Androida i iOS. Atak to czasem setki tysięcy zapytań z jednego „Chrome/99.0” na „Windows NT 10.0”.
• Rozdzielczości ekranów – użytkownicy mają dziesiątki różnych rozdzielczości. Boty często wyglądają jak powielony wzór lub wręcz „brak danych”.

Zadaj sobie pytanie: czy ten nagły napływ użytkowników wygląda jak prawdziwi ludzie, czy jak skrypt, który próbuje ich udawać? Jeśli coś ci „nie pachnie”, zaufaj intuicji i przejdź głębiej w dane.

Reakcja aplikacji: czy system „skaluje się jak zwykle”

Przy normalnych pikach (np. kampania) system zwykle skaluje się zgodnie z planem: autoscaling dodaje instancje, cache grzeje się na popularnych stronach, a ty głównie obserwujesz.

Przy DDoS widać inne zachowanie:

• Cache – zamiast rosnącego odsetka hitów, rosną cache-missy, bo zapytania są zbyt losowe albo uderzają w endpointy z pominięciem cache.
• Autoscaling – instancje są dokładane agresywnie, ale średni czas odpowiedzi nadal rośnie, bo atak celuje w wąskie gardła (np. bazę danych), których nie da się „doskalować w minutę”.
• Kolejki – rosną kolejki zadań asynchronicznych, które normalnie opróżniają się na bieżąco.

Jeśli system „rozjeżdża się” mimo poprawnie działającego autoscalingu, odpowiedź na pytanie „kampania czy atak?” przesuwa się w stronę DDoS.

Co widzi użytkownik: symptomy DDoS widziane z zewnątrz

Użytkownik nie patrzy w metryki, tylko w ekran. Z jego perspektywy jest prościej: „działa” albo „nie działa”. Jakie sygnały świadczą o tym, że problemem nie jest tylko mała awaria, ale możliwy DDoS?

Powolne ładowanie, time-outy i błędy 5xx

Jeśli chcesz zobaczyć aplikację oczami użytkownika, odpowiedz sobie: jak szybko odpalasz stronę, gdy dostajesz 502/504? Większość osób po kilku sekundach po prostu rezygnuje.

Typowe objawy po stronie użytkownika to:

• Wydłużony czas ładowania – strona główna ładuje się kilkanaście–kilkadziesiąt sekund, część zasobów (JS, CSS, obrazki) w ogóle nie dochodzi.
• Time-outy – przeglądarka sygnalizuje „przekroczono limit czasu żądania”, użytkownik wielokrotnie odświeża stronę bez efektu.
• Błędy serwera – 500, 502, 503, 504 pojawiają się losowo lub na konkretnych podstronach (np. logowanie, wyszukiwarka, checkout).

Użytkownik tego nie klasyfikuje. Dla niego to po prostu „firma X znowu ma problemy”. Twoim zadaniem jest połączyć te skargi z tym, co widzisz w logach i metrykach.

Niespójne działanie części funkcji

Przy klasycznej awarii system często „siada” w całości. Przy DDoS na aplikację bywa inaczej: jedne elementy działają, inne padają pod obciążeniem ataku.

Z zewnątrz może wyglądać to tak:

• Strona główna ładuje się poprawnie, ale logowanie trwa w nieskończoność lub kończy się błędem.
• Przeglądanie katalogu produktów działa, natomiast dodaniew koszyka zawiesza przeglądarkę.
• Aplikacja mobilna zgłasza „błąd połączenia z serwerem”, podczas gdy wersja webowa wciąż jakoś funkcjonuje.

Masz zgłoszenia z supportu typu „jedni klienci mówią, że wszystko OK, inni że w ogóle nie mogą się zalogować”? To klasyczny objaw selektywnego ataku na konkretne ścieżki.

Nasilenie problemów w „dziwnych” godzinach

Normalny ruch użytkowników ma rytm: rano, popołudnie, wieczór. Atakujący często wybierają godziny, które są dla nich wygodne, ale dla ciebie – najmniej obsadzone (np. noc, weekend). Zdarzają się też ataki w godzinach szczytu, żeby zmaksymalizować efekt.

Użytkownik może zauważyć, że:

• Wieczorem, gdy chce zrobić szybkie zakupy po pracy, serwis „mulii” bardziej niż zwykle.
• Problemy pojawiają się powtarzalnie w tych samych godzinach lub dniach tygodnia.

Masz monitoring zgłoszeń do helpdesku lub liczby nieudanych transakcji w czasie? To dobry wskaźnik, żeby skorelować czas odczuć użytkownika z twoimi wykresami.

Jak użytkownicy reagują i jak to widać w danych

Użytkownik nie pisze w logu „to był DDoS”. Zostawia jednak ślad w postaci zachowania:

• Odświeżanie – gwałtowny wzrost liczby odświeżeń tej samej strony po stronie klienta, skrócenie średniego czasu sesji.
• Porzucenia koszyka – rośnie liczba koszyków bez finalizacji płatności na etapie, który akurat jest „duszony” atakiem.
• Wzrost ruchu z social media – użytkownicy zaczynają pisać publicznie, że strona nie działa; linkują, screeny trafiają na Twittera, Facebooka, fora.

Masz zespół obsługi klienta? Zapytaj ich wprost: co dokładnie mówią klienci? Czasem jedno trafne zdanie w zgłoszeniu („logowanie nie działa, ale stronę widzę”) skraca diagnozę o godzinę.

Co widzi napastnik: narzędzia, metryki i ograniczenia atakującego

Panel „DDoS-as-a-Service” kontra własny botnet

Z perspektywy napastnika atak na aplikację webową to niekoniecznie skomplikowana operacja. Często sprowadza się do kliknięcia w panelu sprzedawcy usług DDoS. Schemat jest prosty:

• wskazujesz domenę lub adres IP ofiary,
• wybierasz typ ataku (HTTP flood, mixed, „bypass Cloudflare” itp.),
• ustawiasz czas trwania i czasem intensywność (ruch na poziomie „light/medium/hard”).

Taki „panel” raportuje często podstawowe metryki: szacunkowy wolumen wysłanego ruchu, procent skutecznych połączeń, czas odpowiedzi serwera ofiary. To okrojony, ale dla napastnika wystarczający widok – wie, czy serwis „siadł”, czy trzeba coś zmienić.

Bardziej zaawansowany napastnik korzysta z własnego botnetu lub VPS-ów. Ma wtedy większą kontrolę nad:

• rodzajem generowanych żądań (pełne HTTP/2, TLS, niestandardowe nagłówki),
• profilowaniem ruchu (tempo, rozkład w czasie, „udawanie ludzi”),
• lokalizacją i jakością węzłów (szybkie łącza, brak ograniczeń operatora).

Zastanów się: jak bardzo Twój system przypomina cel, który widać z takiego panelu? Czy prosta zmiana domeny, IP albo konfiguracji WAF może nagle „zepsuć” napastnikowi statystyki?

Co atakujący mierzy podczas ataku

Napastnik, który nie mierzy, strzela na ślepo. Bardziej świadomy obserwuje kilka prostych, ale kluczowych wskaźników:

• Czy serwis odpowiada – proste health-checki: HTTP 200, kod odpowiedzi, czas ładowania.
• Zewnętrzne monitory – publiczne narzędzia typu uptime monitor, które pokazują dostępność i czas odpowiedzi z różnych regionów.
• Reakcje infrastruktury – pojawienie się CAPTCHA, stron „Under heavy load”, komunikatów od WAF lub CDN.
• Zmiany DNS/IP – czy ofiara przełącza ruch na inny adres, inny CDN, inną regionę chmurową.

Jeśli nagle aktywujesz np. „Under Attack Mode” w CDN, napastnik widzi to po stronie swojej przeglądarki lub skryptu i może zacząć eksperymentować z innym wektorem.

Feedback z aplikacji: błędy, limity, throttling

Dobrze skonfigurowany system obrony nie tylko blokuje ruch, ale też daje atakującemu mylący feedback. Jak wygląda to z jego perspektywy?

• Kody HTTP 429/503 – informacja o limitach albo chwilowej niedostępności; dla napastnika sygnał, że trafił w rate-limity lub mechanizmy przeciążeniowe.
• Losowe opóźnienia – jeżeli celowo spowalniasz odpowiedzi przy zbyt częstych żądaniach, atakujący widzi „mulący” serwer i trudniej mu ocenić, ile faktycznie osiąga.
• Zwroty z WAF/CDN – strony błędu od pośredników (np. 5xx od CDN) sugerują, że ruch zatrzymuje się przed aplikacją; napastnik będzie wtedy próbował innego typu ruchu lub innej ścieżki (np. omijającej CDN).

Masz wdrożone mechanizmy, które nie tylko bronią, ale też utrudniają napastnikowi pomiar skuteczności? To często decyduje, czy szybko się podda, czy będzie eskalował.

Ograniczenia napastnika: budżet, ryzyko, infrastruktura

Z zewnątrz atak DDoS wygląda jak „nieograniczona moc”. W rzeczywistości napastnik ma konkretne ograniczenia. Jakie?

• Budżet – usługi DDoS-as-a-Service kosztują. Im dłużej i mocniej, tym drożej. Jeśli Twoja obrona sprawia, że musi podnieść „pakiet”, może szybko uznać, że to się nie opłaca.
• Ryzyko prawne – korzystanie z pewnych węzłów (np. własne VPS-y, sieci z dobrą współpracą z organami ścigania) zwiększa szansę namierzenia. Im więcej musi używać „ryzykownych” zasobów, tym większy stres po drugiej stronie.
• Jakość botnetu – zainfekowane urządzenia IoT, stare systemy, słabe łącza – to nie zawsze idealny „materiał” do ataku na nowoczesne, dobrze zabezpieczone aplikacje.
• Ukrywanie się – jeśli zaczynasz agresywnie filtrować ruch, napastnik musi bardziej „udawać użytkowników”, co zmniejsza efektywną moc ataku.

Zadaj sobie pytanie: jak możesz zwiększyć koszt ataku dla napastnika, nie rujnując swojego budżetu? Czasem wystarczą dobrze ustawione limity i dynamiczne reguły WAF, by „podnieść poprzeczkę” na tyle wysoko, że atakujący wybierze łatwiejszy cel.

Jak napastnik bada aplikację przed atakiem

Skuteczny atak L7 zaczyna się nie od włączenia flooda, tylko od rozpoznania. Napastnik sprawdza:

• Strukturę aplikacji – mapuje URL-e, parametry, endpointy API, ścieżki logowania, rejestracji, wyszukiwania.
• Czas odpowiedzi – mierzy, które endpointy są najwolniejsze i najbardziej zasobożerne.
• Mechanizmy cache – próbuje odróżnić treści statyczne od dynamicznych, sprawdza nagłówki cache-control, ETag, vary.
• Ochronę WAF/CDN – identyfikuje, jak szybko i na co reaguje WAF, czy CDN pokazuje się w nagłówkach, czy domena ma alternatywne wejścia (np. poddomeny, inne IP).

Co już próbowałeś, żeby utrudnić takie rozpoznanie? Ukrywanie „ciężkich” endpointów za dodatkowymi warstwami (np. autoryzacją, osobnymi domenami, inną polityką cache) potrafi znacząco zmniejszyć ich atrakcyjność jako celu.

Jak przełożyć „trzy perspektywy” na konkretny plan obrony

Mapa sygnałów: admin – użytkownik – napastnik

Masz już trzy różne „okna” na ten sam atak. Pytanie: jak je połączyć w jedno spójne narzędzie decyzyjne?

Praktyczny krok: zbuduj prostą mapę sygnałów. Wystarczy arkusz lub tablica, na której w trzech kolumnach wpiszesz:

• Co widzi admin – konkretne metryki i logi, np. „wzrost 5xx na /checkout”, „skok RPS na /login z jednego kraju”.
• Co widzi użytkownik – typowe skargi i zachowania, np. „strona długo się ładuje po logowaniu”, „nie mogę opłacić zamówienia”.
• Co może widzieć napastnik – to, co wynika z konfiguracji: „włączony Under Attack Mode”, „błąd 503 przy przekroczeniu limitu”, „dłuższe czasy odpowiedzi przy rate-limitach”.

Zastanów się: czy dziś potrafisz szybko sparować zgłoszenie użytkownika z konkretnym wykresem i logiem? Jeśli nie, zacznij od dwóch–trzech najważniejszych ścieżek (logowanie, koszyk, płatności) i zrób im pełne „przełożenie” na metryki i komunikaty.

Definicja „zdrowia” aplikacji na czas ataku

Podczas DDoS nie zawsze celem jest „100% dostępności dla wszystkich”. Często ważniejsze jest, by krytyczne funkcje przeżyły kosztem reszty. Jak to nazwać i zmierzyć?

Ustal sobie proste, ale jasne definicje:

• Minimalne SLA na czas ataku – np. „95% prób logowania kończy się powodzeniem w 10 s”, „80% płatności przechodzi do operatora w pierwszej próbie”.
• Kolejność priorytetów – co wolisz poświęcić: statyczną stronę główną, wyszukiwarkę produktów, historię zamówień?
• Akceptowalne ofiary – np. użytkownicy spoza kluczowych krajów, starsze API mobilne, rzadko używane funkcje panelu admina.

Jaki masz cel podczas ataku: pełna dostępność, czy ochrona przychodów i kluczowych klientów? Odpowiedz szczerze, a potem skonfiguruj mechanizmy obronne tak, by „wiedziały”, co mogą odcinać jako pierwsze.

Segmentacja funkcji: co musi działać, a co możesz „przydusić”

Jeśli cała aplikacja to jeden monolit z jedną pulą zasobów, atak L7 ma prostsze zadanie. Gdy masz wyraźnie oddzielone warstwy, możesz świadomie decydować, co poświęcić.

Spójrz na swoją aplikację jak na zespół usług:

• Warstwa prezentacji – strony informacyjne, katalogi, landing pages.
• Warstwa transakcyjna – logowanie, rejestracja, koszyk, płatności.
• Panel administracyjny i narzędzia wewnętrzne – raporty, eksporty, integracje.

Przy DDoS zadaj sobie pytanie: co może zwolnić zasoby na backendzie?

• Przekierowanie części ruchu informacyjnego na statyczny mirror (np. S3 + CDN) – użytkownik dalej widzi stronę, ale bez kosztownych zapytań do bazy.
• Tymczasowe wyłączenie ciężkich raportów dla adminów – mniejsza szansa, że dobijesz bazę dodatkowymi zapytaniami.
• Ograniczenie częstości odświeżania w real-time dashboardach lub streamingach.

Co już próbowałeś: masz osobną infrastrukturę dla strony głównej i dla API? Czy wszystko biegnie przez te same serwery aplikacyjne i tę samą bazę?

Projektowanie obrony „od perspektywy napastnika”

Ukrywanie ciężkich endpointów za dodatkowymi warstwami

Napastnik szuka najdroższych operacji, które da się wywołać masowo. Twoim zadaniem jest sprawić, by te operacje:

• były trudne do odkrycia przy anonimowym skanowaniu,
• wymagały dodatkowych kroków (sesja, token, captcha, reputacja IP),
• były rozproszone na tyle, by atak na jeden nie zabił całego systemu.

Przykładowe ruchy:

• Najcięższe zapytania wyszukiwania lub filtrowania zamknij za wymogiem zalogowania lub specjalnym uprawnieniem.
• Wrażliwe endpointy API (np. generowanie raportów, eksporty) odseparuj na inną domenę lub subdomenę bez publicznych linków.
• Transakcje, które szczególnie obciążają bazę, zabezpiecz dodatkowymi tokenami jednorazowymi, trudniejszymi do masowego odtwarzania.

Sprawdź, które URL-e w twoich logach mają najdłuższy czas wykonania. Czy każdy anonimowy użytkownik może je wywołać tak samo łatwo, jak stronę główną?

Świadome „zanieczyszczanie” sygnałów dla atakującego

Napastnik bazuje na prostych wskaźnikach: kody odpowiedzi, czas reakcji, stabilność błędów. Jeśli zrobisz je mniej przewidywalnymi, trudniej będzie mu optymalizować atak.

Kilka praktyk, które możesz połączyć z rate-limitem i WAF:

• Losowe opóźnienia tylko dla podejrzanego ruchu – np. requesty z niską reputacją IP dostają dodatkowe 200–800 ms, zamiast jasnego „429”.
• Zróżnicowane odpowiedzi – raz 429, raz 503, raz strona błędu od CDN. Napastnik nie widzi prostego „próg = X RPS, powyżej zawsze 429”.
• Degradacja treści – dla „prawie zablokowanych” klientów zwracasz uproszczoną stronę bez ciężkich operacji (mniej JS, brak zaawansowanych filtrów), ale formalnie z kodem 200.

Jakie masz obecnie polityki rate-limitu? Czy da się z twoich logów łatwo odczytać, gdzie dokładnie stoją progi i jak się zmieniają w czasie?

Różne poziomy trudności dla różnych profili ruchu

Nie musisz traktować wszystkich klientów tak samo. Właściwie zrobiona segmentacja może sprawić, że atakujący będzie miał „tryb hard”, a twoi stali użytkownicy – „tryb easy”.

Możesz rozróżniać:

• Zaufane IP/ASN – np. klienci biznesowi, partnerzy, ważne biura. Dla nich wyższe limity, mniej CAPTCHA.
• Nowe i „szare” IP – z nich zaczynasz od ostrzejszych limitów, szybszej eskalacji do blokady, łatwiejszego włączania dodatkowych zabezpieczeń.
• Profile sesji – klient, który klika jak człowiek (czas między żądaniami, nawigacja po stronach), ma inną ścieżkę niż klient, który „mieli” ciągle ten sam endpoint.

Jak dziś definiujesz „normalny” ruch? Czy masz chociaż prosty podział: nowi vs powracający użytkownicy, mobilni vs desktop, kraj A vs reszta świata?

Operacyjne reagowanie: jak połączyć obserwacje w czasie rzeczywistym

Checklista „czy to już DDoS na aplikację”

W ferworze kryzysu łatwo panikować. Dobrze mieć krótką checklistę, która w kilka minut pozwala odróżnić problem wydajnościowy od ataku.

Przykład takiej listy:

• Czy ruch wzrósł nietypowo (ilościowo lub strukturalnie: więcej POST/PUT, więcej hitów na konkretny URL)?
• Czy rozkład geograficzny lub ASN nagle się zmienił (nowy kraj, nowe sieci, podejrzane hostingi)?
• Czy użytkownicy zgłaszają te same symptomy na określonej ścieżce (np. tylko logowanie, tylko płatność)?
• Czy zewnętrzne monitory widzą problem wszędzie, czy tylko z części regionów?
• Czy w logach widać powtarzalne wzorce nagłówków, user-agentów, sekwencji zapytań?

Masz już taką checklistę spisaną i dostępną dla dyżurnego admina lub SRE? Czy wciąż wszystko siedzi tylko w głowie jednej osoby „od bezpieczeństwa”?

Rozdzielenie ról: kto patrzy na wykresy, kto słucha użytkowników

Podczas ataku info spływa z kilku stron: monitoring, helpdesk, social media, sprzedaż. Jeśli każdy robi wszystko naraz, gubisz kontekst. Lepszy model to jasny podział.

Możesz zorganizować reakcję tak:

• Osoba „od wykresów” – patrzy w metryki, logi, WAF, podejmuje decyzje o regułach i limitach.
• Osoba „od użytkowników” – zbiera zgłoszenia z helpdesku, social mediów, kanałów sprzedażowych i tłumaczy je na konkretne ścieżki / funkcje.
• Osoba „od biznesu” – scala informacje i odpowiada na kluczowe pytanie: co możemy wyłączyć lub ograniczyć, żeby ratować core biznesowy.

Kto u ciebie w firmie faktycznie decyduje w pierwszych 15 minutach ataku? Czy wszyscy wiedzą, kogo słuchać, gdy metryki zaczynają wariować?

Eksperymenty w trakcie ataku: małe zmiany, szybka ocena

DDoS L7 bywa dynamiczny. Jedna reguła WAF potrafi uciszyć falę, ale równie dobrze może przerzucić atak na inną ścieżkę lub wyciąć za dużo legalnych użytkowników. Z tego powodu reagowanie warto prowadzić małymi krokami.

Praktyczny schemat działania:

1. Wprowadź minimalną zmianę – np. zaostrz limit na konkretnym URL lub włącz dodatkową warstwę CAPTCHA tylko dla jednego kraju.
2. Obserwuj trzy perspektywy:
   • metryki (RPS, błędy, CPU, opóźnienia),
   • głos użytkownika (czy helpdesk widzi poprawę czy nowe problemy),
   • zachowanie napastnika (czy wzorce ruchu się zmieniły, pojawiły się nowe URL-e w logach).
3. Dostosuj – rozszerz, zawęź, cofnij lub przenieś regułę gdzie indziej.

Masz środowisko testowe, na którym możesz w miarę wiarygodnie zasymulować takie zmiany, czy eksperymentujesz tylko na produkcji?

Przygotowanie „na sucho”: jak trenować dzień z DDoS-em

Symulacje i gry wojenne z użyciem realnych logów

Najbardziej bolesne ataki to te, które zaskakują zespoły, gdy wszyscy uczą się w biegu. Da się temu trochę zaradzić, robiąc proste „gry wojenne” bez konieczności generowania realnego DDoS-a.

Pomysły na ćwiczenia:

• Weź fragment historycznych logów z dnia o największym ruchu. Zmodyfikuj je tak, jakby ktoś dokleił do nich prosty HTTP flood na jeden endpoint. Niech zespół spróbuje go „wyłowić”.
• Przygotuj scenariusz zgłoszeń użytkowników (maile, czat, social media) opisujących różne symptomy. Zadanie zespołu: sparować zgłoszenia z potencjalnymi metrykami i logami.
• Zasymuluj zmianę po stronie napastnika – np. po godzinie atak „przełącza się” z /login na /search. Czy wasze dashboardy to pokażą wprost?

Jak często przechodzisz z zespołem przez taką „suchą” symulację? Czy każdy dyżurny miał choć raz okazję przećwiczyć decyzje, zanim stanie pod ścianą o 3:00 w nocy?

Predefiniowane „tryby pracy” infrastruktury

Zamiast wymyślać wszystko na żywo, łatwiej mieć kilka z góry zdefiniowanych trybów pracy. Coś w rodzaju „profilów mocy” dla ochrony i wydajności.

Na przykład:

• Tryb normalny – standardowe limity, minimalne utrudnienia dla użytkownika, monitoring w tle.
• Tryb podwyższonej czujności – nieco ostrzejsze limity dla anonimów, dodatkowe logowanie podejrzanych wzorców, gotowe reguły w WAF czekające na włączenie.
• Tryb DDoS – agresywne rate-limity na wybranych ścieżkach, większa liczba CAPTCHA, tymczasowe wyłączenie części funkcji, przekierowanie ruchu informacyjnego na statyczny mirror.

Czy dziś przełączenie się w „tryb DDoS” oznacza dla ciebie klikanie w 10 różnych panelach, czy jedno–dwa świadome przełączenia konfiguracji?

Standaryzacja sygnałów dla biznesu i supportu

Admin widzi kody HTTP, RPS i saturację zasobów. Biznes widzi „nie idą płatności”. Support widzi „klienci wściekli na czacie”. Dobrze jest mieć wspólny, prosty słownik opisujący fazy ataku.

Możesz ustalić z zespołami kilka prostych statusów:

• Incydent L7 – lekki – drobne spowolnienia, pojedyncze skargi, działania tylko po stronie WAF i limitów.
• Incydent L7 – poważny – widoczny wpływ na część kluczowych funkcji, aktywacja „trybu DDoS”, komunikat dla klienta biznesowego.
• Incydent L7 – krytyczny – konieczność ograniczenia funkcjonalności i/lub geolokacji, priorytetowy komunikat publiczny.

Najważniejsze punkty

• Ten sam atak DDoS wygląda inaczej dla każdej strony: biznes widzi „awarię i stracone zamówienia”, admin widzi anomalie w metrykach (HTTP 502/503, skok CPU, tysiące połączeń), a napastnik – wykresy skuteczności swojego ruchu. Pytanie: z czyjej perspektywy patrzysz dziś ty?
• Typowy „dzień z DDoS-em” zaczyna się jak zwykła awaria: zgłoszenia z działu sprzedaży, telefony na support, komunikaty błędów w przeglądarce. Dopiero korelacja objawów biznesowych z danymi technicznymi pozwala stwierdzić, że to atak, a nie po prostu błąd w aplikacji.
• Rozproszenie w DDoS (wiele źródeł, różne kraje, botnety, zainfekowane IoT) powoduje, że proste blokowanie IP prawie nie działa. Potrzebujesz rozumienia wzorców ruchu HTTP, nagłówków, zachowania sesji – inaczej będziesz gasić pożar wiadrem wody.
• Ataki L7 na aplikację webową są zdradliwe: łącze i infrastruktura sieciowa mogą wyglądać „normalnie”, podczas gdy CPU aplikacji i baza danych są przeciążone specyficznymi żądaniami HTTP do wybranych endpointów. Zadaj sobie pytanie: monitorujesz tylko sieć, czy też realne zachowanie aplikacji?
• Użytkownik widzi jedynie wolne ładowanie, błędy 502/503, znikające koszyki i wygasające sesje, więc często zakłada, że „coś nie tak z jego internetem” albo po prostu porzuca transakcję. Jeśli chcesz ograniczyć szkody biznesowe, potrzebujesz jasnej komunikacji i planu reakcji także po stronie UX.

Źródła

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Zarządzanie incydentami, w tym atakami DoS/DDoS
• NIST SP 800-184: Guide for Cybersecurity Event Recovery. National Institute of Standards and Technology (2016) – Reagowanie i odtwarzanie po incydentach, scenariusze awarii usług
• ENISA Threat Landscape for DDoS Attacks. European Union Agency for Cybersecurity (ENISA) (2020) – Przegląd typów ataków DDoS, trendy, techniki i skutki biznesowe
• DDoS Open Threat Signaling (DOTS) Architecture. Internet Engineering Task Force (2019) – Architektura wymiany informacji o atakach DDoS, RFC 8811
• OWASP Web Application Security Testing Guide. OWASP Foundation (2020) – Testowanie bezpieczeństwa aplikacji webowych, w tym odporności na DoS
• Microsoft Security Documentation: DDoS Protection and Mitigation. Microsoft – Opis typów ataków DDoS, scenariusze L3/L4/L7 i strategie obrony