La consola de administración del FortiGate expuesta a internet: el otro error

Cuando se habla de los riesgos del SSL-VPN, se habla del portal por el que entran los usuarios. Pero hay otra puerta en el mismo equipo que muchas veces está igual de expuesta y casi nadie revisa: la consola de administración del FortiGate. Si el GUI o el SSH del firewall responden desde internet a cualquiera, cualquier falla en esa interfaz se convierte en una forma de tomar el control del equipo que protege toda tu red.

¿Por qué importa tanto?

Porque no es un riesgo teórico. En octubre de 2022, Fortinet publicó una falla crítica de omisión de autenticación en la interfaz de administración de FortiOS (CVE-2022-40684) que se explotó activamente: permitía operar sobre el equipo por la interfaz administrativa sin credenciales. Los equipos con la administración publicada a internet fueron los primeros en caer. Y no es exclusivo de un fabricante: las interfaces de administración expuestas son un blanco constante en toda la industria.

La regla es simple: la consola de administración no tiene por qué estar abierta a internet. Si hace falta administrar el equipo desde fuera, se entra primero por el VPN y después a la consola.

¿Cómo sé si mi consola está expuesta?

Dos revisiones de solo lectura en el CLI. La primera muestra qué servicios de administración tiene habilitada cada interfaz:

show system interface | grep -f allowaccess

Busca la interfaz que da a internet (normalmente wan1, port1 o similar). Si su línea set allowaccess incluye https, http o ssh, la consola responde por esa interfaz.

La segunda muestra desde dónde puede entrar cada administrador:

show system admin | grep -f trusthost

Aquí está la trampa que documenta Fortinet: los trusted hosts se configuran por cuenta de administrador, y basta con que una sola cuenta no tenga trusted hosts para que la administración quede abierta desde cualquier IP. No importa que las demás cuentas estén restringidas.

¿Cómo la cierro?

En orden de preferencia:

1. Quitar la administración de la interfaz de internet. Si no la necesitas ahí, retira https, http y ssh del allowaccess de esa interfaz. Es lo más efectivo.
2. Si de verdad la necesitas desde fuera, limitar el origen con una política local-in que solo permita las IP de administración y niegue el resto. Las políticas local-in controlan el tráfico dirigido al propio FortiGate; hasta FortiOS 7.4 se configuran solo por CLI y desde 7.6 también por el GUI.
3. Trusted hosts en todas las cuentas de administrador, sin excepción, incluidas las cuentas que casi no se usan.

Un ejemplo de política local-in que permite la administración por HTTPS solo desde un grupo de direcciones de confianza y niega el resto:

config firewall local-in-policy
    edit 1
        set intf "wan1"
        set srcaddr "admin-confianza"
        set dstaddr "all"
        set action accept
        set service "HTTPS" "SSH"
        set schedule "always"
    next
    edit 2
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "HTTPS" "SSH"
        set schedule "always"
    next
end

Ajusta el nombre de la interfaz y crea antes el objeto de direcciones. Un detalle: si cambiaste el puerto de administración HTTPS por uno distinto al de omisión, el servicio "HTTPS" de la política ya no coincide y necesitas un servicio personalizado con el puerto real.

¿Qué más conviene endurecer de paso?

• MFA para los administradores, no solo para los usuarios del VPN.
• Solo los protocolos necesarios. Si nadie usa HTTP o Telnet para administrar, que no estén habilitados en ninguna interfaz.
• Registro de los intentos de inicio de sesión, para ver los intentos de fuerza bruta antes de que tengan éxito.
• Ping solo donde haga falta. Aun con trusted hosts, si una interfaz permite ping, responde a cualquiera.
• Firmware al día. Ninguna de estas medidas sustituye el parche: lo complementa.

¿Y si administro el equipo desde fuera con frecuencia?

Es el caso más común en empresas con sucursales o con un proveedor externo de soporte. La salida no es dejar la consola abierta, sino ordenar el camino de entrada:

• Primero el VPN, después la consola. El administrador se conecta al túnel IPsec, con su segundo factor, y desde ahí llega a la administración por la red interna. La consola nunca se publica.
• Un equipo de salto. Si varias personas administran, un servidor de salto con registro de sesiones deja constancia de quién entró y qué hizo.
• Administración centralizada. Con muchos FortiGate, una consola central evita tener que abrir la administración de cada equipo por separado.

En los tres casos, la consola del FortiGate solo responde a direcciones internas conocidas, y eso es lo que la protege cuando aparece la siguiente falla.

¿Qué tiene que ver con la migración del SSL-VPN?

Mucho. La migración es el momento en que alguien revisa a fondo la configuración de acceso remoto del FortiGate, probablemente por primera vez en años. Aprovéchala para revisar también quién puede llegar a la consola. Es la misma lógica de la guía de la NSA y la CISA que citamos en ¿Por qué la industria se aleja del SSL-VPN?: reducir la superficie expuesta.

Si estás en plena migración, la guía completa está en Migrar de SSL-VPN a IPsec en FortiGate, y el segundo factor para los usuarios del túnel nuevo, en MFA en el VPN IPsec del FortiGate.

Referencias

• Fortinet, System administrator best practices (Hardening your FortiGate).
• Fortinet, Local-in policy (guía de administración de FortiOS 7.2.8).
• Fortinet Community, Impact of local-in policies and trusted hosts configuration on FortiGate access.
• Fortinet Community, Configure local-in policy to restrict unauthorized administrative access with custom HTTPS port.
• Fortinet PSIRT, aviso FG-IR-22-377 sobre CVE-2022-40684 (omisión de autenticación en la interfaz de administración de FortiOS, octubre de 2022).