universita` politecnica delle marche

Transcript

UNIVERSITA’ POLITECNICA DELLE MARCHE
FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Elettronica
Dipartimento di Elettronica, Intelligenza Artificiale e Telecomunicazioni
UN SISTEMA DI SUPPORTO
ALLA DETERMINAZIONE DI ANOMALIE
NEL TRAFFICO DI RETE
Tesi di Laurea di:
Luca VESCOVI
Relatore:
Prof. Paolo PULITI
Correlatori:
Ing. Aldo Franco DRAGONI
Ing. Paola BALDASSARRI
Anno Accademico 2003-2004
INDICE
INTRODUZIONE ......................................................................................................................................1
1
SICUREZZA DELL’INFORMAZIONE........................................................................................4
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.4
1.4.1
1.4.2
1.4.3
1.4.4
2
IDS: CONCETTO E STATO DELL’ARTE ................................................................................27
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.5
3
SICUREZZA DELL’INFORMAZIONE ..............................................................................................4
AGGRESSORI, BERSAGLI, OBIETTIVI ..........................................................................................5
LE CLASSI DEGLI ATTACCHI ......................................................................................................8
La Negazione del Servizio ....................................................................................................9
La Fuga di Informazioni.....................................................................................................12
L’accesso Regolare ai File .................................................................................................14
La Disinformazione ............................................................................................................15
L’accesso ai Database........................................................................................................17
L’esecuzioni di Codice Arbitrario Remoto .........................................................................17
L’elevazione dei Privilegi ...................................................................................................20
STRUMENTI E METODOLOGIE DI ATTACCO ..............................................................................21
Attacchi da Remoto.............................................................................................................22
Attacchi Locali....................................................................................................................25
Attacchi Ibridi.....................................................................................................................25
Osservazioni Conclusive.....................................................................................................26
CONCETTO DI INTRUSION DETECTION SYSTEM ........................................................................27
TASSONOMIA DEGLI INTRUSION DETECTION SYSTEM ..............................................................29
I Due Approcci Principali ..................................................................................................29
Host Based, Network Based................................................................................................30
On-Line (In-Line, Real-Time), Off-Line .............................................................................32
Sistemi Centralizzati e Distribuiti.......................................................................................32
CARATTERISTICHE DESIDERABILI PER UN IDS.........................................................................33
Reattività.............................................................................................................................33
Sicurezza Intrinseca: Survivability, Robustezza .................................................................34
Interazione con il Personale e Flessibilità .........................................................................34
Adattabilità ad Attacchi Nuovi ...........................................................................................35
Scalabilità e Concorrenza ..................................................................................................35
PROBLEMI TIPICI DI UN IDS .....................................................................................................36
Individuazione di Attacchi Nuovi, Modificati o Codificati .................................................36
Falsi Positivi e Falsi Negativi ............................................................................................38
Inserimento ed Elusione .....................................................................................................39
Elusione Basata Sul TTL (Time-To-Live) ...........................................................................40
La Frammentazione IP (Internet Protocol) ........................................................................41
Problemi Legati al Protocollo TCP....................................................................................41
UN’ARCHITETTURA RILEVANTE: SNORT................................................................................42
LE RETI NEURALI .......................................................................................................................45
3.1
INTRODUZIONE SULLE RETI NEURALI ......................................................................................45
3.2
APPRENDIMENTO .....................................................................................................................49
3.2.1
Apprendimento Supervisionato...........................................................................................51
3.2.2
Apprendimento Non Supervisionato ...................................................................................51
3.2.2.1
3.2.2.2
3.2.2.3
3.3
3.4
3.5
3.6
3.7
Hard Competitive Learning..................................................................................................... 53
Soft Competitive Learning ...................................................................................................... 53
Competitive Hebbian Learning ............................................................................................... 54
POLIEDRI DI VORONOI E TRIANGOLAZIONE DI DELAUNAY ......................................................55
MAPPE AUTO ORGANIZZANTI ..................................................................................................57
MAPPE CHE PRESERVANO LA TOPOLOGIA ................................................................................58
LA RETE SELF-ORGANIZING MAPS (SOM)...............................................................................60
LA RETE GROWING NEURAL GAS (GNG).................................................................................62
I
Indice
4
METODOLOGIA E SISTEMA IMPLEMENTATO..................................................................67
4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.4.1
4.4.2
4.5
4.6
5
OBIETTIVO DEL PROGETTO ......................................................................................................67
INFORMAZIONI RILEVANTI ALL’INTERNO DEI PACCHETTI DI RETE...........................................70
DECODIFICA DEI PACCHETTI DI RETE .......................................................................................73
IP Protocol Header ............................................................................................................75
TCP Protocol Header.........................................................................................................77
UDP Protocol Header ........................................................................................................79
ICMP Protocol Header ......................................................................................................79
ALGORITMO STATISTICO ..........................................................................................................80
Descrizione .........................................................................................................................81
Implementazione.................................................................................................................97
ALGORITMO DI PREPROCESSAMENTO.....................................................................................103
SOTTOSISTEMA DELLE RETI NEURALI ....................................................................................111
RISULTATI SPERIMENTALI...................................................................................................116
5.1
SET DI DATI UTILIZZATO .........................................................................................................116
5.1.1
DARPA IDS Evaluation dataset .......................................................................................117
5.1.2
Generazione del Dataset ..................................................................................................118
5.1.3
Generazione del Traffico di Background..........................................................................124
5.1.4
Esecuzione degli Attacchi.................................................................................................127
5.2
RISULTATI SPERIMENTALI FORNITI DAL SISTEMA STATISTICO ...............................................129
5.2.1
Risultati Relativi al Traffico di Background.....................................................................132
5.2.2
Risultati Relativi agli Attacchi..........................................................................................144
5.2.2.1
5.2.2.2
5.2.2.3
5.2.2.4
5.2.2.5
5.2.2.6
5.2.2.7
5.2.2.8
Attacco “Mailbomb” ............................................................................................................. 146
Attacco “Smurf”.................................................................................................................... 155
Attacco “Portsweep” ............................................................................................................. 161
Attacco “Udpstorm”.............................................................................................................. 166
Attacco “SshProcessTable”................................................................................................... 169
Attacco “Neptune” ................................................................................................................ 171
Attacco “Mscan” ................................................................................................................... 175
Attacco “Secret”.................................................................................................................... 177
5.3
RISULTATI SPERIMENTALI FORNITI DAL SISTEMA DI RETI NEURALI ......................................180
5.3.1
Risultati Forniti dalle SOM ..............................................................................................181
5.3.1.1
5.3.1.2
5.3.1.3
5.3.1.4
5.3.1.5
5.3.1.6
5.3.1.7
5.3.1.8
5.3.1.9
5.3.1.10
5.3.1.11
5.3.2
Risultati Forniti dalle GNG ..............................................................................................194
5.3.2.1
5.3.2.2
5.3.2.3
5.3.2.4
5.3.2.5
5.3.2.6
5.3.2.7
5.3.2.8
5.3.2.9
5.3.2.10
5.3.2.11
6
Risultati Relativi al Traffico di Background ......................................................................... 183
Risultati Relativi agli Attacchi .............................................................................................. 185
Attacco “Smurf”.................................................................................................................... 187
Attacco “UdpStorm” ............................................................................................................. 190
Attacco “Sshprocesstable” .................................................................................................... 190
Attacco “Neptune” ................................................................................................................ 191
Attacco “Mscan” ................................................................................................................... 191
Attacco “Secret”.................................................................................................................... 192
Considerazioni Finali e Falsi Allarmi.................................................................................... 192
Risultati Relativi al Traffico di Background ......................................................................... 197
Risultati Relativi agli Attacchi .............................................................................................. 198
Attacco “Smurf”.................................................................................................................... 199
Attacco “UdpStorm” ............................................................................................................. 200
Attacco “Sshprocesstable” .................................................................................................... 201
Attacco “Neptune” ................................................................................................................ 201
Attacco “Mscan” ................................................................................................................... 201
Attacco “Secret”.................................................................................................................... 201
Considerazioni Finali e Falsi Allarmi.................................................................................... 201
CONCLUSIONI E SVILUPPI FUTURI ....................................................................................203
BIBLIOGRAFIA ....................................................................................................................................207
II
INTRODUZIONE
L’obiettivo del presente lavoro di tesi è quello di studiare e quindi implementare
un sistema integrato che si basa su tecniche statistiche e tecniche di tipo neurale e che
realizzi un sistema di rilevazione delle intrusioni. In particolare, il sistema deve essere
di supporto alla rilevazione di anomalie nel traffico di una rete informatica e quindi
deve simulare un sistema di “Intrusion Detection” (detto comunemente IDS).
Il concetto di “Intrusion Detection System” è stato introdotto da James P.
Anderson in un suo rapporto tecnico del 15 aprile 1980. L’idea alla base di un IDS è che
sia possibile ricavare i segnali caratteristici di un’intrusione in un sistema informatico
allo scopo di dare l’allarme.
Quando si progetta la sicurezza di un fabbricato, si comincia a realizzare un
sistema di chiusure (porte, lucchetti, chiavistelli) che consenta di “selezionare” le
persone che hanno accesso alle varie aree della costruzione. Dopodichè si integra questo
sistema di “difesa” con un sistema di rilevazione (“antifurto”), che consente di
individuare eventuali trasgressori. Un IDS è l’equivalente informatico di un impianto
antifurto configurato per monitorare i punti di accesso, le attività ostili e gli intrusi
conosciuti.
IDS e sistemi di sicurezza tradizionali sono progettati per essere il più possibile
indipendenti, nella speranza di rendere più difficile la compromissione di entrambi. Un
sistema di sicurezza tradizionale si basa su un approccio classico del tipo “Chi sei ?
Cosa sei autorizzato a fare ?”, un IDS cerca piuttosto di capire “che cosa stai cercando
di fare ?”, o “perché stai operando in questo modo ?”. Idealmente l’obiettivo di un IDS
è “individuare quelle azioni che cercano di far agire il sistema in un modo diverso
rispetto a quello per cui è stato progettato”. Ciò significa, principalmente, cercare di
individuare azioni tese a eludere le misure di sicurezza, nella speranza che le azioni
degli intrusi siano sensibilmente differenti rispetto a quelle degli utenti autorizzati.
1
Introduzione
Possiamo distinguere tra IDS “misuse detection” e “anomaly detection”.
Nell’approccio “misuse detection”, il sistema cerca di individuare direttamente un
comportamento illecito, solitamente basandosi su qualche forma di base di conoscenza
che contenga un catalogo di attacchi noti (“firme” o “signatures”). Nell’approccio
“anomaly detection” invece, si cerca di studiare il comportamento dell’utente o della
rete, confrontandolo con un profilo di comportamento “normale”, modellato secondo
varie tecniche. Il sistema quindi individua, basandosi su parametri del profilo costruito
in precedenza, qualsiasi deviazione “significativa”, dal comportamento “normale”,
segnalandola all’amministratore che si occupa della sicurezza della rete informatica
come “sospetta”.
Il sistema di rilevamento delle anomalie proposto può essere classificato come un
IDS “anomaly detection” ma caratterizzato da una soluzione ibrida, a metà tra un
approccio “network based” e “host based”. Una possibile configurazione, è quella di
affiancare al sistema proposto un tradizionale IDS “misuse detection” come ad esempio
Snort; in tal modo è compito di quest’ultimo ricercare nel traffico di rete pacchetti
malformati o altri tentativi di attacco che un sistema basato su un approccio ”anomaly
detection” potrebbe non rilevare a causa della sua natura statistica.
Il sistema dovrà osservare il traffico di un host sulla rete, presumibilmente un
server Web, un server di posta elettronica o ancora un server di autenticazione remota.
Sotto questo aspetto si avvicina ad un sistema “host based”, ma l’originalità della nostra
soluzione ibrida consiste nel fatto che l’IDS non è eseguito fisicamente dall’host
monitorato bensì in un computer diverso dedicato a tale scopo. Questo ci permette di
non dipendere strettamente dal sistema operativo del server monitorato mantenendo così
un’elevata integrità e robustezza anche nel caso sfortunato che esso sia stato ad esempio
bersaglio di un attacco legato allo sfruttamento di una vulnerabilità, che Snort non ha
rilevato e che purtroppo ha avuto successo.
In uno scenario simile, il sistema proposto intende rilevare che l’host osservato sta
generando un traffico di rete statisticamente diverso da quello prodotto durante una
condizione di “normalità” e segnalare la situazione all’amministratore come “sospetta”.
Tale comportamento, infatti, potrebbe essere causato da un aggressore che una volta
preso il controllo del server, ha installato immediatamente un rootkit o un modulo
maligno del kernel per nascondere la propria presenza ed in questo modo sta sfruttando
l’host compromesso a proprio piacimento.
2
Introduzione
Tutto ciò è reso possibile dall’ idea di integrare i due sistemi: il sistema statistico
ed il sistema basato sulle reti neurali. Il sistema statistico prende in considerazione
finestre temporali scorrevoli durante le quali osserva il traffico di rete, considerando in
particolare alcuni parametri caratteristici, dei quali calcola la variazione nel tempo
determinando il momento primo, secondo, terzo e la varianza. Il sistema statistico
quindi svolgerà il ruolo di “discriminatore” la cui uscita deve consentire, da una
semplice ispezione visiva, di distinguere un andamento temporale “normale” da uno
anomalo.
L’uscita del sistema statistico rappresenterà l’ingresso del sistema di reti neurali
basate su un apprendimento non supervisionato che avrà il ruolo di “motore di
decisione”, dal momento che ha il compito di comunicare lo stato della rete, indicando
la presenza di un attacco conosciuto (o di un’anomalia) o se si stanno configurando le
condizioni per una situazione di preallarme.
Lo schema di questo lavoro ricalca fedelmente le varie fasi del suo sviluppo.
Viene analizzato innanzitutto nel primo capitolo il problema della sicurezza
dell’informazione, e delle minacce che minano alla base tale sicurezza. A partire da
questa analisi viene introdotto, nel secondo capitolo, il tema riguardante gli Intrusion
Detection System. Ci soffermeremo su alcune caratteristiche desiderabili per un sistema
IDS come ad esempio: adattabilità ad attacchi nuovi o modificati, reattività, sicurezza
intrinseca e robustezza. Verranno presentati inoltre i maggiori problemi che affliggono
gli attuali IDS e che conseguentemente possono permettere ad un eventuale aggressore
di eludere tali sistemi di sicurezza. Il terzo capitolo è una descrizione in generale delle
reti neurali; il loro funzionamento e le loro proprietà. Il quarto capitolo riguarda la
metodologia ed il sistema realizzato. Verranno illustrate tutte le varie fasi del lavoro
dall’obiettivo all’implementazione del sistema stesso. Il quinto capitolo riporta varie
verifiche sperimentali a sostegno della validità del sistema di rilevazione delle anomalie
proposto, ed infine nel sesto ed ultimo capitolo riporteremo le conclusioni e gli aspetti
di questo lavoro che possono essere approfonditi e sviluppati con studi futuri.
3
CAPITOLO 1
1 SICUREZZA DELL’INFORMAZIONE
1.1 Sicurezza dell’Informazione
Non è certo necessario dimostrare che nel nostro mondo una parte sempre
maggiore di ciò che facciamo, di ciò che gestiamo, o che trasmettiamo, viene realizzata,
controllata, o coadiuvata dall'utilizzo di sistemi informatici. Per questa ragione è
particolarmente importante capire quanto possiamo fidarci di questi sistemi. Questo
problema diviene sempre più critico, mano a mano che il valore delle informazioni
scambiate in forma digitale cresce.
La sicurezza dell'informazione ha attraversato un lungo periodo in cui veniva
considerata un'arte più che una scienza, da apprendere tramite l'esperienza e non tramite
lo studio. Solo pochi studi pionieristici stendevano le basi dei metodi formali che negli
ultimi anni sono stati sviluppati. Questo, unito all'intrinseca difficoltà della materia,
spiega il motivo per cui gran parte degli approcci al tema della sicurezza
dell'informazione sono basati su esperienza e conoscenza euristica più che su tecniche
raffinate. L'unico settore della sicurezza che vanta una lunga tradizione nell'uso dei
metodi formali è il campo della crittografia, che, non sorprendentemente, è molto più
avanzato e stabile degli altri.
Se questo metodo pragmatico di procedere ha funzionato per anni, lo sviluppo
esplosivo dei sistemi collegati in rete e di dispositivi con potenza e versatilità
francamente inimmaginabili solo pochi anni fa ha reso necessario, urgente, lo sviluppo
di un'ingegneria della sicurezza informatica, dove il termine “ingegneria” va inteso nel
suo senso tradizionale di scienza applicata, con definizione formale di concetti, metodi e
tecniche conosciute, esplorate da una ampia letteratura scientifica, e globalmente
diffuse.
4
Capitolo 1 – Sicurezza dell’Informazione
Cercheremo ora di dare una tassonomia e una nomenclatura per gli attacchi ai
sistemi informatici e per i possibili perpetratori di questi attacchi. Premettiamo che
questa non intende essere in alcun modo una guida esaustiva ai tipi di attacco (compito
che si rivelerebbe improbo, visto il numero quotidiano di innovazioni in questo settore),
ma piuttosto cercherà di delineare una serie di direttrici tipiche d’attacco, e di tecniche
“esemplari”, universalmente note, per farne uso.
1.2 Aggressori, Bersagli, Obiettivi
“Conoscere l’altro, e se stessi – cento battaglie, nessun rischio. Non conoscere
l’altro, e conoscere se stessi – a volte vittoria, a volte sconfitta. Non conoscere né l’altro
né se stessi – ogni battaglia è un rischio certo”. Le parole del saggio Sun Tzu, maestro
cinese dell’arte della guerra, ci devono fare riflettere. Per capire l’andamento di
qualsiasi scontro bisogna conoscere le due parti in gioco, e nel campo di battaglia della
sicurezza vi sono aggressori e aggrediti, o attaccanti e difensori. Ponendoci nell’ottica
dei difensori, conoscere “noi stessi” significa conoscere i sistemi che usiamo ma
soprattutto conoscere cosa dobbiamo proteggere. Conoscere il nemico significa essere
consci delle sue capacità e dei suoi obiettivi.
La prima nota da fare è che (eccettuati rari sottocasi) i sistemi informativi non
vengono aggrediti da altri sistemi, ma da persone. Ciò implica che l’analisi delle loro
motivazioni e delle loro metodologie sia una disciplina delle scienze sociali e della
psicologia più che dell’informatica. Tuttavia, come abbiamo già notato, la disciplina
della sicurezza dell’informazione è una di quelle discipline che si situano all’interfaccia
tra l’uomo e il sistema informativo.
Per cominciare, possiamo fare una macrodistinzione tra minacce esterne e
minacce interne. Infatti, una gran parte degli attacchi provengono da dentro le mura di
qualsiasi organizzazione. Già definire i “confini” di una singola organizzazione diviene
oggi difficile: concetti come le “extranet” che estendono il sistema informativo
mediante Internet fino ad interfacciarlo con quello dei partner, dei clienti e dei fornitori,
rendono molto labile il confine tra ciò che è interno ad una impresa e ciò che è esterno.
Un aggressore interno ha tutti i vantaggi, in quanto molto spesso opera a scatola aperta:
5
sa già quali sono i punti deboli, e come è strutturata l’architettura dei sistemi, tutte cose
che dall’esterno vanno scoperte poco alla volta.
Tra gli aggressori interni possiamo individuare due categorie principali:
Disgruntled Employees: sono persone che stanno coscientemente aggredendo
l’organizzazione, perché hanno qualche conto in sospeso, o perché sono stati
corrotti, o ancora peggio si sono fatti assumere appositamente per avere una
opportunità di violarne la sicurezza;
Trasgressori Ingenui: semplicemente cercano di abusare in qualche modo delle
risorse loro concesse, per esempio violando le linee guida aziendali sull’uso
responsabile di Internet, sul software da installare sulle postazioni di lavoro
aziendali, o simili. Sono pericolosi perché nel loro tentativo di violare le difese
aziendali potrebbero involontariamente fornire una porta d’accesso ad altri
intrusi ben più pericolosi (ad esempio, scaricando ed utilizzando software di
dubbia provenienza come ad esempio un Cavallo di Troia).
Tra gli aggressori esterni possiamo fare due tipi di distinzioni, la prima è una
distinzione a livello di capacità, e distinguiamo:
Esperti: dotati di conoscenze tecniche approfondite, capaci di elaborare attacchi
innovativi o di “inventare” procedimenti nuovi; molto spesso sono più esperti
dei sistemi che stanno attaccando di quanto non siano le persone incaricate di
difenderli; se volessimo tracciarne un quadro psicologico li definiremmo come
controllati, freddi, sul limite del paranoico, desiderosi di sentirsi “in controllo”
della situazione;
Script-Kiddies: privi di reali conoscenze tecniche, studiano ed utilizzano
“exploit”, attacchi preconfezionati rilasciati da esperti; il loro quadro psicologico
è ben più agitato, emotivo, possono lasciarsi prendere dalla paura e agire
irrazionalmente.
Tra le due categorie vi sono ovviamente infinite gradazioni intermedie.
6
Una seconda distinzione dei nemici si può fare secondo i loro fini:
nemici con un obiettivo preciso: sul sistema informativo sono contenuti dati che
vogliono rubare, oppure vogliono informazioni su una singola persona, vogliono
modificare o eliminare qualche informazione scomoda, o in ogni caso mirano ad
un obiettivo specifico e a lasciare quante meno tracce possibile della propria
presenza;
nemici che vogliono fare soltanto un danno, per rabbia, perché sono stati pagati
per farlo, o perché sono l’equivalente telematico dei vandali;
persone che stanno giocando: esplorano sistemi che non gli appartengono e se li
vedono vulnerabili provano a bucarli come “sfida” alle proprie capacità. Non va
assolutamente sottovalutata la potenzialità di questi aggressori “ludici”, e
nemmeno la loro pericolosità. Per quanto spesso non vogliano fare alcun danno,
o addirittura sperino di “dare una mano” agli amministratori delle macchine che
attaccano, un errore può sempre succedere.
Dobbiamo anche valutare quali siano i possibili bersagli di un aggressore con un
obiettivo preciso:
I dati: l’aggressore cerca di violare la confidenzialità delle informazioni che il
sistema contiene, oppure di modificarle abusivamente. I dati possono essere
copiati per essere venduti, oppure dare vita a un rapimento con riscatto
(l’attaccante ottiene abusivamente i segreti industriali di una vittima, e minaccia
di renderli pubblici se non gli verrà versato un cospicuo riscatto, per esempio);
I sistemi: l’aggressore mira alle risorse telematiche in sé più che al loro
contenuto. Ad esempio, moltissimi script-kiddie cercano macchine facili da
penetrare che possano essere usate come “deposito” di materiale illegale e/o
piratato, o che possano essere abusate per fare spam, o per disporre di
connessioni permanenti per qualsivoglia altra ragione.
Le finalità ultime di una persona possono essere, come abbiamo visto, moltissime:
dal guadagno diretto al guadagno derivante dalla vendita di informazioni, dalla
rappresaglia al divertimento; non ci avventuriamo in questo campo che è proprio della.
7
Tutto ciò costituisce il movente dell’attacco informatico, legame fondamentale tra
aggressori e obiettivi, molto spesso trascurato perché si tende a trascurare che la
componente umana è il cuore dell’attacco. Non lo strumento, non l’aggressione in sé,
ma la molla che spinge qualcuno ad aggredire un sistema.
Ogni organizzazione deve perciò considerare che sarà valutata da ogni tipo di
nemici, e che se risulterà interessante anche solo da un punto di vista sarà sicuramente
attaccata ed aggredita. Bisogna mettersi nell’ottica dell’aggressore, anzi, degli
aggressori, non nell’ottica dell’organizzazione: ciò che magari dal nostro punto di vista
è poco importante, per qualcuno può essere molto utile. Per esempio, poche
organizzazioni si rendono conto di quanto attrattivo possa essere, per un ragazzino che
vuole distribuire file musicali MP3, lo spazio su disco e la banda di connessione ad alta
velocità che possiedono in abbondanza.
La relazione tra aggressori ed obiettivi può essere schematizzata come mostrato
dalla figura seguente:
Figura 1.1 Relazione tra aggressori ed obiettivi
1.3 Le Classi degli Attacchi
La serietà di un attacco dipende da due fattori: il modo in cui esso viene condotto e il
danno inferto al sistema vittima. L’aggressore in grado di eseguire codice arbitrario
sulla macchina è forse il tipo di attacco più serio per l’utente finale , mentre per una
società di e-commerce il problema più immediato sarebbe costituito da un attacco DoS
(Denial of Service, negazione del servizio) o dalla fuga di informazioni. Ogni
vulnerabilità in grado di provocare una compromissione può rientrare in una particolare
categoria,
o
classe,
di
attacco;
le
proprietà
8
di
ciascuna
classe
indicano
approssimativamente la gravità di un attacco della classe medesima e il livello di
difficoltà necessario per contrastarlo. In questo paragrafo saranno analizzate le classi
degli attacchi, mostrando il tipo di danno che possono causare e ciò che l’aggressore
ottiene utilizzandole.
I principali tipi di attacco sono sette e costituiscono il criterio generale adottato per
classificare i problemi di sicurezza:
La negazione del servizio;
La fuga di informazioni;
L’accesso regolare ai file;
La disinformazione;
L’accesso ai database;
L’esecuzione di codice arbitrario remoto;
L’elevazione dei privilegi.
1.3.1 La Negazione del Servizio
Gli attacchi di negazione del servizio inferti dalla rete possono essere suddivisi,
sostanzialmente, in due categorie: quelli che colpiscono sul lato client e quelli invece
diretti all’intero sistema. Essi vengono concepiti per arrecare disagio e sono spesso
lanciati come attacchi per rappresaglia. Nella maggior parte dei casi questa classe di
attacco viene utilizzata dai cosiddetti Script-Kiddies, infatti la disponibilità di una serie
di strumenti gratuiti dà a queste persone il potere dell’anonimato e la facoltà di arrecare
disturbo, senza però la necessità di alcuna competenza tecnica.
Gli attacchi DoS sul lato client sono rivolti tipicamente ad un prodotto specifico,
con lo scopo di rendere l’utente finale incapace di eseguire qualunque attività con il
client. Uno di essi si svolge ad esempio con l’impiego della bomba JavaScript. Il
linguaggio JavaScript è infatti abilitato per impostazione predefinita su gran parte dei
browser Web; è possibile accorgersene quando si visita un sito Web con menu e finestre
a comparsa, tuttavia, viene utilizzato anche con numerosi scopi nocivi, fra cui quello di
lanciare un attacco DoS contro un client. Utilizzando la stessa tecnica scelta dai
pubblicitari per creare nuove finestre con le promozioni, l’aggressore crea un pagina
Web nociva che genera un ciclo infinito di creazione delle finestre: come risultato
9
finale, appaiono così tante finestre che il sistema occupa per esse tutte le risorse. Altri
attacchi simili colpiscono prodotti come AOL Instant Messenger, il client di
messagistica ICQ e software simili.
Il genere di aggressioni più conosciute, appartenenti a questa categoria, sono
invece gli attacchi DoS diretti al sistema che hanno lo scopo di degradare le prestazioni
per rendere il sistema completamente inutilizzabile.
Questo genere di attacco presenta tipicamente alcuni approcci che definiscono i
metodi adottati nella loro interezza: uno prevede l’impiego di un programma di
violazione per attaccare un sistema da un altro sistema, lasciando inagibile il sistema
obiettivo. Questo tipo di attacco fu mostrato da programmi di violazione come Ping of
Death e teardrop di un paio d’anni fa e dalle varie vulnerabilità del pacchetto
frammentato TCP/IP in prodotti come i router D-Link e Microsoft ISA Server. Su
questa linea vi è anche il concetto di SYN flood, un attacco che può essere lanciato da un
sistema o da una rete più veloci del sistema obiettivo. Questo attacco ha lo scopo
principale di degradare le prestazioni del sistema e viene eseguito inviando le richieste
di connessione TCP più velocemente di quanto il sistema di destinazione le possa
elaborare. Il sistema vittima conserva le risorse per tenere traccia di ciascuna
connessione, quindi un cospicuo numero di SYN in arrivo può far sì che l’host bersaglio
esaurisca le risorse destinate alle nuove connessioni legittime. L’indirizzo IP sorgente è,
come di consueto, sottoposto a spoofing: in tale modo, quando il sistema bersaglio tenta
di rispondere con la seconda fase dell’handshaking a tre fasi, ovvero SYN-ACK, non
riceve alcuna risposta. Taluni sistemi operativi ritrasmettono SYN-ACK diverse volte
prima di restituire le risorse al sistema. Nella figura 2.1 è mostrato un attacco SYN
flood in esecuzione. È infatti possibile vedere molte connessioni con il flag
“SYN_RECEIVED“per le quali non è stato ricevuto nessun ACK di risposta.
10
Figura 1.2 Sintomi di un attacco SYN flood
È importante affrontare anche gli attacchi smurfing o di pacchetto. L’attacco
smurfing esegue una negazione del sevizio della rete contro l’host di destinazione,
affidandosi all’aiuto di un intermediario, per esempio il router. L’aggressore,
effettuando lo spoofing dell’indirizzo IP sorgente dell’host di destinazione, genera una
grossa quantità di traffico eco ICMP (Internet Control Message Protocol) diretto verso
indirizzi IP di broadcast. Il router, detto anche amplificatore di smurfing, converte la
trasmissione IP in un broadcast di livello 2 e lo invia sul suo percorso. Ogni host che
riceve il broadcast risponde all’IP sorgente sottoposto a spoofing con una replica eco e,
secondo il numero di host sulla rete, sia il router sia l’host bersaglio possono essere
inondati di traffico. Questo può causare un rallentamento delle prestazioni di rete
dell’host colpito e, secondo il numero di reti di amplificazione adoperate, la saturazione
della rete.
L’ultimo attacco di questo tipo che analizzeremo è il DDoS (Distribuited Denial
of Service, negazione della rete distribuita). Questo concetto è simile a quello
dell’attacco di smurfing, ma il mezzo ed il metodo con cui esso viene sfruttato sono
molto diversi da quello dello smurfing. Questo tipo di attacco dipende dall’impiego di
un client, di master e di daemon (detti anche zombie). Il primo viene utilizzato per
avviare l’attacco, che ha poi luogo mediante i master; i master sono host compromessi,
muniti di un particolare programma che permette il controllo di più daemon. Anche i
daemon sono host compromessi muniti di un particolare programma e sono gli unici a
generare il flusso di pacchetti verso la destinazione. Perché un attacco DDoS funzioni,
lo speciale programma deve essere collocato su decine o centinaia di sistemi “agente”.
11
Di norma, un procedura automatizzata cerca gli host attaccabili, per esempio con
overflow del buffer nei servizi RCP (Remote Procedure Call), dopo di che inserisce il
programma sull’host compromesso. Iniziato il DDoS, tutti gli agenti inondano il sistema
bersaglio inviandogli il flusso del traffico.
1.3.2 La Fuga di Informazioni
La fuga di informazioni è tipicamente una risorsa di cui si abusa prima di sferrare
l’attacco. Nello stesso modo in cui i generali militari si affidano alle informazioni
portate dalle truppe di ricognizione che penetrano le linee nemiche per osservare il tipo
di armi, forza lavoro, approvvigionamenti e altre risorse del nemico, così gli aggressori
si introducono nella rete bersaglio per svolgere lo stesso compito: raccogliere
informazioni su programmi, sistemi operativi e struttura della rete.
La fuga di informazioni classica è quella da parte dei sevizi. Questa tecnica si
svolge con varie forme, fra cui i banner, i quali sono quel testo presentato all’utente
quando egli tenta di accedere a un sistema attraverso uno dei numerosi servizi; si
trovano generalmente su servizi come FTP (File Transfer Protocol), SSH (Secure Shell),
Telnet, SMTP (Simple Mail Transfer Protocol) e POP3 (Post Office Protocol). Molti
pacchetti software per questi servizi forniscono agli utenti esterni le informazioni sulla
versione nella loro configurazione predefinita. La figura 1.3 mostra il risultato di una
connessione tramite Telnet ad un server Web, dalla quale è ad esempio passibile capire
che il server in questione è Apache versione 2.0.39 in esecuzione su un sistema Unix.
12
Figura 1.3 Fuga di informazioni da parte di un server Web
Un altro problema simile è dato dai messaggi di errore. Alcuni servizi, come i
server Web, presentano numerose informazioni su sé stessi quando si creano le
condizioni per un’eccezione. L’eccezione è una circostanza fuori dall’ordinario, come la
richiesta di una pagina inesistente o un comando non riconosciuto; in situazioni del
genere, è preferibile adottare le configurazioni di errore personalizzate o crearne una
risolutiva.
Fra gli altri numerosi altri metodi per svolgere l’analisi di un sistema remoto vi è
l’analisi delle risposte IP. Gli strumenti automatizzati come Nmap (o Network Mapper),
forniscono un’utilità di facile impiego finalizzata a raccogliere informazioni su un
sistema, fra cui le porte raggiungibili pubblicamente e il sistema operativo. La
rilevazione del sistema operativo si basa sul cosiddetto “fingerprinting” (letteralmente
rilevamento delle impronte digitali), eseguito controllando la corrispondenza di un
insieme di risposte note prodotta da un tipo di sistema con una tabella che indica il
sistema operativo dell’host. La figura 1.4 mostra il risultato della scansione di un host
mediante Nmap. È possibile vedere le informazioni riguardo quali servizi di rete sono in
esecuzione sul server (Ssh, Smtp, Domain, Http), nonché il sistema operativo utilizzato
con addirittura l’indicazione della versione (Linux 2.4.X o 2.5.X).
13
Figura 1.4 Scansione di un host tramite Nmap
Qualsiasi sistema operativo progettato con intelligenza consente per lo meno di
prevenire questa pratica o di creare una sorta di “impronta digitale” che sia difficile da
identificare senza un accurato esame; alcuni, addirittura, consentono di inviare impronte
digitali fittizie agli host particolarmente invadenti.
1.3.3 L’accesso Regolare ai File
L’accesso regolare ai file offre all’aggressore numerosi mezzi diversi con i quali
lanciare l’attacco; gli può consentire di accedere a informazioni sensibili, come nomi
utente e password di un sistema, nonché di ottenere l’accesso ai file in modi diversi, per
esempio modificando le autorizzazioni o il proprietario di un file. Uno dei modi più
facili per accertare la sicurezza di un file è garantire le autorizzazioni appropriate:
questo è sovente uno degli aspetti più trascurati della protezione. Alcuni sistemi per
utente singolo, come i prodotti Windows 3.1/95/98/Me, sono privi di un’infrastruttura
per le autorizzazioni; gli host multiutente ne possiedono almeno una e, solitamente,
offrono numerosi mezzi per il controllo degli accessi. Ad esempio, i sistemi UNIX e
alcuni sistemi Windows possiedono sia utenti sia gruppi; UNIX e, fino ad un certo
14
punto, Windows consentono l’impostazione degli attributi dei file per indicare quali
utenti e quali gruppi possono ottenere l’accesso per svolgere determinate operazioni su
un file.
Un utente, definito proprietario del file, dispone del totale controllo sul file e
quindi possiede le autorizzazioni di lettura, scrittura ed esecuzione; un utente del gruppo
assegnato al file può invece disporre solo delle autorizzazioni di lettura ed esecuzione.
Gli utenti diversi dal proprietario e dai membri del gruppo possono avere un diverso
insieme di autorizzazioni o non averne affatto.
1.3.4 La Disinformazione
Il concetto di disinformazione si può presentare sotto molti aspetti. Tornando allo
scenario militare, si supponga che nel campo siano appostate alcune sentinelle in vari
punti di osservazione e che una di esse abbia visto il gruppo di ricognizione del nemico.
La sentinella avverte i suoi superiori, i quali inviano il loro gruppo di ricognizione per
scoprire esattamente chi li sta spiando, la sua posizione e la sua forza. Nel caso in cui i
generali scoprono così che l’esercito nemico è maggiore del proprio, loro
rafforzerebbero la propria posizione o si sposterebbero in un’altra zona, dove è più
difficile attaccarli o dove è più complicato individuarli. Com’è intuibile il generale
nemico, ha già pensato a questa situazione, perciò vuole far sembrare le proprie forze
meno minacciose di quanto siano in realtà; egli nasconde le sue armi pesanti e la
maggior parte della fanteria, consentendo la visibilità solo di una piccola parte delle
forze. Questa è l’idea alla base della disinformazione.
Il concetto si applica anche ai sistemi. Dopo averne compromesso uno,
l’aggressore svolge un accurato lavoro di occultamento del proprio passaggio, per
lasciare più disinformazione possibile; questo lavoro viene compiuto in molti modi.
Un metodo utilizzato è, ad esempio, la modifica del registro. L’aggressore può
tentare di riempire i file del registro, ma un sistema ben progettato dispone di molto
spazio e di una caratteristica di rotazione del registro per impedire tale attacco; egli può
allora, come ripiego, generare una grossa quantità di eventi per celare la sua attività.
Nelle circostanze opportune, egli può creare un intenso volume di eventi di
registrazione, generando uno o più eventi somiglianti alla voce creata all’inizio del
programma di hacking. Se l’aggressore ottiene l’accesso come amministratore del
15
sistema, ogni speranza di integrità del registro è perduta: munito di questo accesso, egli
può modificare i file di registro per rimuovere qualsiasi evento che indichi l’intrusione o
addirittura implicare nell’opera un altro utente. In questo caso, gli unici dispositivi che
possono fornire dati con una certa integrità sono gli IDS (Intrusion Detection System,
sistema di rilevamento delle intrusioni).
Alcuni strumenti includono opzioni per generare traffico e dati casuali: questi
sono definiti disturbo e sono utilizzati come tattica diversiva o come tecnica di
offuscamento. Lo scopo dell’aggressore è produrre un effetto come ad esempio: lo stato
di “benessere” del sistema, che equivale a far sembrare che nulla sia accaduto, oppure la
confusione generale e totale, mettendo in conflitto i file di registro o le loro voci, per far
sembrare che un processo del sistema sia impazzito.
Il rootkit, un altro strumento di disinformazione, è un programma pronto all’uso
finalizzato a nascondere l’operato dell’aggressore all’interno di un sistema; è anche lo
strumento preferito per conservare l’accesso a lungo termine a un sistema. Esistono
diversi tipi di rootkit, ciascuno con le proprie caratteristiche e difetti. Il rootkit funziona
sostituendo i programmi fondamentali del sistema nei sistemi UNIX o i driver e le voci
del Registro sui computer Windows. Esso sostituisce questi programmi, e possibilmente
non solo questi, con programmi interni, personalizzati per non fornire alla staff
amministrativo dettagli affidabili. Lo scopo principale dei rootkit è quindi celare
l’attività dell’aggressore e la sua presenza nel sistema, perciò questi pacchetti vengono
concepiti appositamente per creare disinformazione: fanno in modo che tutto appaia
perfettamente normale ma, nel frattempo, l’aggressore controlla il sistema e lancia
attacchi contro nuovi host o esegue altre azioni nefaste.
I moduli del kernel sono codici che possono essere caricati o scaricati da un kernel
in funzione e hanno lo scopo di fornire una funzionalità supplementare quando occorre,
consentendo al kernel di scaricare il modulo quando non occorre più, in modo da
alleggerire il carico della memoria. Questi moduli vengono caricati per fornire funzioni
aggiuntive come il supporto di un file system non nativo o il controllo di periferica, ma
si possono impiegare anche per azioni malevoli. Gli scopi dei moduli maligni del kernel
sono simili a quelli dei rootkit, il modulo infatti, fornisce un mezzo per nascondere
l’aggressore affinché questi svolga sull’host tutto ciò che desidera. Il modulo opera però
su un livello molto inferiore rispetto ai rootkit, intercettando le interrogazioni delle
informazioni sul livello di chiamata del sistema e filtrando tutti i dati che potrebbero
16
segnalare allo staff amministrativo presenze illecite. Tutto questo senza modificare i file
di sistema, come invece avviene nei rootkit, cosa che comporterebbe un rischio
maggiore di essere individuato.
1.3.5 L’accesso ai Database
I database devono combattere una guerra su due fronti: sono software, e perciò
soggetti a tutti i problemi del software come gli overflow del buffer, le negoziazioni del
servizio e così via; allo stesso tempo, essi sono anche un back-end per altri elementi
quali le interfacce Web, gli strumenti di interfaccia utente e così via. I database sono
sicuri solo quanto il software eseguito e le interfacce con cui comunicano. Le interfacce
Web, ad esempio, tendono ad essere un problema abituale per i database: ciò si deve al
fatto che non riescono a filtrare i caratteri speciali o che sono state progettate in modo
non corretto. Questa tesi è avvalorata dalla regolarità con cui si trovano falle nei
pacchetti di e-commerce.
Gestire l’input proveniente dall’utente è quindi rischioso: l’utente tende infatti a
fornire al front-end Web qualunque cosa, sia per semplice ignoranza sia, talvolta, per
agire in mala fede. Occorre progettare script adatti a filtrare i caratteri speciali, come la
virgoletta singola (‘), il carattere slash (/), la barra rovesciata (\), e le virgolette doppie
(“), altrimenti si crea una situazione che potrebbe essere rapidamente sfruttata: un frontend che consente il passaggio di tali caratteri a un database permette di eseguire
comandi arbitrari, solitamente con l’autorizzazione dei daemon dei database.
I front-end progettati in modo non corretto costituiscono uno scenario differente.
Essi consentono agli utenti di interagire con il database e di manipolarlo in molti modi:
l’aggressore può dunque prendere visione delle tabelle, eseguire comandi SQL o perfino
eliminare le tabelle.
1.3.6 L’esecuzioni di Codice Arbitrario Remoto
L’esecuzione di codice remoto è uno dei metodi più comuni per sfruttare i sistemi:
con esso sono stati sferrati numerosi e rilevanti attacchi a siti Web di alto profilo. Il
codice arbitrario remoto, è particolarmente pericoloso, perché non richiede
17
autenticazione e quindi può essere sfruttato da chiunque. Se l’aggressore riesce ad
eseguire codice arbitrario mediante un servizio nel sistema, egli ottiene l’accesso locale
al sistema stesso con gli stessi privilegi del servizio che ha sfruttato per l’attacco.
Esistono svariati metodi per svolgere questa tecnica ad esempio l’overflow del buffer o
gli attacchi mediante il formato delle stringhe, comunque occorre sfruttare una
vulnerabilità.
Esistono tre tipologie fondamentali di vulnerabilità in un sistema informatico:
vulnerabilità
nell’implementazione
dei
programmi,
che
consentono
all’aggressore di far comportare il programma in maniera diversa da quella
attesa. Non possiamo riportarne un elenco completo, ma le più comuni sono:
errori nella validazione dell’input, ovvero nel filtraggio dei dati che
arrivano da fonti inaffidabili (ad esempio, gli utenti). Un esempio comune
sono le pagine web che gestiscono back-end collegati all’esecuzione di
query SQL sui database, come spiegato in precedenza nel paragrafo
“L’Accesso ai Database”;
problematiche di buffer overflow, ovvero la possibilità che un insieme di
valori troppo lungo venga inserito in un buffer di lunghezza prefissata,
andando a influire sullo stack ed alterando il flusso di esecuzione del
programma, o sull’heap del programma, corrompendone le variabili;
problemi nelle chiamate e comunicazioni tra processi e nella gestione
della memoria: ad esempio, passaggi in chiaro di dati molto sensibili che
possono essere intercettati da qualche curioso;
problemi di gestione dei privilegi di esecuzione, in particolare per i demoni
di rete che hanno bisogno dei privilegi di amministratore in alcuni punti
della loro esecuzione;
attacchi relativi al timing di determinate operazioni critiche (le cosiddette
“race condition”).
vulnerabilità nella configurazione: molti programmi per essere considerati
sicuri debbono essere opportunamente configurati ed adattati alle situazioni
specifiche in cui vengono inseriti. Spesso è proprio nella fase di configurazione
18
che amministratori inesperti compiono gravi leggerezze, che rendono inutili tutte
le contromisure di sicurezza. Per esempio, la condivisione di unità a disco in
ambiente Windows senza alcuna forma di autenticazione è da anni
costantemente nella lista delle “20 vulnerabilità più diffuse” gestita dal SANS
institute;
vulnerabilità nella progettazione di una determinata applicazione, sistema, o
protocollo, che la rendano insicura per come è stata creata. Esempio tristemente
noto è il recente protocollo criptografico WEP, Wired Equivalent Privacy,
progettato per rendere sicure le comunicazioni sulle reti Wireless LAN
realizzate secondo lo standard IEEE 802.11b; un errore di design rende tale
protocollo estremamente debole e facile da decodificare.
Abbiamo volutamente ordinato tali classi in ordine crescente di “livello
concettuale”, e di difficoltà di correggere l’errore una volta individuato: un buffer
overflow può essere corretto mediante una patch; un errore di configurazione, una volta
scoperto, può essere sistemato; un algoritmo come WEP è irrecuperabile, e può solo
essere abbandonato in favore di un altro.
L’esecuzione del codice remoto viene sempre compiuta da un mezzo
automatizzato: tentare di effettuarla manualmente è pressoché impossibile. Questi
attacchi sono compiuti tipicamente facendo ricorso ad uno script automatizzato. Nella
maggior parte dei casi, questa tecnica di aggressione ha lo scopo di conferire all’utente
remoto l’accesso amministrativo a un sistema vulnerabile. L’attacco vero e proprio è
solitamente preceduto da un altro di raccolta delle informazioni, nel quale l’autore
identifica la versione vulnerabile del programma mediante, per esempio, strumenti di
scansione automatizzati. Dopo di che l’aggressore esegue uno script sul programma con
l’intento di ottenere l’accesso amministrativo all’host. Ottenuto questo accesso, egli dà
il via al processo descritto precedentemente nel paragrafo “La Disinformazione”, vale a
dire che egli fa del suo meglio per nascondere la propria presenza nel sistema. In
seguito, può utilizzare l’host compromesso per lanciare attacchi di esecuzione di codice
arbitrario remoto contro altri host.
19
1.3.7 L’elevazione dei Privilegi
L’elevazione dei privilegi, si verifica quando un utente ottiene l’accesso a delle
risorse per le quali non era autorizzato. L’elevazione dei privilegi remota può rientrare
in una di due categorie: la prima è quella dell’accesso remoto non privilegiato, che
permette ad un utente remoto l’accesso non autorizzato ad un sistema come utente
regolare; la seconda è l’accesso amministrativo immediato (remote root exploits).
L’accesso remoto ad un sistema come utente regolare si può ottenere mediante
numerosi mezzi, tra cui gli elementi già discussi come il filtraggio dei caratteri speciali
attraverso le interfacce Web, l’esecuzione del codice con metodi quali gli overflow del
buffer e le falle nei formati delle stringhe, oppure con i dati ottenuti dalla fuga di
informazioni. Solitamente a questa prima fase di attacco, segue una seconda denominata
privilege escalation, che consiste nel tentare di sfruttare un’altra vulnerabilità sul
sistema locale col fine di ottenere anche in questo caso i privilegi amministrativi sul
sistema violato.
L’accesso remoto dell’utente privilegiato è il più grave dei due problemi: se un
utente remoto riesce ad ottenere l’accesso ad un sistema come utente privilegiato,
l’integrità del sistema è destinata al collasso. Questo evento è paragonabile ad un
aggressore che accede ad un sistema con i privilegi di un account di sistema; tali
account comprendono, ad esempio, root, bin e sys nei sistemi UNIX e Administrator e
LocalSystem in quelli Windows 2000. I Metodi per raggiungere questo obiettivo sono
sostanzialmente identici a quelli per l’accesso non privilegiato, ma vi sono alcune
importanti differenze. Una si trova nel servizio colpito: per avere l’accesso remoto come
utente privilegiato, occorre sfruttare un servizio che operi come utente privilegiato. Fra
questi vi è tuttora la maggior parte dei servizi UNIX: alcuni di essi, come Telnet e SSH,
sono stati oggetto di serie vulnerabilità.
L’accesso dell’utente remoto privilegiato è anche lo scopo di molti Cavalli di
Troia. Programmi come SubSeven, Back Orifice e le numerose varianti sono utilizzati
per ottenere privilegi amministrativi remoti in un sistema infetto; essi tendono a
includere
l’ingegneria
sociale,
definita
generalmente
come
impiego
della
disinformazione o della persuasione, per convincere un utente ad eseguirli. Nel
momento dell’esecuzione, l’aggressore deve semplicemente adottare il metodo di
comunicazione con il programma maligno e così può osservare il sistema infetto,
20
eseguire operazioni da quest’ultimo e perfino controllare la facoltà degli utenti di
operare su esso.
Figura 1.5 Illustrazione schematica dei cammini tipici per l’accesso ad un sistema informatico; in verde i
cammini leciti, in rosso quelli illeciti
1.4 Strumenti e Metodologie di Attacco
Per mettere in atto le tipologie di attacco viste finora, gli aggressori usano una
vasta serie di strumenti, non crediamo certo di poterne offrire un elenco esaustivo.
Tuttavia proviamo ad elencarne le tipologie principali:
Strumenti di packet forgery: vasta categoria di programmi, sia generali (che
consentono di costruire pacchetti del tipo desiderato dall’utente) sia molto
specifici (che creano pacchetti strutturati appositamente per sfruttare una
specifica vulnerabilità). Molti “remote exploit tools” ricadono in quest’ultima
categoria;
Port-scanner e vulnerability scanner: strumenti che inviano ad una o più
macchine pacchetti TCP/IP per cercare di scoprire quali servizi sono disponibili.
I vulnerability scanner aggiungono a questa funzione una base di conoscenze per
determinare se tali servizi sono vulnerabili ad attacchi noti, sia mediante
funzioni di raccolta di informazioni, che mediante veri e propri tentativi di
attacco;
21
Normali client d’accesso: non sono poche le vulnerabilità che non richiedono
niente altro che un normale browser, un client Telnet, o qualche altro tipo di
client, e un po’ di conoscenze da parte dell’aggressore per essere sfruttate.
Ricadono in questa categoria, per esempio, gran parte delle vulnerabilità dovute
a cattiva configurazione. A volte si usano dei client modificati: per esempio un
client FTP da linea di comando, congiunto ad uno script, può essere utilizzato
per fare molteplici tentativi di accesso tentando di “indovinare” una password;
Programmi da eseguire (o far eseguire con l’inganno) su un host remoto per
ottenere gli effetti più vari. Un noto detto della sicurezza informatica vuole che
“una volta che qualcuno è riuscito, con l’inganno o mediante qualche tecnica, ad
eseguire o a farti eseguire un programma di sua scelta sulla tua macchina, quella
non è più la tua macchina”;
Agenti software autonomi, con varie funzioni, sono dei programmi simili ai
precedenti ma sono in grado di attuare da soli un processo di compromissione
del sistema;
Artefatti fisici: un tempo erano molto di moda i “wiretap”, piccoli morsetti
applicati sui cavi di una rete di telecomunicazioni per intercettare e inserire
traffico abusivamente, al punto che molte canaline di rete sicure venivano
integrate con impianti ad aria compressa per rilevare eventuali forature. Caduta
in disuso negli anni ’90, la pratica sta rinascendo con le reti wireless, in cui l’uso
di apparecchiature di intercettazione dei segnali anche molto semplici consente
risultati sorprendentemente efficaci.
Strumenti e accessi si combinano in un numero sorprendente di scenari di
intrusione possibili, di cui elenchiamo le variazioni più comuni ed i relativi risultati.
1.4.1 Attacchi da Remoto
Attacchi a demoni e servizi di rete: il tipo di exploit forse più conosciuto, al
punto tale da essere spesso l’unico preso in considerazione. L’idea alla base di
questi attacchi è che, in assenza di un accesso diretto al livello comandi del
sistema, l’aggressore cerchi di fare in modo che un processo già in esecuzione,
spesso con elevati privilegi, esegua al posto suo delle operazioni sul sistema:
22
Mediante l’invio di pacchetti artefatti: spesso i progettisti di applicazioni
di rete dimenticano che è possibile per chiunque forgiare ed iniettare
pacchetti all’interno di Internet. Molti servizi si sono dimostrati vulnerabili a
particolari pacchetti malformati;
Mediante l’interazione con l’interfaccia pubblica: molti attacchi vengono
portati a termine interagendo con l’applicazione, demone o servizio,
esattamente come qualsiasi utente normale farebbe, ma inviando dati o
comandi malformati che provocano effetti indesiderabili. Possiamo ricordare
i bug Unicode di I.I.S. (Internet Information Server) di Microsoft, il cui
meccanismo di exploit era una richiesta Http malformata; ma anche le
vulnerabilità delle applicazioni web-based;
Grazie a misconfigurazioni: la più tipica delle vulnerabilità da remoto è
una misconfigurazione o un’errata concezione della sicurezza. Pagine web
amministrative lasciate on-line senza password, directory FTP aperte per
l’upload…ecc;
Bruteforcing: l’aggressore cerca, per tentativi successivi, di individuare i
codici di accesso di un servizio, nella speranza di trovarne di deboli o corti.
Contrariamente a quanto si crede, è un attacco relativamente poco usato
perché facilmente individuabile.
Attacchi all’infrastruttura: con questo termine si intendono quegli attacchi che
non si concentrano sul sistema aggredito, ma che cercano di sfruttare alcune
debolezze dell’infrastruttura di rete che lo circonda, per esempio:
Sniffing: I dati su Internet viaggiano in chiaro e vengono trasmessi da un
punto all’altro rimbalzando per una serie di sistemi di cui non conosciamo
l’affidabilità. Non solo, ma su una rete locale Ethernet, tranne in alcuni casi,
tutte le workstation sullo stesso segmento di rete vedono passare tutto il
traffico destinato anche alle altre macchine. La pratica dello sniffing consiste
proprio nell’analizzare il traffico abusivamente intercettato, in generale alla
ricerca dei codici d’accesso per le macchine;
23
Hijacking: l’hijacking delle connessioni TCP è un tipo d’attacco tanto
pericoloso quanto difficile da realizzare, che consente a un aggressore di
“rilevare” la connessione stabilita tra due macchine, e continuare ad usarla.
Per fare un esempio, un intruso potrebbe attendere che A abbia stabilito una
connessione Telnet con B per poi “inserirsi” al posto di A e sfruttare il
collegamento per fare ciò che vuole su B;
Man-in-the-middle: un attacco in cui l’intruso, C, riesce a interporsi in
maniera perfetta tra due sistemi, A e B, che stanno comunicando via rete. In
pratica A parla con C, illudendosi di parlare con B; B pure parla con C,
interpretando le sue risposte come provenienti da A;
Spoofing: la pratica dello spoofing prende le mosse dall’osservazione che
non c’è, in IP, un meccanismo di autenticazione del mittente: l’indirizzo IP
sorgente può pertanto venire tranquillamente falsificato. A livello di TCP
sono previsti alcuni meccanismi che rendono più difficile questo attacco (la
presenza di un numero pseudocasuale di sincronizzazione, ad esempio) “alla
cieca”, ma se l’aggressore vede tutti i pacchetti mentre passano (mediante
sniffing) la difficoltà non è insormontabile.
Denial-of-Service da remoto: attacchi spesso meno complessi dei precedenti,
in quanto in questo caso l’obiettivo dell’aggressore è “semplicemente” impedire
a chiunque altro di utilizzare il servizio aggredito:
Saturazione delle risorse: sia del particolare servizio, che dell’intero
sistema. Un esempio di attacco di questa classe può essere il SYN flood visto
in precedenza;
Utilizzo di pacchetti artefatti: come per il caso dell’uso di pacchetti
malformati per attacchi finalizzati a ottenere un accesso, determinati
pacchetti malformati possono invece ottenere l’effetto di far bloccare un
servizio o una applicazione, ottenendo un Denial of Service;
Utilizzo
dell’interfaccia pubblica del daemon: facendo richieste
impossibili, malformate, o semplicemente subissando di richieste molto
lunghe il servizio che si vuole bloccare, è possibile impedire l’accesso agli
utenti legittimi.
24
1.4.2 Attacchi Locali
Mediante esecuzione di comandi e script: dall’interno di un computer ed
utilizzando i comandi disponibili agli utenti si possono compiere un gran
numero di possibili attacchi, cercando di ottenere privilegi “migliori”, per
esempio l’accesso in lettura a tutti i file, oppure i privilegi d’amministrazione;
Mediante la compilazione e l’esecuzione di exploit sull’host vittima: esistono
alcuni bug di servizi locali e/o del sistema operativo che possono essere sfruttati
mediante l’esecuzione (in locale) di programmi di exploit;
Denial-of-Service da locale: un utente locale (se non è stato limitato in qualche
modo) può lanciare in esecuzione un’infinità di processi, per esempio scrivendo
un piccolo programma C che lancia due “copie” di se stesso. La crescita
esponenziale metterà in breve in ginocchio il sistema;
Altri tipi di interazione con il sistema: quasi ogni sistema ha delle attività (per
esempio, di manutenzione programmata) in grado di rallentare o bloccare
l’accesso ai servizi. Inoltre, un intruso con i privilegi amministrativi può
arrestare qualsiasi servizio gli interessi disattivare.
1.4.3 Attacchi Ibridi
Utilizzo di agenti autonomi: questi programmi agiscono da soli, in modo
indipendente da chi li ha creati e lanciati, per guadagnare accesso ad altre
macchine ed eseguirvi operazioni non autorizzate. L’esempio più tipico sono i
virus e i worm:
Virus: sono frammenti di codice eseguibile che quando vengono eseguiti
copiano sé stessi all’interno di altri programmi eseguibili. Quando questi
ultimi vengono eseguiti, il codice virale torna in esecuzione e si diffonde
sempre di più. I virus non possono essere inseriti all’interno di file di dati,
però va notato che al giorno d’oggi molti programmi possono salvare
istruzioni “macro” nei propri documenti, che in alcuni casi possono essere
utilizzate per creare virus;
25
Worm: diversamente dai virus, non sono pezzi di codice che si agganciano
ad altri programmi, bensì programmi che clonano se stessi, lanciandosi in
esecuzione in vari modi. Spesso i worm contengono del codice “backdoor”,
installando sulle macchine infettate un accesso per il proprio creatore.
1.4.4 Osservazioni Conclusive
Per completare il quadro mancano ancora alcune annotazioni di carattere generale
ma di estrema importanza.
Per prima cosa, non è assolutamente detto che un attacco proceda in questa
maniera lineare; anzi, sarebbe una pessima indicazione di inefficacia delle misure di
sicurezza se l’attaccante potesse compiere un processo così diretto che lo porta dall’idea
alla realizzazione del suo obiettivo. Solitamente la fase di utilizzo dei tool per
guadagnare un accesso, porta a dei risultati che non sono immediatamente in linea con
gli obiettivi, ma che servono per poter utilizzare altri strumenti, su altre vulnerabilità.
Questo ciclo aggressione – risultato – nuova aggressione è una costante nelle intrusioni
informatiche.
In secondo luogo, non dobbiamo dimenticarci, che gli aggressori hanno dalla loro
parte la straordinaria potenza dell’intelligenza umana. Proprio per questo motivo un
sistema informatico, per quanto possa essere ben progettato e robusto, si troverà
costantemente in svantaggio se confrontato con una mente umana capace di
ragionamento, improvvisazione e flessibilità di gran lunga superiore ad un qualunque
sistema artificiale.
Infine un’ulteriore annotazione, riguarda l’utilizzo da parte degli aggressori di
metodologie di attacco non strettamente informatiche: per esempio, come già accennato,
l’utilizzo di metodologie di social engineering per ottenere accessi ingannando le
persone; oppure, ad esempio, il cosiddetto dumpster diving, la ricerca di preziosi
frammenti di informazione, password, e documenti, nella spazzatura eliminata da una
organizzazione; o ancora, il furto di computer portatili e palmari con memorizzate
importanti chiavi d’accesso (si tratta di un fenomeno in continua crescita, secondo il
rapporto CSI/FBI).
26
CAPITOLO 2
2 IDS: CONCETTO E STATO DELL’ARTE
2.1 Concetto di Intrusion Detection System
Quando si progetta la sicurezza di un fabbricato, si comincia a realizzare un
sistema di chiusure (porte, lucchetti, chiavistelli) che consenta di “selezionare” le
persone che hanno accesso alle varie aree della costruzione. Dopodichè si integra questo
sistema di “difesa” con un sistema di rilevazione (“antifurto”), che consente di
individuare eventuali trasgressori. Un Intrusion Detection System (IDS) è l’equivalente
informatico di un antifurto.
Dopo aver introdotto il concetto con una analogia, vediamo però di esplorare più
approfonditamente cosa sia e come funzioni un IDS. Abbiamo detto che, a fronte delle
possibilità non secondarie di violazione della policy di sicurezza da noi prestabilita,
dobbiamo trovare dei meccanismi complementari di difesa. Molto naturalmente, questi
meccanismi sono quelli di individuazione degli intrusi, reazione, contenimento del
danno e “chiusura” del buco nel sistema difensivo che ha reso possibile la
compromissione. Ovviamente, gli IDS entrano in gioco proprio nella difficile fase di
“individuazione” degli intrusi.
Se la protezione dalle intrusioni è difficile perché deve essere tenuto conto della
determinazione da parte dell’intruso a violare le politiche di sicurezza, a maggior
ragione l’individuazione di queste violazioni sarà doppiamente difficile. A meno di
clamorosi autogol, infatti, uno dei primissimi obiettivi di qualsiasi attaccante è coprire
le proprie tracce, cercare di comportarsi nella maniera più anonima possibile e
soprattutto distruggere qualsiasi prova della violazione perpetrata. Il problema peggiore
è che, laddove la sicurezza del sistema sia stata completamente sovvertita e l’intruso
abbia raggiunto i privilegi amministrativi, improvvisamente tutti i sistemi di
registrazione degli eventi (logging) e tutti i controlli inseriti nel sistema sono
27
Capitolo 2 – IDS : Concetto e Stato dell’Arte
terribilmente inaffidabili e inclini a ogni manipolazione. Proprio per questo motivo gli
amministratori più preoccupati hanno l’abitudine di collegare il logging dei sistemi
critici a una stampante. In questo modo, l’intruso può al massimo disabilitare il sistema
di logging, ma non cancellare selettivamente o modificare le proprie tracce. Sono però
evidenti i limiti di questo tipo di artifici difensivi.
Per questo motivo è necessario che il sistema che tenta di individuare queste
violazioni utilizzi un’ottica il più possibile diversa da quella utilizzata per
l’implementazione del sistema di sicurezza. Laddove quest’ultimo tradizionalmente si
basa su un approccio classico del tipo “Chi sei ? Cosa sei autorizzato a fare ?” un IDS
cerca piuttosto di capire “che cosa stai cercando di fare ?”, o “perché stai operando in
questo modo ?”. Ciò che, idealmente, un IDS dovrebbe fare è “individuare quelle azioni
che cercano di fare agire il sistema in un modo diverso rispetto a quello per cui è stato
progettato”. Ciò significa, principalmente, cercare di individuare azioni tese a eludere le
misure di sicurezza, nella speranza che le azioni degli intrusi siano sensibilmente
differenti rispetto a quelle degli utenti autorizzati.
IDS e sistemi di sicurezza tradizionali sono fatti per essere quanto più possibile
indipendenti, nella speranza di rendere più difficile la compromissione di entrambi.
Come nota a margine, è evidente che il concetto di Intrusion Detection System tracciato
in questo paragrafo è paradigmatico. Non stiamo parlando di un singolo software,
prodotto o meccanismo, ma dell’intera architettura di sistemi che vengono predisposti
per rilevare le intrusioni. In molti casi, specialmente nell’industria, viene indicato come
“Intrusion Detection System” il singolo software utilizzato per individuare le intrusioni.
Questo approccio potrebbe essere limitativo, in quanto riduce una problematica e la
relativa soluzione progettuale all’uso di un singolo prodotto.
Tuttavia, nel seguito di questa tesi, utilizzeremo il termine per indicare anche un
singolo sistema o software che svolga compiti di intrusion detection, seguendo la
convenzione tipica. Ci premeva però sottolineare questo importante concetto di IDS
come architettura integrata di sistemi.
28
2.2 Tassonomia degli Intrusion Detection System
In questo paragrafo cercheremo di dare una rapida panoramica dei possibili
approcci al problema dell’intrusion detection. Daremo esempi concreti, ma per una più
approfondita analisi dei sistemi esistenti in letteratura e commerciali preferiamo
rimandare a testi specifici.
2.2.1 I Due Approcci Principali
Esistono in letteratura due grandi categorie di approcci alla tematica dell’Intrusion
Detection:
Anomaly Detection: in questo tipo di approccio si cerca di studiare il
comportamento dell’utente o della rete, confrontandolo con un profilo di
comportamento “normale”, modellato secondo varie tecniche. Il sistema
individua in modo statistico qualsiasi deviazione “significativa”, segnalandola
all’amministratore come “sospetta”. I sistemi di questo tipo vengono anche detti
“behavior based”;
Misuse Detection: in questo tipo di approccio, viceversa, il sistema cerca di
individuare direttamente un comportamento “anomalo”, solitamente basandosi
su qualche forma di base di conoscenza che contenga un catalogo di attacchi noti
(“firme” o “signatures”). I sistemi di questo tipo vengono anche detti
“knowledge based”.
Ciascuno di questi approcci ha pregi e difetti. I sistemi basati sulla anomaly
detection, per esempio, non richiedono un’immissione di conoscenza “a priori”, né
richiedono continui aggiornamenti delle “firme” d’attacco, essendo teoricamente in
grado di rilevare i “cattivi comportamenti” sulla base di una descrizione di “normalità”.
Tuttavia, per costruire un modello di “comportamento normale” serve innanzitutto uno
studio architetturale preciso su quale tipo di modello usare, e in secondo luogo una fase
più o meno prolungata di addestramento in cui il modello viene “tarato” sullo specifico
29
utente e sullo specifico sistema. Inoltre, questi sistemi sono inclini ad errori e falsi
positivi.
I sistemi basati sulla misuse detection, viceversa, richiedono uno studio estensivo
delle forme d’attacco per la produzione delle “firme” necessarie al loro funzionamento.
Le firme degli attacchi consistono nell’impiego di diversi componenti per descrivere in
modo unico un attacco. Le firme vengono costruite per lo più eseguendo varie volte un
codice di hacking conosciuto, monitorando i dati mentre appaiono sulla rete e cercando
una forma unica che venga ripetuta ad ogni esecuzione. Questo metodo è efficace nel
garantire che la firma corrisponderà in modo coerente ad un tentativo da parte del
codice di hacking in questione. La firma ideale sarebbe peculiare dell’attacco e allo
stesso tempo molto semplice; le firme estese e complesse, difatti, possono costituire un
grosso peso per l’elaborazione. Dalla qualità delle firme e dal loro aggiornamento
costante dipende inevitabilmente l’efficacia del sistema (si può notare immediatamente
un parallelo con i meccanismi e le problematiche tipiche del software antivirus).
Stranamente, il problema dei falsi positivi ma soprattutto degli avvisi indesiderati
affligge drammaticamente anche i sistemi di questo tipo, che dovrebbero essere meno
vulnerabili. Ciò che si nota, infine, è che mantenere una base di conoscenze vasta e in
continuo aggiornamento con i “pattern” degli attacchi è una impresa improba.
Alcuni sistemi di intrusion detection combinano entrambi questi aspetti, in quanto
ciascuno di essi possiede delle caratteristiche molto desiderabili, e sono a tutti gli effetti
complementari. Vi è tuttavia un problema di metriche decisionali, e di aumento
incontrollato dei falsi positivi, che ha scoraggiato fino ad ora lo sviluppo di simili
soluzioni. Nella stragrande maggioranza dei casi i sistemi di Intrusion Detection
commerciali sono comunque “misuse based”.
2.2.2 Host Based, Network Based
Un’altra classificazione molto importante distingue tra sistemi host-based e
network-based:
30
I sistemi “host-based” controllano una singola macchina e a volte una singola
applicazione, e dipendono dal sistema operativo (a cui sono spesso collegati
strettamente, nello specifico molti moduli di intrusion detection host based sul
sistema Linux vengono realizzati come moduli del kernel) per tracciare chiamate
di sistema, utilizzo delle risorse, comandi eseguiti e i passaggi da un livello di
privilegi a un altro. Altre tipiche fonti di dati per un sistema host based sono i
log di sistema;
I sistemi “network-based”, viceversa, sono collegati in posizioni opportune ad
una rete di computer, e cercano di controllare tutto il traffico che la attraversa
(mediante degli sniffer di rete), cercando nel flusso di pacchetti le indicazioni di
possibili attacchi.
Come sempre, entrambi gli approcci presentano vantaggi e svantaggi.
Uno dei principali vantaggi di un IDS network-based è la possibilità di operare
una “passive analysis”, in cui il sistema raccoglie i pacchetti di rete senza che la sua
presenza sia rilevabile: operativamente questo si ottiene dotando la macchina che
esegue l'IDS di una scheda di rete posta in modalità promiscua. In questo modo diventa
molto difficile per un intruso rilevare la presenza dello sniffer. Inoltre un IDS di rete
può utilizzare un numero di sonde relativamente piccolo per controllare anche reti di
grandi dimensioni. Questo tipo di intrusion detection deve, però, processare
continuamente una grossa quantità di dati e quindi và inevitabilmente incontro a
problemi di prestazioni, soprattutto in reti ad alta velocità.
Per quanto riguarda i sistemi “host-based” possiamo dire che studi e ricerche nel
campo degli IDS si sono finora focalizzati quasi esclusivamente su questa classe di
intrusion detection, come conseguenza, questi hanno raggiunto una relativa maturazione
e stabilità. Il principale svantaggio però è che dipendono dal sistema operativo dell’host
che stanno monitorando, quindi sono sottoposti ad enormi rischi legati ad attacchi
finalizzati alla disinformazione. Infatti un aggressore subito dopo aver violato il sistema
tenterà di installare un rootkit oppure un modulo maligno del kernel in questo modo le
informazioni a cui può accedere l’intrusion detection host based saranno sicuramente
compromesse. L’IDS segnalerà il tentativo di intrusione all’amministratore, ma egli
31
vedendo che tutto procede normalmente (grazie al lavoro del software di
disinformazione installato dall’aggressore) penserà sicuramente ad un falso allarme.
2.2.3 On-Line (In-Line, Real-Time), Off-Line
Su questi termini ci soffermiamo perchè rappresentano spesso fonte di confusione.
Vengono definiti “on-line” gli IDS che analizzano i dati mentre le azioni avvengono,
mentre i sistemi di tipo “off-line” o batch analizzano i dati a posteriori. Ultimamente si
tende a considerare questi ultimi più come dei tool di “computer forensics” (ovvero, di
analisi a posteriori delle intrusioni, con scopi generalmente di polizia giudiziaria) che di
“intrusion detection” in senso stretto, ma nella definizione che abbiamo dato di
“Intrusion Detection System” come insieme di accorgimenti mirati a rilevare,
identificare e contenere le intrusioni, è indubbio che sistemi di questo tipo siano da
considerarsi totalmente inclusi.
All’interno dei sistemi on-line spesso si usa la definizione “real-time” per indicare
che l’IDS è progettato per gestire un determinato flusso di dati senza perdere pacchetti e
senza rimanere con un “buffer” in attesa di essere verificato.
I sistemi “in-line” invece sono una relativa novità, e spesso fanno parte della
categoria dei cosiddetti “intrusion prevention systems”. In sostanza, se un IDS è in-line
esso è posizionato come un firewall o uno switch sulla “traiettoria” dei pacchetti, e la
sua funzione più ovvia è quella di poter fungere anche da filtro oltre che da analizzatore,
mentre invece gli IDS on-line di tipo tradizionale sono solitamente posizionati su una
porta di rete che presenta una “copia” di tutto il traffico.
2.2.4 Sistemi Centralizzati e Distribuiti
Un IDS può essere costituito da più processi eseguiti su varie macchine,
denominati sensori. Un esempio notevole in campo accademico, forse uno dei primi e
più documentati, è il DIDS,(Distributed Intrusion Detection System, sistema di
rilevamento delle intrusioni distribuito). A volte, se tali macchine sono dedicate
esclusivamente al software di intrusion detection, esse vengono chiamate sensori o
32
sonde, e vengono spesso realizzate sotto forma di soluzioni integrate composte da
hardware e software proprietario, ottimizzato e preinstallato.
Un IDS così strutturato può utilizzare un modello distribuito o centralizzato per
l’analisi dei dati e per la loro collezione, a seconda che i vari sensori procedano per
conto proprio o facciano riferimento a un server centrale. Le due cose possono essere
miscelate: le sonde potrebbero analizzare ciascuna i propri dati, per poi trasmettere i
risultati ad un server centrale per ulteriori rielaborazioni.
2.3 Caratteristiche Desiderabili per un IDS
2.3.1 Reattività
Una delle caratteristiche desiderate per un IDS è quella di poter in qualche modo
reagire agli attacchi, ovvero cercare di bloccarli automaticamente. Questo concetto,
spesso pomposamente denominato “Intrusion Prevention System”, in realtà pone una
serie di problemi non indifferenti.
Il primo problema è di tipo architetturale. Un sistema on-line, se non è real-time,
non ha nessuna reale possibilità di reagire ad una intrusione prima che si verifichino dei
danni. Se anche il sistema fosse real-time, l’unico modo efficace di consentirgli di
operare preventivamente sarebbe quello di porlo in posizione “in-line”, come filtro
pregresso di tutto il traffico. Ciò è fattibile, tuttavia considerazioni di performance
possono rendere questa soluzione irragionevole su linee ad alta capacità.
Una soluzione alternativa è un IDS on-line, real-time di tipo tradizionale, in
qualche modo accoppiato con un firewall, in grado quindi di interrompere la
comunicazione tra l’host vittima e l’attaccante. Questo sistema ha un difetto terribile:
innanzitutto se del traffico legittimo fa scattare per qualsiasi motivo una firma d’attacco
un utente si troverà privato di un servizio a cui ha diritto. Ma il problema diventa di
gran lunga peggiore se immaginiamo un attaccante che riesce a “forgiare” finti attacchi
provenienti da un indirizzo a suo piacere: potrebbe forzare il nostro stesso IDS a
chiudere fuori dal firewall indirizzi arbitrari.
Ultimo problema (in ordine di esposizione, ma non certo in ordine di importanza),
una certe tipologia di attacchi possono avvenire dall’interno della rete e non
33
dall’esterno. Spesso i firewall (o gli IDS in-line) sono alla frontiera della rete, e di
questo genere di attacchi non si accorgerebbero mai. Viceversa un IDS piazzato sulla
rete interna potrebbe individuarli e bloccarli.
2.3.2 Sicurezza Intrinseca: Survivability, Robustezza
Un IDS può essere progettato per la “survivability”: dal momento che
(esattamente come una scatola nera) le sue registrazioni possono essere l’unico mezzo
di stabilire cos’è accaduto su una rete, diventa importante garantire che il sistema stesso
sia quanto meno vulnerabile possibile. La sovversione di un sistema di difesa è infatti il
più pericoloso risultato di un attacco telematico, in quanto lascia agli attaccati un falso
senso di sicurezza.
Deve inoltre essere in qualche modo garantita la sicurezza della comunicazione
tra le varie componenti di un IDS distribuito, pertanto opportuni meccanismi di
autenticazione, crittografia, e verifica di integrità devono essere implementati per
evitare ogni sorte di attacchi di spoofing o di tipo man-in-the-middle.
È inoltre opportuno che, per ogni tipo di attacco ed aggressione (distruzione di
una sonda dell’IDS, flood di pacchetti per disturbare l’analizzatore di rete, ecc.) il
sistema presenti robustezza, ovvero non si arresti completamente ma esibisca una
graduale riduzione delle performance man mano che l’attacco procede e si aggrava.
2.3.3 Interazione con il Personale e Flessibilità
All’interno di un NOC (Network Operations Center) o di un SOC (Security
Operations Center) spesso vi sono pochi tecnici (specie durante i turni notturni) magari
non eccessivamente esperti, che devono sovrintendere al controllo di numerose reti
remote, che conoscono solo a grandi linee. Oltre alle ovvie problematiche connesse ai
falsi positivi, i sistemi di IDS devono essere progettati per comunicare quante più
informazioni possibile al personale che deve controllarli, nel modo più chiaro possibile,
e possibilmente fornendo anche una guida alla soluzione di un determinato problema.
In aggiunta, deve essere possibile una totale flessibilità e adattabilità del sistema a
circostanze molto specifiche di ogni singola rete. Questo può essere garantito in modo
34
molto automatico da IDS in modalità "anomaly detection", ma deve essere
opportunamente studiato per sistemi basati su firme.
2.3.4 Adattabilità ad Attacchi Nuovi
I possibili tipi di attacco contro una rete informatica si evolvono in continuazione.
Si possono distinguere una microevoluzione, processo con cui vengono ideati nuovi
attacchi all'interno di categorie di attacchi già esistenti, e una macroevoluzione più lenta
mediante la quale vengono scoperti dei metodi di attacco completamente nuovi.
È abbastanza evidente che la macro evoluzione può creare forme d'attacco che
sfruttino gli “angoli morti” del progetto di un IDS, ovvero tecniche di aggressione i cui
unici sintomi ricadano in quelle variabili che sono state scartate come indicatori in fase
di progettazione e quindi per cui il sistema non è architetturalmente predisposto. Per
fare un esempio, se il sistema controlla il traffico di rete al livello 3 ISO/OSI, e viene
sviluppata una metodologia di attacco che coinvolge manipolazioni al livello 2, è molto
probabile che un semplice aggiornamento della base di conoscenza non sia sufficiente.
Si rende necessaria, in questo caso, una revisione del motore di analisi in sé.
Viceversa, in linea di principio, se una forma di attacco è già nota, le sue
successive microevoluzioni dovrebbero essere relativamente semplici da inserire nella
base di conoscenza o nel modello dell'IDS. Il problema colpisce soprattutto i motori di
misuse detection, che in effetti operano su una base di firme che tende a diventare
sempre meno adeguata con il tempo (esattamente come accade per il software antivirus,
che è sicuramente un esempio più familiare).
2.3.5 Scalabilità e Concorrenza
Un buon sistema IDS deve essere in grado di scalare seguendo la crescita della
rete. Per questo le soluzioni network-based hanno spesso sofferto rispetto a soluzioni
host-based, in quanto analizzare gli eventi in modo distribuito è sicuramente più
semplice che cercare di capire qualcosa analizzando tutto il traffico della rete aggregato.
35
Tipicamente, quando un IDS di rete supera la propria capacità di analizzare i
pacchetti inizia a lavorare in una modalità “a campione”, scartando parte del buffer con
una tecnica simile a quella utilizzata dai router. Il problema è che, nel caso dei router, i
meccanismi di ritrasmissione del TCP evitano la perdita di pacchetti, mentre nel caso
dell'IDS, a meno di fortunate coincidenze, ciò che è perso è perso, e potrebbe trattarsi
proprio dei pacchetti interessanti.
Se tale coincidenza pare troppo azzardata e teorica, proviamo a guardare la cosa
dal punto di vista dell'attaccante: generare una marea di traffico di nessun interesse è
relativamente semplice; se ciò significa mettere in crisi l'IDS ancora prima che l'attacco
sia cominciato, si può essere sicuri che qualsiasi attaccante con un minimo di esperienza
adotterà questa tecnica, nella speranza che ad essere scartati siano proprio i pacchetti
con le firme d'attacco.
In aggiunta ai problemi di scalabilità, il sistema deve essere in grado di gestire
attacchi multipli concorrenti. Molto raramente un intruso proverà un singolo attacco
contro le nostre macchine: spesso utilizzerà uno strumento che prova attacchi multipli, e
vogliamo essere in grado di seguirli tutti. Non solo: seguendo le stesse considerazioni
fatte poco fa, se l'attaccante sapesse che il nostro IDS è in grado di seguire soltanto un
attacco alla volta farebbe in modo di generare un finto attacco proveniente da chissà
dove per “distrarre” il sistema.
2.4 Problemi Tipici di un IDS
2.4.1 Individuazione di Attacchi Nuovi, Modificati o Codificati
I sistemi informatici possono essere definiti, con il massimo grado di astrazione,
macchine dagli stati finiti: significa letteralmente che esiste un numero specifico e
predefinito di stati che un sistema può raggiungere. Questa limitazione ostacola l’IDS,
poiché questo può armarsi adeguatamente solo in un singolo momento; in altre parole, è
armato quanto lo sono le dimensioni del proprio database.
In primo luogo, come si possono conoscere in anticipo le caratteristiche che
costituiscono un tentativo di intrusione che non si è ancora verificato? È ovviamente
impossibile avvertire di un attacco che non è mai stato visto.
36
In secondo luogo, si può solo intuire che quanto accaduto in passato possa
ripresentarsi in futuro: è possibile creare una firma per un attacco subito dopo tale
evento, ma non vi è la certezza che quello stesso attacco si verifichi nuovamente con le
stesse modalità viste in precedenza. Una leggere modifica apportata ad un attacco noto,
infatti, potrebbe ostacolare la capacità di rilevamento del sistema.
Una terza considerazione è che un IDS può essere incapace di distinguere un
nuovo attacco con rumore bianco di fondo di qualunque rete: l’impiego della rete
potrebbe essere troppo intenso oppure un numero eccessivo di falsi positivi potrebbe
disabilitare le regole.
Un problema che rientra in questo ambito è rappresentato dalle codifiche
alternative per i dati. Il testo standard inviato fra un client e un server Web può infatti
essere codificato per essere interpretato come Unicode, che può rappresentare tutti i
simboli conosciuto Questi valori, però, devono essere successivamente esaminati e
convertiti in ASCII per l’elaborazione standard. Per fortuna una gran parte dei sistemi
implementa una pratica detta normalizzazione del protocollo, che prende una stringa di
input ed assorbe tutte le codifiche, gli spazi bianchi e qualsiasi delimitatore di
protocollo conosciuto nel tentativo di produrre la forma più basilare dell’input.
Purtroppo, tutte le normalizzazioni immaginabili non possono risolvere il
problema del monitoraggio dei pacchetti software closet source; senza informazioni
dettagliate sul funzionamento di un sistema, può non esservi alcuna spiegazione per le
funzioni non standard e non documentate. IIS (Internet Information Server) di
Microsoft, ad esempio, aveva la particolare funzione di consentire una codifica
alternativa (%u####) alla normale codifica Unicode (%####). Il worm Code Red si è
servito di questa tecnica, precedentemente sconosciuta, allo scopo di aggirare molte
firme dell’IDS preparate per corrispondere specificamente alla vulnerabilità da lui
sfruttata.
Un altro metodo utilizzato per “nascondere” una stringa di attacco ad un IDS è il
polimorfismo. L’obiettivo del codice polimorfo è conservare le stesse funzionalità
assumendo però una forma strutturalmente diversa da quella originale. Il polimorfismo
si ottiene prendendo il codice di hacking e codificandolo con una forma di algoritmo
reversibile. Vengono ad esempio sostituite opportunamente tutte le istruzioni basate
sulla sequenza di NOP (No Operation), in quanto questo codice viene tipicamente usato
nei buffer overflow e quindi molti IDS hanno una specifica firma per riconoscerlo. Il
37
carico di lavoro così codificato è poi inviato sulla rete con una piccola funzione di
decodifica prefissata. Quando il codice di attacco agisce sul target, il decodificatore
“apre” il carico di lavoro originario e lo esegue; in questo modo la funzionalità
originaria è conservata.
La base per generare il codice polimorfo è che vi è sempre più di un modo per
raggiungere un determinato scopo: se, per sfruttare una vulnerabilità si dovesse
calcolare il valore 4, si potrebbe conteggiare 2+2, 3+1, 6-2 e così via. Esiste un numero
letteralmente infinito di modi per calcolare un valore ma per un IDS che esamina il
traffico di rete, non vi è modo di identificare un 2+2 come equivalente di 3+1; esso
riceve solo la istruzioni di basso livello da valutare con una forma conosciuta, quindi
non le interpreta come fa invece l’host target.
2.4.2 Falsi Positivi e Falsi Negativi
Gli errori di un IDS vengono tipicamente suddivisi in due categorie. Si parla di
“falso positivo” quando l’IDS segnala come anomala un’azione che è legittima o
innocua. Si parla di “falso negativo” quando viceversa un IDS non suona l’allarme in
presenza di una azione evidentemente maliziosa.
I “falsi positivi” possono suonare innocui: in fondo, meglio essere avvertiti una
volta di troppo che una volta di meno. La famosa favola del ragazzino che gridava “Al
lupo!” ci ricorda che questo non è sempre vero: un IDS che segnala in continuazione
come “pericolose” azioni perfettamente normali dopo un po’ verrà ignorato. Eliminare i
falsi positivi è dunque uno dei focus della ricerca sugli IDS, in particolare per sistemi di
anomaly detection. Non và comunque dimenticato che anche se a prima vista questo
problema sembra affliggere solo i sistemi basati sul riconoscimento delle anomalie,
potrebbe presentarsi anche in sistemi misuse detection. Se infatti nella base di
conoscenza fosse inserita una firma di attacco generica con lo scopo di rilevare diverse
varianti di un particolare attacco, questa firma molto probabilmente genererà una certa
percentuale di falsi positivi
I falsi negativi sono invece assai più pericolosi: si tratta del mancato
riconoscimento di una forma d'attacco. In generale, in un sistema basato sulla misuse
detection, un falso negativo è associato con la mancanza di una firma per l’attacco
effettuato (e ricadiamo quindi nel problema dell'individuazione di nuovi attacchi
38
descritto nel paragrafo precedente). In un sistema basato sull'individuazione di anomalie
invece è più probabile che si abbia un falso negativo magari anche su un attacco che in
precedenza era stato riconosciuto, proprio a causa della natura statistica di questo tipo di
sistemi.
2.4.3 Inserimento ed Elusione
Per abbattere lo sforzo dell’analisi dei dati un IDS di rete lavora su vari livelli. I
livelli più bassi, cioè quelli di trasporto e di rete, sono quelli in cui l’aggressore ha forti
opportunità di confondere, ingannare o eliminare il sensore dell’intrusion detection.
Tutte le facoltà di rilevamento dell’IDS si affidano alla capacità di interpretare
correttamente il traffico di rete proprio come farebbe l’host target, per questo motivo
ingannare il livello di rete significa ingannare di conseguenza l’intero sistema di
intrusion detection.
L’aggressore potrebbe frammentare il proprio traffico in modo che sia assemblato
diversamente dall’IDS e dall’host target: di conseguenza egli può portare a termine
l’attacco senza che l’intrusion detection riesce ad interpretare l’evento in modo
adeguato. I principali metodi per ottenere questo scopo sono l’inserimento e l’elusione.
L’inserimento si affida alle situazioni in cui l’IDS accetta alcune informazioni con
la supposizione che farà così anche l’host target; se, tuttavia, l’IDS non interpreta il
flusso di rete nello stesso modo in cui lo interpreta il target, esso ha una diversa
comprensione dell’aspetto dello scambio e sarà perciò inefficace nell’avvertire
l’attacco; la firma dell’IDS non corrisponderà in tal caso ai dati acquisiti dalla rete.
Supponiamo che si voglia realizzare una firma per cercare la stringa “CODE RED” in
una qualsiasi richiesta Http. L’IDS vedrebbe “CODE NOT RED” al posto di “CODE
RED” quindi esso non troverà alcuna corrispondenza con le proprie firme, mentre l’host
target riceverebbe “CODE RED”, avendo perso il “NOT” nel tragitto poiché il
pacchetto che lo conteneva non corrispondeva alla comprensione che il target aveva
degli standard.
L’elusione è il contrario dell’inserimento: essa si basa sulla situazione per cui un
sistema target accetta i dati che l’intrusion detection ignora. Un attacco potrebbe quindi
apparire all’IDS come “CODE”, mentre il target riceve “CODE RED”. Questo tipo di
aggressioni può essere compiuto in svariati modi. In qualsiasi momento, la
39
comunicazione TCP/IP può essere terminata da una delle due parti; se l’IDS interpreta
in modo scorretto un FIN o un RST che provengono da un aggressore e che l’host target
non ha accettato (per esempio se l’IDS non ha monitorato correttamente i numeri di
sequenza) l’aggressore è libero di comunicare tranquillamente.
Inserimento ed elusione si basano quindi su una visione limitata che un intrusion
detection ha dell’effettivo stato dello stack TCP/IP interno di ogni host.
Nell’intestazione IP vi sono numerosi campi in cui attraverso una modifica è
possibile creare le condizione per sfruttare alcune vulnerabilità di inserimento o di
elusione. Se si modificano ad esempio le dimensioni del pacchetto, L’IDS può avere
difficoltà a capire dove iniziano i livelli superiori del pacchetto stesso (elusione). Un
altro campo a cui occorre prestare attenzione è il Checksum IP: se si riesce ad inserire
dei pacchetti con checksum non valido nel flusso dati, l’IDS può accettarli come validi
se non calcola manualmente il checksum di ciascuno di essi (il progettista può aver
ritenuto eccessivo il carico di lavoro dell’elaborazione), mentre saranno scartati dal
sistema finale (inserimento).
2.4.4 Elusione Basata Sul TTL (Time-To-Live)
In una tipica configurazione di rete l’IDS viene quasi sempre posizionato sul
perimetro della rete; in questo modo l’intrusion detection può monitorare tutte le
comunicazioni su Internet. Purtroppo, se un aggressore è in grado di eseguire traceroute
o di ridurre metodicamente il TTL del traffico verso il target e identificare l’esatta
quantità di salti necessari per raggiungere l’host, egli può inviare alcuni pacchetti con
valore TTL insufficiente. Tutto ciò ha l’effetto di garantire che con un basso TTL non
raggiungeranno mai il sistema target, ma verranno considerati dall’IDS come parte del
flusso dati (inserimento). Fortunatamente oggigiorno è molto difficile riuscire ad
eseguire traceroute, ping o applicativi simili verso host interni di una rete perché questo
tipo di pacchetti vengono bloccati alla frontiera dal firewall ma comunque è bene tener
presente l’esistenza di questo scenario di elusione.
40
2.4.5 La Frammentazione IP (Internet Protocol)
Il riassemblamento della frammentazione IP è la base di numerosi attacchi. Se
l’IDS non riassembla i frammenti IP nello stesso modo dell’host target, non può far
corrispondere il pacchetto nel proprio database delle firme. Nelle normali operazioni di
rete, i frammenti IP arrivano tipicamente nell’ordine in cui vengono inviati, ma non è
sempre così. L’assemblamento può complicarsi anche a causa della necessità di tenerli
in memoria finchè viene ricevuto l’ultimo frammento, allo scopo di completare
l’assemblamento dell’intero pacchetto. Sorge quindi anche un problema di DoS: è
possibile trasmettere molti frammenti per occupare le strutture o i buffer interni, in
modo che l’IDS possa iniziare a rilasciare pacchetti o perfino subire un crash.
È possibile sviluppare ulteriormente questo problema quando vi si aggiunge la
complessità del garbage collection interno. Cioè quel sistema che ad intervalli regolari
si occupa di rimuovere dalla memoria dati non più utilizzati da nessuno o rimasti orfani
del processo che li ha generati perché ormai terminato. Un IDS che ascolta sul filo può
dover rendere conto delle sessioni di migliaia di host, mentre ogni host deve
preoccuparsi solo del proprio traffico. Un sistema host può consentire ai frammenti di
arrivare nel flusso con tempi eccessivamente lunghi, mentre un IDS potrebbe avere
timeout più aggressivi, imposti al garbage collection, allo scopo di supportare la
gestione di un sistema più esteso. Se l’aggressore invia un attacco che consiste di tre
frammenti e trattiene l’ultimo frammento fino allo scadere di un lasso di tempo
significativo, e se l’intrusion detection di rete non ha processi identici per la gestione dei
frammenti interni (e pare che questo sia quasi impossibile da raggiungere), esso non
dispone di un’immagine coerente del pacchetto IP e, di conseguenza, non può eseguire i
processi di corrispondenza della firma.
2.4.6 Problemi Legati al Protocollo TCP
Finora abbiamo visto i problemi legati al protocollo IP, ma anche l’header TCP
contiene una serie di campi aperti allo sfruttamento; di conseguenza, se l’IDS non lo
esamina completamente, vi sono opportunità di elusione e di inserimento. Il campo
41
CODE definisce il tipo di messaggio inviato per la connessione; se qualcuno inoltrasse
una combinazione non valida o un pacchetto che non incontra il flag ACK, l’host target
potrebbe rifiutare il pacchetto mentre l’IDS invece lo accetterebbe (possibile
inserimento). Anche i segmenti contrassegnati come SYN possono includere dati e, a
causa dell’impiego relativamente raro di questa opzione, un IDS potrebbe ignorare il
contenuto di questi tipi (elusione). Infine anche il campo Checksum presenta le stesse
problematiche viste in precedenza per il protocollo IP.
Il riassemblamento del flusso TCP inoltre presenta numerosi problemi, simili a
quelli della frammentazione IP. I segmenti TCP possono arrivare in modo irregolare,
sovrapporsi o essere ridondanti, quindi l’IDS deve prestare un’attenzione particolare nel
monitorare i numeri di sequenza di ciascuna connessione, allo scopo di garantire che
non vengano desincronizzati. Nel caso di un segmento TCP ridondante ad esempio,
alcuni host potrebbero conservare il vecchio frame, mentre altri potrebbero rifiutarlo in
favore dell’ultimo ricevuto.
Un intrusion detection inoltre deve anche conoscere bene le dimensioni delle
finestre annunciate per ciascuna connessione; questo valore viene spesso regolato
durante una sessione per garantire il massimo throughput. Se l’IDS perde di vista le
dimensioni della finestra TCP, può diventare vulnerabile ad un attacco di inserimento in
cui l’autore invia dati superando le dimensioni della finestra; in questo caso l’host di
destinazione rilascia i pacchetti che vengono ricevuti al di fuori delle proprie dimensioni
annunciate.
2.5 Un’architettura Rilevante: SNORT
Snort è un IDS network-based, basato sulla misuse detection. È un progetto
sviluppato sotto GPL (GNU public license), distribuito gratuitamente su Internet in
formato open source e aperto ai contributi della comunità, l’ideale come riferimento per
un lavoro scientifico. Inoltre, Snort è uno dei progetti open source più famosi del
mondo, e uno dei pochissimi esempi di IDS non commerciali che godano di un supporto
e di una base installata tali da renderlo un “concorrente” di molti sistemi commerciali.
È un sistema multipiattaforma che utilizza le librerie di cattura pacchetti libpcap
(le librerie per la cattura di pacchetti di rete al livello più basso della struttura ISO/OSI
42
quindi bypassando il sistema operativo). L’architettura di Snort comprende tre
sottosistemi primari: un packet sniffer/decoder altamente performante; un motore a
regole basato sul pattern matching; e un sottosistema per il logging, la creazione di
report, e l’invio di avvisi all’amministratore di rete.
Concentriamoci sul componente di analisi, Snort implementa un linguaggio di
descrizione utilizzato per costruire qualsiasi regola. Il linguaggio con cui vengono
espresse le regole di Snort è molto semplice ed efficace. Ecco degli esempi di regole:
1. log tcp any any -> $HOME_NET 79
2. alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg: "SCAN Proxy
attempt";)
3. alert ip $EXTERNAL_NET any -> $HOME_NET 0:1024 (msg: "SHELLCODE
linux shellcode"; content: "|90 90 90 e8 c0 ff ff ff|/bin/sh";)
4. alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg: "ICMP
taceroute"; ipopts: rr;)
5. alert tcp $EXTERNAL_NET any -> $HTTP_SERVER 80 (msg: "WEB-ATTACK
chgrp command attempt"; flags:A+; content: "/usr/bin/chgrp"
nocase;)
Le variabili $EXTERNAL_NET, $HOME_NET e $HTTP_SERVER sono solitamente
definite nello stile 10.10.10.0/24. In questo particolare esempio stiamo specificando
un intervallo della classe C 10.10.10.*. La parola chiave msg definisce il messaggio
che sarà inviato all’amministratore se la regola corrisponde; flags definisce quali flag
TCP sono impostati; ipopts impone le opzioni di un pacchetto IP mentre content, infine,
è utilizzato per specificare una serie unica di dati che appare nel contenuto effettivo del
pacchetto. Nel campo del contenuto, tutto ciò che si trova tra le barre verticali è in
formato esadecimale e tutto il resto è in ASCII.
La prima regola scatta quando viene rilevato del traffico TCP, da qualsiasi host,
qualsiasi porta sorgente (tcp any any), verso un host dell’intervallo $HOME_NET porta 79
e richiede a Snort di effettuare il logging del pacchetto.
La seconda regola attende i tentativi dall’esterno ad un host interno sulla porta
TCP 8080 che è spesso utilizzata per i proxy Web.
La terza regola cerca una sequenza d’uso comune del codice della shell all’interno
di qualsiasi pacchetto IP diretto ad una porta compresa nell’intervallo 0:1024.
43
La quarta attende i pacchetti IP su cui è attivata l’opzione Record Route (rr),
mentre l’ultima regola cerca la stringa /usr/bin/chgrp diretta alla porta 80 Http.
Il database contenente le regole di Snort è continuamente aggiornato sia per
includere firme di nuovi attacchi sia per eliminare delle “cattive” firme che l’utilizzo
quotidiano ha dimostrato essere solo autori di falsi positivi. Inoltre è possibile
personalizzare il database aggiungendo o rimuovendo specifiche firme, ovviamente
tutto a proprio rischi e pericolo.
Snort conserva le sue regole di detection in una lista linkata bidimensionale per
applicare un algoritmo di pattern matching estremamente efficiente. Riprendendo il
concetto di “catena” utilizzato nel packet filtering del kernel di Linux, i pacchetti
vengono fatti “combaciare” dapprima in orizzontale sulla base dell’header, ed in seguito
in verticale per le opzioni di payload solo in caso di match degli header, in modo da
ottimizzare il più possibile il tempo di analisi.
Per quanto riguarda invece sistemi di rilevamento delle intrusioni basati
sull’anomaly detection è difficile riportare un esempio significativo perché questo è
ancora un campo di ricerca molto attivo dove di continuo vengono proposte nuove idee
ed altre vengono scartate. Per tale motivo non esiste ancora un sistema o un progetto
che si è particolarmente distinto rispetto a tutti gli altri.
44
CAPITOLO 3
3 LE RETI NEURALI
3.1 Introduzione sulle Reti Neurali
Le reti neurali si basano sul modello di rete neurale naturale in cui l’elemento
costituente è il neurone biologico. I segnali tra neuroni vengono trasmessi lungo
l’assone, che invece riceve gli impulsi attraverso terminali chiamati dendridi.
Dall’assone si diramano le sinapsi che si andranno a collegare alle altre cellule. Il
segnale trasmesso tra cellule è di tipo digitale, nel senso che grazie ai neurotrasmettitori
la cellula può propagare un segnale alto o basso analogamente a quanto succede nei
circuiti digitali con la trasmissione di una tensione alta per rappresentare il valore 1 ed
invece l’utilizzo di una tensione bassa per indicare il valore 0. Il corpo della cellula è
detto invece soma.
Vediamo due caratteristiche particolari del modello di rete neurale naturale che si
ripercuotono sulle reti neurali artificiali.
Il segnale che si propaga dal soma lungo l’assone è uno, infatti ogni neurone ha
un unico assone, esso però arriva a più cellule mediante le sinapsi: poiché ogni
sinapsi ha un suo potenziale sinaptico il segnale che arriverà ad ogni neurone
non sarà lo stesso. Questo si tradurrà nelle reti neurali artificiali nel peso o
coefficienti dei collegamenti tra un’unità neurale e l’altra;
Un altro concetto importante è quello della soglia: se i segnali in ingresso ad una
cellula supera una certa soglia, allora la cellula genera un potenziale di
attivazione che comincia a propagarsi lungo il proprio assone. Questo concetto
invece si ritroverà nelle reti neurali artificiali con il nome di funzione di
attivazione.
45
Capitolo 3 – Le Reti Neurali
Le reti neurali artificiali sono costituite quindi da un elevato numero di unità
elementari, chiamate neuroni o nodi, organizzate di solito in uno o più strati. Il primo
strato, denominato anche strato di ingresso e l’ultimo strato, denominato anche strato
uscita, permettono alla rete neurale di interagire con l’esterno. In particolare lo strato di
ingresso viene utilizzato per fornire alla rete l’ingresso da elaborare, mentre quello di
uscita viene utilizzato dalla rete per comunicare il risultato della propria elaborazione.
Vediamo a questo punto, nella figura seguente, lo schema di una singola unità
elementare o neurone.
Figura 3.1 Schema di un neurone con n Ingressi ed una sola Uscita
I neuroni di ciascun strato hanno una struttura simile tra loro, ma si distinguono
per “stato di attivazione”, e per un “vettore dei pesi”, che ha la stessa dimensione
dell’ingresso, e che caratterizza le connessioni che hanno con gli altri nodi.
Le varie unità, sono infatti solitamente interconnesse con le altre; sia con le unità
degli strati adiacenti, sia con unità dello stesso strato (connessioni laterali). Tali
connessioni possono avere molti significati e possono essere associate ad un
coefficiente di connessione o peso (indicati con wi nella figura precedente), che
caratterizza l’importanza assunta dai segnali che viaggiano lungo quella particolare
linea.
Esistono reti prive di Localizzazione Spaziale, nelle quali non si tiene conto né
della distanza tra due unità, né della loro posizione. Nelle reti con localizzazione
spaziale invece si tiene conto della posizione spaziale occupata da ogni singola unità. Il
modo in cui le varie unità sono disposte ed il tipo di interconnessioni presenti
46
caratterizzano la topologia della rete. Una possibile topologia è mostrata nella figura
seguente:
Figura 3.2 Rappresentazione della topologia di un percettrone multistrato
La funzione di attivazione caratterizza il modo in cui viene determinato lo stato di
uscita di una particolare linea di uscita di un neurone. Questa funzione viene definita
con l’introduzione di altri due importanti concetti : il potenziale di attivazione e la
funzione di uscita.
Definiamo a questo punto il potenziale di attivazione. Facendo riferimento alla
figura 3.1, supponiamo che il particolare neurone di cui vogliamo calcolare il potenziale
di attivazione abbia n segnali in ingresso (I1,I2,…,In) e che a ciascuno di essi venga
associato un peso rispettivamente (w1,w2,…,wn). Possiamo quindi definire il potenziale
di attivazione per tale neurone come:
n
P (t ) = ∑ wi ⋅ xi (t )
(3.1)
i =1
In questa formula i pesi dei coefficienti non sono dipendenti dal tempo, perché
stiamo ipotizzando che la rete neurale non si trovi in fase di addestramento
(spiegheremo in dettaglio nel seguito questa fase). In tal caso infatti anche i pesi
sarebbero dipendenti dal tempo.
La funzione di uscita invece stabilisce il modo in cui il segnale trasmesso lungo la
linea di uscita dipende dal potenziale assunto dall’unità neurale stessa all’istante
precedente ossia:
47
Out (t + ∆t ) = F ( P(t ))
(3.2)
Esistono diverse possibilità per la funzione F(P(t)) ad esempio:
Funzione a soglia:
⎧1 se P(t ) ≥ s
F ( P(t )) = ⎨
⎩0 se P(t ) < s
(3.3)
L’uscita restituita da questo tipo di funzione è quindi un’uscita digitale (0 o 1).
La soglia viene solitamente posta uguale a zero.
Funzione lineare:
F ( P(t )) = α ⋅ P(t )
(3.4)
L’uscita è quindi in questo caso lineare dal potenziale assunto dall’unità neurale
stessa all’istante precedente secondo la costante di proporzionalità α.
Funzione Sigmoidale:
Questo tipo di funzioni sono utilizzate per rendere più soft il gradino visto in
precedenza con le funzioni a soglia. Tali funzioni hanno le seguenti proprietà:
1
;
2
Se P(t ) → ∞ allora Out (t + ∆t ) → 1.
Se P(t ) = s allora Out (t + ∆t ) =
Segue il grafico di una possibile funzione sigmoidale:
Figura 3.3 Andamento di un possibile funzione sigmoidale
48
(3.5)
Le reti neurali lavorano a tempo discreto: l’elaborazione procede secondo una
sequenza precisa di istanti di lavoro in ognuno dei quali la rete ha un particolare
ingresso, stato interno ed uscita.
La conoscenza accumulata dal sistema è distribuita e contenuta nella struttura
stessa dei coefficienti di connessione, mentre l’informazione che il sistema sta
elaborando è contenuta nei potenziali di attivazione delle differenti unità neurali. Si
tratta quindi di una rappresentazione della conoscenza con un “approccio subsimbolico” in quanto un’entità non è rappresentata da un preciso modello.
Le reti neurali, infine, possono elaborare un grosso quantitativo di informazioni,
mantenendo una ridotta complessità ed un relativamente basso costo computazionale. In
quanto il numero di unità neurali sono solitamente poche centinaia ed inoltre vista la
struttura della rete l’elaborazione viene fatta in modo altamente parallelo contenendo
così i tempi di calcolo necessari.
3.2 Apprendimento
Tutte le caratteristiche descritte nel paragrafo precedente come: funzione di
attivazione, pesi dei collegamenti, architettura della rete e dinamica temporale devono
essere impostate correttamente per permettere alla rete neurale di comportarsi in
maniera desiderata. La metodologia normalmente utilizzata per definire il valore di
questi parametri fa uso di un particolare algoritmo di addestramento che permette,
attraverso piccole raffinazioni successive di giungere al valore ottimo di alcuni di questi
parametri come ad esempio i coefficienti dei vari collegamenti tra le unità neurali. Altre
caratteristiche invece come funzione di attivazione, dinamica temporale e topologia
della rete sono stabilite a priori, durante il progetto della rete stessa, tenendo conto delle
finalità del sistema, quindi prima della fase di addestramento vera e propria.
Una delle maggiori proprietà di una rete neurale consiste quindi proprio
nell’apprendimento: cioè la dinamica delle modificazioni del comportamento derivanti
dalle esperienze avute in un determinato spazio temporale, il tempo di addestramento.
L’obiettivo della fase di addestramento è quello di far avvicinare il più possibile il
comportamento della rete a quello desiderato. Possiamo quindi arrestare l’algoritmo di
apprendimento quando la differenza che intercorre tra la risposta delle rete e la risposta
49
corretta da noi desiderata, cioè l’errore commesso, scende al sotto di una certa soglia. In
caso contrario possiamo procedere con l’addestramento per un numero di passi ben
definito e prefissato riponendo in secondo piano l’errore commesso. In quanto a volte
potrebbe essere difficile determinare quando un errore è accettabile perché dipende
dalla specifica implementazione della rete, ma soprattutto dal particolare contesto in cui
il sistema sta operando.
La scelta del numero di passi di addestramento porta con sé due problemi. Il
primo quello più importante è rappresentato dall’interferenza catastrofica. Il problema
consiste nella tendenza della rete a cancellare le informazioni apprese in passato a
favore di quelle più recenti. Questo fenomeno avviene sia nel caso di diversi insiemi di
addestramento (training set), sia addirittura all’interno dello stesso training set dove gli
ultimi pattern appresi vengono privilegiati rispetto ai primi dell’insieme di
addestramento. Succede un po’ come quando dobbiamo apprendere qualcosa a
memoria: le ultime informazioni sono spesso chiare in mente, mentre le prime sono un
ricordo notevolmente più sfocato. Tutto dipende ovviamente dalla quantità di
informazioni da apprendere sia per noi che per la rete neurale.
Per superare in qualche modo il problema dell’interferenza catastrofica occorre
che gli ingressi all’interno del training set siano uniformemente distribuiti rispetto alla
loro distribuzione di probabilità.
Inoltre se dopo una prima fase di addestramento conclusa, decidiamo di iniziare
una seconda fase con un diverso insieme di dati rispetto al precedente occorre
inevitabilmente ripresentare alla rete anche il primo set di dati con cui abbiamo eseguito
il precedente addestramento, pena l’annullamento delle informazioni già memorizzate
dalla rete.
Esiste anche un problema in qualche modo opposto l’Overfitting. Un numero
troppo elevato di passi di addestramento infatti, potrebbero portare ad una
specializzazione della rete sul particolare set di dati utilizzato durante l’addestramento
con la conseguente perdita della capacità della rete neurale di generalizzare. Cioè
pattern leggermente modificati rispetto a quelli di addestramento potrebbero non essere
correttamente riconosciuti.
L’apprendimento
si
suddivide
in
due
macrocategorie:
l’apprendimento
supervisionato e l’apprendimento non supervisionato. Vediamo a questo punto una
descrizione di entrambi.
50
3.2.1 Apprendimento Supervisionato
La caratteristica fondamentale dell’algoritmo di apprendimento supervisionato è
che deve essere nota a priori l’uscita corretta che la rete dovrà fornire dato un
particolare pattern di ingresso.
I coefficienti dei collegamenti vengono inizialmente posti pari ad un piccolo
valore casuale; piccolo perché altrimenti la rete potrebbe non riuscire a modificare il
valore di tali coefficienti in modo da fornire il comportamento desiderato. Inizialmente
la rete, fornirà un’uscita casuale per un qualsiasi ingresso dato.
Per ogni pattern di ingresso presentato alla rete, questa produrrà un’uscita
basandosi sui valori correnti dei coefficienti di connessione, l’uscita così ottenuta verrà
confrontata con l’uscita corretta che deve essere nota. L’errore tra l’uscita fornita e
quella corretta viene utilizzato per correggere i pesi dei collegamenti della rete neurale
secondo un preciso algoritmo.
Il procedimento di addestramento viene ripetuto più volte finché le rete non
produce la risposta desiderata o l’errore medio non scende al di sotto di una soglia
prefissata.
3.2.2 Apprendimento Non Supervisionato
Gli algoritmi di apprendimento non supervisionato, invece sono caratterizzati dal
fatto che non hanno a disposizione nessuna informazione circa la risposta della rete
neurale ad un particolare ingresso.
La valutazione dei coefficienti di connessione in questo caso, dipende dalle
caratteristiche statistiche del campione dei pattern a cui la rete è sottoposta in fase di
addestramento. Con questo algoritmo quindi le reti neurali devono trovare
autonomamente le caratteristiche dei campioni forniti per produrre un’uscita corretta.
Un particolare tipo di apprendimento non supervisionato è rappresentato
dall’apprendimento competitivo. Questo tipo di apprendimento ha una finalità diversa
rispetto agli altri algoritmi di apprendimento visti finora. Cioè l’addestramento tenta di
far catturare alla rete neurale le regolarità statistiche della sequenza di pattern a lei
51
presentata durante questa fase, invece di far in modo che fornisca le risposte desiderate
dato un particolare ingresso.
L’algoritmo competitivo si può riassumere nei seguenti passi:
Inizializzazione casuale dei pesi;
Determinazione dell’unità vincitrice, cioè dell’unità neurale che si avvicina
maggiormente all’ingresso proposto, prendendo in considerazione il vettore dei
pesi di ciascuna unità neurale ed il vettore di ingresso;
Modifica del vettore dei pesi del vincitore in modo da renderlo il più possibile
simile a quello di ingresso.
Nel suo funzionamento questo algoritmo tende a spostare il vettore dei pesi delle unità
neurali in un punto centrale rispetto al vettore fornito in ingresso. Lo scopo finale è
quello adattare la distribuzione spaziale delle attività delle unità di uscita alla
distribuzione di probabilità degli ingressi.
Una rete addestrata in questo modo classifica ottimamente gli ingressi se, una
determinata classe di valori di ingresso attiva il giusto valore dei pesi e quindi la corretta
unità neurale. Se forniamo in ingresso, nella fase di test, pattern mai osservati in
precedenza, questi verranno classificati nella classe che rappresenta i vettori di ingresso
che più “assomigliano” all’ingresso attualmente analizzato.
Esistono varie implementazioni pratiche di questo algoritmo ma le più importanti sono:
la strategia “Hard Competitive Learning” e la strategia “Soft Competitive Learning”.
52
3.2.2.1 Hard Competitive Learning
Questa strategia di apprendimento nota anche come “winner-take-all” (il vincitore
prende tutto) è caratterizzata dal fatto che ogni pattern presentato in ingresso determina
una sola unità vincitrice su tutte le altre. Tale unità è l’unica che può fornire un segnale
di uscita.
Questo tipo di addestramento può portare però come conseguenza negativa alla
presenza nella rete neurale alla fine dell’apprendimento di “unità morte”. Le unità
morte, a causa di un’inizializzazione sbagliata o inadatta dei pesi non saranno mai
vincitrici e quindi non rappresentando nessun pattern di ingresso costituiscono solo uno
spreco di risorse.
Per evitare il problema occorrerebbe inizializzare i pesi delle unità neurali
mediante campioni distinti prelevati dalla distribuzione di probabilità di ingresso ed
evitare invece l’inizializzazione casuale che può inoltre condurre a risultati molto
differenti tra loro.
Un’ulteriore soluzione è rappresentata da un altro tipo di apprendimento basato
sulla filosofia “winner-take-most” come ad esempio la strategia “Soft Competitive
Learning” che illustreremo nel prossimo paragrafo.
3.2.2.2 Soft Competitive Learning
Diversamente dal metodo precedente questa metodologia di addestramento
conosciuta come “winner-take-most” (il vincitore prende quasi tutto), non modifica
solamente i pesi dell’unità vincitrice ma anche quelli delle unità immediatamente
vicine.
Rispetto alle unità vicine però, l’unità vincitrice viene adattata maggiormente
basandosi, come negli altri casi, sul pattern di ingresso considerato. Le altre unità invece
subiranno un adattamento inversamente proporzionale rispetto alla loro distanza dal
vincitore.
La distanza in questo caso può essere riferita allo stato di attivazione oppure in
caso di reti neurali con topologia spaziale ben definita è possibile utilizzare la distanza
tra i vari nodi della rete. Ad esempio la strategia “a bolla”, adatta le unità
53
nell’immediato intorno della vincitrice, in accordo con una distribuzione chiamata a
“cappello messicano”. Secondo questa particolare curva le unità maggiormente vicine al
vincitore subiranno un’adattamento di tipo eccitatorio, e quindi collaboreranno col
vincitore, mentre quelle più distanti saranno inibite. Nella figura seguente è riportata la
rappresentazione della suddetta curva:
Figura 3.4 Rappresentazione tridimensionale della curva a cappello messicano
Le reti neurali che utilizzano la strategia di apprendimento “Soft Competitive
Learning” possono essere suddivise in due categorie. La prima comprende le reti per cui
non è necessario stabilire a priori la dimensione, in quanto riescono a variare la propria
dimensione e topologia durante la fase di addestramento. In questa categoria rientrano le
reti “Growing Neural Gas” (GNG) introdotte da Fritzke nel 1995. Nella seconda
categoria invece rientrano quelle reti per cui è necessario decidere in anticipo la
dimensione come succede ad esempio con le reti “Self-Organizing sensory Maps”
(SOM) introdotte da Kohonen.
3.2.2.3 Competitive Hebbian Learning
Nell’ottica delle reti neurali che hanno la possibilità di modificare la topologia
durante la fase di addestramento citiamo un altro apprendimento molto importante il
“Competitive Hebbian Learning” (apprendimento hebbiano competitivo). Questo non
modifica i valori dei vettori di riferimento di ciascuna unità neurale ma si preoccupa di
creare le connessioni tra un nodo e l’altro generando in questo modo la topologia della
54
rete. Vengono modificate, ad ogni pattern di ingresso presentatati alla rete, solo le
connessioni tra i due nodi più vicini all’ingresso fornito. Le relazioni di vicinanza sono
stabilite utilizzando il concetto di distanza euclidea.
L’algoritmo può essere riassunto nei seguenti passi:
Ad ogni istante di addestramento, prima viene stabilità l’unità più vicina al
segnale di ingresso presentato e poi la seconda unità più vicina allo stesso
segnale di ingresso. Le distanze vengono calcolate in base alla distanza euclidea
ed inoltre in caso di pareggio l’unità viene scelta casualmente fra quelle
possibili, cioè quelle più vicine all’ingresso;
Tra le due unità selezionate si crea, a meno che non sia già presente, una
connessione non pesata.
Questo metodo, come spiegato in precedenza, serve solo ed esclusivamente per
generare le connessioni tra le varie unità neurali ma non gestisce i valori dei vettori di
riferimento di ciascun nodo. Per tale motivo non può essere utilizzato da solo ma
contestualmente ad un algoritmo principale di apprendimento che gestisca i valori dei
vettori di riferimento delle unità neurali.
3.3 Poliedri di Voronoi e Triangolazione di Delaunay
Una caratteristica molto importante delle reti che modificano la propria topologia
durante la fase di addestramento è la capacità di approssimare la distribuzione di un
qualsiasi ingresso. Prima di continuare però accorre introdurre due importanti concetti
preliminari, come il “diagramma di Voronoi” e la “triangolazione di Delaunay”.
Il diagramma di Voronoi VS di un insieme S = {w 1,...,w N } di punti w i ∈ ℜ D , è
dato da N poliedri D-dimensionali, i poliedri di Voronoi Vi . Il poliedro di Voronoi Vi
di un punto w i ∈ S , è dato da un insieme di punti v ∈ ℜ D che sono più vicini a w i di
ogni altro punto w j ∈ S , con i≠j, ossia:
{
Vi = v ∈ ℜ D : v − wi ≤ v − w j j = 1,K ,N
55
}
i=1,…,N
(3.6)
D
I poliedri di Voronoi forniscono una divisione completa dello spazio ℜ , poiché
N
ℜ D = Ii =1 Vi . La figura 3.5a, mostra i possibili poliedri di Voronoi, di un insieme di
campioni di punti nel piano, che formano il diagramma di Voronoi.
Figura 3.5 (a) Diagramma di Voronoi e (b) Triangolazione di Delaunay
Come è possibile osservare dalla figura, nel piano il grafo che rappresenta il
diagramma di Voronoi ha come vertici punti che sono contemporaneamente elementi di
tre distinti poliedri di Voronoi, mentre per quanto concerne le connessioni, queste sono
formate da punti che appartengono a due diversi poliedri di Voronoi.
La triangolazione di Delaunay DS , invece, su di un piano si ottiene se collegando
tutte le coppie w i , w j ∈ S , di poliedri Vi , Vj con cui condividono una connessione. La
figura 3.5b rappresenta la triangolazione di Delaunay corrispondente al diagramma di
Voronoi in figura 3.5a.
I concetti illustrati in questo paragrafo saranno utilizzate nei paragrafi seguenti per
descrivere le cosiddette “mappe auto organizzanti”, o “mappe che conservano la
topologia”. Queste mappe hanno la capacità di codificare pattern simili in unità
adiacenti e viceversa, unità neurali adiacenti sono relative ad ingressi con un certo grado
di somiglianza.
56
3.4 Mappe Auto Organizzanti
Una mappa auto organizzante è determinata attraverso una funzione Φs, definita
da un insieme M ⊆ ℜ D (insieme dei dati ingresso), e che assume valori nell’insieme G,
il quale rappresenta il grafo delle unità neurali i (i=1,…,N). Il mappaggio da M a G si
determina a partire da w i ∈ ℜ D , con i=1,…,N, relativo ai vertici i. Un vettore
caratteristico v ∈ M è mappato verso il vertice i*(v) , con un vettore w i*(v) più vicino a
v e con poliedro di Voronoi, Vi*(v) vicino a v. Il mappaggio Φs è completamente
determinato a partire da un insieme S = {w1,...,w N }, e quindi si può scrivere:
Φ S : M → G , v ∈ M → i *(v) ∈ G
(3.7)
dove i*(v) è dato da:
w i*(v) − v ≤ w i − v
∀i ∈ G
(3.8)
Una funzione Φ S da M a G che conserva la relazione di vicinanza deve fare in
modo che vettori v con caratteristiche simili, ossia che sono vicini all’interno di M,
siano mappati in vettori adiacenti nel grafo delle unità neurali G. Questo richiede che i
vettori w i e w j che sono vicini per quanto riguarda l’insieme di caratteristiche
corrispondono a vertici i e j che sono adiacenti nel grafo delle unità neurali.
La funzione inversa Φ S−1 dal grafo G sull’insieme M è determinata invece dalla
seguente relazione:
Φ S−1 : G → M ,
i ∈ G → wi ∈ M
(3.9)
assumendo che tutti i vettori w i , i=1,…,N si trovano in M. Analogamente a quanto
accade con la funzione diretta Φ S , la conservazione della relazione di vicinanza del
57
mappaggio inverso Φ S−1 è soddisfatta se i vettori w i e w j di vertici adiacenti i e j sono
vicini sull’insieme M.
Analizziamo a questo punto il problema della conservazione della topologia. Un
grafo G, forma una mappa che conserva la topologia di M se rappresenta i suoi elementi
mantenendo la loro esatta dimensione. La definizione formale è quindi: Un grafo G
forma una mappa che conserva la topologia di M, se il mappaggio Φ S da M a G ed il
mappaggio inverso Φ S−1 da G a M preservano la vicinanza. Solo in questo caso G
costituisce una mappa in cui posizioni adiacenti, nello spazio delle unità neurali,
corrispondono a caratteristiche vicine in M e, viceversa posizioni adiacenti in M
saranno rappresentate da neuroni vicini.
3.5 Mappe che Preservano la Topologia
In genere la triangolazione di Delaunay non definisce una mappa che preserva la
topologia di M. Questo risultato viene infatti raggiunto solo se, ogni elemento
dell’insieme S = {w1,...,w N }, che contiene i vettori di riferimento di tutte le N unità
neurali che appartengono all’insieme G, giace sullo spazio degli ingressi M.
Per questo motivo è stato introdotto il concetto di triangolazione indotta di
Delaunay, definito attraverso l’adiacenza dei poliedri mascherati di Voronoi.
Si definisce poliedro mascherato di Voronoi Vi(M) , la parte di Vi che è anche
parte di M, in altre parole Vi(M) = Vi ∩ M .
Ogni poliedro di Voronoi mascherato è una parte dell’insieme M, e invece di
formare una divisione completa dello spazio ℜ D come i poliedri di Voronoi, essi
N
formano un partizionamento completo solo se è valida la relazione M = Ii=1 Vi(M) .
La triangolazione di Delaunay DS è definita partendo dai poliedri di Voronoi,
analogamente la triangolazione di Delaunay indotta DS(M) è definita partendo dai
poliedri mascherati di Voronoi. La definizione formale è la seguente:
Sia M ⊆ ℜ D un insieme dato e S = {w1,...,w N } un insieme di punti w i ∈ M . La
triangolazione di Delaunay indotta D S(M) di S è determinata dal grafo che connette due
58
punti w i e w j se i loro poliedri mascherati di Voronoi Vi(M) e Vj(M) sono adiacenti,
ossia se Vi(M) e Vj(M) condividono un elemento v ∈ M o, in maniera equivalente, se è
valida la relazione Vi( M ) ∩ Vj( M ) ≠ ∅ .
La differenza tra triangolazione di Delaunay DS e la triangolazione indotta di
Delaunay DS(M) è rappresentata graficamente nella figura seguente:
Figura 3.6 (a) Triangolazione di Delaunay (linea spessa) e (b) Triangolazione di Delaunay indotta (linea
Spessa) che si ottiene mascherando la triangolazione di Delaunay
Vediamo ora una definizione, che ci servirà subito dopo, e che ci permette di
determinare quando la distribuzione dei punti w i è densa su M:
Sia S = {w 1,...,w N } un insieme di punti w i che sono distribuiti su un insieme dato
M ⊆ ℜ D . La distribuzione dei punti w i ∈ M , i=1,…,N è densa su M se per ogni v ∈ M
(
)
il triangolo ∆ v,w i0 ,w i1 , formato dal punto w i0 più vicino a v, il punto w i1 che è il
(
)
secondo più vicino a v che giace completamente su M, ossia se ∆ v,w i0 ,w i1 ⊆ M è
valida.
È possibile dimostrare che se la distribuzione S = {w 1,...,w N } di punti è densa in
M (definizione precedente), allora il grafo G formato attraverso la regola di
apprendimento hebbiano competitivo (descritta nel paragrafo 2.2.3 di questo capitolo) è
la triangolazione indotta di Delaunay DS(M) di S e quindi, forma una mappa che preserva
perfettamente la topologia di M.
59
3.6 La rete Self-Organizing Maps (SOM)
La rete Self-Organizing Maps (SOM), è una rete neurale che utilizza un
apprendimento non supervisionato ed è costituita da un insieme di nodi prefissati. La
SOM infatti non ha la possibilità di variare la propria topologia durante la fase di
addestramento, per questo motivo occorre decidere in anticipo le dimensioni delle rete
utilizzata.
I nodi sono collegati tra loro secondo uno schema deciso dall’implementatore
(solitamente rettangolare o esagonale), che hanno una loro posizione in uno “spazio dei
nodi” solitamente bidimensionale. Ogni nodo rappresenta una classe, e corrisponde
pertanto ad un punto nello spazio dei vettori di ingresso.
Vediamo subito l’algoritmo di addestramento di una SOM che avviene attraverso
una procedura iterativa. Ad ogni passo di apprendimento si ha in input un certo ingresso
v. Gli ingressi sono trattati come variabili random indipendenti di uno spazio di vettori
V, e la loro occorrenza è determinata da una funzione densità di probabilità P(v).
L’algoritmo è il seguente:
1. Inizializzazione: fissare appropriati valori iniziali dei pesi sinaptici, in base alla
distribuzione di probabilità degli ingressi. In assenza di una informazione a priori, i
valori sono scelti in maniera random.
2. Scelta dello stimolo: scegliere, secondo una funzione densità di probabilità P(v), un
vettore random v che rappresenta un “segnale sensoriale” di ingresso.
3. Risposta: determinare l’unità vincitrice r' , ossia il nodo che meglio approssima lo
stimolo in ingresso, tenendo conto della condizione:
v − wr' ≤ min v − wr
r
∀r ∈ A
(3.10)
Dove w r = (w r1,...,w rd )T è una notazione compatta per le connessioni sinaptiche del
neurone r, analogamente wr' è una notazione compatta per il neurone r ′ . L’insieme
A invece rappresenta l’insieme delle unità neurali.
60
4. Passo di adattamento: adattare i pesi sinaptici di ogni unità r secondo la seguente
equazione:
old
= w old
w new
r
r + εh rr'(v − w r )
(3.11)
dove, ε rappresenta il tasso di apprendimento che varia in funzione del tempo:
( ε(t) = ε i (ε f ε i )t t max ). Il valore iniziale di questo parametro, ε(t = 0) = ε i è piuttosto
grande e decresce lentamente con il numero di passi di adattamento verso un piccolo
valore finale ε(t = t max ) = ε f .
Inoltre hrr'
è una funzione gaussiana, detta anche funzione di vicinanza:
− (r − r' )
. Dove r rappresenta il neurone correntemente preso in
2σ 2
2
hrr' = exp
considerazione, mentre r ′ indica l’unità vincitrice. Infine σ rappresenta il raggio in
base al quale lo stimolo di ingresso determina le correzioni della mappa. Solitamente
si sceglie un valore di σ come funzione del tempo: σ(t) = σ i (σ f σ i )t t max , dove
σ(t = 0) = σ i indica il valore iniziale piuttosto grande che decresce lentamente con il
numero di passi di adattamento verso un valore finale prossimo a zero
σ(t = t max ) = σ f . In tal modo, inizialmente si forma una struttura grossolana della
mappa e poi si incorpora la struttura fine all’interno della mappa stessa, ottenendo
un aumento graduale delle selettività dei neuroni individuali durante il processo di
apprendimento.
5. Incremento: incrementare il parametro tempo t=t+1.
Se t < t max ritornare al passo 1.
La figura 3.7 mostra graficamente il funzionamento dell’algoritmo di
addestramento. Un ingresso v, appartenente ad una distribuzione V, seleziona attraverso
la funzione Φ un centro s. Di conseguenza i neuroni vicini, spostano il vettore dei pesi
ws verso l’ingresso v. L’ampiezza dello spostamento è inversamente proporzionale alla
distanza dell’unità dal centro s.
61
Figura 3.7 Rappresentazione di una distribuzione di ingresso e selezione di un nodo s per un valore v in
ingresso
La SOM non garantisce la conservazione della tipologia, a causa della sua
struttura notevolmente vincolata. Nel caso in cui non esiste una corrispondenza tra la
dimensione dello spazio M e la dimensione predeterminata del grafo G oppure se la
distribuzione degli stimoli di ingresso è fortemente convessa la SOM non riesce a
modellare correttamente la distribuzione di ingresso. È inoltre possibile osservare la
presenza di unità morte o connessioni che attraversano zone esterne di M. Per tali
ragioni occorre conoscere a priori le caratteristiche della distribuzione di ingresso per
stabilire, prima dell’addestramento, in fase di progetto la dimensione della rete ed
inoltre per garantire una corretta inizializzazione delle unità neurali.
3.7 La rete Growing Neural Gas (GNG)
La rete Growing Neural Gas (GNG) ha la capacità di modificare in fase di
addestramento la propria topologia, generando o eliminando all’occorrenza nodi o
connessioni. Questo le permette di superare i problemi legati alla scelta preliminare
della dimensione della rete neurale in quanto autonomamente riesce ad adattarsi ad una
particolare distribuzione di ingresso.
La rete è inizialmente formata da poche unità, sarà poi l’algoritmo di
addestramento ad inserire nuove unità dove occorre aumentare la densità dei vettori di
riferimento. Per ciascun pattern di ingresso presentato alla rete vengono selezionate due
62
unità vincitrici, cioè le due unità che in base ad una distanza euclidea hanno i vettori dei
pesi più vicini ai vettori che costituiscono l’ingresso. I due nodi così selezionati
vengono uniti da una connessione, nel caso non esista gia, ed inoltre le posizioni di
questi nodi e di quelli immediatamente vicini vengono modificati in base ad una
particolare regola di adattamento.
Ogni connessione è caratterizzata da un valore che ne specifica l’età, in
particolare, durante l’addestramento, le nuove connessioni vengono inizializzate a zero
mentre le altre non utilizzate vengono aggiornate aumentando l’età di una unità ad ogni
pattern presentato in ingresso. Quando l’età di una connessione supera un certo valore
di soglia viene rimossa dalla topologia.
Come citato in precedenza in addestramento, vengono aggiunte nuove unità
neurali. In particolare viene aggiunta una nuova unità dopo un numero prefissato di
iterazioni; il nuovo nodo viene creato in una posizione intermedia tra altri due nodi. I
due nodi prescelti sono: il primo è quello che ha accumulato il maggior errore ed il
secondo viene scelto, sempre in base al maggior errore accumulato, ma tra i vicini del
primo nodo scelto.
L’algoritmo completo del modello “Growing Neural Gas” è il seguente:
1. Inizializzazione: assegnare a due nodi (N=2) i valori dei pesi iniziali w i ∈ ℜ n ,
i=1,2, in base alla distribuzione di ingresso se nota, altrimenti in maniera random.
2. Scelta dello stimolo: selezionare un vettore di ingresso v dall’insieme M.
3. Determinazione del vincitore: determinare l’unità più vicina (vincitore) i 0 e la
seconda unità vincitrice i1 :
v − w i0 < v − w i1 < K < v − w i N −1
(3.12)
4. Crea connessione: se i 0 e i1 sono già connessi tra loro ( C i0i1 = 1 ), settare l’età della
connessione ( t i0i1 = 0 ); altrimenti se C i0i1 = 0 creare la connessione ( C i0i1 = 1 ) e
settare l’età della connessione a zero ( t i0i1 = 0 ).
63
5. Aggiornamento dell’errore: aggiungere la distanza al quadrato tra il segnale di
ingresso e l’unità più vicina nello spazio di ingresso ad una variabile contatore
locale:
∆error(i 0 ) = w i0 − v
2
(3.13)
6. Aggiornamento dei pesi: Aggiornare i pesi dell’unità vincitrice e delle unità
connesse all’unità vincitrice, mediante le seguenti formule:
(
)
(v − w )
w inew
= w iold
+ ε b v − w iold
0
0
0
(3.14a)
w inew = w iold + ε n
(3.14b)
old
i
dove ε b e ε n sono parametri di apprendimento costanti con un valore compreso tra
[0,1]. Il valore ε n dovrebbe essere scelto di due ordini di grandezza inferiore al
valore di ε b .
7. Incremento età: incrementare di 1 l’età di tutte le connessioni che partono dal
vincitore i 0 , ponendo t i0 j = t i0 j + 1 per tutti gli indici j con C i0 j = 1 .
8. Rimozione: eliminare tutte le connessioni di i 0 che hanno superato il tempo di vita,
ponendo C i0 j = 0 per tutti gli j con C i0 j = 1 e t i0 j > T . Inoltre se dopo questa
procedura esistono nodi con nessuna connessione, rimuovere tali nodi che
rappresentano le unità morte.
9. Inserimento nodi: se il numero di pattern di ingresso presentati alla rete è un
multiplo intero di un parametro λ, inserire una nuova unità mediante la sequenza:
a. Determinare il nodo q con il massimo errore accumulato;
b. Inserire una nuova unità r, tra q e il suo vicino con l’errore accumulato maggiore,
che assume un vettore dei pesi w r ∈ ℜ n :
(
)
wr = wq + wf 2
(3.15)
64
Connettere la nuova unità r con le unità q e f , C qr = 1 , C fr = 1 , e rimuovere la
connessione esistente tra q e f, C qf = 0 .
c. Diminuire le variabili dell’errore di q e f utilizzando un parametro α costante:
∆E q = −αE q
∆E f = −αE f
(3.16)
d. Ottenere la variabile dell’errore di r dall’errore di q e f:
(
)
Er = Eq + Ef 2
(3.17)
10. Diminuire le variabili di errore: ridurre l’errore accumulato da tutte le unità,
utilizzando un parametro costante β:
∆E i = −βE i
∀i ∈ ℜ n
(3.18)
La condizione di arresto dell’algoritmo può essere rappresentata o da una certa
dimensione della rete o da una qualche misura di performance. Se tale condizione è
verificata interrompere la procedura, altrimenti ritornare al passo 2.
Il parametro λ utilizzato nell’algoritmo precedente è molto importante in quanto
può influire negativamente o positivamente sul comportamento della rete neurale. Un
valore di λ troppo basso, porta ad una rapida diminuzione iniziale del valore medio
dell’errore ma in seguito, dovremo compiere un numero maggiore di iterazioni per
ottenere un basso valore dell’errore medio rispetto a quanto sarebbe stato necessario
utilizzando un λ più elevato. Inoltre un valore di λ basso può aumentare la probabilità di
avere “unità morte” che sono uno spreco di risorse in quanto non sono utili per il
raggiungimento dell’obiettivo da parte della rete neurale. Inversamente, un valore
troppo grande di λ determina una lenta crescita della rete e richiede un elevato numero
di iterazioni affinché i nodi siano opportunamente distribuiti.
L’algoritmo di apprendimento porta ad un graduale spostamento delle unità
neurali verso l’area dello spazio da cui provengono i segnali di ingresso. Inoltre
l’inserimento delle connessioni tra il vincitore e la seconda unità vincitrice e la
65
rimozione di unità ormai obsolete sono operazioni finalizzate al continuo inseguimento
della triangolazione di Delaunay indotta che si sta lentamente muovendo a causa
dell’adattamento dei vettori di riferimento.
Tale inseguimento, utilizzando anche l’apprendimento hebbiano competitivo per
la generazione delle connessioni non pesate che formano la topologia della rete, hanno
come risultato quello di ottenere una mappa che preserva perfettamente la topologia di
dell’insieme di ingresso M.
66
Capitolo 4 – Metodologia e Sistema Implementato
CAPITOLO 4
4 METODOLOGIA E SISTEMA IMPLEMENTATO
In questo capitolo descriveremo le varie fasi del progetto sperimentale sviluppato
nel lavoro di tesi, dall’obiettivo del progetto fino al risultato, cioè l’implementazione del
sistema. Come in ogni lavoro sperimentale il percorso lavorativo non è stato molto
lineare; sin dalle prime fasi,infatti, abbiamo dovuto affrontare diversi problemi di natura
teorica. L’unica idea certa era di voler tentare di introdurre dell’intelligenza artificiale in
un IDS per verificare in tal modo la fattibilità di questo approccio.
4.1 Obiettivo del Progetto
Per prima cosa si pone il problema di inquadrare il sistema IDS che vogliamo
realizzare in una delle categorie viste in precedenza nel capitolo riguardante gli
Intrusion Detection System. L’idea principale è studiare la realizzabilità di un IDS di
tipo network based con un approccio anomaly detection.
La scelta di utilizzare un sistema anomaly detection viene motivata da fatto che
l’approccio “misuse detection” è stato studiato approfonditamente ed implementato in
molti modi con risultati del tutto apprezzabili. Tuttavia, il paradigma su cui si basa sta
sempre più mostrando i propri limiti, basti pensare a tutta la serie di problematiche
legate alla ricostruzione del traffico di rete ed alla necessità di mantenere una visione il
più possibile coerente dello stack TCP/IP degli altri host; altrimenti in caso contrario
L’IDS non sarà più in grado di ricostruire fedelmente il pacchetto e quindi rilevare
l’intrusione.
Inoltre non bisogna dimenticare la necessità dei sistemi “misuse detection” di
utilizzare una base di conoscenza a priori (database di firme). Il costante aggiornamento
di questa base di conoscenza equivale ad un eterno gioco di scacchi in cui ad ogni
67
mossa corrisponde una contromossa uguale e contraria. Questi “mirror game” dove ad
ogni mossa si risponde con la mossa speculare sono però destinati alla vittoria
inevitabile di chi ha mosso per primo.
La caratteristica network based invece, è stata momentaneamente trascurata per
probabili problemi computazionali, in quanto l’osservazione del traffico di rete
proveniente e diretto dalla totalità degli host in una rete è sicuramente un compito
computazionamente molto impegnativo.
Quindi ci siamo orientati verso una soluzione ibrida, prendendo cioè
caratteristiche desiderabili sia dall’approccio network based che dall’approccio host
based. Il nostro sistema dovrà osservare il traffico di un host sulla rete, presumibilmente
un server Web, un server di posta elettronica o ancora un server di autenticazione
remota. Sotto questo aspetto si avvicina ad un sistema host based ma l’originalità della
nostra soluzione ibrida consiste nel fatto che l’IDS non è eseguito fisicamente dall’host
monitorato bensì in un computer diverso dedicato a tale scopo.
In questo modo possiamo sfruttare i benefici di entrambe le soluzioni. In quanto
un sistema così configurato può operare una “passive analysis”, senza quindi essere
rilevato, ponendo ad esempio la scheda di rete in modalità promiscua; il software poi si
occuperà di prendere in considerazione solo i pacchetti ricevuti ed inviati dall’host a cui
siamo interessati.
Inoltre caratteristica ancora più rilevante di questa configurazione ibrida, è che in
questo modo non si è legati al sistema operativo dell’host monitorato, come invece
avviene con i tradizionali sistemi host based. In quanto in tal caso, il sistema di
rilevamento delle intrusioni o delle anomalie, è appunto eseguito da una macchina
diversa e dedicata esclusivamente a tale scopo.
Questo ci permette di essere notevolmente più protetti da attacchi legati alla
disinformazione, come ad esempio l’installazione di un rootkit. Il nostro sistema, infatti
non deve prendere le informazioni necessarie al proprio funzionamento dal sistema
operativo dell’host monitorato, ma osserverà i pacchetti che esso riceve ed invia
direttamente dal filo di rete dove non sono possibili manipolazioni.
In ultimo occorre precisare che, la scelta di osservare un solo host di rete, non è
vincolante in alcun modo. Infatti dopo aver verificato la fattibilità in termini di capacità
computazionale è possibile modificare il sistema per permettergli di osservare più di un
host, o addirittura tutti gli host della rete, essendo nella stessa posizione fisica di un
68
classico Intrusion Detection System network based. Questo gli fornisce volendo la
possibilità di controllare l’intero traffico di rete senza dover ristrutturare completamente
l’implementazione presentata in questo lavoro.
Il sistema proposto ha come obiettivo finale quello di rilevare scostamenti
statisticamente significativi nell’andamento, del traffico di rete, dell’host che andremo a
monitorare, rispetto al comportamento “classico”.
A causa del proprio carattere statistico, ma anche perché almeno in un primo
momento trascureremo il contenuto dati dei pacchetti di rete, questo sistema non
rileverà mai la presenza di un pacchetto malformato o dal contenuto generato “ad hoc”
per sfruttare una vulnerabilità in un applicativo di rete eseguito sul nostro server. Per
questo motivo il sistema che proponiamo non vuole in alcun modo sostituire gli IDS
attualmente in uso, ma diversamente abbiamo tentato di implementare un sistema che
andasse ad affiancare un IDS classico.
Una possibile configurazione di esempio, come mostrato in figura 4.1, è quella di
affiancare al sistema proposto un tradizionale IDS misuse detection come ad esempio
Snort; in tal modo è compito di quest’ultimo ricercare nel traffico di rete pacchetti
malformati o altri tentativi di attacco che un sistema basato sull’anomaly detection
potrebbe non rilevare.
Figura 4.1 Una possibile configurazione di esempio per il sistema proposto
Il sistema proposto può essere comunque di supporto ad un amministratore di rete
che si occupa di sicurezza in molti altri modi. Analizzeremo, a questo punto, i due
principali per cui abbiamo verificato almeno in parte il funzionamento durante il nostro
lavoro.
Il primo si basa nel rilevare il più velocemente possibile la situazione in cui l’host
osservato sta generando del traffico di rete diverso da quello prodotto durante una
69
condizione di “normalità”. Infatti tale comportamento, potrebbe essere causato
dall’azione di un aggressore che una volta preso il controllo del server, lo sta utilizzando
a proprio piacimento. Se per qualche ragione (vedi tutte le problematiche che affliggono
un IDS tradizionale nel capitolo 2) l’IDS tradizionale non riesce a rilevare un attacco
che ha poi successo, un aggressore con un po’ di esperienza, installerebbe
immediatamente un rootkit o un modulo maligno del kernel per nascondere la propria
presenza ed in questo modo sfruttare il più a lungo possibile l’host compromesso. In
questo scenario il sistema qui proposto potrebbe fornire un valido aiuto rilevando una
variazione nel traffico di rete generato dal server osservato; variazione dovuta allo
sfruttamento da parte dell’aggressore del computer compromesso.
In secondo luogo, il sistema proposto ha mostrato una discreta capacità nel
rilevare attacchi di tipo DoS oppure tentavi di “fingerprinting” come ad esempio una
scansione delle porte, che un aggressore potrebbe eseguire verso un probabile futuro
bersaglio.
4.2 Informazioni Rilevanti all’interno dei Pacchetti di Rete
Dopo aver delineato la collocazione del nostro sistema circa le categorie di
Intrusion Detection System esistenti abbiamo immediatamente dovuto affrontare il
problema circa il tipo di dati da prendere in considerazione data l’infinita quantità di
informazioni che continuamente attraversa i collegamenti di una rete di computer.
Un pacchetto TCP o UDP consta principalmente di due parti l’header ed il
payload. L’header è l’equivalente di quello che è scritto normalmente fuori di una
normale lettera inviata per posta, quindi conterrà ad esempio il mittente ed il
destinatario, mentre il payload potrebbe essere paragonato al contenuto della lettera.
Occorre osservare che il paragone è estremamente riduttivo, ed inoltre l’header ed il
payload sia TCP che UDP ma anche ICMP verranno spiegati più in dettaglio in seguito,
ma serve comunque in questo momento per dare solo un’idea di cosa stiamo parlando.
Una scelta fondamentale e che influenzerà il lavoro in seguito consiste quindi nel
decidere se includere o meno il payload nelle informazioni che il nostro sistema dovrà
osservare e quindi dalle quali dovrà discriminare il svolgersi o meno di un attacco o di
un’anomalia nel traffico di rete.
70
Occorre ricordare che uno degli obiettivi con cui questo abbiamo iniziato questo
lavoro è introdurre intelligenza artificiale all’interno di un IDS. L’intuizione è che tra
tutte le possibilità che ci vengono offerte dallo studio dell’intelligenza artificiale, nel
nostro particolare caso, possano rivelarsi particolarmente utili quelle tecniche che
permettono una classificazione di un insieme di dati. Questo perché una classificazione
permette di evidenziare che un certo insieme di valori di particolari caratteristiche è
significativamente diverso da un altro insieme in presenza di condizioni o situazioni
distinte. La speranza in questa fase era che queste diverse situazioni potessero
concretizzarsi alcune in anomalie nel traffico di rete ed altre invece in condizioni di
“normalità”. Per questo motivo abbiamo deciso di utilizzare le reti neurali, con
apprendimento non supervisionato che, come anticipato nel capitolo precedente,
permettono una buona classificazione di un insieme di dati. Questa intuizione e
speranza era anche supportata dal fatto che in letteratura si trovano altri lavori basati su
reti neurali ma con la sostanziale differenza che tali lavori si basano su apprendimenti
supervisionati mentre il nostro progetto si concentra su apprendimenti non
supervisionati ed in seguito illustreremo il perché di tale scelta.
Chiusa questa parentesi il problema era quello di decidere se includere o meno il
payload nelle informazioni “sensibili” da tenere in considerazione. Dopo una semplice
visita a qualche sito Web ci si rende subito conto di quanto siano pesantemente
eterogenee le informazioni contenute nel Web. Inoltre il Web come sappiamo offre
moltissimi servizi come portali, posta elettronica, scambio di file attraverso FTP o
applicazioni P2P, servizi di messaggistica immediata come ICQ, streaming audio e
video ecc. Tutti questi servizi producono se andiamo ad osservare il contenuto dei
pacchetti e quindi il payload dati molto diversi tra loro ad eccezione forse della fase di
inizializzazione della connessione che per molti servizi si basa comunque su una
procedura stile Three Way Handshaking, metodo comunemente utilizzato dal protocollo
TCP.
Questo porta ad una intrinseca difficoltà circa l’assegnamento del payload di un
particolare pacchetto ad uno dei possibili servizi o protocolli esistenti e comunemente
utilizzati dagli utenti di Internet. Il compito sarebbe sicuramente più facile se un
ipotetico Intrusion Detection System anomaly based che controlla il contenuto del
payload potesse mantenere una visione d’insieme di quanto sta succedendo nella
comunicazione; cioè prendere nota dell’inizio di una comunicazione, il momento più
71
favorevole per classificare un certo tipo di pacchetto, tracciare i numeri di sequenza
TCP fino ad incontrare un pacchetto FIN o RST, che comunica la volontà da parte di
uno dei due host di chiudere la comunicazione, per terminare quindi il monitoraggio
della connessione.
Questo però introduce i classici problemi di possibilità di elusione dal momento
che l’IDS deve mantenere lo stato della connessione ed inoltre nessuno sarà in grado di
stabilire a priori quanto durerà una connessione e quindi le risorse dell’IDS potrebbero
presto esaurirsi solo per osservare un numero esiguo di collegamenti ma che magari
sono iniziati da un considerevole lasso di tempo.
Inoltre anche all’interno di un particolare servizio possiamo avere delle consistenti
variazioni durante un certo periodo; basti pensare alle pagine Web, la cui maggior parte
è scritta in predominanza con linguaggio HTML.
La pagina Web di un portale o di un’organizzazione infatti viene continuamente
modificata o aggiornata per mettere in risalto una novità, ad esempio un nuovo prodotto
lanciato sul mercato, o solo per un’operazione di restyling in modo da renderla più
gradevole ed accattivante. La homepage del sito Web di una testata giornalistica è un
esempio particolarmente adatto in questo senso, infatti ogni giorno verrà aggiornata con
le ultime notizie giornalistiche.
Mettiamoci a questo punto un momento nell’ottica di una rete neurale che deve
classificare tutte queste informazioni; durante l’addestramento vedrà il contenuto dei
pacchetti che corrispondono al caricamento di una pagina Web in un certo modo ma in
seguito la stessa pagina modificata produrrà durante il proprio caricamento pacchetti
con
contenuto
significativamente
diverso
dal
precedente.
Ammettiamo
che
ipoteticamente una rete neurale fosse riuscita a catalogare in qualche modo un’impronta
del contenuto normale ad esempio dei pacchetti Http (ma con ogni probabilità sarà
formata da un numero elevatissimo di unità neurali con esplosione dei tempi necessari
per l’addestramento e cosa più importante per la classificazione durante le normali
condizioni operative). Di fronte allo scenario precedente in cui la pagina Web è stata
modificata rispetto al passato, non può far altro che segnalare un’anomalia mentre la
situazione è perfettamente nella normalità.
Infine, non dobbiamo tralasciare l’ipotesi che il contenuto dei pacchetti possa
essere criptato ad esempio nel caso in cui vengono utilizzati i protocolli SSL o SSH. In
72
questi casi l’osservazione del contenuto dei pacchetti è nel migliore del casi inutile ma
potrebbe anche generare falsi positivi o peggio falsi negativi.
Dopo aver preso coscienza di tutto ciò abbiamo avuto dei seri dubbi su come si
potesse attraverso una rete neurale non supervisionata a classificare e quindi distinguere
il contenuto di un pacchetto lecito da uno illecito, dal momento che esistono tutte queste
difficoltà solo per classificare diversi tipi di traffico lecito.
Quindi abbiamo preso la decisione di tralasciare il payload dei pacchetti per
concentraci sulle informazioni contenute nell’header, confidando anche nel fatto che il
nostro sistema dovrà affiancare un tradizionale network IDS misuse detection come ad
esempio Snort e di conseguenza sarà proprio quest’ultimo che nel proprio
funzionamento controllerà il contenuto dei pacchetti in transito nella rete. Tale
decisione comunque non pregiudica la possibilità di integrare in futuro un’ ulteriore
controllo sul payload magari come sistema complementare.
4.3 Decodifica dei Pacchetti di Rete
Giunti a questo punto necessitiamo di analizzare i dati di rete. In generale tutte le
utilità che permettono di ottenere una “registrazione” dei dati che passano su una rete
utilizzano un formato di file compatibile, definito nei sistemi Unix nelle librerie di
cattura dei pacchetti libpcap. Queste librerie sono infatti utilizzate anche da Snort,
durante il proprio lavoro, per la cattura dei pacchetti.
In ambiente Windows esiste un port di tali librerie chiamato winpcap, realizzato
dal Politecnico di Torino. Winpcap che in realtà è un driver, è sviluppato in C++ e
distribuito anche con i file sorgente. Esiste inoltre un software gratuito denominato
Ethereal che consente di analizzare in modo completo il traffico di rete, sia catturandolo
che recuperandolo da un dump (cioè una registrazione) salvato in precedenza in formato
libpcap. Ethereal è dotato di utili funzioni di decodifica di protocollo a vari layer, oltre
alla possibilità di filtrare pacchetti e ricostruire comunicazioni TCP. Citiamo questo
applicativo perché è stato molto utile durante le fasi di debug del software sviluppato
per il funzionamento del sistema realizzato.
73
Winpcap si basa su due file DLL: packet.dll e wpcap.dll. La figura 4.2 mostra la
struttura di questo driver ed il ruolo dei due file DLL su cui si basa il suo
funzionamento.
Figura 4.2 Funzionamento del driver winpcap
Abbiamo deciso di utilizzare le librerie winpcap poiché, il dataset utilizzato (che
verrà descritto nel capitolo 5, paragrafo 1), per testare il lavoro da noi proposto è stato
generato utilizzando gli standard definiti nelle librerie libpcap.
Tali librerie ci permettono grazie ad un sistema di buffer di analizzare un
pacchetto alla volta e soprattutto solo quando ne abbiamo veramente bisogno; attraverso
la chiamata di una funzione che restituisce un puntatore ad un’area di memoria
contenente il pacchetto letto dalla scheda di rete. Per decodificare i dati relativi al
pacchetto presenti in memoria dobbiamo far ricorso alle specifiche dei pacchetti dei
protocolli TCP/IP, che sono contenute negli appositi RFC:
Protocollo IPv4: RFC 791;
Protocollo TCP: RFC 793;
Protocollo UDP: RFC 791;
Protocollo ICMP: RFC 792.
74
Per comodità di riferimento riportiamo una descrizione ed uno schema degli
header dei protocolli IP, TCP, UDP e ICMP.
4.3.1 IP Protocol Header
Figura 4.3 Header IP
Riportiamo di seguito la descrizione dei campi presenti nell’header IP mostrato in
figura 4.3:
Version: la versione del protocollo in uso. Attualmente si usa IPv4, anche se già
esiste la versione 6;
IHL: IP Header Length, la lunghezza dell’header IP, espressa in multipli di 32
bit;
Type-of-service(TOS): ai bit di questo byte sono associati valori che consentono
di gestire priorità differenziate o di richiedere determinate qualità di servizio per
i pacchetti in transito. In generale queste richieste vengono onorate solo sulle reti
interne, difficilmente sull’Internet globale.
Total length: lunghezza totale del datagramma in ottetti (byte), incluso l’header;
Identification: un valore univoco di 16 bit assegnato dal mittente;
75
Campo Flags: comprendente i bit DF (Don't Fragment) e MF (More Fragments),
che rispettivamente indicano che il pacchetto non può essere frammentato o che
il pacchetto non è l’ultimo di una serie di frammenti;
Fragment Offset: spiazzamento (in multipli di 64 bit) rispetto al datagramma
iniziale;
Time to Live: indicazione del numero di hop (apparecchiature di rete
attraversate) che sono concesse al pacchetto per raggiungere la destinazione
Quando questo valore arriva a zero il datagramma è scartato. Di solito è
inizializzato a 32 o 64 (a valori minori nei vecchi sistemi), mentre il protocollo
di controllo ICMP usa anche il valore massimo 255. Lo scopo è quello di
eliminare eventuali pacchetti che stiano rimbalzando in un loop;
Protocol: indica il protocollo di livello superiore che sta venendo trasportato da
IP. Per ICMP questo valore è 1, per TCP è 6, per UDP 17;
Checksum: una checksum di 16 bit del solo header. Dato che alcuni campi
cambiano ad ogni hop (ad esempio TTL) questo campo è ricalcolato da ogni
router;
Source Address: è l’indirizzo IP del mittente del pacchetto;
Destination Address: è l’indirizzo IP del destinatario del pacchetto;
Options: il campo Opzioni ha lunghezza variabile (può addirittura mancare) e
contiene le seguenti opzioni:
Sicurezza: il datagramma può essere classificato secondo vari livelli
conformemente agli standard militari;
Source Routing: il datagramma contiene un elenco di indirizzi IP che devono
essere seguiti per arrivare a destinazione. In questa modalità il mittente
impone l'instradamento;
Record Route: usata per registrare il percorso seguito dal datagramma;
Timestamp: usata dai vari router attraversati per registrare l'ora di
attraversamento.
76
4.3.2 TCP Protocol Header
Figura 4.4 Header TCP
Riportiamo di seguito la descrizione dei campi presenti nell’header TCP mostrato
in figura 4.4:
Source Port: è un valore di 2 byte che identifica il processo mittente;
Destination Port: un valore di 2 byte che identifica il processo destinatario;
Sequence Number: è il numero sequenziale del primo byte di dati trasportato da
questo segmento. Fa eccezione il caso del segmento di sincronizzazione (byte
SYN posto a 1), in tal caso il numero è l’Initial Sequence Number (ISN) e il
primo byte trasmesso ha numero ISN+1;
Acknowledgment Number: numero del prossimo Sequence Number che il
mittente del segmento si aspetta di ricevere;
Data Offset: Campo di quattro bit che contiene il numero di parole da 32 bit che
costituiscono l’header. Serve a individuare dove cominciano i dati;
Flags: sono sei bit che rappresentano altrettante flag che consentono ai segmenti
di trasportare oltre ai dati anche informazioni di controllo. Il loro significato è:
77
1. URG: indica che il campo Urgent Pointer ha significato;
2. ACK: indica che il campo Acknowledgment Number ha significato;
3. PSH: Serve a realizzare la funzione di Push;
4. RST: Reinizializza (Reset) la connessione;
5. SYN: Serve a sincronizzare i numeri di sequenza;
6. FIN: Il mittente non ha più dati da mandare.
Window: è il numero di byte che si è pronti a ricevere;
Checksum: la checksum è calcolata premettendo all’header TCP uno
pseudoheader composto da 3 campi da 32 bit ricavati dall’header IP: 32 bit
dell’indirizzo sorgente, 32 bit dell’indirizzo destinazione, 8 bit di zeri, 8 bit del
campo protocollo, e 16 bit del campo TCP length, che è uguale alla TCP header
length più la data length, espressa in ottetti. Si calcola quindi il checksum, come
complemento a uno della somma dei complementi a uno di pseudo-header,
header e dati, presi a blocchi di 16 bit, eventualmente aggiungendo zeri in fondo
(padding). Per il calcolo incrementale dell’header si ricorre alle specifiche
dell’RFC 1624 (che aggiorna l’RFC1141, che a sua volta aggiorna l’RFC 1071
che non è uno standard ma una implementazione suggerita);
Urgent Pointer: sommato al Sequence Number punta al primo byte non urgente
tra quelli del segmento dati;
Options: l’unica opzione prevista dallo standard originale è un campo chiamato
MSS (Maximum Segment Size) che indica la massima lunghezza del segmento
che il destinatario accetta; questo campo può essere usato solo all’inizio della
connessione (nei segmenti SYN). In seguito sono state definite altre opzioni.
78
4.3.3 UDP Protocol Header
Figura 4.5 Header UDP
Riportiamo di seguito la descrizione dei campi presenti nell’header UDP mostrato
in figura 4.5:
Source Port: è un valore di 2 byte che identifica il processo mittente;
Destination Port: un valore di 2 byte che identifica il processo destinatario;
Length: lunghezza totale del messaggio UDP sia dei dati che dell'intestazione;
Checksum: questo valore è opzionale e, al contrario di quello che succedeva con
il checksum nel datagramma TCP, esso non è relativo solo all'intestazione ma a
tutto il datagramma, compresa la parte dati.
4.3.4 ICMP Protocol Header
Figura 4.6 Header ICMP
79
Riportiamo di seguito la descrizione dei campi presenti nell’header ICMP mostrato in
figura 4.6:
Type: identifica il tipo di informazione che il protocollo ICMP sta trasmettendo.
Solitamente contiene uno dei seguenti valori:
0
Echo Reply;
3
Destination Unreachable;
4
Source Quench;
5
Redirect;
8
Echo;
11 Time Exceeded;
12 Parameter Problem;
13 Timestamp Request;
14 Timestamp Reply;
15 Information Request;
16 Information Reply;
Code: identifica un particolare messaggio relativo alla classe di informazioni
specificata nel campo Type;
Checksum: campo di controllo dell’integrità del messaggio ICMP.
4.4 Algoritmo Statistico
Nel passo successivo abbiamo dovuto affrontare le problematiche riguardanti
come organizzare le informazioni estratte dai pacchetti di rete con l’ottica di permettere
alla rete neurale di classificare tali informazioni nel modo più corretto possibile.
L’obiettivo in questo caso è quello di catturare una correlazione temporale o
statistica che un flusso di pacchetti può avere. In questo modo possiamo riconoscere
eventi come “un aumento strano del flusso di richieste verso una particolare porta”,
oppure “una distribuzione anomala del flusso di pacchetti rispetto al normale”, o ancora
“una serie di pacchetti destinati a porte diverse sullo stesso host, provenienti dalla stessa
porta dello stesso host remoto”.
80
L’idea è quindi di sviluppare un algoritmo su base statistica per mettere in
evidenza queste correlazioni temporali e statistiche, con lo scopo di ottenere un risultato
che ci permetta di distinguere un “andamento temporale” relativo ad un traffico
“normale” da uno relativo ad un possibile attacco e quindi ad un’anomalia di rete.
Stiamo quindi tentando di sviluppare una sorta di “discriminatore” la cui uscita
deve consentirci per il momento con una semplice ispezione visiva di distinguere un
andamento temporale “normale” da uno anomalo. Successivamente, una volta verificato
il funzionamento di questo approccio statistico, possiamo introdurre le reti neurali come
sorta di “motore di decisione”, fornendo come ingresso da classificare l’uscita restituita
dal “discriminatore” basato sull’algoritmo statistico.
La successiva introduzione delle reti neurali pone un vincolo importante nel
progetto del sistema statistico. La dimensione dell’ingresso di una rete neurale, infatti,
non può essere variabile e deve essere fissato in fase di progetto. Occorre quindi rendere
l’uscita dell’algoritmo statistico indipendente dal flusso di traffico istantaneo dell’host
osservato; l’uscita non deve quindi dipendere, ad esempio, dal numero di pacchetti
catturati.
Passiamo a questo punto alla descrizione dell’algoritmo statistico ed alla sua
implementazione.
4.4.1 Descrizione
Per prima cosa prendiamo in considerazione una finestra temporale di 60 secondi
durante la quale acquisiamo i pacchetti in transito nel cavo di rete grazie ad una scheda
di rete posta in modalità promiscua ed alle librerie winpcap che ci permettono di
catturare i pacchetti ai più bassi livelli della struttura ISO/OSI.
Durante questa osservazione filtriamo, basandoci sull’indirizzo IP, solo il traffico
in ingresso ed in uscita dal server a cui siamo interessati e che quindi vogliamo
monitorare.
Per ogni pacchetto così filtrato memorizziamo l’indirizzo IP mittente nel caso di
pacchetti in ingresso o l’indirizzo IP del computer destinatario in caso di pacchetti in
uscita. Questa operazione viene effettuata per il protocollo TCP, UDP e ICMP.
Per i primi due cioè TCP e UDP occorre prendere in considerazione anche il
numero di porta che troviamo all’interno dei pacchetti, mentre per il protocollo ICMP
81
non esiste l’informazione sulle porte di comunicazione (come evidenziato in precedenza
riguardo l’header ICMP) e quindi in questo caso ci concentriamo solo sull’indirizzo IP.
Le porte utilizzate nelle comunicazioni attraverso Internet possono assumere
valori da 0 a 65535 ed inoltre le porte che assumono valori all’interno dell’intervallo da
0 a 1024 sono chiamate privilegiate perché associate ad un particolare tipo di traffico e
quindi ad un particolare protocollo; la porta 80 è associata ad esempio al traffico Http,
la porta 21 al traffico FTP, la porta 23 al traffico Telnet ed infine la porta 25 al
protocollo SMTP. Attenzione, però, tutto questo è vero in linea di massima infatti niente
impedisce di utilizzare una certa porta per scopi diversi da quelli usuali; di conseguenza
non bisogna utilizzare le porte, ad esempio, come indicatore di classificazione in quanto
daremmo per scontato che ogni singola porta stia, effettivamente, venendo usata per il
tipo di protocollo che usualmente la sfrutta.
Analizzare anche la porta di comunicazione ha come conseguenza la necessità di
fare una scelta; per ogni pacchetto, infatti, abbiamo a disposizione due possibili
informazioni che riguardano le porte di comunicazione: la porta sorgente e la porta di
destinazione. Questo accade ovviamente sia per i pacchetti in ingresso sia per quelli in
uscita.
La prima intuizione che ci potrebbe venir in mente è quella di comportarci come
con gli indirizzi IP; cioè soffermarsi sulla porta di origine nei pacchetti in ingresso e
sulla porta di destinazione nei pacchetti in uscita. Questo metodo però non si rileva
corretto se pensiamo che le comunicazioni su Internet, come del resto in qualsiasi altro
ambito, sono nella quasi totalità dei casi conformi ad uno schema client-server.
Quando un host client inizia una comunicazione verso un altro, che in questo caso
funge da server, presenta come indirizzo IP mittente il proprio e come porta sorgente la
porta associata al processo che ha richiesto la comunicazione. Il server dopo aver
elaborato la domanda del client dovrà rispedire la risposta, ed ovviamente utilizzerà
come IP e porta di destinazione i valori IP e porta sorgente presenti nel pacchetto che
conteneva la domanda, ricevuto in precedenza.
L’intuizione di comportarsi con le porte come con gli indirizzi IP è quindi errata,
in quanto porterebbe un’identica informazione ridondante osservando i pacchetti in
ingresso ed in uscita di una stessa connessione.
Abbiamo fatto quindi la scelta di prendere in considerazione sia per i pacchetti in
ingresso che per quelli in uscita la porta sorgente.
82
Cerchiamo di spiegare il perché con le seguenti figure. Per prima cosa
analizziamo la situazione in cui un host richiede un servizio Http (porta 80) al server
che stiamo monitorando:
Figura 4.7 Schema di una connessione in cui l'host monitorato svolge il ruolo di server
Nel pacchetto diretto dal client al server, quindi in ingresso al server, la porta
sorgente è 32686; questa è stata assegnata dal sistema operativo al processo che ha
generato la richiesta in tal caso un browser Web. Il nostro server risponderà dalla porta
80 (HTTP) verso la porta 32686 dell’host mittente. In questo caso il nostro sistema
prenderà in considerazione le seguenti informazioni:
Pacchetto in Ingresso : IP mittente e Porta sorgente cioè 80.121.30.48 e 32686;
Pacchetto in Uscita : IP di destinazione e Porta sorgente cioè 80.121.30.48 e 80.
Abbiamo quindi in qualche modo memorizzato nelle informazioni raccolte per il
pacchetto in uscita, il tipo di richiesta effettuata del client; cioè se teniamo presente che,
ad ogni servizio è possibile associare una particolare porta, allora sappiamo il tipo di
servizio richiesto dal client, in questo caso Http (porta 80).
Vediamo a questo punto il caso inverso; cioè il nostro server monitorato, magari
per rispondere ad una particolare richiesta, deve domandare delle determinate
informazioni ad un terzo host. In questo caso il computer da noi osservato si trasforma
nell’host che richiede un particolare servizio mentre il terzo host funge da server.
83
Figura 4.8 Schema di una connessione in cui l'host monitorato svolge il ruolo di client
Nella figura l’host monitorato esegue una richiesta DNS (porta 53) al server DNS
della propria sottorete. Le informazioni memorizzate dal sistema, ricordando che in
questa configurazione il pacchetto in uscita è quello rappresentato dalla freccia in alto
diretta verso destra e quindi il pacchetto in ingresso è rappresentato dall’altra, saranno:
Pacchetto in Ingresso : IP mittente e Porta sorgente cioè 81.5.3.0 e 53;
Pacchetto in Uscita : IP di destinazione e Porta sorgente cioè 81.5.3.0 e 24168.
In questo modo abbiamo memorizzato, nell’informazione relativa al pacchetto in
ingresso un’indicazione sul tipo di servizio richiesto dall’host monitorato: la query
DNS.
Riprendiamo ora la descrizione dell’algoritmo statistico. Durante la finestra
temporale di 60 secondi annotiamo tutte le informazioni illustrate finora; come gli
indirizzi IP sorgente e le porte sorgenti di tutti i pacchetti in ingresso all’host monitorato
e analogamente gli indirizzi IP di destinazione e le porte sorgenti di tutti i pacchetti in
uscita.
Al termine della finestra vengono generati, con i dati raccolti, tre diversi grafici
sia per le comunicazioni viste in ingresso che per quelle viste in uscita per un totale
quindi di sei grafici ogni 60 secondi. Il primo dei tre grafici, avrà nell’asse delle ascisse
i diversi valori associati ai vari indirizzi IP osservati (questo sarà denominato grafico
IP), il secondo le coppie di valori IP : Porta (denominato grafico IP : Porta) ed infine il
terzo solo i diversi valori delle porte (denominato grafico Porta).
Tutti i grafici hanno nell’asse delle ordinate la cardinalità associata ad ogni valore
presente nell’asse delle ascisse di ciascun grafico. Tale cardinalità viene calcolata
tenendo presente le informazioni osservate durante la finestra temporale.
84
Insieme ai tre grafici vengono anche calcolati e memorizzati altri due valori: il
totale dei pacchetti osservati sia in ingresso che in uscita.
A titolo di esempio, di seguito sono riportati degli esempi relativi alle sole
connessioni in uscita dei grafici generati dal sistema statistico, per una particolare
finestra temporale di 60 secondi.
Figura 4.9 Grafico degli indirizzi IP di destinazione contenuti nei pacchetti in uscita e osservati
all’interno di una finestra temporale di 60 secondi
85
Figura 4.10 Grafico delle coppie IP di destinazione e porta sorgente contenute nei pacchetti in uscita e
osservate all’interno di una finestra temporale di 60 secondi
Figura 4.11 Grafico delle porte di destinazione contenute nei pacchetti in uscita e osservate all’interno di
una finestra temporale di 60 secondi
Per quanto riguarda il numero di pacchetti, abbiamo in uscita un totale di 521
pacchetti osservati.
86
Per comodità d’ora in avanti chiameremo le finestre temporali da 60 secondi,
istanti.
Il sistema per catturare una possibile correlazione temporale e statistica elaborerà
5 istanti successivi, quindi 5 minuti. In questo modo vogliamo poter rilevare anomalie
nel flusso dei pacchetti di rete nel tempo, senza però osservare intervalli temporali
troppo lunghi che potrebbero far perdere facilmente variazioni limitate ad un ristretto
periodo di funzionamento del server monitorato. In altre parole osservare il traffico, ad
esempio, per 30 o 60 minuti con molta probabilità significa mascherare, in un sistema
per sua natura “statistico”, delle variazioni significative del comportamento dell’host
preso in considerazione che si sono verificate solo per due o tre minuti.
Questo comportamento potrebbe venir sfruttato da un aggressore, che ormai ha
preso il controllo del server monitorato, per sfruttare indisturbato il sistema. Basterebbe
infatti far eseguire all’host compromesso il carico di lavoro “anomalo” per un ristretto
intervallo di tempo senza che un sistema di rilevamento basato sulla statistica, che
osserva ,finestre temporali troppo ampie se ne accorga.
Il primo istante, dei 5 presi in considerazione, viene ordinato sulla base
dell’occorrenza secondo un ordinamento decrescente, ottenendo quindi dei grafici con
andamento decrescente. Questa scelta è stata fatta col fine di avere una base comune da
cui partire per rilevare poi delle possibili variazioni nel traffico contenuto negli altri 4
istanti successivi. Nessuno, infatti, poteva immaginare a priori che forma avessero avuto
i grafici ottenuti, per avere quindi una sorta di “normalizzazione” iniziale abbiamo
deciso di effettuare questo riordinamento dei grafici derivanti dall’osservazione dei dati
grezzi di rete.
Dopo aver eseguito l’ordinamento, gli assi delle ascisse dei grafici visti in
precedenza vengono bloccati ed inoltre le informazioni ricavate dai 4 istanti temporali
successivi vengono aggiunte ai grafici così ottenuti.
Cioè se viene rilevato, ad esempio, un pacchetto proveniente da un indirizzo IP
già osservato in un istante precedente, dei 5 presi in considerazione, l’occorrenza
relativa a tale indirizzo IP viene aggiornata nel grafico finora costruito. Se diversamente
si presenta un pacchetto proveniente da un indirizzo IP finora sconosciuto, questo valore
con la relativa occorrenza viene aggiunto in coda all’asse delle ascisse bloccato dopo
aver eseguito l’ordinamento decrescente del grafico relativo al primo istante.
87
La metodologia ora descritta si applica per le informazioni che andranno a
costituire, ad esempio il grafico riguardante il solo indirizzo IP e per le connessioni in
ingresso all’host monitorato, ma le stesse considerazioni vengono applicate anche agli
altri due grafici, quelli riguardanti solo la porta e la coppia IP : Porta ed inoltre per tutti i
grafici relativi alle connessioni in uscita.
Ricordando che solo il primo istante, e quindi il primo grafico, viene ordinato e
che gli altri 4 grafici vengono costruiti di conseguenza riportiamo come esempio 5
grafici relativi ai valori IP : Porta di 5 istanti temporali da 60 secondi consecutive
costruiti a partire dai pacchetti osservati in ingresso ad un particolare server di rete.
Figura 4.12 Grafico IP:Porta non ordinato relativo ai pacchetti in ingresso osservati nel primo istante da
60 secondi
Il grafico in figura 4.12 rappresenta i dati grezzi catturati dalla rete nel primo da
60 secondi ed inoltre non è stato ancora ordinato.
88
Figura 4.13 Stesso grafico della figura 4.12 ma ordinato secondo un andamento decrescente
Il grafico in figura 4.13 è relativo allo stesso istante temporale precedente, ossia
agli stessi 60 secondi del grafico in figura 4.12, ma è ordinato in modo decrescente.
Figura 4.14 Grafico relativo al secondo istante da 60 secondi, costruito a partite dal grafico di figura 4.13
89
Quello in figura 4.14 riporta invece i dati relativi al secondo istante e possiamo
osservare che è stato costruito a partire dal grafico precedente con l’asse delle ascisse
bloccato. Infatti la coppia IP : Porta, 172.16.114.207:12294 non erano presenti
nell’istante precedente e pur avendo un’elevata occorrenza sono stati aggiunti in coda
all’asse X.
Figura 4.15 Grafico relativo al terzo istante da 60 secondi, costruito a partite dal grafico di figura 4.14
La figura 4.15 mostra, il grafico relativo al terzo istante. Possiamo notare in coda
all’asse X una nuova coppia IP : Porta osservata cioè 172.16.112.100:25, inoltre
notiamo che si sono presentati nuovi pacchetti provenienti dall’indirizzo IP
172.16.114.50, porta 8860, infatti il valore dell’elemento 172.16.114.50:8860 è stato
aggiornato alla nuova occorrenza 236 rispetto al valore 40 assunto all’istante
precedente.
90
Figura 4.16 Grafico relativo al quarto istante da 60 secondi, costruito a partite dal grafico di figura 4.15
La figura 4.16 rappresenta il grafico relativo al quarto istante; l’ultimo elemento
cioè l’IP 172.16.113.204 è associato al valore -1 per quanto riguarda la porta sorgente.
Questo non è un errore, è dovuto solamente al fatto che il pacchetto in questione
appartiene al protocollo ICMP che non prevede informazioni relative alla porte di
origine e destinazione.
91
Figura 4.17 Grafico relativo al quinto ed ultimo istante da 60 secondi, costruito a partite dal grafico di
figura 4.16
Infine la figura 4.17 riporta il grafico relativo al quinto istante.
In aggiunta a tutti i grafici fin qui descritti, il sistema per ogni finestra di 5 istanti
ne costruisce altri 2 relativi al numero di pacchetti osservati in ingresso ed in uscita
dall’host preso in considerazione (denominati grafici NPkt).
Abbiamo a questo punto cercato una grandezza che potesse caratterizzare in
qualche modo l’andamento di queste curve. L’obiettivo era quello di poter cogliere una
significativa variazione delle curve osservando il valore di tale grandezza, con la
speranza che un flusso di traffico “normale” avrebbe prodotto un valore oscillante in un
certo intervallo limitato.
Valori fuori di tale intervallo significano di conseguenza un’anomalia occorsa
durante i 5 istanti di osservazione e quindi durante gli ultimi 5 minuti trascorsi. La
scelta è ricaduta sull’utilizzo del momento primo, secondo, terzo e varianza.
Dal momento che stiamo parlando di quantità discrete il calcolo di queste
grandezze si riduce ad una sommatoria.
∑ x ⋅ f (x )
m1 =
∑ f (x )
i
Momento del primo ordine:
i
i
i
i
92
(4.1)
∑ x ⋅ f (x )
m2 =
∑ f (x )
(4.2)
∑ x ⋅ f (x )
m3 =
∑ f (x )
(4.3)
σ = m2 − m12
(4.4)
2
i
Momento del secondo ordine:
i
i
i
i
3
i
Momento del terzo ordine:
i
i
i
i
Varianza:
2
Dove xi rappresenta l’elemento i-esimo dell’asse delle ascisse mentre f ( xi )
rappresenta il corrispondente valore di xi sull’asse delle ordinate.
I valori presenti negli assi delle ascisse ( xi ) dei vari grafici, essendo di tipo
alfanumerico, sono stati semplicemente convertiti nella sequenza di numeri interi: 1, 2,
3, 4, 5, 6, ecc. Al primo valore alla sinistra viene assegnato il valore 1, al secondo il
valore 2, e così via. Occorre ricordare che la posizione dei valori sull’asse X vengono
determinati dall’ordinamento decrescente delle occorrenze relative al primo istante della
finestra.
Per ognuno dei 5 grafici visti in precedenza vengono calcolati i valori di queste
grandezze, ma non dobbiamo dimenticarci che contemporaneamente occorre eseguire lo
stesso calcolo anche per i grafici relativi al solo indirizzo IP ed al solo valore della porta
sorgente, naturalmente per i pacchetti sia in ingresso che in uscita.
Per ottenere infine un solo valore caratteristico dei 5 istanti di osservazione i
valori dei momenti e della varianza vengono mediati sulle 5 finestre.
Per quanto riguarda invece l’informazione sul numero di pacchetti osservati in
ciascun istante non vengono eseguiti i calcoli relativi ai momenti primi ed alla varianza,
ma vengono solo memorizzati i valori per costruire i due grafici NPkt; uno relativo ai
pacchetti in ingresso ed uno in uscita. Considerando 5 istanti per entrambe le direzioni
di comunicazione abbiamo un totale di dieci valori memorizzati che riguardano il
numero di pacchetti osservati. Anche in questo caso per ottenere un solo valore
caratteristico dei cinque istanti di osservazione i numeri relativi ai pacchetti osservati e
memorizzati in precedenza vengono mediati sulle cinque finestre ottenendo due valori;
uno come al solito per le connessioni in ingresso ed uno per quelle in uscita.
Occorre precisare che il valore del momento secondo, terzo e della varianza sono
stati calcolati, perché a priori non era possibile stabilire se siano stati significativi o
93
meno, ma dopo aver prestato attenzione ad alcuni risultati ci siamo subito resi conto che
non apportavano significative informazioni utili. Infatti tali valori corrispondono a
quelli relativi al solo momento primo con la differenza che sembrano moltiplicati per
una costante abbastanza elevata, di conseguenza l’effetto è quello di esasperare il gap
presente tra l’andamento “normale” ed l’anomalia che si discosta maggiormente da
quest’ultimo. Anche se a prima vista questo comportamento può sembrare interessante
sotto il punto di vista della discriminazione fra traffico “normale” ed anomalie ha come
effetto negativo quello di far emergere solo l’anomalia più evidente e di mascherare
quindi tutte le altre confondendole con i valori relativi ad una condizione di
“normalità”.
Per queste ragioni utilizzeremo come discriminante il solo valore del momento
primo, fermo restando che in un ulteriore sviluppo è possibile introdurre anche l’analisi
relativa agli altri momenti ed alla varianza. Il programma che implementa questo
sistema statistico, infatti, calcola e gestisce tutti i momenti citati in precedenza, in modo
da non dover rivedere il codice se un domani occorre prendere in analisi anche gli altri
valori.
Abbiamo finora preso in considerazione solo 5 istanti ma noi dobbiamo analizzare
un flusso continuo di traffico e quindi una successione di istanti. Per gestire un flusso
continuo di dati il sistema statistico utilizza una finestra scorrevole di 5 istanti. Ogni
finestra di 5 istanti viene elaborata secondo le modalità viste precedentemente, cioè
ordinando il grafico relativo al primo istante e costruendo i grafici successivi sulla base
del primo.
Per spiegare meglio consideriamo la seguente successione di istanti:
Istante 1, Istante2, Istante3, Istante 4, Istante 5, Istante 6, Istante 7, ecc.
La prima finestra comprenderà gli istanti : 1,2,3,4,5. Tutti i grafici relativi
all’istante 1 vengono ordinati secondo l’ordinamento decrescente ed i seguenti 2,3,4,5
vengono elaborati partendo dal risultato ottenuto col primo istante. Come risultato finale
si ottengono i valori dei momenti primi mediati sui 5 istanti presi in considerazione,
nonché il valore, sempre mediato, relativo al numero di pacchetti osservati nei
medesimi cinque istanti.
94
Riassumendo i valori calcolati saranno in tutto 8, 4 relativi alle connessioni in
ingresso e 4 relativi a quelle in uscita. Dei 4 valori, 3 rappresentano i momenti primi
riferiti al grafico IP, grafico IP : Porta, grafico Porta ed 1, il numero di pacchetti
osservati.
Contemporaneamente una seconda finestra prenderà in considerazione gli istanti
2,3,4,5,6. Questa finestra verrà elaborata come la precedente ordinando quindi l’istante
2 ed elaborando gli altri sulla base delle informazioni dell’istante 2 stesso. Occorre
notare che le due finestre (rispettivamente istanti 1,2,3,4,5 ed istanti 2,3,4,5,6) vengono
trattate contemporaneamente ma separatamente ad esempio l’ordinamento dell’istante 2
nella seconda finestra non modifica l’elaborazione dell’istante 2 nella prima finestra che
dipende dal risultato ottenuto con l’ordinamento dell’istante 1 della stessa finestra.
Sempre contemporaneamente verrà presa in considerazione un’altra finestra da 5
istanti e precisamente gli istanti 3,4,5,6,7.
Ricapitolando:
Istanti 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,ecc.
1÷5
2÷6
3÷7
4÷8
5÷9
6 ÷ 10
7 ÷ 11
…….. e così via.
1a finestra con riordinati i dati relativi all’istante 1
Il risultato di questo sistema è fornito in due file di testo, uno relativo alle
connessioni in ingresso ed un relativo a quelle in uscita dal server monitorato, che
verranno successivamente elaborati dal sistema di reti neurali.
Un file di testo di uscita è ad esempio mostrato nella figura seguente:
95
Figura 4.18 File di testo di uscita relativo ai pacchetti in ingresso al server monitorato
Ogni riga di questo file rappresenta una finestra di 5 istanti ed è memorizzata è nel
formato:
campo1, campo2, campo3, campo4, campo5
Il campo1 rappresenta gli istanti di cui è composta la finestra (estremi compresi),
il campo2 invece è il valore del momento primo mediato sui 5 istanti della finestra del
valore relativo ai grafici IP : Porta, il campo3 si basa sui grafici che comprendono la
sola informazione sulle porte sorgente, il campo4 è relativo ai grafici IP ed infine il
campo5 è il valore mediato del numero di pacchetti osservato nei 5 istanti definiti nel
campo1.
Come ultima osservazione, spendiamo due parole sulle scelte effettuate per
quanto riguarda la durata della finestra temporale iniziale, cioè 60 secondi, e per
96
l’ampiezza della seconda finestra temporale che invece prende in considerazione 5
istanti consecutivi.
Abbiamo provato inizialmente con questi due valori e osservando la qualità dei
risultati forniti dal sistema in questa configurazione si è deciso di adottarli
definitivamente. Prima però, abbiamo fatto una verifica con altri valori dei parametri
per verificare che il funzionamento con quei particolari valori da noi testati, non fosse
solo un caso fortunato. Abbiamo, quindi, testato il funzionamento del sistema con altri
valori dei parametri ottenendo dei risultati abbastanza conformi ai predenti. Di
conseguenza la scelta è ricaduta sui valori iniziali dei parametri cioè, 60 secondi per la
durata della finestra temporale di osservazione del traffico di rete e 5 istanti consecutivi
da prendere in considerazione per l’ampiezza della finestra scorrevole.
Questo metodo di scelta dei valori dei parametri è del tutto “empirico” perciò non
escludiamo la possibilità che con altri insiemi di valori da noi non testati le prestazioni
del sistema possano migliorare o peggiorare. Comunque quello che mi preme
sottolineare è che, come descritto finora, la scelta non è stata effettuata “ad hoc” per il
funzionamento sul particolare set di dati da utilizzato.
Sicuramente questi parametri sono strettamente legati alla particolare struttura di
rete dove il sistema dovrà lavorare, quindi la taratura finale dei parametri andrebbe
eseguita tenendo conto del particolare ambito di lavoro del sistema. Per questo motivo
abbiamo fatto in modo che la scelta effettuata ora non sia vincolante in futuro.
È possibile, infatti, modificare il valore dei parametri molto facilmente in quanto
vengono letti dal sistema in un file di configurazione in formato testo, questo permette
di variarli senza dover ristrutturare il codice sorgente del programma.
4.4.2 Implementazione
Il sistema statistico descritto nel capitolo precedente è stato implementato in un
programma scritto in Visual C++, utilizzando le librerie winpcap per la cattura al livello
più basso della struttura ISO/OSI dei pacchetti dall’interfaccia di rete.
Le finestre temporali di 60 secondi sono state determinate in base
all’informazione contenuta nel timestamp dei vari pacchetti osservati. Questa scelta è
stata obbligata, in quanto per gli esperimenti utilizzeremo una registrazione del traffico
di rete creata appositamente per scopi di benchmark e sperimentazione su sistemi di
97
intrusion detection (vedi capitolo 5 paragrafo 1 per una descrizione approfondita del
dataset utilizzato).
Un intervallo temporale dove essere quindi determinato rispetti agli istanti in cui
si è svolta la registrazione. L’unico modo per determinare quanti pacchetti sono
transitati sul filo di rete nel momento in cui si è stata effettuata la simulazione per
generare il dataset che utilizzeremo, è quello di basarsi sul timestamp dei pacchetti
salvati.
Occorre ricordare però che il timestamp di un pacchetto viene determinato
dall’orologio di sistema del computer che lo invia. In questo modo potremmo avere
delle informazioni inconsistenti siccome nessuno è obbligato a mantenere l’orologio del
proprio computer sincronizzato con gli altri, o semplicemente a causa dei diversi fusi
orari. In altre parole potrebbe arrivare un pacchetto con timestamp che riporta un certo
orario ad esempio 10:15, il pacchetto successivo riporta invece le 10:13, il seguente
ancora le 10:16 e così via. Quando in realtà tutti questi pacchetti sono stati osservati
nell’arco temporale di pochi secondi.
Il problema nel nostro caso particolare non si pone, in quanto il sistema utilizzato
per le registrazioni di rete è stato costruito appositamente per questo scopo, quindi tutti i
computer della simulazione sono sincronizzati con un orario unico.
Però nel momento in cui vogliamo fare un esperimento “on-line” e non “off-line”,
occorre tenere presente che la durata delle finestre temporali và determinata in base
all’orologio dell’host in cui è installato il nostro sistema di rilevamento delle anomalie e
non in base al timestamp dei pacchetti osservati, in questo modo ci mettiamo al riparo
da possibili problemi di incongruenza dei dati.
Il programma nel suo funzionamento utilizza in memoria una struttura basata su
una doppia lista puntata per rendere tale struttura più possibile elastica e dinamica in
modo da potersi adattare ai cambiamenti operativi.
Occorre, infatti, permettere al programma di adattarsi a possibili modifiche dei
parametri di funzionamento, come la durata della finestra temporale di osservazione e
l’ampiezza della finestra scorrevole. In secondo luogo non è possibile sapere a priori la
mole di traffico che il sistema osserverà durante il proprio funzionamento e quindi la
quantità di pacchetti che dovrà analizzare e memorizzare.
La figura 4.19 che segue mostra la struttura a doppia lista puntata utilizzata:
98
Figura 4.19 Struttura a doppia lista puntata implementata per il sistema statistico
La lista orizzontale, cioè quella formata dalla struttura A, viene utilizzata per
mantenere in memoria le informazioni relative alle varie finestre scorrevoli. Ogni
elemento della lista orizzontale rappresenta una particolare finestra scorrevole formata
da 5 istanti. Gli elementi nelle lista orizzontale saranno 5 infatti ogni finestra viene
elaborata indipendentemente dalle altre, tenendo conto dell’ordinamento decrescente del
primo istante della finestra in questione per poi elaborare gli istanti successivi.
Riprendiamo un momento il diagramma utilizzato per la spiegazione nel paragrafo
precedente:
Istanti 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,ecc.
1÷5
2÷6
3÷7
4÷8
5÷9
6 ÷ 10
7 ÷ 11
…….. e così via.
La prima finestra, relativa agli istanti 1,2,3,4,5 sarà memorizzata nel primo
elemento della lista orizzontale, la seconda finestra nel secondo elemento della lista fino
99
ad arrivare alla finestra numero 5 che verrà memorizzata nell’elemento numero 5. A
questo punto l’elaborazione della prima finestra è terminata in quanto, composta da 5
istanti successivi, quindi dopo aver salvato i risultati nei file di testo è possibile
rimuovere la finestra dalla lista.
In questo modo abbiamo liberato la prima posizione della lista orizzontale che
verrà occupata dalla finestra immediatamente successiva cioè la numero 6 relativa agli
istanti 6,7,8,9,10.
La struttura A è formata quindi dai seguenti campi:
Indicatore del primo istante della finestra, questo istante è quello che viene
ordinato in modo decrescente e che quindi influenzerà l’elaborazione di tutti gli
altri istanti della finestra stessa;
Puntatore alla struttura B;
Puntatore alla struttura C;
Puntatore alla struttura D;
Puntatore alla struttura E;
Puntatore alla struttura F;
Puntatore alla struttura A, cioè al prossimo elemento della lista orizzontale.
Le strutture B, C, D, costituiscono alcune delle liste verticali e contengono le
informazioni per generare i grafici visti nel paragrafo precedente. Ogni elemento della
struttura B, ad esempio, corrisponde ad un elemento del grafico IP : Porta, conterrà
quindi l’informazione relativa alla specifica coppia IP : Porta ed all’occorrenza
osservata nelle varie finestre temporali da 60 secondi. In altre parole un elemento della
struttura B contiene un valore dell’asse X ed il corrispondente valore dell’asse Y
appartenenti al grafico IP : Porta.
La struttura C contiene le analoghe informazioni ma per il grafico relativo alla
sola porta sorgente mentre infine la struttura D contiene gli stessi dati per quanto
riguarda il grafico IP.
La struttura B è quindi formata dai seguenti campi:
100
IP osservato nelle finestre temporali da 60 secondi;
Porta relativa all’IP contenuto nel campo precedente;
Valore dell’occorrenza della coppia IP : Porta dei due campi precedenti, ossia il
valore dell’asse Y;
Numero di corrispondenza tra l’indirizzo IP ed il valore utilizzato per il calcolo
dei valori dei momenti statistici della curva, ossia il valore dell’asse X;
Puntatore alla struttura B, cioè al prossimo elemento della lista verticale di tipo
B.
La struttura C sarà invece formata dai seguenti campi:
Porta osservata nelle finestre temporali da 60 secondi;
Protocollo relativo alla porta del campo precedente TCP o UDP;
Valore dell’occorrenza della Porta dei due campi precedenti, ossia il valore
dell’asse Y;
Numero di corrispondenza tra la Porta ed il valore utilizzato per il calcolo dei
valori dei momenti statistici della curva, ossia il valore dell’asse X;
Puntatore alla struttura C, cioè al prossimo elemento della lista verticale di tipo
C.
La struttura D conterrà i seguenti campi:
IP osservato nelle finestre temporali da 60 secondi;
Valore dell’occorrenza dell’IP del campo precedente, ossia il valore dell’asse Y;
Numero di corrispondenza tra l’IP ed il valore utilizzato per il calcolo dei valori
dei momenti statistici della curva, ossia il valore dell’asse X;
Puntatore alla struttura D, cioè al prossimo elemento della lista verticale di tipo
D.
Le strutture E, appartenenti anch’esse all’insieme delle liste verticali, vengono
utilizzate per il calcolo dei momenti statistici relativi alla finestra scorrevole
memorizzata nella struttura A. Un elemento di questa struttura conterrà il valore dei
momenti statistici di un particolare istante all’interno della finestra scorrevole. Ogni
101
struttura di questo tipo ha quindi 5 elementi, uno per ogni istante di cui è formata la
finestra dell’elemento della struttura A.
Ogni elemento della struttura A, ha come è possibile osservare dalla figura 4.19,
tre puntatori ad altrettante strutture di tipo E. Questo perché una struttura di questo tipo
contiene il valore dei momenti statistici relativi ad un particolare tipo di grafico: grafico
IP : Porta oppure il grafico contenente solo la porta sorgente o infine il grafico con solo
l’indirizzo IP.
Vediamo quali campi sono presenti all’interno della struttura di tipo E:
Numero dell’istante a cui si riferiscono i momenti memorizzati nel particolare
elemento della lista verticale di tipo E;
Momenti del primo, secondo, terzo ordine e varianza;
Puntatore alla struttura E, cioè al prossimo elemento della lista verticale di tipo
E.
Infine l’ultima lista verticale è costituita da elementi della struttura F. Questa
struttura viene utilizzata per memorizzare il numero di pacchetti osservati nei 5 istanti di
cui è composta la finestra scorrevole salvata nell’elemento della struttura di tipo A.
I seguenti campi sono contenuti nella struttura di tipo F:
Numero dell’istante a cui si riferisce il numero di pacchetti memorizzati nel
particolare elemento della lista verticale di tipo F;
Numero di pacchetti catturati;
Puntatore alla struttura F, cioè al prossimo elemento della lista verticale di tipo
F.
Le informazioni in queste strutture vengono continuamente aggiornate durante il
funzionamento del sistema statistico per produrre l’uscita, cioè i file di testo contenenti i
vari momenti statistici delle varie finestre scorrevoli.
102
4.5 Algoritmo di Preprocessamento
L’introduzione di questo algoritmo si è resa necessaria a causa del carattere troppo
continuo dei risultati forniti dal sistema statistico fin qui descritto. Ricordiamo che
l’uscita del “discriminatore” statistico dovrà essere utilizzata come ingresso delle reti
neurali, con l’obiettivo di ottenere una classificazione che ci permetta di distinguere una
condizione di “normalità” da un’anomalia.
Dopo un primo esperimento, in cui abbiamo utilizzato i dati forniti dal sistema
statistico senza una fase di preprocessamento, ci siamo subito resi conto
dell’impossibilità delle reti neurali implementate di apprendere correttamente
quell’insieme di valori senza una fase di preelaborazione dei dati.
L’algoritmo utilizzato si basa sulla normale idea di quantizzazione utilizzata nella
conversione da valori analogici a valori digitali. Infatti il nostro obiettivo in questa fase
è di discretizzare l’asse delle ordinate di tutti i grafici visti nel paragrafo precedente,
ottenendo dei fronti di salita e discesa il più possibile ripidi in modo da aiutare la rete
neurale nella sua classificazione. Tutto questo senza perdere ovviamente informazione;
cioè il grafico quantizzato risultante deve mantenere la peculiarità di consentirci con una
semplice ispezione visiva di distinguere un andamento temporale “normale” da uno
anomalo.
Vediamo a questo punto il funzionamento dell’algoritmo. L’asse delle ordinate
viene suddiviso in intervalli di valori contigui e data una coppia di valori (X,Y) viene
determinata l’appartenenza del valore relativo all’asse Y del grafico ad uno degli
intervalli ottenuti. A questo punto il normale metodo di quantizzazione assegnerebbe a
quel particolare valore dell’asse X, come valore della coordinata Y, quello centrale
dell’intervallo individuato.
Il nostro algoritmo invece, prende invece in esame il punto successivo,
determinandone l’appartenenza del valore Y ad un intervallo. Abbiamo due alternative:
la prima è che l’ultimo punto appartenga allo stesso intervallo del precedente, in questo
caso si prende in esame il punto successivo, mentre la seconda alternativa è
rappresentata dalla possibilità che l’intervallo del punto corrente si diverso da quello del
punto precedente.
103
In quest’ultimo caso si determina il numero di punti precedenti caduti all’interno
del vecchio intervallo e si esegue un a semplice media matematica, ottenendo in tal
modo un singolo valore. Tutti i valori della coordinata Y dei punti così selezionati
vengono sostituiti con il valore della media calcolato. L’algoritmo procede in questo
modo fino all’ultima coppia (X,Y) disponibile.
Vediamo un semplice esempio per comprendere meglio il metodo utilizzato.
Supponiamo di avere la seguente successione di coppie (X,Y):
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.
(X = 1; Y = 0,5)
(X = 2; Y = 1,1)
(X = 3; Y = 1,4)
(X = 4; Y = 2,7)
(X = 5; Y = 3,5)
(X = 6; Y = 0,8)
(X = 7; Y = 3,8)
(X = 8; Y = 8,7)
(X = 9; Y = 2,6)
……ecc.
L’asse delle ordinate viene suddiviso in intervalli di ampiezza di 5 unità cioè:
0 ÷ 4; 5 ÷ 9; 10 ÷ 14; 15 ÷ 19; 20 ÷ 24; 25 ÷ 29; ….
(estremi compresi)
L’algoritmo determina l’appartenenza ad un intervallo della prima coppia (X,Y);
in questo particolare caso otteniamo il primo intervallo (0 ÷ 4), poi prosegue con la
seconda coppia, classificandola ottiene lo stesso intervallo precedente, procede quindi
con la coppia seguente. Tutto ciò fino alla coppia numero VIII, la quale appartiene al
secondo intervallo (5 ÷ 9); viene quindi calcolata la media matematica dei valori delle
ordinate delle coppie I ÷ VII ed il valore ottenuto viene sostituito al valore delle
ordinate precedenti. L’algoritmo procede a questo punto con l’elaborazione delle coppie
seguenti.
Il risultato di questa elaborazione sarà:
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
(X = 1; Y = 1,97)
(X = 2; Y = 1,97)
(X = 3; Y = 1,97)
(X = 4; Y = 1,97)
(X = 5; Y = 1,97)
(X = 6; Y = 1,97)
(X = 7; Y = 1,97)
(X = 8; Y = ….)
104
Il valore Y della coppia VIII dipende dai dati seguenti ed è stata omessa per
questo motivo.
Dopo aver descritto il funzionamento dell’algoritmo di preprocessamento dei dati
passiamo ad analizzare come sono stati suddivisi gli assi delle ordinate dei grafici
ottenuti come risultato dell’algoritmo statistico.
Il grafico IP : Porta relativo alle connessioni in ingresso è stato quantizzato
scegliendo intervalli per l’asse delle Y di ampiezza 5 unità;
Il grafico IP : Porta relativo alle connessioni in uscita è stato quantizzato
Il grafico IP relativo alle connessioni in ingresso è stato quantizzato scegliendo
intervalli per l’asse delle Y di ampiezza 5 unità;
Il grafico IP relativo alle connessioni in uscita è stato quantizzato scegliendo
Il grafico Porta relativo alle connessioni in ingresso è stato quantizzato
Il grafico Porta relativo alle connessioni in uscita è stato quantizzato scegliendo
Il grafico sul numero di pacchetti relativo alle connessioni in ingresso è stato
quantizzato scegliendo intervalli per l’asse delle Y di ampiezza 250 unità;
Il grafico sul numero di pacchetti relativo alle connessioni in uscita è stato
quantizzato scegliendo intervalli per l’asse delle Y di ampiezza 250 unità.
L’ampiezza degli intervalli è stata decisa osservando i risultati del sistema
statistico e tentando di rappresentare in maniera adeguata sia il traffico “normale” che le
istanze di attacco.
Inoltre l’ampiezza degli intervalli utilizzati per ciascuna caratteristica è costante.
In alternativa è possibile basare l’algoritmo di preprocessamento su intervalli non
omogenei. Ad esempio aumentando l’ampiezza degli intervalli per valori elevati
ottenendo così una sorta di “quantizzazione non uniforme” che potrebbe aumentare le
prestazioni dell’intero sistema. Ad esempio utilizzando per il grafico IP : Porta relativo
alle connessioni in uscita intervalli del tipo seguente:
105
0 ÷ 49; 50 ÷ 99; 100 ÷ 149; 150 ÷ 199; 200 ÷ 299; 300 ÷ 399; 400 ÷ 499; 500 ÷ 699;
700 ÷ 899;….e così via.
(estremi compresi)
È possibile ottenere un grafico risultante con fronti di salita e discesa più ripidi
rispetto a quanto ottenuto con intervalli di ampiezza omogenea. Soprattutto per quanto
riguarda valori elevati, ossia valori che dovrebbero corrispondere ad un possibile
attacco o ad un’anomalia, che in questo modo verrebbero riconosciuti ancora più
facilmente dalla rete neurale essendo drasticamente diversi dagli altri.
Riportiamo a fine paragrafo un esempio di come si presentano i quattro grafici: IP
: Porta, Porta, IP e numero di pacchetti (NPkt) prima e dopo il preprocessamento. Essi
sono diversi da quelli visti finora in quanto contengono direttamente i risultati finali
dell’intero algoritmo statistico e non di operazioni intermedie come illustrato invece nel
paragrafo precedente, essi sono inoltre disposti con orientamento orizzontale per
problemi di spazio. In altre parole i grafici seguenti illustrano i risultati contenuti in uno
dei due file di testo che costituiscono l’uscita del sistema statistico e precisamente
quello relativo alle connessioni in uscita.
106
Figura 4.20 (a)
Figura 4.20 (b)
107
Figura 4.21 (a)
Figura 4.21 (b)
108
Figura 4.22 (a)
Figura 4.22 (b)
109
Figura 4.23 (a)
Figura 4.23 (b)
110
4.6 Sottosistema delle Reti Neurali
Abbiamo dapprima descritto il funzionamento del sistema statistico, che funge da
“discriminatore”, poi l’algoritmo di preprocessamento, che ha il compito di rendere,
l’uscita fornita dal sistema statistico, più adatta per essere elaborata dallo stadio
successivo formato dal sottosistema delle reti neurali; la cui struttura verrà illustrata in
questo paragrafo.
L’introduzione delle reti neurali comporta una scelta di fondo: adottiamo un
addestramento supervisionato oppure non supervisionato ?
Come illustrato nel capitolo 3 relativo ad una descrizione in generale delle reti
neurali, l’addestramento supervisionato necessita la conoscenza a priori di quale debba
essere l’uscita corretta del sistema. Nel nostro particolare ambito, come in molti altri,
questo porta con sé notevoli problemi: come possiamo, infatti, decidere senza dubbio la
presenza o meno di una particolare anomalia nel traffico di rete o di un attacco ?
Il compito è abbastanza facilitato nei dataset disponibili per testare i sistemi IDS
in ambito accademico in quanto ogni attacco presente in tali dataset è ampiamente
documentato e segnalato ma nel mondo reale è quantomeno problematico stabilire a
priori se un set di dati sia costituito da sole azioni lecite o anche illecite, senza avere a
priori un campione di cosa sia “lecito”.
Il sistema di reti neurali, nel nostro caso, deve svolgere il compito di “motore di
decisione”, osservando cioè l’uscita fornita dal sistema statistico e poi rielaborata
dall’algoritmo di preprocessamento, deve in qualche modo saper distinguere i valori che
possono essere classificati come traffico “normale” dai valori che invece si discostano
significativamente dai precedenti e che quindi sono sintomo dello svolgimento di un
attacco o comunque della presenza di un’anomalia nel traffico di rete osservato.
Lo svolgimento di questo compito implica implicitamente la presenza di una certa
“soglia di riferimento”, possiamo infatti dire che i valori al di fuori di tale soglia
potrebbero essere trattati come anomalie. Ma come possiamo a priori decidere il valore
di questa soglia ?
Tale valore dipende infatti da un elevato numero di fattori, primo fra tutti la
particolare struttura di rete in cui il sistema dovrà operare ed inoltre dalla mole di
traffico che quotidianamente il sistema deve gestire. Questa soglia inoltre sarà adatta per
111
poter rilevare un attacco modificato o magari un attacco che non è stato osservato
durante la fase di addestramento ?
Per questi motivi è desiderabile utilizzare un algoritmo che autonomamente possa
apprendere, durante l’addestramento, le caratteristiche del sistema su cui sta operando e
quindi sempre autonomamente fissare al proprio interno una “soglia di decisione”.
Occorre precisare che nelle reti neurali, per il loro caratteristico funzionamento, il
valore della “soglia” citata in precedenza non è “scritta” esplicitamente da nessuna parte
ma è implicitamente presente nelle informazioni che la rete conserva nei pesi delle
connessioni tra le varie unità neurali. Questo è vero sia per le reti che si basano su un
apprendimento supervisionato sia per quelle che si basano su un apprendimento non
supervisionato; ma la differenza sostanziale è che per quanto riguarda l’apprendimento
supervisionato l’operatore umano che addestra la rete deve scegliere a priori un valore
della “soglia” per poi farla apprendere al sistema di reti neurali, mentre un
apprendimento non supervisionato non ha bisogno, per sua natura, di conoscenza a
priori, liberando quindi noi dall’ingrato e difficile compito di determinare un valore di
“soglia” che potrebbe rivelarsi inadatta per il funzionamento reale del sistema.
Un’altra caratteristica importante che caratterizza un sistema basato su un
apprendimento non supervisionato è una discreta capacità di generalizzazione. Un
sistema di questo tipo infatti, in presenza di un attacco denominato X, già osservato
durante la fase di addestramento, ma che si ripropone durante la fase di test in una veste
leggermente modificata, ha maggiori probabilità di riconoscere che si tratta di un
attacco e magari di classificarlo correttamente come quel particolare attacco che già
conosce denominato X, di quante non ne abbia un sistema basato invece su un
apprendimento supervisionato.
Quest’ultimo, in una situazione simile alla precedente, classificherebbe l’attacco
nella migliore delle ipotesi come attacco Y e nella peggiore delle ipotesi (caso
comunque più probabile) come situazione di pura “normalità”.
Le stesse considerazioni vanno fatte per la presenza, durante il funzionamento
quotidiano (paragonabile alla fase di test), di un attacco mai visto in addestramento ed
anche in questo caso la maggiore probabilità di successo è dalla parte del sistema non
supervisionato.
Per tutte le considerazioni fatte finora abbiamo quindi scelto di adottare un
apprendimento non supervisionato e precisamente abbiamo utilizzato due diverse reti
112
neurali denominate Self-Organizing Maps (SOM) e Growing Neural Gas (GNG),
illustrate nel capitolo precedente riguardante la descrizione in generale delle reti neurali.
Stabilito il tipo di algoritmo di apprendimento e di conseguenza il tipo di reti
neurali che utilizzeremo possiamo decidere in che modo organizzare le informazioni da
utilizzare come ingressi per le reti stesse. Questa scelta influenzerà anche il numero di
reti neurali che dovremmo utilizzare e le modalità con cui esse interagiranno tra loro.
Una possibile implementazione è quella di considerare un primo stadio composta
da 4 reti neurali; una per l’elaborazione delle informazioni provenienti dai grafici
relativi alla coppia IP : Porta (denominata rete IP : Porta), la seconda per l’elaborazione
dei dati forniti dai grafici Porta (denominata rete Porta), la terza prenderà in
considerazione i valori dei grafici con il solo IP (denominata rete IP) ed infine la quarta
classificherà le informazioni riguardanti il numero di pacchetti osservati in ingresso ed
in uscita del server monitorato (denominata rete NPkt).
È inoltre presente un secondo stadio composto da una sola rete (denominata Rete
Finale) che prende in ingresso le classificazioni effettuate dalle quattro reti del primo
stadio. Il secondo stadio avrà quindi il compito di comunicare in modo il più possibile
“user-friendly” lo stato della rete; ossia se tutto procede normalmente oppure se siamo
in presenza di un attacco conosciuto (o di un’anomalia) o se, infine, si stanno
configurando le condizioni per una situazione di preallarme. In questo modo
l’amministratore di rete può reagire prontamente ad una situazione di attacco o di
possibile pericolo per l’integrità della rete stessa.
La classificazione del particolare tipo di attacco in una particolare classe è poi
compito delle quattro reti di cui è costituito il primo stadio.
Ognuna delle quattro reti del primo stadio prenderà in ingresso un vettore di due
elementi. Tale vettore rappresenta una riga dei due file di uscita generati dall’algoritmo
statistico. Il primo elemento del vettore contiene il valore riguardante le connessioni in
ingresso, mentre il secondo elemento sarà occupato dal valore relativo alla connessioni
di uscita. Ciascuna rete prenderà in considerazione, dal file di uscita, e quindi come
ingresso per se stessa solo il dato a cui è interessata; in altre parole la rete che dovrà
classificare i valori del grafico costruito con le coppie IP : Porta leggerà dal file solo i
due valori (uno per le comunicazioni in ingresso ed uno per quelle in uscita dal server
monitorato) relativi alla coppia IP :Porta.
113
Prima di riportare due figure per illustrare la configurazione impiegata ricordiamo
brevemente che i due file di uscita sono memorizzati nel seguente formato:
il campo2 invece è il valore mediato sui 5 istanti della finestra del valore relativo ai
grafici IP : Porta, il campo3 si basa sui grafici che comprendono la sola informazione
sulle porte sorgente, il campo4 è relativo ai grafici IP ed infine il campo5 è il valore
mediato del numero di pacchetti osservato nei 5 istanti definiti nel campo1.
Segue quindi la figura che illustra la formazione dei vettori di ingresso:
Figura 4.24 Formazione dei vettori di ingresso per le varie reti neurali
Continua con la figura relativa allo schema di implementazione del primo e
secondo stadio:
114
Figura 4.25 Primo e secondo stadio del sistema di reti neurali
Come considerazione finale possiamo citare il fatto che abbiamo pensato anche ad
un’implementazione alternativa. Invece di utilizzare quattro reti che prendono in
ingresso un vettore di due elementi è possibile considerare solo due reti le quali
prendono in ingresso vettori di quattro elementi.
In questo modo abbiamo che le due reti sono: una relativa al traffico in ingresso
ed una relativa al traffico in uscita. Gli ingressi sarebbero formati dai soliti quattro
valori provenienti dai rispettivi grafici generati dal sistema statistico: IP : Porta, Porta,
IP e NPkt.
La Rete Finale e quindi il secondo stadio rimarrebbero invariati a patto di
modificare il numero di ingressi da quattro a due come conseguenza della riduzione del
numero di reti neurali nel primo stadio.
Questo schema in qualche modo complementare al precedente, è stato scartato in
quanto non si accosta all’idea di tenere distinti i valori dei quattro grafici, costruiti sulle
quattro diverse caratteristiche prese in considerazione nell’algoritmo statistico, seguita
finora nel nostro lavoro.
115
Capitolo 5 – Risultati Sperimentali
CAPITOLO 5
5 RISULTATI SPERIMENTALI
5.1 Set di dati utilizzato
Nello sviluppo di un progetto sperimentale si ha la necessità di un set di dati
ampio e completo da utilizzare in molteplici occasioni:
Negli esperimenti e valutazioni progettuali iniziali;
Nella determinazione della correlazione tra i parametri dei vari algoritmi
utilizzati, nonché la “sensibilità” degli algoritmi stessi;
Nella taratura preliminare del sistema, una volta implementato, e nelle
valutazioni delle prestazioni del sistema stesso;
Infine, per l’addestramento e la taratura finale del sistema, al suo inserimento
pratico nell’ambito dove dovrà operare.
Nel nostro particolare caso, è evidente che la situazione ottimale sarebbe quella di
disporre già in fase di progettazione concettuale di un dataset ricavato dal vivo sulla rete
a cui il sistema è destinato. Tuttavia, questa soluzione non è praticamente attuabile per
evidenti ragioni. Pertanto, fermo restando che l’addestramento finale del sistema debba
essere compiuto utilizzando dati ricavati dalla specifica rete in cui dovrà operare, per le
prime tre fasi avremo bisogno di un insieme di dati di riferimento.
116
Questi dati devono avere le seguenti caratteristiche:
Realismo: devono essere stati generati su una vera rete, dal vivo o in condizioni
di funzionamento simulato realistiche;
Completezza: devono contenere tutti i dati, sia la traccia delle connessioni che il
contenuto dei pacchetti, possibilmente in un formato utilizzabile facilmente;
Pre-classificazione: vogliamo dei dati che abbiano una legenda di riferimento,
in cui eventuali situazioni anomale inserite o riscontrate abbiano una guida di
riferimento che ci aiuti a individuare veri e falsi positivi;
Dopo accurate ricerche, abbiamo trovato che l’unico insieme di dati oggi
disponibile in rete e di libero uso che presenti contemporaneamente tutte queste
caratteristiche, ed in aggiunta sia stato specificamente creato allo scopo di effettuare
benchmark e sperimentazioni su sistemi di intrusion detection, è il dataset del Lincoln
Laboratory del M.I.T., altrimenti noto come “DARPA IDS Evaluation dataset”. Questo
set di dati è stato infatti utilizzato in moltissimi altri lavori riguardanti lo sviluppo di
sistemi IDS.
In particolare per gli esperimenti abbiamo usato l’intero dataset del 1999 con lo
scopo di testare approfonditamente il funzionamento del nostro sistema.
Nel paragrafo successivo quindi descriveremo come è stato realizzato il “DARPA
IDS Evaluation dataset” dal Lincoln Laboratory del M.I.T. per mettere in evidenza la
qualità del set di dati utilizzato.
5.1.1 DARPA IDS Evaluation dataset
Il problema centrale risiede nel metodo utilizzato per collezionare l’insieme dei
dati. Sono possibili tre principali alternative. La prima idea potrebbe essere quella di
catturare il traffico durante le normali operazioni quotidiane di una vera rete prescelta
ed inoltre generare degli attacchi “controllati” verso host della rete stessa. Questa
proposta, anche se ideale per uno studio di ricerca, non è ovviamente attuabile per
diverse ragioni come: fuga di informazioni private e confidenziali, compromissione
della sicurezza e possibilità di danneggiare o interrompere importanti servizi di rete.
117
Come seconda possibilità si potrebbero rimuovere le informazioni riservate o che
possono in qualche modo minacciare la sicurezza della rete dalla quale sono state
raccolte. Poi, in un secondo momento, inserire manualmente degli attacchi nel set di
dati “filtrato” in precedenza. Questa soluzione, però, comporta in primo luogo delle
difficoltà per la rimozione delle informazioni sensibili, in secondo luogo l’alta
probabilità di introdurre artefatti nell’inserimento manuale degli attacchi.
Infine l’ultima alternativa, che è stata utilizzata per produrre il dataset in
questione, ossia ricreare un traffico normale ed un insieme di attacchi in una rete
dedicata appositamente per questo scopo. Usando quindi host reali, attacchi e traffico
normale di background generati dal vivo.
Il traffico normale è stato generato tenendo presente sia le caratteristiche del
flusso dati osservato alla base militare americana Hanscom Air Force Base, sia le
statistiche sul traffico raccolte da molte altre basi. Gli attacchi ed il codice di hacking
invece, sono stati prelevati da Internet o sviluppati autonomamente per essere poi
eseguiti contemporaneamente al traffico di background.
5.1.2 Generazione del Dataset
La figura 5.1 mostra il diagramma del sistema implementato per generare l’intero
set di dati. I computer sulla sinistra simulano la base militare americana denominata rete
“interna”, mentre i computer sulla destra simulano la rete Internet denominata in questo
caso rete “esterna”. Alla frontiera tra le due reti è posto un router Cisco.
118
Figura 5.1 Sistema implementato per generare il “DARPA IDS Evaluation dataset”
Come è possibile notare dalla figura precedente non sono stati intenzionalmente
utilizzati sistemi di sicurezza attivi come firewall o IDS “in line” per permettere la
corretta l’esecuzione degli attacchi simulati.
Applicativi software simulano centinaia di programmatori, segretarie, manager ed
altri utenti che utilizzano sia applicativi UNIX, sia programmi per sistemi Windows NT.
Un kernel Linux modificato e sviluppato appositamente per questa simulazione,
permette ad un ristretto numero di host di apparire sulla rete e comportarsi come se
fossero centinaia di host diversi con differenti indirizzi IP.
In questo modo sono stati generati diversi tipi di traffico normale utilizzando una
vasta gamma di applicativi di rete, ad esempio, gli utenti simulati inviano e ricevono EMail, navigano su siti Web, inviano e ricevono file utilizzando il protocollo FTP,
utilizzano Telnet per connettersi in remoto ad altri computer, possono inviare e ricevere
messaggi IRC, e così via.
I due elenchi seguenti riassumono l’hardware ed i sistemi operativi dei principali
host nella rete ed inoltre verrà specificato anche il ruolo che essi hanno. La rete interna
che simula la Eyrie Air Force Base contiene i seguenti host:
119
Marx.eyrie.af.mil: vittima, sistema operativo RedHat 5.0 con kernel Linux
2.0.30 su un sistema Intel, è il Web server della base. Esso ospita la homepage e
quindi il sito Internet delle base che viene utilizzato da utenti sia all’interno che
all’esterno della stessa. Il software utilizzato come server Web è Apache
versione 1.1.3 ed inoltre Marx offre anche altri servizi di rete come Telnet e
FTP;
Zeno.eyre.af.mil: vittima, sistema operativo SunOS 4.1.4 su un sistema Sparc 2,
è il file server della base. Esso viene utilizzato come server si posta elettronica e
permette anche la condivisione di file tra utenti mediante il servizio FTP;
Pascal.eyrie.af.mil: vittima, sistema operativo Solaris 2.5 su un sistema
UltraOne, è il server di connessione remota della base. Gli utenti possono
collegarsi a Pascal per leggere E-Mail, navigare nel Web attraverso Lynx, un
browser Web in formato testo, o usufruire degli altri servizi offerti come: Telnet,
SMTP, Ssh e FTP;
Hume.eyrie.af.mil: vittima, sistema operativo Windows NT Server 4.0, build
1381 con Service Pack 1 su un sistema Dell Poweredge 2300. In questo host
sono installati diversi servizi e software come, ad esempio, IIS (Internet
Information Server) versione 2.0 che fornisce servizi come FTP, gopher e Web
server ed il Resource Kit per Windows NT 4 che invece include un server di
posta elettronica e Telnet;
Hobbes.eyrie.af.mil: rappresenta il generatore del traffico di background nella
rete interna. Il sistema operativo è RedHat 5.0 con kernel Linux 2.0.32. Questo
host è dotato del kernel modificato sviluppato appositamente per tale
simulazione, citato in precedenza. Grazie a ciò Hobbes simula 20 workstation
differenti. Sono state installate versioni modificate di sendmail, telnet, login ed
altri strumenti di generazione del traffico di rete, con lo scopo di automatizzare
tali servizi e simulare diversi utenti. Hobbes inoltre svolge anche la funzione di
server DNS. Esso è infatti il server DNS primario della rete interna per quanto
riguarda il dominio eyrie.af.mil;
Locke.eyrie.af.mil: sniffer interno, sistema operativo Solaris 2.6 su un sistema
UltraOne. Locke è utilizzato per catturare il traffico nella rete interna. A tale
scopo è utilizzato l’applicativo Tcpdump versione 3.3. Durante la simulazione
120
sono stati raccolti da Locke più di 16 gigabytes di informazioni osservate dalla
rete;
Attaccanti: due workstation reali e non simulate, la prima con sistema operativo
Linux e la seconda con sistema operativo Windows NT. Questi due host oltre ad
essere utilizzati come punto di partenza per gli attacchi generati dall’interno
della rete militare simulata, possono periodicamente svolgere anche la funzione
di host vittima. Precisamente le versioni dei sistemi operativi sono: RedHat 5.0 e
Windows NT Workstation 4.0 con il Service Pack 1 installato;
Loud.eyrie.af.mil: router Cisco 2500 con in esecuzione IOS v.11.3 rev4. Loud
rappresenta il gateway che connette la rete interna con la rete esterna. Non è
stato abilitato alcun tipo di filtro ed inoltre è possibile monitorare da remoto
questo router attraverso il protocollo SNMP.
La rete esterna invece contiene i seguenti host:
Aesop.eyrie.af.mil: sistema operativo è RedHat 5.0 su una piattaforma Intel.
Aesop simula i vari Internet Web server, appare infatti come se fosse
migliaia di diversi Internet Web server. Grazie alla modificazione del kernel
Linux è in grado di rispondere a richieste da parte degli altri host simulando
ben 2500 diversi Web server;
Calvin.eyrie.af.mil: sistema operativo RedHat 5.0 con kernel Linux
modificato versione 2.0.32 su una piattaforma Intel. Calvin simula la
presenza di 65 diversi host, sembrando in tal modo un gateway di 65 diverse
workstation. Esso è quindi utilizzato come generatore del traffico di
background nella rete esterna. Per questo scopo vengono utilizzati gli stessi
software presenti in Hobbes, il generatore del traffico di background
presente all’interno della rete militare;
Attaccanti: tre workstation reali e non simulate, due sistemi Linux RedHat
5.2 ed un sistema Windows NT Workstation. Questi tre host fisicamente
distinti, sono utilizzati per lanciare attacchi diretti ad host presenti nella rete
interna.
Glassmac: sistema operativo Mac O/S 8.5 su un sistema Macintosh
6100/60. Glassmac simula un monitor SNMP presente in un host militare
121
remoto, che controlla diversi parametri del traffico di rete della base militare
Eyrie.
Solomon.world.net: sniffer esterno, sistema operativo Solaris 2.6 su un
sistema Sparc 2. Questo host è utilizzato per catturare il traffico nella rete
esterna proveniente e diretto verso la rete militare oggetto dei vari attacchi
eseguiti. Per svolgere tale compito viene utilizzato il software Tcpdump
versione 3.3.
Dopo la descrizione del sistema utilizzato per generare il set di dati, soffermiamo
la nostra attenzione sulle modalità di svolgimento della simulazione, come la durata
della stessa e le operazioni necessarie al fine di ottenere un insieme di dati il più
possibile realistico, corretto e continuo nel tempo.
Il sistema è stato utilizzato per cinque settimane consecutive di simulazione,
producendo quindi un set di dati contenente il traffico di rete di un periodo di tempo
abbastanza ampio in modo da poter testare a fondo un sistema IDS. In particolare le
settimane sono composte da cinque giorni (dal lunedì al venerdì) ed inoltre le giornate
sono formate da ventidue ore (dalle 8:00 alle 6:00 del mattino del giorno seguente).La
tabella seguente mostra le ore di inizio e di fine simulazione, oltre ad una breve
descrizione, delle cinque settimane di simulazione.
Settimana
Descrizione
Inizio
Fine
1
Traffico di background
Traffico di background con
bassa percentuale di
attacchi
Traffico di background
alta percentuale di attacchi
alta percentuale di attacchi
1/3/1999, 8:00 am
6/3/1999, 6:00 am
8/3/1999, 8:00 am
13/3/1999, 6:00 am
15/3/1999, 8:00 am
20/3/1999, 6:00 am
29/3/1999, 8:00 am
3/4/1999, 6:00 am
5/4/1999, 8:00 am
10/4/1999, 6:00 am
2
3
4
5
Le settimane 1 e 3 sono caratterizzate solo da traffico di background, quindi senza
lo svolgimento di nessun attacco. La seconda settimana contiene una bassa percentuale
di attacchi rispetto al traffico normale, mentre le ultime due settimane cioè la 4 e la 5
122
sono contraddistinte da un discreto numero di attacchi, in percentuale superiore rispetto
alla settimana numero 2.
Le informazioni circa la data e l’ora sono memorizzate nel formato UNIX, quindi
utilizzando il numero di secondi trascorsi dal 1 Gennaio 1980 fino al particolare istante
di cui vogliamo registrare la data e l’ora.
Occorre notare due cose: la prima è che la settimana di marzo del 1999 è stata
saltata, quindi non abbiamo attività di simulazione registrate nei giorni relativi a tale
periodo. Inoltre domenica 4 aprile è entrata in vigore l’ora legale, per questo motivo
occorre tenere presente tale situazione quando si andranno ad analizzare i dati prodotti
dalla simulazione.
Uno degli obiettivi della simulazione era quello di fornire un insieme di dati
generati nel modo il più possibile continuo nel tempo. Ma le due ore di interruzione al
giorno, si sono rese necessarie per effettuare la manutenzione manuale del sistema. Ad
esempio preparare il software (script) che si occuperà di generare autonomamente il
traffico di background ed anche l’esecuzione di alcuni attacchi, impostare la data ed il
giorno desiderati, raccogliere tutte le informazioni sulla simulazione del giorno
precedente e riavviare le macchine per l’inizio di quella successiva. Tutto questo è
rappresentato nella figura 5.2:
Figura 5.2 Pianificazione temporale delle simulazioni e operazioni effettuate per la manutenzione
manuale del sistema
123
Nonostante l’elevata automazione del sistema di simulazione sono stati necessari
interventi manuali anche durante l’esecuzione vera e propria. Ad esempio per
complesse azioni legate alla generazione del traffico di background come: installare
nuove applicazioni o aggiornare quelle gia presenti. Inoltre alcune volte Aesop, l’host
che simula migliaia di Web server in Internet , ha richiesto un intervento manuale per
un riavvio dopo un blocco del sistema. Azioni manuali sono richieste anche per
l’esecuzione della maggior parte degli attacchi complessi, come ad esempio attacchi
basati su netcat o netbus che comprendono iterazioni con finestre Windows. Oppure
semplicemente per riavviare una macchina o un servizio che ha subito un crash dopo un
attacco riuscito di tipo Denial of Service.
5.1.3 Generazione del Traffico di Background
L’approccio utilizzato per produrre il dataset è quello di generare del traffico di
rete il più possibile realistico e statisticamente simile a quello misurato nei primi mesi
del 1998 nella base militare americana, Hanscom Air Force Base. Sono stati presi in
considerazione anche alcuni aspetti abbastanza particolari di questo traffico come: la
frequenza di alcune parole nelle E-Mail, il tipo di sessioni Telnet ed il tipo di
trasferimenti FTP. Tutte queste caratteristiche sono state riprodotte nella simulazione
effettuata con lo scopo di ricreare un realistico traffico di background.
Come accennato in precedenza è stata ricreata un’elevata quantità di traffico Web,
Telnet ed E-Mail tra PC situati all’interno della base ma soprattutto fra questi ultimi ed i
PC nella rete esterna che simulano il funzionamento di Internet. Le macchine adibite
alla generazione del traffico normale di background sono state presentate nel paragrafo
precedente e svolgono il proprio lavoro grazie ad un kernel Linux modificato in
aggiunta a software di rete personalizzati; come ad esempio server Web, telnet, mail,
ecc.
Il kernel mantiene una tabella di corrispondenza fra l’ID del processo UNIX che
ha richiesto la comunicazione e l’indirizzo IP che aveva l’host al momento della
trasmissione. In quanto per poter simulare diversi host il computer dovrà cambiare
continuamente il proprio indirizzo IP. Tutti i protocolli come TCP, UDP e ICMP
consultano questa tabella prima di formare i pacchetti che verranno trasmessi in modo
da inserire il corretto indirizzo IP per ciascun processo. Le connessioni in ingresso ad
124
host virtuali vengono prima processate da interfacce di rete virtuali gestite dallo stesso
tipo di kernel Linux per poi consegnare il contenuto del pacchetto al processo
proprietario stabilito grazie alla precedente tabella di corrispondenza tra ID del processo
e indirizzo IP. In questo modo un’unica macchina accetta in ingresso pacchetti con
diversi indirizzi IP che poi verranno gestiti dal kernel per la corretta assegnazione ad
una particolare macchina virtuale.
Per quanto riguarda le applicazioni di rete anche queste sono state parzialmente
adattate. Ad esempio l’utilità di login del sistema UNIX controlla l’indirizzo IP virtuale
di destinazione per spedire il corretto messaggio di benvenuto. Anche gli applicativi che
gestiscono i vari server Web sono stati riscritti per avere un comportamento diverso a
seconda dell’host virtuale che invia una richiesta.
Per quanto riguarda Aesop, cioè l’host che simula diversi server Web nella rete
esterna, sottolineiamo che questo contiene la cache di tutti i siti Web reali che sta
simulando. In altre parole, un sever Web simulato da Aesop è ad esempio il dominio
www.yahoo.com, di conseguenza avrà memorizzato nel proprio disco fisso il contenuto
del sito di Yahoo. Tale cache viene aggiornata prima di ogni simulazione.
L’azione di un utente finalizzata alla navigazione sul Web viene simulata da un
software autonomo. Il sito da visitare viene scelto da una lista comprendente i 20 siti
Web più visitati nel periodo della simulazione ed inoltre secondo una distribuzione di
probabilità basata proprio su questa classifica: il sito al primo posto della classifica avrà
più probabilità di essere visitato. Persino l’ora viene considerata infatti durante il giorno
abbiamo più probabilità di iniziare una connessione rispetto alle ore notturne. Una volta
iniziata la navigazione il software simula il comportamento di un utente in carne ed
ossa. Ci sono uguali probabilità di visitare i link di una particolare pagina o secondo il
metodo depth-first (ricerca in profondità) oppure col metodo breadth-first (ricerca in
ampiezza). È presa in considerazione anche la possibilità di saltare ad un nuovo sito o
terminare la navigazione sempre in accordo con una determinata distribuzione di
probabilità in modo da approssimare il più possibile il comportamento umano. Il
software di navigazione autonoma, tanto per fare un confronto si comporta come
l’automa che visita le pagine Web per il famoso motore di ricerca Google, ossia
GoobleBot.
125
Metodologie analoghe basate su distribuzioni statistiche diverse sono utilizzate
per l’automatizzazione di altri compiti come l’invio di file, lettura ed invio di E-Mail,
connessioni remote tramite Telnet, ecc.
Il sistema utilizzato permette quindi la generazione del traffico di background di
un buon livello realistico pur utilizzando un numero ristretto di computer per evidenti
esigenze di simulazione, ma tale sistema porta con sé un aspetto negativo: il carico di
lavoro di un host virtuale ha influenza anche sugli altri host virtuali gestiti dallo stesso
computer fisico. Ad esempio un attacco Denial of Service verso un host virtuale
degraderà le prestazioni di tutti gli altri host virtuali in esecuzione sulla stessa macchina.
La figura seguente mostra ad esempio, il valore medio delle connessioni per
particolari servizi TCP nel traffico di background generato secondo le modalità esposte
finora:
Figura 5.3 Connessioni medie per diversi servizi TCP nelle settimane di simulazione 1 e 3 quindi non
contenenti attacchi
126
5.1.4 Esecuzione degli Attacchi
Come descritto nel primo capitolo ci sono due possibili tipi di aggressori per un
sistema informatico:
Script-Kiddies: privi di reali conoscenze tecniche, studiano ed utilizzano
“exploit”, attacchi preconfezionati rilasciati da esperti e facilmente reperibili su
Internet;
Esperti: dotati di conoscenze tecniche approfondite, capaci di elaborare attacchi
innovativi o di “inventare” procedimenti nuovi.
Nella simulazione sono stati presi in considerazione entrambe le classi di
aggressori. Per simulare l’azione della prima categoria sono stati raccolti numerosi
codici sorgente per eseguire “exploit” conosciuti e sono stati eseguiti nella stessa forma
trovata su Internet, senza cambiamenti. Per la seconda categoria invece si è reso
necessario un ulteriore lavoro di modifica degli attacchi conosciuti per rendere il loro
rilevamento più difficoltoso. Queste modifiche si basano sulle conoscenze generali
utilizzate per eludere gli Intrusion Detection System. Ad esempio alcuni codici di
hacking sono stati modificati utilizzando tecniche legate al polimorfismo oppure legate
alle varie problematiche che riguardano la codifica Unicode. Attacchi finalizzati alla
scansione di porte o di sistemi invece sono stati modificati aumentando il tempo che
intercorre tra due pacchetti o due connessioni consecutive. Intervalli di indirizzi IP o di
porte sono stati analizzati in modo random invece che secondo un ordine ascendente o
discendente ed inoltre durante questi attacchi sono stati aggiunti pacchetti con indirizzo
IP sottoposto a spoofing per mascherare l’autore del vero attacco.
Gli attacchi eseguiti sono stati classificati secondo il loro scopo:
Denial of Service (DOS): attacchi che hanno lo scopo di limitare o negare
completamente l’accesso ad un particolare host o servizio da parte di utenti
legittimi;
Probe: attacchi finalizzati ad ottenere informazioni sull’esistenza o sulla
configurazione di computer singoli o di reti;
127
Remote to Local (R2L): questa classe di attacchi hanno lo scopo di fornire
all’aggressore un accesso locale ad un sistema rispetto al quale egli ha
attualmente solo un acceso remoto;
User to Root (U2R): tipologia di attacco finalizzata ad ottenere i diritti di
amministratore o di utente root, in sistemi UNIX, rispetto ai quali l’aggressore
ha accesso solo come utente non privilegiato;
Data: attacchi con lo scopo finale di ottenere informazioni riservate o comunque
alle quali l’aggressore non dovrebbe avere accesso secondo le politiche di
gestione della sicurezza delle organizzazioni interessate. Alcuni attacchi di
questo tipo, possono anche rientrare sia nella categoria U2R, sia nella R2L.
In accordo con questa classificazione e tenendo presente gli obiettivi del sistema
da noi studiato ed implementato (vedi capitolo 4, paragrafo 1) saremo interessati solo
alle prime due categorie in quanto gli attacchi compresi nelle altre tre saranno
completamente di competenza del tradizionale sistema IDS misuse based che svolge il
proprio lavoro parallelamente al nostro.
Prima di concludere occorre fare una precisazione. Precedentemente durante,
l’illustrazione del sistema implementato per generale il set di dati da utilizzato, è stato
evidenziato il fatto che gli host da cui sono generati gli attacchi sono fisicamente reali e
non virtuali. Questa scelta è stata fatta per evitare di influenzare l’esecuzione di un
attacco quando si verifica contemporaneamente un eccessivo carico computazionale di
un altro host virtuale in esecuzione sulla stessa macchina che gestisce la workstation
sempre virtuale dalla quale dovrebbe essere lanciato l’attacco. Questa soluzione
potrebbe permettere però la rilevazione di un attacco osservando solo l’indirizzo IP dal
quale proviene, in quanto solo alcuni particolari host sarebbero in tal modo adibiti a
funzioni di attacco.
Per evitare ciò sono stati utilizzati un particolare script ed una configurazione di
rete personalizzata che permette di trasferire gli indirizzi IP virtuali tra le macchine che
generano il traffico di background e le macchine utilizzate per lanciare attacchi.
Per verificare il corretto funzionamento dei sistemi IDS valutati con questo set di
dati è stata ovviamente fornito, in un file, l’intero elenco degli attacchi eseguiti durante
tutte le settimane di valutazione. Di seguito è riportata ad esempio una voce relativa ad
un attacco eseguito il 29/03/1999 alle 08:18:35:
128
ID: 41.084031
Date: 29/03/1999
Name: ps
Category: u2r
Start_Time: 08:18:35
Duration: 00:46:05
Attacker: 209.154.098.104
Victim: 172.016.112.050
Username: haraldl
Ports:
At_Attacker: 80{1}, 6000{2}
At_Victim: 23{3}
L’ID rappresenta l’identificatore univoco di ogni attacco eseguito. Possiamo poi
notare il nome dell’attacco in questo caso ps. Questo particolare attacco di tipo U2R
sfrutta una vulnerabilità nella versione dell’utilità “ps” fornita con Solaris 2.5 per
ottenere i privilegi di utente root. È possibile trovare una dettagliata descrizione di tutti
gli attacchi eseguiti nel testo in [2]. Sono riportate anche altre informazioni come
l’indirizzo IP della vittime e dell’aggressore, nonché la durata e le porte utilizzate per
l’attacco. L’informazione denominata Username è presente nel caso in cui l’aggressore
per eseguire l’attacco deve effettuare il login sulla macchina bersaglio come utente non
privilegiato, il valore di questo campo rappresenta il nome utilizzato per l’operazione di
login.
5.2 Risultati Sperimentali forniti dal Sistema Statistico
Come spiegato negli obiettivi del sistema da noi proposto (capitolo 4 paragrafo 1),
osserveremo il comportamento di un host di una rete, un server o comunque un PC che
svolge un ruolo di una certa importanza, dai pacchetti di rete che questo invia e riceve.
In tal modo vogliamo determinare la presenza di un attacco o comunque di un’anomalia
quando la distribuzione statistica dei suddetti pacchetti subisce una variazione
significativa rispetto a quanto osservato in regime di “normalità”.
Dobbiamo quindi scegliere un host da monitorare fra tutti gli host presenti nella
rete interna, che simula la rete di una base militare americana, nel sistema utilizzato per
produrre il dataset del Lincoln Laboratory del M.I.T. La scelta è ricaduta su
Pascal.eyrie.af.mil con indirizzo IP : 172.16.112.50. Un host vittima con sistema
operativo Solaris 2.5 su un sistema UltraOne, che svolge il ruolo di server di
connessione remota della base. Gli utenti possono collegarsi a Pascal per leggere E129
Mail, navigare nel Web attraverso Lynx, un browser Web in formato testo, o usufruire
degli altri servizi offerti come: Telnet, SMTP, Ssh e FTP.
Giustifichiamo a questo punto tale decisione. Siamo particolarmente interessati ad
attacchi appartenenti alle categorie Denial of Service (DOS) e Probe, In quanto data la
particolare struttura del sistema da noi implementato, questo tipo di attacchi hanno una
maggior probabilità di essere rilevati rispetto a tutti gli altri, i quali dovrebbero
comunque interessare l’IDS misuse detection che opera contestualmente con il nostro.
Dopo un’osservazione dei vari attacchi svolti durante la simulazione, quindi presenti nel
dataset, abbiamo notato che Pascal è stato oggetto di un maggior numero di aggressioni
appartenenti alle due suddette categorie rispetto a tutti gli altri host e quindi è stato
scelto per questo motivo.
Rimane comunque la possibilità di ripetere tutti i nostri esperimenti prendendo in
considerazione altri host della simulazione, per testare ancora più a fondo il sistema.
Possibilità da noi trascurata per motivi di tempo.
L’algoritmo statistico è stato quindi testato osservando il traffico di rete di Pascal
per tutta l’estensione temporale della simulazione. Ossia con tutte le informazioni
relative alle cinque settimane, cinque giorni alla settimana presenti nel set di dati.
Prima di vedere i risultati veri e propri riassumiamo un istante in che modo
l’algoritmo statistico fornisce i risultati della propria elaborazione. Vengono generati
due file del tipo di quello mostrato in figura 5.4; uno per le connessioni in ingesso e uno
per le connessioni in uscita. A questo punto possiamo dire che le connessioni in
ingresso ed in uscita sono relative all’host Pascal.eyrie.af.mil che abbiamo deciso di
monitorare.
130
Figura 5.4 File di testo di uscita relativo ai pacchetti in ingresso al server monitorato
Ogni riga di questo file rappresenta una finestra di 5 istanti ed è memorizzata nel
formato:
il campo2 invece è il valore del momento primo mediato sui 5 istanti della finestra del
valore relativo alla caratteristica statistica IP : Porta, il campo3 si basa sulla sola
informazione riguardante le porte sorgente, il campo4 è relativo ai diversi indirizzi IP
presenti nella finestra temporale ed infine il campo5 è il valore mediato del numero di
pacchetti osservato nei 5 istanti definiti nel campo1.
Per visualizzare meglio i risultati non riporteremo i valori contenuti in questi due
file ma bensì i grafici contenenti tali valori. Tutti i grafici riportati in questo capitolo
rappresenteranno un’intera giornata di osservazione dell’host Pascal. Per ogni giorno
131
riporteremo quindi ben otto grafici di cui quattro relativi ai pacchetti aventi come
destinatario Pascal e quattro aventi questo host come mittente. I quattro grafici che
interessano una particolare direzione di comunicazione riporteranno ognuno
l’andamento del momento primo di una particolare caratteristica statistica.
Un grafico sarà quindi relativo alla caratteristica IP : Porta, il quale prenderà come
valori delle ordinate quelli presenti nel campo2, e sarà denominato come in precedenza
grafico IP : Porta, il secondo, denominato Porta, sarà relativo alle informazioni circa la
porta sorgente (campo3), il terzo, denominato IP, riporterà la caratteristica relativa ai
diversi indirizzi IP osservati (campo4) ed infine il quarto graficherà il numero di
pacchetti osservati nelle varie finestre temporali (campo5) e sarà denominato NPkt.
Tutti avranno nell’asse delle ascisse il campo1 del file dei risultati ossia il numero delle
finestre formate da cinque istanti consecutivi contenute nell’intera giornata di
osservazione.
5.2.1 Risultati Relativi al Traffico di Background
Riportiamo, in questo paragrafo, una serie di grafici risultanti dall’elaborazione
del sistema statistico di una giornata di traffico normale e precisamente il secondo
giorno della prima settimana. In questo modo potremmo osservare un andamento
statistico tipico di una giornata contenente solo il traffico di background ed inoltre
metteremo in luce anche alcune caratteristiche di questi andamenti.
132
Figura 5.5 (a)
Figura 5.5 (b)
133
Figura 5.5 (c)
Figura 5.5 (d)
134
Per prima cosa, notiamo che questi grafici sono relativi alle connessioni in
ingresso ed inoltre il valore dei momenti primi mediati nei grafici (a), (b), (c) oscilla al
massimo intorno al valore 7. Questo comportamento si riflette anche nei grafici degli
altri giorni di traffico “normale”, sempre però per quanto riguarda le connessioni in
ingresso, che non riporteremo per problemi di spazio. Il numero di pacchetti, in questo
caso raggiunge quota di circa 600, mentre l’andamento degli altri giorni costituiti solo
dal traffico di background può anche arrivare al massimo intorno al valore di 1400, per
quanto riguarda le connessioni in ingresso.
È interessante capire le differenze tra i grafici (a), (b), (c).Per far ciò prendiamo in
considerazione la zona contrassegnata nei due grafici corrispondente ad un valore in
ascissa pari a 194-198, cioè la finestra formata dai 5 istanti consecutivi, dall’istante 194,
all’istante 198, compresi gli estremi. Il valore riportato nell’asse Y corrisponde quindi al
valore dei momenti primi, determinati con le modalità illustrate nel paragrafo 4.1 del
capitolo 4, mediati sui 5 istanti. Il grafico IP:Porta riporta, nella zona contrassegnata, un
valore di Y abbastanza elevato circa 7,43. Questa situazione non si verifica invece per il
grafico Porta infatti per il particolare valore di X pari a 194-198, il corrispondente
valore Y è di 4,37 che non rappresenta un valore particolarmente elevato in quanto
abbondantemente nella media dell’andamento generale di tale grafico. Quello che
accade con il grafico IP:Porta, invece si ripresenta nel grafico IP con un valore della
coordinata Y di 6,7 pari ad un valore di picco per l’andamento del grafico in generale.
Vediamo il perché di questa situazione osservando il contenuto delle finestre temporali
del secondo giorno, prima settimana, relative al periodo di tempo marcato nelle figure
precedenti (a), (b), (c). Le informazioni riportate di seguito sono estratte da un file che
costituisce un’elaborazione intermedia del sistema statistico. Queste informazioni sono
particolarmente utili sia per scopi di debug ma soprattutto per finalità di “computer
forensics”. È infatti possibile risalire al perché di un determinato comportamento
osservato nei grafici ed inoltre è anche possibile risalire all’indirizzo IP ed al numero di
porta colpevoli di aver determinato un’anomalia nell’andamento dei suddetti grafici.
194,11:14:10.474795,11:15:10.474795,60.000000,332,0
172.16.112.20:53,16
172.16.114.148:25,14
196.227.33.189:25,11
197.182.91.233:25,11
172.16.114.50:25,12
172.16.112.194:25,13
135
172.16.112.10:123,1
172.16.113.84:24694,254
195,11:15:10.474796,11:16:10.474796,60.000000,438,0
172.16.112.149:24705,151
172.16.112.20:53,11
172.16.112.100:25,8
172.16.114.207:26218,267
172.16.112.10:123,1
196,11:16:10.474797,11:17:10.474797,60.000000,730,0
172.16.113.204:28280,712
172.16.112.20:53,8
172.16.112.100:25,9
172.16.112.10:123,1
197,11:17:10.474798,11:18:10.474798,60.000000,277,0
172.16.112.194:29068,228
172.16.112.20:53,8
172.16.112.100:25,8
172.16.112.194:31842,33
198,11:18:10.474799,11:19:10.474799,60.000000,221,0
172.16.112.194:31842,220
172.16.112.10:123,1
Ogni raggruppamento rappresenta un particolare istante è possibile ottenere delle
informazioni sul particolare istante osservando la prima riga di ogni raggruppamento ad
esempio:
194,11:14:10.474795,11:15:10.474795,60.000000,332,0
La riga è memorizzata nel seguente formato:
campo1, campo2, campo3, campo4, campo5, campo6
Il campo1 riporta il numero dell’istante del giorno preso in considerazione, nel
nostro caso il secondo giorno della prima settimana. Il campo2 ed il campo3 riportano
rispettivamente l’ora di inizio e fine dell’istante comprensiva di millisecondi, il campo4
riporta la durata dell’istante, in questo caso 60 secondi, come del resto accade in tutti gli
altri istanti. Il campo5 contiene il numero totale di pacchetti osservati e l’ultimo
(campo6) è utile esclusivamente per informazioni di debug in quanto ci informa nel
caso sia pari ad 1 che l’istante temporale non è completo ossia che il file contenente la
registrazione delle attività di rete è finito prima di poter osservare tutti i 60 secondi. Le
136
informazioni seguenti nel raggruppamento sono le diverse coppie IP : Porta osservate
durante i secondi dell’istante in questione.
Focalizziamo la nostra attenzione sull’istante 194, infatti è proprio questo che ha
determinato il valore 7,43 della coordinata Y relativa alla finestra temporale da 194 a
198 (valore presente nell’asse X). In quanto rispetto agli altri è quello che ha un
maggior numero di coppie IP:Porta osservate. Osserviamo a questo punto gli stessi
istanti ma considerando solo l’informazione sulle diverse porte sorgente osservate:
194,11:14:10.474795,11:15:10.474795,60.000000,332,0
53,UDP,16
25,TCP,61
123,UDP,1
24694,TCP,254
195,11:15:10.474796,11:16:10.474796,60.000000,438,0
24705,TCP,151
53,UDP,11
25,TCP,8
26218,TCP,267
123,UDP,1
196,11:16:10.474797,11:17:10.474797,60.000000,730,0
28280,TCP,712
53,UDP,8
25,TCP,9
123,UDP,1
197,11:17:10.474798,11:18:10.474798,60.000000,277,0
29068,TCP,228
53,UDP,8
25,TCP,8
31842,TCP,33
198,11:18:10.474799,11:19:10.474799,60.000000,221,0
31842,TCP,220
123,UDP,1
Notiamo che la finestra temporale 194 in questo caso non si presenta
significativamente differente rispetto alle altre. Questo è determinato da cinque diversi
indirizzi
IP
(172.16.114.148,
196.227.33.189,
197.182.91.233,
72.16.114.50, 172.16.112.194)
che però sono tutti associati alla stessa porta sorgente ossia la numero 25 relativa
al protocollo TCP. In tal modo ben cinque righe del primo file sono state condensate in
una sola nel file precedente. Il grafico IP : Porta costruito a partire dalle informazioni
137
contenute nel primo file rileva quindi che l’istante 194 è “differente” dagli altri, mentre
il grafico relativo alla sola porta non nota questa differenza.
Abbiamo visto che invece il grafico relativo all’indirizzo IP riporta un valore per
la specifica finestra comprendente gli istanti 194-198 abbastanza elevato, ora possiamo
capire il motivo osservando l’ultimo file ossia quello da cui viene costruito il suddetto
grafico.
194,11:14:10.474795,11:15:10.474795,60.000000,332,0
172.16.112.20,16
172.16.114.148,14
196.227.33.189,11
197.182.91.233,11
172.16.114.50,12
172.16.112.194,13
172.16.112.10,1
172.16.113.84,254
195,11:15:10.474796,11:16:10.474796,60.000000,438,0
172.16.112.149,151
172.16.112.20,11
172.16.112.100,8
172.16.114.207,267
172.16.112.10,1
196,11:16:10.474797,11:17:10.474797,60.000000,730,0
172.16.113.204,712
172.16.112.20,8
172.16.112.100,9
172.16.112.10,1
197,11:17:10.474798,11:18:10.474798,60.000000,277,0
172.16.112.194,261
172.16.112.20,8
172.16.112.100,8
198,11:18:10.474799,11:19:10.474799,60.000000,221,0
172.16.112.194,220
172.16.112.10,1
Possiamo notare, come del resto potevamo aspettarci che l’istante 194 è in questo
caso diverso dagli altri in quanto sono presenti nuovamente tutti gli indirizzi IP che
stanno comunicando sulla porta 25 TCP, questo determinerà la presenza di un valore
elevato nel grafico IP.
Riassumendo il grafico IP:Porta riporta valori abbastanza elevati nelle finestre
temporali dove vengono osservati un congruo numero di indirizzi IP o comunque di
porte diverse rispetto a quanto accade in presenza di valori più bassi. Il grafico IP avrà
un comportamento simile solo in caso di presenza di diversi indirizzi IP ma non ci
138
avvertirà nel caso in cui un unico indirizzo IP sta comunicando su un ampio intervallo
di porte. Questa informazione ci verrà fornita come vedremo successivamente dal
grafico Porta.
I grafici relativi ai pacchetti in uscita della giornata su cui ci siamo focalizzati
ossia prima settimana, secondo giorno sono riportati di seguito.
139
Figura 5.6 (a)
Figura 5.6 (b)
140
Figura 5.6 (c)
Figura 5.6 (d)
141
In questo caso i grafici (a) e (b) sono contraddistinti da valori di picco di circa 50.
Gli altri giorni contenenti solo traffico normale che come in precedenza non sono
riportati per problemi di spazio possono contenere valori di picco per i grafici (a) e (b)
ci circa 110. Il grafico (c) è sostanzialmente identico al precedente e valgono le stesse
considerazioni fatte per quanto riguarda i pacchetti in ingresso. L’ultimo grafico (d)
relativo al numero di pacchetti osservati in uscita ha valori di picco di circa 350, mentre
nelle altre giornate di traffico normale tali valori possono arrivare a circa 1400.
Il curioso andamento dei grafici (a) e (b) che inizia da circa metà giornata e
prosegue fino alla fine della stessa è presente in tutti i giorni del dataset. Tale
andamento è causato da query DNS che Pascal esegue verso il server DNS primario
della rete interna della base militare ossia Hobbes. Come è possibile notare dalle figure
questo andamento non è presente nel grafico (c) relativo alle informazioni sulla sola
caratteristica IP. Questo è spiegabile in modo analogo a quanto fatto in precedenza per i
grafici riportanti le connessioni in ingresso. Una richiesta DNS è caratterizzata da un
unico indirizzo IP di destinazione che rappresenta il server DNS. Le porte sorgente però
sono
diverse
in
quanto
Pascal,
molto
probabilmente
ha
molti
processi
contemporaneamente in esecuzione per rispondere a tutte le richieste di login remoto.
Ognuno di questi processi farà una propria richiesta DNS quando necessario e sarà
contraddistinto da una diversa porta sorgente assegnata nell’istante della richiesta dal
sistema operativo di Pascal al processo interessato.
Rivedendo gli stessi file precedenti generati dal sistema statistico ma per i
pacchetti in uscita relativi ad un istante in cui è presente un valore di picco dei due
grafici (a) e (b) è possibile convincersi di quanto affermato in precedenza. Prendiamo ad
esempio la finestra temporale con gli istanti 714-718 in cui però l’istante interessante
che produce quel particolare andamento è proprio il 714 dal momento che gli altri
quattro hanno solo un paio di voci:
714,19:54:10.475315,19:55:10.475315,60.000000,94,0
172.16.112.100:33098,1
172.16.112.10:32785,2
172.16.112.20:34412,1
172.16.112.20:34413,1
172.16.112.20:34414,1
172.16.112.20:34415,1
172.16.112.20:34416,1
172.16.112.20:34417,1
172.16.112.20:34418,1
172.16.112.20:34419,1
142
172.16.112.20:34420,1
172.16.112.20:34421,1
172.16.112.20:34422,1
172.16.112.20:34423,1
172.16.112.20:34424,1
172.16.112.20:34425,1
172.16.112.20:34426,1
172.16.112.20:34427,1
.
.
.
Sono state rimosse per motivi di spazio altre circa 70 righe con lo stesso indirizzo
IP ossia 172.16.112.20 ed il numero di porta contraddistinto da un aumento
progressivo di una unità. Questo è il file IP : Porta, quello relativo alla sola porta
riportato di seguito è molto simile.
714,19:54:10.475315,19:55:10.475315,60.000000,94,0
33098,TCP,1
32785,UDP,2
34412,UDP,1
34413,UDP,1
34414,UDP,1
34415,UDP,1
34416,UDP,1
34417,UDP,1
34418,UDP,1
34419,UDP,1
34420,UDP,1
34421,UDP,1
34422,UDP,1
34423,UDP,1
34424,UDP,1
34425,UDP,1
34426,UDP,1
34427,UDP,1
.
.
.
Ma infine il file IP è notevolmente differente:
714,19:54:10.475315,19:55:10.475315,60.000000,94,0
172.16.112.100,1
172.16.112.10,3
172.16.112.20,90
Le 90 righe presenti nei file precedenti relative all’indirizzo IP 172.16.112.20
sono state condensate solo in una in questo file. I grafici (a) e (b) riportano quindi valori
molto elevati rispetto all’andamento generale come conseguenza delle 90 righe presenti
143
nei file da cui i grafici sono stati generati. Mentre il grafico (c) non risente della
situazioni degli altri due, dal momento che l’istante 714 è statisticamente simile per
mole di traffico agli altri 4 che formano la finestra temporale 714-718.
Ricapitolando, valori elevati rispetto all’andamento temporale generale del grafico
IP : Porta corrispondono a situazioni in cui sono stati osservati un numero maggiore di
indirizzi IP o numeri di porte diverse rispetto ad altri istanti. Il grafico IP invece
conterrà valori elevati in corrispondenza di finestre con un numero elevato di IP ed
infine il grafico Porta si comporterà analogamente osservando un elevato numero di
valori di porte differenti nello stesso istante temporale.
Inizialmente si è pensato di far funzionare il sistema statistico osservando solo la
coppia IP : Porta, in seguito sono stati introdotti gli altri due grafici per distinguere se un
allarme è stato causato da un eccessivo traffico di indirizzi IP diversi o inversamente da
un eccessivo traffico di porte diverse. Se infatti si presentano pacchetti da “troppi”
indirizzi IP diversi potremo osservare un allarme, caratterizzato da un valore elevato
riportato negli assi Y dei grafici IP : Porta e IP. Mentre se un solo indirizzo IP sta
comunicando su un intervallo di porte troppo elevato possiamo osservare un allarme nei
grafici IP:Porta e Porta. Tutte queste considerazioni sono valide anche in presenza di un
attacco o di un’anomalia con la differenza che in tal caso il delta fra il valore elevato
osservato e l’andamento generale del grafico è molto maggiore rispetto ad una
situazione di “normalità” visto finora.
A questo punto riportiamo i risultati forniti dal sistema statistico in presenza di
attacchi.
5.2.2 Risultati Relativi agli Attacchi
Per determinare se un attacco è stato rilevato o meno abbiamo utilizzato la
seguente procedura. Prima di tutto per ogni grafico relativo alle giornate contenti
attacchi, quindi la seconda, la quarta e la quinta abbiamo verificato mediante una
semplice ispezione visiva se l’andamento dei suddetti grafici fosse in qualche modo
significativamente differente rispetto a quanto visto in caso di traffico normale. Se
questa verifica dava esito positivo siamo passati a verificare l’ora corrispondente al
momento dell’anomalia, nonché l’indirizzo IP e se possibile la porta colpevoli di averla
causata.
144
Questo veniva fatto basandosi su quei file visti nel paragrafo precedente che
vengono salvati dal sistema durante il proprio funzionamento. Infatti data la finestra
temporale con il valore mediato del momento primo in qualche modo “anormale” è
possibile risalire all’ora di occorrenza della finestra temporale ed all’indirizzo IP
osservando le informazioni di ogni istante memorizzate nel file suddetto.
Una volta ottenute queste informazioni abbiamo verificato la presenza di un
attacco in quel determinato giorno e ora, tenendo anche presente l’indirizzo IP
dell’aggressore. La verifica è stata eseguita incrociando i dati presenti nel file
contenente tutti gli attacchi eseguiti durante le cinque settimane di simulazione
ovviamente fornito dal Lincoln Laboratory del M.I.T..
Un attacco verrà rilevato solo da alcune delle caratteristiche osservate. Ad
esempio un tipo potrebbe essere notato solo dai grafici IP : Porta e IP mentre un altro
solo dai grafici IP:Porta e Porta a seconda se coinvolgono rispettivamente un elevato
numero di IP diversi oppure un elevato numero di porte da un ristretto insieme di IP
diversi. Analogamente potrebbe essere rilevato solo dai grafici che si occupano dei
pacchetti in ingresso o solo dai grafici che si occupano di quelli in uscita.
Questo mette in luce il motivo principale per cui sono state contemporaneamente
prese in considerazione più di una caratteristica. La speranza era quella che il sistema di
reti neurali seguente potesse in qualche modo discriminare un particolare tipo di attacco
dalle caratteristiche statistiche che lo hanno rilevato. I risultati forniti dal sistema di reti
neurali metteranno in luce che questa speranza si è almeno in parte verificata.
In seguito sempre per motivi di spazio saranno riportate per ogni istanza di attacco
solo i grafici relativi alle caratteristiche statistiche che lo hanno rilevato. Gli altri non
riportati infatti non hanno significative variazioni rispetto a quelli generati a partire dal
traffico “normale”.
In questo paragrafo riporteremo gli attacchi raggruppando in un particolare
sottoparagrafo tutti quelli dello stesso tipo ossia con lo stesso nome. Quindi nel caso di
istanze multiple di attacco con lo stesso nominativo, queste verranno riportate tutte nello
stesso sottoparagrafo con l’indicazione del giorno e della settimana in cui sono state
osservate.
145
5.2.2.1 Attacco “Mailbomb”
L’attacco denominato “Mailbomb” appartiene alla categoria Denial of Service
(DOS) e si basa sull’invio di un elevato quantitativo di E-Mail ad un singolo server di
posta con lo scopo di sovraccaricare la sua coda di posta con conseguente blocco del
sistema. Un tipico attacco “Mailbomb” si svolge attraverso la richiesta da parte di un
discreto numero di utenti di inviare ben 10000 messaggi da un kilobyte ciascuno, in
totale quindi 10 megabyte di informazioni da ciascun utente.
Nel dataset utilizzato sono presenti 3 diverse istanze di questo attacco con
obiettivo Pascal, il server da noi osservato. In particolare abbiamo la prima aggressione
il secondo giorno della seconda settimana, la seconda si è verificata il giorno dopo ed
infine la terza il terzo giorno della quarta settimana.
Il nostro sistema statistico è stato in grado di rilevare tutte le tre diverse
occorrenze di questo attacco, come testimoniato dai grafici riportati in seguito. Tali
grafici rappresentano le caratteristiche statistiche che hanno permesso di rilevare questo
tipo di attacco per le tre giornate in cui si è verificato.
Essi sono in ordine temporale cioè: la prima sequenza (figure 5.7) è relativa al
secondo giorno della seconda settimana, la sequenza successiva (figure 5.8) è relativa al
terzo giorno della stessa settimana ed infine l’ultima sequenza riporta il terzo giorno
della quarta settimana.
146
Figura 5.7 (a)
Figura 5.7 (b)
147
Figura 5.7 (c)
Figura 5.7 (d)
148
Figura 5.7 (e)
Figura 5.7 (f)
149
Figura 5.8 (a)
Figura 5.8 (b)
150
Figura 5.8 (c)
Figura 5.8 (d)
151
Figura 5.8 (e)
Figura 5.8 (f)
152
Figura 5.9 (a)
Figura 5.9 (b)
153
Figura 5.9 (c)
Figura 5.9 (d)
154
Notiamo che le prime due occorrenze di attacco (figure 5.8 e 5.7 (a), (b), (c), (d),
(e), (f)) hanno mostrato più o meno lo stesso comportamento. Nei grafici relativi al
secondo giorno della seconda settimana l’attacco si è presentato nell’intorno della
finestra temporale 390-394. Per tale valore dell’asse X infatti il picco che ha permesso
l’identificazione dell’attacco ha superato notevolmente i valori visti nel caso di traffico
normale. In particolare è stato raggiunto il approssimativamente il valore di 850 per
quanto riguarda i grafici IP : Porta e Porta per i pacchetti in uscita, mentre i stessi grafici
relativi ai pacchetti in ingresso hanno raggiunto quota 28. I due grafici invece relativi al
numero di pacchetti osservati sia in ingresso che in uscita hanno raggiunto entrambi il
valore 1440 leggermente superiore al massimo valore raggiunto da questi grafici
durante l’osservazione del solo traffico di background.
La rilevazione del giorno seguente in cui l’attacco è stato eseguito ad un’ora
corrispondente alla finestra 350-354 è praticamente identica a quella già vista questo
presuppone che l’attacco sia stato eseguito con le stesse modalità e che quindi abbia
raggiunto la stessa intensità.
La situazione è diversa per quanto riguarda l’ultima aggressione di questo tipo, il
terzo giorno della quarta settimana. L’attacco avvenuto nella finestra 534-538 ha
evidenziato valori leggermente più bassi dei precedenti per i grafici IP : Porta e Porta
mentre il grafico NPkt, prima al limite, ha raggiunto anch’esso valori notevolmente più
bassi e per questa ragione non è stato riportato. Implicitamente quindi abbiamo deciso
che questa aggressione non è stata rilevata dalla caratteristica statistica legata al numero
di pacchetti, conseguenza del fatto che magari è stata meno intensa rispetto alle altre
due.
5.2.2.2 Attacco “Smurf”
Attacco legato alla categoria Denial of Service (DOS). Questo tipo di attacco
esegue una negazione del sevizio della rete contro l’host di destinazione, nel nostro caso
Pascal, affidandosi all’aiuto di un intermediario. L’aggressore, effettuando lo spoofing
dell’indirizzo IP sorgente dell’host di destinazione, genera una grossa quantità di
traffico eco ICMP (Internet Control Message Protocol) diretto verso indirizzi IP di
broadcast. L’intermediario, detto anche amplificatore di smurfing, invia sul suo
155
percorso la trasmissione broadcast. Ogni host che riceve il broadcast risponde all’IP
sorgente sottoposto a spoofing con una replica eco e, secondo il numero di host sulla
rete, sia l’intermediario, sia l’host bersaglio possono essere inondati di traffico. Lo
schema di tale attacco è riportato nella figura 5.10.
Figura 5.10 Schema di un attacco Smurf
L’attacco “Smurf” è stato lanciato nella simulazione tre volte contro Pascal.
Precisamente, il primo giorno della quarta settimana, il quinto giorno della stessa
settimana ed infine il primo giorno della quinta settimana. Anche in questo caso il
sistema statistico ha rilevato tutte le tre istanze di questa aggressione.
Come in precedenza, riporteremo i grafici in ordine temporale cioè: la prima
sequenza (figure 5.11) è relativa alla prima istanza di “Smurf”, la seconda (figure 5.12)
è relativa quinto giorno della quarta settimana ed infine l’ultima sequenza riporta
l’ultima istanza.
156
Figura 5.11 (a)
Figura 5.11 (b)
157
Figura 5.11 (c)
158
Figura 5.12 (a)
Figura 5.12 (b)
159
Figura 5.13 (a)
Figura 5.13 (b)
160
Come avvenuto per l’attacco “Mailbomb” anche in questo caso non tutte le istanze
dell’attacco “Smurf” si sono verificate allo stesso modo e con la stessa intensità.
La prima occorrenza è stata segnalata dai grafici IP : Porta e IP delle connessioni in
ingresso, con valori di picco di circa 100. Inoltre il grafico NPkt sempre relativo alle
connessioni in ingresso ha raggiunto quota 10000.
La seconda istanza di attacco invece è stata riconosciuta solo dai grafici IP : Porta e
IP i quali hanno raggiunto in questo caso il valore 120. Analogamente per l’ultima istanza
di attacco il primo giorno della quinta settimana.
Spendiamo due parole per descrivere meglio gli ultimi due grafici relativi al primo
giorno della quinta settimana. Il picco del grafico IP :Porta che rappresenta l’aggressione a
cui siamo interessati in questo momento è quello evidenziato. Pur essendo infatti più basso
rispetto all’altro raggiunge la quota di circa 770 contro dei valori approssimativamente
intorno ad 8 nel caso “normale”. L’altro picco in figura è dovuto ad un altro tipo di attacco
che vedremo in seguito.
5.2.2.3 Attacco “Portsweep”
Questo tipo di attacco rientra nella categoria Probe, infatti consiste nella scansione di
determinate porte di un singolo host con lo scopo di capire che tipo di servizi di rete sono
in esecuzione sul computer obiettivo.
Nella simulazione sono stati effettuati cinque diversi tentativi di scansione delle porte
verso Pascal. Il sistema di rilevamento in questo caso non si è comportato alla perfezione
come in precedenza ma è stato in grado di rilevare solamente due dei cinque tentativi.
Questo comportamento però era in qualche modo prevedibile infatti una scansione delle
porte è rilevabile attraverso un algoritmo statistico che controlla il flusso del traffico di rete
solo se coinvolge un ampio raggio di porte o magari più host contemporaneamente. Infatti
le altre tre aggressioni non identificate sono caratterizzate da un ristretto numero di
pacchetti inviati pel la scansione. Un’ulteriore conferma di questa affermazione è
rappresentata dal fatto che due su tre delle aggressioni non notate dal sistema statistico
sono state lanciate in modo da renderle meno evidenti, ad esempio controllando solo poche
porte, come se fossero state eseguite da hacker esperti ai quali non occorre avere molte
informazioni su un sistema per capire che tipo di servizi ha in esecuzione.
161
Gli attacchi rilevati e di conseguenza riportati in questo paragrafo sono quindi due.
Precisamente il quinto giorno della seconda settimana ed il terzo giorno della quinta
settimana.
162
Figura 5.14 (a)
Figura 5.14 (b)
163
Figura 5.14 (c)
Figura 5.14 (d)
164
Figura 5.15 (a)
Figura 5.15 (b)
165
Portsweep è stato rilevato dalla caratteristiche IP : Porta e dalla caratteristica Porta. Il
comportamento è corretto in quanto l’attacco è lanciato da un solo indirizzo IP che tenta di
comunicare con un elevato numero di porte del server Pascal, per tale motivo ha dato
l’allarme proprio il grafico Porta.
5.2.2.4 Attacco “Udpstorm”
Con questa aggressione ritorniamo nella categoria Denial of Service (DOS).
Udpstorm sfrutta un bug del demone inetd del sistema operativo Solaris per creare
mediante l’invio di un solo pacchetto sottoposto a spoofing da parte dell’aggressore, un
flusso infinito di pacchetti tra due macchine vulnerabili. Il procedimento è il seguente: per
prima cosa l’aggressore invia un pacchetto con indirizzo IP sorgente sottoposto a spoofing,
attribuendo in questo modo la provenienza del pacchetto alla prima vittima. Questo
pacchetto viene inviato alla porta in cui ascolta il demone inetd (porta echo) della seconda
vittima. Il servizio in questione risponde inviando a propria volta un messaggio echo
all’indirizzo IP contenuto nel pacchetto ricevuto, ossia l’IP della prima vittima. La prima
vittima, ricevuto il pacchetto di risposta ad una domanda che in realtà non ha mai fatto,
invia un ulteriore messaggio echo alla seconda vittima pensando che essa abbia iniziato la
trasmissione. Questo scambio di pacchetti continuerà fino al crash del servizio inetd e
quindi del sistema dei due obiettivi.
Durante le settimane di simulazione questo attacco è stato lanciato contro Pascal due
volte ed entrambe le volte è stato rilevato dal nostro sistema. I grafici seguenti sono relativi
alle due giornate contenenti l’attacco suddetto, ossia il primo ed il secondo giorno della
quinta settimana.
166
Figura 5.16 (a)
Figura 5.16 (b)
167
Figura 5.17 (a)
Figura 5.17 (b)
168
Come prima osservazione possiamo dire che l’attacco è stato rilevato solo dal
grafico NPkt. Questo è dovuto alla particolare struttura dell’aggressione e
contemporaneamente alla struttura del sistema statistico che si occupa delle altre
caratteristiche statistiche come IP : Porta, Porta e IP.
L’attacco si manifesta infatti come un’infinita quantità di pacchetti UDP
provenienti tutti dallo stesso IP, l’IP della seconda vittima supponendo che Pascal sia la
prima, e dalla stessa porta ossia la porta del demone inetd. Per tale ragione le altre tre
caratteristiche statistiche su cui si basa il nostro sistema statistico non hanno sollevato
l’allarme. Nella finestra interessata, sono stati sì osservati più di 6000 pacchetti ma
purtroppo tutti provenienti da un solo indirizzo IP e dalla stessa porta.
Quindi ci siamo trovati costretti ad inserire nelle caratteristiche statistiche
osservate anche il numero di pacchetti processati in una finestra temporale, rischiando
un aumento di falsi positivi, ma catturando anche questo tipo di attacco.
Per quanto riguarda i grafici del primo giorno della quinta settimana il picco
dell’attacco Udpstorm è quello evidenziato, l’altro è relativo ad un altro attacco occorso
nello stesso giorno.
5.2.2.5 Attacco “SshProcessTable”
Sshprocesstable appartiene alla categoria Denial of Service (DOS). Questo attacco
sfrutta una limitazione del kernel del sistema operativo dell’host vittima. Questa
limitazione riguarda il numero di processi che riesce a gestire contemporaneamente.
L’aggressore inizia un elevato numero (solitamente centinaia) di connessioni alla
vittima via Ssh senza però completare il login in nessuna connessione. In tal modo se il
timeout per un login non ancora avvenuto è sufficiente, è possibile riempire la tabella
dei processi dell’host vittima esaurendo le risorse di sistema per i nuovi processi.
Essendo un attacco di tipo Denial fo Service il sistema è stato in grado di
riconoscere correttamente l’unica istanza di questo attacco presente nella simulazione.
Riportiamo quindi i grafici relativi alle caratteristiche statistiche che hanno
evidenziato l’aggressione del giorno in questione ossia il quarto giorno della quarta
settimana.
169
Figura 5.18 (a)
Figura 5.18 (b)
170
5.2.2.6 Attacco “Neptune”
Ancora un attacco appartenente alla categoria Denial of Service (DOS). In
particolare Neptune è un attacco di tipo SYN Flood che ha lo scopo principale di
degradare le prestazioni del sistema e viene eseguito inviando le richieste di
connessione TCP più velocemente di quanto il sistema di destinazione le possa
elaborare. Il sistema vittima conserva le risorse per tenere traccia di ciascuna
connessione, quindi un cospicuo numero di SYN in arrivo può far sì che l’host bersaglio
esaurisca le risorse destinate alle nuove connessioni legittime. L’indirizzo IP sorgente è,
come di consueto, sottoposto a spoofing: in tale modo, quando il sistema bersaglio tenta
di rispondere con la seconda fase dell’handshaking a tre fasi, ovvero SYN-ACK, non
riceve alcuna risposta.
È presente un solo attacco Neptune in tutta la simulazione, il primo giorno della
quinta settimana, ed è stato rilevato, come evidenziato dai grafici seguenti, da diverse
caratteristiche statistiche.
171
Figura 5.19 (a)
Figura 5.19 (b)
172
Figura 5.19 (c)
Figura 5.19 (d)
173
Figura 5.19 (e)
Figura 5.19 (f)
174
Questo è il famoso attacco che abbiamo visto accoppiato in precedenza ad altri il
primo giorno della quinta settimana. Anche in questo caso in presenza di due picchi nello
stesso grafico occorre considerare quello evidenziato.
5.2.2.7 Attacco “Mscan”
Ultimo attacco facente parte della categoria Probe. Mscan in realtà è un tool di
scansione che usa sia tecniche di trasferimento DNS sia scansione a forza bruta di vari
indirizzi IP in cerca di vulnerabilità conosciute. L’attacco si è verificato due volte durante
la simulazione. Come avvenuto in precedenza, con l’altro attacco appartenete alla categoria
Probe, ossia Portsweep, il sistema non si è comportato in modo ottimale come nei casi
appartenenti alla categoria Denial of Service (DOS), rilevando solo una delle due istanze
occorse.
I grafici seguenti sono relativi al quarto giorno della quinta settimana, il giorno in cui
si è verificata l’aggressione Mscan rilevata.
175
Figura 5.20 (a)
Figura 5.20 (b)
176
5.2.2.8 Attacco “Secret”
Questo attacco è particolare rispetto agli altri, infatti fa parte della categoria Data
comprendente attacchi con lo scopo finale di ottenere informazioni riservate. Secret
infatti si verifica quando l’aggressore trasferisce in modo illecito informazioni sensibili
da un particolare host. Questo attacco, pur non appartenendo alle due categorie che il
sistema ha dimostrato di riconoscere, ed essendo solitamente associato ad aggressioni di
tipo R2L o U2R il cui riconoscimento è affidato al sistema IDS misuse detection
parallelo, è stato rilevato. Perché?
I pacchetti coinvolti in questa aggressione sono provenienti da un indirizzo IP che
è stato vittima nello stesso giorno di un attacco Httptunnel (R2L) partito da Pascal, il
server che stiamo monitorando. Questa affermazione è conseguenza dell’osservazione
dei file prodotti dal sistema proposto contenenti le informazioni (ora di ricezione o di
invio dei pacchetti, indirizzi IP e porte) relative a ciascun istante che compongono le
varie finestre temporali graficate nelle figure di questo paragrafo. Come detto in
precedenza infatti tali file possono essere di ausilio nel capire il perché di un particolare
comportamento permettendo una naive metodologia di “computer forensics”.
Ritornando allo scenario di attacco, l’aggressore dopo aver portato a termine con
successo l’attacco R2L ha iniziato a sfruttare la situazione per “rubare” delle
informazioni sensibili dall’host compromesso. Tali informazioni partivano quindi in
modo illecito dalla vittima alla volta di Pascal dove l’aggressore le attendeva sfruttando
l’ignaro server di login sul quale ha un accesso lecito. Il sistema proposto ha notato il
trasferimento di queste informazioni in quanto l’aggressore per accedere a quante più
informazioni possibili ha iniziato un trasferimento in massa obbligando Pascal ad
utilizzare più porte contemporaneamente e quindi a modificare il proprio
comportamento rispetto ad una condizione di “normalità”.
Tutto ciò alimenta la speranza che il sistema proposto sia almeno in parte in grado
di rilevare un comportamento anomalo di un server, in conseguenza allo sfruttamento
dell’host da parte di un aggressore che agisce protetto da un rootkit o da un modulo
maligno del kernel. Egli, infatti, attraverso una vulnerabilità o comunque per mezzo di
un attacco R2L per qualche ragione non rilevato dal tradizionale sistema IDS misuse
detection ha violato il server e dopo aver nascosto la propria presenza può utilizzare
177
l’host a proprio piacimento. L’unico segnale rilevabile di questa presenza è un flusso
anomalo di pacchetti nel filo di rete, provenienti e diretti verso il server violato.
Uno degli obiettivi del nostro lavoro era di rilevare questo tipo di anomalia il più
velocemente possibile, per poi avvertire della situazione l’amministratore di rete che
conseguentemente può correre ai ripari per porre fine al possibile sfruttamento, o alla
fuga di informazioni, dal server compromesso della propria rete. La rilevazione da parte
del sistema statistico dell’attacco Secret in questione mostra che abbiamo intrapreso la
strada giusta per raggiungere l’obiettivo prefissato.
In seguito sono riportati i grafici del quinto giorno della quinta settimana, giorno
in cui si è verificata l’anomalia descritta.
178
Figura 5.21 (a)
Figura 5.21 (b)
179
5.3 Risultati Sperimentali forniti dal Sistema di Reti Neurali
Per prima cosa ricordiamo che le reti neurali hanno il compito di “motore di
decisione”, osservando cioè l’uscita fornita dal sistema statistico e poi rielaborata
dall’algoritmo di preprocessamento, devono in qualche modo saper distinguere i valori
che possono essere classificati come traffico “normale” dai valori che invece si
discostano significativamente dai precedenti e che quindi sono sintomo dello
svolgimento di un attacco o comunque della presenza di un’anomalia nel traffico di rete
osservato.
Nel paragrafo “Sottosistema delle Reti Neurali” nel capitolo 4, abbiamo descritto
in che modo vengono scambiati i dati tra il sistema statistico ed il sistema delle reti
neurali.
L’implementazione utilizzata è quella di un primo stadio composto da quattro reti
neurali; una per l’elaborazione delle informazioni provenienti dai grafici relativi alla
coppia IP : Porta (denominata rete IP : Porta), la seconda per l’elaborazione dei dati
forniti dai grafici Porta (denominata rete Porta), la terza prenderà in considerazione i
valori dei grafici con il solo IP (denominata rete IP) ed infine la quarta classificherà le
informazioni riguardanti il numero di pacchetti osservati in ingresso ed in uscita del
server monitorato (denominata rete NPkt).
È inoltre presente un secondo stadio composto da una sola rete (denominata Rete
Finale) che prende in ingresso le classificazioni effettuate dalle quattro reti del primo
stadio. Il secondo stadio avrà quindi il compito di comunicare in modo il più possibile
“user-friendly” lo stato della rete; ossia se tutto procede normalmente oppure se siamo
in presenza di un attacco conosciuto (o di un’anomalia) o se, infine, si stanno
configurando le condizioni per una situazione di preallarme.
Occorre ricordare che il comportamento del sistema di reti neurali dipende da
quello del sistema statistico. Quindi se un attacco non è stato ad esempio rilevato da una
particolare caratteristica statistica, sicuramente non sarà rilevato dalla corrispondente
rete neurale che prende in ingresso l’uscita della caratteristica statistica in questione.
Abbiamo utilizzato questa struttura con due diverse reti neurali la Self-Organizing
Maps (SOM) e la Growing Neural Gas (GNG).
180
In questo paragrafo riporteremo i comportamenti di entrambe le reti neurali
utilizzate, evidenziando le scelte fatte per l’addestramento e per quanto riguarda la SOM
anche per la scelta della topologia che infatti è fissa in questa rete.
L’uscita, sia per le reti del primo stadio che per l’unica rete del secondo, consiste
in una classe in cui la rete neurale associata con quella particolare uscita ha classificato
l’ingresso proposto in quel momento. Ogni ingresso rappresenta una finestra temporale
composta da cinque istanti consecutivi. L’obiettivo è di ottenere una classificazione del
traffico normale in particolari classi, sia da parte delle reti del primo stadio che da parte
della rete del secondo. Un attacco invece, dovrebbe essere classificato in classi che non
sono mai state riempite in precedenza durante il traffico di background. Meglio ancora
se particolari classi vengono riservate per la classificazione di un solo particolare
attacco, tali classi quindi non dovrebbero essere riempite da finestre relative ad altri
attacchi ma soprattutto al traffico “normale”.
Realisticamente potremmo anche accettare che attacchi diversi siano classificati in
una stessa classe, fermo restando il fatto che tale classe non deve essere utilizzata dal
sistema per la classificazione di valori “normali” dei momenti primi mediati delle
finestre temporali. Come in precedenza vedremo prima le risposte fornite con il solo
traffico di background per poi focalizzare l’attenzione sulle varie istanze di attacco.
5.3.1 Risultati Forniti dalle SOM
La topologia della SOM è stata scelta a priori. In particolare le quattro reti che
compongono il primo stadio sono bidimensionali di ampiezza 5x5, quindi ciascuna avrà
a disposizione 25 classi diverse in cui classificare i pattern di ingresso. La rete del
secondo stadio è invece ad una sola dimensione e contiene 9 unità neurali. Per quanto
riguarda il secondo stadio, 9 unità neurali dovrebbero essere utilizzate per distinguere
gli otto diversi attacchi che sono stati visti tutti in precedenza nei risultati del sistema
statistico, più ovviamente una riservata alla classificazione del traffico “normale”.
Queste scelte all’inizio fatte senza particolari motivazioni teoriche si sono dimostrate
abbastanza valide e per questo motivo dopo aver visto i risultati ottenuti non abbiamo
cambiato la topologia di nessuna rete.
Risolto il problema della topologia passiamo al problema relativo a quali e quanti
giorni del dataset utilizzare come insieme di addestramento. Come primo tentativo si è
181
pensato di utilizzare entrambe le settimane contenenti solo il traffico di background.
Questo significa fornire in addestramento al sistema delle reti neurali le giornate della
prima e della terza settimana. In tal modo però non abbiamo ottenuto risultati
incoraggianti, in quanto, se durante l’addestramento, le reti neurali possono osservare
solo il traffico normale tenderanno ad occupare tutte la classi a propria disposizione solo
per questo tipo di traffico, eseguendo una classificazione più fine. Di conseguenza nella
fase di test finestre temporali relative ad istanze di attacco sono state classificate nelle
classi già utilizzate dalla rete per il riconoscimento di finestre invece con solo il traffico
di background.
Abbiamo quindi pensato di includere nell’addestramento anche giornate in cui
sono stati lanciati degli attacchi con obiettivo Pascal. Nel tentativo seguente quindi
abbiamo presentato in addestramento al sistema di reti neurali i file di uscita del sistema
statistico, sottoposti prima alla fase di preprocessamento, della seconda e quinta
settimana. La seconda settimana contiene principalmente traffico di background con una
bassa percentuale di istanze di attacco, mentre la quinta contiene un’alta percentuale di
attacchi.
Prima della fase di addestramento le varie unità neurali non vengono inizializzate
random ma utilizzando alcuni valori relativi a finestre temporali di cinque istanti
prelevati in modo equamente distribuito dall’insieme che abbiamo deciso di adottare per
l’addestramento successivo.
Nella fase di addestramento vera e propria, invece presentiamo un’intera giornata
alla volta, partendo dalla prima finestra della giornata fino all’ultima, per permettere
alle reti neurali di osservare l’andamento temporale delle caratteristiche statistiche in
una giornata completa, che come è possibile vedere dai risultati del sistema statistico, ha
un carattere abbastanza ripetitivo e ciclico. Basti pensare al fatto che di giorno abbiamo
sicuramente un volume maggiore di traffico di rete rispetto alle ore notturne; questo
comportamento si ripete con una certa regolarità in tutti giorni della simulazione.
L’algoritmo di addestramento è quindi uguale a quello presentato nel sesto
paragrafo del terzo capitolo in cui viene descritta la rete Self-Organizing Maps (SOM).
Prima di passere ai risultati, spendiamo due parole per parlare del numero di
epoche utilizzate in addestramento, ossia il numero di volte che viene proposto alla rete
neurale l’insieme di addestramento. Con una sola epoca le reti neurali SOM hanno
evidenziato grossi problemi di classificazione dei pattern di ingresso. Infatti valori di
182
picco di qualsiasi caratteristica statistica, senza distinzioni, relativi ad avvenimenti del
tutto “normali” e leciti sono stati considerati dal sistema di reti neurali come istanze di
attacco. La situazione è notevolmente migliorata utilizzando dieci epoche di
addestramento. Ad ogni diversa epoca le giornate appartenenti all’insieme di
addestramento vengono presentate secondo sequenze random differenti.
A questo punto riportiamo i risultati della fase di test, successiva alle fase di
addestramento di dieci epoche, in cui abbiamo presentato in ingresso tutte le cinque
settimane del set di dati.
5.3.1.1 Risultati Relativi al Traffico di Background
Allo scopo di avere un’informazione su quali classi siano riservate o meno, da
ciascuna rete neurale nel primo stadio e quindi anche dalla Rete Finale, per il traffico di
background, sono state calcolate alcune percentuali.
In ogni giorno di traffico di background abbiamo calcolato le percentuali di
utilizzo di ciascuna classe da parte di ciascuna rete neurale. In altre parole la percentuale
rappresenta il numero di finestre temporali classificate nelle diverse classi rispetto al
numero totale occorso durante la giornata stessa. Tali percentuali così calcolate sono
state poi mediate su entrambe le settimane e approssimate all’intero più vicino
ottenendo una sorta di rappresentazione del traffico di background da parte delle reti
neurali SOM.
La rappresentazione è riportata nella seguente tabella, in cui la prima colonna da
sinistra rappresenta le possibili classi. Le atre quattro colonne contengono
rispettivamente le percentuali ottenute per la rete IP : Porta, la rete Porta, la rete IP, e la
rete NPkt. Le classi in cui non è presente alcun valore hanno una percentuale di
classificazione pari a zero. Ricordando che stiamo parlando di traffico di background,
questo significa che le classi con percentuale nulla o non sono state utilizzate dalla rete
neurale e quindi sono da considerarsi “unità morte” o più probabilmente molte verranno
utilizzate per la classificazione degli attacchi che vedremo in seguito.
183
Classe
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Rete
IP : Porta
Rete Porta
Rete IP
Rete NPkt
1%
1%
2%
41%
4%
26%
3%
2%
3%
17%
27%
11%
1%
1%
1%
16%
16%
4%
11%
9%
1%
16%
34%
4%
5%
2%
12%
8%
3%
1%
5%
21%
2%
1%
12%
20%
1%
2%
18%
21%
1%
6%
1%
5%
1%
La seguente tabella contiene invece le stesse informazioni ma per quanto riguarda
la rete che costituisce il secondo stadio.
184
Classe
Rete Finale
0
1
2
3
4
5
6
7
8
4%
92%
1%
3%
5.3.1.2 Risultati Relativi agli Attacchi
La classificazione degli attacchi è fortemente influenzata dall’uscita del sistema
statistico. Ovviamente le reti neurali saranno in grado di rilevare solo gli attacchi
identificati correttamente dal sistema statistico. Inoltre le reti neurali che rileveranno
una particolare istanza di attacco saranno quelle associate alle caratteristiche statistiche
che in precedenza hanno permesso la rilevazione dell’attacco da parte del sistema
statistico.
Passiamo a questo punto alla classificazione delle istanze di attacco. Procederemo
in modo analogo a quanto fatto in precedenza per i risultati del sistema statistico, ossia
le istanze di attacco verranno riportate raggruppate a seconda del nome dell’attacco
stesso. In questo modo vogliamo mettere in evidenza il comportamento del sistema in
presenza di attacchi dello stesso tipo. Alla fine possiamo avere una panoramica delle
classi che rappresentano le aggressioni o comunque una situazione di anomalia.
Le istanze di attacco Mailbomb che il sistema statistico è stato in grado di rilevare
sono tre, ricordiamo che sono state notate tutte le occorrenze di questo attacco lanciate
nella simulazione verso Pascal, il server che stiamo osservando.
Vediamo prima come è stata classificata l’anomalia occorsa il secondo giorno
della seconda settimana.
185
Rete IP : Porta classe 15;
Rete Porta classe 23;
Rete NPkt classe 16;
Rete Finale classe 8.
La classificazione della rete IP non è riportata in quanto, la caratteristica statistica
relativa all’indirizzo IP non ha notato questo particolare attacco come conseguenza della
struttura dello stesso. L’attacco Mailbomb coinvolge un elevato numero di porte da un
ristretto intervallo di valori di indirizzi IP per tale motivo le rete IP ha classificato i
valori di queste finestre temporali in classi appartenenti al traffico di background.
Il secondo attacco ossia quello avvenuto il giorno dopo è stato classificato così:
Questa due prime istanze dell’attacco Mailbomb sono state classificate nelle
stesse classi dalle quattro reti che le hanno identificate.
La terza istanza, avvenuta il terzo giorno della quarta settimana, purtroppo non è
stata classificata altrettanto bene.
Rete IP : Porta classi 15 e 10;
Rete Porta classi 22, 23 e 24;
Le prime due reti ossia, IP : Porta e Porta, hanno classificato l’istanza in questione
parzialmente nelle stesse classi delle due precedenti, ossia rispettivamente classe 15 e
23, ma allo stesso tempo sono state occupate anche altre classi comunque abbastanza
adiacenti.
186
Questo comportamento è sicuramente legato al fatto, come possiamo osservare
dai grafici che rappresentano i risultati statistici, che l’ultima istanza Mailbomb si è
presentata con un aspetto leggermente diverso: i valori di picco dei grafici IP : Porta e
Porta sono più bassi in questo caso. Sempre per questa ultima istanza di attacco il valore
raggiunto dal grafico NPkt si trova al di sotto dei valori di picco ottenuti in caso di
traffico di background. Nonostante questo però il valore è stato ugualmente classificato
in classe 16 come nelle due istanze precedenti.
Di conseguenza nella classe 16 della rete NPkt verranno inseriti valori che si
trovano in un intorno del valore di picco raggiunto in caso di traffico “normale”, ossia
un valore di circa 1400. Questo comportamento porterà però, anche ad un ristretto
numero di falsi positivi come vedremo in seguito.
Nonostante queste differenze tutti gli attacchi Mailbomb sono stati comunque
sempre classificati dalla Rete Finale in classe 8.
L’attacco Smurf è presente tre volte nel dataset utilizzato e per tre volte è stato
rilevato correttamente dal sistema statistico.
Vediamo quindi la classificazione della rete neurale per la prima istanza di attacco
del primo giorno della quarta settimana.
Rete IP classe 3;
La seconda istanza dell’attacco Smurf è avvenuta il quinto giorno della quarta
settimana ed è stata classificata così:
Rete IP classe 3;
187
La classificazione è abbastanza simile alla precedente, ma la rete NPkt ha
classificato questa istanza nella classe 22 invece che nella classe 21. Questo ha
comportato anche la variazione del comportamento della Rete Finale che ha classificato
l’istanza in classe 3 invece che in classe 5 come in precedenza.
La classe 3 è utilizzata dalla Rete Finale anche per classificare finestre temporali
relative al solo traffico di background. Questo può sembrare un grosso problema.
Abbiamo però dei fattori mitiganti: per prima cosa la classe in questione ha una
percentuale del solo 3% ottenuta tenendo conto di tutti i valori della prima e terza
settimana. Un secondo luogo le classi utilizzate sempre per questa istanza dalle altre tre
reti non sono mai state utilizzare dalle rispettive reti per la classificazione del traffico
normale.
L’ultima istanza del primo giorno della quinta settimana è invece caratterizzata
dalle seguenti classi:
Rete IP classi 3 e 4;
In questo caso abbiamo invece una classificazione anche in altre due classi
adiacenti da parte delle reti IP : Porta e IP rispetto ai casi precedenti, mentre la rete
NPkt e la Rete Finale hanno nuovamente classificato l’istanza rispettivamente nelle
classi 22 e 3.
Nella simulazione sono stati effettuati cinque diversi tentativi di scansione delle
porte verso Pascal, l’attacco Portsweep infatti rientra nella categoria Probe. Il sistema
statistico ha rilevato solo due di questi tentavi di scansione delle porte. Il motivo è da
ricercare nell’elaborazione effettuata nelle istanze non rilevate per renderle appunto più
nascoste agli occhi di un IDS. Tale elaborazione consiste nel sondare solo un numero
188
limitato di porte inviando quindi pochi pacchetti. Questo a causa della natura statistica
del sistema non è stato rilevato perché mascherato dal traffico di background.
In questo paragrafo riporteremo quindi la classificazione del sistema di reti neurali
relativa ai due attacchi riconosciuti.
La prima è avvenuta il quinto giorno della seconda settimana e la classificazione è
la seguente:
La classe utilizzata dalla Rete Finale è la 8, diversa quindi da quelle utilizzate per
il traffico di background ma è la stessa in cui è stato classificato l’attacco Mailbomb.
Analoga situazione per la classe 16 della rete NPkt.
Questo avviene perché i valori di picco raggiunti da questi attacchi sono più o
meno gli stessi ed il sistema si basa proprio su questi valori per distinguere un attacco
da un altro. In questo caso quindi l’attacco è stato classificato in una classe contenente
anche un’altra aggressione evidenziando comunque la presenza di un’anomalia, ossia
adempiendo all’obiettivo fondamentale del sistema proposto.
La seconda istanza è avvenuta il terzo giorno della quinta settimana:
La classificazione effettuata in questo caso è completamente differente dalla
precedente, inoltre la Rete Finale ha utilizzato la classe 2 che viene riempita anche in
caso di traffico di background. Ma la classe 6 e la classe 2 rispettivamente utilizzate
dalla rete IP : Porta e Porta non sono mai state impiegate per la classificazione del
traffico “normale”, mantenendo un questo modo una distinzione tra l’anomalia ed il
traffico “normale”.
189
5.3.1.6 Attacco “UdpStorm”
Entrambe le istanze di questo attacco presenti nella simulazione sono state
correttamente segnalate dal sistema statistico.
Riportiamo a questo punto la classificazione della prima istanza occorsa il primo
giorno della quinta settimana:
Las seconda istanza del giorno seguente è stata classificata nello stesso modo, ossia:
In questo caso possiamo ritenerci completamente soddisfatti in quanto entrambe le
volte le reti neurali sono state coerenti eseguendo la stessa classificazione. Inoltre le
classi utilizzate, la 20 per la rete NPkt e la 4 per la Rete Finale non sono mai state
riempite in altre occasione riservandole solo per l’attacco Udpstorm.
5.3.1.7 Attacco “Sshprocesstable”
L’unica istanza di attacco Sshprocesstable presente nel dataset è stata lanciata
contro Pascal il quarto giorno della quarta settimana. Essendo stata riconosciuta
correttamente dalle caratteristiche statistiche IP : Porta e Porta riportiamo la
classificazione delle due reti neurali associate più ovviamente quella della Rete Finale.
Rete Porta classi 2 e 9;
190
Ancora una volta la rete del secondo stadio ha utilizzato la classe 3, nella quale
vengono classificate anche le finestre relative al traffico di background. Comunque le
altre reti hanno utilizzato esclusivamente classi relative alle aggressioni permettendo in
tal modo una rilevazione senza possibilità di confusione.
Questo attacco si è verificato una sola volta durante lo svolgimento della
simulazione ed è stato correttamente rilevato dal sistema statistico. Di seguito è riportata
la classificazione delle finestre temporali che riguardano l’aggressione facenti parte del
traffico di rete del primo giorno della quinta settimana.
Questa classificazione è perfetta in quanto sono state riempite classi differenti da
quelli utilizzate per gli altri attacchi e ovviamente differenti dalle classi che
caratterizzano la “normalità”.
Mscan che rientra nella categoria Probe è stato rilevato dal sistema statistico una
sola volta rispetto alle due occorrenze lanciate verso Pascal. La motivazione è analoga a
quanto visto per l’altro attacco di questa categoria ossia Portsweep.
L’aggressione è stata rilevata il quarto giorno della quinta settimana ed è stata
classificata nel modo seguente:
191
In questo caso sono state utilizzate classi in cui sono ricaduti altri attacchi ed
inoltre come avvenuto già altre volte la Rete Finale ha classificato l’aggressione in
classe 3 utilizzata anche se per una limitata percentuale per i campioni relativi al traffico
di background. Fattore mitigante come negli altri casi è che le altre due reti neurali
hanno utilizzato classi in cui ritroviamo solo attacchi.
5.3.1.10
Attacco “Secret”
Attacco facente parte della categoria Data. Attacco un po’ particolare perché
finalizzato alla fuga di un informazioni sensibili sfruttando il successo di un altro
attacco eseguito prima di tipo R2L. La descrizione di questo attacco ed i motivi del
perché tale attacco è stato rilevato dal sistema statistico pur non rientrando nelle due
categoria a cui siamo interessati (Denial of Service e Probe) è riportata appunto nel
paragrafo relativo al rilevamento di questa aggressione da parte del sistema statistico.
Qui ci limiteremo a riportare la classificazione del sistema di reti neurali.
La classificazione è identica a quanto visto per l’aggressione Mscan, valgono
quindi le stesse considerazioni.
5.3.1.11
Considerazioni Finali e Falsi Allarmi
Preso visione delle classi in cui sono stati classificati i vari attacchi siamo ritornati
a considerare i risultati forniti per le giornate del solo traffico di background. Lo scopo è
quello di vedere se alcune classi utilizzate per gli attacchi sono state riempite in
precedenza anche per questo tipo di traffico, generando quindi falsi allarmi. La stessa
operazione è stata svolta anche nelle giornate relative alle aggressioni ma tenendo in
considerazione solo le finestre “normali” tra un attacco e l’altro.
192
Considerato l’intero dataset quindi, il sistema ha generato sei falsi allarmi. Tutti
sono stati causati dall’utilizzo della classe 16 da parte della rete NPkt, con la
conseguenza che poi la Rete Finale ha classificato le stesse finestre nella classe 8.
Questi falsi allarmi sono dovuti quindi ad un intenso uso della rete che ha portato
ad un numero di pacchetti osservati elevato raggiungendo e talvolta superando
leggermente i valori di picco relativi al traffico di background. Abbiamo già esposto in
precedenza che l’introduzione dalla caratteristica statistica sul numero di pacchetti
controllati avrebbe portato probabilmente a dei problemi di falsi positivi, ma abbiamo
fatto la scelta di mantenerla comunque per rilevare l’attacco Udpstorm, altrimenti non
rilevabile a causa della sua particolare struttura.
I falsi allarmi si sono presentati quindi:
Il quarto giorno della prima settimana;
Il primo giorno della quarta settimana (due volte);
Il terzo giorno della quinta settimana;
Il quarto giorno della quinta settimana;
Il quinto giorno della quinta settimana.
Prima di passare alla rete GNG, spendiamo due parole sull’utilizzo delle classi 2 e
3 da parte della Rete Finale per la classificazione di un numero comunque molto
ristretto di attacchi.
Queste classi infatti vengono utilizzate per la classificazione del traffico di
background, anche se per una percentuale molto più bassa rispetto alla classe 1 che
caratterizza tale tipo di traffico. Inoltre come accennato in precedenza le altre reti
neurali hanno classificato gli stessi attacchi in classi utilizzate solo per la classificazione
di aggressioni. Questo permette di distinguere ancora senza dubbio la presenza o meno
di un attacco di questo tipo.
È possibile utilizzare le classi 2 e 3 della Rete Finale come classi di preallarme.
Cioè se alcune finestre temporali vengono classificate in queste classi dal secondo
stadio, ma le altre reti neurali stanno fornendo classificazioni che caratterizzano il
traffico “normale”, allora siamo in presenza di una situazione che si discosta
leggermente dall’andamento classico ma che non significa di per sé lo svolgimento di
un attacco. Inversamente se le reti del primo stadio forniscono una valutazione opposta
193
significa che siamo in presenza di un comportamento che ha i sintomi di un attacco
conosciuto e identificato dalla particolare classificazione delle reti neurali del primo
stadio.
Questa interpretazione è sostenuta dal fatto che in molti casi le finestre temporali
immediatamente precedenti e successive quelle dell’aggressione vera e propria sono
state classificate in classe 3 dalle Rete Finale, nello stesso tempo le altre reti ancora
stavano fornendo informazioni che caratterizzano un traffico di background.
5.3.2 Risultati Forniti dalle GNG
Una rete neurale GNG è in grado di modificare autonomamente la propria
topologia in fase di addestramento per questo motivo non è necessario deciderla a priori
come nel caso della SOM.
L’insieme di addestramento è lo stesso utilizzato per le SOM, ossia la seconda
settimana contenente traffico di background con una bassa percentuale di attacchi e la
quinta settimana , contenente invece un’alta percentuale di attacchi.
Come descritto nell’algoritmo di addestramento delle reti GNG nel terzo capitolo,
tale rete parte inizialmente con due sole unità neurali. L’inizializzazione dei valori di
queste unità è stata fatta, come nel caso delle SOM, prendendo pattern dall’insieme di
addestramento, ossia valori relativi a finestre temporali di cinque istanti prelevati in
modo equamente distribuito.
Nella fase di addestramento, vera e propria, invece presentiamo un’intera giornata
alla volta, partendo dalla prima finestra della giornata fino all’ultima, per permettere
alle reti neurali di poter osservare l’andamento temporale delle caratteristiche statistiche
in una giornata completa, che come è possibile vedere dai risultati del sistema statistico,
ha un carattere abbastanza ripetitivo e ciclico.
Il numero di epoche di addestramento invece costituisce una differenza rispetto a
quanto visto con SOM. Anche in questo caso abbiamo fatto una prima prova con una
sola epoca di addestramento. Diversamente a quanto successo con le SOM i risultati
sono stati abbastanza incoraggianti. Siamo quindi passati a dieci epoche di
addestramento, nella speranza di ottenere risultati migliori. Come successo per le SOM
in ogni diversa epoca le giornate appartenenti all’insieme di addestramento vengono
194
presentate secondo sequenze random differenti. La speranza di ottenere risultati migliori
con dieci epoche rispetto a quelli ottenuti con una si è rilevata vana.
Una possibile motivazione potrebbe essere che le reti neurali appartenenti al
primo stadio si specializzano “troppo”. Infatti osservando più volte lo stesso insieme di
addestramento riescono a cogliere andamenti e informazioni in modo più capillare
rispetto a quanto avviene con una sola epoca di addestramento. Questo è giustificato
anche dal fatto che il numero di unità neurali delle quattro reti presenti nel primo stadio
sono notevolmente aumentate passando a dieci epoche. Con una sola epoca abbiamo
che, la rete IP : Porta è composta alla fine dell’addestramento da 51 unità , la rete Porta
da 54, la rete IP da 59, la rete NPkt da 30 ed infine la Rete Finale è composta da 4 unità.
La situazioni con dieci epoche è notevolmente diversa: , la rete IP : Porta sarà composta
da 349 unità , la rete Porta da 339, la rete IP da 582, la rete NPkt da 215 ed infine la
Rete Finale da 9 unità. Questo comportamento di per sé non è negativo, trascurando il
carico computazionale, ma i risultati forniti dalle reti con questa configurazione sono
notevolmente peggiorati rispetto a quelli ottenuti con un’epoca di apprendimento.
Per prima cosa un attacco viene sempre classificato in un numero elevato di classi
da ciascuna rete neurale del primo stadio. Un solo attacco di media durata, viene infatti
classificato normalmente in 10 classi diverse da ciascuna rete. Questo crea non pochi
problemi alla Rete Finale che in base alle informazioni ricevute dalle reti precedenti
deve decidere la presenza o meno di un’anomalia o un attacco nella finestra temporale
esaminata. La situazione potrebbe essere immaginata come se le reti fornissero
informazioni discordanti come conseguenza di una troppa specializzazione. È come se
l’informazione di un attacco venisse suddivisa idealmente in diversi livelli, tutti i livelli
significano attacco ma in un modo leggermente diverso l’uno dall’altro. La Rete Finale
di conseguenza non riesce più a decidere correttamente, classificando infatti un congruo
numero di attacchi in classi utilizzate per il traffico di background.
Per limitare l’aumento incontrollato delle unità neurali è possibile agire su due
parametri dell’algoritmo di addestramento: il numero di pattern in ingresso che devono
essere presentati alla rete in apprendimento prima di inserire un nuovo nodo (parametro
λ) e il numero massimo di nodi per ciascuna rete. Tentando però di aumentare il
parametro λ oppure limitare il numero di unità abbassando il numero massimo di nodi
delle reti appartenenti al primo stadio abbiamo ottenuto almeno parzialmente l’obiettivo
con reti da al massimo 100 unità neurali, ma anche un grosso effetto collaterale. Il
195
numero di unità della Rete Finale è sceso a 2. Due unità neurali è un numero
insufficiente in quanto riusciamo solo a discriminare tra un traffico “normale” ed un
attacco, perdendo l’informazione sul tipo di attacco e comunque perdendo
completamente la possibilità di avere una classe di preallarme.
In alternativa è possibile pensare di modificare l’algoritmo di addestramento vero
e proprio della rete neurale; imponendo la creazione di una nuova unità non ogni λ
pattern presentati in ingresso ma quando l’errore medio commesso dalle unità neurali
della rete supera un certo valore. Tale possibilità non è stata però sperimentata per
problemi di tempo.
Confrontando quindi i risultati ottenuti addestrando la SOM per dieci epoche e la
GNG per una sola epoca, la prima ha ottenuto risultati migliori anche considerando il
fatto che ha potuto osservare più volte i pattern di ingresso. Le reti GNG ad esempio
hanno classificato in classi appartenenti al traffico “normale”, anche in elevata
percentuale, le finestre temporali relative a tre diversi attacchi avvenuti durante la
simulazione e correttamente rilevati dal sistema statistico.
Con questo non si intende dire che la SOM fornisce universalmente risultati
migliori in quanto ci sono altri studi molto più approfonditi sull’argomento.
Semplicemente per il nostro particolare ambito e per la struttura del sistema decidere i
valori ottimali dei parametri di addestramento della GNG, come ad esempio il
parametro λ e il numero massimo di unità neurali, si è rilevato molto complicato. Infatti
studiando approfonditamente il comportamento delle reti neurali al variare di tali
parametri molto probabilmente si giungerà a dei valori con cui è possibile aumentare le
epoche di addestramento con un conseguente aumento di prestazioni delle reti e non un
degrado come si è verificato nel nostro caso.
La ricerca dei valori ottimali di questi parametri non è stata fatta per un motivo
principale, infatti una volta trovati sarebbero adatti solo per il particolare set di dati
utilizzato. Cambiando dataset quindi o l’ambito di lavoro del sistema proposto lo studio
in questione andrebbe rifatto dall’inizio per trovare i nuovi valori dei parametri di
addestramento adatti alla nuova distribuzione di ingresso.
Riporteremo quindi anche se non verranno commentati approfonditamente come
fatto in precedenza per le SOM i risultati del sistema di reti neurali basato sulle GNG,
addestrate con lo stesso algoritmo riportato nel settimo paragrafo, in cui viene descritta
la rete Growing Neural Gas (GNG), del terzo capitolo e per una sola epoca.
196
5.3.2.1 Risultati Relativi al Traffico di Background
Per ottenere una rappresentazione del traffico normale con le reti GNG abbiamo
seguito la stessa procedura utilizzata per le reti SOM. Abbiamo quindi calcolato, per
ogni rete, la percentuale che rappresenta il numero di finestre temporali classificate
nelle diverse classi rispetto al numero totale occorso durante la giornata stessa. Tali
percentuali sono state poi mediate su entrambe le settimane con solo traffico di
background e approssimate all’intero più vicino.
Le percentuali sono riportate nelle seguenti tabelle che contengono solo le classi
con una percentuale diversa da zero. Inoltre a causa del diverso numero di classi di
ciascuna rete neurale, come conseguenza di un numero diverso di unità neurali, ad ogni
tabella è associata una particolare rete neurale.
Rete IP : Porta
Rete Porta
Classe
Percentuale
Classe
Percentuale
7
8
42
97%
2%
1%
3
16
19
52
1%
97%
1%
1%
Rete IP
Rete NPkt
Classe
Percentuale
Classe
Percentuale
5
10
14
15
17
30
52
56
58
19%
12%
3%
2%
37%
8%
4%
2%
13%
5
7
8
10
83%
2%
2%
13%
197
Rete Finale
Classe
Percentuale
1
3
1%
99%
Come possiamo vedere dalle tabelle la classificazione del traffico normale è molto
buona, pur con una sola epoca. Infatti, ad eccezione della rete IP, abbiamo sempre la
presenza di una classe con una percentuale di classificazione uguale o superiore al 83%,
questo significa che il traffico normale è ben rappresentato da quella classe. È
preferibile infatti avere meno classi con un’alta percentuale che un numero più elevato
di classi con una bassa percentuale di classificazione ciascuna, in quanto sono tutte
riferite al solo traffico normale. Sotto questo punto di vista, tenendo sempre presente la
limitazione di una sola epoca la GNG si comporta meglio rispetto alla SOM, dove le
classi che caratterizzano il traffico normale sono di più ed ovviamente ciascuna ha una
bassa percentuale di classificazione.
5.3.2.2 Risultati Relativi agli Attacchi
Passiamo a questo punto alla classificazione delle istanze di attacco. Procederemo
in modo analogo a quanto fatto in precedenza per le reti neurali SOM, ossia le istanze di
attacco verranno riportate raggruppate a seconda del nome dell’attacco stesso. In questo
modo vogliamo mettere in evidenza il comportamento del sistema in presenza di
attacchi dello stesso tipo. Alla fine possiamo avere una panoramica delle classi che
rappresentano le aggressioni o comunque una situazione di anomalia.
198
Istanza dell’attacco Mailbomb avvenuta il secondo giorno della seconda settimana:
Aggressione del giorno successivo:
Rete Porta classi 53 e 25;
Ultima aggressione il terzo giorno della quarta settimana:
Rete IP : Porta classi 38, 40 e 46;
Primo attacco Smurf il primo giorno della quarta settimana:
Rete IP classi 24, 26, 41 e 42;
Seconda istanza il quinto giorno della quarta settimana:
Rete IP classi 24, 26 e 44;
199
Terza e ultima istanza il primo giorno della quinta settimana:
Rete IP classi 24 e 57;
Prima aggressione il quinto giorno della seconda settimana:
Seconda ed ultima aggressione il terzo giorno della quinta settimana:
5.3.2.6 Attacco “UdpStorm”
Prima istanza il primo giorno della quinta settimana:
La seconda ed ultima istanza è avvenuta il giorno seguente:
Rete NPkt classi 16, 18 e 22;
200
5.3.2.7 Attacco “Sshprocesstable”
L’unica istanza di attacco avvenuta il quarto giorno della quarta settimana non è
stata rilevata in quanto le finestre temporali relative sono state classificate nelle classi
relative al traffico di background viste in precedenza.
Attacco del primo giorno della quinta settimana:
Rete IP : Porta classi 1, 2 e 30;
Rete NPkt classi 1, 2, 15 e 22;
L’unico attacco Mscan il quarto giorno delle quinta settimana non è stato rilevato.
5.3.2.10
Attacco “Secret”
Anche l’unico attacco Secret il quinto giorno delle quinta settimana non è stato rilevato.
5.3.2.11
Considerazioni Finali e Falsi Allarmi
Osservando i risultati forniti, oltre ai tre macroscopici problemi che risiedono nei
rispettivi tre attacchi non rilevati ma che sono stati a loro volta riconosciuti dal sistema
statistico, si possono evidenziare anche altri errori di classificazione.
La terza istanza dell’attacco Mailbomb ad esempio, anche se leggermente diversa
dalle prime due è stata classificata nella stessa classe delle prime due dalle Rete Finale
201
utilizzando le SOM. In questo caso invece la rete dell’ultimo stadio ha classificato
quest’ultima istanza in una classe diversa rispetto alle precedenti due.
Inoltre l’attacco Neptune diverso nella forma e nell’intensità da qualsiasi altro
attacco nella simulazione lanciato contro Pascal, è stato infatti classificato nel caso delle
SOM dalla Rete Finale in una classe riservata, mentre con le GNG è ricaduto nella
classe in cui sono state classificate le prime due istanze di attacco Mailbomb.
Il numero di falsi positivi è un altro fattore, assieme alla capacità di
classificazione del traffico “normale”, in cui il sistema di reti neurali formato dalle
GNG hanno mostrato un certo vantaggio rispetto alle SOM. Teniamo sempre presente
comunque che per problemi di elevata difficoltà nell’impostazione dei parametri di
addestramento della GNG dovuti alla nostra particolare implementazione del sistema di
reti neurali, stiamo testando tale rete con solo un’epoca di addestramento, in quanto con
un numero maggiore le prestazioni peggiorano.
Con tutti i dati della simulazione abbiamo ottenuto solo due falsi allarmi dovuti ad
un eccessivo numero di pacchetto osservati con la conseguente attivazione della classe
15 da parte della rete NPkt e della classe 0 della Rete Finale. Precisamente questo è
avvenuto il primo giorno della quarta settimana ed il terzo giorno della quinta settimana.
202
CAPITOLO 6
6 CONCLUSIONI E SVILUPPI FUTURI
In questo lavoro abbiamo illustrato le problematiche fondamentali connesse alla
sicurezza dell’informazione, e come queste conducano naturalmente alla formulazione
del problema di Intrusion Detection. Abbiamo illustrato gli approcci all’Intrusion
Detection che si riscontrano nel panorama attuale, ed abbiamo discusso i tipici problemi
che i sistemi IDS devono affrontare nel “mondo reale”. Abbiamo proposto un modello
innovativo di sistema di rilevamento delle anomalie nel traffico di una rete informatica.
Tale sistema si basa su un approccio “anomaly detection” ed inoltre si pone a metà tra
un sistema “host based” e “network based”, nel tentativo di sfruttare i vantaggi derivanti
da entrambe le rappresentazioni. Il sistema proposto è formato da due sottosistemi che
interagiscono tra loro.
Il primo è il sottosistema statistico che svolge il ruolo di “discriminatore”, dal
momento che consente una prima distinzione tra un andamento “normale” ed un
andamento “anomalo”, sulla base di alcune caratteristiche statistiche del traffico di rete.
Il secondo sottosistema è caratterizzato da un’architettura di reti neurali che
ricevono in input l’uscita del primo sottosistema, e svolgono il compito di “motore di
decisione”, ossia hanno il compito di comunicare lo stato della rete; se tutto procede
normalmente oppure se siamo in presenza di un attacco conosciuto (o di un’anomalia).
Allo scopo di dimostrare la validità del sistema proposto, sono stati riportati una
serie di risultati sperimentali, utilizzando come insieme di dati di riferimento il dataset
del Lincoln Laboratory del M.I.T., altrimenti noto come “DARPA IDS Evaluation
dataset”.
Il sottosistema statistico è stato in grado di rilevare il 100% delle aggressioni
facenti parte della categoria Denial of Service (DOS) eseguite contro il server da noi
monitorato. Inoltre, sono state rilevate il 67% delle istanze di attacco appartenenti alla
categoria Probe. La rilevazione delle istanze di attacco della categoria U2R e R2L, che
203
Capitolo 6 – Conclusioni e Sviluppi Futuri
un sistema basato su un approccio ”anomaly detection” potrebbe non rilevare a causa
della sua natura statistica, è affidata ad un sistema tradizionale di Intrusion Detection
System “misuse based”.
Uno dei principali obiettivi di questo sistema è stato quello di rilevare, dalle
informazioni ricavate dal traffico di rete, il comportamento di un aggressore che
nascondendo la propria presenza mediante l’installazione di un rootkit o di un modulo
maligno del kernel può sfruttare il più a lungo possibile e a proprio piacimento un host
compromesso in precedenza. Nei risultati sperimentali il sistema statistico ha rilevato
un’istanza di attacco finalizzata al furto di informazioni “sensibili”, appartenente alla
classe Data, che si svolge in maniera analoga allo scenario descritto in precedenza.
In questo attacco infatti, l’aggressore attraverso una vulnerabilità o comunque per
mezzo di un attacco R2L ha violato un altro server e dopo aver nascosto la propria
presenza, utilizza il server che stiamo monitorando, sul quale ha un accesso lecito, per
“rubare” informazioni dall’host compromesso. Il sistema proposto ha notato il
trasferimento di queste informazioni in quanto l’aggressore per accedere a quante più
informazioni possibili ha iniziato un trasferimento in massa obbligando il server
osservato a modificare il proprio comportamento rispetto ad una condizione di
“normalità”.
Il sottosistema delle reti neurali ha innanzitutto mostrato la capacità di
rappresentare in modo corretto il traffico “normale”. Alcune classi vengono infatti
riservate dalle reti neurali esclusivamente per la classificazione del solo traffico di
background senza attacchi.
Per valutare le “performances” di due differenti tipologie di reti neurali autoorganizzanti, il sottosistema neurale è stato implementato utilizzando, in un primo caso
le reti Self-Organizing Maps (SOM), e in un secondo caso le Growing Neural Gas
(GNG). Per quanto riguarda la prima rappresentazione, quella basata sulle SOM, il
secondo stadio del secondo sottosistema ha classificato correttamente il 92% delle
finestre relative al traffico “normale” in classe 1. Mentre utilizzando le GNG questo
risultato è migliorato, dal momento che la Rete Finale ha classificato in classe 3 ben il
99% dei pattern di ingresso relativi al solo traffico di background.
Il fatto di classificare istanze di attacco in classi separate rispetto al traffico
“normale” mette inoltre in evidenza la capacità delle reti neurali di distinguere i risultati
204
del sottosistema statistico riguardanti appunto il traffico “normale” da quelli riguardanti
le varie istanze di attacco.
Utilizzando le SOM, inoltre in alcuni casi la Rete Finale ha saputo riconoscere un
particolare attacco classificando tutte le istanze in una sola classe. Questo è successo ad
esempio nel caso delle tre diverse istanze Mailbomb (classificate in classe 8), le due
istanze di attacchi Udpstorm (classificate in classe 4) ed infine due delle tre istanze di
attacco Smurf (classificate in classe 3). In aggiunta la Rete Finale ha riservato
particolari classi per la classificazione di un solo tipo di attacco, ciò vuol dire che gli
unici pattern classificati in una particolare classe saranno rappresentati solo da ingressi
di un particolare attacco e da nessun altro (compreso il traffico di background). Un
esempio di queste classi sono: la classe 8 per le istanze di attacco Udpstorm, la classe 7
per l’attacco Neptune e la classe 5 in cui è stata classificata una sola istanza di attacco
Smurf.
Le GNG pur mantenendo la capacità di distinguere un’aggressione dal traffico di
background, non hanno riservato particolari classi per la classificazione di un solo tipo
di attacco, cioè pattern relativi a diversi attacchi dello stesso tipo sono stati classificati
in classi diverse. Questo è dovuto al fatto che le reti SOM sono state addestrate con 10
epoche, nel caso delle GNG invece aumentando il numero di epoche di addestramento
si è rilevato un degradamento delle prestazioni. Da questo fatto si può prendere spunto
per uno studio futuro sulla criticità dei parametri di addestramento della rete GNG.
Alternativamente è possibile pensare di cambiare l’algoritmo di addestramento vero e
proprio, in modo da non generare una nuova unità neurale ogni λ pattern di ingresso
presentati, ma bensì quando l’errore medio commesso dalle rete supera una certa soglia.
Sarebbe interessante percorrere anche questa strada per analizzare meglio il
comportamento delle reti GNG nel nostro particolare campo di applicazione.
Un’ulteriore sviluppo futuro è rappresentato da uno studio approfondito sulle
possibili variazioni dei parametri di funzionamento dell’algoritmo statistico presentato e
l’impatto dovuto ad una loro variazione sulle prestazioni dell’intero sistema. I parametri
interessanti sotto questo punto di vista sono principalmente due ossia l’ampiezza della
finestra temporale di osservazione, per la quale abbiamo scelto un valore pari a 60
secondi nelle varie prove sperimentali, e l’ampiezza della finestra scorrevole,
attualmente di cinque istanti consecutivi.
205
Infine sarebbe sicuramente interessante svolgere altri esperimenti con dataset
diversi e magari su una rete on-line, in quanto tutto il sistema proposto è stato pensato e
quindi implementato per poter operare, senza dover ristrutturare l’intera l’architettura,
anche on-line.
206
BIBLIOGRAFIA
[1] J. P. Anderson, “Computer Security Threat Monitoring and Surveillance”,
Technical Report, James P. Anderson Company, Fort Washington, Pennsylvania (Aprile
1980)
[2] J.W. Haines, R.P. Lippmann, D.J. Fried, M.A.Zissman, E. Tran, S.B. Boswell,
Group 62 "1999 DARPA Intrusion Detection Evaluation: Design and Procedures",
Technical Report 1062, Massachusetts Institute of Technology, Lincoln Laboratory
[3] Computer Security Institute – Federal Bureau of Investigations, “The 2002 CSI/FBI
computer
crime
and
security
survey”,
disponibile
online,
http://www.gocsi.com/press/20020407.html
[4] David R.Mirza Ahmad, Ido Dubrawsky, Hal Flynn, Joseph “Kingpin” Grand Robert
Graham, Norris L. Johnson, K2, Dan “Effugas” Kaminsky, F. William Lynch, Steve
W.Manzuik, Ryan Permeh, Ken Pfeil, Rain Forest Puppy, Ryan Russel “Hack Proofing
Seconda Edizione”, McGraw-Hill
[5] E. “Aleph1” Levy, “Smashing the stack for fun and profit”, Phrack magazine, vol.
7, issue 49 (Novembre 1996) http://www.phrack.org/phrack/49/P49-14
[6] http://www.sans.org/top20
[7] T. Kohonen, “Self-Organizing Maps”, 3a edizione, Springer-Verlag, Berlino (2001)
[8] B. Fritzke, “Growing Cell Structures, A self organizing neural network for
unsupervised and supervised learning”, 1994
[9] B. Fritzke, “A growing neural gas network learns topologies”, in G. Tesauro, D. S.
Tou-retzky and T. K. Leen (Eds.): Advances in Neural Information Processing Systems
[10] www.tcpdump.org
[11] http://winpcap.polito.it/
[12] www.ethereal.com
[13] J. Postel, “RFC 791: Internet Protocol” (1981)
ftp://ftp.rfc-editor.org/in-notes/rfc791.txt
[14] J. Postel, “RFC 793: Transmission Control Protocol” (1981)
207
Bibliografia
[15] J. Postel, “RFC 768: User Datagram Protocol” (1980)
[16] J. Postel, “RFC 792: Internet Control Message Protocol” (1981)
[17] P. Lichodzijewski, A. N. Zincir-Heywood, M. I. Heywood, “Dynamic Intrusion
Detection Using Self Organizing Maps”, 14th Annual Canadian Information
Technology Security Symposium (Maggio 2002)
[18] K. Labib, R. Vemuri, “NSOM: A Real-Time Network-Based IntrusionDetection
System Using Self-Organizing Maps”, Technical Report, Department of Applied
Science, University of California, Davis
[19] S. Zanero, “Un Sistema di Intrusion Detection Basato su Tecniche di
Apprendimento non Supervisionato”, tesi di laurea, Politecnico di Milano, Facoltà di
Ingegneria
208

universita` politecnica delle marche

Transcript

Documenti analoghi

49 51 B B Come continuare l`attacco? Il Bianco ha appena

Attacchi di Parigi, lunedì momento di riflessione

integrare al meglio tecnologie e competenze

Disponibilità DoS

AZIONE ATTACCO AL POTERE 2

W Caramiello, Spielberg racconta il World Trade Center BIS TP

Contenuti Introduzione Il gioco del silenzio Capitolo 1. Escursione

armeriapalmieri Attacco Contessa Simply Black x BAR

h~:~R~Il~ SenoIa, rUnicobas chiama a raccolta