Home 1: Adresacja 2: DHCP 3: DNS 4: WWW 5: Proxy 6: SSH 7: Monitoring 8: Logowanie 9: Fileserv 10: Ansible 11: FW + NAT 12: Wirtualizacja
1/50
Zapory sieciowe i translacja adresów w Linux
Cel slajdu: Slajd omawia zagadnienie „Zapory sieciowe i translacja adresów w Linux” w kontekście: Ochrona sieci i zarządzanie ruchem w jądrze Linux.

Ochrona sieci i zarządzanie ruchem w jądrze Linux

Wykład poświęcony jest zaawansowanemu zarządzaniu ruchem sieciowym, filtracji pakietów oraz translacji adresów sieciowych (NAT) w systemie Linux. Omawiamy wewnętrzną architekturę podsystemu Netfilter wbudowanego w jądro systemu operacyjnego, klasyczne narzędzie iptables oraz nowoczesny framework nftables. Przedstawiono różnice między zaporą bezstanową (stateless) a stanową (stateful), mechanizmy śledzenia połączeń (conntrack), politykę domyślnej odmowy (Drop by Default), a także implementację translacji adresów SNAT, MASQUERADE i DNAT (Port Forwarding) zgodnie ze standardami IETF (RFC 2663 oraz RFC 3022).

Zapory sieciowe i translacja adresów w Linux: Slajd przedstawia zagadnienie Ochrona sieci i zarządzanie ruchem w jądrze Linux w ramach tematu Zapory sieciowe i translacja adresów w Linux na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Architektura firewalla Linux
2/50
Cel warsztatu – bezpieczeństwo i translacja pakietów
Cel slajdu: Slajd określa wymagane efekty uczenia się, czyli wiedzę i umiejętności, które uczestnik opanuje po zajęciach i laboratorium.

Cele dydaktyczne i operacyjne

Głównym celem zajęć jest opanowanie zasad projektowania, wdrażania i diagnozowania zapór sieciowych oraz translacji adresów w systemie Linux:

  • Zrozumienie architektury Netfilter i punktów zaczepienia w stosie sieciowym jądra.
  • Praktyczna konfiguracja reguł filtrowania w klasycznym iptables oraz nowoczesnym nftables.
  • Implementacja mechanizmów NAT: SNAT, MASQUERADE, DNAT oraz przekierowania portów.
  • Budowa restrykcyjnych polityk bezpieczeństwa w oparciu o zasadę najmniejszych uprawnień (Least Privilege) i podejście Drop by Default.
  • Diagnostyka przepływu pakietów i rozwiązywanie problemów w środowisku produkcyjnym za pomocą tcpdump, conntrack oraz logowania zdarzeń jądra.
  • Przygotowanie do samodzielnego wdrożenia bezpiecznego routera brzegowego w sieci LAN/WAN.
Cel warsztatu – bezpieczeństwo i translacja pakietów: Slajd przedstawia zagadnienie Cele dydaktyczne i operacyjne w ramach tematu Cel warsztatu – bezpieczeństwo i translacja pakietów na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Mapa celów warsztatu
3/50
Agenda spotkania
Cel slajdu: Slajd przedstawia kolejność omawianych zagadnień i wskazuje miejsce bieżącego tematu w strukturze wykładu.

Plan prezentacji

  • Blok I (slajdy 4–10): Architektura frameworku Netfilter, punkty zaczepienia (hooks) w jądrze, filtracja stateless vs stateful, łańcuchy INPUT, FORWARD, OUTPUT, polityka domyślna oraz system conntrack.
  • Blok II (slajdy 11–20): Stany połączeń w conntrack, eliminacja pakietów INVALID, składnia iptables, architektura i składnia nftables, porównanie narzędzi, selektywne reguły ACCEPT, zasada najmniejszych uprawnień i trwałość konfiguracji.
  • Blok III (slajdy 21–30): Translacja adresów NAT w IPv4, mechanika NAPT/PAT, SNAT vs MASQUERADE, wdrożenia dla adresów statycznych i dynamicznych (PPPoE/DHCP), interakcja z conntrack, protokoły problematyczne (ALG) oraz NAT w świecie IPv6 (NPTv6, NAT64).
  • Blok IV (slajdy 31–40): Translacja docelowa DNAT, przekierowanie portów, wymóg asocjacji z łańcuchem FORWARD, problem zachowania adresu źródłowego klienta, zjawisko Hairpin NAT (NAT Reflection), obsługa zakresów portów oraz włączenie routingu IP.
  • Blok V (slajdy 41–50): Laboratorium wdrożeniowe krok po kroku (router Linux), metodyka rozwiązywania problemów (troubleshooting), diagnostyka narzędziem tcpdump, logowanie LOG/NFLOG, typowe scenariusze awarii, zestawienie poleceń oraz podsumowanie.
Agenda spotkania: Slajd przedstawia zagadnienie Plan prezentacji w ramach tematu Agenda spotkania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Agenda
4/50
Netfilter – framework filtrowania w jądrze Linux
Cel slajdu: Slajd omawia zagadnienie „Netfilter – framework filtrowania w jądrze Linux” w kontekście: Netfilter – wbudowany system filtrowania.

Netfilter – wbudowany system filtrowania

Netfilter to framework zintegrowany bezpośrednio z jądrem systemu Linux, odpowiedzialny za inspekcję, modyfikację oraz sterowanie przepływem pakietów sieciowych:

  • Praca w przestrzeni jądra (Kernel Space): bezpośredni dostęp do buforów sk_buff, brak konieczności kopiowania danych do przestrzeni użytkownika (wysoka przepustowość, minimalne opóźnienia).
  • Punkty zaczepienia (Hooks): zdefiniowane lokalizacje w kodzie stosu sieciowego, w których rejestrowane są funkcje zwrotne (callbacki).
  • Obsługa wielu protokołów: IPv4, IPv6, ARP oraz warstwy łącza danych (Ethernet Bridging).
  • Fundament narzędziowy: podstawa działania dla iptables, nftables, ip6tables, ebtables oraz arptables.
  • Architektura modułowa: rozszerzenia ładowane dynamicznie (śledzenie połączeń nf_conntrack, moduły translacji nf_nat, cele logowania nf_log).
  • Interfejs Netlink: komunikacja z programami przestrzeni użytkownika przez gniazda AF_NETLINK.
Netfilter – framework filtrowania w jądrze Linux: Slajd przedstawia zagadnienie Netfilter – wbudowany system filtrowania w ramach tematu Netfilter – framework filtrowania w jądrze Linux na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat Netfilter hooks
5/50
Punkty zaczepienia pakietów – przepływ przez stos
Cel slajdu: Slajd omawia zagadnienie „Punkty zaczepienia pakietów – przepływ przez stos” w kontekście: Pięć punktów zaczepienia Netfilter.

Pięć punktów zaczepienia Netfilter

W architekturze Netfilter zdefiniowano pięć standardowych punktów zaczepienia (hooks) w stosie sieciowym:

  • PREROUTING (NF_INET_PRE_ROUTING): przechwytuje pakiety przychodzące z interfejsu sieciowego natychmiast po ich odebraniu, przed podjęciem decyzji routingu. Miejsce translacji docelowej (DNAT) i wstępnej modyfikacji nagłówków.
  • INPUT (NF_INET_LOCAL_IN): obsługa pakietów, których docelowym adresem IP jest lokalny system. Służy do ochrony procesów i usług uruchomionych na danym hoście.
  • FORWARD (NF_INET_FORWARD): obsługa pakietów tranzytowych, które przechodzą przez router z jednego interfejsu na inny (nie są zaadresowane do lokalnego hosta).
  • OUTPUT (NF_INET_LOCAL_OUT): pakiety generowane lokalnie przez procesy systemowe, poddawane wstępnej filtracji przed wysłaniem do stosu routingu.
  • POSTROUTING (NF_INET_POST_ROUTING): pakiety po podjęciu ostatecznej decyzji routingu, tuż przed wysłaniem na fizyczny interfejs sieciowy. Miejsce translacji źródłowej (SNAT i MASQUERADE).
Punkty zaczepienia pakietów – przepływ przez stos: Slajd przedstawia zagadnienie Pięć punktów zaczepienia Netfilter w ramach tematu Punkty zaczepienia pakietów – przepływ przez stos na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Diagram przeplywu pakietu przez hooki
6/50
Firewall stateless a stateful – pamięć połączeń
Cel slajdu: Slajd omawia zagadnienie „Firewall stateless a stateful – pamięć połączeń” w kontekście: Stateless vs Stateful Firewall.

Stateless vs Stateful Firewall

Filtracja pakietów może odbywać się według dwóch zasadniczych paradygmatów architektonicznych:

  • Zapora bezstanowa (Stateless): analizuje każdy pakiet w całkowitej izolacji, opierając się wyłącznie na informacjach zawartych w nagłówkach (adresy IP, porty, flagi TCP). Wymaga definiowania reguł symetrycznych dla obu kierunków transmisji, co uniemożliwia skuteczną ochronę portów efemerycznych (1024–65535).
  • Zapora stanowa (Stateful): utrzymuje w pamięci dynamiczną tablicę sesji (Connection Tracking), rejestrując kontekst komunikacji dwukierunkowej.
  • Moduł conntrack: serce zapory stanowej w Netfilter; śledzi połączenia TCP (odwzorowanie maszyny stanowej flag SYN/ACK/FIN/RST), sesje UDP (pseudopołączenia czasowe) oraz powiązane komunikaty ICMP.
  • Stany conntrack: NEW, ESTABLISHED, RELATED, INVALID oraz UNTRACKED.
  • Wzorzec reguły stanowej: natychmiastowe dopuszczenie ESTABLISHED,RELATED i restrykcyjne otwieranie wyłącznie stanu NEW.
Firewall stateless a stateful – pamięć połączeń: Slajd przedstawia zagadnienie Stateless vs Stateful Firewall w ramach tematu Firewall stateless a stateful – pamięć połączeń na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Porównanie firewall stateless vs stateful
7/50
Łańcuchy INPUT, FORWARD, OUTPUT – role i zastosowania
Cel slajdu: Slajd omawia zagadnienie „Łańcuchy INPUT, FORWARD, OUTPUT – role i zastosowania” w kontekście: Trzy główne łańcuchy filtrowania.

Trzy główne łańcuchy filtrowania

W standardowej tablicy filter zdefiniowane są trzy podstawowe łańcuchy odpowiadające za różne wektory ruchu:

  • Łańcuch INPUT: kontrola ruchu przychodzącego zaadresowanego do lokalnego hosta. Zapewnia ochronę usług działających na serwerze (SSH, serwer WWW, bazy danych, demony zarządzające).
  • Łańcuch FORWARD: kontrola ruchu tranzytowego, który jest przekazywany przez router pomiędzy różnymi interfejsami sieciowymi (ochrona stacji roboczych i serwerów w sieciach LAN i DMZ).
  • Łańcuch OUTPUT: kontrola pakietów generowanych lokalnie przez procesy systemowe i użytkowników. Umożliwia zapobieganie wyciekom danych oraz ogranicza komunikację szkodliwego oprogramowania z serwerami C2.
  • Łańcuchy użytkownika (User-defined chains): tworzone poleceniem iptables -N w celu modularyzacji, czytelności i optymalizacji wydajnościowej reguł.
  • Zasada First Match Wins: reguły są ewaluowane sekwencyjnie od góry do dołu – pierwsze dopasowanie kończy przetwarzanie pakietu w łańcuchu.
Łańcuchy INPUT, FORWARD, OUTPUT – role i zastosowania: Slajd przedstawia zagadnienie Trzy główne łańcuchy filtrowania w ramach tematu Łańcuchy INPUT, FORWARD, OUTPUT – role i zastosowania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Trzy główne łańcuchy filtrowania
8/50
Polityka domyślna – ACCEPT czy DROP?
Cel slajdu: Slajd omawia zagadnienie „Polityka domyślna – ACCEPT czy DROP?” w kontekście: Polityka domyślna łańcucha.

Polityka domyślna łańcucha

Polityka domyślna (Default Policy) określa los pakietu, który nie został dopasowany do żadnej ze zdefiniowanych reguł w łańcuchu:

  • ACCEPT (Default Permit / Blacklisting): podejście liberalne – cały ruch jest domyślnie przepuszczany, a administrator blokuje wybrane zagrożenia. Wysoce podatne na błędy i przeoczenia nieznanych wektorów ataku.
  • DROP (Default Deny / Whitelisting): podejście bezpieczne – cały ruch jest domyślnie blokowany, a administrator jawnie zezwala wyłącznie na autoryzowane usługi. Rekomendacja standardów branżowych (CIS Benchmarks, NIST SP 800-41 Rev. 1).
  • Porównanie DROP vs REJECT:
    • DROP: cicho odrzuca pakiet bez powiadomienia nadawcy; skanery sieciowe czekają na timeout, co utrudnia rekonesans.
    • REJECT: odsyła komunikat błędu (ICMP Port Unreachable lub TCP RST); przydatny w sieciach lokalnych LAN, gdyż przyspiesza zamykanie sesji w aplikacjach klienckich.
  • Polecenie zmiany polityki: iptables -P INPUT DROP, iptables -P FORWARD DROP.
Polityka domyślna – ACCEPT czy DROP?: Slajd przedstawia zagadnienie Polityka domyślna łańcucha w ramach tematu Polityka domyślna – ACCEPT czy DROP? na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Porównanie polityk ACCEPT vs DROP
9/50
Wdrażanie polityki Drop by Default
Cel slajdu: Slajd omawia zagadnienie „Wdrażanie polityki Drop by Default” w kontekście: Kroki do bezpiecznej konfiguracji.

Kroki do bezpiecznej konfiguracji

Wdrażanie polityki domyślnej odmowy wymaga zachowania rygorystycznej sekwencji, zapobiegającej natychmiastowej utracie łączności administracyjnej (self-lockout):

# 1. Zezwolenie na ruch lokalny pętli zwrotnej (loopback)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 2. Odrzucenie pakietów uszkodzonych i niespójnych (INVALID)
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# 3. Zezwolenie na ruch powrotny i powiązany (ESTABLISHED,RELATED)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 4. Zezwolenie na dostęp administracyjny SSH przed zmianą polityki!
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -m conntrack --ctstate NEW -j ACCEPT

# 5. Ustawienie restrykcyjnej polityki domyślnej DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
Wdrażanie polityki Drop by Default: Slajd przedstawia zagadnienie Kroki do bezpiecznej konfiguracji w ramach tematu Wdrażanie polityki Drop by Default na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Konfiguracja Drop by Default
10/50
Śledzenie połączeń – conntrack w praktyce
Cel slajdu: Slajd omawia zagadnienie „Śledzenie połączeń – conntrack w praktyce” w kontekście: Narzędzia do monitorowania conntrack.

Narzędzia do monitorowania conntrack

Podsystem conntrack przechowuje informacje o aktywnych sesjach w pamięci jądra i udostępnia interfejsy diagnostyczne. Narzędzie diagnostyczne nie jest instalowane domyślnie – w systemach Debian/Ubuntu wymaga doinstalowania pakietem apt install conntrack:

  • conntrack -L: wyświetla pełną listę aktualnie śledzonych sesji wraz z adresami, portami, stanami i licznikami czasu.
  • conntrack -E: nasłuchuje zdarzeń w czasie rzeczywistym (tworzenie nowych sesji, niszczenie zakończonych, aktualizacje).
  • conntrack -D -p tcp --dport 80: usuwa z tablicy wybrane połączenia spełniające kryteria.
  • Odczyt tablicy połączeń: w starszych jądrach dostępny był plik tekstowy /proc/net/nf_conntrack; w nowych jądrach (od linii 5.x wzwyż) interfejs ten usunięto i jedynym obsługiwanym sposobem odczytu jest narzędzie conntrack komunikujące się z jądrem przez gniazda netlink.
  • sysctl net.netfilter.nf_conntrack_max: maksymalny limit śledzonych połączeń w pamięci jądra.
  • Przepełnienie tablicy (Table Full): osiągnięcie limitu powoduje odrzucanie nowych połączeń i komunikat błędu w dmesg.
Śledzenie połączeń – conntrack w praktyce: Slajd przedstawia zagadnienie Narzędzia do monitorowania conntrack w ramach tematu Śledzenie połączeń – conntrack w praktyce na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Wynik conntrack -L
11/50
Stany połączeń – NEW, ESTABLISHED, RELATED, INVALID
Cel slajdu: Slajd omawia zagadnienie „Stany połączeń – NEW, ESTABLISHED, RELATED, INVALID” w kontekście: Cztery stany conntrack.

Cztery stany conntrack

Moduł conntrack kategoryzuje każdy przetwarzany pakiet do jednego z precyzyjnie zdefiniowanych stanów logicznych:

  • NEW: pakiet rozpoczynający nową sesję komunikacyjną (np. pierwszy pakiet TCP z ustawioną flagą SYN, pierwszy pakiet UDP lub żądanie ICMP Echo Request).
  • ESTABLISHED: pakiet należący do aktywnej, dwukierunkowej sesji, w której zaobserwowano już pakiety w obu kierunkach (np. odebrano pakiet TCP SYN-ACK).
  • RELATED: pakiet inicjujący nowe połączenie, lecz ściśle powiązany logicznie z już istniejącą sesją ESTABLISHED (np. transfer danych FTP w trybie aktywnym/pasywnym, sesja audio/wideo w protokole SIP lub powiązany komunikat błędu ICMP).
  • INVALID: pakiet, którego nie można powiązać z żadną znaną sesją i który nie spełnia reguł poprawnego rozpoczęcia nowego połączenia (nieprawidłowa kombinacja flag TCP, pakiety poza dynamicznym oknem sekwencyjnym).
  • UNTRACKED: pakiet celowo wyłączony z mechanizmu śledzenia w tabeli raw za pomocą celu NOTRACK.
Stany połączeń – NEW, ESTABLISHED, RELATED, INVALID: Slajd przedstawia zagadnienie Cztery stany conntrack w ramach tematu Stany połączeń – NEW, ESTABLISHED, RELATED, INVALID na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Diagram stanów conntrack
12/50
Odrzucanie pakietów INVALID – pierwsza linia obrony
Cel slajdu: Slajd omawia zagadnienie „Odrzucanie pakietów INVALID – pierwsza linia obrony” w kontekście: Pakiet INVALID – natychmiastowe odrzucenie.

Pakiet INVALID – natychmiastowe odrzucenie

Odrzucanie pakietów oznaczonych stanem INVALID stanowi fundament higieny bezpieczeństwa każdego routera i serwera Linux:

# Odrzucenie pakietów uszkodzonych na początku łańcucha INPUT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Odrzucenie pakietów uszkodzonych w ruchu tranzytowym FORWARD
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

# nftables – analogiczna reguła w łańcuchu bazowym
nft add rule inet filter input ct state invalid drop
  • Ochrona przed rekonesansem: neutralizacja złośliwych skanów portów (NULL scan, XMAS scan z flagami FIN+PSH+URG, FIN scan).
  • Ochrona przed atakami desynchronizacji: blokowanie fałszywych pakietów TCP wstrzykiwanych poza bieżącym oknem sekwencyjnym.
  • Oszczędność zasobów procesora: natychmiastowe porzucenie uszkodzonej ramki eliminuje kosztowną ewaluację kolejnych reguł.
Odrzucanie pakietów INVALID – pierwsza linia obrony: Slajd przedstawia zagadnienie Pakiet INVALID – natychmiastowe odrzucenie w ramach tematu Odrzucanie pakietów INVALID – pierwsza linia obrony na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Ilustracja pakietów INVALID
13/50
iptables – klasyczne narzędzie filtrowania
Cel slajdu: Slajd omawia zagadnienie „iptables – klasyczne narzędzie filtrowania” w kontekście: iptables – standard od lat 90..

iptables – standard od lat 90.

Narzędzie iptables stanowiło fundament zarządzania ruchem sieciowym w systemie Linux od wydania jądra 2.4:

  • Organizacja w tablice:
    • raw: konfiguracja zwolnień ze śledzenia sesji (cel NOTRACK), wywoływana przed conntrack.
    • mangle: zaawansowana modyfikacja pól nagłówków IP (TOS, DSCP, TTL, znaczniki MARK).
    • nat: translacja adresów i portów sieciowych (SNAT, DNAT, MASQUERADE, REDIRECT).
    • filter: domyślna tablica zasadniczej filtracji pakietów (INPUT, FORWARD, OUTPUT).
    • security: współpraca z modułami Mandatory Access Control (SELinux SECMARK).
  • Podział narzędziowy: odrębne binaria dla różnych protokołów: iptables (IPv4), ip6tables (IPv6), arptables (ARP) oraz ebtables (mostkowanie L2).
  • Wywołania systemowe: komunikacja z jądrem za pośrednictwem gniazd Netlink oraz mechanizmu getsockopt/setsockopt.
iptables – klasyczne narzędzie filtrowania: Slajd przedstawia zagadnienie iptables – standard od lat 90 w ramach tematu iptables – klasyczne narzędzie filtrowania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Podział na tabele i łańcuchy
14/50
Składnia iptables – opcje i parametry
Cel slajdu: Slajd omawia zagadnienie „Składnia iptables – opcje i parametry” w kontekście: Budowa reguły iptables.

Budowa reguły iptables

Reguła iptables składa się ze wskazania tablicy, akcji na łańcuchu, kryteriów dopasowania oraz celu (werdyktu):

# Składnia ogólna:
iptables [-t tabela] POLECENIE łańcuch [kryteria] [-m moduł] -j CEL [opcje]

# Przykład: Zezwolenie na ruch SSH z wybranej podsieci zarządzającej
iptables -A INPUT -s 10.10.0.0/24 -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Kluczowe polecenia operacyjne:
-A (Append) – dołączenie reguły na końcu łańcucha
-I (Insert) – wstawienie reguły na wybraną pozycję (domyślnie na początek)
-D (Delete) – usunięcie reguły według numeru wiersza lub wzorca
-L -n -v (List) – wylistowanie reguł numerycznie z licznikami pakietów i bajtów
-F (Flush) – usunięcie wszystkich reguł ze wskazanej tablicy
-P (Policy) – ustawienie domyślnej polityki dla danego łańcucha
Składnia iptables – opcje i parametry: Slajd przedstawia zagadnienie Budowa reguły iptables w ramach tematu Składnia iptables – opcje i parametry na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Składnia reguły iptables
15/50
nftables – następca iptables
Cel slajdu: Slajd omawia zagadnienie „nftables – następca iptables” w kontekście: nftables – nowa generacja firewalla.

nftables – nowa generacja firewalla

Podsystem nftables stanowi nowoczesne, kompleksowe rozwiązanie filtracji pakietów w jądrze Linux:

  • Zastąpienie całego ekosystemu: jedno narzędzie nft zastępuje dotychczasowe iptables, ip6tables, arptables oraz ebtables.
  • Wirtualna maszyna w jądrze (Bytecode Engine): jądro wykonuje zwięzły, wysoce zoptymalizowany kod bajtowy; logika protokołów przeniesiona do biblioteki przestrzeni użytkownika libnftnl.
  • Zunifikowana rodzina podwójnego stosu (inet): wspólne reguły dla IPv4 i IPv6 bez konieczności dublowania konfiguracji.
  • Wbudowane zaawansowane struktury danych: natywna obsługa zbiorów (sets), słowników mapujących (maps) oraz map werdyktów (verdict maps) o złożoności wyszukiwania O(1).
  • Atomowość operacji: cały zestaw reguł (ruleset) jest kompilowany i ładowany do jądra w ramach pojedynczej, nierozerwalnej transakcji.
  • Domyślny podsystem: standard w dystrybucjach Debian (od wersji 10), RHEL/CentOS (od wersji 8) oraz Ubuntu (od 20.04 LTS).
nftables – następca iptables: Slajd przedstawia zagadnienie nftables – nowa generacja firewalla w ramach tematu nftables – następca iptables na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Porównanie iptables vs nftables
16/50
Składnia nftables – reguły i rodziny
Cel slajdu: Slajd omawia zagadnienie „Składnia nftables – reguły i rodziny” w kontekście: Składnia nftables.

Składnia nftables

W nftables tabele i łańcuchy nie są na stałe wbudowane w jądro – administrator tworzy je jawnie w odpowiednich rodzinach adresów:

# Rodziny adresów: inet (IPv4+IPv6), ip (IPv4), ip6 (IPv6), arp, bridge, netdev
nft add table inet filtr_sieci

# Utworzenie łańcucha bazowego podpiętego pod hook INPUT jądra
nft add chain inet filtr_sieci wejscie { type filter hook input priority 0; policy drop; }

# Podstawowe reguły Drop by Default:
nft add rule inet filtr_sieci wejscie iifname "lo" accept
nft add rule inet filtr_sieci wejscie ct state invalid drop
nft add rule inet filtr_sieci wejscie ct state established,related accept

# Otwarcie portów za pomocą natywnego zbioru (set)
nft add rule inet filtr_sieci wejscie tcp dport { 22, 80, 443 } ct state new accept
Składnia nftables – reguły i rodziny: Slajd przedstawia zagadnienie Składnia nftables w ramach tematu Składnia nftables – reguły i rodziny na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Składnia nftables
17/50
iptables vs nftables – wybór narzędzia
Cel slajdu: Slajd omawia zagadnienie „iptables vs nftables – wybór narzędzia” w kontekście: Porównanie iptables i nftables.

Porównanie iptables i nftables

Zestawienie kluczowych różnic architektonicznych i użytkowych pomiędzy narzędziami:

Cecha architektonicznaiptablesnftables
Obsługa protokołówOsobne narzędzia dla IPv4 i IPv6Zunifikowana rodzina inet (dual-stack)
Wydajność przy skaliPrzeszukiwanie sekwencyjne O(N)Zbiory haszowane i drzewa O(1) / O(log N)
Atomowość zmianBlokada tablicy, brak atomowości pojedynczych regułTransakcyjne, atomowe ładowanie całego rulesetu
Złożone struktury danychWymaga zewnętrznego rozszerzenia ipsetNatywne zbiory (sets), mapy (maps) i vmaps
Struktura jądraWbudowane predefiniowane tabele i łańcuchyPełna dowolność definiowania obiektów i hooków
Narzędzia migracyjneNarzędzie historyczneiptables-translate, zgodność iptables-nft
iptables vs nftables – wybór narzędzia: Slajd przedstawia zagadnienie Porównanie iptables i nftables w ramach tematu iptables vs nftables – wybór narzędzia na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Tabela porównawcza
18/50
Selektywne otwieranie reguł ACCEPT
Cel slajdu: Slajd omawia zagadnienie „Selektywne otwieranie reguł ACCEPT” w kontekście: Precyzyjne reguły ACCEPT.

Precyzyjne reguły ACCEPT

Każda reguła zezwalająca (ACCEPT) powinna maksymalnie zawężać wektor dopuszczenia ruchu:

# 1. SSH dostępne wyłącznie z dedykowanej podsieci administracyjnej VLAN
iptables -A INPUT -p tcp -s 10.10.50.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# 2. Ruch HTTP/HTTPS z autoryzacją wyłącznie nowych sesji
iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT

# 3. Kontrolowany ICMP: ograniczenie żądań Echo Request z limitem częstości
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 2/s --limit-burst 5 -j ACCEPT

# 4. Krytyczny komunikat ICMP dla Path MTU Discovery (RFC 1191)
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT
Selektywne otwieranie reguł ACCEPT: Slajd przedstawia zagadnienie Precyzyjne reguły ACCEPT w ramach tematu Selektywne otwieranie reguł ACCEPT na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat otwierania portów
19/50
Zasada najmniejszych uprawnień
Cel slajdu: Slajd omawia zagadnienie „Zasada najmniejszych uprawnień” w kontekście: Zasada najmniejszych uprawnień.

Zasada najmniejszych uprawnień

Wdrożenie zasady najmniejszych uprawnień (Least Privilege) w architekturze zapory sieciowej:

  • Minimalizacja ekspozycji (Attack Surface): otwieranie wyłącznie niezbędnych portów, protokołów i interfejsów dla ściśle określonych adresów IP.
  • Rygorystyczna segmentacja stref: fizyczne i logiczne (VLAN) odseparowanie podsieci użytkowników (LAN), serwerów publicznych (DMZ) oraz infrastruktury zarządzania (Management/OOB).
  • Filtracja ruchu wychodzącego (Egress Filtering): serwery w DMZ nie mogą mieć nieograniczonego dostępu do Internetu; ruch wychodzący powinien być dozwolony wyłącznie na potrzeby aktualizacji repozytoriów i synchronizacji czasu NTP.
  • Wycofywanie reguł tymczasowych: usuwanie otwarć portów po zakończeniu prac wdrożeniowych i serwisowych.
  • Bieżący audyt liczników: weryfikacja statystyk użycia reguł (iptables -L -n -v) w celu eliminacji reguł martwych lub nadmiarowych.
Zasada najmniejszych uprawnień: Slajd przedstawia zagadnienie Zasada najmniejszych uprawnień w ramach tematu Zasada najmniejszych uprawnień na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Zasada najmniejszych uprawnień
20/50
Trwałość reguł – zapis i przywracanie
Cel slajdu: Slajd omawia zagadnienie „Trwałość reguł – zapis i przywracanie” w kontekście: Zapis i przywracanie reguł.

Zapis i przywracanie reguł

Reguły wprowadzane z wiersza poleceń są przechowywane wyłącznie w pamięci operacyjnej jądra i znikają po restarcie systemu:

# === iptables – zapis i odtwarzanie atomowe ===
mkdir -p /etc/iptables
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
iptables-restore < /etc/iptables/rules.v4

# Pakiet automatyzujący w systemach Debian/Ubuntu
apt install iptables-persistent netfilter-persistent
systemctl enable --now netfilter-persistent.service

# === nftables – zapis i zarządzanie usługą systemd ===
nft list ruleset > /etc/nftables.conf
nft -f /etc/nftables.conf
systemctl enable --now nftables.service
Trwałość reguł – zapis i przywracanie: Slajd przedstawia zagadnienie Zapis i przywracanie reguł w ramach tematu Trwałość reguł – zapis i przywracanie na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Zapis reguł
21/50
NAT – Network Address Translation w IPv4
Cel slajdu: Slajd omawia zagadnienie „NAT – Network Address Translation w IPv4” w kontekście: NAT – konieczność w świecie IPv4.

NAT – konieczność w świecie IPv4

Mechanizm translacji adresów sieciowych (NAT – Network Address Translation) został zdefiniowany w standardach IETF (RFC 1631, RFC 2663 oraz RFC 3022):

  • Ograniczenia puli IPv4: teoretyczna pojemność 32-bitowej przestrzeni adresowej (ok. 4,29 miliarda adresów) okazała się niewystarczająca dla globalnego Internetu.
  • Prywatne przestrzenie adresowe (RFC 1918):
    • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255) – duże sieci korporacyjne
    • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255) – sieci średniej wielkości
    • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255) – sieci lokalne SOHO i LAN
  • Brak routingu w Internecie: pule RFC 1918 nie są trasowane przez routery w globalnej tablicy BGP.
  • Rola routera NAT: translacja adresów prywatnych na jeden lub więcej publicznych adresów IP routowalnych globalnie.
NAT – Network Address Translation w IPv4: Slajd przedstawia zagadnienie NAT – konieczność w świecie IPv4 w ramach tematu NAT – Network Address Translation w IPv4 na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat NAT
22/50
Mechanizm NAT – translacja adresów i portów
Cel slajdu: Slajd omawia zagadnienie „Mechanizm NAT – translacja adresów i portów” w kontekście: Jak działa NAT?.

Jak działa NAT?

Translacja adresów sieciowych występuje w kilku podstawowych wariantach architektonicznych:

  • Statyczny NAT (Static NAT 1:1): stałe, jednoznaczne przypisanie jednego prywatnego adresu IP do jednego publicznego adresu IP (stosowane głównie przy publikacji serwerów).
  • Dynamiczny NAT (Dynamic NAT Pool): dynamiczne mapowanie adresu prywatnego na wolny adres publiczny z puli N adresów dostarczonych przez ISP.
  • NAPT / PAT (Network Address Port Translation): najpowszechniejsza odmiana (często utożsamiana z pojęciem NAT) – jednoczesna translacja adresu IP oraz numeru portu warstwy czwartej (TCP/UDP).
  • Przestrzeń portów: 16-bitowe pole portu źródłowego umożliwia teoretyczną obsługę do ok. 64 000 równoczesnych sesji na pojedynczym adresie publicznym.
  • Rekalkulacja sum kontrolnych: każda modyfikacja nagłówka IP i portu wymusza przeliczenie sumy kontrolnej pakietu (Checksum Recomputation) przez jądro.
Mechanizm NAT – translacja adresów i portów: Slajd przedstawia zagadnienie Jak działa NAT? w ramach tematu Mechanizm NAT – translacja adresów i portów na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Diagram NAT
23/50
SNAT – zmiana źródłowego adresu pakietu
Cel slajdu: Slajd porządkuje literaturę przedmiotu oraz wskazuje obowiązujące normy techniczne i przepisy stanowiące podstawę wykładu.

SNAT (Source Network Address Translation)

Translacja adresu źródłowego (SNAT) służy do modyfikacji adresu nadawcy w pakietach opuszczających sieć lokalną:

# Składnia iptables – translacja na pojedynczy stały adres publiczny
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5

# Translacja na pulę publicznych adresów IP (obciążenie zrównoważone)
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10-203.0.113.20

# nftables – najpierw tabela i łańcuch typu nat, potem reguła
nft add table ip nat_translacja
nft add chain ip nat_translacja postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat_translacja postrouting ip saddr 192.168.1.0/24 oifname "eth0" snat to 203.0.113.5
  • Lokalizacja w stosie: wyłącznie łańcuch POSTROUTING tabeli nat (po podjęciu decyzji routingu).
  • Warunek: stosowane na łączach ze stałym, niezmiennym adresem IP.
SNAT – zmiana źródłowego adresu pakietu: Slajd przedstawia zagadnienie SNAT (Source Network Address Translation) w ramach tematu SNAT – zmiana źródłowego adresu pakietu na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat SNAT
24/50
Maskarada – SNAT z automatycznym adresem
Cel slajdu: Slajd omawia zagadnienie „Maskarada – SNAT z automatycznym adresem” w kontekście: MASQUERADE – dynamiczny SNAT.

MASQUERADE – dynamiczny SNAT

Cel MASQUERADE to wyspecjalizowany wariant SNAT stworzony z myślą o łączach ze zmiennym adresem IP:

# Składnia iptables dla dynamicznego łącza WAN (np. eth0 z DHCP lub ppp0 z PPPoE)
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# nftables – maskarada w łańcuchu postrouting (tabela i łańcuch jak w przykładzie SNAT)
nft add rule ip nat_translacja postrouting ip saddr 192.168.1.0/24 oifname "eth0" masquerade
  • Automatyczna detekcja adresu: jądro dynamicznie sprawdza aktualny adres IP przypisany do interfejsu wyjściowego w chwili wysyłania pierwszego pakietu.
  • Zarządzanie stanami sesji: przy przerwaniu połączenia lub zmianie adresu IP (zdarzenie NETDEV_DOWN/NETDEV_CHANGEADDR) jądro automatycznie czyści powiązane wpisy w tablicy conntrack.
  • Zastosowanie: łącza domowe i SOHO (FTTH/GPON z DHCP, DSL/PPPoE, modemy komórkowe LTE/5G).
Maskarada – SNAT z automatycznym adresem: Slajd przedstawia zagadnienie MASQUERADE – dynamiczny SNAT w ramach tematu Maskarada – SNAT z automatycznym adresem na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Porównanie SNAT vs MASQUERADE
25/50
SNAT vs MASQUERADE – wybór metody
Cel slajdu: Slajd omawia zagadnienie „SNAT vs MASQUERADE – wybór metody” w kontekście: Kiedy użyć SNAT, a kiedy MASQUERADE?.

Kiedy użyć SNAT, a kiedy MASQUERADE?

Wybór właściwej metody translacji źródłowej zależy bezpośrednio od charakterystyki interfejsu WAN:

Kryterium techniczneSNATMASQUERADE
Adresacja WANStały, niezmienny publiczny adres IPDynamiczny adres IP (DHCP, PPPoE, LTE/5G)
Narzut obliczeniowyMinimalny (stała wartość wpisana w regułę)Nieco wyższy (odczyt konfiguracji interfejsu)
Pula adresów IPTak (obsługa zakresu --to-source IP1-IP2)Nie (wyłącznie bieżący adres interfejsu)
Zmiana adresu interfejsuWymaga ręcznej aktualizacji reguły w zaporzeAutomatyczna detekcja i czyszczenie conntrack
Rekomendowane środowiskoSerwery dedykowane, centra danych, łącza BGPBramy dostępowe SOHO, łącza konsumenckie
SNAT vs MASQUERADE – wybór metody: Slajd przedstawia zagadnienie Kiedy użyć SNAT, a kiedy MASQUERADE? w ramach tematu SNAT vs MASQUERADE – wybór metody na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Tabela decyzyjna
26/50
Praktyczny przykład – SNAT dla sieci lokalnej
Cel slajdu: Slajd omawia zagadnienie „Praktyczny przykład – SNAT dla sieci lokalnej” w kontekście: Konfiguracja SNAT krok po kroku.

Konfiguracja SNAT krok po kroku

Scenariusz: Brama brzegowa łączy sieć LAN 192.168.1.0/24 ze światem przez interfejs WAN eth0 (IP: 203.0.113.5):

# Krok 1: Włączenie przekazywania pakietów w jądrze Linux
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-ipforward.conf

# Krok 2: Ustawienie domyślnej polityki blokowania w łańcuchu FORWARD
iptables -P FORWARD DROP

# Krok 3: Zezwolenie na ruch powrotny dla nawiązanych sesji
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Krok 4: Zezwolenie na inicjowanie nowych połączeń wyłącznie z sieci LAN do Internetu
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

# Krok 5: Wdrożenie translacji SNAT w łańcuchu POSTROUTING tabeli nat
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.5
Praktyczny przykład – SNAT dla sieci lokalnej: Slajd przedstawia zagadnienie Konfiguracja SNAT krok po kroku w ramach tematu Praktyczny przykład – SNAT dla sieci lokalnej na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat sieci z SNAT
27/50
Maskarada dla PPPoE/DHCP
Cel slajdu: Slajd omawia zagadnienie „Maskarada dla PPPoE/DHCP” w kontekście: Maskarada dla dynamicznego adresu WAN.

Maskarada dla dynamicznego adresu WAN

Wdrożenie routera brzegowego dla dynamicznego interfejsu PPPoE (ppp0) z zabezpieczeniem MSS:

# 1. Włączenie forwardingu IP i restrykcyjna polityka tranzytowa
sysctl -w net.ipv4.ip_forward=1
iptables -P FORWARD DROP

# 2. Ruch tranzytowy: akceptacja sesji aktywnych oraz nowych z LAN (10.0.0.0/24)
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o ppp0 -s 10.0.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

# 3. Maskarada na interfejsie WAN (ppp0)
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o ppp0 -j MASQUERADE

# 4. Korekta MTU/MSS dla pakietów enkapsulacji PPPoE (clamp-mss-to-pmtu)
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --clamp-mss-to-pmtu
Maskarada dla PPPoE/DHCP: Slajd przedstawia zagadnienie Maskarada dla dynamicznego adresu WAN w ramach tematu Maskarada dla PPPoE/DHCP na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
MASQUERADE na PPPoE
28/50
Interakcja NAT ze śledzeniem połączeń
Cel slajdu: Slajd omawia zagadnienie „Interakcja NAT ze śledzeniem połączeń” w kontekście: Jak NAT korzysta z conntrack?.

Jak NAT korzysta z conntrack?

Translacja NAT i podsystem conntrack stanowią nierozerwalną całość logiczną w architekturze jądra:

  • Ewaluacja tablicy NAT wyłącznie dla pierwszego pakietu: reguły w tabeli nat są sprawdzane TYLKO dla pierwszego pakietu sesji (stan NEW).
  • Zapis krotki translacji (NAT Tuple): po podjęciu decyzji o translacji conntrack zapisuje w strukturze sesji parę krotek:
    • Krotka oryginalna: (src: 192.168.1.50:45000, dst: 93.184.216.34:80)
    • Krotka przetłumaczona: (src: 203.0.113.5:52000, dst: 93.184.216.34:80)
  • Automatyczna obsługa ruchu powrotnego: pakiety zwrotne (w stanie ESTABLISHED) omijają tablicę nat – translacja odwrotna zachodzi automatycznie w silniku conntrack.
  • Liczniki reguł NAT: zliczają jedynie pakiety inicjujące sesje, a nie wszystkie transmitowane dane!
Interakcja NAT ze śledzeniem połączeń: Slajd przedstawia zagadnienie Jak NAT korzysta z conntrack? w ramach tematu Interakcja NAT ze śledzeniem połączeń na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Wpis conntrack z NAT
29/50
Ograniczenia NAT – problematyczne protokoły
Cel slajdu: Slajd omawia zagadnienie „Ograniczenia NAT – problematyczne protokoły” w kontekście: Protokoły problematyczne dla NAT.

Protokoły problematyczne dla NAT

Niektóre protokoły sieciowe przesyłają informacje o adresach IP i portach wewnątrz warstwy aplikacji (Payload):

  • FTP (Active Mode, RFC 959): klient przesyła adres IP i port w komendzie PORT – serwer próbuje nawiązać połączenie z adresem prywatnym. Wymaga modułów: nf_conntrack_ftp oraz nf_nat_ftp.
  • SIP / H.323 (VoIP, RFC 3261): adresy prywatne zawarte w nagłówkach protokołu SDP. Wymaga modułów: nf_conntrack_sip oraz nf_nat_sip.
  • IPsec (AH / ESP, RFC 4302 / RFC 4303):
    • Protokół AH podpisuje kryptograficznie cały pakiet wraz z nagłówkiem IP – zmiana adresu przez NAT natychmiast niszczy podpis.
    • ESP szyfruje porty L4 – brak możliwości translacji PAT. Rozwiązanie: enkapsulacja UDP (NAT-Traversal / NAT-T, port UDP 4500, RFC 3948).
  • Bramy warstwy aplikacji (ALG): parsowanie i dynamiczne przepisywanie payloadu przez jądro.
Ograniczenia NAT – problematyczne protokoły: Slajd przedstawia zagadnienie Protokoły problematyczne dla NAT w ramach tematu Ograniczenia NAT – problematyczne protokoły na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Problemy NAT
30/50
NAT a IPv6 – czy NAT jest potrzebny?
Cel slajdu: Slajd omawia zagadnienie „NAT a IPv6 – czy NAT jest potrzebny?” w kontekście: NAT w IPv6 – miejsce i czas.

NAT w IPv6 – miejsce i czas

W architekturze protokołu IPv6 podejście do translacji adresów uległo zasadniczej redefinicji:

  • Ogromna przestrzeń adresowa (128 bitów): każdy host może posiadać globalnie routowalny adres publiczny (Global Unicast Address – GUA); brak konieczności oszczędzania adresów.
  • Przywrócenie łączności End-to-End: powrót do pierwotnej filozofii architektury Internetu – bezpośrednia komunikacja między urządzeniami.
  • NPTv6 (Network Prefix Translation, RFC 6296): bezstanowa translacja prefiksu sieciowego 1:1; zachowuje identyfikator hosta (Interface ID) bez konieczności śledzenia stanów w conntrack (użyteczna przy multihomingu).
  • NAT64 / DNS64 (RFC 6146): technologia przejściowa umożliwiająca hostom posiadającym wyłącznie adresację IPv6 komunikację z serwerami dostępnymi tylko w IPv4.
  • Kluczowa zasada: brak NAT w IPv6 NIE oznacza braku zapory! Polityka domyślna DROP w łańcuchu FORWARD pozostaje bezwzględnym wymogiem bezpieczeństwa.
NAT a IPv6 – czy NAT jest potrzebny?: Slajd przedstawia zagadnienie NAT w IPv6 – miejsce i czas w ramach tematu NAT a IPv6 – czy NAT jest potrzebny? na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
IPv6 vs NAT
31/50
DNAT – Destination NAT
Cel slajdu: Slajd omawia zagadnienie „DNAT – Destination NAT” w kontekście: DNAT – zmiana docelowego adresu pakietu.

DNAT – zmiana docelowego adresu pakietu

Translacja adresu docelowego (DNAT) służy do przekazywania ruchu przychodzącego z zewnątrz do serwerów ukrytych w sieci prywatnej:

# Składnia iptables dla translacji portu HTTP (80) na wewnętrzny serwer LAN
iptables -t nat -A PREROUTING -d 203.0.113.5 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# nftables – najpierw tabela i łańcuch typu nat, potem reguła DNAT
nft add table ip nat_translacja
nft add chain ip nat_translacja prerouting { type nat hook prerouting priority -100 \; }
nft add rule ip nat_translacja prerouting ip daddr 203.0.113.5 tcp dport 80 dnat to 192.168.1.10:80
  • Lokalizacja w stosie: wyłącznie łańcuch PREROUTING w tabeli nat (oraz łańcuch OUTPUT dla pakietów generowanych przez lokalne procesy routera).
  • Wpływ na routing: zmiana adresu docelowego zachodzi przed wyborem trasy (Routing Decision).
  • Zastosowanie: publikacja serwerów WWW, poczty, DNS, baz danych oraz bram VPN zlokalizowanych w podsieciach LAN i strefach DMZ.
DNAT – Destination NAT: Slajd przedstawia zagadnienie DNAT – zmiana docelowego adresu pakietu w ramach tematu DNAT – Destination NAT na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat DNAT
32/50
Przekierowanie portów
Cel slajdu: Slajd omawia zagadnienie „Przekierowanie portów” w kontekście: Przekierowanie portów.

Przekierowanie portów

Przekierowanie portów (Port Forwarding) to wyspecjalizowana forma DNAT z jednoczesną translacją numeru portu warstwy transportowej:

# Przekierowanie niestandardowego portu zewnętrznego 8080 na port 80 serwera
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.10:80

# Przekierowanie portu SSH (2222 na port 22 wybranej maszyny w LAN)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.1.50:22

# nftables – przekierowanie z translacją portu (tabela i łańcuch jak powyżej)
nft add rule ip nat_translacja prerouting iifname "eth0" tcp dport 8080 dnat to 192.168.1.10:80
  • Zastosowanie: ukrywanie standardowych numerów portów usług, unikanie konfliktów portów przy wielu serwerach, udostępnianie paneli zarządzających.
  • Rygor interfejsu (-i eth0): zapobiega przechwytywaniu ruchu generowanego wewnątrz sieci lokalnej.
Przekierowanie portów: Slajd przedstawia zagadnienie Przekierowanie portów w ramach tematu Przekierowanie portów na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Schemat port forwardingu
33/50
DNAT wymaga reguł FORWARD
Cel slajdu: Slajd omawia zagadnienie „DNAT wymaga reguł FORWARD” w kontekście: Kompletna konfiguracja DNAT.

Kompletna konfiguracja DNAT

Samo dodanie reguły w tabeli nat jest niewystarczające – pakiet po translacji musi zostać jawnie zaakceptowany w łańcuchu FORWARD:

# Krok 1: Włączenie przekazywania pakietów w systemie
sysctl -w net.ipv4.ip_forward=1

# Krok 2: Domyślna polityka blokowania ruchu tranzytowego
iptables -P FORWARD DROP

# Krok 3: Zezwolenie na pakiety powrotne nawiązanych sesji
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Krok 4: DNAT w tabeli nat (modyfikacja celu na PREROUTING)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# Krok 5: FORWARD w tabeli filter – cel to adres PRYWATNY serwera!
iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.10 --dport 80 -m conntrack --ctstate NEW -j ACCEPT
DNAT wymaga reguł FORWARD: Slajd przedstawia zagadnienie Kompletna konfiguracja DNAT w ramach tematu DNAT wymaga reguł FORWARD na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
DNAT + FORWARD
34/50
Przekierowanie portów – wiele serwerów
Cel slajdu: Slajd omawia zagadnienie „Przekierowanie portów – wiele serwerów” w kontekście: Wiele usług na różnych serwerach.

Wiele usług na różnych serwerach

Wdrożenie publikacji wielu zróżnicowanych usług za pojedynczym publicznym adresem IP (203.0.113.5):

# Serwer WWW (HTTP 80 i HTTPS 443) -> 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.10:443

# Serwer poczty elektronicznej (SMTP 25, IMAPS 993) -> 192.168.1.20
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.1.20:25
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 993 -j DNAT --to-destination 192.168.1.20:993

# Brama VPN WireGuard (UDP 51820) -> 192.168.1.30
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 -j DNAT --to-destination 192.168.1.30:51820

# Reguły FORWARD autoryzujące ruch do strefy serwerowej DMZ
iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.10 -m multiport --dports 80,443 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.20 -m multiport --dports 25,993 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p udp -d 192.168.1.30 --dport 51820 -j ACCEPT
Przekierowanie portów – wiele serwerów: Slajd przedstawia zagadnienie Wiele usług na różnych serwerach w ramach tematu Przekierowanie portów – wiele serwerów na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Wiele serwerów
35/50
DNAT a adres źródłowy klienta
Cel slajdu: Slajd porządkuje literaturę przedmiotu oraz wskazuje obowiązujące normy techniczne i przepisy stanowiące podstawę wykładu.

Serwer widzi adres klienta – ruch musi wracać przez router

Mechanizm DNAT zachowuje oryginalny adres klienta, co niesie istotne konsekwencje dla routingu powrotnego:

  • Zachowanie adresu nadawcy: router modyfikuje wyłącznie pole adresu docelowego (oraz port docelowy); publiczny adres źródłowy klienta z Internetu pozostaje nietknięty.
  • Wymóg bramy domyślnej (Default Gateway): serwer wewnętrzny musi przesyłać pakiety powrotne przez ten sam router, który wykonał translację DNAT!
  • Zagrożenie asymetrią routingu: jeśli serwer wyśle odpowiedź bezpośrednio inną bramą, klient odrzuci pakiet (oczekiwał odpowiedzi z publicznego adresu routera, a otrzymał z innego IP).
  • Znaczenie dla logów i bezpieczeństwa: serwer wewnętrzny rejestruje w logach autentyczny adres IP klienta (niezbędne dla audytu, geolokalizacji i systemów Fail2ban).
DNAT a adres źródłowy klienta: Slajd przedstawia zagadnienie Serwer widzi adres klienta – ruch musi wracać przez router w ramach tematu DNAT a adres źródłowy klienta na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Problem adresu źródłowego
36/50
NAT reflection – SNAT dla ruchu DNAT
Cel slajdu: Slajd omawia zagadnienie „NAT reflection – SNAT dla ruchu DNAT” w kontekście: NAT reflection (hairpin NAT).

NAT reflection (hairpin NAT)

Zjawisko Hairpin NAT występuje, gdy stacja z sieci lokalnej łączy się z serwerem w tej samej sieci przez jego adres publiczny:

# 1. Standardowy DNAT dla portu WWW
iptables -t nat -A PREROUTING -d 203.0.113.5 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# 2. Translacja Hairpin NAT (SNAT): podmieniamy źródło na adres routera w LAN!
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -p tcp --dport 80 -j MASQUERADE
  • Problem bez Hairpin NAT: klient 192.168.1.50 wysyła zapytanie na publiczny IP routera. Router robi DNAT na 192.168.1.10. Serwer odpowiada BEZPOŚREDNIO w warstwie L2 na lokalny adres klienta. Klient odrzuca odpowiedź, gdyż czekał na pakiet od publicznego IP!
  • Rozwiązanie: wymuszenie powrotu przez router za pomocą dodatkowej translacji SNAT/MASQUERADE w łańcuchu POSTROUTING.
NAT reflection – SNAT dla ruchu DNAT: Slajd przedstawia zagadnienie NAT reflection (hairpin NAT) w ramach tematu NAT reflection – SNAT dla ruchu DNAT na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
NAT reflection
37/50
Przekierowanie portów – zakresy i protokoły
Cel slajdu: Slajd omawia zagadnienie „Przekierowanie portów – zakresy i protokoły” w kontekście: Zaawansowane przekierowanie portów.

Zaawansowane przekierowanie portów

Zaawansowane techniki translacji DNAT dla zakresów portów ciągłych, wielu protokołów i trybu 1:1 NAT:

# Przekierowanie zakresu portów ciągłych (np. protokoły gier lub VoIP RTP: 27015-27030)
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 27015:27030 -j DNAT --to-destination 192.168.1.50

# Translacja statyczna 1:1 NAT (tzw. DMZ Host – przekierowanie całego ruchu na jeden serwer)
iptables -t nat -A PREROUTING -i eth0 -d 203.0.113.5 -j DNAT --to-destination 192.168.1.100

# Przekierowanie usługi dualnej (TCP i UDP na porcie 53 dla serwera DNS w DMZ)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.10:53
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to-destination 192.168.1.10:53

# Odpowiednia reguła FORWARD dla zakresu portów
iptables -A FORWARD -i eth0 -o eth1 -p udp -d 192.168.1.50 --dport 27015:27030 -j ACCEPT
Przekierowanie portów – zakresy i protokoły: Slajd przedstawia zagadnienie Zaawansowane przekierowanie portów w ramach tematu Przekierowanie portów – zakresy i protokoły na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Zakresy portów
38/50
Podsumowanie DNAT i port forwardingu
Cel slajdu: Slajd omawia zagadnienie „Podsumowanie DNAT i port forwardingu” w kontekście: Zastosowania DNAT.

Zastosowania DNAT

Podsumowanie wzorców projektowych i zastosowań translacji docelowej:

  • Publikacja usług: bezpieczne udostępnianie serwerów WWW, poczty, DNS oraz baz danych bez konieczności przydzielania im publicznych adresów IP.
  • Zdalny dostęp administracyjny: wystawianie usług SSH lub RDP na nietypowych portach zewnętrznych z translacją na standardowe porty wewnętrzne.
  • Konsolidacja adresacji: obsługa wielu niezależnych maszyn fizycznych i kontenerów pod pojedynczym adresem publicznym.
  • Równoważenie obciążenia (Load Balancing): rozkładanie ruchu metodą Round-Robin za pomocą modułu statystycznego Netfilter: 
    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
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.11:80
  • Złota formuła DNAT: PREROUTING (DNAT) + FORWARD (ACCEPT) + ip_forward=1.
Podsumowanie DNAT i port forwardingu: Slajd przedstawia zagadnienie Zastosowania DNAT w ramach tematu Podsumowanie DNAT i port forwardingu na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Zastosowania DNAT
39/50
Lab – krok 1: Włączenie ip_forward
Cel slajdu: Slajd omawia zagadnienie „Lab – krok 1: Włączenie ip_forward” w kontekście: Krok 1: Włączenie routingu IP.

Krok 1: Włączenie routingu IP

Domyślnie jądro systemu Linux działa w trybie stacji roboczej (host) i nie przekazuje pakietów obcych między interfejsami:

# Tymczasowe włączenie w pamięci jądra (działa natychmiast do restartu)
sysctl -w net.ipv4.ip_forward=1

# Trwała konfiguracja w plikach systemowych (zalecany katalog /etc/sysctl.d/)
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-ipforward.conf
sysctl --system

# Opcjonalnie: włączenie przekazywania pakietów dla protokołu IPv6
echo "net.ipv6.conf.all.forwarding = 1" >> /etc/sysctl.d/99-ipforward.conf
sysctl --system

# Weryfikacja bieżącego stanu parametru w jądrze
sysctl net.ipv4.ip_forward
# Wynik oczekiwany: net.ipv4.ip_forward = 1
Lab – krok 1: Włączenie ip_forward: Włączenie ip_forward: Slajd przedstawia zagadnienie Krok 1: Włączenie routingu IP w ramach tematu Lab – krok 1: Włączenie ip_forward na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
ip_forward
40/50
Lab – krok 2: Przegląd reguł iptables
Cel slajdu: Slajd omawia zagadnienie „Lab – krok 2: Przegląd reguł iptables” w kontekście: Podgląd reguł firewalla.

Podgląd reguł firewalla

Przed przystąpieniem do wprowadzania zmian konfiguracyjnych należy przeprowadzić audyt istniejących reguł:

# Numeryczny podgląd reguł tabeli filter z licznikami pakietów i bajtów
iptables -nL -v

# Podgląd reguł w tabeli translacji adresów nat
iptables -t nat -L -n -v

# Wyświetlenie reguł z numeracją wierszy (niezbędne do selektywnego usuwania -D)
iptables -L INPUT -n -v --line-numbers

# Zrzut reguł i polityk domyślnych w formacie odtwarzalnym
iptables -S

# Zrzut konfiguracji w formacie narzędzia iptables-save
iptables-save
Lab – krok 2: Przegląd reguł iptables: Przegląd reguł iptables: Slajd przedstawia zagadnienie Podgląd reguł firewalla w ramach tematu Lab – krok 2: Przegląd reguł iptables na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
iptables -nL -v
41/50
Lab – krok 3: Wdrożenie maskarady
Cel slajdu: Slajd omawia zagadnienie „Lab – krok 3: Wdrożenie maskarady” w kontekście: Krok 3: Maskarada dla sieci lokalnej.

Krok 3: Maskarada dla sieci lokalnej

Konfiguracja translacji adresów dla stacji roboczych z podsieci LAN (192.168.1.0/24) wychodzących przez interfejs WAN eth0:

# Dodanie reguły MASQUERADE na interfejsie wyjściowym WAN
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# nftables – odpowiednik w istniejącej tabeli nat (patrz tworzenie tabeli na slajdzie SNAT)
nft add rule ip nat_translacja postrouting ip saddr 192.168.1.0/24 oifname "eth0" masquerade

# Weryfikacja reguły w tabeli nat
iptables -t nat -L POSTROUTING -n -v
  • Dyscyplina interfejsu (-o eth0): zapobiega przypadkowej translacji pakietów kierowanych do innych sieci wewnętrznych lub tuneli VPN.
  • Automatyzm: w przypadku pobrania nowego adresu IP z DHCP router natychmiast adaptuje translację bez konieczności restartu zapory.
Lab – krok 3: Wdrożenie maskarady: Wdrożenie maskarady: Slajd przedstawia zagadnienie Krok 3: Maskarada dla sieci lokalnej w ramach tematu Lab – krok 3: Wdrożenie maskarady na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Masquerada
42/50
Lab – krok 4: Przekierowanie portów na serwer WWW
Cel slajdu: Slajd omawia zagadnienie „Lab – krok 4: Przekierowanie portów na serwer WWW” w kontekście: Krok 4: Udostępnienie serwera WWW.

Krok 4: Udostępnienie serwera WWW

Publikacja wewnętrznego serwera WWW (192.168.1.10) w sieci publicznej Internet za pośrednictwem routera:

# Przekierowanie ruchu HTTP (port 80)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80

# Przekierowanie ruchu HTTPS (port 443)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.10:443

# nftables – przekierowanie portów z użyciem zbioru (tabela nat jak na slajdzie DNAT)
nft add rule ip nat_translacja prerouting iifname "eth0" tcp dport { 80, 443 } dnat to 192.168.1.10

# Weryfikacja reguł w łańcuchu PREROUTING
iptables -t nat -L PREROUTING -n -v --line-numbers
  • Transparentność: klienci z Internetu łączą się z publicznym adresem routera, a ruch trafia bezpośrednio do serwera wewnętrznego.
Lab – krok 4: Przekierowanie portów na serwer WWW: Przekierowanie portów na serwer WWW: Slajd przedstawia zagadnienie Krok 4: Udostępnienie serwera WWW w ramach tematu Lab – krok 4: Przekierowanie portów na serwer WWW na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Port forwarding
43/50
Lab – krok 5: Reguły FORWARD dla NAT
Cel slajdu: Slajd omawia zagadnienie „Lab – krok 5: Reguły FORWARD dla NAT” w kontekście: Krok 5: Reguły FORWARD dla ruchu tranzytowego.

Krok 5: Reguły FORWARD dla ruchu tranzytowego

Zabezpieczenie ruchu tranzytowego zgodnie z polityką domyślnej odmowy (Drop by Default):

# 1. Ustawienie polityki domyślnej DROP dla łańcucha tranzytowego
iptables -P FORWARD DROP

# 2. Odrzucenie pakietów uszkodzonych (INVALID)
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

# 3. Zezwolenie na ruch powrotny dla wszystkich aktywnych sesji
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 4. Zezwolenie stacjom z LAN na inicjowanie połączeń do Internetu
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

# 5. Zezwolenie na ruch z Internetu do serwera WWW po translacji DNAT
iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.10 -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
Lab – krok 5: Reguły FORWARD dla NAT: Reguły FORWARD dla NAT: Slajd przedstawia zagadnienie Krok 5: Reguły FORWARD dla ruchu tranzytowego w ramach tematu Lab – krok 5: Reguły FORWARD dla NAT na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Reguły FORWARD
44/50
Lab – podsumowanie konfiguracji
Cel slajdu: Slajd omawia zagadnienie „Lab – podsumowanie konfiguracji” w kontekście: Kompletna konfiguracja routera Linux.

Kompletna konfiguracja routera Linux

Zintegrowany, produkcyjny skrypt konfiguracyjny routera Linux z zaporą stanową i translacją NAT:

# 1. Routing jądra
sysctl -w net.ipv4.ip_forward=1

# 2. Czyszczenie i domyślne polityki DROP
iptables -F && iptables -t nat -F && iptables -t mangle -F
iptables -X && iptables -t nat -X && iptables -t mangle -X
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 -s 10.0.0.0/8 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# 4. FORWARD – ruch tranzytowy LAN i serwera WWW
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.10 -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT

# 5. NAT – maskarada WAN i przekierowanie DNAT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.10

# 6. Trwały zapis konfiguracji
mkdir -p /etc/iptables
iptables-save > /etc/iptables/rules.v4
Lab – podsumowanie konfiguracji: Slajd przedstawia zagadnienie Kompletna konfiguracja routera Linux w ramach tematu Lab – podsumowanie konfiguracji na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Kompletna konfiguracja
45/50
Rozwiązywanie problemów – zapomniane zapisanie reguł
Cel slajdu: Slajd omawia zagadnienie „Rozwiązywanie problemów – zapomniane zapisanie reguł” w kontekście: Najczęstsze błędy i problemy.

Najczęstsze błędy i problemy

Typowe błędy popełniane podczas wdrażania zapór sieciowych i metody ich unikania:

  • Utrata reguł po restarcie: reguły wpisane w CLI znikają po ponownym uruchomieniu serwera. Rozwiązanie: instalacja iptables-persistent lub włączenie nftables.service.
  • Blokada dostępu zdalnego (Self-Lockout): natychmiastowe zerwanie sesji SSH po wykonaniu iptables -P INPUT DROP bez reguły dla ESTABLISHED,RELATED i portu 22.
  • Brak przekazywania pakietów: zapora skonfigurowana poprawnie, lecz ruch nie przechodzi z powodu net.ipv4.ip_forward=0.
  • Procedura bezpiecznego testowania: 
    # Zaplanowanie automatycznego powrotu konfiguracji w razie utraty połączenia
iptables-save > /root/firewall_backup.rules
sleep 180 && iptables-restore < /root/firewall_backup.rules &
# Po pomyślnym przetestowaniu w nowej sesji zabijamy proces sleep (kill %1)
Rozwiązywanie problemów – zapomniane zapisanie reguł: Slajd przedstawia zagadnienie Najczęstsze błędy i problemy w ramach tematu Rozwiązywanie problemów – zapomniane zapisanie reguł na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Błędy firewalla
46/50
Rozwiązywanie problemów – tcpdump
Cel slajdu: Slajd omawia zagadnienie „Rozwiązywanie problemów – tcpdump” w kontekście: Debugowanie pakietów tcpdump.

Debugowanie pakietów tcpdump

Analizator tcpdump to podstawowe narzędzie inżynierskie do weryfikacji przepływu pakietów i translacji NAT:

# 1. Nasłuch na interfejsie WAN (czy pakiet w ogóle dociera do routera?)
tcpdump -i eth0 -nn port 80

# 2. Nasłuch na interfejsie LAN (czy pakiet po DNAT pojawia się w sieci lokalnej?)
tcpdump -i eth1 -nn port 80

# 3. Śledzenie ruchu z zachowaniem numeracji i bez rozwiązywania DNS (-nn)
tcpdump -i any -nn host 192.168.1.10 and tcp port 80

# 4. Zrzut do pliku pcap do szczegółowej analizy w Wireshark
tcpdump -i eth0 -nn -w /tmp/ruch_wan.pcap

# 5. Podgląd wpisu sesji w tablicy conntrack
conntrack -L -p tcp --dport 80
Rozwiązywanie problemów – tcpdump: Slajd przedstawia zagadnienie Debugowanie pakietów tcpdump w ramach tematu Rozwiązywanie problemów – tcpdump na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
tcpdump
47/50
Rozwiązywanie problemów – logowanie i debug
Cel slajdu: Slajd omawia zagadnienie „Rozwiązywanie problemów – logowanie i debug” w kontekście: Logowanie pakietów za pomocą LOG target.

Logowanie pakietów za pomocą LOG target

Rejestracja pakietów w logach jądra pozwala precyzyjnie ustalić powód odrzucenia lub przepuszczenia ruchu:

# Logowanie pakietów INVALID z ograniczeniem częstości (ochrona przed DoS)
iptables -A INPUT -m conntrack --ctstate INVALID -m limit --limit 3/min -j LOG --log-prefix "FW_INVALID: " --log-level 4

# Logowanie nieautoryzowanych prób połączeń do SSH przed ich odrzuceniem
iptables -A INPUT -p tcp --dport 22 -m limit --limit 5/min -j LOG --log-prefix "FW_SSH_DROP: "
iptables -A INPUT -p tcp --dport 22 -j DROP

# nftables – logowanie regułą natywną
nft add rule inet filter input tcp dport 22 limit rate 3/minute log prefix "NFT_SSH: "

# Bieżący podgląd logów w systemie
journalctl -k -f | grep "FW_"
Rozwiązywanie problemów – logowanie i debug: Slajd przedstawia zagadnienie Logowanie pakietów za pomocą LOG target w ramach tematu Rozwiązywanie problemów – logowanie i debug na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Logowanie
48/50
Rozwiązywanie problemów – typowe scenariusze
Cel slajdu: Slajd omawia zagadnienie „Rozwiązywanie problemów – typowe scenariusze” w kontekście: Scenariusze problemów i rozwiązania.

Scenariusze problemów i rozwiązania

Matryca najczęstszych awarii sieciowych na styku firewalla i translacji adresów:

Objaw awariiPrawdopodobna przyczynaDziałanie naprawcze
Brak Internetu ze stacji LANip_forward=0 lub brak reguły MASQUERADEWłączenie sysctl i dodanie reguły w POSTROUTING
Port Forwarding nie odpowiadaBrak reguły w łańcuchu FORWARDDodanie ACCEPT dla prywatnego IP serwera w FORWARD
Zerwanie sesji SSH w trakcie pracyBrak akceptacji ESTABLISHEDWstawienie reguły --ctstate ESTABLISHED,RELATED na początek
Konfiguracja znika po restarcieNiezapisany stan reguł w plikuWykonanie iptables-save lub nft list ruleset
Strony WWW zawieszają się (TLS)Zablokowane ICMP PMTU / brak TCPMSSDodanie reguły TCPMSS --clamp-mss-to-pmtu
LAN nie otwiera domeny serweraBrak mechanizmu Hairpin NATWdrożenie translacji zwrotnej lub Split-DNS
Rozwiązywanie problemów – typowe scenariusze: Slajd przedstawia zagadnienie Scenariusze problemów i rozwiązania w ramach tematu Rozwiązywanie problemów – typowe scenariusze na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Scenariusze problemów
49/50
Ściągawka – najważniejsze polecenia
Cel slajdu: Slajd omawia zagadnienie „Ściągawka – najważniejsze polecenia” w kontekście: Ściągawka poleceń iptables/nftables.

Ściągawka poleceń iptables/nftables

Zestawienie najważniejszych poleceń administracyjnych i diagnostycznych:

Polecenie systemoweZakres działania i cel operacyjny
iptables -nL -vPrzegląd reguł tabeli filter z licznikami pakietów i bajtów
iptables -t nat -L -n -vInspekcja reguł translacji adresów NAT (PREROUTING/POSTROUTING)
iptables-save > plikAtomowy zrzut bieżącej konfiguracji iptables do pliku
iptables-restore < plikAtomowe załadowanie reguł z pliku konfiguracyjnego do jądra
sysctl net.ipv4.ip_forwardWeryfikacja włączenia przekazywania pakietów IP w jądrze
tcpdump -i any -nn port 80Podgląd przepływu pakietów HTTP w czasie rzeczywistym
conntrack -LZrzut aktywnej tablicy śledzenia połączeń i translacji
nft list rulesetWyświetlenie kompletnego zestawu reguł w formacie nftables
iptables-translate -A ...Automatyczna translacja reguły iptables na składnię nftables
Ściągawka – najważniejsze polecenia: Slajd przedstawia zagadnienie Ściągawka poleceń iptables/nftables w ramach tematu Ściągawka – najważniejsze polecenia na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Cheat Sheet
50/50
Zakończenie – podsumowanie i praca własna
Cel slajdu: Slajd omawia zagadnienie „Zakończenie – podsumowanie i praca własna” w kontekście: Podsumowanie.

Podsumowanie

Podsumowanie kluczowych zagadnień wykładu i wytyczne do samodzielnej pracy laboratoryjnej:

  • Fundamenty architektury: framework Netfilter, 5 punktów zaczepienia (hooks) oraz kolejność tablic jądra.
  • Filtracja stanowa: moduł conntrack, eliminacja pakietów INVALID i zasada Drop by Default.
  • Translacja NAT: SNAT i MASQUERADE na POSTROUTING, DNAT na PREROUTING oraz bezwzględny wymóg asocjacji z łańcuchem FORWARD.
  • Ewolucja do nftables: rodzina inet, atomowość ładowania i zbiory haszowane O(1).

Zadania do samodzielnego wykonania:

  1. Skonfigurowanie routera Linux z dwoma interfejsami w maszynie wirtualnej.
  2. Wdrożenie polityki Drop by Default i translacji MASQUERADE dla sieci lokalnej.
  3. Publikacja serwera WWW za pomocą DNAT i rygorystycznej reguły w FORWARD.
  4. Analiza pakietów za pomocą tcpdump i weryfikacja tablicy conntrack.
  5. Przetłumaczenie konfiguracji do składni nftables i zapewnienie trwałości w systemd.
Zakończenie – podsumowanie i praca własna: Slajd przedstawia zagadnienie Podsumowanie w ramach tematu Zakończenie – podsumowanie i praca własna na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę filtrowania opisuje dokumentacja Netfilter, a mechanizm translacji adresów opisano między innymi w RFC 3022.
Podsumowanie