Newsgroup: it.comp.sicurezza.varie
Titolo: man in the middle

Come faccio ad accorgermi se qualcuno sta sniffando i miei pacchetti con
questo sistema? Come ci si puo difendere?
Matteo
--------------------------------
Inviato via 
http://usenet.libero.it

 /tmp/promiscuous_detection_01.pdf
Interessante, interessante, lo manderesti pure a me ?
-- 
ciao
Balin
	"il nano con l'alabarda"


Ciao, piu' o meno ho lo stesso problema anch'io. Credo che un tizio
nell'azienda utilizzi uno sniffer. Ho provato a mandare qualche pacchetto su
quella macchina, utilizzando l'indirizzo MAC sbagliato con un programmino
fatto ad me, pensando che se mi rispondeva, allora aveva settato la sua
scheda in modalita' promiscua, ma credo di aver sbagliato qualcosa,
sicuramente per la mia scarsa conoscenza sul tcp/ip e tutto quello che gli
gira intorno.
Se gentilmente puoi invialrmi a questo indirizzo (togliendo NUNSPAMMA) lo
stesso pdf, sarebbe cosa molto gradita.
Grazie
Ciao

 evitare di rispondere ai miei post. Cito Sciassia: <omissis>
e valido manda pure
grazie


 PDF in proposito.
 . . . e se da buon conterroneo lo mandassi anche a me te ne sarei molto
grato.
Ciao.
Antonino.
ac...@tiscalinet.it

 evitare di rispondere ai miei post. Cito Sciassia: <omissis>
e valido manda pure
grazie
--------------------------------
Inviato via 
http://usenet.libero.it

scheda in modalita' promiscua
Non e' necessario andare in modalita' promiscua per sniffare i
pacchetti: se fai arp poisoning, non ti serve.
Dai un'occhiata al thread sull'arp poisoning su 
sikurezza.org
:
http://www.sikurezza.org/ml/09_02/threads.html
Personalmente, ogni tanto utilizzo arpcop, che e' un plugin di
ettercap (
http://ettercap.sourceforge.net/
) ma ci sono anche altri
strumenti.
Buttha 
-- 
No more antispam

 thorin@angband:~$ ls -l /tmp/promiscuous_detection_01.pdf 
Attenzione: negli attacchi mim in rete locale (basati su arp spoofing)
le interfacce di rete dell'attaccante non sono in modalita' promiscua,
perche' il mac address del traffico da catturare e' quello corretto di
chi attacca. I sintomi di un attacco di questo tipo (in corso) sono, a
seconda dei casi:
- arp reply non sollecitate (gratuitous);
- discordanza della coppia mac<->ip rispetto al traffico "normale";
- (solo con alcuni tool) la presenza di un hop in piu' nel traffico;
- (solo con TLS/SSL, SSH1) il certificato del server pare non valido;
- malfunzionamenti occasionali delle macchine quando l'entry nella arp
  cache (falsa) dei client non e' ancora scaduta e l'attaccante non ha
  fatto il refresh con il mac corretto al termine dell'attacco mim (il
  giorno che lo becco...).
In pratica i sintomi di mim su reti switchate sono rilevabili soltanto
sugli host implicati a meno che non siano causa di malfunzionamenti su
cui si vada ad indagare (e a meno di un nids su un network tap).
Fabio
PS: scusa per il messaggio in mailbox.

 perche' il mac address del traffico da catturare e' quello corretto di
Per identificare lo sniffer ho usato una mezza specie di ping. Mi sono fatto
un programmino che spediva una richiesta agli indirizzi IP della rete ma non
all'indirizzo Ethernet.
Siccome nessuno potrebbe vedere questo pacchetto, se ricevo una risposta
vuol dire che probabilmente il tizio ha un sniffer sulla sua macchina...
Mi pare di capire pero', che puo' non funzionare!
Giusto?
Mi sono accorto che sulle reti c'e' davvero molto da studiare (non c'ho
capito niente di quello che hai detto ...o quasi). Fare l'analista m'ha
rincoglionito ancora di piu' ed ho perso il contatto con la rete. Io che
vorrei passare da analista a sistemista, dovro' faticare molto credo!
Ciao

 Giusto?
Se lo sniffer non e' abbastanza stupido da rispondere ugualmente, si.
In effetti mi pare ci sia una patch del kernel linux per fare cio' (anti-
anti-sniff, mi pare si chiami)
-- 
HappyCactus - Registered Linux User #209744 - >>> SMSPM950 <<<
http://www.angelfire.com/jazz/happycactus/index.html
Made with 100% recycled electrons

 /tmp/promiscuous_detection_01.pdf
Rispondo al post di Thorin per dire a tutti quelli che hanno richiesto il
file che possono reperirlo all'indirizzo:
http://www.securityfriday.com/promiscuous_detection_01.pdf
d'altronde bastava una piccola ricerca con google ;-)
Ciao
Fabio

 sicuramente ci si accorgera' del problema perche' qualche PC protestera'
Una entry va a sostituire l'altra avente lo stesso ip address e, quindi,
non si sovrappongono (e' questo che intendevi, o non ho capito?).
E' molto subdola. Ma e' anche il modo in cui ho scoperto l'unico caso di
attacco mim + sniffing con arp poisoning che mi sia capitato. In pratica
stavo indagando su frequenti malfunzionamenti di rete in una universita'
senza riuscire a venirne a capo. Sai... essendo tutte macchine microsoft
pensavo a qualche malfunzionamento del sistema operativo :) Una notte mi
e' venuta una folgorazione: vuoi vedere che... Al primo malfunzionamento
ho fatto subito eseguire all'utente un arp -a e... ecco li' il mac falso 
nella cache!
Non me n'ero mai accorto perche' (stupidamente, col senno di poi) quando
catturavo con ethereal per vedere cosa diavolo succedeva: a) scartavo il
traffico arp (e' mostruoso su quel segmento) e b) non aprivo mai il ramo
"Ethernet II" del decoder, convinto che fosse un problema dei layer piu'
alti. Se l'avessi fatto me ne sarei accorto: era un mac intel, mentre le 
macchine del dipartimento sono tutte 3com. Probabilmente veniva usato un 
tool che non rinfrescava i corretti valori mac<>ip nella cache arp delle 
vittime (penso che nessuno lo faccia) quando veniva chiuso e, quindi, le
connessioni cadevano, perche' i client continuavano ad inviare pacchetti 
con il mac dell'attaccante, che, pero', era ormai giu' e non faceva piu'
il routing del traffico verso i client legittimi. 
Non ho mai scoperto chi fosse. Probabilmente qualcuno che era in ascolto
non solo in rete: gli attacchi (ed i malfunzionamenti) sono cessati sino
dal giorno successivo. Quel mac non si e' mai piu' visto.
Fabio

 ettercap non si dovrebbe _teoricamente_ presentare il problema.
Con ettercap non si presenta. Per quanto riguarda il settaggio del
ttl con netfilter per risolvere il problema di dsniff non ho mai 
fatto una prova.
Fabio

>potevano avere quell'IP, poi, e' scomparso misteriosamente il problema
L'alert di obsd (+arpwatch?) probabilmmente era causato da quella 
doppia assegnazione dello stesso ip che avevi rilevato. Ma se poi
gli alert proseguivano anche con tutti gli host giu', e se la tua 
macchina debian non aveva l'indirizzo ip in questione, allora puo' 
essere che in realta'... non _tutte_ le macchine fossero spente:/
(sto lavorando proprio adesso su una situazione di questo tipo).
Penso che l'unica possibilita' di scoprire l'arcano fosse trovare
l'host con quel mac per vedere che diavolo stava facendo, ma temo
che ormai sia un po' tardi.
Fabio

 invece proprio niente)
Avete guardato se i computer che conoscevate erano accesi o avete
cercato "dei" computer accesi... che so, qualche palmare nascosto
in un cassetto di una scrivania che non usa nessuno o un notebook
appoggiato sopra uno degli armadi degli switch, sotto una pila di 
fogli? ;)
Il mio problema attuale e' quello di qualche fesso che ha cercato
di uscire tramite nat, sperimentando l'effetto "porta in faccia".
Fin qui andrebbe anche tutto bene... se non fosse che il furbetto
lo ha fatto sabato notte da un ip che non fa parte del range dhcp
e che non appartiene a nessuna macchina con indirizzo fisso della
rete. Ci ha provato per una mezz'oretta, poi ha smesso. Sarebbero
varie le spiegazioni possibili, ma nessuna mi tranquillizza...
Fabio