WEBVTT

00:00.660 --> 00:01.710
Docent: In deze les

00:01.710 --> 00:04.920
gaan we het hebben over het belang van load balancers.

00:04.920 --> 00:06.120
Nu worden load balancers,

00:06.120 --> 00:08.340
die ook bekend staan als een content switch,

00:08.340 --> 00:10.410
gebruikt om de inkomende verzoeken te verdelen

00:10.410 --> 00:11.910
over een aantal servers binnen

00:11.910 --> 00:15.330
een servervorm of een cloud-infrastructuur.

00:15.330 --> 00:17.370
Als je een grote website of service beheert,

00:17.370 --> 00:20.040
kun je dat niet allemaal op één server doen.

00:20.040 --> 00:22.680
Ik heb op dit moment bijvoorbeeld enkele honderdduizenden

00:22.680 --> 00:23.513
studenten die mijn

00:23.513 --> 00:25.680
cursussen volgen en mijn video's bekijken.

00:25.680 --> 00:29.100
Op geen enkele manier kan een enkele server zoveel belasting aan.

00:29.100 --> 00:30.630
Dus moeten we het verspreiden over

00:30.630 --> 00:32.460
een heleboel verschillende servers

00:32.460 --> 00:33.810
over de hele wereld.

00:33.810 --> 00:36.300
Maar als een student mijn website wil bezoeken, hoeft

00:36.300 --> 00:38.340
hij geen specifieke server te kiezen.

00:38.340 --> 00:41.070
In plaats daarvan gaan ze gewoon naar diontraining. com en onze loadbalancer

00:41.070 --> 00:43.230
en contentswitch leiden dat verzoek om

00:43.230 --> 00:45.960
naar de eerstvolgende beschikbare server om het

00:45.960 --> 00:47.460
te kunnen verwerken.

00:47.460 --> 00:49.590
We hebben zelfs tonnen verschillende servers

00:49.590 --> 00:50.880
over de hele wereld om al die

00:50.880 --> 00:53.100
verschillende verzoeken af te handelen.

00:53.100 --> 00:55.230
Hetzelfde gebeurt met Netflix of

00:55.230 --> 00:57.480
Hulu of Facebook of Amazon, maar dan

00:57.480 --> 00:59.280
op veel grotere schaal.

00:59.280 --> 01:01.920
Al deze grote websites moeten een load balancer gebruiken,

01:01.920 --> 01:03.570
anders zou een enkele server simpelweg

01:03.570 --> 01:05.430
crashen onder de belasting en zouden ze

01:05.430 --> 01:06.263
lijden onder een zelfopgelegde

01:06.263 --> 01:08.400
Denial of Service aanval vanwege de populariteit

01:08.400 --> 01:10.650
van hun website.

01:10.650 --> 01:12.510
Een loadbalancer werkt in wezen als een

01:12.510 --> 01:13.500
verkeersagent door voor

01:13.500 --> 01:15.120
je servers te gaan zitten en het verzoek

01:15.120 --> 01:17.310
van de klant te routeren naar de servers die op dat

01:17.310 --> 01:19.410
moment het meest beschikbaar zijn om aan dat verzoek

01:19.410 --> 01:20.970
te voldoen.

01:20.970 --> 01:23.940
Dit maximaliseert de snelheid om te reageren op de gebruiker

01:23.940 --> 01:25.530
en het maakt efficiënter gebruik

01:25.530 --> 01:28.170
van al uw bestaande capaciteit voor uw servers voor

01:28.170 --> 01:30.060
al uw gebruikersverzoeken.

01:30.060 --> 01:32.220
De reden waarom een loadbalancer zo belangrijk is,

01:32.220 --> 01:34.230
is dat het een van de belangrijkste dingen is die

01:34.230 --> 01:36.750
we kunnen doen om ons te verdedigen tegen een Denial of Service-aanval

01:36.750 --> 01:39.270
of een Distributed Denial of Service-aanval.

01:39.270 --> 01:41.730
Wat is een Denial of Service-aanval?

01:41.730 --> 01:43.560
Bij een Denial of Service-aanval worden

01:43.560 --> 01:46.410
de systemen van het slachtoffer voortdurend overspoeld

01:46.410 --> 01:48.090
met verzoeken om diensten, waardoor

01:48.090 --> 01:50.070
het systeem geheugen tekort komt en uiteindelijk

01:50.070 --> 01:51.570
crasht.

01:51.570 --> 01:52.830
De meeste moderne systemen kunnen

01:52.830 --> 01:55.230
echter niet door een enkele machine neergehaald worden.

01:55.230 --> 01:58.230
In plaats daarvan gebruiken aanvallers een DDoS of Distributed

01:58.230 --> 02:00.540
Denial of Service-aanval.

02:00.540 --> 02:02.490
Bij een Distributed Denial of Service aanval,

02:02.490 --> 02:04.920
in plaats van een enkele aanvaller die zich richt op een

02:04.920 --> 02:07.200
server, zijn er honderden of zelfs duizenden machines

02:07.200 --> 02:10.050
die tegelijkertijd die aanval uitvoeren op de server, om deze

02:10.050 --> 02:11.670
offline te krijgen.

02:11.670 --> 02:14.040
In maart 2018 werd GitHub bijvoorbeeld getroffen

02:14.040 --> 02:16.410
door de grootste DDoS tot nu toe, waarbij tienduizenden

02:16.410 --> 02:18.570
unieke eindpunten een gecoördineerde aanval

02:18.570 --> 02:20.160
uitvoerden om die server te treffen

02:20.160 --> 02:22.230
met een piek in het verkeer die 1,5 miljard

02:22.230 --> 02:25.620
euro bedroeg. 35 terabit per seconde.

02:25.620 --> 02:28.980
Hierdoor was de site slechts vijf minuten offline.

02:28.980 --> 02:30.750
Maar de echte vraag is, hoe kunnen we

02:30.750 --> 02:32.670
een van deze aanvallen overleven en voorkomen

02:32.670 --> 02:35.760
dat het de servers van onze organisatie platlegt?

02:35.760 --> 02:37.620
We hoeven alleen maar naar Amazon te kijken

02:37.620 --> 02:39.330
voor een aantal van de best practices.

02:39.330 --> 02:41.520
In februari 2020 werd Amazon namelijk

02:41.520 --> 02:44.130
getroffen door de grootste DDoS tot nu toe, zelfs

02:44.130 --> 02:45.630
groter dan GitHub.

02:45.630 --> 02:47.130
En er was een gecoördineerde

02:47.130 --> 02:49.230
aanval om die server te raken met een piek

02:49.230 --> 02:52.410
in het verkeer van 2. 3 terabit per seconde, maar dankzij

02:52.410 --> 02:55.470
de goede beveiligingsarchitectuur die ze hebben en hun

02:55.470 --> 02:57.480
vermogen om bronnen op te schalen om

02:57.480 --> 02:58.950
die aanval uit te voeren, hadden

02:58.950 --> 03:01.650
ze geen last van downtime tijdens de aanval, ook

03:01.650 --> 03:03.900
al was deze 70% groter dan de aanval die GitHub

03:03.900 --> 03:05.880
neerhaalde.

03:05.880 --> 03:07.410
De eerste techniek die ze gebruikten

03:07.410 --> 03:09.750
staat bekend als blackholing of sinkholing.

03:09.750 --> 03:10.800
Dit is een techniek die

03:10.800 --> 03:13.020
alle aanvallende IP adressen identificeert

03:13.020 --> 03:14.400
en al hun verkeer omleidt naar

03:14.400 --> 03:17.160
een niet-bestaande server via een null interface, waardoor

03:17.160 --> 03:19.410
de aanval effectief gestopt wordt.

03:19.410 --> 03:22.050
Helaas kunnen de aanvallers altijd naar een nieuw IP verhuizen

03:22.050 --> 03:23.760
en de aanval opnieuw starten.

03:23.760 --> 03:25.950
Dus het zal een DDoS niet voor altijd voorkomen,

03:25.950 --> 03:27.480
maar het zal je wat tijd geven terwijl

03:27.480 --> 03:29.640
je aan andere mitigaties werkt.

03:29.640 --> 03:32.070
IPS'en, of Intrusion Prevention Systems, kunnen ook worden

03:32.070 --> 03:33.510
gebruikt om Denial of Service-aanvallen

03:33.510 --> 03:35.730
te identificeren en erop te reageren.

03:35.730 --> 03:37.560
Dit werkt misschien goed voor kleinschalige

03:37.560 --> 03:38.520
aanvallen op je netwerk,

03:38.520 --> 03:40.920
maar het heeft niet genoeg verwerkingskracht om een echt

03:40.920 --> 03:42.780
grootschalige aanval aan te kunnen, zoals

03:42.780 --> 03:45.060
de aanval waar Amazon het doelwit van was.

03:45.060 --> 03:46.920
Een van de meest effectieve methoden

03:46.920 --> 03:49.140
is het gebruik van elastische cloudinfrastructuur,

03:49.140 --> 03:52.290
omdat je daarmee naar behoefte kunt opschalen, zodat je de aanval

03:52.290 --> 03:54.300
kunt overleven.

03:54.300 --> 03:55.770
Het probleem met deze strategie is echter

03:55.770 --> 03:57.090
dat de meeste serviceproviders je

03:57.090 --> 03:58.920
kosten in rekening brengen op basis van de capaciteit

03:58.920 --> 04:00.510
en resources die je gebruikt.

04:00.510 --> 04:02.190
Dus als je opschaalt, zorgt dit ervoor

04:02.190 --> 04:04.380
dat we een veel grotere rekening krijgen van onze

04:04.380 --> 04:05.940
cloud service provider en dit kan

04:05.940 --> 04:07.320
iets zijn waar we geen rendement

04:07.320 --> 04:09.390
op investering voor krijgen, omdat al dat verkeer

04:09.390 --> 04:12.030
geen inkomsten genereerde voor onze organisatie, het

04:12.030 --> 04:13.110
was allemaal gewoon onderdeel

04:13.110 --> 04:15.090
van de aanval.

04:15.090 --> 04:17.280
Dat gezegd hebbende, je blijft tenminste online om je betalende

04:17.280 --> 04:18.750
klanten van dienst te zijn.

04:18.750 --> 04:20.400
Het is dus maar de vraag of je het je kunt

04:20.400 --> 04:22.140
veroorloven om het langer vol te houden

04:22.140 --> 04:24.213
dan de DDoS-aanval kan doorgaan.