Eine Cloud-Firewall-Regel ist eine Anweisung, die Traffic anhand eines 5-Tupels prüft – Quelladresse, Zieladresse, Protokoll, Quellport und Zielport – und ihn entweder zulässt oder verwirft. Die wichtigste Entscheidung bei jeder Firewall ist die Standardrichtlinie: Standardmäßig alles blockieren und dann explizit nur das erlauben, was du wirklich brauchst. Alles andere in diesem Artikel sind Details, die auf dieser einen Regel aufbauen.
Worauf eine Firewall-Regel tatsächlich prüft
Jedes Paket hat eine Quell-IP, eine Ziel-IP, eine Protokollnummer (TCP, UDP, ICMP usw.) und – bei TCP und UDP – einen Quell- und einen Zielport. Cloud-Firewalls (AWS Security Groups, Azure NSGs, GCP-VPC-Firewall-Regeln) werten Regeln alle anhand desselben 5-Tupels aus, auch wenn die Oberflächen unterschiedlich aussehen. Wenn du eine Regel wie „allow TCP 443 from 0.0.0.0/0“ schreibst, weist du die Firewall an, jedes Paket mit Protokoll TCP, Zielport 443 und beliebiger Quelladresse zuzulassen.
ICMP (das Protokoll hinter ping und Path MTU Discovery) wird oft als eigene Klasse behandelt, getrennt von TCP/UDP. Es braucht daher eine eigene explizite Allow-Regel, wenn Diagnosewerkzeuge wie ping durch die Firewall funktionieren sollen.
Default-Deny vs. Default-Allow
Default-Deny bedeutet: Trifft keine Regel auf den Traffic zu, wird er verworfen. Default-Allow bedeutet das Gegenteil – alles, was nicht explizit blockiert ist, kommt durch. Default-Deny gilt bei allen großen Cloud-Anbietern als Best Practice für eingehenden Traffic, weil ein vergessener oder falsch konfigurierter Dienst dann standardmäßig unerreichbar ist statt standardmäßig offen.
Die meisten Anbieter setzen neue Firewall-Gruppen bereits standardmäßig auf „eingehend alles blockieren, ausgehend alles erlauben“:
- AWS Security Groups – neue benutzerdefinierte Gruppen blockieren standardmäßig allen eingehenden Traffic, erlauben allen ausgehenden und unterstützen nur Allow-Regeln (kein explizites Deny; nicht passender Traffic wird implizit verworfen).
- Azure NSGs – werden mit Standardregeln ausgeliefert, die VNet-zu-VNet- und Load-Balancer-Traffic erlauben, alles andere eingehend blockieren und ausgehenden Traffic ins VNet und ins Internet erlauben. Diese Standardregeln lassen sich nicht löschen, aber durch eine benutzerdefinierte Regel mit höherer Priorität überschreiben.
- GCP-VPC-Firewall-Regeln – jedes Netzwerk hat eine implizite Allow-all-Egress-Regel und eine implizite Deny-all-Ingress-Regel mit der niedrigsten Priorität, die von deinen expliziten Regeln mit höherer Priorität überschrieben werden.
Die praktische Konsequenz: Verlass dich nicht auf „das offen zu lassen war bestimmt okay“ – fang geschlossen an und öffne Ports einzeln, sobald Dienste sie brauchen.
Eingehend vs. ausgehend: Warum beide Richtungen zählen
Eingehende Regeln steuern, was deinen Server erreichen kann. Ausgehende Regeln (Egress) steuern, was dein Server im Internet erreichen kann. Die meisten kümmern sich ausschließlich um eingehenden Traffic und ignorieren ausgehenden komplett – ein Fehler, denn uneingeschränkter Egress ist genau das, was es einem kompromittierten Server ermöglicht, Daten abzuziehen oder einen Command-and-Control-Host zu kontaktieren.
Ob du für beide Richtungen separate Regeln schreiben musst, hängt davon ab, ob die Firewall stateful oder stateless ist:
- Stateful Firewalls (AWS Security Groups, Azure NSGs, GCP-VPC-Regeln für bestehende Verbindungen) verfolgen die Verbindung anhand von TCP-Flags (SYN, ACK, FIN). Erlaubst du eine eingehende Anfrage, wird der zugehörige Antwort-Traffic automatisch wieder hinausgelassen – eine gespiegelte Regel brauchst du nicht.
- Stateless Firewalls (AWS Network ACLs sind das klassische Beispiel) werten jedes Paket unabhängig in nummerierter Reihenfolge aus. Du musst also explizite Regeln für Anfrage und Antwort schreiben, einschließlich der hohen ephemeren Rückports.
UDP hat überhaupt keinen Verbindungszustand (es ist von Grund auf verbindungslos). Firewalls, die angeblich UDP-„Sessions“ verfolgen, arbeiten in Wirklichkeit mit Timeouts und Heuristiken, nicht mit einer echten Zustandstabelle wie bei TCP.
NoteAWS Security Groups unterstützen nur Allow-Regeln, die ohne Reihenfolge per ODER verknüpft werden – eine Regelpriorität gibt es dort nicht. Network ACLs, Azure NSGs und GCP-Firewall-Regeln nutzen dagegen eine nummerierte Priorität, bei der die niedrigere Zahl gewinnt.
Offene Ports: Diese bleiben oft versehentlich offen
Die meisten vermeidbaren Sicherheitsvorfälle gehen auf eine Handvoll vorhersehbarer Fehler zurück, nicht auf Zero-Days. Typische Kandidaten:
| Port | Dienst | Warum es riskant ist, ihn für 0.0.0.0/0 offen zu lassen |
|---|---|---|
| 22 | SSH | Ziel für Brute-Force-Angriffe; sollte auf bekannte IPs oder einen Bastion-Host beschränkt sein |
| 3389 | RDP | Gleiches Problem wie bei SSH, wird von Bots massiv gescannt |
| 3306 / 5432 | MySQL / PostgreSQL | Datenbanken sollten nie aus dem Internet erreichbar sein; nutze ein privates Netzwerk oder VPN |
| 6379 | Redis | Wird häufig ganz ohne Authentifizierung betrieben; beliebtes Ziel für Krypto-Mining-Botnets |
| 27017 | MongoDB | Gleiches Muster wie bei Redis – öffentlich + ohne Authentifizierung ist eine häufige Fehlkonfiguration |
| 9200 | Elasticsearch | Wird oft beim Testen freigegeben und danach nie wieder abgesichert |
Die Lösung ist fast immer dieselbe: Beschränke die Quelle der Regel auf deine Büro-IP, einen VPN-Bereich oder ein privates Subnetz statt 0.0.0.0/0 – oder stell den Dienst hinter einen Bastion-Host und entferne die öffentliche Regel ganz. Eine Regel, die während einer Debugging-Session „vorübergehend“ geöffnet wurde, ist genau die, die ein Jahr später am wahrscheinlichsten noch da ist.
Praxisbeispiel: Einen Webserver absichern
Ein typischer öffentlicher Webserver braucht nur drei eingehende Allow-Regeln, alles andere wird standardmäßig blockiert:
Allow TCP 443 from 0.0.0.0/0 # HTTPS
Allow TCP 80 from 0.0.0.0/0 # HTTP (redirect to 443)
Allow TCP 22 from 203.0.113.0/24 # SSH, office range only
Deny all * from 0.0.0.0/0 # implicit or explicit default-deny
Ausgehend kann es meist offener bleiben (Allow-all-Egress ist bei Webservern üblich, die externe APIs aufrufen, Updates holen oder ausgehende Mails versenden müssen). Hat der Server aber keinen Grund, mit beliebigen Hosts zu kommunizieren, schränk auch den Egress ein – genau das begrenzt den Schaden tatsächlich, falls die Maschine jemals kompromittiert wird.
Reihenfolge der Regelauswertung je nach Anbieter
Das sorgt für mehr Verwirrung als alles andere: AWS Security Groups haben überhaupt keine Reihenfolge – jede Allow-Regel wird unabhängig ausgewertet und die Ergebnisse werden per ODER verknüpft, die Reihenfolge in der Konsole ist also rein kosmetisch. Azure NSGs und GCP-Firewall-Regeln nutzen dagegen eine numerische Priorität, bei der die niedrigste Zahl gewinnt und die Auswertung beim ersten Treffer stoppt. AWS Network ACLs verhalten sich genauso – nummeriert, erster Treffer, Stopp. Wenn du das Modell eines Anbieters gewohnt bist und zu einem anderen wechselst, ist das genau das Detail, das am meisten Verwirrung stiftet. Prüf es also explizit, statt es vorauszusetzen.
Firewall-Regeln anbieterübergreifend konsistent halten
Wer Workloads über AWS, Azure, GCP und ein paar VPS-Anbieter verteilt betreibt, dupliziert die Firewall-Logik in drei oder vier verschiedenen Konsolen, jede mit eigenen Eigenheiten bei Standardwerten, Prioritäten und Regellimits. Genau diese Art von Drift führt dazu, dass bei einem Anbieter noch eine veraltete Regel offen ist, lange nachdem sie überall sonst bereinigt wurde – wie das in der Praxis passiert, erfährst du in Infrastructure Drift erklärt. Mit der Firewall-Verwaltung von InfraNest definierst und prüfst du Regeln zentral für jeden Cloud-Server, den du betreibst – so ist eine Default-Deny-Strategie etwas, das du tatsächlich überprüfen kannst, statt es nur anzunehmen.
Wenn du heute einen neuen Server aufsetzt, starte mit einer Default-Deny-Richtlinie für eingehenden Traffic, öffne nur die Ports, für die du einen Grund nennen kannst, und prüfe den Egress mindestens einmal – das ist die Richtung, die fast alle vergessen. Wirf einen Blick auf Cloud-Server-Firewalls, um das anbieterübergreifend einheitlich zu verwalten.
Häufig gestellte Fragen
#Was ist der Unterschied zwischen einer stateful und einer stateless Firewall?
Eine stateful Firewall verfolgt den Verbindungszustand anhand von TCP-Flags. Erlaubst du eingehenden Traffic, wird der zugehörige Rückverkehr automatisch zugelassen, ohne dass du eine separate Regel brauchst. Eine stateless Firewall wie AWS Network ACLs wertet jedes Paket unabhängig aus und benötigt explizite Regeln für beide Richtungen.
#Sollte ich auch ausgehenden Traffic (Egress) einschränken?
Ja – uneingeschränkter Egress ermöglicht es einem kompromittierten Server, Daten abzuziehen oder einen Command-and-Control-Host zu kontaktieren. Beschränkst du ausgehende Regeln auf die Ziele, die ein Dienst wirklich braucht, begrenzt du den Schaden, falls er jemals angegriffen wird.
#Warum sollte ich einen Datenbank-Port wie 3306 oder 5432 nicht ins Internet freigeben?
Datenbanken sind häufige Ziele für automatisierte Scans und Brute-Force-Angriffe, und viele Sicherheitsvorfälle gehen auf einen Datenbank-Port zurück, der für 0.0.0.0/0 offen war. Halte den Datenbankzugriff stattdessen in einem privaten Netzwerk, einem VPN oder einem eingeschränkten IP-Bereich.
#Spielt die Reihenfolge der Regeln bei Cloud-Firewalls eine Rolle?
Das hängt vom Anbieter ab: AWS Security Groups haben keine Reihenfolge (alle Allow-Regeln werden per ODER verknüpft), während Azure NSGs, GCP-Firewall-Regeln und AWS Network ACLs eine nummerierte Priorität mit First-Match-Auswertung nutzen – dort spielt die Reihenfolge also eine Rolle.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
