[gelöst] Sind nftables im Kernel?

[TomL]

Moin

Ich glaube, die Frage ist etwas unglücklich gestellt, aber besser gehts im Moment noch nicht... ich bin noch dabei Infos zu sammeln und stolpere gerade mal im Dunkeln rum. Ich habe gelesen, dass nftables möglicherweise künftig iptables ablösen werden. Und nun überlege ich, ob ein Wechsel vielleicht jetzt schon sinnvoll ist. Angeblich hat die NFT-Projektgruppe schon vor längerer Zeit beantragt, das in den Mainline-Kernel aufzunehmen. Und da kapier ich's im Moment nicht....

Das Stretch-Repo enthält derzeit die Version 0.7 der nftables. Aber was bedeutet das zur oben erwähnten Aufnahme in den Kernel? Weils jetzt so ein Paket gibt, ist das dann noch nicht im Kernel enthalten? Oder anders gefragt, wenns dann mal im Kernel ist, fällt dann das Paket im Repo weg? Oder bedeutet das nur, dass man das Paket immer benötigt, lediglich der Kernel hat seit Version 4711 die passenden Schnittstellen integriert...?... oder wird vielleicht irgendwann integriert haben?

Wie muss man sich das vorstellen? Sind die nftables speziell für Debian 9 noch in der Experimentierphase oder ist das schon ein voll funktionierendes Paket und bieten eine mögliche Ablösung (von iptables) ohne Abstriche? Muss man in nächster Zeit noch mit einem (vielleicht gravierendem) Umbau rechnen oder stehen die nftqables konzeptionell auf festen Beinen und befinden sich schon routinemäßig auf der ganz normalen Straße von Wartung, Pflege und Entwicklung?

Ich würde mich ja gerne mit einem Wechsel befassen.... mich nervt so ein bissen das doppel-handling mit IPv4 und IPv6. Gerade das soll ja mit nftables nicht mehr sein. Hat das schon jemand produktiv im Einsatz und echte Erfahrungen sammeln können?

[scientific]

So wie ich das verstanden habe sind iptables und nftables nur Frontends, für die im Kernel befindlichen Tabellen anhand derer der Kernel Pakete durchlässt oder verwirft.

Wie ich weiters rausgefunden habe, sollte man, wenn man einsteigt, gleich nftables-Syntax lernen, da iptables als deprecated gelten.

Aber iptables wirds noch lange geben.

[MSfree]

Für Netfilter-Tables werden eigenen Kernelmodule benötigt, ansonsten ist das Frontend nftables sehr ähnlich zu iptables.

Ich habe gerade mal bei meinem Jessie-Kernel 3.16.0 geschaut, der bringt bereits

Code: Alles auswählen

/lib/modules/3.16.0-4-amd64/kernel/net/bridge/netfilter/nft_meta_bridge.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv4/netfilter/nft_chain_nat_ipv4.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv4/netfilter/nft_chain_route_ipv4.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv4/netfilter/nft_reject_ipv4.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv6/netfilter/nft_chain_nat_ipv6.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv6/netfilter/nft_chain_route_ipv6.ko
/lib/modules/3.16.0-4-amd64/kernel/net/ipv6/netfilter/nft_reject_ipv6.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_compat.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_counter.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_ct.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_exthdr.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_hash.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_limit.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_log.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_meta.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_nat.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_queue.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_rbtree.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_reject.ko
/lib/modules/3.16.0-4-amd64/kernel/net/netfilter/nft_reject_inet.ko

mit. Netfilter ist also meinem Kenntnisstand nach schon etliche Jahre im Kernel.

[mat6937]

Netfilter ist also meinem Kenntnisstand nach schon etliche Jahre im Kernel.

Hast Du auch das tool nft?

Code: Alles auswählen

which nft

[TomL]

@msfree, Danke, das war der entscheidende Hinweis... ich habe nicht gewusst, dass das so leicht zu prüfen ist

Code: Alles auswählen

root@thomaspc:/lib/modules/4.9.0-5-amd64/kernel/net
# find . -iname "nft*" 
./ipv4/netfilter/nft_chain_route_ipv4.ko
./ipv4/netfilter/nft_dup_ipv4.ko
./ipv4/netfilter/nft_chain_nat_ipv4.ko
./ipv4/netfilter/nft_reject_ipv4.ko
./ipv4/netfilter/nft_masq_ipv4.ko
./ipv4/netfilter/nft_redir_ipv4.ko
./netfilter/nft_exthdr.ko
./netfilter/nft_numgen.ko
./netfilter/nft_compat.ko
./netfilter/nft_masq.ko
./netfilter/nft_limit.ko
./netfilter/nft_ct.ko
./netfilter/nft_queue.ko
./netfilter/nft_set_hash.ko
./netfilter/nft_counter.ko
./netfilter/nft_set_rbtree.ko
./netfilter/nft_reject_inet.ko
./netfilter/nft_nat.ko
./netfilter/nft_meta.ko
./netfilter/nft_reject.ko
./netfilter/nft_log.ko
./netfilter/nft_hash.ko
./netfilter/nft_dup_netdev.ko
./netfilter/nft_quota.ko
./netfilter/nft_redir.ko
./netfilter/nft_fwd_netdev.ko
./bridge/netfilter/nft_reject_bridge.ko
./bridge/netfilter/nft_meta_bridge.ko
./ipv6/netfilter/nft_reject_ipv6.ko
./ipv6/netfilter/nft_masq_ipv6.ko
./ipv6/netfilter/nft_chain_nat_ipv6.ko
./ipv6/netfilter/nft_redir_ipv6.ko
./ipv6/netfilter/nft_dup_ipv6.ko
./ipv6/netfilter/nft_chain_route_ipv6.ko

Was mich jetzt hier nur wieder irritiert ist der Umstand, dass Module auch wieder 2 mal vorhanden sind, V4 und V6. Ok, das wird wahrscheinlich auch so notwendig sein, aber kann man davon ausgehen, dass das Frontend trotzdem mit einer Regel beide Protokolle filtert?

@scientific, ich weiss, dass iptables irgendwann abgelöst werden, aber ich vermute, da werden noch ein, zwei, drei oder mehr Stable-Versionen ins Land gehen, bis es soweit ist. Eigentlich habe ich das bei mir mit meinen iptables-Regeln ja richtig gut im Griff, die auch unzweifelhaft und nachprüfbar filtern. Bei mir ist das nach der Vorgabe "Es ist grundsätzlich alles verboten, was nicht ausdrücklich erlaubt ist" umgesetzt, also alle Default-Policies stehen auf "DROP". Ich habe das jetzt mit einigem Aufwand mittlerweile richtig gut am Laufen und soweit auch verstanden. Aber meine Motivation ist, den doppelten Aufwand für IPv4 und IPv6 loszuwerden. Wenn ich mich recht erinnere, muss man mit nftables nicht mehr beide Protokolle separat einstellen, sondern eine Regel gilt automatisch für beide Protokolle. Ich erinnere mich, dass Du vor Monaten auch schon mal danach gefragt hast. Und....?... hast Du schon Erfahrungen sammeln können, bzw. mal ein Testszenario aufgebaut, um die tatsächliche Vorgänge zu prüfen?

@mat6937, nee, habe ich noch nicht. Und automatisch vom Installer war's das auch nicht dabei. Aber ich vermute, das Paket....

Code: Alles auswählen

# apt  show nftables
Package: nftables
Version: 0.7-1
Priority: extra
Section: net

... ist doch nur das Frontend zum Einstellen der Regeln, oder? Im Kernel scheints ja schon drin zu sein, wie mir msfree gezeigt hat.

[MSfree]

Hast Du auch das tool nft?

Ich habe weder iptables noch nftables auf dem Jessie-Rechner im Einsatz, der hängt hinter einer Firewall und benötigt keinen zusätzlichen eigenen Schutz.

Allerdings liefert mir:

Code: Alles auswählen

# apt-cache search nftables
libnftnl-dev - Development files for libnftnl
libnftnl4 - Netfilter nftables userspace API library
libnftnl4-dbg - Debugging symbols for libnftnl
nftables - Program to control packet filtering rules by Netfilter project
nftables-dbg - debugging symbols for nftables

[mat6937]

Ich habe weder iptables noch nftables auf dem Jessie-Rechner im Einsatz, ...

Naja, darum geht es ja nicht. Es geht darum, wie bzw. ob man "Netfilter ... im Kernel" nutzen kann.

[mat6937]

m Kernel scheints ja schon drin zu sein, ...

Ja, und wird evtl. auch schon genutzt (Abhängigkeiten?):

Code: Alles auswählen

lsmod |grep nf
cat /boot/config-$(uname -r) | grep -iE 'nft_|nf_tables'

[TomL]

...der hängt hinter einer Firewall und benötigt keinen zusätzlichen eigenen Schutz.

Ist bei mir genauso. Der Paketfilter kümmert sich nicht um eingehende Pakete , sondern ausschließlich um ausgehenden Traffic und reglementiert, welche Anwendungen überhaupt "raus" dürfen. Und um die letzteren kümmert sich der Router nicht.

[TomL]

Ja, und wird evtl. auch schon genutzt (Abhängigkeiten?):

Code: Alles auswählen

lsmod |grep nf
cat /boot/config-$(uname -r) | grep -iE 'nft_|nf_tables'

Wenn ich das richtig interpretiere, besteht für die nftables hier auf ganzer Strecke "grünes Licht" ...?... oder?

Code: Alles auswählen

root@thomaspc:/lib/modules/4.9.0-5-amd64/kernel/net
# lsmod |grep nf
nf_reject_ipv6         16384  1 ip6t_REJECT
nf_conntrack_ipv6      20480  20
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
nf_reject_ipv4         16384  1 ipt_REJECT
nf_conntrack_ftp       20480  0
nf_conntrack_ipv4      16384  20
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_conntrack          114688  4 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,xt_conntrack
binfmt_misc            20480  1

root@thomaspc:/lib/modules/4.9.0-5-amd64/kernel/net
# cat /boot/config-$(uname -r) | grep -iE 'nft_|nf_tables'
CONFIG_NF_TABLES=m
CONFIG_NF_TABLES_INET=m
CONFIG_NF_TABLES_NETDEV=m
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
CONFIG_NFT_NUMGEN=m
CONFIG_NFT_CT=m
CONFIG_NFT_SET_RBTREE=m
CONFIG_NFT_SET_HASH=m
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
CONFIG_NFT_MASQ=m
CONFIG_NFT_REDIR=m
CONFIG_NFT_NAT=m
CONFIG_NFT_QUEUE=m
CONFIG_NFT_QUOTA=m
CONFIG_NFT_REJECT=m
CONFIG_NFT_REJECT_INET=m

[mat6937]

Wenn ich das richtig interpretiere, besteht für die nftables hier auf ganzer Strecke "grünes Licht" ...?... oder?

Ja, denn Du kannst mit:

Code: Alles auswählen

# apt  show nftables
Package: nftables
Version: 0.7-1
Priority: extra
Section: net

auch das tool nft, für die Verwendung von nftables im user-space, installieren.

[ThorstenS]

Wenn du die Möglichkeit hast, dann lies mal den Artikel hier:
https://www.heise.de/ct/ausgabe/2015-18 ... 67676.html

Du kannst Regeln schreiben, die gleichzeitig auf ipv4 und ipv6 angewendet werden ( der nft-Name inet wirkt sich auf beide Protokolle aus).

[TomL]

Du kannst Regeln schreiben, die gleichzeitig auf ipv4 und ipv6 angewendet werden ( der nft-Name inet wirkt sich auf beide Protokolle aus).

Genau das ist ja der Grund, warum ich überhaupt über eine Ablösung nachdenke.Ich kenne das schon länger.
https://wiki.archlinux.org/index.php/nftables#Tables

Im Moment kämpfe ich mich durch... ist ja alles ziemlich starker Tobak. Ich hatte mich an die alte Lesweise gewöhnt... und die neue geht noch nicht so wirklich flüssig.
https://wiki.nftables.org/wiki-nftables ... /Main_Page

[TomL]

Moin @ all

Gerade eben habe ich den Thread auf "gelöst" gesetzt ... was soviel bedeutet, dass meine Umstellung von iptables auf nftables erfolgreich abgeschlossen ist. Und ich kann jetzt -ohne Zweifel zu haben- sagen, dass sich ein Umstieg und der damit verbundene Aufwand lohnt. Ein paar kurze Stichworte zu den aktuellen Erfahrungen...

... das Ziel war, wie zuvor mit iptables realisiert, Default-Policies nach der Prämisse "Es ist grundsätzlich alles verboten, was nicht ausdrücklich erlaubt ist!" einzurichten. Was den ganzen Kram bei Verwendung iptables so kompliziert gemacht hat, war der Umstand "Dual-Stack". Das bedeutet, mit IPv4 habe ich NAT, mit IPv6 ist mein PC jedoch Border-Device. Und das ganze Heckmeck mit einem Paketfilter für IPv4 ist für die Katz, wenn man das imho nicht analog auch für IPv6 abbildet

Natürlich, es ist bekannt, der Router firewall't den eingehenden Traffic auch bei IPv6... aber was ist, wenn eine Verbindung via IPv6 durch eine App meines PCs "established" wurde, also von innen heraus "new" verbunden wurde? Ich denke, wenn die App jetzt einen lokalen Port öffnet, entzieht sich alles weitere einer jeglichen Kontrolle... was mir natürlich nicht so gut gefallen hat. Darüber hinaus hatte ich zuvor mit iptables bei gefilterten IPv6 manchmal unreproduzierbare Probleme mit SLAAC, soll heissen, die privacy extensions funktionierten manchmal nicht mehr. Wenn die Temp-IPv6 deprecated waren, hat das irgendwie zu Problemen mit der valid_lft und der prefered_lft geführt. Ab einem Punkt waren dann alle IPv6 mit einem Schlag weg und das Protokoll war tot. Jetzt mag es sein, dass das noch ein Jessie-Effekt war... ich hatte das nämlich ne ganze Zeit lang nicht mehr verfolgt, weil ich ja via täglicher DSL->Zwangstrennung eh einen neuen Prefix bekommen habe. Aber jetzt mit Stretch und mit nftables wollte ich es wissen... und siehe da.... SLAAC funktioniert jetzt auch gefiltert.

Der Nachteil bei IPtables ist, dass man zwei Apps zur Bedienung hat und dementsprechend unterschiedliche Tables und Chains pflegen muss und alles immer nur getrennt sieht. Die Ansage, dass "inet" in nftables beide Protokolle zusammenfasst, war dann der Grund, einen Umstieg zu wagen. Aber es ist nicht so.... die Tabelle inet funktioniert nur, wenn man eher pauschal filtert. Will ich aber auch "saddr" in der Tabelle Input prüfen, um zu sehen, ob der, der "reinkommt" auch wirklich rein darf, gehts nicht. Und dann wirds mit der Drop-Policy richtig verwegen, wenn man 3 mal eine Input-Tabelle hat, IPv4, IPv6 und inet, weil man dann kaum mehr nachvollziehen kann, wer accept und wer dropt. Also sind auch hier wieder 2 Tabellen notwendig und zwar ohne konkurrierende Tabelle "inet". Der Vorteil bei nftables ist aber, dass man nur noch 1 Frontend braucht, und dass alle Tabellen in einer Filterregel liegen, also für beide Protokolle und alles auf einen Blick. Das ist richtig klasse und macht es imho sehr übersichtlich.

Und was mir richtig gut gefällt ist, dass ich für eine Output-Regel, die ja immer von localhost kommt, keine ssadr prüfen muss, sondern dort mit der Tabelle inet beide Protokolle abwickeln kann. Das heisst, alle Ports sind dicht, nur einige ausgewählte explizit für TCP oder UDP sind frei. Das sollte auch eine Anwendung davon abhalten können, eine Verbindung via IPv6 zu etablieren und dann unerlaubt einen freien Port zu öffnen.

Wenn man derzeit iptables-Statements hat, kann man die mit einem Helper-Tool (iptables-translate) in nf-Syntax umwandeln. Entweder aus einer Rules-Datei komplett oder einzeln im Dialog. Das funktioniert richtig gut, aber ich habs aber nur als Lernhilfe genommen und um zu vergleichen, warum meine Syntax fehlerhaft war.

Die Darstellung von aktiven nft-Rules ist deutlich intuitiver lesbar, als das bei iptables jemals war. Die Darstellung ist ein wenig an Programm-Funktionen angelehnt, zuerst mit einem Objektnamen (Table), dann mit mehreren Methoden (Chains) und dort, wo normalerweise Methodensparameter stehen, befinden sich Einstellungen zur Chain. Die Regeln selber befinden sich in der Chain dann ingeschweiften {}, optisch eben so,wie man das so kennt. Jede Tabelle kann neben der Chain Input auch noch die Chains Output und Forward beinhalten... was ich aber hier für mich nicht benötige. Der Rahmen für meinen Paketfilter sieht (ohne meine Regeln) jetzt so aus, die Regeln enthalten nur explizite "accept", weil alles andere (Policy) gedropt wird.

Code: Alles auswählen

table ip filter {
    chain INPUT {
        type filter hook input priority 0; policy drop;
        counter packets 3814 bytes 3285820
        iifname "lo" accept
        
	ct state established,related accept        
    }
}
table ip6 filter {
    chain INPUT {
        type filter hook input priority 0; policy drop;
        counter packets 146 bytes 21561
        iifname "lo" accept
        
	ct state established,related accept        
    }
}
table inet filter {
    chain OUTPUT {
        type filter hook input priority 0; policy drop;
        counter packets 3700 bytes 3277636
        tcp dport { http, https} ct state new accept
        
        ct state established,related accept        
    }
}

Alles was reinkommt, wird getrennt nach IPv4 und IPv6 untersucht, und unsbesondere darauf, dass der Absender von "new"-Paketen sich hier im Netz befinden muss. Und natürlich sind nur ausgewählte Anwendungen/Ports erlaubt. Ausgehende Pakete erlaube ich pauschal nur "established, related" , alle "new"-Pakete sind ebenfalls an explizite Ports gebunden.

Man kann mit nftables wie man's von iptables gewohnt ist, Regeln mit "add" hinzufügen... z.B. via Script. Aber klasse ist, dass man ein Regelwerk auch in der zuvor beschriebenen Programm-Optik erstellen kann und dann dieses Regelwerk an NFT übergibt. Das ist wirklich klasse gemacht, aber leider statisch! Und genau deswegen funktioniert das bei mir leider wegen der gewollten saddr-Prüfung in der Input-Chain nicht... denn mit täglich wechselndem ISP-Prefix muss natürlich auch im Filter jeweils der 64-Bit-Prefix aktualisiert werden.... deswegen kann ich leider nur den script-Mode nutzen, weil eben nur dort die ISP-SLAAC-IPv6 ermittelt werden kann. Aber egal... alles zusammen genommen führt trotzdem zu dem Fazit, dass es deutlich besser lesbar ist, viel besser pflegbar ist, weniger umfänglich und weniger aufwändig ist und bei mir jetzt endlich auch mit SLAAC funktioniert.

Abschliessend noch mal Danke für die hilfreichen Hinweise am Anfang des Threads.