Hartowanie firewalla Linux z nftables w 2026 roku

Wprowadzenie — dlaczego nftables to fundament bezpieczeństwa sieciowego w 2026 roku

Firewall to pierwsza linia obrony każdego serwera Linux — warstwa, która decyduje, jakie pakiety mogą wejść do systemu, a jakie zostają odrzucone zanim dotrą do jakiejkolwiek usługi. W poprzednich artykułach z tej serii omówiliśmy hartowanie jądra Linux (sysctl, Seccomp, Landlock) oraz kompleksowe zabezpieczanie SSH (OpenSSH 10, kryptografia postkwantowa, FIDO2). Teraz pora na kolejną krytyczną warstwę — firewall oparty na nftables.

Dlaczego właśnie teraz? Statystyki z 2025 roku mówią same za siebie. Ponad 5530 podatności CVE dotyczących jądra Linuksa, zautomatyzowane botnety (P2PInfect, Tsunami, SSHStalker) skanujące Internet z przemysłową prędkością — serwer bez firewalla to dosłownie kwestia minut, zanim ktoś spróbuje się na niego dostać. Grupy ransomware takie jak Qilin i RansomHub zaatakowały ponad 700 organizacji w 62 krajach. Prawidłowo skonfigurowany firewall to nie opcja — to absolutna konieczność.

nftables — następca iptables — jest dziś domyślnym frameworkiem filtrowania pakietów w zasadzie we wszystkich głównych dystrybucjach: RHEL 8+, Debian 10+, Ubuntu 20.04+ i Fedora 18+. Najnowsza wersja nftables 1.1.6 (grudzień 2025) przynosi usprawnienia fuzzingu, naprawy dla architektur Big Endian i lepszą dokumentację. W tym artykule przeprowadzimy Cię przez kompletny proces hartowania firewalla — od architektury nftables, przez budowę zahartowanej konfiguracji, po ochronę przed DDoS i integrację z Fail2Ban oraz CrowdSec.

nftables vs iptables — dlaczego warto migrować

Jeśli nadal korzystasz z iptables — szczerze mówiąc, pora się pożegnać. Budowanie nowych firewalli na bazie iptables jest oficjalnie odradzane, a sam projekt pozostaje w trybie konserwacji. Ale to nie jedyny powód, żeby przesiąść się na nftables.

Kluczowe przewagi nftables

• Wydajność — iptables przetwarza reguły liniowo O(n), więc każdy pakiet musi przejść przez wszystkie reguły po kolei. nftables wykorzystuje zoptymalizowane struktury danych (tablice haszujące, drzewa), co daje wyszukiwanie w czasie O(1) lub O(log n). Przy tysiącach reguł różnica jest naprawdę drastyczna.
• Ujednolicona obsługa IPv4/IPv6 — iptables wymaga oddzielnych narzędzi (iptables dla IPv4, ip6tables dla IPv6, arptables dla ARP, ebtables dla mostów). nftables zastępuje to wszystko jednym poleceniem nft i rodziną inet.
• Atomowość zmian — iptables stosuje reguły jedna po drugiej, co tworzy okna podatności podczas przeładowania. nftables stosuje całe zestawy reguł transakcyjnie — albo wszystko się powiedzie, albo nic się nie zmieni. I to jest ogromna sprawa.
• Wbudowane zestawy i mapy — zamiast korzystać z zewnętrznego ipset, nftables ma natywne wsparcie dla zbiorów (sets), map werdyktów (verdict maps) i meterów. Dzięki temu reguły są bardziej zwięzłe i wydajne.
• Wieloakcyjność reguł — w iptables jedna reguła może mieć tylko jeden cel (-j ACCEPT, -j LOG). W nftables jedna reguła może wykonać wiele akcji jednocześnie — np. zalogować i odrzucić pakiet w tym samym kroku.
• Konfigurowalne tabele i łańcuchy — iptables ma predefiniowane tabele (filter, nat, mangle) i łańcuchy (INPUT, OUTPUT, FORWARD). nftables nie narzuca żadnych domyślnych struktur — tworzysz dokładnie to, czego potrzebujesz, nic więcej.
• Zaawansowane śledzenie — nftables oferuje natywne mechanizmy debugowania i śledzenia pakietów, które są po prostu lepsze od tego, co dawał iptables.

Porównanie w tabeli

Cecha	iptables	nftables
Przetwarzanie reguł	Liniowe O(n)	Hash/drzewo O(1)/O(log n)
IPv4 + IPv6	Oddzielne narzędzia	Jedno narzędzie (inet)
Atomowość	Reguła po regule	Transakcyjne
Zbiory IP	Zewnętrzny ipset	Natywne sets/maps
Akcje na regułę	Jedna (target)	Wiele (statements)
Tabele domyślne	Predefiniowane	Brak — pełna dowolność
Kompilacja reguł	Interpretacja w jądrze	Bytecode na VM w jądrze

Architektura nftables — tabele, łańcuchy i reguły

Zanim przejdziemy do właściwego hartowania, warto na chwilę zatrzymać się przy architekturze nftables. Zrozumienie tego, jak reguły są zorganizowane, naprawdę pomaga przy późniejszej konfiguracji.

Reguły zorganizowane są w trzy poziomy hierarchii.

Tabele (tables)

Tabela to kontener najwyższego poziomu. Każda tabela ma przypisaną rodzinę adresów:

• ip — tylko IPv4
• ip6 — tylko IPv6
• inet — IPv4 i IPv6 jednocześnie (w większości przypadków to będzie Twój wybór)
• arp — pakiety ARP
• bridge — ramki mostowe
• netdev — pakiety z konkretnego interfejsu sieciowego (świetne do wczesnego filtrowania)

Co ważne — w nftables nie istnieją żadne predefiniowane tabele. W iptables tabele filter, nat i mangle były z góry zdefiniowane, nawet jeśli ich nie używałeś. Tutaj zaczynasz od czystej karty.

Łańcuchy (chains)

Łańcuchy dzielą się na dwa typy:

• Łańcuchy bazowe (base chains) — punkty wejścia dla pakietów z podsystemu sieciowego jądra. Każdy łańcuch bazowy ma określony typ (filter, nat, route), hak (input, output, forward, prerouting, postrouting) i priorytet.
• Łańcuchy regularne (regular chains) — służą jako cele skoków (jump/goto) z innych łańcuchów. Przydają się głównie do lepszej organizacji reguł, żeby konfiguracja nie zamieniła się w jeden wielki łańcuch-potwora.

Reguły (rules)

Reguły składają się z wyrażeń dopasowujących (matching expressions) i akcji (statements). nftables kompiluje je do bytecode'u wykonywanego przez maszynę wirtualną w jądrze, co minimalizuje narzut na przetwarzanie pakietów.

Zahartowana konfiguracja nftables — strategia default-deny

No dobrze, przechodzimy do konkretów. Fundamentalną zasadą hartowania firewalla jest polityka default-deny: odrzucaj wszystko domyślnie, przepuszczaj tylko to, co jest jawnie dozwolone. Brzmi prosto, ale zdziwilibyście się, ile serwerów produkcyjnych wciąż działa z domyślnym policy accept.

Poniższa konfiguracja implementuje tę strategię kompleksowo.

Kompletny zahartowany plik /etc/nftables.conf

#!/usr/sbin/nft -f

# Wyczyść wszystkie istniejące reguły — atomowe rozpoczęcie
flush ruleset

# === GŁÓWNA TABELA FILTROWANIA ===
table inet filter {

    # --- Zbiory dla zarządzania dostępem ---

    # Zaufane adresy IP do zarządzania (SSH)
    set trusted_ssh {
        type ipv4_addr
        flags interval
        elements = {
            10.0.0.0/24,        # Sieć zarządzania
            192.168.1.0/24      # Sieć biurowa
        }
    }

    # Dynamiczna czarna lista — automatycznie dodawane IP
    set denylist {
        type ipv4_addr
        flags dynamic, timeout
        timeout 30m
    }

    # Zbiór do śledzenia prób połączeń SSH (rate limiting)
    set ssh_meter {
        type ipv4_addr
        flags dynamic, timeout
        timeout 1m
    }

    # --- Łańcuch wejściowy (INPUT) ---
    chain input {
        type filter hook input priority filter; policy drop;

        # Szybka ścieżka — pakiety z czarnej listy odrzucamy natychmiast
        ip saddr @denylist counter drop

        # Interfejs loopback — zawsze dozwolony
        iifname "lo" accept

        # Ustanowione i powiązane połączenia — przepuść
        ct state established,related accept

        # Nieprawidłowe pakiety — odrzuć
        ct state invalid counter drop

        # Ochrona przed SYN flood — akceptuj tylko prawidłowe SYN
        tcp flags syn / fin,syn,rst,ack limit rate 25/second burst 50 accept

        # ICMP IPv4 — rate-limited
        ip protocol icmp icmp type {
            echo-request,
            destination-unreachable,
            time-exceeded
        } limit rate 4/second burst 8 accept

        # ICMPv6 — wymagane dla prawidłowego działania IPv6 (NDP)
        ip6 nexthdr icmpv6 icmpv6 type {
            echo-request,
            echo-reply,
            destination-unreachable,
            packet-too-big,
            time-exceeded,
            parameter-problem,
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } limit rate 10/second accept

        # SSH — tylko z zaufanych adresów, z rate limitingiem
        tcp dport 22 ip saddr @trusted_ssh ct state new accept

        # SSH — publiczny dostęp z ograniczeniem prób (opcjonalnie)
        # tcp dport 22 ct state new \
        #     add @ssh_meter { ip saddr limit rate 3/minute burst 5 } accept

        # HTTP/HTTPS — dla serwerów WWW
        # tcp dport { 80, 443 } ct state new accept

        # Logowanie odrzuconych pakietów (z limitem żeby nie zapchać logów)
        limit rate 5/minute burst 10 log prefix "[nftables-DROP-IN] " level warn
    }

    # --- Łańcuch przekazywania (FORWARD) ---
    chain forward {
        type filter hook forward priority filter; policy drop;

        # Ustanowione/powiązane — przepuść
        ct state established,related accept

        # Nieprawidłowe — odrzuć
        ct state invalid counter drop

        # Logowanie odrzuconych
        limit rate 5/minute burst 10 log prefix "[nftables-DROP-FWD] " level warn
    }

    # --- Łańcuch wyjściowy (OUTPUT) ---
    chain output {
        type filter hook output priority filter; policy accept;

        # Interfejs loopback — dozwolony
        oifname "lo" accept

        # Ustanowione połączenia
        ct state established,related accept

        # DNS, HTTP/HTTPS, NTP — dozwolone dla serwera
        tcp dport { 53, 80, 443 } accept
        udp dport { 53, 123 } accept

        # Opcjonalnie: domyślna polityka drop dla pełnej kontroli
        # policy drop;
    }
}

# === TABELA NAT (jeśli potrzebna) ===
# table inet nat {
#     chain prerouting {
#         type nat hook prerouting priority dstnat;
#     }
#     chain postrouting {
#         type nat hook postrouting priority srcnat;
#         # Masquerade dla ruchu wychodzącego
#         # oifname "eth0" masquerade
#     }
# }

Wdrożenie konfiguracji

Zanim zastosujesz nowe reguły, zawsze je najpierw zwaliduj. Powtórzę — zawsze. Jeden literówka w nftables.conf potrafi odciąć Ci dostęp do serwera (z własnego doświadczenia wiem, że to się zdarza częściej, niż ktokolwiek chciałby przyznać).

# Walidacja bez stosowania (dry run)
sudo nft -c -f /etc/nftables.conf

# Zastosowanie reguł
sudo nft -f /etc/nftables.conf

# Włączenie nftables jako usługi systemowej
sudo systemctl enable nftables
sudo systemctl start nftables

# Weryfikacja aktywnych reguł
sudo nft list ruleset

Ważne: nftables stosuje reguły atomowo — jeśli walidacja wykryje błąd składniowy, żadna zmiana nie zostanie zastosowana. To ogromna przewaga nad iptables, gdzie błąd w środku zestawu reguł mógł zostawić serwer w kompletnie nieokreślonym stanie.

Zaawansowane funkcje nftables — zbiory, mapy i metery

Jedną z największych przewag nftables nad iptables są natywne struktury danych. Zamiast setek powtarzających się reguł, możesz używać zbiorów, map i meterów — a jądro przeszukuje je w czasie stałym. To naprawdę robi różnicę, zwłaszcza na serwerach z rozbudowanymi listami kontroli dostępu.

Zbiory (sets) — wydajne listy adresów

Zbiory pozwalają na grupowanie adresów IP, portów lub innych wartości i odwoływanie się do nich w regułach. Jądro używa tablic haszujących, więc wyszukiwanie w zbiorze 200 adresów jest tak samo szybkie jak w zbiorze 2 adresów. Tak, dobrze przeczytałeś.

# Zbiór anonimowy (inline)
tcp dport { 80, 443, 8080 } accept

# Zbiór nazwany z interwałami
set blocked_ranges {
    type ipv4_addr
    flags interval
    elements = {
        45.148.10.0/24,
        185.220.100.0/24,
        193.32.162.0/24
    }
}

# Zbiór dynamiczny z automatycznym wygasaniem
set rate_exceeded {
    type ipv4_addr
    flags dynamic, timeout
    timeout 15m
    size 65536
}

Mapy werdyktów (verdict maps)

Mapy werdyktów to jedna z moich ulubionych funkcji nftables. Pozwalają na podejmowanie różnych decyzji w oparciu o klucz — np. kierowanie ruchu na różne porty do różnych łańcuchów:

# Mapa kierująca ruch do odpowiednich łańcuchów
chain input {
    type filter hook input priority filter; policy drop;
    tcp dport vmap {
        22 : jump ssh_filter,
        80 : jump http_filter,
        443 : jump https_filter
    }
}

chain ssh_filter {
    ip saddr @trusted_ssh accept
    limit rate 3/minute burst 5 accept
    counter drop
}

chain http_filter {
    ct state new accept
}

chain https_filter {
    ct state new accept
}

Metery — zliczanie i limitowanie per-IP

Metery (dawniej nazywane dynamicznymi zbiorami) umożliwiają śledzenie aktywności poszczególnych adresów IP i podejmowanie decyzji na tej podstawie. Są szczególnie przydatne do wykrywania i blokowania nadmiernie aktywnych hostów:

# Dynamiczne blokowanie po przekroczeniu limitu połączeń
set flood_meter {
    type ipv4_addr
    flags dynamic, timeout
    timeout 5m
}

chain input {
    type filter hook input priority filter; policy drop;

    # Dodaj do czarnej listy IP, które próbują nawiązać >10 nowych
    # połączeń TCP w ciągu minuty
    tcp flags syn ct state new \
        add @flood_meter { ip saddr limit rate over 10/minute } \
        counter drop
}

Rate limiting i ochrona przed DDoS

Ataki DDoS (Distributed Denial of Service) to niestety chleb powszedni administratorów serwerów. nftables oferuje kilka mechanizmów obrony — od prostego limitowania prędkości po dynamiczne czarne listy, które automatycznie reagują na podejrzany ruch.

Limitowanie prędkości pakietów i bajtów

nftables obsługuje dwa typy limitowania (od jądra Linux 4.3):

# Limit pakietów na sekundę
limit rate 25/second burst 50 accept

# Limit bajtów na sekundę — przydatne dla ochrony przed flood
limit rate 10 mbytes/second accept

# Odwrócony limit — dopasowuje pakiety PONAD limitem
limit rate over 100/second burst 200 counter drop

Limitowanie połączeń na adres IP

Parametr ct count pozwala ograniczyć liczbę jednoczesnych połączeń z jednego adresu. To prosta, ale bardzo skuteczna metoda:

# Maksymalnie 5 jednoczesnych połączeń HTTP z jednego IP
tcp dport { 80, 443 } ct state new \
    ct count over 5 counter reject with tcp reset

# Maksymalnie 2 jednoczesne połączenia SSH z jednego IP
tcp dport 22 ct state new \
    ct count over 2 counter drop

Dynamiczna czarna lista z automatycznym wygasaniem

To jeden z najpotężniejszych mechanizmów nftables — i szczerze mówiąc, sam z niego korzystam na każdym serwerze, którym zarządzam. Automatyczne blokowanie agresywnych adresów IP z czasowym wygasaniem:

set auto_denylist {
    type ipv4_addr
    flags dynamic, timeout
    timeout 30m
    size 131072
}

chain input {
    type filter hook input priority filter; policy drop;

    # Natychmiast odrzucaj pakiety z czarnej listy
    ip saddr @auto_denylist counter drop

    # Automatycznie dodaj do czarnej listy IP generujące
    # ponad 50 nowych połączeń w ciągu 10 sekund
    tcp flags syn ct state new \
        meter flood_detect { ip saddr limit rate over 50/second } \
        add @auto_denylist { ip saddr } \
        counter drop
}

Ochrona przed SYN flood

Atak SYN flood polega na zalewaniu serwera pakietami SYN bez dokończenia uzgadniania TCP (three-way handshake). To jeden z najstarszych ataków sieciowych, ale wciąż skuteczny, jeśli serwer nie jest odpowiednio zabezpieczony. nftables w połączeniu z parametrami sysctl oferuje solidną ochronę:

# W /etc/sysctl.d/99-hardening.conf
# net.ipv4.tcp_syncookies = 1   (włączone w hartowaniu jądra)
# net.ipv4.tcp_max_syn_backlog = 4096
# net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30

# Reguła nftables — limit nowych połączeń SYN
tcp flags syn / fin,syn,rst,ack limit rate 200/second burst 300 accept
tcp flags syn / fin,syn,rst,ack counter drop

Ochrona przed skanowaniem portów

Skanowanie portów to typowy etap rozpoznania przed atakiem — taki „pukanie do drzwi", żeby sprawdzić, co jest otwarte. Możemy utrudnić to za pomocą nftables:

set port_scanners {
    type ipv4_addr
    flags dynamic, timeout
    timeout 1h
}

# Wykrywaj próby połączenia na nietypowe porty
tcp dport != { 22, 80, 443 } ct state new \
    add @port_scanners { ip saddr limit rate over 10/minute } \
    counter drop

# Blokuj wykryte skanery
ip saddr @port_scanners counter drop

Integracja nftables z Fail2Ban

Fail2Ban to chyba najpopularniejszy system prewencji intruzów w świecie Linuksa. Monitoruje logi systemowe i automatycznie blokuje adresy IP po wykryciu podejrzanej aktywności — na przykład wielokrotnych nieudanych prób logowania. Integracja z nftables jest całkiem prosta.

Krok 1: Utwórz tabelę nftables dla Fail2Ban

sudo mkdir -p /etc/nftables
cat << 'EOF' | sudo tee /etc/nftables/fail2ban.conf
#!/usr/sbin/nft -f
table ip fail2ban {
    chain input {
        type filter hook input priority filter - 1; policy accept;
    }
}
EOF

Kluczowy szczegół: priorytet filter - 1 oznacza, że łańcuch Fail2Ban będzie przetwarzany przed głównym łańcuchem filtrowania. Dzięki temu zablokowane adresy nigdy nie dotrą do właściwych reguł — są odrzucane wcześniej.

Krok 2: Dołącz konfigurację do głównego pliku

W pliku /etc/nftables.conf, zaraz po flush ruleset, dodaj:

include "/etc/nftables/fail2ban.conf"

Krok 3: Skonfiguruj Fail2Ban do użycia nftables

Utwórz plik /etc/fail2ban/jail.local:

[DEFAULT]
# Używaj nftables zamiast iptables
banaction = nftables-multiport
chain = input

# Konfiguracja czasów blokowania
bantime = 24h
findtime = 600
maxretry = 3

# Progresywne wydłużanie banu dla recydywistów
bantime.increment = true
bantime.multipliers = 1 5 30 60 144 432 1296

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
maxretry = 3
bantime = 24h

[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 9w
findtime = 3d
maxretry = 3
protocol = 0-255

Krok 4: Skonfiguruj akcję nftables

Utwórz plik /etc/fail2ban/action.d/nftables-common.local:

[Init]
nftables_family = ip
nftables_table = fail2ban
blocktype = drop
nftables_set_prefix =

Krok 5: Powiąż usługi przez systemd

Upewnij się, że Fail2Ban restartuje się razem z nftables. Bez tego powiązania, po restarcie nftables reguły Fail2Ban mogą zniknąć:

sudo mkdir -p /etc/systemd/system/fail2ban.service.d
cat << 'EOF' | sudo tee /etc/systemd/system/fail2ban.service.d/override.conf
[Unit]
Requires=nftables.service
PartOf=nftables.service

[Install]
WantedBy=multi-user.target nftables.service
EOF

sudo systemctl daemon-reload
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Weryfikacja integracji

# Sprawdź, czy Fail2Ban utworzył swoje reguły
sudo nft list table ip fail2ban

# Sprawdź aktywne bany
sudo fail2ban-client status sshd

# Testowy ban (ostrożnie — nie zablokuj się!)
sudo fail2ban-client set sshd banip 192.168.99.99
sudo nft list table ip fail2ban
sudo fail2ban-client set sshd unbanip 192.168.99.99

Integracja z CrowdSec — kolaboratywna ochrona

CrowdSec to nowoczesna, open-source'owa alternatywa (i uzupełnienie) dla Fail2Ban. Kluczowa różnica? CrowdSec korzysta z kolaboratywnej bazy danych złośliwych adresów IP. Gdy jeden użytkownik wykryje atak, informacja trafia do wszystkich pozostałych uczestników sieci. To taki kolektywny system immunologiczny — im więcej osób go używa, tym lepiej działa.

Instalacja CrowdSec z bouncerem nftables

# Dodaj repozytorium CrowdSec (Debian/Ubuntu)
curl -s https://install.crowdsec.net | sudo sh

# Zainstaluj CrowdSec i bouncer nftables
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables -y

# Włącz usługi
sudo systemctl enable crowdsec
sudo systemctl enable crowdsec-firewall-bouncer
sudo systemctl start crowdsec
sudo systemctl start crowdsec-firewall-bouncer

Dodaj kolekcje scenariuszy ochrony

# Podstawowa kolekcja Linux (SSH brute-force, skanowanie portów)
sudo cscli collections install crowdsecurity/linux

# Dodatkowe scenariusze
sudo cscli scenarios install crowdsecurity/ssh-bf
sudo cscli scenarios install crowdsecurity/http-probing
sudo cscli scenarios install crowdsecurity/http-crawl-non_statics

# Przeładuj CrowdSec
sudo systemctl reload crowdsec

Monitorowanie CrowdSec

# Aktywne decyzje (zablokowane IP)
sudo cscli decisions list

# Metryki i statystyki
sudo cscli metrics

# Ostatnie alerty
sudo cscli alerts list

# Sprawdź reguły nftables utworzone przez bouncer
sudo nft list table ip crowdsec
sudo nft list table ip6 crowdsec

CrowdSec tworzy osobne tabele nftables (ip crowdsec i ip6 crowdsec) ze zbiorami zawierającymi zablokowane adresy. Operacje na zbiorach są porcjowane (domyślnie po 200 elementów) i deduplikowane, co zapewnia dobrą wydajność nawet przy dużych listach blokujących.

Geoblokowanie — ograniczanie ruchu według kraju

Geoblokowanie to dodatkowa warstwa ochrony, która pozwala ograniczyć ruch przychodzący do adresów IP przypisanych do konkretnych krajów. Jeśli Twój serwer obsługuje wyłącznie użytkowników z Polski i Europy, blokowanie ruchu z krajów o dużej aktywności botów może znacząco zmniejszyć powierzchnię ataku.

Czy to rozwiązanie idealne? Nie. Ale zmniejsza szum i odciąża pozostałe warstwy ochrony.

Geoblokowanie za pomocą nft-geo-filter

# Pobierz nft-geo-filter
git clone https://github.com/rpthms/nft-geo-filter.git
cd nft-geo-filter

# Zezwalaj tylko na ruch z wybranych krajów
# (PL, DE, FR, GB, NL, CZ, SK — Polska i sąsiedzi)
sudo python3 nft-geo-filter.py \
    --allow \
    -f inet \
    -i eth0 \
    PL DE FR GB NL CZ SK AT

# Skrypt tworzy osobną tabelę nftables — nie koliduje
# z istniejącą konfiguracją

Wyjątki i automatyzacja

# Dodaj wyjątki dla konkretnych adresów IP (np. CDN, monitoring)
sudo python3 nft-geo-filter.py \
    --allow \
    --exceptions "1.1.1.1,8.8.8.8,208.67.222.222" \
    -f inet \
    -i eth0 \
    PL DE FR GB NL CZ SK AT

# Automatyczna aktualizacja list IP — dodaj do crona
echo "0 3 * * 0 root /opt/nft-geo-filter/nft-geo-filter.py --allow -f inet -i eth0 PL DE FR GB NL CZ SK AT" \
    | sudo tee /etc/cron.d/nft-geo-update

Uwaga: Geoblokowanie nie jest panaceum. Atakujący mogą używać VPN-ów, serwerów proxy lub skompromitowanych maszyn w dozwolonych krajach. Traktuj je jako dodatkową warstwę, nie jedyną linię obrony.

Migracja z iptables na nftables — krok po kroku

Jeśli Twój serwer wciąż używa iptables, migracja do nftables nie musi być rewolucją. Istnieją narzędzia, które znacząco ją ułatwiają, a cały proces można przeprowadzić bez utraty połączenia (o ile zachowasz ostrożność).

Etap 1: Audyt istniejących reguł

# Eksportuj aktualne reguły iptables
sudo iptables-save > /root/iptables-backup-$(date +%Y%m%d).rules
sudo ip6tables-save > /root/ip6tables-backup-$(date +%Y%m%d).rules

# Sprawdź, ile reguł masz
sudo iptables -L -n --line-numbers | wc -l
sudo ip6tables -L -n --line-numbers | wc -l

Etap 2: Automatyczne tłumaczenie reguł

nftables dostarcza narzędzia do automatycznego tłumaczenia reguł iptables. Nie jest idealne (czasem generuje trochę rozwlekły kod), ale daje solidny punkt wyjścia:

# Tłumaczenie pojedynczej reguły
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Wynik: nft add rule ip filter INPUT tcp dport 22 counter accept

# Tłumaczenie całego zestawu reguł
iptables-restore-translate -f /root/iptables-backup.rules > /root/nftables-translated.nft

# Przejrzyj przetłumaczone reguły
cat /root/nftables-translated.nft

Etap 3: Warstwa kompatybilności

Jeśli korzystasz z oprogramowania, które nadal wymaga interfejsu iptables (np. starsze wersje Dockera), możesz użyć warstwy kompatybilności iptables-nft. Działa to tak, że komendy iptables pod spodem korzystają z backendu nftables:

# Sprawdź, czy iptables używa backendu nftables
iptables -V
# Wynik powinien zawierać "nf_tables"

# Jeśli nie, przełącz na backend nftables
sudo update-alternatives --set iptables /usr/sbin/iptables-nft
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

Etap 4: Testowanie i wdrożenie

# 1. Przetestuj na środowisku staging
sudo nft -c -f /etc/nftables.conf

# 2. Zastosuj i monitoruj
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

# 3. Wyłącz stary iptables
sudo systemctl stop iptables
sudo systemctl disable iptables

# 4. Włącz nftables
sudo systemctl enable nftables
sudo systemctl start nftables

# 5. Monitoruj logi przez 24-48 godzin
sudo journalctl -k --grep="nftables" -f

Wskazówka: Podczas migracji możesz tymczasowo uruchomić oba systemy równolegle (iptables-nft na backendzie nftables). Ale docelowo używaj wyłącznie natywnego nftables — mieszanie dwóch systemów prowadzi do nieprzewidywalnych zachowań i jest po prostu trudne w utrzymaniu.

Logowanie i monitorowanie aktywności firewalla

Firewall bez monitoringu to firewall, o którym nie wiesz, czy działa. Brzmi banalnie, ale widziałem serwery, na których nftables był włączony z domyślną konfiguracją i nikt przez miesiące nie sprawdził, czy reguły w ogóle coś filtrują.

Konfiguracja logowania

# Logowanie odrzuconych pakietów wejściowych
chain input {
    type filter hook input priority filter; policy drop;

    # ... reguły akceptujące ...

    # Loguj odrzucone pakiety TCP z prefiksem
    ip protocol tcp counter log prefix "[nft-drop-tcp-in] " level warn
    ip protocol udp counter log prefix "[nft-drop-udp-in] " level warn

    # Loguj pozostałe odrzucone pakiety
    counter log prefix "[nft-drop-other-in] " level warn
}

Monitorowanie w czasie rzeczywistym

# Obserwuj logi firewalla w czasie rzeczywistym
sudo journalctl -k --grep="nft-drop" -f

# Statystyki liczników
sudo nft list counters

# Wyświetl reguły z licznikami pakietów/bajtów
sudo nft list ruleset -a

# Sprawdź zawartość dynamicznych zbiorów
sudo nft list set inet filter denylist
sudo nft list set inet filter auto_denylist

Integracja z rsyslog

Dla bardziej zaawansowanego zarządzania logami warto przekierować logi nftables do osobnego pliku. Ułatwia to analizę i nie zaśmieca głównych logów systemowych:

# /etc/rsyslog.d/10-nftables.conf
:msg, contains, "[nft-drop" /var/log/nftables.log
& stop

# Logrotate — /etc/logrotate.d/nftables
/var/log/nftables.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
}

Najczęstsze polecenia nftables — ściągawka

Na zakończenie — zwięzła ściągawka poleceń, z których będziesz korzystać na co dzień. Warto mieć ją pod ręką, zwłaszcza na początku przygody z nftables:

# === WYŚWIETLANIE ===
nft list ruleset                          # Wszystkie reguły
nft list tables                           # Wszystkie tabele
nft list table inet filter                # Konkretna tabela
nft list chain inet filter input          # Konkretny łańcuch
nft list set inet filter denylist         # Zawartość zbioru
nft list counters                         # Wszystkie liczniki
nft list meters                           # Wszystkie metery

# === ZARZĄDZANIE REGUŁAMI ===
nft -f /etc/nftables.conf                 # Załaduj konfigurację
nft -c -f /etc/nftables.conf             # Walidacja (dry run)
nft flush ruleset                         # Wyczyść wszystkie reguły
nft flush table inet filter               # Wyczyść konkretną tabelę
nft flush chain inet filter input         # Wyczyść konkretny łańcuch

# === DYNAMICZNE ZARZĄDZANIE ZBIORAMI ===
nft add element inet filter denylist { 1.2.3.4 }           # Dodaj IP
nft add element inet filter denylist { 1.2.3.4 timeout 1h } # Dodaj z czasem
nft delete element inet filter denylist { 1.2.3.4 }        # Usuń IP
nft flush set inet filter denylist                          # Wyczyść zbiór

# === DEBUGOWANIE ===
nft monitor                               # Monitoruj zmiany w czasie rzeczywistym
nft monitor trace                          # Śledzenie pakietów

Najczęściej zadawane pytania (FAQ)

Czy nftables całkowicie zastępuje iptables?

Tak. nftables jest oficjalnym następcą iptables i zastępuje wszystkie jego warianty: iptables, ip6tables, arptables i ebtables. Wszystkie główne dystrybucje (RHEL 8+, Debian 10+, Ubuntu 20.04+, Fedora 18+) używają nftables jako domyślnego frameworka. iptables pozostaje dostępny przez warstwę kompatybilności iptables-nft, ale budowanie nowych firewalli na iptables jest po prostu odradzane.

Czy mogę używać nftables jednocześnie z UFW?

Krótko mówiąc — nie jest to zalecane. UFW działa na bazie starszych narzędzi iptables/ip6tables. Jednoczesne korzystanie z UFW i natywnych reguł nftables może prowadzić do niebezpiecznych konfiguracji i nieoczekiwanych zachowań. Wybierz jedno podejście — dla profesjonalnej administracji nftables daje znacznie większą kontrolę.

Jak sprawdzić, czy mój system używa nftables czy iptables?

Uruchom iptables -V. Jeśli wynik zawiera frazę nf_tables, Twój system używa backendu nftables (nawet jeśli komendy wyglądają jak iptables). Możesz też sprawdzić poleceniem nft list ruleset — jeśli zwraca jakikolwiek wynik, nftables jest aktywne.

Czy nftables obsługuje Deep Packet Inspection (DPI)?

Nie bezpośrednio. Funkcjonalność „string match" dostępna w iptables nie jest wspierana w nftables. Jeśli potrzebujesz DPI, rozważ integrację nftables z narzędziami takimi jak Suricata (IDS/IPS) lub CrowdSec w trybie WAF, które oferują inspekcję ruchu na warstwie 7.

Czy nftables spowalnia ruch sieciowy?

W praktyce — nie. Wpływ na wydajność jest minimalny i znacząco mniejszy niż w przypadku iptables. nftables kompiluje reguły do bytecode'u wykonywanego przez maszynę wirtualną w jądrze, a wbudowane struktury danych zapewniają wyszukiwanie w czasie stałym O(1). Nawet przy tysiącach reguł opóźnienie jest pomijalne. Dodatkowo nftables nie rejestruje nieużywanych łańcuchów — tworzysz tylko to, czego naprawdę potrzebujesz.