theses

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e
dell’Energia Sostenibile
Corso di Laurea Magistrale in Ingegneria Informatica e dei Sistemi per le
Telecomunicazioni
Tesi di Laurea
Utilizzo di Splunk per l’estrazione di conoscenza descrittiva e
diagnostica e per la ricerca di anomalie sugli accessi relativi
al firewall e sugli accessi e gli errori relativi al Web Server di
Ateneo
Relatori
Candidata
Prof. Domenico Ursino
Rossella Oliva
Dott. Melchiorre Monaca
Anno Accademico 2015-2016
Alla mia famiglia.
Indice
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Lo scenario di riferimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Cosa sono i log nel contesto della sicurezza informatica . . . . . . . . . . . . 7
1.2 I log di accesso al web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 I log di errore sul web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 I log di accesso al firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Strumenti software utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 I software di Security Information and Event Management . . . . . . . . .
2.2 Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Utilizzo di Splunk per l’analisi dei log . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 App di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
21
29
33
36
Installazione di Splunk e caricamento dei dati da analizzare . . . . . . . .
3.1 Installazione di Docker e di Spunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Caricamento dei dati in Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Indicizzatore di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
41
45
Progettazione e realizzazione dell’analisi descrittiva . . . . . . . . . . . . . . . . .
4.1 Analisi descrittiva dei log di accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Analisi descrittiva dei log di errore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Analisi descrittiva dei log del firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49
61
62
Anomaly Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Introduzione all’analisi degli outlier e Data Mining a supporto della
cybersecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Machine Learning Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Outlier Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Analisi degli outlier relativi agli accessi al firewall . . . . . . . . . .
5.3.2 Analisi degli outlier relativi agli accessi al server web . . . . . . . .
71
71
72
74
75
84
VI
Indice
Discussione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 SWOT Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 SWOT Analysis dell’analisi dei log tramite Splunk . . . . . . . . . . . . . . . .
6.2.1 Punti di Forza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Punti di Debolezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Opportunità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4 Minacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Best Practice e Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Generalizzabilità dell’approccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
89
90
91
91
93
93
94
96
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Riferimenti bibliografici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Ringraziamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Elenco delle figure
1.1
1.2
1.3
1.4
1.5
Architettura della rete di Ateneo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo di Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schema di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di schema di rete con firewall Cisco ASA . . . . . . . . . . . . . . . . .
10
10
14
16
16
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
Logo di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installazione di Splunk sui principali sistemi operativi . . . . . . . . . . . . . .
Pagina del login di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pagina iniziale dell’nterfaccia web di Splunk . . . . . . . . . . . . . . . . . . . . . .
Aggiunta dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta dei dati da diverse source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazioni di input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anteprima dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File caricato correttamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Campi estratti automaticamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inclusione di una parte di log nella ricerca . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione fornita da Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assistente di ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dati indicizzati da Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaccia per la ricerca in Splunk Enterprice . . . . . . . . . . . . . . . . . . . . .
Modalità di salvataggio delle ricerche . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Condivisione dei risultati della ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di grafico in Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esportazione di dashboard in formato PDF . . . . . . . . . . . . . . . . . . . . . . .
Personalizzazione delle visualizzazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaccia dell’analisi Drilldown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intervallo temporale di analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ricerca app in splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
App Machine Learning Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risultato della ricerca lanciata in Google Maps for Splunk . . . . . . . . .
21
22
24
24
25
25
26
26
27
27
27
28
28
28
29
30
30
31
31
32
32
32
33
34
35
35
36
VIII
Elenco delle figure
3.1
3.2
3.3
3.4
3.5
3.6
3.7
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
Opzioni per immettere i dati in Splunk Web . . . . . . . . . . . . . . . . . . . . . .
Elenco delle opzioni selezionate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avviso di Spunk relativo allo spazio di archiviazione disponibile
sull’hard disk inferiore a 5GB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione del minimo spazio libero sul disco in Splunk Web . . . . . .
Fasi di parsing e indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ciclo di vita dei buckets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posizione dei bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Andamento e frequenza degli eventi per il mese di Ottobre 2016 . . . . .
Pagine web maggiormente consultate . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Home page del sito web dell’Università “Mediterranea”di Reggio
Calabria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Useragent che maggiormente accedono al sito web dell’Ateneo . . . . . . .
Pagina web dei docenti dei diversi dipartimenti d’Ateneo . . . . . . . . . . .
Numero di indirizzi IP che accedono per ogni giorno di Ottobre al
server web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappa degli indirizzi IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le dieci risorse maggiormente richieste . . . . . . . . . . . . . . . . . . . . . . . . . . .
I sistemi operativi maggiormente usati per accedere al server . . . . . . . .
Modelli dei dispositivi usati per accedere al server web . . . . . . . . . . . . .
Web crawler che hanno effettuato il maggior numero di accessi . . . . . .
Mappa dei Web crawler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web crawler che hanno effettuato il maggior numero di accessi . . . . . .
Indirizzi IP che hanno effettuato il maggior numero di accessi . . . . . . .
Andamento degli eventi dell’indirizzo IP che ha effettuato il maggior
numero di accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pagine web richieste dall’indirizzo IP 78.47.225.238 . . . . . . . . . . . . . . . .
Le prime dieci pagine web richieste dall’indirizzo IP 78.47.225.238 . . .
Il sistema operativo più utilizzato dall’indirizzo IP che ha effettuato
più accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivo più utilizzato dall’indirizzo IP che ha effettuato più accessi
Risorse maggiormente richieste dall’indirizzo IP che ha effettuato
più accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Codici di stato HTTP inviati all’indirizzo IP che ha effettuato più
accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabella di contingnza con le pagine web richieste e i relativi codici
di Stato HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappa geografica in cui sono localizzati gli errori . . . . . . . . . . . . . . . . . .
Fascia oraria in cui è stato riscontrato l’errore PHP Fatal Error . . . . .
Primi dieci errori maggiormente riscontrati . . . . . . . . . . . . . . . . . . . . . . .
I dieci messaggi d’errore che sono apparsi maggiormente . . . . . . . . . . . .
Paesi che hanno effettuato più connessioni su porte diverse . . . . . . . . .
Indirizzi IP che accedono maggiormente dalla Cina . . . . . . . . . . . . . . . .
Indirizzi IP che accedono maggiormente dagli Stati Uniti . . . . . . . . . . .
Paesi che hanno effettuato complessivamente più connessioni . . . . . . . .
42
42
43
44
46
47
48
49
50
50
51
51
52
52
53
53
54
55
55
56
56
57
57
58
58
59
59
60
60
61
62
63
63
64
65
65
65
Elenco delle figure
4.31 Andamento temporale delle connessioni relative all’indirizzo IP
205.185.208.98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.32 Connessioni negate dell’IP 205.185.208.98 durante il 16 Ottobre . . . . .
4.33 Connessioni negate all’IP 205.185.208.98 durante il 17 Ottobre . . . . . .
4.34 Connessioni permesse all’IP 205.185.208.98 durante il 17 Ottobre . . . .
4.35 Connessioni SSH negate all’IP 205.185.208.98 il 16 Ottobre . . . . . . . . .
4.36 Connessioni SSH negate all’IP 205.185.208.98 il 17 Ottobre . . . . . . . . .
4.37 Connessioni permesse alla porta SSH per l’IP 205.185.208.98 il 17
Ottobre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.38 Connessioni Telnet negate all’IP 205.185.208.98 il 17 Ottobre . . . . . . .
4.39 Connessioni permesse alla porta Telnet per l’IP 205.185.208.98 il 17
Ottobre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
Interfaccia grafica dell’app Machine Learning Toolkit . . . . . . . . . . . . . .
Esempio di visualizzazione nel caso di rilevazione di outlier numerici .
Andamento temporale degli accessi al firewall . . . . . . . . . . . . . . . . . . . . .
Numero di outlier relativi a tutti gli indirizzi IP sorgente e numero
totale di eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grafico degli outlier relativi a tutti gli indirizzi IP sorgente . . . . . . . . .
Indirizzi IP outlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabella riassuntiva relativa a tutti gli indirizzi IP più anomali . . . . . . .
Stato della connessione relativa all’indirizzo IP del Regno Unito . . . . .
Protocollo usato dall’IP del Regno Unito . . . . . . . . . . . . . . . . . . . . . . . . .
Le prime 20 porte a cui si è connesso l’IP del Regno Unito . . . . . . . . . .
Le prime 20 porte a cui si è connesso l’IP della Cina . . . . . . . . . . . . . . .
Numero degli outlier relativi agli IP italiani e numero totale di eventi
Grafico degli outlier relativi agli indirizzi IP italiani . . . . . . . . . . . . . . . .
Tabella riassuntiva con gli indirizzi IP italiani più anomali . . . . . . . . . .
Numero degli outlier relativi ad IP non italiani e numero totale di
eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabella riassuntiva con gli indirizzi IP più anomali non italiani . . . . . .
Grafico degli outlier relativi agli indirizzi IP anomali non italiani . . . .
Indirizzi IP non italiani più anomali . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Numero di porte di destinazione outlier e numero totale di eventi . . . .
Grafico degli outlier relativi alle porte di destinazione . . . . . . . . . . . . . .
Indirizzi IP che effettuano più connessioni alla porta 23 . . . . . . . . . . . .
Numero degli outlier relativi agli indirizzi IP che si collegano alla
porta 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grafico degli outlier relativi agli indirizzi IP che si collegano alla
porta 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stato delle connessioni effettuate dalla Repubblica Coreana sulla
porta 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stato delle connessioni effettuate dall’Ucraina sulla porta 23 . . . . . . . .
Andamento degli accessi al server web d’Ateneo . . . . . . . . . . . . . . . . . . .
Numero di IP outlier e numero totale di eventi . . . . . . . . . . . . . . . . . . . .
Grafico degli outlier relativi agli indirizzi IP che accedono al web
server Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IX
66
67
67
67
68
68
68
69
69
73
75
75
76
76
77
77
77
78
78
78
79
79
80
80
80
81
81
81
81
82
82
82
83
83
84
84
85
X
Elenco delle figure
5.29
5.30
5.31
5.32
5.33
5.34
5.35
5.36
Tabella riassuntiva con gli indirizzi IP più anomali . . . . . . . . . . . . . . . . .
Numero di IP outlier non italiani e numero totale di eventi . . . . . . . . .
Grafico degli outlier relativi agli IP non italiani . . . . . . . . . . . . . . . . . . .
Tabella riassuntiva con gli indirizzi IP non italiani più anomali . . . . . .
Grafico con gli indirizzi IP degli outlier non italiani . . . . . . . . . . . . . . . .
Numero di bot outlier e numero totale di eventi . . . . . . . . . . . . . . . . . . .
Grafico degli outlier relativi ai bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grafico con i bot outlier che accedono al server web d’Ateneo . . . . . . .
85
85
85
86
86
87
87
87
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Diagramma illustrativo di una matrice SWOT . . . . . . . . . . . . . . . . . . . .
Interfaccia per la ricerca delle app di Splunk . . . . . . . . . . . . . . . . . . . . . .
App “Splunk Enterprise Security” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Costi di Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Errore riscontrato durante il caricamento dei log in Splunk web . . . . .
Logo Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo di Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
92
92
93
95
96
97
Elenco dei listati
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Formato dei log di accesso ad un web server Apache . . . . . . . . . . . . . . .
Formato Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipico formato di un log di firewall per l’evento con codice 106100 . . .
Informazioni contenute nel log per l’evento con codice 106100 . . . . . . .
Tipico formato di un log per l’evento con codice 302013 . . . . . . . . . . . .
Informazioni contenute nel log per l’evento con codice 302013 . . . . . . .
Tipico formato di un log di firewall per l’evento con codice 302014 . . .
Informazioni contenute nel log per l’evento con codice 302014 . . . . . . .
Comandi usati per l’installazione di Docker . . . . . . . . . . . . . . . . . . . . . . .
Comando per la verifica della corretta installazione di Docker . . . . . . .
Output che dimostra che l’installazione è avvenuta correttamente . . . .
Estrazione dal repository di un’immagine che utilizza l’ultima
versione di Splunk Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creazione di un volume virtuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esecuzione di docker Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione del minimo spazio libero sul disco con CLI . . . . . . . . . . .
Impostazione del minimo spazio libero sul disco nel file di
configurazione server.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parser in Python per la divisione dei file di log . . . . . . . . . . . . . . . . . . . .
12
14
16
17
17
18
18
18
39
40
40
40
40
41
43
43
44
Introduzione
La rapida evoluzione delle tecnologie ha avuto un profondo impatto sulla nostra
società e sulle nostre vite. La presenza di reti wireless, a cui si può accedere praticamente dovunque, ha incoraggiato la diffusione capillare di dispositivi in grado di
connettersi alla rete; si va dai tablet ai cellulari fino ai più recenti wearable device,
oggetti tradizionali, come l’orologio o gli occhiali, che possono connettersi al web.
Ma collegarsi alla rete, oltre a permettere l’accesso a una mole enorme di informazioni, rende, anche, potenzialmente vulnerabili i nostri dispositivi con tutto
quello che contengono, dai dati personali, ai profili sui social network, fino agli
accessi ai servizi di online banking.
Questo accade sia per i singoli che per le grandi realtà aziendali, come le banche,
le società energetiche o gli ospedali, che usano la rete per scambiare informazioni,
per organizzare la fornitura dei servizi e per coordinare le attività. In altre parole
l’accesso a Internet ci apre al mondo, ma rende le persone, le aziende e le istituzioni potenzialmente esposte a rischi di truffa, furto di informazioni o sabotaggio. Il
pericolo non va sottovalutato.
Quando colleghiamo un computer ad una rete sorgono molte problematiche legate alla sicurezza. Piccole, medie e grandi aziende, come pure singoli utenti, richedono
che i propri dati mantengano una certa riservatezza e siano inaccessibili da persone
non autorizzate. Tale riservatezza, viene, spesso messa in discussione da hacker, che
possono prendere di mira server web, imbrattare siti web oppure ottenere accessi
fraudolenti.
Le vulnerabilità dei sistemi informatici consentono di accedere in pochi secondi
a segreti industriali, brevetti e innovazioni che hanno richiesto anni di ricerca. Il
crimine informatico può decretare il fallimento di aziende, e quindi danni economici enormi. Per le nostre imprese, che puntano sull’innovazione come elemento di
sviluppo, il danno potenziale può essere enorme.
La correlazione tra prosperità economica del Paese e qualità delle sue infrastrutture cyber sarà sempre più stretta, e l’Italia dovrà puntare sempre più su alti
standard di cybersecurity nella società, nel sistema industriale e nella Pubblica
Amministrazione.
Infatti, non sono a rischio solo le persone e le aziende, anche la sicurezza nazionale può potenzialmente essere messa in pericolo. Si pensi alle conseguenze che
potrebbero derivare dall’alterazione dei sistemi che regolano il trasporto, le reti
4
Introduzione
energetiche o i sistemi di comando e controllo militari. Non si tratta di un futuro
remoto o di uno scenario da saga fantascientifica. Il cyber crimine è già, oggi, una
realtà, e cresce nel mondo a ritmo sostenuto.
In sintesi, tutti noi siamo esposti al rischio di intrusioni, che possono avere
effetti devastanti sulla vita personale e sulla vita economica dell’intero paese. Si
tratta, quindi, di pericoli reali che non possono più essere sottovalutati. Sviluppare
nuove capacità e nuovi strumenti per migliorare la cybersecurity del sistema Paese
rappresenta, quindi, una sfida di grande importanza per la crescita, il benessere e
la sicurezza dei cittadini.
Nel caso di tentato accesso fraudolento, le aziende devono poter bloccare il traffico non autorizzato. La maggior parte delle aziende utilizzano i firewall che, se propriamente aggiornati e manutenuti, servono a bloccare il traffico illecito e a creare
log dettagliati per tutto il traffico in entrata ed in uscita. Se analizzati correttamente, i log dei firewall possono evidenziare attacchi di Denial of Service (DoS), o altre
attività sospette. Tuttavia, poche aziende analizzano questi log, e anche quelle che
lo fanno, lo fanno poco frequentemente.
Quindi, molti tentativi di attacco passano inosservati, dando agli hacker un’elevata probabilità di superare la barriera rappresentata dai firewall. La firewall log
analysis è un’operazione complessa che richiede il controllo simultaneo di migliaia di
eventi. I processi automatizzati di oggi possono filtrare la stragrande maggioranza
degli eventi, identificando soltanto quelli che sono abbastanza sospetti da richiedere
un’ulteriore analisi da parte di un esperto. L’analista distingue un attacco dal normale traffico e, nel caso di un attacco certo, può cambiare proattivamente la firewall
policy aggiornando tutti i sistemi di network intrusion detection.
Nella cybersecurity, la raccolta e la memorizzazione di log è ormai riconosciuta
come una pratica virtuosa per l’analisi dei rischi e per il rafforzamento delle politiche
di sicurezza.
Uno dei meccanismi per l’individuazione delle attività sospette è la verifica dei
log di sistema, che consente di individuare attività anomale e di monitorare i pacchetti destinati al firewall o al server. I file di log di un web server o di un firewall
registrano informazioni di eventi scaturiti durante l’esecuzione di un processo ed,
attraverso la loro analisi, è possibile individuare attacchi ai sistemi, in quanto questi
ultimi potrebbero lasciare segni negli eventi contenuti nei log.
I file di log di un server web registrano gli eventi generati dal sistema di autenticazione nel momento in cui l’utente effettua l’accesso, o tenta di effettuare l’accesso al
server. Gli error log vengono usati principalmente per individuare attività sospette.
Un sistema SIEM (Security Information and Event Management) è uno degli
strumenti fondamentali per un approccio alla difesa in profondità, a beneficio della sicurezza delle aziende. I software SIEM definiscono un prodotto, costituito da
software e servizi, che unisce capacità di “Security Information Management”(SIM)
con capacità di “Security Event Management”(SEM). Più specificatamente:
•
•
un SIM si occupa della parte di “Log management”, di attività di analisi e della
produzione di report;
un SEM si occupa del monitoraggio in real-time degli eventi, dell’incident management (in ambito security) per quanto riguarda eventi che accadono sulla rete,
sui dispositivi di sicurezza, sui sistemi o nelle applicazioni.
Introduzione
5
In sostanza, un SIEM mira a risolvere esigenze in ambito di gestione delle minacce informatiche. Una soluzione SIEM a elevate prestazioni associa eventi, minacce
e dati di rischio per fornire intelligence per la sicurezza, risposte rapide in caso di
necessità, una ininterrotta gestione dei log e un’estensibile reportistica di conformità. Tutto ciò forma il contesto necessario per una gestione adattiva dei rischi alla
sicurezza.
Per tenere testa agli attacchi esterni, alle minacce interne e alle frodi costose
è necessario un monitoraggio continuo della sicurezza e un’aderenza alle policy di
compliance aziendale, una risposta rapida agli incidenti e la capacità di individuare
e rispondere a minacce note, non note e avanzate.
Le soluzioni per la sicurezza di Splunk consentono alle organizzazioni di individuare, prevenire e rispondere a tali minacce, mettendo a disposizione preziose
informazioni contestuali e visive che aiutano a prendere decisioni di sicurezza più
rapide e più intelligenti. Splunk consente un approccio alla sicurezza basato sull’analisi. Splunk Enterprise viene, infatti, utilizzato da organizzazioni di tutto il mondo.
È stato nominato leader nel Magic Quadrant di Gartner per SIEM per quattro anni
consecutivi, compreso il 2016. Il Magic Quadrant di Gartner è la rappresentazione
grafica di un settore di mercato in cui i vendor vengono posizionati in una della
quattro categorie previste: Leader, Visionary, Niche Player e Challenger.
Questa posizione di Splunk nella categoria leader è una testimonianza della
forza della piattaforma nel settore della sicurezza. Splunk, nella categoria Leader
del Magic Quadrant del 2016, si trova al secondo posto, dopo solo IBM che, invece,
si trova al primo.
Splunk è un software che indicizza dati IT da qualsiasi applicazione, server o
dispositivo di rete che costituisce l’infrastruttura IT. È un potente e versatile motore
di ricerca e di analisi che consente di esaminare e risolvere i problemi, monitorare,
avvisare e creare report su tutto ciò che sta accadendo nell’intera infrastruttura IT
in tempo reale. Splunk, in sostanza, raccoglie e indicizza log e dati macchina da
qualsiasi fonte; le sue potenti capacità di ricerca, analisi e visualizzazione sono a
disposizione di qualunque tipo di utilizzatore; in più, le app offrono soluzioni per la
sicurezza, l’operatività IT, la business analysis, e altro ancora.
L’obiettivo della presente tesi è quello di analizzare i log di accesso e di errore
al server web e i log di accesso al firewall dell’Università “Mediterranea”di Reggio
Calabria al fine di individuare eventuali attacchi informatici.
In una prima fase sarà condotta un’analisi descrittiva dei log, per l’estrazione di
conoscenza e il supporto alla diagnosi. Successivamente verrà effettuata l’anomaly
detection al fine di rilevare le intrusioni, in quanto infrangere la sicurezza di un
sistema comporta, spesso, un uso anomalo del sistema stesso e, quindi, eventuali
attacchi informatici possono essere rilevati cercando le attività che si differenziano
dal normale comportamento. La presente tesi consiste di sette capitoli strutturati
come di seguito specificato:
•
•
Nel primo capitolo verrà spiegato cosa sono i file di log e come possono essere
utilizzati nell’ambito della sicurezza informatica. Successivamente, si focalizzerà
l’attenzione sui log di accesso e sui log di errore del web server Apache e sui log
di accesso al firewall Cisco della rete di Ateneo.
Nel secondo capitolo verrà presentato il software utilizzato per l’analisi dei file
di log, ovvero Splunk. Prima di ciò, però, si parlerà dei software di “Security
6
•
•
•
•
•
Introduzione
Information and Event Management”e si discuterà sull’importanza della gestione
dei file di log e sui vantaggi che scaturiscono da quest’ultima. Successivamente,
verrà effettuata una breve panoramica sulle app e sugli add-on di Splunk. Infine,
verrà presentata la tecnologia Docker, illustrando i vantaggi di utilizzo rispetto
alle macchine virtuali.
Nel terzo capitolo, inizialmente, si spiegherà come sono stati installati Docker e
Splunk. Successivamente, ci si soffermerà sulle modalità di caricamento dei dati
in Splunk; infine, si spiegherà come e dove Splunk memorizza i dati.
Nel quarto capitolo ci si soffermerà sulla descrizione dei risultati ottenuti dalle
analisi descrittive relative ai log di accesso e di errore al server web di Ateneo e
ai log di accesso al firewall.
Nel quinto capitolo, inizialmente, verrà spiegato perchè è importante effettuare
attività di “anomaly detection”. Successivamente, si descriverà l’app di Splunk
utilizzata per effettuare “outlier detection”. Infine, verrano illustrate le anomalie
emerse dall’analisi degli outlier.
Nel sesto capitolo, inizialmente, saranno valutati i punti di forza, di debolezza,
le opportunità e le minacce relative all’analisi dei log effettuata tramite Splunk.
Successivamente verranno descritte le Best Practice e le Lessons Learned. Infine,
verrà spiegato come può essere generalizzato il nostro approccio ad altri casi
analoghi.
Infine, nel settimo capitolo, verranno tratte le conclusioni in merito al lavoro
realizzato e verranno esaminati alcuni possibili sviluppi futuri.
1
Lo scenario di riferimento
Questo capitolo spiegherà cosa sono i file di log e come possono essere utilizzati
nell’ambito della sicurezza informatica. Successivamente si focalizzerà l’attenzione
sui log di accesso e sui log di errore del web server Apache della rete di Ateneo e
sui log di accesso al firewall Cisco della rete di Ateneo.
1.1 Cosa sono i log nel contesto della sicurezza
informatica
In ambito informatico, i log sono dei file di testo nei quali vengono registrate le
attività di un sistema operativo, di un’applicazione o degli host che li generano. Essi
memorizzano informazioni testuali riguardo eventi regolari o anomali, catturati da
un sistema durante l’esecuzione.
Quando un computer viene collegato alla rete sorgono diverse problematiche legate alla sicurezza. Le infrastrutture IT producono quotidianamente enormi quantità di log che contengono informazioni di importanza cruciale in termini di sicurezza
della rete. Le aziende, cosı̀ come i singoli utenti, richiedono che i propri dati siano inaccessibili da persone non autorizzate e mantengano una certa riservatezza,
che viene frequentemente messa in discussione dagli hacker, i quali possono inviare
virus, ottenere accessi fraudolenti e prendere di mira server web.
Per ovviare a queste problematiche, è utile una corretta gestione dei log, che
diventano uno strumento efficace per rilevare le intrusioni e gli accessi irregolari al
nostro sistema.
Tramite l’analisi dei log è possibile incrementare la sicurezza nei sistemi informatici, in quanto essa permette di individuare rapidamente, e in molti casi anche di
prevenire, problemi e anomalie della rete, dei sistemi software, dei dispositivi elettronici che generano tali log, oltre che i tentativi di attacco, i comportamenti anomali
degli utenti, le azioni intraprese dagli intrusi, le minacce, i tempi di inattività dei
sistemi, e tanto altro ancora.
I file di log, che possono essere di vario tipo, sono il mezzo attraverso il quale la
nostra applicazione ci parla. In base al loro contenuto permettono di identificare chi
fa cosa e quando, di capire quanti e quali sono i tentativi di connessione ricevuti da
8
1 Lo scenario di riferimento
parte di un certo host in un certo intervallo temporale, da dove ha avuto origine una
particolare connessione, quali sono le azioni che un particolare utente ha intrapreso,
quali sono le azioni più frequenti e in quali momenti.
Negli ultimi anni i file di log hanno assunto un’importanza crescente nell’ambito
della sicurezza dei sistemi informatici poiché consentono di mettere in atto procedure
di monitoraggio, controllo e prevenzione di violazione dei sistemi nonché, in caso di
necessità, di documentare a posteriori gli eventi accaduti e di ricostruire situazioni
che si sono verificate, ad esempio, in seguito ad una perdita di dati. In caso di
compromissione di un servizio, i log ci consentono di risalire alle operazioni effettuate
prima che si verificasse l’errore e ci aiutano ad individuare la fonte delle anomalie.
Quando si verifica un problema al proprio server o siamo stati vittima di qualche
attacco, la soluzione migliore per risalire alla fonte è quella di analizzare i log di
sistema, sempre che non siano stati modificati in caso di attacco.
La possibilità di elaborare report periodici e statistiche, tramite l’analisi dei
log, consente di effettuare attività di monitoraggio e di tenere sotto controllo le
prestazioni di un sistema. Le informazioni ricavate sono lo strumento più adatto
per la risoluzione dei problemi operazionali e per la ricerca delle soluzioni.
Per le aziende, continuamente esposte all’evoluzione dei metodi di attacco, i
rischi sono molto alti. Per tale motivo, in caso di incidenti, bisogna avere un piano
di risposta in tempo reale, una capacità di elaborazione rapida, al fine di individuare
gli eventi più significativi attraverso analisi avanzate e predittive, poiché capire cosa
sta per succedere può essere la migliore difesa.
Con l’incremento dei flussi informativi, è necessario tenere sotto controllo volumi
di dati molto alti; pertanto, aumenta la necessità di sicurezza del dato. Sono, dunque,
necessarie attività continue e rapide di monitoraggio, in modo da poter individuare
nel più breve tempo possibile i rischi per la sicurezza dei dati. Tali attività si basano
sul rilevamento, nell’ individuazione e nell’analisi di minacce, nell’indagine degli
incidenti, nella generazione di report attraverso un sistema di analisi per consentirne
uno studio immediato. Quando la prevenzione non è sufficiente, l’individuazione e
il ripristino rapido sono l’unica risorsa disponibile.
Nonostante la sua palese importanza, la gestione dei log viene affrontata dalla
maggior parte delle aziende in modo approssimativo e poco organizzato.
Inoltre, molto spesso, i file di log vengono presi in considerazione solo dopo che
si è verificato un problema o un attacco.
Tuttavia essi non devono interessare solo i casi negativi degli avvenimenti, ma
devono registrare sia quando l’azione va a buon fine sia quando fallisce. In quest’ultimo caso è bene avere quante più informazioni possibili sia sull’errore sia sul
contesto che lo ha generato, per poter effettuare un’analisi su quanto è accaduto e
prendere le dovute precauzioni affinché ciò non si verifichi più.
Per poter identificare correttamente una compromissione dello stato di security
è necessario disporre di un singolo sistema di raccolta e archiviazione di log, centralizzato ed integrato, e non di più sistemi separati. I log dovrebbero essere archiviati
con tracce temporali, eliminando la possibilità che i dati, una volta scritti, possano essere modificati. Inoltre, per non perdere d’occhio tutto quello che accade sul
nostro sistema, anche dopo un eventuale attacco informatico, è necessario salvare i
log su un dispositivo fisico esterno alla memoria del computer, poiché quest’ultima
potrebbe essere manomessa, oppure posizionare i log su un host separato, dedicato
1.2 I log di accesso al web server
9
esclusivamente a questa finalità, e posto all’interno di una sottorete protetta da firewall. Pertanto, è conveniente predisporre opportune regole per l’archiviazione dei
log e la loro dislocazione in luoghi e su supporti fisicamente sicuri. Per non rischiare
di vanificare inutilmente i meccanismi di logging è conveniente, inoltre:
•
•
•
•
proteggere i log in modo tale da consentire l’accesso ad essi ed agli strumenti
utilizzati per la loro configurazione soltanto agli utenti debitamente autorizzati;
criptare i log contenenti informazioni sensibili nel momento stesso della loro
registrazione;
configurare attentamente questo host in modo da scongiurare o limitare fortemente gli effetti di un possibile attacco di tipo DOS (Denial of Service), che può
verificarsi se l’aggressore cerca di saturare le risorse impiegate per il salvataggio
dei dati in modo da far cessare il logging;
analizzare i log con cadenza periodica avvalendosi degli strumenti esistenti per
questo scopo.
I file di log, dunque, permettono di memorizzare tutte le informazioni riguardanti
lo stato di salute del sistema e delle applicazioni.
1.2 I log di accesso al web server
Al fine di gestire efficientemente un server web, è necessario ottenere un feedback
sulle sue attività e sulle sue prestazioni. Oggigiorno, tutti i programmi software, le
applicazioni più recenti e i nuovi dispositivi sono in grado di generare log.
I log di controllo degli accessi permettono di tenere traccia degli accessi al dominio, sia che avvengano dal Web sia che avvengano da applicazioni non Web, e
consentono di verificare gli accessi riusciti, non riusciti o sospetti. Essi rappresentano un prezioso punto di partenza per indagare un problema riferito da un utente,
poiché il log di una richiesta non riuscita può stabilire il momento esatto in cui si è
verificato un errore.
I file di log di un server web registrano gli eventi generati dal sistema di autenticazione nel momento in cui l’utente effettua l’accesso o tenta di accedere al server.
In sostanza, sono dei file testuali che contengono la lista di tutti gli accessi effettuati
su un sito web.
La raccolta dei dati relativi alle attività degli utenti ed al server web è essenziale poiché, collezionando ed analizzando tali informazioni, diventa possibile non
soltanto scoprire i segni di eventuali intrusioni e determinare la portata delle azioni
compiute dall’aggressore, ma, anche, individuare tutte quelle operazioni che, pur
non rappresentando dei veri e propri attacchi, sono sintomi di un sicuro interesse di
qualcuno verso il sistema ed in particolare verso le sue vulnerabilità.
Una parte dei file di log che sono stati analizzati in questo lavoro di tesi sono i
log di accesso e i log di errore del server Apache della rete d’Ateneo dell’Università
“Mediterranea”di Reggio Calabria, la cui architettura è mostrata in Figura 1.1.
Il server web Apache, il cui logo è mostrato in Figura 1.2, fornisce una varietà
di meccanismi di registrazione per la memorizzazione di tutto quello che accade su
un server, compresi gli accessi ad esso e gli errori che si sono verificati durante tale
attività.
10
1 Lo scenario di riferimento
Figura 1.1. Architettura della rete di Ateneo
Figura 1.2. Logo di Apache
1.2 I log di accesso al web server
11
Apache HTTP Server, sviluppato dalla Apache Software Foundation, è il web
server più diffuso in Internet. È un software che ha il vantaggio di offrire funzioni di
controllo per la sicurezza, come quelle effettuate da un proxy. È affidabile, compatto,
funzionale, freeware e progettato per essere eseguito come processo standalone. È
la piattaforma server Web modulare più diffusa, cioè fornisce un insieme di moduli
per la gestione delle operazioni. Ogni modulo è un’unità indipendente che si occupa
di una funzionalità. Ad ogni richiesta del client vengono svolte funzioni specifiche
da ogni modulo di cui è composto.
Apache utilizza variabili d’ambiente per gestire operazioni come il log o il controllo degli accessi e per comunicare con programmi esterni. Le variabili possono
essere utilizzate all’interno delle direttive per regolare operazioni del server. Apache
HTTP Server è open-source e mette a disposizione sistemi di controllo d’accesso a
più livelli.
Esso è in grado di operare su una grande varietà di sistemi operativi. Viene
sviluppato e aggiornato per sistemi operativi come UNIX e Windows. È stato progettato per essere flessibile su ogni tipo di piattaforma e con ogni configurazione
d’ambiente. È molto popolare tra le aziende commerciali. Sfortunatamente, ciò lo
rende un obiettivo altrettanto popolare tra gli hacker. Di conseguenza, periodicamente, emergono nuovi exploit che mettono in pericolo l’integrità e la stabilità del
proprio server web Apache. Per molti amministratori diventa difficile mantenersi al
passo con le varie patch di sicurezza rilasciate per Apache a fronte di ogni nuovo
exploit; in questo modo, però, essi facilitano le possibilità, per utenti pericolosi, di
trovare su Internet un server web vulnerabile. Questi consentono anche ad un hacker
non particolarmente esperto di attaccare facilmente e, persino controllare, il server
web, con la possibilità di penetrare nella rete interna.
In altri termini, non è molto difficile per soggetti esterni accedere ad informazioni
aziendali riservate. Peggio, non necessariamente gli hacker sono sprovveduti, come
si pensa comunemente: per esempio, dipendenti scontenti o concorrenti dell’azienda
possono avere le loro buone ragioni per penetrare in zone confidenziali della rete.
Pochi attacchi di hacker sono immediatamente e davvero riconoscibili come tali. La
maggior parte degli attacchi non è facile da scoprire, poiché molti intrusi preferiscono
rimanere nascosti in modo da poter utilizzare il server web manipolato come base di
lancio di attacchi nei confronti di server web molto più importanti o popolari. Oltre
a danneggiare l’integrità del proprio sito web, un tale utilizzo del server può rendere
responsabile l’azienda in caso di attacchi nei confronti di altre aziende. L’attività
di logging pertanto è fondamentale per ogni servizio. Il Web Server Apache, oltre a
fornire informazioni su eventi che riguardano il funzionamento del servizio, nei log
tiene traccia di tutte le richieste HTTP eseguite. Chiunque pubblica su Internet un
proprio sito web, è interessato a sapere quanti lo visitano, cosa guardano, da dove
vengono e, magari, perchè lo fanno. Ogni server web registra e tiene traccia di ogni
file fornito ai browser dei propri client. Apache permette di scrivere nei propri log
di accesso una serie di informazioni relative ad ogni richiesta effettuata via HTTP.
I log degli accessi al web registrano informazioni relative agli accessi ai file presenti su un server. In genere, essi memorizzano: l’indirizzo IP del richiedente, l’orario
e la data in cui è avvenuta la richiesta, il metodo di recupero (solitamente GET o
POST), il file richiesto, il codice HTTP della risposta e la dimensione del file trasferito. Nei log di accesso vengono memorizzate tutte le richieste HTTP eseguite dai
12
1 Lo scenario di riferimento
client e che giungono al server, pertanto ci permettono di esaminare il traffico su
un sito web. Gli accessi sono relativi a tutti i tipi di file richiesti dai client: pagine
HTML, immagini, file sonori, e qualsiasi altro tipo di file che è necessario scaricare
dal browser per assicurare il giusto funzionamento e la corretta visualizzazione del
sito web.
Nella maggior parte dei casi, i log vengono elaborati per produrre report di
Web Analytics con finalità di marketing, ad esempio per conoscere il numero di
visitatori giornalieri, le pagine più richieste, e informazioni simili. Analizzando i
dati dei log presenti nei server web è possibile trovare informazioni rilevanti per la
sicurezza. Infatti, un’attenta indagine dei file di testo riguardanti gli accessi permette
di individuare attacchi in atto o pronti ad essere sferrati. Attraverso gli access
log è possibile, per esempio, controllare gli accessi effettuati al server web in un
determinato intervallo temporale, conoscere il numero di visitatori ad una pagina
web, anche in base a paesi e città, sapere quali sono le pagine più consultate dagli
utenti o dai web crawler, i file richiesti da un sito web, il tipo di browser utilizzato
e il dominio dei client. Potremmo, quindi, individuare le richieste che mostrano
attività sospette.
L’approccio ideale per riconoscere, in qualsiasi momento, i segni di probabili
intrusioni o di altre attività anomale consiste nel paragonare le informazioni relative
al funzionamento del sistema in quel dato momento con le analoghe informazioni
catturate in un momento anteriore (generalmente in fase di prima installazione od
operatività) che, in quanto tali, costituiscono un’ impronta affidabile e caratteristica
del funzionamento del sistema stesso. Di regola questo genere di indicazioni viene
fornito dal sistema operativo, dal software che gestisce il server web e da altri
meccanismi di terze parti.
L’utente può personalizzare il formato dei log di accesso, includendo i dati per lui
maggiormente interessanti. I log possono essere, anche, personalizzati per includere
informazioni preziose, come l’ID di sessione o intestazioni HTTP personalizzate.
Il formato di tali log è altamente configurabile: la posizione, il contenuto e il formato degli access log sono impostati dalla direttiva CustomLog. Apache memorizza
gli access log nel formato mostrato nel Listato 1.1:
207.46.13.130 - - [23/Oct/2016:07:36:34 +0200] "GET /giurisprudenza/?id=10043 HTTP/1.1" 301 577 "-"
"Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
Listato 1.1. Formato dei log di accesso ad un web server Apache
I diversi campi che costituiscono il log sono i seguenti:
•
•
207.46.13.130 : indirizzo IP del client che ha generato la richiesta al server;
i due trattini sostituiscono delle informazioni non disponibili, quali:
1. “identd, che indica l’identità del client. Apache fornisce questa informazione
solo se il campo IdentityCheck è impostato ad On.
2. “userid, ovvero l’id della persona che ha richiesto la pagina. Lo userid
è presente solo se la pagina è protetta da password, quindi se è attiva
l’autenticazione HTTP, altrimenti ci sarà “-”.
1.3 I log di errore sul web server
•
•
•
•
•
13
[23/Oct/2016:07:36:34 +0200] : data e ora in cui si è verificato l’evento. Sono necessarie per effettuare le correlazioni. In particolare abbiamo: [day/month/year:hour:minute:second zone].
“GET /giurisprudenza/?id=10043 HTTP/1.1”: richiesta effettuata dal client e
composta da:
1. GET, che rappresenta il metodo utilizzato;
2. /giurisprudenza/?id=10043, che denota la risorsa richiesta;
3. HTTP/1.1, che indica il protocollo utilizzato.
Codice di stato HTTP che il server invia al client. Per esempio, nel caso specifico,
301 indica che questa e tutte le richieste successive andranno dirette ad un altro
URI, che viene indicato nell’header;
il peso in byte.
L’ultima parte della riga contiene informazioni sullo User Agent, in particolare sul browser utilizzato dal client per il collegamento web, sul sistema operativo e sul modello del dispositivo utilizzato. Per esempio, in questo caso ci dice che la richiesta è stata effettuata da bingbot (bingbot/2.0;
+http://www.bing.com/bingbot.htm).
1.3 I log di errore sul web server
I log di errore sono i file di log più importanti di Apache. Essi registrano tutti gli
errori che un server web riscontra nel processare una richiesta e che si verificano ad
esempio quando manca un file, cioè quando gli utenti accedono ad un sito web e
non trovano i file richiesti.
Sono estremamente utili quando si verificano anomalie di funzionamento o di
avvio del server web. In tal caso, infatti, per prima cosa conviene controllare i log
di errore in quanto:
•
•
•
permettono di tenere traccia di tutto ciò che accade nel sistema in esame;
forniscono informazioni dettagliate sui problemi riscontrati dagli utenti e quindi
consentono di capire esattamente ciò che è accaduto;
permettono di determinare quali sono le cause di questi errori e, quindi, sono
utili per capire come rimediare.
Gli error log vengono usati principalmente per individuare attività sospette. Essi
possono fornire informazioni sui tentativi di hacking, in quanto gli hacker mentre
tentano di compromettere il sistema, possono causare errori sul server.
I file di log possono essere configurati in modo da memorizzare ciascun errore
che si verifica sul sistema oppure in modo da salvare soltanto gli errori specificati
dall’utente. E, cosı̀ come i log, anche un sistema può essere configurato in modo da
poter consultare tutti i log in qualsiasi momento, oppure in modo da memorizzare
solo un numero limitato di log.
Mentre gli access log possono essere personalizzati, per gli error log si può
solo definire il “livello”ovvero l’importanza che essi debbono assumere per essere
registrati.
Il nome e la posizione degli error log sono impostate con la direttiva Error Log.
Il formato di default di un error log è quello mostrato nel Listato 1.2, ma può essere
personalizzato con la direttiva ErrorLogFormat:
14
1 Lo scenario di riferimento
[Sun Oct 23 07:45:38 2016] [error] [client 157.55.39.101] File does not exist:
/media/web/unirc/dipartimenti/robots.txt
Listato 1.2. Formato Error Log
I diversi campi che costituiscono il log sono:
•
•
•
•
•
[Sun Oct 23 07:45:38 2016] : data e ora in cui si è verificato l’evento;
[error] : campo contenente il livello di gravità del messaggio (error in questo
caso);
[client 157.55.39.101] : l’indirizzo IP del client che ha generato la richiesta;
File does not exist: errore riscontrato;
/media/web/unirc/dipartimenti/robots.txt: messaggio d’errore dettagliato. In
questo caso, indica la mancanza del file richiesto dal client.
1.4 I log di accesso al firewall
Il firewall è lo strumento centrale dell’architettura e della sicurezza in una rete, della
quale è mostrato uno schema in Figura 1.3. La sua funzione è quella di separare
la rete privata da quella pubblica; tuttavia, esso ha anche la funzione di collegare
due o più tronconi di rete. Un firewall è un dispositivo per la sicurezza della rete
che permette di monitorare il traffico in entrata e in uscita utilizzando una serie
predefinita di regole di sicurezza per consentire o bloccare gli eventi. I firewall rappresentano la prima linea di difesa per la sicurezza della rete. Essi costituiscono una
barriera tra le reti interne, sicure e controllate, e quelle esterne, come Internet, che
possono essere o meno affidabili.
Figura 1.3. Schema di rete
Grazie alla sua collocazione strategica, un firewall è il “cancello”al quale vengono
autenticati ed autorizzati coloro che usufruiscono dei servizi offerti dalla rete interna
ed è il mezzo attraverso il quale la rete privata viene difesa dalle minacce, in continua
evoluzione, che provengono dall’esterno.
Esso, dunque, rappresenta una garanzia di protezione in termini di sicurezza
informatica, in quanto impedisce agli hacker di accedere a ciò che c’è dentro, in
modo che non possano infiltrarsi e installare software dannosi. Un firewall filtra
1.4 I log di accesso al firewall
15
le informazioni utili e rileva i comportamenti anomali e gli attacchi informatici.
Nel caso di trasmissione di malicious code o virus, o nel caso di tentato accesso
fraudolento, le aziende devono poter bloccare il traffico non autorizzato. La maggior
parte delle aziende utilizzano i firewall che, se propriamente aggiornati e manutenuti,
servono a bloccare il traffico illecito e a creare log dettagliati per tutto il traffico
in entrata ed in uscita. Se analizzati correttamente, i log dei firewall rivelano molte
informazioni sui tentativi di minacce alla sicurezza della rete e sulla natura del
traffico in entrata e in uscita dal firewall e, inoltre, possono evidenziare attacchi di
Denial of Service (DoS) o altre attività sospette.
Tuttavia, poche aziende analizzano questi log e anche quelle che lo fanno, effettuano le loro analisi poco frequentemente. Quindi, molti tentativi di attacco passano
inosservati, dando agli hacker un’elevata probabilità di superare la barriera rappresentata dai firewall. La firewall log analysis è un’operazione complessa che richiede
il controllo simultaneo di migliaia di eventi. I processi automatizzati di oggi possono
filtrare la stragrande maggioranza degli eventi, identificando soltanto quelli che sono
abbastanza sospetti da richiedere un’ulteriore analisi da parte di un esperto. L’analista distingue un attacco dal normale traffico e, nel caso di un attacco certo, può
cambiare proattivamente la firewall policy aggiornando tutti i sistemi di network
intrusion detection.
L’analisi dei file di log è importantissima per la sicurezza della rete in quanto
fornisce informazioni in tempo reale agli amministratori, che determinano il traffico ammissibile e non, riguardo i tentativi di minacce alla sicurezza, cosı̀ che loro
possano rapidamente avviare un’azione correttiva.
Le informazioni generate dai firewall devono essere raccolte, analizzate ed archiviate; il risultato prodotto da queste attività fornisce una risposta adeguata alle
minacce che vengono indirizzate verso la rete privata.
Dall’analisi dei file di log generati dal firewall possono essere costruiti report
contenenti, ad esempio, gli accessi bloccati dalle policy di sicurezza, la quantità di
traffico per protocollo, i siti più visitati, la distribuzione del traffico durante la giornata, l’analisi del traffico di specifici indirizzi IP, gli indirizzi IP che vengono rifiutati
e quelli che vengono rilasciati e il luogo di provenienza, i ripetuti tentativi falliti di
accedere al firewall provenienti da uno o da un gruppo di indirizzi IP. Se si notano
tanti login falliti provenienti dallo stesso indirizzo IP è possibile bloccare tutte le
connessioni provenienti da tale indirizzo, o intraprendere qualche altra azione.
L’analisi dei file di log è utile per capire l’utilizzo della rete, per la valutazione
del rischio d’impresa e per identificare qualsiasi attività dannosa all’interno della
rete.
È conveniente monitorare spesso i log dei firewall per capire quali sono le connessioni normali e quali sono quelle anomale. Per esempio, se ci sono pacchetti
provenienti dall’esterno che hanno un indirizzo IP interno alla rete, questo potrebbe indicare che qualcuno sta cercando di falsificare un indirizzo interno, al fine di
ottenere l’accesso alla rete privata.
Un’altra parte dei file di log analizzati in questo lavoro di tesi sono i log di
accesso al firewall Cisco dell’Università “Mediterranea”di Reggio Calabria.
Cisco, il cui logo è mostrato in Figura 1.4, è una azienda multinazionale specializzata nella fornitura di apparati di networking. Produce apparati per il funzionamento delle reti LAN, MAN, WAN e VLAN e il sistema operativo IOS che le
16
1 Lo scenario di riferimento
Figura 1.4. Logo Cisco
pilota. Nell’ottica della fornitura di soluzioni complete, Cisco è entrata anche nel
mercato della sicurezza, con Firewall e VPN, in quello della telefonia, con telefoni
IP, in quello dell’archiviazione, con Storage Area Network (SAN), e in quello del
computing su piattaforma x86. Il firewall Cisco fornisce una protezione ottimale
dai tentativi di intrusione, grazie alle sue numerose funzionalità, tra cui il controllo
delle applicazioni, il supporto di protocolli audio-video, la prevenzione degli accessi
tramite la protezione in tempo reale contro gli attacchi di applicazioni DOS, l’identificazione e il filtraggio dell’attività in rete di worm e di virus, l’ individuazione di
spyware, adware e malware. Il firewall Cisco ASA, mostrato in un esempio di schema di rete nella Figura 1.5, è dedicato alla protezione del nostro server; esso blocca
gli attacchi prima che si diffondano attraverso la rete e protegge le reti aziendali di
ogni dimensione; esso, infatti, può essere utilizzato come soluzione di sicurezza per
le reti di piccole e grandi dimensioni. Tale firewall fornisce agli utenti un accesso
altamente sicuro alle risorse di rete con qualunque dispositivo.
Figura 1.5. Esempio di schema di rete con firewall Cisco ASA
Un log di un firewall ha il formato mostrato nel Listato 1.3:
Oct 25 00:05:50 192.168.33.3 Oct 25 2016 00:00:24: %ASA-6-106100: access-list outside_access_in permitted udp
outside/86.101.202.111(53096) -> inside/193.204.247.180(17490) hit-cnt 1 first hit
Listato 1.3. Tipico formato di un log di firewall per l’evento con codice 106100
In tutti i log analizzati i primi tre campi rappresenteranno sempre:
1.4 I log di accesso al firewall
•
•
•
17
Oct 25 00:05:50 : data ed ora del momento in cui il server dei log registra un
evento del firewall;
192.168.33.3 : l’indirizzo IP del firewall;
Oct 25 2016 00:00:24 : data ed ora di un evento generato dal firewall.
Ogni evento ha un determinato codice identificativo. In questo caso il codice
identificativo è 106100, ma nei log analizzati sono presenti anche eventi con i codici
302013 e 302014.
L’evento con codice 106100 contiene le informazioni mostrate nel Listato 1.4:
Error Message %PIX|ASA-6-106100: access-list acl_ID {permitted | denied | est-allowed} protocol
interface_name/source_address(source_port) -> interface_name/dest_address(dest_port)
hit-cnt number ({first hit | number-second interval})
Listato 1.4. Informazioni contenute nel log per l’evento con codice 106100
Questo messaggio è generato ogni volta che un pacchetto non corrisponde ad
una connessione esistente. Di seguito sono elencati i valori dei diversi campi:
•
•
•
•
•
•
•
•
•
•
i valori “permitted|denied|est-allowed”specificano se l’accesso al pacchetto è stato consentito o negato dall’ Access Control List (ACL); quest’ultimo è un meccanismo usato, appunto, per consentire o negare l’accesso alle risorse di un sistema
informatico da parte dei suoi utenti:
1. se il valore è “permitted”, viene consentito l’accesso al pacchetto che proviene
dall’esterno;
2. se il valore è “denied”, viene negato l’accesso al pacchetto che proviene
dall’esterno;
3. se il valore è “est-allowed”, l’accesso al pacchetto viene negato dall’ACL ma
è consentito per una sessione già stabilita. Vengono, praticamente, accettati
i pacchetti che normalmente l’ACL avrebbe negato.
protocollo: TCP, UDP, ICMP o un numero di protocollo IP.
interface name: il nome dell’interfaccia per la sorgente o la destinazione del
flusso. Le interfacce VLAN sono supportate.
source address: indirizzo IP della sorgente del flusso a cui il log si riferisce.
dest address: indirizzo IP di destinazione del flusso a cui il log si riferisce.
source port: la porta sorgente del flusso a cui il log si riferisce (TCP o UDP).
Questo campo è 0 per ICMP.
dest port: la porta di destinazione del flusso a cui il log si riferisce (TCP o UDP).
Per ICMP, questo campo è src addr.
hit–cnt number : numero delle volte che questo flusso è stato permesso o negato dall’ACL nell’intervallo di tempo configurato. Questo valore è 1 quando
l’applicazione genera il primo messaggio di log per questo flusso.
first hit: primo messaggio generato per questo flusso.
number-second interval : intervallo in cui è accumulato l’hit count.
Consideriamo, ora, l’evento con codice 302013, mostrato nel listato 1.5:
Oct 25 00:05:59 192.168.33.3 Oct 25 2016 00:00:25: %ASA-6-302013: Built inbound TCP connection 543841630
for outside:79.185.235.72/20525 (79.185.235.72/20525) to inside:193.204.246.184/2323 (193.204.246.184/2323)
18
1 Lo scenario di riferimento
Listato 1.5. Tipico formato di un log per l’evento con codice 302013
Questo evento contiene le informazioni mostrate nel Listato 1.6:
Error Message %PIX|ASA-6-302013: Built {inbound|outbound} TCP connection_id for
interface:real-address/real-port (mapped-address/mapped-port)
to interface:real-address/real-port (mapped-address/mapped-port) [(user)]
Listato 1.6. Informazioni contenute nel log per l’evento con codice 302013
Questo messaggio indica che è stata creata una connessione TCP tra due host.
Di seguito c’è una lista che descrive i campi del log:
•
•
•
•
connection id: identificatore univoco;
interface, real–address, real–port: identificano un socket reale;
mapped–address, mapped–port: identificano un socket “mappato”;
user: nome dell’utente.
Se viene specificato inbound, la connessione di controllo originale è avviata dall’esterno. Se viene specificato outbound, la connessione di controllo originale è stata
avviata dall’interno.
Infine, l’ultimo evento che consideriamo è quello che ha codice 302014, mostrato
nel Listato 1.7:
Oct 25 00:05:59 192.168.33.3 Oct 25 2016 00:00:24: %ASA-6-302014: Teardown TCP
connection 543838080 for outside:94.249.127.41/29596
to inside:193.204.243.247/2323 duration 0:00:30 bytes 0 SYN Timeout
Listato 1.7. Tipico formato di un log di firewall per l’evento con codice 302014
Tale evento contiene le informazioni, mostrate nel Listato 1.8:
Error Message %PIX|ASA-6-302014: Teardown TCP connection id for
interface:real-address/real-port to interface:real-address/real-port duration hh:mm:ss bytes bytes [reason] [(user)]
Listato 1.8. Informazioni contenute nel log per l’evento con codice 302014
Questo messaggio indica che è stata interrotta una connessione TCP tra due
host. Di seguito sono elencati i valori del messaggio:
•
•
•
•
•
•
connection id : identificatore univoco;
interface, real–address, real–port: identificano le porte reali;
duration: durata della connessione;
bytes: trasferimento dati della connessione;
reason: rappresenta l’azione che causa l’abbattimento della connessione;
user : nome dell’utente.
2
Strumenti software utilizzati
In questo capitolo verrà presentato il software utilizzato, nel lavoro di tesi, per l’analisi dei file di log, ovvero Splunk. Prima di ciò, però, si parlerà dei software di
“Security Information and Event Management”e si discuterà sull’importanza della
gestione dei file di log e sui vantaggi che scaturiscono da quest’ultima. Successivamente verrà fatta una breve panoramica sulle app e sugli add-on di Splunk. Ed
infine verrà spiegata la tecnologia Docker, illustrando i vantaggi di utilizzo rispetto
alle macchine virtuali.
2.1 I software di Security Information and Event
Management
I software di Security Information and Event Management (SIEM) definiscono un
prodotto, costituito da software e servizi, che unisce capacità di “Security Information Management”(SIM) con quelle di “Security Event Management”(SEM):
•
•
un SIM si occupa della parte di “Log management”, di attività di analisi e della
produzione di report;
un SEM si occupa del monitoraggio in real-time degli eventi, dell’incident management (in ambito security) per quanto riguarda eventi che accadono sulla rete,
sui dispositivi di sicurezza, sui sistemi o nelle applicazioni.
In sostanza, un SIEM mira a risolvere esigenze in ambito di gestione delle minacce informatiche ed in ambito regolatorio o di compliance. La spinta a rispondere ad
esigenze regolatorie ha agevolato l’introduzione dei SIEM nelle aziende, che li hanno,
cosı̀, potuti sfruttare anche per gli scopi di security e rilevazione delle violazioni.
Un SIEM è uno degli strumenti fondamentali per un approccio alla difesa in
profondità, a beneficio della sicurezza delle aziende.
Numerose aziende e agenzie governative hanno subı̀to attacchi informatici, progettati in modo da sfrutare le vulnerabilità e sottrarre importanti informazioni. È
fondamentale arrestare o rilevare un attacco in corso, nelle reti delle vittime, prima
che il danno venga arrecato.
I team della sicurezza si sono resi conto che sono necessarie nuove procedure,
basate sul monitoraggio continuo delle minacce e sul rilevamento e la risoluzione
20
2 Strumenti software utilizzati
rapidi degli attacchi. Per poter conoscere tutto quello che avviene negli ambienti IT,
è necessario fondere più sorgenti di dati, tra cui i pacchetti di rete e la ricostruzione
completa delle sessioni, i file di log provenienti dalla rete e dai dispositivi host e
informazioni esterne.
I sistemi SIEM sono stati progettati per offrire una posizione centrale in cui
raccogliere e memorizzare i dati relativi alla sicurezza (in gran parte informazioni
dei registri e degli eventi), in modo da semplificare l’Incident Management per la
sicurezza e la generazione di report sulla conformità. Tali sistemi raccolgono i log
e gli alert sulla sicurezza, generati da applicazioni e sistemi in rete, ad esempio
firewall e dispositivi di rete. Le tecnologie SIEM aggregano, dunque, i dati corrispondenti agli eventi prodotti da dispositivi di sicurezza, ad esempio del firewall,
dalle infrastrutture di rete, da sistemi ed applicazioni.
I SIEM devono rispondere all’esigenza, che è sorta nel corso degli anni, di applicare in maniera sistematica un’analisi computazionale di dati o statistiche inerenti
alla sicurezza informatica. Quest’analisi deve avvenire in tempo reale, in modo da
rilevare in maniera tempestiva attacchi mirati e violazioni dei dati.
Un’altra necessità che i SIEM devono soddisfare è quella di raccogliere, memorizzare, analizzare e rendere disponibile in forma di report i dati provenienti dai log,
per esigenze di incident response, di compliance in ambito regolatorio o per attività
di analisi forense. La fonte principale dei dati che vengono analizzati da un SIEM
sono i log. Tuttavia, un SIEM non si limita a questo, in quanto potrebbe essere in
grado di elaborare dati sotto altre forme, quali flussi Netflow o, addirittura, il vero
e proprio traffico di rete. I dati “grezzi”devono, poi, essere contestualizzati, ed in
questo senso il SIEM deve essere in grado, dopo una fase di normalizzazione dei dati
stessi, di correlare gli eventi provenienti dalle fonti più disparate. La correlazione è
l’arma fondamentale per chi si trova a gestire migliaia di eventi ed incidenti di sicurezza. Correlazione degli eventi significa trovare relazioni tra eventi apparentemente
non correlati in dati provenienti da più fonti. La possibilità di effettuare query, di
monitorare l’attività degli utenti e delle applicazioni, di effettuare report a scopo di
audit o di compliance rappresenta, poi, un ulteriore insieme di tasselli fondamentali
che compongono un’efficace soluzione SIEM.
Le regole di correlazione possono servire ad individuare possibili attacchi di tipo
brute force, minacce dovute ad attacchi provenienti dall’interno (malicious insider,
ovvero utenti interni all’organizzazione con intenti malevoli), oppure a tracciare
sistemi infetti o compromessi da malware, tramite l’analisi e l’incrocio dei dati
provenienti dai log del traffico in uscita dal firewall, dai log del Web Proxy e dai
flussi di rete interni.
L’elaborazione di eventi complessi e i log del sistema di gestione dei processi aziendali sono veri patrimoni aziendali; infatti, possono essere utilizzati per
implementare il monitoraggio completo delle attività delle aziende.
Sistemi operativi, database, web server e alcuni tipi di programmi applicativi
producono, durante il loro funzionamento, file di log nei quali tengono traccia di
attività quotidiane. La gestione dei log è lo strumento tipico per monitorare il
comportamento dei sistemi. L’elaborazione ed analisi dei file di log permette di
produrre tracciati di dati utilizzabili da altre componenti applicative. Analizzando
un file di log si possono diagnosticare problemi, determinare schemi di utilizzo e
ottimizzare i sistemi per ottenere prestazioni ottimali. Questi file sono cruciali per
2.2 Splunk
21
il debug quotidiano delle applicazioni da parte degli sviluppatori e per l’assistenza
delle applicazioni e dei sistemi informatici. Inoltre, spesso, rappresentano il modo
migliore per creare report su attività delle aziende e degli utenti e per rilevare frodi,
visto che contengono tutti i dettagli delle transazioni.
I file di log sono dei semplici file di testo strutturati e, se da una parte è vero che la quantità e la qualità delle informazioni che essi racchiudono è notevole,
dall’altra è anche vero che tali informazioni non sono sempre di facile lettura o reperibilità. Questo è ciò che riguarda la singola macchina; proviamo, ora, a pensare cosa
vorrebbe dire consultare manualmente i log su una decina di macchine differenti.
Un’operazione di certo non agevole.
Gli analizzatori dei file di log sono programmi o software che distillano informazioni utili a partire dal contenuto del file. Esistono in circolazione una moltitudine di
log analyzer, ovvero programmi, gratuiti o a pagamento, che permettono di raccogliere, processare e analizzare i log, riassumendo, attraverso tabelle, schemi, grafici
e statistiche, i corrispettivi dati. Attualmente, uno dei modi migliori per consultare
ed aggregare grandi volumi di log è affidarsi a Splunk.
2.2 Splunk
Il software che è stato utilizzato in questo lavoro di tesi per analizzare i file di log è
Splunk. Splunk, il cui logo è mostrato in Figura 2.1, fornisce la piattaforma leader
per l’Operational Intelligence, in quanto trasforma i dati macchina in informazioni
significative.
Figura 2.1. Logo di Splunk
Questo software ha rivoluzionato l’approccio delle aziende alla gestione dei dati
macchina. È uno strumento aziendale utilizzato da molte multinazionali.
Vi è una crescita enorme della quantità di dati, generati nel mondo: la maggior
parte dei sistemi moderni generano moltissimi dati di log e anche molto diversi
tra loro. Le infrastrutture IT, i siti Web e le reti di comunicazione generano flussi
imponenti di dati macchina ogni secondo di ogni giorno, in una serie di formati
imprevedibili, che sono difficili da elaborare e da analizzare con i metodi tradizionali
e in tempo reale. L’analisi dei dati, la gestione e i metodi di monitoraggio tradizionali
non sono progettati per grandi volumi di dati, estremamente diversi tra loro.
La potenza di Splunk sta nel fatto che esso fornisce una visibilità unica in tutta l’infrastruttura IT e garantisce scalabilità e sicurezza. La missione di Splunk è
rendere accessibili i dati macchina in un’organizzazione, fornendo la diagnosi dei
22
2 Strumenti software utilizzati
problemi. Splunk è una tecnologia orizzontale, utilizzata per la gestione delle applicazioni, per la sicurezza e per la compliance, nonchè per business e web analytics. È
un software per la ricerca, il monitoraggio e l’analisi di grandi quantità di dati, generati dalle macchine, tramite un’interfaccia web. I server Splunk possono comunicare
tra loro tramite Splunk-2-Splunk, un protocollo basato su TCP per inoltrare i dati
da un server ad un altro e per distribuire le ricerche su più server. L’architettura di
Splunk, mostrata in Figura 2.2, basata su MapReduce, è scalabile e comprende dei
componenti che sono responsabili dell’aggiunta, dell’indicizzazione e dell’analisi dei
dati.
Figura 2.2. Architettura di Splunk
Imprese, fornitori di servizi ed enti pubblici utilizzano Splunk per migliorare i
livelli di servizio, ridurre i costi di esercizio dell’IT, mitigare i rischi per la sicurezza,
creare nuovi prodotti e servizi.
Splunk consente di vedere da vicino i dati macchina, spesso ignorati, e di trovare
informazioni che possono rendere l’azienda più produttiva, redditizia, competitiva
e sicura. I dati generati dalle macchine contengono informazioni molto importanti
sul comportamento delle macchine, su tutte le transazioni degli utenti, sui rischi e
sulle minacce per la sicurezza, sul consumo della capacità, sui livelli di servizio, sulle
attività fraudolente, sull’esperienza dei clienti, e altro ancora. Ora, grazie a Splunk,
i dati raccolti possono diventare un vero valore per l’azienda.
Splunk è un software che dà la possibilità di collezionare, indicizzare e controllare
i dati IT generati dinamicamente da tutte le applicazioni, i dispositivi e i server,
siano essi fisici, virtuali o nel cloud.
L’applicazione è sviluppata in C/C++ and Python ed è basata su un motore
di ricerca che permette di selezionare, aggregare e visualizzare, in tempo reale, i
dati con report altamente personalizzabili. Il risultato concreto è un incremento
nell’efficacia di gestione della rete grazie alla possibilità di identificare rapidamente
le modalità di risoluzione dei problemi.
2.2 Splunk
23
Splunk è un motore di ricerca e di analisi potente e versatile che permette di
indagare, risolvere i problemi e monitorare tutto ciò che accade nella rete in tempo
reale. Fare troubleshooting, gestire la sicurezza, analizzare il comportamento degli
utenti, delle applicazioni o dei sistemi, cercare e analizzare tutti i dati storici, in
tempo reale e con un unico strumento è ora un’attività facile e immediata.
Questo software permette di capire in tempo reale cosa sta succedendo nei sistemi
IT, in modo tale da prendere le giuste decisioni. I file di log, una volta acquisiti,
vengono indicizzati, trasferiti su un repository e certificati, aggiungendo al file il
riferimento temporale, qualora non fosse presente, cosı̀ da renderli inalterabili.
Splunk permette di:
•
•
•
Raccogliere i dati macchina in tempo reale da applicazioni, server web, database,
reti, macchine virtuali, dispositivi mobili, sensori IoT, mainframe, e molto altro
ancora.
Archiviare, indicizzare, ricercare, correlare, visualizzare, analizzare e creare report su qualunque dato generato da macchine, al fine di individuare e risolvere
problemi operativi e di sicurezza in modo veloce e ripetibile. Splunk supporta
l’individuazione di eventi utilizzando tempo e ubicazione geografica, transazioni,
sottoricerche, ricerche con campi e join.
Combinare e arricchire i dati macchina con dati basati su Hadoop, nonchè con
dati tradizionali provenienti da database relazionali e data warehouse.
Splunk mette a disposizione diverse funzionalità e, pertanto, viene usato da divesi utenti: gli amministratori di sistema lo usano per ottenere rapidamente risultati
migliori, gli analisti di sicurezza lo utilizzano per indagare sull’attività degli utenti
e sugli accessi a dati sensibili, per monitorare gli eventi anomali e per trovare, tramite correlazioni, pattern di rischio, come attacchi di forza bruta e perdita di dati,
mentre i manager lo usano per creare report e dashboard, al fine di monitorare le
performance e l’attività delle infrastrutture IT.
Splunk indicizza in tempo reale dati IT di qualsiasi tipo da qualsiasi origine,
senza la necessità di scrivere parser. Sia i dati non elaborati che quelli elaborati
vengono archiviati in un datastore compresso ad alta efficienza basato su un file
system, con la possibilità di firmare ed eseguire l’audit dei dati, per assicurarne
l’integrità. Il cuore di Splunk è un modello di sicurezza estremamente robusto ed
efficace. I dati macchina devono essere sempre al sicuro, perchè rappresentano una
risorsa preziosa. Pertanto Splunk offre una gestione protetta dei dati, controlli dell’accesso, verificabilità, garanzia dell’integrità dei dati e integrazione con le soluzioni
di single sign-on aziendali. La cifratura con hashing garantisce l’integrità dei dati
indicizzati nel tempo. Splunk, quindi, dà la certezza che i dati non verranno manomessi. Ogni transazione di Splunk viene autenticata, incluse le attività di sistema,
le attività utente attraverso il web e da linea di comando.
Installarlo è molto semplice: soltanto dopo essersi registrati sul sito di Splunk,
sarà possibile scaricare la versione corretta per il proprio sistema operativo, come
viene mostrato nella Figura 2.3.
Splunk è un pacchetto software autonomo eseguibile su tutti i principali sistemi
operativi. Basta scegliere la piattaforma adeguata, e, successivamente, scaricarlo e
installarlo. Al termine dell’installazione bisognerà effettuare il login, come mostrato
24
2 Strumenti software utilizzati
Figura 2.3. Installazione di Splunk sui principali sistemi operativi
in Figura 2.4; successivamente, si otterrà un’interfaccia web per gli utenti, come si
vede nella Figura 2.5.
Figura 2.4. Pagina del login di Splunk
È, poi, necessario selezionare il file che si vuole caricare in Splunk, come ci mostra
la Figura 2.6, considerando che la dimesnione di caricamento massima per i file è
di 500 MB.
Grazie ad un’ampia gamma di metodi di input standard e personalizzati, Splunk
è in grado di recepire tutti i tipi di dati e di fonti. I dati basati su file possono essere
inviati tramite forwarder che risiedono direttamente nelle fonti di dati, mentre i
2.2 Splunk
25
Figura 2.5. Pagina iniziale dell’nterfaccia web di Splunk
Figura 2.6. Aggiunta dei dati
dati DevOps, IoT e di altri tipi possono essere acquisiti utilizzando l’API Event
Collector o una porta TCP/UDP.
Come mostrato nella Figura 2.7, i dati inseribili all’interno di questo software
possono essere file CSV, file singoli, cartelle singole; in alternativa, i dati possono
essere passati tramite una porta TCP o UDP. L’opzione “Script”dà la possibilità
di inserire dei codici che generano o raccolgono dei dati, che poi vengono passati a
splunk per essere elaborati. Splunk, permette, anche di distinguere tra file locali e
file inoltrati.
Come mostra la Figura 2.8, i dati possono essere aggiunti da diverse source,
inclusi stream di rete, log di eventi e script.
Se i dati hanno un formato log personalizzato, è possibile creare un nuovo source type e configurare manualmente le suddivisioni in eventi e il riconoscimento del
timestamp. I dati vengono acquisiti in tempo reale; quindi, l’estrazione e la normalizzazione dei timestamp sono obbligatorie per individuare e risolvere eventuali
problemi (che cosa non ha funzionato e quando), per le indagini e per comprendere
il flusso end-to-end delle transazioni.
Splunk determina automaticamente l’ora di ogni evento, persino in presenza dei
formati più atipici o non tradizionali. I dati che non hanno un timestamp vengono
26
2 Strumenti software utilizzati
Figura 2.7. Input di Splunk
Figura 2.8. Aggiunta dei dati da diverse source
gestiti deducendo quest’ultimo sulla base del contesto. I source type controllano le
modalità con cui il software formatta i dati in eventi, prima di iniziare la ricerca, è
consigliabile scegliere il source type e anche l’indice nel quale archiviare i dati, come
ci mostra la Figura 2.9.
Splunk consente, inoltre, di eseguire l’anteprima dei dati, come si può vedere in
Figura 2.10, per verificare che gli eventi siano stati formattati correttamente.
Una volta che i file sono stati correttamente caricati in Splunk, è possibile, come
mostrato in Figura 2.11, avviare la ricerca, estrarre i campi, aggiungere altri dati,
scaricare un’app, oppure creare una dashboard.
La barra laterale dell’interfccia di Splunk mostra i campi che la ricerca ha estratto automaticamente dagli eventi, come mostrato in Figura 2.12; Splunk, comunque,
dà la possibilità di estrarre ulteriori campi, usando la funzione “Estrattore di campi”, per individuare qualunque valore in un’ingente quantità di dati, trovando “l’ago
nel pagliaio”rapidamente, anzichè in ore o giorni.
La ricerca può contenere parole, coppie campo=valore, caratteri jolly (*) e operatori booleani quali AND, OR e NOT. È, inoltre, possibile evidenziare una parte
di un log e cliccare per incluerlo o escluderlo dalla ricerca, come mostrato in Figura
2.13.
Splunk è flessibile, ricco di funzionalità e ben documentato. Una documenta-
2.2 Splunk
Figura 2.9. Impostazioni di input
Figura 2.10. Anteprima dei dati
Figura 2.11. File caricato correttamente
27
28
2 Strumenti software utilizzati
Figura 2.12. Campi estratti automaticamente
Figura 2.13. Inclusione di una parte di log nella ricerca
zione molto buona può essere trovata sul sito di Splunk, come mostrato in Figura
2.14; Splunk possiede, inoltre, una comunità di utenti ben disposta a fornire supporto. L’assistenza di Splunk è strutturata, vicina agli utenti, efficiente, competente,
affidabie e rapida.
Figura 2.14. Documentazione fornita da Splunk
2.3 Utilizzo di Splunk per l’analisi dei log
29
L’assistente di ricerca offre suggerimenti con completamenti automatici e una
guida, come si può vedere in Figura 2.15, in modo da poter utilizzare tutta l’efficacia
del linguaggio Search Processing Language (SPL).
Figura 2.15. Assistente di ricerca
SPL è un potente linguaggio di query che consente di gestire i dati macchina.
Con il supporto per cinque diversi tipi di correlazione (tempo, transazioni, sottoricerche, ricerche, join) e oltre 140 comandi analitici, dà la possibilità di eseguire
analisi approfondite, utilizzare la rilevazione dei pattern degli eventi e altri metodi di
machine learning per prevedere i risultati e, addirittura, scoprire nuove opportunità
nei dati.
Poichè i dati vengono sempre conservati in formato grezzo, non sono necessari
costosi processi di ETL o di normalizzazione dei dati e non è necessario ricreare uno
schema quando si aggiungono nuovi dati o si eseguono nuove ricerche.
2.3 Utilizzo di Splunk per l’analisi dei log
Splunk Enterprise è uno dei migliori strumenti software per la gestione dei log,
tramite un’interfaccia semplice e intuitiva da utilizzare. È una soluzione totalmente
integrata e orientata alle imprese per la raccolta, l’archiviazione e la visualizzazione
di log.
Splunk Enterprise si basa su un’architettura distribuita che scala orizzontalmente sui server ordinari per supportare un numero elevato di utenti e quantità enormi
di dati e, verticalmente, per incrementare la velocità di ricerca e indicizzazione e la
capacità di usufruire della potenza della CPU disponibile.
Il software permette una gestione dei log per una corretta storicizzazione e visualizzazione degli stessi e consente un reperimento veloce delle informazioni, grazie
ad una grafica user-friendly. Esso permette di:
30
•
2 Strumenti software utilizzati
Collezionare, ricercare, indicizzare, archiviare e filtrare centralmente qualunque
tipo e numero di log e dati macchina, come si vede in Figura 2.16, a prescindere
dal formato o dalla posizione: log di sicurezza delle reti e degli endpoint, informazioni sull’analisi dei malware, dati trasmessi dalle reti. I log possono essere
indicizzati da qualsiasi sorgente, formato o posizione.
Figura 2.16. Dati indicizzati da Splunk
•
Eseguire ricerche, indagini, incroci su più fonti di dati, correlazioni di eventi,
tramite più sorgenti di dati, al fine di ottenere informazioni dettagliate e correlazioni dei dati sulla base della data, dell’orario e della posizione. I risultati della
ricerca possono essere visualizzati in una timeline, come si vede in Figura 2.17;
successivamente la ricerca può essere salavata come report, allarme o pannello
dashboard, come mostrato in Figura 2.18.
Figura 2.17. Interfaccia per la ricerca in Splunk Enterprice
La Figura 2.19 mostra che è possibile condividere con altri i risultati della ricerca,
mediante i pannelli dashboard.
2.3 Utilizzo di Splunk per l’analisi dei log
31
Figura 2.18. Modalità di salvataggio delle ricerche
Figura 2.19. Condivisione dei risultati della ricerca
•
•
Creare report, dashboard, grafici e diagrammi, per comprendere tendenze e visualizzare l’andamento dei dati in tempo reale. Splunk mette a disposizione
un’ampia gamma di grafici e visualizzazioni per rendere i risultati più comprensibili e facili da usare. I grafici intuitivi e le visualizzazioni interattive, di
cui vediamo un esempio in Figura 2.20, semplificano la comprensione dei dati
complessi e consentono di identificare i potenziali problemi. È possibile eseguire
query e creare report ad hoc sui dati storici, senza necessità di software di terzi
per la creazione dei report.
Le Figure 2.21 e 2.22 mostrano, rispettivamente, che una dashboard può essere esportata in formato PDF e può, anche, essere inviata via email; inoltre, è
possibile selezionare diverse visualizzazioni dei dati, ad esempio come grafico a
torta o a barre, ed è possibile personalizzare l’aspetto della visualizzazione.
Analizzare velocemente tutti i dati tramite il drilldown, come si può vedere in
Figura 2.23, per indivifuare tendenze, picchi e anomalie. Ciò permette di andare
oltre le semplici ricerche booleane, di utilizzare ricerche con campi, ricerche statistiche, sottoricerche, di correlare gli elementi e di visualizzare immediatamente
32
2 Strumenti software utilizzati
Figura 2.20. Esempio di grafico in Splunk
Figura 2.21. Esportazione di dashboard in formato PDF
Figura 2.22. Personalizzazione delle visualizzazioni
2.4 App di Splunk
33
i risultati e i pattern.
Figura 2.23. Interfaccia dell’analisi Drilldown
•
Monitorare e trasformare le ricerche in allarmi in tempo reale e inviare le notifiche tramite email. Gli allarmi possono essere impostati su un livello qualsiasi di
granularità e possono essere basati su svariate soglie. Al momento dell’allarme
si analizza il problema al fine di eseguire azioni di contenimento e ripristino e
per trovare una soluzione in tempi brevi. Gli allarmi possono segnalare gli eventi
critici in tempo reale ed evitare determinate condizioni prima che si verifichino.
Splunk permette di scegliere se elaborare i log:
•
•
in tempo reale e in modo continuo; nel caso di un sito attivo che produce traffico,
è conveniente che Splunk vada a prendere i dati di continuo;
una sola volta, perchè i dati non cambiano mai nel corso del tempo.
Un’altra importantissima funzionalità di Splunk, mostrata in Figura 2.24, è la
possibilità di scegliere l’intervallo temporale in cui effettuare le analisi; alcune possibilità sono: intervallo di date, intervallo di date e ore, settimana, mese o anno
precedente, da inizio anno o mese fino ad oggi, ultimi 30 giorni. Impostare un intervallo temporale minore è utile, per esempio, per accelerare la ricerca e limitare
il numero di risultati.
Splunk supporta l’arricchimento dei dati di log grazie all’accesso flessibile a
database relazionali. Consente di estrarre i dati dalle fonti basate su API utilizzando
input modulari e altri metodi, nonchè di eseguire l’onboarding e l’analisi delle fonti
di dati più diffuse per IT, sicurezza e applicazioni, direttamente con centinaia di
app e componenti aggiuntivi (add-on) gratuiti.
2.4 App di Splunk
Splunk offre centinaia di app e componenti aggiuntivi (add-on) che migliorano ed
estendono le funzionalità della piattaforma, grazie a funzioni pronte all’uso, quali
34
2 Strumenti software utilizzati
Figura 2.24. Intervallo temporale di analisi
la raccolta di dati ottimizzata o il monitoraggio della sicurezza, la gestione IT, e
molto altro ancora.
Le app rappresentano il fondamento del valore di Splunk; esse offrono un’esperienza utente progettata per rendere Splunk immediatamente utile e pertinente per
le attività più comuni, come il monitoraggio e la generazione di report per esigenze
specifiche di IT e sicurezza, semplificando il processo di aggiunta e visualizzazione
dei dati.
Le app semplificano e ottimizzano le attività degli utenti ma, allo stesso tempo,
consentono l’accesso ai dati e alle funzioni della piattaforma completa. Solitamente
i componenti aggiuntivi (add-on) importano e integrano i dati da qualsiasi fonte,
creando un insieme di dati ricco, pronto per l’analisi diretta o per l’uso in un’app.
Esse possono, anche, essere usate per estendere la piattaforma Splunk in modo che
soddisfi esigenze specifiche.
Splunk, in collaborazione con i partner e la community, non solo mette a disposizione centinaia di app gratuite, che possono essere installate con un semplice click
direttamente dall’interfaccia web, come si può notare nella Figura 2.25, ma anche
una piattaforma con cui è possibile crearle facilmente.
Un’app molto interessante di Splunk, usata anche in questo lavoro di tesi, è Machine Learning Toolkit, la cui interfaccia è mostrata in Figura 2.26. Essa consente
di applicare una varietà di tecniche e metodi di machine learning, come la classificazione, la regressione, la rivelazione di anomalie e rilevamento di outlier. Essa dà
la possibilità di prevedere il valore di un campo numerico, al fine di individuare le
anomalie; le previsioni che si discostano notevolmente dal valore effettivo possono
essere considerate anomale. L’app consente di trovare i valori che differiscono in
modo significativo da quelli precedenti e gli eventi che contengono combinazioni
insolite di valori. In tal modo, un analista di sicurezza, analizzado il traffico di un
firewall, potrebbe, per esempio, prevedere la presenza di un malware.
2.4 App di Splunk
35
Figura 2.25. Ricerca app in splunk
Figura 2.26. App Machine Learning Toolkit
Invece, un add-on di Splunk è, per esempio, Google Maps for Splunk Enterprise.
Esso aggiunge un modulo di geo-visualizzazione basato sulle API di Google Maps,
e permette di tracciare rapidamente informazioni geografiche su una mappa, come
mostrato nella Figura 2.27. Le informazioni sulla posizione devono essere inserite
in un campo nominato “ geo ”. Nella maggior parte dei casi non si deve costruire
il campo “ geo”da soli, perchè i metodi di geolocalizzazione forniscono questo campo per impostazione predefinita. I valori degli indirizzi IP esterni possono essere
facilmente tradotti in luoghi utilizzando il comando geoip incorporato.
36
2 Strumenti software utilizzati
Figura 2.27. Risultato della ricerca lanciata in Google Maps for Splunk
2.5 Docker
Splunk è stato installato utilizzando Docker, che è una tecnologia open source
che permette di creare, eseguire, testare e distribuire le applicazioni in contenitori
software, in modo rapido, affidabile e coerente, indipendentemente dall’ambiente.
Consente di creare pacchetti software in un’unità standard per lo sviluppo, contenenti tutto il necessario per l’esecuzione: codice, runtime, strumenti di sistema,
librerie di sistema, e cosı̀ via.
Lo scopo di Docker è quello di rendere più facile la creazione, il deploy e l’esecuzione di applicazioni utilizzando i container. Questi ultimi consentono allo sviluppatore di “pacchettizzare”un’applicazione con tutte le parti necessarie (le librerie e
altre risorse correlate) e di consegnarla come un unico pacchetto.
Il team di Docker ha sviluppato un formato di “contenierizzazione”interoperabile,
capace di “pacchettizzare”le applicazioni ed effettuarne il deploy in qualsiasi ambiente di esecuzione, senza doversi preoccupare delle condizioni di eseguibilità.
In questo modo, grazie al container, lo sviluppatore è certo del fatto che l’applicazione stessa girerà su qualsiasi macchina Linux indipendentemente da qualsiasi
customizzazione dei setting di quella stessa macchina, setting per i quali quella macchina potrebbe differire da quella che è stata usata per scrivere l’applicazione o per
testarne il codice.
Da un certo punto di vista, quindi, non siamo lontani da una virtual machine.
Ma, al contrario di quest’ultima, invece di creare un intero sistema operativo virtuale, Docker consente alle applicazioni di usare lo stesso kernel Linux del sistema su
cui stanno girando e richiede soltanto che le applicazioni vengano consegnate senza
elementi che risiedano già sulla macchina che le ospita. Questo comporta un deciso
aumento di prestazioni e riduce l’ingombro dell’applicazione.
Docker conferisce un maggior tasso di sicurezza alle applicazioni che girano in un
ambiente condiviso, però, i container non sono di per se un’alternativa alle misure
appropriate di sicurezza.
Inoltre, essendo open source, chiunque può contribuire a Docker ed estenderlo
per coprire esigenze e bisogni aggiuntivi non ancora implementati.
Docker è un tool progettato per fornire vantaggi sia agli sviluppatori sia agli
amministratori di sistema; in particolare:
2.5 Docker
•
•
37
permette agli sviluppatori di scrivere il codice senza doversi preoccupare del
sistema su cui andrà a girare.
il campo Operations ottiene da Docker maggiore flessibilità.
Parlando di Docker e, più in generale, di “contenierizzazione”, le curiosità a
cui si deve fare fronte sono molte: perchè virtualizzare un’intera macchina, quando
sarebbe possibile virtualizzare soltanto una piccola parte di essa?
Questa idea ha condotto gli sviluppatori a trovare delle strade alternative alla
virtualizzazione completa. La “contenierizzazione”può essere considerata figlia della
virtualizzazione, da cui si evolve in una nuova generazione che introduce delle migliorie di non poco conto. Rispetto a un’intera macchina virtualizzata, un container
è capace di offrire:
•
•
•
Un deployment semplificato: impacchettando un’applicazione in un singolo componente distribuibile e configurabile con una sola linea di comando, la tecnologia a container permette di semplificare il deployment di qualsiasi applicazione,
senza doversi preoccupare della configurazione dell’ambiente di runtime.
Una disponibilità rapida: virtualizzando solo il sistema operativo e le componenti
necessarie all’esecuzione dell’applicazione, invece che l’intera macchina, l’intero
package si avvia in un ventesimo di secondo, rispetto ai tempi di avvio di una
macchina virtuale.
Un controllo più granulare: i container consentono agli operatori e agli sviluppatori di suddividere ulteriormente le risorse computazionali in microservizi,
garantendo, cosı̀, un controllo superiore sull’eseguibilità delle applicazioni e un
miglioramento delle prestazioni dell’intero sistema.
La tecnologia dei container ha i seguenti vantaggi indiscutibili:
•
•
•
•
•
L’opportunità, per gli sviluppatori, di possedere una miriade di container anche
sul proprio PC o laptop, per avere sempre a portata di mano un ambiente di
deploy o test adatto a ciascuna applicazione in sviluppo. Per quanto sia possibile
eseguire anche su un laptop diverse virtual machine, questa operazione non è
mai veloce e semplice e impatta non poco sulle prestazioni esecutive.
Distribuzione più rapida di software: gli utenti di Docker, in media, distribuiscono software con una frequenza sette volte maggiore rispetto a chi non utilizza
Docker. La distribuzione delle applicazioni è accelerata grazie alla creazione di
ambienti standard e all’eliminazione dei conflitti tra versioni e stack di linguaggi.
Docker consente agli sviluppatori di distribuire servizi isolati ogni volta che è
necessario, senza preoccuparsi delle complesse dipendenze software. L’amministrazione dei cicli di rilascio delle applicazioni è semplificata, in quanto distribuire una nuova versione di un container richiede il tempo speso per digitare in
console una singola linea di comando.
Facilità di spostamento delle applicazioni.
Maggiore produttività per gli sviluppatori : Docker riduce il tempo necessario per
configurare nuovi ambienti o risolvere i problemi legati alle differenze tra essi.
Le attività di testing traggono un beneficio economico da un ambiente “contenierizzato”. Se si effettua il test di un’app direttamente su un cloud server in un
ambiente di cloud computing pubblico, sarà necessario sostenere i costi relativi
alla frazione di ora o all’ora intera di occupazione delle risorse computazionali.
38
•
•
2 Strumenti software utilizzati
Questo costo aumenta all’aumentare del numero di test che devono essere eseguiti. Con un container è possibile effettuare una serie di semplici test giornalieri
programmati, mantenendo costante il costo, in quanto si userebbero sempre le
stesse risorse di calcolo.
Standardizzazione delle operazioni delle applicazioni : l’uso di contenitori per le
piccole applicazioni semplifica la distribuzione, l’identificazione dei problemi e il
rollback quando necessario.
Componibilità dei sistemi applicativi : invece di obbligare gli sviluppatori a installare e configurare i servizi MySQL, memcached, MongoDB, nginx, node.js e
via discorrendo, per avere la giusta piattaforma esecutiva per le proprie applicazioni, sarebbe meno rischioso e più veloce avviare ed eseguire con piccoli script
quei pochi container che ospitano queste stesse applicazioni.
I container sembrano garantire miglioramenti dello sviluppo delle applicazioni.
Il vantaggio più apprezzato è che, con la distribuzione delle applicazioni più veloce,
si riduce lo sforzo di distribuzione. Sul lungo periodo, il più importante vantaggio
che questa tecnologia promette è la portabilità e la consistenza di un formato che
consente l’esecuzione applicativa su diversi host. Infatti, con la standardizzazione dei
container, i workload possono essere facilmente spostati lı̀ dove vengono eseguiti in
modo più economico e veloce, evitando anche i lock-in dovuti alle peculiarità delle
piattaforme dei singoli provider. Sempre più imprese si affidano alle applicazioni
container-based, ma le sfide sono ancora tante e riguardano temi quali la sicurezza
e le competenze. Nonostante i piani di adozione dei container da parte delle aziende,
si evidenziano una serie di sfide ancora ardue:
•
•
•
•
la sicurezza e la mancanza di certificazione;
l’integrazione con strumenti e processi di sviluppo esistenti;
la gestione;
le conoscenze esistenti e le competenze.
I container rappresentano, dunque, un cambiamento significativo nello sviluppo
di applicazioni enterprise.
3
Installazione di Splunk e caricamento dei
dati da analizzare
In questo capitolo inizialmente si spiegherà come sono stati installati Docker e
Splunk. Successivamente ci si soffermerà sulle modalità di caricamento dei dati
in Splunk ed infine si spiegherà come e dove Splunk memorizza i dati.
3.1 Installazione di Docker e di Spunk
Come anticipato nel capitolo precedente, Splunk è stato installato utilizzando Docker. Per installare Docker, è necessaria una delle seguenti versioni, a 64-bit, di
Ubuntu:
•
•
•
Yakkety 16.10;
Xenial 16.04 (LTS);
Trusty 14.04 (LTS).
È possibile installare Docker in diversi modi, a seconda di quello di cui si ha
bisogno. Più specificatamente:
•
•
•
La maggior parte degli utenti utilizzano i repository di Docker, per la facilità di
installazione e di aggiornamento delle funzioni. Questo è l’approccio consigliato.
Alcuni utenti scaricano il pacchetto DEB, lo installano e gestiscono gli aggiornamenti manualmente.
Altri utenti non possono utilizzare i repository Docker ufficiali e devono fare
affidamento sulla versione di Docker che viene fornita dal loro sistema operativo;
essi, quindi, devono consultare la documentazione relativa al proprio sistema.
Questa versione di Docker, però, potrebbe non essere aggiornata.
In questo lavoro di tesi sono stati usati i repository di Docker. I comandi utilizzati
per l’installazione sono elencati nel Listato 3.1.
$ sudo apt-get install apt-transport-https \
ca-certificates
$ curl -fsSL https://yum.dockerproject.org/gpg | sudo apt-key add $ apt-key fingerprint 58118E89F3A912897C070ADBF76221572C52609D
pub
4096R/2C52609D 2015-07-14
40
3 Installazione di Splunk e caricamento dei dati da analizzare
uid
Key fingerprint = 5811 8E89 F3A9 1289 7C07 0ADB F762 2157 2C52 609D
Docker Release Tool (releasedocker) <[email protected]>
$ sudo add-apt-repository \
"deb https://apt.dockerproject.org/repo/ \
ubuntu-$(lsb_release -cs) \
main"
$ sudo apt-get update
$ sudo apt-get -y install docker-engine
Listato 3.1. Comandi usati per l’installazione di Docker
Una volta eseguiti tutti i precedenti comandi, per verificare che l’installazione
sia andata a buon fine, è necessario lanciare un ulteriore comando, mostrato nel
Listato 3.2.
$ sudo docker run hello-world
Listato 3.2. Comando per la verifica della corretta installazione di Docker
Se l’output restituito è quello mostrato nel Listato 3.3, allora l’installazione è
andata a buon fine.
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker Hub account:
https://hub.docker.com
For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/
Listato 3.3. Output che dimostra che l’installazione è avvenuta correttamente
A questo punto, dopo aver scaricato e installato Docker sul proprio sistema, per
installare Splunk, si deve aprire una shell e digitare il comando mostrato nel Listato
3.4, per estrarre dal repository un’immagine che utilizza l’ultima versione di Splunk
Enterprise.
docker pull splunk/splunk:latest
Listato 3.4. Estrazione dal repository di un’immagine che utilizza l’ultima versione di
Splunk Enterprise
Successivamente, è necessario creare un volume virtuale, tramite il comando mostrato nel Listato 3.5. Tale volume verrà, poi, utilizzato da Splunk per la
memorizzazione dei dati.
docker run --name vsplunk -v /opt/splunk/etc -v /opt/splunk/var busybox
Listato 3.5. Creazione di un volume virtuale
3.2 Caricamento dei dati in Splunk
41
Il comando mostrato nel Listato 3.6 esegue docker Splunk, indica al docker quale
volume virtuale deve essere utilizzato e quale mapping è necessario effettuare tra
porta interna al docker e porta esterna del sistema.
docker run --hostname splunk --name splunk --volumes-from=vsplunk -p 8000:8000 -d -e
"SPLUNK_START_ARGS=--accept-license" splunk/splunk:6.5.0
Listato 3.6. Esecuzione di docker Splunk
3.2 Caricamento dei dati in Splunk
Per caricare i dati in Splunk si possono usare i seguenti metodi:
•
•
•
Splunk Web;
Command Line Interface (CLI);
inputs.conf.
Per indicizzare una volta un file statico conviene usare Splunk Enterprise Web
oppure Splunk Enterprise CLI con i comandi add oneshot o spool. Per poter
utilizzare Splunk Enterprise CLI si deve accedere alla directory $SPLUNK HOME/bin/
da una shell.
L’ultima modalità per caricare in maniera automatica i file in Splunk è mettere
questi ultimi nella directory batch in input.conf. La cartella batch viene creata
durante l’installazione di Splunk e si trova in $SPLUNK HOME/var/spool/splunk. I
dati spostati in questa cartella vengono automaticamente caricati in Splunk, indicizzati ed eliminati dalla posizione in cui si trovavano, al fine di liberare spazio di
archiviazione. In tal caso, la scelta del source type e dell’indice viene effettuata in
maniera automatica da Splunk.
Il modo più semplice per aggiungere dati alla distribuzione Splunk Enterprise è
quello di utilizzare Splunk Web. Ci sono tre opzioni per immettere i dati in Splunk
Web, come mostrato nella Figura 3.1:
•
•
•
Upload : consente di caricare un file o un archivio di file per l’indicizzazione.
Quando si clicca su “Upload”, Splunk Web avvia il processo di caricamento.
Monitor : permette di monitorare uno o più file, directory, flussi di rete, script,
event log, parametri di rendimento, o qualsiasi altro tipo di dato macchina, a
cui Splunk Enterprise ha accesso. Quando si “clicca”su “Monitor”, Splunk Web
avvia il processo di monitoraggio.
Forward : consente di ricevere i dati dai Forwarder in Splunk. Quando si
“clicca”su “Forward”, Splunk Web inizia il processo di raccolta dei dati dai
forwarder.
Splunk Web elenca le scelte selezionate, la source, ossia il nome del file inserito,
il sourcetype, l’host e l’indice, come mostrato in Figura 3.2.
Nel caricamento dei file in Splunk, una difficoltà, riscontrata inizialmente, è
stata quella di non riuscire a caricare tutti i dati in Splunk, in quanto lo spazio di
archiviazione disponibile, dopo l’upload di una parte dei dati sul software, risultava
42
3 Installazione di Splunk e caricamento dei dati da analizzare
Figura 3.1. Opzioni per immettere i dati in Splunk Web
Figura 3.2. Elenco delle opzioni selezionate
inferiore a 5GB. Splunk, in questo caso, blocca l’indicizzazione e avvisa l’utente con
un messaggio, come mostrato in Figura 3.3.
Per qualunque distribuzione Splunk, è necessario disporre di uno spazio libero
di archiviazione minimo di 5 GB, oltre allo spazio richiesto per tutti gli indici, che
consumano la maggior parte dello spazio su disco. Se si esaurisce tale spazio, l’indicizzatore ferma l’indicizzazione. È possibile impostare un limite di spazio libero per
capire che, quando lo spazio scende al di sotto di tale limite, l’indicizzazione sta per
fermarsi. L’indicizzatore va in pausa fino a quando non sarà disponibile più spazio.
Tuttavia, i dati che vengono caricati durante la sospensione dell’indicizzazione possono essere persi. L’indicizzazione riprenderà una volta che si libererà lo spazio che,
quindi, diventerà superiore al minimo.
Sul disco è, anche, possibile impostare una quantità minima di spazio libero in
cui verranno memorizzati i dati indicizzati. Se viene raggiunto tale limite, l’indicizzatore smette di funzionare. Splunk Enterprise utilizza diversi metodi per controllare lo spazio sull’hard disk. Lo spazio libero minimo su disco può essere impostato
attraverso:
3.2 Caricamento dei dati in Splunk
43
Figura 3.3. Avviso di Spunk relativo allo spazio di archiviazione disponibile sull’hard
disk inferiore a 5GB
•
•
Splunk Web, come mostrato nella Figura 3.4.
La CLI, come mostra il Listato 3.7. In questo esempio si imposta il minimo
spazio libero a 20GB.
splunk set minfreemb 20000
splunk restart
Listato 3.7. Impostazione del minimo spazio libero sul disco con CLI
•
Il file di configurazione server.conf, mostrato nel Listato 3.8, dove <num>
rappresenta la dimensione in MB. È possibile monitorare lo spazio su disco, specificando la dimensione massima degli indici oppure impostando l’età massima
dei dati. Quando viene raggiunto uno di questi limiti, i dati indicizzati più vecchi
verranno eliminati (impostazione predefinita) o archiviati.
[diskUsage]
minFreeSpace = <num>
Listato 3.8. Impostazione del minimo spazio libero sul disco nel file di configurazione
server.conf
Indipendentemente dal tipo di licenza, la dimensione di caricamento massima
per i file, da Splunk Web, è di 500 MB. Per tale motivo, i file di log analizzati in
questo lavoro di tesi, avendo una dimensione molto maggiore di 500 MB, sono stati
44
3 Installazione di Splunk e caricamento dei dati da analizzare
Figura 3.4. Impostazione del minimo spazio libero sul disco in Splunk Web
divisi in file di dimensione adeguata, per il caricamento in Splunk Enterprise Web,
con un parser scritto in Python, mostrato nel Listato 3.9.
import os
import sys
suffixes = [’B’, ’KB’, ’MB’, ’GB’, ’TB’, ’PB’]
def humansize(nbytes):
if nbytes == 0: return ’0 B’
i = 0
while nbytes >= 1024 and i < len(suffixes)-1:
nbytes /= 1024.
i += 1
f = (’%.2f’ % nbytes).rstrip(’0’).rstrip(’.’)
return {"dimensione":f,"formato":suffixes[i]}
if __name__ == ’__main__’:
file=sys.argv[1]
print file
try:
with open(file) as fp:
i=1
for line in fp:
f1=open(file+"_asa_log_part"+str(i),"a+")
f1.write(str(line))
#f1.write("\n")
f1.close()
dimensione = humansize(os.path.getsize(file+"_asa_log_part"+str(i)))
if dimensione[’formato’] == ’MB’:
if float(dimensione[’dimensione’]) >=450 :
i+=1
except Exception as e:
print e
pass
Listato 3.9. Parser in Python per la divisione dei file di log
3.3 Indicizzatore di Splunk
45
3.3 Indicizzatore di Splunk
Splunk Enterprise monitora e indicizza i file nel momento in cui appaiono nuovi
dati. Questi vengono portati in Splunk dai forwarder, cioè agenti Splunk, installati
su un computer remoto, per la raccolta dei log.
Un forwarder riceve i dati da una source, ad esempio un server web, e li invia ad
un’istanza di Splunk. L’indicizzatore raccoglie i log inviati dai forwarder e li elabora,
per creare gli index file e i raw data. Prima che i dati raggiungano gli indicizzatori di
Splunk, possono essere analizzati e, se viene richiesta, può anche essere effettuata la
pulizia degli stessi. La comunicazione tra i forwarder e l’indicizzatore viene effettuata
utilizzando un protocollo proprietario che può essere criptato.
Il software Splunk non è ostacolato da un database SQL; piuttosto, utilizza un
archivio di dati flat, per permettere di indicizzare rapidamente tutti i dati grezzi.
Splunk Enterprise si basa su un’architettura distribuita che scala orizzontalmente
sui server ordinari (commodity server) per supportare quantità illimitate di utenti
e di dati. Il software scala anche verticalmente, incrementando la velocità di ricerca
e di indicizzazione, nonchè la capacità di usufruire di tutta la potenza della CPU
disponibile.
Uno dei componenti più importanti dell’architettura di Splunk è il data store, che si occupa di comprimere e immagazzinare i dati grezzi. L’archivio dati è
basato su una politica di conservazione configurabile; la corretta configurazione
dell’indicizzatore di Splunk è la chiave per il successo del software.
I dati in Splunk sono memorizzati in un database specifico di Splunk, noto
come index; questo consiste in una o più directory in cui Splunk memorizza i dati
elaborati.
L’indicizzatore è il più importante componente di Splunk, in quanto memorizza
in modo intelligente tutti i log raccolti. Analogamente ad un qualsiasi indice di un
libro, l’indicizzatore di Splunk crea un indice per tutti i log collezionati dal proprio
ambiente e memorizza tutti i dati in un indexer, ossia in una directory.
L’indicizzatore di Splunk, per creare un indice, richiede due fasi, come mostrato
nella Figura 3.5. Tali fasi sono:
1. Fase di parsing, che comprende l’aggiunta di metadati, che includono source,
sourceyype e host. In questa fase Splunk può essere impostato per nascondere
dati sensibili, come i numeri delle carte di credito.
2. Fase di indicizzazione, che riceve gli eventi, li divide in segmenti ricercabili e,
infine, crea l’index file e i raw data.
Nella fase di parsing, Splunk esegue le seguenti operazioni sui log:
•
•
•
per ogni evento estrae host, source e sourcetype:
– host: è il nome dell’host, l’indirizzo IP o il nome del dominio completo
dell’host di rete da cui l’evento ha avuto origine;
– source: è il nome del file, dello stream o di altro input da cui ha origine
l’evento;
– sourcetype: è il formato dei dati di input da cui proviene l’evento.
configurazione dei caratteri di codifica;
identificazione del timestamp, o creazione dello stesso, se non esiste: ciò consente
l’ordinamento dei log in base al tempo o in base a come si sono verificati.
46
3 Installazione di Splunk e caricamento dei dati da analizzare
Figura 3.5. Fasi di parsing e indexing
Nella fase di indicizzazione, Splunk esegue le seguenti operazioni:
•
•
•
Divisione di tutti gli eventi in segmenti, chiamati bucket. È possibile determinare
il livello di segmentazione, che ha effetti sull’indicizzazione, sulla velocità, sulla
capacità di ricerca e sull’efficienza della compressione del disco.
Costruzione della struttura dell’indice.
Scrittura su disco dei raw data e degli index file. È, in questa fase, che avviene
la compressione post-indicizzazione.
A questo punto, i dati possono essere facilmente cercati su Splunk.
Quando quest’ultimo indicizza i dati, vengono creati:
1. raw data, in forma compressa, che rappresentano il file di log completo;
2. index file, che “puntano”ai raw data.
Insieme, questi file costituiscono l’indice di Splunk. Splunk Enterprise fornisce una
serie di indici preconfigurati, tra cui internal, audit e main, che è l’indice di default
3.3 Indicizzatore di Splunk
47
di Splunk Enterprise. Se non viene specificato diversamente, tutti i dati elaborati
vengono memorizzati nell’indice main.
I file risiedono in una serie di directory, organizzate per periodo di tempo. Alcune di queste contengono i dati indicizzati recentemente, altre contengono dati
indicizzati precedentemente. Il numero di tali directory cresce in base alla quantità
di dati che si stanno indicizzando.
Splunk immagazzina tutti i suoi dati in cartelle sul server chiamate bucket. Con
il passare del tempo, i bucket “rotolano”da uno stadio a quello successivo, ossia si
muovono attraverso diverse fasi. Il ciclo di vita dei bucket, mostrato in Figura 3.6,
prevede le seguenti fasi:
Figura 3.6. Ciclo di vita dei buckets
•
•
•
Hot bucket: questa è la directory in cui sono conservati i dati indicizzati più
recentemente. Ogni hot bucket occupa la sua subdirectory e per tale motivo ci
possono essere più hot subdirectory. Dopo che l’hot bucket raggiunge una certa
dimensione, esso diventa un warm bucket (si dice che esso “rolls to warm”); a
questo punto viene creato un nuovo hot bucket. Gli hot bucket rotolano sempre
allo stadio successivo quando Splunk viene riavviato.
Warm bucket: è il livello successivo ed è di sola lettura. Ci sono molti warm
bucket. Una volta che Splunk ha creato un numero massimo di warm bucket,
sulla base dell’“età”dei bucket, si passa ai cold bucket. Il primo warm bucket
che rotola ad un cold bucket è quello più vecchio; man mano che tutti gli altri
invecchiano, rotolano anch’essi nei cold bucket. Per ciascun warm bucket ci sono
sottodirectory separate.
Cold bucket: in essi ci sono i dati richiesti raramente, in quanto sono invecchiati
o sono stati archiviati in questo bucket. Ci sono più cold subdirectory. Quando i
warm bucket “rotolano”nei cold bucket non vengono rinominati. Dopo un determinato periodo di tempo, i cold bucket rotolano nei frozen bucket. Se un indice è
più grande della dimensione massima specificata, i dati più vecchi rotolano nello
stato frozen.
48
•
3 Installazione di Splunk e caricamento dei dati da analizzare
Frozen bucket: la cancellazione è l’impostazione predefinita. Di default Splunk
elimina i dati congelati, ma è possibile anche archiviarli. I dati archiviati possono
poi essere scongelati. “Thawed” è la posizione dei dati che sono stati archiviati
e che dopo saranno scongelati. I dati sono eliminati o archiviati sulla base del
periodo di conservazione o della dimensione massima dell’archivio dati. È possibile utilizzare la dimensione di un indice per determinare quando i dati devono
essere congelati e rimossi dall’indice. La dimensione massima predefinita per un
indice è 500 MB. Per modificare tale dimensione, bisogna modificare l’attributo
themaxTotalDataSizeMB in indexes.conf. Ad esempio, per specificare la dimensione massima come 500 MB, basta porre maxTotalDataSizeMB = 500. È
importante ricordarsi che la dimensione deve essere specificata in MB.
Modificando gli attributi in indexes.conf è possibile specificare il criterio che
determina quando un bucket deve passare da uno stadio a quello successivo. Splunk
organizza le directory per distinguere tra hot, warm e cold bucket. Ciascun bucket occupa una propria sottodirectory all’interno di una directory più grande nel
database. Il path che indica la posizione di ogni bucket è mostrato nella Figura 3.7.
Figura 3.7. Posizione dei bucket
A seconda della quantità di dati che si deve elaborare, l’indicizzatore può richiedere più o meno tempo per indicizzare tutti i file e, per questo, potrebbe richiedere
un elevato utilizzo della CPU. Dopo un lungo periodo di tempo, tipicamente parecchi
anni, Splunk rimuove i vecchi dati dal sistema.
4
Progettazione e realizzazione dell’analisi
descrittiva
In questo capitolo ci si è soffermati sulla descrizione dei risultati ottenuti dalle
analisi descrittive relative ai log di accesso e di errore al server web di Ateneo e ai
log di accesso al firewall.
4.1 Analisi descrittiva dei log di accesso
L’obiettivo dell’analisi dei file di log è ricavare informazioni utili, quindi, estrarre
conoscenza da una grande quantità di dati. I log analizzati sono relativi al mese
di Ottobre 2016. In Figura 4.1 è possibile visualizzare l’andamento degli accessi al
web server della rete d’Ateneo dell’Università “Mediterranea”di Reggio Calabria,
nel mese di Ottobre 2016.
Figura 4.1. Andamento e frequenza degli eventi per il mese di Ottobre 2016
Ogni log di accesso è costituito da determinati campi che ci permettono di
ricavare l’indirizzo IP del client che ha effettuato l’accesso al server web, le pagine
web a cui i client vogliono accedere, la risorsa richiesta e il metodo utilizzato per
effettuare la richiesta, il codice di stato HTTP, che indica l’esito della richiesta, il
peso in byte e lo useragent del client; da quest’ultimo possiamo ricavare informazioni
sul sistema operativo e sul modello del dispositivo utilizzato.
La prima cosa su cui si è posta l’attenzione sono le pagine web che hanno
riscontrato più accessi, mostrate in Figura 4.2.
50
4 Progettazione e realizzazione dell’analisi descrittiva
Figura 4.2. Pagine web maggiormente consultate
Come ci si aspetta, la pagina web più consultata è la home page del sito web di
Ateneo, mostrata in Figura 4.3.
Figura 4.3. Home page del sito web dell’Università “Mediterranea”di Reggio Calabria
A seguire, troviamo un “-”. Per capire da quali useragent sia partita tale richiesta, è stata effettuata una ricerca, i cui risultati, mostrati in Figura 4.4, evidenziano
che la maggior parte degli accessi sono stati effettuati da web crawler; tra questi
ultimi troviamo bingbot, Yahoo! Slurp (che è un crawler sviluppato da Yahoo! ed
utilizzato dal motore di ricerca Yahoo! Search), MegaIndex, GoogleBot.
I bot (abbreviazione di robot) sono software che navigano in automatico attraverso Internet per rilevare e prelevare contenuti trovati in rete. Sono utilizzati
4.1 Analisi descrittiva dei log di accesso
51
Figura 4.4. Useragent che maggiormente accedono al sito web dell’Ateneo
per lo più dai motori di ricerca nel processo di identificazione ed indicizzazione dei
contenuti delle pagine web.
Il problema è che i bot, a seconda di come vengono utilizzati, possono essere bot
“buoni”e bot “cattivi”. Un esempio di bot “buono”è Googlebot, che viene usato
da Google per eseguire la scansione e per indicizzare le pagine web su Internet.
I “bot cattivi”, invece, vengono utilizzati per scopi malevoli, come, ad esempio:
inviare messaggi di spam, diffondere malware, gonfiare artificialmente il traffico dei
siti web, copiare contenuti dei siti e raccogliere e rubare indirizzi e-mail presenti nei
siti web.
Le altre pagine web più visitate sono, rispettivamente, la home page del Dipartimento di Giurisprudenza ed Economia (DIGIEC), la pagina web dei Docenti dei
diversi dipartimenti d’Ateneo, mostrata in Figura 4.5, la home page del dipartimento di Agraria, quella del Dipartimento di Architettura e Territorio (DARTE)
e quella del Dipartimento di Ingegneria Civile, Energia, Ambiente e Materiali (DICEAM). Le pagine web più visitate potrebbero essere quelle dei dipartimenti che
contano il maggior numero di iscritti.
Figura 4.5. Pagina web dei docenti dei diversi dipartimenti d’Ateneo
52
4 Progettazione e realizzazione dell’analisi descrittiva
La Figura 4.6 permette di capire quanti indirizzi IP ogni giorno si sono connessi
al sito www.unirc.it, senza, però, tenere in considerazione quante volte è acceduto
in un giorno ciascuno di questi indirizzi. Il giorno in cui sono stati registrati più
accessi è Martedı̀ 4 ottobre, allorquando ci sono stati 3.836 accessi.
Figura 4.6. Numero di indirizzi IP che accedono per ogni giorno di Ottobre al server web
Splunk, inoltre, permette di visualizzare la provenienza di ogni indirizzo IP che
accede al server web su una mappa geografica. La Figura 4.7 mostra da dove provengono gli indirizzi IP che hanno effettuato l’accesso al server web durante il mese
di Ottobre. Come ci si aspetta, la maggior parte degli IP vengono localizzati in
Italia.
Figura 4.7. Mappa degli indirizzi IP
Per quanto riguarda, invece, le risorse richieste, le dieci risorse maggiormente
richieste vengono visualizzate nella Figura 4.8.
Successivamente, tramite lo useragent, abbiamo potuto effettuare un’analisi sui
sistemi operativi utilizzati dagli utenti che accedono al web server. La Figura 4.9
4.1 Analisi descrittiva dei log di accesso
53
Figura 4.8. Le dieci risorse maggiormente richieste
ci permette di capire quali sono quelli più usati: al primo posto c’è Windows, poi
Android, iOS, Mac OS e Linux. In “OTHER”sono raccolti i sistemi operativi che
sono stati utilizzati di meno e tutti i web crawler.
Figura 4.9. I sistemi operativi maggiormente usati per accedere al server
Sempre dagli useragent abbiamo ricavato i dispositivi dai quali è stato effettuato
l’accesso. Essi vengono mostrati in Figura 4.10 e, in ordine di utilizzo decrescente,
sono: Personal Computer, Samsung, iPhone, Huawei e LG. Quelli non elencati sono
inglobati in “OTHER”.
Successivamente, è stata posta l’attenzione sui web crawler. Un crawler è un
software che analizza i contenuti di una rete o di un database in un modo metodico e
automatizzato, per conto di un motore di ricerca, il quale fornisce al crawler una lista
di URL da visitare. Esso è un tipo di bot che acquisisce una copia testuale di tutti
i documenti visitati; tali copie vengono, poi, inserite in un indice. Nel nostro caso, i
crawler che hanno effettuato più accessi nel corso di Ottobre 2016 sono mostrati in
Figura 4.11. I primi due sono, rispettivamente, “Bingbot” e “Googlebot”. Bingbot è
lo spider del motore di ricerca Bing, mentre Googlebot è lo spider di Google. I bot
54
4 Progettazione e realizzazione dell’analisi descrittiva
Figura 4.10. Modelli dei dispositivi usati per accedere al server web
sono stati localizzati in 25 paesi, visualizzabili sulla mappa geografica mostrata in
Figura 4.12. L’87,153% di essi si trovano negli USA, ma una bassa percentuale è
presente anche in Italia (3,59%), Germania (2,40%), Francia (2,37%), Regno Unito
(2,30%) e Russia (1.39%), come mostra la Figura 4.13
Gli indirizzi IP che accedono maggiormente al server sono: 78.47.225.238 e
193.204.242.10, come mostrato nella Figura 4.14. Ci si è soffermati su questi ultimi
per capire cosa hanno richiesto e da dove provengono.
Per quanto riguarda il primo indirizzo IP (78.47.225.238) è emerso che si tratta
di un IP proveniente dalla Germania e che ha effettuato gli accessi al web server
solo nei giorni 8/10/2016 e 9/10/2016, come mostrato in Figura 4.15. Il giorno
8/10/2016 conta 28.034 eventi, mentre il giorno 9/10/2016 ne conta 806.232.
La pagina web più richiesta da tale indirizzo è la home page della “Mediterranea”, ossia l’indirizzo www.unirc.it, come si può vedere nella Figura 4.16. Le altre
nove pagine web più richieste sono mostrate in Figura 4.17.
Queste ultime inducono a pensare che si potrebbe trattare di un tentativo di SQL
Injection e, quindi, tutte le richieste effettuate alla home page potrebbero essere
delle prove effettuate per testare la vulnerabilità del sito web. La SQL injection è
una tecnica di hacking che mira ad iniettare del codice sfruttando le vulnerabilità
di una web application che fa uso di DBMS relazionali. La vulnerabilità è dovuta
alla mancanza di controlli sui dati ricevuti in input. I comandi SQL sono, quindi,
iniettati tramite query nel database di un’applicazione web al fine di autenticarsi
con i massimi privilegi, in aree protette del sito, anche senza essere in possesso delle
credenziali d’accesso, e di visualizzare e alterare dati sensibili. Le stringhe di codice
SQL malevole vengono, quindi, eseguite, per esempio, per fare inviare il contenuto
4.1 Analisi descrittiva dei log di accesso
55
Figura 4.11. Web crawler che hanno effettuato il maggior numero di accessi
Figura 4.12. Mappa dei Web crawler
del database all’attaccante.
Lo useragent da cui sono partite più richieste (748.153) è: “Mozilla/5.0
(Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome
/41.0.2228.0 Safari/537.21”, mentre il sistema operativo maggiormente usato
da quell’indirizzo IP è Windows, come si vede nella Figura 4.18. Questo è confermato
dal fatto che il dispositivo più utilizzato è il Personal Computer, come si può vedere
nella Figura 4.19. Invece, le risorse maggiormente richieste sono mostrate nella Figura 4.20; la gran parte di esse sono richieste al sito www.unirc.it. Ai primi tre posti
troviamo, rispettivamente: “/studenti/registrazione aziende tirocini.php?
task=reg”, “/area riservata.php ”e “/ateneo/iscrizione corsi lingua.php”.
56
4 Progettazione e realizzazione dell’analisi descrittiva
Figura 4.13. Web crawler che hanno effettuato il maggior numero di accessi
Figura 4.14. Indirizzi IP che hanno effettuato il maggior numero di accessi
4.1 Analisi descrittiva dei log di accesso
57
Figura 4.15. Andamento degli eventi dell’indirizzo IP che ha effettuato il maggior numero
di accessi
Figura 4.16. Pagine web richieste dall’indirizzo IP 78.47.225.238
A seguire è stata posta l’attenzione sui codici di stato HTTP inviati a questo
indirizzo IP. I codici di stato HTTP sono dei messaggi che i web server inviano al
client in risposta ad una richiesta. Sono codici numerici a tre cifre, in cui la prima
cifra definisce la categoria di appartenenza. Esistono cinque categorie di codici di
stato HTTP:
•
•
•
1xx : messaggio informativo. Questi codici di stato sono indicativi di una risposta
temporanea. Prima di una normale risposta, al client potrebbero essre inviate
una o più risposte 1xx.
2xx : esito positivo. Questa classe di codici indica che la richiesta del client è
stata accettata dal server.
3xx : reindirizzamento. Per completare la richiesta dovrà essere intrapresa un’ul-
58
4 Progettazione e realizzazione dell’analisi descrittiva
Figura 4.17. Le prime dieci pagine web richieste dall’indirizzo IP 78.47.225.238
Figura 4.18. Il sistema operativo più utilizzato dall’indirizzo IP che ha effettuato più
accessi
•
•
teriore azione da parte del browser client. Ad esempio, è possibile che il browser
debba richiedere una pagina diversa sul server o ripetere la richiesta usando un
server proxy.
4xx : errore del client. Si verifica un errore causato apparentemente dal client.
Ad esempio,è possibile che il client abbia inviato una richiesta per una pagina
inesistente oppure che non vengano fornite informazioni di autenticazione valide.
5xx : errore del server. Il server non è in grado di completare la richiesta a causa
di un errore.
4.1 Analisi descrittiva dei log di accesso
59
Figura 4.19. Dispositivo più utilizzato dall’indirizzo IP che ha effettuato più accessi
Figura 4.20. Risorse maggiormente richieste dall’indirizzo IP che ha effettuato più accessi
I codici relativi all’indirizzo IP 78.47.225.238 vengono mostrati in Figura 4.21.
Si può notare che il codice che è apparso maggiormente è il 200, il quale indica che
le richieste hanno avuto esito positivo, cioè sono andate a buon fine e l’operazione
è riuscita. A seguire, troviamo i seguenti codici, elencati in ordine decrescente:
•
•
•
403 : indica che la richiesta è legittima ma il server si rifiuta di soddisfarla. È
possibile che si riceva questo codice di stato se il sito web non dispone di un
insieme di documenti predefinito e non è impostato per consentire l’esplorazione
delle directory.
404 : indica che l’oggetto non è stato trovato. Questo errore si può verificare se
il file a cui si sta tentando di accedere è stato spostato o eliminato.
301 : indica che l’oggetto richiesto è stato spostato permanentemente, e quindi questa richiesta e tutte le richieste future devono essere indirizzate all’URI
specificato.
60
•
•
4 Progettazione e realizzazione dell’analisi descrittiva
302 : la risorsa richiesta è stata trovata ma risiede temporaneamente in un URI
diverso.
500 : errore interno del server. Questo messaggio viene visualizzato per molti
errori lato server.
Figura 4.21. Codici di stato HTTP inviati all’indirizzo IP che ha effettuato più accessi
La Figura 4.22 è la prima parte della tabella di contingenza che mette in relazione
le pagine web richieste dall’indirizzo IP 78.47.225.238 e i relativi codici di stato
HTTP e riporta le frequenze congiunte dei due campi considerati. Questa tabella,
quindi, ci permette di capire immediatamente l’esito delle richieste delle diverse
pagine web.
Figura 4.22. Tabella di contingnza con le pagine web richieste e i relativi codici di Stato
HTTP
Il secondo indirizzo IP che effettua più accessi proviene dalla Provincia di Reggio
Calabria. Anche per questo indirizzo, e per tutti gli altri, è possibile cercare le pagine
web e le risorse più richieste, i sistemi operativi più utilizzati, i dispositivi utilizzati,
i codici di stato HTTP e gli useragent.
4.2 Analisi descrittiva dei log di errore
61
4.2 Analisi descrittiva dei log di errore
I log di errore registrano tutti gli errori che un server web riscontra nell’elaborare
una richiesta. Tali log ci danno informazioni sulla data e sull’ora in cui si è verificato
l’evento, sull’errore riscontrato, sul livello di gravità di quest’ultimo, sul messaggio
d’errore dettagliato e sull’indirizzo IP del client la cui richiesta ha generato un
errore.
Gli indirizzi IP che hanno riscontrato un errore sono stati localizzati; nella mappa
geografica in Figura 4.23 è possibile visualizzare il loro paese diprovenienza. L’Italia
è il paese che ha contato un maggior numero di errori. Ricollegandoci all’indirizzo
IP che ha effettuato il maggior numero di accessi, ossia 78.47.225.238, possiamo
vedere se ha generato errori durante le sue richieste. Quello che emerge è che è stato
riscontrato solo l’errore “PHP Fatal Error” alla pagina web www.unirc.it, il giorno
9/10/2016 dalle ore 01:33 alle ore 01:42, come mostrato in Figura 4.24.
Figura 4.23. Mappa geografica in cui sono localizzati gli errori
Quando si devono eseguire troppe funzioni ed elaborare troppi dati, può capitare che appaia il seguente errore: “PHP Fatal error: Allowed memory size of
134217728 bytes exhausted (tried to allocate 523800 bytes) in /media/
web/unirc/include/functions.inc.php on line 276”. Questo vuol dire che si
sta cercando di caricare in mermoria una quantità di dati, espressa in MB, superiore
a quella consentita nel file php.ini strutturato nel server di residenza del dominio.
Se sono state eseguite delle modifiche, al fine di risolvere tale problematica, è necessario ripristinare la situazione precedente all’errore, altrimenti si deve agire sulle
impostazioni del file php.ini relative alla configurazione del server. Il file php.ini
62
4 Progettazione e realizzazione dell’analisi descrittiva
Figura 4.24. Fascia oraria in cui è stato riscontrato l’errore PHP Fatal Error
non sempre è modificabile; talvolta va chiesto al provider del fornitore se è possibile
aumentare il “limite di memoria”in tale file.
Successivamemte, è stata posta l’attenzione sui bot, per capire se Bingbot
e Googlebot, che sono gli useargent che hanno effettuato un maggior numero di accessi, hanno generato errori nell’effettuare una richiesta. Quindi sono
stati individuati gli indirizzi IP corrispondenti agli useragent Bingbot e Googlebot. L’IP relativo allo useragent “Mozilla/5.0 (compatible; bingbot/2.0;
+http://www.bing.com/bingbot.htm)”è 157.55.39.159. L’IP relativo allo useragent “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/b
ot.html)ӏ 66.249.76.74. Entrambi gli indirizzi hanno generato il seguente errore
“not found or unable to stat”, e il messaggio d’errore dettagliato è “media/web
/unirc/dipartimenti/error apache.php”.
Questo rispecchia l’andamento generale, in quanto “not found or unable to stat”è
l’errore che appare più spesso, con una percentuale del 51.1 %, come si può vedere
in Figura 4.25. Il messaggio d’errore dettagliato che appare più frequentemente,
con una percentuale del 95,567 %, è “media/web/unirc/dipartimenti/error apac
he.php”, come mostra la Figura 4.26. In entrambe le figure è, anche, possibile
visualizzare gli errori che appaiono più raramente.
4.3 Analisi descrittiva dei log del firewall
In generale, lo scopo di un firewall è quello di proteggere la rete interna, privata (in
questo caso la rete universitaria), dal traffico potenzialmente ostile. In informatica
il Port Scanning è una tecnica progettata per sondare un server stabilendo quali
porte siano in ascolto sulla macchina. Qualsiasi attaccante, prima di sferrare un
attacco, deve effettuare la scansione di tutte le porte. Le tecniche di port scanning
permettono di individuare quali servizi espone un sistema remoto. Un port scan è
un processo che invia le richieste dei client a un intervallo di indirizzi di porte su un
server, con l’obiettivo di trovare una porta aperta. Elaborando le risposte è possibile
stabilire quali servizi di rete siano attivi e disponibili su un server.
4.3 Analisi descrittiva dei log del firewall
63
Figura 4.25. Primi dieci errori maggiormente riscontrati
Figura 4.26. I dieci messaggi d’errore che sono apparsi maggiormente
Ogni porta è identificata da un numero, da 0 a 65535. Per convenzione alcuni servizi sono solitamente in esecuzione su determinate porte: un server web (protocollo
HTTP) utilizza di norma la porta 80, mentre un servizio FTP la 21.
La scansione delle porte è facilmente rilevabile, in quanto molte applicazioni
mantengono un log delle connessioni ricevute e tale scansione, probabilmente, verrà
registrata come una connessione non andata a buon fine, dal punto di vista del
server, poichè è stata abbattuta senza inviare alcun dato.
È importante tenere presente che nessuna difesa può essere considerata “definitiva”: ogni giorno vengono scoperte nuove tecniche di attacco ai sistemi; ciò impone
ai sistemisti un aggiornamento costante. Nessuna difesa, per quanto sofisticata, è
impenetrabile. In generale, un attaccante particolarmente motivato e con molto
tempo a disposizione riuscirà sempre a violare in qualche modo il proprio bersaglio.
Quindi, è importante rilevare gli attacchi quando vengono eseguiti e mitigarne i
danni in caso di successo.
L’analisi dei file di log del firewall è utile per identificare qualsiasi attività dannosa all’interno della rete. Ogni evento ha un determinato codice identificativo.
Consideriamo il codice identificativo 106100, che ci permette di conoscere IP sorgente e porta sorgente, IP di destinazione e porta di destinazione. Inoltre, i file di
64
4 Progettazione e realizzazione dell’analisi descrittiva
log ci permettono di capire se l’accesso al pacchetto è stato consentito o negato
dall’Access Control List.
Per prima cosa, vediamo quali sono i dieci paesi che hanno effettuato il maggior
numero di connessioni negate su porte differenti. In questo modo possiamo capire
su quante porte diverse essi si sono connessi. Quindi, se un paese si collega su un
numero elevato di porte, è probabile che stia facendo la scansione di tutte le porte
per sapere dove sferrare l’attacco. La Figura 4.27 mostra che la Cina è il paese che
si collega su un numero elevato di porte, in particolare 61.046, seguita dagli Stati
Uniti (che si collega su 53.615 porte), Francia, Italia, Germania, Olanda, Irlanda,
Regno Unito, Repubblica Coreana ed Ecuador.
Figura 4.27. Paesi che hanno effettuato più connessioni su porte diverse
Per esempio, possiamo analizzare gli indirizzi IP di ogni paese e scoprire quali
sono quelli che appaiono più volte nei log analizzati. In Cina l’IP che appare più
frequentemente è il 59.56.77.6, come si può vedere nella Figura 4.28.
Mentre gli IP che appaiono più di frequente negli Stati Uniti sono: 207.191.195.138,
31.13.77.6 e 172.217.17.147, come si può vedere in Figura 4.29.
Successivamente, al fine di individuare i Paesi che hanno effettuato attacchi al
server, è stata effettuata una ricerca che conta quante volte ogni paese si è collegato
complessivamente su tutte le porte ed ha avuto accesso negato. Anche in questo caso
ci fermiamo ai primi dieci paesi che hanno effettuato più collegamenti. La Figura
4.30 mostra che la Cina ha effettuato complessivamente 9.892.415 collegamenti.
A seguire troviamo il Vietnam, il Brasile, gli Stati Uniti, Taiwan, la Repubblica
Coreana, l’Ucraina, la Turchia, la Russia e l’India.
I paesi in comune ai due grafici, ossia Cina, Stati Uniti e Repubblica Coreana
sono quelli che si sono collegati su un numero elevato di porte per più volte ed hanno
avuto accesso negato. Quindi, questi potrebbero essere i paesi che sferrano attacchi
al server web d’Ateneo. A questo punto, per capire quali sono gli IP da cui, probabilmente, sono partiti attacchi, ci siamo soffermati su questi tre paesi e per ognuno
di essi, abbiamo prima analizzato gli indirizzi IP sorgente che effettuano connessioni
4.3 Analisi descrittiva dei log del firewall
Figura 4.28. Indirizzi IP che accedono maggiormente dalla Cina
Figura 4.29. Indirizzi IP che accedono maggiormente dagli Stati Uniti
Figura 4.30. Paesi che hanno effettuato complessivamente più connessioni
65
66
4 Progettazione e realizzazione dell’analisi descrittiva
su più porte di destinazione distinte e poi gli IP che effettuano complessivamente il
più alto numero di connessioni. Dopo di ciò, abbiamo selezionato gli IP che appaiono in entrambe le analisi. Quelli in comune per gli Sati Uniti sono 172.217.14.147,
205.185.208.98, 65.55.2.82, 131.253.40.10 e 8.8.8.8. Quelli in comune per la Cina sono 114.114.114.114 e 202.118.1.81. Mentre, per la Repubblica Coreana, non ci sono
indirizzi in comune.
Per brevità di trattazione, verrà analizzato, qui di seguito, solo un indirizzo
tra quelli sopra elencati. L’indirizzo su cui ci si è soffermati è il 205.185.208.98, in
quanto è quello che presenta più sovrapposizioni, a livello temporale, tra connessioni
permesse e connessioni negate, come si può vedere in Figura 4.31, nella cui parte
superiore possiamo vedere l’andamento temporale delle connessioni permesse e nella
parte inferiore l’andamento temporale di quelle negate. Questo indica che è più
probabile che in tali giorni questo indirizzo IP abbia potuto effettuare attacchi e
riuscire in tale intento.
Figura 4.31.
205.185.208.98
Andamento temporale delle connessioni relative all’indirizzo IP
L’attaccante giorno 16 Ottobre ha eseguito diverse connessioni, le quali hanno
4.3 Analisi descrittiva dei log del firewall
67
avuto tutte un esito negativo, come si può vedere in Figura 4.32; tale figura riporta le richieste negate. Tale giorno non ci sono state connessioni accettate. Questo
potrebbe voler dire che il client con l’indirizzo IP 205.185.208.98 ha provato ad eseguire la scansione delle porte per capire quale fosse la porta su cui poter sferrare
l’attacco.
Figura 4.32. Connessioni negate dell’IP 205.185.208.98 durante il 16 Ottobre
Il giorno successivo, 17 Ottobre 2016, tale IP ha continuato ad effettuare altre
richieste, ottenendo meno connessioni negate, come si vede in Figura 4.33. Dopo
diversi tentativi, dalle ore 13:27 alle 13:37 riesce ad avere 351 connessioni permesse
mentre altre 66 riesce ad averle dalle 17:00 alle 18:00, come mostra la Figura 4.34;
quindi, riesce ad ottenere l’accesso al server.
Figura 4.33. Connessioni negate all’IP 205.185.208.98 durante il 17 Ottobre
Figura 4.34. Connessioni permesse all’IP 205.185.208.98 durante il 17 Ottobre
68
4 Progettazione e realizzazione dell’analisi descrittiva
A questo punto, il client è riuscito ad individuare le porte a disposizione e capisce
dove può effettuare l’attacco.
Tale indirizzo, inoltre, rispetto agli altri IP, è quello che conta il maggior numero
di connessioni sulle porte Telnet ed SSH, che sono quelle su cui è possibile effettuare
degli attacchi per prendere il controllo del server. Per tale motivo ci siamo soffermati
solo sulle porte 22 (SSH) e 23 (Telnet).
Se analizziamo il caso SSH, è possibile vedere che sia giorno 16 che giorno 17
molte connessioni ad SSH sono state negate, come si vede nelle Figure 4.35 e 4.36.
Però giorno 17 abbiamo anche 14 connessioni permesse dalle ore 13.00 alle ore 14:00,
come mostra la Figura 4.37. Questo vuol dire che l’attaccante ha provato a fare degli
attacchi ed è riuscito a prendere il controllo in questa fascia oraria.
Figura 4.35. Connessioni SSH negate all’IP 205.185.208.98 il 16 Ottobre
Figura 4.36. Connessioni SSH negate all’IP 205.185.208.98 il 17 Ottobre
Figura 4.37. Connessioni permesse alla porta SSH per l’IP 205.185.208.98 il 17 Ottobre
Invece, per quanto riguarda la porta Telnet, giorno 17 Ottobre ci sono state
molte richieste negate, come si vede in Figura 4.38, mentre, nella fascia oraria che
4.3 Analisi descrittiva dei log del firewall
69
va dalle ore 13:00 alle ore 14:00, si riscontrano 24 connessioni permesse, mentre altre
due permesse si hanno dalle ore 17:00 alle ore 18:00.
Figura 4.38. Connessioni Telnet negate all’IP 205.185.208.98 il 17 Ottobre
Figura 4.39. Connessioni permesse alla porta Telnet per l’IP 205.185.208.98 il 17 Ottobre
Tali analisi possono essere effettuate allo stesso modo per qualsiasi altro indirizzo
IP.
5
Anomaly Detection
In questo capitolo, inizialmente, verrà spiegato perchè è importante effettuare attività di “anomaly detection”. Successivamente, si descriverà l’app di Splunk utilizzata per effettuare “outlier detection”. Infine, verrano illustrate le anomalie emerse
dall’analisi degli outlier.
5.1 Introduzione all’analisi degli outlier e Data Mining a supporto della cybersecurity
Nei sistemi operativi, nelle applicazioni e nei database è possibile individuare delle
vulnerabilità. Una vulnerabilità è un punto debole che potrebbe consentire ad un
aggressore di compromettere la sicurezza dell’intero sistema. Quindi, è di fondamentale importanza attuare misure di controllo e prevenzione (come, ad esempio,
dotarsi di dispositivi di protezione firewall o di controllo degli accessi, attraverso procedure di autenticazione) sulle potenziali vulnerabilità, per bloccare minacce e per
permettere alle organizzazioni di proteggere le informazioni considerate riservate,
garantendo confidenzialità e integrità dei dati.
Uno dei meccanismi per l’individuazione delle attività sospette è la verifica dei
log di sistema che consente di individuare attività anomale e di monitorare i pacchetti destinati al firewall o al server, sia per reagire a pattern di attacco noti sia
per accorgersi di un Port Scanning da remoto, generalmente prologo di un tentativo
di intrusione.
È stato già spiegato precedentemente che i file di log di un web server o di
un firewall registrano informazioni di eventi scaturiti durante l’esecuzione di un
processo; attraverso la loro analisi, è possibile individuare attacchi ai sistemi, in
quanto essi potrebbero lasciare segni negli eventi contenuti nei log.
Infrangere la sicurezza di un sistema comporta, spesso, un uso anormale dello
stesso; quindi, le intrusioni sono rilevate cercando le attività che si differenziano dal
normale comportamento.
Nel Data Mining il rilevamento delle anomalie (anomaly detection) consiste nell’identificazione di eventi che non sono conformi ad un modello previsto in un insieme di dati. Attraverso il Data Mining è possibile scoprire relazioni ed informazioni
precedentemente sconosciute e potenzialmente utili.
72
5 Anomaly Detection
Una branca del Data Mining che si occupa in maniera specifica dei file di log è il
Process Mining. La presenza di meccanismi di tracciatura e di logging in un sempre
crescente numero di piattaforme IT ha già consentito di applicare il Process Mining
a svariati contesti applicativi. Tuttavia, l’applicabilità e la rilevanza di tali tecniche
di analisi assumono un carattere ancora più accentuato in contesti organizzativi
sensibili alle problematiche della cybersecurity, dove la raccolta e memorizzazione
di log è ormai riconosciuta come una pratica virtuosa per l’analisi dei rischi e per il
rafforzamento delle politiche di sicurezza.
È importante che le aziende e gli enti governativi predispongano meccanismi
di “security enforcement and security check”al livello dei loro processi organizzativi. Tale orientamento è destinato a produrre una sempre maggiore diffusione di
infrastrutture per il tracciamento dei processi, indispensabili per riscontrare comportamenti fraudolenti o colposi, e una domanda crescente di strumenti innovativi
di analisi che consentano di estrarre conoscenza utile, ai fini della sicurezza, da log
di grandi dimensioni. In tale prospettiva, le tecniche di Process Mining possono rivelarsi un potente strumento di analisi che si presta in modo naturale a varie tipologie
di applicazioni in uno scenario di cybersecurity, tra cui la scoperta e la predizione
dei casi di violazione della sicurezza.
L’idea di base consiste nello stimare come potenziali minacce le istanze di esecuzione che divergono dai pattern di esecuzione tipici del processo facendo leva sull’assunzione, comune a molte applicazioni di security management, che i comportamenti
anomali abbiano un’elevata probabilità di essere pericolosi.
Le strategie di rilevazione delle anomalie perseguono l’obiettivo di identificare un
comportamento non appropriato, non appena esso si è verificato. Spesso, l’obiettivo
finale che si vuole raggiungere è quello di individuare dei tipi di condotta “normali”,
in contrasto ai quali comportamenti dissimili possano risultare “anormali”, e quindi
motivo di allarme e di potenziale intervento.
In altri termini, dall’analisi dei dati comportamentali, ovvero dei valori assunti
dalle feature che caratterizzano le sequenze di azioni compiute da un utente su
una risorsa, è possibile rilevare anomalie comportamentali che evidenziano un uso
inatteso di tale risorsa, e prendere eventuali contromisure.
Dal parsing dei file di log è possibile ricavare gli episodi che avvengono frequentemente (si assume che essi rappresentano il profilo normale del sistema) e gli
episodi che si verificano meno frequentemente (i quali vengono, quindi, considerati
“anomali”). Il numero delle osservazioni “normali”è largamente superiore a quello
delle osservazioni “anormali”. Gli outlier vengono analizzati perchè ci permettono
di individuare anomalie nei dati.
5.2 Machine Learning Toolkit
Per fare “anomaly detection”è stata utilizzata l’app di Splunk “Machine Learning
Toolkit”, la quale, tra le diverse funzioni che offre, permette anche di rilevare gli
outlier. In Figura 5.1 è possibile vedere l’nterfaccia grafica di questa app.
Essa consente di applicare una varietà di tecniche e metodi di machine learning,
come, ad esempio, la classificazione, la regressione, la rilevazione di anomalie e di
outlier. I diversi showcase illustrano come applicare questi metodi su un campione
5.2 Machine Learning Toolkit
73
Figura 5.1. Interfaccia grafica dell’app Machine Learning Toolkit
di dati inclusi nell’applicazione, i quali possono essere utilizzati per esercitarsi e
capire come funziona l’app. Inoltre, l’app stessa offre nuovi comandi SPL ed altre
visualizzazioni.
È possibile installare l’app sia in Splunk Enterprise che in Splunk Cloud. Nel
nostro caso è stata installata in Splunk Enterprise Web; a tal fine è stato sufficiente scaricare il file di installazione e, successivamente, installare l’app dal file,
importandolo in Splunk Web. Dopodichè, per poter utilizzare tutte le funzionalità che questa app ci offre, è stato scaricato l’add-on “The Python for Scientific
Computing”relativo al sistema operativo sul quale è stato installato Splunk.
A questo punto è possibile lanciare la query e, una volta terminata l’esecuzione,
bisogna procedere con il setting dei parametri.
Una delle prime cose che è necessario specificare riguarda quale “threshold
method”utilizzare. Abbiamo tre alternative:
•
•
•
Deviazione standard : si usa se i dati seguono una distribuzione normale e se non
importa che gli outlier abbiano un grande impatto sulla soglia di classificazione.
La deviazione standard è un indice di dispersione statistico, ossia è uno dei modi
per esprimere la dispersione dei dati intorno ad un indice di posizione, quale può
essere, ad esempio, la media aritmetica o una sua stima. La deviazione standard
(o scarto quadratico medio) è la radice quadrata della varianza.
Median absolute deviation (MAD): è una misura di dispersione. Essa viene utilizzata quando è necessario che il valore della deviazione sia meno influenzato
dai valori estremi. Ciò è dovuto al fatto che la mediana è meno influenzata dai
valori estremi rispetto alla media. La MAD è uno stimatore più robusto della
semplice varianza o deviazione standard e presenta una minore sensibilità agli
outlier rispetto alla deviazione standard.
Scarto interquartile: essendo in grado di escludere la maggior parte degli elementi anomali, esso viene utilizzato spesso in relazione ad un campione di dati
per misurarne l’indice di dispersione. Esso è una misura di quanto i valori si
allontanino da un valore centrale.
74
5 Anomaly Detection
Gli ultimi due metodi si usano se si vuole più robustezza rispetto ai valori anomali.
La MAD è più robusta agli outlier riseptto alla deviazione standard.
Dopodichè, un altro paramentro che bisogna specificare è il valore del “moltiplicatore di soglia (threshold multiplier)”. Maggiore è tale numero e maggiore sarà
l’intervallo all’interno del quale i valori vengono considerati “normali”; minore sarà,
quindi, il numero di outlier.
I valori del lower bound e dell’upper bound di tale intervallo vengono determinati automaticamente dall’app in base al valore che viene scelto per il threshold
multiplier.
Nelle nostre analisi, di volta in volta, sono state considerate variabili diverse;
pertanto, il valore del moltiplicatore di soglia e, di conseguenza, i valori dell’upper
bound e del lower bound, sono stati scelti in maniera euristica e considerando, anche,
che il valore di outlier restituito debba contenere al massimo un valore anomalo ogni
1000; tale scelta è motivata dal fatto che un outlier, per definizione, è un valore che
deve essere molto diverso dagli altri e, quindi, si verifica raramente.
Come si è ben capito, questo metodo è flessibile; pertanto, la soglia può essere
cambiata facilmente in qualunque istante.
Ad esempio, se la maggior parte delle porte di destinazione riceve migliaia di
connessioni, non è possibile avere un upper bound pari a 1000, perchè, altrimenti,
rischieremmo di avere un numero spropositatodi potenziali outlier che, alla prova
dei fatti, si rivelerebbero falsi positivi.
È, inoltre, possibile specificare una “sliding window”. Se non si specifica, l’intervallo all’interno del quale i valori non sono considerati outlier è calcolato utilizzando
l’intero set di dati e, quindi, esso avrà una dimensione uniforme.
A questo punto, il rilevatore di outlier numerici determinerà i valori che sembrano
essere molto più alti o più bassi rispetto al resto dei dati; successivamente, sarà
possibile visualizzare i grafici e vedere quanti sono gli outlier identificati.
I valori che cadono al di fuori dell’intervallo blu sono indicati da un punto giallo
e rappresentano gli outlier. Se si passa il mouse sopra il punto giallo è possibile
visualizzare sia il valore che la quantità di tale outlier; se si “clicca”su di esso è
possibile effettuare drill-down, ossia viene lanciata una query che mostra in dettaglio le informazioni su quel valore anomalo. In Figura 5.2 vediamo un esempio di
visualizzazione di outlier numerici.
L’Anomaly Detection ha il vantaggio che permette di rilevare i “sintomi”di un attacco, senza conoscerne esattamente i dettagli. Però ha lo svantaggio che si potrebbe
avere un alto numero di falsi positivi.
5.3 Outlier Detection
Gli outlier rappresentano dati che sono considerevolmente differenti rispetto agli
altri. Sapere come trattare i valori anomali è importante per assicurare una comprensione adeguata dei dati e per consentire, in ultima analisi, di raggiungere conclusioni più accurate dallo studio. Infatti, i valori anomali individuati potrebbero
essere indicativi di eventi interessanti, insoliti e potenzialmente pericolosi.
La presenza di un outlier può essere determinata, per esempio, da una distribuzione della variabile, rispetto alla quale abbiamo trovato l’outlier, con valori estre-
5.3 Outlier Detection
75
Figura 5.2. Esempio di visualizzazione nel caso di rilevazione di outlier numerici
mi rispetto ad una distribuzione normale. Un outlier, infatti, è un’osservazione con
valori molto diversi da quelli degli altri dati.
Nel nostro caso, per esempio, se decidiamo di analizzare quali sono i client che
si sono collegati maggiormente al firewall d’Ateneo e vediamo che la maggior parte
degli indirizzi IP hanno un numero di connessioni compreso in un certo intervallo,
mentre un altro indirizzo IP effettua un numero di connessioni estremamente più
alto, si può concludere che quello è un outlier.
5.3.1
Analisi degli outlier relativi agli accessi al firewall
Il metodo per la scelta della soglia deve essere selezionato anche in base alla distribuzione dei dati. Quindi, considerando che i log relativi agli accessi al firewall non
seguono un andamento normale, come si può vedere in Figura 6.2, e visto che la
mole di dati analizzata è pari 55 GB, abbiamo bisogno di un metodo più robusto
agli outlier. Per tali ragioni, è stato utilizzato la Median Absolute Deviation.
Figura 5.3. Andamento temporale degli accessi al firewall
Inoltre, considerando che in Splunk le visualizzazioni sono state configurate per
visualizzare un numero massimo di risultati e considerando anche che, nel nostro
caso, il numero totale di eventi è sempre elevato, i grafici degli outlier non permettono di visualizzare tutti i valori anomali. Allora, per ovviare a questa problematica
76
5 Anomaly Detection
grafica, di volta in volta è stata lanciata una query che permettesse di visualizzare
solo i valori esterni al lower bound e all’upper bound e, quindi, desse come risultato
grafico solo gli outlier, rappresentati con un pallino giallo. Quindi ciò che escludiamo
dalle visualizzazioni sono i valori considerati “normali”.
Iniziamo analizzando tutti gli indirizzi IP sorgente, considerando tutti i paesi
coinvolti. La Figura 6.6 mostra che ci sono 165 indirizzi IP che possono essere considerati outlier su 7.224.630 eventi in totale. In Figura 5.5 possiamo visualizzare
l’andamento di questi 165 valori anomali. Gli IP che hanno effettuato più accessi tra questi 165 sono mostrati in Figura 5.6. Il picco in Figura 5.5 corrisponde
all’indirizzo IP 10.117.2.6, che effettua 2.224.214 connessioni. Nella Figura 6.7, in
corrispondenza di ogni indirizzo IP, c’è il paese nel quale esso è stato localizzato.
Però in corrispondenza dell’IP 10.117.2.6 la casella “Country”è vuota e questo vuol
dire che tale IP fa parte della rete interna all’università.
Il secondo picco in Figura 5.5 corrisponde all’IP 37.220.14.234, localizzato nel
Regno Unito. Esso ha effettuato 1.699.804 accessi al firewall.
In Figura 5.8 possiamo vedere che soltanto 460.049 connessioni sono state rifiutate mentre 1.239.755 connessioni sono state accettate. Tutti i collegamenti sono
stati realizzati tramite il protocollo TCP, come mostra la Figura 5.9. Le prime 20
porte a cui si è collegato tale indirizzo sono mostrate in Figura 5.10: ai primi posti
troviamo la 83 e la 443. Questo potrebbe essere benissimo un Port Scanning.
Allo stesso modo possiamo analizzare l’IP 59.56.77.6 proveniente dalla Cina,
che effettua 632.724 connessioni su diverse porte, le prime 20 sono mostrate in
Figura 5.11 e anche in questo caso sembra essere un Port Scanning. La stessa cosa
potremmo fare per l’IP olandese 93.174.93.136, che effettua 567.657 connessioni, e
per tutti gli altri.
Figura 5.4. Numero di outlier relativi a tutti gli indirizzi IP sorgente e numero totale di
eventi
Figura 5.5. Grafico degli outlier relativi a tutti gli indirizzi IP sorgente
5.3 Outlier Detection
Figura 5.6. Indirizzi IP outlier
Figura 5.7. Tabella riassuntiva relativa a tutti gli indirizzi IP più anomali
Figura 5.8. Stato della connessione relativa all’indirizzo IP del Regno Unito
77
78
5 Anomaly Detection
Figura 5.9. Protocollo usato dall’IP del Regno Unito
Figura 5.10. Le prime 20 porte a cui si è connesso l’IP del Regno Unito
Figura 5.11. Le prime 20 porte a cui si è connesso l’IP della Cina
5.3 Outlier Detection
79
Consideriamo, adesso soltanto l’Italia e analizziamo gli indirizzi IP per scoprire
quali potrebbero essere quelli anomali. Come si può vedere nella Figura 6.3, in Italia
ci sono 167 indirizzi IP su 206.560 che possono essere considerati “anomali”.
L’indirizzo IP più anomalo, in quanto è quello che ha effettuato un maggior
numero di connessioni (316.679) al firewall, è 192.167.48.85, che è localizzato a
Reggio Calabria e si collega principalmente sulle porte 443 e 80.
Figura 5.12. Numero degli outlier relativi agli IP italiani e numero totale di eventi
Figura 5.13. Grafico degli outlier relativi agli indirizzi IP italiani
Nella Figura 5.14 viene mostrata una tabella riassuntiva con gli indirizzi IP più
anomali, ordinati in numero decrescente di connessioni.
A questo punto, escludiamo l’Italia per vedere come varia l’andamento degli
outlier se consideriamo solo paesi internazionali. Troviamo 412 outlier su 6.994.645
eventi in totale, come mostra la Figura 5.15. Nella Figura 5.16 vediamo che l’IP dal
quale sono state ricevute più connessioni (si parla di ben 1.699.804 collegamenti) è
37.220.14.234, ossia quello proveniente dal Regno Unito, analizzato precedentemente. Il picco che si vede in Figura 5.17 è relativo a tale IP. Gli altri tre valori anomali,
che in Figura 5.17 spiccano sugli altri, sono relativi ad un IP cinese (59.56.77.6) e a
due IP (93.174.93.136 e 80.82.65.120) olandesi. In Figura 5.18 possiamo visualizzare
gli IP considerati più anomali.
Soffermiamoci, ora, sulle porte di destinazione, per capire quali possono essere
considerate outlier. La Figura 5.19 mostra che ci sono 43 porte che hanno subito
un maggior numero di connessioni rispetto alle altre (65.533). In Figura 5.20 c’è un
outlier che spicca sugli altri. Tale outlier corrisponde alla porta 23. Gli indirizzi
IP che effettuano più connessioni alla porta 23 sono mostrati in Figura 5.21; anche
tra questi ci siamo calcolati i possibili outlier, per capire quali sono gli indirizzi
IP che effettuano un numero di connessioni eccessivo sulla porta 23. La Figura
5.22 mostra che su 2.285.521 indirizzi IP sorgente che si collegano alla porta 23, ci
sono 114 IP che possono essere considerati anomali. In Figura 5.23 possiamo vedere
80
5 Anomaly Detection
Figura 5.14. Tabella riassuntiva con gli indirizzi IP italiani più anomali
Figura 5.15. Numero degli outlier relativi ad IP non italiani e numero totale di eventi
Figura 5.16. Tabella riassuntiva con gli indirizzi IP più anomali non italiani
5.3 Outlier Detection
Figura 5.17. Grafico degli outlier relativi agli indirizzi IP anomali non italiani
Figura 5.18. Indirizzi IP non italiani più anomali
Figura 5.19. Numero di porte di destinazione outlier e numero totale di eventi
Figura 5.20. Grafico degli outlier relativi alle porte di destinazione
81
82
5 Anomaly Detection
immediatamente i valori anomali che spiccano sugli altri outlier. Il picco in figura
corrisponde all’IP 211.201.69.50, localizzato nella Repubblica Coreana; il secondo
picco corrisponde all’IP 46.172.91.20, localizzato in Ucraina. La maggior parte delle
connessioni sulla porta 23 effettuate da questi due IP sono state negate, come si può
vedere nelle Figure 5.24 e 5.25; entrambi gli IP hanno utilizzato, per la connessione,
soltanto il protocollo TCP.
Figura 5.21. Indirizzi IP che effettuano più connessioni alla porta 23
Figura 5.22. Numero degli outlier relativi agli indirizzi IP che si collegano alla porta 23
Figura 5.23. Grafico degli outlier relativi agli indirizzi IP che si collegano alla porta 23
5.3 Outlier Detection
83
Figura 5.24. Stato delle connessioni effettuate dalla Repubblica Coreana sulla porta 23
Figura 5.25. Stato delle connessioni effettuate dall’Ucraina sulla porta 23
84
5.3.2
5 Anomaly Detection
Analisi degli outlier relativi agli accessi al server web
Anche in questo caso, per la scelta della soglia è stato utilizzato il metodo MAD,
visto che i log di Ottobre non sono distributi secondo un andamento normale, come
si può ben vedere in Figura 5.26.
Anche per quanto riguarda gli access log, per prima cosa abbiamo analizzato i
valori anomali degli indirizzi IP che accedono al web server Apache.
Come mostra la Figura 5.27 ci sono 103 valori anomali su 127.437 in totale.
Nella Figura 5.28 sono mostrati tutti gli outlier; dalla figura si può notare che c’è
un outlier che spicca sugli altri. A questo punto, spinti dalla curiosità, siamo andati
a vedere di quale indirizzo IP si tratta e, soprattutto, la provenienza di tale indirizzo.
La Figura 5.29 mostra che si tratta dell’IP 78.47.225.238 che ha fatto 834.266
connessioni e proviene dalla Germania; esso corrisponde all’IP che, nel Capitolo 4,
avevamo supposto che facesse SQL Injection.
Il secondo valore anomalo, che effettua 129.649 connessioni, è un indirizzo IP
che proviene dall’Italia, in particolare dalla Provincia di Reggio Calabria, quindi si
può ben capire che, in questo caso, non si tratta di un possibile attacco al server
web. Suona molto strano il fatto che dalla Provinicia di Reggio Calabria siano state
effettuate 129.649 connessioni e dalla Germania, invece, arrivi un numero di connessioni pari a sette volte tanto. Ciò rafforza la nostra idea che l’IP 78.47.225.238 è
potenzialmente pericoloso. Analogamente a quanto effettuato in precedenza, escludiamo l’Italia e vediamo quali sono gli IP internazionali potenzialmente pericolosi.
L’outlier degli outlier è l’IP 78.47.225.238 proveniente dalla Germania, come si può
vedere in Figura 5.32. Il picco in Figura 5.31 è relativo a tale indirizzo. Gli altri
nove indirizzi IP anomali sono tutti statunitensi. Ovviamente l’IP della Germania
effettua molti più accessi rispetto a quelli statunitensi e ciò si può vedere anche
nella Figura 5.33, in cui metà del grafico a torta è occupato da quell’IP.
Figura 5.26. Andamento degli accessi al server web d’Ateneo
Figura 5.27. Numero di IP outlier e numero totale di eventi
5.3 Outlier Detection
85
Figura 5.28. Grafico degli outlier relativi agli indirizzi IP che accedono al web server
Apache
Figura 5.29. Tabella riassuntiva con gli indirizzi IP più anomali
Figura 5.30. Numero di IP outlier non italiani e numero totale di eventi
Figura 5.31. Grafico degli outlier relativi agli IP non italiani
86
5 Anomaly Detection
Figura 5.32. Tabella riassuntiva con gli indirizzi IP non italiani più anomali
Figura 5.33. Grafico con gli indirizzi IP degli outlier non italiani
5.3 Outlier Detection
87
Infine, sono stati analizzati i bot, perchè alcuni di essi potrebbero essere “bot
cattivi”. In Figura 5.34 vediamo che c’è un outlier su 137 e in Figura 5.35 vediamo,
appunto, un picco, che corrisponde a Bingbot, che è il bot che effettua più accessi,
come si può vedere nella fetta verde del grafico a torta in Figura 5.36.
Figura 5.34. Numero di bot outlier e numero totale di eventi
Figura 5.35. Grafico degli outlier relativi ai bot
Figura 5.36. Grafico con i bot outlier che accedono al server web d’Ateneo
6
Discussione
In questo capitolo, inizialmente, abbiamo valutato i punti di forza, di debolezza,
le opportunità e le minacce relative all’analisi dei log effettuata tramite Splunk.
Successivamente sono state descritte le Best Practice e le lessons learned. Infine, è
stato spiegato come può essere generalizzato tale approccio.
6.1 SWOT Analysis
La SWOT analysis è uno strumento operativo di pianificazione strategica delle attività, usato, spesso, per la valutazione di un sistema. Essa è un’analisi di supporto
alle scelte che risponde ad un’esigenza di razionalizzazione dei processi decisionali.
L’acronimo SWOT sta per Strenghts, Weaknesses, Opportunities e Threats che
significano, rispettivamente: punti di forza, punti di debolezza, opportunità e minacce. In particolare, questo strumento analizzerà in dettaglio tutti i punti di forza
(Strenghts), quelli di debolezza (Weaknesses), le opportunità (Opportunities) e le
minacce (Threats) di un dato progetto o di una particolare situazione.
In pratica, l’analisi SWOT è una matrice che serve per valutare cosa accade nel
contesto in cui si opera e serve per valutare quali possono essere i punti di forza e
di debolezza propri del contesto di analisi, al fine di far emergere e valutare quali
sono le opportunità offerte e le minacce che derivano dal contesto esterno cui sono
esposte le specifiche realtà.
La validità dell’analisi SWOT è legata in maniera diretta alla completezza delle
analisi “preliminari”. Il fenomeno oggetto della valutazione deve essere approfonditamente studiato per poter mettere in luce tutte le caratteristiche e le relazioni.
Per tale ragione non è necessario conoscere solo il tema specifico ma c’è bisogno di
avere quanto più possibile il quadro riguardante l’intero contesto completo.
L’analisi SWOT consente inoltre di distinguere tra fattori esogeni e fattori
endogeni:
•
•
i fattori endogeni sono tutte quelle variabili che fanno parte integrante del
sistema, sulle quali è possibile intervenire;
i fattori esogeni, invece, sono quelle variabili esterne al sistema che possono, però,
condizionarlo; su di esse non è possibile intervenire direttamente ma è necessario
90
6 Discussione
tenerle sotto controllo in modo da sfruttare gli eventi positivi e prevenire quelli
negativi.
I punti di forza e di debolezza sono da considerarsi fattori endogeni, sono propri
del contesto di analisi e sono modificabili. Le minacce e le opportunità, al contrario,
sono fattori esogeni e non sono modificabili, perchè derivano dal contesto esterno.
I vantaggi dell’analisi SWOT sono molteplici; ad esempio, l’analisi in profondità
del contesto orienta nella definizione delle strategie e consente di migliorare l’efficacia delle analisi. Ma altrettanti sono gli svantaggi, come, ad esempio, il rischio di
procedure soggettive nella selezione delle azioni.
Figura 6.1. Diagramma illustrativo di una matrice SWOT
Quindi, i vari punti per costruire la matrice SWOT sono i seguenti:
•
•
•
•
Punti di forza: i vantaggi della propria analisi. Bisogna tenere presente che, per
una buona analisi, si deve essere quanto più oggettivi possibile.
Punti di debolezza: migliorie che sarebbe possibile apportare al proprio contesto
di analisi e cose che dovrebbero essere evitate.
Opportunità: possono provenire dall’analisi di scenari alternativi di sviluppo.
Minacce: derivano dal contesto esterno cui sono esposte le specifiche realtà
analizzate.
6.2 SWOT Analysis dell’analisi dei log tramite Splunk
La SWOT analysis evidenzia i principali fattori, interni ed esterni al contesto di
analisi, in grado di influenzare il successo di uno studio effettuato. È estremamente
utile per la comprensione e il processo decisionale per tutti i tipi di situazioni nel
mondo degli affari e delle organizzazioni. Essa è perfetta per business planning e
strategic planning, per valutare la concorrenza, per il marketing e per realizzare
report di ricerca. L’analisi SWOT permette alle aziende di identificare i fattori
positivi e negativi che influenzano l’interno e l’esterno di un’organizzazione.
6.2 SWOT Analysis dell’analisi dei log tramite Splunk
6.2.1
91
Punti di Forza
Splunk è uno dei migliori strumenti per la gestione dei log. È un applicativo che
nasce per l’analisi di grandi quantità di dati. Permette di risolvere problemi di
sicurezza in modo veloce e ripetibile. Infatti, ci ha permesso di eseguire le indagini
sulle violazioni della sicurezza in pochi minuti, anzichè in ore o giorni.
Un punto di forza delle nostre analisi è stata, indubbiamente, la velocità di
esecuzione di Splunk, che ci ha consentito di indicizzare e analizzare grandi quantità
di log velocemente, di eseguire ricerche, correlazioni, indagini e analisi drill-down
evitando interruzioni dell’attività o compromissione dei servizi.
I log degli accessi al firewall analizzati avevano una dimensione pari a 55 GB e,
per effettuare una specifica analisi, bastava lanciare una query che durava poco meno
di un’ora. Ovviamente, sono state effettuate diverse analisi; quindi, per poter ottimizzare i tempi, è stato necessario effettuare più analisi in parallelo. L’app “Search
& Reporting”consente di eseguire una query e di lanciare il processo in background.
Questo ci ha consentito di affrontare diverse analisi contemporaneamente.
Nonostante sia stata usata la versione free di Splunk, siamo riusciti ad ottenere
dei risultati concreti, che mettono la pulce nell’orecchio e danno indicazioni a chi
di competenza. L’obiettivo di questo lavoro di tesi era quello di riuscire ad individuare eventuali attacchi informatici al server e al firewall d’Ateneo. Tramite questo
software siamo riusciti a:
•
•
•
•
•
•
•
trovare quali sono gli indirizzi IP che nel mese di ottobre hanno effettuato più
collegamenti al firewall e al server e conoscere la loro provenienza;
capire quale protocollo di connessione è stato utilizzato dagli indirizzi IP;
capire se tali connessioni sono state accettate o negate dal firewall;
conoscere quali sono state le risorse più richieste al server web, nonchè i sistemi
operativi e i dispositivi più utilizzati per accedere al server;
conoscere quali sono i relativi codici di stato di una richiesta al web server;
trovare gli errori scaturiti da una determinata richiesta al web server;
rilevare, tramite l’app “Machine Learning Toolkit”, le anomalie, ossia le attività
che si differenziano dal normale comportamento e capire quali possono essere
stati gli indirizzi IP che hanno effettuato tentativi di port scanning e, quindi, di
intrusione.
6.2.2
Punti di Debolezza
Per poter effettuare le nostre analisi, abbiamo scaricato gratuitamente Splunk Enterprise ottendendo una licenza Splunk Enterprise Free per 60 giorni, che permette
di indicizzare fino a 500 MB di dati al giorno. Questa, però, ha avuto delle limitazioni
sia funzionali sia in termini di supporto.
Invece, le licenze Splunk Enterprise e Splunk Cloud offrono funzionalità aggiuntive per supportare installazioni distribuite multiutente e includono la creazione di
allarmi, la sicurezza basata su ruoli, il single sign-on, la generazione di PDF pianificata, il clustering, le app Splunk Premium e il supporto di volumi di dati più
elevati.
92
6 Discussione
Quindi, sostanzialmente, il fatto di aver usato solo componenti gratuiti non ci
ha permesso di utilizzare tutte le funzionalità che Splunk mette a disposizione,
precludendo, dunque, la possibilità di effettuare analisi ancora più approfondite.
Per esempio, Splunk mette a disposizione l’app “Splunk Enterprise Security”che
è il centro nevralgico dell’ecosistema di sicurezza e che permette di rilevare rapidamente e rispondere agli attacchi, sia interni che esterni, semplificando la gestione delle minacce e minimizzando il rischio. Però, come si può vedere nella Figura
6.2, non è stato possibile installarla gratuitamente. Avremmo dovuto contattare un
esperto per metterci d’accordo sul costo, come mostra la Figura 6.3.
Figura 6.2. Interfaccia per la ricerca delle app di Splunk
Figura 6.3. App “Splunk Enterprise Security”
Uno dei punti di debolezza per le nostre analisi è, sicuramente stato il costo di
6.2 SWOT Analysis dell’analisi dei log tramite Splunk
93
alcune app e il fatto di aver usato la versione gratuita di Splunk.
Il prezzo del software Splunk Enterprise si basa sulla quantità di dati che vengono
inviati ogni giorno a Splunk. La Figura 6.4 mostra che il prezzo varia in base ai
dati che devono essere indicizzati quotidianamente. L’interesse del mercato verso
Figura 6.4. Costi di Splunk
Splunk è in costante, rapida, crescita anche in Italia; le caratteristiche di flessibilità
e scalabilità della soluzione rendono Splunk interessante tanto per le grandi aziende,
che hanno bisogno di indicizzare centinaia o migliaia di GB di dati macchina al
giorno, quanto per le piccole e medie aziende, che generano poche decine di MB.
Tuttavia, soprattutto per queste ultime, le ristrettezze di budget dovute alla
perdurante crisi economica del paese spesso precludono l’investimento richiesto per
la licenza base di Splunk, orientandole, quindi, verso l’utilizzo della versione “free”,
con le conseguenti limitazioni sia funzionali sia in termini di supporto.
6.2.3
Opportunità
Le opportunità potrebbero riguardare l’individuazione di attacchi informatici, che
sprecano tante risorse inutilmente. Se il server deve rispondere a delle richieste,
ovviamente, consumerà delle risorse, ad esempio, CPU, banda e RAM.
L’individuazione di tali attacchi e la loro eliminazione potrebbe liberare risorse
preziose che, poi, potrebbero essere usate per soddisfare altre richieste.
6.2.4
Minacce
Analizzare le minacce, che potrebbero contrapporsi a tale approccio di analisi, è
tutt’altro che banale.
Sicuramente, le minacce a questo tipo di metodo utilizzato potrebbero essere
rappresentate da tipologie di attacchi per le quali Splunk non è stato pensato e che,
quindi, non riesce ad individuare.
Ad esempio, l’attaccante potrebbe “proxarsi”su più paesi. Il termine “proxarsi”deriva da “proxy”, ovvero un programma che si frappone tra una comunicazione
94
6 Discussione
client/server; praticamente il client si connette al proxy che, a sua volta, si connette
al server; ovviamente il server conoscerà sempre e soltanto l’IP del proxy. Il proxy
offre la possibilità di rimanere anonimi durante la navigazione sul web. Navigare su
internet in modo anonimo significa nascondere il proprio indirizzo IP per non farsi
localizzare e non far sapere da dove ci si collega.
Un proxy può essere usato per diverse ragioni, quella più comune è, appunto,
l’anonimato. Navigare restando anonimi significa che l’IP di un attaccante è diverso
da quello vero durante ogni connessione,. Infatti, si potrebbe facilmente risalire
alla posizione dell’attaccante, e, dunque, ad altre informazioni su di lui, mediante
l’indirizzo IP, che identifica il suo dispositivo all’interno di una rete.
Il proxy serve, proprio, per evitare che ciò avvenga. Per capire al meglio il funzionamento di un proxy, dobbiamo immaginare una pallina che rimbalza all’infinito da
una parte all’altra; ovviamente, nel contesto informatico, ciò che rimbalza è l’indirizzo IP, che si muove da una parte all’altra del mondo e, per questo, risulta difficile
da rintracciare.
In rete troviamo tantissimi programmi che ci vengono indicati come ottimi proxy,
i quali trasformano magicamente gli indirizzi IP reali in falsi IP americani, cinesi o
francesi.
Tramite Splunk, non è possibile risolvere un problema di questo tipo.
6.3 Best Practice e Lessons Learned
L’obiettivo di questo lavoro di tesi è stato quello di riuscire ad analizzare decine di
GB di log in formato grezzo ed ottenere informazioni utili ai fini della sicurezza.
Le procedure o le azioni più significative, che hanno permesso di raggiungere tali
obiettivi, sono riassunte qui di seguito.
Innanzitutto, quando ci si trova davanti a dei log da analizzare, la prima cosa
da fare è, indubbiamente, studiare il loro formato e la loro struttura, in quanto
ciascuno dei campi di cui è composto il log, fornisce informazioni differenti.
Ogni log generato dal firewall Cisco ha un determinato codice identificativo. Il
suo formato e le informazioni contenute nei diversi log dipendono da tale codice. In
sostanza, per ogni codice, avremo un log che contiene diverse informazioni e, quindi,
un log con una diversa struttura.
Per tale motivo, è necessario subito capire quanti e quali codici identificativi
contengono i file da analizzare, studiarsi cosa indica ogni codice e decidere quali
eventi, relativi ad un determinato codice, analizzare.
Nel nostro caso, i log contenevano i codici 106100, 302103 e 302014. Quindi,
abbiamo eseguito tre diverse query, ciascuna delle quali cercava gli eventi relativi
solo ad uno di questi codici; alla fine, sono stati estratti tre file CSV, ciascuno
relativo ad un codice. A questo punto, abbiamo importato nuovamente in Splunk il
file CSV relativo al codice di nostro interesse.
Le analisi sono state effettuate sugli eventi relativi al codice 106100 (la struttura
del log relativa a tale codice è stata spiegata in dettaglio nel Capitolo 1).
Conoscere i campi di cui è composto il log è necessario per capire quali informazioni si possono estrarre e, quindi, per poter indirizzare le analisi su un aspetto
piuttosto che su un altro.
6.3 Best Practice e Lessons Learned
95
Infatti, in base alle analisi da compiere e ai risultati che si vogliono raggiungere,
si può utilizzare solo un sottoinsieme dei campi.
I log scritti dai vari sistemi contengono, usualmente, una grande mole di informazioni. Nel nostro caso, non c’è stata una richiesta specifica da parte di un
committente, come, ad esempio, soffermarsi, solo sulle connessioni provenienti da
un paese, e, quindi, le analisi sono state effettuate esaminando e correlando tra di
loro tutti i campi in linea generale.
Lo step immediatamente successivo all’interpretazione dei log, è stato il caricamento dei dati in Splunk. Durante questa fase sono stati riscontrati alcuni problemi,
perchè, inizialmente, i dati erano stati caricati da interfaccia web e, considerata la
loro dimensione, Splunk ci segnalava il seguente errore: “The minimum free disk space (5000 MB) reached for /opt/splunk/var/run/splunk/dispatch.”, come mostra la
Figura 6.5.
Figura 6.5. Errore riscontrato durante il caricamento dei log in Splunk web
Dopo aver consultato la documentazione di Splunk, siamo riusciti ad aggirare il
problema, caricando i dati, da terminale Linux, nella cartella batch.
Questo, però, non ci ha permesso di selezionare il sourcetype dei file caricati;
a causa di ciò Splunk, automaticamente, ha assegnato un sourcetype di default; in
particolare, agli error log ha associato il sourcetype “access combined”, tipico dei
log di accesso. Il sourcetype determina il modo con cui Splunk Enterprise formatta
i dati durante il processo di indicizzazione. In sostanza, esso determina la struttura
dei dati di un evento.
96
6 Discussione
Il fatto che Splunk abbia assegnato automaticamente il sourcetype ai file ha
avuto implicazioni negative sull’estrazione dei campi, in quanto i log, essendo stati
formattati con una struttura diversa, nel momento in cui si andava a selezionare un
campione per effettuare l’estrazione dei campi, quest’ultima coinvolgeva solo i log
che avevano lo stesso sourcetype del campione selezionato e, dunque, la rimanente
parte di log non veniva coinvolta.
Inoltre, a volte, Splunk non riusciva ad effettuare l’estrazione dei campi di tutti
i log caricati nel software e, dunque, se la query veniva effettuata su determinati
campi e questi erano stati estratti solo per una parte dei file, mentre l’altra parte
dei log non era stata coinvolta nell’estrazione, le analisi risultavano falsate. Per
rimediare a tale incoveniente, una volta che ci si è resi conto che c’era qualcosa
che non quadrava rispetto ad altre analisi, è stato necessario effettuare un’ulteriore
estrazione dei campi per i file esclusi dalla precedente estrazione. Ovviamente i
nuovi campi estratti sono stati chiamati con lo stesso nome dei campi estratti in
precedenza.
In ogni ricerca abbiamo utilizzato comandi diversi del linguaggio SPL, in base
a quello che si voleva ottenere. Quindi, è necessario dapprima studiare in linea
generale tutti i comandi che il linguaggio SPL mette a disposizione e, poi, si devono
scegliere quelli che permettono di ottenere gli obiettivi prefissati.
6.4 Generalizzabilità dell’approccio
In questo lavoro di tesi sono state effettuate le analisi dei log di accesso al firewall
Cisco (il cui logo è mostrato in Figura 6.6) dell’Università “Mediterranea”di Reggio
Calabria e dei log di accesso e di errore al server web Apache (il cui logo è mostrato
in Figura 6.7).
Figura 6.6. Logo Cisco
Ogni log generato dal firewall Cisco ha un determinato codice identificativo e
il formato e le informazioni contenute nei diversi log dipendono da tale codice. In
sostanza, per ogni diverso codice identificativo, avremo un log che contiene diverse
informazioni e, quindi, log con una diversa struttura.
In questa tesi ci siamo soffermati sull’analisi dei log del firewall che hanno il
codice identificativo 106100. I log con tale codice vengono generati ogni volta che
un pacchetto non corrisponde ad una connessione esistente e contiene determinate
informazioni.
6.4 Generalizzabilità dell’approccio
97
Figura 6.7. Logo di Apache
Però, i log generati dal firewall Cisco possono, anche, contenere eventi con altri codici identificativi. Ad esempio, nei nostri log c’erano anche i codici 302013 e
302014, che indicano, rispettivamente, che è stata creata e interrotta una connessione TCP tra due host.
Le analisi svolte in questo lavoro di tesi possono essere esattamente riprodotte
per i log generati da un firewall Cisco di un altro ente o di un’altra organizzazione
che hanno lo stesso codice identificativo (106100). Invece, se il codice identificativo
è diverso da 106100, il formato dei log cambia, quindi cambiano le informazioni
contenute in esso e la sua struttura, la quale dovrà essere studiata al fine di capire
quali campi estrarre per compiere determinate analisi; una volta effettuato atle
studio, tutto può essere eseguito utilizzando la stessa procedura.
La questione è diversa se, invece, il firewall di un altro ente o organizzazione non
è della Cisco. In tal caso, è necessario studiarsi il formato dei log generati da quel
determinato firewall e rifare lo studio di fattibilità.
Per quanto riguarda i log di errore e di accesso al server web vale la stessa
cosa, ossia se l’ente o l’organizzazione utilizza un web server Apache, allora si può
utilizzare l’approccio usato in questo lavoro di tesi. Altrimenti si deve rifare, anche in
questo caso, lo studio di fattibilità, in quanto il formato dei log, generati da un altro
server, potrebbe essere più o meno dettagliato rispetto al formato dei log generati
dal server Apache e, quindi, potrebbe contenere, ad esempio, campi aggiuntivi che
permetterebbero di trovare altre informazioni.
Ovviamente, se i log sono diversi rispetto a quelli analizzati da noi, è possibile
trovare app o add-on specifici per condurre le analisi su quella determinata tipologia
di log, oppure utilizzare comandi SPL diversi e visualizzazioni ad hoc per quei dati.
7
Conclusioni
In questo lavoro di tesi sono stati analizzati i log di accesso e di errore al server
web e i log di accesso al firewall dell’Università “Mediterranea”di Reggio Calabria
al fine di individuare eventuali attacchi informatici.
In una prima fase è stat condotta un’analisi descrittiva dei log, per l’estrazione
di conoscenza diagnostica; successivamente, è stata effettuata l’anomaly detection al
fine di rilevare le intrusioni, in quanto infrangere la sicurezza di un sistema comporta,
spesso, un uso anormale dello stesso e, quindi, eventuali attacchi informatici possono
essre rilevati cercando le attività che si differenzino dal normale comportamento.
Grazie alle attività condotte con la presente tesi siamo riusciti a:
•
•
•
•
•
•
•
trovare quali sono gli indirizzi IP che, nel mese di Ottobre 2016 hanno effettuato
più collegamenti al firewall e al server ed a consocere la loro provenienza;
capire quale protocollo è stato utilizzato dagli indirizzi IP per la connessione;
capire se queste connessioni sono state accettate o negate dal firewall;
conoscere quali sono state le risorse più richieste al server web nonchè i sistemi
operativi e i dispositivi più utilizzati per accedere ad esso;
conoscere quali sono i relativi codici di stato di una richiesta al web server;
trovare gli errori scaturiti da una determiata richiesta al web server;
rilevare, tramite l’app “Machine Learning Toolkit”, le anomalie, ossia le attività
che si differenziano dal normale comportamento e in modo tale da comprendere
quali possono essere stati gli indirizzi IP che hanno effettuato tentativi di port
scanning e, quindi, di intrusione.
Dalle analisi svolte è stata rilevata l’efficacia di Splunk nell’individuare possibili
minacce. In futuro, potrebbe essere effettuata l’analisi predittiva al fine di prevenire
e rispondere alle intrusioni e di identificare potenziali rischi. L’analisi predittiva,
poi, costituisce il punto di partenza per quella prescrittiva, che definisce indicazioni
concrete sulle azioni da intraprendere.
Riferimenti bibliografici
1. Intrusion detection e analisi dei log. http://openskill.info/topic.php?ID=160,
2003.
2. ABC della sicurezza: SIEM (Security Information and Event Management).
https://www.luigicristiani.it/abc-della-sicurezza-siem-securityinformation-and-event-management.html, 2017.
3. Apache. https://httpd.apache.org/, 2017.
4. Cisco. http://www.cisco.com/c/it_it/index.html, 2017.
5. Detect Numeric Outliers. http://docs.splunk.com/Documentation/MLApp/2.0.1/
User/DetectNumericOutliers, 2017.
6. Docker-Splunk.
https://github.com/splunk/docker-splunk/blob/master/
enterprise/README.md, 2017.
7. Get Docker for Ubuntu. https://docs.docker.com/engine/installation/linux/
ubuntu/, 2017.
8. Log Files. https://httpd.apache.org/docs/2.4/logs.html, 2017.
9. Scarica Splunk Enterprise.
https://www.splunk.com/it_it/download/splunkenterprise.html, 2017.
10. Splunk Architecture. http://www.splunk.com/view/SP-CAAABF9, 2017.
11. System Log Messages. http://www.cisco.com/en/US/docs/security/asa/asa80/
system/message/logmsgs.html#wp4769049, 2017.
12. Using the Machine Learning Toolkit. http://docs.splunk.com/Documentation/
MLApp/2.0.1/User/Usetheapp, 2017.
13. What is Docker? https://www.docker.com/what-docker, 2017.
14. What is Splunk? https://www.splunk.com/, 2017.
15. C.C. Aggarwal. Outlier Analysis. Hardcover, 2016.
16. A. Bahga and V. Madisetti. Big Data, Data Science Analytics: An Hands-On
Approach. 2015.
17. D.K. Bhattacharyya and J.K. Kalita. Network Anomaly Detection: A Machine
Learning Perspective. Hardcover, 2013.
18. J. Dean. Big Data, Data Mining, and Machine Learning. Garzanti, 2014.
19. J. Diakun, P.R Johnson, and D. Mock. Splunk Operational Intelligence Cookbook.
Packt Publishing, 2014.
20. T. Dunning and E. Friedman. Practical Machine Learning: A New Look at Anomaly
Detection. Paperback, 2014.
21. G. Giuseppini. Microsoft Log Parser Toolkit: A Complete Toolkit for Microsoft’s
Undocumented Log Analysis Tool. Paperback, 2005.
22. Icon Group International. The 2018-2023 World Outlook for Security Information and
Event Management (SIEM). Paperback, 2012.
102
Riferimenti bibliografici
23. D. Krygowski and G.B. Asquith. Basic Well Log Analysis. Paperback, 2004.
24. D.R. Miller, S. Harris, A. Harper, S. Vandyke, and C. Blask. Security Information
and Event Management (SIEM) Implementation (Network Pro Library). Paperback,
2010.
25. J. Nickoloff. Docker in Action. Paperback, 2016.
26. A. Peicevic and M. Maslac. Splunk introduction. Paperback, 2016.
27. A.E. Thomas. Security Operations Center - Analyst Guide: SIEM Technology, Use
Cases and Practices. Paperback, 2016.
28. J. Turnbull. The Docker Book: Containerization is the new virtualization. Kindle
Edition, 2014.
29. A.K.T. Yadav. Advanced Splunk. 2016.
Ringraziamenti
Ringrazio, di cuore, il Professor Domenico Ursino, mio relatore, per la disponibilità
mostrata durante la preparazione di questo lavoro, sempre presente a dirimere i miei
dubbi in qualsiasi momento.
Ringrazio i miei genitori, da sempre mio grande punto di riferimento, per avermi motivata a studiare sin da bambina, per il sostegno morale ed economico, per
non avermi mai fatto mancare nulla per raggiungere questo straordinario traguardo
e per l’appoggio che mi avete dato durante tutto il mio percorso di studi. Grazie per
avermi incoraggiata nei momenti di sconforto e per avermi dato la forza di superare
gli ostacoli e le difficoltà che si sono presentate durante questo cammino.
Grazie a te papà, perchè mi hai fatto capire quali sono le cose importanti della
vita, perchè mi hai insegnato a non perdere mai di vista l’obiettivo. Grazie perchè
mi hai insegnato ad essere forte, grazie per avermi insegnato a non arrendermi mai
difronte alle difficoltà che la vita ci pone e per avermi insegnato che esiste una soluzione per ogni problema.
Grazie a te mamma, perchè mi hai sempre capita in ogni circostanza, hai compreso i miei stati d’animo e mi hai trasmesso la tranquillità di cui avevo bisogno.
Grazie perchè mi sei stata vicina in ogni momento.
Ringrazio mia sorella Dalila, per essermi stata sempre accanto e aver vissuto con me
tutti i momenti della mia vita. Grazie perchè mi hai sempre ascoltata, hai saputo
darmi i giusti consigli e, soprattutto, perchè mi hai sopportata.
Ringrazio, immensamente, il mio ragazzo Paolo che, più di chiunque altro, mi è
stato vicino, concretamente, durante tutto il percorso universitario. Grazie perchè
sei stato il mio punto di riferimento in ogni momento, grazie perchè ho sempre potuto contare su di te, grazie perchè ci sei sempre stato in tutti i momenti, belli e
brutti. Grazie perchè hai sempre creduto in me e perchè mi hai sempre dato forza,
facendomi capire che tutto sarebbe andato a finire per il meglio. Grazie per avermi
ascoltato, per avermi supportato e sopportata, con molta pazienza, durante tutti i
periodi “no”di questo cammino. Grazie per essere stato sempre comprensivo, nono-
104
Ringraziamenti
stante tutto.
Ringrazio i miei nonni. Un grazie particolare va a mia nonna Cetta, nonna speciale, presente in tutti i momenti importanti della mia vita. Grazie per avermi fatto
sentire sempre la tua vicinanza, perchè non è mai mancata una telefonata dopo ogni
esame e perchè mi hai sempre dimostrato, come nessuno mai, di essere orgogliosa
di me.
Rigrazio tutti i colleghi che mi hanno accompagnato in questi ultimi due anni;
grazie per aver condiviso insieme preoccupazioni, difficoltà e, soprattutto, risate. In
particolare, ringrazio la mia collega e amica Cecilia, per avermi sempre compresa
e per essermi stata vicina nei momenti di difficoltà, dandomi forza con le parole
giuste. Grazie, soprattutto, perchè mi hai fatto capire cosa voglia dire la parola
“amicizia”. Ringrazio Caterina, con la quale abbiamo condiviso solo l’ultimo periodo della vita universitaria, ma, anche in poco tempo, ha dimostrato di essere una
splendida persona, gentile, disponibile, premurosa e pronta a tendere la mano in
qualunque momento.
Ringrazio, infine, tutti coloro che hanno sempre creduto in me; quelli che ci sono
sempre stati e che mi hanno resa una persona migliore.