Intrusion Detection Systems Introduzione, Tecnologie, Implementazione Ing. Stefano Zanero Politecnico di Milano
Richiamiamo il punto chiave Continuando 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 posteriori Misuse Detection: confrontare gli eventi con schemi predefiniti di attacchi; conoscenza a priori
Tassonomia degli IDS (1) Anomaly Detection Model 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 Misuse Detection Model 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
Tassonomia degli IDS (2) Host Based: opera su una singola macchina Network Based controlla 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 funzioni Scelta 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
SNORT: a Lightweight NIDS
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 engine Detection plugin: esegue dei test su un aspetto o campo del pacchetto Output 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 Snort Database MySQL PostgreSQL Oracle XML (SNML DTD del CMU/CERT) Formato tcpdump/libpcap Unified format specifico di Snort ASCII Syslog WinPopup (SMB)
Architettura di Snort 1.x Snort Pacchetti sulla rete Sniffing Data Flow Packet Decoder Preprocessori (Plug-ins) Detection Engine (Plug-ins) Plugin di Output (Plug-ins) Molto veloce! Veloce! Alerts/Logs Preprocessori/output: la velocità dipende dall implementazione
Snort 1.x Detection Engine Lista linkata tridimensionale di regole La 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 comparazione L engine viene valutato ricorsivamente sui pacchetti Detection 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
Tre regole di esempio Rule Header Alert tcp 1.1.1.1 any -> 2.2.2.2 any Alert tcp 1.1.1.1 any -> 2.2.2.2 any Alert tcp 1.1.1.1 any -> 2.2.2.2 any Rule Options (flags: SF; msg: SYN-FIN Scan ;) (flags: S12; msg: Queso Scan ;) (flags: F; msg: FIN Scan ;)
La loro rappresentazione Rule Alert tcp 1.1.1.1 any -> 2.2.2.2 any Option (flags: SF; msg: SYN-FIN Scan ;) (flags: S12; msg: Queso Scan ;) (flags: F; msg: FIN Scan ;)
avete capito l idea? Rule Rule Rule Rule Rule Option Option Option Option Option Option Option Option Option Option Option
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 architettura Più tipi di plug-in Acquisizione di dati da vari formati Decoder 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
Configurare Snort File di configurazione con esempi e readme: http://www.0xdeadbeef.info/ Scrittura delle regole e manuale: www.snort.org/docs/snortusersmanual.pdf Intrusion Signatures and Analysis (Northcutt, Cooper, Fearnow, Frederick)