Utilisez BGP pour vous défendre contre une attaque DDoS provenant d'un AS distant

J'ai une question concernant BGP et comment réaliser cette configuration.

Mon routeur principal d'entreprise est connecté à un FAI (single homed). Ce routeur a déjà échangé les préfixes IP publics spécifiques au FAI dans les mises à jour BGP. Maintenant, disons qu'il y a un AS à plusieurs sauts qui inonde mon AS local d'une attaque DDoS. Il existe plusieurs réseaux dans cet AS ciblant les serveurs Web de mon AS local.

Comment pouvons-nous arrêter ce trafic sur notre routeur en utilisant BGP?

Appréciez votre réponse !! :)

Vous pouvez faire deux choses avec BGP:

RTBH - Trou noir déclenché à distance

La première option est la plus radicale: Blackhole (stop traffic) pour que l'IP soit attaquée. Inconvénient: l'adresse IP ciblée n'est plus accessible. Avantage: le reste de votre réseau reste actif. Packetlife a une belle explication sur comment cela fonctionne et comment le faire. La deuxième option s'appuie sur la première:

RTBH basé sur la source

RTBH peut également être utilisé (dans certaines configurations) pour bloquer le trafic provenant d'IP spécifiques (dans un vrai DDoS qui n'aiderait pas beaucoup car le trafic proviendrait de milliers d'IP). Encore une fois, Packetlife a une explication.

Dans votre cas, vous pouvez obtenir tous les préfixes pour l'AS à partir d'une base de données de routage comme RADB et les bloquer avec RTBH basé sur la source. Le trafic frapperait quand même votre réseau à la frontière.

Lorsque vous utilisez la RTBH "simple", l'avantage est que vous pouvez envoyer ces routes RTBH à votre FAI en amont (si elles le prennent en charge) qui pourraient alors bloquer le trafic dans leur réseau déjà afin que vous n'ayez pas à le gérer.

La méthode RTBH décrite par @Sebastian via Packetlife est utile, mais cette méthode ne fonctionnera que si votre liaison montante n'est pas saturée par le trafic d'attaque. Si votre liaison montante est saturée, le trou noir doit être implémenté à un moment donné avant que le trafic d'attaque n'atteigne votre réseau.

Vous pouvez accomplir cela avec les communautés de trous noirs en amont.

Hurricane Electric offre une explication / un exemple simple de blackholing déclenché par le client avec une communauté BGP:

1. L'attaque commence
2. Le client identifie l'IP ou la plage IP attaquée
3. Le client statique route la plage ip ou ip vers Null0 et ajoute une annonce du préfixe correspondant avec une carte de route qui la marque avec 6939: 666.

Exemple de configuration Cisco (où XXXX est l'adresse IP attaquée):

conf t
ip route X.X.X.X 255.255.255.255 Null0
router bgp YourAS
network X.X.X.X mask 255.255.255.255 route-map blackhole
route-map blackhole permit 10
set community 6939:666
end

Notez que 6939:666c'est la communauté blackhole spécifique à Hurricane Electric. Vous modifieriez cette valeur pour correspondre à la communauté blackhole de votre fournisseur en amont.

Il existe bien sûr plusieurs façons de configurer cela. Sur mon équipement Brocade, j'utilise la configuration suivante:

router bgp
!
redistribute static route-map blackhole
!
!
route-map blackhole permit  5
 match tag  66
 set community  55555:666

Où 55555:666est la communauté blackhole de votre fournisseur en amont. Un trou noir en amont peut ensuite être appliqué avec une simple commande:

ip route 123.123.123.123 255.255.255.255 null0 tag 66

Du point de vue BGP, vous ne pouvez pas faire grand-chose. Vous pouvez arrêter de faire la publicité de votre préfixe, mais vous terminez simplement l'attaque DoS car personne ne pourra accéder à votre service.

Si vous avez plusieurs préfixes, vous pouvez renuméroter mais l'attaque se déplacera probablement vers le nouveau préfixe également.

Ce que vous devez faire, c'est travailler avec votre amont. Ont-ils un service de nettoyage? S'ils ont un système tel qu'Arbor Peakflow, ils pourraient nettoyer le trafic et le nettoyer avant qu'il n'entre dans votre réseau. Ces services sont souvent très chers.

Il existe également d'autres options telles que Cloudflare et des entreprises similaires où vous configurez BGP via un tunnel GRE vers cette entreprise et votre trafic est géré par leur «cloud» qui peut gérer beaucoup plus de trafic que vos appareils locaux.

Je travaille pour CloudFlare, j'aimerais partager certaines des connaissances que j'ai développées sur l'atténuation des attaques DDOS au cours des derniers mois que je suis ici.

D'abord; beaucoup de gens ont recours à des mesures au niveau du réseau pour atténuer les attaques DDOS de la couche application. Avant de plonger au BGP Blackholing, demandez-vous s'il s'agit d'un problème de limitation de débit ou de protection de la couche d'application. Cela dit; il est désormais très bon marché de lancer des attaques DDOS de très grande capacité (compte tenu du nombre de récurseurs Open DNS et de la manière dont ils peuvent amplifier les attaques).

Comme Elliot l'a décrit dans sa réponse, l'utilisation des communautés BGP pour le trafic de trou noir peut bien fonctionner si votre réseau est petit; ce mécanisme est documenté dans la RFC 3882 . Cependant, comme nous, si vous souhaitez plutôt absorber le trafic d'attaque au lieu du trou noir (c'est-à-dire que vous souhaitez collecter les données d'attaque DDOS ), alors méfiez-vous des dommages collatéraux par lesquels les fournisseurs de réseaux intermédiaires finissent par être encombrés. Vous pouvez atténuer les dommages collatéraux en regardant directement les FAI des réseaux qui lancent les attaques. Ce faisant, vous avez le chemin le plus court de l'attaquant à la destination. De plus, vous pouvez implémenter une conception de réseau Anycast , cela signifie en fait qu'une adresse IP atteint plusieurs centres de données (selon la plus proche).

De toute évidence, il n'est pas possible pour chaque entreprise d'avoir l'infrastructure pour faire Anycast et peering; c'est pourquoi les entreprises se tournent de plus en plus vers les services cloud pour éliminer le mauvais trafic avant qu'il n'atteigne leurs centres de données. Naturellement, CloudFlare est l'un de ces services.

Si toutes les preuves que vous avez collectées sont un flot de paquets avec les adresses IP source d'un AS particulier, vous avez probablement sauté à la mauvaise conclusion. Une explication plus probable serait que ces adresses IP source sont usurpées.

Une attaque par réflexion / amplification implique l'envoi de nombreux paquets usurpant l'adresse IP source d'une victime. Si c'est réellement ce qui se passe, et que vous avez des serveurs dans votre réseau qui peuvent amplifier une attaque, alors le réseau que vous accusez d'une attaque est en fait la victime, et vous aidez l'attaquant.

Dans une telle situation, la solution n'est pas d'appliquer une quelconque ingénierie du trafic, mais plutôt de configurer vos serveurs de sorte qu'ils ne puissent pas être utilisés dans une attaque d'amplification. Comment faire cela n'est pas vraiment une question d'ingénierie réseau.

Il est bien sûr possible que tous les paquets proviennent d'un seul AS. Avec la coopération de l'AS incriminé, vous pourriez obtenir la confirmation que les paquets proviennent en fait de leur AS. Cependant, avec ce niveau de coopération, vous pouvez également bloquer l'attaque à la source.

Si nous supposons que vous avez à travers une méthode que je n'ai pas pensé à obtenir la confirmation que les paquets proviennent vraiment de l'AS que vous pensez, et que vous ne pouvez pas le bloquer à la source et que vous souhaitez le bloquer via BGP, alors je ont lu une méthode quelque peu risquée pour y parvenir. L'idée est que vous ajoutiez un chemin AS à l'itinéraire que vous annoncez. Dans ce chemin AS ajouté, vous incluez le numéro AS de la source de ces paquets.

Lorsque l'annonce atteint les routeurs BGP dans l'AS incriminé, ils vont détecter une boucle et supprimer l'annonce. Pendant ce temps, le reste du monde ne verra pas de boucle et n'acceptera pas l'annonce.

Voilà la théorie. Que cela fonctionne réellement dans la pratique dépend de quelques facteurs différents. Par exemple, cela dépend de l'utilisation effective du numéro AS d'où proviennent les paquets, qui peut être différent du numéro AS annonçant ces adresses IP. (Une telle différence peut être légitime ou due à une usurpation.)

Cela dépend également du fait que votre amont ne filtre pas l'itinéraire s'il trouve le chemin AS suspect. De plus, les réseaux plus éloignés de vous peuvent également abandonner votre itinéraire par exemple s'ils ont également eu de mauvaises expériences avec l'AS incriminé et ont décidé de supprimer tous les itinéraires à partir de là.

C'est à vous de décider si cette approche en vaut le risque.

(J'aurais lié à la source de cette approche, si je pouvais la retrouver.)

Vous pouvez trou noir leur AS à partir de votre réseau local, de sorte que votre routeur BGP crée des routes nulles pour tout préfixe qu'il annonce.

Pro:

• votre AS leur semblera mort, ce qui est leur objectif, tandis que vous échangez toujours des données avec tout le monde normalement.
• votre filtrage d'entrée local supprimera automatiquement les paquets entrants de cet AS

Contra:

• ils peuvent créer des itinéraires de trou noir sur votre routeur, alors assurez-vous d'avoir des règles appropriées en place pour garder vos itinéraires les plus vitaux intacts