Qu’est-ce que XDP et comment peut-il aider à construire une protection anti-DDoS ?

Introduction à XDP et comment peut-il aider à construire une protection anti-DDoS ?

Si vous exploitez une API publique, un reverse proxy, un service de jeu ou toute autre charge de travail exposée à Internet, vous pouvez atteindre un point douloureux où le serveur est occupé par du trafic qui n’a jamais été utile en premier lieu. L’application n’échoue pas nécessairement parce qu’elle ne peut pas gérer les vrais utilisateurs. Elle échoue parce que l’hôte dépense du temps CPU à recevoir, analyser, classer et transporter des paquets inutiles plus profondément dans Linux avant que quelque chose ne dise « non ». De nombreux problèmes anti-DDoS commencent là : non pas comme une histoire de bande passante, mais comme une histoire de coût de traitement des paquets.

Cela concerne plus que les spécialistes du kernel. Les développeurs, les auto-hébergeurs, les opérateurs de VPS et de serveurs dédiés, et même les lecteurs commerciaux comparant les options de résilience se posent tous la même question fondamentale : à quel point tôt le mauvais trafic peut-il être rejeté avant qu’il ne consomme du temps et des ressources qui devraient appartenir au travail réel ? Certaines attaques écrasent la liaison montante elle-même, mais de nombreuses situations dommageables apparaissent plus tôt sous forme de pression de paquets par seconde sur l’hôte bien avant que la ligne soit complètement saturée.

C’est là que XDP devient digne de compréhension. Il ne remplace pas l’atténuation en amont, un firewall ou les contrôles conscients des applications. Ce qu’il offre, c’est un point de contrôle beaucoup plus précoce dans le chemin des paquets Linux. Cet article explique ce qu’est XDP, pourquoi cette position « plus tôt » importe pour le travail anti-DDoS, et où il s’inscrit dans une pile réaliste. Pour suivre le reste, vous n’avez besoin que d’un très petit ensemble de vocabulaire en premier.

Mots-clés XDP que vous devez connaître en 2 minutes

Plusieurs des termes autour de XDP se chevauchent, et au premier abord, ils semblent plus intimidants qu’ils ne le sont réellement. C’est normal. Le but de ce glossaire n’est pas de transformer l’article en cours sur les internals de Linux. C’est juste assez de vocabulaire pour que le reste de l’explication soit clair.

Si vous ne retenez qu’un seul raccourci mental de ce tableau, que ce soit celui-ci : eBPF est le mécanisme programmable, et XDP est un endroit spécifique où ce mécanisme peut s’exécuter. Avec cela en place, l’étape suivante est une question plus simple et plus utile : que fait réellement XDP ?

Ce qu’est réellement XDP

XDP est un hook de traitement précoce des paquets dans Linux. Il permet au système d’exécuter un petit programme eBPF sur un paquet dès que ce paquet arrive sur une interface réseau. À ce moment, Linux peut prendre une décision rapide : laisser le paquet continuer (XDP_PASS), le supprimer immédiatement (XDP_DROP), ou le traiter d’une autre manière définie. Pour cet article, la partie importante est simple : XDP peut dire « laisse passer » ou « arrête-le ici » très tôt.

Linux utilise eBPF dans plusieurs contextes, pas seulement en réseau. XDP est la version orientée réseau conçue pour un traitement très précoce des paquets entrants. XDP n’est donc pas un autre mot pour eBPF. C’est un outil basé sur eBPF avec un rôle très spécifique.

Ce rôle est ce qui rend XDP utile pour le travail anti-DDoS. XDP s’exécute avant que les paquets ne traversent les parties normales et plus lourdes du chemin réseau Linux. Ainsi, Linux peut décider de certains trafics avant de dépenser plus d’efforts en pare-feu, suivi de connexion, sockets et finalement l’application elle-même. C’est pourquoi le véritable avantage de XDP n’est pas seulement le filtrage — c’est le filtrage plus tôt.

De plus, XDP est utile pour bien plus que l’anti-DDoS. Il peut également supporter l’orientation du trafic et d’autres tâches de traitement des paquets. Mais l’anti-DDoS est l’endroit le plus facile pour voir sa valeur, car l’avantage se résume à une idée pratique : plus tôt le mauvais trafic est rejeté, moins de travail inutile le serveur doit faire. Et pour comprendre pourquoi cela compte tellement, l’étape suivante est de regarder exactement où XDP se situe dans le chemin de réception des paquets.

Le modèle mental : XDP est la porte, pas la réception

La façon la plus simple de visualiser XDP est de la voir comme un agent de sécurité à la porte, et non comme une réceptionniste plus loin dans le bâtiment. Si un visiteur indésirable évident est refusé à la porte, le bâtiment évite une longue chaîne de travail inutile. Personne n’ouvre la porte intérieure, ne l’enregistre dans un système, ou ne le guide dans le couloir. Si vous attendez la réception pour le rejeter, le bâtiment a déjà consacré du temps et de l’attention à la mauvaise personne.

La gestion des paquets Linux fonctionne de la même manière. Dans un chemin de réception simplifié, le paquet arrive de la NIC et du pilote, atteint XDP, et seulement ensuite continue dans la pile réseau du noyau plus riche qui alimente conntrack, le pare-feu, les sockets et finalement l’application. Visuellement, le chemin ressemble à ceci :

NIC / driver
    ↓
XDP  ← earliest checkpoint
    ↓
kernel networking stack
    ↓
conntrack / firewall
    ↓
socket
    ↓
application

En mode natif, XDP peut agir avant que Linux n’alloue et ne remplisse la structure sk_buff habituelle — l’objet paquet du noyau plus riche que le reste de la pile attend. Ce détail semble petit, mais il est au cœur de l’histoire de performance. Si le paquet est manifestement indésirable, le supprimer avant que Linux ne construise cette structure normale signifie moins de travail CPU, moins de churn mémoire et moins de pression en aval. XDP_PASS existe parce que tous les paquets ne sont pas mauvais ; c’est l’action « continuer » qui permet au trafic légitime de continuer. XDP_DROP est la vedette anti-DDoS parce qu’elle termine le voyage avant que la partie coûteuse ne commence. D’autres actions comme REDIRECT existent aussi, mais elles ne sont pas essentielles pour cette explication.

Une fois le placement clair, la valeur anti-DDoS — et les limitations — deviennent beaucoup plus faciles à juger de manière réaliste.

Comment XDP aide à la protection anti-DDoS — et où ses limites commencent

Le cas anti-DDoS pour XDP est simple : c’est un moyen bon marché de rejeter les données évidentes avant que Linux ne dépense des ressources sur conntrack, la gestion des sockets et la livraison en espace utilisateur. Si un hôte est bombardé de trafic à haut débit qui ne devrait jamais atteindre l’application de toute façon, chaque paquet rejeté tôt est du travail que le serveur n’aura plus à faire plus tard. C’est pourquoi XDP est le plus puissant à la limite L3/L4 du problème : les adresses source que vous méfiez déjà, les protocoles que vous ne voulez pas, ou les modèles de trafic qui ne sont clairement pas légitimes pour la charge de travail.

Cela importe surtout lors des inondations de déchets où la partie douloureuse n’est pas le volume de données brutes mais la manipulation répétée des paquets. Un proxy inverse, un service lourd en UDP ou une API publique peuvent devenir lents bien avant que le lien montant soit complètement saturé si l’hôte est occupé à classer des absurdités. XDP vous donne un moyen de couper une partie de ce gaspillage près de la porte.

📝 Remarque : XDP protège mieux les ressources de l’hôte qu’il ne protège un lien en amont saturé. Si le lien côté fournisseur est déjà plein, la suppression précoce au niveau de l’hôte est trop tard pour corriger le chemin réseau par lui-même.

Cette distinction est la principale raison pour laquelle XDP appartient à une conception en couches plutôt que sur un piédestal. Le tableau suivant est la version pratique de XDP vs nftables vs mitigation en amont/fournisseur :

En d’autres termes, XDP et nftables ne sont pas des ennemis. Ils résolvent différentes parties du chemin. nftables est plus riche et avec état. xdp-filter — l’outil de démonstration utilisé dans cet article — est intentionnellement simple et sans état, ce qui est exactement pourquoi il est utile pour montrer le modèle XDP sans prétendre remplacer un pare-feu complet. Si vous avez besoin du suivi des connexions, de listes d’autorisation en couches, de gestion de l’état de réponse ou de règles conscientes de l’application, vous décrivez déjà des problèmes qui appartiennent plus profondément que cet utilitaire de démonstration.

Les opérateurs en production utilisent la suppression de style XDP car la suppression précoce réduit le travail en aval. L’histoire L4Drop de Cloudflare est un exemple bien connu de pourquoi ce modèle est devenu attrayant dans les opérations réelles. Mais la leçon importante n’est pas seulement le nombre de paquets par seconde en gros titre. C’est la logique de conception : rejeter le mauvais trafic plus tôt pour que le reste de la machine puisse continuer à servir le trafic réel plus longtemps.

Les résultats du monde réel dépendent fortement de l’environnement. Le support NIC et pilote, si XDP s’exécute en mode natif ou skb, et la forme du trafic entrant affectent tous le bénéfice que vous obtenez réellement. C’est pourquoi les chiffres de paquets par seconde en gros titre des fournisseurs ou des hyperscalers sont mieux traités comme la preuve que le modèle de suppression précoce fonctionne, et non comme des nombres que chaque VPS devrait attendre. Avec cela à l’esprit, la section suivante montre à quoi ressemble XDP sur un vrai hôte Ubuntu à travers quelques instantanés d’opérateur sûrs.

À quoi ressemble XDP en pratique — Instantanés de commandes

Cette section est un instantané de preuve de concept. L’objectif est de rendre XDP concret sur Ubuntu 24.04 avec l’ensemble pertinent de commandes : suffisamment pour charger un filtre, inspecter ce qui est attaché, ajouter une règle à faible risque, et lire les compteurs qui importent.

Avant de procéder à la configuration de XDP, vous devez d’abord découvrir et sélectionner le nom de l’interface.

ip -br link

Installez les prérequis.

sudo apt update
sudo apt install -y xdp-tools

Dans la commande ci-dessous, remplacez <ifname> par le nom réel de votre interface réseau, tel que eth0 ou ens3.

sudo xdp-filter load -m skb <ifname>

Les deux premières commandes sont responsables de l’installation des outils requis, en s’assurant que l’environnement dispose de tout ce qui est nécessaire pour exécuter la démo.

La troisième commande charge ensuite xdp-filter en mode skb avec la politique allow par défaut. Sur l’hôte Ubuntu utilisé pour cet article, cela a produit la variante xdpfilt_alw_all avec l’ensemble complet de fonctionnalités tcp,udp,ipv6,ipv4,ethernet,allow. Choisir -m skb évite de supposer un support XDP natif dans votre NIC ou votre pilote, ce qui en fait le chemin plus sûr pour une première preuve de concept.

Pour vérifier que le programme s’est réellement attaché, exécutez :

sudo xdp-filter status
ip -details link show dev <ifname>

Dans xdp-filter status, vous voulez voir votre interface listée avec skb mode ; sur l’hôte de test ici, l’ensemble de fonctionnalités chargé affichait tcp,udp,ipv6,ipv4,ethernet,allow. Dans ip -details link show, une attachement xdpgeneric et le programme xdp_dispatcher confirment que XDP générique est actif sur cette interface.

⚠️ Avertissement : Ne testez pas les politiques deny-default ou les règles de suppression larges sur une interface distante active qui porte votre session SSH à moins que vous ayez une récupération de console. Cet article reste avec une politique allow et une règle d’adresse de documentation pour exactement cette raison.

Ensuite, inspectez la découverte de capacité. Cela vous indique ce que la NIC et le pilote exposent dans la surface XDP, pas ce que sera votre performance finale.

sudo xdp-loader features <ifname>

La sortie exacte varie selon le matériel, mais un résultat représentatif contient souvent des lignes comme celles-ci :

Ce qui importe le plus ici est NETDEV_XDP_ACT_BASIC, car cela vous indique que le chemin expose le modèle d’action XDP principal. Les drapeaux supplémentaires tels que le support de redirection sont utiles, mais ils ne sont pas requis pour une simple preuve de concept anti-DDoS.

Ensuite, vérifiez comment le chargeur XDP gère le programme et dans quel mode il s’exécute.

sudo xdp-loader status

Sur un système fonctionnant correctement, une vue d’état peut ressembler à ceci :

C’est une vérification d’opérateur petite mais importante. Elle confirme que XDP n’est pas juste un concept de règle vivant dans l’espace utilisateur — il y a un programme chargé sur l’interface, et la colonne de mode vous indique si vous regardez native ou skb.

Maintenant, ajoutez une règle d’exemple sûre en utilisant une adresse IP de documentation. Le drapeau -s est utile car il imprime l’état de la règle résultante immédiatement au lieu de vous laisser avec un succès silencieux.

sudo xdp-filter ip -s -m src 192.0.2.1

Une réponse représentative peut ressembler à ceci :

📝 Note : xdp-filter utilise par défaut une politique allow. En d’autres termes, les paquets qui correspondent à la règle sont supprimés, et les paquets qui ne correspondent pas à la règle continuent par le chemin normal.

Cet exemple est intentionnellement ennuyeux. En termes anti-DDoS, il montre également la version la plus simple possible d’une règle de suppression précoce : le trafic provenant d’une source que vous ne voulez pas peut être rejeté avant que le reste de l’hôte n’y investisse beaucoup de travail.

Enfin, inspectez l’état global en un seul endroit.

sudo xdp-filter status

Sur un système typique, le modèle de sortie est le plus informatif.

Cette vue d’état est l’endroit où la preuve de concept devient opérationnellement utile. Vous pouvez voir l’interface chargée, le mode actif, la variante xdp-filter active, l’ensemble de fonctionnalités effectif, et l’état du compteur par règle en une seule commande. XDP_ABORTED, s’il apparaît, est principalement un compartiment d’erreur/débogage plutôt que l’action que vous planifiez. Plus important encore, si le compteur de suppression reste à 0, cela ne signifie pas que le filtre a échoué. Cela signifie seulement qu’aucun paquet correspondant n’a frappé la règle pendant la fenêtre de capture.

💡 Conclusion : Traitez xdp-filter comme un outil simple et sans état de preuve de concept, pas comme un remplacement pour nftables. Gardez également à l’esprit que les paquets supprimés au niveau XDP peuvent ne jamais apparaître dans le chemin tcpdump habituel, ce qui rend la sortie d’état et les compteurs natifs de XDP la méthode de validation plus fiable. Si vous voulez une vue en direct plus tard, sudo xdp-filter poll -i 2000 est une prochaine étape optionnelle raisonnable — mais seulement quand l’interface a déjà assez de trafic intéressant pour rendre cette sortie utile.

Voir une démo sûre rend l’idée concrète. La vraie décision, cependant, n’est pas si les commandes s’exécutent. C’est si cette couche supplémentaire vaut la complexité opérationnelle sur le type d’infrastructure que vous gérez réellement.

Quand XDP vaut la peine d’être envisagé pour VPS et serveurs dédiés

XDP devient intéressant quand une charge de travail exposée au public perd du temps CPU significatif à cause de paquets indésirables avant que l’application puisse répondre normalement. Les bons candidats incluent les API publiques, les proxies inverses, les passerelles, les services UDP exposés à Internet et les hôtes qui voient régulièrement assez de trafic indésirable pour stresser le chemin réseau même quand l’application elle-même n’est pas le goulot d’étranglement. Dans ces environnements, un rejet précoce peut récupérer de l’espace serveur réel.

Il y a aussi beaucoup de cas où un filtrage plus simple suffit. Un site web à faible trafic, un outil interne, une boîte de staging, ou un service dont l’exigence réelle est un pare-feu hôte avec état plutôt qu’un soulagement du débit de paquets n’a généralement pas besoin de XDP en premier. Si nftables couvre déjà le risque sans pression visible sur le chemin des paquets, ajouter une autre couche peut créer plus de pièces mobiles que de valeur.

Comme cadre de décision rapide :

• Le pare-feu est généralement suffisant quand le trafic est léger, la politique a besoin d’état ou d’une logique de service plus riche, et l’hôte ne brûle pas visiblement du CPU sur les paquets indésirables.
• XDP vaut la peine d’être évalué quand le trafic indésirable atteint l’hôte assez souvent pour qu’un rejet précoce puisse protéger le CPU, conntrack, et la capacité des sockets.
• L’atténuation en amont reste obligatoire quand le vrai mode de défaillance est la saturation du lien du fournisseur ou un inondation volumétrique plus importante avant même que les paquets n’atteignent votre serveur.

Les utilisateurs de VPS doivent garder une mise en garde à l’esprit : les chemins de NIC virtuels et l’abstraction du fournisseur peuvent limiter les attentes du mode natif même quand le mode skb fonctionne bien pour une démo. Les serveurs dédiés vous donnent généralement plus de contrôle sur les pilotes, le matériel, et l’observabilité, donc les chances d’un support du mode natif significatif sont meilleures là — mais même sur du métal nu, XDP est toujours une couche, pas la réponse complète. Si vous évaluez AlexHost ou tout autre fournisseur, posez trois questions séparées au lieu de les regrouper : quelle gestion DDoS en amont existe, combien d’espace libre l’offre vous donne-t-elle, et quels contrôles au niveau de l’hôte sont réalistes sur cette plateforme ?

Conclusion : XDP est une couche de suppression précoce, pas le bouclier complet

La façon la plus claire de penser à XDP est celle-ci : il donne à Linux un premier point de contrôle rapide pour le trafic manifestement mauvais et les inondations de paquets, ce qui signifie qu’il protège mieux les ressources du serveur qu’il ne protège un lien amont saturé. C’est pourquoi XDP est important dans les conversations anti-DDoS. Il ne remplace pas l’atténuation amont, le pare-feu avec état ou les contrôles conscients des applications. Il aide en faisant en sorte que l’hôte fasse moins de travail inutile.

La règle empirique est donc simple. Si le trafic indésirable gaspille le CPU de l’hôte avant que les charges de travail réelles puissent répondre, XDP vaut la peine d’être évalué comme couche de suppression précoce. Si le problème principal est un lien de liaison complètement saturé ou une politique qui dépend de l’état et de la logique applicative, XDP devrait être placé derrière l’atténuation amont et le filtrage plus profond plutôt que devant eux comme réponse complète. Une prochaine étape naturelle serait un suivi sur l’écriture de programmes XDP personnalisés ou la construction d’une défense en couches plus riche autour de la même idée de suppression précoce.