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.

El procedimiento principal configura Sophos OTP local. Más adelante se comparan RADIUS y Entra ID SSO como alternativas.

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.

Después de Apply, completar inmediatamente el proceso con un usuario piloto: según el servicio seleccionado, iniciar sesión primero en User Portal o VPN Portal solo con la contraseña, registrar el código QR o la clave Base32 en la aplicación de autenticación y abrir después una sesión nueva con <password><passcode>. Un código erróneo introducido de forma intencionada debe rechazarse y el intento debe aparecer en Log viewer. All users solo debe plantearse después de esta prueba positiva y negativa.

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.

Para los usuarios autenticados externamente, la eliminación de un grupo MFA no surte efecto inmediato en el primer inicio de sesión posterior. Sophos exige todavía un inicio de sesión con MFA; el código OTP deja de ser necesario a partir de los siguientes accesos. Por tanto, una modificación de grupo se comprueba con una sesión nueva y al menos dos inicios de sesión controlados.

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.

Provisionar manualmente un token de hardware o software

Si el firewall no debe generar un código QR, se deja desactivado Generate OTP token with next sign-in. Los tokens ya registrados siguen funcionando; para los nuevos usuarios, el seed se introduce manualmente en Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). El nombre del botón es más limitado que su función, ya que el mismo cuadro de diálogo también permite provisionar manualmente un token de software.

Primero se seleccionan OTP hash algorithm y el timestep que requiere el token concreto o la aplicación de autenticación. Para Secret se aplican estas reglas:

• Para un token de hardware, se introduce la clave individual suministrada por el fabricante.
• Para un token de software, se utiliza un seed hexadecimal único y suficientemente aleatorio. Si la aplicación requiere Base32, el seed se convierte localmente con una herramienta offline controlada.
• Un seed de producción no debe introducirse en una web pública de conversión ni incluirse en un ticket, un correo sin cifrar o un comando de shell que quede guardado en el historial. Quien conozca el seed puede generar códigos OTP válidos.

Si el token concreto difiere del Default token timestep global, se activa Use custom timestep únicamente para ese token y se introduce el intervalo que realmente admite. Sin esta opción se aplica el valor global; antes de guardar se comprueba la compatibilidad de la aplicación y del hardware.

A continuación, se selecciona el usuario exacto previsto y se guarda con Save. El token de hardware o el seed Base32 se entrega una sola vez mediante un canal protegido. Después se prueban un código correcto y otro deliberadamente incorrecto, y se sincroniza el desfase horario en Issued tokens si es necesario. Si el seed puede haber quedado expuesto, no se sigue utilizando el token: se elimina y se emite uno con un seed nuevo.

Emitir códigos de un solo uso adicionales de forma controlada

Si el acceso a la aplicación o al token de hardware no está disponible temporalmente, se edita el usuario afectado en Authentication > Multi-factor authentication > Issued tokens. En Additional codes, el botón de suma genera códigos adicionales y Save los asigna al token. El firewall elimina automáticamente cada código de la lista después de utilizarlo.

Antes de emitirlos se verifica la identidad del usuario. Los códigos se entregan una sola vez mediante un canal protegido exclusivamente a ese usuario y no se guardan juntos en un ticket o correo sin protección. Los códigos adicionales no sustituyen la renovación de un token perdido de forma permanente o que pueda haberse copiado: se elimina el token antiguo y se registra otro con un seed nuevo.

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.

Sophos Intercept X for Mobile admite un timestep de token personalizado. La mayoría de las demás aplicaciones de autenticación solo admiten el valor predeterminado de 30 segundos, por lo que el valor global no se modifica únicamente para una aplicación.

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.

Después de actualizar desde una versión anterior a SFOS 22, se debe contar con tokens SHA1 existentes, ya que las versiones anteriores de SFOS generaban los tokens MFA con SHA1. Seleccionar un algoritmo global más seguro no convierte esos tokens existentes.

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

1. Probar la aplicación piloto con SHA256 o SHA512.
2. Activar Generate OTP token with next sign-in.
3. Seleccionar el nuevo algoritmo en Authentication > Multi-factor authentication.
4. Guardar con Apply.
5. Eliminar los tokens SHA1 antiguos en Issued tokens.
6. Hacer que los usuarios inicien sesión solo con la contraseña y vuelvan a registrar el código QR o la clave Base32.
7. 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.

Limitar el timestep y las ventanas de tolerancia

En OTP timestep settings se configura no solo el intervalo para los códigos nuevos, sino también dos ventanas de verificación. Los tres valores tienen efectos diferentes:

• Default token timestep establece el intervalo en el que la aplicación o el token de hardware genera un código nuevo. El valor predeterminado es de 30 segundos. Un cambio solo se aplica a los tokens generados a partir de entonces y no modifica los existentes.
• Maximum verification code offset determina cuántos intervalos sigue siendo válido un código aún no utilizado. Con el valor predeterminado 2 y un intervalo de 30 segundos, también se aceptan códigos no utilizados de los 60 segundos anteriores.
• Maximum initial verification code offset se aplica al primer código después de escanear el código QR. Con el valor predeterminado 10 y un intervalo de 30 segundos, la ventana es de 300 segundos si el código todavía no se ha utilizado.

Estas ventanas no sustituyen una sincronización horaria correcta. Primero se comprueban el NTP del firewall y la hora del dispositivo; después se mantiene cada offset tan pequeño como resulte práctico para las aplicaciones y los tokens de hardware utilizados. Una ventana mayor acepta durante más tiempo un código interceptado que aún no se haya utilizado. Tras un cambio se prueba un token piloto recién emitido; no se presupone que un token existente utilice el nuevo timestep.

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

Las opciones de menú 6 y 7 solo aparecen si MFA for default admin ya está configurado en Administration > Device access. Si no aparecen, no se debe asumir un error de consola; primero se comprueban este ajuste y que la cuenta sea realmente el usuario predeterminado admin. Las opciones no se aplican a otras cuentas de administrador.

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.