6 octobre 2026
·
9 min de lecture
Le port mirroring détecte une attaque DDoS : RTBH après env. 1 s, filtrage après 6–10 s ; NetFlow avec 35–95 s de retard. Délai, coût et charge du routeur.
En bref : avant de construire toute protection DDoS, vous devez décider d’où proviennent vos données de trafic. Le port mirroring offre une visibilité complète sans délai et permet de détecter une attaque et de déclencher le RTBH après environ 1 s, le filtrage sélectif après 6–10 s, mais il exige des ports libres et du câblage. NetFlow / IPFIX / sFlow ne nécessite aucun port supplémentaire et s’adapte à un réseau de n’importe quelle taille, mais au prix d’un délai de 35–95 s dû à l’export des flux, avec en outre une erreur d’échantillonnage. Dans un réseau de petite ou moyenne taille, choisissez le port mirroring partout où vous disposez de ports ; réservez NetFlow aux endroits où copier l’intégralité du trafic est physiquement impossible.
Il s’agit de la première décision d’architecture, et non d’un détail de mise en œuvre. La méthode de collecte fixe la limite de votre rapidité de réaction : aucun filtre ne peut agir avant que vous ayez connaissance de l’attaque.
Pourquoi le temps de détection est-il déterminant ?
Une attaque volumétrique sature un lien en quelques dizaines de secondes. Si les données de trafic parviennent au sensor avec un retard comparable à la durée de l’attaque elle-même, la défense réagit sur des ruines. Nous l’avons décrit en détail dans notre article sur une attaque DDoS contre un FAI vue depuis le NOC.
D’où vient le délai de NetFlow ? Le routeur n’envoie pas immédiatement l’information sur un paquet. Il construit les entrées de flux en mémoire, les agrège et ne les exporte qu’à l’expiration de timeouts définis : active flow timeout et inactive flow timeout. S’y ajoute le temps de traitement des datagrammes côté sensor. En pratique, 35–95 s s’écoulent entre le premier paquet de l’attaque et le moment où le système peut le voir.
Avec le port mirroring, cette étape n’existe pas : le commutateur ou le routeur copie les paquets vers le port de monitoring au moment même où il les commute. D’où l’écart : RTBH après environ 1 s et filtrage sélectif après 6–10 s, contre 35–95 s. Face aux attaques impulsionnelles courtes, de moins de 30 secondes, c’est cet écart qui décide si l’attaque sera remarquée ou non.
En quoi le port mirroring diffère-t-il de NetFlow ?
| Critère | Port mirroring (copie du trafic) | NetFlow / IPFIX / sFlow / jFlow |
|---|---|---|
| Temps de détection | RTBH après environ 1 s, filtrage sélectif après 6–10 s | 35–95 s (export des flux) |
| Visibilité | 100 %, chaque paquet | échantillonnée, un paquet sur n |
| Précision pendant une attaque | complète | faible erreur, croissante avec l’échantillonnage |
| Charge du routeur | minimale, copie passive | sensible, la génération des flux consomme du CPU |
| Câblage | ports et câbles nécessaires | aucun câble supplémentaire |
| Couche | fonctionne indépendamment de la couche 3 | plus simple sur les équipements L3 |
| Évolutivité | limitée par le nombre de ports | pratiquement illimitée |
| Attaques impulsionnelles (<30 s) | détectées | souvent invisibles |
| Coût de mise en œuvre | ports, câbles, éventuellement TAP | généralement nul, fonction de l’équipement |
Deux points sont faciles à négliger lors de la planification.
Premièrement, le port mirroring copie le trafic dans les deux sens. Un lien à 5 Gbit/s en RX plus 5 Gbit/s en TX donne 10 Gbit/s sur le port de monitoring : si celui-ci a le même débit que le port surveillé, vous commencerez à perdre des paquets à pleine charge. C’est l’erreur la plus fréquente lors d’un premier déploiement.
Deuxièmement, le mirroring de plusieurs ports ou VLAN simultanément est soumis aux limites de la plateforme : nombre de sessions, sens pris en charge, coexistence avec d’autres fonctions. Consultez la documentation de votre matériel (Cisco : SPAN/RSPAN/ERSPAN et limites des plateformes Nexus ; Juniper : limites du port mirroring sur les commutateurs EX).
Quelle erreur l’échantillonnage NetFlow introduit-il ?
Moins importante que ne le laisse penser l’intuition. Selon la présentation Cisco Live BRKSPG-3335 (« DDoS Mitigation Deployment: Impact on your Architecture », Nicolas Fevrier, Rajendra Chayapathi, Syed Hassan), la modification du taux d’échantillonnage a peu d’effet sur la capacité à détecter l’attaque, même si elle introduit une erreur de mesure. Pour une attaque générique de type flood (paquets de 84 octets, attaque distribuée de 100 Mbit/s par interface du routeur) :
| Échantillonnage | Erreur |
|---|---|
| 1:1 000 | 2,1 % |
| 1:2 000 | 2,9 % |
| 1:4 000 | 2,9 % |
| 1:10 000 | 6,5 % |
Conclusion pratique : lors d’une attaque volumétrique importante et prolongée, même un échantillonnage de 1:10 000 suffit pour constater qu’« il se passe quelque chose ». Le problème n’est donc pas la précision du volume, mais le délai et l’invisibilité des phénomènes rares : une attaque répartie sur tout un sous-réseau, dans laquelle aucune adresse ne dépasse individuellement le seuil, peut se perdre dans le bruit avec un échantillonnage agressif.
Que faire en l’absence de ports libres ?
Il existe deux solutions, toutes deux utilisées en production.
TAP optique, passif ou actif. Si vous n’avez plus de ports ou si NetFlow ne fonctionne pas comme il le devrait, l’insertion d’un TAP sur le chemin optique fournit une copie du trafic sans solliciter le routeur. Un TAP passif ne nécessite pas d’alimentation et n’introduit pas de point de défaillance ; un TAP actif offre davantage de possibilités (régénération du signal, agrégation des sens), mais doit être alimenté. Pour répartir la copie entre plusieurs systèmes d’analyse, on utilise un packet broker.
Trafic échantillonné au lieu d’une copie complète. Si le réseau est grand et que vous ne pouvez pas vous permettre de mirrorer chaque port WAN, le routeur peut envoyer au sensor un paquet sur dix : 30 Gbit/s deviennent alors 3 Gbit/s à analyser.
L’analyse de la copie du trafic nécessite, côté sensor, un moteur de capture de paquets. WanGuard en prend en charge plusieurs variantes, qui diffèrent par le débit, le coût et la complexité de mise en œuvre :
| Moteur de capture | Débits | Coût | Complexité |
|---|---|---|---|
| Embedded LibPcap | 1–4 Gbit/s | aucun | nulle |
| System LibPcap | 1–4 Gbit/s | aucun | nulle |
| Myricom Sniffer 10G | 10 Gbit/s | licence par carte | moyenne |
| PF_RING | 10/40 Gbit/s | licence par adresse MAC | module noyau supplémentaire / moyenne |
| Netmap | 10/40 Gbit/s | aucun | module noyau supplémentaire / élevée |
| DPDK | 10/40 Gbit/s | aucun | module noyau supplémentaire / élevée |
Règle pratique : jusqu’à 4 Gbit/s, LibPcap suffit. Au-delà, il faut un moteur qui contourne la pile réseau du noyau, sinon le sensor commencera à perdre des paquets précisément au moment où vous en avez le plus besoin, c’est-à-dire pendant une attaque. Nous décrivons le rôle du sensor dans l’architecture dans l’article qu’est-ce que WanGuard.
Quelle méthode choisir pour votre réseau ?
Deux variables doivent servir de point de départ : les types d’attaques auxquels vous vous attendez et le débit que vous devez observer. Règle de décision simplifiée :
- Vous avez des ports libres et moins d’une quinzaine de Gbit/s en bordure : port mirroring. Temps de détection le plus court, charge minimale sur le routeur, le moins de surprises.
- Grand réseau, nombreux ports WAN, plusieurs dizaines de Gbit/s : NetFlow / IPFIX, éventuellement complété par du mirroring sur les liens les plus critiques.
- Pas de ports disponibles et un NetFlow au comportement étrange : TAP optique.
- Vous voulez vous protéger des attaques impulsionnelles courtes : mirroring ou trafic échantillonné. Le NetFlow classique n’a tout simplement pas le temps de les faire apparaître.
Les solutions ne s’excluent pas : un déploiement type chez un FAI de taille moyenne combine les deux, avec le mirroring là où le temps de réaction compte et NetFlow pour couvrir le reste du réseau et alimenter le reporting ainsi que la planification de capacité des liens. Si vous hésitez sur la variante adaptée à votre topologie, contactez-nous : le choix de la méthode de collecte est la première étape de tout déploiement de WanGuard.
Questions fréquentes
Le port mirroring charge-t-il le routeur ?
Faiblement. La copie d’une trame vers le port de monitoring est généralement assurée par le circuit de commutation, et non par le CPU. La génération de flux pour NetFlow est bien plus coûteuse, car elle impose de maintenir une table de flux et d’effectuer des exports périodiques. Attention aux exceptions : sur certaines plateformes, le mirroring de plusieurs VLAN ou de plusieurs sens simultanément peut faire basculer le traitement sur un chemin plus lent.
De quelle bande passante le port de monitoring a-t-il besoin ?
De la somme des deux sens du lien surveillé. Un lien à 5 Gbit/s en RX + 5 Gbit/s en TX produit 10 Gbit/s de copie. Un port de monitoring du même débit que le port surveillé commencera à perdre des paquets dès que la charge augmente : prévoyez de la marge ou répartissez les sens sur des ports distincts.
sFlow suffit-il pour détecter les attaques DDoS ?
Pour détecter une attaque volumétrique importante, oui : l’échantillonnage introduit une erreur de quelques pour cent, ce qui n’empêche pas de constater que le lien est saturé. Pour détecter des attaques courtes, de faible volume ou réparties sur tout un sous-réseau, généralement non. Il faut alors une visibilité complète.
Pourquoi un TAP si j’ai déjà le port mirroring ?
Un TAP est utile dans trois situations : lorsque vous n’avez plus de ports libres, lorsque vous ne voulez pas charger un équipement de production avec une fonction supplémentaire, et lorsque vous avez besoin d’une copie du trafic indépendante de la configuration du routeur. Un TAP passif continue de fonctionner même si l’équipement redémarre ou si quelqu’un supprime la session de mirroring.
