IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les attaques par déni de service deviennent plus sophistiquées
Comme l'explique un conférencier du Black Hat

Le , par Katleen Erna
7 commentaires

5PARTAGES

0  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

7 commentaires
Commenter Signaler un problème
ratomms
Avatar de ratomms
Membre actif https://www.developpez.com
Le 20/01/2011 à 9:33
Apparemment, c'est le moyen le plus sûr pour faire une attaque.
0  0 
Antoine_935
Avatar de Antoine_935
Membre éprouvé https://www.developpez.com
Le 20/01/2011 à 11:05
Ç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.
0  0 
JulienDuSud
Avatar de JulienDuSud
Membre confirmé https://www.developpez.com
Le 20/01/2011 à 11:58
Citation Envoyé par souviron34 Voir le message


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

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".
0  0 
Antoine_935
Avatar de Antoine_935
Membre éprouvé https://www.developpez.com
Le 20/01/2011 à 12:35
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.
0  0 
Avatar de
https://www.developpez.com
Le 22/01/2011 à 15:09
Citation Envoyé par souviron34 Voir le message


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 ?
0  0 
souviron34
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 20/01/2011 à 11:18
Citation Envoyé par Antoine_935 Voir le message
Ç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.


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

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....
0  1 
souviron34
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 20/01/2011 à 13:25
Citation Envoyé par JulienDuSud Voir le message
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".


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...
0  1 
Commenter Signaler un problème