Aller au contenu

Dsniff la CC


MetreM

Messages recommandés

Bonjour,

Voila cela fait pres d'une semaine que je suis bloqué, Je n'arrive pas a faire sniffer quoi que ce soit a dsniff !!!

Precision:

-J'utilise dsniff exclusivement pour mon reseau personnel

-J'utilise debian 4.0 (stable)

-J'utilise dsniff 2.4b1

Mise en situation:

1PC debian qu'on appelera debian1

1PC windows qu'on appelera windobe xD

Je me connecte en ssh sur debian1 avec windobe grace a putty

Je me log en root

Je fait :

#apt-get install dsniff >> tout s'install correctement

#dsniff -i eth0 port 23

Je me connecte ensuite en telnet sur debian1 sans me deconnecter de ma session SSH

Et la normalement je devrai voire les paquets sniffer sur ma console en SSH mais RIEN !!!

Bref je me dis que c'est mon reseau qui deconne

Alors j'install tcpdump qui a ma grande surprise voit les paquets nikel des que je me connect en telnet !!!

Alors voila j'ai chercher et encore chercher sur mon amis google qui me donne pas beaucoup de reponses pour une fois :-(

J'ai eu quand meme quelques indices que voici :

http://forum.backtrack-fr.net/viewtopic.php?id=777

http://www.groar.org/trad/dsniff/dsniff-faq/faq.html

Je suis en train de me demander si Berkeley DB est bien installé meme si sur le log d'install il est bien afficher comme installé

Cette personne a le meme probleme et je lui est donc envoyé un mail pour savoir si finalement il a trouvé une solution. (sans reponse)

http://www.nabble.com/dsniff-marche-pas-al...-td7636517.html

Voili voilou Je compte sur vous ^^

Lien vers le commentaire
Partager sur d’autres sites

Merci pour vos reponses plus que rapide

Pour les numero de port je suis au courant (-; (Je scan d'abord les paquets correspondant au port 23 >> (telnet) ,puis je me connect en telnet pour qu'il puisse voir une trace de la connction mais le probleme c'est que je ne voit rien)

Pouquoi pas ethernal >> Car dsniff est plus puissant grace a arpspoof xD et qu'il decode beaucoup plus de protocol (le telnet c'est juste pour du test)

Un bug du logiciel >> Je ne pense pas car d'autre utilisateurs arrive a le faire fonctionner sur debian 4.0 avec la version dsniff que j'ai

D'autres idées?

Lien vers le commentaire
Partager sur d’autres sites

Merci pour vos reponses plus que rapide

Pour les numero de port je suis au courant (-; (Je scan d'abord les paquets correspondant au port 23 >> (telnet) ,puis je me connect en telnet pour qu'il puisse voir une trace de la connction mais le probleme c'est que je ne voit rien)

Pouquoi pas ethernal >> Car dsniff est plus puissant grace a arpspoof xD et qu'il decode beaucoup plus de protocol (le telnet c'est juste pour du test)

Un bug du logiciel >> Je ne pense pas car d'autre utilisateurs arrive a le faire fonctionner sur debian 4.0 avec la version dsniff que j'ai

D'autres idées?

[root@Osiris ~]# dsniff -i eth0 port 23
dsniff: listening on eth0 [port 23]
^C[root@Osiris ~]# tcpdump -i eth0 port 23
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:17:16.923106 IP 192.168.2.208.49588 > Osiris.telnet: S 1070683178:1070683178(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
21:17:19.912827 IP 192.168.2.208.49588 > Osiris.telnet: S 1070683178:1070683178(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

ça a pas l'air si top que ça dsniff...

Lien vers le commentaire
Partager sur d’autres sites

Lol bon alors c'est peu etre un bug ^^

Ca fait plaisir de se sentir moins seul

Si quelqun sait quand meme faire fonctionner dsniff ca m'interesse car apparament Il n'y a que lui pour faire tout ca:

dsniff est un renifleur de mots de passe qui supporte les

protocoles FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP,

IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS,

YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, Post­

greSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere,

NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase et

Microsoft SQL.

Lien vers le commentaire
Partager sur d’autres sites

J'ai eu eu reponse du bugreport

> From: luciano _at_ debian org

> To: metrem _at_ hotmail fr

> Subject: Re: Why i don't see packets

> Date: Thu, 21 Aug 2008 18:26:32 -0300

>

> El Jue 21 Ago 2008, Romain DAVID escribió:

> > Why i don't see packets

>

> SYN/ACK missing.

>

> luciano

Il me dit que les paquet SYN ACK manque

Tcp_normal.png

Mais c'est impossible puissque j'ecoute avant meme que je me connecte

Un idée?

Lien vers le commentaire
Partager sur d’autres sites

c'est pas le probleme...

si j'ai bien compris, dsniff ne gere pas les packets syn/ack or, lorsque tu te telnet, tu ne fais qu'envoyer syn, puis renvoyer ack. Si tu veux voire du trafic, tu doit faire passer quelque chose.

Merci pour ta reponse

Si j'ai compris ce que tu dis tu me dis que j'absorbe tout les paquets et que je ne les renvoi pas mais pourtant dans ma consol telnet je voit bien ce que j'ecrit et j'arrive a me connecter et faire des cmmandes

Tu peux m'expliquer plus detail s'il te plais

Lien vers le commentaire
Partager sur d’autres sites

c'est pas le probleme...

si j'ai bien compris, dsniff ne gere pas les packets syn/ack or, lorsque tu te telnet, tu ne fais qu'envoyer syn, puis renvoyer ack. Si tu veux voire du trafic, tu doit faire passer quelque chose.

Merci pour ta reponse

Si j'ai compris ce que tu dis tu me dis que j'absorbe tout les paquets et que je ne les renvoi pas mais pourtant dans ma consol telnet je voit bien ce que j'ecrit et j'arrive a me connecter et faire des cmmandes

Tu peux m'expliquer plus detail s'il te plais

ce que j'essais de dire (j'étais pas forcément très concentré), c'est que simplement initialiser une connexion avec telnet ne suffit pas a voire apparaître des packets sur dsniff. Je ne me suis jamais penché sur le fonctionnement de telnet, mais je présume qu'il ne fait qu'initialiser une connexion, à savoir, envoyer syn, attendre synack, renvoyer ack. syn/ack n'étant pas supporté par dsniff, il est normal que tu ne puisse pas les voire dans le log associé.

si tu veux faire le test, utilise telnet pour simuler le fonctionnement d'une connexion, ou n'utilise pas telnet, et log le traffique d'autre port (que tu aura préalablement ouvert, et sur lequel tu fera passer tes datas).

edit (pour tester en simulant une connexion):

autrefois, il me semblait que je faisais:

toto@server ~> netcat -l -e /bin/tcsh -p 1664

/**/

toto@client ~> telnet server 1664

et avec ca, je m'ouvrais un shell a distance. C'est le genre de traffic que tu pourrais logguer.

sauf que, en testant avec ces commandes, j'arrive plus à le faire marcher... (aurais-je oublié quelque chose ?)

bref, si t'arrives à le refaire marcher, tu devrais pouvoir conclure ton test :eeek2:

bonne chance !

Lien vers le commentaire
Partager sur d’autres sites

Le meilleur itinéraire est de simplement se faire passer pour la passerelle par défaut, volant le trafic client à destination de quelque destination distante. Bien sûr, le trafic doit être réexpédié par votre système attaquant, soit en activant l' "IP forwarding" dans le noyau (sysctl -w net.inet.ip.forwarding=1 sous BSD) soit avec un programme en espace utilisateur qui accomplit la même chose (fragrouter -B1).
Lien vers le commentaire
Partager sur d’autres sites

Le meilleur itinéraire est de simplement se faire passer pour la passerelle par défaut, volant le trafic client à destination de quelque destination distante. Bien sûr, le trafic doit être réexpédié par votre système attaquant, soit en activant l' "IP forwarding" dans le noyau (sysctl -w net.inet.ip.forwarding=1 sous BSD) soit avec un programme en espace utilisateur qui accomplit la même chose (fragrouter -B1).

Je rapel que je fait ca uniquement en local (hack des propres paquet que ma machine envoi machine)

J'utuliserai arpspouf plus tard.

Merci mephisto pour ta reponse je vais tester tout ca et je posterai plus tard

Lien vers le commentaire
Partager sur d’autres sites

Ben en local ou pas il faut pas couper le flux de données...

oui mais j'arrive a me connecter correctement en telnet pour faire le test de dsniff et puis tcpdump voit le trafic...

En local il n'y a pas besoin de rediriger le travif vers son destinataire sinon je recevrai en boucle les meme paquets c'est uniquement avec arpspoof qu'on doit s'assurer de redireger les paquets pour ne pas interompre une connection. Non?

Lien vers le commentaire
Partager sur d’autres sites

>>Je ne me suis jamais penché sur le fonctionnement de telnet, mais je présume qu'il ne fait qu'initialiser une connexion, à savoir, envoyer syn, attendre synack, renvoyer ack. >>syn/ack n'étant pas supporté par dsniff, il est normal que tu ne puisse pas les voire dans le log associé.

dsniff est un renifleur de mots de passe qui supporte les

protocoles FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP,

IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS,

YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, Post­

greSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere,

NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase et

Microsoft SQL.

>>si tu veux faire le test, utilise telnet pour simuler le fonctionnement d'une connexion, ou n'utilise pas telnet, et log le traffique d'autre port (que tu aura préalablement ouvert, et >>sur lequel tu fera passer tes datas).

J'utilise deja telnet pour faire mes tests car pour dsniff c'est le protocol le plus simple a dechifré (login et MDP en clair)

Pour resumer:

1) J'ai une console comme ca connecter en ssh sur 192.168.1.104

22:25 root@Debian ~# dsniff port 23

dsniff: listening on eth0 [port 23]

2) J'ai une autre console comme ca connecter en ssh sur 192.168.1.104

22:29 root@Debian ~# tcpdump -A dst port 23

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

3) Ensuite je me connecte en telnet sur 192.168.1.104

4) je rentre mes logs sur la console connecter en telnet (USER=metrem MDP=alienware)

5)resultat de la console dediee a tcpdump

22:35 root@Debian ~# tcpdump -A dst port 23

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

22:35:29.140859 IP 192.168.1.100.51345 > 192.168.1.104.telnet: S 1824515601:1824 515601(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

E..4_=@....j...d...h....l......... ..y..............

22:35:29.140913 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 1780701965 win 256

P...J..........d...h....l...j#[

22:35:29.147169 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 0:21(21) ack 1 win 256

P............ .....'.........#[

22:35:29.206588 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 21:24(3) ack 13 win 256

E..+_@@....p...d...h....l..'j#[.P...&.....#...

22:35:29.206853 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 24:33(9) ack 25 win 256

E..1_A@....i...d...h....l..*j#[%P...........P....

22:35:29.207093 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 33:50(17) ack 4 3 win 256

E..9_B@....`...d...h....l..3j#[7P... ..... .38400,38400..

22:35:29.207123 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 50:56(6) ack 43 win 256

E..._C@....j...d...h....l..Dj#[7P...".....'...

22:35:29.207141 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 56:67(11) ack 4 3 win 256

E..3_D@....d...d...h....l..Jj#[7P...U.......XTERM..

22:35:29.213880 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 67:70(3) ack 52 win 256

E..+_E@....k...d...h....l..Uj#[@P...H.........

22:35:29.213889 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 70:73(3) ack 52 win 256

E..+_F@....j...d...h....l..Xj#[@P...D.........

22:35:29.213916 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 73:76(3) ack 52 win 256

E..+_G@....i...d...h....l..[j#[@P...(.....!...

22:35:29.410005 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 74 win 256

E..(_I@....j...d...h....l..^j#[VP...Iw........

22:35:29.610017 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 88 win 256

E..(_K@....h...d...h....l..^j#[dP...Ii........

22:35:31.262750 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 76:77(1) ack 88 win 256

E..)_M@....e...d...h....l..^j#[dP...._..m.....

22:35:31.414653 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 77:78(1) ack 89 win 256

E..)_N@....d...d...h....l.._j#[eP....]..e.....

22:35:31.610198 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 90 win 256

E..(_P@....c...d...h....l..`j#[fP...Ie........

22:35:31.646654 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 78:79(1) ack 90 win 256

E..)_Q@....a...d...h....l..`j#[fP....[..t.....

22:35:31.838659 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 79:80(1) ack 91 win 256

E..)_S@...._...d...h....l..aj#[gP....Y..r.....

22:35:31.990668 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 80:81(1) ack 92 win 256

E..)_T@....^...d...h....l..bj#[hP....W..e.....

22:35:32.142703 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 81:82(1) ack 93 win 256

E..)_V@....\...d...h....l..cj#[iP....U..m.....

22:35:32.340493 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 94 win 256

E..(_X@....[...d...h....l..dj#[jP...I]........

22:35:32.862690 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 82:84(2) ack 94 win 256

E..*_Z@....W...d...h....l..dj#[jP...<I..

....

22:35:33.060550 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 96 win 256

E..(_\@....W...d...h....l..fj#[lP...IY........

22:35:33.261113 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 106 win 256

E..(_^@....U...d...h....l..fj#[vP...IO........

22:35:34.766767 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 84:85(1) ack 10 6 win 256

E..)_`@....R...d...h....l..fj#[vP....E..a.....

22:35:34.966746 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 85:86(1) ack 10 6 win 256

E..)_b@....P...d...h....l..gj#[vP....D..l.....

22:35:35.159014 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 86:87(1) ack 10 6 win 256

E..)_d@....N...d...h....l..hj#[vP....C..i.....

22:35:35.286757 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 87:88(1) ack 10 6 win 256

E..)_e@....M...d...h....l..ij#[vP....B..e.....

22:35:35.462760 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 88:89(1) ack 10 6 win 256

E..)_g@....K...d...h....l..jj#[vP....A..n.....

22:35:35.574749 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 89:90(1) ack 10 6 win 256

E..)_h@....J...d...h....l..kj#[vP....@..w.....

22:35:35.814779 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 90:91(1) ack 10 6 win 256

E..)_j@....H...d...h....l..lj#[vP....?..a.....

22:35:36.078876 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 91:92(1) ack 10 6 win 256

E..)_l@....F...d...h....l..mj#[vP....>..r.....

22:35:36.230786 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 92:93(1) ack 10 6 win 256

E..)_m@....E...d...h....l..nj#[vP....=..e.....

22:35:36.398784 IP 192.168.1.100.51345 > 192.168.1.104.telnet: P 93:95(2) ack 10 6 win 256

E..*_p@....A...d...h....l..oj#[vP...<2..

....

22:35:36.590640 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 108 win 256

E..(_q@....B...d...h....l..qj#[xP...IB........

22:35:36.790657 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 535 win 254

E..(_s@....@...d...h....l..qj#]#P...G.........

22:35:36.990654 IP 192.168.1.100.51345 > 192.168.1.104.telnet: . ack 882 win 253

E..(_u@....>...d...h....l..qj#^~P...F?........

37 packets captured

37 packets received by filter

0 packets dropped by kernel

(On voit bien les users et MDP )

6)resultat de la console dediee a dsniff:

22:25 root@Debian ~# dsniff port 23

dsniff: listening on eth0 [port 23]

Voila!

EDIT: J'ai fait aussi le test sur une connexion telnet entre deux pc avec le troisieme qui fait du man in the middle grace a arpspoof et j'ai exactement le meme cas sur ma console dediee a tcpdump et sur ma console dediee a dsniff

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...