Anti-DDoS : comment être certain qu’une solution protège correctement ?

Disposer d’une protection anti-DDoS ne permet pas nécessairement de savoir comment elle se comporte, lorsqu’une attaque survient. Une bonne prise en main commence par une connaissance précise des flux, des applications exposées et des réglages de protection. Elle passe ensuite par la simulation, les tests et la capacité à ajuster les mécanismes de mitigation en fonction de la réalité du trafic.

De nombreuses entreprises partent du principe que leur protection DDoS, souvent fournie dans le cadre d’un bundle d’offres réseau ou sécurité, fonctionne en mode « plug & play ». En place, elle serait là pour agir comme un airbag et peu importe si les détails sur son fonctionnement exact ou ce qui se passe au quotidien sont limités. Pourtant, en cas d’attaque et de crise, ce parti pris peut vite poser un problème.

Comment faire pour éviter cet écueil et se sentir vraiment en maîtrise de sa défense anti-DDoS ? La première étape consiste à organiser des ateliers techniques au moment du déploiement. Il s’agit notamment de cartographier les flux : quelles applications sont exposées, quels types de trafic, comment les regrouper ou les isoler, quels modules sont associés…

Chez IMS Networks, nous prenons le temps de mener deux ou trois ateliers avec nos clients avant de placer la solution en mode « simulation » pendant sept à quatorze jours. Cette période permet d’identifier les faux positifs, de retrouver des applications oubliées ou encore de repérer des flux qui devraient être séparés.

La phase de déploiement peut d’ailleurs faire apparaître des éléments inattendus dans le système d’information. C’est un moment où l’on peut découvrir qu’une application censée être décommissionnée est toujours utilisée, par exemple. Le travail autour de l’anti-DDoS devient alors également un exercice plus large de connaissance du SI.

Tester, améliorer, paramétrer avec finesse

Après la phase de simulation vient la mise en protection, de manière coordonnée avec le client. Les protections robustes sont souvent celles qui ont été testées plusieurs fois et améliorées. Cette logique de test reste encore peu répandue. Dans le cadre d’un échange organisé par Alliancy et IMS Networks avec plusieurs responsables de la sécurité de grands groupes, le stress test est apparu comme une préoccupation particulièrement importante. Un dispositif qui n’est pas testé n’est pas « combat proof », résumait avec justesse l’un des participants.

Le principe est simple : une organisation peut difficilement savoir si sa protection est correctement adaptée lorsqu’elle n’a jamais observé son comportement dans une situation proche d’une attaque réelle. Les entreprises régulièrement ciblées disposent d’un retour d’expérience direct. Pour les autres, la simulation et les tests permettent de mettre en évidence les éventuels angles morts. 

En revanche, si une attaque a bien eu lieu, il est nécessaire de comprendre en profondeur ce qui s’est réellement passé. C’est pourquoi nous comparons ce que montrent nos propres graphes avec ce que le client a observé sur ses serveurs. Si un serveur DNS est tombé, nous pouvons par exemple constater que le seuil configuré était trop élevé. Sur le papier, le serveur devait peut-être tenir 6 000 requêtes par seconde, mais dans la réalité, il peut ne pas en être capable ou encore recevoir en parallèle du trafic venant d’un second opérateur. Dans ce cas, il devient possible d’abaisser le seuil de tolérance pour bloquer plus tôt et au plus proche de la réalité du trafic que le serveur peut supporter.

Dans d’autres cas, il devient nécessaire d’activer un module qui ne l’était pas parce qu’il pouvait générer des faux positifs. Certains clients choisissent un fonctionnement où un module reste en simulation au quotidien et bascule automatiquement en protection lorsque le volume devient inhabituel. À ce moment-là, la politique devient volontairement beaucoup plus stricte. La finesse de la réponse vient de la capacité à s’adapter à la criticité des applications. Sur un service particulier, le client peut ainsi accepter qu’une petite part de trafic légitime soit rejetée pendant l’attaque pour garantir la disponibilité globale. Sur un autre, aucun faux positif ne sera acceptable. Nous pouvons aussi utiliser de la GeoIP dans certains scénarios, par exemple pour n’autoriser temporairement que des IP françaises. C’est précisément l’intérêt d’un réglage application par application.

Mesurer le temps nécessaire pour réagir

Un autre paramètre mérite une attention particulière : le « time to mitigate », c’est-à-dire le temps qui s’écoule entre le début de l’attaque et le moment où le trafic est effectivement nettoyé. Dans une architecture inline, comme celle proposée par IMS Networks, l’équipement se trouve en permanence sur le chemin du trafic, à l’entrée de notre backbone opérateur. Il voit donc immédiatement ce qui arrive. Sur des pics volumétriques importants, le temps de réaction peut être de l’ordre de quelques secondes.

Cependant, d’autres architectures fonctionnent avec une phase de détection suivie d’une redirection du trafic vers un centre de scrubbing. Le délai peut alors être plus long, certaines solutions annonçant une à deux minutes. Cette différence devient importante face aux attaques dites « hit and run ». Un pic extrêmement violent de trente secondes va faire tomber ou redémarrer un firewall ou un équipement réseau, puis recommencer dix ou quinze minutes plus tard. Si la mitigation démarre après une minute, le pic est déjà terminé alors que l’équipement a pu subir le choc.

La question de la capacité doit donc être associée à celle de la vitesse de réaction. Un client ne peut évidemment pas absorber seul tous les volumes. L’opérateur doit lui-même dimensionner son infrastructure en fonction du nombre de clients protégés, du risque d’attaques simultanées et des volumes plausibles.

Au fond, pour être certain qu’une solution anti-DDoS protège correctement, il faut comprendre comment elle fonctionne, ce qu’elle voit, à quelle vitesse elle agit, ce qu’il est possible d’ajuster et si son niveau de protection correspond réellement à la criticité des services exposés.