Auf Mastodon ansehen
Ich betreibe selbst einen dedizierten Server, diesen hatte ich bisher immer mit UFW abgesichert, aber das führte zu Problemen mit einigen Docker-Containern. In dieser folgenden Serie später dazu mehr. Nun aber erstmal ein paar Grundlagen zu Iptables-Persistent. Kommende Woche Montag 15 Uhr erscheint dann der nächste Teil.
Die integrierte Firewall iptables ist auf den meisten GNU/Linux-Systemen verfügbar und bietet eine leistungsfähige Möglichkeit, Netzwerkzugriffe zu kontrollieren. Wer jedoch eigene Regeln erstellt, stellt schnell fest: Nach einem Neustart sind alle Änderungen verloren. Genau hier kommt iptables-persistent ins Spiel.
Was ist iptables-persistent?
iptables-persistent ist ein Hilfswerkzeug, das die bestehenden iptables-Regeln dauerhaft speichert und sie beim Systemstart automatisch wieder lädt. Es besteht im Wesentlichen aus zwei Skripten:
-
netfilter-persistent: ein Dienst, der beim Booten Regeln lädt und beim Herunterfahren speichert (falls gewünscht). -
iptables-saveundiptables-restore: Werkzeuge, um den aktuellen Regelzustand zu exportieren und wiederherzustellen.
Nach der Installation von iptables-persistent wird man beim ersten Mal gefragt, ob man die aktuellen Regeln speichern möchte. Diese landen dann in den Dateien:
-
/etc/iptables/rules.v4(für IPv4) -
/etc/iptables/rules.v6(für IPv6)
Änderungen an den Regeln während des Betriebs muss man aktiv mit iptables-save > /etc/iptables/rules.v4 sichern, sonst gehen sie beim nächsten Neustart verloren.
Unterschied zu UFW
UFW steht für „Uncomplicated Firewall“ und ist eine benutzerfreundliche Oberfläche für iptables. Sie richtet sich vor allem an Einsteiger:innen und übernimmt die Verwaltung der iptables-Regeln im Hintergrund. Ein Beispiel:
ufw allow 22/tcpDas erlaubt eingehende SSH-Verbindungen – ohne dass man sich mit der komplexeren Syntax von iptables auseinandersetzen muss. Wer UFW verwendet, braucht in der Regel nicht zusätzlich iptables-persistent, da UFW die Regeln selbst speichert und verwaltet.
Vergleich:
| Funktion | iptables + iptables-persistent | UFW |
|---|---|---|
| Zielgruppe | Fortgeschrittene | Einsteiger:innen |
| Bedienung | Manuell, detailliert | Einfach, abstrahiert |
| Regeln speichern | Manuell über iptables-save | Automatisch |
| Flexibilität | Hoch | Eingeschränkt |
Fazit
iptables-persistent ist ideal für alle, die iptables direkt nutzen möchten und dafür sorgen wollen, dass ihre Regeln nach einem Neustart erhalten bleiben. UFW ist dagegen einfacher, aber weniger flexibel. Wer volle Kontrolle braucht, greift zur Kombination iptables und iptables-persistent.
Im einem kommenden Artikel nächste Woche geht es darum wie man Iptables Regeln erstellt und diese auch bei einem Reboot dauerhaft speichert. Freut auch also auf kommende Woche.
https://wiki.ubuntuusers.de/UFW/, https://wiki.ubuntuusers.de/iptables/, www.thomas-krenn.com
Ist iptables nicht obsolete und nicht durch nftables abgelöst worden?
Grüße mszet
Das hab ich mich gestern auch gefragt. Wenn man heutzutage noch iptables nutzen will, dann führt das, zumindest bei Alpine Linux, zu entsprechenden Warnhinweisen.
Das Problem mit nftables: https://superuser.com/questions/1787416/nftables-how-to-stop-further-chain-traversal-after-accept-verdict https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains -> Info bei Base Chain Priority
Hier wird das Problem wirklich gut erklärt: https://www.danisch.de/blog/2024/07/07/linux-paketfilter-nftables-broken-by-design/
Eine Woche später gab es noch ein Update: https://www.danisch.de/blog/2024/07/16/design-by-ignorance/
Danish mokiert sich mal wieder wegen seinem eingeschränkten Weltbild!
Bei unix ist es so, dass ohne Firewall, ohne Regeln eben alle Pakete erlaubt sind, was der unsicherste Zustand ist. Die Firewall hat nun die Aufgabe Pakete auszufiltern, womit die Sicherheit steigt. Der sicherste Zustand (ohne Funktionalität) ist erreicht, wenn alle Pakete ausgefiltert werden. Man kann auf zwei Arten Pakete filtern: Positiv per Whitelist (allow, bei standard drop) oder Negativ per Blacklist (drop, bei standard allow). Das hat aber nichts damit zu tun, dass es am Ende darum geht Pakete zu auszufiltern. Vorstellen kann man sich das, wie wenn man ein weisses Blatt Papier mit einen schwarzen Stift bemalt. Jede zugefügte Regel, jede zugefügte Tabelle filtert Pakete und macht das Papier schwarzer, ohne das bisherige Bild zu zerstören bzw. zu korrigieren. Das ist eine Design-Entscheidung. Letztendlich erschwert es den Distributionsdefault sicherheitstechnisch durch einfaches Zufügen von Tabellen aufzuweichen. Dies gibt mir zumindest etwas Sicherheit nichts kaputt zu machen.
Letztendlich muss halt Herr Danish, wie alle anderen früheren iptables-Benutzer sich ein anders Denkmodell zulegen.
Grüße mszet
Vielleicht hast du das Problem nur noch nicht voll erfasst? Beim jetzigen Stand ist man gezwungen, in seinen Firewall-Regeln die LXD-Regeln in den Firewall-Regeln immer erneut zu wiederholen, damit sie wirken können. Das entspricht keiner natürlichen Logik und es ist vollkommen überflüssig, unnötig oder (wie die Informatiker zu sagen pflegen) es ist einfach redundant(er Unsinn)! Wenn man Regeln doppelt eintragen muss, damit sie wirken, kann etwas nicht stimmen.
Wenn man eine globale Whitelist verwendet (was üblich und sinnvoll ist), dann muss die vollständig sein. (Was auch das Wesen von Whitelistes ist) Dazu muss man den Wirkungsbereich der spezialisierten Listen in diese Liste eintragen, sonst ist eben da alles geblockt. Dazu genügt meist eine Regel. Ich halte das für sinnvolle Redundanz, wie das Zwei-Augen-Prinzip. Weil ich nicht möchte, dass meine Regeln durch irgendwelche anderen, automatisch erstellten ungültig werden.
Also zum Beispiel, wenn man Docker verwendet, muss man die Dockerbridge freischalten. Dann kann Docker mit seiner spezialisierten Liste dort arbeiten. Wenn man das in Zukunft nicht wieder tun will, wenn man weitere Docker Bridges erstellt, schaltet man halt mit ifname und Wildcard auf das Namensschema von Dockerbridges frei. Man muss sich dann nur daran halten.
Grüße mszet