No more maintained.
Now just a test in a lab.
Snort
Installazione, configurazione e utilizzo di Snort
Installazione SNORT
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Snort è uno dei numerosi strumenti di rilevazione del traffico di rete per individuare e segnalare intrusioni.
Snort è stato progettato per funzionare in 3 modi differenti:
-Sniffer intercetta i pacchetti che viaggiano nella rete e li visualizza in console.
-Packet Logger salva su disco locale i pacchetti
-Network Intrusion Detection analizza il traffico di rete attraverso delle regole customizzabili ed esegue operazioni configurabili in caso di corrispondenza.
INSTALLAZIONE DI SNORT
L'installazione base di SNORT prevede come unico requisito di sistema la presenza delle libpcap (librerie per la cattura di pacchetti).
[root@GIOVE snort-1.9.0]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
........
[root@GIOVE snort-1.9.0]# make
cd . && /root/snort/snort-1.9.0/missing autoheader
.....
[root@GIOVE snort-1.9.0]# make install
Making install in src
make[1]: Entering directory `/root/snort/snort-1.9.0/src'
.......
Snort è ora installato sul sistema in /usr/local/bin/snort.
[root@GIOVE snort]# snort -?
Initializing Output Plugins!
-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
USAGE: snort [-options] <filter options>
Utilizzo di SNORT come SNIFFER
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
SNORT può essere utilizzato come un normale packet sniffer per visualizzare il traffico di rete.
snort [-opzioni] < filtri >
Come ogni sniffer è possibile creare filtri in modo da monitorare solo certi tipi di pacchetti o interfacce.
Con snort -v (verbose mode) si visualizzano gli header dei pacchetti, con snort -dev
si visualizzano sia i dati che gli header dei pacchetti.
[root@GIOVE root]# snort -v
Initializing Output Plugins!
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==--
Decoding Ethernet on interface eth0
--== Initialization Complete ==--
-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
03/04-11:47:04.995500 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26313 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F186E3 Ack: 0x13A910FF Win: 0x25B0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/04-11:47:04.995841 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26314 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F18733 Ack: 0x13A910FF Win: 0x25B0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Utilizzo di SNORT come PACKET LOGGER
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Attraverso le opzioni del comando snort è possibile salvare su disco i pacchetti catturati da snort per poterli analizzare in un tempo successivo.
snort -dv -l /var/log/snort
dove /var/log/snort è una directory. Al suo interno verranno create diverse sottodirectory, con nomi corrispondenti agli indirizzi IP trovati nei pacchetti analizzati.
Nel caso su operi su reti ad alta velocità con l'opzione -b si imposta un logging più veloce (formato di tcpdump):
snort -dv -l /var/log/snort -b
con l'opzione -h (home network) si definisce la network di cui loggare i pacchetti:
snort -dev -l /var/log/snort -h 192.168.0.0/24
Utilizzo di SNORT come NIDS
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Un NIDS (Network Intrusion Detection Systems) è un sistema di monitoring di traffico di rete, volto ad individuare pattern di pacchetti potenzialmente ostili in risposta ai quali possono essere eseguite determinate azioni (notifica via mail, chiusura di una connessione, logging su un database ecc.).
Snort presenta vari modi per essere configurato come NIDS.
Innanzitutto prevede 3 tipi principali di regole:
-ALERT invia messaggi ad ogni infrazione;
-PASS non considera il pacchetto;
-LOG visualizza/scrive le informazioni del pacchetto;
Lo standard di Snort è stampare a video i messaggi di alert ma è possibile utilizzare altre modalita':
-full, visualizza l'intero messaggio
-fast, logging rapido dei messagggi
-unsock, invio dei messaggi ad un socket unix
-syslog, scrittura dei messaggi nel syslog di sistema
-smb messages, invio di messaggi di alert ad altri host tramite samba
-none, non invia nessun messaggio
Per le opzioni full,fast,unsock e none è necessario anteporre il comando -A mentre con -s i messaggi di alert vengono inviati al syslog. Per abilitare a Snort l'invio di messaggi tramite il samba client, una sorta di Winpopup, è necessario aggiungere l'opzione "--enable-smbalerts" in fase di installazione di Snort.
snort -c snort.conf -l /var/log/snort -h 192.168.0.0/24
salva i log nella dir /var/log/snort prendendo in considerazione la rete 192.168.0.0/24
snort -c snort.conf -b -h 192.168.0.0/24 -M HOSTS
salva i dati in modalità tcpdump (meno informazioni ma più veloce), invia gli alert alle workstation windows
snort -c /etc/snort.conf -l /var/log/snort -h 10.1.0.0/24 -aIe -D
mostra i pacchetti ARP, aggiunge il nome interfaccia al log, mostra il layer secondario del pacchetto e con -D agisce come demone senza occupare una shell
Snort + ELK: utilizzo di Kibana come console
Tipo Infobox: DESCRIPTION - Skill:
Sebbene snort sia un'ottima soluzione ids trovo sia sempre stato carente dal punto di vista dell'interfaccia per visualizzare gli alert.
Per alcuni anni ho utilizzato snorby come console, un'interfaccia web basata su Ruby on Rails, ma che non sembra piu' molto mantenuta a livello di sviluppo.
Una possibile alternativa (anche se meno completa, secondo il sottoscritto) potrebbe essere l'integrazione di snort con uno stack ELK (ElasticSearch, Logstash e Kibana).
Escludendo l'utilizzo di tool di terze parti per parsare i log unified di snort e generare l'output in formato json e' possibile configurare logstash per leggere i file di log generati da barnyard.
Volendo registrare anche il payload dei pacchetti relativi agli eventi rilevati da snort, e' necessario utilizzare il plugin log_syslog_full di barynard specificando complete come operation mode:
output log_syslog_full: sensor_name snort-home, server 192.168.16.16, log_priority LOG_WARNING, log_facility LOG_LOCAL1, protocol udp, port 514, operation_mode complete
Di seguito, un esempio di evento in questo formato:
Aug 12 17:47:49 192.168.16.15 | [SNORHOST[LOG]: [snort-home] ] || 2016-08-12 17:47:48.896+002 2 [1:2022466:3] ET CURRENT_EVENTS Possible Keitaro TDS Redirect || bad-unknown || 6 46.28.68.3 192.168.16.101 4 20 0 409 58575 2 0 14248 0 || 80 58828 4294113776 1054781659 5 0 24 7504 18093 0 || 423 00000C07AC0100090F090013080045000199E4CF4000400637A82E1C44030A2
7A0A10050E5CCFFF2F9F03EDEB0DB50181D5046AD0000485454502F312E3120
333032204D6F7665642054656D706F726172696C790D0A5365727665723A206
E67696E782F312E31302E300D0A446174653A204672692C2031322041756720
323031362031353A34363A343020474D540D0A436F6E74656E742D547970653
A20746578742F68746D6C3B20636861727365743D7574662D380D0A436F6E74
656E742D4C656E6774683A20300D0A436F6E6E656374696F6E3A206B6565702
D616C6976650D0A582D506F77657265642D42793A205048502F352E342E3435
0D0A457870697265733A205468752C203231204A756C20313937372030373A3
3303A303020474D540D0A43616368652D436F6E74726F6C3A206D61782D6167
653D300D0A507261676D613A206E6F2D63616368650D0A4C6173742D4D6F646
9666965643A204672692C2031322041756720323031362031353A34363A3430
20474D540D0A4C4F434154494F4E3A20687474703A2F2F6164756C7477656263616D2E67612F7765620D0A0D0A ||
Per effettuare il parsing dei log scritti da barnyard modificare come segue il file di configurazione di logstash:
#Input, log file written by barnyard
Input
{
file
{
path => "/var/log/messages"
type=> "snort"
}
}
Filter
{
if [type] == "snort"
{
#grok filters to identify snort events
grok
{
break_on_match => true
match => {
"message" => [": \[%{GREEDYDATA:sensor}\] \] \|\| %{TIMESTAMP_ISO8601:tstamp} %{INT:PRIORITY} \[%{INT:GENID}:%{INT:SIGID}:%{INT:VER}\] %{GREEDYDATA:Signature} \|\| %{GREEDYDATA:LOGSOURCE } \|\| %{INT:PROTO} %{IPV4:SRCIP} %{IPV4:DSTIP} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} \|\| %{INT:SRCPORT} %{INT:DSTPORT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} \|\| %{I NT} %{GREEDYDATA:CAPTURE} \|\|",
": \[%{GREEDYDATA:sensor}\] \] \|\| %{TIMESTAMP_ISO8601:tstamp} %{INT:PRIORITY} \[%{INT:GENID}:%{INT:SIGID}:%{INT:VER}\] %{GREEDYDATA:Signature} \|\| %{GREEDYDATA:LOGSOURCE} \|\| %{INT:PROTO} %{IPV4:SRCIP} %{IPV4:DSTIP} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} %{INT} \|\| %{INT} %{GREEDYDATA:CAPTURE} \|\|"]
}
}
#geoip source ip address for kibana maps
geoip
{
database => "/usr/local/etc/logstash/GeoLiteCity.dat"
source => "SRCIP"
target => "geoip"
#add_tag => ["GeoIP"]
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
#geoip destination ip address for kibana maps
geoip
{
database => "/usr/local/etc/logstash/GeoLiteCity.dat"
source => "DSTIP"
target => "geoip"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate
{
convert => [ "[geoip][coordinates]", "float" ]
convert => [ "SRCPORT", "integer" ]
convert => [ "DSTPORT", "integer" ]
}
#convert capture field from hex to ascii string
ruby
{
code => "event['CAPTURE'] = [event['CAPTURE']].pack('H*')"
}
}
Date
{
match => [ "tstamp", "ISO8601" ]
}
}
#send events to elasticsearch
Output
{
#only logs that matched snort’s grok filter
if "_grokparsefailure" not in [tags]
{
elasticsearch { }
}
}
Logstash cosi' configurato non riconosce ancora tutti i campi, ma quelli essenziali dovrebbero essere presenti.
Come si puo' notare dal file logstash.conf l'istanza di elasticsearch gira su localhost, ed e' stato mantenuto il nome di default per gli indici (logstash-%{+YYYY.MM.dd}"). Anche Kibana e' configurato in listening solamente su localhost, tramite la seguente direttiva nel file kybana.yml:
server.host: "127.0.0.1"
Essendo Kibana accessibile solo su localhost, e' necessario configurare un reverse proxy che forwardi le connessioni verso la porta 5601.
Nel caso si utilizzi apache, di seguito un estratto del file httpd.conf contenente la parte relativa alla configurazione come reverse proxy:
#Load mod_proxy modules
LoadModule proxy_module libexec/apache24/mod_proxy.so
LoadModule proxy_http_module libexec/apache24/mod_proxy_http.so
#Don't pass the host header of the incoming request
ProxyPreserveHost off
#Prevent apache to work as forward proxy server!
ProxyRequests Off
#mapping for kibana instance
ProxyPass / http://127.0.0.1:5601/
#adjust url in http response headers sent from kibana
ProxyPassReverse / http://127.0.0.1:5601/
Una volta avviati snort, barynard, elasticsearch, logstash e kibana sara' possibile visualizzare gli eventi via browser puntando all'ip e porta sulla quale e' stato configurato in listening apache.
Questo e' un esempio degli eventi visualizzabili: https://drive.google.com/file/d/0B_K5uRb-eSH7bGtmTGxtVW5JWUE/view
All'interno di Kibana e' possibile personalizzare la propria dashboard per eseguire specifiche ricerche, e visualizzare grafici.
Di seguito gli export di una dashboard di esempio (qui uno screenshot: https://drive.google.com/file/d/0B_K5uRb-eSH7cU9ydWhUMUNYM0U/view) contenente una mappa per la geolocalizzazione degli eventi, un diagramma a torta con le signature piu' utilizzate, gli istogrammi relativi ai top source e destination ip e l'elenco degli eventi relativi ai grafici mostrati:
search.json: https://drive.google.com/file/d/0B_K5uRb-eSH7M0pBUVZ2NnNpVDA/view?usp=sharing
visualization.json: https://drive.google.com/file/d/0B_K5uRb-eSH7Tzh6U2RfZ1ZRcjg/view?usp=sharing
dashboard.json: https://drive.google.com/file/d/0B_K5uRb-eSH7Rm1XT2ZobUlITnc/view?usp=sharing