19. 09. 2017 Massimo Giaimo Information Security Operations Center, NetEye

Vittime di attacchi cibernetici? NetEye e Kibana possono aiutarvi!

La sicurezza informatica rientra tra le principali priorità di ogni CIO. Gli attacchi cibernetici sono ormai una realtà che va affrontata quotidianamente. Sempre più aziende rientrano tra le vittime dei cosiddetti cybercrime dovendo, loro malgrado, pagarne le conseguenze in termini finanziari, operativi e di reputazione.

Ecco perché cercare di strutturare meglio le difese, aumentando l’efficienza e la reattività in caso di attacco è ormai una pratica da considerarsi fondamentale per i reparti IT. Come adeguarsi a queste nuove esigenze? Uno tra i principali accorgimenti è l’adozione di un Information Security Operations Center (ISOC) che si occupi della gestione delle funzionalità di sicurezza e del monitoraggio proattivo dell’infrastruttura.

Nuova strategia per il controllo della sicurezza

Ultimamente, nel Gruppo Informatica Bancaria Trentina, azienda per la quale lavoro, che si occupa dello sviluppo del sistema informativo bancario Gesbank Evolution e dell’erogazione di servizi di outsourcing informatico, ci stiamo sempre più focalizzando sulla realizzazione di un Information Security Operations Center. Per garantire maggiore sicurezza e controllare le minacce cibernetiche stiamo sfruttando i vantaggi offerti da Kibana e Grafana: moduli di data visualization integrati in NetEye. Questi strumenti consentono la creazione di dashboard di facile interpretazione. Più precisamente, ci siamo concentrati sulla produzione di dashboard relative al load dell’infrastruttura (utilizzo di cpu dei vari nodi e carico di banda dei diversi switch) ed agli eventi di sicurezza che ci consentono di capire se la nostra organizzazione in un dato momento è oggetto di attacco.

Sono proprio quelle dashboard che riescono ad offrire valore aggiunto in quelle situazioni nelle quali è essenziale individuare in tempi rapidi la sorgente del problema, come ad esempio all’interno di un ISOC (Information Security Operation Center).

Kibana per la visualizzazione in tempo reale di potenziali attacchi cibernetici

Una delle prime attività che è necessario effettuare per rendere sicura un’organizzazione, come ho avuto modo di scrivere in un recente post sul mio blog personale (http://www.fastfire.org/2017/09/07/sicurezza-di-unorganizzazione-da-dove-parto/), è quella di avere la disponibilità delle varie informazioni sulle quali andremo poi a costruire le nostre visualizzazioni.

Nel nostro caso è perciò importante configurare i vari device (host, switch, router, firewall, oggetti IoT,…) in modo tale che inoltrino i log generati verso il log manager di NetEye.

Fatto questo possiamo concentrarci sull’implementazione delle dashboard. Una cosa che abbiamo trovato davvero utile in Kibana è la possibilità di creare una mappa riportante la geolocalizzazione dei campi ip contenuti nei vari log. Nel nostro caso abbiamo utilizzato questa funzionalità per visualizzare le varie sorgenti di attacco. All’interno della nostra organizzazione abbiamo costruito una mappa che visualizza le sorgenti di attacco raccolte da vari data set creati ad esempio dall’Intrusion Prevention System (IPS) Snort e dai vari agenti Safed installati sui nostri sistemi. Dopo aver configurato l’IPS in modo tale da consentirgli di inviare le proprie evidenze al log manager di NetEye, in Kibana abbiamo creato una semplice ricerca del tipo “program:snort OR (“ImapSSLServer” AND “invalid password) OR (“more authentication failures”).

Questo è solo un esempio di ricerca che ha come obiettivo quello di collezionare in un’unica dashboard gli attacchi provenienti da diverse sorgenti, ma ovviamente la ricerca può contenere qualsiasi cosa che restituisca un output utilizzabile. Abbiamo poi configurato il necessario per la creazione della mappa. Di seguito l’installazione step-by-step del supporto alla geolocalizzazione effettuata in NetEye:

# cd /var/lib/neteye/logstash/etc
# curl -O “http://geolite.maxmind.com/download/geoip/database/
GeoLiteCity.dat.gz”
# gunzip GeoLiteCity.dat.gz

Abbiamo poi modificato i file di filtro di logstash dove già erano presenti dei campi di tipo ip ai quali applicare la geolocalizzazione. Abbiamo aggiunto il blocco geoip all’interno del quale è necessario inserire il nome del campo al quale si vuole applicare la geolocalizzazione ( source => “$field_name”). Nel nostro caso abbiamo modificato i seguenti filtri:

Click here to learn more

1_f00200_safed_header.filter (viene applicato a tutti i log inviati a NetEye dall’agent Safed)

else if [type] == “syslog” and [message] =~ /.*Safed\[\d+\]\[\d+\].*ImapSSLServer-.*authentication failed.*/ {
grok {
match => [ “message”, “(?\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d*) (?\w*)\s+(?\[\w*\-\d*\]) \[ip=(?\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3});] security – cmd=Auth; account=(?\S*)@sibtonline.eu;” ]
add_tag => “zimbra_imap_auth_failed”
remove_tag => “_grokparsefailure”
break_on_match => true
}
geoip {
source => “remoteHost”
target => “geoip”
database => “/var/lib/neteye/logstash/etc/
GeoLiteCity.dat”
add_field => [ “[geoip][coordinates]”, “%{[geoip][longitude]}” ]
add_field => [ “[geoip][coordinates]”, “%{[geoip][latitude]}” ]
}
mutate {
convert => [ “[geoip][coordinates]”, “float”]
}
date {
match => [ “timestamp”, “MMM d HH:mm:ss”, “MMM dd HH:mm:ss”, “ISO8601” ]
remove_field => “timestamp”
}
}

1_f00450_pfsense_snort.filter (viene applicato a tutti i log inviati a NetEye dall’IDS Snort)

filter {
if [program] == “snort” {
if [message] =~ /.* ET .*{(TCP|UDP)} .*:.* -> .*:.*/ {
grok {
match => [ “message”, “.* ET .*{%{WORD:snort_protocol}} %{IP:snort_src_ip}:%{INT:snort_src_port} -> %{IP:snort_dst_ip}:%{INT:snor
t_dst_port}” ]
remove_tag => “_grokparsefailure”
}
geoip {
source => “snort_src_ip”
target => “geoip”
database => “/var/lib/neteye/logstash/etc/GeoLiteCity.dat”
add_field => [ “[geoip][coordinates]”, “%{[geoip][longitude]}” ]
add_field => [ “[geoip][coordinates]”, “%{[geoip][latitude]}” ]
}
mutate {
convert => [ “[geoip][coordinates]”, “float”]
}
}
}
}

1_f00500_unix_audit.filter

} else if [message] =~ /.*authentication failures;.*user=.*/ {
grok {
match => [ “message”, “.*%{NUMBER:count} more authentication failures;.*rhost=%{IPORHOST:rhost}.*user=%{USER:username}” ]
add_field => [ “audit_type”, “FAILURE” ]
add_tag => “AUDIT_FAILURE”
}
geoip {
source => “rhost”
target => “geoip”
database => “/var/lib/neteye/logstash/etc/GeoLiteCity.dat”
add_field => [ “[geoip][coordinates]”, “%{[geoip][longitude]}” ]
add_field => [ “[geoip][coordinates]”, “%{[geoip][latitude]}” ]
}
mutate {
convert => [ “[geoip][coordinates]”, “float”]
}
}
mutate {
convert => { “count” => “integer” }
}

Abbiamo poi applicato la configurazione di logstash:

# /var/lib/neteye/logstash/scripts/logstash-applyconf.sh

In Kibana abbiamo quindi creato una nuova Visualization di tipo Tile map, specificando come field del bucket geoip.location:

Nuova Visualization di tipo Tile map in Kibana per la geolocalizzazione

Configurazione della Visualization di tipo Tile map in Kibana

Successivamente abbiamo quindi creato la dashboard:

Geolocalizzazione in Kibana degli attacchi cibernetici

In questo modo conosciamo istantaneamente la geolocalizzazione delle sorgenti di attacco alla nostra infrastruttura. Ma ovviamente le potenzialità di questo strumento hanno ben pochi limiti se non quello della fantasia e quindi ognuno può facilmente costruire le proprie mappe geolocalizzate in tutta semplicità e a seconda delle diverse esigenze.

In Kibana abbiamo costruito anche una dashboard che ci permette di controllare l’andamento temporale degli attacchi registrati da Snort e gli ip che hanno portato più attacchi, oltre ad ulteriori informazioni utili al fini dell’information security dell’organizzazione, quali ad esempio gli eventuali errori di autenticazione ai sistemi di firewalling e la presenza di ip/mac address duplicati nella rete, che potrebbe far pensare ad esempio ad errori umani oppure alla presenza di attacchi di tipo MITM (Man In The Middle).

Errori di autenticazione ai sistemi di firewall e presenza di ip/mac address duplicati nella rete, che potrebbero segnalare la presenza di attacchi di tipo MITM (Man In The Middle).

Verifica del load generale dell’infrastruttura con Grafana

Un’ulteriore dashboard che ci sta aiutando notevolmente nelle nostre attività di troubleshooting è quella che abbiamo costruito in Grafana. Grazie alla possibilità di mettere a confronto diversi output in unico grafico, abbiamo costruito una prima dashboard che ci consente di visualizzare il load della nostra infrastruttura di sistemi (suddivisi tra host AIX e host Linux) e del bandwidth gestito in un determinato momento da alcuni dei nostri switch. Di seguito la dashboard creata:

Visualizzazione del load dell’infrastruttura di sistemi (suddivisi tra host AIX e host Linux) e del bandwidth

Da questa dashboard possiamo poi andare più in dettaglio sfruttando quello che è il campo “Drilldown / detail link” di Grafana e che consente di creare un link ad un’ulteriore dashboard. Ad esempio, cliccando sul link della dashboard “SWITCH bandwidth” possiamo visualizzare il dettaglio di quelle che sono le porte dello switch con maggior traffico:

Il “Drilldown / detail link” di Grafana consente di visualizzare il dettaglio del traffico sulle porte dello switch

In generale l’integrazione della stack ELK (Elasticsearch, Logstash, Kibana) e di Grafana in NetEye ci sta dando grandi soddisfazioni e ci permette di avere finalmente un punto di osservazione unico, in grado di aiutarci notevolmente nelle nostre attività di troubleshooting.

Conclusione

In conclusione, l’integrazione di Kibana e Grafana all’interno di NetEye consente di raccogliere dati, analizzarli e automatizzarli per garantire un rilevamento tempestivo delle possibili minacce a livello cibernetico e poter intraprendere le dovute azioni preventive. Grazie a questo ambiente riusciamo a lavorare con maggior sicurezza con un sistema di monitoraggio ottimizzato che si concentra sulla proattività e sulla rapida identificazione della causa di possibili problematiche.