Atak DDoS nie wymaga od napastnika żadnej finezji. Nie musi łamać haseł, znajdować dziury w kodzie ani podszywać się pod administratora. Wystarczy, że zaleje Twój serwer ruchem tak gęstym, że ten przestaje obsługiwać prawdziwych użytkowników. Efekt: strona pada, API milczy, a Ty tracisz pieniądze i zaufanie klientów. W tym poradniku pokażę Ci, jak zbudować obronę warstwa po warstwie — od jądra Linuksa, przez firewall, po usługi typu Cloudflare i AWS Shield — oraz co konkretnie wpisać w konfigurację, żeby przeżyć pierwsze uderzenie.
Czym jest atak DDoS i dlaczego pojedyncza zapora nie wystarczy
DDoS (Distributed Denial of Service) to atak, w którym ruch generuje nie jeden komputer, tylko tysiące — najczęściej zainfekowanych urządzeń tworzących botnet. To rozproszenie jest sednem problemu: nie zablokujesz jednego adresu IP i po sprawie, bo źródeł są dziesiątki tysięcy, rozsianych po całym świecie.
Żeby skutecznie się bronić, musisz wiedzieć, w którą warstwę celuje napastnik. Ataki dzielą się z grubsza na trzy rodzaje:
- Wolumetryczne (warstwa 3/4) — zalewają Twoje łącze samą ilością danych. Klasyka to UDP flood, ICMP flood oraz ataki ze wzmocnieniem (amplification) wykorzystujące źle skonfigurowane serwery DNS, NTP czy memcached. Skala? Największe zarejestrowane ataki przekraczają już kilka terabitów na sekundę — żadne pojedyncze łącze tego nie wytrzyma.
- Protokołowe (warstwa 4) — uderzają w słabości protokołów. Najpopularniejszy to SYN flood: napastnik wysyła lawinę pakietów
SYN, ale nigdy nie kończy handshake’u TCP, przez co zapełnia tablicę półotwartych połączeń serwera. - Aplikacyjne (warstwa 7) — najbardziej podstępne. Wysyłają pozornie legalne żądania HTTP (np. HTTP flood na
/szukaj?q=...albo na ciężki endpoint logowania). Ruch jest niewielki w bajtach, ale każde żądanie kosztuje serwer dużo CPU i zapytań do bazy. Trudno je odróżnić od prawdziwych użytkowników.
I tu klucz: nie istnieje jedno narzędzie, które zatrzyma wszystkie trzy. Firewall poradzi sobie z SYN flood, ale nie obroni Cię, gdy zapchane jest samo łącze do data center. Dlatego obrona przed DDoS to zawsze model warstwowy — od brzegu sieci po kod aplikacji.
Warstwa sieci: filtruj ruch zanim dotrze do aplikacji
Pierwsza linia obrony to firewall i jądro systemu. Na Linuksie zacznij od utwardzenia parametrów sieciowych w sysctl. Włączenie SYN cookies sprawia, że serwer nie rezerwuje zasobów dla półotwartych połączeń, dopóki klient nie odpowie:
net.ipv4.tcp_syncookies = 1— ochrona przed SYN floodnet.ipv4.tcp_max_syn_backlog = 4096— większa kolejka połączeńnet.ipv4.tcp_synack_retries = 2— szybsze porzucanie martwych połączeńnet.ipv4.icmp_echo_ignore_broadcast = 1— blokada ataków typu smurf
Następnie ogranicz tempo nowych połączeń na firewallu. Z nftables (następcą iptables) limit nowych połączeń TCP na porcie 80 ustawisz regułą typu tcp dport 80 ct state new limit rate 50/second. Z poziomu iptables ten sam efekt da moduł hashlimit, który liczy połączenia per adres IP, a nie globalnie.
Warto też ograniczyć liczbę jednoczesnych połączeń z jednego IP modułem connlimit — np. blokuj hosty, które otwierają więcej niż 20 równoległych sesji do Twojego serwera WWW. To prosty sposób, żeby pojedynczy bot nie zjadł całej puli workerów.
Pamiętaj jednak o twardym ograniczeniu: jeśli atak wolumetryczny wysyca Twoje łącze 1 Gbps, to żadna reguła na serwerze nie pomoże — pakiety zostają odrzucone już na routerze dostawcy. Filtrowanie na poziomie systemu chroni przed atakami mieszczącymi się w przepustowości łącza, nie większymi.
Usługi anty-DDoS i CDN: oddaj brudną robotę większym
Gdy atak przekracza możliwości Twojej infrastruktury, jedynym realnym rozwiązaniem jest przepuszczenie ruchu przez sieć kogoś, kto dysponuje pojemnością liczoną w terabitach. To rola usług anty-DDoS i sieci CDN.
Jak to działa: kierujesz domenę przez taką usługę (zwykle zmianą rekordów DNS), a cały ruch trafia najpierw do ich rozproszonej sieci. Dzięki routingowi Anycast ten sam adres IP ogłaszany jest z setek lokalizacji na świecie, więc atak rozkłada się na wiele punktów obecności (PoP) zamiast skupiać na jednym serwerze. Złośliwy ruch jest filtrowany w tych węzłach, a do Ciebie dociera tylko czysty.
Najczęściej spotykane rozwiązania:
- Cloudflare — w darmowym planie oferuje nielimitowaną ochronę przed DDoS na warstwach 3, 4 i 7 (bez limitu wolumenu), co czyni go najpopularniejszym wyborem na start. To, co jest płatne, to konfigurowalny WAF z regułami niestandardowymi i zarządzanymi zestawami reguł — sama mitygacja DDoS L7 działa już na darmowym planie.
- AWS Shield — Standard działa automatycznie i bezpłatnie dla zasobów w AWS; Shield Advanced (płatny, w okolicach kilku tysięcy dolarów miesięcznie) daje dedykowany zespół reagowania i gwarancje finansowe.
- Akamai i Imperva — rozwiązania klasy enterprise, drogie, ale potężne.
- OVH i wielu innych dostawców serwerów oferuje ochronę anty-DDoS wliczoną w cenę hostingu — sprawdź, co już masz, zanim za coś zapłacisz.
Najczęstszy błąd: wpinasz domenę w Cloudflare, ale prawdziwy adres IP serwera wcześniej wyciekł (np. ze starych rekordów DNS, nagłówków maili albo certyfikatu). Wtedy atakujący uderza bezpośrednio w serwer, omijając całą ochronę. Po skonfigurowaniu CDN zablokuj na firewallu cały ruch poza zakresami IP swojego dostawcy ochrony — tylko wtedy origin jest naprawdę schowany.
Load balancing i redundancja: nie miej jednego punktu awarii
Pojedynczy serwer to pojedynczy cel. Rozłożenie ruchu na kilka maszyn za pomocą load balancera nie tylko zwiększa wydajność na co dzień, ale też podnosi próg, przy którym atak Cię położy.
Najpopularniejsze narzędzia to HAProxy i NGINX jako reverse proxy, a w chmurze gotowe usługi typu AWS Elastic Load Balancing czy Google Cloud Load Balancing. Load balancer może też pełnić rolę punktu, w którym terminujesz TLS i nakładasz limity, zanim ruch dotrze do aplikacji.
Jeśli budujesz coś poważniejszego, rozważ:
- Architekturę wieloregionową — serwery w różnych data center i lokalizacjach geograficznych, żeby atak na jeden region nie zabił całej usługi.
- Redundancję łączy (multi-ISP) — więcej niż jeden dostawca internetu, najlepiej z BGP, by w razie ataku przekierować ruch.
- Autoskalowanie — w chmurze możesz automatycznie dorzucać instancje przy nagłym wzroście ruchu. To kupuje czas, ale uważaj: przy ataku L7 autoskalowanie potrafi wygenerować rachunek wyższy niż straty z samego downtime’u. Ustaw limit górny.
Warstwa aplikacji: WAF, rate limiting i cache
Ataki warstwy 7 przechodzą przez firewall jak nóż przez masło, bo to z pozoru normalne żądania HTTP. Tu obrona przenosi się bliżej Twojego kodu.
Web Application Firewall (WAF)
WAF analizuje żądania HTTP i blokuje te, które pasują do wzorców ataków. Na własnym serwerze najpopularniejszy jest ModSecurity z zestawem reguł OWASP Core Rule Set, działający jako moduł NGINX lub Apache. WAF chroni przy okazji przed SQL injection i XSS, więc to inwestycja, która zwraca się na kilku frontach.
Rate limiting na serwerze WWW
Ogranicz liczbę żądań z jednego adresu IP bezpośrednio w serwerze WWW. W NGINX robisz to dyrektywą limit_req_zone i limit_req — np. pozwól na 10 żądań na sekundę z jednego IP, z niewielkim buforem (burst) na naturalne skoki. W Apache podobny efekt dają moduły mod_qos i mod_reqtimeout (ten drugi odcina powolne ataki typu Slowloris, które utrzymują połączenia otwarte minimalnym strumieniem danych).
CAPTCHA i caching
Gdy detekcja wykryje podejrzany ruch, dorzuć wyzwanie typu CAPTCHA na wrażliwych endpointach (logowanie, rejestracja, wyszukiwarka). Sprawdzą się Cloudflare Turnstile, hCaptcha czy reCAPTCHA — boty zwykle ich nie przejdą.
Niedoceniana broń to cache. Im więcej żądań obsłużysz ze statycznej pamięci podręcznej (CDN, Varnish, Redis, Memcached) zamiast generować odpowiedź od zera, tym mniej obciążasz bazę danych i tym wyższy atak L7 wytrzymasz. Każde żądanie, które nie trafi do PHP czy bazy, to żądanie, którym nie musisz się martwić.
Monitorowanie i detekcja: zauważ atak, zanim zauważą go klienci
Nie obronisz się przed czymś, czego nie widzisz. Atak DDoS najlepiej wykryć w pierwszych minutach — wtedy masz czas zareagować, zanim usługa padnie.
Co monitorować i czym:
- Ruch sieciowy i obciążenie —
Zabbix,Prometheus+Grafana,Netdata. Ustaw alerty na nietypowe skoki liczby połączeń, ruchu na interfejsie i zużycia CPU. - Logi i wzorce żądań —
ELK Stack(Elasticsearch, Logstash, Kibana) alboGraylogdo analizy, skąd i jakie żądania napływają. - Systemy wykrywania włamań (IDS/IPS) —
SuricataiSnortrozpoznają znane wzorce ataków na poziomie pakietów. - Automatyczne blokowanie —
Fail2banczyta logi i banuje IP, które przekraczają zdefiniowane progi (np. dziesiątki błędów 404 albo prób logowania w minutę).
Kluczowa rzecz, którą ludzie pomijają: poznaj swoją linię bazową. Jeśli nie wiesz, ile żądań na sekundę generuje normalny ruch w Twojej usłudze, nie odróżnisz ataku od udanej kampanii marketingowej. Zbierz metryki z kilku tygodni zanim coś się stanie.
Plan reakcji na atak: co robić, gdy już się dzieje
W trakcie ataku nie ma czasu na improwizację. Przygotuj plan reakcji na incydent wcześniej i miej go pod ręką. Powinien zawierać:
- Identyfikację — potwierdź, że to atak, a nie awaria czy nagły ruch. Sprawdź typ: wolumetryczny czy aplikacyjny? Po porcie i wzorcu żądań poznasz, w co celuje.
- Eskalację — kontakt do dostawcy hostingu i usługi anty-DDoS. Miej numery i dane do logowania zapisane offline, nie tylko na serwerze, który właśnie pada.
- Mitygację — włącz tryb „pod atakiem” w Cloudflare, zaostrz reguły rate limitingu, w ostateczności zastosuj blackholing (null routing) na atakowany adres IP. To ostatnie zatrzymuje atak kosztem chwilowego odcięcia usługi — bywa mniejszym złem niż przeciążenie całej sieci.
- Komunikację — poinformuj zespół i klientów (strona statusu, media społecznościowe). Cisza w trakcie awarii szkodzi bardziej niż sama awaria.
- Analizę po fakcie — gdy opadnie kurz, przejrzyj logi, wyciągnij wnioski i zaktualizuj zabezpieczenia. Atakujący często wracają.
I rzecz oczywista, a często pomijana: przetestuj ten plan. Symulacja kontrolowanego ataku (np. narzędziami do testów obciążeniowych na środowisku testowym, nigdy na produkcji bez zgody dostawcy) pokaże, czy Twoje progi i alerty faktycznie działają.
Najczęstsze błędy w ochronie przed DDoS
- Ujawniony adres IP origin mimo wpięcia w CDN — najpopularniejsza dziura, omawiana wyżej.
- Zbyt agresywny rate limiting — blokujesz prawdziwych użytkowników razem z botami. Testuj progi na realnym ruchu.
- Brak monitoringu — dowiadujesz się o ataku od wkurzonego klienta zamiast z alertu.
- Poleganie na jednej warstwie — sam firewall albo sam Cloudflare to za mało. Buduj obronę w głąb.
- Brak planu i kontaktów — w trakcie ataku szukasz numeru do supportu zamiast działać.
FAQ — najczęstsze pytania o ochronę przed DDoS
Czym różni się atak DoS od DDoS?
DoS pochodzi z jednego źródła, więc wystarczy zablokować jeden adres IP. DDoS jest rozproszony na tysiące maszyn (botnet), przez co prosta blokada IP nie działa i potrzebujesz obrony warstwowej oraz filtrowania ruchu na poziomie sieci.
Czy darmowa ochrona Cloudflare wystarczy?
Dla małych i średnich stron darmowy plan Cloudflare zatrzyma większość ataków — automatyczna ochrona przed DDoS na warstwach 3, 4 i 7 jest nielimitowana i działa na wszystkich planach, łącznie z darmowym. Po plany płatne warto sięgnąć wtedy, gdy potrzebujesz pełnego WAF z regułami niestandardowymi i zarządzanymi zestawami (np. OWASP), by precyzyjniej filtrować złożone ataki warstwy 7.
Jak sprawdzić, czy serwer jest właśnie atakowany?
Obserwuj nagły, nieuzasadniony skok liczby połączeń, ruchu na interfejsie sieciowym i zużycia CPU. Komendy takie jak netstat -an | grep SYN_RECV | wc -l pokażą liczbę półotwartych połączeń (wysoka wartość sugeruje SYN flood), a analiza logów serwera WWW ujawni, czy żądania walą w jeden endpoint z wielu IP.
Czy małej firmie też grozi DDoS?
Tak. Ataki bywają wymierzone w konkretne małe biznesy (np. przez konkurencję lub szantaż), a sklep internetowy traci pieniądze za każdą minutę niedostępności. Dodatkowo małe serwery padają przy znacznie niższym wolumenie niż infrastruktura korporacji, więc próg „opłacalności” ataku jest niski.
Ile kosztuje ochrona przed DDoS?
Rozpiętość jest ogromna. Podstawowa ochrona Cloudflare i AWS Shield Standard są darmowe. Plany pośrednie to kilkadziesiąt do kilkuset złotych miesięcznie. Rozwiązania enterprise (Akamai, Imperva, AWS Shield Advanced) kosztują od kilku tysięcy złotych w górę. Ceny szybko się zmieniają — zawsze sprawdź aktualny cennik u dostawcy, bo te liczby to jedynie orientacyjne widełki.
