6 octobre 2026
·
12 min de lecture
Avant le déploiement d’une protection DDoS : routage sans boucle, collecte du trafic, serveurs et seuils. Liste de contrôle pour FAI et datacenters.
En bref : avant d’activer le filtrage du trafic DDoS, vous devez préparer trois éléments, à savoir un routage qui ne fera pas boucler le trafic redirigé, une méthode de collecte des données de trafic (port mirroring, sFlow ou NetFlow/IPFIX) et des serveurs pour la console ainsi que pour les sensors et les filtres. Si votre routeur prend en charge BGP FlowSpec, le premier et le troisième point se simplifient radicalement : plus de VRF, plus de tunnels GRE, plus de serveur de filtrage dédié. D’après notre expérience, c’est cette préparation côté client, et non l’installation elle-même, qui représente environ 90 % de la durée du déploiement d’une protection DDoS.
Ce texte est une liste de contrôle. Parcourez-la avant la première réunion : elle raccourcira le déploiement de plusieurs semaines.
Par où commencer : en quoi une protection diffère-t-elle du RTBH ?
Avant de préparer quoi que ce soit, définissez précisément ce que vous déployez. Lorsqu’elles parlent de « protection DDoS », la plupart des équipes pensent au RTBH (Remotely Triggered Black Hole), parce que c’est le seul mécanisme dont elles disposaient.
Le RTBH n’est pas une protection. Il coupe le trafic vers l’adresse attaquée ; du point de vue du client final, l’effet est identique à celui d’une attaque réussie : le service ne fonctionne plus. L’attaquant atteint son objectif, simplement par vos propres mains. Le RTBH a du sens pour sauver le reste du réseau au prix d’une ou de quelques adresses, lorsqu’il n’est plus possible de faire mieux. Nous détaillons quand y recourir dans notre article sur le RTBH.
Ce dont vos clients ont réellement besoin, c’est d’un filtrage du trafic : supprimer les paquets d’attaque tout en maintenant la continuité des communications, sans interruption ni latence perceptible.
Deuxième situation fréquente : le client dispose déjà d’un outil gratuit, mais déclenché par un script ou manuellement par un administrateur. Cela fonctionne exactement tant que quelqu’un surveille les graphes, donc pas à trois heures du matin ni le week-end. Le passage à la détection et au filtrage automatiques est généralement le moment où les équipes réseau se tournent vers nous et vers WanGuard.
Liste de contrôle : que préparer avant le déploiement de la protection DDoS
Trois domaines, dans cet ordre :
| Domaine | Concrètement | Responsable |
|---|---|---|
| Routage | possibilité de séparer les tables de routage pour que le trafic redirigé ne reparte pas en boucle, ou routeur BGP FlowSpec qui ne l’exige pas | Votre équipe réseau |
| Collecte du trafic | port mirroring, sFlow ou NetFlow/IPFIX acheminé jusqu’au sensor ; avec le port mirroring, également une carte et un port de capacité suffisante | Votre équipe réseau |
| Serveurs | une machine pour la console et des machines pour les sensors et les filtres ; accès distant pour l’équipe de déploiement | Votre équipe + ITORO |
Voici le détail des points qui posent le plus de difficultés en pratique.
Pourquoi la redirection du trafic risque-t-elle de créer une boucle de routage ?
C’est la partie la plus difficile d’un déploiement dans un réseau sans BGP FlowSpec, et la raison la plus fréquente pour laquelle le projet s’éternise.
Le mécanisme est simple. Lorsque le système détecte une attaque, il envoie au routeur une mise à jour BGP qui redirige le trafic destiné au préfixe attaqué vers le serveur de filtrage. Le serveur élimine l’attaque et réinjecte le trafic propre dans le réseau. Le problème : ce trafic arrive dans la même table de routage, où la redirection vers le serveur de filtrage est toujours active. Le paquet retourne au filtre. Puis encore. Et encore.
La solution consiste à séparer les tables de routage à l’aide de VRF (Virtual Routing and Forwarding). Un projet type en nécessite trois :
- Table de bordure BGP : elle reçoit tous les préfixes des opérateurs de transit.
- Table d’entrée du filtre : une VRF avec une route par défaut pointant vers le serveur de filtrage.
- Reste du réseau : sous-réseaux clients et services, sans visibilité sur les préfixes Internet du point 1.
Une redirection par tunnels GRE est parfois proposée comme alternative, mais elle ne supprime pas le problème : elle le déplace seulement.
Le fait est qu’une telle refonte du routage est une opération à cœur ouvert. Vous la réalisez sur un réseau en service, avec du trafic de production et des services qui ne doivent pas être interrompus. Cela demande une fenêtre de maintenance dédiée, un plan de retour arrière et quelques nuits blanches. Si vous lisez ce paragraphe en pensant « chez nous, ce n’est pas faisable dans un délai raisonnable », vous avez raison, et c’est pour cela qu’existe la section suivante.
Que simplifie BGP FlowSpec ?
Si vous disposez d’un routeur compatible BGP FlowSpec ou prévoyez d’en acheter un, vous pouvez ignorer toute la section précédente. FlowSpec résout deux problèmes majeurs à la fois :
- Plus de problème de boucle. Vous ne redirigez le trafic nulle part : la règle de filtrage est installée directement sur l’interface du routeur. Rien ne peut boucler, il n’est donc pas nécessaire de construire des VRF.
- Plus de serveur de filtrage. Le filtrage s’effectue en matériel, au débit de l’interface. Qu’il s’agisse de 10, 40 ou 100 GE n’a pas d’importance : la charge CPU du routeur reste négligeable.
Cela se traduit directement dans le budget : vous n’achetez ni serveurs de filtrage ni cartes réseau spécialisées, vous ne refondez pas le routage et vous ne payez pas des semaines de travail sur un projet réseau. Vous trouverez à quoi ressemble une règle FlowSpec en pratique et quels critères elle peut utiliser dans notre article sur le filtrage des attaques DDoS par BGP FlowSpec.
Une réserve issue du terrain : il ne suffit pas que le constructeur annonce la prise en charge de FlowSpec. Les plateformes ne programment pas toutes les règles en matériel de la même manière ; vérifiez-le sur le modèle et la version logicielle précis avant de signer la commande. Les constructeurs dont FlowSpec fonctionne en pratique dans les réseaux de nos clients sont Arista, Cisco, Huawei, Juniper et Nokia.
Comment collecter les données de trafic ?
Le sensor doit voir le trafic. Deux voies s’offrent à vous :
- Port mirroring : une copie de l’ensemble du trafic arrive sur la carte du sensor. C’est le temps de réaction le plus court, car le sensor voit les paquets au même instant que le routeur. Cela exige un port libre de capacité suffisante et une carte réseau côté serveur.
- NetFlow / IPFIX / sFlow : le routeur exporte des échantillons ou des résumés de flux. C’est moins cher et plus simple, mais l’export introduit un délai de 35–95 s, et l’échantillonnage sous-estime les volumes de petits paquets.
Face aux attaques volumétriques, cette différence est déterminante : un réseau peut tomber en quelques dizaines de secondes, c’est-à-dire le temps qu’il faut à NetFlow pour exporter ses premiers flux. Si vous avez le choix, optez pour le port mirroring et gardez NetFlow en complément pour le reporting et la planification des liens.
Installation et réglage : ce que nous faisons ensemble
Une fois les serveurs prêts et le trafic acheminé jusqu’au sensor, l’installation proprement dite est rapide. Le périmètre des travaux est le suivant :
- Installation des composants : console (GUI), sensors et filtres. Établissement des sessions BGP entre le serveur de la console et les routeurs (par exemple via ExaBGP). Nous en décrivons les détails dans notre guide d’installation de WanGuard.
- Définition des sous-réseaux et des modèles de seuils : séparément pour chaque type d’environnement (clients finaux, serveurs d’hébergement, services internes). Le trafic d’un abonné ne ressemble pas à celui d’un serveur de messagerie, et les seuils doivent en tenir compte.
- Exclusions : il faut parfois exclure de la protection certaines adresses ou certains réseaux pour ne pas risquer de violer un SLA. Exemple typique : les serveurs de cache Google ou d’autres systèmes proxy qui échangent des données à haut débit sur un lien fermé ou de peering, suffisamment sûr pour justifier une telle exception.
Les seuils initiaux changent toujours. Ce n’est pas un défaut, c’est le cycle de vie normal d’un déploiement. Les premiers réglages sont un point de départ ; au cours des semaines suivantes, vous les ajustez aux profils de trafic réels jusqu’à ce que le système distingue le niveau normal du niveau anormal pour chaque segment du réseau. L’objectif de ce réglage est de limiter les fausses alertes, qui déclencheraient inutilement le RTBH ou le filtrage sur du trafic légitime.
En situation de crise (un client sous une série d’attaques, pratiquement invisible sur Internet), nous avons pu mettre en service un filtrage opérationnel avec BGP FlowSpec en moins de 48 heures. La condition était toujours la même : un serveur prêt et le port mirroring, ou une autre méthode de collecte du trafic, raccordé et fonctionnel.
En résumé : une question avant le premier échange
Avant de comparer les solutions anti-DDoS, posez-vous la question suivante : mon routeur de bordure prend-il en charge BGP FlowSpec ? La réponse détermine si le déploiement sera un projet réseau de plusieurs semaines ou une installation de quelques jours.
Si vous prévoyez de remplacer vos équipements de bordure prochainement, la prise en charge de BGP FlowSpec doit figurer parmi les exigences obligatoires du cahier des charges, que vous déployiez la protection maintenant ou dans deux ans. C’est un seul paramètre, qui vous épargnera plus tard des serveurs, une refonte du routage et du temps.
C’est par ce point que nous commençons chaque premier échange. Les tarifs à jour et le calculateur, sans « demandez un devis », sont disponibles sur la page Tarifs.
Questions fréquentes
Combien de temps dure le déploiement d’une protection anti-DDoS ?
Cela dépend presque exclusivement de l’état de préparation du réseau. Avec un routeur BGP FlowSpec, un serveur prêt et une collecte du trafic raccordée, un filtrage opérationnel peut démarrer en quelques jours, et en mode crise en moins de 48 heures. Sans FlowSpec s’ajoute une refonte du routage avec des VRF, qui constitue en soi un projet réseau distinct.
Ai-je besoin d’un serveur de filtrage si je dispose de BGP FlowSpec ?
Non. Avec un filtrage fondé sur FlowSpec, les règles s’installent directement sur les interfaces du routeur et s’exécutent en matériel ; un serveur de filtrage dédié et des cartes réseau spécialisées deviennent donc inutiles. Il vous faut toujours un serveur pour la console et le sensor, mais la dépense est nettement moindre.
Quelle méthode privilégier pour la détection : port mirroring ou NetFlow ?
Le port mirroring, si le temps de réaction compte pour vous : le sensor voit les paquets immédiatement, sans attendre l’export des flux. NetFlow, IPFIX et sFlow sont moins chers et plus simples à mettre en place, mais le délai d’export et l’échantillonnage font que, face à des attaques volumétriques rapides, la réaction arrive après coup. De nombreux réseaux utilisent les deux méthodes en parallèle.
Dois-je exclure certaines adresses de la protection ?
Parfois, oui. Les systèmes qui génèrent des volumes très élevés mais légitimes (serveurs de cache des grands fournisseurs de contenu, systèmes proxy échangeant des données via le peering) peuvent ressembler à une anomalie pour le système de détection. Si le lien qui les dessert est fermé ou de peering et suffisamment sûr, les exclure de la protection coûte moins cher que d’avoir à expliquer de fausses alertes.
Quel est le meilleur moment pour parler de protection DDoS ?
Avant le remplacement du routeur de bordure, et non après. Le choix d’un équipement avec ou sans BGP FlowSpec détermine l’architecture de protection pour les années suivantes, ainsi que le coût de sa mise en service. Le deuxième bon moment est la planification budgétaire : c’est là qu’il est le plus simple d’ajouter une ligne au cahier des charges.
