ufw-Regelsatz reparieren und SSH-Zugriff wiederherstellen

Zuerst wieder Zugang herstellen

Wenn ufw Sie von Ihrem VPS ausgesperrt hat, führt der Weg zurück über die Provider-Konsole oder den Rettungsmodus. Sobald die blockierende Regel aktiv ist, gibt es keine Lösung über SSH. Der Kernel verwirft Ihr Paket, bevor sshd es überhaupt sieht. Deshalb können Sie sich nicht über das Netzwerk anmelden und den Fehler auch nicht darüber beheben. Öffnen Sie die Konsole im Control Panel Ihres Providers, melden Sie sich an der Eingabeaufforderung an und führen Sie einen Befehl aus.

sudo ufw disable

Sie sollten Firewall stopped and disabled on system startup sehen. Neue SSH-Verbindungen funktionieren innerhalb von ein bis zwei Sekunden wieder. Ihre Konfiguration geht nicht verloren: disable entfernt die Regeln aus dem Kernel und schreibt ENABLED=no in /etc/ufw/ufw.conf. Ihre Regeln bleiben in /etc/ufw/user.rules auf der Festplatte gespeichert und warten auf das nächste ufw enable.

Starten Sie das System nicht einfach neu. ufw startet beim Booten automatisch, sodass ENABLED=yes denselben Regelsatz erneut lädt, bevor das Netzwerk verfügbar ist. Ein Neustart ändert nichts an einer ufw-Sperre.

Die Konsole benötigt ein Passwort, das möglicherweise nicht gesetzt ist

Die Webkonsole (VNC oder seriell) ist eine direkt an die Maschine angeschlossene Tastatur. Sie ist kein Netzwerkpfad, daher kann keine Firewall-Regel den Zugriff blockieren. Sie benötigt jedoch eine lokale Anmeldung. Genau hier scheitern Konfigurationen, die ausschließlich Schlüssel verwenden: Wenn Sie nie ein Passwort für Ihren sudo-Benutzer gesetzt haben und die Anmeldung für root gesperrt ist, zeigt die Konsole eine Eingabeaufforderung an, die Sie nicht beantworten können. Setzen Sie dieses Passwort jetzt, solange Sie noch SSH verwenden: sudo passwd yourname. In den meisten Verwaltungsoberflächen können Sie auch das root-Passwort zurücksetzen. Das erzwingt normalerweise einen Reboot.

Wenn die Konsole nicht verwendbar ist, booten Sie das Rescue-System des Providers. Es führt ein separates Betriebssystem aus, während Ihre Festplatte nicht eingehängt ist. Dadurch können Sie ufw von außerhalb deaktivieren.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Führen Sie zuerst lsblk aus, da die Root-Partition nicht immer /dev/vda1 ist. Booten Sie anschließend wieder in das normale System. ufw bleibt deaktiviert, bis Sie es manuell aktivieren.

Die minimale Wiederherstellungssequenz

Arbeiten Sie in dieser Reihenfolge. Die ersten vier Schritte sind sicher. Der darauffolgende Schritt ist es nicht.

1. sudo ufw disable, um die Regeln zu entladen und den Zugriff wiederherzustellen.
2. sudo ufw show added, um die hinzugefügten Regeln in Form der Befehle auszugeben, mit denen sie hinzugefügt wurden. Das funktioniert, solange ufw inaktiv ist; ufw status funktioniert in diesem Zustand nicht.
3. sudo sshd -T | grep -i '^port', um zu bestätigen, an welchem Port sshd tatsächlich lauscht. Ohne Änderung gibt der Befehl port 22 aus.
4. sudo ufw allow 22/tcp mit Ihrem tatsächlichen Port, damit die nächste Aktivierung die Sperrung nicht erneut verursacht.
5. sudo ufw enable, nachdem Sie zuerst einen Rollback eingeplant haben. Dieser Vorgang wird weiter unten auf dieser Seite beschrieben.

Was ufw reset tatsächlich bewirkt

ufw reset ist der letzte Ausweg, nicht der erste Schritt. Der Befehl deaktiviert die Firewall, sichert jede Regeldatei und setzt die Standardrichtlinien auf eingehenden Datenverkehr ablehnen und ausgehenden Datenverkehr zulassen. Für jede Datei wird eine Sicherungszeile ausgegeben:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Nach einem Reset gibt es überhaupt keine Regeln zum Zulassen mehr. Führen Sie den Befehl daher an der Konsole und nicht über SSH aus. Fügen Sie die SSH-Regel hinzu, bevor Sie die Firewall wieder aktivieren. Die Sicherungen sind Klartextdateien. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 zeigt, welche Regeln zuvor vorhanden waren. Damit können Sie einen Regelsatz wiederherstellen, den Sie nicht verwerfen wollten.

Wo ufw seine Regeln speichert

Die Dateien zu lesen ist zuverlässiger, als sich auf das Gedächtnis zu verlassen. Fünf Pfade enthalten den vollständigen Zustand:

• /etc/ufw/user.rules und /etc/ufw/user6.rules: die Regeln, die Sie hinzugefügt haben, in der Reihenfolge ihrer Auswertung.
• /etc/ufw/before.rules und /etc/ufw/after.rules sowie die Varianten 6: das Framework, das ufw um Ihre Regeln legt, einschließlich der Regel zum Akzeptieren bereits bestehender Verbindungen und der Loopback-Regeln.
• /etc/default/ufw: die Standardrichtlinien und der Schalter IPV6.
• /etc/ufw/ufw.conf: ENABLED und die Protokollierungsstufe.
• /var/log/ufw.log: die blockierten Verbindungen, sobald die Protokollierung aktiviert ist.

ufw erstellt eine mit einem Zeitstempel versehene Kopie einer Datei, bevor es diese neu schreibt. Daher füllt sich ls /etc/ufw/ mit Namen wie user.rules.20260813_101500. Das ist Ihre Historie zum Rückgängigmachen. Sie sollten sie lesen, bevor Sie Änderungen zurücknehmen.

Um zu sehen, was im Kernel geladen ist, und nicht nur, was auf der Festplatte liegt, verwenden Sie sudo ufw show raw oder sudo iptables -S und sudo ip6tables -S. Unter Ubuntu 22.04 und 24.04 sind dies die von nft unterstützten Varianten. Daher gibt sudo nft list ruleset dieselben Regeln in der neueren Syntax aus.

Warum wurde meine SSH-Sitzung nach dem Aktivieren von ufw getrennt?

Die Standardregel für eingehenden Datenverkehr lautet deny. Wenn Sie ufw ohne eine Regel für Ihren SSH-Port aktivieren, werden alle neuen Verbindungen blockiert. ufw warnt davor: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Die Antwort y ohne vorhandene SSH-Allow-Regel ist die häufigste Ursache für alle Probleme auf dieser Seite.

Verwirrend ist die Verzögerung. /etc/ufw/before.rules akzeptiert Pakete mit dem Status ESTABLISHED,RELATED, bevor Ihre eigenen Regeln ausgewertet werden. Deshalb funktioniert die Sitzung, in der Sie den Befehl eingegeben haben, zunächst normal weiter. Die Aussperrung tritt erst bei der nächsten Verbindung auf. Das kann Stunden später sein. Zu diesem Zeitpunkt wirkt die Änderung der Firewall möglicherweise nicht mehr als Ursache. Öffnen Sie immer eine zweite SSH-Sitzung und bestätigen Sie, dass sie funktioniert, bevor Sie die erste Sitzung schließen.

Warum funktionierten apt und DNS nach einer Richtlinienänderung nicht mehr?

sudo ufw default deny outgoing blockiert ausgehende DNS-Abfragen (domain name system) und ausgehendes HTTP. Dadurch funktioniert die Namensauflösung nicht mehr, und Paketaktualisierungen schlagen fehl. apt update meldet Temporary failure resolving 'archive.ubuntu.com'. Eingehendes SSH funktioniert weiterhin, weil die Antworten darauf den Status ESTABLISHED haben und die Framework-Regeln passieren. Dadurch wirkt die Firewall unbeteiligt, obwohl sie die Ursache ist.

Wenn Sie eine Richtlinie für ausgehenden Datenverkehr mit Standardaktion deny verwenden möchten, geben Sie die Verbindungen frei, die der Rechner tatsächlich benötigt:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Ohne die letzte Regel geht die Systemuhr nach. Eine falsche Uhrzeit verhindert die Validierung von TLS-Zertifikaten (transport layer security). Daher schlägt curl wegen der Zeitstempel und nicht wegen der Ports fehl. Dieses Symptom tritt erst Tage nach der Änderung auf. Deshalb eignet sich deny outgoing für Systeme, die Sie überwachen, nicht für einen Rechner, den Sie einmalig einrichten.

Warum wird meine ufw-Regel nie angewendet?

ufw wertet benutzerdefinierte Regeln der Reihe nach aus und beendet die Verarbeitung beim ersten Treffer. Ein deny, das nach einem weit gefassten allow hinzugefügt wird, greift nie, weil die Allow-Regel das Paket bereits zugelassen hat. Lassen Sie die Reihenfolge mit Nummern ausgeben und fügen Sie die Regel an der benötigten Position ein.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp gibt die Regeln aus, die geschrieben würden, und nimmt keine Änderungen vor. Das ist die sichere Methode, eine Regel zu prüfen, bevor sie aktiviert wird.

Eine weitere Fehlerquelle sind die Anwendungsprofile. sudo ufw allow OpenSSH verwendet das Profil aus /etc/ufw/applications.d/openssh-server, und dieses Profil steht für Port 22. Wenn sshd auf 2222 lauscht, öffnet die Regel einen Port, den kein Dienst verwendet. Dadurch verlieren Sie möglicherweise den Zugriff, obwohl das Regelwerk korrekt aussieht. Verwenden Sie die Portnummer, nachdem Sie den Port geändert haben. Die restliche Syntax wird in den ufw-Grundlagen für eine VPS erläutert.

Warum erklären die IPv4-Regeln nicht, was ich sehe?

Weil die Hälfte des Datenverkehrs kein IPv4 verwendet. Ubuntu installiert IPV6=yes in /etc/default/ufw, und ufw führt anschließend in /etc/ufw/user6.rules einen parallelen v6-Regelsatz. Eine Regel mit einer IPv4-Adresse wie ufw allow from 203.0.113.10 to any port 22 erstellt überhaupt keine v6-Regel. Wenn Ihr VPS über einen AAAA-Record verfügt, bevorzugt Ihr Client IPv6 und die Verbindung läuft ab, während ufw status eine scheinbar korrekte Regel anzeigt. Testen Sie den Unterschied mit ssh -4 user@host und ssh -6 user@host. Wenn der erste Befehl funktioniert und der zweite nicht, liegt die Lücke im v6-Regelsatz.

Der umgekehrte Fall ist für die Sicherheit problematischer. Mit IPV6=no verwaltet ufw ip6tables überhaupt nicht, sodass die v6-Richtlinie beim Kernel-Standardwert ACCEPT bleibt. Ein Port, den Sie für geschlossen halten, antwortet über seine IPv6-Adresse, und kein ufw-Befehl wird ihn jemals anzeigen. Prüfen Sie dies mit sudo ip6tables -S und ss -tlnp. Eine vollständige Erläuterung finden Sie unter wie ufw IPv6-Ports verwaltet.

Warum ist ein Docker-Port offen, wenn ufw ihn blockiert?

Docker veröffentlicht einen Port, indem es DNAT-Regeln (Destination Network Address Translation) in die Tabelle nat schreibt und eine eigene Chain in FORWARD einfügt. Die Regeln von ufw befinden sich im Pfad INPUT. Der Datenverkehr zu einem Container wird weitergeleitet, statt an den Host zugestellt zu werden. Deshalb erreicht er die Chain mit Ihrer Blockierungsregel nicht. docker run -p 5432:5432 ist aus dem Internet erreichbar, obwohl ufw aktiv ist und sämtlichen Datenverkehr blockiert.

sudo iptables -t nat -S DOCKER

Die einfachste Lösung besteht darin, den Port an die Loopback-Schnittstelle zu binden: -p 127.0.0.1:5432:5432 bindet die Host-Seite an 127.0.0.1. Dadurch kann sie unabhängig von den ufw-Regeln nicht von außen erreicht werden. Docker-Ports an ufw vorbei veröffentlichen behandelt die Fälle, in denen der Dienst öffentlich erreichbar sein muss.

Planen Sie den Rollback, bevor Sie die Regel anwenden

Diese Vorgehensweise macht die Arbeit mit der Firewall sicher. Planen Sie vor jeder riskanten Änderung das Rückgängigmachen. Wenn die Änderung Sie aussperrt, stellt die Maschine den vorherigen Zustand nach fünf Minuten selbst wieder her. Sie müssen die Konsole nicht öffnen.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd gibt Running timer as unit: ufw-rollback.timer aus. Nehmen Sie jetzt Ihre Änderung vor. Wenn Sie anschließend noch eine neue SSH-Sitzung öffnen können, brechen Sie den Rollback ab:

sudo systemctl stop ufw-rollback.timer

Wenn Sie diese Sitzung nicht öffnen können, warten Sie. ufw wird automatisch beendet, und Ihr nächster Verbindungsversuch ist erfolgreich. Der klassische shutdown -r +5-Trick hilft bei ufw nicht, weil ufw beim Booten denselben Regelsatz erneut lädt.

Eine zweite Zugriffsmöglichkeit bereithalten

• Melden Sie sich einmal bei der Konsole des Anbieters an, bevor Sie sie benötigen, und bestätigen Sie, dass das Passwort funktioniert. Eine Konsole, die Sie nie getestet haben, ist keine Absicherung.
• Richten Sie einen zweiten sudo-Benutzer mit einem eigenen Schlüssel ein, damit eine beschädigte authorized_keys-Datei nicht zum vollständigen Verlust des Zugriffs führt.
• Prüfen Sie, ob Ihr Anbieter im Panel eine Netzwerk-Firewall betreibt, die von ufw getrennt ist. Sie blockiert dieselben Ports, und ufw status weist nie darauf hin.
• Machen Sie ufw allow from <your home address> nicht zu Ihrer einzigen SSH-Regel, wenn diese Adresse dynamisch ist. Ihr Anbieter ändert sie über Nacht, und Sie verlieren den Zugriff.

Am einfachsten lässt sich all das auf einem frisch eingerichteten Server erledigen, zusammen mit den anderen Einrichtungsschritten in den ersten zehn Minuten auf einem neuen VPS.

Refused oder timed out zeigt, auf welcher Ebene der Fehler auftritt

Connection refused bedeutet, dass ein Paket den Server erreicht hat und ein Dienst ein TCP-Reset zurückgesendet hat. Der Netzwerkpfad funktioniert. Daher ist sshd beendet oder lauscht an einem anderen Port. Eine Firewall ist selten die Ursache, weil ufw standardmäßig verwirft, anstatt die Verbindung zurückzuweisen.

Connection timed out bedeutet, dass überhaupt keine Antwort zurückkam. Das ist typisch für ein verworfenes Paket, etwa durch ufw, eine Firewall im Netzwerk des Providers oder eine falsche Adresse. Wenn Sie diese beiden Fehler richtig interpretieren, vermeiden Sie eine Stunde vergeblicher Fehlersuche. Der Unterschied zwischen „connection refused“ und „timed out“ behandelt die verbleibenden Fälle.

Protokollierung vor der nächsten Änderung aktivieren

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Ein blockiertes Paket sieht so aus:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 mit Ihrer eigenen Adresse in SRC= ist ein Beweis dafür, dass ufw die Verbindung blockiert, nicht das Netzwerk und nicht sshd. Bei einem minimalen Image ohne rsyslog gibt es keine /var/log/ufw.log. Dieselben Zeilen kommen dann aus sudo journalctl -k | grep UFW. ufw begrenzt die Rate seiner eigenen Protokollierungsregeln. Eine fehlende Zeile ist daher kein Beweis dafür, dass ein Paket zugelassen wurde.

Wenn Sie Regeln finden, die Sie nie hinzugefügt haben

Ein Ruleset, das sich selbst geändert hat, ist kein Firewall-Problem. Jemand mit root-Berechtigungen hat es geschrieben. Führen Sie sudo grep ufw /var/log/auth.log aus, um zu sehen, welche sudo-Befehle ausgeführt wurden und unter welchem Konto. Prüfen Sie anschließend mit last die Anmeldungen rund um diesen Zeitstempel. Wenn die Konten keiner Ihnen bekannten Person zugeordnet werden können, beenden Sie die Fehlersuche an der Firewall und arbeiten Sie stattdessen eine Checkliste für einen kompromittierten VPS durch. Eine Firewall auf einem System, das jemand anderes kontrolliert, erneut zu aktivieren, verdeckt das Problem nur.

Zusammenführen

Sobald die Ursache bekannt ist, aktivieren Sie ufw wieder so, dass sich die Sperrung nicht wiederholen kann. Erlauben Sie den tatsächlich verwendeten SSH-Port, planen Sie den Rollback, aktivieren Sie ufw und öffnen Sie anschließend in einem anderen Terminal eine vollständig neue SSH-Sitzung. Prüfen Sie, ob die Verbindung hergestellt wird. Erst wenn diese neue Sitzung aktiv ist, dürfen Sie die bisher verwendete Sitzung schließen. Lassen Sie die Protokollierung einen Tag lang aktiviert. Anhand des Protokolls erkennen Sie deutlich schneller, welche Freigabe fehlt, als beim Lesen von user.rules.

FAQ

Löscht ufw disable meine Regeln?

Nein. disable entfernt den Regelsatz aus dem Kernel und schreibt ENABLED=no in /etc/ufw/ufw.conf. Ihre Regeln bleiben in /etc/ufw/user.rules und /etc/ufw/user6.rules erhalten, und sudo ufw show added listet sie auf, während die Firewall inaktiv ist. ufw reset ist der Befehl, der sie löscht. Zuvor wird jede Datei gesichert. Dabei wird eine Zeile wie Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' ausgegeben.

Macht ein Neustart meines VPS eine ufw-Sperre rückgängig?

Nein. ufw wird beim Booten aus ENABLED=yes in /etc/ufw/ufw.conf gestartet. Deshalb werden dieselben Regeln geladen, bevor das Netzwerk verfügbar ist, und Sie werden erneut ausgesperrt. Ein Neustart hilft erst, nachdem Sie ufw deaktiviert haben, oder nachdem Sie diese Datei im Rettungsmodus bei eingebundenem Datenträger bearbeitet haben. Verwenden Sie die Konsole des Providers und führen Sie dort sudo ufw disable aus.

Warum ist mein Docker-Container erreichbar, obwohl ufw den Port verweigert?

Docker schreibt für jeden veröffentlichten Port eigene DNAT- und FORWARD-Regeln. Dieser Datenverkehr wird an den Container weitergeleitet und nicht an den Host zugestellt. Deshalb durchläuft er nicht die INPUT-Kette, in der Ihre ufw-Verweigerungsregel liegt. Veröffentlichen Sie den Port mit -p 127.0.0.1:5432:5432 nur auf dem Loopback-Interface, wenn er ausschließlich für den Host bestimmt ist. Prüfen Sie mit sudo iptables -t nat -S DOCKER, welche Regeln Docker eingerichtet hat.

Ich habe kein Konsolenpasswort und keinen Rettungsmodus. Welche Möglichkeiten habe ich?

Die verbleibenden Möglichkeiten hängen von Ihrem Provider ab: ein Passwort-Reset über das Control Panel, bei dem der Server normalerweise neu gestartet wird, oder das Einbinden des Datenträgers in eine andere Instanz, damit Sie /etc/ufw/ufw.conf von dort aus bearbeiten können. Fragen Sie den Support, bevor Sie den Server neu aufsetzen, weil dabei die darauf gespeicherten Daten gelöscht werden. Sobald Sie wieder Zugriff haben, führen Sie sudo passwd yourname aus und testen Sie die Anmeldung an der Konsole einmal. So kostet Sie die nächste Sperre nur zwei Minuten.