Eine Einführung in Firewalld: Dynamisches Firewall-Management unter Linux

Firewalld ist ein Userspace-Firewall-Management-Daemon für Linux, der eine dynamische, zonenbasierte Schnittstelle über die Kernel-Paketfilter-Backends iptables und nftables bereitstellt. Im Gegensatz zu statischen Firewall-Tools, die einen vollständigen Dienstneustart erfordern, um Regeländerungen anzuwenden, modifiziert Firewalld netfilter-Regeln im laufenden Betrieb — dabei werden aktive TCP-Sitzungen beibehalten und Ausfallzeiten bei Richtlinienaktualisierungen vermieden.

Dieser Leitfaden behandelt jede Betriebsebene von Firewalld: sein Architekturmodell, Zonen- und Dienstabstraktionen, Rich Rules, Runtime- versus permanente Konfiguration sowie die genauen Befehle, die Sie benötigen, um einen Produktionsserver sicher zu verwalten.

Warum Firewalld statische iptables-Workflows ersetzt hat

Traditionelles iptables-Management bedeutet, Regeln in Shell-Skripte oder flache Konfigurationsdateien zu schreiben und dann den gesamten Regelsatz zu leeren und neu zu laden, wenn eine Änderung erforderlich ist. Auf einem stark ausgelasteten Server unterbricht dieser Flush-und-Reload-Zyklus laufende Verbindungen und erzeugt ein kurzes Zeitfenster, in dem keine Filterung aktiv ist.

Firewalld löst dieses Problem durch einen D-Bus-aktivierten Daemon (firewalld), der den autoritativen Regelzustand hält und Änderungen inkrementell an den Kernel übermittelt. Das Ergebnis sind atomare Regelaktualisierungen ohne Verbindungsunterbrechung — entscheidend für jeden Server, der persistente Workloads wie Datenbanken, VPN-Tunnel oder langlebige API-Verbindungen betreibt.

Wenn Sie eine VPS Hosting-Umgebung bereitstellen und diese absichern müssen, ohne neu zu starten oder Dienste zu unterbrechen, ist Firewalld die natürliche Betriebswahl auf RHEL-basierten und vielen Debian-basierten Distributionen.

Kernarchitektur: Wie Firewalld mit dem Kernel interagiert

Das Verständnis des Stacks unter Firewalld verhindert Fehlkonfigurationen und hilft Ihnen, unerwartetes Verhalten zu debuggen.

User Space
┌─────────────────────────────────────────────┐
│ firewall-cmd / firewall-config / D-Bus API  │
└────────────────────┬────────────────────────┘
                     │ D-Bus
┌────────────────────▼────────────────────────┐
│              firewalld daemon               │
│  (zone engine, service definitions, rich    │
│   rule parser, direct rule passthrough)     │
└────────────────────┬────────────────────────┘
                     │ nftables / iptables backend
Kernel Space
┌────────────────────▼────────────────────────┐
│           netfilter (kernel module)         │
└─────────────────────────────────────────────┘

Seit RHEL 8 und Fedora 32 verwendet Firewalld standardmäßig das nftables-Backend. Auf älteren Systemen oder explizit konfigurierten Umgebungen verwendet es das iptables-Backend. Sie können das aktive Backend in /etc/firewalld/firewalld.conf über die FirewallBackend-Direktive einsehen oder überschreiben.

Kritische Falle: Mischen Sie niemals direkte iptables– oder nft-Befehle mit Firewalld auf derselben Schnittstelle. Firewalld besitzt die netfilter-Tabellen, die es erstellt; manuell außerhalb des Daemons eingefügte Regeln werden beim nächsten Reload stillschweigend überschrieben.

Schlüsselkonzepte in Firewalld

Zonen

Eine Zone ist ein benanntes Vertrauensniveau, das auf eine Netzwerkschnittstelle oder einen Quelladressbereich angewendet wird. Jedes in das System eingehende Paket wird mit der Zone abgeglichen, die seiner Eingangsschnittstelle zugewiesen ist, und der Regelsatz der Zone bestimmt, was erlaubt ist.

Firewalld wird mit den folgenden vordefinierten Zonen geliefert, geordnet von der freizügigsten zur restriktivsten:

Architektonische Nuance: Eine Zone kann an eine Netzwerkschnittstelle (z. B. eth0) oder an ein Quell-CIDR (z. B. 192.168.1.0/24) gebunden werden. Quellenbasierte Bindung hat Vorrang vor schnittstellenbasierter Bindung, was es Ihnen ermöglicht, unterschiedliche Richtlinien auf Datenverkehr anzuwenden, der auf derselben physischen Schnittstelle aus verschiedenen Subnetzen eintrifft — ein Muster, das in Multi-Tenant- oder containerisierten Umgebungen üblich ist.

Dienste

Ein Dienst in Firewalld ist eine XML-Definitionsdatei, die unter /usr/lib/firewalld/services/ (Systemstandards) oder /etc/firewalld/services/ (Benutzerüberschreibungen) gespeichert ist. Jede Datei deklariert die Ports, Protokolle und optionalen Hilfsmodule, die für eine benannte Anwendung erforderlich sind.

Zum Beispiel öffnet die https-Dienstdefinition den TCP-Port 443 und lädt keine zusätzlichen Kernel-Helfer. Der ftp-Dienst öffnet TCP-Port 21 und lädt den nf_conntrack_ftp-Helfer, um die dynamische Port-Aushandlung des FTP-Datenkanals zu verwalten.

Die Verwendung von Dienstnamen anstelle von rohen Portnummern macht Ihre Firewall-Richtlinie selbstdokumentierend und reduziert das Risiko von Tippfehlern, die einen Port unbeabsichtigt offen oder geschlossen lassen.

Um alle verfügbaren Dienstdefinitionen auf Ihrem System aufzulisten:

firewall-cmd --get-services

Um die XML-Definition eines bestimmten Dienstes zu inspizieren:

cat /usr/lib/firewalld/services/https.xml

Rich Rules

Rich Rules erweitern das Zonenmodell mit bedingter Logik, die die einfache Dienst-/Port-Abstraktion nicht ausdrücken kann. Sie unterstützen den Abgleich von Quell- und Zieladressen, Portbereichen, Protokollen, Zeitfenstern und Verbindungszustand und können Aktionen auslösen, darunter accept, drop, reject, log und audit.

Die Rich-Rule-Syntax folgt einer strukturierten Grammatik:

rule [family="ipv4|ipv6"]
  [source address="addr[/mask]" [invert="true"]]
  [destination address="addr[/mask]" [invert="true"]]
  [service name="service-name"] | [port port="port" protocol="tcp|udp"]
  [log [prefix="prefix"] [level="level"] [limit value="rate/duration"]]
  [audit]
  [accept|drop|reject [type="reject-type"]]

Ein praktisches Beispiel — SSH-Anmeldeversuche auf 3 pro Minute von einer einzelnen IPv4-Quelle begrenzen, dann den Überschuss protokollieren und verwerfen:

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  log prefix="SSH_RATELIMIT " level="warning" limit value="3/m"
  accept' --permanent

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  drop' --permanent

Sonderfall: Die Reihenfolge der Rich Rules ist wichtig. Firewalld wertet Rich Rules in der Reihenfolge aus, in der sie innerhalb einer Zone hinzugefügt wurden. Wenn Sie eine breite drop-Regel vor einer spezifischen accept-Regel hinzufügen, wird die accept niemals erreicht. Fügen Sie immer zuerst spezifischere Regeln hinzu.

Runtime- vs. permanente Konfiguration

Dies ist die betrieblich wichtigste Unterscheidung in Firewalld und die Quelle der häufigsten Produktionsfehler.

Best-Practice-Workflow für Produktionsänderungen:

1. Wenden Sie die Regel nur zur Runtime an (kein --permanent-Flag) und überprüfen Sie, ob sie sich wie erwartet verhält.
2. Wenn korrekt, wenden Sie dieselbe Regel mit --permanent an, um sie auf die Festplatte zu schreiben.
3. Führen Sie firewall-cmd --reload aus, um die permanente Konfiguration in den Runtime-Zustand zu synchronisieren und die Parität zu bestätigen.

Dieser Workflow verhindert das klassische Szenario, in dem ein Administrator eine --permanent-Regel hinzufügt, neu lädt und feststellt, dass er sich selbst aus SSH ausgesperrt hat — denn der Runtime-Test hätte das Problem aufgedeckt, bevor es permanent wurde.

Firewalld installieren und aktivieren

Firewalld ist standardmäßig auf RHEL, CentOS Stream, Fedora, AlmaLinux und Rocky Linux installiert. Auf Debian und Ubuntu muss es explizit installiert werden.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux:

sudo dnf install firewalld

Debian / Ubuntu:

sudo apt-get update && sudo apt-get install firewalld

Hinweis für Ubuntu-Benutzer: Wenn ufw aktiv ist, deaktivieren Sie es vor der Aktivierung von Firewalld, um widersprüchliche netfilter-Regeln zu vermeiden:

sudo ufw disable
sudo systemctl disable ufw

Daemon starten und aktivieren:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Überprüfen Sie, ob der Daemon läuft und das Kernel-Backend aktiv ist:

sudo firewall-cmd --state
sudo firewall-cmd --info-zone=public

Wesentliche Firewalld-Befehle

Aktuellen Zustand inspizieren

Daemon-Status prüfen:

sudo firewall-cmd --state

Alle aktiven Zonen mit ihren zugewiesenen Schnittstellen und Quellen auflisten:

sudo firewall-cmd --get-active-zones

Den vollständigen Regelsatz für eine bestimmte Zone anzeigen:

sudo firewall-cmd --zone=public --list-all

Den vollständigen Regelsatz für alle Zonen gleichzeitig anzeigen:

sudo firewall-cmd --list-all-zones

Standardzone verwalten

Die Standardzone wird auf jede Schnittstelle angewendet, die nicht explizit einer anderen Zone zugewiesen ist:

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --set-default-zone=public

Eine Schnittstelle einer Zone zuweisen

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Falle: Auf Systemen, die NetworkManager verwenden, können über firewall-cmd vorgenommene Schnittstellen-zu-Zonen-Zuweisungen beim Wiederverbinden durch das NetworkManager-Verbindungsprofil überschrieben werden. Setzen Sie die Zone dauerhaft im NetworkManager-Verbindungsprofil:

nmcli connection modify "Wired connection 1" connection.zone internal

Dienste hinzufügen und entfernen

HTTP in der öffentlichen Zone zur Runtime erlauben:

sudo firewall-cmd --zone=public --add-service=http

Dauerhaft machen:

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

Einen Dienst entfernen:

sudo firewall-cmd --zone=public --remove-service=http --permanent

Bestimmte Ports öffnen und schließen

TCP-Port 8080 zur Runtime öffnen:

sudo firewall-cmd --zone=public --add-port=8080/tcp

Einen UDP-Portbereich dauerhaft öffnen:

sudo firewall-cmd --zone=public --add-port=60000-61000/udp --permanent

Einen Port entfernen:

sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent

IP-Adressen auf Allowlist und Blocklist setzen

Den gesamten Datenverkehr von einem vertrauenswürdigen Verwaltungssubnetz erlauben:

sudo firewall-cmd --zone=trusted --add-source=10.0.0.0/24 --permanent

Den gesamten Datenverkehr von einer bestimmten IP blockieren (quellenbasiertes Verwerfen):

sudo firewall-cmd --zone=drop --add-source=203.0.113.45/32 --permanent

Port-Weiterleitung

Externen TCP-Port 2222 an den internen SSH-Port 22 weiterleiten (nützlich, um den Standard-SSH-Port zu verschleiern, ohne sshd_config zu ändern):

sudo firewall-cmd --zone=public --add-forward-port=port=2222:proto=tcp:toport=22 --permanent
sudo firewall-cmd --reload

IP-Masquerading (NAT)

Masquerade in der externen Zone aktivieren, damit ein VPS, der als Gateway fungiert, Datenverkehr aus einem privaten Subnetz per NAT weiterleiten kann:

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Konfiguration neu laden und synchronisieren

Alle permanenten Änderungen auf den laufenden Zustand anwenden, ohne Verbindungen zu unterbrechen:

sudo firewall-cmd --reload

Einen vollständigen Neustart durchführen (unterbricht alle Verbindungen — nur in Notfällen verwenden):

sudo systemctl restart firewalld

Benutzerdefinierte Zonen und Dienstdefinitionen erstellen

Benutzerdefinierte Zone

sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --zone=management --add-source=10.10.0.0/16 --permanent
sudo firewall-cmd --zone=management --add-service=ssh --permanent
sudo firewall-cmd --zone=management --add-service=cockpit --permanent
sudo firewall-cmd --reload

Benutzerdefinierte Dienstdefinition

Eine Dienstdatei für eine benutzerdefinierte Anwendung erstellen, die auf TCP 9200 lauscht (z. B. Elasticsearch):

sudo nano /etc/firewalld/services/elasticsearch.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Elasticsearch</short>
  <description>Elasticsearch HTTP API and transport port</description>
  <port protocol="tcp" port="9200"/>
  <port protocol="tcp" port="9300"/>
</service>

sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --add-service=elasticsearch --permanent
sudo firewall-cmd --reload

Firewalld vs. Alternativen: Das richtige Tool wählen

Für Teams, die Dedicated Servers in großem Maßstab verwalten, ermöglicht Firewallds D-Bus-API die programmatische Regelverwaltung über Konfigurationsverwaltungstools wie Ansible (ansible.posix.firewalld-Modul) oder Puppet, was ein erheblicher betrieblicher Vorteil gegenüber der Pflege von rohen iptables-Skripten ist.

Praktische Sicherheitshärtungsmuster

Einen Webserver absichern

Eine typische Konfiguration für einen Server, der HTTPS mit SSH betreibt, das auf eine Verwaltungs-IP beschränkt ist:

# Set the default zone
sudo firewall-cmd --set-default-zone=public --permanent

# Allow HTTPS globally
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow HTTP only to redirect to HTTPS (optional)
sudo firewall-cmd --zone=public --add-service=http --permanent

# Restrict SSH to a specific management IP only
sudo firewall-cmd --zone=public --remove-service=ssh --permanent
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  source address="198.51.100.10/32"
  accept' --permanent

sudo firewall-cmd --reload

Wenn Sie einen Webserver zusammen mit einer SSL Certificates-Bereitstellung betreiben, ist die Sicherstellung, dass Port 443 in der richtigen Zone geöffnet ist, bevor das Zertifikat ausgestellt wird (insbesondere für ACME HTTP-01- oder TLS-ALPN-01-Challenges), ein vorausgesetzter Schritt, der häufig übersehen wird.

Einen Mail-Server schützen

Für Server, die Email Hosting-Stacks (Postfix, Dovecot) betreiben, ist der erforderliche Dienstsatz:

sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --zone=public --add-service=smtps --permanent
sudo firewall-cmd --zone=public --add-service=imap --permanent
sudo firewall-cmd --zone=public --add-service=imaps --permanent
sudo firewall-cmd --zone=public --add-service=pop3s --permanent
sudo firewall-cmd --reload

Verworfene Pakete für die Forensik protokollieren

sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  log prefix="DROPPED_PUBLIC " level="warning" limit value="10/m"
  drop' --permanent
sudo firewall-cmd --reload

Protokolle erscheinen in /var/log/messages oder im systemd-Journal (journalctl -k -g DROPPED_PUBLIC). Begrenzen Sie die Protokollrate (wie oben gezeigt), um eine Protokollüberschwemmung in einem DDoS-Szenario zu verhindern.

Firewalld auf einem cPanel-verwalteten VPS

Wenn Sie einen VPS mit cPanel verwenden, beachten Sie, dass cPanel seine eigene Firewall-Schicht installiert und verwaltet (standardmäßig CSF/LFD). Das gleichzeitige Ausführen von Firewalld neben CSF ohne explizite Koordination erzeugt widersprüchliche netfilter-Regeln. Der empfohlene Ansatz ist, eine Firewall-Verwaltungsschicht pro Server zu wählen und die andere zu deaktivieren, oder Firewallds direkte Regel-Passthrough-Schnittstelle zu verwenden, um die Anforderungen von cPanel zu integrieren.

Häufige Firewalld-Probleme beheben

Problem: Mit --permanent hinzugefügte Regel ist nicht wirksam.

Ursache: Permanente Regeln erfordern einen Reload, um in den Runtime-Zustand zu gelangen.

Lösung:

sudo firewall-cmd --reload

Problem: SSH-Verbindung nach Firewall-Änderung unterbrochen.

Ursache: Der SSH-Dienst wurde aus der aktiven Zone entfernt, oder eine drop-Rich-Rule wurde vor der accept-Regel hinzugefügt.

Lösung: Greifen Sie über die Out-of-Band-Konsole Ihres Hosting-Anbieters (VNC/KVM-Konsole) auf den Server zu und stellen Sie dann den SSH-Dienst wieder her:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

Problem: firewall-cmd gibt FirewallD is not running zurück.

Ursache: Der Daemon ist abgestürzt oder wurde nie gestartet.

Lösung:

sudo systemctl start firewalld
sudo journalctl -u firewalld -n 50

Problem: Regeln erscheinen korrekt, aber Datenverkehr wird weiterhin blockiert.

Ursache: Eine widersprüchliche iptables– oder nft-Regel existiert außerhalb der von Firewalld verwalteten Tabellen, oder SELinux/AppArmor blockiert die Verbindung auf der Anwendungsschicht.

Lösung: Prüfen Sie auf manuelle Regeln und SELinux-Verweigerungen:

sudo iptables -L -n -v
sudo ausearch -m avc -ts recent

Problem: Schnittstelle nach dem Neustart nicht der erwarteten Zone zugewiesen.

Ursache: Das NetworkManager-Verbindungsprofil überschreibt die Schnittstellenzuweisung von Firewalld.

Lösung: Setzen Sie die Zone im NetworkManager-Profil wie im Abschnitt zur Schnittstellenzuweisung beschrieben.

Entscheidungsmatrix und technische Checkliste

Verwenden Sie diese Checkliste, bevor Sie Firewalld auf einem Produktionsserver bereitstellen:

• Bestätigen Sie, dass das aktive Firewall-Backend (FirewallBackend in /etc/firewalld/firewalld.conf) der nftables/iptables-Unterstützung Ihres Kernels entspricht.
• Überprüfen Sie, ob keine widersprüchlichen Firewall-Tools (UFW, CSF, direkte iptables-Skripte) auf denselben Schnittstellen aktiv sind.
• Weisen Sie jede Netzwerkschnittstelle explizit einer Zone zu — verlassen Sie sich bei Multi-Homed-Servern niemals ausschließlich auf die Standardzone.
• Wenden Sie alle Änderungen zuerst zur Runtime an, überprüfen Sie die Konnektivität und bestätigen Sie dann mit --permanent und --reload.
• Beschränken Sie den SSH-Zugriff auf bestimmte Quell-IPs über Rich Rules, bevor Sie den SSH-Dienst aus der öffentlichen Zone entfernen.
• Fügen Sie Rate-Limiting-Rich-Rules für alle öffentlich zugänglichen Authentifizierungsdienste hinzu (SSH, SMTP, HTTPS-Login-Endpunkte).
• Aktivieren Sie die Protokollierung für die drop-Zone mit einer Ratenbegrenzung, um Bedrohungsinformationen zu erfassen, ohne den Speicher zu überfluten.
• Bestätigen Sie bei Servern, die über VPS Control Panels verwaltet werden, dass die erforderlichen Ports des Control Panels auf der Whitelist stehen, bevor Sie eine restriktive Standardrichtlinie anwenden.
• Testen Sie die permanente Konfiguration, indem Sie firewall-cmd --reload ausführen und sofort überprüfen, ob alle kritischen Dienste erreichbar bleiben.
• Dokumentieren Sie jede benutzerdefinierte Zone, Rich Rule und Dienstdefinition in der Versionskontrolle zusammen mit Ihrem Infrastructure-as-Code.

FAQ

Was ist der Unterschied zwischen --reload und sudo systemctl restart firewalld?

--reload wendet permanente Konfigurationsänderungen auf den laufenden Daemon an, ohne bestehende Verbindungen zu unterbrechen. systemctl restart startet den Daemon-Prozess vollständig neu, was alle netfilter-Regeln leert und aktive Verbindungen kurzzeitig unterbricht. Bevorzugen Sie auf Produktionssystemen immer --reload.

Können Firewalld und iptables auf demselben Server koexistieren?

Nicht sicher auf derselben Schnittstelle. Firewalld verwaltet seine eigenen netfilter-Chains; direkte iptables-Befehle, die dieselben Chains modifizieren, werden beim nächsten Firewalld-Reload überschrieben. Wenn Sie benutzerdefinierte Regeln einfügen müssen, verwenden Sie stattdessen Firewallds --direct-Schnittstelle oder Rich Rules.

Wie mache ich eine Runtime-Regel dauerhaft, ohne sie erneut einzugeben?

Es gibt keinen eingebauten Befehl, um alle Runtime-Regeln in einem Schritt dauerhaft zu machen. Der korrekte Workflow besteht darin, jede Regel zweimal anzuwenden — einmal ohne --permanent zum Testen, dann mit --permanent für die Persistenz — gefolgt von --reload. Alternativ können Sie firewall-cmd --runtime-to-permanent (verfügbar in Firewalld 0.9+) verwenden, um den aktuellen Runtime-Zustand auf die Festplatte zu speichern.

Warum wird meine Zonenzuweisung nach einem NetworkManager-Reconnect zurückgesetzt?

NetworkManager speichert Zonenzuweisungen in seinen eigenen Verbindungsprofilen. Eine firewall-cmd --change-interface-Zuweisung ist eine Runtime-Überschreibung, die NetworkManager überschreiben kann. Persistieren Sie die Zuweisung mit nmcli connection modify <profile-name> connection.zone <zone>.

Unterstützt Firewalld IPv6?

Ja. Firewalld verwaltet gleichzeitig sowohl IPv4- als auch IPv6-netfilter-Regeln. Rich Rules erfordern das family="ipv6"-Attribut, um IPv6-Datenverkehr gezielt anzusprechen. Zonen- und Dienstregeln gelten standardmäßig für beide Adressfamilien, es sei denn, die Dienstdefinition oder Rich Rule schränkt den Geltungsbereich ein.