Krótkie spis treści:
— DDoS bez mitów
— Nasza ochrona “z pudełka” na poziomie sieci
— L7: dlaczego wygląda jak zwykły ruch, a kładzie stronę
— Cloudflare: ustawienia, które robią różnicę
— Nginx i aplikacja: odporność i cache
— Spokojny plan działania w trakcie ataku
Wiele osób myśli o DDoS jak o jednym scenariuszu: „ktoś wysłał dużo danych i strona padła”. Czasem tak jest, ale coraz częściej atak nie musi być wielki wolumenowo — wystarczy, że jest sprytny. Wtedy napastnik nie zalewa łącza, tylko uderza w miejsca najdroższe dla Twojej aplikacji: logowanie, wyszukiwarkę, filtry, API, generowanie stron z ciężkimi zapytaniami do bazy. Efekt bywa podobny: realni użytkownicy widzą time-outy, a monitoring sieci nie zawsze pokazuje katastrofę.
Dlatego skuteczna ochrona jest warstwowa. Najpierw odcinasz „brud” sieciowy zanim dotrze do serwera. Potem stawiasz perymetr, który rozumie HTTP i potrafi reagować na zachowanie (Cloudflare). Na koniec wzmacniasz Nginx i samą aplikację, aby nie dało się „zjeść” wszystkich połączeń i workerów.
Co zapewniamy klientom domyślnie: ochrona sieciowa
W naszej usłudze bazowa ochrona Anti-DDoS działa na poziomie infrastruktury sieciowej centrum danych. Najważniejsze jest to, że dzieje się to „przed” Twoim serwerem — i właśnie dlatego działa na klasyczne, głośne ataki L3/L4. Jeśli atak jest wolumenowy, walka na serwerze bywa spóźniona: łącze może być zapchane zanim Nginx zobaczy prawdziwe żądania HTTP.
W praktyce system wykrywa anomalie (nagłe skoki PPS, nietypowe wzorce handshake, amplification) i uruchamia filtrowanie/czyszczenie ruchu. To zwykle bardzo dobrze radzi sobie z UDP flood, amplification, SYN storm i innymi transportowymi wektorami.
Jednak gdy napastnik wysyła poprawne żądania HTTPS, sytuacja się komplikuje — bo na poziomie sieci to nadal „normalny” ruch. I wtedy wchodzi L7.
L7: dlaczego to boli najbardziej
Ataki L7 potrafią wyglądać jak zwykli użytkownicy. Tylko że takich „użytkowników” jest nagle dziesiątki tysięcy i wszyscy klikają w najbardziej kosztowne funkcje. Każde żądanie to praca CPU, bazy danych, cache i czasem usług zewnętrznych. W efekcie strona zwalnia albo staje, mimo że nie widać gigantycznego wolumenu danych.
Rozwiązanie to połączenie Cloudflare (WAF, reguły, challenge), limitów w Nginx oraz praktycznych optymalizacji w aplikacji.
Cloudflare: jak zrobić to poprawnie
Największy błąd: mieć Cloudflare, ale zostawić origin dostępny po IP. Wtedy atakujący omija Cloudflare. Dlatego:
-
proxy w DNS (żeby nie świecić IP origin),
-
firewall na origin: 80/443 tylko z sieci Cloudflare,
-
dostęp administracyjny ograniczony do zaufanych IP/VPN.
Następnie: WAF i rate limiting, ale z głową. Najlepiej zabezpieczać punkty ryzyka: logowanie, API, wyszukiwarkę, formularze. Rate limiting działa dobrze, bo człowiek nie zachowuje się jak bot — i tę różnicę zamieniasz w regułę.
W incydencie przydaje się też mocniejszy challenge jako „hamulec awaryjny”, żeby zyskać czas na dopracowanie reguł.
Nginx i aplikacja: odporność i cache
Po stronie serwera chcesz przede wszystkim zapobiec sytuacji, gdzie jeden klient zajmuje wszystkie połączenia. Dlatego limity połączeń i limity żądań ustawiaj na drogich ścieżkach, a nie na całej stronie.
Timeouty i limity rozmiaru też robią różnicę — pomagają unikać trzymania zasobów przez wolne lub podejrzane połączenia. A cache jest często „game changerem”: nawet krótkie cache’owanie potrafi dramatycznie zmniejszyć obciążenie backendu podczas floodu.
W aplikacji warto mieć plan B: tryb uproszczony, ograniczenie najcięższych funkcji, kolejki dla kosztownych operacji i dodatkowe zabezpieczenia logowania.
Co robić, gdy atak już trwa
Najpierw wzmacniasz Cloudflare na konkretnych endpointach i upewniasz się, że origin jest zamknięty. Potem dokładasz limity w Nginx tam, gdzie idzie ruch, włączasz cache, a na końcu doprecyzowujesz reguły na podstawie logów (URI, źródła, powtarzalne wzorce).
Jak w praktyce wygląda atak: po czym poznać różne typy
Warto rozróżniać symptomy, bo „strona nie działa” może oznaczać zupełnie inne wąskie gardło.
SYN flood często objawia się niestabilnością: raz działa, raz time-out. CPU nie zawsze musi być w 100%, ale brakuje „miejsca” na poprawne zestawienie połączeń. Użytkownicy widzą problemy już na etapie łączenia się.
UDP flood / amplification zwykle widać na wykresach sieci: rośnie inbound, potrafi zwolnić wszystko, czasem nawet SSH. Jeśli czyszczenie ruchu działa dobrze, spadek bywa krótszy — to właśnie rola warstwy sieciowej.
L7 HTTP flood jest najbardziej podstępny: wolumen nie musi być ogromny, ale aplikacja się dusi. Workery są zajęte, baza dostaje lawinę podobnych zapytań, cache nie nadąża. Prawie zawsze są cele: logowanie, wyszukiwarka, filtry, API, checkout. Jeśli logi pokazują dominację jednego–dwóch URI, to typowy L7.
Cloudflare: trzy scenariusze konfiguracji
WordPress.
Najczęściej atakowane są wp-login.php i xmlrpc.php. Najlepsza praktyka to nie męczyć wszystkich użytkowników, tylko zabezpieczyć “drzwi”. Jeśli XML-RPC nie jest potrzebny — zablokować. Logowanie ograniczyć częstotliwościowo, a ostrzejsze challenge włączać w incydencie.
Warto też zwrócić uwagę na ciężkie endpointy AJAX z pluginów — pod atakiem to one potrafią wyłożyć serwer.
Laravel / aplikacje sesyjne.
Cele to logowanie, rejestracja, reset hasła, drogie strony konta i API. Cloudflare ma odciąć nadużycia przed aplikacją: limity na auth, osobne reguły na API, a origin zamknięty (żeby nie było obejścia po IP). W aplikacji: ochrona progresywna, cache i niewykonywanie ciężkiej logiki zanim żądanie przejdzie podstawowe filtry.
Czyste API.
API pada, gdy jeden klient może „wystrzelać” zasoby bez limitu. Edge jako bramka jest bardzo pomocny, ale wymagane są też limity wewnętrzne: per token, rozmiar payload, walidacja, ochrona przed powtórzeniami i osobne limity dla drogich endpointów.
Nginx i L7 bez zepsucia UX
Najlepiej działa podejście precyzyjne: limity na logowanie, API, wyszukiwarkę i filtry, a treści cache’ować i oddawać szybko. Dodatkowo warto pilnować timeoutów i keepalive, bo “wolne” połączenia potrafią zająć zasoby i zablokować realnych użytkowników.