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

Los siguientes procedimientos distinguen entre las funciones de MFA documentadas de SFOS 22 y SFOS 23. En particular, Share QR code y el periodo de validez del QR descrito no deben extrapolarse a SFOS 22. Las restricciones de las aplicaciones se refieren al procedimiento de registro de Sophos documentado, no de forma general a todas las versiones actuales de las aplicaciones. Por ello, antes del despliegue se comprueban con el grupo piloto la compilación de SFOS instalada, el sistema operativo móvil, la versión concreta de la aplicación y cada servicio necesario.

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. En SFOS 23, seleccionar también Share QR code: Email envía el código QR a la dirección de correo del usuario en el siguiente inicio de sesión en VPN Portal o User Portal. Portals lo muestra en User Portal y VPN Portal después del siguiente inicio de sesión en VPN Portal, User Portal o WebAdmin. Esta selección no corresponde al asistente del administrador predeterminado descrito más adelante.
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.

Con Email, comprobar antes del piloto que está configurada la dirección correcta del usuario y que la entrega funciona. El código QR contiene el secreto del token: proteger el acceso al buzón y no incluir el código QR ni la clave Base32 en tickets o capturas de pantalla sin protección. Si no se produce la entrega, comprobar primero la dirección y el envío de correo electrónico; no provocar un bloqueo de inicio de sesión mediante intentos fallidos repetidos. Para un piloto sin entrega de correo electrónico, Portals es la alternativa documentada; debe ser posible acceder al portal desde la red prevista.

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 registra el código QR en una aplicación compatible. En SFOS 22 se muestra el QR; los administradores también pueden registrar el token en WebAdmin si allí se exige MFA. En SFOS 23, la entrega sigue Share QR code: con Email, utilizar el QR recibido por correo; con Portals, el mostrado en los portales. Un inicio de sesión en WebAdmin puede activar la visualización en los portales con Portals, pero no el envío por correo. El registro solo se aplica a usuarios y grupos que tienen MFA configurado.

Para el registro inicial en SFOS 23 con Generate OTP token with next sign-in en ON, se aplica lo siguiente a los usuarios MFA seleccionados: el QR generado caduca si no se utiliza para iniciar sesión en las 24 horas siguientes a su generación. Para generar otro, el usuario inicia sesión en VPN Portal o User Portal solo con la contraseña; el nuevo QR se entrega según Email o Portals. Después, registrarlo en la aplicación y verificar un inicio de sesión nuevo con <password><passcode>. Esta duración del QR es distinta de la ventana de 300 segundos del primer código. El flujo no se aplica a un token emitido con estado OFF ni a la reemisión manual de un seed; no se presupone para SFOS 22 ni para todos los flujos del asistente del administrador predeterminado.

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.

Poner el estado del token en OFF impide que el usuario inicie sesión; no permite el acceso solo con contraseña. No equivale a eliminar el token y registrarlo de nuevo ni a omitir MFA para un único inicio de sesión en CLI Main Menu > 2. System Configuration.

Si se pierde un smartphone o se cambia de aplicación, verificar primero la identidad del usuario. Justo antes de eliminar el token, comprobar en Authentication > Multi-factor authentication que Generate OTP token with next sign-in está en ON; en SFOS 23, configurar también Share QR code como Email o Portals. Si el modo manual OFF es intencionado, preparar en su lugar la emisión manual de un token con un seed nuevo; el flujo QR automático siguiente no se aplica. Solo entonces eliminar el token antiguo en Issued tokens. El usuario inicia sesión una vez en VPN Portal o User Portal solo con la contraseña y registra el QR nuevo: SFOS 22 lo muestra, mientras que SFOS 23 lo envía por correo o lo muestra en el portal según la selección. Después, verificar un inicio de sesión nuevo con <password><passcode>. Un token antiguo no debe seguir existiendo en paralelo sin control.

En este flujo de cambio de aplicación o sustitución de SFOS 23, el QR generado caduca si no se utiliza para iniciar sesión en las 24 horas siguientes a su generación. Volver a iniciar sesión solo con la contraseña genera un QR nuevo, que se entrega otra vez mediante Email o Portals. Las 24 horas corresponden al QR, no a la ventana de 300 segundos del primer código explicada más adelante. No se presupone esta duración del QR para SFOS 22 ni para todos los flujos del asistente del administrador predeterminado.

La lista también puede contener tokens preparados manualmente sin asignación de usuario; se les puede asignar un usuario más adelante. También aparecen los tokens asignados manualmente y los tokens de usuarios y administradores que han registrado el código QR. Por tanto, una entrada en la lista no demuestra por sí sola un inicio de sesión con MFA correcto: antes de la entrega, comprobar la asignación de usuario, el estado del token y el inicio de sesión real.

Tras la eliminación, el código de acceso del token antiguo deja de ser válido y no debe añadirse en el inicio de sesión de registro solo con contraseña. Una eliminación no puede deshacerse introduciendo de nuevo el código antiguo; la vía segura de recuperación es una nueva emisión controlada. Por ello, antes de eliminar, comprobar el acceso al portal, la entrega o la entrega manual de la semilla y la alternativa de respaldo. Si hay varios usuarios, proceder por etapas y validar cada nuevo registro antes de migrar el siguiente grupo.

Provisionar manualmente un token de hardware o software

También en el modo manual, configurar primero Specific users and groups con el grupo piloto y los servicios necesarios en Require MFA for, seleccionar el algoritmo compatible y el intervalo de tiempo y guardar con Apply. Después, en el diálogo Add token (for hardware tokens), seleccionar OTP hash algorithm para el token que se va a crear antes de completar Secret, el usuario y, si procede, Use custom timestep, y guardar con Save. Seleccionar únicamente un valor predeterminado global no sustituye ni la asignación del token ni el posterior inicio de sesión del piloto.

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.

Automatización mediante API: separar los ajustes del estado del token

En la automatización mediante API, OTPSettings y OTPTokens corresponden a dos tareas distintas: los ajustes definen el ámbito de aplicación de MFA, los servicios y los valores globales; el registro del token corresponde a un único token emitido. Un cambio en los ajustes no sustituye la asignación de usuario, el registro ni el inicio de sesión del piloto.

En OTPSettings se utilizan los valores de conmutación documentados 0 y 1, no las etiquetas de la GUI ni Enable/Disable:

• otp desactiva o activa OTP. allUsers=0 limita el ámbito de aplicación a los usuarios o grupos seleccionados explícitamente; no activa OTP por sí mismo. Para el piloto, se mantiene una selección restrictiva en lugar de establecer allUsers=1. El ejemplo muestra la selección en otpUsers/user, pero la tabla de parámetros no define ninguna codificación de ID de usuario para este campo. No construir identidades a partir de nombres o de supuestos ID.
• tokenAutoCreation controla la generación automática de tokens, no el estado de un token ya emitido. otpUserPortal, otpVPNPortal, otpSSLVPN, otpWebAdmin y otpIPsec corresponden a User Portal, VPN Portal, SSL VPN Remote Access, WebAdmin e IPsec Remote Access. Seleccionar únicamente los servicios necesarios; al revisar la configuración, también debe tenerse en cuenta la selección automática de User Portal en el flujo de la GUI.
• Solo SFOS 23 documenta el campo opcional qrCodeVia, con los valores exactos email o portal. Las etiquetas de la GUI Email y Portals no son valores literales de la API. No se documenta ningún valor predeterminado de la API; este campo no aparece en la referencia de SFOS 22.

Tratar los valores temporales por separado: OTPSettings/defaultTimeStep es el intervalo global de los tokens, OTPSettings/maxTimeStepsInterval es la ventana de verificación para el uso habitual y OTPSettings/maxInitialTimeStepDiff es la ventana para el primer uso. En cambio, OTPTokens/timeStep es el intervalo del token individual. La API indica, respectivamente, 10–300 segundos, 0–10 intervalos de tiempo, 0–600 intervalos de tiempo y 10–300 segundos como límites de validación. No son recomendaciones de funcionamiento ni valores predeterminados de la API; las columnas de valores predeterminados están vacías. Los valores predeterminados de la GUI descritos anteriormente y la compatibilidad de la aplicación se consideran por separado.

En el token, active, autoCreated y lastLogin se refieren a su estado, su origen y su último inicio de sesión correcto, no a la selección global de MFA. No rellenar lastLogin ni autoCreated como campos obligatorios de una automatización. El ejemplo del token tampoco es un esquema de importación validado: utiliza OTPTokens/user, mientras que la tabla indica userid. En la ayuda de MFA, Sophos exige un <tokenid/> vacío para la importación mediante API; el ejemplo del token también lo muestra así, pero la tabla de la API indica una longitud mínima de 1 carácter. No resolver esta contradicción mediante ID inventados ni mediante un supuesto esquema de escritura válido de forma general.

XML-Delete no es una importación de tokens. La referencia Delete OTP Token para SFOS 22 y SFOS 23 identifica un token existente mediante tokenid; se documenta una única cadena de 1–32 caracteres. Antes de eliminarlo, se lee el registro guardado del token desde una vista actual y fiable y se comprueban su identificador y su asignación al usuario exacto previsto. Ni user, ni userid, ni el <tokenid/> vacío de la guía de importación sustituyen este identificador de eliminación. La indicación Mandatory: No de la tabla no autoriza a omitir el identificador, inventarlo ni deducirlo de un nombre de usuario. Si la identidad o el esquema correspondiente a la versión no están claros, no se realiza la eliminación; primero se aclara la asignación o el esquema.

Antes de XML-Delete, se mantienen disponibles el acceso de respaldo probado, el acceso de gestión y el acceso a la consola; la verificación del usuario y la preparación de la nueva emisión automática o manual descritas anteriormente siguen aplicándose sin cambios. También siguen vigentes las restricciones para el administrador predeterminado. Después de la llamada, se vuelve a leer el inventario de tokens y se comprueba que el token antiguo exacto previsto ya no está presente y que los demás tokens no han cambiado. A continuación, se realiza la nueva emisión preparada y se verifica un inicio de sesión nuevo con MFA correcto; el acceso de respaldo se mantiene disponible hasta la aceptación. Una respuesta por sí sola no sustituye esta comprobación del inventario ni la prueba de MFA.

La referencia de Delete enumera 200 con el símbolo de mensaje no resuelto OTPTokenDeleted y 500 con OTPTokenNotThere. Son datos de la documentación, no mensajes confirmados en tiempo de ejecución ni garantías de un estado HTTP, de repetibilidad o de un reintento automático seguro. De ellos no se deriva ninguna solicitud XML ejecutable ni ninguna envoltura de solicitud.

La importación mediante API no equivale al diálogo manual Add token. Antes de una importación en producción, comprobar la copia de seguridad y el acceso permitido a la API, aclarar el esquema correspondiente a la versión y no almacenar seeds en registros de solicitudes sin protección. Después, revisar los ajustes guardados, la selección restrictiva de usuarios, la asignación de servicios y el estado del token, y comprobar el inicio de sesión del piloto descrito. Una llamada a la API correcta no constituye por sí sola la aceptación de MFA.

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. En SFOS 23, elegir también Email o Portals en Share QR code antes de Apply.
3. Seleccionar el nuevo algoritmo en Authentication > Multi-factor authentication.
4. Guardar con Apply.
5. Eliminar los tokens SHA1 antiguos en Issued tokens. Para eliminar el token del admin predeterminado, iniciar sesión como ese usuario; otro administrador no puede eliminarlo. Mantener disponibles de antemano el acceso de respaldo probado y el acceso a la consola.
6. Hacer que los usuarios normales inicien sesión en VPN Portal o User Portal solo con la contraseña y registren de nuevo el QR o la clave Base32 en una aplicación compatible con SHA256/SHA512. En SFOS 23, la entrega del QR sigue Email o Portals. Para el admin predeterminado, el nuevo registro tras eliminar el token comienza en cambio con un inicio de sesión en WebAdmin solo con contraseña, no en User Portal o VPN Portal; seguir el flujo de registro que se muestra allí. Esto es la migración SHA, no Use an existing token en el asistente de reactivación. No presuponer un selector Share QR code adicional en el asistente para esta excepción.
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. Su asistente específico está en Administration > Device access, no en Issued tokens > Add token (for hardware tokens) para usuarios normales.

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.

Antes de empezar, también se comprueban la hora, la compatibilidad de la aplicación o del hardware y Block login, tal como se ha explicado antes. Los nuevos tokens de hardware y software heredan el algoritmo de Authentication > Multi-factor authentication > OTP hash algorithm; no se selecciona de forma independiente en el asistente del administrador predeterminado. Escanear correctamente el QR no demuestra la compatibilidad del algoritmo. Siguen aplicándose las limitaciones de aplicaciones y Base32 descritas anteriormente.

1. Iniciar sesión en WebAdmin como admin predeterminado y abrir Administration > Device access.
2. Activar MFA for default admin y pulsar Apply.
3. Seleccionar el método de token adecuado en el asistente y pulsar Next. A continuación, completar la opción correspondiente:

• Configure a hardware token: Introducir la clave individual proporcionada por el fabricante del dispositivo y el intervalo que coincida con el token de hardware. Pulsar Next e introducir la contraseña del administrador predeterminado seguida inmediatamente del código actual del hardware, con el formato <password><passcode>, sin espacios ni separadores. Pulsar Validate y, tras una validación correcta, finalizar con Apply.
• Generate a software token: Instalar una aplicación de autenticación compatible en el dispositivo móvil y escanear el código QR mostrado. Introducir la contraseña del administrador predeterminado seguida inmediatamente del código actual de la aplicación como <password><passcode>. Pulsar Validate y, tras una validación correcta, finalizar con Apply.
• Use an existing token: Si ya existe un token de hardware o software para el admin predeterminado y solo se está reactivando MFA, seleccionar esta opción e introducir la contraseña seguida inmediatamente del código actual. Para configurar en su lugar un nuevo token de software, seleccionar Generate a software token y registrar el código QR en la aplicación. Esta elección no es una migración de tokens de usuario SHA1 existentes.

El primer Apply inicia el proceso de configuración; los nuevos tokens de hardware y software siguen requiriendo Validate y el Apply final. Si la validación falla, comprobar primero la contraseña más el código, la hora, el intervalo y el algoritmo, en lugar de probar repetidamente al azar. Mantener abierta la sesión existente durante la comprobación y, después de completar la configuración, probar una sesión nueva e independiente de WebAdmin como admin predeterminado con la contraseña más un código nuevo. Considerar la configuración completa solo tras un inicio de sesión correcto y el almacenamiento seguro de los códigos de un solo uso; el segundo administrador no sustituye la gestión del token del administrador predeterminado ni el procedimiento de recuperación por consola descrito a continuación.

Recuperación mediante CLI Main Menu > 2. System Configuration

Las opciones de recuperación están en CLI Main Menu > 2. System Configuration, no en 4. Device Console. Si ya se está en Device Console, primero se vuelve al Main Menu y allí se selecciona 2 para System Configuration.

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, en CLI Main Menu > 2. System Configuration se puede autorizar sin MFA únicamente el siguiente inicio de sesión en WebAdmin del admin predeterminado:

1. En CLI Main Menu, introducir 2 para System Configuration.
2. Introducir 6 para Skip multi-factor authentication for next Admin user login.
3. Iniciar sesión una vez en WebAdmin solo con la contraseña del admin predeterminado y comprobar el token. Mantener disponibles el acceso de respaldo probado y el acceso a la consola.
4. Después, abrir una sesión nueva e independiente de WebAdmin como admin predeterminado con la contraseña más el código actual, con el formato <password><passcode>. La recuperación solo se completa tras un inicio de sesión con MFA correcto; documentar el resultado y mantener disponible el acceso de respaldo hasta entonces.

Si el token sigue siendo inutilizable, seguir el procedimiento de restablecimiento y nuevo registro que se describe a continuación y verificar después otro inicio de sesión nuevo con MFA. La omisión de MFA solo se aplica al siguiente inicio de sesión; ni No OTP para todos ni un acceso WAN más amplio sustituyen esta comprobación.

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

1. En CLI Main Menu, 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

Si el piloto falla, se detiene el despliegue. Mediante el segundo administrador probado, la selección normal del piloto en Specific users and groups puede restablecerse al estado inicial documentado; esto no afecta al asistente separado del administrador predeterminado ni restaura tokens eliminados. Para los grupos externos, sigue siendo necesario tener en cuenta el inicio de sesión con MFA adicional explicado anteriormente. No utilizar ni No OTP para todos ni un acceso WAN amplio como solución general de reparación. Tras una corrección, volver a probar los servicios afectados en sesiones nuevas.

• Grupo piloto probado correctamente con todos los servicios necesarios.
• Segundo administrador, códigos de un solo uso y recuperación mediante CLI Main Menu > 2. System Configuration 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.

Para sincronizar, abrir Authentication > Multi-factor authentication > Issued tokens, seleccionar Synchronize token time offset para el token afectado, introducir el código actual generado por la aplicación o el token de hardware y pulsar Check. El desfase horario se sincroniza con el firewall y se corrige la desviación temporal. Después, repetir de forma controlada la prueba con un inicio de sesión nuevo; mantener disponible el acceso de respaldo y revisar Block login antes de nuevos intentos fallidos.

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. En SFOS 22, los administradores también pueden registrarse en WebAdmin si MFA está activa allí. En SFOS 23, comprobar primero Share QR code: con Email, revisar la bandeja de entrada después del inicio de sesión en el portal en vez de esperar un QR visible en el portal; con Portals, el QR se muestra en los portales, también después de un inicio de sesión en WebAdmin que active la visualización. Además, el portal y el origen deben estar permitidos en Administration > Device access. Para el registro inicial o la sustitución de la aplicación en SFOS 23 con la generación de tokens activada, comprobar también la duración de 24 horas explicada antes: si el QR no se utilizó para iniciar sesión durante ese periodo, iniciar sesión en VPN Portal o User Portal solo con la contraseña y registrar el nuevo QR entregado según Email o Portals.

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 descritas anteriormente en CLI Main Menu > 2. System Configuration. 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.