Az nftables egy Netfilter projekt, amelynek célja a meglévő {ip,ip6,arp,eb}tables keretrendszer leváltása. Új csomagszűrő keretrendszert, egy új felhasználói térben futó segédprogramot (nft), valamint egy kompatibilitási réteget biztosít az {ip,ip6}tables számára. A netfilter meglévő automatikus műveletindítóit (hook-jait), kapcsolatkövető rendszerét, felhasználói térbeli várólista-komponensét és naplózási alrendszerét használja.

Három fő összetevőből áll: Egy kernelimplementációból, a libnl netlink kommunikációból és az nftables felhasználói térbeli előtétprogramból. A kernel egy netlink-beállítófelületet, valamint a szabálykészlet futásidejű kiértékelését biztosítja. A libnl a kernellel történő kommunikációhoz szükséges alacsony szintű függvényeket tartalmazza, az nftables előtétprogram pedig az a komponens, amellyel a felhasználó az nft segítségével kapcsolatba lép.

További információkért látogassa meg a hivatalos nftables wiki weboldalt.

Telepítse a felhasználói térben futtatható nftables segédprogram szoftvercsomagját.

Ha Önél fel van telepítve a számítógépre az iptables-legacy szoftvercsomag, akkor telepítse az iptables szoftvercsomagot, amely automatikusan eltávolítja az iptables-legacy szoftvercsomagot, és megakadályozza az nftables szoftvercsomaggal történő összeütközéseket.

• firewalld (firewall-cmd) — Szolgáltatás és parancssoros felhasználói felülettel is rendelkezik. Hálózati és tűzfalzónák beállítására, valamint a tűzfalszabályok megadására és azok beállítására szolgál.

https://firewalld.org/ || firewalld

• nft-blackhole — Szkriptfájl / szolgáltatásfájl az IP-címek nftables rendszerben történő blokkolására, országok és feketelisták alapján.

https://github.com/tomasz-c/nft-blackhole || nft-blackhole^AUR

• ufw — Az ufw az Uncomplicated Firewall rövidítése, és egy netfilter alapú tűzfal kezelésére szolgáló program.

https://help.ubuntu.com/community/UFW || ufw

• reaction — Egy szolgáltatásfájl, amely a programok kimenetét vizsgálja ismétlődő minták után kutatva, és intézkedéseket tesz. A fail2ban könnyűsúlyú alternatívája.

https://framagit.org/ppom/reaction || reaction^AUR

Az nftables nem tesz különbséget a parancssorban létrehozott ideiglenes szabályok és a fájlból betöltött vagy fájlba mentett állandó szabályok között.

Minden szabályt az nft parancssori segédprogrammal kell létrehozni vagy betölteni a számítógép memóriájába.

A használattal kapcsolatban tekintse meg a #Beállítás című szakaszt.

A jelenlegi szabálykészlet a következőképpen jeleníthető meg:

# nft list ruleset

Az összes szabály eltávolítása, amely által a rendszer tűzfal nélkül fog maradni:

# nft flush ruleset

A szabálykészlet beolvasása a számítógép memóriájába a /etc/nftables.conf fájlból az nftables.service újraindításával történik.

Az nftables szoftvercsomag számítógépre történő feltelepítésekor egy egyszerű és biztonságos tűzfalbeállítással érkezik a számítógépre, amely a /etc/nftables.conf fájlban lesz eltárolva.

Tehát amikor az nftables.service el lesz indítva vagy engedélyezve lesz, a szabályokat az említett fájlból betölti a számítógép memóriájába.

Az nftables felhasználói térben lévő segédprogramja, az nft, a szabálykészletek nagy részének értékelését elvégzi, mielőtt a szabálykészleteket a kernelnek átadná. A szabályok láncokban vannak eltárolva, amelyek viszont táblákban vannak elhelyezve. A következő szakaszok bemutatják, hogy miként lehet létrehozni és módosítani ezeket a konstrukciókat.

A fájlból történő bemenet olvasása érdekében használja a -f/--file kapcsolót:

# nft --file fájlneve

Vegye figyelembe, hogy a már betöltött szabályok nem kerülnek automatikusan törlésre.

A teljes parancslistát megtekintheti az nft(8) man súgóban.

A táblák tulajdonképpen tárolók a #Láncok, #Készletek és egyebek számára. Kizárólag ezek névterezésére, hatókörének meghatározására és rendszerezésére szolgálnak.

Nincsenek különleges vagy varázslatos táblanevek. Általában az programok a saját nevüket viselő táblákat hozzák létre (pl. a Firewalld létrehozza a firewalld táblát és csak a firewalld táblát módosítja), ezért érdemes lehet egy manuális úton, tehát kézzel létrehozandó táblát valami általános névvel ellátni, például firewall. (Itt egy példa).

Minden tábla többféle szabályt is tartalmazhat (pl. mind filter, mind nat), de kizárólag egyetlen családba tartozó csomagokra vonatkozik az alábbiak közül:

Amennyiben Ön egy szabályt szeretne létrehozni, amely mind az IPv4 protokollra, mind az IPv6 protokollra vonatkozik, akkor használja az inet táblát. Az inet tábla lehetővé teszi az ip és az ip6 családok egyesítését, így egyszerűbbé téve a szabályok mindkettőre történő meghatározását.

Tekintse meg az nft(8) § ADDRESS FAMILIES man súgót a címcsoportok teljes leírásáért.

Táblák listázása

# nft list tables

Új tábla hozzáadása

# nft add table táblacsalád_típusa tábla_neve

Egy tábla összes láncának és szabályának listázása

# nft list table táblacsalád_neve tábla_neve

Például az inet táblacsaládba tartozó, én_táblám nevű tábláján rajtalévő összes szabály listázásához:

# nft list table inet én_táblám

Egy tábla kiürítése (láncok és szabályok)

# nft flush table táblacsalád_típusa tábla_neve

Egy tábla törlése

# nft delete table táblacsalád_típusa tábla_neve

A lánc a csomagokra alkalmazandó szabályok gyűjteménye. A csomagok balról jobbra haladnak a forgalomáramlási diagramon: Minden alkalommal, amikor egy "hook"-pontot (ingress, prerouting, input...) érnek el, az adott hookhoz társított összes "alap"-lánc feldolgozásra kerül. (Így a láncok implicit módon a hook-típusuk szerint vannak rendezve.)

A láncok különböző tulajdonságai és felhasználási módjai, valamint a kezelésük módja nagyon jól dokumentálva van a Netfilter Wikipédiájának Láncok beállítása című cikkében.

Vegye azonban figyelembe, hogy egy lánc prioritási értéke nemcsak a többi lánchoz viszonyítva határozza meg a sorrendjét, hanem a kernel egyes feldolgozási műveleteihez viszonyítva is, különösen a kapcsolatkövetés (connection tracking) esetében. Minél korábban kerül egy csomag eldobásra, annál kevesebb fölösleges munka keletkezik, ugyanakkor annál kevesebb információ áll rendelkezésre a csomagról.

A szabályok szerkezetének alapjai és a kapcsolódó parancsok a Netfilter wikijének Egyszerű szabálykezelés című cikkében vannak leírva.

A szabályok kifejezésekből állnak, amelyeket utasítások követnek.

A leggyakoribb utasítástípus a "verdict utasítások": accept, drop, queue, continue, return, jump láncneve, és goto láncneve. A verdict utasításokon kívül más utasítások is lehetségesek. Tekintse meg az nft(8) § STATEMENTS man súgót.

Az nftables programnál különböző kifejezések érhetők el, és többnyire megegyeznek az iptables megfelelőivel. A legszembetűnőbb különbség, hogy nincsenek általános vagy implicit illesztések. Az általános illesztés olyan volt, amely mindig elérhető volt, például --protocol vagy --source. Az implicit illesztések protokoll-specifikusak voltak, például --sport, amikor egy csomagról meg lett állapítva, hogy TCP.

Tekintse meg továbbá a Netfilter wiki weboldalon az Építési szabályok kifejezéseken keresztül című lapot.

Az alábbiakban a rendelkezésre álló illesztések nem teljes listája található:

• meta (Meta-tulajdonságok, pl. interfészek.)
• icmp (ICMP protokoll.)
• icmpv6 (ICMPv6 protokoll.)
• ip (IP protokoll.)
• ip6 (IPv6 protokoll.)
• tcp (TCP protokoll.)
• udp (UDP protokoll.)
• sctp (SCTP protokoll.)
• ct (Kapcsolatkövetés.)

Az alábbiakban az egyezésargumentumok nem teljes listája található. (A teljesebb lista az nft(8) man súgóban található.) :

meta:
 iif <input interface INDEX>
 oif <output interface INDEX>
 iifname <input interface NAME>
 oifname <output interface NAME>

icmp:
 type <icmp type>

icmpv6:
 type <icmpv6 type>

ip:
 protocol <protocol>
 daddr <destination address>
 saddr <source address>

ip6:
 daddr <destination address>
 saddr <source address>

tcp:
 dport <destination port>
 sport <source port>

udp:
 dport <destination port>
 sport <source port>

sctp:
 dport <destination port>
 sport <source port>

ct:
 state <new | established | related | invalid>

Bizonyos értelemben az iif és oif, illetve az iifname és oifname közötti különbség hasonló a statikus és dinamikus megközelítéshez. Vagy a programozási fogalomhoz: Definíció versus deklaráció. Vagy a korai kötés versus késleltetett kötés fogalmához. Tekintsen meg egy felhasználási esetet és további magyarázatot tartalmazó linket.

A készletek névvel ellátottak vagy névtelenek, és egy vagy több elemből állnak, vesszővel elválasztva, kapcsos zárójelek közé zárva. A névtelen készletek szabályokba vannak beágyazva, és nem frissíthetők: Önnek a szabályt törölnie kell, és újra hozzá kell adnia. Pl. Ön nem tudja egyszerűen eltávolítani a "http" protokollt a dports készletből a következőben:

# nft add rule ip6 filter input tcp dport {telnet, http, https} accept

A névvel ellátott készletek frissíthetők, valamint típusozhatók és jelölőkkel láthatók el. Az sshguard névvel ellátott készleteket használ a blokkolt gépek IP-címeihez.

table ip sshguard {
 set attackers {
 type ipv4_addr
 flags interval
 elements = { 1.2.3.4 }
 }

Az elemek készlethez történő hozzáadása érdekében vagy abból történő törlése érdekében használja a következőt:

# nft add element ip sshguard attackers { 5.6.7.8/32 }
# nft delete element ip sshguard attackers { 1.2.3.4/32 }

Vegye figyelembe, hogy az ipv4_addr típus tartalmazhat CIDR hálózati maszkot (a /32 itt nem szükséges, de a teljesség kedvéért szerepel). Vegye továbbá figyelembe, hogy az itt a TABLE ip sshguard { SET attackers } által definiált készletet ip sshguard attackers-ként lehet hivatkozni.

Az aktuális szabálykészlet ürítése:

# echo "flush ruleset" > /tmp/nftables

Az aktuális szabálykészlet kiíratása:

# nft -s list ruleset >> /tmp/nftables

Most szerkesztheti a /tmp/nftables fájlt, és a módosításokat a következővel alkalmazhatja:

# nft -f /tmp/nftables

/etc/nftables.conf

flush ruleset

table inet my_table {
	set LANv4 {
		type ipv4_addr
		flags interval

		elements = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 }
	}
	set LANv6 {
		type ipv6_addr
		flags interval

		elements = { fd00::/8, fe80::/10 }
	}

	chain my_input_lan {
		udp sport 1900 udp dport >= 1024 meta pkttype unicast limit rate 4/second burst 20 packets accept comment "Accept UPnP IGD port mapping reply"

		udp sport netbios-ns udp dport >= 1024 meta pkttype unicast accept comment "Accept Samba Workgroup browsing replies"

	}

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

		iif lo accept comment "Accept any localhost traffic"
		ct state invalid drop comment "Drop invalid connections"
		fib daddr . iif type != { local, broadcast, multicast } drop comment "Drop packets if the destination IP address is not configured on the incoming interface (strong host model)"
		ct state { established, related } accept comment "Accept traffic originated from us"

		meta l4proto { icmp, ipv6-icmp } accept comment "Accept ICMP"
		ip protocol igmp accept comment "Accept IGMP"

		udp dport mdns ip6 daddr ff02::fb accept comment "Accept mDNS"
		udp dport mdns ip daddr 224.0.0.251 accept comment "Accept mDNS"

		ip6 saddr @LANv6 jump my_input_lan comment "Connections from private IP address ranges"
		ip saddr @LANv4 jump my_input_lan comment "Connections from private IP address ranges"

		counter comment "Count any other traffic"
	}

	chain my_forward {
		type filter hook forward priority filter; policy drop;
		# Drop everything forwarded to us. We do not forward. That is routers job.
	}

	chain my_output {
		type filter hook output priority filter; policy accept;
		# Accept every outbound connection
	}

}

/etc/nftables.conf

flush ruleset

table inet my_table {
	set LANv4 {
		type ipv4_addr
		flags interval

		elements = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 }
	}
	set LANv6 {
		type ipv6_addr
		flags interval

		elements = { fd00::/8, fe80::/10 }
	}

	chain my_input_lan {
		meta l4proto { tcp, udp } th dport 2049 accept comment "Accept NFS"

		udp dport netbios-ns accept comment "Accept NetBIOS Name Service (nmbd)"
		udp dport netbios-dgm accept comment "Accept NetBIOS Datagram Service (nmbd)"
		tcp dport netbios-ssn accept comment "Accept NetBIOS Session Service (smbd)"
		tcp dport microsoft-ds accept comment "Accept Microsoft Directory Service (smbd)"

		udp sport { bootpc, 4011 } udp dport { bootps, 4011 } accept comment "Accept PXE"
		udp dport tftp accept comment "Accept TFTP"
	}

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

		iif lo accept comment "Accept any localhost traffic"
		ct state invalid drop comment "Drop invalid connections"
		fib daddr . iif type != { local, broadcast, multicast } drop comment "Drop packets if the destination IP address is not configured on the incoming interface (strong host model)"
		ct state { established, related } accept comment "Accept traffic originated from us"

		meta l4proto { icmp, ipv6-icmp } accept comment "Accept ICMP"
		ip protocol igmp accept comment "Accept IGMP"

		udp dport mdns ip6 daddr ff02::fb accept comment "Accept mDNS"
		udp dport mdns ip daddr 224.0.0.251 accept comment "Accept mDNS"

		ip6 saddr @LANv6 jump my_input_lan comment "Connections from private IP address ranges"
		ip saddr @LANv4 jump my_input_lan comment "Connections from private IP address ranges"

		tcp dport ssh accept comment "Accept SSH on port 22"

		tcp dport ipp accept comment "Accept IPP/IPPS on port 631"

		meta l4proto { tcp, udp } th dport { http, https, 8008, 8080 } accept comment "Accept HTTP (ports 80, 443, 8008, 8080)"

		udp sport bootpc udp dport bootps ip saddr 0.0.0.0 ip daddr 255.255.255.255 accept comment "Accept DHCPDISCOVER (for DHCP-Proxy)"
	}

	chain my_forward {
		type filter hook forward priority filter; policy drop;
		# Drop everything forwarded to us. We do not forward. That is routers job.
	}

	chain my_output {
		type filter hook output priority filter; policy accept;
		# Accept every outbound connection
	}

}

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

		iif lo accept comment "Accept any localhost traffic"
		ct state invalid drop comment "Drop invalid connections"
		fib daddr . iif type != { local, broadcast, multicast } drop comment "Drop packets if the destination IP address is not configured on the incoming interface (strong host model)"

		meta l4proto icmp icmp type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"
		meta l4proto ipv6-icmp icmpv6 type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"

		ct state { established, related } accept comment "Accept traffic originated from us"

		meta l4proto { icmp, ipv6-icmp } accept comment "Accept ICMP"
		ip protocol igmp accept comment "Accept IGMP"

		tcp dport ssh ct state new limit rate 15/minute accept comment "Avoid brute force on SSH"

	}

}

Az ugrások (jumps) használatakor a beállításfájlban szükséges először a cél láncot (target chain) definiálni. Ellenkező esetben Ön az Error: Could not process rule: No such file or directory hibába ütközhet.

table inet my_table {
 chain web {
 tcp dport http accept
 tcp dport 8080 accept
 }
 chain my_input {
 type filter hook input priority filter;
 ip saddr 10.0.2.0/24 jump web
 drop
 }
}

Ha az Ön számítógépén több hálózati interfész van, és különböző szabályokat szeretne használni különböző interfészekhez, akkor érdemes egy "dispatching" szűrőláncot, majd interfész-specifikus szűrőláncokat használni. Például tegyük fel, hogy az Ön számítógépe otthoni routerként működik, és egy LAN-on keresztül elérhető webszervert szeretne futtatni (interfész enp3s0), de a nyilvános internetről nem (interfész enp2s0), akkor az alábbi szerkezetet érdemes megfontolni:

table inet my_table {
 chain my_input { # this chain serves as a dispatcher
 type filter hook input priority filter; policy drop;

 iif lo accept comment "always accept loopback"
 iifname enp2s0 jump my_input_public
 iifname enp3s0 jump my_input_private
 }
 chain my_input_public { # rules applicable to public interface interface
 ct state {established,related} accept
 ct state invalid drop
 udp dport bootpc accept
 tcp dport bootpc accept
 }
 chain my_input_private {
 ct state {established,related} accept
 ct state invalid drop
 udp dport bootpc accept
 tcp dport bootpc accept
 tcp port http accept
 tcp port https accept
 reject with icmpx port-unreachable comment "all other traffic"
 }
 chain my_output { # we let everything out
 type filter hook output priority filter;
 accept
 }
}

Alternatívaként Ön választhat egyetlen iifname utasítást is, például az egyetlen upstream interfészhez, és az összes többi interfészhez tartozó alapértelmezett szabályokat egy helyen helyezheti el, ahelyett, hogy minden interfészhez külön disztribúciót (dispatchinget) használna.

Az nftables rendelkezik egy különleges masquerade (elmaszkolás) kulcsszóval ahol "a forráscím automatikusan a kimeneti interfész címére van beállítva" (source). Ez különösen hasznos olyan helyzetekben, amikor az interfész IP-címe kiszámíthatatlan vagy instabil, például a routerek upstream interfészénél, amelyek sok internetszolgáltatóhoz csatlakoznak. Enélkül a hálózati címfordítás (NAT) szabályait minden alkalommal frissíteni kellene, amikor az interfész IP-címe megváltozik.

Használatához:

• Győződjön meg arról, hogy a masquerading engedélyezve van a kernelben (ez igaz, amikor Ön az alapértelmezett kernelt használja), ellenkező esetben a kernel beállítása során állítsa be CONFIG_NFT_MASQ=m opciót.
• A masquerade kulcsszó csak nat típusú láncokban használható.
• A masquerading a forrás NAT egy típusa, ezért csak a kimeneti útvonalon működik.

Példa egy olyan számítógépre, amely két interfésszel rendelkezik: A LAN az enp3s0 interfészhez csatlakozik, a nyilvános internet pedig az enp2s0 interfészhez csatlakozik:

table inet my_nat {
 chain my_masquerade {
 type nat hook postrouting priority srcnat;
 oifname "enp2s0" masquerade
 }
}

Mivel a tábla típusa inet, ezért mind az IPv4, mind az IPv6 csomagok el lesznek maszkolva (masquerade). Ha Ön csak az IPv4 csomagokat szeretné elmaszkolni (mivel az IPv6 nagyobb címtartománya miatt a NAT nem szükséges), akkor a meta nfproto ipv4 kifejezés használható az oifname "enp2s0" elé, vagy a tábla típusa módosítható ip-re.

Ez a példa maszkolni fogja a forgalmat, amely egy eth0 nevű WAN interfészen keresztül hagyja el a rendszert, és továbbítja a 22-es és 80-as portokat a 10.0.0.2 címre. Önnek a sysctl segítségével be kell állítania a net.ipv4.ip_forward értékét 1-re.

table nat {
 chain prerouting {
 type nat hook prerouting priority dstnat;
 iif eth0 tcp dport {22, 80} dnat to 10.0.0.2
 }
 chain postrouting {
 type nat hook postrouting priority srcnat;
 oif eth0 masquerade
 }
}

Használja ezt a kódrészletet a HTTPS protokollú kapcsolatok számlálásához:

/etc/nftables.conf

table inet filter {
 set https {
 type ipv4_addr;
 flags dynamic;
 size 65536;
 timeout 60m;
 }

 chain input {
 type filter hook input priority filter;
 ct state new meta l4proto { tcp, udp } th dport 443 update @https { ip saddr counter }
 }
}

A számlálók megjelenítése érdekében futtassa az nft list set inet filter https parancsot.

Használja ezt a kódrészletet annak érdekében, hogy 1 percre eldobja az összes HTTPS protokollú kapcsolatot egy olyan forrás IP-címről (vagy /64 IPv6 tartományból), amely meghaladja a 10/másodperc korlátot.

/etc/nftables.conf

table inet dev {
 set blackhole_ipv4 {
 type ipv4_addr;
 flags dynamic, timeout;
 size 65536;
 }
 set blackhole_ipv6 {
 type ipv6_addr;
 flags dynamic, timeout;
 size 65536;
 }

 chain input {
 type filter hook input priority filter; policy accept;
 ct state new meta l4proto { tcp, udp } th dport 443 \
 meter flood_ipv4 size 128000 { ip saddr timeout 10s limit rate over 10/second } \
 add @blackhole_ipv4 { ip saddr timeout 1m }
 ct state new meta l4proto { tcp, udp } th dport 443 \
 meter flood_ipv6 size 128000 { ip6 saddr and ffff:ffff:ffff:ffff:: timeout 10s limit rate over 10/second } \
 add @blackhole_ipv6 { ip6 saddr and ffff:ffff:ffff:ffff:: timeout 1m }

 ip saddr @blackhole_ipv4 counter drop
 ip6 saddr and ffff:ffff:ffff:ffff:: @blackhole_ipv6 counter drop
 }
}

A feketelistára rákerült IP-címek megjelenítése érdekében futtassa az nft list set inet dev blackhole_ipvX parancsot.

Az nft list ruleset parancs kimenete egyben érvényes bemeneti fájl is. Az aktuális szabálykészlet elmenthető fájlba, majd később visszatölthető.

# nft -s list ruleset | tee filename

További információért tekintse meg az Egyszerű állapotkövető tűzfal című oldalt.

Törölje az aktuális szabálykészletet:

# nft flush ruleset

Adjon hozzá egy táblát:

# nft add table inet my_table

Adja hozzá a bejövő (input), továbbítási (forward) és kimenő (output) alapláncokat. A bejövő és továbbítási lánc alapértelmezett szabálya az eldobás (drop) lesz. A kimenő lánc alapértelmezett szabálya az elfogadás (accept) lesz.

# nft add chain inet my_table my_input '{ type filter hook input priority 0 ; policy drop ; }'
# nft add chain inet my_table my_forward '{ type filter hook forward priority 0 ; policy drop ; }'
# nft add chain inet my_table my_output '{ type filter hook output priority 0 ; policy accept ; }'

Adjon hozzá két normál láncot, amelyek a TCP protokollhoz és az UDP protokollhoz lesznek társítva:

# nft add chain inet my_table my_tcp_chain
# nft add chain inet my_table my_udp_chain

A kapcsolódó és már létrejött forgalom elfogadásra kerül:

# nft add rule inet my_table my_input ct state '{ related, established }' accept

Minden loopback interfész forgalom elfogadásra kerül:

# nft add rule inet my_table my_input iif lo accept

Minden érvénytelen forgalom elutasításra kerül:

# nft add rule inet my_table my_input ct state invalid drop

ICMP és IGMP elfogadása:

# nft add rule inet my_table my_input meta l4proto '{ icmp, ipv6-icmp }' accept
# nft add rule inet my_table my_input ip protocol igmp accept

Az új UDP forgalom az UDP láncba ugrik:

# nft add rule inet my_table my_input meta l4proto udp ct state new jump my_udp_chain

Az új TCP forgalom a TCP láncba ugrik:

# nft add rule inet my_table my_input 'meta l4proto tcp tcp flags & (fin|syn|rst|ack) == syn ct state new jump my_tcp_chain'

Ezen a ponton Önnek el kell döntenie, hogy mely portokat kívánja megnyitni a bejövő kapcsolatok számára, amelyeket a TCP és UDP láncok kezelnek. Például egy webszerver kapcsolatainak a megnyitása érdekében adja hozzá:

# nft add rule inet my_table my_tcp_chain tcp dport 80 accept

Annak érdekében, hogy egy webszerver esetén a 443-as porton a HTTPS kapcsolatok elfogadásra kerüljenek:

# nft add rule inet my_table my_tcp_chain tcp dport 443 accept
# nft add rule inet my_table my_udp_chain udp dport 443 accept

Annak érdekében, hogy az SSH forgalom el legyen fogadva a 22-es porton:

# nft add rule inet my_table my_tcp_chain tcp dport 22 accept

Bejövő DNS kérések elfogadása érdekében:

# nft add rule inet my_table my_tcp_chain tcp dport 53 accept
# nft add rule inet my_table my_udp_chain udp dport 53 accept

Ügyeljen arra, hogy amikor Ön már elégedett a módosításokkal, akkor azokat tartósan megmaradóvá tegye.

Az sshguard egy olyan program, amely képes észlelni a brute-force támadásokat, és képes a tűzfalakat az IP-címek ideiglenes feketelistára helyezésével az észlelésnek megfelelően módosítani. A program beállítása érdekében tekintse meg az sshguard#nftables című leírást, amely bemutatja, hogy miként kell az nftables programot használni vele.

Ön az adatcsomagokat a log művelettel naplózhatja. A legegyszerűbb szabály az összes bejövő forgalom naplózására:

# nft add rule inet filter input log

További részletekért tekintse meg az nftables wiki weboldalt.

Figyelje az összes eseményt, natív nft formátumban jelentve.

# nft monitor

Részletekért tekintse meg az nft(8) § MONITOR man súgót.

meta nftrace set 1 szabálykészlet csomagkövetés be/ki. A monitor trace parancs használható a nyomkövetések megtekintésére.

Egy másik shell-be include"-olja a fájlt az interaktív shell-en belül:

# nft -i
nft> include "/root/nftables.trace"

Egy példa, amelyet Ön a saját igényeinek megfelelően módosíthat:

/root/nftables.trace

add table ip temp-trace {comment "Temporary table!!"; flags owner;}
add chain ip temp-trace icmp-prerouting { type filter hook prerouting priority raw - 1 ; }
add rule ip temp-trace icmp-prerouting ip protocol icmp meta nftrace set 1

Ez a fájl egy ideiglenes táblát ad hozzá (flags owner) a tűzfalszabályzathoz, amely automatikusan eltávolításra kerül, amikor a hívó (folyamat) interaktív nft bezáródik. Az alapláncot (Base Chain) az Ön felhasználási esetéhez kell igazítani. Ön több láncot és több szabályt is létrehozhat a "meta nftrace set 1" használatával. Az "ip protocol icmp" csak példaként szolgál, és nem szükséges. Számos módja van hasonló hatás elérésének: Az előnye az, hogy az interaktív shell bezárásával az előző állapot automatikusan visszaáll, és ha hiba van a fájlban, akkor nem hajtódik végre semmi.

Tekintse meg az nftables wiki weboldalt, valamint egy, a folyamatot automatizáló és színező Python segédprogramot.

A régebbi iptables nyelv továbbra is meglehetősen meghatározó szerepet tölt be a Linux dokumentációban, és számos dolog még mindig az iptables programra támaszkodik a működés érdekében (például a Docker hálózati rendszere). Bár teljes mértékben működőképes az örökölt iptables és az nftables egyidejű használata, az iptables-nft fordítás használata előnyben részesített, mert:

• Mindent ugyanarra a helyre tesz, az újabb, hatékonyabb, nem zároló keretrendszert használva.
• Ellenőrzi az ütközéseket.

Az iptables program régi nyelvének nftables programmal történő használatára kétféle mód van:

• Az iptables-translate és az iptables-restore-translate (ugyanez vonatkozik a ip6tables, ebtables stb. programokra is) az iptables nyelvet nft nyelvre fordítja. Ezek nem módosítják a futó nft beállításokat. Tekintse meg az xtables-translate(8) man súgót.

Az olyan beállítások esetén, amelyeket később is karbantartani kíván, jó ötlet a -translate eszközt használni, és az eredménykódot beilleszteni a meglévő szabályok közé. Például, ha hasznos dolgot talál az Egyszerű állapotkövető tűzfal című leírásban vagy az interneten, akkor lefordíthatja annak érdekében, hogy az nft beállításába beillessze.

• Az iptables és az iptables-restore (ugyanez igaz a ip6tables stb. programokra is) az előbbi fordítást használja, és egyúttal be is helyezi azt a futó nft beállítások közé. Emellett statisztikákat is kínál, ahogyan a hagyományos iptables is. Tekintse meg az xtables-nft(8) man súgót.

Ezek a parancsok a rendelkezésre álló információk mellett elfogadhatóan működnek. Egyszerű használat esetén "egyszerűen csak működniük kell", de időnként szükség lehet beavatkozásra és hibakeresésre.

A systemd-networkd kapcsolatai használhatják az NFTSet= opciót előre definiált, elnevezett készletek feltöltésére host IP-címekkel, hálózati előtagokkal és interfészindexekkel. Ez lehetővé teszi, hogy elkerülje ezek hard-kódolását a /etc/nftables.conf fájlban. Az NFTSet= opció támogatott az [Address], [DHCPv4], [DHCPv6] és [IPv6AcceptRA] szekciókban. Tekintse meg a systemd.network(5) § [ADDRESS] SECTION OPTIONS man súgót.

Annak érdekében például, hogy a helyi hálózatból érkező kapcsolatok (ahol az IP-címek DHCP vagy SLAAC segítségével kerülnek kiosztásra) egy külön my_input_lan láncban legyenek feldolgozva:

/etc/nftables.conf

...
table inet my_table {

	set eth_ipv4_prefix {
		type ipv4_addr
		flags interval
		comment "Populated by systemd-networkd"
	}
	set eth_ipv6_prefix {
		type ipv6_addr
		flags interval
		comment "Populated by systemd-networkd"

		elements = { fe80::/10 }
	}
	set eth_ifindex {
		type iface_index
		comment "Populated by systemd-networkd"
	}
...
	chain my_input {
		type filter hook input priority filter; policy drop;

		iif @eth_ifindex ip6 saddr @eth_ipv6_prefix jump my_input_lan comment "Connections from LAN"
		iif @eth_ifindex ip saddr @eth_ipv4_prefix jump my_input_lan comment "Connections from LAN"
	}
...
}

/etc/systemd/network/my-network.network

...

[DHCPv4]
NFTSet=prefix:inet:my_table:eth_ipv4_prefix
NFTSet=ifindex:inet:my_table:eth_ifindex

[DHCPv6]
NFTSet=prefix:inet:my_table:eth_ipv6_prefix
NFTSet=ifindex:inet:my_table:eth_ifindex

[IPv6AcceptRA]
NFTSet=prefix:inet:my_table:eth_ipv6_prefix
NFTSet=ifindex:inet:my_table:eth_ifindex
...

Az nftables használata zavarhatja a Docker hálózatkezelését (és valószínűleg más konténer futtatókörnyezetekét is). Különféle kerülőmegoldások találhatók az interneten, amelyek vagy az iptables szabályok módosítását és egy meghatározott szolgáltatásindítási sorrend biztosítását igénylik, vagy a Docker iptables-kezelésének teljes letiltását igénylik, ami a Docker használatát erősen korlátozza (például port forwarding vagy docker-compose esetén).

Egy megbízható módszer az, hogy a Docker külön hálózati névtérben fut, ahol szabadon végezhet bármilyen műveletet. Valószínűleg a legjobb nem az iptables használata, hanem helyette az iptables-legacy használata annak érdekében, hogy Ön ezáltal megakadályozza a Docker számára az nftables és iptables szabályok keverését.

Használja a következő Docker szolgáltatás beilleszthető kódrészletfájlt:

/etc/systemd/system/docker.service.d/netns.conf

[Service]
PrivateNetwork=yes
PrivateMounts=No

# cleanup
ExecStartPre=-nsenter -t 1 -n -- ip link delete docker0

# add veth
ExecStartPre=nsenter -t 1 -n -- ip link add docker0 type veth peer name docker0_ns
ExecStartPre=sh -c 'nsenter -t 1 -n -- ip link set docker0_ns netns "$$BASHPID" && true'
ExecStartPre=ip link set docker0_ns name eth0

# bring host online
ExecStartPre=nsenter -t 1 -n -- ip addr add 10.0.0.1/24 dev docker0
ExecStartPre=nsenter -t 1 -n -- ip link set docker0 up

# bring ns online
ExecStartPre=ip addr add 10.0.0.100/24 dev eth0
ExecStartPre=ip link set eth0 up
ExecStartPre=ip route add default via 10.0.0.1 dev eth0

Állítsa be a 10.0.0.* IP-címeket, amennyiben azok nem megfelelőek az Ön beállításához.

Engedélyezze az IP-forwarding műveletet, és állítsa be a NAT műveletet a docker0 számára a következő postrouting szabállyal:

iifname docker0 oifname eth0 masquerade

Ezután gondoskodjon arról, hogy a kernel IP-forwarding engedélyezve legyen.

Most már beállíthat tűzfalat és port forwarding műveletet a docker0 interfészhez nftables használatával, bármilyen zavarás nélkül.

• netfilter nftables wiki
• debian:nftables
• gentoo:nftables
• First release of nftables
• nftables quick howto
• The return of nftables
• What comes after ‘iptables’? Its successor, of course: `nftables`
• Gene's Tech Blog – További nftables minták munkaállomásokhoz és tűzfalhoz.