Snort

SNORT è un applicativo open source con funzioni di tipo IDS distribuito con la licenza GPL.

Intrusion Detection Systems Snort

L'IDS viene installato collegando una o più sonde configurate per analizzare ogni pacchetto che circola nella rete, garantendo un ottimo punto di osservazione su tutti i movimenti nella nostra rete:

• analizza i pacchetti che transitano in rete, confrontandoli con un database di firme di attacchi;
• impara a riconoscere nuovi attacchi, introducendo nuove firme riconosciute come attacchi;
• verifica i protocolli utilizzati dai pacchetti, in modo da riconoscere eventuali anomalie nel traffico;
• rileva l'attività dei port scan, "esplorazione" che precede generalmente un attacco;
• segnala tutte le possibili minacce identificate da queste attività di controllo.

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à 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.

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.

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, 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 la global IIS unicode map.

• 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, è:

preprocessor http_inspect_server: 
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:

preprocessor http_inspect_server: 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.

• 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 
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 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.

• 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 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 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 
# 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.

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.
• -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.

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).

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;) 

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 pacchetti 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 
(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;
• F: per verificare se è attivo solo il flag FIN;
• P: per verificare se è attivo solo il flag PSH;
• R: per verificare se è attivo solo il flag RST;
• S: per verificare se è attivo solo il flag SYN;
• U: per verificare se è attivo solo il flag URG;
• +: usato per identificare se sono attivi altri flag oltre quello specificato

(Es. A+ identificherà i pacchetti con attivi i flag AF,AP,AR,AS,AU);

• *: usato per verificare se sono attivi i flag specificati (Es. *AS, identi-

ficherà solo i pacchetti con attivi i flag AS);

• !: usato per verificare se sono attivi i flag diversi da quello specificato

(Es. !S identificherà i pacchetti con attivi uno o più flag tra i seguenti: A,F,P,R,U).

Inoltre, se da un lato l’opzione ‘ack’, permette di selezionare i 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 è:

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ù 
# 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 
# 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 
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 

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.

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:

[**] [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ù 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.

Collegamenti esterni

• (EN) Sito Ufficiale
• (EN) Guide all'uso di Snort
• (EN) Snort Virtual Machine
• (IT) (EN) Snortattack Snort guide, tips and tricks, SUG Snort User Group Italiano ufficiale