Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access

Para la función OTP local, se abre Authentication > Multi-factor authentication, se selecciona primero Specific users and groups, se activan los servicios necesarios y se prueba todo con un grupo piloto. All users solo debe utilizarse después de completar las pruebas correctamente.

MFA protege WebAdmin, VPN Portal y Remote Access frente al uso exclusivo de contraseñas robadas. Sin embargo, no sustituye unas reglas de acceso restrictivas ni un acceso de emergencia probado. Por ello, este artículo abarca desde la activación segura hasta la elección de la aplicación, la recuperación y la solución de problemas.

Activar Sophos OTP de forma segura

Antes de la activación

Antes del primer cambio, deben aclararse estos puntos:

• El firewall utiliza una hora correcta en Administration > Time, preferiblemente mediante NTP.
• Los usuarios y grupos están disponibles localmente o a través de AD, LDAP u otro servidor de autenticación.
• Existe un grupo piloto y un segundo administrador probado.
• Se conocen la consola y el procedimiento de recuperación del admin predeterminado.
• Se dispone de una copia de seguridad actual y de un proceso documentado para restablecer tokens.

Para Active Directory clásico, Añadir Active Directory a Sophos Firewall explica cómo configurar la fuente de usuarios.

En Administration > Device access se definen las zonas desde las que se puede acceder a WebAdmin, User Portal, VPN Portal y otros servicios locales. Las Local service ACL exception rules limitan aún más el acceso a redes de gestión, redes VPN o direcciones de origen conocidas. Proteger el acceso a Sophos Firewall: configurar correctamente Device Access explica el endurecimiento en detalle.

SSH no es uno de los servicios protegidos por Sophos OTP. Debe restringirse mediante Device Access y utilizar una clave pública siempre que sea posible; el procedimiento se describe en Conectarse a Sophos Firewall mediante SSH.

⚠️ MFA reduce el riesgo derivado de contraseñas comprometidas, pero no disminuye la superficie de ataque de un servicio accesible públicamente. WebAdmin, SSH y los portales nunca deben estar expuestos más de lo necesario.

Antes de realizar pruebas negativas, también se revisa Administration > Admin and user settings > Login security > Block login. Varios intentos fallidos deliberados pueden bloquear la IP de origen para WebAdmin, CLI, VPN Portal y User Portal, lo que también puede impedir el acceso de un administrador de respaldo desde la misma red. Por tanto, debe existir una segunda fuente o acceso a la consola.

Configurar MFA para un grupo piloto

1. Iniciar sesión en WebAdmin y abrir Authentication > Multi-factor authentication.
2. En One-time password (OTP), seleccionar primero Specific users and groups.
3. Abrir Add users and groups, seleccionar el grupo piloto y aplicar la selección.
4. Activar Generate OTP token with next sign-in si se utiliza una aplicación de autenticación.
5. En Require MFA for, seleccionar únicamente las interfaces de inicio de sesión realmente necesarias.
6. En OTP hash algorithm, elegir un algoritmo compatible con la aplicación prevista.
7. Cambiar los ajustes opcionales de OTP timestep settings solo si la aplicación admite el mismo intervalo; el valor predeterminado es de 30 segundos.
8. Guardar con Apply.

Las opciones de usuario significan:

• No OTP: MFA está desactivada.
• All users: MFA se aplica a todos los usuarios; debe utilizarse solo después del piloto.
• Specific users and groups: MFA se aplica únicamente a las cuentas o grupos seleccionados.

Si Generate OTP token with next sign-in está activado, los usuarios registran una aplicación de software en el siguiente inicio de sesión. User Portal se selecciona automáticamente como servicio MFA. Si la opción está desactivada, los tokens de hardware o administrados manualmente se asignan en Issued tokens.

Seleccionar los servicios de forma deliberada

En SFOS 22, los siguientes servicios están disponibles en Require MFA for:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

MFA para User Portal también se aplica a Captive Portal y Client Authentication Agents. Los usuarios de acceso remoto deben registrar primero su token mediante VPN Portal o User Portal.

Para WAF, no basta con seleccionar el servicio. A partir de SFOS 22 se necesitan Webserver Protection, una Authentication Policy basada en formularios y su asignación a la regla WAF. El procedimiento completo se describe en Proteger Sophos Firewall WAF con MFA.

Elegir el modelo MFA adecuado

Sophos OTP local

Sophos OTP administra los tokens directamente en el firewall y no requiere infraestructura adicional de RADIUS ni de un proveedor de identidad. Resulta especialmente adecuado para usuarios locales normales, entornos pequeños y el endurecimiento rápido de WebAdmin o Remote Access.

La contrapartida de una implantación sencilla es un token independiente de los procesos existentes de Microsoft 365. Los usuarios y el equipo de soporte deben conocer el registro de la aplicación, la entrada de contraseña más OTP y el procedimiento para cambiar de dispositivo.

RADIUS o Entra ID SSO

Una plataforma MFA existente puede encajar mejor en la gestión central de identidades mediante RADIUS o SSO. Sin embargo, requiere pruebas específicas para cada servicio:

• VPN Portal no admite RADIUS con MFA de desafío.
• Sophos Connect no admite un desafío OTP. El cliente envía la contraseña y el OTP juntos con el formato passwordotp, pero admite MFA mediante llamada y notificación push.
• User Portal y WebAdmin admiten además MFA basado en desafío.
• Con Entra ID SSO, MFA se realiza en el proveedor de identidad; no se puede añadir MFA local de Sophos OTP al mismo inicio de sesión SSO.
• Entra SSO con Sophos Connect requiere al menos la versión 2.4 del cliente en Windows. WebAdmin SSO no está disponible en el dispositivo auxiliar de HA.

Para Remote Access existe la guía específica Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal. Si Entra debe controlar en cambio el inicio de sesión de WebAdmin y los roles de administrador, Entra ID SSO para WebAdmin de Sophos Firewall explica el Role mapping, el mínimo privilegio, el inicio de sesión piloto y el acceso local de emergencia.

Sophos Connect o SSL VPN: ¿qué solución conviene? ayuda a elegir el modelo de acceso remoto; antes del despliegue también conviene comprobar la versión del cliente Sophos Connect.

Independientemente del modelo, se comienza con un grupo piloto. Solo se incorporan más usuarios cuando WebAdmin, los portales, los clientes VPN reales, los grupos, los tiempos de espera, los registros y el acceso de respaldo funcionan correctamente.

Configurar tokens y la aplicación de autenticación

Registrar y administrar tokens

Con Generate OTP token with next sign-in activado, el usuario inicia sesión en VPN Portal o User Portal y escanea el código QR. Los administradores también pueden registrar el token en WebAdmin si allí se exige MFA. El código QR solo aparece para usuarios y grupos que tienen MFA configurado.

En Authentication > Multi-factor authentication > Issued tokens se pueden revisar, desactivar temporalmente, eliminar o añadir manualmente los tokens emitidos. También se pueden generar códigos de un solo uso adicionales y comprobar o sincronizar el desfase horario de un token.

Si se pierde un smartphone o se cambia de aplicación, se elimina el token antiguo después de verificar la identidad del usuario. A continuación, el usuario inicia sesión una vez en el portal solo con la contraseña y registra el nuevo código QR mostrado. Un token antiguo no debe seguir existiendo en paralelo sin control.

La aplicación y el algoritmo hash deben ser compatibles

SFOS 22 admite SHA1, SHA256 y SHA512. Sophos recomienda SHA256 o SHA512, pero la aplicación debe ser compatible con el algoritmo elegido:

• Sophos Intercept X for Mobile y Google Authenticator admiten SHA256 y SHA512.
• Microsoft Authenticator no admite estos dos algoritmos en este flujo de trabajo de Sophos. El código QR puede escanearse correctamente, pero el inicio de sesión posterior falla.
• Duo Mobile y Okta Verify figuran entre las aplicaciones indicadas por Sophos; la compatibilidad del código QR y del algoritmo debe corresponder al sistema operativo y a la configuración utilizados.
• Otras aplicaciones TOTP solo deben aprobarse después de una prueba piloto real.

En iOS, el código QR de Sophos no se puede escanear con Google Authenticator, Duo Mobile ni Microsoft Authenticator. La cuenta se crea manualmente con la clave Base32 mostrada. Okta Verify requiere el registro manual mediante Base32 tanto en iOS como en Android. Sin embargo, esto no soluciona la falta de compatibilidad de Microsoft Authenticator con SHA256/SHA512.

La antigua aplicación Sophos Authenticator llegó al final de su vida útil el 31 de julio de 2022 y ya no debe incluirse en nuevos despliegues.

Para migrar de SHA1 a un algoritmo más seguro:

1. Probar la aplicación piloto con SHA256 o SHA512.
2. Seleccionar el nuevo algoritmo en Authentication > Multi-factor authentication.
3. Eliminar los tokens SHA1 antiguos en Issued tokens.
4. Hacer que los usuarios inicien sesión solo con la contraseña y vuelvan a registrar el código QR o la clave Base32.
5. Realizar pruebas controladas de inicio de sesión con un código correcto y otro incorrecto.

Durante la migración pueden coexistir tokens con algoritmos diferentes. Sin embargo, los tokens que no se eliminen seguirán utilizando su algoritmo anterior.

Introducir correctamente la contraseña y el OTP

Para los inicios de sesión con Sophos OTP nativo, el formato oficial es <password><passcode>, sin espacios ni separadores.

Ejemplo:

Contraseña: MiContrasenaSegura
Código OTP: 123456
Entrada:    MiContrasenaSegura123456

Sophos Connect puede mostrar un tercer campo de entrada independiente mediante otp: true. El cliente añade internamente el código a la contraseña. Esta presentación no cambia el formato enviado al servidor de autenticación.

Proteger y recuperar el administrador predeterminado

Activar MFA para el admin predeterminado

El usuario local admin predeterminado no se activa mediante la lista normal de usuarios. Se abre Administration > Device access, se activa MFA for default admin y se configura allí el token de hardware o software.

Antes deben funcionar un segundo administrador, el acceso de gestión y el acceso a la consola. Los códigos de un solo uso adicionales se guardan de forma segura, por ejemplo, en un gestor de contraseñas. El admin predeterminado sigue siendo una cuenta de emergencia y no se utiliza para la administración diaria.

Otros administradores no pueden activar, desactivar, editar ni eliminar el token del admin predeterminado. El OTP hash algorithm global elegido también se aplica a este token.

Recuperación mediante Device Console

Si el token solo falta temporalmente, Device Console permite autorizar un único inicio de sesión sin MFA:

1. Introducir 2 para System Configuration.
2. Introducir 6 para Skip multi-factor authentication for next Admin user login.
3. Iniciar sesión en WebAdmin y comprobar el token.

Si se ha perdido el dispositivo o el token ha quedado inutilizable de forma permanente, se restablece MFA:

1. Introducir 2 para System Configuration.
2. Introducir 7 para Reset multi-factor authentication for Admin user.
3. Confirmar con y.
4. Iniciar sesión una vez en WebAdmin solo con la contraseña de administrador.
5. Seguir las instrucciones para registrar de nuevo MFA y, a continuación, volver a probar el inicio de sesión con MFA.

Estas dos opciones solo modifican el estado de MFA. Si también se desconoce la contraseña del administrador predeterminado, el artículo independiente sobre recuperación de contraseña explica el procedimiento serie documentado para appliances físicos y las limitaciones cuando se pierden tanto la contraseña como MFA.

Probar, revisar los registros y desplegar

Probar cada servicio por separado

Un inicio de sesión correcto en WebAdmin no demuestra que los portales y clientes VPN funcionen igual. Antes de un despliegue amplio, se comprueba:

• WebAdmin: Iniciar sesión como administrador piloto con un OTP correcto y otro deliberadamente incorrecto.
• Default admin: Comprobar la ruta independiente de Device Access y el procedimiento de recuperación documentado.
• User Portal y VPN Portal: Probar el registro mediante QR o Base32 y el inicio de sesión con <password><passcode>.
• SSL VPN e IPsec Remote Access: Probar clientes reales y exactamente el grupo de usuarios utilizado en producción.
• Sophos Connect: Cuando proceda, probar el tercer campo OTP, los perfiles de cliente actuales y el comportamiento de llamada/push.
• RADIUS o Entra SSO: Comprobar tiempos de espera, registros del IdP y el comportamiento de desafío realmente compatible.
• Device Access: Probar el acceso desde una red de origen permitida y otra no permitida.

Solo se realiza un número controlado de intentos fallidos después de revisar Block login. El resultado esperado no es solo un inicio de sesión correcto: un código incorrecto debe rechazarse, el intento debe registrarse y el servicio debe ser accesible únicamente desde las redes previstas.

Interpretar correctamente los registros de autenticación

En Log viewer se revisan los inicios de sesión correctos y fallidos junto con el servicio, el usuario, el origen, la hora y el motivo documentado. Según el evento, SFOS puede mostrar únicamente un mensaje genérico, como credenciales incorrectas. Sin pruebas adicionales, no debe deducirse que la causa fue exclusivamente la contraseña, el OTP o un código caducado.

Con MFA externa, los registros de RADIUS, NPS o IdP forman parte de la misma comprobación. Solución de problemas de Sophos Firewall: servicios y registros ayuda con los archivos de registro locales y la asignación de servicios. Para una conservación y correlación más prolongadas, véase Enviar Syslog de Sophos Firewall a un SIEM.

Antes del despliegue amplio

• Grupo piloto probado correctamente con todos los servicios necesarios.
• Segundo administrador, códigos de un solo uso y recuperación mediante Device Console documentados.
• Usuarios informados sobre el registro de la aplicación y contraseña más OTP.
• Proceso de restablecimiento de tokens definido para smartphones perdidos o nuevos.
• Device Access, bloqueos de inicio de sesión y conservación central de registros revisados.
• Responsabilidades, tiempos de espera y acceso de respaldo definidos para MFA externa.

Solución de problemas

Token, código QR y entrada

No se acepta el código OTP

Primero se comparan la hora del firewall y del smartphone, la aplicación utilizada, el algoritmo hash y el intervalo. En Issued tokens se puede comprobar y sincronizar el desfase horario. Tras migrar el algoritmo, el token antiguo debe haberse eliminado y registrado de nuevo.

El cambio de servidor NTP debe planificarse por separado, ya que el firewall vuelve a conectar los túneles IPsec existentes.

El código QR no aparece o no se puede escanear

El usuario debe pertenecer al grupo MFA seleccionado e iniciar sesión en VPN Portal o User Portal. Los administradores también pueden registrarse en WebAdmin si MFA está activa allí. Además, el portal y el origen deben estar permitidos en Administration > Device access.

En iOS o con Okta Verify se utiliza la clave Base32 en lugar del código QR cuando se aplican las limitaciones indicadas anteriormente.

El inicio de sesión indica una contraseña incorrecta

En un inicio de sesión con Sophos OTP nativo, la contraseña debe ir seguida inmediatamente del código. Sin un campo OTP separado, introducir solo la contraseña no es suficiente.

Acceso, grupos y Remote Access

No se puede acceder al portal

Primero se revisan la zona, el origen y el servicio necesario en Administration > Device access. Una Local Service ACL Exception Rule restrictiva es más segura que una autorización general desde WAN.

MFA no se aplica a Remote Access

Las configuraciones de MFA y Remote Access deben utilizar el mismo grupo de usuarios realmente importado. Después se vuelve a importar o distribuir el perfil del cliente y se prueba la conexión con el cliente real. Antes de la primera conexión VPN, el token debe estar registrado mediante VPN Portal o User Portal.

MFA solo se aplica a algunos usuarios

No se comparan únicamente los nombres de grupo visibles, sino los grupos realmente coincidentes de AD, LDAP, RADIUS o Entra ID. Tras eliminar a un usuario de AD de un grupo MFA, puede ser necesario un último inicio de sesión con MFA; solo los inicios posteriores dejan de requerir OTP.

Bloqueo y MFA externa

El administrador está bloqueado

Para el admin predeterminado se utilizan las opciones 6 o 7 de Device Console descritas anteriormente. Para otro administrador se utiliza el segundo administrador preparado desde un origen permitido y después se revisan los grupos, el token y el estado del bloqueo de inicio de sesión.

RADIUS o Entra MFA no funcionan de forma fiable

Se revisan los tiempos de espera de RADIUS, los registros del IdP, los grupos y el comportamiento de desafío del servicio concreto. Una prueba correcta del servidor de autenticación no demuestra un inicio de sesión productivo mediante VPN Portal, Sophos Connect o WebAdmin. Cada una de estas rutas debe probarse por separado.