Attaques réseaux lentes

Dernièrement sont parues deux attaques réseaux qui se ressemblent; leur but est identique, réaliser un DOS, et leur méthode également puisque la principe consiste à émettre lentement des données afin d'empêcher le fonctionnement normal du service visé.
La première vient de phrack et concerne TCP 1/ Phrack: Exploiting TCP and the Persist Timer Infiniteness, la seconde de ha.ckers.org 2/ ha.ckers.org: Slowloris HTTP DoS.

1/
TCP est un protocole à timers et débits adaptatif. Il permet ainsi d'assurer des connexions dans des contextes variés. L'attaque présentée par phrack concerne une adaptation aux variations de débits constatées sur les lignes internet.
TCP possède une fenêtre d'envoi, ou taille maximale d'octets pouvant être envoyée sans acquittement par la source. L'émetteur ou le destinataire peuvent décider de la taille de cette fenêtre.

Le destinataire peut donc choisir d'augmenter ou diminuer cette fenêtre, la réduire, voire même la rendre nulle en cas d'incapacité de traitement local ou de surcharge réseau détectée.
La source ne peut donc plus envoyer aucune données tant que cette fenêtre est nulle. TCP va donc attendre que la fenêtre d'envoi de données grandisse avant de renvoyer des données.
La connexion reste ouverte tant qu'elle n'est pas terminée. Le code source de linux précise à ce sujet (conserver ou tuer la connexion):

It is not killed only because window stays zero
for some time, window may be zero until armageddon
and even later.

Donc la connexion peut rester ouverte tant que l'autre partie continue d'émettre des paquets TCP continuant de préciser que la fenêtre est de zéro. Il est de plus tout à fait possible de jouer sur le timer TCP permettant de détecter un temps de parcours lent. Plus on répond avec du délai, plus le timer TCP de la source peut conserver la connexion ouverte sans envoi ni réception de paquets.

L'attaque est donc basée sur ce principe
a) on ouvre une connexion
b) on demande un fichier
c) on indique une fenêtre de zéro octets, et on avertit régulièrement la source que la fenêtre est toujours de zéro. La consommation de ressource côté attaquant est minime.
d) L'hôte visé conserve le nombre de connexions ouvertes, et la quantité de mémoire correspondant aux paquets non envoyés.
e) on boucle sur a) un certain nombre de fois.

L'émetteur va donc devoir conserver au niveau applicatif des fichiers ouverts, et au niveau noyau des connexions TCP ouvertes.
Conclusion: DOS.
L'article contient de plus un code source (nkiller2.c) permettant de prouver cette attaque.

La puissance de cette attaque repose sur un des mécanismes de base de TCP. Et c'est bien à ce sujet qu'elle est redoutable. Les failles protocolaires sont les plus difficiles à contrer. Ce n'est pas une erreur de programmation que l'on peut patcher, ce n'est pas une faille de paramétrage. Cette faille fait intrinsèquement partie de TCP, il va être difficile de la corriger.

Ceci dit, j'émettrai deux réserves.
La première concerne la mise en pratique de cette attaque. Il est bien entendu nécessaire que l'hôte visé soit serveur. Mais pas n'importe quel serveur. En imaginant un serveur ssh, la quantité de mémoire consommée risque d'être faible; en effet la réponse d'un serveur ssh tient en quelques octets. A ce sujet, il est éclairant de voir que le PoC vise explicitement un serveur web. nkiller2 réalise une requête GET, puis pose la fenêtre TCP à zéro.
La seconde concerne l'attaque en elle-même. Elle impose une connexion TCP complète, et maintenue dans le temps. L'attaquant voit donc immédiatement quelle est l'IP source de l'attaquant. Il est donc possible de prendre des contremesures.

Enfin, je testerai bien cette attaque contre un proxy HTTP. L'attaquant requete un gros fichier au proxy, mettons une image ISO de DVD, puis envoie des fenêtres TCP à zéro. Je pense que la connexion TCP entre le proxy et le site final ne sera pas de zéro, obligeant ainsi le relais à conserver en mémoire l'intégralité du fichier. Une extension de l'attaque qui pourrait être intéressante.

2/
ha.ckers.org
Cette attaque cible précisément les serveurs HTTP. Comme le dit son auteur, c'est le principe du TCP SynFlood adapté au protocole HTTP.
Le principe consiste à ouvrir presque complètement, mais pas totalement, une session HTTP et à ne rien faire, sauf à la conserver dans cet état. Par exemple en envoyant octet après octet, en prenant garde à ne jamais dépasser le timeout d serveur web:
GET / HTTP/1.1
X-header : une ligne longue (répetition d'une centaine de caractères)
X-header2 : encore une autre ligne
(...)
etc...
Le serveur web va donc utiliser unt hread pour lire cette requête et conserver ce thread ouvert tant que cette requête n'est pas servie. Comme elle peut mettre très longtemps à arriver, le thread ne pourra pas servir à autre chose...
Le serveur web va donc rapidement consumer ses ressources disponibles et ne plus avoir un unique thread de libre pour servir des requêtes légitimes.
Tant que l'attaquant maintient un grand nombre de connexions ouvertes (supérieure aux nombre de threads alloués pour ce site particulier), alors le site est inaccessible.

Cette attaque est pleine de finesse car elle peut faire tomber un unique site web sans toucher aux autres services de la même machine. De plus, comme la connexion n'est pas entièrement ouverte, les logs n'affichent rien (bien entendu, dès que l'attaque termine, les logs se rempliront). Enfin, si le pirate a préalablement ouvert une connexion de type keep-alive, il pourra alors continuer à interroger le serveur alors que toute nouvelle connexion est impossible.

Encore une fois, la même réserve est abordée. L'adresse IP source de l'attaquant est immédiatement connue, et donc filtrable. Il suffit d'interdire à plus d'une adresse IP un maximum de thread, et l'attaque devient inopérante. Deux méthodes sont fournis permettant de contrer cette attaque, toute les deux basées sur ce principe; la première au niveau système en comptant via netstat le nombre d'IP identiques, la seconde au niveau serveur apache directement.

Par ailleurs, ce site web présente un lien vers un message de security focus .
Ce message propose une autre méthode pour attaquer un serveur web. Elle consiste à utilier plusieurs fois l'option Range:
Range: bytes=0-,0-,0-,0-,0-...
le serveur va donc renvoyer autant de fois le fichier que demandé. Ce comportement pourrait être intéressant, encore une fois contre un proxy.

Conclusion:
Les attaques réseaux lentes sont une manière élégante de faire du DOS. Généralement, le DOS implique une énorme connexion, ou une énorme quantité de données à envoyer. Ces deux méthodes montrent qu'il est possible de faire des DoS efficace en envoyant très peu de données.
Je n'ai pas eu le temps de tester contre un proxy, mais je pense que l'expérience serait efficace.