Leichtgewichtige Firewall auf Ihrem Cloud-Server einrichten (UFW-Anleitung)

Frisch installiertes Linux-VPS, öffentliche IP – und schon landet der Server im Visier automatischer Scanner. Wir haben einen frisch gebooteten Ubuntu-22.04-Server beobachtet: Innerhalb von vier Stunden tauchten in /var/log/auth.log über tausend SSH-Brute-Force-Versuche aus aller Welt auf. Die Security Group des Cloud-Anbieters fängt einen Teil ab, aber die Firewall auf Systemebene ist die zweite Verteidigungslinie, die Sie wirklich selbst kontrollieren.

Auf Ubuntu- und Debian-Servern ist UFW (Uncomplicated Firewall) praktisch die Standardlösung: einfache Syntax, nahtlose Anbindung an iptables, gute Dokumentation. Dieser Artikel erklärt nicht dutzende iptables-Kettenregeln, sondern fasst einen in Produktion erprobten UFW-Workflow als Checkliste zusammen – von Installation und SSH-Freigabe über Web-Ports und Docker-Koexistenz bis zur Zusammenarbeit mit Cloud-Security-Groups. Und vor allem: wie Sie die Firewall konfigurieren, ohne sich auszusperren.

Voraussetzung: Sie sind per SSH oder Cloud-Konsole (VNC) eingeloggt und haben sudo-Rechte. Wenn SSH bereits nicht mehr funktioniert, lesen Sie zuerst unseren Leitfaden zur Fehlerbehebung bei SSH-Verbindungsabbrüchen auf Linux-Servern, klären Sie Netzwerk- vs. Firewall-Problem – und kommen Sie dann hierher zurück.

Warum braucht ein Cloud-Server eine Firewall?

Viele denken: „Ich habe eine Security Group, im System muss ich nichts mehr tun.“ Tatsächlich haben die beiden Ebenen unterschiedliche Aufgaben: Die Cloud-Security-Group filtert außerhalb der virtuellen NIC, verwaltet über die Web-Konsole; UFW filtert auf Kernel-Ebene (netfilter), verwaltet über die Kommandozeile. Nur eine Ebene zu nutzen, ist wie ein Haustor zu verriegeln, aber die Schlafzimmertür offen zu lassen – laterale Bewegung im internen Netz, versehentlich exponierte Dienste und Reverse Shells nach einem Einbruch brauchen Regeln auf Systemebene.

UFW ist laut der offiziellen Ubuntu-UFW-Dokumentation ein iptables-Frontend: ufw allow 22 wird in entsprechende ACCEPT-Regeln übersetzt. Die Syntax ist nahe an natürlicher Sprache, ufw status numbered zeigt die aktuelle Policy auf einen Blick, und Regeln lassen sich ändern, ohne den Überblick zu verlieren.

Schritt 1: UFW installieren und prüfen

Ubuntu Desktop und die meisten Server-Images haben UFW vorinstalliert; minimale Images oft nicht. Zuerst prüfen:

sudo apt update
                sudo apt install ufw -y

                # Aktuellen Status anzeigen (inactive = noch nicht aktiv)
                sudo ufw status verbose

                # Autostart (Regeln vor enable konfigurieren)
                sudo systemctl enable ufw

Zeigt die Ausgabe Status: inactive, können Sie Regeln sicher einzeln hinzufügen – sie greifen noch nicht. Das ist das beste Konfigurationsfenster. Führen Sie niemals ufw enable aus, bevor SSH freigegeben ist – sonst verlieren Sie sofort die Remote-Verbindung.

Schritt 2: SSH freigeben (die wichtigste Regel)

SSH ist Ihr Admin-Kanal und muss als Erstes freigegeben werden. Wenn sshd auf einem Nicht-Standard-Port läuft (z. B. 2222), muss der Port in der Regel mit sshd_config übereinstimmen – und die Security Group muss ebenfalls angepasst werden.

# Standard-Port 22
                sudo ufw allow 22/tcp comment 'SSH'

                # Benutzerdefinierter Port
                sudo ufw allow 2222/tcp comment 'SSH custom'

                # Nur Büro-Exit-IP (empfohlen in Produktion)
                sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

                # Nach Dienstname (wenn in /etc/services definiert)
                sudo ufw allow OpenSSH

Prüfen, ob sshd wirklich lauscht: sudo ss -tlnp | grep ssh. Sehen Sie 0.0.0.0:22 oder [::]:22, läuft der Dienst. Ist ListenAddress auf 127.0.0.1 gesetzt, hilft UFW nicht – das ist ein sshd-Konfigurationsproblem, kein Firewall-Problem.

Wie SSH-Port und Security Group zusammenspielen, erklärt unser FAQ zur Minimal-Exposition und Firewall-Entscheidungen für Linux-Cloud-Hosts – inklusive einer SSH/HTTPS-Matrix für langfristige Planung.

Schritt 3: Default-Policy setzen

Die empfohlene UFW-Baseline: alle eingehenden Verbindungen verweigern, alle ausgehenden erlauben. Ausgehend offen, damit der Server apt-Pakete laden, APIs aufrufen und DNS auflösen kann; eingehend nur die Ports, die Sie wirklich brauchen.

sudo ufw default deny incoming
                sudo ufw default allow outgoing

                # Regeln mit Nummern anzeigen (zum Löschen)
                sudo ufw status numbered

Bei Compliance-Anforderungen können Sie auch ausgehend einschränken: ufw default deny outgoing, dann gezielt allow out für DNS (53), HTTPS (443) usw. Für die meisten Web-/API-Server ist „ausgehend offen, eingehend nach Bedarf“ das beste Verhältnis aus Aufwand und Sicherheit.

Schritt 4: Dienstports öffnen

Regeln nach Ihren tatsächlichen Diensten hinzufügen. Typische Kombinationen:

# HTTP / HTTPS (Nginx, Caddy, Apache)
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp

                # Oder Dienstnamen-Kurzform
                sudo ufw allow 'Nginx Full'

                # Dev: Node oder andere Ports temporär
                sudo ufw allow 3000/tcp comment 'dev API'

                # Admin-Panel nur von bestimmter Quell-IP
                sudo ufw allow from 198.51.100.0/24 to any port 8080 proto tcp

Produktionstipp: Was über 443 per Reverse Proxy laufen kann, sollte 3000/8080 nicht direkt exponieren. In UFW nur 22 + 80 + 443 öffnen, Anwendung auf 127.0.0.1 binden, TLS-Terminierung über Nginx oder Caddy – die Angriffsfläche schrumpft sofort.

Schritt 5: Aktivieren und verifizieren

Nach dem Hinzufügen aller Regeln UFW aktivieren:

sudo ufw enable
                # Warnt vor möglicher SSH-Unterbrechung – mit y bestätigen

                sudo ufw status verbose
                sudo ufw status numbered

Von einem anderen Rechner testen: nc -zv your.server.ip 22 sollte open melden; nicht freigegebene Ports (z. B. 3306) sollten timeout oder refused liefern. Fällt SSH weg, sofort per Cloud-Konsole/VNC sudo ufw disable ausführen, fehlende Regel finden und neu starten.

Fortgeschritten: Rate-Limit, Löschen, Reihenfolge

UFW bietet mehr als allow – häufige Szenarien:

# Rate-Limit: SSH-Brute-Force (6 Versuche/30 Sek.)
                sudo ufw limit 22/tcp

                # Regel nach Nummer löschen (zuerst status numbered)
                sudo ufw delete 3

                # Bestimmte IP sperren
                sudo ufw deny from 192.0.2.100

                # Alle Regeln zurücksetzen (vorsichtig)
                sudo ufw reset

ufw limit nutzt intern iptables recent für Verbindungsraten – effektiv für SSH, ersetzt aber nicht Schlüssel-Login und deaktivierte Passwort-Auth. Regeln werden in Hinzufügereihenfolge abgearbeitet; spezifischere Regeln sollten weiter oben stehen. Wirkt ein allow nicht, prüfen Sie, ob ein späteres deny es überdeckt.

UFW mit Docker / Kubernetes

Hier wirkt UFW am leichtesten „konfiguriert, aber wirkungslos“. Docker fügt standardmäßig eigene iptables-Ketten ein und kann UFW-Regeln umgehen – Sie glauben, 3306 sei zu, der Container-Port ist trotzdem öffentlich erreichbar.

Lösungen (nach Empfehlung):

• Container nur an 127.0.0.1 binden – -p 127.0.0.1:3000:3000, nach außen per Host-Reverse-Proxy
• In docker-compose kein ports – internes Netz + Reverse Proxy
• Docker "iptables": false (Forwarding selbst verwalten – für Fortgeschrittene)
• Cloud-Security-Group als letztes Netz – filtert auch dann, wenn Docker UFW umgeht

Auf K8s-Knoten kommen Calico/Cilium NetworkPolicies dazu; UFW ergänzt auf Knotenebene. Für einzelnes VPS mit Docker Compose reicht meist Punkt eins (Loopback-Bindung).

Security Group und UFW zusammen

Beide Ebenen konfigurieren – und die Policy sollte übereinstimmen: Security Group erlaubt 22, UFW muss 22 allowen; Security Group blockiert 3306, UFW-allow hilft von außen nicht – aber kompromittierte Maschinen im internen Netz könnten scannen, daher UFW trotzdem deny.

Empfohlene Aufteilung:

• Security Group: grob, nur 22/80/443, Quell-IP ggf. auf Büro oder CDN
• UFW: fein, Dienst-Kommentare, SSH limit, bösartige IPs sperren
• fail2ban: dynamisch, liest Logs und sperrt automatisch

Nach Änderungen extern prüfen: nmap -p 22,80,443,3306 your.server.ip (nur eigene Server scannen!). Zeigt 3306 open, obwohl Sie keine DB exponieren wollten, sofort Docker-Bindung oder Listen-Adresse der App prüfen.

Troubleshooting: Dienst nach UFW-Aktivierung nicht erreichbar

In dieser Reihenfolge – die meisten Fälle sind in zehn Minuten geklärt:

• sudo ufw status verbose – greifen die Regeln? Stimmen Port und Protokoll (tcp/udp)?
• sudo ss -tlnp – lauscht die App auf 0.0.0.0 statt nur 127.0.0.1?
• Cloud-Security-Group eingehend synchron?
• Umgeht Docker UFW?
• Kurz sudo ufw disable zum Vergleich (danach wieder enable)

Scheitert nur eine Quell-IP, prüfen Sie deny from oder fail2ban. UFW-Logs sind standardmäßig knapp; bei Bedarf in /etc/ufw/ufw.conf LOGLEVEL=medium, dann sudo ufw reload, abgelehnte Pakete in /var/log/ufw.log.

Go-Live-Checkliste (zum Kopieren)

Nach Neuinstallation oder Reimage in dieser Reihenfolge:

sudo apt install ufw -y
                sudo ufw default deny incoming
                sudo ufw default allow outgoing
                sudo ufw allow 22/tcp comment 'SSH'      # oder Ihr Custom-Port
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp
                sudo ufw limit 22/tcp                    # optional: SSH Rate-Limit
                sudo ufw enable
                sudo ufw status verbose

Nicht vergessen: SSH-Schlüssel, root-Login per Passwort aus, regelmäßige Updates via unattended-upgrades. Die Firewall ist Grenze, kein Allheilmittel – aber sie hält den Großteil automatisierter Scans draußen, während Sie tiefergehende Härtung vornehmen.