Comment configurer un pare-feu UFW sur un serveur Linux en 6 étapes

Quels ports sont ouverts, en ce moment même, sur le serveur qui héberge votre site ou votre application métier ? Dans beaucoup de PME, la réponse honnête est « on ne sait pas trop ». Le serveur a été installé, des services ont été ajoutés au fil des projets, et personne n’a jamais dressé la liste de ce qui écoute vraiment sur le réseau. Un pare-feu répond exactement à cette question, à condition d’être configuré avec une intention claire.

Sur un serveur Ubuntu ou Debian, l’outil le plus direct s’appelle UFW. L’image classique est celle du garde posté à l’entrée d’une forteresse : il regarde qui se présente, laisse entrer ceux qui figurent sur la liste et refuse tous les autres. Ce tutoriel décrit la mise en place complète en six étapes : installer UFW et lire son état, autoriser SSH avant de l’activer, ouvrir les ports utiles, restreindre les règles à certaines machines, corriger ou effacer ce qui a été écrit, puis activer les journaux pour vérifier ce que le pare-feu refuse réellement. À la fin, on dispose d’un serveur qui n’expose que les ports décidés, d’une liste de règles lisible et d’une trace consultable en direct.

Étape 1 : installer UFW et regarder son état avant d’y toucher

Avant d’écrire la moindre règle, il faut savoir ce qu’un pare-feu filtre. Chaque service en fonctionnement sur le serveur écoute sur un port et attend qu’une connexion se présente : SSH sur le port 22, HTTP sur le 80, HTTPS sur le 443, MySQL sur le 3306, FTP sur le 21, DNS sur le 53. Autoriser un service revient donc à ouvrir un port, et fermer un port revient à rendre le service injoignable depuis l’extérieur.

L’installation elle-même tient en trois commandes.

sudo apt update
sudo apt install ufw -y
sudo ufw status

1. La mise à jour de la liste des paquets évite d’installer une version périmée.
2. L’installation se fait sans confirmation grâce à l’option -y. Sur beaucoup de serveurs Ubuntu, la réponse sera « ufw is already the newest version » : l’outil est déjà présent, simplement inactif.
3. La vérification d’état retourne Status: inactive. C’est le point de départ normal : UFW est installé mais ne filtre rien du tout.

Ce dernier détail mérite d’être souligné, parce qu’il piège régulièrement. La présence du paquet ne protège pas le serveur. Tant que le statut affiche « inactive », toutes les connexions passent, et l’audit de sécurité qui listera les ports ouverts ne verra aucune différence avec une machine sans pare-feu.

Étape 2 : autoriser SSH, puis seulement ensuite activer le pare-feu

Voici la règle qui explique tout le reste : par défaut, UFW refuse l’ensemble du trafic entrant et autorise l’ensemble du trafic sortant. Le serveur peut donc continuer à joindre Internet, mais plus personne ne peut le joindre. Que se passe-t-il si le pare-feu est activé alors qu’aucune règle n’autorise SSH ? La connexion administrative tombe dans le trafic entrant refusé, et sur une machine distante, on perd purement et simplement la main.

UFW connaît ce scénario et affiche un avertissement au moment de l’activation. L’ordre correct est donc le suivant.

sudo ufw allow 22
sudo ufw allow ssh
sudo ufw enable
sudo ufw status

1. La règle sur le port 22 ouvre la porte de l’administration. Le retour « Rules updated » puis « Rules updated (v6) » confirme qu’elle a été écrite deux fois, une fois pour IPv4 et une fois pour IPv6.
2. La variante par nom de service produit un résultat légèrement différent, sur lequel on revient juste après.
3. L’activation demande une confirmation : « Command may disrupt existing ssh connections. Proceed with operation (y|n) ? ». On répond y, et le pare-feu répond « Firewall is active and enabled on system startup ». Cette dernière mention compte : la configuration survivra au redémarrage.
4. Le statut affiche maintenant « Status: active » et un tableau à trois colonnes, To, Action et From.

Ce tableau révèle la nuance entre les deux commandes précédentes. La ligne 22 correspond à ufw allow 22 et ouvre le port pour TCP comme pour UDP. La ligne 22/tcp vient de ufw allow ssh : le pare-feu a reconnu le nom du service et n’a ouvert que le protocole dont SSH a besoin. Or SSH ne fonctionne qu’en TCP. Garder la règle nommée et supprimer l’autre ferme donc une porte inutile, sans rien casser. C’est une habitude qui prolonge naturellement le travail de durcissement d’un serveur Linux en production.

Étape 3 : n’ouvrir que les ports dont le serveur a réellement besoin

Une fois l’accès administratif sécurisé, on ouvre les services attendus, et eux seuls. UFW accepte trois façons de désigner ce qu’on autorise : le numéro de port, le nom du service, ou le nom d’une application déclarée.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow 1000:2000/tcp
sudo ufw allow 53/udp
sudo ufw status

1. Les noms http et https sont reconnus directement. Le statut montre que HTTP n’est ouvert qu’en TCP, alors que HTTPS apparaît en TCP et en UDP, ce dernier servant aux versions récentes du protocole.
2. Une plage de ports s’écrit avec deux points et exige la précision du protocole. Les deux bornes sont incluses : de 1000 à 2000, le port 1000 et le port 2000 font partie du lot.
3. Le suffixe /udp restreint la règle à un seul protocole, ce qui est le bon réflexe pour un service DNS.
4. Un contrôle du statut après chaque ajout évite les mauvaises surprises et permet de repérer les règles redondantes.

D’où viennent ces noms de services ? D’un fichier présent sur le système, que l’on peut consulter directement pour savoir à quel port correspond un nom donné.

cat /etc/services | grep "https"
cat /etc/services | grep "ssh"

La sortie associe chaque nom à son port et à son protocole. C’est là qu’on lit noir sur blanc que ssh vaut 22/tcp, que https couvre 443 en TCP et en UDP, ou encore que http-alt correspond au port 8080. Utile quand une application demande d’« ouvrir le port du service X » sans préciser lequel.

Dernière possibilité, plus pratique encore quand un logiciel a besoin de plusieurs ports : les profils d’application. La commande sudo ufw app list énumère ce qui est déclaré sur la machine, par exemple Apache, Apache Full, Apache Secure et OpenSSH. Autoriser sudo ufw allow 'Apache Full' ouvre alors d’un seul geste les ports 80 et 443 en TCP, et le statut affiche la règle sous le nom du profil plutôt que sous une liste de numéros. Pour comprendre le vocabulaire employé par ces outils, notre définition du pare-feu reprend les notions de base.

Étape 4 : restreindre une règle à une machine ou à un sous-réseau

Ouvrir un port pour la terre entière n’a de sens que pour un service public. Une base de données, une interface d’administration ou un partage interne méritent mieux : une règle qui nomme précisément la machine autorisée. UFW s’en charge avec le mot-clé from.

sudo ufw allow from 192.168.1.1
sudo ufw allow from 172.16.3.0/24
sudo ufw allow from 192.168.1.1 to any port 53
sudo ufw allow from 172.16.3.1 to any port 3306

1. La première forme autorise toutes les connexions provenant d’une seule adresse. Dans le statut, la colonne To indique « Anywhere » et la colonne From porte l’adresse.
2. La deuxième ouvre l’accès à un sous-réseau complet, ici toutes les machines dont l’adresse commence par 172.16.3, ce que traduit le suffixe /24 correspondant au masque 255.255.255.0. Pratique pour laisser entrer un parc de machines virtuelles sans les énumérer une à une.
3. La troisième combine origine et destination : cette machine, et seulement elle, peut joindre le port 53.
4. La quatrième applique le même principe à MySQL. Une seule adresse peut atteindre le port 3306, ce qui est exactement ce qu’on attend d’un serveur de base de données qui ne doit jamais être exposé au réseau entier.

Attention à la syntaxe : la partie to any port n’est pas décorative. Si elle est oubliée, UFW renvoie « ERROR: Wrong number of arguments » et n’écrit rien du tout. Autant vérifier le statut derrière chaque ajout.

L’inverse fonctionne de la même façon, avec deny. On peut refuser un service entier, bloquer une adresse qui se montre insistante, ou couper une communication sortante.

sudo ufw deny 21
sudo ufw deny from 192.168.1.200
sudo ufw deny out from 192.168.1.222

Le statut distingue alors clairement le sens de circulation : la colonne Action affiche DENY IN pour ce qui vient de l’extérieur et DENY OUT pour ce qui part du serveur, avec la mention (out) en bout de ligne. Cette capacité à fermer le trafic sortant est souvent négligée alors qu’elle limite beaucoup de dégâts après une compromission, dans le même esprit que la segmentation du réseau pour bloquer les ransomwares.

Étape 5 : corriger une règle, ou tout remettre à plat

Au bout de quelques semaines, la liste de règles ressemble rarement à ce qui était prévu. Des tests sont restés, des ports ont été ouverts « le temps de vérifier », et personne n’ose plus rien toucher. UFW propose deux méthodes de suppression, plus une remise à zéro complète.

La première méthode passe par les numéros de règles.

sudo ufw status numbered
sudo ufw delete 12

1. L’option numbered affiche la même liste que d’habitude, chaque ligne étant précédée de son numéro entre crochets.
2. La suppression demande confirmation et rappelle la règle concernée, par exemple « Deleting: deny out from 8.8.8.8 ». On relit avant de valider, c’est le moment ou jamais.
3. Point crucial : la numérotation se recalcule après chaque suppression. Enchaîner deux delete sans réafficher le statut revient à supprimer une règle au hasard. Il faut relancer ufw status numbered entre chaque opération.

La seconde méthode évite ce piège en désignant la règle par son énoncé, exactement comme elle a été créée.

sudo ufw delete allow 443
sudo ufw delete deny 21

Cette écriture supprime la règle IPv4 et son équivalent IPv6 d’un seul coup, ce qui évite d’avoir à traiter les doublons. Elle est plus lisible dans un script ou dans une procédure écrite, puisque la commande de suppression est le miroir exact de la commande de création.

Reste le cas où la configuration est devenue trop confuse pour être réparée. La remise à plat se fait en quatre commandes, dans cet ordre précis.

sudo ufw disable
sudo ufw reset
sudo ufw allow ssh
sudo ufw enable

Le reset sauvegarde les règles existantes dans des fichiers datés avant de les effacer, ce qui laisse une porte de sortie si une règle utile disparaît au passage. Et il ne faut surtout pas s’arrêter après la deuxième commande : une fois les règles effacées, plus rien n’autorise SSH. Réautoriser puis réactiver fait partie de la même séquence, à exécuter sans quitter la session en cours.

Étape 6 : activer les journaux et vérifier ce qui est vraiment bloqué

Un pare-feu bien réglé est silencieux, et c’est justement le problème. Comment savoir si une adresse tente de se connecter, ou si une règle bloque par erreur un service légitime ? En activant la journalisation, qui n’est pas en service par défaut.

sudo ufw logging on
sudo ufw logging medium
sudo journalctl -f | grep "UFW BLOCK"

1. La première commande démarre l’enregistrement au niveau le plus bas.
2. Le niveau se règle ensuite selon le détail souhaité, de low à medium puis high. Plus le niveau monte, plus le journal est verbeux : à réserver à une période de diagnostic, pas à un fonctionnement permanent.
3. Les traces partent dans le journal système. Le filtre sur UFW BLOCK isole les paquets refusés et l’option -f les affiche au fil de l’eau.

Chaque ligne se lit comme une petite fiche d’identité de la connexion refusée : l’interface d’entrée, l’adresse source dans SRC, l’adresse visée dans DST, le protocole, puis le port d’origine et le port de destination dans SPT et DPT. Un DPT=22 qui revient toutes les secondes depuis une adresse inconnue ne laisse pas beaucoup de place au doute.

Le test grandeur nature ne prend qu’une minute. On lance le suivi du journal sur le serveur, puis on tente une connexion SSH depuis un autre poste du réseau. Sans règle autorisant le port 22, la connexion n’aboutit pas et la tentative apparaît immédiatement dans les traces, avec l’adresse du poste et le port visé. À l’inverse, quand la journalisation tourne à un niveau élevé, le trafic autorisé apparaît lui aussi, sous la mention UFW AUDIT : de quoi vérifier qu’une règle fait bien ce qu’on croit.

Erreurs fréquentes avec UFW

Ce sont presque toujours les mêmes gestes qui font perdre du temps, ou l’accès au serveur.

• Activer le pare-feu avant d’autoriser SSH. Sur une machine distante, la session se coupe et il faut passer par la console du fournisseur pour reprendre la main. L’avertissement affiché par ufw enable mérite d’être lu jusqu’au bout.
• Laisser la règle « 22 » toute nue. Elle ouvre le port en TCP et en UDP alors que SSH n’utilise que TCP. La règle 22/tcp suffit, l’autre peut être supprimée.
• Oublier « to any port » dans une règle nominative. UFW répond « ERROR: Wrong number of arguments » et n’écrit rien : on croit la machine protégée alors que la règle n’existe pas.
• Enchaîner les suppressions par numéro. La numérotation change après chaque delete. Sans réafficher la liste, la deuxième suppression tombe sur une autre règle que celle visée.
• S’arrêter au milieu d’un reset. Une fois les règles effacées, plus rien n’autorise SSH tant que la commande d’autorisation et la réactivation n’ont pas été relancées.
• Croire que le pare-feu garde une trace par défaut. Tant que la journalisation n’est pas activée, aucune analyse n’est possible après coup : ni tentative d’intrusion, ni blocage involontaire.
• Oublier qu’un poste de travail ne se traite pas comme un serveur. Le pare-feu de Windows repose sur le même principe, entrant et sortant, par port ou par programme, mais il arrive avec de nombreuses règles entrantes déjà autorisées. Tout fermer d’un bloc peut empêcher la machine de dialoguer avec le domaine.