UFW sans perdre l’accès SSH

Objectifs des règles UFW

Accès public :       autoriser 80/tcp et 443/tcp ; pas d’autorisation générale de 22/tcp
tailscale0 :         autoriser 22/tcp
Entrées par défaut : deny
Sorties par défaut : allow

Sous Linux, Tailscale utilise par défaut le mode on. Ses règles de pare-feu sont évaluées en premier et acceptent le trafic arrivant par tailscale0.

UFW est une interface simple pour netfilter. Ses règles autorisent ou refusent le trafic ; elles ne démarrent aucun service. Ouvrir le port 80 ne crée pas de site web.

Pourquoi procéder par étapes

Définir deny incoming puis activer UFW immédiatement peut couper les accès SSH actuels et futurs. Conservez deux chemins indépendants pendant cette opération :

• Une session SSH publique dont le fonctionnement est confirmé, laissée ouverte pour rétablir l’accès en cas de problème.
• Une session OpenSSH via Tailscale déjà vérifiée, qui deviendra l’accès d’administration habituel.

Le suivi des connexions peut maintenir une session SSH établie après la suppression d’une règle entrante. Cette session reste un recours, mais ne prouve pas qu’une nouvelle connexion fonctionnera.

Examiner l’état sans réinitialiser

[REMOTE: VPS]

sudo ufw status verbose
sudo ufw status numbered

N’exécutez pas ufw reset pour obtenir un état « propre ». Les règles existantes peuvent appartenir à une autre infrastructure, et leurs numéros changent au fil des ajouts et des suppressions.

Activer UFW dans un ordre sûr

Exécutez ces commandes dans la session Tailscale vérifiée, en gardant la session publique ouverte :

[REMOTE: VPS]

sudo ufw default deny incoming
sudo ufw default allow outgoing

# Conserver temporairement le SSH public
sudo ufw allow 22/tcp

# Futurs accès web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Accès SSH définitif
sudo ufw allow in on tailscale0 to any port 22 proto tcp

sudo ufw --force enable
sudo ufw status verbose
sudo ufw status numbered

Ouvrez ensuite de nouvelles sessions SSH, l’une par l’adresse publique et l’autre par Tailscale. Si les deux réussissent, UFW est actif et le chemin de secours reste utilisable.

Supprimer la règle générique du port 22

Relisez d’abord les règles. Lorsque la règle est identifiée sans ambiguïté, privilégiez une suppression reprenant sa définition d’origine : cela traite ensemble les règles génériques IPv4 et IPv6 correspondantes.

[REMOTE: VPS]

sudo ufw delete allow 22/tcp
sudo ufw status verbose
sudo ufw status numbered

Une suppression par numéro ne retire généralement que l’entrée IPv4 ou IPv6 désignée. Ne réutilisez pas un ancien numéro sans consulter la liste actuelle. Celle-ci doit encore contenir :

80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp on tailscale0       ALLOW IN    Anywhere

Effectuer les tests finaux depuis le client

[LOCAL: WSL2]

# Doit réussir
ssh -o ConnectTimeout=10 "$VPS_USER@$TAILSCALE_IPV4"

# La connexion doit expirer ou être refusée ; elle ne doit pas réussir
ssh -o ConnectionAttempts=1 -o ConnectTimeout=5 \
  "$VPS_USER@$VPS_PUBLIC_IPV4"

Il faut que la connexion Tailscale réussisse et que la connexion par l’adresse publique échoue pour valider ces deux chemins SSH. Fermez seulement ensuite l’ancienne session publique conservée pour le dépannage.

L’exception Docker

Les ports de conteneurs publiés par Docker peuvent contourner les règles UFW ordinaires. Si un futur fichier Compose contient :

ports:
  - "8080:8080"

Le seul résultat de ufw status ne permet pas d’affirmer que le port 8080 n’est pas exposé. Lors d’un déploiement, examinez les ports de Compose, les adresses d’écoute et docker ps, puis les règles correspondant au backend de pare-feu réellement configuré dans Docker. DOCKER-USER s’applique au backend iptables ; le backend nftables natif de Docker ne possède pas de chaîne DOCKER-USER. Ne changez pas de backend et ne désactivez pas la gestion du pare-feu par Docker pour aller plus vite : ces deux actions peuvent casser le réseau ou modifier l’exposition des ports.

Principes de rétablissement de l’accès

Si une nouvelle connexion SSH par Tailscale échoue après la suppression de la règle générique du port 22 :

1. Gardez la session SSH encore ouverte.
2. Depuis cette session, rétablissez sudo ufw allow 22/tcp.
3. Vérifiez une nouvelle connexion SSH par clé publique via l’adresse publique.
4. Relevez l’état d’UFW, de tailscale0 et de sshd.
5. Cessez de restreindre l’accès jusqu’à ce que le chemin réseau soit compris.

Le but est de retrouver un accès vérifiable, plutôt que de réinitialiser tout le pare-feu dans l’urgence.

Mes lectures