nftables tűzfal mesterfokon: Linux szervervédelem az iptables utáni korszakban

Bevezetés — Miért kell most váltanod nftables-re?

Ha még mindig iptables-t használsz a Linux szervereiden, itt az ideje szembenézni a valósággal: egy olyan technológiára támaszkodsz, amit az iparág hivatalosan is leírásra ítélt. A Red Hat az RHEL 9-ben deprecálta az iptables-nft és ipset csomagokat, és megerősítette, hogy az RHEL 10-ben már nem lesznek elérhetők. A Debian 10 óta az nftables az alapértelmezett tűzfal-keretrendszer, az Ubuntu 20.10-től pedig az nftables backend fut a háttérben. Még a kernel is figyelmeztet: „Warning: Deprecated Driver is detected: iptables will not be maintained in a future major release and may be disabled."

Na de itt nem csak arról van szó, hogy „cseréld le, mert régi".

Az nftables architekturálisan jobb: egységes IPv4/IPv6 kezelés, beépített set és map adatstruktúrák O(log n) keresési idővel az iptables lineáris O(n) szabályfeldolgozása helyett, atomi szabálycserék versenyhelyzet nélkül, és egy sokkal olvashatóbb szintaxis. A 2026. februári Linux kernel 6.19.5 és 6.18.15 frissítések pedig tovább javították a teljesítményt — Pablo Neira-Ayuso pipapo set backend optimalizációja gyorsabb tömeges törlést tesz lehetővé, ami különösen dinamikus blokkolási listáknál jön jól (gondolj a fail2ban integrációra).

Szóval, vágjunk bele. Ebben az útmutatóban végigmegyünk mindenen: az architektúra megértésétől a telepítésen és alapkonfiguráción át egészen a haladó funkciókig. Szó lesz DDoS-védelemről, a Docker 29 natív nftables támogatásáról, a Kubernetes kube-proxy nftables módról és a Fail2Ban integrációról is. Gyakorlati kódpéldákat és produkciós konfigurációkat is kapsz — szóval azonnal tudod alkalmazni, amit itt olvastál.

Az nftables architektúra megértése

Mielőtt bármit is konfigurálnánk, érdemes megérteni, mi is az nftables valójában. Nem egyszerűen az iptables újraírt verziója — hanem egy teljesen új csomagszűrő keretrendszer a Linux kernelben. Ez fontos különbség.

A Netfilter alrendszer és az nftables viszonya

Az nftables a Linux kernel Netfilter alrendszerére épül, amely a hálózati csomagok sorsáról dönt. A Netfilter hook-jai (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) biztosítják azokat a csatlakozási pontokat, ahol a csomagszűrés megtörténik. Az nftables egy BPF-szerű virtuális gépet használ a kernelben, amely alapvető kifejezésekből (expressions) építi fel a szűrési logikát.

Alapfogalmak: táblák, láncok és szabályok

Az nftables három szinten szervezi a tűzfalszabályokat:

• Tábla (table) — Logikai konténer, amely láncokat tartalmaz. Az iptables-szal ellentétben nincsenek előre definiált táblák — te hozod létre, amit akarsz, bármilyen névvel. Minden tábla egy címcsaládhoz (address family) tartozik: ip (IPv4), ip6 (IPv6), inet (mindkettő), arp, bridge vagy netdev.
• Lánc (chain) — Szabályok rendezett listája. A base chain egy Netfilter hook-hoz kapcsolódik (pl. input, forward, output), míg a regular chain más láncokból hívható jump/goto utasítással.
• Szabály (rule) — Feltételeket (expressions) és műveletet (verdict) definiál. Fontos különbség az iptables-hez képest: az nftables-ben egy szabályban több műveletet is végrehajthatsz, míg az iptables-ben minden egyes művelethez külön szabályt kellett írnod.

Halmazok és térképek — beépített adatstruktúrák

Őszintén szólva, az nftables egyik legjobb tulajdonsága a beépített set és map támogatás. Az iptables-ben ehhez külső eszköz (ipset) kellett, ami sosem volt igazán kényelmes.

• Set (halmaz) — IP-címek, portok vagy tartományok gyűjteménye O(1) keresési idővel. Atomikusan frissíthető, és több szabályból is hivatkozható.
• Map (térkép) — Kulcs-érték párok gyűjteménye, ahol a kulcs alapján döntés (verdict) születik. Remekül használható stateful szűrésre, rate limiting-re és routing döntésekre.
• Dinamikus set — A szabályok maguk adhatnak hozzá elemeket, automatikus lejárati idővel. Ez az alapja a dinamikus blokkolási listáknak.

Telepítés és kezdeti konfiguráció

A jó hír az, hogy a legtöbb modern Linux disztribúción az nftables már előre telepítve van. De azért nézzük meg a részleteket, mert disztribúciónként lehetnek apró eltérések.

Debian/Ubuntu rendszerek

# nftables telepítése Debian/Ubuntu rendszeren
sudo apt update
sudo apt install -y nftables

# Szolgáltatás engedélyezése és indítása
sudo systemctl enable nftables
sudo systemctl start nftables

# Verzió ellenőrzése
nft --version
# Kimenet pl.: nftables v1.1.1 (Broken Sword)

RHEL/AlmaLinux/Rocky Linux rendszerek

# nftables telepítése RHEL alapú rendszeren
sudo dnf install -y nftables

# Szolgáltatás engedélyezése és indítása
sudo systemctl enable nftables
sudo systemctl start nftables

# Fontos: ha firewalld fut, azt először le kell állítani,
# vagy együtt kell használni (firewalld nftables backenddel)
sudo systemctl stop firewalld
sudo systemctl disable firewalld

Arch Linux

# nftables telepítése Arch Linuxon
sudo pacman -S nftables

# Szolgáltatás engedélyezése
sudo systemctl enable nftables
sudo systemctl start nftables

Egy fontos megjegyzés: ha a rendszereden még fut az iptables szolgáltatás, feltétlenül állítsd le, mielőtt az nftables-t használnád. A kettő egyidejű futtatása kiszámíthatatlan viselkedéshez vezet, mivel mindkettő a Netfilter hook-okkal dolgozik. Ebből szinte biztosan probléma lesz — ne kísérletezz vele produkciós szerveren.

Produkciós szerver tűzfal — teljes konfiguráció

Na, most jön a lényeg. Az alábbi konfiguráció egy produkciós szerverre ajánlott kiindulópont, amely a default-deny elvet követi: minden bejövő forgalmat elutasítunk, kivéve amit kifejezetten engedélyezünk.

Az alap ruleset

#!/usr/sbin/nft -f
# /etc/nftables.conf — Megerősített produkciós konfiguráció
# Utoljára frissítve: 2026

# Meglévő szabályok törlése
flush ruleset

# Fő tábla létrehozása (inet = IPv4 + IPv6)
table inet filter {

    # === BEJÖVŐ FORGALOM ===
    chain input {
        type filter hook input priority 0; policy drop;

        # Állapotkövetés: létrejött és kapcsolódó kapcsolatok engedélyezése
        ct state established,related accept

        # Érvénytelen csomagok azonnali eldobása
        ct state invalid drop

        # Loopback interfész engedélyezése
        iif "lo" accept

        # ICMP engedélyezése (ping, path MTU discovery)
        ip protocol icmp icmp type {
            echo-request,
            echo-reply,
            destination-unreachable,
            time-exceeded,
            parameter-problem
        } accept

        # ICMPv6 engedélyezése (szükséges IPv6 működéshez)
        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
        } accept

        # SSH engedélyezése (egyedi port, rate limiting-gel)
        tcp dport 2222 ct state new limit rate 4/minute burst 8 packets accept

        # HTTP és HTTPS engedélyezése (webszervereknél)
        tcp dport { 80, 443 } accept

        # Minden más tiltva — opcionális naplózással
        log prefix "[nftables-drop] " flags all counter drop
    }

    # === TOVÁBBÍTOTT FORGALOM ===
    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    # === KIMENŐ FORGALOM ===
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Ez a konfiguráció néhány kulcsfontosságú biztonsági döntést tartalmaz. Érdemes kiemelni őket:

• policy drop — Minden, amit nem engedélyezünk kifejezetten, eldobásra kerül. Ez a zero-trust megközelítés alapja, és a legfontosabb dolog, amit megtanulhatsz.
• ct state invalid drop — Az érvénytelen csomagok azonnali eldobása megakadályozza a különféle state-manipulációs támadásokat.
• rate limiting az SSH-n — Percenként maximum 4 új kapcsolat, 8 csomagos burst-tel. Ez önmagában is drasztikusan csökkenti a brute force kísérletek sikerességét.
• ICMPv6 engedélyezése — Ne tiltsd le! Tudom, csábító, de az IPv6 működéséhez elengedhetetlen a neighbor discovery és a router advertisement.

Konfiguráció érvényesítése és betöltése

# Szintaxis ellenőrzése betöltés nélkül
sudo nft -c -f /etc/nftables.conf

# Konfiguráció betöltése
sudo nft -f /etc/nftables.conf

# Aktuális szabályok listázása
sudo nft list ruleset

# Egy adott lánc listázása
sudo nft list chain inet filter input

# Számlálók megjelenítése
sudo nft list counters table inet filter

Kritikus tanács (tapasztalatból mondom): ha távoli szerveren dolgozol, mindig hagyj magadnak egérutat tűzfal-módosítás előtt. Egyszer kizártam magam egy produkciós szerverből, mert nem csináltam meg ezt a lépést. Egy egyszerű megoldás a következő, ami 5 perc után visszaállítja az eredeti konfigurációt:

# Ideiglenes biztonsági háló — 5 perc múlva visszaállítja a szabályokat
echo "nft -f /etc/nftables.conf.bak" | at now + 5 minutes

# Ha minden rendben, töröld az ütemezett feladatot
atrm $(atq | awk '{print $1}')

Haladó funkciók: halmazok, térképek és mérők

Az nftables igazi ereje a haladó adatstruktúrákban rejlik. Ezek teszik lehetővé, hogy komplex szűrési logikát építs minimális szabályszámmal — és igazából ez az, amitől az nftables annyival többet tud, mint az iptables.

Nevesített halmazok (named sets)

A nevesített halmazok lehetővé teszik, hogy IP-címeket, portokat vagy tartományokat csoportosíts, és egyetlen szabályból hivatkozz rájuk:

# Megbízható IP-címek halmaza
table inet filter {
    set trusted_ips {
        type ipv4_addr
        flags interval
        elements = {
            192.168.1.0/24,
            10.0.0.0/8,
            203.0.113.50
        }
    }

    # Tiltott országok IP-tartományai (geo-IP szűrés)
    set blocked_ranges {
        type ipv4_addr
        flags interval
        auto-merge
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept

        # Tiltott tartományok azonnali eldobása
        ip saddr @blocked_ranges counter drop

        # Megbízható IP-kből mindent engedélyezünk
        ip saddr @trusted_ips accept

        # ... további szabályok ...
    }
}

Halmazelemek kezelése futásidőben:

# Elem hozzáadása
sudo nft add element inet filter trusted_ips { 198.51.100.0/24 }

# Elem törlése
sudo nft delete element inet filter trusted_ips { 198.51.100.0/24 }

# Halmaz tartalmának listázása
sudo nft list set inet filter trusted_ips

Verdict map — döntési térkép

A verdict map-ek valami olyasmit tudnak, amiért az iptables-ben hosszú szabálylistákat kellett írni. Egyetlen szabályban különböző műveleteket hajthatsz végre a kulcs értéke alapján:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Állapotkezelés verdict map-pel — egy szabály, három döntés
        ct state vmap {
            established : accept,
            related     : accept,
            invalid     : drop
        }

        iif "lo" accept

        # Portalapú verdict map
        tcp dport vmap {
            22   : jump ssh_filter,
            80   : accept,
            443  : accept,
            3306 : jump db_filter
        }
    }

    chain ssh_filter {
        # SSH rate limiting
        ct state new limit rate 4/minute burst 8 packets accept
        drop
    }

    chain db_filter {
        # Adatbázis csak belső hálózatból
        ip saddr 10.0.0.0/8 accept
        drop
    }
}

Dinamikus halmazok és mérők (meters)

A dinamikus halmazok és mérők az nftables leghatásosabb eszközei a valós idejű fenyegetésvédelemhez. A szabályok maguk hozzák létre és frissítik a halmaz elemeit, automatikus lejárati idővel. Igazából ez az, ami miatt érdemes megtanulni az nftables-t:

table inet filter {
    # Dinamikus halmaz a túl sok kapcsolatot nyitó IP-khez
    set rate_limit_exceeded {
        type ipv4_addr
        flags dynamic, timeout
        timeout 5m
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept

        # Már blokkolt IP-k azonnali eldobása
        ip saddr @rate_limit_exceeded drop

        # Percenként 10-nél több új kapcsolat = 5 perces tiltás
        tcp flags syn ct state new \
            update @rate_limit_exceeded { ip saddr limit rate over 10/minute } drop

        tcp dport { 80, 443 } accept
    }
}

Ez a mechanizmus lényegében egy automatikus, kernel szintű blokkolási lista, amely emberi beavatkozás nélkül reagál a gyanús forgalomra. A timeout 5m biztosítja, hogy a blokkolás automatikusan feloldódik 5 perc inaktivitás után. Nincs szükség kézi karbantartásra, ami egyébként valós környezetben hatalmas megkönnyebbülés.

DDoS és brute force védelem

Az nftables számos beépített mechanizmust kínál a különféle hálózati támadások ellen. Nézzük a legfontosabbakat egyenként.

SYN flood védelem Synproxy-val

A Synproxy a Netfilter beépített mechanizmusa, amely elkapja az új TCP kapcsolatokat és syncookie-k segítségével kezeli a háromutas kézfogást, anélkül hogy a conntrack erőforrásokat terhelné. Ez igazán hatékonyan véd a SYN flood támadások ellen — és meglepően egyszerű beállítani.

# Kernel paraméterek beállítása (szükséges a synproxy működéséhez)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/tcp_timestamps

# Synproxy szabály az nftables-ben
table inet filter {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;

        # Synproxy a 80-as és 443-as portra
        tcp dport { 80, 443 } tcp flags syn notrack
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop

        # Synproxy kezelés
        tcp dport { 80, 443 } ct state untracked,new synproxy mss 1460 wscale 7 timestamp sack-perm

        iif "lo" accept
        # ... további szabályok ...
    }
}

Brute force védelem IP-nkénti rate limiting-gel

Az SSH és más hitelesítési szolgáltatások elleni brute force támadások ellen a leghatékonyabb az IP-nkénti rate limiting, dinamikus halmazokkal kombinálva:

table inet filter {
    # SSH támadók dinamikus listája
    set ssh_bruteforce {
        type ipv4_addr
        flags dynamic, timeout
        timeout 15m
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept

        # Már blokkolt SSH támadók eldobása
        tcp dport 2222 ip saddr @ssh_bruteforce drop

        # 3 sikertelen kísérlet 2 percen belül = 15 perces tiltás
        tcp dport 2222 ct state new \
            update @ssh_bruteforce { ip saddr limit rate over 3/minute burst 5 packets } drop

        # Normál SSH forgalom engedélyezése
        tcp dport 2222 ct state new accept

        tcp dport { 80, 443 } accept
        log prefix "[nftables-drop] " counter drop
    }
}

Párhuzamos kapcsolatszám korlátozás

A ct count segítségével korlátozhatod az egyidejű kapcsolatok számát IP-nként. Egyszerű, de rendkívül hatásos:

# Maximális egyidejű kapcsolatok IP-nként a webszerverre
tcp dport { 80, 443 } ct count over 50 drop
tcp dport { 80, 443 } accept

# SSH: maximum 3 egyidejű kapcsolat IP-nként
tcp dport 2222 ct count over 3 reject with tcp reset

NAT és port forwarding

Az nftables teljes NAT (Network Address Translation) támogatást nyújt. Akár router/gateway konfigurációra, akár port forwarding-re van szükséged, az nftables egyszerűen kezeli mindkettőt.

Source NAT (masquerade)

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        # Belső hálózat masquerade-je a kimenő interfészen
        oifname "eth0" ip saddr 10.0.0.0/24 masquerade
    }
}

# IP forwarding engedélyezése a kernelben
# echo 1 > /proc/sys/net/ipv4/ip_forward
# Vagy permanensen: net.ipv4.ip_forward = 1 a /etc/sysctl.conf-ban

A masquerade automatikusan a kimenő interfész IP-címét használja forrás címként — ideális dinamikus IP-cím esetén (pl. DHCP, PPPoE).

Destination NAT (port forwarding)

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;

        # 8080-as port átirányítása belső webszerverre
        tcp dport 8080 dnat to 10.0.0.100:80

        # HTTPS átirányítása másik szerverre
        tcp dport 443 dnat to 10.0.0.101:443
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        oifname "eth0" masquerade
    }
}

Docker és az nftables: végre barátok

A Docker és az nftables viszonya évek óta fejfájást okoz rendszergazdáknak. Ha valaha is próbáltad a kettőt együtt használni, tudod miről beszélek. De van jó hír: 2026-ban végre komoly előrelépés történt.

Docker Engine 29 — natív nftables támogatás

A Docker Engine 29 bevezette az experimentális nftables támogatást. Ez azt jelenti, hogy a Docker végre közvetlenül nftables szabályokat hoz létre az ip docker-bridges és ip6 docker-bridges táblákban — nem kell többé az iptables kompatibilitási rétegen keresztül trükközni.

Az engedélyezéshez a /etc/docker/daemon.json-ben:

{
    "iptables": false,
    "ip6tables": false,
    "experimental": true,
    "bridge-nf-call-iptables": false
}

De azért legyünk őszinték, vannak még korlátai:

• A Swarm mód és overlay hálózatok még mindig iptables-t használnak — ez még fejlesztés alatt áll.
• Ha van iptables FORWARD chain DROP policy-d, az felülírhatja a Docker nftables szabályait. Ilyenkor vagy távolítsd el az iptables DROP policy-t, vagy adj hozzá explicit iptables szabályokat a Docker-forgalom engedélyezésére.
• A --bridge-accept-fwmark opció lehetővé teszi firewall mark-ok használatát a Docker szabályainak testreszabásakor.

Kubernetes kube-proxy nftables mód

A Kubernetes v1.21-től a kube-proxy támogatja az nftables módot az iptables alternatívájaként. A fő CNI pluginek (Calico, Cilium, Weave) szintén támogatják az nftables-t hálózati szabályzatokhoz.

A gyakorlati eredmények 2026-ban elég impresszívek: a Calico nftables-szal 20-30%-kal jobb teljesítményt nyújt nagy léptékű környezetekben az iptables-hez képest, 80-90 Gbps átvitellel és 100-200 µs késleltetéssel. Egy pénzügyi szolgáltató esettanulmánya szerint a Flannel-ről Calico nftables-re való áttérés 40%-kal csökkentette a késleltetést egy 50 csomópontos klaszterben. Ezek nem kis számok.

Fail2Ban integráció nftables-szal

Ha már használod a Fail2Ban-t (és ha nem, akkor kérdezd meg magadtól, hogy miért nem), érdemes natívan nftables-szal konfigurálni. Az alapértelmezett Fail2Ban konfiguráció iptables-t feltételez, de a 0.9.4-es verzió óta van natív nftables támogatás.

1. lépés: nftables tábla létrehozása a Fail2Ban számára

#!/usr/sbin/nft -f
# /etc/nftables/fail2ban.conf
table ip fail2ban {
    chain input {
        type filter hook input priority 100;
    }
}

A priority 100 biztosítja, hogy a Fail2Ban szabályai a fő tűzfalszabályok után futnak — így a tiltott IP-k blokkolódnak, mielőtt a fő szabálykészlethez érnének.

2. lépés: beillesztés a fő konfigurációba

# /etc/nftables.conf elején, a flush ruleset után
include "/etc/nftables/fail2ban.conf"

3. lépés: Fail2Ban beállítása nftables-hoz

# /etc/fail2ban/jail.local
[DEFAULT]
banaction = nftables-multiport
chain = input

# SSH jail
[sshd]
enabled = true
port = 2222
maxretry = 3
findtime = 600
bantime = 3600
logpath = /var/log/auth.log

# Visszaeső támadók (recidive) — hosszabb tiltás
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 86400
findtime = 86400
maxretry = 3

4. lépés: systemd integráció

# /etc/systemd/system/fail2ban.service.d/override.conf
[Unit]
Requires=nftables.service
PartOf=nftables.service

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

# Alkalmazzuk a módosítást
sudo systemctl daemon-reload
sudo systemctl restart fail2ban

Ezzel a konfigurációval, ha az nftables szolgáltatás újraindul, a Fail2Ban automatikusan újratölti a tiltási szabályait. A Fail2Ban az nftables set-eket használja a tiltott IP-k tárolására, ami azt jelenti, hogy egyetlen halmaz-hivatkozás elegendő az összes tiltás kezeléséhez. Nem kell IP-nként külön szabályt létrehozni — ez jóval hatékonyabb, mint az iptables-es megoldás volt.

Migráció iptables-ról nftables-re

Ha meglévő iptables konfigurációd van, ne aggódj — az nftables beépített eszközöket kínál a zökkenőmentes áttéréshez.

Automatikus fordítás

# Egyedi iptables szabály fordítása nftables szintaxisra
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Kimenet: nft add rule ip filter INPUT tcp dport 22 counter accept

# Teljes szabálykészlet fordítása
iptables-save | iptables-restore-translate -f /etc/nftables-migrated.conf

# IPv6 szabályok fordítása
ip6tables-save | ip6tables-restore-translate -f /etc/nftables-migrated-v6.conf

Migrációs lépések

1. Mentsd el a jelenlegi iptables szabályokat: iptables-save > /root/iptables-backup.rules
2. Fordítsd le nftables formátumba az iptables-restore-translate eszközzel
3. Ellenőrizd a generált konfigurációt — a fordítás nem mindig tökéletes, különösen összetett szabályoknál (ezt tapasztalatból mondom)
4. Teszteld staging környezetben — soha ne élesíts migrált tűzfalat ellenőrzés nélkül
5. Állítsd le az iptables szolgáltatást és indítsd el az nftables-t
6. Monitorozd a forgalmat a számlálók és naplók segítségével

Fontos: az iptables-ről nftables-re való migráció egyirányú folyamat. A két rendszer nem futhat stabilan párhuzamosan, és az iptables-nft kompatibilitási réteg nem helyettesíti a natív nftables konfigurációt. Ha egyszer váltottál, ne nézz vissza.

Produkciós best practice-ek összefoglalása

Végül álljon itt egy összefoglalás azokról a gyakorlati tanácsokról, amelyeket érdemes betartani:

• Mindig default-deny policy — Az input és forward láncokon a policy drop az alap. Csak azt engedélyezd, amire tényleg szükség van.
• Atomi frissítések — Az nft -f paranccsal töltsd be a konfigurációt, ez tranzakcionálisan alkalmazza a változtatásokat. Nincs versenyhelyzet, nincs átmeneti állapot.
• Verziókezelés — Tartsd a /etc/nftables.conf fájlt Git-ben. Minden változtatás legyen követhető és visszaállítható.
• Monitoring — Használd a számlálókat (nft list counters) az eldobott csomagok figyelésére. A naplózás (log prefix) pedig a hibakeresésben sokat segít.
• Tesztelés — Az nft -c -f szintaxis-ellenőrzéssel validáld a konfigurációt betöltés előtt. Mindig.
• Biztonsági háló távoli szervereken — Mindig legyen egy at vagy cron job, ami visszaállítja az eredeti konfigurációt. Egy pillanat figyelmetlenség elég, és kizárod magad.
• Réteges védelem — Az nftables önmagában nem elegendő. Kombináld Fail2Ban-nal, IDS/IPS rendszerrel (pl. Suricata) és felhőszintű tűzfallal (AWS Security Groups, DigitalOcean Cloud Firewall, stb.).
• Rendszeres felülvizsgálat — Havi rendszerességgel ellenőrizd a tűzfalszabályokat: vannak-e felesleges vagy elavult szabályok, megfelelőek-e a rate limit értékek.

Gyakran ismételt kérdések (GYIK)

Lehet-e egyszerre használni az iptables-t és az nftables-t?

Technikailag igen, de erősen ellenjavalt. Mindkettő a Netfilter hook-okkal dolgozik, és az egyidejű használat kiszámíthatatlan viselkedéshez vezet. Az iptables-nft kompatibilitási réteg létezik, de ne tekintsd hosszú távú megoldásnak. Válassz egyet, és maradj annál.

Hogyan befolyásolja az nftables a Docker konténerek hálózatát?

A Docker történelmileg iptables-t használt a hálózati szabályok kezeléséhez, ami nem ritkán konfliktusba került az nftables-szal. A Docker Engine 29 óta van experimentális natív nftables támogatás. Ha ezt nem használod, a legbiztosabb megoldás a Docker iptables kezelésének letiltása ("iptables": false a daemon.json-ben) és a szabályok manuális kezelése. Mindig teszteld a konténerek hálózati elérhetőségét a tűzfal módosítása után.

Az nftables tud geo-IP szűrést végezni?

Közvetlenül nem, de halmazokkal (sets) tökéletesen megoldható. Bash szkriptek vagy dedikált eszközök segítségével országspecifikus IP-tartományokat tölthetsz be nftables halmazokba, amelyeket aztán a szűrési szabályokban felhasználhatsz. Hatékonyan csökkenti a kártékony forgalmat, különösen DDoS támadások és brute force kísérletek ellen.

Mennyivel gyorsabb az nftables az iptables-nél nagy szabálykészleteknél?

Az nftables beépített set és map adatstruktúrái O(log n) vagy O(1) keresési időt biztosítanak, szemben az iptables lineáris O(n) feldolgozásával. Néhány száz szabálynál a különbség elhanyagolható, de több ezer szabálynál (ami ipari környezetben egyáltalán nem ritka) az nftables nagyságrendekkel gyorsabb. A Calico CNI plugin nftables módja 20-30%-kal jobb teljesítményt mutat nagy Kubernetes környezetekben.

Mi történik, ha az nftables szolgáltatás összeomlik?

Az nftables szabályai a kernelben élnek, nem a felhasználói térben. Ha az nft parancssori eszköz vagy az nftables systemd szolgáltatás összeomlik, a már betöltött szabályok továbbra is aktívak maradnak. A szabályok csak akkor vesznek el, ha a kernel újraindul, vagy ha valaki explicit módon törli őket (nft flush ruleset). Éppen ezért fontos, hogy a /etc/nftables.conf mindig naprakész legyen, és a systemd szolgáltatás legyen engedélyezve rendszerindításkor.