MetreM Posté(e) le 21 août 2008 Partager Posté(e) le 21 août 2008 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 More sharing options...
Amour Posté(e) le 21 août 2008 Partager Posté(e) le 21 août 2008 Le port 23 c'est telnet, pour SSH c'est le 22 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Starbetrayer Posté(e) le 21 août 2008 Partager Posté(e) le 21 août 2008 Pourquoi ne pas utiliser ethereal ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 21 août 2008 Partager Posté(e) le 21 août 2008 Si dsniff ne trouve rien, et que ton cas n'est pas isolé, c'est peut être que le logiciel n'est pas capable de le faire. Si ça se confirme, tu peux toujours envoyer un bugreport. Lien vers le commentaire Partager sur d’autres sites More sharing options...
MetreM Posté(e) le 21 août 2008 Auteur Partager Posté(e) le 21 août 2008 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 More sharing options...
madko Posté(e) le 21 août 2008 Partager Posté(e) le 21 août 2008 Merci pour vos reponses plus que rapidePour 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 More sharing options...
MetreM Posté(e) le 21 août 2008 Auteur Partager Posté(e) le 21 août 2008 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 More sharing options...
MetreM Posté(e) le 22 août 2008 Auteur Partager Posté(e) le 22 août 2008 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 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 More sharing options...
Mephisto Posté(e) le 22 août 2008 Partager Posté(e) le 22 août 2008 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
MetreM Posté(e) le 22 août 2008 Auteur Partager Posté(e) le 22 août 2008 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 More sharing options...
theocrite Posté(e) le 22 août 2008 Partager Posté(e) le 22 août 2008 Depuis le bugreport ? Je ne vois pas le thread en question http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dsniff Lien vers le commentaire Partager sur d’autres sites More sharing options...
Mephisto Posté(e) le 22 août 2008 Partager Posté(e) le 22 août 2008 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 bonne chance ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krapace Posté(e) le 22 août 2008 Partager Posté(e) le 22 août 2008 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 More sharing options...
MetreM Posté(e) le 22 août 2008 Auteur Partager Posté(e) le 22 août 2008 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 More sharing options...
Krapace Posté(e) le 22 août 2008 Partager Posté(e) le 22 août 2008 Ben en local ou pas il faut pas couper le flux de données... Lien vers le commentaire Partager sur d’autres sites More sharing options...
MetreM Posté(e) le 22 août 2008 Auteur Partager Posté(e) le 22 août 2008 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 More sharing options...
MetreM Posté(e) le 22 août 2008 Auteur Partager Posté(e) le 22 août 2008 >>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 More sharing options...
MetreM Posté(e) le 25 août 2008 Auteur Partager Posté(e) le 25 août 2008 up Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.