Mythe de sécurité #2: Le déni de service distribué est un problème de bande passante
Tous les dénis de service, qu’ils soient distribués ou non, ne se limitent pas qu’à la seule bande passante.
Il ne demeure pas moins qu’une classe de déni de service va aller par saturation de la bande passante, mais cette approche est couteuse et peu rentable pour l’attaquant. Ça exige une masse importante de drones pour mener à bien ce type d’attaque. Essentiellement, la consommation de la bande passante se fait 1:1. Où ça devient plus intéressant pour l’attaquant, c'est lorsqu’il est possible d’arriver à un déni de service lorsque l’usage de la bande passante est inférieur à 1:1. Cela est possible quand on s’attaque aux applications, qui généralement ne « scale » avec la même facilité que la bande passante, en plus qu’il existe certains vecteurs d’attaque qui à l’aide d’un seul paquet peut générer une charge importante et ainsi permet de saturer le CPU et/ou la mémoire rapidement et sans effort. Comme dans tout, l’effet de levier est toujours l’avenue la plus avantageuse pour celui qui s’en sert.
À tort, la disponibilité est regardée seulement sous l’angle de la sécurité et de l’infrastructure. Le domaine de la « capacité performance » englobe justement l’évaluation de la capacité des applications à prendre une charge définie, mettre en place des fils d’attentes pour protéger l’application d’une surcharge subite ou encore d’augmenter la capacité applicative au gré de la demande. À l’intérieur des outils à la disposition des spécialistes en capacité performance, il existe des volets de sécurité qui vont spécifiquement protéger les applications contre des manoeuvres couteuses en ressource et les diverger ailleurs (offloading) ou carrément les bloquer avant d’atteindre l’application.