Atak DDoS: jak sprawdzić, czy Wasza ochrona naprawdę zadziała
Ochronę przed DDoS ma dziś prawie każdy, w umowie z operatorem albo w panelu CDN. Znacznie mniej firm wie, przy jakim natężeniu ruchu się włącza i który element infrastruktury padnie pierwszy. Jak to ustalić w kontrolowanych warunkach.
Prawie każda firma ma dziś jakąś ochronę przed DDoS: w umowie z operatorem, w panelu CDN albo w konfiguracji hostingu. Znacznie mniej firm wie, przy jakim natężeniu ruchu ta ochrona się włącza, co przepuści i który element infrastruktury padnie pierwszy. Ten tekst jest o tej różnicy.
Czym atak DDoS różni się od zwykłego szczytu ruchu
DDoS to celowe wyczerpanie zasobu, od którego zależy dostępność usługi. Zasobem bywa pasmo łącza, tablica połączeń na firewallu, pula wątków serwera aplikacyjnego albo pula połączeń do bazy danych. Atak nie musi być duży. Musi trafić w ten zasób, którego macie najmniej.
Dlatego porównywanie DDoS do „bardzo dużego ruchu" bywa mylące. Kampania marketingowa też generuje szczyt, ale ma inny rozkład: przychodzi z przeglądarek, respektuje sesje, akceptuje ciasteczka i rozkłada się w czasie. Ruch atakującego jest tani w wytworzeniu i drogi w obsłużeniu. To cała ekonomia tego zjawiska.
Praktyczna konsekwencja: obrona, która sprowadza się do „mamy szerokie łącze", chroni tylko przed jednym z trzech rodzajów ataku. Pozostałe dwa przejdą przez nią bez zauważenia.
Trzy warstwy, trzy zupełnie różne ataki
Rozróżnienie warstw nie jest akademickie: decyduje o tym, które zabezpieczenie w ogóle ma szansę zadziałać. Ochrona kupiona pod jedną warstwę nie przenosi się na pozostałe.
| Warstwa | Co wyczerpuje | Typowe wektory | Co je zatrzymuje |
|---|---|---|---|
| L3-L4 — wolumetryczna | Pasmo łącza i wydajność routingu | UDP flood, amplifikacja DNS i NTP, ICMP flood | Filtrowanie u operatora lub w centrum czyszczenia ruchu, rozproszenie Anycast |
| L3-L4 — protokołowa | Tablice stanów firewalla i load balancera | SYN flood, ataki na fragmentację, wyczerpanie sesji | SYN cookies, limity sesji, urządzenia brzegowe odporne na wyczerpanie stanu |
| L7 — aplikacyjna | Wątki aplikacji, zapytania do bazy, wyszukiwarka | HTTP flood, Slowloris, uderzenia w kosztowne endpointy i koszyk | Analiza zachowania, rate limiting per sesja, strony wyzwania, reguły aplikacyjne |
Największy problem sprawia zwykle trzecia warstwa. Atak aplikacyjny wygląda jak normalny ruch użytkowników, potrafi zmieścić się w kilkuset żądaniach na sekundę i nie uruchamia progów opartych na wolumenie. Usługa przestaje odpowiadać, a wykresy pasma pozostają spokojne.
Dlaczego „mamy ochronę" nie znaczy „jesteśmy odporni"
Ochrona przed DDoS jest zwykle kupowana raz, konfigurowana na starcie i nietykana przez lata. W tym czasie zmienia się wszystko dookoła: dochodzą nowe usługi, część ruchu przenosi się do API, aplikacja dostaje nowe kosztowne endpointy, ktoś wystawia panel administracyjny poza CDN „tymczasowo, na czas migracji".
Powstaje wtedy rozjazd między tym, co chroni umowa, a tym, czym organizacja faktycznie oddycha. Typowe przykłady: rekord DNS wskazujący bezpośrednio na adres origin, który miał zniknąć po wdrożeniu CDN. Subdomena środowiska testowego na tym samym łączu co produkcja. Endpoint API dodany po podpisaniu umowy z operatorem i nieobjęty jej zakresem.
Żadnej z tych rzeczy nie widać w umowie ani w panelu dostawcy. Widać je dopiero wtedy, gdy ktoś sprawdzi albo gdy sprawdzi je atakujący. To jest cała różnica między posiadaniem ochrony a posiadaniem odporności.
Baseline: czego zwykle nie wiadomo o własnej infrastrukturze
Zanim cokolwiek da się przetestować, trzeba wiedzieć, jak wygląda stan normalny i gdzie są granice. Pytania, na które w większości organizacji nie ma gotowej odpowiedzi:
- Które usługi są krytyczne dla przychodu albo dla obowiązku ustawowego, a które mogą być niedostępne przez godzinę bez konsekwencji?
- Ile żądań na sekundę obsługuje aplikacja, zanim czas odpowiedzi przekroczy próg akceptowalny dla użytkownika?
- Który element pada pierwszy: łącze, firewall, warstwa aplikacji czy baza danych?
- Czy jakikolwiek rekord DNS wskazuje bezpośrednio na adres origin z pominięciem warstwy ochronnej?
- Przy jakim natężeniu ruchu włącza się mitygacja u dostawcy i ile trwa, zanim zacznie działać?
- Kto podejmuje decyzję o włączeniu trybu obronnego o trzeciej w nocy i czy ma do tego uprawnienia bez konsultacji?
Ostatnie pytanie bywa najtrudniejsze, bo nie jest techniczne. Procedura, w której krok „decyzja o aktywacji trybu obronnego" nie ma przypisanego właściciela, kosztuje kilkadziesiąt minut uzgodnień, dokładnie wtedy, gdy liczy się każda minuta.
Jak wygląda kontrolowana weryfikacja odporności
Weryfikacja odporności to nie jest ćwiczenie polegające na wywróceniu produkcji. To kontrolowane, uzgodnione i rosnące obciążenie, prowadzone w oknie serwisowym, z ustalonym progiem przerwania i z ręką na wyłączniku. Cel jest jeden: poznać granice, zanim pozna je ktoś inny.
- Etap 1Zespół sieci i właściciele aplikacjiMapowanie i baseline
Inwentaryzacja tego, co faktycznie jest wystawione: domeny, subdomeny, rekordy DNS, endpointy API, panele. Ustalenie wydajności bazowej i progów akceptowalnych dla każdej usługi krytycznej.
- Etap 2Zespół prowadzący weryfikacjęKontrolowane obciążenie
Uzgodnione scenariusze w warstwach od L3 do L7, prowadzone rosnąco, w oknie serwisowym, z twardym progiem przerwania. Chodzi o zlokalizowanie punktu, w którym coś przestaje odpowiadać, a nie o utrzymanie ataku.
- Etap 3Architektura i utrzymanieUtwardzanie
Usunięcie znalezionych obejść warstwy ochronnej, dostrojenie limitów, wprowadzenie stron wyzwania i reguł aplikacyjnych, uporządkowanie progów alertowania i ról decyzyjnych w procedurze.
- Etap 4Zespół prowadzący weryfikacjęWalidacja
Powtórzenie tych samych scenariuszy po zmianach. Bez tego kroku nie wiadomo, czy poprawka zadziałała, czy tylko przesunęła problem w inne miejsce. To ten etap zamienia raport w dowód.
Wynikiem nie jest ocena „przeszliście" albo „nie przeszliście", tylko liczby: przy jakim natężeniu która usługa zwalnia, po ilu sekundach włącza się mitygacja, co przez nią przechodzi i który element wymaga zmiany w pierwszej kolejności.
Warstwy mitygacji: co realnie zatrzymuje ruch
Pojedyncza metoda nie wystarcza, bo każda działa na inny rodzaj ataku i każda ma koszt uboczny. Sensowna obrona układa je warstwami, od najtańszej w skutkach do najbardziej inwazyjnej.
| Metoda | Na co działa | Czym za to płacicie |
|---|---|---|
| Rozproszenie Anycast i CDN | Ataki wolumetryczne (rozkłada ruch na wiele lokalizacji) | Nie pomaga, jeśli origin da się wykryć i uderzyć bezpośrednio |
| Rate limiting | Ataki aplikacyjne o powtarzalnym wzorcu | Zbyt ostry limit odcina realnych użytkowników za NAT-em operatora |
| Blokowanie geograficzne | Kampanie z wyraźnie obcego obszaru | Bezużyteczne wobec botnetu z tego samego kraju, blokuje klientów z zagranicy |
| Strony wyzwania | Ruch automatyczny udający przeglądarkę | Pogarsza dostępność i psuje integracje maszynowe oraz API |
| Czyszczenie ruchu u operatora | Duże ataki wolumetryczne poza Waszym łączem | Czas przekierowania ruchu, w którym usługa jest już niedostępna |
Kolumna po prawej jest tą, o której najczęściej się zapomina. Każda z tych metod potrafi zaszkodzić własnym użytkownikom, jeśli włączy się ją w panice i bez wcześniejszego sprawdzenia, jak zachowa się przy normalnym ruchu.
DDoS jako zasłona dla czegoś innego
Nie każdy atak DDoS ma na celu niedostępność. Bywa hałasem, który ma zająć zespół i zalać logi w momencie, gdy równolegle dzieje się coś cichszego: próba logowania na wykradzionych poświadczeniach, wynoszenie danych albo modyfikacja konfiguracji. Zespół patrzy wtedy na wykresy ruchu, a nie na alerty z systemów tożsamości.
Praktyczny wniosek dla procedury: w trakcie ataku wolumetrycznego nie wolno wyłączać ani ignorować monitoringu bezpieczeństwa, choćby generował szum. Odwrotnie: to moment na podniesioną czujność wobec logowań, zmian uprawnień i ruchu wychodzącego. Ciągły nadzór nad tymi sygnałami opisaliśmy szerzej przy usłudze SOC.
- Nikt nie potrafi podać progu, przy którym mitygacja się włącza.
- Ostatnia weryfikacja odporności nie odbyła się nigdy albo była przed ostatnią większą zmianą architektury.
- Rekordy DNS nie były przeglądane od czasu wdrożenia CDN.
- Procedura reagowania nie wskazuje osoby uprawnionej do decyzji poza godzinami pracy.
- Nikt nie sprawdził, czy zgłoszenie incydentu poważnego da się wykonać w 24 godziny, skoro kanał zgłoszeniowy działa na tej samej infrastrukturze co usługa.
Obowiązek zgłoszenia: 24 godziny, 72 godziny, miesiąc
Jeżeli jesteście podmiotem kluczowym albo ważnym, udana kampania DDoS nie kończy się na przywróceniu usługi. Znowelizowana ustawa o KSC nakłada trzy terminy liczone od wykrycia incydentu poważnego: wczesne ostrzeżenie do właściwego CSIRT sektorowego niezwłocznie, nie później niż w ciągu 24 godzin, pełne zgłoszenie w ciągu 72 godzin, a sprawozdanie końcowe nie później niż miesiąc od zgłoszenia.
Wszystkie te przekazy idą przez system teleinformatyczny wskazany w ustawie, a na wniosek CSIRT sektorowego dochodzi jeszcze sprawozdanie okresowe z obsługi incydentu. To, kto jest podmiotem kluczowym, a kto ważnym, rozłożyliśmy w tekście o krajowym systemie cyberbezpieczeństwa.
Z tego wynika rzecz, którą warto sprawdzić zawczasu: zegar rusza od wykrycia, nie od zakończenia ataku. Organizacja, która nie ma monitoringu dostępności z alertowaniem, dowiaduje się o incydencie od klientów i zaczyna liczyć te 24 godziny znacznie później, niż powinna.
Kluczowe wnioski
- 1DDoS był najczęstszym typem incydentu zgłaszanego w Unii, a administracja publiczna jest sektorem atakowanym najczęściej.
- 2Trzy warstwy ataku wymagają trzech różnych zabezpieczeń: ochrona przed jedną z nich nie chroni przed pozostałymi.
- 3Najgroźniejszy jest atak aplikacyjny: mieści się w niewielkim wolumenie i nie uruchamia progów opartych na paśmie.
- 4Posiadanie ochrony to nie to samo co odporność. Różnicę widać dopiero po kontrolowanej weryfikacji.
- 5Każda metoda mitygacji ma koszt uboczny dla własnych użytkowników: trzeba go poznać przed atakiem, nie w jego trakcie.
- 6Atak wolumetryczny bywa zasłoną: monitoring bezpieczeństwa musi w tym czasie działać intensywniej, nie słabiej.
- 7Dla podmiotów kluczowych i ważnych zegar 24 i 72 godzin rusza od wykrycia incydentu.
Najczęstsze pytania
Czy atak DDoS można całkowicie zablokować?
Nie da się zagwarantować, że żaden atak nie wpłynie na usługę. Da się natomiast doprowadzić do stanu, w którym atak wymaga nieproporcjonalnie dużych zasobów, a jego skutek ogranicza się do chwilowego spadku wydajności zamiast wielogodzinnej niedostępności. Celem obrony jest podniesienie kosztu ataku, nie jego wyeliminowanie.
Czy szerokie łącze wystarczy jako ochrona?
Chroni wyłącznie przed atakami wolumetrycznymi, czyli jednym z trzech rodzajów. Atak protokołowy wyczerpuje tablicę stanów na firewallu, a atak aplikacyjny wątki serwera. Obydwa zadziałają przy ruchu, który nie wysyci nawet ułamka pasma.
Jak sprawdzić odporność, nie przerywając pracy firmy?
Weryfikację prowadzi się w uzgodnionym oknie serwisowym, z rosnącym obciążeniem i twardym progiem przerwania, przy udziale osób, które mogą natychmiast zatrzymać ćwiczenie. Sensem nie jest wywrócenie usługi, tylko ustalenie, gdzie leży jej granica, i zatrzymanie się tuż przed nią.
Czy atak DDoS trzeba zgłosić?
Podmiot kluczowy i podmiot ważny zgłasza incydent poważny: wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, pełne zgłoszenie w ciągu 72 godzin, sprawozdanie końcowe w ciągu miesiąca od zgłoszenia. Ocena, czy dany incydent jest poważny, zależy od skali zakłócenia usługi, a nie od samego faktu wystąpienia ataku.
Co zrobić w pierwszych minutach ataku?
Potwierdzić, że to atak, a nie awaria własna. Uruchomić uzgodnioną wcześniej ścieżkę kontaktu z dostawcą mitygacji. Zachować logi ruchu, bo będą potrzebne do zgłoszenia. I podnieść czujność monitoringu bezpieczeństwa, ponieważ atak wolumetryczny bywa zasłoną dla równoległych działań w innym miejscu.
Podsumowanie
Ochrona przed DDoS rzadko zawodzi dlatego, że jej nie ma. Zawodzi dlatego, że została skonfigurowana pod infrastrukturę sprzed trzech lat, nikt nie sprawdził jej od tego czasu, a decyzja o jej aktywacji nie ma właściciela. Wszystkie trzy rzeczy da się ustalić w kontrolowanych warunkach i w wybranym przez siebie momencie albo poczekać, aż ustali je ktoś, kto wybierze moment za Was.
Odporność jest tym, co zostaje sprawdzone. Reszta jest deklaracją w umowie.
Źródła
- 1.ENISA Threat Landscape 2025ENISA · październik 2025 · dostęp 2026-08-16Analiza 4875 incydentów w okresie od 1 lipca 2024 do 30 czerwca 2025. DDoS był dominującym typem zdarzenia i odpowiadał za 77% zgłoszonych incydentów.
- 2.Public administration increasingly targeted by DDoS attacksENISA · 2025-11 · dostęp 2026-08-16Administracja publiczna najczęściej atakowanym sektorem w UE (38,5% zdarzeń), z przewagą ataków DDoS o niskim wpływie.
- 3.Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustawDziennik Ustaw 2026 poz. 252 · 2026-01-23 · dostęp 2026-08-16Terminy zgłoszeniowe odczytane z art. 11 ust. 1 pkt 4, 4a i 4c w brzmieniu nadanym nowelizacją, która weszła w życie 3 kwietnia 2026 r.
- 4.Krajobraz bezpieczeństwa polskiego internetu — raport roczny 2025CERT Polska / NASK · 2026 · dostęp 2026-08-16Kontekst krajowy: 260 783 unikalnych incydentów zarejestrowanych w 2025 roku, wzrost o 152% rok do roku.
Nie wiecie, przy jakim natężeniu ruchu Wasza ochrona się włącza?
Sprawdzamy to w kontrolowanych warunkach: mapujemy wystawione zasoby, ustalamy wydajność bazową i pokazujemy, który element pada pierwszy, a potem weryfikujemy poprawki.