Firewall-Änderungen testen, ohne sich selbst auszusperren

Die Regel wird eingespielt, das bereits offene Terminal antwortet weiter, und die nächste Anmeldung wird abgelehnt. Genau diese Lücke macht die ganze Schwierigkeit aus, eine Firewall-Änderung über die Verbindung zu testen, die man gerade ändert. Das Connection Tracking entscheidet einmal und schaut danach nicht mehr hin, deshalb ist ein bestehender Flow die einzige Probe, die die neue Richtlinie nicht sehen kann. Im Folgenden werden die drei Wege zurück verglichen, danach wird die Reihenfolge festgelegt, in der die Regeln geändert und geprüft werden.

Warum die überlebende Sitzung der schwächste Beweis ist

Eine zustandsbehaftete Firewall bewertet das erste Paket eines Flows und behält dieses Urteil, solange der Eintrag besteht. Später hinzugefügte Regeln gelten für Flows, die danach beginnen; deshalb bleibt das Fenster, in dem man tippt, nutzbar, während alle anderen abgelehnt werden. Was man daraus lernt, beschreibt die Richtlinie, die vor Minuten galt. Selbst ein Mitschnitt auf diesem Flow zeigt nur eine Entscheidung, die die Maschine bereits getroffen hat.

Behandle die funktionierende Sitzung als Notausstieg und nicht als Messung. Jede sinnvolle Prüfung muss einen neuen Flow aus einer Quelle öffnen, die die neue Regel bewertet, und die erste Prüfung sollte die sein, deren Scheitern am meisten schmerzt. Wenn diese Sitzung der einzige Weg hinein ist, ist die Änderung noch nicht reif.

Drei Wege zurück, geordnet nach ihrer Abhängigkeit

Ordne die Optionen danach, wie stark sie vom getesteten Gerät abhängen, denn diese Rangfolge ist es, nach der man greift, wenn sich die Regel als falsch erweist. Eine Konsole, die nie durch die Firewall läuft, ist unabhängig, ein geprobter Rollback fast, und die bereits offene Sitzung ist es nicht.

Melde dich vor der Änderung über die Konsole an und beweise, dass sie funktioniert, denn ein Out-of-Band-Weg, den man nie benutzt hat, ist ein Diagramm und kein Rückfallweg. Ein Rollback verdient seinen Platz erst nach einer Probe auf dieser Plattform, mit diesem Regelsatz und nach dem freigegebenen Verfahren statt Improvisation auf einer laufenden Maschine. Schreib die Schritte auf und lass sie von jemand anderem zurücklesen. Wenn die Abfolge dein Gedächtnis braucht, um zu Ende zu kommen, ist sie kein Plan.

Eine Änderung, dann eine Verbindung, die bewertet werden muss

Sichere den laufenden Regelsatz und die Datei, die ihn besitzt, und nimm dann eine einzige eng begrenzte Änderung vor. Eine Änderung pro Test hält das Ergebnis zuordenbar; zwei auf einmal hinterlassen eine funktionierende Maschine und keine Ahnung, welche Änderung gewirkt hat. Wo die Plattform eine Konfiguration prüfen kann, ohne sie zu laden, tue das zuerst, damit ein Tippfehler scheitert, solange nichts auf dem Spiel steht.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Starte dann eine neue Sitzung von einer Quelle aus, auf die die geänderte Regel passt, während die Konsole noch verbunden ist. Wiederhole es einmal, wenn es gelingt, denn der erste Versuch kann auf einem Eintrag landen, den die Tabelle bereits hatte. Wenn es scheitert, hast du noch einen Weg hinein und eine Entscheidung zum Rückgängigmachen, und das ist das billigste schlechte Ergebnis, das es gibt.

Zähler, Zustand und Datei beantworten unterschiedliche Fragen

Jede der drei Beobachtungen kann für sich überzeugend wirken und dich über die anderen beiden täuschen. Zähler zeigen, ob der gerade erzeugte Flow die bearbeitete Regel erreicht hat. Die Zustandstabelle zeigt, welche Flows die Maschine für bereits aufgebaut hält; so kann eine kaputte Regel weiterhin gesund aussehen. Die gesicherte Datei zeigt, was das Gerät nach dem nächsten Neuladen tun wird, und das muss nicht das sein, was der laufende Regelsatz jetzt tut.

ss -tn state established

Lies Zähler als Differenz und nicht als Summe, denn die einzige Zahl, die zählt, ist die, die dein Testflow bewegt hat. Eine Regel, deren Zähler nie steigt, trifft nicht zu, so richtig sie auf dem Papier auch aussieht. Bestätige auch den Ablehnungsfall: Eine Richtlinie, die noch nie etwas abgelehnt hat, hat nie bewiesen, dass sie ablehnt, was du blockieren wolltest. Arbeite eine Schnittstelle in jeder Familie durch, die die Installation tatsächlich führt, denn eine v4-Regel sagt nichts über einen v6-Flow.

Aus dem gesicherten Regelsatz wiederherstellen, dann die Datei angleichen

Wenn die Änderung scheitert, lade den gesicherten Regelsatz, statt erlaubende Regeln hinzuzufügen, bis die Anmeldungen wieder funktionieren. Jedes zusätzliche Allow dämpft das Symptom und hinterlässt ein Loch, das den Vorfall und die Erinnerung daran überlebt. Wiederherstellen, neu verbinden und dann den gescheiterten Vergleich neben der Aufzeichnung des Versuchs aufbewahren.

Nach einer erfolgreichen Änderung soll die Datei auf der Festplatte den laufenden Regelsatz beschreiben, und bestätige, dass ein Neuladen ihn reproduziert. Ein laufender Regelsatz, der von seiner eigenen Konfigurationsdatei abgewichen ist, ist eine Falle für den nächsten Neustart.