Auditer une règle firewall qui droppe trop : méthode de debug

Lorsqu'on mène une analyse d'un debug firewall règle, la première source de confusion surgit quand une règle de filtrage bloque non seulement le trafic malveillant mais aussi des paquets légitimes. Vos joueurs se déconnectent, vos API ne répondent plus ou le téléchargement des ressources d'un serveur de jeu s'interrompt : un drop trop large met en péril la disponibilité du service tout en vous laissant croire que la protection fonctionne.

Ce guide détaille une méthode de debug systématique pour identifier quelle règle firewall droppe trop, comprendre pourquoi et ajuster le filtre sans rouvrir la porte aux attaquants. Les techniques s'appliquent aux pare-feu Linux modernes (nftables, iptables, XDP/eBPF) et s'appuient sur les compteurs natifs du noyau, les outils en ligne de commande et l'analyse du trafic en temps réel.

Symptômes d'une règle firewall qui droppe trop

Avant de plonger dans les compteurs, identifiez les symptômes concrets qui révèlent un drop excessif :

• Déconnexions partielles : certains joueurs restent connectés tandis que d'autres, souvent derrière le même FAI ou la même région, perdent brutalement l'accès.
• Timeouts sur les requêtes HTTP/HTTPS : les API externes ou les webhooks reçoivent des erreurs de timeout alors que le service est en ligne.
• Ressources non téléchargées : sur FiveM ou Minecraft, les clients récupèrent une partie des fichiers puis stagnent, signe que des paquets UDP ou TCP légitimes sont jetés en cours de transfert.
• Échec du handshake TCP : les connexions nouvelles échouent alors que les connexions déjà établies continuent de fonctionner, indiquant un drop sur les paquets SYN ou ACK.
• Volume bloqué disproportionné : les compteurs du pare-feu montrent un nombre de paquets droppés qui dépasse largement le volume attendu d'une attaque.

Ces indices orientent l'analyse : si seuls certains pays ou plages IP sont touchés, la règle cible peut-être une plage CIDR trop large ou un blocage géographique mal calibré. Si les coupures surviennent lors de pics de trafic, un rate-limit global du port ou par IP source est probablement trop serré.

Méthode manuelle de debug d'une règle firewall nftables

Nftables fournit des compteurs par règle et par chaîne. La première étape consiste à lister toutes les règles actives avec leurs statistiques :

nft list ruleset -a

L'option -a affiche les handles numériques et les compteurs de paquets et d'octets. Repérez la règle suspecte en comparant les volumes bloqués à ceux acceptés sur le même port ou protocole. Par exemple, une règle drop sur le port 30120 UDP avec 500 000 paquets droppés alors que la règle accept correspondante n'en compte que 10 000 signale un déséquilibre.

Activer les logs sur une règle spécifique

Ajoutez temporairement une directive log avant l'action drop pour capturer les IP sources et ports concernés :

nft insert rule inet filter input udp dport 30120 limit rate 100/second log prefix "DROP-30120: " drop

Le préfixe personnalisé facilite le filtrage dans /var/log/kern.log ou journalctl -k. Le rate-limit 100/second évite de saturer les logs lors d'un flood massif. Analysez ensuite les entrées :

journalctl -k --grep="DROP-30120" --since "5 minutes ago" | awk '{print $10}' | sort | uniq -c | sort -rn | head -20

Cette commande extrait les IP sources (champ SRC), les trie par fréquence et affiche les 20 IP les plus droppées. Si vous reconnaissez des adresses de joueurs réguliers ou des plages de votre hébergeur (DNS, NTP, passerelles), la règle bloque du trafic légitime.

Vérifier l'état conntrack des paquets droppés

Nftables peut jeter des paquets invalid ou new qui appartiennent en réalité à des connexions établies, en raison d'une table conntrack saturée ou mal dimensionnée. Vérifiez les statistiques globales :

conntrack -S

Si insert_failed ou drop augmente rapidement, le noyau abandonne des entrées. Les règles nftables qui filtrent sur ct state new dropperont alors des paquets ESTABLISHED ou RELATED classés à tort comme invalides. Augmentez les limites conntrack dans /etc/sysctl.conf :

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536

Puis appliquez sysctl -p et observez si les drops diminuent.

Analyser les limites par IP source

Une règle limit rate X/second burst Y sans le drapeau per source applique un plafond global : dès que le total des paquets du port dépasse ce seuil, tous les clients sont affectés. Listez la règle complète :

nft list table inet filter -a | grep -A2 "limit rate"

Si la limite est globale et que le trafic légitime cumulé des joueurs dépasse régulièrement le seuil, deux options s'offrent à vous : augmenter le plafond global ou basculer vers une limite par IP source en ajoutant ip saddr dans un set avec quota. La méthode manuelle requiert de créer un set dynamique et d'y référencer chaque IP avec son propre compteur, ce qui alourdit la syntaxe.

Débugger une règle XDP qui droppe trop

Les programmes XDP attachés à l'interface réseau filtrent avant la pile TCP/IP du noyau. Ils ne disposent pas d'état conntrack ni de logs natifs, ce qui complique le debug. La première étape consiste à vérifier quel programme est actif :

ip -details link show dev eth0

La ligne prog/xdp indique le programme chargé et son ID. Pour lister les maps BPF associées et consulter les compteurs :

bpftool net show
bpftool map dump name <nom_de_map>

Les maps BPF stockent généralement les règles et les compteurs de paquets passés (XDP_PASS) et droppés (XDP_DROP). Si votre programme XDP intègre plusieurs règles, comparez les compteurs de chaque entrée : un déséquilibre flagrant (millions de drops pour quelques milliers de pass) signale une règle trop stricte.

Capturer le trafic en amont du filtre XDP

XDP opère au niveau du driver réseau, avant que tcpdump ne puisse voir les paquets droppés. Pour contourner cette limite, attachez temporairement un programme XDP de debug qui journalise tous les paquets avant de les passer à la pile, ou utilisez xdpdump (disponible dans xdp-tools) :

xdpdump -i eth0 -w /tmp/xdp_capture.pcap

Cet outil capture les paquets au niveau XDP, y compris ceux droppés, et les écrit dans un fichier pcap que vous analysez ensuite avec Wireshark ou tcpdump. Filtrez par port et IP pour identifier les flux bloqués à tort.

Limites intrinsèques du filtrage XDP stateless

XDP ne suit pas les connexions : il décide du sort de chaque paquet de manière indépendante. Une règle qui limite les paquets UDP sur le port 30120 à 10 000 PPS global jettera les paquets au-delà de ce seuil, qu'ils proviennent d'un attaquant unique ou de cent joueurs légitimes téléchargeant simultanément des ressources. Un rate-limit XDP par IP source atténue ce problème, mais il requiert une map BPF dimensionnée pour stocker l'état de chaque IP, avec un coût mémoire et CPU proportionnel au nombre d'IP distinctes.

Si votre base de joueurs dépasse régulièrement le plafond global en trafic légitime, envisagez de relever le seuil ou de déplacer le filtrage vers nftables, où vous pouvez combiner état conntrack et limites par source plus finement.

Identifier les plages IP et pays légitimes touchés

Un blocage géographique ou une règle CIDR mal calibrée peuvent couper des régions entières de joueurs. Collectez les IP sources droppées depuis les logs nftables ou les maps BPF, puis effectuez une résolution GeoIP :

geoiplookup 203.0.113.42

Ou utilisez une base GeoIP MaxMind et un script pour traiter un fichier d'IP en masse. Si vous constatez que des IP françaises, belges ou canadiennes sont bloquées alors que ces pays hébergent vos joueurs principaux, votre liste de plages CIDR ou votre règle de blocage pays doit être ajustée.

Les faux positifs géographiques proviennent souvent de :

• Listes de plages CIDR obsolètes ou trop larges qui englobent des blocs réattribués.
• VPN et proxies légitimes utilisés par les joueurs, classés dans un pays bloqué.
• Bases GeoIP imprécises : une IP peut basculer de pays lors de réattributions de blocs.

Pour contourner ce problème, maintenez une whitelist manuelle des plages IP de vos joueurs connus ou des serveurs partenaires (Discord bots, API de modération), qui passe avant toute règle de blocage géographique ou rate-limit.

Ajuster une règle de rate-limit trop stricte

Les règles de limitation de débit protègent contre les floods, mais un seuil trop bas coupe le trafic légitime. Voici une démarche empirique pour calibrer le plafond :

1. Mesurer le trafic légitime de référence : observez le volume de paquets par seconde sur le port en question pendant une période normale (pas d'attaque). Utilisez nft list ruleset pour relever les compteurs avant et après une fenêtre de 60 secondes, ou iftop, vnstat et bpftool pour une vue en temps réel.
2. Ajouter une marge de 50 à 100 % au pic observé : si le trafic nominal atteint 8 000 PPS, fixez le plafond à 12 000 ou 16 000 PPS pour absorber les variations (événements ingame, afflux de joueurs).
3. Tester en production avec logs : activez le logging temporaire sur la nouvelle limite et surveillez les drops pendant 24 à 48 heures. Si des IP légitimes continuent d'être bloquées, relevez encore le seuil ou basculez vers une limite par IP source.
4. Limiter par IP source quand c'est pertinent : une limite globale protège la bande passante totale du port, une limite par IP empêche un seul client de monopoliser les ressources. Combinez les deux : un plafond global élevé (par exemple 50 000 PPS) et un plafond par IP modéré (500 PPS) bloque les attaquants isolés sans affecter la capacité totale.

Exemple de règle nftables combinant les deux approches :

nft add rule inet filter input udp dport 30120 ct state new limit rate over 50000/second drop
nft add rule inet filter input udp dport 30120 ct state new meter rate_per_ip { ip saddr limit rate over 500/second } drop
nft add rule inet filter input udp dport 30120 ct state new accept

La première règle jette tout paquet qui dépasse 50 000 PPS globalement. La seconde utilise un meter (compteur par IP source dynamique) pour jeter les paquets des IP qui dépassent 500 PPS individuellement. Les paquets qui passent ces deux filtres sont acceptés.

Cas particulier des connexions derrière CGNAT

Les joueurs derrière un Carrier-Grade NAT partagent la même IP publique. Un rate-limit par IP source de 500 PPS peut couper dix joueurs partageant cette IP, chacun générant 50 PPS. Pour détecter ce scénario, croisez les logs de votre serveur de jeu (identifiants uniques des joueurs) avec les IP sources droppées : si plusieurs comptes distincts apparaissent derrière la même IP publique, relevez le seuil par IP ou excluez cette IP via une whitelist.

Automatiser le debug avec les compteurs en temps réel depuis le panel PAKKT

La méthode manuelle décrite ci-dessus fonctionne, mais elle impose de se connecter en SSH à chaque serveur, de maîtriser la syntaxe nftables et bpftool, et de jongler entre les logs, les maps BPF et les commandes ip link. PAKKT centralise ces informations dans un dashboard unique pour tous vos serveurs, avec des compteurs rafraîchis toutes les 30 secondes.

Pour identifier une règle XDP ou nftables qui droppe trop, rendez-vous dans Protection → XDP ou Protection → nftables depuis le panel. Chaque règle affiche ses compteurs de paquets passés et droppés. Si une règle rate_limit sur le port 30120 UDP montre 2 millions de drops pour seulement 100 000 paquets passés, c'est un signal clair de sur-blocage.

Le Dashboard du serveur concerné vous donne ensuite :

• Le graphique de trafic avec une timeline précise : sélectionnez à la souris la plage horaire du pic de drops pour isoler l'événement.
• Le top IP sources : les adresses qui génèrent le plus de paquets, y compris ceux bloqués. Si vous reconnaissez des IP de joueurs ou de services légitimes, ajoutez-les à la whitelist en un clic.
• La carte monde GeoIP : visualisez les pays d'origine du trafic bloqué. Si votre base de joueurs est française et que vous constatez des drops massifs depuis la France, votre règle est trop stricte.
• Le top ports : y compris les ports sans règle, pour repérer du trafic légitime qui frappe un port que vous avez bloqué par erreur.

Pour ajuster une règle XDP rate_limit, cliquez sur la règle concernée dans Protection → XDP, modifiez les champs Max PPS · port (global) ou Max PPS · par IP source, puis enregistrez. La nouvelle limite est appliquée immédiatement, sans rechargement du programme XDP ni interruption de service. Les compteurs se remettent à jour dans les 30 secondes suivantes, vous permettant de vérifier en temps réel l'effet de votre ajustement.

Si vous protégez un serveur FiveM, RedM, Minecraft ou CS2, consultez la Marketplace : les modèles validés par PAKKT intègrent des plafonds prudents, testés sur des environnements de production. Vous les ouvrez, ajustez les valeurs (par exemple relever le plafond global de 20 000 à 30 000 PPS si votre serveur héberge 200 joueurs simultanés), puis déployez sur un ou plusieurs serveurs en un clic. Les règles sont stockées sur la plateforme et réappliquées automatiquement au redémarrage de l'agent : aucun risque de perdre votre configuration après une mise à jour du noyau ou un reboot.

Les règles nftables du panel affichent également, pour chaque règle, la liste des IP sources des paquets droppés. Si cette liste contient des adresses que vous souhaitez protéger (par exemple l'IP publique de votre infrastructure de monitoring), basculez-les immédiatement dans Protection → Contrôle d'accès → Whitelist. La whitelist passe toujours en premier, avant toute règle de rate-limit ou de blocage pays.

PAKKT propose un essai gratuit de 7 jours jusqu'à 5 serveurs, sans carte bancaire. L'abonnement coûte ensuite 3 € par serveur protégé et par mois, sans limite de bande passante ni palier caché. Vous gardez votre hébergeur actuel, installez l'agent en une commande générée par le panel, et pilotez toute votre flotte depuis une interface centralisée. Plus besoin de maintenir des scripts de surveillance, de parser les logs kern.log ou de jongler avec bpftool : les compteurs, les graphiques et les listes d'IP droppées sont déjà là, mis à jour en continu.

Conclusion

Debugger une règle firewall qui droppe trop repose sur trois piliers : lire les compteurs par règle, identifier les IP et pays légitimes bloqués, et ajuster les seuils en fonction du trafic réel observé. Les outils natifs du noyau (nft, bpftool, conntrack, xdpdump) fournissent toutes les données nécessaires, mais leur utilisation impose une charge opérationnelle élevée dès que vous gérez plusieurs serveurs. PAKKT centralise ces compteurs dans un dashboard unique, applique les ajustements sans SSH et garantit que vos règles survivent aux redémarrages, vous permettant de consacrer votre temps à l'optimisation réelle de la protection plutôt qu'à la maintenance de la syntaxe.

FAQ

Comment savoir si une règle nftables bloque du trafic légitime sans activer les logs ?

Comparez les compteurs de paquets droppés et acceptés sur le même port avec nft list ruleset -a. Un déséquilibre important (par exemple 10 fois plus de drops que d'accept) indique un problème. Croisez ensuite avec les métriques applicatives : si votre serveur de jeu affiche des timeouts ou des déconnexions pendant que les compteurs de drops explosent, la règle est trop stricte. Vous pouvez également interroger la table conntrack avec conntrack -L pour vérifier que les connexions établies ne sont pas jetées à tort.

Une limite XDP par IP source protège-t-elle d'un flood distribué sur des milliers d'IP ?

Non. Si chaque IP attaquante reste sous le seuil individuel (par exemple 400 PPS alors que la limite est 500 PPS par IP), elles passeront toutes. Seul un plafond global du port peut limiter le volume total, mais il jettera aussi les paquets des clients légitimes une fois le seuil atteint. Pour une vraie protection contre un flood distribué, combinez une limite globale élevée (qui absorbe le trafic légitime total) avec une limite par IP modérée, et envisagez un système de bannissement automatique comme le Bouclier Auto de PAKKT, qui détecte les IP dont les paquets sont massivement droppés et les bannit temporairement.

Pourquoi mes règles XDP ne remontent-elles pas de compteurs après un redémarrage du serveur ?

Les programmes XDP et leurs maps BPF résident en mémoire : un reboot du serveur les efface. Si vous avez attaché manuellement un programme XDP avec ip link set dev eth0 xdp obj ..., vous devez le recharger à chaque démarrage via un script systemd. Les compteurs redémarrent également à zéro. Avec PAKKT, l'agent réapplique automatiquement toutes les règles XDP et nftables au démarrage, et les compteurs recommencent à s'incrémenter dès que le trafic reprend, sans intervention manuelle.