IPTABLES to potężne narzędzie w świecie bezpieczeństwa sieciowego, umożliwiające zaawansowaną konfigurację reguł zapory ogniowej w systemach opartych na Linuxie.
Pozwala administratorom na precyzyjne definiowanie, jakie połączenia są dozwolone lub blokowane, co stanowi kluczowy element skutecznej ochrony sieci.
Konfiguracja IPTables na serwerze Linux to podstawowa umiejętność bezpiecznego hostingu w 2026 roku.
Ten przewodnik przeprowadzi Cię krok po kroku - omówi działanie IPTables, bezpieczną konfigurację, typowe reguły, NAT/przekierowanie portów, trwałość po ponownym uruchomieniu oraz rozwiązywanie problemów.
Niezależnie od tego, czy korzystasz z serwera VPS, serwera dedykowanego, czy instancji w chmurze, poznasz gotowy do produkcji proces konfiguracji zapory sieciowej.
Iptables to program sterujący filtrem pakietów (głównie używanym jako zapora sieciowa bądź NAT) opracowany dla systemu operacyjnego Linux.
Program może być używany jako filtr pakietów, bądź tzw. stanowa zapora dla systemów Linux z jądrem począwszy od serii 2.4.x, kontrolujący połączenia wchodzące i wychodzące do sieci komputerowej lub stacji roboczej.
Iptables to interfejs wiersza poleceń dla frameworka Netfilter w jądrze Linux, który pozwala na filtrowanie pakietów sieciowych.
iptables to narzędzie wiersza poleceń do konfigurowania zapory sieciowej jądra Linuksa, zaimplementowanej w projekcie Netfilter.
Terminu iptables używa się również w odniesieniu do tej zapory sieciowej na poziomie jądra.
iptables służy do inspekcji, modyfikacji, przekazywania, przekierowywania i/lub odrzucania pakietów IP.
Kod filtrowania pakietów IP jest wbudowany w jądro i zorganizowany w zbiór tabeli, z których każda ma określone przeznaczenie.
Tabele składają się z predefiniowanych łańcuchów, zawierających reguły przeglądane sekwencyjnie.
Każda reguła zawiera predykat potencjalnych dopasowań i odpowiadającą akcję (zwaną celem), wykonaną gdy predykat jest spełniony.
Jeśli pakiet IP dotrze do końca łańcucha (w tym łańcucha pustego), jego ostateczne przeznaczenie określa polityka łańcucha.
Kluczem do zrozumienia działania iptables jest ten diagram.
Słowo małymi literami na górze to tabela, a słowo dużymi literami poniżej to łańcuch.
Każdy pakiet IP przychodzący na dowolnym interfejsie sieciowym przechodzi przez ten diagram przepływu od góry do dołu.
Powszechnym błędnym przekonaniem jest założenie, że pakiety przychodzące z interfejsu wewnętrznego są obsługiwane inaczej niż pakiety z interfejsu zwróconego do Internetu.
Wszystkie interfejsy są obsługiwane w ten sam sposób; to od Ciebie zależy zdefiniowanie reguł, które będą je traktować inaczej.
Oczywiście niektóre pakiety są przeznaczone dla procesów lokalnych i przychodzą z góry diagramu, zatrzymując się w punkcie <Local Process>, podczas gdy inne są generowane przez procesy lokalne; zaczynają się w punkcie <Local Process> i przechodzą w dół diagramu.
W zdecydowanej większości przypadków użycia nie będzie potrzeby korzystania z tabel raw, mangle ani security.
W większości przypadków użytkownik będzie potrzebować tylko dwóch z nich: filter i nat.
Tablicą domyślną jest “filter” i to tam konfigurujemy główne regułki takie, jak otwieranie i zamykanie portów, dostęp do poszczególnych usług z zewnątrz.
W tablicy “nat” umieszczamy regułki służące do realizacji NAT.
Ta tablica nie widzi wszystkich pakietów wchodzących na serwer, a jedynie pierwszy z nich, który zainicjalizował połączenie.
W tablicy “mangle” umieszczamy regułki, które dokonują modyfikacji pakietów, np. zmiana ttl.
Pakiety te nie będą NATowane.
W tej tablicy serwer widzi pakiety należące do danego połączenia poddawanego modyfikacji.
Nazwy łańcuchów wskazują, do którego ruchu zostaną zastosowane reguły na każdej liście.
INPUT dotyczy wszystkich połączeń przychodzących na maszynę wirtualną, OUTPUT dotyczy wszystkich połączeń wychodzących z maszyny wirtualnej, FORWARD dotyczy połączeń, które zostaną przekazane dalej.
Każdy łańcuch ma również swoje ustawienie zasad (policy), które określa sposób obsługi ruchu.
Zapory można zazwyczaj konfigurować na jeden z dwóch sposobów: albo ustawić domyślną regułę na akceptowanie, a następnie blokować niepożądany ruch za pomocą określonych reguł, albo za pomocą reguł definiować dozwolony ruch i blokować wszystko inne.
Łańcuchy posiadają domyślną politykę, która jest zazwyczaj ustawiona na ACCEPT, ale można ją zresetować na DROP, aby upewnić się, że nic nie przejdzie przez zestaw reguł.
Polityka domyślna zawsze obowiązuje tylko na końcu łańcucha.
Trzy najczęściej używane targety to ACCEPT, DROP oraz skok do chain zdefiniowanego przez użytkownika.
Gdy targetem jest wbudowany target, los pakietu jest ustalany natychmiast i przetwarzanie pakietu w bieżącej tabeli się kończy.
Gdy targetem jest łańcuch użytkownika, a przetwarzanie tego łańcucha nie ustali losu pakietu, pakiet zostanie porównany z pozostałymi regułami oryginalnego łańcucha.
Gdy reguła z targetem DROP się dopasuje, pakiet jest odrzucany i dalsze przetwarzanie zostaje zatrzymane.
Jeśli pakiet osiągnie target ACCEPT, nie przechodzi już przez pozostałe reguły chain ani kolejne chains tabeli - przetwarzanie przechodzi do pierwszego chain kolejnej tabeli.
Wbudowane targety to ACCEPT, DROP, QUEUE i RETURN; rozszerzeniami target'u są na przykład REJECT i LOG.
Przestrzegaj zasad i testuj dokładnie.
Ustaw domyślne zasady na DROP.
Zezwalaj na pętlę zwrotną i ustanowiony/powiązany ruch.
Dopuszczać SSH (z ograniczeniami prędkości) i wymaganymi portami serwisowymi (np. 80/443).
Opcjonalnie zezwól na ICMP (ping) z ograniczeniami.
Kłoda spada w rozsądnym tempie, aby zapewnić widoczność.
Aby skonfigurować IPTables na serwerze Linux, zdefiniuj domyślne zasady, zezwól na niezbędny ruch (SSH, HTTP/HTTPS), zezwól na nawiązane połączenia, a następnie usuń wszystkie pozostałe.
Zapisz i utrwal reguły za pomocą iptables-save lub iptables-persistent (Debian/Ubuntu) lub iptables-services (RHEL/Alma/Rocky).
Przetestuj w drugiej sesji, aby uniknąć blokad i utraty logów w celu rozwiązywania problemów.
Zawsze testuj nowe reguły iptables na zdalnym serwerze z ostrożnością.
Nieostrożna zmiana może zablokować Twój dostęp SSH!
Zawsze testuj reguły przed ich stałym wdrożeniem.
Rozwiązanie: Zawsze testuj nowe reguły z zabezpieczeniem.
Zawsze dodawaj reguły zezwalające na SSH oraz manageprzed ustawieniem zasad DROP.
Korzystaj z okien zmian i utrzymuj otwartą sesję konsoli (lub korzystaj z dostępu poza pasmem za pośrednictwem panelu hostingowego).
Zastosuj najmniejsze uprawnienia: udostępniaj tylko wymagane porty i podsieci.
Połącz z fail2ban i silnym uwierzytelnianiem (SSH klawiszy, MFA na panelach sterowania).
Udokumentuj swój zestaw reguł, używając komentarzy za pomocą -m comment -comment “purpose”.
Kontroluj wersje swoich reguł i automatyzuj je za pomocą Ansible lub skryptów powłoki.
Przejrzyj logi pod kątem nietypowych spadków i dostosuj limity przepustowości do swojego profilu ruchu.
Dostęp z uprawnieniami root lub sudo na serwerze Linux.
Dwie sesje otwarte.
Zawsze rób kopię zapasową.
Wymaga jądra skompilowanego z modułem ip_tables.
Iptables wymaga uprawnień roota do uruchomienia.
W większości dystrybucji Linux iptables jest preinstalowany.
Niestety tuż po zainstalowaniu naszego Debiana nasz firewall - którym jest iptables jest nie skonfigurowany i cały ruch przychodzący i wychodzący jest otwarty.
Możemy to sprawdzić.
Warto zwrócić uwagę, że reguły iptables domyślnie są tymczasowe i znikają po restarcie systemu.
Nasz firewall działa, ale po restarcie serwera zostanie przywrócona konfiguracja domyślna, bez naszych wpisów.
Obecnie, jeżeli maszyna wirtualna zostałaby ponownie uruchomiona wprowadzone zmiany w iptables nie zostaną zapamiętane.
Na początek utrzymujemy już nawiązane połączenie z serwerem (np.
pakietów tylko zapychają tablice i bufor serwera.
pakiety, które są pofragmentowane, błędne i nie powinny biegać po serwerze.
Najpierw ustaw rejestrowanie, a następnie zasady DROP.
Odrzuć nieprawidłowe pakiety.
Użycie limitu przepustowości pomaga spowolnić próby siłowego ataku.
Udostępniaj tylko to, czego potrzebujesz.
Ping pomaga w diagnostyce.
Minimum, które z pewnością będziemy chcieli mieć.
Tu ruch na portach 80 (HTTP), 443 (HTTPS), 22 (SSH).
Iptables może śledzić stan połączenia.
Po dodaniu wszystkich wymaganych reguł, należy zmienić zasady polityki łańcucha INPUT na DROP, aby nie zezwalać na innych ruch przychodzący niż zdefiniowany w dodanych wcześniej regułach.
W pierwszym wariancie będziemy informować o tym urządzenie, które nas odpytuje (REJECT).
Pierwsze polecenie sprawia, że ruch przychodzący jest odrzucany z powiadomieniem o tym adresu źródłowego pakietu.
W tym przypadku chcemy odrzucić pakiety bez informowania o tym urządzenia, z którego pochodzą zapytania.
Ważne - wyczyszczenie (parametr -F) musi znajdować się przed ponownym określeniem zasady dla danego rodzaju ruchu (DROP/REJECT/ACCEPT dla INPUT/OUTPUT/FORWARD).
Za pomocą tych dwóch parametrów możemy decydować o tym, jaką odpowiedź dostaną urządzenia wysyłające zapytania.
Oczywiście, produkcyjne wykorzystanie iptables nie może być takie uproszczone, ponieważ odrzucalibyśmy wszystkie zapytania, przez co dane urządzenie nie mogłoby w pełni funkcjonować w sieci.
Odpowiednie zabezpieczenie SSH to dość obszerny temat.
Nie należy bazować jedynie na wyłączeniu pingów i okrojeniu dostępu do portu - odpowiednie zabezpieczenie może wymagać np.
Sprawdźmy teraz czy SSH działa na porcie 22 i czy ten port jest otwarty.
Jak widać powyżej, port 22 jest otwarty i działa na nim usługa ssh.
Sprawdźmy, czy możemy za pomocą ssh zalogować się do systemu.
Udało się zalogować do ssh.
Zobaczmy co się stanie, gdy zablokujemy ruch przychodzący.
W tym momencie nie powinniśmy mieć możliwości zalogować się do SSH, bo zablokowaliśmy cały ruch przychodzący.
Zgodnie z planem, nie możemy połączyć się z urządzeniem za pomocą SSH.
Moim celem jest ograniczenie ruchu przychodzącego, pozwalając na działanie SSH w sieci lokalnej.
W tym wariancie urządzenie będzie odrzucać zapytania z poinformowaniem o tym nadawcy, pozwalając na połączenie SSH w sieci lokalnej.
Taka konfiguracja powinna zapewniać to, że podczas wysyłania pingów host odpowie o tym, że odrzuca zapytanie, lecz pozwoli na zalogowanie się do systemu z wykorzystaniem SSH.
Jak widać powyżej, konfiguracja działa poprawnie.
W tym wariancie będziemy logować się z wykorzystaniem SSH do systemu, który zgodnie z ustawieniami iptables będzie odrzucał ruch przychodzący, lecz zezwalał na logowanie po SSH dla urządzeń w sieci lokalnej.
Jak widać powyżej, udało się!
Do sprawdzenia konfiguracji iptables można wykorzystać proste polecenie, które wylistuje obecne ustawienia.
Warto zwrócić uwagę na przedostatnią linijkę na zrzucie ekranu (-A FORWARD -j REJECT -reject-with icmp-port-unreachable).
To właśnie to ustawienie odpowiada za to, jaki komunikat jest widoczny po wysłaniu zapytania ping, jeżeli używamy opcji REJECT.
Na podstawie powyższych przykładów dobrze widać, że iptables to wielofunkcyjne narzędzie, które może zwiększyć poziom bezpieczeństwa w danej organizacji lub pomóc w zarządzaniu ruchem sieciowym.
SSH to tylko jedna z usług, której bezpieczeństwo może zwiększyć iptables.
Można go również używać np.
Zamiast używania domyślnych łańcuchów (np. INPUT, OUTPUT, FORWARD), można tworzyć niestandardowe łańcuchy, co pozwala na bardziej zorganizowaną i czytelną konfigurację.
Możliwość filtrowania na podstawie adresacji MAC dodaje warstwę bezpieczeństwa.
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t mangle -A PREROUTING -p tcp -m conntrack -ctstate NEW -m tcpmss !
iptables -t mangle -A PREROUTING -s 127.0.0.0/8 !
Jeśli Twój serwer działa jako brama lub odwrotny serwer proxy, możesz potrzebować reguł NAT.
Moduł LOG może służyć do rejestrowania pakietów spełniających regułę.
W przeciwieństwie do innych celów, takich jak ACCEPT lub DROP, pakiet będzie nadal przechodzić przez łańcuch po napotkaniu celu LOG.
Oznacza to, że aby włączyć rejestrowanie wszystkich odrzuconych pakietów, należy dodać duplikat reguły LOG przed każdą regułą DROP.
Powyższy łańcuch logdrop wykorzystuje moduł limit, aby zapobiec nadmiernemu wzrostowi logu iptables lub niepotrzebnym zapisom na dysku.
Moduł limit jest wywoływany za pomocą -m limit.
Następnie można użyć --limit do ustawienia średniego tempa oraz --limit-burst do ustawienia tempa początkowego.
Dodaje regułę, która loguje wszystkie pakiety przechodzące przez nią.
Pierwsze 10 kolejnych pakietów będą logowane, a następnie tylko 5 pakietów na minutę.
Zakładając, że używasz syslog-ng, możesz kontrolować, gdzie w pliku syslog-ng.conf będą zapisywane wyniki logów iptables.
Najpierw utwórz kontener hash ipset.
Reguły można edytować poprzez: dołączenie -A reguły do łańcucha, wstawienie -I jej w określonym miejscu łańcucha, zastąpienie -R istniejącej reguły lub usunięcie -D jej.
Polecenie -F bez argumentów opróżnia wszystkie łańcuchy w bieżącej tabeli.
Podstawowym poleceniem do wyświetlenia listy bieżących reguł jest --list-rules (-S), które ma podobny format wyjściowy do narzędzia iptables-save.
Podczas pracy z iptables w wierszu poleceń polecenie --list (-L) przyjmuje więcej opcji i wyświetla więcej informacji.
Aby wyświetlić numery wierszy podczas wyświetlania reguł, dodaj do tego pola --line-numbers.
Domyślnie iptables udostępnia pusty zestaw reguł w pliku /etc/iptables/iptables.rules.
Podobnie, reguły iptables dla IPv6 są domyślnie przechowywane w pliku /etc/iptables/ip6tables.rules, który jest odczytywany przez ip6tables.service.
W systemach Debian/Ubuntu zainstaluj iptables-persistent i uruchom netfilter-persistent save.
W systemach RHEL/Alma/Rocky zainstaluj iptables-services, zapisz reguły w pliku /etc/sysconfig/iptables i włącz usługę iptables.
Sprawdź przy ponownym uruchomieniu poleceniem iptables -L -n -v.
Na Debianie, jeśli widzimy plik firewall to przystępujemy do następnej czynności.
Kopiujemy nasz plik firewall do katalogu init.d.
W katalogu tym znajdują się skrypty startowe uruchamiane podczas ładowania systemu.
Zamykamy terminal i uruchamiamy ponownie komputer.
Wraz ze startem nasz zestaw reguł filtrujących powinien wystartować.
Active: active (exited) - oznacza że skrypt działa, ale nie wie gdzie jest jego daemon by go monitorować.
Komunikaty Active: active (exited) i mar 16 16:24:03 debian systemd[1]: Started firewall.
Wyświetlanie reguł w formie polecenia: iptables -S
Sprawdź liczniki: iptables -L -n -v
Zweryfikuj usługi nasłuchujące: ss -tulpn
Skanuj z innego hosta (ostrożnie): nmap -Pn -p 22,80,443 your.server.ip
Obserwuj logi: journalctl -f lub tail -f /var/log/syslog
Przywróć kopię zapasową, jeśli to konieczne:
sudo iptables-restore < ~/iptables.backup.DATE.v4
Pora na sprawdzenie poprawności działania konfiguracji iptables.
Jak widać na powyższym zrzucie ekranu, dostajemy informację zwrotną o treści Destination port unrechable.
Można również zauważyć w ostatniej linijce, że na cztery wysłane zapytania (Sent) wszystkie dostały odpowiedź (Received), co skutkuje zerową utratą pakietów (0% loss).
Terminal po edytowaniu opcji dla ruchu wychodzącego.
Porównanie zapytań.
Tak jak widać powyżej - pierwsze zapytanie dało odpowiedź o treści Destination port unreachable i 0% utraconych pakietów (0% loss), zaś drugie zapytanie dało jedynie informacje o braku odpowiedzi (Request timed out.) i o tym, że wszystkie pakiety nie dostały odpowiedzi (100% loss).
IPTables: granularne, klasyczne narzędzia; stroma krzywa uczenia się; nadal obsługiwane poprzez iptables-nft w nowoczesnych jądrach.
UFW: przyjazny dla użytkownika interfejs (Ubuntu); świetny dla prostych zapór sieciowych hosta.
firewalld: dynamiczny demon ze strefami; domyślny w RHEL/Fedora; łatwiejsze zasady obsługi wielu interfejsów.
nftables: nowoczesna wymiana; ujednolicona IPv4/IPv6; prostsza składnia i lepsza wydajność.
Uwaga: Nowsze dystrybucje coraz częściej używają nftables jako alternatywy dla iptables.
Tak, nftables to następca iptables, oferujący lepszą wydajność i składnię. Jednak iptables pozostaje szeroko używany i wspierany.
W przypadku nowych wdrożeń w najnowocześniejszych dystrybucjach, nftables lub firewalld są odporne na wyzwania przyszłości.
Jeśli Twoje podręczniki i zespoły są ujednolicone w oparciu o IPTables, warstwa kompatybilności pozostanie niezawodna w 2026 roku.
Dla uproszczenia, UFW (Ubuntu) i firewalld (RHEL) są prostsze i dobrze integrują się z nftables.
IPTables doskonale nadaje się do szczegółowej kontroli lub starszych podręczników.
Wybierz narzędzie, które pasuje do umiejętności Twojego zespołu i domyślnych ustawień systemu operacyjnego.
| Obszar | Znaczenie |
|---|---|
| filter | otwieranie i zamykanie portów, dostęp do usług z zewnątrz |
| nat | realizacja NAT i przekierowanie portów |
| mangle | modyfikacja pakietów, np. zmiana ttl |
| INPUT | ruch przychodzący do maszyny |
| OUTPUT | ruch wychodzący z maszyny |
| FORWARD | ruch przekazywany dalej |
Na podstawie tych zasad można budować konfiguracje od prostych reguł po bardzo złożone profile zapory.
Bardziej zaawansowane filrewalle mają po kilkaset linijek i są bardziej skomplikowane.
Powyższe jednak powinny wyeliminować typowe ataki oraz zabezpieczyć przed typowymi robotami, a takich ataków jest w sieci ok 90%.
Iptables to potężne narzędzie do konfiguracji zapory sieciowej w systemach Linux, będące standardem w zabezpieczaniu serwerów i sieci.
Mimo że jego składnia może wydawać się początkowo skomplikowana, opanowanie podstawowych komend i zrozumienie typowych reguł pozwoli Ci znacząco zwiększyć bezpieczeństwo Twojego serwera.
Iptables to potężne narzędzie, które stanowi pierwszą linię obrony Twojego serwera.
Zapamiętaj, że iptables to tylko jeden z elementów kompleksowej strategii bezpieczeństwa.

Iptables to program, który powinien być znany każdemu „linuksiarzowi”.
Pozwala on na stworzenie filtrowanie i przekierowywanie pakietów, określanie dozwolonych portów i protokołów, przekierowywanie portów czy stworzenie prostej zapory sieciowej (ang.
Nie należy bazować jedynie na wyłączeniu pingów i okrojeniu dostępu do portu - odpowiednie zabezpieczenie może wymagać np.
SSH to tylko jedna z usług, której bezpieczeństwo może zwiększyć iptables.
tags: #iptables #ochrona #konfiguracja #debian
About the author