Cómo proteger WordPress, cPanel y paneles internos con Cloudflare Zero Trust Access

La página de inicio de sesión de WordPress, cPanel, WHM, la interfaz del router y los paneles internos no tienen por qué estar abiertos a todo internet. Con Cloudflare Access, que forma parte de la plataforma Zero Trust de Cloudflare (Cloudflare One), quien visite esas páginas debe identificarse primero en Cloudflare con una identidad que usted aprueba, como una cuenta corporativa de Microsoft o Google, antes de que la petición llegue a su servidor. Cloudflare presenta su plan Zero Trust Free para equipos de menos de 50 usuarios. La configuración tiene cuatro partes: agregar la aplicación, conectar un proveedor de identidad, escribir una política estricta y asegurarse de que nadie pueda llegar al servidor directamente, rodeando Cloudflare. La mayoría de las configuraciones fallidas olvidan esa última parte.

Por qué poner los paneles de administración detrás de Access

Las páginas de administración son un blanco favorito porque una sola contraseña robada le da al atacante el control de todo el sitio o del servidor. Problemas típicos que vemos:

• wp-login.php y /wp-admin recibiendo intentos automáticos de adivinar contraseñas a toda hora.
• cPanel (puerto 2083) y WHM (puerto 2087) expuestos a cualquier dirección IP de internet.
• Herramientas internas como un NAS, una consola de copias de seguridad o un panel de monitoreo publicados "temporalmente" hace años.

Access coloca una verificación de identidad delante de todos ellos. Los atacantes no llegan siquiera al formulario de inicio de sesión de la aplicación, y usted tiene un solo lugar para dar y quitar accesos. No reemplaza las buenas contraseñas ni la autenticación multifactor dentro de cada aplicación. Agrega una segunda puerta.

Paso 1: Conecte un proveedor de identidad

En el panel de Cloudflare, abra Zero Trust > Integrations > Identity providers y agregue el proveedor que su equipo ya usa:

• Microsoft Entra ID si trabaja con Microsoft 365. Así podrá usar grupos de Entra en las políticas.
• Google Workspace si su correo está en Google. La integración de Workspace de Cloudflare puede leer la pertenencia a grupos, cosa que el inicio de sesión genérico de Google no hace.
• One-time PIN, el método integrado de Cloudflare, que envía por correo un código de un solo uso a una dirección permitida. Funciona sin proveedor de identidad y es útil para contratistas externos.

Puede activar varios proveedores a la vez, por ejemplo Entra ID para el personal y one-time PIN para un desarrollador web.

Dos detalles del one-time PIN según la documentación de Cloudflare: el código vence 10 minutos después de solicitarlo, y las herramientas de seguridad de correo que abren enlaces automáticamente pueden consumir el PIN antes que la persona. Si eso ocurre, pida a su administrador de correo que excluya los correos de inicio de sesión de Cloudflare del análisis de enlaces.

Paso 2: Agregue una aplicación autoalojada

Vaya a Zero Trust > Access controls > Applications > Create new application, elija la opción autoalojada (self-hosted) y agregue el nombre de host público que desea proteger.

Ejemplos reales:

Qué proteger	Nombre de host y ruta	Notas
Administración de WordPress	example.com/wp-admin y example.com/wp-login.php	Pruebe las funciones públicas que llaman a /wp-admin/admin-ajax.php
cPanel / WHM	Un nombre de host dedicado, como cpanel.example.com	Cloudflare pasa por proxy HTTPS en los puertos 2083 y 2087
Panel interno	dashboard.example.com	Buen candidato para Cloudflare Tunnel

El dominio debe ser una zona activa en su cuenta de Cloudflare. Cloudflare advierte que, mientras no exista una aplicación de Access para un nombre de host publicado, ese nombre queda abierto a cualquiera en internet, así que cree la aplicación de Access antes de publicar la ruta.

En la misma pantalla se eligen los métodos de inicio de sesión (los proveedores del Paso 1) y la duración de la sesión, que define cada cuánto los usuarios deben identificarse de nuevo. Para herramientas de administración, una jornada laboral o menos es razonable. Un mes no lo es.

Paso 3: Escriba políticas que de verdad restrinjan el acceso

Access niega por defecto: si ninguna política Allow coincide, el usuario queda bloqueado. Las políticas se arman con tres tipos de reglas:

• Include funciona como O. Al menos una debe coincidir. Toda política necesita una.
• Require funciona como Y. Todas las reglas Require deben cumplirse.
• Exclude funciona como NO. Quien coincida queda denegado.

Una política sólida para la administración de WordPress o cPanel se ve así:

1. Acción: Allow.
2. Include: Emails, con las personas concretas que administran el sitio (no "Emails ending in @suempresa.com" para un panel de servidor).
3. Require: Authentication method con MFA, si su proveedor de identidad lo informa. Cloudflare lo verifica al iniciar sesión.
4. Require: Country en Estados Unidos, si todos sus administradores trabajan desde aquí. Cloudflare determina el país por la dirección IP, así que una VPN puede cambiar el resultado.

Para herramientas internas más amplias, un grupo del proveedor de identidad (por ejemplo, un grupo de Entra ID llamado "Personal de oficina") es más fácil de mantener que una lista de correos. Cuando alguien se va, sacarlo del grupo le quita el acceso, lo que encaja con su lista de verificación de salida de empleados.

Cuidado con Bypass

La acción Bypass desactiva Access para las peticiones que coinciden. La documentación de Cloudflare indica que esas peticiones no se registran, que Bypass no admite reglas de identidad y que Cloudflare no recomienda usar Bypass para dar acceso permanente a aplicaciones internas. Úselo solo en casos concretos y probados, como una URL pública de verificación de estado. No lo use como atajo para que "la IP de la oficina entre sin iniciar sesión".

Paso 4: Service tokens para la automatización

Los scripts, los monitores de disponibilidad y las tareas de copia de seguridad no pueden escribir una contraseña ni un PIN. Para ellos, cree un service token en Zero Trust > Access controls > Service credentials > Service Tokens. Cloudflare emite un Client ID y un Client Secret, que el script envía en los encabezados CF-Access-Client-Id y CF-Access-Client-Secret.

Tenga en cuenta:

• La política que acepta el token debe usar la acción Service Auth. De lo contrario, Access envía la petición a una página de inicio de sesión.
• El Client Secret se muestra una sola vez. Guárdelo de inmediato en su gestor de contraseñas o bóveda de secretos.
• Los tokens tienen una fecha de vencimiento que usted elige. Anote la renovación en el calendario y use un token por sistema para poder revocar uno solo.

La trampa del acceso directo: su origen sigue siendo accesible

Esta es la parte más importante. Access protege el tráfico que pasa por Cloudflare. Si se conoce la dirección IP de su servidor, por registros DNS antiguos, por un registro de correo en el mismo servidor o simplemente por escaneo, un atacante puede conectarse directamente a https://<ip-del-servidor>/wp-login.php o al puerto 2083 sin pasar nunca por Access.

Cierre esa brecha con una o varias de estas medidas:

• Cloudflare Tunnel. El servidor abre una conexión solo de salida hacia Cloudflare y usted cierra los puertos de entrada web y de los paneles. Con Protect with Access activado en la configuración del túnel, cloudflared también verifica el token de Access. Es la opción más limpia para paneles internos.
• Lista de permitidos en el firewall. Permita los puertos 80, 443, 2083 y 2087 solo desde los rangos de IP publicados por Cloudflare (cloudflare.com/ips) y desde las IP fijas de confianza. Aplican los fundamentos de endurecimiento de servidores Linux.
• Valide el token de Access en el origen. Access agrega un token firmado en el encabezado Cf-Access-Jwt-Assertion. Cloudflare recomienda que su aplicación lo valide con la clave pública de Access para distinguir las peticiones que realmente pasaron por Access.

Después pruebe desde afuera: intente entrar por la IP del servidor desde un teléfono con datos móviles. Si todavía llega a una página de inicio de sesión, el trabajo no está terminado.

Lista de verificación rápida

• Proveedor de identidad conectado (Entra ID o Google Workspace), con one-time PIN solo donde haga falta.
• Aplicación de Access creada antes de publicar el nombre de host.
• Política Allow limitada a administradores con nombre propio, con requisitos de MFA y país donde correspondan.
• Duración de sesión de una jornada laboral o menos para herramientas de administración.
• Sin políticas Bypass amplias.
• Service tokens para la automatización, guardados con seguridad y con su vencimiento controlado.
• Origen protegido con Tunnel, una lista de permitidos en el firewall o validación del token, y probado directamente.

Nuestros equipos de ciberseguridad y soporte de TI administrado configuran Cloudflare Access para empresas como proveedor de TI independiente. Cloudflare no nos respalda; configuramos sus herramientas para nuestros clientes. Si sus paneles de administración siguen abiertos a internet, solicite una evaluación de TI gratuita. Trabajamos con empresas en todo Miami-Dade y el sur de la Florida, en español e inglés.

Fuentes

• Add a self-hosted public application (Cloudflare Docs)
• Access policies (Cloudflare Docs)
• Identity providers (Cloudflare Docs)
• Google Workspace identity provider (Cloudflare Docs)
• One-time PIN login (Cloudflare Docs)
• Service tokens (Cloudflare Docs)
• Validate JWTs (Cloudflare Docs)
• Network ports (Cloudflare Docs)
• Cloudflare One plans