================================================================================
========================== SNORT - A Lightweight NIDS ==========================
================================================================================
"Un computer sicuro e' un computer spento". - Se siete avvezzi all'ambiente
dell'informatica vi sara' sicuramente capitato di sentire questa frase molte
volte. Per quanto a prima vista esagerata essa esprime perfettamente
l'importanza dell' implementazione di un buon sistema di sicurezza su
qualsiasi computer acceso ;) e, per di piu', connesso ad una rete, sottoposto,
quindi, ad un numero elevatissimo di potenziali attacchi.
Nel panorama di tool che si offrono di dare una mano all'amministratore di
sistema in questo senso, emerge SNORT, un leggero e flessibilissimo NIDS
(Network Intrusion Detection System - Sistema di Rilevamento Intrusioni di
Rete).
Cenni generali
==============
Il lavoro di SNORT consiste nel captare il traffico di rete e di scandagliare
i pacchetti che ne fanno parte alla ricerca di quelli di essi che presentano
caratteristiche anomale o sospette, nonche' tipiche dei piu' conosciuti
attacchi, per metterne al corrente l'amministratore di sistema.
Ma la flessibilita' di SNORT fa si' che il suo impiego non si limiti a questo
scopo soltanto. Esso, infatti, si dimostra estremamente utile anche in altre
molteplici situazioni:
- individuare la presenza di backdoor, trojan e server per attacchi Denial of
Service;
- rilevare eventuali portscan, che evidenziano un interesse decisamente
sospetto nei confronti del nostro sistema o della nostra rete da parte di
qualche utente un po' malizioso;
- monitorare il traffico generato dalle applicazioni lanciate da utenti della
nostra rete, all'eventuale ricerca di quello generato da specifici programmi
del cui uso (o abuso... ) si vuole essere messi al corrente;
Essenzialmente, le carateristiche che rendono SNORT un tool degno di nota
sono le seguenti:
- e' in grado di rilevare sia attacchi provenienti dall'esterno, che eventuali
attacchi lanciati dall'interno della rete che si controlla;
- e' estremamente leggero e performante, la sua compilazione non richeide piu'
di pochi minuti e cosi' anche la sua configurazione, facilitata da un
linguaggio di scripting molto flessibile e facile da imparare;
- proprio grazie al linguaggio di scripting sopra menzionato, usato per
redigere i file di configurazione di SNORT contenenti i ruleset che esso
usera' per stabilire quali pacchetti considerare "sospetti", e' possibile
implementare in pochissimo tempo protezioni contro attacchi di recentissimo
annuncio, non ancora coperti da altri IDS, gli upgrade dei quali non sempre
sono disponibili con la stessa rapidita';
- i sistemi di logging/alerting che offre sono facilmente configurabili ed
offrono un ottimo livello funzionale;
- la sua installazione ed il suo impiego non richiedono particolari modifiche
ai sitemi sui quali esso dovra' girare;
- e' un programma cross-platform;
- ultimo, ma non meno importante, e' un prodotto gratuito ed open-source,
rilasciato sotto la licenza GNU GPL.
L'architettura di SNORT
=======================
Snort fa uso delle librerie LibCap per captare il traffico di rete e si
appoggia al Barkeley Packet Filter (BPF) per stabilire quali pacchetti
prendere in considerazione (ad esempio per processare solo i pacchetti TCP);
la sua struttura operativa e' quindi cosi' riassumibile:
_________
/\ | |
/ \ | SNORT |
/____\ |_________|
|| | |
|| | LibCap |
|| |_________|
|| | |
|| | BPF |
|| |_________|
|| | |
|| | kernel |
|| |_________|
|| | |
|| | harware | Ethernet, PPP, SLIP, ecc.
|| |_________|
L'architettura interna di SNORT, invece, e' astraibile come sotto
schematizzato:
________________ __________________ ____________________________
_ | |__ | |__ | |_
_> Packet Decoder __> Detection Engine __> Logging/Alerting Subsystem _>
|________________| |__________________| |____________________________|
Come si puo' facilmente notare dallo schema, SNORT si compone di 3
sottosistemi:
- il Packet Decoder, il cui compito e' quello di captare i pacchetti in
transito sulla nostra rete (o da/per il nostro host);
- il Detection Engine, che tramite i ruleset sopra menzionati si occupa di
stabilire quali pacchetti sono "sospetti", secondo metodi che vedremo piu'
approfonditamente nel seguito dell'articolo;
- il sottosistema di Logging/Alerting, che, in seguito al rilevamento di un
pacchetto "sospetto" da parte del Detection Engine, si occupa di loggare
tale evento o di avvertire l'amministratore secondo le modalita' decise in
fase di avvio del programma (per mezzo di switch da linea di comando) o
tramite particolari impostazioni nei file di configurazione;
Il Detection Engine
===================
Le regole definite nei file di configurazione di SNORT sono conservate in liste
likate bidimensionali di Chain Headers e Chain Options. Questo sistema e' stato
adottato per rendere il processo di detecting piu' performante: se in un
ruleset sono presenti numerose regole che hanno in comune determinate
caratteristiche, queste sono conservate come Chain Headers, mentre i caratteri
che le distinguono sono conservati come Chain Options. Questo permette al
Detection Engine di evitare di valutare numerose espressioni inutilmente. Un
esempio chiarira' le idee: si supponga di disporre di un ruleset che contiene
qualche decina di regole atte a rilevare eventuali attacchi contro il server
ftp della nostra rete; di norma tutte dovrebbero presentare almeno lo stesso
indirizzo ip e la stessa porta. Ora, se un pacchetto preso in analisi dal
Detection Engine non presenta quelle due caratteristiche contemporaneamente, e'
inutile che subisca i test per tutte le decine di regole relative agli attacchi
al server ftp. Quindi SNORT conserverebbe l'indirizzo ip e la porta del server
ftp come Chain Headers e tutti i caratteri per cui le varie regole prese in
considerazione differiscono come Chain Options. Questo schema (preso dalla
documentazione di SNORT scaricata dal sito ufficiale e riadattato solo nella
forma) dovrebbe chiarire le idee in proposito:
________________________ ________________________ ____________...
| Chain Header | | Chain Header | | Chain ...
| | | | |
| -IP di provenienza | | -IP di provenienza | | -IP di prov...
| -IP di destinazione |=>| -IP di provenienza |=>| -IP di prov...
| -Porta di provenienza | | -Porta di provenienza | | -Porta di p...
| -Porta di destinazione | | -Porta di destinazione | | -Porta di p...
|________________________| |________________________| |____________...
| | |
\'/ \'/ \'/
________________________ ________________________
| Chain Option | | Chain Option |
| | | |
| -Contenuto | | Contenuto |
| -Flag TCP | : ::::::::: :
| -Dimensione payload | . ......... .
| -ecc. ecc. |
|________________________|
|
\'/
________________________
| Chain Option |
| |
| -Contenuto |
| -Flag TCP |
| -Dimensione payload |
| -ecc. ecc. |
: :::: :::: :
. .... .... .
Secondo lo schema logico i Chain Header vengono valutati da sinistra verso
destra; quando il pacchetto preso in analisi matcha uno di essi vengono
valutate le eventuali corrispondenze dei Chain Option. Se il pacchetto non
matcha un Chain Header, si passa alla valutazione del successivo.
Il sottosistema di logging/alerting
===================================
SNORT offre al momento 3 opzioni sul logging e 5 sull'alerting, che vengono
definite in fase di avvio del programma (tramite switch da linea di comando) o
tramite apposite istruzioni da inserire nei file di configurazione (vedi
seguito dell'articolo).
L'output del sistema di logging puo' essere:
- in formato human-readable, che permette un'analisi piu' veloce ma e' poco
performante in fase di scrittura dei log su disco;
- in formato tcpdump, che presenta caratteristiche opposte;
Il logging puo' anche essere disabilitato.
Per quanto riguarda il sistema di alerting, esso puo' effettuare notifiche in
vari modi:
- via syslog;
- registrando tutti gli alert in un apposito file. In questo caso si puo'
scegliere tra due tipi di alert logging:
- full alerting, che registra nel suddetto file sia i messaggi di alert che
l'intera intestazione dei pacchetti "sospetti";
- fast alerting, che registra nel suddetto file solo una parte degli
header dei pacchetti "sospetti", metodo che si dimostra, ovviamente, piu'
performante del primo in fase di scrittura dei dati su disco.
- tramite l'invio di messaggi WinPopup a client Samba;
Anche il sistema di alerting, come quello di logging, puo' essere
completamente disabilitato.
I ruleset di SNORT
==================
Come accennato in precedenza, uno dei punti di forza di SNORT e' la
semplicita' del linguaggio di scripting usato per redigere i ruleset che ne
condizionano il funzionamento.
Il formato dei ruleset di snort e' abbastanza semplice:
azione protocollo ip_prov porta_prov -> ip_dest porta_dest (opzioni)
dove, ovviamente:
- "azione" corrisponde all'azione da eseguire;
- "ip_prov" corrisponde all'indirizzo ip di provenienza del pacchetto;
- "porta_prov" corrisponde alla porta di provenienza del pacchetto;
- "ip_dest" corrisponde all'indirizzo ip di destinazione del pacchetto;
- "porta_dest" corrsponde alla porta di destinazione del pacchetto;
- "opzioni" corrisponde al campo dedicato alle opzioni della regola descritte
in seguito.
L'operatore '->' indica la direzione del traffico ('a -> b' = da 'a' a 'b').
Esso puo' anche essere sostituito con l'operatore '<>', che indica la
validita' della regola sia sul traffico in entrata che su quello in uscita
('a <> b' = da 'a' a 'b' e da 'b' ad 'a').
Si noti che le regole di SNORT, dalla versione 1.8 in poi, sono estendibili su
piu' righe tramite l'aggiunta di un backslash ('\') alla fine di ognuna di
esse.
Il campo "azione" puo' assumere i seguenti valori;
- 'alert': fa si' che per i pacchetti che matchano la regola sia generato un
alert secondo le impostazioni scelte e successivamente ne venga effettuato
il log;
- 'log': fa si' che i pacchetti che matchano la regola siano loggati secondo
le impostazioni scelte;
- 'pass': fa si' che i pacchetti che matchano la regola siano semplicemente
ignorati;
- 'activate': fa si' che quando un pacchetto matcha la regola sia generato un
alert e successivamente sia attivata una regola dinamica (vedi seguito dell'
articolo);
- 'dymanic': la regola cosi' marcata rimane "inerte" fino a quando non viene
attivata da un'altra regola attiva, dopodiche' agisce come una regola di
log.
Il campo "protocollo" puo' assumere i seguenti valori, che corrispondono
rispettivamente ai nomi dei protocolli che identificano:
- tcp;
- udp;
- icmp;
- ip;
Altri protocolli dovrebbero essere supportati nelle versioni future di SNORT.
Sia per il campo "ip_prov" che per il campo "ip_dest" il discorso e'
leggermente piu' complicato. I valori di questi due campi devono ovviamente
corrispondere agli indirizzi rispettivamente di provenienza e di desinazione
del pacchetto. Ora, questi due campi possono assumere diversi valori:
- un indirizzo ip specifico;
- un indirizzo che identifica un'intera subnet (classi A,B,C)
- una lista di indirizzi ip;
- "any": corrisponde a "qualsiasi indirizzo ip";
E' il caso di fare una precisazione sulla sintassi che SNORT ci permette di
usare per definire questi due campi: come noto, esistono subnet
di 3 classi: A, B e C; SNORT permette di utilizzare una notazione particolare
per esprimere un indirizzo che identifica un'intera subnet:
network_number_identifier/24 (per subnet di classe C - corrisponde al range
di indirizzi da x.x.x.0 a x.x.x.255)
network_number_identifier/16 (per subnet di classe B - corrisponde al range
di indirizzi da x.x.0.0 a x.x.255.255)
Per indicare un host preciso si usa invece la sintassi:
specific_host_ip_address/32
Per specificare una lista di indirizzi ip (tra i quali possono comparire
quelli di intere subnet, nella forma sopra specificata), invece, si devono
scrivere tra parentesi gli indirizzi che ne fanno parte, separati da virgole
e senza alcuno spazio.
I campi "porta_prov" e "porta_dest" possono assumere i seguenti valori:
- "any": corrisponde a "qualsiasi porta";
- una porta precisa;
- un range di porte;
- una lista di porte;
Per specificare un range di porte si usa l'operatore ":". Esso puo' essere
posto:
- tra due porte (identifica le porte da quella a sinistra sino a quella a
a destra dell'operatore);
- prima di una porta (identifica tutte le porte da 1 a quella specificata)
- dopo una porta (identifica tutte le porte da quella specificata alla
65535)
Sui campi "ip_prov", "ip_dest", "porta_prov" e "porta_dest" e' utilizzabile
l'operatore di negazione '!' che esprime il concetto opposto a quello
specificato dopo di esso. Qualche esempio rendera' meglio l'idea:
Nei campi "porta_prov" e "porta_dest":
- '!21' indica tutte le porte eccetto la 21;
- '!1:1024' indica tutte le porte eccetto quelle dalla 1 alla 21;
Nei campi "ip_prov" e "ip_dest":
- '!192.168.0.1/24' indica tutti gli indirizzi ip al di fuori di quelli
della rete locale;
- '!62.98.45.183/32' indica tutti gli indirizzi ip al di fuori di
62.98.45.183
Il contenuto del campo "opzioni", che va posto tra parentesi, permette di
specificare un elevato numero di opzioni sulla regola, il modo in cui essa
agira' nei confronti di un pacchetto che la matcha, ecc.
Le opzioni che SNORT permette di utilizzare sono molte, ed alcune di esse
sono pensate per un uso avanzato del programma; dal momento che quest'articolo
si propone di introdurre il lettore all'uso di SNORT e di chiarirne il
funzionamento, e non di essere un vero e proprio manuale, vi rimando alla sua
documentazione ufficiale (vedi Riferimenti in fondo all'articolo) per quanto
riguarda le opzioni piu' complesse o inusuali. Di seguito sono trattate solo
le principali (per completezza e' comunque riportato l'elenco di tutte le
opzioni disponibili):
_____________ _________________ __________________
| | | |
| Opzioni che | Opzioni che | Opzioni che |
| specificano | specificano | modificano il |
| azioni da | caratteristiche | comportamento |
| compiere | dei pacchetti | di altre opzioni |
______________________|_____________|_________________|__________________|
| | | | |
| Opzioni descritte | msg | dsize | offset |
| in dettaglio: | logto | same_ip | nocase |
| | resp | ack | depth |
| | | icmp_id | |
| | | content | |
| | | content-list | |
| | | ip_proto | |
|______________________|_____________|_________________|__________________|
| | | | |
| Opzioni non trattate | reference | ttl | Altre opzioni |
| in questa sede | tag | tos |__________________|
| | react | id | |
| | | ipoption | sid |
| | | fragbits | rev |
| | | flags | classtype |
| | | icode | priority |
| | | icmp_seq | |
| | | session | |
| | | rpc | |
| | | stateless | |
| | | regex | |
| | | seq | |
| | | itype | |
| | | uricontent | |
|______________________|_____________|_________________|__________________|
Nota: dopo ogni opzione specificata e' necessario aggiungere il carattere ';'
L'opzione "msg" serve a specificare il messaggio da inviare al sistema di
logging o a quello di alerting quando un pacchetto match la regola. La sua
sintassi e' la seguente:
msg: "MESSAGGIO";
Le virgolette sono necessarie per evitare che il parser dei ruleset possa
andare in confusione.
L'opzione "logto" serve ad indicare a SNORT dove deve loggare i pacchetti che
matchano quella specifica regola.
logto: "FILE";
L'opzione "resp" serve a specificare che tipo di reazione attiva SNORT deve
mettere in atto quando un pacchetto mathca la regola. Sinatssi:
resp: "PARAMETRO";
Si noti che in caso di parametri multipli questi vanno separati con una
virgola. I parametri di quest'opzione sono:
- "rst_snd": invia un pacchetto TCP con il flag RST impostato al socket di
origine del pacchetto;
- "rst_rcv": invia un pacchetto TCP con il flag RST impostato al socket di
destinazione del pacchetto;
- "rst_all": invia un pacchetto TCP con il flag RST impostato sia al socket
di origine che a quello di destinazione del pacchetto;
- "icmp_net: invia un pacchetto ICMP del tipo NET UNREACHABLE al mittente;
- "icmp_host": invia un pacchetto ICMP del tipo HOST UNREACHABLE al mettente;
- "icmp_port": invia un pacchetto ICMP del tipo PORT UNREACHABLE al mittente;
- "icmp_all": invia tutti i 3 tipi di pacchetto ICMP al mittente.
E' possibile combinare i vari parametri per ottenere un controllo piu'
flessibile sul tipo di azione separandoli con una virgola.
L'opzione "dsize" serve per controllare le dimensioni del payload dei
pacchetti; la sua sintassi e' la seguente:
dsize: NUMERO;
Si possono anche specificare range di dimensioni anteponendo a 'NUMERO' i
segni '<' e '>' ('minore' e 'maggiore').
L'opzione "content" e' una delle piu' usate. Essa permette di specificare una
stringa da cercare nel payload dei pacchetti valutati. Piu' opzioni "content"
possono essere specificate nella stessa regola in modo da fornire una maggior
precisione nella ricerca di pacchetti sospetti. La sintassi di quest'opzione
e' la seguente:
content: "STRINGA";
Si noti che i caratteri '"', ':' e '|' NON possono essere contenuti nella
stringa da ricercare in quanto hanno un significato particolare. Nello
specifico il carattere '|' e' usato per delimitare una sequenza binaria,
espressa tramite un numero esadecimale, all' interno della stringa. E'
infatti possibile combinare all'interno della suddetta stringa sia testo che
dati in forma binaria, utilizzando la semplice sintassi |HEX_NUMBER| per
delimitare i dati in forma binaria. Anche per l'opzione "content" e'
possibile utilizzare l'operatore di negazione '!' (che va eventualmente
anteposto alla stringa da cercare) per indicare tutti i pacchetti che non
presentano al loro interno la stringa specificata. Si noti che il sistema di
ricerca della stringa e' CASE-SENSITIVE (vedi seguito dell'articolo per
maggiori informazioni).
In combinazione con l'opzione "content" ne posso essere usate altre 3:
- "offset";
- "depth";
- "nacase";
L'opzione "offset" indica da quale byte del payload deve partire la ricerca
della stringa specificata dall'opzione content; la sua sintassi e' la
seguente:
offset: NUMERO;
L'opzione "depth" agisce al contrario dell'opzione offset: indica oltre quale
byte del payload non e' piu' necessario continuare la ricerca della stringa:
depth: NUMERO;
L'opzione "nocase", come intuibile dal nome, fa si' che la ricerca della
stringa specificata nell'opzione "content" non avvenga in maniera
CASE-SENSITIVE per la parte testuale di essa (la parte binaria espressa in
esadecimale non e' interessata da quest' aspetto).
L'opzione "content-list", invece, permette una ricerca di stringhe multiple.
Esse vanno specificate all'interno di un file, una per riga e tra virgolette;
la sintassi dell'opzione e':
content-list: "FILE";
dove, ovviamente, FILE e' il file sopra menzionato. Anteponendo l'operatore di
negazione a "FILE" si ottiene la ricerca di tutti i messaggi che NON
contengono le stringhe specificate in FILE.
L'opzione "ack" fa riferimento all campo ACK dei pacchetti TCP. Come messo in
evidenza anche dalla documentazione ufficiale di SNORT, quest'opzione e'
particolarmente utile per rilevare attivita' di network-scanning effettuati
tramite TCP-PING: uno dei metodi utilizzati per sapere se un determinato host
in un rete e' attivo e' quello di inviare a tale host un pacchetto con
ACKNOWLEDGEMENT NUMBER settato a '0', in modo tale che, se l'host destintario
e' attivo, rispondera' con un pacchetto TCP con il flag RST attivo. Sintassi:
ack: NUMERO;
L'opzione "icmp_id" fa riferimento al campo ID dei pacchetti ICMP. La sua
sintassi e' la seguente:
icmp_id: NUMERO;
dove NUMERO puo' assumere diversi valori, tra cui i piu' importanti sono:
- "8": richiesta di reinvio dei dati specificati nel datagramma ICMP (Echo);
- "0": rispedisce al mittente i dati da esso inviati con richiesta di
restituzione (Echo Answer);
- "3": destinazione non raggiungibile (il pacchetto non e' potuto arrivare a
destinazione);
- "4": richiesta di rallentamento nella spedizione di pacchetti;
- "5": richiesta di reinstradamento dei pacchetti;
- "11": e' scaduto il tempo massimo di vita (TTL) di un pacchetto (Timeout);
L'opzione "ip_proto" serve per effettuare una ricerca mirata all'interno del
campo PROTOCOL nell' header dei pacchetti IP. La sintassi e':
ip_proto: NOME;
oppure:
ip_proto: NUMERO;
Anche in questo caso sia a NUMERO che a NOME e' anteponibile l'operatore di
negazione. I valori di NOME (con i corrispondenti valori di NUMERO) sono
presenti nel file /etc/protocols (sotto OS unix-like). Una breve lista* dei
piu' importanti e' riportata qui sotto:
NOME NUMERO DESCRIZIONE
ip 0 # internet protocol
icmp 1 # internet control message protocol
igmp 2 # internet group management protocol
ggp 3 # gateway-gateway protocol
ipencap 4 # IP encapsulated in IP (officially ``IP'')
tcp 6 # transmission control protocol
egp 8 # exterior gateway protocol
igp 9 # any private interior gateway (Cisco: for IGRP)
nvp 11 # Network Voice Protocol
udp 17 # user datagram protocol
mux 18 # Multiplexing protocol
hmp 20 # host monitoring protocol
ipv6 41 # IPv6
ipv6-route 43 # Routing Header for IPv6
ipv6-frag 44 # Fragment Header for IPv6
gre 47 # Generic Routing Encapsulation
ipv6-crypt 50 # Encryption Header for IPv6
ipv6-auth 51 # Authentication Header for IPv6
swipe 53 # IP with Encryption
ipv6-icmp 58 # ICMP for IPv6
ipv6-nonxt 59 # No Next Header for IPv6
ipv6-opts 60 # Destination Options for IPv6
wb-mon 78 # WIDEBAND Monitoring
iso-ip 80 # ISO Internet Protocol
eigrp 88 # Enhanced Interior Routing Protocol (Cisco)
mtp 92 # Multicast Transport Protocol
ipip 94 # Yet Another IP encapsulation
micp 95 # Mobile Internetworking Control Pro.
etherip 97 # Ethernet-within-IP Encapsulation
encap 98 # Yet Another IP encapsulation
qnx 106 # QNX
ipcomp 108 # IP Payload Compression Protocol
ipx-in-ip 111 # IPX in IP
smp 121 # Simple Message Protocol
sctp 132 # Stream Control Transmission Protocol
fc 133 # Fibre Channel
L'opzione "sameip" ha invece lo scopo di verificare se l'indirizzo di
destinazione e quello di provenienza coincidono. La sua sintassi e' molto
semplice:
sameip;
Ulteriori istruzioni nei file di configurazioen di SNORT
========================================================
Nei file di configurazione di SNORT oltre alle regole sono specificabili
ulteriori parametri; vediamo i piu' importanti.
Come vedremo in seguito, alcune opzioni di SNORT vanno impostate tramite
switch da linea di comando; tra queste c'e' il file di configurazione
contenente le regole che SNORT dovra' utilizzare. Per praticita' e' possibile
usare, all'interno di questo file, la direttiva "include", sicuramente
familiare a chi programma. Essa serve a comunicare a SNORT in quali altri file
trovera' le regole che dovra' utilizzare. Questa direttiva si dimostra
particolarmente utile per splittare ruleset di grandi dimensioni. La sintassi
e':
include: "FILE"
Sempre all'interno dei file di configurazione di SNORT e' possibile utilizzare
delle variabili. La sintassi per dichiararle e' la seguente:
var: NOME VALORE
Per l'uso avanzato delle variabili vi rimando alla documentazione ufficiale di
SNORT.
Esempi di rules
===============
Quelli che seguono sono alcuni esempi di rules (tratti dai ruleset scaricati
da snort.org) e commentati.
Quella che segue e' una regola atta a segnalare eventuali tentativi di login
non andati a buon fine:
alert tcp $EXTERNAL_NET any <- $HOME_NET 23 (msg:"TELNET login incorrect"; \
content:"Login incorrect"; flags: A+; reference:arachnids,127; \
classtype:bad-unknown; sid:718; rev:2;)
Questa rule effettua un ALERT per ogni pacchetto tcp che provenga ('<-') dalla
nostra rete ('$HOME_NET') dalla porta 23, nel quale payload sia presente la
stringa "Login incorrect", e che abbia il flag ACK settato ('flags: A+'). Si
noti che la regola e' valida solo per i pacchetti provenienti dalla nostra
rete e diretti verso l'esterno: la stringa cercata sara' infatti inviata dal
nostro server telnet al client che fallisce il login.
La seguente regola, invece, genera un alert in caso di un XMAS scan:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN NMAP XMAS"; /
flags:FPU; reference:arachnids,30; classtype:attempted-recon; sid:1228; /
rev:1;)
Vengono considerati sospetti i pacchetti tcp provenienti dall'esterno della
nostra rete, indipendentemente dalla porta di provenienza e destinazione, che
abbiano i flag tcp FIN, PSH e URG settati (l'XMas Tree Scan prevede che tali
flag siano attivi, in maniera tale che se il pacchetto spedito e' diretto ad
una porta aperta l'host destinatario non rispondera' al pacchetto, se e'
diretto ad una porta chiusa l'host destinatario rispondera' con un pacchetto
tcp con il flag RST attivo).
Switch da linea di comando
==========================
Al momento dell'avvio di SNORT e' possibile (e talvolta necessario)
specificare alcune opzioni da linea di comando. Innanzitutto, la sintassi per
il lancio di SNORT e' la seguente:
snort [-switch1 [parametro1 paramtro2 ...]] [-switch2 [parametro1 ...]] ...
Gli switch da linea di comando sono i seguenti:
- "-A [fast|full|console|none]": definisce la modalita' di alerting;
- "-b": questo switch non accetta parametri ed indica a SNORT di effettuare il
logging in formato TCPDUMP (che risulta essere piu' veloce in fase di
scritturarispetto dei dati su disco rispetto al formato proposto da SNORT);
- "-c [path/file]": a questo switch (strettamente necessario al funzionamento
del programma) va fatto seguire il percordo del file primario dei ruleset di
SNORT;
- "-C": indica a SNORT di omettere dall'output la notazione esadecimale del
payload dei pacchetti loggati;
- "-D": lancia SNORT in background (daemon mode);
- "-h [HOME_NTW_IP]": specifica l'indirizzo della rete locale;
- "-i [interface]": l'interfaccia su cui SNORT dovra' mettersi in ascolto;
- "-I": indica a SNORT di segnalare negli alert l'interfaccia su cui sono
transitati i pacchetti sospetti;
- "-l [path/]": indica la directory in cui SNORT piazzera' i log;
- "-n [numero]: termina l'esecuzione di SNORT dopo la processazione di
'numero' pacchetti;
- "-N": inibisce l'attivita' di logging (quella di alerting continua a
funzionare);
- "-p": disabilita lo sniffing in promiscuous mode (SNORT processera' solo i
pacchetti effettivamente diretti all'host su cui e' in esecuzione);
- "-s": invia i messaggi di alert al demone syslogd;
- "-V" e "?" mostrano rispettivamente il numero di versione di SNORT e la
pagina di help.
Per la lista completa e la descrizione di tutti gli switch fare riferimento
alla pagina di help di SNORT.
Un esempio di implementazione
=============================
Quella che segue e' la descrizione di come implementare SNORT su una singola
macchina connessa ad internet. Ovviamente la situazione proposta e' oltremodo
semplice, ma d'altronde il presente articolo intende semplicemente essere un'
introduzione al programma e non una guida vera e prorpia. Inoltre, per capire
il funzionamento di SNORT e' piu' che sufficiente e puo' permettere alla
maggior parte degli utenti di provare questo software anche non disponendo di
una rete locale.
Procediamo come sotto indicato:
- procuriamoci i pacchetti necessari www.snort.org:
- "snort-x.y.z.i386.rpm" (per semplicita' si fara' riferimento al pacchetto
RPM e non ai sorgenti, la cui compilazione non e' comunque cosa
difficoltosa);
- "libnet-x.y.z-snort.i386.rpm" (il pacchetto libnet, da scaricare nel caso
non sia gia' installato - e in tal caso da installare prima di SNORT);
- procuriamoci (sempre su snort.org) i file di ruleset "preconfezionati";
- supponiamo di aver piazzato i file appena prelevati nella directory
temporanea /tmp/snort/;
- installiamo le libnet:
[root@hell snort]# rpm -i libnet-x.y.z-snort.i386.rpm
- installiamo il SNORT:
[root@hell snort]# rpm -i snort-x.y.z.i386.rpm
- scompattiamo il tarball dei ruleset:
[root@hell snort]# tar xzvf snortrules.tar.gz
- ora copiamo i file di ruleset (dopo aver scompattato l'archivio in cui si
trovano con "tar xzvf snortrules.tar.gz") nella directory che dovra'
continuare a contenerli anche in futuro; per l'esempio useremo quella che
ho usato sul mio sistema, ovvero /etc/snort/rules.conf;
[root@hell snort]# cp rules/* /etc/snort/rules/
- ora, dal momento che nel nostro caso SNORT deve mettersi in ascolto sull'
interfaccia ppp0, che non risulta attiva fino al momento della connessione,
e, dal momento che avere SNORT in esecuzione quando non si e' connessi ad
internet non risulta affatto utile - nel caso in esame si intende - e, anzi,
si traduce uno spreco di risorse, inseriamo la seguente riga nel file
/etc/ppp/ip-up:
snort -A fast -c /etc/snort/rules/snort.conf -D -i ppp0
cosi' facendo SNORT verra' automaticamente avviato ad ogni connessione.
Prendiamo ora in esame gli switch:
- "-A fast": indica a SNORT di effettuare l'alerting in modalita' 'fast';
- "-c /etc/snort/rules/snort.conf": indica al programma dove si trova il file
di configurazione principale;
- "-D": serve a lanciare l'IDS in daemon-mode;
- "-i ppp0": indica a SNORT su quale interfaccia sniffare i pacchetti.
Non avendo specificato diversamente, i log di SNORT si troveranno nella
directory /var/log/snort/.
Ora avete il vostro bel sistema monitorato da un eccellente IDS ;)
Qui si chiude quest'articolo introduttivo a SNORT, nella speranza di aver
fatto cosa gradita :)
--------------------------------------------------------------------------------
Riferimenti, disclaimer e informazioni varie
La documentazione integrale di SNORT, che vi consiglio di leggere se volete
approfondire le vostre conoscenze sull'argomento, e' reperibile, come anche il
programma stesso, i ruleset "preconfezionati", ecc. all'indirizzo del sito
ufficiale del progetto:
http://www.snort.org
DISCLAIMER: L'AUTORE DI QUESTO DOCUMENTO NON SI ASSUME ALCUNA RESPONSABILITA'
PER L'USO CHE CHICCHESSIA FARA' DELLE INFORMAZIONI IN ESSO CONTENUTE, NE' NE
ASSICURA LA CORRETTEZZA E/O LA VERIDICITA'. CHIUNQUE E' LIBERO DI COPIARE,
PUBBLICARE E/O DISTRIBUIRE QUESTO DOCUMENTO, PURCHE' RISPETTI LE SEGUENTI
CONDIZIONI:
- IL PREZZO DI VENDITA DEL SUPPORTO SUL QUALE IL DOCUMENTO VERRA' DISTRIBUITO
NON DOVRA' SUPERARE IL COSTO EFFETTIVO DELLA SUA PRODUZIONE;
- NEL CASO DI PUBBLICAZIONE IN RETE, NON DOVRA' ESSERE RICHIESTO ALCUN
CORRISPETTIVO PER LA CONSULTAZIONE DEL DOCUMENTO STESSO;
- IL DOCUMENTO DOVRA' ESSERE MESSO A DISPOSIZIONE NELLA SUA FORMA INTEGRALE E
PRIVO DI MODIFICHE;
NEI CASI SUDDETTI DI DISTRIBUZIONE AUTORIZZATA PER CORTESIA INVIARE
SEGNALAZIONE ALL'INDIRIZZO E-MAIL: scrawlATquipo.it
(Causa motivi legati al mailspamming, e' necessario sostituire con una
chiocciola ('@') la particella "AT" dell' indirizzo sopra riportato).
Autore: hylux (#compuita, #spaghettilinux, #redhat, #it - irc server:
irc.azzurranet.org).
--------------------------------------------------------------------------------
eof