WEBVTT

00:00.660 --> 00:01.710
Docente: In questa lezione

00:01.710 --> 00:04.920
parleremo dell'importanza dei bilanciatori di carico.

00:04.920 --> 00:06.120
I bilanciatori di carico,

00:06.120 --> 00:08.340
noti anche come content switch, sono utilizzati

00:08.340 --> 00:10.410
per distribuire le richieste in arrivo su

00:10.410 --> 00:11.910
un certo numero di server all'interno

00:11.910 --> 00:15.330
di una forma di server o di un'infrastruttura cloud.

00:15.330 --> 00:17.370
Se gestite un sito web o un servizio di grandi dimensioni,

00:17.370 --> 00:20.040
non potete fare tutto questo su un singolo server.

00:20.040 --> 00:22.680
Per esempio, a questo punto ho diverse centinaia di migliaia

00:22.680 --> 00:23.513
di studenti che seguono

00:23.513 --> 00:25.680
i miei corsi e guardano i miei video.

00:25.680 --> 00:29.100
È impossibile che un singolo server possa gestire un carico così elevato.

00:29.100 --> 00:30.630
Quindi dobbiamo distribuirlo

00:30.630 --> 00:32.460
su molti server diversi in tutto

00:32.460 --> 00:33.810
il mondo.

00:33.810 --> 00:36.300
Ma quando uno studente vuole visitare il mio sito web,

00:36.300 --> 00:38.340
non deve scegliere un server specifico.

00:38.340 --> 00:41.070
Invece, vanno semplicemente a diontraining. com e il nostro load balancer

00:41.070 --> 00:43.230
e content switch reindirizza la richiesta

00:43.230 --> 00:47.460
al prossimo server disponibile per poterla elaborare.

00:47.460 --> 00:49.590
In effetti, abbiamo tonnellate di server

00:49.590 --> 00:50.880
diversi in tutto il mondo

00:50.880 --> 00:53.100
per gestire tutte le richieste.

00:53.100 --> 00:55.230
La stessa cosa accade con Netflix

00:55.230 --> 00:57.480
o Hulu o Facebook o Amazon, ma su scala

00:57.480 --> 00:59.280
molto più ampia.

00:59.280 --> 01:01.920
Tutti questi siti web di grandi dimensioni devono utilizzare

01:01.920 --> 01:03.570
un bilanciatore di carico, altrimenti

01:03.570 --> 01:05.430
un singolo server si bloccherebbe sotto

01:05.430 --> 01:06.263
il carico e subirebbe

01:06.263 --> 01:08.400
un attacco di Denial of Service autoimposto a causa

01:08.400 --> 01:10.650
della popolarità del sito.

01:10.650 --> 01:12.510
Un bilanciatore di carico agisce essenzialmente

01:12.510 --> 01:13.500
come un poliziotto del traffico,

01:13.500 --> 01:15.120
sedendosi di fronte ai vostri server e instradando

01:15.120 --> 01:17.310
le richieste dei clienti verso i server più disponibili

01:17.310 --> 01:20.970
a soddisfare tali richieste in un determinato momento.

01:20.970 --> 01:23.940
In questo modo si massimizza la velocità di risposta all'utente

01:23.940 --> 01:25.530
e si utilizza in modo più efficiente

01:25.530 --> 01:28.170
tutta la capacità esistente dei server per tutte le

01:28.170 --> 01:30.060
richieste degli utenti.

01:30.060 --> 01:32.220
Il motivo per cui un bilanciatore di carico è così

01:32.220 --> 01:34.230
importante è che è una delle cose principali

01:34.230 --> 01:36.750
che possiamo fare per difenderci da un attacco Denial

01:36.750 --> 01:39.270
of Service o Distributed Denial of Service.

01:39.270 --> 01:41.730
Che cos'è un attacco Denial of Service?

01:41.730 --> 01:43.560
Un attacco di tipo "Denial of Service"

01:43.560 --> 01:46.410
consiste nell'inondare continuamente i sistemi della vittima

01:46.410 --> 01:48.090
con richieste di servizi, facendo

01:48.090 --> 01:50.070
sì che il sistema esaurisca la memoria e alla

01:50.070 --> 01:51.570
fine si blocchi.

01:51.570 --> 01:52.830
Ora, però, la maggior parte dei sistemi

01:52.830 --> 01:55.230
moderni non può essere abbattuta da una singola macchina.

01:55.230 --> 01:58.230
Gli aggressori utilizzano invece un attacco DDoS

01:58.230 --> 02:00.540
o Distributed Denial of Service.

02:00.540 --> 02:02.490
In un attacco Distributed Denial of Service,

02:02.490 --> 02:04.920
invece di un singolo attaccante che prende di mira un

02:04.920 --> 02:07.200
server, ci sono centinaia o addirittura migliaia

02:07.200 --> 02:10.050
di macchine che lanciano simultaneamente l'attacco al server

02:10.050 --> 02:11.670
per metterlo offline.

02:11.670 --> 02:14.040
Nel marzo 2018, ad esempio, GitHub è stato colpito

02:14.040 --> 02:16.410
dal più grande DDoS mai avvenuto, in cui decine

02:16.410 --> 02:18.570
di migliaia di endpoint unici hanno condotto

02:18.570 --> 02:20.160
un attacco coordinato per colpire

02:20.160 --> 02:22.230
il server con un picco di traffico pari a 1,5

02:22.230 --> 02:25.620
milioni di euro. 35 terabit al secondo.

02:25.620 --> 02:28.980
Questo ha costretto il sito a rimanere offline per cinque minuti.

02:28.980 --> 02:30.750
Ma la vera domanda è: come possiamo sopravvivere

02:30.750 --> 02:32.670
a uno di questi attacchi e impedire che distruggano

02:32.670 --> 02:35.760
i server della nostra organizzazione?

02:35.760 --> 02:37.620
Basta guardare ad Amazon per capire quali

02:37.620 --> 02:39.330
sono le migliori pratiche.

02:39.330 --> 02:41.520
Nel febbraio del 2020, Amazon è stata colpita

02:41.520 --> 02:44.130
dal più grande DDoS mai avvenuto, persino più

02:44.130 --> 02:45.630
grande di GitHub.

02:45.630 --> 02:47.130
E c'è stato un attacco coordinato

02:47.130 --> 02:49.230
per colpire quel server con un picco di traffico

02:49.230 --> 02:52.410
che ha misurato 2. 3 terabit al secondo, ma grazie

02:52.410 --> 02:55.470
alla buona architettura di sicurezza di cui dispone e alla

02:55.470 --> 02:57.480
capacità di scalare le risorse per sostenere

02:57.480 --> 02:58.950
l'attacco, non ha subito alcun

02:58.950 --> 03:01.650
downtime durante l'attacco, anche se era del 70%

03:01.650 --> 03:03.900
più grande di quello che ha messo fuori uso

03:03.900 --> 03:05.880
GitHub.

03:05.880 --> 03:07.410
La prima tecnica utilizzata

03:07.410 --> 03:09.750
è nota come blackholing o sinkholing.

03:09.750 --> 03:10.800
Si tratta di una tecnica

03:10.800 --> 03:13.020
che identifica gli indirizzi IP attaccanti e

03:13.020 --> 03:14.400
instrada tutto il loro traffico

03:14.400 --> 03:17.160
verso un server inesistente attraverso un'interfaccia

03:17.160 --> 03:19.410
nulla, bloccando di fatto l'attacco.

03:19.410 --> 03:22.050
Purtroppo, gli aggressori possono sempre spostarsi su un

03:22.050 --> 03:23.760
nuovo IP e ricominciare l'attacco.

03:23.760 --> 03:25.950
Quindi non impedirà per sempre un DDoS, ma vi

03:25.950 --> 03:27.480
farà guadagnare un po' di tempo

03:27.480 --> 03:29.640
mentre lavorate su altre mitigazioni.

03:29.640 --> 03:32.070
Gli IPS, o sistemi di prevenzione delle intrusioni, possono

03:32.070 --> 03:33.510
essere utilizzati anche per identificare

03:33.510 --> 03:35.730
e rispondere agli attacchi Denial of Service.

03:35.730 --> 03:37.560
Questo può funzionare bene per gli attacchi

03:37.560 --> 03:38.520
su piccola scala contro

03:38.520 --> 03:40.920
la rete, ma non ha abbastanza potenza di elaborazione

03:40.920 --> 03:42.780
per gestire un attacco su larga scala, come

03:42.780 --> 03:45.060
quello che ha colpito Amazon.

03:45.060 --> 03:46.920
Uno dei metodi più efficaci è l'utilizzo

03:46.920 --> 03:49.140
di un'infrastruttura cloud elastica, che

03:49.140 --> 03:52.290
consente di scalare su richiesta in base alle necessità, in modo

03:52.290 --> 03:54.300
da poter superare l'attacco.

03:54.300 --> 03:55.770
Il problema di questa strategia, tuttavia,

03:55.770 --> 03:57.090
è che la maggior parte dei fornitori

03:57.090 --> 03:58.920
di servizi addebita il costo in base alla capacità

03:58.920 --> 04:00.510
e alle risorse utilizzate.

04:00.510 --> 04:02.190
Quindi, man mano che si sale di scala,

04:02.190 --> 04:04.380
si riceve una fattura molto più alta dal nostro provider

04:04.380 --> 04:05.940
di servizi cloud e questo può essere

04:05.940 --> 04:07.320
qualcosa per cui non si ottiene

04:07.320 --> 04:09.390
alcun ritorno sull'investimento, perché tutto

04:09.390 --> 04:13.110
quel traffico non generava alcun guadagno per la nostra organizzazione, era solo

04:13.110 --> 04:15.090
parte dell'attacco.

04:15.090 --> 04:17.280
Detto questo, almeno rimarrete online per servire

04:17.280 --> 04:18.750
i vostri clienti paganti.

04:18.750 --> 04:20.400
Si tratta quindi di capire se potete

04:20.400 --> 04:22.140
permettervi di resistere più a lungo di

04:22.140 --> 04:24.213
quanto l'attacco DDoS possa continuare.