# Firewall Orchestration: UFW, firewalld oder rohes nftables?

TL;DR / Management Summary Es gibt nicht “die eine” Firewall für Linux. Die Wahl des Werkzeugs hängt von der Distribution und dem Komplexitätsgrad ab. UFW ist der König der Einfachheit (Debian/Ubuntu), firewalld bietet mächtige Zonen-Konzepte für Enterprise-Server (RHEL/SLES) und nftables ist das Werkzeug für Puristen und High-Performance-Appliances. In diesem Modul vergleichen wir die Frameworks und geben eine klare Empfehlung für verschiedene Enterprise-Szenarien.

# 1. Einführung & Architektur

Die Abstraktions-Schichten.

Alle drei Tools steuern im Hintergrund den gleichen Kernel-Mechanismus: Netfilter / nftables. Sie unterscheiden sich nur in der Art der Bedienung und Verwaltung.

# Der Framework-Vergleich (Mermaid)

graph TD
    A[Admin User] --> B{Management Tool}
    B -->|Simple / Single Node| C[UFW]
    B -->|Zones / Enterprise| D[firewalld]
    B -->|Raw / Max Performance| E[nftables]
    C --> F[Kernel: nftables / iptables]
    D --> F
    E --> F

# 2. Die Kontrahenten im Detail

Stärken und Schwächen.

# 3. Entscheidungshilfe: Welches Tool für welchen Zweck?

Szenario-basierte Wahl.

# Szenario A: Standalone Webserver (Debian/Ubuntu)

Empfehlung: UFW.

• Warum?: Ein ufw allow http ist in Sekunden getippt. Die Komplexität von firewalld ist hier unnötiger Overhead.

# Szenario B: Enterprise Gateway / Hypervisor (RHEL/SLES)

Empfehlung: firewalld.

• Warum?: Durch das Zonen-Modell (Artikel 093) lassen sich verschiedene Netze (Management, Public, VM-Traffic) sauber trennen, ohne den Überblick zu verlieren.

# Szenario C: Spezialisierte Firewall-Appliance / Docker-Host

Empfehlung: nftables.

• Warum?: Maximale Performance bei zehntausenden Regeln (via Sets) und volle Kontrolle über die Interaktion mit Docker-Regeln.

# 4. Day-2 Operations: Fallstricke bei der Migration

Vom alten zum neuen Tool.

# Best Practice für den Wechsel

1. Status prüfen: nft list ruleset.
2. Alten Dienst stoppen und maskieren (Artikel 138).
3. Neuen Dienst konfigurieren und erst dann starten.

# 5. Troubleshooting & “War Stories”

Wenn das Tool die Sicht versperrt.

# Story 1: “Der D-Bus Hänger”

Symptom: firewall-cmd reagiert nicht mehr oder wirft Timeouts. Das System-Log ist sauber. Ursache: firewalld kommuniziert via D-Bus mit dem System. Wenn der D-Bus überlastet ist oder hakt, blockiert das Management-Tool, obwohl die Firewall im Kernel weiterarbeitet. Lösung: Nutzen Sie nft list ruleset als Fallback, um die Wahrheit im Kernel zu sehen. Starten Sie dbus und firewalld neu.

# Story 2: “UFW und die Docker-Lücke”

Symptom: Der Admin schaltet UFW aus, aber die Firewall-Regeln für Docker-Container bleiben aktiv. Ursache: UFW verwaltet nur seine eigenen Ketten. Docker erstellt eigene Iptables-Ketten, die von UFW ignoriert werden. Lösung: Verlassen Sie sich bei Docker-Hosts nicht blind auf UFW. Nutzen Sie spezialisierte Tools wie ufw-docker oder konfigurieren Sie Docker so, dass es Iptables nicht selbst verwaltet.

# 6. Fazit & Empfehlung

• Standard: Bleiben Sie beim Default Ihrer Distribution.
• Automatisierung: Nutzen Sie Ansible-Module für UFW/firewalld, anstatt Shell-Kommandos zu schicken.
• Sicherheit: Unabhängig vom Tool: Dokumentieren Sie jede Regel mit einem Kommentar (Reasoning).

# Anhang: Cheatsheet