Einführung
Regeln, die mit dem Befehl iptables hinzugefügt werden, verändern die aktive Firewall im Kernel. Eine solche unmittelbare Änderung allein ist jedoch noch keine dauerhafte Konfiguration. Administratoren serialisieren IPv4-Regeln üblicherweise mit iptables-save und laden dieses Format mit iptables-restore wieder. Auf Debian- und Ubuntu-Systemen ist /etc/iptables/rules.v4 eine gängige Persistenzdatei, sofern ein geeigneter Loader für den Systemstart aktiviert ist.
Betrachten Sie den Ablauf als drei getrennte Ebenen. Der aktive Regelsatz beschreibt, was der Kernel momentan durchsetzt. Eine gespeicherte Regeldatei enthält lediglich Text auf dem Datenträger, bis ein Werkzeug oder Dienst sie wiederherstellt. Eine Baseline-Sicherung ist ein bekannter Ausgangszustand, der zum Zurücksetzen aufbewahrt wird. Die Änderung einer Ebene aktualisiert die beiden anderen nicht automatisch. Daher müssen Administratoren jeden Übergang bewusst speichern, wiederherstellen und überprüfen.
In diesem Lab sichern Sie die ursprüngliche Firewall als Wiederherstellungspunkt, fügen eine eng gefasste Serviceregel hinzu und speichern sie, prüfen die gespeicherte Datei vor ihrer Anwendung, simulieren das erneute Laden eines Regelsatzes und stellen abschließend die ursprüngliche Baseline wieder her. Dabei unterscheiden Sie drei wichtige Zustände: die aktiven Regeln, die gespeicherte Regeldatei und die Rücksetzdatei.
Aktive IPv4-Firewall sichern
In diesem Schritt erfassen Sie den Ausgangszustand der Firewall, bevor Sie Änderungen vornehmen. Eine Rücksetzdatei stellt einen bekannten, funktionierenden Zustand bereit, falls sich spätere Befehle nicht wie erwartet verhalten.
Wechseln Sie in das Projektverzeichnis.
cd /home/labex/project
Stellen Sie sicher, dass der Testdienst verfügbar ist, bevor Sie die Regeln ändern.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Dies ist ein Kontrolltest. 127.0.0.1 verwendet die Loopback-Schnittstelle, --noproxy '*' hält die Anfrage lokal, selbst wenn Proxy-Variablen konfiguriert sind, und --fail --silent liefert eine saubere Antwort mit einem zuverlässigen Rückgabestatus. Ein funktionierender Ausgangszustand erleichtert die spätere Interpretation des Firewall-Verhaltens.
Verwenden Sie iptables-save, um den vollständigen IPv4-Regelsatz auszugeben. Die Pipe leitet diese Ausgabe an tee weiter. Dadurch wird baseline.v4 geschrieben, während der Befehl weiterhin problemlos als normaler Lernbenutzer ausgeführt werden kann.
sudo iptables-save | tee baseline.v4 >/dev/null
Die Berechtigungsgrenze ist bewusst gewählt: sudo iptables-save liest den geschützten Regelsatz des Kernels, während das nicht privilegierte tee in Ihr Projektverzeichnis schreibt. Die abschließende Umleitung sendet die doppelte Bildschirmausgabe von tee an /dev/null; sie leert die Datei nicht. Die erstellte Sicherung enthält alle von diesem Host gemeldeten serialisierten IPv4-Tabellen und -Ketten, nicht nur die eine Regel, die Sie später hinzufügen.
Sehen Sie sich den Anfang der gespeicherten Datei an.
head -n 12 baseline.v4
Die genauen Zählerwerte können variieren. Die Datei verwendet jedoch das von iptables-restore erwartete Format, das in Tabellenabschnitte gegliedert ist. Ein minimaler Filterabschnitt sieht beispielsweise so aus:
*filter
:INPUT ACCEPT ...
...
COMMIT
Jeder Abschnitt beginnt mit einem Tabellennamen wie *filter, deklariert seine Ketten und Richtlinien, listet die Regeln auf und endet mit COMMIT. iptables-restore wendet einen Tabellenabschnitt erst an, wenn es diese Markierung erreicht. Behandeln Sie die Datei daher nicht als beliebige Liste eigenständiger Shell-Befehle.
Stellen Sie sicher, dass die Datei eine Markierung für die Filtertabelle und eine Commit-Markierung enthält.
grep -E '^\*filter$|^COMMIT$' baseline.v4
Serviceregel hinzufügen und speichern
In diesem Schritt fügen Sie der aktiven Firewall eine explizite Zulassungsregel hinzu und speichern den daraus resultierenden Regelsatz im üblichen Pfad für IPv4-Persistenzdateien.
Fügen Sie am Anfang der Kette INPUT eine Regel ein, die TCP-Datenverkehr über die Loopback-Schnittstelle für den Port 18087 akzeptiert. Die Einschränkung auf Schnittstelle und Port hält die Regel für diese Übung präzise.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18087 -j ACCEPT
INPUT umfasst Datenverkehr, der an den Host selbst gerichtet ist. -I INPUT 1 platziert die Regel an erster Stelle, -i lo beschränkt sie auf die Loopback-Schnittstelle, -p tcp --dport 18087 wählt den Testdienst aus, und -j ACCEPT erlaubt eine passende Verbindung. Eine explizite, eng gefasste Regel lässt sich leichter prüfen und entfernen als eine weitreichende Regel, die zahlreiche Dienste akzeptiert.
Prüfen Sie die aktive Regel. Ein Rückgabestatus von null bedeutet, dass die exakte Übereinstimmung und das Ziel vorhanden sind. Die auf nftables basierende Implementierung auf diesem Host gibt außerdem eine normalisierte Form der passenden Regel aus.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Speichern Sie den vollständigen aktiven IPv4-Regelsatz. sudo tee ist erforderlich, da /etc/iptables administrative Schreibrechte voraussetzt.
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null
Dieser Befehl erstellt nach dem Hinzufügen der Regel eine neue Momentaufnahme. sudo wird auf beiden Seiten der Pipe aus unterschiedlichen Gründen benötigt: Die linke Seite liest den Firewall-Zustand, während die rechte Seite eine Datei öffnet, deren Zielverzeichnis dem Benutzer root gehört. Das bloße Erstellen von rules.v4 aktiviert oder plant noch nichts; die Datei kann anschließend von einem Wiederherstellungsbefehl oder einem Dienst für den Systemstart verwendet werden.
Suchen Sie in der gespeicherten Datei nach dem Dienstport. Das -- nach grep beendet die Optionsauswertung. Das ist hilfreich, wenn ein Suchmuster mit einem Bindestrich beginnen könnte.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Die Ausgabe sollte eine INPUT-Regel enthalten, die mit -j ACCEPT endet. Zu diesem Zeitpunkt enthalten sowohl der aktive Regelsatz als auch die gespeicherte Datei die gewünschte Regel.
Vergleichen Sie die neue Datei nicht byteweise mit der Baseline. Paket-Zähler und von anderer Software verwaltete Regeln können sich legitimerweise ändern. Für diese Übung ist entscheidend, dass die gewünschte Regel sowohl im aktiven Zustand als auch im gespeicherten Artefakt vorhanden ist.
Gespeicherten Regelsatz prüfen und wiederherstellen
In diesem Schritt entfernen Sie die aktive Regel, prüfen die gespeicherte Datei, ohne sie anzuwenden, und laden sie anschließend erneut. Damit simulieren Sie den wichtigen Teil einer Wiederherstellung beim Systemstart, bleiben aber innerhalb einer einzigen Lab-Sitzung.
Löschen Sie die Regel aus der aktiven Kette INPUT.
sudo iptables -D INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Diese Löschung verändert ausschließlich den aktuellen Regelsatz des Kernels. /etc/iptables/rules.v4 wird dadurch nicht bearbeitet. Deshalb kann die gespeicherte Regel mit einem späteren Befehl wiederhergestellt werden. Diese bewusst herbeigeführte Abweichung verdeutlicht den Unterschied zwischen aktivem und gespeichertem Zustand.
Stellen Sie sicher, dass die Regel nicht vorhanden ist. Die Prüfung soll fehlschlagen; daher gibt || eine Meldung aus und lässt den Ablauf fortsetzen.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Live rule is absent"
Verwenden Sie vor dem Anwenden einer gespeicherten Firewall iptables-restore --test. Dadurch wird die vollständige Datei analysiert und bei ungültiger Syntax ein Fehler gemeldet, ohne den aktiven Regelsatz zu ersetzen.
sudo iptables-restore --test < /etc/iptables/rules.v4
Der Operator < übergibt die Datei über die Standardeingabe an iptables-restore. Eine stille Ausgabe bedeutet, dass die Syntax akzeptiert wurde; die Datei wurde dadurch noch nicht angewendet. Diese Prüfung ist eine wichtige Sicherheitsmaßnahme, da ein fehlerhafter oder unvollständiger Regelsatz beim Wiederherstellen die Netzwerkverbindung unterbrechen kann.
Eine erfolgreiche Prüfung wird ohne Ausgabe abgeschlossen. Stellen Sie nun die gespeicherten Regeln in der aktiven Firewall wieder her.
sudo iptables-restore < /etc/iptables/rules.v4
Im Gegensatz zum Hinzufügen einer einzelnen Regel mit iptables verarbeitet iptables-restore alle in der Datei enthaltenen Tabellenabschnitte. Behandeln Sie den Befehl als weitreichenden administrativen Vorgang: Prüfen Sie zuerst, bewahren Sie eine Rücksetzdatei auf und überprüfen Sie anschließend unverzüglich den kritischen Zugriff. In diesem kontrollierten Lab wurde die gespeicherte Datei erst wenige Augenblicke zuvor auf demselben Host erstellt.
Prüfen Sie, ob die Serviceregel wieder vorhanden ist.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Stellen Sie sicher, dass die Anwendung nach der Wiederherstellung weiterhin erreichbar ist.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Zur ursprünglichen Baseline zurückkehren
In diesem Schritt verwenden Sie die Sicherung aus Schritt 1, um die Änderung des Labs aus der aktiven Firewall zu entfernen. Gleichzeitig bleibt der gespeicherte Zielregelsatz zur Prüfung erhalten.
Prüfen Sie die Baseline, bevor Sie sie anwenden.
sudo iptables-restore --test < baseline.v4
baseline.v4 und /etc/iptables/rules.v4 haben hier absichtlich unterschiedliche Aufgaben. Die Baseline stellt den ursprünglichen aktiven Zustand dar, während rules.v4 den Zielzustand mit der Serviceregel enthält. Das Wiederherstellen einer Datei verändert die jeweils andere nicht.
Stellen Sie den ursprünglichen aktiven Regelsatz wieder her.
sudo iptables-restore < baseline.v4
Bestätigen Sie, dass die Regel des Labs nicht mehr aktiv ist.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Original firewall baseline restored"
Die gespeicherte Zieldatei ist ein separates Artefakt und enthält weiterhin die Regel, deren Wiederherstellung Sie geübt haben.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Diese Prüfung belegt die Trennung der Zustände am deutlichsten: Die aktive Firewall wurde zurückgesetzt, während das Persistenzartefakt die Zielregel weiterhin dokumentiert. Ein Administrator könnte die Regel später erneut wiederherstellen oder einen Persistenzdienst so einrichten, dass er sie beim Systemstart lädt.
Prüfen Sie abschließend, dass der lokale Dienst auch nach der Rückkehr zur ursprünglichen, freizügigen Baseline erreichbar bleibt.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Prüfen Sie in einer Produktionsumgebung, welcher Dienst die Persistenzdatei der Distribution beim Systemstart lädt. Auf Debian-basierten Systemen werden beispielsweise häufig ein Paket wie iptables-persistent und der Dienst netfilter-persistent verwendet. Verfügbarkeit und Richtlinien unterscheiden sich jedoch je nach Host. Das Speichern einer korrekten rules.v4 bereitet den Regelsatz vor; ob er automatisch wiederhergestellt wird, hängt von einem installierten und aktivierten Loader ab.
Zusammenfassung
Sie haben die aktive IPv4-Firewall gesichert, eine gezielte Serviceregel hinzugefügt und gespeichert, den serialisierten Regelsatz mit iptables-restore --test geprüft, ihn in den Kernel geladen und anschließend die ursprüngliche Baseline wiederhergestellt. Außerdem haben Sie die aktive Firewall von den gespeicherten Persistenz- und Rücksetzdateien unterschieden – eine wesentliche Gewohnheit, bevor Paketfilterregeln geändert oder wiederhergestellt werden.
