Weblog

firewalld nutzen statt abschalten

27.01.2026 · 5 Min. Lesezeit

firewalld nutzen statt abschalten

Firewalld gehört zu den Komponenten unter RHEL‑basierten Systemen, die man gern unterschätzt, bis man sie wirklich braucht. Rocky Linux 9.7 bringt wie alle aktuellen Enterprise‑Distributionen eine moderne, zonenbasierte Firewall mit, die weit mehr kann als simple Paketfilter. Gerade in Umgebungen, in denen ein Server in mehreren VLANs hängt und unterschiedliche Vertrauensstufen bedienen muss, zeigt firewalld seine Stärken.

Das folgende Szenario ist keineswegs fiktiv sondern regelmäßig für Jumpserver genutzt: Ein Server dient als Remote‑Workstation, steht aber gleichzeitig in zwei logisch getrennten Netzen. Das eine VLAN ist das Default‑Gateway‑Netz, aber nur bedingt vertrauenswürdig. Das andere VLAN ist das interne, vertrauenswürdige Netz, über das RFC1918‑Routen erreichbar sind. Die Firewall muss also differenziert arbeiten: SSH und Cockpit sollen aus beiden Netzen erreichbar sein, HTTP und HTTPS jedoch ausschließlich aus dem vertrauenswürdigen VLAN.

Dieser Artikel beleuchtet die Architektur von firewalld, erklärt die relevanten Konzepte und führt anschließend durch die konkrete Konfiguration für Rocky Linux 9.7 - inklusive eines Bonus‑Abschnitts, in dem die DHCP‑Konfiguration des „suspicious VLAN“ so angepasst wird, dass zwar die IP per DHCP kommt, aber die DNS‑Server überschrieben werden.

firewalld

Firewalld ist kein klassisches Regelwerk wie iptables oder nftables, sondern eine Abstraktionsschicht darüber. Die zentrale Idee besteht darin, Netzwerkinterfaces oder Quellen (source addresses) in Zonen einzuteilen, die jeweils eigene Regeln und Services definieren.

Eine Zone beschreibt also eine Sicherheitsstufe. Typische Beispiele sind „public“, „internal“, „trusted“ oder „drop“. Jede Zone kann eigene Regeln, Ports, Services und Forwarding‑Regeln enthalten. Firewalld übersetzt diese Definitionen dann in nftables‑Regeln.

Für unser Szenario ist diese Zonierung ideal. Wir haben zwei VLAN‑Interfaces, die klar unterschiedlichen Vertrauensstufen entsprechen:

• VLAN 1000: „suspicious VLAN“, 192.168.10.0/24
• VLAN 2000: „trusted VLAN“, 10.20.20.0/24

Die Firewall soll abhängig vom Interface entscheiden, welche Dienste erreichbar sind. Genau dafür sind Zonen gedacht.

Netzwerktopologie und Routing

Der Server besitzt zwei Interfaces, jeweils mit VLAN‑Tagging:

• eth0.1000 → 192.168.10.100/24, Default‑Gateway 192.168.10.254
• eth0.2000 → 10.20.20.100/24, Gateway 10.20.20.254 für RFC1918‑Netze

Das Default‑Gateway liegt im „suspicious VLAN“. Das ist nicht ungewöhnlich, aber sicherheitstechnisch relevant. Der Server soll zwar über dieses Netz ins Internet kommen, aber Dienste wie HTTP/HTTPS sollen nicht aus diesem Netz erreichbar sein.

Das „trusted VLAN“ hingegen ist das interne Netz, über das administrative Zugriffe und interne Dienste laufen. Hier sollen HTTP und HTTPS erreichbar sein.

Zuweisung der Interfaces zu Firewalld‑Zonen

Firewalld ordnet Interfaces standardmäßig der Zone „public“ zu. Für unser Setup definieren wir zwei Zonen:

• suspicious für VLAN 1000
• trusted für VLAN 2000

Die Zuordnung erfolgt über:

sudo firewall-cmd --permanent --zone=suspicious --add-interface=eth0.1000

sudo firewall-cmd --permanent --zone=trusted --add-interface=eth0.2000

Damit ist die Grundlage gelegt: Jedes Interface hat seine eigene Sicherheitszone.

Dienste definieren

SSH und Cockpit überall, HTTP/HTTPS nur im trusted VLAN

Firewalld arbeitet mit sogenannten „Services“, die definierte Portsets und Protokolle enthalten. SSH und Cockpit sind bereits als Services vorhanden, ebenso HTTP und HTTPS.

SSH und Cockpit in beiden Zonen erlauben

sudo firewall-cmd --permanent --zone=suspicious --add-service=ssh

sudo firewall-cmd --permanent --zone=suspicious --add-service=cockpit

sudo firewall-cmd --permanent --zone=trusted --add-service=ssh

sudo firewall-cmd --permanent --zone=trusted --add-service=cockpit

HTTP und HTTPS nur im trusted VLAN erlauben

sudo firewall-cmd --permanent --zone=trusted --add-service=http

sudo firewall-cmd --permanent --zone=trusted --add-service=https

Im „suspicious VLAN“ werden diese Services bewusst nicht freigeschaltet.

Firewall neu laden

sudo firewall-cmd --reload

Damit ist die grundlegende Zonenkonfiguration abgeschlossen.

Kontrolle der aktiven Regeln

Ein Blick auf die aktiven Regeln zeigt, ob alles korrekt zugeordnet wurde:

sudo firewall-cmd --get-active-zones

Erwartete Ausgabe:

trusted interfaces: eth0.2000

suspicious interfaces: eth0.1000

Und die Dienste pro Zone:

sudo firewall-cmd --zone=trusted --list-services

sudo firewall-cmd --zone=suspicious --list-services

Damit ist die Firewall‑Konfiguration abgeschlossen und entspricht exakt den Anforderungen.

Statisches Routing

Ein Punkt, der in Multi‑VLAN‑Setups oft übersehen wird, ist die saubere Definition zusätzlicher statischer Routen. In unserem Szenario dient das „trusted VLAN“ nicht nur als Verwaltungsnetz, sondern stellt über das Gateway 10.20.20.254 auch die Erreichbarkeit sämtlicher RFC1918‑Netze bereit. Da das Default‑Gateway jedoch im „suspicious VLAN“ liegt, muss das System explizit angewiesen werden, interne Netze über das Interface eth0.2000 zu routen. Ohne diese Definition würden Anfragen an 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 fälschlicherweise über das untrusted Netz laufen, was sowohl funktional als auch sicherheitstechnisch unerwünscht ist.

Unter Rocky Linux 9.7 erfolgt die Konfiguration über NetworkManager. Für das Interface des trusted VLAN wird eine statische Route definiert, die alle RFC1918‑Netze über das Gateway 10.20.20.254 leitet. Dies geschieht in der entsprechenden .nmconnection‑Datei, typischerweise:

/etc/NetworkManager/system-connections/eth0.2000.nmconnection

Im Abschnitt [ipv4] ergänzt man die Route‑Definition:

[ipv4] method=manual address1=10.20.20.100/24,10.20.20.254 routes=10.0.0.0/8,10.20.20.254; 172.16.0.0/12,10.20.20.254; 192.168.0.0/16,10.20.20.254;

Die Syntax folgt dem Muster Zielnetz,Gateway;. NetworkManager erzeugt daraus persistente Routen, die beim Hochfahren des Interfaces automatisch gesetzt werden. Nach der Änderung wird die Konfiguration neu geladen und das Interface aktiviert:

sudo nmcli connection reload

sudo nmcli connection up eth0.2000

Damit ist sichergestellt, dass sämtlicher Verkehr zu internen Netzen konsequent über das trusted VLAN läuft, während der allgemeine Internetverkehr weiterhin über das Default‑Gateway im suspicious VLAN abgewickelt wird. Dieses Policy‑Routing‑Verhalten ist essenziell, um die Trennung der Vertrauenszonen nicht nur auf Firewall‑Ebene, sondern auch auf Routing‑Ebene sauber durchzusetzen.

Bonus: DHCP im suspicious VLAN, aber DNS überschreiben

Rocky Linux nutzt NetworkManager für die Interface‑Konfiguration. Wenn die IP im VLAN 1000 per DHCP bezogen werden soll, aber die DNS‑Server nicht übernommen werden sollen, muss man die DHCP‑Optionen überschreiben.

Konfiguration für VLAN 1000

Die Datei liegt typischerweise unter:

/etc/NetworkManager/system-connections/eth0.1000.nmconnection

Wichtige Parameter:

[ipv4]<br></br> method=auto <br></br> ignore-auto-dns=true <br></br> dns=9.9.9.9;1.1.1.1;

ignore-auto-dns=true sorgt dafür, dass DHCP zwar IP, Gateway und Routing übernimmt, aber die DNS‑Server ignoriert werden. Stattdessen werden die manuell gesetzten DNS‑Server verwendet.

Nach der Änderung:

sudo nmcli connection reload

sudo nmcli connection up eth0.1000

Damit bezieht das Interface weiterhin seine IP per DHCP, aber die DNS‑Konfiguration bleibt unter Kontrolle.

Fazit: firewalld als präzises Werkzeug für Multi‑VLAN‑Setups

Dieses Szenario zeigt exemplarisch, wie sauber firewalld mit komplexen Netzwerksituationen umgehen kann. Die Zonierung erlaubt eine klare Trennung zwischen vertrauenswürdigen und untrusted Netzen, ohne dass man sich in nftables‑Regeln verlieren muss.

Die Kombination aus:

• VLAN‑basierten Zonen
• differenzierten Service‑Freigaben
• DHCP‑Konfiguration mit DNS‑Override

macht den Server robust, sicher und gleichzeitig flexibel.

Also, in Zukunft schaltest du firewalld nicht einfach nur ab, in Ordnung?