Profil d'application UFW absent ? Il décrit des ports, pas des services

UFW indique qu'il ne trouve aucun profil correspondant à OpenSSH, et la recherche de la cause mène tout droit au serveur SSH. C'est la mauvaise direction : le message porte sur une définition de pare-feu nommée et ne dit rien sur le fait que sshd soit installé, en cours d'exécution ou à l'écoute. Un profil d'application UFW est une liste de ports et de protocoles portant une étiquette. Lire la définition prend une commande et termine généralement l'enquête.

Étape 1 : listez les noms que UFW connaît vraiment

Demandez au pare-feu quels noms il possède avant de lui demander d'en autoriser un. La liste vient des profils installés sur cette machine, donc un nom manquant est un fait sur ce système, pas sur le logiciel que vous cherchiez à protéger. Si le nom est présent, l'erreur vient d'une faute de frappe ou d'un alias obsolète dans l'historique de votre shell.

ufw app list
ufw app info OpenSSH

La liste est courte sur une installation par défaut, et les noms ne sont pas des noms de paquets. Un profil nommé OpenSSH peut manquer alors que le paquet openssh-server est installé, et l'inverse est aussi possible. Utilisez le nom exact affiché par la liste ; un nom de profil VPN ou un lanceur de bureau avec une orthographe similaire n'est pas un profil d'application UFW. Si le nom souhaité manque, c'est là le constat, et l'étape suivante consiste à voir ce qui devrait le fournir.

Étape 2 : lisez la définition, pas l'étiquette

Un profil est un fichier de style INI sous /etc/ufw/applications.d, avec un nom, un titre, une description et un champ de ports. Le champ de ports peut lister plusieurs ports et transports, donc l'étiquette en dit moins que la définition. Le manuel d'UFW documente ces champs et l'opération de mise à jour des applications. Lisez le fichier au lieu de supposer que le nom désigne un port familier.

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

Une définition contenant 22/tcp décrit le port TCP 22 et rien d'autre. Elle ne prouve pas que le démon de cette machine écoute là, et elle ne couvre pas un second port ajouté plus tard. Si le démon tourne ailleurs, le profil est la mauvaise autorisation même si son nom correspond au produit. Comparez l'écouteur avec la définition avant d'autoriser l'un ou l'autre.

ss -ltnp 'sport = :22'

Arrêtez-vous si la définition et l'écouteur ne concordent pas. Autoriser un profil qui nomme un port où personne n'écoute crée une règle qui ressemble à un progrès et ne protège rien.

Étape 3 : séparez le profil du service en cours d'exécution

Autoriser un profil nommé n'installe, ne démarre ni ne configure le service, et un service en cours d'exécution n'a pas besoin d'un profil empaqueté pour être joignable. Ce sont des décisions distinctes, détenues par des outils différents : le gestionnaire de paquets, le gestionnaire de services et le pare-feu. Les traiter comme une seule est la façon dont les gens installent un serveur non désiré pour faire apparaître un nom symbolique.

Pour un serveur VPN, la séparation continue une fois l'écouteur externe autorisé. L'autorisation du port du transport chiffré n'active pas le transfert dans le noyau, n'ajoute pas de règle NAT et ne donne pas aux utilisateurs du tunnel l'accès à un LAN. Chacun de ces points est une politique distincte avec sa propre revue. Un profil nommé d'après le produit VPN ne décrit que les ports qu'il liste, et le reste de la configuration du serveur reste à écrire par vous.

Si le profil manque et que vous en avez besoin, une règle de port explicite revue ou un profil local sous applications.d sont tous deux légitimes. Installer un paquet dont vous ne vouliez pas ne l'est pas.

Étape 4 : gardez une voie de retour avant de recharger le pare-feu

Avant toute modification de règle, confirmez que vous avez une seconde voie vers la machine : une console, une adresse hors bande ou un retour planifié. Lisez ensuite le jeu de règles et la politique par défaut, car un refus par défaut sans règle SSH est la façon classique de s'enfermer dehors pendant un test. Changez une règle à la fois et lisez la confirmation qu'UFW imprime. Une règle enregistrée, une règle active et un service joignable sont trois observations différentes.

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

Après le changement, testez la connexion autorisée et une voie qui devrait rester refusée. Le test de refus compte autant que celui d'autorisation, car une règle plus large que prévu passe le premier test et échoue au second. Notez le nom du profil, les ports qu'il contenait et l'écouteur par rapport auquel vous avez vérifié.

La liste de contrôle se termine lorsque le nom existe ou est délibérément remplacé, que la définition correspond à l'écouteur réel, que le service est géré séparément et que vous avez testé une voie autorisée et une voie refusée avec une route de récupération en main. Un nom dans la liste n'est rien de tout cela.