nftables - filter forward und NAT.

[fichtl]

Seid gegrüsst an diesem wunderschönen Sonntag Morgen.

Ich habe eine Frage zu nftables, der chain forward und nat (pre/postrouting).

Ich habe mir selbst einen Router, erstellt mit einem NUC / Debian 10 und nftables. Das läuft auch alles wunderbar und auch die firewall regeln laufen soweit sauber. Ich bin immer noch im lern Modus, also es wird noch viel zugefügt und erweitert, aber fürs erste habe ich eine Frage zur Chain forwart vom Typ Filter.

Das ist meine /etc/nftables.conf :

Code: Alles auswählen

#!/usr/sbin/nft -f

flush ruleset

define LAN    = "enp5s0"
define WAN    = "enp0s25"


table inet filter {

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

                ct state established, related counter accept
                ct state invalid counter drop

                iifname lo accept
                iifname { $WAN, $LAN } tcp dport 22 counter accept

                drop
        }

        chain forward {
                type filter hook forward priority 0; policy drop;

                ct state new,established,related counter accept
                ct state invalid drop

                ip daddr 172.16.100.100 tcp dport 6776 counter accept

                drop
        }

        chain output {
                type filter hook output priority 0; policy drop;

                ct state established, related, new accept
                ct state invalid drop

                oifname $WAN accept

                drop
        }
}


table ip nat {

        chain prerouting {
                type nat hook prerouting priority -100; policy accept;

                nftrace set 1
                iifname $WAN tcp dport 6776 counter dnat 172.16.100.100
        }

        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname $WAN counter masquerade
        }
}

Ich habe da die Zeile:

Code: Alles auswählen

  ip daddr 172.16.100.100 tcp dport 6776 counter accept

in der Chain forward. Diese funktioniert auch aber der counter nicht.
Wenn ich die zeile lösche, kann ich nicht mehr einloggen, wen ich sie wieder hinzufüge, geht es wieder. Dennoch, der COunter bleibt bei 0.

Wieso ? Funktionieren counter beim forwarding filter nicht ?

Und noch eine frage zu "ct state" im Forward Filter, braucht es da wirklich "new" oder sollte man dies genauer auf "LAN -> WAN = ct state new accept" stellen ?

Ich grüsse Euch

Andi

[TomL]

Das läuft auch alles wunderbar und auch die firewall regeln laufen soweit sauber.

Wie hast Du das überprüft? Und zwar gerade hinsichtlich der sicherheitsrelevanten Entscheidungen im Paketfilter. "Es läuft" oder "Es gibt keine Störungen" sagt hinsichtlich einer tatsächlichen Firewall-Funktionalität überhaupt nicht aus.

Ich habe mir selbst einen Router, erstellt mit einem NUC / Debian 10 und nftables.

Wenn der als echtes Border-Device arbeiten soll, würde ich Dir empfehlen, von solchen Experimenten abzusehen. Für diesen Fall halte ich es für deutlich verantwortungsbewusster, wenn Du auf dem System z.B. OPNsense installieren würdest und dieses dann den Anforderungen gemäß korrekt konfigurierst. Läuft Dein Router allerdings hinter einem obligatorischen Consumer-DSL-Router, braucht der eigentlich keine Firewall, es sei denn, Du willst wirklich das interne Netz von außen trennen.... aber da gehört dann ein bisschen mehr dazu, als nur ein paar Paketfilter-Regeln. Beispielsweise hätte das auch Auswirkung auf ein möglicherweise vorhandenes lokales IPv6-Geschehen, bei dem üblicherweise die Clients öffentliche IPv6-Adressen verwenden. Und die Vorteile von IPv6 abzuschalten wäre schon ziemlich dumm.

Hinsichtlich der forward-Chain ist festzustellen, dass dort nur die Pakete behandelt werden, für die auf dem lokalen Host kein Prozess wartet, die also ein anderes Ziel haben. Das bedeutet, ein Paket wird niemals in der forward-Chain UND in der input-Chain behandelt, sondern immer nur entweder oder. Insofern ist Deine Frage total schwer zu beantworten, weil man das ganze Konstrukt nicht kennt und weil in der Ferne keine Vorstellung besteht, was überhaupt beabsichtigt ist. Wenn der Counter dort nicht zählt, kann es halt sein, dass ein Paket eben gar nicht dort behandelt wird.

Vielleich hilft Dir meine Doku zu ein paar weiteren Anregungen.... darin geht es eben nicht nur um die technische Umsetzung, sondern primär um die Relevanz an sich und maßgebliche Einflussgrößen... was wiederum im Zusammenhang mit meiner Frage am Anfang steht.

[fichtl]

Guten Morgen.

Ja deine Doku werde ich mir gleich vornehmen. Ich danke Dir.

Edit:

Zu Lernzwecken, habe ich mir folgendes eingerichtet:

Zuerst ist da die UPC Box im Bridge-Modus, also kein IPv6 möglich. Der 1. Router ist ein Ausus AC87U mit der ASUSwrt-Merlin Firmware drauf. Das alles ist im 192.168.1.0/24 Netz.
In meinem Büro ist, der 2. Router der NUC.
"WAN" 192.168.1.150
"LAN" 172.16.0.1/16

Wie gesagt, es ist zu lern zwecken (routing switching), da hängen oben dann noch eine L3 und L2 Cisco Switch.
Ich mache es daran fest, das es soweit läuft, dass in einer VM mit der IP 172.16.12.200 auf dem Server, ein Tor relay läuft und auf dem NUC Router mit nftables die Regel (inet hook forward):

Code: Alles auswählen

iif "enp0s25" oif "enp5s0" ip daddr 172.16.12.200 tcp dport 54321 counter packets 915 bytes 54400 accept
iif "enp0s25" oif "enp5s0" ip daddr 172.16.12.200 tcp dport 64321 log prefix "Tor Dir: " accept

Ohne die geht es nicht und mit der geht es.

Genau das selbe mit SSH, nehme ich die Regel raus, geht nichts mehr, lasse ich diese drin geht es, aber der zähler bleibt 0.

Ich würde ja nicht einfach behaupten alles geht super, ich fange da langsam an mich in das Thema firewall / routing einzuarbeiten, aber ich erstelle teste und lerne und soweit fusioniert es mit ssh und dem forwarding, nur der zähler bleibt 0.
In der gleichen Table -> Chain -> Hook (forwarding) alle counter für div. dienste gehen, nur der SSH nicht. Es ist kein Problem, mir gehts nicht um die zahl, es ist nur wirklich komisch.

Edit_2:
Mir ist bewusst, das ich mich von "aussen" per SSH connecten muss, daher bin ich auf meinem Server in der Firma per SSH eingeloggt und teste sozusagen von der Firma aus diese regel. Auch mit dem Laptop im 192.168.1.0 Netz, bin ich da am Probieren.

Edit_3:
Ich weiss nicht wieso, warum weshalb... aber reboot tut gut, alles tut wie es muss.

[TomL]

"WAN" 192.168.1.150
"LAN" 172.16.0.1/16

Das sind beides lokale und somit rein private LAN-Adressen, die keine öffentliche (WAN) Bedeutung haben.

[fichtl]

"WAN" 192.168.1.150
"LAN" 172.16.0.1/16

Das sind beides lokale und somit rein private LAN-Adressen, die keine öffentliche (WAN) Bedeutung haben.

Das ist mir klar, ich habe es nur WAN statt LAN_OUT genannt.