Tecnologie innovative per il rilevamento e il

Transcript

SICUREZZA
Tecnologie innovative per il
rilevamento e il contrasto degli
attacchi informatici
GERARDO LAMASTRA
LUCA VIALE
Il costante aumento della complessità delle reti, dei sistemi e dei servizi richiede l’adozione di approcci innovativi al rilevamento e alla scoperta degli attacchi informatici. I sistemi di rilevamento, sia quelli mirati alla protezione del
backbone, sia quelli mirati alla protezione della Intranet e degli utenti, sono
una componente fondamentale di una moderna infrastruttura di sicurezza.
L’articolo descrive e analizza lo stato dell’arte in questo settore, con particolare attenzione agli aspetti emersi nel campo della ricerca e illustra i risultati
delle attività di studio e innovazione condotte in Telecom Italia Lab.
1. Introduzione
I sistemi di rilevazione e prevenzione delle intrusioni (IDS - Intrusion Detection System) sono divenuti, negli ultimi venti anni, uno degli elementi fondamentali dell’architettura di sicurezza di una rete
informatica. Un sistema di Intrusion Detection è l’analogo informatico del sistema di allarme che protegge un’abitazione o una banca. Come un vero e
proprio sistema di allarme, un IDS è caratterizzato
dai seguenti elementi:
• sensori, per il rilevamento degli eventi indesiderati o delle condizioni anomale nell’ambiente
monitorato;
• sistema di raccolta e di correlazione delle informazioni fornite dai sensori, in grado di decidere
se è effettivamente il caso di emettere una
segnalazione;
• meccanismo di segnalazione, tipicamente multimodale (per esempio la sirena ed un avviso
inviato direttamente alle forze dell’ordine).
Anche i sistemi di Intrusion Detection sono
caratterizzati fondamentalmente dalle stesse
componenti; inoltre, proprio come i sistemi di
allarme tradizionali, i sistemi IDS, essendo dei
sistemi automatici, possono essere aggirati, specie se si ha una conoscenza molto approfondita
di come sono dislocati e configurati.
L’obiettivo di questo articolo è quello di presentare la tematica attraverso un’analisi dettagliata dello stato dell’arte, illustrando quindi i
risultati ottenuti nell’ambito dell’attività di ricerca
svolta presso il laboratorio Be-Secure di Telecom
Italia Lab.
2. L’evoluzione dei sistemi di Intrusion Detection
Il 1987 si può considerare, a tutti gli effetti,
come l’anno in cui si inizia pubblicamente a parlare
delle tecnologie di rilevazione delle intrusioni; in
particolare, Il lavoro di D. Denning [1] si può consi-
NOTIZIARIO TECNICO TELECOM ITALIA › Anno 14 n. 1 - Giugno 2005
97
LAMASTRA › VIALE • Tecnologie innovative per il rilevamento e il contrasto degli attacchi informatici
derare l’articolo scientifico di riferimento su questo
importantissimo tema. Oggi, esistono numerosi
sistemi commerciali di Intrusion Detection e vari
progetti portati avanti dalla comunità Open Source,
tuttavia i problemi da risolvere sono ancora molti e
le opportunità di ricerca sono ancora significative.
Dal momento che gli IDS nascono come
“sistemi di protezione” per una infrastruttura limitata, è naturale che il loro ambito tradizionale sia
quello del data center o della Intranet aziendale. Lo
sviluppo recente delle reti informatiche, caratterizzato da un aumento pressoché esponenziale della
banda disponibile, dall’aumento della connettività
di tipo always on (disponibile anche per l’utenza
casalinga e SOHO) e dall’aumento della mobilità,
grazie all’uso delle tecnologie cellulari di nuova
generazione e wireless, comporta un sempre maggiore allargamento dei confini da proteggere. L’IDS
diviene dunque un componente strategico, che
deve operare su diversi livelli, partendo da quello
dell’utente inesperto, passando per l’utenza largebusiness di tipo tradizionale, fino ad arrivare a
coinvolgere direttamente il gestore dell’infrastruttura, e dunque i grossi operatori nazionali di telecomunicazioni.
I sistemi di rilevazione delle Intrusioni nascono
in un ambito prevalentemente militare, sebbene
siano strettamente correlati all’attività di alcuni
ricercatori universitari operanti nell’ambito della
sicurezza delle informazioni. Nel 1980, l’articolo di
J. Anderson [2] introduce il problema del monitoraggio dei sistemi informativi, in particolare di quelli
utilizzati per operazioni di tipo militare; poco dopo,
D. Denning inizia a lavorare sui sistemi di rilevazione delle intrusioni, anche grazie alla sponsorizzazione offerta da varie entità governative. Alla fine
degli anni Ottanta, molte strutture universitarie
hanno un progetto incentrato sul tema della rilevazione delle intrusioni; pensiamo al progetto
Haystack dell’Università di Davis in California [3],
ad IDES del Computer Science Laboratory dell’SRI
[4], ed al progetto IDIOT [5] del CERIAS dell’università di Purdue.
All’inizio degli anni Novanta, la rete Internet
esce dal contesto puramente accademico/militare
e si avvia a diventare la più grande infrastruttura
informatica del pianeta; all’inizio, come spesso
accade, le problematiche di sicurezza passano in
secondo piano rispetto a quelle dell’usabilità.
Inoltre, la maggior parte degli attacchi sono appannaggio di una elite esclusiva e non ancora alla portata di tutti. Si ritiene che il livello di sicurezza
offerto da un firewall sia tutto ciò che serve per
proteggere la propria infrastruttura. Nel frattempo,
seguendo un trend abbastanza tipico (almeno negli
USA), alcuni gruppi di ricerca che hanno prodotto i
prototipi più interessanti di sistemi per la rilevazione delle intrusioni, iniziano ad evolversi in
società start up. È il caso di Haystack Labs, che
commercializza l’omonimo prodotto, di NFR
(Network Flight Recorder, tuttora presente sul mercato), o di Network ICE, fondata da R. Graham
(oggi leader dell’area R&D di Internet Security
Services, ISS). Allo stesso tempo, gli attacchi
98
divengono più difficili da rilevare, più facili da
orchestrare e sempre più alla portata di tutti.
Diventa sempre più evidente che non si può ottenere la sicurezza usando un solo dispositivo e,
quindi, gli IDS iniziano ad diventare elementi sempre più essenziali di una infrastruttura di protezione
che ha il suo paradigma nella cosiddetta “Defense
in Depth” [6].
Contestualmente, anche la tecnologia IDS inizia
a svilupparsi seguendo altre strade: appaiono i
primi sistemi che integrano il firewall e l’IDS; la
linea di demarcazione che separa i sistemi di rilevazione da quelli di contromisura diventa più sottile, così da una parte i firewall iniziano ad integrare
meccanismi di ispezione del traffico sempre più
sofisticati mentre gli IDS imparano a rispondere
direttamente agli attacchi rilevati, trasformandosi
appunto in sistemi di prevenzione.
L’apparizione dei primi attacchi di tipo distribuito ed i drammatici effetti del numero crescente
di worm che si propagano sulla rete, fanno presagire le possibilità di un enorme black out informatico. Appaiono così i primi sistemi pensati esplicitamente per la protezione dell’infrastruttura, come i
router ed altri sistemi di interconnessione. Le
aziende più importanti nel contesto informatico,
quali Cisco, Symantec, Internet Security Systems
investono cifre considerevoli per acquisire la tecnologia di varie start up, allo scopo di offrire nella
propria offerta di sicurezza anche un sistema di
rilevazione delle intrusioni.
Gli anni successivi al 2000 sono caratterizzati
da una relativa stasi, almeno nel settore della
ricerca e sviluppo; la tecnologia dominante è rappresentata dai sistemi di Network-IDS, che operano analizzando in maniera estremamente ottimizzata i flussi di pacchetti che attraversano i perimetri aziendali. L’attenzione dei produttori si sposta
sulle problematiche di gestione, incentrate sulla
necessità di ridurre l’enorme mole di dati generata
da questi sistemi. Iniziano anche a diffondersi dei
dubbi sulla validità effettiva di questo tipo di tecnologie [7]; molte aziende comprano le sonde e le
installano, ma l’investimento necessario per mantenere un proprio gruppo interno che si occupi del
monitoraggio risulta proibitivo; spesso i costi per
un servizio di sicurezza gestito sono insostenibili, a
meno di non possedere una propria tecnologia di
IDS ed un proprio team per la messa a punto degli
aggiornamenti necessari al sistema per riconoscere nuovi attacchi.
Oggi, la tendenza prevalente dei produttori è
quella di proporre soluzioni di tipo All in One, che
integrino su una singola appliance, firewall, IDS ed
antivirus; questo tipo di meccanismi sposta il baricentro della tecnologia dai sistemi puramente passivi verso tecnologie di prevenzione IPS (Intrusion
Prevention System). Gli IPS, a differenza dei sensori che operano in modo passivo, divengono elementi attivi dell’infrastruttura, agendo direttamente
ai livelli 2 e 3 della pila protocollare, ed intervenendo direttamente sul transito dei pacchetti, con
un livello di analisi notevolmente più complesso
rispetto a quello dei firewall tradizionali. La loro
adozione è comunque contrastata dagli effetti collaterali connessi alla loro elevata complessità
(dovuta in moltissimi casi alla necessità di mantenere lo stato della sessione e di utilizzare algoritmi
più complicati rispetto a quelli tradizionalmente
impiegati in firewall ed antivirus) che potrebbe
ritorcersi contro l’infrastruttura stessa. Se infatti un
dispositivo di questo tipo dovesse per qualche
motivo diventare non operativo, l’intera sottorete
protetta rischierebbe di essere tagliata fuori.
Anche le tecnologie non strettamente basate
sull’approccio di tipo network based vivono una
fase difficile; strette infatti tra la morsa dei sistemi
antivirus e dei sempre più diffusi personal firewall, i
sistemi IDS di tipo host based stentano a diffondersi seriamente; la tendenza prevalente è quella
dell’approccio integrato firewall e IDS, specie nell’ambito workstation, dove è possibile sfruttare efficacemente il feedback diretto dell’utente. Molti
amministratori di sistema continuano a non vedere
di buon occhio l’installazione di un sistema IDS
host based, a causa del potenziale overhead computazionale che graverebbe sul sistema.
D’altra parte, i grossi gestori di infrastrutture,
hanno una necessità sempre maggiore di dotarsi di
sistemi specifici per proteggere le loro risorse tecnologiche; gli strumenti standard per la rilevazione
delle intrusioni male si adattano a questo compito,
in particolare in previsione della trasformazione
della rete telefonica tradizionale in una rete basata
sul protocollo IP. Uno degli aspetti più critici dal
punto di vista del gestore di rete è rappresentato
dalle problematiche correlate ai protocolli di routing. Sebbene alcuni protocolli integrino alcune
caratteristiche di sicurezza (come la possibilità di
autenticare in modo forte le transazioni fra i router)
o esistano delle soluzioni specifiche a livello dei
singoli apparati (come la possibilità di eseguire un
filtraggio sofisticato dei pacchetti), la maggior
parte degli amministratori di rete tende a non utilizzare questi meccanismi. I motivi sono molteplici:
spesso l’overhead computazionale è elevato (e
dunque si riduce la banda gestita dall’apparato),
oppure possono crearsi dei problemi di interoperabilità tra le soluzioni di differenti produttori o
ancora perché, come accade nei peer BGP, l’abilitazione e la configurazione delle funzionalità di
sicurezza richiede spesso la collaborazione di differenti operatori.
L’attività svolta a partire dal 2003 nel gruppo di
sicurezza informatica di Telecom Italia Lab (BeSecure) si concentra in particolare su due aspetti:
• L’evidenza che i sistemi tradizionali di IDS non
risultano sempre adeguati rispetto alle esigenze
dell’operatore di telecomunicazioni; infatti, questi sistemi sono tipicamente pensati per ambiti
di tipo Intranet/Corporate. L’infrastruttura di rete
di un grosso gestore di telecomunicazioni
richiede invece una grande flessibilità dovendo
gestire una molteplicità di tipologie di rete, a
partire dall’utenza domestica sotto forma di
ADSL, fino alle offerte per aziende con particolari requisiti di sicurezza, quali banche o sanità.
Oltre alla rete in senso classico, esiste poi la
dorsale di trasporto (backbone), che ha ovviamente delle caratteristiche e delle peculiarità
completamente differenti rispetto alle reti convenzionali; l’utilizzo di una soluzione standard è
quindi di difficile applicabilità.
• La constatazione che il controllo dei costi associati all’IDS è abbastanza problematico; al di là
dei costi iniziali delle sonde, gli IDS sono dei
sistemi che richiedono un continuo aggiornamento. Se si guarda il recente trend sul numero
medio di vulnerabilità nuove riscontrate per
ogni anno [8], si nota chiaramente un andamento abbastanza il linea con la legge di
Moore, la stessa legge che caratterizza in generale la diffusione di tutto ciò che è computing
technology. In più, oltre ai costi dovuti all’aggiornamento, è essenziale tener conto anche
dei costi di funzionamento, tutt’altro che affidabile, dei sistemi di rilevazione. È ben noto che il
numero di falsi allarmi generati dai sensori può
diventare elevatissimo, soprattutto in ambienti
estremamente eterogenei o laddove sia difficile
operare una configurazione molto fine del sensore. Ogni falso allarme genera un costo dovuto
alla necessità di gestire, seppure in minima
parte, l’evento ma ha un effetto molto più negativo e meno misurabile, correlato alla tendenza
da parte di chi esegue il monitoraggio, di considerare tutti gli eventi come falsi allarmi; e così,
paradossalmente, un sensore IDS finisce per
essere utilizzato spesso come uno strumento
per l’analisi a posteriori di un evento pericoloso
verificatosi sulla rete piuttosto che come il
primo campanello di allarme per rendersi conto
che sta accadendo qualcosa di negativo.
L’obiettivo dell’attività di ricerca svolta presso
Telecom Italia Lab nell’ultimo biennio è stato pertanto quello di ideare, ove possibile, una serie di
soluzioni tecnologiche focalizzate sulla rilevazione
delle intrusioni nei diversi domini concettuali: a
livello del singolo sistema (host), a livello delle reti
(wired e wireless), per arrivare fino al livello dei
sistemi di infrastruttura. L’attività di ricerca è stata
distribuita su tre progetti (EAGLE - Innovative
Intrusion Detection; RDS - Routing Detection
Security; WIDS - Wireless Intrusion Detection
System); sono stati ottenuti numerosi risultati interessanti, sia per ciò che riguarda gli aspetti innovativi (che ha dato luogo a numerose domande di
brevetto), sia per ciò che riguarda la prototipazione
dei sistemi (che ha visto la realizzazione di sistemi
realmente funzionanti, sia in laboratorio, sia
durante specifici test in campo).
3. Stato dell’arte e ricerca scientifica
I sistemi di Intrusion Detection non sono più
una tecnologia innovativa; anzi, da un certo punto
di vista, si possono considerare relativamente
maturi dal momento che da diversi anni numerosi
produttori offrono delle soluzioni commerciali.
Tuttavia, gli IDS richiedono una competenza sensibilmente superiore da parte del personale di
99
gestione rispetto ad altri apparati di sicurezza e
della questione, è bene osservare che il costo
una messa a punto non ottimale può generare
associato ad un IDS può essere considerato come
facilmente un numero elevato di eventi inutili. Una
la somma di quattro contributi sostanziali: costo
valutazione scorretta delle performance effettivadell’hardware necessario, costo delle licenze
mente necessarie potrebbe rendere il sistema incasoftware, costo degli aggiornamenti e costo assopace di rispondere in maniera adeguata. Inoltre,
ciato alla gestione del sistema (in altre parole, il
molto spesso è difficile capire cosa esattamente è
costo dovuto al fatto che il sistema va comunque
accaduto su un sistema attaccato, partendo dalle
monitorato da personale specializzato).
indicazioni fornite dall’IDS.
Dal punto di vista scientifico, trattandosi di una
Tutte queste problematiche d’uso hanno un
tecnologia non recentissima, è opportuno basarsi
notevole impatto pratico, oltre che economico, che
su un approccio tassonomico per descrivere
è fortemente amplificato nel contesto di grandi
meglio tutti gli aspetti significativi relativi ad un
installazioni. È importante capire come valutare in
sistema di IDS. Come vedremo, la classificazione
maniera appropriata almeno gli aspetti essenziali
adottata risente notevolmente del fatto che, storiche caratterizzano un IDS, sia per eseguire una
camente, i primi IDS sono stati sistemi di tipo
scelta corretta sulla tecnologia da impiegare, sia
network based; tuttavia, la classificazione è suffiper valutare fino in fondo quali sono i vantaggi che
cientemente generale da adattarsi anche ai sistemi
un certo meccanismo può effettivamente fornire.
di tipo host ed a quelli pensati specificatamente
Le metriche più importanti per valutare un IDS
per la protezione delle infrastrutture.
sono tre:
La classificazione a cui facciamo riferimento è
1) Numero di “Falsi Positivi” (#FP): un falso posiquella del CIDF (Common Intrusion Detection
tivo è un evento che l’IDS ritiene significativo e
Framework) [9]; questo risultato è uno dei frutti delche invece non ha alcun effetto reale sul
l ’atti vi tà i n i zi ata da T. L u n t al l ’In fo rm a t io n
sistema. Potrebbe ad esempio derivare dall’iTechnology Office della DARPA e sviluppatasi poi
dentificazione di un tentativo di attacco verso
come sforzo mirante a definire una sorta di archiuna macchina che non è vulnerabile, dal fatto
tettura standard per l’interoperabilità degli IDS.
che il pacchetto pericoloso potrebbe, per qualIn accordo a questa classificazione, un IDS è
che altro motivo, non raggiungere mai il sistema
composto da 4 elementi essenziali, come illustrato
bersaglio, o più semplicemente da un vero e
in figura 1:
proprio errore di rilevazione;
• E-Box: si occupa di raccogliere gli eventi rile2) Numero di “Falsi Negativi” (#FN): un falso negavanti dal sistema sotto analisi; questo elemento
tivo è un evento dannoso che il sistema non rieè il sensore vero e proprio e si interfaccia con il
sce ad identificare. Ciò solitamente accade persistema in maniera solitamente passiva per catché viene utilizzato un attacco che il sistema
turare tutte le informazioni significative per l’anon conosce, oppure perché l’attacco viene
nalisi;
offuscato o mascherato in qualche modo; come
• A-Box: è il cuore del sistema, che effettua l’anavedremo, la frammentazione è uno dei meccanilisi e stabilisce se effettivamente l’evento è un
smi “classici” per aggirare un IDS.
attacco o meno;
3) Capacità di carico: a differenza dei due fattori
• D-Box: è il sistema di memorizzazione, che ha
indicati in precedenza, correlati prevalentel’obiettivo di mantener traccia di ciò che è
mente all’efficacia di funzionamento del
accaduto;
sistema, la capacità di carico è una
misura dell’efficienza; in pratica, è una
valutazione del massimo carico che il
sistema può sostenere mantenendo la
capacità di eseguire l’analisi. Nel conGeneratore di
contromisure
testo dei sistemi network, si può
misurare sia in termini di byte/s, sia in
Reazione
Interprete
Memorizzazione
termini di pacchetti/s; di solito, è
(R-box)
di eventi
eventi
importante poter disporre di entrambi
Memorizzazione
Analisi
i valori per avere una valutazione
(D-box)
(A-box)
completa del sistema. Nel contesto
dei sistemi host-based, si misurano
Eventi
(E-box)
tipicamente le risorse sottratte al
sistema ospite; è evidente che un IDS
host-based che sottrae più del 50%
delle risorse di calcolo e/o memoria
Flusso dati
disponibili al sistema ospite ha delle
pessime performance.
Fonte: GDF
Ovviamente,
in
un
ambito
strategico/commerciale, la metrica correlata ai costi è importante quanto quella di
tipo più squisitamente tecnologico; seb- FIGURA 1› Architettura generica di un sistema di IDS.
bene questo articolo non entri nel merito
100
• R-Box: è il sistema di reazione, che può limitarsi
ad emettere un allarme per il personale di monitoraggio, oppure eseguire automaticamente una
contromisura appropriata per l’attacco identificato.
In base a questo schema, è possibile classificare un IDS in base ai quattro meccanismi essenziali, correlati appunto alle “Box” che compongono
lo schema. Ad esempio, il meccanismo di raccolta
degli eventi (la E-Box) può essere tipicamente la
re te , i l s i n g olo host, un siste ma i bri do
(host/network) o una componente rappresentata da
un dispositivo specifico.
Ovviamente, per ciò che riguarda le metodologie di analisi, esiste la più ampia diversificazione,
sebbene si possano individuare due grandi paradigmi: “Misuse Detection” e “Anomaly Detection”,
che sono descritti in dettaglio nel riquadro di
approfondimento “Misure Detection & Anomaly
Detection”. Nelle fasi iniziali della ricerca, sono
sorti svariati progetti universitari che hanno
approfondito l’utilizzo di una particolare tecnica
algoritmica; abbiamo così IDS che lavorano con il
classico meccanismo del pattern matching,
oppure sistemi che lavorano utilizzando algoritmi
di tipo rete neurale, sistema esperto, genetico e
statistico.
I meccanismi di reazione possono essere
essenzialmente di due tipi: passivi, che si limitano
ad inoltrare un avviso al personale che si occupa
della gestione, o attivi che invece eseguono autonomamente una qualche contromisura. Sebbene
l’adozione dei meccanismi di reazione attivi abbia
portato allo sviluppo dei cosiddetti sistemi di prevenzione delle intrusioni (IPS), non bisogna dimen-
MISUSE DETECTION &
ANOMALY DETECTION
Con la definizione di “Misuse
Detection” si intende la tecnica di
rilevamento delle intrusioni volta a
modellare il comportamento improprio o illecito del sistema [10] attraverso la definizione di uno o più
schemi o pattern. Un pattern rappresenta, quindi, una classificazione dell’attacco in termini di informazioni a
priori che permettono di individuare e
classificare ciò che è “malevolo”. La
tecnica specifica più comune nell’ambito dei sistemi di tipo network è il
pattern matching, che è in un certo
senso il sistema di Misuse Detection
per eccellenza. Altri approcci basati
sul paradigma Misuse Detection
ticare che un sistema di questo genere rischia di
trasformarsi in un’arma a doppio taglio, nel caso in
cui le contromisure scattino a fronte di un falso
positivo che è invece associato ad un pacchetto
perfettamente lecito che somiglia apparentemente
ad un pacchetto pericoloso.
Per ciò che riguarda il supporto di memorizzazione, in generale si possono avere sia sistemi che
utilizzano un’infrastruttura classica basata su un
data base relazionale, sia sistemi più sofisticati,
spesso poi evolutisi come prodotti indipendenti,
che sono utilizzati come veri e propri sistemi di
raccolta e correlazione. Questo genere di sistemi
aggregano eventi provenienti da un numero estremamente elevato di sorgenti, spesso molto diverse
l’una dall’altra. Gli eventi sono prima trasformati in
una rappresentazione “normalizzata” e, quindi,
sono confrontati con una serie di regole, spesso
scritte in qualche linguaggio di specifica più o
meno formale, per evidenziare macro-anomalie,
comportamenti irregolari o, in generale, qualsiasi
evento di interesse che possa essere descritto
sfruttando il linguaggio fornito.
L’approccio senza dubbio più diffuso nell’ambito dei sistemi IDS è rappresentato dall’uso di
sistemi di tipo network con una logica basata sul
pattern matching. Questo approccio caratterizza
quasi tutte le soluzioni commerciali più diffuse
(ISS Network Sensor, SourceFire, Enterasys
Dragon) e molti sistemi open source sia nuovi
(Snort [11]) che vecchi (Shadow [12], NID [13],
IDIOT [5]). Nel caso specifico, parlando di pattern
matching (si veda il riquadro “Modelli formali per
il problema del Pattern Matching”), si intende una
tecnica di individuazione di una o più sequenze
includono l’uso dei sistemi esperti e
dei sistemi basati su modelli formali e
semi-formali che cercano di riconoscere l’insieme di transizioni eseguito
da un sistema per arrivare alla condizione di bersaglio.
Il paradigma “Anomaly Detection” si
basa, invece, su di un principio duale
rispetto a quello descritto in precedenza: l'IDS non cerca di individuare
gli schemi di attacchi ben noti, ma
eventuali anomalie nel comportamento dell'oggetto monitorato (rete,
host, applicativo, … .). Di conseguenza, la costruzione di un rilevatore
di questo tipo inizia con un'accurata
definizione del modello normale di
comportamento del sistema da monitorare. In seguito vengono definite le
regole che governano il rilevamento
vero e proprio: fondamentalmente,
per ciascuna variabile del modello
viene indicato l’intervallo di variazione
(spesso definito deviazione) che rappresenta la soglia tra una situazione
normale ed una che non lo è. I sistemi
di tipo Anomaly Detection non hanno
bisogno della descrizione di ogni singolo attacco ed in più possono individuare potenzialmente molti più attacchi al sistema monitorato, siano essi
noti o meno. Ovviamente tale capacità
rappresenta un vantaggio rispetto ai
sistemi di Misuse Detection, che
necessitano di aggiornamenti continui
del database contenente la descrizione degli attacchi. Lo svantaggio
principale del sistema è rappresentato dalla notevole difficoltà della sua
messa a punto. Infatti, questi tipi di
sistemi reagiscono tipicamente a
qualsiasi cosa che non sia stata marcata come ammissibile e dunque producono molti più falsi positivi rispetto
ai sistemi di tipo Misuse. Inoltre, un
ulteriore problema può essere anche
rappresentato dalla minore possibilità
di fornire informazioni precise sul tipo
di attacco corrispondente ad un'anomalia rilevata.
101
Modelli formali per il
problema del
PATTERN MATCHING
Il problema del pattern matching [14].
è uno dei grandi problemi classici dell’informatica teorica. La letteratura
disponibile è davvero moltissima, così
come gli ambiti applicativi; in particolare nel contesto della sicurezza dei
sistemi informativi, pensiamo agli IDS
ed agli antivirus; fra gli altri campi
applicativi, citiamo invece quello dell’analisi delle sequenze di geni, che di
recente ha creato un rinnovato interesse in questo particolare ambito di
ricerca.
Di seguito descriviamo brevemente i
quattro approcci che consideriamo
rappresentativi per ciò che riguarda il
problema del pattern matching:
• Regular Expression (RE): questa
classe di algoritmi ricerca sul
•
•
flusso di byte in input le cosiddette “espressioni regolari”. È una
ricerca di pattern di tipo lineare
con una semantica ben nota (le
RE sono ampiamente utilizzate in
moltissimi contesti applicativi dell’informatica); il vantaggio principale sta nella relativa semplicità
con cui è possibile scrivere le
regole.
Deterministic Context Free
Grammars (CFG): gli algoritmi che
appartengono a questa categoria
sono caratterizzati da una grammatica costituita da simboli semplici (cioè che possono assumere
un unico valore deterministico) a
cui vengono applicate regole
semantiche. L’output è un albero
simile ad un parse-tree costruito
dal parser di un compilatore che
rappresenta una signature.
Attribute Grammars: gli algoritmi
che appartengono a questa categoria offrono un potente meccanismo di rappresentazione delle
signature con lo svantaggio che
non forniscono un modello grafico
ben specificate e contigue di simboli, dette
signature, all’interno di un flusso continuo di simboli. Tipicamente, nella stragrande maggioranza
dei casi, i simboli sono essenzialmente byte, ma
possono anche essere caratteri unicode, word a
32 bit o altro.
Esistono diversi modelli formali per inquadrare il problema del pattern matching; in pratica, nella stragrande maggioranza dei casi vengono utilizzate le espressioni regolari per la loro
immediatezza d’uso ed anche perché esistono
ottimi algoritmi applicabili al caso in cui si voglia
eseguire una ricerca simultanea di numerose
signature su un singolo flusso di dati. Oltre tutto,
non bisogna dimenticarsi che, oltre a disporre di
un buon sistema per l’analisi delle regole, è
altresì necessario riuscire a codificare i tratti
caratteristici di un attacco in una signature specifica. Pertanto, l’uso di un approccio più semplice (anche se meno potente) è probabilmente
preferibile, vista la rapidità con cui è necessario
scrivere una signature dopo che l’attacco viene
reso noto.
Negli ultimi anni lo sforzo di sviluppo degli IDS
tradizionali in ambito open source si è concentrato attorno al progetto Snort [11] di M. Roesch,
che è rapidamente diventato uno degli strumenti
di riferimento di tutta la comunità della ICT security. Come molti progetti open source di successo, Snort ha generato una community molto
attiva che continua lo sviluppo del sistema.
Inoltre, la possibilità di disporre di un sistema
102
•
facilmente interpretabile. Una
Attribute Grammar può essere
vista come una CFG in cui i simboli possono assumere più valori,
chiamati per l’appunto “attributi”.
L’individuazione di un attributo
per un simbolo è legato all’azione
che determina l’elezione di quel
simbolo. Quindi, ad ogni passo
dell’algoritmo di pattern matching, un simbolo è caratterizzato
dalla coppia (azione, attributo).
Colored Petri Nets: le Reti di Petri
sono uno dei modelli formali più
noti nel contesto dell’informatica
teorica. Tipicamente, vengono
usate per modellare problemi di
concorrenza e per il riconoscimento di specifiche sequenze di
eventi. Gli algoritmi che rientrano
in questa categoria permettono
una rappresentazione delle signature in termini di grafi con la possibilità di inserimento di informazioni legate alla semantica di un
attacco; la loro potenza espressiva è molto simile a quella delle
Attribute Grammar.
aperto, consente di provare in maniera molto
rapida l’efficacia di un nuovo algoritmo o di un
meccanismo di analisi differente da quello usuale,
permettendo di confrontare in maniera immediata
e trasparente l’effetto in termini di efficacia ed
efficienza.
U n o d e i r i s u l t a t i p i ù i n t e re s s a n t i e m e r s i
durante l’evoluzione del progetto è l’ottimizzazione dell’algoritmo di pattern matching nel contesto specifico degli IDS. Le prime implementazioni del motore di pattern matching sono basate
sull’algoritmo di Boyer-Moore [15]; questo algoritmo è sostanzialmente un algoritmo euristico
che nella maggioranza dei casi è computazionalmente più efficiente dell’algoritmo ottimo. Il
numero crescente di signature ha di recente condotto all’adozione dell’algoritmo di Aho-Corasic
[16] che è pensato per l’analisi simultanea di
numerose signature in un colpo solo.
L’approccio basato sull’utilizzo di modelli formali (descritti sia per mezzo di regole, sia per
mezzo di modelli basati sulle transizioni di stato) è
stato caratterizzato da un discreto successo in
ambito accademico, ma si è poi scontrato con la
difficoltà pratica di codificare gli attacchi per
mezzo degli strumenti forniti. In particolare, STAT
[17,18] dell’Università della California di S. Barbara
è uno degli esempi più interessanti: si sfrutta una
descrizione astratta del sistema in termini di
modello ridotto dello stato e si cercano di modellare gli attacchi al sistema come insiemi di transizioni su tale modello.
Sebbene l’approccio basato sul paradigma del
“Misuse Detection” risulti prevalente, esistono
comunque dei sistemi implementati con la logica
dell’Anomaly Detection che vale la pena di citare.
Andare alla ricerca di anomalie sul sistema monitorato richiede di misurare una variazione di qualche
proprietà dell’oggetto in esame. Bisogna cioè
avere una indicazione misurabile di ciò che si
intende per “comportamento ammissibile” ed una
soglia al di là della quale è lecito segnalare un
“comportamento sospetto”. Gli approcci si possono sostanzialmente ricondurre a due filoni principali: Characteristic Deviation e Statistical Deviation.
Una deviazione caratteristica offre una misura qualitativa (ad esempio, “normalmente l'utente root
non utilizza il servizio ftp”), mentre una deviazioni
statistica è una misura quantitativa osservabile (ad
esempio, “il traffico icmp della rete monitorata non
supera normalmente il 15% del traffico totale”).
Per quanto riguarda la natura delle informazioni
necessarie per effettuare le misure, i sistemi di tipo
Anomaly Detection si possono così classificare:
• Behavioral Based: si tratta di sistemi che misurano deviazioni di tipo caratteristico (eventualmente integrandole con alcune misure statistiche); tali sistemi si basano sulla creazione di un
profilo che caratterizza il comportamento normale dell'oggetto monitorato. Normalmente,
questi sistemi lavorano in due distinte modalità;
all’inizio, durante la fase di addestramento (training), il sistema campiona l’oggetto monitorato
per definire il comportamento ammissibile; è
essenziale che il sistema in questa fase venga
protetto da qualsiasi attacco; in una seconda
fase, il sistema sfrutta ciò che ha appreso (ed
eventualmente rimaneggiato in modo opportuno) per identificare gli scostamenti dalla
norma. La tecnologia soggiacente a tali sistemi
è tipicamente basata su reti neurali, sistemi
fuzzy o emulazione del sistema immunitario.
• Traffic Pattern: si tratta di sistemi molto tipici
nell’ambito network/infrastruttura; lavorano prevalentemente sfruttando modelli di tipo statistico, valutando la distribuzione temporale e
spaziale del traffico, estrapolandone le caratteristiche significative (es. numero di connessioni
per unità di tempo, numero di pacchetti scambiati, ... .); questo tipo di sistemi trova un suo
ambito applicativo naturale nel rilevare gli attacchi di tipo DDoS (Distributed Denial of
Services), che mirano ad esaurire le risorse
disponibili convogliando in modo ben coordinato un enorme numero di richieste verso il
sistema da attaccare. Solitamente, i profili di
traffico durante queste condizioni particolari differiscono sensibilmente dalla situazione standard; pertanto è possibile identificare il comportamento anomalo fin dai primissimi istanti.
Il paradigma della cosiddetta “Immunologia
Computazionale” è uno degli approcci che ha
riscosso il maggiore successo nell’ambito della
ricerca sugli IDS di tipo Anomaly Detection.
L’ispirazione è chiaramente di matrice biologica; è
infatti ben noto che i sistemi biologici sono in
grado di riconoscere una miriade di attacchi, anche
strutturalmente molto differenti, e di mettere in
piedi una adeguata risposta proprio per mezzo del
sistema immunitario. Ovviamente, il reale funzionamento del sistema immunitario di un organismo
superiore è estremamente complesso, essendo in
grado di riconoscere un “attacco” già noto (nei
confronti del quale la reazione è mirata e solitamente efficace), oppure di identificare attacchi
sconosciuti, proprio in base ad un meccanismo
che è effettivamente simile, a livello di paradigma,
all’Anomaly Detection. L'idea di applicare i principi
che governano il funzionamento dei sistemi immunitari naturali alla protezione dei sistemi di calcolo,
è stata esposta nel 1994 dal gruppo di ricerca di S.
Forrest dell'Università di New Mexico [19,20].
L'obiettivo del progetto è quello di costruire un
sistema immunitario artificiale per i computer [21].
Gli IDS realizzati nell'ambito del progetto coprono
praticamente tutti i contesti applicativi tradizionali:
Application based, User based, Host based e
Network based. Il principio comune implementato
da tali sistemi è definito “Negative Selection”, un
algoritmo che realizza appunto la distinzione tra ciò
che è legittimo (siano essi utenti, azioni sul sistema
operativo, connessioni di rete) e ciò che non lo è.
L’approccio basato sull’Anomaly Detection di
tipo “Traffic Pattern” è dominante nel contesto
della sicurezza backbone. In questo settore la
ricerca è molto meno matura rispetto al contesto
più tipico dell’Intrusion Detection ed i problemi che
sono stati approfonditi sono fondamentalmente
due: da una parte il tentativo di individuare e bloccare i DDoS che viene affrontato prevalentemente
con tecniche di tipo statistico; dall’altra abbiamo
l’analisi focalizzata sui protocolli di routing. I protocolli di routing, avendo la funzione di distribuire le
informazioni relative alla topologia della rete, permettono ai pacchetti di essere inoltrati correttamente verso la destinazione finale. In assenza di
informazioni di routing accurate, o in presenza di
informazioni false, la trasmissione dei pacchetti
attraverso la rete risulta inefficiente o addirittura
impossibile. Questo fatto è di per se problematico,
in quanto un eventuale attacco all’infrastruttura di
routing che regola il normale funzionamento del
backbone, potrebbe avere delle conseguenze
molto gravi poiché l’attacco avrebbe pesanti effetti
anche sulle altre reti, interconnesse al backbone,
che si troverebbero ad essere completamente o in
parte isolate dal resto della rete.
Lo stato dell’arte in questo specifico campo
non vede, per il momento, emergere una soluzione
di riferimento, anche se da qualche tempo i fornitori di soluzioni di sicurezza hanno reso disponibili
alcune soluzioni che si propongono di rispondere
al problema della sicurezza del backbone. Queste
soluzioni, in teoria, si propongono di lavorare non
solo sui livelli protocollari tipici degli end-point (dal
trasporto in su), ma anche a livello di internetworking (dunque, essenzialmente sul livello 3).
In pratica però, molte delle soluzioni disponibili non
intervengono attivamente, interfacciandosi con i
sistemi di routing utilizzati nel contesto da control-
103
lare, ma utilizzano informazioni derivate dagli
apparati tramite tecniche standard (prelievo di
variabili SNMP dalle MIB dedicate agli aspetti di
routing) oppure utilizzando altre sorgenti di informazioni (NetFlow). L’approccio classico della
Network Intrusion Detection è difficilmente applicabile in questo contesto, dal momento che l’utilizzo
del pattern matching non permette di identificare
immediatamente una condizione di funzionamento
anomala. Attualmente, alcuni produttori specifici (in
particolare Arbor Network e Riverhead) offrono
soluzioni puntuali per alcuni problemi, quali ad
esempio il contrasto degli attacchi DistributedDoS, mentre i maggiori produttori (in particolare
Cisco e Juniper) stanno portando avanti delle interessanti iniziative di ricerca e sviluppo.
Con il discorso sul backbone, concludiamo la
panoramica sullo stato dell’arte. In questo articolo,
non abbiamo la pretesa di essere completamente
esaurienti. Abbiamo, infatti, ritenuto opportuno
limitare la descrizione alle soluzioni che, a nostro
avviso, risultano maggiormente interessanti. Il quadro fornito dovrebbe essere più che sufficiente per
inquadrare gli aspetti rilevanti delle tecnologie più
diffuse relative al contesto dell’Intrusion Detection.
4. Dalla tecnologia ai prodotti:
Intranet e Backbone IDS
A partire dalla fine degli anni Novanta, molte
delle soluzioni elaborate sia in ambito militare, sia
nel contesto accademico iniziano ad essere implementate direttamente in contesti commerciali,
seguendo la più classica logica dei prodotti di
ISS Proventia
e
Sourcefire RNATM
TM
ISS (Internet Security System) propone con Proventia la tecnologia
Fusion per la riduzione dei falsi positivi. Fusion correla i risultati dell’analisi del Vulnerability Assessment con
le segnalazioni del sensore di
Intrusion Detection per determinare
l’impatto effettivo dell’attacco sul
sistema bersaglio. Il sistema esegue
periodicamente una scansione delle
rete che permette di identificare in
modo puntuale le eventuali vulnerabilità presenti. Quando il sensore identifica un attacco, l’informazione viene
incrociata con i risultati della scansione più recente e se la macchina
104
sicurezza. Chiaramente, la necessità di offrire un
prodotto completo richiede di prendere in considerazione altri aspetti che non sono necessariamente
legati alle problematiche della rilevazione in senso
stretto. In ogni caso, il passaggio dal laboratorio
all’ambiente di esercizio porta ad evidenziare molti
problemi ed anche alcuni limiti strutturali delle
soluzioni identificate in ambito di ricerca.
La soluzione largamente più diffusa nell’ambito
IDS è rappresentata da un sensore di tipo networkbased che lavora essenzialmente con un paradigma di tipo misure detection, in particolare con
una logica di tipo pattern matching. Tutti i più
importanti prodotti commerciali (ISS ProventiaTM,
Sourcefire TM , Dragon Enterasys TM , o Symantec
Manhunt TM ) implementano una logica di questo
genere, affiancandola poi con varie altre tecnologie
specifiche che mirano a ridurre l’incidenza dei falsi
positivi e dei falsi negativi (si veda il riquadro “ISS
ProventiaTM e Sourcefire RNATM).
Il problema dei falsi negativi è sicuramente
quello più drammatico nel contesto degli IDS. Un
falso negativo è spesso associato alla possibilità di
modificare in modo più o meno arbitrario la forma
dell’attacco senza variarne la sostanza. Un’intera
classe di attacchi basati su questa problematica è
rappresentata dall’utilizzo della tecnica di frammentazione. In pratica, spezzettando in pacchetti
molto piccoli il payload applicativo che contiene
l’attacco, si impedisce al sistema di pattern matching di funzionare in modo efficace. Un approccio
più sottile consiste nell’invio di frammenti che si
sovrappongono in modo parziale; dal momento
che il criterio con cui vengono trattati frammenti
parzialmente sovrapposti non è univoco, è possi-
risulta vulnerabile, viene emesso un
allarme di alta priorità; altrimenti, l’evento viene conservato nel log, ma
l’operatore non viene coinvolto direttamente.
Il vantaggio principale della tecnologia è quello di ridurre l’incidenza dei
falsi positivi; tuttavia, i problemi principali di questo approccio sono: la
necessità di eseguire delle continue
scansioni sulla rete monitorata e il
potenziale disallineamento che può
crearsi tra la configurazione reale
della rete e quella vista da Fusion
(perché, per esempio, è stata
aggiunta una patch e non è ancora
stata rieseguita la scansone).
Sourcefire, l’azienda di M. Roesch che
commercializza Snort, propone un
approccio alternativo, denominato
RNA (Real-time Network Awareness).
Il vantaggio prevalente rispetto alla
soluzione di ISS è quello di essere
appunto real time nella rilevazione.
Infatti, non appena un sistema viene
modificato o aggiunto alla rete da
monitorare, sfruttando una serie di
tecniche di analisi passiva dei pacchetti, RNA è in grado di identificare
numerose caratteristiche del sistema,
e dunque di associare agli eventi
generati dal sensore una indicazione
relativa al potenziale impatto dell’evento. Ad esempio, se si identifica un
attacco per un server Linux diretto ad
una macchina Windows (o viceversa),
RNA è in grado di disattivare l’allarme,
che è sicuramente un falso positivo.
La limitazione principale di questo
approccio è legata al fatto che non è
possibile rilevare tutti i falsi positivi
sfruttando un meccanismo che sia
solamente passivo. In effetti, RNA
prevede comunque la possibilità di
inserire nella base di conoscenze del
sistema anche informazioni ricavate
per mezzo di altri strumenti (come ad
esempio, quelli di Vulnerability
Assessment).
bile che il sensore ed il sistema bersaglio vedano
due distinti contenuti e dunque l’effetto netto è
quello di un errata interpretazione di ciò che sta
accadendo; la figura 2 mostra graficamente un
esempio di ciò che può accadere in questo caso.
S
H
E
L
F
A
K
C
O
D
L
E
Frammenti duplicati
e sovrapposti;
il risultato del
riassemblaggio
dipende dal
sistema operativo.
FIGURA 2› Il problema della ricostruzione del payload a partire da fram-
menti sovrapposti.
Un’altra classe di attacchi sempre basati su
questo stesso paradigma è rappresentata dalla
cosiddetta “denormalizzazione”; in pratica, alcuni
protocolli supportano diverse forme di codifica per
il contenuto applicativo. Sfruttando codifiche alternative, è possibile aggirare le specifiche signature
per un attacco; inoltre, è impossibile pensare di
inserire tutte le forme differenti con cui può essere
codificato un attacco; chiaramente, l’approccio
ideale consiste nel riportare il contenuto del pacchetto in una forma standard prima di eseguire il
pattern matching.
Per evitare di prolungare troppo la descrizione,
si rimanda al lavoro di Ptacek et al. [22] per un
approfondimento sugli attacchi che è possibile
effettuare verso un IDS. Oggi, la maggior parte dei
La soluzione
Arbor Networks
PeakFlow PlatformTM è la soluzione di
Arbor Networks per l’analisi degli
attacchi al backbone. Si tratta di
un’architettura di raccolta ed analisi
dei dati di traffico secondo un paradigma di tipo Anomaly Detection. I
dati sono raccolti sia a partire dalle
informazioni generate dagli apparati
di rete, esportate per mezzo del protocollo NetFlow, sia analizzando direttamente il traffico rilevato. La piattaforma è basata su due sistemi:
• Peakflow X è la soluzione orien-
•
sistemi commerciali utilizza le tecniche di analisi
del protocollo per gestire i problemi correlati a
frammentazione, denormalizzazione ed offuscamento. Queste tecniche non sono di per sé innovative, tuttavia lo sforzo richiesto per realizzare un
sistema robusto ed efficiente è notevole e può
essere affrontato solo in sistemi che vengono
gestiti con la logica del prodotto.
L’altro problema tradizionale degli IDS è l’enorme numero di allarmi che questi dispositivi tendono a generare soprattutto quando non sono ben
configurati. Anche in questo caso, le tecniche di
analisi del protocollo possono ridurre notevolmente
i falsi positivi, eliminando tutti quegli allarmi che
corrispondono a situazioni che non sono effettivamente ammissibili. Ad esempio, un pacchetto
sospetto su una connessione TCP che però non ha
ancora completato il 3-way handshake è chiaramente un falso allarme. Il pacchetto non sarà mai
processato dal livello applicativo, e dunque l’attacco è destinato all’insuccesso.
Il problema della gestione dei falsi positivi è
stato affrontato in vari modi dai diversi produttori.
In molti casi, la tendenza è quella di andare verso
sistemi multilivello che correlino le informazioni
generate dall’IDS con quelle ottenute da altre fonti,
tipicamente i sistemi di scansione delle vulnerabilità o, in generale, altri sistemi che permettono di
eseguire un assessment dei sistemi che si intende
proteggere. Rimandiamo ai riquadri “La soluzione
Arbor Networks” e “La soluzione Riverhead” per un
approfondimento sugli approcci utilizzati in due
delle soluzioni più diffuse in ambito IDS.
Nel contesto backbone, gli approcci più tipici
sono quelli di tipo Anomaly Detection; le tecnologie
più importanti sono quelle correlate all’analisi statistica del traffico. Il problema essenziale nella rilevazione degli attacchi di tipo Distributed Denial of
tata alle reti di grandi aziende ed
ha l’obiettivo di aiutare gli amministratori di rete a risolvere i problemi derivanti dalle minacce alla
sicurezza nei confronti delle
risorse interne. La soluzione si
appoggia sul modello comportamentale della rete che viene
costruito ed aggiornato in real
time; questo modello permette
agli amministratori di tracciare il
comportamento fino al livello del
singolo host, analizzando come e
con chi sono state instaurate le
connessioni. Le informazioni sono
un utile strumento per identificare
sia le fonti di attacco, sia le
misure per rinforzare il perimetro
della rete;
Peakflow SP è la soluzione dedicata ai Service Provider il cui prin-
cipio di funzionamento è molto
simile a quello della soluzione precedente, anche se focalizzato
essenzialmente sul monitoraggio
statistico del traffico. La soluzione
in realtà è formata da tre elementi:
- Infrastructure Security, che si
occupa di individuare anomalie a livello di rete;
- Traffic and Routing, che
costruisce il modello di traffico della rete controllata abilitando gli amministratori ad
intervenire in funzione di
variazioni significative del
modello;
- Managed services, che permette all’operatore di erogare
un servizio di Dos/DDos prevention ed altri servizi di sicurezza ai propri clienti.
105
La soluzione
Riverhead
La società israeliana RiverHead
Networks, acquisita nel 2004 da
Cisco, è stata la prima a rilasciare sul
mercato una tecnologia in grado di
identificare e rimuovere in real-time
gli attacchi DoS/DDoS senza andare
ad impattare sul traffico legittimo. La
soluzione prevede la presenza di due
differenti sistemi:
• Detector: funziona, in sostanza,
come un classificatore del traffico
ed è in grado di identificare la presenza di schemi di attacco;
• Guard: è l’oggetto che si occupa
di ripulire il traffico, lavorando sui
vari flussi in base alle indicazioni
che gli provengono dal Detector.
Il funzionamento del sistema ideato
da Riverhead prevede che quando il
Detector identifica un potenziale
attacco, venga inviato un allarme alla
Guard, affinché questa inizi un processo di ridirezione del solo flusso
sospetto, mentre il resto del traffico
rimane inalterato. Il Detector è
comunque un componente opzionale
dell’architettura, dal momento che la
Guard può ricevere notifiche anche da
altre sorgenti.
La ridirezione del traffico avviene
sfruttando alcune particolari meccanismi di routing; il traffico viene quindi
elaborato dalla Guard per mezzo di
una serie di controlli basati sull’architettura brevettata MVP (Multi
Verification Process). Questa prevede
Service è rappresentato proprio dalla difficoltà nel
distinguere situazioni di carico elevato dovute ad
una particolare condizione di servizio (ad esempio,
si pensi a ciò che accade quando si cerca di acquistare un biglietto per un grande concerto e l’intervallo temporale per eseguire la richiesta è molto
ridotto: il numero enorme di richieste in un ridotto
intervallo di tempo somiglia drasticamente ad un
SYN-flood distribuito).
Uno dei problemi essenziali in quest’ambito è
rappresentato dalla necessità di raccogliere un
numero elevatissimo di informazioni rilevanti ai
flussi. È evidente che se ogni apparato di rete
esporta queste informazioni in modo proprietario,
diventa molto più complesso riuscire a far funzionare un qualsiasi sistema di monitoraggio, che è
uno dei componenti essenziali di qualsiasi architettura mirante a risolvere questo tipo di problemi.
L’IETF (Internet Engineering Task Force) si è pertanto mossa in questa direzione ed ha fatto sua
[22] una specifica di Cisco, denominata NetFlow,
che consente ai vari amministratori di rete di ottenere, in un formato standard, una serie di informazioni sui flussi dati che attraversano la rete.
NetFlow nasce in primis per supportare le attività
di raccolta dei dati di traffico per la tariffazione, ma
le informazioni che esso genera possono essere
usate in modo naturale per l’analisi dei problemi di
sicurezza. Oggi, la maggior parte degli apparati
(Enterasys, Foundry Networks, Extreme Networks,
Juniper, Riverstone, InMon Networks) integrano
questo protocollo; inoltre esistono vari applicativi
in grado di interpretare ed analizzare queste informazioni; nello specifico, citiamo PeakflowTM (sviluppato da Arbor Networks) ed NTop, un prodotto
open-source sviluppato presso il centro SERRA
dell’Università di Pisa. NetFlow è in grado di catturare un ricco insieme di dati statistici. Queste statistiche includono tra l’altro il protocollo, le porte, il
106
differenti livelli di intervento, che
includono operazioni di limitazione
della banda, di terminazione completa
di una connessione, ed altre ancora;
l’azione appropriata viene selezionata
in base al livello di pericolosità associato dal processo di identificazione.
Il traffico che supera questo processo
di “ripulitura”, e che dunque viene
ritenuto legittimo, viene reintrodotto
in rete affinché possa raggiungere la
corretta destinazione.
La soluzione di Riverhead, ora Cisco,
è sicuramente indicata per la protezione di un backbone da attacchi
massivi che potrebbero minare il funzionamento dell’intera rete, ma risulta
appropriata anche per grandi reti
enterprise o data center.
tipo di servizio che combinate insieme forniscono,
come detto in precedenza, una base informativa
utile per una vasta gamma di servizi.
L’entità misurata da NetFlow è il “flusso”, identificato come un insieme di pacchetti tra una sorgente ed una destinazione che vengono identificati
dai seguenti campi:
• Source IP Address;
• Destination IP Address;
• Source Port Number;
• Destination Port Number;
• Protocol Type;
• Type of Service;
• Input Interface.
Le informazioni generate da NetFlow sono trasmesse tramite pacchetti UDP; il protocollo ha
subito varie evoluzioni (oggi la versione utilizzata è
la 5). La modifica più importante rispetto alle vecchie versioni è rappresentata dall’introduzione delle
informazioni relative al protocollo di routing BGP
ed ai sequence number.
A livello più strettamente applicativo, le tecnologie più interessanti in questo ambito sono rappresentate da Riverhead e Arbor Networks, che
descriviamo con maggiore dettaglio nei rispettivi
riquadri di approfondimento.
5. L’Attività di Ricerca & Sviluppo in TILAB
A p a r t i re d a l 2 0 0 3 , s o n o s t a t i a v v i a t i i n
Telecom Italia Lab una serie di progetti focalizzati
sul tema dell’Intrusion Detection. La motivazione
principale è legata al fatto che le soluzioni proposte dal mercato, oltre ad essere economicamente
onerose, non sono sempre funzionalmente adatte
ad un contesto eterogeneo come quello che
caratterizza un grosso operatore di telecomunicazioni che richiede una enorme flessibilità in grado
tre meccanismi innovativi (sottoposti a domanda di
brevetto), descritti nel seguito:
• Il Bidirectional Rule Matching (BRM) è un
meccanismo che analizza la risposta del server a seguito di un pacchetto identificato
come potenzialmente pericoloso; la risposta
spesso consente di identificare se l'attacco ha
avuto successo o meno. In questo modo, il
numero di falsi positivi viene ridotto drasticamente, lavorando direttamente a livello del
sensore. Inoltre, mentre le regole che descrivono gli attacchi richiedono un continuo
aggior namento, le regole di risposta sono
relativamente stabili, essendo correlate alle
caratteristiche del protocollo applicativo. A
titolo puramente esemplificativo, descriviamo
un esempio d’uso del BRM: il successo di un
attacco diretto ad un server Web, che sfrutta
le vulnerabilità di un particolare script installato per default, può essere desunto con un
certo grado di precisione dalla risposta del
server: se infatti il server risponde con un
codice di errore 400 (ad esempio Access
Forbidden o Object not Found) è estremamente probabile che l’attacco sia andato a
vuoto. Un risultato di tipo 200 (OK), seguito
poi da pacchetti che contengono elementi
tipici di una interazione basata su una command-line shell, è una chiara indicazione del
fatto che l’attacco ha avuto successo.
Chiaramente, questo scenario non ha lo
scopo di presentare in modo esaustivo ed
approfondito il BRM, ma solo di dare un’idea
di come esso funzioni praticamente.
Alert Coding & Emission System
Enhanced Pattern Matching Engine
External Open Source Rules
di operare in per vari segmenti di rete (dalla connettività broadband per utenti domestici fino al
backbone).
L’attività di ricerca si è articolata su tre progetti.
Il progetto EAGLE è stato focalizzato sull’ideazione
e sulla prototipazione di nuove tecnologie che
potessero essere utilizzate nell’ambito più tradizionale, prestando particolare attenzione agli aspetti
di flessibilità e scalabilità menzionati in precedenza. Il progetto RDS (Routing Detection Security)
è stato invece focalizzato sulle problematiche
legate alla rete di backbone, ponendo particolare
attenzione agli attacchi che è possibile effettuare
sull’infrastruttura, in particolar modo ai protocolli di
routing. Infine, nell’ambito del progetto dedicato
alla sicurezza delle reti wireless (con particolare
enfasi al mondo IEEE 802.11 e WiFi) si è provveduto a studiare e prototipare delle componenti
specifiche per questo ambito che potessero essere
comunque integrate in un sistema tradizionale di
tipo network.
I risultati dell’attività di ricerca sono notevoli e
possono essere riassunti dai seguenti risultati:
• Brevetti: l’intera attività ha portato al deposito
di sei domande di brevetto focalizzate sulla tecnologia di tipo network, due domande di brevetto focalizzate sulla tecnologia host, una
domanda di brevetto focalizzata sul contesto
WiFi ed una domanda di brevetto focalizzata sul
contesto backbone.
• Prototipi: ogni singolo progetto ha prodotto uno
o più prototipi; in particolare, è disponibile una
soluzione completamente funzionante, per il
sistema di network-IDS. Inoltre, sono stati integrati nel sistema due componenti prototipali
relative al contesto WiFi. Il sistema host-IDS è
invece disponibile solamente in stato di prototipazione avanzata e solamente per la piattaforma Linux. Per ciò che riguarda l’ambito
backbone, sono state messe a punto le sonde
per il protocollo OSPF e per il protocollo BGP
oltre ad un sistema specifico per la raccolta e
l’elaborazione delle informazioni raccolte dalle
sonde.
• Linee di codice complessive: per quanto questa
quantificazione possa ritenersi imprecisa nel
descrivere la complessità effettiva dei sistemi
che sono stati realizzati, risulta comunque utile
nel fornire almeno un’indicazione di massima
sulla loro dimensione “quantitativa”. Esistono
oggi circa 150.000 linee di codice per il sensore
di tipo rete (più altre 2000 per il supporto WiFi),
20.000 linee per il sistema di tipo host-based e
altre 20.000 per i sistemi di tipo backbone.
Passiamo ora a descrivere brevemente le più
importanti caratteristiche delle singole soluzioni.
Bidirectional
Rules Matching
Detection
Rules DB
Dynamic
Auto Tuning
Protocol
Analyser
TCP Flow Re-Assembly
IP Defragmentation
SMP Load Balancing System
Custom Network Driver
10/100 Mbit/s
1000 Mbit/s
WiFi
5.1 Il sensore Network-IDS: nEAGLE™
nEAGLE™ è la soluzione network-IDS sviluppata nell’ambito del progetto omonimo (figura 3). Il
sistema è basato sulla tecnologia state of the art
per ciò che riguarda il pattern matching; assieme a
questa tecnologia tradizionale, implementa anche
IP = Internet Protocol
SMP = Symmetric Multi Processor
TCP = Transmission Control Protocol
FIGURA 3› nEAGLETM: architettura schematica.
107
• Il Dynamic Auto Tuning (DAT) consente al sensore di adattare il set di regole alla configurazione della rete; in questo modo il sistema è in
grado di identificare autonomamente la presenza di un servizio/protocollo noto (ad esmpio
HTTP, FTP, Telnet) su porte non standard.
Questo consente di ridurre i falsi negativi,
dovuti ad attacchi non rilevati perché diretti
verso server attestati su porte non standard. Il
DAT utilizza delle regole di tipo pattern matching o di protocol analysis per identificare in
un flusso di pacchetti ben definito la presenza
degli elementi distintivi di un particolare protocollo applicativo. A fronte di una tale situazione,
il DAT riconfigura automaticamente il sensore,
di modo che tutte le regole utilizzabili per quel
particolare protocollo vengano altresì adottate
anche su quella particolare connessione.
• Il supporto per Multi-Processori Simmetrici: un
sistema di network IDS funziona analizzando i
pacchetti; per poter trarre vantaggio dalla presenza di più CPU sono possibili due approcci: il
pipeline, o la distribuzione del carico sulle singole CPU. nEAGLE™ sfrutta l’approccio del
load balancing, e ripartisce fra le CPU disponibili sia l’attività di ripartizione del carico, sia la
vera e propria attività di rilevazione degli attacchi. L’algoritmo di scheduling che seleziona la
specifica attività da eseguire su ogni singola
CPU è di tipo application based, a differenza
della maggior parte degli approcci standard,
che sono invece di tipo kernel based e dunque
non possono in alcun modo sfruttare la conoscenza del dominio applicativo per pilotare le
decisioni di scheduling. Questo approccio consente di ottenere delle prestazioni notevolmente
superiori su sistemi SMP rispetto a quelle che si
otterrebbero con sistemi tradizionali, senza
dover ricorrere ad alcun load balancer separato.
Oltre all’adozione di specifiche tecnologie innovative, l’intero sistema è stato sottoposto ad una
completa ingegnerizzazione, focalizzata sulla riduzione notevole dell’overhead computazionale associato alla cattura dei pacchetti. Utilizzando un
sistema ad hoc, realizzato per mezzo di un devicedriver customizzato, si possono evitare alla radice i
problemi del livelock [24], sfruttando due approcci
classici della teoria dei sistemi operativi: implementazione di canali di comunicazione tra devicedriver ed user space che siano 0-copy e la
gestione del dispositivo di rete a polling invece che
con le interruzioni.
nEAGLE™ supporta inoltre un meccanismo per
rilevazione degli attacchi specifico per reti WiFi;
questo meccanismo è in grado di rilevare attacchi
portati ai livelli fisico e datalink dello stack TCP/IP
quali Authentication-Deauthentication, FrameF l o o d i n g,
Assoc ia tion-D isa ssoc iati o n Reassociation, Request-flooding. Oltre a questi
meccanismi, l’attività di ricerca e sviluppo ha portato alla realizzazione di una specifica funzionalità
(attualmente coperta da domanda di brevetto),
orientata alla riduzione dei falsi positivi ed all'individuazione di attacchi o tentativi di violazione del
108
meccanismo di autenticazione per reti WiFi IEEE
802.1x (ad esempio: THC-LeapCracker [25],
ASLEAP [26], 4Way Handshake Start DoS [27]).
Tale funzionalità è basata sulla correlazione delle
informazioni scambiate sulla rete WiFi con le informazioni ricevute dagli elementi di rete quali
Access-Point e server di autenticazione (ad esempio RADIUS) che realizzano la rete WiFi.
nEAGLE™ è stato verificato in laboratorio, dove
sono state ottenute delle prestazioni davvero notevoli (fino ad un ordine di grandezza superiore),
rispetto a quelle basate su tecnologie attualmente
disponibili su sistemi hardware a basso costo. Per
ciò che riguarda l’efficacia (Falsi Positivi e Falsi
Negativi), nEAGLE™ si è dimostrato estremamente
valido, sia durante i test di laboratorio, sia durante
l’attività di field trial. In particolare, nEAGLE risulta
in grado di gestire un numero di pacchetti superiore di un ordine di grandezza rispetto a soluzioni
convenzionali (su hardware low cost in condizioni
di sovraccarico), con un aumento della banda
media gestita da 5 Mbit/s a circa 34 Mbit/s. Per ciò
che riguarda il contesto high end, sfruttando un
sistema SMP a due CPU, nEAGLE riesce a gestire
tranquillamente una banda dell’ordine del Gbit/s.
5.2 Il sensore HIDS: SPID™
La sonda di sistema SPID (System Photo
Intrusion Detection), figura 4, usa un approccio
innovativo, basato sul paradigma dell'Anomaly
Detection, per identificare gli attacchi.
SPID
Alert Coding
Alerting
Internal Alert
Correlation
...
File System
Shell
Knowledge
Base
Network
Application
Detection
System
Application
Current
State
Data Normalisation
System
Call
Kernel
Info
Interception
System
Sensor
10
Mbit/s
Status Photo Intrusion Detection (SPID)
Technology TILAB Be-SecureTM Patent Pending
FIGURA 4› Architettura essenziale di una sonda SPID.
La metafora su cui è basato è ben descritta dal
nome che lo contraddistingue; in pratica, SPID
esegue una serie di “fotografie istantanee” del
sistema, focalizzandosi sugli schemi di utilizzo
delle varie risorse disponibili sul singolo host. Ad
esempio, si monitorano le relazioni parent/child
esistenti tra tutti i processi attivi, le relazioni tra
utenti, applicazioni e file; quelle fra applicazioni e
connessioni di rete, e così via. Ogni particolare
aspetto del sistema è analizzato da un componente ad hoc della Knowledge Base.
Come tutti i sistemi di tipo Anomaly Detection,
SPID opera in due fasi. Nella prima fase
(Addestramento), il sistema raccoglie tutte le informazioni che caratterizzano l’uso normale dell’host.
Alla fine dell’addestramento, la Knowledge Base
così ottenuta viene normalizzata; in altre parole, si
identificano tutti gli intervalli tipici di variabilità del
sistema, quale ad esempio l’utilizzo di file temporanei o eventuali periodicità con cui sono usate specifiche applicazioni. Queste informazioni, estrapolate dai dati osservabili, vengono incluse nei dati
che verranno poi usati durante la seconda fase di
funzionamento (Analisi). In analisi, SPID confronta
lo stato del sistema con le informazioni della
Knowledge Base; se viene rilevata un’anomalia, si
emette una segnalazione. Un opportuno sistema di
raccolta ed aggregazione di queste segnalazioni si
occupa poi di codificare in un allarme vero e proprio le anomalie rilevate dalle singole componenti
che costituiscono il sistema.
SPID è costituito da un insieme di componenti,
organizzati in base ad una architettura a tre strati.
Lo strato più basso si occupa dell’acquisizione
delle informazioni dal sistema operativo; la tecnica
adottata in SPID è quella dell’intercettazione delle
system call. A differenza di altri sistemi, in cui vengono intercettate indistintamente tutte le system
call per fornire un modello che caratterizzi l’esecuzione di un dato processo, SPID si limita ad intercettare tutte e sole quelle system call che coinvolgono direttamente una risorsa del sistema operativo, nello specifico: file, socket, device-driver, processi, identificativi di utente. Di queste system call
vengono registrati i parametri ed il processo che ha
eseguito la richiesta. Utilizzando queste system
call, il secondo strato è in grado di costruire un
modello analogico ridotto del sistema; in pratica
questo strato ha due compiti: tradurre la specifica
system call in una richiesta astratta di utilizzo di
risorsa del sistema operativo, ed offrire allo strato
superiore una visione astratta di quello che è lo
stato istantaneo del sistema monitorato. L’ultimo
strato è quello più complesso e si occupa di raccogliere e controllare gli schemi con cui sono usate le
varie risorse. Dal momento che ogni risorsa ha le
sue particolarità, sono stati implementati diversi
moduli, ognuno con una logica:
• User Table: questo modulo mappa le relazioni di
tipo utente/applicativo/file, fornendo una vista
globale del comportamento del sistema ricavata
direttamente a partire dal modello analogico
ridotto presente nel secondo strato. Il modulo
tiene traccia di tutte le risorse che vengono uti-
lizzate nel corso del funzionamento del sistema;
inoltre, per mezzo di appositi contatori, viene
anche misurato il numero complessivo di
istanze di un certo oggetto. Ogni volta che
appare un oggetto nuovo, che non era mai stato
visto dal sistema durante la fase di apprendimento, oppure ogni volta che uno dei counter
eccede i limiti ricavati dalla fase di apprendimento, viene emessa una segnalazione.
• Process Tree: questo modulo traccia la relazione di utilizzo tra applicazioni; in altre parole,
si cerca di capire quali applicazioni possono
essere seguite da una applicazione data. La
relazione ad albero è molto utile per catturare
tutti quei casi in cui, per effetto di un overflow,
si riesce a creare una shell abusiva nel contesto
di un server di rete.
• Network: questo modulo tiene traccia di tutte le
connessioni di rete, identificando gli applicativi
che svolgono il ruolo di client e/o server; le
porte su cui operano, e le caratteristiche statistiche della durata delle connessioni.
• File System: questo modulo tiene traccia di
tutte le modifiche al file system; in particolare,
può rilevare mount/unmount impropri, la creazione o la cancellazione di un elevato numero di
file, la cancellazione di file che sono ancora
aperti, o l’eccessivo numero di link simbolici
associati ad un file. Anche in questo caso, l’uso
dei contatori e l’applicazione della procedura di
normalizzazione consente di discriminare le
azioni ammissibili da quelle che non lo sono.
SPID è stato verificato in laboratorio su alcuni
server specifici della rete interna; al momento è
ancora considerato un sistema incompleto. I risultati ottenuti durante la sperimentazione sono positivi, in particolare, SPID sembra immune da alcuni
attacchi che invece caratterizzano altri sistemi
basati sulla syscall interception e sul paradigma di
Anomaly Detection.
5.3 La tecnologia RDS
Il progetto RDS (Routing Detection System)
nasce con l’obiettivo di realizzare un sistema di
Intrusion Detection dedicato interamente all’analisi
degli attacchi rivolti ai protocolli di routing. Una
delle sue caratteristiche essenziali è la capacità di
adattarsi all’ambiente d’uso, raccogliendo in modo
differente, a seconda del protocollo di routing
monitorato, tutte le informazioni che determinano il
comportamento della rete. Tale approccio permette
di identificare, in modo preventivo, il verificarsi di
particolari eventi che possono essere associati a
malfunzionamenti o a veri e propri attacchi che
direttamente o indirettamente provocano malfunzionamenti all’infrastruttura.
L’architettura del sistema (figura 5) prevede che
le sonde siano minimamente intrusive pur essendo
in condizione di ricevere tutte le informazioni di
routing. Il sistema, nel suo insieme, è caratterizzato
da una struttura gerarchica nella quale le operazioni di rilevazione sono segmentate sui vari livelli,
in funzione della complessità e della necessità di
109
input provenienti da altri componenti; l’affidabilità, che nel contesto
del backbone è una caratteristica
irrinunciabile, è garantita dalla presenza di più elementi ridondanti,
non solo a livello delle sonde, ma
anche degli altri componenti.
Management System
Particolare attenzione viene data
alla struttura dei vari moduli del
sistema, che presentano una configurazione che facilita la realizzaData Base
Ring
zione e l’integrazione di nuove logiche di detection e nuove tipologie di
sonde per protocolli non ancora
considerati dal sistema.
Il sistema consta di due livelli
Sonda
concettuali: le sonde, che sono
oggetti specializzati in grado di
Sonda
interfacciarsi, secondo differenti
modalità con i processi di routing,
ed il cosiddetto “Data Base Ring”,
che è un sistema di alta affidabilità
che riceve le informazioni dalle
sonde, le processa secondo logiche
codificate e memorizza i dati otteRete
nuti su un apposito database. Un
Controllata
Sonda
attacco al sistema di routing può
provocare la “scomparsa”, seppur
momentanea, di alcune zone di rete FIGURA 5› Architettura essenziale del sistema RDS.
da monitorare. La struttura ad
anello, garantisce che, anche in
condizioni critiche, il sistema può
continuare a funzionare correttamente; la presenza di
tive o di numerose variazioni nell’unita di
più elementi in grado di raccogliere le informazioni
tempo, è spesso indicativo di un attacco.
permette anche di suddividere il carico di lavoro
- Apparizione di rotte non appartenenti al progarantendo in questo modo un buon livello di scalaprio dominio IP: l’iniezione di rotte non
bilità. Ovviamente, l’operatore può interrogare i dataappartenenti al dominio è, nel migliore dei
base attraverso una classica interfaccia GUI. Oggi
casi, un errore di configurazione. La rilevaRDS è in grado di funzionare con due protocolli di
zione avviene mediante l’analisi incrociata
routing: OSPF (Open Shortest Path First) e BGP
della tabella di routing OSPF con i file di
(Border Gateway Protocol) di seguito descritti:
configurazione redatti dall’operatore.
• Sonda OSPF: esegue l’analisi dei pacchetti
- Rilevazione di anomalie sulla sonda stessa: il
OSPF sia attraverso una logica classica di snifsistema è in grado di rilevare la presenza di
fing del traffico sia interfacciandosi direttamente
criticità nella connessione con le sonde; che
con il processo di routing che collega la sonda
possono indicare un malfunzionamento o l’inialla rete da monitorare. La sonda è in grado di
zio di un attacco diretto all’infrastruttura.
controllare varie “anomalie”, tra le quali:
• Sonda BGP: l’analisi dei pacchetti BGP è basata
- Reti foglia su cui è attivo OSPF: questo consu un vero e proprio sistema di routing inserito
trollo permette di identificare e segnalare la
direttamente dentro la sonda, unito ad un meccapresenza, o la comparsa, di reti di accesso
nismo di protocol analysis sviluppato appositasu cui è attivo il protocollo OSPF; tale situamente per il protocollo BGP. Il dialogo tra la
zione non è necessariamente indicativa di un
sonda e gli apparati di rete si realizza attraverso
attacco, ma segnala la presenza di un
una sessione di peering BGP. La sonda è in grado
potenziale punto di attacco.
di lavorare sia in configurazione iBGP che eBGP.
- Cr eazione di nuove adiacenze: q u esto
Tipicamente si utilizza la modalità iBGP in quanto
evento segnala la creazione di una nuova
permette di trasportare informazioni di routing
adiacenza su una rete su cui OSPF è attivo e
con un livello di dettaglio superiore; infatti in quepuò rappresentare l’inizio di un attacco.
sto caso non vengono eseguite variazioni sul
- Detection dell’attacco MAXSEQ-MAXAGE e
campo Next Hop dei messaggi BGP e inoltre
dell’attacco LOWCOST [28].
viene utilizzato il campo Local Preference. Più in
- Variazione del numero di rotte: questo condettaglio, la sonda è in grado di eseguire molti
trollo serve per segnalare modifiche in crescita
controlli, tra i quali:
o decrescita della tabella di routing; questo
- Rilevamento di un eccessivo scambio di
evento, specie nel caso di variazioni significamessaggio tra peer.
110
-
Rilevamento del “flapping”: si riferisce ad
una modifica troppo frequente delle informazioni presenti nella tabella di routing, sia in
update sia in withdrawn.
- Distribuzione di prefissi/reti non autorizzati,
non allocati e ad uso privato.
- Rilevamento dei conflitti MOAS (Multiple Origin
AS) [29]: questo controllo permette di verificare
la corrispondenza degli AS di origine di un
update con quanto risulta dagli archivi del
RIPE, ed evidenziare discrepanze e/o conflitti.
- Redistribuzione della default route.
- Rilevamento anomalie sui Next-Hop: comparsa, sparizione, modifica dei Next-Hop
associati alle rotte.
- Rilevamento attacchi alla sonda: realizzazione di una honeypot BGP in grado di identificare eventuali tentativi di instaurazione di
sessioni BGP non autorizzate.
- Rilevazione anomalie sul campo AS-Path:
analisi del campo AS-Path per valutarne le
variazioni significative nel tempo.
- Monitoraggio delle rotte degli AS cliente:
monitoraggio della raggiungibilità delle reti
degli AS cliente.
Il sistema RDS è stato verificato nei laboratori di
Telecom Italia Lab, utilizzando a tale scopo una
rete emulata consistente di circa 18 router distinti.
Le sperimentazioni hanno dato esito positivo e si è
quindi partiti con un primo field trial, posizionando
le sonde sulla rete di Telecom Italia Lab. In questo
ambiente le sonde hanno evidenziato una buona
capacità di rilevazione delle anomalie, sia in ambito
OSPF che BGP.
—
BIBLIOGRAFIA
[1]
Denning D. E.: “An Intrusion-Detection Model”, IEEE
Transactions on software engineering, Vol. SE-13, NO. 2,
february 1987, 222-232.
[2]
Anderson, J.: “Computer Security Threat and
Surveillance”, Tech. Rep. James P. Anderson Co., Fort
Washinton, Pa, 1980.
[3]
Smaha, S. E.: “Haystack: An intrusion detection system”,
in Proc. of the IEEE 4th Aerospace Computer Security
Applications Conference, Orlando, FL, Dec. 1988.
[4]
D.E. Denning, Neumann P.G.: “Requirements and Model
for IDES - a real-time intrusion detection expert system”,
Tech. Rep., Computer Science Laboratory, SRI
International, 1985.
[5]
Kumar S., “Classification and Detection of Computer
Intrusion” ,M.S. Thesis, Computer Science Dep., Purdue
University, Agosto 1995.
[6]
“Information Assurance through Defense-in-Depth”
Directorate for Command, Control, Communications, and
Computer Systems, U.S. Department of Defense Joint
Staff, February 2000.
[7]
Gartner Group: “Gartner Information Security Hype Cycle
Declares Intrusion Detection Systems a Market Failure”;
2003 Press Release.
www.gartner.com/5_about/press_releases/pr11june2003c.jsp
[8]
Cormack, A.: “Moore’s Law of Computer Security”; Terena
Networking Conference 2002; 3-6 June 2002; Ireland.
6. Conclusioni
[9]
Staniford-Chen, S.: “Common Intrusion Detection
Framework”; http://seclabs.cs.ucdavies.edu/cidf/.
Questo articolo ha cercato di fornire una panoramica, quanto più ampia possibile, sull’ambito
della rilevazione delle intrusioni informatiche.
Chiaramente, il tema è estremamente vasto, e
dunque ci si è limitati a fornire un punto di partenza per approfondire le caratteristiche delle
varie tecnologie disponibili. Il problema della rilevazione è cruciale nel contesto di un’architettura
d i s i c u re z z a c o s t r u i t a s u l p a r a d i g m a d e l l a
“Defense in Depth”, perché è evidente che solo
attraverso un sistema di rilevazione davvero efficiente è possibile pensare di adottare delle tecnologie automatiche di risposta e protezione. La
ricerca svolta in Telecom Italia Lab su questo
tema nello scorso biennio, è stata incentrata sulla
problematica dell’efficacia e dell’efficienza,
ovvero sulla capacità di rendere il processo di
rilevazione quanto più accurato possibile, riducendo i falsi positivi e negativi, sfruttando al
meglio le performance dell’hardware disponibile e
focalizzando l’intervento umano solo sui problemi
davvero significativi. L’esperienza maturata nel
corso delle varie sperimentazioni, indica che questi aspetti sono fondamentali per consentire un
utilizzo ottimale delle tecnologie IDS anche al
contesto delle grosse reti di telecomunicazioni.
[10] Verwoerd, T. and Hunt, R., “Intrusion Detection
Techniques and Approaches”, Computer
Communications, Elsevier, U.K., Vol 25, No 15,
September 2002, pp1356-1365.
[11] Roesch M.: “The Snort Intrusion Detection System”;
www.snort.org/.
[12] Naval Surface Warfare Center - Dahlgren Lab: “The
Shadow Intrusion Detection System”.
www.nswc.navy.mil/ISSEC/CID/.
[13] Department of Energy: “The NID Network Intrusion
Detection System”; Il sistema è stato ritirato dal
6/11/2004. L’accesso alla documentazione è ristretto al
personale del Dipartimento della Difesa (DoD - USA).
[14] Kumar S., Spafford E. H., “An Application of Pattern
Matching In Intrusion Detection”, Technical Report,
Giugno 1994.
[15] Boyer R. S, Moore J. S.: “A Fast String Search
Algorithm”. Communications of ACM, 20(10); pp.
762-772; Ottobre 1977.
111
—
[16] Aho A., Corasic M.: “Fast Pattern Matching: an Aid to
Bibliographic Search”; Communications of ACM, 18(6),
pp. 333-340; Giugno 1975.
[17] Ilgun K., Kemmerer R.A., and Porras P.A., “State
Transition Analysis: A Rule-Based Intrusion Detection
Approach,” IEEE Transaction on Software Engineering, 21,
Marzo1995.
[18] Vigna G., Eckmann S.T., and Kemmerer R.A., “The STAT
Tool Suite,” in Proceedings of DISCEX 2000, Hilton Head,
South Carolina, Gennaio 2000, IEEE Press.
[19] Forrest S., Hofmeyr S. A., Somayaji A., Longstaff T. A., “A
sense of self for Unix processes”, Proceedings of the
1996 IEEE Symposium on Security and Privacy, 1996.
[20] Forrest S., Perelson A.S., Allen L., Cherukuri R.,”SelfNonself Discrimination in a Computer”, IEEE Symposium
on Research in Computer Security and Privacy, 1994.
[21] Forrest S., Perelson A.S., Allen L., Somayaji A.,
“Computer Immunology”, Communications of the ACM,
40 10), 1994.
[22] Ptacek T., Newsham T.: “Insertion, Evasion, and Denial of
Service: Eluding Network Intrusion Detection”. Secure
Network Inc. Whitepaper, 1998.
[23] RFC 3954: “Cisco Systems NetFlow Services Export
Version 9” e RFC 3955 “Evaluation of Candidate Protocols
for IP Flow Information Export (IPFIX)”.
[24] Mogul J. C., Ramakrishnan K. K.: “Eliminating receive livelock in an interrupt-driven kernel”; in ACM Transactions on
Computer Systems; 15(3), Agosto 1997, pp. 217-252.
ABBREVIAZIONI
ADSL
AG
BGP
BRM
CFG
CIDF
DAT
DDoS
DoS
FP
FN
FSM
GUI
LAN
IDS
IETF
IPS
MOAS
PoP
OSPF
RDS
RE
RNA
SMP
SNMP
SOHO
SPID
STIDE
WIDS
Asymmetric Digital Subscriber Line
Attribute Grammar
Border Gateway Protocol
Bidirectional Rule Matching
(Deterministric) Context Free Grammar
Common Intrusion Detection Framework
Dynamic Auto Tuning
Distributed Denial of Service
Denial of Service
False Positives rate
False Negatives rate
Finite State Machine
Graphic User Interface
Local Area Network
Intrusion Detection System
Internet Engineering Task Force
Intrusion Prevention System
Multiple Origin Autonomous System
Point of Presence
Open Shortest Path First
Routing Detection Security
Regular Expressions
Real-time Network Awareness
Symmetric Multi Processor
Simple Network Management Protocol
Small Office Home Office
System Photo Intrusion Detection
Sequenze Time Delay Embeddeing
Wireless Intrusion Detection System
[25] V. Hauser: THC-LeapCracker (v. 0.1): released by The
Hackers’ Choice on 2/10.2004. www.thc.org/.
[26] Wright J.:”The AS-LEAP”; http://asleap.sourceforge.net/.
[27] He C., Mitchell J. C.: “Analysis of the 802.11i 4-Way
Handshake”; In Proceedings of the 3rd ACM International
Workshop on Wireless Security (WiSe'04). Philadelphia,
PA, Oct. 2004.
[28] Jones E., Le Moigne O.: “OSPF Security Vulnerabilities
Analysis”; Internet Draft, 1 Dicembre 2004.
[29] Zhao X., Pei D., Wang L., Massey D., Mankin A., Wu F.
S., Zhang L.: “An Analysis of BGP Multiple Origin AS
(MOAS) Conflicts”; Proc. ACM SIGCOMM Internet
Measurement Workshop; 2001.
112
G e r a r d o L a m a s t r a si è laureato in
Ingegneria Informatica presso l’Università degli
Studi di Pisa nel 1996 ed ha conseguito il
Perfezionamento in Ingegneria dei Sistemi
Informatici (equipollente al Dottorato di Ricerca)
nel 2000. Nel 1999 è stato Research Scholar
presso l’University del North Carolina, Chapel
Hill, dove ha lavorato sull’analisi degli algoritmi di
scheduling per sistemi soft real-time. Dal 2000
fa parte del Centro di Sicurezza Be-Secure™ di
TILAB, dove si è occupato di Penetration Testing, Forensic Analysis
ed Intrusion Detection.
L u c a V i a l e s i è la u r e a t o in Sci enz e
dell’informazione presso l’Università degli Studi di
Torino nel 1996 ed ha conseguito il master
COREP in Telecomunicazioni nel 1997. Dal
1997 opera in CSELT (oggi TILAB) dove
in izia lm e n t e s i è o c c u p a t o d i a t ti v i tà di
conformance testing in ambito LAN/WAN. Dal
1998 fa parte del Centro di Sicurezza BeSecure™ di TILAB dove si è dedicato alle
problematiche di sicurezza approfondendo le
conoscenze nel campo della sicurezza delle infrastrutture di rete.
Oggi è impegnato su tematiche di innovazione nel settore delle
tecnologie di rilevamento e contrasto delle intrusioni.

Tecnologie innovative per il rilevamento e il

Transcript

Documenti analoghi

Che Cos`è un attaCCo wateRIng hole

IDS

`Ottobre Rosso` un esempio di Cyber-spionaggio

1 - Würth

(UPPATO) Linguaggi Programmazione per la Sicurezza

Regolamento Jyiu Ippon Kumite

Newsletter COI N. 3

Rapporto Clusit 2015 - Collabra Professional Email

penetration test: case study sql injection e cross

scarica presentazione in formato pdf

Progettazione di un Intrusion Detection System

Stefano Fornara - Honeypots e SURFids

sirmi - infopress

Evaluation of two commercially available methods used for the rapid

CARLO TAORMINA. Non parlo delle deleghe LUCIO IZZO

Relazione annuale 2015

Rapporto

I sistemi peer-to-peer

Progetto STUDIO B.6.72 B/7 ATTIVITÀ DI RILEVAMENTO

Rendere sicure le reti wireless

"INTRANET - EXTRANET" in formato PDF

Lista degli SMTP di configurazione della Posta Elettronica