Blackholing sécurisé : trois points à vérifier dans votre réseau

Le blackholing (RTBH) est le moyen le plus rapide de couper le trafic d’attaque, mais le simple fait de l’activer ne garantit encore rien. Nous appelons blackholing sécurisé la vérification de quelques points précis du réseau : ce n’est qu’une fois ces points validés que vous avez la certitude que le mécanisme fonctionnera dans son intégralité et que le trafic d’attaque n’atterrira pas là où il cause le plus de dégâts.

Cet article présente d’abord le principe du blackholing, puis les endroits où il échoue le plus souvent, et enfin la manière d’éliminer chacun de ces problèmes, l’un après l’autre.

Le principe du blackholing, point par point

1. Le système de détection identifie une attaque volumétrique visant une adresse précise de votre réseau.
2. La console WanGuard annonce cette adresse sous forme de préfixe (/32 en IPv4) via une session BGP.
3. Le préfixe est marqué avec une BGP community (par exemple 5617:666), grâce à laquelle le fournisseur de lien (uplink) reconnaît qu’il s’agit d’un BGP blackhole (RTBH).
4. Vos fournisseurs de transit, en voyant cette BGP community, rejettent le trafic destiné à cette adresse chez eux, c’est-à-dire avant qu’il ne les atteigne et n’atteigne votre réseau.
5. Votre propre routeur de bordure rejette ce qui est malgré tout arrivé, à condition qu’un RTBH local soit configuré.

Trois points à vérifier

Les trois conditions ci-dessous se vérifient précisément dans cet ordre : chacune n’a de sens que si la précédente est remplie.

Point 1. Le jeu complet de BGP communities à l’annonce

C’est la condition la plus importante et, en même temps, celle que l’on surveille le moins. L’annonce d’un préfixe blackhole doit porter toutes les BGP communities utilisées par vos fournisseurs et par vos partenaires d’échange de trafic (peering). Chaque opérateur dispose de sa propre BGP community pour signaler un blackhole et ne respecte que la sienne : à côté de la valeur standard 65535:666, les valeurs propres à chaque réseau restent d’usage courant.

La conséquence est simple : s’il manque dans l’annonce la BGP community de l’un des fournisseurs, ce fournisseur ne rejettera pas le trafic, et tout le volume de l’attaque entrera sur le lien de son côté, même si les autres fournisseurs ont réagi correctement. Le blackholing paraîtra alors « actif mais inefficace », alors que la cause tient uniquement à la BGP community manquante.

Une fois le jeu complet de BGP communities couvert, le trafic destiné à l’adresse attaquée cesse d’atteindre votre réseau. Il faut toutefois savoir qu’un résidu peut encore arriver par les points d’échange Internet : le blackholing n’y fonctionne pas toujours comme sur les liens de transit, car certains partenaires ne respectent pas du tout les BGP communities blackhole ou appliquent leurs propres règles, différentes. C’est précisément pour cette raison que les points deux et trois sont nécessaires.

Point 2. Le next-hop ne doit pas pointer vers la console WanGuard

Dans le protocole BGP, chaque préfixe porte un attribut next-hop qui indique l’adresse IP suivante par laquelle le réseau concerné est joignable. Le préfixe blackhole arrive sur le routeur depuis la console WanGuard ; son next-hop pointe donc par défaut vers l’adresse de la console.

L’effet se manifeste précisément au pire moment. Si, malgré le blackholing, un trafic accru apparaît sur vos liens, par exemple depuis un point d’échange Internet comme évoqué plus haut, le routeur considère la console comme le dernier élément du chemin vers l’adresse attaquée et dirige ce trafic vers elle. La console WanGuard est une machine de gestion, pas un équipement de transfert de trafic : à volume suffisant, elle perd en performance, cesse de répondre et peut faire tomber la session BGP qui porte toute la protection du réseau. Vous perdez alors la protection, et l’intégralité du trafic de l’attaque DDoS arrive sur les liens.

La solution : dans la politique d’import de la session BGP avec la console, remplacez le next-hop des préfixes reçus par une adresse appartenant au routeur.

Point 3. Blackholing local sur le routeur

Remplacer le next-hop, à lui seul, déplace le problème au lieu de le résoudre : le trafic cesse d’aller vers la console, mais commence à arriver sur le routeur, qui n’a nulle part où l’envoyer. L’adresse désignée comme nouveau next-hop doit donc disposer, sur le routeur, d’une règle de rejet locale : une route qui indique explicitement que le trafic destiné à cette adresse doit être supprimé.

Cet élément est indispensable, que vous travailliez sur un routeur matériel ou logiciel. Une route discard correctement configurée fait disparaître les paquets dans le plan de commutation, et ceux-ci n’atteignent pas le processeur de contrôle. Sans elle, le routeur commence à traiter le trafic de manière logicielle, ce qui, sous une attaque volumétrique, se traduit par une charge processeur croissante, des problèmes de sessions BGP et une perte de stabilité, c’est-à-dire le même résultat que celui que nous voulions éviter sur la console, simplement déplacé ailleurs.

Comme adresse de destination du blackholing local, choisissez n’importe quelle adresse inutilisée de l’espace privé défini par la RFC 1918 : 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16. Les exemples ci-dessous utilisent 10.255.255.1. Une adresse issue de ces plages n’est pas routée sur Internet : il est donc impossible de couper par accident quelque chose de réel, et elle n’entre pas non plus en conflit avec la liste martians par défaut de Junos.

Le résultat des trois points combinés

Avec le jeu complet de BGP communities à l’annonce, un next-hop remplacé à l’import et un blackholing local sur le routeur, vous avez la certitude que le trafic d’attaque :

• est rejeté pour l’essentiel chez les fournisseurs, avant d’arriver sur vos liens,
• n’atteint pas la console WanGuard, si bien que le système de détection continue de fonctionner et suit le déroulement de l’incident,
• ne charge pas le routeur de bordure, mais est simplement rejeté en tant que trafic superflu et dangereux.

Configuration Juniper MX

Voici la configuration complète de la session avec la console WanGuard, qui couvre à la fois le RTBH et BGP FlowSpec :

set protocols bgp group eBGP-Wanguard type internal
set protocols bgp group eBGP-Wanguard description Wanguard
set protocols bgp group eBGP-Wanguard peer-as 65000
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 local-address 10.0.2.5
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 import import-Wanguard
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 export no-export

set policy-options policy-statement NO-VALIDATION then accept
set policy-options policy-statement REJECT-ALL term reject then reject
set policy-options policy-statement import-Wanguard term flowspec_import from rib inetflow.0
set policy-options policy-statement import-Wanguard term flowspec_import then accept
set policy-options policy-statement import-Wanguard term rtbh from protocol bgp
set policy-options policy-statement import-Wanguard term rtbh from community blackhole
set policy-options policy-statement import-Wanguard term rtbh then accept
set policy-options policy-statement import-Wanguard term last-deny-all then reject

set policy-options community blackhole members 5617:666

set routing-options rib inetflow.0 maximum-prefixes 5000
set routing-options flow term-order standard

Le dernier terme compte : la session avec la console WanGuard sert exclusivement à signaler le RTBH et les règles BGP FlowSpec, donc tout ce qui ne correspond pas au motif est rejeté.

S’y ajoutent deux éléments qui mettent en œuvre les points deux et trois, le remplacement du next-hop à l’import et la route discard :

set routing-options static route 10.255.255.1/32 discard

set policy-options policy-statement import-Wanguard term rtbh then next-hop 10.255.255.1

Junos permet aussi de diriger le trafic vers une interface discard plutôt que vers une route statique. Cette solution est plus pratique lorsque vous souhaitez compter ou échantillonner le trafic rejeté, car des filtres peuvent être attachés à l’interface.

Configuration Cisco

ip route 10.255.255.1 255.255.255.255 Null0

ip community-list standard BLACKHOLE permit 5617:666

ip prefix-list HOST-ROUTES permit 0.0.0.0/0 ge 32 le 32

route-map WANGUARD-IN permit 10
 match community BLACKHOLE
 match ip address prefix-list HOST-ROUTES
 set ip next-hop 10.255.255.1
route-map WANGUARD-IN deny 20

router bgp <ASN>
 neighbor <adresse-console> route-map WANGUARD-IN in

L’interface Null0 est une pseudo-interface toujours active, qui ne transfère jamais de trafic ; y diriger des routes est la méthode standard de mise en œuvre du blackholing local sur les plateformes Cisco.

Vérification

Trois tests, à réaliser de préférence à froid, en dehors de toute attaque.

BGP community. Après avoir signalé un blackhole de test, vérifiez auprès de chaque fournisseur que le préfixe a été accepté et qu’il est bien marqué comme blackhole chez lui. C’est le seul moyen de repérer une BGP community manquante avant qu’une attaque ne le fasse.

Next-hop. Sur le routeur, vérifiez la route vers l’adresse testée. Le next-hop doit pointer vers l’adresse de blackholing local et jamais vers l’adresse de la console. C’est le test le plus important de tout le déploiement.

Route discard. Sur Juniper, show route 10.255.255.1 doit afficher une entrée de type Discard ; sur Cisco, show ip route 10.255.255.1 doit pointer vers Null0. Les compteurs de l’interface d’entrée doivent augmenter, ceux de l’interface de sortie non.

Liste de contrôle

• Une liste écrite de tous les fournisseurs et partenaires d’échange de trafic, avec les BGP communities qu’ils exigent.
• La console ajoute le jeu complet de ces BGP communities à l’annonce d’un préfixe blackhole.
• La politique d’import de la session avec la console remplace le next-hop par une adresse locale.
• La politique n’agit que sur les préfixes d’hôte marqués avec la BGP community blackhole ; tout le reste est rejeté.
• L’adresse de blackholing local dispose d’une route discard ou Null0.
• Test effectué : le next-hop pointe vers le blackholing local, et non vers la console.
• Les préfixes blackhole ne fuient pas au-delà du périmètre d’annonce prévu.

Documentation de référence

• Cisco : Remotely Triggered Black Hole Filtering (document technique).
• Cisco : Remotely triggered blackhole filtering (documentation BGP, IOS XR).
• Juniper : discard (routing-options).
• Juniper : Example: Forwarding Packets to the Discard Interface.
• IETF : RFC 7999 (BGP community BLACKHOLE 65535:666) et RFC 5635 (blackholing déclenché à distance).