DDoS: Pourquoi ne pas bloquer les adresses IP d'origine?
Je suis modérateur d'un babillard majeur. Lorsqu'un méchant se présente, nous bloquons son adresse IP; cela fonctionne, au moins jusqu'à ce qu'ils en trouvent un nouveau. Pourquoi un protocole ne peut-il pas être développé pour les routeurs du monde pour lutter contre les DDoS, que ce soit par les adresses IP ou le contenu des messages ou autre, pour arrêter les DDoS sur ses traces? Il y a clairement une réponse, sinon cela aurait déjà été fait. Quelqu'un peut-il donner un résumé exécutif de pourquoi cela ne peut pas être fait? Par exemple, cela nécessiterait une autorité centrale qui n'existe pas.
Disons que vous dirigez une boutique. Chaque jour, vous pourriez obtenir quelques centaines de clients.
Un jour, vous recevez des dizaines de milliers de personnes qui entrent dans la file d'attente, achètent un bibelot, puis se remettent en ligne pour répéter.
De toute évidence, vous perdez des affaires de clients authentiques qui doivent attendre des heures en ligne.
Maintenant, vous engagez un gardien de sécurité à l'entrée pour vérifier que ces clients satisfont à certains critères.
Cependant, il y a encore des dizaines de milliers de personnes qui veulent entrer. La seule différence est que maintenant, tout le monde doit passer par la sécurité.
Vous remarquez que, du point de vue du client authentique, vous attendez toujours des heures en ligne, juste que maintenant c'est juste pour passer à travers la sécurité!
TL; DR Les IP source multiples sont ce qui les rend si difficiles à défendre.
Pour une réponse plus longue, nous examinons le nom. D Attaque DoS. Ce premier D signifie distribué. En d'autres termes, il n'y a pas une seule IP à bloquer. Ou deux, ou trois, ou même quatre .. Il existe des centaines ou des milliers d'adresses IP uniques.
Habituellement, les attaques DDoS proviennent d'un pirate informatique qui contrôle un botnet ou un réseau de machines zombies. L'attaquant enverra une commande à tous les bots leur demandant de faire des demandes pour une ressource/URI particulière. Le grand nombre de requêtes submerge le serveur et le supprime.
En plus de l'excellente réponse de @ Hollowproc, les "adresses" réelles utilisées comme sources sont souvent usurpées lors d'une attaque comme celle-ci. Un hôte attaquant peut prétendre être n'importe quel nombre d'autres adresses IP, en particulier dans une attaque basée sur UDP telle qu'elle est utilisée contre les fournisseurs DNS.
Il existe une solution pour cela appelée BCP 38 , ou Network Ingress Filtering. Si tout le monde se réunissait, avait un coke et implémentait des contrôles pour bloquer les adresses usurpées là où elles entrent dans le réseau, ces attaques ne pourraient plus usurper le trafic. Les Dyn eux-mêmes mentionnez-le comme une défense utile .
Notez que l'implémentation d'une défense sur de nombreux points sources présente l'avantage d'être évolutive; les exigences des blocs individuels ne sont pas onéreuses en taille. Cependant, ils sont onéreux dans la mesure où plus de personnes doivent faire ce qui est bien pour quelque chose qui ne les affecte pas directement et négativement ... La nature humaine a, pendant plus d'une décennie, empêché cette solution d'atteindre la masse critique.
Il est possible que l'impact croissant des attaques DDoS incite à une plus grande adoption du filtrage des entrées réseau ... Internet traite les dommages comme de la censure et les contourne :)
Le problème avec un DDoS est en deux parties:
1) Étant donné que les bots sont nombreux, ils n'ont pas besoin d'avoir un accélérateur de requête aussi élevé qu'un seul bot, et ne sont donc pas aussi faciles à reconnaître que les bots.
2) Tout ce que vous voyez, ce sont des adresses IP (et User-Agents selon la façon dont vous filtrez le trafic des robots). Toute adresse IP peut être un bot DDoS et toute adresse IP peut être un visiteur légitime. Certaines adresses IP auront à la fois un bot DDoS et un visiteur légitime. Que faire?
Supposons que votre site puisse gérer 1000 requêtes/s et qu'un visiteur ne fasse jamais plus de 10 requêtes/s. Un bot à 100 req/s est facile à bloquer, dix bots à 100 req/s sont faciles à bloquer. Mais 200 bots à 5 req/s sont difficiles à bloquer, car ils se comportent correctement.
200 bots à 100 req/s sont également difficiles à bloquer, car ils ne peuvent même pas faire plus de 5 req/s, ce qui donne l'impression qu'ils se comportent correctement. Cette situation est bien pire que 200 bots à vraiment 5 demandes/s, car un visiteur est maintenant 10 parmi 10010 demandes essayant de se faufiler dans la connexion plutôt que les 10 plus gérables parmi 1010 qui parviennent avec succès au serveur.
1000 bots à 100 req/s rendraient improbable pour tout visiteur réel de se connecter au site. Et une attaque de cette ampleur va également causer des ennuis ailleurs.
Une défense solide pour votre site est une arme puissante pour un attaquant:
Si votre site bloque les adresses IP (ou même des navigateurs spécifiques sur les IP) en cas de mauvais comportement, quelqu'un pourrait décider d'abuser de votre défense pour provoquer une attaque DoS du côté client.
Exemple: Mallory crée une page Web contenant une centaine "d'images" avec margin-left: -1000em; width: 1px; height: 1px; et toutes ces images sont des URL "sensibles" sur votre site. Lorsqu'un visiteur visite la page de Mallory, il envoie 100 requêtes abusives à votre serveur et devient donc bloqué.
Ainsi, obtenir une défense plus agressive contre les attaques (D) DoS entraînera également une autre vulnérabilité.
Une défense "intelligente" telle que CAPTCHA (pour donner aux visiteurs la chance de prouver qu'ils sont aussi des visiteurs et pas seulement des bots malveillants) aura également pour effet secondaire d'exiger réellement des ressources du serveur.
Le téléchargement d'images lorsque la connexion est obstruée ne semble pas être une très bonne idée. Il ne se souvient pas non plus d'un grand nombre de sessions pour les CAPTCHA, des CAPTCHA auxquelles il ne sera pas répondu, en partie parce que les images n'ont pas pu être envoyées, en partie parce que la majorité des visiteurs sont non humains.
Et sur un site dynamique (hautement ou non mis en cache), vous combattriez le feu avec de l'essence.
Supposons que vous hébergiez un service quelconque, dont le but principal est de desservir un emplacement géographique particulier, et supposons que vous l'ayez fait par certaines règles d'accès basées sur des adresses IP.
UDP
Maintenant, si UDP est utilisé dans ce contexte, toute personne connaissant un outil de fabrication de paquets (par exemple scapy) peut usurper l'adresse IP légitime qui est autorisée à accéder, et si vous optez pour l'approche de blocage, vous bloquerez les utilisateurs légitimes du accéder au service.
TCP Similairement usurpé TCP (par exemple syn flood)) Les attaques DDoS peuvent faire souffrir un véritable utilisateur si l'approche de la liste noire active est suivie .
Donc, pour gérer les DDoS, il est préférable d'appliquer un filtrage prudent, en utilisant des appareils suffisamment intelligents pour faire la distinction entre le trafic authentique et le trafic d'attaque par DPI ou d'autres algorithmes.
CDN, NAT, PROCURATION
Si les utilisateurs sont derrière un CDN ou quelque chose comme ça, bloquer un utilisateur peut faire souffrir tout le groupe derrière le proxy.
De plus, "que ce soit par les adresses IP ou le contenu des messages ou autre chose," comme vous l'avez mentionné, pour que les routeurs soient capables de filtrer sur la base du contenu, cela nuirait à ses performances de routage. Mais oui, il y a encore des routeurs pour le faire (par exemple NBAR), et tout ce que l'on peut appliquer dans ses locaux.
Et le blocage devrait être sur une base plus spécifique.
D'autres ont apporté d'excellentes réponses concernant les défis techniques liés à l'atténuation des DDoS, mais ma réponse ici va se concentrer sur ce qui se passe une fois que vous avez créé la capacité de filtrer les DDoS en bloquant un grand nombre d'adresses IP sur votre site.
Le blocage d'un grand nombre d'adresses IP n'est pas toujours souhaitable. En bloquant un grand nombre d'adresses IP en raison d'un DDoS important, vous pourriez bloquer un grand nombre d'utilisateurs légitimes qui pourraient partager cette adresse IP comme un effet secondaire indésirable (par exemple Tor, utilisateurs proxy, universités, foyer partagé, FAI qui utilisent = NAT pour enregistrer les adresses IP publiques).
Ce n'est peut-être pas vraiment un problème pour les petits sites personnels, mais pour un certain nombre de sites où les utilisateurs ont légitimement besoin d'un anonymat sérieux, par exemple les sites s'adressant aux militantes politiques, aux LGBT, aux services féminins dans les pays oppressifs, aux violences domestiques, etc. Le blocage IP simple tombe essentiellement dans le stratagème de l'attaquant pour ces sites. En refusant le service aux utilisateurs anonymes d'accéder à votre service, vous empêchez peut-être vos utilisateurs légitimes les plus vulnérables d'accéder à votre site en toute sécurité, ce qui atteint l'objectif de l'attaquant aussi bien que le DDoS d'origine.
Il n'y a pas de solution simple ou unique aux attaques DDOS, car elles peuvent être exécutées de différentes manières. La nature de la technologie derrière Internet ne se prête à rien d'autre qu'à être grande ouverte. Il existe de nombreux correctifs et solutions pour essayer de renforcer la sécurité et d'atténuer de nombreux problèmes. Dans l'ensemble, il est beaucoup plus difficile de protéger un site ou un réseau contre une attaque que d'attaquer. C'est juste l'état de sécurité aujourd'hui.
Pour une attaque au niveau du réseau (comme DNS plus récemment pour Dyn), le filtrage d'entrée réseau, comme mentionné précédemment, aurait été utile. Cela aide au moins le problème de l'usurpation d'identité.
Un problème plus urgent avec ce type d'attaque, cependant, est l'échelle. Avec le nombre de systèmes infectés dans un botnet pour une attaque importante atteignant des dizaines de milliers, voire des centaines de milliers de systèmes, le blocage basé sur IP n'est pas raisonnable. Avez-vous besoin de bloquer la chaîne du réseau pour survivre si vous bloquez? L'attaque DDOS de Krebs aurait été de l'ordre de 600 Go. Pouvez-vous ou votre fournisseur gérer cela (ou même juste un plus typique dans mon expérience 10-120 Go)? Quoi qu'il en soit, vous ne jouez que whack-a-mole à ce stade, car une fois bloqué, votre attaquant passera probablement à un autre ensemble de machines exploitées. avec différentes IP.
Si vous décidez de jouer au jeu de réputation IP <cough> CloudFlare <cough>, vous pouvez faire des choses stupides comme finir par bloquer les grands fournisseurs, par exemple Pokemon Go la baisse de la plupart/tout le trafic en provenance de Belgique. Encore une fois, ce n'est qu'un coup de poing et pas une solution viable.
Parlons plus haut de la pile. Les attaques de services Web, comme le bourrage ou le raclage d'informations d'identification, ressemblent souvent à du trafic légitime. Les enfants de script de la ligue junior auront une signature de navigateur déformée que vous pourriez rechercher, mais des choses comme Sentry MBA ou même PhantomJS imiteront les navigateurs appropriés qui vaincront cette impression simpliste d'empreinte digitale d'en-tête/ID de navigateur HTTP. De meilleurs attaquants simuleront même une utilisation correcte de la souris et du clavier, obscurcissant davantage leur nature automatisée.
Les captchas sont chers à la fois du point de vue de l'implémentation (soit les ressources sur vos serveurs, soit l'externalisation $$). Les plus simples peuvent être vaincus avec des algorithmes de détection d'image raisonnables. Des captchas plus complexes commencent à énerver les utilisateurs et peuvent entraîner des problèmes d'accessibilité pour les utilisateurs malvoyants. Il existe également des systèmes qui éliminent efficacement les captchas par le biais de la turk mécanique, soit directement (des hordes de personnes ont payé des sous sur le captcha) soit indirectement (le captcha de votre site reçoit une réponse d'un utilisateur sans méfiance sur un autre site).
Quoi qu'il en soit, comme les attaques sont à plusieurs volets, vous avez besoin d'une approche de défense à plusieurs volets. Les grands opérateurs sont même passés à l'offensive, car Microsoft a travaillé avec le FBI pour prendre le relais et fermer les botnets. Malheureusement, l'IoT vient d'ouvrir un tout nouvel ensemble de systèmes prêts à être exploités.
Il n'est pas facile de distinguer un trafic normal d'un trafic DDoS.
DDoS peut être expliqué en termes simples comme -
En tant qu'être humain, je ne peux discuter (discuter avec des gens) que d'une seule personne à la fois et si 10 personnes me parlent en même temps, je ne pourrai répondre à aucune des eux et je serai dans non disponible état pour chacun d'eux.
Les attaquants génèrent généralement l'attaque DDoS à partir de machines compromises (également appelées ** bot). Il se peut qu'au moment où j'écris la réponse à votre question, ma machine puisse impliquer une attaque ddos vers une destination (si ma machine est compromise, bien que les chances de son soient très moindres).
Comme expliqué, il n'y a pas de solution en noir et blanc disponible pour contrôler (ou bloquer) l'attaque ddos.
Comme expliqué par @gowenfawr, si le modèle d'attaque ddos est de udp, la mise en œuvre d'URF au niveau du FAI sur Internet peut aider à bloquer le trafic usurpé et donc à contrôler l'attaque ddos.
Le génie des attaques DDoS provient du fait que le trafic provient d'adresses IP potentiellement légitimes de clients réels.
Disons qu'une personne normale vivant aux États-Unis pourrait voir son routeur compromis et le faire utiliser pour les DDoS. La société victime a complètement bloqué l'adresse IP, maintenant cette personne ne peut plus se connecter au service Web de la société, car la société a bloqué complètement l'adresse IP, empêchant une adresse IP potentiellement valide d'accéder à nouveau à ses serveurs.
C'était un exemple simple, mais imaginez une université disposant de quelques NAT IP pour la navigation Web et une entreprise a bloqué certaines de ces NAT IP pendant une atténuation DDoS. Maintenant des dizaines de milliers de personnes sur ce campus pourraient perdre la connectivité avec les serveurs de cette entreprise, ce qui est catastrophique pour les entreprises.
Sans parler des attaques DDoS suffisamment importantes peuvent employer une quantité folle d'adresses IP différentes.
Histoire vraie ici
Nous vendions autrefois un petit système de caméra. Était d'une grande marque et l'appareil photo n'était pas spectaculaire, mais coûtait tout de même un montant décent. Un jour, quelqu'un nous a appelés au sujet d'un débit sur leur carte de crédit. Il s'est avéré que quelqu'un l'avait obtenu et avait l'habitude d'acheter une de ces caméras et de la faire expédier à quelqu'un qui les agrégeait probablement et les clôturait directement ou les expédiait en vrac aux fraudeurs.
En tant qu'administrateur entreprenant, j'ai fouillé dans les journaux pour comprendre d'où venait la fraude. J'en ai trouvé un d'une IP africaine, mais le reste des commandes suspectes avaient toutes des IP américaines. En fait, ils étaient tous mandatés par des serveurs compromis dans le même centre de données où se trouvaient nos serveurs Web. Au-delà de le signaler à l'hôte, il n'y avait rien à faire. Celui qui faisait cela tirait les cordes via des machines compromises. Il n'y a tout simplement aucun moyen de se prémunir contre ce genre de chose en regardant la source réseau elle-même. Vous ne savez jamais où ni quand quelqu'un sera compromis et son adresse IP transformée en arme.
La récente attaque contre Dyn a montré à quel point c'est simple et stupide maintenant
Le botnet, composé d'appareils tels que des routeurs Wi-Fi domestiques et des caméras vidéo à protocole Internet, envoie un nombre considérable de demandes au service DNS de Dyn. Ces demandes semblent légitimes, il est donc difficile pour les systèmes de Dyn de les éliminer des demandes de recherche de nom de domaine normales.
Et
Ce sont des attaques difficiles à arrêter car elles sont souvent acheminées via des fournisseurs récursifs. Ils ne peuvent pas être mis en cache en raison du préfixe aléatoire. Nous avons commencé à voir des attaques de préfixe aléatoires comme celles-ci il y a trois ans, et elles restent une attaque très courante. Si des appareils IoT sont utilisés, cela expliquerait la taille et l'échelle [et comment l'attaque] affecterait: quelqu'un de la taille de Dyn.
Avec le décollage d'IPv6, vous pourriez bientôt avoir des milliards d'appareils, chacun avec sa propre IP, avec lesquels travailler. La portée est trop grande pour filtrer efficacement.
Un protocole qui permet à "quelqu'un" de dire aux parties d'infrastructure/dorsale Internet d'arrêter d'accepter/de transférer du trafic à partir de certaines adresses signifie simplement que cette "personne" n'aurait même pas besoin d'employer des techniques DDOS pour mettre hors ligne toute personne de son choix. Sans une "autorité centrale qui n'existe pas", il serait difficile de se mettre d'accord sur les personnes à qui on devrait confier ce genre de pouvoir.