1/50
Zapory sieciowe i translacja adresów w Linux

Ochrona sieci

Prezentacja dotyczy zaawansowanego zarządzania ruchem sieciowym w systemie Linux z wykorzystaniem frameworku Netfilter oraz narzędzi iptables i nftables. Omówione zostaną architektura zapory stanowej i bezstanowej, mechanizmy translacji adresów NAT (SNAT, DNAT, masquerading) oraz przekierowanie portów w środowisku produkcyjnym. Jest to jedenasta część cyklu Administracja Sieci Komputerowych.

Architektura firewalla Linux

Prezentacja numer jedenaście z cyklu Administracja Sieci Komputerowych poświęcona jest w całości tematyce zapór sieciowych i translacji adresów w systemie Linux. W materiale przedstawiono zarówno teoretyczne podstawy działania frameworku Netfilter wbudowanego w jądro systemu, jak i praktyczne aspekty konfiguracji reguł filtrowania pakietów z użyciem narzędzi iptables oraz nftables.

Szczególny nacisk położono na zrozumienie różnic między filtrowaniem stateless a stateful, architekturę łańcuchów (chains) oraz polityki domyślne kształtujące zachowanie zapory. Druga część prezentacji koncentruje się na mechanizmach NAT – zarówno źródłowym (SNAT, masquerading), jak i docelowym (DNAT, port forwarding).

Prezentacja zawiera szczegółowe laboratorium krok po kroku, w którym przedstawiono praktyczną konfigurację firewalla i NAT na rzeczywistym przykładzie routera Linux. Całość uzupełniają techniki troubleshootingu, użycie tcpdump do debugowania oraz ściągawka (cheat sheet) najważniejszych poleceń.

2/50
Cel warsztatu – bezpieczeństwo i translacja pakietów

Cel warsztatu

Zarządzanie bezpieczeństwem i translacją pakietów na warstwie rdzeniowej systemu Linux.

  • Zrozumienie architektury Netfilter i jej miejsca w stosie sieciowym jądra
  • Praktyczna konfiguracja reguł filtrowania w iptables i nftables
  • Implementacja NAT: SNAT, DNAT, masquerading i port forwarding
  • Budowanie polityk bezpieczeństwa zgodnie z zasadą najmniejszych uprawnień
  • Diagnostyka i rozwiązywanie problemów z regułami firewalla w środowisku produkcyjnym
  • Przygotowanie do samodzielnej konfiguracji routera Linux w sieci LAN/WAN
Mapa celów warsztatu

Głównym celem warsztatu jest wyposażenie uczestników w praktyczną wiedzę niezbędną do konfiguracji i utrzymania zapory sieciowej w systemie Linux w środowisku produkcyjnym. Obejmuje to zarówno ochronę samego hosta (INPUT/OUTPUT), jak i konfigurację routera z funkcją firewalla dla ruchu tranzytowego (FORWARD).

Drugim kluczowym obszarem jest translacja adresów sieciowych (NAT), bez której działanie współczesnego Internetu w oparciu o IPv4 nie byłoby możliwe. Uczestnicy nauczą się konfigurować SNAT dla ruchu wychodzącego, DNAT dla usług dostępnych z zewnątrz oraz mechanizm masquerading dla interfejsów z dynamicznym adresem IP.

Warsztat kładzie silny nacisk na aspekty bezpieczeństwa – uczestnicy poznają zasadę least privilege (otwieraj tylko niezbędne porty), politykę Drop by Default oraz techniki audytu reguł firewalla. Wiedza ta jest niezbędna każdemu administratorowi systemów Linux odpowiedzialnemu za bezpieczeństwo sieci.

3/50
Agenda spotkania

Plan prezentacji

  • Architektura Netfilter – punkty zaczepienia w stosie sieciowym jądra
  • Firewall stateless vs stateful – rola systemu conntrack
  • Łańcuchy INPUT, FORWARD, OUTPUT i polityki domyślne
  • iptables vs nftables – składnia, wydajność, zastosowania
  • NAT: SNAT, DNAT, masquerading, port forwarding
  • Laboratorium krok po kroku – konfiguracja routera Linux
  • Rozwiązywanie problemów: tcpdump, logowanie, debugowanie reguł
  • Ściągawka i podsumowanie najważniejszych poleceń
Agenda

Prezentacja podzielona jest na osiem bloków tematycznych, które prowadzą uczestnika od podstaw architektury Netfilter, przez zaawansowane konfiguracje NAT, aż po praktyczne laboratorium i troubleshooting. Pierwsze dwadzieścia minut poświęcono na głęboką teorię, a pozostałe trzydzieści na intensywną demonstrację i warsztat praktyczny.

W bloku architektury Netfilter omówione zostaną punkty zaczepienia w stosie TCP/IP jądra Linux, na których opiera się cały system filtrowania pakietów. Zrozumienie tych mechanizmów jest kluczowe dla poprawnego projektowania reguł firewalla, szczególnie w kontekście routingu i NAT.

Blok praktyczny obejmuje konfigurację routera Linux od podstaw: włączenie ip_forward, ustawienie domyślnych polityk DROP, dodanie reguł ACCEPT dla niezbędnych usług, konfigurację masquerady oraz przekierowanie portów na wewnętrzny serwer.

4/50
Netfilter – framework filtrowania w jądrze Linux

Netfilter – wbudowany system filtrowania

Netfilter to framework wbudowany bezpośrednio w jądro Linux, umożliwiający przechwytywanie i modyfikację pakietów sieciowych.

  • Działa na poziomie jądra – maksymalna wydajność i minimalne opóźnienie
  • Punkty zaczepienia (hooks) w kluczowych miejscach stosu TCP/IP
  • Obsługa IPv4, IPv6, ARP, mostkowania (bridge)
  • Podstawa dla iptables, nftables, ebtables, ip6tables
  • Możliwość rozszerzania przez moduły jądra (conntrack, NAT, LOG)
  • API dla programów przestrzeni użytkownika przez gniazda netlink
Schemat Netfilter hooks

Netfilter to nie jest osobny program ani usługa – to zestaw funkcji i struktur danych wbudowanych bezpośrednio w jądro systemu Linux. Jego głównym zadaniem jest umożliwienie przechwytywania, inspekcji i modyfikacji pakietów sieciowych na różnych etapach ich przepływu przez stos TCP/IP.

Architektura Netfilter opiera się na pięciu głównych punktach zaczepienia (hooks): NF_IP_PRE_ROUTING, NF_IP_LOCAL_IN, NF_IP_FORWARD, NF_IP_LOCAL_OUT oraz NF_IP_POST_ROUTING. Każdy z nich przechwytuje pakiet na innym etapie jego podróży przez system.

Każdy z tych hooków może być powiązany z regułami filtrowania, które decydują o losie pakietu – ACCEPT, DROP, REJECT, QUEUE lub RETURN. Zrozumienie tych punktów zaczepienia jest absolutnie kluczowe dla poprawnej konfiguracji firewalla i NAT.

5/50
Punkty zaczepienia pakietów – przepływ przez stos

Pięć punktów zaczepienia Netfilter

  • PREROUTING: pakiet po wejściu, przed decyzją routingu (NAT, filtrowanie wstępne)
  • INPUT: pakiet przeznaczony dla lokalnego procesu (ochrona hosta)
  • FORWARD: pakiet tranzytowy – przechodzi przez router (ochrona sieci)
  • OUTPUT: pakiet wysyłany przez lokalny proces (kontrola wychodzących)
  • POSTROUTING: pakiet po decyzji routingu, przed wysłaniem (NAT wyjściowy)
Diagram przeplywu pakietu przez hooki

Kolejność przechodzenia pakietu przez punkty hook Netfilter zależy od tego, czy pakiet jest przeznaczony dla lokalnego procesu, czy jest tranzytowy. Dla pakietu przychodzącego do lokalnej usługi ścieżka wygląda następująco: PREROUTING → INPUT. Dla pakietu tranzytowego: PREROUTING → FORWARD → POSTROUTING.

Dla pakietu wychodzącego z lokalnego procesu ścieżka to: OUTPUT → POSTROUTING. Zrozumienie tych ścieżek jest kluczowe przy projektowaniu reguł firewalla – reguła umieszczona w niewłaściwym łańcuchu może nie zadziałać zgodnie z oczekiwaniami, przepuszczając ruch, który powinien być blokowany.

W kontekście NAT reguły DNAT muszą być umieszczone w łańcuchu PREROUTING tabeli nat, ponieważ decyzja routingu musi być podjęta na podstawie już zmodyfikowanego adresu. Reguły SNAT umieszcza się w łańcuchu POSTROUTING, po podjęciu decyzji routingu.

6/50
Firewall stateless a stateful – pamięć połączeń

Stateless vs Stateful Firewall

  • Stateless (bezstanowy): analizuje każdy pakiet niezależnie, bez pamięci poprzednich pakietów
  • Stateful (stanowy): śledzi stan połączeń, podejmuje decyzje na podstawie kontekstu
  • Netfilter z conntrack to firewall stateful – najlepsze rozwiązanie
  • Conntrack: moduł śledzący stan połączeń (TCP, UDP, ICMP, GRE)
  • Stany w conntrack: NEW, ESTABLISHED, RELATED, INVALID
  • Reguła: ACCEPT dla ESTABLISHED,RELATED; selektywnie dla NEW
Porównanie firewall stateless vs stateful

Firewall bezstanowy (stateless) przetwarza każdy pakiet w izolacji, nie posiadając informacji o poprzednich pakietach należących do tego samego połączenia. Oznacza to, że aby przepuścić ruch, należy dodać reguły zarówno dla pakietów wychodzących, jak i przychodzących, co znacznie komplikuje konfigurację.

Firewall stanowy (stateful) prowadzi tablicę aktywnych połączeń (connection tracking), co pozwala na podejmowanie decyzji w kontekście całej sesji komunikacyjnej. Dzięki temu wystarczy dodać regułę ACCEPT dla ruchu NEW dla inicjowanego połączenia, a pakiety powrotne (ESTABLISHED) i pakiety połączeń pochodnych (RELATED) są automatycznie przepuszczane.

Moduł conntrack w Netfilter śledzi nie tylko połączenia TCP, ale także sesje UDP (pseudopołączenia) i komunikaty ICMP. Stany NEW, ESTABLISHED, RELATED i INVALID pozwalają na precyzyjne i bezpieczne budowanie reguł firewalla.

7/50
Łańcuchy INPUT, FORWARD, OUTPUT – role i zastosowania

Trzy główne łańcuchy filtrowania

  • INPUT: kontrola pakietów przychodzących do lokalnego procesu (ochrona serwera)
  • FORWARD: kontrola pakietów tranzytowych przez router (ochrona sieci LAN)
  • OUTPUT: kontrola pakietów wychodzących z lokalnego procesu (kontrola wycieku danych)
  • Każdy łańcuch może mieć własną politykę domyślną (ACCEPT/DROP)
  • Reguły przetwarzane są po kolei – pierwsze dopasowanie decyduje
  • Możliwość tworzenia własnych łańcuchów użytkownika (user-defined chains)
Trzy główne łańcuchy filtrowania

Łańcuch INPUT obsługuje pakiety przychodzące, które są adresowane do lokalnego procesu – na przykład połączenie SSH do serwera, zapytanie DNS do lokalnego resolvera, czy żądanie HTTP do serwera WWW. To podstawowy łańcuch do ochrony samego hosta przed nieautoryzowanym dostępem z zewnątrz.

Łańcuch FORWARD jest kluczowy dla routerów Linux – obsługuje pakiety, które nie są adresowane do lokalnego procesu, ale mają być przekazane do innego interfejsu sieciowego. Bez odpowiednich reguł w FORWARD ruch tranzytowy nie będzie przepuszczany, nawet jeśli ip_forward jest włączone.

Łańcuch OUTPUT kontroluje pakiety inicjowane przez lokalne procesy – na przykład żądania HTTP z przeglądarki na serwerze, zapytania DNS z resolvera, czy połączenia SSH wychodzące. Jest często używany do blokowania ruchu wychodzącego z zainfekowanych procesów lub do ograniczania dostępu do określonych zasobów zewnętrznych.

8/50
Polityka domyślna – ACCEPT czy DROP?

Polityka domyślna łańcucha

  • ACCEPT: domyślnie przepuszczaj wszystko, blokuj selektywnie – podejście liberalne
  • DROP: domyślnie blokuj wszystko, otwieraj selektywnie – podejście bezpieczne
  • Zalecenie branżowe: DROP jako polityka domyślna dla wszystkich łańcuchów
  • DROP vs REJECT: DROP cicho odrzuca pakiet, REJECT odsyła ICMP odmowy
  • DROP jest bezpieczniejszy – nie informuje atakującego o istnieniu hosta
  • Politykę domyślną zmienia się komendą: iptables -P INPUT DROP
Porównanie polityk ACCEPT vs DROP

Wybór polityki domyślnej (default policy) dla każdego z trzech głównych łańcuchów ma fundamentalne znaczenie dla bezpieczeństwa całego systemu. Polityka ACCEPT oznacza, że jeśli żadna reguła nie dopasuje pakietu, zostanie on przepuszczony – to podejście jest wygodne, ale niebezpieczne.

Polityka DROP implementuje zasadę domyślnej odmowy (default deny) – tylko jawnie dozwolony ruch jest przepuszczany. Jest to zgodne z najlepszymi praktykami bezpieczeństwa (CIS Benchmarks, NSA Guidelines). Odwrotną stroną medalu jest większe ryzyko przypadkowego zablokowania działającej usługi.

W praktyce produkcyjnej stosuje się najczęściej politykę DROP dla INPUT i FORWARD, oraz ACCEPT dla OUTPUT. Dla ruchu lokalnego (localhost) często dodaje się osobną regułę ACCEPT na początku, aby nie blokować komunikacji międzyprocesowej na porcie loopback.

9/50
Wdrażanie polityki Drop by Default

Kroki do bezpiecznej konfiguracji

# Ustawienie domyślnej polityki DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Zezwolenie na ruch lokalny (loopback)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Zezwolenie na ustanowione i powiązane połączenia
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Konfiguracja Drop by Default

Wdrożenie polityki Drop by Default wymaga systematycznego podejścia. Zanim ustawi się domyślną politykę na DROP, należy upewnić się, że istnieją reguły zezwalające na niezbędną komunikację – w przeciwnym razie można stracić dostęp do serwera, szczególnie w przypadku zdalnego połączenia SSH.

Pierwszym krokiem jest dodanie reguł dla interfejsu loopback (lo) – komunikacja między procesami na tym samym hoście odbywa się przez ten interfejs. Bez reguł ACCEPT dla lo wiele podstawowych usług systemowych przestanie działać poprawnie.

Drugim kluczowym krokiem jest dodanie reguły przepuszczającej pakiety w stanach ESTABLISHED i RELATED. Dzięki tej regule, jeśli lokalny proces zainicjuje połączenie wychodzące, pakiety powrotne będą automatycznie przepuszczane mimo domyślnej polityki DROP dla INPUT.

10/50
Śledzenie połączeń – conntrack w praktyce

Narzędzia do monitorowania conntrack

  • conntrack -L: wyświetla tablicę aktualnie śledzonych połączeń
  • conntrack -E: nasłuchuje zdarzeń (nowe połączenia, zamykanie)
  • conntrack -D: usuwa wybrane połączenia z tablicy
  • cat /proc/net/nf_conntrack: bezpośredni podgląd tablicy
  • sysctl net.netfilter.nf_conntrack_max: maksymalna liczba śledzonych połączeń
  • Domyślnie: 65536 połączeń dla 64-bitowych systemów
Wynik conntrack -L

Connection tracking to mechanizm, który umożliwia firewollowi stanowemu (stateful) śledzenie wszystkich połączeń przechodzących przez system. Każde połączenie jest identyfikowane przez krotkę: adres źródłowy, adres docelowy, port źródłowy, port docelowy i protokół.

Narzędzie conntrack (część pakietu conntrack-tools) pozwala na zaawansowane monitorowanie i zarządzanie tablicą połączeń. Polecenie conntrack -L pokazuje wszystkie aktywne wpisy, a conntrack -E umożliwia nasłuchiwanie zdarzeń w czasie rzeczywistym.

W środowiskach z dużą liczbą jednoczesnych połączeń należy monitorować rozmiar tablicy conntrack, aby nie osiągnąć limitu nf_conntrack_max. Przekroczenie limitu powoduje odrzucanie nowych połączeń, co objawia się błędami timeout dla klientów.

11/50
Stany połączeń – NEW, ESTABLISHED, RELATED, INVALID

Cztery stany conntrack

  • NEW: pierwszy pakiet nowego połączenia (SYN w TCP, pierwszy pakiet UDP)
  • ESTABLISHED: połączenie z dwukierunkowym ruchem – pakiety powrotne widziane
  • RELATED: połączenie powiązane z istniejącym (kanał danych FTP, ICMP Error)
  • INVALID: pakiet niepasujący do żadnego połączenia – atak lub błąd
  • Dla TCP conntrack dodatkowo śledzi stany TCP (SYN_SENT, SYN_RECV, ESTABLISHED)
  • Reguła: INVALID zawsze DROP – to pakiety niespójne lub uszkodzone
Diagram stanów conntrack

Stan NEW oznacza pierwszy pakiet nowego połączenia, który nie jest powiązany z żadnym istniejącym wpisem w tablicy conntrack. Dla TCP będzie to pakiet z flagą SYN, dla UDP pierwszy pakiet w danym kierunku, a dla ICMP pierwsze echo-request. Reguły ACCEPT dla NEW powinny być bardzo selektywne.

Stan ESTABLISHED oznacza, że conntrack widział już ruch w obu kierunkach. Dla TCP oznacza to, że trójstronne uzgodnienie (SYN, SYN-ACK, ACK) zostało zakończone. Dla UDP wystarczy, że pakiet powrotny został zarejestrowany. To najważniejszy stan dla reguł firewalla – powinien być zawsze akceptowany.

Stan RELATED pojawia się, gdy conntrack rozpoznaje nowe połączenie powiązane z istniejącym. Klasycznym przykładem jest protokół FTP w trybie aktywnym, gdzie połączenie kontrolne (port 21) inicjuje połączenie danych (port 20). Moduł nf_conntrack_ftp śledzi te zależności.

12/50
Odrzucanie pakietów INVALID – pierwsza linia obrony

Pakiet INVALID – natychmiastowe odrzucenie

# Reguła odrzucająca niepoprawne pakiety
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

# Przykłady INVALID:
# - TCP SYN na istniejącym połączeniu
# - Pakiet z błędną sumą kontrolną
# - TCP z flagami SYN i FIN jednocześnie
# - ICMP echo-reply bez wcześniejszego request
# - Fragmenty IP z błędnym przesunięciem
Ilustracja pakietów INVALID

Pakiety oznaczone jako INVALID przez system conntrack to poważny sygnał ostrzegawczy – mogą świadczyć o ataku (nmap, OS fingerprinting, TCP injection), błędzie konfiguracji lub problemie z fragmentacją pakietów IP. W każdym przypadku taki pakiet powinien być natychmiast odrzucony przez DROP.

Przykłady pakietów INVALID: pakiety TCP z flagą SYN dla istniejącego połączenia (próba desynchronizacji), pakiety z błędną sumą kontrolną, pakiety TCP z kombinacją SYN+FIN (używane w skanowaniu), oraz pakiety ICMP niepasujące do żadnego oczekiwanego połączenia.

Umieszczenie reguły INVALID na początku łańcucha INPUT i FORWARD jest najlepszą praktyką bezpieczeństwa. Zapewnia to odrzucenie niepoprawnych pakietów jeszcze przed próbą dopasowania do innych reguł, co zmniejsza obciążenie CPU i zabezpiecza przed atakami.

13/50
iptables – klasyczne narzędzie filtrowania

iptables – standard od lat 90.

  • Część pakietu netfilter – domyślnie dostępny w większości dystrybucji Linux
  • Organizacja reguł w tabele (filter, nat, mangle, raw, security)
  • Każda tabela zawiera łańcuchy (chains) z regułami
  • Składnia: iptables -t tabela -A łańcuch -m moduł -j cel
  • Osobne narzędzia dla IPv4 (iptables), IPv6 (ip6tables), ARP (arptables)
  • Wciąż najpopularniejsze narzędzie w istniejących instalacjach
Podział na tabele i łańcuchy

iptables to narzędzie przestrzeni użytkownika, które komunikuje się z frameworkiem Netfilter w jądrze przez gniazda netlink. Mimo że jest stopniowo wypierane przez nftables, wciąż pozostaje najczęściej spotykanym narzędziem do konfiguracji firewalla w systemach Linux.

Architektura iptables opiera się na tabelach grupujących reguły według przeznaczenia. Tabela filter służy do filtrowania, nat do translacji adresów, mangle do modyfikacji nagłówków, raw do pomijania conntrack, a security do reguł SELinux.

Każda tabela ma predefiniowane łańcuchy powiązane z punktami hook Netfilter. Tabela filter ma łańcuchy INPUT, FORWARD i OUTPUT, tabela nat ma PREROUTING, POSTROUTING i OUTPUT, a tabela mangle zawiera wszystkie pięć łańcuchów.

14/50
Składnia iptables – opcje i parametry

Budowa reguły iptables

# Ogólna składnia:
iptables -t tabela -A łańcuch -m moduł -j cel

# Przykład: SSH z sieci 192.168.1.0/24
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Najważniejsze opcje:
-A (append) – dodaj regułę na koniec łańcucha
-I (insert) – wstaw regułę na początek łańcucha
-D (delete) – usuń regułę
-L (list) – wyświetl reguły
-F (flush) – wyczyść wszystkie reguły
-P (policy) – ustaw politykę domyślną
Składnia reguły iptables

Składnia iptables oferuje wiele opcji dopasowania pakietów. Podstawowe kryteria to źródłowy adres IP (-s), docelowy adres IP (-d), protokół (-p tcp/udp/icmp), interfejs wejściowy (-i) i wyjściowy (-o). Dla TCP i UDP dodatkowo port źródłowy (--sport) i docelowy (--dport).

Moduły dopasowania (match modules) rozszerzają możliwości: conntrack (--ctstate) filtruje po stanie połączenia, limit ogranicza liczbę pakietów, recent śledzi częstotliwość połączeń z IP, a multiport umożliwia podanie wielu portów jednocześnie.

Cel (target) określa co zrobić z pakietem: ACCEPT, DROP, REJECT, LOG, MASQUERADE, SNAT, DNAT. Możliwe jest również przekazanie pakietu do własnego łańcucha użytkownika.

15/50
nftables – następca iptables

nftables – nowa generacja firewalla

  • Następca iptables – zaprojektowany od podstaw, bez kompatybilności wstecznej
  • Jednolita składnia dla IPv4 i IPv6 – brak osobnych narzędzi
  • Wydajniejszy – mniejszy narzut na przetwarzanie reguł
  • Reguły w plikach konfiguracyjnych, nie polecenia CLI do zapisywania
  • Wbudowane wsparcie dla zestawów (sets), słowników (maps), limitów
  • Domyślny firewall w Debian ≥10, RHEL ≥8, Ubuntu ≥20.04
Porównanie iptables vs nftables

nftables został wprowadzony w jądrze Linux 3.13 (2014) jako następca całego stosu iptables/ip6tables/arptables/ebtables. Główną motywacją było uproszczenie architektury – zamiast czterech odrębnych narzędzi z różną składnią, nftables oferuje jednolitą platformę.

W przeciwieństwie do iptables, gdzie każda reguła dodawana jest osobno, nftables operuje na plikach reguł (ruleset) ładowanych atomowo do jądra. Eliminuje to problem czasowego otwarcia dostępu przy błędnej kolejności reguł.

nftables wprowadza zestawy (sets) i słowniki (maps), które upraszczają zarządzanie dużymi zbiorami reguł. Zamiast dziesięciu reguł dla dziesięciu adresów IP, definiuje się zestaw i odwołuje w jednej regule, co poprawia czytelność i wydajność.

16/50
Składnia nftables – reguły i rodziny

Składnia nftables

# Rodziny adresów w nftables:
nft add table inet filter   # inet = IPv4 + IPv6
nft add table ip filter      # ip = tylko IPv4

# Definiowanie łańcucha i reguł:
nft add chain inet filter input { type filter hook input priority 0; }
nft add rule inet filter input tcp dport 22 accept

# Drop by Default w nftables
nft add rule inet filter input ct state invalid drop
nft add rule inet filter input iif lo accept
nft add rule inet filter input ct state established,related accept
Składnia nftables

Rodzina adresów w nftables określa dla jakiego protokołu obowiązują reguły. Rodzina inet łączy IPv4 i IPv6, co eliminuje potrzebę duplikowania. Rodzina ip dotyczy tylko IPv4, ip6 tylko IPv6, bridge – ruchu mostkowanego, a arp – protokołu ARP.

Definicja łańcucha wymaga podania typu (filter, nat, route), punktu hook (input, forward, output, prerouting, postrouting) oraz priorytetu określającego kolejność przetwarzania. Niższa wartość priorytetu oznacza wcześniejsze przetwarzanie.

W przeciwieństwie do iptables, gdzie tabele i łańcuchy są predefiniowane, w nftables wszystko tworzy się jawnie. Polecenie nft list ruleset wyświetla całą konfigurację w formacie do ponownego załadowania.

17/50
iptables vs nftables – wybór narzędzia

Porównanie iptables i nftables

Cechaiptablesnftables
SkładniaOsobne dla IPv4/IPv6Jednolita (inet)
WydajnośćStarsza, większy narzutZoptymalizowana
AtomowośćReguły dodawane pojedynczoRuleset ładowany atomowo
Zestawy/MapsWymaga ipsetWbudowane (sets, maps)
Debugowanieiptables -v -L, tracenft monitor trace
Backward compatStandard od lat 90.iptables-translate
Tabela porównawcza

Dla nowych wdrożeń nftables jest zdecydowanie zalecany – oferuje lepszą wydajność, prostszą składnię, atomowe ładowanie reguł i wbudowane struktury danych. Nowe dystrybucje Linux domyślnie używają nftables.

Jednak iptables wciąż ma swoje miejsce – ogromna istniejąca baza zainstalowanych systemów, skrypty automatyzacji (Ansible, Puppet) często używają iptables. Ponadto niektóre starsze moduły Netfilter nie mają jeszcze odpowiedników w nftables.

Narzędzie iptables-translate pomaga w migracji, tłumacząc reguły iptables na składnię nftables. Polecenie iptables-translate -A INPUT -s 10.0.0.0/8 -j DROP pokaże odpowiednik w nftables.

18/50
Selektywne otwieranie reguł ACCEPT

Precyzyjne reguły ACCEPT

# SSH tylko z sieci administracyjnej
iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# HTTP/HTTPS dla wszystkich
iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT

# Ping tylko z sieci lokalnej
iptables -A INPUT -s 192.168.1.0/24 -p icmp --icmp-type echo-request -j ACCEPT

# DNS tylko dla zapytań do serwera
iptables -A INPUT -p udp --dport 53 -j ACCEPT
Schemat otwierania portów

Selektywne otwieranie reguł ACCEPT to realizacja zasady najmniejszych uprawnień (least privilege). Zamiast otwierać szeroki zakres portów dla wszystkich adresów, precyzyjnie określa się kto, co i w jaki sposób może uzyskać dostęp do danej usługi.

Reguły ACCEPT powinny być możliwie najbardziej restrykcyjne. Dostęp do SSH powinien być ograniczony do konkretnej sieci administracyjnej, a panel administracyjny (port 8443) tylko z wewnętrznej sieci zarządzania.

Kolejność reguł ma znaczenie – reguły bardziej szczegółowe przed ogólnymi. Reguła zezwalająca na SSH z sieci biurowej powinna być przed ewentualną regułą blokującą cały ruch SSH.

19/50
Zasada najmniejszych uprawnień

Zasada najmniejszych uprawnień

  • Otwieraj tylko niezbędne porty i protokoły dla konkretnych usług
  • Ograniczaj źródłowe adresy IP do minimum (podsieci administracyjne)
  • Używaj reguł opartych na stanie (ESTABLISHED,RELATED) dla ruchu zwrotnego
  • Blokuj cały ruch domyślnie, dodawaj tylko jawne reguły
  • Regularnie audytuj reguły – usuwaj nieużywane otwarcia
  • Stosuj osobne reguły dla różnych stref sieciowych (DMZ, LAN, Management)
Zasada najmniejszych uprawnień

Zasada najmniejszych uprawnień (least privilege) w kontekście firewalla oznacza, że każda reguła powinna przyznawać tylko minimalny zakres dostępu niezbędny do działania danej usługi. Nie chodzi tylko o port – ale także o źródło, cel, protokół, interfejs i stan połączenia.

Wielu administratorów popełnia błąd, dodając zbyt ogólne reguły dla wygody, na przykład otwierając cały zakres portów 1024-65535 zamiast polegać na conntrack. Innym częstym błędem jest używanie protokołu TCP zamiast konkretnych portów.

Regularny audyt reguł firewalla jest kluczowy. Należy przynajmniej raz na kwartał przeglądać listę reguł i identyfikować nieużywane. Polecenie iptables -L -n -v z licznikami pakietów pokazuje, które reguły są faktycznie używane.

20/50
Trwałość reguł – zapis i przywracanie

Zapis i przywracanie reguł

# Zapis reguł iptables do pliku
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

# Przywrócenie reguł z pliku
iptables-restore < /etc/iptables/rules.v4

# Automatyczne ładowanie (Debian/Ubuntu)
apt install iptables-persistent

# nftables – zapis całego ruleset
nft list ruleset > /etc/nftables.conf
nft -f /etc/nftables.conf
Zapis reguł

Jednym z najczęstszych błędów jest dodanie reguł bez ich zapisania – po restarcie wszystkie znikają. Reguły iptables są przechowywane wyłącznie w pamięci jądra i nie są automatycznie zapisywane na dysk. Konieczne jest jawne wykonanie iptables-save.

W Debianie/Ubuntu pakiet iptables-persistent automatycznie ładuje reguły z /etc/iptables/rules.v4 przy starcie. W RHEL/CentOS reguły zapisuje się poleceniem service iptables save.

Dla nftables proces jest prostszy – ruleset zapisuje się do pliku przez nft list ruleset, a ładuje poleceniem nft -f. Usługa systemd nftables.service automatycznie ładuje reguły przy starcie systemu.

21/50
NAT – Network Address Translation w IPv4

NAT – konieczność w świecie IPv4

  • NAT – translacja adresów prywatnych (RFC 1918) na publiczne i odwrotnie
  • Rozwiązuje problem wyczerpania adresów IPv4
  • Adresy prywatne: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • Działa na poziomie pakietów – modyfikuje nagłówki IP i TCP/UDP
  • Wymaga włączenia ip_forward (forwarding między interfejsami)
  • Wady NAT: łamie zasadę end-to-end, problemy z FTP, SIP, IPSec
Schemat NAT

Network Address Translation (NAT) pozwala wielu urządzeniom w sieci prywatnej współdzielić jeden lub kilka publicznych adresów IP. W dobie wyczerpywania się puli adresów IPv4 NAT stał się niezbędnym elementem infrastruktury sieciowej.

Adresy prywatne z RFC 1918 nie są routowane w publicznym Internecie, dlatego pakiety wychodzące muszą mieć zmieniony źródłowy adres IP na publiczny adres interfejsu zewnętrznego. Pakiety powrotne muszą mieć zmieniony adres docelowy z publicznego na prywatny.

NAT w Linux jest realizowany przez conntrack i tabele nat Netfilter. Tabela nat ma trzy łańcuchy: PREROUTING (DNAT), POSTROUTING (SNAT/MASQUERADE) i OUTPUT (DNAT dla pakietów lokalnych).

22/50
Mechanizm NAT – translacja adresów i portów

Jak działa NAT?

  • SNAT: zmienia źródłowy adres IP na publiczny adres routera
  • DNAT: zmienia docelowy adres IP na adres wewnętrznego serwera
  • Conntrack zapamiętuje pierwotne i zmienione adresy w tablicy translacji
  • Pakiety powrotne są automatycznie odwracane przez conntrack
  • PAT (Port Address Translation): translacja portów – wiele hostów na jednym IP
  • NAT wymaga routingu – pakiety muszą przechodzić przez system (ip_forward)
Diagram NAT

Mechanizm NAT opiera się na tablicy translacji prowadzonej przez conntrack. Gdy pakiet z sieci prywatnej (192.168.1.10:34567) wychodzi na zewnątrz, router zmienia jego źródłowy adres IP na swój publiczny (203.0.113.5) i często port źródłowy.

Gdy pakiet powrotny przychodzi na adres 203.0.113.5:54321, conntrack odwraca translację – zmienia docelowy adres IP i port z powrotem na 192.168.1.10:34567. Dla hosta wewnętrznego cały proces jest przezroczysty.

PAT pozwala wielu hostom współdzielić jeden publiczny adres IP. Conntrack używa portów TCP/UDP do rozróżniania połączeń, umożliwiając tysiące jednoczesnych połączeń przez jeden adres IP.

23/50
SNAT – zmiana źródłowego adresu pakietu

SNAT (Source Network Address Translation)

# SNAT – stałe mapowanie na konkretny adres IP
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5

# SNAT z zakresem adresów (round-robin)
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5-203.0.113.10

# SNAT tylko dla konkretnych portów docelowych
iptables -t nat -A POSTROUTING -p tcp --dport 80 -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5
Schemat SNAT

SNAT zmienia źródłowy adres IP pakietu. Stosuje się go dla ruchu wychodzącego z sieci lokalnej do Internetu – adresy prywatne muszą być przetłumaczone na publiczny adres routera, aby pakiety były routowane w Internecie.

Reguły SNAT umieszcza się w łańcuchu POSTROUTING tabeli nat, po zakończeniu routingu. Opcja --to-source określa docelowy adres źródłowy. SNAT wymaga podania konkretnego adresu IP interfejsu zewnętrznego.

SNAT można skonfigurować z pulą adresów (--to-source IP1-IP2), co rozkłada ruch na wiele adresów publicznych. Jest to popularne w data center, gdzie klient ma przydzieloną pulę adresów IP.

24/50
Masquerading – SNAT z automatycznym adresem

MASQUERADE – dynamiczny SNAT

# Masquerading – używa adresu interfejsu wyjściowego
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# nftables – odpowiednik masquerady
nft add rule nat postrouting ip saddr 192.168.1.0/24 oif eth0 masquerade

# Sprawdzenie działania
iptables -t nat -L -n -v

# Zastosowanie: interfejsy z dynamicznym IP (PPPoE, DHCP)
Porównanie SNAT vs MASQUERADE

Masquerading to forma SNAT, w której adres źródłowy pobierany jest automatycznie z interfejsu wyjściowego. Główną zaletą jest działanie przy dynamicznie zmieniającym się adresie IP – na przykład PPPoE (DSL) lub DHCP.

W przypadku SNAT statycznego, zmiana adresu IP interfejsu zewnętrznego powoduje niedziałanie reguły. Masquerade automatycznie wykrywa bieżący adres i używa go do translacji.

Kosztem jest nieco większe obciążenie – każdy pakiet wymaga sprawdzenia bieżącego adresu interfejsu. Dla typowego routera domowego różnica jest pomijalna.

25/50
SNAT vs MASQUERADE – wybór metody

Kiedy użyć SNAT, a kiedy MASQUERADE?

SytuacjaZalecaneUzasadnienie
Statyczny adres IP na WANSNATWiększa wydajność
Dynamiczny adres IP (PPPoE, DHCP)MASQUERADEAutomatyczna adaptacja
Pula adresów publicznychSNAT z zakresemRozłożenie ruchu
Router zapasowy (failover)MASQUERADEAdres zmienia się
Wysoka wydajność (100k+ sesji)SNATMniejszy narzut
Tabela decyzyjna

Wybór między SNAT a MASQUERADE zależy od charakteru połączenia zewnętrznego. Dla statycznego adresu IP (serwery dedykowane, łącza biznesowe) zaleca się SNAT z jawnym adresem źródłowym dla lepszej wydajności.

Dla dynamicznego adresu IP (łącza domowe, DSL, LTE/5G) masquerade jest jedynym sensownym wyborem. Użycie SNAT z adresem, który może ulec zmianie, doprowadzi do przerwania ruchu po zmianie adresu.

W środowiskach z pulą publicznych adresów IP (np. /28 od dostawcy) stosuje się SNAT z zakresem, co automatycznie rozkłada połączenia na dostępne adresy publiczne.

26/50
Praktyczny przykład – SNAT dla sieci lokalnej

Konfiguracja SNAT krok po kroku

Założenia: LAN 192.168.1.0/24, WAN eth0 z adresem 203.0.113.5

# Krok 1: Włączenie routingu IP
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

# Krok 2: Polityka DROP dla FORWARD
iptables -P FORWARD DROP

# Krok 3: Zezwolenie na ESTABLISHED,RELATED
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Krok 4: SNAT dla ruchu LAN do Internetu
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5
Schemat sieci z SNAT

Pierwszym krokiem jest włączenie forwardingu (ip_forward), domyślnie wyłączonego ze względów bezpieczeństwa. Bez tego pakiety nie będą przekazywane między interfejsami.

Następnie konfiguruje się reguły FORWARD. Nawet przy poprawnym NAT, pakiety tranzytowe muszą być jawnie dozwolone. Najpierw dodaje się reguły dla ESTABLISHED i RELATED, potem dla ruchu NEW z sieci lokalnej.

Na końcu reguła SNAT w POSTROUTING. Określa, że ruch z 192.168.1.0/24 przez eth0 ma mieć adres źródłowy 203.0.113.5.

27/50
Masquerading dla PPPoE/DHCP

Masquerade dla dynamicznego adresu WAN

# LAN 10.0.0.0/24, WAN = ppp0 (PPPoE)
sysctl -w net.ipv4.ip_forward=1
iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o ppp0 -j MASQUERADE

Adres ppp0 zmienia się – MASQUERADE automatycznie go śledzi.

MASQUERADE na PPPoE

Masquerading na interfejsie PPPoE jest typowe dla routerów domowych. Połączenie DSL tworzy interfejs ppp0 z adresem IP przydzielanym przez dostawcę, zmieniającym się przy każdej sesji.

Reguła MASQUERADE przypisana do ppp0 automatycznie wykrywa publiczny adres. Po przerwaniu i ponownym nawiązaniu połączenia z innym adresem, masquerade dostosowuje się bez modyfikacji reguł.

Reguły FORWARD są restrykcyjne – tylko ruch z źródłowej sieci 10.0.0.0/24 inicjuje nowe połączenia. Ruch z Internetu do LAN jest domyślnie blokowany.

28/50
Interakcja NAT ze śledzeniem połączeń

Jak NAT korzysta z conntrack?

  • Conntrack rejestruje pierwotne i przetłumaczone adresy dla każdego połączenia
  • Dla SNAT: zapamiętuje (src_orig, dst) → (src_nat, dst) i odwrotność
  • Dla DNAT: zapamiętuje (src, dst_orig) → (src, dst_nat) i odwrotność
  • Dzięki conntrack pakiety powrotne są automatycznie odwracane
  • Bez conntrack NAT wymagałby symetrycznych reguł – bardzo skomplikowane
  • Czas życia wpisu: TCP ~5 dni, UDP ~30s, ICMP ~30s
Wpis conntrack z NAT

Connection tracking i NAT są ściśle powiązane. Gdy pakiet podlega translacji, conntrack zapisuje oryginalną i przetłumaczoną parę adresów, umożliwiając automatyczne odwrócenie translacji przy pakietach powrotnych.

Dla SNAT, wpis zawiera oryginalny adres źródłowy (192.168.1.10) i przetłumaczony (203.0.113.5). Przy pakiecie powrotnym conntrack odwraca translację – zmienia adres docelowy na 192.168.1.10.

Czas życia wpisu NAT zależy od protokołu: TCP pozostaje 5 dni po zakończeniu połączenia, UDP około 30 sekund, ICMP około 30 sekund. W środowiskach z dużym ruchem warto monitorować rozmiar tablicy conntrack.

29/50
Ograniczenia NAT – problematyczne protokoły

Protokoły problematyczne dla NAT

  • FTP (Active Mode): adres IP w payload – wymaga nf_conntrack_ftp
  • SIP/VoIP: adresy IP w nagłówkach SDP – wymaga nf_conntrack_sip
  • IPSec (AH/ESP): NAT modyfikuje nagłówek – problem z integralnością
  • ICMP: tylko niektóre typy translowane
  • PPTP/GRE: wymaga modułu nf_conntrack_pptp
  • DCCP/SCTP: ograniczona obsługa w conntrack
Problemy NAT

NAT modyfikuje nagłówki IP i transportowe, ale nie dane aplikacji. Niektóre protokoły przesyłają adresy IP w payload (FTP w komendzie PORT), co wymaga dodatkowych modułów conntrack do poprawnej translacji.

Dla FTP w trybie aktywnym serwer wysyła klientowi adres IP w payload. Moduł nf_conntrack_ftp analizuje payload i modyfikuje wpisy NAT. Podobnie dla SIP (nf_conntrack_sip) i PPTP (nf_conntrack_pptp).

Rozwiązaniem jest załadowanie odpowiednich modułów conntrack lub zastosowanie ALG (Application Layer Gateway) analizujących i modyfikujących payload pakietów.

30/50
NAT a IPv6 – czy NAT jest potrzebny?

NAT w IPv6 – miejsce i czas

  • IPv6 ma wystarczającą pulę adresów – każdy host może mieć globalny adres
  • W czystym IPv6 NAT nie jest potrzebny – łączność end-to-end
  • NAT66 istnieje, ale jest rzadko stosowany
  • IPv6 używa NPTv6 (Network Prefix Translation) – zmiana prefiksu
  • NPTv6 jest bezstanowy – nie wymaga conntrack
  • Firewall w IPv6 nadal jest konieczny
IPv6 vs NAT

IPv6 został zaprojektowany z założeniem, że każdy host ma globalnie routowalny adres. Teoretycznie NAT nie jest potrzebny, przywracając zasadę end-to-end utraconą w erze NAT IPv4.

W praktyce NAT w IPv6 bywa stosowany, gdy dostawca przydziela tylko prefiks /64 (zamiast /56), wymuszając NPTv6 do dalszej segmentacji. Przejście z IPv4 wymaga też NAT64/DNS64 do translacji między protokołami.

NPTv6 zmienia tylko prefiks, pozostawiając identyfikator interfejsu. Jest bezstanowy, co eliminuje problemy z FTP czy SIP. Mimo braku NAT, IPv6 wymaga firewalla, ponieważ każdy host jest bezpośrednio dostępny z Internetu.

31/50
DNAT – Destination NAT

DNAT – zmiana docelowego adresu pakietu

  • Zmienia docelowy adres IP pakietu przychodzącego
  • Udostępnianie usług z sieci lokalnej na zewnątrz
  • Reguły DNAT w łańcuchu PREROUTING tabeli nat
  • Po DNAT decyzja routingu dla nowego adresu docelowego
  • Wymaga reguł FORWARD do wewnętrznego serwera
  • Wymaga włączenia ip_forward
Schemat DNAT

DNAT zmienia docelowy adres IP pakietu przychodzącego. Główne zastosowanie to udostępnianie usług z sieci prywatnej do Internetu. Bez DNAT serwer 192.168.1.10 nie byłby dostępny z zewnątrz.

Reguły DNAT w PREROUTING są przetwarzane przed decyzją routingu. DNAT zmienia adres, a routing podejmuje decyzję na podstawie zmodyfikowanego adresu, kierując pakiet do odpowiedniego interfejsu.

Po DNAT pakiet trafia do FORWARD. Należy dodać reguły FORWARD zezwalające na ruch do wewnętrznego serwera – bez tego pakiet zostanie odrzucony przez domyślną politykę DROP.

32/50
Przekierowanie portów

Przekierowanie portów

# Przekierowanie portu 80 na serwer WWW 192.168.1.10:80
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# Przekierowanie portu 443 na serwer WWW
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.1.10:443

# Przekierowanie portu 3030 na SSH (port 22)
iptables -t nat -A PREROUTING -p tcp --dport 3030 -j DNAT --to-destination 192.168.1.20:22

# nftables – port forwarding
nft add rule nat prerouting tcp dport 80 dnat to 192.168.1.10:80
Schemat port forwardingu

Przekierowanie portów kieruje pakiety z określonego portu zewnętrznego adresu IP routera na adres IP i port wewnętrznego serwera. To podstawowa technika udostępniania usług z sieci prywatnej.

Ruch na port 80 routera jest przekierowywany na 192.168.1.10:80. Dla klienta z Internetu wygląda to jak serwer działający na routerze.

Mapowanie portu 3030 na 22 pozwala udostępnić SSH na niestandardowym porcie, omijając skanowanie botów na porcie 22.

33/50
DNAT wymaga reguł FORWARD

Kompletna konfiguracja DNAT

# Krok 1: Włączenie routingu
sysctl -w net.ipv4.ip_forward=1

# Krok 2: Polityka DROP dla FORWARD
iptables -P FORWARD DROP

# Krok 3: ESTABLISHED,RELATED
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Krok 4: DNAT – port 80 na serwer
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# Krok 5: FORWARD dla ruchu do serwera
iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT
DNAT + FORWARD

Błędem jest dodanie tylko DNAT bez reguł FORWARD. DNAT zmienia adres, ale pakiet nadal przechodzi przez FORWARD. Przy domyślnej polityce DROP pakiet zostanie odrzucony.

Reguła FORWARD powinna być precyzyjna: protokół, docelowy IP serwera, port i stan NEW. Tylko ruch dla konkretnej usługi jest przepuszczany.

Reguła dla ESTABLISHED,RELATED jest niezbędna dla ruchu powrotnego. Bez niej odpowiedź serwera zostanie zablokowana.

34/50
Przekierowanie portów – wiele serwerów

Wiele usług na różnych serwerach

# Serwer WWW na 192.168.1.10
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT

# Serwer poczty na 192.168.1.20 (SMTP, IMAP)
iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.1.20:25
iptables -t nat -A PREROUTING -p tcp --dport 143 -j DNAT --to-destination 192.168.1.20:143
iptables -A FORWARD -p tcp -d 192.168.1.20 -m multiport --dports 25,143 -m conntrack --ctstate NEW -j ACCEPT

# Baza danych tylko dla VPN
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.30:3306
Wiele serwerów

W środowiskach produkcyjnych często udostępnia się wiele usług na różnych serwerach. Każda wymaga osobnej reguły DNAT w PREROUTING i odpowiadającej reguły FORWARD.

Moduł multiport pozwala połączyć wiele portów w jednej regule FORWARD, co upraszcza konfigurację i jest bardziej czytelne.

DNAT można ograniczyć źródłowym adresem IP (-s 192.168.2.0/24), co zwiększa bezpieczeństwo – usługa dostępna tylko z sieci VPN.

35/50
DNAT a adres źródłowy klienta

Problem: serwer widzi adres routera, nie klienta

  • DNAT zmienia tylko adres docelowy – źródłowy pozostaje IP klienta
  • Problem: odpowiedź serwera może ominąć router, klient odrzuca pakiet
  • Rozwiązanie: SNAT dla ruchu DNAT (NAT reflection)
  • Alternatywa: X-Forwarded-For dla HTTP
  • Dla SSH: ProxyProtocol lub TCP wrappers
  • TPROXY z przekazywaniem oryginalnego adresu
Problem adresu źródłowego

Router wykonując DNAT zmienia adres docelowy, ale źródłowy pozostaje niezmieniony. Teoretycznie serwer widzi faktyczny adres klienta, ale w praktyce pakiety powrotne muszą wrócić przez router.

Jeśli serwer ma bramę domyślną na router, pakiety powrotne trafiają na router, który forwarduje je do klienta. W tym przypadku serwer widzi faktyczny adres klienta.

Problemy pojawiają się przy dodatkowym SNAT na ruchu DNAT. W HTTP popularnym rozwiązaniem jest nagłówek X-Forwarded-For dodawany przez reverse proxy.

36/50
NAT reflection – SNAT dla ruchu DNAT

NAT reflection (hairpin NAT)

# DNAT na serwer WWW
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# SNAT dla ruchu przekierowanego
iptables -t nat -A POSTROUTING -d 192.168.1.10 -p tcp --dport 80 -j SNAT --to-source 192.168.1.1

# Alternatywnie: MASQUERADE
iptables -t nat -A POSTROUTING -d 192.168.1.10 -p tcp --dport 80 -j MASQUERADE

Uwaga: może powodować problemy z dostępem LAN przez adres publiczny.

NAT reflection

NAT reflection (hairpin NAT) dodaje SNAT dla pakietów po DNAT, zapewniając że pakiety powrotne wracają przez router. Bez tego, gdy klient LAN łączy się przez adres publiczny, serwer odpowiada bezpośrednio.

Klient z sieci wewnętrznej łączy się przez publiczny adres routera. Router wykonuje DNAT, serwer odpowiada bezpośrednio do klienta (ta sama sieć). Odpowiedź ma adres serwera, nie publiczny routera – klient odrzuca.

NAT reflection dodaje SNAT w POSTROUTING, zmieniając źródło na adres routera. Serwer odpowiada do routera, który przekazuje do klienta. Wada: dodatkowe obciążenie routera.

37/50
Przekierowanie portów – zakresy i protokoły

Zaawansowane przekierowanie portów

# Zakres portów (gry: 27015-27030)
iptables -t nat -A PREROUTING -p udp --dport 27015:27030 -j DNAT --to-destination 192.168.1.50

# DMZ – cały ruch na jeden serwer
iptables -t nat -A PREROUTING -d 203.0.113.5 -j DNAT --to-destination 192.168.1.100

# TCP i UDP dla portu 53 (DNS)
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to-destination 192.168.1.10:53
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.10:53

# FORWARD dla zakresu
iptables -A FORWARD -p udp -d 192.168.1.50 -m multiport --dports 27015:27030 -m conntrack --ctstate NEW -j ACCEPT
Zakresy portów

Przekierowanie portów obsługuje zakresy portów (--dport 27015:27030), przydatne dla gier sieciowych, VoIP i aplikacji P2P korzystających z wielu portów.

Konfiguracja DMZ przekierowuje cały ruch na jeden serwer. Jest wygodna, ale niebezpieczna – wystawia cały serwer na ataki. Zaleca się przekierowywanie tylko niezbędnych portów.

DNAT działa niezależnie dla TCP i UDP. Dla usług korzystających z obu (DNS na porcie 53) należy dodać osobne reguły dla każdego protokołu.

38/50
Podsumowanie DNAT i port forwardingu

Zastosowania DNAT

  • Udostępnianie serwera WWW z sieci prywatnej
  • SSH na wewnętrzny serwer przez niestandardowy port
  • Hosting wielu serwerów za jednym publicznym adresem IP
  • Równoważenie obciążenia (DNAT z statistic module)
  • Przekierowanie VPN do wewnętrznego serwera
  • Migracja usług bez zmiany adresu publicznego

Zawsze: DNAT + FORWARD + ip_forward = kompletna konfiguracja.

Zastosowania DNAT

DNAT pozwala elastycznie zarządzać dostępem do usług wewnętrznych bez ujawniania topologii sieci. Klient widzi tylko publiczny adres routera.

Równoważenie obciążenia realizuje się przez DNAT z modułem statistic: iptables -t nat -A PREROUTING -p tcp --dport 80 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to-destination 192.168.1.10:80 i następna dla 192.168.1.11:80.

Przekierowanie portów ułatwia migracje – zmiana adresu w regule DNAT jest przezroczysta dla klientów, minimalizując czas przestoju.

39/50
Lab – krok 1: Włączenie ip_forward

Krok 1: Włączenie routingu IP

Bez forwardingu pakiety nie są przekazywane między interfejsami – NAT nie działa.

# Tymczasowe włączenie
sysctl -w net.ipv4.ip_forward=1

# Trwałe włączenie
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# lub: /etc/sysctl.d/99-forward.conf

# Weryfikacja
sysctl net.ipv4.ip_forward
# Oczekiwany: net.ipv4.ip_forward = 1
ip_forward

Pierwszym krokiem w konfiguracji routera Linux jest włączenie forwardingu IP. Domyślnie jądro nie przekazuje pakietów między interfejsami – to zabezpieczenie przed nieautoryzowanym routingiem.

Parametr ustawia się tymczasowo (sysctl -w) lub trwale w /etc/sysctl.conf. Ustawienie tymczasowe działa do restartu. W konfiguracji produkcyjnej konieczne jest trwałe ustawienie.

W nowych dystrybucjach zaleca się pliki w /etc/sysctl.d/. Plik 99-forward.conf z zawartością net.ipv4.ip_forward=1 jest czytelny i łatwy do audytu.

40/50
Lab – krok 2: Przegląd reguł iptables

Podgląd reguł firewalla

# Lista reguł w filter z licznikami
iptables -nL -v

# Lista reguł w tabeli nat
iptables -t nat -L -n -v

# Lista z numerami reguł
iptables -L --line-numbers

# Podgląd konkretnego łańcucha
iptables -L INPUT -n -v

# Polityki domyślne
iptables -L | grep "policy"
iptables -nL -v

Przed konfiguracją warto sprawdzić stan reguł. iptables -nL -v wyświetla reguły z licznikami pakietów i bajtów. Opcja -n wyłącza rozwiązywanie nazw, -v włącza tryb szczegółowy.

Tabela nat ma własne reguły, widoczne przez iptables -t nat -L -n -v. Łańcuchy PREROUTING, POSTROUTING i OUTPUT są puste do czasu dodania reguł NAT.

Opcja --line-numbers dodaje numerację, niezbędną przy wstawianiu (iptables -I INPUT 5) lub usuwaniu reguł (iptables -D INPUT 5).

41/50
Lab – krok 3: Wdrożenie masquerady

Krok 3: Masquerada dla sieci lokalnej

# Założenia: LAN 192.168.1.0/24, WAN eth0

# Polityka DROP dla FORWARD
iptables -P FORWARD DROP

# Ruch powrotny
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Ruch wychodzący z LAN
iptables -A FORWARD -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

# Masquerada
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
Masquerada

Po włączeniu ip_forward konfigurujemy reguły FORWARD. Polityka DROP dla FORWARD jest bezpiecznym domyślnym ustawieniem. Następnie dodajemy reguły dla ESTABLISHED,RELATED (ruch powrotny) i NEW (inicjowanie połączeń z LAN).

Reguła MASQUERADE w POSTROUTING tabeli nat tłumaczy adresy źródłowe wszystkich pakietów z sieci 192.168.1.0/24 wychodzących przez eth0 na adres tego interfejsu.

Hosty w sieci LAN mogą teraz inicjować połączenia do Internetu, a pakiety powrotne są automatycznie kierowane z powrotem dzięki conntrack.

42/50
Lab – krok 4: Przekierowanie portów na serwer WWW

Krok 4: Udostępnienie serwera WWW

# Założenia: serwer WWW na 192.168.1.10:80

# DNAT – przekierowanie portu 80
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# FORWARD dla ruchu do serwera
iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT

# Sprawdzenie reguł NAT
iptables -t nat -L -n -v

# Sprawdzenie działania
curl http://localhost:80
# lub z zewnątrz: curl http://203.0.113.5:80
Port forwarding

Reguła DNAT w PREROUTING przekierowuje ruch z portu 80 routera na serwer 192.168.1.10:80. Bez reguły FORWARD pakiet zostałby odrzucony przez politykę DROP.

Reguła FORWARD dla NEW pozwala na inicjowanie połączeń z Internetu do serwera. Ruch powrotny jest obsługiwany przez wcześniejszą regułę ESTABLISHED,RELATED.

Testowanie: curl z lokalnego hosta lub z zewnątrz na adres publiczny routera. W przeglądarce powinna otworzyć się strona z serwera wewnętrznego.

43/50
Lab – krok 5: Reguły FORWARD dla NAT

Krok 5: Reguły FORWARD dla ruchu tranzytowego

# Kompletny zestaw reguł FORWARD dla routera NAT

# 1. DROP dla INVALID
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

# 2. ACCEPT dla ESTABLISHED,RELATED
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 3. ACCEPT dla ruchu LAN do Internetu
iptables -A FORWARD -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

# 4. ACCEPT dla DNAT (port 80 do serwera)
iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT

# 5. Polityka domyślna: DROP (ustawiona wcześniej)
Reguły FORWARD

Kompletna konfiguracja FORWARD dla routera z NAT i port forwardingiem. Kolejność reguł ma znaczenie: najpierw INVALID, potem ESTABLISHED,RELATED, a na końcu selektywne reguły dla NEW.

Reguła dla ruchu LAN (192.168.1.0/24) pozwala hostom wewnętrznym inicjować połączenia do Internetu. Reguła dla DNAT (do 192.168.1.10:80) pozwala na dostęp do serwera WWW z zewnątrz.

Polityka domyślna DROP zapewnia, że każdy niedozwolony jawnie ruch jest blokowany. Audyt reguł przez iptables -L FORWARD -n -v pozwala sprawdzić liczniki pakietów.

44/50
Lab – podsumowanie konfiguracji

Kompletna konfiguracja routera Linux

# === ROUTER LINUX – NAT + PORT FORWARDING ===

# 1. Włączenie routingu
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

# 2. Reset i polityki domyślne
iptables -F
iptables -t nat -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# 3. INPUT – ochrona routera
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -m conntrack --ctstate NEW -j ACCEPT

# 4. FORWARD – ruch tranzytowy
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

# 5. NAT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT

# 6. Zapis reguł
iptables-save > /etc/iptables/rules.v4
Kompletna konfiguracja

To jest kompletny skrypt konfiguracyjny routera Linux z NAT i port forwardingiem. Obejmuje włączenie routingu, ustawienie polityk, reguły INPUT dla ochrony routera i FORWARD dla ruchu tranzytowego.

Reguły INPUT zezwalają na SSH tylko z sieci administracyjnej (10.0.0.0/8), chroniąc router przed nieautoryzowanym dostępem. Loopback i ESTABLISHED,RELATED są zawsze akceptowane.

Po skonfigurowaniu reguł należy je zapisać (iptables-save), aby przetrwały restart. Weryfikacja przez iptables -nL -v i iptables -t nat -L -n -v.

45/50
Rozwiązywanie problemów – zapomniane zapisanie reguł

Najczęstsze błędy i problemy

  • Brak zapisu reguł – po restarcie firewall znika
  • Zła kolejność reguł – DROP przed ACCEPT
  • Brak ip_forward – NAT nie działa mimo poprawnych reguł
  • Złe interfejsy w regułach (-i zamiast -o, eth0 zamiast ppp0)
  • Brak reguł FORWARD dla DNAT – pakiet odrzucony
  • ICMP jest NATowany przez conntrack przy użyciu ICMP ID (np. ping)
Błędy firewalla

Najczęstszym błędem jest brak zapisania reguł po skonfigurowaniu firewalla. Po restarcie systemu wszystkie reguły znikają, a serwer zostaje bez ochrony lub NAT przestaje działać. Zawsze wykonuj iptables-save po każdej zmianie.

Kolejność reguł ma krytyczne znaczenie. Jeśli reguła DROP znajdzie się przed regułą ACCEPT dla tego samego ruchu, pakiet zostanie odrzucony. Zawsze umieszczaj reguły zezwalające przed blokującymi.

Brak ip_forward to trzeci najczęstszy problem. Nawet z poprawnymi regułami NAT, bez forwardingu pakiety nie będą przekazywane między interfejsami. Zawsze sprawdzaj sysctl net.ipv4.ip_forward.

46/50
Rozwiązywanie problemów – tcpdump

Debugowanie pakietów tcpdump

# Nasłuchiwanie na interfejsie zewnętrznym
tcpdump -i eth0 -nn port 80

# Nasłuchiwanie na interfejsie wewnętrznym
tcpdump -i eth1 -nn port 80

# Sprawdzenie czy pakiet dociera do routera
tcpdump -i any -nn host 203.0.113.5

# Podgląd ruchu ICMP
tcpdump -i eth0 -nn icmp

# Zapis do pliku do późniejszej analizy
tcpdump -i eth0 -nn -w capture.pcap

# Sprawdzenie czy conntrack widzi połączenie
conntrack -L | grep 192.168.1.10
tcpdump

tcpdump to podstawowe narzędzie do debugowania problemów z firewallem i NAT. Pozwala sprawdzić, czy pakiety docierają do interfejsu, czy są przekazywane i czy opuszczają system.

Porównanie ruchu na interfejsie zewnętrznym (eth0) i wewnętrznym (eth1) pozwala zlokalizować problem. Jeśli pakiet dociera do eth0, ale nie pojawia się na eth1, problem leży w regułach FORWARD lub NAT.

Zapis do pliku pcap umożliwia późniejszą szczegółową analizę w Wireshark. conntrack -L pokazuje aktywną tablicę translacji – jeśli wpis nie istnieje, NAT nie zadziałał.

47/50
Rozwiązywanie problemów – logowanie i debug

Logowanie pakietów za pomocą LOG target

# Logowanie odrzuconych pakietów do syslog
iptables -A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "INVALID: " --log-level 4

# Logowanie nowych połączeń HTTP
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j LOG --log-prefix "HTTP_NEW: "

# Podgląd logów
tail -f /var/log/syslog | grep "INVALID\|HTTP_NEW"

# nftables – logowanie
nft add rule inet filter input tcp dport 22 log prefix "SSH: "

# Liczniki reguł – sprawdzenie czy reguła jest używana
iptables -L -n -v
Logowanie

Target LOG w iptables zapisuje informacje o dopasowanych pakietach do syslog bez wpływania na ich dalszy los. Jest to niezbędne narzędzie do debugowania, pozwalające sprawdzić, które reguły są dopasowywane.

Opcja --log-prefix dodaje identyfikator ułatwiający filtrowanie logów. Poziomy logowania (--log-level) od 0 (emerg) do 7 (debug) pozwalają kontrolować ilość informacji.

Liczniki w iptables -L -n -v pokazują ile pakietów dopasowało każdą regułę. Jeśli licznik dla reguły ACCEPT wynosi 0, a ruch nie działa, problem leży gdzie indziej.

48/50
Rozwiązywanie problemów – typowe scenariusze

Scenariusze problemów i rozwiązania

ProblemDiagnozaRozwiązanie
Brak Internetu z LANip_forward=0, brak MASQUERADEsysctl -w, dodaj MASQUERADE
Przekierowanie portów nie działaBrak reguły FORWARDDodaj FORWARD dla DNAT
SSH przerywa połączenieDROP dla ESTABLISHEDDodaj ESTABLISHED,RELATED
Po restarcie brak regułiptables-save nie wykonaneZapisz reguły, zainstaluj iptables-persistent
Niektóre strony nie działająMTU/MSS, fragmentacjaiptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Scenariusze problemów

Brak Internetu z LAN to najczęstszy problem. Sprawdź sysctl net.ipv4.ip_forward (musi być 1), reguły FORWARD (czy zezwalają na ruch z LAN) i regułę MASQUERADE w POSTROUTING.

Przekierowanie portów wymaga trzech elementów: DNAT w PREROUTING, reguły FORWARD dla NEW do serwera i reguły ESTABLISHED,RELATED dla ruchu powrotnego. Brak któregokolwiek powoduje niedziałanie usługi.

Problem z MTU/MSS objawia się nieładowaniem niektórych stron (szczególnie z obrazkami). Rozwiązaniem jest dodanie reguły TCPMSS clamp-mss-to-pmtu w FORWARD, która dostosowuje MSS do MTU ścieżki.

49/50
Ściągawka – najważniejsze polecenia

Ściągawka poleceń iptables/nftables

PolecenieOpis
iptables -L -n -vLista reguł w tabeli filter
iptables -t nat -L -n -vLista reguł NAT
iptables-saveZapis reguł do pliku
iptables-restore < plikPrzywrócenie reguł z pliku
sysctl net.ipv4.ip_forwardSprawdzenie forwardingu
tcpdump -i eth0 -nnNasłuch pakietów
conntrack -LPodgląd tablicy połączeń
nft list rulesetLista reguł nftables
iptables-translate ...Tłumaczenie iptables na nftables
Cheat Sheet

iptables -L -n -v to najważniejsze polecenie do przeglądu reguł. Opcja -n wyłącza rozwiązywanie DNS (przyspiesza), -v pokazuje liczniki pakietów i bajtów. Dla tabeli NAT dodaj -t nat.

iptables-save i iptables-restore służą do zapisu i przywracania reguł. Zawsze wykonuj iptables-save po każdej zmianie, aby reguły przetrwały restart. W Debianie/Ubuntu pakiet iptables-persistent automatyzuje ten proces.

Dla nftables kluczowe jest nft list ruleset, które wyświetla całą konfigurację. Polecenie iptables-translate pomaga przy migracji z iptables na nftables.

50/50
Zakończenie – podsumowanie i praca własna

Podsumowanie

Prezentacja omówiła architekturę Netfilter, konfigurację firewalla z iptables i nftables, mechanizmy NAT (SNAT, DNAT, masquerading) oraz port forwarding. Praktyczne laboratorium przedstawiło kompletny proces konfiguracji routera Linux.

Praca własna:

  • Skonfiguruj router Linux na maszynie wirtualnej/VM z dwoma interfejsami
  • Wdróż politykę Drop by Default i masquerading
  • Skonfiguruj port forwarding dla serwera WWW
  • Przetestuj działanie tcpdump i conntrack
  • Porównaj składnię iptables i nftables
  • Zbadaj działanie NAT reflection w środowisku testowym
Podsumowanie

Dziękujemy za uwagę poświęconą jedenastej części cyklu Administracja Sieci Komputerowych. Materiał ten stanowi solidną podstawę do samodzielnej konfiguracji i utrzymania zapory sieciowej oraz NAT w systemie Linux w środowisku produkcyjnym.

Zachęcamy do praktycznego wykorzystania zdobytej wiedzy poprzez samodzielną konfigurację routera Linux na maszynie wirtualnej. Eksperymenty z różnymi konfiguracjami NAT, testowanie reguł i debugowanie tcpdump pozwolą utrwalić wiedzę i rozwinąć praktyczne umiejętności.

W kolejnych częściach cyklu omówione zostaną zagadnienia zaawansowanego routingu, sieci VPN site-to-site oraz monitorowania ruchu sieciowego z wykorzystaniem narzędzi takich jak ntopng, NetFlow i sFlow.