UFW : configurer le pare-feu sans perdre SSH

Sur un serveur distant, configurez UFW sans couper votre accès : identifiez le vrai port SSH, autorisez-le, définissez les politiques par défaut, ouvrez seulement les services nécessaires, puis activez le pare-feu. Vérifiez ensuite IPv4, IPv6, journaux et règles Docker depuis une seconde session.

Faire l’inventaire avant de toucher au pare-feu

UFW simplifie les règles netfilter d’un pare-feu hôte. Il ne devine ni les services nécessaires ni le chemin réel des paquets. Commencez par observer ce qui écoute et ce qui doit rester joignable.

sudo ufw status verbose
sudo sshd -T | grep '^port '
sudo ss -lntup

La commande sshd -T affiche la configuration effective, y compris les fichiers inclus. Elle est plus fiable qu’une recherche limitée au fichier principal. Comparez ensuite le port affiché avec les sockets en écoute.

Notez dans l’inventaire :

• le port et les adresses d’écoute de SSH ;
• les services publics réellement attendus ;
• les interfaces et familles IP actives ;
• les ports publiés par un moteur de conteneurs.

Pour IPv6, vérifiez à la fois l’adresse du serveur et la configuration UFW :

ip -6 address show scope global
grep '^IPV6=' /etc/default/ufw

Une adresse IPv6 publique est une surface d’entrée distincte. Avec IPV6=yes, les règles génériques UFW s’appliquent aux deux familles. Ne testez pas uniquement l’adresse IPv4 si le serveur répond aussi en IPv6.

Autoriser SSH avant d’activer UFW

Sur une machine distante, l’ordre n’est pas un détail. Conservez la session actuelle ouverte et prévoyez la console de secours du fournisseur si elle existe.

Si SSH écoute sur le port déclaré par le profil OpenSSH, inspectez d’abord ce profil :

sudo ufw app info OpenSSH
sudo ufw allow OpenSSH

Si SSH utilise un port personnalisé, autorisez ce port explicitement. Exemple avec un port fictif à remplacer par la valeur retournée par sshd -T :

sudo ufw allow 2222/tcp comment 'SSH administration'
sudo ufw status numbered

N’utilisez pas OpenSSH par habitude si le profil annonce un autre port. Une règle correcte sur le mauvais port laisse le serveur inaccessible dès l’activation.

Poser des politiques par défaut explicites

Une installation UFW part normalement sur des entrées et du trafic routé refusés, avec les sorties autorisées. Écrivez néanmoins les choix attendus : cela rend la procédure reproductible et évite de dépendre d’un ancien état.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw default deny routed

Une politique sortante permissive n’est pas une obligation. Elle convient à une base simple, mais une machine très cloisonnée peut demander une liste de destinations. Cette conception dépasse vite l’usage confortable de l’interface UFW et mérite alors un jeu de règles documenté plus fin.

Ouvrir uniquement les services utiles

Pour un serveur web classique, les règles explicites restent faciles à relire :

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

Les profils applicatifs peuvent regrouper ports et protocoles. Listez-les et inspectez leur contenu avant de les autoriser :

sudo ufw app list
sudo ufw app info 'Nginx Full'

Un profil installé n’est pas une recommandation. Il décrit une ouverture technique, parfois plus large que le service réellement utilisé. Autorisez un besoin observé, pas un nom rassurant.

Pour restreindre l’administration à une adresse ou à un réseau connu :

sudo ufw allow proto tcp from 203.0.113.10 to any port 2222 \
  comment 'SSH bureau'

Cette règle n’est sûre que si l’adresse source est stable et si un chemin de secours existe. Une connexion mobile, un VPN indisponible ou un changement d’adresse peut sinon produire le même verrouillage qu’un port oublié.

Activer sans fermer la porte derrière soi

Relisez les règles avant l’activation :

sudo ufw status numbered
sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status verbose

Le mode dry-run montre les changements calculés, mais ne remplace pas un test réseau. Gardez la première session ouverte, lancez une seconde connexion SSH depuis un autre terminal, puis vérifiez les services autorisés depuis l’extérieur.

Ne fermez la session initiale qu’après le second accès réussi. Demandez le plan de panne : console du fournisseur, commande de désactivation et règle SSH correcte doivent être connus avant la bascule.

Sur un VPS, le pare-feu du fournisseur peut ajouter une autre couche. Un échec peut venir de UFW, du pare-feu réseau, du service qui n’écoute pas ou d’une route. Testez chaque couche séparément.

Lire l’état, les journaux et l’ordre des règles

UFW affiche ses règles gérées et leurs numéros :

sudo ufw status verbose
sudo ufw status numbered
sudo ufw show raw

status verbose résume politiques et règles UFW. show raw aide lorsque des règles de framework ou d’autres outils modifient le résultat. Il reste nécessaire de connaître le backend réellement utilisé sur la version installée.

Activez une journalisation modérée pendant la validation :

sudo ufw logging low
sudo journalctl -k --grep='UFW' --since '15 minutes ago'

Les niveaux élevés peuvent produire beaucoup de données sur un serveur exposé. Un journal utile doit avoir une rotation, une durée de conservation et une question précise. Coupez ou réduisez le niveau après le diagnostic.

Supprimer une règle sans viser la mauvaise

La suppression numérotée est pratique lorsque deux règles se ressemblent :

sudo ufw status numbered
sudo ufw delete 4
sudo ufw status numbered

Remplacez le numéro après lecture de la liste courante. Les numéros changent après une suppression. Avec IPv6 actif, une autorisation générique peut apparaître sous des entrées IPv4 et IPv6 distinctes ; supprimer un numéro n’efface que l’entrée visée.

Évitez ufw reset sur un serveur distant sans inventaire ni accès de secours. Cette commande désactive et remet UFW à son état initial ; ce n’est pas un bouton d’annulation ciblé.

Ne pas promettre que UFW protège les ports Docker

Docker crée ses propres règles pour les réseaux bridge et la publication de ports. Sa documentation avertit que le trafic d’un port publié peut être détourné avant les chaînes INPUT et OUTPUT utilisées par UFW. Une politique deny incoming ne garantit donc pas qu’un conteneur publié reste inaccessible.

docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ufw show raw

Testez chaque port publié depuis une machine externe. Lier un port à l’adresse de boucle, le placer derrière un proxy, ou filtrer dans la chaîne prévue par Docker sont des choix distincts. Ne désactivez pas les règles Docker au hasard : la documentation indique que cela risque de casser le réseau des conteneurs.