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

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’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

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)