1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
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)
|
