Les attaques par déni de service (DoS) constituent un type particulier de menace pour la cybersécurité. L'attaquant n'a pas besoin de pirater vos systèmes ou de trouver une faille dans votre dispositif de sécurité. Il n'a même pas besoin de disposer de connaissances ou de ressources importantes pour lancer une attaque par déni de service efficace - il lui suffit de payer 30 USD par mois pour louer un réseau de zombies et couper efficacement le réseau d'une petite ou moyenne entreprise de l'internet pendant un certain temps.
Les attaques DoS - non, pas MS-DOS, le vénérable système d'exploitation d'autrefois - se divisent en deux grandes catégories : un trafic réseau excessif qui empêche effectivement le trafic légitime d'atteindre vos systèmes et des requêtes excessives qui mobilisent une quantité considérable de ressources pour répondre et empêchent les requêtes légitimes d'être traitées par vos systèmes. Il existe d'autres scénarios marginaux qui relèvent du déni de service au sens large (par exemple, endommager physiquement un serveur ou une ligne de communication), mais il s'agit là de cas exceptionnels plutôt que de la norme.
On distingue également les attaques par déni de service lancées par un seul individu et un seul système source, ou avec un nombre réduit de systèmes sources, et celles lancées par des centaines de milliers de systèmes simultanément contre un système ou un réseau cible (attaque par déni de service distribué, ou DDoS).
En 2020, Amazon a annoncé avoir réussi à se défendre contre la plus grande attaque DDoS connue à l'époque : 2,3 Tbps de trafic ont frappé le réseau AWS, ciblant un petit sous-ensemble de services hébergés. Cela représente 2,3 térabits de trafic par seconde, chaque seconde, pendant un certain temps. Cela équivaut à près de 300 gigaoctets par seconde ou, en chiffres plus anciens, à 67 DVD de données par seconde, chaque seconde (si vous ne connaissez pas, un DVD est comme Netflix, mais sans la partie "net", et ne contient qu'un seul film).
Mais c'était en 2020. En 2018, github s'est défendu contre une autre attaque à grande échelle d'une taille similaire, soit 1,3 Tbps. Il s'agit toujours d'une quantité stupéfiante de données, mais en termes d'aujourd'hui, c'est comme une peinture rupestre comparée à la Joconde.
En 2023, CloudFlare vient d'annoncer qu'il avait mis fin à une attaque DDoS de 71 millions de requêtes par seconde. attaque DDoS de 71 millions de requêtes par seconde. Bien que nous ne puissions pas exactement comparer les chiffres, étant donné qu'AWS a rapporté ses résultats en termes de trafic réseau et Cloudflare en termes de requêtes par seconde (ou, l'attaque d'AWS était du type inondation du réseau et celle de CloudFlare du type épuisement des ressources), il s'agit tout de même d'un chiffre incroyablement élevé.
Comment est-il possible de lancer des attaques d'une telle ampleur ?
Plusieurs facteurs contribuent à la croissance apparente de l'échelle de DoS. Tout d'abord, et c'est assez important, les fournisseurs de services en nuage à grande échelle disposent des plus grandes connexions réseau sur l'internet, de sorte que le trafic de cette ampleur pourra atteindre leurs réseaux et leurs services hébergés. Deuxièmement, le lancement d'une attaque DoS ne dépend pas "seulement" des ressources propres de l'attaquant.
Pour réussir une attaque DoS, il faut généralement exploiter les vulnérabilités d'une multitude de systèmes qui ne le souhaitent pas. Une tactique courante consiste à trouver un type de service qui répond à une requête avec plus de données que celles qui lui ont été envoyées - par exemple, une requête DNS pour google.com répond avec beaucoup plus de caractères que ceux qui ont été initialement envoyés dans la requête. Si vous pouvez également trouver un moyen de tromper le serveur DNS pour qu'il envoie la réponse à votre cible, vous venez de trouver les pions dont vous avez besoin pour réaliser un déni de service. C'est ce qu'on appelle un "DoS par amplification".
De nombreux services se sont révélés vulnérables à l'amplification, c'est-à-dire susceptibles d'être exploités par un pirate pour inonder une cible. serveurs DNS BIND ou les serveurs LDAP exposés à l'internet. Ainsi, un simple attaquant sirotant son café à la maison pourrait compiler une liste de serveurs DNS (et il y en a des milliers), écrire un simple script et, ta-da ! - Le DDoS est prêt à fonctionner.
Si un attaquant n'est pas prêt à se donner la peine d'effectuer une simple recherche Shodan de ces serveurs DNS, il dispose peut-être de 30 USD pour s'abonner à un service de déni de service (DoS-as-a-service). Oui, c'est bien cela. Avec seulement 30 dollars par mois, vous pouvez "louer" un réseau de zombies prêt à participer à de telles entreprises. Payez davantage pour obtenir plus de bots ou des périodes de disponibilité plus longues pour vos attaques.
Qu'est-ce qu'un réseau de zombies ? Il s'agit d'un groupe de postes de travail ou de serveurs, généralement d'entreprise, dotés d'un logiciel caché qui leur permet d'être contrôlés à distance - et donc d'être armés - par un acteur malveillant ou un groupe de menace.
Et quel est l'intérêt d'une attaque DoS ?
Les motivations sont généralement le gain ou le préjudice financier. Il peut s'agir de prendre une organisation en otage en la menaçant de lui verser un montant X en bitcoins ou de mettre ses systèmes hors service, ou de causer un préjudice financier direct en mettant hors service des systèmes qui permettent à une entreprise de faire des affaires ou de réaliser des ventes.
Quel que soit le choix de l'attaquant, la victime est perdante.
Comment la combattre ?
À part compter sur votre fournisseur d'accès pour filtrer le trafic ou souscrire à un service de protection comme Cloudflare, vous ne pouvez pas faire grand-chose d'autre. Et même dans ce cas, vous ne "résolvez" pas le problème, vous ne faites qu'ajouter un tampon (que l'on espère suffisamment grand) entre votre réseau et l'attaquant. Au moment où votre pare-feu périmétrique ou applicatif coupe le trafic DoS, il est déjà trop tard - le tuyau est déjà bouché et il importe peu que vous bouchiez l'évier ou non. Et même si vous parvenez à éviter que le trafic n'atteigne l'intérieur de votre réseau, il peut être d'une telle ampleur qu'il inonde le réseau de votre fournisseur d'accès et finit par affecter votre disponibilité, quels que soient vos efforts.
Et c'est là qu'une attaque par déni de service se distingue des autres menaces de cybersécurité classiques, comme les ransomwares ou un pirate informatique qui s'introduit dans un système. L'attaquant n'a pas besoin de connaître vos systèmes de l'intérieur, il n'a pas besoin de compétences en matière de piratage, et même si vous avez apporté des correctifs à temps pour répondre à vos exigences en matière de conformité, cela ne fait pas vraiment de différence.
Pour lutter efficacement contre les attaques par déni de service, il faut déployer des efforts plus importants pour combattre directement les réseaux de zombies et les services d'amplification des correctifs, plutôt que d'opérer au niveau de la cible. Il s'agit en quelque sorte d'éliminer les armes plutôt que de protéger les cibles.
Les botnets sont créés lorsque les systèmes sont infectés, et c'est là l'approche traditionnelle - hameçonnage, vulnérabilités non corrigées, mauvaises configurations - qui peut en effet être corrigée efficacement. Les services d'amplification sont généralement le résultat de bogues au niveau de la conception ou de la mise en œuvre de ces services - et cela peut également être corrigé. Cela ne fait que renforcer la nécessité d'appliquer des correctifs appropriés à tous vos systèmes. Non pas parce que vous êtes la victime du DoS, mais parce que vos systèmes peuvent être l'arme dirigée contre les systèmes de quelqu'un d'autre.
La meilleure option pour lutter contre ce phénomène est de s'attaquer à la source, et la "source" est tout système infecté ou non corrigé. Comme il n'est pas possible de deviner quel service sera jugé vulnérable pour être utilisé comme amplificateur dans une telle attaque, le meilleur conseil est de simplement patcher tout ce que vous pouvez, partout où vous le pouvez, et de le faire tout le temps. Si cette solution vous semble insurmontable parce qu'elle est perturbatrice, recherchez des options non perturbatrices, telles que le patch en direct.
Assurer la sécurité de vos propres systèmes permet également d'assurer la sécurité des systèmes des autres.

