WEBVTT

00:00.270 --> 00:01.103
- - W tej lekcji

00:01.103 --> 00:03.690
skupimy się na monitorowaniu i audycie.

00:03.690 --> 00:05.343
Zacznijmy najpierw od monitorowania.

00:05.343 --> 00:06.930
Kiedy mówimy o monitorowaniu,

00:06.930 --> 00:09.090
jednym z głównych zadań analityka bezpieczeństwa

00:09.090 --> 00:11.130
jest monitorowanie sieci.

00:11.130 --> 00:12.150
Jesteśmy jak detektywi.

00:12.150 --> 00:13.350
Staramy się wykorzenić wszystko,

00:13.350 --> 00:14.970
co nie wydaje się właściwe, a można to

00:14.970 --> 00:18.180
zrobić ręcznie lub za pomocą zautomatyzowanych środków.

00:18.180 --> 00:21.150
Obecnie syslog jest protokołem umożliwiającym różnym urządzeniom

00:21.150 --> 00:23.820
i aplikacjom przesyłanie swoich dzienników lub zapisów

00:23.820 --> 00:26.520
zdarzeń do scentralizowanego serwera.

00:26.520 --> 00:30.300
Teraz syslog będzie działał zgodnie ze standardowym modelem klient-serwer.

00:30.300 --> 00:33.030
Jest to defacto standard rejestrowania zdarzeń

00:33.030 --> 00:35.490
z systemów rozproszonych w sieci.

00:35.490 --> 00:38.820
Syslog jest wykorzystywany w wielu systemach, nad

00:38.820 --> 00:40.950
którymi pracujesz na co dzień.

00:40.950 --> 00:43.590
Obecnie syslog działa w większości systemów operacyjnych i

00:43.590 --> 00:45.270
na większości urządzeń sieciowych.

00:45.270 --> 00:47.310
Niezależnie od tego, czy korzystasz z routera

00:47.310 --> 00:49.920
Cisco, maszyny z systemem Windows czy serwera Linux, wszystkie

00:49.920 --> 00:51.630
one mogą korzystać z syslog.

00:51.630 --> 00:53.490
Jak wygląda wiadomość syslog,

00:53.490 --> 00:55.920
gdy wysyłamy ją z powrotem?

00:55.920 --> 00:58.860
Cóż, komunikat syslog będzie zawierał kilka rzeczy.

00:58.860 --> 01:01.530
Zawiera on kod PRI, który jest kodem priorytetowym.

01:01.530 --> 01:04.410
Zawiera nagłówek i część zawierającą wiadomość.

01:04.410 --> 01:05.610
Porozmawiajmy o każdym z nich.

01:05.610 --> 01:08.040
Po pierwsze, mamy ten kod PRI, ten priorytet,

01:08.040 --> 01:10.200
który zostanie obliczony na podstawie

01:10.200 --> 01:12.450
obiektu i poziomu ważności danych.

01:12.450 --> 01:13.710
Następnie mamy nagłówek,

01:13.710 --> 01:15.570
który będzie zawierał znacznik czasu

01:15.570 --> 01:17.190
zdarzenia i nazwę hosta.

01:17.190 --> 01:20.160
Wiemy więc, skąd pochodzi i o której godzinie.

01:20.160 --> 01:22.230
Wreszcie, mamy część wiadomości, która

01:22.230 --> 01:24.360
zawiera proces źródłowy zdarzenia i powiązaną

01:24.360 --> 01:27.330
treść, w zasadzie jakie dane się wydarzyły i o czym chcesz nam

01:27.330 --> 01:28.560
powiedzieć?

01:28.560 --> 01:30.570
I o to właśnie chodzi z częścią wiadomości.

01:30.570 --> 01:33.390
To jest sedno tej wiadomości.

01:33.390 --> 01:34.800
Teraz, gdy zajmowaliśmy

01:34.800 --> 01:37.770
się syslogiem, w oryginalnej wersji ma on kilka wad.

01:37.770 --> 01:40.230
Oryginalny protokół opierał się na protokole UDP.

01:40.230 --> 01:42.990
Może to powodować problemy z dostarczaniem w przeciążonych sieciach,

01:42.990 --> 01:45.510
ponieważ UDP jest protokołem typu "fire and forget".

01:45.510 --> 01:46.920
Wysyła go i nie czeka na odpowiedź

01:46.920 --> 01:48.270
ani potwierdzenie.

01:48.270 --> 01:50.250
Więc po prostu zakłada, że tam dotarł.

01:50.250 --> 01:51.420
Jeśli masz przeciążoną

01:51.420 --> 01:53.051
sieć, dane mogą być porzucane,

01:53.051 --> 01:55.500
a zatem informacje nie dotrą do serwera dziennika

01:55.500 --> 01:57.630
i nie zostaną zarejestrowane.

01:57.630 --> 01:59.760
Na początku mogło to być w porządku, ponieważ

01:59.760 --> 02:00.930
ludzie zakładali, że wszyscy

02:00.930 --> 02:02.520
w sieci są godni zaufania, ale obecnie

02:02.520 --> 02:04.080
tego nie chcemy.

02:04.080 --> 02:05.760
Chcemy mieć pewność, że nasze dane tam dotrą.

02:05.760 --> 02:07.920
Musimy więc znaleźć rozwiązanie tego problemu.

02:07.920 --> 02:09.690
Drugą rzeczą jest to, że nie ma zbyt wielu

02:09.690 --> 02:11.640
podstawowych kontroli bezpieczeństwa.

02:11.640 --> 02:14.070
Nie było niczego takiego jak szyfrowanie lub uwierzytelnianie

02:14.070 --> 02:16.080
domyślnie dołączone do syslog.

02:16.080 --> 02:17.850
I to znowu była kolejna wada.

02:17.850 --> 02:20.250
Tak więc w nowoczesnych implementacjach syslog

02:20.250 --> 02:21.750
poprawiliśmy te rzeczy.

02:21.750 --> 02:23.220
Teraz, ze względu na te kwestie bezpieczeństwa,

02:23.220 --> 02:25.590
nasze nowsze implementacje syslog dodały wiele różnych

02:25.590 --> 02:27.510
funkcji i możliwości.

02:27.510 --> 02:29.400
Omówimy tutaj kilka z nich.

02:29.400 --> 02:32.460
Pierwsze nowsze implementacje używają protokołu TCP

02:32.460 --> 02:34.170
do spójnego dostarczania.

02:34.170 --> 02:36.360
W ten sposób, jeśli sieć zostanie przeciążona i wiadomość

02:36.360 --> 02:37.770
nie będzie mogła tam dotrzeć, będzie

02:37.770 --> 02:39.600
ona dostarczana ponownie i ponownie, ponieważ

02:39.600 --> 02:41.220
korzysta z protokołu TCP.

02:41.220 --> 02:43.470
Drugie ulepszenie, nowsze implementacje, mogą

02:43.470 --> 02:46.230
wykorzystywać TLS, czyli transport layer security, do

02:46.230 --> 02:49.050
szyfrowania wiadomości wysyłanych do serwerów.

02:49.050 --> 02:50.760
W ten sposób przesyłane dane nie mogą zostać

02:50.760 --> 02:52.580
odczytane przez inną osobę w sieci.

02:52.580 --> 02:55.200
Może być odczytany tylko przez punkt końcowy, który

02:55.200 --> 02:57.510
go wysłał i serwer, który go odbiera.

02:57.510 --> 02:58.343
Trzecią rzeczą

02:58.343 --> 03:02.130
jest to, że nowsze implementacje używają również MD5 i SHA1 do zapewnienia

03:02.130 --> 03:04.950
uwierzytelniania i integralności.

03:04.950 --> 03:07.770
W ten sposób wiadomości mogą mieć uwierzytelnianie i integralność

03:07.770 --> 03:10.080
wiadomości podczas przechodzenia przez sieć,

03:10.080 --> 03:12.930
aby upewnić się, że nikt inny ich nie manipuluje.

03:12.930 --> 03:14.730
Ponownie, wiele innych funkcji.

03:14.730 --> 03:16.920
Nie skupiam się jednak zbytnio na tym zestawie, ponieważ

03:16.920 --> 03:19.290
tak naprawdę trzy duże, na których nam zależy, to przejście

03:19.290 --> 03:21.900
na TCP w celu zapewnienia spójnej dostawy.

03:21.900 --> 03:23.910
Przeszliśmy na TLS do szyfrowania

03:23.910 --> 03:26.130
i zaczęliśmy używać MD5 i SHA1 do uwierzytelniania

03:26.130 --> 03:28.050
i integralności.

03:28.050 --> 03:30.090
Teraz ta nowsza wersja serwera

03:30.090 --> 03:33.810
jest zwykle nazywana syslog-ng, czyli syslog nowej generacji

03:33.810 --> 03:35.490
lub rsyslog.

03:35.490 --> 03:37.470
Ostatnią rzeczą, o której chcę wspomnieć na temat

03:37.470 --> 03:40.560
syslog, jest to, że syslog jest często używany do oznaczania trzech rzeczy.

03:40.560 --> 03:43.380
Może odnosić się do protokołu, przez który wysyłamy dane.

03:43.380 --> 03:46.410
Może odnosić się do serwera, jak w przypadku serwera syslog,

03:46.410 --> 03:48.690
lub do samych wpisów dziennika, jak w przypadku

03:48.690 --> 03:50.430
danych syslog.

03:50.430 --> 03:51.990
Ludzie często mówią po prostu syslog i

03:51.990 --> 03:54.090
mają na myśli wszystkie trzy lub dowolny z tych trzech,

03:54.090 --> 03:55.470
w zależności od kontekstu.

03:55.470 --> 03:56.700
Bądź więc ostrożny, gdy

03:56.700 --> 03:58.530
słyszysz ludzi mówiących w branży,

03:58.530 --> 03:59.790
aby upewnić się, że rozumiesz,

03:59.790 --> 04:01.860
który z trzech, o których mówią, SNMP jest

04:01.860 --> 04:03.810
naszym następnym.

04:03.810 --> 04:06.900
SNMP to protokół prostego zarządzania siecią.

04:06.900 --> 04:09.480
Jest to protokół TCP, który pomaga w monitorowaniu

04:09.480 --> 04:12.000
podłączonych do sieci urządzeń i komputerów.

04:12.000 --> 04:14.520
SNMP jest włączony do systemów zarządzania i monitorowania

04:14.520 --> 04:16.830
sieci i jest intensywnie wykorzystywany w koncepcji

04:16.830 --> 04:18.840
zarządzania i monitorowania.

04:18.840 --> 04:21.870
SNMP dzieli się na trzy komponenty.

04:21.870 --> 04:24.030
Są to zarządzane urządzenia, agent

04:24.030 --> 04:26.370
i same systemy zarządzania siecią.

04:26.370 --> 04:28.020
Mówimy o urządzeniach zarządzanych.

04:28.020 --> 04:30.510
Są to komputery i inne urządzenia podłączone do sieci,

04:30.510 --> 04:32.400
które są monitorowane za pomocą agentów

04:32.400 --> 04:34.380
przez system zarządzania siecią.

04:34.380 --> 04:37.560
Agenci to oprogramowanie, które jest ładowane na zarządzane urządzenie.

04:37.560 --> 04:39.450
Dzięki temu możemy przekierować informacje

04:39.450 --> 04:41.040
do systemu zarządzania siecią, który

04:41.040 --> 04:42.510
będzie monitorował.

04:42.510 --> 04:44.700
System zarządzania siecią (NMS) to oprogramowanie

04:44.700 --> 04:47.100
uruchamiane na jednym lub kilku serwerach, które

04:47.100 --> 04:48.120
kontroluje monitorowanie

04:48.120 --> 04:50.760
wszystkich podłączonych do sieci urządzeń i komputerów

04:50.760 --> 04:52.230
w całej sieci.

04:52.230 --> 04:54.840
SNMP jest klejem, który sprawia, że wszystkie te trzy

04:54.840 --> 04:58.080
elementy komunikują się ze sobą za pomocą protokołu SNMP.

04:58.080 --> 05:00.570
Jak to wszystko wygląda wewnątrz sieci?

05:00.570 --> 05:03.180
Cóż, tutaj na ekranie można zobaczyć krótki schemat.

05:03.180 --> 05:05.910
Po lewej stronie mamy naszą stację zarządzania siecią lub nasz

05:05.910 --> 05:09.000
NMS, który jest częścią naszego systemu zarządzania siecią.

05:09.000 --> 05:10.830
To będzie działać jako nasz menedżer

05:10.830 --> 05:12.630
i będzie wysyłać i odbierać wiadomości

05:12.630 --> 05:15.060
do wszystkich zarządzanych urządzeń w sieci,

05:15.060 --> 05:17.850
routerów, przełączników i serwerów, prawda?

05:17.850 --> 05:19.290
Teraz, gdy chce uzyskać

05:19.290 --> 05:20.860
informacje, wyśle żądanie

05:20.860 --> 05:23.970
get, a następnie te urządzenia odeślą informacje

05:23.970 --> 05:25.890
za pomocą żądania set.

05:25.890 --> 05:27.960
Teraz jest też coś, co nazywa się żądaniem pułapki, które

05:27.960 --> 05:29.910
będzie odbierać niezamówione informacje z tych urządzeń

05:29.910 --> 05:31.320
zarządzających, gdzie po prostu wysyłają

05:31.320 --> 05:32.970
informacje w razie potrzeby w okresowych odstępach

05:32.970 --> 05:34.440
czasu.

05:34.440 --> 05:38.070
Tak więc podczas zarządzania siecią za pomocą SNMP dostępne

05:38.070 --> 05:40.620
są dwie opcje przesyłania danych.

05:40.620 --> 05:42.690
Można go wysłać za pośrednictwem używanej

05:42.690 --> 05:44.670
sieci, co jest znane jako komunikacja

05:44.670 --> 05:46.830
wewnątrzpasmowa, lub poza pasmem.

05:46.830 --> 05:47.940
W przypadku transmisji w

05:47.940 --> 05:49.890
paśmie oznacza to, że dane zarządzania będą

05:49.890 --> 05:51.810
przesyłane przez tę samą sieć, przez którą

05:51.810 --> 05:54.120
przesyłane są informacje firmowe i zwykłe dane.

05:54.120 --> 05:57.600
Jest to tańsze, łatwiejsze, ale mniej bezpieczne.

05:57.600 --> 05:58.710
Teraz, aby być bardziej bezpiecznym,

05:58.710 --> 06:00.930
należy utworzyć sieć pozapasmową.

06:00.930 --> 06:02.760
Jest to sieć drugorzędna, w której odbywa

06:02.760 --> 06:04.560
się całe zarządzanie, ale nadal masz

06:04.560 --> 06:06.780
tę podstawową sieć w paśmie, w której będą znajdować

06:06.780 --> 06:10.050
się wszystkie dane, które otrzymają użytkownicy.

06:10.050 --> 06:11.610
Zarządzanie powinno zawsze odbywać

06:11.610 --> 06:14.490
się w sieci pozapasmowej, ponieważ zwiększa to bezpieczeństwo

06:14.490 --> 06:17.160
i przenosi tę funkcję zarządzania z miejsca, w którym użytkownicy

06:17.160 --> 06:18.993
mogą ją dotknąć lub zobaczyć.
