Investigazioni di Rete

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.

Arrivo fin lì? Tu ci sei? Pronto?
Controllo delle intrusioni
- Esperimenti di portscan
Il percorso dei nostri pacchetti
A quanto vado?
- Esperimento Netkit
  - Traffic shaping
Chi è chi?
- Whois
Riferimenti

Arrivo fin lì? Tu ci sei? Pronto?

Quando in un computer, abbiamo configurato

l'indirizzo IP,
la network mask,
il default gateway, e
il DNS,

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

verificare il corretto funzionamento della nostra interfaccia di rete, dirigendo il ping verso noi stessi;
verificare la connessione alla rete locale, dirigendo il ping verso un computer con uguale prefisso di sottorete;
verificare il corretto instradamento verso il default gateway, dirigendo il ping verso un computer esterno alla LAN;
verificare la corretta configurazione del DNS, dirigendo il ping verso un nome di dominio.

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.

Controllo delle intrusioni

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.

Su quali porte stanno ascoltando, i miei servizi?

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)

Quale programma sta ascoltando su questa porta?

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.

Nmap e Zenmap

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, HowTo italiano, 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.

Tipo di scan

L'opzione -s permette di specificare uno tra diversi Tipi di scan (vedi anche) capaci utilizzare tecniche diverse per investigare a riguardo degli host target, e di seguito se ne descrivono le principali:

-sL: List scan - non invia nessun pacchetto verso il(i) taget, ma si limita a chiedere al DNS la risoluzione inversa dei loro indirizzi IP, realizzando così una lista di nomi di host, sia che siano effettivamente attivi, o spenti. Es.: nmap -sL 151.100.122.0/24;
-sP: Ping sweep - una passo in più rispetto al precedente, permette di stabilire quali host siano effettivamente presenti, inviando loro sia una richiesta ICMP echo, che un TCP SYN verso la porta 80. Es.: nmap -sP 192.168.100.0/24;
-sT: Connect Scan - tenta di eseguire il three way handshake del TCP in modo completo, indirizzando un nutrito inseme di porte di destinazione, e può essere eseguito anche da utenti non-root. Ha lo svantaggio che un processo applicativo che dovesse rispondere presso il target, può facilmente tenere traccia dell'avvenuto tentativo di connessione;
-sS: Syn-Scan - si limita ad inviare solo il primo pacchetto (SYN) dell'handshake, impiegando così meno tempo del precedente, e permette di rilevare la presenza o meno di un server in ascolto sulla porta di destinazione, in funzione del tipo di risposta (ACK, RST, ICMP, o... nulla); inoltre, non completando l'handshake, il kernel neanche notifica l'eventuale servizio in ascolto;
-sU: UDP Scan - per scoprire i servizi offerti via UDP, soffre della limitazione che l'assenza di una risposta può significare sia che non c'è nessun server in ascolto, sia che invece è presente un firewall che blocca la porta; inoltre, in assenza di firewall, le RFC IETF raccomandano di porre un limite al ritmo dell'invio di messaggi ICMP da parte del kernel, e dunque questo tipo di scan può richiedere tempi molto lunghi.

Nella stessa invocazione di nmap, possono essere contemporaneamente specificati più tipi di scan.

Intervallo delle porte

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

default - non specificando nulla, lo scan è diretto verso le prime 1024, più quelle elencate nel file /usr/share/nmap/nmap-services
un insieme esplicito - è specificato inserendo l'opzione -p seguita dalla descrizione dell'insieme, ad es. separate da vigole (25,80,110) oppure indicando un intervallo, individuato separandone i numeri con un trattino (es. 20-200);
ordine di scansione - aggiungendo l'opzione -r le porte vengono investigate in ordine crescente; al contrario, non specificando nulla, il loro ordine è casuale.

Indicazione del target

Possiamo specificare

un indirizzo IP singolo
un intervallo di indirizzi IP (es. 192.168.0.64-128)
una intera sottorete (es.192.168.0.0/24)

e nel secondo e terzo caso, lo scan sarà ripetuto per tutti gli host indicati.

Stato delle porte

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

open - la porta è aperta, c'è un programma in ascolto:
- ad es, il TCP-SYN produce un SYN-ACK di risposta, oppure un UDP non produce nulla
closed - la porta è chiusa, non c'è nessun socket in ascolto:
- ad es, TCP-SYN produce un RST, ed un UDP produce un ICMP port unreachable
filtered - la porta non esibisce il comportamento atteso per uno dei due casi precedenti, e questo è da imputare alla presenza di un firewall

Esperimenti di portscan

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.

Proviamo a dirigere un SYN Scan (opzione -sS) verso le porte 0-10000 di 127.0.0.1, ed impostando l'opzione (opzione -r) Ordered Ports. Riusciamo ad individuare i servizi attivi? ne troviamo aperti altri? Quali?
Durante lo scan, teniamo aperto Wireshark. Cosa accade ?
1. Se richiediamo che lo lo scan avvenga con porte ordinate, ci è facile individuare che al pacchetto 5700 si trova il SYN diretto verso la porta 3490, dove è in ascolto server, che a differenza delle altre porte, risponde SYN, ACK anziché RST, ACK, dopodiché nmap interrompe la connessione con un RST.
per scoprire i servizi offerti in UDP, selezioniamo UDP Port Scan (opzione -sU)
mediante wireshark, etherape, tcpdump, iptraf, scopriamo qualche altro computer nella nostra stessa rete, scegliamone uno, e ripetiamo lo scan. Quali sono i servizi che troviamo attivi? Quindi, indirizziamo lo scan all'intera rete, lanciando nmap con l'opzione -sP e target 192.168.0.0/24. Mediante Wireshark, notiamo qual'è la tecnica usata da nmap.
effettuiamo ora uno scan verso un computer fuori della nostra rete, ad esempio 151.100.122.122. Notiamo nuovi messaggi ? cosa vuol dire filtered ports ? (verifichiamolo con Wireshark).

Il percorso dei nostri pacchetti

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 Universidad Tecnica Federico Santa Maria che si trova in Cile, e

contiamo quanti salti è possibile visualizzare;
notiamo i nomi delle macchine attraversate. Notiamo che per alcuni hop, sono elencati più router, in alternativa tra loro;
facciamo caso ai tempi che sono mostrati.
Osserviamo infine, qual'è l'ultimo router che riusciamo a raggiungere, e l'IP ad esso associato, differente dal nostro. Perchè ?
proviamo ora a fare il tragitto inverso, eseguendo traceroute a partire dal nostro computer. Facciamo lo stesso percorso ?
mentre proviamo il traceroute che parte dal nosto computer, possiamo tenere aperto Wireshark, ed esaminare cosa avviene
1. una alternativa a traceroute è tracepath, che realizza anche la funzione di path MTU discovery
2. da notare anche xtraceroute (vedi anche, man), che offre una visione tridimensionale del globo, e tenta di localizzarvi i router incontrati per la strada

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

tcptraceroute, che analogamente a quanto fatto da nmap, usa la tecnica di tentare di aprire una connessione TCP, sempre incapsulandola in una intestazione IP con un valore di TTL via via crescente, oppure
mtr, che riporta su schermo, in modo continuativo, le statistiche sui ritardi medi, minimi e massimi, e la deviazione standard

finalmente, possiamo confrontare il percorso per il Cile, con quello dal Cile verso di noi.
catturando con Wireshark il traffico generato da tcptraceroute e mtr, possiamo studiarne il funzionamento.

nel corso di questa verifica, ci siamo trovati nel caso in cui sia traceroute che tcptraceroute non funzionavano, mentre invece mtr si. A quanto pare, l'ISP utilizzato filtrava i pacchetti ICMP di tipo icmp time to live exceeded. A seguito della verifica fatta con wireshark si è notato che mentre mtr opera inviando pacchetti icmp echo request, tcptraceroute invia invece un TCP SYN, sempre con un campo TTL IP troppo basso. In entrambi i casi i router di transito, nel generare la risposta ICMP, vi inseriscono come PDU l'inizio del pacchetto scartato, dando modo ai router sulla strada di ritorno, di investigare il tipo di traffico che ha prodotto l'icmp. Quindi, evidentemente, il nostro ISP decide di non bloccare l'ICMP prodotto dal ping, e di bloccare invece quello prodotto dal TCP, in quanto in questo secondo caso, non è esplicita l'intenzione del mittente originario, di effettuare una investigazione di rete.

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.

A quanto vado?

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. L'unico modo per conoscerne il valore è 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.

Esperimento Netkit

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, e su r2 e r3 in modo client. Infine, mentre su r1 è anche lanciato tcpdump 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.

Traffic shaping

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.

Chi è chi?

Whois

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. 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 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.

Eseguiamo il comando whois 151.100.106.71, ovvero relativo all'indirizzo del nostro NAT, con cui "usciamo" su internet: leggendo la risposta, sembra che questa provenga da whois.ripe.net, del RIR RIPE, il quale risponde che questo indirizzo fa parte del lotto 151.100.0.0 - 151.100.255.255 assegnato all'Università la Sapienza, e vengono mostrati i riferimenti al contatto tecnico ed al sistema autonomo di riferimento (AS137)
se eseguiamo il comando whois AS137 mentre è in esecuzione wireshark, osserviamo che viene prima interrogato il server whois.arin.net, nella cui risposta si dichiara che gli indirizzi sono stati ri-assegnati, e di consultare http://www.ripe.net/whois. A quanto pare, l'attuale versione del comando whois è intelligente abbastanza da eseguire la nuova query di sua iniziativa (altrimenti, avremmo potuto eseguire whois -h whois.ripe.net AS137), e stavolta il server whois di RIPE risponde indicando che il numero di sistema autonomo AS137 è gestito dal GARR
si vada sul sito del GARR: potremo osservare la topologia della rete, ed investigare sullo stato del collegamento verso uniroma1, mediante uno tra due diversi meccanismi di visualizzazione dello stato dei collegamenti:
1. quello basato su MRTG (presso http://www.noc.garr.it/mrtg/) dove possiamo scegliere sotto il POP di Roma-G il link di Università di Roma I, cliccare show data in basso, ed osservare l'andamento del traffico giornaliero, mensile e annuale. Notiamo la crescita costante del traffico sul link da 1 Gbit, che si riscontra anche bene ad es. sul link da 2 Gbit del MIX, tramite il quale la rete GARR scambia traffico con molti altri provider.
  - I grafici sono prodotti con MRTG, che basa il funzionamento su di un programma eseguito ad intervalli regolari come un cron job, e che interroga via SNMP gli oggetti reperibili presso i MIB dei router, acquisendo così le informazioni sui byte in transito, che vengono salvate in un file, e da cui i derivano le informazioni differenziali. Quindi, sono invocati i servizi offerti dalla libreria GD in grado di generare i grafici che osserviamo.
2. quello basato su GINS, sviluppato dal GARR stesso, e raggiungibile dal link statistiche backbone, dove l'intera rete è visualizzata in forma grafica, e sono mostrati in modo interattivo le percentuali di utilizzo dei links, e la temperatura dei router; inoltre, sono direttamente accessibili i grafici temporali, e riportata l'evoluzioni degli eventi di guasto e menutenzione.
presso il sito del MIX, che è un Internet Exchange Point (IXP - lista a volte detto Neutral Access Point o NAP - video, dove gli ISP fanno peering, vedi [DrPeering]) troviamo l'elenco degli afferenti alla struttura, la documentazione ed i costi, oltre ad una sezione sulle statistiche ad accesso riservato, a beneficio degli aderenti.
altre interconnessioni internazionali tra GARR ed altre reti di accademiche avvengono tramite la rete GEANT (video) o meglio, Geant2

Ma il comando whois effettua anche ricerche sui domini:

eseguire il comando whois uniroma1.it: viene interrogato il server whois.nic.it, e si ottiene di nuovo l'informazione di assegnazione all'Università Sapienza, con i contatti, ed il DNS autorevole per i nomi di dominio.

Riferimenti

Home Network Security - presso CERT Coordination Center
Top 100 Network Security Tools - presso insecure.org
mappe della rete
Exploring Autonomous System Numbers
The Internet Peering Knowledge Center
Robtex - swiss army knife internet tool
Strumenti Linux per la sicurezza wireless - di A.Falaschi

Realizzato con

da Alessandro Falaschi -