Botnets IoT Mirai : stoppez-les avec XDP (2026)

Les botnets IoT XDP représentent en 2026 la menace volumétrique la plus critique pour les infrastructures exposées sur Internet. Héritiers de Mirai, ces réseaux d'objets connectés compromis bombardent ports SSH, Telnet, HTTP et gaming avec des débits qui saturent en quelques secondes les firewalls traditionnels. Seul le filtrage kernel-level par XDP/eBPF offre la vitesse nécessaire pour bloquer des millions de paquets par seconde avant qu'ils n'atteignent la pile réseau. Cet article détaille les techniques de mitigation XDP, nftables et BPF maps pour neutraliser Mirai et ses variantes directement dans le pilote réseau de votre serveur Linux.

Anatomie d'un botnet IoT Mirai moderne : vecteurs d'attaque 2026

Mirai a marqué 2016 en exploitant des mots de passe par défaut sur caméras IP et routeurs domestiques. Dix ans plus tard, les clones actuels ciblent des vecteurs élargis :

SSH brute-force à haut débit : 22/tcp bombardé par des dizaines de milliers d'IPs simultanées, chacune tentant des combinaisons root:root, admin:admin à 100–500 connexions/seconde.
Telnet (23/tcp) et TR-069 (7547/tcp) : protocoles de gestion jamais désactivés sur caméras, NAS et CPE FTTH déployés en masse.
Exploitation de CVE obsolètes : endpoints HTTP (/cgi-bin/luci, /shell?cat) sur firmware non patchés, conduisant à l'exécution distante de code.
Amplification DDoS réfléchie : une fois compromis, les bots deviennent relais DNS, NTP ou Memcached pour amplifier les attaques contre des tiers.

Les bots infectés envoient des paquets SYN à cadence maximale (plusieurs millions de pps par botnet), souvent forgés avec des adresses source aléatoires (IP spoofing). La pile réseau Linux classique, qui traite chaque paquet jusqu'à netfilter dans le noyau, s'effondre dès 100 000 pps : CPU saturé, table de conntrack pleine, services légitimes inaccessibles.

Pourquoi netfilter seul ne suffit plus

Netfilter (iptables/nftables) intervient après l'allocation de la sk_buff dans le noyau. Chaque paquet malveillant consomme CPU et mémoire avant d'être jeté. À 500 000 pps, le coût du simple passage dans la pile dépasse les 8 cœurs modernes. XDP, au contraire, examine et drop les paquets dans le pilote réseau, avant toute allocation : latence sub-microseconde, overhead négligeable.

Déploiement d'une défense XDP/eBPF contre botnets IoT

Le filtrage XDP s'articule autour d'un programme eBPF attaché à l'interface réseau. PAKKT.io fournit un moteur XDP pré-compilé (PAKKT Engine) qui charge en mémoire jusqu'à 256 règles simultanées pilotées par BPF maps. Voici l'architecture recommandée pour bloquer Mirai :

1. Blacklist IP dynamique en BPF map

Chaque tentative brute-force SSH détectée (via un parseur de logs ou fail2ban) alimente une BPF map de type BPF_MAP_TYPE_HASH indexée par adresse IPv4 source. Le programme XDP effectue une recherche O(1) :

if (bpf_map_lookup_elem(&blacklist_ips, &src_ip)) {
    return XDP_DROP;
}

Résultat : chaque paquet provenant d'une IP blacklistée est jeté à la vitesse du pilote (plusieurs millions de pps sur une NIC 10 GbE moderne), sans jamais atteindre la pile TCP/IP. PAKKT synchronise automatiquement cette BPF map avec la blacklist centralisée du panel, et injecte une règle nftables complémentaire pour les cas où un paquet contourne XDP (trafic local ou interface sans XDP).

2. Rate-limit par port en BPF map

Pour protéger SSH sans bloquer les administrateurs légitimes, configurez une règle de type rate_limit sur 22/tcp avec max_port_pps = 200. Le PAKKT Engine maintient en BPF map un compteur par seconde glissante :

u64 *counter = bpf_map_lookup_elem(&port_rate, &key);
if (counter && *counter > max_port_pps) {
    return XDP_DROP;
}
__sync_fetch_and_add(counter, 1);
return XDP_PASS;

Dès que le seuil est franchi, les paquets excédentaires sont droppés instantanément. Les connexions légitimes (< 200 pps cumulé) passent normalement vers netfilter pour inspection stateful.

3. Filtrage par taille de paquet

Les attaques Mirai génèrent souvent des paquets SYN minimaux (54 octets Ethernet+IP+TCP sans payload) ou des floods UDP à taille fixe. Configurez min_packet_size = 60 et max_packet_size = 1500 pour rejeter les anomalies :

u16 pkt_len = data_end - data;
if (pkt_len < rule->min_size || pkt_len > rule->max_size) {
    return XDP_DROP;
}

Cette heuristique élimine les outils de flood scriptés qui n'ajustent jamais la MTU.

4. Whitelist des IPs de confiance

Inversement, une BPF map whitelist_ips force XDP_PASS immédiat pour les plages d'administration (VPN d'entreprise, IP de backup), court-circuitant toute règle de rate-limit ou blacklist. PAKKT gère la double couche : whitelist XDP + règle nftables ip saddr @whitelist_set accept dans la table inet pakkt.

Nftables stateful : couche complémentaire de défense

XDP est stateless : il voit chaque paquet isolément, ignore le contexte TCP (SYN, ACK, FIN), ne peut pas rate-limiter par connexion. Nftables, avec conntrack et meters, comble ces lacunes.

Rate-limit par connexion TCP

Bloquez les bots qui ouvrent 50 connexions SSH simultanées depuis la même IP :

nft add rule inet pakkt input tcp dport 22 ct state new \
    meter ssh_connlimit { ip saddr ct count over 10 } reject

Ici, ct count comptabilise les connexions établies (état conntrack NEW ou ESTABLISHED). Dès qu'une IP dépasse 10 connexions parallèles, les nouvelles sont rejetées avec RST. Les administrateurs légitimes (1–2 sessions) restent accessibles.

Protection contre SYN flood avec syncookies kernel

Activez les SYN cookies dans sysctl pour absorber les floods résiduels :

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Combiné à une règle nftables limitant la cadence de SYN :

nft add rule inet pakkt input tcp flags syn ct state new \
    limit rate 500/second burst 1000 accept
nft add rule inet pakkt input tcp flags syn drop

Seuls 500 nouveaux SYN/seconde (burst 1000) passent ; le reste est droppé avant même d'allouer un socket. XDP aura déjà éliminé la majorité grâce au rate-limit global max_pps, mais cette couche nftables protège les ports non couverts par XDP ou le trafic local.

Filtrage TCP flags invalides

Mirai envoie parfois des paquets avec combinaisons de flags interdites (SYN+FIN, FIN sans ACK, NULL sans flags). Nftables détecte ces anomalies :

nft add rule inet pakkt input tcp flags \& (fin|syn) == (fin|syn) drop
nft add rule inet pakkt input tcp flags \& (syn|rst) == (syn|rst) drop
nft add rule inet pakkt input tcp flags \& (fin|rst|psh|ack|urg) == 0 drop

Ces règles rejettent en sub-milliseconde les paquets forgés, avant qu'ils n'atteignent l'application.

Monitoring temps réel et GeoIP : identifier les sources botnets

Une fois XDP et nftables en place, la visibilité devient critique. PAKKT collecte les métriques XDP (paquets droppés, passés, rate-limited) toutes les 30 secondes et les stocke dans TimescaleDB. Le dashboard affiche :

Top IPs sources : liste des adresses qui tentent le plus de connexions, enrichie par GeoIP (pays, ASN).
Top pays : carte monde montrant la distribution géographique des attaques. Les botnets Mirai proviennent massivement de Chine, Brésil, Inde, Russie (caméras et routeurs domestiques jamais patchés).
Métriques par port : 22/tcp, 23/tcp, 7547/tcp — courbes pps/seconde pour chaque règle XDP configurée.
Logs internes agent : timestamps de mise à jour BPF map, rechargement du programme XDP, erreurs de compilation (si vous modifiez le code eBPF).

Quand un pic de trafic apparaît sur 22/tcp depuis un ASN chinois, vous pouvez en un clic ajouter le CIDR entier à la blacklist XDP. La mise à jour se propage en < 1 seconde à l'agent via mTLS, recharge la BPF map sans interruption du trafic légitime (remplacement atomique de la map).

Audit log et conformité

Chaque modification de règle XDP ou nftables est tracée dans l'audit log du panel : utilisateur, timestamp, diff avant/après. Utile pour les certifications ISO 27001 ou PCI-DSS qui exigent la traçabilité des changements firewall.

Intégration dans un écosystème existant : Docker, fail2ban, Pterodactyl

Les administrateurs craignent souvent les conflits entre firewalls. PAKKT isole toutes ses règles dans une table nftables dédiée inet pakkt, avec priorité 0 dans la chaîne input. Docker manipule la table nat, fail2ban la table filter, iptables-persistent la table filter legacy : zéro collision.

Cas d'usage Pterodactyl

Pterodactyl v1.x assigne des ports dynamiques (25565–25600) à chaque serveur Minecraft. L'intégration PAKKT permet de créer automatiquement une règle XDP rate_limit pour chaque allocation de port, avec max_port_pps ajusté selon la taille du serveur. Quand un serveur est supprimé, la règle XDP correspondante est révoquée. Documentation complète sur pakkt.io/integrations.

Fail2ban + blacklist PAKKT

Configurez fail2ban avec une action custom qui appelle l'API PAKKT pour injecter l'IP bannie dans la BPF map :

[Definition]
actionban = curl -X POST https://api.pakkt.io/v1/blacklist \
    -H "Authorization: Bearer VOTRE_CLE_API" \
    -d '{"ip":"<ip>","duration":3600}'
actionunban = curl -X DELETE https://api.pakkt.io/v1/blacklist/<ip> \
    -H "Authorization: Bearer VOTRE_CLE_API"

Dès qu'une IP dépasse 5 tentatives SSH ratées, elle est bloquée en XDP pendant 1 heure, puis automatiquement retirée. Le trafic légitime ne subit aucune latence supplémentaire grâce au court-circuit XDP.

Complémentarité avec le scrubbing cloud amont

XDP/eBPF protège sur le serveur : si le lien WAN (1 Gbps) est saturé par une attaque 10 Gbps, aucun filtrage kernel ne peut sauver la connectivité. Dans ce scénario, un scrubbing cloud (CloudFlare Magic Transit, OVH VAC, Arbor) nettoie le trafic en amont et route uniquement les paquets légitimes vers votre IP.

PAKKT se positionne en couche de défense périmétrique kernel : il élimine les attaques sub-saturation (< débit du lien), les scans de ports, les brute-forces, les petits botnets IoT, sans coût de bande passante scrubbing. Pour les attaques volumétriques pures (> 10 Gbps), combinez scrubbing cloud + PAKKT : le scrubbing absorbe le volume, PAKKT affine le filtrage sur les vecteurs applicatifs (rate-limit par port, whitelist admin).

Cette architecture hybride optimise le coût : vous ne payez le scrubbing que lors des pics majeurs, tandis que PAKKT gère 99 % du bruit quotidien (scanners Shodan, bots Mirai opportunistes) pour 3 €/mois par agent.

Benchmark et impact performance

Les tests internes sur serveur dédié (Intel Xeon E-2388G, NIC Intel X710 10 GbE, noyau Linux 6.1) montrent :

Scénario	Trafic entrant	CPU utilisé (8 cœurs)	Latence p99 app
Baseline (sans firewall)	100 kpps légitime	5 %	0,8 ms
nftables seul (500 kpps attaque)	500 kpps mixed	95 %	120 ms
XDP PAKKT + nftables (500 kpps attaque)	500 kpps mixed	12 %	1,2 ms
XDP PAKKT + nftables (2 Mpps attaque)	2 Mpps mixed	38 %	2,1 ms

XDP drop les paquets malveillants avant qu'ils ne consomment des cycles CPU dans netfilter. L'overhead de l'agent Go PAKKT reste < 1 % CPU et < 5 MB RAM, confirmé par production sur plusieurs milliers de serveurs gaming et VPS.

⚠️ Limite connue : le rate-limit XDP du PAKKT Engine compte les paquets (pps), pas les octets (bps). Pour un rate-limit en bytes (utile contre les floods UDP payload volumineux), utilisez les meters nftables :

nft add rule inet pakkt input udp dport 19132 \
    meter udp_bw { ip saddr limit rate over 50 mbytes/second } drop

Recommandations d'hébergement pour serveurs exposés

PAKKT protège le serveur que vous possédez déjà ; il ne fournit pas d'hébergement. Lors du choix de votre hébergeur, privilégiez :

Noyau Linux ≥ 5.4 avec support XDP (vérifiez ip link set dev eth0 xdpgeneric ou mode natif). La plupart des distributions récentes (Ubuntu 22.04, Debian 12, Rocky 9) répondent au critère.
NIC moderne : Intel X710, Mellanox ConnectX-5 offrent XDP natif (mode xdpdrv) plus rapide que le mode générique kernel (xdpgeneric). Sur VPS, le mode générique fonctionne mais avec overhead +20 %.
Lien WAN adapté : 1 Gbps suffit pour serveurs gaming (25 000 joueurs simultanés Minecraft = ~300 Mbps), 10 Gbps pour clusters web à fort trafic.
Protection DDoS amont optionnelle : si budget disponible, scrubbing cloud en complément pour absorber les attaques > 5 Gbps. Sinon, PAKKT seul gère efficacement jusqu'à la saturation du lien (tests réussis à 1 Mpps sur 1 Gbps).

Ne choisissez jamais un hébergeur sur la seule promesse "anti-DDoS inclus" : testez la réactivité du filtrage (délai de mitigation), la granularité (peut-on whitelister une IP ?), la transparence (logs d'attaques accessibles ?). PAKKT vous donne cette visibilité et ce contrôle, quel que soit l'hébergeur.

Conclusion

Face aux botnets IoT Mirai et leurs millions de requêtes par seconde, le filtrage XDP/eBPF s'impose comme l'unique architecture kernel capable de protéger les services exposés sans effondrement CPU. En combinant blacklist dynamique BPF, rate-limit par port, filtrage nftables stateful et monitoring GeoIP temps réel, vous construisez une défense périmétrique qui élimine 99,9 % des attaques avant qu'elles n'atteignent votre application. L'agent PAKKT automatise ce déploiement en 30 secondes, pour un coût mensuel équivalent à un café, sans compromis sur la performance ni conflit avec Docker ou Pterodactyl. Votre infrastructure reste résiliente, votre équipe garde le contrôle, vos utilisateurs bénéficient d'une latence optimale.

FAQ

XDP peut-il bloquer une attaque Mirai de 5 Mpps sur une interface 10 GbE ?

Oui, en mode natif (xdpdrv) sur NIC Intel X710 ou Mellanox ConnectX, XDP traite plusieurs millions de paquets par seconde par cœur CPU. Avec 8 cœurs et RSS (Receive Side Scaling) activé, 5 Mpps restent gérables. Le PAKKT Engine drop atomique via BPF map blacklist garantit une latence sub-microseconde par paquet, préservant les flux légitimes. Au-delà de 10 Mpps, envisagez un scrubbing cloud amont pour absorber le volume brut avant routage vers votre serveur.

Pourquoi rate-limiter en pps plutôt qu'en bps contre les botnets IoT ?

Les attaques Mirai génèrent des paquets minimaux (54–64 octets SYN TCP ou UDP) à cadence maximale pour saturer la table de conntrack et les interruptions NIC. Un flood 1 Mpps de paquets 64 octets = seulement 512 Mbps en bande passante, mais sature 4 cœurs CPU. Le rate-limit XDP en pps stoppe cette saturation avant allocation sk_buff. Pour les floods UDP à payload volumineux (amplification DNS), complétez avec un meter nftables en bytes (limit rate over X mbytes/second), car XDP du PAKKT Engine est stateless et ne comptabilise que les paquets.

Comment synchroniser la blacklist PAKKT entre plusieurs serveurs exposés ?

Chaque agent PAKKT se connecte au panel centralisé via mTLS et récupère la blacklist globale toutes les 30 secondes (heartbeat). Quand vous ajoutez une IP dans le panel ou via l'API publique, elle se propage automatiquement à tous les agents du compte, recharge la BPF map blacklist_ips sans redémarrage du programme XDP (remplacement atomique de map). Pour les infrastructures multi-datacenter, l'API REST permet d'automatiser l'injection depuis vos outils de corrélation SIEM ou Wazuh, unifiant la défense périmétrique sur l'ensemble de votre parc.

Mirai et les botnets IoT : bloquer leurs patterns avec XDP