Analisi e implementazione di una tecnica di Bivariate Non-parametric Network Anomaly Detection

(1)

Corso di Laurea in Ingegneria delle Telecomunicazioni Tesi di Laurea Magistrale

Analisi e implementazione di un algoritmo di

Bivariate Non-Parametric

Network Anomaly Detection

Relatori:

Prof. Ing. Michele Pagano Prof. Ing. Stefano Giordano Ing. Christian Callegari

Candidato: STV(AN) Alessandra Fonzino

(2)

Indice

Sommario 3

Introduzione 5

1 Nozioni generali sulla sicurezza informatica 9

1.1 Caratteristiche della sicurezza informatica . . . 10

1.2 Tipologia di attacchi alla rete . . . 11

1.3 Misure di prevenzione e protezione . . . 14

2 Intrusion Detection Systems 16 2.1 Architettura generale degli IDSs . . . 17

2.2 Host-based vs Network-based IDSs . . . 19

2.3 Anomaly-based vs Signature-based IDSs . . . 21

2.4 Stateless IDSs vs Stateful IDSs . . . 23

2.5 IDSs passivi vs IDSs attivi . . . 23

3 Statistical anomaly-based Intrusion Detection Systems 25 3.1 Introduzione agli A-NIDSs . . . 25

(3)

3.2 Analisi statistica di tipo univariate, bivariate e multivariate 26

3.3 Tecniche di analisi parametriche e non parametriche . . . 28

4 Bivariate Non-Parametric Algorithm Detection 30 4.1 Dataset utilizzato e Data Formatting . . . 31

4.2 Strutture dati . . . 32

4.3 Algoritmo di rilevazione . . . 34

5 Risultati sperimentali 39 5.1 Tracce MAWI . . . 39

5.2 Prove sperimentali . . . 43

5.3 Estrazione delle features di traffico . . . 44

5.4 Confronto con altri algoritmi . . . 58

(4)

Sommario

La complessit`a delle reti moderne e il loro costante utilizzo hanno favorito un processo di digitalizzazione del quotidiano e nuove modalit`a di utiliz-zazione della conoscenza. Tuttavia, a pari passo con il crescente sviluppo di Internet come mezzo di comunicazione e commercio, anche le minacce, gli aggressori e le imprese criminali sono cresciute di conseguenza.

In uno scenario come quello appena descritto, a fronte delle possibilit`a non secondarie di violazione delle policy di sicurezza, il modo migliore per proteggere una rete o un singolo computer risiede nel riconoscere e respingere in maniera preventiva gli attacchi. I principali strumenti im-piegati nell’ambito della rilevazione degli attacchi di rete sono gli Intru-sion Detection Systems: si tratta di sistemi capaci di monitorare il traffico in transito, verso un host o su un segmento di rete, e di generare degli allarmi per evidenziare il sopraggiungere di una situazione pericolosa.

In questa tesi, in particolare, si propone lo sviluppo di un sistema che sia capace di eseguire il monitoraggio di due descrittori di traffico (da qui, la natura bivariate dell’algoritmo implementato), di costruire modelli stati-stici non parametrici e di effettuare una decisione basata sull’osservazione

(5)

congiunta delle due metriche scelte.

Dalle prove sperimentali eseguite, sono state ottenute prestazioni che dimostrano la fattibilit`a e il potere discriminante di un sistema di Intrusion Detectionbasato su un algoritmo di tipo Bivariate Non-Parametric Network Anomaly Detection.

(6)

Introduzione

La complessit`a delle reti moderne e il loro costante utilizzo hanno favori-to un processo di digitalizzazione del quotidiano: quesfavori-to fenomeno, come specificato nella Dichiarazione dei diritti in Internet,“ha contribuito in ma-niera decisiva a ridefinire lo spazio pubblico e privato, a strutturare i rapporti tra le persone e tra queste e le Istituzioni. Ha cancellato confini e costruito mo-dalit`a nuove di produzione e utilizzazione della conoscenza” [1]. Tuttavia, a pari passo con il crescente sviluppo di Internet come mezzo di comunica-zione e commercio, anche le minacce, gli aggressori e le imprese criminali sono cresciute di conseguenza.

Il primo virus informatico moderno che ha dimostrato la scarsa sicu-rezza della rete Internet, si è registrato nel 1988 quando uno studente della Cornell University lanciò un programma di attacco alla rete. Il virus Worm, ideato con il solo intento di misurare la capacità e il grado di sicurezza for-nito dalla rete, ha portato al collasso di 6000 macchine di dominio pubblico. Fortunatamente, la somma dei siti colpiti dal virus rappresentava solo il 5-7% di Internet: nonostante questo, l’evento è servito come campanello d’allarme per tutti coloro che si occupavano di sicurezza e di tecnologia

(7)

delle informazioni in quanto fu palese che i rischi legati a Internet erano reali e gravi. [2]

Sono passati diversi anni e ancora la ricerca di sistemi di sicurezza rappre-senta una assoluta esigenza: gli ultimi rapporti sulla sicurezza informatica si riferiscono ad anni come quelli che vanno dal 2001 al 2017 come agli anni horribiles[3].

In un panorama come quello appena descritto, le progettualit`a e le poli-cy messe in atto per una gestione consapevole dell’information security riguardano molti aspetti:

• Identificazione, intesa come la capacit`a di comprendere come ge-stire le vulnerabilit`a di sistema e i conseguenti attacchi;

• Protezione, che rappresenta la capacit`a di sviluppare e implemen-tare misure di sicurezza che garantiscano la corretta erogazione dei servizi offerti dalla rete;

• Rilevazione, in riferimento alle attivit`a necessarie ad individuare le anomalie di sistema;

• Risposta, capacit`a di rispondere all’evento anomalo identificato; • Ripristino, come la capacit`a di garantire la resilienza dei sistemi e

la facolt`a di riattivare i servizi.

Nella fase di rilevazione offrono grande supporto gli Intrusion Detection Systems, i quali attuano un monitoraggio del traffico e una identificazio-ne delle anomalie.

(8)

Sono stati proposti approcci che permettessero di rilevare non solo anoma-lie note al sistema ma anche quelle di cui non si era a conoscenza dell’esi-stenza. Per questo motivo, lo scopo di questa tesi `e quello di illustrare una strategia di identificazione delle anomalie a partire da un monitoraggio bidimensionale del traffico dati, di cui si suppone, quindi, non conoscere la distribuzione di probabilit`a: questo spiega la natura “Bivariate” e ”Non-parametric” del sistema proposto.

Per consentire una comprensione ottimale dell’argomento in analisi, l’e-laborato si articola sulle seguenti sezioni:

• il primo capitolo presenta alcuni concetti basilari legati alla sicu-rezza informatica: si evidenziano le caratteristiche e le tipologie di attacchi che potrebbero comprometterla. Si conclude con una panoramica sugli strumenti utilizzati per garantire che le policy di sicurezza vengano rispettate;

• il secondo capitolo presenta l’architettura generale dei sistemi di intrusion detectione propone una descrizione dettagliata di ogni blocco che li compone;

• il terzo capitolo approfondisce le caratteristiche implementative le-gate ad un anomaly-based e network-based IDS, che rappre-senta il sistema scelto per l’implementazione dell’algoritmo propo-sto. In particolare, viene spiegato il concetto di monodimensionalit`a, multidimensionalit`a e i vantaggi e svantaggi che esistono nell’uti-lizzare una strategia non parametrica rispetto ad una che lo sia;

(9)

• il quarto capitolo `e dedicato alla descrizione del test statistico propo-sto ottenuto monitorando le tracce appartenenti all’archivio MAWI; • il quinto capitolo descrive nel dettaglio le verifiche sperimentali ef-fettuate a sostegno della fattibilit`a dell’algoritmo proposto: si ripor-tano le valutazioni in termini di prestazioni e confronto con sistemi precedentemente sviluppati.

(10)

Capitolo 1

Nozioni generali sulla

sicurezza informatica

Alcuni dispositivi di sicurezza di rete, come i firewall, possono essere ag-girati dagli intruder che possono alterare le funzionalità del sistema senza essere identificati. Recenti studi dimostrano che mensilmente vengono ri-levate dalle 20 alle 40 nuove vulnerabilità di sistema e, di conseguenza, un numero sconcertante di possibili tentativi di intrusione. Data l’ampia gamma di azioni malevole esistenti, è naturale iniziare la costruzione di un rilevatore a partire dalla natura del segnale che si desira rilevare. Que-sto permetterà di capire come, nel tempo, si siano sviluppati i sistemi di Intrusion Detectione in che modo si possono classificare.

In questo capitolo si cerca di dare una descrizione di massima di co-sa si intenda per sicurezza informatica e da quali propriet`a esco-sa

(11)

dipen-1.1. CARATTERISTICHE DELLA SICUREZZA INFORMATICA

da, per poi analizzare brevemente quali siano gli attacchi che rischiano di comprometterla e quali i mezzi per cercare di garantirla.

1.1 Caratteristiche della sicurezza

informati-ca

Il sistema di informazione è generalmente definito dall’insieme dei dati e delle risorse hardware e software accessibili esclusivamente agli utenti le-gittimati a farne uso. In questo scenario, la sicurezza informatica subentra per assicurare che queste risorse siano usate unicamente nei casi previsti. Affinchè un sistema possa considerarsi sicuro è necessario che venga-no garantite alcune proprietà: riservatezza, integrità e autenticazione.

Quanto alla riservatezza delle informazioni, solo ed esclusivamente gli utenti autorizzati devono essere a conoscenza del contenuto e/o del-l’esistenza di un dato flusso informativo. Garantire la riservatezza delle informazioni vuol dire proteggere i dati trasmessi dagli attacchi di utenti non autorizzati al monitoraggio e all’ascolto del traffico.

Per integrità delle informazioni si intende la proprietà per cui tutto è come dovrebbe essere. Il sistema deve impedire l’ alterazione diretta o indiretta delle informazioni, sia da parte di utenti che di processi non autorizzati. Anche la perdita di dati, per esempio a seguito di cancellazione o danneggiamento, viene considerata come alterazione.

In un’ottica generale di sicurezza non deve essere possibile alterare i dati di qualsivoglia transazione. Dette informazione devono rimanere integre.

(12)

1.2. TIPOLOGIA DI ATTACCHI ALLA RETE

Il servizio di autenticazione fornisce garanzia dell’autenticit`a di una comunicazione. Ad esempio, in caso di segnalazione o di allarme, il servi-zio di autenticaservi-zione si assicura che il traffico monitorato sia stato effetti-vamente generato dalla sorgente dichiarata[4].

Le caratteristiche appena descritte rappresentano delle condizioni ne-cessarie perché il sistema venga considerato sicuro: è un paradigma cui spesso si fa riferimento che sembrerebbe fornire le garanzie necessarie per l’inviolabilità di un sistema informativo. Tuttavia la realtà dimostra che questo non è possibile (nella sezione successiva si riportano alcuni degli attacchi alla rete finora identificati).

1.2 Tipologia di attacchi alla rete

La potenziale minaccia rappresentata da un attacco alla rete ha portato ad un costante sforzo da parte della comunit`a dei ricercatori per progettare efficaci mezzi di rilevazione. Per fare questo, `e stato necessario stabilire una tassonomia delle anomalie note.

Uno dei primi lavori nell’ambito della sicurezza informatica che propo-se una definizione di comportamento anomalo `e da attribuirsi allo scien-ziato James P. Anderson. In [5] si distinguono 3 classi di aggressori:

• Misfeasor: utente legittimo che accede a dati, programmi o risor-se per i quali non possiede l’autorizzazione all’accesso oppure le possiede ma abusa dei proprio privilegi;

• Clandestine: individuo che si impadronisce del controllo per la su-pervisione del sistema e lo utilizza per eludere i meccanismi di

(13)

con-1.2. TIPOLOGIA DI ATTACCHI ALLA RETE

trollo, oppure per nascondere/eliminare l’insieme dei record di audit del sistema;

• Masquerader: individuo non autorizzato all’uso del sistema che penetra i meccanismi di controllo dell’accesso, allo scopo di sfruttare l’account di un utente legittimo.[4]

Ognuno di questi aggressori pu`o provocare una serie di incidenti volti a compromettere le funzionalit`a del sistema operativo vittima, a partire da una una serie di tecniche che prendono il nome di privilege escalation. Queste strategie, intese come sorpasso delle autorizzazioni, si classificano come segue:

• Masquerading che riguarda tutte le attività volte a falsificare l’i-dentità dell’attacker e far s`ı che il sistema lo scambi per un’il’i-dentità fidata;

• System Misconfiguration: riguarda gli attacchi che sfruttano una componente critica, una vulnerabilit`a, che riguarda la sicurezza di un sistema;

• Abuse of feature: un utente legittimo pu`o sfuttare le sue creden-ziali di accesso per violare la policy di sicurezza del sistema; • Implementation bugs: veri e propri errori di progettazione o di

implementazione per i quali pu`o essere scritto un exploit che con-senta di ottenere un accesso non autorizzato al sistema o l’acquisi-zione di privilegi pi`u elevati;

(14)

1.2. TIPOLOGIA DI ATTACCHI ALLA RETE

• Social engineering che `e, fra quelle elencate, senza dubbio la tec-nica pi`u subdola: l’attaccante si finge un’altra persona e cerca di car-pire ad utenti autorizzati le informazioni che necessita per accedere al sistema [6].

La variet`a di attacchi provocati applicando ognuna delle tecniche ap-pena citate pu`o essere raggruppata in quattro macrocategorie:

1. Probe (detto anche scan): questa tecnica rappresenta il tentativo di collezionare informazioni preziose sui sistemi vittima, da utilizzare per attacchi successivi. Attraverso dei tool che ne automatizzano il processo, si esegue una scansione di una rete di host per identificare indirizzi IP validi, porte in ascolto, sistemi operativi delle macchine e vulnerabilit`a gi`a note.

2. Denial of service (DOS): attacchi di questo tipo sono disegnati per disturbare il regolare utilizzo di servizi o l’accesso ai dati. Ciò che ne consegue, realizzato tramite la creazione di un numero sproporzio-nato di richieste al servizio, è che una successiva richiesta da parte di un utente legittimo sarà estremamente lenta e difficoltosa, se non addirittura negata. Un esempio di attacchi di questo tipo sono il jamminge il flooding.

3. Remote to local (R2L): in questo tipo di attacchi il malintenzio-nato, che non dispone di un account valido sulla macchina vittima, riesce in qualche modo ad accedervi, o a reperire da essa dei dati sensibili, oppure a modificare il traffico in entrata verso la stessa.

(15)

1.3. MISURE DI PREVENZIONE E PROTEZIONE

4. User to root (U2R): in questa categoria rientrano tutte quelle tec-niche che consentono, ad un utente del sistema, di ottenere sullo stesso privilegi normalmente destinati agli amministratori [4] [7]. E’ bene precisare che quello fornito non `e un elenco esaustivo e che la classificazione degli attacchi informatici rappresenta ancora oggi un campo di ricerca attivo.

1.3 Misure di prevenzione e protezione

Data l’evoluzione delle modalit`a di attacco, numerose sono le misure che possono essere utilizzate come mezzi di prevenzione e protezione delle politiche di sicurezza. Queste possono essere sintetizzate come segue:

• Attack prevention: di questa classe fanno parte tutti quei mec-canismi utilizzati per la prevezione degli attacchi prima che questi possano raggiungere il bersaglio designato. Ne sono un esempio i firewall(letteralmente ”muro blocca fuoco”) che sono dei tool che proteggono una rete privata interna di computer dal traffico mali-gno proveniente da una rete pubblica esterna. Questi analizzano il traffico diretto ad un computer, o ad una rete di computer, e blocca-no tutto ciò che può danneggiare le funzionalità e compromettere i servizi garantiti da un sistema;

• Attack avoidance: ne `e un esempio la crittografia che altro non `e che un sistema pensato per rendere illegibile un messaggio a chi non possiede la soluzione per decodificarlo;

(16)

1.3. MISURE DI PREVENZIONE E PROTEZIONE

• Attack Detection: i principali strumenti impiegati nell’ambito del-la rilevazione delle anomalie sono gli Intrusion Detection Systems, oggetto di approfondimento di questo elaborato. Si tratta di siste-mi che monitorano e analizzano il traffico in trasito su un partico-lare segmento di rete o verso un host, con l’obiettivo di rilevare il sopraggiungere di una situazione pericolosa;

• Attack Tolerance: ci riferiamo a tutte quelle tecniche per le quali il sistema, nonostante sia vittima di un attacco andato a segno, rie-sca comunque ad erogare alcuni servizi. Le tecniche utilizzate per eliminare le anomalie dallo stato del sistema sono principalmente tre:

1. Rollback Recovery: durante la normale esecuzione del sistema vengono salvati degli stati corretti, detti checkpoint. Quando un’anomalia viene rilevata, il sistema viene riportato nel pi`u recente di questi stati;

2. Rollforward Recovery: il sistema viene fatto avanzare di stato in stato fino a quando non venga trovato con certezza lo stato safe;

3. Compensation: l’anomalia viene mascherata dal sistema poich´e lo stato contiene sufficienti ridondanze in modo da permettere al sistema di continuare a fornire il correct service [6].

Nel capitolo successivo, si riportano i dettagli relativi agli Intrusion Detection Systemsche intervengono nella critica fase di rilevazione e iden-tificazione delle anomalie.

(17)

Capitolo 2

Intrusion Detection

Systems

A fronte delle possibilit`a non secondarie di violazione delle policy di si-curezza, il modo migliore per proteggere una rete o un singolo computer risiede nel riconoscere e respingere in maniera preventiva gli attacchi. Per far questo, sono necessari sistemi di individuazione degli intrusi, reazione e contenimento del danno.

Gli IDSs entrano in gioco nella fase di rilevazione delle azioni tese a elu-dere le misure di sicurezza. Sono tool software che, come i firewall e i sistemi di controllo dell’accesso, mirano a rafforzare la sicurezza dei si-stemi. Nella seguente sezione, si descrivono dunque questi mezzi di ri-levazione degli attacchi a partire dalla loro architettura generale e se ne stabilisce una classificazione in funzione delle caratteristiche dei blocchi

(18)

2.1. ARCHITETTURA GENERALE DEGLI IDSS

che li compongono.

2.1 Architettura generale degli IDSs

Figura 2.1: Architettura CIDF per sistemi di ID

La ricerca dei sistemi di ID ottimi rappresenta un campo in crescente sviluppo e una sfida ancora aperta.

Nel 1998 il DARPA ( Defence Advanced Research Projects Agency) ha svi-luppato un’architettura generale che potesse meglio chiarire il principio di funzionamento degli IDSs e favorire la cooperazione fra sistemi di detec-tion sviluppati in ambiti differenti. Il risultato `e stato una metodologia di standardizzazione dei tool progettati nell’ambito dell’intrusion detection che va sotto il nome di CIDF ( Common Intrusion Detection Framework)[13]. Il CIDF definisce quattro tipologie diverse di componenti e ruoli spe-cifici:

1. “Event Boxes”: sono moduli costituiti da una serie di sensori che mo-nitorano il traffico dati in transito. Acquisiscono quindi le

(19)

informa-2.1. ARCHITETTURA GENERALE DEGLI IDSS

zioni osservate dal sistema di sorveglianza e le rendono disponibili alle altre component dell’IDS. In funzione della sorgente di infor-mazione considerata, un sistema di ID pu`o essere classificato come host-based o network-based. Un host-based IDS analizza i processi relativi ad un sistema operativo, a differenza dei network-based IDS che osservano i dati in transito su un segmento di rete.

2. “Analysis Boxes”: sono blocchi di processing e di generazione di al-larmi quando si rilevano violazioni delle policy di sicurezza, anoma-lie o intrusion. A seconda del tipo di analisi effettuata gli IDS si pos-sono ulteriormente classificare in: signature-based o anomaly-based, statelesso stateful.

I signature-based IDSs definiscono a priori dei modelli di attacco, o firme, e li confrontano con il traffico monitorato. Se c’è corrispon-denza, il sistema può generare l’allarme per un attacco noto in atto. Al contrario, i rilevatori basati su anomalie stimano il comporta-mento “normale” del sistema da proteggere e ogni volta che si os-serva una significativa deviazione dallo stesso generano un allarme. E’importante sottolineare anche che i dati di output di un analizza-tore possono diventare l’ingresso di blocchi che hanno il compito di svolgere analisi aggiuntive come la correlazione di dati in analisi. In tal caso, si potrà parlare di Statefull IDS o, alternativamente, di Stateless IDS.

3. “Database boxes”: il loro compito `e quello di registrare i dati tra-smessi dall’E-boxes secondo una propria configurazione;

(20)

2.2. HOST-BASED VS NETWORK-BASED IDSS

4. “Response boxes”, detto anche countermeasures boxes: il loro compi-to `e quello di generare delle contromisure adeguate al tipo di allarme notificato. Potrebbe trattarsi di semplici report relativi agli attacchi subiti (IDS passivi) o di una qualche azione attiva mirata a contenere la minaccia (IDS attivi)[13].

Nella sezione successiva si chiariscono i dettagli relativi alle varie ti-pologie di approcci che possono essere adottati.

2.2 Host-based vs Network-based IDSs

In funzione della natura dei dati osservati un IDS pu`o essere classificato come host-based o network-based.

Non appena furono progettate, le reti di computer avevano un’archi-tettura tipicamente mainframe: tutti gli utenti erano locali e dipendevano da un unico server centrale. Per garantire un servizio di anomaly detec-tion bastava implementare il rilevatore sul mainframe e monitorare dati campione come i file di log e i file di sistema.

Con lo sviluppo di terminali con capacit`a di calcolo propria, si rese necessario riadattare la tecnica basata su host: su ogni terminale venne-ro installati dei sensori di monitoraggio che filtravano il traffico dati e lo inoltravano al server centrale. Questo approccio processa informazioni di alto livello, come le system calls e i comandi eseguiti su un computer.

Tuttavia per questi sistemi si `e riscontrata la difficolt`a di rilevare at-tacchi diretti ai protocolli di rete. Questo ha portato allo sviluppo di luzioni che esaminassero direttamente i segmenti di rete: si tratta di

(21)

so-2.2. HOST-BASED VS NETWORK-BASED IDSS

luzioni network-based. Poichè gli accessi non autorizzati devono passare dal protocollo TCP/IP, i nuovi sistemi hanno iniziato a monitorare le in-formazioni trasportate nei campi di intestazione dei pacchetti IP. In questo modo un’unità di sorveglianza centrale non è più limitata al controllo di un singolo sistema, inteso come dispositivo, ma vigila su tutto il traffico dati della rete [6][9].

Figura 2.2: Network-based IDSs vs Host-based IDSs

La tendenza degli IDSs moderni `e comunque quella di combinare i due approcci: si raccolgono i dati relativi ai file di login e a informazioni di sistema come il carico della CPU, in coerenza con l’approccio H-IDSs, e si integrano con le informazioni relative alle connessioni TCP/IP come l’indirizzo IP di sorgente e quello di destinazione [13].

(22)

2.3. ANOMALY-BASED VS SIGNATURE-BASED IDSS

2.3 Anomaly-based vs Signature-based IDSs

Il flusso dati raccolto e prefiltrato viene inviato all’analizzatore che ha il compito di elaborare e valutare le informazioni ricevute secondo due approcci classici:

• Signature- based (o misuse-based): questi sistemi vengono anche detti “knowledge-based”. Basano la loro strategia di detection sulla conoscenza del modello del processo intrusivo e sul confronto del traffico monitorato con le firme di attacchi noti. Se c’`e equivalenza, l’IDS pu`o segnalare una violazione di sicurezza.

I principali svantaggi dei signature-based IDSs sono che i pattern di intrusione conosciuti richiedono normalmente di essere inseri-ti manualmente nel sistema; inoltre, sebbene quesinseri-ti modelli siano facilmente riconoscibili e classificabili, gli attacchi non noti potreb-bero non essere identificati.

Questi meccanismi quindi funzionano bene solo con attacchi ai quali si pu`o associare un modello comportamentale statico mentre perdo-no di efficienza nel caso di firme variabili.

• Anomaly-based o ”behaviour-based”. Il primo a proporre questo tipo di approccio fu Denning il quale pensò di studiare il comporta-mento dell’utente confrontandolo con un profilo di comportamen-to “normale”. Qualsiasi attività che devi dalla baseline tracciata è trattata come possibile intrusione.

Questa tipologia di IDS offre benefici significativi. In primo luogo hanno la capacit`a di rilevare gli attacchi interni: se qualcuno usa un

(23)

2.3. ANOMALY-BASED VS SIGNATURE-BASED IDSS

account rubato e genera un traffico che non è il linea con il compor-tamento tracciato per un utente legittimo, l’IDS produce un allarme. Un altro vantaggio è dato dal fatto che ogni sistema è identifica-to da profili di comportamenidentifica-to diversi: diventa molidentifica-to difficile per l’aggressore svolgere un’attività che sia a loro conforme e che non generi un allarme.

Un approccio di questo tipo si sviluppa su una fase di training e una di test. La fase di training rappresenta uno stadio molto importante da cui dipende la capacit`a del sistema di funzionare in modo efficien-te o meno: la creazione di un profilo di traffico normale, se non do-vesse rispecchiare l’effettiva attivit`a degli utenti legittimi, potrebbe generare numerosi falsi allarmi[10].

La principale differenza tra le due metodologie sopra enunciate risiede nel-la diversità tra il concetto di “attacco” e quello di “anomalia”. Un attacco può essere definito come “una sequenza di operazioni che mettono a ri-schio la sicurezza di un sistema” al contrario di un’anomalia che può esse-re interpesse-retata semplicemente come un evento che risulta esseesse-re sospetto in termini di sicurezza.

Il trend moderno `e comunque quello di integrare i due approcci in un unico rilevatore, anche noto come hybrid detection system: `e un sistema che basa la fase di rilevazione sui profili di comportamento normale e sulle firme che identificano processi intrusivi noti.

(24)

2.4. STATELESS IDSS VS STATEFUL IDSS

2.4 Stateless IDSs vs Stateful IDSs

Gli stateful IDS rappresentano un articolato protocollo di analisi mediante il quale si paragonano profili predefiniti, relativi a definizioni universal-mente accettate di come determinati protocolli debbano essere utilizzati, con il tipo di attività realmente osservata: in questo modo, l’IDS è in grado di riconoscere e tracciare lo stato di protocolli di rete, trasporto o appli-cazione per i quali la nozione di stato sia presente[6]. E’ un sistema più complesso da mettere in pratica, ma nello stesso tempo dimostra una mag-giore efficacia in presenza di attacchi distribuiti nel tempo al contrario de-gli stateless i quali, se pur di semplice realizzazione e prestanti in termini di velocità di processing, trattano ogni evento in modo indipendente dagli altri e rilevandosi poco efficiente[18].

2.5 IDSs passivi vs IDSs attivi

Il rilevamento delle intrusioni rappresenta una tecnologia passiva: rileva e riconosce un problema ma non interrompe il traffico della rete e non si preoccupa di applicare alcuna contromisura che possa mitigare la perico-losità dell’attacco. Tuttavia, col tempo, si è sempre più sentita l’esigen-za di integrare le capacità degli IDS rendendoli capaci di rispondere alla minaccia.

Gli IDSs attivi possono esercitare la loro forma di controllo sul sistema attaccato o sul sistema di attacco. Mentre i primi tutelano il bersaglio ap-plicando azioni di rollback e bloccando le connessioni di rete pericolose, la seconda tipologia di IDSs attacca direttamente la piattaforme

(25)

dell’uten-2.5. IDSS PASSIVI VS IDSS ATTIVI

te malintenzionato. Potremmo quindi dire che gli IDS definiti attivi sono strumenti che, oltre a fare detection, incorporano funzioni tipiche di un sistema intrusion tolerant[6].

(26)

Capitolo 3

Statistical anomaly-based

Intrusion Detection

Systems

3.1 Introduzione agli A-NIDSs

I particolari algoritmi di detection trattati nel resto di questo elaborato sono di tipo network-based e anomaly-based. E’ interessante notare che questi si sviluppano su due fasi:

• fase di apprendimento, durante la quale viene definito il profilo di traffico assumendo che questo non sia soggetto ad intrusioni; • fase di monitoraggio e test, durante la quale il sistema analizza la

(27)

na-3.2. ANALISI STATISTICA DI TIPO UNIVARIATE, BIVARIATE E MULTIVARIATE

tura dei dati monitorati mediante confronto con il profilo tracciato durante la fase di training.

In funzione del tipo di elaborazione utilizzato, le tecniche di rileva-zione delle anomalie possono essere classificate in tre grandi categorie: statistical-based, knowledge-based e machine learning-based. Nel corso di questo capitolo si approfondisce esclusivamente il primo approccio (si ri-manda a testi pi`u dettagliati per la descrizione delle tecniche alternative a quella sviluppata [11]).

3.2 Analisi statistica di tipo univariate,

biva-riate e multivabiva-riate

Secondo quanto riportato in [12], un anomaly-based IDS caratterizza il comportamento normale ( privo di anomalie) del sistema, in termini di metriche e modelli statistici.

Per metrica si intende una variabile aleatoria che, monitorata su un deter-minato periodo, fornisce una misura accumulata di uno specifico dato. Per i sistemi di nostro interesse (network-based), queste variabili forniscono dunque informazioni legate ai campi di intestazione dei pacchetti IP (ad esempio numero di porte TCP o UDP di sorgente e destinazione, numero di Byte e pacchetti, etc).

Nel modello trattato da Denning, per la valutazione della metrica osservata possono seguirsi diversi approcci statistici:

• Modello operazionale: `e basato sull’assunzione che l’anomalia possa

(28)

3.2. ANALISI STATISTICA DI TIPO UNIVARIATE, BIVARIATE E MULTIVARIATE

essere rilevata comparando una nuova osservazione con certi valori di soglia. Questo approccio `e applicabile a tutte quelle metriche per le quali l’esperienza ha mostrato che certi valori sono indicatori di intrusione;

• Media e deviazione standard: questo modello si basa su due soli pa-rametri della sequenza di osservazioni considerata. Non richiede conoscenza a priori dell’attività normale per impostare le soglie di valutazione; al contrario, il sistema è in grado di imparare ciò che costituisce l’attività normale dalla diretta osservazione.

Questo tipo di modello risponde ad un approccio di tipo univariate: il sistema modella il comportamento della rete a partire dall’azione di monitoraggio di un solo descrittore di traffico.

• Modello Multivariato: molto simile al precedente ma si basa sulla correlazione tra 2 o più metriche. L’idea alla base di questo ap-proccio è molto semplice: il modello del comportamento della rete sarà tanto più accurato quanto maggiore è il numero di descrittori di traffico considerato (o come precedentemente definiti, metriche). Un IDSs che considera un solo descrittore potrebbe essere ingannato da quelle intrusioni che provocano anomalie in parametri differen-ti. Per questo motivo è bene studiare il comportamento di variabili casuali bivariate, nel caso di due metriche ( è l’approccio adottato per l’implementazione dell’algoritmo proposto), o multivariate nel caso di più metriche.

(29)

maggio-3.3. TECNICHE DI ANALISI PARAMETRICHE E NON PARAMETRICHE

re complessità del sistema, poichè aumenta il potere discriminan-te del rilevatore, operando un’osservazione congiunta di due o più metriche [11].

3.3 Tecniche di analisi parametriche e non

pa-rametriche

Un altro fattore critico che si vuole sottolineare `e la natura parametrica o non parametrica degli algoritmi proposti per la detection delle anomalie.

Secondo un approccio parametrico, i modelli utilizzati dispongono a priori dell’informazione di distribuzione statistica delle metriche conside-rate: un’anomalia corrisponde ad un cambio di parametro della distribu-zione [14]. Purtroppo non sempre è possibile caratterizzare la natura del traffico osservato, nè in presenza di anomalie nè quando si fa riferimento ad attività di traffico note.

Per ovviare a questo problema si introduce un approccio di tipo non parametrico: il sistema `e in grado di apprendere, in seguito ad una fase di training, quale sia la normale distribuzione delle features dalla solo osser-vazione di tracce che si suppone non contenere anomalie.

Tra le soluzioni sviluppate per implementare algoritmi di questa tipologia, si valuta quella che organizza i dati in istogrammi [15].

Un istogramma rappresenta il numero di flussi, pacchetti o byte (osserva-ti durante un intervallo di tempo prestabilito, detto (osserva-time bin) in funzione dei possibili valori di una o pi`u combinazioni di metriche. Un algoritmo

(30)

3.3. TECNICHE DI ANALISI PARAMETRICHE E NON PARAMETRICHE

di anomaly detection basato sulla costruzione di istogrammi prevede le seguenti fasi:

• Estrazione delle metriche di traffico, in funzione degli attacchi che si crede di subire (gli attacchi possono causare anomalie in metriche diverse);

• Costruzione degli istogrammi di riferimento: durante la fase di trai-ning, si sfrutta l’osservazione del traffico non anomalo per definirne le caratteristiche;

• Costruzione degli istogrammi di test, osservando il traffico da moni-torare in ogni time bin;

• Calcolo della statistica di decisione secondo quanto riportato in (4.3); • Test di decisione a soglia.

(31)

Capitolo 4

Bivariate Non-Parametric

Algorithm Detection

Questo capitolo presenta l’analisi di un algoritmo non parametrico di tipo bivariate per la rilevazione delle anomalie di rete.

Sono stati proposti approcci che considerano le informazione relative ai campi di intestazione dei pacchetti IP: questa caratteristica rende il sistema robusto al traffico dati soggetto a crittografia e a tecniche di tunneling.

E’ importante sottolineare un altro aspetto pratico: a causa della natura fortemente variabile del traffico di Internet, `e poco realistico stimarne una distribuzione a priori che consenta di fare detection. Per questo motivo, in questo elaborato, si sviluppa un algoritmo che esegue un’analisi statistica non parametrica delle metriche monitorate.

In questo capitolo si forniscono i dettagli implementativi relativi

(32)

4.1. DATASET UTILIZZATO E DATA FORMATTING

l’architettura di sistema raffigurato in figura 4.1.

Figura 4.1: Architettura di sistema

4.1 Dataset utilizzato e Data Formatting

Le tracce utilizzate per eseguire e valutare il test statistico proposto sono relative al traffico memorizzato nel dataset MAWILab (Measurement and Analysis of the Wide Internet Laboratory)[21].

Prima di essere impiegati come dati di ingresso è necessario applicare una conversione dal formato pcap, che riporta le informazioni memorizza-te pacchetto per pacchetto, in formato NetFlow. Questa conversione pro-durrà un file distinto per ogni time bin considerato (ogni time bin è riferito al giorno durante il quale si memorizzano i 15 minuti di traffico) ed è ne-cessaria perché i nostri algoritmi si aspettano in ingresso le informazioni relative ai flussi.

La procedura di conversione `e possibile tramite tre tool open source reperibili liberamente in rete: Softflowd, Nfdump e Nfcapd:

(33)

4.2. STRUTTURE DATI

• Softflowd `e un analizzatore di traffico in grado di mettersi in ascolto su un’interfaccia di rete, leggere un file di acquisizione di pacchetti e esportarli tramite il protocollo Netflow, in modo che possano essere raccolti dal tool Nfcapd;

• Nfcapd legge i dati provenienti da Softflowd e li archivia ogni n mi-nuti in file secondo il timestamp YYYYMMddhhmm dell’intervallo (ad esempio il file nfcapd.200407110845 contiene i dati dell’11 luglio 2004 dalle 08:45 per gli n minuti successivi);

• Nfdump legge i dati memorizzati da Nfcapd e li converte in un for-mato intelligibile sullo standard di output (quindi da un terminale Linux), registrando le statistiche di interesse flusso per flusso. Nel dettaglio, ogni file conterr`a un elenco di chiavi (ad esempio, l’elen-co degli indirizzi IP di destinazione) e i pesi ad esse associati (ad esempio, il numero di byte ricevuti da tale indirizzo IP).

4.2 Strutture dati

Dati i problemi di scalabilit`a che si avrebbero nel memorizzare contatori distinti per ogni flusso, si valutano soluzioni che prevedono l’uso di strut-ture statistiche, anche note come sketches[16][17], che sintetizzino in mo-do casuale aggregati di traffico. Nel dettaglio, in questo elaborato si utilizza il K-ary Sketch: si tratta di una matrice Count[d][w] costituita da D righe e W colonne.

Come precedentemente specificato, gli algoritmi presentati nel seguito di

(34)

4.2. STRUTTURE DATI

questo elaborato sono di tipo bivariate: consistono nell’osservazione con-giunta di due descrittori di traffico. Si assume allora che lo stream di dati di input sia una coppia di parametri (chiave, peso) (it,ct) , dove itdove ctsar`a

quindi costituito da due valori tali per cui ct=[ct(0), ct(1)]T. Di conseguenza,

anche le celle dello sketch rappresentano vettori bidimensionali C[d][w]=[ C0[d][w], C1[d][w] ]Tche verranno aggiornati secondo la funzione:

Cl[d][hd(it)] ← Cl[d][hd(it)] + ct(l) ∀l = 0, 1; ∀d = 0, 1, ..., D − 1

(4.1)

Figura 4.2: Aggiornamento di uno sketch

Ad una generica riga di indice d : d = 1, 2, ..., D si associa una parti-colare funzione di hash hdche legge la chiave ite rimappa il peso ctin uno

specifico bucket dello sketch. In questo modo, al termine del time bin, il valore della generica cella Cl[d][w]corrisponder`a alla somma dei pesi ct(l)

associati all’aggregato di chiavi itche, processate dalla funzione di hash

(35)

4.3. ALGORITMO DI RILEVAZIONE

4.3 Algoritmo di rilevazione

Una volta costruiti gli sketches bidimensionali, per ogni time bin, `e pos-sibile applicarvi un qualsiasi algoritmo di rilevazione: noi proponiamo il Bivariate Non-Parametric Detection Algorithm[19]. Consideriamo di esse-re al time bin t. Il sistema analizza l’evoluzione di due metriche X e Y nei precedenti W time bins. Per far questo, vengono definite due finestre temporali disgiunte:

• W0data dagli N1time bins di riferimento precedenti a {t-N2};

• W1data da N2time bins sotto test.

L’algoritmo di rilevazione prevede il calcolo di due funzioni:

     FX= µX,1+σ2X,1 µX,0+σ2X,0 FY= µY,1+σY,12 µY,0+σY,02 (4.2)

dove i pedici si riferiscono rispettivamente alla metrica sotto test X, Y e alle finestre temporali 0, 1.

I generici parametri µ e σ2_{rappresentano una stima di media e varianza,}

calcolati secondo l’algoritmo di EWMA (Exponentially Weighted Moving Average):      ˆ µk= αˆµk−1+ (1 − α)yk; ˆ σ2_k= αˆσ2_k−1+ (1 − α)(yk− ˆµk)2; (4.3)

dove α `e un parametro compreso tra 0 e 1 e pesa in modo diverso le osservazioni precedenti da quella corrente; ˆµk−1e ˆσ2k−1rappresentano la

(36)

stima EWMA di media e varianza nel time bin precedente e yk

rappresen-ta il campione corrente. Si noti che le srappresen-tatistiche FXe FYdevono essere

calcolate per ogni bucket dello sketch costruito per il time bin di test (per semplicit`a di notazione abbiamo omesso la dipendenza dagli indici di riga e colonna degli sketches).

Una volta calcolate le due funzioni FXe FYsi esegue un test di

decisio-ne. Nel dettaglio si considerano due valori di soglia TA e TBe si decide

(37)

Figura 4.3: Blocco di Decisione

In particolare possono verificarsi tre casi specifici[19]:

1. FX< TA, FY< TA. Entrambe le statistiche sono inferiori al valore di

soglia minimo, quindi si può stabilire che durante il time bin sotto test non è stata rilevata alcuna anomalia. In questo caso, la finestra W0di riferimento verrà aggiornata;

(38)

2. FX> TB, FY> TB. Entrambe le statistiche deviano dal

comporta-mento normale di traffico di un valore superiore alla quantit`a mas-sima stabilita. Il time bin sotto test risulta anomalo e, per questo, la finestra di riferimento non viene aggiornata;

3. FX> TB, FY< TBe viceversa. In questo caso si definisce una nuova

finestra costituita da Nctime bins di controllo. A partire da {t+1} si

calcola e si controlla fino al time bin {t+1+τ} che anche la statistica Y, non anomala nel time bin di test, non ecceda la soglia massima considerata. Se questo dovesse verificarsi, in conseguenza al fatto che un’alterazione della metrica X pu`o causare delle variazioni nella metrica Y durante gli Nctime bins successivi, si decide che il time

bin sotto test `e sospetto e, per questo, la finestra di riferimento non viene aggiornata.

Implementando questa strategia di decisione per ciascun bucket dello sketch di test, se FXe FYeccedono TBper almeno un numero H di righe ( H `e

un valore che generalmente si setta a D

2+1con D numero totali di righe

che compongono lo sketch ), il time bin sotto sotto test viene considerato anomalo.

Si evidenzia che l’aggiornamento della finestra di riferimento W0

av-viene solo quando entrambe le statistiche di decisione sono al di sotto di TA. La ragione di tale scelta si deve al fatto che una corretta decisione

`e strettamente vincolata alla costruzione di una finestra di riferimento che rispecchi effettivamente il traffico legittimo del sistema: `e necessa-rio quindi che W0sia costituita da time bins che si ritengono sicuramente

(39)

La possibilit`a di costruire una finestra di controllo che ispezioni l’evo-luzione temporale di una delle due metriche permette di ignorare le flut-tuazioni istantanee dell’altra e di aumentare le prestazioni del sistema in termini di probabilit`a di falso allarme[19].

(40)

Capitolo 5

Risultati sperimentali

In quest’ultimo capitolo vengono valutati i risultati ottenuti testando l’al-goritmo di detection descritto in (4.3) e se ne discutono le prestazioni.

Le prestazioni di un sistema sono comunemente descritte in termini di falsi positivi e falsi negativi e vengono rappresentate tramite curva ROC (Receiver Operating Characteristic): per far questo, si esegue un confronto tra i flussi ritenuti anomali dall’algoritmo BnPDA e quelli che realmente lo sono in funzione delle label con le quali i filtri presenti nell’archivio MAWI etichettano le tracce monitorate. Si propongono nella sezione successiva i dettagli.

5.1 Tracce MAWI

Le prove sperimentali sono state realizzate impiegando come dati di in-put alcune delle tracce di traffico reperibili nell’archivio MAWILab.

(41)

L’ar-5.1. TRACCE MAWI

chivio contiene più di nove anni di tracce relative a 15 minuti di traffico giornaliero registrato sul link trans-Pacifico dal Giappone agli Stati Uni-ti. I dati sono stati memorizzati giornalmente a partire dal Gennaio 2001 e contengono le informazioni relative agli header dei pacchetti del livello IP e del livello trasporto (suddette informazioni sono disponibili online; gli indirizzi IP sono stati resi anonimi e vengono omesse le informazioni di payload). Tramite rilevazione eseguita da quattro detector differenti (i quali implementano algoritmi basati su Trasformata di Hough, divergenza di Kullback-Leibler, Principal Component Analysis e distribuzione Gamma), il contributo più significativo fornito dal progetto MAWI è stato quello di classificare le tracce monitorate come segue:

• anomalous: traffico quasi certamente anomalo;

• suspicious: traffico che con alta probabilit`a pu`o essere considerato anomalo;

• notice: traffico non anomalo ma segnalato da almeno un detector; • benign: traffico non anomalo, non segnalato da nessun detector. Inoltre, i flussi etichettati come ”anomalous” sono a loro volta suddivisi in:

• attack: anomalie riconducibili ad attachi noti;

• special: anomalie associate ad attivita che coinvolgono porte well-known;

• unknown: anomalie di tipo sconosciuto, che non rientrano nelle due categorie precedenti.

(42)

5.1. TRACCE MAWI

Il traffico etichettato come anomalous, suspicious o notice `e riportato in due file di tipo xml per traccia analizzata (uno per le anomalie di tipo ano-malouse suspicious, uno per quelle di tipo notice), dove per ogni anomalia individuata vengono riportati:

• T: tipo di anomalia (anomalous, suspicious o notice);

• Dr, Da: distanze da due punti di riferimento rispettivamente per il traffico regolare e anomalo. Si utilizza l’algoritmo opportuno (SCANN) per processare le uscite dei quattro detector; sulla base di tali va-lori viene deciso il tipo di anomalia. In particolare a questa vie-ne assegnata la label anomalous se Da≤Dr,suspicious se Da>Dr e Da/Dr-1≤0.5, notice se Da/Dr-1>0.5;

• C: numero associato alla categoria dell’anomalia: gli attack sono contraddistinti da 1 ≤ C ≤ 500, le anomalie special sono carat-terizzate da 500 < C ≤ 900 mentre per gli unknown si ha che C > 900);

• V: vettore costituito da 12 elementi binari i cui valori indicano quali detector hanno rivelato l’anomalia e con quale modalit`a di lavoro. In ordine, il vettore riporta: Hough (sensitive, optimal, conservati-ve), Gamma (sensitive, optimal, conservaticonservati-ve), KL (sensitive, optimal, conservative), PCA (sensitive, optimal, conservative).

• Filtri che identicano l’anomalia tramite feature del traffico; • Timestamp che forniscono informazioni sull’inizio e la fine del

(43)

5.1. TRACCE MAWI

Tramite confronto tra le tracce che l’algoritmo proposto distingue in anomalous e normal e la classificazione effettuata a partire dal calcolo dei parametri di cui sopra, si caratterizzano le prestazione del sistema proposto in termini di falsi positivi e falsi negativi.

I falsi positivi sono i flussi considerati anomali dal sistema ma che sono etichettati dall’archivio MAWI come benign o notice; i falsi negativi sono invece i flussi etichettati come anomalous che non vengono rilevati.

Valutando anche la categoria cui appartiene l’anomalia ( attack, spe-cial, unknown), si pu`o ridefinire il concetto di falso negativo e rivalutare le prestazioni complessive del sistema testato. Le possibili definizioni cui si fa riferimento sono le seguenti [18]:

1. ”fn 2/3/4 detector”: considera falsi negativi le mancate rivelazioni di flussi etichettati come anomalous individuati da 2/3/4 dei quattro detector usati dal progetto MAWI;

2. ”fn attack”: considera falsi negativi le mancate rivelazioni di flussi etichettati come anomalous appartenenti alla categoria attack, ossia quella degli attacchi noti;

3. ”fn attack special”: considera falsi negativi le mancate rivelazioni di flussi etichettati come anomalous appartenenti alla categoria attack o alla categoria special (attacchi che utilizzano porte well-known); 4. ”fn unknown”: considera falsi negativi le mancate rivelazioni di

flus-si etichettati come anomalous appartenenti alla categoria unknown (attivita anomale sconosciute);

(44)

5.2. PROVE SPERIMENTALI

5. ”fn unknown 4 detector”: considera falsi negativi le mancate rivela-zioni di flussi etichettati come anomalous appartenenti alla catego-ria unknown, individuati da tutti i quattro detector.

A partire dalle definizioni di falsi positivi e falsi negativi, le prestazioni possono essere valutate in termini di:

• probabilit`a di falso allarme PFA, calcolata come il rapporto tra il

numero di falsi positivi e il numero totale di tracce non anomale ( identificate nell’archivio MAWI dalle label notice e benign); • probabilit`a di mancato avvistamento PMA, calcolata come il

rap-porto tra il numero di falsi negativi ( a cui si associano definizioni diverse e, quindi, conteggi diversi) e il numero totale di tracce con-siderate anomalous e suspicious. Si noti che PMA=(1 − PD), con PD

uguale alla probabilit`a di detection.

5.2 Prove sperimentali

L’implementazione di un algoritmo di tipo bivariate non parametric si basa sulle seguenti operazioni:

• Estrazione delle features di traffico;

• Costruzione di N1sketches di riferimento, leggendo le tracce ripulite

dalle anomalie mediante i filtri presenti nell’archivio MAWI; • Costruzione di N2sketches di testnei time bins successivi a quelli di

(45)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO

• Detection tramite il calcolo delle statistiche di decisione per ogni bucket dello sketch sotto test.

Prima di discutere i risultati ottenuti tramite il test statistico proposto, si sono rese necessarie alcune considerazioni preliminari riguardo l’estra-zione delle metriche di traffico e la scelta delle lunghezze delle finestre di riferimento, di test e di controllo (nel dettagio, N1, N2, Nc).

Sono stati proposti dei test per valutare la scelta di parametri otti-mi che permettessero una otti-miniotti-mizzazione della probabilit`a di falso allar-me e di mancato avvistaallar-mento e, quindi, migliori prestazioni del sistema presentato.

5.3 Estrazione delle

features di traffico

Si ricorda che lo stream dei dati di input pu`o essere interpretato come una coppia di parametri (it, ct(i)) con ct(i)) vettore bidimensionale.

Il primo aspetto valutato quindi `e stato la scelta delle metriche con cui ag-giornare le strutture di dati. Prendendo in considerazione le anomalie che possono essere riscontrate in una generica traccia, i descrittori di traffico monitorati sono:

1. Numero di byte;

2. Numero di porte destinatarie TCP o UDP diverse (dst port); 3. Numero di sorgenti TCP o UDP diverse (src port);

4. Numero di pacchetti TCP con flag SYN settato;

(46)

5. Numero di pacchetti.

Le metriche appena elencate vengono impiegate per costruire il vet-tore di incremento ctcon il quale, per ogni entry presente nella traccia di

ingresso vengono aggiornati i valori dello sketch. L’algoritmo BnPDA `e stato implementato considerando quattro coppie di features:

1. (byte, dst port); 2. (byte, src port); 3. (byte, syn); 4. (byte, pkts).

Quello che è emerso testando la traccia riferita al giorno 2007 01 02 è che la coppia (Byte, src port) e (Byte, pkts) hanno fornito prestazioni mi-gliori in termini di PFA(probabilità di falso allarme) e di PD( probabilità di

detection). Questa prima valutazione ci ha permesso di restringere il cam-po delle coppie di metriche da testare. Si ricam-portano in (5.1) i grafici delle prestazioni garantite dalle quattro coppie di metriche considerate.

(47)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale

(a) (Byte, dst port)

0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (b) (Byte, src port)

(48)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (c) (Byte, syn) 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (d) (Byte, pkts)

(49)

Quanto alla scelta delle lunghezze delle finestre di riferimento, di test e di controllo, abbiamo ritenuto opportuno valutare diverse configurazioni:

• N1=1, N2=1, Nc=1;

• N1=2, N2=1, Nc=0;

• N1=1, N2=2, Nc=0;

• N1=2, N2=2, Nc=0;

Fissata la coppia di metriche (Byte, pkts) abbiamo valutato le relative ROC:

(50)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (a) N1=1, N2=1, Nc=1; 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (b) N1=2, N2=1, Nc=0;

(51)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (c) N1=1, N2=2, Nc=0; 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (d) N1=2, N2=2, Nc=0;

Figura 5.2: Prestazioni calcolate al variare della lunghezza delle finestre

(52)

Andamenti simili sono garantiti anche dalle features (Byte, src port). Da quanto rappresentato in figura (5.2), si evince che la configurazione che offre prestazioni vantaggiose `e quella per cui N1=N2=Nc=1.

Queste prove preliminari si sono rese utili per una scelta ottima delle grandezze che entrano in gioco per il calcolo delle statistiche di decisione. Nella fase finale, si sono valutate le prestazioni complessive garantite dalle due coppie di metriche (Byte, src port) e (Byte, pkts).

(53)

(a) (Byte, src port)

0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (b) (Byte, pkts)

(54)

(c) (Byte, src port), fn unknown 4 detector

0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale

(d) (Byte, pkts), fn unknown 4 detector

(55)

Quello che si evince dai grafici `e che usare come metrica il numero di porte sorgenti diverse offre migliori prestazioni. Si nota inoltre un netto miglioramento delle performance garantite dal sistema nel caso in cui si consideri come falso negativo la mancata rilevazione di flussi etichettati come anomalous appartenenti alla categoria unknown, individuati da tutti i quattro detector.

Una implementazione alternativa del BnPDA prevede il monitorag-gio dell’entropia delle metriche considerate. Lo schema di formattazio-ne dei dati rimaformattazio-ne lo stesso: lo stream di dati ingresso vieformattazio-ne visto come una serie temporale di elementi cui si associano una coppia di variabili ( it,ct(i)), dove it `e la chiave (ancora l’indirizzo IP di destinazione)

men-tre ct rappresenta un vettore bidimensionale che questa volta considera

non semplicemente le metriche fornite dalle tracce NetFlow, ma la loro entropia.

L’entropia di una variabile aleatoria X, secondo la definizione di Shan-non, rappresenta una misura della variabilit`a associata alla variabile stessa. Nel dettaglio, si consideri P={p1, p2,…, pB}il vettore delle probabilit`a di

distribuzione della variabile X, tale per cui:

pb= P r{X = b} B

X

b=1

pb= 1

l’ entropia di Shannon `e allora definita come:

H(X) = −

B

X

b=1

pblog2pb. (5.1)

Perch`e il sistema sia capace di calcolare l’entropia associata ad un deter-minato aggregato di traffico, `e stato necessario introdurre degli sketches

(56)

tridimensionali Cl[d][w][b], dove la terza dimensione serve per calcolare

gli istogrammi e quindi le probabilit`a di distribuzione pb delle metriche

c_l={ct(0), ct(1)}. Nel dettaglio, viene utilizzata una seconda funzione di

hashing hd2, indipendente dalla prima, che mappa ogni chiave di input in

un determinato bucket dell’istogramma. Formalmente, per ogni dato di ingresso ricevuto, lo sketch si aggiorner`a come segue:

Cl[d][h1d(it)][h2d(ct)] ← Cl[d][h1d(it)][h2d(ct)] + 1. (5.2)

Una volta calcolata l’entropia, per ogni bucket dello sketch, si seguono le procedure indicate nel quarto capitolo per l’elaborazione delle statisti-che di test FX e FY ( in questo caso, X o Y , o entrambe, rappresentano

non semplicemente le metriche, ma la loro entropia). Per valutare le pre-stazioni ottenute implementando l’algoritmo di BnPDA che consideri la variabilit`a dei descrittori di traffico, sono stati effettuati diversi test. Rite-nendo ancora valida la scelta delle lunghezze delle finestre di test, riferi-mento e controllo pari a 1, durante le prove sperimentali effettuate, sono state considerate le seguenti metriche:

1. (H(byte), src ip); 2. (byte, H(src ip)); 3. (H(byte),H(src ip));

Si riportano di seguito le prestazioni calcolate secondo la tradiziona-le definizione di falsi negativi e secondo la definizione ”fn unknown 4 detector”

(57)

(a) (H(byte), src ip);

(58)

5.3. ESTRAZIONE DELLE FEATURES DI TRAFFICO 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (b) (byte, H(src ip)); 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (c) (H(byte),H(src ip));

(59)

5.4. CONFRONTO CON ALTRI ALGORITMI

Dai grafici (5.4.b) e (5.4.c) si può osservare che gli algoritmi bivariate che implementano la costruzione di statistiche legate al concetto di en-tropia hanno prestazioni non soddisfacenti: si ha infatti una probabilità di corretta rivelazione troppo bassa per i valori della probabilità di falso allarme di interesse (minori di 0.2). Solo il caso (a) risulta ottenere pre-stazioni accettabili ma comunque inferiori rispetto a quelle garantite dalle prove sperimentali le cui ROC sono mostrate in figura (5.3.a) e (5.3.c)

5.4 Confronto con altri algoritmi

Nell’ultima fase di test viene effettuato un confronto con un algoritmo di anomaly detection noto in letteratura e che offre ottimi risultati, il CUSUM bidimensionale[18]. In questo caso vengono analizzate le tracce presenti nell’archivio MAWILab, sulle quali le operazioni di formattazione e aggre-gazione dei dati restano invariate rispetto a quanto descritto nel capitolo 4. La differenza risiede nel fatto che viene costruito uno sketch per ogni metrica analizzata e si fa detection tramite l’osservazione indipendente e simultanea delle metriche considerate. In figura (5.5) viene rappresentata l’architettura di sistema.

Formalmente, per ogni campione osservato nella sequenza temporale y(k)={y1(k), y2(k)}, dove k rapresenta l’indice del time bin sotto test, si

calcolano le stime di media e varianza secondo l’algoritmo EWMA:

ˆ

µl(k) = αˆµl(k − 1) + (1 − α)yl(k) (5.3)

ˆ

σ2_l(k) = αˆσ2_l(k − 1) + (1 − α)(yl(k) − ˆµl(k))2 (5.4)

(60)

5.4. CONFRONTO CON ALTRI ALGORITMI

Figura 5.5: Architettura di sistema

e, successivamente, la somma cumulativa g(k):

L(y(k)) = ||y(k) − y(k − 1)|| − (||ˆµ(k)|| + cp||σ2_(k)|| (5.5)

g(k) = max{0, g(k − 1) + L(y(k))} (5.6) Una volta calcolata la statistica di decisione, questa viene confrontata con il valore di soglia prestabilito h, per decidere se il campione osservato `e anomalo. Quando la statistica di decisione supera h, viene registrato un allarme[18]. Come per il BnPDA, anche in questo caso proponiamo un monitoraggio bidimensionale e non parametrico dei dati. Di seguito si riportano le prestazioni a confronto dei due algoritmi.

Per quanto abbiano prestazioni paragonabili per probabilit`a di falso allarme alte, l’algoritmo di BnPDA offre PDmigliori per valori di PFAal di

(61)

5.4. CONFRONTO CON ALTRI ALGORITMI 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (a) BnPDA 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale (a) CUSUM

(62)

5.4. CONFRONTO CON ALTRI ALGORITMI 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale

(63)

5.4. CONFRONTO CON ALTRI ALGORITMI 0 0.2 0.4 0.6 0.8 1 P(falso allarme) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 P(corretta rivelazione) ROC ROC diagonale

(a) BnPDA, fn unknown 4 detector

Figura 5.6: Confronto ROC complessive di BnPDA e CUSUM calcolate fissata la coppia di metriche (Byte, src port)

(64)

Capitolo 6

Conclusioni

Il lavoro svolto nel corso di questo elaborato ha cercato di dimostrare la fattibilit`a di un sistema di anomaly-based Intrusion Detection che applichi un’analisi statistica bivariata e non parametrica dei dati da proteggere.

Impiegando come dataset un sottoinsieme di tracce presenti nell’ar-chivio MAWILab, l’analisi sviluppata ha integrato il test statistico basato sul BnPDA con la tecnica di organizzazione dei dati del Count-Min Sketch, consolidata nell’ambito dell’Intrusion Detection. Nel dettaglio si applicano le procedure di aggiornamento delle strutture di sketches utilizzando come chiave l’indirizzo IP di destinazione e come pesi le coppie di metriche :

• (byte, dst port) con lo scopo di individuare le vittime di un attacco Dos/DDos;

(65)

• (byte, syn) e (byte, pkts) per scoprire un attacco DoS ( nel primo caso di tipo SYN flooding).

A seguito di questa prima fase sperimentale, è stato introdotto il con-cetto di entropia: mantenendo lo stesso algoritmo, è stata costruita la sta-tistica di decisione non semplicemente sui descrittori di traffico ma sfrut-tando l’informazione di entropia. Non si può dire in assoluto che tali algo-ritmi si siano mostrati efficienti nella rilevazione di attacchi noti poiché è stato possibile osservare un miglioramento significativo delle prestazioni nella ricerca di anomalie di tipo sconosciuto.

Per finire, il test che ha offerto migliori garanzie di rilevazione `e sta-to confrontasta-to con un algoritmo bidimensionale di CUSUM. Il confronsta-to non ha evidenziato particolari differenze per PF A alte, mentre nel

ran-ge di valori di interesse, il BnPDA ha garantito prestazioni sensibilmente migliori.

(66)

Elenco delle figure

2.1 Architettura CIDF per sistemi di ID . . . 17

2.2 Network-based IDSs vs Host-based IDSs . . . 20

4.1 Architettura di sistema . . . 31

4.2 Aggiornamento di uno sketch . . . 33

4.3 Blocco di Decisione . . . 36

5.1 Prestazioni calcolate al variare delle metriche . . . 47

5.2 Prestazioni calcolate al variare della lunghezza delle finestre 50 5.3 Prestazioni calcolate al variare delle metriche . . . 53

5.4 Prestazioni calcolate al variare delle coppie di metriche. . . 57

5.5 Architettura di sistema . . . 59

5.6 Confronto ROC complessive di BnPDA e CUSUM calcolate fissata la coppia di metriche (Byte, src port) . . . 62

(67)

Bibliografia

[1] Commissione per i diritti e i doveri relativi ad Internet (2014), Dichiarazione dei Diritti in Internet, Camera dei Deputati.

[2] Kris Jamsa(2002), Kacker proof. Sicurezza in rete, Mc-Graw Hill [3] (2017), Rapporto Clusit 2017 sulla sicurezza ICT in Italia.

[4] Christian Callegari, (2007) Intrusion Detection System, Slide delle le-zioni del corso di Sicurezza nelle Reti, Universit`a di Pisa, Ingegneria delle Telecomunicazioni.

[5] Stefan Axelsson, (2000), Intrusion Detection Systems:A Survey and Ta-xonomy, Department of Computer Engineering Chalmers University of Technology Goteborg, Sweden

[6] Alberto Menichetti, (2005) INTRUSION DETECTION SYSTEMS. Tecni-che per la rilevazione di intrusioni sui sistemi informatici, Tesi di Laurea Informatica, Universit`a degli Studi di Firenze

[7] David Ahmad Effendy, Kusrini Kusrini, Sudarmawan Sudarma-wan (2017), Classification of Intrusion Detection System (IDS) Based

(68)

BIBLIOGRAFIA

on Computer Network, 2nd International Conferences on Informa-tion Technology, InformaInforma-tion Systems and Electrical Engineering (ICITISEE)

[8] Xiaoting Li, Jin Meng, Haiyan Zhao, Jing Zhao (2015), Overview of In-trusion Detction Systems. Journal of Applied Science and Engineering Innovation, Vol.2 No.6.

[9] Rafath Samrin, D Vasumathi, (2017), Review on Anomaly based Net-work Intrusion Detection System,International Conference on Elec-trical, Electronics, Communication, Computer and Optimization Techniques (ICEECCOT)

[10] Animesh Patcha , Jung-Min Park(2007), An overview of anomaly de-tection techniques: Existing solutions and latest technological trends, Computer Network.

[11] P. Garcıa-Teodoro, J. Dıàz-Verdejo, G. Macia-Fernàndez, E. Vàzquez, (2009) Anomaly-based network intrusion detection: Techniques, systems and challenges

[12] Dorothy E. Denning, (1987), An Intrusion-Detection Model. IEEE Transactions on Software Engineering.

[13] Xiaoting Li, Jin Meng, Haiyan Zhao, Jing Zhao (2015), Overview of In-trusion Detction Systems. Journal of Applied Science and Engineering Innovation, Vol.2 No.6.

(69)

BIBLIOGRAFIA

[14] Gautam Thatte, Urbashi Mitra, John Heidemann, (2011), Parame-tric Methods for Anomaly Detection in Aggregate Traffic. IEEE/ACM Transactions on Networking.

[15] Andreas Kind, Marc Ph. Stoecklin, and Xenofontas Dimitro-poulos, (2009) Histogram-Based Traffic Anomaly Detection, IEEE TRANSACTIONS ON NETWORK SERVICE MANAGEMENT. [16] C. Callegari, L. Gazzarrini, S. Giordano, M. Pagano, T. Pepe,

(2010), When randomness improves the anomaly detection performan-ce. Applied Sciences in Biomedical and Communication Technologies (ISABEL), 2010 3rd International Symposium on.

[17] C. Callegari, A. Casella, S. Giordano, M. Pagano, T. Pepe, (2013) Sketch-based multidimensional ids: A new approach for network anomaly detection, Communications and Network Security (CNS). [18] A. Casella, (2011), Tecniche di Network Anomaly Detection

Multi-dimensionale. Tesi di Laurea Specialistica, Universit`a degli Studi di Pisa.

[19] Christian Callegari, Stefano Giordano, Michele Pagano, (2015) Biva-riate Non-parametric Anomaly Detection, High Performance Compu-ting and Communications, IEEE 6th Intl Symp on Cyberspace Safety and Security.

[20] Romain Fontugne, Pierre Borgnat, Patrice Abry, Kensuke Fuku-da , (2008), MAWILab : Combining Diverse Anomaly Detectors for Automated Anomaly Labeling and Performance Benchmarking.

(70)

BIBLIOGRAFIA