Von iptables zu firewalld (mit Ansible)

[LowPowerMan]

Schönen Tag

Da ja leider iptables immer öfter als deprecated gekennzeichnet wird und man stattdessen firewalld nutzen soll, muß ich mich wohl mal einarbeiten.

Dabei tauchten ein paar Fragen auf bei denen ich nicht weiterkomme.

Gibt es tatsächlich bei firewalld keine Möglichkeit, um die aktuelle Konfiguration zu ex- und importieren? Also sowas wie iptables-save?
Bisher habe ich in Ansible ein jinja2 Template, was anhand von Variablen die Konfiguration erstellt. Läuft auf meinen bisherigen Servern so problemlos. Jedwede manuelle Änderung an der Firewall wird durch Ansible korrigiert.

Für Ansible gibt es wohl ein firewalld Modul, aber soweit ich das bisher gelesen habe, erstellt man hier einzelne Regeln pro Task, bzw via with_items in der Schleife. Es scheint aber nicht so zu sein, daß vorhandene Regeln entfernt werden, dh wenn jemand am Server manuell eine Regel hinzufügt, dann bleibt die bestehen. Wie soll man da einen verlässlich reproduzierbaren Stand hinbekommen?

Den ganzen Müll mit x-Zonen und Services will ich nicht haben. Einfach nur einen simpler Filter für Ports und Proto mit Default-Drop für In-/Output. Firewalld scheint mir hier viel zu aufgeblasen und umständlich.

 

[Pummeluff]

IPTables ist seit Jahren deprecated und wird im Kernel nach NFTables übersetzt. Darin solltest du Dich einarbeiten.

Firewalld ist hübsch bei einzelnen Desktopsystemen. Bei Verwendung von Ansible & Co. halte ich es für ungeeignet.

 

[konkretor]

firewalld würde ich im Server Bereich nicht nutzen.

Hier mal nen Beispiel wie du das machen könntest

https://www.kuketz-blog.de/howto-wechsel-von-iptables-zu-nftables/

 

[Pummeluff]

firewalld würde ich im Server Bereich nicht nutzen

Blöderweise ist das die Vorgabe bei RHEL (seit 7) genauso wie der Network Manager und wurde auch im RHCE 7 bis zum Erbrechen forciert.

 

[snaxilian]

RHEL 9: https://access.redhat.com/documenta...es-or-iptables_getting-started-with-firewalld

RHEL 8: https://access.redhat.com/documenta...es-or-iptables_getting-started-with-firewalld

Beide schreiben: Es kommt drauf an. Wirf halt firewalld runter und nimm nftables.

 

[lokked]

Du hast überhaupt kein Problem, wenn du nicht gezwungen bist firewalld aus irgendeinem Grund einzusetzen.
Die Syntax von iptables wird niemals nicht mehr unterstützt werden; dafür gibts keinen trifitigen Grund. Was evtl. mal passieren kann ist das der Übersetzungslayer per default entfernt wird, aber dafür gibts ja den iptables-legacy befehl. Was wir gemacht haben, um unsere Ruhe zu haben, ist alle iptables-Befehle per Suchen & Ersetzen mit

iptables-legacy

zu ersetzen, dann ist Ruhe im Karton.

P.S.: Schliesse mich den anderen an, für neuere Sachen einfach mal nftables lernen, das ist eine flache Lernkurve.

 

[LowPowerMan]

IPTables ist seit Jahren deprecated und wird im Kernel nach NFTables übersetzt. Darin solltest du Dich einarbeiten.

Ich werde mir das mal genauer ansehen, danke.

firewalld würde ich im Server Bereich nicht nutzen.

Will ich auch nicht, aber Rocky zB empfehlen den Wechsel zu firewalld:
https://docs.rockylinux.org/guides/security/enabling_iptables_firewall/

Die Syntax von iptables wird niemals nicht mehr unterstützt werden; dafür gibts keinen trifitigen Grund.

Wenn ich in all meinen Jahren was gelernt habe, dann daß man keine triftigen Gründe für Knieschüsse braucht. Siehe die Entstehungsgeschichte von Rocky.

Aber wenn nftables noch viele Jahre erhalten bleibt, dann steht firewalld weiterhin auf der uninstall Liste.

 

[Pummeluff]

Will ich auch nicht, aber Rocky zB empfehlen den Wechsel zu firewalld:

S. o. Redhat forciert Firewalld. Rocky ist ein RHEL-Klon. Entsprechend empfehlen die auch Firewalld.

Wir haben im Unternehmen SLES und RHEL im Einsatz. Um die Firewall per Ansible und Puppet einheitlich konfigurieren zu können, wurden Firewalld und die Suse-Firewall deinstalliert und durch IPTables ersetzt.

Auch wenn ich NFTables empfohlen hab, wird IPTables im Enterprise-Umfeld in den nächsten Jahren nicht verschwinden.

Ergänzung (24. August 2023)

Aber wenn nftables noch viele Jahre erhalten bleibt, dann steht firewalld weiterhin auf der uninstall Liste.

https://firewalld.org/documentation/architecture.html

Ohne iptables/nftables kein Firewalld.

Der Linux-Kernel arbeitet intern mit NFTables. IPTables werden im Kernel zu NFTables übersetzt. Alles andere (Firewalld, Apparamor UFW) setzt darauf auf.

 

[Uridium]

Was wir gemacht haben, um unsere Ruhe zu haben, ist alle iptables-Befehle per Suchen & Ersetzen mit

iptables-legacy

zu ersetzen

Warum nicht gleich 'iptables' direkt darauf verlinken (iptables -> xtables-legacy-multi)? Wenn irgend ein Knaller aus Versehen 'iptables' benutzt, dann habt ihr den Salat. Beide APIs (gleichzeitig) benutzen soll man ja tunlichst vermeiden.
Ich bin noch keinem (legacy) Script begegnet, das nicht mit dem neuen binary läuft (iptables -> xtables-nft-multi). Wenn es einmal übersetzt wurde, kann man es ja sofort exportieren.

 

[lokked]

Aus Gründen der Selbst-Dokumentation, damit niemand dran rumfummelt. Legacy-Systeme sind als solche vermerkt und Änderungen daran müssen immer separat genehmigt oder begründet werden.
Quasi als Wink mit dem Zaunpfahl. Teamspezifische oder "verdeckte" Lösungen sind immer etwas prekär, da man am Ende nie ausschliessen kann, das jemand nicht im Bilde ist, da sowieso niemand Dokumentation liest

 

[snaxilian]

S. o. Redhat forciert Firewalld

Naja das ist ja auch nur die halbe Wahrheit, siehe meine zwei Links zur RHEL Doku, da steht klar, dass firewalld eine Option ist, man aber auch direkt nftables verwenden kann bei komplexeren Anforderungen.

im Unternehmen SLES und RHEL im Einsatz. Um die Firewall per Ansible und Puppet einheitlich konfigurieren zu können, wurden Firewalld und die Suse-Firewall deinstalliert und durch IPTables ersetzt.

Mit SLES 15 ist die yast-firewall sowieso deprecated und firewalld auch unter SLES standardmäßig gesetzt wobei als Backend weiterhin iptables verwendet wird. Na vielleicht migrieren sie mit SLES 16 ja zu nftables.

 

[DEADBEEF]

Darf ich fragen warum ihr überhaupt lokal auf den Servern die Firewall einsetzt?

 

[snaxilian]

• Keine Segmentierung der Server per VLANs oder zu groß gewählte VLANs (diverse Services oder n-facher gleicher Service für unterschiedliche Anforderungen im gleichen Segment)
• regulatorische Vorgaben (KRITIS, VAIT, DORA, etc., such dir was aus^^)
• Compliance-Vorgaben weil man z.B. ne "Cyber-Versicherung" hat oder haben will und diese entsprechende Regelungen fordern weil sonst die Prämie in exorbitante Höhen steigen würde

 

[DEADBEEF]

Ich arbeite auch in einem Kritis Unternehmen aber diese Vorgabe kenn ich nicht. Ich war aber in der Vergangenheit bei einigen PoC für Netzsegmentierung wie z.B. illumio dabei. Dann wird das wohl diesen Hintergrund haben

 

[snaxilian]

Es gibt auch nicht die eine konkrete Anforderung "du musst lokale Firewalls nutzen" aber das kann sich halt ergeben aus den BSI Anforderungen und der Realität. Wenn man, warum auch immer, gewisse Forderungen/Maßnahmen aus BSI NET 1.1 nicht umsetzen kann (oder dies erst in der Zukunft geplant ist), dann könnten lokal konfigurierte Firewalls eine Maßnahme sein um das gewünschte Ziel zu erreichen.

Auch kann man so z.B. lateral movement verhindern. Natürlich kannst du administrative Zugriffe an der (Netz-)Firewall reglementieren aber wenn jemand durch eine Sicherheitslücke einen Server in dem Netz übernommen hat und sich ausbreiten will, kannst du das so unterbinden indem du Zugriffe auf den Servern aus dem gleichen Subnetz verhinderst. Das kann man mit Tools wie illumio umsetzen oder wenn man ein zentrales config management tool wie ansible oder puppet bereits hat, auch damit.

 

[LowPowerMan]

Darf ich fragen warum ihr überhaupt lokal auf den Servern die Firewall einsetzt?

Darf ich fragen, warum Du das nicht machst?

Am äußersten Perimeter ist eine Firewall um schon mal das Grobe draußen zu halten.
Dann hat jeder Server seine eigene Firewall, die nur das freigibt, was auch explizit nötig ist.

Dadurch bin ich gezwungen, auch interne Ports etc in die Doku mit aufzunehmen.
Und durch das Management mit Ansible ist das nicht wirklich viel Aufwand, gibt aber ein besseres Gefühl der Sicherheit.

Aber vielleicht bin ich auch nur zu paranoid

 

[DEADBEEF]

Schadet nicht paranoid zu sein wenn es um Sicherheit geht. Bei uns wird es ja auch in diese Richtung gehen mit welchem Tool auch immer. Die lokale Firewall hab ich allerdings noch nie irgendwo aktiviert gesehen. Macht aber alles Sinn wenn es nicht anders geht und man den Aufwand gering halten kann.

Btw. Es ist sicherlich auch irgendwo abhängig von der Umgebung und Organisation. Wenn ich eine public cloud für jedermann betreibe ist es sicherlich nochmal was anderes als wenn ausschließlich die interne IT auf den Systemen unterwegs ist.

 

[foofoobar]

Ich arbeite auch in einem Kritis Unternehmen aber diese Vorgabe kenn ich nicht. Ich war aber in der Vergangenheit bei einigen PoC für Netzsegmentierung wie z.B. illumio dabei. Dann wird das wohl diesen Hintergrund haben

Nicht jede Butze hat vernünftige Security-Fuzzys die administrative Alpträume vernünftig weg argumentieren können.

Ergänzung (25. August 2023)

Gefühl der Sicherheit.

Na dann.

 

[Drystanz]

Ein bisschen paranoid bin ich auch . Deswegen habe ich noch ein paar nftables-Regeln geladen. Aber im Grunde genommen benötigen nur die Wenigsten auf einem Desktop-Rechner eine IP-Paketfilterung. Welche Dienste laufen denn üblicherweise, und welche offenen Ports werden wirklich benötigt? Dienste wie z.B. cups können entsprechend konfiguriert werden. Ich halte Tools wie Firejail für viel wichtiger. Die DNS würde ich ebenfalls verschlüsseln.

 

[Pummeluff]

Im Heimnetz hab ich keine Firewall aktiviert. Aber mein V-Server ist zugenagelt. Da sind nur die Ports für SSH (geändert auf 222) + Wireguard offen. Zusätzlich läuft da Fail2Ban.