Przeciążenie ruchem potrafi unieruchomić sklep, API albo panel administracyjny szybciej, niż administrator zdąży wejść do logów. W tym artykule wyjaśniam, czym jest atak typu DDoS, po czym go rozpoznać, jak zabezpieczyć serwer Linux i co zrobić w trakcie incydentu, żeby nie pogorszyć sytuacji. Skupiam się na działaniach, które realnie pomagają, a nie na poradach brzmiących dobrze tylko w teorii.
Najważniejsze fakty o DDoS i obronie przed nim
- DDoS to próba zablokowania usługi przez masowe obciążenie ruchem, a nie klasyczne włamanie do systemu.
- Najbardziej cierpią zwykle łącze, reverse proxy, limity połączeń i kosztowne endpointy aplikacji.
- Skuteczna obrona jest warstwowa: CDN lub WAF, limity żądań, cache, monitoring i plan reakcji.
- Samo
fail2banalbo pojedynczy firewall nie wystarczą przy większym wolumetrze ruchu. - W Polsce incydenty warto zgłaszać do CERT Polska, ale najpierw trzeba ustabilizować usługę i zebrać dane.
Jak działa przeciążenie rozproszone i dlaczego jest skuteczne
Jak podaje CISA, w ataku DDoS wiele maszyn działa jednocześnie przeciw jednemu celowi, najczęściej pod kontrolą botnetu. Napastnik nie musi łamać haseł ani omijać uwierzytelniania. Wystarczy, że zaleje usługę ruchem tak długo, aż zacznie odrzucać prawdziwych użytkowników albo stanie się po prostu nieużyteczna.
W praktyce rozróżniam trzy podstawowe warianty. Każdy z nich przeciąża inny element infrastruktury, więc każdy wymaga trochę innej reakcji.
| Typ | Na czym polega | Co zwykle pada pierwsze |
|---|---|---|
| Wolumetryczny | Zajmuje pasmo i łącze ogromną liczbą pakietów | Przepustowość, łącze operatora, edge |
| Protokołowy | Wyczerpuje zasoby związane z zestawianiem połączeń | Firewall, load balancer, tablice stanów |
| Aplikacyjny | Zasypuje konkretne endpointy kosztownymi żądaniami | CPU, backend, baza danych, workerzy aplikacji |
To ważne rozróżnienie, bo obrona przed każdym wariantem wygląda trochę inaczej. Gdy wiem, czy problem jest w paśmie, protokole, czy samej aplikacji, mogę szybciej zawęzić źródło kłopotów w logach i metrykach. A to z kolei prowadzi do pytania, jak odróżnić atak od zwykłego skoku ruchu.
Po czym odróżnić DDoS od zwykłego skoku ruchu
Ja zwykle zaczynam od prostej obserwacji: jeśli ruch rośnie, ale aplikacja nadal odpowiada, to często jest to normalny pik. Jeśli natomiast rosną timeouty, błędy 5xx, liczba otwartych połączeń i żądania przychodzą z setek różnych adresów, trzeba brać pod uwagę atak. Szczególnie podejrzane są sytuacje, w których użytkownicy skarżą się na wolne ładowanie, a monitoring pokazuje jednocześnie skok liczby żądań i spadek skuteczności odpowiedzi.
Jeśli widzę rosnące SYN, czyli pierwsze pakiety zestawiania połączenia TCP, a jednocześnie mało pełnych sesji, zwykle patrzę na warstwę protokołu. Gdy CPU i baza danych są przeciążone, ale transfer nie jest szczególnie wysoki, bardziej podejrzany staje się atak na warstwę aplikacji.
| Objaw | Co to sugeruje | Na co patrzeć od razu |
|---|---|---|
| Wykres transferu wystrzelił, a użytkownicy nie mogą wejść na stronę | Ruch wolumetryczny | Łącze, ruch przychodzący, statystyki operatora |
| Rośnie liczba krótkich połączeń i timeoutów | Presja na zestawianie połączeń | Firewall, tablica stanów, proxy, backlog |
| CPU i backend są na granicy, ale pasmo nie jest pełne | Atak aplikacyjny | Logowanie, wyszukiwanie, API, baza danych |
| Tylko część ścieżek działa wolno, reszta jest w porządku | Uderzenie w kosztowny endpoint | Najdroższe operacje i ich limity |
Największy błąd w tej fazie to reagowanie wyłącznie na samą liczbę wejść. W praktyce ważniejsze jest to, czy rośnie koszt obsługi pojedynczego żądania, bo właśnie tam przeciążenie najczęściej wygrywa z normalnym ruchem. Kiedy ten obraz zaczyna być czytelny, warto spojrzeć na to, co dokładnie dzieje się po stronie Linuksa.
Co dzieje się z serwerem Linux pod presją ruchu
Na Linuksie problem nie zawsze zaczyna się od CPU. Często pierwsze wysiadają limity połączeń, kolejka w NGINX-ie, tablica conntrack albo baza danych, która musi obsłużyć każde kosztowne żądanie po kolei. Jeśli masz tylko jedną maszynę z webserwerem, aplikacją i bazą, problem rozlewa się szybciej niż w układzie rozproszonym.
- Sieć - łącze zapycha się zanim proces aplikacji dostanie szansę odpowiedzieć.
- Kernel - rośnie liczba stanów połączeń, a tablice pomocnicze zaczynają się zapełniać.
- Serwer WWW - workerzy NGINX-a lub Apache przestają nadążać za żądaniami.
- Aplikacja - drogie endpointy, logowanie, wyszukiwanie i koszyk zużywają najwięcej zasobów.
- Dysk i logi - masowy zapis też potrafi spowolnić całość, zwłaszcza gdy logowanie jest zbyt gadatliwe.
To dlatego w praktyce patrzę nie tylko na wykres ruchu, ale też na opóźnienia, długość kolejek i zachowanie zależności, bo sama wysoka liczba żądań jeszcze niczego nie przesądza. Z takiego obrazu łatwo przejść do pytania ważniejszego: co trzeba mieć gotowe wcześniej, żeby incydent nie zamienił się w chaos.
Jak zbudować warstwową ochronę zanim pojawi się problem
Najlepsza obrona nie polega na jednym przełączniku. Ja układam ją warstwowo: najpierw edge i dostawca infrastruktury, potem aplikacja, a dopiero na końcu sam host. Dzięki temu pojedynczy skok ruchu nie musi od razu dotykać serwera, który naprawdę wykonuje pracę.
| Warstwa | Co wdrożyć | Po co |
|---|---|---|
| Edge i CDN | Anycast, cache, WAF, filtrowanie na brzegu | Odcina część ruchu zanim dojdzie do originu |
| Aplikacja |
limit_req, limit_conn, cache, oddzielenie ciężkich endpointów |
Chroni kosztowne żądania i logowanie |
| Host Linux | Gotowe reguły w nftables albo iptables, monitoring, alerty, backup konfiguracji |
Ułatwia utrzymanie stabilności po stronie systemu |
| Architektura | Repliki, osobny backend, zapasowy DNS lub failover | Zmniejsza ryzyko, że jedna awaria zatrzyma wszystko |
W NGINX-ie czy Apache warto zacząć od limitów na najbardziej kosztowne ścieżki, ale z głową. Zbyt agresywny rate limit bez rozsądnego burst potrafi odciąć prawdziwych użytkowników przy normalnym, chwilowym skoku ruchu. Przy kosztownych endpointach, takich jak logowanie, jako punkt startowy traktuję zwykle kilka-kilkadziesiąt żądań na minutę na adres IP, a dopiero potem koryguję próg po testach z realnym ruchem.
Jeśli mam wybrać jedną rzecz, którą wdrażam najpierw, to jest nią ochrona przy wejściu do infrastruktury, a nie dokładanie kolejnych zasobów na samym serwerze. To prowadzi wprost do pytania, co zrobić, kiedy ruch już trwa i trzeba ratować usługę w czasie rzeczywistym.
Co robić w trakcie incydentu, zanim usługa padnie całkiem
- Potwierdź, gdzie jest wąskie gardło. Sprawdź, czy problem dotyczy łącza, reverse proxy, aplikacji czy bazy danych.
- Włącz lub zaostrz ochronę u dostawcy. Jeśli masz CDN, WAF albo ochronę anty-DDoS u hostingu, uruchom ją od razu.
- Odetnij najdroższe ścieżki. Tymczasowo ogranicz logowanie, wyszukiwanie, API i inne endpointy, które kosztują najwięcej.
- Nie zmieniaj wszystkiego naraz. Jedna korekta, krótka obserwacja, dopiero potem kolejna. W przeciwnym razie nie wiesz, co faktycznie pomogło.
- Zachowaj logi i metryki. Eksport wykresów, zrzuty z dashboardów i próbki żądań są później bezcenne.
- Przygotuj komunikat dla użytkowników. Krótka informacja o problemie jest lepsza niż cisza i kolejne zgłoszenia do supportu.
- Jeśli masz plan awaryjny, użyj go. Przełączenie na statyczny komunikat lub zapasową lokalizację bywa lepsze niż trzymanie wszystkiego na siłę online.
W praktyce ten etap sprowadza się do kontroli szkód. Dopiero gdy sytuacja się stabilizuje, ma sens chłodna analiza, które zabezpieczenia pomogły, a które tylko podbiły liczbę fałszywych blokad. Właśnie tu najłatwiej popełnić błędy, które zamiast pomóc, jeszcze pogarszają sytuację.
Jakich błędów unikać, gdy walczysz o dostępność
Najczęstszy błąd to wiara, że jedno narzędzie załatwi wszystko. To nie działa ani z firewallem, ani z fail2ban, ani z ręcznym blokowaniem adresów, bo botnet zwykle szybko zmienia źródła i sposób wysyłania ruchu.
| Mit | Co jest prawdą |
|---|---|
| Wystarczy zablokować kilka IP | Przy ruchu rozproszonym adresy zmieniają się szybciej, niż zdążysz je dopisać do reguł. |
| Więcej CPU rozwiąże sprawę | Jeśli zapycha się łącze albo warstwa połączeń, mocniejszy procesor niewiele pomoże. |
fail2ban wystarczy |
To dobre narzędzie na nadużycia sesji i logowania, ale nie na masowy flood. |
| Im ostrzejszy limit, tym lepiej | Zbyt niski limit potrafi zablokować realnych użytkowników, zwłaszcza przy ruchu mobilnym lub kampanii promocyjnej. |
| CDN naprawi wszystko | CDN zmniejsza presję na origin, ale nie usuwa błędów aplikacji ani złych decyzji architektonicznych. |
Ja mam prostą zasadę: w czasie ataku nie naprawiam całej architektury, tylko ograniczam straty i zbieram dane do późniejszej poprawy. Jeśli problem wychodzi poza jedną maszynę, wchodzą w grę zgłoszenia i wsparcie z zewnątrz.
Kiedy zgłaszać incydent i co przygotować do analizy
Jeśli incydent dotyczy hostów w domenie .pl, polskiego dostawcy internetu albo po prostu nie masz pewności, skąd bierze się ruch, zgłoszenie do CERT Polska ma sens. Jak przypomina CERT Polska, zespół obsługuje incydenty związane z polską infrastrukturą i pomaga w ich analizie, więc im lepiej opiszesz sytuację, tym szybciej da się ocenić skalę problemu.
Przed zgłoszeniem przygotuj kilka rzeczy: dokładny czas rozpoczęcia incydentu, listę niedostępnych usług, przykładowe logi z reverse proxy lub firewalla, zrzuty metryk z ruchu oraz informację, czy zmieniłeś konfigurację w trakcie zdarzenia. Jeśli korzystasz z hostingu lub CDN, wyślij też te same dane do dostawcy, bo często ma własne narzędzia do szybkiego odcięcia szkodliwego ruchu.
W praktyce najbardziej pomaga krótki, rzeczowy opis tego, co widać, a nie emocjonalny raport po fakcie. Z takim materiałem łatwiej wrócić do pytania najważniejszego: co zrobić dziś, żeby następny incydent trwał krócej i kosztował mniej.
Co wdrożyć dziś, żeby następny incydent był krótszy
Gdybym miał ułożyć minimalny plan odporności dla serwera Linux, zacząłbym od pięciu rzeczy: CDN lub WAF przed publicznymi usługami, limity na kosztowne endpointy, sensowne monitorowanie, zapasową ścieżkę komunikacji i prosty runbook dla zespołu. To nie brzmi spektakularnie, ale właśnie taki zestaw najczęściej decyduje, czy awaria trwa dziesięć minut, czy pół dnia.
- Oddziel statyczne zasoby od dynamicznych odpowiedzi.
- Ustaw alerty na wzrost 5xx, timeoutów i nowych połączeń do 2-3 razy względem normalnego poziomu.
- Przećwicz ręczne włączenie ochrony i przełączenie na wersję awaryjną.
- Sprawdź, czy reguły
limit_reqilimit_connnie blokują normalnego ruchu po podbiciu obciążenia. - Trzymaj kopię konfiguracji i kontaktów do operatora, hostingu oraz osób decyzyjnych.
Jeśli mam wskazać jedną rzecz o największym zwrocie, to nie jest nią drogi sprzęt, tylko przygotowanie prostego planu reakcji i danych o normalnym ruchu. Bez tego każdy kolejny DDoS zamienia się w improwizację, a z nim staje się po prostu kolejnym incydentem do opanowania.
