Questo paragrafo presenta l’architettura di un singolo IDS locale che, insieme con gli altri IDS, `e parte dell’architettura complessiva del sistema. Si suppone che a partire da un IDS locale qualsiasi, con informazioni di bassa qualit`a, si possa ottenere un IDS globale che produce informazioni di elevata qualit`a grazie alla collaborazione tra gli IDS. Come caso d’esempio `e stato scelto un IDS locale che come evento per mandare un allarme controlli le connessioni TCP che falliscono. Comunque l’approccio utilizzato pu`o essere adottato indipendemente dall’evento o dagli eventi considerati dagli IDS locali.
Ogni IDS locale `e composto da tre moduli:
1. IDSsniffer: memorizza in una struttura dati adatta tutto il traffico di rete che esamina. In questo modo controlla sia il comportamento della sottorete, per la quale si comporta da gateway, per il traffico esterno, sia i nodi esterni che tentano di connettersi con la sottorete stessa; 2. IDSctrlConn: utilizza i dati catturati dal modulo IDSsniffer, per
controllare se ci sono anomalie in qualche nodo della rete. Se riscontra nodi con un comportamento sospetto, comincia ad applicare il test SHT e, se `e necessario, invia le informazioni raccolte ad un altro IDS; 3. IDSrecvInfo: riceve informazioni su un nodo sospetto da un altro IDS
ed applica il SHT al nodo su cui ha ricevuto informazioni.
5.2.1
IDSsniffer
Il modulo IDSsniffer osserva tutto il traffico TCP su una data connessio- ne di rete che `e condivisa tra pi`u nodi. Le sue osservazioni permettono poi al modulo IDSctrlConn di rilevare quali connessioni TCP falliscono. La sua implementazione, cos`ı come le librerie e le strutture dati utilizzate sa- ranno descritte nel paragrafo 5.3. Per ogni pacchetto catturato, il modulo IDSsniffer controlla l’header TCP, e come chiave di accesso per riconoscere i pacchetti di una certa connessione, il modulo utilizza la stringa formata da:
Indirizzo IP sorgente + Indirizzo IP destinatario + Porta sorgente + Porta destinatario
Per ogni pacchetto, il modulo controlla in particolare i flag necessari per crea- re una connessione: syn ed ack. Tutti i pacchetti che non hanno settato nessu- no dei due flag precedenti sono immediatamente ignorati. Il comportamento per tutti gli altri pacchetti dipende dal flag settato. In particolare:
• se `e settato soltanto il flag syn, la connessione `e memorizzata, regi- strando che il nodo che ha inviato il pacchetto sta cercando di iniziare una nuova connessione;
• se sono settati sia il campo syn sia il campo ack, si registra che la procedura per instaurare una connessione `e giunta al secondo passaggio; • se `e settato soltanto il campo ack, si notifica che la connessione ha
avuto successo.
Se, durante il monitoraggio si trova un pacchetto inatteso, come un ack finale senza aver ricevuto precedentemente il synack, questo `e ignorato. Oc- corre ricordare, infatti, che il flag ack `e settato sempre dal protocollo TCP in risposta ad un pacchetto con payload ricevuto e soltanto dall’inizio della connessione si utilizza il pacchetto ack per instaurare una connessione con successo.
5.2.2
IDSctrlConn
Il modulo IDSctrlConn controlla lo stato delle connessioni memorizzate dal modulo IDSsniffer. In particolare il modulo considera due eventi:
• se una connessione `e terminata con successo, la elimina dalla lista delle connessioni da monitorare e controlla se il nodo che ha eseguito la connessione monitorata ha avuto precedentemente un comportamento sospetto:
– in caso positivo, esegue il SHT, notificando una connessione riu- scita;
– in caso negativo scarta l’informazione.
• se una connessione non `e terminata ed `e scattato un timeout, elimina la connessione dalla lista connessioni ed esegue il SHT.
Dopo l’esecuzione del SHT:
• se il risultato `e inferiore alla soglia T0, smette di monitorare il nodo
sospetto;
• se il risultato `e superiore alla soglia T1 smette di monitorare il nodo
sospetto ed informa tutti gli altri IDS che quel nodo `e infetto;
• se il risultato `e inferiore a T0Loc o superiore a T1Loc continua a monito-
rare il nodo ed inoltre informa un altro IDS;
5.2.3
IDSrecvInfo
Il modulo IDSrecvInfo attende una connessione da parte di un altro IDS. Quando riceve nuove informazioni su un nodo sospetto, dopo aver memoriz- zato tutte le informazioni necessarie, si comporta esattamente come il modulo IDSctrlConn nel caso di un nodo considerato sospetto. La sua implementa- zione, cos`ı come le strutture dati utilizzate e le sue librerie saranno descritte nel paragrafo 5.3.
Protocollo di comunicazione
Tutti gli IDS formano tra loro una rete peer to peer, infatti, ognuno di loro, `
e in modalit`a:
• client quando ha dati da inviare per cercare di effettuare una connes- sione;
• server quando il modulo IDSrecvInfo `e in attesa di ricevere nuove informazioni.
La porta sulla quale sta in ascolto il modulo IDSrecvInfo `e la 9001, ma `
e possibile cambiarla in fase di configurazione. Occorre per`o notare, che `e opportuno che tutti gli IDS utilizzino la stessa porta di comunicazione per una maggior semplicit`a del protocollo. Inoltre, `e consigliabile che gli IDS sfruttino una VPN per le comunicazioni sui nodi infetti in modo da evitare possibili manomissioni dei dati ed essere sicuri dell’identit`a del mittente del messaggio.
Il protocollo del livello di trasporto utilizzato `e il TCP. Dopo aver ef- fettuato la connessione, l’IDS mittente ed il modulo IDSrecvInfo dell’IDS destinatario iniziano a scambiarsi i dati. L’IDS mittente invia nell’ordine:
• la dimensione della stringa che contiene l’indirizzo IP del nodo da mo- nitorare, perch´e il programma utilizza l’IP di un nodo infetto come stringa;
• l’indirizzo IP del nodo da monitorare che `e memorizzato dal modulo IDSrecvInf ;
• il risultato del SHT applicato al nodo sospetto;
• il numero di IDS che condividono gi`a le informazioni inviate dall’IDS mittente e che hanno monitorato il nodo sospetto.
• elenco degli IDS che condividono le informazioni, memorizzando ogni indirizzo IP degli IDS in una struct in addr. Queste informazioni per- mettono di garantire che le informazioni sul nodo sospetto siano tra di loro indipendenti.