☰

iptables/nftables: Wie kann der gesamte weitergeleitete Datenverkehr von der Verbindungsverfolgung auf einem Router ausgeschlossen werden?

tag-icon • tag-icon iptables nftables
iptables/nftables: Wie kann der gesamte weitergeleitete Datenverkehr von der Verbindungsverfolgung auf einem Router ausgeschlossen werden?

Eine Linux-Box verfügt über mehrere Netzwerkschnittstellen. Die IP-Weiterleitung ist für IPv4 und IPv6 aktiviert.

Ich möchte die auf dem Router selbst laufenden Dienste durch eine Stateful Firewall schützen. Dazu muss das Connection Tracking aktiviert werden. Gleichzeitig möchte ich allen Datenverkehr, der von einer Schnittstelle zur anderen weitergeleitet wird, vom Connection Tracking ausschließen.

Für die Stateful Firewall würde ich normalerweise die INPUT- und OUTPUT-Ketten der Filtertabelle verwenden. Weitergeleiteter Datenverkehr würde an die FORWARD-Kette gehen. Aber meines Wissens gibt es in der FORWARD-Kette keine Möglichkeit, Datenverkehr als nicht verfolgt zu markieren. Eine solche Logik muss in die PREROUTING-Kette in der Rohtabelle gehen. Aber ich glaube, in der PREROUTING-Kette wurde noch nicht entschieden, ob Datenverkehr weitergeleitet wird oder nicht.

Die Verbindungsverfolgung hat viele Nachteile, beispielsweise Paketverluste, wenn die Liste der verfolgten Verbindungen ihre maximale Größe erreicht hat.

Was ist die einfachste Möglichkeit, weitergeleiteten Datenverkehr (und nur diesen) von der Verbindungsverfolgung auszuschließen?

Antwort1

Für einen generischen Regelsatz kann man fragenNftableseine Routensuche im Voraus durchzuführen mit demfibAusdruck, anstatt darauf zu warten, dass der Routing-Stack dies tut. Dies ermöglicht die Einbeziehung der (zukünftigen)AusgabeSchnittstelle, obwohl sie noch nicht existiert (Routing-Entscheidung wurde nicht getroffen), auf Kosten einer zusätzlichen Suche. Wenn die Ergebnisse dann zeigen, dass das Paket geroutet wird, verhindern Sie das Tracking mithilfe einesnotrackStellungnahme.

FIB-AUSDRÜCKE

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

AFlunkereiAusdruck fragt denFlunkerei(Forwarding Information Base), um Informationen wie den Ausgabeschnittstellenindex zu erhalten, den eine bestimmte Adresse verwenden würde. Die Eingabe ist ein Tupel von Elementen, das als Eingabe für dieFlunkereiNachschlagefunktionen.

NOTRACK-ERKLÄRUNG

Mit der Anweisung „notrack“ können Sie die Verbindungsverfolgung für bestimmte Pakete deaktivieren.

notrack

Beachten Sie, dass diese Anweisung, um wirksam zu sein, auf Pakete angewendet werden muss, bevor einKontaktSuche erfolgt. Daher muss es in einer Kette sitzen mit entwederVorab-RoutingoderAusgabeHook und eine Hook-Priorität von -300 oder weniger.

Man sollte also einen "einfachen" Routencheck machen vonVorab-Routing, wobei nur die Zieladresse als Selektor verwendet wird und geprüft wird, ob eine Ausgabeschnittstelle vorhanden ist (nicht routbare Pakete oder Pakete, die für den Host bestimmt sind, lösen keine auf). Es gibt eine Ausnahme für diesiehe(Loopback)-Schnittstelle, um es zu verfolgen: Während es lokalen Verkehr darstellt, ein gesendetes Paket (über dieAusgabePfad) vom Host zu sich selbst kommt zurück durchVorab-RoutingPfad und hat eine Ausgabeschnittstelle vonsieheauch. Da das ausgehende Paket bereits eineKontaktEintrag, halten Sie dies besser konsistent.

nft add table ip stateless
nft add chain ip stateless prerouting '{ type filter hook prerouting priority -310; policy accept; }'
nft add rule ip stateless prerouting iif != lo fib daddr oif exists notrack

Das Ersetzen der ipFamilie durch die inetKombifamilie sollte das gleiche allgemeine Verhalten auf IPv4+IPv6 erweitern.

Um genauer zu sein, könnte man die zukünftige Ausgabeschnittstelle fib daddr oif eth1beispielsweise mit angeben, was mehr oder weniger dem Äquivalent von entspricht oif eth1, aber auch in verfügbar istVorab-Routing.

Wenn die Topologie im Voraus bekannt ist, kann natürlich eine FIB-Suche vermieden werden, indem eine oder mehrere Regeln auf Basis von Adresstests verwendet werden, da die Routen dann dem Administrator im Voraus bekannt sind. Möglicherweise muss ein Benchmarking der Ergebnisse durchgeführt werden, um zu wissen, ob dies interessanter ist als die Beibehaltung einer generischen Methode.

Ersetzen Sie beispielsweise mit den vom OP bereitgestellten Informationen die vorherige Regel durch:

nft add rule ip stateless prerouting 'ip daddr != { 192.168.1.1, 192.168.2.1, 127.0.0.0/8 } notrack'

sollte einen nahezu gleichwertigen Effekt haben. 127.0.0.0/8 ist aus den gleichen Gründen wie oben vorhanden, mit demsieheSchnittstelle.

Handhabung von Broadcasts (wie 192.168.1.255 empfangen aufeth0) und Multicast (wie Link-Local 224.0.0.1, das über eine Schnittstelle empfangen wird) funktionieren bei beiden Methoden möglicherweise nicht gleich und auch nicht wie erwartet und erfordern möglicherweise zusätzliche Regeln für spezielle Anforderungen, insbesondere bei der zweiten Methode. Da das Verfolgen von Broadcast und Multicast selten sinnvoll ist, weil eine Antwortquelle nicht das ursprüngliche Ziel der Broadcast- oder Multicast-Adresse sein wird (und kann), sodass der Conntrack-Eintrag nie bidirektionalen Datenverkehr „sieht“, spielt es für Stateful-Regeln normalerweise keine große Rolle.

Anmerkungen

  • Dies ist normalerweise nicht mit Stateful NAT kompatibel.

    Nach meinem Verständnis wird DNAT zu einem Remote-Host seinen Antwortverkehr nicht de-NATed bekommen und fehlschlagen, und weitergeleitetes SNAT wird nicht ausgelöst, da es keineKontaktEintrag erstellt. Selten verwendetes SNAT im Eingabepfad sollte in Ordnung sein, und eine Kombination aus DNAT+SNAT (unter Verwendung einer lokalen Adressquelle) könnte auch funktionieren, da dann sowohl in der ursprünglichen als auch in der Antwortrichtung ein lokales Ziel beteiligt ist, sodass einKontaktDer Eintrag sollte dann immer korrekt angelegt bzw. nachgeschlagen werden.

  • Standardregelsatz

    Aktuelle Regeln mitiptablesoderNftables(in einer eigenen Tabelle) kann dann wie gewohnt durchgeführt werden, einschließlich Stateful-Regeln für den Host selbst. Da gerouteter Verkehr keineKontaktEinträge und Regeln, sofern welche solchen Datenverkehr betreffen, sollten ausschließlich zustandslos sein und keine ctAusdrücke verwenden, da diese nie übereinstimmen würden.

  • Verhalten überprüfen

    Das Gesamtverhalten lässt sich auch ohne entsprechende Firewall-Regeln wie folgt überprüfen:

    • Verwenden Sie eine Dummy- ctRegel, um sicherzustellen, dass dieKontaktDie Einrichtung wird im aktuellen Netzwerk-Namespace registriert.

      nft add table ip mytable
nft add chain ip mytable mychain '{ type filter hook prerouting priority -150; policy accept; }'
nft add rule ip mytable mychain ct state new

    • verwenden Sie dieconntrackTool zum Verfolgen von Ereignissen:

      conntrack -E

    • Generieren Sie Datenverkehr aus der Ferne

      NEUKontaktEs werden dann Einträge für den vom Router zu empfangenden Datenverkehr erstellt, jedoch nicht für den gerouteten Datenverkehr.

verwandte Informationen