Un pare-feu avec ufw et nftables

Module 5: Protéger le réseau · Temps de lecture : 12 minutes

Objectif pédagogique : À la fin de cette leçon, vous saurez configurer un pare-feu qui n'autorise que le nécessaire, en IPv4 comme en IPv6, sans vous enfermer dehors, et vous saurez contre quoi un pare-feu sur votre serveur ne vous protège pas.

Notions clés : filtre de paquets, netfilter, nftables, iptables-nft, ufw, politique par défaut, allow, deny, reject, limit, IPv6 dans ufw, pare-feu du fournisseur, firewalld, Docker et le pare-feu

Ce que fait un pare-feu

Un pare-feu sur votre serveur est un filtre de paquets : pour chaque paquet réseau entrant, il consulte une liste de règles et décide s'il peut passer. Sous Linux, ce filtre se trouve dans le noyau et s'appelle netfilter. Vous le configurez avec un programme :

• nftables (commande nft) est l'outil actuel. Debian l'utilise par défaut depuis Debian 10.
• iptables est l'ancien outil. Sur les systèmes modernes, iptables est généralement une traduction vers nftables (iptables-nft), afin que les anciens guides fonctionnent encore.
• ufw (Uncomplicated Firewall) est une couche simple par-dessus, présente par défaut sur Ubuntu et installable en une commande sur Debian. Pour un serveur unique, ufw est le choix le plus simple. Cette leçon utilise ufw, puis montre à quoi ressemblent les mêmes règles dans nftables.

Un pare-feu est votre deuxième couche de défense. La première consiste à ce que les services n'écoutent que sur la bonne adresse (leçon 5.1). Ensemble, elles garantissent qu'une erreur dans une couche ne devient pas aussitôt une porte ouverte.

D'abord : comment revenir si ça tourne mal ?

L'erreur classique : vous activez le pare-feu, oubliez d'autoriser SSH, et votre connexion tombe. Vous ne pouvez alors plus accéder au serveur via SSH. Avant de commencer :

1. Sachez comment ouvrir la console de votre fournisseur (leçon 1.2). Elle fonctionne en dehors du réseau, donc même si le pare-feu bloque tout. Vous vous y connectez et tapez ufw disable.
2. Faites un snapshot en cas de doute.
3. Gardez votre session SSH actuelle ouverte et testez avec une deuxième session.

ufw en cinq étapes

Étape 1 : installer et choisir la politique par défaut.

anna@web1:~$ sudo apt install ufw
anna@web1:~$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
anna@web1:~$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'

La politique par défaut s'applique à tout ce qui n'a pas de règle. « Deny incoming » signifie : tout ce qui entre est interdit, sauf ce que vous autorisez ensuite. C'est la seule base sûre. Vous autorisez le trafic sortant (votre serveur qui récupère des mises à jour).

Étape 2 : autoriser SSH, avant d'activer le pare-feu.

anna@web1:~$ sudo ufw allow OpenSSH
Rules updated
Rules updated (v6)

OpenSSH est un profil d'application connu d'ufw (il correspond au port 22/tcp). Si SSH tourne sur un autre port, utilisez le numéro : sudo ufw allow 2222/tcp. Remarquez « Rules updated (v6) » : ufw crée aussi la règle pour IPv6. Il le fait parce que /etc/default/ufw contient la ligne IPV6=yes, ce qui est la valeur par défaut. Vérifiez-le ; si elle est réglée sur no, votre pare-feu ne s'applique qu'à IPv4.

Étape 3 : ce dont vous avez besoin en plus.

anna@web1:~$ sudo ufw allow 80/tcp
anna@web1:~$ sudo ufw allow 443/tcp
anna@web1:~$ sudo ufw allow 443/udp       # uniquement si vous utilisez HTTP/3

Vous pouvez limiter une règle à une seule adresse source, par exemple un port d'administration accessible uniquement depuis votre bureau :

anna@web1:~$ sudo ufw allow from 198.51.100.20 to any port 9090 proto tcp

Étape 4 : activer.

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

Étape 5 : vérifier. Ouvrez une deuxième fenêtre et reconnectez-vous. Si cela fonctionne, SSH est bien configuré. Consultez ensuite les règles :

anna@web1:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (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)

Pour supprimer une règle, utilisez les numéros : sudo ufw status numbered, puis sudo ufw delete 3.

deny, reject et limit

• deny laisse tomber le paquet en silence : de l'extérieur, vous voyez « filtré » (leçon 5.1).
• reject renvoie un refus : de l'extérieur, vous voyez « fermé ». C'est plus propre pour vos propres services, mais cela révèle qu'il y a un serveur.
• limit autorise une connexion, mais bloque une adresse qui tente de se connecter six fois ou plus en 30 secondes. Pratique pour SSH : sudo ufw limit OpenSSH au lieu de allow. C'est grossier (cela compte les connexions, pas les connexions échouées) ; fail2ban (leçon 5.3) est plus précis.

Les mêmes règles dans nftables

En coulisses, ufw écrit des règles netfilter. Si vous voulez travailler sans ufw, vous écrivez vous-même un fichier nftables. Sur Debian, il se trouve dans /etc/nftables.conf et vous le chargez avec le service nftables :

#!/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
        meta l4proto { icmp, 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;
    }
}

Lisez-le ainsi. La table s'appelle filter et appartient à la famille inet : une seule table pour IPv4 et IPv6 à la fois, de sorte que vous ne pouvez pas oublier IPv6. Dans la chaîne input, la politique est drop. Ensuite : les réponses aux connexions déjà existantes peuvent revenir (established,related), tout ce qui passe par loopback est autorisé, ICMP est autorisé (nécessaire notamment pour IPv6 et pour les messages d'erreur sur la taille des paquets), et les ports 22, 80 et 443 sont autorisés.

anna@web1:~$ sudo nft -c -f /etc/nftables.conf    # vérifier sans charger
anna@web1:~$ sudo systemctl enable --now nftables
anna@web1:~$ sudo nft list ruleset

Utilisez soit ufw, soit votre propre fichier nftables, pas les deux : ils écrivent dans le même netfilter et peuvent se gêner mutuellement.

Contre quoi votre pare-feu ne protège pas

• Les services que vous autorisez vous-même. Le port 443 est ouvert pour votre site web ; une faille dans votre site reste donc parfaitement accessible. Le pare-feu ne protège que les ports fermés.
• Docker. Lorsque vous publiez un port avec Docker (-p 5432:5432), Docker pose ses propres règles netfilter, qui redirigent le trafic avant que les règles d'ufw ne s'appliquent. La documentation de Docker indique littéralement que Docker et ufw ne font pas bon ménage. Un port de conteneur peut donc être ouvert depuis l'extérieur alors que ufw status ne l'affiche pas. La solution (publier sur 127.0.0.1) est abordée dans la leçon 9.3.
• Le trafic sortant. Avec « allow outgoing », un programme piraté peut aller n'importe où. Pour la plupart des petits serveurs, c'est un choix acceptable ; les environnements stricts limitent aussi le trafic sortant.

Le pare-feu de votre fournisseur

De nombreux fournisseurs proposent aussi un pare-feu dans le réseau, devant votre serveur, que vous configurez dans l'espace client (parfois appelé « cloud firewall » ou « security group »). C'est une excellente couche supplémentaire, qui fonctionne même si vous faites une erreur sur le serveur lui-même. Mais il ne remplace pas le pare-feu du serveur : si vous déplacez le serveur ou changez de fournisseur, il ne suit pas, et tous les fournisseurs ne le proposent pas. Gardez donc toujours un pare-feu sur le serveur lui-même.

Sur AlmaLinux et Rocky Linux

Sur ces systèmes, firewalld est activé par défaut, avec des zones. Les commandes principales :

[root@web1 ~]# firewall-cmd --list-all
[root@web1 ~]# firewall-cmd --permanent --add-service=http --add-service=https
[root@web1 ~]# firewall-cmd --reload

Sans --permanent, une modification n'est valable que jusqu'au prochain redémarrage ; avec --permanent, elle ne prend effet qu'après --reload. SSH est déjà ouvert dans la zone par défaut.

En pratique

Si vous vous enfermez malgré tout dehors sur un VPS chez WebOké, ouvrez la console dans l'écran du VPS, connectez-vous et désactivez le pare-feu (ufw disable) ou annulez la dernière règle. Chez d'autres fournisseurs, cet accès de secours s'appelle aussi console, VNC ou rescue. Sachez où se trouve ce bouton avant d'en avoir besoin.

Résumé

• Un pare-feu est votre deuxième couche après « n'écouter que là où c'est nécessaire » ; nftables est l'outil du noyau, ufw une couche simple par-dessus.
• Commencez par default deny incoming, autorisez SSH avant ufw enable, testez avec une deuxième session et sachez utiliser la console de votre fournisseur.
• Vérifiez qu'ufw couvre aussi IPv6 (IPV6=yes) ; dans nftables, la famille inet le fait en une fois.
• deny donne « filtré » vu de l'extérieur, reject donne « fermé » ; limit freine les connexions répétées.
• Les ports Docker contournent ufw (leçon 9.3) ; le pare-feu de votre fournisseur est une couche supplémentaire, pas un remplacement.

Quiz

Exercice

Exercice O5.2 : Configurer votre pare-feu. Activez sur votre serveur un pare-feu avec ufw (ou nftables, ou firewalld sur AlmaLinux/Rocky) : par défaut tout fermé en entrée, SSH, et ce dont vous avez réellement besoin en plus. Testez avec une deuxième session, vérifiez qu'IPv6 est couvert, et contrôlez depuis l'extérieur avec nc qu'un port non autorisé est fermé ou filtré. Remplissez la checklist et collez votre ufw status verbose (ou nft list ruleset) ; indiquez pour chaque port ouvert à quoi il sert.

Pour aller plus loin

• Sécuriser votre VPS : les cinq premières minutes
• Plus d'accès à votre VPS : que faire ?
• Debian Wiki, nftables : https://wiki.debian.org/nftables
• Documentation Ubuntu Server, Firewall (ufw) : https://ubuntu.com/server/docs/how-to/security/firewalls/
• Documentation Docker, Packet filtering and firewalls : https://docs.docker.com/engine/network/packet-filtering-firewalls/