Par Jouni Viinikka, Directeur R&D chez 6cure ; Frédéric Coiffier, Ingénieur Développement Logiciel chez 6cure
Les réseaux de diffusion de contenu, les Content Delivery Network (CDN) ont été conçus pour optimiser les performances en matière de distribution de contenus sur Internet et pour optimiser les coûts de bande passante pour celui qui produit ce contenu, afin de faire face à des demandes de plus en plus nombreuses, et à une volumétrie de données à fournir, en forte croissance. Nous entendons souvent l’argument que la protection contre les attaques DDoS fournie par un CDN est LA solution permettant de se protéger : Voyons sur quoi se base cet argument.
FONCTIONNEMENT D’UN CDN
En simplifiant, un CDN est constitué d’un ensemble de serveurs interconnectés, largement distribués du point de vue géographique et mais aussi logique au sein du maillage de l’Internet. Le CDN utilise ces serveurs distribués pour cacher le contenu de leurs clients et le diffuser à leurs utilisateurs. Une utilisation astucieuse du routage permet de s’appuyer sur les « caches » les plus proches de chaque client, permettant une livraison plus rapide du contenu, et d’éviter ainsi de consommer des ressources – y compris la bande passante – du serveur d’origine hébergeant le contenu original. Quand un client demande une première fois une ressource – une image ou une page web, le CDN doit chercher ce contenu auprès du serveur d’origine pour servir le client. Par contre, à partir de ce moment, la ressource reste « en cache » et est distribuée au sein du CDN, afin de servir toute nouvelle demande, par n’importe quel client, à partir de ces caches.
Les CDN cachent typiquement le contenu statique, qui ne change pas, comme justement les images d’un site web. Cependant, les CDN ne peuvent pas ou sont plus limités en leur capacité de cacher du contenu dynamique, comme les informations concernant les stocks et les commandes d’un site de vente. Le contenu dynamique est typiquement hébergé par le site d’origine. Le site d’origine est donc sollicité, non pas par ses utilisateurs, mais par le CDN, d’une part pour du contenu statique pas encore caché et d’autre part pour le contenu dynamique, qui ne peut pas être caché.
CDN ET PROTECTION CONTRE LES ATTAQUES DDOS
De par sa nature, le CDN dispose des mécanismes qui peuvent être utiles en face d’attaques par déni de service distribuée. Par exemple, un CDN dispose souvent de ressources importantes en termes de capacité réseau et de serveurs, lui permettant souvent tout simplement d’absorber une quantité plus importante de requêtes que le serveur d’origine. De plus, par les mêmes mécanismes de distribution et de routage qui lui permettent de distribuer la charge des utilisateurs, les attaques distribuées seront amenées à viser non plus une cible unique, mais une cible distribuée en fonction de la localisation de chaque source d’attaque.
« THE DEVIL IS IN THE DETAILS »
Par contre, malgré ces couches de protection utiles, le fonctionnement même d’un CDN peut ouvrir de nouveaux vecteurs d’attaque ou rendre la défense du serveur d’origine plus
difficile. Par exemple, si une attaque, faisant usage d’un botnet, sollicite un site web pour des ressources non-existantes, et donc non-cachées, cela peut amener le CDN à solliciter à son tour le serveur d’origine à répétition pour ces ressources et provoquer une condition de déni de service pour le serveur d’origine. En plus, l’attaque vue par le serveur d’origine n’est plus distribuée, mais en provenance du CDN ! Dans cette situation, il peut être difficile au serveur d’origine de se protéger car le CDN est en même temps l’origine de l’attaque et des requêtes légitimes: Des approches simples s’appuyant sur le blacklisting des sources au niveau du serveur d’origine ne peuvent plus être utilisées dans ce cas.
D’autre part, il ne faut pas oublier que les protections fournies par le CDN ne couvrent que le contenu caché. Le serveur d’origine, ainsi que plus généralement, l’entreprise à qui le site appartient, aura probablement besoin d’une connectivité fonctionnelle. Au-delà du serveur d’origine qui doit pouvoir fournir le contenu non-caché et dynamique pour le CDN, le service aura peut-être besoin d’interagir avec d’autres sites, l’entreprise de pouvoir envoyer et réceptionner des emails, ses équipes d’accéder aux services de Voix sur IP ou de se connecter à Internet d’une manière générale pour accéder à des services cloud . Tout cela nécessite que des services on-site ou à minima l’accès Internet de l’entreprise, qui ne peuvent pas être protégés par un CDN, continuent à fonctionner.
De plus, en fonction du CDN, les protections fournies peuvent être limitées aux protections de type volumétriques, alors que des attaques applicatives plus sophistiquées risquent de traverser le CDN et d’atteindre le site d’origine. En somme, la situation est souvent bien plus complexe qu’imaginée au premier abord.
CONCLUSION
Premièrement, il est important de bien comprendre le fonctionnement, pas seulement de son site Internet, mais de son entreprise dans sa globalité et d’effectuer une analyse de risque pour identifier les différentes menaces.
Ensuite, selon les risques impliquant la disponibilité et/ou la qualité de service des communications, des services réseau et/ou des applications, il peut être utile de s’appuyer sur des fonctionnalités de protection fournies par son CDN – potentiellement plus capables pour des grosses attaques volumétriques – ou utiliser des protections plutôt de type « On-Premise », potentiellement plus précises et capables pour des attaques applicatives. Souvent une protection optimale implique une protection hybride, combinant la précision et rapidité d’une solution « On-Premise », avec des capacités volumétriques suffisamment élevés proposées par un fournisseur de service de mitigation. Dans certains cas le CDN peut-être un composant adapté, dans d’autres vous aurez besoin d’une capacité de protection volumétrique importante capable aussi à protéger votre site local.