🔒 Mise à jour du dépôt GitHub : d’iptables à nftables, plongée au cœur du filtre de paquets

🌐 Aussi en: English · Deutsch · Español

Petite mise à jour du dépôt : le dépôt GitHub www_k3s vient de recevoir une sérieuse refonte de son pare-feu. L’ancienne configuration reposait sur le bon vieux iptables – ça marchait très bien, mais ça commençait à ressembler à une voiture de collection avec starter manuel et double débrayage. Il était temps de passer à autre chose. Le pare-feu est désormais entièrement réécrit en nftables, le successeur moderne livré par défaut sous Linux depuis le noyau 3.13. Voici pourquoi c’est le bon choix, et une visite complète de ce que fait concrètement le nouveau jeu de règles. 🧵

⚡ nftables vs iptables – pourquoi c’est important

iptables est le filtre de paquets standard de Linux depuis la fin des années 90. Il fonctionne, il a fait ses preuves, et environ un milliard de réponses sur Stack Overflow y font référence. Mais il accuse son âge :

• Pas de mises à jour atomiques des règles – les modifications sont appliquées ligne par ligne, ce qui laisse une courte fenêtre pendant laquelle votre jeu de règles n’est que partiellement appliqué
• Des outils séparés pour IPv4/IPv6 – iptables et ip6tables, deux stocks de règles distincts à garder synchronisés
• Pas de sets natifs – les listes de blocage d’IP nécessitent des outils tiers comme ipset
• Performances – la correspondance des règles est linéaire ; plus il y a de règles, plus c’est lent

nftables (introduit avec Linux 3.13, par défaut sur la plupart des distributions depuis 2019 environ) règle tout cela :

• ✅ Un seul jeu de règles pour IPv4 + IPv6 (table inet)
• ✅ Remplacement atomique des règles – tout le jeu de règles est échangé en un seul appel système
• ✅ Des sets natifs avec gestion des délais d’expiration (listes de blocage d’IP intégrées, pas besoin d’ipset)
• ✅ De meilleures performances grâce à une machine virtuelle compilée JIT dans le noyau

Sous AlmaLinux 9, nftables est la solution par défaut du système. La commande iptables n’y est littéralement qu’une couche de compatibilité au-dessus de nftables. Utiliser la vraie syntaxe iptables en 2025, c’est donc écrire des règles iptables qui seront de toute façon traduites en règles nftables – en perdant au passage toute la jolie syntaxe. 😅

📄 Le jeu de règles – section par section

Le pare-feu est un template Jinja2 Ansible (roles/common_firewall/templates/fw.nft.j2) rendu pour chaque hôte et appliqué via nftables. Parcourons-le.

🗂️ Les sets de blocage

set banned4 {
  type ipv4_addr
  flags timeout
  timeout 1d
}
set banned6 {
  type ipv6_addr
  flags timeout
  timeout 1d
}

Deux sets – un pour IPv4, un pour IPv6 – qui servent de liste de blocage dynamique. flags timeout + timeout 1d signifie que chaque entrée expire automatiquement au bout de 24 heures. fail2ban écrit dans ces sets dès qu’il détecte une attaque par force brute ou un scan de ports. Pas besoin de tâche cron pour nettoyer les vieux bannissements. 🧹

🔗 Chaîne INPUT – le plat de résistance

La politique par défaut est DROP – tout ce qui n’est pas explicitement autorisé est rejeté en silence.

iif lo accept

Le trafic loopback (127.0.0.1, ::1) est toujours accepté. Toute la communication interne à l’hôte – kubectl, kubelet, collecte Prometheus, sockets de base de données – passe par ici.

ct state established,related accept
ct state invalid drop

Le suivi de connexions (connection tracking) fait le gros du travail. Les connexions déjà établies sont acceptées sans examiner d’autres règles. Les paquets à l’état invalide (par ex. des paquets TCP qui n’appartiennent à aucune connexion connue) sont rejetés immédiatement.

tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg drop  # XMAS
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 drop                       # NULL

Le grand classique : jeter les paquets malformés. Les paquets XMAS ont tous les drapeaux TCP activés en même temps – impossible dans un trafic réel, utilisé par les scanners de ports (nmap -sX). Les paquets NULL n’ont aucun drapeau – même combat. Ce sont deux astuces de fingerprinting ou d’évasion. Poubelle. 🎄🚫

ct state new tcp flags & (syn|ack) == syn|ack reject with tcp reset

Anti-usurpation : un SYN,ACK qui arrive comme nouvelle connexion signifie que quelqu’un forge de toutes pièces une réponse à une poignée de main TCP. Rejeté avec un TCP RST.

tcp flags & (syn|ack|fin|rst) == rst limit rate 1/second accept
tcp flags & (syn|ack|fin|rst) == rst drop

Protection contre les inondations de RST. Les paquets RST sont légitimes (ils servent à fermer des connexions), mais un déluge de RST est une technique de DoS. On en autorise au maximum un par seconde, le reste part à la poubelle.

ip  saddr @banned4 drop
ip6 saddr @banned6 drop

Vérification des sets de blocage dynamiques alimentés par fail2ban. Ils sont placés avant les règles d’exception K3s, pour qu’une IP bannie ne puisse jamais se faufiler par les exemptions du CIDR des pods plus bas.

{% if 'nextcloud' in group_names %}
ip saddr {{ k3s_pod_cidr }} tcp dport 3306 accept
ip saddr {{ k3s_pod_cidr }} tcp dport 6379 accept
{% endif %}

Une condition Jinja2 – ce bloc n’apparaît que sur les hôtes Nextcloud. Sur les serveurs Nextcloud, MariaDB et Redis tournent comme services de l’hôte (pas dans K3s), les pods doivent donc les joindre via l’IP de l’hôte. Sur les hôtes WordPress, MariaDB tourne dans le cluster sous forme de pod : ces règles sont inutiles et donc omises. 🧠

ip saddr {{ server_ipv4 }} tcp dport { 3000, 10254 } accept

ingress-nginx tourne avec hostNetwork: true, ce qui veut dire qu’il vit dans l’espace de noms réseau de l’hôte. Quand il transmet une requête à Grafana (port 3000) via un ExternalService Kubernetes, l’IP source est l’IP publique de l’hôte lui-même – pas une IP de pod. Idem pour les sondes de santé du kubelet sur le port 10254. On autorise donc l’IP propre de l’hôte, mais uniquement pour ces deux ports précis – pas d’accept général. 🎯

ip saddr {
  0.0.0.0/8, 10.0.0.x/8, 127.0.0.0/8, 169.254.0.0/16,
  172.16.0.x/12, 192.168.0.x/16, 224.0.0.0/4, 240.0.0.0/5
} drop

On rejette toutes les plages sources RFC-1918 et réservées qui arrivent sur l’interface externe. Si un paquet venu de l’Internet public prétend provenir de 10.x.x.x ou de 192.168.x.x, il est usurpé. Les exceptions du CIDR des pods K3s ci-dessus sont placées avant ce bloc justement pour que le trafic légitime des pods ne s’y fasse pas piéger.

icmp type { destination-unreachable, echo-request, time-exceeded, parameter-problem } accept

On n’autorise que les types ICMP réellement nécessaires : ping, traceroute et les signaux de réseau injoignable. Tout le reste (redirect, router-advertisement, etc.) est rejeté.

icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem,
  router-advertisement, router-solicitation,
  nd-neighbor-solicitation, nd-neighbor-advertisement,
  echo-request, echo-reply } accept

ICMPv6 nécessite une liste d’autorisation plus longue, car IPv6 en dépend fondamentalement. Le Neighbor Discovery Protocol (NDP) – l’équivalent IPv6 d’ARP – passe par ICMPv6. Sans ces types, IPv6 ne fonctionne tout simplement pas.

ip  daddr {{ server_ipv4 }} tcp dport { 80, 443 } ct state new accept
ip  daddr {{ server_ipv4 }} udp dport 443          ct state new accept
ip6 daddr {{ server_ipv6 }} tcp dport { 80, 443 } accept
ip6 daddr {{ server_ipv6 }} udp dport 443          accept

Ouverture de HTTP, HTTPS et UDP/443 (QUIC/HTTP3) pour le serveur web. En IPv4 comme en IPv6. C’est la règle UDP qui permet HTTP/3 – les navigateurs le découvrent via Alt-Svc, puis basculent dessus pour les connexions suivantes. 🚀

ip  daddr {{ server_ipv4 }} tcp dport 10022 ct state new accept

SSH sur un port non standard. Le port 22, à ce stade, ce n’est plus que du bruit.

limit rate 2/minute log prefix "nftables DROP IN:  " level warn flags all

Journalisation à débit limité de tout le reste avant le rejet par la politique par défaut. Vous voyez ce qui est bloqué sans inonder le journal du noyau. Le préfixe permet de le retrouver facilement avec grep dans journald.

🔀 Chaîne FORWARD

K3s gère ses propres chaînes KUBE-* pour le routage des services – cette chaîne doit seulement laisser passer le trafic pod-à-pod et pod-à-service dans le CIDR des pods, et bloquer tout le reste. Les sets de blocage sont vérifiés ici aussi, pour que les IP bannies ne puissent pas exploiter le trafic transféré.

📤 Chaîne OUTPUT

Le trafic sortant est lui aussi restreint par un DROP par défaut. Autorisés : DNS, NTP, HTTP/HTTPS pour le téléchargement des paquets et le renouvellement des certificats ACME, SMTP pour l’envoi des e-mails, le serveur d’API K3s sur 6443 et QUIC en sortie. Tout le reste – y compris les connexions sortantes aléatoires qu’un malware pourrait tenter – est rejeté et journalisé.

🏁 En résumé

Le jeu de règles nftables abat beaucoup de travail en relativement peu de lignes. Un seul fichier, double pile IPv4/IPv6, listes de blocage dynamiques natives, suivi de connexions et exceptions adaptées à Kubernetes – le tout dans une unité atomique appliquée proprement à chaque exécution d’Ansible. C’est typiquement le genre de chose qui fait apprécier l’infrastructure as code. 🤓

Le dépôt se trouve sur github.com/aptupgrademe/www_k3s si vous voulez creuser.