UFW-App-Profil fehlt? Es beschreibt Ports, nicht Dienste

UFW meldet, dass es kein zu OpenSSH passendes Profil findet, und die Ursachensuche führt geradewegs zum SSH-Server. Das ist die falsche Richtung: Die Meldung betrifft eine benannte Firewall-Definition und sagt nichts darüber, ob sshd installiert ist, läuft oder lauscht. Ein UFW-App-Profil ist eine Liste von Ports und Protokollen mit einer Bezeichnung. Die Definition zu lesen kostet einen Befehl und beendet die Untersuchung meist.

Schritt 1: Liste die Namen auf, die UFW wirklich kennt

Frag die Firewall, welche Namen sie hat, bevor du sie bittest, einen davon zu erlauben. Die Liste stammt aus den auf dieser Maschine installierten Profilen, ein fehlender Name ist also eine Tatsache über dieses System und nicht über die Software, die du schützen wolltest. Ist der Name vorhanden, kam der Fehler von einem Tippfehler oder einem veralteten Alias in deiner Shell-Historie.

ufw app list
ufw app info OpenSSH

Die Liste ist bei einer Standardinstallation kurz, und die Namen sind keine Paketnamen. Ein Profil namens OpenSSH kann fehlen, während das Paket openssh-server installiert ist, und umgekehrt ist es auch möglich. Verwende den exakten Namen, den die Liste ausgibt; ein VPN-Profilname oder ein Desktop-Starter mit ähnlicher Schreibweise ist kein UFW-App-Profil. Fehlt der gewünschte Name, ist das der Befund, und der nächste Schritt ist zu prüfen, was ihn liefern sollte.

Schritt 2: Lies die Definition, nicht die Bezeichnung

Ein Profil ist eine Datei im INI-Stil unter /etc/ufw/applications.d mit Name, Titel, Beschreibung und einem Ports-Feld. Das Ports-Feld kann mehrere Ports und Transporte auflisten, die Bezeichnung verrät dir also weniger als die Definition. Das UFW-Handbuch dokumentiert diese Felder und den Vorgang zum Aktualisieren von Anwendungen. Lies die Datei, statt anzunehmen, der Name meine einen vertrauten Port.

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

Eine Definition mit 22/tcp beschreibt TCP-Port 22 und sonst nichts. Sie beweist nicht, dass der Daemon auf dieser Maschine dort lauscht, und sie deckt keinen zweiten Port ab, den du später hinzugefügt hast. Läuft der Daemon anderswo, ist das Profil die falsche Erlaubnis, auch wenn sein Name zum Produkt passt. Vergleiche den Listener mit der Definition, bevor du eines von beiden erlaubst.

ss -ltnp 'sport = :22'

Halt an, wenn Definition und Listener nicht übereinstimmen. Ein Profil zu erlauben, das einen Port nennt, auf dem niemand lauscht, erzeugt eine Regel, die nach Fortschritt aussieht und nichts schützt.

Schritt 3: Trenne das Profil vom laufenden Dienst

Ein benanntes Profil zu erlauben installiert, startet oder konfiguriert den Dienst nicht, und ein laufender Dienst braucht kein paketiertes Profil, um erreichbar zu sein. Das sind getrennte Entscheidungen in der Hand verschiedener Werkzeuge: Paketverwaltung, Dienstverwaltung und Firewall. Sie als eines zu behandeln, ist der Weg, auf dem Leute einen unerwünschten Server installieren, damit ein symbolischer Name auftaucht.

Bei einem VPN-Server geht die Trennung weiter, nachdem der äußere Listener erlaubt ist. Die Erlaubnis für den Port des verschlüsselten Transports aktiviert kein Kernel-Forwarding, fügt keine NAT-Regel hinzu und gewährt Tunnelbenutzern keinen Zugang zu einem LAN. Jedes davon ist eine eigene Richtlinie mit eigener Prüfung. Ein nach dem VPN-Produkt benanntes Profil beschreibt nur die Ports, die es auflistet, und der Rest der Serverkonfiguration bleibt dir zum Schreiben.

Fehlt das Profil und brauchst du eines, sind eine geprüfte explizite Portregel oder ein lokales Profil unter applications.d beides legitim. Ein Paket zu installieren, das du nicht wolltest, nicht.

Schritt 4: Sichere dir einen Rückweg, bevor du die Firewall neu lädst

Bevor du eine Regel änderst, bestätige, dass du einen zweiten Weg in die Maschine hast: eine Konsole, eine Out-of-Band-Adresse oder ein geplantes Zurückrollen. Lies dann das Regelwerk und die Standardrichtlinie, denn ein Standard-Deny ohne SSH-Regel ist der klassische Weg, sich beim Testen auszusperren. Ändere jeweils eine Regel und lies die Bestätigung, die UFW ausgibt. Eine gespeicherte Regel, eine aktive Regel und ein erreichbarer Dienst sind drei verschiedene Beobachtungen.

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

Teste nach der Änderung die erlaubte Verbindung und einen Weg, der weiterhin abgelehnt werden sollte. Der Ablehnungstest zählt so viel wie der Erlaubnistest, denn eine breitere Regel als beabsichtigt besteht den ersten Test und scheitert am zweiten. Notiere den Profilnamen, die enthaltenen Ports und den Listener, gegen den du geprüft hast.

Die Checkliste endet, wenn der Name existiert oder bewusst ersetzt ist, die Definition zum echten Listener passt, der Dienst getrennt verwaltet wird und du sowohl einen erlaubten als auch einen abgelehnten Weg getestet hast, mit einem Wiederherstellungsweg zur Hand. Ein Name in der Liste ist nichts davon.