Les attaques DoS figurent parmi les plus courantes sur le web. Il en existe de nombreuses variantes. L’une d’elles, particulièrement simple à exploiter et peu coûteuse en ressources, mérite notre attention : les attaques Slow HTTP.
Dans cet article, nous présenterons les principes et le fonctionnement d’une attaque Slow HTTP. Nous verrons également les principaux types ainsi que les bonnes pratiques sécurité pour se prémunir.
Comment fonctionne un pool de connexions ?
Pour comprendre le Slow HTTP, il faut d’abord expliquer le fonctionnement d’un pool de connexions d’un serveur web.
Lors de son initialisation, un serveur web threadé crée un pool de connexions. Chaque connexion reste inactive jusqu’à ce qu’un utilisateur, appelé client, en ouvre une via HTTP. À ce moment-là, un thread lui est attribué pour gérer l’échange de données. La connexion reste active jusqu’à ce que l’une des trois situations suivantes se produise : le client termine son opération, ferme la connexion ou celle-ci expire faute d’activité.
Le nombre de threads disponibles est limité et dépend du nombre de cœurs du processeur du serveur. Il est possible d’assigner plusieurs threads par cœur, mais cela peut ralentir les connexions.
Principes et fonctionnement d’une attaque Slow HTTP
Un serveur dispose d’un nombre limité de connexions simultanées. Une fois ce seuil atteint, il ne peut plus en accepter de nouvelles, ce qui le rend indisponible. C’est précisément l’objectif d’une attaque Slow HTTP.
L’idée est d’occuper le pool de connexions aussi longtemps que possible. Une approche classique consiste à générer un grand nombre de connexions pour saturer le serveur, comme dans une attaque DoS classique. Cependant, il existe des méthodes plus subtiles et moins gourmandes en ressources : les attaques Slow HTTP.
Toutes les attaques Slow HTTP reposent sur le même principe : établir une connexion avec le serveur et la maintenir ouverte en envoyant ou recevant des données très lentement, sans déclencher de timeout.
Dans les exemples suivants, nous verrons comment reproduire ces attaques à l’aide de l’outil slowhttptest.
Attention : Tester ces attaques sur des serveurs sans autorisation est illégal. Même si vous possédez ou avez obtenu l’accord du propriétaire, soyez prudent. Certains services tiers (reverse proxy, load balancer, hébergeur, etc.) peuvent être impactés et interdire ce type de test.
Quels sont les principaux types d’attaques Slow HTTP ?
Attaque Slow HTTP de type Slowloris
L’exemple le plus simple concerne une requête GET. Sa structure est la suivante :
GET /index.php HTTP/1.1[CRLF]
Pragma: no-cache[CRLF]
Cache-Control: no-cache[CRLF]
Host: target.com[CRLF]
Connection: Keep-alive[CRLF]
Accept-Encoding: gzip,deflate[CRLF]
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:134.0) Gecko/20100101 Firefox/134.0 [CRLF]
Accept: */*[CRLF][CRLF]Les tags [CRLF] (Carriage Return Line Feed) correspondent aux retours à la ligne. Une requête GET est considérée comme complète lorsque le serveur reçoit deux [CRLF] consécutifs, signalant une ligne vide.
L’attaque repose sur deux principes :
- Ralentir l’envoi des headers : Tant que la connexion reste active, on envoie les données très lentement. Par exemple, si le serveur coupe la connexion après 5 secondes d’inactivité, on envoie un caractère toutes les 4,5 secondes.
- Ne jamais terminer la requête : Pour éviter que le serveur la traite, on ne lui envoie jamais le double [CRLF] final. À la place, on continue à ajouter des headers fictifs à l’infini. Comme les spécifications HTTP autorisent des headers inconnus, il suffit d’en inventer de nouveaux.
Cette attaque, connue sous le nom de Slowloris, a été popularisée par le script du même nom, écrit par Robert « RSnake » Hansen. Son nom fait référence au Loris Lent, un primate d’Asie du Sud-Est au métabolisme particulièrement lent.
La commande pour cette attaque est la suivante :
slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://target.com/index.php -x 24 -p 3Attaque Slow HTTP de type R.U.D.Y
L’attaque R.U.D.Y (aRe-You-Dead-Yet) repose sur le même principe que Slowloris, mais cette fois-ci en ciblant les requêtes POST.
L’attaquant annonce l’envoi d’un volume important de données, comme lors de la soumission d’un formulaire. Ensuite, il transmet ces données extrêmement lentement, bit par bit, tout en respectant les délais pour éviter que le serveur ne ferme la connexion par timeout.
La commande pour cette attaque est la suivante :
slowhttptest -c 1000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u https://target.com/index.php -x 10 -p 3Slow HTTP de type Slow read
Ici, l’attaquant envoie une requête valide à laquelle le serveur répond normalement.
L’attaque intervient lors de la lecture de la réponse : le client récupère les données de manière extrêmement lente, parfois un bit à la fois. Cette technique est particulièrement efficace contre les endpoints qui renvoient de grandes quantités de données.
slowhttptest -c 1000 -X -r 1000 -w 10 -y 20 -n 5 -z 32 -u http://target.com/index.php -p 5 -l 350Comment prévenir les attaques Slow HTTP ?
Le principal défi des attaques Slow HTTP, du point de vue défensif, est qu’elles ressemblent à du trafic légitime. Distinguer une requête volontairement ralentie d’une connexion lente due à un problème réseau peut être complexe.
Les solutions doivent donc trouver un équilibre entre sécurité et expérience utilisateur. Par exemple, imposer un délai strict de 2 secondes pour finaliser une connexion réduit considérablement le risque d’attaque, mais peut pénaliser les utilisateurs avec une connexion lente ou un matériel peu performant.
Il s’agit d’un exercice d’équilibriste. Il faut analyser les données d’utilisation et prendre en compte les retours des utilisateurs pour ajuster en permanence les paramètres et garantir à la fois sécurité et accessibilité.
Limiter le nombre de connexions par IP
Cette solution est très efficace : si un client ne peut ouvrir que quelques connexions, les attaques Slow HTTP deviennent impossibles.
Cependant, il faut rester prudent. Une restriction trop stricte peut pénaliser certains utilisateurs, notamment ceux connectés via un VPN d’entreprise, où plusieurs personnes partagent la même adresse IP.
Réduire la durée maximum d’une requête
Il s’agit simplement de couper les connexions qui ne se finalisent pas après un certain délai.
Cette méthode est très efficace, mais doit être appliquée avec précaution. Une limite trop stricte peut affecter l’expérience utilisateur, surtout si l’application possède des endpoints qui génèrent de grandes quantités de données ou mettent du temps à répondre.
Mettre en place du rate limiting
Il s’agit de limiter la vitesse d’ouverture des connexions, plutôt que leur nombre total par IP. Par exemple, en interdisant à un client d’ouvrir plus de 5 connexions par seconde, les attaques Slow HTTP deviennent quasiment impossibles (en complément des autres mesures). Cependant, il faut rester vigilant : assurez-vous que cela ne bloque pas des besoins métiers qui nécessitent l’ouverture de plusieurs connexions rapidement.
Le rate limiting est une bonne pratique à adopter pour protéger votre plateforme contre diverses attaques, notamment les attaques par brute force.
Il est important de noter que ces options sont généralement incluses dans les technologies de proxying, reverse proxying, load balancing et autres services similaires. Cependant, cela n’est pas systématique, alors vérifiez bien qu’elles sont disponibles dans votre solution.
Conclusion
Les attaques Slow HTTP sont efficaces, simples et peu coûteuses en ressources pour l’attaquant. Elles sont souvent difficiles à détecter avant qu’il ne soit trop tard et peuvent être dévastatrices, rendant les services ciblés complètement inaccessibles.
Heureusement, se protéger contre ces attaques est relativement simple. Il suffit de configurer correctement certaines options du serveur, ce qui devrait déjà être fait pour garantir une gestion optimale des ressources allouées au serveur.
Auteur : Renaud CAYOL – Pentester @Vaadata