Bienvenido a tu nueva red segura

Tarea

Examinar el lab y cómo está configurado

Por qué

En este taller, empezaremos con un entorno de lab parcialmente configurado. Hemos creado dos máquinas virtuales. Una representa el servidor de aplicaciones y tiene algunos contenedores docker en ejecución, además de un Cloudflare Tunnel que ya conecta este servidor a nuestra red. La segunda máquina es un escritorio Windows y no tiene nada configurado salvo nuestro device agent instalado y listo para que inicies sesión. Este escritorio simula a un usuario remoto trabajando fuera de la oficina.

También hemos configurado un IdP basado en SAML que tiene un usuario que usaremos durante el taller. Ese usuario es alice@company.com y la contraseña es Savetheinternet!1

Pasos

Vamos a ver cómo está configurada la cuenta de Cloudflare y nuestro lab. Abre el dashboard de Cloudflare yendo a labs.cloudflare.com, seleccionando tu lab y haciendo clic en el enlace "Open CF Dashboard" en la barra de navegación superior.

• Ve a Networking > Tunnels
  • Puedes ver que tenemos un tunnel configurado hacia el servidor de aplicaciones. Haz clic en el nombre del tunnel Application Server.
  • Ve a la pestaña Routes. Aquí aparecen tanto las rutas publicadas (Published) como las de CIDR en un mismo listado, sin necesidad de cambiar de pestaña. Verás que tenemos la intranet en tu dominio apuntando a un contenedor docker que se ejecuta en el servidor y escucha en el puerto HTTP 8000, y que también hemos expuesto la dirección IP del servidor local mediante una ruta CIDR.
• Ve a Zero Trust > Traffic Controls > Resolver Policies, haz clic y edita "Application Network"
  • Estamos usando nuestro propio servicio de DNS interno, de forma que cualquier solicitud DNS para el dominio company.internal desde una red o dispositivo conectado a Cloudflare pueda resolverse con tu propio dominio interno alojado en Cloudflare.
  • Ve a la sección Then (o Resolver) y busca la opción Use Internal DNS para resolver las consultas DNS internas. Las DNS views determinan cómo se gestionan las consultas DNS dentro de las redes internas. Haz clic en el enlace Manage DNS views, que abrirá una nueva pestaña del navegador
  • Selecciona la pestaña Internal zones y haz clic en la zona company.internal.
  • Aquí puedes ver que solo tenemos un registro A que apunta a la misma dirección IP de nuestro servidor de aplicaciones.
• Ahora veamos cómo gestionamos el acceso a la intranet. Cierra la pestaña y vuelve a Access controls > Policies.
  • Aquí tenemos políticas centralizadas que podemos usar en muchas aplicaciones y otras áreas. Haz clic en la pestaña Rule groups, selecciona y configura el rule group Employees.
  • Un rule group es un elemento pequeño que se puede usar en muchas políticas. Este define qué es un empleado e incluye a cualquiera que forme parte del grupo all-employees del IdP SAML.
  • Vuelve a la sección Policies y en la pestaña Reusable policies, selecciona View more para la política Employees,
    • Baja hasta Policy details y verás que el rule group Employees está en esta política.
    • Sube un poco y verás en la sección Applications dónde se está usando esta política. No solo para la intranet, sino también para determinar quién puede registrar dispositivos (Warp Login App) y quién puede iniciar sesión en la interfaz web para acceder a todas sus apps. (https://grateful-terminal.cloudflareaccess.com)
    • Haz clic en el botón Configure en la parte superior,
  • La combinación de rule groups y policies permite una combinación muy potente de elementos simples, como un rule group que se combina en políticas complejas con muchos rule groups y otros atributos.
    • Haz clic en Add include y abre el desplegable Selector. Recorre las diferentes formas en que podemos definir una política. Puedes leer más sobre los distintos tipos de selector aquí.
• Ahora vuelve a Access controls > Applications, selecciona y configura la aplicación Intranet.
  • Esto define la política de acceso para el sitio de la intranet expuesto a través del tunnel.
  • Selecciona la pestaña Policies y podemos ver que, para esta aplicación, se aplica la política Employees. Ahora sabemos que todos los usuarios autenticados que son miembros del grupo all-employees en el IdP tienen acceso a la intranet de la empresa.
  • Cambia a la pestaña Login methods. Ten en cuenta que el acceso a esta aplicación es válido tanto desde el IdP como usando un One Time Pin por email. Exploraremos esto más adelante en el taller.
• En las políticas que crearemos más adelante, usaremos atributos del dispositivo conectado además del usuario autenticado. Veamos dónde se configuran, navega a Zero Trust > Reusable components > Posture checks.
  • Aquí podemos ver los checks de Warp y Gateway. Se usan para comprobar si el tráfico hacia una aplicación o hacia Internet en general viene a través de Cloudflare. Warp comprueba específicamente si ese tráfico proviene de un dispositivo con nuestro agent, en lugar de simplemente tráfico conectado a Cloudflare a través de una conexión de red. Ten en cuenta que muchos de estos posture checks requieren que el device agent esté instalado, ya que es lo que informa a Cloudflare sobre el estado del dispositivo.
  • Como el check Windows firewall enabled, que informa si el firewall de software local está activo en el dispositivo.
  • Haz clic en el check Latest version of Windows, aquí podemos ver un check que podemos usar en una regla que requiere que el dispositivo conectado tenga una versión 10 o superior.
• Ahora examinemos los controles de acceso para Internet en general. Ve a Traffic Controls > Firewall policies > DNS
  • Aquí puedes ver que solo tenemos una política sencilla, Block DNS requests to high risk and inappropriate sites. Haz clic y edita la política
  • Revisa las categorías que se van a bloquear. Puedes ver que usa categorías predefinidas, gestionadas por Cloudflare, para asegurar que los usuarios en la red no puedan visitar sitios web peligrosos o inapropiados.
  • Activa también la opción Display block notification for Cloudflare One Client, para que el usuario reciba un aviso en el device agent cuando se bloquee una solicitud.
  • Si quieres modificar el mensaje que ven los usuarios al ser bloqueados, aquí mismo tienes la opción de personalizarlo, incluyendo la custom block page, a la que se accede desde esta misma regla y también navegando a Reusable components > Custom pages > Account Gateway block page. Allí puedes editar tu Custom Gateway block page.
  • Vuelve a Firewall policies y cambia a la pestaña HTTP. Aquí tenemos una regla HTTP coincidente, pero también una regla de isolation que permite el acceso a sitios de redes sociales, pero los ejecuta en nuestro servicio de navegador aislado. Aquí, en lugar de que el sitio de redes sociales se cargue y renderice directamente en el navegador local, ejecutamos un navegador headless en la red de Cloudflare y el sitio se carga ahí, enviando los resultados al navegador del usuario. Esto garantiza que cualquier código malicioso que se ejecute en el navegador solo afecte a una instancia de navegador aislada y segura.
  • A diferencia de las políticas DNS, las políticas HTTP nos permiten inspeccionar el contenido de la solicitud. Por eso, también podemos aprovechar nuestros perfiles DLP para detectar y filtrar ciertos tipos de datos que van hacia y desde aplicaciones web.
    • Navega a Data loss prevention > Profiles. Haz clic y edita AI Prompt: PII.
    • Tenemos perfiles DLP predefinidos, y por ejemplo este coincide con cualquier prompt a un agente de IA que contenga información de identificación personal (PII).

Ahora que hemos visto cómo está configurada esta cuenta de Cloudflare, conectemos el dispositivo de un usuario remoto y comprobemos cómo esta configuración habilita e impacta su acceso.

🛠️ Solución de problemas

• No veo ningún tunnel en Networking > Tunnels. Confirma que estás en el dashboard de tu cuenta del lab (accedido vía "Open CF Dashboard") y no en otra cuenta de Cloudflare que puedas tener abierta en otra pestaña.
• La pestaña Routes del tunnel aparece vacía. Espera unos segundos y recarga; a veces la carga inicial del tunnel tarda un poco tras entrar por primera vez al dashboard del lab.
• No encuentro la opción "Use Internal DNS" en la política de Resolver. Asegúrate de estar editando la política ya existente "Application Network" y no creando una nueva desde cero; la opción aparece en la sección Then al configurar una regla de tipo Resolver.
• El enlace "Manage DNS views" no abre nada o da error. Comprueba que no tengas un bloqueador de ventanas emergentes activo en el navegador, ya que este enlace abre una pestaña nueva.
• No veo el rule group "Employees" al configurarlo. Ve a Access controls > Policies > pestaña Rule groups; si no aparece, confirma que sigues en la cuenta correcta del lab.
• La categoría de bloqueo DNS no incluye el sitio que estoy probando (por ejemplo poker.com). Las categorías de Cloudflare se actualizan periódicamente; si un dominio de prueba concreto no está categorizado como esperado, prueba con otro sitio de la misma temática o continúa con el resto del taller, ya que el objetivo es entender el mecanismo, no una lista exhaustiva de dominios.