Firewall Linux avancé : nftables (et pont ufw)

À la fin de ce tutoriel, vous saurez lire et écrire une politique nftables (table inet filter, chains input/forward/output, policies), utiliser un set d’IP et des counters, appliquer via nft -f, et persister avec nftables.service — sur VM jetable avec console de secours. ufw n’apparaît qu’en pont / contraste : ce n’est pas un redo du bonus ufw + fail2ban.

Niveau : Intermédiaire+ · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-firewall-nftables-ufw · Série : Linux Réseau & Sécurité · Remplace / fusionne : N/A — création (chapitre 1) ; P5 ufw reste prérequis

Prérequis

• Hub Linux Réseau & Sécurité (ton « suite avancée »)
• Réseau ip/ss/curl + bonus ufw + fail2ban déjà faits (pas de redo ufw enable)
• SSH & clés ; console / SSM de secours (SSM)
• nftables + sudo ; lab /tmp/lab-nft ; pas de secrets

Coût : 0 €. Risque lock-out si policy drop sans SSH — snapshot + console avant le lab.

Ce que nous allons construire

Pourquoi nft vs ufw (quand migrer)
  → Anatomie : table inet filter · input/forward/output · policy
  → Lab : SSH/HTTP/HTTPS + set IP + counters (nft -f)
  → Persistance : /etc/nftables.conf · nftables.service
  → Pont bref : ufw status → idées équivalentes nft
  → Rollback / nettoyage lab

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « nftables : table inet filter, sets, counters, persist — suite avancée après ufw ».)

Chapitre 1 de Linux Réseau & Sécurité. Bonus P5 = ufw simple ; ici cœur = nftables (sets, counters, inet).

Règle d’or : session SSH ouverte + console avant nft -f / restart nftables. Tester depuis /tmp.

Étape 1 — Pourquoi nftables plutôt qu’ufw (quand migrer)

Besoin	ufw (bonus P5)	nftables (ce tuto)
VPS simple deny/allow ports	Excellent	Possible, plus verbeux
Sets d’IP, compteurs, règles Git	Limité	Natif
IPv4+IPv6 une seule table	Règles doublées souvent	Famille inet
Backend moderne Debian/RHEL	Enveloppe nft/iptables	Langage direct

Migrer vers nft pour versionner la politique, gérer des sets d’IP (bastion, CI) ou coller à la doc amont. Rester sur ufw si le bonus P5 suffit. En lab avancé : sudo ufw disable avant de piloter nft — une seule source de vérité.

# État actuel (lecture) — ne change rien
command -v nft && nft --version
systemctl is-active nftables 2>/dev/null || true
systemctl is-active ufw 2>/dev/null || true
# Inventaire ports ouverts (rappel Basics)
ss -tuln | head -n 20

Rocky/Alma 9 : souvent firewalld devant nft. Lab = Ubuntu/Debian + nftables.service ; RHEL-like : VM nft dédiée (firewall-cmd hors cœur).

Étape 2 — Anatomie nft : table, chains, policy

table inet filter
  ├── chain input   (policy drop|accept)  ← trafic vers la machine
  ├── chain forward (policy drop|accept)  ← routage / conteneurs
  └── chain output  (policy accept)       ← sorties (souvent permissif lab)

Concept	Rôle
table	Conteneur de chains (inet = v4+v6)
chain	Liste ordonnée de règles + policy par défaut
rule	Match (port, IP, set…) → verdict (accept, drop, counter)
set	Ensemble d’éléments (IP, ports) réutilisable

Ordre input typique : loopback → established,related → SSH/HTTP/S → set admin optionnel → drop (policy).

# Voir règles actuelles (peut être vide ou géré par ufw)
sudo nft list ruleset | head -n 40

Étape 3 — Lab nftables : SSH, HTTP/S, set, counters

Fichier versionnable sous /tmp : politique restrictive en input, SSH avant le drop, HTTP/HTTPS ouverts, set admin_v4 pour un accès admin optionnel, counters pour mesurer.

Remplacez 192.0.2.10 par votre IP lab (RFC 5737 OK pour la syntaxe seule).

mkdir -p /tmp/lab-nft
# IMPORTANT : session SSH + console ouvertes
cat > /tmp/lab-nft/filter.nft << 'NFT'
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set admin_v4 {
    type ipv4_addr
    flags interval
    elements = { 192.0.2.10 }
  }

  chain input {
    type filter hook input priority filter; policy drop;

    iif "lo" accept
    ct state established,related accept
    ct state invalid drop

    # SSH — compteur pour voir les hits
    tcp dport 22 counter accept comment "ssh"
    # HTTP / HTTPS (prépare certbot chapitre 3)
    tcp dport { 80, 443 } counter accept comment "web"

    # Optionnel : tout TCP depuis le set admin
    ip saddr @admin_v4 counter accept comment "admin-set"

    # ICMP echo (ping) limité — lab
    ip protocol icmp icmp type echo-request limit rate 5/second accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
  }

  chain output {
    type filter hook output priority filter; policy accept;
  }
}
NFT

sudo nft -f /tmp/lab-nft/filter.nft
sudo nft list ruleset
# sudo nft list chain inet filter input   # counters après trafic

Élément lab	Intention
policy drop (input)	Deny par défaut — équivalent idée ufw deny, en nft natif
tcp dport 22 accept	Ne pas se couper SSH
tcp dport { 80, 443 }	Set anonyme de ports web
set admin_v4	Allowlist IP admin
counter	Visibilité hits (debug / capacity)

Test : autre client ssh / curl -I http://lab ; les counters doivent bouger.

Étape 4 — Persistance : nftables.service et nft -f

nft -f est en RAM : sans conf + service, perdu au reboot.

# Ubuntu/Debian : paquet + unit
dpkg -l nftables 2>/dev/null | tail -n 1 || true
systemctl status nftables --no-pager 2>/dev/null | head -n 15 || true

# Lab : installer la conf système depuis le fichier testé
# (sur VM jetable UNIQUEMENT — backup d’abord)
sudo cp -a /etc/nftables.conf /etc/nftables.conf.bak.$(date +%Y%m%d) 2>/dev/null || true
sudo cp /tmp/lab-nft/filter.nft /etc/nftables.conf
# En-tête souvent attendu : flush déjà dans notre fichier
sudo nft -c -f /etc/nftables.conf   # check syntaxe sans appliquer
sudo systemctl enable --now nftables
sudo systemctl restart nftables
sudo nft list ruleset | head -n 30

Fichier / unit	Rôle
/etc/nftables.conf	Ruleset chargé au boot (Debian/Ubuntu)
nftables.service	Exécute nft -f sur la conf
nft -c -f fichier	Check syntaxe
nft flush ruleset	Efface tout (danger sans console)

Rollback : restaurer le .bak + restart nftables, ou console : nft flush ruleset puis conf minimale SSH.

Étape 5 — Pont / contraste bref avec ufw (pas un redo)

Pas de redo P5 : seulement la traduction d’idées pour migrer.

Idée déjà vue (ufw)	Équivalent nft (ce lab)
deny incoming par défaut	chain input { policy drop; … }
allow 22 / OpenSSH	tcp dport 22 accept
allow 80,443	tcp dport { 80, 443 } accept
ufw status verbose	nft list ruleset / nft list chain inet filter input
règles persistantes ufw	/etc/nftables.conf + nftables.service

# Lecture seule — contraste
sudo ufw status verbose 2>/dev/null || echo "ufw inactif ou absent — OK pour lab nft"
sudo nft list chain inet filter input 2>/dev/null | head -n 40
# Si ufw encore actif en parallèle : préférez en lab
# sudo ufw disable
# puis re-appliquer : sudo nft -f /tmp/lab-nft/filter.nft

Première activation ufw : bonus ufw + fail2ban. Ici on pilote nft.

Étape 6 — Vérification et nettoyage / rollback lab

sudo nft list ruleset >/dev/null && echo "ruleset OK"
systemctl is-active nftables || true
# Compteurs (hits)
sudo nft list chain inet filter input | grep -E 'counter|dport' || true

# Rollback : sudo cp /etc/nftables.conf.bak.* /etc/nftables.conf && sudo systemctl restart nftables
# Ou console : sudo nft flush ruleset
rm -rf /tmp/lab-nft
echo "lab nft /tmp nettoyé — vérifier SSH encore OK"

Validé si : ruleset inet filter OK, SSH passe, counters visibles, nft -c -f OK, rollback connu.

Erreurs fréquentes

Symptôme	Cause	Correction
Lock-out SSH après nft -f	Policy drop sans règle 22 / mauvais port	Console ; nft flush ruleset ou conf minimale tcp dport 22 accept
Règles perdues au reboot	Pas de nftables.service / conf	Copier vers /etc/nftables.conf + enable --now
ufw et nft se marchent dessus	Deux managers	Lab : ufw disable puis nft seul
nft -f syntax error	Accolades / set mal formé	nft -c -f fichier avant apply
IPv6 encore ouvert	Table ip only	Utiliser inet (ce lab)
Set admin sans effet	IP client ≠ élément	Vérifier IP source (ss / logs) ; nft list set inet filter admin_v4

Quiz (3 questions)

1. Rôle de policy drop sur la chain input ?
– A. Autoriser tout le trafic entrant
– B. Refuser par défaut ce qui ne match aucune règle accept
– C. Remplacer fail2ban

2. Pourquoi un set admin_v4 ?
– A. Stocker des mots de passe
– B. Grouper des IP (allowlist) réutilisables dans les règles
– C. Compresser /var/log

3. Commande pour charger un fichier de règles ?
– A. ufw default deny uniquement
– B. sudo nft -f /chemin/fichier.nft (après check nft -c -f)
– C. chmod 777 /etc/nftables.conf

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Dois-je désinstaller ufw ?
Non. En lab nft : disable ufw. Prod simple P5 : ufw peut rester. Ici = politique nft versionnée.

nftables remplace-t-il le Security Group AWS ?
Non : SG/NACL avant l’instance ; nft sur l’hôte — AWS SG/NACL.

Où voir les hits ?
counter via nft list chain inet filter input — utile avant TLS / fail2ban.

Pour aller plus loin

• man nft, man nftables, doc Debian nftables
• Suite : fail2ban avancé : jails, filtres, banactions
• Prérequis P5 (pas copie) : ufw + fail2ban · réseau ip/ss

Maillage série Linux Réseau & Sécurité

← Précédent	Hub Linux Réseau & Sécurité
→ Suivant	fail2ban avancé : jails, filtres, banactions
Prérequis P5	ufw + fail2ban · réseau ip, ss, curl
Aussi	SSH & clés · AWS SG/NACL · SSM

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : nftables Linux : firewall avancé et pont ufw (2026)
• Meta description (≤ 155) : Écrivez une politique nftables (sets, counters, persist). Suite avancée après ufw Basics — guide DevOps 2026.
• Focus keyphrase : nftables
• KW secondaires : firewall linux, nft sets, nftables.conf, pont ufw
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-firewall-nftables-ufw-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire+
• Slug : linux-firewall-nftables-ufw
• Statut : HOLD — draft only (ne pas publier)

← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.