Conférence DEFCON 19. Trois générations d'attaques DoS (impliquant le public comme victime). 2e partie

Conférence DEFCON 19. Trois générations d'attaques DoS (impliquant le public comme victime). Partie 1

Mais pire encore ... J'ai essayé de développer un projet pour mes étudiants, et cela s'est avéré drôle, mais le problème était qu'il était impossible de voir les adresses "tuées", car c'était ce dont vous aviez besoin pour voir la configuration IP. Mais si je réalise l'attaque vraiment très rapidement, le système répondra immédiatement et personne ne verra ce qui lui est arrivé.



Je l'ai fait pour que vous puissiez voir l'ensemble du réseau, toutes les adresses de ce réseau page par page. Cette liste pourrait être encore plus longue, car 5 adresses IP par seconde y ont été ajoutées. Quand j'ai commencé ce projet pour la première fois, il me semblait que rien ne se passait, car ma machine Windows ne semblait pas du tout réagir à ce qui s'était passé.

Les étudiants ne seraient pas intéressés, car ils n'apprendront rien s'ils ne peuvent pas voir les dégâts causés par l'attaque. Je me suis dit "ok, c'est un mauvais projet, que dois-je faire?", Mais ensuite il m'est apparu - cette chose tue un contrôleur de domaine, un serveur de messagerie et tout ça, c'est très mauvais. C'est tellement mauvais que je ne peux pas du tout en parler à mes élèves, il vaut mieux que j'en parle à Microsoft tranquillement!

J'ai donc envoyé un tweet indiquant que Windows 7 contient une vulnérabilité dangereuse, ce qui n'est cependant pas du tout surprenant. J'ai dit qu'à cet égard, j'avais besoin de contacts du service de sécurité Windows, et les gens sur Twitter m'ont aidé à trouver les bonnes personnes chez Microsoft. Après 2 jours, j'ai eu une réponse officielle de Microsoft, dans laquelle il a été rapporté que Mark Hughes en avait parlé il y a un an. Mais cela n'a pas d'importance, car ils n'ont pas l'intention d'apporter des corrections aux versions actuelles de Windows, car Vista, Windows 7, Windows Server 2003, Windows Server 2008, Windows XP meurent progressivement et cessent de les prendre en charge. Au lieu de cela, ils corrigeront cette vulnérabilité dans Windows 8 ou Windows 9 s'ils n'arrivent toujours pas à trouver quelque chose.

Je pensais - très bien, si vous allez agir de cette façon, je vais en parler au monde entier et laisser mes élèves tester ce projet comme devoirs, les avertissant de l'utiliser dans un réseau isolé, car sinon vous pouvez tuer tous les ordinateurs du collège , y compris nos serveurs. C'est exactement ce qu'ils ont fait, alors j'enseigne toujours là-bas, plutôt que de rester dans la rue avec une tasse pour l'aumône.

En tout cas, c'est une attaque très puissante, et je voudrais parler un peu de la façon dont vous pouvez vous défendre contre elle. Mais avant de commencer, je remettrai cette affaire à Matthew, et la seule chose que je veux, c'est que vous testiez maintenant l'impact de cette attaque sur vous-même.

Toutes les machines et tous les ordinateurs Windows avec l'une des versions de Free BSD Unix sont sensibles à l'attaque de RA Flood, mais les machines avec MAC OS et Open BSD sont invulnérables. Si vous regardez la configuration de mon MacBook, vous verrez qu'il est également un hôte et a rejoint certains des réseaux existants ici, vous voyez ici le réseau inet6 avec une adresse à partir de 2001.



Il s'est connecté à certains de ces réseaux inutiles, mais pas à tous les réseaux. Je pense que ce pourrait être des réseaux DefCon. Mais en tout cas, vous voyez que mon «MacBook» depuis quelque temps connecté aux 10 premiers réseaux a trouvé et ne fait plus attention à RA. C'est une très bonne défense, et je pense que Microsoft aurait dû venir de Windows également, mais ils ne sont pas intéressés par mon avis. Cisco a publié un correctif conçu pour protéger leur équipement contre des attaques de ce type, et Juniper ne l'a pas encore fait.

Donc, si vous avez des appareils pour les tests, Ryan va mettre en place son réseau isolé et tuer quelqu'un là-bas. Si vous souhaitez y participer, vous pouvez rejoindre le réseau SSID appelé «Ne pas utiliser», qui utilise le cryptage WPA2, vous devez donc saisir le mot de passe «Ne pas utiliser». Si vous rejoignez ce réseau, Ryan verra combien de personnes sont sur le réseau et vous tuera. Cette mise à mort est assez intéressante, car elle aide à déterminer quels autres appareils sont vulnérables, à l'exception de Windows et de Free BSD.

Certaines personnes ont dit qu’elles allaient apporter des appareils intéressants ici, et j’aimerais en savoir plus. Je vous demanderai donc après la démonstration d’aller dans la salle de questions-réponses et d’en parler. Ensuite, nous pourrions informer le fabricant pour l'encourager à publier un correctif pour la vulnérabilité révélée de son appareil. Je pense que beaucoup de gens sont vulnérables aux attaques de ce genre, mais ne le savent pas.

Je vais maintenant donner la parole à Matthew pour qu'il raconte l'histoire de LulzSec, puis je poursuivrai la conversation sur la défense, si nous en avons le temps. Pour l'instant, je vais fermer toutes les fenêtres pour effacer le bureau. Je suis désolé, le nom du réseau est "Ne pas se connecter" et le mot de passe est également "Ne pas se connecter"!

Matthew Prince: Sam est la seule personne que je connaisse qui puisse mener une attaque DDoS avec un tel charme. Je m'appelle Matthew Prince, je connais Sam, nous vivons tous les deux à San Francisco et nous sommes tous les deux impliqués dans l'histoire de LulzSec.



Par conséquent, je vais vous raconter une histoire sur la façon dont ils m'ont entraîné dans ce dossier, sur certaines attaques DDoS que nous avons observées pendant 23 jours et sur ce que nous avons fait pour les arrêter.
Le 2 juin 2011, vers 16 h 54 GMT, LulzSec a annoncé sur son compte Twitter avoir créé la page de sécurité Lulz sur lulzsecurity.com . Ce qui était surprenant, c'est que cette page était hors ligne pendant 15 minutes en raison d'une puissante attaque DDoS. Je ne connais pas les détails de cette attaque en particulier, car nous n'étions pas encore impliqués.

Environ une heure après la publication du message sur la création de la page, LulzSec a tweeté qu'ils étaient en mesure de résoudre le problème de déni de service. La seule chose qui a changé pendant cette période, comme on m'a informé plus tard, c'est qu'ils se sont inscrits à notre service CloudFlare 9 minutes avant ce message. Nous rendons les sites Web plus rapides et les protégeons de certains types d'attaques, mais nous ne nous considérons pas comme un service pour empêcher les attaques DDoS, donc certains d'entre nous ont été surpris par cet acte LulzSec.



Une autre grande surprise a été lorsqu'une heure plus tard, des pirates ont publié un message qui m'était adressé dans lequel ils avouaient leur amour pour CloudFlare et leur demandaient s'ils pouvaient compter sur un compte premium gratuit en échange de rhum.



Je ne savais pas qui étaient ces LulzSec à ce moment-là, alors j'ai écrit un message sur Twitter, que mon avocat a ensuite dit de supprimer: "Cela dépend de la qualité du rhum." Je dois dire tout de suite qu'ils ne nous ont jamais envoyé de rhum, et nous ne leur avons jamais fourni de compte pro. Mais CloudFlare est un service gratuit, chaque jour, nous avons des milliers de sites enregistrés, et généralement nous n'avons aucun problème avec eux.

Ainsi, au cours des 23 prochains jours, ces gars-là ont fait des ravages de diverses manières. Enfin, le 25 juin, ils ont publié un tweet marquant la fin de l'attaque.



Il était intéressant que CloudFlare fonctionne comme un proxy inverse, donc tout le trafic qui est allé à Lulz Security est d'abord passé par notre réseau, ce qui a deux effets significatifs. Le premier - toute personne qui a attaqué Lulz Security nous a attaqués, le second - grâce à nous, Lulz Security a pu cacher l'emplacement de la source de leur attaque, c'est-à-dire l'endroit où se trouvait réellement leur hébergement. Ce sont des effets secondaires de l'architecture de notre système, mais les pirates les ont utilisés à leur avantage.

Sam m'a contacté il y a un moment et a dit qu'il allait parler de DDoS. Nous avons parlé de notre expérience et il m'a demandé si je pouvais partager des informations à ce sujet. Nous avons un conseiller juridique, nous sommes une véritable entreprise avec notre propre politique de confidentialité, et même si vous êtes sur la liste internationale des personnes recherchées pour la cybercriminalité, nous essayons de respecter votre vie privée. Par conséquent, j'ai écrit une lettre à LulzSec et l'ai envoyée à l'adresse e-mail indiquée par eux dans mon compte.



Je leur ai dit que j'avais été invité à DefCon en tant que conférencier, alors j'ai parlé des attaques sur CloudFlare liées aux activités de leur communauté. J'ai écrit que certaines des informations que je souhaite communiquer lors de ma présentation sont protégées par notre politique de confidentialité, je demande donc à LulzSec son consentement à leur divulgation. Après 11 jours, quelqu'un nommé Jack Sparrow m'a répondu avec le texte: "Vous avez mon consentement."



Et me voici, pour parler de certaines choses dont je ne pourrais pas parler sans cette permission. Je peux parler de la façon dont ils nous ont influencés, mais je ne vous dévoilerai pas les hôtes qu'ils ont utilisés pour attaquer ou les vraies adresses IP.

Permettez-moi de vous en dire un peu plus sur ce qui s'est passé au cours de ces 23 jours et de montrer une analyse du trafic réel sur le site Web de Lulz Security pendant cette période.



Pendant cette période, plus de 18 millions de pages ont été vues lorsque les internautes ont visité ce site. Vous pouvez voir que presque depuis le tout début de l'attaque du 22 juin au 5 juillet, un pic de trafic normal a été observé, puis le site a cessé de fonctionner, même s'il utilisait toujours CloudFlare. Si vous essayez de visiter ce site aujourd'hui, vous ne verrez que la page de configuration d'Apache, et je ne sais pas ce qu'ils prévoient de faire ensuite.
Il est intéressant de regarder le trafic de l'attaque qui a fait tomber le site.



Je dirais que tout le trafic vers le sommet du milieu est juste un bruit de fond normal, dans lequel il n'y avait rien de spécial et qui ne présageait rien de ce que je montrerai sur la diapositive dans quelques secondes. En fait, les trois semaines pendant lesquelles LulzSec a utilisé le service CloudFlare ont été assez calmes en ce qui concerne les attaques DoS. C'est étrange car beaucoup de gens ont déclaré avoir attaqué LulzSec à ce moment-là.

Le pic au milieu du graphique a été provoqué par quelques événements très évidents, dont je parlerai plus tard. Nous parlerons également des types d'attaques qui ont été utilisées contre LulzSec et de ce que nous avons fait pour nous protéger.

Un événement particulièrement intéressant s'est produit le 25 juin. Il était associé à Jester. Je ne savais pas qui il était, alors Sam m'a fourni des informations à son sujet.



Il semble que Jester ait passé beaucoup de temps à trouver l'emplacement du site Web de LulzSec et a fièrement publié sur sa page les adresses IP de leurs ressources: www.lulzsecurity.com : 204.197.240.133 et lulzsecurity.com: 111.90.139.55.

Je connais l'hébergeur du site LulzSec le 25 juin et je peux vous dire que ces adresses n'y sont pour rien. Pendant ces 23 jours, ils ont utilisé 7 hôtes différents, initialement l'hôte était situé à Montréal, Canada. Depuis quelque temps, début juin, l'hébergement malaisien était utilisé avec une adresse IP de 111.90.139.55. La plupart des hôtes qu'ils utilisent se trouvaient aux États-Unis, y compris un grand hôte spécialisé dans l'atténuation des effets des attaques DoS, et finalement ils sont passés à l'hébergement allemand, où le site se trouve aujourd'hui.

Fait intéressant, beaucoup de gens ont affirmé que ce sont eux qui ont fait tomber le site Web de LulzSec et publié des photos pertinentes sur Internet. En fait, cela démontre simplement le service que nous proposons dans CloudFlare - si votre serveur principal est déconnecté, nous montrons sa version mise en cache, comme en témoigne la barre orange en haut de la page. Il indique à l'utilisateur qu'il parcourt le cache, tout comme avec le cache de pages sur Google.



Je pense que lorsque les gens ont déclaré avoir fait tomber le site LulzSec, ce qui s'est réellement passé, c'est que les gars de LulzSec ont simplement été expulsés de leurs hôtes. Ainsi, pendant une courte période de 36 heures, ils ont en fait indiqué l'adresse IP invalide 2.2.2.2 comme adresse, car il n'y a pas d'hôte ou de serveur Web actif sous cette adresse. Je pense qu'ils ont juste choisi une adresse IP aléatoire afin que notre système les «pousse» simplement en ligne en permanence, car la version du cache existe pendant une période limitée jusqu'à son expiration. À ce stade, ils sont retournés brièvement à l'hôte et ont indiqué une fausse adresse juste pour apparaître dans notre cache.

Je ne connais pas une seule personne qui indiquerait que le site Web de LulzSec a fonctionné hors ligne pendant au moins une courte période, malgré le fait que beaucoup de gens ont essayé de le mettre hors service en ligne. En fait, en même temps, c'est LulzSec qui a détruit les sites d'autres personnes, par exemple le site Web de la CIA, et il était intéressant d'observer ces attaques. La diapositive répertorie exactement les attaques que nous avons observées.

Nous avons été très surpris et avons littéralement «mis tout le monde sur les oreilles» lors de l'attaque DDoS, qui a tenté de faire tomber le site pendant trois semaines, car nous avons généralement observé des attaques qui ont duré beaucoup moins longtemps. Ce n'est pas aussi dangereux de taquiner les pirates qui broutent sur Twitter que de taquiner la cyber-mafia chinoise ou d'Europe de l'Est ou les gens qui se livrent à l'extorsion d'Internet, car ce sont eux qui sont capables d'une puissante attaque DDoS. Oui, ces gars-là sont également assez intelligents, mais de telles attaques ne sont pas à leur niveau.
Nous avons observé plusieurs attaques relativement inoffensives au niveau OSI 7 en utilisant des outils tels que Slowloris. Mais le serveur Web interne de CloudFlare est spécialement conçu pour non seulement «tuer» les attaques au 7e niveau, mais aussi pour réparer toutes les adresses IP à partir desquelles ces attaques ont été effectuées. Je veux dire, en fait, nous ne sommes heureux que lorsque les pirates attaquent notre 7e niveau, car les attaques DDoS au niveau 3 ou 4 nous causent beaucoup plus de problèmes.

Dans ce cas, nous atténuons leurs conséquences, car nous utilisons le réseau Anycast. Cela signifie que nous avons un tas de machines, des centaines et des centaines d'ordinateurs travaillant dans 14 centres de données différents à travers le monde et liés à la même adresse IP.



Cela vous permet de "pulvériser" une attaque DoS distribuée - ou une attaque avec une grande quantité de trafic vers une grande surface de réseau, ce qui rend très difficile l'utilisation de telles attaques contre nous.
Beaucoup plus de problèmes nous ont apporté des attaques d'un type différent. Le premier a été produit en utilisant quelque chose comme un très grand réseau avec une énorme quantité de trafic que les attaquants nous ont envoyé directement. Ce réseau était situé géographiquement à proximité de notre centre de données à San Jose, et ils utilisaient presque toute sa bande passante. Nous avons dû transférer nos clients vers d'autres centres de données moins occupés, cela ne les a donc pas affectés. Mais le centre de données de San Jose à cette époque n'était en mesure de gérer que Lulz Security, tout en continuant à les garder en ligne.

Une attaque encore plus intéressante, qui menaçait la plupart des personnes connectées avec nous, a utilisé Google comme «réflecteur» du trafic. Nous adhérons à des règles spécifiques concernant les adresses IP de Google pour nous assurer de ne jamais bloquer le trafic légitime qui nous parvient de là. Quelqu'un vraiment intelligent a découvert que si vous envoyez beaucoup de demandes SYN à Google avec de faux en-têtes pointant vers notre adresse IP, Google nous les renverra. La solution à ce problème était assez simple et ne prenait que quelques minutes - nous avons bloqué les ACK auxquels SYN n'était pas attaché, puis avons appelé nos amis sur Google et leur avons dit qu'ils ne recevraient jamais de trafic de ces sources, alors utilisez simplement un pare-feu contre eux . C'était une attaque vraiment intelligente qui a pris en compte la nature de notre infrastructure et a profité des caractéristiques de son travail.

La dernière attaque, qui nous a causé beaucoup de problèmes, était basée sur le fait que quelqu'un a soigneusement analysé les plages de nos adresses IP et y a découvert les interfaces du routeur qui étaient soumises à des influences externes. En utilisant cela, un attaquant a lancé une attaque de type dictionnaire et a désactivé plusieurs de nos routeurs, ayant réussi à contourner Anycast.

La solution au problème s'est à nouveau avérée assez simple - nous avons bloqué ces adresses IP qui sont en dehors de notre réseau, mais l'attaque nous a néanmoins causé des dommages, car pendant plusieurs minutes nos routeurs ont été mis hors ligne.

Vous savez, quand j'ai comparé les plus grosses attaques dont nous avons été témoins, je l'ai même regardé lorsque notre client a reçu un e-mail avec le texte: «Bonjour, nous sommes une agence gouvernementale chinoise qui a découvert que quelqu'un sur le réseau allait vous attaquer "et si vous nous envoyez 10 000 $, nous pourrons probablement résoudre ce problème." Évidemment, ce n'est pas une agence, mais ils sont vraiment capables de résoudre ce problème, car ils le créent eux-mêmes. Cependant, il y a eu relativement peu d'attaques de ce type.

Je vais parler de choses plus intéressantes. La poussée sur fond de trafic de fond normal coïncide avec la déclaration de LulzSec selon laquelle ils ont fait planter des serveurs Minecraft. Une fois l'attaque terminée, le trafic a légèrement diminué.



Les employés de notre bureau, qui sont fans de Minecraft, ont lancé un grand débat pour savoir si LulzSec ne devrait pas quitter notre réseau après cela, car ils ont eux-mêmes causé beaucoup de mal et en général, ce n'est pas du tout cool. Vous pouvez donc apprendre une leçon: si vous prévoyez d’organiser une attaque DDoS contre quelqu'un, il vaut mieux ne pas toucher à Minecraft.

J'ai très peu d'informations sur qui sont vraiment ces gars de Lulz Security, pour nous, ce n'est qu'un des noms d'utilisateurs qui créent des comptes sur Cloudflare. C'est très similaire au nom de la personne qui a été arrêtée, et je ne sais pas si c'est juste une coïncidence ou si ces personnes ont vraiment fait tomber ces sites. Nous n'avons pas remarqué une telle activité derrière eux pour déplacer leurs hôtes, d'ailleurs, leur site est maintenant en panne.



Cependant, il était intéressant pour nous d'observer comment le monde entier a essayé de les «tuer» pendant 23 jours, et quoi qu'il en soit, nous les avons aidés à rester à flot. Merci de m'avoir invité ici!

Sam Bone: Merci, Matthew, d'avoir décidé de venir. Je reviens maintenant à ma présentation. J'ai entendu beaucoup parler de la façon dont l'attaque est plus facile que la défense, donc je vais vous montrer une attaque qui fera tout exploser.Et si vous ne l'aimez pas, alors asseyez-vous et attendez que Microsoft publie son correctif, sinon vous vous retrouverez en vol. C'était le message principal de mon discours. Cependant, je vais aller plus loin et vous dire qu'il existe plusieurs façons de se protéger contre une attaque de la forme de RA Flood.

Vous protéger est vraiment plus difficile, car si vous désactivez IPv6, vous perdrez de nombreuses fonctionnalités utiles, telles que la possibilité de créer des groupes de maison et la possibilité d'accéder directement. Vous pouvez désactiver la découverte de routeur Router Discovery à l'aide de la commande de console appropriée, ce qui signifie que vous définissez une adresse IPv6 statique, ce qui est probablement bon pour le serveur.

RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .



, : , . — , — , .

, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .

, Akamai, , . Load Balancer, , , . , , 4 , .



. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.

CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .

, , ? - ? - ? ? , , . , . , !


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).

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! 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?