Un jeu de règles nftables minimal pour un serveur unique

Objectif

N'exposer que les ports qu'un serveur est censé servir, aussi bien en IPv4 qu'en IPv6, avec un jeu de règles qui tient sur un écran et se recharge en toute sécurité.

Prérequis

Un accès root, le binaire nft et une liste des ports que l'hôte sert.

Étapes

1. Écrire /etc/nftables.conf en suivant la structure de l'exemple de serveur du wiki nftables : flush ruleset, puis une seule table inet filter, afin qu'un jeu de règles unique couvre les deux familles d'adresses.
2. Définir chain input { type filter hook input priority 0; policy drop; ... } et, dans l'ordre : ct state vmap { established : accept, related : accept, invalid : drop }, iifname lo accept, meta l4proto { icmp, ipv6-icmp } accept (l'ICMPv6 transporte la découverte de voisins ; le bloquer casse l'IPv6, donc l'exemple du wiki accepte au moins les types nd-*), puis tcp dport { 22, 80, 443 } accept.
3. Ajouter chain forward { type filter hook forward priority 0; policy drop; } uniquement si l'hôte ne route rien et ne fait tourner aucun conteneur : nft(8) indique qu'un paquet n'est accepté que si aucune chaîne de base ne le rejette, donc une chaîne forward qui rejette bloque aussi le trafic du bridge d'un runtime de conteneurs. Laisser output non défini, ce qui signifie accepter.
4. Pendant le débogage, terminer la chaîne input par log prefix "nft-drop " counter drop.
5. Valider la syntaxe sans l'appliquer : nft -c -f /etc/nftables.conf.
6. Armer un retour arrière avant le chargement : systemd-run --on-active=120 nft flush ruleset programme un flush dans deux minutes (--on-active est documenté dans systemd-run(1)). Charger avec nft -f /etc/nftables.conf, confirmer qu'une nouvelle session SSH fonctionne, puis arrêter le timer éphémère dont systemd-run a affiché le nom d'unité.
7. Inspecter l'état en cours avec nft list ruleset ; nft(8) indique que cette sortie peut servir d'entrée à nft -f, ce qui en fait aussi une sauvegarde.
8. Activer le service nftables de la distribution pour que le fichier soit chargé au démarrage.

Résultat attendu

nft list ruleset affiche exactement les chaînes prévues ; un scan de port depuis l'extérieur ne montre que les ports listés ; un rechargement avec nft -f remplace l'ancien jeu de règles par le nouveau en une seule opération (l'« atomic rule replacement » du wiki), donc il n'y a jamais de moment sans règles, et les connexions existantes continuent de correspondre à ct state established.

Limites et base de vérification

Le jeu de règles ne sait pas quel processus écoute sur un port. Les runtimes de conteneurs insèrent leurs propres tables et priorités ; avec la mise en réseau en bridge, le trafic vers les ports de conteneurs publiés est généralement traduit et redirigé plutôt que délivré localement, si bien qu'il contourne cette chaîne input et rencontre plutôt le hook forward. Consulter la documentation de pare-feu du runtime avant d'ajouter des règles forward, et ne pas mélanger l'ancien iptables avec nft. La syntaxe suit le wiki et le manuel cités ; aucune mesure de débit ou de sécurité n'est avancée.

Retour arrière vers le jeu de règles précédent, pas vers rien

Un flush ruleset programmé laisse l'hôte sans aucune règle et supprime des tables dont d'autres logiciels dépendent. Sauvegarder d'abord l'état courant et armer une restauration à la place :

nft list ruleset > /root/nft-before.conf
systemd-run --on-active=120 nft -f /root/nft-before.conf
nft -f /etc/nftables.conf

Confirmer qu'une nouvelle session SSH fonctionne, puis arrêter le timer éphémère. Pour la même raison, éviter flush ruleset dans le fichier de configuration sur les hôtes qui font tourner un runtime de conteneurs : cela supprime les tables ip nat et ip filter du runtime, et les ports publiés cessent de fonctionner jusqu'au redémarrage du runtime. Ne vider que sa propre table (table inet filter {} suivi de flush table inet filter), ce qui reste atomique pour cette table.