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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

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

  1. #1
    Expert éminent sénior
    Avatar de Katleen Erna
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    1 547
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 547
    Points : 75 990
    Points
    75 990
    Par défaut 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

  2. #2
    Membre actif Avatar de ratomms
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    septembre 2009
    Messages
    163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : septembre 2009
    Messages : 163
    Points : 245
    Points
    245
    Par défaut
    Apparemment, c'est le moyen le plus sûr pour faire une attaque.

  3. #3
    Membre éprouvé
    Avatar de Antoine_935
    Profil pro
    Développeur web/mobile
    Inscrit en
    juillet 2006
    Messages
    883
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur web/mobile

    Informations forums :
    Inscription : juillet 2006
    Messages : 883
    Points : 1 058
    Points
    1 058
    Par défaut
    Ç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.

  4. #4
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    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....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #5
    Membre confirmé
    Inscrit en
    août 2004
    Messages
    556
    Détails du profil
    Informations forums :
    Inscription : août 2004
    Messages : 556
    Points : 585
    Points
    585
    Par défaut
    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".

  6. #6
    Membre éprouvé
    Avatar de Antoine_935
    Profil pro
    Développeur web/mobile
    Inscrit en
    juillet 2006
    Messages
    883
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur web/mobile

    Informations forums :
    Inscription : juillet 2006
    Messages : 883
    Points : 1 058
    Points
    1 058
    Par défaut
    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.

  7. #7
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    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...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #8
    Invité
    Invité(e)
    Par défaut
    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 ?

Discussions similaires

  1. Réponses: 2
    Dernier message: 01/11/2011, 04h11
  2. Détecter une attaque par déni de service
    Par BenjaminN dans le forum Apache
    Réponses: 1
    Dernier message: 07/07/2011, 13h14
  3. Réponses: 2
    Dernier message: 08/03/2011, 13h36
  4. Réponses: 0
    Dernier message: 07/03/2011, 18h36
  5. Réponses: 2
    Dernier message: 13/11/2009, 15h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo