¡Muy buenas! ¿Qué tal? Bienvenido, bienvenida. Espero que estés súper bien, que estés preparado, preparada, porque hoy vamos a hablar de ataques, ataques a las páginas web, un montón de ataques.
Ya desde abril, si os acordáis, desde abril tuvimos ataques a la web de La Velada, que lo estuve comentando, donde nos atacaron con más de 120 millones de peticiones en una hora,
que hicieron más de un terabyte de ancho de banda, con cientos y miles de IPs distintas, y que no tuvimos ningún tipo de problema, porque pudimos parar el ataque.
Fijaos que tuvimos aquí 120 millones de peticiones, y ya lo comentamos en algunos vídeos, ¿vale? De que me estaban atacando las páginas web, os voy a explicar algunas estrategias, y las vamos a hacer.
Todo lo que vamos a aprender hoy va a ser pensado en la defensa, en defendernos, pero os voy a explicar los ataques. ¿Por qué? ¿Para que los hagáis? No.
No, porque es muy fácil. De hecho, le podríais preguntar a ChagPT y os va a explicar cómo hacer este tipo de ataque, porque es muy sencillo.
Le podríais engañar un poco, ¿vale? Pero el tema es que este tipo de ataque es demasiado sencillo de realizar desde tu ordenador, desde un servidor.
Lo puedes contratar el servidor, puedes ir cambiando, puedes hacer un montón de cosas. Pero lo importante no es tanto que hagas el ataque, que no te lo recomiendo,
porque además, si lo haces desde tu IP, te van a pillar en un momento, estás gastando recursos de forma tonta, que no tiene mucho sentido.
Tampoco es tan... No es tan importante, no es tan interesante lo que puedas llegar a hacer, porque no te creas que es tan fácil hacer daño.
No es fácil el hecho de que le pueda costar dinero a la otra persona, pero es interesante que sepáis cómo se hacen para que veáis cómo es el modus operandi
de estos ataques y entendáis cómo se tiene uno que defender, ¿vale? O sea, por ejemplo, cuando a mí me llegan todas estas peticiones,
aquí hay una estrategia detrás de cómo intentar hacerme daño. Y lo podéis ver, por ejemplo, aquí con los paths.
¿Veis aquí los paths? Que hay una barra, barra A, barra G, barra F. También lo podemos ver en los usuarios user agents, muy diferentes,
diferentes países, diferentes IPs. Pero ya se ve aquí alguna estrategia. Y os voy a contar algunas estrategias que se utilizan.
Desde ir a buscar, pues, APIs que sean lentas. Desde utilizar versiones de HTTP antiguas. Todo eso vamos a ver cómo lo tenemos que ir arreglando
para que no ocurra y no nos puedan atacar por ahí, ¿vale? Entonces, lo vamos a ir viendo poco a poco y vamos a ver cómo lo podemos hacer.
Yo pensando que me están atacando, pero no, es mi código mal hecho. No, se puede... También vamos a hablar de eso, de cómo notar si te están atacando
o no te están atacando, ¿vale? Eso lo vamos a ver desde el principio para que entendáis cuándo tenéis que entender... O sea, cuándo tenéis que pensar que os están atacando.
Entonces, venga, vamos a empezar con el curso que hay muchas cosas que comentar, hay muchas cosas que decir
y quiero que no os perdáis nada. Así que vamos por el principio y vamos a clarificar también algunos conceptos.
Pero vamos a hacer como una introducción. Empezamos con los ataques de la velada.
Ya en abril a mí me empezaron a atacar la página web de la velada que hicimos, la de Ibai Llanos.
La estuvimos desarrollando aquí todos juntos. ¿Y qué pasa? Pues que Ibai, bueno, como todos los streamers del mundo,
pues tiene amigos y también gente que no le cae muy bien y por lo que sea, o igual me estaban atacando a mí.
Nunca lo sabremos, nunca lo sabremos, ¿no? Pero lo interesante es que alguien decidió ponerme en la mirilla
y lo que hizo fue un ataque distribuido en el que utilizaba un rango muy grande de IPs
para atacarme e intentar tirar la página web. Vamos a ver esto porque esto sí que era un ataque
de denegación de servicio distribuido. Esto es importante, luego os explicaré más sobre esto,
porque hay mucha gente que confunde el DDoS. Esto no es siempre el ataque que le suele ocurrir a la gente.
De hecho, ya os voy a decir una cosa. Normalmente no se hace este ataque.
El ataque que vais a ver que es el más típico es el que hace una persona, no un DDoS.
Esto es un ataque distribuido de denegación de servicio.
Y vais a ver que este no es el ataque más típico porque mucha gente se cree que este es el ataque
que se está haciendo y no es el caso, ¿vale? En este caso sí que lo es porque tiene muchos rangos de IPs,
muchos user agents y esto sí que era distribuido, pero no es lo más normal.
Ahora lo veremos porque los ataques que muchas veces veis que le pasa a la gente en Vercell,
en Netlify y tal, no es este, no es este. De hecho, tiene otro nombre diferente que os lo voy a comentar,
que es el Economic Denial of Sustainability, ¿vale? Es el E2. Es un ataque pensado para que te cueste dinero, ¿vale?
Y luego hay otro que es bastante parecido que sería el Resource Exhaustion, pero este tampoco sería el caso, ¿vale?
Luego os lo comento, luego os lo comento, pero solo para que entendáis esto, porque todo el mundo se cree
que esto es DDoS y no es tan así, ¿vale? En este caso sí que tiene pinta de que era un intento de esto,
pero ya veréis poco a poco. Esto lo explicamos, el ataque este lo explicamos ya en abril
y ya os comenté cómo solucionarlo un poco con Cloudflare, un poco por encima,
las cosas que habíamos hecho de guardarlo como archivos estáticos, ¿vale?
Esto ya lo comentamos en abril, hace cuatro meses. Y os comenté cómo utilizar Cloudflare,
hoy lo revisaremos y comentaremos más cosas. Pero hicimos dos vídeos al respecto
de cómo arreglar esto, ¿vale? Lo que había que mirar en los eventos, el Firewall y todo esto.
Fijaos, 120 millones de peticiones. Es una pasada, ¿eh? Es una pasada todo lo que nos hicieron.
Bueno, esto fue en abril, pero lo interesante es que tenéis que saber que esto no se ha solucionado,
porque una cosa que tienes que tener muy clara cuando te atacan una página web
es que esto de repente no va a desaparecer. O sea, nunca jamás vas a dejar de recibir ataques.
Suena muy crudo, pero es lo que hay. Lo que hay que hacer es abrazarlos, minimizarlos
y hacer que no tengan coste o que tenga el coste mínimo. Pero la realidad es que los ataques cero
no existen, ¿vale? Tú no puedes hacer que de repente te dejen de atacar. Para que os hagáis una idea de esto,
lleváis que lo de la velada es de hace cuatro meses, que ya explicamos cómo solucionarlo y todo esto,
pero esto es una cosa que nunca termina. Siempre tienes que estar pendiente de cómo te atacan,
cómo cambia el vector de ataque, cómo lo están haciendo, ¿vale? En este caso, fijaos, esta es la velada.
Y en la velada hace unos días, el otro día, el 18 de agosto, aquí tengo un pico de 150.000 peticiones.
150.000 peticiones que fueron 2 GB de transferencia de datos, 26.000 visitas.
Aquí podemos ver un poco de dónde vino el ataque, en este caso de Estados Unidos, de Indonesia, de China,
de Tailandia, de Singapur, de México, de Brasil. Lo bueno es que esto no significa que el ataque tuviese éxito, ¿vale?
Una cosa es entender que nos van a estar atacando constantemente, porque esto ya va a ocurrir,
pero lo que tenemos que decir es que no, no significa que vayan a tener éxito.
Por ejemplo, aunque aquí podemos ver un ataque, fijaos que si miramos el código de estado, ¿vale?
Vemos aquí el código de estado, fijaos de que de las 150.000 peticiones que hicieron intentando,
de alguna forma, atacarme, 74.000 le dieron un 403, 45.000 un 429 y solo 28.000 fueron las que tuvieron,
digamos, éxito. O sea, es normal hasta cierto punto que de un ataque muy grande,
cuanto más grande es el ataque, es normal que se te pueda escapar un número de peticiones.
Lo importante es limitarlo y minimizar el coste al máximo, ¿vale?
Entonces, esto es una cosa que hay que tenerlo en cuenta, porque ahora lo que deberíamos hacer es decir,
vale, ahora que he visto que se me escaparon estas, pues, 20.000 peticiones, debería mirar,
oye, de estas 20.000 peticiones vamos a filtrar, vamos a ver cuál fue el ataque que intentó hacer,
cómo lo intentó, pues mira, Indonesia. Ostras, pues igual deberíamos hacer algún tipo de chequeo extra para Indonesia,
porque mis usuarios no son de Indonesia. Por lo tanto, ¿qué más da? Vamos a mirar ahí
si podemos cambiar lo que sea de Indonesia y ya está, ¿no? Bueno, pues ese sería el tema.
Bueno, luego lo veremos, ¿eh? Cómo hacemos esto. Pero esto es importante que ya lo tengáis en cuenta
porque esto siempre, siempre vamos a estar constantemente, constantemente vamos a estar mirando
y vais a ver luego que se pueden bloquear países directos. O sea, totalmente un país.
Ahora, ¿por qué es importante este curso de Cloudflare para evitar ataques de tu página web?
¿Por qué lo necesitas en tu vida? ¿Y por qué no hay otro sitio que deberías estar ahora mismo?
¿Por qué? Bueno, pues a ver, hace unos meses ya hubo un mítico caso que fue este,
donde una persona recibió una factura de 104.000 dólares en su servidor de Netlify.
¿Y cómo fue esto? Bueno, pues lo que pasó directamente es que alguien se puso a descargar
constantemente un archivo MP3, un archivo MP3 constantemente, que ahora ya lo quitó, obviamente, ¿vale?
Pero lo que tenía, él tenía un archivo MP3 y empezaron a descargarlo constantemente.
Alguien le hizo un ataque de descargar ese archivo MP3 constantemente, pam, pam, pam,
y le generó 190 terabytes de transferencia de ancho de banda en 4 días.
Y por lo tanto, le vino una factura de 100.000 dólares.
Por suerte, por suerte, esto acabó bien, ¿vale?
Se no tuvo ningún problema, se lo devolvieron el dinero, no hubo ningún problema,
pero ya ahí tienes el susto.
Ahora bien, esto te puede pasar más grande o más pequeño,
pero sí que puede ser que alguien, por lo que sea, vaya por un archivo estático
que es lo más típico que suelen hacer con Netlify, con Vercel y todo esto.
Lo que suelen hacer es un archivo estático, es lo que a mí me hacen.
Van a por un proyecto mío y me dicen,
ah, voy a ver cuál es el archivo estático que más ocupa.
Este, vale, pues lo voy a atacar.
Ya está, eso es lo que hacen constantemente.
Lo hacen con todos los proyectos y es lo más típico.
¿Por qué?
Porque tanto Vercel como Netlify como todos estos servicios se paga por ancho de banda
y como se paga por ancho de banda, lo que intentan de alguna forma es decir,
vale, pues como sé que el ancho de banda tiene un límite,
llegará un momento donde voy a acabar con tu ancho de banda.
¿Ves? Aquí tendríamos Fast Data Transfer.
Tendríamos la capa gratuita, sería 100 GB, la capa de pago es 1 TB.
A partir del GB ya te deberías pagar 15 céntimos de dólar por GB.
Entonces ahí es donde estaría el ataque.
Por eso, y esto es muy importante,
si hay algo que tienes que aprender es que esto, lo que suelen hacer,
no es un ataque de DDoS.
Es un error hablar de eso porque lo que podemos asegurar
es que tu página web no se va a caer en ningún momento con Vercel.
No se va a caer.
Pero lo que te va a hacer es costar dinero.
Te puede costar dinero.
Y esto tiene un nombre en concreto que es el ataque de E2,
o Economic Denial of Sustainability.
Que lo que quieren es un ataque a tu cartera.
Es un ataque, ¿veis? Aquí lo tenéis.
El E2, lo que buscan es enviarte tráfico que no es legítimo
para consumir tus recursos del cloud.
Que pueden ser máquinas virtuales, base de datos, transferencia, lo que sea.
Lo que quieren es que te cueste dinero.
Esto es un nuevo tipo de ataque que hay en el cloud
y mucha gente confunde con el DDoS.
Pero este es el ataque que realmente estamos sufriendo
como casi todos los que estaríamos en Vercel, en Netlify y todo esto, ¿vale?
Pero es diferente.
El Distributed Denial of Service, lo que busca realmente,
sería más bien que tu página deje de funcionar.
Pero con Vercel o con Netlify, como esto escala infinito,
no suele ser el caso.
Y lo que busca el E2, lo que busca es que te cueste dinero.
Es que te cueste dinero.
Punto.
Eso es lo que quieren.
Que no te salga a cuenta el tenerlo.
¿Ok?
Eso sería un poco el asunto.
Ahora, vamos a continuar un poquito más con el tema este.
Porque aquí tenemos otro ataque que pasó hace poco en Vercel,
que le costó 500 dólares a este chico, Thomas Sanlis,
donde decía, pues, aquí teníamos, ¿no?
Que le costó, que todavía le habían costado 10 días.
Le había costado 10 días a Vercel responder.
Y que, nada, al final le habían quitado la factura.
Pero, otra vez, 500 dólares.
Otro ataque de DDoS, ¿no?
Que dicen ellos, que es este.
Que, pues, Fortuna Sol le costó 1 dólar 20.
Pero, que en mitad de la noche empezaron a invocarle 1,5 millones de peticiones desde Rusia.
Fijaos aquí.
Desde Rusia, con amor.
600.000 peticiones en mitad de la noche.
Y aquí tenemos las invocaciones.
Se las ha saltado.
Y, por suerte, solo le costó 1 dólar y medio.
Pero, claro, esto porque te das cuenta en mitad de la noche.
Si no, pues, no te das cuenta.
Ya lo tenemos.
Otro.
Creación de 56.000 cuentas.
Esta persona, 23.000 dólares de factura.
¿Por qué?
Porque alguien, de repente, pues, empezó ahí a hacer como suscriptores.
Aquí lo tenemos.
Y esto se supone que te contaba el pago, pero realmente luego estaba incompleto.
¿Sabes?
Esto así constantemente.
Luego, hace poco, justamente, me lo sabéis comentando en el chat, a Moure, a Bryce, el otro día, también, el mismo ataque.
He descubierto que desde hace una hora me han atacado el servidor enviando medio millón de peticiones, 600 gigas de tráfico.
Medio millón de peticiones.
Medio millón de peticiones no es nada.
Medio millón de peticiones es bastante poco, ¿eh?
Pero fijaos que solo con medio millón de peticiones, 600 gigas de tráfico desde 3 IP de Argelia.
Esto es importante.
Este tipo de ataque es importante.
Vamos a ver cómo se puede hacer este ataque.
Y vais a ver que esto, por ejemplo, tampoco es un ataque de DOS.
Esto es un ataque 2.
Es un ataque 2 de denegación de servicio, pero no es distribuido.
Con 3 IPs.
Con 3 IPs.
Esto significa que es una sola persona.
Tiene un servidor, ya sea que lo ha contratado, puede ser un servidor, puede ser utilizando una VPN, un servidor en su casa.
3 IPs no es un ataque distribuido.
Es un ataque sencillo, de una sola persona.
Entonces, esto no es un DDoS, que muchas veces también la gente lo confunde.
Y medio millón de peticiones no es nada.
Imaginad, medio millón de peticiones es muy poquito.
Teniendo en cuenta, por ejemplo, en la velada tuvimos 120 millones de peticiones.
Si medio millón de peticiones son 600 GB, ¿cuánto podrían ser 120 millones de peticiones?
En menos de una hora.
Pero fijaos que solo haciendo medio millón de peticiones, ¿medio millón era?
¿Medio millón de peticiones?
¿Medio millón de peticiones 600 GB?
O sea, solo con medio millón de peticiones.
Es que son muy pocas y el coste en transferencia es muy alto.
O sea, una persona podría hacer medio millón de peticiones.
Tampoco es un número tan imposible de hacer.
Y de hecho vais a ver ahora cómo lo podríais hacer vosotros desde vuestra casa muy fácilmente.
Entonces, ya veis que es el ataque típico que le pasa a todo el mundo.
Toda la gente que tiene un proyecto en Bersel, pues le van a atacar, le van a intentar hacer esto de alguna forma o de otra.
Entonces, ¿qué es lo que pasa?
Pues que te llega este típico email que os voy a enseñar ahora mismo.
Es el típico email que da mucho miedo, que a lo mejor tú no has visto, por fortuna, que es este email.
¡Pum!
Te dice, oye, tu equipo tal se ha pasado un tera de tu pro plan y ahora te vas a tener que pagar esto.
O sea, ¿qué?
¿No?
Esto es normalmente el típico email que te llega con el miedo de, oye, te has pasado de tu plan, ¿vale?
Te has pasado de tu plan.
Y entonces este es el primer aviso que normalmente tenemos de que algo no está bien.
No es normal recibir tanto tráfico.
Nuestros proyectos normalmente tenían, pues, un uso normal.
De repente nos llega este correo, nos entra un escalofrío, nos dice, hostia, qué miedo.
¿Qué es lo que ha pasado?
¿Por qué pasa esto?
Y empezamos a mirar, ¿no?
Empezamos a ver que están pasando cosas raras con nuestro servidor.
Entonces, miramos y chequeamos qué es lo que pasa.
Y cuando miramos la factura, empezamos a ver el dinero, ponemos esta cara.
¡Oh, no!
¡Oh, no!
¿Qué ocurre con los proyectos del plan hobby?
Si tienes el plan hobby, lo que pasa directamente es que te dan como una...
Te dan un periodo de gracia para intentar arreglarlo, pero luego te bloquean la página directamente.
Te la bloquean de una y ya está.
Muy bien.
Entonces, ya que tenemos todo esto, ¿vale?
Tenemos estos sudor fríos, nos solemos enterar primero con esto, ¿vale?
¿Qué es lo primero que hacemos?
Lo primero que hacemos, y os lo voy a enseñar para que veáis cómo sería un ataque de este estilo, ¿vale?
Fijaos.
Aquí tenemos, por ejemplo, la página del curso de React, que todavía no lo tengo en Cloudflare
y lo podemos hacer en vivo y en directo para que veamos cómo lo podemos hacer.
Pero vamos a atacarla.
Vamos a atacarla.
Mira, para atacarla, lo más fácil es que una persona...
El ataque más sencillo que se puede hacer es, básicamente, entrar a una página web,
aquí, Disable Cache, y hacer esto.
Todo el rato.
Refrescar, refrescar, refrescar, ¿vale?
Y aquí estamos refrescando constantemente y estamos consumiendo, pues aquí lo tenéis,
aquí podríamos ver lo que estamos consumiendo, 780 Ks.
Puede parecer poco, pero ya podríamos estar ahí refrescando manualmente 780 Ks.
Podrían ser un mega.
Esto lo podríamos automatizar, pum, pum, pum, pum, pum, y se pone a gastar casi un mega
de nuestro ancho de banda por cada vez que refrescamos.
Hola de nuevo, Midu.
Perdón por interrumpir.
Nada, cuéntame.
Pero, ¿realmente sirven de algo los certificados SSL gratuitos?
Obviamente que sí.
Claro que sí.
Después lo comentamos.
Pero sí, obviamente que sí.
Totalmente.
Sí que sirve.
¿Cómo nos va a servir?
Que sean gratuitos no significa que sean inútiles.
Bueno, pues entonces tenemos aquí esto, ¿no?
Te pones ahí a recargar, a recargar constantemente.
Y esto no va a tumbar la página porque encima es una página que es estática.
No hay ningún tipo de problema.
Pero ya estamos viendo que está transfiriendo unos datos.
En este caso son 700 Ks.
Y esto ya, de alguna forma, está costando dentro del ancho de banda de Vercell.
Y podríamos ver si realmente esto está teniendo algún tipo de impacto en Vercell.
Podríamos ir aquí a Cursor React, ¿vale?
Y aquí podríamos ir a Firewall.
En Firewall ya podríamos ver las peticiones.
Fijaos que ahora, como habéis entrado unos cuantos, ¿no?
Como de repente aquí la gente, bueno, aquí podemos ver que se ha disparado un poco.
Pero lo mejor de esto, ¿ves?
Se ha disparado, luego ha bajado porque ya hemos parado.
Perfecto, ¿no?
Hemos visto que ha habido un pico ahí hasta 650, que es bastante brutal.
650, o sea, hay bastante gente que ha entrado de golpe.
Ahora va bajando.
Bueno, esto está bien.
Podríamos estar refrescando, pero normalmente, a base de refrescar, es bastante difícil.
Otra cosa que podemos hacer ya para el siguiente nivel de intentar hacerle daño a esta página, ¿no?
De que le cueste dinero, sería el tema de hacer un curl.
Este es el ataque más sencillo que existe en el universo, ¿vale?
Si no lo sabéis lo que es el curl, al final es una forma de traerte cualquier página, ¿no?
Y puedes como descargarla desde la terminal.
Pues hacemos curl, le decimos la página.
En este caso, pues vamos a decir cursoreac.dev, ¿vale?
Pum, y la descargamos.
Ahora, esto lo que sería como hacer un fetch, como una petición.
Podríamos estar así todo el rato, ¿vale?
La hacemos así todo el rato y ya está.
Claro, esto al final es una tontería.
Estamos como mejorando un poco esto, ¿no?
El ataque que hemos hecho.
Pero tenemos como que estar ahí pendientes.
Además, a mí me molesta un poco el hecho de que estamos viendo ahí todo el output y tal.
Bueno, podemos mejorar un poco este.
Podemos hacer esto.
Le podemos decir que el output nos lo lleve a nul, porque no lo quiero ver, ¿vale?
Entonces ya aquí podríamos ver que nos va saliendo esta información.
Sí que nos pone aquí como alguna cosita lo que ha descargado.
Pero ya no me molesta tanto ver todo el output.
Y, de hecho, podríamos ir un poquito más allá.
Y podríamos decirle que solo me muestre cuánto es lo que ha descargado aquí.
¿Vale?
Vamos a poner size download y con un salto de línea.
Y lo he puesto mal.
Algo he puesto mal por aquí.
Size download.
Size download.
¿Lo he puesto bien, no?
¿Lo he puesto bien?
¿Lo he puesto mal?
Creo que lo he puesto bien.
Ah, espérate.
Claro.
Me falta el menos ese.
Vale.
Ahora sí.
¿Vale?
Aquí lo tenemos.
Aquí ya tendría cuánto estoy descargando de esa página.
Entonces ya no me molesta y ya está.
Ahora que ya sé esto, ahora lo que podría hacer es una cosa todavía mucho más perversa.
Y es poner un bucle infinito.
While true.
¿Vale?
Vamos a poner que hagamos esto.
While true.
Do.
Tal.
¿Vale?
Pues ya está.
Ya estamos atacando aquí.
Ya estamos atacando aquí la página de cursos.de.
Ya está.
A tomar por saco.
La estamos atacando, pero obviamente esto no va a tirar la página abajo.
No va a haber ningún problema.
Lo que estamos haciendo aquí es que constantemente le estamos haciendo peticiones.
¿Vale?
Y lo que vamos a encontrar, si vemos aquí la lista, aquí tendríamos como todos los usuarios,
lo que va enseñando.
Y eventualmente aquí debería aparecer esto que estamos haciendo por aquí.
Aparecería el curl.
¿Vale?
Todavía no, porque a lo mejor no ha hecho suficientes peticiones.
Pero eventualmente deberíamos ver que ahí aparece la nuestra.
Igual aquí también hay otro.
Por ejemplo, aquí.
Este.
Parece que hay alguien que está haciendo el ataque este ahora.
Podríamos filtrarlo.
Podríamos poner un relimit.
Podríamos hacer un montón de cosas.
¿Vale?
Entonces, aquí pues aparece, a ver si aparece el, a ver si vemos el del curl.
Aunque, a lo mejor no lo pilla nunca.
A lo mejor no lo pilla nunca, por lo que sea.
Pero lo tendríamos que tener por aquí.
Ahora, lo que podríamos hacer para evitar, no sé, eventualmente debería salir o a lo mejor
no sale porque estáis como un montón.
La IP no pasa nada porque no es mi IP.
Es la IP de Cloudflare que estoy con su VPN.
¿Ves?
Esta persona, por ejemplo, me está atacando aquí a lo bestia que está aquí pues dándolo
todo.
Aquí hay una persona que está como atacando, atacando, atacando.
Si por lo que sea llega un momento que me doy cuenta que están atacando y digo, ostras,
vamos a evitar que esto por lo que sea pues que se está disparando y no quiero que de
repente pues haga algún problema y me cueste dinero.
Lo que podríamos hacer es activar este, Attack Challenge Mode.
Tarda un poquito, pero ¿qué es lo que hace esto?
Esto lo que va a hacer es que va a requerir que cada usuario tenga que pasar un challenge
para verificar que realmente es un usuario, ¿vale?
Esto es muy importante.
Esto realmente es para que podamos limitar un ataque.
Pero claro, todos los usuarios van a tener que revisar esto.
Entonces, si nosotros lo activamos, lo voy a activar, ¿vale?
Lo activamos, tarda todavía un poquito, ¿vale?
Tarda un poquito, pero cuando vayamos a cursoria.dev, ahora me aparece este checkpoint.
¿Habéis visto que ha aparecido un checkpoint?
Además, fijaos en una cosa.
De repente, el ataque que yo estaba haciendo aquí, fijaos que estaba descargando 68k,
porque estos son en bytes, 68k, y de repente ha habido un momento que ha estado descargando 30k.
¿Por qué ha pasado esto?
Porque si yo ahora, por lo que sea, hago un curl de cursoria.dev,
vais a ver que lo que me está devolviendo ya no es la página esta de React,
sino que lo que me está devolviendo más bien es el checkpoint.
En este caso, ¿veis?
Que pone verse el security checkpoint.
Entonces, de repente hemos parado el ataque, ¿vale?
Hemos parado el ataque que estábamos haciendo, lo hemos conseguido minificar,
ya no nos está atacando nadie ni nada.
¿Por qué?
Porque lo hemos parado.
Lo malo, que todos nuestros usuarios deberían ver este check, ¿vale?
Ahora, podríamos ser todavía más perversos.
Y os voy a explicar algo.
Este ataque que habéis visto, este ataque que hemos visto,
pero ese checkpoint es horrible.
A mí no me parece tan horrible.
Ese me parece que está súper bien.
Ese mensaje, que además lo ponen ahora en español, está genial.
O sea, me parece tremendo.
Pero sigue haciendo requests, solo que consume la mitad de transferencia.
Ojo, la transferencia que veis aquí, que está consumiendo,
esto ya no llega a vuestro...
A vuestro...
Esto, estos 30k, ya no os lo facturan a vosotros.
Ya no lo facturan a vosotros.
Esto ya sería para Vercell.
Porque digamos que Vercell ha puesto de repente como un check
antes de entrar a tu servidor, ¿vale?
Eso sería lo importante.
Que ya no tendríamos como que preocuparnos por esa transferencia
porque es Vercell la que ha puesto como un muro para proteger nuestra página web.
Entonces, esto le aparecerá a toda la gente.
¿Ves?
Attack Challenge Mode is enabled.
Y aquí podemos ver que de repente, pues ahora ha bajado totalmente
todas las peticiones, ¿no?
A que sabía voy el todo loco.
Hemos añadido a Attack Challenge Mode.
Todavía podría hacer algún tipo de ataque.
Podría aquí, manualmente, empezar a recargar otra vez.
Sería un poco raro.
Pero ahora lo que ya podemos ver es que ya hemos hecho que de alguna forma se pare, ¿vale?
Ahora, os voy a contar otra cosa.
Esto que hemos hecho, este Wild True, esto es bastante perverso
porque es un bucle infinito.
En lo que estás haciendo aquí es que de alguna forma estás como atacando la página sin cesar.
Pero lo peor de todo es que se puede ir peor.
Puede ser peor.
Por ejemplo, una cosa que podéis hacer aquí para ver o para comprobar una página,
a ver cómo la podéis atacar y tal, sería que podéis hacer en paralelo más de una petición.
O sea, podéis copiar esto, ponéis el curl, ponéis aquí el ampersand para hacer en paralelo
la siguiente y la siguiente y la siguiente y la siguiente.
Y luego podéis hacer aquí un wait, por ejemplo, ¿vale?
Y esto lo que va a hacer sería hacer en paralelo las peticiones todo el rato, ¿vale?
Aquí tendríamos el número del proceso y aquí lo que ha descargado.
Ahora ya no tenemos un problema.
Pero esto, con esto, por eso os digo que hacer un millón de peticiones,
cinco millones de peticiones, 50 millones de peticiones,
es cuestión de muy poco tiempo.
Porque si tú tienes un servidor y te pones a hacer esto,
el número de peticiones que puedes hacer es absurdamente alto.
Puedes hacer más de millones de peticiones en muy pocos segundos.
Última interrupción, lo prometo.
Recuerdo que en la carrera nos enseñaron a usar Jmeter.
Fue como darle un Ferrari a alguien que recién sacó el carnet de conducir.
Pobre la página de mi escuela.
Claro, Jmeter y todas esas herramientas son básicamente para poder comprobar la carga
que puede tener un servidor.
Hay un montón de herramientas de ese tipo.
No está pensada tanto para hacer ataques, sino para ver si un servidor puede controlar la carga,
cómo va a funcionar, también ver si tiene una degradación del rendimiento y este tipo de cosas.
Bueno, ya veis que ahora desde que tengo el ataque, ya está bastante más abajo.
Esto parece más usuarios normales.
Ya no había ningún tipo de problema.
Ahora, aquí ha aparecido el Curve 8.9.1, que es la versión que yo tengo.
Y ha hecho 600 peticiones.
Ya ha aparecido por aquí.
Lo que podemos ver con esto del Curve es que, claro, el Attack Challenge Mode,
esto se activa para todos los usuarios.
Una cosa que podéis intentar con el Firewall de Vercel sería darle a configurar
y aquí tenéis algunas reglas que os pueden ayudar para evitar estos ataques.
Por ejemplo, podéis poner una nueva regla y podéis decir,
oye, si el Request Path es igual a barra, pues entonces lo que voy a hacer es hacer un challenge.
O por ejemplo, API, barra, lo que sea.
Aquí lo que queréis intentar es, si es por la Request, si tenéis un path en concreto que están atacando mucho,
pues al menos le ponemos un challenge, pero no lo hacemos en la home, lo hacemos en ese path en concreto.
Hay un montón de posibilidades.
Esto lo vamos a ver mejor después porque en Cloudflare es todavía más avanzado.
Pero uno que es muy típico sería el de UserAgent.
De hecho, podríamos decir que si el UserAgent contiene Curl, pues directamente que lo bloquee.
Y con esto, ¿vale? Lo vamos a denegar.
Y con esto ya, solo con esta regla, vamos a poner aquí Curl, CurlBlocking y Block CurlRequest.
¿Vale? Solo con esta regla ya evitaríamos que cualquier persona que quiera utilizar Curl, pues nos intente atacar así tan fácil.
Obviamente, y esto es lo que vamos a ir viendo, ¿no?
Cuando ya tenemos esta regla, si yo quito el challenge mode, lo voy a quitar, aunque bueno, ahora la gente se me volverá loca,
pero bueno, por ahora lo voy a quitar.
Una cosa que vamos a notar, ¿vale?
Vamos a tener que hacer un ReviewChange y le damos a Publish para que se publiquen los cambios en nuestro firewall, ¿vale?
Una cosa que vamos a notar, fijaos aquí que tenemos como diferentes etiquetas, cuántos challenge modes se han hecho,
las mitigaciones de Distributed Denial of Service, el CurlBlocking, esta es nuestra regla, por ahora hay cero.
Si nosotros intentamos hacer un Curl como lo hemos hecho antes, pues vamos a ver que, ¿veis que aparece ahora 59?
¿Por qué está descargando 59 bytes?
59 bytes solo está descargando porque ahora ni siquiera le está mostrando el challenge.
Lo que está pasando ahora es que está detectando que si hacemos un Curl, lo voy a hacer aquí para que lo veas bien,
vamos a poner el Curl, es que directamente lo que me devuelve es esto, Forbidden.
Si detecta que tú me estás intentando hacer una petición con el Curl, me va a poner Forbidden porque está prohibido.
Pero, pero, como ya puedo decir, el UserAgen no es, no es algo que pueda parar bien un ataque.
Porque al final del UserAgen vosotros podéis decir, vale, Curl, hago esto y voy a poner que el UserAgen sea,
sea, de hecho, dame un UserAgen real.
Venga, tienes un ejemplo, perfecto, gracias, copiar, pegar, ala, ya nos hemos saltado la regla.
¡Ting!
Ya nos hemos saltado la regla.
El UserAgen es como una verificación mínima, pero por desgracia, por desgracia no es suficiente.
El UserAgen cualquier persona se la puede inventar.
Por lo tanto, una persona que esté utilizando Curl, pensá que puede cambiar el UserAgen y de repente volver a atacar.
De hecho, si nos ponemos a ver aquí el tráfico, este que estaba haciendo, alguna persona creo que estaba utilizando este,
hay alguien que estaba haciendo los ataques y estaba utilizando justamente un UserAgen que era real.
¿Por qué? Porque así intentas enmascarar que te puedan pillar.
¿Vale?
Entonces, voy a hacer una explicación rápida del tema de los ataques, para que entendamos.
Los ataques más típicos, más comunes que todo el mundo conoce.
El de 2, que es denegación de servicio, y el de DDoS, que es denegación de servicio distribuida.
Ahora bien, los ataques que solemos tener en Vercell, Netlify y demás, serían más bien E2,
que son Economic Denial of Sustainability, ¿vale?
Que están intentando que te cueste dinero, porque saben que no te van a tirar la página como tal,
sino que lo que quieren es hacerte daño para hacerte pagar, para que no te salga cuenta.
Entonces, históricamente, la denegación de servicio, el 2, es un ataque que está mal intencionado,
que la idea es que, pues, tires o hagan más lento un sitio web, una aplicación, recursos de red,
o que sea inaccesible por los usuarios, ¿no?
La idea es sobrecargar el sistema objetivo para que no responda.
Y el impacto, obviamente, pues, ¿qué puede hacer?
Pues que no puedas usar la página web, que pierdas dinero, medios de historias.
Ese sería el 2.
El DDoS es lo mismo, pero simplemente es distribuido.
Y cuando es distribuido significa que cientos o miles de IPs te atacan.
¿Y esto cómo funciona?
¿Cómo puede ser que hagan eso?
Eso normalmente, no siempre, pero normalmente funciona con una botnet.
Esto es un grupo de ordenadores que han sido hackeados o han sido infectados con malware
o están controlados y se ponen de acuerdo de repente para hacer algo,
para hacer un ataque que digan, vale, pues, ahora que tengo un montón de servidores controlados,
que esto puede ser, por ejemplo, un WordPress por ahí que está utilizando un plugin antiguo
y que tiene una vulnerabilidad que puedes utilizar ese servidor, acceder y ejecutar cualquier comando.
Los servidores estos que están infectados normalmente están como dormidos
hasta que de repente alguien va y dice, venga, ataca.
Y esto puede ser desde servidores así con WordPress, pero puede ser un microondas
que tenga conexión a internet, una nevera, una tele.
De hecho, esto es lo que suele pasar, que muchos dispositivos IoT,
que es del Internet of Things o dispositivos conectados a la red,
tienen vulnerabilidades, los atacan y como tiene salida a internet,
normalmente tienen algún pequeño sistema operativo
y lo que hacen es decir, vale, pues este atacante,
ahora ya tengo un montón de acceso a un montón de servidores que pueden ser dispositivos,
vamos a atacar de repente a esto.
Y eso es lo que hace que un ataque sea distribuido,
porque no te atacan desde un país, te atacan desde un montón de repente.
Y esto lo podéis ver fácilmente, por ejemplo, con el primer ataque este de hace meses de la velada.
Si miráis cuánta gente atacó, 120 millones de peticiones y teníamos de Estados Unidos,
de Indonesia, de Canadá, de Países Bajos, de un montón de países.
¿Por qué? Porque está distribuido totalmente, ¿vale?
Están infectados un montón de dispositivos, lo están utilizando,
se coordina el ataque y pam, te lo hacen de repente.
Normalmente además son ráfagas, ¿vale?
No te lo hacen constantemente, sino que te hacen ráfagas de durante una hora te atacan a ti.
¿Y esto por qué?
Porque amigos, os voy a decir una cosa muy triste,
pero los botnets se pueden comprar o se pueden alquilar incluso, ¿vale?
Yo no os voy a enseñar un recurso de dónde lo podéis hacer, ¿vale?
Pero que sepáis que se pueden alquilar estos botnets en un montón de sitios
y le podéis decir, ¿ves? DDS for hire, attackers for hire,
podéis hacer want to rent a botnet, pues le podéis dar y lo podéis leer.
Es una cosa que en muchos foros tenéis información de cómo lo podéis alquilar,
lo podéis mirar y tal.
Ya os digo dos cosas.
No lo recomiendo, no lo recomiendo, a no ser que sea por fines educativos
y no porque sea un tema de que no, es que está mal, está bien,
sino porque esta gente no es de fiar, ¿vale?
Estos botnets que muchas veces, pues cualquier persona puede decir,
ah, pues voy a atacar, no sé qué.
No os fiéis.
Estos servicios son de gente que son criminales, criminales,
y puede ser que sea peligroso para ti,
que tú en tu inocencia creas que estás alquilando algo,
que no te den el dinero, que se aprovechen de ti, que lo que sea.
O sea, que tened cuidado.
No penséis solo por hacer el mal,
igual sois vosotros los que salís ahí mal parados.
Así que tened bastante cuidado con esto,
pero que sepáis que por eso, que hay gente que los alquila
y por eso muchas veces vais a ver que estos ataques a lo mejor ocurren
durante una hora o cosas así, ¿vale?
Entonces, mira, ahora, por ejemplo, aquí tenemos otro tipo de ataque,
Python Request.
Otro que también, utilizando una request de Python,
esto también me ha pasado a mí un montón,
utilizando un script de Python, uno de JavaScript,
pues empieza a atacarte.
Fijaos que ahora este está ahí a tope,
que ha dicho, oh, voy a aprovechar en mi oportunidad,
no sé qué, no sé cuánto.
Pues aquí podríamos volver otra vez,
pero, de nuevo, aunque yo pueda hacer esto,
puedo decir, ah, pues voy a hacer que también,
si el user hay en...
Anda, hostia, he petado el rule blocking.
Bueno, podríamos hacer otra y tal, no sé qué, no sé cuánto.
Pero bueno, esto como lo vamos a hacer después,
lo vamos a hacer mejor.
Bueno, ahora ha parado, por ejemplo.
Parece, parece que ha parado.
Pero el tema es, vamos a poner el challenge mode mientras,
para que la gente no se flipe.
Pero bueno, el del Python ahí se ha vuelto loco
y lo ha hecho ahí en un momento.
Vamos a poner por ahora el challenge mode,
para que nadie se flipe mientras comentamos.
Muy bien, entonces, ya vemos un poco por dónde van los tiros,
los ataques.
Ahora, te voy a explicar en Vercell
dónde deberías ver correctamente los ataques.
¿Por qué?
Os vais a dar cuenta que este firewall
le falta bastante trabajo a la gente de Vercell.
Creo que han mejorado mucho, muchas cosas,
pero todavía le falta bastante trabajo, ¿vale?
Tienen que mejorar cosas.
Tened cuidado con dos cosas.
Uno, un sitio interesante son los logs.
En los logs podéis revisar muchas veces qué peticiones se están haciendo.
Mala noticia, mala noticia.
Los logs solo funcionan con servidor.
¿Qué quiere decir?
Que si tu página es estática, no vas a ver aquí ninguna entrada.
Si se hace una petición a una imagen,
si se hace una petición a un archivo estático,
aquí no lo vais a ver.
Pero, por ejemplo, si tenéis un producto como, por ejemplo,
la MiduConf, que tenemos tickets y tal,
está bastante bien que echéis un vistazo a los logs
para ver cómo la gente le está, si está haciendo demasiadas peticiones.
Veis aquí, por ejemplo, no parece que haya tantas peticiones en tiempo real,
pero podríais ver si alguien está intentando hacer algún ataque,
si hay demasiadas peticiones de repente.
Este tipo de cosas las podéis revisar porque son muy interesantes,
pero, de nuevo, tened en cuenta que esto sería solo para servidor, no estático.
Para temas estáticos, un sitio que sí o sí tenéis que revisar,
y esto hablo de Vercel, pero también podría ser para Netlify o para cualquier producto,
es el tema de ir a vuestra cuenta en general y ir a Usage.
Este es súper importante porque aquí es donde vais a ver cuánto dinero os va a costar todo.
Por ejemplo, aquí vais a tener desde Current Billing Circle,
este sería el ciclo de facturación.
Esto es un dashboard que os recomiendo que reviséis constantemente,
¿vale? Constantemente para no tener sorpresas.
Por ejemplo, yo aquí veo que mi ciclo de facturación termina el 22, dentro de dos días.
Y ya puedo ver aquí que el Fast Origin Transfer estoy justito,
de hecho estoy bastante justito, y puede ser que pronto tenga que pagar, ¿no?
Y aquí también, el Edge Middleware Invocations.
Aquí vais a tener toda esta información, pero lo más interesante de esto,
todavía lo más interesante, es que en este dashboard también podéis detectar ataques.
Y es que, mirad, aquí podéis ver, aquí podéis ver, por ejemplo,
si filtráis por fecha, por ejemplo, o no hace falta ni filtrar por fecha,
porque veis, aquí se nota que tuve un ataque.
Aquí se nota que tuve un ataque, ¿no?
Vale, pues aquí se nota que tuve un ataque, aquí otro, se nota que tuve otro ataque,
y ahí ya me permitiría estar revisando su tuve ataques y no tuve ataques.
Este dashboard es la bomba, ¿vale?
Entonces, como os he dicho, aquí sería más la parte de enterarte qué problemas has tenido,
lo de intentar activar el Challenge Mode y todo esto, ¿no?
Bloquear los User Agents, pero ya hemos visto que todo lo que estamos haciendo hasta ahora
no es suficiente.
Vercell está mejorando mucho, de hecho, os voy a enseñar una cosa que...
No sé si os la debería enseñar, pero será nuestro secreto, será nuestro secreto,
solo para que lo sepáis.
En Firewall, muy pronto, muy pronto vais a tener aquí, en el...
En Configure, vamos a tener por aquí, si ponemos una nueva regla,
vamos a tener... Creo que lo tengo por aquí...
Aquí, el Rate Limit.
Esto creo que está en beta, no lo tiene todo el mundo, ¿vale?
El Rate Limit.
Pero el Rate Limit va a tener...
Esto está en beta, por lo tanto, no sé si será definitivo o no.
Pero van a añadir un Rate Limit.
Y eso sí que me parece interesante, porque va a ser bastante, bastante potente.
Están trabajando todavía en ello, o sea que hay que darle tiempo.
Pero no es suficiente.
Vercell es muy interesante, pero no es suficiente.
Por lo tanto, ¿qué es lo que pasa?
Me estoy dando cuenta que me están atacando.
Estoy viendo que poco a poco, Curso React, me están subiendo aquí las peticiones.
Ahora he tenido que poner el Challenge Mode y digo, esto, vamos a pararlo.
¿Cómo lo vamos a parar?
Con Cloudflare.
Cloudflare es seguramente la plataforma de infraestructura y servicios más utilizada en el mundo por grandes empresas.
Y no es la única que existe.
Por ejemplo, tenéis como alternativa, por ejemplo, por decir una Akamai.
También AWS podría ser una alternativa en muchas cosas, ¿vale?
Pero tendríais Akamai.
AWS también tiene muchos servicios que se solapan.
Pero Cloudflare, ¿qué es lo que nos da y de qué sirvía?
Es algo parecido a AWS porque empezó a ser una plataforma en el cloud a nivel de infraestructura y poco a poco ha ido añadiendo como más servicios, ¿vale?
Más pensado para desarrolladores.
Entonces tendríamos, por un lado, servicios SSE.
Que serían servicios de perimetrales de seguridad, ¿vale?
Para hacer que sea tu página más segura, evitar ataques, todo este tipo de cosas, ¿no?
También servicios de aplicaciones e infraestructuras para detectar los ataques, para evitar bots, los ataques de denial of service, información de amenazas, logs, todo esto, ¿no?
Y luego tendríamos lo tercero, que serían los servicios para desarrolladores, que sería el hosting, funciones en la nube, archivos estáticos, guardar imágenes, tratar imágenes, hacer stream.
Podrías hacer un Twitch con servicios de Cloudflare, inteligencia artificial, bases de datos.
Podrías desplegar tu aplicación también en Cloudflare.
Pero de lo que es más famoso Cloudflare sería de la protección de tus servicios web y de tus aplicaciones, ¿vale?
Entonces, lo más interesante que tiene Cloudflare, y esto es una cosa muy interesante, es que tiene una capa gratuita muy generosa.
Puedes, ya sea que tengas un visitante, 10, 100 o los que sea, los puedes utilizar sin preocuparte, ¿vale?
Entonces, para iniciar sesión, vámonos por aquí, a ver si entro en el sitio correcto.
Vamos a iniciar sesión.
Os tendrías que registrar, ¿vale?
Tendríamos que iniciar sesión.
Y como os he dicho, aunque os he dicho AWS, Vercell y todo esto, lo más interesante es que Cloudflare lo podéis utilizar a la vez con AWS,
lo podéis utilizar a la vez con Vercell, con Netlify, con cualquier servicio, porque podéis poner Cloudflare por delante.
De hecho, ahora mismo, yo, curso React, lo tengo en Vercell.
Lo tengo desplegado totalmente en Vercell.
Y el dominio lo tengo totalmente configurado en Vercell, ¿vale?
Aquí tengo toda la configuración en Vercell, pero lo que voy a querer hacer, de alguna forma, es poner a Cloudflare por delante, ¿vale?
¿Por qué?
Porque ahora mismo, cuando una persona accede, para que lo veáis bien, si tú haces una petición, fijaos que la petición,
que es lo que devuelve aquí, devuelve información y te dice, vale, pues esta petición, estas son las requests, aquí, viene de Vercell.
Fijaos que tiene Vercell caché, Vercell, o sea, el usuario va directamente, va directamente al servidor de Vercell.
Lo que vamos a querer es poner en medio a Cloudflare, para que, de alguna forma, pare los ataques y haga también como una protección,
para no dejar que el usuario llegue hasta el servidor de Vercell.
Para añadir nuestro primer proyecto, yo ya tengo un montón de proyectos y ahora, luego os enseñaré algunas de las cosas que he hecho en algunos proyectos
para evitar ataques, ataques que están ocurriendo ahora en vivo y en directo, ¿vale?
Pero lo primero que deberías hacer en sitios web es añadir tu página, ¿vale?
Aquí, añadir dominio, vamos a poner cursoriac.de.
Yo os recomiendo que dejéis el examen rápido.
¿Por qué? Porque esto lo que va a hacer Cloudflare es, automáticamente, por ti, lo que va a hacer es importar todos los records DNS que ya tienes en el dominio
y se los va a traer y te va a decir, oye, tienes estos records, estos registros en tu DNS, ya los tengo en cuenta y te los configuraré.
Ahora, aquí el primer susto, porque te dice por aquí, Pro Business Enterprise, y dices, oye, ¿qué pasa con la capa gratuita?
Está abajo, ¿vale? Está abajo. Es verdad que no se ve un carajo porque el modo oscuro de Cloudflare es horrible
y es que tengo una mala noticia. Lo que es la experiencia del desarrollador con Cloudflare no es la mejor.
La UI de Vercell es muy buena y la de Cloudflare es, vamos, han mejorado y aún así, vamos, es una cosa loca, ¿eh?
Así que teníamos la capa gratuita, teníamos el Pro, que está muy bien, el Plan Pro está muy, muy bien
y si es un servicio, es una web que tienes que controlar bien, que no te la atacan y tal, te la recomiendo mucho,
vale mucho la pena el Plan Pro y luego te lo enseñaré porque yo lo estoy pagando en un servicio y es espectacular.
Ahora, el problema que tiene Cloudflare, porque mucha gente dirá, ostras, ¿y cuál es el problema de Cloudflare?
El problema que tiene Cloudflare es que la capa gratuita es brutal, es brutal.
Luego tendríamos que el Plan Pro es increíble, pero el business está muy bien, pero a partir del business el enterprise te mete en una sablada que alucinas.
Es un servicio que está pensado para que grandes empresas lo utilicen y ahí ganar pasta, ¿vale?
Y ganan mucho dinero con esos servicios. Lo digo por si te preguntas por qué tienen una capa gratuita tan generosa,
lo hacen justamente por esto, para llamar la atención de todos los desarrolladores que lo utilizan y tal,
o un producto, una startup, lo empieza a utilizar y conforme tú vas creciendo vas a tener que pagar.
Así que tened en cuenta una sablada, una sablada significa que te van a cobrar mucho dinero, ¿vale?
¿Quiénes usan Cloudflare? Todo el mundo usa Cloudflare.
La pregunta sería, ¿quién utiliza Cloudflare? Muchas empresas utilizan Cloudflare. No sé si tenemos por aquí socios a lo mejor, socios tecnológicos,
pero podéis ver que tienen un montón de usuarios de páginas que lo utilizan. Vamos a ver si tienen por aquí clientes.
Mira, aquí tenemos tres, por ejemplo, Gartner, Forrester, IDC. Bueno, eso dicen analistas.
Mira, aquí tenemos líder mundiales, incluido el 30% de las empresas de la lista Fortune 1000 confían en Cloudflare.
O sea, el 30% de las empresas de la lista Fortune utilizan Cloudflare. Carrefour, Deliver Hero, L'Oreal, Mars, Shopify, Garmin, Dropbox.
Es que aquí te puedes estar todo el día porque es tremendo la de empresas que utilizan Cloudflare.
¿Quién no utiliza Cloudflare? Pues ya os podéis imaginar que a lo mejor algunos servicios, la gente de Google, Amazon y cosas así,
pues normalmente no utilizarán Cloudflare porque ya tendrán sus propios servicios y ya no lo utilizarán tanto, ¿no?
Pero tened en cuenta que sí, que casi todas las empresas, o sea, casi todas no, pero muchas, muchas empresas,
el 30% de las empresas de la lista Fortune 1000, o sea, muchas empresas muy poderosas la están utilizando.
Incluso muchos gobiernos también lo utilizan.
Vercell no lo usa. Error. Vercell también lo utiliza.
De hecho, Vercell utiliza los Cloudflare Workers.
Vercell también lo utiliza, pero no para el servidor, que ahí utiliza WS, pero sí que lo utiliza para algunos servicios.
Ya os digo que no tiene por qué utilizarlo como servidor, pero tienen tantos y tantos servicios que algunos sí que puedes utilizar porque te salen muy a cuenta.
¿Vale? Así que ahí lo tenéis.
Bueno, vamos a ver el tema este.
Capa gratuita. Le decimos que utilizamos el Free.
El Free ya tienes la protección por defecto para los ataques distribuidos de denegación de servicio.
También tienes Rate Limit y algunas cosas interesantes de optimización que los vamos a comentar.
¿Vale?
Entonces, ahora, aquí estamos. Paso 1 de 3.
Aquí se pone a pensar. Está recuperando los registros.
Y cuando lo recupere, nos mostrará aquí todos los registros que tendemos en nuestro dominio actualmente.
¿Vale? Nos está haciendo este examen rápido.
Nos dice, vale, vamos a ver qué registro DNS tenéis ya.
Esto es por si vuestro dominio, el dominio que tengáis, ya lo habéis configurado para que el 3W apunte a Vercell.
Si tenéis un email y está apuntando a, yo que sé, un email está apuntando a Google Workspaces.
Si habéis puesto cualquier registro en vuestro dominio, os aparecerá aquí.
En este caso, mi dominio no tiene muchos registros. Solo tiene dos.
Tiene el de A y el CNAME, que están apuntando a la IP de Vercell y al CNAME de Vercell.
¿Vale? Esto es para que funcione con el servidor de Vercell.
Pero fijaos que ya los ha detectado, nos ha dicho, vale, perfecto, esto lo voy a poder redirigir sin ningún problema.
Esto va a ser totalmente automático. No tienes que hacer absolutamente nada.
Si por lo que sea, algo no aparece aquí, lo tenéis que importar o lo tenéis que añadir.
También puede ser un buen momento para poner cualquier registro que queráis.
Por ejemplo, TXT, pues para el Google, Google, A, Verify, lo que sea.
¿Vale? Pues lo ponéis, lo añadís y ya está.
¿Vale?
Ahora que ya lo habéis visto, le daríamos a continuar y nos va a indicar qué tenemos que hacer para configurarlo.
Nos dice aquí que tenemos que cambiar las DNS.
Esto es un mal necesario, amigos. Es un mal necesario.
¿Por qué?
Esto lo que va a hacer es utilizar las DNS para resolver los nombres de dominio.
O sea, cuando alguien entre a tu dominio para saber cómo tiene que resolver, hacia dónde tiene que ir, pues va a preguntarle.
Ostras, ya veo que este dominio le tengo que ir a preguntar a quien me resuelve los nombres.
Es el servidor de Cloudflare.
Esto es necesario y tiene sus cosas positivas.
Lo primero, que cuando vayamos al dominio, lo primero que tendremos será Cloudflare.
¿Vale? O sea que va a ser esa pantalla de seguridad.
Y la segunda cosa es que las DNS de Cloudflare son muy, pero que muy rápidas.
Por ejemplo, tienen un servicio que es el de 1111, que son unas DNS que son más bien para trabajar, o sea, para ti, de forma individual.
Que esto lo que hace es que Internet te vaya más rápida y además sea segura.
Por ejemplo, yo cuando estoy trabajando, ahora si miro mi IP, vais a ver que la IP que aparece la puedo mostrar porque no es mi IP.
Esto es la IP de Cloudflare Warp.
Entonces, cuando yo estoy, por lo que sea, navegando por Internet, aparece mi IP o lo que sea, no es mi IP, es la IP de Cloudflare.
Y ellos se dedican, y total, ya tienen experiencia de sobra para evitar ataques, así que no va a haber ningún problema, que ahí se pueden poner a atacar y no ven mi IP y a mí no me van a atacar.
Y cuando yo visite páginas, nadie va a saber que yo era el que estaba visitando esa página.
O sea que os recomiendo mucho ese servicio.
Lo más interesante es que las DNS de los dominios también son muy rápidas, así que nuestro servidor va a responder, el servidor va a responder igual de rápido, pero van a encontrar nuestro dominio un poquito más rápido.
O sea, esa negociación que tiene que hacer al principio va a ser un poco más rápida.
Para arreglar esto, ¿qué tenemos que hacer?
Yo lo tengo, tengo ahora mismo todos mis dominios en portban, pero ya os digo que los voy a ir pasando a dondominio, ¿vale?
En dondominio, tengo ahora, estoy empezando a pasar algunos dominios en dondominio, porque la verdad es que tengo el soporte en español, si tengo cualquier problema, pues me gusta un montón.
Y voy a estar pasando poco a poco en dondominio mis dominios, pero ahora mismo tengo un montón aquí, así que es lo que hay, ¿vale?
Aquí tengo el de Cursor React, ¿vale?
Le vamos a dar aquí a detalles.
Voy a mirar una cosa que no se vea nada raro.
Vale, menos mal que no hemos liado parda por aquí.
Vamos a poner esto para acá y vamos a cambiar esto por aquí.
Y aquí en las DNS, ¿vale?
En los Authorative Name Servers, aquí tenemos ahora mismo los de portban y vamos a cambiar por estos, ¿vale?
Fijaos que antes teníamos cuatro, ahora solo tenemos dos, los pegamos aquí y ya está.
Le damos a Submit y esto ya nos va a cambiar los DNS sin ningún problema.
Ahora bien, esto puede tardar hasta 24 horas.
Esto no es algo que sea inmediato, ¿vale?
Esto tarda un poquito porque obviamente tiene que procesar los cambios, se tiene que propagar por un montón de sitios y tened en cuenta que puede tardar.
Normalmente, si tenéis suerte, a lo mejor os tarda menos dependiendo también de qué ciudad estéis.
Puede ser que vosotros veáis antes el cambio que yo o al revés, ¿vale?
Y mientras se encuentran en estado pendiente, Cloudflare no puede responder por ti.
Todavía será en Vercel, no hay problema.
Lo más interesante de esto, puedes estar aquí, comprueba los nombres de servidor ahora.
Le puedes ir dando todo el rato, ¿vale?
Está verificando y te espera unas horas para recibir una actualización.
Normalmente es más rápido.
Lo más interesante que tienes que saber, para que te despreocupes y no estés dándole al botoncito todo el rato,
que sepas que te va a llegar un correo cuando esto ya no esté pendiente.
Fijaos que ahora pone actualización pendiente de servidor.
Eventualmente, en el directo, me llegará un correo y me dirá, oye, que ya está actualizado, ¿vale?
No suele tardar mucho, puede tardar algunos minutos, pero bueno, por ahora le vamos a dar a continuar, ¿vale?
Y aquí ya nos empieza a preguntar unas cosas y ahora vamos a empezar con la chicha de todo lo que nos ofrece Cloudflare, ¿vale?
Mejorar la seguridad.
Venga, vamos a darle a comenzar.
Reescritura automática de HTTPS.
Esto le vamos a decir que sí, por supuesto.
Esto es que si nuestra página web tiene vínculos o cualquier referencia a cualquier dirección que ponga HTTP,
lo que va a hacer es reescribirla por HTTPS.
Esto es para evitar que haya cualquier navegación interna en nuestra página web a una web que no sea segura, ¿vale?
Porque es bastante importante el hecho de que siempre se utilice HTTPS.
Luego veremos que se puede hacer todavía más exigible, ¿vale?
Pero esto es importante para que cualquier recurso o vínculo que tengamos en nuestra página web siempre utilice HTTPS.
Le damos a guardar y luego tendríamos a usar siempre HTTPS.
Sé que parece lo mismo, pero para que nos hagamos la idea, el primero sería si detecta en mi página web, por ejemplo,
que esta URL, imagínate para que lo entendáis bien, si esta URL, claro, esta URL ahora lo veis así,
pero imaginad que aparece esto, cursorria.dev01html.
Si detecta Cloudflare esto, lo que va a hacer es reescribir esto y va a decir,
ostras, no puede ser HTTP, así que voy a poner HTTPS.
Esa sería la primera opción.
Y la segunda opción que estamos aquí activando sería al revés.
O sea, sería más bien que si alguien intenta hacer HTTP, cursorria.dev,
lo que va a hacer automáticamente esto sería redirigirlo a la versión HTTPS, ¿vale?
O sea, que son dos cosas distintas.
Lo digo para que no lo confundáis, aunque parece que sea exactamente lo mismo.
Las dos las tenéis que activar.
Son muy importantes, ¿vale?
Las vamos a finalizar.
Todavía está con la actualización pendiente.
Ya podemos ver algunas cosas, algunas acciones rápidas que hay por aquí.
Modo under attack, modo desarrollo, características básicas, ¿vale?
Y suscripciones activas.
Ahora mismo es totalmente gratuito, ¿vale?
No hay que preocuparse, no hay ninguna cosa.
Hay cosas que ya lo de la redirección HTTPS, en nuestro caso, ya lo hace Vercell.
Pero aún así, no está de más que lo hagáis y que lo tengáis ahí porque, bueno, pues eso que os harráis.
Mira, ya tenemos buenas noticias.
Cloudflare ahora protege el sitio.
Esta es la diferencia.
Fijaos que antes, cuando íbamos a la página...
¿Midu, por qué es importante que siempre sea HTTPS?
Te lo explico después.
Porque el tema de HTTPS, al final, es que la negociación, el contenido, cómo se transfiere, está cifrado.
Y, por lo tanto, no se puede observar.
Una persona ahí, maliciosa, podría ver cómo la transferencia de datos y ver y echar un vistazo en la transferencia de datos.
Podría decir, ostras, mira, estos son los datos que el usuario está enviando o, al revés, que el servidor le está enviando al usuario.
Con HTTPS, esa comunicación, digamos, que está cifrada.
¿Vale?
Y es bastante importante para evitarlo.
La S es de Secure por algo.
¿Vale?
Ahora, de hecho, es obligatorio.
Es obligatorio.
¿Vale?
Para ver si ya funciona nuestro servidor y ya está en Cloudflare, podemos ver aquí, a ver si tiene alguna, aquí en Response, si tiene algún header más.
¿Vale?
Aquí, claro, esto es lo que os comentaba.
Ahora, yo todavía no estoy viendo ninguna cabecera que tenga nada que ver con Cloudflare.
¿Veis?
Que todavía me pone servidor, Vercel.
Todavía, para mí, a mis ojos, todavía no veo que esto esté en Cloudflare.
Pero Cloudflare sí que lo ha visto.
Para esto, check propagation.
Podemos ver cómo se está propagando esto.
Por ejemplo, aquí, si buscamos cursoriac.dev y le damos a buscar, podemos ver que, dependiendo de la localización en la que estés, puedes estar viendo una IP u otra.
Por ejemplo, resulta que aquí, en San Francisco, ya están viendo las IPs de Cloudflare.
Pero en Mountain View, ah, no, en Berkeley, están viendo todavía la de Vercel.
¿Vale?
O sea, es bastante importante que tengáis en cuenta que esto no es, ves, en España, Madrid, todavía estoy viendo la de Vercel.
Como podéis ver, no es tan rápido.
Por lo tanto, tenemos que esperar, tenemos que tener un poco de paciencia.
Poco a poco iremos viendo que cada vez más se va propagando.
Y esto es lo que puede tardar hasta 24 horas, que os comentaba.
Así que, aunque aquí la gente de Cloudflare nos diga que ya está activo, tened paciencia porque, a lo mejor, en tu localización no es verdad.
Pero, aún así, lo bueno es que ya nos va a permitir ver algunas cositas.
¿Vale?
Entonces, ahora voy a revisar unos ataques, pero antes voy a hacer un pequeño inciso para que, si tenéis cualquier pregunta, aprovechemos ahora.
Y ahora veamos el tema de los ataques y cómo los vamos a proteger utilizando Cloudflare.
¿Vale?
¿Podrías detallar el proceso para establecer un CDN?
Luego lo comento.
Un consejo.
Normalmente, con datos móviles suele ser más rápida la propagación por si te urge ver el cambio.
No hay problema porque tampoco es importante.
A mí no me carga la página.
¿Pero está caída?
No está caída.
No debería estar caída.
A lo mejor, no carga por lo que sea.
No sé.
Pero, funcionar debería funcionar sin problema.
Tener doble cifrado simétrico, también es recomendable.
Totalmente recomendable.
De hecho, también lo vamos a comentar eso.
Bastante importante.
Cuanto más cifrado podamos tener, mejor.
No es que Midu sepa cosas, son las cosas que salen de Midu.
¿Vale?
¿Midu, habría algún beneficio si registro otro dominio de alguna página?
Siempre que lo hagas ahí, vas a tener un beneficio seguro.
Más que...
Salen problemas de SSL.
Vale, ese problema de SSL, eso es porque ya estaría viviendo el nuevo y seguramente todavía lo está generando.
Eso es totalmente normal.
Si vamos aquí a SSL, en Cloudflare, será bastante común que...
Me gustaría saber más de estos temas.
¿Dónde podría empezar?
¿Curso que recomiendes?
Seguramente lo está construyendo.
No te recomiendo ningún curso.
Lo que te recomiendo más bien es que te pongas aquí a revisar y a darle cañita.
¿Veis?
Pendiente de validación.
Bueno, pues todavía está añadiendo este registro.
Cuando termine este registro, pues me podrá poner el SSL.
Y es posible que temporalmente, durante un momento, mientras hace este cambio,
como está generando el certificado para tener HTTPS, ¿vale?
Pues estará tardando un poquito.
Tardará mejor unos minutos, pero no os preocupéis que esto se arregla solo
y eventualmente aparecerá correctamente.
Entonces, ahora puede ser que os aparezca esto.
Cuando ya esté así, ¿vale?
Esto lo podría poner yo manualmente, pero no hace falta.
O sea, esto ya lo pone automáticamente para que yo no tenga que preocuparme y ya lo haga.
Y por eso ahora os aparecerá un error de SSL,
pero lo va a crear automáticamente sin que tengáis que hacer absolutamente nada, ¿vale?
El certificado SSL no cuesta nada de dinero, ¿vale?
Lo hace automáticamente sin...
No sé si utiliza OpenSSL.
No lo sé.
Luego lo podemos mirar.
Pero te crea su propio certificado, ¿eh?
No tenéis que preocuparos absolutamente por nada de eso,
que ya lo hace automáticamente.
Tarda un poquito porque lo estará configurando y tal.
Puede ser que durante unos minutos no lo...
Eh, Let's Encrypt.
Perdón.
He dicho OpenSSL.
Let's Encrypt, que es el que te permite hacer certificados SSL totalmente gratuitos.
Y lo utilizan un montón de hostings y cosas así, ¿vale?
Entonces, esto eventualmente funcionará, lo hará bien.
Vamos a ver uno de los ataques que estamos teniendo ahora mismo en el tema de la velada, ¿vale?
No tenés que pagar por el full streak.
Luego lo veremos también.
Dura tres meses el certificado.
Sí, pero se actualiza automáticamente.
No hay ningún tipo de problema porque cuando va a expirar,
lo que hace automáticamente es arreglarlo.
Vale, vamos al sitio de la DepthLeak.
Por ejemplo, la DepthLeak es uno de los sitios que me han estado atacando hace poquito.
Vamos a ver alguno de los ataques, ¿vale?
A ver aquí las últimas...
Vale, está cargando.
Vamos a dejarla ahí.
En los últimos 30 días...
Bueno, 24 horas es muy poco.
Pero aquí en los últimos 7 días sí que podemos ver que nos han estado atacando.
Mira, aquí en solicitudes, ¿vale?
Veis aquí un pedazo de pico.
Medio millón de peticiones en una hora.
Bueno, aquí pone...
Vale, pero tuvo que ser en una hora.
Medio millón de peticiones que me hicieron en una hora en la DepthLeak.
La DepthLeak es una página que tenemos que utilizamos el año pasado
para un concurso entre programadores, con preguntas, que ganó Gonzi,
que fue súper divertido.
La verdad es que nos lo pasamos súper bien.
Y el tema es que hace unos días me empezaron a atacar, ¿vale?
Me estuvieron atacando.
Aquí podemos ver ancho de banda 6 GB que se llevaron.
Y ahora sí, lo que podemos ver es, ostras, a ver qué pasó aquí
y cómo lo podemos solucionar.
Entonces, lo primero que vamos a poder tener cuando entramos en cualquier proyecto
es esta vista de información general
en la que vamos viendo los visitantes únicos de las últimas 24 horas,
7 días y 30 días.
Esto os va a ayudar un montón para el tema de ver un pico, ¿vale?
Esto sería la primera señal de que estáis siendo atacados.
Puede ser, uno, que hay un pico, os está atacando alguien.
Dos, hay un pico y es que habéis tenido éxito con vuestro proyecto.
De repente, volvéis a saber por qué.
Normalmente, si es un pico así, tan, tan pico, algo raro ha pasado y hay que mirarlo.
Especialmente cuando veis aquí visitantes únicos, solicitudes y está todo aquí aplanado
y de repente aparece esto, hay que echarle un vistazo.
¿Datos entregados?
6 GB.
Mal asunto.
Vamos a echarle un vistazo y vamos a tirar del hilo
para evitar justamente lo que nos está pasando.
Aquí podemos ver el tráfico HTTP y podríamos ver cuándo fue el ataque.
¿Fue en este momento?
¿Cuántos fueron a la caché?
Solo 50.000.
Mal asunto.
Cuántos menos peticiones vayan a la caché, más dinero nos va a costar.
Porque esto significa que no fue a la caché y fue al servidor.
Vamos a revisar también cuáles fueron los países.
Vale, Estados Unidos y también tenemos aquí España.
Y también Irlanda.
Estos serían los países con más tráfico.
Irlanda, España, Estados Unidos, Reino Unido, Singapur.
Mal asunto.
¿Por qué?
Si tú tienes una página web, que tus usuarios tienen que ser de México, por ejemplo,
oye, pues hay que revisar y decir, ostras, ¿por qué viene gente de Irlanda?
Pues obviamente porque están atacando desde Irlanda.
No vas a tener tráfico real de repente desde Irlanda o desde Estados Unidos.
Ya aquí tenemos como unas cuantas ideas de cómo evitar estos ataques.
Por ejemplo, sabéis que el CNE de Venezuela se quejó de que Macedonia, Macedonia del Norte, ataque, ¿no?
Que le atacó Macedonia del Norte.
Pues si Macedonia del Norte te está atacando, ya vamos a ver después cómo podríamos bloquear esto.
Pero antes de bloquearlo, vamos a ver unas cuantas cosas más.
Vamos a aprovechar y vamos a ver todas las secciones.
Seguridad.
O sea, aquí lo que nos va a indicar sería como las amenazas que ha detectado.
¿Ves?
Estos serían amenazas.
A veces no las clasifica, pero puede ser que se están utilizando navegadores malos,
que alguien te está haciendo CUR, que se está haciendo una denegación de servicio.
Y esto es que Cloudflare automáticamente, sin ningún tipo de configuración,
ya ha detectado y ha parado estas amenazas.
Lo cual está bastante brutal, ¿vale?
No hemos tenido que hacer nada.
Y ha detectado de España 48 solicitudes y ha parado estas amenazas sin ningún problema.
En las últimas 24 horas, 52 amenazas.
Ojo con esto, que esto ya nos empieza a dar pistas.
Tráfico entregado por SSL.
Ninguno.
Inseguro.
484.
La pregunta del millón.
¿Nosotros queremos entregar tráfico inseguro?
No.
Por lo tanto, ya vemos aquí que de estas 484 deberíamos quitarlas para evitar que alguien pueda atacarnos por HTTP.
Lo podemos quitar.
Tenemos a TLS 2.1.2.581 y TLS 1.3.907.
Estas serían las versiones de los certificados que se están utilizando para el HTTPS, ¿no?
Y vemos que se está utilizando el 1.2 y el 1.3.
Importante.
Acuérdate de esto porque luego va a ser importante para una cosa.
Y los tipos de amenazas, que serían sin clasificar y navegadores malos.
Bueno, seguimos mirando.
Rendimiento.
También muy importante la de rendimiento.
En este caso, sería más bien para ver la optimización que podemos hacer en nuestra página web.
Pero también nos puede ayudar para el tema de todo lo que sería versión HTTP, porque esto también hay un montón de ataques así.
Versión HTTP del cliente actualizada.
¿Pareces un asesor comercial?
A ver, Dios mío.
Vamos a leer este.
Parece un asesor comercial de Cloudflare.
Dice James Success.
Vale.
Vamos a ver.
Si hiciese un curso de AWS, soy un asesor comercial.
Si haces un curso de Vercel, sería un asesor comercial.
Si hago un curso de React, sería un asesor comercial.
Creo que Cloudflare, que mira, antes estaba explicando Vercel porque explico Vercel, soy un asesor de Vercel.
Ahora que explico Cloudflare, que soy de Cloudflare.
Ninguno, nada de este contenido está promocionado.
Yo no sé si es que trabajas en Akamai, si es que trabajas en alguna empresa de estas y es algo que te pica, pero el tema, amigos y amigas, es que Cloudflare es una plataforma lo suficientemente importante, potente y útil, con una capa gratuita muy generosa que os pueda ayudar.
Si a ti, por lo que sea, consideras, crees, o yo que sé, te pica el ano porque crees que es un asesor comercial que me están susurrando lo que tengo que decir, porque también os digo las cosas buenas o las cosas malas, si no os gusta, te puedes ir a tomar por culo.
Así, o sea, te puedes ir, que no pasa absolutamente nada, haz lo que te dé la gana.
Pero, de verdad, lo siento un montón porque me parece que es súper importante, súper interesante y siempre estáis con lo de asesor comercial, que es un ad, que es un patrocinio.
Ya tengo patrocinadores y cuando tengo patrocinadores os lo digo, tengo Don Dominio, tengo Platzi, tengo KeepCoding, tengo LemonCode y no me pica deciros que tengo patrocinadores.
De hecho, me parece muy infantil que la gente se queje de que tengo patrocinadores o que alguien, si me pagase Cloudflare, ya os lo hubiera dicho, es que no tengo ningún, ojalá, ojalá, Cloudflare, págame, págame, o sea, ojalá.
Y lo primero que os hubiera dicho es, Cloudflare me paga porque me encanta trabajar con empresas que justamente considero que son útiles.
Por lo tanto, si tú crees que esto por lo que sea no te gusta, no te interesa porque crees que es una publicidad, que no sé qué, te puedes ir tranquilamente porque nadie te está obligando a estar aquí.
Nadie. Así que eso es lo único que te puedo decir, amigo.
Oye, y gracias SkylandCray por regalar 5 suscripciones a la comunidad. Muchas gracias, te quiero mucho.
Y Mark, gracias por decirte un comentario.
Hola, Midu. Como ingeniero en CyberSec, me alegra ver que enseñas a la comunidad de desarrollo sobre seguridad de aplicaciones.
Es un tema que hace mucha falta la concienciación sobre seguridad. Muchas gracias, Mark. Te lo agradezco infinito.
Pues, retomemos esto, que estaba interesante, antes de que saltásemos con asesor comercial.
Ay, que es que son un poco cansinos con el tema. Son un poco cansinos.
Entonces, no te enojes. No me enojo, pero la verdad es que es un poco cansino el hecho de decir, oh, Dios mío, otra vez el de asesor comercial. Dios mío.
En fin, el tema es que aquí podéis ver la versión del HTTP del cliente que se utiliza.
Y ojo con esto porque también es muy importante. Tenemos HTTP2, que es el más común, HTTP3 y ojo, HTTP1.1.
Esto es importante porque también vais a ver que también podemos evitar muchos ataques a partir de esto.
Luego os explicaré por qué. Aquí podemos ver cuánto ancho de banda hemos ahorrado gracias a la caché, que esto también lo vamos a configurar para que veáis, que es muy interesante.
Y aquí voy a clasar por tipo de contenido para ver qué es lo que más se pide. Normalmente el HTML.
Que también puede ser interesante porque si de repente veis que el contenido que más se consume es un PNG, pues hay que decir, ostras, ojo, cuidado, porque igual me están atacando las imágenes.
Como veis, todo esto nos está ayudando. Vale, por aquí tenemos los registros. Podéis añadir aquí directamente registros a vuestros dominios.
Ya no necesitáis ir a por van o don dominio, donde tengáis el dominio. Lo podéis hacer aquí directamente y añadir los registros que necesitéis.
Vale, tendríamos la configuración. Y ojo, porque esto es muy interesante. Tenemos el tema de DNSSEC, que esto sería como...
A ver, ¿cómo os lo explico? Imagina que estás en una clase, en el colegio, ¿no? Y vas a enviarle una carta, una cartita a tu enamorada.
Le vas a pasar una cartita. Pues lo que harías con esto, el DNSSEC, es que vas a firmar esa carta para asegurarte que cualquier persona que esté en medio
no pueda, pues, yo que sé, ni cambiar el contenido, no te vaya a dibujar una caca o un pene o lo que sea.
Porque la persona que está enviando la información y la que la está recuperando son los únicos que tienen como el sello criptográfico
que saben cómo leer esa información. Entonces nadie puede cambiarlo. Y esto es importante para evitar que alguien pueda vulnerar el sistema de DNS
como utilizando el envenenamiento de la caché, manipulación de las respuestas de DNS, y alguien se pueda hacer pasar por ti.
Normalmente, esto lo puedes utilizar si eres un servicio muy pro, ¿vale? O sea, no hace falta que todos los servicios lo tengan.
Es muy complicado que alguien se haga pasar por tu página web, ¿sabes? Pero una página como google.es o un banco que alguien puede entrar en el banco
y en realidad, aunque tú ves el mismo dominio, alguien ha podido cambiar ese DNS para que apunte a otro servidor
es muy peligroso. Esto muchas veces puede ser un ataque muy brutal. Pero para proyectos como tu portafolio,
pues el hecho de que alguien lo va a hacer, es bastante... No queda mucha historia, ¿eh? O sea que... Vamos a ver.
Luego tendríamos esto para que tenga multifirma, para que lo tengamos. Esto ya... Seguridad también para evitar su plantación de correo electrónico.
También tenéis un servicio de correo electrónico. Vamos con el tema del SSL, que aquí vienen cositas importantes
y más interesantes, ¿vale? El tema del SSL. Aquí, el que yo recomiendo es que tengáis la encriptación automática.
Que esto lo que va a hacer es que Cloudflare va a determinar cuál va a ser el modo más adecuado para protegerlo.
Si no, lo podéis poner personalizado y aquí podéis ver un poco los que tenéis. Tenéis que no sea seguro, que ya os digo
que esto no tienes que activar nunca jamás. El que es flexible, que entonces la encriptación es entre tus visitantes
y Cloudflare, pero que esto sería como la más laxa. Pero las conexiones entre Cloudflare y Vercell serían entre HTTP.
O sea, entre Vercell y Cloudflare serían HTTP. Luego tendrías el full, que ahora sí que tendríamos de punta a punta.
Serían que están todas como encriptadas. Y luego tendrías la que es encripta.
Que encima hace validaciones del origen del certificado, ¿vale? Y tendrías que no...
Está haciendo... Genera certificaciones Cloudflare para asegurarse que de punta a punta,
desde el usuario en navegador hasta Cloudflare y de Cloudflare a Vercell,
todo se está haciendo de forma encriptada, ¿vale? Este sería el más recomendado.
El problema de este, del SSL Only Origin Pool, es que muchas veces puedes tener problemas
tanto de que sea compatible el servidor con este modo y por eso puedes tener problemas.
Por eso yo te recomiendo el automático, que te va a poner Cloudflare el mejor.
En este caso ya nos está poniendo el completo estricto, que está bastante bien y ya lo tendríamos, ¿vale?
Luego vamos a tener aquí certificados de perímetro. Esto lo que podéis ver es que lo hace automáticamente.
¿Veis lo que antes estaba como pendiente? Pues aquí ya lo tenemos activo con una copia de seguridad emitida.
Ahora, estos certificados los administra, los genera automáticamente Cloudflare por ti.
No tienes que hacer absolutamente nada y además son universales, no solo para el dominio principal,
sino que es también para los subdominios.
Ahora bien, igual queréis cambiar alguna cosa, alguna configuración.
Podríais, por ejemplo, poner el transporte estricto de HSTS.
Este está muy bien para evitar ataques a los cambios que puedan...
O sea, este es para que siempre tenga que mantener una configuración HTTPS válida.
Y es un encabezado que se pone, que se utiliza, que es el HSTS,
para que no se pueda de alguna forma cambiar esa configuración o sea puedan saltar, ¿vale?
Lo malo que tiene esto es que si tú cambias o le quitas el HTTPS a tu página,
el problema es que esto se cachea.
Y el problema que vas a tener es que te puede hacer que tu página web sea totalmente inaccesible.
Entonces, ten mucho cuidado porque si no te puedes encontrar que por lo que sea tu página,
si se quedas en HTTPS, sea totalmente inaccesible, ¿vale?
Entonces, activalo, pero con la seguridad de que no vas a hacer cambios muy bruscos.
La versión mínima de TLS, la predeterminada, es la 1.0.
Yo os recomiendo que esto lo podáis cambiar a la 1.2.
Esto es porque la versión que ahora mismo utilizan los navegadores modernos, casi todo,
si buscáis aquí la versión TLS, aparecerá TLS, por ejemplo, 1.0.
La 1.0 lo tienen todos.
Esta versión TLS 1.0 ya la han quitado en la Chrome 84, en las últimas versiones.
Porque es insegura.
Entonces, no tiene mucho sentido realmente utilizar la versión 1.0 o soportarla,
a no ser que necesites soportar un navegador muy antiguo,
porque en realidad es vulnerable.
Entonces, no es muy buena idea.
Lo mismo pasa con la versión 1.1,
que aunque esta todavía podéis ver por aquí,
que sí, está soportada por el 97%,
realmente tiene muchas vulnerabilidades.
Está deprecada, pero no está eliminada.
¿Cuál es el problema de utilizarla?
El problema es que un navegador que soporte la versión TLS 1.1,
un atacante se podría aprovechar de decir,
ah, voy a utilizar la TLS 1.1,
voy a forzarlo y de esta forma,
como el servidor que tiene vulnerabilidades
la está utilizando, pues no va a tener ningún problema.
Entonces, yo os recomiendo que sea a partir de la 1.2,
a no ser que sepáis lo que estáis haciendo
y tengáis una buena excusa.
La TLS 1.2 tiene un soporte también del 97% todavía, ¿vale?
Así que no os preocupéis porque todavía tiene un soporte brutal
que funciona un montón y no debería haber ningún problema.
¿El dominio de curso RIA.dev?
Ah, puede ser.
¿Sabéis lo que pasa?
Lo del curso RIA.dev igual,
el problema que está teniendo es que está haciendo
una redirección infinita.
Porque, ¿ves?
Esto es por el tema que hemos estado haciendo antes.
Luego lo arreglo, no hay ningún problema.
Esto es porque seguramente en Vercel tenía una configuración
y en el otro lo está haciendo al revés.
Así que luego lo solucionamos sin ningún problema en Cloudflare
y ya está.
Por ahora, seguimos con el de Devsleek y luego arreglamos este.
Venga, vamos con eso.
Encriptación oportunista, esto ya está activado.
TLS 1.3, esta es la última versión.
Si no la tenéis activada, la activáis.
La reescritura automática de HTTPS también la tenéis que activar
y ya lo tendríamos.
Esto de desactivar el SDSL universal,
esto es en el caso de que por lo que sea,
no vayáis a utilizar un subdominio,
pues igual es interesante que lo desactivéis y ya está.
Y así solo lo utilizáis para el dominio principal.
Vamos con más cositas.
Estos son los certificados de cliente que ya hemos visto.
No, este no lo necesitamos.
Servidor de origen tampoco.
A ver si hay servidor de origen.
Vale.
Venga, vamos con la seguridad.
El tema de la seguridad,
aquí vais a tener listados todos los eventos
que están ocurriendo.
Por ejemplo, aquí tenemos las actividades,
los ataques que habréis visto.
Habréis visto que se está bloqueando del Reino Unido.
Y fijaos que me está haciendo una ruta súper rara
y además HTTP 1.1.
Esto lo vamos a solucionar rápido después
porque no tiene sentido uno que intente acceder
con la versión HTTP 1 y además a una ruta tan rara.
Esto es súper normal y lo vais a ver constantemente.
donde un montón de gente lo que hace es atacar a los random,
un montón de páginas, para ver si cuela.
Y van viendo, tienen una lista de rutas para ver si esa página existe.
Muchas veces es para temas de WordPress,
para ver si existe el archivo WP Content y cosas así.
¿Ves?
Esto sí que parece que es un uno real.
Parece que es real.
No os creáis porque, ¿veis?
Aquí tenemos de la Federación Rusa
que está tirando del API Number
y está ahí intentando hacer una llamada a la API.
Esto lo vamos a ver después de cómo arreglarlo, ¿vale?
Tendríamos el WAF.
Este, el WAF es Web Application Firewall.
Y esto lo que nos va a permitir,
y es lo más interesante,
es empezar a poner reglas para evitar ciertos ataques.
Por ejemplo, aquí la primera que podríamos poner,
ya hemos visto que nos está atacando, por ejemplo,
hemos visto la Federación Rusa
y yo, la verdad es que no tengo usuarios en la Federación Rusa.
Así que vamos a poner Challenge Weird Countries Continents, ¿vale?
Este firewall lo que nos va a permitir
es intentar evitar, sobre todo, ataques en el nivel de la aplicación.
Cuando alguien nos hace una petición
y aquí tenemos diferentes campos,
por URL, por UserAllen, por Cookie, según el país.
Ya hemos visto que el país de, si es igual a Rusia,
pues vamos a decirle que tenga que hacer algo.
Si el país que está visitando mi página es Rusia,
quiero decir una acción.
Y aquí tenemos diferentes cositas.
Podríamos decirle que bloquee,
esto es, que le va a dar que está prohibido totalmente
el hecho de entrar en nuestra página web.
Podríamos decirle que haga un desafío de JavaScript.
Este no está recomendado,
de hecho está deprecado, no lo recomiendo.
Omitir significaría, básicamente,
que se va a saltar cualquier problema.
O sea, cualquier regla que hayamos hecho,
omitir para que es útil.
Esto sería útil para, por ejemplo, Google Bot.
Si queremos que Google no tenga ninguna restricción,
le podríamos decir, vale,
quiero que omita cualquier regla para que se la salte.
O si sabemos que hay algún usuario que está registrado,
que tiene una cookie en concreto,
pues le podemos permitir que se salte cualquier regla
que hayamos puesto.
Y luego tendríamos el desafío interactivo,
el típico desafío interactivo,
esto del CAPTCHA, ¿vale?
Lo más recomendable es desafío manejado.
Porque esto lo que nos va a permitir
es que automáticamente Cloudflare decida
cuál es el tipo de desafío que le va a mostrar
y nosotros ya nos podemos totalmente,
podemos decir, vale, pues ya no me preocupa
porque Cloudflare va a decir, vale,
si tengo dudas, un desafío interactivo.
Si es demasiado complejo, desafío de JavaScript.
Es el mejor desafío que podéis hacer
y le va a presentar interactivo o no interactivo
dependiendo de cómo de complicado vea qué es esto.
Para que os hagáis un poco la idea de cómo es,
este sería el automático,
donde chequea el browser automáticamente
y no le pone ningún tipo de desafío.
Y este sería más bien el desafío interactivo,
donde realmente el usuario tiene que llegar
a hacerle un clic.
Este sería automático, este sería interactivo.
Y dependiendo de cómo declaro Cloudflare lo tiene,
pues puede mostrar uno u otro.
En este caso yo siempre, casi siempre,
os recomiendo el desafío manejado
y ahora le damos a implementar.
Ahora ya con esto, los usuarios que sean de Rusia,
pues lo que va a hacer es que va a mostrarle,
pues un desafío.
Ojo cuidado porque en la capa gratuita,
en el firewall de aplicaciones web,
solo tenemos cinco reglas disponibles.
Si pagáis, tenéis más.
Si no me equivoco, no sé si son 10 o son 20, ¿vale?
Así que eso lo vamos a tener arreglado.
El tema es que si son 20, o sea, si son 5,
tenéis que ser muy buenos con el tema de cómo lo hacéis, ¿vale?
O sea que aquí cuando editemos,
no vayáis a poner una regla para cada uno,
aprovechad y aquí podéis añadirle otro.
Si es de Rusia o es de un continente entero,
podéis decir, si el continente es igual,
por ejemplo, África,
que yo no tengo usuario de África,
o por ejemplo, si el continente, por ejemplo,
es igual a Asia o por ejemplo,
si el continente es igual, ¿vale?
Pues esto podéis continuar constantemente.
Por ejemplo, si es de la red Tor,
pues le vamos a enseñar el desafío.
Luego podríais ir más a nivel de país también.
Pero bueno, esto para que lo tengáis un poquito así para la idea.
Esto sería lo primero.
Esto para la Devsleak,
que es lo que estamos haciendo por ahora, ¿vale?
Esto es el proyecto de la Devsleak,
devsleak.com, ¿vale?
Pues entramos y nos funciona perfectamente.
Para que veáis cómo de efectivo es,
si yo por lo que sea,
ponemos aquí una regla de Challenge Weird Countries, ¿vale?
Ponemos una regla y le voy a decir que
si el país es España y como yo estoy en España,
vais a ver que tarda un poquito,
porque en desplegarse los cambios puede tardar un poquito,
pero una vez que lo tenga, ¿vale?
Yo voy a ir refrescando y ahora veréis que eventualmente
pues aparecerá con el PT,
pues vais a ver que lo bloquea definitivamente.
O sea, no va a haber ningún tipo de esperar ni nada.
O sea, lo bloquea de una.
Tarda unos minutos, o sea, que es normal.
Mientras vamos a continuar y os voy a enseñar
una cosa súper importante.
Y os voy a enseñar el ataque
que me han estado haciendo en la Devsleak, ¿vale?
El ataque que me han estado haciendo en la Devsleak,
el ataque,
es que normalmente,
si nos ponemos a mirar aquí todos los recursos,
una cosa que hacen es mirar
cuál es el recurso que más ocupa, ¿no?
Que normalmente aquí son las imágenes.
Y aquí lo que me han podido hacer
es ir aquí a la imagen de Carmen
y ponerse constantemente a recargarla,
a descargarla,
porque esto, como podemos ver aquí en los headers,
¿veis? Se está revalidando.
Esto lo podemos arreglar y lo arreglaremos
para que no haya ningún problema, ¿vale?
Pero hay otro ataque que me han estado haciendo.
Bueno, ¿veis? Ya me está empezando a fallar
y ahora me está poniendo verificar.
¿Por qué?
Porque como soy de España,
lo está verificando
y ahora me está apareciendo.
¿Ves que me ha aparecido?
Porque como soy de España,
me ha aparecido.
Y lo bueno es que ahora ya
puedo entrar sin ningún problema.
Esa es la verificación automática que ha hecho, ¿vale?
Entonces, para esto,
voy a quitar España,
que ya no tiene mucho sentido,
o podría poner que lo bloquee directamente.
Podría haberle puesto un block,
pero bueno,
no tiene mucho sentido que pongamos un block.
Solo era para que veáis cómo defectivo es
y que tarda un poquito.
Lo digo para que lo tengáis en cuenta
que tarda un poquito en enviar los cambios.
Otro ataque que me han hecho,
aparte de la imagen,
ha sido atacarme la API.
Porque aquí tengo una API
que no es una API que sea muy lenta,
no es una API lenta,
pero ¿qué pasa?
Que esta API,
fíjate que es una tontería,
que hace esto.
Solo me devuelve el número del ticket.
Es una API que, ya ves.
¿Pero cuál es el problema de esto?
Pues claro,
esta API,
si nos vamos a Nickware,
pese a que la tengo en Cloudflare,
¿vale?
Para que entendáis que Cloudflare
automáticamente no te salva de todo,
sino que hay que configurarlo.
Fijaos que aquí me pone
caché status.
Ya tenemos aquí las cabeceras de Cloudflare
y me pone caché status.
Dynamic, ¿vale?
Vamos a ver cómo esto lo podemos arreglar.
Si es dinámico,
significa que no se está solucionando,
o sea,
no se está cacheando.
Y esto significa
que está llegando
al servidor de Vercel
para recuperar esto.
Por lo tanto,
nos está haciendo una petición
para el servidor,
nos está costando dinero
y tenemos que ver
cómo lo solucionamos
para que no nos afecte,
¿vale?
Así que tenemos que ver
cómo arreglamos esto.
Vamos a chequearlo,
vamos a arreglarlo
para que no nos dé ningún problema.
¿Vale?
¿Cómo lo arreglamos?
Vamos a ver cómo lo arreglamos.
Vámonos aquí.
Aquí.
¿Vale?
Vámonos aquí.
Tiene una cosa tremenda,
Cloudflare,
que es el Rate Limit.
El Rate Limit
es la posibilidad
de limitar
el número de peticiones
que te pueden hacer
a cualquier URL.
Es aquí.
Reglas de limitación
de tasa.
Esto es una cosa
muy típica
que se hace
en servidores,
en APIs
y todo esto.
Y podéis crear aquí
una regla,
solo podéis crear una.
En la capa gratuita
solo podéis crear una.
Pero os digo una cosa,
esto suele costar
mucho dinero
porque normalmente
necesitáis poner
un servidor,
normalmente tenéis que hacer
un montón de cosas
y aquí lo podéis hacer
totalmente gratuito,
al menos una regla.
Así que tiene que ser
la mejor regla
que podéis hacer.
Podéis hacerlo
a nivel de API,
por ejemplo.
Podéis decir,
veis aquí tenéis
bot verificado,
categoría de bot
o ruta de URI.
Lo que podemos decirle
es que todas las que empiecen
con barra
barra
barra
API,
¿vale?
Todo lo que empiece
con barra API,
ahora aquí
lo que vamos a tener
es,
vamos a poner aquí
rate limit API.
Todo lo que empiece
con barra API
lo vamos a limitar.
Para que veamos
la diferencia,
vamos aquí
y vamos a hacer
el truquito este
de
el while este
que tenía por aquí.
Teníamos antes
aquí un while.
Ah, mira,
un ataque.
Vamos a hacer este ataque,
¿vale?
Y vamos a hacer
el ataque con la API,
que esto es lo que me
estaban haciendo a mí.
Tenía esta API abierta,
me están haciendo
un ataque con la API
y digo,
ostras,
claro,
me están atacando la API,
es un poco rollo,
¿cómo lo puedo evitar?
Vamos a hacer,
vamos a cambiar esto por aquí,
¿vale?
Vamos a poner esto por aquí.
Pum,
venga,
y ya me lo están atacando.
Fijaos que son 15 bytes
porque total,
es que lo que
está devolviendo
es muy poquito.
O sea,
lo que está devolviendo
es muy poquito,
pero claro,
ya me está haciendo aquí
un montón de peticiones.
O sea,
y aquí,
estos son peticiones
que va a haber sell
y que cuestan dinero.
¿Qué vamos a hacer
para evitarlo?
Vamos a limitar,
vamos a hacer que limite.
Para limitar esto,
mira,
para que veáis un poco
qué es lo que me está devolviendo,
para que se vea bien,
vamos a hacer esto,
pero lo vamos a hacer
que se vea la respuesta,
¿vale?
Vamos a hacer que se vea
la respuesta,
así,
¿vale?
Y ahora,
ahora se va viendo ahí
el number constantemente
y tal.
Claro,
no se está cacheando,
no se está limitando,
pues ahí me están atacando
y estoy perdiendo dinero.
Lo que vamos a hacer
es limitar
que todo lo que sean
con la misma IP,
vamos a decirle
un límite de solicitudes,
vamos a decirle
que solo puede hacer
20 solicitudes
cada 10 segundos,
así vamos a evitar
que constantemente
me esté haciendo ahí
peticiones
y si hace más de 20 solicitudes
cada 10 segundos,
lo vamos a bloquear.
Vamos a decirle
bloquear.
Durante,
solo lo podemos limitar
a 10 segundos,
esto es lo malo
de la capa gratuita,
que es gratuita
y tiene sus limitaciones,
lo que podríamos hacer
con esto
sería pagar
y si pagas
tiene muchas más opciones,
pero si no pagas
al menos limitas
cada 10 segundos
y esto quieras o no
ya limita bastante,
de hecho podemos bajar aquí
a 10 peticiones
cada 10 segundos
y esto ya nos va a ayudar
un montón.
Y esto lo podríais hacer
también a subdominio,
claro,
esto también funciona
a nivel de subdominio,
lo importante es la ruta,
porque al final
los subdominios
estarían dentro
del propio dominio,
o sea que no debería
haber ningún problema
y de hecho aquí
lo he puesto solo
para la API,
pero lo podríais poner
para cualquier página también.
Vamos a implementarlo,
de nuevo,
esto puede tardar
unos minutos
en hacerse en efectivo,
o sea que puede ser
que tengamos todavía
que podamos atacar,
digamos,
durante un momento,
¿vale?
Vamos viendo ahí
que pone,
¿ves?
Pero ya está,
error code 1015.
¿Qué es lo que pasa con esto?
Lo que ha pasado
es que hemos superado
el límite,
aquí lo tendríamos,
el límite,
hemos hecho aquí
unas cuantas peticiones,
hemos superado el límite
y finalmente
ya me está baneando.
Llega un momento
que pasa
el tiempo de baneo
que son 10 segundos
y puede continuar,
pero ya el ataque
que puede hacer
está muy limitado,
porque solo me puede hacer
como máximo
10 peticiones
cada 10 segundos.
Ya no me puede hacer
un millón de peticiones
al minuto,
¿vale?
Ya está mucho más limitado,
o sea que ya
estamos bloqueando bastante.
Luego,
más cositas,
reglas administradas,
esto también es un tema
de pago,
pero aquí en herramientas
os voy a recomendar
una cosa
que es muy potente.
Además de que podéis
bloquear agentes de usuario
de forma muy sencilla,
por ejemplo,
lo que os decía
de CUR,
aquí pues si encontráis
nombre de descripción,
bloquear navegador
o bloquear
ataques
de CUR.
No es que sea
muy útil,
pero al menos
no gastáis
las reglas
que son de la capa gratuita.
Entonces aquí podéis
bloquear
las que sean
agentes de usuario,
pues si era CUR
con la versión
8.9.1.
Esto está muy bien
en el caso
que tengáis
ataques específicos
y queráis pararlo
muy rápidamente
de un agente de usuario
concreto
para hacerlo,
¿vale?
Porque tenéis que poner
user agent
exactamente igual,
¿vale?
Luego tendríamos
este sería esto,
¿vale?
Esto sería el WAF.
El WAF,
que es el Web Application Firewall,
es la herramienta
más potente
que tenéis en Cloudflare
a la hora de evitar
cualquier problema.
Lo podéis hacer,
por ejemplo,
a nivel de limitar
también ataques
de imágenes,
¿no?
Como habéis visto,
también a mí
me están atacando
las imágenes.
Este de Carmen,
pues me están
pillando a Carmen
constantemente
y me la están atacando
a la pobre Carmen
que me están gastando
un montón.
Entonces también
podríamos hacer
una regla
de que
si por lo que sea
van directamente
a las imágenes
que terminen
con PNG,
pues que lo haga.
También,
ojo,
que hay un montón
de dirección de IP
si tiene
por lo que sea
una cabecera.
Antes hemos visto
que nos estaban
haciendo muchas peticiones
con HTTP 1.0.
Pues también
podríais decir,
oye,
pues no tiene mucho sentido
que realmente
alguien
nos intente
atacar,
o sea,
intente utilizar
HTTP 1.0.
Así que si la versión
de HTTP
es la 1.0,
vamos a
block
weird things,
¿vale?
Cosas que son raras
las vamos a bloquear.
Si alguien utiliza
versión HTTP 1.0
lo vamos a bloquear
directamente
porque seguro
que está utilizando
o un navegador
muy antiguo
o que directamente
nos está intentando
atacar.
Los usuarios normales
como mínimo
utilizarán 1.1
y lo más normal
es que utilicen
2.0
o 3.0.
Así que estos protocolos
que al final
son tan antiguos
lo que estamos haciendo
es directamente
los vamos a evitar.
Aquí ojo
porque además
como estas reglas
pueden ir por delante
o por detrás
poned más adelante
las que queráis
que sean
más
o sea
que filtren
más usuarios.
En este caso
pues esta la vamos a poner
la primera
para que sea lo primero
que se chequee
que si tienes
este protocolo
nos lo quitamos
de encima.
Hay un montón
de reglas
esto es solo
la punta del iceberg
pero para que os hagáis
una idea
hay repositorios
incluso
que están súper
súper bien
que te vienen
ya con reglas
preestablecidas.
Por ejemplo
aquí tendríamos
para malos bots
y aquí
pues lo podéis
veis que aquí
tenéis reglas
son reglas
que os podéis copiar
que os da
una lista
de buenos bots
de malos bots
de crawlers malos
de buenos
escaneadores de seguridad
que esto también
hay un montón de ataques
de gente que te escanea
para ver
cuáles son los posibles
ataques que pueden tener
pues estos son
bots
que te escanean
para ver si tienes
algún fallo de vulnerabilidad
pues también
los podrías intentar sacar
pero también hay algunos
muy interesantes
este por ejemplo
para archivos
por ejemplo
action block
este está muy bien
este también
bloquea el http
1.0
pero también te bloquea
sospechas
que tengan esta cabecera
method request
que estén mal
listas de asn
que ya se saben
que son malignas
también algunos
para bloquear
posibles vulnerabilidades
sql
estas son las típicas
veis aquí
tendríamos vulnerabilidades
que te intenta la gente hacer
veis aquí
esto es una regla
estas reglas
que veis aquí
son las mismas reglas
que estamos construyendo
aunque lo estamos haciendo
con ui
la estamos construyendo
aquí
fijaos en esta regla
que tenemos aquí
veis aquí que pone
vista previa
pues aquí podéis editar
la expresión
y ponerla directamente
veis
lo podéis poner a mano
podríais copiar
toda esta regla
que sería más pensado
para php
y tal
la ponéis
y aquí tendrías
toda la regla
ya pues ahí documentada
para no tener que utilizar
el generador
lo podéis hacer a mano
también totalmente
y esto fijaos
que os va a quitar
un montón de ataques
para inyección
de sql
inyección de javascript
xss
y un montón de ataques
está muy bien
porque hay muchos repositorios
que tienen ya reglas
preestablecidas
y así no os tenéis que preocupar
vosotros de volveros locos
ni mucho menos
muy bien
entonces
os decía lo de carmen
que está muy bien
pero nos está atacando esto
hay otra cosa
muy interesante
que podemos hacer
para evitar
ataques
en nuestra página web
o sea
no solo podemos hacer esto
de tener reglas
como para que
bloquear
sino que también
tenemos que pensar
en la optimización
de los recursos
y es muy interesante
porque fijaos
que muchas veces
se nos olvida
lo que hacemos siempre
es poner defensa
defensa
defensa
y también
tenemos que hacer
que las cosas
que podamos
ostia
tengo aquí este ataque
fijaos
tengo aquí este ataque
se me ha olvidado quitarlo
bueno
lo que podemos hacer
es optimizar
los recursos
y os voy a explicar
cómo ataca
la gente
para evitar
vuestra caché
y cómo lo podéis solucionar
mirad
aquí tenemos la imagen
de carmen
claro
imaginad
la imagen de carmen
son mucho
ocupa mucho
o sea que imaginad
lo que suele hacer la gente
son medio mega
claro
medio mega
pues te vienes aquí
dice vale
pues como ahora ya
me han quitado la api
pues toma
voy a por carmen
voy a por carmen
pum pum pum
y esto
aunque aquí pone
que el output
no me lo puede enseñar
la realidad es que
lo está descargando
vale
está descargando esto
y por lo tanto
mira lo voy a
lo voy a hacer
a ver si puedo
aquí
vale
para que podamos ver
el size.load
vamos a poner aquí
a la buena de carmen
para que nos enseñe
el size.load
veis
estoy descargando
medio mega
y esto llega
al servidor de vercel
que de hecho esto
a lo mejor
pues me cuesta dinero
así que por ahora
lo voy a parar
lo voy a parar por ahora
pero bueno
veis que medio mega
medio mega
medio mega
este es el ataque
más típico
que suele ocurrir
vale
pero lo que vamos a hacer
es que
porque está ocupando
medio mega
en realidad el problema
no es que ocupe
medio mega
el problema
es que está llegando
al servidor de vercel
y tengo una mala noticia
servidores de vercel
netlify
casi cualquiera de cloud
el problema es que
tú no pagas
por
por las peticiones
que
que estén cacheadas
y tal
o sea
tú pagas
por las peticiones
que están cacheadas
y por la transferencia
de esos datos
da igual que esté
cacheado
eso
no le importa
vercel
si hay medio mega
que se está transfiriendo
paga
paga
entonces
que es lo que vamos a hacer
vamos a evitar
que
cloudflare
haga esto
de revalidarlo
y llevar
llegar incluso
a vercel
para eso
podemos hacer diferentes cosas
pero lo más fácil
que podéis hacer
vamos a ver aquí
tenemos almacenamiento
en caché
vale
podemos hacer
en la configuración
tenemos aquí diferentes configuraciones
que podríamos mirar
tal tal tal
pero vamos a hacer
una cosa en concreto
esta configuración sería como muy general
pero te recomiendo mucho
sobre todo las reglas de caché
porque esto lo puedes utilizar
a nivel de apis
a nivel de archivos estáticos
y a nivel de cualquier cosa
y te puede salvar la vida
vamos a crear una regla
podéis utilizar hasta 10 reglas
y vamos a crear una regla
vamos a aquí
caché
caché
images
por ejemplo
y vamos a decir
mira
vamos a filtrar
que si la ruta
de la url
contiene
podríamos decir
que contiene
o es igual
vamos a decir
que contenga
o podríamos decir
si coincide
o termina
o sea
podríamos decir
lo que nos dé la gana
no sé decir
si es igual
vamos a poner
que sea
que contiene
porque total
vamos a hacerlo
solo para las imágenes
vamos a decir
que los barra image
vale
todo lo que contenga
barra image
pues
barra image
barra
vamos a poner
barra image
barra
o podríais poner
el wildcard
no pasa nada
pero bueno
solo que contenga
el barra image
vamos a decir
que es elegible
para la caché
ojo con esto
porque vais a ver
un ataque muy típico
que suelen hacer
y que con esto
lo podéis solucionar
y que la gente
suele ser muy perra
entonces
vamos a decir
que sea elegible
para caché
y le vamos a decir
que a Cloudflare
que debe almacenar
en caché
la respuesta
y durante cuánto tiempo
vamos a agregar
esta configuración
y le vamos a decir
que no utilice
el encabezado
de control de caché
que lo ignore
y que le vamos a decir
que el tiempo de vida
de la caché
aquí no tenemos
muchas opciones
podría hacer
seis meses
un año
dos horas
pero ojo cuidado
con esto
ojo cuidado
con esto
ahora vas a entender
una cosa
muy importante
porque
ojo cuidado
si aquí ponéis
un año
significa que
la imagen de Carmen
aunque yo la cambie
se va a cachear
en Cloudflare
durante un año
y como el nombre
que tiene
este archivo
es Carmen.png
es muy fácil
que yo
cambie este nombre
porque Carmen.png
es un nombre muy normal
y entonces
quedará cacheada
siempre durante un año
la imagen
de Carmen
por eso
esa es la razón
por la que seguramente
muchas veces
te has preguntado
por qué cuando tenemos
archivos estáticos
que se generan
por aquí
por ejemplo
de javascript
y todo esto
por qué se hace
este hash
estos hashes
se utilizan
para que así
tú puedas cachear
estos archivos
hasta el infinito
y como estos hashes
vienen determinados
por el contenido
del archivo
cuando tú vuelvas
a generar
una nueva versión
de esa página web
pues si ha cambiado
el contenido del archivo
se generará
otro hash
y no colisionará
con la caché
entonces la caché
podría ser infinito
que el hash
habrá cambiado
y así no tendrás
ningún tipo de problema
por eso se utilizan
hashes en los archivos
estáticos
que esto es una cosa
que a mucha gente
se le pasa
oye pero por qué
tenemos estos hashes
y tal
pues esta es la razón
por eso utilizamos hashes
y es una buena práctica
utilizar hashes
en archivos estáticos
en este caso de Carmen
no tenemos
pero al menos
sí que podemos evitar
el hecho
de que me intenten
atacar
y que vayan a Vercell
entonces lo que vamos a hacer
es decirle
oye al menos
dos horas
ahí lo tenemos
que durante dos horas
lo vaya a cachear
Cloudflare
y no vaya al servidor
de Vercell
para que no me cueste dinero
en Vercell
vale
por ahora
vamos a hacer esto
creo que podemos
todo lo demás
todo lo demás
todo lo demás
por ahora
lo vamos a
lo vamos a
a ignorar
ahora veremos
una cosa
ah espérate
no no
no lo vamos a ignorar
porque quiero enseñaros
bien esto
y a ver si no lo vamos a leer
entre las otras opciones
esto de clave de caché
voy a agregar la configuración
vamos a poner
la protección
contra engaño
en caché
esto es para que
evite
que la gente
pueda
atacar
a la caché
e intentar engañarle
para que nos dé
el recurso
vale
porque claro
si la gente
intenta engañar
esta caché
igualmente va al servidor
de Vercell
pues entonces
no nos ha servido
de nada
vale
entonces
por ahora
vamos a poner esto
así
y ahora
y ahora veremos
si esto funciona
correctamente
guardamos
vamos a ver
esto normalmente
también tarda un poquito
o sea que puede ser
que ahora lo veamos
igual tarda un poco
vamos a ver si
vamos por aquí
revalidate
mira
ya lo tenemos
fijaos la diferencia
veis que aquí ahora pone hit
vale
estos son buenas noticias
esto significa
que ahora
Cloudflare
esta imagen
ya no está llegando
hasta Vercell
para que lo entendamos
lo que acabamos de hacer
vale
os voy a hacer
un croquis
en un momento
es que
tendríamos aquí
nuestro querido usuario
vamos a poner
un usuario
vale
hostia
no sé por qué
no lo ha pillado
pero usuario
bueno
el usuario este
que estaba haciendo
una petición
vale
esta petición
la estaba haciendo
a nuestro servidor
vamos a poner aquí
que esto sería
Cloudflare
Cloudflare
y esto
lo estaba llegando
también
a Vercell
vale
a Vercell
y que es lo que pasa
vale
pues está haciendo
la petición
en este caso
estaba pidiendo
la imagen
de carmen.png
entonces Cloudflare
pues estaba diciendo
ah no lo tengo
en la caché
aquí no está
está caché
caché
aquí no está la imagen
porque no está
cacheada esta imagen
que es lo que vamos a hacer
no está cacheada
entonces mira aquí
no está cacheada
le dice
oye
no
no
vale
no está cacheada
y por lo tanto
Cloudflare
va a Vercell
y Vercell
le devuelve
le devuelve
la información
esto es lo que estaba
ocurriendo antes
que es lo que hemos hecho ahora
claro
lo que estamos haciendo ahora
es
oye
carmen.png
ahora le dice
sí
vale
sí que está aquí cacheado
por lo tanto
ya no tenemos que
pedirle nada
a Vercell
ya no tenemos que
ir a Vercell
lo tenemos cacheado
vale
sí que lo tengo
y por lo tanto
ya le puedo devolver
desde la cache
la información
aquí
sería en rojo
vale
y estaría ocurriendo
todo esto
y ahora lo estamos
minimizando
ahora el trabajo
que se está haciendo
es mucho menos
totalmente gratis
ahora hay un problema
esto funcionar
funciona
nos estamos evitando
ya el trabajo de Vercell
pero hay un problema
y es que
qué pasa
si nos atacan
así
le ponemos una query param
a uno
y aquí en los headers
¿qué pone aquí?
miss
vale
está
está fallando
vale
hacemos a dos
¿qué pasa aquí?
también
pues vamos a ver
que también
a dos
miss
vale
lo que está pasando
es que ahora
de repente
lo que alguien
podría hacer
sería
empezar a enviarnos
una ruta
random
para intentar
atacarnos
y constantemente
primero
generar
de nuevo
un montón de recursos
en la cache
que por suerte
para nosotros
no nos cuesta dinero
en Cloudflare
pero lo está intentando
pero lo que va a ocurrir
es que ahora
constantemente
va a estar haciendo
peticiones a Vercell
porque se está saltando
totalmente la protección
que hemos hecho
ahora
para arreglar esto
esto se puede arreglar
por supuesto
tenemos que modificar
la regla que hemos hecho
de la caché
la vamos a editar
vale
y ahora aquí
lo que podemos hacer
en la clave de caché
es decirle
que
ignore
la cadena de consulta
entrega el mismo recurso
a todos
sin importar
la cadena de consulta
claro
esto lo podemos hacer
con las imágenes
con algunas APIs
también
para evitar
que tenga en cuenta
la cadena de consulta
que sería la query string
porque la query string
al final
lo que estamos haciendo
es decirle
ostras
pues vamos a evitar
la query string
la ignoramos totalmente
y me lo cacheas
exactamente igual
pero claro
hay algunas APIs
que sí que puede ser
que la query string
pues no se pueda cachear
porque si es una API
que acepta
por la query string
en la URL
pues un montón de parámetros
claro
pues no lo vamos a poder cachear
así que tened en cuenta
por ejemplo
si tenemos una URL
que sea
api.pokemon.com
y aquí
pones una query string
que sea Pikachu
no lo puedes ignorar
porque si pones Pikachu
si pones aquí
Bulbasaur
Bulbasaur
o lo que sea
pues no puedes cachearlo
todo igual
pero para esto
también se pueden hacer
otras cosas
como el rate limit
pero al menos
sí que lo podríamos hacer
para ciertas URL
que sí que puede ser
que no sean tan importantes
como puede ser
el tema de los estáticos
de hecho ahora
si ha pasado
el tiempo suficiente
vale
aquí deberíamos ver
vale
aquí tendríamos
tú tú tú
bueno
esto me ha puesto no cache
vamos a ver
ah espérate
no cache
no
aquí tenemos miss
vale
aquí tenemos a dos
ah espérate
vamos a también
vamos a también
también
también tenemos que hacer
una cosita
vale
ahora sí que me pone hit
vamos a ver si me pone miss
porque puede ser que no lo ponga
sí que lo pone
vale
veis hit
ahora da igual
da igual lo que pongas aquí
vale
pum
da igual lo que pongas aquí
tú te puedes inventar
la URL que quieras
que ahora se va a ignorar
y está yendo siempre
a la cache
entonces lo que hemos evitado
que es
vale
pues el ataque
que nos estaban intentando hacer
era
este ataque
como han visto
que pues ha dicho
ostras
sí que ha puesto cache
vale
pues vamos a hacer
voy a inventarme
esta URL
aquí constantemente
aquí voy a poner
un random
vale
para estar cambiando
totalmente la URL
y constantemente
en la cache
no aparecerá
pero lo que hemos hecho
aquí en la cache
es que en lugar de preguntarle
por este random
nosotros ignoramos esto
y le preguntamos
no no
aunque haya un query string
a mí lo que quiero
es por el recurso
de Carmen
entonces me dice
ah sí
ese sí que lo tengo
el de Carmen.png
sí
pues si no me pasa
query string
perfecto
y ya está
y ya lo hemos vuelto
a arreglar
esto es otro ataque
súper típico
muy común
que suele ocurrir
muchísimo
vale
más cositas
que teníamos
en Cloudflare
e importantes
para temas de rendimiento
y tal
tendríamos
esto también lo podéis utilizar
para APIs
de hecho
antes que hemos hecho
la API este
que hemos utilizado
teníamos esto
de la DepthLeak
teníamos
la
API
barra
number
vale
que esto le hemos puesto
un rate limit
un rate limit
que si yo me pongo aquí
todo el rato
eventualmente
debería aparecer
a ver si aparece
¿veis?
me aparece el rate limit
error 1015
como podéis ver
oye ha sido
rate limit
hemos puesto el límite ese
de cada 10 segundos
10 peticiones
entonces te peta
que cuando pasan 10 segundos
lo puedo volver a hacer
es bastante interesante
por esto
luego
esto
el problema que tenemos
aquí también
es un tema de recursos
¿ves que nos pone
que esto es dinámico?
podríamos decir
oye pues quiero que también
la API
API
API caché
le podemos decir
que si la ruta
pues sea
barra
API
barra
asterisco
vamos a decir
que también vaya
a la caché
vamos
como esta
API si que tiene sentido
que la podamos cachear
porque pone el número
y que más da
que durante dos horas
ponga el valor anterior
o sea
tampoco pasa nada
¿vale?
lo podríamos hacer
entonces podemos ignorarlo
le podemos decir
vale pues durante dos horas
le decimos
clave de caché
la protección contra engaños
que ignore la cadena de consultas
porque en esta API
no
no sirve para nada
la API
la
la query string
¿vale?
siempre nos tiene que dar
este valor
cuando se pone en grande
queda muy mal
pero bueno
siempre nos tiene que dar
este valor
no utiliza query string
lo podemos hacer
lo podemos implementar
y esto puede ser interesante
para algunas APIs
que también de alguna forma
os de información estática
¿vale?
y así ya no
no tengáis
que esta también sea dinámica
ahora
igual tarda un poquito
pero eventualmente
debería aparecer
por aquí
a ver
¿vale?
ahora todavía aparece
dynamic
a ver si
aparece eventualmente
aquí
dynamic
bueno
puede tardar un poquito
a ver si
yo creo que lo he puesto bien
igual se me ha
no
yo creo que lo he puesto bien
dynamic
puede tardar un poco
también tarda
ya os digo que tarda
un poquito
a ver
dynamic
bueno
podemos estar ahí
todo el día
pero ya os digo
que esto lo podéis hacer
sin ningún problema
para cachearlo
porque de hecho
yo tengo algunas
cacheadas así
a ver
esto lo he puesto
sí
API
yo creo que sí
que el query string
ese está bien
dynamic
vamos a ver otra vez
dynamic
dynamic
dynamic
otra vez
a ver
elegible para cache
ignorar el cabezado
clave de cache
vale
se enseña que la regla
se alterará después
no yo creo que se lo he hecho
dice
cuando utiliza la query string
de igual manera
se hace la petición al servidor
si no tenemos esa regla
que ignorará
claro
exacto
se haría la petición
claro que se haría la petición
por eso hay que tener cuidado
mira ya está
hit
claro
hit
esto significa
que esta petición
no ha llegado a Vercell
y entonces por lo tanto
en Vercell
ya no nos estarían facturando
por esta petición
de aquí
en el usage
este function invocations
que fijaos
que tenemos ya un millón
que nos ha hecho esto
de hecho seguramente ahora
pues me han estado
con todo lo que hemos hecho hoy
pues me habrá estado atacando gente
y tal
de hecho veis que aquí me ha crecido
hoy ahora esto
podríamos ver
que si alguien me ha estado atacando
que es lo que ha hecho
algunas invocaciones
is request
pero es una forma muy interesante
de ver justamente
las invocaciones
que se están haciendo
y tal ves
ahora yo ya he llegado
y a partir de ahora
ya voy a tener que pagar esto
bueno pues no
no pasa absolutamente nada
si lo haces por cur
tarda igual
lo digo más que nada
para comprobar
que está operativa la regla
si lo hacemos por cur
aparte que vamos a tener
rate limit
vale
a ver
igual que vamos a tener
rate limit
ves
está limitado
el tema es que también
va a funcionar la caché
lo digo para que lo tengáis
en cuenta
ahora no me acuerdo
como se hacía
menos a
menos h
como era para ver
la respuesta
para ver la respuesta
de cur
como era para ver
la respuesta de cur
tu tu tu tu
a ver
parámetro
parámetro
para ver
la
el response
headers
en cur
ahora no me acuerdo
del parámetro
el menos i
vale
menos i
vale
no sé
me voy a acordar
que era menos i
menos i
vale
el menos i
ahora
si nos ponemos a mirar
por aquí
veremos
que debería tener
el caché
hit
no lo veo
por aquí
no lo veo
debe estar por ahí
pero no lo veo
porque como me lo está cortando
es que claro
me sale tanta información
por aquí
a ver
a ver
hit
bueno
aparece por ahí
ves aquí
caché status hit
o sea la caché
también funciona para
para cur
obviamente
totalmente
cositas interesantes
aparte de todo esto
que debéis tener
primero
scrape shield
esto también es interesante
para protegeros de hotlink
que esto es que alguien
pueda utilizar
pueda utilizar vuestras imágenes
desde otro servidor
esto también está muy interesante
otras cosas
que también os recomiendo
el tema de optimización
en speed
tenéis esto de observar
que durante una
una vez a la semana
podéis observar
en rendimiento
y en optimización
tenéis reglas
muy fáciles
que rápidamente
podéis optimizar
algunas cositas
imágenes no
que es de pago
pero de contenido
optimizar las fuentes
si las estáis cargando
de google
phones
smart hints
esto es para mejorar
cuando
ah bueno
esto es de pago
también smart hints
que pena
que pena
esto es de pago
que pena
porque eso está súper chulo
pues optimización
de protocolo
esto sí
que podéis optimizar
algunas cosas
de http 3
esto sí que lo podéis activar
todo esto está bien
activarlo
no hay ningún problema
y poca cosa más
o sea la optimización
de protocolo
es todo lo que podéis activar
y ya lo tendríais
bueno amigos
me tengo que ir
pero
me tengo que ir
porque voy a ir a correr
y voy justito
hola
hola
se pueden proteger
imágenes dinámicas
como en un e-commerce
exactamente
lo podéis hacer
con la caché
con el ray limit
lo podéis hacer exactamente igual
sin ningún tipo de problema
mañana
mañana vamos a hacer
las votaciones
de los proyectos finales
de la hackatón
de Bersel
ya tenemos finalistas
seleccionados
espero y deseo
que os haya servido
todo el tema este
de Cloudflare
me gustaría volver a hacer
otro curso más
pero más pensado
en todos los servicios
para desarrolladores
R2
CDN
imágenes
stream
workers
y todo esto
porque Cloudflare
no solo es para evitar ataques
sino que también puede ser
para que construyáis
aplicaciones
y proyectos
mañana hacemos
la revisión
de los proyectos
de la hackatón
de Bersel
hay unos proyectazos
que vais a alucinar
que son espectaculares
vale
y
que más os quería contar
ah si
solo recordaros
que tenéis la MiduConf
para que os registréis
que tenéis ya
la oportunidad
de conseguir vuestro ticket
de compartirlo
y muchas cosas más
así que
muchas gracias
por haberos pasado
espero que hayáis aprendido
alguna cosita nueva
ostras
mañana os explico
lo del redirect
que no me ha dado tiempo
a arreglarlo
que es que me tengo que ir
porque he quedado
a las 8 para correr
pero mañana
os explicaré en un momento
también como arreglar
el tema del redirect
que tenemos en el curso
react.dev
pero esto básicamente
es por
ah bueno
esto
pero luego de esto
debería aparecer
la redirección infinita
que nos está ocurriendo
ah no
ah porque lo he podido arreglar
porque me lo habrá puesto
en full
el problema
mira lo voy a explicar
en un momento
el problema
es que estarían flexible
vale
el problema
es que en el proyecto
seguramente
me lo he arreglado
solo el Cloudflare
el tema es que
en curso react.dev
en el SSL
en el
en este
en este modo
vale
continue
no sé qué
no sé cuánto
bueno esto no sé por qué es
pero en este modo
seguramente
me lo había puesto
en flexible
entonces tenéis que pasarlo
a completo
y al pasarlo a completo
ya lo tendríais arreglado
vale
seguramente
como en algún momento
he puesto que me lo ponga
de la forma recomendada
o porque me ha debido llegar
un correo
y lo que sea
pues
y tiene ahí un call to action
para arreglarlo
pues seguramente
se habrá arreglado
eso es lo único
que tenéis que hacer
cambiarlo del SSL
y ya está
pues nada
caché
optimización
evitar ataques
ya sabéis
que es un 2
un D2
un E2
que es lo que suele ocurrir
y espero que os haya servido
para conocer un montón más
sobre Vercell
sobre Cloudflare
y evitar facturas
no
que no
¡compa!
que no
que no
анич4
que no
sí
se me encuentra
muy bien
como
muе cook
la
o
actuar
y
se me route