Snort

Intrusion Detection Systems Snort

SNORT è un applicativo open Source sotto licenza GPL

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.

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 ful l, 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.

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

Bibliografia

• Danilo Vizzarro, "Progettazione di un Intrusion Detection System", December 2006.