7 Dati di sessione
7.1 Introduzione
I dati di sessione rappresentano un riassunto di una conversazione tra due parti. Una sessione, che viene denominata anche flusso, o corrente, o stream, è un riassunto dello scambio di pacchetti tra due sistemi.
Tra gli elementi basici dei dati di sessione sono presenti i seguenti: • Ip di origine.
• Porta di origine. • Ip di destinazione. • Porta di destinazione.
• Marca temporale, che generalmente è l'istante in cui incomincia la sessione . • Quantità di pacchetti scambiati durante la sessione.
I dati di sessione, rappresentano il secondo livello di registrazione delle attività all'interno della rete. E' praticamente impossibile, per ovvie ragioni di spazio di memorizzazione, registrare tutte i dati di contenuto completo per registrare le attività svolte all'interno della rete, e poter quindi individuare degli attacchi o delle anomalie nel traffico di rete.
Da un punto di vista di investigazione di rete, i dati di contenuti completo sono più validi dei dati di sessione. Si usufruisce invece dei dati di sessione per ovviare al problema dello spazio di immagazzinamento.
I dati di sessione vengono registrati attraverso l'utilizzo di alcuni agenti che fanno parte dell'attività di monitoraggio del traffico:
• sonda: è un sistema che si occupa di osservare il traffico e esportare i registri di dati di sessione,
• collezionatore: è un sistema che riceve le conversazioni esportate • console: interpreta i registri e gli da senso.
7.2 Cosa ci si aspetta da quest'analisi.
Senza dubbio con quest'analisi si sta facendo un ulteriore passo in avanti nel mondo dell'auditoria di rete. Trattare dati di sessione eleva il sistemista di rete o analista, a una posizione più alta dal quale osservare il traffico di rete. La quantità di informazioni gestite è inferiore a prima, ma è possibile disegnare uno scenario di attacco in maniera più immediata.
Individuare un flusso con wireshark comporta l'utilizzo di filtri che escludano gli altri flussi tcp, con argus i flussi sono l'unica cosa registrata.
Ci si immagini difronte a dimensioni di traffico superiori al GB, come si pensa possibile un'analisi del traffico di rete mediante i dati di contenuto completo? Non basterebbero giorni per analizzare il file, e presumibilmente le persone andranno a lavorare e utilizzeranno la rete
nei giorni a venire, quindi renderebbe praticamente impossibile il monitoraggio della rete in tempo reale.
Dato che legalmente viene imposto alle aziende di registrare il traffico che va dalla propria rete verso internet, questa rappresenta una delle possibili soluzioni per adempiere a tale obbligo.
Registrare le azioni effettuate dai propri utenti è fondamentale per una questione di riconoscimento delle azioni effettuate da una persona. Infatti nelle reti di tipo LAN viene utilizzato un indirizzamento IP di tipo privato, questo tipo di indirizzamento viene poi NATtato dal router, che cambierà l'indirizzo IP sorgente dei pacchetti provenienti dalla rete interna con l'indirizzo IP della sua interfaccia che si affaccia a internet. Sarà il router a memorizzare in una tabella le connessioni in uscita, per poter così poi inoltrare le risposte provenienti dall'esterno verso l'host corretto all'interno della rete.
Mantenendo traccia delle connessioni all'interno della LAN si è in grado di identificare quale macchina (in base all'indirizzo IP) ha effettuato una determinata connessione.
A questo punto bisogna fare una considerazione importante sull'indirizzamento IP, quando si è su internet si suppone infatti che a un IP corrisponda una sola macchina, ma di fatto l'indirizzo ip generalmente nasconde dietro una rete di computer. Per permettere questo si usa una tecnica chiamata NAT. Questa tecnica permette di inoltrare correttamente il traffico che deve essere diretto all'interno della rete.
In una delle macchine della rete, se si posseggono i privilegi di amministratore della macchina è possibile cambiare l'indirizzo IP. Per come è stata progettata la rete di CHM, un accesso di tipo amministratore è stato facilmente procurato dall'attaccante, perciò affidarsi a questo livello di sicurezza sembra poco prudente. Inoltre alcuni utenti hanno molto probabilmente l'account con privilegi di Administrator e potrebbero quindi effettuare questa operazione (o lo si potrebbe effettuare come utente sotto mentite spoglie). Bisognerebbe essere sicuri che un determinato IP corrisponda a un determinato utente.
Per poter fare questo è necessario utilizzare un sistema di autenticazione centralizzato, e forzare gli utenti che vogliono uscire dalla rete privata per andare su internet ad autenticarsi su un sistema proxy gateway. In questa maniera la criticità del sistema sarà data dalla vulnerabilità delle password utilizzate dagli utenti del proxy. Una buona amminsitrazione delle password metterebbe al sicuro la rete e eviterebbe il tipo di attacco condotto da Ardala.
Ad ogni modo il solo IP non corrisponde un metodo completo di autenticazione di una macchina, in quanto è sempre possibile spoofare l'indirizzo IP di una macchina e tentare un'intrusione come utente sotto mentite spoglie.
Per verificare se una macchina è effettivamente quella che dice di essere si può controllare un parametro ulteriore, che è l'indirizzo fisico delle schede di rete della macchina (sia schede ethernet che schede wi-fi sono dotate di indirizzo fisico). Questo indirizzo è chiamato MAC address. Anche quest'indirizzo può essere a sua volta spoofabile, e per spoofarlo viene coinvolto il protocollo ARP e RARP. Mediante l'utilizzo dello stesso protocollo è possibile scoprire un MAC spoofato.
Sostanzialmente, utilizzare una sonda che cattura il traffico e ne trasforma i dati di contenuto completo in dati di sessione, fornisce un ottimo strumento di auditoria, ma non
migliora nell'immediato la sicurezza della rete. Si possono invece estrappolare numerose informazioni che possono aiutare a gestire in maniera ottimale le prestazioni e la sicurezza di rete.
Nel paragrafo 6.5 si analizzerà l'attacco sferrato alla rete di CHM individuando le sessioni che riguardano le parti salienti dell'attacco.
Come già si è detto precedentemente solo l'esperienza aiuta nell'analisi dei tipi di dato di sessione. E' molto difficile, inizialmente, riconoscere un particolare tipo di attacco dalle poche variabili messe in gioco nei dati di sessione.
La prassi vuole che si cerchino gli indirizzi IP che riguardano una determinata sessione, le porte utilizzate, e poi è possibile vedere quanti pacchetti sono stati inviati da un host e quanti dall'altro, vedere la quantità di traffico scambiata, la marca temporale, e lo stato finale della sessione. Una volta individuato un pattern sconosciuto o sospetto, se si vuole realmente arrivare a ricostruire le azioni svolte da un aggressore è necessario avere i dati di contenuto completo che riguardano l'attacco.
7.3 Strumento utilizzato: Argus.
Per la trasformazione dei dati di contenuto completo in dati di sessione, si è utilizzato uno strumento chiamato argus.
Argus permette di svolgere auditoria di rete, e di analizzare il traffico che passa per la rete. E' possibile generare flusso dati a partire da files che contengono pacchetti, come per esempio i file creati con tcpdump, ovvero gli stessi file che si sono analizzati per l'attacco. Questi file hanno estensione *.lpc.
I dati di sessione sono fondamentali per il monitoraggio di rete, perchè riassumono i dati di contenuto completo. Ovviamente salvare tutti i dati di contenuto completo che transitano in una rete non è conveniente in termini di risorse utilizzate.
Argus è stato creato a partire dal protocollo proprietario Cisco Netflow, che si trova all'interno del'IOS (Inter Operating System) Cisco. Il sistema operativo che gira su router cisco.
7.3.1
Chi usa argus
Molte università, aziende e entità governative utilizzano Argus per registrare entrambi i flussi di traffico, quelli che entrano e quelli che lasciano la/e loro rete/i. Questi registri sono usati sia in analisi di utilizzo della rete in tempo reale, sia in analisi a distanza di tempo. Con un sensore di rete sul quale viene eseguito Argus, le organizzazioni possono validare la connettività di host finali attraveso router multipli. Inoltre può essere usato come strumento di troubleshooting della rete. Per esempio se i router A,B e C stanno inoltrando il traffico degli host Y e Z, Argus può essere usato per determinare la latenza e altri problemi che potrebbero verificarsi tra i router B e C, o tra A e B.
Il flusso di dati Netflow, immagazzinati, possono essere usati per investigazioni forensi diversi mesi, o anni, dopo che un incidente è avvenuto. Il flusso netflow di Argus comprime fino a 10 000:1 la dimensione dei pacchetti che devono essere scritti nel disco, ciò permette
installazioni che conservano molti più dati e possono essere mantenuti per molto più tempo rispetto agli interi pacchetti catturati.
Mentre la sicurezza di rete è molto importante, la non-repudiazione diviene un requisito molto importante che deve essere fornito in una rete. Argus fornisce i dati basilari richiesti per creare un sistema di auditoria delle attività di rete centralizzato.
Se implementato correttamente, questo sistema, può registrare tutte le attività di rete in entrata e in uscita, e può fornire un sistema di base necessario a garantire che nessuno può negare di aver fatto qualcosa in rete.
I laboratori di ricerca hanno usato Argus per ottenere una misura per le prestazioni di rete di un unico protocollo, come la Infiniband su Ipv6. Argus può rapidaemente adattarsi ai nuovi protocolli e in alcuni casi, fornire le metriche basiche senza estensione. Gli individui usano Argus a casa loro, per poter determinare le prestazione della loro rete basata su DSL o Cable Modem. Argus fornisce una visuale più elevata del traffico, che permette agli utenti di individuare i problemi velocemente.
[tradotto da [40]].
7.3.2
Tasso di compressione rispetto ai dati di contenuto
completo.
Nella conduzione degli esperimenti si è potuto verificare un tasso di compressione di 10 a 1 nel caso del file sf1.lpc (inizialmente 5,0 MB e successivamente 466 KB)e nel caso del file em0.lpc il tasso di compressione fu di 51,47 a 1 (175 KB iniziali contro i 3,4 finali). Questa differenza è data dall'attacco di tipo DdoS e dalle scansioni effettuate con nmap. I flussi generati da scansioni e attacchi Ddos sono formati da massimo 3 pacchetti (es. ACK, SYN- ACK e RST nel caso di scanning di porte aperte), a volte due pacchetti (nel caso di porte chiuse, la macchina obiettivo risponde con un RST) o da uno solo (come nel caso dell'ACK flooding lanciato contro il server IRC).
Si può verificare, controllando il numero di linee del file contenente i dati di sessione, che sf1.lpc contiene 2880 sessioni, mentre em0.lpc ne contiene solo 20. I pacchetti totali salvati nel file sf1.lpc sono 17604, mentre in em0.lpc sono 1136.
Il tasso di compressione Pacchetto->Dato di sessione è di 6,11 per il file sf1.lpc, a conferma del gran numero di scansioni e attacchi che sono stati sferrati e registrati da questa interfaccia, e per l'interfaccia em0.lpc il tasso è di 56,8. Che i tassi di compressione del pacchetto in dato di sessione e della grandezza in byte dei file, per em0.lpc siano molto simili (51, 5 contro 56,8) è dato dal fatto che la maggior parte del traffico è stato generato durante lunghe sessioni (per esempio l'esportazione dei progetti di CHM, l'attacco mediante datapipe con il tsgrinder, che come vedremo sarà identificato da dieci sessioni), e quindi i pacchetti essendo carichi di dati raggiungono facilmente il limite massimo di MTU (maximum transmission unit) di 1500, mantenendo quindi pari, o, meglio, poco tendente verso la compressione del pacchetto, il rapporto tra compressione pacchetto e compressione dimensione del file.
7.3.3
Installazione
L'installazione del software argus in ambiente Ubuntu Linux, viene estremamente semplificata dalla presenza di argus nei repository di Ubuntu. Quindi sarà semplice lanciare da terminale il comando:
“sudo apt-get install argus-client”.
In questa maniera sarà il sistema a preoccuparsi di installare anche tutte le dipendenze perchè funzioni correttamente il pacchetto argus-client.
7.3.4
Esecuzione
Argus dovrà eseguire due operazioni prima di restituire la sintesi del traffico da dati di contenuto completo in dati di sessione.
Per prima cosa avrò un'estrazione dei dati di sessione dal file *.lpc, e immagazzineremo l'output del comando in un file che successivamente darò in mano al programma “ra”(read argus data) della suite “argus-client”.
root@michelangelo:~# argus -r em0.lpc -w em0.lpc.argus
L'opzione -r sta per “read” e indica il nome del file da quale leggere, e l'opzione -w sta per write e specifica il nome del file su cui indirizzare lo standard output.
Ora si utiizzerà lo strumento read argus, per convertire i dati in maniera leggibile.
root@michelangelo:~# ra -r em0.lpc.argus >>
file_analizzabile.txt
Per filtrare e quindi cercare dentro i file si possono utilizzare espressioni regolari con il comando ragrep.
7.4 Topologia della rete CHM
L'illustrazione , si può osservare la topologia di rete di CHM (la parte LAN-DMZ). In questo scenario sono implicate tre sottoreti:
• la 10.10.10.0, che è la rete interna di CHM,
• la 172.27.20.0 che è la rete da dove Ardala lancia il suo attacco (che è considerata come Internet),
• la 192.168.60.0 che è la rete DMZ della CHM.
Questo schema sarà utile quando si analizzeranno i due file em0.lpc e sf1.lpc.
Logicamente non sarà possibile trovare il traffico appartenente al server 10.10.10.3 verso l'esterno della rete, nel file sf1.lpc, in quanto il traffico catturato in sf1.lpc è stato catturato dall'interfaccia collegata alla DMZ. E' invece vero che ci si sarebbe aspettati di trovare alcuni flussi di traffico registrati su entrambe le interfacce, per esempio quello tra DMZ 192.168.60.0/24 e il server della LAN 10.10.10.0/24.
Si prenda come esempio il traffico generato da un server della DMZ e il server 10.10.10.3, essendo collegata a un hub, la sonda dovrebbe catturare il traffico anche con l'interfaccia sf1, oltre che con la em0 che è collegata alla porta SPAN dello switch della rete interna. Però tenendo presente che si stanno analizzando dei file riguardanti un attacco simulato, è possibile che i due file siano stati costruiti in uno scenario leggermente differente da quello mostrato nella topologia (per esempio la sonda non è stata attivata su entrambe le interfaccie se non nel momento preciso in cui si doveva registrare il traffico, e quindi in fase di registrazione è stato compiuto questo piccolo errore).