6 octobre 2026 · 10 min de lecture

Le RTBH (Remotely Triggered Black Hole) utilise BGP pour envoyer le trafic DDoS vers nulle part sur tout le réseau après environ 1 s. Principe et usage.

En bref : le RTBH (Remotely Triggered Black Hole) est une technique de défense qui s’appuie sur BGP pour ordonner, après environ 1 s, à chaque routeur de bordure de rejeter le trafic à destination de l’adresse attaquée, sur l’ensemble du réseau simultanément. Au lieu des ACL, plus lentes car évaluées paquet par paquet, il utilise la table de transfert du routeur (forwarding table) en routant le préfixe de la victime vers un next-hop de rejet (discard/Null0). Il passe ainsi à l’échelle au débit de ligne (line rate) sur des dizaines de routeurs, presque instantanément. Le prix à payer est cependant élevé : l’adresse attaquée devient injoignable, y compris pour le trafic légitime.

L’essentiel

  • Le RTBH achemine le trafic vers nulle part (null route) au moyen de BGP et d’un next-hop de rejet (Null0) : rapidement, au débit de ligne, sur tout le réseau.
  • Le RTBH basé sur la destination rejette tout le trafic vers l’adresse IP de la victime ; le RTBH basé sur la source rejette le trafic provenant des sources de l’attaquant (via uRPF).
  • Défini dans la RFC 5635 ; la community blackhole bien connue 65535:666 provient de la RFC 7999.
  • Le compromis : le RTBH basé sur la destination parachève l’attaque DoS contre cette adresse IP, car vous sacrifiez l’hôte pour sauver le réseau.
  • Utilisez le RTBH en dernier recours ; privilégiez d’abord BGP FlowSpec lorsque vous pouvez préserver le trafic légitime.

Qu’est-ce que le RTBH ?

Le RTBH (Remotely Triggered Black Hole filtering) est une méthode fondée sur BGP qui permet de rejeter le trafic indésirable dans tout le réseau à partir d’un point de déclenchement unique. Au lieu de configurer des filtres sur chaque routeur pendant l’attaque, l’opérateur annonce une seule route BGP portant le marquage approprié ; chaque routeur qui la reçoit installe une règle de rejet de ce trafic. La technique est normalisée dans la RFC 5635, qui développe la RFC 3882 antérieure (« Configuring BGP to Block Denial-of-Service Attacks »).

Cette technique est née parce que le filtrage par ACL ne passe pas à l’échelle face à un flood massif. La RFC 5635 en situe l’origine dans la réponse aux attaques de février 2000 : en s’appuyant sur la table de transfert plutôt que sur des ACL, il était possible de pousser des routes black-hole sur plus de 60 routeurs en 60 secondes environ, au débit de ligne, assez vite pour peser sur une attaque en cours.

Comment fonctionne le RTBH ?

Le RTBH transforme une mise à jour de routage en rejet du trafic sur tout le réseau. Le routeur de déclenchement annonce le préfixe de la victime en iBGP avec un next-hop pointant vers une interface discard/Null0 (ou marque la route avec une community blackhole que chaque routeur associe à Null0). Une fois la route propagée, chaque routeur de bordure envoie le trafic à destination de ce préfixe directement à la poubelle, sans consulter d’ACL, par une simple décision de transfert (très rapide).

Il existe deux façons courantes de le déclencher :

  • Méthode next-hop : définir le next-hop de la route annoncée sur une adresse discard préconfigurée (routée statiquement vers Null0 sur chaque routeur).
  • Méthode community : marquer la route avec une community BGP blackhole. La RFC 7999 a normalisé la valeur bien connue 65535:666, qui permet à un client ou à un peer de signaler à un fournisseur amont qui la respecte : « envoyez ce /32 (ou /128) dans un trou noir ».

Quelle différence entre le RTBH basé sur la destination et le RTBH basé sur la source ?

Les deux variantes du RTBH se distinguent par ce qu’elles rejettent :

  • Le RTBH basé sur la destination envoie dans un trou noir (black-hole) tout le trafic vers l’adresse attaquée. Simple et pris en charge partout, il rejette aussi le trafic légitime destiné à la victime : il achève le travail de l’attaquant sur cette adresse IP pour protéger tout le reste.
  • Le RTBH basé sur la source rejette le trafic provenant des sources de l’attaquant, en s’appuyant sur le contrôle uRPF (unicast Reverse Path Forwarding) en mode loose : si la source d’un paquet correspond à un préfixe routé vers nulle part (null route), le paquet est rejeté. La RFC 5635 a étendu le RTBH au filtrage par adresse source précisément pour permettre aux opérateurs de rejeter le trafic en fonction de l’attaquant plutôt que de sacrifier la victime, ce qui suppose toutefois de connaître (et de pouvoir énumérer) les sources.

Quand utiliser le RTBH et quand utiliser BGP FlowSpec ?

Le RTBH est un outil grossier ; BGP FlowSpec agit de manière chirurgicale. FlowSpec peut identifier un 5-tuple précis et rejeter ou limiter uniquement les flux malveillants, en maintenant le service attaqué en ligne. Le RTBH rejette tout ce qui est destiné à l’adresse visée. Règle pratique :

  • Utilisez BGP FlowSpec lorsque vous pouvez caractériser l’attaque et souhaitez préserver le trafic légitime vers la cible.
  • Utilisez le RTBH lorsque le flood dépasse la capacité de votre bordure ou de votre scrubber, lorsque la cible est une adresse IP unique que l’on peut sacrifier, ou lorsque l’attaque est trop aléatoire pour tenir dans une règle FlowSpec concise.

La plupart des bordures de réseau matures automatisent les deux : filtrage granulaire avec FlowSpec, et passage au RTBH uniquement lorsque les liens amont (uplink) approchent de la saturation.

Quel compromis faut-il accepter avec le RTBH ?

Le RTBH basé sur la destination parachève l’attaque par déni de service contre l’adresse IP visée. C’est son principe même, et c’est un choix délibéré : perdre un hôte pour maintenir en ligne le réseau et tous les autres clients. Considérez-le comme un frein d’urgence, et non comme un mécanisme de routine. C’est précisément pour cela que la précision de la détection et l’automatisation comptent : vous ne voulez recourir au RTBH que lorsque le filtrage granulaire ne suffit réellement plus, et vous voulez que cette décision soit prise en quelques secondes, pas en quelques minutes.

Comment WanGuard automatise-t-il le RTBH ?

En production, le RTBH ne doit pas être une manipulation manuelle et précipitée en pleine panne. WanGuard anti-DDoS (ce que recouvre exactement ce système) détecte l’attaque, filtre d’abord le trafic par BGP FlowSpec granulaire après 6–10 s sur vos routeurs (ou via la passerelle de filtrage Juniper MX) et ne déclenche le RTBH automatiquement qu’en dernier recours, lorsque l’attaque est trop volumineuse pour être filtrée de manière granulaire ou que les liens amont approchent de la saturation, tout en envoyant en permanence des alertes à votre NOC. Cette automatisation par couches maintient les clients en ligne aussi longtemps que possible et réserve l’outil grossier aux moments où il est réellement nécessaire.

ITORO installe, paramètre et exploite cette solution pour les FAI, les opérateurs télécoms et les data centers ; consultez la grille tarifaire actuelle et le calculateur.

Questions fréquentes

Que signifie le sigle RTBH ?

RTBH signifie Remotely Triggered Black Hole filtering. Il s’agit d’une technique de protection DDoS fondée sur BGP qui permet à un opérateur, depuis un point de déclenchement unique, de rejeter le trafic à destination (ou en provenance) de l’adresse attaquée sur chaque routeur du réseau, en routant ce trafic vers un next-hop de rejet (discard/Null0).

Quelle est la différence entre le RTBH basé sur la destination et le RTBH basé sur la source ?

Le RTBH basé sur la destination rejette tout le trafic vers l’adresse IP de la victime : il est simple, mais rejette aussi le trafic légitime destiné à cet hôte. Le RTBH basé sur la source rejette le trafic provenant des sources de l’attaquant grâce au contrôle uRPF en mode loose : il peut épargner la victime, mais suppose de pouvoir identifier les sources.

Qu’est-ce que la community blackhole dans le RTBH ?

La RFC 7999 définit la community BGP blackhole bien connue 65535:666. Marquer une route /32 (IPv4) ou /128 (IPv6) avec cette community signale à un fournisseur amont qui la respecte qu’il doit router cette adresse vers nulle part (null route), ce qui permet au client de déclencher le RTBH dans le réseau du fournisseur.

Quand utiliser le RTBH plutôt que BGP FlowSpec ?

Utilisez d’abord BGP FlowSpec : il ne rejette que les flux malveillants et maintient le service en ligne. Recourez au RTBH lorsque l’attaque dépasse la capacité de votre bordure ou de votre scrubber, lorsqu’elle vise une adresse IP unique que l’on peut sacrifier, ou lorsqu’elle est trop aléatoire pour tenir dans une règle FlowSpec. Le RTBH est une solution de secours, réservée au dernier recours.

Le RTBH arrête-t-il une attaque DDoS ?

Le RTBH basé sur la destination arrête l’attaque avant qu’elle n’atteigne le reste de votre réseau, mais il rejette aussi tout le trafic légitime vers l’adresse IP attaquée, ce qui revient en pratique à parachever le déni de service contre cette adresse. Il protège le réseau au prix d’un hôte, c’est pourquoi on l’utilise en dernier recours.

Comment arrêter une attaque DDoS ?

La méthode la plus rapide est le RTBH : annoncer via BGP que le trafic à destination de l’adresse attaquée doit être rejeté dès le réseau de l’opérateur. Avantage : il agit après environ 1 s et sauve le reste du réseau. Inconvénient : l’adresse attaquée devient injoignable, y compris pour le trafic légitime. C’est pourquoi le RTBH s’applique de façon ciblée, et non comme protection par défaut.

Faut-il signaler l’incident après avoir utilisé le RTBH ?

Le RTBH règle le problème sur le plan technique, mais ne clôt pas le dossier sur le plan formel. Les entités relevant de la directive NIS2 et de sa transposition en droit français disposent de délais réglementaires pour notifier l’incident à l’ANSSI, et toute victime peut porter plainte.

Sources

  • IETF : RFC 5635, Remote Triggered Black Hole Filtering with Unicast RPF : https://www.rfc-editor.org/rfc/rfc5635
  • IETF : RFC 3882, Configuring BGP to Block Denial-of-Service Attacks : https://datatracker.ietf.org/doc/html/rfc3882
  • IETF : RFC 7999, BLACKHOLE BGP Community : https://www.rfc-editor.org/rfc/rfc7999
  • Cisco : Remotely Triggered Black Hole Filtering (basé sur la destination et sur la source) : https://www.cisco.com/c/dam/en_us/about/security/intelligence/blackhole.pdf