Lo strato applicativo di Internet
Trattiamo ora di alcuni strumenti utili per verificare la corretta configurazione degli host sia nella nostra rete, che remoti, e che possono aiutare di molto il compito di diagnosticare malfuzionamenti e problemi, investigare sulle possibili soluzioni, e svelare chi contattare.
Quando in un computer, abbiamo configurato
non ci resta che verificare se possiamo collegarci o meno. Per questo possiamo fare uso del programma ping (man page), che invia dei pacchetti ICMP echo, ne riceve la risposta, e ci informa del ritardo intercorso. Può essere usato per
Analizzando questo capture, possiamo verificare il traffico prodotto durante l'esecuzione di un ping.
Ora, sperimentiamo gli strumenti per la scoperta dei servizi attivi su uno o più computer della nostra rete.
L'intrusion detection è un aspetto di Network Security spesso trascurato dagli amministratori di rete (ammesso che, nelle piccole realtà, siano previsti), almeno finchè non si è oggetto di un serio attacco informatico. L'approfondimento della questione non è tra gli scopi di questo corso; ci limitiamo quindi ad indicare in Nessus uno degli applicativi più usati a questo scopo. Analizziamo invece ora una serie di strumenti più di base, ma che potremmo definire indispensabili.
Mentre con il comando ps possiamo scoprire quali programmi sono in esecuzione presso il nostro computer, ma non cosa fanno, il comando
| netstat -n --udp --tcp -p -l |
ci mostra su quali numeri di porta (-n) udp e tcp ci sono programmi in ascolto (-l), indicando il PID ed il nome del programma (-p) che ha aperto il socket. Per lo stesso comando, sono possibili diverse combinazioni di opzioni, in grado di mostrare anche i socket non in ascolto (omettendo -l), mostrando il relativo stato, o di mostrare i socket unix, oppure ancora di mostrare le informazioni di instradamento (netstat -r)
L'opzione -p di netstat, che ci mostra PID e nome del programma connesso al socket, è di introduzione recente, per la sola architettura Linux; altrimenti, una volta noto un numero di porta, si può ricorrere al comando
| fuser -n tcp -v numero_di_porta |
che ci mostra il nome del programma che sta usando il numero di porta specificato. Anche in questo caso, le opzioni della chiamata possono variare: ad es. l'opzione -n udp ci permette di interrogare il namespace udp, o (-n file) quello dei descrittori di file.
Dopo aver investigato il proprio computer, può venire la voglia di curiosare in quello degli altri, e questo può essere fatto analizzando il tipo di risposta che il kernel invia, nel caso in cui presso una certa porta, ci sia un programma in ascolto o meno. Si badi che questo tipo di analisi non rappresenta necessariamente una azione di attacco, anzi, al contrario, permette ad un amministratore di verificare lo stato di salute (o di compromissione) delle macchine della propria rete.
Ad esempio se un virus
ha infettato un computer, può mettersi in ascolto su di una porta non
prevista, permettendo ad un attaccante di conettercisi, ed eseguire
azioni da remoto. Per questo, un amministratore che voglia proteggere
le proprie macchine da sguardi indiscreti,
provvederà senz'altro a configurare un firewall
che ne impedisca la raggiungibilità.
Un modo semplice di verificare su quali porte di un computer terzo vi siamo programmi in ascolto, ci viene offerto dal programma nmap (sito, man in italiano), che è eseguibile anche per mezzo del suo front-end grafico Zenmap, (precedentemente chiamato nmapfe). Zenmap ha l'aspetto mostrato sotto, in cui è evidenziato il campo Target in cui inserire l'indirizzo del computer da esaminare, ed il campo Profile che determina il tipo di analisi da effettuare; quindi, nella finestrella Command è mostrato il risultato, ovvero le opzioni con cui il comando nmap sarà effettivamente invocato.
Al momento della scrittura di questo testo, la versione di
sviluppo
(4.85) di Zenmap contiene già caratteristiche molto più avanzate di
quelle presenti nella versione (4.62) presente nella distribuzione
Linux Ubuntu 8.10 in uso, quindi si preferisce non entrare nella
descrizione dei suoi dettagli, e limitare i commenti a solo
alcune delle possibili opzioni con le quali invocare nmap,
mediante il formato generale
| nmap [Tipo di scan] [Opzioni] {specifica del target} |
rimandando alla guida di riferimento per la descrizione competa delle possibilità di utilizzo.
L'opzione -s permette di specificare uno tra diversi Tipi di scan capaci utilizzare tecniche diverse per investigare a riguardo degli host target, e di seguito se ne descrivono le principali:
Nella stessa invocazione di nmap, possono essere contemporaneamente specificati più tipi di scan.
A parte il caso di Ping Sweep, in cui l'intenzione è quella di determinare se un computer remoto è in rete o meno, negli altri casi lo scan è orientato alla scoperta dei servizi in esecuzione sul target, ed è possibile specificare l'intervallo delle porte da esaminare, potendo ad es. scegliere tra
Possiamo specificare
e nel secondo e terzo caso, lo scan sarà ripetuto per tutti gli host indicati.
In funzione della presenza o meno di un programa in ascolto sulle porte esplorate, e della presenza o meno di un firewall tra i due computer, lo stato della porta può essere classificato come
Proviamo a sperimentare l'uso di nmap, lasciando aperti sui nostri computer i programmi server (server, listener e selectserver) che ricordiamo, sono rispettivamente in ascolto sulle porte TCP 3490, UDP 4950 e TCP 9034.
Abbiamo parlato di come l'ICMP può essere usato dal programma traceroute
per scoprire, utilizzando dei time
to live via via crescenti, la sequenza dei router attraversati per
raggiungere una determinata destinazione. Questo capture
riporta il traffico prodotto durante l'esecuzione di un traceroute
indirizzato verso www.fasthit.net,
un service provider australiano.
Presso traceroute.org è possibile eseguire un traceroute che parte da svariate località del mondo, verso il nostro computer. Partiamo ad esempio dalla Cooperativa Telefonica Pinamar Ltda che si trova in Argentina, e
Qualora ci si trovi dietro un firewall che blocca i pacchetti ICMP, oppure se gli operatori di rete che gestiscono i router intermedi non generano, o bloccano, le risposte icmp time to live exceeded, possiamo provare ad usare
Presso cybergeography si trova una interessante rassegna di links a siti e strumenti che svolgono un compito simile, di cui alcuni sviluppati in java, alcuni non più raggiungibili, ed altri che integrano ulteriori funzionalità, come la ricerca whois. Un altro sito (Morgan) offre (oltre a diverse altre cose utili) un servizio di traceroute da loro verso di noi, senza mappatura geografica, ma con la visualizzazione del dove si generano i maggiori ritardi.
Come discusso altrove, il TCP fa del suo meglio per adeguare la finestra di trasmissione all'RTT stimato per l'instradamento IP tra sorgente e destinazione, in modo da massimizzare la velocità di trasmissione, altrimenti nota come throughput, che può quindi raggiungere un massimo teorico pari a
| Max. Throughput = TCP Window Size / Round-trip time |
Ad esempio, considerando che la massima ampiezza di finestra del TCP è pari a 65,535 bytes (a meno che non sia attiva l'opzione window scale), un instradamento con RTT di 220 msec permette di conseguire una velocità pari a 65535 bytes / 0.220 s = 297886.36 bytes/s = 2.38 Mbit/s. D'altro canto, non è affatto detto che tutti i singoli links attraversati possiedano una tale capacità, e dunque il throughput può essere inferiore.
In tal caso la strategia di controllo congestione del TCP impedisce alla finestra di trasmissione di aprirsi completamente, in quanto la coda di uscita del router connesso al link con capacità minore vincola il massimo ritmo a cui sono inviati i pacchetti, e di conseguenza quello dei rispettivi riscontri. Trasmettere a velocità maggiore causa presto una perdita di pacchetti in tale coda, facendo intervenire i meccanismi di controllo congestione.
L'unico modo per conoscerne il valore effettivo della velocità è di misurarlo, facendo uso di una coppia di programmi client-server posti ai due estremi del collegamento, che realizzano una connessione TCP greedy (letteralmente, avido), e che al tempo stesso valutano ad intervalli di tempo regolari la quantità di dati scambiati, e determinano sia la velocità media, sia come questa evolve nel tempo. Questo è l'approccio seguito da siti come Speedtest, che poi conserva i valori misurati presso Netindex permettendo interessanti confronti.
Allo scopo di sperimentare questo tipo di misura, scegliamo di usare iperf (wikipedia), e di operare il test su di un ambiente di rete simulato come quello offerto da netkit. Per questo, dopo aver inizializzato le variabili di ambiente, copiamo presso il nostro computer la configurazione posta nella directory /media/netkit/labs/labthru (versione on-line), e rendiamo eseguibile (se non lo è) il file iperf. Come possiamo osservare, si tratta di una unica LAN su cui si affacciano tre host, r1 r2 ed r3, con indirizzi IP rispettivamente pari a 30.0.0.1, 30.0.0.2, e 30.0.0.3. Nella stessa directory si trova anche il file eseguibile iperf, che può quindi essere invocato da parte delle VM come /hostlab/iperf, e infatti, nei file di startup delle tre VM sono presenti (oltre ai comandi per configurare le interfacce di rete) anche quelli per lanciare iperf, specificando gli opportuni parametri in modo che su r1 iperf operi in modo server
| /hostlab/iperf -s |
e su r2 e r3 in modo client
| /hostlab/iperf -c 30.0.0.1 -t 8 -i 1 |
Infine, mentre su r1 è anche lanciato tcpdump
| tcpdump -i any -s 0 -w /hosthome/cattura.pcap |
in modo da salvare il traffico osservato nel file cattura.pcap presso la home della macchina host, su r2 e r3 sono impostati degli intervalli di attesa in modo che il traffico generato sia in parte indipendente, ed in parte sovrapposto temporalmente.
Lanciamo le tre VM con il comando lstart -f, permettendo a queste (in virtù dell'opzione -f) di partire in contemporanea. Osserviamo l'evoluzione dei comandi nelle tre finestre terminali, ed al termine degli iperf client, prendiamo nota delle porte effimere da loro usate, e killiamo il tcpdump in esecuzione su r1.
Possiamo ora aprire il file cattura.pcap
con Wireshark (è grande!) e richiedere Statistics/IOGraph,
impostando quattro display filter come
mostrato a fianco con le porte effimere usate dai client, e ottenendo un
grafico mostrato sotto
A quanto pare, il throughput conseguito si arresta poco sotto al valore di 100 Mbit/sec, che potrebbe dipendere dalle limitazioni imposte dal virtualhub che interconnette le VM di Netkit. I client sono configurati per produrre 8 secondi di traffico, ma probabilmente per effetto dello slowstart del TCP, nei primi due secondi il throughput di r2 non raggiunge la velocità massima; per quanto riguarda r3 inoltre, anche se i suoi pacchetti dovrebbero iniziare attorno al terzo secondo, a quanto pare il traffico non inizia veramente finché non termina quello prodotto da r2, nei confronti del quale (a partire dal sesto secondo) opera addirittura una azione di contrasto. Questo fenomeno può essere interpretato considerando che, in presenza di un traffico molto elevato in una direzione del collegamento, anche gli ACK nella stessa direzione sono ostacolati e possono venir perduti, impedendo di fatto anche il traffico entrante.
Ripetiamo l'esperimento precedente utilizzando tre computer nella stessa LAN, di indirizzo 192.168.100.156, 157 e 234: sui primi due eseguiamo l'applicazione client, e sul terzo quella server, con le stesse opzioni prima indicate. Il risultato è salvato in questo nuovo file di capture (più di 130 MB) che analizzato con Wireshark, permette di visualizzare l'andamento
Osserviamo come al quarto secondo inizi il traffico proveniente dal
secondo computer (linea verde), entrando subito in competizione con quella
dal primo (linea rossa): come possiamo osservare, dopo una iniziale
oscillazione, la ripartizione della banda del collegamento tra i due
flussi non risulta equa. Dopo aver cliccato su di un pacchetto del primo
flusso, sperimentiamo l'opzione di wireshark Statistics/TCP stream
graph/Throughput Graph in modo da osservare l'evoluzione della
velocità; cliccando ora su di uno dei punti, possiamo posizionare l'elenco
dei pacchetti in corrispondenza del preciso pacchetto.
Proviamo ora ad analizzare ciò che avviene quando i due flussi iniziano a competere: al pacchetto 47247 osserviamo la notifica dell'evento TCP previouos segment lost, dedotto da Wireshark in quanto il numero di sequenza 47020233 non corrisponde al precendente più la dimensione del segmento MSS, pari a 47017337 + 1448 = 47018785. Il motivo della perdita risiede probabilmente nella coda FIFO della porta di uscita dello switch collegata all'iperf-server, che ora non è più in grado di smaltire il nuovo volume di traffico. La perdita determina gli ACK ripetuti osservabili ai pacchetti n. 47250, 47254, e 47257, e poi si assiste ad una sequanza di ben 155 ACK duplicati, arrivando al pacchetto n. 47805, poiché evidentemente sono stati nel frattempo ricevuti i pacchetti già presenti nella code di uscita. Finalmente al pacch. n. 47808 viene reinviato il segmento con n. di seq. 47018785, indicato come Fast retransmission. Da quel momento inizia una fase in cui gli ACK indicano i numeri di sequenza attesi, che quando ricevuti sono indicati da Wireshark come Out-Of-Order segment.
Potrebbe essere interessante sperimentare gli effetti di una limitazione della velocità di trasmissione, allo scopo di meglio simulare situazioni come ad es. il collegamento al proprio ISP via ADSL: purtroppo sembra che il kernel compilato per Netkit non comprenda i moduli che implementano le discipline di coda qdisc necessarie al comando tc. Neanche trickle, che offre un meccanismo di shaping operante in user space, sembra compilarsi correttamente in Netkit, e quindi forse l'ultima possibilità può essere quella di invocare l'opzione --limit-rate= del comando wget.
Per quanto riguarda gli indirizzi IP ed i numeri di sistema autonomo, questi sono registrati presso i Registri Internet Regionali (RIR): ce ne sono 5 nel mondo, dislocati nei continenti. Gli Internet Service Provider (ISP), a loro volta, si rivolgono ai RIR per vedersi assegnate risorse di questo tipo. In supporto all'ICANN, si è creato il Number Resource Organization (NRO) allo scopo di coordinare i cinque RIR.
E' un comando che si immette da tastiera sui sistemi Unix, che implementa il protocollo descritto dalla RFC 3912 operante via TCP su porta 43, e che permette di risalire alle informazioni riguardanti gli intestatari dei domini, degli indirizzi IP, e dei sistemi autonomi. In linea di principio, eseguendo whois per i router descritti da traceroute, potremmo risalire a tutte le organizzazioni da ringraziare per l'inoltro del nostro traffico Internet. Proviamo quindi ad iniziare questa ricerca, partendo dalla nostra rete locale.
Ma il comando whois effettua anche ricerche sui domini:
Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade
dietro le quinte di Internet, completo di cattura del traffico.
Scopri
come effettuare il download,
ricevere gli aggiornamenti,
e contribuire!
