Les plateformes et services numériques doivent se protéger des attaques par déni de service distribué (DDoS). Ces attaques reposent sur un réseau de logiciels robots appelés “bots” (généralement des milliers de machines compromises connectées à Internet). Chacun de ces bots contribue à saturer votre plateforme numérique (au niveau du réseau, de l’équilibreur de charge et du serveur) et à rendre votre service indisponible. Le fait que ces attaques soient distribuées sur des milliers d’appareils répartis sur une multitude de réseaux d’opérateurs rend leur atténuation difficile (si vous voulez creuser davantage la nature des DDoS : https://en.wikipedia.org/wiki/DDoS_mitigation). La plupart des organisations qui s’appuient sur des services numériques / applications web pour mener leurs activités s’abonnent à des services de protection contre les DDoS. La question est de savoir comment ces protections DDoS influencent le chemin du réseau et la vitesse à laquelle leurs utilisateurs accèdent à leur plateforme numérique. Chaque client de ces services doit évaluer l’impact des protections DDoS sur les performances de ses utilisateurs.
La plupart des fournisseurs cloud / CDN de taille mondiale ont leurs propres offres d’atténuation des attaques DDoS
- Google → Projectshield
- CloudFlare → CloudFlare DDoS
- Amazon Web Services → AWS Shield
- Microsoft Azure → Azure DDoS Protection
- Verisign → Verisign DDoS Protection
Si vous cherchez une bonne comparaison de ces différents services, jetez un coup d’œil à cet article.
Comment fonctionnent les protections contre les DDoS
Tous les services de protection contre les attaques DDoS énumérés ci-dessus s’appuient sur une infrastructure cloud à grande échelle et surtout sur une présence réseau distribuée. Cela leur permet de ne pas être affectés par les quantités massives de trafic DDoS qu’ils doivent filtrer.
A partir de cette liste, la première distinction à faire est d’isoler :
- les fournisseurs de services cloud offrant une protection contre les attaques DDoS pour les charges de travail de serveurs hébergé dans leur plateforme cloud,
- les fournisseurs qui offrent ce service pour les charges de travail de serveurs indépendamment de leur emplacement (par exemple, dans votre datacenter).
Enfin, ils visent tous à filtrer le trafic des botnets par une série d’heuristiques alimentées par des inspections du trafic réseau, des proxies, etc. Ils effectuent ce filtrage par différents moyens :
- Agir comme un proxy inverse comme Projectshield
- Rediriger le trafic vers la Platforme de protection contre les DDoS en modifiant vos enregistrements DNS.
- Les fournisseurs de protection contre les attaques DDoS annoncent vos préfixes IP dans leurs stratégies BGP afin de rediriger votre trafic vers eux.
Toutes ces méthodes consistent à réacheminer le trafic qui irait normalement du réseau et /systèmes autonomes de vos utilisateurs vers votre plateforme en passant directement par la plateforme de votre fournisseur, afin de délivrer un trafic « propre » à votre plateforme.
Cette protection DDoS peut être active 365 jours par an ou sur demande.
Quel est l’impact d’une protection DDoS sur les performances ?
En cas de DDoS, vos performances seront préservées et stabilisées, mais quel est l’impact sur les performances dans des conditions d’exploitation normales ?
La toute première chose à comprendre est que le chemin de vos utilisateurs vers votre plateforme sera affecté, soit pour tous les utilisateurs, soit pour certains utilisateurs à certains moments.
Prenons l’exemple d’une protection DDoS fournie par CloudFlare par le biais du routage BGP. Dans ce cas, CloudFlare annonce les préfixes de ses clients dans sa politique BGP. Ceci est fait 365 jours par an et la route de CloudFlare peut être préférée en cas de DDoS pour éviter d’inonder l’infrastructure du client avec du trafic DDoS..
Dans la capture d’écran ci-dessous, nous voyons l’itinéraire emprunté depuis l’une des stations de Kadiska jusqu’à la plateforme du client. Nous pouvons identifier plusieurs chemins pour aller d’une extrémité à l’autre.
Nous voyons deux routes principales entre notre station à Tokyo et la Platforme de ce client :
- la route part d’un premier fournisseur qui prend la décision de faire passer tout le trafic par iD3.net.
- Dans la plupart des cas, iD3.net achemine le trafic via son propre réseau directement vers le système autonome du client (le plus souvent, cet AS correspond directement à l’AS du client), mais dans certains cas, il peut décider d’acheminer le trafic via l’infrastructure de CloudFlare.
Le fait le plus important à retenir de ce diagramme est que les décisions de routage sont pilotées par la politique BGP de l’opérateur / AS situé au point d’entrée de vos utilisateurs (à gauche) qui prendra des décisions de routage basées sur la performance (chemin le plus court) et la rentabilité (coût du transit / accords de peering). Si vous avez besoin d’éclaircissements sur la façon dont BGP gère cela, veuillez vous référer à cet article.
Quelles sont les questions clés de performance auxquelles il faut répondre ?
- Tout d’abord, vous devez comprendre où se trouvent vos utilisateurs et par quel opérateur ou AS ils se connectent.
- Deuxième question sur votre liste : où se trouvent vos points de présence (ou ceux de vos fournisseurs cloud ou d’hébergement) ? A quelle distance, en termes de latence et de nombre de sauts, se trouvent-ils des opérateurs de vos utilisateurs ?
- Troisième question de votre liste : où se trouvent les points de présence de vos fournisseurs de DDoS et à quelle distance se trouvent-ils de vos utilisateurs ?
- Enfin, comment les AS les plus importants côté utilisateurs acheminent-ils le trafic vers les différents éléments de votre plateforme ?
Cela vous permettra de savoir si, dans des conditions normales, vous acheminez votre trafic directement vers votre AS ou par l’intermédiaire de votre fournisseur de protection contre les DDoS et si cela se traduit par une perte ou un gain de performance (plus ou moins de latence, de perte de paquets et de sauts).
En fonction de la route empruntée, la latence sera plus ou moins élevée, le nombre de sauts plus ou moins important. La perte de paquets variera également.
Ce que nous voyons ci-dessus est l’évolution sur 2 semaines, mais vous devez considérer que tout ceci est dynamique, dirigé par de multiples facteurs et sujet à de fréquents changements :
- La politique BGP de chaque opérateur sur la gauche
- L’évolution du chemin du réseau (indisponibilité, congestion, événements) affecte toutes les routes possibles qui sont évaluées.
Que pouvez-vous faire pour optimiser l’accessibilité de votre plateforme ?
Les données de surveillance ne sont utiles que si elles sont exploitables et applicables ! Il est évident que votre politique BGP a un impact sur la façon dont vous acheminez le trafic de votre système autonome vers le reste de l’Internet.
En ce qui concerne le trafic entrant, la question clé est de savoir comment vous pouvez avoir un effet sur la route empruntée pour atteindre votre propre Platforme. Il est facile de comprendre que plus un AS est éloigné de votre propre AS, plus votre capacité à agir sur lui est réduite..
Les seules actions que vous pouvez entreprendre sont :
- Modifier les accords d’échange de trafic et de transit (pour éviter d’annoncer des routes en provenance/à destination de votre AS par des AS qui offrent de mauvaises performances).
- Demander à vos fournisseurs de transit d’agir de la même manière et d’éviter les routes peu performantes.
Par exemple (voir la figure ci-dessous), vous pouvez éviter la route de Cogent à CloudFlare (menant à l’AS du client) parce qu’elle présente des taux de perte de paquets élevés et lui préférer d’autres routes (y compris par le même opérateur Tier1 mais par un chemin différent).
Si vous souhaitez prendre des mesures et commencer à optimiser l’accessibilité de votre plateforme (en passant par un service de protection contre les DDoS ou non), je vous suggère de jeter un coup d’œil à cet article.
