[0:00]Como muchos sabréis, nosotros hace poco más de un año creamos Mastermind, que es una plataforma diseñada para aprender desde cero conceptos del mundo de la tecnología. Tenemos cursos de programación, ciberseguridad, hardware, modding, sistemas operativos, robótica, desarrollo web, o sea, tenemos realmente un poco de todo. Y la verdad, estoy super orgulloso de lo que estamos haciendo, estamos realmente reuniendo una buena colección de cursos con profesores además que son alucinantes. Por ejemplo, mismamente los últimos tres cursos que hemos publicado son con SFDX Show, el maestro en persona, Beta Deck, un pedazo de senior developer y Sara Stech, que también tiene unos vídeos muy interesantes sobre todo el tema de hardware. Además, en breve vamos a publicar un curso con Soy Dalto y este año se vienen tres cursos bastante potentes míos antes de final de año que creo que os van a gustar muchísimo. Así que creo que la cosa realmente está cogiendo bastante nivel. Sin embargo, hoy vamos a hablar de una pequeño paréntesis oscuro que ha ocurrido en la plataforma y es algo que me apetece mucho compartir con vosotros y creo que es una situación de la que todos vamos a poder aprender. Hace poquito más de 2 semanas, sufrimos el ataque de un hacker que tuvo nuestra plataforma caída durante una semana entera. Tranquilos que no robaron nada, no robaron datos, nada por el estilo, o sea, no es este tipo de ataque, es otro tipo de ataque. Un ataque que fue toda una batalla bastante épica, por cierto, y hoy os la voy a contar. Todo empezó el domingo 30 de agosto, recibimos un email de nuestros proveedores de infraestructura, que nos estaban preguntando si estábamos haciendo un test de carga en el servidor, porque básicamente les estaba llegando un gran número de peticiones, un número mucho más alto de lo normal. Y si esto te suena chino, no te preocupes porque enseguida lo vamos a entender. Mastermind es una página web. Las páginas web para poder funcionar, necesitan un programa llamado servidor web. Hay varios programas de este tipo, como por ejemplo Apache o Engines. El servidor web es un programa que está abierto constantemente a la espera de peticiones. Estas peticiones llegan desde el navegador del usuario. Cuando un usuario escribe en su navegador mastermind.ac/cursos, el PC donde está corriendo este programa, servidor web, recibe la petición y determina cuál es la página que el usuario quiere consultar. Por ejemplo, en este caso sería la lista de cursos que tenemos en Mastermind. Cuando el servidor recibe la petición, se encarga de ejecutar el código que el programador ha determinado para esa ruta en concreto. En nuestra web, por ejemplo, el código es PHP y el servidor web es quien se encargaría de lanzar esa ejecución en tiempo real. En este caso concreto, el código va a preguntar a una base de datos MySQL, cuál es la lista de cursos actuales. El programa en PHP recibe esa lista de cursos y la coloca en un documento HTML. Devuelve ese documento HTML al navegador y es cuando el navegador empieza a interpretarlo, o sea, convertir ese HTML en algo que va a aparecer en la pantalla de nuestro navegador web. Todo esto ocurre en cuestión de milisegundos, a veces puede tardar algún segundo si la web va un poco lenta, pero bueno, lo importante aquí es entender que detrás de una página web hay un PC con un servidor web ejecutándose. Y este servidor web hace una serie de tareas cada vez que un usuario se conecta a la página web para que la web se pueda cargar. Cada petición, de hecho, como podéis imaginar, tiene un pequeño coste de procesador, de RAM y de ancho de banda. De hecho, podríamos decir que estos tres recursos son los importantes a la hora de servir una página web, ya que no hay ni gráfica ni nada de esto implicado. Eso nos lleva al test de carga. Nuestros proveedores nos estaban preguntando si hacíamos un test de carga. ¿Qué es un test de carga? Básicamente es simular una gran cantidad de tráfico que llega de repente a la página web, o sea, nosotros vamos a hacer a propósito nosotros mismos un montonazo de peticiones de carga a la página web, a ver hasta qué punto es capaz de aguantar ese ordenador donde está la web en ejecución. En otras palabras, es testear el servidor. Ver cuántas peticiones hacen falta para que este servidor se quede totalmente saturado.
[3:31]Y para qué queremos hacer esto? Bueno, a ver, realmente el tráfico de una web es más o menos predecible, más o menos siempre es el mismo, no hay una diferencia muy grande de día a día. A menos que hagamos una campaña de marketing, como por ejemplo, yo que sé, Black Friday, no?
[3:47]Páginas web como PC Componentes, en el pasado, sí que han tenido algunos problemas para cargar durante el Black Friday. La web funcionaba demasiado lenta o directamente no cargaba porque quizás esta gente, yo no lo sé porque no trabajo ahí, pero quizás no habían hecho las suficientes pruebas para saber qué pasaría con tantos usuarios al mismo tiempo, o les vino muchísima más gente de la que ellos esperaban y de repente la web pues estaba totalmente saturada. Ahora, en España, en el momento que estamos, es la vuelta al cole y es una época donde se suelen hacer ofertas, promociones y todo esto. Por eso nuestros proveedores se pensaron que a lo mejor estábamos haciendo alguna prueba de carga antes de lanzar nuestra campaña de vuelta al cole. Pero nosotros no estábamos haciendo ningún tipo de prueba por el estilo. Y si no eran pruebas, la alternativa solo podía ser una, estábamos bajo el ataque de un hacker. Ahí fue cuando me puse a revisar un poco mi email, a ver si tenía algo relacionado con esto que estaba pasando. Y entré en mi cuenta de contacto del canal de YouTube. Y en esa cuenta nosotros recibimos muchísimos mensajes cada día, por lo que no había visto que hacía 24 horas aproximadamente, habíamos recibido un mensaje bastante inquietante. El mensaje decía, Estamos haciendo un ataque dedos a su página web Mastermind.ac. Si deseas detener el ataque, envía 1000$ en Bitcoin a esta dirección y el ataque se detendrá. En otras palabras, nos estaban pidiendo un rescate. En ese momento, el ataque iba creciendo poco a poco de magnitud y la página web estaba funcionando bastante lenta ya. El hacker estaba haciendo cientos de miles de peticiones por minuto a la página web y si seguía aumentando, pues el servidor al final no iba a ser capaz de aguantar la carga e iba a petar, o sea, la web iba a estar completamente caída. Estábamos sufriendo lo que se conoce como un ataque DDoS o ataque de denegación de servicio distribuida. El ataque DDoS busca denegar el servicio de la página web, en otras palabras, que la web no funcione, haciendo cientos de miles o incluso millones de peticiones a la web en cuestión de minutos para que el servidor se sature y no responda más. De esto ya hablamos en el vídeo de el Ciber-Ataque más grande de la historia, empezó con Minecraft. En ese vídeo, de hecho, hablamos de la botnet Mirai y de cómo un par de adolescentes fanáticos del anime que tenían un servidor de Minecraft privado crearon una de las armas de destrucción digital más grandes jamás vista, solo para denegar el acceso a los servidores de Minecraft de la competencia y llevarse los usuarios. En ese vídeo ya explicamos bastante bien qué es un DDoS y de hecho, yo te recomiendo verlo para entender un poco mejor todo este caso. Pero voy a intentar que lo entiendas de todos modos, aunque no hayas visto ese vídeo. Recapitulando, nuestra web iba muy lenta, cientos de miles de conexiones a cada minuto, saturando nuestro servidor donde estaba la página web, lo que hacía que los alumnos no pudiesen entrar. Y ahí teníamos al hacker pidiéndonos un rescate. Por lo que yo en ese momento estimaba que había cuatro posibles escenarios. El primero era pagar el rescate y esperar que el ataque pare, cosa que yo no iba a hacer. Pero yo creo que si hubiésemos pagado, el ataque se hubiese detenido. Además, yo creo que la cifra es clave, no, los 1000$ porque, digamos que tu web no funciona durante 3, 4 días. A ver, ellos ya eligen webs que están funcionando bien, que tienen una cierta facturación, porque saben que si a una empresa que más o menos le está yendo bien, le piden 1000$, pues los paga, porque la alternativa es quedarse sin web y sin web, pues no vendes, y si no vendes, pues no ganas dinero y puedes incluso tener pérdidas, dependiendo de cuántos empleados tengas contratados y cuánto dependes de esas ganancias, no? Por lo cual, esos 1000$ son como un pago muy fácil de hacer, no, para las empresas. Pero yo estoy bastante seguro de que si los pagas, más adelante, te vienen a pedir más, o sea, vamos, de cabeza. Así que ese es el primer escenario, pagar y que el ataque pare, pero yo me niego rotundamente a hacerlo. Segundo escenario es que, bueno, si hubiese sido un ataque así bastante tontito, vale, algún chaval que hace algún tipo de ataque pequeñito y tal y se me, pongamos que tengo un filtro de dos y me llegan algunas peticiones, pues yo puedo llegar a ampliar los recursos de mi servidor, o sea, asignar más RAM, más ancho de banda y más procesador, para que mi servidor aguante el ataque, vale, lo aguante bien, porque tampoco es un ataque tan grande, y cuando se canse, pues ya bajo la infraestructura, no, y la dejo un poco más pequeña. Lo que pasa que este ataque pequeño precisamente no era, era un ataque que empezó pequeño y fue a más y más y más, y bueno, ya veréis las cifras, porque son bastante bastante desorbitadas. Además, esta solución no es ideal, es muy fácil que te produzca unos gastos super altos. Y esto pasó, de hecho, lo vimos en el caso de Mirai, que de repente te meten muchísimas peticiones, tú para aguantar la carga y no dejar a tus usuarios sin servicio, empiezas a ampliar los recursos y de repente te está creando unos agujeros de dinero brutales, porque claro, tú todos esos recursos que estás usando de tu proveedor, los tienes que luego pagar, no? O sea, es un servicio al final, no, por lo cual puede salir bastante mal. Ahora la solución ideal es el tercer escenario. El escenario en el que tu web está preparada para resistir este tipo de ataques y el ataque no te afecte prácticamente nada. El hacker intentaría atacar durante algunas horas con distintos tipos de cargas, pero no lo conseguiría. Ahora, lo curioso es que nosotros estábamos bien preparados para recibir ataques de dos. El problema aquí, la cosa super rara, es que la protección contra ataques de dos no estaba funcionando, o sea, se lo estaban saltando completamente. Así que primer escenario pagamos, segundo escenario intentamos aguantar, tercer escenario tenemos una protección anti DDoS y eso nos lleva al cuarto y último escenario que es el que nos tocó vivir, bueno, el que elegimos también, que es vamos a dejar que el ataque tumbe la web. No vamos a pagar el rescate y vamos a trabajar contrarreloj para intentar frenarlo y mitigarlo lo antes posible. Mientras tanto, nuestra página web no funcionaría, pero no le íbamos a dar la satisfacción al hacker de cobrar su dinero. Bueno, pues habiendo explicado un poco la situación en la que estábamos, vamos a analizar juntos este ataque porque es bastante interesante. Del atacante no sabíamos nada, absolutamente nada, solo sabíamos que era alguien que ha estudiado bastante bien nuestro perfil. Básicamente, porque sabía quién soy y sabía que soy uno de los fundadores de la empresa, porque el email, de hecho, al que me escribió, está publicado únicamente en tres sitios, en mi canal de YouTube, en mi cuenta de Twitter y en mi cuenta de Instagram, que no tienen nada que ver con la página web de Mastermind. La persona que me escribió, me escribió desde la cuenta destroy@protonmail.com, por lo que es literalmente imposible rastrearla. Ese email y ese nombre de usuario no han sido registrados en ninguna otra plataforma que yo haya encontrado. Y ProtonMail, que es el servicio que usó para contactarme, es una plataforma de email ultra segura con sede en Suiza, donde todo el mail está encriptado y protegido por las leyes de privacidad suizas. Es una cuenta creada a propósito para este ataque. Además, la cuenta fue creada en la plataforma sin ningún tipo de método de recuperación, por lo que no hay ninguna forma de intentar recuperar la contraseña, hacer algún truco de ese estilo, porque no hay ningún tipo de método de recuperación. Por otra parte, la dirección del monedero de Bitcoin donde me estaba pidiendo el rescate, también era nuevo, no había sido usado nunca, no tenía ninguna transacción asociada. De hecho, la única pista la podemos ver en la forma de escribir del usuario. El mensaje empieza con hello sir, que es una forma típica de saludar que usan en los emails los asiáticos. Los emails suelen empezar con Dear Sir, hello sir, cosas por el estilo, y el Dear Sir es especialmente común para países como Pakistán e India, por lo que es bastante probable que este atacante estuviese en Asia, tirando hacia Pakistán, India, por esa zona, que además muchos ataques suelen venir de ahí. Como os dije, lo que hacía el usuario era mandar cientos de miles de peticiones a mi página web todo el rato sin parar, que esto era lo que hacía que no funcionase. Pero, ¿de dónde venían estos ataques? Pues desde todo el planeta al mismo tiempo, de hecho, desde cientos de miles de ordenadores de todo el planeta al mismo tiempo. Se trataba de una botnet. Una botnet, como vimos ya en el vídeo sobre Mirai, es cuando un hacker tiene una gran red de ordenadores bajo su control. Estos ordenadores, que pueden ser cientos, miles o incluso millones de ellos, están infectados con algún tipo de malware. Ese malware no es nada más que un programita malicioso que se queda latente a la espera en el ordenador de su usuario. Sin hacer nada, vale, el programita está ahí y no hace nada. Pero cuando nuestro hacker decide hacer un ataque, desde su propio ordenador o bueno, desde algún ordenador que él controla, lanza un mensaje a todos los ordenadores del mundo que tienen este malware instalado y les pide que hagan una petición a una página web en concreto, a una página web, a un servidor, a donde sea. De esa manera, el ordenador que tiene el malware, imagínate que tú en tu casa tienes este malware instalado y no lo sabes, pues ese ordenador cargaría la página web de mi servidor sin que tú ni siquiera lo sepas, o sea, todo ocurre de fondo, en segundo plano. Y lo peor es que ni siquiera lo notarías realmente, no, o sea, a lo mejor notas el PC un poco más lento, internet se satura en el caso de que estés haciendo muchas peticiones, pero prácticamente nada. Y esto, aunque dé un poco de miedo, significa que tu ordenador desde el que estás viendo esto, podría hacer parte de una botnet sin que tú lo sepas. Ahora, la pregunta clave es, ¿cómo consigue un ciberdelincuente hacerse con la botnet? O sea, ¿cómo consigue todos estos ordenadores zombie? Bueno, pues existen varias formas. El primer paso es crear un malware para controlar los ordenadores, aunque también podemos bajarlo de internet, o sea, existen proyectos en GitHub con malware preparados para infectar ordenadores que ya te lo descargas y con cuatro pasos ya lo tienes funcionando. Luego, aparte de eso, necesitamos alguna forma de distribuirlo, no, de mandárselo a este usuario final. Hay muchas formas de hacer esto, realmente. Podríamos, pues, mandarle un mail diciendo que se baje una factura. Podríamos subir un crack para Photoshop, lo típico en la medicina, ¿no?, de Photoshop o de cualquier programa, y que cuando lo ejecutas, te está instalando el malware en el ordenador, o, por ejemplo, algún programita para activar Windows gratis, que te lo descargas, lo ejecutas, no hace nada y de repente tu ordenador ya está infectado. Y bueno, realmente el atacante no necesita sí o sí tener una botnet en su poder, sino que además hoy en día se puede contratar, o sea, tú puedes contratar un servicio de dos a personas que tienen una botnet de ellos mismos. Esto se hace en la Dark Web y no es algo que, que lo tengas en eBay, no, comprar una botnet, pero sí que lo puedes hacer, puedes contratarlos. Pero bueno, yo creo que en este caso concreto no es así, yo creo que es un tipo de organización criminal que debe estar por ahí, Pakistán, India, algo por el estilo, que tiene una botnet bastante decente y que eligen ellos a propósito ciertas empresas bien escogidas a dedo. Estudian el perfil de la empresa, encuentran quién es el propietario. Y eligen además el mejor momento para atacar, porque esta gente, pensad que nos atacaron en la última semana de agosto, el sábado, la madrugada, o sea, realmente, mhm, el mejor momento que podían elegir. Es un momento en el que es fin de semana, en España estamos de vacaciones y vamos, o sea, lo más probable es que te cueste bastante poder arreglarlo por tu cuenta, no, si tú eres el el dueño de la empresa. Ahora, como os dije antes, nosotros tenemos un sistema para evitar ataques de dos, que no funcionó para nada. El sistema que nosotros tenemos se llama Cloudflare. Cloudflare es una empresa que se dedica a estar justo entre el servidor de tu web y el navegador del usuario. Cuando el usuario escribe mastermind.ac en su navegador y da enter, el nombre de mastermind.ac no va directamente al servidor web, sino que va a Cloudflare y luego Cloudflare decide qué hacer con eso, que normalmente es pues, redireccionar la petición a nuestro servidor web. ¿Por qué íbamos a querer tener algo así? Pues básicamente por tres motivos. El primero, lo menos interesante, analíticas, vale, pues tenemos estadísticas, analíticas, cuánta gente se conecta, de dónde, etcétera. Pero también tenemos otras analíticas, tenemos analíticas de Google, de nuestra plataforma, del servidor. Pero bueno, de todos modos, pues es interesante tener estos datos también en Cloudflare, de tráfico, de un montón de cosas que son interesantes. El segundo motivo es la caché, ¿qué significa la caché? Bueno, pues básicamente que Cloudflare se acuerda de cómo es tu página web. Y en el caso de apartados concretos que nunca cambian, pues en lugar de molestarte a ti, o sea, en lugar de pedirle a tu servidor web que te reenvíe esa página, pues directamente se la envía al usuario. Pero sobre todo, para nosotros, lo más importante que hace Cloudflare es frenar los ataques de dos. Cloudflare estaba muy bien preparado para mitigar ataques de dos, tiene un firewall que es muy completo y muy configurable. Pero que no estaba funcionando. De hecho, cada dos por tres sí que detectaba que había un ataque, pero solo era capaz de tener entre un 10 y un 15% de las peticiones, como veremos enseguida. ¿Por qué? Es una buena pregunta. Porque el ataque estaba muy bien hecho, las peticiones de los usuarios parecían reales. Veréis, en un ataque de dos, la cosa se puede complicar muchísimo porque puede ser bastante difícil de mitigar. Para poder parar un ataque de dos, nosotros tenemos que ser capaces de distinguir entre una petición del atacante y una petición de un usuario. O sea, imagínate que un usuario está tranquilamente haciendo los cursos y yo, pues a ese usuario le corto la conexión. Pues esto no puede ser, no, yo tengo que ser capaz, de alguna forma, de separar el uno del otro. El ataque empezó de forma muy progresiva, vale. Empezó a lo largo de los días, al principio no nos dimos cuenta, empezó con unas pocas peticiones, luego fue aumentando, aumentando, aumentando, por lo que Cloudflare, así de buenas a primeras, no se dio cuenta que era un ataque de dos, o sea, él notó que había un incremento en los usuarios, pero no sabía por qué, o sea, podía ser un incremento gradual, porque simplemente, pues, mucha gente estaba conociendo la página. Además, el ataque, la mayoría del tiempo, no era muy grande, o sea, al principio la media era de 250.000 peticiones en un lapso de 10 minutos, que a ver, son peticiones, pero no es una locura, no es el gran ataque de dos del siglo, vale. Y el problema es que esas 250.000 peticiones venían de todas partes del mundo. O sea, solo había dos ordenadores, en este lapso de 15 minutos, que estaban haciendo 100 peticiones, lo que significa que eran muchísimos, muchísimos ordenadores haciendo muy pocas peticiones. De esa manera, es muy difícil darte cuenta cuáles son usuarios de verdad y cuáles no. Y por otro lado, como os decía, estas peticiones no son una locura, se pueden llegar a mitigar, pero el atacante hizo muy bien los deberes, estuvo estudiando, bueno, supongo yo, eh, por por cómo vi el patrón del ataque, el atacante estuvo estudiando cada una de nuestras páginas, vale, cada uno de los apartados de la página web y cogió en concreto un apartado que tardaba bastante en cargar. Por lo cual, estaba haciendo más trabajo de servidor.
[16:37]Así que fue atacar ese talón de Aquiles, directamente, empezó a cargar esa página como si no hubiese un mañana desde un montón de ordenadores a la vez de todo el mundo, donde aparentemente, aparentemente lo que había detrás era un navegador de verdad, que cargaba la web, cargaba todas las imágenes, hacía todo como lo tenía que hacer. De hecho, hay otra barrera en Cloudflare que también es muy interesante y que nosotros activamos en ese momento, que es el JavaScript challenge. Que lo que hace es que tu navegador tenga que ejecutar un temporizador de algunos segundos antes de cargar la web definitiva. Y esto lo que hace es que si tú atacas desde un bot, pues te encuentras la página que es de Cloudflare, no es la final y tiene un temporizador y hasta que ese temporizador no acaba, no llegas directamente a la web final. Y aún así no había manera, aún así nos estaba llegando tráfico de todas maneras sin parar a la página web, a nuestro servidor. Ahora, de vez en cuando, el atacante, para provocar un pico de ataques, aumentaba la frecuencia de ataques de ciertos ordenadores, o sea, cogía, no sé, a lo mejor 100 ordenadores y los hacía atacar con muchísima más intensidad. Y ahí es cuando Cloudflare sí que detectaba, no, que había un ataque de dos y lo frenaba, pero claro, lo que frenaba era un 10, 15% del tráfico que estábamos recibiendo. Eso no era suficiente, o sea, es muy poquito lo que está filtrando. Por lo que, aparentemente, no podíamos mantener la web funcionando, no paraba de caerse y necesitábamos sí o sí algo de tiempo para empezar a buscar soluciones en el servidor, ver qué podíamos hacer para que esto, pues, pare del todo. Así que, primero que nada, para bloquear los ataques en seco, se me ocurrió que podía bloquear todos los países que no fuesen hispanohablantes. Entre esos países, pues, había un montón que tenían muchísimos ataques, tales como China, Rusia, Vietnam, Tailandia, Indonesia, India, Brasil, Alemania, Estados Unidos. A ver, bloquear por países no es una buena solución. No es ideal, no es definitiva, ni nada, pero por lo menos, ganábamos algo de tiempo y los alumnos iban a poder seguir cursando los cursos. Ahora, el atacante se dio cuenta, no fue inmediato, vale, pero lo entendió. Y estoy bastante seguro de que no es alguien hispanohablante, porque para alguien que hable español, si tú ves el patrón de las peticiones que te están fallando, pues es bastante claro que lo que yo estoy haciendo es bloqueando los países que no hablan español. Y para una persona que habla español es muy fácil saber cuáles son esos países y cuáles no.
[18:39]Así que el hacker no entendió el patrón así de buenas a primeras, pero bueno, al final lo entendió, empezó a entender lo que estaba pasando y empezó a incrementar los ataques sobre todo desde Latinoamérica y España. Empezaron a venir cada vez más ataques desde Perú, de Chile, de Argentina, de México, de Costa Rica. Y esto nos estaba diciendo una cosa bastante clara, y es que este atacante no nos estaba soltando aún todo el poder de ataque que tenía, o sea, solo nos estaba atacando con una parte pequeña de su red. Lo más probable es que tenga la red atacando varias páginas web al mismo tiempo y nosotros pues eramos una más de estas. Lo que pasa que al ver que el ataque estaba yendo por ahí, pues él se picó y empezó a sacar todo el potencial de Latinoamérica y atacarnos directamente con eso. Aparte de bloquear los países, la segunda cosa que hice fue pagar una cuenta más cara de Cloudflare, porque la la básica pues tiene cosas que están bien, pero luego si pagas una más cara, tienes el control avanzado sobre una funcionalidad muy especial que se llama anti-bot. Y es un tipo de filtro que es distinto, es más avanzado y analiza las peticiones de una en una, buscando ciertos patrones. A través de heurística, intenta determinar si esta petición puede ser extraña, puede ser proveniente de un bot, tampoco te explican cómo lo hacen, porque obviamente no quieren que los atacantes lo sepan, y aparte de eso, pues también tienen un sistema de inteligencia artificial que también se encarga de distinguir las peticiones buenas de las malas, usando datos históricos de la web. Ahora, lo que hace es a cada petición que llega a la página web, le asigna una puntuación de entre 0 y 100. Donde 0 es que definitivamente estamos delante de un bot y 100 es que definitivamente estamos delante de un ser humano. Pero claro, las peticiones normalmente no están en 0 ni en 100, sino que están en medio, no, por ejemplo, 25 puntos, podríamos decir que posiblemente sea un bot, pero vamos, no es seguro. Es un 75% seguro. Así que activamos este filtro y de buenas a primeras no hizo absolutamente nada. Seguíamos en las mismas. Pero con el bloqueo de país habíamos hecho muchísimo, aunque claro, a la que el hacker se puso a trabajar, pues empezó de nuevo a hacer que la web funcionara lenta. Ahora, a todo esto, nosotros ya habíamos avisado a nuestros usuarios de que teníamos problemas con el servidor. Mandamos un email a todo el mundo, a todos los usuarios, a los suscritos. Incluso puse un tweet para explicar todo lo que estaba pasando. También expliqué que se trataba de una botnet bastante grande, que ya habíamos encontrado una solución y que era cuestión de tiempo ponerla en marcha. Un tweet donde además estaba dejando bastante claro que no teníamos ninguna intención de pagar. Nada más poner ese tweet, pasaron, no sé, 10 minutos, un poco menos, voy y recibo un email del atacante diciéndome que no sea tonto y que, por favor, pague, que su botnet es gigante. Coincidencia, bueno, es posible, pero yo creo que no, yo creo que esta persona, pues me sigue en Twitter, porque justamente investigó la empresa, me siguió en Twitter y de ahí fue donde cogió además mi email personal, bueno, el de contacto de de del canal de YouTube. Y la verdad, pues, no sé, creo que han hecho un buen trabajo a la hora de investigarnos antes de atacar y de buscar todos esos puntos débiles, encontrar la hora, el mes ideal, el momento ideal, ¿no?, para poder hacer este ataque lo más exitoso posible. Pero obviamente con nosotros no iban a poder. También tomamos otra decisión, y es que, después de 3 días en los cuales nuestros alumnos no podían entrar en Mastermind, no queríamos dejarlos tirados, así que montamos una plataforma paralela en otro servidor, todo duplicado, alternativo, con otro dominio, otra URL y todo distinto, para pasárselo a nuestros usuarios. Y esto también tenía su riesgo, porque si el atacante estaba suscrito a Mastermind, pues significaba que se iba a enterar de que también teníamos una segunda web y también nos la iba a tumbar. Pero bueno, nos la jugamos y al final salió bien. No se enteró y los alumnos pues ya tenían donde seguir estudiando. Que, por cierto, yo estoy super agradecido de todo el apoyo que nos habéis dado, la comprensión, el apoyo, la camaradería. La verdad que yo lo flipo, o sea, en mi vida me imaginé que tendría una comunidad tan top como la que tengo. O sea, es brutal, es brutal el sentimiento que que nos habéis transmitido. Sobre todo, muchas empresas tienen miedo, ¿no?, de decir, nos están atacando, nos están hackeando, nos está pasando esto. Yo, pues, fui por delante, no sabía qué me iba a encontrar, y lo que me encontré fue un montón de apoyo por vuestra parte, así que os doy las gracias. Ahora, fueron pasando las horas y las horas y las horas y de repente, de la nada, de la nada, el filtro anti-bot empezó a funcionar. Primero empezó a filtrar algunas peticiones, así, tres o cuatro y cada vez más y más y más, hasta que parecía que estaba filtrando la gran mayoría. Ahí fue cuando dije, pues, mira, igual desactivo el el filtro este de países y ya, pues, la regla anti-bot empieza a filtrar todo, así que me la jugué, bueno, tampoco pasaba nada, ¿no?, porque ya estábamos bajo ataque total, así que desactivé la regla de países y, efectivamente, el sistema anti-bot ya se había entrenado y ya estaba haciendo, efectivamente, su trabajo, de filtrar una gran parte de peticiones. Ahora, el hacker estaba muy activo, él ya se estaba dando cuenta de lo que estaba pasando, estaba viendo que su ataque ya no era efectivo y decidió empezar a aumentar el número de ataques de forma brutal. O sea, el tío dijo, vale, me están bloqueando la mayor parte de los ataques, pues no pasa nada, yo aumento la apuesta, me meto un all-in. Y empezó a hacer ataques de 22 millones de peticiones en un lapso de 15 minutos con un montón de máquinas en todo el planeta. O sea, el atacante mantenía siempre un nivel de ataque base, que era más o menos 150.000, 250.000 ataques en un lapso de 15 minutos, que esto lo aguantábamos bien, sin problema, pero, de repente, él cogía y se metía un ataque super bestia que duraba 2 horas, en el cual, en 15 minutos, recibíamos unas 20 millones de request, en media, más o menos. O sea, Cloudflare estaba haciendo un trabajo brutal, hay que decirlo, o sea, la verdad que era descomunal la cantidad de request que estaban deteniendo, pero entre un 5 y un 15% se seguían filtrando hacia nuestro servidor y esa carga seguía siendo relativamente alta. Por lo cual, la web de Mastermind seguía sin funcionar, pero aún así, nosotros seguíamos trabajando con nuestros proveedores para intentar que los cambios estén implementados al 100%, que tengamos este firewall y que todo esté un poco más protegido del lado del servidor. Y finalmente, cuando nuestro partner desplegó los cambios, el ataque dejó de hacer efecto. Habíamos vencido al atacante. El ataque siguió durante algunas horas, tirando con todo lo que tenía, con picos de 18 millones de peticiones, pero finalmente el sábado a la 1:30 de la madrugada, después de casi una semana de haber empezado el ataque, se cansó y desistió y no volvimos a saber nada más de él. Habíamos vencido el ataque de dos. Y no solo eso, sino que hemos aprendido muchísimo, hemos fortificado nuestra plataforma y hemos podido crear este vídeo para levantar conciencia sobre estas cosas. Hoy en día los ciberdelincuentes están atacando un gran número de empresas, muchas pagan sin rechistar para poder mantener sus servicios y no es algo que suelan comentar, porque realmente no es algo de lo que tienes que estar orgulloso. Pero nosotros decidimos, por un lado, no pagar y aparte contar nuestra historia para que sepáis un poco lo que lo que tenéis que hacer, no. Y sobre todo, daros cuenta de que por mucho que nosotros pensemos que estamos protegidos para un ataque de dos, aunque tengas algún sistema para bloquearlos, un buen ataque bien pensado y bien ejecutado, es bastante difícil de mitigar. Y sobre todo, puede llegar a durar semanas, pero creo que aún así es importante no pagar, creo que es más importante invertir el dinero en intentar mitigar el ataque como sea, que no estar alimentando esta industria de cibercrimen. Porque básicamente, si pagamos, lo que estamos haciendo es financiar organizaciones criminales que van a usar ese dinero para desarrollar mejores botnets, para mejorar las herramientas y hacer ataques aún más difíciles de detectar y de mitigar, por lo que creo que pagar nunca tiene que ser una opción. Es fácil decirlo, pero creo que que no vale la pena, aunque perdamos algo de dinero y tengamos que compensar a nuestros clientes. Y hablando de eso, como os dije, hemos estado 3 días completos sin servicio antes de habilitar la URL alternativa, así que queremos compensar a todos nuestros usuarios, y no, no solo queremos compensar a los usuarios, queremos celebrar que hemos sobrevivido a nuestro primer ataque de dos. Esto al final es una fase del proceso de crecimiento de cualquier plataforma, y nosotros lo hemos vivido junto con nuestros usuarios, así que hemos creado el Día internacional de He sobrevivido el ataque DDoS. Y para celebrar ese día vamos a activar una página en la cual vais a poder registraros con un 50% de descuento durante las próximas 48 horas de la publicación de este vídeo. Por otra parte, también para disculparnos con nuestros usuarios, pues vamos a aplicar un descuento por valor de una semana de suscripción. Este descuento se va a aplicar de forma automática en el pago, no tenéis que hacer nada más, o sea, simplemente, si estáis suscritos, automáticamente se os descontará este dinero, y por último, queremos también recompensaros por haber sobrevivido a este ataque como campeones junto con nosotros. Y por eso vamos a enviar a cada uno de nuestros suscriptores un cupón de un mes gratis para regalar a cualquier persona que queráis, vale, a vuestro primo, vuestro padre, vuestro tío, vuestro amigo, a quien queráis, le podéis regalar este cupón. Ya tiramos la casa por la ventana. Así de contento me he quedado después de vencer al hacker. En fin, pues, esta ha sido la historia de nuestro ciberataque, del ataque de dos que han hecho nuestra página web y de cómo lo hemos mitigado. Obviamente hay ciertos detalles que no quiero compartir por motivos obvios, pero creo que con lo que hemos dicho, pues, hay hay bastante sobre lo que reflexionar y bastante que aprender. Si te ha gustado este vídeo, ya sabes lo que tenéis que hacer, déjanos una manita para arriba, suscríbete al canal y nos vemos en el próximo vídeo. Y me estoy quedando sin voz. Como podéis ver. Adiós.
