Le point de vue de Simon Bonin, expert
cybersécurité IMS Networks.
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…
Il faut prendre le
temps de mener deux ou trois ateliers 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. Pour de nombreux
responsables de la sécurité de grands groupes, le stress test apparait 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é. 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. Certaines entreprises 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, l’entreprise 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, l’équipement se trouve en
permanence sur le chemin du trafic, à l’entrée du 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. Une
entreprise 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.