nftables et UFW : filtrer soi-même

Prérequis : Réseaux 4.1 (firewall) + DevOps 3.1.

Pourquoi

UFW suffit en façade, mais comprendre nftables (le successeur d'iptables) permet des règles fines (rate-limit, sets, journalisation ciblée) — et de lire ce que les outils génèrent vraiment.

Concepts

• Chaînes/table inet : table inet filter { input { type filter hook input priority 0; } } — une table, IPv4+v6 ensemble (fini les doublons iptables/ip6tables !).
• Verdicts : accept / drop (silencieux, préfèré : l'attaquant ne sait pas) / reject (poli, informe — utile en interne pour débugger).
• Sets : listes d'IP/ports nommées (set blacklist { type ipv4_addr; }) : bannir sans réécrire les règles. fail2ban s'en sert.
• UFW = frontend : ufw allow 22 génère du nftables/iptables. Pratique quotidienne ; nftables direct pour le fin (limites, logs par règle avec log prefix).

Exemple : SSH durci en nftables

table inet filter {
  set ssh_allow { type ipv4_addr; elements = { 203.0.113.5 } }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    tcp dport 22 ip saddr @ssh_allow accept
    tcp dport { 80, 443 } accept
  }
}

Cas réel

Brute-force SSH distribué (jamais 2 fois la même IP → fail2ban impuissant) : rate-limit nftables (limit rate 5/minute) sur le port 22 + clés uniquement. Le bruit tombe à zéro, les légitimes passent.

Pièges

• policy drop sans established/related accepté : on coupe les réponses — tout tombe, y compris SSH en cours. Toujours en premier.
• Règles dans le mauvais ordre : première correspondance gagne. Spécifique avant général, toujours.
• IPv6 oublié (table ip seule) : moitié de la surface non filtrée. inet couvre les deux.

À retenir

inet pour les deux piles, drop silencieux dehors / reject dedans, established d'abord, sets pour bannir.