6 octobre 2026
·
18 min de lecture
Détection DDoS : le port mirroring (DPDK) voit 100 % des paquets, RTBH après env. 1 s, filtrage après 6–10 s ; NetFlow, sFlow et IPFIX échantillonnés : 35–95 s.
Réponse courte : les méthodes de détection DDoS se répartissent en deux familles. L’analyse des paquets issus d’un port en miroir (SPAN ou TAP passif) avec DPDK voit 100 % du trafic au débit de la ligne, détecte l’attaque et déclenche le RTBH après environ 1 s, puis le filtrage sélectif après 6–10 s. L’analyse des flux (NetFlow, sFlow, IPFIX) s’appuie sur les enregistrements échantillonnés que le routeur exporte de toute façon : elle est bien moins coûteuse et couvre l’ensemble du réseau, mais réagit au bout de 35–95 s. Cet écart détermine si le client remarquera l’attaque ou non.
Qu’est-ce que la détection DDoS, concrètement ?
La détection est le processus qui permet de reconnaître qu’une attaque par déni de service distribué est en cours : le système profile le trafic en continu et lève une alerte dès que le volume, la répartition des protocoles ou la taille des paquets dans un sous-réseau donné s’écarte de la ligne de base apprise. Elle répond à une seule question, et doit le faire vite : s’agit-il d’un trafic normal ou d’une attaque ?
La détection n’est pas la riposte, mais l’une n’existe pas sans l’autre. Aucun filtre, aucune règle BGP FlowSpec ni aucune coupure d’adresse par RTBH ne rejettera le moindre paquet tant que le détecteur n’aura pas signalé qu’il y a quelque chose à rejeter. Toute la chaîne de défense n’est jamais plus rapide que son premier maillon.
Ce dont vous alimentez le détecteur, copie des paquets ou flux exportés, fixe simultanément deux paramètres : le temps de réaction et le coût de couverture du réseau. C’est le seul choix réellement difficile dans la conception d’un système de détection.
Pourquoi le délai de détection décide-t-il si les clients remarquent l’attaque ?
Parce que les attaques volumétriques actuelles saturent un uplink en quelques dizaines de secondes, et non en quelques minutes. Dans son rapport du quatrième trimestre 2025, Cloudflare indique que le nombre d’attaques DDoS a augmenté de 121 % sur un an et que l’attaque record bloquée, d’un volume de 31,4 Tbit/s, n’a duré que 35 secondes. Le secteur le plus visé par les attaques hypervolumétriques était celui des opérateurs télécoms et des fournisseurs de services, c’est-à-dire précisément le profil de réseau dont il est question ici.
Relisez ce chiffre : 35 secondes du début à la fin. Une méthode de détection qui réagit en 35–95 s peut manquer entièrement une telle attaque, ou ne la voir qu’une fois le lien déjà engorgé, alors que les clients subissent des timeouts depuis longtemps. L’alerte n’arrive alors pas comme un avertissement, mais comme la confirmation d’une panne.
Les données de NETSCOUT pour le second semestre 2025 font état de plus de 8 millions d’attaques DDoS dans 203 pays, dont environ 42 % combinaient deux à cinq vecteurs simultanément. Une attaque multivectorielle de courte durée est le cas d’école dans lequel une détection lente et échantillonnée ne suit tout simplement pas : avant que les statistiques ne fassent apparaître une anomalie, le vecteur a déjà changé.
La règle pratique que nous appliquons est la suivante : le délai de détection doit être inférieur au délai de saturation du lien. Sur une bordure 100GE chargée, ce budget se compte en secondes. Pour voir à quoi cela ressemble du point de vue de l’ingénieur d’astreinte au NOC, consultez notre article consacré à une attaque DDoS contre un FAI : quelques dizaines de secondes de trafic y ont suffi à faire tomber le réseau.
Comment fonctionne la détection par port mirroring (DPDK) ?
La détection au niveau paquet analyse une copie complète du trafic. Une session SPAN ou un miroir sur un commutateur ou un routeur, ou bien un TAP optique passif si vous ne voulez pas solliciter l’équipement de production, duplique chaque paquet vers un port de supervision. Le Packet Sensor de WanGuard y capture le trafic en espace utilisateur à l’aide de DPDK (Data Plane Development Kit), au débit de la ligne.
Le point essentiel : rien n’est estimé. Le capteur voit directement chaque en-tête, chaque flag TCP, chaque protocole et chaque fragment. Pas de reconstruction statistique, pas de taux d’échantillonnage par lequel il faudrait multiplier le résultat.
C’est DPDK qui rend cette approche réaliste sur des liens à haut débit. Il contourne la pile réseau du noyau Linux et utilise des pilotes en mode polling (poll mode) ainsi que des hugepages, ce qui réduit au minimum le coût de traitement par paquet. Résultat : un serveur x86 standard peut analyser des dizaines de Gbit/s, voire des centaines avec une configuration adaptée.
Le gain est unique et très concret : le temps de réaction. Dans les déploiements ITORO, la détection par port mirroring signale une attaque volumétrique assez tôt pour déclencher le RTBH après environ 1 s et un filtrage sélectif par règles BGP FlowSpec après 6–10 s.
La contrepartie est la couverture. Il faut de la capacité de mirroring et un capteur à chaque point de mesure ; couvrir plus d’une dizaine de POP géographiquement dispersés avec une analyse complète des paquets devient donc coûteux, et n’a généralement pas de sens. Le port mirroring est un outil à placer là où les secondes coûtent vraiment cher : sur les bordures les plus chargées et auprès des clients à plus forte valeur.
Ce que le port mirroring exige de l’équipement
Avant de planifier le déploiement, vérifiez trois points. Premièrement : l’équipement supporte-t-il une session de mirroring sans impact sur le forwarding (sur du matériel au budget PFE limité, le mirroring peut être coûteux) ? Deuxièmement : le port de supervision dispose-t-il d’une bande passante couvrant le pic de trafic dans les deux sens ? Un mirroring de 2 × 10GE vers un seul port 10GE ne passera tout simplement pas, et vous commencerez à perdre des paquets précisément au moment où ils comptent le plus. Troisièmement : un TAP passif ou un packet broker, qui répartit le même flux entre plusieurs outils, ne reviendrait-il pas moins cher ?
Comment fonctionne la détection basée sur NetFlow, sFlow et IPFIX ?
La détection par flux analyse les enregistrements de synthèse que vos routeurs exportent déjà. Vous n’avez besoin ni de mirroring ni de TAP. Le Flow Sensor collecte ces enregistrements, en reconstitue une image statistique du trafic par sous-réseau et signale une anomalie lorsque cette image s’écarte de la ligne de base.
Trois formats d’export dominent et, contrairement à l’usage courant qui appelle tout « NetFlow », ils ne fonctionnent pas de la même manière.
NetFlow et IPFIX : export depuis le cache de flux
NetFlow (d’origine Cisco, versions v5 et v9) et son équivalent normalisé par l’IETF, IPFIX (RFC 7011), maintiennent sur le routeur un cache de flux. L’équipement regroupe les paquets en flux et n’exporte un enregistrement que lorsque le flux se termine ou qu’un temporisateur expire. C’est l’active flow timeout qui détermine la rapidité avec laquelle une attaque de longue durée sera signalée, et sa valeur par défaut sur de nombreuses plateformes est d’environ 60 secondes. Sur la plupart des équipements, elle peut être abaissée, et nous recommandons de le faire, mais plus vous descendez, plus vous payez en nombre d’enregistrements exportés et en charge sur le collecteur.
Ce seul temporisateur est la principale raison pour laquelle la détection par flux se situe dans une plage de 35–95 s.
sFlow : échantillonnage de paquets
sFlow suit une autre voie. Il échantillonne 1 paquet sur N et envoie ces échantillons en continu, sous forme de datagrammes : il n’y a ici aucun cache qui doive expirer. Comme il n’attend pas la fermeture d’un flux, il peut réagir plus vite que NetFlow classique. Il reste toutefois échantillonné, et échange donc l’exhaustivité de l’image contre une livraison en quasi temps réel.
Une économie commune aux trois
L’export de flux est indépendant de la bande passante : vous envoyez des enregistrements, pas une copie du trafic. Il couvre chaque routeur qui parle déjà ce protocole et passe à l’échelle des volumes térabits pour un coût modeste. Vous le payez en temps et en finesse : les enregistrements sont échantillonnés (généralement 1:1000 ou 1:2000 sur les liens rapides) et souvent agrégés sur la fenêtre d’export ; en production, la détection par flux se situe donc typiquement dans la plage 35–95 s et voit une image bien plus grossière que l’analyse des paquets.
Port mirroring ou NetFlow, sFlow et IPFIX : comparatif
Voici une comparaison honnête. Aucune de ces méthodes n’est « meilleure » hors contexte : chacune l’emporte sur une tâche différente, et c’est pourquoi, sur une bordure de réseau mature, les deux fonctionnent généralement en parallèle.
| Critère | Port mirroring (Packet Sensor DPDK) | NetFlow / IPFIX | sFlow |
|---|---|---|---|
| Ce qu’il voit | 100 % des paquets | enregistrements échantillonnés issus du cache de flux | en-têtes de paquets échantillonnés |
| Échantillonnage | aucun (analyse complète) | oui + agrégation dans le cache | oui (1 sur N) |
| Délai de détection typique | RTBH après ~1 s, filtrage sélectif après 6–10 s | ~35–95 s (limite : active timeout) | ~35–95 s (toujours échantillonné) |
| Modèle de couverture | par point de mesure (TAP/SPAN) | chaque routeur qui exporte | chaque routeur qui exporte |
| Coût en bande passante | nécessite de la capacité de mirroring/TAP | indépendant de la bande passante | indépendant de la bande passante |
| Coût relatif | plus élevé par site | faible | faible |
| Angles morts | pratiquement aucun | attaques à faible volume, fragments, trous d’échantillonnage | trous d’échantillonnage |
| Idéal pour | bordures chargées, liens critiques | large couverture de nombreux POP | large couverture en quasi temps réel |
La visibilité au niveau de chaque paquet se combine bien avec la télémétrie en streaming des Juniper MX : le NOC suit la même attaque et le même filtrage sur un seul tableau de bord, quel que soit le capteur qui a levé l’alerte.
Où l’échantillonnage crée-t-il des angles morts ?
L’échantillonnage crée des angles morts parce que le Flow Sensor reconstitue le trafic de manière statistique à partir d’une fraction des paquets. Tout ce qui tient dans les intervalles entre deux échantillons risque d’être sous-estimé ou mal classé.
À 1:1000, un motif de faible intensité mais réellement nuisible (flood applicatif lent, épuisement ciblé de la table d’états) peut tout simplement ne pas accumuler assez d’échantillons pour franchir le seuil à temps. L’attaque fonctionne, le client appelle, et le graphique reste plat.
Les floods de fragments en sont l’exemple classique. Les fragments IP autres que le premier ne portent pas d’en-tête de couche 4 ; ils ne contiennent donc aucune information sur les ports TCP/UDP (RFC 791). Les enregistrements de flux peuvent ainsi les ranger dans la mauvaise catégorie ou les ignorer, et l’échantillonnage dégrade encore cette image. Le Packet Sensor sur DPDK voit directement chaque fragment ; il peut le compter précisément ou le réassembler.
La même logique s’applique aux attaques courtes : une attaque de 35 secondes ne laisse aucune chance à un active timeout de 60 secondes. L’enregistrement sera exporté après coup, quand il n’y aura plus rien à défendre.
Cela ne signifie pas que la détection par flux soit inutile : bien au contraire, sur la plupart des réseaux, c’est elle qui assure la couverture. Cela signifie seulement qu’on la place là où ses angles morts n’ont pas d’importance, et qu’on la complète par l’analyse des paquets là où ils en ont.
Quand utiliser quelle méthode ?
Choisissez la méthode en fonction de la valeur et du budget de temps de chaque lien ; dans la plupart des réseaux réels, cela signifie utiliser les deux. Il n’y a pas de vainqueur unique : il s’agit d’un compromis d’ingénierie entre le temps de réaction et le coût d’une analyse complète des paquets sur l’ensemble du réseau.
- Port mirroring (DPDK) : sur les bordures les plus chargées, sur les uplinks de peering et de transit ainsi que sur les segments des clients à plus forte valeur. Partout où quelques secondes décident si le lien sera saturé avant que vous ne réagissiez.
- Flux (NetFlow/sFlow/IPFIX) : pour une couverture large et économique de nombreux POP et routeurs internes, là où installer un TAP partout n’est pas réaliste et où une alerte un peu plus lente est acceptable.
- Les deux à la fois : la norme sur les réseaux matures, avec l’analyse des paquets pour la vitesse là où elle compte, les flux pour la couverture ailleurs, et une seule console qui corrèle les deux.
C’est exactement ainsi que nous chiffrons et concevons nos services de protection DDoS : nous associons chaque lien à une méthode de détection selon son niveau de risque, au lieu de déployer un schéma unique partout. Le périmètre du déploiement et le coût qui en découle figurent dans la grille tarifaire actuelle avec son calculateur.
Comment WanGuard prend en charge les deux méthodes de détection
WanGuard est construit précisément autour de ce modèle double, et c’est la raison pour laquelle nous l’avons choisi comme standard. Le Packet Sensor capture le trafic en miroir via DPDK, offre une visibilité complète et permet de déclencher le RTBH après environ 1 s et le filtrage sélectif après 6–10 s. Le Flow Sensor accepte NetFlow (v5/v9), sFlow (v5) et IPFIX, et assure une couverture indépendante de la bande passante à l’échelle du térabit.
Les deux alimentent le même moteur de détection et la même console ; une alerte issue de l’un ou de l’autre déclenche donc la même riposte automatique. Une description plus courte de l’architecture figure sur la page consacrée à WanGuard, et une introduction pour ceux qui débutent dans l’article qu’est-ce que WanGuard.
En pratique, vous n’avez pas à choisir un camp et à vivre avec ses angles morts. Vous placez le port mirroring avec DPDK sur les liens où un RTBH après environ 1 s et un filtrage sélectif après 6–10 s ne sont pas négociables, vous répartissez des capteurs de flux sur le reste de la bordure pour la couverture, et un seul système corrèle les deux, détecte l’attaque et la transmet au filtrage (BGP FlowSpec d’abord, RTBH seulement en dernier recours).
Il faut le dire clairement : la précision de la détection dépend toujours du réglage. Lignes de base calculées par sous-réseau, exceptions pour les clients connus à fort trafic, seuils correctement fixés. Si le réglage est bien fait, les deux méthodes produisent des alertes automatiques justes. S’il est mal fait, chacune générera des faux positifs ; le port mirroring simplement plus vite.
ITORO est partenaire Gold d’Andrisoft au niveau mondial, avec une expérience des déploiements WanGuard depuis 2014. Nous installons, réglons et maintenons les deux modes de détection sous forme de service managé, de bout en bout, au même prix partout dans le monde.
Questions fréquentes
Quelle est la méthode de détection DDoS la plus rapide ?
La plus rapide est la détection par port en miroir avec DPDK : elle détecte l’attaque et déclenche le RTBH après environ 1 s, puis le filtrage sélectif après 6–10 s. Elle analyse 100 % des paquets au débit de la ligne via une session SPAN/miroir ou un TAP optique, si bien que rien n’est échantillonné ni estimé. La détection par flux (NetFlow/sFlow/IPFIX) est moins coûteuse et couvre davantage de routeurs, mais réagit généralement au bout de 35–95 s.
Quelle différence entre le port mirroring et la détection par NetFlow ?
Le port mirroring analyse via DPDK une copie complète de chaque paquet ; il voit donc tout le trafic au débit de la ligne et détecte l’attaque assez tôt pour déclencher le RTBH après environ 1 s et le filtrage sélectif après 6–10 s. NetFlow analyse des enregistrements de synthèse échantillonnés, exportés depuis le cache de flux du routeur : il est indépendant de la bande passante et peu coûteux, mais plus lent (limité par l’active flow timeout, souvent d’environ 60 secondes) et moins détaillé.
sFlow est-il plus rapide que NetFlow pour la détection DDoS ?
Il peut l’être. sFlow envoie en continu des en-têtes de paquets échantillonnés et n’a pas de cache qui doive expirer ; il n’attend donc pas le timeout d’un flux comme NetFlow classique et IPFIX. Tous deux restent cependant échantillonnés : ils demeurent plus lents et moins précis qu’une analyse complète des paquets sur DPDK et partagent les mêmes angles morts face aux attaques à faible volume et aux floods de fragments.
Pourquoi le délai de détection est-il si important ?
Parce que les attaques volumétriques actuelles saturent un uplink en quelques dizaines de secondes. Cloudflare a enregistré une attaque record de 31,4 Tbit/s qui a duré 35 secondes (février 2026). Si votre détection réagit au bout de 35–95 s, une attaque courte peut se terminer, ou le lien être saturé, avant même que le filtrage ne démarre.
La détection par flux peut-elle manquer une attaque que le port mirroring repère ?
Oui. Les données de flux sont échantillonnées (généralement 1:1000) ; les attaques de faible intensité et les rafales courtes peuvent donc passer sous le seuil statistique. Les floods de fragments sont en outre difficiles à classer, car les fragments autres que le premier ne portent aucune information de port de couche 4. Le Packet Sensor sur DPDK voit directement chaque paquet et chaque fragment ; c’est pourquoi les liens critiques en termes de délai sont couverts par les deux méthodes à la fois.
Peut-on réduire le délai de détection avec NetFlow seul ?
En partie. Abaisser l’active flow timeout (par exemple de 60 à 10–15 secondes) et raccourcir l’intervalle d’export accélère réellement l’alerte, au prix d’un nombre accru d’enregistrements et d’une charge plus élevée sur le routeur et le collecteur. Augmenter la densité d’échantillonnage améliore la précision, mais augmente aussi le coût. Même après réglage, vous n’atteindrez pas le niveau de l’analyse des paquets : par définition, un flux décrit le trafic, il ne le montre pas.
Sources
- Cloudflare, Q4 2025 DDoS Threat Report (février 2026) : https://blog.cloudflare.com/ddos-threat-report-2025-q4/
- NETSCOUT, DDoS Threat Intelligence Report, Issue 16 / 2H 2025 (mars 2026) : https://www.netscout.com/threatreport/
- IETF, RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol : https://www.rfc-editor.org/rfc/rfc7011
- IETF, RFC 3176, InMon Corporation's sFlow : https://www.rfc-editor.org/rfc/rfc3176
- IETF, RFC 791, Internet Protocol (fragmentation IP) : https://www.rfc-editor.org/rfc/rfc791
- DPDK, documentation du Data Plane Development Kit : https://doc.dpdk.org/guides/
- Andrisoft, WanGuard, documentation produit : https://www.andrisoft.com/software/wanguard
