Disons que vous dirigez une boutique. Chaque jour, vous pourriez avoir quelques centaines de clients.

Un jour, des dizaines de milliers de personnes entrent, qui arrivent à la caisse, achètent un bijou, puis rentrent tout de suite ligne à répéter.

De toute évidence, vous perdez des affaires de clients authentiques qui doivent faire la queue pendant des heures.

Maintenant, vous engagez un agent de sécurité à l'entrée pour vérifier que ces clients satisfont quelques 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 encore des heures en ligne, juste que maintenant c'est juste pour passer la sécurité!

TL; DR Les adresses IP sources multiples sont ce qui les rend si difficiles à défendre.

Pour une réponse plus longue, nous regardons le nom. D attaque DoS. Ce premier D signifie distribué. En d'autres termes, il n'y a pas une seule adresse IP à bloquer. Ou deux, trois ou même quatre .. Il existe des centaines ou des milliers d'adresses IP uniques.

Généralement, les attaques DDoS proviennent d'un pirate informatique contrôlant un botnet ou un réseau de machines zombies. L'attaquant enverra une commande à tous les bots leur demandant de faire des requêtes 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 que celle utilisée contre les fournisseurs DNS.

Il existe une solution pour cela appelée BCP 38 , ou filtrage d'entrée réseau. Si tout le monde se réunissait, avait un coca et implémentait des contrôles pour bloquer les adresses falsifiées là où elles entrent sur le réseau, ces attaques ne pourraient plus usurper le trafic. Les gens de Dyn eux-mêmes le mentionnent comme une défense utile.

Notez que l'implémentation d'une défense à de nombreux points sources a l'avantage d'être évolutive; les exigences de chaque bloc ne sont pas onéreuses en taille. Cependant, ils sont onéreux dans la mesure où plus de gens doivent faire ce qui est juste 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 une masse critique.

Il est possible que l'impact croissant des attaques DDoS incite à une plus grande adoption du filtrage d'entrée 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 si nombreux, ils n'ont pas besoin d'avoir une régulation de requête aussi élevée qu'un seul bot, et ne sont donc pas aussi faciles à reconnaître comme des robots.

2) Tout ce que vous voyez, ce sont les adresses IP (et les User-Agent en fonction de 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 faites-vous?

Disons que votre site peut gérer 1000 req / s et qu'un visiteur ne fait jamais plus de 10 req / 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 req / s, car un visiteur a maintenant 10 demandes sur 10010 essayant de se faufiler dans la connexion plutôt que les 10 plus gérables parmi 1010 qui parviennent au serveur.

1000 bots à 100 req / s rendrait improbable pour chaque visiteur réel de se connecter au site. Et une attaque de cette ampleur va également causer des problèmes ailleurs.

Une défense solide pour votre site est une arme puissante pour un attaquant:

Si votre site bloque des adresses IP (ou même des navigateurs spécifiques sur les IP) s'ils se comportent mal, quelqu'un pourrait décider abuser de votre défense pour provoquer une attaque DoS côté client.

Exemple: Mallory crée une page Web contenant une centaine "d'images" avec margin-left: -1000em; largeur: 1px; height: 1px; et toutes ces images sont des URL "sensibles" sur votre site. Lorsqu'un visiteur visite la page de Mallory, il enverra 100 demandes abusives à votre serveur et sera donc bloqué.

Donc, obtenir une défense plus agressive contre les attaques (D) DoS entraînera également une autre vulnérabilité.

Une défense "intelligente" comme les CAPTCHA (pour donner aux visiteurs une chance de prouver qu'ils sont également des visiteurs et pas seulement des bots malveillants) aura également pour effet secondaire d'exiger des ressources du serveur.

Télécharger des images lorsque la connexion est bloquée ne semble pas être une très bonne idée. Je ne me souviens pas non plus d'un grand nombre de sessions pour les CAPTCHA, les CAPTCHA qui ne recevront pas de réponse, en partie parce que les images n'ont pas pu être envoyées, en partie parce que la majorité des visiteurs ne sont pas humains.

Et sur un site dynamique (hautement ou non mis en cache), vous combattrez 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 ayez fait cela avec des règles d'accès basées sur les adresses IP.

UDP

Maintenant, si UDP est pris dans ce contexte, toute personne ayant une connaissance d'un outil de création de paquets (par exemple scapy) peut usurper l'adresse IP légitime à laquelle l'accès est autorisé, et si vous optez pour le blocage approche, vous empêcherez les utilisateurs légitimes d'accéder au service.

TCP De même, des attaques DDoS TCP (par exemple, syn flood) peuvent faire souffrir un utilisateur authentique si la liste noire active approche.

Donc, pour faire face aux DDoS, il est préférable d'appliquer un filtrage minutieux, 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, PROXY

Si les utilisateurs sont derrière un CDN ou quelque chose du genre, le blocage d'un utilisateur peut faire souffrir tout le groupe derrière le proxy.

De plus, " que ce soit par adresse IP ou contenu de message 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 faire ça (par exemple NBAR), et tout ce que l'on peut appliquer à l'intérieur de ses locaux.

Et le blocage devrait être sur une base plus spécifique.

Il n'est pas facile de faire la distinction entre un trafic normal et un trafic DDoS.

DDoS peut être expliqué en termes simples comme -
En tant qu'être humain, je ne peux discuter (avoir un bavardage) de choses qu'avec une seule personne à la fois et si des dizaines de personnes parlent à moi en même temps, je ne pourrai répondre à aucune d’entre elles et je serai dans l’état indisponible pour tous.

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 de la rédaction de la réponse à votre question, ma machine puisse impliquer une attaque ddos ​​vers une destination (si ma machine est compromise, bien que sa probabilité soit très moindre).

Comme expliqué, il n'y a pas de solution noir et blanc disponible pour contrôler (ou bloquer) l'attaque ddos.

Comme expliqué par @gowenfawr, si le modèle d'attaque ddos ​​est udp, la mise en œuvre d'URF au niveau du FAI sur Internet peut aider à bloquer le trafic usurpé et donc aider à contrôler l'attaque ddos.

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 construit 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 important DDoS, vous pourriez bloquer un grand nombre d'utilisateurs légitimes qui pourraient partager ces adresses IP comme un effet secondaire indésirable (par exemple Tor, utilisateurs proxy, universités, foyer partagé, FAI utilisant NAT pour enregistrer les adresses IP publiques).

Ce n'est peut-être pas tant 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, disent les sites s'adressant aux militants politiques, aux LGBT, aux services féminins oppressifs pays, abus domestique, etc. Le simple blocage IP tombe essentiellement dans le stratagème de l'attaquant pour ces sites. En refusant l'accès à votre service aux utilisateurs anonymes du service, vous pouvez empêcher vos utilisateurs légitimes les plus vulnérables d'accéder en toute sécurité à votre site, ce qui permet d'atteindre l'objectif de l'attaquant tout aussi bien que le DDoS d'origine.

Il n'existe pas de solution simple ou unique aux attaques DDOS, car elles peuvent être exécutées de nombreuses manières différentes. La nature de la technologie derrière Internet ne se prête à rien d'autre qu'à être largement ouverte. Il existe de nombreux correctifs et solutions pour tenter 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 la sécurité aujourd'hui.

Pour les attaques au niveau du réseau (comme encore une fois DNS pour Dyn), le filtrage d'entrée du réseau comme mentionné précédemment, aurait été utile. Cela aide au moins à résoudre le problème de l'usurpation d'identité.

Un problème plus pressant avec ce type d'attaque, cependant, est l'échelle. Avec le nombre de systèmes infectés dans un botnet pour une attaque de taille 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 loin dans la chaîne du réseau pour survivre si vous bloquez? L'attaque Krebs DDOS aurait été de l'ordre de 600 Gbs. Pouvez-vous ou votre fournisseur gérer cela (ou même juste un plus typique dans mon expérience 10-120Gbs) Quoi qu'il en soit, vous jouez simplement à 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 réduit la plupart / tout le trafic en provenance de Belgique. Encore une fois, c'est juste un coup de taupe et non une solution viable.

Parlons plus haut dans la pile. Les attaques de services Web, comme le bourrage d'informations d'identification ou le grattage, ressembleront souvent à du trafic légitime. Les enfants de script de la ligue junior auront une signature de navigateur désordonnée que vous pourriez rechercher, mais des choses comme Sentry MBA ou même PhantomJS imiteront les navigateurs appropriés qui vaincront cette impression de doigt simpliste d'en-tête HTTP / ID de navigateur. Les 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 la mise en œuvre (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 causer des problèmes d'accessibilité aux utilisateurs malvoyants. Il existe également des systèmes qui éliminent efficacement les captchas via turk mécanique, soit directement (des hordes de personnes ont payé des centimes sur le captcha) ou indirectement (captcha de votre site auquel répond un utilisateur sans méfiance sur un autre site).

Quoi qu'il en soit, comme les attaques comportent 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 reprendre et fermer les botnets. Malheureusement, l'IoT vient d'ouvrir un tout nouvel ensemble de systèmes prêts à l'emploi et ouverts à l'exploitation.

Le génie des attaques DDoS vient du fait que le trafic provient d'adresses IP potentiellement LÉGITIMES de vrais clients.

Disons qu'une personne normale vivant aux États-Unis pourrait voir son routeur compromis et le faire utiliser pour DDoS. L'entreprise victime a complètement bloqué l'adresse IP, maintenant cette personne ne peut plus se connecter au service Web de l'entreprise car l'entreprise a entièrement bloqué l'adresse IP, empêchant une adresse IP potentiellement valide d'accéder à nouveau à ses serveurs.

Ceci était un exemple simple, mais imaginez une université ayant quelques adresses IP NAT pour la navigation sur le Web et une entreprise a bloqué certaines de ces adresses IP NAT lors d'une atténuation DDoS. Désormais, des dizaines de milliers de personnes sur ce campus pourraient perdre la connectivité aux serveurs de cette entreprise, ce qui est catastrophique pour les entreprises.

Sans parler des attaques DDoS suffisamment importantes peuvent utiliser 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 la caméra n'était pas spectaculaire, mais coûtait quand même un montant décent. Un jour, quelqu'un nous a appelé au sujet d'une charge sur sa carte de crédit. Il s'est avéré que quelqu'un l'avait récupéré et avait l'habitude d'acheter l'une de ces caméras et l'avait expédiée à quelqu'un qui les regroupait probablement et les clôturait directement ou les expédiait en vrac aux frausters.

Étant un administrateur entreprenant, je creusé dans les journaux pour savoir d'où provenait la fraude. J'en ai trouvé un sur une adresse IP africaine, mais les autres commandes suspectes avaient toutes des adresses IP américaines. En fait, ils étaient tous mandatés par l'intermédiaire de serveurs compromis dans le même centre de données dans lequel se trouvaient nos serveurs Web. À part le signaler à l'hôte, il n'y avait rien à faire. Celui qui a fait cela tirait les ficelles 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 du 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 stupide et simple maintenant

Le botnet, composé d'appareils comme les routeurs Wi-Fi domestiques et les caméras vidéo de protocole Internet, envoie un nombre massif de demandes au service DNS de Dyn. Ces requêtes semblent légitimes, il est donc difficile pour les systèmes de Dyn de les exclure des requêtes normales de recherche de nom de domaine.

Et

Ce sont des attaques difficiles pour arrêter car ils sont souvent canalisés par des fournisseurs récursifs. Ils ne peuvent pas être mis en cache à cause du préfixe aléatoire. Nous avons commencé à voir des attaques de préfixes 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: une personne de la taille de Dyn.

Avec le décollage d'IPv6, vous pourriez bientôt avoir des milliards d'appareils, chacun avec sa propre adresse IP, avec lesquels travailler. La portée est trop grande pour être filtrée efficacement.

Un protocole qui permet à "quelqu'un" de dire à l'infrastructure Internet / aux parties de la dorsale d'arrêter d'accepter / de transférer le trafic de certaines adresses signifie simplement que ce "quelqu'un" n'aurait même pas besoin d'employer des techniques DDOS pour mettre ceux de son choix hors ligne. Sans une "autorité centrale qui n'existe pas", il serait difficile de se mettre d'accord sur qui devrait avoir ce genre de pouvoir de confiance.