DDoS atak ochrona – jak realnie zabezpieczyć serwer i stronę

DDoS atak ochrona to zestaw mechanizmów, które utrzymują dostępność serwisu w momencie, gdy do infrastruktury trafia ruch wielokrotnie przekraczający normalne obciążenie. Skuteczna DDoS atak ochrona nigdy nie sprowadza się do jednego produktu – składa się z warstwy sieciowej, transportowej i aplikacyjnej, a każda z nich wymaga innych narzędzi. Rozproszony atak odmowy usługi polega na tym, że tysiące zainfekowanych urządzeń – kamer IP, routerów, konsol, a nawet drukarek – jednocześnie wysyłają żądania do jednego celu. Wolumen liczony w gigabitach na sekundę wysyca łącze, wyczerpuje tablicę połączeń firewalla albo zajmuje wszystkie procesy PHP. Efekt dla użytkownika jest zawsze ten sam: strona nie odpowiada, koszyk nie działa, formularz kontaktowy zwraca błąd 503. Dla firmy oznacza to utracone przychody, spalony budżet reklamowy i spadek zaufania, który odbudowuje się miesiącami. Dlatego planowanie zabezpieczeń zaczyna się na długo przed pierwszym incydentem, a nie w jego trakcie.

Anatomia ataku: co dokładnie dzieje się z serwerem

Typowy incydent zaczyna się niepozornie: liczba połączeń rośnie o kilkaset procent w dwie minuty. Na biurku administratora drugi monitor do komputera pokazuje wykresy Grafany, na których load average skacze z 0,4 do 60. Serwer wciąż odpowiada, ale kolejka żądań rośnie szybciej, niż aplikacja zdąży ją obsłużyć.

Ataki wolumetryczne wykorzystują amplifikację. Zapytanie DNS o rozmiarze 60 bajtów potrafi zwrócić odpowiedź 3000-bajtową, co daje mnożnik około 50. Źle skonfigurowany memcached wystawiony na port 11211 zwiększa ruch nawet dziesiątki tysięcy razy. Napastnik podszywa się pod adres IP ofiary i kieruje na nią całą lawinę odpowiedzi.

Zupełnie inaczej wygląda atak warstwy siódmej. Zamiast wysycać pasmo, generuje kilkaset żądań na sekundę do najdroższych obliczeniowo adresów: wyszukiwarki sklepu, filtrów kategorii, koszyka albo panelu logowania. Łącze 1 Gb/s pozostaje wolne w 95 procentach, a mimo to strona przestaje się otwierać, bo baza danych nie nadąża z zapytaniami.

Ruch wolumetryczny kontra ataki warstwy aplikacji

Rozróżnienie tych dwóch scenariuszy decyduje o doborze narzędzi. Przed zalewem pakietów UDP obroni wyłącznie filtrowanie po stronie operatora, bo lokalny firewall padnie razem z łączem. Z kolei atak HTTP na endpoint wyszukiwania zatrzymuje się dopiero na regułach WAF, limitach zapytań i cache’owaniu odpowiedzi po stronie serwera proxy.

Warstwy obrony: od brzegu sieci po reguły aplikacyjne

Pierwsza warstwa działa poza twoją maszyną. Operator przekierowuje ruch do centrum czyszczącego, gdzie sprzęt analizuje pakiety i odrzuca te ze sfałszowanym źródłem. Dopiero oczyszczony strumień wraca na serwer. Ten mechanizm uruchamia się automatycznie po przekroczeniu progu, zwykle liczonego w setkach megabitów na sekundę lub tysiącach pakietów.

Druga warstwa to konfiguracja systemu operacyjnego. Włączone SYN cookies, rozsądne limity w conntrack, ograniczenie liczby jednoczesnych połączeń z jednego adresu IP i wyłączenie nieużywanych usług UDP kosztują wyłącznie czas administratora. Ta pozornie nudna higiena zatrzymuje znaczącą część automatycznych, masowych prób przeciążenia infrastruktury.

Trzecia warstwa mieszka w aplikacji i przed serwerem WWW. Cache pełnych stron w Varnish lub Nginx, rate limiting na poziomie lokalizacji, captcha na formularzach oraz reguły blokujące podejrzane nagłówki potrafią obniżyć zużycie procesora o 80–90 procent. Poniższe zestawienie porządkuje typowe scenariusze i realne koszty.

Ile kosztuje ochrona i jaką infrastrukturę wybrać

Na hostingu współdzielonym nie masz wpływu na filtrowanie, a przy większym ataku dostawca po prostu wyłączy twoje konto, żeby ratować pozostałych klientów. To wystarczające rozwiązanie dla wizytówki, ale nie dla sklepu obsługującego kilkaset zamówień dziennie. Granicą opłacalności jest zwykle poziom kilkudziesięciu tysięcy złotych obrotu miesięcznie.

Serwer wirtualny z wbudowaną mitygacją zmienia układ sił. Usługi klasy ovh vps startują od kilkudziesięciu złotych miesięcznie i obejmują automatyczne filtrowanie ruchu wolumetrycznego bez dopłat, co przy własnym sprzęcie kosztowałoby wielokrotnie więcej. Dostajesz też pełny dostęp do systemu, więc możesz samodzielnie dostroić limity jądra i reguły firewalla.

Serwer dedykowany lub klaster ma sens powyżej kilkuset tysięcy odsłon miesięcznie. Koszt rzędu 400–1200 zł miesięcznie kupuje przewidywalną wydajność, ale nie zwalnia z konfiguracji. Agencja zajmująca się projektowaniem stron internetowych powinna wliczać czas na wdrożenie zabezpieczeń w wycenę projektu, a nie traktować go jako opcję dodatkową.

Kiedy przenieść ruch przez CDN

Sieć CDN ukrywa prawdziwy adres serwera i przejmuje ruch statyczny: obrazy, arkusze stylów, skrypty. Sklep z peryferiami, w którym karta produktu zawiera dziesięć zdjęć takich jak klawiatura mechaniczna czy monitor do komputera, potrafi w ten sposób odciążyć origin o ponad 70 procent transferu, co bezpośrednio zwiększa odporność na przeciążenie.

Zabezpieczenie aplikacji: sklepy, panele i integracje

Najczęściej atakowanym adresem w polskim internecie pozostaje panel administracyjny popularnych CMS-ów. Standardowe wordpress logowanie pod adresem /wp-login.php jest celem automatycznych botów niemal bez przerwy. Zmiana adresu panelu, limit pięciu prób na piętnaście minut, dwuskładnikowe uwierzytelnianie i blokada XML-RPC eliminują większość tego ruchu.

W sklepach kluczowe są endpointy, które omijają cache. Wyszukiwarka, filtry parametryczne i porównywarka produktów wykonują ciężkie zapytania SQL. Jeśli katalog obejmuje warianty w rodzaju klawiatura gamingowa mechaniczna, klawiatura mechaniczna 60 czy tablet graficzny wacom, liczba kombinacji filtrów rośnie wykładniczo i każdy bot potrafi wygenerować tysiące unikalnych adresów URL.

Osobnego planu wymagają integracje zewnętrzne. Feed produktowy dla usługi google merchant musi generować się z pliku statycznego odświeżanego cyklicznie, a nie w locie przy każdym pobraniu. Kilkanaście minut niedostępności feedu podczas ataku potrafi wstrzymać kampanie zakupowe na wiele godzin, mimo że sama witryna wróciła już do normy.

Konsekwencje biznesowe, SEO i plan reakcji

Długotrwała niedostępność uderza w widoczność organiczną. Robot indeksujący, który przez kilka dni otrzymuje kod 503, ogranicza budżet indeksowania, a pozycjonowanie strony traci tempo wypracowane przez miesiące. Powrót do wcześniejszych pozycji zajmuje zwykle od dwóch do sześciu tygodni, nawet gdy treści i profil linków pozostały nienaruszone.

Nie mniej istotny jest wpływ na parametry jakości. Czas odpowiedzi serwera i stabilność Core Web Vitals wpływają na pozycjonowanie strony w google, a incydenty przeciążeniowe pogarszają oba wskaźniki w danych zbieranych od realnych użytkowników. Dane te uśredniają się z okresu wielu tygodni, więc jeden poważny atak psuje statystyki na długo po jego zakończeniu.

Plan reakcji powinien istnieć na piśmie i poza atakowaną infrastrukturą. Zespół potrzebuje niezależnego kanału komunikacji – firmowa skrzynka w usłudze, której google workspace cena zaczyna się od kilkudziesięciu złotych za użytkownika miesięcznie, działa nawet wtedy, gdy własny serwer pocztowy stoi. Do tego lista kontaktów do operatora, gotowe reguły firewalla i zapasowa strona informacyjna na osobnym hostingu.

Jak sprawdzić, czy strona padła ofiarą ataku DDoS, a nie zwykłej awarii?

Zacznij od rozróżnienia objawów. Awaria pojedynczej usługi daje zwykle błąd 500 przy niskim obciążeniu maszyny, natomiast atak objawia się jednoczesnym wzrostem liczby połączeń, ruchu wychodzącego i czasu odpowiedzi. Sprawdź polecenie ss pod kątem połączeń w stanie SYN_RECV, przejrzyj logi serwera WWW pod kątem powtarzalnych ścieżek oraz nagłówków User-Agent i porównaj wykresy pasma z poprzednimi dniami. Jeżeli tysiące różnych adresów IP z kilkudziesięciu krajów odpytują ten sam adres URL co sekundę, masz do czynienia z atakiem. Pomocne jest też zestawienie z danymi analitycznymi: realny ruch użytkowników narasta stopniowo i ma dobową sezonowość, ruch z botnetu pojawia się skokowo i utrzymuje płaski, sztucznie równy poziom.

Czy darmowy plan CDN wystarczy jako ochrona przed atakiem DDoS?

Dla małej witryny informacyjnej lub bloga bezpłatny plan sieci dostarczania treści zwykle wystarcza, ponieważ blokuje ruch wolumetryczny zanim dotrze on do serwera źródłowego, a limity przepustowości nie są w nim narzucone. Ograniczenia zaczynają się przy warstwie aplikacyjnej: darmowe pakiety oferują podstawowy zestaw reguł WAF, prosty rate limiting i brak gwarantowanego czasu reakcji wsparcia. Sklep internetowy albo aplikacja SaaS potrzebuje reguł dopasowanych do własnych endpointów, analizy behawioralnej i logów w czasie rzeczywistym, a to elementy planów płatnych, kosztujących orientacyjnie od 80 do kilkuset złotych miesięcznie. Kluczowy warunek skuteczności jest zawsze ten sam: prawdziwy adres IP serwera musi pozostać ukryty, inaczej napastnik ominie całą warstwę filtrującą.

Co zrobić w pierwszych minutach trwania ataku?

Nie restartuj serwera w panice, bo utracisz dane diagnostyczne i wydłużysz przestój. Najpierw zabezpiecz próbkę logów i statystyki połączeń, potem włącz tryb ograniczonego zaufania: blokadę żądań bez poprawnego nagłówka, captcha dla ruchu spoza kraju docelowego oraz agresywny cache dla wszystkich stron publicznych. Równolegle powiadom operatora hostingu, podając adres IP celu, przybliżony wolumen i typ ruchu, ponieważ tylko on może uruchomić filtrowanie na brzegu sieci. Jeśli atak celuje w jeden adres URL, tymczasowo wyłącz tę funkcję zamiast całego serwisu. Po zakończeniu incydentu opisz przebieg zdarzenia, dopisz brakujące reguły do konfiguracji i ustaw alerty progowe, żeby kolejny raz wykryć problem w ciągu sekund.