Botnet DDoS na Linuxie - Jak się bronić?

Atak z użyciem botnetu potrafi unieruchomić serwis szybciej, niż administrator zdąży zareagować, bo ruch przychodzi z wielu, często rozproszonych urządzeń. W praktyce botnet DDoS to sieć przejętych maszyn, która jednocześnie zalewa usługę zapytaniami, a skutkiem bywa nie tylko spowolnienie, lecz także pełna niedostępność. W tym tekście wyjaśniam, jak taki mechanizm działa, po czym go rozpoznać i co realnie zrobić, gdy utrzymujesz usługę na Linuxie.

Czym jest botnet i dlaczego staje się narzędziem DDoS

Najprościej ujmując, botnet to grupa urządzeń przejętych przez napastnika. Czasem są to domowe routery, kamery, telewizory albo odkurzacze, ale w praktyce równie dobrze mogą to być źle zabezpieczone serwery. Gdy taka sieć dostaje polecenie, każde przejęte urządzenie wysyła część ruchu i razem tworzą przeciążenie, którego pojedynczy adres IP zwykle nie byłby w stanie wygenerować.

W analizie NASK przywołano dane, z których wynika, że w Polsce zarejestrowano 110 611 ataków DDoS, a średnia długość zakłócenia wyniosła 13 minut. To ważne, bo krótkie okno niedostępności bywa dla biznesu równie bolesne jak dłuższa awaria: użytkownik nie kupi, nie zaloguje się i często nie wróci od razu. Z mojego punktu widzenia właśnie ten krótki, ale powtarzalny efekt sprawia, że zagrożenie jest niedoceniane do momentu pierwszego poważnego incydentu.

Jeśli rozumiesz już różnicę między samym przeciążeniem a rozproszonym źródłem ruchu, łatwiej przejść do pytania, jak taki atak faktycznie wygląda od strony technicznej.

Jak przebiega atak z użyciem przejętych urządzeń

Napastnicy bardzo często opierają taki scenariusz na botnecie, bo tylko on daje im jednocześnie skalę i rozproszenie. To nie jest jednorazowe „uderzenie”, ale cały łańcuch działań: od przejęcia urządzeń po wysłanie polecenia do wszystkich naraz. Z perspektywy administratora ważne jest to, że końcowy ruch wygląda jak chaos, choć po stronie napastnika wszystko bywa zaskakująco uporządkowane.

1. Przejęcie urządzeń - najczęściej przez malware, słabe hasła, niezaktualizowane firmware albo wystawione usługi administracyjne.
2. Utworzenie kanału sterowania - zainfekowane urządzenia łączą się z serwerem C2, czyli centrum dowodzenia i kontroli.
3. Wybór wektora ataku - ruch może uderzać w warstwę sieciową, protokoły albo w samą aplikację webową.
4. Masowe wysłanie żądań - boty jednocześnie zalewają usługę pakietami, zapytaniami HTTP lub ruchem odbierającym zasoby serwera.

Najważniejsze są tu trzy techniczne pojęcia. Wolumetryczny atak zużywa łącze, atak protokołowy wyczerpuje zasoby pośrednich urządzeń, a atak warstwy aplikacji celuje w konkretne kosztowne operacje, na przykład wyszukiwanie, logowanie albo generowanie raportów. Dla obrony ma to znaczenie większe niż sama nazwa ataku, bo każdy z tych wariantów wymaga trochę innej reakcji.

Gdy już wiesz, co dzieje się po stronie napastnika, łatwiej rozpoznać, czy problem, który widzisz w logach, to zwykły wzrost ruchu, czy już realny incydent.

Po czym rozpoznać, że to nie jest zwykły skok popularności

Najczęstszy błąd polega na tym, że zespół przez kilka minut liczy na spontaniczny wzrost ruchu, kampanię marketingową albo chwilowe „przycięcie” hostingu. W przypadku DDoS wzór jest zwykle inny: ruch rośnie nagle, jest mało wartościowy, powtarzalny i pochodzi z wielu źródeł, które nie zachowują się jak normalni użytkownicy. Jeśli patrzę na takie incydenty, od razu szukam nie tylko skali, ale też jakości ruchu.

Na serwerze Linux dobrym sygnałem ostrzegawczym są też logi pełne podobnych żądań z krótkimi odstępami czasu, nagły wzrost liczby połączeń do jednego endpointu i nieproporcjonalnie wysokie zużycie procesora przez warstwę webową. Właśnie dlatego nie patrzę wyłącznie na `top` czy `htop`, ale na cały obraz: ruch sieciowy, logi serwera, błędy aplikacji i zachowanie łącza. To prowadzi prosto do pytania, jak takie środowisko ustawić, żeby atak nie położył wszystkiego jednym ruchem.

Jak bronić usługi na Linuxie przed przeciążeniem

Obrona przed DDoS nie zaczyna się w momencie ataku, tylko znacznie wcześniej. Z mojego doświadczenia najlepiej działa podejście warstwowe: najpierw odciążasz origin, potem ograniczasz koszt pojedynczego żądania, a dopiero na końcu próbujesz dopinać reguły na firewallu. Sam `nftables` czy `iptables` nie rozwiąże problemu, jeśli łącze zostanie zapełnione zanim pakiety w ogóle dotrą do hosta.

Na brzegu sieci

• Postaw przed usługą reverse proxy albo CDN, jeśli ruch webowy na to pozwala.
• Włącz ochronę upstream, czyli filtrowanie po stronie operatora lub dostawcy ochrony DDoS.
• Trzymaj kontakt do hostingu, ISP albo kolokacji zanim wydarzy się incydent.
• Nie zakładaj, że zmiana portu SSH uratuje usługę. To ogranicza szum, ale nie zastępuje ochrony przed zalaniem ruchem.

Na poziomie aplikacji

• Włącz rate limiting dla kosztownych endpointów, zwłaszcza logowania, wyszukiwania i API.
• Cache’uj to, co może być cache’owane, bo każda odpowiedź wygenerowana z pamięci jest tańsza niż dynamiczne przetwarzanie.
• Rozdziel publiczne zasoby od paneli administracyjnych.
• Sprawdź, czy aplikacja nie wykonuje ciężkich operacji przy każdym żądaniu.

Przeczytaj również: Jak usunąć wirusa z komputera - Skuteczny poradnik

Na poziomie hosta i procesu

• Monitoruj limity połączeń, czas odpowiedzi i błędy 5xx.
• Utrzymuj aktualizacje systemu i pakietów, zwłaszcza elementów wystawionych do internetu.
• Odseparuj usługi krytyczne od mniej ważnych, żeby awaria jednego komponentu nie wyłączyła wszystkiego.
• Przetestuj procedurę awaryjną, zanim będzie potrzebna.

ENISA w raporcie z 2025 roku pokazała, że DDoS nadal mocno uderza w administrację publiczną i sektor finansowy, a Polska jest w grupie krajów, które nie traktują tego zjawiska teoretycznie. To dobry argument, by nie stawiać wszystkiego na jedną kartę i nie liczyć na pojedyncze narzędzie ochronne. Kiedy ta warstwa jest już przemyślana, pozostaje pytanie: co zrobić w chwili, gdy atak właśnie trwa.

Co robić, gdy atak już trwa i liczy się każda minuta

W trakcie incydentu najważniejsze jest to, żeby nie popsuć sobie dostępu do danych o zdarzeniu i nie wprowadzić chaosu w zespole. Ja zwykle zaczynam od potwierdzenia, czy problem dotyczy łącza, aplikacji, czy konkretnego endpointu, a dopiero potem przechodzę do ostrych zmian w konfiguracji. Zbyt szybkie „gaszenie wszystkiego” często kończy się utratą informacji i trudniejszą analizą po fakcie.

1. Potwierdź wektor ataku - sprawdź, czy chodzi o pasmo, liczbę połączeń, HTTP, DNS czy inny protokół.
2. Włącz tryb ograniczania szkód - czasem lepsza jest częściowa degradacja usługi niż pełna awaria.
3. Uprość odpowiedzi - jeśli możesz, wyłącz ciężkie moduły, rozbudowane wyszukiwanie i kosztowne integracje.
4. Skontaktuj się z operatorem - przy większym ruchu filtracja po Twojej stronie może zwyczajnie nie wystarczyć.
5. Komunikuj się jasno - status page, krótkie komunikaty i przewidywany czas działań są lepsze niż cisza.
6. Zbieraj dowody - zrzuty logów, wykresy, sygnatury ruchu i czasy wystąpienia ataku przydadzą się później.

Warto też pamiętać o ograniczeniach: jeśli atak jest wolumetryczny, lokalne reguły bezpieczeństwa nie naprawią problemu same z siebie, bo ruch już zapełnił zasoby przed wejściem do aplikacji. Dlatego plan reakcji powinien zawierać nie tylko techniczne kroki, ale też jasną decyzję, kiedy przełączyć usługę w tryb awaryjny albo czasowo ją ograniczyć. Z takiego podejścia wynika jeszcze jedno ważne pytanie: dlaczego ten model ataku w ogóle nadal działa tak dobrze.

Dlaczego ten model ataku wciąż jest opłacalny dla przestępców

Odpowiedź jest prosta: niski próg wejścia, wysoka skala i duża liczba podatnych urządzeń. Dziś nie trzeba być wybitnym technicznie napastnikiem, żeby wynająć infrastrukturę DDoS, skorzystać z gotowego panelu albo oprzeć się na cudzym botnecie. To właśnie dlatego usługi typu web stresser lub DDoS-for-hire są tak niebezpieczne: zamieniają zaawansowany atak w produkt „na klik”.

Drugim powodem jest Internet rzeczy. Tysiące domowych urządzeń działa na domyślnych hasłach, z niedokładnie aktualizowanym firmware i bez realnej segmentacji sieci. W praktyce wystarczy jedno słabe ogniwo, by zostało dołączone do sieci zombie, a właściciel często niczego nie zauważa, bo sprzęt wygląda na sprawny. Taka cisza jest zdradliwa, bo utrudnia wykrycie całego problemu.

Trzeci powód dotyczy motywacji. DDoS jest używany nie tylko do zarabiania, lecz także do sabotażu, odwetu, zasłony dymnej albo nacisku politycznego. Wtedy celem bywa nie tyle trwałe zniszczenie infrastruktury, ile widoczny przestój, który psuje reputację i odciąga uwagę od innych działań. Z tego powodu sama blokada pojedynczej kampanii rzadko rozwiązuje temat na stałe; trzeba usuwać źródło podatności i uszczelniać cały proces.

To wszystko prowadzi mnie do praktycznej części końcowej: jeśli zarządzasz serwisem na Linuxie, co wdrożyć najpierw, żeby podnieść odporność bez przepalania czasu na rzeczy, które niewiele dają.

Co wdrożyć najpierw na serwerze Linux, żeby podnieść odporność

Gdybym miał wybrać tylko kilka działań na start, ustawiłbym je w tej kolejności. Najpierw potrzebujesz odciążenia przed serwerem, potem ograniczenia kosztu żądania, a dopiero na końcu dopieszczania reguł lokalnych. To nie jest efektowne, ale działa lepiej niż stawianie wszystkiego na pojedynczy firewall czy losowy plugin.

• Oddziel warstwę publiczną od originu - reverse proxy, CDN albo zewnętrzna ochrona mają więcej sensu niż bezpośrednie wystawianie aplikacji.
• Ustaw limity i cache - szczególnie dla loginu, wyszukiwania, API i stron dynamicznych.
• Zadbaj o monitoring - wykresy ruchu, opóźnień, błędów i saturacji łącza pokażą problem szybciej niż pojedynczy alert CPU.
• Przećwicz procedurę awaryjną - kto dzwoni do operatora, kto publikuje komunikat, kto zmienia konfigurację.
• Wzmocnij podstawy administracyjne - aktualizacje, MFA, segmentację sieci i sensowne hasła, bo botnet bardzo często zaczyna się od banalnego błędu.

Jeśli mam wskazać jedną zasadę, to tę: najlepsza obrona przed przeciążeniem nie polega na ściganiu każdego pakietu, tylko na skróceniu ścieżki, jaką musi przejść złośliwy ruch, zanim dotrze do Twojej aplikacji. Przy dobrze ustawionej architekturze, prostych limitach i planie reakcji botnet przestaje być nagłym zaskoczeniem, a staje się ryzykiem, które da się kontrolować.