33
Intrusion Detection System Giampaolo Fresi Roglia [email protected]

Giampaolo Fresi Roglia [email protected]

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Giampaolo Fresi Roglia gianz@security.dico.unimi

Intrusion Detection System

Giampaolo Fresi [email protected]

Page 2: Giampaolo Fresi Roglia gianz@security.dico.unimi

Sommario

IntroduzioneRichiami alla sicurezza InformaticaIntrusion Detection Systems

Strategie di monitoraggioLocalizzazione della sorgente delle informazioniModalita temporale di analisi

Tipologie di analisiMisuse detectionAnomaly detection

Elusione di un Network Intrusion Detection System

Problematiche dell’Intrusion Detection

Page 3: Giampaolo Fresi Roglia gianz@security.dico.unimi

Paradigma C.I.D.

I ConfidenzialitaI Permettere accesso in lettura ai soli utenti autorizzati

I IntegritaI Permettere accesso in scrittura ai soli utenti autorizzati

I DisponibilitaI Garantire accesso in lettura e scrittura agli utenti autorizzati

Page 4: Giampaolo Fresi Roglia gianz@security.dico.unimi

Conformita al paradigma C.I.D.

I Bonta del softwareI Accurata progettazioneI Testing del software

I Limitazione degli accessiI Politiche di sicurezzaI Apparati di enforcement

I Auditing delle politicheI Sistemi di rilevamento delle intrusioni

Page 5: Giampaolo Fresi Roglia gianz@security.dico.unimi

Intrusion Detection

I La prevenzione degli attacchi informatici non e sufficiente:I Troppo oneroso prevenire ogni possibile tipologia attaccoI Troppe misure preventive potrebbero limitare l’usabilita dei sistemiI Le misure preventive potrebbero rivelarsi inutili

I Le principali categorie di difesa sono:I PrevenzioneI RilevazioneI Intervento

I Intrusion Detection rappresenta il processo di monitoraggio deisistemi informatici e delle infrastrutture di comunicazione perindividuare intrusioni ed abusi

Page 6: Giampaolo Fresi Roglia gianz@security.dico.unimi

Utilita 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 qualitadelle misure preventive

I Deterrente contro attacchi ed abusi

Page 7: Giampaolo Fresi Roglia gianz@security.dico.unimi

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

Page 8: Giampaolo Fresi Roglia gianz@security.dico.unimi

Strategie di monitoraggioLocalizzazione della sorgente delle informazioni

I Host-basedI I dati di audit provenienti dal sistema operativo sono l’unico modo

per raccogliere informazioni in merito a quello che sta succedendoall’interno di un sistema:I System call chiamateI File letti, modificati e creatiI Comandi esterni eseguitiI Input ed output

I Le informazioni locali al sistema sono le piu vulnerabili: in caso diattacco portato a termine con successo possono essere alterate oeliminate

I L’attivita del sistema devono essere analizzate in tempo reale primache l’attaccante possa sovvertire il sistema e manomettere questeinformazioni

Page 9: Giampaolo Fresi Roglia gianz@security.dico.unimi

Strategie di monitoraggioLocalizzazione della sorgente delle informazioni

I Network-basedI I dati di audit corrispondo a tutto il traffico di rete visibileI Sotto particolari condizioni sono in grado di monitorare anche

un’intera sottoreteI L’analisi e passiva, ossia non c’e alcuna interazione con il normale

flusso delle informazioni:I Basso impatto nei confronti di strutture di rete gia esistentiI Possono essere configurati in modo da risultare invisibili

I L’analisi del traffico puo essere sia stateless che stateful

Page 10: Giampaolo Fresi Roglia gianz@security.dico.unimi

Strategie di monitoraggioLocalizzazione della sorgente delle informazioni

I Application-basedI Informazioni raccolte da una particolare applicazione (es. server

web)I Viene monitorato l’uso da parte degli utenti dell’applicazione:

I Cronologia degli accessiI Tipologia degli accessiI Quantita degli accessiI Frequenza degli accessi

I Si basano su informazioni tratte da fonti (es. log) generalmente nondotate di particolari protezioni

Page 11: Giampaolo Fresi Roglia gianz@security.dico.unimi

Strategie di monitoraggioModalita temporale di analisi

I Analisi onlineI analisi in tempo reale degli eventi che coinvolgono i sistemi

monitoratiI le anomalie vengono notificate in tempo realeI potrebbe essere possibile impedire l’attacco o l’abuso (Intrusion

Prevention)

I Analisi offlineI analisi successiva al verificarsi degli eventiI non e possibile identificare un attacco mentre viene compiuto, ma

solo in un momento successivo

Page 12: Giampaolo Fresi Roglia gianz@security.dico.unimi

Accuratezza dell’analisi

I Falsi positivi: un evento non maligno viene erroneamenteclassificato come maligno (fp)

I Falsi negativi: un evento maligno viene erroneamente classificatocome non maligno (fn)

I Nell’Intrusion Detection System ottimale:

fp = fn = 0

I Troppi falsi positivi rendono inutile l’Intrusion Detection Systemperche la mole di allarmi generati diventa ingestibile

I I falsi negativi contribuiscono ad un false sense of security

Page 13: Giampaolo Fresi Roglia gianz@security.dico.unimi

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 puo essere espresso come:

Tt = vp + vn + fp + fn

I L’indicatore di efficacia di un IDS dipende dall’incidenza degliattacchi nel traffico: (vp + fn)/Tt

Page 14: Giampaolo Fresi Roglia gianz@security.dico.unimi

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.

Page 15: Giampaolo Fresi Roglia gianz@security.dico.unimi

Tipologie di analisi

I Le metodologie utilizzate per analizzare i dati raccolti sonosuddivise in due categorie:I Misuse detection: ricerca di qualcosa definito maligno attraverso

pattern rappresentati attacchi o altre violazioni di policy gia note.Conoscenza a priori

I Anomaly detection: ricerca di qualcosa definito raro o inusuale enon riconducibile al normale comportamento del sistema.Conoscenza a posteriori

Page 16: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detection

I Principio di base:I Gli attacchi e gli abusi possono essere descritti con dei pattern o

signatureI Al verificarsi di un evento questo viene analizzato per determinare se

contiene uno dei pattern noti

I Identificazione delle signature:I Analisi delle vulnerabilita noteI Analisi degli attacchi gia subiti in passato

I Descrizione delle signature:I Descrizione delle possibili anomalie identificate attraverso il

linguaggio fornito dall’IDS

Page 17: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detection

I Problematiche:I E necessario conoscere a priori i potenziali attacchiI 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 positiviI Signature troppo restrittive rischiano di generare falsi negativi alla

minima variazione dell’attacco

Page 18: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionAlcuni 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

Page 19: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionAlcuni 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

Page 20: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionAlcuni esempi di signature

Signature ISS IDS per Slammer

SQL_SSRP_StackBo is (

udp.dst == 1434

ssrp.type == 4

ssrp.name.length > 97)

Page 21: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionEuristiche

I Per diminuire la possibilita di falsi negativi sono state realizzatedelle euristiche che permettono di individuare attacchi (lasignature di ISS IDS e 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 eseguibileI Se il pacchetto contiene piu di un numero prestabilito di istruzioni

macchina viene generato un allarme

Page 22: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionEuristiche 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;)

Page 23: Giampaolo Fresi Roglia gianz@security.dico.unimi

Misuse detectionEuristiche 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;)

Page 24: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detection

I Principio di base:I Il sistema viene utilizzato in modi piuttosto standard:

I durata dell’utilizzoI quantita e tipologia di risorse utilizzate (file, programmi, memoria, ...)I modalita di utilizzo di queste risorse

I Assunzione:I Il comportamento normale puo essere descritto statisticamenteI E necessaria una fase di training in cui si insegna al sistema qual’e il

comportamento normale

I Analisi:I Ogni evento viene confrontato con il profilo del comportamento

normaleI Se l’evento non e riconducibile al normale comportamento del

sistema viene generato un allarme

Page 25: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detection

I Vantaggi:I Lo scenario dell’attacco non deve essere definito a prioriI Questo approccio potrebbe permettere di individuare attacchi non

ancora conosciuti

I Problematiche:I PrivacyI Richiede la continua attualizzazione del profilo comportamentale

normaleI Il rischio di falsi positivi e molto alto (nel periodo di training

dovrebbero essere analizzati tutti i possibili casi d’uso del sistema)I E necessario che durante il periodo di training non si verifichino

eventi anomali

Page 26: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detectionAttacchi via web

I Correlazione dei programmi server-side invocati dal client con iparametri a loro trasmessi

I Il sistema deriva automaticamente il profilo dei paramteritrasmessi 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

Page 27: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detectionAttacchi via web, rilevazione delle anomalie

I Il compito di un modello e di assegnare una probabilita ad unaquery o ad un suo attributo

I Questa probabilita riflette la probabilita di trovare questa querynel profilo costruito (nel comportamento normale)

I Query e attributi con una probabilita bassa rappresentanoun’anomalia

I Una richiesta viene considerata anomala se considerando tutti gliattributi si supera una certa soglia prestabilita:

∑n∈M

wm ∗ (1− pm)

wm rappresenta il peso associato al modello m e pm e laprobabilita ritornata

Page 28: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detectionAttacchi via web, modelli utilizzati

I Lunghezza degli attributi delle query

I Distribuzione dei caratteri negli attributi delle query (es. testoitaliano)

I Inferenza strutturale: generazione di una grammatica in grado didescrivere gli attributi

I Ricerca di token: il valore di alcuni attributi potrebbe essereristretto ad un piccolo insieme di simboli

I Presenza o assenza di attributi: a volte molti attributi vengonoinseriti automaticamente lato client, nelle richieste malignegenerate manualmente molti di questi attributi sono omessi

I Ordinamento degli attributi

Page 29: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly detectionAttacchi via web, attacchi rilevati

Attacco Len Dist. Car. Struct Token Presenza Ordine

BO x x x xDir. Trav. x xXSS x x x xInput Val. x xCode Red x x x

Page 30: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly DetectionPAYL

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 profiloI Metrica di distanzaI Se la distanza supera una soglia scatta l’allarme

Page 31: Giampaolo Fresi Roglia gianz@security.dico.unimi

Anomaly DetectionPAYL

I Fase di trainingI Profilo statistico del traffico lecitoI Vettore Feature per ogni pacchetto lungo l verso la porta pI Pl,p = (µ, σ)I µ ⇒ vettore medio featureI σ ⇒ 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.

Page 32: Giampaolo Fresi Roglia gianz@security.dico.unimi

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)

Page 33: Giampaolo Fresi Roglia gianz@security.dico.unimi

Problematiche dell’Intrusion Detection

I Analisi dei dati:I Quantita di eventi da analizzareI Protezione dei dati raccoltiI Determinare l’espressivita 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