Jak skutecznie zabezpieczyć serwer przed DDoS i botami? Praktyczny przewodnik po firewallu serwerowym

Konfiguracja firewallu serwerowego polega na otwarciu tylko niezbędnych portów i zablokowaniu wszelkiego niepotrzebnego ruchu; stanowi pierwszą linię obrony przed atakami DDoS, brute force i złośliwym ruchem botów. W praktyce chodzi o ograniczenie dostępu do SSH, kontrolowane udostępnienie usług webowych, wprowadzenie limitów na podejrzane zapytania, monitorowanie logów oraz – jeśli to możliwe – filtrowanie ruchu na wyższych warstwach dzięki CDN/WAF, zanim dotrze on do serwera.

Od momentu wystawienia serwera WWW do internetu możesz zostać niemal natychmiast zaatakowany skanowaniem portów, próbami logowania do SSH, botami szukającymi luk i fałszywymi user-agentami. Szczególnie w przypadku WordPressa, e-commerce, paneli administracyjnych, API czy serwerów gier, firewall to nie tylko kwestia technicznego wyboru, ale konieczność zapewniająca ciągłość działania. W tym poradniku krok po kroku pokażemy, jak zbudować skuteczną architekturę firewallu na serwerach Linux, uwzględniając UFW, firewalld, nftables, Fail2ban, web application firewall oraz metody ograniczania ataków DDoS.

Ważna uwaga na start: lokalny firewall na serwerze nie powstrzyma ataków DDoS o bardzo dużej skali. Przy ruchu na poziomie 20 Gbps, 80 Gbps lub więcej, pakiety mogą wypełnić łącze jeszcze zanim reguły na systemie operacyjnym zaczną działać. Dlatego najlepszą strategią jest wielowarstwowa ochrona: zabezpieczenia na poziomie dostawcy (DDoS protection), CDN/WAF, firewall systemowy, ograniczenia ruchu na poziomie aplikacji oraz regularna analiza logów. Jeśli szukasz odpowiedniej infrastruktury, zajrzyj na stronę Hostragons rozwiązania serwera VPS i VDS, a na temat bezpiecznego hostingu odwiedź Hostragons pakiety hostingu WWW.

Do czego służy firewall serwerowy?

Firewall serwerowy filtruje ruch sieciowy na podstawie adresu źródłowego i docelowego IP, portu, protokołu, stanu połączenia oraz czasem właściwości pakietów. Przykładowo, dla strony WWW powinny być otwarte porty 80 i 443, ale port bazy danych 3306 nie powinien być dostępny z internetu. Zamiast pozwalać na nieograniczony dostęp do SSH na porcie 22, lepiej zezwolić na połączenia tylko z adresu IP biura.

Firewall nie ma na celu magicznego wyeliminowania wszystkich ataków, ale zmniejszenie powierzchni ataku. Im mniej otwartych usług, tym mniej możliwości dla atakującego. Nowo postawiony serwer Linux może mieć otwarte SSH, panel WWW, pocztę, bazę danych, agenta monitoringu i usługi testowe – każda z nich to potencjalne ryzyko. Dobrze skonfigurowany firewall działa według zasady „domyślnie odrzucaj, zezwalaj na to, co potrzebne”.

Zrozumienie ataków DDoS i ruchu botów

Dlaczego ataki DDoS są wyjątkowe?

DDoS (Distributed Denial of Service) to atak polegający na zalaniu docelowej usługi ruchem z wielu źródeł, co prowadzi do jej niedostępności. Czasem atak wypełnia łącze internetowe, innym razem obciąża CPU i RAM serwera, a jeszcze innym wywołuje kosztowne operacje na poziomie aplikacji. Przykładowo, mały serwer aplikacji przy 50 000 żądań HTTP na sekundę może przestać odpowiadać, nie z powodu zapełnienia łącza, ale przeciążenia PHP-FPM, Node.js lub puli połączeń bazy danych.

Czy wszystkie boty są złe?

Nie. Boty takie jak Googlebot czy Bingbot oraz niektóre narzędzia monitorujące są pożyteczne. Z kolei złośliwe boty wykonują skanowanie paneli administracyjnych, przeglądanie otwartych katalogów, spamowanie formularzy, kopiowanie treści, nadużywają XML-RPC, tworzą fałszywe konta i wykonują próby logowania. Dlatego zarządzanie botami polega na rozróżnianiu ich zachowań, a nie na blokowaniu wszystkich. Sygnały alarmowe to wysoki odsetek błędów, bardzo szybkie i liczne żądania, nietypowe nagłówki i podejrzane wzorce URL.

Lista kontrolna przed rozpoczęciem konfiguracji

Największym ryzykiem przy wprowadzaniu reguł firewallu na działającym serwerze jest zablokowanie sobie dostępu. Dlatego przed zmianami warto się dobrze przygotować. Poniższa lista to sprawdzony sposób na bezpieczny start w środowiskach produkcyjnych.

• Nie zamykaj aktywnej sesji SSH; testuj zmiany z drugiego terminala.
• Upewnij się, że dostawca serwera oferuje konsolę, VNC lub tryb ratunkowy.
• Sprawdź, jakie porty są aktualnie otwarte, używając ss -tulpn lub netstat -tulpn.
• Zanotuj porty używane przez usługi webowe, mailowe, DNS, bazy danych, panele i monitoring.
• Jeśli korzystasz z IPv6, zaplanuj także reguły firewall dla tego protokołu.
• Zawsze najpierw dodaj reguły zezwalające (allow), potem odrzucające (deny).
• Sprawdź, czy reguły są trwałe i nie znikną po restarcie serwera.

Na przykład na typowym serwerze WWW powinny być otwarte porty 80, 443 oraz ograniczony port SSH. Jeśli nie działa poczta, porty 25, 465, 587, 993 nie muszą być dostępne. Jeśli baza danych jest wykorzystywana tylko lokalnie, porty 3306 lub 5432 powinny być zamknięte dla ruchu z internetu.

Jak wybrać narzędzie firewall?

W systemach Linux dostępnych jest wiele narzędzi zarządzających tą samą podstawową infrastrukturą filtrowania, ale różniących się łatwością obsługi. Dla początkujących UFW jest prosty i szybki w konfiguracji. W środowiskach korporacyjnych i na dystrybucjach opartych na Red Hat popularny jest firewalld. Zaawansowani użytkownicy mogą sięgnąć po nftables – nowoczesne i elastyczne rozwiązanie. Poniższa tabela ułatwia wybór:

Krok po kroku: konfiguracja firewallu serwera

1. Sprawdź otwarte porty i działające usługi

Pierwszym krokiem jest ustalenie, które usługi nasłuchują na jakich portach. Polecenie ss -tulpn pokazuje, jakie programy i porty są aktywne. Jeśli nginx słucha na 0.0.0.0:80 i 0.0.0.0:443, oznacza to, że przyjmuje ruch na wszystkich interfejsach sieciowych. MariaDB na 0.0.0.0:3306 to często ryzyko, bo baza powinna być dostępna lokalnie (np. 127.0.0.1).

Praktyczna zasada: żadna usługa, która nie musi być dostępna z internetu, nie powinna nasłuchiwać na 0.0.0.0. Najpierw popraw konfigurację usług, a dopiero potem blokuj porty firewallem – w ten sposób nawet jeśli firewall zostanie wyłączony, serwisy nie będą bezpośrednio dostępne z zewnątrz.

2. Ustaw domyślną politykę na odrzucanie

Bezpieczne konfiguracje firewallu zaczynają się od ustawienia domyślnej polityki blokującej ruch przychodzący i – w zależności od potrzeb – zezwalającej na ruch wychodzący. Na Ubuntu z UFW typowy przebieg to: najpierw zezwól na SSH, potem otwórz porty 80 i 443, następnie ustaw domyślne odrzucanie połączeń i włącz firewall.

Przykład: pozwól na SSH tylko z IP administratora, otwórz HTTP i HTTPS, zamknij niepotrzebne porty, włącz ochronę. Nigdy nie włączaj firewalla bez przyznania dostępu do SSH – to jedna z najczęstszych przyczyn utraty kontroli nad serwerem.

3. Ogranicz dostęp do SSH

SSH jest najczęstszym celem ataków. Serwer z otwartym portem 22 może otrzymywać setki lub tysiące prób logowania dziennie. Najbezpieczniejszą metodą jest ograniczenie dostępu po IP (np. biuro, VPN) oraz wyłączenie logowania na hasło na rzecz kluczy SSH.

• Wyłącz bezpośrednie logowanie na konto root.
• Korzystaj z kluczy SSH zamiast haseł.
• Ustal listę dozwolonych użytkowników za pomocą AllowUsers lub AllowGroups.
• Włącz Fail2ban do automatycznego blokowania adresów IP po wielu nieudanych próbach.
• Jeśli masz panel zarządzania, ogranicz dostęp do jego portu na podstawie IP.

Zmiana portu SSH może zmniejszyć ilość automatycznego szumu botów, ale prawdziwą ochronę zapewnia ograniczenie IP, silna autoryzacja i monitoring.

4. Kontrolowane otwarcie portów webowych

Na większości serwerów porty 80 (HTTP) i 443 (HTTPS) są niezbędne. Obecnie powinien dominować ruch na 443, a 80 służyć jedynie do przekierowań na HTTPS. Brak certyfikatu SSL obniża zaufanie użytkowników i pozycjonowanie w Google. Warto skorzystać z Hostragons certyfikaty SSL, by łatwo wdrożyć bezpieczne połączenie.

Jeśli korzystasz z CDN lub reverse proxy, zamiast otwierać porty dla całego internetu, zezwól tylko na ruch z adresów IP dostawcy CDN. To utrudnia poznanie prawdziwego adresu IP serwera i zwiększa ochronę przed atakami.

5. Zamknij porty baz danych i usług wewnętrznych

Usługi takie jak MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB nie powinny być dostępne z internetu. Brak zabezpieczeń w Redis lub otwarte porty Elasticsearch i MongoDB były przyczyną wielu wycieków danych. Te usługi należy konfigurować do nasłuchiwania tylko na localhost lub na prywatnym interfejsie sieciowym.

Na przykład WordPress może łączyć się z bazą działającą na 127.0.0.1. Jeśli baza jest na osobnym serwerze, pozwól na dostęp tylko z adresu IP serwera aplikacji. Pozostawienie portów 3306 lub 5432 otwartych do internetu to znany błąd, który zaprasza boty do ciągłych skanów.

6. Blokuj próby brute force z Fail2ban

Fail2ban analizuje logi i tymczasowo blokuje adresy IP, które wielokrotnie próbują się nieudanie zalogować. Można skonfigurować go dla SSH, nginx, Apache, Postfix, Dovecot, WordPressa i paneli administracyjnych. Przykład: zablokuj IP na godzinę po 5 nieudanych próbach logowania w ciągu 10 minut.

Uważaj, aby nie ustawiać zbyt agresywnych reguł na starcie – mogą blokować prawdziwych użytkowników. Lepiej monitorować logi i stopniowo zaostrzać politykę.

7. Dodaj limitowanie ruchu i połączeń

Na poziomie systemu można ograniczać liczbę połączeń i zapytań z jednego IP, co pomaga przy atakach DDoS i ogranicza złośliwy ruch botów. Nginx oferuje moduły limit_req i limit_conn, Apache ma mod_evasive lub podobne. Po stronie aplikacji warto wprowadzić limity na logowania, wyszukiwania, dodawanie do koszyka, płatności i endpointy API.

Przykład: na stronie logowania można zezwolić na około 10 prób na minutę z jednego IP, a na endpointach wyszukiwania – 2–5 zapytań na sekundę. Dla API stosuj limity na podstawie tokenów użytkowników, adresów IP i analizy zachowań, by atakujący nie mogli ominąć limitów przez zmianę IP.

Przykład bezpiecznej konfiguracji UFW

Na Ubuntu lub Debianie można zacząć od prostego scenariusza: sprawdź działające usługi, pozwól na SSH tylko z IP administratora, otwórz porty 80 i 443, ustaw domyślną politykę blokującą ruch przychodzący i włącz UFW. Jeśli nie możesz ograniczyć SSH do stałego IP, tymczasowo pozwól na dostęp z dowolnego adresu, a potem przejdź na VPN lub stały adres IP.

Przykładowa konfiguracja: adres IP administratora to 203.0.113.10; SSH dostępne tylko z tego IP; ruch webowy na 80 i 443 otwarty dla wszystkich; porty baz danych, Redis, panele i testowe zamknięte. To dobre rozwiązanie dla wielu małych i średnich serwisów. Aby poprawnie ustawić domenę i DNS, sprawdź Hostragons sprawdzanie domeny i rejestracja.

firewalld i strefy (zones)

Na serwerach AlmaLinux, Rocky Linux i RHEL firewalld jest często używany. Umożliwia pracę ze strefami: public dla interfejsów internetowych, trusted dla sieci zaufanych oraz drop do cichego odrzucania niechcianego ruchu. Ważne jest rozróżnienie reguł runtime (tymczasowych) i permanent (trwałych). Runtime działa od razu, ale znika po restarcie, permanent wymaga przeładowania, ale jest trwały.

W środowiskach korporacyjnych firewalld ułatwia zarządzanie dzięki profilom usług. Można np. udostępnić http i https w strefie public, a ssh tylko z wybranych adresów IP. Gdy masz różne sieci (administracja, backup, użytkownicy) na osobnych interfejsach, podział na strefy zwiększa bezpieczeństwo i przejrzystość.

CDN, WAF i ochrona DDoS na poziomie dostawcy

Firewall lokalny działa dopiero po dotarciu pakietów do serwera. Przy dużych atakach DDoS ważne jest, aby ruch był filtrowany wcześniej – na poziomie CDN, WAF i dostawcy usług. CDN dostarcza statyczne treści z lokalizacji brzegowych, WAF filtruje złośliwe żądania na poziomie aplikacji, a ochrona u dostawcy eliminuje duże natężenia ruchu na poziomie sieci.

Idealnie, gdy DNS kieruje ruch przez CDN, ukrywając prawdziwy adres IP serwera, który akceptuje połączenia tylko z IP CDN na portach 80 i 443. Porty administracyjne dostępne są tylko przez VPN lub stałe IP. Taki model zmniejsza ryzyko ataku bezpośrednio na IP serwera i pozwala wyłapywać boty jeszcze przed dotarciem do aplikacji. Więcej o bezpieczeństwie i optymalizacji strony znajdziesz w Przewodniki dotyczące przyspieszania i bezpieczeństwa strony internetowej.

Ochrona aplikacji przed botami

Blokowanie botów to nie tylko zakaz dostępu na podstawie IP. Nowoczesne boty korzystają z proxy, sieci mobilnych, adresów centrów danych oraz zmiennych user-agentów. Potrzebne jest podejście oparte na analizie zachowań: liczne próby logowania z jednego IP, masowe błędy 404, duża aktywność na wp-login.php lub xmlrpc.php, nietypowe wzorce kliknięć i nagłówki HTTP powinny być monitorowane.

• Stosuj limity zapytań na formularzach logowania i rejestracji.
• Ogranicz lub wyłącz niepotrzebny dostęp do XML-RPC.
• Chroń panel administracyjny innym URL, ograniczeniami IP i uwierzytelnianiem dwuskładnikowym.
• Filtruj podejrzane user-agenty i referery na poziomie WAF.
• Stosuj CAPTCHA i niewidzialne mechanizmy wykrywania botów, ale z umiarem.
• Dodaj kontrolę kluczy, podpisów, limitów i znaczników czasowych na endpointach API.

Zarządzanie botami powinno minimalizować uciążliwość dla prawdziwych użytkowników. Nadmierne CAPTCHA, agresywne blokady czy błędne blokowanie krajów mogą zaszkodzić klientom. Testuj i wprowadzaj zmiany stopniowo.

Monitorowanie logów i alarmy

Zakończenie konfiguracji to nie koniec pracy. Firewall to żywy system, który wymaga stałego nadzoru. Monitoruj pliki auth.log lub secure pod kątem prób logowania, analizuj access logi nginx pod kątem nagłych wzrostów ruchu, sprawdzaj error logi na zwiększoną liczbę błędów 404 i 500 oraz obserwuj obciążenie CPU i liczbę połączeń. Nawet proste alarmy mogą dać kilka minut przewagi podczas ataku.

Przykładowe progi alarmowe: ponad 100 błędów 404 z jednego IP w 5 minut, 20 prób logowania w minutę, CPU powyżej 90% przez 10 minut, trzykrotne zwiększenie liczby połączeń. Progi te należy dostosować do charakterystyki swojego serwisu.

Typowe błędy i jak ich unikać

• Włączenie firewalla bez ustalenia dostępu SSH: prowadzi do utraty dostępu. Zawsze testuj zmiany z drugiej sesji.
• Zapominanie o IPv6: może pozostawić otwarty dostęp, gdy IPv4 jest zablokowany.
• Otwarte porty baz danych (3306, 5432, 6379, 9200): to częsty cel botów skanujących.
• Używanie CDN bez ukrycia prawdziwego IP: atakujący mogą ominąć CDN i zaatakować bezpośrednio serwer.
• Brak dokumentacji reguł: utrudnia szybkie reagowanie w sytuacjach awaryjnych.
• Brak zaplanowanego dostępu awaryjnego: bez konsoli dostawcy naprawa błędów może się przedłużyć.

Przykładowa polityka bezpieczeństwa firewallu

Dla małej firmy polityka może wyglądać tak: domyślnie blokuj cały ruch przychodzący; port 443 dostępny dla wszystkich; port 80 tylko do przekierowań na HTTPS; SSH dostępne tylko z VPN lub stałego IP administratora; bazy danych dostępne lokalnie lub w sieci prywatnej; jeśli korzystasz z CDN, porty webowe otwarte tylko dla ich IP; Fail2ban monitoruje próby logowania; logi wysyłane do centralnego systemu monitoringu.

W średnich sklepach internetowych dodatkowo: whitelisty dla IP obsługi płatności, panel administracyjny za VPN, limity na API, aktywna ochrona WAF przed SQL injection i XSS, a także filtry geograficzne lub ASN na poziomie firewallu. Ważne, by plan był spisany – w trakcie ataku łatwiej wtedy zachować zimną krew i szybko reagować.

Testowanie: czy reguły działają?

Po konfiguracji koniecznie przetestuj firewall. Z innej sieci wykonaj skan portów, sprawdź, czy SSH działa tylko z autoryzowanego IP, potwierdź dostępność strony przez HTTPS, zweryfikuj, że porty baz danych są niedostępne z internetu. Jeśli korzystasz z CDN, spróbuj wykonać zapytanie HTTP bezpośrednio na adres IP serwera i sprawdź, czy jest zablokowane.

Podczas testów unikaj agresywnych skanów, które mogą zakłócić działanie produkcji. Po każdej zmianie eksportuj lub zapisuj konfigurację, by w razie problemów łatwo przywrócić poprzedni stan.

Plan konserwacji i aktualizacji

Zabezpieczenie serwera to proces ciągły, a nie jednorazowe działanie. Przy dodawaniu nowych usług sprawdzaj, czy wymagają otwarcia portów. Po usunięciu usług usuń niepotrzebne reguły. Regularnie instaluj aktualizacje bezpieczeństwa i przeglądaj logi. Dobrą praktyką jest miesięczna kontrola otwartych portów oraz kwartalny audyt konfiguracji firewallu.

Plan kopii zapasowych jest integralną częścią strategii bezpieczeństwa. Ataki DDoS mogą przerwać dostęp, ale ransomware lub nieautoryzowany dostęp grożą utratą danych. Bezpieczny hosting, certyfikaty SSL, zarządzanie domenami i backupy to elementy, które powinny iść w parze. W tym kontekście warto zajrzeć do Co należy wziąć pod uwagę przy wyborze bezpiecznego hostingu oraz Jak zainstalować certyfikat SSL.

Podsumowanie

Konfiguracja firewallu na serwerze nie uczyni go całkowicie niewidocznym dla ataków DDoS i botów, ale znacząco zmniejsza powierzchnię ataku, redukuje ryzyko nieautoryzowanego dostępu i pozwala na bardziej kontrolowane reagowanie na incydenty. Najlepsze efekty osiąga się łącząc ochronę na poziomie dostawcy, CDN/WAF, restrykcyjne polityki portów, ograniczenia SSH, Fail2ban, limity połączeń oraz monitoring logów.

Jeśli dopiero uruchamiasz projekt, zaplanuj politykę firewallu od początku – to znacznie łatwiejsze niż poprawianie błędów później. W Hostragons możesz kompleksowo zarządzać serwerem, hostingiem, domeną i SSL, jednocześnie dbając o wysoką odporność środowiska. Zacznij od prostego checklistu: zamknij niepotrzebne porty, ogranicz SSH, wymuś HTTPS i monitoruj logi.

Najczęściej zadawane pytania

Czy firewall serwerowy całkowicie powstrzyma atak DDoS?

Nie. Firewall lokalny może zmniejszyć skutki mniejszych ataków i niektórych protokołów, ale w przypadku dużych ataków niezbędne jest korzystanie z ochrony na poziomie dostawcy, CDN i WAF.

Jakie porty powinny być otwarte na serwerze WWW?

Standardowo porty 80 i 443 pozostają otwarte. SSH powinien mieć dostęp tylko z adresów IP administratorów. Porty baz danych i usług wewnętrznych powinny być zamknięte dla ruchu z internetu.

Co wybrać: UFW czy firewalld?

Dla Ubuntu i Debiana UFW jest prostszy na start. Na AlmaLinux, Rocky Linux i RHEL firewalld jest bardziej rozpowszechniony. Zaawansowane scenariusze mogą wymagać nftables.

Czy blokada botów na podstawie IP wystarczy?

Zazwyczaj nie. Nowoczesne boty korzystają z wielu IP i proxy. Obok blokad IP stosuje się limity zapytań, reguły WAF, analizę zachowań, CAPTCHA i limity na poziomie aplikacji.

Jakie jest największe ryzyko przy konfiguracji firewallu?

Największym ryzykiem jest zablokowanie własnego dostępu do SSH przez błędnie ustawione reguły. Dlatego najpierw konfiguruj dostęp do SSH, sprawdzaj zmiany z drugiego połączenia i miej przygotowany dostęp do konsoli dostawcy.