Ochrona przed DDoS: dziewięć warstw obrony

Atak DDoS nie próbuje przejąć konta ani wykraść bazy klientów. Jego celem jest niedostępność usługi — i osiąga ją przez wyczerpanie tego zasobu, który skończy się pierwszy: łącza, tablicy połączeń, procesora albo puli połączeń do bazy danych.

Dlatego uczciwa odpowiedź na pytanie, jak chronić firmę przed atakiem DDoS, nie brzmi „kup jedno narzędzie”. Różne ataki wyczerpują różne zasoby, a każda warstwa obrony domyka inny scenariusz awarii. Poniżej opisujemy te warstwy w kolejności, w jakiej naprawdę zatrzymują ruch, oraz plan działania na moment, w którym atak już trwa.

Co atak DDoS naprawdę wyczerpuje

Rodzina ataków	Przykłady	Co się kończy	Gdzie trzeba go zatrzymać
Wolumetryczne	zalew UDP, wzmacnianie DNS i NTP, carpet bombing	Przepustowość łącza	U dostawcy lub w sieci scrubbingowej
Protokolarne	zalew SYN i ACK, zalew połączeń	Tablice połączeń serwerów i zapór	Limity na brzegu, SYN cookies, dostrojenie jądra
Aplikacyjne (L7)	zalew HTTP, cache busting, slowloris, nadużycia API	Procesor, wątki robocze, połączenia do bazy	CDN i WAF, cache, limity w aplikacji

Wniosek bywa niewygodny: jeśli atak jest większy niż Twoje łącze, żadne ustawienie na serwerze nie ma znaczenia. Pakiety wygrywają, zanim lokalna reguła zapory w ogóle je zobaczy. Ochrona wolumetryczna musi więc działać wyżej, po stronie operatora. Pozostałe warstwy można utwardzić samodzielnie i to one decydują, czy strona wstanie po pierwszej fali.

Warstwa pierwsza: scrubbing i sieć anycast

Każda poważna obrona zaczyna się od pojemności, której firma nie posiada. Sieci scrubbingowe i anycast rozkładają ruch na dziesiątki lokalizacji, odfiltrowują go i przekazują do serwera tylko czyste żądania.

W praktyce ruch publiczny powinien przechodzić przez CDN lub odwrotne proxy z wbudowaną mitygacją: Cloudflare, CloudFront z Shield, Azure Front Door, Gcore, Bunny czy Fastly. Warto zapytać dostawcę, jaka pojemność mitygacyjna stoi przed adresem IP i czy działa stale, czy dopiero po wykryciu anomalii. Ochrona uruchamiana na żądanie zostawia lukę dokładnie w pierwszych minutach ataku, kiedy liczy się każda sekunda.

Ukrycie adresu IP serwera origin

To krok, który zespoły najczęściej pomijają, a który po cichu unieważnia warstwę pierwszą. Jeśli atakujący pozna prawdziwy adres serwera, ominie CDN i uderzy bezpośrednio w origin — technika znana jako direct-to-origin.

Gdzie wycieka adres origin

archiwa historii DNS ze starymi rekordami A sprzed wdrożenia proxy;
logi przejrzystości certyfikatów, ujawniające certyfikaty wystawione dla nazwy origin;
subdomeny typu mail, vpn, ftp czy dev, które często wskazują na tę samą maszynę;
nagłówki wiadomości wychodzących, gdzie adres potrafi pojawić się w polu Received;
stare rekordy MX, SPF i TXT wskazujące na infrastrukturę poza CDN.

Co zrobić po wdrożeniu CDN

Po pierwsze zmienić adres IP origin, bo stary jest już publicznie znany. Po drugie ograniczyć zaporę tak, aby porty 80 i 443 przyjmowały ruch wyłącznie z opublikowanych zakresów dostawcy CDN. Po trzecie sprawdzać własną ekspozycję raz na kwartał, najlepiej tą samą metodą, jaką zastosowałby atakujący: przeglądem archiwów, subdomen i logów certyfikatów.

WAF, czyli kontrola warstwy aplikacji

Zapora sieciowa widzi poprawne połączenie TCP i przepuszcza je dalej. WAF czyta samo żądanie HTTP i tam znajduje to, co interesuje atakujących: zniekształcone parametry, próby wykorzystania podatności, boty dobijające się do logowania i wyszukiwarki.

Kolejność wdrożenia jest prosta. Najpierw zestawy reguł zarządzanych przez dostawcę, w tym reguły rdzenia OWASP. Potem reguły własne, dopasowane do aplikacji: limit rozmiaru ciała żądania na endpointach przyjmujących pliki, wyzwanie dla ruchu wchodzącego na ścieżki administracyjne oraz limity liczone osobno dla każdej trasy.

Limity zapytań na dwóch poziomach

Limitowanie żądań jest najtańszą kontrolą, jaką dysponuje firma, i jednocześnie najczęściej skonfigurowaną połowicznie. Reguła ustawiona tylko na serwerze webowym nic nie da, jeśli najpierw zapełni się łącze, a reguła liczona wyłącznie po adresie IP jest bezradna wobec botnetu z tysiącami adresów źródłowych.

Brzeg sieci

Liczba żądań na adres IP, na sieć autonomiczną i — tam, gdzie ma to sens — na kraj. Limity muszą być dość luźne, by nie odcinać sieci komórkowych, i dość ciasne, by zatrzymać proste zalewy.

Aplikacja

Limity na sesję, na klucz API i na zalogowanego użytkownika. Dobrze działają algorytmy token bucket lub okna przesuwnego, bo dopuszczają krótkie skoki ruchu, a jednocześnie karzą stałe nadużycie. Odpowiedź powinna zawierać kod 429 i nagłówek Retry-After, żeby uczciwy klient zwolnił, a nie dobijał się w pętli.

Utwardzenie stosu TCP

Zalew SYN zapełnia tablicę połączeń, zanim dotrze choć jedno żądanie HTTP, dlatego w logach aplikacji często nie ma po nim śladu. Rozwiązania są stare, nudne i skuteczne: włączone SYN cookies, podniesiony backlog nasłuchu, parametry somaxconn i tcp_max_syn_backlog dopasowane do realnej współbieżności, skrócony czas tcp_fin_timeout oraz limit równoczesnych połączeń z jednego źródła ustawiony na brzegu.

Każdą zmianę potwierdź pomiarem pod obciążeniem; ustawienia skopiowane z sieci częściej szkodzą, niż pomagają.

Cache przejmuje ruch

Żądanie obsłużone z cache nigdy nie trafia do origin, więc nie zużywa wątku roboczego ani połączenia z bazą. Wszystko, co może być statyczne, powinno być statyczne: obrazy, style, skrypty oraz HTML dla odwiedzających anonimowych.

Dwa szczegóły nabierają znaczenia w trakcie ataku. Pierwszy to cache busting, czyli celowe doklejanie losowych parametrów do adresów, aby wymusić przejście żądania do origin — CDN powinien ignorować nieistotne parametry na trasach objętych cache'owaniem. Drugi to współczynnik trafień w cache, który jest miarą bezpieczeństwa: spadek z 85 do 20 procent w trakcie incydentu oznacza, że firma płaci za ruch atakującego.

Baseline i alerty na odchylenia

Nie da się obronić przed czymś, czego nie widać. Przed atakiem warto zapisać, jak wygląda normalność: liczba żądań na sekundę, bajty w obie strony, odsetek błędów 4xx i 5xx, opóźnienie p95, liczba połączeń oraz najczęściej odpytywane adresy.

Alerty powinny reagować na odchylenie, nie na wartość absolutną. Pięciokrotny wzrost ruchu przy stabilnym odsetku błędów to często skuteczna kampania marketingowa, a płaski ruch z rosnącym opóźnieniem i liczbą połączeń to klasyczny atak na wyczerpanie stanu. Dane NetFlow lub IPFIX razem z logami aplikacji dają oba obrazy, czego sama konsola CDN nie pokaże.

Plan reagowania napisany zawczasu

W trakcie ataku najgorszy moment na ustalanie, kto dzwoni do dostawcy i kto ma prawo włączyć tryb podwyższonej ochrony. Plan na jednej stronie wystarczy, jeśli zawiera konkrety:

Kto ogłasza incydent i gdzie informuje o tym zespół.
Kto kontaktuje się z dostawcą hostingu lub CDN, wraz z numerami umowy.
Jakie kontrole włącza się w jakiej kolejności i kto ma do nich uprawnienia.
Kto komunikuje się z klientami i jaki jest tekst pierwszego komunikatu.
Kiedy uruchamia się ścieżkę prawną, zwłaszcza przy próbie wymuszenia.

Plan warto przećwiczyć raz na kwartał w formie ćwiczenia na sucho.

Gdy atak już trwa

Kolejność działań ma znaczenie, bo prowadzi od ruchów najmniej inwazyjnych do najbardziej:

Potwierdź, że to atak — sprawdź źródła ruchu, wzorce żądań, najczęściej odpytywane adresy i geografię, zanim cokolwiek zablokujesz.
Ustal warstwę — zapełnione łącze wskazuje na wolumen, wyczerpane tablice połączeń na warstwę trzecią i czwartą, a wysoki procesor na jednym endpoincie na warstwę siódmą.
Otwórz zgłoszenie u dostawcy natychmiast — mitygacja u operatora uruchamia się z opóźnieniem, więc zamów ją, zanim skończysz diagnozę.
Włącz kontrole na brzegu: tryb podwyższonej ochrony, reguły zarządzane WAF, ciaśniejsze limity i wyzwanie skryptowe na najbardziej obciążonych trasach.
Sprawdź origin — czy przyjmuje ruch wyłącznie z CDN i czy żądania kierowane prosto na adres IP są odrzucane.
Komunikuj — najpierw strona statusu, potem kanały wsparcia. Cisza szkodzi bardziej niż sam atak.
Zabezpiecz dowody — logi, zrzuty pakietów i znaczniki czasu przydają się dostawcy, ubezpieczycielowi i w ewentualnym postępowaniu.

Jeśli atak łączy się z żądaniem okupu, nie należy negocjować na warunkach napastnika — taką decyzję trzeba przygotować wcześniej, z prawnikiem i ubezpieczycielem. Porozmawiaj z zespołem, jeśli potrzebujesz wsparcia w trakcie aktywnego ataku.

Ile to naprawdę kosztuje

Wariant	Typowy koszt	Dla kogo
Tani plan CDN	od zera do około stu złotych miesięcznie	Blogi, małe strony firmowe, usługi o niskim ryzyku
Ochrona w chmurze dostawcy infrastruktury	wliczona w rachunek	Projekty już działające w tej chmurze
Zarządzany WAF i DDoS	od kilkuset do kilku tysięcy złotych miesięcznie	Aplikacje krytyczne dla przychodu
Dedykowany scrubbing	umowy enterprise	Cele wysokiej wartości, finanse, gaming

Liczba, która naprawdę się liczy, to koszt godziny przestoju pomnożony przez prawdopodobieństwo ataku. Dla większości małych firm tani, dobrze skonfigurowany plan i przećwiczone procedury biją drogie urządzenie, którego nikt nie umie obsłużyć.

Błędy, które przedłużają awarię

blokowanie zakresów adresów samego CDN, co wyłącza stronę całkowicie;
limity liczone wyłącznie po adresie IP, podczas gdy botnet rotuje źródła;
ochrona strony głównej przy całkowicie otwartym API;
pomijanie warstwy trzeciej i czwartej, której nie widać w logach HTTP;
brak ochrony origin, gdy CDN absorbuje atak, a napastnik dobija się do prawdziwego adresu;
plan reagowania, którego nikt nie ćwiczył.

Najczęściej zadawane pytania

Czy da się całkowicie zapobiec atakowi DDoS?

Nie. Ruch w stronę usługi publicznej może wysłać każdy; realistyczny cel to wchłonięcie go i odfiltrowanie bez utraty dostępności dla uczciwych użytkowników.

Czy sam CDN wystarczy, żeby zatrzymać atak?

CDN radzi sobie z zalewem wolumetrycznym i dużą częścią nadużyć w warstwie aplikacji, ale nie naprawia ekspozycji origin ani wyczerpania stanu. To jedna z dziewięciu warstw.

Jak odróżnić atak od zwykłego skoku ruchu?

Patrz na skład, nie na wolumen. Skok z jednego kraju lub na jeden adres, z nietypowymi identyfikatorami klienta, rosnącym opóźnieniem i płaskim odsetkiem konwersji to atak. Ruch rozłożony na zwykłe źródła zwykle oznacza, że kampania działa.

Co powinna zrobić mała firma w pierwszej kolejności?

Wprowadzić ruch pod CDN z mitygacją, ukryć adres origin, włączyć reguły zarządzane WAF i napisać plan reagowania na jednej stronie — ta kolejność pokrywa najczęstsze scenariusze najmniejszym kosztem.

Czy potrzebny jest dedykowany dostawca ochrony anty-DDoS?

Tylko wtedy, gdy koszt przestoju przewyższa wartość umowy. Zacznij od planu CDN, zmierz realną ekspozycję i wracaj do tematu, gdy rachunek zacznie się uzasadniać.

Chcesz sprawdzić, które z tych warstw działają w Twojej infrastrukturze, a które istnieją tylko na papierze? Porozmawiaj z zespołem.

Jak chronić firmę przed atakami DDoS