Vittime di attacchi cibernetici? NetEye e Kibana possono aiutarvi!

Posted by on set 19, 2017 in Information Security Operations Center, NetEye | 0 comments

cyber attacks as a technology concept illustration design

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”, “(?

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

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).

IMG_Kibana_ErroriDILogin_03

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:

IMG_Kibana_Load_04

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:

IMG_Kibana_05

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.

Read More

Remote Banking Monitoring con Alyvix e NetEye

Posted by on dic 13, 2016 in NetEye, NetEye Conference, Real User Experience Monitoring | 0 comments

RemoteBanking_Header_Alyvix

Massimo Giaimo, Senior System & Network Administrator in IBT, condivide la propria esperienza d’uso di Alyvix e NetEye.

Quali sono i cambiamenti recenti più significativi dal punto di vista del monitoraggio di applicazioni?

Per decenni i reparti IT si sono occupati principalmente del controllo delle prestazioni attraverso gli uptime dei sistemi che erogano i servizi IT. Solo negli ultimi anni è nata l’esigenza e la consapevolezza che non è sufficiente soffermarsi al controllo dell’infrastruttura. È indispensabile misurare la reale percezione dell’utente. Attraverso la misurazione della End User Experience si può garantire la soddisfazione dei clienti e il corretto funzionamento delle applicazioni. Tempi di risposta, interazioni fallite e utilizzo reale sono le nuove metriche poste al centro dell’attenzione.

Read More