Top IPs sources : comment savoir qui matraque son serveur en temps réel ?

Identifier les top IPs sources qui bombardent votre serveur est la première étape indispensable pour endiguer une attaque par déni de service ou un flood applicatif. En 2026, les attaques DDoS évoluent : elles sont de plus en plus distribuées, fragmentées et difficiles à distinguer du trafic légitime. Pourtant, même dans un flux de plusieurs millions de paquets par seconde, une poignée d'adresses IP concentre souvent 80 % du volume abusif. Cet article vous montre comment extraire, analyser et bloquer ces IPs sources de manière chirurgicale, en combinant métriques kernel-level XDP, tableaux nftables et dashboards de monitoring centralisés comme ceux proposés par PAKKT.io.

Pourquoi les top IPs sources sont-elles la clé du diagnostic DDoS

Lors d'une attaque par flood, le volume global (paquets par seconde, bande passante) est rarement uniformément réparti. Une analyse fine révèle toujours une distribution asymétrique : quelques dizaines d'IPs sources génèrent la majorité du trafic, tandis que le reste sert de bruit de fond. Cette réalité s'explique par plusieurs facteurs :

• Botnets mal obfusqués : les serveurs C&C bon marché réutilisent les mêmes pools d'IPs zombie, facilement repérables en triant par volume.
• Amplification DNS/NTP : les réflecteurs publics répondent depuis un petit nombre d'IPs si le flood exploite des requêtes mal randomisées.
• Floods applicatifs concentrés : les attaques par connexion lente (Slowloris, R.U.D.Y.) ou par requête ciblée (login brute-force) partent souvent d'un sous-ensemble d'IPs que le rate-limit global ne suffit pas à bloquer.

En identifiant ces top IPs sources, vous pouvez :

1. Basculer du rate-limit global vers un blocage sélectif, restaurant instantanément le service pour les clients légitimes.
2. Corréler avec la géolocalisation (GeoIP) et les ASN pour détecter des patterns (datacenter louche, pays inhabituel).
3. Alimenter votre blacklist XDP/nftables avec des adresses déjà « brûlées », économisant des cycles CPU sur les prochains floods.

Le dashboard de PAKKT.io affiche en temps réel une carte monde des IPs sources, un classement top pays et un classement top IPs (volume de paquets par IP). Ces vues permettent de passer d'une alerte vague « serveur saturé » à un diagnostic chirurgical « 3 IPs en Chine envoient 90 % des SYN » en quelques secondes.

Collecter les métriques au niveau kernel : XDP et BPF maps

Pour obtenir un classement fiable des top IPs sources, il faut capturer les compteurs avant que le noyau ne consomme du CPU sur les paquets malveillants. C'est le rôle de XDP (eXpress Data Path), qui inspecte chaque paquet au niveau du driver réseau, avant l'allocation de socket buffers.

Architecture du PAKKT Engine

Le PAKKT Engine est un programme XDP unique par interface (attaché avec ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp), qui maintient plusieurs BPF maps :

• pakkt_rules : tableau de 256 règles (port range, protocole, rule_type block/rate_limit/allow_only, max_pps, max_port_pps, min/max packet size).
• pakkt_stats : compteurs par règle (paquets matchés, paquets droppés, bytes total).
• pakkt_ip_blacklist / pakkt_ip_whitelist : hash maps indexées par IP source, synchronisées en double couche avec nftables.
• pakkt_ip_stats : hash map qui incrémente un compteur de paquets pour chaque IP source vue (clé = IPv4/IPv6, valeur = struct { uint64_t packets; uint64_t bytes; }).

La BPF map pakkt_ip_stats est le socle du classement des top IPs sources. À chaque paquet reçu, le programme XDP incrémente atomiquement le compteur associé à l'IP source. L'agent Go (PAKKT Agent) scrute cette map toutes les 30 secondes (heartbeat) et envoie les deltas au panel centralisé via mTLS.

Exemple de dump manuel

Pour vérifier manuellement quelles IPs sont comptabilisées, utilisez bpftool :

bpftool map dump name pakkt_ip_stats
# Sortie :
# key: 0a 00 00 01  value: 2f 4e 00 00 00 00 00 00  # 10.0.0.1 → 20 015 paquets
# key: c0 a8 01 0a  value: ff ff 00 00 00 00 00 00  # 192.168.1.10 → 65 535 paquets

Cette approche stateless (pas de conntrack dans XDP) permet de traiter plusieurs millions de pps avec un overhead négligeable (sub-microseconde par paquet). Le tri et l'agrégation sont déportés sur le panel, ce qui préserve les ressources CPU du serveur protégé.

Analyser et visualiser les top IPs sources depuis le panel centralisé

Les compteurs bruts de la BPF map pakkt_ip_stats sont envoyés toutes les 30 secondes vers le backend PAKKT, qui les stocke dans TimescaleDB (base temps-série PostgreSQL). Le panel web expose trois vues complémentaires :

1. Classement top IPs sources (volume de paquets)

Table triée par nombre de paquets reçus sur la période sélectionnée (dernière heure, dernier jour, dernière semaine). Colonnes affichées :

IP source	Paquets	Bytes	Pays (GeoIP)	ASN	Action rapide
203.0.113.42	1 247 893	64 MB	CN	AS4134	Blacklist XDP
198.51.100.7	987 452	52 MB	RU	AS12389	Blacklist XDP

Le bouton « Blacklist XDP » ajoute l'IP simultanément dans la BPF map pakkt_ip_blacklist (drop instantané en XDP) et dans la table nftables inet pakkt (pour bloquer aussi les paquets qui passeraient par une interface sans XDP). La synchronisation est automatique et prend effet en moins d'une seconde.

2. Carte monde des IPs sources

Visualisation géographique agrégée : chaque pays est coloré en fonction du volume de paquets reçus. Permet de détecter d'un coup d'œil un flood concentré sur une région (par exemple, 95 % du trafic provient de trois pays). En cliquant sur un pays, le panel affiche la liste des IPs sources de ce pays, triée par volume.

3. Top pays (classement par volume)

Tableau récapitulatif : code pays ISO (CN, RU, US, etc.), nombre de paquets, nombre d'IPs distinctes vues. Utile pour distinguer un flood distribué (beaucoup d'IPs, peu de paquets par IP) d'un flood concentré (quelques IPs, beaucoup de paquets par IP).

L'ensemble de ces vues s'appuie sur les données GeoIP enrichies côté backend (base MaxMind GeoLite2, mise à jour hebdomadaire). Aucun traitement GeoIP n'est effectué sur le serveur protégé, préservant ainsi les ressources.

Stratégies de blocage sélectif basées sur les top IPs sources

Une fois les top IPs sources identifiées, plusieurs stratégies de mitigation s'offrent à vous, selon le contexte de l'attaque :

Blocage immédiat en XDP (drop silencieux)

Pour les IPs manifestement malveillantes (volume anormal, pays inhabituel, ASN déjà signalé), ajoutez-les à la blacklist XDP. L'agent PAKKT insère l'IP dans la BPF map pakkt_ip_blacklist, et le programme XDP retourne XDP_DROP dès le premier paquet de cette IP, sans consommer de cycles kernel supplémentaires. Exemple de commande manuelle (si vous gérez l'agent vous-même) :

bpftool map update name pakkt_ip_blacklist key 0xc0a8010a value 0x01
# Bloque 192.168.1.10 (représentation hexa little-endian)

Depuis le panel PAKKT, un simple clic suffit : le backend envoie un ordre mTLS à l'agent, qui met à jour la map et recharge la règle nftables complémentaire (nft add element inet pakkt blacklist_v4 { 192.168.1.10 }). Le drop est donc doublement assuré (XDP + nftables), même si l'interface réseau secondaire ne supporte pas XDP.

Rate-limit ciblé par IP (nftables conntrack)

Si vous souhaitez limiter une IP suspecte sans la bloquer totalement (par exemple, un client légitime derrière un proxy mal configuré), créez une règle nftables de rate-limit par connexion :

nft add rule inet pakkt input ip saddr 203.0.113.42 tcp dport 25565 ct state new limit rate 10/second accept
nft add rule inet pakkt input ip saddr 203.0.113.42 tcp dport 25565 drop

Cette règle autorise 10 nouvelles connexions par seconde depuis 203.0.113.42 sur le port 25565 (Minecraft), et drop le reste. Le compteur ct state new s'appuie sur le conntrack kernel, donc cette approche est stateful et consomme plus de CPU que XDP, mais reste acceptable pour un nombre limité d'IPs « grises ».

Whitelist préemptive (allow_only en XDP)

Si votre service a une liste connue de clients (serveurs amis, IPs d'entreprise), configurez une règle XDP allow_only couplée à la BPF map pakkt_ip_whitelist. Seules les IPs présentes dans cette map seront acceptées ; toutes les autres seront droppées en XDP, quelle que soit leur légitimité apparente. Syntaxe dans le panel PAKKT :

• Règle : port 25565, protocole TCP, rule_type allow_only.
• Whitelist : ajouter manuellement les IPs autorisées (192.0.2.0/24, 198.51.100.0/24, etc.).

Cette stratégie est radicale mais ultra-efficace contre les floods distribués : même un botnet de 100 000 IPs ne pourra générer aucun paquet au-delà du driver réseau.

Tableau récapitulatif des stratégies

Stratégie	Couche	Cas d'usage	Overhead CPU
Blacklist XDP	XDP (L2/L3)	IPs manifestement malveillantes, flood brutal	Négligeable
Rate-limit nftables par IP	nftables (L3/L4 stateful)	IPs suspectes mais potentiellement légitimes	Modéré (conntrack)
Whitelist XDP (allow_only)	XDP (L2/L3)	Service fermé, liste de clients connue	Négligeable
Meter/burst nftables global	nftables (L3/L4 stateful)	Rate-limit applicatif (HTTP, login)	Modéré à élevé

Intégration avec les outils de monitoring et d'investigation

Les métriques des top IPs sources exportées par PAKKT peuvent être croisées avec d'autres sources de données pour affiner le diagnostic :

Corrélation avec les logs applicatifs

Si vous hébergez un serveur de jeu (Minecraft, CS:GO, FiveM) géré par Pterodactyl, comparez les top IPs sources PAKKT avec les logs de connexion du panel. Une IP qui envoie 500 000 paquets mais n'apparaît jamais dans les logs de connexion est probablement un scanner ou un flood SYN.

Enrichissement ASN et WHOIS

Le panel PAKKT affiche l'ASN (Autonomous System Number) de chaque IP source. Un ASN de datacenter (AS16276 OVH, AS14061 DigitalOcean, AS16509 Amazon) peut indiquer un serveur légitime ou un bot hébergé. Un ASN résidentiel (FAI grand public) avec un volume anormal est un signe de malware sur un PC infecté. Vous pouvez exporter la liste des top IPs sources (CSV) et la croiser avec des bases CERT-FR ou MITRE ATT&CK pour vérifier si ces IPs sont déjà signalées dans des campagnes actives.

API publique PAKKT pour automatisation

L'API REST de PAKKT (authentification par clé API) expose un endpoint GET /api/v1/agents/{agent_id}/top_ips?period=1h&limit=100 qui retourne un JSON des top 100 IPs sources sur la dernière heure. Vous pouvez scripter un webhook vers votre Discord, Slack ou système de ticketing (WHMCS à venir) pour alerter automatiquement votre équipe lorsqu'une IP dépasse un seuil (par exemple, 100 000 paquets en 5 minutes).

Exemple de script bash utilisant l'API PAKKT pour blacklister automatiquement les IPs dépassant 200 000 pps :

#!/bin/bash
API_KEY="votre_cle_api"
AGENT_ID="12345"
THRESHOLD=200000

curl -s -H "Authorization: Bearer $API_KEY" \
  "https://pakkt.io/api/v1/agents/$AGENT_ID/top_ips?period=5m&limit=10" \
| jq -r ".ips[] | select(.packets > $THRESHOLD) | .ip" \
| while read ip; do
  curl -X POST -H "Authorization: Bearer $API_KEY" \
    -d "{\"ip\":\"$ip\"}" \
    "https://pakkt.io/api/v1/agents/$AGENT_ID/blacklist"
  echo "Blacklisted $ip"
done

Ce type d'automatisation transforme le classement des top IPs sources en outil proactif : vous ne réagissez plus manuellement à chaque spike, vous configurez une politique de réponse automatique calibrée sur vos seuils métier.

Limites et complémentarité avec les solutions de scrubbing cloud

PAKKT.io opère au niveau kernel du serveur protégé, pas en amont du réseau. Cela signifie que le trafic malveillant arrive jusqu'à votre interface réseau avant d'être droppé en XDP. Si votre lien physique (1 Gbps, 10 Gbps) est saturé par un flood volumétrique (100 Gbps+), PAKKT ne pourra pas empêcher la saturation de la bande passante — il limitera seulement l'impact CPU et applicatif sur le serveur.

Dans ce scénario, PAKKT est complémentaire aux solutions de scrubbing cloud (CloudFlare, OVH VAC, Arbor Networks) :

• Le scrubbing cloud filtre en amont les gros volumes (centaines de Gbps), ne laissant passer que le trafic « propre ».
• PAKKT, en couche kernel sur le serveur, affine la protection : rate-limit applicatif, blocage de patterns spécifiques (flags TCP suspects, tailles de paquets anormales), whitelist stricte pour les services critiques.

Les top IPs sources identifiées par PAKKT peuvent même être remontées manuellement à votre provider de scrubbing cloud pour améliorer ses règles de filtrage. Par exemple, si PAKKT détecte que 90 % du flood provient de l'ASN AS12345, vous pouvez demander à votre scrubbing cloud de rate-limiter ou bloquer cet ASN en amont, réduisant ainsi la charge arrivant jusqu'au serveur.

En résumé : PAKKT ne remplace pas un scrubbing cloud sur un lien saturé, mais il rend le serveur résilient même si le scrubbing laisse passer du trafic abusif (faux positifs, attaques applicatives sous le radar volumétrique). Pour plus de détails sur l'architecture de PAKKT, consultez le blog PAKKT.

Conclusion

Identifier les top IPs sources qui bombardent votre serveur transforme une alerte générique « serveur sous attaque » en diagnostic actionnable. En combinant les compteurs XDP temps réel (BPF map pakkt_ip_stats), le classement centralisé du panel PAKKT (GeoIP, ASN, volume par IP) et les stratégies de blocage sélectif (blacklist XDP, rate-limit nftables, whitelist allow_only), vous reprenez le contrôle sur le trafic entrant. Les métriques kernel-level offrent une granularité sub-microseconde et un overhead CPU négligeable, même face à plusieurs millions de pps. Cette approche pragmatique, appuyée sur des outils open source (XDP, eBPF, nftables) et une orchestration centralisée, vous permet de protéger vos services critiques sans sacrifier la performance ni la transparence pour vos utilisateurs légitimes.

FAQ

Comment différencier une IP légitime d'une IP malveillante dans le classement des top IPs sources ?

Croisez le volume de paquets avec les logs applicatifs : une IP qui envoie 500 000 paquets mais n'apparaît jamais dans les logs de connexion est probablement un scanner ou un flood SYN. Vérifiez aussi la géolocalisation (pays inhabituel pour votre service) et l'ASN (datacenter suspect). Le panel PAKKT affiche ces métadonnées en un clic. En cas de doute, appliquez un rate-limit nftables ciblé (10-50 connexions/seconde) plutôt qu'un blocage total, et observez le comportement sur quelques minutes.

Puis-je exporter la liste des top IPs sources pour l'intégrer à mon SIEM ou firewall périmétrique ?

Oui. Le panel PAKKT propose une export CSV (bouton « Export » en haut du tableau des top IPs). Vous pouvez aussi utiliser l'API REST GET /api/v1/agents/{agent_id}/top_ips pour récupérer les données en JSON et les ingérer automatiquement dans votre SIEM (Splunk, Elastic, Graylog) ou firewall (pfSense, FortiGate). Un script cron qui appelle l'API toutes les 5 minutes et met à jour une blacklist centralisée est un pattern courant chez nos utilisateurs.

Quelle est la différence entre bloquer une IP en XDP et bloquer une IP en nftables dans PAKKT ?

XDP drop l'IP au niveau du driver réseau, avant même l'allocation de socket buffers : overhead sub-microseconde, aucun impact CPU applicatif. nftables drop l'IP après la stack réseau kernel, mais avant l'application : overhead légèrement supérieur (quelques microsecondes), mais permet du stateful (conntrack, rate-limit par connexion). PAKKT synchronise automatiquement les deux couches : une IP blacklistée via le panel est ajoutée simultanément dans la BPF map XDP pakkt_ip_blacklist et dans le set nftables inet pakkt blacklist_v4. Ainsi, même si une interface ne supporte pas XDP (driver ancien, interface virtuelle), le blocage reste effectif en nftables.