nftables: was filtert "ct state invalid"?

[ingo2]

Ich habe ein Verständnisproblem:

Habe nach Studium mehrerer Beispiele u.a. folgende Regel in meiner Filterkette:

nft list ruleset

Code: Alles auswählen

ct state established,related accept
ct state invalid counter packets 46 bytes 7432 drop

und wie man sieht, werden etliche Pakete gefiltert. Etliche davon sind "ICMPv6 redirects" - das habe ich schon herausgefunden.

Im Wiki https://wiki.nftables.org/wiki-nftables ... 10_minutes im Abschnitt "ct match" ist allerdings ein state "invalid garnicht aufgeführt. Es gibt nur

Code: Alles auswählen

{ new, established, related, untracked }

und ein Beispiel mit "state = 8".
Weitere Recherchen führen dann zu irgendwelchen Kernel-Konfigurationen, die ich nicht mehr verstehe.

Zusätzliche Info:
Neue Verbindungen sind danach immer noch zulässig, wenn man sie weiter unten in der chain z.B. mit

Code: Alles auswählen

tcp dport { ssh, ipp } ct state new accept

erlaubt - wird also von "invalid" nicht gedroppt. Auch IP-Telefonie mit Linphone geht ohne jegliche Portöffnung einwandfrei in beider Richtungen.

Mir ist also völlig unklar, was die Regel mit "ct state invalid" nun wirklich tut/filtert (entspricht wohl conntrack in iptables).
Kann mir das Jemand erklären/allgemeinverständlich beschreiben?

Gruß,
Ingo

[ReturnToSender]

Invalid filtert Pakete, die nicht einer bekannten (Conntrack-State related/established) Verbindung zuzuordnen sind und auch nicht dem new-State entsprechen, was im Endeffekt also einem Invalid-Conntrack-State entspricht. Dafür gibts unterschiedliche Ursachen, z.B. Traffic außerhalb der Conntrack-Module z.B. durch Stealth-Mechanismen. Ich habe mal irgendwo gelesen, das Pakete auch als solche deklariert werden, wenn die Conntrack-Tabellen überlaufen. Invalid-Pakete müssen nicht zwingend was schlechtes sein, aber ich würde sie dennoch filtern.

Neue Verbindungen sind danach immer noch zulässig, wenn man sie weiter unten in der chain z.B. mit...

Ja, das ist auch so richtig, weil CT-State NEW ein korrekter und bekannter Status ist, hier eben nur für eine neue Verbindung.

[ingo2]

Danke für die Info.
Erstaunlich, das das nirgends dokumentiert ist.

Invalid filtert Pakete, die nicht einer bekannten (Conntrack-State related/established) Verbindung zuzuordnen sind und auch nicht dem new-State entsprechen, was im Endeffekt also einem Invalid-Conntrack-State entspricht. Dafür gibts unterschiedliche Ursachen, z.B. Traffic außerhalb der Conntrack-Module z.B. durch Stealth-Mechanismen. Ich habe mal irgendwo gelesen, das Pakete auch als solche deklariert werden, wenn die Conntrack-Tabellen überlaufen. Invalid-Pakete müssen nicht zwingend was schlechtes sein, aber ich würde sie dennoch filtern.

Was ich bisher sicher herausgefunden habe:
ct state invalid filtert auf jeden Fall IPv6-Redirekts, die meine FritzBox an meinen PC (der hat auch eine ULA) sendet

Code: Alles auswählen

IN=eno1 OUT= MAC=00:22:4d:83:64:41:38:10:d5:d2:23:55:86:dd SRC=fe80:0000:0000:0000:3a10:d5ff:fed2:2355 DST=fd33:0000:0000:abba:34c1:68e0:a015:bec1 LEN=200 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=137 CODE=0

Das hatte ich schon vorher so realisiert:

Code: Alles auswählen

ip6 nexthdr ipv6-icmp icmpv6 type nd-redirect counter packets 0 bytes 0 drop

Der counter steht nämlich auf "0" seit ich "ct state invalid" eingefügt habe. Aber was geht so eine ICMP-Meldung conntrack an?

Und dann gibt's ja noch den Typ "untracked" - was soll man sich darunter vorstellen?

EDIT:
Ich hatte schon recht schnell eine funktionierende nftables.conf für meine Desktop-Ansprüche beisammen.
Hatte schon überlegt, die hier im Forum zur Diskussion zu stellen, da sicher auch andere User an einer universellen Firewall mit nftables (wird Standard in Buster) interessiert sind. Meine Firewall nutzt keine IP-Adressen und somit universell.
Vorher wollte ich natürlich auch alle Details dazu selbst verstehen - aber das wirft immer mehr Fragen auf.
Hat doch so einen Anflug von schwarzer Magie

[ReturnToSender]

Was ich bisher sicher herausgefunden habe:
ct state invalid filtert auf jeden Fall IPv6-Redirekts, die meine FritzBox an meinen PC (der hat auch eine ULA) sendet

Code: Alles auswählen

IN=eno1 OUT= MAC=00:22:4d:83:64:41:38:10:d5:d2:23:55:86:dd SRC=fe80:0000:0000:0000:3a10:d5ff:fed2:2355 DST=fd33:0000:0000:abba:34c1:68e0:a015:bec1 LEN=200 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=137 CODE=0

Ob das jetzt ganz sicher daher kommt, kann man ohne das Regelwerk zu kennen nicht feststellen. Ich würde dieser Behandlung ein besonderes einmaliges Log-Flag vergeben, um Irrtümer auszuschließen.

Aber was geht so eine ICMP-Meldung conntrack an?

ICMP ist nach meinem Verständnis nur ein höheres Protokoll, welches sich TCP/IP bedient... also muss es auch durch den Paketfilter durch und kann deshalb natürlich auch gefiltert werden. Das braucht man z.B. bei Echo-Request-Flooding , also die ICMP-Typen 8 bzw. 128

Und dann gibt's ja noch den Typ "untracked" - was soll man sich darunter vorstellen?

Das kann passieren, wenn Du Pakete in der RAW-Tabelle manipulierst, also in gewisser Weise mit Absicht dahinter. Solche Pakete können theoretisch am Tracking vorbei geleitet werden und werden dann als untracked markiert. Ich würde das jetzt vielleicht so interpretieren, wie beispielsweise TCP-Pakete auf gebridg'ten VirtualBox-Maschinen sowohl am Tracking als auch am Paketfilter vorbeigehen. Die sind faktisch auf dem System, in dessen NIC sie physisch ankommen, untracked. Möglicherweise ist das auch ein Fall für Malware... das kann ich aber nicht gut beurteilen oder treffend einschätzen, sondern nur vermuten.

[ingo2]

Noch was, was von "ct state invalid" gefiltert wird:

Habe im XFCE-Panel das weather applet, das bezieht stündlich seine Daten von https://www.met.no/.
Anscheinend beendet das Plugin seine Verbindung nich ordnungsgemäß und met.no sendet das "RST-Flag":

Code: Alles auswählen

IN=eno1 OUT= MAC=00:22:4d:83:64:41:38:10:d5:d2:23:55:08:00 SRC=157.249.177.128 DST=192.168.xxx.12 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=20518 DF PROTO=TCP SPT=443 DPT=53902 WINDOW=0 RES=0x00 RST URGP=0

Auch das filtert "ct state invalid".