Progettazione di un Intrusion Detection System

Transcript

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 informazioni e servizi rende sempre più critico, per qualunque azienda, la protezione
delle risorse da accessi non autorizzati e/o attacchi mirati all’acquisizione
di privilegi non garantiti. Questo problema diventa di vitale importanza
per l’economia di un’azienda, dal momento che quest’ultima ha bisogno di
amministrare notevoli quantità di informazioni mantenendone segretezza, integrità e disponibilità. Questa esigenza ha portato alla rapida diffusione di
dispositivi software/hardware, Intrusion Detection System (IDS), utilizzati per identificare accessi non autorizzati e per rilevare tutti gli attacchi a
computer e reti informatiche. Tuttavia, la progettazione di un sistema di
sicurezza non è limitato alla configurazione di un IDS, ma richiede la conoscenza di diverse tecnologie e componenti, quali router, firewall e VPN, e la
capacità di integrarle e farle interagire per garantire la sicurezza dei dati.
Obiettivo del lavoro di tesi è la progettazione e lo sviluppo di un Intrusion
Detection System che massimizzi il rapporto qualità/prezzo. A questo scopo
dopo un’attenta analisi ed uno studio approfondito sono stati selezionati i
migliori strumenti Open Source attualmente disponibili in rete. Il progetto
di 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 determinare le mancanze e le necessità di sicurezza della rete, effettuandone un’analisi preliminare e identificandone le risorse da
proteggere 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 a
disposizione, si è deciso di utilizzare una macchina con processore
di 1600 Mhz per installare il Sistema Operativo CentOS v4.4 e il
software di intrusion detection Snort v2.6, entrambi scelti per le
loro funzionalità.
– Dopo aver proceduto con la loro configurazione, sono state definite
delle regole di intrusion detection ad hoc per le esigenze della rete.
– È stato implementato sulla stessa macchina un server web Apache
con supporto PHP 4 e un database MySQL sul quale sono stati
archiviati e resi accessibili da qualsiasi postazione sulla rete i log
generati da Snort.
– È stata creata un’interfaccia per la visualizzazione grafica dei log
di Snort. È stato inoltre installato e configurato il software nTop
per mostrare tramite interfaccia web le statistiche sui protocolli
più attaccati.
– Per risolvere il problema dell’aggiornamento delle politiche di sicurezza è stato implementato OinkMaster, un sistema automatico
che controlla il rilascio di nuove regole, ed eventualmente ne effettua l’aggiornamento automatico, creando il backup delle vecchie
regole e archiviando i log dell’operazione.
– È stato, infine, installato un server SSH per permettere l’amministrazione dell’IDS da remoto.
• Test dell’IDS.
– La fase di test dell’IDS si è basata sull’adozione di due software, chiamati Nmap e Metasploit, il primo utilizzato per cercare i servizi attivi su un sistema e l’altro per scoprirne eventuali
vulnerabilità.
3
PREFAZIONE
• Ottimizzazione delle regole.
– Dopo l’implementazione dell’IDS è stato necessario procedere con
l’ottimizzazione delle regole dell’IDS al fine di risolvere il problema
dei falsi positivi riscontrato durante la fase di test.
Il lavoro di tesi lascia spazio a sviluppi futuri e possibili evoluzioni dell’architettura proposta. Prima fra tutte l’incremento del livello di sicurezza
dell’IDS al fine di evitare eventuali compromissioni dell’IDS e dei log. A
tale scopo l’IDS potrebbe intercettare passivamente il traffico e archiviare le
informazioni sugli eventi anomali su una macchina remota.
Lavori futuri riguardano anche l’implementazione di un Distribuited Intrusion Detection System, che preveda l’uso di un sensore per ogni segmento di
rete, configurato per monitorare il traffico ed inviare i log su un unico database centrale dove le informazioni verrebbero memorizzate e correttamente
organizzate.
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 di
Intrusion Detection Systems e le loro caratteristiche peculiari, mettendone in
evidenza gli aspetti positivi e negativi. Si illustreranno, inoltre, le analogie
e le differenze con i firewall focalizzando la discussione sui motivi che suggeriscono l’utilizzo di entrambe le componenti, durante il processo di sicurezza
di un sistema informatico. Saranno discusse le tecniche e gli attacchi più o
meno sofisticati che consentono di aggirare un IDS e infine saranno esaminati
il problema dell’analisi dei log e gli aspetti legali da considerare qualora un
sistema di intrusion detection venga realmente installato.
Nel Capitolo 3 si illustrerà l’architettura di Snort, il più celebre Networkbased Intrusion Detection System della comunità OpenSource analizzandone
i requisiti hardware richiesti e le modalità di funzionamento. Saranno, dun-
4
PREFAZIONE
que, esaminate la sintassi delle regole di intrusion detection e quella dei log
generati.
Nel Capitolo 4 verrà proposta l’architettura che effettua l’intrusion detection,
descrivendo in dettaglio le parti in gioco e argomentando le scelte implementative.
Nel Capitolo 5 si presenteranno alcune proposte per ottimizzare l’architettura
e renderla più completa.
5
INDICE
Indice
1 Introduzione
10
1.1
Tipologie di IDS . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2
Obiettivi del lavoro di tesi . . . . . . . . . . . . . . . . . . . . 11
2 Intrusion Detection System
14
2.1
NIDS: Pro e Contro . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2
NIDS vs Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3
Tecniche di Analisi dei Pacchetti . . . . . . . . . . . . . . . . . 17
2.4
Allarmi: Falsi Positivi e Falsi Negativi . . . . . . . . . . . . . 19
2.5
Risposta dei NIDS . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6
Posizionamento degli IDS
2.7
NIDS: gli Attacchi . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8
Log Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9
Aspetti Legali . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . . . . 21
2.10 Scelta di un NIDS . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Snort
33
3.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2
Requisiti Hardware . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3
Architettura di Snort . . . . . . . . . . . . . . . . . . . . . . . 34
3.4
Modalità di Funzionamento . . . . . . . . . . . . . . . . . . . 43
3.5
Regole di Intrusion Detection . . . . . . . . . . . . . . . . . . 44
3.6
Analisi dei Log . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7
INDICE
4 Configurazione del NIDS
55
4.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2
Analisi del Sistema . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3
Setup del NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4
4.3.1
Setup di CentOS v4.4 . . . . . . . . . . . . . . . . . . . 59
4.3.2
Setup di Apache e MySQL . . . . . . . . . . . . . . . . 62
4.3.3
Setup di Snort v2.6 . . . . . . . . . . . . . . . . . . . . 69
4.3.4
Setup di AdoDB e BASE . . . . . . . . . . . . . . . . . 72
4.3.5
Setup di nTop . . . . . . . . . . . . . . . . . . . . . . . 77
4.3.6
Setup di OinkMaster . . . . . . . . . . . . . . . . . . . 79
Test del NIDS: i Risultati . . . . . . . . . . . . . . . . . . . . 81
4.4.1
Test con Nmap . . . . . . . . . . . . . . . . . . . . . . 81
4.4.2
Test con Metasploit . . . . . . . . . . . . . . . . . . . . 88
4.5
Amministrazione Remota via SSH . . . . . . . . . . . . . . . . 97
4.6
Ottimizzazione di Snort . . . . . . . . . . . . . . . . . . . . . 97
5 Sviluppi Futuri
101
5.1
Incremento del Livello di Sicurezza . . . . . . . . . . . . . . . 101
5.2
Realizzazione di un IDS Distribuito . . . . . . . . . . . . . . . 102
5.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 di
guadagnare un accesso non autorizzato ad un sistema, ad esempio, si pensi
al pirata informatico che cerca di ottenere un accesso abusivo ad un server o
che diffonde virus per controllare le vittime1 infettate.
Per intrusion detection si intende quel processo di scoperta, analisi e reporting 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 informazioni a livello applicativo. Permettono di sapere quale utente ha utilizzato
una particolare applicazione e danno la possibilità di ricostruire le transazioni effettuate. Le loro prestazioni non vengono influenzate dalla quantità di
traffico di rete in quanto agiscono su singoli host. Gli AIDS però, richiedendo
elevate risorse per la computazione, possono influenzare le prestazioni della
1
2
Si definisce vittima, un sistema o una singola entità attaccata.
Per 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 di
cui controllano il traffico di rete relativo. Si occupano di monitorare l’attività
di login, registrando i tentativi falliti e inviando appositi allarmi all’amministratore di rete e inoltre controllano le azioni compiute dall’utente root alla
ricerca di comportamenti sospetti. Possono richiedere notevoli quantità di
spazio per l’archiviazione dei log.
I NIDS sono installati su un apparato dedicato detto sensore e si occupano di monitorare l’intero segmento di rete al quale appartengono. I pacchetti
vengono catturati per mezzo dei packet sniffer3 utilizzando interfacce di rete
in 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-Based
Intrusion Detection System, in quanto permette di riconoscere eventuali attacchi o violazioni della sicurezza e fornisce dei report via web sullo stato
della rete in tempo reale. La classe di NIDS verrà analizzata in dettaglio per
poi focalizzare nel Capitolo 3, la discussione su Snort, il più diffuso sistema
di 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 intrusioni realizzato utilizzando un sensore IDS per l’intercettazione e l’analisi dei
pacchetti, un database MySQL per l’archiviazione degli eventi, un server web
e un’interfaccia grafica per monitorare l’attività del sensore IDS. La scelta
degli strumenti utilizzati si è basata sulla valutazione di due requisiti fondamentali: il costo e le funzionalità d’uso. L’obiettivo principale è stato quello
3
I packet sniffer si occupano di intercettare tutti i pacchetti in transito.
11
di realizzare un sistema semplice da usare anche per un tecnico informatico
non specializzato in sicurezza. A tale scopo si è cercato di creare un’interfaccia grafica amichevole per permettere una chiara analisi degli eventi generati
dal sensore. Infine, altro obiettivo di particolare importanza è stato quello di
mantenere 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 aggiungere un tassello fondamentale a quello che è il processo di sicurezza informatica.
Infatti, la sola integrazione di un IDS, con un firewall ben configurato, un
antivirus aggiornato, e con una valida formazione degli utenti della rete, finalizzata a prevenire attacchi di Social Engineering4 , permette di raggiungere
un discreto livello di sicurezza. Nel lavoro di tesi si è cercato, con l’aiuto
di software Open Source come Snort, Nmap e Metasploit, di conoscere i limiti del sistema creato e di capire come personalizzarlo in base alle proprie
esigenze.
4
Gli 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 il
sistema 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, un
buon sistema di incident response e che adotta firewall, antivirus e tutte le
più moderne misure di sicurezza, i NIDS giocano un ruolo fondamentale, in
quanto:
• 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 alla
rete;
• segnalano se qualche altra misura di sicurezza, come il firewall o l’antivirus, non ha funzionato correttamente;
• rilevano eventuali attacchi provenienti dalla rete interna verso la rete
esterna;
14
• rilevano la presenza di eventuali worm che cercano di inviare informazioni all’esterno della rete;
• effettuano il monitoraggio delle risorse condivise utilizzate;
• permettono di capire quali misure preventive adottare al fine di evitare
eventuali attacchi futuri;
• sono difficili da rilevare in quanto agiscono passivamente.
Le ampie funzionalità descritte hanno portato alcuni amministratori di
rete a pensare che i NIDS siano in grado di segnalare e risolvere qualsiasi problema di sicurezza. Paradossalmente, pensare che i NIDS garantiscano totale
sicurezza date le loro enormi potenzialità, può risultare controproducente in
quanto ciò genererebbe un falso senso di sicurezza. Non esiste, infatti, né totale sicurezza, né un unico prodotto che permetta di essere totalmente sicuri.
Anche se i NIDS sono sicuramente necessari a garantire un buon livello di
sicurezza del sistema, da soli non sarebbero sufficienti in quanto:
• non sostituiscono l’esistente staff di sicurezza in quanto necessitano di
costante monitoraggio;
• non individuano attacchi che sfruttano vulnerabilità non ancora rese
pubbliche detti 0-day;
• agiscono passivamente, ovvero non bloccano il traffico dannoso anche
se possono essere configurati per interagire con un firewall;
• quando c’è una grande quantità di traffico da processare, è possibile che
vengano persi dei pacchetti, con conseguente fallimento nella rilevazione
di 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 frammentati;
• incrementando il numero delle firme1 , può essere ridotta l’efficenza del
NIDS;
• richiedono notevoli risorse in termini di spazio per l’archiviazione dei
log;
• non sostituiscono gli altri meccanismi di protezione.
Da quanto detto, emerge che i NIDS sono necessari ad aumentare il controllo 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 ad
una rete. Entrambi sono fondamentali ma nessuno è sufficiente a garantire
da solo un elevato livello di sicurezza. A parte queste analogie, ci sono delle
sostanziali differenze tecniche che li caratterizzano.
I firewall hanno funzione di filtraggio dei pacchetti allo scopo di bloccare il
traffico non conforme alle loro politiche. I pacchetti vengono filtrati in base
all’indirizzo IP sorgente o di destinazione e alle corrispettive porte. Difficilmente i log memorizzati riguardano il traffico permesso2 , in quanto ritenuto
affidabile. Se alcuni dei pacchetti dannosi riuscissero a superare il firewall a
causa di una configurazione non corretta dello stesso, o di una qualsiasi vulnerabilità sfruttata, non solo sarebbe possibile portare a termine un attacco
con successo ma, sopratutto, non verrebbe memorizzata alcuna informazione
1
Ciascuna firma consiste in una o più stringhe contenenti alcuni parametri, che se
riscontrati in un pacchetto devono generare un allarme.
2
Il traffico permesso è quello non bloccato dal firewall. Solitamente non viene registrato
in 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 il
contenuto di tali pacchetti e segnalano con un allarme ogni attività anomala
individuata, indipendentemente dal successo o dall’insuccesso della stessa.
Inoltre nel caso in cui un attacco provenisse dall’interno della rete, il firewall
non avrebbe utilità alcuna. Esso infatti, pur essendo capace di filtrare il traffico verso e dalla rete esterna, non ha alcun potere sul traffico interno alla
rete.
Altra debolezza dei firewall è dovuta al fatto che talvolta gli utenti per ingenuità o impazienza si collegano a Internet creando connessioni non autorizzate tramite modem. Questo comportamento mette a rischio l’intera rete
perchè il traffico generato, anche in questo caso, non sarà filtrato dal firewall.
I NIDS, pertanto, pur monitorando il traffico interno alla rete, non eliminano
i firewall.
2.3
Tecniche di Analisi dei Pacchetti
Vediamo adesso in che modo gli Intrusion Detection System riescono a svolgere la loro funzione di analizzatori di pacchetti. Impostando la scheda di
rete del NIDS in modalità promisqua, è possibile ‘ascoltare’ in maniera passiva tutto il traffico passante sul segmento di rete, senza interferire sullo stesso.
L’analisi dei pacchetti può essere effettuata mediante tre tecnologie: la pattern matching analysis, la stateful pattern matching analysis e la protocol
analysis.
La Pattern Matching Analysis si occupa di analizzare i contenuti dei
pacchetti alla ricerca di sequenze di bit prefissate. Questo è un approccio
semplice da implementare ma, allo stesso tempo, abbastanza rigido e pesante
dal punto di vista computazionale in quanto ogni pacchetto deve essere confrontato con centinaia di firme di intrusion detection. Ogni firma è associata
a 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 <payload_con_exploit> che vengono confrontati con i pacchetti in ingresso e in
uscita nel seguente modo: SE il protocollo utilizzato è <protocollo>, l’indirizzo IP sorgente è <ip_src>, la porta associata all’indirizzo IP sorgente è
<porta_src>, l’indirizzo IP di destinazione è <ip_dst>, la porta associata
all’indirizzo IP di destinazione è <porta_dst> e il payload contenuto nel
pacchetto è <payload_con_exploit>, ALLORA genera un allarme.
In base a quanto descritto fino ad ora, un allarme viene generato quando
si verifica il pattern matching tra un pacchetto e una regola. Questo significa
che sarebbe sufficiente dividere la stringa dell’exploit contenuta nel payload
in due frame TCP, per non far rilevare l’attacco. Per risolvere questo problema, è stato introdotta la Stateful Pattern Matching Analysis che è un
criterio più sofisticato di analisi che effettua gli stessi controlli della Pattern
Matching Analysis tenendo però conto dello stream TCP dei dati.
Questo comporta maggiore carico computazionale in quanto capita spesso
che ci siano sessioni TCP aperte da monitorare per un lungo periodo.
La Protocol Analysis invece, genera un allarme per ogni violazione delle specifiche tecniche di un protocollo3 . Si supponga, per esempio, che un
client intenda aprire una connessione TCP con un server, a tal fine invia
un pacchetto SYN e si aspetta di ricevere o un pacchetto SYN/ACK o un
RST/ACK. Qualsiasi altro pacchetto ricevuto viene considerato una violazione e genera un allarme.
Questa tecnica minimizza, qualora il protocollo sia ben definito, il numero
di falsi positivi generati se traffico lecito viene riconosciuto come anomalo, tuttavia, non è raro trovare delle RFC ambigue che lasciano spazio agli
sviluppatori di implementare il protocollo a propria discrezione.
3
Le specifiche dei protocolli sono documentate nelle Request For Comment e reperibili
su 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 necessitano
di almeno un algoritmo di generazione degli allarmi. Alcuni amministratori
scelgono di ritenere anomalo tutto il traffico considerato non affidabile (politica chiusa), altri invece scelgono di ritenere affidabile tutto il traffico non
considerato 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 essere
dovuti a:
• pacchetti generati da alcuni dispositivi di rete non riconosciuti dal
NIDS;
• violazioni di protocolli non dovute ad attacchi ma ad implementazioni
ambigue;
• circostanze normali ritenute pericolose dal NIDS, come per esempio la
visualizzazione di una pagina web contenete il codice sorgente di un
exploit.
Nella seconda ipotesi il numero di allarmi sarà notevolmente minore, ma si
corre il rischio di non identificare il traffico anomalo che non trova alcuna
corrispondenza 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 dal
NIDS;
• traffico cifrato;
• firme errate o troppo generiche;
19
• attacchi 0-day dei quali non è stata ancora rilasciata la corrispettiva
firma.
Il numero di falsi negativi può essere limitato solo con una costante manutenzione del NIDS e con un frequente aggiornamento delle firme.
Per trovare il giusto equilibrio tra falsi positivi e falsi negativi, è opportuno
analizzare approfonditamente la topologia della rete ed eliminare la causa che
genera falsi allarmi. Procedere eliminando radicalmente la regola corrispondente ad un attacco, potrebbe essere una scelta troppo ingenua e superficiale
che 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 rispondere passivamente segnalando le anomalie tramite messaggi di testo, email,
o telefonate. La modalità di segnalazione dell’allarme spesso dipende dalla
gravità dello stesso.
Alcuni IDS, possono anche essere programmati per rispondere attivamente
agli attacchi più seri, adottando una delle seguenti contromisure:
• inviando un pacchetto RST all’attaccante simulando che esso provenga dal sistema attaccato al fine di far credere che la vittima non sia
raggiungibile;
• interagendo con un firewall di rete per bloccare temporaneamente o
permanentemente le connessioni con la vittima;
• monitorando l’intero scambio di pacchetti;
20
• eseguendo un nslookup 4 , un portscan 5 o un traceroute 6 verso il sistema
attaccante per reperire maggiori informazioni.
Tuttavia, configurando l’IDS per rispondere attivamente ad attacchi, in caso
di falsi positivi si rischierebbe il blocco delle connessioni che normalmente
dovrebbero essere consentite causando un DoS.
2.6
Posizionamento degli IDS
Una delle attività maggiormente critiche nella configurazione e messa in opera di un IDS è il suo posizionamento all’interno della rete da monitorare. In
base alla topologia della rete, possono presentarsi diversi casi. Quando in un
segmento di rete gli host sono collegati da un hub, l’implementazione di un
NIDS è relativamente semplice perchè l’hub è una componente di rete che si
occupa di replicare ogni singolo pacchetto su tutte le porte. In questo modo
è sufficiente collegare il NIDS a una porta qualsiasi dell’hub per poter leggere
tutto il traffico passante.
In presenza di uno switch, invece, la situazione è diversa e l’implementazione
dei NIDS è maggiormente complicata. Gli switch, infatti, lavorano ad un
livello superiore della pila ISO/OSI[25] rispetto agli hub e quando devono
inviare un pacchetto, lo inviano solo verso la relativa porta di destinazione. 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 somma
della capacità di banda di tutte le porte monitorate. Solo in questo modo il
traffico potrà essere gestito in modo opportuno.
4
Nslookup è un comando che permette di risalire dall’hostname di una macchina al suo
indirizzp IP.
5
Il Portscan è una tecnica utlizzata per raccogliere informazioni e capire quali sono i
servizi attivi su una vittima.
6
Traceroute è un comando che permette di individuare il percorso compiuto dai
pacchetti di dati per giungere dal computer dell’utente ad un computer remoto.
21
Come detto, la scelta del posizionamento degli IDS è un’attività molto delicata che deve tener conto delle esigenze della rete e delle risorse di cui si
dispone.
Un’altra variabile da considerare nel posizionamento di un IDS è la sua collocazione rispetto ad un firewall. Posizionando l’Intrusion Detection System
all’esterno del firewall, si identificheranno tutte le attività anomale incluse
quelle che non avranno accesso alla rete in quanto bloccate dal firewall. Un
IDS disposto in questo modo sarà più esposto agli attacchi provenienti dall’esterno perchè privo di protezione. Le risorse richieste sono ingenti in quanto
la quantità di traffico analizzato e di log memorizzati sarà rilevante.
Una soluzione più economica consiste nel posizionare l’IDS all’interno del firewall per monitorare solo il traffico che accede alla rete. In tal modo saranno
generati meno allarmi e ci saranno meno log da analizzare.
Se invece, l’obiettivo dell’IDS è la protezione dei server, una valida alternativa è installare il sistema di intrusion detection nella Demilitarized Zone
(DMZ)7 [23]. Tuttavia, gli altri segmenti di rete rimarrebbero privi di monitoraggio.
Pertanto, nel caso in cui le risorse a disposizione siano elevate, la soluzione
più robusta consiste nell’installare un IDS per ogni segmento di rete. Questo permette di tenere sotto controllo l’intera rete, di configurare ciascun
Intrusion Detection System in maniera diversa in base alle esigenze del singolo segmento e di evitare eventuali sovraccarichi dei sistemi. Inoltre, se
un IDS dovesse venire meno per una qualsiasi ragione (come ad esempio errori hardware/software o attacchi di vario tipo), gli altri segmenti di rete
continuerebbero ad essere monitorati.
7
La DMZ è un segmento di rete isolato della LAN, che si trova tra la rete interna e la
rete esterna. Alla DMZ si può accedere sia dalla rete interna che da quella esterna, ma le
connessioni 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 sfruttate diversamente, in base alle caratteristiche tecniche del sistema di intrusion
detection e quelle della rete che viene monitorata. Le tipologie d’attacco descritte di seguito, sfruttano il timeout di riassemblaggio del frame IP che è il
tempo massimo in cui un frame viene tenuto in memoria prima di essere eliminato e la frammentazione. Quando un pacchetto è eccessivamente grande
rispetto alla rete che deve attraversare, può essere frammentato da qualsiasi
router. Ogni frame viene associato a un Time to Live (TTL) che per essere
accettato dal router deve avere un valore maggiore di 1. Quando il router
riceve un frame, prima di inviarlo a destinazione, provvede a decrementare il
TTL di 1. Se questo diventa uguale a 0, il pacchetto viene eliminato e viene
restituito 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 opportuno
per nascondere un attacco. Possono essere sfruttati diversi tipi di Insertion
Attack, descritti in seguito.
• Il tempo di timeout del NIDS è maggiore di quello della vittima
Supponiamo che il tempo di timeout del NIDS sia 60 secondi e quello
del sistema attaccato sia 30 secondi. Il pacchetto contenente codice
maligno viene diviso in 4 frammenti numerati da 1 a 4. Vengono poi
generati altri due frame ai quali associamo i numeri 2’ e 4’, con payload
apparentemente normale. L’attacco viene espletato come descritto di
seguito. Si inviano i frame 2’ e 4’ che saranno ricevuti sia dal NIDS
che dalla vittima. Dopo 30 secondi la vittima scarterà tali frame in
quanto scaduto il tempo di timeout e non genererà alcun messaggio
ICMP di errore. Si inviano quindi, i frame 1 e 3. A questo punto la
vittima 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 e
pertanto scarterà i frammenti senza generare allarmi. Ora è possibile
inviare i frame 2 e 4. In questo modo la vittima, avendo ricevuto tutti
i 4 frame, riassemblerà il pacchetto, mentre il NIDS avendo ricevuto
solo gli ultimi due pacchetti, attenderà il rispettivo tempo di timeout
e provvederà a scartarli.
• Attacco basato su TTL
Per sfruttare questo attacco è necessario conoscere il numero dei router
presenti tra l’attaccante e la vittima. A tale scopo possono essere utilizzati tool come traceroute. Supponiamo che tra il NIDS e la vittima
ci sia un router. Si divide il pacchetto contenente codice maligno in
3 frammenti numerati da 1 a 3. Viene poi generato un altro frame al
quale associamo il numero 2’ con payload apparentemente normale. Si
invia il frame 1 con un TTL elevato il quale sarà ricevuto sia dal NIDS
che dalla vittima. Si invia il frame 2’ con TTL impostato a 1. Questo
frammento sarà ricevuto dal NIDS ma non arriverà a destinazione perchè sarà scartato dal router a causa del basso TTL. Si invia il frame 3
con un TTL valido. A questo punto il NIDS riassemblerà i 3 frammenti,
mentre la vittima resterà in attesa del secondo frammento. Dopo aver
inviato il frame 2, la vittima riassemblerà il pacchetto e l’attacco sarà
riuscito con successo.
• Overlapping dei frammenti
Come detto precedentemente, ogni sistema operativo adotta una sua
politica di riassemblaggio dei pacchetti. Si supponga di avere un pacchetto anomalo diviso in 4 frammenti numerati da 1 a 4. Vengono poi
generati altri due frame ai quali associamo i numeri 2’ e 4’, i quali hanno un payload apparentemente normale, stesso offset, stessa lunghezza
e stesso header IP dei pacchetti 2 e 4. Si inviano i frame 1,2,3 i quali
8
La checksum è una somma di controllo utilizzata per rilevare eventuali errori nella
trasmissione.
24
giungeranno a destinazione senza problemi. Si inviano ora i frammenti
2’,3’,4. A questo punto diversi sistemi operativi potrebbero reagire in
modo diverso. Per esempio, i sistemi Windows, MacOC o SunOS riassemblerebbero il pacchetto considerando validi i frame 1,2,3,4; sistemi
come Cisco IOS considererebbero validi i frame 1,2’,3’,4. Pertanto, in
base al sistema operativo attaccato, questa tecnica può essere sfruttata
per portare a termine un attacco.
Evasion Attack
Si verifica quando un NIDS scarta un pacchetto che sarà accettato dal sistema
finale. In questo modo l’attaccante può inviare pacchetti dannosi alla vittima
senza che il NIDS ne effettui l’analisi.
• Il tempo di timeout del NIDS è minore di quello della vittima
Supponiamo di aver diviso il pacchetto da inviare in 2 frame e che
il tempo di timeout del NIDS sia di 15 secondi e quello del sistema
attaccato sia 30 secondi. Dopo aver inviato il primo frame, l’attaccante
invia il secondo frame in un intervallo di tempo che varia tra i 15 e i 30
secondi. 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 riassemblaggio
portanto l’attacco a compimento.
• Unicode Evasion
Consiste nel modificare i pacchetti cercando di evitare il pattern matching con le regole di intrusion detection. Per esempio, in occasione della diffusione del worm Nimda[5] è stato riscontrato che il worm inviava
una particolare richiesta HTTP, dove il simbolo “/” veniva sostituito
con 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 ad
accedere 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 definitivo
dei NIDS.
• Esaurimento delle Risorse della CPU
Consiste nell’inviare grandi quantità di pacchetti frammentati sfruttando il fatto che, quando l’IDS riceve tali pacchetti, questi devono essere
salvati e mantenuti fino a quando tutti i pacchetti dello stream non
siano arrivati o il tempo di timeout non sia raggiunto.
2.8
Log Analysis
L’analisi dei log è di fondamentale importanza nel processo di intrusion detection sia nel caso ci siano stati dei tentativi di intrusione, che nel caso si
sia verificato un incidente informatico.
I log memorizzano record contenenti informazioni sul timestamp9 , sul protocollo utilizzato, sull’indirizzo IP sorgente e di destinazione e sulle porte
utilizzate da qualsiasi attività anomala monitorata. Possono anche essere
contenuti dati aggiuntivi come una descrizione testuale dell’evento o il numero della regola che ha generato l’allarme.
Quando vengono generati log causati da eventi di una certa entità, è opportuno memorizzare anche il payload del pacchetto che ha generato l’allarme
per avere maggiori dettagli sull’evento.
9
Il timestamp include la data e l’ora in cui l’evento è stato registrato.
26
Facciamo un esempio considerando una richiesta DNS10 . In corrispondenza
di questo evento, verrà generato un log dove sarà riportato che il potenziale
attaccante con indirizzo IP 100.200.100.200 ha inviato un pacchetto UDP al
destinatario 90.80.70.60, sulla porta 53. Ciò non sarà sufficiente a capire se
la richiesta DNS è stata dannosa o meno. La situazione sarebbe differente
nel caso in cui si potesse analizzare anche il payload del pacchetto.
Uno dei problemi maggiori nell’analisi dei log è l’eterogeneità intrinseca degli
stessi, in quanto variano a seconda del firewall, del router o dell’IDS utilizzato. Non esistono tool che sincronizzano cronologicamente i log prodotti da
sistemi differenti. Può talvolta capitare che la time zone differisca da sistema
a sistema, rendendo ancora più complicata l’analisi; tuttavia, per sincronizzare sistemi diversi, possono essere usati protocolli come NTP[24].
Inoltre, di estrema importanza è la capacità di reazione di fronte ad un’intrusione. 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 solo
alla possibile manipolazione dei log ma anche alle molteplici attività anomale
che 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 compromesse per archiviare programmi, mp3 e film da mettere illegalmente in
condivisione con gli altri utenti della rete.
• Il traffico sospetto verso indirizzi IP sconosciuti o su protocolli non
utilizzati comunemente. Se si rilevano connessioni in uscita provenienti da un server web, questo può significare che il server sia stato
compromesso.
• Se si identificano pacchetti malformati, c’è il rischio che un attaccante
10
Per 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 stia
tentando di aggirare un firewall.
• La perdita di connettività, che potrebbe essere associata ad un attacco
DoS.
• Un numero elevato di tentativi di login falliti, i quali sono comuni quando l’attaccante cerca di ottenere maggiori privilegi di quelli realmente
concessi.
• Un’attività inusuale del modem, che potrebbe indicare la probabile
presenza di dialer.
• Le ‘Scansioni’ verso le macchine della rete, che sono utilizzate dall’attaccante per raccogliere informazioni sui sistemi operativi installati, i
servizi attivi, le porte aperte e la topologia della rete. Tali informazioni
saranno poi usate per effettuare un attacco.
• L’alta quantità di traffico generata in orari non di lavoro, indice di
utenti non autorizzati che stanno usufruendo della rete.
Nel caso in cui nella rete attaccata fosse presente uno switch, una volta introdottosi, l’attaccante potrebbe intercettare il traffico utilizzando due
attacchi.
• L’attacco ARP-POISONING, dove vengono alterate le tabelle ARP11
degli host appartenenti allo stesso segmento di rete, in modo che la
macchina sul quale risiede lo sniffer veda anche il traffico generato dagli
altri host.
• L’attacco DHCP-POISONING, dove l’attaccante fa in modo che un host della rete interna simuli di essere il server DHCP e invii delle risposte
ad-hoc alle DHCP-REQUEST che gli arrivano, specificando l’indirizzo
11
Le tabelle ARP contengono la correlazione tra indirizzi IP e MAC address di una
macchina.
28
IP dell’attaccante come default gateway. In tal modo tutto il traffico, prima di arrivare all’esterno, passerà per la macchina controllata
dall’attaccante.
2.9
Aspetti Legali
Qualsiasi attività di monitoraggio della rete deve rispettare le normative in
vigore nello stato in cui si trova il sistema informatico e le politiche interne
aziendali. In caso contrario esiste il rischio di essere perseguiti penalmente
per violazione della privacy degli utenti della rete e per intercettazione abusiva di comunicazione informatica. Non sarà, inoltre, possibile utilizzare i dati
raccolti 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 eventuali compromissioni.
Dal punto di vista burocratico tali accorgimenti possono essere tradotti
in una lettera informativa da far firmare a tutti gli utenti della rete per presa
visione. Dal punto di vista tecnico è possibile implementare un “Message of
the Day” (MOTD) che consiste in un messaggio iniziale che informa gli utenti
dell’attività di logging della rete.
In caso di incidente informatico i log rappresentano prove preziose, ed in
quanto tali, devono essere ottenute in modo conforme alla normativa vigente
ed 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 che
contengono la prova stessa;
• completa, in quanto non deve mostrare l’incidente dall’unica prospettiva riconducibile alle azioni compiute dall’attaccante, ma deve valutare
anche prospettive che potrebbero dare adito a contraddizioni;
• comprensibile e credibile, ovvero rappresentata in un formato leggibile
da 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 in
considerazione durante la scelta di un NIDS.
• Costo: deve, ovviamente, essere proporzionato alle risorse che si vogliono proteggere.
• Capacità della banda supportata: è la quantità di traffico che il sensore può analizzare in un’unità di tempo. Si misura in Mb/s o in
pacchetti/sec.
• Aggiornamento delle firme: i NIDS da questo punto di vista funzionano
esattamente come gli antivirus. Per poter identificare i nuovi attacchi
devono avere nel loro database le firme recenti. Per questa ragione
è di estrema importanza che gli aggiornamenti vengano rilasciati in
modo tempestivo e venga data la possibilità di aggiornare il database
in modo automatico. Importante è anche la possibilità di utilizzare
firme personalizzate create ad-hoc per le proprie esigenze.
• Attività di logging: è opportuno verificare la chiarezza dei log e valutare
se l’output viene salvato in formato standard o proprietario.
• Scalabilità: La possibilità di ampliare le funzionalità del NIDS in caso
di esigenze future è di estrema importanza, in partiolare andrebbe valu30
tato il numero di sensori supportati e la possibilità di gestire il sistema
in 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 comunità OpenSource, progettato per funzionare sia su sistemi operativi Unix
che Windows[30]. Uno degli aspetti che lo differenzia dagli altri NIDS è l’ampio bagaglio di regole di cui dispone che sono aggiornate in modo tempestivo
dalla communità e la semplicità della loro sintassi che permette a chiunque
di scriverne e aggiungerne nuove. La possibilità di salvare i log e di fornire l’output in diversi formati e ciò che lo rende uno dei migliori NIDS del
settore.
3.2
Requisiti Hardware
Per implementare Snort in una rete e realizzare un buon sistema di intrusion
detection è opportuno disporre di 2 macchine, ciascuna dotata di due schede
di rete e un hub. La prima macchina funzionerà da sensore, l’altra verrà utilizzata per archiviare i log e per permettere il monitoraggio delle statistiche
da remoto.
Più grande sarà la rete da monitorare, migliori dovranno essere le caratteristiche 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 di
una CPU sufficientemente rapida per processare tutti i pacchetti in tempo
reale.
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 disporre
di un processore da almeno 2Ghz per l’analisi dei pacchetti e 5Gb di spazio
libero 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 potenzialmente dannosi;
• il detection engine che controlla il pattern matching dei pacchetti con
le regole;
• i componenti di alerting e logging che generano gli allarmi e archiviano
i log.
Di seguito vengono analizzati i diversi componenti che fanno parte dell’architettura di Snort.
34
CAPITOLO 3. SNORT
Il Packet Decoder
Il packet decoder è il componente responsabile dell’analisi dei pacchetti. Esso ne determina il protocollo e la struttura, generando allarmi qualora vengano identificati pacchetti malformati. Si configura modificando il file di
configurazione /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 comportamento
dei pacchetti. Ogni preprocessore ha la funzione di identificare una diversa tipologia di attacco. Qualora il comportamento dei pacchetti dovesse risultare
dannoso, essi vengono inviati al detection engine che provvederà a verificarne 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 HTTPInspect e sfportscan e le loro principali opzioni di configurazione.
Il preprocessore HTTPInspect, si occupa di decodificare il traffico HTTP
e di identificare attacchi a livello applicativo che sfruttano eventuali vulnerabilità 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 global
IIS unicode map1 .
• detect_anomalous_servers
che genera un allarme se viene rilevato traffico HTTP su porte non
standard; è opportuno non attivare questa opzione se è prevista una
configurazione 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,
è:
1
Unicode è 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 rispettiva
combinazione 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 server HTTP utilizzato, scegliendo tra ‘all’, ‘apache’ e ‘iis’. Questa opzione 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 cifrato
SSL 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 traffico
di risposta, mentre 0 permette di ispezionare integralmente i payload
dei pacchetti.
• ascii [yes/no]
che permette di decodificare un URL che contiene sequenze di caratteri
ASCII.
• utf_8 [yes/no]
che permette di decodificare un URL che contiene sequenze di caratteri
UTF-8.
37
CAPITOLO 3. SNORT
• iis_unicode [yes/no]
che permette di usare la mappa di default, se non è specificata una IIS
Unicode Map.
• multi_slash [yes/no]
che permette di generare un allarme ogni volta che viene incontrata
una stringa contenente più caratteri ‘/’ consecutivi.
(Es. “pippo/////////pluto”)
• iis_backslash [yes/no]
che permette di generare un allarme ogni volta che viene incontrata
una 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 non
hanno alcun effetto.
• oversize_dir_length [non-zero positive integer]
che specifica la lunghezza massima di un URL. Generalmente la lunghezza media è di 300 caratteri.
• inspect_uri_only
che migliora notevolmente le prestazioni in quanto permette di esaminare 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 sulle
porte 80,3128 e 8080. Non sarà ispezionato il payload dei pacchetti di risposta del server, ma saranno decodificati gli URL contenenti caratteri ASCII
che potranno avere una lunghezza massima di 300 caratteri.
Il preprocessore sfportscan invece, si occupa di identificare la prima fase di
un attacco, dove l’attaccante cerca di acquisire informazioni sui protocolli
e sui servizi supportati da una vittima. Questo preprocessore, permette di
identificare qualsiasi tipo di Portscan.
A tal proposito, è necessario che sia abilitato il preprocessore flow 2 con
il 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 sfportscan
sono:
• 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’, ‘decoy_portscan’, ‘distributed_portscan’ oppure ‘all’ se si intende monitorare tutti i tipi di scan.
2
Il preprocessore flow è un prerequisito di funzionalità di altri preprocessori in quanto
lascia 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 di
sensibilità che si vuole assegnare al sensore.
• ignore_scanners { <ip_list> }
che definisce gli indirizzi IP che possono eseguire scansioni e pertanto
da ignorare.
• ignore_scanned { <ip_list> }
che definisce gli indirizzi IP che possono ricevere scansioni e pertanto
da 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 appartenenti a tutti i protocolli, saranno monitorati tutti i tipi di scansioni, il file
contenente i log dei Portscan sarà /var/log/snort/portscan, e il sensore
avrà una sensibilità alta.
Il Detection Engine
Il Detection Engine è il componente che riceve i pacchetti dai preprocessori e
si occupa di confrontarli con le regole di intrusion detection. Nel caso in cui
dovesse esserci una corrispondenza tra un pacchetto e più regole diverse, la
prima 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 generare un allarme per ciascun evento.
Per ridurre il numero di falsi positivi può essere configurato il file
threshold.conf. Siccome ogni evento è associato ad un gen_id e un sig_id,
conoscendo questi due valori, è possibile disabilitare completamente gli allarmi 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 accertarsi
che 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 venga
generato 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 generare gli allarmi, il secondo per archiviare i pacchetti che hanno causato la
generazione 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 nel
file 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 tipo
di output. Nel caso in cui si intenda archiviare i dati in un server Syslog, va
specificato se tale server sia Unix o Windows. Per archiviare i dati in un file
compatibile con Tcpdump, è sufficiente configurare il nome da dare a tale
file. Nel caso si intenda archiviare i dati in un database, dovrà essere inserito
il nome del database, l’username e la password.
3.4
Modalità di Funzionamento
Snort ha diverse opzioni di funzionamento che possono essere adottate a
seconda del contesto in cui viene installato.
• -A alert-mode: Permette di specificare la modalità di generazione degli
allarmi che può essere di tipo full, fast, none e unsock. L’opzione full è
impostata di default e permette di avere informazioni complete sull’attacco, fast invece permette di rendere più rapido il sistema generando 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 processo
attraverso 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 configurazione
specificato.
• -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 di
non 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 di
verificare il pattern matching con l’header dei pacchetti, oppure con stringhe
contenute nel payload dei pacchetti.
Una buona regola deve essere specifica e chiara in modo tale da ridurre
falsi negativi e falsi positivi, e deve contenere una descrizione accurata dell’attacco fornendo referenze per eventuali approfondimenti esterni.
Una regola è composta da un header (l’intestazione della regola) e un
body (il corpo della regola).
44
CAPITOLO 3. SNORT
Header
L’header è la parte principale della regola e comprende: l’azione da intraprendere (alert, log, pass, ...), il protocollo utilizzato, l’indirizzo IP e la porta
sorgente, l’indirizzo IP e la porta di destinazione. Una volta trovata una corrispondenza tra una regola e il contenuto di un pacchetto, è possibile scegliere
tra 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 come
la keyword LOG.
# Esempio
alert udp any 19 <> any 7
Nel precente esempio viene generato un allarme, qualora venga riconosciuto un pacchetto UDP proveniente dalla porta 19 di un qualsiasi indirizzo
IP sorgente, verso la porta 7 di un qualsiasi indirizzo IP di destinazione. I
parametri aggiuntivi, come il testo del messaggio da scrivere nei log, saranno
configurati nel body.
Body
Il body completa la definizione della regola e comprende una serie di opzioni
che 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 tentativo di effettuare un attacco DoS, l’identificatore della regola che ha generato
l’allarme è 271 e tale regola è stata revisionata 3 volte. Vengono inoltre
dati 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 pacchetti
da 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 destinazione
dei 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 tool
come Traceroute, Tracert o Netroute e supporta i simboli ‘>’,‘<’ e ‘=’, mentre l’opzione ‘seq’, permette di selezionare i pacchetti con numero di sequenza
statico.
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, identificherà 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 pacchetti
con numero di acknowledgement statico, l’opzione ‘itype’ esamina invece il
valore del campo itype dei pacchetti ICMP, al fine di identificare i pacchetti
con valori non validi.
Lo Snort ID ‘sid’ identifica univocamente le regole di Intrusion Detetion. I
valori 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 creare le proprie regole. In questo ambito l’opzione ‘rev’ rilascia informazioni
circa il numero di revisioni avuto da una regola, l’identificatore di sicurezza
‘priority’ assegna una priorità ad ogni regola e l’opzione ‘classtype’ permette
di raggruppare le regole in base ad una categoria di attacco.
L’opzione ‘reference’, inoltre, permette di associare a ciascuna regola
una 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 di
una regola di intrusion detection, troviamo l’opzione ‘msg’ che permette di
associare alla regola un messaggio che informerà sul tipo di attacco potenzialmente 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. La
sintassi di questa opzione è
logto: "PATH/FILE.estensione";
Snort fornisce, inoltre, la possibilità di definire delle variabili da usare
nelle 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 di
alleggerire 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 saranno
inclusi 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 al
file 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 pacchetti
in ingresso e uscita dal server DNS e non su tutto il restante traffico di rete
che non sarebbe comunque vulnerabile ai tipi di attacchi controllati dalle
regole.
È anche possibile disabilitare una categoria di regole commentando la
stringa corrispondente al file include. Per esempio se non è configurato un
server web, sarà possibile aggiungere il simbolo ‘#’ davanti alle seguenti
stringhe 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 avere
maggiori informazioni sia su come si è sviluppato l’attacco, che sull’entità in
termini di pericolosità dello stesso. Il primo passo che permette di raccogliere
maggiori informazioni è l’analisi degli eventi. Snort produce dei log di questo
formato:
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 componente di Snort ha generato l’allarme, il secondo indica il SID della
firma 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 è direttamente
proporzionale 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 15
ottobre 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 protocollo
utilizzato.
Terminata l’analisi di Snort, nel prossimo capitolo si esaminerà la sua
implementazione 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 che
vengono compiute abusivamente all’interno di un sistema informatico.
Durante il lavoro di progettazione dell’Intrusion Detection System si sono
tenuti in considerazione diversi requisiti, tra i quali:
• usabilità al fine di rendere comprensibili anche a tecnici non esperti i
risultati prodotti dal sistema di intrusion detection;
• adattabilità a nuovi attacchi. A questo scopo gli aggiornamenti devono essere eseguiti in modo automatico e tempestivo, limitando la
manutenzione del sensore;
• ottimizzazione del rapporto qualità/prezzo allo scopo di ottenere le
migliori prestazioni utilizzando una macchina con risorse limitate.
Si è scelto, pertanto, di adottare esclusivamente software gratuiti, realizzati
dalla comunità OpenSource e che presentano tutte le caratteristiche essenziali
per implementare un valido sistema di sicurezza.
Nel corso di questo capitolo, si analizzeranno le fasi fondamentali d’installazione e configurazione di un Intrusion Detection System, completo di
55
interfaccia web, per la visualizzazione degli allarmi e per l’aggiornamento
automatico delle regole. Per prima cosa verranno descritte le fasi di installazione dei diversi software necessari per il funzionamento dell’IDS (vedi Capitolo 4.3). Successivamente, verrà presentata la fase di test (vedi Capitolo
4.4), e la fase di configurazione dei componenti necessari all’amministrazione
remota via SSH (vedi Capitolo 4.5). Per concludere, verranno presentate in
dettaglio le ottimizzazioni apportate alle regole di intrusion detection al fine
di 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 sviluppo 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, la
conoscenza approfondita della rete e delle sue peculiarità diventa un requisito fondamentale per lo sviluppo di un’infrastruttura robusta ad attacchi
e tentativi di intrusione. Pertanto, prima di procedere alla configurazione
dell’IDS si è valutato:
• il tipo risorse da proteggere, al fine di comprendere quali tipi di dati
vengono trattati e di capire quali sono i rischi che si corrono nel caso
in cui venga infranta la loro integrità 1 , disponibilità 2 e riservatezza 3 ;
• il design e la topologia della rete, per individuare eventuali misure di
sicurezza già implementate, e la collocazione dei dati da proteggere;
• l’utilizzo di hub, switch o entrambi, per stabilire le modalità di implementazione e il posizionamento dei sensori nella rete;
1
Per integrità si intende la protezione dei dati nei confronti delle modifiche non
autorizzate del loro contenuto.
2
Per disponibilità si intende la prevenzione da attacchi che mirano a rendere i dati non
accessibili anche a coloro che ne hanno il diritto.
3
Per riservatezza si intende la protezione dei dati scambiati tra due o più interlocutori
al 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 firewall, per valutare l’opportunità di rilevare anche i tentativi di attacco
bloccati dal firewall stesso.
Il sistema di intrusion detection è stato implementato in una rete caratterizzata 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 interna
sono stati collocati tutti gli host utilizzati dagli utenti per l’archiviazione e
l’elaborazione dei dati, nella DMZ sono stati inseriti i server web, SMTP,
POP3 e un database ORACLE contenenti gli archivi dei dati, mentre la rete
esterna è 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 non
garantisca alcuna protezione da attacchi provenienti dall’interno della rete;
inoltre, nel caso in cui un intruso, che agisce all’esterno del firewall, riesca
ad aggirare il firewall, nessun log sul traffico di rete generato viene mantenuto.
Disponendo di una sola macchina per l’implementazione del sistema di
intrusion detection, questa è stata configurata per agire contemporaneamente da sensore per le intrusioni, da database in cui archiviare i log generati
dal 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 della
configurazione di un NIDS è la scelta della sua posizione all’interno della
rete. Installare il sensore all’esterno del firewall non sembra la scelta più
opportuna, in quanto questa scelta lo esporrebbe ad attacchi provenienti
dall’esterno; dato che i dati da proteggere sono collocati nei database posti
nella DMZ si è quindi pensato di installare il sensore in questo segmento di
rete (vedi Figura 4.2).
Per l’installazione e la configurazione dell’Intrusion Detection System,
inoltre, sono state identificate come necessarie le seguenti tecnologie, che
verranno 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 visualizzazione
grafica dei log (http://secureideas.sourceforge.net);
• nTop (www.ntop.org) per analizzare e monitorare il traffico anomalo;
• Oinkmaster (http://oinkmaster.sourceforge.net) per aggiornare
automaticamente 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 configurazione
dei 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 Operativo
per la gestione delle risorse del sensore. Per questo lavoro di tesi, si è scelto il
sistema operativo CentOS v4.4[4] in quanto premette di avere una maggiore
stabilità anche in realtà estese come quelle ‘enterprise’, più ampie delle comuni reti domestiche. Per evitare di occupare risorse che potrebbero essere
necessarie al software di intrusion detection, è stata effettuata un’installazione minimale del Sistema Operativo, priva di interfaccia grafica. Inoltre,
poichè il sistema viene gestito da riga di comando, si può fare a meno del
sistema grafico X window 4 [26].
4
X Window System, ben noto in gergo come X11 o ancor più semplicemente X, è di
fatto 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 installati sono stati necessari per questo lavoro di tesi. In particolare, i servizi
non necessari, quali ad esempio apmd che si occupa del risparmio energetico,
cups che è il server di stampa, isdn che permette di effettuare connessioni
tramite modem ISDN, nfslock che permette ai client NFS di bloccare i file
presenti sul server, pcmcia che permette di rilevare l’eventuale inserimento
o l’estrazione di una scheda PCMCIA, portmap che converte i numeri dei
programmi RPC nei numeri di porta del protocollo DARPA, sono stati disabilitati per migliorare le performance dell’infrastruttura mediante i seguenti
comandi:
[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 configurare
le 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 modificare il contenuto del file ifcfg-eth0.
A questo punto si digitano le seguenti righe di codice personalizzate che
permettono 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 se
il dispositivo è attivato all’avvio;
• BOOTPROTO, segnala se c’è un protocollo per l’assegnazione dell’indirizzo IP, e può essere configurato con le opzioni static se l’indirizzo
IP della scheda di rete è statico, bootp se viene utilizzato il protocollo
BOOTP, dhcp se viene utilizzato il protocollo DHCP;
• IPADDR, corrisponde all’indirizzo IP della scheda di rete; questa opzione non va configurata nel caso in cui si utilizzano i protocolli DHCP
o 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 server
DNS (Domain Name Server). Analogamente a quanto fatto precedentemente,
si modifica il file /etc/resolv.conf inserendo la seguente riga di codice che
identifica 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 rispettivo server DNS.
La configurazione di rete è a questo punto terminata. Nel prossimo paragrafo verrà descritta in dettaglio la configurazione del database MySQL e del
server 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 grafica
che sarà utilizzata per gestire gli allarmi generati dal software di intrusion
detection Snort. A tal proposito si è scelto di utilizzare Apache[2] che è la
piattaforma server Web più diffusa e MySQL[8] che è un DBMS relazionale, composto da un client e un server, utilizzabile sia in ambiente Unix che
Windows.
Prima di procedere alla configurazione del server web Apache e del server
MySQL è opportuno aggiungere al sistema un nuovo utente chiamato snort
che non abbia i privilegi dell’utente root ma che possa compiere tutte le
operazioni necessarie al processo di intrusion detection.
[root@localhost ~]# groupadd snort
groupadd: group snort exists
[root@localhost ~]# useradd -g snort snort -s /sbin/nologin
5
Un Database Management System è un sistema software che consente la creazione e
la modifica di un database da parte di più utenti.
62
I servizi Apache e MySQL vengono, poi, avviati mediante i seguenti
comandi:
[root@localhost ~]# chkconfig httpd on
[root@localhost ~]# chkconfig mysqld on
[root@localhost ~]# service httpd start
Avvio di httpd:
[
OK
]
[
OK
]
[root@localhost ~]# service mysqld start
Avvio di MySQL:
Per la configurazione del server web Apache è sufficiente modificare, in
base alle proprie esigenze, il file httpd.conf che si trova nella directory
/etc/httpd/conf/ oppure nella directory /usr/local/apache/conf/ che
contiene 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ò coincidere
con 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 viene
eseguito il processo httpd : per ragioni di sicurezza è sempre opportuno
utilizzare utenti che non hanno i privilegi dell’utente root come apache
o nobody;
User apache
Group apache
63
• DocumentRoot che va configurata con la directory che conterrà i file
HTML 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 corretto funzionamento del server web: la configurazione di default integra
i 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 alla
configurazione e alla gestione amministrativa del database MySQL. Per prima
cosa, è necessario collegarsi al database con i privilegi di amministratore
dell’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 software
di 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 download dell’archivio all’interno del quale è presente il file create_mysql. Si
decomprime, quindi, nella diretory /etc/snort/ il file create_mysql, contenente i comandi per la generazione delle tabelle. Tale file è contenuto nella
subdirectory /schemas/ dell’archivio snort-2.6.0.2.tar.gz, scaricabile da
www.snort.org.
La creazione delle tabelle avviene con il seguente comando che esegue, a
sua 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 database
dell’utente root. Dopo aver inserito la password, sarà portata a termine
l’importazione delle tabelle e sarà, quindi, opportuno controllare che tutto
sia 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 il
comando 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 visualizzare
le tabelle in esso contenute.
mysql> use snort
67
Reading table information for completion of table and column
names
You can turn off this feature to get a quicker startup with -A
Database changed
Se tutte le operazioni sono state compiute correttamente, l’output dovrebbe essere come segue:
mysql> show tables;
+------------------+
| Tables_in_snort
|
+------------------+
| data
|
| detail
|
| encoding
|
| event
|
| icmphdr
|
| iphdr
|
| opt
|
| reference
|
| reference_system |
| schema
|
| sensor
|
| sig_class
|
| sig_reference
|
| signature
|
| tcphdr
|
| udphdr
|
+------------------+
16 rows in set (0.00 sec)
68
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à trattata
nel prossimo paragrafo, può cominciare.
4.3.3
Setup di Snort v2.6
Il software di intrusion detection Snort e le sue regole, possono essere scaricate dal sito ufficiale www.snort.org. Dopo aver installato il programma e decompresso le regole nella cartella /etc/snort/, la configurazione di
Snort può avere inizio aprendo il file /etc/snort/snort.conf contenente le
impostazioni di default.
[root@localhost ~]# vi /etc/snort/snort.conf
In aggiunta alle suddette regole di default devono essere specificati i dati
relativi 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 database
MySQL
output database: log, mysql, user=snort password=snort
dbname=snort host=localhost
Fatto questo, Snort è funzionante ma non è ancora possibile visualizzare
l’output degli eventi tramite un’interfaccia HTML.
Per eseguire Snort è sufficiente portarsi nella directory /usr/sbin/, ed
eseguire 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 ==-,,_
o"
-*> Snort! <*)~
’’’’
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’opzione -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 -dev
6
Nei 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 server web Apache e del database MySQL. Nel prossimo paragrafo verranno esaminati alcuni componenti aggiuntivi che offrono un’interfaccia più amichevole
a 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 specifiche per ogni database, ma utilizzando query SQL standard, si utilizza
il componente AdoDB[1] (Active Data Objects DataBase) che va installato
nella directory /var/www.
Per analizzare tramite un’interfaccia HTML, gli allarmi generati da Snort
si installa, invece, il Basic Analysis and Security Engine nella directory /var/
www/html.
A questo punto è opportuno rinominare prima la directory del componente BASE[3] /base-1.2.6 in /base (questo semplicemente per semplificare le
operazioni 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 alla
pagina https://192.168.1.22/base si potrà visualizzare il seguente messaggio:
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 Engine, cliccando prima su ‘Setup page’ e nella pagina che segue su ‘Create
BASE 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
BASE tables
Description
Status
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 visualizzazione 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, aggiungendo 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 di
controllo, la pagina https://192.168.1.22/base visualizzerà la schermata
principale di BASE (vedi Figura 4.3). Nel pannello di controllo si può scegliere se visualizzare gli allarmi più recenti o quelli più frequenti e raggrupparli
in base alla porta sorgente o di destinazione o in base al protocollo utilizzato. Per ogni evento è possibile, inoltre, visualizzare innumerevoli dettagli ed
eseguire il download del payload del pacchetto che l’ha generato (vedi Figura
4.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 la
pericolosità 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 consultazione degli eventi e si integra totalmente con Snort, tanto da sembrare uno
strumento unico. Nel prossimo paragrafo sarà esaminato nTop, uno strumento che permette di sfruttare il server web e il database per esaminare il
traffico di rete.
4.3.5
Setup di nTop
Per mezzo di nTop[10] si può monitorare e analizzare il traffico generato
dai diversi protocolli. Per quanto riguarda la sua configurazione, è necessario 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 con
nTop sulla porta 3001 con protocollo HTTPS. Per questo motivo, si deve
configurare nTop modificando il file /etc/ntop.conf, verificando che la porta
3001 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
7
Admin user password has been set
GPG è un software cifratura asimettrica per la criptazione di messaggi, documenti e
file che agisce utilizzando una coppia di chiavi (pubblica e privata) che vengono scambiate
tra 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 certezza
della 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’indirizzo
https://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 monitoraggio della rete verrà esaminato nel prossimo paragrafo un altro strumento
che permette di automatizzare il download delle regole di intrusion detection
aggiornate, OinkMaster.
4.3.6
Setup di OinkMaster
Oinkmaster[11] è uno script scritto in linguaggio Perl che effettua il download
automatico delle regole aggiornate disponibili su www.snort.org. L’utilizzo
gratutito di OinkMaster è vincolato alla registrazione di un account su www.
snort.org.
Prima di procedere can la configurazione di OinkMaster, si deve modificare l’utente proprietario della directory contenente le regole di Snort per
poter 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. Nella
directory /etc viene creato il file oinkmster.conf che va configurato con un
URL valido utilizzato da OinkMaster per effettuare il download delle regole
aggiornate. 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 comando che esegue lo script oinkmaster.pl in base alle configurazioni stabite
nei file /etc/oinkmaster.conf e /etc/autodisable.conf. Il comando si
occupa 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 fondamentale per un sistema di intrusion detection è la possibilità di automatizzarne alcune fuzionalità. A questo scopo, si crea nella cartella /etc un file
di testo chiamato snort-oinkmaster che conterrà il codice per l’esecuzione
di 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 programma 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 esegue
ogni ventiquattro ore. Aprendo il file /etc/crontab è possibile visualizzare
l’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 nella
directory /etc/cron.daily.
La sintassi della stringa è relativamente semplice. La prima colonna indica i
minuti (0-59), la seconda le ore (1-23), la terza il giorno (1-31), la quarta il
mese (1-12), la quinta il giorno della settimana (0-7 dove 7 corrisponde alla
domenica). Il carattere ‘*’ significa che tutti i valori del rispettivo campo
sono validi.
Con OinkMaster si completa la realizzazione e configurazione del sistema
di intrusion detection. A questo punto non resta che testarne il funzionamento.
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 Metasploit
per 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 scansioni
delle porte, Nmap[9] è risultato il tool più completo in grado di eseguire
diversi tipi di scansioni, di frammentare i pacchetti nel tentativo di aggirare
gli IDS e di mantenere parzialmente l’anonimità mediante una tecnica detta
Decoy 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 scansione in cui la chiamata di sistema connect() fornita dal Sistema Operativo
di chi effettua la scansione, è usata per aprire una connessione ad ogni porta interessante sulla macchina di destinazione. In questo tipo di scansione,
l’attaccante invia alla vittima un pacchetto TCP con flag SYN attivo. Se
la porta obiettivo della scansione risulterà aperta, l’attaccante riceverà in
risposta 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 connessione. In altre parole, se la porta vittima della scansione è in ascolto, la
chiamata di sistema connect() avrà luogo e l’handshake verrà completato, in
caso 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 genera
i seguenti allarmi:
• (portscan) TCP Portscan: 304:61441
Il preprocessore sfPortscan rileva il traffico anomalo e identifica la scansione delle porte che costituisce la prima fase di un attacco la quale non
danneggia la vittima ma permette di ottenere innumerevoli informazioni su di essa. Tali informazioni potranno essere sfruttate in seguito per
danneggiare il sistema o assumerne il controllo. I numerosi tool presenti in rete che realizzano i Portscan, rendono la scansione delle porte un
attacco alla portata di chiunque. Tutti i sistemi sono soggetti a questo
tipo 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 un
attaccante sia alla ricerca di vulnerabilità sulla vittima.
I sistemi
vulnerabili sono analoghi a quelli discussi per il precedente allarme.
SYN Scan
Un attacco analogo al TCP Connect() Scan è il SYS Scan. La differenza tra i
due attacchi consiste nel fatto che nel SYS Scan l’handshake non viene completato. L’attaccante invia, quindi, un pacchetto TCP con flag SYN attivo,
se la porta da controllare è aperta riceverà in risposta un pacchetto TCP con
i flag SYN e ACK attivi al quale Nmap risponderà chiudendo la connessione
con un pacchetto TCP con flag RST attivo. Se la porta è chiusa, l’attaccante
riceverà un pacchetto TCP con flag RST attivo che chiuderà la connessione.
In entrambi i casi, la connessione non verrà mai completata e per questa
ragione difficilmente comparirà nei file di log, anche se generalmente viene
riconosciuta 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 il
TCP Connect() Scan già descritti precedentemente:
Viene generato per qualsiasi attività di scanning.
Segnala una possibile situazione di pericolo dovuta ad una porta trovata
aperta.
FIN Scan
Il FIN Scan ha delle sostanziali differenze rispetto alle scansioni analizzate precedentemente. L’attacco è caratterizzato dall’invio di pacchetti TCP
83
anomali, alle porte della vittima, aventi solo il flag FIN attivo. Le specifiche
tecniche dalla RFC 793[28] prevedono che un host che riceve un pacchetto con flag FIN attivo, nel caso in cui la porta sia chiusa, risponda con un
pacchetto con flag RST attivo, nel caso in cui la porta sia aperta, ignori il
pacchetto. Da evidenziare che alcuni sistemi come Windows, Cisco, HP-UX,
IRIX non seguono lo standard e rispondono inviando in qualsiasi caso un
pacchetto 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 viene
generato 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. I
sistemi affetti da questo tipo di attacco sono quelli che rispettano la
RFC 793. Non sono conosciuti casi di falsi positivi riguardanti questo
allarme.
XMAS Scan
Questo tipo di scansione è analoga al FIN Scan con la differenza che i pacchetti TCP inviati hanno attivi i flag FIN, URG, e PSH. Analoghi sono i
problemi 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 porta
aperta.
• SCAN nmap XMAS
Individua la scansione XMAS e rileva Nmap come programma con cui
potrebbe essere stata effettuata. Tipicamente la vittima, nel caso in
cui la porta a cui è stato inviato il pacchetto sia chiusa, risponderà con
un pacchetto TCP con flag ACK e RST attivi, nel caso in cui la porta
sia aperta, non invierà alcuna risposta. Tutti i sistemi sono vulnerabili
a questo tipo di scansione e non sono conosciuti casi di falsi positivi in
quanto i flag FIN, PSH e URG dei pacchetti TCP, non sono mai stati
attivi contemporaneamente nel normale traffico TCP, ad eccezione del
caso 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 attivi
sul protocollo UDP. Tipicamente la vittima, nel caso in cui la porta attaccata
sia aperta non invierà risposta alcuna, nel caso in cui sia chiusa, invierà un
pacchetto 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 alla
ricerca di servizi attivi su questo protocollo. Tutti i sistemi sono vulnerabili a questo tipo di attacco, che combinato con altri attacchi può
85
permettere, di rilevare anche il Sistema Operativo utilizzato dalla vittima. Analogamente a quanto avviene per il TCP Portscan non sono
conosciuti falsi positivi.
IP Protocol Scan
Questo tipo di scansione, permette di determinare quali sono i protocolli supportati 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 protocolli
supportati 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 viene
generato da un altro tool.
• BAD-TRAFFIC Unassigned/Reserved IP protocol
Questo allarme viene generato quando in rete viene identificato un pacchetto che utilizza un protocollo non supportato o riservato. Questo
non dovrebbe accadere in circostanze normali.
Decoy SYS Scan
Il Decoy Scan è una variante applicabile a tutte le precedenti scansioni che
permette di rimanere parzialmente anonimi che nel nostro caso è stata integrata al SYS Scan. Nel comando di Nmap che implementa l’attacco, è pos-
86
sibile specificare altri indirizzi IP dai quali sembrerà provenire la scansione
in 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’output di Snort sarà analogo a quello generato per una qualsiasi scansione,
con la differenza che la provenienza dei pacchetti sospetti sarà costituita sia
dall’indirizzo IP dell’attaccante che da quelli indicati dopo l’opzione -D del
comando Nmap eseguito. Inserendo dopo l’opzione -D un numero elevato di
indirizzi 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 dei
pacchetti è stata implementata insieme alla scansione SYS Scan. Ne consegue
che il seguente comando ha gli stessi effetti di un normale SYN Scan con la
differenza 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 scansione
non ha rilevato le porte aperte e di conseguenza Snort non ha generato allarmi
di alcun tipo.
TCP Connect() Scan con Frammentazione
Il test è stato quindi ripetuto implementando la frammentazione dei pacchetti
al 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 porte
aperte vengono rilevate correttamente, ma Snort rileva l’attacco generando
gli stessi allarmi descritti per il TCP Connect() Scan.
87
Nonostante, complessivamente, Nmap si sia rivelato un tool particolarmente
adatto 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à conosciuti che permettono di sfruttare vulnerabilità e di acquisire in maniera non
autorizzata dei privilegi sulla macchina obiettivo di un attacco, è anche un
ambiente completo per scrivere, testare e usare codici maliziosi[18]. Esso fornisce una solida piattaforma di ricerca di vulnerabilità, utilizzabile non solo
allo scopo di testare un Intrusion Detection System ma anche per eseguire
dei Penetration Test. Dopo aver installato il programma, l’interfaccia web si
avvia 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 pannello di controllo di Metasploit (vedi Figura 4.5), e si seleziona, un exploit ed
un payload che Metasploit provvederà ad inviare alla vittima (vedi Figura
4.6).
Di rilevante importanza è il fatto che Metasploit, prima di inviare i pacchetti contenente codice malizioso, controlla che la porta con cui si cerca
di stabilire una connesione sia aperta. Snort rileverà tale condotta come
Portscan e produrrà di conseguenza un allarme. Se la porta risulterà chiusa
Metasploit non eseguirà l’attacco e Snort non produrrà alcun allarme.
Di seguito si esamineranno gli exploit eseguiti in questo lavoro di tesi per
testare 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 utilizzato per analizzare i log generati da un server web e per produrre delle
statistiche sul suo utilizzo.
Dopo aver eseguito l’exploit, seguendo le istruzioni descritte in precedenza, 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 web
dovuta al fatto che un attaccante può iniettare codice a sua discrezione
sfruttando la vulnerabilità dello script awstats.pl. I sistemi vulnerabili a questo tipo d’attacco sono quelli su cui è installato il tool Awstats
versione 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 che
permette 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 attacco in quanto è stata riscontrata una richiesta /cgi-bin/, costituita
da un URL contenente approssimativamente 330 caratteri Unicode, che
può causare un DoS del server. Un attaccante può anche inviare un
URI 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 vulnerabile
a questo tipo di attacco che può essere sfruttata dall’attaccante per ottenere un elenco completo delle directory contenute nella root directory
o 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 server
web.
Riconoscendo un accesso al file viewtopic.php Snort genera il seguente
allarme:
• WEB-PHP viewtopic.php access
Viene riconosciuto il tentativo di sfruttare la vulnerabilità descritta di
phpBB. L’attaccante può sfruttare questo attacco per poter ottenere
password e altre informazioni contenute nel database. I sistemi vulnerabili sono quelli su cui è installato phpBB Group e phpBB versioni
2.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 richieste HTTP GET generalmente utilizzate per ottenere il contenuto delle
pagine HTML. La sua vulnerabilità può essere sfruttata per causare un Overflow di Buffer che permette di eseguire codice arbitrario sul server.
Snort, ancora una volta, rileva il tentativo d’attacco e genera i seguenti
allarmi:
• (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 caratteri UTF-8 la quale può essere sfruttata per portare a termine un
attacco 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 precedente
exploit, viene identificato un pacchetto contenente un URI costituito
da un numero eccessivo di caratteri Unicode tale da presentare il rischio
di Denial of Service. Casi di falsi positivi posono identificarsi qualora
gli utenti di una rete utilizzino in maniera autorizzata applicativi che
generano 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 completamente
personalizzabile su un sito web. La vulnerabilità è stata riscontrata nel file
misc.php che permette di iniettare ed eseguire codice PHP arbitrario sul
server. In questo caso il test dell’IDS ha fallito in quanto, dopo aver eseguito
l’exploit, Snort non ha rilevato l’attacco ma ha riconosciuto il traffico come
affidabile.
Dall’analisi effettuata, risulta che su quattordici attacchi diversi, uno di questi, il SYS Scan con Frammentazione, non è stato eseguito con successo in
quanto Nmap non è riuscito ad inviare correttamente i pacchetti frammentati; un’altro di questi, il vBulletin misc.php Template Name Arbitrary Code
Execution non è stato per nulla rilevato da Snort che ritiene affidabile il
contenuto dei pacchetti generati per questo attacco. I restanti 12 attacchi
sono stati tutti rilevati da Snort anche se sono stati individuati 3 casi possibili di falsi positivi. I primi due relativi agli allarmi SCAN nmap XMAS
e ICMP PING NMAP in cui Snort potrebbe generare questi allarmi anche
se gli attacchi sono stati realizzati mediante tool diversi da Nmap. L’ultimo
falso positivo, di cui si tornerà a parlare nel Paragrafo 4.6, è relativo all’al93
larme OVERSIZE REQUEST-URI DIRECTORY generato sia dall’attacco
IIS 5.0 WebDAV ntdll.dll Overflow che dall’attacco IA WebMail 3.x Buffer
Overflow ; in questo caso il falso positivo si riscontrerebbe qualora gli utenti
della rete fossero autorizzati ad utilizzare applicazioni che generano richieste
HTTP contenenti più di 300 caratteri Unicode le quali sarebbero interpretate
da Snort come traffico anomalo.
Complessivamente sia gli attacchi effettuati con Nmap che quelli implementati con Metasploit hanno dimostrato l’efficacia di Snort nel rilevamento delle
intrusioni. Tuttavia, l’attacco vBulletin misc.php Template Name Arbitrary
Code Execution è sufficiente per dimostrare la non infallibilità degli strumenti di intrusion detection.
Di seguito sono riportate due tabelle riassuntive riguardo gli attacchi eseguiti
con Nmap (Tabella 4.1) e con Metasploit (Tabella 4.2), gli eventi generati
per ciascun attacco e i casi possibili di falsi positivi. Successivamente nel
paragrafo seguente, si esaminerà l’utilizzo di un sistema client/server SSH da
utilizzare per l’amministrazione remota dell’IDS.
94
Attacco
Evento Generato
TCP Connect() Scan
TCP Portscan
Falsi Positivi
Open Port
SYN Scan
TCP Portscan
Open Port
FIN Scan
TCP Portscan
Open Port
SCAN FIN
XMAS Scan
TCP Portscan
Open Port
SCAN nmap XMAS
XMAS scan eseguito
con un tool diverso da
NMAP
UDP Scan
UDP Portscan
IP Protocol Scan
IP Protocol Scan
ICMP PING NMAP
ICMP PING eseguito
con un tool diverso da
NMAP
BAD-TRAFFIC
Unassigned/Reserved
IP protocol
Decoy SYS Scan
TCP Portscan
Open Port
SYS Scan con Fram-
NESSUNO
mentazione
TCP Connect() Scan TCP Portscan
con Frammentazione
Open Port
Tabella 4.1: Tabella degli attacchi eseguiti con Nmap.
95
Attacco
Evento Generato
AWStats configdir Re-
WEB-CGI awstats ac-
mote Command Exe-
cess
Falsi Positivi
cution
IIS
5.0
WebDAV OVERSIZE
ntdll.dll Overflow
Esecuzione
autoriz-
REQUEST-URI
zata di applicazioni
DIRECTORY
che generano richieste
HTTP
contenenti
più di 300 caratteri
Unicode
WEB-MISC WebDAV
search access
phpBB viewtopic.php WEB-PHP
Arbitrary Code Exe-
viewtopic.php access
cution
IA WebMail 3.x Buffer BARE BYTE UNIOverflow
CODE ENCODING
OVERSIZE
Esecuzione
REQUEST-URI
zata di applicazioni
DIRECTORY
che generano richieste
HTTP
autoriz-
contenenti
più di 300 caratteri
Unicode
vBulletin
misc.php NESSUNO
Template
Name
Arbitrary
Code
Execution
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 remota cifrata con un altro host inviando comandi testuali. Il fatto che l’intera
comunicazione avvenga in maniera cifrata ha fatto in modo che il protocollo
SSH diventasse uno standard de facto per l’amministrazione remota di sistemi
Unix e dispositivi di rete. L’utilità dell’amministrazione remota nasce dalla
possibilità di modificare, aggiornare ed effettuare interventi di manutenzione
sull’IDS (o su un host qualsiasi), anche se ci si trova fisicamente lontani dal
sensore. Si pensi agli enormi vantaggi del suo utilizzo in una rete di notevoli
dimensioni in cui sono dislocati più sensori IDS in edifici diversi.
La fase di configurazione dell’accesso remoto è molto semplice e si riduce a poche 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 distribuzioni Unix ne integrano uno, mentre per i sistemi Windows si può utilizzare un
client come Putty (www.chiark.greenend.org.uk/~sgtatham/putty)[13].
Digitando il seguente comando con i privilegi di utente root è possibile accede
ad una console che permette di avere il totale controllo dell’IDS e di compiere
qualsiasi operazione.
[root@localhost ~]#
ssh 192.168.1.22
Nel prossimo paragrafo si esaminerà l’ottimizzazione di Snort finalizzata a
limitare la generazione di falsi positivi.
4.6
Ottimizzazione di Snort
Capita frequentemente che Snort rilevi numerosi falsi positivi e che generi
allarmi 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 IP
sui 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 è dovuto affrontare il problema dei falsi positivi, in particolare è stato rilevato un
allarme che sicuramente non costituiva un attacco: l’Oversize Request-URI
Directory. L’allarme in questione, le cui caratteristiche sono state discusse nel Capitolo 4.4.2, veniva causato dai pacchetti contenenti URI costituiti
da un numero eccessivo di caratteri Unicode. In realtà gli utenti della rete,
utilizzavano a fini professionali, un applicativo che generava questo tipo di
URI. Si è pertanto deciso di disabilitare l’allarme relativamente al range di
indirizzi IP della rete privata.
Per procedere con la disattivazione delle regole che hanno generato l’allarme, 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_id
e il sig_id della regola che genera falsi positivi, sarà sufficiente creare delle
stringhe analoghe a quelle riportate di seguito per disabilitare i corrispettivi
allarmi:
suppress gen_id <valore1>, sig_id <valore2>,
by_src, ip 10.1.1.54
Nella precedente riga di codice, valore1 e valore2 sono rispettivamente il
gen_id e il sig_id della regola che si vuole disabilitare, mentre track by_src
permette di disabilitare il controllo delle regole relativamente al traffico proveniente 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 diretto
all’indirizzo IP 10.1.1.54. La stessa modifica può essere effettuata anche in
relazione 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 la
generazione di falsi negativi. Prima di procedere è, quindi, opportuno esaminare attentamente la documentazione fornita su www.snort.org in merito
alle 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 soffermando
l’attenzione sul software di intrusion detection Snort. Successivamente è
stato presentato il modello di Intrusion Detection System progettato durante
questo lavoro di tesi, il quale è soggetto a numerose possibilità di sviluppo
al fine di rendere l’architettura più completa e sicura. Vengono ora esposti
quelli che sono i possibili sviluppi futuri.
5.1
Incremento del Livello di Sicurezza
L’architettura proposta, garantisce il rilevamento delle intrusioni e il logging delle attività anomale; tuttavia, l’IDS progettato, deve necessariamente
interagire con l’esterno per poter permettere la visualizzazione dei log, esponendosi a tutti i pericoli di sicurezza che ne conseguono. Si è quindi pensato
ad un possibile intervento che potesse incrementare il suo livello di sicurezza. 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. Ciascuna
macchina deve essere dotata di due schede di rete. Il sensore utilizza la prima
scheda di rete per ricevere i pacchetti da analizzare e la seconda per inviare
i log degli eventi al database il quale, a sua volta, utilizza invece la prima
scheda 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 macchine
diverse
nettersi alla rete interna dalla quale sarà possibile accedere alle informazioni
contenute nel database (vedi Figura 5.1). È possibile perfezionare l’upgrade
configurando il sensore per non rispondere alle rischieste provenienti dall’esterno. Questo permette di rendere l’IDS difficile da rilevare e da attaccare e
può garantire un notevole incremento dell’affidabilità del NIDS e del livello
di sicurezza del sistema.
5.2
Realizzazione di un IDS Distribuito
Nel corso della tesi sono state illustrate diverse ragioni che hanno influenzato
la scelta del posizionamento del sensore nella DMZ (vedi Capitolo 4.2). Nel
caso in cui si intenda monitorare più segmenti di rete, risulta interessante
implementare un sistema che preveda un sensore per ogni segmento e che
gestisca in maniera centralizzata l’archiviazione dei log. Ogni sensore intercetta passivamente il traffico per mezzo della prima scheda di rete e invia i
log degli eventi al database centrale per mezzo della seconda scheda di rete. Il database, è accedibile solamente dalla rete interna. Un’architettura
di questo tipo, garantisce un monitoraggio efficiente degli eventi dell’intera
102
rete, e rende più facile un’eventuale azione di correlazione finalizzata alla
ricostruzione delle procedure di attacco.
5.3
Invio degli Allarmi via Email e SMS
Un Intrusion Detection System ideale, richiede un monitoraggio costante, situazione che nella realtà è difficilmente riproducibile. L’ultimo miglioramento
proposto è finalizzato ad informare in maniera tempestiva i CERT (Computer Emergency Response Team) aziendali di eventuali situazioni dannose.
Implementando un sistema che invii gli allarmi più gravi via email o SMS, sarebbe possibile informare in tempo reale le persone responsabili, permettendo
interventi tempestivi.
103
RINGRAZIAMENTI
Ringraziamenti
Alla fine di questo ciclo di studi rivolgo i miei più sentiti ringraziamenti a tutti
coloro che mi hanno accompagnato in questi tre anni. Ci tengo a ringraziare
particolarmente:
• Mamma, Papà che mi hanno sempre sostenuto, moralmente ed economicamente durante tutto il percorso di studi, senza i quali probabilmente questo momento non sarebbe mai arrivato;
• Federica che ha messo sempre il suo tocco di brio in qualsiasi cosa mi
riguardasse;
• Il relatore Prof. Ernesto Damiani e il correlatore Dott. Claudio Agostino Ardagna per l’aiuto costante fornito durante il lavoro di tesi e per
l’infinita pazienza e disponibilità mostrata;
• Il prof. Dario Forte e il Prof. Marco Cremonini per gli utili suggerimenti
e per la documentazione fornita;
• Il mio amico Vittorio con il quale ho trascorso un anno formidabile e
grazie al quale affrontare i problemi universitari è stato più semplice;
• Il mio amico Antonio senza il quale probabilmente l’ultimo anno a
Crema sarebbe stato una catastrofe;
• Mio Zio Franco che, anche se non è presente, mi ha iniettato indispensabili 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 anche
se sommerso dalle mille faccende comunali ha sempre trovato tempo da
dedicarmi;
• Gli amici di Bari in particolare Biagio, Giuseppe, Mario Z., Francesco,
Raffaele, Claudio, Alessandro, Amedeo, Mario C. ed Emiliano per gli
anni 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 a
farmi 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.
R Advisory CA-2001-26 Nimda Worm. http://www.cert.org/
[5] CERT
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 : intrusion
detection. Syngress Publishing, 2004.
[31] Bejtlich Richard. The Tao of Network Security Monitoring: Beyond
Intrusion Detection.
[32] Bejtlich Richard. Extrusion detection: security monitoring for internal
intrusions. Addison Wesley, 2006.
[33] Massaro Roberta. Metodologie di test per la sicurezza delle reti informatiche. Master’s thesis, Università degli Studi di Milano, Dipartimento
di Tecnologie dell’Informazione di Crema, 2003-2004.
[34] Northcutt, Stephen [et al.]. Inside network perimeter security. Sams
publishing, 2005.
[35] Northcutt Stephen, Novak Judy. Network intrusion detection. New
Riders, 2003.
[36] Soragni Michele. Sviluppo e implementazione di un sistema di analisi della sicurezza e di controllo del traffico su Reti IP. Master’s thesis, Università degli Studi di Milano, Dipartimento di Tecnologie dell’Informazione
di Crema, 2004-2005.
110

Progettazione di un Intrusion Detection System

Transcript

Documenti analoghi

Nuovo repository APT!

Scarica

Tecnologie innovative per il rilevamento e il

Installazione Pacchetti Alternativi

sviluppo e progettazione di una piattaforma e-learnig

Ethan Frome

Scarica il documento

L`ANELITO DI OETZI

DOWNLOAD/MANUALI/DIGITEK/Manuale Dataview

Ubuntu Desktop Guide - Documentazione ufficiale di Ubuntu

pdf ITA - The Italian Honey Project