nftables grundsätzliches

[otto001]

Hallo,

ich versuche grade, mich in nftables einzuarbeiten, habe aber ein paar Probleme damit.
Wir haben ein IPv4/IPv6 Setup und ich möchte, daß der betroffene host (in beiden IP-Stacks) von überallher pingbar ist.
Außerdem soll er von bestimmten Netzen aus per ssh erreichbar sein sowie ntp, syslog, smtp bzw submission in bestimmten Netzen erreichen können.
Da es sich um einen Reverse-Proxy handelt soll er außerdem http und https eingehend und ausgehend von/zu allen Hosts zulassen.

Leider scheitert beispielsweise ping in IPv6.
Ich habe den Verdacht, daß ich irgendwie einen falschen Ansatz verfolge und wäre froh über Ratschläge.

Ich habe derzeit folgendes in /etc/nftables.conf (die Netze habe ich zum posten geändert):

Code: Alles auswählen

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set netze_intern4 {
         type ipv4_addr
         flags interval
         auto-merge
         elements = { 192.168.240.0/24, 192.168.244.0/24, 192.168.245.0/24 }
  }
  set netze_intern6 {
         type ipv6_addr
         flags interval
         auto-merge
         elements = { 2020:67a:1434:1::/64 }
  }
  chain incoming {
    type filter hook input priority 0;
    policy drop;
    ct state invalid counter drop comment "early drop of invalid packets"
    ct state established,related accept comment "accept all connections related to connections made by us"
    iifname lo accept comment "accept loopback"
    iif != lo ip daddr 127.0.0.1/8 counter drop comment "drop connections to loopback not coming from loopback"
    iif != lo ip6 daddr ::1/128 counter drop comment "drop connections to loopback not coming from loopback"
    ip protocol icmp counter accept comment "accept all ICMP types"
    ip6 nexthdr icmpv6 counter accept comment "accept all ICMP types"

    tcp dport { ssh } ip saddr @netze_intern4 accept comment "accept SSH from internal net"
    tcp dport { ssh } ip6 saddr @netze_intern6 accept comment "accept SSH from internal net"
    tcp dport { http, https } accept
    # uncomment to enable log, choose one
    log flags all
  }
  chain outgoing {
    type filter hook output priority 0;
    policy drop;
    ct state established,related accept
    iifname lo accept
    ip protocol icmp accept #ausgehende pings
    tcp dport { http, https, 53, ntp, smtp, submission, 514 } accept
    udp dport { 53, 514 } accept
 }
}

Erkennt jemand, warum zb ein ping in IPv6 nicht funktioniert? (in IPv4 tut es)
Vielen Dank im Voraus!
Otto

[TomL]

Erkennt jemand, warum zb ein ping in IPv6 nicht funktioniert?

Eingehend nicht?
Ausgehend nicht?
Beide Richtungen gehen nicht?

[otto001]

Sorry, war nicht präzise genug.
Beide Richtungen tun nicht bei IPv6
Auf dem host mit nftables bekomme ich:

ping: sendmsg: Operation not permitted

Wenn ich versuche, den host von einer anderen Maschine zu pingen:

Destination unreachable: Address unreachable

Sobald ich nftables stoppe, gehen beide Richtungen.
ping auf IPv4 geht immer in beide Richtungen - unabhängig davon, ob die rules aktiv sind oder nicht.

[TomL]

Ich sehe keine ausgehende Regel für ipv6-icmp.

[otto001]

Stimmt. Du hast recht.
Habe die Regel nun eingefügt und ausgehende pings gehen jetzt auch auf IPv6.
Jetzt geht auch ping auf IPv6 EINGEHEND????? - obwohl ich eingehend nichts geändert habe?!
ARGH - ist ja eigentich logisch. Wenn ausgehend nichts erlaubt ist, kann der host auch nicht antworten ^^
Danke für den Schubs!

[otto001]

Dummerweise tut ssh (eingehend aus dem Netz in netze_intern6) bei IPv6 noch nicht. Bei IPv4 tut es (aber nur aus den Netzen in netze_intern4 - wie erwartet).
Hat da evtl noch jemand eine Idee dazu?
Danke im voraus
Otto

[TomL]

Hat da evtl noch jemand eine Idee dazu?

Ja sicher... ich noch mal .... wenn ich ehrlich bin, hatte ich mich zuvor gewundert, dass dieses Konstrukt überhaupt funktioniert. Eigentlich war ich der Meinung, dass IPv6 kaputt gefiltert wurde und das nach Ablauf der preferred lifetime der IPv6-Stack gar nicht mehr leben wird.... kam dann aber auf den Schluss "nee, muss wohl anscheinend doch funktionieren"

Hier als Lösung zu diesem aktuellen Problem: Es fehlt noch eine LLA- und ggf. ULA-Beachtung.... und zwar in der Elementlist. Im Regelfall werden diese Adressen res. Ranges vom DSL-Router verwendet.

[otto001]

Hi!

Danke für die rasche Antwort!
Ich kann das erst morgen testen. Aber ich verstehe es nicht.
Warum müssen die ULA und LLA in der IPv6-Liste sein? Ist mir grade überhaupt nicht klar?
Wäre doch in etwa das gleiche, wenn bei IPv4 localhost drin sein müsste - wie man sieht, kenne ich mich mit IPv6 noch nicht so richtig aus...
Es handelt sich hier um ein Firmen-Netz, das nicht an DSL hängt - ist also in dem Fall eher die Range von einem der Switches oder so...
Vielen Dank!
Otto

[TomL]

Wenn Du mit

Code: Alles auswählen

ip a

nachsiehst, wirst Du feststellen, dass das Interface auch eine LLA-Adresse hat... darüber kommt das Router-Advertisement (Prefix-Delegation) rein und wird für Router-Solicitation gebraucht.... das ist also für den IPV6-Stack selber wichtig. Das NDP für IPv6 ist in Deinem Filter auch noch gar nicht berücksichtigt. Allerdings halte ich mich hier zurück, weil ich nicht die geringste Vorstellung darüber habe, wie dieses Netz aufgebaut ist.

Es handelt sich hier um ein Firmen-Netz, das nicht an DSL hängt

Das wundert mich aber auch... und das sagt eigentlich was anderes aus:

Code: Alles auswählen

elements = { 2020:67a:1434:1::/64 }

Nur einen gutgemeinten Rat noch: Erlaube keinesfalls Zugänge aus dem Internet ins lokale Firmen-Netzwerk. Dazu solltest Du Dir professionelle Kenntnisse durch einen Fachmann an die Seite stellen.

[otto001]

Danke sehr!
Also eigentlich BIN ich der Fachmann gg
Aber halt noch neu in IPv6 und auch nftables
(hab bisher nur IPv4 und iptables genutzt)

Wir haben ja auch mehrere (kommerzielle) Firewalls an den verschiedenen Standorten (und bald auch eine eigene Web Application Firewall) - nur will ich die Systeme, die in irgend einer Form aus dem Internet erreichbar sind (Reverse Proxy und diverse Web/Applikations-Server) noch zusätzlich absichern.
Damit im Falle eines Falles beispielsweise kein Zugriff auf Rechner per ssh im gleichen Segment möglich ist etc.

Und da ja nftables ab Bullseye iptables ablösen soll, ergreife ich die Gelegenheit, mich hier gleich damit auseinanderzusetzen.

Dass wir grade dabei sind, IPv6 flächendeckend auszurollen ist hier scheinbar nicht gerade hilfreich

Ich werde mich da morgen noch einmal genauer einlesen, was ULA und LLA betrifft.

Vielen Dank für Deine Antwort!

Otto

[TomL]

Und da ja nftables ab Bullseye iptables ablösen soll, ergreife ich die Gelegenheit, mich hier gleich damit auseinanderzusetzen.

iptables wurde bereits mit Buster abgelöst... es gibt da jetzt nur sowas wie eine Kompatibilitätschicht. Eigentlich sollten in einer Standard-Buster-Installation die iptables-Module gar nicht mehr geladen werden, sondern nur noch nft. Also zumindest auf meinen Buster-Setups gibts ohne Eingriffe durch mich keine iptables mehr... nur noch einen Translator, der solche alten Statements in nft-Syntax übersetzt.

[otto001]

wirklich? das letzte debian, wo ich mit iptables gearbeitet habe, war (glaube ich) stretch.
Ist aber gut zu wissen, dass es das in buster eigentlich auch schon nicht mehr gibt - ich hab mir das gleich gar nicht angesehen unter buster, weil ich das mit nftables gelesen hatte...
bg
Otto

[Scheidewasser]

Danke sehr!
Also eigentlich BIN ich der Fachmann gg
Aber halt noch neu in IPv6 und auch nftables
(hab bisher nur IPv4 und iptables genutzt)

Wir haben ja auch mehrere (kommerzielle) Firewalls an den verschiedenen Standorten (und bald auch eine eigene Web Application Firewall) - nur will ich die Systeme, die in irgend einer Form aus dem Internet erreichbar sind (Reverse Proxy und diverse Web/Applikations-Server) noch zusätzlich absichern.
Damit im Falle eines Falles beispielsweise kein Zugriff auf Rechner per ssh im gleichen Segment möglich ist etc.

Otto

Hm, Du verdienst Dein Geld mit netfilter und Du fragst hier im Forum um Hilfe?

Da gibt es doch bestimmt qualifiziertere Quellen, ich meine Quellen die von Profis frequentiert werden. Das Df ist nicht so die Quelle für "Rund um netfilter". Hier ist wenig los zu dem Thema. Eigentlich gar nichts. Meist antwortet nur ein User. Die meisten User in diesem Forum verlassen sich offensichtlich auf den Router oder so was. Einige betreiben sogar Server völlig ohne netfilter. Siehe viewtopic.php?p=1060583&sid=65899970c14 ... 7#p1060583

Bei mir ist ipv6 deaktiviert. Ich wüßte auch nicht welche ipv6 Webseite ich aufrufen sollte. Mache ich ein nslookup für "irgendwas", dann werden mir bei 100 Aufrufen vielleicht 170 ipv6 Verweise angezeigt. Rufe ich davon was im Browser auf, dann kommt immer ein Platzhalter oder ein redirect auf ipv4. Also habe ich ipv6 temporär deaktiviert und warte auf bessere ipv6 Zeiten.

Das mit der Ablösung von iptables halte ich für mainstream.

[mat6937]

Einige betreiben sogar Server völlig ohne netfilter.

BTW: Wie könnte deiner Meinung nach, netfilter einen Server schützen, wenn dieser z. B. auf UDP-Port 1194 und den TCP-Ports 22 bzw. 443 lauschen muss?

[otto001]

@Scheidenwasser:
Ich habe ehrlich gesagt lange überlegt, ob und was ich auf solche Kommentare antworten soll.
Vermutlich ist es besser, nicht darauf einzugehen und Dich in Deiner kleinen Welt zu lassen

[otto001]

@mat6937:
Es geht hier weniger darum, den Server zu schützen, auf dem eh schon ein Bösewicht ist.
Eher geht es darum, zu verhindern, daß dieser sich weiter im Netzwerk (zb in der DMZ) verbreitet.