GeoIP réseau : cartographiez vos attaques en temps réel (2026)

Le GeoIP réseau est devenu un outil incontournable pour cartographier l'origine géographique des attaques DDoS et des connexions suspectes en temps réel. Face à la multiplication des vecteurs d'attaque — amplification DNS, flood SYN, botnet distribué — identifier d'où provient le trafic malveillant permet de prendre des décisions rapides : bloquer un pays entier, isoler un ASN, ou ajuster dynamiquement les règles de filtrage XDP et nftables. Cet article détaille comment exploiter le GeoIP au niveau kernel, pourquoi la visualisation en temps réel sur une carte monde change la donne, et comment orchestrer cette donnée avec un firewall stateful et des règles XDP performantes.

Pourquoi intégrer la donnée GeoIP au cœur de la stack réseau

Traditionnellement, l'enrichissement GeoIP intervient dans les logs applicatifs (Apache, Nginx, panels web), souvent après coup. Cette approche passive ne convient plus face à des attaques volumétriques : lorsque plusieurs millions de paquets par seconde frappent une interface réseau, il est trop tard pour analyser les logs a posteriori. Intégrer le GeoIP au niveau kernel — dans les programmes XDP ou dans les règles nftables — offre deux avantages critiques :

Décision instantanée : un paquet peut être drop avant même d'atteindre la stack TCP/IP si son IP source appartient à un pays bloqué, avec une latence sub-microseconde.
Réduction de la charge : en filtrant à la couche 2 (XDP) ou 3 (nftables), on évite l'allocation de ressources pour le conntrack, les buffers skb et l'éventuel parsing applicatif.

Concrètement, nftables supporte nativement les ensembles (sets) et maps qui peuvent contenir des milliers de préfixes IP enrichis par métadonnée (pays, ASN). Un programme XDP peut interroger une BPF map préalablement chargée avec les blocs CIDR par pays. PAKKT.io automatise cette synchronisation : la plateforme maintient une base GeoIP actualisée (MaxMind GeoLite2 ou équivalent) et peuple en continu les BPF maps et les ensembles nftables de chaque agent, sans intervention manuelle.

Architecture classique : BPF map + nftables set

L'approche la plus courante combine deux couches :

XDP stateless : une BPF map de type LPM_TRIE (Longest Prefix Match) contient les blocs IPv4 et IPv6 indexés par pays. Le programme XDP consulte cette map dès réception du paquet. Si le pays est banni (valeur 0 = drop), le paquet est immédiatement rejeté avec XDP_DROP. Latence typique : quelques dizaines de nanosecondes par lookup.
nftables stateful : un ensemble nommé blacklist_geoip regroupe les préfixes interdits. Une règle en tête de chaîne input de la table inet pakkt teste l'IP source contre cet ensemble et applique un verdict (drop, log, rate-limit par pays). Cette couche gère le conntrack et les métadonnées TCP (flags, états).

Exemple de règle nftables filtrant le trafic d'un ensemble GeoIP :

nft add set inet pakkt blacklist_geoip { type ipv4_addr; flags interval; }
nft add rule inet pakkt input ip saddr @blacklist_geoip counter drop

La même logique s'étend à IPv6 et à l'enrichissement par ASN (Autonomous System Number), utile pour bloquer des plages entières d'hébergeurs cloud notoires dans les campagnes de botnet.

Visualiser les attaques sur une carte monde en temps réel

Une fois la donnée GeoIP intégrée au kernel, il reste à l'exploiter pour la supervision. Le dashboard GeoIP temps réel de PAKKT agrège les compteurs par pays depuis chaque agent (via les métriques BPF et nftables), les stocke dans TimescaleDB et les affiche sur une carte interactive. Cela permet de :

Détecter visuellement les botnets distribués : un flash simultané de trafic depuis plusieurs continents indique une attaque coordonnée.
Identifier les anomalies géographiques : un serveur de jeu européen qui reçoit subitement 90 % de son trafic depuis l'Asie de l'Est peut révéler une campagne d'amplification DNS ou un scanning massif.
Ajuster les règles en un clic : depuis la carte, un opérateur peut bannir un pays entier temporairement (whitelist les IP légitimes, blocage du reste) ou activer un rate-limit différencié par zone géographique.

Métriques exposées par agent et agrégation centrale

L'agent PAKKT envoie toutes les 30 secondes (heartbeat) un snapshot JSON contenant :

Top 10 des IP sources, avec pour chacune : nombre de paquets drop XDP, acceptés, rate-limités, pays ISO 3166-1 alpha-2, ASN.
Top 10 des pays par volume (paquets, connexions TCP nouvelles, octets si disponible via nftables meter).
Règles XDP actives : pour chaque rule_id, compteur de hits, max_pps atteint, violations.
Règles nftables : nombre de paquets/octets par handle (extraits via nft --json list ruleset).

Ces métriques alimentent un schéma TimescaleDB optimisé pour les séries temporelles (partitions par jour, rétention configurable). La carte monde interpole les données sur une projection Mercator ou équirectangulaire, avec des bulles proportionnelles au volume d'attaque. Un clic sur un pays affiche le détail des top IPs sources et l'évolution temporelle du trafic (graphe Packets/s sur 1h, 6h, 24h).

Cas d'usage concret : mitigation DDoS game-server

Étape	Action	Outil
1. Détection	Pic de 5 Mpps sur UDP 27015 (CS2), origine multiple pays	Dashboard GeoIP PAKKT, alerte > 2 Mpps
2. Analyse	95 % du trafic provient de 3 pays : CN, RU, BR	Carte temps réel + top IPs
3. Décision	Blocage temporaire (1 h) de ces 3 pays en XDP	Ajout automatique dans BPF map `pakkt_geoip_block`
4. Validation	Le trafic chute à 200 kpps (baseline légitime EU/US)	Graphe temps réel, latency monitoring
5. Affinage	Whitelist de 2 IP CN légitimes (joueurs VPN), reste bloqué	Règle XDP allow_only + liste blanche IP

Ce workflow, de la détection à la mitigation, s'exécute en moins de 60 secondes grâce à la synchronisation mTLS entre le panel et l'agent, et à la mise à jour atomique des BPF maps (pas de redémarrage du programme XDP).

Orchestrer GeoIP, XDP et nftables : architecture double couche

Le vrai défi réside dans la cohérence entre les deux couches de filtrage. Un paquet peut traverser XDP sans être drop (pays autorisé) mais ensuite être bloqué par nftables (rate-limit dépassé, flag TCP invalide). Inversement, un paquet drop en XDP ne génère aucune trace nftables. La clé est d'orchestrer les métadonnées GeoIP de manière bidirectionnelle :

Blacklist IP partagée : une IP ajoutée à la blacklist PAKKT (manuellement ou via API) est simultanément insérée dans la BPF map pakkt_blacklist (XDP) et dans l'ensemble nftables blacklist_ip. Ainsi, le drop intervient au plus tôt (XDP), mais si l'IP passe (race condition, règle désactivée), nftables la bloque en fallback.
Enrichissement ASN : PAKKT maintient une table ASN → pays → blocs CIDR. Un opérateur peut bloquer l'ASN 64496 (faux exemple) entièrement. Cette règle se traduit en plusieurs milliers de préfixes injectés dans la BPF map et l'ensemble nftables.
Rate-limit différencié par zone : nftables supporte les maps : meta geoip country { CN : 10/second, RU : 20/second, default : 100/second }. (Note : cette syntaxe exacte dépend de la version nftables et du module nft_geoip ; PAKKT génère les règles équivalentes via des ensembles multiples si nécessaire.) Le rate-limit XDP reste global par port (stateless, max_port_pps), mais nftables peut affiner au niveau connexion.

Exemple de configuration nftables avec enrichissement GeoIP

#!/usr/sbin/nft -f

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

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

    # Drop immédiat des pays à haut risque
    ip saddr @geoip_high_risk counter drop

    # Rate-limit par IP source (toutes zones confondues)
    ct state new limit rate over 50/second burst 100 packets counter drop

    # Accepter le reste
    counter accept
  }
}

Cette table inet pakkt est isolée : elle ne conflite pas avec les règles Docker (table nat chaîne DOCKER), fail2ban (table filter chaîne f2b-sshd), ni iptables-persistent (legacy). L'agent PAKKT gère atomiquement les ajouts/suppressions d'éléments dans geoip_high_risk sans recharger l'intégralité du ruleset.

Monitoring et audit log GeoIP

Chaque modification de règle GeoIP (ajout pays, suppression ASN, whitelist IP) génère une entrée dans l'audit log PAKKT :

Timestamp UTC
User (clé API ou compte panel)
Type d'action (geoip_block_country, geoip_allow_asn)
Détail (code ISO pays, numéro ASN, liste CIDR affectée)
Agent concerné (ou all si règle globale template)

Cet audit est stocké côté panel et consultable via l'API publique PAKKT, permettant l'intégration avec des SIEM tiers (Splunk, Elastic, Graylog). La corrélation entre événements GeoIP et pics de trafic TimescaleDB facilite l'investigation post-mortem : « Quel pays a été bloqué à 14h37 UTC ? Quel a été l'impact sur le débit accepté ? »

Limites techniques et bonnes pratiques

Le GeoIP n'est jamais précis à 100 %. Les bases publiques (GeoLite2, IP2Location) ont une marge d'erreur de 5 à 15 % au niveau pays, et bien plus au niveau ville. Les VPN, proxies et Tor faussent la localisation. Trois règles d'or pour exploiter le GeoIP réseau sans casser le trafic légitime :

Toujours maintenir une whitelist IP explicite : avant de bannir un pays entier, identifiez les IP légitimes (clients VIP, partenaires, CDN origin) et ajoutez-les à la whitelist. L'agent PAKKT consulte d'abord la whitelist (lookup BPF map prioritaire) avant de tester la blacklist GeoIP.
Activer le mode log avant le mode drop : nftables permet log prefix "GEOIP_DROP: " counter drop. Pendant une phase de test, utilisez log … counter accept pour observer quel volume de trafic légitime serait impacté.
Mettre à jour la base GeoIP régulièrement : les blocs IP changent de propriétaire, de pays, d'ASN. PAKKT synchronise automatiquement sa base chaque semaine (MaxMind publie des mises à jour bi-mensuelles). Un agent déconnecté plus de 7 jours risque de travailler sur des données obsolètes ; le panel envoie une alerte heartbeat manquant au bout de 5 minutes.

Complémentarité avec le scrubbing cloud

Le filtrage GeoIP au niveau kernel est complémentaire d'une solution de scrubbing cloud (CloudFlare Magic Transit, OVH VAC, Arbor Networks). Le scrubbing opère en amont, dévie le trafic via BGP Anycast, nettoie les attaques volumétriques (> 100 Gbps) et renvoie le trafic propre vers votre serveur. PAKKT intervient sur le serveur, une fois le trafic arrivé à l'interface réseau : il bloque les résidus (attaques < seuil scrubbing, false negatives, scanning post-DDoS) et applique des règles métier fines (port range, packet size, rate-limit par port). Combiner les deux approches offre une défense en profondeur :

Couche	Technologie	Rôle
Amont (réseau)	Scrubbing BGP Anycast	Absorption DDoS volumétrique multi-Tbps
Kernel (serveur)	XDP + nftables (PAKKT)	Filtrage fin, GeoIP, rate-limit par port, whitelist/blacklist
Application	Panel (Pterodactyl), game-server	Logique métier, gestion utilisateurs

Pour en savoir plus sur l'architecture kernel XDP et nftables, consultez la documentation officielle du projet netfilter : netfilter.org/documentation.

Conclusion

Intégrer la donnée GeoIP réseau directement dans les programmes XDP et les règles nftables transforme la défense anti-DDoS : au lieu de réagir après coup, vous bloquez le trafic malveillant avant même qu'il ne consomme des ressources CPU ou mémoire. La visualisation temps réel sur une carte monde, couplée à l'orchestration automatique des BPF maps et ensembles nftables, permet une mitigation en moins d'une minute. Combinée à une whitelist IP rigoureuse et à des mises à jour régulières de la base GeoIP, cette approche offre un rapport efficacité/latence imbattable pour protéger serveurs de jeu, APIs, infrastructures critiques — sans quitter le kernel Linux.

FAQ

Peut-on bloquer un ASN entier en XDP sans impacter les performances ?

Oui. Une BPF map de type LPM_TRIE supporte plusieurs dizaines de milliers de préfixes avec un temps de lookup constant (O(log n) sur la profondeur de l'arbre, typiquement < 50 ns). Bloquer un ASN se traduit par l'injection de tous ses blocs CIDR dans la map. L'agent PAKKT automatise cette expansion ASN → préfixes et met à jour la map sans redémarrage du programme XDP, garantissant zéro downtime et overhead négligeable (< 1 % CPU même sous 10 Mpps).

Comment gérer les faux positifs GeoIP (VPN, proxies) ?

Maintenez une whitelist IP explicite consultée en priorité par le programme XDP (BPF map pakkt_whitelist). Toute IP whitelistée bypass les règles GeoIP, rate-limit et blacklist. PAKKT synchronise cette whitelist en double couche (XDP + nftables set) pour garantir qu'aucun paquet légitime ne soit drop, même si la base GeoIP classe l'IP dans un pays banni. Activez également le mode log temporaire avant de passer en mode drop, afin d'identifier les IP légitimes à whitelister.

Le GeoIP fonctionne-t-il aussi bien en IPv6 qu'en IPv4 ?

Oui. Les bases GeoIP modernes (MaxMind GeoLite2, IP2Location) fournissent des blocs IPv6. Les BPF maps XDP et les ensembles nftables supportent nativement ipv6_addr avec le flag interval pour les préfixes. L'agent PAKKT charge simultanément les deux versions (IPv4 et IPv6) dans des maps distinctes, et le programme XDP inspecte le champ EtherType (0x0800 vs 0x86DD) pour router le lookup vers la bonne map. Les performances restent identiques : le LPM_TRIE est aussi efficace sur des préfixes /64 IPv6 que sur des /24 IPv4.

GeoIP et carte monde du trafic réseau : visualiser d'où viennent les attaques