DDoS Déni de service distribué.

Ce que fait réellement une attaque par déni de service distribué

Une attaque par déni de service a un seul but : rendre un service indisponible pour ceux qui en dépendent. La version distribuée, le DDoS, y parvient en générant le trafic depuis de nombreuses machines à la fois, souvent un botnet d'appareils compromis, de serveurs détournés ou d'infrastructures d'attaque louées.

Parce que la charge arrive depuis des milliers d'adresses distinctes, vous ne pouvez pas simplement bloquer un seul coupable, et c'est le nombre considérable de sources qui permet à l'attaquant de submerger une capacité qu'une seule machine n'aurait jamais pu atteindre. La cible n'a pas besoin d'être compromise ni de subir un vol de données. Elle a seulement besoin d'être mise hors ligne, ce qui fait du DDoS une attaque contre la disponibilité plutôt que contre la confidentialité ou l'intégrité.

Les praticiens classent généralement les DDoS en trois couches, car la couche dicte la défense. Les attaques volumétriques cherchent à saturer la bande passante du lien lui-même, en recourant fréquemment à l'amplification, où une petite requête usurpée déclenche une réponse volumineuse dirigée vers la victime. Les attaques protocolaires épuisent l'état des équipements réseau et des serveurs, par exemple en laissant des connexions à moitié ouvertes qui ne se terminent jamais.

Les attaques de la couche applicative sont les plus discrètes : elles envoient des requêtes qui semblent légitimes, comme des appels répétés à un point d'accès de recherche ou à une page de connexion, et épuisent l'application plutôt que le tuyau. Cette dernière catégorie est la plus difficile à distinguer des utilisateurs réels.

Pourquoi l'atténuation n'est plus la partie difficile

Arrêter le trafic DDoS est devenu un service banalisé. De grands fournisseurs comme Cloudflare, Akamai et AWS Shield absorbent les attaques en bordure de réseaux gigantesques, en encaissant les déluges volumétriques bien en amont du client et en filtrant les abus protocolaires et applicatifs par nettoyage du trafic et limitation de débit. Pour la plupart des organisations, la question technique de savoir si une attaque peut être bloquée reçoit un oui assuré, à condition que le trafic soit acheminé via cette protection. La question plus difficile, et celle qu'une fonction de gestion des risques devrait poser, relève de la couverture plutôt que de la capacité.

L'écart qui fait mal, c'est l'actif que personne n'a acheminé via le bouclier. Un site marketing public se trouve derrière le CDN, mais l'API que l'application mobile appelle, l'adresse IP d'origine héritée qui n'a jamais été mise hors service, le point d'accès d'intégration partenaire ou le service régional déployé par une autre équipe peuvent résoudre directement vers l'origine, contournant entièrement la protection. Les attaquants trouvent ces chemins directs et les visent. Une défense DDoS efficace est donc d'abord un problème d'inventaire et de routage : connaître chaque service exposé sur internet, confirmer que chacun se trouve effectivement derrière l'atténuation, et prouver que l'origine ne peut pas être atteinte en la contournant.

La place du DDoS dans la continuité et les normes

Parce que le DDoS attaque la disponibilité, il relève de la même conversation que la gestion de la continuité d'activité. Un système de management de la sécurité de l'information aligné sur ISO/IEC 27001 traite la disponibilité comme l'une des trois propriétés qu'il protège, et un scénario de déni de service est un cas d'école pour une analyse d'impact sur l'activité : combien de temps chaque service peut-il rester hors service, qu'est-ce qui en dépend, et quelle est la solution de repli. La réponse est rarement un contrôle unique. Elle combine une atténuation en amont, un plan de réponse à incident avec des contacts nommés chez le fournisseur d'atténuation, et des dispositions de continuité pour la période pendant laquelle une attaque est absorbée.

Ce que les praticiens font réellement, au-delà de l'achat d'une atténuation, c'est répéter et vérifier. Ils tiennent un inventaire précis des services exposés sur internet, confirment que chacun est derrière la protection, et testent que l'origine est inaccessible directement. Ils ajustent les limites de débit et les pages de défi pour les abus de la couche applicative, puisque ces attaques imitent le trafic réel et ne peuvent pas être résolues par la seule bande passante.

Ils rédigent le chemin d'escalade avant un incident, afin que pendant un déluge personne ne soit à la recherche du bon numéro de téléphone. Et ils traitent un événement DDoS comme un exercice de continuité, avec des seuils clairs pour déclencher le plan, communiquer aux clients et remettre les services en service une fois le trafic retombé.