Firewall-Regeln nur für NEW schließen nicht jeden WAN-Pfad

Das Ablehnen neuer ausgehender Verbindungen am WAN sieht nach einer Fail-Closed-Richtlinie aus, ist aber ein engeres Versprechen, als es scheint. Pakete, die zu bereits bestehenden Flüssen gehören, passen nicht darauf, und viele Antworten ebenso wenig. Diese Lücke ist leicht zu übersehen, weil die Regel so gelesen wird, als decke sie die Schnittstelle ab und nicht einen Verbindungszustand darauf. Das Zustands-Matching als Urteil zu lesen erzeugt genau das falsche Gefühl von Geschlossenheit.

Zustand ist eine Trefferbedingung, kein Urteil

Connection Tracking klassifiziert Pakete danach, was die Firewall bereits gesehen hat, nicht danach, was die Anwendung glaubt. Ein in beide Richtungen beobachteter Fluss gilt als established, und seine späteren Pakete bleiben established, selbst wenn die Route darunter von einem Tunnel auf den gewöhnlichen Uplink wechselt. Auch die Antwort auf eine eingehende Verbindung kann established-Verkehr sein. Diese Pakete werden nie wieder new.

Deshalb kann eine auf neue Verbindungen beschränkte Regel nicht belegen, dass jedes geschützte Paket blockiert wird. Sie überlässt die anderen Zustände dem, was der Rest des Regelsatzes mit ihnen tut, und das kann ein früher in der Kette platziertes Accept sein.

Lesen Sie die Regel in ihrer Umgebung

Ein breites Accept für established- und related-Verkehr vor dem Block lässt ein Paket durch, bevor der Block überhaupt ausgewertet wird. Die Zustandsbedingung aus einer späteren Regel zu entfernen ändert daran nichts, weil die Auswertung sie nie erreicht. Die Reihenfolge entscheidet das Ergebnis, und das Zustands-Matching entscheidet, welche Pakete diese Reihenfolge erreichen.

Prüfen Sie den wirksamen Regelsatz und nicht die Datei, die Sie bearbeitet haben, einschließlich Sprüngen in andere Ketten und allem, was die Plattform erzeugt. Auf einem iptables-verwalteten Router zeigt das Auflisten der Kette die Regeldeinitionen, und die Ketten, auf die sie verweist, müssen ebenfalls verfolgt werden. Ein natives nftables-System verlangt die Prüfung seines eigenen Regelsatzes und der Hook-Prioritäten, da Firmware selten identische Ketten erzeugt.

Zähler zeigen, welche Regel tatsächlich getroffen hat, und sie sind meist aussagekräftiger als ein Paketmitschnitt nach der Entscheidung. Eine Regel mit Zählerstand null wurde nicht erreicht, was auch immer ihre Position nahelegt.

Drücken Sie das Verbot unabhängig vom Zustand aus

Wenn eine Gruppe von Clients niemals außerhalb des Tunnels ins Internet gelangen darf, sagen Sie das direkt, statt es mit einem Zustand anzunähern. Die Regel muss nach Quelle, Ausgang und Ziel auswählen, ohne vom Verbindungszustand abzuhängen, und sie muss dort stehen, wo kein früheres Accept sie umgehen kann. Verwaltungszugang und Ausnahmen für das lokale Netz bekommen dann eigene ausdrückliche Regeln, sodass die Absicht in der Richtlinie sichtbar ist.

Reject statt drop zu wählen ändert, wie der getroffene Verkehr scheitert, und es vergrößert nicht die Menge der Pakete, die die Regel auswählt. Eine abgelehnte Verbindung und ein stiller Timeout sind verschiedene Symptome, die auf dieselbe Auswahl zeigen.

Eine Richtlinie, die Antworten auf von außen initiierten Zugriff über das WAN bewusst erlaubt, ist vertretbar. Sie muss nur so beschrieben werden, statt als vollständige Isolation ausschließlich durch den Tunnel zu gelten.

Prüfen Sie, wer tatsächlich in der Gruppe ist

Das Beispiel deckt weitergeleiteten IPv4-Verkehr aus einem Präfix über eine Schnittstelle ab. Es sagt nichts über IPv6, einen zweiten Uplink oder Verkehr, den der Router selbst erzeugt. Ein Router, der als DNS-Resolver arbeitet, sendet seine eigenen Upstream-Abfragen, und die laufen überhaupt nicht durch die forward-Kette.

Bestätigen Sie, dass die geschützten Clients noch Adressen innerhalb des gewählten Präfixes haben, denn ein Gerät, das es verlassen hat, ist zufällig direkt und nicht per Richtlinie. Die Sperre ohne Prüfung des Ausnahmedesigns auf das ganze LAN auszuweiten nimmt außerdem meist den eigenen Verwaltungsweg weg.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Testen Sie dann einen alten Fluss neben einem neuen. Ein frischer Verbindungsversuch und eine bereits aktive bidirektionale Übertragung verhalten sich unter dieser Regel unterschiedlich, und nur beides zu testen zeigt, welche Richtlinie Sie wirklich haben.