Compteurs nftables en prod : lisez vos drops (2026)

Les compteurs nftables sont des outils de diagnostic indispensables pour toute infrastructure réseau en production, notamment lorsqu'on exploite des serveurs de jeu, des API ou des services exposés sur Internet. En 2026, malgré la montée en puissance de XDP et eBPF pour la protection au niveau kernel, nftables reste la pierre angulaire du firewall stateful Linux. Pourtant, la plupart des administrateurs déploient leurs règles sans activer les compteurs — et perdent ainsi toute visibilité sur les paquets réellement bloqués, acceptés ou ratés. Cet article vous montre comment instrumenter correctement vos règles nftables avec des compteurs, interpréter les drops en production et bâtir une routine de monitoring efficace qui complète parfaitement une stack moderne XDP + nftables.

Pourquoi instrumenter vos règles nftables avec des compteurs

Déployer un firewall nftables sans compteurs, c'est naviguer à l'aveugle. Vous savez que des règles existent, mais vous ignorez si elles déclenchent, combien de paquets elles traitent et à quelle fréquence elles bloquent du trafic légitime ou malveillant.

Visibilité sur les drops réels

Les compteurs nftables incrémentent deux métriques par règle : le nombre de paquets (packets) et le volume en octets (bytes). Quand une règle termine par drop ou reject, le compteur vous indique combien de connexions ou de paquets ont été refusés depuis le dernier redémarrage (ou reset manuel). En production, cette donnée est cruciale pour :

Détecter une attaque DDoS en cours — un pic soudain sur une règle de rate-limit ou de blocage générique.
Identifier des faux positifs — trafic légitime bloqué par erreur de configuration.
Mesurer l'efficacité d'une règle de mitigation — une règle qui bloque zéro paquet peut être retirée.
Auditer le respect des politiques de sécurité — vérifier qu'un port sensible (SSH, RDP) n'est sollicité que depuis les IP autorisées.

Décorréler XDP et nftables

Dans une architecture moderne comme celle déployée par PAKKT.io, le trafic traverse d'abord le programme XDP en tête d'interface (couche 2–3, stateless, drop ultra-rapide), puis — si le paquet est passé — nftables prend le relais pour le suivi de connexion (ct state) et les règles stateful. Les compteurs nftables permettent donc de distinguer :

Les paquets jamais arrivés à nftables (droppés par XDP) — visibles via bpftool map dump sur la map XDP.
Les paquets rejetés par nftables malgré le passage de XDP — signe d'une politique de firewall stateful, d'un rate-limit TCP ou d'un filtrage avancé (TCP flags, conntrack, meter).

Sans compteurs sur chaque couche, impossible de diagnostiquer où se situe le point de blocage. Une attaque SYN flood peut par exemple être absorbée à 90 % par XDP et les 10 % résiduels bloqués par un ct state invalid drop dans nftables — seule la lecture des compteurs révèle cette répartition.

Activer et lire les compteurs nftables en ligne de commande

Nftables propose une syntaxe unifiée pour associer un compteur à n'importe quelle règle. Le compteur s'incrémente avant le verdict final (accept, drop, reject, etc.).

Ajouter un compteur à une règle existante

Imaginons une règle de rate-limit classique pour un serveur Minecraft (port 25565 TCP) :

nft add rule inet pakkt input tcp dport 25565 ct state new limit rate 50/second accept

Pour instrumenter cette règle avec un compteur, insérez simplement le mot-clé counter avant le verdict :

nft add rule inet pakkt input tcp dport 25565 ct state new counter limit rate 50/second accept

Ou bien, pour une règle de drop générique sur ICMP :

nft add rule inet pakkt input icmp type echo-request counter drop

Lister les règles avec compteurs

La commande de base pour afficher une table et ses compteurs est :

nft list ruleset

Exemple de sortie partielle (table inet pakkt) :

table inet pakkt {
  chain input {
    type filter hook input priority 0; policy drop;
    
    # Règle 1 : accept established/related
    ct state established,related counter packets 1847293 bytes 2847192837 accept
    
    # Règle 2 : rate-limit SYN 25565
    tcp dport 25565 ct state new counter packets 4821 bytes 289260 limit rate 50/second accept
    
    # Règle 3 : drop ICMP
    icmp type echo-request counter packets 18452 bytes 739264 drop
  }
}

Chaque règle affiche packets X bytes Y. Pour surveiller l'évolution, vous pouvez scripter une boucle :

watch -n 2 'nft list ruleset | grep counter'

Réinitialiser les compteurs

Pour repartir de zéro après un test ou un incident, utilisez :

nft reset counters table inet pakkt

Ou bien, pour cibler une seule chaîne :

nft reset counters inet pakkt input

Attention : la réinitialisation est globale à la table ou la chaîne. Si vous monitorez vos compteurs dans un système de métriques (Prometheus, TimescaleDB), pensez à horodater le reset pour éviter les doublons.

Interpréter les compteurs : scénarios typiques en production

Détecter un flood SYN ou UDP

Vous constatez une montée en flèche du compteur sur la règle de rate-limit (limit rate 50/second) ou sur une règle de drop générique. Exemple :

tcp dport 25565 ct state new counter packets 482193 bytes 28931580 limit rate 50/second accept

Si packets augmente de plusieurs milliers par seconde, c'est le signe d'une attaque. Comparez avec le compteur XDP (via bpftool map dump name pakkt_drops) : si XDP a déjà drop une partie du trafic, nftables voit la queue résiduelle. Si le compteur nftables explose alors que XDP est stable, l'attaque utilise peut-être des IP sources variées (pas encore blacklistées) ou contourne les règles XDP (taille de paquet, protocole exotique).

Identifier des faux positifs

Une règle trop restrictive peut bloquer du trafic légitime. Exemple : vous avez bloqué tous les pings ICMP, mais votre monitoring externe utilise justement ICMP pour les healthchecks.

icmp type echo-request counter packets 18452 bytes 739264 drop

Si ce compteur grimpe régulièrement et que vous constatez des alertes "host unreachable" sur votre outil de supervision, ajustez la règle pour autoriser ICMP depuis les IP de votre monitoring :

nft insert rule inet pakkt input ip saddr 203.0.113.10 icmp type echo-request counter accept

Le compteur de la règle initiale cessera d'augmenter, confirmant que le faux positif est corrigé.

Mesurer l'efficacité d'une règle de mitigation

Après avoir déployé une règle anti-spoofing ou une liste noire temporaire, surveillez son compteur. Si packets reste à zéro après 24 heures, soit la menace s'est tarie, soit la règle est mal placée dans la chaîne (ordre d'évaluation). Inversement, un compteur qui augmente prouve que la règle protège activement.

Audit de conformité et logging sélectif

Les compteurs permettent de repérer les règles sensibles à logger. Plutôt que de journaliser chaque paquet (overhead important), loguez uniquement les règles dont le compteur dépasse un seuil :

nft add rule inet pakkt input tcp dport 22 ct state new counter limit rate 10/minute log prefix "SSH_ATTEMPT " drop

Ici, le compteur incrémente pour chaque tentative SSH, mais seul un échantillon (10/minute) génère une entrée de log. En croisant compteurs et logs, vous obtenez une vision exhaustive sans saturer /var/log/syslog.

Automatiser la collecte : exporter les compteurs vers un TSdb

En 2026, le monitoring manuel via nft list ruleset est insuffisant pour une infrastructure de production. Les compteurs doivent être exportés vers une base de données de séries temporelles (TimescaleDB, InfluxDB, Prometheus) et visualisés dans Grafana.

Script d'export JSON

Nftables supporte nativement le format JSON via l'option -j :

nft -j list ruleset > /tmp/nft_counters.json

Un script Python ou Go peut ensuite parser ce JSON, extraire les valeurs packets et bytes par règle (identifiées par handle ou commentaire), puis pousser les métriques vers votre TSdb. Exemple minimaliste en Bash + jq :

#!/bin/bash
nft -j list ruleset | jq -r '
  .nftables[] 
  | select(.rule?) 
  | .rule 
  | select(.expr[]?.counter?) 
  | {
      table: .table, 
      chain: .chain, 
      handle: .handle, 
      packets: (.expr[] | select(.counter?) | .counter.packets), 
      bytes: (.expr[] | select(.counter?) | .counter.bytes)
    }
' | while read -r line; do
  # Push vers InfluxDB, Prometheus Pushgateway, etc.
  echo "$line"
done

Intégration avec PAKKT.io

La plateforme PAKKT.io collecte déjà les métriques XDP (paquets droppés, rate-limit hits par règle) via son agent Go et les stocke dans TimescaleDB. En complément, l'agent peut parser les compteurs nftables de la table inet pakkt toutes les 30 secondes (synchronisé avec le heartbeat mTLS) et les remonter au panel centralisé. Ainsi, vous visualisez sur une même timeline :

Les drops XDP (couche 2–3, stateless, plusieurs millions de pps).
Les drops nftables (couche 3–4, stateful, conntrack, rate-limit TCP).
Les accepts (trafic légitime passé par les deux couches).

Cette double instrumentation permet de diagnostiquer précisément où une attaque est bloquée et d'ajuster la politique en temps réel depuis le dashboard PAKKT.

Alerting sur seuils de compteurs

Configurez des alertes Prometheus/Grafana sur les métriques dérivées des compteurs. Exemple : si rate(nft_drop_packets[1m]) > 10000, déclencher une alerte "DDoS suspect sur port 25565". Combiné aux alertes XDP, vous obtenez une détection multi-couches avec peu de faux positifs.

Bonnes pratiques : nommer et commenter vos règles

Nftables permet d'ajouter un comment à chaque règle, ce qui facilite énormément la lecture des compteurs dans les logs et les exports JSON.

nft add rule inet pakkt input tcp dport 25565 ct state new counter comment "Minecraft rate-limit" limit rate 50/second accept

Lors de l'export JSON, le champ comment sera présent, vous permettant d'identifier la règle sans ambiguïté. Adoptez une convention de nommage cohérente :

PROTO_PORT_ACTION (ex. TCP_22_DROP, UDP_19132_RATELIMIT).
Incluez le numéro de ticket ou d'incident si la règle est temporaire (INCIDENT_2026_03_15_BLOCK_ASN12345).

Cette discipline rend les audits de sécurité et les post-mortems beaucoup plus rapides.

Cas d'usage avancé : corrélation XDP + nftables + GeoIP

Imaginons un scénario réel : vous hébergez un serveur FiveM (GTA V RP) sur le port 30120 UDP. Vous observez une latence inhabituelle et suspectez un flood. Voici comment les compteurs nftables s'inscrivent dans le diagnostic :

XDP : vérifiez la map pakkt_drops via bpftool. Si vous voyez des millions de paquets droppés sur le port 30120, l'attaque est absorbée en amont.
Nftables : listez les compteurs de la règle UDP 30120. Si le compteur augmente modérément, c'est que XDP laisse passer un flux résiduel (IP sources variées, non encore blacklistées).
GeoIP : dans le dashboard PAKKT, consultez la carte monde. Si 80 % du trafic provient d'un pays inattendu (ex. Chine alors que votre communauté est francophone), créez une règle nftables temporaire de drop géographique (via ipset + module geoip ou liste manuelle d'AS).
Ajustement : ajoutez ces IP/AS à la blacklist XDP (synchronisée automatiquement par l'agent PAKKT). Le compteur nftables cesse d'augmenter, confirmant que le trafic malveillant est désormais bloqué dès la couche XDP.

Les compteurs nftables jouent ici le rôle de canari : tant qu'ils grimpent, la protection XDP n'est pas complète. Une fois stabilisés, vous savez que la politique XDP + nftables couvre l'attaque.

Erreurs fréquentes et pièges à éviter

Oublier de réinitialiser après un test

Si vous testez une nouvelle règle et la supprimez ensuite, le compteur associé disparaît. Mais si vous la recréez plus tard, le compteur repart de zéro — vous perdez l'historique. Solution : exportez les compteurs vers votre TSdb avant toute modification de ruleset.

Confondre packets et connexions

Un compteur nftables incrémente par paquet, pas par connexion. Une seule connexion TCP peut représenter des milliers de paquets (établissement, données, FIN). Pour suivre les connexions, utilisez conntrack -L en parallèle, ou activez le module ct count de nftables (disponible depuis nftables 0.9.3).

Ordre des règles et priorité des compteurs

Les règles nftables s'évaluent dans l'ordre d'insertion (handle croissant). Si une règle accept sans compteur est placée avant une règle drop avec compteur, le trafic concerné ne sera jamais compté. Vérifiez l'ordre via nft -a list ruleset (option -a affiche les handles) et réorganisez si nécessaire avec nft insert rule ... position X.

Oublier la table inet vs ip/ip6

La table inet couvre IPv4 et IPv6 simultanément. Si vous créez des compteurs dans une table ip seulement, le trafic IPv6 ne sera pas instrumenté. Privilégiez inet pour une couverture exhaustive, sauf si vous avez des politiques IPv4/IPv6 radicalement différentes.

Conclusion

Les compteurs nftables transforment votre firewall d'une boîte noire en un outil de diagnostic précis et quantifiable. En 2026, dans un contexte où XDP et eBPF absorbent la majorité des attaques volumétriques, nftables conserve son rôle central pour le filtrage stateful, le rate-limit par connexion et l'audit de conformité. Instrumenter chaque règle avec un compteur, automatiser la collecte vers un TSdb et corréler ces métriques avec les drops XDP et les données GeoIP — comme le propose PAKKT.io — permet de bâtir une posture de sécurité kernel-level robuste, observable et ajustable en temps réel. Ne naviguez plus à l'aveugle : lisez vos drops, comprenez vos règles et optimisez votre protection.

FAQ

Comment différencier un drop XDP d'un drop nftables dans les métriques ?

Consultez d'abord la map BPF XDP (bpftool map dump name pakkt_drops) pour voir les paquets rejetés en amont. Ensuite, listez les compteurs nftables (nft list ruleset). Si le compteur XDP augmente mais pas celui de nftables, le trafic est stoppé dès la couche 2–3. Si les deux compteurs augmentent, le paquet traverse XDP (accepté ou rate-limité) puis est évalué par nftables. Dans le dashboard PAKKT, les deux métriques sont affichées côte à côte sur la même timeline pour faciliter la corrélation.

Peut-on exporter les compteurs nftables vers Prometheus sans agent custom ?

Oui, via le nftables exporter Prometheus (projet communautaire nftables_exporter sur GitHub). Il parse nft -j list ruleset toutes les X secondes et expose les compteurs au format Prometheus sur :9630/metrics. Vous pouvez ensuite scraper ce endpoint depuis votre serveur Prometheus. Attention : l'exporter ne gère pas la réinitialisation automatique des compteurs ; vous devez scripter un nft reset counters périodique si vous souhaitez des métriques en delta plutôt qu'en absolu. L'agent PAKKT intègre cette logique nativement et synchronise les resets avec le cycle de heartbeat (30 secondes).

Comment éviter que les compteurs saturent après plusieurs semaines de production ?

Les compteurs nftables sont stockés en mémoire kernel (type u64, soit 18 446 744 073 709 551 615 paquets max). En pratique, même sur un serveur à très fort trafic (plusieurs millions de pps), il faudrait des années pour saturer. Toutefois, pour des raisons de lisibilité et d'analyse, réinitialisez les compteurs à intervalles réguliers (hebdomadaire ou mensuel) en les exportant d'abord vers votre TSdb. Ainsi, vous conservez l'historique dans Grafana tout en gardant des valeurs compréhensibles dans nft list ruleset. Un cron quotidien (0 0 * * * nft reset counters table inet pakkt) suffit pour la plupart des cas d'usage.

Monitorer les compteurs nftables en prod : packets, bytes, drop rate