Conférence BLACK HAT. Leçons de survivre à une attaque DDOS de 300 Gb / s. 2e partie

Conférence BLACK HAT. Leçons de survivre à une attaque DDOS de 300 Gb / s. Partie 1

La chose intéressante à propos de cette attaque est que nous n'avons pas osé attaquer directement, mais avons suivi la chaîne de nos fournisseurs. Ils ont commencé à attaquer les fournisseurs en amont situés au-dessus de CloudFlare, et la source de l'attaque était en effet à Londres. Au début, je n'en étais pas sûr, mais comme Spamhaus était également à Londres, le pirate voulait peut-être les mettre dans une position honteuse. Comme je l'ai dit, l'inspirateur technique de l'attaque semblait être un adolescent de Londres, peut-être de cette façon, il pourrait plus efficacement suivre les effets de son attaque. Cette diapositive montre la route du trafic BGP, qui comprenait un maximum de 30 nœuds de transit de saut suivant.



J'ai caché les extensions d'adresse du fournisseur de haut débit de Londres, le dernier saut est l'une des adresses IP de Spamhaus, il y en avait plusieurs dans notre réseau. Vous voyez comment le trafic a été acheminé, il est difficile de déterminer le chemin exact à partir des données ci-dessus, mais il a été dirigé vers notre équipement à Londres, où il a obtenu 17 millisecondes après avoir passé l'adresse IP frontalière de notre réseau, qui fonctionnait à Londres.

Au début, l'attaquant a attaqué cette adresse marquée d'une flèche, et comme le DNS distribué est utilisé ici, il a légèrement frappé Londres, un peu à Amsterdam et à Francfort, aux États-Unis, en Asie et un peu en Australie. Ensuite, le pirate a réalisé que l'attaque était dispersée et non efficace, et a décidé de grimper la chaîne de routage sur des parties supplémentaires de l'infrastructure. Par conséquent, après la dernière adresse IP, il est passé à l'avant-dernière adresse IP. Encore une fois, si vous ne savez pas comment fonctionnent le routage et les connexions Internet, je dirai que le trafic est partiellement échangé directement entre les réseaux lorsque je connecte mon réseau directement à un autre réseau. Dans ce cas particulier, le trafic entre dans notre réseau à partir du réseau Sky, passant par ce que l'on appelle le London Internet Exchange ou LINX.

Les attaquants ont commencé à faire passer des tonnes de trafic via LINX en tant que port. Nous avons un port dans LINX avec des capacités relativement modestes, donc si vous envoyez 300 gig de trafic au port LINX, vous surchargez notre port et les autres ports de cet échange. La solution la plus raisonnable pour nous a donc été de supprimer la connexion via ce port, dès que nous avons vu qu'il était attaqué et que le trafic «circulait» autour de lui de différentes manières.

Le problème était qu'il y avait des dommages collatéraux qui ont affecté les autres ports LINX, de sorte que d'autres fournisseurs de grands réseaux Internet ont également rencontré des problèmes en raison de la baisse du trafic. C'était plutôt désagréable et nous avons ensuite travaillé avec eux pour les aider à protéger leurs réseaux.

L'attaque a provoqué des violations régionales temporaires, mais nous avons eu une bonne occasion de rediriger le trafic vers d'autres nœuds afin de créer la possibilité de rester en ligne pour Spamhaus et tous nos autres clients. Les attaquants ont également affecté nos fournisseurs de transit de niveau supérieur, envoyant tout un tas de trafic aux personnes avec lesquelles nous avions des contrats de services réseau. Leur objectif était de gêner le plus possible nos clients, de sorte que des parties de l'infrastructure réseau qui n'étaient pas directement liées à notre réseau soient affectées.



Il est possible que les attaques aient atteint un niveau supérieur, cependant, je n'ai pas de données qui confirmeraient cela, mais ils ont attaqué les routeurs de base fonctionnant au cœur de divers réseaux. En fait, cette attaque a servi de gigantesque pentest non seulement pour notre réseau, mais aussi pour les réseaux qui nous entouraient, les fournisseurs que nous avons utilisés et les fournisseurs que ces fournisseurs ont utilisés. Il s'est avéré que grâce à cette attaque, nous avons effectué un audit de nos vulnérabilités. Plus tard, nous sommes allés à divers échanges Internet tels que Londres et avons mis en place les meilleures solutions en termes de mise en place de leurs réseaux afin d'augmenter l'efficacité de l'opposition à de telles attaques. Nous avons constaté que tout le trafic interne de l'organisation ne devait pas être acheminé via des routeurs de périphérie réseau. Ainsi, si vous ne souhaitez pas frapper l'un de ces échanges au sein du réseau des échanges Internet, son adresse IP ne doit pas être acheminée via ces échanges. Idéalement, vous devez utiliser 192.168, l'une des adresses RFC 1918 non résolubles qui ne peuvent pas être routées et transmettre le trafic à travers lui-même, c'est-à-dire un réseau qui ne nécessite pas d'accès externe pour fonctionner. C'est la meilleure chose que vous puissiez faire pour contrer une telle attaque.

Il y a d'autres choses que vous pouvez faire, comme le Next Hop Self routing en interne, pour vous assurer que le trafic destiné à la transmission au sein du réseau n'utilisera pas de paquets provenant de l'extérieur. Vous devez non seulement le faire pour votre propre réseau, mais également convaincre les fournisseurs en amont de faire de même.

Il y a une autre chose utile - le filtrage des limites pour une adresse IP spécifique, basé sur une compréhension du fonctionnement de notre application. Par exemple, notre application fonctionne avec différents protocoles, et si nous voyons un paquet UDP qui n'est pas destiné à notre serveur DNS, alors quelque chose s'est mal passé.

Depuis lors, nous avons segmenté nos réseaux de manière à ce que les adresses IP pour les serveurs Web soient différentes des adresses IP pour les serveurs DNS, et nous pouvons demander à nos fournisseurs en amont de simplement bloquer tout le trafic UDP vers cette adresse IP particulière pour assurer la sécurité de notre segment de réseau. Cette séparation des adresses nous a permis d'effectuer un filtrage plus agressif du trafic de haut niveau.

Le filtre BGP Flowspec est notre véritable ami, c'est le protocole que Cisco a proposé. Malgré le fait qu'il contient des bogues, nous utilisons ce protocole et préférons que les fournisseurs de transit l'utilisent également, car il nous permet de transférer nos règles vers des nœuds de réseau distants qui affectent nos itinéraires. Cela vous permet de répondre rapidement à une telle attaque.

L'architecture nLayer à trois niveaux mérite une mention spéciale, et je tiens à exprimer ma profonde gratitude à ses créateurs de GTT, qui ont fait un travail considérable pour rendre leur réseau particulièrement résistant aux attaques. Dès qu'ils ont vu les pics de cette attaque, ils ont rapidement battu le trafic même depuis les frontières de leur réseau. Vous êtes-vous déjà demandé à quel point c'est cool d'être un fournisseur de niveau 1, de couche 3 ou de NTT? Tout leur travail est un week-end solide, car les fournisseurs de premier niveau ne paient personne pour les connexions, ce qui signifie également qu'ils ne peuvent pas transférer le transit à qui que ce soit. Alors que nous commencions à bloquer l'attaque en déconnectant des segments de notre réseau, l'impact s'est concentré sur un petit nombre de fournisseurs de niveau 1 qui étaient au centre de l'attaque, et un «trou noir» s'est formé à l'intérieur de leur réseau, dans lequel tout le trafic s'est précipité, car il n'avait nulle part où aller. . Ce fut donc un test difficile pour de nombreux fournisseurs de premier niveau.

C'est l'une des raisons pour lesquelles vous avez vu le projet Open Resolver créé le premier lundi après l'attaque. Les gars de nLayer sont vraiment une équipe technophile et ils nous ont beaucoup aidés. Ils nous ont traités avec compréhension et ne se sont pas contentés de dire: "Sortez d'ici, vous nous créez trop de problèmes." Nous avons donc développé des étapes pratiques que vous pouvez suivre pour vous assurer que vos réseaux sont sécurisés.



Ce sont quatre recommandations, dont la première semble idiote, mais évidente: assurez-vous d'abord que vous ne faites pas partie du problème! Je pense que beaucoup de gens vous l'ont dit ces dernières années. Arrêtez-vous au moins une seconde et vérifiez que ces deux composants ne fonctionnent pas sur votre réseau.

Le premier est les résolveurs ouverts. S'ils se trouvent dans l'espace d'adresses IP de l'entreprise, si vos clients les utilisent, vous devez les bloquer ou limiter la vitesse du trafic. Il est encore mieux de configurer les résolveurs de manière à ce qu'ils n'acceptent que le trafic provenant directement de votre réseau.



Sur cette diapositive, vous voyez mon article préféré sur The Register, écrit par Trevor Pott. Cela s'appelle «Reconnaître un professionnel de l'informatique: comment j'ai aidé la plus grande attaque DDoS».



Trevor écrit: «Je pensais que je faisais tout correctement. Mais il s'est avéré que j'avais un résolveur ouvert, et j'ai vu à travers les journaux de trafic comment les demandes frappaient Spamhouse. » Je sais qu'il y a des personnes responsables du fonctionnement de très grands réseaux qui ont des résolveurs DNS ouverts. En faisant cela, vous contribuez à la création du problème ci-dessus, je vous demande donc de passer littéralement une seconde de temps et de vous en débarrasser.

Ensuite, assurez-vous que vous utilisez le BCP38. Les gars du réseau iBall ont fait un excellent travail, mais beaucoup de personnes qui fournissent les grands réseaux ici croient que le réseau est fermé s'ils ne permettent pas l'accès externe.



Cependant, supposons que vous ayez un serveur WordPress compromis sur votre réseau qui puisse commencer à usurper des packages source qui ne sont pas destinés à votre réseau, et cela posera un gros problème pour le reste d'Internet.

Le problème, ce sont les résolveurs ouverts, ce sont 28 millions de résolveurs, dont le nombre augmente chaque semaine. Nous ne pouvons vaincre ce problème que par des efforts conjoints. Vous devez définir des indicateurs sur vos routeurs frontaliers qui garantissent qu'ils ne reçoivent que des paquets provenant de sources fiables au sein de votre réseau. Si vous faites cela, refusez aux attaquants la possibilité d'exploiter cette vulnérabilité. La difficulté est de découvrir de grosses machines compromises qui fonctionnent sur des réseaux et qui permettent le spoofing.

Si vous regardez les attaques par force brute sur WordPress, et qu'il y a d'autres attaques là-bas, par exemple, en utilisant le réseau de botnet, il vous sera difficile de deviner que la raison est précisément la possibilité d'utiliser l'usurpation d'identité.

Une autre recommandation est d'utiliser des protocoles vraiment fiables. Vous pouvez dire: "Hé, j'ai obtenu cette adresse IP et démarrer le service en utilisant UDP, et le service utilise TCP et tout autre trafic via ICMP, et je lierai tous ces protocoles à la même IP." Je tiens à vous avertir que si un problème survient, cela limite votre capacité à répondre de manière flexible à ce type d'attaque, d'autant plus que vous pouvez facilement segmenter le réseau afin que chaque protocole fonctionne sur sa propre adresse IP. Mieux si vous pouvez filtrer le trafic en amont. Le but de l'une de ces attaques n'est pas d'arrêter le trafic au sein de votre réseau, mais de le bloquer aussi près que possible de la source de trafic.Par conséquent, en donnant à quelqu'un la possibilité de bloquer tout le trafic UDP dirigé vers chaque IP, à l'exception de l'adresse sélectionnée, vous réduirez considérablement la surface d'attaque. qui peut être utilisé par un attaquant.

Ainsi, des protocoles distincts pour les adresses IP individuelles fonctionnent efficacement lors de l'interaction avec les fournisseurs en amont. Vous leur posez simplement la question: "Hé, pouvez-vous implémenter ces types de filtrage?". Soit dit en passant, l'une des raisons pour lesquelles nous, en tant que fournisseurs, soutenons Flowspec est que nous pouvons à juste titre leur demander: «Les gars, soutenez-vous Flowspec?», Et s'ils répondent «Oui», la conversation est terminée, et nous pouvons déployer nos propres filtres en bordure du réseau aussi rapidement que nous le souhaitons.

La troisième recommandation est la mise en œuvre de l'infrastructure ACL, c'est-à-dire l'utilisation de listes de contrôle d'accès. Je veux dire, un paquet ne peut pas être destiné à votre réseau interne si sa source n'appartient pas à ce réseau interne. Si un paquet provient de votre réseau ou entre dans votre réseau à partir d'un routeur périphérique, il ne doit pas «voyager» à travers l'infrastructure de votre réseau interne. Il existe de nombreuses façons de mettre en œuvre cette disposition. Vous pouvez appliquer un filtrage pour empêcher certaines adresses IP d'atteindre les limites du réseau, vous pouvez utiliser Next Hop Self routing pour empêcher l'accès à certaines adresses internes, vous pouvez utiliser les protocoles RFC 1918 à l'intérieur du réseau pour vous assurer que vos adresses IP internes ne sont pas utilisé pour l'adressage du monde extérieur.



Cela peut vraiment apporter un mal de tête supplémentaire, car il vous oblige à vérifier les paramètres du routeur, à vraiment utiliser le réseau VPN, au lieu de faire semblant de l'utiliser, etc. Ce ne sont pas les solutions les plus populaires, mais si elles ne sont pas implémentées, l'attaquant peut regarder dans votre réseau et viser ses segments individuels afin de faire encore plus de mal.

La quatrième recommandation est que vous devez bien connaître votre trafic en amont. Je tiens à souligner une fois de plus que cette attaque n'a pas utilisé d'applications complexes ou de syn-packages, c'était juste un homme des cavernes avec un club lourd. D'une certaine manière, vous devriez avoir plus de transports en commun que le méchant. Il peut générer 300 Gbps de trafic, et je suis sûr que peu de ceux qui sont présents peuvent se vanter de réseaux avec un tel volume de trafic. Cela signifie que vous devez avoir un ami qui a beaucoup de trafic sortant et, l'attirant à la coopération, vous couvrir le dos d'une telle attaque. Nous sommes très sélectifs sur le trafic sortant avec lequel nous travaillons afin de pouvoir constater à temps une attaque de ce type.

L'autre jour, j'ai parlé avec le directeur technique d'un grand fournisseur de services de transport en commun et je lui ai demandé s'il allait me vendre du transport en commun, ce à quoi il a répondu - non, les gars, de cela, vous n'obtiendrez qu'un mal de tête supplémentaire en tant que clients.

Cependant, nous recherchons un tel trafic et payons même aux fournisseurs les primes de transit que nous utilisons, car lorsque des attaques de ce type se produisent, nous voulons pouvoir les appeler et demander de l'aide pour atténuer les conséquences de l'attaque. Vous n'avez pas besoin de créer des réseaux avec un débit de 3-4-5 térabits, si vous pouvez répartir le trafic de pointe entre les réseaux partenaires.

Il ne s'agit pas nécessairement d'entreprises dotées d'une puissante protection DDoS, il leur suffit d'utiliser l'architecture nLayer pour vraiment faire leur travail et vous aider en cas de problème. Travaillez en étroite collaboration avec eux pour étendre les limites de votre réseau. Utilisez une stratégie de configuration réseau qui vous permet de rejoindre la frontière de leurs réseaux, et les fournisseurs sont prêts à le faire si vous avez des fournisseurs de réseau compétents. C'est toute l'histoire de l'attaque de 300 gigabits, il nous reste environ 10 minutes pour répondre à vos questions.



Je vous demande d'utiliser un microphone si vous acceptez de faire la queue pour poser une question. Une autre innovation dont j'ai oublié de parler: les organisateurs de Blackhat veulent avoir des commentaires avec le haut-parleur, et si vous "allumez" votre badge de l'extérieur, ils transfèreront vos informations à la NSA et recevront également des commentaires. J'ai plaisanté sur la première partie, mais la seconde relative est vraie - vous pouvez utiliser les commentaires, vous pouvez donc me traiter d'idiot et généralement poser des questions.

Question: Quels protocoles d'amplification, en plus de UDP et 53, avez-vous rencontrés lors de l'exécution de CloudFlare?

Réponse: demandez-vous, y avait-il d'autres protocoles d'amplification que ceux mentionnés? Nous observons toujours l'utilisation d'ICMP pour effectuer la bonne vieille attaque de Schtroumpf, mais rien n'est comparable à l'ampleur de l'attaque dont je vous ai parlé. L'année prochaine, nous insisterons donc catégoriquement pour que les gens n'utilisent pas de résolveurs ouverts, mais utilisent un serveur DNS autorisé et légitime. Utilisez CloudFlare, Bind ou UltraDNS pour démarrer vos réseaux, et si vous pouvez répertorier tous les domaines dont le serveur autorisé est responsable, trouver des domaines qui ont de très grandes listes de noms, vous pouvez protéger votre réseau, car un tel serveur peut limiter si nécessaire vitesse du trafic. Nous avons consacré beaucoup de temps à la mise en œuvre de cette solution, et je serai heureux de le dire à ceux qui sont vraiment intéressés.

Question: Le botnet n'a pas été utilisé dans cette attaque, mais pouvez-vous recommander des ressources qui permettront de détecter si les grands réseaux que vous contrôlez utilisent le botnet pour mener une attaque DDoS?

Réponse: cela dépend de l'endroit où vous vous trouvez - par exemple, vous pouvez rechercher de tels outils dans des organisations qui surveillent le comportement du botnet et en trouver un qui convient à vos besoins. Si vous avez besoin d'un projet open source, je recommande Honeypot, qui est apparu il y a quelques années. Avec lui, nous surveillons efficacement une partie importante des réseaux mondiaux de botnet, vous pouvez spécifier la plage de vos adresses IP et il montrera s'il y a des réseaux malveillants là-bas. Ce n'est là qu'un des nombreux projets de ce type. Vous pouvez simplement rechercher des modèles de trafic anormal qui se trouvent sur votre réseau, donc si vous voyez un gigabit de trafic qui est acheminé vers une seule adresse IP, et il n'y a aucune raison raisonnable pour laquelle cela se produit à un moment donné, alors ce trafic arrive probablement non pas à partir d'un serveur Web, mais à partir d'un réseau de botnet. Cela devrait vous rendre suspect.

Question: Google possède l'un des résolveurs DNS ouverts les plus populaires, ne pensez-vous pas que cela peut causer des problèmes?

Réponse: ils ont fait beaucoup de travail pour limiter le trafic, et la meilleure façon de le vérifier est d'utiliser la même demande digANY que je vous ai donnée en exemple, et de remplacer l'adresse IP du réseau PCCW par l'adresse 888. N'importe laquelle des personnes présentes ne peut envoyer cette demande qu'une seule fois, répétez cela ne fonctionnera pas. . , – UDP, , , , .

: , BGP Flowspec, , , , , , BGP Flowspec?

: , BGP Flowspec, - Cisco, . , , , . , Flowspec , . , Juniper, Flowspec. , 12 Cisco .

: Flowspec CloudFlare?

: , . , , Flowspec. , . , Flowspec, , . , , upstream-.



: CloudFlare, . , - , . , : «, »?

: , , . , , , , . , DDoS- , , 300 / . , Akamai, . , , «», , . , , .
, , , , . , , , . , , Akamai, Amazon, CloudFlare, Google, , , . , , ?

: , BC38, , DNSSec…

: , DNSSec!

: , , DNSSec, , ?

: . , DNSSec , . ? . , , – DNSSec , . , DNSSec, , , DNS-, .

DNSSec, , , , DNSSec. , Cloudflare, DNS, , . DNS- .

: upstream- ? .



: , , , upstream-. , . CloudFlare , , .

, , , - . , DNS DDoS: , , , .

Question: Pourrait-il arriver que vous transférez vos dépenses pour payer un trafic excessif en raison d'une attaque DDoS à vos clients, motivant cette décision par le fait qu'ils exigent trop d'argent de votre part?

Réponse: vous sous-estimez combien d'argent nous avons à la banque!

Merci à tous, je serai heureux de vous parler dans un autre endroit, et maintenant il est temps de céder cette plate-forme au prochain orateur.


Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'au printemps gratuitement lors du paiement pendant six mois, vous pouvez commander ici .

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?