Les attaques par déni-de-service deviennent plus sophistiquées

Version imprimable

20/01/2011, 01h26
Katleen Erna

Les attaques par déni-de-service deviennent plus sophistiquées

Des attaques DoS plus performantes
De nouvelles attaques DoS menacent

le 19/01/2011
Un nouveau type d'attaques par déni-de-service, plus costaud, a émergé ces derniers mois. Il s'en prends de manière plus virulente aux piles TCP/IP des réseaux.

Les chercheurs du cabinet sécurité Trustwave SpiderLabs ont donné plus de détails sur ces nouvelles attaques cette semaine lors de la conférence de sécurité Black Hat. Ils ont également fourni des suggestions sur la façon d'atténuer les risques.

Tom Brennan, directeur de Trustwave SpiderLabs explique qu’une simple utilisation de Layer 7 avec une application web suffit pour causer une attaque de type DoS.

Il explique aussi que ceci se produit lorsqu’un client fait une demande de connexion sur un serveur web qui demande des informations via une requête HTTP POST (comme un formulaire par exemple), le serveur en attend les réponses, qui sont en fait envoyées lentement par l’attaque.

Brennan a publié un outil appelé l'outil HTTP POST dans le cadre de l'OWASP (Open Web Application Security Project), pour aider les professionnels de la sécurité à voir s’ils courent des risques avec l’attaque du Layer 7 DoS.

Contrairement aux attaques traditionnelles DoS (layer 4) qui peuvent être bloquées par un FAI, les attaques de Layer 7 sont plus difficiles à traiter.

Emma Hernandez

Source : Conference de Black Hat D.C. security
20/01/2011, 09h33
ratomms

Apparemment, c'est le moyen le plus sûr pour faire une attaque.
20/01/2011, 11h05
Antoine_935

Ça fait une bail qu'on la connait cette attaque. Et seuls les serveurs qui servent avec des threads y sont sensible. Des serveurs tel qu'Nginx, qui lisent les sockets de manière asynchrone, y sont logiquement immunisés.
20/01/2011, 11h18
souviron34

Citation:

Envoyé par Antoine_935

Ça fait une bail qu'on la connait cette attaque. Et seuls les serveurs qui servent avec des threads y sont sensible. Des serveurs tel qu'Nginx, qui lisent les sockets de manière asynchrone, y sont logiquement immunisés.

:mrgreen:

je vais peut-être enfin arrêter de me faire prendre pour un gonzo :D

Depuis le temps que je dis que les threads sont une c.nnerie et que le traitement asynchrone des sockets est un outil merveilleux... Quoique nécessitant (ah, mais mon brave, c'est tout le problème) une programmation correcte et réfléchie....
20/01/2011, 11h58
JulienDuSud

Citation:

Envoyé par souviron34

:mrgreen:

je vais peut-être enfin arrêter de me faire prendre pour un gonzo :D

Depuis le temps que je dis que les threads sont une c.nnerie et que le traitement asynchrone des sockets est un outil merveilleux... Quoique nécessitant (ah, mais mon brave, c'est tout le problème) une programmation correcte et réfléchie....

Mwai, pas convaincu. L'utilisation de threads est la solution la plus naturelle à ce problème. Et la non-utilisation de threads est impossible dans pas mal de cas où il est impératif d'avoir du vrai multi-user.

Je ne vois vraiment pas comment on peut imaginer faire tourner un serveur multi-tâche, multi-user sur un seul thread... Après, que tu places ton thread sur le socket ou sur les tâches elles même, je ne vois pas la différence, excepté peut-être une gestion plus compliquée (sans raison, à mon avis) au final pour les "threads par tâche".
20/01/2011, 12h35
Antoine_935

Citation:

Après, que tu places ton thread sur le socket ou sur les tâches elles même, je ne vois pas la différence

Justement, la différence c'est ce DoS.

La bonne solution à mon avis, c'est de mettre un serveur d'application « threadé » (apache, jboss) derrière un proxy asynchrone (Nginx). De cette manière, le proxy reçoit les requêtes de l'extérieur, puis les forward au serveur applicatif une fois qu'elles sont complètes.

Plus de risque de DoS (du moins pas celui là), et on a la facilité des threads.
20/01/2011, 13h25
souviron34

Citation:

Envoyé par JulienDuSud

Mwai, pas convaincu. L'utilisation de threads est la solution la plus naturelle à ce problème. Et la non-utilisation de threads est impossible dans pas mal de cas où il est impératif d'avoir du vrai multi-user.

Je ne vois vraiment pas comment on peut imaginer faire tourner un serveur multi-tâche, multi-user sur un seul thread... Après, que tu places ton thread sur le socket ou sur les tâches elles même, je ne vois pas la différence, excepté peut-être une gestion plus compliquée (sans raison, à mon avis) au final pour les "threads par tâche".

:D

C'est juste que les threads ne sont réellement apparus/utilisés que depuis le début des années 2000, parce que M$ était incapable de faire de vrais sockets asynchrones (ceux qu'ils avaient violaient la règle de séparation des couches : WSAsync nécessite(ait ?) un id de fenêtre comme paramètre).

Sur unix et linux, comme ils respectaient la règle des couches, tous les serveurs - et c'est comme ça que s'est développé le WWW - ne possèdaient pas de threads...
22/01/2011, 15h09
Invité

Citation:

Envoyé par souviron34

:D

C'est juste que les threads ne sont réellement apparus/utilisés que depuis le début des années 2000, parce que M$ était incapable de faire de vrais sockets asynchrones (ceux qu'ils avaient violaient la règle de séparation des couches : WSAsync nécessite(ait ?) un id de fenêtre comme paramètre).

Sur unix et linux, comme ils respectaient la règle des couches, tous les serveurs - et c'est comme ça que s'est développé le WWW - ne possèdaient pas de threads...

Bien qu'on ait un poil dérapé du sujet, j'ai beaucoup travaillé sur des implémentations IP sur système monothread. J'ai aussi constaté que le winsock des années 2000 crachait beaucoup avec le VBRUN de l'époque car le code fourni par msdn était basé sur un tableau et un thread uniques.
Les systèmes antérieur au réseau supposaient une lecture de données réseau "non-bloquante" précédée d'un test pour savoir s'il y a quelque chose à lire. Les thread permettent une lecture "bloquante" , le thread attend qu'une donnée soit lue pour faire sa petite cuisine. Si on veut annuler, il suffit de "tuer" le thread.

Pour revenir aux attaques dos , comme tu le soulignes , le thread de lecture étant à l'origine du traitement qui est fait des données lues, toute désynchronisation avec d'autres ressources (comme les fenêtres) a des conséquences sur le comportement de la stack IP et c'est bien là que le hiatus windows/unix était le plus grand. La stack ip est préemptive sur le déroulement du programme client alors que la culture rs232 ou vb donnait le pouvoir au client.

Cela dit, les multiples timeouts de la stack ip devraient retourner en erreur si le socket n'est pas assez réactif.
Je suppose que l'astuce consiste justement à transmettre juste en deçà de la valeur de ces timeouts. Mais le réseau a aussi ses humeurs et s'il tarde un peu à transmettre un paquet, le timeout fera son boulot.

Hélas ça ne suffit pas vraiment puisque l'attaque ddos consiste précisément à laisser le socket dans une position de connection non-achevée même si aucune donnée ne transite jusqu'à l'échéance d'un second timeout plus long (qui peut laisser le socket instable pendant des heures).

TCPIP reste un protocole très intrusif et le développeur d'un client n'y peut pas grand chose. C'est plutot l'admin d'un site qui doit ajuster ses timeouts et mettre en place des daemons capables de détecter ce cas de figure. La conception multithread est-elle vraiment à l'origine de cette vulnérabilité ? Sans doute mais une stack et un client strictement monothread sont quasiment inimaginables aujourd'hui non ?