From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- RFC_7999_BLACKHOLE_Community.txt | 126 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 RFC_7999_BLACKHOLE_Community.txt (limited to 'RFC_7999_BLACKHOLE_Community.txt') diff --git a/RFC_7999_BLACKHOLE_Community.txt b/RFC_7999_BLACKHOLE_Community.txt new file mode 100644 index 0000000..33aa240 --- /dev/null +++ b/RFC_7999_BLACKHOLE_Community.txt @@ -0,0 +1,126 @@ +Titre: RFC 7999: BLACKHOLE Community +Auteur: +Date: Thu 20 Oct 2016 02:00:00 +0200 +Lien: https://www.bortzmeyer.org/7999.html + +Lorsqu'on est soumis à une sérieuse attaque par déni de service volumétrique, +il faut parfois sacrifier la machine qui en est la cible, afin de préserver le +reste des ressources réseau. On demande alors à son opérateur de jeter le +trafic à destination de cette machine, avant qu'il n'emprunte la liaison qu'on +veut préserver. Cela peut se faire manuellement mais c'est évidemment plus +rapide et moins risqué si on le fait automatiquement, via une annonce BGP vers +le préfixe visé. Pour cela, on marque l'annonce BGP avec une communauté (RFC +1997) qui veut dire « poubelle donc tout ce trafic ». Ce nouveau RFC normalise +une communauté standard, « bien connue », pour cela, BLACKHOLE (0xFFFF029A). +Ainsi, il n'y aura plus besoin d'utiliser une communauté différente pour chaque +opérateur. + +Cette méthode consistant à envoyer le trafic destiné à la victime vers un +« trou noir » (blackholing) est décrite dans les RFC 3882 et RFC 5635. Comme +elle agit au niveau IP, elle ne nécessite pas d'équipements spéciaux, et elle +est très rapide, ne prenant que peu de ressources chez les routeurs. Par +contre, elle est peu subtile : tout le trafic à destination d'un préfixe donné +(préfixe en général réduit à une seule adresse IP, celle de la machine +attaquée) est jeté, qu'il fasse partie de l'attaque ou pas. Quel est l'intérêt +de couper tout le trafic ? Cela réalise l'objectif de l'attaquant, non ? C'est +en effet une mesure désespérée mais rationnelle : son but est de préserver les +ressources réseau pour que les autres machines fonctionnent. Si vous êtes +connecté à l'Internet par une liaison à 10 Gb/s, et qu'une attaque de 20 Gb/s +frappe votre opérateur, votre ligne va être complètement inutilisable. Aucune +action de votre côté n'y changerait rien, dès que les paquets sont arrivés chez +vous, c'est trop tard. Ce RFC traite le cas où on demande à l'opérateur de +jeter le trafic avant qu'il ne soit envoyé sur la ligne entre l'opérateur et +vous. + +Le problème (section 1 du RFC) est qu'il existait plusieurs méthodes pour +déclencher cet envoi dans un trou noir, ce qui compliquait la tâche des équipes +réseau, une annonce BGP marquée avec une certaine communauté, une annonce BGP +avec un certain next hop, et des méthodes non-BGP (dont le coup de téléphone au +NOC). D'où la solution de notre RFC, définir une communauté standard. Plus +besoin de se poser de question (à part celle de savoir si votre opérateur +accepte cette commande, voir les sections 3.3 et 4). Au passage, les +communautés BGP sont décrites dans le RFC 1997. + +Une communauté BLACKHOLE est donc définie (section 2) et mise dans le registre +IANA[1] des communautés bien connues. Sa valeur est 0xFFFF029A. Le 666 à la fin +vient de la Bible et était déjà couramment employé par les opérateurs. Notez +donc que ce RFC n'invente pas une nouvelle technique (demander à son pair de +jeter certains paquets est une technique très ancienne), il lui donne juste une +communauté standard. + +Voilà, c'est tout, juste une réservation d'un nom et d'une valeur. Si vous êtes +intéressés par les détails pratiques, la section 3 est consacrée aux problèmes +opérationnels. D'abord, un point essentiel : accepter des annonces BGP +étiquetées BLACKHOLE est un choix local. Aucun opérateur n'est obligé de +respecter cette demande et, dans ce cas, ladite communauté est ignorée. +Lorsqu'on se connecte à un nouveau pair BGP, il peut donc être prudent de lire +leur documentation ou de leur poser la question. N'utilisez BLACKHOLE qu'entre +des adultes consentants. (Notez que cet avertissement du RFC est un peu +contradictoire avec l'avantage proclamé de la normalisation de BLACKHOLE : en +pratique, on est toujours obligé de savoir ce que fait son pair, on ne peut pas +compter sur une méthode standard qui marcherait partout.) Une liste des +opérateurs et points d'échange qui acceptent BLACKHOLE est disponible en ligne[2] +. + +Si tout le monde accepte BLACKHOLE, on s'en sert comment ? Lorsqu'une attaque +DoS est en cours, on annonce un préfixe qui couvre l'adresse IP visée, et on y +ajoute cette communauté. On peut aussi utiliser BLACKHOLE pour les annonces du +RFC 5635 (mais pas avec celles du RFC 5575). + +Attention à ne pas propager ces annonces ! En effet, étant en général très +spécifiques (souvent une seule adresse IP), elles seraient préférées, si elles +étaient insérées dans une table de routage. Leur effet est prévu pour être +strictement local et, donc, les annonces doivent être marquées avec la +communauté NO_EXPORT (ou NO_ADVERTISE). + +En parlant de spécificité, quelle doit être la longueur des préfixes annoncés +avec un BLACKHOLE attaché ? Souvent, l'attaque ne vise qu'une seule adresse et, +donc, les annonces BLACKHOLE seront souvent des /32 (en IPv4) et /128 (en +IPv6), afin de ne sacrifier que le strict minimum de son réseau. Si vous avez +une politique BGP de n'accepter que des préfixes plus généraux, c'est un point +à modifier. Aujourd'hui (RFC 7454, section 6.1.3), les préfixes plus +spécifiques que /24 (IPv4) et /48 (IPv6) sont rarement acceptés. Il faut donc +faire des exceptions pour les trous noirs. + +Lorsqu'un opérateur reçoit une de ces annonces « envoie-moi tout ça dans un +trou noir », que doit-il vérifier ? Comme le résultat de cette annonce est de +jeter tout le trafic, une attaque avec une annonce mensongère, ou bien une +erreur d'un opérateur maladroit, pourrait avoir de sérieuses conséquences. +Notre RFC recommande donc un certain nombre de tests de vraisemblance : +vérifier que le pair est autorisé à annoncer un préfixe couvrant celui qu'il +annonce avec BLACKHOLE, et vérifier que BLACKHOLE avec ce pair a été +spécifiquement permis (le RFC recommande plus loin que ce ne soit pas permis +par défaut). Même chose s'il y a des serveurs de route (RFC 7947) sur le +trajet. + +Par contre, il faut, pour le cas spécifique des annonces BLACKHOLE, débrayer +les techniques de validation comme celle du RFC 6811. Par exemple, si un ROA ( +Route Origin Authorisation, RFC 6482) autorise une longueur maximale de préfixe +de /48, l'annonce BLACKHOLE de longueur /128 doit quand même être acceptée. + +À des fins de traçabilité, pour faciliter l'analyse a posteriori d'une attaque, +et du traitement qu'elle a reçu, le RFC recommande de journaliser toutes les +annonces BLACKHOLE. (Cela permettra, par exemple, de repérer les pairs qui +abusent du mécanisme, cf. section 6.) + +Si vous travaillez chez un éditeur de logiciels pour routeurs, n'oubliez pas +les conseils de la section 4, destinés aux programmeurs. D'abord, l'acceptation +des annonces « trou noir » ne devrait pas être faite par défaut. Le RFC demande +qu'une action explicite de l'administrateur réseau soit nécessaire. D'autre +part, pour ne pas avoir à taper la valeur numérique de cette communauté, le RFC +suggère de permettre une valeur texte à indiquer, par exemple blackhole. + +Quelques petits points sur la sécurité pour finir (section 6). D'abord, bien se +rappeler que BGP n'a par défaut aucun mécanisme pour empêcher ou détecter les +modifications des annonces. Si un attaquant actif retire ou ajoute la +communauté BLACKHOLE, ça ne se voit pas. Même le futur BGPSec ne l'empêchera +pas, puisqu'il ne protège pas les communautés. Il y a donc des possibilités +d'attaques par déni de service de ce côté. + +C'est entre autre pour cela que le RFC demande qu'on vérifie qu'un pair qui +annonce un préfixe avec BLACKHOLE est autorisé à le faire (RFC 7454, section +6.2.1.1.2). + +Liens: +[1]: http://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xml#bgp-well-known-communities-1 (lien) +[2]: https://github.com/tking/BLACKHOLE-BGP-Community (lien) -- cgit v1.2.1