Intrusion Detection Systems -...
Transcript of Intrusion Detection Systems -...
Intrusion Detection Systems
Ing. Stefano Zanero Ing. Stefano Zanero –– Politecnico di MilanoPolitecnico di Milano
Introduzione, Tecnologie, Implementazione
Richiamiamo il punto chiaveContinuando a usare il paradigma classico “Who are you? What can you do?” complichiamo terribilmente le cose: una volta era il login/password, ora sono intrecci di criptografie.
Il principio dell’identificazione e dell’associazione ai permessi è ancora fondamentale ma non “scala”facilmente alle dimensioni di una WAN, o dell’Internet
Gli hacker non utilizzano la forza, ma sfruttano le debolezze intrinseche dei sistemi. Il paradigma classico su scala di rete è insicuro, ma non può essere “aggiornato”.
Logica KISS: Keep It Simple, Stupid.
Bisogna trovare un nuovo paradigma che complementi quello classico, ovviando alle sue debolezze
Why are you doing this ?Torniamo alle origini: confidenzialità, integrità, disponibilità hanno un comune denominatore
Il sistema informatico ha uno scopo, e deve servire a quello scopo evitando compromissioni
Ogni violazione del paradigma CID è visibile perché il sistema compie azioni “anomale”
Invece di limitarci a chiedere “Who are you ? What can you do ?” cerchiamo di capire: “Why are you doing this?”
INTRUSION DETECTION SYSTEM, rivelatore di intrusione
Intrusion Detection System
Un IDS non si sostituisce ai normali controlli, ma piuttosto cerca di scoprire i loro fallimenti
Chi entra in un sistema informatico abusivamente compie alcuni tipi di azione che un utente normale non farebbe mai; identificando queste azioni “anomale” possiamo scoprire un intruso
Due metodi principali per farlo:Anomaly Detection: determinare statisticamente modelli di “comportamento normale”, e segnalare eventuali deviazioni “significative”; conoscenza a posterioriMisuse Detection: confrontare gli eventi con “schemi”predefiniti di attacchi; conoscenza a priori
Tassonomia degli IDS (1)
Descrivere comportamento normale e segnalare deviazioni
In teoria, può riconoscere ogni attacco
Dipende fortemente dal modello, dalle metriche e dalla scelta dei threshold
Le sue segnalazioni sono di tipo statistico
Descrivere i vari tipi di attacco informatico e riconoscerli
Riconosce solo gli attacchi per cui esiste una firma
Il modello di regole usate per esprimere gli attacchi può avere problemi di espressività
Le segnalazioni sono molto precise e possono essere usate per risposte attive
Anomaly Detection Model Misuse Detection Model
Tassonomia degli IDS (2)
Host Based: opera su una singola macchina Network Basedcontrolla il traffico sulla rete
Misuse detection: pessima idea?I sistemi di misuse detection hanno molti problemi ma ne presentano uno in particolare: la necessitàdi gestire una knowledge base degli attacchi
Problemi di aggiornamento (solo gli attacchi conosciuti vengono segnalati) e di ingegnerizzazione delle signature (in qualsiasi modo vengano gestite...)
Problema del polimorfismo negli attacchi: ADMutate, encoding UTF...
Inoltre: problema di uncertain reasoning e sequenzialità
Anomaly Detection: i problemi
Scelta delle metriche (cosa misurare) Scelta dei threshold (soglia d’allarme) e delle funzioniScelta dei modelli di base: cosa succede se l’attacco compare solo in variabili che non abbiamo modellato ?Segnalazione di tipo statistico che va interpretata da un esperto umano
Cos’è Snort ?
Snort è un “multi-mode packet analysis tool”, fondamentalmente un IDS network based e misuse based
Sviluppato dal famoso Martin Roesch
Snort è disponibile al sito www.snort.org
Un database di regole è disponibile su www.whitehats.com
Supporto tecnico commerciale: www.silicondefense.com
Appliance commerciali basate su Snort: www.sourcefire.com
Le caratteristiche
È un packet sniffer studiato per essere leggero e performante
Basato sulle librerie Libpcap
Sistema di individuazione degli attacchi basato su regole
Sistema di “plug-in” per massima flessibilità
I tipi di plug-in
Preprocessore: esamina e manipola I pacchetti prima di passarli all’engineDetection plugin: esegue dei test su un aspetto o campo del pacchettoOutput plugin: trasforma ed esporta i risultati dell’analisi
Modalità di utilizzo di snort
Sniffer Mode (come tcpdump)
Packet Logger Mode (come tcpdump, ma con più opzioni di output)
NIDS Mode (attivazione delle regole, funzionalità complete)
Forensic Data Analysis Mode: come i precedenti, ma si dà in pasto a Snort un dump di rete
Uso come NIDS
Vengono attivate tutte le componenti di snort
Sono disponibili online una grande quantità di regole, inoltre molto spesso vengono scritte e inserite nelle advisory
Regole e plug-in consentono di effettuare molti controlli: di base, misuse detection, ma anche controlli statistici e verifica di protocollo
Preprocessori per portscan detection, IP defragmentation, TCP stream reassembly, application layer analysis, ecc.
Gli output di SnortDatabase
MySQLPostgreSQLOracle
XML (SNML DTD del CMU/CERT)
Formato tcpdump/libpcap
Unified format specifico di Snort
ASCII
Syslog
WinPopup (SMB)
Architettura di Snort 1.x
Packet DecoderPreprocessori
(Plug-ins)Detection Engine
(Plug-ins)Plugin di Output
(Plug-ins)
Pacchetti sulla rete
Sniffing
Snort
Data Flow
Alerts/Logs
Molto veloce !
Veloce !
Preprocessori/output: la velocitàdipende dall’implementazione
Snort 1.x Detection Engine
Lista linkata tridimensionale di regoleLa prima e la seconda dimensione contengono i nodi di dati da testare (parametri delle regole) La terza dimensione contiene la lista dei puntatori alle funzioni da usare per la comparazioneL’engine viene valutato ricorsivamente sui pacchettiDetection a “prima uscita”: appena una regola fa match viene eseguito il comando e si passa al pacchetto successivo
Snort arriva senza problemi a 100Mb/sec di throughput
Rule HeaderAlert tcp 1.1.1.1 any -> 2.2.2.2 any
Rule Options(flags: SF; msg: “SYN-FIN Scan”;)
Alert tcp 1.1.1.1 any -> 2.2.2.2 anyAlert tcp 1.1.1.1 any -> 2.2.2.2 any
(flags: S12; msg: “Queso Scan”;)(flags: F; msg: “FIN Scan”;)
Tre regole di esempio…
Alert tcp 1.1.1.1 any -> 2.2.2.2 anyRule Node
(flags: SF; msg: “SYN-FIN Scan”;)
(flags: S12; msg: “Queso Scan”;)
(flags: F; msg: “FIN Scan”;)
Option Node
La loro rappresentazione…
RuleNode
RuleNode
RuleNode
RuleNode
RuleNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
OptionNode
… avete capito l’idea ?
I limiti di Snort 1.x
Centrato sul livello IP (singolo pacchetto)
Deframmentazione IP e reassembly di stream del TCP fatti su preprocessore… e spesso sono diventati colli di bottiglia
Ancora più spesso, I plugin di output risucchiavano inutilmente risorse!
Supporto per nuovi protocolli non ben modularizzato
Application layer non gestito dal decoding engine, lasciato completamente a chi scrive regole. Insomma, è semplice descrivere regole per IP/TCP/UDP/ICMP/IGMP… complesso descrivere HTTP, RPC, SMTP…
Snort 2.0: nuova architetturaPiù tipi di plug-in
Acquisizione di dati da vari formatiDecoder di traffico estensibile (protocol verification, stream analysis su multi-path…) Regole multiformato (da DB, in XML…)Detection engine a plug-in: Standard NIDS, Target-based IDS, Statistical IDS, Host-based IDS…
Miglioramento nel pattern matching, tramite algoritmi Aho-Corasick; Boyer-Moore; set-wise Boyer-Moore-Horspool: tradotto, una velocità migliorata di 5 volte !
I plugin di output si attaccano a un processo secondario (“barnyard-aia”) che fa da buffer tra Snort e l’output