Intrusion Detection System

Giampaolo Fresi Roglia

gianz@security.dico.unimi.it
Sommario

Introduzione
Richiami alla sicurezza Informatica
Intrusion Detection Systems

Strategie di monitoraggio
Localizzazione della sorgente delle informazioni
Modalità temporale di analisi

Tipologie di analisi
Misuse detection
Anomaly detection

Elusione di un Network Intrusion Detection System

Problematiche dell’Intrusion Detection

Paradigma C.I.D.

I Confidenzialità
I Permettere accesso in lettura ai soli utenti autorizzati
I Integrità
I Permettere accesso in scrittura ai soli utenti autorizzati
I Disponibilità
I Garantire accesso in lettura e scrittura agli utenti autorizzati
Conformità al paradigma C.I.D.

I Bontà del software

I Accurata progettazione
I Testing del software
I Limitazione degli accessi
I Politiche di sicurezza
I Apparati di enforcement
I Auditing delle politiche
I Sistemi di rilevamento delle intrusioni
Intrusion Detection

I La prevenzione degli attacchi informatici non è sufficiente:

I Troppo oneroso prevenire ogni possibile tipologia attacco
I Troppe misure preventive potrebbero limitare l’usabilità dei sistemi
I Le misure preventive potrebbero rivelarsi inutili
I Le principali categorie di difesa sono:
I Prevenzione
I Rilevazione
I Intervento
I Intrusion Detection rappresenta il processo di monitoraggio dei
sistemi informatici e delle infrastrutture di comunicazione per
individuare intrusioni ed abusi
Utilità dei sistemi di Intrusion Detection

I Rilevazione di attacchi informatici e degli attaccanti

I Rilevazione di abusi (anche da parte di utenti legittimi)
I Limitazione dei danni (se esiste un meccanismo di intervento)
I Ampliamento dell’esperienza in modo da migliorare la qualità
delle misure preventive
I Deterrente contro attacchi ed abusi
Tipologie degli IDS

I Network based IDS (NIDS)

I Sensori collocati alla periferia
I Host based IDS (HIDS)
I Sensori Installati nelle macchine da monitorare
Strategie di monitoraggio
Localizzazione della sorgente delle informazioni

I Host-based
I I dati di audit provenienti dal sistema operativo sono l’unico modo
per raccogliere informazioni in merito a quello che sta succedendo
all’interno di un sistema:
I System call chiamate
I File letti, modificati e creati
I Comandi esterni eseguiti
I Input ed output
I Le informazioni locali al sistema sono le più vulnerabili: in caso di
attacco portato a termine con successo possono essere alterate o
eliminate
I L’attività del sistema devono essere analizzate in tempo reale prima
che l’attaccante possa sovvertire il sistema e manomettere queste
informazioni
Strategie di monitoraggio
Localizzazione della sorgente delle informazioni

I Network-based
I I dati di audit corrispondo a tutto il traffico di rete visibile
I Sotto particolari condizioni sono in grado di monitorare anche
un’intera sottorete
I L’analisi è passiva, ossia non c’è alcuna interazione con il normale
flusso delle informazioni:
I Basso impatto nei confronti di strutture di rete già esistenti
I Possono essere configurati in modo da risultare invisibili
I L’analisi del traffico può essere sia stateless che stateful
Strategie di monitoraggio
Localizzazione della sorgente delle informazioni

I Application-based
I Informazioni raccolte da una particolare applicazione (es. server
web)
I Viene monitorato l’uso da parte degli utenti dell’applicazione:
I Cronologia degli accessi
I Tipologia degli accessi
I Quantità degli accessi
I Frequenza degli accessi
I Si basano su informazioni tratte da fonti (es. log) generalmente non
dotate di particolari protezioni
Strategie di monitoraggio
Modalità temporale di analisi

I Analisi online
I analisi in tempo reale degli eventi che coinvolgono i sistemi
monitorati
I le anomalie vengono notificate in tempo reale
I potrebbe essere possibile impedire l’attacco o l’abuso (Intrusion
Prevention)
I Analisi offline
I analisi successiva al verificarsi degli eventi
I non è possibile identificare un attacco mentre viene compiuto, ma
solo in un momento successivo
Accuratezza dell’analisi

I Falsi positivi: un evento non maligno viene erroneamente

classificato come maligno (fp)
I Falsi negativi: un evento maligno viene erroneamente classificato
come non maligno (fn)
I Nell’Intrusion Detection System ottimale:

fp = fn = 0

I Troppi falsi positivi rendono inutile l’Intrusion Detection System

perché la mole di allarmi generati diventa ingestibile
I I falsi negativi contribuiscono ad un false sense of security
Accuratezza dell’analisi (2)

I Veri positivi: un evento maligno viene classificato come tale (vp)

I Veri negativi: un evento non maligno viene ignorato (vn)
I Detection rate: dr = vp/(vp + fn)
I False positive rate: fpr = fp/(fp + vn)
I Il traffico totale può essere espresso come:

Tt = vp + vn + fp + fn

I L’indicatore di efficacia di un IDS dipende dall’incidenza degli

attacchi nel traffico: (vp + fn)/Tt
Accuratezza dell’analisi Esempio:

I Traffico totale: Tt = 10000 connessioni

I Attacchi stimati: 1% del totale, ossia 100 connessioni
I Traffico non maligno: 99% del totale, ossia 9900 connessioni
I Detection: 80% (80 attacchi rilevati)
I Falsi positivi: 1% (99 connessioni rilevate come attacchi)
I Falsi positivi: 55% degli allarmi totali.
Tipologie di analisi

I Le metodologie utilizzate per analizzare i dati raccolti sono

suddivise in due categorie:
I Misuse detection: ricerca di qualcosa definito maligno attraverso
pattern rappresentati attacchi o altre violazioni di policy già note.
Conoscenza a priori
I Anomaly detection: ricerca di qualcosa definito raro o inusuale e
non riconducibile al normale comportamento del sistema.
Conoscenza a posteriori
Misuse detection

I Principio di base:
I Gli attacchi e gli abusi possono essere descritti con dei pattern o
signature
I Al verificarsi di un evento questo viene analizzato per determinare se
contiene uno dei pattern noti
I Identificazione delle signature:
I Analisi delle vulnerabilità note
I Analisi degli attacchi già subiti in passato
I Descrizione delle signature:
I Descrizione delle possibili anomalie identificate attraverso il
linguaggio fornito dall’IDS
Misuse detection

I Problematiche:
I È necessario conoscere a priori i potenziali attacchi
I L’archivio delle signature deve essere costantemente aggiornato
I Rischio di falsi-negativi molto elevato
I La signature deve essere scelta con la massima precisione:
I Rischio di falsi positivi
I Signature troppo restrittive rischiano di generare falsi negativi alla
minima variazione dell’attacco
Misuse detection
Alcuni esempi di signature

Dump del traffico di rete generato da Slammer

0x0000 4500 0194 17a0 0000 6d11 3ed7 d564 a224 E.......m.>..d.
0x0010 xxxx xxxx 0a0c 059a 0180 355d 0401 0101 .o........5]....
0x00.. .... .... .... .... .... .... .... .... ...............
0x0070 0101 0101 0101 0101 0101 0101 01dc c9b0 ...............
0x00.. .... .... .... .... .... .... .... .... ...............
0x00b0 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 ..Qh.dllhel32hke
0x00c0 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe
0x00.. .... .... .... .... .... .... .... .... ...............
0x00e0 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f.etQhsockf.toQ
0x00f0 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend....B.E.P..
0x0100 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E.P.E.P..P....
0x0110 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=U..Qt.....
0x0120 42ff 16ff d031 c951 5150 81f1 0301 049b B....1.QQP......
0x0130 81f1 0101 0101 518d 45cc 508b 45c0 50ff ......Q.E.P.E.P.
0x01.. .... .... .... .... .... .... .... .... ...............
0x0180 c951 6681 f178 0151 8d45
0x0190 ffd6 ebca
Misuse detection
Alcuni esempi di signature

Signature Snort per Slammer

alert udp xxx any -> xxx 1434 (msg:"MS-SQL Worm";

content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1|";
content:"sock"; content:"send"; sid:2004; rev:1;)

Signature Dragon IDS per Slammer

U D A B 1 166 1434 MS-SQL:SERVER-WORM

/64/6c/6c/68/65/6c/33/32/68/6b/65/72/6e
Misuse detection
Alcuni esempi di signature

Signature ISS IDS per Slammer

SQL_SSRP_StackBo is (
udp.dst == 1434
ssrp.type == 4
ssrp.name.length > 97)
Misuse detection
Euristiche

I Per diminuire la possibilità di falsi negativi sono state realizzate

delle euristiche che permettono di individuare attacchi (la
signature di ISS IDS è un esempio)
I Decodifica dei protocolli:
I Ogni protocollo a livello applicazione (http, smtp, ...) viene
decodificato per verificare se ci sono delle violazioni delle politiche
I Abstract Payload Execution:
I Si analizza il payload di un pacchetto per vedere se contiene una
sequenza di byte che rappresenta del codice macchina eseguibile
I Se il pacchetto contiene più di un numero prestabilito di istruzioni
macchina viene generato un allarme
Misuse detection
Euristiche elementari

Linux Shellcode SNORT

alert ip xxx -> xxx any (msg:"Linux shellcode"; content:"|90 90

90 E8 C0 FF FF FF|/bin/sh"; sid:652; rev:9;)

Linux Unicode NOOP SNORT

alert ip xxx -> xxx any (msg:"Linux unicode NOOP"; content:"|90

00 90 00 90 00 90 00 90 00|"; sid:653; rev:9;)

Linux Setuid SNORT

alert ip xxx -> xxx any (msg:"Linux setuid"; content:"|B0 17 CD

80|; sid:650; rev:8;)
Misuse detection
Euristiche elementari

SQL Injection generico

alert ip xxx -> xxx any (msg:"SQL injection"; uricontent:"GET /";

uricontent:"’"; sid=1233; rev:9;)

Query SQL

alert ip xxx -> xxx any (msg:"SQL query"; pcre:"(select|or|union|

delete|drop)"; sid=1234; rev:9;)
Anomaly detection

I Principio di base:
I Il sistema viene utilizzato in modi piuttosto standard:
I durata dell’utilizzo
I quantità e tipologia di risorse utilizzate (file, programmi, memoria, ...)
I modalità di utilizzo di queste risorse
I Assunzione:
I Il comportamento normale può essere descritto statisticamente
I È necessaria una fase di training in cui si insegna al sistema qual’è il
comportamento normale
I Analisi:
I Ogni evento viene confrontato con il profilo del comportamento
normale
I Se l’evento non è riconducibile al normale comportamento del
sistema viene generato un allarme
Anomaly detection

I Vantaggi:
I Lo scenario dell’attacco non deve essere definito a priori
I Questo approccio potrebbe permettere di individuare attacchi non
ancora conosciuti
I Problematiche:
I Privacy
I Richiede la continua attualizzazione del profilo comportamentale
normale
I Il rischio di falsi positivi è molto alto (nel periodo di training
dovrebbero essere analizzati tutti i possibili casi d’uso del sistema)
I È necessario che durante il periodo di training non si verifichino
eventi anomali
Anomaly detection
Attacchi via web
I Correlazione dei programmi server-side invocati dal client con i
parametri a loro trasmessi
I Il sistema deriva automaticamente il profilo dei paramteri
trasmessi a questi programmi da un insieme di dati

Esempio di richiesta HTTP

xxx.xxx.xxx.xxx johndoe 29/Oct/2003:16:03:00 -0500

"GET /scripts/access.pl?user=johndoe&cred=admin" 200 2122

I Insieme delle richieste: U = {u1 , u2 , ..., un }

I Richiesta: ui =< pathi , pinfoi , qi >
I Query: qi = (a1 , v1 ), (a2 , v2 ), ..., (an , vn )
I Richieste specifiche ad un’applicazione: Ur = {uj | pathi = r }
I Per ogni Ur viene costruito un insieme di modelli
Anomaly detection
Attacchi via web, rilevazione delle anomalie

I Il compito di un modello è di assegnare una probabilità ad una

query o ad un suo attributo
I Questa probabilità riflette la probabilità di trovare questa query
nel profilo costruito (nel comportamento normale)
I Query e attributi con una probabilità bassa rappresentano
un’anomalia
I Una richiesta viene considerata anomala se considerando tutti gli
attributi si supera una certa soglia prestabilita:

X
wm ∗ (1 − pm )
n∈M

wm rappresenta il peso associato al modello m e pm è la

probabilità ritornata
Anomaly detection
Attacchi via web, modelli utilizzati

I Lunghezza degli attributi delle query

I Distribuzione dei caratteri negli attributi delle query (es. testo
italiano)
I Inferenza strutturale: generazione di una grammatica in grado di
descrivere gli attributi
I Ricerca di token: il valore di alcuni attributi potrebbe essere
ristretto ad un piccolo insieme di simboli
I Presenza o assenza di attributi: a volte molti attributi vengono
inseriti automaticamente lato client, nelle richieste maligne
generate manualmente molti di questi attributi sono omessi
I Ordinamento degli attributi
Anomaly detection
Attacchi via web, attacchi rilevati

Attacco Len Dist. Car. Struct Token Presenza Ordine

BO x x x x
Dir. Trav. x x
XSS x x x x
Input Val. x x
Code Red x x x
Anomaly Detection
PAYL

I Funzionamento diviso in due fasi:

I Fase di training:
I Viene definito il profilo del traffico lecito
I Fase di Detection:
I Il traffico nuovo viene confrontato con il profilo
I Metrica di distanza
I Se la distanza supera una soglia scatta l’allarme
Anomaly Detection
PAYL

I Fase di training
I Profilo statistico del traffico lecito
I Vettore Feature per ogni pacchetto lungo l verso la porta p
I Pl,p = (µ, σ)
I µ ⇒ vettore medio feature
I σ ⇒ varianza delle feature
I In fase di detection calcola:
I Distanza di Mahalanobis d = mahal(F , Pl,p )
I Se la distanza supera una soglia t genera l’allarme.
Elusione di un NIDS

I Mutazione a livello rete:

I Frammentazione
I Mutazione dell’exploit:
I Exploit polimorfico (ADMutate)
I Codifiche alternative (es. randhttpreq e libwhisker)
Problematiche dell’Intrusion Detection

I Analisi dei dati:

I Quantità di eventi da analizzare
I Protezione dei dati raccolti
I Determinare l’espressività dei dati (quali sono importanti e quali no)
I Elevati costi computazionali
I Alto numero di falsi positivi
I Correlazione tra fonti di dati differenti
I Correlazione tra gli allarmi di differenti tipologie di IDS