Newsgroup: it.comp.sicurezza.varie
Titolo: sniffer sulla LAN

Come individuare e annullare i computer/programmi che sono in ascolto sulla
rete LAN con degli sniffer
-- 
Posted from 
dario.insean.it
 [212.239.73.177] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

rete LAN con degli sniffer
Se sono sniffer fessi, c'e' un programmino che credo si chiami "MAC Check".
Per Linux, vari scripts tipo "
antisniff.pl
", che trovi su Rootshell, giusto
per nominare un sito.
Se sono sniffer ganzi, non c'e' modo, semplicemente. Devi usare uno switch,
al posto dell'hub ($$$)... per cominciare :-)
Leonardo
-- 
"Open Source programs are designed and developed.
 Our products are tested."
 Steve Lipner, manager, Microsoft Security Response Center

 Devi usare uno switch, al posto dell'hub ($$$)... per cominciare :-)
Non vorrei minare troppo a fondo il tuo ottimismo ma esistono anche
sniffer che annusano su reti switchate (o suicciate, o switzchate, boo)
... e non attraverso la porta monitor ovviamente :)
Fabio

 wrote:
:> Se sono sniffer ganzi, non c'e' modo, semplicemente.
: Be, comunque funzionino devono mettere la nic in modalità promiscua e
: l'antisniffer cerca le nic in modalità promiscua: come fanno a
: nascondersi più di tanto?
: A parte con un cavo a una sola coppia o cose simili, ovviamente.
c'e' un modulo kernel che si chiama anti-anti-sniff lo hanno codato quelli di s0ftpj...
serve apposta a fare quello che dice il nome... ;)
:> Devi usare uno switch, al posto dell'hub ($$$)... per cominciare :-)
: Non vorrei minare troppo a fondo il tuo ottimismo ma esistono anche
: sniffer che annusano su reti switchate (o suicciate, o switzchate, boo)
: ... e non attraverso la porta monitor ovviamente :)
esatto !!
-- 
  --==> ALoR <==---------------------- -  -   -
  ettercap project: 
http://ettercap.sourceforge.net
  e-mail: alor (at) users (dot) sourceforge (dot) net    

 sniffer che annusano su reti switchate (o suicciate, o switzchate, boo)
Ma se impedisci il "poisoning" delle tabelle dello switch... a meno di
non craccare lo switch stesso...
-- 
Ciao!
HappyCactus


Non è esatto, la tecnica a cui ti riferisci si chiamo ARP-Poisoning e
consiste come dice la parola nell'avvelenare le tabelle arp delle
macchine
di una rete in modo tale da associare l'indirizzo IP del router di
quella
sottorete all'indirizzo arp di una macchina interna compromessa (sulla
quale
e' installato uno sniffer o di cui si abbia pieno controllo). In
questo modo
tutte le macchine "avvelenate" invece che passare per il router
"legale"
passano attraverso la macchina compromessa che puo' cosi' comodamente
sniffare tutto cio' che passa.
Ovviamente su quella macchina bisognera' installare anche un software
che
permetta di reindirizzare il traffico al vero router...
Questo causa diversi problemi:
1. La macchina con lo sniffer deve avere una banda enorme o il
traffico
rallentera' in modo preoccupante.
2. E' relativamente difficile raggiungere una macchina interna  a una
sottorete da remoto e installarci uno sniffer...a me no che non si
abbia
accesso diretto alla macchina ovviamente.
Tutto questo rende il sistema molto difficile da attuare.

 non craccare lo switch stesso...
Uh, non sapevo che si potesse impedire il poisoning.
Come si fa?
Comunque crackare uno switch di solito non è un problema: se community name
non è "3com3300" o "procurve" bastano un altro paio di tentativi per entrare
:))
Fabio

 che non si abbia accesso diretto alla macchina ovviamente.
Ma questo è un problema comune a quasi tutti gli sniffer: non è specifico di
quelli che esguono l'ARP-poisoning.
Fabio

 che non si abbia accesso diretto alla macchina ovviamente.
A proposito di questo punto mi sono dimenticato di fare un osservazione che
ritengo importante e cioč che con questo commento sembra che tu parta dal
presupposto, come spesso accade, che siano sempre *quelli-di-fuori* quelli
da cui ci dobbiamo guardare ...
... e che sistemisti, softwaristi e sedicenti consulenti che (purtroppo) a
volte ti ritrovi in casa o che bazzicano altri dipartimenti su cui non hai
controllo siano sempre degni di fiducia :\.
Spero in una risposta ... che perň leggerň lunedi :)
Ciao
Fabio

 modalità promiscua (se risponde vuol dire che lo è).
Ciao Fabio,  se non  ricordo male  era un  difetto di  una particolare
versione di kernel x Linux, ma di altro non ho trovato info.
Puoi fornire piu' informazioni in merito? 
Ciao Francesco.
-- 
<*> bash$ man -h  per il pinguino che non deve chiedere mai. <*>  
<*> lynx file:/usr/doc/*                                     <*>

Spero in una risposta ... che però leggerò lunedi :)
E' sempre un piacere disquisire di queste simpatiche cose, se ti viene
in mente qualcosa per migliorare ancora le nozioni sull'argomento non
esitare...ah e ricordati di dirmi il nome di quello sniffer tuttofare
se ti capita, a presto!

 utilizzo sniffer più specifici, vedi ethereal, ettercap e tcpdump...
scusa, ma se tu usi ettercap... come fai a non sapere che fa anche il routing i automatico...
con la modalita' arpsniff, poisona, sniffa e inoltra i pacchetti, poi se vuoi prima di inoltrarli, li puoi filtrare, modificare, loggare etc etc... ;)
bye


Come non detto, ettercap in effetti l'ho usato poche volte e non ho
mai notato tutte quelle belle cosette, grazie per avermelo fatto
notare, alla prossima...

 :))
Ne ho sentito parlare... :(
-- 
HappyCactus

 Puoi fornire piu' informazioni in merito?
Non era proprio un bug quanto un modo di lavorare del kernel e non solo di
Linux: anche gli stack TCP/IP di alcuni Unix BSD (NetBSD?) si comportano in
modo analogo.
La tecnica è quella di inviare un pacchetto con un MAC address falso ma un
intestazione IP valida contenente l'IP della macchina da analizzare come
destinatario e la tua come sorgente: questo pacchetto, che dovrebbe essere
droppato a causa del MAC address non corrispondente, viene invece processato
perchè l'interfaccia è in modalità promiscua.
Questo perchè non viene controllata la corrispondenza tra gli indirizzi IP e
MAC.
Windows, invece, controlla la corrispondenza tra MAC e IP: se non
corrisponde al contenuto dell tabella arp il pacchetto viene scartato anche
se l'interfaccia di rete è in modalità promiscua. Il problema è che
l'operazione avviene in modo corretto solo per i pacchetti unicast: se il
pacchetto è broadcast e l'interfaccia di rete è in modo promiscuo, viene
verificato solo il primo ottetto del MAC address e non tutti e sei. Quindi
un pacchetto del tipo ff:00:00:00:00:00, che dovrebbe essere scartato, viene
invece processato. Idem come sopra per il contenuto dell'intestazione IP.
La bontà del metodo basato sul DNS lookup è legata al funzionamento dello
sniffer.
Il metodo della latenza è un po' lungo da spiegare.
In questo sito trovi un po' di documentazione anche su queste due tecniche.
http://www.securitysoftwaretech.com/antisniff/index.html
Spero di non aver scritto qualche scemenza :)
Fabio

 "furbo").
Il problema non č lo sniffer ma l'implementazione dello stack TCP/IP.
Ho scritto una risposta piů dettagliata a Francesco.
Fabio

 occhiata :-)
Ettercap, come ti ha già consigliato ALoR.
Per Windows ho un tool sviluppato da un amico di amici ma non trovo più il
suo sito.
Devo indagare.
Ciao
Fabio

 Ho scritto una risposta piů dettagliata a Francesco.
Capisco.
Quindi in pratica e' lo stack tcp che risponde al pacchetto ICMP,
nonostante esso non sia indirizzato a tale host e nonostante la presenza
dello sniffer.
Chiaramente lo stack della macchina sniffata risponde solo se
l'indirizzo IP di destinazione e' il suo, altrimenti lo stack ignora il
pacchetto.
Quindi in pratica se la macchina "COP" vuole controllare se "EVILHACKER"
sniffa, deve inviare un pacchetto ICMP con indirizzo NIC di destinazione
errato e indirizzo IP di "EVILHACKER", giusto?
In ogni caso "EVILHACKER" non rispondera' agli echo-request indirizzati,
ad esempio, a "PERO".
Mi sorge un'altra domanda.
Supponiamo che EVILHACKER abbia avvelenato le tabelle di ARP dello
switch. COP invia un pacchetto echo-reply a PERO, ma esso arriva allo
sniffer su EVILHACKER attraverso lo switch. Come puo' EVILHACKER inviare
il pacchetto a PERO attraverso lo stesso switch, se quest'ultimo ha le
tabelle "avvelenate"? tali pacchetti arriveranno nuovamente a
EVILHACKER.
O c'e' qualche cosa che non ho compreso?
Ciao! e thnx
-- 
Ciao!
HappyCactus

sniffer che annusano su reti switchate (o suicciate, o switzchate, boo)
Appunto dicevo "per cominciare". Ci sono anche switches resistenti ai
trucchetti ARP (e trucchi piu' complessi, sicche' alla fin fine forse
e' piu' comodo tenere PGP-over-TCP-over-IP :-) ).


 Spero di non aver scritto qualche scemenza :)
Beh appena faccio le prove lo scopro ;-) 
Grazie ancora per le info.


> Basta che non rispondano a quello cui non devono rispondere ;-)
E' esattamente il modo in cui funzionano gli anti-anti-sniffer, che in
pratica sono delle patch per lo stack TCP/IP.
Fabio

 tabelle "avvelenate"? tali pacchetti arriveranno nuovamente a
No, no ... forse non mi sono spiegato. La cache arp che viene avvelenata non
è quella dello switch ma quella delle macchine: se si avvelenasse quella
dello switch si avrebbe un DoS abbastanza evidente proprio per il motivo che
dici tu.
I 'pacchetti' di cui parli ovviamente sono degli echo-request:)).
Fabio

 e' piu' comodo tenere PGP-over-TCP-over-IP :-) ).
Ok per gli switch.
Per quanto riguarda l'uso di una VPN realizzata con PGP rimane una pecca:
spesso gli sniffer non vengono utilizzati per loggare tutto il traffico
(operazione titanica) ma solo la fase di autenticazione dei client, alla
ricerca delle password scambiate in chiaro, degli hash LanManager scambiati
con i controller di dominio, etc.
Questi dati non vengono scambiati attraverso la VPN di PGP.
Fabio

Ok per gli switch.


Non la conosco. Se Windows la vede come dispositivo di rete, pero', si puo'
forse realizzarla cosi':
	[-] Scheda di Rete NE2000 Compatibile
	 |
	 +-- Protocollo TCP/IP (
192.168.0.0/24
)
		[ ] NetBEUI
		[ ] Supporto NetBIOS
		[ ] Condivisione file e stampanti
		[ ] Client per reti Microsoft
	[-] Scheda di Rete PGP VPN
	 |
	 +-- Protocollo TCP/IP (
192.168.1.0/24
)
		[ ] NetBEUI
		[x] Supporto NetBIOS
		[x] Condivisione file e stampanti
		[x] Client per reti Microsoft
...mi sembra che in questa configurazione l'handshake su 
192.168.1.0/24
 non
sia intercettabile (ripensandoci, non so come funzioni, per i broadcasts, e
ci vorrebbe forse un keyservice affidabile...?).


 ci vorrebbe forse un keyservice affidabile...?).
Non ho mai provato. Una cosa mi sembra certa: qualsiasi comunicazione che
richieda NetBIOS/NBT potrà avvenire solo con PC che offrono i servizi di
PGPNet (oltre alle autorizzazioni e alle chiavi, ovviamente). Il che non è
molto comodo :-)
L'indirizzo di broadcast è 192.168.1.255 e quindi appartiene alla VPN.
Non capisco cosa ci faccia NetBEUI nel tuo schemino.
Fabio

 I 'pacchetti' di cui parli ovviamente sono degli echo-request:)).
oVio. :)
mi sono sconfusionato.
-- 
Ciao!
HappyCactus

 per tale protocollo? esiste gia'?
Attualmente non esiste un protocollo di autenticazione a questo livello.
Fabio

 Tra poco dovrò (re)imparare C: potrebbe essere un buon allenamento.
Da quel che mi par di capire, si tratterebbe di un "modulo" da attivare
in locale, che controlla la cache ARP per verificare se e' tutto ok: non
ho capito il fatto della "congurenza" con uno stato di riferimento, in
quanto se esiste uno stato di riferimento, considerato "buono" non vedo
come sia necessario aggiornare lo stato...
In ogni caso: si diceva un po' di tempo fa che alcuni s.o. sono "bacati"
nel senso che tengono buone anche le ARP-reply non sollecitate, mentre
altri non lo fanno. Ancor piu' difficile quando si utilizzano indirizzi
di Broadcast.
Sai se e' il caso di Windows e vari kernel linux?
-- 
Ciao!
HappyCactus

 Ancor piu' difficile quando si utilizzano indirizzi di Broadcast.
Non capisco bene cosa intendi dire con difficile. Il mac address di una
comunicazione broadcast contiene ff:ff:ff:ff:ff:ff e viene elaborato
comunque da tutte le macchine.
Fabio

Non capisco cosa ci faccia NetBEUI nel tuo schemino.
Prende memoria :-(
Leonardo che svista fu


 comunque da tutte le macchine.
Intendevo dire: 
Se si filtrano le risposte non sollecitate, e' un conto. ma quando si ha
a che fare con pacchetti di broadcast, forse la cosa si complica un po'.
Comunque, daro' una occhiata alla rfc...
Grazie di tutto!
-- 
Ciao!
HappyCactus

A parte con un cavo a una sola coppia o cose simili, ovviamente.
Questa del cavo mi incuriosisce assai: puoi dare qualche informazione in
piu'? Va benissimo anche un URL...
-- 
BlueRaven
Scrivi su USENET? Allora:
# kill -HUP html_posting && modprobe quoting.o

 piu'? Va benissimo anche un URL...
E' una tecnica che prevede l'utilizzo di cavi con la sola coppia RX
funzionante. Richiede l'uso di alcune tecniche per far si che l'hub/switch
non chiuda la porta come guasta o vuota: in pratica la coppia TX viene
'guastata' srotolando i conduttori e usando un cavo molto lungo, in modo che
esista comunque un link fisico attraverso cui possa pasare lo stream di
controllo della porta ma non i dati.
Purtroppo i link che avevo non funzionano più: prova a cercare su gugl con
"clipped cable wiretap" o cose simili.
Fabio

"clipped cable wiretap" o cose simili.
Grazie mille.
