Configurar de forma segura administradores y perfiles en Sophos Firewall

Para la administración diaria, cada persona debería disponer de su propia cuenta. Primero se crea un perfil Device Access adecuado y después, en Authentication > Users, un usuario local con User type: Administrator. El perfil determina qué puede ver o modificar el administrador. MFA, los orígenes de acceso y Device Access protegen además el inicio de sesión y restringen el acceso a WebAdmin.

El administrador predeterminado admin se conserva como acceso de emergencia probado y no se utiliza como cuenta diaria compartida. Así, los cambios se pueden atribuir a una persona y un error en un perfil restringido no bloquea la última vía de recuperación.

Configurar un administrador local en ocho pasos

1. Comprobar la copia de seguridad, el administrador predeterminado y el acceso de recuperación. Mantener abierta una sesión de administrador existente hasta que la prueba termine correctamente.
2. Documentar la tarea y los permisos necesarios, por ejemplo, solo diagnóstico o también cambios en objetos de red.
3. Crear un perfil propio en Profiles > Device access > Add y dejar en None las áreas que no se necesiten.
4. En Authentication > Users > Add, introducir un nombre de usuario personal y establecer User type en Administrator.
5. Asignar el nuevo perfil, una contraseña propia y segura, y la dirección de correo corporativa.
6. En Administrator advanced settings, limitar cuando corresponda Schedule for device access y Login restriction for device access.
7. Comprobar que Local sigue disponible en Authentication > Services > Administrator authentication methods. Después, configurar MFA y el acceso a WebAdmin desde la red de gestión.
8. Probar la cuenta de forma positiva y negativa en una ventana privada del navegador. Solo entonces migrar otras cuentas o desactivar accesos antiguos.

⚠️ Un perfil nuevo no debe utilizarse en producción hasta que exista un segundo administrador funcional y una vía de recuperación documentada. El perfil integrado Administrator concede acceso completo y debe limitarse al grupo mínimo imprescindible.

Diferenciar las cinco capas de protección

En el acceso administrativo intervienen varias opciones. Cumplen funciones distintas y no se sustituyen entre sí:

• Cuenta de usuario: Identifica a la persona. Las cuentas personales permiten atribuir los cambios; las cuentas de equipo como firewalladmin ocultan esa relación.
• Perfil Device Access: Define con None, Read-only y Read-write qué menús y funciones son visibles o modificables. Los permisos también se aplican a la API.
• Schedule y Login Restriction: Limitan cuándo y desde qué direcciones IPv4 puede utilizar WebAdmin esta cuenta de administrador concreta.
• Device Access y Local Service ACL: Determinan desde qué zonas y orígenes se puede acceder a WebAdmin. La implementación se explica en Configurar de forma segura Device Access y Local Service ACL.
• MFA y Audit Trail: MFA añade protección a la contraseña. Audit Trail ayuda a atribuir los cambios compatibles a una identidad, un origen y una consola. Para Data Anonymization en logs e informes se preparan además al menos dos autorizadores personales con cuentas separadas.

Un perfil Read-only, por ejemplo, no protege contra el robo de contraseñas. MFA, a su vez, no impide que se ataque una página de acceso expuesta innecesariamente a Internet. Solo la combinación reduce tanto los permisos como la superficie de ataque.

Los avisos de inicio de sesión y los mensajes personalizados solo añaden notificaciones visibles a estas capas. La aceptación no amplía ni el perfil de Device Access ni la autorización de red y no sustituye ninguno de los cinco controles.

Administrador predeterminado, cuentas locales e identidades centrales

El usuario predeterminado admin tiene los permisos del perfil integrado Administrator. Es adecuado como acceso local de emergencia, pero no como cuenta diaria compartida. Su contraseña, MFA, acceso por consola y procedimiento de recuperación deben estar documentados y probados de forma independiente a las cuentas personales.

Los administradores locales personales son adecuados para equipos pequeños, firewalls aislados y como alternativa de acceso deliberada. Los equipos más grandes pueden gestionar roles administrativos mediante Microsoft Entra ID SSO para WebAdmin, TACACS+ con asignación local de perfiles o roles de administración de Sophos Central. Un usuario marcado como Managed by Central en Authentication > Users se administra en Central y no se puede editar localmente.

Las automatizaciones no reciben una cuenta personal de uso diario. Para la API XML se utiliza una cuenta de servicio independiente, con responsable propio, permisos limitados y un origen permitido fijo. Asegurar el acceso a la API XML de Sophos Firewall describe todo el proceso de protección.

Planificar el perfil Device Access

Sophos proporciona varios perfiles estándar no editables en Profiles > Device access:

• Administrator: Acceso completo a WebAdmin y a la API. Sophos también describe el perfil con acceso completo a la CLI; no obstante, el acceso SSH directo en SFOS solo admite el nombre de usuario predeterminado admin.
• Audit admin: Acceso de lectura y escritura a logs e informes.
• Crypto admin: Acceso de lectura y escritura a certificados de seguridad.
• HAProfile: Acceso Read-only a la Auxiliary Appliance de un clúster HA.
• Security admin: Acceso de escritura a las funciones, excepto perfiles, logs e informes.

Estos perfiles son puntos de partida útiles, pero no constituyen automáticamente el rol correcto para cada entorno. Un perfil propio resulta más adecuado cuando una persona solo necesita un área de responsabilidad claramente limitada.

Derivar los permisos de la tarea

El nombre del perfil no tiene ningún efecto técnico por sí solo. Un perfil llamado ReadOnly puede seguir conteniendo permisos de escritura. Lo decisivo es toda la matriz de permisos, incluidos los submenús desplegados.

Por ejemplo, una cuenta de Help Desk puede planificarse así:

• Establecer en Read-only el diagnóstico, los logs y las áreas de configuración necesarias para el soporte.
• Conceder Read-write solo si el equipo debe realizar por sí mismo un cambio definido expresamente.
• Dejar en None los perfiles de administrador, los certificados y todas las áreas de producto que no se necesiten.
• Para cada permiso de escritura, definir un ejemplo de lo que debe estar permitido y otro de lo que debe quedar expresamente prohibido.

Un perfil de operaciones de red puede leer más áreas y modificar, por ejemplo, determinadas funciones de red. Aun así, no necesita acceso completo a administradores, certificados u otras funciones de seguridad independientes. El mínimo privilegio no significa mostrar el menor número posible de menús, sino conceder exactamente los derechos necesarios para la tarea asignada.

Crear un perfil propio

1. Abrir Profiles > Device access.
2. Seleccionar Add.
3. Introducir un nombre inequívoco, por ejemplo SFOS-NOC-Limited.
4. Elegir None, Read-only o Read-write para cada menú visible.
5. Utilizar Expand para abrir los submenús y limitar con mayor precisión los permisos diferentes.
6. Guardar con Save.
7. Volver a comprobar el perfil con las tareas y pruebas negativas documentadas.

SFOS-NOC-Limited es solo un nombre de ejemplo. Debe adaptarse al equipo y a la tarea. Además, hay que documentar los permisos realmente asignados, porque el nombre no explica la matriz de autorizaciones.

Crear un administrador local personal

Introducir los datos del usuario

1. Abrir Authentication > Users.
2. Seleccionar Add.
3. En Username, introducir un nombre personal permanente, por ejemplo m.mueller. El nombre de usuario no se puede modificar posteriormente.
4. Introducir un nombre para mostrar claro y la dirección de correo corporativa.
5. Establecer User type en Administrator.
6. En Profile, seleccionar el perfil SFOS-NOC-Limited comprobado previamente.
7. Establecer una contraseña larga y exclusiva, y entregarla de forma segura. Si el firewall detecta una contraseña utilizada con frecuencia o una palabra de diccionario, exige una contraseña más segura.

m.mueller es un ejemplo y debe sustituirse por la identidad inequívoca de la persona responsable. Los nombres funcionales como noc-admin solo deberían utilizarse si representan realmente una única identidad técnica con su propio responsable. Varias personas no deben compartir una contraseña.

Limitar el horario y el origen de acceso

En Administrator advanced settings hay dos controles adicionales:

• Schedule for device access: Permite iniciar sesión en WebAdmin solo durante el horario seleccionado. Es adecuado para soporte temporal u horarios de operación definidos. En un servicio de guardia, el horario no debe bloquear accidentalmente intervenciones de emergencia necesarias.
• Login restriction for device access: Permite iniciar sesión en WebAdmin solo desde direcciones IPv4 seleccionadas o un rango IPv4. Para un jump host administrativo, por ejemplo, puede utilizarse 10.20.30.25 como Selected node.

La dirección 10.20.30.25 es un ejemplo de una red privada. Debe sustituirse por la dirección fija del jump host o puesto de gestión correspondiente. Si las direcciones de cliente cambian, una VPN administrativa o una red de gestión dedicada suele ser más limpia que un rango IP amplio.

Access Time para usuarios y grupos normales controla el acceso a internet; para WebAdmin es relevante Schedule for device access en Administrator advanced settings. No son la misma opción.

Mantener disponible la autenticación local

En Authentication > Services > Administrator authentication methods, la base de datos local debe estar seleccionada para los administradores locales personales. El superadministrador predeterminado admin está excluido de esta lista de métodos, pero los administradores locales recién creados no.

No se debe eliminar el método local antes de probar correctamente la cuenta nueva en otro navegador. Con servidores de autenticación externos, el orden determina a dónde se envía primero un intento de acceso. Por eso, los cambios de orden deben formar parte del mismo plan de aceptación y reversión que la propia cuenta.

Proteger MFA y restringir el acceso

MFA debería activarse para los administradores interactivos. Los administradores personales se añaden en Authentication > Multi-factor authentication para Web admin console. Para el usuario predeterminado admin existe un ajuste independiente en Administration > Device access > MFA for default admin. Activar MFA para WebAdmin de Sophos Firewall explica el grupo piloto, el registro de tokens, Login Security y la recuperación. MFA se prueba primero con un solo administrador nuevo, no con todas las cuentas a la vez.

WebAdmin también se mantiene limitado a redes de gestión, VPN u orígenes definidos de forma estricta. Una Login restriction for device access activa no hace segura una autorización WAN amplia. Del mismo modo, una Local Service ACL no sustituye a la cuenta personal ni a su perfil de permisos.

Una prueba correcta de WebAdmin no habilita SSH. SFOS solo admite el nombre de usuario admin para el acceso SSH directo; por eso, un administrador local personal de WebAdmin no se prueba como cuenta SSH. SSH también requiere una decisión específica en Device Access. La gestión de claves públicas del administrador predeterminado y el acceso SSH seguro se tratan aparte en Conectarse a Sophos Firewall mediante SSH.

En Administration > Admin and user settings, Administrator password complexity, el tiempo de espera de sesión y Block login complementan los ajustes de la cuenta. Estos valores se aplican a todo el sistema y, por tanto, no deben endurecerse agresivamente por una sola cuenta. En especial, Block login puede bloquear la IP de origen para todos los servicios de acceso después de varios intentos fallidos; antes de probarlo debe existir un segundo origen de gestión o acceso por consola.

Probar de forma segura los permisos y el acceso

Durante la prueba se mantienen disponibles la ventana de administración existente y una vía de recuperación independiente. No conviene provocar varios accesos fallidos, porque Block login puede bloquear temporalmente la IP de origen compartida para otros servicios de acceso.

1. Abrir una ventana privada del navegador y acceder a WebAdmin mediante el FQDN previsto desde la red de gestión permitida.
2. Iniciar sesión con la cuenta nueva y MFA.
3. Comprobar que todos los menús necesarios están visibles y que se puede consultar la información prevista.
4. Si el perfil contiene permisos de escritura, realizar un cambio de prueba inocuo y autorizado previamente, con una reversión inmediata.
5. Abrir un área configurada como None o Read-only. La cuenta no debe poder guardar allí un cambio prohibido.
6. Probar una sola vez un acceso controlado desde un origen no permitido. Si el resultado no está claro, evaluar primero los ajustes y logs en lugar de generar más intentos fallidos.
7. Comprobar el cambio de prueba y el administrador utilizado en Configuration Audit Trail. No todos los objetos generan el mismo nivel de detalle; también hay que verificar el efecto técnico en la función afectada.
8. Cerrar sesión, volver a iniciarla y solo entonces migrar la siguiente cuenta.

En un clúster HA, después de un failover planificado también se prueba un nuevo inicio de sesión en el nodo que ahora está activo. Una sesión WebAdmin existente o su continuación sin interrupciones no es un criterio fiable de éxito.

Un menú visible no demuestra que el permiso de escritura funcione. Un menú oculto tampoco demuestra que las demás funciones asignadas sean correctas. Por eso, la prueba positiva, la prueba negativa y la atribución en auditoría deben realizarse juntas.

Revisar y eliminar cuentas de forma segura

Los accesos administrativos se revisan periódicamente respecto a su responsable, tarea, perfil, MFA, origen de acceso y último uso. Las cuentas de soporte temporales también requieren una fecha de finalización documentada. Para un caso temporal de Avanet se aplica el procedimiento específico Configurar un acceso de soporte de Avanet en Sophos Firewall.

En el offboarding, un proceso controlado es más seguro que la eliminación inmediata:

1. Comprobar si la cuenta se utiliza en scripts de API, almacenes de contraseñas, documentación o procesos de soporte.
2. En Authentication > Users, establecer el estado como inactivo.
3. Comprobar en una ventana privada del navegador que ya no es posible iniciar una sesión nueva.
4. Revisar por separado las sesiones WebAdmin activas y los cambios recientes. La desactivación no debe considerarse una prueba de que todas las sesiones existentes hayan terminado inmediatamente.
5. Eliminar o rotar los tokens MFA, secretos y asignaciones externas asociados a la cuenta.
6. Tras el periodo de observación acordado, eliminar al usuario si ya no existe ninguna dependencia.
7. Eliminar un perfil personalizado que ya no se necesite solo cuando no esté asignado a ningún administrador.

El administrador predeterminado queda fuera de este proceso normal de offboarding. Si se pierde su contraseña o acceso MFA, Restablecer la contraseña de administrador de Sophos Firewall ayuda a preparar la vía de recuperación.

Delimitar problemas habituales

La cuenta existe, pero falla el acceso a WebAdmin

Comprobar estos puntos en orden:

• User type está realmente establecido en Administrator.
• El estado del usuario está activo y la contraseña es correcta.
• Local está seleccionado en Administrator authentication methods.
• Schedule for device access permite el momento actual.
• Login restriction for device access contiene la dirección IPv4 de origen real.
• El token MFA, la hora del sistema y el registro son correctos.
• Block login no ha bloqueado la IP de origen después de intentos fallidos.
• Device Access o una Local Service ACL permite HTTPS desde este origen.

Si la página de acceso no se puede abrir, el análisis comienza por Device Access, routing y la dirección de origen. Si se puede abrir, pero solo rechaza esta cuenta, las pistas más cercanas son el usuario, el perfil, el método de autenticación, Schedule, Login Restriction y MFA.

Para la correlación temporal resultan útiles el área Authentication de Log Viewer y access_server.log para autenticación y autorización. syslog.log añade eventos del sistema y eventos provocados por administradores. Los cambios en objetos compatibles se comprueban por separado en configuration-audit.log.

La cuenta ve demasiado o demasiado poco

Comprobar el perfil asignado y sus submenús desplegados. Read-only y Read-write pueden configurarse de forma diferente dentro de un menú principal. Después, volver a probar con una sesión nueva y no confiar únicamente en el nombre del perfil.

Con Managed by Central, el rol procede de Sophos Central y no se modifica en el usuario local. Con Entra SSO, la asignación de roles o grupos del servidor Entra determina el perfil Device Access local.

WebAdmin funciona, pero la API o SSH no

El perfil Device Access también se aplica a los permisos de API, pero la API necesita además que el acceso API esté activado y que el origen esté permitido. SSH es un servicio local independiente y no constituye una prueba adecuada para un perfil WebAdmin restringido. Una cuenta no obtiene acceso SSH simplemente porque funcione el acceso a WebAdmin.

Lista de comprobación operativa

• El administrador predeterminado y la vía de recuperación están probados y no se comparten.
• Cada persona utiliza su propia cuenta.
• Los perfiles derivan de las tareas y se han revisado los submenús desplegados.
• El acceso completo se limita al grupo mínimo imprescindible.
• MFA, Schedule y el origen de acceso son adecuados para el uso previsto.
• Solo se puede acceder a WebAdmin desde los orígenes de gestión previstos.
• Se han realizado pruebas positivas y negativas de permisos.
• Cuando existe compatibilidad, los cambios se pueden atribuir a una cuenta personal en Audit Trail.
• Las cuentas de API y soporte tienen sus propios responsables y ciclos de vida.
• El offboarding incluye estado, sesiones, MFA, secretos y dependencias.

FAQ