Configurer ufw sous Linux : pare-feu serveur et bases de nftables

Le pare-feu Linux décide quels paquets réseau laisser entrer sur le serveur et lesquels rejeter. C'est le noyau qui assure ce filtrage, via le sous-système netfilter, et plusieurs outils permettent de le piloter : les utilitaires bas niveau iptables et nftables, et la surcouche ufw (Uncomplicated Firewall). Sur la plupart des serveurs Ubuntu et Debian, configurer ufw prend cinq minutes : bloquer tout le trafic entrant, ouvrir SSH et les ports des services, puis activer. Vous trouverez ci-dessous la démarche pas à pas, les erreurs courantes et le minimum de nftables pour comprendre ce qui se passe en coulisses.

Fonctionnement du pare-feu sous Linux

Le filtrage des paquets est assuré par le noyau : c'est netfilter. Il fournit des points d'interception (hooks) : trafic entrant vers la machine elle-même, trafic sortant, et trafic en transit (forward). Les utilitaires en espace utilisateur se contentent d'inscrire des règles dans le noyau pour ces points.

Point important : utilisez un seul outil de gestion. Si vous modifiez les règles à la fois avec ufw et à la main avec iptables, elles se remplacent mutuellement et le résultat devient imprévisible.

Installation et vérification de ufw

Sur Ubuntu, ufw est généralement déjà installé mais désactivé. Sur Debian, il faut l'installer séparément :

$ sudo apt update
$ sudo apt install ufw
$ sudo ufw status
Status: inactive

Le statut inactive signifie que les règles ufw ne sont pas appliquées. Ne l'activez pas encore : commencez par autoriser SSH, sinon, sur un serveur distant, vous vous couperez vous-même l'accès.

Configuration pas à pas de ufw sur le serveur

Étape 1. Politiques par défaut

La politique par défaut définit le sort d'un paquet qu'aucune règle ne concerne. Pour un serveur, le schéma sûr consiste à interdire le trafic entrant et à autoriser le trafic sortant.

$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'

Les réponses à vos propres connexions sortantes passent automatiquement : ufw suit l'état des connexions (connection tracking), il n'est donc pas nécessaire d'ouvrir des ports pour les réponses.

Étape 2. Autoriser SSH

$ sudo ufw allow OpenSSH
Rules updated
Rules updated (v6)

OpenSSH est un profil d'application. Si SSH écoute sur un port non standard, autorisez-le explicitement : sudo ufw allow 2222/tcp. Pour vérifier le port réellement utilisé par sshd, lancez sudo ss -tlnp | grep sshd.

Étape 3. Ouvrir les ports des services

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

Précisez toujours le protocole : sans /tcp, ufw ouvre le port à la fois en TCP et en UDP, et une porte ouverte inutilement n'a aucun intérêt.

Étape 4. Activer le pare-feu

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

ufw démarre immédiatement et s'activera à chaque démarrage. Ne fermez pas votre session SSH actuelle : ouvrez-en une seconde et vérifiez que la connexion fonctionne.

Étape 5. Vérifier les règles

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

ufw crée lui-même les règles IPv6 si IPV6=yes est défini dans /etc/default/ufw (valeur par défaut).

Ouvrir un port avec ufw : toutes les syntaxes

La commande ufw allow accepte une forme courte et une forme complète. La forme courte suffit dans les cas habituels ; la forme complète sert lorsqu'il faut préciser la source, l'interface ou l'adresse de destination.

Différence entre deny et reject : deny rejette le paquet silencieusement, et le client attend jusqu'à l'expiration du délai ; reject renvoie une réponse indiquant que le port est fermé. Pour le trafic venant d'Internet, on choisit en général deny ; sur les réseaux internes, reject est plus pratique, car les clients voient tout de suite l'erreur.

Base de données accessible depuis un seul serveur

Cas fréquent : PostgreSQL ou MySQL ne doit pas être visible depuis Internet, mais l'application située sur un autre serveur doit pouvoir s'y connecter.

$ sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp
Rule added

Le port 5432 reste fermé pour tous les autres grâce à la politique deny incoming. Il est conseillé en complément de configurer le SGBD lui-même pour n'écouter que sur l'adresse interne : le pare-feu et la configuration du service se protègent mutuellement.

Profils d'applications

Les paquets peuvent déposer la description de leurs ports dans /etc/ufw/applications.d/. Liste et contenu des profils :

$ sudo ufw app list
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH
$ sudo ufw app info "Nginx Full"
Profile: Nginx Full
Title: Web Server (Nginx, HTTP + HTTPS)
Description: Small, but very powerful and efficient web server

Ports:
  80,443/tcp

Autoriser un profil : sudo ufw allow "Nginx Full". Les noms contenant des espaces doivent être entre guillemets. Vous pouvez décrire votre propre profil au format INI dans le même répertoire, puis l'appliquer avec sudo ufw app update nom.

Supprimer une règle ufw

Le moyen le plus fiable consiste à supprimer par numéro :

$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] OpenSSH (v6)               ALLOW IN    Anywhere (v6)
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

$ sudo ufw delete 2
Deleting:
 allow 80/tcp
Proceed with operation (y|n)? y
Rule deleted

Après une suppression, les numéros se décalent : relancez status numbered avant toute nouvelle suppression. Autre méthode : répéter la règle précédée de delete, par exemple sudo ufw delete allow 80/tcp ; cette commande supprime en même temps la variante IPv4 et la variante IPv6.

Ordre des règles et insertion en tête

ufw examine les règles de haut en bas, et la première correspondance s'applique. Une interdiction visant une adresse précise doit donc se trouver au-dessus de l'autorisation générale :

$ sudo ufw insert 1 deny from 198.51.100.23
Rule inserted

Si vous ajoutez le deny avec la commande habituelle, il se retrouve en fin de liste, après allow 443/tcp, et ne s'applique pas à ce port.

Protéger SSH contre le brute force : ufw limit

La règle limit autorise la connexion, mais bloque une adresse qui a ouvert 6 connexions ou plus en 30 secondes :

$ sudo ufw limit OpenSSH
Rule updated

Il s'agit d'une protection simple contre le test massif de mots de passe. Pour une protection sérieuse, ajoutez une connexion par clés uniquement et, si besoin, fail2ban, qui sait bannir des adresses via ufw.

Journaux de ufw

La journalisation s'active avec sudo ufw logging on ; les niveaux disponibles sont low, medium, high et full. Les entrées sont écrites dans /var/log/ufw.log (via rsyslog) et dans le journal du noyau :

$ sudo journalctl -k | grep 'UFW BLOCK' | tail -2
Oct 14 10:12:03 web kernel: [UFW BLOCK] IN=eth0 OUT= SRC=45.155.205.1 DST=192.0.2.10 PROTO=TCP SPT=51544 DPT=3389
Oct 14 10:12:09 web kernel: [UFW BLOCK] IN=eth0 OUT= SRC=89.248.165.7 DST=192.0.2.10 PROTO=TCP SPT=40312 DPT=23

Les champs SRC et DPT indiquent qui frappait et sur quel port. Si un service ne répond pas et qu'un UFW BLOCK apparaît pour son port, c'est qu'aucune règle ne l'autorise.

ufw et Docker : pourquoi des ports sont ouverts malgré les règles

C'est le piège le plus connu. Lorsqu'il publie un port (-p 8080:80), Docker ajoute ses propres règles NAT et sa chaîne DOCKER : le trafic vers le conteneur passe par forward et contourne les règles d'entrée de ufw. Résultat : ufw status n'affiche pas le port 8080, et pourtant il est accessible de l'extérieur.

Solutions possibles :

• Publier les ports uniquement sur localhost : -p 127.0.0.1:8080:80, puis exposer le service vers l'extérieur via un reverse proxy (nginx).
• Ajouter vos propres règles dans la chaîne DOCKER-USER, que Docker ne réécrit pas.
• Ne publier aucun port des conteneurs techniques et les relier entre eux par le réseau Docker.

Réinitialisation et désactivation

$ sudo ufw disable     # désactiver, les règles sont conservées
$ sudo ufw reset       # supprimer toutes les règles et désactiver
$ sudo ufw reload      # relire la configuration

Avant un reset, ufw enregistre des copies des fichiers de règles dans /etc/ufw/, avec un suffixe de date. Les règles elles-mêmes sont stockées dans /etc/ufw/user.rules et user6.rules : ne les modifiez pas à la main, passez uniquement par les commandes.

Bases de nftables

nftables est le successeur moderne d'iptables dans le noyau Linux. Sous Debian 10+ et Ubuntu 20.10+, la commande iptables passe par la couche de compatibilité iptables-nft par défaut : les règles de ufw se retrouvent donc aussi dans nftables. Pour afficher tout ce qui est chargé dans le noyau :

$ sudo nft list ruleset

Structure de nftables : une table (famille ip, ip6, ou inet pour les deux) contient des chaînes rattachées aux points de netfilter, et les chaînes contiennent des règles. Voici un pare-feu minimal pour serveur, dans le fichier /etc/nftables.conf :

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        ip protocol icmp accept
        meta l4proto ipv6-icmp accept
        tcp dport { 22, 80, 443 } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Appliquer la configuration et l'activer au démarrage :

$ sudo nft -c -f /etc/nftables.conf   # vérifier uniquement la syntaxe
$ sudo systemctl enable --now nftables

On peut aussi ajouter des règles à chaud, mais elles disparaissent au redémarrage si elles ne sont pas inscrites dans un fichier :

$ sudo nft add rule inet filter input tcp dport 5432 ip saddr 10.0.0.5 accept
$ sudo nft -a list chain inet filter input   # -a affiche le handle des règles
$ sudo nft delete rule inet filter input handle 9

Le principal atout de nftables : les ensembles ({ 22, 80, 443 }) et une seule table inet pour IPv4 et IPv6. Ne lancez pas votre propre service nftables en même temps que ufw : flush ruleset effacerait les règles de ufw.

Erreurs fréquentes

• ufw activé sans règle pour SSH — l'accès est perdu. La console de l'hébergeur (VNC/série) permet de se rattraper : sudo ufw allow OpenSSH ou sudo ufw disable.
• Port ouvert, mais service inaccessible — le service écoute sur 127.0.0.1 et non sur l'adresse externe. Vérifiez avec ss -tlnp.
• Un pare-feu cloud supplémentaire existe — de nombreux hébergeurs proposent des groupes de sécurité ; il faut aussi y ouvrir le port.
• deny sans effet — la règle se trouve sous une autorisation qui la précède ; utilisez insert 1.

Conclusion

Configurer ufw de façon minimale revient à : default deny incoming, autoriser SSH et les ports des services, ufw enable, puis vérifier avec status numbered. Pour un accès ciblé, utilisez des règles avec from et port ; pour SSH, limit ; et n'oubliez pas que Docker contourne ufw. Lorsque vous avez besoin de NAT ou d'ensembles de règles complexes, passez à nftables. La protection d'un serveur par pare-feu est détaillée en pratique dans le cours Linux.