Journal WireShark la capture réseau

Posté par  .
Étiquettes :
14
28
jan.
2010
WireShark (anciennement Ethereal) est un outils d'analyse des trames réseau. L'application a été renommée car le développeur principal a changé de société : le nom Ethereal appartient à sa société précédente, il n'a donc pu continuer le projet sous le même nom...

Wireshark est un analyseur multi plateformes de protocoles réseaux ou « packet sniffer » classique. Son utilité principale est d'examiner les données qui transitent sur un réseau ou de chercher des données ou un fichier sur un disque. L'outil est utilisable sur plusieurs plateformes : Windows (*.exe), Linux (.deb), OS X (*.dmg).

Installation :

Sous Linux, il suffit de lancer la commande : apt-get install wireshark.
Petite astuce à l'installation : il peut arriver que lorsque l'on exécute Wireshark via l'utilisateur, celui ci ne reconnaisse pas les interfaces réseaux, car l'utilisateur n'as pas les droits d'accès. Il suffit de donner les droits à l'utilisateur ou de lancer directement Wireshark depuis root, mais c'est déconseillé...

Utilisation simple :

L'utilisation de ce type d'outils, permet de se rendre compte de la pertinence des protocoles chiffrés comme HTTPS, TLS ou SSL.
Voici une petite démonstration d'une connexion à partir d'un client Mozilla-Thunderbird vers un serveur (Protocol IMAP standard, sans chiffrement).

Après configuration du compte IMAP sur le client, on lance l'analyse réseau : voici le détail des échanges entre le client et le serveur.

Image : Par ici

On peut s'apercevoir que dans les échanges, la ligne avec l'ID 35 contient l'identifiant et le mot de passe de l'utilisateur (test-wireshark/linagora). Pas besoin de plus de commentaire...

L'analyse d'une trame hexadécimale.

Si l'on souhaite avoir des informations plus précises ou plus poussées, plus bas dans WireShark, il y a la trame correspondante en Hexadécimal :

Image : Par ici

A partir de là, il est possible de découper la trame. Grâce aux en-têtes, on peut comprendre en détail ce qui se passe. La trame en hexadécimal comprends les différentes couches : hardware, réseau, etc jusqu'à l'applicatif. En voici l'analyse détaillée.

La première en-tête est la trame Ethernet :

Image : Par ici

La première couleur correspond à l'adresse MAC de destination (si celle ci est à FF:FF:FF:FF:FF:FF c'est bien souvent une requête ARP). La seconde couleur est l'adresse MAC de l'hôte qui envoie sa requête. La couleur rose correspond au type de protocole (IPV4, IPV6, ARP, AppleTalk etc..) étant à '0800' ça sera de l'IPv4 par la suite. En fin de trame la couleur jaune (2 octets) est le CRC, le contrôle d'erreur.

Voici la trame IP :

Image : Par ici

La première couleur correspond à la version de l'IP donc 4. La longueur de l'entête est de 5 (cette valeur est toujours comprise entre 5 et 15). Ensuite nous avons 7 octets qui correspondent aux :
  • Type de service
  • Longueur totale de l'entête en octets
  • Identification du numéro de paquets, car un paquet peux être fragmenter en plusieurs trame.
  • Flags
  • Fragment Offset
Pour avoir plus d'informations sur les cinq points précédents je vous invite à lire la page Wikipédia.

En couleur grise, c'est le TTL, suivi par le numéro de protocole, étant à '06', le protocole suivant sera du TCP. Ensuite sur 2 octets nous avons une somme de contrôle. Enfin nous arrivons sur les 8 derniers octets de la partie IP qui correspondent aux adresses IP source et destination. '0A 4B 81 29' si on transforme l'hexadécimal en base décimale, on retrouve notre adresse IP source (10.75.129.41), pareil pour l'adresse de destination.

Comme trouvé dans la partie IP, le protocole suivant est le TCP, voici la découpe :

Image : Par ici

Cette partie est en 9 morceaux distincts. Voici à quoi ils correspondent respectivement :
  • Port source : 'a691'
  • Port destination : '008f'
Si on convertit ces 4 octets on retrouve ces valeurs : '42 641' et '143'. Le lecteur éclairé aura reconnu ici que le port de destination correspond à celui utilisé pour le protocole IMAP, dans sa version non sécurisée. Si on regarde les échanges réseau de la première image, on retrouve bien ces valeurs.

Ensuite, il y a :
  • Numéro de séquence
  • Numéro d'acquittement
  • Taille de l'entête : codé sur 4 octets, la valeur '8' indique que l'entête TCP est composée de 4 mots de 32 bits.
  • Le champs réservé aux drapeaux (flags), de valeur '0 18'
  • Le champs "fenêtre", permettant de connaître le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception
  • Somme de contrôle (CRC) : 56 73
  • Les champs d'options et de remplissage.
Les niveaux supérieurs concernent directement l'application. L'analyse d'une telle trame peut être utile lors d'analyse de problème applicatif ou de problème réseau, afin de savoir ce qu'il se passe concernant le transport des paquets. Ces analyses servent également à procéder à la rétro-ingénierie des protocoles propriétaires. C'est à travers cette méthode que Rob Savoye et ses collègues développent le logiciel Gnash, par exemple.

Ce journal reste une simple présentation des de Wireshark, et de montrer l'importance des protocoles chiffrées.
  • # (HS) Du choix des outils

    Posté par  (site web personnel) . Évalué à 10.

    Arghhh les captures d'écran en JPEG!

    Quand on fait des capture d'écran de GUI affichant du texte, on les met en PNG, ça bouffe peu de place (car pas une photo), et c'est lossless : on évite le fourmillement horrible qu'il y a sur les captures fournies, c'est pas très lisible la...
  • # Licence, paquets

    Posté par  . Évalué à 0.

    Quelle est la licence?

    Et pourquoi pas un paquet tar.gz compilé pour ceux qui ne sont pas sous debian?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Licence, paquets

      Posté par  (site web personnel) . Évalué à 10.

      Euh, si wireshark n'est pas dans ta distribution ... change de distribution !
    • [^] # Re: Licence, paquets

      Posté par  (site web personnel) . Évalué à 2.

      Pour ce qui est de la licence, c'est du GPL.

      Pour les paquets, le site officiel te propose les sources, comme à peu près tous les projets libres. Et propose des binnaires aux utilisateurs de windows et de Mac car leurs utilisateurs sont tout perdus quand ils voient les sources.

      Donc sous Linux, cest à ta distribution de faire les paquets, ce que fait notament Debian, mais aussi la grosse majorité des distribution. Donc te fais pas trop de soucis, si tu lance «commande_qui_vas_bien wireshark» tu as de bonnes chance que ça marche chez toi aussi.

      Et pour ceux que cela intéresse, il y a une fonction très pratique dans wireshark : les interpreteurs de protocol. Ils permettent pour les protocoles classiques d'affiche le conteus des trames sous forme bien plus lisible que le dumbp hexa.
      • [^] # Re: Licence, paquets

        Posté par  . Évalué à 3.

        A ce propos, sous Fedora, il faut installer wireshark-gnome sinon, l'interface graphique n'est pas installée:
        $ yum install wireshark-gnome
      • [^] # Re: Licence, paquets

        Posté par  . Évalué à 2.

        Donc sous Linux, cest à ta distribution de faire les paquets, ce que fait notament Debian, mais aussi la grosse majorité des distribution. Donc te fais pas trop de soucis, si tu lance «commande_qui_vas_bien wireshark» tu as de bonnes chance que ça marche chez toi aussi.
        Tu veux dire que les distributions linux proposent des binaires car leurs utilisateurs sont perdus quand ils voient les sources?

        Il y a un interpreteur pour SIP, que je recommande quand au boulot vous utilisez du SIP :)

        Depending on the time of day, the French go either way.

  • # HTTPS

    Posté par  . Évalué à 4.

    l'https pour ne pas envoyer le login/mdp en clair c'est bien.... mais si c'est pour envoyer les cookies d'authentification en clair à chaque requête par la suite, c'est bof. La page sécurisée de login Facebook fait bien rire.

    http://tuxicoman.jesuislibre.net/2010/01/vous-prendrez-bien-(...)
    • [^] # Re: HTTPS

      Posté par  . Évalué à 2.

      Sur facebook avant il y avait une page de login en https et ça passait ensuite en http.
      Mais maintenant c'est en https après la connexion également, donc y'a plus de problème!
    • [^] # Re: HTTPS

      Posté par  (site web personnel) . Évalué à 1.

      Ca répond tout de même à une problématique. Celui qui intercepte le HTTP n'a plus qu'un token a durée de vie limitée et qui normalement ne permet pas de toucher aux informations importantes (dans les sites qui sont bien faits) comme changer le mot de passe ou l'email de contact.

      Certes ça permet encore à bob qui intercepte ton réseau d'utiliser ton compte, mais une fois que tu cliques sur "se déconnecter" ça lui coupe l'accès et tu peux défaire ou palier ce qu'il a fait comme bêtises.

      C'est moins gênant que si on divulgue ton mot de passe avec lequel on peut tout faire (et malheureusement souvent aller taper sur d'autres services avec ton compte parce que les gens utilisent le même mot de passe).
      • [^] # Re: HTTPS

        Posté par  (site web personnel) . Évalué à 5.

        Certes ça permet encore à bob qui intercepte ton réseau d'utiliser ton compte

        Euh... je trouve ça TRÈS gênant. Imagine le scénario cauchemardesque : un attaquant vole mon compte linuxfr et écrit un commentaire calomnieux en ton nom !

        mais une fois que tu cliques sur "se déconnecter" ça lui coupe l'accès

        Je sais pas toi, mais moi mis à part sur le site de ma banque je ne le fais pas. La plupart du temps, je me débrouille plutôt que le cookie ait la durée de vie la plus longue car ça me saoule de me réauthentifier.

        C'est moins gênant que si on divulgue ton mot de passe avec lequel on peut tout faire

        Euh, le mot de passe n'est pas très utile. Au mieux il permet de voler le compte un peu plus longtemps, mais le cookie est déjà très largement suffisant pour faire énormément de choses.

        et malheureusement souvent aller taper sur d'autres services avec ton compte parce que les gens utilisent le même mot de passe

        Tiens, récemment j'ai changé tous mes mots de passe justement pour ne plus utiliser le même partout. Pour justement éviter le problème de la fuite d'un mot de passe.
        • [^] # Re: HTTPS

          Posté par  . Évalué à 2.



          Certes ça permet encore à bob qui intercepte ton réseau d'utiliser ton compte

          Euh... je trouve ça TRÈS gênant. Imagine le scénario cauchemardesque : un attaquant vole mon compte linuxfr et écrit un commentaire calomnieux en ton nom !


          Au contraire, c'est génial!
          Je me suis toujours dit qu'un jour je pourrais utiliser ça comme excuse après un commentaire trop foireux.

          Et puis comment ferait Jean-Paul Ney si on ne pouvait plus usurper les identités sur internet?
  • # sympa mais...

    Posté par  . Évalué à 5.

    Salut,

    Merci pour le tutoriel sur l'utilisation de Wireshark, c'est sympa. Mis à part le petit enfonçage de porte ouverte ouah l'imap sai pas secure ;) à propos d'un protocole de plus de 15 ans, même si ton commentaire est pertinent, ça ne surprendra personne.

    Ensuite, tu dis
    Ce journal reste une simple présentation des de Wireshark, et de montrer l'importance des protocoles chiffrées.

    Tu prêches des convaincus, d'ailleurs tout dlfpien qui se respecte surfe en HTTPS sur linuxfr.org

    De plus je m'interroge sur l'essence même de ce journal. Le lectorat de linuxfr dispose d'une pilosité faciale que l'on pourrait qualifier de fichtrement barbue, et en fait il est assez rompu à l'utilisation de wireshark, ou plutôt de tcpdump (qui lui n'est pas pour les nOObs des clickodromes)

    Alors pourquoi poster ce tutorial ici alors que des sites plus orientés "pédagogie" comme wikibooks me semblent plus adaptés ?

    De là à dire que c'était une occasion de poster des liens vers le site d'une entreprise qui déplace ses blogs de son site vers linuxfr pour augmenter son audimat, il n'y a qu'un pas que je ne franchirai pas.
    • [^] # Re: sympa mais...

      Posté par  . Évalué à 7.

      C'est une façon de le voir.

      En fait, les gens de Linagora publient avant tout sur internet pour eux, afin de ne pas perdre la connaissance qu'ils ont acquises. On retrouve toujours quelque chose qui est sur internet, on perd de temps en temps ce qui est sur un disque dur.

      La raison pour laquelle certains de ces articles sont LinuxFr est parce que nous avons, à Linagora, un esprit de partage. Au lieu que ce soit que les xxx personnes de Linagora, les lecteurs de LinuxFr peuvent aussi en profiter. Ce sont des articles techniques sur des solutions techniques, qui ne sont pas développés par Linagora. Ils ne sont pas écris par des commerciaux et n'ont pas vocation à décrire les offres de cette société.

      Tant mieux pour toi si tu sais déjà toutes ces choses et si tu connais déjà un meilleur outil que celui là. Mais vu les autres commentaires, il est clair que tout le monde n'a pas ton niveau ou ton approche sur le sujet. Ça permet également d'en discuter à travers les commentaires.

      Je suis personnellement content que l'un de mes collègues ait pu augmenter le contenu et la qualité d'un site communautaire comme linuxFr. Ça fait quand même quelques années qu'on en profite avec très peu d'articles à notre actif, je suis content que ça puisse désormais changer.

      Mais si tu crois que Linagora est une société d'édition ou un site de presse, libre à toi.
    • [^] # Re: sympa mais...

      Posté par  (site web personnel) . Évalué à 8.

      Le lectorat de linuxfr dispose d'une pilosité faciale que l'on pourrait qualifier de fichtrement barbue, et en fait il est assez rompu à l'utilisation de wireshark, ou plutôt de tcpdump (qui lui n'est pas pour les nOObs des clickodromes)

      Pas forcement.
      On peut être sous LinuxFr juste parce qu'on a installé Linux, avec un KDE qui va bien, et ne rien connaitre dans l'analyse de protocole.
      Ce que tu dis, ça revient à ne jamais présenter de produit, juste parler de la dernière version, car "tout le monde connait".

      Par exemple, dans le dernier journal de SoGo, un commentaire a justement été "il n'y a pas de présentation générale, tout le monde ne connait pas SoGo", et je pourrai réagir comme toi "pfff... Mais si, tout viviteur de LinuxFr est barbu et connait SoGo".
      Tu penses peut-être que SoGo mérite une présentation car pas connu. C'est exactement ce que pensent d'autres sur Wireshark.

      En fait, tout produit mérite présentation, car tout le monde ne connait pas tous les produits, et sûrement pas un analyseur de protocole qui est un domaine assez particulier.
    • [^] # Re: sympa mais...

      Posté par  . Évalué à 4.

      Le lectorat de linuxfr dispose d'une pilosité faciale que l'on pourrait qualifier de fichtrement barbue

      Tu veux dire qu'il y a des femmes à barbe parmi nous ?
  • # sécurité...

    Posté par  (Mastodon) . Évalué à 3.

    Est-ce que les problèmes mentionnés ci-bas ont été résolus (séparation de privilèges, correction des failles) ?


    OpenBSD CVS log for ports/net/ethereal/Attic/distinfo:

    Revision 1.20
    Wed Jul 14 21:52:25 2004 UTC (5 years, 6 months ago) by pvalchev
    Branches: MAIN
    CVS tags: HEAD
    FILE REMOVED
    Changes since revision 1.19: +0 -0 lines

    Remove ethereal from the ports tree. Right during 3.5, it had more than
    a dozen remote holes being fixed, that we shipped with. Weeks later
    things have not improved, and there continue to be problems reported
    to bugtraq, and respective band-aids - but it is clear the ethereal
    team does not care about security, as new protocols get added, and
    nothing gets done about the many more holes that exist.

    Maybe someone will at least privilege separate this one day, and then
    the OpenBSD stance with respect to this may change.

    Encouraging people to run broken software by distributing packages
    with known security holes is not desired by any of us.
    • [^] # Re: sécurité...

      Posté par  . Évalué à 2.

      Ethereal est connu pour être une passoire, notamment au niveau des dissectors...
      Aux dernières nouvelle, la séparation des privilèges n'est pas implémentée.
      • [^] # Re: sécurité...

        Posté par  . Évalué à 1.

        La dernière version sortie aujourd'hui indique:
        A vulnerability in the LWRES dissector has been fixed.
        Ca avance, doucement certe, mais ça avance.
        • [^] # Re: sécurité...

          Posté par  . Évalué à 2.

          Les logiciels de capture sont très utiles, mais ont deux gros inconvénients qui en font un cauchemar pour la sécurité :
          - ils tournent en root (il faut voir si on peut éviter cela avec des capabilities)
          - ils parsent des données potentiellement très dangereuse, puisque circulant sur le réseau, ou internet
          Je ne sais pas comment ils font, mais je pense que pour ce type d'application, des tests automatiques pourraient être utiles.
          On fait tourner un ethereal, et on balance des trames formattées au hasard, ou selon un pattern. Je pense que ça permettrait déjà de détecter pas mal de problème, couplé à valgrind.
          • [^] # Re: sécurité...

            Posté par  . Évalué à 3.

            C'est astucieux comme technique pour contrer l'espionnage: faire transiter des frames qui plantent ou prennent le contrôle des sniffeurs réseau. L'arroseur arrosé :)

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: sécurité...

            Posté par  (site web personnel) . Évalué à 2.

            Pour le fuzzing, c'est déjà conseillé lorsqu'on développe un dissector :
            http://wiki.wireshark.org/FuzzTesting

            Je ne suis pas très activement le développement de wireshark, mais à chaque fois il y a de grosses améliorations pour le développeur. C'est un logiciel très actif.
          • [^] # Re: sécurité...

            Posté par  (site web personnel) . Évalué à 3.

            Les logiciels de capture sont très utiles, mais ont deux gros inconvénients qui en font un cauchemar pour la sécurité :
            - ils tournent en root (il faut voir si on peut éviter cela avec des capabilities)
            - ils parsent des données potentiellement très dangereuse, puisque circulant sur le réseau, ou internet


            On peut séparer les deux : tcpdump pour sniffer le trafic (tourne en root) et wireshark pour parser les paquets (tourne sous un utilisateur non privilégié, voir dans un bac à sable).

            Par contre, je ne sais pas si on peut utiliser tcpdump + wireshark pour voir le trafic en temps réel (j'en doute). Du coup, j'utilise wireshark en root chez moi pour les tests (dans mon LAN j'estime quand même que le risque est très faible).
            • [^] # Re: sécurité...

              Posté par  . Évalué à 2.

              > On peut séparer les deux : tcpdump pour sniffer le trafic (tourne en root) et wireshark pour parser les paquets (tourne sous un utilisateur non privilégié, voir dans un bac à sable).

              Selon les besoins, on peux se passer complètement de wireshark pour la dissection des paquets, et utiliser des outils comme tcpflows, tcpextract et foremost (en ligne de commande, donc scriptables, etc). Par exemple on peux extraire des dumps pcap "bruts" les fichiers transférés sur le réseau sans problème.

              ngrep couvre aussi (en cli) certains cas d'utilisation de wireshark.
            • [^] # Re: sécurité...

              Posté par  (site web personnel) . Évalué à 1.

              En même temps ... tu peux utiliser tshark plutôt que tcpdump ;)
    • [^] # Re: sécurité...

      Posté par  (Mastodon) . Évalué à 3.

      on peut utiliser wireshark en séparant les privilèges capture et analyse: il suffit de capturer en root avec tshark ou tcpdump, de piper dns une fifo et de lancer wireshark en user en écoute sur cette même fifo. Après dire qu'ils ne font rien pour la sécu, c'est abuser, chaque maj bouche des trous...
      • [^] # Re: sécurité...

        Posté par  . Évalué à 2.

        Passer par un pipe à construire soi-même en dehors de wireshark, on perd un peu l'intégration du GUI qui a en gros un bouton capture et un bouton stop. Ce qu'il faudrait, c'est que le GUI se fasse lui même son pipe avec gksu/kdesu/etc.
  • # Linux 3.0 ?

    Posté par  . Évalué à 7.

    "Sous Linux, il suffit de lancer la commande : apt-get install wireshark."

    Rien à dire, ça marche bien chez moi. Pourtant, y'a comme un truc qui me pique les yeux dans cette phrase...
    • [^] # Re: Linux 3.0 ?

      Posté par  . Évalué à -1.

      Oui en effet,
      Cela fonctionne sur Debian, Ubuntu...
      • [^] # Re: Linux 3.0 ?

        Posté par  (site web personnel) . Évalué à 2.

        Lors de la traduction initiale du make install en dialectes locaux, chez les Mandriviens ça a été traduit en urpmi wireshark

        D'ailleurs
        [pointal@mamachine ~]$ urpmq -i wireshark
        Name : wireshark
        Version : 1.2.3
        Release : 1mdv2010.0
        Group : Monitoring
        Size : 8893702 Architecture: i586
        Source RPM : wireshark-1.2.3-1mdv2010.0.src.rpm
        URL : http://www.wireshark.org
        Summary : Network traffic analyzer
        Description :
        Wireshark is a network traffic analyzer for Unix-ish operating systems. It is
        based on GTK+, a graphical user interface library, and libpcap, a packet
        capture and filtering library.

        Wireshark is a fork of Ethereal(tm)

        Name : wireshark
        Version : 1.2.5
        Release : 0.1mdv2010.0
        Group : Monitoring
        Size : 8904333 Architecture: i586
        Source RPM : wireshark-1.2.5-0.1mdv2010.0.src.rpm
        URL : http://www.wireshark.org
        Summary : Network traffic analyzer
        Description :
        Wireshark is a network traffic analyzer for Unix-ish operating systems. It is
        based on GTK+, a graphical user interface library, and libpcap, a packet
        capture and filtering library.

        Wireshark is a fork of Ethereal(tm)



        Last updated : Tue Jan 19 18:47:42 2010
        Update importance : security
        Reason for update :
        This advisory updates wireshark to the latest 1.2.5 version, fixing
        several bugs and two security issues:
        - The (1) SMB and (2) SMB2 dissectors in Wireshark 0.9.0 through
        1.2.4 allow remote attackers to cause a denial of service (crash)
        via a crafted packet (CVE-2009-4377)
        - Buffer overflow in the daintree_sna_read function in the Daintree SNA
        file parser in Wireshark 1.2.0 through 1.2.4 allows remote attackers
        to cause a denial of service (crash) and possibly execute arbitrary
        code via a crafted packet (CVE-2009-4376)


        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Linux 3.0 ?

      Posté par  . Évalué à 5.

      aptitude. Pas apt-get.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Moi

    Posté par  . Évalué à 6.

    Là, tu peux voir tous tes identifiants qui passent en clair de ton ordinateur au site web en passant par la passerelle de là où t'es. En soit, c'est pas dérengeant, le problème c'est qu'il faut être sûr que personne ne lit ce qui transite par ce chemin.

    Le mieux pour bien montrer tout ça, c'est d'utiliser Ettercap en plus de Wireshark, tu fais une attaque MITM sur un ordinateur tierce, et tous ses paquets transitent par toi avant d'aller à la passerelle. (je ferais un tuto si ca en intéresse mais c'est pas bien dur) Après, on utilise dsniff sur l'interface réseau ou sur les fichiers de Wireshark pour extraire tous les mot de passes et, TADA.
    Par exemple, en cité U du crous, avec un réseau wifi ouvert, on peut obtenir pleins d'accès au proxy.
    Personnellement, chez moi, c'est le seul accès à internet utilisable, et les sites qui utilisent https comme linuxfr, yen a pas tant que ça. Ici, le problème est encore plus grand puisque c'est du wifi, un coup de airodump-ng et de dsniff et on peut savoir quels sont vos mots de passe pour quels sites, ou au moins, quels sites vous avez visité.
    Du coup, quelles solutions pour se protéger ? Moi, j'ai installé un serveur SSH chez mes parents.

    ssh -D5555 -p 443 moi@chezmoi

    Et hop, un serveur SOCKS ! Où que je sois dans le monde, il me suffit d'un accès au web pourri pour accéder à internet ! Bon, bien sûr, le HTTP entre mon PC chez mes parents et le site web n'est pas chiffré, mais au moins, je me fiche de ce qui peut se passer sur le réseau sur lequel je suis (logs, MITMs, wifi non sécurisé).
    En plus, ya tsocks, pour que les applications qui ne supportent pas les proxy SOCKS marchent avec un proxy SOCKS quand même.
    Truc dommage, konqueror (et KDE) qui supporte nativement le proxy HTTP mais pas le proxy SOCKS, même avec tsocks ça ne marche pas ! Ah, j'oubliais, pour configurer le serveur SOCKS, par exemple firefox, dites que le serveur c'est localhost, et le port, celui qui se trouve après le -D (5555).
    Pour avoir accès au SSH à travers le proxy HTTP, il faut utiliser corkscrew.
    En plus, truc que je n'arrive pas à expliquer de manière certaine, le soir, quand tout le monde accède à internet en même temps, une page met au moins 20s à s'afficher, c'est très pénible, là où, en passant par le serveur SOCKS (avec l'option -C de ssh, ou sans, c'est pareil), la même page met moins d'une seconde à s'afficher.
    • [^] # Re: Moi

      Posté par  (site web personnel) . Évalué à 2.

      En plus, truc que je n'arrive pas à expliquer de manière certaine, le soir, quand tout le monde accède à internet en même temps, une page met au moins 20s à s'afficher, c'est très pénible, là où, en passant par le serveur SOCKS (avec l'option -C de ssh, ou sans, c'est pareil), la même page met moins d'une seconde à s'afficher.

      Peut-être des flux HTTP considérés comme moins prioritaires a niveau de la politique de qualité de service du réseau de la cité U...

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Moi

      Posté par  (Mastodon) . Évalué à 2.

      Le proxy doit ramer à bidouiller les pages web – il n'y aurait pas du contrôle « parental » ou antivirus ? – du coup, toi qui utilise la méthode de proxy CONNECT vers un port 443, le proxy ne fait que passe-plat, ne voit rien à l'intérieur du flux et ne perd pas de temps à traiter des choses en CPU…
  • # Indispensable

    Posté par  . Évalué à 4.

    L'actualité nous montre à quel point ce genre d'outil peut s'avérer utile.

    http://www.numerama.com/magazine/14948-la-google-toolbar-sus(...)

    Bon ok, ca ne concerne que les windowsiens.
  • # Alternatives ?

    Posté par  . Évalué à 1.

    Wireshark est un outil vraiment pratique, qui m'a bien aidé quand je codais des trucs liés au réseau (pour les paquets SIP, par exemple). Par contre, j'ai un peu de mal avec certains aspects de l'interface et je n'ai pas le temps (lire « l'envie ») de développer un patch. Parmi les choses qui me gênent : la configuration des filtres de capture est différente de celle des filtres d'affichage. Je crois que c'est parce que la capture se fait avec une bibliothèque tierce (pcap) alors que le décodage est fait par Wireshark lui-même. Bref, il y a des choses qui ne me conviennent pas, même si je peux faire avec. Je me demandais si les gens qui traînent ici ont des retours à partager sur des programmes similaires à Wireshark.

    Tcpdump est pratique parce qu'on le trouve de partout. Mais je trouve qu'il lui manque ce côté « on capture tout et on se posera des questions après » de Wireshark. Par ailleurs je ne crois pas que l'on puisse faire des anayses très fines avec cet outil, du genre récupérer le SDP d'un paquet SIP sur un port non standard.

    En clone (propriétaire) de tcpdump, il y a NI_Dump [1], qui sert de vitrine technologique à la société Qosmos. Ce qui est intéressant dans ce programme, c'est qu'il fait une analyse poussée des paquets, et les résultats devraient donc être plus précis (il ne serait pas trompé par du NFS sur le port 80).

    [1] http://labs.qosmos.com/?p=3
    • [^] # Re: Alternatives ?

      Posté par  (site web personnel) . Évalué à 2.

      J'aime bien aussi, je m'en suis servi pour debugger un peu des services XMLRPC .

      C'est aussi pratique pour savoir si il y a du monde qui "téléphone à la maison".

      Par contre, pour une utilisation rapide, impossible pour moi de comprendre quoi que ce soit aux filtres et surlignement. Je m'en suis sorti sans mais ça a pas l'air trivial.
  • # Attaque Man In The Middle.

    Posté par  . Évalué à 2.

    On m'a envoyé un MP pour me demander un tutorial, quelqu'un voudrait convaincre son patron d'utiliser HTTPS.

    L'attaque se déroulera en trois temps :
    1- on trouve la cible sur le réseau
    2- on lance l'attaque MITM
    3- on regarde les paquets qui transitent et on choppe les mots de passe.

    1°) Ici, il faut deux choses, trouver l'adresse IP de la victime, Alice, et l'adresse IP de la passerelle. C'est donc entre ces deux entités que passent le contenu auquel on veut avoir accès.
    Pour ça, on peut utiliser nmap, zenmap ou autoscan par exemple. (zenmap et autoscan ne sont que des front-end à nmap) Pour trouver le bon ordinateur, le bon indicateur, c'est le nom de la machine. Pour nmap, faites simplement (en modifiant la plage IP pour s'adapter au réseau où vous êtes) :
    # nmap -A 192.168.1.1-255

    2°) On a l'IP d'Alice, celle de la passerelle, il faut donc maintenant créer un contexte MITM.
    Pour ça, plusieurs solutions, la plus efficace : l'ARP poisoning (même si dans ce cas, utiliser l'attaque ICMP de ettercap peut être plus efficace, je vous conseille de lire le man qui est très instructif). En gros, on ouvre ettercap, on commence le sniffing (unified). Ensuite on fait un scan des hosts, on selectionne l'IP de Alice, on la met en target1 et l'IP de la passerelle qu'on met en target 2 (ou l'inverse, peu importe).
    Ensuite, menu MITM, on lance une attaque arp poisonning, on attend un peu et nous voila en contexte MITM. (on peut vérifier que l'arp poisonning fonctionne avec un plugin, manage plugin > et on double clique sur chk_poison.)
    Nous voila dans un contexte MITM, qu'est ce que ca veut dire ? Que toutes les communications entre Alice et la passerelle passeront par votre ordinateur (Alice croit que votre adresse mac est la passerelle, donc tous ses messages vous arrive à vous, vous les envoyez ensuite à la passerelle et vice versa).

    3°) À partir de là, il vous suffit de lancer wireshark et vous verrez tous ces paquets. Mais c'est moins pratique.
    On va donc utiliser dsniff. Ce petit logiciel regarde ce qu'il se passe sur votre interface réseau, comme wireshark, mais tout ce qu'il vous donnera, c'est ce qui nous intéresse : les mots de passe. Ça doit s'utiliser comme ça :
    dsniff -i eth0
    On attend, dès que un mot de passe arrive sur l'interface, il sera affiché, et voila. (ça marche avec des tas de protocoles)

    Si vous n'avez pas compris grand chose, il y a des tas de tutos pour faire tout ça, pour ettercap :
    http://openmaniak.com/fr/ettercap.php
    pour dsniff, la page sur le wiki de backtrack :
    http://wiki.backtrack-fr.net/index.php/Dsniff

    Ah, par contre, une attaque arp ca peut augmenter la latence de la cible, et diminuer sa BP. Et ça se détecte en regardant son cache ARP si on connait déja l'adresse mac de la passerelle. Ce qui a peu de chances d'arriver chez beaucoup de personnes lambda.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.