written by: D. Besana, M. Matricardi, D. Muscetta
In molte corporate il problema della sicurezza è una questione critica. Gli esperti reali sono veramente pochi mentre i problemi che devono essere risolti sono sempre tanti e gravi ed il tempo a disposizione è sempre poco. Tra gli strumenti a disposizione degli amministratori dei sistemi si stanno affermando gli IDS (Intrusion Detection System). Ovvero dei sistemi in grado di rilevare e segnalare dei tentativi di intrusione ed eventualmente gestirne le contromisure necessarie. In questo articolo vogliamo presentare quelle che sono le strategie con cui un IDS lavora, quali sono le linee guida mediante il quale individuare attività sospette sulla rete e cercare di capire quali di queste tecniche sono più efficaci di altre e perché. Approfondiremo poi le caratteristiche di due prodotti tra i più diffusi: SNORT proveniente dal mondo open-source e Dragon prodotto da Enterasys Networks.
INTRO
Proteggere i propri sistemi è una guerra.
I nemici non mancano: virus, script kiddie, hacker amatoriali e professionisti sono i principali contendenti.
Le tattiche di difesa neppure: il primo passo è installare un punto di controllo alla frontiera della propria rete, esattamente come una porta blindata protegge una casa dall’ingresso di persone indesiderate.
Nelle reti, questo punto di controllo è il Firewall, il cui unico compito è filtrare tutto il traffico di una rete e lasciar passare o bloccare i pacchetti secondo dei parametri (policy) prestabiliti ad esempio porte e/o indirizzi IP.
I prodotti più evoluti possono verificare la semantica di un protocollo analizzando per esempio che il traffico che sta passando a livello applicativo (7) sia effettivamente quello che vogliamo associato a quella porta 80 GET/POST, HEAD di HTTP.
Tutti sappiamo che le porte blindate sono un buon deterrente, ma che i furti non sono mai terminati. Quindi si è passati all’installazione degli antifurti per abitazioni. Ce ne sono di tanti tipi: volumetrici, a sensori su porte e finestre, con i raggi laser ecc.
Gli antifurti sono sistemi di controllo delle intrusioni. In una rete questo controllo è compito degli IDS, appunto gli Intrusion Detection System: controllare che il traffico lasciato passare dai punti di controllo non sia traffico indesiderato.
Un altro paragone, per certi versi più azzeccato, è la procedura di imbarco in un aeroporto: al check-in ci pesano la valigia e ci dicono se possiamo imbarcarla a mano (firewall) mentre all’imbarco il nostro bagaglio viene passato ai raggi X alla ricerca di armi o altri oggetti pericolosi (IDS).
Un IDS è un sistema complesso ed ostico. Perché funzioni al meglio e svolga in suo compito in maniera ottimale occorre un’attenta osservazione di tutto quello che accade normalmente sulla rete in esame al fine di stabilirne la posizione e la politica di funzionamento.
Ora che abbiamo inquadrato cosa fa un IDS all’interno di una strategia di difesa, vediamo come lo fa.
TIPOLOGIE DI IDS: NIDS e HIDS
Rilevare le intrusioni è una sfida che va combattuta con tutte le armi a disposizione. Lo scopo è rilevare tutti gli eventi strani che possono essere potenzialmente pericolosi. Per raggiungere questo obiettivo si percorrono due strade: è possibile analizzare il traffico di rete, potenziale veicolo di attacco oppure mantenere monitorate le macchine.
Da questa semplice distinzione sono nate due grandi famiglie di IDS: i Network IDS e gli Host IDS.
NIDS
I NIDS funzionano analizzando tutto il traffico che passa sulla rete alla ricerca di anomalie.
Esistono diverse tecnologie di controllo del traffico, che vedremo più avanti, ma sono tutte caratterizzate dalla possibilità da parte dello strumento NIDS di “sniffare†l’intera comunicazione sulla rete: da qui viene anche chiamato Network Sensor.
I NIDS sono ritenuti il modo più efficacie per fare Intrusion Detection, perché evitano di installare agenti software sui server (usati dagli HIDS) restando di fatto un componente della rete, peraltro non critico poiché anche in caso di fault non provoca un disservizio.
Un grosso limite dei NIDS sono i protocolli cifrati. Queste soluzioni si sono diffuse con l‘aumentare dell‘attenzione della comunità verso la crittografia: scienza che si occupa di garantire sicurezza durante i trasferimenti di informazioni.
L‘aggiunta di uno strato di crittografia, nella comunicazione in rete riduce drasticamente l‘analisi che può fare un NIDS. In questi casi un sensore di rete può generare un evento quando viene iniziata una sessione crittografata, e comunicare la versione del protocollo utilizzato, ma non è in grado di darci informazioni su chi si sia autenticato e su cosa stia facendo né tanto meno effettuare controlli sul contenuto del traffico..
E’ chiaro dunque che basare l’Intrusion Detectioning su NIDS non è più sufficiente, occorre vedere cosa è un HIDS.
HIDS
Un HIDS è un agente software che tiene monitorato il sistema su cui è installato.
Per ottenere un simile risultato si possono analizzare:
- i file di log
- l’integrità dei file
- lo stato del sistema alla ricerca di segnali di anomalie per esempio utilizzo di memoria e disco
- le porte in stato di LISTEN sul sistema
I controlli sono sempre più sofisticati e approfonditi.
Ma gli HIDS non sono la panacea dell’Intrusion Detection.
Un HIDS ha una visuale molto ristretta: l’host su cui è installato e funzionante. Non capirà mai se è in corso un port scan su tutti i server della rete, e non potrà mai essere installato su tutti gli elementi della rete (pensate ad un router).
D’altro canto, potrà avere una visione A FONDO di ciò che succede su quel sistema: il server sensor nel caso di ISS RealSecure porta con sé funzioni di “personal firewall†che e’ in grado di droppare i pacchetti pericolosi PRIMA di passarli eventualmente all’applicazione (effettivamente bloccando attacchi di cui e’ a conoscenza e per cui magari una patch non e’ ancora stata installata).
L’origine degli Host IDS e’ nei prodotti di pura e semplice Log Analisys, e ci sono ancora vendor che propongono soluzioni “Host Onlyâ€, e che vanno MOLTO a fondo nell’analisi di cio’ che avviene su un sistema (controllando i logs e i “tenendo d’occhio†i files), e magari correlando queste informazioni con gli alert di un NIDS di un’altro vendor, o con i log del firewall di un’altro vendor ancora.
Qui entriamo però nel campo dei cosidetti SIMS: “Security Information Management Systemsâ€, campo in cui giocano NetForensics, NetIQ, e altri, ma che esulano un po’ dalla nostra trattazione degli IDS “puri e semplici 
Inoltre (relativamente ad i rischi di un HIDS): possiamo fidarci di un software che lavora su un elemento che potrebbe essere potenzialmente compromesso? Come sempre, la soluzione sta nell’integrazione di NIDS e HIDS in un’architettura IDS distribuita e gestita centralmente.
Questo tipo di IDS integrati (Host/Network) viene anche definito ibrido.
REAGIRE AGLI ATTACCHI INLINE
Con il passare del tempo sono state introdotte negli IDS delle “parti attiveâ€, cioè dei meccanismi di reazione ad un attacco rilevato. La reazione può avvenire in vari modi: tramite un reset delle connessioni ritenute pericolose (reset TCP o “destination unrechable†UDP) oppure mediante un’integrazione tra IDS e firewall, che si concretizza con una modifica delle policy del firewall in accordo con quanto ritenuto pericoloso dall’IDS.
Sebbene queste tecniche di reazione all’attacco siano molto richieste e fornite da tutti i prodotti, si tratta di un’estensione del concetto di IDS attualmente poco usata per i seguenti motivi:
- pone la rete a rischio di DoS (Denial of Service): per esempio cosa succede se l’attaccante usa un IP che non è realmente il suo ?
- richiede una totale fiducia verso la capacità di rilevazione dell’IDS: cosa accadrebbe se un falso positivo blocca connessioni lecite?
In sostanza, un IDS è uno strumento di rilevazione con delle aggiunte di reazione, non va inteso come uno strumento che blocca dei tentativi di intrusione o degli accessi non autorizzati.
INTRUSION PREVENTION
Una nuova frontiera del mercato degli IDS è il concetto di Intrusion PREVENTION.
Fondamentalmente un sistema di Intrusion Prevention non e’ altro che un NIDS messo INLINE (come bridge o come router) che fornisce le caratteristiche di blocco proattivo del traffico ritenuto pericoloso come menzionato prima.
In questo caso non si parla di Intrusion Detection ma di Intrusion Prevention, con tutti gli svantaggi esposti per i sistemi INLINE.
Se con un IDS possiamo generare allarmi in tutta tranquillità , sia per traffico inequivocabilmente malevolo che per traffico incerto, un sistema INLINE deve bloccare le connessioni se esse sono certamente indesiderate.
Tuttavia l’Intrusion Prevention non è da considerare come una frontiera negativa, ma è importante capire che è una tecnologia profondamente diversa dall’ Intrusion Detection.
La filosofia dell’Intrusion Prevention si può riassumere con la frase:
“se sappiamo che è sicuramente un attacco, perché non fermarlo?â€
La filosofia dell’Intrusion Detection è esposta meglio con la frase:
“se c’è qualcosa di strano lo voglio sapereâ€
I produttori di firewall si stanno muovendo rapidamente per inserire nei loro prodotti delle funzionalità di Intrusion Prevention: la stessa Checkpoint, leader di mercato, da oltre un anno spinge il suo SmartDefense che è una parte integrata in FW-1.
Dato che un Intrusion Prevention blocca attacchi conosciuti, e riconosciuti in modo inequivocabile, credo che possa aggiungere poco alla security di un’azienda dove i sistemi sono tenuti costantemente aggiornati.
Dove invece può effettivamente aiutare è nelle piccole realtà , dove non è presente del personale che si occupa di security o che comunque ha conoscenze in materia.
Solo il tempo e le forze di marketing ci potranno dire come si evolveranno questi prodotti…
MANTENERE UN IDS: FALSI POSITIVI E FALSI NEGATIVI
L’IDS è uno strumento di monitoring che va continuamente aggiornato e tenuto sotto controllo perché lavori in maniera efficiente.
L’efficacia di un IDS è nulla senza un costante controllo e un accurato tuning del sistema di rilevazione in relazione alla tipologia ed alla mole di traffico presente sulla rete.
E’ importante capire anche cosa rileva un IDS, poiché a differenza di quanto suggerito dall’acronimo non rileva solo le intrusioni.
Grazie alla sua capacità di analizzare tutto il traffico permette di rilevare:
- attacchi
- tentativi non riusciti
- scansioni
- pacchetti malformed
- accessi ritenuti sensibili (root, administrator)
Qualunque tecnologia di rilevamento utilizzi l’IDS, ci si scontrerà sempre con il problema dell’affidabilità di funzionamento nella parte di rilevazione eventi.
In particolare il problema che all’inizio può apparire banale ma che in realtà è comune quando si parla di analisi del traffico, è distinguere le reali anomalie della rete dagli errori di rilevazione dovuti ad una errata configurazione dello strumento. Sbagliare la regolazione dello strumento è molto facile. Ad esempio facendo una configurazione molto rigida ci si trova di fronte ad una mole di segnalazioni che rendono inutile e difficile l’analisi del traffico. Al contrario non ponendo nessuna restrizione sembra che la rete funzioni in maniera ottimale quando, in realtà non è così.
Nella letteratura questi eventi si chiamano: falsi positivi e falsi negativi. I falsi positivi si verificano quando viene rilevata un’intrusione che in realtà non è tale mentre i falsi negativi accadono quando non viene rilevata un’intrusione che invece c’è stata.
Una particolare categoria di eventi vengono comunemente chiamati “rumore†(in inglese noise). Per spiegarla ci serviamo di un esempio:
Ammettiamo di avere un web server che fa uso di Microsoft Internet Information Server. Nel momento in cui il nostro IDS rileva un’exploit per la “chunked encoding vulnerability†di Apache, questo non è un falso positivo, in quanto l’attacco c’è stato, ed è probabilmente reale. Tuttavia, dal momento che noi non “soffriamo†di quella vulnerabilità , questo evento è per noi non rilevante.
Questo tipo di informazione va sotto il nome di “rumore di fondo†di un IDS.
La fase di messa a punto di un IDS è molto ampia e complessa e viene di solito attuata in accordo con le politiche di sicurezza adottate dalla corporate/azienda.
FASE DI PROGETTAZIONE: DOVE POSIZIONARE UN nIDS
Quando si valuta l’introduzione nella rete di uno strumento di monitoring come un NIDS è fondamentale capire quale sarà il punto migliore in cui collocarlo.
Un IDS di tipo offline lavora in modo passivo, “sniffando†da un’interfaccia promiscua il traffico e analizzandolo.
Per stabilire il punto migliore vanno fatte due importanti considerazioni:
ormai le reti aziendali fanno largo uso di switch, che a differenza degli hub non replicano il traffico su tutte le porte ma lo inoltrano solo su quella dove è presente il mac-address a cui il pacchetto è destinato.
Si sono diffuse le VLAN, reti virtuali che permettono la separazione a L2 del traffico
In situazioni di questo tipo per permettere ad un nIDS di analizzare il traffico occorre “fornirgli†una copia del traffico.
Un NIDS analizza il traffico che riesce a vedere e che noi gli permettiamo di vedere.
Si può scegliere se posizionare un IDS prima o dopo i firewall aziendali.
Le linee guida da seguire sono:
- l’IDS deve vedere tutto il flusso di dati di una connessione. Situazioni di routing asimmetrico (es. più link internet) rischiano di rendere il funzionamento dell’IDS inutile!
- Gli IDS analizzano bene un link 100 mbit, i più prestanti raggiungono a fatica il Gbit. Se avete davvero tanto traffico prima di considerare l’acquisto di un super-IDS valutate la possibilità di analizzare meno traffico: quello più importante.
- Posizionate l’IDS in un punto dove può vedere traffico non solo da internet ma anche tra reti interne
- Se mettete un IDS dietro firewall, esso potrà analizzare solo quanto consentito dalle policy, perdendosi tutti gli attacchi verso il firewall stesso
TECNICHE DI RILEVAZIONE DELLE INTRUSIONI
Tutti i gli IDS che possiamo trovare in giro per la rete utilizzano tre tecniche principali: pattern matching, protocol decoding, anomaly detection [1].
Tutti gli IDS prodotti basano la loro efficacia su una o più combinazioni di queste metodologie di rilevazione.
Ognuna di queste metodologie presenta significativi vantaggi e degli svantaggi poiché i vantaggi di una tecnica sono al tempo stesso i punti deboli di un’altra.
Da segnalare una cosa, a nostro avviso molto curiosa, il core di tutti gli IDS in commercio viene progettato per implementare al meglio una soltanto di queste tecniche a causa dei problemi computazionali al quale vanno in contro gli algoritmi di confronto ed analisi.
I cores di Dragon e Snort utilizzano per lo più sofisticati algoritmi di pattern matching per rilevare anomalie.
Altri prodotti, come ad esempio ISS RealSecure, si vantano di non fare “semplice†pattern matching, ma di decodificare i protocolli alla ricerca di anomalie (anomaly detection), così da minimizzare i falsi positivi.
Ovviamente ogni soluzione software utilizza oramai entrambe le tecniche, il percentuali diverse (Snort e Dragon sono nati come pattern matching “puriâ€, ma ora implementano anche un poco di protocol analysis).
Pattern Matching
Questa è la tecnica basata sulla ricerca di signature all’interno dei pacchetti che transitano sulla ns rete. Una situazione classica è quella di ricercare una particolare stringa che appare sempre in uno specifico Trojan come “Hacked by pl4gu3z†oppure specifici shellcode noti.
Ha come vantaggio una grande affidabilità e una indubbia velocità ; di contro, basta variare 1 bit nel pacchetto perché la signature non venga rilevata.
Inoltre è un tipo di rilevamento buono solo per gli attacchi già noti, per i quali esiste appunto una signature. Altri tipi di attività non possono essere rilevati così facilmente.
Anomaly Detection
Questa tecnica ha due sottocategorie: rilevamento di anomalie nel flusso di traffico o nel protocollo.
Protocollo
Questa implementazione non decodifica il protocollo ma analizza tutti i campi dei pacchetti in cerca di anomalie nella loro struttura.
Per capire meglio questa tecnica facciamo l’esempio di un attacco in cui si cerca di compromettere il protocollo SSL durante la negoziazione della sessione.
In questa fase le regole del protocollo prevedono che il campo Key Argument abbia una lunghezza predefinita mentre in alcuni casi se un’attaccante compone un pacchetto specificando una chiave di dimensioni diverse il sistema IDS è in grado di rilevare l’anomalia.
Flusso di traffico
Cerca anomalie analizzando il traffico sulla rete.
Un esempio può essere un port scan, oppure un FTP server che inizia ad effettuare connessioni TELNET verso l’esterno, o ancora un numero esagerato di connessioni che possono essere fonte di sospetti.
Questa tecnica permette generalmente di rilevare una anomalia successiva ad un tentativo di intrusione andato a buon fine, ma fatica a rilevare i tipi di attacchi che vengono evidenziati con le altre tecniche.
Protocol Decoding
Questa tecnica rappresenta un po’ un cross tra le due precedenti tecniche. Si basa principalmente sul fatto che i pacchetti inviati siano RFC compliant e ricerca in maniera mirata anomalie dovute a campi incompleti e riempiti con valori pseudo-casuali.
Il problema più grosso di questa metodologia è che molte applicazioni non implementano in maniera rigorosa le specifiche RFC vanificando di fatto l’utilizzo di questa tecnica.
SNORT
Snort [5] è un prodotto che viene distribuito secondo la licenza GPL open-source. E’ stato creato da Marty Roesch.
Nonostante venga descritto come un IDS “leggeroâ€, le sue prestazioni sono più che buone per permetterne l’uso in grandi reti aziendali. E’ di fatto l’IDS più usato al mondo (si veda: “This little pig guards the market†[7] ).
Il primo impatto con uno strumento di questo tipo devo ammettere che non è il proprio massimo a causa della documentazione. Per lo più si tratta di articoli scritti da sviluppatori ed esperti di sicurezza ed il manuale utente offre solo una visione sommaria delle potenzialità dell’applicazione. Snort soffre di carenza di documentazione organizzata in modo organico quindi è necessario spendere del tempo per pianificare le attività da svolgere.
Se la documentazione in generale non è il massimo il sito ufficiale del prodotto contiene dei links da dove poter di scaricare molte regole di esempio pronte per l’uso e di file di configurazione che gli utenti hanno messo a disposizione.
La sua architettura è strutturata su tre moduli principali:
- Packet decoder
- Detection engine
- Logging Alert system
Vedremo poi un componente aggiuntivo molto usato: Acid
L’intera configurazione dell’applicazione viene gestita con dei file di testo ben commentati.
Packet decoder
Questo modulo dell’applicazione si occupa di catturare tutti i pacchetti che passano nella rete e decodificarli per passarli alla detection engine.
Tutto questo strato architetturale è completamente basato sulle Berkley Packet Filter. Il quale consente l’accesso al livello data link della rete.
Detection engine
La detection engine è il modulo del sistema svolge il vero lavoro dell’IDS. Analizza tutto il traffico applicando delle regole di detection utilizzando un algoritmo di Pattern Matching davvero efficiente.
Praticamente in un file di testo vengono specificate le regole da applicare sui pacchetti e le relativa azioni da compiere in caso affermativo o meno (generare un alert o mandare un sms).
Questo file di configurazione viene scritto interamente utilizzando un apposito linguaggio per descrivere le opzioni.
Esistono numerose signatures, ed è molto facile creare le proprie.
Logging & Alert system
Questo è quello che potremmo definire il sistema di output dell’intero applicativo. Mediante questo modulo Snort permette di visionare tutte le attività di interesse per l’amministratore di rete.
Ci sono vari modi per avere un output dal sistema:
- Pass: il pacchetto vieni ignorato
- Log: scrive il pacchetto usando la routine di logging
- Alert: genera un allarme e notifica l’admin nel metodo prescelto. Ci sono due tipi di allarme: Full alert che consiste nella registrazione dei messaggi di allarme e dell’header completo del pacchetto IP ed il Fast alert che consiste nella registrazione delle informazioni più importanti dell’header dei pacchetti sospetti
In questo senso, Snort delega la configurazione degli alert e del sistema di log completamente a carico dell’amministratore.
Un’altra pecca consiste nell’analisi dei dati registrati che viene lasciata interamente all’utente finale. Esistono comunque molti altri prodotti open-source che possono essere uniti ed integrati per creare un proprio IDS puzzle.
La gestione dei sensori Snort non è così semplice e veloce come sarebbe quella di prodotti commerciali, che vengono forniti con console integrate e semplici tool di gestione. Anche le funzioni di Analisi dei dati e il Reporting non sono semplici.
Acid
L’ Analysis Console for Intrusion Databases (ACID) [6] è un motore di analisi basato su PHP in grado di effettuare ricerche e processare dati contenuti in un database di eventi generati da Snort. Si compone di un’interfaccia per creare ed eseguire QUERY, di un packet viewer/decoder, di un modulo di gestione degli alerts ed è in grado anche di generare gradevoli grafici relativi alla distribuzione temporale degli alert, o della distribuzione degli stessi per sensore, o per indirizzo IP, o per tipo di attacco, per porte ecc. E’ stato creato come parte del progetto ed è comunemente considerato come l’interfaccia più completa disponibile per l’uso con Snort.
Il più grosso vantaggio è di essere Web-Based, che la rende facilmente personalizzabile e non obbliga ad usare un programma compilato come console (come per altri prodotti, che vantano una console unica).
Questo permette ad esempio di avere console multiple aperte nello stesso momento sullo stesso database.
Add-on
Ci sono altre componenti open-source (anche se in questo campo il solo limite all’integrazione e’ dettato dalla fantasia) che possono essere usate per arricchire “l’esperienza snort” e renderlo più facilmente gestibile.Per una conoscenza esaustiva a riguardo di altri progetti open-source integrabili con snort, rimandiamo a sito del progetto dove ne potrete trovare numerosi nell’area download o nella documentazione. Citiamo qui per brevità solo i più noti:
- SnortSnarf [7]: è un’altra applicazione (perl based) che analizza gli Alert di Snort e li pubblica in chiari e leggibili pagine web. Non sostituisce completamente le funzionalità di ACID, ma può essere complementare ad esso. La società che lo produce, SiliconDefense, offre anche supporto per implementazioni di Snort su windows, e fornisce numerosi documenti a riguardo sul proprio sito.
- STunnel [8]: è la più usata alternativa a SSH (che comunque a buon bisogno lavora piuttosto bene) per cifrare le comunicazioni tra i sensori Snort e il database, comunicazioni che altrimenti avvengono in chiaro
- SnortCenter [9]: è un’applicazione web che si poggia su un sistema di agents e manager, che permette di gestire la configurazione e l’update dei sensori Snort in maniera centralizzata. Gira in ambiente linux/unix ed è probabilmente la più completa soluzione di questo tipo.
- IDS Policy Manager [10]: anche questo prodotto di Activeworx si occupa della gestione remota e centralizzata dei sensori snort. E’ mirata agli amministratori di snort in ambiente windows piuttosto che linux, o anche ambiente misto, ma comunque è un’applicazione win32. IDS Policy Manager evita – a differenza di SnortCenter – di dover distribuire un agente separato che si occupi di configurare snort macchina per macchina, ed invece genera i file di configurazione e ne effettua un push dalla console verso i sensori per mezzo di SCP o FTP
Al di là dei prodotti già citati, e dei numerosi che si potranno trovare sul sito, vi rimandiamo anche a “Updated Snort Enterprise Implementation†[11].
Per conto suo Snort è un tool piuttosto scarno, e richiede molte personalizzazioni per arrivare a gestire il tutto nella maniera desiderata, ricevere allarmi ed effettuare reports.
E’ in pratica una soluzione “fai da teâ€, molto probabilmente troppo difficile per coloro che non abbiamo una ragionevole esperienza nell’uso di Unix/Linux.
Ma per chiunque altro, che abbia quel tipo di esperienza, Snort sarà sicuramente un’esperienza molto positiva. E’ un bel prodotto, molto potente, e la sua natura open lo rende senza dubbio l’IDS più flessibile che esista sul mercato.
In ogni caso, dopo le difficoltà iniziali, una volta che tutto è “up and running†richiede molta poca manutenzione (se si esclude l’obbligatorio aggiornamento delle signatures).
Se configurato correttamente, dimostra prestazioni uguali o migliori di altri prodotti commerciali che costano migliaia di euro.
NOTA: Marty Roesch, il suo creatore, è ora CEO della sua propria azienda (sourcefire.com) che vende questo software, non così semplice come quello rilasciato al pubblico gratuitamente, ma nella forma di appliances ottimizzate, provvisto di interfacce di analisi dei dati e di supporto commerciale.
E’ importante tenere presente qui che stiamo parlando del semplice prodotto open-source, che ancora deve essere integrato in un “framework casalingo†con vari altri software open-source. NON stiamo parlando del prodotto commerciale di Sourcefire.
DRAGON
Dragon [12] è un prodotto di Intrusion Detection commerciale tra i più venduti ed apprezzati al mondo.
Vediamo brevemente di capire come di caratterizza la sua architettura e quali sono i suoi punti di forza.
Dragon si presenta come un sistema di Intrusion Detection completo, i cui componenti della famiglia sono:
- Network Sensor
- Host Sensor
- Policy Manager
- Analisys Console
Quando ci si approccia all’architettura di Dragon la prima impressione è di smarrimento: svariati componenti client, server, agent e possibilità di svariate combinazioni.
Tutto diventa più chiaro dopo un po’ di pratica e quando si capisce l’essenza del prodotto: nonostante la natura commerciale, Dragon ha una filosofia molto aperta. Niente è tenuto nascosto, tutto è ben documentato e nella maggior parte dei casi customizzabile.
La presenza di componenti separati per le varie funzioni consente di poter “creare†l’architettura di Intrusion Detection che meglio si addice alla nostra rete: si può passare da un’installazione single-host (cioè tutto su un singolo server) ad una configurazione distribuita su più sedi, con diversi sensori, diversi punti di raccolta e controllo degli eventi e un unico punto di gestione centralizzata delle policy.
Considerate anche che le configurazioni vengono sempre mantenute in file di testo pienamente modificabili sia a mano che tramite l’apposita interfaccia grafica completamente web-based.
Questa filosofia non stupisce più di tanto se si va a dare uno sguardo alla storia del prodotto.
Dragon nasce dal genio di un pioniere del settore, tale Ron Gula che ha scritto e tuttora mantiene il codice di questo IDS.
Successivamente il prodotto è stato acquistato da Enterasys, azienda presente da diversi anni nel settore della sicurezza e con una gamma di prodotti che spazia dai VPN Gateway fino a prodotti di gestione di reti wireless.
Network Sensor
Enterasys fornisce il suo NIDS sia come software da installare su macchine Linux / Solaris che come un classico appliance linux-based.
Questo sensore basa la sua capacità di rilevamento principalmente sul pattern matching, in cui ogni pacchetto viene confrontato con un set di signature completamente personalizzabili contenute in un file di testo e memorizzate con una sintassi semplice e ben documentata.
Una caratteristica interessante è la possibilità di scrivere signature “dinamicheâ€, in cui l’evento viene rilevato solo se sulla stessa connessione è stato precedentemente rilevato un altro evento per esempio un login FTP riuscito può essere interessante solo se prima è stato rilevato un tentativo di accesso FTP come utente root.
Ma Dragon non basa il rilevamento solo su quello: ogni pacchetto viene pre-processato in una fase in cui vengono fatti controlli di protocol analisys e misure detection.
Questi controlli comprendono:
verifica dell’intestazione del pacchetto
evitare le tecniche di IDS-evasion come la frammentazione, gli attacchi al TTL (Time To Live del pacchetto) o l’utilizzo di un encoding web non standard
generare eventi se la connessione è ritenuta un utilizzo anomalo della rete: scan, connessioni a certi host/porte prestabilite.
Il NIDS ha anche una parte attiva in cui è possibile bloccare delle connessioni ritenute pericolose, con possibilità di impostare una soglia ad esempio reset dopo 3 eventi rilevati oppure di bloccare a priori certi tipi di traffico.
Quando viene rilevato un evento è possibile inoltrarlo ad un componente server che lo manterrà in un ring di memoria e che lo memorizzerà anche in un DB binario per le analisi successive.
Host Sensor
L’HIDS di Dragon è davvero uno strumento di monitoring della macchina completo.
Disponibile per molti OS, è in grado di controllare:
- l’integrità dei file (md5), con possibilità di tenere l’archivio degli MD5 su una macchina separata
- la modifica di permessi, dimensione, data e ora, incremento eccessivo dei file
- i log della macchina, alla ricerca di signature predefinite
- lo stato delle porte dello stack IP, per verificare backdoor o trojan
- traitem SNMP e attività syslog, che permettono di monitorare da un HIDS altre macchine che lo usano come syslog o SNMP server
- registro eventi di windows
- registro di windows
- il kernel alla ricerca di rootkit
- emula dei servizi (funzionalità di honeypot)
Questi sono solo alcuni dei controlli, inoltre è possibile scriverne di altri (per esempio per controllare un database attraverso delle query) avendo a disposizione tempo, pazienza e un po ‘di conoscenze di programmazione.
Le policy di default presenti per l’HIDS forniscono una serie di controlli sui file basati sull’OS, inoltre ci sono una serie di signature per i file più importanti che ci permettono di vedere cosa effettivamente contengono o NON contengono (signature a logica negativa).
Policy Manager
Il Policy Manager permette di gestire i sensori, le policy e le signature attraverso un’interfaccia web.
Consente di:
- monitorare lo stato dei sensori
- aggiungere/modificare/eliminare sensori
- modificare policy e signature
- installare, da un punto centrale, le configurazioni di uno o più sensori
Analisys console
Questa interfaccia web permette l’ analisi degli eventi attraverso differenti componenti:
- Realtime Monitor: analizza gli eventi presi dalla memoria, consentendo analisi veloci sulle ultime attività dei sensori
- Forensic Console: permette l’analisi di eventi memorizzati nel DB binario di Dragon, con la possibilità di ricostruire sessioni e vedere il traffico effettivamente catturato dal sensore durante la rilevazione dell’evento
- Trending Console: basandosi sui dati contenuti in un DB relazionale (di default mySQL) consente di analizzare l’andamento dell’attività degli IDS su archi di tempo personalizzabili
- Reporting tool: strumento di reporting, fornisce alcune visualizzazioni degli eventi da fornire all’executive
- Alarm Tool: strumento di gestione degli allarmi tramite mail, syslog, SNMP o script custom
In definitiva, Dragon è un prodotto per esperti ma che consente proprio a loro di ritagliarsi un’architettura di Intrusion Detection che di sicuro non li deluderà .
Se invece si decide di mettere in azienda un IDS solo per moda e senza sapere esattamente cosa si vuole, allora ci sono altri prodotti più semplici da utilizzare e pensati per chi non vuole addentrarsi troppo a basso livello.
I suoi punti di forza a mio avviso più importanti sono:
- filosofia “openâ€
- alto livello di customizzazione e integrazione di script
- HIDS molto completo
- Gestione centralizzata di NIDS e HIDS
Una nota negativa va però ai report: è molto forte la richiesta del mercato di report di alto livello da presentare alla dirigenza aziendale (magari per far capire il valore dell’investimento!) e in questo Dragon si mostra ancora come uno strumento puramente per tecnici.
CONCLUSIONI
In questo documento abbiamo visto cosa fa un IDS, perché lo fa e come.La lettura di questo e altri documenti non è però tutto quello che serve per poter decidere di implementare questa tecnologia nella propria rete: l’esperienza gioca un ruolo molto importante.
Dovrete valutare la quantità e il tipo di traffico che avete, capire cosa passa nella vostra rete per rendervi conto di quello che deve sorvegliare un sistema IDS.
Dovrete anche mettervi in testa che sarà necessario dedicarci molto tempo, sia nella fase iniziale di messa a punto che successivamente, in modo costante.
Per chi è abituato a gestire una rete e un firewall, mettere le mani su un IDS sarà un’esperienza molto interessante: qui occorre conoscere i protocolli da livello 2 fino a livello 7, e non si smette mai di imparare.
Purtroppo la filosofia e i vantaggi che stanno alla base di questa tecnologia non sono ancora chiari a tutti, soprattutto a quelle persone che devono poi deciderne l’implementazione e soprattutto gli investimenti all’interno dell’azienda.
Questo ha fatto in modo che fino ad ora si sia solo parlato molto di IDS, ma senza mai tradursi in qualcosa di concreto.
Il futuro vedrà una diffusione dei sistemi di Intrusion Prevention che potranno fermare un buon numero di attacchi noti, ma che porteranno le minacce ad evolversi ancora di più verso il livello applicativo.
E’ lì che la perfetta conoscenza del nostro sistema informativo, dalla rete all’applicazione, unita ad un buon IDS avranno il loro spazio.
NOTE SUGLI AUTORI
Daniele Besana lavora presso un system integrator che fornisce soluzioni di sicurezza per grosse aziende. E’ certificato, tra le altre cose, ESS (Enterasys Security Specialist) su Dragon. Fondatore di IT Virtual Community (www.itvirtualcommunity.net)
Massimo Matricardi tesista presso il laboratorio LTA dell’università degli studi di Milano-Bicocca, si interessa ormai da tempo alla sicurezza dei sistemi informatici applicata al Software Design. E’ appassionato di open-source e ideatore e coordinatore della rivista web Mibmagazine disponibile su www.mibmagazine.it
Daniele Muscetta lavora come Security Officer di una azienda nei Paesi Bassi, dove vive con la propria famiglia. Pubblica regolarmente articoli su IT Virtual Community (www.itvirtualcommunity.net), sul proprio WebLog sul sito personale http://www.muscetta.com/ e su varie mailing lists di ambito sicurezza informatica.
RIFERIMENTI
- “Intrusion Detection Methodologies Demystified†by G. Golomb
www.enterasys.com/products/whitepapers/9013198.pdf - “Broadening the scope of penetration-testing techniques†by R. Gula
www.enterasys.com/products/whitepapers/security/9012542.pdf - SANS Security Reading Room – http://www.sans.org/rr
- “This little pig guards the marketâ€
www.theage.com.au/articles/2002/09/22/1032055006051.html - SNORT – http://www.snort.org/
- ACID – http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html
- SnortSnarf – http://www.silicondefense.com/
- STunnel – http://www.stunnel.org/
- SnortCenter – http://users.pandora.be/larc/
- IDS Policy Manager – http://www.activeworx.com/
- “Updated Snort Enterprise Implementation†by E. Lubow
www.linuxsecurity.com/articles/documentation_article-7137.html - Dragon – http://dragon.enterasys.com
- AirCERT – http://www.cert.org/kb/aircert/
- Network Security Resource – http://www.networkintrusion.co.uk/