Le regole Snort

Questa lezione ci introdurrà nel mondo delle regole Snort. Esistono tre modi per la creazione delle regole:

1. creazione manuale;
2. download delle regole create dalla community, disponibili qui (sotto la voce community);
3. download delle regole ufficiali, disponibili qui (sotto la voce registered).
   Questa opzione richiede la creazione di un account gratuito, che consentirà di avere il supporto degli sviluppatori per ottenere regole costantemente aggiornate.
   Una volta terminata la creazione dell’account gratuito, ci verrà rilasciato il cosiddetto oinkcode.
   Per il momento, conserviamolo e manteniamolo segreto.

In questa lezione ci focalizzeremo sul formato delle regole e come esse possano essere scritte manualmente.
In una delle prossime lezioni vedremo poi come utilizzare l’oinkcode per il download automatico delle regole da parte del plugin PulledPork.

Formato di una regola

Le regole Snort sono formate da una intestazione più eventuali opzioni. L’intestazione è costituita dalle seguenti informazioni:

1. Action: indica quale operazione deve eseguire Snort quando trova un pacchetto che soddisfa la regola:
   • alert: scrive un output testuale e logga il pacchetto;
   • drop: blocca e logga il pacchetto;
   • reject: blocca e logga il pacchetto, e successivamente
     invia un messaggio TCP di “connection reset” se il protocollo è TCP,
     oppure un messaggio “ICMP port unreachable” se il protocollo è UDP o ICMP;
2. Protocol: il tipo di protocollo da monitorare (TCP, UDP, ICMP o IP);
3. Source IP: una maschera di rete per gli indirizzi di provenienza da monitorare;
4. Ports: le porte di provenienza da monitorare;
5. Operatore di direzione: indica l’orientazione del traffico da monitorare (in uscita o in ingresso);
6. Destination IP: una maschera di rete per gli indirizzi di destinazione da monitorare;
7. Ports: le porte di destinazione da monitorare.

Le opzioni disponibili sono le seguenti:

• msg: una stringa di testo che verrà prodotta in output quando verrà rilevato un pacchetto che soddisfa la regola;
• SID/REV: Snort ID della regola e revisione, utile per la gestione delle regole da parte dei plugin;
• classtype: consente di categorizzare una regola facente parte di una classe di attacchi specifici. Utile per organizzare gli eventi prodotti da snort. Riferitevi al file “classification.config” per utilizzare il nome corretto della classe da assegnare alle vostre regole;
• priority: il grado di severità della regola;
• content: una stringa indicante un contenuto specifico da cercare all’interno dei payload dei pacchetti; l’utilizzo di content può essere ripetuto più volte all’interno della stessa regola.

Scrivere la prima regola e verificarne il funzionamento

Nella lezione precedente abbiamo disabilitato il caricamento delle regole da parte di Snort,
con l’obiettivo di fare eseguire questa operazione al plugin PulledPork. Ciò non toglie che in
futuro possiamo avere la necessità di scrivere o modificare in qualche modo
le regole fornite dalla community o dagli sviluppatori ufficiali. Per questo motivo,
è importante imparare a capire come modificare le regole per adeguarle alle nostre esigenze.
Passiamo a scrivere una semplice regola di test e verifichiamone
il corretto funzionamento.

Supponiamo di volere scrivere una regola che consenta di
generare un alert ogni volta che Snort individua un pacchetto ICMP in ingresso.
Per fare ciò, eseguiamo:

sudo nano /etc/snort/rules/local.rules

Dopodiché, incolliamo in coda al file la seguente linea (senza andare a capo):

alert icmp any any -> $HOME_NET any (msg:"Pacchetto ICMP rilevato"; GID:1;
sid:10000001; rev:001; classtype:icmp-event;)

Questa regola indica di eseguire un’azione di tipo alert
per tutti i pacchetti del protocollo icmp che hanno un qualunque indirizzo e
porta sorgente (any), con direzione del traffico in entrata (->),
con destinazione un IP qualunque appartenente alla HOME_NET per qualunque porta destinazione.
Le opzioni della regola sono separate dal carattere ;, mentre il valore dell’opzione è specificato tramite il delimitatore :.
Per compatibilità con il plugin, Barnyard2 (oggetto della prossima lezione), modifichiamo anche il file sid-msg.map:

sudo nano /etc/snort/sid-msg.map

In questo caso, incolliamo la seguente linea (senza andare a capo):

gid,1 || sid,10000001 || ref,001 || classification,icmp-event || priority,0 ||
msg, Pacchetto ICMP rilevato || url,tools.ietf.org/html/rfc792

Verifichiamo il funzionamento corretto della regola, eseguendo Snort (sulla corretta interfaccia di rete):

sudo snort -T -c /etc/snort/snort.conf -i eth0

Scorrendo il log fornito dal comando, se tutto è andato bene, dovrebbe apparire qualcosa del genere:

Verifichiamo che Snort rilevi correttamente la presenza dei pacchetti ICMP in ingresso,
dunque eseguiamolo con il seguente comando:

sudo /usr/local/bin/snort -A console -q -u snort
-g snort -c /etc/snort/snort.conf -i eth0

Inizialmente non vedremo alcun output, anche se Snort sta processando
i pacchetti in input. Non rimane quindi che provare ad inviare un messaggio ICMP
verso la macchina che sta eseguendo Snort. Per fare ciò, dovremo necessariamente
utilizzare una macchina con un diverso indirizzo IP. Possiamo quindi ricorrere ad un altro PC, oppure, se stiamo utilizzando VirtualBox, passando il comando alla macchina “reale” (host).

Eseguiamo dunque il comando ping (che sfrutta proprio il protocollo ICMP) dalla shell:

ping IP_ADDRESS

dove IP_ADDRESs va sostituito con l’indirizzo IP del server Snort. Terminiamo Snort ed apriamo
/var/log/snort, dove troveremo un file snort.log.nnnnnnnnn. Visualizziamone il contenuto:

cat snort.log.nnnnnnnnnnn

Se tutto ha funzionato a dovere, il file dovrebbe contenere una o più righe con il seguente contenuto:

12/24-15:29:31.982144 [**] [1:10000001:1] Pacchetto ICMP rilevato [**]
[Classification: Generic ICMP event] [Priority: 3] {ICMP}
192.168.1.100 -> 192.168.1.101

Consigli per la scrittura di regole efficienti

Utilizzare l’opzione content all’interno delle regole è uno dei modi migliori
per ridurre il numero di pacchetti e di regole da valutare.
Questo perché le regole senza un contenuto specifico sono sempre valutate interamente,
e normalmente il traffico “buono” è molto di più del traffico “cattivo”. Ciò significa che eseguire le regole senza cercare un contenuto specifico produrrà
un drastico calo delle prestazioni. Un’altra importante informazione da tenere a mente
è che il contenuto di un pacchetto viene verificato ricorsivamente.
Questo perché la stringa del contenuto che si vuole matchare deve essere cercata all’interno
dell’intero pacchetto. Supponiamo ad esempio di avere utilizzato la seguente opzione per una regola:

content:"|18|"; dsize:1;

Questo indica di cercare un pacchetto contenente il carattere “0x18”
avente lunghezza unitaria . Dunque, un pacchetto lungo 1000 bytes
che non contiene il carattere specifico verrà controllato 1000 volte a causa della ricorsione.
Riordinando le due opzioni avremo una regola che cerca solo all’interno di pacchetti di lunghezza “1”
il carattere “0x18”:

dsize:1; content:"|18|";

Un pacchetto lungo 1000 byte fallirà immediatamente
la regola senza utilizzo di ricorsione, e questo migliorerà notevolmente l’efficienza delle ricerche.
Per i motivi di efficienza suddetti, si consiglia di posizionare le seguenti opzioni sempre all’inizio
della sezione opzionale delle regole:

• dsize : specifica la lunghezza del payload dei pacchetti;
• id: utilizzata per verificare il campo ID di un pacchetto IP;
• seq: specifica il numero di sequenza di un pacchetto TCP;
• ttl: specifica il valore time-to-live di un pacchetto IP;
• ack: utilizzata per verificare un numero di ack specifico per una connessione TCP.