Wann solltest du Cloud-Firewalls einsetzen?

Setze für alles, was aus dem Internet erreichbar ist, eine Cloud-Firewall als erste Verteidigungslinie ein und lass darunter eine Host-Firewall als zweite, unabhängige Schutzschicht laufen. Cloud-Firewalls (Security Groups, Network Security Groups, Paketfilter auf Cloud-Ebene) sitzen außerhalb des Servers und blockieren Traffic, bevor er überhaupt CPU, Bandbreite oder einen lauschenden Socket beansprucht. Host-Firewalls (iptables, nftables, ufw, Windows Defender Firewall) laufen direkt auf der Maschine und sind deine letzte Verteidigungslinie, falls die Netzwerkebene falsch konfiguriert ist oder umgangen wird.

Kurz gesagt: Cloud-Firewalls für die Perimeterkontrolle und um den möglichen Schaden zu begrenzen, Host-Firewalls für Defence-in-Depth und alles, was die Cloud-Ebene nicht sieht (Loopback-Traffic, Regeln zwischen Containern, prozessbezogene Filterung). Die meisten Produktivumgebungen brauchen beides.

Was ist der Unterschied zwischen Cloud-Firewall und Host-Firewall?

Eine Cloud-Firewall wird von der Netzwerkinfrastruktur des Anbieters durchgesetzt, also vor der Netzwerkschnittstelle deines Servers. Abgelehnter Traffic berührt nie die CPU oder die NIC deiner Instanz – er wird bereits auf Hypervisor- oder Software-Defined-Networking-Ebene verworfen. Dadurch sind Cloud-Firewalls günstig im Betrieb (sie verbrauchen keine Serverressourcen) und wirksam gegen volumetrische Angriffe und einfache Portscans, weil das Rauschen deine Maschine gar nicht erst erreicht.

Eine Host-Firewall läuft als Software im Betriebssystem und prüft Pakete, nachdem sie bereits an der Netzwerkschnittstelle angekommen sind. Sie ist flexibler – du kannst nach Prozess, Benutzer oder Anwendungslogik filtern, und sie funktioniert identisch, egal ob der Server Bare Metal ist, eine Cloud-VM oder hinter überhaupt keiner Cloud-Firewall steht. Dafür kostet sie pro Paket etwas CPU, und wenn das Betriebssystem kompromittiert oder falsch konfiguriert ist, kann ein Angreifer sie unter Umständen deaktivieren.

Wann solltest du eine Cloud-Firewall einsetzen?

Setze eine Cloud-Firewall immer dann ein, wenn dein Server eine öffentliche IP-Adresse hat. Deine Standardregel sollte lauten: Allen eingehenden Traffic blockieren, außer auf den Ports, die du ausdrücklich brauchst – angewendet auf Netzwerkebene, bevor irgendetwas die Instanz erreicht.

Cloud-Firewalls sind das richtige Werkzeug, wenn du:

• den SSH- oder RDP-Zugriff auf eine feste Liste von Büro- oder VPN-IP-Adressen beschränken willst, statt Management-Ports dem gesamten Internet auszusetzen.
• die Schichten einer Anwendung segmentieren willst – zum Beispiel nur deinen Webservern erlauben, deine Datenbankserver über den Datenbankport zu erreichen, und alles andere zwischen den Subnetzen blockieren.
• Scans und einfachen Angriffstraffic abfangen willst, ohne dafür Server-CPU zu verbrauchen. Ein vorgelagert verworfenes Paket berührt nie den TCP-Stack deiner Instanz.
• einheitliche Regeln für eine ganze Serverflotte anwenden willst, indem du jeder Instanz einer Rolle dasselbe Regelset (oft Security Group oder Firewall-Policy genannt) zuweist, statt jede Maschine einzeln zu konfigurieren.
• bei einem Vorfall schnell einen Port flottenweit sperren oder öffnen willst, ohne dich per SSH auf jeden einzelnen Server einzuloggen.

Wenn du mehrere Cloud-Server bei verschiedenen Anbietern betreibst, wird es schnell fehleranfällig, diese Regelsets von Hand konsistent zu halten – eine Firewall-Regel, die in der Konsole des einen Anbieters stimmt, wird bei einem anderen leicht vergessen. Wenn du deine Cloud-Server über ein einziges Dashboard verwaltest, kannst du viel einfacher prüfen, welche Ports in deiner gesamten Flotte tatsächlich offen sind, statt darauf zu vertrauen, dass alle daran gedacht haben, die Konsole jedes Anbieters auf die gleiche Weise zu aktualisieren.

Wann solltest du eine Host-Firewall einsetzen (oder beides)?

Setze auf jedem Server eine Host-Firewall ein, unabhängig davon, ob zusätzlich eine Cloud-Firewall vorhanden ist. Sie ist dein Rückfallnetz, falls eine Cloud-Regel versehentlich gelockert wird, falls der Server später auf Bare Metal oder zu einem anderen Anbieter ohne vergleichbare Kontrollen umzieht oder falls du Filterlogik brauchst, die die Cloud-Ebene nicht abbilden kann – etwa Rate-Limiting pro Quell-IP, Filterung nach Prozess/UID oder die Behandlung von East-West-Traffic zwischen Containern auf demselben Host.

Nutze beides, wenn:

• der Server aus dem Internet erreichbar ist und sensible Daten verarbeitet – Zahlungsdaten, Authentifizierung, Kundendaten. Defence-in-Depth bedeutet, dass eine einzelne Fehlkonfiguration nicht gleich zu einem Sicherheitsvorfall führt.
• du den Server als Teil einer Flotte verwaltest, in der Cloud-Firewall-Regeln abdriften oder von jemandem mit Konsolenzugriff überschrieben werden könnten.
• du Verbindungsstatus-Tracking oder Logging brauchst, das sich lokal leichter konfigurieren und prüfen lässt als über eine Cloud-Konsole.

Nutze nur eine Host-Firewall, wenn tatsächlich keine Firewall auf Cloud-Ebene verfügbar ist – manche kleineren Anbieter und Dedicated-/Bare-Metal-Hoster bieten keine an – oder wenn der Server gar keine öffentliche IP hat und vollständig in einem privaten Netzwerk läuft, das du bereits am Router kontrollierst.

WarningVerlass dich nie allein auf die Cloud-Firewall und lass die Host-Firewall nicht deaktiviert, „weil die Cloud das ja schon blockiert“. Eine einzige falsch angewendete Regel, eine vorübergehende Debugging-Änderung, die jemand vergisst zurückzunehmen, oder ein Server, der in eine neue Security Group mit lockereren Standardeinstellungen verschoben wird, entfernt deine einzige Schutzschicht.

Sinnvolle Standardregeln für den Einstieg

Eine vernünftige Ausgangskonfiguration für einen typischen Webserver, angewendet sowohl auf Cloud- als auch auf Host-Ebene:

# Cloud firewall (security group) — inbound
Allow  tcp/22   from <your office/VPN IP only>
Allow  tcp/80   from 0.0.0.0/0
Allow  tcp/443  from 0.0.0.0/0
Deny   all      from 0.0.0.0/0

# Host firewall (ufw) — mirrors and backs up the above
ufw default deny incoming
ufw default allow outgoing
ufw allow from <your office/VPN IP> to any port 22
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Ein paar Gewohnheiten, mit denen das auf Dauer überschaubar bleibt:

• Eingehenden Traffic standardmäßig blockieren und dann nur explizit erlauben, was gebraucht wird – niemals standardmäßig alles erlauben und versuchen, das Schlechte herauszufiltern.
• Datenbankports (5432, 3306, 27017 usw.) auf keiner der beiden Ebenen für 0.0.0.0/0 öffnen; beschränke sie auf die konkreten Anwendungsserver, die sie brauchen.
• Abgelehnte Verbindungen nach jeder Änderung eine Zeit lang auf Host-Ebene protokollieren, damit du eine zu strenge Regel bemerkst, bevor sie in der Produktion etwas kaputt macht.
• Regeln jedes Mal überprüfen, wenn ein Server seine Rolle wechselt – eine alte „Alles erlauben zum Testen“-Regel auf einer Maschine, die später in Produktion geht, ist ein häufiger Grund, warum Perimeter unbemerkt schwächer werden.

Überblick über alle Anbieter hinweg

Das Schwierigste an sauberer Firewall-Hygiene ist nicht das Schreiben der Regeln – sondern auf einen Blick zu wissen, welche Ports auf jedem deiner Server tatsächlich offen sind, besonders sobald du mehr als einen Cloud-Anbieter nutzt. Betrachte deine Firewall-Konfiguration als etwas, das du regelmäßig prüfst, und nicht als etwas, das du einmal einrichtest und dann vergisst.

Wenn du Server bei mehreren Cloud-Anbietern verwaltest und an einer Stelle sehen willst, was tatsächlich offenliegt, wirf einen Blick auf die Cloud-Server-Funktion von InfraNest.