Firewall-Regeländerung wirkt nicht: Regelreihenfolge und Verbindungszustand

Sie haben die Regel bearbeitet, das Ruleset neu geladen, und der Tunnel verhält sich genau wie zuvor. Dieses Ergebnis hat zwei häufige Ursachen, und sie erfordern unterschiedliche Tests. Entweder steht die neue Regel hinter einer früheren Regel, die das Paket bereits akzeptiert hat, oder der Austausch, den Sie beobachten, ist eine verfolgte Verbindung, die die Änderung nie neu bewertet. Eine Regel in einer Datei drückt Absicht aus; was über das Paket entscheidet, ist der aktive Pfad, auf den es trifft. Arbeiten Sie die folgenden Prüfungen der Reihe nach durch und halten Sie dabei einen Rückweg offen.

Regelreihenfolge und Verbindungszustand sind verschiedene Fehler

Geordnete Ketten werden von oben nach unten ausgewertet, und die erste Regel, die zu einem abschließenden Urteil kommt, beendet den Durchlauf durch diese Kette. Setzen Sie ein breites Accept über eine sorgfältig geschriebene Sperrregel, und die Sperrregel wird zur Dokumentation: Sie steht im Ruleset, ihr Zähler ist null, und kein Paket wird sie jemals erreichen. Derselbe Text auf eine andere Kette angewendet beweist ebenso wenig. In nftables hängen Basis-Ketten an Hooks mit Prioritäten, daher verhindert ein Accept in einer Kette nicht, dass eine andere Kette an einem anderen Hook oder mit anderer Priorität dasselbe Paket sieht.

Die Verbindungsverfolgung erzeugt das zweite Symptom, und von außen sieht es identisch aus. Sobald ein Flow in der Zustandstabelle steht, kehrt ein Accept für established-or-related nahe dem Kopf der Kette zurück, bevor Ihre neue Regel überhaupt befragt wird. NAT-Mappings haben dieselbe Eigenschaft: Die Übersetzung wurde festgelegt, als der Flow begann, daher schreibt eine geänderte postrouting-Regel keine Sitzung um, die bereits läuft. Deshalb scheint eine Änderung um 09:00 für eine neue Verbindung zu wirken und für die Sitzung, die jemand um 08:55 geöffnet hat, nichts zu tun.

Cloud-Sicherheitsgruppen fügen ein drittes Modell hinzu, das Leute erwischt, die mit iptables gelernt haben. Ihre Inbound-Regeln sind eine Allow-List, die als Menge ausgewertet wird statt als First-Match-Durchlauf, sie sind stateful, und das Entfernen einer Allow-Regel beendet keine Flows, die bereits verfolgt werden. First-Match-Semantik auf einer Plattform anzunehmen, die sie nicht hat, führt zu selbstsicheren, falschen Schlüssen.

Lesen Sie das aktive Ruleset, nicht die Datei, die Sie bearbeitet haben

Beginnen Sie mit dem, was der Kernel gerade durchsetzt. Eine gespeicherte Konfiguration, die nie angewendet wurde, erklärt erstaunlich viele unveränderte Verhaltensweisen, und sie auszuschließen kostet einen Befehl:

nft list ruleset
iptables-save

Fragen Sie dann, ob Ihre Regel überhaupt erreicht wird. Paketzähler beantworten das direkt und besser als jede Überlegung zur Absicht:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Eine Sperrregel mit null Paketen nach einem echten Testversuch ist kein Richtlinienproblem, sondern ein Positionsproblem. Sie zu verschieben ist eine Änderung in einer Zeile, und die Syntax ist genau das, was den ursprünglichen Fehler verursacht hat. Mit iptables -I fügt ein, und -A hängt an; mit nftables insert platziert eine Regel am Anfang der Kette, während add anhängt. Wenn eine Regel gewinnen muss, sagen Sie es ausdrücklich, statt sich auf die Reihenfolge zu verlassen, die zufällig geladen wurde.

Beweisen Sie, ob der Flow verfolgt wird

Bevor Sie die Regel beschuldigen, prüfen Sie, ob der Verkehr überhaupt eine verfolgte Verbindung ist. Fragen Sie die Zustandstabelle nach dem konkreten Flow, statt sie komplett auszugeben:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Die Auflistung zeigt den Zustand und die verbleibende Zeitüberschreitung, und so unterscheiden Sie eine etablierte Sitzung von einem frischen Versuch; der Ereignismodus druckt Aktualisierungen, sobald sie geschehen, was nützlich ist, während Sie einen Client neu verbinden. Wenn der Flow bereits mit etabliertem Zustand vorhanden ist, bevor Sie etwas angefasst haben, wird keine Änderung der Filterregeln sein Schicksal ändern. Das ist kein Fehler in der Firewall, es ist der Vertrag der zustandsbehafteten Filterung.

Widerstehen Sie der Abkürzung, die ganze Tabelle auf einem Produktions-Gateway zu leeren. conntrack -F ist verfügbar, und es zerstört auch jeden verfolgten Flow auf der Maschine, einschließlich der Verwaltungssitzung, aus der Sie arbeiten, und des Tunnels, der Ihre Shell trägt. Einzelne Einträge lassen sich löschen, wenn Sie es wirklich brauchen, aber ein frischer Flow von einem neuen Quellport ist normalerweise ein saubereres Experiment.

Manche Pfade werden nicht verfolgt, und sie verhalten sich umgekehrt. Verkehr, der als notrack in der raw-Tabelle markiert ist, manche Tunnel, die die normalen Hooks umgehen, und asymmetrisches Routing, das einen Flow über zwei Gateways aufteilt, erzeugen allesamt Pakete, die einzeln ausgewertet werden, oder Zustand, der an beiden Enden nie entsteht. Wenn sich die Zähler bei jedem Paket bewegen, verdächtigen Sie diese Art von Pfad, bevor Sie die Reihenfolge verdächtigen.

Testen Sie aus einem frischen Flow mit einem Rückweg

Bevor Sie eine Regel testen, die den Fernzugriff abschneiden könnte, richten Sie einen Wiederherstellungspfad ein: die Konsole des Anbieters, eine serielle Konsole, eine Out-of-Band-Verwaltungsadresse oder eine zweite Schnittstelle, die die Regel nicht treffen kann. Ein Rollback-Timer ist ein sinnvoller Begleiter, denn er stellt das vorherige Ruleset wieder her, selbst wenn Ihre Sitzung mitten im Test abstirbt.

Testen Sie dann mit einem Austausch, den der Zustand noch nicht abgedeckt haben konnte. Trennen Sie den Client und verbinden Sie ihn neu, damit ein neues Fünftupel entsteht, und beobachten Sie beide Enden, während das geschieht:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Führen Sie den Test in beide Richtungen aus. Eine Regel, die den neuen eingehenden Handshake blockiert, kann den Antwortpfad weiterhin zulassen, oder umgekehrt, und ein einseitiges Ergebnis ist der übliche Grund, warum eine Sperre nur halb funktioniert. Verbinden Sie sich nach dem Test noch einmal, um den stabilen Zustand zu bestätigen, und prüfen Sie, ob legitimer Verwaltungszugriff überlebt hat; eine Regel, die auf einen Port geschrieben wurde, neigt dazu, einen breiteren Bereich zu treffen als beabsichtigt.

Zweck und Position zusammen mit der Regel festhalten

Eine Regel ohne festgehaltenen Zweck ist eine Regel, die niemand zu entfernen wagt. Halten Sie zu jedem Sperreintrag den Flow fest, den er schützt, die Kette und den Hook, in dem er lebt, die Position, die er gegenüber breiteren Accepts halten muss, und den Test, der ihn bewiesen hat. Wenn jemand sechs Monate später das umgebende Ruleset bearbeitet, ist diese Notiz die einzige Warnung, dass die Position beabsichtigt war.

Bevor Sie die Änderung abschließen, bestätigen Sie vier Dinge: Das laufende Ruleset stimmt mit der Datei überein, die neue Regel hat nach einem frischen Versuch Zähler ungleich null, die Gegenrichtung und der Verwaltungszugriff funktionieren noch, und Sie haben sich einmal neu verbunden, um den stabilen Zustand zu beweisen statt den Zustand einer Sitzung, die älter ist als die Änderung. Wenn irgendetwas davon ungeprüft ist, ist die Änderung nicht fertig, was auch immer der Tunnel tut.