Tu veux un pare feu qui fait le job, sans te taper trois jours de docs, ni copier coller un truc trouvé sur un forum en 2017. nftables, c’est ça. Plus moderne que iptables, plus propre une fois que tu as pigé la logique.
On va faire simple, pratique, et un peu pressé, oui. Objectif : en 30 minutes tu as des règles de base correctes, une machine pas ouverte comme un hall de gare, et tu sais où regarder quand ça bloque.
Petit contexte : j’écris ça dans l’esprit du Le Blog Tech Pro de Samyn-Antoy ABASSE (sur https://monblog-sa-abasse.blogspot.com), donc style terrain, utile, et tu peux ensuite adapter dans tes serveurs, VPS, lab Proxmox, ou ta Debian de prod.
ce que tu vas obtenir à la fin
Un pare feu nftables qui :
- accepte ce qui est déjà établi (les connexions existantes)
- accepte le loopback (localhost)
- autorise SSH (avec ton port, et idéalement depuis tes IP)
- autorise éventuellement HTTP/HTTPS
- autorise ICMP utile (ping, MTU)
- bloque le reste, proprement
- log si tu veux, mais sans spammer
Et tu sais tester, lister, sauvegarder, restaurer.
avant de commencer : deux minutes de préparation
vérifier que nftables est là
Sur Debian, Ubuntu, etc :
bash nft --version
Si ça répond, OK.
Sinon :
bash sudo apt update sudo apt install nftables
Active le service :
bash sudo systemctl enable --now nftables sudo systemctl status nftables
attention si tu es en SSH
Si tu appliques des règles à distance, fais ça proprement sinon tu te coupes la branche.
Astuce simple : ouvre une deuxième session SSH, ou utilise tmux.
Et surtout, tu appliques d’abord des règles permissives, tu testes, puis tu verrouilles.
nftables en 2 phrases (sans souffrir)
- nftables fonctionne avec des tables (ex : inet filter), qui contiennent des chains (input, forward, output), qui contiennent des règles.
- les règles matchent des paquets et décident : accept, drop, reject, log, etc.
Le truc cool : la famille inet gère IPv4 et IPv6 d’un coup.
image mentale rapide (et utile)
Source : Wikimedia Commons. Ça aide à situer input, forward, output. Même si tu ne lis pas tout, regarde juste où passe un paquet entrant.
plan express : on part sur une base saine
On va créer une table inet filter avec trois chaînes :
input: ce qui arrive vers la machineforward: si la machine route du trafic (souvent non sur un VPS simple)output: ce qui sort de la machine
Politique :
- input : drop
- forward : drop
- output : accept (souvent OK, tu peux durcir plus tard)
version 1 : règles de base prêtes en 5 minutes
1) créer un fichier de conf
Crée un fichier :
bash sudo nano /etc/nftables.conf
Mets ceci, puis adapte les ports :
nft #!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input { type filter hook input priority 0; policy drop;
# 1) trafic déjà établi
ct state established,related accept
# 2) loopback
iif "lo" accept
# 3) ICMP utile (ping, PMTU)
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
# 4) SSH (à adapter)
tcp dport 22 accept
# 5) HTTP/HTTPS si serveur web
tcp dport { 80, 443 } accept
# 6) optionnel : log des drops (modéré)
limit rate 10/second log prefix "nft drop input : " flags all counter
}
chain forward { type filter hook forward priority 0; policy drop; }
chain output { type filter hook output priority 0; policy accept; } }
2) tester la syntaxe
Très important :
bash sudo nft -c -f /etc/nftables.conf
Si pas d’erreur, applique :
bash sudo nft -f /etc/nftables.conf
Liste :
bash sudo nft list ruleset
image : à quoi ressemble la sortie en vrai
Ce n’est pas ton serveur, c’est juste pour visualiser. L’idée : table, chains, rules. C’est lisible.
le point critique : SSH, ne te piège pas
La règle tcp dport 22 accept est le minimum vital. Mais en prod, tu veux souvent restreindre par IP.
Exemple : tu autorises SSH seulement depuis ton IP publique (remplace par la tienne) :
nft ip saddr 203.0.113.10 tcp dport 22 accept
Si tu as plusieurs IP, un set :
nft ip saddr { 203.0.113.10, 198.51.100.22 } tcp dport 22 accept
Et si tu utilises un port SSH différent (ex : 2222) :
nft tcp dport 2222 accept
Oui, changer le port ne remplace pas une vraie sécu, mais ça réduit du bruit. Le vrai gain c’est IP allowlist, fail2ban, clés SSH, pas de mot de passe.
règles un peu plus propres : l’approche « pro simple »
Là on améliore deux trucs :
- on évite de tout autoriser en ICMP, on garde l’utile
- on met des compteurs, pratique pour debug
Tu peux remplacer la partie ICMP par ça :
nft
ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded, parameter-problem } accept
ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert, packet-too-big, time-exceeded, parameter-problem, destination-unreachable } accept
Tu vois l’idée. Tu gardes IPv6 fonctionnel au lieu de le casser et de te demander ensuite pourquoi certains trucs « rament ».
sets : le truc qui te fait gagner du temps
nftables est très fort avec les sets. Par exemple, tu veux gérer une liste d’IP admin pour SSH.
Dans la table :
nft set admin_v4 { type ipv4_addr; elements = { 203.0.113.10, 198.51.100.22 } }
Et ta règle :
nft ip saddr @admin_v4 tcp dport 22 accept
Tu veux ajouter une IP sans réécrire tout :
bash sudo nft add element inet filter admin_v4 { 203.0.113.99 }
C’est propre. Et ça évite le fichier conf qui devient un roman.
logs : oui, mais pas en mode mitraillette
Le log peut vite devenir infernal. Donc :
- limite rate
- préfixe clair
- place le log avant la fin, mais après les accept
Exemple raisonnable :
nft limit rate 5/second log prefix "nft input drop : " flags all counter
Astuce debug : tu actives le log le temps de diagnostiquer, puis tu le coupes. Sinon, tu payes en I/O disque, et tu te noies.
forward : tu en as besoin ou pas
Sur un VPS classique, forward peut rester en drop.
Mais si tu fais du routage, du NAT, un serveur VPN, un hôte Docker avec règles custom, là ça devient un autre sujet. On reste « débutant pressé », donc :
- si tu ne sais pas, laisse forward en drop
- si ton infra dépend du forwarding, tu le sais déjà (normalement…)
et docker dans tout ça
Docker peut manipuler iptables, et maintenant parfois nftables selon distro. Ça peut créer des surprises.
Si tu fais du Docker en prod :
- vérifie ce que Docker configure
- teste tes règles après lancement de Docker
- évite de faire la guerre entre deux systèmes de règles
Si tu veux que je fasse une version « nftables + docker propre », c’est typiquement un bon sujet à poser sur le blog, et je peux te proposer une matrice de règles par usage.
sauvegarder et restaurer
Tu as deux méthodes :
méthode fichier (recommandée)
Ton /etc/nftables.conf est la source.
Et tu appliques avec :
bash sudo nft -f /etc/nftables.conf
méthode dump live
Dump :
bash sudo nft list ruleset > /root/nftables-backup.nft
Restore :
bash sudo nft -f /root/nftables-backup.nft
check rapide : commandes utiles à connaître
Lister :
bash sudo nft list ruleset
Lister une table :
bash sudo nft list table inet filter
Lister une chain :
bash sudo nft list chain inet filter input
Voir les compteurs (si counter dans les règles) :
bash sudo nft -a list chain inet filter input
Tester la conf sans appliquer :
bash sudo nft -c -f /etc/nftables.conf
exemple 2 : configuration minimaliste pour un serveur SSH only
Si ta machine ne sert qu’à l’admin, pas de web :
nft #!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input { type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } accept
ip6 nexthdr icmpv6 icmpv6 type {
echo-request, echo-reply,
nd-neighbor-solicit, nd-neighbor-advert,
nd-router-solicit, nd-router-advert,
packet-too-big, time-exceeded, parameter-problem,
destination-unreachable
} accept
# SSH uniquement depuis IP admin
ip saddr 203.0.113.10 tcp dport 22 accept
limit rate 5/second log prefix "nft drop : " flags all counter
}
chain forward { type filter hook forward priority 0; policy drop; }
chain output { type filter hook output priority 0; policy accept; } }
image : aide mémoire ports utiles (mini tableau)
Tu n’as pas besoin de retenir tout. Juste : 22 SSH, 80 HTTP, 443 HTTPS. Et après tu ajoutes selon tes services.
erreurs classiques (que j’ai faites aussi)
« j’ai tout bloqué, même SSH »
Tu as appliqué une policy drop sans règle SSH valide, ou mauvaise IP source.
Solutions :
- console du provider (VNC, console web)
- revert conf
- applique une règle temporaire permissive, teste, puis restreins
« ça marche en IPv4 mais pas en IPv6 »
Tu as autorisé seulement ip et pas ip6, ou tu as cassé ICMPv6.
Rappel : ICMPv6 n’est pas optionnel.
« mon service écoute, mais inaccessible »
Vérifie :
ss -tulpnpour voir le port- nftables input règle port
- security group du cloud (OVH, AWS, etc)
- pare feu applicatif, ou binding sur 127.0.0.1 seulement
mini méthode de debug en 3 étapes
- Est ce que le service écoute ?
bash sudo ss -tulpn
- Est ce que nftables bloque ? Ajoute un log temporaire à la fin de input.
- Est ce que le réseau cloud bloque avant ton serveur ? Security group, firewall provider, etc.
Franchement, la moitié des « nftables ne marche pas » viennent du firewall du cloud.
durcissement rapide (si tu as 5 minutes de plus)
refuser au lieu de drop (parfois)
Drop est silencieux. Reject répond. Pour certains services, reject peut aider au diagnostic mais donne aussi une info à l’attaquant.
Exemple :
nft tcp dport 113 reject
Tu peux faire un mix. Pour un serveur public, drop est souvent OK.
limiter SSH (anti bruteforce basique)
Ce n’est pas un remède miracle, mais ça réduit le spam :
nft tcp dport 22 ct state new limit rate 10/minute accept
Mais attention, si tu fais ça n’importe comment tu peux te bloquer toi même en cas de reconnexions rapides.
Le bon plan reste : clés SSH + fail2ban + allowlist IP.
petit rappel « production »
- garde ta conf versionnée (Git privé, ou au moins un backup)
- documente tes ports autorisés
- teste après reboot
- ne mélange pas 4 pare feux en même temps (ufw + firewalld + règles nft à la main, etc)
conclusion : ton pare feu est prêt, maintenant fais le tien
En 30 minutes, tu as une base nftables utilisable, lisible, et surtout modifiable sans stress. Tu peux la coller sur un VPS, une VM, un serveur web, et avancer.
Si tu veux aller plus loin, je publie souvent des checklists et des méthodes « build, scale, sell » côté admin Linux et productivité sur Le Blog Tech Pro de Samyn-Antoy ABASSE. Tu peux passer sur https://monblog-sa-abasse.blogspot.com et regarder les pages ressources, services, et les articles sysadmin. L’idée, c’est que tu puisses réutiliser des patterns, pas réinventer la roue à chaque serveur.
Et si tu veux un exercice concret pour t’entraîner : prends une VM Debian, applique la conf minimaliste SSH only, puis ajoute HTTP/HTTPS, puis restreins SSH par IP. Tu vas comprendre nftables en le touchant, pas en le lisant.
Questions fréquemment posées
Qu'est-ce que nftables et pourquoi l'utiliser plutôt qu'iptables ?
Nftables est un pare-feu moderne et plus propre que iptables une fois que vous avez compris sa logique. Il permet de gérer les règles de filtrage réseau de manière plus simple, efficace et adaptée aux systèmes récents, notamment en combinant IPv4 et IPv6 dans la famille 'inet'.
Comment vérifier si nftables est installé et actif sur ma machine Debian ou Ubuntu ?
Pour vérifier si nftables est installé, tapez la commande 'nft --version'. Si elle répond avec une version, c'est bon. Sinon, installez-le avec 'sudo apt update' puis 'sudo apt install nftables'. Activez ensuite le service avec 'sudo systemctl enable --now nftables'.
Quelles sont les règles de base recommandées pour un pare-feu nftables sécurisé ?
Un pare-feu nftables de base doit accepter les connexions déjà établies, autoriser le trafic loopback (localhost), permettre SSH (idéalement restreint à vos IP), autoriser HTTP/HTTPS si nécessaire, accepter les paquets ICMP utiles comme ping ou PMTU, bloquer tout le reste proprement et éventuellement logguer sans spammer.
Comment éviter de se couper l'accès SSH lors de la configuration des règles nftables à distance ?
Il est conseillé d'ouvrir une deuxième session SSH ou d'utiliser un multiplexeur comme tmux avant d'appliquer des règles. Appliquez d'abord des règles permissives, testez-les bien, puis verrouillez progressivement. Cela évite de perdre l'accès en cas d'erreur.
Comment restreindre l'accès SSH à certaines adresses IP avec nftables ?
Vous pouvez spécifier les IP autorisées en utilisant une règle du type : 'nft ip saddr { 203.0.113.10, 198.51.100.22 } tcp dport 22 accept'. Remplacez les IP par celles autorisées et ajustez le port si vous utilisez un port SSH différent.
Quels sont les avantages de la famille 'inet' dans nftables ?
La famille 'inet' permet de gérer simultanément le filtrage pour IPv4 et IPv6 dans une seule table, simplifiant ainsi la gestion des règles réseau sans avoir à créer des tables séparées pour chaque protocole IP.
0 Commentaires