Utiliser BGP pour se protéger des DDoS

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é mais à aussi le désavantage de rendre le service visé par l'attaque inaccessible à tous. On donne ici donc raison à l'attaquant même si son attaque est bloquée.

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 vers l'autre lien ? (j'aurais envie de dire oui mais je ne suis pas sûr)

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é mis en œuvre à ce jour uniquement sur Juniper et Alcatel et que donc le fournisseur doit disposer de ces équipements. Il y a ensuite 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.

J'ai lu ensuite s'était 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'ai besoin que tout ça me soit confirmé ou réexpliqué.

Merci pour le courage dont vous avez fait preuve pour lire mon message.

Bonne journée ;-)

Sur ce sujet qui est le coeur du boulot de tous les experts ISPs de la planète, tu ferais bien d'aller voir les vrais spécialistes des réseaux :
http://www.mail-archive.com/frnog@frnog.org/index.html

les DDoS, même les experts réseaux de longue date s'arrachent les cheveux et s'y cassent les dents...

Sur la mail list de frnog, tu pourras poser tes questions à des spécialistes et voir les expériences relatés par certains lors d'attaques ddos

Merci pour l'info ;-)

Je vais y re-poster ma question.

Merci !

Citation:

---

Envoyé par Natsirt

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é mais à aussi le désavantage de rendre le service visé par l'attaque inaccessible à tous. On donne ici donc raison à l'attaquant même si son attaque est bloquée.

---

Ca c'est l'approche un peu naive de RTBH. En general on couple RTBH a uRPF. Ca permet de bloquer le traffic par IP source. Le principe est que sur tes routeurs de bordure tu as une route pointant une addresse de destination (non-routable) vers null0. Sur ton master tu ajoutes une route statique pour l'IP source de l'attaquant pointant vers l'adresse non-routable et tu redistribue dans BGP. L'adresse source de l'attaquant est censee etre connue via null0, donc quand le paquet entre via une interface physique, il est "blackholer" via uRPF.
Le mechanisme s'appelle SRTBH.

En gros, une fois tes attaquant identifies, tu automatises l'ajout de route statiques vers cette IP sur ton master. Tu l'enleves une fois l'attaque terminee.

Le probleme des DDoS n'est pas vraiment la contre mesure mais l'identification du traffic.

Citation:

---

Envoyé par Natsirt

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 vers l'autre lien ? (j'aurais envie de dire oui mais je ne suis pas sûr)

---

Ca depend de comment tu multihome BGP et des metriques que tu annonces.

Citation:

---

Envoyé par Natsirt

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.

---

Oui, tu peux bloquer ce que tu veux via route map et redirection vers null0. Effectivement ca ne passe pas bien a l'echelle.

Citation:

---

Envoyé par Natsirt

Après il existe également FlowSpec qui permettrait de pouvoir distribuer ses PBR à son fournisseur de trafic

---

Non pas vraiment. Flowspec permet de passer des parametres regardant un paquet (src/dst IP/port, flags tcp,... ainsi que des parametres de QoS).

Citation:

---

Envoyé par Natsirt

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é mis en œuvre à ce jour uniquement sur Juniper et Alcatel et que donc le fournisseur doit disposer de ces équipements.

---

IOS-XE (ASR-1K) devrait implementer FlowSpec dans la prochaine release.

Citation:

---

Envoyé par Natsirt

Il y a ensuite 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.

---

Effectivement. C'est complique de faire confiance a des annonces FlowSpec sur eBGP.

Citation:

---

Envoyé par Natsirt

J'ai lu ensuite s'était 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)

---

Oui, c'est exact je pense. Je connais pas trop le cote client, mais plus le cote ISP. Les clients ne peuvent pas controller flowspec, c'est trop dur a securiser pour un ISP.

Salut,

Citation:

---

L'attaque sera-t-elle forcément re-dirigée vers l'autre lien ? (j'aurais envie de dire oui mais je ne suis pas sûr)

---

Sauf cas exceptionnels, non. Parce que l'IP à blackholer /32 fait partie du bloc IP /x (x>32) qui t'a été alloué.
D'un point de vue BGP, le /x est la route IP qui est annoncée par ton peer BGP pour continuer à être joignable dans le réseau d'AS.
Donc toutes les AS neighbors de ton peer BGP continueront à envoyer le traffic en direction de ton AS (règle du longest match dans la table de routage). En d'autres termes, blackholing ou pas, le traffic continuera à traverser physiquement ton interco physique avec ton ISP afin d'être envoyé le plus vite possible vers la Null0...

En revanche, il est déjà arrivé que plusieurs ISP collaborent pour propager le /32 autour d'une AS à risque (attaques massives). Chaque AS annonçant le /32 rajoute un mur supplémentaire pour pouvoir atteindre l'IP blackholée. Une IP blackholée est une IP blacklistée au niveau routage, dans un certain périmètre d'AS.

Par contre, en guise de remarque, blackholing ou pas, les IP attaquées ne sont plus accessibles durant la déviation par host route. Ce qui peut quand même entraîner des pertes colossales pour les victimes (flux bancaires notamment).

Citation:

---

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,

---

Oui. BGP, c'est beaucoup de politique donc la nature humaine fait qu'on ne se truste jamais le long d'une session eBGP. Donc demander du PBR à un peer, c'est forcément trop.
Bon, il y a aussi des cas de figures où les ISP sont appelés à collaborer. Je pense notamment aux attaques massives vers des AS qui hébergent des .gov

Citation:

---

Après il existe également FlowSpec qui permettrait de pouvoir distribuer ses PBR

---

PBR est une information/configuration locale sur une gateway, ça n'a pas d'intérêt à être propagé entre ISPs.

En revanche, FlowSpec c'est plus intéressant. Juniper a effectivement implémenté cette RFC. Aux dernières nouvelles, Cisco le prévoit pour XR 5.2.2 et NX 7.2.

Comme le suggère dahtah, on va pouvoir agir jusqu'au champ DSCP voire jusqu'aux bits flags de l'en-tête TCP. On se rapproche du Deep Inspection Packet de la fonction de firewall. Un BGP Router RFC 5575 se comporterait donc fonctionnellement comme un firewall (les amerlocks appelent ces bestioles des "transproxies BGP").

Citation:

---

Il y a ensuite une implémentation de FlowSpec dans ExaBGP

---

Oui, ExaBGP est un OSS (Operations Support System) qui s'appuie sur FlowSpec. Un chouchou du RIPE :

https://labs.ripe.net/Members/thomas...-to-bgp-engine

Citation:

---

J'ai lu ensuite s'était 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.

---

En théorie, rien ne t'empêche d'envoyer des flow routes dans tes NLRI vers ton peer eBGP s'il est d'accord.
Comme j'ai déjà écrit plus haut, BGP c'est de la politique .

Steph

Tiens, je rebondis sur ce sujet parce que BGP, s'il est mal configuré, peut entrainer les mêmes effets qu'une attaque massive DDOS :aie:
C'est arrivé à Indosat il y a 5 jours :

http://www.renesys.com/2014/04/indonesia-hijacks-world/

Je vous traduis à l'arrache :

Citation:

---

Le 2 Avril dernier, Indosat, un des principaux FAI d'Indonésie, a corrompu la table de routage de l'Internet pendant environ 2 heures. Indosat était soudain devenu "propriétaire" d'une grande partie des préfixes IP de l'Internet puisque c'est lui-même qui les annonçait. Derrière l'erreur humaine, on est en droit de se poser la question de savoir jusqu'à quel point les FAI peuvent se faire confiance mutuellement, et quelle pourrait être l'étendue des dommages causés par de telles erreurs. Ces incidents, même s'ils sont rares, ne sont jamais passés sous silence et peuvent avoir des implications géopolitiques, comme ça avait été le cas lors d'un incident similaire provoqué par la Chine en 2010.

Il faut bien comprendre que c'est la façon dont fonctionne l'Internet: les annonces de routage sont des "déclarations sur l'honneur". Un peu comme Twitter et Facebook qui vous permettent d'être qui vous voulez, le routage sur l'Internet vous permet d'annoncer les réseaux que vous voulez, sans authentification ni validation. Le problème, c'est que contrairement à Twitter et Facebook, les fausses annonces se propagent à travers le monde entier et les décisions de routage, bonnes ou mauvaises, sont faites automatiquement par les routeurs. Ce qui signifie que d'innocentes erreurs peuvent avoir un impact global immédiat. Lots de l'incident d'Indosat, les impacts ont été durement ressentis par Akamaï, un des plus grands fournisseurs de contenus sur Internet. Akamaï possède des milliers de réseaux pour des clients très visibles comme turbotax.com, healthcare.gov et paypal.com entres autres.

Le problème d'Indosat a démarré à 18:25 UTC le 2 Avril 2014 avec la corruption de 320000 routes de l'Internet. La table globale contenant environ 500000 routes, Indosat s'est mis à propager les 2/3 de l'Internet !

Beaucoup de ces routes sont restées confinées à l'Indonésie, et n'ont donc pas impacté le traffic Internet. En revanche, plusieurs centaines ont été propagées dans tout l'Internet, et une large fraction de celles-ci appartenait à Akamaï.

En plus d'avoir perturbé Akamaï, cette corruption de routage a provoqué les mêmes effets que celui d'une attaque DDOS sur l'AS d'Indosat. La latence vers cet opérateur en passant par les FAI qui lui sont directement connectés a été quasiment nulle durant cet incident de 2 heures et quelques temps encore après la correction d'erreur.

Pour certains préfixes d'Akamaï, la corruption était complète et tout le trafic vers ces réseaux était envoyé en Indonésie.

Pour d'autres AS, la corruption était partielle puisqu'une partie du trafic était routée vers Indosat et l'autre partie dans les AS propriétaires des réseaux impactés (comme par exemple la société Chevron basée à Londres).

[...]

En l'absence de gouvernance unique (en terme d'authentification) et de meilleurs moyens de contrôles sur le routage de l'Internet (pour vérification), il n'existe pas à l'heure actuelle de moyen d'empêcher ce type d'incident. De même qu'il est possible à quiconque de s'enregistrer sur Facebook en usurpant votre identité, un routeur connecté à l'Internet peut prétendre être le "propriétaire" ou le meilleur choix de routage pour joindre vos réseaux publics. En dernier ressort, les entreprises doivent s'assurer que la propagation de leurs propres préfixes est correcte puisque des corruptions de table de routage de l'Internet pourraient être de nature malveillante pour dévier le traffic qui leur est destiné.

Les entreprises doivent également être vigilantes avec leurs politiques de routage et comprendre comment le traffic est sensé arriver jusqu'à elles. La raison pour laquelle Chevron a été impacté globalement provient de leur design BGP, puisqu'ils utilisent de façon intensive le rajout d'AS dans leurs annonces BGP avec British Telecom. En d'autres termes, l'AS Path pour annoncer le réseau 146.23.208.0/21 ressemble à quelque chose comme 2856 7862 7862 7862 7862 7862. En utilisant ce mécanisme, Chevron allonge artificiellement le chemin d'AS, mais ce faisant, en baisse la priorité lorsqu'un routeur construit sa table de routage car la sélection de route BGP utilise principalement la longueur de l'AS Path. Lorsqu'Indosat a commencé à corrompre sa table de routage BGP, l'AS Path modifié de Chevron a fait partie des tous premiers préfixes impactés parce que l'AS Path connu dans l'AS d'Indosat était plus court. C'est donc cette entrée que le routeur BGP a inséré dans sa table de routage.

On avait noté le même comportement en Avril 2010 suite à la corruption de la table de routage de l'Internet par la Chine. Des réseaux parmi les plus impactés étaient nativement annoncés depuis Charlottesville en Virginie avec des AS Paths lourdement modifiés.

En résumé, les événements de "fuite de routes" commme celui-ci, qui surviennent une fois par an, rappellent à quel point BGP est vulnérable. Il n'existe aucun remède facile à mettre en oeuvre. Ce qui contraint les entreprises directement connectées à l'Internet de surveiller leurs annonces BGP, particulièrement la structure des AS Paths propagés et d'être préparées pour temporairement annoncer une ou plusieurs routes IP plus spécifiques que le bloc IP qui leur a été alloué.

---

En résumé, Indosat a fait une très très grosse boulette et a entrainé la convergence vers son AS de tout le traffic destiné à plus de 320000 préfixes IP publics :aie:
Là, ça pardonne pas... C'est exactement le principe d'une DDOS pour tuer la bande passante : ça n'est plus un ou plusieurs hosts qui sont HS sur l'Internet, c'est l'AS entière qui est en vrac.

Les entreprises qui annoncent des préfixes IP sur l'Internet par BGP4 utilisent donc des outils pour monitorer l'intégrité de leurs préfixes avec les AS-Paths (BGPMon est le plus connu). Il y a aussi les BGP Looking Glass/Public Route servers dont voici la liste des plus utilisés :

http://www.bgp4.as/looking-glasses
http://routeserver.org/

Par exemple, je voudrais savoir comment est propagé le réseau qui héberge developpez.net, vers, par exemple, Global Crossing aux US :

Code:

---

1 2 3 4 5 6 7 8

steph@steph-ThinkPad-T400:~$ nslookup www.developpez.net Server: 212.27.40.241 Address: 212.27.40.241#53 Non-authoritative answer: www.developpez.net canonical name = developpez.net. Name: developpez.net Address: 37.187.86.89

---

On se connecte sur le route server de Gblx, puis on détermine l'AS-Path (les commandes autorisées peuvent varier d'un route server à l'autre, celles qui suivent fonctionnent dans 99% des cas) :

Code:

---

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

steph@steph-ThinkPad-T400:~$ telnet route-server.gblx.net Trying 2001:450:2001:1000:0:670:1708:1028... Connected to loop0.route-server.phx1.gblx.net. Escape character is '^]'. C ******************************* WARNING ******************************* This equipment is the property of Level 3 Communications. Unauthorized access is strictly prohibited. Any unauthorized access or tampering with this equipment will result in civil and/or criminal prosecution. ******************************* WARNING ******************************* route-server.phx1>sh ip ro 37.187.86.89 Routing entry for 37.187.0.0/16 Known via "bgp 3549", distance 200, metric 50 Tag 6453, type internal Last update from 67.16.148.37 6d10h ago Routing Descriptor Blocks: * 67.16.148.37, from 4.69.241.37, 6d10h ago Route metric is 50, traffic share count is 1 AS Hops 2 Route tag 6453 MPLS label: none route-server.phx1>sh ip bgp | i 37.187.0.0/16 * i37.187.0.0/16 67.16.148.37 50 200 0 6453 16276 i

---

Le Path est donc

Global Crossing <-> AS 6453 (Tata) <-> AS 16276 (OVH France).

Steph

Désolé pour la réponse tardive, mais merci pour toutes ces explications ! J'espère que ce sera utile à d'autres.