Il fut un temps où de nombreux architectes réseaux et systèmes s'arrachaient les cheveux pour optimiser au mieux leur infrastructure d'hébergement web.
La raison principale ? Offrir une qualité de service à la hauteur de la volumétrie des données distribuées aux visiteurs de leur(s) sites(s) web.
Puis vinrent sur le marché des solutions de Content Delivery Network, abrégées sous l'acronyme CDN, offrant à ces mêmes architectes un réseau de serveurs capables de distribuer les données via l'utilisation de mécanisme de cache.
Principes du serveur web
Un serveur web est constitué d'un ensemble de processus systèmes dont le rôle consiste à accomplir les principales tâches fonctionnelles suivantes :
- être à l'écoute des requêtes HTTP sur un port défini (généralement le port 80)
- répondre par l'envoi du contenu du fichier demandé (ex: un fichier image, un fichier PDF, ...)
- répondre par l'envoi du résultat d'un script exécuté (ex: un script PHP, un script Python, ...)
- stocker dans un fichier log le détail des informations demandées et échangées
Afin d'optimiser la capacité du serveur à répondre à plusieurs demandes simultanées, le processus maitre distribue les tâches à effectuer à un certain nombre de processus fils.
Néanmoins, tout système d'exploitation possède un nombre limité de sockets TCP (canaux de communication dans lesquels sont échangées les données). Pour faire un parallèle simple, lorsque toutes les pompes d'une station service sont occupées, les automobilistes qui arrivent et souhaitent faire le plein, doivent attendre la libération d'une pompe.
Principes des réseaux de distribution de contenu
Les réseaux de distribution de contenu ("Content Delivery Network" ou CDN) ont pour objectif de distribuer un contenu au plus grand nombre selon les conditions suivantes :
- déterminer quel est le serveur du réseau se trouvant au plus près du demandeur
- répondre à la demande en allant chercher l'information sur le serveur d'origine
- stocker l'information récupérée en y associant une durée de conservation
- transférer en réponse l'information au demandeur
- tant que l'information stockée est encore conservable, la distribuer aux prochains demandeurs
En résumé, le CDN s'apparente à un réseau intelligent qui redirige les demandes des internautes vers le serveur qui d'un point de vue réseau se trouve le plus près (temps de latence ou nombre de réseaux traversés faibles). Charge ensuite à ce serveur de prendre contact avec le serveur détenteur de l'information (le serveur web maitre) et de stocker en cache les informations.
Bien évidemment, le principe ne s'applique qu'aux contenus statiques et non dynamiques. Si la demande concerne une recherche d'informations en fonction de critères saisis par l'utilisateur, alors la requête ne peut être mise en cache et sera donc demandée systématiquement au serveur web maitre.
Les réseaux CDN sont caractérisés par le nombre très important de serveurs caches dont ils disposent ainsi que leur emplacement aux croisées des noeuds réseaux des grands opérateurs nationaux et internationaux. A l'image d'une raquette de randonnée qui répartit le poids du randonneur lorsqu'il marche sur la neige, les milliers de serveurs cache du DNS permettent de répartir des demandes nombreuses en plusieurs points réseaux répartis géographiquement.
Illustration de l'utilisation d'un CDN
Comme indiqué plus haut, la première étape consiste à déterminer le serveur du CDN au plus proche de l'internaute :
Le principe est le suivant :
1. le système de l'internaute interroge son serveur DNS pour connaitre l'adresse IP du serveur web
2. le serveur DNS s'adresse au serveur DNS autoritaire, qui fait partie du réseau CDN
3. le serveur DNS du CDN détermine quelle est le serveur cache le plus proche de l'internaute
4. le serveur DNS de l'internaute lui retourne l'adresse IP déterminée par le réseau CDN
Une fois l'adresse IP en poche, le système de l'internaute va initier une session HTTP avec le serveur cache qu'il pense être le serveur web qu'il souhaite joindre. Il lui demande alors un fichier image (appelé ici "fleur.png") :
Cliquer sur l'image pour l'agrandir
Le serveur cache choisi par le CDN va alors devoir répondre à la demande de l'internaute en se positionnant lui même comme un internaute vis à vis au serveur web maitre :
1. l'internaute demande le fichier "fleur.png"
2. le serveur cache demande à son tour le fichier "fleur.png" au serveur web
3. le serveur web répond par l'envoi du contenu du fichier image demandé
4. le serveur cache stocke dans son système cache le fichier et le distribue à l'internaute
A présent, si de nouveaux internautes réclament le même fichier du même serveur web au même serveur cache, ce dernier se contentera de leur distribuer le fichier sans solliciter le serveur web maitre :
5. un nouvel internaute demande le fichier "fleur.png"
6. le serveur cache distribue le fichier qu'il a stocké à l'étape 4
7. un nouvel internaute demande le fichier "fleur.png"
8. le serveur cache distribue le fichier qu'il a stocké à l'étape 4
... etc
Attaque DDoS utilisant le CDN
Le système présenté ici vous semble optimisé et capable de répondre à un nombre important de requêtes associées à des contenus statiques. Et bien, détrompez-vous, c'est en substance ce que met en évidence une étude d'une université datant de fin 2009 : "Content Delivery Networks: Protection or Threat ?" (ou "Réseaux de distribution de contenu : protection ou menace ?").
L'étude menée sur trois CDN (Akamai, Coral et Limelight) démontre que ces derniers n'offrent pas le niveau de protection attendu face à des attaques en déni de service, distribuées. L'objectif de telles attaques est par exemple d'inonder un serveur web de requêtes HTTP afin de saturer le système qu'il l'héberge. Au passage, il est fort probable qu'un équipement de protection, de type firewall situé en amont, sature également en laissant passer des flux légitimes mais qui remplissent rapidement sa table de sessions actives.
Le principe de l'attaque se base sur l'incapacité du CDN à traiter les demandes relatives à du contenu dynamique. en ajoutant un paramètre de type QUERY_STRING à la demande, le CDN comprend qu'il s'agit de contenu non statique et s'adresse donc au serveur web maitre :
Cliquer sur l'image pour l'agrandir
1. l'attaquant demande le fichier "fleur.png?hack=001"
2. le serveur cache demande à son tour le fichier "fleur.png?hack=001" au serveur web
3. le serveur web répond par l'envoi du contenu du fichier image demandé
4. le serveur cache stocke dans son système cache le fichier et le distribue à l'internaute
Puis l'attaquant reproduit sa demande une nouvelle fois :
5. l'attaquant demande le fichier "fleur.png?hack=002"
6. le serveur cache demande à son tour le fichier "fleur.png?hack=002" au serveur web
7. le serveur web répond par l'envoi du contenu du fichier image demandé
8. le serveur cache stocke dans son système cache le fichier et le distribue à l'internaute
Et ainsi de suite ... opérations 9 à 12. Des requêtes HTTP adressant un contenu statique sont donc assimilées à des requêtes adressant un contenu dynamique. La protection initiale du CDN est donc outrepassée !
Optimisation de l'attaque
En agissant de la sorte, l'attaquant récupère, suite à sa demande, le contenu du fichier demandé. La bande passante utilisée devient donc rapidement chargée entre le serveur cache du CDN et le poste de l'attaquant. En imaginant que l'attaquant agisse via l'utilisation de machines zombies, les propriétaires des machines zombies vont rapidement s'apercevoir de la baisse de leur bande passante et des performances de leur poste, occupé à récupérer les nombreux fichiers demandés.
C'est alors qu'une autre faille des CDN, constatée lors de l'étude, est employée. Partant du constat que les serveurs cache des CDN agissent dans la chaine de traitement comme des postes clients standards (ils initient une demande auprès du serveur maitre, indépendante d'un point de vue TCP de la demande initiale), voici le mécanisme employé :
Cliquer sur l'image pour l'agrandir
1. l'attaquant demande le fichier "fleur.png?hack=001" et se déconnecte immédiatement
2. le serveur cache demande à son tour le fichier "fleur.png?hack=001" au serveur web
3. le serveur web répond par l'envoi du contenu du fichier image demandé
Puis l'attaquant reproduit sa demande une nouvelle fois :
4. l'attaquant demande le fichier "fleur.png?hack=002" et se déconnecte immédiatement
5. le serveur cache demande à son tour le fichier "fleur.png?hack=002" au serveur web
6. le serveur web répond par l'envoi du contenu du fichier image demandé
Et ainsi de suite ... opérations 7 à 9. Un effet d'amplification est donc réalisé puisque l'attaquant n'a plus à supporter la bande passante générée par les réponses à ses requêtes HTTP ! L'étude mentionnée plus haut démontre que le concept s'applique aisément sans que les CDN ne repèrent le mécanisme de demandes abandonnées en cours de route ...
Conclusion
Vous remarquerez en reprenant les trois mécanismes de requêtes que nous avons réalisé une optimisation non négligeables :
Scénario "classique"
pour N requêtes client, nous avons N réponses au client
via 1 requête et 1 réponse du serveur maitre
Scénario "attaque"
pour N requêtes client, nous avons N réponses au client
via N requêtes et N réponses du serveur maitre
Scénario "attaque amplifiée"
pour N requêtes client, nous avons 0 réponses au client
via N requêtes et N réponses du serveur maitre
N'oubliez pas non plus qu'en cas d'attaques de ce type, votre solution de protection doit être en mesure de répondre de manière adaptée. En effet, un filtrage trop rapide qui ajouterait les serveurs cache d'un CDN dans une blacklist, vous priverait des toutes les autres requêtes licites en provenance du même CDN.
Il est donc primordial pour les architectes désireux de déployer une solution de CDN, de fortement prendre en compte ces éléments dont l'impact est fort en terme de sécurité. Une configuration particulièrement adaptée aux contenus à distribuer est donc nécessaire (par exemple, ne pas considérer les requêtes de type "/images/*.png" comme du contenu dynamique).
Avertissement : cet article n'a pas pour objectif d'inciter nos lecteurs à mettre en oeuvre des tels mécanismes d'attaques qui n'engageraient que leur responsabilité.
Pour aller plus loin
Définition d'un serveur HTTP: http://fr.wikipedia.org/wiki/Serveur_HTTP
Définition d'un réseau CDN : http://fr.wikipedia.org/wiki/Content_Delivery_Network
Définition d'une attaque DDoS : http://fr.wikipedia.org/wiki/Ddos
Jeu de briques
Snake
Pacman
Bubble