Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Amplification d'attaques DDoS via un CDN

Amplification d'attaques DDoS via un CDN
2011-03-072013-02-11DDoS/Botnetsfr
Les solutions Content Delivery Network apportent-elles une véritable protection contre les attaques DDoS ? Une étude a démontré que leurs faiblesses permettaient au contraire de réaliser des attaques amplifiées et potentiellement fatales pour les services...
Publié le 7 Mars 2011 par Vincent Maurin dans DDoS/Botnets

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 :

DDoS-et-CDN-1-Requetes-DNS.pngCliquer sur l'image pour l'agrandir

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") :

DDoS-et-CDN-2-Requetes-HTTP-normal.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 :

DDoS-et-CDN-3-Requetes-HTTP-attaque.png

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é :

DDoS-et-CDN-4-Requetes-HTTP-attaque-amplifiee.png

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

2 Commentaires

  • 21 Juin 2011
    2011-06-21
    par
    Topinou
    Super topic !
    Merci !
  • 23 Mars 2011
    2011-06-21
    par
    Je me permets d'apporter quelques lumières à ce billet qui comporte un certain nombre d'inexactitudes.

    Avant toute chose, je tiens à préciser que je travaille au sein de la société Akamai Technologies citée plusieurs fois dans l'étude et ici-même.

    Depuis plus de 5 ans maintenant (une éternité à l'échelle d'internet) les CDN - ces réseaux distribués de diffusion d'applications et de contenus - ont bien évolué en passant de simples relais avec une logique limitée, mise en cache de requêtes HTTP et faire face aux montées en charge, à intelligence multiple, redondée, distribué et haute performance.

    Aujourd'hui, les offres permettent l'accélération des services Internet aussi variés que des applications métiers, des sites de e-commerce, des extranets, des plateformes B2B, et on travaille directement sur IP en plus des protocoles comme HTTP/HTTPS.

    Revenons aux exemples ci-dessus. Les requêtes malicieuses sont la plupart du temps aisément détectable.

    Elles peuvent être bloquées par de l'intelligence directement au niveau du serveur Edge. L'utilisation d'un argument QueryString ne constitue en rien une menace pour qui est correctement préparé. Filtrer les variables QueryString est une question de paramétrage et de quelques clics depuis bien longtemps.

    Concernant l'amplification des requêtes et donc des attaques, l'étude semble complètement ignorer les mécanismes de démultiplexages comme les connexions persistantes et les systèmes hiérarchique qui viennent s'intercaler et contenir l'attaque en terme de connexions TCP et taux de requêtes.

    Akamai est particulièrement conscient de ce type de challenge pour les architectes et responsables sécurité. C'est ce qui nous a amené à proposer plusieurs solutions orientées sécurité dans le Cloud.

    Aujourd'hui nous sommes en mesure de proposer un filtrage opérant dans chaque serveur Edge, ce mécanisme intelligent agit comme un firewall niveau 7 avec une puissance de calcul inégalée jusqu'alors puisqu'utilisant les ressources de nos 84 000 machines autour du globe. Avec cette capacité de traitement on peut, par exemple, prévenir des attaques Cross Site Scripting ou encore « patcher » virtuellement des applications coté Edge en attendant que les équipes de productions puissent faire les mises à jours d'urgence sur les serveurs applicatifs.

    De l'autre coté du nuage, il est possible de protéger les serveurs maîtres en s'authentifiant et en faisant sorte que les équipements réseaux sur l'infrastructure d'origine puissent se couper totalement de l'Internet et ne laisser entrer que les serveurs autorisés.

    Et ce ne sont pas les seuls mécanismes ! La richesse des possibilités permet de combiner des solutions permettant ainsi de répondre à chaque attaque DDoS de manière efficace et sans douleur pour les infrastructures d'origine.

    Les réseaux distribués type CDN ne constituent donc en rien une menace pour les architectures, bien au contraire. Ils agissent comme un bouclier « managé » apportant sécurités et services (de la production jusqu'au conseil) permettant aux responsables de plateformes complexes d'envisager sereinement une protection sans les limites hardware qu'une architecture classique imposait jusqu'alors.

    Pour plus d'informations : http://www.akamai.com/html/solutions/security/ddos_defense.html

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage