Pendant des mois, j’ai utilisé Linux en me disant que j’étais « plutôt bien protégé ». Pare-feu actif, mises à jour régulières, mot de passe solide. La totale. Sauf qu’un jour, en tapant une seule commande pour vérifier l’état de mes connexions réseau, j’ai vu défiler des dizaines de ports ouverts dont je n’avais aucune idée de l’existence. Des services qui écoutaient en silence. Des portes entrouvertes que je n’avais jamais fermées. C’est là que nftables est entré dans ma vie.
À retenir
- Votre Linux « fraîchement installé » cache probablement des ports ouverts dont vous ignorez l’existence
- nftables offre une syntaxe cohérente pour filtrer le trafic, bien plus accessible qu’iptables
- Une politique « default deny » change tout : on n’ouvre que ce qu’on utilise vraiment
Le problème qu’on ne voit pas
Une installation Linux fraîche, même sur une distribution grand public, n’est pas aussi hermétique qu’on l’imagine. Les services démarrent, les ports s’ouvrent, et si personne ne surveille, le trafic entre et sort à peu près librement. L’analogie classique de la maison avec des fenêtres ouvertes est trop douce : c’est plutôt une maison où certaines portes n’ont jamais eu de serrure installée, parce que personne n’a pensé à le faire.
Les outils de filtrage réseau sous Linux ont une longue histoire un peu chaotique. iptables a régné pendant des années, mais sa syntaxe complexe décourage beaucoup de gens, et son modèle de règles en cascade prête à confusion. ufw (Uncomplicated Firewall) simplifie les choses sur Ubuntu et Debian, mais reste une surcouche avec ses propres limites. Depuis quelques années, nftables s’est imposé comme le successeur officiel, intégré directement dans le noyau Linux, avec une syntaxe cohérente et des performances améliorées.
La bonne nouvelle : pas besoin d’être administrateur système dans une grande entreprise pour le maîtriser. Quelques commandes suffisent pour reprendre le contrôle.
Prendre la main avec nftables : le guide sans prise de tête
Avant de toucher quoi que ce soit, on vérifie l’état actuel. La commande sudo nft list ruleset affiche toutes les règles actives. Si la sortie est vide ou presque, votre système n’a pratiquement aucun filtrage actif. Respiration profonde.
Pour visualiser les connexions réseau actuellement ouvertes, ss -tuln est votre meilleur ami : elle liste les ports en écoute avec les protocoles associés. TCP, UDP, ports locaux ou exposés sur l’interface réseau principale. C’est souvent là qu’on découvre que le serveur SSH écoute sur toutes les interfaces, qu’un service de partage de fichiers traine ouvert, ou qu’une application installée il y a six mois a ouvert son propre port sans prévenir.
Une fois ce diagnostic posé, la création d’une table nftables de base ressemble à ça :
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 \; policy drop \; }
sudo nft add chain inet filter output { type filter hook output priority 0 \; policy accept \; }
Ce bloc crée une table de filtrage, définit trois chaînes (entrée, transit, sortie) et applique une politique de rejet par défaut sur tout ce qui entre. On part du principe que rien n’est autorisé tant qu’on ne l’a pas explicitement dit. C’est ce qu’on appelle le modèle « default deny », et c’est la philosophie de sécurité la plus saine qui soit.
Évidemment, si on bloque tout en entrée, on se coupe de certaines choses utiles. On réautorise les connexions déjà établies (pour ne pas couper ce qui fonctionne) et les connexions locales :
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
Puis, selon les besoins, on ouvre des ports spécifiques. SSH sur le port 22 ? sudo nft add rule inet filter input tcp dport 22 accept. Un serveur web local sur le 8080 ? Même logique. On n’ouvre que ce qu’on utilise vraiment. Pas de port « au cas où ».
Rendre tout ça permanent (parce que sinon, au prochain reboot…)
Le piège classique avec nftables : les règles ajoutées manuellement disparaissent au redémarrage. Pour les rendre persistantes, la méthode la plus propre consiste à les exporter dans un fichier de configuration puis à activer le service systemd correspondant.
On sauvegarde l’état actuel : sudo nft list ruleset > /etc/nftables.conf. Ensuite, on s’assure que le service nftables est bien activé au démarrage avec sudo systemctl enable nftables. Sur certaines distributions, il faudra peut-être ajuster le chemin du fichier de configuration dans /etc/sysconfig/nftables.conf ou équivalent, mais la logique reste identique.
Une alternative confortable pour les moins à l’aise avec la ligne de commande pure : firewalld, qui utilise nftables en backend depuis quelques versions et propose une interface un peu plus abstraite avec des notions de « zones » réseau. Pratique pour distinguer ce qu’on autorise sur le réseau local vs sur une interface publique.
La sécurité réseau, c’est un état d’esprit
Le vrai changement, ce n’est pas la commande elle-même. C’est l’habitude de vérifier. Avoir une règle « default deny » force à réfléchir à chaque service qu’on installe : est-ce qu’il doit être joignable depuis l’extérieur ? Est-ce qu’il doit même écouter sur le réseau, ou juste en local ? Ces questions, la plupart des utilisateurs ne se les posent jamais, et les applications ne les posent certainement pas à leur place.
Un chiffre qui donne à réfléchir : la majorité des compromissions de systèmes Linux personnels ou de petits serveurs exploitent des services oubliés ou mal configurés, pas des failles zero-day sophistiquées. On ne parle pas d’attaques de film d’espionnage, mais d’un bot qui scanne l’internet en cherchant un port ouvert avec un mot de passe par défaut. Ce genre de chose arrive en quelques minutes après qu’une machine est exposée en ligne.
Auditer son réseau avec ss ou nmap sur sa propre machine, construire ses règles nftables progressivement, vérifier une fois par mois ce qui a changé : c’est une hygiène numérique accessible à n’importe quel utilisateur Linux intermédiaire. Et si la ligne de commande vous intimide encore, c’est peut-être le projet idéal pour franchir ce cap. Parce qu’au fond, comprendre ce qui entre et sort de votre machine, c’est comprendre Comment votre machine fonctionne vraiment.
Sources : astuces-aide-informatique.info | it-connect.fr