WEBVTT

00:00.660 --> 00:01.710
Conferenciante: En esta

00:01.710 --> 00:04.920
lección, vamos a hablar de la importancia de los balanceadores de carga.

00:04.920 --> 00:06.120
Ahora los equilibradores de

00:06.120 --> 00:08.340
carga, que también se conocen como conmutadores de

00:08.340 --> 00:10.410
contenido, se utilizan para distribuir las solicitudes

00:10.410 --> 00:11.910
entrantes entre varios servidores

00:11.910 --> 00:15.330
dentro de una forma de servidor o una infraestructura de nube.

00:15.330 --> 00:17.370
Si gestionas un sitio web o un servicio de gran

00:17.370 --> 00:20.040
tamaño, no puedes hacerlo todo en un único servidor.

00:20.040 --> 00:22.680
Por ejemplo, en este momento tengo varios cientos de

00:22.680 --> 00:23.513
miles de alumnos

00:23.513 --> 00:25.680
que siguen mis cursos y ven mis vídeos.

00:25.680 --> 00:29.100
Es imposible que un solo servidor pueda soportar tanta carga.

00:29.100 --> 00:30.630
Así que tenemos que distribuirlo

00:30.630 --> 00:32.460
por un montón de servidores diferentes

00:32.460 --> 00:33.810
en todo el mundo.

00:33.810 --> 00:36.300
Pero cuando un estudiante quiere visitar mi sitio web,

00:36.300 --> 00:38.340
no tiene que elegir un servidor específico.

00:38.340 --> 00:41.070
En vez de eso, van a diontraining. com y nuestro equilibrador

00:41.070 --> 00:43.230
de carga y conmutador de contenidos redirige

00:43.230 --> 00:45.960
esa petición al siguiente servidor disponible para

00:45.960 --> 00:47.460
poder procesarla.

00:47.460 --> 00:49.590
De hecho, tenemos montones de servidores

00:49.590 --> 00:50.880
repartidos por todo el mundo

00:50.880 --> 00:53.100
para atender todas esas peticiones.

00:53.100 --> 00:55.230
Ocurre exactamente lo mismo con Netflix

00:55.230 --> 00:57.480
o Hulu o Facebook o Amazon, pero a una

00:57.480 --> 00:59.280
escala mucho mayor.

00:59.280 --> 01:01.920
Todos estos grandes sitios web tienen que utilizar un equilibrador

01:01.920 --> 01:03.570
de carga, de lo contrario un solo servidor

01:03.570 --> 01:05.430
simplemente se colapsaría bajo la carga y

01:05.430 --> 01:06.263
sufrirían un ataque

01:06.263 --> 01:08.400
de denegación de servicio autoimpuesto debido

01:08.400 --> 01:10.650
a la popularidad de su sitio web.

01:10.650 --> 01:12.510
Ahora bien, un equilibrador de carga actúa esencialmente

01:12.510 --> 01:13.500
como un policía de tráfico,

01:13.500 --> 01:15.120
sentándose delante de sus servidores y dirigiendo

01:15.120 --> 01:17.310
la petición del cliente a los servidores que están más disponibles

01:17.310 --> 01:20.970
para satisfacer esas peticiones en un momento dado.

01:20.970 --> 01:23.940
esto maximiza la velocidad de respuesta al usuario y utiliza

01:23.940 --> 01:25.530
de forma más eficiente toda la capacidad

01:25.530 --> 01:28.170
existente de sus servidores para todas las peticiones

01:28.170 --> 01:30.060
de sus usuarios.

01:30.060 --> 01:32.220
La razón por la que un balanceador de carga es tan importante,

01:32.220 --> 01:34.230
es que es una de las cosas clave que podemos hacer para

01:34.230 --> 01:36.750
ayudar a defendernos contra un Ataque de Denegación de Servicio

01:36.750 --> 01:39.270
o un Ataque Distribuido de Denegación de Servicio.

01:39.270 --> 01:41.730
Ahora bien, ¿qué es un ataque de denegación de servicio?

01:41.730 --> 01:43.560
Pues bien, un ataque de denegación de servicio

01:43.560 --> 01:46.410
consiste en inundar continuamente los sistemas de la víctima

01:46.410 --> 01:48.090
con peticiones de servicios, lo que provoca

01:48.090 --> 01:50.070
que el sistema se quede sin memoria y acabe por

01:50.070 --> 01:51.570
bloquearse.

01:51.570 --> 01:52.830
Ahora bien, la mayoría de los sistemas

01:52.830 --> 01:55.230
modernos no pueden ser derribados por una sola máquina.

01:55.230 --> 01:58.230
Así que, en su lugar, los atacantes utilizan un ataque DDoS o ataque

01:58.230 --> 02:00.540
distribuido de denegación de servicio.

02:00.540 --> 02:02.490
En un ataque distribuido de denegación de

02:02.490 --> 02:04.920
servicio, en lugar de que un único atacante se dirija

02:04.920 --> 02:07.200
a un servidor, hay cientos o incluso miles de máquinas

02:07.200 --> 02:10.050
que lanzan simultáneamente ese ataque contra el servidor, para

02:10.050 --> 02:11.670
forzar su desconexión.

02:11.670 --> 02:14.040
En marzo de 2018, por ejemplo, GitHub fue golpeado

02:14.040 --> 02:16.410
por el mayor DDoS hasta la fecha, donde decenas

02:16.410 --> 02:18.570
de miles de puntos finales únicos llevaron

02:18.570 --> 02:20.160
a cabo un ataque coordinado para

02:20.160 --> 02:22.230
golpear ese servidor con un pico de tráfico

02:22.230 --> 02:25.620
que midió 1. 35 terabits por segundo.

02:25.620 --> 02:28.980
Esto obligó a desconectar el sitio durante cinco minutos.

02:28.980 --> 02:30.750
Pero la verdadera pregunta es, ¿cómo podemos

02:30.750 --> 02:32.670
sobrevivir a uno de estos ataques y evitar

02:32.670 --> 02:35.760
que derriben los servidores de nuestra organización?

02:35.760 --> 02:37.620
Sólo tenemos que fijarnos en Amazon para conocer

02:37.620 --> 02:39.330
algunas de las mejores prácticas.

02:39.330 --> 02:41.520
Verás, en febrero de 2020, Amazon sufrió

02:41.520 --> 02:44.130
el mayor ataque DDoS hasta la fecha, incluso mayor

02:44.130 --> 02:45.630
que el de GitHub.

02:45.630 --> 02:47.130
Y hubo un ataque coordinado

02:47.130 --> 02:49.230
para golpear ese servidor con un pico

02:49.230 --> 02:52.410
de tráfico que midió 2. 3 terabits por segundo, pero

02:52.410 --> 02:55.470
debido a la buena arquitectura de seguridad que tienen

02:55.470 --> 02:57.480
y a su capacidad de escalar recursos

02:57.480 --> 02:58.950
para sostener ese ataque,

02:58.950 --> 03:01.650
no sufrieron ningún tiempo de inactividad durante

03:01.650 --> 03:03.900
el ataque, a pesar de que era un 70% mayor

03:03.900 --> 03:05.880
que el que tumbó GitHub.

03:05.880 --> 03:07.410
La primera técnica que utilizaron

03:07.410 --> 03:09.750
se conoce como blackholing o sinkholing.

03:09.750 --> 03:10.800
Se trata de una técnica

03:10.800 --> 03:13.020
que identifica cualquier dirección IP atacante

03:13.020 --> 03:14.400
y enruta todo su tráfico a un

03:14.400 --> 03:17.160
servidor inexistente a través de una interfaz nula, deteniendo

03:17.160 --> 03:19.410
eficazmente el ataque.

03:19.410 --> 03:22.050
Por desgracia, los atacantes siempre pueden trasladarse a una

03:22.050 --> 03:23.760
nueva IP y reiniciar el ataque de nuevo.

03:23.760 --> 03:25.950
Así que no evitará un DDoS para siempre, pero

03:25.950 --> 03:27.480
le hará ganar algo de tiempo mientras

03:27.480 --> 03:29.640
trabaja en otras mitigaciones.

03:29.640 --> 03:32.070
Los IPS, o sistemas de prevención de intrusiones, también

03:32.070 --> 03:33.510
pueden utilizarse para identificar

03:33.510 --> 03:35.730
y responder a ataques de denegación de servicio.

03:35.730 --> 03:37.560
Esto puede funcionar bien para los ataques

03:37.560 --> 03:38.520
a pequeña escala contra

03:38.520 --> 03:40.920
su red, pero no va a tener suficiente capacidad de procesamiento

03:40.920 --> 03:42.780
para manejar un ataque a gran escala, como

03:42.780 --> 03:45.060
el que se dirigió a Amazon.

03:45.060 --> 03:46.920
Ahora bien, uno de los métodos más eficaces

03:46.920 --> 03:49.140
es utilizar una infraestructura elástica en

03:49.140 --> 03:52.290
la nube, ya que permite escalar a demanda según sea necesario, de

03:52.290 --> 03:54.300
modo que se puede capear el ataque.

03:54.300 --> 03:55.770
El problema de esta estrategia es que

03:55.770 --> 03:57.090
la mayoría de los proveedores de

03:57.090 --> 03:58.920
servicios te cobrarán en función de la capacidad

03:58.920 --> 04:00.510
y los recursos que utilices.

04:00.510 --> 04:02.190
Por tanto, a medida que aumentamos la escala,

04:02.190 --> 04:04.380
esto hace que recibamos una factura mucho mayor de nuestro

04:04.380 --> 04:05.940
proveedor de servicios en la nube y esto

04:05.940 --> 04:07.320
puede ser algo por lo que no estemos

04:07.320 --> 04:09.390
obteniendo ningún retorno de la inversión, porque

04:09.390 --> 04:12.030
todo ese tráfico no estaba generando ningún ingreso para nuestra

04:12.030 --> 04:13.110
organización, todo era sólo

04:13.110 --> 04:15.090
parte del ataque.

04:15.090 --> 04:17.280
Dicho esto, al menos sigues en línea para atender

04:17.280 --> 04:18.750
a tus clientes de pago.

04:18.750 --> 04:20.400
Así que se convierte en una cuestión de si

04:20.400 --> 04:22.140
usted puede permitirse el lujo de durar más

04:22.140 --> 04:24.213
tiempo que el ataque DDoS puede seguir adelante.