:: soci della - Metro Olografix - associazione culturale telematica (http://www.olografix.org)::

INTRODUZIONE
In questo articolo parleremo dello sniffer in un modo un po' diverso e piu' teorico di
quanto si faccia di solito, visto che oramai e' da considerarsi uno degli strumenti piu'
utili per la comprensione delle reti. Il nostro scopo e' solo di dare qualche input alle
anime piu' smanettone. Ovviamente non ci prendiamo nessuna responsabilita' nel caso il
contenuto dell'articolo fosse usato in modo non canonico.

Diamo per scontante le basi del TCP/IP; se cosi' non fosse datevi uno 'sguardo' al
celeberrimo TCP/IP Illustrated di Stevens.

MR. ETHERNET I SUPPOSE..
Il protocollo ethernet si colloca al livello 2 della pila OSI, il livello data-link.
Lo standard e' definito CSMA/CD (Carrier Sense Multiple Access/Collision Detect)
perche' piu' macchine posso accedere simultaneamente alla ethernet e ciascuna macchina
puo' determinare lo stato della rete attraverso l'individuazione della portante.
Quando una macchina ha un pacchetto da inviare controlla che la rete sia libera,
altrimenti attende un tempo casuale per verificare se la rete e' ancora occupata.
Una volta inviato il frame (vedi sotto) la macchina controlla la rete per verificare 
che altri segnali non interferiscano con la trasmissione (Collision Detect).
Infatti se due frame vengono inviati quasi contemporaneamente, nessuno dei due risulta
leggibile e si verifica una collisione.
La ritrasmissione del frame avviene anch'essa dopo un tempo casuale per evitare che
entrambe le macchine rispediscano di nuovo contemporaneamente i dati; se questo evento 
si riverifica, il precedente tempo di attesa viene moltiplicato esponenzialmente in 
ogni tentativo successivo.
Il mittente comunque non ha nessuna informazione riguardo la ricezione dei dati da 
parte del destinatario (best-effort delivery), visto che normalmente questo e' compito 
dei protocolli di livello superiore al protocollo ethernet della pila OSI.
Ogni scheda di rete ethernet contiene un indirizzo 'fisico' ed univoco (MAC address)
che viene inserito direttamente nel firmware dal produttore e che serve a indirizzare
i frame sulla corretta destinazione fisica.
Nell'header del frame, oltre agli indirizzi MAC di destinazione e sorgente, e'
specificato il protocollo incapsulato all'interno del frame, informazione fondamentale
per il kernel che dovra' interpretare i dati in base al protocollo utilizzato.

Piu' specificatamente, un classico frame Ethernet (per i curiosi, RFC 894) si
compone di un header di 14 byte, 6 byte per l'indirizzo MAC di destinazione, 6 byte
per l'indirizzo MAC sorgente e 2 byte per definire il tipo di protocollo incapsulato
all'interno della frame. In coda al frame, dopo i dati, abbiamo 4 byte utilizzati
per il CRC.
Ora sappiamo di cosa stiamo parlando :)

HUB?
Tutti (noi speriamo) abbiamo avuto qualche esperienza con qualche tipo di rete lan. 
Sicuramente tutti abbiamo presente il concetto di 'hub', ma una ripassatina non fa
male. 
L'hub (testualmente 'concentratore') viene utilizzato per creare delle reti
cosiddette 'shared' con caratteristiche di risorse condivise. 'Shared' significa
innanzitutto che tutte le macchine sulla rete condividono lo stesso cavo. Inoltre
ogni macchina puo' inviare dei pacchetti quando vuole, questi non vengono indirizzati
intelligentemente e vengono ricevuti da TUTTE le schede di rete collegate all'hub.
In seguito sara' la stessa macchina a discriminare i pacchetti che la riguardano
confrontando il MAC address di destinazione, e in caso di match con il proprio
(che ricordiamo essere univoco), il pacchetto viene immagazzinato nel buffer e
reso pronto per essere
elaborato. 
Questo sistema, come potete ben immaginare, e' affetto da vari problemi, primo
fra tutti le collisions dei frame (vedi sopra). Inoltre, sempre per il concetto
di 'shared-media', e' molto facile intercettare i dati di passaggio sul cavo,
dato che tutte le macchine sono in condizione di 'affacciarsi' sulla rete e
'vedere' tutto. 

Il diligente netmanager puo' essere avvantaggiato da una simile caratteristica
della rete, ma come lui anche il prode hacker ne puo' trarre benefici :)
Effettivamente analizzare il traffico di una rete puo' essere molto utile per
vari motivi, primo fra tutti il debug e, non ultimo, quello di 'carpire' informazioni.

SNIFFAMI!
Da dove viene il nome 'sniffer'? Non ci crederete.. dalla Network Associates.
Per i romantici di turno, beh.. un brusco ritorno alla realta' :) 
In effetti il prodotto della NA 'Sniffer Network Analyzer' vanta l'invenzione
di un nuovo termine di uso comune.
Il principio di funzionamento e' semplice. Riprendiamo per un attimo il discorso
sul passaggio delle informazioni su un segmento di rete ethernet. 
Supponiamo di modificare il comportamento della nostra scheda di rete e di fargli
elaborare anche i pacchetti non destinati alla nostra macchina. Per fare questo
utilizziamo una feature dello standard 802.3, il 'promiscuous mode' per le
schede di rete. Il comportamento della nostra scheda in questo caso sara'
diverso: non accettera' piu' solo i pacchetti con il destination MAC che
corrisponde al suo, ma accettera' tutti i pacchetti in transito, di qualsiasi tipo.
Ogni commento e' superfluo :)

HO PAURA..
Proteggersi dagli sniffer comuni e' un compito abbastanza semplice. Il piu' 
veloce e' sicuramente creare une rete switched e non shared, installando degli 
switch al posto degli hub (ne parleremo in seguito). Un altro metodo e' la
criptazione dei dati in transito. 
Per quanto riguarda specificatamente le password ci sono vari tipi di sistemi 
che ora non ci interessa elencare (una fra tutti le one time passwords). 

Per proteggersi e comunque prendere delle contromisure dobbiamo prima INDIVIDUARE
la presenza di uno sniffer sulla nostra lan. Ecco qualche dritta.

I led dell'hub
Uno dei metodi piu' empirici, funzionali e che presuppone una certa familiarita'
con la rete in esame, consiste nel constatare la presenza di traffico non dovuto
attraverso l'accensione del led di controllo di una porta dell'hub collegata
fisicamente su una macchina che non dovrebbe creare traffico in quel momento.
Puo' essere un buon indizio che richiede una verifica utilizzando gli altri metodi.

Il dns
Normalente gli sniffer sono configurati per restituire l'hostname degli ip
che sniffano. Quindi fanno una query PTR al dns per avere questa informazione.
Beh, se constatate un traffico anomalo di richeste dns da una macchina sospetta..
non indugiate ed andate a controllare.

La ping
Il trucco consiste nell' inviare una echo request ICMP all'indirizzo IP
della macchina sospetta modificandone leggermente il MAC address e inserendone
in effetti uno inesistente su quel segmento. Se la macchina in esame ci risponde,
la sua scheda e' in modo promiscuo e probabilmente abbiamo individuato lo sniffer.
Oltre al metodo della ping, possiamo utilizzare qualsiasi altro tipo di
protocolli che prevedono una risposta dalla macchina sospetta, ad esempio
il finger, il time, etc.

Metodo della latenza
Questo e' il piu' intrigante e cattivo metodo per scoprire uno sniffer.
Cosa succede se spediamo una quantita' enorme di pacchetti sulla rete?
Si potrebbe dire quasi nulla. Effettivamente le macchine 'normali' non
subiranno nessun rallentamento apprezzabile, ma la macchina in promiscuous
mode.. beh quella muore :->

Esistono altri metodi (come quello molto comune dell'ARP), ma andare a
scoprirli puo' essere uno stimolo per la curiosita' del lettore.

IL TANTO ATTESO SIGNOR SWITCH
Per parlare degli switch facciamo prima una panoramica sul concetto di
bridging.

Un bridge semplice ha due sole interfacce di rete a cui sono collegati due
segmenti di lan shared (vedi dis. A). La sua funzione e' di immagazzinare i
dati che provengono da uno dei segmenti e inviarli sull' altro segmento SOLO
se lo riguardano. 
Il bridge lavora a livello 2 (data-link) della pila OSI, infatti effettua
controlli solo sull' indirizzo MAC di destinazione dei frame con una tabella
dove riporta tutti i MAC delle schede collegate ai due segmenti di lan (vedi
Tab. A)
La sequenza delle operazioni e' questa: il bridge riceve e immagazzina il frame,
legge il destination MAC e, se corrisponde ad uno dei MAC nella sua arp table,
provvede ad inviare il frame attraverso una delle sue NIC verso il segmento
corrispondente.

- Disegno A
                __                                        __
               s  |                                      |  s
               e  |             | bridge /|             |  e
               g  |             |       / |             |  g
            A  m  |       NIC A |  ____/  | NIC B       |  m  B
               e  |_____________|          |_____________|  e
               n  |             |__________|             |  n
               t__|                                      |__t
	
- Tabella A

              /----------------------------------------------
              |       NIC A          |         NIC B         | 
              |----------------------|-----------------------| 
              | 00-50-04-32-43-xx    |  52-54-05-28-xx-xx    | 
              | 00-40-01-23-43-xx    |  52-54-17-32-xx-xx    | 
              | 00-50-03-22-54-xx    |  00-10-04-33-00-xx    | 
              ----------------------------------------------/
 
Nel caso in cui l' indirizzo richiesto nel pacchetto non fosse presente nella 
tabella, il bridge invia una richiesta arp in broadcast su entrambi i segmenti 
in modo da individuare eventuali nuove interfacce. 
In questo modo ogni segmento risulta fisicamente diviso dall' altro, e le 
comunicazioni che avvengono internamente al segmento non vengono inviate 
attraverso il bridge. 

Lo switch e' semplicemente un perport bridge, ovvero un bridge con molte porte.
Tipicamente lo switch viene utilizzato come super-hub (perdonateci il termine :), 
collegando direttamente i pc alle sue porte, ma un utilizzo piu' canonico prevede 
il collegamento di hub o altri switch invece dei pc. Questo secondo metodo viene 
utilizzato comunemente per reti di grandi dimensioni in cui vi sono esigenze di
segmentazione fisica della rete preesistente (le Virtual LAN meritano un discorso
futuro piu' approfondito).

MI SFORZO MA NON CI RIESCO..
Per quelli che lo stanno facendo: smettetela, TEORICAMENTE non e' possibile sniffare
in una rete switched. Ma come ormai tutti gli smanettoni sanno, nulla e' impossibile
in informatica 'tutto dipende dal tempo, dai soldi e dalle donne' (Maxxx maxima :)

Sorvoliamo tutti gli interessanti discorsi sull'overflowing di richieste arp fittizie
per trasformare il lavoro dello switch da 'bridging' a 'repeating' e passiamo subito
al metodo piu' comodo :)

SPAN E MONITOR PORT
Prendiamo in esame una serie di apparati molto utilizzati, i SuperStack della 3Com.
Questi switch hanno un modulo integrato per la configurazione che si puo' effettuare
in tre modi. Via porta console, telnet e addirittura via web. 

Nota 1: capita spesso di trovare degli switch con un indirizzo ip pubblico e password
di default (leggetevi i manuali per la pass). Se anche voi avete avuto un' idea da nobel
del genere, beh.. andate a chiudervi nel bagno vergognandovi come un camaleonte zoppo
per un' ora :) Infatti attraverso queste comodissime interfacce di configurazione si
puo' fare praticamente qualsiasi operazione sull'apparato. Un esempio? La possibilita'
di disattivare tutte le porte dello switch che, se unita ad un cambio di password, vi
fara' ritrovare con una rete bloccata e un DoS da fine dell' universo. 
Nota per quelli che erano in bagno prima: e' il momento di suicidarsi :) 

Un'altra possibilita' offerta da queste interfacce e' poter configurare una 'monitor'
o 'span' port. Il primo termine appartiene molto all'ambito 3Com dove sugli switch
possiamo monitorare il traffico di una sola porta alla volta. Dunque in questo caso
dovremo decidere quale porta usare come bersaglio e quale come monitor port. 
Il termine 'span' invece riguarda molto l'ambito Cisco con i suoi Catalyst. Qui
abbiamo la possibilita' di configurare una porta che riceve i dati anche di TUTTE
le altre porte dello switch. Possiamo considerare questa porta cosi' configurata
come una porta di un semplice hub.

Tutte queste features vengono gestite attraverso i classici modi di interfacciamento
di questi apparati, quali le porte console, il telnet e in quelli piu' recenti anche
l'interfaccia web.
Visto che questi sistemi di configurazione hanno normalmente dei menu user-friendly,
pensiamo che non siano necessarie spiegazioni piu' dettagliate. Se comunque ne avete
bisogno tutta la documentazione e' presente sui siti dei relativi costruttori :)

Oltre questi metodi di configurazione ne manca una che forse e' il piu' sfizioso: il
protocollo SNMP. 
Il Simple Network Management Protocol e' pienamente supportato oltre che dai 3Com e
dai Cisco, anche dalle altre maggiori marche, e -fidatevi- ci sono molti piu' switch
con il supporto SNMP attivato e community di default che con password di default. 
Delle possibili sfiziosissime applicazioni dell' SNMP & Sniff parleremo magari in un
prossimo articolo :)
Nel frattempo fatevi una bella spremuta di.. meningi :)

SFRAJO SNIFFER
Fino ad ora abbiamo discusso prevalentemente su come individuare uno sniffer e favorirne
il funzionamento.
Supponiamo di aver accesso fisico ad una rete e di non volere affatto che il nostro
sniffer sia individuabile o che generi traffico inutile.
Il metodo piu' efficace ed interessante e' quello di rendere 'muta' la scheda di rete
della macchina su cui gira lo sniffer. Naturalmente la funzionalita' generale del
collegamento fisico deve rimanere invariata in quanto la nostra scheda di rete deve
continuare a ricevere i frame in ingresso. 
Sui cavi di rete oltre ad essere trasmessi i dati, viene mantenuto un segnale di link
con l'hub. Questo impulso elettrico viene trasmesso dall'hub verso la scheda di rete
che provvede a rinviarlo automaticamente. Ora, bloccare completamente i segnali in
uscita della scheda di rete non consentirebbe il normale link con l'hub. Infatti
l'hub non trovando nessun collegamento sulla porta, la considera non utilizzata.
Il trucco c'e' e consiste nel 'danneggiare' i segnali in uscita dalla scheda. 
Complicato? Affatto. 
Questo nefasto segnale viene ritrasmesso solamente su uno dei due poli di trasmissione
del cavo (TD+). Scollegando solamente l'altro polo (TD-), i frame in uscita dalla
scheda verranno interpretati dalle altre macchine sulla rete come semplici disturbi,
ma il segnale di link continuera' ad essere presente.
Abbiamo fatto i nostri esperimenti del caso su una classica rete shared a 10 Mb con
un comunissimo hub.
Abbiamo preso un cavetto cat. 5 UTP (normalmente utilizzato per tutte le moderne lan
ethernet) e abbiamo scollegato il pin 2 che provvede a fornire il segnale di Transmit
Data negativo (TD-) di cui parlavamo sopra.
Il nostro pc, come l'hub d'altronde, non si accorge minimamente della nostra modifica. 
L'hub vedendo un computer collegato, smista anche su di esso i frame della lan.
Il computer dal suo canto li riceve tranquillamente.
Quando il pc prova ad inviare dei frame non riscontra nessun problema poiche'
vengono realmente spediti sulla rete ma sono interpretati dal resto delle macchine
solamente come disturbi e dunque ignorati.
Non ci crederete ma la cosa funziona veramente. 
(un grazie sentito a _Q_ che ci ha permesso di 'tagliuzzare' il physical layer
della sua rete :)

Nella seconda parte approfondiremo alcuni discorsi qui solo accennati, sperando
di avere piu' tempo per fornire anche qualche parte di codice utile.



Ringraziamenti

W.R. Stevens... grazie per essere esistito, che il tuo spirito scenda su di noi
per illuminarci.

AhPook per l'italianizzazione delle nostre nozioni tecniche

Tutta la Metro Olografix



Bibliografia

Internetworking with TCP/IP, Comer
Sniffing-faq, Robert Graham
Cisco training, Cisco training group

Ultimo aggiornamento: 23 Marzo 2000