WEBVTT

00:00.270 --> 00:01.103
-: In deze les gaan

00:01.103 --> 00:03.690
we ons richten op monitoring en auditing.

00:03.690 --> 00:05.343
Laten we eerst beginnen met monitoren.

00:05.343 --> 00:06.930
Als we het over monitoren hebben, is

00:06.930 --> 00:09.090
een van de belangrijkste taken van een beveiligingsanalist

00:09.090 --> 00:11.130
het monitoren van het netwerk.

00:11.130 --> 00:12.150
We zijn net detectives.

00:12.150 --> 00:13.350
We proberen alles eruit

00:13.350 --> 00:14.970
te halen wat er niet goed uitziet

00:14.970 --> 00:18.180
en dit kan handmatig of geautomatiseerd gebeuren.

00:18.180 --> 00:21.150
Welnu, syslog is een protocol waarmee verschillende apparaten

00:21.150 --> 00:23.820
en softwaretoepassingen hun logs of eventrecords naar

00:23.820 --> 00:26.520
een gecentraliseerde server kunnen sturen.

00:26.520 --> 00:30.300
Nu volgt syslog een standaard client-server model.

00:30.300 --> 00:33.030
En dit is de defacto standaard voor het loggen van gebeurtenissen

00:33.030 --> 00:35.490
van gedistribueerde systemen over een netwerk.

00:35.490 --> 00:38.820
Je zult syslog in gebruik zien in veel van de systemen

00:38.820 --> 00:40.950
waar je dagelijks mee werkt.

00:40.950 --> 00:43.590
Nu draait syslog op de meeste besturingssystemen en

00:43.590 --> 00:45.270
op de meeste netwerkapparatuur.

00:45.270 --> 00:47.310
Dus of je nu een Cisco router gebruikt of

00:47.310 --> 00:49.920
een Windows machine of een Linux server, ze kunnen

00:49.920 --> 00:51.630
allemaal syslog gebruiken.

00:51.630 --> 00:53.490
Als we deze berichten terugsturen,

00:53.490 --> 00:55.920
hoe ziet een syslog bericht er dan uit?

00:55.920 --> 00:58.860
Een syslog bericht bevat een aantal dingen.

00:58.860 --> 01:01.530
Het bevat een PRI-code, wat een prioriteitscode is.

01:01.530 --> 01:04.410
Het bevat een koptekst en een berichtgedeelte.

01:04.410 --> 01:05.610
Laten we het over elk van deze hebben.

01:05.610 --> 01:08.040
Ten eerste hebben we deze PRI-code, deze prioriteit,

01:08.040 --> 01:10.200
en deze wordt berekend op basis van de faciliteit

01:10.200 --> 01:12.450
en het ernstniveau van de gegevens.

01:12.450 --> 01:13.710
Vervolgens hebben we een header

01:13.710 --> 01:15.570
en de header bevat de tijdstempel van de

01:15.570 --> 01:17.190
gebeurtenis en de hostnaam.

01:17.190 --> 01:20.160
We weten dus waar het vandaan kwam en hoe laat het was.

01:20.160 --> 01:22.230
En tot slot hebben we het berichtgedeelte, dat het

01:22.230 --> 01:24.360
bronproces van de gebeurtenis en de gerelateerde

01:24.360 --> 01:27.330
inhoud bevat, in feite welke gegevens er zijn gebeurd en waarover je ons

01:27.330 --> 01:28.560
iets wilt vertellen?

01:28.560 --> 01:30.570
En dat is het idee hier met het berichtgedeelte.

01:30.570 --> 01:33.390
Dit is het vlees en de aardappelen van deze boodschap.

01:33.390 --> 01:34.800
Nu, toen we syslog behandelden,

01:34.800 --> 01:37.770
zaten er een paar nadelen aan in de originele versie.

01:37.770 --> 01:40.230
Het oorspronkelijke protocol vertrouwde op UDP.

01:40.230 --> 01:42.990
Nu kan dit afleverproblemen veroorzaken met overbelaste

01:42.990 --> 01:45.510
netwerken omdat UDP een fire and forget protocol is.

01:45.510 --> 01:46.920
Het verzendt het en wacht niet op

01:46.920 --> 01:48.270
antwoord en bevestiging.

01:48.270 --> 01:50.250
En dus gaat het er gewoon van uit dat het er is gekomen.

01:50.250 --> 01:51.420
Als je een overbelast netwerk

01:51.420 --> 01:53.051
hebt, kan het zijn dat gegevens wegvallen,

01:53.051 --> 01:55.500
waardoor je informatie niet op de logserver terechtkomt

01:55.500 --> 01:57.630
en niet wordt gelogd.

01:57.630 --> 01:59.760
Vroeger was dit misschien oké, omdat mensen ervan

01:59.760 --> 02:00.930
uitgingen dat iedereen in je

02:00.930 --> 02:02.520
netwerk te vertrouwen was, maar tegenwoordig

02:02.520 --> 02:04.080
willen we dat niet meer.

02:04.080 --> 02:05.760
We willen er zeker van zijn dat onze gegevens daar terechtkomen.

02:05.760 --> 02:07.920
We moeten hier dus een oplossing voor bedenken.

02:07.920 --> 02:09.690
Het tweede punt is dat er niet veel basisbeveiligingscontroles

02:09.690 --> 02:11.640
zijn.

02:11.640 --> 02:14.070
Er was niets zoals encryptie of authenticatie

02:14.070 --> 02:16.080
standaard inbegrepen bij syslog.

02:16.080 --> 02:17.850
En dit was weer een nadeel.

02:17.850 --> 02:20.250
Dus in moderne implementaties van syslog hebben

02:20.250 --> 02:21.750
we deze dingen gecorrigeerd.

02:21.750 --> 02:23.220
Vanwege deze beveiligingsproblemen

02:23.220 --> 02:25.590
hebben onze nieuwere syslog implementaties veel verschillende

02:25.590 --> 02:27.510
functies en mogelijkheden toegevoegd.

02:27.510 --> 02:29.400
En we gaan er hier een paar bespreken.

02:29.400 --> 02:32.460
Eerst gebruiken nieuwere implementaties TCP voor

02:32.460 --> 02:34.170
consistente aflevering.

02:34.170 --> 02:36.360
Op deze manier, als het netwerk overbelast raakt

02:36.360 --> 02:37.770
en dat bericht niet aankomt,

02:37.770 --> 02:39.600
zal het het steeds opnieuw afleveren

02:39.600 --> 02:41.220
omdat het TCP gebruikt.

02:41.220 --> 02:43.470
De tweede verbetering, nieuwere implementaties,

02:43.470 --> 02:46.230
kunnen TLS, of transport layer security, gebruiken om je berichten

02:46.230 --> 02:49.050
die naar servers worden gestuurd te versleutelen.

02:49.050 --> 02:50.760
Op die manier kunnen gegevens die onderweg zijn niet

02:50.760 --> 02:52.580
worden gelezen door iemand anders op het netwerk.

02:52.580 --> 02:55.200
Het kan alleen worden gelezen door het eindpunt dat het

02:55.200 --> 02:57.510
heeft verzonden en de server die het ontvangt.

02:57.510 --> 02:58.343
Het derde punt

02:58.343 --> 03:02.130
is dat nieuwere implementaties ook MD5 en SHA1 gebruiken

03:02.130 --> 03:04.950
voor authenticatie en integriteit.

03:04.950 --> 03:07.770
Op deze manier kunnen de berichten berichtauthenticatie en -integriteit

03:07.770 --> 03:10.080
hebben terwijl ze door je netwerk gaan om er zeker van

03:10.080 --> 03:12.930
te zijn dat er niemand anders mee kan knoeien.

03:12.930 --> 03:14.730
Nogmaals, veel andere functies.

03:14.730 --> 03:16.920
Ik concentreer me echter niet te veel op deze set, want

03:16.920 --> 03:19.290
de drie belangrijkste waar we ons zorgen over maken is dat

03:19.290 --> 03:21.900
we zijn overgestapt op TCP voor een consistente levering.

03:21.900 --> 03:23.910
We zijn overgestapt op TLS voor encryptie

03:23.910 --> 03:26.130
en we gebruiken MD5 en SHA1 voor authenticatie

03:26.130 --> 03:28.050
en integriteit.

03:28.050 --> 03:30.090
Nu wordt deze nieuwere versie van

03:30.090 --> 03:33.810
de server meestal syslog-ng genoemd, voor syslog next generation,

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

03:35.490 --> 03:37.470
Het laatste wat ik wil zeggen over syslog

03:37.470 --> 03:40.560
is dat syslog vaak gebruikt wordt om drie dingen te betekenen.

03:40.560 --> 03:43.380
Het kan verwijzen naar het protocol waar we de gegevens over verzenden.

03:43.380 --> 03:46.410
Het kan verwijzen naar de server, zoals in een syslogserver, of

03:46.410 --> 03:48.690
het kan verwijzen naar de logboekvermeldingen

03:48.690 --> 03:50.430
zelf, zoals in sysloggegevens.

03:50.430 --> 03:51.990
Mensen zeggen vaak gewoon syslog en

03:51.990 --> 03:54.090
bedoelen dan alle drie, of een van deze drie, afhankelijk

03:54.090 --> 03:55.470
van de context.

03:55.470 --> 03:56.700
Dus wees voorzichtig als

03:56.700 --> 03:58.530
je mensen hoort praten in de industrie

03:58.530 --> 03:59.790
om er zeker van te zijn dat

03:59.790 --> 04:01.860
je begrijpt over welke van de drie ze het hebben,

04:01.860 --> 04:03.810
SNMP is onze volgende.

04:03.810 --> 04:06.900
SNMP is het Simple Network Management Protocol.

04:06.900 --> 04:09.480
Het is een TCP-protocol dat helpt bij het monitoren

04:09.480 --> 04:12.000
van netwerkapparaten en computers.

04:12.000 --> 04:14.520
SNMP is opgenomen in netwerkbeheer- en bewakingssystemen

04:14.520 --> 04:16.830
en wordt veel gebruikt in het concept van beheer

04:16.830 --> 04:18.840
en bewaking.

04:18.840 --> 04:21.870
SNMP is onderverdeeld in drie componenten.

04:21.870 --> 04:24.030
Er zijn de beheerde apparaten, de agent

04:24.030 --> 04:26.370
en de netwerkbeheersystemen zelf.

04:26.370 --> 04:28.020
We praten over beheerde apparaten.

04:28.020 --> 04:30.510
Dit zijn computers en andere netwerkapparaten die

04:30.510 --> 04:32.400
gemonitord worden met behulp van agents

04:32.400 --> 04:34.380
door een netwerkbeheersysteem.

04:34.380 --> 04:37.560
Agents zijn software die op een beheerd apparaat wordt geladen.

04:37.560 --> 04:39.450
Hierdoor kunnen we informatie doorsturen

04:39.450 --> 04:41.040
naar het netwerkbeheersysteem dat

04:41.040 --> 04:42.510
de monitoring uitvoert.

04:42.510 --> 04:44.700
En een netwerkbeheersysteem, of NMS,

04:44.700 --> 04:47.100
is de software die op een of meer servers draait

04:47.100 --> 04:48.120
en die de bewaking

04:48.120 --> 04:50.760
van alle netwerkapparaten en -computers in het

04:50.760 --> 04:52.230
netwerk regelt.

04:52.230 --> 04:54.840
SNMP is de lijm die ervoor zorgt dat alle

04:54.840 --> 04:58.080
drie met elkaar praten via dat SNMP-protocol.

04:58.080 --> 05:00.570
Hoe ziet dit er allemaal uit binnen het netwerk?

05:00.570 --> 05:03.180
Hier op het scherm zie je een kort diagram.

05:03.180 --> 05:05.910
Links hebben we ons netwerkbeheerstation, of onze

05:05.910 --> 05:09.000
NMS, dat deel uitmaakt van ons netwerkbeheersysteem.

05:09.000 --> 05:10.830
Dit gaat fungeren als onze manager

05:10.830 --> 05:12.630
en het gaat berichten sturen en ontvangen

05:12.630 --> 05:15.060
naar alle beheerde apparaten in het netwerk, je

05:15.060 --> 05:17.850
routers, je switches en je servers, toch?

05:17.850 --> 05:19.290
Nu, wanneer het informatie

05:19.290 --> 05:20.860
wil, stuurt het een get verzoek,

05:20.860 --> 05:23.970
en dan sturen die apparaten informatie terug door middel

05:23.970 --> 05:25.890
van een set verzoek.

05:25.890 --> 05:27.960
Nu is er ook nog zoiets als een trap verzoek, dat ongevraagd

05:27.960 --> 05:29.910
informatie gaat ontvangen van die beheerapparaten,

05:29.910 --> 05:31.320
waarbij ze gewoon informatie sturen

05:31.320 --> 05:34.440
als dat nodig is met periodieke tussenpozen.

05:34.440 --> 05:38.070
Dus wanneer je al dit netwerkbeheer uitvoert met SNMP, heb je twee opties

05:38.070 --> 05:40.620
waar de gegevens naartoe gestuurd kunnen worden.

05:40.620 --> 05:42.690
Je kunt het versturen via het netwerk dat je gebruikt,

05:42.690 --> 05:44.670
wat bekend staat als in-band communicatie,

05:44.670 --> 05:46.830
of je kunt het out-of-band versturen.

05:46.830 --> 05:47.940
Wanneer je nu in-band doet,

05:47.940 --> 05:49.890
betekent dit dat je deze managementgegevens

05:49.890 --> 05:51.810
over hetzelfde netwerk stuurt dat je bedrijfsinformatie

05:51.810 --> 05:54.120
en normale gegevens vervoert.

05:54.120 --> 05:57.600
Dit is goedkoper en gemakkelijker, maar het is minder veilig.

05:57.600 --> 05:58.710
Om veiliger te zijn, zou

05:58.710 --> 06:00.930
je nu een out-of-band netwerk moeten creëren.

06:00.930 --> 06:02.760
Dit is een secundair netwerk waar al het

06:02.760 --> 06:04.560
beheer plaatsvindt, maar je hebt nog

06:04.560 --> 06:06.780
steeds dat primaire in-band netwerk waar alle

06:06.780 --> 06:10.050
gegevens die de gebruikers gaan krijgen plaatsvinden.

06:10.050 --> 06:11.610
Beheer moet altijd worden uitgevoerd

06:11.610 --> 06:14.490
op een out-of-band netwerk omdat het de veiligheid verhoogt

06:14.490 --> 06:17.160
en de beheerfunctie weghaalt van de plaats waar gebruikers

06:17.160 --> 06:18.993
het kunnen aanraken of zien.