WEBVTT

00:00.270 --> 00:01.103
-: In questa lezione

00:01.103 --> 00:03.690
ci concentreremo sul monitoraggio e sull'auditing.

00:03.690 --> 00:05.343
Cominciamo con il monitoraggio.

00:05.343 --> 00:06.930
Quando parliamo di monitoraggio, uno

00:06.930 --> 00:09.090
dei compiti principali di un analista della sicurezza

00:09.090 --> 00:11.130
è proprio quello di monitorare la rete.

00:11.130 --> 00:12.150
Siamo come dei detective.

00:12.150 --> 00:13.350
Cerchiamo di eliminare tutto

00:13.350 --> 00:14.970
ciò che non sembra corretto e questo

00:14.970 --> 00:18.180
può essere fatto manualmente o in modo automatizzato.

00:18.180 --> 00:21.150
Ora, syslog è un protocollo che consente a diverse apparecchiature

00:21.150 --> 00:23.820
e applicazioni software di trasmettere i loro log o record

00:23.820 --> 00:26.520
di eventi a un server centralizzato.

00:26.520 --> 00:30.300
Ora syslog seguirà un modello client-server standard.

00:30.300 --> 00:33.030
Questo è lo standard definitivo per la registrazione

00:33.030 --> 00:35.490
di eventi da sistemi distribuiti in rete.

00:35.490 --> 00:38.820
Il syslog viene utilizzato in molti dei sistemi su cui

00:38.820 --> 00:40.950
si lavora quotidianamente.

00:40.950 --> 00:43.590
Ora syslog funziona sulla maggior parte dei sistemi operativi e sulla maggior

00:43.590 --> 00:45.270
parte delle apparecchiature di rete.

00:45.270 --> 00:47.310
Quindi, sia che si utilizzi un router Cisco, sia

00:47.310 --> 00:49.920
che si utilizzi una macchina Windows o un server Linux, tutti

00:49.920 --> 00:51.630
possono utilizzare il syslog.

00:51.630 --> 00:53.490
Ora, quando inviamo questi messaggi,

00:53.490 --> 00:55.920
che aspetto ha un messaggio syslog?

00:55.920 --> 00:58.860
Un messaggio syslog contiene un paio di cose.

00:58.860 --> 01:01.530
Contiene un codice PRI, che è un codice di priorità.

01:01.530 --> 01:04.410
Contiene un'intestazione e una parte di messaggio.

01:04.410 --> 01:05.610
Parliamo di ciascuno di essi.

01:05.610 --> 01:08.040
In primo luogo, abbiamo il codice PRI, la priorità,

01:08.040 --> 01:10.200
che verrà calcolata in base alla struttura

01:10.200 --> 01:12.450
e al livello di gravità dei dati.

01:12.450 --> 01:13.710
Poi, abbiamo un'intestazione

01:13.710 --> 01:15.570
che conterrà il timestamp dell'evento

01:15.570 --> 01:17.190
e il nome dell'host.

01:17.190 --> 01:20.160
Così sappiamo da dove proviene e che ora era.

01:20.160 --> 01:22.230
Infine, abbiamo la parte del messaggio, che

01:22.230 --> 01:24.360
contiene il processo di origine dell'evento

01:24.360 --> 01:27.330
e il relativo contenuto, in pratica quali dati sono accaduti e di

01:27.330 --> 01:28.560
cosa volete parlarci?

01:28.560 --> 01:30.570
E questa è l'idea della parte del messaggio.

01:30.570 --> 01:33.390
Questo è il nocciolo del messaggio.

01:33.390 --> 01:34.800
Ora, quando abbiamo trattato il

01:34.800 --> 01:37.770
syslog, ci sono un paio di svantaggi nella versione originale.

01:37.770 --> 01:40.230
Il protocollo originale si basava su UDP.

01:40.230 --> 01:42.990
Questo può causare problemi di consegna in caso di reti congestionate,

01:42.990 --> 01:45.510
perché UDP è un protocollo "fire and forget".

01:45.510 --> 01:46.920
Lo invia e non attende la risposta

01:46.920 --> 01:48.270
e la conferma.

01:48.270 --> 01:50.250
E quindi si presume che sia arrivato lì.

01:50.250 --> 01:51.420
Se la rete è congestionata,

01:51.420 --> 01:53.051
è possibile che i dati vengano interrotti

01:53.051 --> 01:55.500
e che quindi le informazioni non arrivino al server

01:55.500 --> 01:57.630
di log e non vengano registrate.

01:57.630 --> 01:59.760
All'inizio questo poteva andare bene, perché

01:59.760 --> 02:00.930
si dava per scontato che tutti

02:00.930 --> 02:02.520
i membri della rete fossero affidabili,

02:02.520 --> 02:04.080
ma oggi non è più così.

02:04.080 --> 02:05.760
Vogliamo assicurarci che i nostri dati arrivino a destinazione.

02:05.760 --> 02:07.920
Dovremo quindi trovare una soluzione a questo problema.

02:07.920 --> 02:09.690
La seconda cosa è che non ci sono molti

02:09.690 --> 02:11.640
controlli di sicurezza di base.

02:11.640 --> 02:14.070
Non c'era nulla come la crittografia o l'autenticazione

02:14.070 --> 02:16.080
inclusa di default in syslog.

02:16.080 --> 02:17.850
Anche questo era un altro inconveniente.

02:17.850 --> 02:20.250
Quindi, nelle moderne implementazioni di syslog, abbiamo

02:20.250 --> 02:21.750
corretto questi aspetti.

02:21.750 --> 02:23.220
A causa di questi problemi di sicurezza,

02:23.220 --> 02:25.590
le implementazioni di syslog più recenti hanno aggiunto molte

02:25.590 --> 02:27.510
caratteristiche e capacità diverse.

02:27.510 --> 02:29.400
E qui ne parleremo di un paio.

02:29.400 --> 02:32.460
Le prime implementazioni più recenti utilizzano il protocollo

02:32.460 --> 02:34.170
TCP per una consegna coerente.

02:34.170 --> 02:36.360
In questo modo, se la rete si congestiona e il messaggio

02:36.360 --> 02:37.770
non riesce ad arrivare a destinazione,

02:37.770 --> 02:39.600
il sistema lo riconsegnerà più volte perché

02:39.600 --> 02:41.220
utilizza il protocollo TCP.

02:41.220 --> 02:43.470
Il secondo miglioramento, le implementazioni

02:43.470 --> 02:46.230
più recenti, possono utilizzare TLS, o transport layer security,

02:46.230 --> 02:49.050
per crittografare i messaggi inviati ai server.

02:49.050 --> 02:50.760
In questo modo i dati in transito non possono

02:50.760 --> 02:52.580
essere letti da qualcun altro sulla rete.

02:52.580 --> 02:55.200
Può essere letto solo dall'endpoint che lo ha inviato

02:55.200 --> 02:57.510
e dal server che lo sta ricevendo.

02:57.510 --> 02:58.343
La terza cosa è

02:58.343 --> 03:02.130
che le implementazioni più recenti utilizzano anche MD5 e SHA1

03:02.130 --> 03:04.950
per fornire autenticazione e integrità.

03:04.950 --> 03:07.770
In questo modo i messaggi possono avere un'autenticazione e un'integrità

03:07.770 --> 03:10.080
del messaggio mentre transitano sulla vostra rete, per

03:10.080 --> 03:12.930
assicurarsi che non vengano manipolati da nessun altro.

03:12.930 --> 03:14.730
Anche in questo caso, molte altre funzioni.

03:14.730 --> 03:16.920
Non mi sto concentrando troppo su questo set,

03:16.920 --> 03:19.290
perché i tre principali che ci interessano sono

03:19.290 --> 03:21.900
passati a TCP per una consegna coerente.

03:21.900 --> 03:23.910
Siamo passati a TLS per la crittografia

03:23.910 --> 03:26.130
e abbiamo iniziato a usare MD5 e SHA1 per l'autenticazione

03:26.130 --> 03:28.050
e l'integrità.

03:28.050 --> 03:30.090
Questa nuova versione del server

03:30.090 --> 03:33.810
è solitamente chiamata syslog-ng, per syslog next generation,

03:33.810 --> 03:35.490
o rsyslog.

03:35.490 --> 03:37.470
L'ultima cosa che vorrei menzionare a proposito

03:37.470 --> 03:40.560
di syslog è che syslog viene spesso usato per indicare tre cose.

03:40.560 --> 03:43.380
Può riferirsi al protocollo con cui vengono inviati i dati.

03:43.380 --> 03:46.410
Può riferirsi al server, come nel caso di un server syslog,

03:46.410 --> 03:48.690
o può riferirsi alle voci di log stesse, come

03:48.690 --> 03:50.430
nel caso dei dati syslog.

03:50.430 --> 03:51.990
Spesso si dice semplicemente syslog

03:51.990 --> 03:54.090
e si intendono tutti e tre o uno qualsiasi di questi

03:54.090 --> 03:55.470
tre, a seconda del contesto.

03:55.470 --> 03:56.700
Quindi fate attenzione

03:56.700 --> 03:58.530
quando sentite parlare gli addetti

03:58.530 --> 03:59.790
ai lavori per assicurarvi

03:59.790 --> 04:01.860
di capire quale dei tre sta parlando

04:01.860 --> 04:03.810
di SNMP è il prossimo.

04:03.810 --> 04:06.900
SNMP è il protocollo di gestione della rete semplice.

04:06.900 --> 04:09.480
È un protocollo TCP che aiuta a monitorare i dispositivi

04:09.480 --> 04:12.000
e i computer collegati alla rete.

04:12.000 --> 04:14.520
SNMP è incorporato nei sistemi di gestione e monitoraggio

04:14.520 --> 04:16.830
della rete ed è molto utilizzato nel concetto

04:16.830 --> 04:18.840
di gestione e monitoraggio.

04:18.840 --> 04:21.870
SNMP è suddiviso in tre componenti.

04:21.870 --> 04:24.030
Ci sono i dispositivi gestiti, l'agente

04:24.030 --> 04:26.370
e i sistemi di gestione della rete stessi.

04:26.370 --> 04:28.020
Parliamo di dispositivi gestiti.

04:28.020 --> 04:30.510
Si tratta di computer e altri dispositivi collegati alla rete

04:30.510 --> 04:32.400
che vengono monitorati attraverso l'uso di agenti

04:32.400 --> 04:34.380
da un sistema di gestione della rete.

04:34.380 --> 04:37.560
Gli agenti sono software caricati su un dispositivo gestito.

04:37.560 --> 04:39.450
Questo ci permette di reindirizzare le informazioni

04:39.450 --> 04:41.040
al sistema di gestione della rete che si

04:41.040 --> 04:42.510
occuperà del monitoraggio.

04:42.510 --> 04:44.700
Il sistema di gestione della rete, o NMS,

04:44.700 --> 04:47.100
è il software eseguito su uno o più server che

04:47.100 --> 04:48.120
controlla il monitoraggio

04:48.120 --> 04:50.760
di tutti i dispositivi e i computer collegati alla

04:50.760 --> 04:52.230
rete.

04:52.230 --> 04:54.840
SNMP è il collante che fa dialogare tutti e tre

04:54.840 --> 04:58.080
questi elementi, utilizzando il protocollo SNMP.

04:58.080 --> 05:00.570
Come si presenta tutto questo all'interno della rete?

05:00.570 --> 05:03.180
Qui, sullo schermo, potete vedere un breve schema.

05:03.180 --> 05:05.910
A sinistra abbiamo la nostra stazione di gestione della rete,

05:05.910 --> 05:09.000
o NMS, che fa parte del nostro sistema di gestione della rete.

05:09.000 --> 05:10.830
Questo fungerà da manager e

05:10.830 --> 05:12.630
invierà e riceverà messaggi

05:12.630 --> 05:15.060
a tutti i dispositivi gestiti della rete,

05:15.060 --> 05:17.850
router, switch e server, giusto?

05:17.850 --> 05:19.290
Ora, quando vuole informazioni,

05:19.290 --> 05:20.860
invia una richiesta di tipo

05:20.860 --> 05:23.970
"get" e i dispositivi rispondono con una richiesta

05:23.970 --> 05:25.890
di tipo "set".

05:25.890 --> 05:27.960
Esiste anche una cosa chiamata richiesta di trappola,

05:27.960 --> 05:29.910
che riceve informazioni non richieste dai dispositivi

05:29.910 --> 05:31.320
di gestione, che inviano le informazioni

05:31.320 --> 05:34.440
necessarie a intervalli periodici.

05:34.440 --> 05:38.070
Quindi, quando si effettua la gestione della rete utilizzando SNMP,

05:38.070 --> 05:40.620
si hanno due opzioni per l'invio dei dati.

05:40.620 --> 05:42.690
È possibile inviarlo attraverso la rete

05:42.690 --> 05:44.670
in uso, il che è noto come comunicazione

05:44.670 --> 05:46.830
in-band, oppure inviarlo fuori banda.

05:46.830 --> 05:47.940
Quando si parla di in-band,

05:47.940 --> 05:49.890
significa che i dati di gestione vengono inviati

05:49.890 --> 05:51.810
sulla stessa rete che trasporta le informazioni

05:51.810 --> 05:54.120
aziendali e i dati normali.

05:54.120 --> 05:57.600
È più economico e più facile, ma è meno sicuro.

05:57.600 --> 05:58.710
Ora, per essere più sicuri,

05:58.710 --> 06:00.930
è necessario creare una rete fuori banda.

06:00.930 --> 06:02.760
Si tratta di una rete secondaria in

06:02.760 --> 06:04.560
cui avviene tutta la gestione, ma

06:04.560 --> 06:06.780
è ancora presente la rete primaria in-band

06:06.780 --> 06:08.940
in cui avvengono tutti i dati che gli utenti

06:08.940 --> 06:10.050
riceveranno.

06:10.050 --> 06:11.610
La gestione dovrebbe sempre essere

06:11.610 --> 06:14.490
condotta su una rete fuori banda, perché aumenta la sicurezza

06:14.490 --> 06:17.160
e porta la funzione di gestione fuori dal luogo in cui gli utenti

06:17.160 --> 06:18.993
possono toccarla o vederla.