Estas semanas en Cloudflare en Español

Hola, buenos días, buenas tardes, buenas noches. Donde quiera que nos estén sintonizando el día de hoy, o estén viendo la retransmisión de este programa, bienvenidos a Estas Semanas en Cloudflare en Español. Mi nombre es Alex Mayorga Adame, soy ingeniero de soporte técnico en Cloudflare. Para los que nos sintonizan por primera vez, bueno, en este programa revisamos un poco de las novedades de producto de Cloudflare, revisamos el blog en Cloudflare, y también revisamos una de las redes sociales de Cloudflare, que es Twitter, en este caso. Bueno, eso es lo que tratamos de revisar. Tenemos formas de comunicarse con nosotros, en la parte baja de la transmisión pueden ver un correo electrónico, así como un número telefónico, en caso de que tengan alguna pregunta, o algún comentario sobre el programa, para que nos lo hagan llegar, por favor. Y si nos da tiempo, trataremos de responder todas las preguntas que recibamos. Bueno, antes que nada, bueno, para todos los que están en Estados Unidos, pues feliz 4 de julio, esta reciente que pasó, y también un gran saludo y todo mi amor a mi esposa, porque estamos celebrando nuestro 15 aniversario. Y comenzamos entonces, con las novedades en Cloudflare, tenemos Cloudflare.com, diagonal a whats, guión a barra new. Y tenemos aquí las últimas novedades que se han anunciado, tenemos un anuncio sobre una API, para el manejo de las rutas estáticas, en la oferta de Magic Transit. Aquí podemos ver que, bueno, esta API, nos permite controlar las rutas de cada uno de los prefijos, o túneles que tenemos registrados en Magic Transit. Así como modificar su prioridad, su alcance regional, y el peso en el balanceo de SMP. Ese es el primer anuncio que tenemos. Después tenemos, bueno, que comenzando el primero de este mes, se ha eliminado el encabezado cf-request-id. Menciona aquí que, bueno, ya se había removido temporalmente, el día 15 de junio, como una prueba. Y bueno, el encabezado al día de hoy, debe estar ya removido completamente. Pero si por alguna razón aún lo están utilizando, bueno, la sugerencia es cambiar a usar el encabezado cf-request-id en su lugar. Y también aquí vemos un enlace donde podemos ver las depreciaciones que se planean en la API de Cloudflare. Después tenemos otra característica, que se está anunciando aquí, que es la disponibilidad general del ruteo por proximidad en la oferta de load balancing de Cloudflare. Como indica aquí, pues, esta característica nos permite indicar la longitud y latitud del centro de datos en donde se encuentran nuestros servidores de origen. Para así poder hacer que Cloudflare enrute a la dirección más cercana geográficamente. Y enviar esas solicitudes a ese punto. Estas son las tres novedades que tenemos. Vamos ahora a seguir revisando el blog de Cloudflare. Este lo pueden encontrar en la dirección de blog.Cloudflare.com. Y vamos a empezar con un blog de nuestra colega Natasha, que nos habla un poco sobre cómo se hace el monitoreo de niveles de servicio en los orígenes de una manera más inteligente. Bueno, este es un anuncio que nos indica Natasha de una nueva forma de detectar cuando se elevan los niveles de errores 500 en los orígenes. Nos comenta aquí, bueno, que hace un par de años ya se había anunciado el monitoreo pasivo de los orígenes. Que esto funcionaba cuando se recibían errores 521 por un total de 5 minutos de un origen. Se envía, en ese caso, una alerta. Pero bueno, aquí nos cuenta que también es importante detectar cuando el nivel de los errores se está aumentando. Entonces nos cuenta aquí cómo se hace el cálculo para detectar las anomalías. Para evitar que se hagan alertas cuando no son necesarias. Vemos aquí un poco, por ejemplo, si se establece un nivel muy elevado y los picos no llegan hasta ahí, pues no se hace el alertamiento correcto. Pero también nos muestra acá que en caso de que ese nivel de alerta sea muy bajo, pues se comenzarían a recibir muchas alertas, lo que podría crear fatiga de las mismas y que las mismas no se detectarían. O sea, accionarían. También nos muestra aquí otro caso de cuando indica lo que ella describe como un problema que es lento y bajo, que sería esta meseta que vemos aquí. Que a pesar de que hay mucho impacto en esta parte, pues como no llega al nivel de la alerta, se mantiene sin alertar y pues eso sería un problema. Entonces, bueno, nos cuenta acá que también se pueden hacer distintos alertamientos, por ejemplo, notificar cuando hay más de 10% de errores, o cuando hay más de 5% por más de 5 minutos, o más de 2% por 10 minutos. Y acá vemos otro caso que podría ser... Tienen relativamente estables y luego hay caídas. Y acá nos cuenta un poco sobre el burn rate. Si utilizamos estos, podemos detectar distintas problemas en los orígenes. Y bueno, en este caso se cubren las problemáticas de recibir un alertamiento rápido cuando algo dramático está ocurriendo. Y también indica acá si se puede hacer que no se haga la alerta si son problemas que se resuelven rápidamente. Entonces vemos aquí, por ejemplo, se comienza a hacer la detección del problema. Después, en la siguiente medición, se observa que el problema continúa. Sería la alerta. Y después vemos aquí cómo después de que cae el pico, pues se continúa monitoreando. Nos muestra acá cómo se puede hacer la configuración de estas alertas. En este caso se va al panel y se pueden establecer aquí los niveles de sensibilidad que tendría el alertamiento e indicar cuáles son los correos electrónicos que deben recibir las alertas. Nos cuenta aquí que esta notificación se encuentra disponible para todos los clientes en el plan Enterprise. Y bueno, los invita a probar la funcionalidad. Asimismo, nos cuenta que su equipo está haciendo contrataciones en las oficinas de Austin, de Lisboa y de Londres, por si tienen interés en unirse al equipo. Seguimos con un blog de nuestra colega Ming, que nos cuenta sobre las reglas de transformación. Vemos aquí un poco sobre las principales funcionalidades que tenemos, que es la normalización de las URLs para que sean estandarizadas. Otra de las funciones es reescribir las URLs en sus paths y en sus query strings. Y otra es la modificación de los encabezados. Para transmitir información específica a las aplicaciones. Bueno, nos cuenta aquí... Bueno, un poco como charla el servidor con Cloudflare, agradeciéndole que le quita ese trabajo. Y bueno, Cloudflare, los servidores de Cloudflare, agradeciéndole. Bueno, un poco la razón por la que estas reglas de transformación son requeridas. Nos cuenta aquí que es uno de los casos de uso principales de Cloudflare Workers. Y bueno, nos dice aquí que Cloudflare Workers ofrece mucha funcionalidad, pero también nos dice que es un poco como meterse con la escafandra completa en la piscina de los niños. Entonces es una herramienta quizá muy poderosa. Entonces es por eso que surgió la idea de ofrecer estas reglas de transformación directamente en la interfaz gráfica en la consola de Cloudflare. Como ya decíamos, bueno, se tiene la opción de normalizar las URLs, de reescribir las URLs y de hacer modificaciones en los encabezados. Nos cuenta aquí un poco el caso de la normalización. La normalización es, bueno, uno intenta hacer una regla de limitación de velocidad en esta URL del login, pero tenemos un atacante que hace un encoding en el pad y bueno, eso le permitiría saltarse la regla. Aplicando la normalización pues se convierte todas las URLs que tengan el pad codificado directamente a la forma base y entonces ya se puede agregar la regla. Vemos por ejemplo aquí el caso de que la configuración tenga normalizar las URLs entrantes, pero no normalizarlas al origen. El usuario pues da esa URL codificada, como se está normalizando, se transforma. Cloudflare aplica en ese caso la regla de Firewall, pero al pasar la URL se la da al origen con la codificación tal como venía. Tenemos aquí también otros casos de uso, que es la reescritura de las URLs. Normalmente, bueno, nos dice aquí Ming que puede ser con PageRules, hacer una redirección ya sea con 301 o 302. Pero bueno, eso cambia la URL que se le despliega al visitante. Y después nos da aquí un caso de la reescritura de una URL de manera estática. Veamos aquí. Se crea la regla, está con un hostname y una cookie y también tiene una URI y al encontrarse estas características se reescribe de manera estática para que vaya al pad de la versión, en este caso. También tenemos otro que es una reescritura dinámica. Como vemos aquí, se cumplen ciertas condiciones que en este caso es ese host y esta cookie y después se hace una reescritura dinámica agregando o concatenando la dirección B1 al pad existente. Otro caso de reescritura dinámica en el que utiliza expresiones regulares. Tenemos aquí la expresión regular para cambiar la parte de global a B1. Y también modificando el queryString en este caso. El último caso de uso es la modificación de los encabezados. En este caso vemos cómo se agrega un encabezado estático con el nombre de foo, con el valor de var en todos los hosts que contengan example.com. Aquí nos muestra un poco cómo luce el encabezado. Bien, vemos que se pueden hacer encabezados dinámicos. Por ejemplo, aquí agregando el número de sistema autónomo de la solicitud. También vemos cómo agrega el continente y un poco la subdivisión geográfica. Vemos aquí el encabezado que nos muestra ya esas características. También si se tiene contratado bot management se puede pasar como un encabezado el score de bots en este caso. Y bueno, vamos a probar las transformaciones, las reglas de transformación directamente en nuestro dashboard de Cloudflare haciendo clic en ese enlace. Seguimos con otro blog de Diksha y Avi que nos cuenta un poco de una colaboración entre Cloudflare y Microsoft, Microsoft en Azure, para reducir el costo con las preferencias de ruteo en la transferencia de datos. Bueno, aquí nos muestra, bueno, nos cuentan un poco que utilizando las preferencias de ruteo en Microsoft se pueden reducir los costos y aumentar el desempeño de las aplicaciones. Nos cuentan un poco aquí sobre la red de Cloudflare y la interconexión que tiene. Nos dicen que Cloudflare está conectado con 9500 redes a nivel global, muchos ISPs, proveedores de nube y distintas empresas. Y también nos cuenta que tiene interconexión con la red de Azure en varias localidades a través de lo que se llama la interconexión de redes privadas. Y vemos aquí un poco el mapa en donde estas interconexiones están. Entonces aquí qué nos dice en Chicago, en San José, California, en Ashburn, Virginia, así como en Londres, Amsterdam y Frankfurt y en Sydney. Vemos ahí en el mapa marcadas estas ubicaciones. Y vemos aquí un poco cuál sería la ruta que tomaría una solicitud de un cliente. Se conecta a su ISP local y de ahí a la red de Cloudflare. Y después la red de Cloudflare transmite esto al punto o centro de datos más cercano al origen de Azure en la red de Microsoft. Y después se devuelve esto al cliente. Y bueno, nos cuenta un poco aquí la necesidad de tener esto es para reducir el bloqueo de vendedores y facilitar la interconectividad. Y aquí tenemos una referencia del director de Azure. Y aquí nos dice cómo hacer la configuración. En este caso, en nuestras preferencias del dashboard de Azure se cambiaría a utilizar Internet routing. Y también hacer lo mismo en la parte de Firewall y redes virtuales. Seleccionar Internet routing. Esto, bueno, actualizaría los endpoints en Azure y estos serían los que se tienen que reemplazar en el panel de Cloudflare. Y después vemos aquí ya un poco de las referencias de algunos clientes que, bueno, les ha permitido hacer esta transición de forma sencilla, sin mucho esfuerzo. Y también cuentan cómo obtienen descuentos en su egreso, en este caso, en su factura de Azure. Y también, bueno, el descuento que sea. Y nos deja aquí un enlace en el caso de que quieran participar en este programa, para que lo visiten y puedan saber más. Yendo con el blog, tenemos un blog de Arwa, Jessica y Jade. Nuestros colegas que nos cuentan un poco sobre lo que ocurrió en el mes de la diversidad de nuestros colegas hacia Pacífico. Nos cuenta que durante el mes de mayo se celebra esto. Nos cuenta aquí que en este mes hubo una colaboración entre Azientflare y Deciflare, que son dos recursos de empleados aquí en Cloudflare. Y nos cuenta, bueno, un poco un listado de todas las participaciones que se tuvieron en Cloudflare, aquí en Cloudflare TV. Sobre la experiencia de los americanos asiáticos. Vemos aquí las recetas. Sobre la juventud de estos casos. Algunos paneles de discusión que hubo ahí. Tenemos a algunos invitados que vinieron a Cloudflare TV durante este evento. Otros de los paneles de discusión que se presentaron ahí. Sobre las minorías, sobre las políticas de un solo hijo en la parte del Partido Comunista. También varios fundadores de startups o compañías que vinieron a hablar sobre Cloudflare TV. Tenemos ahí a Huynh Hoang que es fundador de Quadrant Eye. También X. Yang, cofundador de Sourcegraph. Y varios otros, ahí tenemos los enlaces por si quieren visitar los distintos streamings o las grabaciones en este caso. Y también varios fireside chats que se tuvieron. Durante este mes. Tanto personal de Cloudflare como invitados de otras organizaciones. Ahí Broadcom por ejemplo. Yo de Arte de Cleveland. Así como varios colegas de Cloudflare. Tenemos ahí Oli, Mojit, Roy y Andrew que también estuvieron en estos fireside chats. Programas de entrevistas, como ya decíamos, de cocina, un poco el de caminar una milla en los zapatos de otro, donde varios colegas cuentan sus historias familiares sobre sus mascotas, su educación, etcétera. Vidas de vida. Y después nos cuenta un poco cómo comenzó en este caso el grupo de ASEAN Flare. Nos cuenta Jade que estaba platicando con nuestro colega Stanley el año pasado. Alrededor de marzo. Y bueno, nos cuenta que tristemente hubo un ataque a una familia en Texas. Entonces eso comenzó una conversación y después básicamente el grupo siguió reuniéndose para apoyo en este caso y un poco para intentar hacer un cambio positivo al respecto. Y bueno, nos cuenta aquí que por ejemplo, estuvieron viendo con preocupación cuando existía la posibilidad de que el baneo de aplicaciones como WeChat y TikTok y como platicaron con nuestra colega Lisa sobre la política y lo que creían que sucedería. Y un poco, bueno, cuando ocurrieron los incidentes en marzo pasado también el apoyo que se recibieron de nuestro equipo de personal, así como de nuestro CEO para poder conversar sobre el tema. Tenemos el otro grupo de recursos que es DeciFlare. Nos cuenta aquí que este comenzó en la oficina de San Francisco alrededor del 2019 un poco para aprender un poco más de la cultura del sur de Asia. Y bueno, durante una celebración de Diwali, que es el festival de las luces, se hizo una reunión ahí y obviamente congregaron a 25 personas y comida conmemorativa. Y después, a partir de ahí, pues empezó a tener representación en distintas oficinas, como vemos, San Francisco, Austin, Nueva York, Londres y Singapur. Y bueno, el objetivo de la organización básicamente es de pertenencia y comunidad a todos aquellos empleados de Cloudflare que tengan un interés en las culturas del sur de Asia. Y un poco de unir a las personas que tienen ese interés o pertenecen a esta comunidad. Y tenemos que, bueno, como en el caso de todos los grupos de recursos, está disponible para cualquiera que quiera y desee participar o conocer un poco más sobre la cultura. Viendo con el blog, tenemos un blog de Michael que nos cuenta sobre la disponibilidad de la protección de cuentas en el WAF. Nos cuenta aquí que hubo un reporte donde se dio a conocer que estos ataques estaban ocurriendo, básicamente de fuerza bruta para obtener acceso, después se hacen movimientos laterales en la red, y así como el despliegue de ejecuciones remotas, en este caso el REEL. Aquí que, bueno, esta funcionalidad se había lanzado como beta en marzo. Y nos lista aquí un poco de las aplicaciones que se pueden proteger directamente al utilizar. WordPress, Joomla, Drupal, Magento, y Microsoft Exchange. Aquí nos da un enlace a las herramientas para desarrolladores. Nos detalla aquí un poco las reglas que fueron actualizadas. Y nos cuenta sobre mitigaciones adicionales que podemos aplicar para este tipo de situaciones, como puede ser utilizar access, datos mútuos de TLS, en este caso, que se pueden configurar en Google Rules. Y también podemos utilizar las reglas administradas de abiertos que tiene Cloudflare, así como las soluciones de Bot Management y Superbot 5.0. Y bueno, nos cuenta que, obviamente, Cloudflare está siempre para proteger a nuestros usuarios. A ver si tenemos alguna pregunta. Vamos a cerrar revisando un poco la red social de Twitter. Vemos aquí el tweet correspondiente al blog post de Azure, que ya veíamos. Tenemos un poco aquí una revista de tecnología que tiene algunos artículos de Cloudflare. Tenemos el monitoreo y las reglas de transformación que ya veíamos. El tweet correspondiente a Asia Pacífico. Tenemos acá un webinar que hubo sobre la contención de attacks de bots. Y también vemos la parte del blog de Michael sobre la protección de toma de cuentas. Vemos otro tweet sobre la parte del control de caché de CDN que ya revisábamos en una emisión anterior. Y, bueno, un poco sobre cómo Cloudflare puede ayudar a proteger contra ciberataques y problemas en el servicio. Tenemos las sesiones que hubo recientemente de Cloudflare Connect, que también nos pueden encontrar disponibles ahí. Diagonal Connect. Un tweet sobre el reciente aniversario de Cloudflare TV. Un gran y felicitarlos nuevamente por su primer aniversario. Esperemos sean muchos más. Tenemos una conversación que se tuvo ahí con Macrometa y 451 Research. Y aplicaciones distribuidas en la red de borde de Cloudflare. Les agradecerles que se hayan sintonizado.