Progettazione di un Intrusion Detection System Laurea Danilo Vizzarro.pdf · 1.2 Obiettivi del...

UNIVERSITA DEGLI STUDI DI MILANO

Facolta di Scienze Matematiche Fisiche e Naturali

Dipartimento di Tecnologie dell’Informazione

Progettazione di un

Intrusion Detection System

RELATORE: Prof. Ernesto Damiani

CORRELATORE: Dott.ssa Barbara Rossi

CORRELATORE: Dott. Claudio Agostino Ardagna

Tesi di Laurea di:

Danilo Vizzarro

Matr. n. 693177

Anno Accademico 2005/2006

PREFAZIONE

Prefazione

La grande diffusione delle reti e di Internet come mezzi di accesso ad informa-zioni e servizi rende sempre più critico, per qualunque azienda, la protezionedelle risorse da accessi non autorizzati e/o attacchi mirati all’acquisizionedi privilegi non garantiti. Questo problema diventa di vitale importanzaper l’economia di un’azienda, dal momento che quest’ultima ha bisogno diamministrare notevoli quantità di informazioni mantenendone segretezza, in-tegrità e disponibilità. Questa esigenza ha portato alla rapida diffusione didispositivi software/hardware, Intrusion Detection System (IDS), utilizza-ti per identificare accessi non autorizzati e per rilevare tutti gli attacchi acomputer e reti informatiche. Tuttavia, la progettazione di un sistema disicurezza non è limitato alla configurazione di un IDS, ma richiede la cono-scenza di diverse tecnologie e componenti, quali router, firewall e VPN, e lacapacità di integrarle e farle interagire per garantire la sicurezza dei dati.Obiettivo del lavoro di tesi è la progettazione e lo sviluppo di un IntrusionDetection System che massimizzi il rapporto qualità/prezzo. A questo scopodopo un’attenta analisi ed uno studio approfondito sono stati selezionati imigliori strumenti Open Source attualmente disponibili in rete. Il progettodi tesi si è sviluppato in più fasi che possono essere riassunte come segue.

• Analisi del design della rete.

– Prima di procedere alla configurazione dell’IDS è necessario de-terminare le mancanze e le necessità di sicurezza della rete, ef-fettuandone un’analisi preliminare e identificandone le risorse daproteggere e le misure di sicurezza già implementate.

2

PREFAZIONE

• Progettazione e implementazione dell’IDS.

– Dopo aver definito lo schema di rete e aver analizzato le risorse adisposizione, si è deciso di utilizzare una macchina con processoredi 1600 Mhz per installare il Sistema Operativo CentOS v4.4 e ilsoftware di intrusion detection Snort v2.6, entrambi scelti per leloro funzionalità.

– Dopo aver proceduto con la loro configurazione, sono state definitedelle regole di intrusion detection ad hoc per le esigenze della rete.

– È stato implementato sulla stessa macchina un server web Apachecon supporto PHP 4 e un database MySQL sul quale sono statiarchiviati e resi accessibili da qualsiasi postazione sulla rete i loggenerati da Snort.

– È stata creata un’interfaccia per la visualizzazione grafica dei logdi Snort. È stato inoltre installato e configurato il software nTopper mostrare tramite interfaccia web le statistiche sui protocollipiù attaccati.

– Per risolvere il problema dell’aggiornamento delle politiche di si-curezza è stato implementato OinkMaster, un sistema automaticoche controlla il rilascio di nuove regole, ed eventualmente ne effet-tua l’aggiornamento automatico, creando il backup delle vecchieregole e archiviando i log dell’operazione.

– È stato, infine, installato un server SSH per permettere l’ammini-strazione dell’IDS da remoto.

• Test dell’IDS.

– La fase di test dell’IDS si è basata sull’adozione di due soft-ware, chiamati Nmap e Metasploit, il primo utilizzato per cer-care i servizi attivi su un sistema e l’altro per scoprirne eventualivulnerabilità.

3

PREFAZIONE

• Ottimizzazione delle regole.

– Dopo l’implementazione dell’IDS è stato necessario procedere conl’ottimizzazione delle regole dell’IDS al fine di risolvere il problemadei falsi positivi riscontrato durante la fase di test.

Il lavoro di tesi lascia spazio a sviluppi futuri e possibili evoluzioni del-l’architettura proposta. Prima fra tutte l’incremento del livello di sicurezzadell’IDS al fine di evitare eventuali compromissioni dell’IDS e dei log. Atale scopo l’IDS potrebbe intercettare passivamente il traffico e archiviare leinformazioni sugli eventi anomali su una macchina remota.Lavori futuri riguardano anche l’implementazione di un Distribuited Intru-sion Detection System, che preveda l’uso di un sensore per ogni segmento direte, configurato per monitorare il traffico ed inviare i log su un unico data-base centrale dove le informazioni verrebbero memorizzate e correttamenteorganizzate.

La tesi è organizzata come segue:Nel Capitolo 1 verrà presentata una panoramica sull’intero lavoro di tesi,rimandando agli altri capitoli per approfondimenti.Nel Capitolo 2 si esamineranno e analizzeranno in dettaglio i diversi tipi diIntrusion Detection Systems e le loro caratteristiche peculiari, mettendone inevidenza gli aspetti positivi e negativi. Si illustreranno, inoltre, le analogiee le differenze con i firewall focalizzando la discussione sui motivi che sugge-riscono l’utilizzo di entrambe le componenti, durante il processo di sicurezzadi un sistema informatico. Saranno discusse le tecniche e gli attacchi più omeno sofisticati che consentono di aggirare un IDS e infine saranno esaminatiil problema dell’analisi dei log e gli aspetti legali da considerare qualora unsistema di intrusion detection venga realmente installato.Nel Capitolo 3 si illustrerà l’architettura di Snort, il più celebre Network-based Intrusion Detection System della comunità OpenSource analizzandonei requisiti hardware richiesti e le modalità di funzionamento. Saranno, dun-

4

PREFAZIONE

que, esaminate la sintassi delle regole di intrusion detection e quella dei loggenerati.Nel Capitolo 4 verrà proposta l’architettura che effettua l’intrusion detection,descrivendo in dettaglio le parti in gioco e argomentando le scelte implemen-tative.Nel Capitolo 5 si presenteranno alcune proposte per ottimizzare l’architetturae renderla più completa.

5

INDICE

Indice

1 Introduzione 10

1.1 Tipologie di IDS . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Obiettivi del lavoro di tesi . . . . . . . . . . . . . . . . . . . . 11

2 Intrusion Detection System 14

2.1 NIDS: Pro e Contro . . . . . . . . . . . . . . . . . . . . . . . . 142.2 NIDS vs Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Tecniche di Analisi dei Pacchetti . . . . . . . . . . . . . . . . . 172.4 Allarmi: Falsi Positivi e Falsi Negativi . . . . . . . . . . . . . 192.5 Risposta dei NIDS . . . . . . . . . . . . . . . . . . . . . . . . 202.6 Posizionamento degli IDS . . . . . . . . . . . . . . . . . . . . 212.7 NIDS: gli Attacchi . . . . . . . . . . . . . . . . . . . . . . . . 232.8 Log Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.9 Aspetti Legali . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.10 Scelta di un NIDS . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Snort 33

3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Requisiti Hardware . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Architettura di Snort . . . . . . . . . . . . . . . . . . . . . . . 343.4 Modalità di Funzionamento . . . . . . . . . . . . . . . . . . . 433.5 Regole di Intrusion Detection . . . . . . . . . . . . . . . . . . 443.6 Analisi dei Log . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7

INDICE

4 Configurazione del NIDS 55

4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Analisi del Sistema . . . . . . . . . . . . . . . . . . . . . . . . 564.3 Setup del NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Setup di CentOS v4.4 . . . . . . . . . . . . . . . . . . . 594.3.2 Setup di Apache e MySQL . . . . . . . . . . . . . . . . 624.3.3 Setup di Snort v2.6 . . . . . . . . . . . . . . . . . . . . 694.3.4 Setup di AdoDB e BASE . . . . . . . . . . . . . . . . . 724.3.5 Setup di nTop . . . . . . . . . . . . . . . . . . . . . . . 774.3.6 Setup di OinkMaster . . . . . . . . . . . . . . . . . . . 79

4.4 Test del NIDS: i Risultati . . . . . . . . . . . . . . . . . . . . 814.4.1 Test con Nmap . . . . . . . . . . . . . . . . . . . . . . 814.4.2 Test con Metasploit . . . . . . . . . . . . . . . . . . . . 88

4.5 Amministrazione Remota via SSH . . . . . . . . . . . . . . . . 974.6 Ottimizzazione di Snort . . . . . . . . . . . . . . . . . . . . . 97

5 Sviluppi Futuri 101

5.1 Incremento del Livello di Sicurezza . . . . . . . . . . . . . . . 1015.2 Realizzazione di un IDS Distribuito . . . . . . . . . . . . . . . 1025.3 Invio degli Allarmi via Email e SMS . . . . . . . . . . . . . . . 103

Ringraziamenti 105

Bibliografia 108

8

CAPITOLO 1. INTRODUZIONE

Capitolo 1

Introduzione

1.1 Tipologie di IDS

Il termine ‘intrusione’ viene usato per descrivere il processo che permette diguadagnare un accesso non autorizzato ad un sistema, ad esempio, si pensial pirata informatico che cerca di ottenere un accesso abusivo ad un server oche diffonde virus per controllare le vittime1 infettate.Per intrusion detection si intende quel processo di scoperta, analisi e re-porting delle attività non autorizzate che possono violare la confidenzialità,l’integrità e la riservatezza dei dati.Esistono diverse tipologie di IDS: gli AIDS (Application-based IDS), gli HIDS(Host-based IDS) e i NIDS (Network-based IDS).

Gli AIDS vengono installati su una singola macchina2 e raccolgono informa-zioni a livello applicativo. Permettono di sapere quale utente ha utilizzatouna particolare applicazione e danno la possibilità di ricostruire le transazio-ni effettuate. Le loro prestazioni non vengono influenzate dalla quantità ditraffico di rete in quanto agiscono su singoli host. Gli AIDS però, richiedendoelevate risorse per la computazione, possono influenzare le prestazioni della

1Si definisce vittima, un sistema o una singola entità attaccata.2Per macchina si intende un computer appartenente ad una rete LAN o ad Internet.

10


macchina sulla quale sono installati.

Gli HIDS hanno una visione limitata all’host che deve essere monitorato dicui controllano il traffico di rete relativo. Si occupano di monitorare l’attivitàdi login, registrando i tentativi falliti e inviando appositi allarmi all’ammini-stratore di rete e inoltre controllano le azioni compiute dall’utente root allaricerca di comportamenti sospetti. Possono richiedere notevoli quantità dispazio per l’archiviazione dei log.

I NIDS sono installati su un apparato dedicato detto sensore e si occupa-no di monitorare l’intero segmento di rete al quale appartengono. I pacchettivengono catturati per mezzo dei packet sniffer3 utilizzando interfacce di retein modalità promisqua e vengono, poi, analizzati alla ricerca di anomalie.Agendo passivamente, sono difficili da rilevare per un attaccante.

Nel lavoro di tesi qui descritto, si è deciso di adottare un Network-BasedIntrusion Detection System, in quanto permette di riconoscere eventuali at-tacchi o violazioni della sicurezza e fornisce dei report via web sullo statodella rete in tempo reale. La classe di NIDS verrà analizzata in dettaglio perpoi focalizzare nel Capitolo 3, la discussione su Snort, il più diffuso sistemadi intrusion detection che è stato utilizzato per questo lavoro di tesi.

1.2 Obiettivi del lavoro di tesi

La tesi si è concentrata sullo sviluppo di un sistema di rilevamento delle intru-sioni realizzato utilizzando un sensore IDS per l’intercettazione e l’analisi deipacchetti, un database MySQL per l’archiviazione degli eventi, un server webe un’interfaccia grafica per monitorare l’attività del sensore IDS. La sceltadegli strumenti utilizzati si è basata sulla valutazione di due requisiti fonda-mentali: il costo e le funzionalità d’uso. L’obiettivo principale è stato quello

3I packet sniffer si occupano di intercettare tutti i pacchetti in transito.

11


di realizzare un sistema semplice da usare anche per un tecnico informaticonon specializzato in sicurezza. A tale scopo si è cercato di creare un’interfac-cia grafica amichevole per permettere una chiara analisi degli eventi generatidal sensore. Infine, altro obiettivo di particolare importanza è stato quello dimantenere intatte le performance della rete in cui il sensore è stato installato.

Mediante la realizzazione di questo Intrusion Detection System, non si èvoluto garantire la totale sicurezza del sistema, ma semplicemente aggiunge-re un tassello fondamentale a quello che è il processo di sicurezza informatica.Infatti, la sola integrazione di un IDS, con un firewall ben configurato, unantivirus aggiornato, e con una valida formazione degli utenti della rete, fina-lizzata a prevenire attacchi di Social Engineering4, permette di raggiungereun discreto livello di sicurezza. Nel lavoro di tesi si è cercato, con l’aiutodi software Open Source come Snort, Nmap e Metasploit, di conoscere i li-miti del sistema creato e di capire come personalizzarlo in base alle proprieesigenze.

4Gli attacchi basati sul Social Engineering, sfruttano l’ingenuità degli utenti per otte-nere informazioni preziose come password di accesso. A questo tipo di attacchi anche ilsistema informatico più sicuro esistente ha effetto scarso.

12

CAPITOLO 2. INTRUSION DETECTION SYSTEM

Capitolo 2

Intrusion Detection System

2.1 NIDS: Pro e Contro

In un sistema informatico che implementa valide politiche di sicurezza, unbuon sistema di incident response e che adotta firewall, antivirus e tutte lepiù moderne misure di sicurezza, i NIDS giocano un ruolo fondamentale, inquanto:

• analizzano il payload dei pacchetti identificando il traffico anomalo;

• danno informazioni sulle scansioni che la rete ha ricevuto;

• permettono di ricevere allarmi real-time;

• evidenziano eventuali errori nella configurazione del sistema;

• evidenziano eventuali vulnerabilità della rete;

• permettono di monitorare il comportamento degli utenti interni allarete;

• segnalano se qualche altra misura di sicurezza, come il firewall o l’an-tivirus, non ha funzionato correttamente;

• rilevano eventuali attacchi provenienti dalla rete interna verso la reteesterna;

14


• rilevano la presenza di eventuali worm che cercano di inviare informa-zioni all’esterno della rete;

• effettuano il monitoraggio delle risorse condivise utilizzate;

• permettono di capire quali misure preventive adottare al fine di evitareeventuali attacchi futuri;

• sono difficili da rilevare in quanto agiscono passivamente.

Le ampie funzionalità descritte hanno portato alcuni amministratori direte a pensare che i NIDS siano in grado di segnalare e risolvere qualsiasi pro-blema di sicurezza. Paradossalmente, pensare che i NIDS garantiscano totalesicurezza date le loro enormi potenzialità, può risultare controproducente inquanto ciò genererebbe un falso senso di sicurezza. Non esiste, infatti, né to-tale sicurezza, né un unico prodotto che permetta di essere totalmente sicuri.

Anche se i NIDS sono sicuramente necessari a garantire un buon livello disicurezza del sistema, da soli non sarebbero sufficienti in quanto:

• non sostituiscono l’esistente staff di sicurezza in quanto necessitano dicostante monitoraggio;

• non individuano attacchi che sfruttano vulnerabilità non ancora resepubbliche detti 0-day;

• agiscono passivamente, ovvero non bloccano il traffico dannoso anchese possono essere configurati per interagire con un firewall;

• quando c’è una grande quantità di traffico da processare, è possibile chevengano persi dei pacchetti, con conseguente fallimento nella rilevazionedi un attacco;

• non possono analizzare informazioni criptate;

• identificano un tentativo d’attacco ma non rilevano se questo è riuscito;

15


• presentano problemi nel gestire attacchi che utilizzano pacchetti fram-mentati;

• incrementando il numero delle firme1, può essere ridotta l’efficenza delNIDS;

• richiedono notevoli risorse in termini di spazio per l’archiviazione deilog;

• non sostituiscono gli altri meccanismi di protezione.

Da quanto detto, emerge che i NIDS sono necessari ad aumentare il con-trollo sull’attività dei sistemi ma non sono sufficienti a garantire la continuitàdel servizio in quanto agiscono passivamente.

2.2 NIDS vs Firewall

Sia i firewall che i NIDS collaborano al fine di prevenire accessi abusivi aduna rete. Entrambi sono fondamentali ma nessuno è sufficiente a garantireda solo un elevato livello di sicurezza. A parte queste analogie, ci sono dellesostanziali differenze tecniche che li caratterizzano.

I firewall hanno funzione di filtraggio dei pacchetti allo scopo di bloccare iltraffico non conforme alle loro politiche. I pacchetti vengono filtrati in baseall’indirizzo IP sorgente o di destinazione e alle corrispettive porte. Difficil-mente i log memorizzati riguardano il traffico permesso2, in quanto ritenutoaffidabile. Se alcuni dei pacchetti dannosi riuscissero a superare il firewall acausa di una configurazione non corretta dello stesso, o di una qualsiasi vul-nerabilità sfruttata, non solo sarebbe possibile portare a termine un attaccocon successo ma, sopratutto, non verrebbe memorizzata alcuna informazione

1Ciascuna firma consiste in una o più stringhe contenenti alcuni parametri, che seriscontrati in un pacchetto devono generare un allarme.

2Il traffico permesso è quello non bloccato dal firewall. Solitamente non viene registratoin quanto l’archiviazione di questo tipo di log richiede risorse notevoli.

16


in merito.Per ovviare a questo problema, entrano in gioco i NIDS, i quali analizzano ilcontenuto di tali pacchetti e segnalano con un allarme ogni attività anomalaindividuata, indipendentemente dal successo o dall’insuccesso della stessa.Inoltre nel caso in cui un attacco provenisse dall’interno della rete, il firewallnon avrebbe utilità alcuna. Esso infatti, pur essendo capace di filtrare il traf-fico verso e dalla rete esterna, non ha alcun potere sul traffico interno allarete.Altra debolezza dei firewall è dovuta al fatto che talvolta gli utenti per in-genuità o impazienza si collegano a Internet creando connessioni non auto-rizzate tramite modem. Questo comportamento mette a rischio l’intera reteperchè il traffico generato, anche in questo caso, non sarà filtrato dal firewall.I NIDS, pertanto, pur monitorando il traffico interno alla rete, non eliminanoi firewall.

2.3 Tecniche di Analisi dei Pacchetti

Vediamo adesso in che modo gli Intrusion Detection System riescono a svol-gere la loro funzione di analizzatori di pacchetti. Impostando la scheda direte del NIDS in modalità promisqua, è possibile ‘ascoltare’ in maniera passi-va tutto il traffico passante sul segmento di rete, senza interferire sullo stesso.L’analisi dei pacchetti può essere effettuata mediante tre tecnologie: la pat-tern matching analysis, la stateful pattern matching analysis e la protocolanalysis.

La Pattern Matching Analysis si occupa di analizzare i contenuti deipacchetti alla ricerca di sequenze di bit prefissate. Questo è un approcciosemplice da implementare ma, allo stesso tempo, abbastanza rigido e pesantedal punto di vista computazionale in quanto ogni pacchetto deve essere con-frontato con centinaia di firme di intrusion detection. Ogni firma è associataa un attacco specifico e istruisce l’IDS sul tipo di pacchetto da considerare

17


anomalo. Ciascuna firma assume una struttura composta da sei componenti<protocollo>, <ip_src>, <porta_src>, <ip_dst>, <porta_dst> e <pay-load_con_exploit> che vengono confrontati con i pacchetti in ingresso e inuscita nel seguente modo: SE il protocollo utilizzato è <protocollo>, l’indi-rizzo IP sorgente è <ip_src>, la porta associata all’indirizzo IP sorgente è<porta_src>, l’indirizzo IP di destinazione è <ip_dst>, la porta associataall’indirizzo IP di destinazione è <porta_dst> e il payload contenuto nelpacchetto è <payload_con_exploit>, ALLORA genera un allarme.

In base a quanto descritto fino ad ora, un allarme viene generato quandosi verifica il pattern matching tra un pacchetto e una regola. Questo significache sarebbe sufficiente dividere la stringa dell’exploit contenuta nel payloadin due frame TCP, per non far rilevare l’attacco. Per risolvere questo proble-ma, è stato introdotta la Stateful Pattern Matching Analysis che è uncriterio più sofisticato di analisi che effettua gli stessi controlli della PatternMatching Analysis tenendo però conto dello stream TCP dei dati.Questo comporta maggiore carico computazionale in quanto capita spessoche ci siano sessioni TCP aperte da monitorare per un lungo periodo.

La Protocol Analysis invece, genera un allarme per ogni violazione del-le specifiche tecniche di un protocollo3. Si supponga, per esempio, che unclient intenda aprire una connessione TCP con un server, a tal fine inviaun pacchetto SYN e si aspetta di ricevere o un pacchetto SYN/ACK o unRST/ACK. Qualsiasi altro pacchetto ricevuto viene considerato una viola-zione e genera un allarme.Questa tecnica minimizza, qualora il protocollo sia ben definito, il numerodi falsi positivi generati se traffico lecito viene riconosciuto come anoma-lo, tuttavia, non è raro trovare delle RFC ambigue che lasciano spazio aglisviluppatori di implementare il protocollo a propria discrezione.

3Le specifiche dei protocolli sono documentate nelle Request For Comment e reperibilisu www.rfc-editor.org[14].

18


2.4 Allarmi: Falsi Positivi e Falsi Negativi

I NIDS lavorano con grandi quantità di dati e per funzionare necessitanodi almeno un algoritmo di generazione degli allarmi. Alcuni amministratoriscelgono di ritenere anomalo tutto il traffico considerato non affidabile (po-litica chiusa), altri invece scelgono di ritenere affidabile tutto il traffico nonconsiderato anomalo (politica aperta).

Nella prima ipotesi il carico computazionale del NIDS sarà rilevante e verràgenerato un alto numero di falsi allarmi detti falsi positivi che possono esseredovuti a:

• pacchetti generati da alcuni dispositivi di rete non riconosciuti dalNIDS;

• violazioni di protocolli non dovute ad attacchi ma ad implementazioniambigue;

• circostanze normali ritenute pericolose dal NIDS, come per esempio lavisualizzazione di una pagina web contenete il codice sorgente di unexploit.

Nella seconda ipotesi il numero di allarmi sarà notevolmente minore, ma sicorre il rischio di non identificare il traffico anomalo che non trova alcunacorrispondenza con le regole impostate, generando falsi negativi che sono piùdifficili da rilevare e possono essere dovuti a:

• configurazioni non appropriate della rete;

• quantità di traffico elevata a tal punto da non essere supportata dalNIDS;

• traffico cifrato;

• firme errate o troppo generiche;

19


• attacchi 0-day dei quali non è stata ancora rilasciata la corrispettivafirma.

Il numero di falsi negativi può essere limitato solo con una costante manu-tenzione del NIDS e con un frequente aggiornamento delle firme.

Per trovare il giusto equilibrio tra falsi positivi e falsi negativi, è opportunoanalizzare approfonditamente la topologia della rete ed eliminare la causa chegenera falsi allarmi. Procedere eliminando radicalmente la regola corrispon-dente ad un attacco, potrebbe essere una scelta troppo ingenua e superficialeche tal volta può comportare il rischio di non rilevare attacchi reali.

2.5 Risposta dei NIDS

Gli IDS generalmente non intervengono sul traffico, ma si limitano a rispon-dere passivamente segnalando le anomalie tramite messaggi di testo, email,o telefonate. La modalità di segnalazione dell’allarme spesso dipende dallagravità dello stesso.

Alcuni IDS, possono anche essere programmati per rispondere attivamenteagli attacchi più seri, adottando una delle seguenti contromisure:

• inviando un pacchetto RST all’attaccante simulando che esso proven-ga dal sistema attaccato al fine di far credere che la vittima non siaraggiungibile;

• interagendo con un firewall di rete per bloccare temporaneamente opermanentemente le connessioni con la vittima;

• monitorando l’intero scambio di pacchetti;

20


• eseguendo un nslookup4, un portscan5 o un traceroute6 verso il sistemaattaccante per reperire maggiori informazioni.

Tuttavia, configurando l’IDS per rispondere attivamente ad attacchi, in casodi falsi positivi si rischierebbe il blocco delle connessioni che normalmentedovrebbero essere consentite causando un DoS.

2.6 Posizionamento degli IDS

Una delle attività maggiormente critiche nella configurazione e messa in ope-ra di un IDS è il suo posizionamento all’interno della rete da monitorare. Inbase alla topologia della rete, possono presentarsi diversi casi. Quando in unsegmento di rete gli host sono collegati da un hub, l’implementazione di unNIDS è relativamente semplice perchè l’hub è una componente di rete che sioccupa di replicare ogni singolo pacchetto su tutte le porte. In questo modoè sufficiente collegare il NIDS a una porta qualsiasi dell’hub per poter leggeretutto il traffico passante.In presenza di uno switch, invece, la situazione è diversa e l’implementazionedei NIDS è maggiormente complicata. Gli switch, infatti, lavorano ad unlivello superiore della pila ISO/OSI[25] rispetto agli hub e quando devonoinviare un pacchetto, lo inviano solo verso la relativa porta di destinazio-ne. Una soluzione per poter leggere tutto il traffico del segmento di rete èil port mirroring che consiste nel monitorare una o più porte dello switch,copiandone il traffico su un’altra porta detta mirror port. Tale porta dovrànecessariamente avere una capacità di banda possibilmente pari alla sommadella capacità di banda di tutte le porte monitorate. Solo in questo modo iltraffico potrà essere gestito in modo opportuno.

4Nslookup è un comando che permette di risalire dall’hostname di una macchina al suoindirizzp IP.

5Il Portscan è una tecnica utlizzata per raccogliere informazioni e capire quali sono iservizi attivi su una vittima.

6Traceroute è un comando che permette di individuare il percorso compiuto daipacchetti di dati per giungere dal computer dell’utente ad un computer remoto.

21


Come detto, la scelta del posizionamento degli IDS è un’attività molto de-licata che deve tener conto delle esigenze della rete e delle risorse di cui sidispone.Un’altra variabile da considerare nel posizionamento di un IDS è la sua col-locazione rispetto ad un firewall. Posizionando l’Intrusion Detection Systemall’esterno del firewall, si identificheranno tutte le attività anomale inclusequelle che non avranno accesso alla rete in quanto bloccate dal firewall. UnIDS disposto in questo modo sarà più esposto agli attacchi provenienti dall’e-sterno perchè privo di protezione. Le risorse richieste sono ingenti in quantola quantità di traffico analizzato e di log memorizzati sarà rilevante.Una soluzione più economica consiste nel posizionare l’IDS all’interno del fi-rewall per monitorare solo il traffico che accede alla rete. In tal modo sarannogenerati meno allarmi e ci saranno meno log da analizzare.Se invece, l’obiettivo dell’IDS è la protezione dei server, una valida alter-nativa è installare il sistema di intrusion detection nella Demilitarized Zone(DMZ)7[23]. Tuttavia, gli altri segmenti di rete rimarrebbero privi di moni-toraggio.Pertanto, nel caso in cui le risorse a disposizione siano elevate, la soluzionepiù robusta consiste nell’installare un IDS per ogni segmento di rete. Que-sto permette di tenere sotto controllo l’intera rete, di configurare ciascunIntrusion Detection System in maniera diversa in base alle esigenze del sin-golo segmento e di evitare eventuali sovraccarichi dei sistemi. Inoltre, seun IDS dovesse venire meno per una qualsiasi ragione (come ad esempio er-rori hardware/software o attacchi di vario tipo), gli altri segmenti di retecontinuerebbero ad essere monitorati.

7La DMZ è un segmento di rete isolato della LAN, che si trova tra la rete interna e larete esterna. Alla DMZ si può accedere sia dalla rete interna che da quella esterna, ma leconnessioni dalla DMZ possono essere dirette solo verso l’esterno.

22


2.7 NIDS: gli Attacchi

Esistono diverse tecniche per aggirare un NIDS[17] che possono essere sfrutta-te diversamente, in base alle caratteristiche tecniche del sistema di intrusiondetection e quelle della rete che viene monitorata. Le tipologie d’attacco de-scritte di seguito, sfruttano il timeout di riassemblaggio del frame IP che è iltempo massimo in cui un frame viene tenuto in memoria prima di essere eli-minato e la frammentazione. Quando un pacchetto è eccessivamente granderispetto alla rete che deve attraversare, può essere frammentato da qualsiasirouter. Ogni frame viene associato a un Time to Live (TTL) che per essereaccettato dal router deve avere un valore maggiore di 1. Quando il routerriceve un frame, prima di inviarlo a destinazione, provvede a decrementare ilTTL di 1. Se questo diventa uguale a 0, il pacchetto viene eliminato e vienerestituito un messaggio di errore ICMP “Time Exceeded in Transit”.

Insertion Attack

Si verifica quando un NIDS accetta un pacchetto che il sistema finale rifiuterà.In questo modo l’attaccante può inserire dati nel NIDS in modo opportunoper nascondere un attacco. Possono essere sfruttati diversi tipi di InsertionAttack, descritti in seguito.

• Il tempo di timeout del NIDS è maggiore di quello della vittimaSupponiamo che il tempo di timeout del NIDS sia 60 secondi e quellodel sistema attaccato sia 30 secondi. Il pacchetto contenente codicemaligno viene diviso in 4 frammenti numerati da 1 a 4. Vengono poigenerati altri due frame ai quali associamo i numeri 2’ e 4’, con payloadapparentemente normale. L’attacco viene espletato come descritto diseguito. Si inviano i frame 2’ e 4’ che saranno ricevuti sia dal NIDSche dalla vittima. Dopo 30 secondi la vittima scarterà tali frame inquanto scaduto il tempo di timeout e non genererà alcun messaggioICMP di errore. Si inviano quindi, i frame 1 e 3. A questo punto lavittima avrà in memoria solo questi due frame, mentre il NIDS avrà i

23


frame 1,2’,3,4’ e andrà a calcolare la checksum8 che risulterà invalida epertanto scarterà i frammenti senza generare allarmi. Ora è possibileinviare i frame 2 e 4. In questo modo la vittima, avendo ricevuto tuttii 4 frame, riassemblerà il pacchetto, mentre il NIDS avendo ricevutosolo gli ultimi due pacchetti, attenderà il rispettivo tempo di timeoute provvederà a scartarli.

• Attacco basato su TTLPer sfruttare questo attacco è necessario conoscere il numero dei routerpresenti tra l’attaccante e la vittima. A tale scopo possono essere uti-lizzati tool come traceroute. Supponiamo che tra il NIDS e la vittimaci sia un router. Si divide il pacchetto contenente codice maligno in3 frammenti numerati da 1 a 3. Viene poi generato un altro frame alquale associamo il numero 2’ con payload apparentemente normale. Siinvia il frame 1 con un TTL elevato il quale sarà ricevuto sia dal NIDSche dalla vittima. Si invia il frame 2’ con TTL impostato a 1. Questoframmento sarà ricevuto dal NIDS ma non arriverà a destinazione per-chè sarà scartato dal router a causa del basso TTL. Si invia il frame 3con un TTL valido. A questo punto il NIDS riassemblerà i 3 frammenti,mentre la vittima resterà in attesa del secondo frammento. Dopo averinviato il frame 2, la vittima riassemblerà il pacchetto e l’attacco saràriuscito con successo.

• Overlapping dei frammentiCome detto precedentemente, ogni sistema operativo adotta una suapolitica di riassemblaggio dei pacchetti. Si supponga di avere un pac-chetto anomalo diviso in 4 frammenti numerati da 1 a 4. Vengono poigenerati altri due frame ai quali associamo i numeri 2’ e 4’, i quali han-no un payload apparentemente normale, stesso offset, stessa lunghezzae stesso header IP dei pacchetti 2 e 4. Si inviano i frame 1,2,3 i quali

8La checksum è una somma di controllo utilizzata per rilevare eventuali errori nellatrasmissione.

24


giungeranno a destinazione senza problemi. Si inviano ora i frammenti2’,3’,4. A questo punto diversi sistemi operativi potrebbero reagire inmodo diverso. Per esempio, i sistemi Windows, MacOC o SunOS rias-semblerebbero il pacchetto considerando validi i frame 1,2,3,4; sistemicome Cisco IOS considererebbero validi i frame 1,2’,3’,4. Pertanto, inbase al sistema operativo attaccato, questa tecnica può essere sfruttataper portare a termine un attacco.

Evasion Attack

Si verifica quando un NIDS scarta un pacchetto che sarà accettato dal sistemafinale. In questo modo l’attaccante può inviare pacchetti dannosi alla vittimasenza che il NIDS ne effettui l’analisi.

• Il tempo di timeout del NIDS è minore di quello della vittimaSupponiamo di aver diviso il pacchetto da inviare in 2 frame e cheil tempo di timeout del NIDS sia di 15 secondi e quello del sistemaattaccato sia 30 secondi. Dopo aver inviato il primo frame, l’attaccanteinvia il secondo frame in un intervallo di tempo che varia tra i 15 e i 30secondi. In questo modo il NIDS scarterà il pacchetto in quanto saràscaduto il tempo di timeout e non genererà allarmi, mentre la vittima,dopo aver ricevuto il secondo pacchetto, effettuerà il riassemblaggioportanto l’attacco a compimento.

• Unicode EvasionConsiste nel modificare i pacchetti cercando di evitare il pattern mat-ching con le regole di intrusion detection. Per esempio, in occasione del-la diffusione del worm Nimda[5] è stato riscontrato che il worm inviavauna particolare richiesta HTTP, dove il simbolo “/” veniva sostituitocon il corrispondente codice Unicode “%c0%af”:

GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir

In tal modo, sfruttando una vulnerabilità di alcuni server Microsoft

25


IIS, il worm riusciva a guadagnare i privilegi di amministratore ed adaccedere alla root directory. Dopo la ricezione della sringa, sostituiva‘%c0%af’ con il carattere ‘/’ ottenendo la stringa:

GET /scripts/../../winnt/system32/cmd.exe?/c+dir

che coincide esattamente con la root directory.

Denial of Service

Il Denial of Service è finalizzato a provocare l’arresto temporaneo o definitivodei NIDS.

• Esaurimento delle Risorse della CPUConsiste nell’inviare grandi quantità di pacchetti frammentati sfruttan-do il fatto che, quando l’IDS riceve tali pacchetti, questi devono esseresalvati e mantenuti fino a quando tutti i pacchetti dello stream nonsiano arrivati o il tempo di timeout non sia raggiunto.

2.8 Log Analysis

L’analisi dei log è di fondamentale importanza nel processo di intrusion de-tection sia nel caso ci siano stati dei tentativi di intrusione, che nel caso sisia verificato un incidente informatico.I log memorizzano record contenenti informazioni sul timestamp9, sul pro-tocollo utilizzato, sull’indirizzo IP sorgente e di destinazione e sulle porteutilizzate da qualsiasi attività anomala monitorata. Possono anche esserecontenuti dati aggiuntivi come una descrizione testuale dell’evento o il nu-mero della regola che ha generato l’allarme.Quando vengono generati log causati da eventi di una certa entità, è oppor-tuno memorizzare anche il payload del pacchetto che ha generato l’allarmeper avere maggiori dettagli sull’evento.

9Il timestamp include la data e l’ora in cui l’evento è stato registrato.

26


Facciamo un esempio considerando una richiesta DNS10. In corrispondenzadi questo evento, verrà generato un log dove sarà riportato che il potenzialeattaccante con indirizzo IP 100.200.100.200 ha inviato un pacchetto UDP aldestinatario 90.80.70.60, sulla porta 53. Ciò non sarà sufficiente a capire sela richiesta DNS è stata dannosa o meno. La situazione sarebbe differentenel caso in cui si potesse analizzare anche il payload del pacchetto.Uno dei problemi maggiori nell’analisi dei log è l’eterogeneità intrinseca deglistessi, in quanto variano a seconda del firewall, del router o dell’IDS utiliz-zato. Non esistono tool che sincronizzano cronologicamente i log prodotti dasistemi differenti. Può talvolta capitare che la time zone differisca da sistemaa sistema, rendendo ancora più complicata l’analisi; tuttavia, per sincroniz-zare sistemi diversi, possono essere usati protocolli come NTP[24].Inoltre, di estrema importanza è la capacità di reazione di fronte ad un’intru-sione. Intervenire tempestivamente quando si identifica un’intrusione, spessoè essenziale per evitare che l’attaccante possa alterare o eliminare i log.Gli amministratori di rete, tuttavia, dovrebbero prestare attenzione non soloalla possibile manipolazione dei log ma anche alle molteplici attività anomaleche possono presentarsi, come quelle che si stanno per analizzare.

• Il calo delle performance della rete dovuto alla saturazione della banda,che si verifica perchè spesso l’attaccante utilizza le macchine compro-messe per archiviare programmi, mp3 e film da mettere illegalmente incondivisione con gli altri utenti della rete.

• Il traffico sospetto verso indirizzi IP sconosciuti o su protocolli nonutilizzati comunemente. Se si rilevano connessioni in uscita prove-nienti da un server web, questo può significare che il server sia statocompromesso.

• Se si identificano pacchetti malformati, c’è il rischio che un attaccante10Per richiesta DNS si intende un’interrogazione inviata al server DNS per risolvere

un’indirizzo IP ottenendo l’indirizzo IP numerico, dal nome della macchina.

27


sia alla ricerca di vulnerabilità sulle varie macchine del sistema o stiatentando di aggirare un firewall.

• La perdita di connettività, che potrebbe essere associata ad un attaccoDoS.

• Un numero elevato di tentativi di login falliti, i quali sono comuni quan-do l’attaccante cerca di ottenere maggiori privilegi di quelli realmenteconcessi.

• Un’attività inusuale del modem, che potrebbe indicare la probabilepresenza di dialer.

• Le ‘Scansioni’ verso le macchine della rete, che sono utilizzate dall’at-taccante per raccogliere informazioni sui sistemi operativi installati, iservizi attivi, le porte aperte e la topologia della rete. Tali informazionisaranno poi usate per effettuare un attacco.

• L’alta quantità di traffico generata in orari non di lavoro, indice diutenti non autorizzati che stanno usufruendo della rete.

Nel caso in cui nella rete attaccata fosse presente uno switch, una vol-ta introdottosi, l’attaccante potrebbe intercettare il traffico utilizzando dueattacchi.

• L’attacco ARP-POISONING, dove vengono alterate le tabelle ARP11

degli host appartenenti allo stesso segmento di rete, in modo che lamacchina sul quale risiede lo sniffer veda anche il traffico generato daglialtri host.

• L’attacco DHCP-POISONING, dove l’attaccante fa in modo che un ho-st della rete interna simuli di essere il server DHCP e invii delle rispostead-hoc alle DHCP-REQUEST che gli arrivano, specificando l’indirizzo

11Le tabelle ARP contengono la correlazione tra indirizzi IP e MAC address di unamacchina.

28


IP dell’attaccante come default gateway. In tal modo tutto il traffi-co, prima di arrivare all’esterno, passerà per la macchina controllatadall’attaccante.

2.9 Aspetti Legali

Qualsiasi attività di monitoraggio della rete deve rispettare le normative invigore nello stato in cui si trova il sistema informatico e le politiche interneaziendali. In caso contrario esiste il rischio di essere perseguiti penalmenteper violazione della privacy degli utenti della rete e per intercettazione abusi-va di comunicazione informatica. Non sarà, inoltre, possibile utilizzare i datiraccolti per intraprendere azioni legali nei confronti di un intruso.

È pertanto opportuno:

• informare gli utenti che la loro attività di rete sarà monitorata;

• indicare lo scopo del monitoraggio;

• specificare le tipologie di traffico monitorate;

• specificare il responsabile a cui saranno inviate le segnalazioni di even-tuali compromissioni.

Dal punto di vista burocratico tali accorgimenti possono essere tradottiin una lettera informativa da far firmare a tutti gli utenti della rete per presavisione. Dal punto di vista tecnico è possibile implementare un “Message ofthe Day” (MOTD) che consiste in un messaggio iniziale che informa gli utentidell’attività di logging della rete.

In caso di incidente informatico i log rappresentano prove preziose, ed inquanto tali, devono essere ottenute in modo conforme alla normativa vigenteed essere tali da poter illustrare dettagliatamente lo svolgimento dei fatti.È pertanto opportuno fare in modo che la prova ottenuta sia:

29


• autentica ed inalterata anche in caso di spostamenti dei dispositivi checontengono la prova stessa;

• completa, in quanto non deve mostrare l’incidente dall’unica prospetti-va riconducibile alle azioni compiute dall’attaccante, ma deve valutareanche prospettive che potrebbero dare adito a contraddizioni;

• comprensibile e credibile, ovvero rappresentata in un formato leggibileda chiunque e non ad uso esclusivo degli esperti del settore.

2.10 Scelta di un NIDS

Per concludere questa panoramica, vengono discussi gli elementi da tenere inconsiderazione durante la scelta di un NIDS.

• Costo: deve, ovviamente, essere proporzionato alle risorse che si vo-gliono proteggere.

• Capacità della banda supportata: è la quantità di traffico che il sen-sore può analizzare in un’unità di tempo. Si misura in Mb/s o inpacchetti/sec.

• Aggiornamento delle firme: i NIDS da questo punto di vista funzionanoesattamente come gli antivirus. Per poter identificare i nuovi attacchidevono avere nel loro database le firme recenti. Per questa ragioneè di estrema importanza che gli aggiornamenti vengano rilasciati inmodo tempestivo e venga data la possibilità di aggiornare il databasein modo automatico. Importante è anche la possibilità di utilizzarefirme personalizzate create ad-hoc per le proprie esigenze.

• Attività di logging : è opportuno verificare la chiarezza dei log e valutarese l’output viene salvato in formato standard o proprietario.

• Scalabilità: La possibilità di ampliare le funzionalità del NIDS in casodi esigenze future è di estrema importanza, in partiolare andrebbe valu-

30


tato il numero di sensori supportati e la possibilità di gestire il sistemain maniera centralizzata tramite un’apposita console.

31

CAPITOLO 3. SNORT

Capitolo 3

Snort

3.1 Introduzione

Snort[21] è il più noto Network-based Intrusion Detection System della co-munità OpenSource, progettato per funzionare sia su sistemi operativi Unixche Windows[30]. Uno degli aspetti che lo differenzia dagli altri NIDS è l’am-pio bagaglio di regole di cui dispone che sono aggiornate in modo tempestivodalla communità e la semplicità della loro sintassi che permette a chiunquedi scriverne e aggiungerne nuove. La possibilità di salvare i log e di forni-re l’output in diversi formati e ciò che lo rende uno dei migliori NIDS delsettore.

3.2 Requisiti Hardware

Per implementare Snort in una rete e realizzare un buon sistema di intrusiondetection è opportuno disporre di 2 macchine, ciascuna dotata di due schededi rete e un hub. La prima macchina funzionerà da sensore, l’altra verrà uti-lizzata per archiviare i log e per permettere il monitoraggio delle statisticheda remoto.Più grande sarà la rete da monitorare, migliori dovranno essere le caratteristi-che tecniche delle macchine usate. Bisognerà infatti disporre di una quantità

33

CAPITOLO 3. SNORT

sufficiente di memoria RAM, di un adeguato spazio per archiviare i log e diuna CPU sufficientemente rapida per processare tutti i pacchetti in temporeale.Per poter quantificare le risorse necessarie è opportuno valutare:

• la dimensione della rete in cui sarà posto il sensore NIDS;

• la quantità di traffico normalmente vista dalla rete;

• dove e per quanto tempo saranno archiviati i log;

• quante regole saranno abilitate;

• quale forma di output sarà utilizzata;

• in che modo saranno generati gli allarmi.

Concretamente, per monitorare una rete domestica è consigliabile disporredi un processore da almeno 2Ghz per l’analisi dei pacchetti e 5Gb di spaziolibero da dedicare all’archiviazione dei log.

3.3 Architettura di Snort

Snort ha un’architettura molto complessa composta da diversi componenti:

• il packet decoder che intercetta e decodifica i pacchetti in arrivo;

• i preprocessori che analizzano i pacchetti individuando quelli potenzial-mente dannosi;

• il detection engine che controlla il pattern matching dei pacchetti conle regole;

• i componenti di alerting e logging che generano gli allarmi e archivianoi log.

Di seguito vengono analizzati i diversi componenti che fanno parte del-l’architettura di Snort.

34

CAPITOLO 3. SNORT

Il Packet Decoder

Il packet decoder è il componente responsabile dell’analisi dei pacchetti. Es-so ne determina il protocollo e la struttura, generando allarmi qualora ven-gano identificati pacchetti malformati. Si configura modificando il file diconfigurazione /etc/snort.conf come segue:

# Stop generic decode events:

config disable_decode_alerts

# Stop Alerts on experimental TCP options

config disable_tcpopt_experimental_alerts

# Stop Alerts on obsolete TCP options

config disable_tcpopt_obsolete_alerts

# Stop Alerts on T/TCP alerts

# In snort 2.0.1 and above, this only alerts when a TCP option

# is detected that shows T/TCP being actively used on the

# network. If this is normal behavior for your network, disable

# the next option.

config disable_tcpopt_ttcp_alerts

# Stop Alerts on all other TCPOption type events:

config disable_tcpopt_alerts

# Stop Alerts on invalid ip options

config disable_ipopt_alerts

Terminata l’analisi, i pacchetti vengono inviati ai preprocessori.

I Preprocessori

I preprocessori, sono dei plug-in di Snort che analizzano il comportamentodei pacchetti. Ogni preprocessore ha la funzione di identificare una diversa ti-pologia di attacco. Qualora il comportamento dei pacchetti dovesse risultaredannoso, essi vengono inviati al detection engine che provvederà a verificar-ne il pattern matching con le regole. I preprocessori possono essere attivati,

35

CAPITOLO 3. SNORT

disattivati e configurati attraverso il file /etc/snort.conf.Per capirne meglio il funzionamento, esaminiamo i preprocessori HTTPIn-spect e sfportscan e le loro principali opzioni di configurazione.

Il preprocessore HTTPInspect, si occupa di decodificare il traffico HTTPe di identificare attacchi a livello applicativo che sfruttano eventuali vulne-rabilità del protocollo HTTP. La configurazione di questo preprocessore èdivisa in due parti, una globale e una per i server.La configurazione globale è identificata dalla stringa:

preprocessor http_inspect: global [opzioni di configurazione]

I parametri che possono essere configurati sono:

• iis_unicode_map [filename (located in the config dir)]

[codemap (integer)]

che deve essere sempre specificato in quanto contiene contiene la globalIIS unicode map1.

• detect_anomalous_servers

che genera un allarme se viene rilevato traffico HTTP su porte nonstandard; è opportuno non attivare questa opzione se è prevista unaconfigurazione server di default.

La sezione dedicata ai server ha due modalità di configurazione: default e IP.La stringa che identifica la configurazione di default è:

preprocessor http_inspect_server:

server default [server options]

mentre quella IP, che identifica la configurazione di indirizzi IP individuali,è:

1Unicode è un sistema di codifica che assegna una combinazione di bit a ogni carat-tere. La Unicode Map è un file contenente l’associazione tra un carattere e la rispettivacombinazione di bit.

36

CAPITOLO 3. SNORT


server [IP] [server options]

Le opzioni specificabili sono:

• profile [all/apache/iis]

che permette di selezionare dei profili predefiniti in base al tipo di ser-ver HTTP utilizzato, scegliendo tra ‘all’, ‘apache’ e ‘iis’. Questa opzio-ne può essere combinata ad opzioni come ‘ports’, ‘iis_unicode_map’,‘flow_depth’, ‘no_alerts’, ‘inspect_uri_only’ e ‘oversize_dir_length’che vanno specificate dopo il profilo in questo modo:


server 1.1.1.1 profile all ports { 80 3128 }

• ports { [port] [port] . . . }

che indica su quale porta è attivo il servizio HTTP. Il traffico cifratoSSL non potrà essere decodificato.

• flow_depth [integer]

che specifica quanti byte del payload di risposta del server ispezionare.Questa opzione incrementa notevolmente le prestazioni dell’IDS perchépermette di ignorare una buona parte del traffico HTTP. Il valore puòessere impostato da -1 a 1460. -1 permette di ignorare l’intero trafficodi risposta, mentre 0 permette di ispezionare integralmente i payloaddei pacchetti.

• ascii [yes/no]

che permette di decodificare un URL che contiene sequenze di caratteriASCII.

• utf_8 [yes/no]

che permette di decodificare un URL che contiene sequenze di caratteriUTF-8.

37

CAPITOLO 3. SNORT

• iis_unicode [yes/no]

che permette di usare la mappa di default, se non è specificata una IISUnicode Map.

• multi_slash [yes/no]

che permette di generare un allarme ogni volta che viene incontratauna stringa contenente più caratteri ‘/’ consecutivi.(Es. “pippo/////////pluto”)

• iis_backslash [yes/no]

che permette di generare un allarme ogni volta che viene incontratauna stringa contenente un carattere ‘\’.(Es. “pippo\pluto”)

• no_alerts

che permette di non ricevere allarmi generati da questo preprocessore.Se questa opzione viene selezionata, le rispettive regole HTTP nonhanno alcun effetto.

• oversize_dir_length [non-zero positive integer]

che specifica la lunghezza massima di un URL. Generalmente la lun-ghezza media è di 300 caratteri.

• inspect_uri_only

che migliora notevolmente le prestazioni in quanto permette di esami-nare solo la porzione di payload contenente l’URL.

Un esempio di configurazione del preprocessore HTTPInspect è:

# unicode.map should be wherever your snort.conf lives, or

# given a full path to where snort can find it.

preprocessor http_inspect: global \

iis_unicode_map unicode.map 1252

38

CAPITOLO 3. SNORT

preprocessor http_inspect_server: server 1.1.1.1 \

ports { 80 3128 8080 } \

flow_depth 0 \

ascii yes \

oversize_dir_length 300

Dal precedente codice si deduce che il file contenente la mappa Unicode èunicode.map, l’indirizzo IP del server HTTP è 1.1.1.1 il quale è attivo sulleporte 80,3128 e 8080. Non sarà ispezionato il payload dei pacchetti di rispo-sta del server, ma saranno decodificati gli URL contenenti caratteri ASCIIche potranno avere una lunghezza massima di 300 caratteri.

Il preprocessore sfportscan invece, si occupa di identificare la prima fase diun attacco, dove l’attaccante cerca di acquisire informazioni sui protocollie sui servizi supportati da una vittima. Questo preprocessore, permette diidentificare qualsiasi tipo di Portscan.

A tal proposito, è necessario che sia abilitato il preprocessore flow 2 conil quale il preprocessore sfportscan interagisce, mediante la seguente stringa:

preprocessor flow: stats_interval 0 hash 2

I parametri che possono essere configurati per il preprocessore sfportscansono:

• proto { <proto> }

che può essere configurato con una delle seguenti opzioni: ‘tcp’, ‘udp’,‘icmp’, ‘ip’ oppure ‘all’ se si intende esaminare tutti i protocolli.

• scan_type { <scan_type> }

che può essere configurato con le opzioni: ‘portscan’, ‘portsweep’, ‘de-coy_portscan’, ‘distributed_portscan’ oppure ‘all’ se si intende moni-torare tutti i tipi di scan.

2Il preprocessore flow è un prerequisito di funzionalità di altri preprocessori in quantolascia Snort in un continuo meccanismo di acquisizione.

39

CAPITOLO 3. SNORT

• sense_level { <level> }

che accetta i parametri: ‘low’, ‘medium’ o ‘high’ in base al grado disensibilità che si vuole assegnare al sensore.

• ignore_scanners { <ip_list> }

che definisce gli indirizzi IP che possono eseguire scansioni e pertantoda ignorare.

• ignore_scanned { <ip_list> }

che definisce gli indirizzi IP che possono ricevere scansioni e pertantoda ignorare.

• logfile { <file> }

che definisce su quale file salvare l’output delle scansioni.

Un esempio di configurazione è:

preprocessor sfportscan: proto { all } \

scan_type { all } \

logfile { /var/log/snort/portscan } \

sense_level { high }

Dal precedente codice si deduce che saranno esaminati i pacchetti appar-tenenti a tutti i protocolli, saranno monitorati tutti i tipi di scansioni, il filecontenente i log dei Portscan sarà /var/log/snort/portscan, e il sensoreavrà una sensibilità alta.

Il Detection Engine

Il Detection Engine è il componente che riceve i pacchetti dai preprocessori esi occupa di confrontarli con le regole di intrusion detection. Nel caso in cuidovesse esserci una corrispondenza tra un pacchetto e più regole diverse, laprima regola che trova una corrispondenza con il contenuto di un pacchetto

40

CAPITOLO 3. SNORT

genera un allarme o, in alternativa, Snort offre anche la possibilità di gene-rare un allarme per ciascun evento.

Per ridurre il numero di falsi positivi può essere configurato il filethreshold.conf. Siccome ogni evento è associato ad un gen_id e un sig_id,conoscendo questi due valori, è possibile disabilitare completamente gli allar-mi in questo modo:

# Suppress this event completely

suppress gen_id 1, sig_id 1852

# Suppress this event from this IP

suppress gen_id 1, sig_id 1852, track by_src, ip 10.1.1.54

# Suppress this event to this CIDR block

suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.0/24

Per garantire l’effettiva disattivazione delle regole, è opportuno accertarsiche il file threshold.conf sia incluso nel file snort.conf mediante la stringa

include threshold.conf

È anche possibile fare in modo che in un certo intervallo di tempo vengagenerato al massimo un allarme.

# Esempio

threshold gen_id 1, sig_id 1851, type limit, track by_src,

count 1, seconds 60

I Componenti di Alerting e Logging

Quando viene trovata una corrispondenza tra un pacchetto e una regola,entrano in gioco i componenti di alerting e logging, il primo usato per gene-rare gli allarmi, il secondo per archiviare i pacchetti che hanno causato lagenerazione dell’allarme. È possibile archiviare i log in un database MySQL,PosgreSQL, Oracle o ODBC, oppure inviarli ad un server Syslog, o salvarli

41

CAPITOLO 3. SNORT

in formato compatibile con Tcpdump. Queste opzioni sono configurabili nelfile snort.conf in questo modo:

# Step #3: Configure output plugins

#

# È sufficiente eliminare il commento al plug-in che si intende

# usare.

#

# La configurazione generale è di questo tipo

# output <name_of_plugin>: <configuration_options>

#

# alert_syslog: log alerts to syslog

# ----------------------------------

# Use one or more syslog facilities as arguments. Win32 can

# also optionally specify a particular hostname/port.

# Under Win32, the default hostname is ’127.0.0.1’, .

# and the default port is 514

#

# [Unix flavours should use this format...]

# output alert_syslog: LOG_AUTH LOG_ALERT

#

# [Win32 can use any of these formats...]

# output alert_syslog: LOG_AUTH LOG_ALERT

# output alert_syslog: host=hostname, LOG_AUTH LOG_ALERT

# output alert_syslog: host=hostname:port, LOG_AUTH LOG_ALERT

# log_tcpdump: log packets in binary tcpdump format

# -------------------------------------------------

# The only argument is the output file name.

#

# output log_tcpdump: tcpdump.log

42

CAPITOLO 3. SNORT

# database: log to a variety of databases

# ---------------------------------------

# In questo caso è attivo il database MySQL

#

# output database: log, mysql, user=snort password=test

# dbname=snort host=localhost

# output database: alert, postgresql, user=snort dbname=snort

# output database: log, odbc, user=snort dbname=snort

# output database: log, oracle, dbname=snort user=snort

# password=test

In base alla riga di codice a cui viene tolto il commento si stabilisce il tipodi output. Nel caso in cui si intenda archiviare i dati in un server Syslog, vaspecificato se tale server sia Unix o Windows. Per archiviare i dati in un filecompatibile con Tcpdump, è sufficiente configurare il nome da dare a talefile. Nel caso si intenda archiviare i dati in un database, dovrà essere inseritoil nome del database, l’username e la password.

3.4 Modalità di Funzionamento

Snort ha diverse opzioni di funzionamento che possono essere adottate aseconda del contesto in cui viene installato.

• -A alert-mode: Permette di specificare la modalità di generazione degliallarmi che può essere di tipo full, fast, none e unsock. L’opzione full èimpostata di default e permette di avere informazioni complete sull’at-tacco, fast invece permette di rendere più rapido il sistema generan-do allarmi in un formato più semplice che contiene solo il timestamp,il messaggio di allarme e gli indirizzi IP sorgente e di destinazione.La modalità none permette di non generare allarmi, mentre unsock èun’opzione sperimentale che invia le informazioni ad un altro processoattraverso un socket UNIX.

43

CAPITOLO 3. SNORT

• -b: Effettua il logging dei pacchetti in formato binario.

• -c config-file: Utilizza le regole trascritte nel file di configurazionespecificato.

• -D : Avvia snort in modalità daemon.

• -h home-net : Imposta la rete domestica nel formato 192.168.1.0/16.

• -i interface: Imposta l’interfaccia di rete sul quale effettuare lo sniffing.

• -k logging-mode: Imposta la modalità di logging. Quella di default èpcap ma può essere anche cambiata in ascii o none, che permette dinon effettuare il logging dei pacchetti.

• -l log-dir : Imposta il percorso del file nel quale saranno archiviati i log.

• -N : Disabilita il logging dei pacchetti ma continua a generare allarmi.

• -s : Invia messaggi di allarme ad un server Syslog.

• -v : Visualizza l’header dei pacchetti.

• -V : Visualizza la versione di Snort.

3.5 Regole di Intrusion Detection

Una regola è un set di istruzioni strutturato in modo tale da permettere diverificare il pattern matching con l’header dei pacchetti, oppure con stringhecontenute nel payload dei pacchetti.

Una buona regola deve essere specifica e chiara in modo tale da ridurrefalsi negativi e falsi positivi, e deve contenere una descrizione accurata del-l’attacco fornendo referenze per eventuali approfondimenti esterni.

Una regola è composta da un header (l’intestazione della regola) e unbody (il corpo della regola).

44

CAPITOLO 3. SNORT

Header

L’header è la parte principale della regola e comprende: l’azione da intra-prendere (alert, log, pass, ...), il protocollo utilizzato, l’indirizzo IP e la portasorgente, l’indirizzo IP e la porta di destinazione. Una volta trovata una cor-rispondenza tra una regola e il contenuto di un pacchetto, è possibile sceglieretra diverse opzioni ciascuna identificata da una particolare keyword:

• ALERT ha la semplice funzione di generare un allarme;

• LOG archivia l’evento senza generare l’allarme;

• PASS ignora il pacchetto;

• ACTIVATE genera un allarme e poi attiva una regola DYNAMIC;

• DYNAMIC viene attivata da una regola ACTIVATE e poi agisce comela keyword LOG.

# Esempio

alert udp any 19 <> any 7

Nel precente esempio viene generato un allarme, qualora venga ricono-sciuto un pacchetto UDP proveniente dalla porta 19 di un qualsiasi indirizzoIP sorgente, verso la porta 7 di un qualsiasi indirizzo IP di destinazione. Iparametri aggiuntivi, come il testo del messaggio da scrivere nei log, sarannoconfigurati nel body.

Body

Il body completa la definizione della regola e comprende una serie di opzioniche vengono racchiuse tra parentesi:

# Esempio

(msg:"DOS UDP echo+chargen bomb";

reference:cve,CAN-1999-0635; reference:cve,CVE-1999-0103;

classtype:attempted-dos; sid:271; rev:3;)

45

CAPITOLO 3. SNORT

Nel precedente esempio, il messaggio scritto nei log sarà ‘DOS UDP echo+ chargen bomb’, la tipologia d’attacco è ‘attempted-dos ’ che indica il tenta-tivo di effettuare un attacco DoS, l’identificatore della regola che ha generatol’allarme è 271 e tale regola è stata revisionata 3 volte. Vengono inoltredati alcuni riferimenti da cui reperire informazioni aggiuntive sull’attacco:cve,CAN-1999-0635 e cve,CVE-1999-0103.

Il body è inoltre configurabile con una serie di opzioni come ad esempio‘flow’, ‘TTL’ o ‘sid’ che saranno analizzate di seguito.L’opzione ‘flow’, permette di definire la direzione dello stream di pacchettida controllare e può assumere i seguenti valori:

• to_server: per i pacchetti inviati al server;

• from_server: per i pacchetti inviati dal server;

• to client: per i pacchetti inviati al client;

• from_client: per i pacchetti inviati dal client;

• established: per i paccheti di una sessione TCP in stato established.

L’opzione ‘sameip’ permette di analizzare se la sorgente e la destinazionedei pacchetti coincidono; la regola assume la seguente forma:

alert ip any any -> any any

(msg:"Same Source and Destination IP Address"; sameip;)

Il Time To Live ‘TTL’ viene utilizzato per identificare le query via toolcome Traceroute, Tracert o Netroute e supporta i simboli ‘>’,‘<’ e ‘=’, men-tre l’opzione ‘seq’, permette di selezionare i pacchetti con numero di sequenzastatico.

La verifica dei flag TCP è invece attivata tramite l’opzione ‘flags’ che puòassumere diversi valori:

• A: per verificare se è attivo solo il flag ACK;

46

CAPITOLO 3. SNORT

• F: per verificare se è attivo solo il flag FIN;

• P: per verificare se è attivo solo il flag PSH;

• R: per verificare se è attivo solo il flag RST;

• S: per verificare se è attivo solo il flag SYN;

• U: per verificare se è attivo solo il flag URG;

• +: usato per identificare se sono attivi altri flag oltre quello specificato(Es. A+ identificherà i pacchetti con attivi i flag AF,AP,AR,AS,AU);

• *: usato per verificare se sono attivi i flag specificati (Es. *AS, identi-ficherà solo i pacchetti con attivi i flag AS);

• !: usato per verificare se sono attivi i flag diversi da quello specificato(Es. !S identificherà i pacchetti con attivi uno o più flag tra i seguenti:A,F,P,R,U).

Inoltre, se da un lato l’opzione ‘ack’, permette di selezionare i pacchetticon numero di acknowledgement statico, l’opzione ‘itype’ esamina invece ilvalore del campo itype dei pacchetti ICMP, al fine di identificare i pacchetticon valori non validi.

Lo Snort ID ‘sid’ identifica univocamente le regole di Intrusion Detetion. Ivalori tra 1 e 1.000.000 sono riservati alle regole rilasciate da www.snort.org,mentre quelli maggiori di 1.000.000 possono essere usati dagli utenti per crea-re le proprie regole. In questo ambito l’opzione ‘rev’ rilascia informazionicirca il numero di revisioni avuto da una regola, l’identificatore di sicurezza‘priority’ assegna una priorità ad ogni regola e l’opzione ‘classtype’ permettedi raggruppare le regole in base ad una categoria di attacco.

L’opzione ‘reference’, inoltre, permette di associare a ciascuna regolauna referenza esterna dove reperire maggiori informazioni sulla vulnerabilitàsfruttata. La sintassi di riferimento per questa opzione è:

47

CAPITOLO 3. SNORT

reference:<fonte> <valore>;

Continuando l’analisi delle opzioni configurabili all’interno del body diuna regola di intrusion detection, troviamo l’opzione ‘msg’ che permette diassociare alla regola un messaggio che informerà sul tipo di attacco poten-zialmente riscontrato. Questa opzione si utilizza nel seguente modo:

alert tcp $EXTERNAL any -> $INTERNAL 79 (msg:"Finger";)

L’opzione ‘logto’ permette di archiviare i pacchetti relativi alla regola. Lasintassi di questa opzione è

logto: "PATH/FILE.estensione";

Snort fornisce, inoltre, la possibilità di definire delle variabili da usarenelle regole. Ogni variabile deve avere una struttura di questo tipo:

Var <nome variabile> <valore variabile>

Ogni variabile definita all’interno di regole o nei file di configurazione, puòessere richiamata anteponendo al suo nome il simbolo ‘$’.

Nel file snort.conf è opportuno definire le variabili principali al fine dialleggerire il carico della CPU nel modo seguente:

# Indirizzi IP o range di indirizzi IP della rete interna

var HOME_NET [10.1.1.0/24,192.168.1.0/16]

# Indirizzi IP o range di indirizzi IP della rete esterna

# che in questo caso assume tutti i valori diversi

# dalla rete interna

var EXTERNAL_NET !$HOME_NET

# Indirizzo IP di un eventuale Server DNS

# Anche per i server è possibile specificare più

48

CAPITOLO 3. SNORT

# di un indirizzo IP nel caso ci siano più server

# dello stesso tipo

var DNS_SERVERS 192.168.1.101

# Indirizzo IP di un eventuale Server SMTP

var SMTP_SERVERS 192.168.1.102

# Indirizzo IP di un eventuale Server Web

var HTTP_SERVERS 192.168.1.103

# Indirizzo IP di un eventuale Server SQL

var SQL_SERVERS 192.168.1.104

# Indirizzo IP di un eventuale Server Telnet

var TELNET_SERVERS 192.168.1.105

# Indirizzo IP di un eventuale Server SNMP

var SNMP_SERVERS 192.168.1.106

# Il valore di default per tutti i server è

var NOME_SERVER $HOME_NET

# che permette di trattare tutti gli host della rete interna

# come server

# Valore numerico della Porta Http su quale il

# server web è in ascolto

var HTTP_PORTS 80

# Valore Numerico della Porta di un eventuale Server Oracle

var ORACLE_PORTS 1521

49

CAPITOLO 3. SNORT

# Indirizzi IP dei Server Aim

var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,

64.12.163.0/24,64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,

205.188.7.0/24,205.188.9.0/24,205.188.153.0/24,

205.188.179.0/24,205.188.248.0/24]

# Percorso dei file contenenti le regole

var RULE_PATH /boot/etc/rules

Le regole sono, infine, raggruppate per categorie in alcuni file che sarannoinclusi nel file di configurazione snort.conf.

include $RULE_PATH/local.rules

include $RULE_PATH/bad-traffic.rules

include $RULE_PATH/exploit.rules

include $RULE_PATH/scan.rules

include $RULE_PATH/finger.rules

include $RULE_PATH/ftp.rules

include $RULE_PATH/telnet.rules

include $RULE_PATH/rpc.rules

include $RULE_PATH/rservices.rules

include $RULE_PATH/dos.rules

include $RULE_PATH/ddos.rules

include $RULE_PATH/dns.rules

include $RULE_PATH/tftp.rules

include $RULE_PATH/web-cgi.rules

include $RULE_PATH/web-coldfusion.rules

include $RULE_PATH/web-iis.rules

include $RULE_PATH/web-frontpage.rules

include $RULE_PATH/web-misc.rules

include $RULE_PATH/web-client.rules

50

CAPITOLO 3. SNORT

include $RULE_PATH/web-php.rules

include $RULE_PATH/sql.rules

include $RULE_PATH/x11.rules

include $RULE_PATH/icmp.rules

include $RULE_PATH/netbios.rules

include $RULE_PATH/misc.rules

include $RULE_PATH/attack-responses.rules

include $RULE_PATH/oracle.rules

include $RULE_PATH/mysql.rules

include $RULE_PATH/snmp.rules

include $RULE_PATH/smtp.rules

include $RULE_PATH/imap.rules

include $RULE_PATH/pop2.rules

include $RULE_PATH/pop3.rules

include $RULE_PATH/nntp.rules

include $RULE_PATH/other-ids.rules

include $RULE_PATH/web-attacks.rules

include $RULE_PATH/backdoor.rules

include $RULE_PATH/shellcode.rules

include $RULE_PATH/policy.rules

include $RULE_PATH/porn.rules

include $RULE_PATH/info.rules

include $RULE_PATH/icmp-info.rules

include $RULE_PATH/virus.rules

include $RULE_PATH/chat.rules

include $RULE_PATH/multimedia.rules

include $RULE_PATH/p2p.rules

include $RULE_PATH/experimental.rules

51

CAPITOLO 3. SNORT

Ad una tipologia di server, è usualmente associata una tipologia di regole:ad esempio il server DNS è associato al file dns.rules o il server POP3 alfile pop3.rules.

In questo modo, specificando per esempio l’indirizzo IP di un server DNS,tutte le regole presenti nel file dns.rules saranno verificate solo sui pacchettiin ingresso e uscita dal server DNS e non su tutto il restante traffico di reteche non sarebbe comunque vulnerabile ai tipi di attacchi controllati dalleregole.

È anche possibile disabilitare una categoria di regole commentando lastringa corrispondente al file include. Per esempio se non è configurato unserver web, sarà possibile aggiungere il simbolo ‘#’ davanti alle seguentistringhe di inclusione:

# include $RULE_PATH/web-cgi.rules

# include $RULE_PATH/web-coldfusion.rules

# include $RULE_PATH/web-iis.rules

# include $RULE_PATH/web-frontpage.rules

# include $RULE_PATH/web-misc.rules

# include $RULE_PATH/web-client.rules

# include $RULE_PATH/web-php.rules

Terminata questa panoramica sulla configurazione delle regole di Snort,si esamineranno nel prossimo l’analisi dei log generati dalle regole.

3.6 Analisi dei Log

Quando si verifica un incidente, l’analisi delle intrusioni permette di averemaggiori informazioni sia su come si è sviluppato l’attacco, che sull’entità intermini di pericolosità dello stesso. Il primo passo che permette di raccoglieremaggiori informazioni è l’analisi degli eventi. Snort produce dei log di questoformato:

52

CAPITOLO 3. SNORT

[**] [1:469:1] ICMP PING NMAP [**]

[Classification: Attempted Information Leak] [Priority: 2]

10/15-06:01:46.050056 192.168.0.4 -> 192.168.0.3

ICMP TTL:45 TOS:0x0 ID:17750 IpLen:20 DgmLen:28

Type:8 Code:0 ID:31266 Seq:8282 ECHO

[Xref => http://www.whitehats.com/info/IDS162]

Analizzando i campi del log registrato si evince che:

• 1:469:1 è composto da tre numeri, di cui il primo indica quale com-ponente di Snort ha generato l’allarme, il secondo indica il SID dellafirma e l’ultimo il numero di revisioni della firma stessa.

• ICMP PING NMAP è il nome dell’attacco.

• Classification: Attempted Information Leak indica il tipo di attacco.

• Priority: 2 indica il grado di priorità dell’allarme che è direttamenteproporzionale alla potenziale pericolosità dell’attacco (scala da 1 a 3);gli allarmi in cui il valore del campo Priority è 1 sono i più più critici.

• 10/15-06:01:46.050056 è la data e l’ora dell’attacco effettuato il 15ottobre 2006 alle 06:01.

• 192.168.0.4 -> 192.168.0.3 indica gli indirizzi IP sorgente (192.168.0.4)e di destinazione (192.168.0.3).

• Le restanti informazioni riguardano le specifiche tecniche del protocolloutilizzato.

Terminata l’analisi di Snort, nel prossimo capitolo si esaminerà la suaimplementazione pratica all’interno di una rete.

53

CAPITOLO 4. CONFIGURAZIONE DEL NIDS

Capitolo 4

Configurazione del NIDS

4.1 Introduzione

Il compito principale di un NIDS è rilevare le attività non autorizzate chevengono compiute abusivamente all’interno di un sistema informatico.

Durante il lavoro di progettazione dell’Intrusion Detection System si sonotenuti in considerazione diversi requisiti, tra i quali:

• usabilità al fine di rendere comprensibili anche a tecnici non esperti irisultati prodotti dal sistema di intrusion detection;

• adattabilità a nuovi attacchi. A questo scopo gli aggiornamenti de-vono essere eseguiti in modo automatico e tempestivo, limitando lamanutenzione del sensore;

• ottimizzazione del rapporto qualità/prezzo allo scopo di ottenere lemigliori prestazioni utilizzando una macchina con risorse limitate.

Si è scelto, pertanto, di adottare esclusivamente software gratuiti, realizzatidalla comunità OpenSource e che presentano tutte le caratteristiche essenzialiper implementare un valido sistema di sicurezza.

Nel corso di questo capitolo, si analizzeranno le fasi fondamentali d’in-stallazione e configurazione di un Intrusion Detection System, completo di

55


interfaccia web, per la visualizzazione degli allarmi e per l’aggiornamentoautomatico delle regole. Per prima cosa verranno descritte le fasi di instal-lazione dei diversi software necessari per il funzionamento dell’IDS (vedi Ca-pitolo 4.3). Successivamente, verrà presentata la fase di test (vedi Capitolo4.4), e la fase di configurazione dei componenti necessari all’amministrazioneremota via SSH (vedi Capitolo 4.5). Per concludere, verranno presentate indettaglio le ottimizzazioni apportate alle regole di intrusion detection al finedi limitare i falsi positivi (vedi Capitolo 4.6).

4.2 Analisi del Sistema

Il lavoro di tesi, come detto, si è occupato della progettazione e dello svilup-po di un IDS, da integrare all’interno di una rete informatica già esistente,in grado di garantire un livello di sicurezza maggiore. A questo scopo, laconoscenza approfondita della rete e delle sue peculiarità diventa un requi-sito fondamentale per lo sviluppo di un’infrastruttura robusta ad attacchie tentativi di intrusione. Pertanto, prima di procedere alla configurazionedell’IDS si è valutato:

• il tipo risorse da proteggere, al fine di comprendere quali tipi di dativengono trattati e di capire quali sono i rischi che si corrono nel casoin cui venga infranta la loro integrità1, disponibilità2 e riservatezza3;

• il design e la topologia della rete, per individuare eventuali misure disicurezza già implementate, e la collocazione dei dati da proteggere;

• l’utilizzo di hub, switch o entrambi, per stabilire le modalità di imple-mentazione e il posizionamento dei sensori nella rete;

1Per integrità si intende la protezione dei dati nei confronti delle modifiche nonautorizzate del loro contenuto.

2Per disponibilità si intende la prevenzione da attacchi che mirano a rendere i dati nonaccessibili anche a coloro che ne hanno il diritto.

3Per riservatezza si intende la protezione dei dati scambiati tra due o più interlocutorial fine di evitare che terze parti vi possano accedere in modo non autorizzato.

56


Figura 4.1: Schema di rete prima dell’installazione del NIDS

• l’opportunità di visualizzare il traffico prima che venga filtrato dal fi-rewall, per valutare l’opportunità di rilevare anche i tentativi di attaccobloccati dal firewall stesso.

Il sistema di intrusion detection è stato implementato in una rete caratte-rizzata da un firewall perimetrale con tre interfacce: una per la rete interna,una per la rete esterna e una per la DMZ. In particolare, nella rete internasono stati collocati tutti gli host utilizzati dagli utenti per l’archiviazione el’elaborazione dei dati, nella DMZ sono stati inseriti i server web, SMTP,POP3 e un database ORACLE contenenti gli archivi dei dati, mentre la reteesterna è stata impiegata per collegare la rete interna e la DMZ ad Internet(vedi Figura 4.1). In una LAN di questo tipo, è evidente come il firewall nongarantisca alcuna protezione da attacchi provenienti dall’interno della rete;inoltre, nel caso in cui un intruso, che agisce all’esterno del firewall, riescaad aggirare il firewall, nessun log sul traffico di rete generato viene mantenuto.

Disponendo di una sola macchina per l’implementazione del sistema diintrusion detection, questa è stata configurata per agire contemporaneamen-te da sensore per le intrusioni, da database in cui archiviare i log generatidal sensore e da webserver per permettere che i log siano visibili tramite

57


Figura 4.2: Schema di rete dopo l’installazione del NIDS

interfaccia grafica. Uno dei problemi più critici da affrontare prima dellaconfigurazione di un NIDS è la scelta della sua posizione all’interno dellarete. Installare il sensore all’esterno del firewall non sembra la scelta piùopportuna, in quanto questa scelta lo esporrebbe ad attacchi provenientidall’esterno; dato che i dati da proteggere sono collocati nei database postinella DMZ si è quindi pensato di installare il sensore in questo segmento direte (vedi Figura 4.2).

Per l’installazione e la configurazione dell’Intrusion Detection System,inoltre, sono state identificate come necessarie le seguenti tecnologie, cheverranno analizzate in dettaglio nei prossimi capitoli.

• Il sistema operativo CentOS v4.4 (www.centos.org);

• Il software di intrusion detection Snort v2.6 (www.snort.org);

• Le regole di intrusion detection per Snort v2.6 (www.snort.org);

• Il server web Apache con supporto PHP (www.apache.org);

• Il server MySQL (www.mysql.org);

• L’Active Data Objects DataBase (http://adodb.sourceforge.net);

58


• Il Basic Analysis and Security Engine per permettere la visualizzazionegrafica dei log (http://secureideas.sourceforge.net);

• nTop (www.ntop.org) per analizzare e monitorare il traffico anomalo;

• Oinkmaster (http://oinkmaster.sourceforge.net) per aggiornareautomaticamente le regole (è richiesta la registrazione su www.snort.

org);

• Nmap (www.insecure.org/nmap) e Metasploit (www.metasploit.org)per il test dell’IDS;

• Un server SSH per permettere l’amministrazione remota dell’IDS;

• Un client SSH per amministrare l’IDS da remoto.

4.3 Setup del NIDS

La fase di setup di un IDS si compone di molteplici passi di configurazionedei diversi componenti utilizzati per lo sviluppo dell’IDS stesso.

4.3.1 Setup di CentOS v4.4

Primo passo nella configurazione di un IDS è la scelta del Sistema Operativoper la gestione delle risorse del sensore. Per questo lavoro di tesi, si è scelto ilsistema operativo CentOS v4.4[4] in quanto premette di avere una maggiorestabilità anche in realtà estese come quelle ‘enterprise’, più ampie delle co-muni reti domestiche. Per evitare di occupare risorse che potrebbero esserenecessarie al software di intrusion detection, è stata effettuata un’installa-zione minimale del Sistema Operativo, priva di interfaccia grafica. Inoltre,poichè il sistema viene gestito da riga di comando, si può fare a meno delsistema grafico X window 4[26].

4X Window System, ben noto in gergo come X11 o ancor più semplicemente X, è difatto il sistema grafico standard per tutti i sistemi Unix (Linux e BSD compresi)

59


Tuttavia, anche in caso di installazione minimale, non tutti i servizi in-stallati sono stati necessari per questo lavoro di tesi. In particolare, i servizinon necessari, quali ad esempio apmd che si occupa del risparmio energetico,cups che è il server di stampa, isdn che permette di effettuare connessionitramite modem ISDN, nfslock che permette ai client NFS di bloccare i filepresenti sul server, pcmcia che permette di rilevare l’eventuale inserimentoo l’estrazione di una scheda PCMCIA, portmap che converte i numeri deiprogrammi RPC nei numeri di porta del protocollo DARPA, sono stati disa-bilitati per migliorare le performance dell’infrastruttura mediante i seguenticomandi:

[root@localhost ~]# chkconfig apmd off

[root@localhost ~]# chkconfig cups off

[root@localhost ~]# chkconfig isdn off

[root@localhost ~]# chkconfig nfslock off

[root@localhost ~]# chkconfig pcmcia off

[root@localhost ~]# chkconfig pcmcia off

A questo punto è stato effettuato l’aggiornamento del sistema operativo:

[root@localhost ~]# yum -y update

e l’installazione dei servizi necessari:

[root@localhost ~]# yum -y install mysql

mysql-bench mysql-server mysql-devel mysqlclient10

php-mysql httpd gcc pcre-devel php-gd gd mod_ssl glib2-devel

gcc-c++

Una volta che il sistema è installato ed operativo, è necessario configurarele opzioni di rete, utilizzando il comando:

[root@localhost ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

60


In questo modo viene eseguito l’editor di testo vi, che permette di modi-ficare il contenuto del file ifcfg-eth0.

A questo punto si digitano le seguenti righe di codice personalizzate chepermettono di configurare la scheda di interfaccia di rete eth0.

DEVICE=eth0

ONBOOT=yes

BOOTPROTO=static

IPADDR=192.168.1.22

NETMASK=255.255.255.0

GATEWAY=192.168.1.1

HWADDR=00:0C:29:2B:60:6D

Nella precedente configurazione,

• DEVICE, indica il nome del dispositivo di rete fisico;

• ONBOOT, può essere configurato con le opzioni yes e no ed indica seil dispositivo è attivato all’avvio;

• BOOTPROTO, segnala se c’è un protocollo per l’assegnazione dell’in-dirizzo IP, e può essere configurato con le opzioni static se l’indirizzoIP della scheda di rete è statico, bootp se viene utilizzato il protocolloBOOTP, dhcp se viene utilizzato il protocollo DHCP;

• IPADDR, corrisponde all’indirizzo IP della scheda di rete; questa op-zione non va configurata nel caso in cui si utilizzano i protocolli DHCPo BOOTP per l’assegnazione dell’indirizzo IP;

• NETMASK, corrisponde al valore della maschera di rete;

• GATEWAY, corrisponde all’indirizzo IP del gateway di rete;

• HWADDR, corrisponde al MAC address della scheda di rete.

61


Il setup della rete continua e si conclude con la configurazione del serverDNS (Domain Name Server). Analogamente a quanto fatto precedentemente,si modifica il file /etc/resolv.conf inserendo la seguente riga di codice cheidentifica l’indirizzo IP del server DNS.

nameserver 192.168.1.10

Ovviamente, al posto di 192.168.1.10, va inserito l’indirizzo IP del rispet-tivo server DNS.La configurazione di rete è a questo punto terminata. Nel prossimo paragra-fo verrà descritta in dettaglio la configurazione del database MySQL e delserver web Apache.

4.3.2 Setup di Apache e MySQL

L’installazione di un server web e di un Database Management System (DBMS)5

è una fase necessaria che precede l’implementazione dell’interfaccia graficache sarà utilizzata per gestire gli allarmi generati dal software di intrusiondetection Snort. A tal proposito si è scelto di utilizzare Apache[2] che è lapiattaforma server Web più diffusa e MySQL[8] che è un DBMS relaziona-le, composto da un client e un server, utilizzabile sia in ambiente Unix cheWindows.

Prima di procedere alla configurazione del server web Apache e del serverMySQL è opportuno aggiungere al sistema un nuovo utente chiamato snortche non abbia i privilegi dell’utente root ma che possa compiere tutte leoperazioni necessarie al processo di intrusion detection.

[root@localhost ~]# groupadd snort

groupadd: group snort exists

[root@localhost ~]# useradd -g snort snort -s /sbin/nologin

5Un Database Management System è un sistema software che consente la creazione ela modifica di un database da parte di più utenti.

62


I servizi Apache e MySQL vengono, poi, avviati mediante i seguenticomandi:

[root@localhost ~]# chkconfig httpd on

[root@localhost ~]# chkconfig mysqld on

[root@localhost ~]# service httpd start

Avvio di httpd: [ OK ]

[root@localhost ~]# service mysqld start

Avvio di MySQL: [ OK ]

Per la configurazione del server web Apache è sufficiente modificare, inbase alle proprie esigenze, il file httpd.conf che si trova nella directory/etc/httpd/conf/ oppure nella directory /usr/local/apache/conf/ checontiene le direttive usate per la configurazione.

Le direttive principali che è necessario configurare sono:

• Listen che identifica la porta sul quale il server web sarà attivo;

Listen 80

• ServerName che identifica il nome del server web che può coinciderecon il nome della macchina o può essere un nome arbitrario;

ServerName new.host.name:80

• User e Group che identificano l’utente e il gruppo con i quali vieneeseguito il processo httpd : per ragioni di sicurezza è sempre opportunoutilizzare utenti che non hanno i privilegi dell’utente root come apacheo nobody ;

User apache

Group apache

63


• DocumentRoot che va configurata con la directory che conterrà i fileHTML da visualizzare;

DocumentRoot "/var/www/html"

• ServerRoot che definisce la directory di base di Apache;

ServerRoot "/etc/httpd"

• LoadModule utilizzata per caricare i moduli di Apache necessari al cor-retto funzionamento del server web: la configurazione di default integrai seguenti moduli:

LoadModule access_module modules/mod_access.so

LoadModule auth_module modules/mod_auth.so

LoadModule auth_anon_module modules/mod_auth_anon.so

LoadModule auth_dbm_module modules/mod_auth_dbm.so

LoadModule auth_digest_module modules/mod_auth_digest.so

LoadModule ldap_module modules/mod_ldap.so

LoadModule auth_ldap_module modules/mod_auth_ldap.so

LoadModule include_module modules/mod_include.so

LoadModule log_config_module modules/mod_log_config.so

LoadModule env_module modules/mod_env.so

LoadModule mime_magic_module modules/mod_mime_magic.so

LoadModule cern_meta_module modules/mod_cern_meta.so

LoadModule expires_module modules/mod_expires.so

LoadModule deflate_module modules/mod_deflate.so

LoadModule headers_module modules/mod_headers.so

LoadModule usertrack_module modules/mod_usertrack.so

LoadModule setenvif_module modules/mod_setenvif.so

LoadModule mime_module modules/mod_mime.so

LoadModule dav_module modules/mod_dav.so

LoadModule status_module modules/mod_status.so

64


LoadModule autoindex_module modules/mod_autoindex.so

LoadModule asis_module modules/mod_asis.so

LoadModule info_module modules/mod_info.so

LoadModule dav_fs_module modules/mod_dav_fs.so

LoadModule vhost_alias_module modules/mod_vhost_alias.so

LoadModule negotiation_module modules/mod_negotiation.so

LoadModule dir_module modules/mod_dir.so

LoadModule imap_module modules/mod_imap.so

LoadModule actions_module modules/mod_actions.so

LoadModule speling_module modules/mod_speling.so

LoadModule userdir_module modules/mod_userdir.so

LoadModule alias_module modules/mod_alias.so

LoadModule rewrite_module modules/mod_rewrite.so

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule proxy_connect_module modules/mod_proxy_connect.so

LoadModule cache_module modules/mod_cache.so

LoadModule suexec_module modules/mod_suexec.so

LoadModule disk_cache_module modules/mod_disk_cache.so

LoadModule file_cache_module modules/mod_file_cache.so

LoadModule mem_cache_module modules/mod_mem_cache.so

LoadModule cgi_module modules/mod_cgi.so

Terminata la configurazione del server web Apache si può passare allaconfigurazione e alla gestione amministrativa del database MySQL. Per primacosa, è necessario collegarsi al database con i privilegi di amministratoredell’utente root, e se non è stata precedentemente impostata una password,è opportuno configurarne una eseguendo il comando:

mysql> SET PASSWORD FOR root@localhost=PASSWORD(‘password’);

Query OK, 0 rows affected (0.03 sec)

65


Si procede, poi, con la creazione vera e propria di un nuovo database,chiamato ‘snort’, che si occuperà di memorizzare i log generati dal softwaredi intrusion detection.

mysql> create database snort;

Query OK, 1 row affected (0.00 sec)

Si impostano quindi i privilegi e la password di accesso dell’utente snort.

mysql> grant insert,select on root.* to snort@localhost;


mysql> SET PASSWORD FOR snort@localhost=PASSWORD(‘password’);


mysql> grant create,insert,select,delete,update on

snort.* to snort@localhost;


mysql> grant create,insert,select,delete,update on

snort.* to snort;


mysql> exit

Bye

Per creare le tabelle del database si effettua, successivamente, il down-load dell’archivio all’interno del quale è presente il file create_mysql. Sidecomprime, quindi, nella diretory /etc/snort/ il file create_mysql, con-tenente i comandi per la generazione delle tabelle. Tale file è contenuto nellasubdirectory /schemas/ dell’archivio snort-2.6.0.2.tar.gz, scaricabile dawww.snort.org.

La creazione delle tabelle avviene con il seguente comando che esegue, asua volta, i comandi contenuti nel file create_mysql:

66


[root@localhost ~]#

mysql -u root -p < /etc/snort/create_mysql snort

Enter password:

Prima di creare le tabelle sarà richiesta la password di accesso al databasedell’utente root. Dopo aver inserito la password, sarà portata a terminel’importazione delle tabelle e sarà, quindi, opportuno controllare che tuttosia stato compiuto correttamente tramite il seguente brano di codice:

[root@localhost ~]# mysql -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 6 to server version: 4.1.20

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

A questo punto, il server MySQL contiene tre database: ‘mysql’, ‘snort’e ‘test’. Per visualizzare il contenuto del server MySQL basta digitare ilcomando show databases e sullo schermo comparirà il seguente output:

mysql> show databases;

+----------+

| Database |

+----------+

| mysql |

| snort |

| test |

+----------+

3 rows in set (0.00 sec)

A questo punto selezionando il database ‘snort’, si possono visualizzarele tabelle in esso contenute.

mysql> use snort

67


Dopo aver verificato che tutto sia stato portato a termine con successo èpossibile terminare la configurazione del server MySQL.

A questo punto, l’installazione e configurazione di Snort, che sarà trattatanel prossimo paragrafo, può cominciare.

4.3.3 Setup di Snort v2.6

Il software di intrusion detection Snort e le sue regole, possono essere sca-ricate dal sito ufficiale www.snort.org. Dopo aver installato il program-ma e decompresso le regole nella cartella /etc/snort/, la configurazione diSnort può avere inizio aprendo il file /etc/snort/snort.conf contenente leimpostazioni di default.

[root@localhost ~]# vi /etc/snort/snort.conf

In aggiunta alle suddette regole di default devono essere specificati i datirelativi alla Home Network e agli indirizzi IP dei server.

## var HOME_NET [172.20.1.0/24,192.168.1.0/24]

var HOME_NET 192.168.1.0/16

var EXTERNAL_NET !\$HOME_NET

# Configure your server lists. This allows snort to only look for

# attacks to systems that have a service up. Why look for HTTP

# attacks if you are not running a web server? This allows quick

# filtering based on IP addresses

# These configurations MUST follow the same configuration

# scheme as defined

# above for \$HOME_NET.

# List of DNS servers on your network

var DNS_SERVERS \$HOME_NET

69


# List of SMTP servers on your network

var SMTP_SERVERS \$HOME_NET

# List of web servers on your network

var HTTP_SERVERS \$HOME_NET

# List of sql servers on your network

var SQL_SERVERS \$HOME_NET

# List of telnet servers on your network

var TELNET_SERVERS \$HOME_NET

# List of snmp servers on your network

var SNMP_SERVERS \$HOME_NET

È inoltre necessario configurare la porta sulla quale è attivo il server web,

var HTTP_PORTS 80

il percorso della directory contenente le regole,

var RULE_PATH /boot/etc/rules

e la stringa che comunica a Snort di memorizzare gli eventi nel databaseMySQL

output database: log, mysql, user=snort password=snort

dbname=snort host=localhost

Fatto questo, Snort è funzionante ma non è ancora possibile visualizzarel’output degli eventi tramite un’interfaccia HTML.

Per eseguire Snort è sufficiente portarsi nella directory /usr/sbin/, edeseguire il seguente comando:

70


[root@localhost sbin]# ./snort -dev -l /var/log/snort -b

-h 192.168.1.1/16 -c /etc/snort/snort.conf

Se tutto è andato a buon fine, l’output visualizzato sarà:

Running in IDS mode

--== Initializing Snort ==--

Initializing Output Plugins!

Initializing Preprocessors!

Initializing Plug-ins!

Parsing Rules file /etc/snort/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++

--== Initialization Complete ==--

,,_ -*> Snort! <*-

o" )~ Version 2.6.0 (Build 59)

’’’’ By Martin Roesch & The Snort Team:

http://www.snort.org/team.html

(C) Copyright 1998-2006 Sourcefire Inc., et al.

È anche possibile avviare Snort in modalità daemon6 aggiungendo l’op-zione -D.


-h 192.168.1.1/16 -c /etc/snort/snort.conf -D

Snort è anche capace di funzionare in modalità Sniffer:

[root@localhost sbin]# ./snort -dev6Nei sistemi operativi Unix-like, un processo avviato in modalità daemon viene eseguto

in background senza che l’utente possa interagire con esso o possa visualizzarne l’output.

71


o in modalità Packet Logger:


Sino a questo punto sono stati trattati la configurazione di Snort, del ser-ver web Apache e del database MySQL. Nel prossimo paragrafo verranno esa-minati alcuni componenti aggiuntivi che offrono un’interfaccia più amichevolea livello utente per la consultazione degli eventi generati da Snort.

4.3.4 Setup di AdoDB e BASE

Per interagire con diversi tipi di database senza dover scrivere query spe-cifiche per ogni database, ma utilizzando query SQL standard, si utilizzail componente AdoDB[1] (Active Data Objects DataBase) che va installatonella directory /var/www.

Per analizzare tramite un’interfaccia HTML, gli allarmi generati da Snortsi installa, invece, il Basic Analysis and Security Engine nella directory /var/

www/html.A questo punto è opportuno rinominare prima la directory del componen-

te BASE[3] /base-1.2.6 in /base (questo semplicemente per semplificare leoperazioni successive) e poi il file base_conf.php.dist in base_conf.php.Si modificano quindi, nel seguente modo, alcuni parametri nel file base_

conf.php.

\$BASE_urlpath = ‘/base’;

\$DBlib_path = ‘/var/www/adodb’;

\$DBtype = ‘mysql’;

\$alert_dbname = ‘snort’;

\$alert_host = ‘localhost’;

\$alert_port = ‘’;

\$alert_user = ‘snort’;

\$alert_password = ‘password’;

72


Se tutto è andato a buon fine, accedendo per mezzo di un browser allapagina https://192.168.1.22/base si potrà visualizzare il seguente mes-saggio:

The database version is valid, but the BASE DB structure

(table: acid_ag)is not present. Use the ‘Setup page’ to

configure and optimize the DB.

Si procede, così, alla configurazione del Basic Analysis and Security En-gine, cliccando prima su ‘Setup page’ e nella pagina che segue su ‘CreateBASE AG’. L’output visualizzato è:

Successfully created ‘acid_ag’

Successfully created ‘acid_ag_alert’

Successfully created ‘acid_ip_cache’

Successfully created ‘acid_event’

Successfully created ‘base_roles’

Successfully INSERTED Admin role

Successfully INSERTED Authenticated User role

Successfully INSERTED Anonymous User role

Successfully INSERTED Alert Group Editor role

Successfully created ‘base_users’

Operation Description Status

BASE tables Adds tables to extend the Snort DB to support the

BASE functionality DONE

Il Basic Analysis and Security Engine e l’interfaccia HTML per la visua-lizzazione grafica degli eventi di Snort sono adesso funzionanti.

È tuttavia opportuno proteggere la directory di BASE da password.

[root@localhost base]# mkdir /var/www/passwords

73


[root@localhost www]#

/usr/bin/htpasswd -c /var/www/passwords/passwords base

New password:

Re-type new password:

Adding password for user base

È quindi necessario modificare il file /etc/httpd/conf/httpd.conf, ag-giungendo sotto la sezione

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

le seguenti stringhe:

<Directory "/var/www/html/base">

AuthType Basic

AuthName "SnortIDS"

AuthUserFile /var/www/passwords/passwords

Require user base

</Directory>

Infine, il server Apache deve essere riavviato con il seguente comando:

[root@localhost /]# service httpd restart

Interruzione di httpd: [ OK ]

Avvio di httpd: [ OK ]

A questo punto, dopo aver inserito la password di accesso nel pannello dicontrollo, la pagina https://192.168.1.22/base visualizzerà la schermataprincipale di BASE (vedi Figura 4.3). Nel pannello di controllo si può sceglie-re se visualizzare gli allarmi più recenti o quelli più frequenti e raggrupparliin base alla porta sorgente o di destinazione o in base al protocollo utilizza-to. Per ogni evento è possibile, inoltre, visualizzare innumerevoli dettagli edeseguire il download del payload del pacchetto che l’ha generato (vedi Figura4.4).

74


Figura 4.3: Schermata principale di BASE

75


Figura 4.4: Schermata dettagli di BASE

76


Riguardo ciascun allarme è possibile conoscere:

• l’id;

• il sensore che l’ha generato;

• la data e l’orario della segnalazione;

• il nome del potenziale attacco;

• i riferimenti dai quali reperire maggiori informazioni sui dettagli e lapericolosità dell’attacco;

• gli indirizzi IP sorgente e di destinazione dell’attacco;

• il protocollo utilizzato con le rispettive specifiche;

• il payload del pacchetto.

L’interfaccia web creata, incrementa notevolmente la facilità di consulta-zione degli eventi e si integra totalmente con Snort, tanto da sembrare unostrumento unico. Nel prossimo paragrafo sarà esaminato nTop, uno stru-mento che permette di sfruttare il server web e il database per esaminare iltraffico di rete.

4.3.5 Setup di nTop

Per mezzo di nTop[10] si può monitorare e analizzare il traffico generatodai diversi protocolli. Per quanto riguarda la sua configurazione, è neces-sario creare nella directory /etc/yum.repos.d un file chiamato dag.repo

contenente le seguenti stringhe:

[dag] name=Dag RPM Repository for Red Hat Enterprise Linux

baseurl=http://apt.sw.be/redhat/el\$releasever/en/\$basearch/dag/

gpgcheck=1

enabled=1

77


ed importare la chiave GPG7:

[root@localhost ~]# rpm --import http://dag.wieers.com/

packages/RPM-GPG-KEY.dag.txt

L’installazione è, successivamente, avviata per mezzo del comando:

[root@localhost ~]# yum install ntop

A questo punto è necessario permettere l’interazione del server web connTop sulla porta 3001 con protocollo HTTPS. Per questo motivo, si deveconfigurare nTop modificando il file /etc/ntop.conf, verificando che la porta3001 sia associata al server HTTPS,

#--http-server 3000

--https-server 3001

ed accertandosi che la stringa che permette di far partire nTop in modalitàdaemon sia commentata:

#--daemon

Dopo l’impostazione della password,

[root@localhost etc]# /usr/bin/ntop @/etc/ntop.conf -A

Processing file /etc/ntop.conf for parameters...

Wed Oct 11 12:21:10 2006 NOTE: Interface merge enabled by

default

Wed Oct 11 12:21:10 2006 Initializing gdbm databases

ntop startup - waiting for user response!

Please enter the password for the admin user:

Please enter the password again:

Wed Oct 11 12:21:18 2006 Admin user password has been set7GPG è un software cifratura asimettrica per la criptazione di messaggi, documenti e

file che agisce utilizzando una coppia di chiavi (pubblica e privata) che vengono scambiatetra gli utenti. Particolare attenzione va prestata alla corrispondenza tra chiave e (presunta)identità: se non può essere certificata l’autenticità della chiave, non si può avere la certezzadella provenienza del documento.

78


nTop è pronto per essere avviato in modalità daemon. A tal scopo si puòeliminare il commento, inserito in precedenza, dalla seguente stringa

--daemon

e far partire il servizio:

[root@localhost etc]# chkconfig ntop on

[root@localhost etc]# service ntop start

Starting ntop: [ OK ]

In questo modo nTop è raggiungibile all’indirizzohttps://192.168.1.22:3001 dove 192.168.1.22 è l’indirizzo IP dell’IDS.

Dopo questa panoramica sugli strumenti che permettono l’analisi e il monito-raggio della rete verrà esaminato nel prossimo paragrafo un altro strumentoche permette di automatizzare il download delle regole di intrusion detectionaggiornate, OinkMaster.

4.3.6 Setup di OinkMaster

Oinkmaster[11] è uno script scritto in linguaggio Perl che effettua il downloadautomatico delle regole aggiornate disponibili su www.snort.org. L’utilizzogratutito di OinkMaster è vincolato alla registrazione di un account su www.

snort.org.Prima di procedere can la configurazione di OinkMaster, si deve modi-

ficare l’utente proprietario della directory contenente le regole di Snort perpoter permettere a OinkMaster di modificare i file in essa contenuti:

[root@localhost /]# chown -R snort:snort /etc/snort/rules

Si effettua, quindi, il download e l’installazione di OinkMaster. Nelladirectory /etc viene creato il file oinkmster.conf che va configurato con unURL valido utilizzato da OinkMaster per effettuare il download delle regoleaggiornate. Ogni URL avrà una struttura di questo tipo:

79


http://www.snort.org/pub-bin/oinkmaster.cgi/

<codice oinkmaster>/<file regole>

mentre un esempio di URL valido potrebbe essere il seguente:

http://www.snort.org/pub-bin/oinkmaster.cgi/

397c07dd8761ea56d9c8115ca2b6c13cd7790ea3/

snortrules-snapshot-2.4.tar.gz

OinkMaster è quindi pronto per essere avviato mediante il seguente co-mando che esegue lo script oinkmaster.pl in base alle configurazioni stabitenei file /etc/oinkmaster.conf e /etc/autodisable.conf. Il comando sioccupa inoltre di scrivere le nuove regole nella directory /boot/etc/rules:

[root@localhost etc]# oinkmaster.pl -C /etc/oinkmaster.conf

-C /etc/autodisable.conf -o /boot/etc/rules

Una delle caratteristiche che rende OinkMaster, un componente fonda-mentale per un sistema di intrusion detection è la possibilità di automatiz-zarne alcune fuzionalità. A questo scopo, si crea nella cartella /etc un filedi testo chiamato snort-oinkmaster che conterrà il codice per l’esecuzionedi OinkMaster,

#! /bin/bash

/usr/bin/oinkmaster.pl -C /etc/oinkmaster.conf

-C /etc/autodisable.conf -o /etc/snort/rules

e si impostano sul file snort-oinkmaster i privilegi di esecuzione:

[root@localhost etc]# chmod 755 snort-oinkmaster

In questo modo per avviare OinkMaster sarà sufficiente eseguire il pro-gramma snort-oinkmaster.

Spostando il programma snort-oinkmaster nella cartella /etc/cron.

daily si attiverà quotidianamente l’aggiornamento delle regole:

[root@localhost etc]# mv snort-oinkmaster cron.daily/

80


Nella cartella /cron.daily risiedono, infatti, i file che il sistema esegueogni ventiquattro ore. Aprendo il file /etc/crontab è possibile visualizzarel’ora esatta in cui tali file verranno eseguiti.

Il file /etc/crontab contiene infatti una stringa di questo tipo:

02 4 * * * root run-parts /etc/cron.daily

che informa che alle 4.02 di ogni giorno saranno eseguiti tutti i file nelladirectory /etc/cron.daily.La sintassi della stringa è relativamente semplice. La prima colonna indica iminuti (0-59), la seconda le ore (1-23), la terza il giorno (1-31), la quarta ilmese (1-12), la quinta il giorno della settimana (0-7 dove 7 corrisponde alladomenica). Il carattere ‘*’ significa che tutti i valori del rispettivo camposono validi.

Con OinkMaster si completa la realizzazione e configurazione del sistemadi intrusion detection. A questo punto non resta che testarne il funziona-mento.

4.4 Test del NIDS: i Risultati

Il test dell’IDS è stato diviso in due fasi principali. Nella prima fase di testè stato utilizzato il tool Nmap per rilevare eventuali scansioni delle porte(Paragrafo 4.4.1), mentre nella seconda è stato utilizzato il tool Metasploitper rilevare attacchi basati sull’esecuzione di exploit (Paragrafo 4.4.2).

4.4.1 Test con Nmap

Dopo un’attenta analisi dei tool Open Source in grado di eseguire scansionidelle porte, Nmap[9] è risultato il tool più completo in grado di eseguirediversi tipi di scansioni, di frammentare i pacchetti nel tentativo di aggiraregli IDS e di mantenere parzialmente l’anonimità mediante una tecnica dettaDecoy Scan descritta in seguito. Nel corso di questo capitolo si procederàall’analisi dettagliata dei test eseguiti in questo lavoro di tesi.

81


TCP Connect() Scan

La prima scansione eseguita è stata il TCP Connect() Scan, un tipo di scan-sione in cui la chiamata di sistema connect() fornita dal Sistema Operativodi chi effettua la scansione, è usata per aprire una connessione ad ogni por-ta interessante sulla macchina di destinazione. In questo tipo di scansione,l’attaccante invia alla vittima un pacchetto TCP con flag SYN attivo. Sela porta obiettivo della scansione risulterà aperta, l’attaccante riceverà inrisposta un pacchetto TCP con i flag SYN e ACK attivi a cui risponderàcon un pacchetto TCP con flag ACK attivo, altrimenti se la porta risulteràchiusa, riceverà un pacchetto TCP con flag RST attivo che terminerà la con-nessione. In altre parole, se la porta vittima della scansione è in ascolto, lachiamata di sistema connect() avrà luogo e l’handshake verrà completato, incaso contrario la porta non sarà raggiungibile.

Il TCP Connect() Scan si esegue mediante il seguente comando:

[root@localhost ~]# nmap -sT 192.168.1.22

Snort rileva i pacchetti inviati per effettuare la scansione e pertanto generai seguenti allarmi:

• (portscan) TCP Portscan: 304:61441

Il preprocessore sfPortscan rileva il traffico anomalo e identifica la scan-sione delle porte che costituisce la prima fase di un attacco la quale nondanneggia la vittima ma permette di ottenere innumerevoli informazio-ni su di essa. Tali informazioni potranno essere sfruttate in seguito perdanneggiare il sistema o assumerne il controllo. I numerosi tool presen-ti in rete che realizzano i Portscan, rendono la scansione delle porte unattacco alla portata di chiunque. Tutti i sistemi sono soggetti a questotipo d’attacco e non sono conosciuti falsi positivi in merito.

• (portscan) Open Port: 80

Il preprocessore sfPortscan rileva una porta aperta corrispondente ad

82


un servizio attivo sulla vittima. Questo indica la probabilità che unattaccante sia alla ricerca di vulnerabilità sulla vittima. I sistemivulnerabili sono analoghi a quelli discussi per il precedente allarme.

SYN Scan

Un attacco analogo al TCP Connect() Scan è il SYS Scan. La differenza tra idue attacchi consiste nel fatto che nel SYS Scan l’handshake non viene com-pletato. L’attaccante invia, quindi, un pacchetto TCP con flag SYN attivo,se la porta da controllare è aperta riceverà in risposta un pacchetto TCP coni flag SYN e ACK attivi al quale Nmap risponderà chiudendo la connessionecon un pacchetto TCP con flag RST attivo. Se la porta è chiusa, l’attaccantericeverà un pacchetto TCP con flag RST attivo che chiuderà la connessione.In entrambi i casi, la connessione non verrà mai completata e per questaragione difficilmente comparirà nei file di log, anche se generalmente vienericonosciuta e registrata dagli IDS.

Il SYS Scan si esegue mediante il seguente comando:

[root@localhost ~]# nmap -sS 192.168.1.22

Gli allarmi generati da Snort saranno analoghi a quelli prodotti per ilTCP Connect() Scan già descritti precedentemente:


Viene generato per qualsiasi attività di scanning.


Segnala una possibile situazione di pericolo dovuta ad una porta trovataaperta.

FIN Scan

Il FIN Scan ha delle sostanziali differenze rispetto alle scansioni analizza-te precedentemente. L’attacco è caratterizzato dall’invio di pacchetti TCP

83


anomali, alle porte della vittima, aventi solo il flag FIN attivo. Le specifichetecniche dalla RFC 793[28] prevedono che un host che riceve un pacchet-to con flag FIN attivo, nel caso in cui la porta sia chiusa, risponda con unpacchetto con flag RST attivo, nel caso in cui la porta sia aperta, ignori ilpacchetto. Da evidenziare che alcuni sistemi come Windows, Cisco, HP-UX,IRIX non seguono lo standard e rispondono inviando in qualsiasi caso unpacchetto TCP con flag RST attivo rendendo la scansione inefficace.Il FIN Scan si esegue mediante il seguente comando:

[root@localhost ~]# nmap -sF 192.168.1.22

A questo tipo di traffico, Snort reagisce generando i seguenti allarmi:


Trattandosi di un’attività di scansione, anche nei casi di FIN Scan vienegenerato un allarme che segnala l’esecuzione di un TCP Portscan.


Viene riconosciuta una porta aperta.

• SCAN FIN

Viene identificato un pacchetto TCP con il solo flag FIN attivo. Isistemi affetti da questo tipo di attacco sono quelli che rispettano laRFC 793. Non sono conosciuti casi di falsi positivi riguardanti questoallarme.

XMAS Scan

Questo tipo di scansione è analoga al FIN Scan con la differenza che i pac-chetti TCP inviati hanno attivi i flag FIN, URG, e PSH. Analoghi sono iproblemi relativi al rispetto della RFC 793.L’XMAS Scan si esegue mediante il seguente comando:

[root@localhost ~]# nmap -sF 192.168.1.22

Ancora una volta Snort risulta efficace e genera i seguenti allarmi:

84



Si presenta in quanto l’attacco portato a termine è una scansione.


Viene riconosciuta una siutazione di pericolo dovuta ad una portaaperta.

• SCAN nmap XMAS

Individua la scansione XMAS e rileva Nmap come programma con cuipotrebbe essere stata effettuata. Tipicamente la vittima, nel caso incui la porta a cui è stato inviato il pacchetto sia chiusa, risponderà conun pacchetto TCP con flag ACK e RST attivi, nel caso in cui la portasia aperta, non invierà alcuna risposta. Tutti i sistemi sono vulnerabilia questo tipo di scansione e non sono conosciuti casi di falsi positivi inquanto i flag FIN, PSH e URG dei pacchetti TCP, non sono mai statiattivi contemporaneamente nel normale traffico TCP, ad eccezione delcaso in cui la scansione venga realizzata con un tool diverso da Nmap.

UDP Scan

L’UDP Scan è una scansione utilizzata per rilevare quali sono i servizi attivisul protocollo UDP. Tipicamente la vittima, nel caso in cui la porta attaccatasia aperta non invierà risposta alcuna, nel caso in cui sia chiusa, invierà unpacchetto ICMP Port Unreachable.

L’UDP Scan si avvia mediante il seguente comando:

[root@localhost ~]# nmap -sU 192.168.1.22

L’allarme generato da Snort è il seguente:

• (portscan) UDP Portscan: 477:7000

Il preprocessore sfPortscan rileva una scansione delle porte UDP allaricerca di servizi attivi su questo protocollo. Tutti i sistemi sono vul-nerabili a questo tipo di attacco, che combinato con altri attacchi può

85


permettere, di rilevare anche il Sistema Operativo utilizzato dalla vit-tima. Analogamente a quanto avviene per il TCP Portscan non sonoconosciuti falsi positivi.

IP Protocol Scan

Questo tipo di scansione, permette di determinare quali sono i protocolli sup-portati dalla macchine a cui la scansione è indirizzata.

L’IP Protocol Scan si avvia mediante il seguente comando:

[root@localhost ~]# nmap -sO 192.168.1.22

Rilevando traffico anomalo, Snort genera i seguenti allarmi:

• (portscan) IP Protocol Scan

Segnala una scansione effettuata nel tentativo di rilevare i protocollisupportati dalla vittima.

• ICMP PING NMAP

Viene rilevato un ICMP Ping realizzato con Nmap. Può indicare che èin corso una completa scansione del sistema alla ricerca di vulnerabilità.Casi di falsi positivi possono essere rilevati qualora l’ICMP Ping vienegenerato da un altro tool.

• BAD-TRAFFIC Unassigned/Reserved IP protocol

Questo allarme viene generato quando in rete viene identificato un pac-chetto che utilizza un protocollo non supportato o riservato. Questonon dovrebbe accadere in circostanze normali.

Decoy SYS Scan

Il Decoy Scan è una variante applicabile a tutte le precedenti scansioni chepermette di rimanere parzialmente anonimi che nel nostro caso è stata inte-grata al SYS Scan. Nel comando di Nmap che implementa l’attacco, è pos-

86


sibile specificare altri indirizzi IP dai quali sembrerà provenire la scansionein questo modo:

[root@localhost ~]# nmap -sS 192.168.1.22 -D 1.1.1.1,2.2.2.2

L’indirizzo IP dell’attaccante sarà comunque visibile alla vittima e l’out-put di Snort sarà analogo a quello generato per una qualsiasi scansione,con la differenza che la provenienza dei pacchetti sospetti sarà costituita siadall’indirizzo IP dell’attaccante che da quelli indicati dopo l’opzione -D delcomando Nmap eseguito. Inserendo dopo l’opzione -D un numero elevato diindirizzi IP, sarà possibile nascondere il reale indirizzo IP dell’attaccante.

SYN Scan con Frammentazione

Nel tentativo di non far rilevare a Snort la scansione, la frammentazione deipacchetti è stata implementata insieme alla scansione SYS Scan. Ne consegueche il seguente comando ha gli stessi effetti di un normale SYN Scan con ladifferenza che i pacchetti vengono frammentati:

[root@localhost ~]# nmap -sS -f 192.168.1.22

Il test presentato, tuttavia, non ha avuto successo in quanto la scansionenon ha rilevato le porte aperte e di conseguenza Snort non ha generato allarmidi alcun tipo.

TCP Connect() Scan con Frammentazione

Il test è stato quindi ripetuto implementando la frammentazione dei pacchettial TCP Connect() Scan, mediante il seguente comando:

[root@localhost ~]# nmap -sT -f 192.168.1.22

Altrettanto scarso è stato il successo di questo test in quanto le porteaperte vengono rilevate correttamente, ma Snort rileva l’attacco generandogli stessi allarmi descritti per il TCP Connect() Scan.

87


Nonostante, complessivamente, Nmap si sia rivelato un tool particolarmenteadatto alla fase di testing perchè in grado di gestire scansioni di vario tipo,esso non è sufficiente ad eseguire un testing completo ed intensivo dell’IDS.Il secondo tool utilizzato per completare la fase di test è, quindi, Metasploit(www.metasploit.org), uno strumento utile ad analizzare le vulnerabilitàdei sistemi e funzionante sia da console che tramite interfaccia web.

4.4.2 Test con Metasploit

Metasploit[7] oltre ad essere uno strumento per eseguire exploit già cono-sciuti che permettono di sfruttare vulnerabilità e di acquisire in maniera nonautorizzata dei privilegi sulla macchina obiettivo di un attacco, è anche unambiente completo per scrivere, testare e usare codici maliziosi[18]. Esso for-nisce una solida piattaforma di ricerca di vulnerabilità, utilizzabile non soloallo scopo di testare un Intrusion Detection System ma anche per eseguiredei Penetration Test. Dopo aver installato il programma, l’interfaccia web siavvia nel modo seguente:

[root@localhost msf]# ./msfweb

+----=[ Metasploit Framework Web Interface (127.0.0.1:55555)

A questo punto dall’indirizzo http://127.0.0.1:55555 si accede al pan-nello di controllo di Metasploit (vedi Figura 4.5), e si seleziona, un exploit edun payload che Metasploit provvederà ad inviare alla vittima (vedi Figura4.6).

Di rilevante importanza è il fatto che Metasploit, prima di inviare i pac-chetti contenente codice malizioso, controlla che la porta con cui si cercadi stabilire una connesione sia aperta. Snort rileverà tale condotta comePortscan e produrrà di conseguenza un allarme. Se la porta risulterà chiusaMetasploit non eseguirà l’attacco e Snort non produrrà alcun allarme.Di seguito si esamineranno gli exploit eseguiti in questo lavoro di tesi pertestare il corretto funzionamento di Snort.

88


Figura 4.5: Pannello di controllo di Metasploit

89


Figura 4.6: Esempio di exploit e payload inviati tramite Metasploit

90


AWStats configdir Remote Command Execution

(Irix Inetd Bind Shell)

AWStats (http://awstats.sourceforge.net) è un tool Open Source uti-lizzato per analizzare i log generati da un server web e per produrre dellestatistiche sul suo utilizzo.

Dopo aver eseguito l’exploit, seguendo le istruzioni descritte in preceden-za, Snort riconosce il traffico come anomalo e genera il seguente allarme.

• WEB-CGI awstats access

L’allarme segnala un tentativo di accedere al CGI script awstats.pl.Il rischio che si corre, è l’esecuzione di comandi arbitrari sul server webdovuta al fatto che un attaccante può iniettare codice a sua discrezionesfruttando la vulnerabilità dello script awstats.pl. I sistemi vulnera-bili a questo tipo d’attacco sono quelli su cui è installato il tool Awstatsversione 6.1 e precedenti.

IIS 5.0 WebDAV ntdll.dll Overflow

(win32_bind)

Questo exploit ha come obiettivo i server Windows IIS 5.0 con WebDAV(Web-based Distributed Authoring and Versioning) che è un protocollo chepermette di gestire il contenuto di una directory di un server remoto.Dopo aver eseguito l’exploit Snort genera i seguenti allarmi:

• (http_inspect) OVERSIZE REQUEST-URI DIRECTORY

Il preprocessore http_inspect identifica il traffico anomalo come un at-tacco in quanto è stata riscontrata una richiesta /cgi-bin/, costituitada un URL contenente approssimativamente 330 caratteri Unicode, chepuò causare un DoS del server. Un attaccante può anche inviare unURI di questa dimensione nel tentativo di evadere un IDS.

• WEB-MISC WebDAV search access

Viene identificato un tentativo di utilizzo improprio dell’applicazione

91


WebDAV. IIS 5.0, include un’implementazione di WebDAV vulnerabilea questo tipo di attacco che può essere sfruttata dall’attaccante per ot-tenere un elenco completo delle directory contenute nella root directoryo per causare un Denial of Service (DoS) del server.

phpBB viewtopic.php Arbitrary Code Execution

(cmd_unix_reverse)

PhpBB presenta una vulnerabilità contenuta nello script viewtopic.php,che permette ad un attaccante di iniettare codice SQL arbitrario nel serverweb.Riconoscendo un accesso al file viewtopic.php Snort genera il seguenteallarme:

• WEB-PHP viewtopic.php access

Viene riconosciuto il tentativo di sfruttare la vulnerabilità descritta diphpBB. L’attaccante può sfruttare questo attacco per poter ottenerepassword e altre informazioni contenute nel database. I sistemi vulne-rabili sono quelli su cui è installato phpBB Group e phpBB versioni2.0.4 e 2.0.5.

IA WebMail 3.x Buffer Overflow

(win32_exec)

L’IA Webmail è una comoda interfaccia per la gestione della posta via web.Il problema di questa applicazione consiste in una cattiva gestione delle ri-chieste HTTP GET generalmente utilizzate per ottenere il contenuto dellepagine HTML. La sua vulnerabilità può essere sfruttata per causare un Over-flow di Buffer che permette di eseguire codice arbitrario sul server.Snort, ancora una volta, rileva il tentativo d’attacco e genera i seguentiallarmi:

• (http_inspect) BARE BYTE UNICODE ENCODING

Il preprocessore http_inspect rileva traffico anomalo che può costituire

92


un attacco. La vulnerabilità consiste in una anomala codifica dei ca-ratteri UTF-8 la quale può essere sfruttata per portare a termine unattacco verso un server IIS o per evadere un IDS.

• (http_inspect) OVERSIZE REQUEST-URI DIRECTORY

Anche in questo caso, analogamente a quanto visto per il precedenteexploit, viene identificato un pacchetto contenente un URI costituitoda un numero eccessivo di caratteri Unicode tale da presentare il rischiodi Denial of Service. Casi di falsi positivi posono identificarsi qualoragli utenti di una rete utilizzino in maniera autorizzata applicativi chegenerano richieste HTTP composte da più di 300 caratteri Unicode.

vBulletin misc.php Template Name Arbitrary Code Execution

(cmd_irix_bind)

vBulletin è un pacchetto che permette di installare un forum completamentepersonalizzabile su un sito web. La vulnerabilità è stata riscontrata nel filemisc.php che permette di iniettare ed eseguire codice PHP arbitrario sulserver. In questo caso il test dell’IDS ha fallito in quanto, dopo aver eseguitol’exploit, Snort non ha rilevato l’attacco ma ha riconosciuto il traffico comeaffidabile.

Dall’analisi effettuata, risulta che su quattordici attacchi diversi, uno di que-sti, il SYS Scan con Frammentazione, non è stato eseguito con successo inquanto Nmap non è riuscito ad inviare correttamente i pacchetti frammen-tati; un’altro di questi, il vBulletin misc.php Template Name Arbitrary CodeExecution non è stato per nulla rilevato da Snort che ritiene affidabile ilcontenuto dei pacchetti generati per questo attacco. I restanti 12 attacchisono stati tutti rilevati da Snort anche se sono stati individuati 3 casi pos-sibili di falsi positivi. I primi due relativi agli allarmi SCAN nmap XMASe ICMP PING NMAP in cui Snort potrebbe generare questi allarmi anchese gli attacchi sono stati realizzati mediante tool diversi da Nmap. L’ultimofalso positivo, di cui si tornerà a parlare nel Paragrafo 4.6, è relativo all’al-

93


larme OVERSIZE REQUEST-URI DIRECTORY generato sia dall’attaccoIIS 5.0 WebDAV ntdll.dll Overflow che dall’attacco IA WebMail 3.x BufferOverflow ; in questo caso il falso positivo si riscontrerebbe qualora gli utentidella rete fossero autorizzati ad utilizzare applicazioni che generano richiesteHTTP contenenti più di 300 caratteri Unicode le quali sarebbero interpretateda Snort come traffico anomalo.

Complessivamente sia gli attacchi effettuati con Nmap che quelli implemen-tati con Metasploit hanno dimostrato l’efficacia di Snort nel rilevamento delleintrusioni. Tuttavia, l’attacco vBulletin misc.php Template Name ArbitraryCode Execution è sufficiente per dimostrare la non infallibilità degli strumen-ti di intrusion detection.

Di seguito sono riportate due tabelle riassuntive riguardo gli attacchi eseguiticon Nmap (Tabella 4.1) e con Metasploit (Tabella 4.2), gli eventi generatiper ciascun attacco e i casi possibili di falsi positivi. Successivamente nelparagrafo seguente, si esaminerà l’utilizzo di un sistema client/server SSH dautilizzare per l’amministrazione remota dell’IDS.

94


Attacco Evento Generato Falsi Positivi

TCP Connect() Scan TCP PortscanOpen Port

SYN Scan TCP PortscanOpen Port

FIN Scan TCP PortscanOpen PortSCAN FIN

XMAS Scan TCP PortscanOpen PortSCAN nmap XMAS XMAS scan eseguito

con un tool diverso daNMAP

UDP Scan UDP Portscan

IP Protocol Scan IP Protocol ScanICMP PING NMAP ICMP PING eseguito

con un tool diverso daNMAP

BAD-TRAFFICUnassigned/ReservedIP protocol

Decoy SYS Scan TCP PortscanOpen Port

SYS Scan con Fram-mentazione

NESSUNO

TCP Connect() Scancon Frammentazione

TCP Portscan

Open Port

Tabella 4.1: Tabella degli attacchi eseguiti con Nmap.

95


Attacco Evento Generato Falsi Positivi

AWStats configdir Re-mote Command Exe-cution

WEB-CGI awstats ac-cess

IIS 5.0 WebDAVntdll.dll Overflow

OVERSIZEREQUEST-URIDIRECTORY

Esecuzione autoriz-zata di applicazioniche generano richiesteHTTP contenentipiù di 300 caratteriUnicode

WEB-MISC WebDAVsearch access

phpBB viewtopic.phpArbitrary Code Exe-cution

WEB-PHPviewtopic.php access

IA WebMail 3.x BufferOverflow

BARE BYTE UNI-CODE ENCODINGOVERSIZEREQUEST-URIDIRECTORY

Esecuzione autoriz-zata di applicazioniche generano richiesteHTTP contenentipiù di 300 caratteriUnicode

vBulletin misc.phpTemplate NameArbitrary CodeExecution

NESSUNO

Tabella 4.2: Tabella degli attacchi eseguiti con Metasploit.

96


4.5 Amministrazione Remota via SSH

SSH (Secure SHell) è un protocollo che permette di stabilire una sessione re-mota cifrata con un altro host inviando comandi testuali. Il fatto che l’interacomunicazione avvenga in maniera cifrata ha fatto in modo che il protocolloSSH diventasse uno standard de facto per l’amministrazione remota di sistemiUnix e dispositivi di rete. L’utilità dell’amministrazione remota nasce dallapossibilità di modificare, aggiornare ed effettuare interventi di manutenzionesull’IDS (o su un host qualsiasi), anche se ci si trova fisicamente lontani dalsensore. Si pensi agli enormi vantaggi del suo utilizzo in una rete di notevolidimensioni in cui sono dislocati più sensori IDS in edifici diversi.La fase di configurazione dell’accesso remoto è molto semplice e si riduce a po-che semplici operazioni; è infatti sufficiente installare un qualsiasi server SSH,come quello disponibile sul cd d’installazione di CentOS v4.4 sul sensore IDS,e un qualsiasi client SSH sulla macchina da connettere all’IDS. Molte distribu-zioni Unix ne integrano uno, mentre per i sistemi Windows si può utilizzare unclient come Putty (www.chiark.greenend.org.uk/~sgtatham/putty)[13].

Digitando il seguente comando con i privilegi di utente root è possibile accedead una console che permette di avere il totale controllo dell’IDS e di compierequalsiasi operazione.

[root@localhost ~]# ssh 192.168.1.22

Nel prossimo paragrafo si esaminerà l’ottimizzazione di Snort finalizzata alimitare la generazione di falsi positivi.

4.6 Ottimizzazione di Snort

Capita frequentemente che Snort rilevi numerosi falsi positivi e che generiallarmi per eventi di importanza non rilevante. Snort permette di limitare

97


Figura 4.7: Console remota SSH

la generazione di falsi positivi modificando le regole di intrusion detection(vedi Capitolo 3.5), disabilitandole totalmente o definendo degli indirizzi IPsui quali non verrà effettuato alcun controllo in relazione ad una o più regole.

Dopo la fase di test di Snort, svolta durante questo lavoro di tesi, l’IDSè stato installato nella rete da proteggere. Anche in questo caso, si è dovu-to affrontare il problema dei falsi positivi, in particolare è stato rilevato unallarme che sicuramente non costituiva un attacco: l’Oversize Request-URIDirectory. L’allarme in questione, le cui caratteristiche sono state discus-se nel Capitolo 4.4.2, veniva causato dai pacchetti contenenti URI costituitida un numero eccessivo di caratteri Unicode. In realtà gli utenti della rete,utilizzavano a fini professionali, un applicativo che generava questo tipo diURI. Si è pertanto deciso di disabilitare l’allarme relativamente al range diindirizzi IP della rete privata.

Per procedere con la disattivazione delle regole che hanno generato l’allar-me, si deve configurare il file /etc/snort/threshold.conf che deve essere

98


incluso nel file /etc/snort/snort.conf.Aprendo, quindi, il file /etc/snort/threshold.conf e conoscendo il gen_ide il sig_id della regola che genera falsi positivi, sarà sufficiente creare dellestringhe analoghe a quelle riportate di seguito per disabilitare i corrispettiviallarmi:

suppress gen_id <valore1>, sig_id <valore2>,

by_src, ip 10.1.1.54

Nella precedente riga di codice, valore1 e valore2 sono rispettivamente ilgen_id e il sig_id della regola che si vuole disabilitare, mentre track by_srcpermette di disabilitare il controllo delle regole relativamente al traffico pro-veniente dall’indirizzo IP 10.1.1.54.

Con la riga di codice


track by_dst, ip 10.1.1.54

si disabilita invece il controllo delle regole relativamente al traffico direttoall’indirizzo IP 10.1.1.54. La stessa modifica può essere effettuata anche inrelazione ad un range di indirizzi IP in questo modo:


track by_dst, ip 10.1.1.0/24

In ultimo è anche possibile disabilitare completamente una regola:

suppress gen_id <valore1>, sig_id <valore2>

L’ottimizzazione è un’operazione delicata, in quanto può comportare lagenerazione di falsi negativi. Prima di procedere è, quindi, opportuno esa-minare attentamente la documentazione fornita su www.snort.org in meritoalle regole che si intende disabilitare.

99

CAPITOLO 5. SVILUPPI FUTURI

Capitolo 5

Sviluppi Futuri

Nei Capitoli 2 e 3 sono state discusse le peculiarità dei NIDS soffermandol’attenzione sul software di intrusion detection Snort. Successivamente èstato presentato il modello di Intrusion Detection System progettato durantequesto lavoro di tesi, il quale è soggetto a numerose possibilità di sviluppoal fine di rendere l’architettura più completa e sicura. Vengono ora espostiquelli che sono i possibili sviluppi futuri.

5.1 Incremento del Livello di Sicurezza

L’architettura proposta, garantisce il rilevamento delle intrusioni e il log-ging delle attività anomale; tuttavia, l’IDS progettato, deve necessariamenteinteragire con l’esterno per poter permettere la visualizzazione dei log, espo-nendosi a tutti i pericoli di sicurezza che ne conseguono. Si è quindi pensatoad un possibile intervento che potesse incrementare il suo livello di sicurez-za. A tal fine occorrono due macchine, la prima da configurare come sensore,l’altra da utilizzare come server web e database per archiviare i log. Ciascunamacchina deve essere dotata di due schede di rete. Il sensore utilizza la primascheda di rete per ricevere i pacchetti da analizzare e la seconda per inviarei log degli eventi al database il quale, a sua volta, utilizza invece la primascheda di rete per ricevere i pacchetti inviati dal sensore, e l’altra per con-

101


Figura 5.1: Schema di rete con IDS e database implementate su due macchinediverse

nettersi alla rete interna dalla quale sarà possibile accedere alle informazionicontenute nel database (vedi Figura 5.1). È possibile perfezionare l’upgradeconfigurando il sensore per non rispondere alle rischieste provenienti dall’e-sterno. Questo permette di rendere l’IDS difficile da rilevare e da attaccare epuò garantire un notevole incremento dell’affidabilità del NIDS e del livellodi sicurezza del sistema.

5.2 Realizzazione di un IDS Distribuito

Nel corso della tesi sono state illustrate diverse ragioni che hanno influenzatola scelta del posizionamento del sensore nella DMZ (vedi Capitolo 4.2). Nelcaso in cui si intenda monitorare più segmenti di rete, risulta interessanteimplementare un sistema che preveda un sensore per ogni segmento e chegestisca in maniera centralizzata l’archiviazione dei log. Ogni sensore inter-cetta passivamente il traffico per mezzo della prima scheda di rete e invia ilog degli eventi al database centrale per mezzo della seconda scheda di re-te. Il database, è accedibile solamente dalla rete interna. Un’architetturadi questo tipo, garantisce un monitoraggio efficiente degli eventi dell’intera

102


rete, e rende più facile un’eventuale azione di correlazione finalizzata allaricostruzione delle procedure di attacco.

5.3 Invio degli Allarmi via Email e SMS

Un Intrusion Detection System ideale, richiede un monitoraggio costante, si-tuazione che nella realtà è difficilmente riproducibile. L’ultimo miglioramentoproposto è finalizzato ad informare in maniera tempestiva i CERT (Com-puter Emergency Response Team) aziendali di eventuali situazioni dannose.Implementando un sistema che invii gli allarmi più gravi via email o SMS, sa-rebbe possibile informare in tempo reale le persone responsabili, permettendointerventi tempestivi.

103

RINGRAZIAMENTI

Ringraziamenti

Alla fine di questo ciclo di studi rivolgo i miei più sentiti ringraziamenti a tutticoloro che mi hanno accompagnato in questi tre anni. Ci tengo a ringraziareparticolarmente:

• Mamma, Papà che mi hanno sempre sostenuto, moralmente ed econo-micamente durante tutto il percorso di studi, senza i quali probabil-mente questo momento non sarebbe mai arrivato;

• Federica che ha messo sempre il suo tocco di brio in qualsiasi cosa miriguardasse;

• Il relatore Prof. Ernesto Damiani e il correlatore Dott. Claudio Ago-stino Ardagna per l’aiuto costante fornito durante il lavoro di tesi e perl’infinita pazienza e disponibilità mostrata;

• Il prof. Dario Forte e il Prof. Marco Cremonini per gli utili suggerimentie per la documentazione fornita;

• Il mio amico Vittorio con il quale ho trascorso un anno formidabile egrazie al quale affrontare i problemi universitari è stato più semplice;

• Il mio amico Antonio senza il quale probabilmente l’ultimo anno aCrema sarebbe stato una catastrofe;

• Mio Zio Franco che, anche se non è presente, mi ha iniettato indispen-sabili dosi di matematica pura;

• Tutti i miei Nonni che aspettavano più di me questo momento;

105

RINGRAZIAMENTI

• Il Dott. Rossi del Comune di Piacenza e i suoi tips su Linux che anchese sommerso dalle mille faccende comunali ha sempre trovato tempo dadedicarmi;

• Gli amici di Bari in particolare Biagio, Giuseppe, Mario Z., Francesco,Raffaele, Claudio, Alessandro, Amedeo, Mario C. ed Emiliano per glianni indimenticabili passati insieme;

• Gli amici di Crema con cui ho trascorso serate stupende;

• Gli amici dell’Università per aver condiviso le loro conoscenze;

• Il Comune di Piacenza per aver ospitato il mio tirocinio.

Grazie infine, a tutti coloro che hanno creduto in me e hanno contribuito afarmi raggiungere questo ambito traguardo!

106

BIBLIOGRAFIA

Bibliografia

[1] ADOdb Database Abstraction Library for PHP. http://adodb.

sourceforge.net.

[2] Apache HTTP Server Project. http://httpd.apache.org.

[3] Basic Analysis and Security Engine. http://secureideas.

sourceforge.net.

[4] CentOS - The Community Enterprise Operating System. http://www.centos.org.

[5] CERT R© Advisory CA-2001-26 Nimda Worm. http://www.cert.org/

advisories/CA-2001-26.html.

[6] Insecure.org. http://www.insecure.org.

[7] Metasploit.org. http://www.metasploit.org.

[8] MySQL. http://www.mysql.org.

[9] Nmap. http://insecure.org/nmap.

[10] nTop. http://www.ntop.org.

[11] OinkMaster. http://oinkmaster.sourceforge.net.

[12] Php.net. http://www.php.net.

[13] Putty Official Website. http://www.chiark.greenend.org.uk/

~sgtatham/putty/.

108

BIBLIOGRAFIA

[14] Rfc Editor. http://www.rfc-editor.org.

[15] Seclists.org. http://www.seclists.org.

[16] Securiteam.com. http://www.securiteam.com.

[17] Securityfocus.com - Evading NIDS. http://www.securityfocus.com/

infocus/1852.

[18] Securityfocus.com - Metasploit Framework, Part 2. http://www.

securityfocus.com/infocus/1790.

[19] Sikurezza.org. http://www.sikurezza.org.

[20] Snort User Manual 2.6.0.

[21] Snort.org. http://www.snort.org.

[22] Sourceforge.net. http://www.sourceforge.net.

[23] Wikipedia.org - Demilitarized Zone. http://it.wikipedia.org/wiki/Demilitarized_zone.

[24] Wikipedia.org - NTP. http://it.wikipedia.org/wiki/NTP.

[25] Wikipedia.org - Standard ISO/OSI. http://it.wikipedia.org/wiki/Protocollo_di_rete.

[26] Wikipedia.org - X Window System. http://it.wikipedia.org/wiki/X_Window_System.

[27] Rfc 791 - Internet Protocol. ftp://ftp.rfc-editor.org/in-notes/

rfc791.txt, Settembre 1981.

[28] Rfc 793 - Transmission Control Protocol. ftp://ftp.rfc-editor.org/in-notes/rfc793.txt, Settembre 1981.

[29] AA.VV. 2002-2006. Iritaly - Italian Incident Response Project. http:

//www.iritaly.org, 2006.

109

BIBLIOGRAFIA

[30] Baker Andrew, Caswell Brian, Poor Mike. Snort 2.1 : intrusiondetection. Syngress Publishing, 2004.

[31] Bejtlich Richard. The Tao of Network Security Monitoring: BeyondIntrusion Detection.

[32] Bejtlich Richard. Extrusion detection: security monitoring for internalintrusions. Addison Wesley, 2006.

[33] Massaro Roberta. Metodologie di test per la sicurezza delle reti informa-tiche. Master’s thesis, Università degli Studi di Milano, Dipartimentodi Tecnologie dell’Informazione di Crema, 2003-2004.

[34] Northcutt, Stephen [et al.]. Inside network perimeter security. Samspublishing, 2005.

[35] Northcutt Stephen, Novak Judy. Network intrusion detection. NewRiders, 2003.

[36] Soragni Michele. Sviluppo e implementazione di un sistema di analisi del-la sicurezza e di controllo del traffico su Reti IP. Master’s thesis, Univer-sità degli Studi di Milano, Dipartimento di Tecnologie dell’Informazionedi Crema, 2004-2005.

110

Progettazione di un Intrusion Detection System Laurea Danilo Vizzarro.pdf · 1.2 Obiettivi del...

Documents

Transcript of Progettazione di un Intrusion Detection System Laurea Danilo Vizzarro.pdf · 1.2 Obiettivi del...