Más allá de Tunnel y Access, qué piezas de Cloudflare Zero Trust me quedan por activar

La serie de migración del VPS detrás de Cloudflare cerró con Tunnel y Access para sacar los paneles admin de Internet. Pero la suite de Cloudflare Zero Trust y Cloudflare One es bastante más amplia que eso, y hay piezas que en plan Free (o muy barato) merecen un hueco en cualquier setup pequeño que se quiera tomar la seguridad medio en serio.

Este post no es un tutorial sino un inventario con criterio. Para cada servicio cuento qué hace, qué problema resuelve, qué te dan realmente en Free y si lo activaría hoy en mi VPS, lo dejaría para más adelante o lo descartaría. Una persona, un VPS, un puñado de apps, ese es el contexto del que hablo. Para una empresa con 200 desarrolladores las prioridades cambian.

Gateway DNS, filtrado en el resolver

El más fácil y posiblemente el más infravalorado. Cloudflare Gateway permite configurar políticas de DNS, bloquear categorías enteras (malware, phishing, contenido para adultos, criptomineros, dynamic DNS) o dominios concretos, y aplicarlas a cualquier dispositivo o servidor que use sus resolvers.

El uso clásico es proteger los endpoints de los empleados con WARP, pero hay otro caso muy interesante para un VPS, apuntar el /etc/resolv.conf del propio servidor a los resolvers de Gateway. Cualquier resolución DNS que haga el VPS (descargar una imagen Docker, instalar un paquete, una llamada saliente de una app a un dominio comprometido) pasa por las políticas. Si una dependencia de NPM se compromete y hace un fetch a un dominio de filtrado de credenciales conocido, Gateway lo corta antes de la petición.

Free admite hasta 50 usuarios y suficientes políticas DNS para un homelab. La trampa de la UX es que en plan Free tienes una ubicación de Gateway, así que no puedes diferenciar políticas por VPS si tuvieras varios, todos comparten la misma. Para mi caso es irrelevante porque todos mis servidores son en la práctica el mismo perfil.

¿Lo activaría? Sí, primero de la lista. Es trivial, gratis y reduce la superficie de ataque de cadena de suministro de forma medible.

Service Tokens, el huequito para automatizaciones

Cloudflare Access es perfecto cuando soy yo quien entra al panel. Pero qué pasa con un GitHub Action que tiene que llamar a un endpoint detrás de Access, un script local que consulta el estado de algo o un cron remoto. Pedirle OTP a un job de CI no tiene sentido.

La pieza para esto son los Service Tokens. Son pares CF-Access-Client-Id y CF-Access-Client-Secret que se generan en el dashboard de Zero Trust y se incluyen como cabeceras en la petición. La política de la Application tiene que aceptar ese token explícitamente con un selector Service Auth > Service Token.

El patrón mental es el mismo que el de un API key dedicado, pero con dos diferencias importantes. Primero, el token vive en CF, así que se puede revocar instantáneamente desde el dashboard sin tocar el origen. Segundo, los tokens son auditables, los logs de Access te dicen qué token entró por qué path y cuándo. Eso convierte un secreto opaco en un actor con identidad.

Limitaciones del plan Free, los tokens funcionan, pero la cadencia de rotación recomendada (90 días) hay que gestionarla a mano, no hay rotación automática. En la práctica para CI lo aceptable es generar el token, meterlo en GitHub Secrets, y rotarlo cuando hay un evento que lo pida.

¿Lo activaría? Sí, en cuanto un proyecto tenga un workflow de GitHub Actions que necesite hablar con un endpoint protegido por Access. Hoy mis deploys van por webhooks de GitHub al endpoint bypass que ya documenté en el post anterior, así que aún no lo necesito, pero lo siguiente que tendría que llamar a un panel admin desde un job lo haría con Service Token, no abriendo más bypass.

Turnstile, el reemplazo decente de CAPTCHA

Cualquier formulario público que reciba alta de usuarios, suscripciones a newsletter, contacto o submissions de cualquier tipo, acaba teniendo bots. Llevo años huyendo de reCAPTCHA por dos motivos, la dependencia con Google (con el coste reputacional y de privacidad que eso supone) y porque el v3 silencioso castiga a los usuarios que se cuidan (Tor, navegadores con privacy hardening) sin que el sitio sepa por qué pierde altas legítimas.

Turnstile es la respuesta de Cloudflare a eso, un widget que en la mayoría de los casos no muestra reto al usuario, hace análisis pasivo del navegador (signals típicos) y emite un token que el backend valida llamando a la API de CF. Si el análisis es ambiguo, sale un challenge no invasivo en lugar del clásico semáforo de imágenes.

El plan Free admite 1 millón de validaciones al mes. Para un blog y formularios de tamaño normal eso es prácticamente ilimitado.

El integrador es trivial. En el frontend, el script https://challenges.cloudflare.com/turnstile/v0/api.js y un <div class="cf-turnstile" data-sitekey="...">. En el backend, antes de procesar el form, una llamada POST a https://challenges.cloudflare.com/turnstile/v0/siteverify con el token del cliente y la secret key. Si la respuesta es success: true, sigues. Si no, devuelves 400.

¿Lo activaría? Sí, en cualquier formulario público nuevo. De hecho, ya lo uso en algunos proyectos como TimeCapsule, ScamDetector, y el CV. Para los existentes (suscripción a la newsletter del blog, alta de comentarios) lo metería en cuanto vea picos de spam.

mTLS en Access, segundo factor de verdad para paneles críticos

OTP por email es suficiente para la mayoría de paneles personales, pero para los que pueden hacer mucho daño (orquestador, gestor de secretos) el inicio de sesión idealmente debería exigir algo que tengas además de algo que sepas. La opción que ofrece Access en este sentido es mTLS, la Application requiere un certificado cliente firmado por una CA que tú controles, y solo dispositivos con ese certificado instalado pueden siquiera ver el formulario de OTP.

El flujo es, generas una CA tú mismo (o usas una existente), la subes a CF como Mutual TLS Authentication en la zona, generas certificados de cliente para cada dispositivo desde el que vas a entrar (portátil, móvil) y los importas en el almacén del sistema. La política de la Application añade require > valid certificate. Sin certificado, ni siquiera ves el login.

El flujo de uso normal es transparente, la primera vez el navegador pide elegir certificado y ya. La parte molesta es la operativa, importar el cert en macOS, en iOS, en Linux, en Android, cada plataforma tiene sus rollos. Y rotar la CA cuando expira (las CA suelen ser de 5-10 años) es un evento que hay que planificar.

Disponible en plan Free, sin coste extra.

¿Lo activaría? Sí, pero solo en Dokploy y posiblemente Infisical. Para Umami u otros paneles de bajo daño no lo justifica el coste operacional. Para el orquestador, sí. La idea es que ni siquiera un atacante con OTP por email comprometido pueda ver el login.

WARP Connector, redes privadas para servicios que no son HTTP

Tunnel y Access funcionan con HTTP/HTTPS. ¿Y si quiero acceder a SSH del VPS, a un Postgres no expuesto, al puerto de un servicio interno como un Redis Insight o un PgAdmin que solo escucha en la red Docker? Una opción es exponerlos por HTTPS detrás de algún proxy, pero hay otra mejor.

WARP es el cliente VPN de Cloudflare. WARP Connector es el componente del lado del servidor que conecta una red entera (la del VPS, una LAN, un cluster) al edge de Cloudflare como una red privada. Combinado con WARP en el cliente, se forma un túnel cifrado donde tu portátil puede llegar a cualquier IP de esa red privada como si estuvieras dentro.

El caso de uso ideal es el de SSH al VPS, dejar el puerto 22 cerrado a Internet, instalar WARP en el cliente, conectar al equipo de Zero Trust, y SSH funciona contra una IP privada que solo se ve dentro del túnel. La identidad para entrar a WARP es la misma que la de Access, así que no hay que mantener dos sistemas de auth.

Free incluye WARP con uso ilimitado para hasta 50 usuarios. La pega para un setup tipo Dokploy es que crear el Connector dentro del orquestador hay que pensarlo bien, los pods cloudflared de Tunnel y los de WARP Connector son contenedores diferentes y conviene aislarlos.

¿Lo activaría? Sí, en orden de prioridad medio. SSH al VPS hoy va por puerto 22 con clave (sin password, con fail2ban / CrowdSec) y la verdad es que funciona bien. Cerrarlo del todo y meterlo detrás de WARP sería más limpio y eliminaría toda la categoría de scanners de SSH del log, pero no es urgente. Lo activaría como tarea de un fin de semana.

Page Shield, vigilar los scripts de terceros del navegador

Si un script externo de tu sitio se compromete (Magecart-style, supply chain de un CDN), tus visitantes se llevan el regalo. Page Shield es la pieza de Cloudflare que monitoriza qué scripts JavaScript se cargan en tus páginas, su integridad y su comportamiento, y te alerta si aparece uno nuevo o si uno conocido cambia.

La parte gratuita expone el monitor básico, te da el inventario de scripts cargados en tus páginas (lo que ven los visitantes reales) y un changelog. Las acciones avanzadas (alertas activas, content security policy gestionada por CF, blocking) requieren plan Pro o Business.

En mi blog uso muy pocos scripts externos (Tiptap es propio, Umami es self-hosted, no tengo Google Tag Manager ni reCAPTCHA), así que el inventario debería ser muy corto. Si un día aparece un script que yo no metí, salta la alerta. Es una de esas piezas que vale más por lo que detecta que por lo que hace activamente.

¿Lo activaría? Sí, el monitor base. No me cuesta nada y la primera vez que veo el inventario me confirma que el sitio está limpio. Si algún día tengo que pagar Pro por otra razón, miraría las acciones activas (alertas, CSP) seriamente.

Cloudflare Notifications, las alertas que muchos no activan

Esta es la más simple y la más olvidada. CF tiene un panel de Notifications donde se pueden configurar alertas a email o webhook por eventos del propio CF, ataques DDoS, alta latencia del origen, fallos de validación de certificados, expiración inminente, problemas con el Universal SSL, errores 5xx anormales, fluctuaciones grandes en el tráfico.

Es gratis. La curva de adopción es absurdamente baja, abrir el panel y elegir lo que quieres recibir. Y resuelve un agujero típico, enterarte de que tu certificado caducó porque un usuario te lo dijo es una experiencia que se previene con dos clics.

¿Lo activaría? Sí, ya. De hecho, este es el primero que voy a hacer cuando termine este post.

Lo que estoy mirando pero aún no me convence

Browser Isolation

Concepto interesante, ejecutar el navegador en un sandbox remoto y enviarte solo el render. Para abrir links de phishing reportados o adjuntos de email sospechosos sin riesgo. Pero está fuera del plan Free (incluido en Cloudflare One Premium) y para mi perfil no compensa, ya filtro a nivel DNS y abro raro lo dudoso desde una VM.

Zaraz

Tag manager con server-side execution. Útil si dependes de muchos pixels y scripts externos para analytics y marketing. Yo no, así que no le saco partido.

Email Routing y Email Security

Email Routing ya lo uso, gratis y muy bien. Email Security (la suite ex-Area1, antiphishing y filtrado avanzado) es de pago y para uso personal con un dominio donde recibo apenas 10 correos al día, no compensa. Para una empresa pequeña sí.

Logpush

Push de logs de CF a un destino externo (S3, R2, BigQuery...). Útil para análisis forense y SIEM. Solo en Enterprise.

Plan de adopción si tuviera que ordenar todo esto

Si tuviera que poner orden por relación valor-esfuerzo, mi lista sería esta.

1. Cloudflare Notifications, 5 minutos de setup, valor enorme.

2. Gateway DNS en el VPS, una hora, blinda saliente del propio servidor.

3. Page Shield monitor, dos clics, inventario gratis.

4. Turnstile en cualquier formulario público nuevo, una tarde si lo metes en algo existente.

5. mTLS en Access para Dokploy, un fin de semana de operativa (CA, certs, importes, prueba en cada dispositivo).

6. Service Tokens, cuando aparezca el primer caso de CI a endpoint protegido.

7. WARP Connector para SSH y servicios no-HTTP, un fin de semana.

El patrón aquí es el mismo que para el resto de la serie. Cada pieza tiene un coste de configuración y de carga mental, y se activa cuando el beneficio es real, no cuando "queda bonito". Cloudflare Zero Trust y Cloudflare One ofrecen mucho más de lo que cabe en un plan Free, pero el plan Free cubre asombrosamente bien un homelab de una persona si se eligen las piezas con criterio.

Lo que sigue

Por orden, lo siguiente que voy a tocar son las Notifications y Gateway DNS, son las dos más rápidas y las que más reducen la categoría de fallos por sorpresa. Cuando alguno de los demás pase de "miraría" a "hago", probablemente le caiga su propio post con el setup real, igual que pasó con la serie de migración. Pero esto es ya fuera del arco principal de "meter el VPS detrás de Cloudflare", que cierro oficialmente con el post anterior de Tunnel y Access.