Firewall-Regeln, die wirklich funktionieren: Häufige Fehler und bessere Standardeinstellungen

Firewall-Regeln richtig zu konfigurieren bedeutet mehr als nur schlechten Traffic zu blockieren - es geht darum, Regeln präzise genug zu schreiben, um Angreifer aufzuhalten, ohne die Dienste zu beeinträchtigen, auf die dein Team angewiesen ist. Die meisten Fehlkonfigurationen folgen denselben vorhersehbaren Mustern: zu weit gefasste Regeln, unkontrollierter ausgehender Traffic oder Standard-Allow-All-Richtlinien, die "vorübergehend" waren und nie angepasst wurden. Dieser Leitfaden zeigt die häufigsten Fehler von Sysadmins und Entwicklern - und die besseren Standardkonfigurationen, die sie ersetzen.

Eingehende und ausgehende Regeln erklärt

Jede Firewall bewertet Traffic in zwei Richtungen - und genau hier machen viele Teams den Fehler, beide als ein einziges Thema zu behandeln.

Inbound-Regeln steuern den Traffic, der von außen auf deinen Server oder dein Netzwerk zugreift. Wenn jemand deinen Webserver auf Port 80 oder 443 aufruft, ist das eingehender Traffic. Wenn ein Angreifer Port 22 nach einem SSH-Login abklopft, ebenfalls. Deine Inbound-Regeln entscheiden, ob diese Verbindungen durchkommen.

Outbound-Regeln steuern den Traffic, der deinen Server verlässt. Ein kompromittierter Server, der eine Verbindung zu einer Command-and-Control-Infrastruktur aufbaut, eine falsch konfigurierte App, die Daten an einen externen Endpoint überträgt, oder ein Container, der Pakete aus einer unbekannten Registry lädt - das alles ist ausgehender Traffic. Die meisten Teams konfigurieren Inbound-Regeln sorgfältig und lassen Outbound völlig unkontrolliert - ein ernsthafter Fehler.

In Cloud-Umgebungen wie AWS Security Groups werden Inbound- und Outbound-Regeln getrennt konfiguriert. In Linux iptables oder nftables entsprechen sie den INPUT- und OUTPUT-Chains. In der Windows Firewall sind sie in der Benutzeroberfläche buchstäblich als "Eingehende Regeln" und "Ausgehende Regeln" beschriftet. Das Konzept ist universell - die Umsetzung variiert je nach Plattform.

Häufige Firewall-Fehlkonfigurationen

1. 0.0.0.0/0 auf sensiblen Ports erlauben

Das ist das gefährlichste Muster in der Firewall-Konfiguration überhaupt. Das gesamte Internet auf folgende Ports zugreifen zu lassen, ist eine Einladung für Angreifer:

Das MongoDB-Beispiel verdient besondere Aufmerksamkeit. Zwischen 2017 und 2019 wurden zehntausende Datenbanken gelöscht und als Geiseln gehalten, weil MongoDB-Instanzen ohne Authentifizierung öffentlich erreichbar waren. Der IP-Blacklist-Checker ist eine nützliche Erinnerung daran, dass Expositionsüberwachung wichtig ist - denn "das findet schon niemand" ist keine Sicherheitsstrategie.

2. Ausgehenden Traffic ignorieren

Wenn ausgehender Traffic völlig uneingeschränkt bleibt, kann ein kompromittierter Host frei mit Angreifer-Infrastruktur kommunizieren, Daten exfiltrieren oder Teil eines Botnets werden. Ein Server, der eine Web-App betreibt, hat keinen legitimen Grund, ausgehende Verbindungen zu beliebigen IPs auf beliebigen Ports aufzubauen. Egress auf das Notwendige zu beschränken - deinen DNS-Resolver, dein Paket-Repository, deine API-Endpoints - schränkt die Handlungsmöglichkeiten eines Angreifers erheblich ein, selbst nachdem er Zugang erlangt hat.

3. Fehler in der Regelreihenfolge

Betrachte folgendes iptables-Setup:

# BAD: This allow-all rule fires first
-A INPUT -j ACCEPT
-A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j DROP

Die DROP-Regel für SSH aus diesem Subnetz ist vollkommen wirkungslos, weil jedes Paket zuerst auf die ACCEPT-Regel trifft. Die Lösung: Spezifische Regeln müssen vor allgemeinen stehen, und das Standard-Deny kommt ganz ans Ende.

4. Zu weit gefasste Port-Bereiche

Regeln wie "TCP 1024-65535 eingehend erlauben" sind in Legacy-Konfigurationen verbreitet und als Sicherheitskontrolle praktisch bedeutungslos. Wenn deine Anwendung Port 8080 nutzt, schreib eine Regel für Port 8080. Wenn du für passives FTP einen Bereich benötigst, dokumentiere genau, welchen Bereich dein Server verwendet, und beschränke dich darauf. Weite Bereiche existieren, weil jemand nicht nachschlagen wollte, welcher Port der richtige ist - nicht weil sie tatsächlich nötig waren.

5. Standard-Allow-All-Regeln nicht entfernen

Cloud-Anbieter verwenden beim Einrichten neuer Ressourcen oft permissive Standardregeln. Die Standard-Security-Group von AWS erlaubt den gesamten ausgehenden Traffic. Neue Azure-VMs erhalten eine eingehende "AllowAzureLoadBalancerInBound"-Regel, die in Ordnung ist - aber die Standard-Outbound-Regel erlaubt alles. Diese Standardwerte sind für einen schnellen Einstieg gedacht, nicht für den Produktionsbetrieb. Sobald du eine Workload in die Produktion überführst, überprüfe und verschärfe jede Standardregel.

6. Kein Logging bei Deny-Regeln

Eine Firewall, die Traffic stillschweigend verwirft, liefert dir keinerlei Informationen. Ohne Logging auf deinen Deny-Regeln kannst du nicht unterscheiden, ob ein Angreifer deine Ports abscannt oder ein legitimer Dienst falsch konfiguriert ist. Aktiviere Logging mindestens für deine Standard-Deny-Regeln, damit du eine Grundlage hast, was blockiert wird.

Bessere Standardkonfigurationen, die wirklich funktionieren

Die folgende Netzwerk-Sicherheitsrichtlinien-Struktur funktioniert in den meisten Umgebungen und gibt dir einen soliden Ausgangspunkt, den du anpassen kannst - statt einem permissiven Chaos, das du erst bereinigen musst.

Inbound-Regeln

• Standard: Alles eingehende DENY. Beginne damit, nichts zu erlauben, und öffne explizit nur das, was benötigt wird.
• Port 80 (HTTP) und 443 (HTTPS): Von 0.0.0.0/0 erlauben, nur wenn es sich um einen öffentlich erreichbaren Webserver handelt. Bei rein internen Servern auf deinen internen IP-Bereich beschränken.
• Port 22 (SSH): NUR von spezifischen IP-Adressen oder CIDR-Blöcken erlauben - deiner Büro-IP, deinem VPN-Exit-Node, deinem Bastion-Host. Niemals von 0.0.0.0/0.
• Port 3389 (RDP): Wie SSH - nur spezifische IPs, oder noch besser: vollständig hinter ein VPN legen und nicht ins Internet exponieren.
• Port 3306 (MySQL) und 5432 (PostgreSQL): Nur von den privaten IPs deiner Applikationsserver erlauben. Diese Ports sollten vom öffentlichen Internet aus niemals erreichbar sein.
• ICMP (Ping): Von vertrauenswürdigen Bereichen für Diagnosezwecke erlauben. Vollständiges Blockieren erschwert die Fehlersuche erheblich, ohne nennenswerten Sicherheitsgewinn.

Outbound-Regeln

• Port 53 (DNS): Nur zu deinen festgelegten DNS-Resolvern erlauben (z.B. dem internen Resolver deines VPC oder einer spezifischen IP wie 1.1.1.1).
• Port 80 und 443: Zu bekannten Zielen erlauben - deinen Paket-Repositories, deinen APIs, deinem CDN. Wenn du sie aufzählen kannst, tu es.
• Port 25 (SMTP): Ausgehenden SMTP blockieren, sofern dieser Server nicht explizit als Mailserver fungiert. Kompromittierte Server, die Spam versenden, sind ein häufiges Anzeichen für einen Einbruch.
• Alles andere: Standardmäßig DENY.

Hier ist ein minimales iptables-Beispiel, das diesen Ansatz für einen Webserver umsetzt:

# Flush existing rules
iptables -F

# Default policies: deny all inbound and outbound
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Inbound: HTTP and HTTPS from anywhere (public web server)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Inbound: SSH only from your office IP
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.50 -j ACCEPT

# Outbound: DNS to internal resolver
iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT

# Outbound: HTTPS for package updates
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# Log dropped inbound packets
iptables -A INPUT -j LOG --log-prefix "DROPPED-IN: " --log-level 4

Für ein tieferes Verständnis, wie Port-Filterung auf Protokollebene funktioniert, erklärt die TCP-Spezifikation in RFC 793 genau, was beim Verbindungsaufbau passiert - also genau das, was deine Firewall abfängt, wenn sie Regeln gegen eingehende Pakete auswertet.

Separate Regeln für Dev, Staging und Prod

Eine der am meisten unterschätzten Gewohnheiten bei der Firewall-Konfiguration ist es, jede Umgebung als eigenständig zu behandeln - mit einem eigenen Regelwerk. Dieselbe Security Group oder Firewall-Richtlinie für Dev und Prod zu verwenden, ist der Grund, warum "temporäre" Debug-Ports am Ende in der Produktion exponiert sind.

Eine praktische Struktur dafür:

• Dev: Großzügigere Inbound-Regeln aus dem IP-Bereich deines Teams. Port 8080, 8443 und andere Entwicklungsports offen. Datenbankports von Entwicklermaschinen aus erreichbar. Logging optional.
• Staging: Prod-Regeln so genau wie möglich spiegeln. Das Ziel ist, Firewall-bezogene Probleme zu erkennen, bevor sie die Produktion erreichen. Zugang für die IPs deines QA-Teams hinzufügen.
• Prod: Strengste Regeln. Keine Debug-Ports. Kein direkter Datenbankzugriff von außerhalb des privaten Subnetzes. Alle Deny-Regeln protokolliert. SSH nur über einen Bastion-Host oder VPN.

Versehe deine Firewall-Regeln mit Tags für die jeweilige Umgebung. In AWS nutze Resource-Tags auf Security Groups. In Terraform oder anderen IaC-Tools verwende variablengesteuerte Regelsets, sodass Dev- und Prod-Regeln dieselbe Struktur, aber unterschiedliche Werte teilen. Das macht Audits erheblich einfacher.

Du kannst auch unser Ping-Tool nutzen, um schnell zu prüfen, ob ein Host in einer bestimmten Umgebung auf Netzwerkebene erreichbar ist, bevor du mit portspezifischen Prüfungen beginnst.

Überprüfen, was tatsächlich exponiert ist

Firewall-Regeln zu schreiben ist nur die halbe Arbeit. Die andere Hälfte besteht darin, zu bestätigen, dass das, was du blockieren wolltest, tatsächlich blockiert ist - und das, was du erlauben wolltest, wirklich erreichbar ist. Genau hier überspringen viele Teams einen Schritt und deployen falsch konfigurierte Systeme.

Führe nach jeder Änderung an deiner Firewall-Konfiguration eine externe Port-Prüfung von außerhalb deines Netzwerks durch. Das simuliert, was ein Angreifer sehen würde - nicht das, was dein internes Monitoring als exponiert einschätzt.

Was du nach jeder Firewall-Änderung prüfen solltest:

• Port 22 (SSH): Sollte von jeder IP, die nicht auf deiner Erlaubnisliste steht, als CLOSED oder TIMEOUT erscheinen.
• Port 3306 (MySQL) und 5432 (PostgreSQL): Sollten vom öffentlichen Internet aus niemals als OPEN erscheinen.
• Port 3389 (RDP): Sollte CLOSED oder TIMEOUT sein, sofern du ihn nicht bewusst mit IP-Einschränkungen freigegeben hast.
• Port 80 und 443: Sollten auf öffentlich erreichbaren Webservern OPEN sein.
• Alle benutzerdefinierten Anwendungsports: Prüfen, ob sie deiner Absicht entsprechen - offen wo nötig, geschlossen überall sonst.

Du kannst auch unser DNS-Lookup-Tool nutzen, um zu bestätigen, dass der Hostname, den du testest, zur erwarteten IP aufgelöst wird, bevor du Port-Prüfungen durchführst - hilfreich in Umgebungen, wo DNS-Einträge und tatsächliche Server-IPs nicht immer übereinstimmen.

Sieh genau, welche Ports nach dem Anwenden deiner Firewall-Regeln exponiert sind

Nutze unseren kostenlosen Port Checker, um zu testen, ob SSH (22), RDP (3389), MySQL (3306), PostgreSQL (5432) und andere sensible Ports von außen tatsächlich offen oder geschlossen sind - damit du sicherstellen kannst, dass deine Firewall-Konfiguration wie beabsichtigt funktioniert und nicht nur korrekt geschrieben ist.

Offene Ports prüfen →