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

NetEye & EriZone at it-sa

Posted by on set 13, 2017 in EriZone & OTRS, NetEye | 0 comments

Tobias_TrueHeroes_03

Be our guest on the it-sa

Between the 10th and 12th of October, we welcome you  at Europe’s largest IT security fair trade, the it-sa in Nuremberg-Germany.

By visiting our stand located in Hall 10.1 – 520, you will get the latest insights on all new functionalities related to NetEye, EriZone and ntop – especially in Cloud and IoT environments.

When and where

Get your free, personal ticket by inserting our Special guest Code A384367 at it-sa.de/Gutschein. We´re looking forward to meet you there!!

Read More

JavaScript Design Patterns in Icinga Web 2

Posted by on set 11, 2017 in Development, NetEye | 0 comments

Picture5

Sei alla ricerca delle linee guida per creare nuove funzioni JavaScript in Icinga Web 2? Attraverso quest’articolo cercherò di spiegarti la struttura che la tua funzione dovrà avere per essere correttamente compilata da Icinga Web 2.

Se hai già analizzato il codice, ti sarai accorto che le funzioni JavaScript di Icinga sono caratterizzate dalla tipica struttura dei JavaScript Design Patterns.

Cos’è un Design Pattern?

design pattern sono avanzate soluzioni per lo sviluppo object-oriented, che viene comunemente utilizzato nello sviluppo di soluzioni software. Il cruccio di ogni sviluppatore è quello di produrre codice che sia facilmente interpretabile, ri-utilizzabile e mantenibile e i design pattern risultano un ottimo strumento per risolvere questo problema: lo sviluppo basato su design pattern prevede la creazione di funzioni attraverso l’ausilio di blocchi base di codice, che non sono altro che le soluzioni di problemi/funzionalità che ricorrono frequentemente nel software, che possono essere riutilizzati all’interno di funzioni, con struttura piu complessa.

Design Pattern in JavaScript

JavaScript è un linguaggio “ad oggetti” basato sul concetto di prototipo a differenza della maggior parte dei linguaggi di programmazione basati sul concetto di classe. A differenza dei linguaggi ad oggetti tradizionali, dove una classe definisce tutte le caratteristiche che può avere un oggetto, in JavaScript è possibile definire alcune caratteristiche per un oggetto ed arricchirlo di nuove proprietà e metodi, facendoli ereditare da altri oggetti sulla base di un concetto noto come “prototypical inheritance“, che in parole povere significa che un “data type” può essere creato definendo quella che viene chiamata funzione costruttore. Vediamo come, quanto finora descritto viene applicato in Icinga:


			
Read More

Release Notes: NetEye 3.11 e EriZone 5.2!

Posted by on set 1, 2017 in EriZone & OTRS, NetEye | 0 comments

ReleaseNotes_new

Siamo lieti di annunciare il rilascio delle nuove minor release delle nostre soluzioni di IT System & Service Management NetEye e EriZone. Oltre ad importanti miglioramenti, soprattutto in ambito di stabilità e ottimizzazione delle prestazioni, sono state introdotte molteplici funzionalità. Le release notes descrivono le nuove funzionalità e forniscono informazioni per la procedura di aggiornamento,  per maggiori dettagli potete visualizzarle sulle pagine del nostro sito web aziendale.

Read More

Non mancare al prossimo NetEye & EriZone User Group

Posted by on ago 31, 2017 in EriZone & OTRS, NetEye, ntop | 0 comments

UserGroup

NetEye & EriZone User Group

Sfide e opportunità per l’IT Management 4.0

Connectbay, Mantova, Giovedì 19 ottobre 11:00 – 17:00

Siamo lieti di invitarvi il 19 ottobre al NetEye & EriZone User Group. L’evento vi offrirà un’occasione unica per scoprire le ultime novità nell’IT System & Service Management, individuare i requisiti necessari per adeguarsi al GDPR (General Data Protection Regulation) e partecipare attivamente alla definizione della fase evolutiva delle nostre soluzioni.

Read More

Dovete aggiornare Computer Windows con WSUS? Ecco alcuni consigli.

Posted by on ago 22, 2017 in NetEye | 0 comments

Upgrade_WSUS

Da molti anni il servizio WSUS (Windows Server Update Services, ex SUS, Software Update Services) rappresenta il modo più utilizzato nelle aziende per gestire gli aggiornamenti dei Computer Windows.

Il prodotto esiste dall’anno 2005 e a partire da Windows Server 2008 R2 è diventato un Ruolo installabile sui Server.

WSUS gestisce il catalogo degli aggiornamenti per le componenti di Windows e degli altri prodotti Microsoft, il ciclo di approvazione, la messa a disposizione in rete locale, ma non ha alcun controllo su quando e come tali aggiornamenti vengono applicati sui Computer destinatari: pur con questo limite, WSUS viene preferito perché gratuito e più facile da gestire rispetto al System Center Configuration Manager, prodotto che invece può forzare e controllare centralmente l’invio degli aggiornamenti.

Read More