Configurer un pare-feu avec UFW

UFW (Uncomplicated Firewall) est un frontend en ligne de commande pour nftables/iptables. Il est installé par défaut sur Ubuntu (désactivé au démarrage), disponible via apt sur Debian, et conçu pour rendre la configuration d'un pare-feu hôte accessible sans apprendre la syntaxe de iptables. C'est la bonne porte d'entrée pour un serveur Debian/Ubuntu autonome. Dans ce guide, vous posez une politique par défaut stricte, ouvrez les flux utiles, validez l'état du pare-feu, et vous équipez d'un plan de rollback pour ne jamais vous couper de votre propre serveur.

Ce que vous allez apprendre

• Installer UFW sur Debian/Ubuntu et comprendre quand il n'est pas disponible ailleurs
• Autoriser SSH avant toute activation pour éviter le lockout
• Poser une politique par défaut (deny incoming, allow outgoing) et l'activer
• Ajouter des règles allow, deny, limit par service ou par port
• Vérifier l'état et le numéro de chaque règle avec ufw status verbose / numbered
• Revenir en arrière proprement en cas de mauvaise règle

Dans quel contexte ?

UFW est fait pour le pare-feu hôte d'un serveur ou d'un poste Linux. On l'utilise quand :

• on est sur Ubuntu ou Debian et qu'on veut un pare-feu simple, auditable rapidement
• on veut une syntaxe lisible (sudo ufw allow 22/tcp) plutôt que des chaînes iptables
• on met en place une première couche de filtrage avant d'envisager nftables direct ou firewalld

Si vous êtes sur RHEL, Fedora, CentOS Stream ou Rocky, la valeur par défaut est Firewalld — UFW n'y est pas packagé par défaut et le mélanger avec Firewalld crée des conflits. Sur ces systèmes, restez sur Firewalld.

Prérequis

• Un serveur Debian 12 ou Ubuntu 24.04 LTS
• Un utilisateur avec droits sudo
• Un accès SSH par clé déjà configuré — si vous utilisez SSH par mot de passe, lisez d'abord Clés SSH
• Un moyen d'accès de secours (console physique, console cloud provider, série…) en cas de lockout

Risque de lockout

UFW peut vous couper votre connexion SSH si vous activez une politique deny incoming avant d'avoir autorisé le port 22. Ayez toujours un plan B : console cloud (AWS EC2 Instance Connect, Hetzner console, OVH IPMI, KVM/VNC chez Proxmox…) ou accès physique.

Installer UFW

Debian 12

sudo apt update
sudo apt install -y ufw

Ubuntu 24.04

UFW est normalement déjà présent :

dpkg -l ufw

Si absent :

sudo apt update
sudo apt install -y ufw

RHEL / Fedora

UFW n'est pas la solution recommandée ici. Préférez Firewalld qui est packagé par défaut et intégré à l'écosystème Red Hat. Si vous voulez quand même UFW, il est disponible via EPEL mais le mixage avec Firewalld est à éviter.

Vérifiez que la commande répond :

sudo ufw status

Sortie attendue après installation, avant activation :

Status: inactive

Autoriser SSH avant toute activation

C'est l'étape la plus importante du guide. Avant d'activer UFW, créez la règle qui garde votre session SSH vivante.

1. Autoriser SSH explicitement

   sudo ufw allow 22/tcp

   Si votre SSH écoute sur un port non standard :

   sudo ufw allow 2222/tcp comment 'SSH admin'

2. Rate-limiter SSH pour freiner les attaques par force brute

   sudo ufw limit 22/tcp

   limit accepte jusqu'à 6 connexions par source par 30 s avant de bloquer l'IP. Utile contre les bots ; pas un substitut à des clés SSH et à un durcissement SSH complet si vous exposez SSH sur Internet (voir Durcir SSH).

3. Relire la règle

   sudo ufw show added

   Doit afficher ufw limit 22/tcp ou ufw allow 22/tcp selon votre choix.

limit vs allow

Utilisez limit pour SSH exposé sur Internet, allow pour SSH en LAN ou via VPN. Les deux ouvrent le port ; seul limit ajoute le ralentissement.

Règles en file d'attente

Tant qu'UFW n'est pas enable, les commandes ufw allow/limit/deny ne sont pas encore actives — elles sont ajoutées à une file d'attente visible avec sudo ufw show added. Elles seront toutes appliquées d'un coup lors de l'étape suivante.

Activer UFW avec une politique stricte

Par défaut, UFW applique :

• deny incoming — tout trafic entrant non explicitement autorisé est refusé
• allow outgoing — tout trafic sortant est autorisé

C'est la bonne baseline. Activez :

sudo ufw enable

Vous verrez un avertissement puis la règle d'activation. Vérifiez immédiatement :

sudo ufw status verbose

Sortie attendue :

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT       Anywhere
22/tcp (v6)                LIMIT       Anywhere (v6)

Votre connexion SSH courante doit toujours fonctionner. Si elle tombe, utilisez votre accès de secours et exécutez sudo ufw disable.

Ouvrir les services utiles

UFW connaît les noms de services via /etc/services. Les deux syntaxes ci-dessous sont équivalentes :

# par nom de service
sudo ufw allow http

# par numéro de port
sudo ufw allow 80/tcp

Quelques cas courants :

# Serveur web
sudo ufw allow http
sudo ufw allow https

# Serveur mail (SMTP + IMAP chiffrés)
sudo ufw allow 587/tcp comment 'SMTP submission'
sudo ufw allow 993/tcp comment 'IMAPS'

# Limiter un service à un réseau interne
sudo ufw allow from 192.168.10.0/24 to any port 3306 proto tcp comment 'MySQL LAN only'

# Bloquer une IP qui martèle un service public (ex: HTTP exposé)
# Inutile sur un port déjà bloqué par deny-by-default
sudo ufw deny from 203.0.113.42 to any port 80 proto tcp

Toujours vérifier après chaque lot de règles :

sudo ufw status numbered

Le numéro permet de supprimer une règle précise :

sudo ufw delete 3

Vérifier et lire les règles

Trois commandes de vérification à garder sous la main :

Besoin	Commande
État + politique par défaut + règles	sudo ufw status verbose
Règles avec numéro (pour suppression)	sudo ufw status numbered
Règles en attente (avant ufw enable)	sudo ufw show added

Glissez pour voir

Pour inspecter le trafic bloqué, activez la journalisation :

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

Les entrées [UFW BLOCK] indiquent les paquets refusés ; utilisez-les pour diagnostiquer un service qui ne répond pas.

Bonnes pratiques

• Toujours autoriser SSH avant ufw enable — règle d'or.
• Préférer limit à allow sur SSH exposé sur Internet, complété par clé SSH uniquement.
• Commenter chaque règle avec comment '…' — la relecture dans 6 mois sera beaucoup plus facile.
• Scoper les règles au bon réseau (from 192.168.0.0/16 to any …) plutôt que d'ouvrir Anywhere par défaut.
• Ne pas mixer UFW et iptables/nftables à la main — UFW écrit ses propres chaînes, une modification manuelle crée des conflits silencieux.
• Tester la persistance : sudo systemctl reboot puis revérifier ufw status verbose. UFW est normalement activé au démarrage, mais une config cloud-init peut remettre l'état à inactive.

Sécurité et rollback

Avant de lancer ufw enable, ayez ces deux filets de secours :

1. Une deuxième session SSH ouverte sur le serveur (l'activation ne coupe pas les connexions établies, mais une règle ratée pourrait le faire sur la prochaine).
2. L'accès console configuré et testé (IPMI, KVM cloud, port série).

Rollback complet en cas de problème :

# Désactiver UFW (retour à l'état pré-activation)
sudo ufw disable

# Réinitialiser toutes les règles
sudo ufw reset

reset efface toutes les règles et désactive UFW. C'est radical, utilisez-le si vous êtes perdu. Après un reset, il faut refaire la procédure d'autorisation SSH avant un nouveau enable.

Dépannage rapide

Symptôme	Cause probable	Action
SSH coupé après ufw enable	Port SSH non autorisé ou règle trop restrictive	Accès console → sudo ufw disable, corriger, réessayer
Service accessible en local, pas depuis l'extérieur	Port non autorisé ou règle avec from trop étroite	sudo ufw status numbered ; ajuster ou ajouter allow <port>/tcp
ufw status vide après reboot	UFW désactivé au démarrage (Ubuntu cloud init)	sudo systemctl enable --now ufw + vérifier sudo ufw enable
Règles non visibles dans iptables -L	Normal : UFW utilise ses propres chaînes	Utiliser sudo iptables -L -n -v avec les chaînes UFW ou rester sur sudo ufw status
[UFW BLOCK] dans /var/log/ufw.log pour un service légitime	Service arrive sur une interface non autorisée	Ajouter allow in on <iface> ou élargir la règle

Glissez pour voir

À retenir

• UFW est un frontend simplifié de nftables/iptables, packagé par défaut sur Ubuntu et installable sur Debian.
• Autorisez SSH avant d'activer — c'est la seule erreur qui peut vous couper votre serveur.
• Utilisez limit pour SSH exposé sur Internet, allow pour un réseau interne.
• Politique par défaut recommandée : deny incoming, allow outgoing.
• sudo ufw status verbose et sudo ufw status numbered sont les deux commandes à mémoriser.
• Chaque règle peut recevoir un comment — utilisez-le systématiquement.
• Sur RHEL/Fedora/Rocky, préférez Firewalld ; ne mélangez pas les deux.
• ufw reset en dernier recours pour repartir d'une page blanche.

Prochaines étapes

Introduction aux pare-feux Comprendre les notions de politique par défaut, flux et ports avant de configurer UFW ou Firewalld.

Firewalld Équivalent UFW côté Red Hat/Fedora/Rocky, avec zones et services dynamiques.

Durcir SSH Compléter UFW avec un sshd configuré : clés uniquement, pas de root, fail2ban.

Serveur OpenSSH Configurer sshd pour LFCS : directives clés, validation avant reload, rollback.

×

📖 Voir la documentation →