Cómo Proteger tu Web con Cloudflare

Hola, buenos días. Bienvenidos a Cloudflare. Soy Sergio, soy ingeniero de soluciones. Llevo más o menos un añito en Cloudflare y hoy me acompaña Pablo, que es otro ingeniero y juntos vamos a guiaros a través de cómo añadir una página web a Cloudflare y protegerla de forma sencilla. Pablo, si queréis decir algo. Hola, buenos días, buenas tardes, depende de donde estéis. Mi nombre es Pablo Camino. Trabajo como solución en Cloudflare desde hace tres años. Como comentó Sergio, vamos a intentar enseñaros un poco cómo hacer un onboarding muy simple a Cloudflare con las cosas básicas, un poco de seguridad, un poco de performance y cómo mover el DNS. Creo que Sergio va a compartir la pantalla y ahora nos va a enseñar un servidor que tenemos ahí con una cuenta demo. Vamos a empezar todo esto desde el principio viendo el servidor. Como veis, por ejemplo, ahora mismo el servidor tiene la IP, no tiene ningún dominio, no tiene certificado. Esto es una cuenta demo, algo súper básico. Vamos a intentar hacer el onboarding. Tenemos 30 minutos, vamos justos de tiempo, pero yo creo que lo podemos hacer. ¿Cómo empezamos? Seguro que lo podemos hacer. Lo primero de todo es hacerse una cuenta en Cloudflare. Es muy sencillo, solo tienes que ir a la página web de Cloudflare y pulsar en registrarse. En mi caso, como ya tengo cuenta aquí, se ha abierto automáticamente mi cuenta, que es lo que ocurriría cuando vosotros os la crearais y ahora el siguiente paso que tendríamos que hacer sería añadir el dominio a nuestra cuenta. Pulsaríamos en add site y añadiríamos aquí nuestro dominio. Es un paso que también nos vamos a saltar porque para hacerlo más ágil, nosotros ya lo hemos añadido y es este que veis aquí. Correcto. Es súper simple comentar que básicamente en el momento que vosotros creáis la cuenta teníais que añadir un sitio. El sitio que añadís tiene que ser un dominio raíz, no tiene que ser un subdominio, tiene que ser el dominio Apex y luego a partir de ahí os llevaría por una especie de wizard en el que os vamos a escanear los DNS, después os haríamos unas preguntas sobre SSL TLS. Lo mejor es que vayáis todo siguiente, siguiente, siguiente y lleguéis un poco al dashboard donde estamos ahora. Toda esa configuración la podemos hacer aquí. Entonces, venimos hasta este dashboard y lo primero de todo, ¿qué vamos a hacer? Lo primero de todo va a ser importar los registros que teníamos en nuestro antiguo proveedor de DNS a EclosFlare. Para ello es muy simple, nosotros hemos exportado de nuestro antiguo proveedor un archivo BIN y vamos a importarlo seleccionándolo desde aquí. Esta parte es súper importante. Por defecto, nosotros vamos a escanear todos los DNS y vamos a traer nuestros records. Obviamente, si vuestras zonas tienen miles de records y son muy grandes, posiblemente nos vamos a dejar algunos. Esta es la forma segura de hacerlo. Exportáis vuestro archivo, lo subís aquí y estáis seguros de que todos los registros DNS están en Cloudflare. Ahora Sergio va a hacer un cambio aquí que básicamente va a convertir todos los registros a DNS only. Como veis, hay una nube, esa nube puede ser naranja o gris. Si la nube es naranja significa que Cloudflare está haciendo proxy del tráfico, significa que estamos dando seguridad, dando performance, todo este tipo de cosas y cuando la nube es gris, lo que hacemos es básicamente solo damos un servicio de DNS. Vamos a hacer esto primero porque no queremos que cuando el tráfico se mueva hacia Cloudflare, de repente algo esté mal configurado en Cloudflare y todo funcione mal. Lo primero que ponemos todo en DNS y vamos a seguir la configuración. Ya tenemos todo aquí. Un par de cosas para comentar a nivel de DNS si vamos un poco más hacia abajo. Aquí como veis, Cloudflare os da dos nameservers, en este caso son Bart y Nina y luego tenemos tres opciones más. Una sería añadir los custom nameservers. Esto básicamente es si tú quieres en vez de mostrar que Cloudflare te esté dando servicio de DNS, quieres mostrar vuestro branding, vuestro nombre, pues podéis añadir los custom nameservers. DNSSEC también lo podéis habilitar. Un clic, los proveemos todos los datos, los ponéis en vuestro registro y a correr. Y el SYNINFLATENING, que básicamente esto es si queréis hacer alias a nivel de root y queréis mandar tráfico a través de un cename, lo podéis hacer también. Ahora, ¿qué nos falta hacer? Ahora nos vamos a asegurar de que todo el apartado de SSL funciona, entonces nos vamos a ir a la pestaña de SSL, como veis aquí. Lo primero de todo, vamos a hablar un ratito de los distintos tipos, los distintos modos de actuación que tiene SSL dentro de Cloudflare. El estándar es el modo full, que lo que hace es que encripta la comunicación tanto del seguidor de origen hacia Cloudflare como de Cloudflare hacia el cliente, hacia vuestro cliente. Es el modo que nosotros hemos elegido. También hay distintos modos y creo que Pablo os va a hablar un poco sobre ellos. Tenemos otros modos, básicamente vamos a ir muy rápidamente porque tampoco queremos profundizar muchísimo. Fullstreet sería muy parecido a full, la única diferencia sería que validaríamos el certificado que está instalado en el origen, con lo cual tiene que ser un certificado firmado por una CEA válida, tiene que contener el hostname que está accediendo a Cloudflare y todo este tipo de cosas. La parte de flexible es en caso de que tu origen no soporte HTTPS, podríamos servir desde el browser a Cloudflare, podríamos servir el contenido sobre HTTPS y desde Cloudflare al origen es sobre HTTP. Obviamente no está recomendado porque iría en texto plano y si alguien es nifa tráfico se podría ver tarjetas de crédito, información, login y todo este tipo de cosas. Pero bueno, si tienes esta limitación lo podrías hacer. Y luego lo último sería el Origin Pool que básicamente lo que haría es que subiría todas las conexiones del puerto 80443. Aunque a ti desde el browser hablo a Cloudflare, accedan sobre texto plano en HTTP, desde Cloudflare al origen se subiría todo a HTTPS. Es como un siguiente modo a nivel de seguridad. Y ahora vamos a echar un vistazo a los certificados a ver qué tenemos por ahí. Como veis no tenemos ningún certificado desplegado, por defecto Cloudflare despliega uno cuando insertamos un dominio en Cloudflare, pero nosotros lo hemos eliminado anteriormente para que veáis cómo sería si no hay ningún certificado. Es importante que nos aseguremos de que aquí tenemos un certificado válido antes de usar Cloudflare para asegurarnos de que no tenemos ninguna pérdida de servicio en nuestra página web. Vale, entonces aquí un poco más abajo tenemos la posibilidad de habilitarlo, ¿no? Sí, es lo que vamos a hacer ahora. Como veis, si estáis creando un dominio desde cero, obviamente, a vosotros esta parte no la tendríais que hacer porque estaría habilitado, ya estaría un certificado ahí funcionando, ¿vale? Vamos a hacer refresh de la página porque se ha borrado, pero va a aparecer aquí, ¿vale? El caso es que la parte muy importante, como veis ahora se pone pending deployment, la parte muy importante es que vosotros no tenéis que empezar a hacer proxy del tráfico hasta que el certificado se ponga activo, ¿vale? Eso es algo clave porque si Cloudflare no tiene ningún certificado, obviamente todas las conexiones SSL van a fallar, ¿vale? Entonces es súper, súper importante que si no hay certificado activo por parte de Cloudflare, vosotros subáis vuestro certificado, que lo podéis hacer en el botón que pone Upload Custom SSL Certificate, podéis subir vuestro certificado y estar seguro, pero siempre tiene que haber un certificado SSL en Cloudflare para poder emitir tráfico, ¿vale? Y aquí debajo justo tenemos unas opciones, ¿no? Sí, tenemos, por ejemplo, la opción de redireccionar todo el tráfico HTTP a HTTPS, que es algo que vamos a activar. También tenemos el TLS mínimo, que también lo vamos a poner a 1.2, ¿a que sí, Pablo? Sí, a ver, esta parte es también bastante importante, sobre todo si tenemos, por ejemplo, si somos PCI Compliance o tenemos que pasar este tipo de certificaciones, nos van a exigir que el servicio de TLS mínimo sea 1.2, aquí lo podéis seleccionar, podéis habilitar, por ejemplo, también TLS 1.3 y se le va a redirigir todo HTTPS. Hay algunas opciones más, por ejemplo, reescribir todo HTTPS, algunas opciones que realmente ahora mismo no vamos a tocar, esto sería un poco lo mínimo y lo recomendado. Ya estaría toda la parte SSL TLS, tenemos el certificado activo, tenemos todos los registros de DNS, ¿vale? Ahora, ¿qué haríamos? Ahora vamos a empezar a hacer realmente proxy del tráfico, ¿no? Claro, entonces, para ello lo que vamos a hacer va a ser volver al tab de DNS y vamos a coger los DNS servers que nos ha asignado el Cloudflare, estos dos, y los vamos a copiar a nuestro registrar, ¿vale? En nuestro caso, nuestro antiguo registrar era root53 y los vamos a añadir aquí en nameservers, como veis, en register domains y luego aquí en nameservers. En nuestro caso ya lo hemos cambiado antes para acelerar un poco el proceso y la propagación de los cambios, entonces este paso ya estaría hecho. Vale, entonces una vez hecho, ya llegamos a la cuenta de Cloudflare, se volvería activa, todo empezaría a funcionar y lo que va a hacer Sergio, si te fijas ahora, es va a empezar a hacer proxy del tráfico, ¿vale? Como veis, hay como unos 10 o 12 registros y hay algunos que no va a habilitarlos. Ha saltado, por ejemplo, InMap1 e InMap2. ¿Por qué hacemos esto, Sergio? Hacemos esto porque Cloudflare, por defecto, solo hace proxy del tráfico HTTP y HTTPS. Si nosotros configuráramos nuestros servidores de correo para que hicieran proxy a través de Cloudflare, pues prenderíamos el tráfico de correo, ¿vale? Aquí, muy importante, obviamente, como bien dice Sergio, por defecto Cloudflare va a hacer HTTP y HTTPS, pero no significa que no podamos hacer proxy de cualquier otro protocolo, ¿vale? Tenemos un producto que no vamos a tocar ahora mismo que se llama Spectrum, ¿vale? Este producto permitiría hacer proxy de cualquier TCP UDP, con lo cual hay clientes que lo usan, por ejemplo, para hacer tráfico de mail, tráfico, por ejemplo, no sé, tráfico de FTP, SSH, RDP, lo que quieras, ¿vale? La idea es que, por defecto, aquí en DNS solo el tráfico HTTP y HTTPS, es una parte importante, si no Cloudflare puede dejar de funcionar y tu servicio puede dejar de funcionar, ¿vale? Vale, pues ahora mismo ya tendríamos Cloudflare habilitado, tenemos el certificado SSL, tenemos todos los DNS, está todo habilitado a nivel de proxy, ya empezaríamos, ahora mismo Cloudflare empezaría a anunciar estos registros con las IPs de Cloudflare en vez de con las IPs reales, ¿vale? Y ahora creo que teníamos unos requerimientos a nivel de seguridad, ¿no? A nivel de Firewall que queríamos hacer. Sí, y para ello lo que vamos a hacer va a seguirnos a la tab de Firewall y vamos a activar, lo primero de todo vamos a activar el Firewall, es un botón muy sencillo de activar y también vamos a configurar un poco los paquetes de reglas que nos ofrece Cloudflare. Los primeros son los paquetes de reglas OWASP que están, bueno, están basadas en las reglas de OWASP. Vamos a configurar su sensibilidad a Medium y la acción a Simular, porque primero de todo nos queremos asegurar de que no hay ningún tráfico que esté recibiendo nuestra web que esté generando un falso positivo. Vale, y un poco más abajo tenemos, sí. Sí, aquí tenemos los paquetes de reglas que generan nuestros ingenieros de seguridad con todo el tráfico que vemos día a día. Más o menos vemos 17 millones de peticiones al segundo, lo cual es un montón. Y nosotros vamos a activar, bueno, hay dos paquetes que sí o sí tenemos que activar que es el Cloudflare Miscellaneous y el Cloudflare Specials y también nosotros vamos a activar el Cloudflare PHP porque en nuestro caso el backend de nuestra web está escrito en PHP y queremos asegurarnos que nadie puede atacar nuestro backend. Correcto. Como veis, la idea es proveer un servicio bastante simple, ¿no? O sea, habilitáis el WAF, es un botón que podéis elegir los tipos de categorías y habilitar lo que necesitéis, ¿vale? Aquí abajo tenéis la parte de protección de DDoS. Esto realmente es un poco testimonial en el sentido de decir que realmente no podéis modificar nada de lo que haya de DDoS. Es algo que Cloudflare tiene 200 datacenters, 200 POPs, puntos de presencia alrededor de todo el mundo. No tenemos Scrubbing Centers en el sentido de decir que cada POP puede hacer DDoS, digamos, por él mismo, ¿vale? Y esto es un poco los tipos de ataques volumétricos que podríamos parar, ¿vale? Como comentó Sergio, Cloudflare Specials es posiblemente la más importante, tiene las que más reglas tiene, tenemos ingenieros de seguridad que están constantemente chequeando, pues eso, vulnerabilidades, nuevos tipos de agujeros de seguridad y van poniendo todas las reglas ahí, ¿vale? Si por ejemplo clicáis ahí esto es súper simple, veríais el número de la regla y podéis decidir qué acción queréis tomar, por ejemplo podéis moverlos a Block, a Simulate, a lo que sea, ¿vale? En plan, la idea es que un poco Cloudflare lo que quiere hacer con el WAF es, quiere daros un WAF que sea simple de manejar, no quiere que necesitéis un ingeniero de seguridad súper experto que maneje esto. Esto, como veis, la configuración estática funciona muy bien y no tenéis que hacer prácticamente nada más que habilitarlo, ¿vale? Luego la parte de OWASP, bueno, pues eso es un estándar de seguridad y como Sergio hizo, lo tenéis que poner en Simulate. A ver, esto es un poco como queráis. Obviamente, si vosotros conocéis OWASP y estáis habituados a utilizarlo y a manejarlo, pues posiblemente podéis tomar una acción. Lo que pasa es que OWASP es bastante agresivo puede crear bastantes pasos positivos, incluso puede bloquear tráfico real y lo recomendado es ponerlo en Simulate por una semana, dos semanas, analizáis qué tipo de tráfico tenéis y en función de eso podéis empezar a decir, oye, pues quiero bajar la sensibilidad y quiero tomar acción de Challenge o Block o lo que sea, ¿vale? Y justo un poco encima de esto hay una pequeña tarjeta que pone Customer Requested Rules. Esta tarjeta tendría todas las reglas que vosotros podéis pedir, ¿vale? O sea, Cloudflare no deja que vosotros escribáis reglas WAF como cliente, ¿vale? Pero vosotros las podéis pedir, nos enviaríais los logs, el payload, cualquier información que sea importante para vosotros y nosotros podríamos crear la regla y la pondríamos dentro de esta tarjeta, ¿vale? Entonces, ahora mismo ya estaría toda la parte WAF configurada. Tenemos dos requerimientos más. Uno que será la parte de Firewall Rules, ¿no? Sí. Firewall Rules es otra forma que entregamos a nuestros clientes para generar reglas de Firewall. Como veis, tenía por ahí que acabo de eliminar. Nosotros vamos a crear una regla especial, ¿no? Que va a ser específica para bloquear cierto tráfico que estamos recibiendo con un user agent específico y desde Reino Unido, desde un país específico, ¿no? Entonces, lo primero le vamos a poner un nombre. Elegimos que el user agent contenga la palabra WAF y también que el país de origen sea Reino Unido, ¿vale? Bueno, como veis, tenemos muchas otras más opciones que podemos elegir. Por ejemplo, podemos elegir también que el método sea Get. Vamos a poner un ejemplo. Y, finalmente, podemos elegir la acción que queremos hacer. Bueno, Pablo, si quieres explicar un poco las acciones que podemos hacer. Sí. Aquí, como veis, bueno, súper rápido, como veis, hay una serie de dropdown que podéis elegir. Como podéis elegir muchísimos campos, desde campos que afectan a URL, podéis cookies, hay cabeceras. Y, luego, los operadores son muy interesantes porque podéis hacer también usar regex, podéis usar que contenga, que sea igual, que sea diferente. O sea, es súper, súper flexible. Como veis, tenéis también AND y OR, con lo cual podéis hacer nesting de las reglas. Podéis juntarlas o separarlas con diferentes tipos de, digamos, en paréntesis. Y si os sentís también bastante cómodos y os gusta más el comando, más o menos como el modo quizás más clásico, tenéis la parte esta en la que podéis realmente escribir la regla. Usamos la expresión que usamos y la gramática sería la de wildsort, ¿vale? Entonces, bueno, si os sentís cómodos haciendo esto, pues la podéis escribir directamente. Y, luego, a nivel de acciones, pues podemos bloquear, podemos hacer bypass, podemos hacer JavaScript challenge y podemos permitir y lograr el tráfico. En este caso, vamos a hacer bloquear y vamos a desplegar la regla. Y tendríamos, a nivel de seguridad, un último requerimiento, ¿no? Para un tema de un post. Sí, y para ello nos vamos a ir a nuestro a nuestra página web. Vamos a asegurarnos de que funciona. Puede ser el DNS. Vete a la parte de DNS y no, yo creo que es, me refiero, vete directamente en directo al post, vete a la IP. Ah, vale, de acuerdo. Vete a la IP y vete al post de abajo. Sí, vamos a... Bueno, un problema que nosotros tenemos es que tenemos un usuario que es, bueno, tenemos un pequeño formulario donde los usuarios nos pueden dejar mensajes y, sin embargo, tenemos un pequeño, bueno, tenemos un usuario malicioso que lo que está haciendo es que está incluyendo, bueno, nos está enviando mensajes basura constantemente, ¿no? Entonces, vamos a hacer uso de un producto que tiene Cloudflare que se llama Red Limiting para evitar que un usuario nos dé la chapa en ese formulario. ¿Cómo lo podemos hacer? Bueno, hemos visto que cuando pulsamos Submit lo que se genera es un mensaje post, así que vamos a bloquear los mensajes post que vengan de esa página web. Vale, súper, súper simple. Red Limiting es bastante útil, ¿vale? Nosotros tenemos una parte de protección de díos en la que, obviamente, enseñamos, o sea, protegemos cualquier tipo de tráfico, ¿vale? Pero Red Limiting es muy útil para ataques de K7 que son mucho más lentos, que no son realmente súper volumétricos, ¿vale? Aquí es donde podéis crear vuestras reglas y en este caso, por ejemplo, vamos a crear una regla para bloquear ese post. ¿Vale? Sí, vamos a darle a crear regla, ¿vale? Y, bueno, lo primero de todo es que le vamos a poner un nombre, vamos a ponerle Blog Comments, por ejemplo. Y, bueno, elegimos la URL que queremos proteger, en este caso, Digestive Home, ¿vale? El número máximo de intentos que vamos a dejar por usuario, vamos a decirle que sean tres intentos cada minuto. Es muy raro que un usuario nos envíe tres mensajes en un mismo minuto. Y también vamos a configurar algunos criterios avanzados, por ejemplo, como hemos visto que el mensaje que está dañando a nuestro servidor es un mensaje post, pues vamos a elegir que Clojure solo cuente como, solo cuente en este right limiting los mensajes post y también vamos a hacer que no distinga entre los mensajes que están cacheados dentro de Clojure, las requests que se han cacheado dentro de nuestra CDN y los mensajes que no. Así que vamos a pulsar en este pequeño, en esta pequeña cajita. Como veis, muy simple de configurar, bastante intuitivo, todo está más o menos claro de que hay que hacer. Simple, podéis hacer, aquí tenéis una casilla que significa Origin Response Codes, que básicamente podéis decir quiero que haga triggering o quiero que empiece a saltar el right limiting solo si mi servidor responde con X códigos, pues 400, 500, lo que quieras, ¿vale? Luego elegirías la acción, elegirías por cuánto tiempo quieres que esa acción afecte a ese usuario, por ejemplo en ese caso Sergio tiene puesto block y le falta por elegir el tiempo a la derecha, perfecto, y vamos a un minuto, que eso significaría que por un minuto ese usuario va a ser bloqueado, ¿vale? Y luego también aquí puede customizar la respuesta, si por ejemplo por defecto la página de Clojure no te gusta, podrías customizarla, ¿vale? Pues tenemos la regla hecha, tenemos el right limiting, tenemos el firewall rule, ya tendríamos más o menos toda la parte de seguridad configurada, ¿no? Vamos a despegar esta regla. Vamos a ir rápidamente a la parte de performance para habilitar una serie de cosas. Lo primero va a ser, vamos a activar una optimización de imagen sin pérdida, ¿vale? Y también vamos a cambiar el formato de nuestras imágenes a WebP, que es un formato más comprimido. También vamos a activar las opciones de minify, que lo que hacen es que eliminan caracteres de nuestros JavaScript y CSS y HTML que usa nuestra página, que no son necesarios como espacios en blanco o saltos de línea. Vamos a activar también Broadlink, que es una compresión que es más efectiva que Fzip. En general, la idea de Cloudflare es una que todo supe bastante siempre, como veis hay bastantes tarjetas, hay bastante descripción de lo que hace cada cosa, ¿vale? Aquí debajo hay bastantes otras opciones, un poco más complejas. La que vamos a habilitar ahora mismo es la priorización sobre HTTP version 2. Esto lo que va a hacer es que Cloudflare va a decir al navegador qué objeto se tiene que descargar primero, en función de qué navegador sea. Hay algunos navegadores que lo hacen bien, otros que lo hacen peor. Al final la idea es que haciendo eso la experiencia de usuario es bastante mejor. Hay otros productos como Mirage, Rocket Loader, que no vamos a entrar ahora mismo, que son un poco más complejos y requerirían casi un capítulo aparte. Vamos a dejar esto por ahora así. Solo comentar que de lo que ha habilitado Sergio todo es bastante seguro, no va a crear ningún tipo de problema en general. Autominify quizás es uno de los que más pueda, a ver no crear problemas, pero obviamente cuando haces Autominify lo que va a hacer Cloudflare es coger los javascripts de ese HTML y los va a leer, le va a quitar comentarios, espacios, caracteres que básicamente no se necesitan para ejecutar código. Puede llegar a afectar en alguna forma al javascript, pero vamos que sería bastante raro y siempre existe la posibilidad de primero probarlo en un dominio de prueba y luego ya pasar para producción. Vamos a ir rápidamente a Firewall. Hay algo de tráfico lanzado contra esta web. Ya deberíamos ver justo a la derecha que hay un pico y ya podemos ver por servicio qué tipo de acciones tenemos. Ya empezamos a ver que tenemos WAF, tenemos rebadge de Firewall y tenemos Red Limit. Y justo a la derecha tenemos Browser Integrity Check, que esto está normalmente habilitado por defecto. Es una característica que lo que hace es verifica que las cadenas de UserAgent no contienen ningún carácter un poco raro, o sea que no contienen a lo mejor, o que están bien formadas. Viene de una lista, verifica y que no haya nada raro. En función de eso si considera que el UserAgent no es válido, lo va a bloquear. Ya vemos que hay tráfico bloqueado ya desde Bad Actor, que es lo que ha creado Sergio hace un minuto desde UK. También tráfico desde Estados Unidos y las IPS de donde está viniendo el tráfico. Vale, yo creo que nos quedan cinco minutitos. Vamos a pasar a la parte de PageRules, a enseñar un poco la parte de caching. Primero, Sergio, vete por favor a la parte de cacheo. Sí. A la parte de soporte de cacheo un momento. A ver si no es la página de cacheo que pone las partes estáticas. No, prefiero en el tab de arriba, en la tab que tienes abierta arriba. Sí, te acuerdo, perdón. Aquí básicamente cómo funciona Cloudflare o cómo funciona la cache por efecto de Cloudflare. Cacheamos lo que se llama contenido estático. ¿Qué es contenido estático? Son estas extensiones. Y un poco más arriba está el tiempo por defecto de cuánto cacheamos las cosas. Como veis, justo debajo están los 404 y 403 que los cachamos por tres minutos y un minuto. Hay muchos clientes que obviamente no quieren hacer eso porque básicamente no quieren cachar en 400. Entonces vamos a crear una PageRule que lo que va a hacer es va a evitar ese cacheo. Entonces vamos a las PageRules mientras Sergio crea la regla, yo os voy a comentar rápidamente que las PageRules es un poco la forma por defecto de modificar el comportamiento por defecto de Cloudflare. Entonces lo que está haciendo Sergio ahora mismo está definiendo una URL, todo lo que mache esa URL va a tener esa acción de la PageRule y está haciendo un castctl por estado de código y ha seleccionado un rango entero de 400 a 499. Con lo cual cuando creen 400 no se va a cachear, se va a hacer el bypass. Y ahora vamos a hacer también lo del WAF. Vamos a hacer el bypass del WAF para una Intranet o para un Development o algo de esto. Sí, tenemos también una pequeña URL que están usando nuestros desarrolladores para hacer pruebas y queremos desactivar el WAF en esa URL. Así que simplemente lo desactivamos y desplegamos la regla y en muy poco tiempo debería estar desplegada en toda nuestra red. Claro, como veis esto es también súper útil. Me refiero al tipo, muchas empresas tienen equipos de Development, equipos de desarrollo que están haciendo pruebas constantemente y a lo mejor esa gente no quiere realmente que el WAF esté saltando. ¿Por qué? Pues porque nos va a molestar, porque ellos hacen cosas un poco más rarillas y pueden saltar. Entonces mediante eso quitamos el WAF de todo ese path. Y ahora lo que está haciendo Sergio es crear una regla para forzar el cacheo. Sí, ahora vamos a hacer una regla para forzar el cacheo de las imágenes que tenemos en nuestra web de una forma específica como nosotros queremos y sin hacer caso a las cabeceras que nos están llegando del servidor de origen. Entonces lo primero va a ser configurar el cache level para cache everything, todo lo que esté por debajo de esta URL lo vamos a cachear sí o sí. Lo segundo va a ser elegir el TTL del navegador, lo vamos a poner a 5 minutos y por último vamos a también elegir el TTL de nuestra CDN que lo vamos a poner a 10 minutos. ¿Y qué pasa si por ejemplo un usuario ya está logueado y quiere que el usuario que está logueado no se cachee porque no queremos darle contenido que no es suyo? ¿Cómo podemos hacer esto? Pues vamos a añadir también otra opción más a esta page rule que va a ser permitir que no se cacheen elementos cuando existe un header que es username. Nos quedan creo que segundos, creo que si vas a la web y haces reset o vas a digestive.be debería funcionar. Ya vemos que básicamente la web está funcionando, que tendríamos un certificado emitido que está por Cloudflare y si vamos a la parte de analíticas rápidamente veríais que aquí está ya todo el tráfico. Creo que ya se nos ha acabado el tiempo.