Atak DDoS na stronę: co zrobić w pierwszych 30 minutach i jak nie dać się zaskoczyć drugi raz

Strona przestaje odpowiadać. Panel hostingowy działa, serwer pinguje, ale przeglądarka kręci się w nieskończoność. W statystykach ruch skoczył kilkunastokrotnie. Pierwsze pytanie brzmi: czy to atak, czy po prostu coś zadziałało lepiej, niż się spodziewałeś?

To rozróżnienie prowadzi do dwóch zupełnie różnych reakcji. Poniżej praktyczna kolejność działań na pierwsze pół godziny, bez teorii o tym, czym jest DDoS (pisaliśmy o tym w tekście czy DDoS jest realnym zagrożeniem dla Twojej strony), za to z konkretami.

Minuta 0–5: ustal, czy to w ogóle atak

Zanim cokolwiek zrestartujesz, zbierz trzy informacje.

Skąd przychodzi ruch. Otwórz statystyki serwera albo logi dostępowe i spójrz na rozkład geograficzny oraz adresy IP. Normalny skok ruchu ma sensowną strukturę: różne przeglądarki, wejścia na różne podstrony, konkretne źródło (kampania, link z dużego portalu, newsletter). Atak wygląda inaczej: setki adresów uderzających w jeden URL, ten sam user-agent w kółko, ruch z krajów, z których nigdy nie masz klientów.

Co dokładnie nie działa. Jeśli strona nie odpowiada, ale SSH i panel działają normalnie, problem jest najpewniej na poziomie aplikacji lub serwera WWW. Jeśli nie odpowiada nic, łącznie z pingiem, zapchało się łącze albo zadziałała mitygacja po stronie operatora.

Czy to pojedynczy adres URL. Ataki aplikacyjne bardzo często biją w jeden kosztowny endpoint: wyszukiwarkę, koszyk, stronę logowania, xmlrpc.php w WordPressie. Jeśli reszta serwisu odpowiada, a tylko ten jeden adres się dławi, masz już wskazówkę, gdzie postawić blokadę.

Minuta 5–10: czego NIE robić

Odruch numer jeden to restart serwera. W trakcie ataku to prawie zawsze zły pomysł: kasujesz bieżący obraz połączeń, tracisz kilka minut na start usług, a po podniesieniu wracasz do tego samego ruchu, tylko z pustym cache’em. Serwer dostaje wtedy mocniej niż przed restartem.

Drugi odruch to podbicie limitów: więcej procesów PHP, więcej workerów, większy pool bazy. Przy realnym skoku ruchu to pomaga, przy ataku pozwala tylko wysycić więcej zasobów, zanim coś padnie.

Trzeci: kasowanie logów, żeby „odetkać” dysk. Logi z czasu ataku to materiał, z którego potem zbudujesz reguły filtrowania. Jeśli brakuje miejsca, przenieś je, nie usuwaj.

Minuta 10–20: zgłoś i odetnij to, co da się odciąć

Zgłoś incydent operatorowi. Rób to równolegle do własnej diagnostyki. Ochrona antyDDoS działa na poziomie sieci, czyli tam, gdzie Ty nie masz dostępu. Twój firewall na serwerze filtruje pakiety, które już zjadły łącze. W RapidDC ochrona antyDDoS jest wpisana w usługę: przy serwerach VPS figuruje jako „Bezpłatny antiDDoS”, a przy serwerach dedykowanych jako ochrona Wanguard zawarta w cenie serwera (źródło: rapiddc.pl). Zgłaszając incydent, podaj godzinę rozpoczęcia, adres docelowy i przykładowe źródłowe adresy IP. To skraca czas dobrania filtra.

Zablokuj to, co oczywiste, u siebie. Jeśli atak idzie w jeden endpoint, najszybszą ulgę daje wyłączenie go lub postawienie przed nim bariery: wyłączenie xmlrpc.php, rate limiting na formularzu logowania, blokada zakresów IP w firewallu lub w .htaccess. Ataku wolumetrycznego to nie zatrzyma, ale przy ataku aplikacyjnym, takim, który udaje zwykłych użytkowników, potrafi wystarczyć.

Włącz agresywne cache’owanie. Statyczna wersja strony z cache’a kosztuje ułamek tego, co pełne renderowanie z bazą. Przestaw warstwę cache na maksimum i wydłuż czas życia. Sklep na chwilę przestanie pokazywać aktualne stany magazynowe. To mniejszy problem niż strona, która nie odpowiada w ogóle.

Minuta 20–30: obserwuj, nie eksperymentuj

Mitygacja po stronie operatora nie jest przełącznikiem: ruch jest analizowany, filtr dobierany, a efekt widać stopniowo. Daj temu kilkanaście minut i notuj, co zrobiłeś i o której. Jeśli w tym czasie zmienisz trzy rzeczy naraz, nie dowiesz się, co zadziałało.

Jak nie dać się zaskoczyć drugi raz

Atak DDoS rzadko jest jednorazowy. Jeśli ktoś raz sprawdził, że Twoja strona się kładzie, jest spora szansa na powtórkę.

Sprawdź, czy ochrona sieciowa w ogóle jest w Twojej usłudze. Filtrowanie musi działać przed Twoim serwerem, nie na nim. Warto to zweryfikować w opisie usługi, zanim będzie potrzebne. W ofercie VPS i serwerów dedykowanych RapidDC jest wymienione wprost; w tańszych pakietach hostingu współdzielonego argumentem jest raczej to, że dzielisz infrastrukturę operatora, a nie osobna, opisana usługa filtrowania.

Zmniejsz powierzchnię ataku. Wyłącz to, czego nie używasz: nieużywane wtyczki, otwarte porty, publiczne endpointy API bez uwierzytelnienia, xmlrpc.php, jeśli nie korzystasz z aplikacji mobilnej WordPressa. Każda z tych rzeczy to potencjalny cel, który nic Ci nie daje.

Miej cache i limity ustawione na stałe. Rate limiting na logowaniu, cache stron statycznych, limit żądań na IP. To wszystko ma sens na co dzień, a w trakcie incydentu kupuje czas.

Wiedz, kogo zawiadomić, i monitoruj stronę z zewnątrz. Kontakt do wsparcia operatora trzymaj poza własną infrastrukturą; jeśli zapiszesz go w intranecie na tym samym serwerze, w krytycznym momencie go nie odczytasz. Do tego prosty monitoring sprawdzający stronę co minutę z kilku lokalizacji: to różnica między reakcją po pięciu minutach a po dwóch godzinach.

Podsumowanie

W pierwszych 30 minutach ataku nie chodzi o to, żeby go pokonać. Od tego jest filtrowanie po stronie sieci operatora. Chodzi o to, żeby nie pogorszyć sytuacji: nie restartować w ciemno, nie kasować logów, szybko zgłosić incydent i odciąć najbardziej kosztowny endpoint. Reszta to praca, którą wykonuje się wcześniej.

Jeśli planujesz przeprowadzkę projektu na własny serwer albo właśnie wybierasz dostawcę, sprawdź, czy ochrona przed atakami jest częścią usługi, a nie płatnym dodatkiem, który dokupuje się po fakcie. W RapidDC antyDDoS jest wliczony w serwery VPS i serwery dedykowane. A jeśli nie masz pewności, który wariant pasuje do Twojego ruchu, napisz do nas i dobierzemy go razem.

FAQ – najczęściej zadawane pytania o atak DDoS na stronę

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

Zwykły skok ruchu ma sensowną strukturę: różne podstrony, różne przeglądarki, ruch z rynku, na którym działasz, i zwykle da się wskazać jego źródło: kampanię, newsletter, link z dużego serwisu. Atak zwykle uderza w jeden adres URL, powtarza ten sam user-agent i przychodzi z adresów, z których nigdy nie miałeś klientów.

Czy restart serwera pomaga w trakcie ataku?

Prawie nigdy. Restart kasuje bieżący obraz połączeń, czyści cache i zabiera kilka minut, a po starcie serwer dostaje ten sam ruch, tylko w gorszej kondycji. Lepiej zgłosić incydent operatorowi i ograniczyć najbardziej kosztowny endpoint.

Czy ochrona antyDDoS jest dodatkowo płatna w RapidDC?

Nie. Przy serwerach VPS ochrona antyDDoS jest opisana jako bezpłatna, a przy serwerach dedykowanych jako ochrona Wanguard zawarta w cenie serwera. Szczegóły znajdziesz na stronach serwerów VPS i serwerów dedykowanych.

Czy firewall na moim serwerze wystarczy, żeby zatrzymać DDoS?

Przy ataku aplikacyjnym, który generuje stosunkowo mało ruchu, firewall i rate limiting potrafią wystarczyć. Przy ataku wolumetrycznym nie. Pakiety wysycają łącze, zanim dotrą do Twoich reguł. Dlatego filtrowanie musi działać na poziomie sieci operatora, przed serwerem.

Co powinienem przygotować, zanim dojdzie do ataku?

Trzy rzeczy: kontakt do wsparcia operatora zapisany poza własną infrastrukturą, monitoring dostępności z zewnątrz oraz ustawione na stałe cache i limity żądań. To wszystko można przygotować w godzinę, a w trakcie incydentu oszczędza godziny.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.