[dernière mise à jour de l’article : 24/06 @ 11h30 GMT+2]

Bien que la technique mise en oeuvre par l’outil d’attaque Slowloris (voir notre brève précédente) ne soit guère nouvelle, la simplicité avec laquelle il permet de faire tomber un serveur Apache en fait une menace immédiate.

« Nous l’avons testé à partir d’une Livebox domestique vers un serveur Apache hébergé chez OVH et doté d’une connexion à 100mbps. Il est tombé en six secondes », confirme Nicolas Kerschenbaum, consultant sécurité chez XMCO Partners.

L’attaque opérée par Slowloris (Lémurien en anglais) n’est pas un déni de service réseau traditionnel, mais opère plutôt au niveau applicatif contre Apache, Squid, dhttpd et GoAhead WebServer. Et c’est bien ce qui la rend plus complexe à parer. « Un déni de service traditionnel basé sur un épuisement des connexions sockets sera gêné par la présence d’un équilibreur de charge. Car s’il n’y a aucun contenu, mais simplement un handshake TCP, le load balancer ne va rien transmettre aux serveurs web. Tandis qu’avec cette attaque, il y a du contenu et donc, bien que nous n’ayons pas encore validé ce point précis, il semble qu’un équilibreur de charge ne soit d’aucune aide ici », précise Sébastien Macke, consultant sécurité chez HSC.

Slowloris, en effet, ouvre une véritable connexion sur le serveur web, comme le ferait n’importe quel client HTTP. Il l’initie normalement une requête GET traditionnelle. « Mais il ne termine jamais cet échange, il n’envoie pas la séquence retour chariot / nouvelle ligne attendue. A la place, il envoie juste de temps à autre un en-tête quelconque, qui sera ignoré par le serveur mais qui permettra de maintenir la connexion TCP ouverte », poursuit Sébastien Macke. Et pendant ce temps, bien entendu, Apache attend toujours la fin de sa requête GET…

Le problème posé par Slowloris est épineux car aucune solution toute faite n’est encore disponible. « Nous préconisons de réduire le TIME_ OUT d’Apache, qui est par défaut à 300 secondes. En descendant à 5 secondes cela permettra de libérer des connexions plus rapidement, mais au prix de couper également l’accès aux utilisateurs qui disposeraient d’une moins bonne connexion. Et puis cela ne fait que repousser l’échéance : une vulgaire connexion ADSL suffira toujours à faire tomber le serveur, il faudra simplement un peu plus de temps », estime Sébastien Macke.

Autre piste de solution proposée par les consultants : le module Apache mod_limitipconn , qui permet de limiter le nombre de connexion ouvertes par chaque adresse IP. Mais cela pénalisera nécessairement les utilisateurs légitimes qui se connectent depuis un proxy (dans une grande entreprise ou via celui de leur fournisseur d’accès). « Et puis cela arrêtera peut-être l’attaquant inexpérimenté qui veut s’amuser depuis chez lui, mais pas celui plus motivé qui dispose de plusieurs adresses IP, par exemple via un botnet », met en garde Sébastien Macke.

Le module Apache mod-qos permettrait lui aussi de renforcer le serveur en limitant le nombre de connexions par IP sur une fenêtre de temps donnée (Maj du 24/06 @ 11h30 GMT+2)

Dans une discussion dédiée à la menace , les membres de SecurityVibes proposent également plusieurs solutions de contournement. La première, et probablement la plus efficace : placer devant les serveurs Apache un serveur non-vulnérable en mode reverse proxy.

« Attention toutefois à bien sélectionner le reverse proxy en question ! De nombreuses solutions du commerce sont basées sur Apache et tomberont elles-aussi ! Un ISA Server devant Apache serait toutefois un bon candidat en effet », observe Pierre Noguès, lui aussi consultant sécurité chez XMCO Partners. Des solutions très utilisées, telles celles de F5 Networks, sont par exemple basées sur Apache et ne conviendront pas à un tel usage. Deux membres de SecurityVibes, Sylvain Maret et Sebastien Gioria , ont d’ailleurs validé la fragilité d’un reverse proxy Apache (avec mod_proxy) en faisant tomber une telle infrastructure en une minute et 700 connexions.

Ainsi, lightHTTP, que l’on disait résister à cette attaque et donc un bon candidat au rôle de reverse proxy, serait en fait seulement plus long à neutraliser, mais ne serait pas invulnérable, d’après un commentaire laissé sur le site de RSnake. Nous ne l’avons toutefois pas testé (Maj du 24/06 @ 11:30 GTM+2)

Autre approche préconisée par un membre de SecurityVibes : « Mettre en place des scripts Perl / Python / Ruby / shell qui regardent les connexions ESTABLISHED depuis trop longtemps, via netstat, et génèrent des blacklists pour le firewall ». La solution est toutefois à manier avec précaution tant elle peut rapidement conduire à couper le site de tout un pan d’internet (ce qui serait en quelque sorte un DoS dans le DoS !). En outre, la fenêtre de réaction est limitée : le script n’aurait que quelques secondes pour réagir avant que le serveur ne tombe.

Pour Matthieu Estrade , committer Apache httpd et membre de SecurityVibes, le salut reste à inventer coder : il pourrait venir d’un module au sein d’Apache qui s’accrocherait au niveau connexions et obligerait les clients à envoyer un volume minimal d’informations avec leurs requêtes, afin d’exiger une bande passante plus importante de la part de l’attaquant. Mais, précise-t-il, « cela exigerait d’analyser le comportement des clients » au préalable. Autant dire que ce sera pour la prochaine vague d’attaques. Mais en tout cas l’idée est déjà dans le tuyau via la mailing list des développeurs Apache.

FreeBSD semble, quant à lui, un peu mieux protégé, mais ce n’est pas encore suffisant : « Il existe bien sous FreeBSD un outil appelé HTTPReady susceptible de protéger les serveurs Apache contre cette attaque. Mais il ne protège que contre les requêtes GET et HEAD, et non POST. Slowloris intègre donc un switch pour basculer sur des requêtes POST juste pour les serveurs FreeBSD avec le filtre HTTPReady », explique Wolfgang Kandek, CTO de l’éditeur Qualys.

S’il est très efficace, le lémurien tueur n’est en revanche pas très discret, ce qui permet de déceler une attaque rapidement. « Elle apparaît très clairement dans les journaux, avec une rafale d’erreur de type ‘internal dummy connections’, ou bien des messages relatifs à l’incapacité de lire les en-têtes HTTP », explique Nicolas Kerschenbaum.

En ciblant essentiellement Apache (67% des serveurs sur Internet selon Netcraft ) et en étant particulièrement simple à mettre en oeuvre (quelques centaines de lignes de Perl), Slowloris a le potentiel de devenir une véritable nuisance sur le web, d’autant plus que la Fondation Apache n’a semble-t-il guère de marge de manoeuvre. Car corriger le défaut impliquerait « de revoir une bonne partie du code, et la gestion même des connexions », imagine Nicolas Kerschenbaum. Une tâche peu triviale qui encore n’a jamais été entreprise, alors même que les principes de cette attaque remontent à 2005. A moins, bien sûr, que la publicité autour de l’outil ne soulève les montagnes…

Maj du 24/06 @ 11h30 GMT+2 : des correctifs seraient en préparation chez plusieurs éditeurs de WAF (web application firewall) vulnérables afin de les protéger contre cette attaque.

N’hésitez pas à partager votre expérience si vous avez une solution pour remédier à cette faille.