WEBVTT

00:00.270 --> 00:01.103
-Nesta lição, vamos

00:01.103 --> 00:03.690
nos concentrar no monitoramento e na auditoria.

00:03.690 --> 00:05.343
Vamos começar com o monitoramento primeiro.

00:05.343 --> 00:06.930
Quando falamos em monitoramento,

00:06.930 --> 00:09.090
uma das principais tarefas de um analista de segurança

00:09.090 --> 00:11.130
é realmente monitorar a rede.

00:11.130 --> 00:12.150
Somos como detetives.

00:12.150 --> 00:13.350
Estamos tentando eliminar

00:13.350 --> 00:14.970
qualquer coisa que não pareça correta

00:14.970 --> 00:18.180
e isso pode ser feito manualmente ou por meios automatizados.

00:18.180 --> 00:21.150
Agora, o syslog é um protocolo que permite que diferentes dispositivos

00:21.150 --> 00:23.820
e aplicativos de software transmitam seus logs ou registros

00:23.820 --> 00:26.520
de eventos para um servidor centralizado.

00:26.520 --> 00:30.300
Agora, o syslog seguirá um modelo padrão de cliente-servidor.

00:30.300 --> 00:33.030
E esse é o padrão de fato para o registro de eventos

00:33.030 --> 00:35.490
de sistemas distribuídos em uma rede.

00:35.490 --> 00:38.820
Você verá o syslog em uso em muitos dos sistemas em

00:38.820 --> 00:40.950
que trabalhará diariamente.

00:40.950 --> 00:43.590
Atualmente, o syslog é executado na maioria dos sistemas operacionais

00:43.590 --> 00:45.270
e na maioria dos equipamentos de rede.

00:45.270 --> 00:47.310
Portanto, quer você esteja usando um roteador

00:47.310 --> 00:49.920
Cisco ou uma máquina Windows ou um servidor Linux, todos

00:49.920 --> 00:51.630
eles podem usar o syslog.

00:51.630 --> 00:53.490
Agora, quando enviamos essas mensagens

00:53.490 --> 00:55.920
de volta, qual é a aparência de uma mensagem syslog?

00:55.920 --> 00:58.860
Bem, uma mensagem de syslog conterá algumas coisas.

00:58.860 --> 01:01.530
Ele contém um código PRI, que é um código de prioridade.

01:01.530 --> 01:04.410
Ele contém um cabeçalho e uma parte da mensagem.

01:04.410 --> 01:05.610
Vamos falar sobre cada um deles.

01:05.610 --> 01:08.040
Primeiro, temos esse código PRI, essa prioridade,

01:08.040 --> 01:10.200
que será calculada com base na instalação

01:10.200 --> 01:12.450
e no nível de gravidade dos dados.

01:12.450 --> 01:13.710
Em seguida, temos um cabeçalho,

01:13.710 --> 01:15.570
que conterá o registro de data e hora do

01:15.570 --> 01:17.190
evento e o nome do host.

01:17.190 --> 01:20.160
Portanto, sabemos de onde veio e em que época foi.

01:20.160 --> 01:22.230
E, por fim, temos a parte da mensagem, que contém

01:22.230 --> 01:24.360
o processo de origem do evento e o conteúdo relacionado,

01:24.360 --> 01:27.330
basicamente quais dados aconteceram e sobre o que você quer nos

01:27.330 --> 01:28.560
contar?

01:28.560 --> 01:30.570
E essa é a ideia aqui com a parte da mensagem.

01:30.570 --> 01:33.390
Essa é a essência desta mensagem.

01:33.390 --> 01:34.800
Agora, quando tratamos do

01:34.800 --> 01:37.770
syslog, há algumas desvantagens na versão original.

01:37.770 --> 01:40.230
O protocolo original se baseava no UDP.

01:40.230 --> 01:42.990
Isso pode causar problemas de entrega em redes congestionadas

01:42.990 --> 01:45.510
porque o UDP é um protocolo do tipo "dispare e esqueça".

01:45.510 --> 01:46.920
Ele o envia e não espera pela resposta

01:46.920 --> 01:48.270
e pelo reconhecimento.

01:48.270 --> 01:50.250
Assim, ele simplesmente presume que chegou lá.

01:50.250 --> 01:51.420
Se a rede estiver congestionada,

01:51.420 --> 01:53.051
os dados poderão ser descartados e,

01:53.051 --> 01:55.500
portanto, as informações não chegarão ao servidor de

01:55.500 --> 01:57.630
registro e não serão registradas.

01:57.630 --> 01:59.760
Nos primórdios, isso pode ter sido aceitável, porque

01:59.760 --> 02:00.930
as pessoas presumiam que todos

02:00.930 --> 02:02.520
em sua rede eram confiáveis, mas hoje

02:02.520 --> 02:04.080
em dia não queremos isso.

02:04.080 --> 02:05.760
Queremos garantir que nossos dados cheguem lá.

02:05.760 --> 02:07.920
Portanto, teremos que encontrar uma solução para isso.

02:07.920 --> 02:09.690
A segunda coisa é que não há muitos

02:09.690 --> 02:11.640
controles básicos de segurança.

02:11.640 --> 02:14.070
Não havia nada como criptografia ou autenticação

02:14.070 --> 02:16.080
incluído por padrão no syslog.

02:16.080 --> 02:17.850
E isso também foi outra desvantagem.

02:17.850 --> 02:20.250
Portanto, nas implementações modernas do syslog,

02:20.250 --> 02:21.750
corrigimos esses problemas.

02:21.750 --> 02:23.220
Agora, devido a esses problemas de segurança,

02:23.220 --> 02:25.590
nossas implementações mais recentes de syslog adicionaram muitos

02:25.590 --> 02:27.510
recursos e capacidades diferentes.

02:27.510 --> 02:29.400
E vamos falar sobre alguns deles aqui.

02:29.400 --> 02:32.460
As primeiras implementações mais recentes usam o TCP

02:32.460 --> 02:34.170
para entrega consistente.

02:34.170 --> 02:36.360
Dessa forma, se a rede ficar congestionada

02:36.360 --> 02:37.770
e a mensagem não puder chegar,

02:37.770 --> 02:39.600
ela será reenviada várias vezes,

02:39.600 --> 02:41.220
pois está usando TCP.

02:41.220 --> 02:43.470
O segundo aprimoramento, as implementações mais

02:43.470 --> 02:46.230
recentes, podem usar TLS, ou segurança da camada de transporte,

02:46.230 --> 02:49.050
para criptografar as mensagens enviadas aos servidores.

02:49.050 --> 02:50.760
Dessa forma, os dados em trânsito não podem

02:50.760 --> 02:52.580
ser lidos por outra pessoa na rede.

02:52.580 --> 02:55.200
Ele só pode ser lido pelo ponto de extremidade que o

02:55.200 --> 02:57.510
enviou e pelo servidor que o está recebendo.

02:57.510 --> 02:58.343
O terceiro aspecto

02:58.343 --> 03:02.130
é que as implementações mais recentes também usam MD5 e SHA1 para

03:02.130 --> 03:04.950
fornecer autenticação e integridade.

03:04.950 --> 03:07.770
Dessa forma, as mensagens podem ter autenticação e integridade

03:07.770 --> 03:10.080
de mensagens enquanto transitam pela sua rede para

03:10.080 --> 03:12.930
garantir que não sejam manipuladas por ninguém.

03:12.930 --> 03:14.730
Novamente, muitos outros recursos.

03:14.730 --> 03:16.920
No entanto, não estou me concentrando muito nesse conjunto

03:16.920 --> 03:19.290
porque, na verdade, o que nos interessa são os três grandes itens

03:19.290 --> 03:21.900
que mudamos para o TCP para obter uma entrega consistente.

03:21.900 --> 03:23.910
Mudamos para o TLS para criptografia

03:23.910 --> 03:26.130
e começamos a usar MD5 e SHA1 para autenticação

03:26.130 --> 03:28.050
e integridade.

03:28.050 --> 03:30.090
Agora, essa versão mais recente do

03:30.090 --> 03:33.810
servidor é normalmente chamada de syslog-ng, para syslog next

03:33.810 --> 03:35.490
generation, ou rsyslog.

03:35.490 --> 03:37.470
Agora, o último aspecto que quero mencionar sobre

03:37.470 --> 03:40.560
o syslog é que ele é frequentemente usado para significar três coisas.

03:40.560 --> 03:43.380
Ele pode se referir ao protocolo pelo qual enviamos os dados.

03:43.380 --> 03:46.410
Ele pode se referir ao servidor, como em um servidor syslog,

03:46.410 --> 03:48.690
ou pode se referir às entradas de registro

03:48.690 --> 03:50.430
em si, como em dados syslog.

03:50.430 --> 03:51.990
Muitas vezes, as pessoas dizem apenas syslog

03:51.990 --> 03:54.090
e estão se referindo a todos os três, ou a qualquer um deles,

03:54.090 --> 03:55.470
dependendo do contexto.

03:55.470 --> 03:56.700
Portanto, tenha cuidado

03:56.700 --> 03:58.530
ao ouvir as pessoas falando sobre o setor,

03:58.530 --> 03:59.790
para ter certeza de que você

03:59.790 --> 04:01.860
entendeu qual dos três eles estão falando

04:01.860 --> 04:03.810
sobre SNMP, que é o próximo.

04:03.810 --> 04:06.900
SNMP é o protocolo de gerenciamento de rede simples.

04:06.900 --> 04:09.480
É um protocolo TCP que auxilia no monitoramento de

04:09.480 --> 04:12.000
dispositivos e computadores conectados à rede.

04:12.000 --> 04:14.520
O SNMP é incorporado aos sistemas de gerenciamento

04:14.520 --> 04:16.830
e monitoramento de rede e é muito usado no conceito

04:16.830 --> 04:18.840
de gerenciamento e monitoramento.

04:18.840 --> 04:21.870
O SNMP é dividido em três componentes.

04:21.870 --> 04:24.030
Há os dispositivos gerenciados, o agente e os

04:24.030 --> 04:26.370
próprios sistemas de gerenciamento de rede.

04:26.370 --> 04:28.020
Falamos sobre dispositivos gerenciados.

04:28.020 --> 04:30.510
Trata-se de computadores e outros dispositivos conectados

04:30.510 --> 04:32.400
à rede que são monitorados por meio do uso de agentes

04:32.400 --> 04:34.380
por um sistema de gerenciamento de rede.

04:34.380 --> 04:37.560
Os agentes são softwares carregados em um dispositivo gerenciado.

04:37.560 --> 04:39.450
E isso nos permite redirecionar as informações

04:39.450 --> 04:41.040
para o sistema de gerenciamento de rede

04:41.040 --> 04:42.510
que fará o monitoramento.

04:42.510 --> 04:44.700
E um sistema de gerenciamento de rede, ou NMS,

04:44.700 --> 04:47.100
é o software executado em um ou mais servidores que

04:47.100 --> 04:48.120
controla o monitoramento

04:48.120 --> 04:50.760
de todos os dispositivos e computadores conectados à

04:50.760 --> 04:52.230
rede em toda a rede.

04:52.230 --> 04:54.840
O SNMP é a cola que faz com que todos esses três elementos

04:54.840 --> 04:58.080
se comuniquem entre si, usando o protocolo SNMP.

04:58.080 --> 05:00.570
Então, como fica tudo isso dentro da rede?

05:00.570 --> 05:03.180
Bem, aqui na tela, você pode ver um breve diagrama.

05:03.180 --> 05:05.910
À esquerda, temos nossa estação de gerenciamento de rede,

05:05.910 --> 05:09.000
ou NMS, que faz parte do nosso sistema de gerenciamento de rede.

05:09.000 --> 05:10.830
Ele atuará como nosso gerente e enviará

05:10.830 --> 05:12.630
e receberá mensagens para todos os

05:12.630 --> 05:15.060
dispositivos gerenciados na rede, seus roteadores,

05:15.060 --> 05:17.850
seus switches e seus servidores, certo?

05:17.850 --> 05:19.290
Agora, quando ele quiser informações,

05:19.290 --> 05:20.860
enviará uma solicitação de obtenção

05:20.860 --> 05:23.970
e, em seguida, esses dispositivos enviarão informações de volta usando

05:23.970 --> 05:25.890
uma solicitação de configuração.

05:25.890 --> 05:27.960
Agora, há também algo chamado solicitação de armadilha,

05:27.960 --> 05:29.910
que receberá informações não solicitadas desses dispositivos

05:29.910 --> 05:31.320
de gerenciamento, em que eles apenas enviam

05:31.320 --> 05:32.970
informações conforme necessário em intervalos

05:32.970 --> 05:34.440
periódicos.

05:34.440 --> 05:38.070
Portanto, ao realizar todo esse gerenciamento de rede usando o SNMP, você

05:38.070 --> 05:40.620
tem duas opções de onde os dados podem ser enviados.

05:40.620 --> 05:42.690
Você pode enviá-la pela rede que está usando,

05:42.690 --> 05:44.670
o que é conhecido como comunicação dentro

05:44.670 --> 05:46.830
da banda, ou pode enviá-la fora da banda.

05:46.830 --> 05:47.940
Agora, quando você faz in-band,

05:47.940 --> 05:49.890
isso significa que enviará esses dados de gerenciamento

05:49.890 --> 05:51.810
pela mesma rede que transporta suas informações

05:51.810 --> 05:54.120
corporativas e dados normais.

05:54.120 --> 05:57.600
Isso é mais barato e mais fácil, mas é menos seguro.

05:57.600 --> 05:58.710
Agora, para ter mais segurança,

05:58.710 --> 06:00.930
você deve criar uma rede fora da banda.

06:00.930 --> 06:02.760
Essa é uma rede secundária em que

06:02.760 --> 06:04.560
ocorre todo o gerenciamento, mas

06:04.560 --> 06:06.780
você ainda tem a rede primária em banda em

06:06.780 --> 06:08.940
que ocorrem todos os dados que os usuários

06:08.940 --> 06:10.050
receberão.

06:10.050 --> 06:11.610
O gerenciamento sempre deve ser

06:11.610 --> 06:14.490
realizado em uma rede fora de banda, pois aumenta a segurança

06:14.490 --> 06:17.160
e retira a função de gerenciamento do local onde os usuários

06:17.160 --> 06:18.993
podem tocá-la ou vê-la.