Laurea triennale in Informatica. Tesi di Laurea: Valutazione degli strumenti User Defined. Prof. Francesco Bergadano. Massimiliano Faudarole

Transcript

1 Università degli studi di Torino Facoltà di scienze Matematiche Fisiche Naturali Laurea triennale in Informatica Tesi di Laurea: INTRUSION DETECTION SYSTEM Valutazione degli strumenti User Defined Relatore: Correlatore: Candidato: Prof. Francesco Bergadano Massimiliano Faudarole Lorenzo Antonio Carella Anno Accademico 2003/2004 Sessione Straordinaria di Febbraio 2004

2 A tutte le persone che mi hanno sostenuto ed aiutato, in particolare ai miei genitori, per aver sempre creduto nelle mie capacità. ii

3 INDICE INTRODUZIONE... 1 CAPITOLO 1 LA SICUREZZA DELLE INFORMAZIONI UN PO DI STORIA COS È LA SICUREZZA LA SICUREZZA È FONDAMENTALE L età d oro degli hacker I RISCHI PERCHÉ CONVIENE DIFENDERSI Considerazioni legali I costi COSA SI PUÒ FARE Investire nei meccanismi di difesa Trovare l anello debole Sensibilizzare i dipendenti RIASSUMENDO...12 CAPITOLO 2 SISTEMI INTRUSION DETECTION LA PROTEZIONE PASSIVA NON BASTA TIPOLOGIE DI SISTEMI ANTINTRUSIONE SISTEMI NIDS Signature Based Detection Anomaly Detection REAZIONE AL TRAFFICO SOSPETTO LIMITI DEI SISTEMI NIDS Limiti della Signature Based Limiti della Anomaly detection POSIZIONARE UN NETWORK IDS PROBLEMI DA AFFRONTARE...24 iii

4 Indice Reti fortemente trafficate Reti switched Reti locali asimmetriche Traffico cifrato Sensori malfunzionanti Protocolli non supportati LE SOLUZIONI ESISTONO...30 CAPITOLO 3 IL VALORE DELLA FLESSIBILITÀ NIDS USER DEFINED IDS PRESI IN ESAME Snort McAfee IntruShield ISS Realsecure CAPITOLO 4 SNORT COMPONENTI DI SNORT Packet Capturing e Decoding Engine Rules parsing e detection engine Logging engine Plugin e preprocessor engine LA FLESSIBILITÀ DI SNORT Le regole IMPLEMENTAZIONE DI SNORT Sistema Operativo Web server Snort MySQL PureSecure PROVA EFFETTUATA Le rules create Opzioni escluse Risultati ottenuti Conclusione iv

5 Indice CAPITOLO 5 MCAFEE INTRUSHIELD COMPONENTI DI INTRUSHIELD IntruShield Sensor IntruShield Security Management System IntruVert Update Server FLESSIBILITÀ DI INTRUSHIELD Policy editor User-defined signature IMPLEMENTAZIONE DI MCAFEE INTRUSHIELD PROVA EFFETTUATA Conclusione CAPITOLO 6 ISS REALSECURE COMPONENTI DI REALSECURE FLESSIBILITÀ DI REALSECURE Derivare le Policy IL MODULO TRONS Attivare TRONS Sintassi Esempio di file per TRONS Riscontro di un evento IMPLEMENTAZIONE DI REALSECURE PROVA EFFETTUATA Prima fase Risultati ottenuti nella prima fase Seconda Fase Risultati ottenuti nella seconda fase Conclusione CAPITOLO 7 CONSIDERAZIONI FINALI LE TRE GRANDI STRADE POSSIBILI IMPLEMENTAZIONI v

6 Indice CONCLUSIONI RINGRAZIAMENTI BIBLIOGRAFIA vi

7 INTRODUZIONE In qualunque settore di lavoro Internet è diventato indispensabile, aprendo orizzonti che prima erano soltanto immaginabili. Come spesso avviene per le nuove tecnologie, ci sono aspetti sia positivi sia negativi. Quelli positivi sono riconducibili ad esempio, alle enormi opportunità commerciali, mentre tra quelli negativi risaltano i sempre più elevati rischi nel settore della sicurezza delle informazioni. Desta inoltre preoccupazione l inconsapevolezza o quantomeno la poca attenzione che le aziende pongono nei confronti di questi pericoli. Molti considerano la sicurezza come qualcosa da implementare a posteriori: prima costruiscono la rete con tutti i suoi componenti, poi aggiungono un firewall o altre misure di sicurezza. Come è stato dimostrato dall aumento del numero di sistemi violati, questo modo di procedere non è efficace. La sicurezza non è un optional che si aggiunge alla fine: deve essere prevista nel progetto fin dall inizio. Le aziende non possono aspettare di subire un attacco per agire, devono attuare politiche di sicurezza in maniera preventiva. I sistemi di protezione andrebbero studiati in modo che un attacco richieda molto tempo per essere portato a termine, così da permettere, grazie a sistemi di rilevamento delle intrusioni, l intercettazione dell attaccante. Tanto prima si rileva un problema, tanto minori saranno i danni sofferti. Se un attacco viene rilevato immediatamente, vi si può rimediare in tempi brevissimi, senza la necessità di fermare la rete; se, invece, passano ad esempio, due settimane senza accorgersene, possono servire diversi giorni di lavoro per rimediare, probabilmente con l obbligo di disattivare la rete. Un firewall è un buon punto di partenza, ma solo un punto di partenza, non una soluzione finale. Idealmente, un azienda dovrebbe disporre di un sistema di rilevamento delle intrusioni (definito IDS, acronimo di Intrusion Detection System) in grado di rilevare un attacco e segnalarlo immediatamente agli addetti alla sicurezza, così da permettere l uso di contromisure capaci, in alcuni casi, di fermare l attacco prima che possa procurare danni. Spesso, avere un rapporto di tutti gli eventi di rete, che consente 1

8 Introduzione di fare un analisi forense, è l unico modo per capire se i propri sistemi stanno per essere compromessi, oppure lo sono già. In sostanza è necessario un approccio composito, perché un solo meccanismo di sicurezza non è sufficiente. Solo integrando armonicamente più sistemi, come ad esempio diversi firewall, un sistema di rilevamento delle intrusioni (IDS), un controllo attivo dei rapporti dell attività di rete (log), accessi telefonici sicuri, reti virtuali private, un buon sistema di crittografia, password robuste e liste di controllo dell accesso, si può affermare di possedere un impianto di sicurezza robusto. Negli ultimi anni, grazie anche al perfezionamento dei sistemi antintrusione, le aziende si sono rese conto dell importanza di adottare tali sistemi per la protezione delle loro reti. Gli IDS sono ormai uno strumento fondamentale per la sicurezza informatica, perché oltre alla capacità di rilevare le intrusioni e in alcuni casi anche di prevenirle, consentono di registrare le attività della rete, fornendo un valido resoconto per lo studio delle debolezze e delle vulnerabilità della rete aziendale. Tuttavia, c è chi afferma che i sistemi antintrusione siano già superati, e che presto saranno sostituiti da nuove tecnologie. Forse questi pareri non tengono conto dell efficacia dimostrata dai prodotti IDS e delle potenzialità esistenti, che, in alcuni casi, non vengono ancora sfruttate completamente, ma soprattutto sono in contraddizione con il successo, che, negli ultimi anni, sta caratterizzando il mercato dei prodotti per la sicurezza informatica e in particolare di questi sistemi. Non si spiegherebbero, infatti, i continui investimenti affrontati dalle grandi case del settore IT nella ricerca e sviluppo di sistemi IDS sempre più potenti e flessibili, nonché la sempre maggiore richiesta, da parte del mercato. Le strutture che hanno già adottato la tecnologia IDS, sono in costante aumento e le loro esigenze sempre più pressanti; di conseguenza le case produttrici di questi sistemi puntano, sempre più spesso, a creare IDS, non solo efficaci nella rilevazione delle intrusioni, ma anche flessibili e adattabili a tutte le realtà aziendali. Quello che caratterizza la scelta di un sistema a scapito di un altro, non è più solo la capacità di rilevare gli attacchi. L aspetto sempre più importante è l impatto che questi prodotti possono avere sulla propria infrastruttura. Un sistema flessibile, capace di adattarsi alla rete aziendale, configurabile e implementabile dal personale della sicurezza, diventa oggi sempre più richiesto. Nasce inoltre la necessità di costruire prodotti capaci anche di discriminare le diverse tipologie di traffico, proprio, perché ogni azienda ha le sue caratteristiche e le sue peculiarità. 2

9 Introduzione Lo scopo di questa tesi è tentare di dare una panoramica della situazione attuale, tralasciando gli aspetti relativi alla capacità nel rilevamento delle intrusioni, che ormai, per i più diffusi sistemi IDS ha raggiunto lo stesso livello, focalizzando invece l attenzione su quello che le più grandi case produttrici hanno fatto per rendere questi sistemi più flessibili, aspetto che denota ancora grandi differenze tra un sistema e l altro ed ancora pienamente in fase di sviluppo. La tesi è il frutto di uno stage di quattro mesi, svolto presso l ufficio di Sicurezza Logica nel Centro Contabile di Moncalieri (Direzione MOI Macchina Operativa Integrata), del Gruppo Sanpaolo IMI s.p.a.. Il Gruppo Sanpaolo IMI s.p.a. è una delle principali realtà bancarie e finanziarie italiane, nonché il terzo gruppo bancario nazionale. Può vantare una diffusa presenza in quasi tutte le regioni italiane e un adeguato presidio territoriale in tutte le principali nazioni europee, in Asia e nel continente Americano, raggiungendo una base di clientela complessiva di circa 8 milioni di clienti. Grazie agli strumenti messi a disposizione dal Gruppo Sanpaolo IMI ed alla collaborazione del personale dell ufficio è stato possibile portare a termine questo lavoro. Nel primo capitolo della tesi vengono illustrate le ragioni di una politica di sicurezza delle informazioni. Nel secondo vengono presentati i sistemi IDS, per spiegare cosa sono e cosa fanno. Il terzo affronta le motivazioni che spingono le case produttrici a sviluppare sistemi IDS sempre più flessibili. I capitoli 4,5 e 6 affrontano il cuore di questo lavoro, descrivendo i sistemi presi in esame dal punto di vista della flessibilità e le prove effettuate per saggiarne le capacità di adattamento. Il settimo capitolo illustra alcune possibili soluzioni per ottenere un sistema di rilevazione delle intrusioni efficiente e flessibile; seguono, infine, le conclusioni. 3

10 CAPITOLO 1 LA SICUREZZA DELLE INFORMAZIONI Cos è la sicurezza delle informazioni? Perché è fondamentale implementarla? Conviene difendersi? Chi è a rischio e cosa bisogna fare per ritenersi sicuri? Queste e molte altre sono domande che prima o poi, chiunque fornisca un servizio in rete, deve affrontare. Le informazioni da proteggere possono essere qualsiasi cosa, ad esempio i dati anagrafici di un dipendente o cliente, o le password di accesso ad un server. Variano a seconda del contesto: ciò che è necessario proteggere per alcuni può essere totalmente indifferente ad altri. La sicurezza delle informazioni è soggettiva e mutevole. Soggettiva perché dipende dall ambiente in cui si sviluppa e deve essere adattata alle reali esigenze richieste. E inutile e costoso costruire la Grande Muraglia se si deve difendere un piccolo giardino. Mutevole perché quello che oggi si può definire sicuro non è detto che lo sia anche domani. Il processo della sicurezza va seguito e aggiornato costantemente, soprattutto se si pensa che ogni mese vengono scoperte nuove vulnerabilità nei software. 1.1 UN PO DI STORIA Il mondo informatico si è dovuto confrontare per la prima volta con il problema della sicurezza quando si è introdotto il concetto di condivisione delle risorse. La possibilità di condividere tra più utenti i programmi, le attrezzature e soprattutto i dati, ha costretto a riflettere sulla necessità di istituire delle politiche di accesso e utilizzo di queste risorse. Il primo esempio si è avuto con la nascita dei sistemi operativi multiutente, che ha portato alla luce il problema della riservatezza: i dati di ciascun utente andavano mantenuti privati e non esposti alle attività altrui. Le reti di computer sono nate principalmente con lo scopo di condividere l utilizzo di dispositivi, sfruttare in maniera più proficua risorse di calcolo e permettere la comunicazione tra utenti fisicamente distanti. Utilizzate inizialmente in ambito universitario, sono sorte senza porre attenzione al problema della sicurezza. 4

11 La sicurezza delle informazioni La rete Internet è sorta agli inizi degli anni 70 come progetto militare: è nata come rete ad alta resistenza da utilizzarsi in caso di conflitto mondiale; i sistemi interconnessi venivano considerati fidati: gli attacchi dall interno, ossia sferrati da macchine della rete stessa, non erano stati previsti. Oggi giorno però, la Rete ha un bacino di utenza enorme e assolutamente non preventivato (fig. 1). Alcuni utilizzi per cui viene sfruttata non erano previsti: la Rete non era sorta per compiere commercio elettronico, transazioni bancarie e fiscali. Questo tipo di impieghi costringe gli studiosi, oggi, a confrontarsi seriamente con le problematiche relative alla sicurezza. Figura 1 Crescita degli utenti Internet in Italia negli ultimi anni 1.2 COS È LA SICUREZZA Per maggiore chiarezza, è bene specificare cosa si intende con il termine sicurezza. La convinzione più popolare è che l obiettivo della sicurezza, nei computer, sia la segretezza: fare in modo che dati importanti e riservati non cadano nelle mani sbagliate. Questo aspetto, sicuramente importante, non è però l unico da considerare. Il termine sicurezza racchiude tre significati distinti: Segretezza. Un sistema sicuro non deve permettere che informazioni riservate siano accessibili a persone non autorizzate. 5

12 La sicurezza delle informazioni Integrità. Un sistema sicuro deve mantenere l integrità dei dati che in esso vengono conservati. Queste informazioni non devono poter essere corrotte dall intervento di malintenzionati, e se lo fossero, la modifica deve poter essere individuata con certezza. Disponibilità. Un sistema sicuro deve rendere disponibile l informazione agli utenti autorizzati in ogni momento. 1.3 LA SICUREZZA È FONDAMENTALE In un mondo dove non esistono più confini, dove tutti possono raggiungere tutti, e ogni informazione diventa reperibile, non è possibile lasciare la tutela di se stessi al caso. Sarebbe come abitare in una casa senza recinzioni, porte e finestre. L errore più comune è pensare di non essere a rischio. Molte aziende, non avendo mai subito attacchi (o forse non avendoli mai rilevati), credono di non aver bisogno di una politica di sicurezza. In realtà, così facendo, mettono seriamente a rischio il loro futuro. Gli stessi motivi che hanno reso Internet famosa, l hanno anche resa più pericolosa. La possibilità di accedere a qualsiasi informazione, di apprendere in modo più semplice e veloce, di ottenere la risposta a qualsiasi domanda, di condividere e sfruttare ogni tipo di software, hanno permesso a chiunque di diventare potenzialmente pericoloso. E diventato semplicissimo reperire tools capaci di sfruttare le vulnerabilità delle reti, e spesso vengono utilizzati per gioco da persone che non ne comprendono veramente il funzionamento, con il risultato di creare ancora più danni di chi porta l attacco scientemente. Sarebbe difficile credere che una azienda con l interesse di crescere voglia rischiare di restare in balia di questi giocatori. Ecco perché la sicurezza è indispensabile ed è indispensabile implementarla L ETÀ D ORO DEGLI HACKER Se si osservano gli avvenimenti degli ultimi anni, l enorme sviluppo di Internet, la facilità di accesso a risorse una volta riservate a pochi e l aumento della potenza di calcolo dei computer; diventa subito chiaro che questa è l età d oro degli hacker. In sostanza, essere hacker è molto vantaggioso: esiste un enorme numero di sistemi in cui è possibile entrare, molti hanno misure di sicurezza scarse o nulle, la maggior parte 6

13 La sicurezza delle informazioni delle aziende non posseggono informazioni o risorse sufficienti per individuarli ed anche se riuscissero ad accorgersi dell attacco, le possibilità di catturare i responsabili sono molto limitate. Gli hacker, quindi, possono scegliere le loro vittime in tutta tranquillità. Non esiste una polizia di Internet, e gli hacker hanno un grande vantaggio in termini di competenza ed esperienza (fig. 2). Figura 2 Rapporto fra la sofisticazione degli attacchi e le conoscenze degli Hacker Il numero degli hacker non può che essere destinato a salire, come lo è il numero degli utilizzatori di Internet. Quando quelli che ora giocano avranno acquisito l esperienza mancante e si saranno accorti che questi atti illegali possono portare profitti, avremo una nuova schiera di hacker, sempre più numerosa e capace. 1.4 I RISCHI Secondo le società produttrici di soluzioni per l IT security, i rischi per le aziende negli ultimi anni sono aumentati. Per il 2004 si prevede un aumento vertiginoso del numero di attacchi (fig. 3). 7

14 La sicurezza delle informazioni Incidenti Year Incidents Year Incidents ,334 2, Year Incidents 2,412 2,573 2,134 3,734 9, Year Q-3Q 2003 Incidents 21,756 52,658 82, ,855 Total incidents reported (1988-3Q 2003): 297, Figura 3 Numero di incidenti riportati da attacchi a sistemi aziendali (fonte: Le cause di rischio si possono attribuire a tre fattori: la diffusione capillare della Rete con il conseguente aumento delle informazioni accessibili; lo sviluppo di nuove tecnologie; la grande differenza di preparazione tra aggressori e vittime. Viste le prospettive per il futuro le aziende dovrebbero cercare di non farsi cogliere impreparate. Gli ambienti più a rischio sono: La protezione dei dati. Il valore reale del dato informatico è spesso sottovalutato da parte di chi lo possiede. Diviene vitale proteggere in maniera efficace i propri dati dai possibili rischi di distruzione,corruzione o copia. Questo aspetto può creare grossi danni economici alla azienda, soprattutto nei casi in cui l intruso agisce per profitto (ad esempio spionaggio industriale). Le transazioni finanziarie online. Generano problemi di sicurezza diversi e molto più complessi, come l affidabilità delle informazioni che transitano sulla rete; l affidabilità del servizio, che dovrebbe garantire l utilizzo di software esente da bug sfruttabili per effettuare operazioni illegali; la privacy degli utenti protetta da abusi esterni o interni. 1.5 PERCHÉ CONVIENE DIFENDERSI Quando un sistema viene collegato ad una rete di grandi dimensioni (o direttamente a Internet) per la maggior parte del tempo, rimane soggetto ad aggressioni di ogni tipo. 8

15 La sicurezza delle informazioni Per garantire la sicurezza dei sistemi in rete non esistono soluzioni definitive, ma solo delle regole indicative. Alle volte è sufficiente ignorare una carenza della versione particolare di un servizio attivo su un computer, per lasciare un varco aperto a disposizione di qualcuno che ne conosce l accesso. Esistono tre importanti motivi che spingono verso lo sviluppo di un buon sistema di difesa. Il primo deriva dalle responsabilità legali dell azienda, il secondo dai costi di riparazione dei danni subiti, mentre il terzo è legato al danno di immagine, spesso più critico dei primi due CONSIDERAZIONI LEGALI Dal momento in cui un azienda fornisce un servizio in rete installato su una macchina, accessibile al pubblico, si deve assumere delle responsabilità. Potrebbe capitare che altri sistemi vengano danneggiati da attacchi provenienti dalla propria rete compromessa in precedenza. Un sistema attaccato e compromesso può essere usato dall aggressore come piattaforma di lancio per inviare messaggi indesiderati (spam), rilevare informazioni sulla rete circostante per compromettere altre macchine, oppure, più in generale, a coprire azioni di attacco verso altri sistemi esterni, usando il primo come copertura. Diventa chiaro che la cosa più grave che deriva da un sistema compromesso è il rischio per l azienda proprietaria del sistema di essere coinvolta nelle attività illegali di altri, con la conseguenza di gravi perdite economiche e di immagine. La sicurezza non può essere ignorata neanche quando si ritiene poco importante per se stessi I COSTI La sicurezza ha un costo, ben valutabile, ma i cui "ritorni", se la sicurezza funziona, non si vedono; anche la "non sicurezza" ha un costo ed è quindi importante, nella pianificazione dei sistemi di sicurezza stabilire preventivamente il grado di rischio a cui viene sottoposto il sistema. Per poter dire che le informazioni sono sicure, è necessario che sia garantita la sicurezza in tutte le fasi del loro trattamento, acquisizione, trasmissione, elaborazione, archiviazione, gestione e presentazione. Si tratta di una catena, e la resistenza 9

16 La sicurezza delle informazioni complessiva è pari a quella dell'anello più debole: vanno quindi presi in considerazione con pari attenzione tutti gli aspetti del sistema informativo. Poiché la sicurezza assoluta non esiste e qualsiasi protezione può essere superata con uno sforzo adeguato, è necessario determinare il livello di sicurezza da raggiungere proporzionalmente al valore del bene da proteggere, e ad un analisi accurata per determinare il livello di rischio accettabile. La sicurezza deve essere quindi vista in termini "relativi" rispetto agli obiettivi da raggiungere. La spesa per la sicurezza è talvolta non indifferente e la decisione non è facile da prendere e da giustificare. E bene, però, valutare anche i costi della non sicurezza. La maggior parte degli interventi, effettuati dalle aziende, per elevare il livello della sicurezza è in molti casi legato all accadimento di eventi negativi, con la conseguenza di dover affrontare spese per rimediare ai danni subiti e spese per far in modo che l attacco non sia ripetibile. In altri casi, invece, l intervento per migliorare la sicurezza è più formale che effettivo, e questo comporta un altro insidioso rischio: la falsa sicurezza. Un conto, infatti, è essere coscienti che il sistema non è protetto, un conto è credere erroneamente che lo sia. La difficoltà maggiore per le aziende è quella di trovare il punto di equilibrio tra i costi indotti, cioè l effettiva perdita economica che potrebbe verificarsi nel caso di un attacco informatico, e i costi da affrontare per implementare i sistemi di sicurezza (fig. 4). L approccio alla sicurezza deve avvenire, quindi, in una logica di prevenzione piuttosto che in una logica di gestione delle emergenze e/o di semplice controllo. 1.6 COSA SI PUÒ FARE Le aziende considerano Internet come uno strumento utile a molti aspetti della loro attività, limitandosi ad analizzarne solo il lato economico. Bisogna cambiare mentalità e tenere conto anche dei requisiti di sicurezza. Se per mettere in pratica misure difensive si aspetta il momento dell emergenza, si arriverà in ritardo per limitare i danni. Nel settore informatico, in caso di attacco, per poter agire prontamente, è necessario aver preventivato una politica di sicurezza che attivi meccanismi di difesa adeguati. 10

17 La sicurezza delle informazioni Figura 4 Confronto fra costo della sicurezza e livello di protezione ottenuto INVESTIRE NEI MECCANISMI DI DIFESA Per avere un sito sicuro, è necessario disporre di due risorse: prevenzione e rilevamento. Molte compagnie si concentrano sulla prevenzione, ma trascurano il rilevamento. Oltre il 90% delle grandi aziende dispone di almeno un firewall, che è una misura preventiva, della quale occorre, però, analizzare due aspetti. Prima di tutto, è impossibile bloccare tutto il traffico, dunque nella rete aziendale ne deve entrare almeno una parte, che potrebbe essere vettore di attacco; ed in secondo luogo, molti meccanismi di prevenzione non sono progettati o configurati in modo corretto, dunque offrono una protezione scarsa o nulla. Le aziende dovrebbero implementare misure di sicurezza per impedire il maggior numero possibile di attacchi, tenendo però presente che è impossibile prevenirli tutti. Quando non si può bloccare un attacco, occorre quantomeno disporre di difese organizzate in modo da rilevare l attaccante prima che riesca a compromettere la rete. Anche in presenza di validi meccanismi preventivi, la capacità di rilevare tempestivamente un attacco renderebbe decisamente più efficace il sistema di sicurezza. 11

18 La sicurezza delle informazioni TROVARE L ANELLO DEBOLE Quando un hacker attacca un sito, sceglie sempre il percorso che offre minore resistenza. Dunque, è essenziale che le aziende siano consapevoli dei loro punti deboli, e che non concentrino tutti gli sforzi in un solo settore. Questo fa si che le prime necessità diventino una chiara politica di sicurezza e un preciso piano per ridurre i rischi. L obiettivo di un professionista della sicurezza è trovare l anello più debole e rinforzarlo prima che qualche malintenzionato lo attacchi. Lo scopo finale dovrebbe essere la correzione di tanti punti deboli, in modo da rendere molto difficile l accesso agli intrusi SENSIBILIZZARE I DIPENDENT I Oltre che ai necessari investimenti fatti per i sistemi di sicurezza, le aziende dovrebbero anche provvedere a sensibilizzare i propri dipendenti sui rischi esistenti legati ad una scarsa protezione delle risorse. Un azienda può essere in grado di implementare i meccanismi di difesa più performanti, ma rimanere comunque vulnerabile a causa della noncuranza dei propri dipendenti. L uso di password deboli, l installazione di software non autorizzato, l apertura di allegati di posta potenzialmente dannosi, sono alcuni tra i tanti motivi che possono creare falle nel sistema aziendale. Investire nella formazione del proprio personale diventa un ulteriore tassello, importante, per costruire un buon sistema di sicurezza. L azienda fornirà, inoltre, delle linee guida, sotto forma di policy, che gli utenti dovranno seguire. Questa soluzione è necessaria per porre una chiara distinzione fra ciò che è consentito fare e ciò che non lo è. La presenza di policy di sicurezza serve anche per tutelare dal punto di vista legale l azienda o permettere alla stessa di rivalersi sul dipendente negligente. 1.7 RIASSUMENDO La notevole diffusione di collegamenti permanenti, e a larga banda, ad Internet sta portando un numero sempre maggiore di aziende ad esporsi, senza alcuna precauzione, ai nuovi pericoli dell'informatica. Una rete collegata ad Internet è infatti continuamente soggetta ad attacchi da parte di elementi esterni. 12

19 La sicurezza delle informazioni Nella maggior parte dei casi, di attacco ai sistemi informativi, i "pirati informatici" che li portano sono degli esperti o appassionati di telematica che si divertono a penetrare nei sistemi delle aziende per soddisfazione personale; tuttavia in altri casi queste persone sono assoldate da aziende concorrenti per trarre vantaggio economico e/o commerciale in maniera scorretta. La crescente disponibilità di servizi online ha causato un forte aumento del tempo medio di permanenza in rete e questo ha conseguentemente incrementato la probabilità di subire intrusioni ed attacchi informatici casuali o deliberati. Inoltre le interazioni tra le aziende, fino a qualche tempo fa basate prevalentemente sullo scambio di documenti cartacei trasmessi a mezzo fax, si attuano oggi sempre più mediante la trasmissione di documenti elettronici (file) aumentando così la probabilità di diffusione dei virus informatici. Per questi motivi l adozione di sistemi di difesa delle risorse aziendali è diventata indispensabile. Sebbene non sia facilmente quantificabile la perdita economica che si avrebbe nel caso di un attacco portato a termine con successo, risulta chiaro che la soluzione vincente al problema rimane l attuazione preventiva di meccanismi di difesa. Meccanismi capaci sia di prevenire, sia di rilevare gli attacchi. Il tema della sicurezza è di primaria importanza anche da un punto di vista di immagine e di conseguenza economico; infatti, i clienti, così come i partner o i fornitori, daranno preferenza alle aziende che forniscono servizi e prodotti in maniera sicura rispetto a chi invece trascura questi aspetti. I clienti che mantengono rapporti con aziende che garantiscono servizi, non solo efficienti e qualitativamente validi, ma anche sicuri, si troveranno coinvolti in un processo di fidelizzazione che garantirà all azienda un più ampio margine di crescita futura nel settore di mercato in cui essa opera. 13

20 CAPITOLO 2 SISTEMI INTRUSION DETECTION L IDS (Intrusion Detection System) è un sistema di rilevazione e analisi del traffico in tempo reale che costituisce l estensione logica delle capacità di un firewall, mettendo a disposizione dell amministratore di sistema funzionalità, oggi, indispensabili per la gestione della sicurezza e fornendo strumenti per l analisi e il riconoscimento degli attacchi o delle anomalie del traffico, proveniente sia dall esterno, sia dall interno della rete aziendale. Oltre al riconoscimento degli attacchi, l IDS svolge anche funzioni di diagnostica di rete e di controllo sulla corretta applicazione delle policy di sicurezza. Inoltre, può essere configurato per reagire attivamente agli attacchi, intercettando i tentativi di connessioni sospette e bloccandoli in modo automatico. I motivi per cui si è resa necessaria l'introduzione di sistemi di rilevamento delle intrusioni sono: oltre alla necessità, da parte di individui o aziende, di tutelare le informazioni contenute all'interno dei propri sistemi informatici; anche aspetti legali e di responsabilità. Infatti sempre più spesso i sistemi compromessi vengono utilizzati per coprire attacchi verso reti esterne. In questo modo la responsabilità di questi ultimi attacchi viene a cadere sul proprietario del sistema da cui sono partiti, invece che sul reale attaccante. 2.1 LA PROTEZIONE PASSIVA NON BASTA I meccanismi di protezione passiva (i firewall) sono, semplicemente, macchine dotate di almeno due interfacce di rete, in grado di regolare il traffico TCP/IP che le attraversa. Sempre più frequentemente gli amministratori di reti locali si rendono conto che questi strumenti, da soli, non garantiscono un livello di sicurezza accettabile. Spesso non è possibile mantenere sotto controllo tutte le risorse di rete e può succedere che, su macchine utilizzate normalmente dagli utenti, vengano accidentalmente lasciate aperte porte che possono essere utilizzate da un attaccante. 14

21 Sistemi Intrusion Detection Il firewall, essendo uno strumento di protezione passivo, non ha nessuna capacità di rilevamento di eventuali tentativi di intrusione, né esegue un controllo sul tipo di traffico che viene scambiato attraverso le porte abilitate. Un ulteriore problema dei firewall è che forniscono protezione esclusivamente agli attacchi mossi dall'esterno della rete locale, mentre è dimostrato che l'80% delle perdite finanziarie dovute ad hacker provengono da attacchi mossi dall'interno della rete stessa. In contrapposizione al firewall, i sistemi IDS eseguono esattamente ciò che il firewall non può svolgere, cioè il riconoscimento di attacchi mossi verso le risorse di rete protette dal firewall. Riassumendo risulta quindi evidente che la sola presenza dei firewall non è sufficiente e l'affiancamento ad essi di sistemi Intrusion Detection comporta diversi vantaggi, tra cui: - Rilevamento di errate configurazioni dei firewall. Il sistema IDS, rilevando traffico che, per le politiche di firewalling adottate, non dovrebbe essere presente all'interno della rete locale, permette di segnalare tale anomalia e quindi di intervenire sulla configurazione dei firewall. - Rilevamento di attacchi. Capacità di rilevare in tempo utile eventuali attacchi portati attraverso i canali legittimati dal firewall. - Rilevamento dei tentativi di intrusione falliti. Possibilità di comprendere se il sistema reagisce correttamente agli attacchi, le caratteristiche dell intruso e della tecnica usata. - Rilevamento di tentativi di intrusione mossi dall'interno della rete locale. Poter monitorare anche l interno della propria rete locale permette di aumentare il grado di sicurezza, eliminando una debolezza non sanabile con i mezzi messi a disposizione dalla sicurezza passiva. 2.2 TIPOLOGIE DI SISTEMI ANTINTRUSIONE Esistono sostanzialmente quattro tipologie di Intrusion Detection, inquadrabili nelle seguenti categorie: - Network based Intrusion Detection System (NIDS). Si tratta di sistemi che analizzano costantemente il traffico sulla rete o segmento di rete che si intende 15

22 Sistemi Intrusion Detection proteggere, alla ricerca di tentativi di intrusione e/o di interruzione di servizi (Denial of Service). Un sistema NIDS può essere installato sulla stessa macchina che ospita i servizi che si intende proteggere, monitorando quindi il traffico in entrata e in uscita dalla macchina stessa, oppure può essere installato su una macchina dedicata esclusivamente al compito di NIDS, in grado di analizzare tutto il traffico di rete. - Host based Intrusion Detection System. Si tratta di sistemi che mantengono sotto controllo i file della macchina su cui sono installati, con lo scopo di rilevare eventuali cambiamenti eseguiti da un intruso, ad esempio la modifica di file eseguibili al fine di installare Backdoor che permettano all'attaccante un accesso successivo al sistema. Può mantenere sotto controllo anche altre componenti della macchina, quali il registro di configurazione del sistema operativo, i file di configurazione dei servizi e degli accessi di rete, i file che gestiscono le attività pianificate oppure parametri relativi al funzionamento del sistema operativo e della macchina, come ad esempio i processi di sistema, l'utilizzo della CPU ecc. I sistemi Host based inoltre sono in grado di rilevare se un normale utente, dotato di privilegi di accesso limitati, acquisisce privilegi di amministratore, che gli permettono di eseguire azioni non autorizzate sulla macchina. Questi sistemi sono anche in grado di monitorare i log file generati dal sistema operativo o dai servizi di rete forniti da una macchina. - Distribuited Intrusion Detection System. Si tratta di sistemi ibridi, contenenti sia la componente NIDS, sia quella HIDS. Tali sistemi acquisiscono tutti i vantaggi derivati dagli altri due, e contemporaneamente anche tutte le problematiche legate all efficienza ed all implementazione delle politiche intrusion detection. - Deception Systems. Anche conosciuti come Honeypots (sistemi esca), sono sistemi contenenti pseudo-servizi il cui fine è quello di emulare vulnerabilità conosciute, al fine di attirare un attaccante e "intrappolarlo". Questo lavoro prenderà in esame solo i sistemi NIDS, poiché tali sistemi, commerciali e open source, sono i più richiesti e utilizzati dalle aziende. 16

23 Sistemi Intrusion Detection 2.3 SISTEMI NIDS Un sistema di rilevamento delle intrusioni capace di analizzare il traffico di intere reti si dice "network based". I pacchetti vengono "sniffati", cioè letti dal sistema NIDS, in diversi modi: utilizzando una macchina dotata di scheda di rete impostata in modo da funzionare in modalità promiscua, oppure utilizzando appositi collegamenti presenti su switch o router, su cui è duplicato tutto il traffico che transita sulla rete. Il protocollo a cui si indirizzano la maggior parte dei prodotti NIDS è il TCP/IP, esistono, comunque diverse tecnologie orientate al monitoraggio dei vari livelli di protocollo, fino ad arrivare a quello applicativo. Un sistema NIDS è normalmente costituito da due componenti principali: - Il sensore. Il motore di rilevamento vero e proprio, in grado di analizzare i pacchetti della rete su cui è installato alla ricerca di pattern sospetti. - La console di gestione. Componente che si occupa della gestione del sistema e dei sensori, ed a cui il sensore comunica gli eventuali allarmi relativi al traffico sospetto. Questo tipo di architettura, disponibile nella maggior parte dei prodotti NIDS, è altamente scalabile. Mantenendo una singola console di gestione, è possibile aggiungere, virtualmente, un numero infinito di sensori, andando incontro alle esigenze di espansione della rete che si vuole mantenere sotto controllo, come l'aumento del traffico. La ricerca di traffico sospetto avviene utilizzando principalmente due tecniche: signature-based detection e anomaly detection SIGNATURE BASED DETECTION Si tratta della tecnologia più diffusa nei sistemi attualmente disponibili. Si fonda sull'analisi del traffico alla ricerca di pattern di attacco conosciuti. Significa che per ogni attacco esistente è necessario che sia presente, all'interno del sistema IDS, una signature (firma che caratterizza l attacco) per riconoscerlo. 17

24 Sistemi Intrusion Detection Utilizzando delle regole, basate sulle caratteristiche degli attacchi, come ad esempio le porte utilizzate, i flag dei protocolli attivati negli header, particolari stringhe contenute nel payload dei pacchetti, la direzione del flusso dei pacchetti, ecc.; questi sistemi riescono a discriminare il traffico autorizzato da quello potenzialmente dannoso. Si intuisce facilmente, che questo tipo di sistema permette di rilevare esclusivamente attacchi già conosciuti, mentre non offre alcun tipo di protezione riguardo nuovi attacchi ANOMALY DETECTION La tecnica Anomaly Detection, consiste nella costruzione di un modello relativo al normale traffico di rete e il rilevamento avviene analizzando eventuali deviazioni della tipologia di traffico dal modello iniziale. Il vantaggio dell Anomaly Detection è la capacità di rilevare nuovi attacchi; tuttavia, tale tecnologia soffre di un alto numero di falsi allarmi (in gergo, falsi positivi), in quanto anche il traffico legittimo, ma mai visto precedentemente, viene rilevato come un tentativo di intrusione. La maggior parte degli algoritmi di Anomaly Detection richiede un insieme consistente di dati relativi al traffico di rete, definito come normale, al fine di addestrare il modello, considerando implicitamente che tutto il traffico non contenuto all'interno di esso sia etichettato come anomalo. 2.4 REAZIONE AL TRAFFICO SOSPETTO I sistemi NIDS possono essere configurati in modo da svolgere, una volta rilevato traffico sospetto, azioni che richiedono l intervento dell amministratore di rete, oppure che attivano risposte automatizzate. Le azioni, svolte dai sistemi NIDS, destinate all attenzione dell amministratore di rete, si possono riassumere nelle seguenti categorie: - Salvataggio dei pacchetti. Consiste nel salvare tutti i pacchetti considerati sospetti in modalità cruda (raw). Tuttavia, questa tecnica richiede un applicativo in grado di interpretare correttamente il pacchetto salvato in modo da estrarne i dati più significativi. 18

25 Sistemi Intrusion Detection - Logging dell'attacco. Il sistema NIDS registra su un apposito logfile solo i dettagli relativi all'attacco: ora dell'attacco, indirizzo IP della macchina da cui proviene l'attacco, indirizzo IP della macchina vittima, informazioni sulle porte TCP/UDP utilizzate e sul protocollo applicativo, fino a salvare il contenuto del payload (dati) del pacchetto che ha generato l'alert. - Allarme visivo o acustico. Viene generato mediante finestre pop-up sulla console dell'amministratore di rete, oppure riproducendo file audio che avvertono dell'attacco in corso. - Invio di . Viene inviata una all'amministratore di rete contenente i dettagli relativi all'attacco, nonché data e ora. - Utilizzo di servizi di paging o sms. L'amministratore di rete viene avvertito dell'attacco in corso mediante paging o invio di sms al telefono cellulare. Per quanto riguarda le risposte automatizzabili, nella maggior parte dei casi, esistono le seguenti possibilità: - Riconfigurazione dei firewall. Il firewall della rete può essere riconfigurato in modo da bloccare l'indirizzo IP da cui viene mosso l'attacco per un periodo di tempo predeterminato. Bisogna porre attenzione però a questa soluzione poichè l'attaccante potrebbe eseguire un attack-flooding associato a spoofing dell'indirizzo IP sorgente, ad esempio utilizzando l indirizzo di un server appartenente alla azienda, in modo da costringere il firewall a bloccare il traffico proveniente dal server, causando un Denial of Service. Per risolvere il problema si potrebbe predisporre una lista di indirizzi IP "autorizzati", per i quali sia previsto che non venga mai effettuato il blocco. Affinchè questa tecnica sia utilizzabile è necessario che il firewall permetta la riconfigurazione attraverso applicazioni esterne: ad esempio i firewall Checkpoint supportano un protocollo chiamato SAMP (Suspicious Activity Monitoring Protocol) che permette di modificare le regole di filtering del firewall. - SNMP Trap. Viene inviata una trap, notifica di evento inaspettato, SNMP (Simple Network Management Protocol) ad una console di gestione, per la riconfigurazione ad esempio di un router. 19

26 Sistemi Intrusion Detection - Reset della connessione TCP. Tramite un pacchetto TCP con bit FIN o RST settato, oppure un ICMP unreachable, il sistema NIDS forza la chiusura della connessione relativa all'attacco in corso. - Throttling. Questo tipo di risposta si rivolge principalmente alle scansioni di host, scansioni di porte, SYN flooding e tecniche di mapping della rete. Si tratta di aggiungere un ritardo alla risposta ogni volta che una scansione o un flooding da parte di un attaccante viene rilevato; se l'attività di attacco continua il ritardo aumenta ulteriormente. Ad esempio per UDP il sistema NIDS potrebbe generare un pacchetto di source quench (smorzare la sorgente), mentre per TCP, se il traffico attraversa un proxy firewall, l'interfaccia in uscita potrebbe essere configurata in modo da utilizzare una dimensione di window più piccola. - Esecuzione di un programma esterno. Un programma esterno può essere invocato per occuparsi di mettere in atto le opportune contromisure all'attacco in corso. Tutte le tecniche descritte possono essere, nella maggior parte dei sistemi NIDS, combinate tra loro in modo da offrire la risposta più rapida ed efficace agli attacchi. Tuttavia, l'intervento diretto da parte del sistema NIDS in risposta ad un attacco, può risultare molto rischioso, in quanto comporta, che il NIDS renda nota la propria presenza, e se mal configurato può diventare causa scatenante di attacchi DoS a se stessi. 2.5 LIMITI DEI SISTEMI NIDS I sistemi di Network Intrusion Detection funzionano analizzando il traffico di rete alla ricerca di attività sospette o non autorizzate. Quando tali attività vengono identificate i sistemi NIDS generano un alert ed eventualmente eseguono una azione predeterminata. La maggior parte dei sistemi NIDS, indipendentemente dalla tecnologia di rilevamento utilizzata, soffre però dei seguenti limiti: - Alert generati. I sistemi NIDS tendono a generare un volume di alert estremamente elevato. Tale volume causa un intenso utilizzo delle risorse 20

27 Sistemi Intrusion Detection hardware, nonché richiede un impegno non indifferente da parte degli amministratori per rivedere e analizzare tutti i dati generati dal NIDS. - Falsi positivi. Per quanto tempo si dedichi ad una attenta configurazione dei sistemi NIDS, i falsi positivi rimangono comunque un problema non eliminabile completamente. La presenza di falsi positivi costituisce essa stessa una minaccia per la sicurezza della rete: il fatto di rilevare giornalmente alert che si rivelano falsi comporta un abbassamento della soglia di attenzione da parte degli amministratori di rete, che potrebbero finire con il considerare falsi allarmi anche attacchi reali. - Falsi negativi. Così come i sistemi NIDS possono generare falsi allarmi, allo stesso modo possono fallire nel rilevare un nuovo attacco. Gli attaccanti infatti, sviluppano in continuazione, oltre a nuovi attacchi, anche tool in grado di mascherare gli attacchi preesistenti in modo che non vengano rilevati dai sistemi NIDS. - Risorse. I sistemi NIDS richiedono hardware in grado di garantire buone prestazioni. Basti pensare che all'aumento del traffico sulla rete e soprattutto della velocità con cui questo la percorre corrisponde un aumento del lavoro che il sistema deve svolgere e della quantità di dati generati. Inoltre i dati generati richiedono la memorizzazione in grandi database che ovviamente necessitano di ulteriori risorse e impegno per essere gestiti (archiviazione periodica, backup ecc). Inoltre, i due paradigmi di rilevamento analizzati, Signature Based e Anomaly Detection (par e 2.3.2), presentano anch essi dei limiti non trascurabili LIMITI DELLA SIGNATURE BASED I sistemi Signature Based si basano su particolari stringhe, contenute all'interno dei pacchetti, indicative di traffico sospetto. Se un pacchetto, o un insieme di pacchetti, contenenti tali stringhe, vengono rilevati sulla rete mantenuta sotto controllo, viene generato un alert ed eseguita un'azione opportuna in risposta all'attacco. 21

28 Sistemi Intrusion Detection L'implementazione di un sistema NIDS Signature based presenta, in maniera piuttosto evidente, la problematica relativa ai falsi positivi, cioè allarmi relativi a traffico che è in realtà benigno. Ad esempio se un utente autorizzato all'utilizzo delle risorse di rete esegue un upload verso un server FTP di un file binario, è possibile che nella lunga sequenza di bytes che viene trasferita si presenti casualmente una stringa uguale ad una signature attiva sul sistema antintrusione, sebbene invece faccia parte di traffico legittimo, generando un alert. Per limitare questo problema è necessario selezionare con la massima attenzione il set di regole su cui verrà svolto il controllo. Ad esempio il fatto di non includere regole relative a servizi FTP, se nella rete che si vuole monitorare non è presente un server FTP, può essere utile a limitare il numero di falsi positivi generati. L analisi delle regole da utilizzare richiede un notevole lavoro iniziale da parte dello staff preposto alla sicurezza. Anche l aggiornamento del set di regole può rivelarsi un problema. La frequenza con cui vengono rilasciate le nuove regole è piuttosto elevata, in genere si tratta di coprire decine di nuove minacce al mese. Il nuovo set di regole deve essere analizzato ogni volta, con grande sforzo da parte degli amministratori di rete, in quanto è necessario verificare se sia applicabile alla tipologia di servizi presenti all'interno della rete ed eventualmente se sia possibile aggiungerlo al set esistente LIMITI DELLA ANOMALY DETECTION I sistemi basati su Anomaly Detection cercano di suddividere il traffico in due categorie: traffico normale e traffico considerato anomalo, che genera un alert. Il problema più grosso di tale tecnologia è la definizione esatta di quale sia il traffico considerato normale. Se una rete non presenta cambiamenti per un lungo periodo di tempo, a livello di servizi offerti nonché tipologia di traffico, è relativamente semplice, da parte del sistema NIDS, definire quale sia il traffico normale, ma è difficile che accada, poiché vengono costantemente sviluppate e utilizzate nelle reti nuove applicazioni e tecnologie. Tutto questo rende estremamente difficoltoso definire una metrica sulla cui base stabilire quale sia effettivamente il traffico da considerarsi "normale". 22

29 Sistemi Intrusion Detection 2.6 POSIZIONARE UN NETWORK IDS Indipendentemente dalla tecnica utilizzata dai sensori per il rilevamento delle intrusioni (Anomaly Detection e/o Signature Based) il posizionamento, fisico, all interno della rete da monitorare dei sistemi NIDS può presentare delle criticità. Nel caso di reti locali semplici e a traffico limitato, eventualmente protette da firewall, il posizionamento dei sensori NIDS è immediato. A seconda che si voglia monitorare il traffico all'interno della rete locale oppure proveniente da Internet, il sensore può essere posizionato subito prima o subito dopo il firewall, oppure, disponendo di due sensori, in entrambe le posizioni (fig. 5). Figura 5 Sistema NIDS integrato in una possibile architettura di rete aziendale Il posizionamento a valle del firewall presenta il vantaggio di ridurre notevolmente il numero di alert generati, in quanto la maggior parte degli attacchi viene bloccato dal firewall prima di raggiungere il sensore NIDS. Un sensore posto sulla rete interna permette, tra le altre cose, di rilevare eventuali errori di configurazione del firewall, riportando ad esempio attacchi mossi passando attraverso porte che dovrebbero normalmente essere bloccate dal firewall. D'altra parte il posizionamento all'esterno permette di capire a quale tipologia e quantità di attacchi la rete, che si intende proteggere, è normalmente soggetta. Si può dire quindi che il posizionamento all'esterno permette di avere un sistema di "attack detection", nel senso che consente di rilevare quali attacchi vengano mossi nei confronti della rete, mentre il posizionamento all'interno corrisponde all'attività di 23

30 Sistemi Intrusion Detection "intrusion detection", cioè vengono rilevate quelle attività connesse ad una effettiva intrusione all'interno della rete. Avere almeno due tipologie di sensori: una a valle del firewall e una a monte, ovviamente configurando opportunamente le console di gestione in modo da distinguere, per ogni alert presentato, la sua origine fisica; potrebbe risultare la soluzione più efficace. In questo modo, infatti, è possibile verificare non solo se un attacco sia riuscito a penetrare il firewall, ma anche l'origine dell'attacco (mosso dall interno o dall esterno), errori di configurazione dei firewall, delle impostazioni di rete degli host ed eventuali presenze di backdoor. 2.7 PROBLEMI DA AFFRONTARE Non sempre è possibile eseguire l installazione di un NIDS, come descritto nel paragrafo precedente (par. 2.6), a causa della complessità delle installazioni di rete aziendali e del sempre maggiore traffico generato. Un sistema NIDS ideale infatti dovrebbe garantire il 100% nel rilevamento delle intrusioni; ciò non è sempre possibile a causa dei seguenti motivi: Reti fortemente trafficate. In ambienti di rete locale ad alta velocità (Gigabit Ethernet) fortemente trafficati è possibile che la quantità di traffico monitorato dal sensore NIDS per unità di tempo superi le capacità del sensore stesso di analizzarlo; quindi una parte del traffico potrebbe attraversare la rete incontrollato. Reti Switched. In ambienti di rete di tipo Switched, cioè in cui le varie macchine siano collegate in una topologia a stella mediante Switch, non esiste una collocazione ideale per il sensore del sistema NIDS. Le porte SPAN degli Switch, inoltre non sono dimensionate per replicare tutto il traffico che attraversa lo Switch e, se anche lo fossero, il traffico generato su tale porta supererebbe le capacità di rilevamento di un normale sensore NIDS. La conseguenza di ciò è l'utilizzo di più sensori o, in caso di budget limitato, il monitoraggio di una parte della rete, lasciando porzioni di rete non protette. Reti locali asimmetriche. In reti locali asimmetriche, cioè composte da più sottoreti collegate tramite router, il traffico può compiere percorsi diversi prima 24

31 Sistemi Intrusion Detection di raggiungere il sensore del sistema NIDS; quest'ultimo quindi potrebbe rilevare solo una parte dei pacchetti costituenti un attacco, con la conseguenza di non poter dare l allarme. Come vedremo infatti un sistema NIDS necessita di ricevere il flusso completo di una comunicazione TCP/IP, al fine di determinare la presenza di un tentativo di intrusione. Reti con traffico cifrato. Sempre più spesso si fa ricorso a protocolli che utilizzano algoritmi di cifratura del traffico a livello applicativo, come ad esempio HTTPS. In questo caso i sistemi NIDS non possono analizzare il contenuto dei pacchetti criptati, ciò permette l'esecuzione di attacchi a livello applicativo senza che questi vengano rilevati. Sensori non funzionanti. Un sensore potrebbe, per un problema software o hardware, smettere di funzionare e l'anomalia venire scoperta solo dopo che sia stato portato a termine con successo un attacco. Protocolli non supportati. la maggior parte dei sistemi NIDS supporta esclusivamente il protocollo IP; tuttavia, questo non è l'unico protocollo di comunicazione esistente RETI FORTEMENTE TRAFFICATE Per quanto riguarda il primo punto, relativo alle reti fortemente trafficate, la capacità di rilevamento di un sistema NIDS è direttamente proporzionale alle sue performance. Il concetto di performance dei sistemi NIDS è probabilmente uno degli aspetti più controversi relativi a tali applicazioni in quanto è molto difficile darne una quantificazione, tuttavia, esistono una serie di elementi, da considerare, che possono influenzare le performance del sistema antintrusione, come: - L' hardware e il software utilizzato per far funzionare il sensore; - Il tipo di tecnica di rilevamento utilizzata dal sensore (Anomaly Detection o Signature Based); - La percentuale di traffico cifrato che attraversa la rete sul totale; - La dimensione dei pacchetti; - Le politiche di sicurezza adottate sulla rete locale e la configurazione del sensore NIDS; 25

32 Sistemi Intrusion Detection Esistono principalmente due tipologie di sensori NIDS: sensori Megabit e sensori Gigabit. Sebbene entrambi i tipi utilizzino le medesime tecniche per il rilevamento degli attacchi (Anomaly Detection o Signature Based) la differenza più importante tra i due è il metodo utilizzato per decidere o meno se catturare un pacchetto e passarlo alla routine di analisi. Risulta molto difficile ottenere in laboratorio statistiche relative alle performance dei sistemi NIDS, poiché il fattore discriminante più importante non può basarsi sul numero di attacchi che un sistema NIDS è in grado di rilevare (sebbene spesso sia l'unico risultato considerato nelle prove), ma piuttosto in che misura sia in grado di rilevare un attacco immerso all'interno di una quantità elevata di traffico normale. La dimensione dei pacchetti è un altro aspetto importante. I prodotti NIDS disponibili sono realizzati in modo da fornire prestazioni ottimali se i pacchetti hanno dimensione media di 1024 bytes, tuttavia, se i pacchetti sono più piccoli il sensore funzionerà in maniera decisamente più lenta. Il terzo aspetto chiave nella misurazione delle performance di un sistema NIDS sono le politiche di sicurezza adottate sulla rete locale. I sistemi NIDS sono configurabili in modo da riflettere le politiche di sicurezza relative al traffico abilitato sulla rete, ad esempio in una rete su cui la politica di sicurezza preveda l'assenza di traffico HTTP non è necessario che il sistema NIDS esegua il controllo di tale tipo di protocollo, anche perchè, soprattutto nei sistemi Signature Based, un numero elevato di regole da controllare corrisponde a un deciso aumento delle risorse hardware. Per questo motivo è necessario che i sistemi NIDS vengano opportunamente configurati in modo da essere aderenti alle politiche di sicurezza che determinano la tipologia di traffico ammesso sulla rete da controllare, al fine di ottimizzarne le performance. Come abbiamo visto esistono troppe variabili per poter fornire una quantificazione precisa delle performance di un sistema NIDS. Tuttavia, in prima approssimazione per un sensore di tipo Megabit è lecito aspettarsi una capacità di monitoraggio del 60/80% del traffico, mentre per un sensore Gigabit la capacità scende al 40/60%. Prima di affermare che un solo sensore NIDS è sempre insufficiente, è necessario ricordare quale sia il tipico ambiente in cui i sistemi NIDS sono stati progettati. Il concetto principale su cui la progettazione è stata fatta è quella di segmento di rete. Un sistema NIDS, infatti, è in grado di monitorare singoli segmenti di rete, come quello proveniente da un hub. 26

33 Sistemi Intrusion Detection In un'architettura di questo tipo il posizionamento del sensore NIDS è immediato: è sufficiente collegarlo ad una qualunque delle porte dell'hub per monitorare tutto il traffico relativo al segmento di rete che essendo virtualmente condiviso tra tutte le macchine, permette un utilizzo della banda disponibile che non supera il 40%. Per questo motivo un singolo sensore di tipo Megabit, in grado di rilevare, come visto precedentemente, il 60/80% del traffico totale, sarebbe sufficiente RETI SWITCHED Sempre più frequentemente nell'implementazione di reti locali Ethernet vengono utilizzati, al posto degli hub, apparecchi di tipo Switch. Gli switch, a differenza degli hub che lavorano esclusivamente a livello 2 della pila ISO/OSI, sono in grado di processare anche i livelli 3 e 4. Sono, quindi, a conoscenza degli indirizzi IP delle macchine collegate alle proprie porte. L'utilizzo di switch al posto degli hub consente un utilizzo della banda Ethernet decisamente più efficiente, in quanto sono possibili più comunicazioni contemporanee tra coppie di macchine, oltre a portare notevoli vantaggi sul piano della sicurezza e della privacy, poichè le macchine non possono ricevere traffico che non sia loro destinato (in realtà esistono tecniche di spoofing che permettono di superare questo limite). Il principio di funzionamento dello switch però costituisce un grosso problema nel posizionamento del sistema NIDS, in quanto il collegamento ad una porta normale dello switch non permetterebbe di monitorare il traffico tra le varie macchine. La soluzione a questo problema è stata introdotta da Cisco nei suoi prodotti switch: si tratta di una porta aggiuntiva, chiamata SPAN port, o Mirror port dagli altri produttori, su cui lo switch replica tutti i pacchetti ricevuti da qualunque porta utente. In questo modo sulla SPAN port viene a trovarsi tutto il traffico relativo al segmento di rete costituito dallo switch (fig. 6). Tuttavia tale soluzione presenta un rovescio della medaglia. Infatti, l'utilizzo della SPAN port su uno switch comporta grossi problemi di banda, ad esempio anche nel caso di reti a basso traffico (switch con 10 porte da 100Mbit utilizzate al 10% della banda disponibile) la SPAN port, dovendo replicare simultaneamente il traffico di tutte e 10 le porte, genererà una quantità di traffico pari a 100Mbit effettivi. 27

34 Sistemi Intrusion Detection Figura 6 La SPAN port (numero 10) replica tutto il traffico del segmento di rete Un sensore NIDS di tipo 100Mbit quindi, potendo rilevare solo il 60/80% del traffico a 100Mbit, non sarà sufficiente. Anche l'utilizzo di un sensore Gigabit, sulla SPAN port di uno switch a 10 porte 100Mbit intensamente trafficate, non è sufficiente in quanto la capacità di rilevamento, come abbiamo visto precedentemente, è ben al di sotto del 100%. Inoltre l'utilizzo di una SPAN port Gigabit su uno switch con porte a 100Mbit generalmente introduce un abbassamento delle prestazioni globali del segmento di rete di circa il 10/20% RETI LOCALI ASIMMETRICHE L'implementazione di una rete locale spesso prevede, in ambito aziendale, un incremento progressivo del numero di macchine collegate, che comporta una ristrutturazione della struttura della rete, con l'aggiunta di nuovi segmenti collegati tra loro attraverso router. Con l ampliamento della rete continua ad essere indispensabile garantire una certa affidabilità e performance nelle comunicazioni tra le varie sottoreti. Tale scopo si ottiene aumentando la ridondanza dei componenti di rete, così da creare percorsi alternativi tra le sottoreti, utili in caso di guasto; oppure, utilizzando apparecchiature di load balancing capaci di migliorare sensibilmente la velocità di comunicazione tra le varie sottoreti. Un sistema NIDS può eseguire correttamente la sua funzione di monitoraggio solo se è in grado di vedere tutti i pacchetti appartenenti ad un singolo flusso di dati. Ad esempio, 28

35 Sistemi Intrusion Detection nel caso di un attacco ad un server HTTP in cui la stringa di attacco sia stata suddivisa in 5 pacchetti, ed ogni pacchetto appartenente al flusso di dati in arrivo da Internet possa raggiungere la rete locale seguendo percorsi diversi, anche utilizzando più sensori NIDS collegati ai router esterni, il traffico rilevato da ognuno di essi sarebbe parziale, non permettendo, così, la rilevazione dell'intruso (fig. 7). Figura 7 - I pacchetti splittati transitano su router monitorati da sensori diversi TRAFFICO CIFRATO L'utilizzo di tecniche di cifratura a livello applicativo, ad esempio mediante il protocollo HTTPS o tunnel SSH, comporta grossi limiti nella capacità di analisi del traffico dei sistemi NIDS. Buona parte degli attacchi viene mossa utilizzando vulnerabilità dei servizi che possono essere sfruttate semplicemente inviando ai server stringhe o comandi opportunamente forgiati, che viaggiano sulla rete a livello applicativo. I sistemi di cifratura, cifrando il traffico tra i due endpoint coinvolti nella comunicazione, non permettono a nessun'altro di osservare il contenuto dei pacchetti scambiati, ovviamente nemmeno ai sistemi NIDS. 29

36 Sistemi Intrusion Detection Un utente malintenzionato quindi che voglia muovere un attacco, ad esempio per sfruttare una vulnerabilità CGI di un web server che utilizza il protocollo HTTPS, potrebbe farlo in maniera del tutto indisturbata in quanto non verrebbe rilevato SENSORI MALFUNZIONANTI Come tutti i sistemi anche i NIDS presentano i cosiddetti "point of failure", sia a livello software, sia nell hardware su cui sono installati. Il blocco di un sistema NIDS non comporta alcun problema oltre a quello di non rilevare più gli attacchi, per questo motivo potrebbe trascorrere molto tempo, o accadere qualunque cosa, prima che l amministratore si accorga che il sistema, che dovrebbe svolgere l'attività di intrusion detection, è bloccato o la macchina su cui è installato si è guastata PROTOCOLLI NON SUPPORTATI Attacchi mossi attraverso protocolli non supportati dal sistema NIDS, quindi non decodificabili, non vengono rilevati. Prima di implementare un sistema NIDS su una rete è bene analizzare attentamente la tipologia di traffico che l attraversa. Sebbene poco diffusi, esistono una moltitudine di protocolli diversi da IP, ad esempio Signaling System 7, IBM SNA, IP Protocol 54, NHRP, che possono essere utilizzati con successo per eseguire attacchi a livello applicativo, senza poter essere rilevati da un sistema NIDS progettato per lavorare esclusivamente con il protocollo IP. 2.8 LE SOLUZIONI ESISTONO Come abbiamo visto l'implementazione di un sistema NIDS all'interno di una rete locale complessa, comporta diverse problematiche che è necessario non sottovalutare se si vogliono ottenere prestazioni soddisfacenti. Una prima soluzione può essere la ridondanza dei sensori NIDS. Aumentando il numero di sensori e posizionandoli opportunamente all'interno dei segmenti che compongono una rete locale è possibile monitorare il traffico dell'intera rete in maniera efficace. In genere i prodotti NIDS disponibili in commercio prevedono la possibilità di amministrare più sensori facenti capo ad un'unica console di gestione. Questa soluzione, 30

37 Sistemi Intrusion Detection tuttavia, in certi casi da sola non è sufficiente. Nel caso di switch dotati di SPAN port, ad esempio, l'utilizzo di più sensori collegati a tale porta non sarebbe di nessun aiuto, in quanto ogni sensore riceverebbe comunque una quantità di traffico superiore alle sue effettive capacità. In questo caso possono essere utili prodotti di load balancing sviluppati appositamente per l'utilizzo con sistemi NIDS. Alcuni produttori forniscono apparecchiature in grado di distribuire il traffico proveniente dalla SPAN port di uno switch o di un router a più sensori NIDS, ovviamente in modo tale da far giungere ad ogni sensore il contenuto di un intero flusso di comunicazione (fig. 8). Figura 8 Bilanciamento del traffico verso più sensori Un load balancer di questo tipo risulta decisamente più complesso rispetto ad uno comune, in quanto non può limitarsi a distribuire equamente i pacchetti ai vari sensori, bensì deve mantenere una conoscenza del tipo di comunicazione proveniente dalla SPAN port e inviare l'intero flusso relativo a tale comunicazione (ad esempio una connessione TCP) ad un solo sensore NIDS. Un'altra situazione in cui può rivelarsi utile l'utilizzo di un load balancer dedicato ai sistemi NIDS è nel caso di presenza di più server web ridondanti ad alto traffico (fig. 9). In questo caso è possibile, mediante l'utilizzo di taps, intercettare il traffico relativo ai vari server e inviarlo al load balancer, che provvederà a distribuirlo ai vari sistemi NIDS. I taps sono una sorta di hub a tre porte in grado di replicare il traffico che li attraversa su una porta, attiva solo in trasmissione (fig. 10). 31

38 Sistemi Intrusion Detection Figura 9 Possibile soluzione con LoadBalancer e Tap In particolare il tap è costruito in modo da inviare alla porta di monitoraggio tutti i pacchetti che lo attraversano, in entrambe le direzioni. L'utilizzo dei taps al posto di uno switch con SPAN port comporta diversi vantaggi: innanzitutto essi hanno, al contrario di switch 100Mbit con SPAN port Gigabit, un impatto nullo sulla infrastruttura di rete, sia a livello di prestazioni che di topologia di rete. Quindi non è necessario riconfigurare router o switch esistenti dopo la loro installazione. Inoltre permettono di ottenere una copia esatta del traffico proveniente dai server di rete senza che questa attività comporti traffico aggiuntivo sulla rete locale. Figura 10 - Il tap replica passivamente il traffico entrante e uscente Un ulteriore vantaggio è la protezione, a livello di rete, delle apparecchiature poste sulla porta di monitoraggio, in quanto, quest'ultima, essendo abilitata solo alla trasmissione del traffico che attraversa il tap ma non alla ricezione, non permette la risposta da parte 32

39 Sistemi Intrusion Detection delle macchine in ascolto sulla porta di monitoraggio e di conseguenza rende impossibile un attacco. Per risolvere i problemi relativi alle reti asimmetriche (par ), i load balancer possono essere utili, infatti, collegando le SPAN port di tutti i router della rete asimmetrica agli ingressi del load balancer, quest ultimo provvederà a ricostruire i vari flussi di comunicazione provenienti dai router e ad inviarli ai sensori NIDS (fig. 11). Figura 11 - Il LoadBalancer riaggrega le sessioni TCP prima di inviare i pacchetti ai NIDS In questo modo ogni sensore NIDS riceverà i pacchetti relativi ad una singola comunicazione e sarà in grado di rilevare eventuali pacchetti contenenti tentativi di attacco. Per quanto riguarda il problema relativo al traffico cifrato, esistono diverse soluzioni possibili, a seconda del tipo di protocollo di cifratura utilizzato e dal budget disponibile. Nel caso di comunicazione cifrata attraverso tunneling ssh è necessario installare il sistema IDS sul segmento di rete relativo al traffico che verrà incapsulato nel tunnel ssh (fig. 12). Ciò presuppone ovviamente la presenza di un sensore per ognuno dei segmenti di rete locale esistenti, anche se il traffico totale della rete fosse gestibile da un solo sensore. Nel caso di presenza di server HTTPS la situazione è più complessa. A differenza del caso tunneling ssh, la cifratura del traffico avviene per opera del server stesso, in teoria 33

40 Sistemi Intrusion Detection quindi solo i due endpoint coinvolti nella comunicazione possono accedere al traffico cifrato. Figura 12 - Esempio di connessione cifrata con SSH Sono possibili due soluzioni: la prima prevede l'utilizzo di appositi appliance che, intercettando il traffico cifrato tra i due endpoint e condividendo con il server web i certificati relativi alla comunicazione HTTPS, partecipano all'handshake del protocollo SSL e sono quindi in grado di accedere ai dati protetti. (fig. 13). Tali dati vengono quindi inviati in chiaro al sensore NIDS che potrà svolgere correttamente la funzione di monitoraggio. La seconda soluzione prevede l'utilizzo di un reverse proxy con capacità di cifratura del traffico HTTP (fig. 14). Figura 13 - L appliance HTTPS è in grado di decrittografare il traffico HTTPS e inviarlo al NIDS 34

41 Sistemi Intrusion Detection Figura 14 - Apache può funzionare da reverse proxy per crittografare il traffico HTTP Il reverse proxy cattura le richieste HTTPS provenienti dall'esterno e le reindirizza, in modalità HTTP, al server Web. Nel percorso inverso, le relative risposte del server web, prima di essere inviate al client, vengono intercettate dal reverse proxy e trasformate in HTTPS. Il tutto avviene in maniera completamente trasparente all'utente, a cui il server Web apparirà a tutti gli effetti di tipo HTTPS. In questo modo, ponendo il sensore NIDS tra il reverse proxy e il server HTTP è possibile monitorare correttamente il traffico. 35

42 CAPITOLO 3 IL VALORE DELLA FLESSIBILITÀ La nascita di nuove tecnologie ed il potenziamento di quelle standard costringe spesso le aziende ad aggiornare i propri sistemi e di conseguenza ad integrare nuove soluzioni, espandere e a volte addirittura rivoluzionare la propria rete informatica. Se si pensa che quando un aggiornamento diventa indispensabile l azienda si trova ad affrontare nuove spese, e che queste spese sono composte non solo dal costo della nuova tecnologia, ma anche dagli interventi che potrebbero essere richiesti per adattare il nuovo sistema alla rete aziendale, diventa chiaro che nella classifica dei prodotti acquistabili, al primo posto troveremo quello con il miglior rapporto prezzo/impatto. A questo punto sorge un problema: mentre il costo di un nuovo strumento informatico, solitamente, è ben chiaro, tutt altro si può dire per il suo impatto sulla rete, anche perché la sua quantificazione dipende da fattori diversi per ogni realtà aziendale. Le grandi case produttrici di soluzioni informatiche per le aziende si sono trovate quindi a dover spostare i loro investimenti verso lo sviluppo di nuovi sistemi che, pur mantenendo la loro linea di qualità, garantiscano un certo grado di flessibilità. Oggi più che mai questo aspetto acquista valore e la sua priorità aumenta nei confronti di tutti quei fattori che precedentemente erano primari. Gli aspetti che permettono di capire quale sia il livello di flessibilità di un sistema informatico si possono dividere in due grandi categorie: il primo corrisponde al grado di compatibilità che il nuovo prodotto riesce ad ottenere nei confronti del sistema preesistente, sia per quanto riguarda l aspetto hardware, sia per quello software; l altro è legato alla scalabilità che lo stesso riesce ad offrire. Questo secondo aspetto diventa prioritario se si pensa ad una azienda in espansione, che magari si trova ad affrontare operazioni di integrazione/fusione societarie, e quindi con la necessità di integrare altre realtà e strutture informatiche. Se la stessa non aveva preventivato l utilizzo di sistemi capaci di scalare con la sua crescita, si troverà a dover cercare nuove soluzioni con tutto quello che possono comportare (una fra tutte, addestrare nuovamente gli utenti del vecchio sistema), senza tralasciare la spesa necessaria a coprire tutta la nuova rete; mentre sarebbe stato possibile, grazie ad un prodotto più flessibile, aggiungere solo pochi nuovi componenti per ottenere lo stesso risultato o anche meglio. 36

43 Il valore della flessibilità Per una categoria di sistemi, per la sicurezza informatica, come gli intrusion detection, la flessibilità diviene un aspetto molto importante. Gli IDS capaci di offrire, oltre ad elevate prestazioni, anche garanzie di adattamento e scalabilità sono quelli che otterranno più successo. 3.1 NIDS USER DEFINED Oltre alla compatibilità con l hardware e il software della rete aziendale ed alla capacità di riuscire a sostenere la copertura di nuovi segmenti di rete (o intere reti), un NIDS può offrire un altro parametro utile per valutarne la flessibilità, ovvero la possibilità di creare nuove politiche di rilevamento. Un NIDS user defined, infatti, permette all amministratore di rete, di definire delle regole e/o policy per gestire situazioni particolari che non appartengono agli attacchi conosciuti o alle tipologie di traffico normali. Per fare un esempio, pensate ad una grande azienda che deve inglobare nella sua struttura un altra società più piccola. Le due reti dovrebbero fondersi in una sola ed i sistemi allinearsi, instaurando di conseguenza rapporti di fiducia fra le macchine. Se il NIDS della grande azienda fosse in grado di coprire la nuova rete, ma non consentisse di creare politiche di sicurezza per gestire i cambiamenti del nuovo traffico di rete, probabilmente come risultato finale si avrebbe ancora sicurezza dagli attacchi esterni conosciuti, da cui si è protetti grazie alle policy fornite insieme al sistema NIDS, ma non da quelli interni; o potrebbe accadere che traffico autorizzato, ma prima sconosciuto, venga rilevato come sospetto, causando grandi quantità di falsi positivi e saturando le risorse del sistema antintrusione. La possibilità di definire regole per tenere sotto controllo certi tipi di traffico di rete o particolari eventi, diventa, quindi, un caratteristica molto importante che un intrusion detection deve possedere. Riepilogando la flessibilità nei sistemi NIDS è l insieme di tre componenti: - Compatibilità; - Scalabilità; - Personalizzazione. 37

44 Il valore della flessibilità Lo scopo di questa tesi è valutare il terzo aspetto, avendo considerato che la compatibilità e la scalabilità sono ormai largamente fornite da quasi tutti i sistemi in commercio. 3.2 IDS PRESI IN ESAME Si è deciso di considerare, per la valutazione delle caratteristiche User Defined, tre prodotti molto conosciuti sul mercato: Snort (nella versione 2.0.2), McAfee IntruShield e ISS Realsecure 7.0. La scelta si basa principalmente sulle differenze che questi tre prodotti hanno tra loro, infatti, ognuno individua, in maniera molto chiara, una possibile strada per sviluppare sistemi NIDS flessibili. Di seguito viene riportata una breve descrizione di ognuno di essi SNORT 2.0 L autore e realizzatore di Snort è Martin Roesch. La prima release risale al dicembre 1998 ma la svolta avvenne un anno dopo, quando nella versione 1.5 fu aggiunta l architettura modulare. Nell'aprile del 2003 è stata rilasciata la versione 2.0, che implementa un motore di rilevamento ottimizzato, comprendente funzionalità di analisi e rilevamento di anomalie dei protocolli. Attualmente lo sviluppo di Snort è mantenuto da Martin Roesch e Brian Caswell e il progetto Snort è di proprietà della Sourcefire Inc. Snort è un software Open Source, con esso sono forniti i sorgenti, ed è possibile distribuirlo e modificarlo secondo lo standard GNU GPL. Parte di questo codice è stato estratto dal tool di sniffing "tcpdump" sviluppato dal Network Research Group nei laboratori della Lawrence Berkeley National ed è coperto da copyright dall'università della California Regents (USA). Si tratta di un sistema per il rilevamento di intrusioni in rete (NIDS) basato sulla libreria libpcap ( Il 18 dicembre 2003 è stata rilasciata l ultima versione di Snort (ver. 2.1), che comprende nuove funzionalità, oltre ai miglioramenti delle vecchie e il fissaggio di alcuni bug. Il materiale è disponibile all indirizzo web 38

45 Il valore della flessibilità Per la valutazione di Snort è stata presa in considerazione la versione 2.0.2, rilasciata ad ottobre 2003, data la coincidenza con l inizio di questo progetto MCAFEE INTRUSHIELD McAfee Intrushield, fa parte della famiglia di prodotti McAfee Network Protection Solutions di Network Associates Inc., è una tecnologia all avanguardia che previene le intrusioni on the wire prima che vadano a colpire i sistemi critici. Estremamente automatizzato, McAfee Intrushield è progettato per un elevato livello di flessibilità tanto da poter essere implementato con un approccio progressivo che consente di sviluppare la giusta policy di protezione per ogni singola struttura IT. McAfee Intrushield è un appliance ad alta velocità in grado di effettuare la scansione del traffico e valutare i livelli di minaccia anche su reti gigabit. Intrushield è in grado di bloccare un ampia gamma di attacchi alla rete con latenze di rete tipicamente inferiori ai 10 millisecondi. McAfee Intrushield ricerca inoltre comportamenti anomali e include analisi specializzata per individuare nuovi attacchi di tipo DoS e DDoS. La linea di prodotti McAfee Intrushield include, oltre al nuovo McAfee Intrushield 1200: la sensor appliance McAfee Intrushield 4000, progettata per essere posizionata al cuore della rete aziendale o presso un centro dati e offre prestazioni fino a 2 Gbps; McAfee Intrushield 2600, una soluzione flessibile studiata per la protezione perimetrale della rete aziendale e offre prestazioni fino a 600 Mbps e il sistema McAfee Intrushield Security Management, un avanzata soluzione per la gestione IDS. Intrushield è distribuito dalla Network Associates Inc., la quale acquisendo la società IntruVert Network realizzatrice di Intrushield, ha rafforzato ancora di più la sua gamma di prodotti, già famosa per la linea McAfee. Network Associates Inc. con sede principale a Santa Clara, California, crea soluzioni avanzate per la sicurezza informatica che prevengono intrusioni sulle reti e proteggono le attrezzature informatiche dalle future generazioni di attacchi e minacce miste. Con due famiglie di prodotto, McAfee System Protection Solutions, per la protezione di desktop e server, e McAfee Network Protection Solutions, che garantisce la protezione e le prestazioni delle reti corporate, Network Associates fornisce sicurezza informatica a grandi aziende, enti governativi e pubblici, aziende di piccole e medie dimensioni e 39

46 Il valore della flessibilità utenti finali. Queste due linee d offerta includono le famose famiglie di prodotto McAfee, Sniffer e Magic. Ulteriori informazioni sono disponibili su Internet all indirizzo ISS REALSECURE 7.0 Nel 1992, il fondatore di ISS Christopher Klaus inventò una rivoluzionaria tecnologia in grado di identificare i problemi relativi alla sicurezza nella rete e di segnalare azioni correttive per risolverli. Due anni dopo, Klaus, che allora aveva solo 21 anni, collaborando con il "veterano del software" Thomas E. Noonan, fondò Internet Security Systems e lanciò il primo prodotto dell'azienda, Internet Scanner. Da quel momento, ISS ha concentrato i suoi obiettivi sulla creazione di soluzioni per la sicurezza in Internet e ha sviluppato un'offerta completa di software e servizi. ISS, acronimo di Internet Security Systems, ha sede ad Atlanta ed è quotata al NASDAQ con la sigla ISSX. Attualmente, ISS è leader mondiale nel campo del security management software per la sicurezza e per il rilevamento delle intrusioni. L'azienda conta più di 1500 impiegati in 22 paesi e, nel 1999, è stata inserita dalla rivista Forbes tra le "Top 50 Most Dynamic Company" e da Red Herring Magazine nelle "Top 50 Public Company". USA Today ha parlato di ISS come di una delle più importanti aziende business-to-business di Internet e l'ha inserita tra le "Top 50 E- Business Stock". Internet Security Systems è un fornitore leader di soluzioni per il controllo della sicurezza, della sua integrità e vulnerabilità dell "Enterprise Information System", dinamicamente rileva e segnala eventuali varchi e attacchi sulla rete. Le grandi conquiste di ISS partono da Internet Scanner, la prima applicazione adatta alle imprese per la network security, passando per Realsecure, la prima piattaforma d indagine contro le intrusioni integrata su base host e network, fino a SafeSuite Decisions, il primo sistema di supporto per le decisioni di sicurezza aziendale. 40

47 CAPITOLO 4 SNORT 2.0 La peculiarità di questo software è la capacità di eseguire in tempo reale l analisi del traffico e il packet logging (utile per debuggare il traffico della rete) su IP networks. Può compiere analisi dei protocolli, può individuare una gran varietà di attacchi e probes, come buffer overflow, port scanning, attacchi CGI e probes SMB. Analizzando i file di log è possibile determinare a quale tipo di attacco si è stati soggetti. Un uso efficace dei meccanismi di logging è fondamentale per la sicurezza di un sistema. E' possibile usare programmi di filtro dedicati, che periodicamente effettuano uno scanning sui principali file di log di sistema, verificando eventuali anomalie, come ad esempio parecchie connessioni dallo stesso indirizzo IP in un brevissimo intervallo di tempo. Si possono anche scrivere programmi di logging dedicati per difendersi, quando possibile, da attacchi tipo SYN flooding. Snort utilizza un semplice linguaggio formale di descrizione di regole flessibili e potenti che consente di descrivere che tipo di traffico dovrebbe essere catturato o ignorato e di individuare traffico ostile o semplicemente sospetto sulla rete. Snort può lavorare in diverse modalità: - Packet Sniffer. E capace di ispezionare il carico dei pacchetti sulla rete, decodificando il livello di applicazione di un pacchetto e catalogando il traffico basato su un certo contenuto di dati. Può anche filtrare il traffico attraverso BPF (comandi Berkley Packet Filter), i quali lo rendono flessibile nel catalogare specifici tipi di dati basati sull insieme delle regole. - Packet Logger. Può effettuare il log dei pacchetti indirizzati ad una specifica locazione, in un syslog, ed inviare alert a video. Uno dei migliori vantaggi è che esso effettua il log in formato leggibile decodificato in una directory basata su IP sorgenti. Esegue anche il log di pacchetti in formato binario su un singolo file oppure su database relazionale, come Oracle o MySQL. - Intrusion Detection. Può essere usato come IDS su reti dove sono richieste alte prestazioni. Precisamente può essere posizionato tra il firewall, che controlla una 41

48 Snort 2.0 sottorete, e il perimetro esterno non sicuro, analizzando in questo modo il traffico diretto al firewall; oppure può essere posizionato all'interno di una rete locale, mantenendone in questo modo sotto controllo il traffico. E' progettato per essere un tool veloce, di alerting in tempo reale, quando sono individuate attività sospette. I sistemi operativi su cui si può installare Snort sono: Linux, OpenBSD, FreeBSD, NetBSD, Solaris, SunOS 4.1.X, HP-UX, AIX, IRIX, Tru64 (tutti sistemi Unix like), MacOS (su sistemi Macintosh), Win32 (Win9x/NT/2000/XP). Dopo aver installato Snort, si possono scaricare ed installare dei file di regole, aggiornati periodicamente, dall indirizzo Questi file contengono tutte le regole concernenti una serie di attacchi noti, ma nulla vieta di scrivere un proprio file di regole. 4.1 COMPONENTI DI SNORT La struttura interna di Snort può essere divisa nei seguenti moduli principali: - Packet capturing e decoding engine; - Rules parsing e detection engine; - Logging engine; - Plugin e preprocessor engine. Per utilizzare Snort come IDS è necessario passare alla linea di comando (usando l opzione c) il file snort.conf contenente la configurazione del software e il collegamento alle regole. In questo modo il programma inizializza le seguenti parti del sistema: dopo aver fatto il parsing degli argomenti della linea di comando, usando la funzione ParseCmdLine(), eventualmente passando nella modalità daemon, inizializza i preprocessori ed i plugin, quindi legge i file delle regole. Questa funzione è svolta dalla routine ParseRulesFile() che fa parte del modulo rules parsing engine. Durante questo processo vengono chiamate le routine di inizializzazione dei preprocessori e dei plugin. 42

49 Snort 2.0 Quando tutte le regole sono state lette e tradotte nel formato interno, viene inzializzato il sistema di logging e infine viene chiamata la routine Pcap_loop() (fig. 15). Figura 15 - Schema a blocchi di Snort La routine Pcap_loop() chiama la routine ProcessPacket() ogni volta che viene catturato un pacchetto. ProcessPacket() è il punto di ingresso del modulo packet capturing e decoding engine e funge da switch-point per le diverse routine che svolgono un iniziale decodifica dei pacchetti a seconda dello specifico datalink. Durante l intero cammino del pacchetto vengono opportunamente riempiti i campi della struttura Packet. Ogni routine ( DecodeEthPacket(),DecodePppPacket(), DecodeFDDIPacket() ecc...) riempie i campi della struttura Packet che riguardano il livello datalink quindi, prima di ritornare, chiama la routine di decodifica appropriata per il livello network. Le routine di decodifica del livello network lavorano allo stesso modo; anch esse riempiono i campi appropriati della struttura Packet e passano il controllo alle routine di decodifica del livello di trasporto, se queste sono definite, o altrimenti ritornano. Sono supportati i protocolli TCP, UDP, IP e ICMP. 43

50 Snort 2.0 Quando la decodifica del pacchetto è terminata, il pacchetto, se richiesto, viene loggato, passa attraverso i preprocessori ed infine arriva al detection engine. Quest ultimo inizia con la funzione Detect() che scorre la lista linkata delle regole e confronta il pacchetto con ognuna di esse. Se il pacchetto coincide con una regola, il processo di rule-check viene fermato e viene generata un azione di alert o di log PACKET CAPTURING E DECODING ENGINE La maggior parte delle routine che appartengono a questo modulo si trovano nel file decode.c del codice sorgente di Snort. La routine ProcessPacket() è il punto di ingresso di questo modulo. Essa viene invocata da pcap_loop, una funzione libpcap, quando il pacchetto viene catturato e riceve due puntatori: uno alla struttura libpcap pcap_pkthdr che contiene informazioni sul pacchetto catturato, la sua lunghezza totale, la lunghezza catturata, i timestamp ecc.; e un puntatore ad un array di u_char byte che è proprio il pacchetto catturato. Da questo punto in poi viene riempita la struttura Packet che è definita nel file header decode.h. A questo punto viene chiamata la funzione di decodifica del livello datalink (DLD) (fig. 16) e il puntatore grinder viene assegnato dalla funzione SetPacketProcessor() ad una delle funzioni DLD definite nel file decode.c. Le funzioni DLD sono le seguenti: - DecodeEthPkt( ) decodifica i pacchetti per le interfacce Ethernet 10Mb/s. - DecodeIEEE80211Pkt() decodifica i pacchetti provenienti da interfacce WiFi - DecodeNullPkt( ) decodifica i pacchetti per l interfaccia di loopback. - DecodeTRPPkt( ) decodifica i pacchetti per le interfacce Token Ring. - DecodeFDDIPkt( ) decodifica i pacchetti per le interfacce FDDI. - DecodePPPoEPkt() decodifica i pacchetti provenienti da interfacce ethernet collegate a modem ADSL - DecodePppPktEncapsulated() e DecodePppPkt(): si tratta di due funzioni che svolgono la decodifica dei pacchetti per le interfacce ppp. - DecodeSlipPkt( ) decodifica i pacchetti per le interfacce slip. - DecodeRawPkt() su alcune piattaforme le interfacce ppp ritornano DLT_RAW quando viene richiesto il tipo del datalink.questa routine gestisce tali interfacce. - DecodeI4LRawPkt( ), DecodeI4LCiscoRawPkt( ), come sopra. 44

51 Snort 2.0 Figura 16 - Schema a blocchi del ciclo in pcap_loop Ogni decodificatore di pacchetti lavora allo stesso modo. Riempie i puntatori appropriati della struttura Packet e poi passa il controllo alla funzione DecodeIP() o DecodeArp() (fig. 17). Figura 17 - Rappresentazione delle relazioni che ci sono tra i diversi decodificatori 45

52 Snort 2.0 Nel file decode.h sono definite le strutture dati per i diversi header dei pacchetti al livello datalink (header Token Ring, header FDDI, header Ethernet ecc. ), e anche le strutture dati per gli header TCP, UDP, IP e ICMP. La routine DecodeIP() prende come argomenti la lunghezza del datagramma IP, un puntatore alla struttura Packet e un puntatore al pacchetto stesso. Dopo alcune verifiche sulla lunghezza del pacchetto (non deve essere minore della lunghezza minima dell header) e sulla versione del protocollo, se la lunghezza dell header del pacchetto è maggiore di 20 byte, allora il datagramma ricevuto contiene delle opzioni e quindi viene invocata la funzione DecodeIPOptions(). Fatto ciò vengono riempiti i rimanenti campi dell header. Quando viene analizzato l header IP, la funzione DecodeIP() usa il campo ip_proto come switch per invocare la funzione di decodifica del livello di trasporto (TLD) appropriata. Al momento sono definite le funzioni di decodifica per i protocolli TCP, UDP, IP ed ICMP. Se il protocollo non corrisponde a nessuno dei seguenti, viene settato il puntatore al payload del pacchetto IP, il decoding engine termina e il controllo passa alla routine ProcessPacket(), altrimenti la funzione TLD riempie i campi appropriati della struttura packet e ritorna RULES PARSING E DETECTION ENGINE Questo modulo risiede per lo più nel file rules.c del codice sorgente di Snort. Esso può essere ulteriormente diviso in due moduli principali: il traduttore di regole e il detection engine. Il traduttore di regole viene attivato durante la fase di inizializzazione e il punto d ingresso in questo modulo è la funzione ParseRulesFile(). Essa riceve il nome del file di cui fare il parsing e un contatore del livello di profondità degli include e non ritorna niente. Fondamentalmente questa funzione legge il file linea per linea, saltando i commenti, le linee vuote e rimuovendo gli spazi vuoti, quindi passa le linee, una ad una, alla funzione ParseRule(). Questa funzione esegue un espansione delle variabili, se necessaria, quindi processa ogni direttiva contenuta nella linea traducendo la regola nel formato interno di rappresentazione delle regole oppure eseguendo operazioni come gli include di file o definizioni di variabili, ecc. 46

53 Snort 2.0 Le regole internamente sono rappresentate come liste concatenate bidimensionali che rappresentano rispettivamente l header e le opzioni delle regole (fig. 18). Ogni regola internamente è associata alla struttura RuleTreeNode (fig. 19) definita nel file rules.h. Quando una linea contenente una regola viene tradotta nella rappresentazione interna, viene chiamata la funzione ProcessHeadNode() che scorre la catena di regole e la inserisce alla fine. Ogni elemento RuleTreeNode contiene un puntatore alla lista linkata RuleFpList che è la lista contenente le funzioni di detection per quell header, un puntatore al nodo successivo (right), un puntatore alla testa della lista e uno alla lista contenente le opzioni delle regole. In un modo simile sono mantenuti i nodi contenenti le opzioni delle regole. Figura 18 - Rappresentazione interna delle regole Ogni singola opzione è rappresentata con la struttura OptTreeNode definita nel file rules.h. Il modulo detection inizia con la funzione Preprocessor() che riceve come argomento il puntatore alla struttura Packet, poi invoca tutte le funzioni dei preprocessori contenute nella lista PreprocessList quindi chiama la routine Detect() che applica le regole contenute nelle liste descritte in precedenza al pacchetto corrente usando la funzione 47

54 Snort 2.0 EvalPacket(), infine fa partire le funzioni di output alert o di log se ciò è richiesto. Le regole sono valutate da sinistra a destra e le opzioni dall alto in basso. Figura 19 - Struttura rule tree node LOGGING ENGINE Questo modulo risiede per lo più nel file log.c (anche i plugin output possono considerarsi parte di questo modulo). Ci sono due punti d ingresso in questo modulo, le funzioni CallAlertPlugins() (fig. 20) e CallLogPlugins(). I puntatori AlertFunc e LogFunc puntano alle funzioni menzionate, e le funzioni CallAlertFuncs() e CallLogFuncs() fanno partire le funzioni di alert/log per una regola. Ci sono diverse routine che sono messe a disposizione per il packet logging, vengono chiamate dai moduli di rule processing e detection engine o dal modulo che si occupa della decodifica dei pacchetti a seconda del tipo di regola o delle opzioni che contiene, delle opzioni passate a linea di comando, del settaggio dei plugin di output, ecc. Ci sono funzioni che permettono vari tipi di alert: fast alert, full alert, none alert e unix socket alert, anche se queste funzioni possono considerarsi obsolete in quanto sostituite dai vari plugin output. Infine ci sono funzioni che stampano i vari tipi di pacchetti definiti come PrintEtHeader, PrintIPheader, ecc. Tra i plugin di output si segnalano il modulo Database, scritto da Jed Pickel, in grado di inviare gli alert a diversi tipi di 48

55 Snort 2.0 database SQL, e il modulo CSV, che permette l'output degli alert in un formato facilmente importabile dai database. Figura 20 - Schema a blocchi della funzione CallAlertPlugins PLUGIN E PREPROCESSOR ENGINE Il modulo che si occupa di questa funzione si trova nel file plugbase.c e nei vari file sp* (i file degli Snort plugin). In generale ci sono 3 tipi di moduli add-on per Snort: i plugin, i preprocessori e i plugin output. Ognuno di questi viene gestito separatamente. La differenza maggiore tra essi consiste nel fatto che i plugin di solito vengono invocati con parole chiave presenti nelle regole, i preprocessori vengono invocati prima che il pacchetto sia decodificato, mentre i plugin output vengono invocati quando il programma deve generare un messaggio alert o un log. I plugin presenti attualmente in Snort possono essere suddivisi in due classi distinte: i preprocessori e i moduli output. I preprocessori sono stati introdotti nella versione 1.5 di Snort ed hanno permesso l estensione delle funzionalità di Snort. Il codice del preprocessore viene eseguito prima 49

56 Snort 2.0 che il pacchetto arrivi al detection engine ma dopo che esso è stato decodificato dal packet decoder, che è un altro elemento fondamentale dell architettura di Snort. Questo meccanismo fa sì che il pacchetto sia analizzato o modificato in modo cosiddetto out of band. La parola chiave per caricare e configurare il preprocessore è preprocessor. L istruzione contenuta nel file delle regole di Snort ha il seguente formato: preprocessor <name> : <options>. I moduli preprocessori attualmente forniti con Snort sono: - Minfrag: esamina i pacchetti che sono stati frammentati ed hanno una grandezza al di sotto di una soglia stabilita. Poiché nelle reti commerciali si è visto che difficilmente il pacchetto viene frammentato al di sotto dei 512 bytes, di solito si usa questa grandezza come soglia; - HTTP Decode: usato per processare le stringhe HTTP URI e convertire i loro dati in stringhe ASCII. Questo modulo è stato sviluppato per contrastare quegli attacchi che cercano di evadere l analisi del contenuto delle stringhe, usate per esaminare il traffico http per scopi sospetti. Questo preprocessore prende come argomenti la lista delle porte su cui girano i servizi http (generalmente 80 e 8080); - Portscan Detector: è stato sviluppato da Patrick Mullen, è definito come un tentativo di connettersi a N porte TCP in T secondi o di mandare N pacchetti UDP in T secondi. Le porte possono anche essere sparse su diversi indirizzi IP. Crea il log sullo standard logging contenente l inizio e la fine dei portscan da un singolo indirizzo IP sorgente; se viene specificato un file di log, esso indica gli indirizzi IP di destinazione e le porte su cui si è fatto lo scan nonché il tipo di scan; - Portscan Ignorehosts: scritto anch esso da Patrick Mullen serve ad indicare una lista di host su cui non si deve applicare il portscan detector. L argomento di questo preprocessore è la lista degli indirizzi IP/CIDR degli host che si vuole scartare; - Frag2: introdotto a partire da Snort 1.8, è un preprocessore che si occupa della deframmentazione a livello IP. Frag2 è progettato per sostituire il preprocessore Defrag. E' stato sviluppato utilizzando tecniche di ottimizzazione dell'uso della memoria, che è completamente configurabile, così come il periodo di timeout; 50

57 Snort Stream4: fornisce a Snort la funzionalità di riassemblare uno stream di dati TCP. Gli stream di dati TCP su una porta specificata vengono trasformati in un singolo stream che può essere analizzato da Snort per rilevare attività sospette. Inoltre aggiunge capacità di analisi statefull, al fine di limitare i falsi positivi dovuti all'utilizzo di tool come Snot o Stick. Nella sua configurazione di default permette di tenere traccia di connessioni TCP simultanee; - Conversation: permette di tenere traccia di connessioni diverse dal protocollo TCP. Inoltre esegue il controllo sul campo IP Protocol dell'header IP, sulla base dei protocolli ammessi sulla rete sotto controllo e impostati in fase di configurazione; - Portscan2: implementa il rilevamento delle attività di portscanning. In particolare è in grado di rilevare portscan veloci come quelli effettuati per mezzo di Nmap. Richiede che sia presente anche il preprocessore Conversation; - Telnet decode: permette a Snort di normalizzare i caratteri di controllo del protocollo Telnet. Dalla versione 1.9 accetta una lista di porte su cui effettuare il controllo, oltre alla possibilità di salvare in un buffer dedicato i pacchetti raw sospetti in modo da essere esaminati con routine aggiuntive; - RPC Decode: normalizza i record multipli frammentati in un singolo record non frammentato. Questa funzione viene eseguita normalizzando i pacchetti nel packet buffer. Se anche il modulo Stream4 è attivato, si limita ad esaminare solo il lato client della connessione. Come configurazione di default controlla il traffico sulle porte 111 e 32771; - Perf Monitor: è un modulo utilizzato per generare statistiche di performance di Snort; - HTTP Flow: è utilizzato per permettere a Snort di ignorare le risposte dei server http presenti dopo gli header. Le funzioni responsabili delle inizializzazioni dei vari moduli sono: InitPlugins(), InitPreprocessors(), InitOutputPlugins(). Ci sono anche un insieme di funzioni di registrazione (RegisterPlugin(), RegisterPreprocessor() e RegisterOutputPlugin()), che dovrebbero essere chiamate dai plugin prima della loro inizializzazione, e alcune funzioni che cancellano le diverse liste 51

58 Snort 2.0 di moduli all uscita del programma (AddFunctionToRestartList(), AddFunctionToClearExitList(), AddFunctionToSignalList()). 4.2 LA FLESSIBILITÀ DI SNORT Snort è sicuramente il sistema IDS più flessibile oggi esistente, grazie alla sua struttura completamente configurabile, in ogni suo aspetto. Non avendo un interfaccia grafica propria, il programma può essere configurato semplicemente modificando alcuni file, tramite un qualsiasi editor di testo. Esistono, comunque, sul mercato diversi software per la gestione di Snort tramite interfaccia grafica, che rendono l utilizzo di questo software più user-friendly. Tuttavia, agire direttamente sui file di configurazione rimane l opzione migliore per un amministratore capace. Snort è un IDS di tipo Signature Based, che si serve di diversi file di regole per rilevare gli attacchi. Tali file sono disponibili sul sito di Snort e vengono costantemente aggiornati. Le regole sono completamente modificabili e possono essere integrate con l aggiunta di nuove signature definite dall utente, a cui si richiede unicamente la conoscenza della sintassi necessaria LE REGOLE Per creare delle regole, basta scrivere un file in formato testo, seguendo la sintassi di Snort, e successivamente salvarlo con l estensione rules. Fatto ciò bisogna inserire nel file snort.conf (file che permette di modificare i parametri di configurazione) una linea di comando per includere il nuovo file contenente le regole. Esistono una serie di linee guida da seguire quando si scrivono nuove regole: innanzitutto devono essere scritte su di un'unica riga, infatti, il parser di Snort non riconosce regole scritte su più linee; e poi bisogna attenersi scrupolosamente al linguaggio formale necessario a definirle. Ogni regola è suddivisa in due sezioni logiche: - Header. Contiene le azioni delle regole, il protocollo, l indirizzo IP di origine e destinazione e le informazioni sulle porte; 52

59 Snort Options. Contiene i messaggi di alert e i parametri che servono per determinare se le regole di azione debbano essere eseguite. Questa sezione non è obbligatoria nella definizione della regola. Le regole seguono tutte questo formato: Azione protocollo sorg_ip/mask sorg_port -> dest_ip/mask dest_port (opzione 1; opzione 2; ;opzione n;) HEADER OPTIONS Dell header è possibile configurare i seguenti parametri: - Azione. Permette di definire il tipo di risposta da associare al riscontro della regola. In questa versione le azioni disponibili sono: alert (genera un alert usando il metodo definito durante l installazione di SNORT, e poi esegue il log del pacchetto); log (esegue il log del pacchetto); pass (ignora il pacchetto); activate (genera un alert e poi attiva un azione dynamic); dynamic (rimane inattiva finché non è attivata da un azione activate, poi agisce come un log). Attualmente l unica azione implementata nelle rules è alert. - Protocollo. Indica il protocollo usato dal pacchetto che può essere TCP, UDP, ICMP o IP. - Sorg_ip/mask, dest_ip/mask. Indicano rispettivamente indirizzo IP sorgente e destinazione del pacchetto insieme al blocco CIDR che indica la netmask utilizzata. Il formato consentito per gli indirizzi IP è il dotted quad, questo perché Snort non ha un meccanismo per la risoluzione dei nomi. In particolare il blocco CIDR /24 indica una Classe C, /16 una Classe B e /32 indica uno specifico indirizzo logico. Per esempio la combinazione sorg_ip/mask /24 si riferisce al blocco di indirizzi da a E possibile, usando la parola chiave any, definire come indirizzi da controllare qualsiasi indirizzo IP. Inserendo un indirizzo IP preceduto dal carattere! (operatore di negazione) si specifica a Snort di escludere la ricerca di codice sospetto nei pacchetti provenienti da tale indirizzo. Volendo è anche possibile inserire una lista di indirizzi IP nel seguente formato: [add1_ip/mask,add2_ip/mask, add3_ip/mask], attenzione a non inserire spazi tra le parentesi quadre. 53

60 Snort Sorg_port, dest_port. Indicano rispettivamente il numero decimale della porta sorgente e destinazione. Come per l indirizzo IP anche per le porte è possibile specificare che siano considerate tutte con la parola chiave any, tutte eccetto una o eccetto un range con! ed inoltre è possibile specificare un range di porte usando il separatore :. Un range si può specificare in diversi modi: A:B (tutte le porte comprese tra A e B inclusi); A: (tutte le porte con valore maggiore o uguale ad A); :B (tutte le porte con valore minore o uguale a B). - Direzione. Indica la direzione del traffico a cui è applicata la regola. Si definisce con il simbolo -> direzione dalla sorgente alla destinazione, che può essere anche inversa (<-) o bidirezionale (<>). Snort consente di gestire un gran numero di opzioni, con le quali è possibile controllare praticamente tutti i parametri dei vari protocolli gestiti e il payload del pacchetto. Tutte le opzioni sono separate tra loro dal punto e virgola. Le opzioni presenti in questa versione sono: Opzione Descrizione Esempio msg Consente di inserire un testo, che compare nel file msg: message ; di log e descrive brevemente l alert generato. log to Logga i dati generati dall alert in un file specificato log to: filename ; dall utente. Non funziona quando si usa il binary logging. ttl Confronta il time to live con il valore specificato ttl: number; (compreso tra 0 e 255). tos Controlla il campo type of service nell header IP. tos: number; id Controlla il campo id nell header IP alla ricerca di valori conosciuti usati dagli hacker. id: number; ipopts Controlla il campo options dell header IP. Per ogni regola si può specificare una sola opzione alla volta. Le opzioni disponibili sono: rr (record route); eol ipopts: options; 54

61 Snort 2.0 fragbits dsize content offset (end of list); nop (no operation); ts (timestamp); sec (IP security options); lsrr (loose source routing); ssrr (strict source routing); satid (stream identifier). Controlla se sono settati i campi fragment e reserved bits nell header IP. I bit controllabili sono reserved bit (R), more fragment (M) e don t fragment (D). Se all opzione segue il carattere speciale +, la regola scatta solo se oltre al bit specificato anche gli altri sono settati. Se invece si usa! il bit specificato non deve essere settato. Controlla la dimensione in ottetti del payload del pacchetto. Si può usare con gli operatori < e > per definire dimensioni minori o maggiori di un certo valore, oppure per definire dimensioni comprese fra due valori (x<>y). Specifica la firma del carico sospetto da cercare nel payload del pacchetto. Si possono inserire stringhe di testo, dati binari o esadecimali (racchiusi tra ). Nella stessa regola si possono inserire più content così da ridurre i possibili falsi positivi. Se il contenuto di content è preceduto da! la regola scatterà solo se il pacchetto non contiene questa informazione. Il campo content è case sensitive. Consente di specificare (in ottetti) da quale punto del payload cominciare a cercare il codice inserito in content (deve essere presente un content nella regola). fragbits: options; dsize: [< >] value; content:! string ; content: 0A 33 F3 ; offset: number; depth Come offset va specificato solo se esiste content. Definisce fino a che profondità cercare nel payload, ad esempio se si cerca un comando specifico basterà cercarlo in un ristretto numero di byte depth: number; 55

62 Snort 2.0 iniziali, senza dover confrontare tutto il contenuto del payload. nocase Non ha parametri, serve per non considerare il nocase; content case sensitive (sia caratteri maiuscoli, sia minuscoli). flags Testa i flags di TCP. I flags controllabili sono: F flags: options; (fin), S (syn), R (rst), P (psh), A (ack), U (urg), 2 (bit riservato 2), 1 (bit riservato 1), 0 (nessun flag settato). Anche per flags valgono i caratteri speciali + e! visti per fragbits. seq Controlla il valore del campo sequence number seq: number; nell header TCP. ack Controlla il valore del campo acknowledge number ack: number; nell header TCP. Molti scanner di rete settano questo campo a 0 e settano il flag ack per vedere se un host è attivo sulla rete. window Controlla la dimensione (in ottetti) del campo window: number; window nell header TCP. itype Controlla il valore del campo type nell header itype: number; ICMP. icode Controlla il valore del campo code nell header icode: number; ICMP. session Si usa per catturare una sessione TCP. Grazie a session: option; questa opzione è possibile vedere cosa digita un intruso durante un attacco (telnet, ftp, rlogin e sessioni web). Ha due parametri: printable (stampa nel log solo i caratteri digitabili), all (stampa tutti i caratteri e quelli non visibili li sostituisce con il valore esadecimale). icmp_id Controlla il valore del campo id nell header ICMP. icmp_id: number; icmp_seq Identico a icmp_id. icmp_seq: number; 56

63 Snort 2.0 rpc Controlla le richieste rpc e se l applicazione, la procedura e la versione del programma corrispondono ai valori inseriti. Si può usare il carattere speciale * per identificare un campo in modo generale. resp Specifica le flex resp associate alla regola. Le flex resp danno la possibilità di bloccare la connessione nei seguenti modi: rst_snd (invia reset alla sorgente), rst_rcv (invia reset al ricevente), rst_all (invia reset ad entrambi), icmp_net (invia rete irraggiungibile alla sorgente), icmp_host (invia host irraggiungibile alla sorgente), icmp_port (invia porta irraggiungibile alla sorgente), icmp_all (invia tutti i messaggi ICMP precedenti alla sorgente). Le opzioni si possono combinare separandole con la virgola. Per sfruttare le caratteristiche di resp bisogna installare Snort con l opzione flex resp. content-list Serve per definire una lista di content. Bisogna creare un file di testo dove inserire, uno per linea, i content (tra virgolette) da riscontrare. react Necessità delle flex resp. Permette di reagire in modo attivo alle connessioni. Ha due parametri base: block (blocca la connessione è spedisce un messaggio all utente), warn (spedisce solo il messaggio). Inoltre è possibile usare parametri addizionali per definire: msg (testo del messaggio da visualizzare), proxy:port_nr (usa la porta del proxy per spedire il messaggio). reference Indica su quali indirizzi web è possibile riferirsi per avere maggiori informazioni sulla regola. rpc: program, proc/*,vers/*; resp: option 1,, option n; content-list: filename; react: option, additional; reference: id system, id; sid Identificatore unico della regola. I range assegnati sono: minore di 100 (riservati ad usi futuri), tra 100 sid: number; 57

64 Snort 2.0 rev classtype priority uricontent tag e (regole incluse nella distribuzione di Snort), maggiore di (regole locali definite dall utente). Identifica le rules revisionate indicandone la versione. Definisce la classe di appartenenza della regola. Se si vuole creare una nuova classificazione per una regola bisogna inserire nel file classification.config una riga di testo indicando il nome della classe, una breve descrizione e la priorità da assegnare agli eventi di questa categoria. Il valore della priorità varia da 1 a 4, ma qualsiasi altro valore può essere specificato. Se viene specificato si sovrappone al valore di priorità definito nella classtype. Serve per discriminare la priorità fra le regole appartenenti alla stessa classe. Controlla il valore di una richiesta presente all inizio del payload. Consente di segnare con un tag tutti i pacchetti che transitano su una connessione dopo che il primo è stato riscontrato dalla regola, in modo da poter fare un analisi successiva del traffico sospetto. Questo parametro ha quattro opzioni: - type: session (logga i pacchetti della sessione), host (logga i pacchetti provenienti dall host che ha fatto scattare la regola; - count: è un numero necessario al campo metric; - metric: packets (tag per un numero di pacchetti definiti da count), seconds (tag per un numero di secondi definiti da count); - direction: indica la direzione del traffico. rev: number; classtype: name; priority: number; uricontent:! content string ; tag: type, count, metric, [direction]; 58

65 Snort 2.0 ip_proto Controlla l header IP alla ricerca di protocolli inusuali. ip_proto: number or name sameip Controlla se l IP sorgente è uguale a quello di sameip; destinazione (utile contro lo spoofing IP). flow Specifica la direzione del traffico e lo stato della connessione. Le opzioni disponibili sono: to_client flow: direction,option; (dal server verso il client), to_server (dal client verso il server), from_client (dal client verso il server), from_server (dal server verso il client), estabilished (solo le connessioni stabilite), stateless (controlla lo stato dello stream processor), no_stream (non trigga sullo stream riassemblato), only_stream (trigga solo sullo stream riassemblato). fragoffset Controlla il campo offset dell header IP. Può essere utile per catturare tutti i primi frammenti di diverse fragoffset: [< >] number; connessioni. rawbytes Controlla dati anomali su una connessione telnet. rawbytes; distance Definisce la distanza in ottetti fra gli argomenti di distance: byte; due content riscontrati nel payload del pacchetto sospetto. within Indica che fra due content, definiti nella regola, ci sono al massimo n ottetti. within: byte; byte_test Controlla il valore di un numero di byte definiti dall utente in base ai seguenti parametri: bytes_to_convert (numero di byte da controllare); operator (operazione che caratterizza il test [<,>,=,!]); value (valore da confrontare); offset (indica il punto di inizio della ricerca nel payload). Segue un ultimo parametro che effettua la conversione del valore in byte nei seguenti formati: relative (usa un offset relativo all ultimo pattern catturato); big (processa i dati in ordine big endian); byte_test: byte_to_convert, operator, value, offset, conversione1, conversione2; 59

66 Snort 2.0 little (processa i dati in ordine little endian); string (i dati sono memorizzati in formato stringa); hex (converte una stringa in esadecimale); dec (converte una stringa in decimale); oct (converte una stringa in base otto). Esempio di regola (fig. 21): Figura 21 - Esempio di regola per Snort Le opzioni possono essere combinate in qualsiasi modo per rilevare e classificare pacchetti sospetti e sono processate usando un AND logico; quindi tutte le opzioni elencate nella regola devono essere rispettate affinché sia generato l alert. In riferimento alla regola precedente (fig. 21), ciò che Snort fa, si può rappresentare schematicamente nella figura seguente (fig. 22): Figura 22 - Reazione di Snort al ricevimento di un pacchetto contenente pattern sospetto 60

67 Snort IMPLEMENTAZIONE DI SNORT Snort è fornito privo di tools di gestione, configurazione e raccolta dei dati relativi agli alert. Originariamente, infatti, Snort prevede la configurazione mediante un file contenente le direttive di funzionamento e le regole da attivare, mentre per quanto riguarda gli alert, vengono semplicemente memorizzati come file di testo all interno della directory dei log del sistema operativo. Una semplice configurazione di questo tipo ovviamente non risponde alle necessità di utilizzo in un ambiente aziendale complesso, magari costituito da più sottoreti da mantenere sotto controllo. Per questo motivo sono stati sviluppati moduli opzionali aggiuntivi che permettono una notevole scalabilità e flessibilità di utilizzo in situazioni più diverse, dalla singola rete locale a reti multiple poste in siti diversi e da mantenere sotto controllo mediante una singola postazione centralizzata. L implementazione scelta per la sperimentazione è quindi stata quella che prevede l utilizzo di un browser web come interfaccia utente, sia per la configurazione dell IDS che per la consultazione dei dettagli riguardanti gli alert, che vengono memorizzati in un database SQL. Si è quindi resa necessaria la configurazione ad-hoc di una macchina dedicata alla funzione di IDS, tenendo conto comunque che tale implementazione può essere realizzata distribuendo le varie funzioni su più macchine, secondo il paradigma three tier. In particolare i pacchetti utilizzati sono: - Sistema Operativo Linux RedHat 9 ( /iso/i386/ ); - Web Server Apache ( ); - IDS Snort ( ); - MySQL versione ( ); - Tool di analisi degli alert Puresecure versione 1.60 Pro Eval ( ). La macchina utilizzata è un laptop Secure Vision 3000 dotata di processore Intel Pentium III 1 Ghz, 128 Mb di memoria RAM, 20 Gb di HD e una scheda di rete Realtek 61

68 Snort fast ethernet 10/100Mbit SISTEMA OPERATIVO Si è scelto di utilizzare come sistema operativo Red Hat 9, una delle numerosissime distribuzioni Linux, poichè fornisce un ampio supporto di software applicativo, oltre a garantire buone caratteristiche di sicurezza e facilità di installazione e aggiornamento. Tuttavia tale scelta non è vincolante in quanto per il funzionamento di Snort, che viene distribuito sotto forma sorgente, è sufficiente una qualunque distribuzione Linux recente comprensiva dei tool di sviluppo (compilatori e file header dei sorgenti del kernel). L installazione del sistema operativo sulla macchina non ha comportato problemi, tutte le periferiche sono state riconosciute e configurate automaticamente. La procedura di installazione di Linux RedHat prevede la possibilità di scegliere tra diverse configurazioni predefinite (Server, Workstation) oppure di indicare manualmente quali pacchetti applicativi installare. Questi ultimi possono comunque essere installati in un secondo momento in maniera molto semplice utilizzando il sistema a pacchetti RPM di RedHat WEB SERVER Come web server la scelta è caduta sull ormai più che noto e consolidato Apache nella versione Il web server è stato successivamente configurato in modo da utilizzare il modulo "Mod_SSL", che permette di stabilire connessioni HTTPS protette con i client SNORT L'installazione di Snort non ha presentato difficoltà particolari, è stato sufficiente scaricare i file sorgenti dal sito compilarli e installarli. Nell'implementazione presentata Snort rappresenta solo uno dei vari componenti del sistema IDS. Infatti, esso costituisce il sensore vero e proprio che esegue l'analisi del traffico e fornisce gli alert relativi agli attacchi rilevati. L'installazione di Snort è stata eseguita sulla stessa macchina su cui è presente il database degli alert, il server web e l applicativo di configurazione e gestione. Tuttavia 62

69 Snort 2.0 è possibile installare Snort su più macchine poste in luoghi diversi, purché raggiungibili mediante una connessione TCP/IP. Durante la fase di compilazione di Snort è stata specificata un'opzione che prevede l'output degli alert verso un database MySQL MYSQL 4 MySQL è un RDBMS (Relational Database Management System - Sistema di gestione per Database Relazionali) Open Source attraverso il quale è stato creato un archivio utilizzato da Puresecure, contenente i dati relativi agli allarmi generati. Come detto precedentemente, MySQL non deve essere necessariamente installato sulla stessa macchina su cui è installato il sensore né su quella su cui è presente il server web; infatti è utilizzabile in maniera remota tramite connessione TCP/IP. In questo modo, in ambito aziendale, è possibile utilizzare installazioni MySQL preesistenti PURESECURE Demarc Puresecure v1.6 è un applicativo completo, capace di fornire monitaraggio del traffico, informazioni sullo stato della rete e controllo della consistenza dei file di sistema. Integrato con la tecnologia di SNORT diventa uno strumento molto potente per la gestione del proprio sistema IDS. Puresecure è composto di due componenti, un server ed un client. Il server ha il compito di centralizzare tutte le funzioni necessarie a gestire il sistema antintrusione, mentre il client può essere usato per la configurazione remota di SNORT. E anche possibile definire diversi livelli di accesso per gli utenti. L interfaccia utente di Puresecure è scritta in Perl e PHP, è di facile interpretazione e gestione (fig. 23). Puresecure necessità della presenza di un web server che deve essere installato sulla stessa macchina dove è situato il prodotto della Demarc. Una volta effettuato il login, l utente ha la possibilità di visualizzare le informazioni relative agli allarmi, con un dettaglio molto elevato, in cui viene inserito anche una parte del pacchetto (fig. 24). La console consente di effettuare operazioni sugli eventi, di configurare il sistema antintrusione, i parametri di Puresecure e le caratteristiche di accesso utente. 63

70 Snort 2.0 Figura 23 Console di comando di PureSecure Figura 24 Dettaglio di un pacchetto catturato 64

71 Snort PROVA EFFETTUATA Per valutare la flessibilità e la capacità di adattamento alle possibili realtà aziendali di Snort sono state create venti regole formattate in modo da valutare il funzionamento e l efficacia delle opzioni disponibili. Le regole non hanno la pretesa di rilevare attacchi reali, ma solo lo scopo di valutare gli strumenti messi a disposizione dell utente. Provando che Snort è in grado, in base a regole inventate, di rilevare traffico con caratteristiche definite dall utente; si vuole dimostrare che un amministratore esperto può essere in grado di personalizzare l IDS per discriminare tipologie di traffico e rilevare attacchi reali. Per ottenere chiarezza e pieno controllo degli allarmi generati ogni regola contiene poche opzioni da controllare durante la cattura dei pacchetti. In questo modo si riesce a generare un allarme per ogni specifico caso, senza incappare in falsi positivi. Sono stati quindi creati appositi attacchi, sui quali fosse possibile applicare rule semplici che ne rilevassero la presenza. Successivamente le regole sono state divise in quattro file, uno per ogni protocollo gestito da Snort (TCP, UDP, IP e ICMP). I file sono stati poi inclusi nella configurazione di Snort, in modo che fossero caricati durante l avvio in modalità daemon. Tutti gli atri file di rules forniti insieme a Snort sono stati esclusi, questo per ottenere solamente la visibilità delle regole create ad hoc LE RULES CREATE Di seguito viene riportato l elenco di rules, definite per effettuare le prove, distribuite nei quattro file con associato l attacco necessario alla generazione dell allarme. File TCP-test.rules: alert tcp $EXTERNAL_NET any -> $HOME_NET 20:21 (msg:"ftp PUT Virus"; content:"stor"; content:"virus"; nocase; classtype:test;) Questa rule rileva se viene spostato sul server ftp, appartenente alla home net, un file contenente codice sospetto. Utilizzando il comando PUT e trasferendo un file vuoto 65

72 Snort 2.0 chiamato virus (indifferente l uso di caratteri minuscoli o maiuscoli, poiché la regola contiene l opzione nocase) si ottiene la generazione di un allarme. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ftp transfer Sourcecod to client"; content:"sourcecod"; nocase; dsize:<180; classtype:test;) L allarme viene generato se sul canale dati FTP viene trasferito il file chiamato sourcecod, dal server ad un client esterno. L opzione dsize è stata usata (oltre che per essere testata) per distinguere questo attacco da quello della regola successiva, grazie al fatto che il file essendo vuoto occupa meno di 180 byte. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"client FTP looking for Sourcecod"; content:"sourcecod"; dsize:>181; nocase; classtype:test;) Se un client dall esterno richiede tramite il comando ls o dir la lista dei file contenuti nella stessa cartella dove è presente anche il file sourcecod, il passaggio dei dati dal server al client farà scattare quest allarme. alert tcp $EXTERNAL_NET any -> $HOME_NET 20:21 (msg:"client FTP GET Source"; content:"retr"; content:"sourcecod"; nocase; classtype:test;) Se un host dall esterno richiede tramite il comando GET di prelevare dal server FTP un file, chiamato sourcecod, verrà visualizzato sulla console un messaggio di allarme relativo alla seguente regola. alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ftp bad file stored"; content:" "; offset:57; depth:3; classtype:test;) In questo caso è stato creato un file contenente del testo.dopo aver catturato il pacchetto con uno sniffer è stato possibile definire con precisione la posizione e il valore in byte della parola qui, in modo da creare una regola capace di riscontrare questo tipo di evento (questa teoria è la stessa usata per l individuazione delle signature che contraddistinguono un codice dannoso). La regola è in grado di generare un allarme se il file viene trasferito sul server FTP, per farlo confronta il valore del campo content (rappresentazione esadecimale della parola qui ) con il payload dei pacchetti, tenendo conto di dover saltare i primi 57 byte del carico e di non cercare oltre i successivi 3. 66

73 Snort 2.0 alert tcp $EXTERNAL_NET any -> $HOME_NET 135:139 (msg:"port scanner NMAP"; flags:s; ack:0; classtype:test;) Questa regola genera un allarme se viene usato Nmap, un famoso scanner fornito insieme al sistema operativo Linux. Questo scanner invia un pacchetto con il bit Syn settato e acknowledge number uguale a 0 a tutte o ad un range di porte definito dall utente verso un host vittima. Il suo scopo è scoprire quali e quante porte risultano aperte sul sistema. Grazie a questa caratteristica la regola riesce ad individuare l attacco. Poiché viene generato un allarme per ogni pacchetto catturato, si è scelto di limitare il controllo a cinque porte (dalla 135 alla 139) in modo da ottenere solo cinque segnalazioni a video. alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"sequence 13 and Window 17 to port 135"; seq:13; window:17; classtype:test;) Inviando un pacchetto indirizzato alla porta 135 con sequence number 13 e window 17 formato con Hping2, un tool che permette di modificare i campi dei protocolli di comunicazione TCP, UDP, IP e ICMP; viene generato un allarme. Questa rule mette bene in evidenza la grande flessibilità posseduta da Snort. alert tcp $EXTERNAL_NET any -> $HOME_NET 20:21 (msg:"session FTP"; dsize:>2; session:printable; classtype:test;) Grazie all opzione session è possibile catturare tutto il traffico generato dalla sessione FTP. Tutti i comandi digitati dall intruso vengono loggati per poter essere studiati successivamente. alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"get /error.htm"; uricontent:" f 72 2e d ";classtype:test;) In questo caso viene controllato se al server web è richiesta la pagina error.htm. L opzione uricontent permette di testare solo il campo relativo all uri, confrontando il valore esadecimale della stringa error.htm con il path inserito nella richiesta (se l intruso utilizzasse caratteri maiuscoli questa regola non genererebbe allarmi). 67

74 Snort 2.0 alert tcp $EXTERNAL_NET!139 -> $HOME_NET 1024: (msg:"ftp PUT offset file with distance and within parameters";content:"q"; content:"i"; nocase; distance:1; within:3; classtype:test;) La regola genera un allarme se viene trasferito sul server FTP un file di testo (chiamato offset) contenente la stringa q ui. Grazie alle opzioni distance e within è possibile individuare la stringa sospetta all interno del payload del pacchetto. File UDP-test.rules: alert udp $EXTERNAL_NET any -> $HOME_NET any (msg:"rpc program "; rpc:100000,*,*; classtype:test;) L Invio di un pacchetto UDP con il comando rpcinfo u HOME_IP verso un host su cui è attivo il servizio RPC causerà la generazione dell allarme relativo a questa regola. alert udp $EXTERNAL_NET any -> $HOME_NET any (msg:"probable Traceroute"; ttl:1; classtype:test;) Lo scopo del comando traceroute è individuare il percorso che un pacchetto compie dalla sorgente verso una destinazione impostata. Per farlo invia un pacchetto UDP con ttl impostato a 1, in modo tale che i sistemi intermedi scartino il pacchetto rispondendo con un messaggio ICMP di time exceeded. In questo modo, inviando nuovamente pacchetti con ttl più alto, per ogni hop effettuato dal pacchetto si ottiene la lista di tutti i sistemi intermediari fino al destinatario che risponderà con un messaggio ICMP di port unreachable. Questa regola controlla se sulla rete sta passando un pacchetto con ttl a 1. Normalmente una situazione del genere non determina necessariamente che si tratti di traceroute. File IP-test.rules: alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"ip bad More Fragment"; fragbits:m; dsize:<1479; classtype:test;) Tramite l opzione fragbits questa regola è in grado di controllare se un datagramma IP ha il bit di more fragment settato e una dimensione minore di 1479 byte. 68

75 Snort 2.0 alert ip any any -> any any (msg:"probable IP Spoofing"; sameip; classtype:test;) In questo caso viene generato un allarme se nel pacchetto catturato sia l indirizzo mittente sia quello destinatario sono uguali. Questa semplice regola è in grado di rilevare se sulla rete sta avvenendo un caso di IP spoofing. alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"fragment offset IP set"; fragoffset:>1; fragbits:!d; classtype:test;) Se un pacchetto IP con offset maggiore di 1 e bit don t fragment non settato passa sulla rete, verrà catturato e genererà un allarme sulla base di questa regola. File ICMP-test.rules: alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp echo Ping Request with Record Route"; itype:8; ipopts:rr; classtype:test;) Questa regola genera un allarme se arriva una richiesta ICMP con l opzione record route. alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"icmp echo Ping Reply with Record Route"; itype:0; ipopts:rr; classtype:test;) Alla richiesta ICMP con opzione record route segue una risposta, se non esistono impostazioni di comportamento diverse. Questa regola è in grado di rilevare i pacchetti di risposta. alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp echo Ping Request Timestamp with Tag parameter"; itype:8; tag:host,3,packets; ipopts:ts; classtype:test;) Il comportamento di questa regola è simile a quello per i pacchetti con l opzione record route, qui però, viene rilevata la richiesta con timestamp, grazie al parametro tag messo a disposizione da SNORT. alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"reply to probable Traceroute"; itype:3; icode:3; content:" 01 "; offset:12; depth:1; classtype:test;) 69

76 Snort 2.0 Poiché nelle risposte ICMP viene inserita una parte del pacchetto che ha generato l errore, grazie alle opzioni content, offset e depth, è possibile controllare se si tratta di una errore dovuto a traceroute. Infatti basta verificare se nel carico di informazioni aggiuntive fornite da ICMP è presente il valore 1 in una precisa posizione corrispondente al campo ttl del pacchetto iniziale. Quindi se viene lanciato traceroute verso la home net, il messaggio di risposta ICMP (in questo caso port unreachable perché si è assunto di essere la destinazione da raggiungere) genera la segnalazione di un allarme sulla base di questa regola. alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp Flood"; id:0; ip_proto:1; icmp_seq:50; classtype:test;) Eseguendo il comando, fornito da tutti i sistemi operativi, ping f HOME_IP (sotto sistema Linux), l host vittima viene sommerso di pacchetti ICMP echo request. Questa regola segnala se un attacco di questo genere sta avvenendo. L opzione icmp_seq controlla il numero di sequenza progressivo del pacchetto ICMP, impostato a 50 permette di generare un solo allarme corrispondente al cinquantesimo pacchetto OPZIONI ESCLUSE Non tutte le opzioni disponibili sono state prese in considerazione, di seguito viene riportato l elenco delle opzioni escluse con la motivazione: - Log, pass, activate e dynamic: sono azioni disponibili per diversificare la modalità di risposta ad un evento. La loro esclusione è dovuta al fatto che attualmente non sono usate nei file di rules forniti con Snort, perchè l azione alert oltre a generare un allarme fa anche il log del pacchetto catturato, e quindi da sola è sufficiente. - Log to: non è usata e non serviva fare il log in locazioni diverse da quella di default. - Tos, resp, react, content-list,: non vengono usate nelle regole attuali disponibili con Snort. - Icmp_id: si è preferito utilizzare icmp_seq. - Rawbytes, byte_test, byte_jump: sono usati raramente e si è scelto di non testarli. 70

77 Snort Reference, rev, sid, priority: sono molto usati nelle rules di Snort, ma non era rilevante ai fini della prova testarne l efficacia. - Flow: è un opzione molto usata, tuttavia non essendo un parametro riconosciuto dai sistemi IDS commerciali si è preferito non farne uso, per facilitare la prova relativa all integrazione delle regole per Snort nei suddetti sistemi RISULTATI OTTENUTI Dopo aver avviato Snort in modalità daemon e integrato le rules nella configurazione del programma, sono stati lanciati i comandi necessari a far scattare gli allarmi. Utilizzando la console Puresecure è stato possibile verificare l effettivo riscontro degli allarmi da parte di Snort. Tutte le regole sono state riscontrate esattamente come mostrato in figura 25. Snort si è dimostrato uno strumento eccezionale, grazie alla sua flessibilità ha permesso di definire regole capaci di individuare situazioni particolari di traffico non rilevabili con le normali tecniche. Figura 25 Resoconto degli attacchi rilevati da Snort E stato dimostrato, che oltre alle sue già note capacità di rilevamento delle intrusioni, Snort offre la massima flessibilità e quindi risulta essere uno strumento adattabile a qualsiasi esigenza aziendale. Infatti, nelle prove effettuate con gli altri sistemi 71

78 Snort 2.0 antintrusione, Snort è stato preso come punto di riferimento per valutare la capacità di adattamento alle diverse realtà aziendali che offrono i sistemi IDS commerciali CONCLUSIONE In conclusione i vantaggi offerti da SNORT sono la capacità per un amministratore di definire nuove regole per rispondere a nuovi attacchi, in modo semplice e più rapido di qualsiasi sistema commerciale; la sua struttura modulare che lo rende rapido e potente; la caratteristica di essere open source, quindi completamente libero e programmabile; il fatto di essere un applicazione molto leggera e di facile installazione. Tuttavia non è in grado di offrire il supporto di cui le aziende grandi e medie necessitano. A meno che una azienda non disponga di amministratori esperti in grado di realizzare un buon sistema antintrusione autonomamente e senza il bisogno di supporto esterno, Snort pur offrendo questa possibilità potrebbe non risultare conveniente. Più interessante potrebbe essere l integrazione nella rete aziendale di Snort con altri sistemi IDS, che danno il supporto, in modo da poter controllare, ad esempio, il corretto comportamento dei sistemi IDS commerciali installati sulla rete. 72

79 CAPITOLO 5 MCAFEE INTRUSHIELD Intrushield è un sistema IDS di tipo Network-based che combina applicazioni di network sensor e management software per la rilevazione di attacchi conosciuti (usando Signature Detection), attacchi sconosciuti (usando Anomaly Detection), attacchi DoS e Distribuited DoS. Intrushield offre: - Completezza. Intrushield è in grado di riconoscere attacchi conosciuti, sconosciuti, Dos e DDoS. La combinazione di queste tecniche rende il sistema IDS un mezzo potente e accurato per la rilevazione degli attacchi. - Prevenzione. Il sistema è capace di prevenire i possibili attacchi prima che raggiungano la rete aziendale. In questo modo Intrushield oltre ad offrire intrusion detection può realizzare anche intrusion prevention. - IDS Virtuale. Intrushield permette di attivare su di un unico sensore diversi sensori virtuali. In questo modo è possibile definire diverse policy e quindi differenti modalità di comportamento per ogni sensore virtuale. Grazie a questa caratteristica ed alla capacità di assorbimento dei sensori (multi-gigabit) è possibile gestire il sistema usando un numero di sensori reali minore di quello necessario per altri IDS commerciali. Intrushield sensor analizza e convalida il traffico sulla base degli elementi e di specifici campi del protocollo di comunicazione, mantenendo pieno controllo dello stato delle applicazioni e del flusso di dati. Il sensore gestisce il riassemblaggio della frammentazione IP e dello stream TCP e fornisce meccanismi di controllo per tutti i livelli applicativi superiori. Intrushield è in grado di controllare i contenuti di un pacchetto dal livello due al sette della pila ISO/OSI e di interpretare la semantica del protocollo fino al livello applicativo. Il pacchetto catturato viene analizzato in base ai campi specifici del protocollo che utilizza. Dopo questa fase Intrushield passa il pacchetto al modulo appropriato per la 73

80 McAfee IntruShield ricerca di traffico sospetto (Dos, Signature e Anomaly detection). Se il modulo rileva qualcosa, passa la segnalazione di allarme e i dati corrispondenti al management process caricato sul sensore stesso. Il management process può generare delle risposte automatiche, basate su policy, e spedire la segnalazione di allarme alla piattaforma centrale di gestione. 5.1 COMPONENTI DI INTRUSHIELD I componenti principali di Intrushield sono: - Intrushield Sensor; - Intrushield Security Management System; - IntruVert Update Server INTRUSHIELD SENSOR I sensori sono dispositivi appositamente progettati per gestire grandi quantità di traffico anche su reti molto veloci, in grado di rilevare con accuratezza traffico sospetto entrando in profondità nei livelli di protocollo, mantenendo un elevata flessibilità e scalabilità nella gestione della architettura di rete. I sensori monitorizzano in tempo reale la rete alla ricerca di traffico sospetto e rispondono in modo automatico sulla base della configurazione definita dall amministratore di rete. Una volta che i sensori sono collegati alla rete ed attivati, la loro gestione e configurazione è affidata al manager server (descritto nella sezione security management system). La funzione primaria del sensore è di analizzare il traffico su un segmento di rete definito e di rispondere quando un attacco viene rilevato. Il sensore esamina l header e la porzione di dati di ogni pacchetto, alla ricerca di prove che identifichino il traffico come sospetto. Il pacchetto viene esaminato sulla base di policy o regole definite dall utente, che determinano il tipo di attacco da cercare e con quali contromisure reagire. Per ogni attacco il sensore genera un allarme che descrive l evento, e risponde in accordo con le policy configurate. 74

81 McAfee IntruShield Il sensore può rispondere in vari modi ad un attacco, includendo la generazione di allarmi e il log dei pacchetti, resettando la connessione TCP, bloccando il traffico, riconfigurando il firewall o scartando il traffico dannoso prima che raggiunga l obiettivo. IntruVert offre due tipi di sensori, differenti per capacità di banda e tipologia di sviluppo. Questi sensori sono Intrushield 2600 (per reti lan di medie e grandi dimensioni) e Intrushield 4000 (solo per reti Gigabit) INTRUSHIELD SECURITY MANAGEMENT SYSTEM Intrushield security management system è la combinazione di risorse hardware e software necessarie alla gestione ed alla configurazione del sistema antintrusione Intrushield. Il cuore del sistema è l Intrushield Manager composto dai seguenti componenti: - Una macchina con determinate caratteristiche hardware e software (Windows 2000 Server), su cui girerà il software di gestione del sistema IDS. - Il Manager Software, basato su un interfaccia grafica web per la gestione e la configurazione del sistema da parte dell utente. Gli utenti possono connettersi al manager utilizzando un comune browser come Internet Explorer (5.5 o superiore). Il manager è composto dai seguenti componenti: network console (consente di visualizzare lo stato del sistema, tutti i componenti installati e di operare modifiche di configurazione in base ai permessi che l utente possiede); tool di configurazione (provvedono alla configurazione di tutte le opzioni disponibili, come la gestione dei sensori, degli utenti, delle policy, delle regole o delle signature create dall utente, delle risposte, dei report, ecc.); alert viewer (visualizza gli allarmi e le caratteristiche dei pacchetti sospetti); report (genera in modo automatico o manuale report degli allarmi riscontrati o della configurazione del sistema, permettendone successivamente l archiviazione su disco o l inoltro via ); incident generator (permette di definire un tipo di incidente in base alla correlazione di certi attacchi). - Un database relazionale come MySQL per mantenere le informazioni sulla configurazione del sistema e i dati relativi agli allarmi. 75

82 McAfee IntruShield INTRUVERT UPDATE SERVER Per garantire efficienza IntruVert mette a disposizione del suo prodotto una serie di aggiornamenti, con frequenza quasi giornaliera, contenenti nuove signature, nuove policy e anche nuove release del software di gestione. L aggiornamento può essere fatto in modo automatico o manuale, e il collegamento con il server di IntruVert può essere diretto oppure tramite proxy. 5.2 FLESSIBILITÀ DI INTRUSHIELD Intrushield offre la possibilità, ad un amministratore esperto, di creare o modificare delle proprie policy e di definire signature personalizzate. Nell interfaccia grafica del manager si possono trovare due sezioni che consentono queste operazioni di customizzazione. La prima è il policy editor, grazie alla quale l utente può creare delle policy in base alle proprie esigenze. Il policy editor contiene al suo interno un editor per le rules, in questo modo si possono inserire nuove rules che andranno poi a caratterizzare la policy, scendendo così nel dettaglio della policy. La seconda sezione riguarda la user-defined signature, altro editor di customizzazione, grazie al quale è possibile definire nuove signature per la ricerca e cattura del traffico sospetto. L insieme di più signature potrà poi essere utilizzato per comporre nuove regole POLICY EDITOR Il policy editor è un tool per la gestione delle policy, grazie al quale è possibile definire da quali attacchi ci si vuole proteggere, il tipo di risposta all attacco, la severità dell impatto sulla rete e il tipo di notifica dell allarme. Si possono aggiungere nuove policy, modificarle e/o cancellarle. Il pop-up Java del policy editor è diviso in quattro sezioni principali (fig. 26): - Policy. Definisce il nome assegnato alla nuova policy e se debba essere visibile anche ai domini sottostanti al dominio dell utente che sta effettuando l operazione; - Exploit. Consente di specificare gli attacchi da cui si vuole essere protetti, le regole per riscontrarli, le signature per la ricerca nel campo dati del pacchetto e 76

83 McAfee IntruShield la direzione del traffico. E possibile definire diverse regole per entrambe le direzioni del traffico (entrante o uscente dalla rete interna). Gli attacchi disponibili, associati alle rules, sono ordinati per protocollo. Si possono creare delle proprie regole, avendo così la possibilità di modificare parametri come la categoria della regola (policy violation, exploit, attacco DoS), il protocollo da controllare, il sistema operativo soggetto all attacco, l applicazione software vulnerabile, il livello di severità, la probabilità di riscontro e il tipo di attacco vero e proprio (selezionabile tramite una lista fornita da Intrushield). Ogni categoria di attacco contiene una serie di vulnerabilità note, per quel protocollo di rete, che si possono attivare o disattivare, modificarne la severità, definire il tipo di risposta, impostare filtri per i falsi positivi e configurare il tipo di notifica all utente. La lista contenente gli attacchi noti, oltre a poter essere aggiornata tramite update dal server IntruVert, può essere incrementata da parte dell utente inserendo nuove signature tramite l editor user-defined signauture. - DoS. Permette di definire quali attacchi DoS associare alla policy. Si divide in learning mode e threshold mode. Il primo, disabilitato di default, consente ad Intrushield di imparare (per un tempo, circa, di due giorni), facendo delle statistiche sulla base della mole di traffico transitante sulla rete, su quali possano essere situazioni di attacco DoS reali, riuscendo a discriminare il traffico elevato da un attacco, grazie alla capacità di adattamento alle caratteristiche della rete. Il secondo, sistema più classico, si basa sul flood di traffico con caratteristiche tipiche degli attacchi DoS (TCP SYN, IP fragments, ecc.). La modalità threshold consente anche di definire un intervallo di tempo nel quale esaminare l eventualità dell attacco. - Reconnaissance. Consente di associare alla policy il controllo di tool riconosciuti come port scan e probes. E possibile impostare il livello di severità, l intervallo di tempo da prendere in considerazione durante il controllo, il tipo di risposta all attacco e il tipo di notifica dell allarme. Le policy possono essere create da zero oppure modificando policy già esistenti, fornite insieme al programma, semplicemente clonandole. 77

84 McAfee IntruShield Figura 26 Policy editor (sezione Exploit) Tra le impostazioni configurabili si trovano parametri interessanti come la cattura dei primi 256 bytes o dell intero pacchetto sospetto (fig. 27), grazie alla quale l amministratore può fare analisi successive per scoprire nuovi particolari sull attacco. Una volta definita la policy, basta applicare i cambiamenti per far si che le nuove impostazioni vengano caricate sul sensore associato al segmento di rete da monitorare. Figura 27 Opzioni di logging disponibili per la cattura dei pacchetti 78

85 McAfee IntruShield USER-DEFINED SIGNATURE Questa sezione consente di creare delle proprie signature per definire nuovi tipi di attacco da cui proteggersi (fig. 28). Le nuove signature andranno poi caricate nel database del manager, per essere aggiunte all elenco di attacchi già presenti nel programma. La creazione delle signature si basa sulla definizione di regular expressions, in particolare IntruVert utilizza una notazione di tipo BNF-like (Backus-Naur form). Ad esempio il carattere (barra verticale) identifica una sequenza di scelte multiple, mentre l espressione ::= associa i valori definiti a destra ad un simbolo posto alla sua sinistra. Intrushield impone tre restrizioni all utente nella generazione di nuove signature: non è possibile controllare i campi option dei protocolli IP e TCP; si possono testare al massimo 10 campi dell header nei protocolli IP, TCP e UDP; e i campi fragmentation flags, lengths e offsets non sono supportati. Figura 28 Editor per la definizione di nuove signature L editor user-defined signature consente di fare le seguenti operazioni: - New attack. Definisce il nome assegnato al nuovo attacco e il suo impatto sulla rete; - Package/Protocol. Permette di impostare la ricerca dell attacco sulla base del protocollo utilizzato dall hacker o della vulnerabilità a livello applicativo 79

86 McAfee IntruShield sfruttata. A seconda della scelta effettuata bisogna selezionare da una lista, fornita da Intrushield, l applicazione o il protocollo da controllare. - Signature. Permette di inserire la signature vera e propria. E possibile inserire il nome della nuova signature, un riferimento ad un documento per fornire maggiori informazioni sulla vulnerabilità, la probabilità che l attacco avvenga e l architettura del sistema da controllare. Inoltre si può impostare che la signature venga cercata in ogni pacchetto, solo nelle risposte, solo nelle richieste, in tutti i pacchetti contenenti una parte della signature seguiti da pacchetti contenenti l altra. A questo punto si possono inserire una serie di condizioni, che devono essere riscontrate nei pacchetti, le quali possono essere messe in AND o in OR tra loro (fig. 29). Le espressioni nelle condizioni definiscono il tipo di contesto da ricercare nel pacchetto. E possibile scegliere il tipo di comparazione da eseguire (confronto fra stringhe, fra numeri, fra campi dell header, ecc.) e il protocollo di rete. Infine usando le regular expression si definisce il valore da confrontare con il pacchetto (fig. 30). Figura 29 Signature con condizioni multiple Definirsi delle proprie signature non è una cosa semplice, infatti, l uso di questa opzione, è consigliato solo ad utenti veramente esperti. In più è importante sapere come muoversi perché Intrushield, a seconda del tipo di comparazione e del protocollo scelti, mette a disposizione solo i campi dell header conformi alla strada seguita 80

87 McAfee IntruShield precedentemente. Ad esempio i campi dell header del protocollo ICMP non vengono resi disponibili se come metodo di comparazione si sceglie il confronto fixed field (campi fissi di protocollo), per poterli controllare bisogna scegliere il confronto fra valori numerici. Figura 30 Configurazione del tipo di comparazione scelto 5.3 IMPLEMENTAZIONE DI MCAFEE INTRUSHIELD Il cd d installazione di Intrushield contiene tutto il software necessario al funzionamento del programma. Di base viene richiesto solo Windows 2000 server SP2 o superiore e Internet Explorer 5.5 o superiore. L installazione risulta molto semplice, l utente in pochi passi riesce ad installare il software del manager, il database MySQL (è consigliato usare la versione fornita con il cd), e la Java VM. Terminata questa fase è necessario fornire il file contenente la licenza, prima di avviare il programma. Per effettuare le prove Intrushield è stato installato su un PC modello HP Brio con CPU PIII 550 Mhz, 256 Mb di memoria RAM, 20 Gb di hard disk e una scheda di rete intel PRO/100+. La configurazione software comprende: Windows 2000 Server SP4; Java 2 SE v.1.4.1; MySQL; Intrushield Security Management System. Come sensore è stato utilizzato il modello Intrushield

88 McAfee IntruShield 5.4 PROVA EFFETTUATA Avendo avuto a disposizione il prodotto della NAI solo per pochi giorni non è stato possibile effettuare una prova completa. In più, poiché Intrushield richiede maggiori risorse hardware di quelle che erano disponibili, l interfaccia grafica (realizzata in Java) risultava estremamente pesante da caricare e lenta nel rispondere ai comandi. Per cui i risultati esposti in questa sezione sono da ritenere puramente teorici e non confutabili da prove tangibili. La fondatezza di questa prova si basa esclusivamente sullo studio del manuale d uso fornito insieme a Intrushield e su alcuni punti del programma che si è riusciti ad esplorare. La prova consisteva nel verificare se le regole realizzate per Snort (cap ) potevano essere implementate anche con Intrushield. In base alle caratteristiche dell editor User-defined signature sembrerebbe di si. Tuttavia si possono escludere a priori le seguenti rules: alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ftp transfer Sourcecod to client"; content:"sourcecod"; nocase; dsize:<180; classtype:test;) alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"client FTP looking for Sourcecod"; content:"sourcecod"; dsize:>181; nocase; classtype:test;) alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ftp bad file stored"; content:" "; offset:57; depth:3; classtype:test;) alert tcp $EXTERNAL_NET any -> $HOME_NET 20:21 (msg:"session FTP"; dsize:>2; session:printable; classtype:test;) alert tcp $EXTERNAL_NET!139 -> $HOME_NET 1024: (msg:"ftp PUT offset file with distance and within parameters";content:"q"; content:"i"; nocase; distance:1; within:3; classtype:test;) 82

89 McAfee IntruShield alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"ip bad More Fragment"; fragbits:m; dsize:<1479; classtype:test;) alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"fragment offset IP set"; fragoffset:>1; fragbits:!d; classtype:test;) alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"reply to probable Traceroute"; itype:3; icode:3; content:" 01 "; offset:12; depth:1; classtype:test;) L esclusione è dovuta ai campi offset, depth, dsize, distance e within. I primi tre non sono proprio replicabili in Intrushield, mentre i successivi due sono stati esclusi perché Intrushield non offre un sistema di ricerca basato sulla posizione precisa dei byte all interno del payload del pacchetto. Per quanto riguarda le restanti regole, è possibile rappresentarle settando in modo appropriato le signature. Infatti Intrushield consente di discriminare tra traffico entrante e uscente, di scegliere il protocollo di rete e di ricercare stringhe sospette all interno dei pacchetti. L unica difficoltà sta nel fatto che una regola definita per Snort deve essere completamente rivoluzionata per essere adattata a Intrushield. Per di più, quello che per uno si può descrivere in una riga di testo, per l altro richiede diversi passaggi piuttosto impegnativi e lunghi CONCLUSIONE Intrushield, potenzialmente, sembra offrire un buon livello di flessibilità nella customizzazione delle regole per il riscontro degli attacchi. Gli strumenti messi a disposizione dell utente consentono, effettivamente, di apportare molte modifiche alle policy fornite dal sistema. Tuttavia, bisogna far notare anche che l uso di questi componenti non è affatto semplice. Anche un amministratore esperto potrebbe avere problemi nell inserire nuove regole, in quanto alcuni aspetti dell editor user-defined signature non sono ben definiti neanche sul manuale di Intrushield (vedi fra tutti, l impossibilità di conoscere a priori, a seconda del metodo di comparazione scelto, quali siano tutte le opzioni settabili nei passi successivi). 83

90 McAfee IntruShield Un altra importante mancanza riscontrata in Intrushield è l incompatibilità, del programma, con le rules di Snort. Sarebbe interessante se il sistema, vista la forza dimostrata da Snort, fosse in grado di importare queste regole. Purtroppo, non è possibile e non è neanche previsto dal software della NAI. L utente interessato ad usare le rules di Snort dovrebbe prima imparare un altro linguaggio formale (il BNF-Like), e poi tentare di adattare tutte le regole di cui necessità, definendole una ad una, nel formato compreso da Intrushield. In definitiva risulta possibile creare nuove signature per comporre nuove regole, ma ogni singola signature richiede molto tempo, imponendo così, un lavoro lento e difficile. 84

91 CAPITOLO 6 ISS REALSECURE 7.0 Il commercio elettronico, le connessioni remote ed altre esigenze dell odierna economia online esigono che i networks siano aperti ed accessibili e che la sicurezza delle reti sia il più possibile trasparente ai partners, vendors, clienti ed utenti interni. Per soddisfare questa necessità, ISS offre Realsecure, la prima piattaforma industriale completamente integrata per l identificazione di intrusioni su host e network. Combinando la ricerca di intrusioni su base host e su base network in un unica piattaforma, Realsecure fornisce una soluzione completa. Realsecure utilizza un approccio standard-based, confrontando il traffico di rete e le log entries dell host contro i metodi d attacco più conosciuti. Eventi sospetti o attività contrarie alle policy di sicurezza attivano gli allarmi presso gli amministratori e altri responsi configurabili. Realsecure è progettato per diminuire il carico di lavoro dell amministratore della sicurezza. Tutti i componenti di Realsecure possono essere configurati da una console centrale. I parametri di monitoraggio di Realsecure si adattano con facilità alle differenti situazioni di network; in aggiunta, Realsecure si integra semplicemente con le principali applicazioni per la gestione dei networks e delle applicazioni. Realsecure è in grado di riconoscere i vari livelli del protocollo TCP/IP e di applicazione quale HTTP, FTP, SMTP, SNMP, RPC, SMB, NetBIOS così come molti protocolli di comunicazione utilizzati da virus e Trojan. ISS Realsecure concentra la propria analisi dei protocolli in base al contesto ed impiega tecniche di pattern matching ove necessario per identificare efficacemente i pacchetti appartenenti ad attacchi. In più, ISS Realsecure è in grado di eseguire la deframmentazione completa dei pacchetti IP frammentati, così come la corretta interpretazione di sessioni TCP e HTTP splittate, mantenendo traccia di 500'000 connessioni simultanee, oltre ad essere in gran parte immune alle tecniche di evasione quale la polimorphic shell code, mutazioni, codifica URL Unicode, sovrapposizione dei pacchetti e frammentazione dei record RPC. 85

92 ISS Realsecure 7.0 La logica di correlazione degli eventi contribuisce a ridurre il numero totale di eventi unici che il sensore genera unendo logicamente molteplici eventi simili in un singolo allarme. Oltre all utilizzo del motore di analisi di protocollo, Realsecure Sensor ha la capacità di interpretare regole scritte usando un sottoinsieme della sintassi offerta da Snort, attraverso un apposito modulo chiamato Trons. Lo scopo di questo modulo è fornire la possibilità agli utenti di scrivere signature proprie utilizzando un linguaggio relativamente semplice di definizione di regole, che è universalmente noto nell'industria di sicurezza. Trons supporta una parte delle regole attualmente disponibili con Snort ed è fornito di un programma a linea di comando chiamato Tronstester che può essere usato per eseguire la compilazione delle firme e per fornire avvertimenti relativi a eventuali problemi di sintassi. 6.1 COMPONENTI DI REALSECURE 7.0 I componenti principali di Realsecure 7.0 sono: RealSecure Engine RealSecure Engine funziona su workstations dedicate per fornire indagini e responsi sull identificazione delle intrusioni nel network. Ciascun RealSecure Engine controlla il traffico che viaggia su uno specifico segmento di rete per ricercare le "attack signatures", cioè le prove che una tentata intrusione sta avendo luogo. Quando RealSecure rileva attività sospette, è in grado di reagire immediatamente terminando la connessione, inviando o pagine di allerta, registrando la sessione, riconfigurando i firewalls o rispondendo con altre azioni definibili dall utente. Inoltre, RealSecure Engine invia un segnale di allarme a RealSecure Manager o ad una terza console gestionale per la revisione amministrativa, in modo che l utente possa avere un immagine immediata dell evento. RealSecure Agent RealSecure Agent è un complemento host-based di RealSecure Engine. 86

93 ISS Realsecure 7.0 RealSecure Agent analizza gli host logs per riconoscere gli attacchi, determinare il loro eventuale successo e fornire altre informazioni legali. Ciascun RealSecure Agent si installa su una workstation o su un host, esaminando a fondo i logs di quel sistema alla ricerca di indizi circa l utilizzo scorretto del network e di interferenze nella sicurezza. RealSecure Agent reagisce per prevenire ulteriori incursioni terminando i processi dell utente e sospendendo l account dell utente stesso. E inoltre in grado di inviare allarmi, eventi log, s e di eseguire azioni personalizzabili dall utente. RealSecure Manager Tutti i RealSecure Engine e RealSecure Agent sono configurati da RealSecure Manager, a cui forniscono i reports. Il risultato è un prodotto facilmente configurabile ed amministrabile da una singola postazione. Realsecure Manager viene dato come parte integrante di Realsecure Engine o Realsecure Agent ed è anche disponibile come modulo plug-in per un ampia varietà di ambienti gestionali di network e di sistema. Deployment Manager Il Deployment Manager può essere usato per installare tutti i componenti di SiteProtector a partire da un calcolatore centralizzato e posizionato ovunque sulla rete. Una volta che il Deployment Manager è stato installato su un pc, il CD non è più richiesto per installare SiteProtector o qualunque altro componente di un sistema RealSecure. Il Deployment Manager può essere usato per eseguire una installazione base o custom di SiteProtector oltre che per installare altri componenti. Application Server L Application Server permette la comunicazione tra la console di SiteProtector e il RealSecure Site Database Sensor Controller. Il Sensor Controller trasmette i comandi ai sensori, come ad esempio il comando di avvio o di sospensione della raccolta degli eventi. 87

94 ISS Realsecure 7.0 Il Sensor Controller e l Application Server sono installati sullo stesso calcolatore centrale. RealSecure Database RealSecure Database memorizza i dati che l event collector raccoglie dai sensori. Il sistema è basato sul server Microsoft SQL per le installazioni su larga scala o su MSDE per le installazioni in ambienti di rete limitati. Event Collector L Event Collector estrae i dati dai sensori e li memorizza nella base di dati. In genere viene installato un solo Event Collector per una installazione di SiteProtector, ma fino a cinque Event Collector possono essere installati nel caso fossero richieste prestazioni elevate. Security Fusion Il modulo Security Fusion è un modulo opzionale che correla i dati dalle sorgenti multiple, compreso i sensori di rete, i sensori dei server e l'applicazione Internet Scanner. Questa correlazione automatizzata intensifica gli attacchi critici e riduce i falsi positivi. Site Protector Console Il Site Protector Console è l'interfaccia utente grafica (GUI) basata su Java per la gestione di SiteProtector (fig. 31). Attraverso la Console, l'amministratore può effettuare molteplici attività, come il controllo degli eventi e programmazione delle scansioni. Le attività specifiche che possono essere eseguite utilizzando SiteProtector Console dipendono dal ruolo assegnato all'amministratore. 6.2 FLESSIBILITÀ DI REALSECURE 7.0 Realsecure 7.0 si propone come un strumento potente e flessibile per l amministratore che desidera personalizzare il proprio sistema antintrusione. Oltre ad offrire la possibilità di creare nuove policy, in questa versione, è presente un nuovo componente, Trons, che consente di sfruttare alcune potenzialità di Snort. 88

95 ISS Realsecure 7.0 Verrà dedicato poco spazio alla customizzazione delle policy, poiché questa sezione non consente grande libertà nella realizzazione di proprie regole per il controllo del traffico. Figura 31 SiteProtector Console DERIVARE LE POLICY Una delle due possibilità di personalizzazione che Realsecure 7.0 offre è la capacità di derivare una policy da quelle predefinite, fornite insieme al prodotto. Derivare una policy significa clonarla, in pratica l utente può scegliere fra le varie possibilità esistenti per cercare la soluzione che più si avvicina alle sue esigenze e poi modificarla per ottenere il miglior risultato. Una volta derivata la policy e possibile assegnarle un nuovo nome e successivamente tramite il policy editor (fig. 32) l utente sarà in grado di modificarne anche il contenuto. Il policy editor permette di modificare i cinque aspetti principali di una policy, che sono: 89

96 ISS Realsecure Security Events; - Connection Events; - User Defined Events; - Packet Filters (permette di filtrare i pacchetti che non devono essere riscontrati); - Event Filters (permette di filtrare gli eventi che non devono essere riscontrati). Figura 32 Policy Editor Security Events Permette di configurare il tipo di eventi che si desidera riscontrare. Si divide in due parti: - Attacks. Contiene tipologie di attacchi, conosciuti, divisi per categorie. Di questi attacchi è possibile modificare la priorità, il tipo di risposta e la porta su cui controllare il traffico. Non è possibile creare nuovi attacchi e non è possibile vedere nel particolare la struttura di quelli predefiniti. Gli attacchi, di cui è disponibile una lista, possono essere abilitati o disabilitati; 90

97 ISS Realsecure Audits. Contiene un elenco di vulnerabilità conosciute divise per categorie. La personalizzazione segue le stesse regole valide per la sezione attacks. Connection Events Consente di controllare le connessioni entranti e/o uscenti verso determinati indirizzi e porte per i protocolli ICMP, UDP, TCP. E possibile aggiungere o rimuovere nuovi eventi e personalizzare i campi corrispondenti al nome dell evento, la priorità, il tipo di risposta, l indirizzo IP sorgente e destinazione, il protocollo di comunicazione, il numero di porta sorgente e destinazione (per TCP e UDP), il code type (per ICMP) e una breve descrizione dell evento. Di conseguenza questa sezione offre la possibilità di riscontrare gli eventi esclusivamente in base al tipo di traffico senza poter considerare il payload dei singoli pacchetti. User Defined Events Permette di inserire o rimuovere nuove signature definite dall utente. I campi customizzabili sono il nome della signature, la priorità, il tipo di risposta, un context (propone una serie di contesti predefiniti entro i quali si deve trovare la stringa da confrontare), string (stringa da riscontrare nel pacchetto, definibile tramite delle regole di espressione) e una descrizione della signature. Non è possibile aggiungere nuovi context e quelli predefiniti sono molto limitati. Le caratteristiche e le possibilità di customizzazione offerte dalla sezione policy permettono di modificare qualcosa di preesistente e non di creare nuove soluzioni. Personalizzare le policy è sicuramente utile se non si necessita di caricare sul sistema tutte le caratteristiche di una policy predefinita. Tuttavia, per poter tenere sotto controllo aspetti come, ad esempio, un certo tipo di traffico generato dalla propria rete aziendale è necessario poter usufruire di maggiori possibilità di personalizzazione. Per permettere alle aziende di creare un sistema antintrusione su misura ISS ha integrato Trons in Realsecure

98 ISS Realsecure IL MODULO TRONS Il modulo Trons implementato nella versione 7.0 di ISS Realsecure permette di acquisire le rules di Snort o di crearne delle proprie personalizzate (si noti che Trons è Snort al contrario). Questo componente si propone come un mezzo potente per l amministratore che desidera disporre in modo autonomo della segnalazione e della catalogazione degli eventi di rete. Grazie a Trons il sistema della ISS ha una maggiore flessibilità e una maggiore granularità nel gestire le segnalazioni. Tuttavia, ISS raccomanda di non usare questo sistema per ottenere elevate prestazioni e avere pochi falsi positivi, ma di utilizzare le policy già implementate in Realsecure 7.0. Per questo motivo giustificano l inserimento solo di un sottoinsieme delle possibili opzioni di Snort, in modo da ridurre sensibilmente i falsi positivi che troppi parametri avrebbero potuto generare. Il riassemblaggio di sessioni TCP splittate non è supportato da Trons e non è possibile utilizzare i collegamenti ed i preprocessori standard di Snort. Naturalmente per poter utilizzare questo strumento è raccomandabile possedere una buona conoscenza della sintassi definita per le rules di Snort ATTIVARE TRONS Il modulo Trons è disabilitato di default, per poterlo utilizzare è necessario attivarlo. Trons deve essere abilitato su ogni sensore che necessita l integrazione con le rules di Snort. Per ongi Sensor bisogna, quindi, accedere alle proprietà del sensore ed entrare nella sezione advanced tab (fig. 33). In questa sezione vengono presentati i parametri del sensore con una breve descrizione. I parametri che permettono di configurare Trons sono: - Trons.enabled. Permette di abilitare o disabilitare TRONS, è un valore boolean settato a false di default. Per attivare TRONS basta semplicemente settarlo a true; - Trons.filename. Permette di specificare il nome assegnato al file contenente le rules e il path che ne indica la posizione sul sensor. E importante ricordare che il file deve trovarsi sul sensore. Ad esempio, nel caso del network sensor con 92

99 ISS Realsecure 7.0 sistema operativo linux la stringa da inserire potrebbe essere /iss/network_sensor/trons.rules; - Trons.eventpriority. Consente di definire il livello di priorità per gli eventi generati. I valori possibili sono: 1=High, 2=Medium e 3=Low. Si noti che sulla console manager tutte le signature integrate con TRONS se riscontrate genereranno eventi con la priorità impostata in questo campo. Sarà poi possibile, visualizzando il dettaglio dell evento, conoscere la priorità specifica assegnata durante l implementazione della rules, a quella signature; - Trons.responses. Specifica il tipo di risposta da assegnare agli eventi (non è possibile discriminare i singoli eventi, tutte le rules saranno associate allo stesso tipo di risposta). Di default le risposte attive sono display:default, log:logwithoutraw. E possibile comunque definire altri tipi, l importante è rispettare la forma response_type:response_name. I valori devono essere separati tra di loro dalla virgola. Figura 33 Parametri avanzati delle proprietà del sensore Configurando questi parametri e applicando le modifiche sui sensori, il modulo Trons verrà attivato. 93

100 ISS Realsecure 7.0 Per evitare messaggi di errore, è importante, che il file contenente le rules sia già presente sul sensore. Se tutti i passaggi sono andati a buon fine e le rules sono corrette, Realsecure 7.0 sarà in grado, grazie a Trons, di riscontrare gli eventi generati dalle nuove impostazioni SINTASSI La buona conoscenza della sintassi e dei parametri consentiti da Trons è essenziale per ottenere il massimo risultato da questo strumento. Si consiglia, per chi volesse utilizzare questo strumento, di imparare molto bene la sintassi e le opzioni offerte da Snort, infatti poiché Trons usa un sottoinsieme delle possibilità offerte da Snort, conoscere bene il primo equivale ad avere tutte le capacità necessarie ad usare il secondo. Come già detto è necessario creare un file (nomefile.rules) dove inserire le rules. In questo file è possibile anche specificare le variabili (già note nella sintassi di Snort) che consentono di impostare valori come il range IP della propria home net o le porte http consentite, ecc. La sintassi per questo parametro è var:< nome> < valore>. Un altro parametro utile, che si può inserire nel file è include. Infatti poiché a Trons si può passare un unico file, il solo modo di implementare le tante rules fornite da Snort è inserirle tutte dentro questo file. Invece, grazie a questo parametro è possibile definire un include per ogni file di rules che si vuole associare a Trons. Risulta subito evidente che è più semplice gestire 40 file che 1700 signature. Per sfruttare questo parametro bisogna inserire una riga per ogni file con la seguente sintassi: include \nome dir\otherfile.rules. Anche in questo caso i file devono trovarsi sul sensore. Di seguito viene riportato l elenco delle opzioni consentite dalla sintassi di Trons. - Azioni. Trons consente un solo tipo d azione. Mentre in Snort le azioni possibili sono alert, log, pass, activate e dynamic, qui è possibile definire solo alert. Questa restrizione non è un problema, in quanto le altre azioni non sono generalmente usate. - Protocolli. Tutti i protocolli consentiti da Snort, sono anche consetiti da Trons. Quindi è possibile specificare rules per ICMP, IP, TCP e UDP. 94

101 ISS Realsecure Indirizzi IP. Nelle rules è necessario specificare gli indirizzi IP del mittente e del destinatario. Le forme possibili sono: - Formato numerico standard per indirizzi IP (dotted quad), es ; - Parola chiave any per identificare qualsiasi indirizzo IP; - Range di indirizzi, combinando indirizzo IP con una netmask, es /24; - Lista di indirizzi separati da virgola, es /24, /24; - Non è consentito l uso dell operatore di negazione! davanti all indirizzo (utile per escludere un indirizzo o un range di indirizzi dal riscontro dell evento). - Numero di porta. Le porte di comunicazione sorgente e destinazione seguono la stessa sintassi definita per Snort. - Operatori di direzione. Usando questi operatori è possibile definire la direzione del traffico che si vuole prendere in considerazione. Gli operatori sono ->, <- e <>. - Opzioni delle regole. Le opzioni permettono di specificare in base a quali valori la rule deve scattare. Le opzioni consentite in Trons sono un sottoinsieme di quelle possibili con Snort, seguono la stessa sintassi e le stesse funzioni. Le opzioni consentite da Trons sono: ack, classtype, content (al massimo tre per regola), depth, dsize, flags, fragbits, icmp_id, icmp_seq, icode, id, ipopts, ip_proto, itype, msg, nocase, offset, priority, reference, rev, rpc, sameip, seq, sid, tos, ttl e uricontent. Questi parametri sono descritti in modo dettagliato nel capitolo (Snort - Le regole) ESEMPIO DI FILE PER TRONS Trons.rules # questo esempio mostra l uso della sintassi per i file di rules 95

102 ISS Realsecure 7.0 include /iss/myrule/myrule.rules var home_net /24 var ftp_port 20,21 alert icmp any any -> $home_net any (msg: large ICMP packet ; dsize:>800; sid:1;) alert ip any any -> $home_net any (msg: lsrr opt packet ; ipopts:lsrr; sid:2;) RISCONTRO DI UN EVENTO Quando una regola viene riscontrata Trons genera un evento che segnala sulla console del manager. A video viene visualizzato solo il tipo di evento e un insieme di informazioni su di esso, il pacchetto originale che ha generato l alert non viene incluso. Non includendo il pacchetto Trons, a differenza di Snort, non consente di accertare la veridicità dell allarme. Infatti solo grazie al pacchetto è possibile sapere con certezza se si tratta di un attacco o di un falso positivo. Generalmente una signature ben fatta crea pochi falsi positivi o forse nessuno, ma quei pochi che genera non saranno, in questo caso, discriminabili dai veri attacchi. 6.4 IMPLEMENTAZIONE DI REALSECURE 7.0 Realsecure 7.0 viene fornito da ISS tramite un cd contenente tutto il software necessario all installazione ( SiteProtector, Security Fusion Module, Workgroup Manager, Icecap Manager, SafeSuite Decision, SQL Server 2000 Desktop Engine ) e tutta la documentazione in formato PDF, più la documentazione online fornita dal sito Per installare Realsecure viene richiesta la presenza del sistema operativo Window 2000 Server con Service Pack 3 o superiore, Internet Explorer 6 o superiore, MSDE 2000 (fornito con il cd d installazione) o SQL Server 2000 SP2 o superiore, Microsoft Data Access Component 2.7 o superiore e Java 2 SE v La configurazione usata per le prove comprende: - Sistema operativo Window 2000 Server SP4; 96

103 ISS Realsecure Java 2 SE v1.4.1; - MSDE 2000; - Realsecure Siteprotector installazione base (Application Server, Console, Desktop Controller, Event Collector, Site Database). Il software è stato installato su un PC modello HP Brio con CPU PIII 550 Mhz, 256 Mb di memoria RAM, 20 Gb di hard disk e una scheda di rete Intel PRO/100+. La parte di Network Sensor è stata installata su una sonda modello Provent A201 dedicata solo alla cattura del traffico sospetto. 6.5 PROVA EFFETTUATA Poiché, come descritto in precedenza, la derivazione delle policy non permette di creare regole in grado di rilevare gli attacchi creati per Snort, si è deciso di testare solo la parte riguardante il modulo Trons. Dopo aver settato tutti i parametri necessari ad attivare Trons, la prova è stata suddivisa in due fasi: nella prima si è testato il modulo inserendo le rules create per Snort; nella seconda si è controllato quale fosse il grado di compatibilità del prodotto della ISS con le attuali rules disponibili per Snort PRIMA FASE Lo scopo di questa fase è quello di verificare se Realsecure offre la possibilità ad un utente di poter creare delle rules ad-hoc per i propri sistemi. La prova è stata effettuata pensando ad un amministratore di sistema che ha bisogno di integrare in quelle che sono già le policy offerte da Realsecure una componente di rilevamento e discriminazione del traffico di rete personalizzata. Per fare ciò sono state create rules molto semplici capaci di riscontrare eventi di cui si avesse il pieno controllo. La scelta di sviluppare rules semplici, spesso basate sul riscontro di un solo paramettro per volta, è stata dettata dalla necessità di poter controllare meglio l affidabilità di Trons e la sua risposta all evento. Scrivendo delle rules di cui si conosceva bene il comportamento e testandole con Snort, se si fossero ottenuti gli stessi risultati con Trons, sarebbe stato possibile affermare con 97

104 ISS Realsecure 7.0 certezza che il sistema della ISS offre effettivamente la possibilità di gestire regole personalizzate RISULTATI OTTENUTI NELLA PRIMA FASE Basandosi sulle regole di Snort, sia come sintassi sia come opzioni, sono state scritte 20 rules (vedere cap. Snort 4.4.1). Per poterle passare ha Trons è stato creato un file, chiamato test.rules, nel quale sono state specificate le variabili riguardanti la Home Net e il mondo esterno, seguite dall elenco delle rules. Infine il file è stato salvato sulla sonda dove era installato il network sensor. Attivando Trons da SiteProtector Console sono stati riscontrati a video una serie di errori. In effetti alcune delle rules contenevano parametri che Trons non è in grado di gestire. In realtà ci si aspettava questa risposta, perché nelle specifiche esiste un elenco di opzioni consentite (vedere par Sintassi). L esperimento è stato fatto per vedere la reazione del modulo ad una situazione di errore. Si è riscontrato che nel caso di file sintatticamente errati il modulo non carica il file e segnala all utente, in modo molto preciso, il motivo e la posizione dell errore nel file. Dopo aver avuto conferma del comportamento di Trons in caso di errore è stato modificato il file eliminando le rules non corrette. Con il nuovo file non è stato segnalato nessun errore e la risposta agli attacchi è andata sempre a buon fine (fig. 34). Trons ha permesso a Realsecure 7.0 di rilevare tutti gli eventi e di farlo esattamente come Snort o quasi, infatti l unico difetto riscontrato è l impossibilità di ottenere l intero o anche solo parte del pacchetto catturato. Difetto abbastanza rilevante, poiché le informazioni sull attacco fornite dal programma contengono pochi dettagli (fig. 35). Le rules non accettate da Trons sono: 1- alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg: Sequence 13 and Window 17 to port 135 ; seq:13; window:17; classtype:test;) In questo caso il parametro non supportato è window. Risulta subito evidente che il 98

105 ISS Realsecure 7.0 riscontro di questo evento, eliminando l opzione window, è possibile, ma genera un gran numero di falsi positivi. Questo problema si ritrova anche sulle rules di Snort che fanno, in diversi casi, uso di questo parametro; Figura 34 Segnalazione di alcuni attacchi rilevati 2- alert tcp $EXTERNAL_NET any -> $HOME_NET 20:21 (msg: Session FTP ; session: printable; dsize:>2; classtype:test;) Il problema è session, questo parametro permette di catturare il contenuto di una sessione (FTP in questo caso). In realtà nelle rules attuali di Snort non è usato, però rimane un opzione molto potente che Snort possiede e Trons no; 3- alert tcp $EXTERNAL_NET any -> $HOME_NET 1024: (msg: FTP put file with distance and within parameters ; content: q ; content: i ; nocase; distance:1; within:3 ;classtype:test;) I parametri non supportati sono distance e within. Anche in questo caso la mancanza di questi parametri genererebbe una grande quantità di falsi positivi, per di più sono parametri attualmente usati nelle rules di Snort; 99

106 ISS Realsecure 7.0 Figura 35 Dettaglio di un attacco 4- alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg: ICMP echo ping request timestamp with tag parameter ; itype:8; tag:host,3,packets; ipopts:ts; classtype:test;) Il problema è tag. Nelle rules di Snort è usato, ma raramente; 5- alert ip $EXTERNAL_NET any -> $HOME_NET any (msg: Fragment offset IP ; fragoffset:>1; fragbits:!d; classtype:test;) Qui il parametro non supportato è fragoffset. Attualmente non è utilizzato nelle rules di Snort. 100