W. Kumari (Google)D. McPherson (Arbor Networks)August20092009-08-29
Un des ennuis les plus fréquents sur
l'Internet est l'attaque par déni de
service. Répondre à ce genre d'attaques ne peut pas se
faire par une mise à jour logicielle ou par un changement de
configuration ; d'une manière ou d'une autre, il faut éliminer le
trafic anormal qui constitue la DoS. Notre présente une technique permettant de déclencher le
filtrage à distance, et en le faisant en fonction de l'adresse source
des paquets IP de l'attaquant.
Plusieurs techniques ont déjà été développées pour faire face aux
DoS, résumées dans la section 1 du RFC. Filtrer le trafic
sur son propre routeur ou
pare-feu est souvent inefficace : le trafic
anormal a déjà transité sur votre liaison Internet et cela suffit
souvent à la rendre inutilisable. Le mieux est en général de filtrer
chez le FAI. Filtrer par le biais
d'ACL marche bien mais les routeurs sont en général bien plus rapides
à router qu'à filtrer à l'aide d'ACL. Il est donc préférable
d'utiliser le routage en créant des routes « bidon », qui aboutissent
dans le vide (Null0 sur
IOS, par exemple, ou bien route
... discard sur JunOS), et à qui on envoie le trafic indésirable. L'élimination
des paquets sera ainsi faite à la vitesse maximale du routeur.
Autre problème avec le filtrage chez le FAI : le faire à la main, après
échange de coups de téléphone, n'est pas très pratique, et impose des
détails alors que l'attaque est déjà en cours. D'où l'utilité de
pouvoir déclencher le filtrage à distance, selon la technique dite RTBH (Remote Triggered
Black Hole), qui est décrite dans le . Dans
ce RFC, on se sert de BGP pour annoncer le filtrage à un autre
routeur, en
marquant les annonces en question avec une
communauté BGP particulière (une communauté est
une sorte d'étiquette numérique attachée à l'annonce BGP).
C'était l'état de l'art documenté avant la sortie de ce . Le problème de cette méthode du est que les routes, dans le protocole
IP, sont en fonction
de la destination. On va par exemple filtrer tout
le trafic à destination du serveur victime d'une attaque. On empêche
ainsi les dommages collatéraux sur les autres machines mais on rend le
serveur attaqué complètement inaccessible (section 1 du RFC). Lors d'une attaque, on
préférerait parfois filtrer selon la
source.
Le principe est donc de combiner le RTBH (Remote Triggered
Black Hole) classique avec les techniques
RPF du . C'est là l'apport de
notre RFC, détaillé en section 4.
Avant cela, le RFC rappelle, dans sa section 3, le fonctionnement
du RTBH par destination tel que décrit dans le , en
fournissant des détails nouveaux. Le principe du RTBH est que l'annonce BGP indique comme routeur suivant
(next hop) une route vers un trou noir, où tous les
paquets sont détruits. Les détails pratiques sont en section
3.2. Parmi eux, attention aux importants filtres de sortie, qui
empêcheront les annonces BGP de destruction de fuir en dehors du
réseau de l'opérateur.
Le déclenchement du filtrage par le client nécessite que celui-ci
puisse communiquer ses desiderata. Il le fait en général en marquant
ses annonces par une communauté BGP, choisie par l'opérateur. Celui-ci
a même intérêt à prévoir plusieurs communautés, pour un filtrage plus fin.
La section 4 présente la nouvelle technique. Le principe est de
réutiliser le mécanisme uRPF (unicast
Reverse Path Forwarding) du . uRPF vérifie
qu'il existe une route légitime pour l'adresse
source du paquet entrant, afin d'éliminer des
paquets dont l'adresse source est fausse. Si le routeur sait qu'une
route vers un trou noir n'est pas légitime, alors, il peut filtrer en
fonction de la source, si des routes vers ces adresses sources ont été
installées par RTBH. Pour l'instant, aucun routeur ne fournit
apparemment la possibilité de refuser uniquement les adresses pour
lesquelles la route va dans un trou noir, mais elle devrait apparaitre
bientôt.
La section 4.1 fournit les étapes exactes à suivre lorsqu'on met en
œuvre ce filtrage. Lorsqu'on veut bloquer les paquets venant de
192.0.2.66, on doit :
Activer RPF sur les routeurs du FAI,Annoncer, depuis le client, une route vers 192.0.2.66/32,
marquée avec
la communauté BGP de filtrage indiquée par le FAI. (Attention, cela
veut dire que le client va annoncer des réseaux qui ne lui
appartiennent pas : le FAI devra accepter ces annonces mais faire très
attention à ce qu'elles ne se propagent pas au delà de son réseau.)La route sera alors installée dans les routeurs du FAI, pointant
vers un trou noir. Les tests RPF échoueront alors pour les paquets
émis par l'attaquant et les paquets seront rejetés.
Permettre à n'importe quel client de vouer ainsi n'importe quelle
adresse source au trou noir est évidemment dangereux et le RFC
conseille de ne pas activer cette possibilité par défaut (contrairement à ce qu'on peut faire pour le filtrage selon la destination). Le RTBH
reste utile même s'il n'est utilisé que dans le réseau de l'opérateur,
car il évite de configurer manuellement tous les routeurs de ce
dernier. La section 5
détaille les risques de cette technique et les précautions à prendre.
L'annexe A détaille la configuration des routeurs pour cette
famille de techniques, avec des exemples concrets pour
IOS et JunOS.
Un bon article sur RTBH est « Mitigating
DoS/DDoS attacks with Real Time Black Hole (RTBH)
filtering », avec exemples pour Cisco IOS.