Bonjour, Je prépare actuellement un dossier sur les DDoS et je cherche à déterminer les différents moyens de s'en prémunir au niveau routage BGP.
Au fil de mes recherches, j'ai pu constater qu'il existait différentes techniques : La première consistant lors d'une attaque sur une IP précise à annoncer un préfix /32 à son fournisseur de trafic via une communauté BGP pour "blackholer" le trafic vers cette IP. Cette méthode semble fonctionner et a l'avantage de bloquer le trafic avant qu'il ne soit facturé. Elle a aussi le désavantage de rendre le service visé par l'attaque inaccessible à tous. On donne donc ici raison à l'attaquant même si son attaque est bloquée. D'après ce que j'ai compris, ce mécanisme a tout de même été amélioré par la suite avec la RFC5635, introduisant la possibilité de filtrer l'adresse source. Je me pose en revanche une question; si l'on dispose de deux voisins BGP (deux fournisseurs de trafic) et que lors d'une attaque DDoS on identifie le lien par lequel l'attaque arrive, on annonce alors à ce voisin BGP en particulier notre IP à "blackholer". L'attaque sera-t-elle forcément re-dirigée dans les mêmes proportions vers l'autre lien ? (j'aurais envie de dire oui) Ensuite il existe apparemment une deuxième méthode consistant à utiliser les PBR (Policy base routing) pour bloquer du trafic en s'appuyant sur les autres informations contenues dans le header d'un paquet IP (et non uniquement l'adresse de destination). En revanche il semblerait que ce ne soit pas vraiment réalisable dans la mesure où cela doit être réalisé du côté fournisseur et qu'il faut donc le contacter, le convaincre de mettre en place le PBR sur tous les routeurs de son backbone, puis de les retirer. Pour moi cette solution n'est donc pas viable. Après il existe également FlowSpec qui permettrait de pouvoir distribuer ses PBR à son fournisseur de trafic, sans nécessiter un nouveau canal de distribution car s'appuyant sur BGP (grâce à MP-BGP et les NLRI MP-REACH-NLRI/MP-UNREACH-NLRI/NLRI FlowSpec). En plus côté fournisseur cela à l'avantage de se répliquer automatiquement par annonce en iBGP. Cette techniques est détaillée par le RFC5575 introduisant donc de nouveaux NLRI avec de nouveaux composants ( Prefixe source (unique), Prefix de Destination (unique), Protocole (multiple), Port (multiple), Port de Destination (multiple), Port Source (multiple), Type ICMP, code ICMP, TCP Flags, Longueur de paquet, ...). Les actions à effectuer sont quant à elles définies dans des communautés étendues. Il faut bien entendu que les deux parties supporte ce mécanisme, d'ailleurs à ce propos, je crois que ce RFC a été appliqué à ce jour uniquement par Juniper et Alcatel et que donc le fournisseur doit disposer de ces équipements. Il y a une implémentation de FlowSpec dans ExaBGP, un logiciel libre, qui permet de faire de l'injection de route. Par contre j'ai cru comprendre que c'était peu pratique car tout d'abord il était difficile de déterminer une politique en fonction de la situation et que ensuite concrètement les fournisseurs de trafic n'autorisent pas cette méthode sur les sessions eBGP. Cette méthode serait probablement mis en place uniquement au sein des backbones des fournisseurs de trafic. Concrètement seul un peer, meshé avec les routeurs coeur, est autorisé à annoncer des inetflow. Ici j'ai pas vraiment compris comment on pouvait profiter de cela puisqu'on n'a pas la main en tant que client. Donc pour moi on en revient un peu à la deuxième solution; nous sommes obligés de contacter les fournisseurs de trafic pour leur spécifier les politiques à mettre en place (ex bloquer les flux UDP et ne laisser passer que les flux TCP lors d'une attaque DDoS basée sur UDP) Si je me trompe n'hésitez pas à m'expliquer. En faite j'aimerais que tout ça me soit confirmé. Merci pour le temps passé à lire mon message. Bonne journée ;-) Tristan --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
