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
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'
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.
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 Zenitram (site web personnel) . Évalué à 10.
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...
[^] # Re: (HS) Du choix des outils
Posté par Axel R. (site web personnel) . Évalué à 9.
# Licence, paquets
Posté par claudex . Évalué à 0.
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 GnunuX (site web personnel) . Évalué à 10.
[^] # Re: Licence, paquets
Posté par beagf (site web personnel) . Évalué à 2.
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 Frédéric COIFFIER . Évalué à 3.
$ yum install wireshark-gnome[^] # Re: Licence, paquets
Posté par Frank-N-Furter . Évalué à 2.
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 eon2004 . Évalué à 4.
http://tuxicoman.jesuislibre.net/2010/01/vous-prendrez-bien-(...)
[^] # Re: HTTPS
Posté par Damien Thébault . Évalué à 2.
Mais maintenant c'est en https après la connexion également, donc y'a plus de problème!
[^] # Re: HTTPS
Posté par Éric (site web personnel) . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 5.
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 Maclag . É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 Axel . Évalué à 5.
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 Coren . Évalué à 7.
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 Zenitram (site web personnel) . Évalué à 8.
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 jeffcom . Évalué à 4.
Tu veux dire qu'il y a des femmes à barbe parmi nous ?
# sécurité...
Posté par Psychofox (Mastodon) . Évalué à 3.
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 neologix . Évalué à 2.
Aux dernières nouvelle, la séparation des privilèges n'est pas implémentée.
[^] # Re: sécurité...
Posté par _seb_ . Évalué à 1.
A vulnerability in the LWRES dissector has been fixed.
Ca avance, doucement certe, mais ça avance.
[^] # Re: sécurité...
Posté par neologix . Évalué à 2.
- 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 Grunt . Évalué à 3.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: sécurité...
Posté par Leroy Frederic (site web personnel) . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 3.
- 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 herodiade . Évalué à 2.
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 GnunuX (site web personnel) . Évalué à 1.
[^] # Re: sécurité...
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
[^] # Re: sécurité...
Posté par Octabrain . Évalué à 2.
[^] # Re: sécurité...
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
En même temps, un petit :
sudo tshark -i eth1 -w - | wireshark -k -i -n'est pas si violent que ça si on tient à sa sécurité. on peut même faire des trucs plus marrants : http://www.commandlinefu.com/commands/tagged/1042/wireshark# Linux 3.0 ?
Posté par moi1392 . Évalué à 7.
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 Jimmy Goffaux . Évalué à -1.
Cela fonctionne sur Debian, Ubuntu...
[^] # Re: Linux 3.0 ?
Posté par lolop (site web personnel) . Évalué à 2.
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)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Linux 3.0 ?
Posté par Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Moi
Posté par Sébastien B. . Évalué à 6.
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 lolop (site web personnel) . Évalué à 2.
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...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Moi
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
# Indispensable
Posté par nomorepost . Évalué à 4.
http://www.numerama.com/magazine/14948-la-google-toolbar-sus(...)
Bon ok, ca ne concerne que les windowsiens.
# Alternatives ?
Posté par nigaiden . Évalué à 1.
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 Philippe F (site web personnel) . Évalué à 2.
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 Sébastien B. . Évalué à 2.
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-2552°) 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 eth0On 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.