Re: Whitepaper: Individuazione dei nodi promiscui su reti Token ring con

> Introduzione
> La possibilit? di individuare i nodi di una rete locale che effettuano
> intercettazione, analisi e monitoraggio dei dati (sniffing) ? stata oggetto
> di numerosi studi. Sebbene questi studi non abbiano permesso di sviluppare
> tecniche universalmente efficaci, nondimeno hanno fornito alcuni strumenti
> comunemente usati per le reti basate sulla tecnologia Ethernet.
> Daiji Sanai nel suo white paper [1] ?Detection of promiscuous nodes using
> ARP Protocol? illustra una di queste tecniche che si basa, appunto, sul
> protocollo ARP.
l'analisi da egli compiuta si basa sul fatto che un pacchetto letto in 
promisquo verra' trattato dallo stack TCP/IP, un test simile veniva fatto
con i ping, era un bug ed e` stato corretto. riguardo l'arp e` stato corretto
anch'esso.

inoltre il fatto che uno sniffer sia software e con del software tu possa 
controllare le tue risposte http://www.s0ftpj.org/bfi/online/bf9/BFi09-14
(e` del 2001) mi suggerisce che se c'e` un modo per individuare macchine 
in promisquo questo non deve basarsi sulle risposte del sw (dando per 
scontato che non sia stato modificato su una macchina compromessa, o una
macchina li` per sniffare :)

> Ovviamente i commenti sono graditi.

l'unico sistema abbastanza valido per poter fare individuazione di una macchina
in promisquo la puoi trovare descritta a nome di "network latency test"
perche` si appoggi ad un limite hardware e a delle considerazioni logiche 
piu` che categoriche ("e` tornato l'arp / non lo e`", qui ci sara` un rapporto
che su una base di studi verra` comparato con dei valori di base)

sostanzialmente funziona cosi`:

si testa una macchine pingandola, si vede la velocita` che ci impiega
a rispondere (sapendo che questa dipende sia dal suo carico di lavoro,
che dalle performance espresse dai suoi software e dal suo hardware, che
dal suo traffico) una volta calcolato un valore medio, si inizia a fare grosso
traffico verso un'altra macchina nella rete o fuori (sapendo che se una 
macchina fosse in promisquo comunque lo leggerebbe) si ri-testa la 
macchina in analisi, se il tempo aumenta di poco e` perche` siamo noi ad essere
congestionati a causa dell'invio, se aumenta di molto e` perche` anche egli
sta` leggendo ed interpretando quel traffico (la lettura e l'analisi sono 
piu' strassanti dell'invio) e quindi e` in promisquo

"poco" e "molto" devono essere dei rapporti con dei range e con dei 
confronti ben pensati, antisniff dei l0pht lo faceva, la versione GPL
sentinel non mi sembra sia mai arrivato a supportalo.

nel mio articolo la soluzione proposta e` scritta pensando ad un'analisi da 
parte di sentinel o di antisniff, che usano gli icmp, ma non risolvo il
problema alla base, ovvero che quest'analisi si appoggia a un limite hardware
ed e` parecchio difficile riuscire via software evitarla (un po' come la 
famosa domanda "ma con un firewall posso proteggermi da smurf ?" no, perche` ?
perche` la tua banda e` un limite hardware :)

la soluzione definitiva sarebbe che lo sniffer individui il flood e stacchi la 
scheda dalla modalita` promisqua, perdere un po' di traffico per un istante
per rimanere invisibili ad un test puo' essere un compromesso accettabile in
certe situazioni.


mi sono gia` ripromesso di studiare come scriverlo appena uscira` la versione
next generation di un software che tutit ben conosciamo :))




ciao ciao 
Claudio

Attachment: pgp00011.pgp
Description: PGP signature