Wie man Firewall-Regeln konfiguriert: Ein vollständiger technischer Leitfaden

Eine Firewall-Regel ist ein Richtlinieneintrag, der eine Firewall-Engine anweist, Netzwerkverkehr basierend auf definierten Kriterien wie Quell-/Ziel-IP-Adresse, Portnummer, Transportprotokoll und Verkehrsrichtung zu erlauben, zu verweigern oder zu protokollieren. Korrekt konfigurierte Firewall-Regeln bilden die primäre Durchsetzungsschicht zwischen Ihrer Infrastruktur und dem öffentlichen Internet und machen sie zur wichtigsten Sicherheitskontrolle auf jedem Server oder Netzwerkgerät.

Dieser Leitfaden behandelt die Firewall-Regelarchitektur, UFW unter Linux, firewalld, Windows Defender Firewall, nftables sowie die betrieblichen Praktiken, die eine gehärtete Umgebung von einer falsch konfigurierten unterscheiden.

Was Firewall-Regeln tatsächlich steuern

Jede Regel in einem Firewall-Regelwerk wird anhand von fünf grundlegenden Paketattributen ausgewertet, die allgemein als 5-Tupel bezeichnet werden:

• Quell-IP-Adresse — der ursprüngliche Host oder das Subnetz (z. B. 192.168.1.0/24)
• Ziel-IP-Adresse — der Zielhost oder -bereich
• Quellport — der ephemere Port auf der initiierenden Seite
• Zielport — der Dienstport auf der empfangenden Seite (z. B. 443 für HTTPS, 22 für SSH)
• Protokoll — TCP, UDP, ICMP oder Protokollnummer

Über das 5-Tupel hinaus verfolgen Stateful-Firewalls auch den Verbindungsstatus (NEW, ESTABLISHED, RELATED, INVALID), wodurch sie Rückverkehr für ausgehende Verbindungen erlauben können, ohne explizite eingehende Regeln für jede Antwort schreiben zu müssen.

Stateful vs. Stateless Firewalls

Für nahezu alle Server-Deployments — einschließlich VPS Hosting und Dedizierte Server — ist eine Stateful Host-basierte Firewall die richtige Standardwahl.

Verarbeitung von Firewall-Regeln: Das Reihenfolge-Problem

Eine der häufigsten Quellen für Fehlkonfigurationen ist das Missverständnis der Regelreihenfolge. Die meisten Firewalls werten Regeln von oben nach unten aus und wenden die erste übereinstimmende Regel an und stoppen dann. Das bedeutet:

• Eine breite ALLOW-Regel, die über einer spezifischen DENY-Regel platziert ist, überschreibt diese stillschweigend.
• Ein DENY ALL am Anfang einer Kette blockiert alles, unabhängig davon, was folgt.
• Doppelte oder überlagerte Regeln verschwenden Verarbeitungszyklen und erzeugen Verwirrung bei Audits.

Best Practice: Platzieren Sie immer spezifische Regeln vor allgemeinen. Platzieren Sie explizite DENY-Regeln für bekannte schädliche Quellen nahe am Anfang, gefolgt von spezifischen ALLOW-Regeln für vertrauenswürdige Dienste, und beenden Sie jede Kette mit einer Standard-DENY-Richtlinie.

Konfiguration von Firewall-Regeln unter Linux mit UFW

UFW (Uncomplicated Firewall) ist ein Frontend für iptables und nftables auf Debian/Ubuntu-basierten Systemen. Es abstrahiert die Low-Level-Chain-Syntax in menschenlesbare Befehle und bewahrt dabei die vollständige Kontrolle über Port-, Protokoll-, IP- und Schnittstellenfilterung.

Schritt 1: UFW installieren und aktivieren

UFW ist auf Ubuntu vorinstalliert. Überprüfen Sie den Status vor der Aktivierung:

sudo ufw status verbose

Falls inaktiv, aktivieren Sie es:

sudo ufw enable

Kritische Warnung: Wenn Sie über SSH verbunden sind und Port 22 noch nicht erlaubt haben, sperrt die Aktivierung von UFW Sie aus. Erlauben Sie SSH immer, bevor Sie die Firewall auf einem Remote-Server aktivieren.

Schritt 2: Standardrichtlinien festlegen

Standardrichtlinien definieren, was mit Datenverkehr passiert, der keiner expliziten Regel entspricht. Die sichere Basiskonfiguration lautet:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Dies verwirft alle unaufgeforderten eingehenden Verbindungen und erlaubt gleichzeitig den gesamten ausgehenden Datenverkehr. Wenn Ihre Sicherheitsrichtlinie eine Egress-Filterung erfordert (z. B. zur Verhinderung von Datenexfiltration oder C2-Callbacks), ändern Sie den ausgehenden Standard:

sudo ufw default deny outgoing

Erlauben Sie dann explizit nur die ausgehenden Ziele, die Ihre Anwendung benötigt.

Schritt 3: Bestimmte Dienste und Ports erlauben

UFW unterstützt Dienstnamen aus /etc/services oder explizite Portnummern:

# Allow SSH by service name
sudo ufw allow ssh

# Allow HTTP and HTTPS
sudo ufw allow http
sudo ufw allow https

# Allow a custom application port
sudo ufw allow 8080/tcp

# Allow a UDP service (e.g., DNS resolver)
sudo ufw allow 53/udp

Um einen Portbereich zu erlauben (z. B. passives FTP):

sudo ufw allow 49152:65535/tcp

Schritt 4: Zugriff auf bestimmte Quell-IPs beschränken

Das Exponieren von Verwaltungsports für 0.0.0.0/0 ist eine häufige Ursache für Brute-Force-Kompromittierungen. Beschränken Sie SSH auf eine bekannte Verwaltungs-IP:

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

Um ein gesamtes Verwaltungssubnetz zu erlauben:

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp

Schritt 5: Datenverkehr von bestimmten IPs oder Subnetzen verweigern

Eine bekannte schädliche IP blockieren:

sudo ufw deny from 198.51.100.77

Ein gesamtes Subnetz blockieren (z. B. eine geografische Sperre oder ein missbräuchlicher ASN-Bereich):

sudo ufw deny from 198.51.100.0/24

Sonderfall: UFW-deny-Regeln senden eine TCP RST- oder ICMP-Port-Unreachable-Antwort, die bestätigt, dass der Host existiert. Verwenden Sie reject, um Pakete stattdessen stillschweigend zu verwerfen:

sudo ufw reject from 198.51.100.0/24

Schritt 6: Aktive Regeln überprüfen

sudo ufw status numbered

Das Flag numbered weist jeder Regel einen Index zu, der für die gezielte Löschung erforderlich ist:

[ 1] 22/tcp                     ALLOW IN    203.0.113.50
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

Für eine vollständige ausführliche Ausgabe einschließlich Standardrichtlinien und Schnittstellenbindungen:

sudo ufw status verbose

Schritt 7: Regeln löschen

Nach Regelnummer löschen (bevorzugt — vermeidet Mehrdeutigkeiten):

sudo ufw delete 3

Nach Regelspezifikation löschen:

sudo ufw delete allow 8080/tcp

Schritt 8: Regeln neu laden und beibehalten

UFW-Regeln bleiben automatisch über Neustarts hinweg erhalten. Nach umfangreichen Änderungen ohne Unterbrechung bestehender Verbindungen neu laden:

sudo ufw reload

Um alle Regeln vollständig zurückzusetzen und von vorne zu beginnen:

sudo ufw reset

Erweitertes UFW: Anwendungsprofile

UFW unterstützt benannte Anwendungsprofile, die in /etc/ufw/applications.d/ gespeichert sind. Dadurch können Sie Multi-Port-Regeln unter einem einzigen Namen definieren:

sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw app info 'Nginx Full'

Erstellen eines benutzerdefinierten Profils für eine Node.js-API:

[NodeAPI]
title=Node.js API Server
description=Custom Node.js application
ports=3000,3001/tcp

Dann anwenden:

sudo ufw allow NodeAPI

Konfiguration von Firewall-Regeln mit firewalld (RHEL/CentOS/Fedora)

firewalld verwendet ein zonenbasiertes Modell anstelle eines flachen Regelwerks. Jede Netzwerkschnittstelle wird einer Zone zugewiesen (z. B. public, internal, dmz), und Regeln werden pro Zone angewendet. Dies ist architektonisch flexibler für Multi-Homed-Server.

Grundlegende firewalld-Operationen

# Check status
sudo firewall-cmd --state

# List all active zones and their interfaces
sudo firewall-cmd --get-active-zones

# List rules in the public zone
sudo firewall-cmd --zone=public --list-all

Dienste erlauben und entfernen

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

# Allow a custom port
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent

# Remove a service
sudo firewall-cmd --zone=public --remove-service=http --permanent

# Reload to apply permanent changes
sudo firewall-cmd --reload

Rich Rules für IP-spezifische Richtlinien

firewalld Rich Rules bieten die Granularität von iptables mit einer besser lesbaren Syntax:

# Allow SSH only from a specific IP
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="203.0.113.50" service name="ssh" accept' 
  --permanent

# Block all traffic from a subnet
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" drop' 
  --permanent

sudo firewall-cmd --reload

Konfiguration von Firewall-Regeln mit nftables

nftables ist der moderne Ersatz für iptables und bietet ein einheitliches Framework für IPv4-, IPv6-, ARP- und Bridge-Filterung mit deutlich besserer Leistung und atomarem Regelersatz.

Grundlegendes nftables-Regelwerk

# Flush existing ruleset
sudo nft flush ruleset

# Create a basic filtering table
sudo nft add table inet filter

# Add input, forward, and output chains
sudo nft add chain inet filter input { type filter hook input priority 0 ; policy drop ; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }
sudo nft add chain inet filter output { type filter hook output priority 0 ; policy accept ; }

# Allow established and related connections
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from a specific IP
sudo nft add rule inet filter input ip saddr 203.0.113.50 tcp dport 22 accept

# Allow HTTP and HTTPS from anywhere
sudo nft add rule inet filter input tcp dport { 80, 443 } accept

Um das Regelwerk dauerhaft zu speichern, sichern Sie es in der Standard-Konfigurationsdatei:

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Konfiguration von Firewall-Regeln unter Windows

Windows Defender Firewall mit erweiterter Sicherheit bietet sowohl GUI- als auch Befehlszeilen-Schnittstellen (netsh, PowerShell) für die Regelverwaltung.

Verwendung der GUI

1. Öffnen Sie Windows Defender Firewall mit erweiterter Sicherheit über wf.msc.
2. Wählen Sie Eingehende Regeln oder Ausgehende Regeln im linken Bereich.
3. Klicken Sie auf Neue Regel im rechten Bereich.
4. Wählen Sie den Regeltyp:

• Port — Filterung nach TCP/UDP-Portnummer
• Programm — Filterung nach ausführbarem Pfad
• Vordefiniert — Verwendung einer integrierten Windows-Dienstdefinition
• Benutzerdefiniert — vollständige Kontrolle über alle Parameter

1. Geben Sie den Port oder das Programm an, wählen Sie Zulassen oder Blockieren, wählen Sie die anwendbaren Profile (Domäne, Privat, Öffentlich) und benennen Sie die Regel.

Verwendung von PowerShell (empfohlen für die Automatisierung)

# Allow inbound HTTPS
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Allow inbound SSH (Windows OpenSSH)
New-NetFirewallRule -DisplayName "Allow SSH Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow `
  -RemoteAddress 203.0.113.50

# Block inbound traffic from a specific IP
New-NetFirewallRule -DisplayName "Block Malicious IP" `
  -Direction Inbound -RemoteAddress 198.51.100.77 -Action Block

# View all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Remove a rule by name
Remove-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

Verwendung von netsh (veraltet, aber weit verbreitet)

:: Allow inbound port 443
netsh advfirewall firewall add rule name="Allow HTTPS" protocol=TCP dir=in localport=443 action=allow

:: Block a specific IP
netsh advfirewall firewall add rule name="Block IP" dir=in remoteip=198.51.100.77 action=block

:: Delete a rule
netsh advfirewall firewall delete rule name="Allow HTTPS"

Kritische Fallstricke und Sonderfälle bei Firewall-Regeln

Die implizite Erlaubnis für ESTABLISHED-Datenverkehr

Bei Stateful-Firewalls führt das Fehlen einer expliziten Erlaubnis für ESTABLISHED– und RELATED-Verbindungen in der Input-Chain dazu, dass alle ausgehend initiierten Sitzungen unterbrochen werden (z. B. apt update, curl, DNS-Lookups), selbst wenn die Output-Chain auf ACCEPT gesetzt ist. Dies ist die häufigste Fehlkonfiguration bei reinen iptables– oder nftables-Setups.

# This rule MUST appear before any DROP rules in the input chain
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

IPv6-Parität

Viele Administratoren konfigurieren IPv4-Regeln sorgfältig und vergessen IPv6 vollständig. Wenn Ihr Server eine IPv6-Adresse hat und die IPv6-Unterstützung von UFW nicht aktiviert ist, kann ein Angreifer alle IPv4-Regeln umgehen, indem er sich über :: verbindet. Überprüfen Sie, ob /etc/default/ufw folgendes enthält:

IPV6=yes

Loopback-Schnittstelle

Erlauben Sie immer explizit den Datenverkehr auf der Loopback-Schnittstelle (lo). Viele lokale Dienste (Datenbanken, Message Queues, interne APIs) kommunizieren über 127.0.0.1 oder ::1. Das Blockieren von Loopback unterbricht die Inter-Prozess-Kommunikation stillschweigend.

sudo ufw allow in on lo
sudo ufw allow out on lo

Ratenbegrenzung zur Verhinderung von Brute-Force-Angriffen

UFW unterstützt nativ eine Verbindungsratenbegrenzung, die für SSH und andere Authentifizierungsdienste unerlässlich ist:

sudo ufw limit ssh

Dies erlaubt maximal 6 Verbindungsversuche pro 30 Sekunden von einer einzelnen IP, bevor eine automatische temporäre Sperre ausgelöst wird — eine leichtgewichtige Alternative zu fail2ban für einfache Deployments.

ICMP und Diagnosedatenverkehr

Das vollständige Blockieren von ICMP ist eine verbreitete, aber kontraproduktive Praxis. Es unterbricht ping, traceroute, MTU-Pfaderkennung und einige Routing-Protokolle. Der richtige Ansatz besteht darin, bestimmte ICMP-Typen zu erlauben:

• Typ 0 (Echo Reply) und Typ 8 (Echo Request) — für ping
• Typ 3 (Destination Unreachable) — für die Pfad-MTU-Erkennung
• Typ 11 (Time Exceeded) — für traceroute

Blockieren Sie Typ 17 (Address Mask Request) und Typ 18 (Address Mask Reply), die keinen legitimen modernen Verwendungszweck haben.

Firewall-Regeln und Hosting-Umgebungen

Die richtige Firewall-Strategie hängt stark von Ihrer Infrastrukturebene ab.

Bei Shared Web Hosting wird die Firewall auf Plattformebene vom Anbieter verwaltet. Mieter konfigurieren in der Regel Zugriffskontrollen auf Anwendungsebene anstelle von Paketfiltern auf Kernel-Ebene.

Bei einem VPS mit cPanel enthält cPanel/WHM ConfigServer Security & Firewall (CSF), das iptables mit einer High-Level-Schnittstelle, automatischer Brute-Force-Erkennung und Port-Knocking-Unterstützung umhüllt. CSF ist die Standard-Firewall-Lösung für cPanel-Umgebungen und sollte auf diesen Systemen gegenüber reinem UFW bevorzugt werden.

Auf nicht verwalteten VPS Hosting– oder Dedizierten Servern haben Sie die vollständige Kontrolle über die Kernel-Firewall. Hier sind UFW, firewalld und nftables die geeigneten Werkzeuge. Die Härtungs-Basiskonfiguration sollte Folgendes umfassen:

• Standard-Deny-Eingangsrichtlinie
• SSH auf bekannte Verwaltungs-IPs oder ein VPN-Gateway beschränkt
• Alle nicht wesentlichen Ports geschlossen
• Ratenbegrenzung auf Authentifizierungsports
• Protokollierung für verweigerten Datenverkehr aktiviert

Wenn Sie GPU-Workloads oder ML-Inferenzdienste auf GPU Hosting betreiben, achten Sie besonders auf die Ports, die von Jupyter Notebooks, TensorBoard und Modell-Serving-APIs exponiert werden — diese werden häufig von Cryptomining-Bots angegriffen, die nach offenen hochnummerierten Ports suchen.

Checkliste für Firewall-Regel-Audit und -Wartung

Regelmäßige Regelaudits sind genauso wichtig wie die Erstkonfiguration. Regeln häufen sich im Laufe der Zeit an und werden veraltet, was unnötige Angriffsflächen schafft.

Vierteljährlich durchzuführende Audit-Aufgaben:

• sudo ufw status numbered oder Äquivalent ausführen und jede Regel gegen das aktuelle Dienstinventar überprüfen
• Regeln für stillgelegte Dienste, alte IP-Adressen und temporäre Ausnahmen entfernen, die nie bereinigt wurden
• Überprüfen, ob die Standardrichtlinien noch deny incoming sind
• Sicherstellen, dass IPv6-Regeln IPv4-Regeln widerspiegeln
• Bestätigen, dass die Protokollierung aktiviert ist und dass Protokolle für verweigerten Datenverkehr von Ihrem SIEM oder Log-Aggregator erfasst werden
• Regeln mit nmap von einem externen Host testen, um zu überprüfen, ob die Angriffsfläche Ihrer Absicht entspricht

# Scan your own server from an external host to verify exposed ports
nmap -sS -sV -p 1-65535 --open YOUR_SERVER_IP

• Überprüfen, ob ESTABLISHED/RELATED-Regeln vorhanden und korrekt geordnet sind
• Ratenbegrenzungsregeln überprüfen und Schwellenwerte basierend auf beobachteten Verkehrsmustern anpassen

Entscheidungsmatrix: Das richtige Firewall-Tool wählen

Praktische Kernaussagen

• Legen Sie Standard-Deny für eingehenden Datenverkehr fest, bevor Sie Allow-Regeln schreiben. Dies stellt sicher, dass jede vergessene Regel zu einer blockierten Verbindung führt, nicht zu einer offenen.
• Exponieren Sie SSH niemals für 0.0.0.0/0 auf einem Produktionsserver. Beschränken Sie es auf eine Verwaltungs-IP, ein VPN-Subnetz oder verwenden Sie Port Knocking.
• Schreiben Sie Allow-Regeln so spezifisch wie möglich. Bevorzugen Sie from 203.0.113.50 to any port 22 proto tcp gegenüber allow 22.
• Spiegeln Sie IPv4-Regeln in IPv6. Eine Firewall, die nur IPv4 filtert, ist eine halbe Firewall.
• Aktivieren Sie die Verbindungsratenbegrenzung auf allen Authentifizierungsports als grundlegende Brute-Force-Abwehr.
• Protokollieren Sie verweigerten Datenverkehr. Stille Verwerfungen ohne Protokollierung machen die Reaktion auf Vorfälle nahezu unmöglich.
• Führen Sie Regelaudits nach einem Zeitplan durch. Veraltete Regeln sind eine Haftung, kein Sicherheitsnetz.
• Testen Sie von außen. Verwenden Sie nmap oder einen externen Port-Scanner nach jeder wesentlichen Regeländerung, um die effektive Angriffsfläche zu bestätigen.
• Verwenden Sie ufw reload anstelle von ufw disable && ufw enable, um das Unterbrechen aktiver Verbindungen während Regelaktualisierungen zu vermeiden.
• Bei nftables und iptables platzieren Sie die ESTABLISHED/RELATED-Accept-Regel immer am Anfang der Input-Chain, um das Unterbrechen ausgehend initiierter Sitzungen zu vermeiden.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Firewall-Regel und einer Sicherheitsgruppe in Cloud-Umgebungen?

Eine Sicherheitsgruppe (AWS, GCP, Azure) ist ein Stateful, cloud-verwalteter Paketfilter, der auf Hypervisor-Ebene angewendet wird, bevor der Datenverkehr Ihre VM erreicht. Eine Host-basierte Firewall-Regel (UFW, firewalld) läuft innerhalb des OS-Kernels. Beide sollten gleichzeitig für Defense in Depth verwendet werden — die Cloud-Sicherheitsgruppe als äußerer Perimeter und die Host-Firewall als innere Durchsetzungsschicht.

Warum zeigt UFW eine Regel als aktiv an, aber der Datenverkehr wird trotzdem blockiert?

Die häufigste Ursache ist die Regelreihenfolge. Eine DENY-Regel früher in der Chain stimmt überein, bevor Ihre ALLOW-Regel greift. Führen Sie sudo ufw status numbered aus und überprüfen Sie die Reihenfolge. Überprüfen Sie auch, ob IPv6-Regeln vorhanden sind, wenn der Client über IPv6 verbindet, und bestätigen Sie, dass die richtige Schnittstelle angesprochen wird, wenn der Server Multi-Homed ist.

Sollte ich ICMP vollständig aus Sicherheitsgründen blockieren?

Nein. Das Blockieren aller ICMP unterbricht die Pfad-MTU-Erkennung, was dazu führt, dass TCP-Sitzungen in Netzwerken mit nicht standardmäßigen MTUs hängen bleiben. Es unterbricht auch traceroute und erschwert die Netzwerkdiagnose erheblich. Blockieren Sie nur die ICMP-Typen ohne legitimen operativen Nutzen (Typen 17 und 18). Erlauben Sie Echo Request/Reply, Destination Unreachable und Time Exceeded.

Was passiert mit aktiven SSH-Verbindungen, wenn ich UFW neu lade?

sudo ufw reload lädt das Regelwerk neu, ohne bestehende conntrack-Statuseinträge zu löschen. Aktive SSH-Sitzungen bleiben verbunden, weil die Verbindungsverfolgungstabelle des Kernels noch deren ESTABLISHED-Status enthält. Nur sudo ufw disable gefolgt von sudo ufw enable würde den Status löschen und möglicherweise aktive Verbindungen unterbrechen.

Wie verhindere ich, dass Firewall-Regeln nach einem Systemneustart verloren gehen?

UFW speichert Regeln automatisch über Neustarts hinweg über /etc/ufw/-Konfigurationsdateien. Für firewalld verwenden Sie das Flag --permanent bei jeder Regel und führen Sie sudo firewall-cmd --reload aus. Für reines nftables speichern Sie das Regelwerk mit sudo nft list ruleset > /etc/nftables.conf und stellen Sie sicher, dass der nftables-systemd-Dienst aktiviert ist. Für iptables verwenden Sie iptables-save > /etc/iptables/rules.v4 und installieren Sie das Paket iptables-persistent.