Atak DDoS - Jak chronić serwer Linux? Poradnik

Atak DDoS to jedno z tych zagrożeń, które nie muszą wykradać haseł ani łamać serwera, żeby sparaliżować biznes. Wystarczy przeciążyć łącze, firewall albo samą aplikację, a użytkownik widzi tylko błędy, timeouty i niedostępny panel. W tym tekście wyjaśniam, jak taki atak działa, czym różni się od zwykłego DoS, po czym go rozpoznać i co realnie pomaga na serwerach z Linuksem.

Co właściwie oznacza atak DDoS

Ja patrzę na DDoS przede wszystkim jak na atak na dostępność. Celem nie jest zwykle kradzież danych, tylko zablokowanie normalnego ruchu, tak aby legalni użytkownicy nie mogli skorzystać z usługi. W praktyce serwis może działać częściowo, ale odpowiada wolno, zwraca 502/503 albo przestaje przyjmować połączenia w ogóle.

Różnica między DoS a DDoS jest prosta: w DoS źródło ruchu jest jedno lub nieliczne, w DDoS ruch płynie z wielu maszyn naraz, często z botnetu. To właśnie rozproszenie utrudnia blokowanie, bo pojedynczy adres IP przestaje być wystarczającą wskazówką. Z perspektywy administratora problemem nie jest sam hałas w logach, tylko fakt, że infrastruktura musi odróżnić normalnych użytkowników od atakujących.

Warto też rozdzielić dwa scenariusze: czasem atak tylko „dusi” serwis ruchem, a czasem wykorzystuje słabsze punkty aplikacji, na przykład kosztowne zapytania do bazy danych albo endpointy bez cache. To rozróżnienie będzie ważne, bo inna obrona działa na zalew sieci, a inna na przeciążenie logiki aplikacji. Żeby to dobrze zobaczyć, najpierw trzeba zajrzeć pod maskę samego ataku.

Jak wygląda taki atak od środka

Najczęściej wszystko zaczyna się od botnetu, czyli grupy zainfekowanych urządzeń, które napastnik może sterować zdalnie. Właściciele tych komputerów czy kamer IP zwykle niczego nie widzą, a ich sprzęt staje się źródłem ruchu wysyłanego do ofiary. To dlatego ataki rozproszone są tak kłopotliwe: pojedyncze źródło wygląda niegroźnie, ale setki albo tysiące źródeł naraz potrafią zalać nawet solidną infrastrukturę.

Botnet i ruch sterowany z wielu miejsc

Każdy bot wysyła niewielką porcję żądań, ale razem tworzą one strumień większy, niż zwykły serwer jest w stanie obsłużyć. W praktyce w logach widzisz dziesiątki krajów, różne adresy IP i często ten sam wzorzec zachowania. To jeden z powodów, dla których proste blokowanie pojedynczych adresów zwykle niewiele daje.

Refleksja i amplifikacja

W części ataków napastnik korzysta z serwerów pośrednich, aby wzmocnić ruch. To właśnie amplifikacja: małe zapytanie wywołuje dużą odpowiedź, która trafia do ofiary. Taki mechanizm często wykorzystuje usługi oparte na UDP, bo łatwiej tam ukryć źródło i podbić objętość ruchu.

Warstwa aplikacji

Inny wariant polega na wysyłaniu żądań HTTP, które wyglądają normalnie, ale są kosztowne dla aplikacji. Jedna strona może wymagać kilku zapytań do bazy, renderowania szablonu i sprawdzania sesji, więc duża liczba takich wejść zjada CPU i pamięć szybciej, niż administrator się spodziewa. Na Linuksie widać to potem jako rosnące zużycie procesora, kolejki połączeń i opóźnienia, które narastają lawinowo.

Ten podział ma znaczenie, bo nie każdą falę ruchu zatrzyma ten sam zestaw narzędzi. I właśnie dlatego kolejny krok to rozróżnienie typów ataków oraz ich skutków.

Rodzaje ataków i różnica między DoS, DDoS oraz DRDoS

Jeśli ktoś mówi o DDoS ogólnie, zwykle ma na myśli jeden z trzech wzorców. W praktyce różnią się one źródłem ruchu, celem technicznym i tym, co najbardziej cierpi po stronie ofiary.

Warto zapamiętać, że DRDoS jest w praktyce odmianą DDoS opartą na odbiciach i amplifikacji, więc nie chodzi o nowy osobny problem, tylko o inny sposób pompowania ruchu. Z perspektywy obrony liczy się nie nazwa, lecz to, czy trzeba filtrować ogromny wolumen pakietów, czy raczej kosztowne żądania aplikacyjne.

Właśnie dlatego dalej skupię się na objawach, które pozwalają odróżnić prawdziwy atak od zwykłego skoku popularności. To oszczędza czas i chroni przed błędną reakcją.

Po czym poznać, że to już atak, a nie tylko większy ruch

Największy błąd, jaki widzę, to zakładanie z góry, że każdy skok ruchu jest atakiem. Czasem źródłem problemu jest kampania mailingowa, publikacja w dużym serwisie albo po prostu nowa funkcja, która generuje więcej zapytań. DDoS zaczyna się wtedy, gdy wzorzec ruchu jest nienaturalny, rozproszony i wyraźnie nieproporcjonalny do realnej aktywności użytkowników.

• Łącze osiąga maksimum, mimo że ruch biznesowy nie wzrósł w podobnym tempie.
• W logach pojawia się masa powtórzeń jednej ścieżki, na przykład logowania, wyszukiwania albo endpointu API.
• Rośnie liczba połączeń półotwartych, a użytkownicy zgłaszają timeouty i błędy 502/503.
• Obciążenie CPU, pamięci albo bazy danych skacze bez wyraźnej przyczyny po stronie aplikacji.
• Widzisz wiele adresów IP, ale bardzo podobny sposób działania, nagłówki albo sekwencję żądań.

Ja na szybko sprawdzam ss -s, obciążenie procesów w top lub htop i logi reverse proxy, bo to daje szybki obraz tego, czy problem siedzi w sieci, w połączeniach czy w aplikacji. ss -s pokazuje podsumowanie socketów, a logi Nginxa albo Apache często od razu ujawniają, które ścieżki są mielone najczęściej. Jeśli ten obraz się potwierdza, czas przejść z diagnozy do obrony.

W praktyce najwięcej zyskuje się wtedy, gdy zespół ma już przygotowaną warstwę ochrony, a nie dopiero zastanawia się, co włączyć pod presją.

Jak się bronić na Linuksie i w całej architekturze

Ja zawsze zaczynam od jednej zasady: obrona przed DDoS nie jest pojedynczą regułą w firewallu, tylko warstwą decyzji. Jeśli łącze do serwera jest pełne, to nawet najlepszy nftables nie uratuje sytuacji, bo pakiety i tak nie dotrą do hosta. Dlatego największą różnicę robi ochrona upstream, czyli po stronie CDN, WAF, hostingu lub sieci Anycast.

Co daje najwięcej zanim pojawi się problem

• CDN i cache dla treści statycznych, żeby origin nie obsługiwał każdego żądania samodzielnie.
• WAF z regułami pod ataki HTTP, zwłaszcza gdy problem dotyczy logowania, wyszukiwania lub API.
• Anycast, które rozrzuca ruch po wielu węzłach i zmniejsza ryzyko jednego gardła.
• Ukrycie serwera źródłowego za warstwą pośrednią, żeby nie wystawiać publicznie originu.
• Limity żądań per IP i per ścieżka, bo kosztowne endpointy trzeba traktować osobno.

Przeczytaj również: Wolne Wi-Fi? Darmowe programy do analizy sieci - optymalizacja

Co warto ustawić na samym serwerze

• limit_req i limit_conn w Nginx, jeśli to właśnie reverse proxy stoi na pierwszej linii.
• Rozsądne reguły nftables, ale bez wiary, że hostowy firewall załatwi wszystko.
• Wyłączenie zbędnych usług i zamknięcie portów, których nikt realnie nie używa.
• Monitoring i alerty, które pokażą wzrost ruchu, zanim zrobi to klient.
• Osobny kanał administracyjny lub bastion, żeby nie stracić dostępu do maszyny zarządzającej.

Na hostach linuksowych dobrze działa też zdrowy sceptycyzm wobec narzędzi typu fail2ban: pomagają przy brute force i prostym nadużyciu, ale same nie zatrzymają dużego zalewu ruchu. To narzędzie porządkowe, nie tarcza przeciw volumetric DDoS. W praktyce najlepiej sprawdza się zestaw: CDN lub proxy zewnętrzne, cache, limity aplikacyjne i monitoring, który pokaże problem, zanim użytkownicy zaczną się skarżyć.

Gdy ta warstwa jest już ustawiona, kolejnym krokiem jest procedura reakcji na moment, w którym atak jednak się zacznie.

Co robić, gdy atak już trwa

W czasie ataku najgorsze są chaotyczne ruchy. Reset serwera, losowe zmiany w regułach i wyłączanie usług „na próbę” często wydłużają przestój, zamiast go skrócić. Ja trzymam się wtedy krótkiej sekwencji działań.

1. Potwierdź, czy to rzeczywiście DDoS, sprawdzając metryki, logi i stan łącza.
2. Skontaktuj się z hostingiem, CDN lub ISP, bo tylko oni mogą ograniczyć ruch przed Twoim łączem.
3. Włącz ostrzejsze reguły WAF, rate limiting i, jeśli trzeba, tymczasowe blokady na najbardziej kosztowne endpointy.
4. Przełącz ruch statyczny na cache albo stronę zastępczą, żeby odciążyć origin.
5. Zapisz logi, timestampy i zmiany konfiguracyjne, bo po incydencie będą potrzebne do analizy.
6. Poinformuj użytkowników o problemie i przewidywanym czasie reakcji, zamiast zostawiać ich bez komunikatu.

Na samym Linuxie pomaga szybka diagnostyka: ss -s do spojrzenia na połączenia, top lub htop do obciążenia procesów i logi reverse proxy, które pokażą, czy atak celuje w konkretny adres, metodę lub nagłówek. Ale jeśli pasmo jest już zapchane, te narzędzia mówią głównie, co się dzieje, a nie przywracają dostępności. Od tego jest warstwa zewnętrzna i dlatego nie wolno jej odkładać „na później”.

Po opanowaniu sytuacji warto jeszcze wyciągnąć wnioski, bo ten sam błąd zwykle wraca w kolejnym ataku.

Co zostaje z tego tematu po pierwszym incydencie

DDoS nie jest problemem, który wygrywa się jedną regułą albo jednym narzędziem. Najlepsze efekty daje warstwowa obrona: ochrona przed łączem, filtracja na brzegu sieci, limity w aplikacji i procedura reakcji, którą zespół zna zanim wydarzy się awaria.

• Największa różnica to przygotowanie originu i ruchu przez CDN, WAF oraz cache.
• Najczęstszy błąd to poleganie wyłącznie na firewallu hosta albo fail2ban.
• Najbardziej zdradliwy wariant to atak na warstwę aplikacji, bo wygląda jak zwykły ruch użytkowników.
• Najlepsza inwestycja to monitoring, limity i plan eskalacji, a nie improwizacja w momencie awarii.

Jeśli mam streścić to jednym zdaniem, DDoS to test nie tyle samego serwera, ile całej architektury i procesu reakcji. Kto ma zapas pojemności, warstwy pośrednie i sensowny playbook, ten przechodzi przez taki incydent znacznie spokojniej niż ktoś, kto liczy wyłącznie na pojedynczą regułę w systemie.