Crear y gestionar usuarios locales en Sophos Firewall

Un usuario local se guarda directamente en Sophos Firewall y se autentica con la base de datos local de usuarios. Es adecuado para entornos pequeños, cuentas piloto y colaboradores externos concretos. Una cuenta local solo resulta apropiada como alternativa a un servicio de directorio si se han probado, para ese servicio, el orden de los servidores, un nombre de usuario distinto, el acceso al portal y el comportamiento cuando falla la fuente externa. La ayuda de SFOS documenta el orden de los servidores, pero no garantiza la conmutación para todos los tipos de error.

Este artículo se aplica a la interfaz WebAdmin de SFOS 22. La mera creación de un usuario no le concede acceso. El grupo, el método de autenticación, el portal o cliente y la política de firewall o VPN deben configurarse de forma coherente.

Flujo de trabajo rápido:

1. Definir el caso de uso, los usuarios destinatarios y el servicio necesario.
2. Preparar un grupo restrictivo de tipo Normal en Authentication > Groups.
3. En Authentication > Users > Add, introducir un nombre de usuario permanente y seleccionar User type: User.
4. Asignar una contraseña individual y robusta, así como el grupo correcto.
5. Dejar sin cambios los campos de política del usuario si deben aplicarse los valores del grupo.
6. Limitar conscientemente Simultaneous sign-ins y Sign-in restriction.
7. En Authentication > Services, comprobar que Local esté seleccionado para el servicio utilizado.
8. Configurar por separado y con el menor alcance posible el portal, la regla de usuario o la política de acceso remoto.
9. Probar con una cuenta piloto un inicio de sesión positivo, uno negativo y tráfico real.
10. Solo entonces activar MFA, crear más usuarios y documentar la baja.

⚠️ El nombre de usuario no se puede cambiar posteriormente. Defina el esquema de nombres, el tipo de cuenta y el responsable antes de guardar. SFOS convierte en minúsculas las letras mayúsculas del nombre de usuario. Una cuenta de sustitución tiene una identidad nueva; por tanto, vuelva a comprobar sus reglas, cuotas, asignaciones VPN y trazas de auditoría.

Cuándo es adecuado un usuario local

Los usuarios locales no requieren Active Directory ni un servidor RADIUS o LDAP externo. Esto simplifica la puesta en marcha, pero traslada por completo al firewall la gestión de contraseñas, MFA, grupos, desactivación y revisiones. Resulta práctico para unas pocas cuentas administradas cuidadosamente. Para muchos empleados o altas y bajas frecuentes, un directorio central suele ser más fácil de mantener.

Un usuario local normal es adecuado, por ejemplo, para:

• una cuenta piloto para Captive Portal, User Portal o Remote Access;
• un entorno pequeño sin servicio de directorio;
• un proveedor externo concreto con una duración y una responsabilidad claras;
• una alternativa de emergencia probada, con un nombre de usuario distinto, cuando una fuente de autenticación externa no está disponible temporalmente.

No utilice una cuenta local para varias personas. Las credenciales compartidas dificultan los cambios de contraseña, el uso de MFA, la gestión de cuotas, la auditoría y una baja ordenada.

No mezclar los tipos de usuario

SFOS ofrece varios tipos de usuario similares que resuelven tareas diferentes:

• Un usuario local normal inicia sesión con nombre de usuario y contraseña y recibe políticas mediante un grupo normal o mediante excepciones deliberadas a nivel de usuario.
• Un usuario invitado tiene una duración limitada, utiliza la configuración de Guest User y se usa normalmente mediante Captive Portal.
• Un Clientless User se identifica por una dirección IP y no realiza un inicio de sesión interactivo.
• Un administrador local recibe User type: Administrator y un perfil de Device Access para permisos de WebAdmin.
• Un usuario de AD, LDAP, RADIUS o Entra se autentica mediante una fuente externa. Según el método, su registro local no se crea hasta el primer inicio de sesión correcto.

Para una persona que deba iniciar sesión en Captive Portal o en un servicio VPN se utiliza User type: User. Esta cuenta no recibe por ello acceso a WebAdmin ni a SSH.

Ejemplo y requisitos

El siguiente ejemplo utiliza:

• nombre de usuario pilotuser01;
• nombre visible Local Pilot User;
• dirección de correo pilotuser01@example.com;
• grupo Local_Pilot_Users;
• regla de firewall Local-Pilot-to-WAN;
• origen de inicio de sesión permitido desde 10.20.30.10 hasta 10.20.30.50.

example.com es un dominio reservado para documentación; el intervalo de direcciones pertenece a una red privada utilizada como ejemplo. Sustituya el nombre de usuario, la dirección de correo electrónico, el grupo, la regla y las direcciones por los valores de su entorno. El nombre de usuario, deliberadamente neutro respecto a la función, no contiene ninguna dirección de correo electrónico y, por tanto, sigue siendo válido si esta cambia. El esquema de nombres debe ser coherente con los procesos del servicio de asistencia y de baja, así como con los nombres ya utilizados en el directorio.

Antes de crear la cuenta se aclara lo siguiente:

• ¿Qué servicio autentica al usuario: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec u otro acceso compatible?
• ¿Qué grupo normal contiene la configuración común?
• ¿Qué política de firewall o Remote Access permite el acceso posterior?
• ¿Desde qué direcciones IPv4 puede iniciar sesión la cuenta?
• ¿Cuántos inicios de sesión simultáneos se necesitan realmente?
• ¿Se exige MFA local y mediante qué portal se hará el registro inicial?
• ¿Quién desactiva la cuenta y comprueba las sesiones existentes al darla de baja?

Gestionar grupos de usuarios y el Main Group en Sophos Firewall explica la lógica común de grupos. Para usuarios locales normales se utiliza un grupo de tipo Normal. Un grupo de tipo Clientless pertenece al modelo basado en IP y no es la base adecuada para este proceso de inicio de sesión.

Crear el usuario local

La cuenta se crea en Authentication > Users > Add:

1. Introduzca pilotuser01 en Username. SFOS almacena el valor en minúsculas y este no se puede modificar posteriormente.
2. Introducir Local Pilot User en Name.
3. Establecer User type en User.
4. Introducir y confirmar una contraseña larga e individual procedente del proceso de contraseñas previsto.
5. Para Email, introduzca pilotuser01@example.com o el buzón de correo de esta persona. Para una cuenta técnica, utilice una dirección monitorizada con un responsable claramente designado.
6. En Group, seleccionar Local_Pilot_Users.
7. Cambiar Quarantine digest, los campos de políticas y los campos de Remote Access únicamente cuando se necesite la función correspondiente o una excepción de usuario documentada.
8. Definir de forma adecuada Simultaneous sign-ins y Sign-in restriction.
9. Guardar con Save.

SFOS rechaza las contraseñas de uso común y las palabras detectadas por su comprobación de diccionario. Utilice para cada cuenta una contraseña larga y única generada conforme a su proceso de gestión de contraseñas. Una contraseña de ejemplo que pudiera copiarse directamente se convertiría de inmediato en un secreto conocido y, por tanto, no sería un modelo seguro.

Valores del grupo o excepciones de usuario

En el usuario se pueden definir Surfing quota, Access time, Network traffic y Traffic shaping, además de varios campos de Remote Access. Los valores específicos del usuario tienen prioridad sobre los del grupo. Si el grupo debe seguir siendo la base fácil de mantener, estos campos no se sobrescriben de forma preventiva.

Una excepción de usuario es adecuada para un caso claramente documentado, por ejemplo un Access Time más restrictivo durante una intervención temporal. Se registra:

• qué campo difiere del valor del grupo;
• por qué es necesaria la excepción;
• cuándo se revisará o eliminará;
• cómo volverá a aplicarse el valor original del grupo.

Access Time para usuarios y cuotas de Surfing y Network Traffic explican por completo cada política. En el objeto de usuario solo debe asignarse una política cuyo funcionamiento ya se conozca.

Limitar el número y el origen de los inicios de sesión

Simultaneous sign-ins limita las sesiones paralelas. Global setting adopta el valor para nuevos usuarios definido en Authentication > Services. También se puede establecer un valor propio o elegir Unlimited. Las sesiones ilimitadas rara vez son necesarias para una cuenta individual estándar y dificultan detectar credenciales compartidas.

Sign-in restriction limita las direcciones IPv4 desde las que el usuario puede iniciar sesión:

• Any node: permitir el inicio de sesión desde cualquier origen accesible;
• User group nodes: heredar el valor del grupo;
• Selected nodes: indicar direcciones IPv4 concretas previstas;
• Node range: permitir un intervalo IPv4 contiguo.

Para este ejemplo, seleccione Node range e introduzca 10.20.30.10 como dirección inicial y 10.20.30.50 como dirección final. Sustituya ambos valores por el intervalo contiguo más pequeño desde el que el usuario inicia sesión realmente. Si necesita direcciones IPv4 individuales no contiguas, utilice Selected nodes. Una selección demasiado restrictiva bloquea inicios de sesión legítimos; Any node no sustituye una regla de firewall, una ACL del portal ni la MFA.

No se activa MAC binding en este procedimiento básico. Es compatible con la autenticación basada en cliente, pero no con Remote Access VPN ni Captive Portal. Si se activa sin indicar una dirección MAC, SFOS vincula automáticamente la primera dirección MAC detectada en el primer inicio de sesión. En dispositivos móviles, tras un cambio de Wi-Fi o con clientes compartidos, esto puede convertirse rápidamente en una dependencia inesperada.

Conectar el método de autenticación y el acceso

Un usuario guardado solo puede iniciar sesión en un servicio que consulte la base de datos local. En Authentication > Services, active el método Local en la lista correspondiente al servicio utilizado.

Las áreas están separadas:

• Firewall authentication methods para tráfico de firewall y Captive Portal;
• User portal authentication methods para User Portal;
• VPN portal authentication methods para VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estos métodos VPN;
• SSL VPN authentication methods para Remote Access SSL VPN.

Cuando hay varias fuentes, se consultan en el orden mostrado. Por tanto, una prueba correcta en User Portal no demuestra automáticamente que el mismo usuario esté configurado correctamente para SSL VPN o IPsec.

Puede seleccionar hasta 20 servidores por método de autenticación. Para User Portal y VPN Portal, la opción de herencia es Set authentication methods same as firewall. Para SSL VPN, SFOS muestra Same as VPN o Same as firewall, según la referencia seleccionada. Compruebe esta opción y el orden resultante antes de añadir o mover Local.

Configurar el acceso por separado

La identidad local no abre una ruta de red. Captive Portal requiere además Device Access, Web Authentication y una regla de usuario adecuada. El procedimiento completo se explica en Configurar y probar Captive Portal en Sophos Firewall.

User Portal y VPN Portal también son servicios independientes. El modelo de portales de Sophos Firewall explica puertos, finalidad, Device Access y límites WAN. Las políticas de Remote Access se mantienen en las guías VPN correspondientes y no se consideran terminadas solo porque haya un campo definido en el objeto de usuario.

Interpretar correctamente los campos de Remote Access

En los métodos de Remote Access distintos de SSL VPN, los valores de política específicos del usuario prevalecen sobre el grupo. SSL VPN sigue otra lógica: El usuario recibe los recursos de todas las políticas Full y Split Tunnel en las que figure directamente o mediante uno de sus grupos compatibles. Por tanto, el campo SSL VPN policy no sustituye de forma simple las políticas de grupo.

SSL VPN IP address solo aparece cuando las direcciones estáticas están activadas en SSL VPN global settings. La dirección IPv4 o IPv6 debe estar libre y pertenecer al rango estático creado automáticamente en esa sección. Si un servidor RADIUS asigna direcciones, su asignación tiene prioridad. IPsec remote access, en cambio, activa el acceso mediante Sophos Connect y puede recibir una dirección propia asignada.

L2TP y PPTP son métodos heredados. Tras la asignación, el usuario debe iniciar sesión primero en VPN Portal y crear una contraseña antes de poder conectarse. La valoración actual y la ruta de migración de L2TP se explican en L2TP Remote Access; PPTP no debe planificarse para nuevos accesos. Clientless SSL VPN policy solo abre los bookmarks de navegador asignados y no es un túnel completo. El procedimiento independiente está en Clientless Access.

Para una regla de firewall basada en usuarios, se definen con el menor alcance posible el origen, el destino, el servicio y el usuario o grupo. Log firewall traffic permanece activo durante la validación. Los fundamentos se explican en Comprender y configurar de forma segura las reglas de Sophos Firewall.

Validar con pruebas positivas y negativas

Una cuenta visible con estado Active todavía no demuestra que todo funcione. El piloto se prueba mediante el mismo servicio que se utilizará después:

1. Iniciar sesión con pilotuser01 en una ventana privada del navegador o desde un cliente de prueba limpio.
2. En Current activities > Live users, comprobar el nombre de usuario, la IP de origen y el Client Type.
3. En Log Viewer > Authentication, comprobar el inicio de sesión correcto, la autenticación local y la hora.
4. Generar el tráfico previsto y comprobar en el registro del firewall o de la VPN que Local-Pilot-to-WAN, o su Firewall Rule ID, corresponde a la regla aplicada.
5. Utilizar como prueba negativa un origen o una función expresamente no permitidos.
6. Si hay una cuota o un Access Time activo, probar su efecto por separado dentro y fuera del límite.
7. Documentar el resultado, el grupo utilizado, las excepciones de usuario y el método de autenticación.

Una prueba negativa no debería fallar únicamente porque se haya utilizado a propósito una contraseña incorrecta. También se comprueba que un origen no autorizado, un usuario sin el grupo adecuado o una función no prevista no obtengan acceso. Así se separa la validación de la contraseña del efecto de las políticas y reglas.

Si no está claro si el error se debe al estado del usuario, al método de autenticación, al grupo o a la regla de acceso, Solucionar sistemáticamente los errores de autenticación de Sophos Firewall describe la secuencia de comprobaciones. Para un análisis detallado, /log/access_server.log contiene eventos de autenticación, autorización y contabilización; Log Viewer sigue siendo el primer paso.

Administrar contraseñas, MFA y el uso

Para cambiar como administrador la contraseña de una cuenta local existente en SFOS 22 y 23, se abre el usuario correspondiente en Authentication > Users y se hace clic en Change password. Antes se comprueban la cuenta y su responsable, y se prepara una contraseña nueva, larga y única mediante el proceso de contraseñas aprobado. Se introduce la nueva contraseña, se guarda el cambio y se entrega el secreto de forma segura a la persona autorizada. Después se prueba un nuevo inicio de sesión con la nueva contraseña en el servicio que se utiliza realmente. Esta operación de WebAdmin es distinta del autoservicio en User Portal; las cuentas autenticadas externamente siguen gestionándose en su fuente de usuarios correspondiente. Esto no garantiza que las sesiones existentes finalicen automáticamente.

Un usuario local puede cambiar su contraseña en User Portal > Personal > Change Password. Esto se aplica a la base de datos local, no a cuentas de AD, LDAP o RADIUS autenticadas externamente. En Personal > Personal Details, el usuario también puede cambiar su nombre visible. El nombre de usuario y la dirección de correo permanecen en modo de solo lectura y los mantiene el administrador en el objeto de usuario. User Portal solo se hace accesible desde las zonas necesarias y no se abre de forma general a WAN solo para este mantenimiento.

Para obtener una protección adicional, seleccione la cuenta en Authentication > Multi-factor authentication. Con Generate OTP token with next sign-in, el usuario registra el token mediante User Portal o VPN Portal. MFA para Sophos Firewall explica el algoritmo de hash, el acceso al portal, la recuperación y el despliegue piloto. Active MFA únicamente después de probar el inicio de sesión normal y el procedimiento de recuperación.

En Authentication > Users > > View usage se muestran las cuotas asignadas, el tiempo de Surfing y el consumo de datos. Para ello, el tráfico debe coincidir con una regla de firewall basada en usuarios que tenga Log firewall traffic. Reset user accounting pone a cero los contadores de Surfing y Network Traffic y, por tanto, no se utiliza como solución general para problemas de inicio de sesión.

Revertir el cambio y eliminar la cuenta

Antes de la fase piloto, documente el orden existente en Authentication > Services y todos los ajustes modificados de grupos, portales, reglas y VPN. De este modo, la reversión no dependerá de valores predeterminados supuestos. Cuando una persona cause baja, falle el piloto o deje de ser necesaria la cuenta, proceda en orden inverso:

1. Comprobar dependencias en reglas, grupos, políticas de Remote Access, cuotas, MFA y documentación.
2. En Authentication > Users, seleccionar al usuario y establecer Change status en Inactive.
3. Intentar un nuevo inicio de sesión como prueba negativa.
4. En Current activities > Live users, comprobar las sesiones existentes y usar Disconnect para un usuario normal cuando sea necesario.
5. Eliminar al usuario de reglas de cortafuegos y políticas de acceso remoto, o restaurar la selección previa documentada.
6. Restaurar exactamente el estado anterior documentado de los ajustes modificados de grupos, portales y servicios de autenticación.
7. Comprobar los registros del firewall, de la VPN y de configuración para detectar nuevos intentos, tráfico residual y las modificaciones realizadas.
8. Eliminar la cuenta únicamente después de resolver las dependencias, o mantenerla inactiva conforme al proceso de conservación.

La ayuda de SFOS no confirma que la desactivación finalice todas las conexiones existentes. Compruebe y desconecte por separado las sesiones y los túneles. Después de una reactivación, repita las pruebas positivas y negativas.

Antes de una eliminación arriesgada, puede exportar el objeto de configuración User con Include dependent entity en Backup and firmware > Import export. La exportación contiene datos confidenciales, incluidas contraseñas, y debe cifrarse y almacenarse en una ubicación con acceso controlado. La Secure Storage Master Key correcta también debe estar disponible para una importación posterior. Una importación actualiza la configuración existente y aplica los valores importados cuando hay elementos que se solapan. Por tanto, también pueden sobrescribirse las dependencias compartidas exportadas junto con el objeto. Revise el contenido y las consecuencias antes de importar, preferiblemente en un entorno de prueba adecuado.

Una copia de seguridad completa no permite revertir rápidamente un solo usuario: una restauración sustituye toda la configuración, reinicia el firewall y descarta los cambios posteriores. El proceso se explica en Copia de seguridad y restauración en Sophos Firewall.

En un clúster HA, realice el cambio en el nodo principal y compruebe después el estado de sincronización. Los registros y los informes no se sincronizan entre los nodos y deben examinarse por separado durante el diagnóstico.

Los usuarios y grupos comparten identificadores internos. Una gran cantidad de objetos por sí sola no demuestra un problema. Sin embargo, si un usuario muestra una User ID superior a 65535 y no se autentica, se utiliza el procedimiento específico para el límite de User ID de Sophos Firewall, en lugar de cambiar contraseñas o reglas sin pruebas.

Delimitar errores según el síntoma

Se rechazan el nombre de usuario y la contraseña

En Authentication > Users, comprobar que la cuenta sea local, esté activa y tenga el nombre de usuario esperado. Después, en Authentication > Services, comprobar para el servicio concreto si está seleccionado Local. Un inicio de sesión correcto en otro portal no demuestra esta selección de servicio.

El inicio de sesión funciona, pero la regla de usuario no coincide

En Current activities > Live users, comprobar la identidad, la IP de origen y el Client Type. A continuación, revisar en Log Viewer la posición de la regla, Source Zone, usuario o grupo y Firewall Rule ID. Una regla de red situada por encima de la regla de usuario puede coincidir ya con el tráfico.

Un cambio de grupo no tiene efecto

Buscar en el usuario valores específicos de cuota, Access Time, Traffic Shaping o Remote Access. Estas excepciones tienen prioridad sobre el grupo. Restablecer la herencia del grupo solo después de comparar el valor con la excepción documentada.

El usuario puede iniciar sesión desde un origen inesperado

Comprobar Sign-in restriction tanto en el usuario como en el grupo. Revisar también el servicio utilizado, Device Access y la regla de red. MFA o una regla de firewall restrictiva no compensan automáticamente una configuración Any node.

View usage permanece vacío

Comprobar que el usuario se reconoce como Live User y que el tráfico coincide con una regla basada en usuarios con Log firewall traffic. Después, revisar el periodo, la asignación de cuotas y el tráfico real de prueba. Reset user accounting no genera logs que faltan ni corrige una regla errónea.

Lista de comprobación operativa

• Live users muestra pilotuser01, la dirección IP de origen prevista y el Client Type esperado.
• El registro de autenticación confirma el inicio de sesión local; Local-Pilot-to-WAN o su Firewall Rule ID coincide con el tráfico de prueba.
• Una contraseña incorrecta, fuente no autorizada y función no autorizada proporcionan las pruebas negativas esperadas.
• Las excepciones específicas del usuario, Simultaneous sign-ins, Sign-in restriction y cualquier fecha de vencimiento están documentadas.
• El registro de MFA y el proceso de recuperación se han probado si se utiliza MFA.
• El estado anterior, el responsable, la desactivación, la desconexión de las sesiones y la posterior eliminación están documentados.

Preguntas frecuentes