UDP amplification : pourquoi le rate-limit au kernel change tout

Le rate-limit kernel UDP représente aujourd'hui la première ligne de défense contre les attaques par amplification DNS, NTP, Memcached ou SSDP qui saturent vos serveurs en quelques secondes. En 2026, alors que les botnets IoT génèrent des volumes de 500 Gbit/s et plus, seule une filtration au plus près du matériel réseau – directement dans le noyau Linux via XDP/eBPF – permet de rejeter les paquets malveillants avant qu'ils ne consomment cycles CPU, bande passante et mémoire. Cet article détaille comment identifier une attaque par amplification UDP, configurer un rate-limit kernel efficace avec XDP et nftables, et automatiser la réponse via une plateforme centralisée.

Comprendre les attaques par amplification UDP

Une attaque par amplification UDP exploite des services publics mal configurés (résolveurs DNS ouverts, serveurs NTP mode monlist, instances Memcached exposées) pour transformer une requête de quelques octets en une réponse de plusieurs kilooctets, envoyée à une IP victime usurpée. Le facteur d'amplification atteint couramment 50:1 pour DNS, 500:1 pour NTP et jusqu'à 51 000:1 pour Memcached.

Anatomie d'un flood UDP amplifié

L'attaquant forge des paquets UDP avec l'adresse source falsifiée de sa cible, les envoie vers des milliers de réflecteurs, qui répondent tous en même temps à la victime. Le serveur cible reçoit un déluge de fragments UDP légitimes en apparence, saturant sa bande passante et épuisant les tables de connexion du firewall stateful. Les symptômes typiques incluent :

• Latence réseau en hausse brutale (> 200 ms)
• Pic de trafic entrant UDP sur un ou plusieurs ports (53, 123, 11211, 1900)
• Drop de paquets au niveau du driver NIC (RX errors)
• CPU système élevé (softirq, ksoftirqd)
• Services applicatifs inaccessibles malgré un serveur « up »

Pourquoi le userspace arrive trop tard

Lorsqu'un paquet UDP atteint iptables ou nftables en chemin classique (netfilter hook INPUT), le noyau a déjà alloué un sk_buff, traversé la pile TCP/IP, consulté les tables de routage et éventuellement déclenché conntrack. À 10 millions de paquets par seconde, ce coût cumulé sature les cœurs avant même que la règle de rate-limit ne soit évaluée. XDP (eXpress Data Path) intervient immédiatement après la réception par le driver NIC, avant toute allocation mémoire, offrant une latence de traitement inférieure à la microseconde par paquet.

Déployer un rate-limit kernel UDP avec XDP et nftables

La stratégie optimale combine XDP pour le filtrage stateless à très haut débit et nftables pour le suivi de connexion et le rate-limit fin par source. PAKKT.io orchestre ces deux couches via un agent Go léger qui synchronise règles BPF maps et table nftables inet pakkt, sans conflit avec Docker, fail2ban ou iptables-persistent.

Étape 1 : Activer XDP sur l'interface réseau

Le programme XDP PAKKT Engine se charge en mode natif (driver) ou générique selon les capacités de votre NIC. La commande suivante attache le programme compilé :

ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp

Vérifiez l'attachement avec :

ip link show dev eth0 | grep xdp

Le programme lit une BPF map pakkt_rules contenant jusqu'à 256 règles simultanées. Chaque règle définit un port range, un protocole, un rule_type (block, rate_limit, allow_only), un max_pps global et un max_port_pps. Pour un serveur de jeu Minecraft exposé sur le port 25565, une règle XDP typique autorise 50 000 pps globaux et 10 000 pps par port, rejetant tout surplus avec XDP_DROP avant même l'entrée dans la pile réseau.

Étape 2 : Configurer nftables pour le suivi stateful

XDP étant stateless, il ne distingue pas une connexion légitime d'un paquet isolé. nftables prend le relais pour les paquets acceptés par XDP, appliquant conntrack et rate-limit par IP source. La table inet pakkt s'isole totalement des autres règles système :

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority 0 \; policy accept \; }
nft add rule inet pakkt input udp dport 25565 ct state new limit rate 100/second accept
nft add rule inet pakkt input udp dport 25565 ct state new drop

Cette configuration autorise 100 nouvelles connexions UDP par seconde vers le port 25565, rejetant toute tentative supplémentaire. Les connexions établies (ct state established) passent sans limite. Le meter nftables peut aussi segmenter par IP source :

nft add rule inet pakkt input udp dport 25565 meter flood_udp { ip saddr limit rate 20/second } accept
nft add rule inet pakkt input udp dport 25565 drop

Chaque IP source peut envoyer jusqu'à 20 paquets UDP/s vers le port 25565 ; au-delà, les paquets sont jetés. Cette granularité empêche un seul attaquant de monopoliser votre quota global.

Étape 3 : Synchroniser blacklist et whitelist entre XDP et nftables

PAKKT maintient deux BPF maps (pakkt_blacklist, pakkt_whitelist) et deux sets nftables (@blacklist, @whitelist). Lorsque vous ajoutez une IP via le panel centralisé, l'agent met à jour les deux couches en quelques millisecondes. Les IPs whitelistées bénéficient d'un XDP_PASS immédiat ; les IPs blacklistées reçoivent un XDP_DROP avant toute autre évaluation, économisant des milliers de cycles CPU par seconde sous attaque.

Taille de paquet et détection d'amplification

Les réponses DNS amplifiées dépassent rarement 512 octets en UDP standard, mais les attaques EDNS0 peuvent atteindre 4096 octets. Memcached envoie des réponses jusqu'à 1 MB fragmentées. PAKKT Engine permet de définir un min_packet_size et max_packet_size par règle XDP. Exemple de règle bloquant les paquets UDP > 1400 octets sur le port 11211 (Memcached) :

{
  "port_start": 11211,
  "port_end": 11211,
  "protocol": "udp",
  "rule_type": "block",
  "min_packet_size": 1401,
  "max_packet_size": 65535
}

Cette approche rejette les fragments volumineux typiques d'une amplification sans impacter le trafic légitime, généralement inférieur à 1400 octets.

Monitoring et réponse automatisée en temps réel

Un rate-limit kernel statique ne suffit pas : les attaques évoluent en volume, en source (rotation d'IP) et en vecteur (DNS puis NTP puis SSDP). Le dashboard PAKKT affiche en temps réel les métriques par port et par règle (paquets acceptés, droppés, rate-limités), une carte monde GeoIP des IPs sources, et les top pays/IPs attaquants. Les données sont stockées dans TimescaleDB pour analyse historique et corrélation.

Détection d'anomalies et seuils dynamiques

Lorsque le max_port_pps d'une règle XDP est atteint pendant plus de 60 secondes, l'agent PAKKT peut déclencher automatiquement :

• L'ajout des IPs sources dépassant un seuil (ex. 500 pps/IP) à la blacklist XDP
• L'abaissement temporaire du rate-limit nftables (ex. passer de 100/s à 50/s)
• Une alerte webhook vers Slack, Discord ou PagerDuty
• L'activation d'une règle allow_only restreignant le trafic à une whitelist prédéfinie

Ces réponses sont configurables via l'API PAKKT ou directement dans le panel. L'audit log horodate chaque action (règle ajoutée, IP blacklistée, seuil franchi) pour conformité et post-mortem.

Intégration avec Pterodactyl et panels tiers

Pour les hébergeurs de serveurs de jeu, PAKKT s'intègre nativement à Pterodactyl v1.x, permettant aux utilisateurs finaux de consulter les statistiques d'attaque, d'ajouter des IPs à leur whitelist personnelle et de basculer entre profils de protection (« Gaming », « DDoS max », « Maintenance ») sans accès SSH. Les templates XDP/nft partagés sur le marketplace PAKKT accélèrent le déploiement pour Minecraft (Bedrock/Java), FiveM, Rust, CS2, ARK ou Valheim.

Complémentarité avec le scrubbing cloud

Le rate-limit kernel sur le serveur final complète, mais ne remplace pas, un scrubbing cloud en amont (OVH VAC, Cloudflare Magic Transit, Arbor). Le scrubbing absorbe les volumétriques pures (> 100 Gbit/s) ; XDP/eBPF filtre les paquets qui passent le scrubbing mais restent malveillants ou consomment des ressources locales (SYN flood, UDP fragment, slowloris applicatif relayé). Cette défense en profondeur réduit la surface d'attaque à chaque couche.

Optimisations avancées et limites techniques

XDP offre des performances exceptionnelles mais impose des contraintes architecturales. Comprendre ces limites vous évitera des surprises en production.

Mode XDP : natif vs générique

Le mode natif (driver XDP) requiert un pilote réseau compatible (Intel ixgbe, i40e, ice ; Mellanox mlx5 ; Netronome nfp). Il offre un traitement zero-copy et atteint plusieurs millions de pps par cœur. Le mode générique (fallback) fonctionne sur tout NIC mais passe par la pile réseau classique, divisant les performances par 5 à 10. Vérifiez la compatibilité de votre NIC avant déploiement :

ethtool -i eth0 | grep driver

Consultez la documentation kernel officielle XDP pour la liste des drivers supportés.

Rate-limit en paquets vs octets

Le PAKKT Engine en XDP effectue un rate-limit stateless par paquets (max_pps, max_port_pps). Il ne comptabilise pas les octets (stateless = pas de fenêtre glissante en mémoire partagée). Pour un rate-limit en bytes par seconde, nftables reste la solution :

nft add rule inet pakkt input udp dport 19132 limit rate 50 mbytes/second accept
nft add rule inet pakkt input udp dport 19132 drop

Cette règle plafonne le débit UDP entrant sur le port 19132 (Minecraft Bedrock) à 50 MB/s. Au-delà, les paquets sont rejetés. Combinez les deux approches : XDP pour éliminer le bruit (paquets hors profil, tailles anormales), nftables pour gérer le débit et le state.

Impact CPU et scaling multi-cœurs

XDP distribue le traitement via RSS (Receive Side Scaling) : chaque queue RX du NIC est traitée par un cœur distinct. Pour maximiser le débit, configurez autant de queues que de cœurs disponibles :

ethtool -L eth0 combined 8

L'agent PAKKT consomme moins de 1 % CPU et moins de 5 MB RAM en idle, montant à 3–5 % CPU sous attaque soutenue (10 Mpps) grâce à l'optimisation du code Go (garble obfuscation, mTLS réutilisé, heartbeat 30s). Le programme XDP lui-même ajoute une latence négligeable (sub-microseconde par paquet).

Tableau comparatif : XDP vs nftables vs iptables

Critère	XDP/eBPF	nftables	iptables
Débit max (pps/cœur)	10–20 Mpps	2–5 Mpps	1–3 Mpps
Latence par paquet	< 1 µs	5–10 µs	10–20 µs
Stateful (conntrack)	Non	Oui	Oui
Rate-limit par IP source	Possible (map partagée)	Oui (meter)	Oui (hashlimit)
Compatibilité kernel	≥ 5.x + driver XDP	≥ 3.13	≥ 2.4

En résumé : XDP pour le premier filtre brutal, nftables pour la logique stateful fine, iptables legacy à éviter (performance et maintenabilité inférieures).

Conclusion

Le rate-limit kernel UDP via XDP et nftables constitue en 2026 la seule réponse viable aux attaques par amplification multi-vectorielles dépassant 10 Mpps. En rejetant les paquets malveillants avant l'allocation mémoire et en appliquant un suivi de connexion granulaire, vous préservez la disponibilité de vos services même sous DDoS soutenu. Une plateforme centralisée comme PAKKT automatise le déploiement, le monitoring temps réel et la réponse orchestrée sur des dizaines de serveurs, transformant la protection kernel en avantage opérationnel concret pour les hébergeurs et DevOps. Trois euros par agent et par mois suffisent à sécuriser chaque nœud ; l'essai gratuit de 7 jours sur le premier agent vous permet de valider l'efficacité sur votre infrastructure sans engagement.

FAQ

Puis-je appliquer un rate-limit XDP différent par IP source ou uniquement un plafond global ?

Le PAKKT Engine XDP applique un max_pps global et un max_port_pps par port, mais reste stateless : il ne maintient pas de compteur par IP source en BPF map (coût mémoire prohibitif à plusieurs millions d'IPs). Pour un rate-limit fin par IP, utilisez le meter nftables (ip saddr limit rate X/second) en complément. XDP rejette le surplus global, nftables segmente ensuite par source.

Mon NIC ne supporte pas le mode XDP natif : le mode générique reste-t-il efficace contre une attaque à 5 Mpps ?

Le mode XDP générique traite les paquets après l'entrée dans la pile réseau, divisant le débit atteignable par 5 à 10 par rapport au mode natif. À 5 Mpps, vous saturerez probablement les softirq avant que XDP ne filtre. Solution : upgrader vers un NIC compatible (Intel X710, Mellanox ConnectX-5 ou supérieur) ou combiner un scrubbing cloud en amont pour abaisser le volume à un niveau gérable (< 1 Mpps) où le mode générique reste utile.

Comment vérifier que mes règles XDP sont bien appliquées et comptabilisent les drops ?

Utilisez bpftool pour inspecter les maps BPF. Exemple : bpftool map dump name pakkt_stats affiche les compteurs de paquets acceptés, droppés et rate-limités par règle. Le dashboard PAKKT agrège ces métriques en temps réel avec granularité par port, protocole et règle. Vérifiez aussi ip -s link show dev eth0 pour les statistiques RX du driver ; une hausse des RX drops côté NIC indique que XDP rejette efficacement avant la pile réseau.