6 octobre 2026 · 16 min de lecture

Quelques dizaines de secondes, et tout l’hébergement tombe. Attaque DDoS contre un FAI : limites du pare-feu et du RTBH, et ce que change NIS2.

En bref : une attaque DDoS typique fait tomber les services en quelques dizaines de secondes, soit plus vite qu’un humain ne peut se connecter au routeur. Les règles manuelles et le RTBH ne sont pas une protection, mais une coupure contrôlée du client. Une protection réelle consiste à détecter en quelques secondes et filtrer le trafic, de sorte que le service reste disponible pendant l’attaque. Pour les petits et moyens FAI, c’est aujourd’hui d’un ordre de grandeur moins cher qu’une appliance clé en main, et depuis 2024 ce n’est plus un choix mais une obligation légale.

Voici une histoire qui s’est réellement produite, et ce qu’il en est resté dans nos procédures.

Quelques dizaines de secondes

La journée s’annonçait calme. Un sandwich salade-fromage attendait sur le bureau, le thé refroidissait dans la tasse. Tom jeta machinalement un coup d’œil à l’écran suspendu au plafond. Puis au sandwich. Puis de nouveau à l’écran.

Quelque chose n’allait pas. Mais alors, pas du tout.

Il se leva de son fauteuil plus vite qu’il ne l’aurait voulu, s’appuya d’une main sur le bureau et se gratta la tête de l’autre. Il travaillait dans la sécurité réseau depuis des années et les attaques DDoS n’avaient rien de nouveau pour lui. Celle-ci, pourtant, le surprit par son ampleur et son intensité.

Les cibles avaient été choisies avec précision : de grands portails et des boutiques en ligne appartenant au plus gros client de l’entreprise. Les services ne résistèrent pas au volume de trafic. Avant que Tom ait pu réagir, les sites des autres clients commencèrent à tomber à leur tour, ceux que personne n’attaquait. Un lien saturé ne demande pas qui est la cible.

Le système déclencha une alerte. Le pare-feu complété à la main ne servit à rien cette fois : l’attaque avait fait son œuvre en quelques dizaines de secondes, et les dégâts ne pouvaient plus être réparés sur place.

Les premiers appels arrivèrent au bout de quelques minutes. Des administrateurs inquiets demandaient pourquoi leurs sites avaient disparu d’Internet. Les heures suivantes furent l’exact opposé d’une journée de travail tranquille.

C’est alors que Tom se promit que, cette fois, il parlerait sérieusement à la direction.

Pourquoi « on va acheter du matériel » ne mène généralement à rien

La direction réagit comme dans un manuel : lancez un appel d’offres.

Les offres reçues atteignaient des montants considérables : c’était, à l’époque, le prix de la sécurité. Même si l’entreprise avait décidé d’un tel investissement, ses clients en auraient de toute façon supporté le coût. Les prix de l’hébergement auraient augmenté, la compétitivité aurait baissé, et les clients seraient partis chez des concurrents qui continuent de prendre le risque et restent vulnérables.

Une impasse classique. Et la raison la plus fréquente pour laquelle, après un incident majeur, rien ne se passe, en dehors d’une note « à étudier l’an prochain ».

Cette fois, Tom ne lâcha pas. Cette affaire lui avait coûté trop de nerfs. Il fit des recherches sérieuses, interrogea les bonnes personnes, et c’est ainsi qu’il arriva jusqu’à nous.

Nous sommes ITORO.

Nous aidons les petits et moyens FAI à réduire le coût de leur protection contre les attaques DDoS d’un facteur compris entre une dizaine et plusieurs dizaines par rapport aux solutions matérielles clé en main, très coûteuses. Nous sommes partenaire Gold certifié d’Andrisoft, dont le logiciel protège des milliers de réseaux dans le monde.

Ce qui a changé depuis cette attaque DDoS

La journée décrite remonte à quelques années. Le mécanisme de l’attaque n’a pas changé ; c’est l’environnement qui a changé, et suffisamment pour le détailler point par point.

L’attaque est devenue un service que l’on achète. Il suffit désormais de savoir utiliser un navigateur et un portefeuille de cryptomonnaie. Cela a changé le profil de l’attaquant : aujourd’hui, ce n’est plus seulement un concurrent ou un joueur mécontent, mais aussi quelqu’un de totalement aléatoire.

Le DDoS de rançonnage est apparu. Une courte attaque de démonstration, suivie d’un e-mail exigeant une rançon avant une échéance. Nous avons observé de telles campagnes menées en série, selon un calendrier, contre des listes entières d’opérateurs d’un même pays simultanément. Qui dispose d’un filtrage met l’e-mail à la corbeille. Qui n’en dispose pas négocie.

On attaque des sous-réseaux entiers, et non plus des adresses isolées. La technique dite du carpet bombing répartit le trafic sur tout un /24 ou /22, de sorte qu’aucune adresse ne dépasse individuellement le seuil d’alerte. La détection classique « par IP » ne la voit pas, et un RTBH sur une seule adresse n’a rien à couper.

Le DDoS n’est plus seulement un problème technique. Nous y revenons plus bas, car c’est le changement le plus important.

Comment fonctionne WanGuard

WanGuard se compose de deux modules principaux : le sensor et le filter.

Sensor : la détection

Le sensor collecte les informations sur le trafic via NetFlow / IPFIX / sFlow ou analyse une copie de l’ensemble du trafic (port mirroring). Cette seconde méthode réduit le temps de réaction à une attaque à 5 secondes au maximum.

La différence est fondamentale. Avec NetFlow, vous attendez l’export des flux depuis le routeur : avant même que les données n’atteignent le sensor, plusieurs dizaines de secondes se sont écoulées. Soit exactement le temps qu’il a fallu pour mettre le réseau à terre dans l’histoire ci-dessus. Avec le port mirroring, le sensor voit les paquets au même instant que le routeur.

Au-delà de la sécurité, ce module peut réellement réduire les coûts. Grâce à la rétention des données et à un reporting détaillé du trafic entre réseaux BGP, vous pouvez mieux planifier l’achat de liens à partir de l’analyse du trafic réel plutôt que d’estimations. Lors de nos déploiements, nous aidons à optimiser les coûts de transit ; selon le périmètre, les économies potentielles peuvent dépasser le coût de l’investissement lui-même.

Filter : le filtrage

Nous réalisons le filtrage du trafic soit sur un serveur de filtrage, soit avec le protocole BGP FlowSpec sur le routeur BGP. Pour les serveurs, nous utilisons des cartes réseau spéciales prenant en charge le filtrage matériel à 10/40/100 GE. Il s’agit d’une forme très avancée de filtrage du trafic.

La plupart des méthodes de filtrage nécessitent une redirection du trafic. Dans un réseau à routeur unique, cela peut poser problème et risque de créer des boucles de routage. Il existe plusieurs solutions, des plus simples aux plus complexes, qui exigent alors des modifications importantes du réseau et du routage. C’est précisément à ce stade qu’il est utile de s’appuyer sur quelqu’un qui l’a déjà fait.

Nous détaillons l’architecture sur notre page consacrée à WanGuard.

Le RTBH n’est pas une protection. C’est une capitulation contrôlée

Certaines entreprises fondent encore la défense de leur réseau uniquement sur le RTBH (Remotely Triggered Black Hole). Ce n’est pas une solution fiable, mais une forme très primitive et inefficace de lutte contre une attaque.

Pourquoi ? Parce que le blackholing met fin à l’attaque en l’achevant à la place de l’attaquant. Vous coupez l’adresse IP attaquée du reste du monde. L’attaquant voulait rendre ce service indisponible, et vous venez de le faire pour lui, de vos propres mains.

Du point de vue de l’utilisateur

Rien ne compte davantage qu’un accès Internet stable et permanent. C’est particulièrement vrai pour les joueurs en ligne, un groupe de clients cibles en croissance. Les joueurs sont les plus exposés aux attaques de leurs adversaires, et un fournisseur d’accès peut avoir de sérieux problèmes s’il n’applique aucune forme de protection.

Et voici le point essentiel : pour un joueur, le déclenchement du RTBH est exactement la même sanction qu’une attaque réussie. Dans les deux cas, il est éjecté de la partie et subit une coupure de plusieurs minutes. De son point de vue, il n’y a aucune différence, et c’est à vous qu’il paie son abonnement.

Quand le RTBH a du sens

En dernier recours, pas en première ligne. La solution au problème est le filtrage des attaques DDoS. La seule exigence est une capacité d’uplink suffisante pour absorber à la fois votre propre trafic et l’attaque. Les entreprises protégées par WanGuard disposant de liens de plus de 2–3 Gbit/s sont en mesure de filtrer la plupart des attaques qui tiennent dans la capacité disponible de leurs uplinks, sans aucune interruption d’accès pour leurs clients.

Pour des attaques plus importantes, il reste le RTBH ou un scrubbing center avec redirection du sous-réseau attaqué (/24). Mais chaque attaque de ce type et chaque redirection se paient cher, et c’est un coût difficile à prévoir dans un budget.

Filtrage chez l’opérateur : EDGE BGP FlowSpec

Il existe une troisième voie qui, en 2021, n’existait tout simplement pas sous cette forme sur le marché polonais.

Si l’attaque dépasse la capacité de votre uplink, aucun équipement de votre salle serveurs ne pourra la filtrer : les paquets satureront le lien avant de l’atteindre. On ne triche pas avec la physique. Le trafic doit être arrêté en amont, chez l’opérateur.

En Pologne, Orange Polska accepte les règles de filtrage BGP FlowSpec en bordure de son réseau. Une règle générée par WanGuard peut ainsi être poussée non seulement vers votre propre routeur, mais aussi vers l’opérateur, et le trafic est rejeté avant même d’atteindre votre lien. Sans couper le client, sans blackholing, sans frais de redirection.

Cela change l’équation : la limite haute de ce que vous pouvez filtrer n’est plus fixée par votre uplink. Plus d’informations sur cette coopération sur la page Partenaires.

NIS2 : le DDoS n’est plus seulement un problème informatique

C’est le changement le plus important depuis l’histoire racontée, et la raison pour laquelle la discussion avec la direction est aujourd’hui tout autre.

La directive NIS2 et sa transposition en droit national (en France, sous la supervision de l’ANSSI) ont fait passer la résilience face aux DDoS de la catégorie « bonne pratique » à celle d’obligation dont la direction répond personnellement. Pour les entités essentielles, les amendes peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

S’y ajoutent des délais impossibles à respecter sans préparation :

  • 24 heures : alerte précoce au CSIRT (en France, le CERT-FR de l’ANSSI)
  • 72 heures : notification de l’incident proprement dite

Mesurez ce que cela signifie en pratique. Pour notifier un incident en 24 heures, il faut d’abord le détecter, le qualifier et le documenter. Sans système qui enregistre précisément ce qui s’est passé (quel vecteur, quel volume, quelles adresses, à quelle heure), la notification se résume à « nous avons eu une attaque, il nous semble ». Ce n’est pas un rapport qui clôt le dossier.

La rétention et le reporting du sensor ne sont donc plus un simple « bonus ». Ils sont devenus une preuve.

En France, la notification d’un incident relevant de NIS2 s’adresse à l’ANSSI : préparez à l’avance les contacts, les délais et le contenu attendu de la déclaration.

Disponibilité des services et coût

Le déploiement d’une protection anti-DDoS chez un FAI ou dans un datacenter est une nécessité. Il peut toutefois entraîner des coûts d’acquisition et d’exploitation élevés. Ce n’est pas une fatalité.

Avec WanGuard, ce coût est étonnamment bas. Même les plus petits réseaux peuvent bénéficier de ce type de protection, sans abonnement mensuel élevé ni investissement matériel considérable.

Grâce à nos solutions, une protection complète avec filtrage du trafic DDoS d’une capacité de n × 10–40 GE devient accessible aux petits et moyens FAI. Elle évolue selon la taille du réseau et le volume du trafic Internet. Nos solutions sont utilisées par des opérateurs en Pologne et à l’étranger, qui réalisent ainsi d’importantes économies tout en offrant à leurs clients un niveau de sécurité élevé.

Nos prix sont publics, sans « demandez un devis » et sans négociation selon l’urgence de votre situation. Les tarifs à jour et le calculateur se trouvent sur la page Tarifs.

Les leçons de cette journée

Les mécanismes de protection méritent d’être anticipés et déployés progressivement. La protection et la prévention coûteront toujours moins cher que les pertes causées par les attaques. C’est particulièrement sensible dans les datacenters, où les clients partent presque immédiatement après de tels incidents.

Quelques éléments ont tout décidé dans cette histoire :

  1. Le temps de détection compte plus que la puissance de filtrage. Le meilleur filtre activé au bout de deux minutes ne protège plus que des ruines.
  2. Les réactions manuelles ne fonctionnent pas. Non pas parce que l’administrateur est mauvais, mais parce qu’un humain n’a pas le temps. Quelques dizaines de secondes ne suffisent pas pour se connecter et poser un diagnostic.
  3. Ceux que personne n’attaquait sont aussi des victimes. Un lien saturé fait tomber tous les clients qui se trouvent derrière.
  4. Le RTBH est un plan de secours, pas un plan.
  5. Sans documentation de l’incident, pas de notification, et sans notification dans les délais, un risque de sanction.

Notre longue expérience du marché des FAI nous permet d’aborder chaque réseau de façon individuelle et de choisir la variante la plus économique. Découvrez notre offre et contactez un consultant.

Notre mission est de fournir une protection contre les attaques DDoS à un prix accessible à tous les FAI et fournisseurs de contenu, quelle que soit la taille de leur réseau et le volume de leur trafic.

Questions fréquentes

Combien de temps faut-il à une attaque DDoS pour faire tomber les services ?

Dans le cas décrit, quelques dizaines de secondes. Lors d’une attaque volumétrique visant à saturer le lien, le temps se compte en secondes, pas en minutes. C’est pourquoi une détection fondée sur NetFlow (plusieurs dizaines de secondes de délai dues à l’export des flux) réagit souvent après coup, alors que le port mirroring ramène ce délai à 5 secondes au maximum.

Un pare-feu suffit-il à se protéger contre les DDoS ?

Non. Le pare-feu se trouve derrière le lien : si l’attaque sature l’uplink, les paquets engorgent le lien avant même de l’atteindre. De plus, un pare-feu maintient l’état des sessions ; lors d’une attaque de type SYN flood, il devient lui-même une cible et tombe en premier. Le trafic doit être filtré en amont du pare-feu ou, pour les attaques plus importantes, chez l’opérateur.

Le RTBH protège-t-il contre une attaque DDoS ?

Le RTBH arrête l’attaque, mais au détriment de la disponibilité de l’adresse attaquée. Vous coupez l’IP du reste du monde ; du point de vue du client, l’effet est donc le même qu’une attaque réussie, puisque le service ne fonctionne plus. C’est une dernière ligne de défense raisonnable face aux attaques qui dépassent la capacité du lien, mais ce n’est pas une protection. La protection, c’est le filtrage, après lequel le service continue de fonctionner.

Une petite entreprise ou un petit FAI est-il une cible réelle ?

Oui, pour deux raisons. Premièrement, une attaque s’achète aujourd’hui pour une somme modique : la barrière d’entrée pour l’attaquant est pratiquement inexistante. Deuxièmement, lors d’attaques sur des sous-réseaux entiers (carpet bombing) et en cas de saturation d’un lien partagé, ce sont des clients qui n’étaient pas visés qui en pâtissent. Il n’est pas nécessaire d’être la cible pour subir des pertes.

Combien coûte une protection DDoS pour un FAI ?

Une solution fondée sur WanGuard coûte généralement de dix à plusieurs dizaines de fois moins cher qu’une appliance anti-DDoS dédiée de performance comparable. Le montant exact dépend du débit, du nombre de sensors et de la variante de filtrage choisie. Nous publions l’intégralité de nos tarifs avec un calculateur : consultez la page Tarifs.

La protection DDoS est-elle exigée par NIS2 ?

NIS2 ne cite aucune technologie précise, mais exige une gestion des risques, une continuité d’activité et un traitement des incidents, et pour un opérateur de réseau, le DDoS fait partie des risques fondamentaux. Il faut y ajouter l’obligation de notification sous 24 h (alerte précoce) et 72 h (notification proprement dite), impossible à respecter sérieusement sans système de détection et de rétention des données.