Comprendre conntrack et les états TCP pour un firewall Linux stateful

Le conntrack firewall Linux est le système de suivi de connexions (connection tracking) au cœur de netfilter, l'infrastructure de filtrage réseau du noyau Linux. Lorsqu'un administrateur configure un pare-feu stateful avec nftables ou iptables, conntrack enregistre chaque flux TCP/UDP/ICMP pour autoriser les paquets de réponse légitimes et bloquer les tentatives d'intrusion. Comprendre son fonctionnement interne devient indispensable dès que l'on dépasse quelques milliers de connexions simultanées ou que l'on souhaite protéger efficacement un serveur exposé à Internet. Ce guide détaille les mécanismes de conntrack, ses tables en mémoire, ses limites sous charge, et les stratégies d'optimisation pour 2026.

Qu'est-ce que conntrack et pourquoi Linux en a-t-il besoin ?

Conntrack (connection tracking) est un module du noyau Linux qui maintient une table d'état pour chaque flux réseau traversant le système. Contrairement à un filtrage stateless qui examine chaque paquet isolément, un firewall stateful s'appuie sur conntrack pour mémoriser l'état d'une connexion TCP (SYN, SYN-ACK, ESTABLISHED, FIN, etc.) ou d'une pseudo-connexion UDP (premier datagramme sortant, réponse attendue dans un délai fixe).

Différence entre filtrage stateless et stateful

Un filtre stateless (règle DROP sur port 80 sans condition d'état) bloque ou autorise chaque paquet individuellement. Le filtrage stateful, lui, autorise automatiquement les paquets de retour d'une connexion initiée localement. Exemple concret : votre serveur initie une requête DNS (UDP port 53) vers 8.8.8.8 ; sans conntrack, il faudrait une règle explicite permettant la réponse UDP depuis 8.8.8.8:53 vers votre_ip:port_source. Avec conntrack, ct state established,related suffit pour accepter toutes les réponses légitimes.

Modules et dépendances du noyau

Conntrack repose sur plusieurs modules kernel :

• nf_conntrack : module principal, chargé automatiquement dès qu'une règle stateful est ajoutée.
• nf_conntrack_ipv4 / nf_conntrack_ipv6 : suivi IPv4/IPv6.
• nf_conntrack_ftp, nf_conntrack_sip, etc. : helpers pour protocoles applicatifs complexes (ouverture de ports dynamiques).
• nf_nat : pour la traduction d'adresse (NAT/masquerade) qui nécessite conntrack.

Sur une distribution récente (kernel 5.x ou supérieur), ces modules se chargent à la demande. Vérifiez leur présence avec :

lsmod | grep nf_conntrack
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

La première commande liste les modules actifs, les deux suivantes affichent le nombre de connexions suivies et la limite maximale. Par défaut, nf_conntrack_max est souvent dimensionné pour un usage desktop (65536 entrées), insuffisant pour un serveur web ou un serveur de jeu à fort trafic.

Architecture interne de conntrack : tables et hashmaps

Conntrack stocke les états de connexion dans une table de hachage (hashtable) en mémoire kernel. Chaque entrée correspond à un tuple unique : (src_ip, src_port, dst_ip, dst_port, protocole). Pour TCP, conntrack suit les flags (SYN, ACK, FIN, RST) et les numéros de séquence pour détecter les anomalies.

États de connexion TCP

État conntrack	Description
NEW	Premier paquet du flux (SYN sans SYN-ACK précédent)
ESTABLISHED	Connexion établie, échanges bidirectionnels
RELATED	Nouveau flux lié à une connexion existante (ex: FTP data channel)
INVALID	Paquet malformé ou incohérent (flags TCP impossibles, séquence hors fenêtre)
UNTRACKED	Paquet explicitement exclu du tracking via règle notrack

Pour UDP et ICMP, les états sont simplifiés : NEW pour le premier paquet, ESTABLISHED dès qu'une réponse est détectée dans le délai de timeout (120 secondes par défaut pour UDP).

Timeouts et garbage collection

Chaque entrée conntrack possède un timer. Une connexion TCP ESTABLISHED expire après 5 jours d'inactivité (432 000 secondes), une connexion UDP après 120 secondes, un flux ICMP après 30 secondes. Ces valeurs sont ajustables via /proc/sys/net/netfilter/nf_conntrack_*_timeout_*.

sysctl net.netfilter.nf_conntrack_tcp_timeout_established
# net.netfilter.nf_conntrack_tcp_timeout_established = 432000

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600
# Réduit à 1 heure pour libérer plus vite les entrées

Le garbage collector kernel parcourt régulièrement la table pour supprimer les entrées expirées. Sous forte charge (millions de pps), ce nettoyage peut consommer du CPU. Réduire les timeouts accélère la libération mais expose à des coupures prématurées de connexions légitimes longues.

Limites de la table conntrack

La taille maximale de la table est définie par nf_conntrack_max. Lorsque cette limite est atteinte, conntrack rejette les nouvelles connexions (erreur "nf_conntrack: table full, dropping packet" dans dmesg). Calculez nf_conntrack_max en fonction de votre RAM :

# Recommandation : 1 entrée conntrack ~ 300 octets
# Serveur 16 GB RAM, on alloue 512 MB pour conntrack
# 512 MB / 300 octets ≈ 1 800 000 entrées

sysctl -w net.netfilter.nf_conntrack_max=1800000
sysctl -w net.netfilter.nf_conntrack_buckets=450000
# nf_conntrack_buckets = nf_conntrack_max / 4

Augmenter nf_conntrack_buckets (nombre de buckets de la hashmap) améliore les performances de recherche mais consomme plus de mémoire. Cet ajustement doit être fait avant le chargement du module ou via boot parameter nf_conntrack.nf_conntrack_buckets=450000.

Utiliser conntrack avec nftables : exemples pratiques

Nftables est le successeur d'iptables, unifiant IPv4/IPv6 et offrant une syntaxe plus claire. PAKKT.io configure automatiquement une table nftables isolée inet pakkt pour éviter tout conflit avec Docker, fail2ban ou iptables-persistent. Voici comment construire manuellement des règles stateful avec conntrack.

Politique par défaut et règles de base

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Autoriser loopback
nft add rule inet filter input iif lo accept

# Autoriser connexions établies et liées
nft add rule inet filter input ct state established,related accept

# Rejeter paquets invalides
nft add rule inet filter input ct state invalid drop

Ces trois règles constituent la base d'un firewall stateful. La règle ct state established,related autorise automatiquement les réponses à vos requêtes sortantes (DNS, HTTP, SSH client, etc.). La règle ct state invalid bloque les paquets malformés (tentatives de TCP hijacking, scans furtifs).

Protéger un serveur de jeu avec rate-limit par connexion

Un serveur Minecraft (TCP 25565) exposé à Internet reçoit souvent des connexions abusives. Nftables + conntrack permettent de limiter le nombre de nouvelles connexions par seconde et par IP source :

nft add rule inet filter input tcp dport 25565 ct state new \
  limit rate over 10/second burst 20 packets drop

nft add rule inet filter input tcp dport 25565 ct state new accept

Ici, une IP source peut initier jusqu'à 10 nouvelles connexions par seconde avec un burst de 20. Au-delà, les SYN sont droppés silencieusement. Cette approche est complémentaire au rate-limit XDP (qui filtre en amont, stateless, au niveau paquet brut). PAKKT combine XDP stateless + nftables stateful pour une défense en profondeur : XDP bloque les gros floods volumétriques (plusieurs millions de pps), nftables affine le filtrage par état de connexion.

Utiliser les meters pour un rate-limit par IP

Les meters nftables (équivalent des sets dynamiques) permettent de créer des quotas par IP source sur une fenêtre glissante :

nft add set inet filter rate_limit_ssh { type ipv4_addr \; size 65536 \; flags dynamic,timeout \; timeout 60s \; }

nft add rule inet filter input tcp dport 22 ct state new \
  add @rate_limit_ssh { ip saddr limit rate over 5/minute } drop

nft add rule inet filter input tcp dport 22 ct state new accept

Chaque IP peut ouvrir 5 nouvelles connexions SSH par minute. L'entrée expire après 60 secondes d'inactivité. Ce mécanisme protège contre les brute-force SSH sans bloquer les utilisateurs légitimes réessayant après une faute de frappe.

Intégration avec PAKKT : table inet pakkt isolée

PAKKT déploie automatiquement une table inet pakkt avec priorité négative (priority -150) pour s'exécuter avant les autres règles. Exemple de règle générée par l'agent PAKKT pour protéger un port de jeu :

table inet pakkt {
  set blacklist_ips {
    type ipv4_addr
    flags interval
    elements = { 192.0.2.123, 198.51.100.0/24 }
  }

  chain input {
    type filter hook input priority -150; policy accept;

    # Blacklist IP (XDP + nft double-couche)
    ip saddr @blacklist_ips drop

    # Rate-limit global port 25565
    tcp dport 25565 ct state new limit rate over 100/second drop

    # Rate-limit par connexion (meter burst)
    tcp dport 25565 ct state new meter port_25565 { ip saddr limit rate over 50/second burst 100 packets } drop

    # Accepter connexions légitimes
    tcp dport 25565 ct state new,established accept
  }
}

Le set blacklist_ips est synchronisé avec la BPF map XDP, garantissant qu'une IP blacklistée dans le panel PAKKT est bloquée à la fois au niveau XDP (sub-microseconde) et au niveau nftables (état de connexion). Les administrateurs peuvent gérer ces règles via l'API PAKKT ou directement dans le dashboard centralisé.

Optimisation et troubleshooting de conntrack en production

Sur un serveur à forte charge (hébergeur de jeux, proxy, API publique), conntrack peut devenir un goulot d'étranglement. Voici les leviers d'optimisation et les outils de diagnostic.

Augmenter nf_conntrack_max et buckets

Comme vu précédemment, ajustez nf_conntrack_max en fonction de la RAM disponible. Pour un serveur dédié 32 GB, visez 3 à 4 millions d'entrées :

echo 4000000 > /proc/sys/net/netfilter/nf_conntrack_max
echo 1000000 > /sys/module/nf_conntrack/parameters/hashsize
# hashsize (buckets) doit être modifié au boot ou via modprobe

Ajoutez dans /etc/modprobe.d/nf_conntrack.conf :

options nf_conntrack hashsize=1000000

Puis rechargez le module (attention, cela réinitialise la table) :

modprobe -r nf_conntrack
modprobe nf_conntrack

Réduire les timeouts pour libérer plus vite les entrées

Si vous hébergez des serveurs de jeu avec beaucoup de connexions courtes (requêtes query, pings), réduisez les timeouts UDP et ICMP :

sysctl -w net.netfilter.nf_conntrack_udp_timeout=60
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=120
sysctl -w net.netfilter.nf_conntrack_icmp_timeout=10

Pour TCP, réduire nf_conntrack_tcp_timeout_established en dessous de 3600 secondes est risqué (coupure de connexions SSH/FTP longues). Privilégiez l'augmentation de nf_conntrack_max d'abord.

Exclure certains flux du tracking avec notrack

Pour du trafic local à très haut volume (scraping interne, monitoring Prometheus, logs), désactiver conntrack réduit la charge CPU :

nft add rule inet filter prerouting ip saddr 10.0.0.0/8 ip daddr 10.0.0.0/8 notrack
nft add rule inet filter output ip saddr 10.0.0.0/8 ip daddr 10.0.0.0/8 notrack

Les paquets marqués notrack ne seront jamais insérés dans la table conntrack. Attention : toute règle stateful (ct state) les ignorera. Cette technique est réservée aux flux internes maîtrisés.

Diagnostiquer les problèmes avec conntrack-tools

Le paquet conntrack-tools fournit l'utilitaire conntrack pour inspecter et manipuler la table en temps réel :

apt install conntrack  # Debian/Ubuntu
dnf install conntrack-tools  # RHEL/Rocky

# Afficher toutes les connexions
conntrack -L

# Filtrer par IP source
conntrack -L -s 203.0.113.42

# Supprimer une connexion spécifique
conntrack -D -s 203.0.113.42 -p tcp --dport 25565

# Statistiques globales
conntrack -S

La commande conntrack -S affiche les compteurs de recherche, insertion, suppression, collisions de hash. Un taux de collisions élevé indique qu'il faut augmenter hashsize.

Surveiller les métriques avec le dashboard PAKKT

PAKKT.io collecte automatiquement les métriques conntrack (via /proc/sys/net/netfilter/ et conntrack -S) et les affiche dans le dashboard centralisé. Vous visualisez en temps réel le taux d'utilisation de la table, les pics de nouvelles connexions, et les drops liés à "table full". Le moteur d'alerte déclenche une notification Webhook si nf_conntrack_count dépasse 90 % de nf_conntrack_max, vous permettant d'ajuster la configuration avant saturation.

Combiner XDP et conntrack : défense en profondeur

L'architecture recommandée pour 2026 combine trois couches :

1. XDP (PAKKT Engine) : rate-limit stateless au niveau driver réseau, bloque les floods volumétriques (SYN flood, UDP amplification) avant qu'ils ne consomment des ressources kernel. Jusqu'à 256 règles par interface, filtre par port, protocole, taille de paquet, max_pps global et par port.
2. Nftables + conntrack : filtrage stateful, rate-limit par connexion (meter burst), validation des flags TCP, blocage des états INVALID. Complémentaire à XDP pour les attaques applicatives (slowloris, connection exhaustion).
3. Application : rate-limit applicatif (ex: fail2ban sur SSH, plugin anti-bot Minecraft), chiffrement TLS, authentification forte.

PAKKT orchestre les deux premières couches depuis un panel unique, avec synchronisation automatique des blacklist IP entre BPF map XDP et set nftables. Pour des détails techniques sur l'intégration XDP/eBPF, consultez la documentation officielle du kernel Linux.

En production, cette approche hybride permet de tenir plusieurs millions de pps tout en maintenant un suivi de connexion précis pour les flux légitimes. L'impact CPU reste inférieur à 5 % sur hardware moderne (Xeon Gold, EPYC), et la latence ajoutée par conntrack est négligeable (quelques microsecondes par paquet) comparée à la latence réseau.

Conntrack reste un pilier incontournable de la sécurité réseau Linux en 2026. Maîtriser son dimensionnement, ses timeouts et son intégration avec nftables permet de construire des pare-feux stateful robustes, capables de protéger aussi bien des serveurs web que des infrastructures de jeu à fort trafic. En combinant conntrack avec XDP/eBPF pour le pré-filtrage stateless, les administrateurs disposent d'une stack kernel complète, performante et open-source, pilotable via des outils modernes comme PAKKT.

FAQ

Quelle différence entre ct state established et ct state related dans nftables ?

ct state established correspond aux paquets faisant partie d'une connexion déjà établie (ex: réponses HTTP d'un serveur web vers lequel vous avez initié une requête). ct state related désigne un nouveau flux lié à une connexion existante, typiquement les canaux de données FTP (port 20) ouverts dynamiquement par le canal de contrôle FTP (port 21), ou les messages ICMP "port unreachable" en réponse à un datagramme UDP. Les deux états sont généralement autorisés ensemble (ct state established,related accept) pour permettre les communications bidirectionnelles légitimes.

Comment savoir si ma table conntrack est saturée et provoque des drops ?

Consultez dmesg | grep nf_conntrack pour détecter les messages "nf_conntrack: table full, dropping packet". Comparez cat /proc/sys/net/netfilter/nf_conntrack_count avec nf_conntrack_max : si le ratio dépasse 90 %, augmentez nf_conntrack_max et hashsize. Utilisez conntrack -S pour vérifier les compteurs insert_failed et drop. Le dashboard PAKKT affiche ces métriques en temps réel et déclenche des alertes avant saturation.

Peut-on désactiver complètement conntrack pour améliorer les performances ?

Oui, mais vous perdez tout filtrage stateful : impossible d'utiliser ct state dans nftables, pas de NAT, pas de suivi de connexion. Cette approche est réservée aux routeurs purement stateless ou aux serveurs mono-service (ex: serveur DNS autoritatif répondant uniquement sur UDP 53 sans règles complexes). Pour la majorité des cas (serveur web, jeu, API), gardez conntrack activé et optimisez sa configuration (augmenter nf_conntrack_max, réduire les timeouts, exclure le trafic interne avec notrack). XDP/eBPF (PAKKT Engine) permet de filtrer en amont sans toucher à conntrack, offrant les performances du stateless avec la sécurité du stateful en couche 2.