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 sur 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 ne tombe pas nécessairement en panne parce qu’elle ne peut pas gérer les vrais utilisateurs. Elle tombe en panne parce que l’hôte passe du temps CPU à recevoir, analyser, classifier et transporter des paquets indésirables plus loin dans Linux avant que quoi que ce soit 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 noyau. Les développeurs, les auto-hébergeurs, les opérateurs de VPS et de serveurs dédiés, et même les lecteurs professionnels comparant les options de résilience se heurtent tous à la même question fondamentale : à quel point le mauvais trafic peut-il être rejeté tôt avant de consommer du temps et des ressources qui devraient appartenir au vrai travail ? Certaines attaques saturent le lien en amont lui-même, mais de nombreuses situations dommageables apparaissent plus tôt sous forme de pression en paquets par seconde sur l’hôte bien avant que la ligne soit entièrement saturée.

C’est là que XDP mérite d’être compris. Il ne remplace pas la mitigation en amont, un pare-feu ou des contrôles tenant compte des applications. Ce qu’il offre 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 précoce » est importante pour le travail anti-DDoS, et où il s’inscrit dans une pile réaliste. Pour suivre la suite, vous n’avez besoin que d’un très petit vocabulaire de base.

Les mots-clés XDP dont vous avez besoin en 2 minutes

Plusieurs des termes autour de XDP se chevauchent, et au premier abord ils semblent plus intimidants qu’ils ne le sont vraiment. C’est normal. L’objectif de ce glossaire n’est pas de transformer l’article en cours sur les composants internes de Linux. C’est juste assez de vocabulaire pour aider le reste de l’explication à être compris clairement.

Si vous ne retenez qu’un seul raccourci mental de ce tableau, faites en sorte 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, la prochaine étape 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 de paquets précoce 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-là, Linux peut prendre une décision rapide : laisser le paquet continuer (XDP_PASS), le supprimer immédiatement (XDP_DROP), ou le gérer d’une autre manière définie. Pour cet article, la partie importante est simple : XDP peut dire « laissez-le passer » ou « arrêtez-le ici » très tôt.

Linux utilise eBPF dans plusieurs contextes, pas seulement en réseau. XDP est la version axée sur le réseau conçue pour une gestion très précoce des paquets entrants. Donc XDP n’est 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 passent par 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 sur le pare-feu, le suivi des connexions, les 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 plus que l’anti-DDoS. Il peut également prendre en charge la direction du trafic et d’autres tâches de gestion 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 le serveur a de travail inutile à faire. Et pour comprendre pourquoi cela est si important, la prochaine étape est de regarder exactement où XDP se situe dans le chemin de réception des paquets.

Le modèle mental : XDP est le portail, pas le bureau d’accueil

La façon la plus simple de visualiser XDP est comme un agent de sécurité au portail, pas comme un réceptionniste plus loin à l’intérieur du bâtiment. Si un visiteur manifestement indésirable est refoulé au portail, 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, ni ne le guide dans le couloir. Si vous attendez jusqu’au bureau d’accueil pour le rejeter, le bâtiment a déjà dépensé du temps et de l’attention sur la mauvaise personne.

La gestion des paquets Linux fonctionne de la même façon. Dans un chemin de réception simplifié, le paquet arrive depuis le NIC et le driver, atteint XDP, et seulement ensuite continue dans la kernel networking stack plus riche qui alimente conntrack, le pare-feu, les sockets et finalement l’application. Visualisé, le chemin ressemble à ceci :

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

En native mode, XDP peut agir avant que Linux n’alloue et ne remplisse la structure habituelle sk_buff — l’objet de paquet noyau plus riche que le reste de la pile attend. Ce détail semble petit, mais c’est le 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 pression mémoire et moins de pression en aval. XDP_PASS existe parce que tous les paquets ne sont pas mauvais ; c’est l’action « continuez » qui permet au trafic légitime de continuer à circuler. XDP_DROP est la star anti-DDoS car il met fin au voyage avant que la partie coûteuse ne commence. D’autres actions telles que REDIRECT existent aussi, mais elles ne sont pas essentielles pour cette explication.

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

Comment XDP aide l’anti-DDoS — et où ses limites commencent

L’argument anti-DDoS pour XDP est simple : c’est un moyen peu coûteux de rejeter les déchets évidents 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 supprimé tôt est du travail que le serveur n’a plus à faire plus tard. C’est pourquoi XDP est le plus fort à la frontière L3/L4 du problème : les adresses sources que vous ne faites déjà pas confiance, 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 est le plus important lors des inondations de déchets où la partie douloureuse n’est pas le volume brut de données mais la gestion répétée des paquets. Un reverse proxy, un service à forte utilisation UDP ou une API publique peut devenir lent bien avant que le lien en amont soit entièrement saturé si l’hôte est occupé à classifier 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 tardive pour corriger le chemin réseau par elle-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 de suivi des connexions, de listes d’autorisation en couches, de gestion de l’état des réponses ou de règles tenant compte des applications, 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 parce que 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 chiffre de paquets par seconde en 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 vrai trafic plus longtemps.

Les résultats réels dépendent fortement de l’environnement. La prise en charge du NIC et du driver, que XDP s’exécute en native mode ou en mode skb, et la forme du trafic entrant affectent tous le bénéfice réel que vous obtenez. C’est pourquoi les chiffres de paquets par seconde des fournisseurs ou des hyperscalers sont mieux traités comme une preuve que le modèle de suppression précoce fonctionne, et non comme des chiffres que chaque VPS devrait attendre. Avec cela à l’esprit, la section suivante montre à quoi ressemble XDP sur un vrai hôte Ubuntu à travers quelques captures de commandes sécurisées pour les opérateurs.

À quoi ressemble XDP en pratique — Captures de commandes

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

Avant de procéder à la configuration 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, garantissant que l’environnement dispose de tout ce qui est nécessaire pour exécuter la démonstration.

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 de fonctionnalités complet tcp,udp,ipv6,ipv4,ethernet,allow. Choisir -m skb évite de supposer la prise en charge native XDP dans votre NIC ou driver, ce qui en fait le chemin le plus sûr pour une première preuve de concept.

Pour vérifier que le programme est bien 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, un attachement xdpgeneric et le programme xdp_dispatcher confirment que le XDP générique est actif sur cette interface.

⚠️ Avertissement : Ne testez pas les politiques de refus par défaut ou les règles de suppression larges sur une interface distante active qui porte votre session SSH à moins d’avoir une récupération par 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 des capacités. Cela vous indique ce que le NIC et le driver exposent dans la surface XDP, pas quelle 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 de base. Les indicateurs supplémentaires tels que la prise en charge de la redirection sont utiles, mais ils ne sont pas requis pour une simple preuve de concept anti-DDoS.

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

sudo xdp-loader status

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

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

Ajoutez maintenant une règle d’exemple sécurisée en utilisant une adresse IP de documentation. L’indicateur -s est utile car il imprime immédiatement l’état de la règle résultante 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 :

📝 Remarque : 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 autour de laquelle 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 atteint la règle pendant la fenêtre de capture.

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

Voir une démonstration sécurisée rend l’idée concrète. La vraie décision, cependant, n’est pas de savoir si les commandes s’exécutent. C’est de savoir 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 les VPS et les serveurs dédiés

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

Il existe également de nombreux cas où un filtrage plus simple est suffisant. Un site web à faible trafic, un outil interne, une boîte de staging ou un service dont la vraie exigence est un pare-feu d’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 notable 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 lorsque le trafic est léger, que la politique nécessite un état ou une logique de service plus riche, et que l’hôte ne brûle pas visiblement du CPU sur des paquets indésirables.
• XDP mérite d’être évalué lorsque le trafic indésirable atteint l’hôte assez souvent pour que la suppression précoce puisse protéger le CPU, conntrack et la capacité des sockets.
• La mitigation en amont reste obligatoire lorsque le vrai mode de défaillance est la saturation du lien fournisseur ou des inondations volumétriques plus importantes 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 native mode même lorsque le mode skb fonctionne bien pour une démonstration. Les serveurs dédiés vous donnent généralement plus de contrôle sur les drivers, le matériel et l’observabilité, donc les chances d’une prise en charge significative du native mode sont meilleures là — mais même sur du bare metal, 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, quelle marge d’hôte le plan vous donne-t-il, 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 mauvais trafic évident et les inondations de paquets, ce qui signifie qu’il protège mieux les ressources du serveur qu’il ne protège un lien en amont saturé. C’est pourquoi XDP est important dans les conversations anti-DDoS. Il ne remplace pas la mitigation en amont, le pare-feu avec état ou les contrôles tenant compte des applications. Il aide en faisant faire moins de travail inutile à l’hôte.

Donc la règle générale est simple. Si le trafic indésirable gaspille du CPU de l’hôte avant que les vraies charges de travail puissent répondre, XDP vaut la peine d’être évalué comme couche de suppression précoce. Si le problème principal est un lien plein ou une politique qui dépend de l’état et de la logique applicative, XDP appartient derrière la mitigation en amont et le filtrage plus profond plutôt que devant eux comme réponse complète. Une prochaine étape naturelle à partir d’ici 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.