WEBVTT

00:00.270 --> 00:01.103
-: En esta lección

00:01.103 --> 00:03.690
vamos a centrarnos en la supervisión y la auditoría.

00:03.690 --> 00:05.343
Empecemos por la supervisión.

00:05.343 --> 00:06.930
Cuando hablamos de supervisión, uno

00:06.930 --> 00:09.090
de los principales trabajos de un analista de seguridad

00:09.090 --> 00:11.130
es realmente supervisar la red.

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

00:12.150 --> 00:13.350
Intentamos eliminar todo

00:13.350 --> 00:14.970
lo que no nos parece correcto, y

00:14.970 --> 00:18.180
esto puede hacerse manualmente o de forma automatizada.

00:18.180 --> 00:21.150
En la actualidad, syslog es un protocolo que permite a distintos

00:21.150 --> 00:23.820
aparatos y aplicaciones de software transmitir sus logs

00:23.820 --> 00:26.520
o registros de eventos a un servidor centralizado.

00:26.520 --> 00:30.300
Ahora syslog va a seguir un modelo cliente servidor estándar.

00:30.300 --> 00:33.030
Y este es el estándar de facto para el registro de eventos

00:33.030 --> 00:35.490
de sistemas distribuidos a través de una red.

00:35.490 --> 00:38.820
Vas a ver syslog en uso en muchos de los sistemas en

00:38.820 --> 00:40.950
los que vas a trabajar a diario.

00:40.950 --> 00:43.590
Ahora syslog funciona en la mayoría de los sistemas operativos

00:43.590 --> 00:45.270
y en la mayoría de los equipos de red.

00:45.270 --> 00:47.310
Así que tanto si utilizas un router Cisco como

00:47.310 --> 00:49.920
si usas una máquina Windows o un servidor Linux, todos

00:49.920 --> 00:51.630
ellos pueden utilizar syslog.

00:51.630 --> 00:53.490
Ahora, cuando devolvemos estos mensajes,

00:53.490 --> 00:55.920
¿qué aspecto tiene un mensaje syslog?

00:55.920 --> 00:58.860
Bueno, un mensaje syslog va a contener un par de cosas.

00:58.860 --> 01:01.530
Contiene un código PRI, que es un código de prioridad.

01:01.530 --> 01:04.410
Contiene una cabecera y una parte de mensaje.

01:04.410 --> 01:05.610
Hablemos de cada uno de ellos.

01:05.610 --> 01:08.040
En primer lugar, tenemos este código PRI, esta prioridad,

01:08.040 --> 01:10.200
y esto va a ser calculado sobre la base de la instalación

01:10.200 --> 01:12.450
y el nivel de gravedad de los datos.

01:12.450 --> 01:13.710
A continuación, tenemos un encabezado

01:13.710 --> 01:15.570
y el encabezado va a contener la marca de tiempo

01:15.570 --> 01:17.190
del evento y el nombre del host.

01:17.190 --> 01:20.160
Así que sabemos de dónde vino y qué hora era.

01:20.160 --> 01:22.230
Y, por último, tenemos la parte del mensaje, que

01:22.230 --> 01:24.360
contiene el proceso de origen del evento y el contenido

01:24.360 --> 01:27.330
relacionado, básicamente qué datos han sucedido y sobre qué nos quiere

01:27.330 --> 01:28.560
informar.

01:28.560 --> 01:30.570
Y esa es la idea aquí con la parte del mensaje.

01:30.570 --> 01:33.390
Este es el meollo de este mensaje.

01:33.390 --> 01:34.800
Ahora, cuando nos ocupamos de

01:34.800 --> 01:37.770
syslog, hay un par de inconvenientes en la versión original.

01:37.770 --> 01:40.230
El protocolo original se basaba en UDP.

01:40.230 --> 01:42.990
Ahora bien, esto puede causar problemas de entrega en redes congestionadas

01:42.990 --> 01:45.510
porque UDP es un protocolo de "disparar y olvidar".

01:45.510 --> 01:46.920
Lo envía y no espera respuesta

01:46.920 --> 01:48.270
ni acuse de recibo.

01:48.270 --> 01:50.250
Y entonces simplemente asume que llegó allí.

01:50.250 --> 01:51.420
Si usted tiene una red congestionada,

01:51.420 --> 01:53.051
puede tener datos que se están cayendo

01:53.051 --> 01:55.500
y por lo tanto su información no va a llegar al servidor

01:55.500 --> 01:57.630
de registro y no se registrará.

01:57.630 --> 01:59.760
Al principio, esto podía estar bien, porque la

01:59.760 --> 02:00.930
gente asumía que todos los

02:00.930 --> 02:02.520
miembros de la red eran de confianza,

02:02.520 --> 02:04.080
pero hoy en día no queremos eso.

02:04.080 --> 02:05.760
Queremos asegurarnos de que nuestros datos llegan allí.

02:05.760 --> 02:07.920
Así que vamos a tener que encontrar una solución para esto.

02:07.920 --> 02:09.690
Lo segundo es que no hay muchos controles

02:09.690 --> 02:11.640
de seguridad básicos.

02:11.640 --> 02:14.070
No había nada como encriptación o autenticación

02:14.070 --> 02:16.080
incluido por defecto con syslog.

02:16.080 --> 02:17.850
Y esto también era otro inconveniente.

02:17.850 --> 02:20.250
Así que en las implementaciones modernas de syslog,

02:20.250 --> 02:21.750
hemos corregido estas cosas.

02:21.750 --> 02:23.220
Ahora, debido a estos problemas de seguridad,

02:23.220 --> 02:25.590
nuestras implementaciones de syslog más recientes han añadido un montón

02:25.590 --> 02:27.510
de características y capacidades diferentes.

02:27.510 --> 02:29.400
Y aquí vamos a hablar de un par de ellas.

02:29.400 --> 02:32.460
En primer lugar, las nuevas implementaciones utilizan TCP

02:32.460 --> 02:34.170
para una entrega coherente.

02:34.170 --> 02:36.360
De esta forma, si la red se congestiona y ese

02:36.360 --> 02:37.770
mensaje no puede llegar, lo

02:37.770 --> 02:39.600
volverá a entregar una y otra vez porque

02:39.600 --> 02:41.220
está utilizando TCP.

02:41.220 --> 02:43.470
La segunda mejora, las implementaciones más recientes,

02:43.470 --> 02:46.230
pueden utilizar TLS, o seguridad de la capa de transporte, para

02:46.230 --> 02:49.050
cifrar los mensajes que se envían a los servidores.

02:49.050 --> 02:50.760
De ese modo, los datos en tránsito no pueden

02:50.760 --> 02:52.580
ser leídos por otra persona en la red.

02:52.580 --> 02:55.200
Sólo puede ser leído por el endpoint que lo

02:55.200 --> 02:57.510
envió y el servidor que lo recibe.

02:57.510 --> 02:58.343
Lo tercero es que

02:58.343 --> 03:02.130
las implementaciones más recientes también utilizan MD5 y SHA1 para

03:02.130 --> 03:04.950
proporcionar autenticación e integridad.

03:04.950 --> 03:07.770
De este modo, los mensajes pueden tener autenticación

03:07.770 --> 03:10.080
e integridad mientras transitan por tu red

03:10.080 --> 03:12.930
para asegurarte de que nadie los manipula.

03:12.930 --> 03:14.730
De nuevo, muchas otras características.

03:14.730 --> 03:16.920
Pero no me voy a centrar demasiado en este conjunto,

03:16.920 --> 03:19.290
porque realmente los tres grandes que nos importan es

03:19.290 --> 03:21.900
que hemos pasado a TCP para una entrega consistente.

03:21.900 --> 03:23.910
Hemos pasado a TLS para el cifrado, y

03:23.910 --> 03:26.130
empezamos a utilizar MD5 y SHA1 para la autenticación

03:26.130 --> 03:28.050
y la integridad.

03:28.050 --> 03:30.090
Ahora, esta nueva versión del servidor

03:30.090 --> 03:33.810
suele denominarse syslog-ng, por syslog next generation,

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

03:35.490 --> 03:37.470
Ahora, lo último que quiero mencionar sobre

03:37.470 --> 03:40.560
syslog es que syslog se utiliza a menudo para significar tres cosas.

03:40.560 --> 03:43.380
Puede referirse al protocolo por el que enviamos los datos.

03:43.380 --> 03:46.410
Puede referirse al servidor, como en un servidor syslog, o

03:46.410 --> 03:48.690
puede referirse a las propias entradas de registro,

03:48.690 --> 03:50.430
como en los datos syslog.

03:50.430 --> 03:51.990
La gente a menudo dice simplemente syslog

03:51.990 --> 03:54.090
y se refiere a los tres, o a cualquiera de estos tres,

03:54.090 --> 03:55.470
dependiendo del contexto.

03:55.470 --> 03:56.700
Así que ten cuidado con eso

03:56.700 --> 03:58.530
cuando escuches a la gente hablar en la

03:58.530 --> 03:59.790
industria para asegurarte

03:59.790 --> 04:01.860
de que entiendes cuál de los tres están hablando

04:01.860 --> 04:03.810
de SNMP es el siguiente.

04:03.810 --> 04:06.900
SNMP es el protocolo simple de gestión de redes.

04:06.900 --> 04:09.480
Es un protocolo TCP que ayuda a supervisar los dispositivos

04:09.480 --> 04:12.000
y ordenadores conectados a la red.

04:12.000 --> 04:14.520
SNMP está incorporado en los sistemas de gestión y monitorización

04:14.520 --> 04:16.830
de redes y se utiliza mucho en el concepto de gestión

04:16.830 --> 04:18.840
y monitorización.

04:18.840 --> 04:21.870
SNMP se divide en tres componentes.

04:21.870 --> 04:24.030
Están los dispositivos gestionados, el agente

04:24.030 --> 04:26.370
y los propios sistemas de gestión de red.

04:26.370 --> 04:28.020
Hablamos de dispositivos gestionados.

04:28.020 --> 04:30.510
Se trata de ordenadores y otros dispositivos conectados

04:30.510 --> 04:32.400
a la red que son supervisados mediante el uso

04:32.400 --> 04:34.380
de agentes por un sistema de gestión de red.

04:34.380 --> 04:37.560
Los agentes son software que se carga en un dispositivo gestionado.

04:37.560 --> 04:39.450
Y esto nos permite redirigir la información

04:39.450 --> 04:41.040
al sistema de gestión de red que va a

04:41.040 --> 04:42.510
realizar la supervisión.

04:42.510 --> 04:44.700
Y un sistema de gestión de red, o NMS, es el software

04:44.700 --> 04:47.100
que se ejecuta en uno o varios servidores y que

04:47.100 --> 04:48.120
controla la supervisión

04:48.120 --> 04:50.760
de todos los dispositivos y ordenadores conectados

04:50.760 --> 04:52.230
a la red.

04:52.230 --> 04:54.840
SNMP es el pegamento que hace que los tres se

04:54.840 --> 04:58.080
comuniquen entre sí, utilizando el protocolo SNMP.

04:58.080 --> 05:00.570
¿Qué aspecto tiene todo esto dentro de la red?

05:00.570 --> 05:03.180
Bueno, aquí en la pantalla, se puede ver un breve diagrama.

05:03.180 --> 05:05.910
A la izquierda tenemos nuestra estación de gestión de red,

05:05.910 --> 05:09.000
o NMS, que forma parte de nuestro sistema de gestión de red.

05:09.000 --> 05:10.830
Esto va a actuar como nuestro gestor y

05:10.830 --> 05:12.630
va a enviar y recibir mensajes a todos

05:12.630 --> 05:15.060
los dispositivos gestionados a través de la red,

05:15.060 --> 05:17.850
tus routers, tus switches y tus servidores, ¿verdad?

05:17.850 --> 05:19.290
Ahora, cuando quiera información,

05:19.290 --> 05:20.860
enviará una petición get, y entonces

05:20.860 --> 05:23.970
esos dispositivos enviarán información de vuelta usando

05:23.970 --> 05:25.890
una petición set.

05:25.890 --> 05:27.960
Ahora también hay algo llamado solicitud de trampa,

05:27.960 --> 05:29.910
que va a recibir información no solicitada de esos

05:29.910 --> 05:31.320
dispositivos de gestión, donde sólo

05:31.320 --> 05:32.970
envían información según sea necesario

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

05:34.440 --> 05:38.070
Así que cuando realizas toda esta gestión de red utilizando SNMP,

05:38.070 --> 05:40.620
tienes dos opciones donde enviar los datos.

05:40.620 --> 05:42.690
Puedes enviarla a través de la red que estás utilizando,

05:42.690 --> 05:44.670
lo que se conoce como comunicación en banda,

05:44.670 --> 05:46.830
o puedes enviarla fuera de banda.

05:46.830 --> 05:47.940
Ahora, cuando lo haces en banda,

05:47.940 --> 05:49.890
significa que vas a enviar estos datos de gestión

05:49.890 --> 05:51.810
a través de la misma red que transporta la información

05:51.810 --> 05:54.120
corporativa y los datos normales.

05:54.120 --> 05:57.600
Es más barato y fácil, pero menos seguro.

05:57.600 --> 05:58.710
Ahora, para estar más

05:58.710 --> 06:00.930
seguro, debes crear una red fuera de banda.

06:00.930 --> 06:02.760
Se trata de una red secundaria en la que

06:02.760 --> 06:04.560
tiene lugar toda la gestión, pero sigues

06:04.560 --> 06:06.780
teniendo esa red primaria en banda en la que se

06:06.780 --> 06:08.940
producen todos los datos que van a obtener los

06:08.940 --> 06:10.050
usuarios.

06:10.050 --> 06:11.610
La gestión debe realizarse siempre

06:11.610 --> 06:14.490
en una red fuera de banda porque aumenta la seguridad y saca

06:14.490 --> 06:17.160
esa función de gestión del lugar donde los usuarios

06:17.160 --> 06:18.993
pueden tocarla o verla.