-
serglasser.
User deleted
Titolo originale: Detecting packet injection: a guide to observing packet spoofing by ISPs
Rilevare il packet injection: guida all'individuazione della contraffazione di pacchetto degli ISP
Introduzione
Alcuni provider di servizi Internet (ISP) hanno cominciato a intromettersi nelle comunicazioni dei propri utenti immettendo pacchetti falsati [forged] o contraffatti [spoofed] - dati che sembrano provenire dall'altro capo della comunicazione, ma che invece sono stati appunto generati da un ISP nella sua parte centrale. Lo spoofing è uno dei mezzi (ma non l'unico) per bloccare, disturbare o comunque compromettere il possibile utilizzo - da parte di un utente - di particolari applicazioni, servizi o protocolli.
Un importante strumento per mostrare la responsabilità degli ISP in questo tipo di interferenza sarebbe la possibilità per gli utenti di rilevarla e documentarla. Dobbiamo apprendere cosa stanno facendo gli ISP prima di provare a far qualcosa per impedirglielo. Gli utenti di Internet possono perlopiù rilevare queste interferenze confrontando i dati inviati a un capo con i dati ricevuti dall'altro capo di una connessione.
Tecniche del genere sono state usate dalla EFF e da Associated Press per produrre prove chiare sulla volontaria interferenza di Comcast nelle applicazioni di file sharing; sono state usate anche per documentare la censura del Grande Firewall Cinese.
In ciascuno di questi casi, è stato beccato un intermediario che immetteva pacchetti TCP reset i quali provocavano la caduta della connessione - anche quando i capi della connessione intendevano continuare a comunicare.
In questo documento, descriviamo come utilizzare un analizzatore di rete come Wireshark per effettuare un esperimento e rilevare comportamenti come quelli descritti.
NOTA BENE: Queste istruzioni sono rivolte a persone che abbiano una buona competenza tecnica, una comprensione generale dei meccanismi di internet, ed esperienza nell'installazione di software, nell'esame e nella modifica delle impostazioni amministrative dei propri computer, nonché in grado di gestire programmi a riga di comando.
REQUISITI
L'utilizzo di queste tecniche richiede una comprensione generale della tecnologia di Internet e un buon grado di competenza tecnica. Se non capite il processo, non potete produrre prove significative delle azioni del vostro provider. Benché abbiamo provato a spiegare la maggior parte dei concetti e dei principi relativi alla rete implicati, potrebbe rivelarsi utile la lettura di almeno un libro o sito web tecnico sull'insieme di protocolli noto come TCP/IP prima di cominciare.
Il test qui descritto va effettuato insieme ad un amico che utilizza una connessione internet diversa (dovrebbe stare, quindi, presumibilmente in un luogo diverso). Sia voi sia il vostro amico dovreste avere una buona comprensione del processo che stiamo per descrivere; il test si basa sul confronto di osservazioni fatte in due punti diversi, allo scopo di trovare differenze tra di esse. Per questo motivo, non sarebbe sensato effettuare il test da soli. Queste istruzioni sono anzitutto utili per testare le applicazioni peer-to-peer o applicazioni per le quali potete gestire il vostro server (è più difficile verificare se un ISP stia bloccando un servizio "terzo" come Google, a meno che l'operatore di quel servizio non sia interessato a partecipare direttamente ai test) (1)
I test di cui trattiamo sono più un modo per individuare uno specifico problema, osservato e riproducibile (per esempio, l'impossibilità di connettersi a un altro nodo terminale) che un mezzo speculativo per investigare sul comportamento dei provider. Questo è dovuto innanzitutto alle limitazioni dei tool per automatizzare la messa a confronto di tracce di pacchetti tra due nodi terminali di una connessione. Tradizionalmente, questo confronto veniva operato a mano, cosa che può essere piuttosto lunga, se non si sta cercando qualcosa in particolare.
La EFF ha cominciato a sviluppare tool per automatizzare questo processo in modo che si possano confrontare automaticamente tracce di pacchetti di grandi dimensioni e si possa individuare l'immissione di pacchetti anche laddove non ci verrebbe in mente di cercarla.
Chi vuole partecipare all'esperimento deve avere:
un computer su cui poter eseguire Wireshark, e la possibilità di installare il programma e farlo partire
la possibilità di connettere questo computer a internet direttamente, con un indirizzo IP pubblico e dietro nessun firewall (quindi, non deve essere connesso tramite un classico router wireless casalingo)
la capacità di determinare l'indirizzo IP pubblico del computer
la capacità di disabilitare i firewall presenti sul computer stesso
un'applicazione da testare e la capacità di configurare questa applicazione in modo da comunicare direttamente con l'altro capo della connessione (tramite indirizzo IP)
Nota sulla privacy
Un intercettatore di pacchetti [packet sniffer] può catturare tutto il traffico che passa attraverso il vostro computer (comprese tutte le vostre comunicazioni personali e - potenzialmente - quelle di altri utenti sulla stessa rete); se il vostro computer è connesso a una rete wireless, per esempio, l'interecettatore di pacchetti può registrare tutto quello che fate e tutto quello che qualsiasi altra persona appoggiata alla rete wireless fa online.
Siete pregati di non registrare le comunicazioni di altre persone senza il loro consenso. Farlo è scorretto e, a determinate condizioni, può essere proibito dalla legge. Un modo per evitare di registrare le comunicazioni di terzi è evitare di utilizzare la modalità promiscuous per l'intercettazione di pacchetti, a meno che non ne abbiate specificamente bisogno.
Se producete un file di intercettazione (traccia del pacchetto) con i risultati del vostro esperimento, fate attenzione a che il file riveli il vostro indirizzo IP, l'IP dell'altra persona coinvolta e una registrazione completa di tutto quello che avete fatto online nel corso dell'esperimento. Per esempio: se avete scaricato un file, la traccia del pacchetto dovrebbe rivelare quale file avete scaricato/uploadato (e dovrebbe anche includere tutto il contenuto del file). Se durante l'esecuzione dello sniffer avete effettuato una ricerca sul web oppure dato un'occhiata all'e-mail, le identità e i contenuti delle pagine web che avete visitato e dei messaggi e-mail che avete scaricato possono apparire nella traccia del pacchetto. Inoltre, vi saranno inclusi tutti i cookie HTTP mandati al vostro browser (che potrebbero comprendere lo username e la password che utilizzate per i siti web che visitate). Dovreste muovervi con cutela se pubblicate o condividete un file di intercettazione pacchetto, se non intendete rivelare più informazioni di quelle che vorreste.
TEORIA
La tradizionale architettura Internet è caratterizzata da una struttura end-to-end in cui gli ISP inoltrano passivamente pacchetti non modificati da un utente all'altro. Questo significa che, nel migliore dei casi, ogni pacchetto inviato da un utente dovrebbe essere ricevuto senza modifiche dall'altro nodo terminale. Ma ci sono parecchi motivi per cui questo potrebbe non succedere, anche in mancanza di immissione di pacchetti da parte degli ISP:
Frammentazione
Lo standard Internet Protocol permette agli ISP di frammentare pacchetti troppo estesi (per esempio: quando una particolare tecnologia di rete utilizzata da un provider contempla una dimensione dei pacchetti massima). I pacchetti vengono così ridotti in frammenti più piccoli che arrivano a destinazione separatamente; al computer destinatario è dato di riassemblare questi frammenti.
La frammentazione è diventata meno comune, per diversi motivi, tra cui parametri predefiniti per dimensioni di pacchetto nel codice di rete dei sistemi operativi mirati e meccanismi come il path MTU discovery (per selezionare automaticamente una dimensione di pacchetto sufficientemente piccola da evitare la frammentazione).
Nei risultati del test che abbiamo ottenuto finora, generalmente non abbiamo riscontrato frammentazione, quindi nel presente scritto ignoreremo questa possibilità, anche se dovrebbe essere considerata una plausibile causa di discrepanze tra pacchetti inviati e pacchetti ricevuti.
Perdita di pacchetti
In occasione di una congestione del traffico di rete, è normale che alcuni pacchetti vengano scartati anziché inoltrati: questo fenomeno è noto come «perdita di pacchetti».
La perdita di pacchetti normalmente viene calcolata in percentuali; la utility ping misura la perdita di pacchetti inviando una ICMP echo request e contando quante risposte ICMP vengono ricevute in relazione a un certo numero di indagini.
Alti tassi di perdita di pacchetti potrebbe essere causati volontariamente da un provider, per ridurre la performatività di un'applicazione o di un protocollo-bersaglio, ma potrebbero anche essere il frutto di un eccesso di traffico sulla rete o di qualche altro problema tecnico. Quando si perde un pacchetto, esso non arriva più a destinazione. Alcuni protocolli internet di alto livello includono meccanismi per rintuzzare la perdita di pacchetti (per es., il meccanismo del protocollo TCP che ritrasmette i dati di pacchetti che sono andati persi).
Riordinamento
A volte, i pacchetti non vengono inviati nello stesso ordine con cui sono stati originariamente trasmessi. Se il pacchetto B è stato trasmesso dopo il pacchetto A, ricevere il pacchetto B all'altro capo della connessione non significa che il pacchetto A sia andato perso; potrebbe stare ancora a metà strada. Generalmente, il protocollo TCP riesce a correggere anche il riordinamento. Come la perdita di pacchetti, così il riordinamento potrebbe essere usato intenzionalmente da un ISP per degradare un'applicazione, ma potrebbe anche accadere normalmente nel corso del routing su Internet.
Spoofing
Lo spoofing o immissione di pacchetti si ha quando un'entità diversa dagli endpoint (i nodi terminali di una comunicazione/connessione) genera traffico utilizzando l'indirizzo IP sorgente [source address] di un endpoint. Lo spoofing è il mezzo di interferenza col traffico internet più facilmente individuabile, visto che produce prove concrete nella forma di pacchetti contraffatti anomali e che normalmente non ha luogo nel tradizionale routing su internet.
Lo spoofing può essere individuato cercando i pacchetti ricevuti da un nodo e mai mandati dall'altro nodo. Se l'utente B riceve un pacchetto che sembra mandato da un utente A ma che l'utente A non ha prove di aver mandato, l'utente B può concludere che qualcuno, a metà strada tra i due nodi, ha contraffatto questo pacchetto. Il resto di questo articolo descrive il modo per raccogliere tracce di pacchetti in modo che i pacchetti effettivamente trasmessi tra due utenti possano essere confrontati.
Lo spoofing non implica necessariamente l'impedimento o il blocco delle comunicazioni; potrebbe anche comportare "solo" la modifica del loro contenuto, come succede con un "proxy trasparente" (2). Alcuni provider hanno provato con successo a modificare il codice HTML in pagine web di terzi, allo scopo di inserirvi pubblicità.Ecco un recente esempio realmente verificatosi:
In questa immagine fornita da Chris Palmer, un ISP wireless ha modificato il codice sorgente della home page di Google per aggiungere la sua pubblicità, presumibilmente effettuando uno spoofing di pacchetti con un proxy HTTP trasparente. Benché simili situazioni spesso derivino da adware, in questo caso Palmer ha verificato che il colpevole era l'ISP, che aveva installato un nuovo esemplare [instance] di Windows all'interno di una macchina virtuale (3).
IMPOSTAZIONI
1. Installare Wireshark
Scaricate una copia di Wireshark per la vostra piattaforma da tunnel o una regola del firewall, e senza dover utilizzare un proxy per connettersi (5).
Se utilizzate una connessione di rete aziendale/istituzionale con un firewall che non vi è consentito disattivare, potete ancora effettuare questi test, ma ogni spoofing di pacchetti che individuate può essere il risultato del firewall della vostra azienda anziché della sua connessione a monte con l'ISP. Come avremo modo di dire, l'osservazione dello spoofing di pacchetti mostra che qualcuno lo sta operando, ma non rivela chi. Noi vogliamo ridurre il numero di possibili responsabili per tale fenomeno.
Perciò, prima di cominciare il test, disabilitate tutti i firewall e i NAT disposti tra il vostro computer e Internet - anche i software o i firewall "personali" che girano sul vostro PC e le funzioni di firewall dei vostri router. In alternativa a questi dispositivi, connettete il computer a un nodo della rete localizzato al di fuori di qualsiasi firewall o router NAT (connettendolo, per esempio, direttamente a un modem a cavo o a un modem DSL). Alcune strutture di rete e certi documenti chiamano questo tipo di localizzazione DMZ.
3. Se possibile, disabilitate l'offload del checksum TCP e UDP e l'offload di segmentazione TCP
L'offload di checksum (a volte chiamato «TCP checksum offloading», benché possano essere offloadati anche i checksum UDP) è una caratteristica di alcune schede Ethernet di nuovo tipo - in particolare di quelle con velocità di trasferimento nell'ordine dei Gigabit per secondo - che consente alla scheda di ricostruire porzioni di alcuni pacchetti di rete sull'hardware, togliendo un po' di carico alla CPU.
Tuttavia, l'uso di questa funzione rende l'intercettamento dei pacchetti inaccurato perché impedisce al sistema operativo locale di "vedere" cosa è stato effettivamente trasmesso. Ciò può provocare una discrepanza, dal momento che uno dei nodi terminali pensa erroneamente di avere inviato qualcosa di leggermente diverso da quello che l'altro nodo ha correttamente ricevuto; la risultante discordanza dei valori di checksum TCP o UDP potrebbe essere erroneamente interpretata come una manomissione da parte dell'ISP, ma gli ISP non dovrebbero poter alterare questi valori.
L'offload di checksum dovrebbe essere, se possibile, disabilitato in entrambi i capi della connessione prima di cominciare l'esperimento. Se sapete che la vostra scheda Ethernet non supporta questa funzione, ovviamente non avete bisogno di disabilitarla. È anche possibile ottenere risultati validi quando l'offload di checksum è abilitato: gli accorgimenti da operare saranno descritti in seguito.
Ecco come normalmente si disabilita l'offload di checksum su parecchi sistemi operativi popolari:
Su Linux (root)
ethtool -K eth0 rx off tx off (inserite la corretta interfaccia di rete, se non è eth0)
Su FreeBSD (root)
ifconfig em0 -rcxsum -tcxsum (inserite la corretta interfaccia di rete, se non è em0)
Su MacOS (root)
sysctl -w net.link.ether.inet.apple_hwcksum_tx=0
sysctl -w net.link.ether.inet.apple_hwcksum_rx=0 (Si noti che questo può far sì che alcune applicazioni locali non funzionino correttamente)
Su Windows (root)
Cliccate su Pannello di controllo, poi selezionate Connessioni di rete --> (selezionate la vostra connessione di rete) --> Proprietà --> Avanzate --> disabilitate l'offload del checksum, se l'opzione è presente.
Per ulteriori dettagli sull'offload del checksum e sui motivi per cui può generare errori nell'intercettazione di pacchetti, si vedano http://www.wireshark.org/docs/wsug_h...Checksums.html e http://www.wireshark.org/faq.html#q11.1.
Si noti che l'approccio suggerito in questi articoli (ossia disabilitare la verifica del checksum TCP) non serve a granché sotto Wireshark, visto che intendiamo confrontare pacchetti; avere valori di checksum TCP diversi nei file di intercettamento sembrerà ancora suggerire una discrepanza tra quei file, anche se i valori di checksum non verranno mai verificati.
Se il vostro sistema effettua l'offload del checksum e non riuscite a disabilitarlo, è possibile affidarsi ad altre soluzioni. Il programma pcapdiff che descriveremo vi consente di ignorare del tutto i valori di checksum TCP e UDP, nel caso in cui abbiate motivo di ritenere che l'offload del checksum è operativo. Potete anche effettuare l'intercettazione su un'altra macchina, diversa dal computer che genera il traffico per compiere il test - a patto che essa sia connessa alla stessa rete di area locale e possa "vedere" il traffico che passa. In questo caso, l'intercettazione andrebbe effettuata in modalità «promiscuous». Su una rete usata da più persone, dovreste stare ancora più attenti ad evitare di intercettare le comunicazioni di altri utenti a loro insaputa.
Un'altra forma di offload che può provocare una scarsa accuratezza nell'intercettazione di pacchetti è l'offload di segmentazione TCP, noto anche come offload di segmenti estesi. Nell'offload di segmentazione TCP, una scheda Ethernet - anziché il software del sistema operativo - spezza un pacchetto TCP di grandi dimensioni in più pacchetti. Questo processo può provocare una sensibile discrepanza tra il numero di pacchetti che un host crede di aver trasmesso e il numero di pacchetti che ha effettivamente trasmesso; dal momento che i pacchetti vengono spezzati dalla scheda Ethernet senza che l'operazione sia visibile al sistema operativo del mittente, ogni pacchetto TCP sufficientemente esteso da essere spezzettato può sembrare "contraffatto" [forged], poiché il mittente non avrà alcuna registrazione relativa all'invio di uno qualsiasi dei pacchetti ricevuti nella forma in cui sono stati ricevuti. Anche l'offload di segmentazione TCP andrebbe disabilitato, se il vostro sistema ne fa uso. Pcapdiff, per esempio, non riesce a ignorare le discrepanze dovute alla segmentazione TCP in maniera altrettanto valida rispetto alle discordanze dei valori dei checksum TCP e UDP. Si consulti la pagina http://www.inliniac.net/blog/2007/04/20/sn...offloading.html per avere un'idea delle conseguenze sull'intercettazione di pacchetti dell'offload di segmentazione TCP, e per ottenere informazioni sul modo di disabilitare questa funzione su Linux. In generale, la validità dei risultati degli esperimenti di intercettazione pacchetti migliora quando le funzioni di offload presenti sul sistema vengono disabilitate.
4. Determinate l'indirizzo IP locale
Determinate l'indirizzo IP del vostro computer. Potete ottenerlo localmente dai tool di configurazione della rete del vostro computer, oppure da un sito web come http://whatismyipaddress.com/ o http://www.whatismyip.com/, che mostra l'indirizzo IP dal quale si accede ad esso. Usate entrambi i metodi per assicurarvi di essere davvero connessi direttamente a Internet (quindi, di non usare un server proxy o una connessione NAT: se non state utilizzando un NAT, l'indirizzo IP trovato localmente sul vostro computer dovrebbe essere identico all'IP visto dai siti web e da altri utenti internet. Se non sono gli stessi, è possibile che l'ISP o la vostra rete istituzionale stia forzando tutti gli utenti a utilizzare un NAT o un proxy, anziché fornire accesso diretto a Internet.)
Da adesso, supporremo che il vostro indirizzo IP sia 12.13.14.15 e che l'indirizzo della persona all'altro capo della connessione sia 4.8.16.32. Ovviamente, dovreste sostituire questi indirizzi-prova con gli IP effettivi coinvolti nel test (6).
5. Confermate l'indirizzo IP e testate la connettività
Per assicurare che sia voi sia la persona all'altro capo della connessione avete individuato correttamente gli indirizzi IP, cercate di effettuare qualche operazione che vi consenta di comunicare l'un con l'altro specificando i reciproci indirizzi IP. Potreste usare il comando ping o provare la stessa applicazione che alla fine avete scelto di sottoporre al test, come un client di file-sharing P2P o un'applicazione VoIP. Se non riuscirete a stabilire una comunicazione nodo-a-nodo [end-to-end] usando gli indirizzi IP che avete individuato, dovrete risolvere questo problema prima di andare avanti. Tra le possibili cause dei problemi di connessione c'è la presenza di un firewall che non è stato ancora disattivato a uno dei nodi.
6. Sincronizzate l'orologio del computer
Se col vostro sistema operativo è possibile, assicuratevi che l'orologio del vostro computer sia sincronizzato con un server temporale di rete Network Time Protocol (NTP) autorevole, per far sì che i dati e gli orari registrati nell'intercettazione pacchetti siano accurati e corrispondano a quelli registrati dall'altro computer. Questo contribuirà a rendere il confronto tra risultati o righe di log di diversi computer più facile.
IL TEST
Avviate Wireshark (con privilegi da amministratore di macchina - root privileges - sufficienti ad effettuare un'approssimativa intercettazione di pacchetti (7)). Selezionate Interfaces dal menù Capture. Scegliete l'interfaccia corrispondente al dispositivo di rete che userete per intercettare pacchetti: sono mostrati gli indirizzi IP connessi a tutte le interfacce di rete disponibili; questo può aiutarvi a distinguerle se non siete sicuri dell'interfaccia di rete che fa al vostro caso. Cliccate sul bottone Options per l'interfaccia corretta.
Nella finestra di dialogo Capture Options, assicuratevi che l'indirizzo IP che voi pensate il vostro computer stia usando compaia nel campo IP address. Suggeriamo di impostare un filtro di intercettazione per assicurare che solo i pacchetti in transito al o dall'altro computer saranno catturati. Se l'indirizzo IP dell'altro computer è 4.8.16.32, una buona stringa per filtrare l'intercettazione di pacchetti è host 4.8.16.32. Raccomandiamo anche di selezionare le impostazioni Update list of packets in real time e Automatic scrolling in live capture, che vi consentono di osservare l'intercettazione dei pacchetti durante il processo, in tempo reale, a meno che il vostro computer non sia troppo lento.
QUando siete pronti a cominciare la cattura di pacchetti, cliccate sul bottone Start. Se avete impostato un filtro per limitare l'intercettazione al traffico diretto al o dall'altro computer, probabilmente non vedrete apparire alcun pacchetto fin quando non genererete volontariamente traffico tra i due computer.
Per avere la certezza che il traffico venga visualizzato, dovreste assicurarvi che le intercettazioni di pacchetti operate da Wireshark siano in corso su entrambi i nodi, e poi fare in modo che un computer "pinghi" l'indirizzo IP dell'altro. Questo genera un flusso costante di pacchetti di ICMP echo request ed echo reply. Gli attuali sistemi operativi Unix, Windows e MacOS vi consentono di avviare il processo di ping digitando ping 4.8.16.32 sul prompt dei comandi. (Su alcuni sistemi, il ping si fermerà automaticamente dopo un periodo predeterminato; su altri, potete interromperlo premendo Ctrl+C.)
Se entrambi i capi della connessione stanno intercettando dati, i pacchetti ICMP che rappresentano le richieste e le risposte ping dovrebbero apparire nella finestra di Wireshark su entrambi i terminali. Questi pacchetti dovrebbero essere identici sul layer IP e - a meno che non sia la stessa utility di ping a riportare perdita di pacchetti - entrambi i nodi dovrebbero "vedere" un numero identico di pacchetti. Questo test mostrerà se il processo di intercettazione è configurato correttamente e funziona.
Qui vediamo come il processo di intercettazione sembra, su entrambi i nodi, eseguire un gran numero di richieste ping da 12.13.14.15 a 4.8.16.32. I pacchetti mostrati hanno una concordanza di uno a uno (come si potrebbe verificare guardando il contenuto dei pacchetti in maniera più attenta di quanto non facciamo noi adesso); non ci sono pacchetti persi né pacchetti falsati.
(Ovviamente, non è possibile ottenere una schermata relativa ad entrambi i nodi in tempo reale; questo screen shot è stato creato dopo il test, copiando un file d'intercettazione memorizzato da un computer all'altro. Durante il processo di cattura, ogni parte vede solo una delle due finestre mostrate sopra; per verificare durante il processo che le intercettazioni di pacchetti corrispondono, dovrete usare altri mezzi di comunicazione per parlare alla persona che sta all'altro capo della connessione, tipo un telefono o un'applicazione di instant messaging. Utilizzerete questo canale per coordinare queste attività e per confrontare le impressioni).
Una volta sicuri che entrambi i computer comunicano su Internet in modo corretto e che memorizzano una traccia pacchetto valida, potete cominciare a raccogliere dati sperimentali su una qualsiasi applicazione di vostro interesse - o provare a riprodurre problemi ed errori segnalati o ipotizzati. Pe esempio: per i nostri test con Comcast, abbiamo configurato uno dei computer come tracker e seeder BitTorrent e abbiamo dato all'altro computer un file BitTorrent contenente l'istruzione per far scaricare a questo computer il file ospitato dal primo elaboratore.
I dettagli di quello che testerete dipendono da quello che vi interessa e richiederanno una particolare familiarità con l'applicazione sulla quale volete effettuare il test. (Nell'esempio di BitTorrent, non è sufficiente far partire su entrambi i nodi della connessione BitTorrent nello stesso momento; piuttosto, un computer deve essere configurato esplicitamente per offrire un download all'altro computer il quale, a sua volta, deve essere configurato per richiedere un download da quel computer).
Quando il vostro esperimento sarà completato, dovreste fermare l'intercettazione e memorizzare i file di cattura risultanti su disco. Potete, poi, scambiare questi file con la persona corrispondente all'altro nodo - tramite e-mail, per esempio. Wireshark può essere usato per aprire e leggere un file d'intercettazione memorizzato generato su un altro computer.
Ci sono molti altri analizzatori di rete o intercettatori di pacchetti che potrebbero essere usati al posto di Wireshark. Noi abbiamo scelto di parlare di Wireshark perché è efficace, user friendly, open source e disponibile per parecchie piattaforme. L'importante è che l'analizzatore di rete che usate memorizzi le sue tracce pacchetto anche in formato pcap, in modo che esse possano essere lette da un'ampia gamma di software, compreso Wireshark.
Sicché, possono essere ottenuti risultati significativi e confrontabili anche usando altri software. Se intercettate pacchetti con un dispositivo sul quale non è possibile far girare Wireshark - come un server accessibile da remoto in una facility di co-locazione senza interfaccia grafica - dovreste prendere in considerazione il programma tcpdump, di serie su parecchi sistemi operativi di tipo Unix e disponibile su http://www.tcpdump.org/.
È importante essere a conoscenza del fatto che alcuni analizzatori di rete catturano, di default, solo una porzione di ogni pacchetto. L'opzione di Wireshark Limit each packet to 68 bytes (limita i pacchetti a 68 byte) che si vede in uno degli screeshot presentati sopra è (opportunamente) disabilitata di default, ma la corrispondente opzione in altri programmi analoghi potrebbe essere (non opportunamente) abilitata di default. Per confrontare sensatamente le tracce di pacchetto risultanti, il limite di dimensione dei pacchetti dovrebbe essere impostato sul valore più alto possibile (solitamente 65535 bytes) o disabilitato tout-court. Per esempio: se si usa la utility tcpdump, una riga di comando appropriata potrebbe essere
tcpdump -v -s 0 -w packet-trace.pcap
L'impostazione -s 0 predispone il limite di dimensione dei pacchetti su "illimitato" anziché sul default di 68 bytes. (Quando si fa girare tcpdump su un computer con diverse interfacce di rete, può anche essere necessario specificare un'interfaccia di rete con l'opzione -i).
INTERPRETARE I RISULTATI
Come abbiamo già detto, i file di tracciamento dei pacchetti generati su macchine diverse comunicanti in maniera diretta possono essere confrontate per vedere se i pacchetti inviati da uno dei computer corrispondono ai pacchetti ricevuti dall'altro computer. Dal momento che un semplice trasferimento di file o una conversazione VoIP potrebbe generare migliaia di pacchetti, la mancanza di strumenti che operino automaticamente questo confronto può rendere il processo davvero noioso.
Siamo disposti a collaborare con altre parti interessate per produrre tool del genere nel futuro prossimo, consentendo un'analisi rapida di insiemi di dati passibili di spoofing molto più estesi, anche di dati dove non si sospetterebbe spoofing. Ecco alcune indicazioni per confrontare le tracce di pacchetti a mano:
I pacchetti manomessi possono corrispondere a errori di protocollo o a forti ritardi registrati od osservati in software applicativi; per esempio, se un programma client dà errori del tipo "Connection reset by peer", "Connection closed by foreign host", "Lost connection", ecc. ecc., oppure il flusso dei dati improvvisamente crolla, è possibile che ci sia stato uno spoofing di pacchetti. Annotare i momenti in cui sono capitati errori sospetti può fornire un modo per orientarsi nella ricerca dei pacchetti manomessi in una file di tracciamento.
I pacchetti manomessi usati per disturbare le connessioni sono spesso segmenti TCP con flag FIN o RST (noti anche come «pacchetti FIN» e «pacchetti RST»); ciascuna di queste flag indica che un computer non vuole continuare una conversazione TCP. Wireshark può essere configurato per colorare in modo diverso questi pacchetti, in modo da metterli in evidenza.
Tenete presente che ci sono anche usi legittimi per i pacchetti FIN e RST negli standard TCP e che è solo la presenza di pacchetti FIN o RST manomessi ad essere sospetta, non la presenza di quei pacchetti in generale. (Un software client o un bug del firewall, per esempio, potrebbero causare la disconnessione prematura di un nodo - ma questa non è colpa dell'ISP!)
Se un problema che avete riscontrato è diffuso, qualcuno può aver già pubblicato notizie sui tempi e sulle circostanze in cui possono apparire pacchetti contraffatti; voi potete consultare i dettagli delle analisi di altre persone per vedere se potete confermare quelle notizie.
Tralasciando la possibilità della frammentazione, abbiamo spiegato che un pacchetto si dice manomesso [spoofed] quando esso è ricevuto da un computer ma non è stato trasmesso dall'altro computer. Prima che comincino i pacchetti RST (il numero di pacchetto 2338 nell'intercettazione locale e il numero 2549 in quella remota (8)), i pacchetti ricevuti e trasmessi si corrispondono (benché compaiano in ordini abbastanza diversi)(9). Quando cominciano i pacchetti RST, possiamo notare un gran numero di pacchetti ricevuti da ogni nodo che non corrispondono ai pacchetti trasmessi dall'altro nodo. Possiamo verificare ciò guardando il dettaglio del contenuto di questi pacchetti (per esempio: i loro numeri di sequenza, mostrati da Wireshark come Seq=nnnnn), anche se in questo caso basta semplicemente contarli.
La macchina locale, quella con l'indirizzo IP 12.13.14.15, riportava di aver trasmesso un totale di cinque pacchetti RST alla macchina remota con indirizzo 4.8.16.32 (i pacchetti numero 2340, 2342, 2346, 2350 e 2354), mentre riportava di aver ricevuto tredici di questi pacchetti da 4.8.16.32 (quelli con numero 2338, 2339, 2343, 2344, 2347, 2348, 2351, 2352, 2355, 2356, 2357, 2358 e 2359). La macchina remota (4.8.16.32 riportava di aver trasmesso solo un pacchetto RST (il numero 2560) e credeva di aver ricevuto 17 pacchetti RST da 12.13.14.15 (2549, 2550, 2551, 2552, 2553, 2554, 2555, 2556, 2557, 2558, 2561, 2562, 2563, 2564, 2565, 2566, 2567). Evidentemente, molti dei pacchetti RST ricevuti da ciascuna delle due macchine non avevano avuto effettivamente origine dall'altra (10).
L'azione dei pacchetti RST in questo caso ha fatto terminare la sessione di BitTorrent: questa non si è riavviata se non quattro minuti e mezzo dopo. (Viene stabilita una nuova sessione TCP, coi caratteristici pacchetti SYN e SYN/ACK che nel file di tracciamento della macchina locale corrispondono ai numeri 2446 e 2447 (2578 e 2579 nella macchina remota)
Wireshark offre la possibilità di vedere non solo un sommario elenco di pacchetti come quelli mostrati sopra, ma anche la sequenza di byte che costituisce ogni singolo pacchetto e una sezione che mostra cosa significa effettivamente il contenuto di un pacchetto dal punto di vista di vari livelli del protocollo Internet. Un'attenta analisi di questa prova potrebbe implicare un confronto byte-per-byte, pacchetto-per-pacchetto per determinare esattamente quali pacchetti sono stati manomessi. Se ci si decide ad eseguire un confroto del genere, è importante tenere a mente che Wireshark intercetta più dei semplici pacchetti IP che vengono trasmessi su Internet; solitamente ogni pacchetto IP è, infatti, "catturato" avvolto dentro un header di livello-link (spesso chiamato «header di struttura Ethernet» o «header di pacchetto Ethernet», se si tratta di una rete di tipo Ethernet - una rete Ethernet cablata, o una rete wifi).
Gli header di livello-link sono usati per comunicare tra computer della stessa rete Ethernet locale, e sono messi da parte e rigenerati ogni volta che un pacchetto viene inoltrato tramite un router. Sicché, non c'è motivo per aspettarsi che gli header di livello-link appartenenti a due tracce di pacchetti corrispondano, a meno che quelle tracce non siano state intercettate sulla stessa rete fisica di area locale. Quando si effettua manualmente un dettagliato confronto tra pacchetti, questi ultimi dovrebbero essere considerati "gli stessi" se gli header IP e il payload coincidono; gli header di livello-link possono essere semplicemente ignorati perché non sono mai stati inoltrati su Internet.
C'è da aspettarsi anche una serie di discrepanze tra gli header IP; per esempio, il valore espresso nel campo Time-To-Live (TTL) dovrebbe diminuire in base ad ogni router che inoltra un pacchetto, sicché il TTL, quando viene ricevuto un pacchetto, dovrebbe sempre essere più piccolo del TTL originario, quando è stato trasmesso. Analogamente, il campo IP checksum, che indica se gli header IP di un pacchetto sono stati trasmessi senza errori, deve essere ricalcolato ogni volta che il pacchetto viene inoltrato, visto che il valore di TTL è cambiato. Ci sono anche altre circostanze in cui i router dell'ISP possono, coerentemente con gli standard del protocollo Internet, alterare legittimamente altri campi negli header IP (11).
Nel modo attuale di concepire Internet, ci sono solitamente parecchi ISP che inoltrano pacchetti dalla loro origine alla loro destinazione. Da un punto di vista strettamente tecnico, ciascuno di questi ISP ha la possibilità di manomettere (o far perdere) pacchetti. L'individuazione di pacchetti manomessi, quindi, non rivela direttamente o definitivamente quale ISP è stato responsabile della loro immissione. Per scoprire quali ISP sono stati coinvolti nell'inoltro di pacchetti da un computer all'altro, si può usare il traceroute, uno dei suoi discendenti o una sua variante. (Su Unix e MacOS, la versione a riga di comando di questo tool è generalmente chiamata «traceroute»; su Windows, è nota come tracert). Inserite il nome o l'indirizzo IP di un host, e questo tool determinerà sperimentalmente il percorso probabilmente seguito da dei pacchetti di prova, mostrando una lista dei router che si trovano tra il computer locale e il computer-"bersaglio". Per stabilire quale ISP è responsabile dello spoofing dei pacchetti, si potrebbero provare dei test con un'ampia gamma di ISP, allo scopo di determinare se gli utenti di un ISP sono più o meno frequentemente vittime dello spoofing; si potrebbe anche provare ad attivare una rete virtuale privata (VPN) per nascondere il traffico a un ISP locale... ma i dettagli di questo processo vanno al di là della portata di questo articolo.
USARE I FILE PCAP
Come abbiamo già detto, i file di intercettazione pacchetto prodotti da Wireshark e da molti altri programmi per l'analisi di rete sono normalmente in formato pcap (noto anche come libpcap o tcpdump). Questo formato è uno standard aperto ampiamente diffuso nei software per l'analisi delle reti. Se siete certi che un file o un insieme di file pcap da voi prodotti non contengano informazioni sensibili personali - rammentiamo che questo tipo di file può contenere, per default, una registrazione di tutta l'attività su Internet creata dal vostro computer durante l'intercettazione - potete condividere i file pcap con un ISP, a mo' di bollettino dei problemi o di richiesta di supporto, oppure pubblicarli su un blog o web site per documentare un problema di cui avete fatto esperienza. Questi file sono prove concrete e utili che possono aiutare persone tecnicamente informate a diagnosticare problemi di rete e a confermare che un problema come lo spoofing di pacchetti da parte di un ISP ci sia davvero.
La EFF sta sviluppando un tool chiamato pcapdiff per automatizzare il confronto di file di tracciamento pcap creati simultaneamente a ogni capo di una connessione. Questa automazione rende più facile individuare lo spoofing o la manomissione di pacchetti quando un utente non sa cosa cercare e potrebbe far diventare l'intero processo di confronto meno noioso (considerando che molte comunicazioni coinvolgono migliaia di pacchetti, o più, e che non tutti i tipi di alterazione avranno risultati di lettura relativamente chiara come l'immissione di TCP RST). Pcapdiff è una utility a riga di comando scritta in Python che, per funzionare, richiede esattamente due tracce pacchetti pcap; li confronta automaticamente per trovare discrepanze che indichino pacchetti persi o soggetti a spoofing. Potete scaricare il programma dalla pagina http://www.eff.org/testyourisp/pcapdiff. Il vostro computer deve avere già installato l'interprete Python (altrimenti potete trovarlo su http://www.python.org/).
Attualmente, pcapdiff richiede anche il modulo pcapy (http://oss.coresecurity.com/projects/pcapy.html) per leggere i file pcap; sono disponibili anche versioni binarie di questo modulo per Windows e Linux, ma esso deve essere compilato dal codice sorgente per MacOS. Le versioni future di pcapdiff potranno girare senza pcapy.
Pcapdiff si lancia dal prompt dei comandi: dovete specificare due file di tracciamento pcap e l'indirizzo IP locale del computer dove sono stati catturati. Oltre a produrre statistiche sui tassi complessivi di perdita e spoofing di pacchetti, pcapdiff produrrà una lista dei valori dei campi di identificazione IP di ciascun pacchetto. Ciò può aiutarvi a localizzare pacchetti "interessanti" in un programma come Wireshark molto più velocemente. Per esempio: se pcapdiff dice che un pacchetto con valore di identificazione IP 4321 è stato manomesso in direzione di uscita, potete inserire il filtro ip.id eq 4321 nel campo dei filtri di visualizzazione di Wireshark e vedere solo il pacchetto (o i pacchetti) con questo particolare valore d'identificazione IP. Generalmente, i valori d'identificazione IP individuano unicamente i pacchetti IP trasmessi da un particolare computer, anche se questi valori saranno ripetuti almeno ogni 65536 (2 ^16) pacchetti.
L'osservazione di un grandissimo numero di pacchetti alterati può suggerire che qualcosa vada sistematicamente per il verso sbagliato - per esempio: può capitare che abbiate cominciato o finito le intercettazioni a orari diversi (così, una macchina non ha registrato di aver inviato molti dei pacchetti che ha, di fatto, inviato); che abbiate limitato il numero di byte intercettati per pacchetto a un nodo ma non all'altro; che abbiate qualche offload di protocollo attivo su un nodo (e questo significa che il sistema operativo di un computer non è preciso sul contenuto dei pacchetti che la scheda di rete ha effettivamente inviato via cavo); che abbiate ancora un dispositivo NAT o un firewall attivato a un capo della connessione; oppure che il vostro ISP contraffaccia o alteri i pacchetti meccanicamente, forse con una tecnica come i proxy HTTP trasparenti, invisibili alla maggior parte dei software applicativi.
È importante pensare in maniera critica al significato delle prove e alla possibilità che i risultati siano riproducibili o attribuibili a fattori di turbamento. Pcapdiff e le tecniche descritte in questo articolo sono stati creati per aiutare gli utenti a trovare discrepanze anomale tra pacchetti inviati e pacchetti ricevuti, non per trovare un colpevole definitivo per l'origine di queste anomalie.
PER APPROFONDIRE
Per una più profonda comprensione dei protocolli di rete e delle tracce dei pacchetti come quelle che abbiamo descritto, potete consultare i documenti sugli standard di Internet che specificano la suite di protocolli TCP/IP. La maggior parte di questi documenti è stata pubblicata nel bollettino RFC disponibile su http://www.rfc-editor.org/ e http://www.faqs.org/rfcs/. Per esempio, l'Internet Protocol (IP) è descritto in RFC 791, il Transmission Control Protocol (TCP) in RFC 793 e l'User Datagram Protocol (UDP) in RFC 768.
Un'eccellente guida ai protocolli TCP/IP è il libro di W. Richard Stevens, TCP/IP Illustrated: Volume 1, The Protocols (Reading, MA: Addison-Wesley, 1994), ISBN 0201633469. Stevens usa il tool tcpdump per produrre tracciamenti di pacchetti su reti connesse a Internet degli anni '90, e spiega con cura la teoria e la pratica della rete Internet, facendo riferimento a quelle tracce di pacchetti. FAre la stessa cosa con Wireshark oggi sarebbe più comprensibile, perché Wireshark ha un'interfaccia più intuitiva e una capacità di analisi del protocollo più estesa di tcpdump, ma le spiegazioni di Stevens sono chiare, minuziose e generalmente valide anche per l'Internet che conosciamo oggi.
--------------------------------------------------------------------------------
NOTE
(1) Se il vostro ISP stesse bloccando Google, potreste accorgervene nel momento in cui incontrate difficoltà a connettervi ai servizi di Google - potreste notare dei pacchetti chiaramente anomali in una traccia lasciata dai pacchetti sul vostro terminale. Tuttavia, solo l'aggiunta di una registrazione della stessa interazione sul terminale di Google potrebbe stabilire con certezza se il problema è di Google o di un ISP che si intromette. Diversamente, è difficile dire se il problema è il risultato di una normale perdita di pacchetti, di un cattivo funzionamento dei computer di Google, oppure di un cattivo funzionamento di qualche software sul vostro stesso computer.
Esortiamo i lettori a interpretare con cautela i risultati dei loro test e ad evitare di saltare subito a conclusioni, lanciando accuse illegittime. Per esempio: i pacchetti RST fanno normalmente parte del protocollo TCP, e ricevere pacchetti di questo tipo non significa necessariamente che essi siano stati contraffatti da un intermediario. Lo spoofing di pacchetti RST packet può essere provato con certezza soltanto effettuando misurazioni simultanee ai punti terminali di una connessione. (Alcune forme di spoofing dei pacchetti potrebbero produrre prove significative anche considerando solo un terminale della comunicazione, perché i pacchetti contraffatti hanno proprietà anomale tali da rendere improbabile una loro trasmissione dall'alro terminale. Ma osservare queste anomalie di per sé forse non sarà decisivo, a meno che non si raccolgano prove relative anche all'altro capo della connessione)
Chiaramente sarebbe utile avere un affidabile mezzo automatico per testare i servizi non-P2P e rilevare interferenze o degradazioni di pacchetti operate dai provider. In alcuni casi ciò significherebbe semplicemente programmare un software dedicato, in altri casi - invece - sarebbe necessaria una coordinazione tra parti diverse (tipo Google). Per esempio, sarebbe utile sapere se i provider forniscono agli utenti connessioni con tempi di latenza inferiori per alcuni siti anziché per altri.
Poiché per questo tipo di test la co-operazione degli operatori web è necessaria, esso esula dallo scopo di questo articolo.
Un test, invece, che potrebbe essere effettuato rapidamente da due end user consiste nel vedere se scambiare lo stesso volume di dati su protocolli diversi (per esempio, mandando un singolo file da 1 megabyte tramite HTTP, FTP, BitTorrent, Gnutella, oppure mascherato da stream dati SIP VoIP) richiede porzioni di tempo significativamente diverse, e se il Round Trip Time per ciascuno di questi protocolli è lo stesso o no. Nel presente articolo non si parla di tool per automatizzare un test del genere. Si parla, invece, del nostro pcapdiff e si fa anche mensione del progetto di ricerca della University of Washington, basato sull'utilizzo di JavaScript per il rilevamento di alcune modifiche ai contenuti delle pagine web operate dagli ISP.
(2) Un utente internet ha configurato il suo gateway aperto wireless per modificare le immagini viste dagli utenti quando fanno ricerche sul web, rovesciandole specularmente od offuscandole. Vd èURL="http://www.ex-parrot.com/~pete/upside-down-ternet.html"]http://www.ex-parrot.com/~pete/upside-down-ternet.html[/url]. È facile dimenticarsi del fatto che gli intermediari, su Internet, possono cambiare arbitrariamente il modo in cui i loro utenti vedono Internet.
(3) Questa particolare pubblicità sembra esser stata aggiunta da AnchorFree, una delle molte aziende che sperimenta con i mezzi dell'ad placement (collocazione delle pubblicità); si veda la pagina web http://anchorfree.com/advertisers-agencies/how-it-works/. Si veda anche http://vancouver.cs.washington.edu/, dve si discute di un progetto di ricerca che analizza la prevalenza di questo fenomeno
(4) Se state facendo girare Wireshark sulla stessa macchina che sta generando o ricevendo il traffico di prova, come noi suggeriamo di fare, non avete bisogno di seguire le istruzioni aggiuntive presentate in http://www.wireshark.org/faq.html#promiscsniff, perché non vi servirà intercettare traffico in modalità "promiscuous".
Far girare Wireshark in modalità "promiscuous" su un'altra macchina nello stesso segmento di rete dell'area locale (attenzione: non su uno switch Ethernet) potrebbe, tuttavia, contribuire a rintuzzare i problemi relativi all'eccessivo carico della CPU; all'indisponibilità di Wireshark o di un driver per l'intercettazione di pacchetti adatto a un particolare sistema operativo o a un particolare dispositivo; all'offload del checksum del TCP o dell'UDP; o alla necessità di loggarsi a un server remoto con mezzi quali SSH allo scopo di effettuare test sulle comunicazioi di quel server col vostro client. In questo caso, la macchina che intercetta pacchetti non è la stessa macchina che li genera; nondimeno, la traccia-pacchetto risultante può generalmente essere usata allo stesso modo di una traccia-pacchetto intercettata direttamente dalla macchina che ha generato i pacchetti, fin quando la LAN cui le macchine sono connesse trasmette tutti i pacchetti alla macchina intercetta-pacchetti.
Ci sono anche tecniche per intercettare il traffico su reti LAN commutate senza trasmissione [non-broadcast switched LANs], ma non sono pertinenti all'oggetto del nostro articolo.
Per far girare Wireshark su MacOS X, c'è bisogno di X11; ci sono altri intercettatori di pacchetti nativi pcap-compatibili per MacOS X.
(5) I dispositivi NAT e i firewall creano incertezza perché, normalmente, riscrivono, sopprimono oppure bloccano il traffico; se essi non saranno disabilitati, sarà difficile provare che le comunicazioni risultanti in pacchetti bloccati o alterati siano state manipolate da un ISP anziché da un firewall.
I NAT e i proxy impediscono anche il diretto confronto pacchetto per pacchetto delle tracce di pacchetti, perché i nodi terminali non hanno una visione coerente degli indirizzi di partenza e di destinazione relativi alla comunicazione, e può perfino non esserci un rapporto uno-a-uno tra i pacchetti che entrano in un NAT o in un proxy e quelli che ne escono.
Le prove di manomissione pacchetti da parte di terzi raccolte in presenza di uno di questi dispositivi sono meglio della mancanza di prove, certo, ma devono essere interpretate con estrema cautela.
(6) Se il vostro indirizzo IP appare in un range di indirizzi privati definito da RFC 1918 (10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255, oppure da 192.168.0.0 - 192.168.255.255), non avete seguito correttamente le istruzioni per disabilitare i firewall e i dispositivi NAT (oppure il vostro ISP sta costringendo tutti a usare il suo stesso servizio NAT).
(7) Gli utenti Windows possono usare il driver NPF per operare un'intercettazione di pacchetti anche come utenti senza privilegi
(8) In questo contesto, «numero di pacchetto» si riferisce al numero ordinale del pacchetto all'interno di un particolare file di tracciamento, numero che è mostrato da Wireshark nella colonna a sinistra; il primo pacchetto inviato o ricevuto è il numero 1, il successivo è il numero 2, e così via. Ci sono anche altre forme di numerazione seriale contenute all'interno degli stessi pacchetti, come il campo di identificazione IP e il numero di sequenza TCP. Pcapdiff usa il campo di identificazione IP (che Wireshark chiama ip.id) per riferirsi ai pacchetti, ma in questo paragrafo parliamo soltanto dei numeri ordinali dei pacchetti mostrati da Wireshark. In questo senso, «pacchetto numero 2340» non ha bisogno di avere 2340 come valore di identificazione IP.
(9) Questa diversa ordinazione non ha a che fare necessariamente solo con il riordinamento dei pacchetti effettuato dall'ISP, ma anche con l'esistenza di una latenza di rete; se entrambi i computer trasmettono un pachetto, a mezzogiorno, su una rete con tempo di latenza di un secondo, ciascuno dei computer riceverà le trasmissioni dell'altro computer alle 12:00:01 e considererà la propria trasmissione come avvenuta "prima".
(10) A rendere ancor più sospetta la situazione, ogni macchina credeva di non essere la prima a inviare un pacchetto RST in questa trasazione - sia la macchina locale sia quella remota credevano che fosse stata l'altra parte a iniziare il processo di disconnessione dalla comunicazione. Nel protocollo TCP può capitare normalmente di inviare un RST in risposta a un RST, e questa traccia suggerisce che ciascuna macchina credesse di fare proprio questo: disconnettersi solo dopo che l'altra parte si era già disconnessa.
(11) Potremmo, con una buona dose di approssimazione, paragonare questo comportamento a quello dell'ufficio postale quando si spedisce una lettera: l'ufficio postale può mettervi un timbro postale o stampare un codice a barre sulla busta, attaccarvi note relative alla spedizione o perfino correggere un codice postale sbagliato. Tuttavia, l'ufficio postale non dovrebbe alterare il contenuto delle lettere.
.