nftables auf einem normalen Debian-PC?

Selbst wenn du das nftables-Userspace-Paket deinstallierst: Die Kernel-Module mit allen ihren Möglichkeiten bleiben vorhanden. Du verlierst nur die Option, komfortabel zu kontrollieren, was diese tun.

komfortabel zu kontrollieren

Wenn man sich den "Regelverhau" mal ansieht, stellt sich die Komfortfrage oft gar nicht mehr.

Ich fand/finde immer noch ein Skript, dass die Regeln kommentiert(!) laedt, am uebersichtlichsten. Das haben mir auch alle meine Urlaubsvertretungen so bestaetigt.

Man muss halt wissen was man tut.

Aber warum ich das überhaupt brauche wird nirgends erklärt.

Weil die Sicherheitsfuzzeln halt immer von der GROESSTMOEGLICHEN Bedrohungslage ausgehen. Die mitgelieferten Regelwerke werden ueber zahlreiche Variable(!) zur Laufzeit gesetzt. Was da im einzelnen passiert, ist auch fuer Experten nur mit Muehe nachzuvollziehen.

Wenn der Benutzer seine Netzwerkeinstellungen selber aendern will, sollte er auch das Wissen haben, wie es sein Netzwerk im Bedarfsfall schuetzen kann.

Εrnst B. schrieb:

Die Kernel-Module mit allen ihren Möglichkeiten bleiben vorhanden.

Gut Tipp, vorhanden sind sie natürlich, aber sie werden nicht geladen (sagt lsmod | grep nf). Und ssh und vnc funktionieren trotzdem noch ;)

Motopick schrieb:

Was da im einzelnen passiert, ist auch fuer Experten nur mit Muehe nachzuvollziehen.

Genau den Eindruck hatte ich auch. Sowas mag ich garnicht anfassen. Werde ich auch nicht, du hast mich überzeugt. Dann muss er mit geänderten Einstellungen eben neu booten :(

Motopick schrieb:

Man muss halt wissen was man tut.

Korrekt.

Was da im einzelnen passiert, ist auch fuer Experten nur mit Muehe nachzuvollziehen.

Was da im Einzelnen passiert, ist für Experten nachvollziehbar.

NFT ist ein mächtiges Schwert. Wenn man's an der falschen Seite anpackt, dann kann's^H^H wird's weh tun.

Und eine halbe Stunde Dokus lesen reicht in diesem Fall ganz sicher nicht aus.

Bauform B. schrieb:

Gut Tipp, vorhanden sind sie natürlich, aber sie werden nicht geladen (sagt lsmod | grep nf). Und ssh und vnc funktionieren trotzdem noch

Normalerweise sind ja auch keine Regeln gesetzt. Und wenn kein Programm/Startup-Script welche einfügen will, werden die Module auch nicht automatisch geladen.

Motopick schrieb:

Die mitgelieferten Regelwerke werden ueber zahlreiche Variable(!) zur Laufzeit gesetzt.

Welche "mitgelieferten Regelwerke"? Standard-Debian bootet mit leerem netfilter.

Norbert schrieb:

Was da im Einzelnen passiert, ist für Experten nachvollziehbar.

"Leere Liste an Regeln --> tut nix" ist soo schwer nicht zu verstehen...

Das nftables-Paket ist übrigens noch nicht mal im Standard-Installationsumfang dabei. Was dabei ist, ist das "iptables"-Paket, was (in aktuellen, "nicht-legacy")-Versionen ebenfalls netfilter verwendet.

Εrnst B. schrieb:

"Leere Liste an Regeln --> tut nix" ist soo schwer nicht zu verstehen...

Ach Ernst, ich könnte mir vorstellen das man mit ein wenig gutem Willen erkennen kann, das sich meine Aussagen nicht auf ›Leere‹ Listen bezogen.

Sei's drum.

Norbert schrieb:

Ach Ernst, ich könnte mir vorstellen das man mit ein wenig gutem Willen erkennen kann, das sich meine Aussagen nicht auf ›Leere‹ Listen bezogen.

Die Fragestellung dreht sich um "nftables auf einem normalen Debian-PC?"

Und dort sind nunmal keine ultra-komplexen, variablen-abhängigen Firewall-Regeln installiert, die sich nur mit Informatik-Doktorabschluss verstehen lassen, sondern: NIX.

Εrnst B. schrieb:

Die Fragestellung dreht sich um "nftables auf einem normalen Debian-PC?"

Ein ›normales‹ Debian bietet auch firewalls als Pakete. Oder wollen wir jetzt diskutieren was ein ›normales‹ Debian ist? Alles, aber keine GUI? Die Minimalinstallation? Oder nur ein Kernel und 'ne rescue shell?

Egal, lassen wir's…

Norbert schrieb:

Ein ›normales‹ Debian bietet auch firewalls als Pakete. Egal, lassen wir's…

Ja. Spätestens nach der Deinstallation von iptables/nftables sind die nämlich weg, und der "Wenn ich was installiere, was ich nicht verstehe, dann ist was installiert, was ich nicht verstehe"-Teufelskreis durchbrochen.

@ TO:

Mit einem "nft list ruleset" kannst du dir den aktuellen Zustand deiner nft Firewall ja mal anzeigen lassen.

Bleibt zu hoffen, dass die Default Policies der weiter nicht benutzten Firewall auch auf ACCEPT stehen.

Ich bin ganz unfreiwillig :) auch nftables Benutzer geworden.

Die Kostprobe eines "nft -a list ruleset":

table inet fw4 { # handle 1 chain input { # handle 1 type filter hook input priority filter; policy drop; iifname "lo" accept comment "!fw4: Accept traffic from loopback" # handle 70 ct state established,related accept comment "!fw4: Allow inbound established and related flows" # handle 71 tcp flags syn / fin,syn,rst,ack jump syn_flood comment "!fw4: Rate limit TCP syn packets" # handle 72 iifname "br-lan" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic" # handle 73 jump handle_reject # handle 74 }

chain forward { # handle 2 type filter hook forward priority filter; policy drop; ct state established,related accept comment "!fw4: Allow forwarded established and related flows" # handle 75 iifname "br-lan" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic" # handle 76 jump handle_reject # handle 77 }

chain output { # handle 3 type filter hook output priority filter; policy accept; oifname "lo" accept comment "!fw4: Accept traffic towards loopback" # handle 78 ct state established,related accept comment "!fw4: Allow outbound established and related flows" # handle 79 oifname "br-lan" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic" # handle 80 }

chain prerouting { # handle 4 type filter hook prerouting priority filter; policy accept; iifname "br-lan" jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment" # handle 81 }

chain handle_reject { # handle 5 meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic" # handle 82 reject comment "!fw4: Reject any other traffic" # handle 83 }

chain syn_flood { # handle 6 limit rate 25/second burst 50 packets return comment "!fw4: Accept SYN packets below rate-limit" # handle 84 drop comment "!fw4: Drop excess packets" # handle 85 }

chain input_lan { # handle 7 jump accept_from_lan # handle 86 }

chain output_lan { # handle 8 jump accept_to_lan # handle 87 }

chain forward_lan { # handle 9 jump accept_to_wan comment "!fw4: Accept lan to wan forwarding" # handle 88 jump accept_to_lan # handle 89 }

chain helper_lan { # handle 10 }

chain accept_from_lan { # handle 11 iifname "br-lan" counter packets 158 bytes 15410 accept comment "!fw4: accept lan IPv4/IPv6 traffic" # handle 90 }

chain accept_to_lan { # handle 12 oifname "br-lan" counter packets 124 bytes 19424 accept comment "!fw4: accept lan IPv4/IPv6 traffic" # handle 91 }

chain input_wan { # handle 13 meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew" # handle 92 icmp type echo-request counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping" # handle 93 meta nfproto ipv4 meta l4proto igmp counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP" # handle 94 meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6" # handle 95 ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . no-route, mld-listener-report . no-route, mld-listener-done . no-route, mld2-listener-report . no-route } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD" # handle 96 icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input" # handle 97 icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input" # handle 98 jump reject_from_wan # handle 99 }

chain output_wan { # handle 14 jump accept_to_wan # handle 100 }

chain forward_wan { # handle 15 icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward" # handle 101 icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward" # handle 102 meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP" # handle 103 udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP" # handle 104 jump reject_to_wan # handle 105 }

chain accept_to_wan { # handle 16 }

chain reject_from_wan { # handle 17 }

chain reject_to_wan { # handle 18 }

chain dstnat { # handle 19 type nat hook prerouting priority dstnat; policy accept; }

chain srcnat { # handle 20 type nat hook postrouting priority srcnat; policy accept; }

chain srcnat_wan { # handle 21 meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic" # handle 106 }

chain raw_prerouting { # handle 22 type filter hook prerouting priority raw; policy accept; }

chain raw_output { # handle 23 type filter hook output priority raw; policy accept; }

chain mangle_prerouting { # handle 24 type filter hook prerouting priority mangle; policy accept; }

chain mangle_postrouting { # handle 25 type filter hook postrouting priority mangle; policy accept; }

chain mangle_input { # handle 26 type filter hook input priority mangle; policy accept; }

chain mangle_output { # handle 27 type route hook output priority mangle; policy accept; }

chain mangle_forward { # handle 28 type filter hook forward priority mangle; policy accept; } }

Motopick schrieb:

Mit einem "nft list ruleset" kannst du dir den aktuellen Zustand deiner nft Firewall ja mal anzeigen lassen.

Danach installiert Debian seit dem aktuellen stable ziemlich einfache(?) Regeln. In den Vorgängerversionen gab es zwar nft, aber keine Regeln. Jetzt in testing hat sich nichts mehr geändert. kuemmel und salbei sind weitgehend unverbastelt, auf vanille habe ich gebastelt und "nft -f /etc/nftables.conf" wird beim booten nicht mehr aufgerufen. Ab Werk sieht es da genau wie auf salbei aus.

1

root@kuemmel:~# cat /etc/debian_version 

2

10.13

3

root@kuemmel:~# nft -a list ruleset

4

root@kuemmel:~# 

5

----------------

6

root@salbei:~# cat /etc/debian_version 

7

11.6

8

root@salbei:~# nft -a list ruleset

9

table inet filter { # handle 1

10

        chain input { # handle 1

11

                type filter hook input priority filter; policy accept;

12

        }

13

14

        chain forward { # handle 2

15

                type filter hook forward priority filter; policy accept;

16

        }

17

18

        chain output { # handle 3

19

                type filter hook output priority filter; policy accept;

20

        }

21

}

22

root@salbei:~# 

23

---------------

24

root@vanille:~# cat /etc/debian_version 

25

bookworm/sid

26

root@vanille:~# nft -a list ruleset

27

root@vanille:~#

Bauform B. schrieb:

Danach installiert Debian seit dem aktuellen stable ziemlich einfache(?) Regeln.

das was du das gepostet hast sind keine regeln, sondern der "accept all"-Default. Und den hast du möglicherweise erst mit dem "list ruleset"-Kommando angelegt, das hat das Laden der Kernel-Module mit ihrer Default-Config angestoßen.

Statt dir mit dem "nft"-Kommando die Low-Level-Details anzuschauen, kannst du die auch per "iptables(-nft) -L" ansehen, da sind die übersichtlicher.

Mir erschließt sich aus der Lektüre dieses Threads nicht, welches Problem eigentlich gelöst werden soll. Funktioniert durch die Existenz von nftables irgendwas nicht?

Das Problem war, dass ich die gesamten Netzwerkeinstellungen nicht beim Booten, sondern später durch das Anwendungsprogramm machen muss. Dabei ist mir zum ersten Mal nftables aufgefallen. Die Frage war also, was macht das Teil und muss ich das in meinem Programm berücksichtigen. Nachdem der PC hinter einen sehr restriktiven Router sitzt, werde ich nftables einfach ignorieren.

sondern später durch das Anwendungsprogramm machen muss

Dann solltest du auch einen eventuell laufenden "Network Manager" nicht aus den Augen und aus dem Sinn lassen. Dessen Tun kann fuer dein Vorhaben weitaus destruktiver ausfallen.

Wenn man es selber macht, darf man halt nichts vergessen. Ein einfaches ifconfig reicht da eben nicht ganz. Es kann dir z.B. passieren, dass der sshd nicht gestartet wird, weil das "Network" meint, da waere nichts. Usw. usf....

Motopick schrieb:

Dann solltest du auch einen eventuell laufenden "Network Manager" nicht aus den Augen und aus dem Sinn lassen.

Ausgerechnet der läuft hier garantiert nicht, noch nie und niemals. Und sshd usw. usf. sind pflegeleicht, mit denen verstehe ich mich schon länger, nur nftables war mir neu.

Bauform B. schrieb:

nur nftables war mir neu.

Wie oben schon geschrieben: Vom Userspace aus gesehen macht das keinen Unterschied zum alten "iptables", es wird nur im Kernel eine andere Infrastruktur verwendet.

Ärgerlich waren nur die "Übergangs-Versionen", wo sowohl iptables-legacy als auch iptables-nft gleichzeitig aktiv sein konnten. Da musste man beim Debuggen von Netzwerk-Problemen immer zweimal hinschauen.