[gelöst] Sind nftables im Kernel?
[gelöst] Sind nftables im Kernel?
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?
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?
Zuletzt geändert von TomL am 21.01.2018 15:45:45, insgesamt 1-mal geändert.
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Sind nftables im Kernel?
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.
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.
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Sind nftables im Kernel?
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
mit. Netfilter ist also meinem Kenntnisstand nach schon etliche Jahre im Kernel.
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
Re: Sind nftables im Kernel?
Hast Du auch das tool nft?MSfree hat geschrieben:18.01.2018 09:20:02Netfilter ist also meinem Kenntnisstand nach schon etliche Jahre im Kernel.
Code: Alles auswählen
which nft
Re: Sind nftables im Kernel?
@msfree, Danke, das war der entscheidende Hinweis... ich habe nicht gewusst, dass das so leicht zu prüfen ist
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....
... ist doch nur das Frontend zum Einstellen der Regeln, oder? Im Kernel scheints ja schon drin zu sein, wie mir msfree gezeigt hat.
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
@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
Re: Sind nftables im Kernel?
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
Re: Sind nftables im Kernel?
Naja, darum geht es ja nicht. Es geht darum, wie bzw. ob man "Netfilter ... im Kernel" nutzen kann.MSfree hat geschrieben:18.01.2018 10:35:01Ich habe weder iptables noch nftables auf dem Jessie-Rechner im Einsatz, ...
Re: Sind nftables im Kernel?
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'
Re: Sind nftables im Kernel?
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.MSfree hat geschrieben:18.01.2018 10:35:01...der hängt hinter einer Firewall und benötigt keinen zusätzlichen eigenen Schutz.
Zuletzt geändert von TomL am 18.01.2018 14:39:58, insgesamt 1-mal geändert.
Re: Sind nftables im Kernel?
Wenn ich das richtig interpretiere, besteht für die nftables hier auf ganzer Strecke "grünes Licht" ...?... oder?mat6937 hat geschrieben:18.01.2018 10:43:42Ja, 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'
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
Re: Sind nftables im Kernel?
Ja, denn Du kannst mit:TomL hat geschrieben:18.01.2018 14:10:50Wenn ich das richtig interpretiere, besteht für die nftables hier auf ganzer Strecke "grünes Licht" ...?... oder?
Code: Alles auswählen
# apt show nftables
Package: nftables
Version: 0.7-1
Priority: extra
Section: net
Re: Sind nftables im Kernel?
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).
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).
Re: Sind nftables im Kernel?
Genau das ist ja der Grund, warum ich überhaupt über eine Ablösung nachdenke.Ich kenne das schon länger.ThorstenS hat geschrieben:18.01.2018 15:25:04Du kannst Regeln schreiben, die gleichzeitig auf ipv4 und ipv6 angewendet werden ( der nft-Name inet wirkt sich auf beide Protokolle aus).
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
Re: [gelöst] Sind nftables im Kernel?
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.
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.
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
}
}
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.