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, colaboradores externos concretos o un acceso alternativo mantenido de forma deliberada. Sin embargo, crear la cuenta no concede acceso por sí solo. El grupo, el método de autenticación, el portal o cliente, la política de firewall o VPN y la posterior comprobación deben encajar entre sí.

El procedimiento seguro y breve es el siguiente:

1. Definir el caso de uso, el grupo objetivo 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. Por ello, antes de guardar se definen el esquema de nombres, el tipo de cuenta y la responsabilidad. Una cuenta nueva con otro nombre crea una identidad nueva y puede separar reglas, cuotas, asignaciones VPN, logs 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 de forma consciente. 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;
• un acceso alternativo documentado cuando una fuente externa de usuarios no está disponible temporalmente.

No se recomienda una cuenta local compartida por varias personas. Las credenciales compartidas dificultan los cambios de contraseña, MFA, las cuotas, la auditoría y una baja limpia.

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.

Planificar el ejemplo y los 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 10.20.30.0/24.

example.com es un dominio reservado para documentación; 10.20.30.0/24 solo se utiliza aquí como red privada de ejemplo. El nombre de usuario, la dirección de correo, el grupo, la regla y la red se sustituyen por valores del entorno real. El nombre de usuario es deliberadamente neutro y no contiene una dirección de correo, para que un cambio posterior de correo no modifique la identidad de inicio de sesión. En producción, el esquema de nombres debería encajar con el soporte técnico, el proceso de baja y los nombres existentes 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. Introducir pilotuser01 en Username.
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. En Email, introducir pilotuser01@example.com o la dirección real responsable.
6. En Group, seleccionar Local_Pilot_Users.
7. Cambiar los campos de política y Remote Access solo cuando se pretenda una excepción de usuario documentada.
8. Definir de forma adecuada Simultaneous sign-ins y Sign-in restriction.
9. Guardar con Save.

SFOS rechaza contraseñas de uso frecuente y palabras detectadas por su comprobación de diccionario. El artículo no muestra deliberadamente una contraseña de ejemplo. Una contraseña copiable en una documentación se convertiría inmediatamente en un secreto conocido y no sería una plantilla segura.

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 se asigna una política que ya se comprende.

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 un usuario personal normal 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.

En el ejemplo se utiliza la red real de administración, usuarios o VPN, no se copia sin más 10.20.30.0/24. Una selección demasiado estrecha bloquea inicios de sesión legítimos. Any node, en cambio, solo amplía el posible origen del inicio de sesión y no sustituye una regla de firewall, una ACL de portal ni 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 realmente la base de datos local. Por ello, en Authentication > Services se selecciona Local para el servicio previsto.

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.

El portal, la regla o la política VPN siguen siendo independientes

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.

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 log de firewall o VPN la regla o política esperada.
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 falla la base de datos local, la selección del servicio, el estado del usuario, el grupo o la regla posterior, solucionar sistemáticamente los errores de autenticación de Sophos Firewall ofrece la secuencia completa. Para un análisis más profundo, /log/access_server.log contiene eventos de autenticación, autorización y contabilidad; Log Viewer sigue siendo el primer paso.

Gestionar contraseñas, MFA y uso

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. User Portal solo se hace accesible desde las zonas necesarias y no se abre de forma general a WAN solo para gestionar contraseñas.

Para una protección adicional, se puede seleccionar 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 hash, el acceso al portal, la recuperación y la fase piloto. MFA solo se activa cuando funcionan el inicio de sesión normal y la vía 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 reinicia los contadores de Surfing y Network Traffic y, por tanto, no se utiliza como solución general para problemas de inicio de sesión.

Desactivar y eliminar la cuenta de forma segura

Cuando una persona deja la organización o termina la finalidad de la cuenta, no se elimina inmediatamente sin revisar:

1. Comprobar dependencias en reglas, grupos, políticas de Remote Access, cuotas, MFA y documentación.
2. En Authentication > Users, seleccionar el usuario y usar Change status para ponerlo inactivo.
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. Revisar los logs de firewall y VPN para detectar nuevos intentos o tráfico residual.
6. Eliminar la cuenta solo después de resolver las dependencias o mantenerla inactiva según el proceso de conservación.

La desactivación no se trata como garantía de finalización automática de todas las conexiones existentes. Las sesiones, túneles y el tráfico se comprueban por separado. Tras una reactivación se repiten las pruebas positivas y negativas.

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 por sospecha.

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 haber capturado ya el flujo.

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. Solo se devuelve un valor a la herencia del grupo tras compararlo 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

• El caso de uso, el responsable y la fecha de caducidad de la cuenta están documentados.
• El nombre de usuario y el tipo de usuario se eligieron conscientemente antes de guardar.
• Un grupo de tipo Normal contiene la configuración común.
• Las excepciones de usuario se evitan o están justificadas.
• Simultaneous sign-ins y Sign-in restriction son adecuados para el caso de uso.
• Local está seleccionado para cada servicio de autenticación necesario.
• El portal, la regla de firewall o la política VPN se configuraron por separado.
• Se comprobaron los inicios de sesión positivo y negativo, así como el tráfico real.
• Live Users, Authentication Log y la regla o política esperada coinciden.
• MFA y la recuperación se han probado si se utiliza MFA.
• Una persona responsable se ocupa de los cambios de contraseña, el uso y la baja.
• La desactivación, las sesiones existentes y la eliminación posterior son pasos separados.

Preguntas frecuentes