Crear y gestionar Guest users de forma segura en Sophos Firewall

Los Guest users de Sophos Firewall son cuentas temporales para personas que no tienen una cuenta de usuario normal. Son adecuadas para visitantes, técnicos externos o participantes en una formación que inician sesión a través del Captive Portal y solo deben tener acceso a internet claramente limitado.

El procedimiento rápido y seguro es el siguiente:

1. Preparar un grupo de invitados restrictivo con las políticas necesarias.
2. En Authentication > Guest user settings, definir el prefijo, el grupo, la contraseña y la limpieza.
3. Decidir si un administrador crea cuentas individuales o múltiples, o si el autorregistro por SMS es realmente necesario.
4. Establecer la validez en Immediately o After first login y entregar las credenciales de forma segura.
5. Probar el Captive Portal, la regla de usuario, la separación de red y un destino permitido y otro bloqueado.
6. Desactivar o purgar la cuenta tras su caducidad y comprobar por separado las sesiones existentes y los registros.

⚠️ Una cuenta de invitado es solo una identidad. No separa una red ni abre una ruta de tráfico. Los invitados deben estar en una zona o VLAN propia y recibir una regla de firewall restrictiva y registrada. Las credenciales, impresiones y mensajes SMS deben tratarse como contraseñas.

Distinguir Guest users, vales y usuarios normales

Un Guest user es un registro de usuario local temporal. El firewall genera el nombre de usuario y la contraseña a partir de los ajustes globales de usuarios invitados. Tras el inicio de sesión, puede asociar el tráfico a esta identidad y aplicar las políticas del grupo seleccionado.

Otros modelos de acceso resuelven tareas diferentes:

• Usuario local o externo normal: Adecuado para personas recurrentes con una cuenta permanente, una fuente de usuarios central o MFA. Crear y gestionar usuarios locales normales explica el modelo mantenido directamente en el firewall.
• Guest user: Adecuado para una persona temporal con una cuenta individual, una validez propia y controles de uso opcionales.
• Vale de hotspot: Es un código para un hotspot inalámbrico. La validez, el tiempo en línea, el volumen de datos y el número de dispositivos se gestionan en el modelo de hotspot. La configuración se explica en Hotspot de Sophos Firewall con vales o contraseña del día.
• Clientless User: Asocia una dirección IP fija a un dispositivo sin que una persona inicie sesión. Este procedimiento se explica en Configurar Clientless Users en Sophos Firewall.

Los Guest users no están destinados al acceso remoto SSL VPN ni al acceso remoto IPsec. La política SSL VPN actual no permite Guest users ni Guest groups como Policy members. Para el acceso remoto se utiliza un usuario normal de una fuente local o externa adecuada. La configuración completa se explica en Configurar el acceso remoto SSL VPN.

La antigua página de ayuda de SFOS 22 Edit guest user sigue mostrando campos para políticas de acceso remoto. Sin embargo, las páginas de ayuda más recientes sobre IPsec y SSL VPN excluyen expresamente a Guest users y Guest groups. Por tanto, esos campos antiguos no demuestran que el acceso VPN sea compatible y no deben utilizarse.

Configuración de ejemplo y requisitos

El siguiente ejemplo utiliza una red de invitados separada y una cuenta para una visita de un día:

• Zona: Guest
• Red: 10.30.40.0/24
• Nombre del portal: login.example.com
• Grupo de invitados: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 es una red privada de ejemplo y debe sustituirse por la red de invitados real. login.example.com es un nombre de documentación. Debe sustituirse por un FQDN que, desde la red de invitados, se resuelva a la dirección accesible del firewall y que esté cubierto por el certificado del portal. El grupo recibe únicamente las políticas previstas realmente para este acceso de invitados.

Antes de crear cuentas deben cumplirse estos requisitos:

1. La red de invitados, DHCP, DNS, el enrutamiento y NAT se han verificado con una regla de prueba temporal y estrictamente limitada. Esta regla se elimina antes de probar la autenticación; una regla DNS independiente solo debe permitir el tráfico necesario hacia el resolvedor.
2. Las redes internas y los servicios de administración están bloqueados desde la zona de invitados.
3. El Captive Portal solo es accesible desde la zona prevista.
4. Un grupo propio reúne Access Time, cuotas, Traffic Shaping y Sign-in Restriction.
5. Durante la prueba siguen disponibles una cuenta de administrador y una vía de administración independiente.
6. La emisión, caducidad, revocación y conservación de las credenciales están definidas operativamente.

Definir los ajustes globales de usuarios invitados

Antes de crear la primera cuenta, se abre:

Authentication > Guest user settings

Estos valores sirven de plantilla para las nuevas cuentas de invitado. Por ello, cualquier cambio en la plantilla se prueba primero con una cuenta piloto.

Elegir ajustes generales seguros

En Guest user general settings se definen los siguientes campos:

1. Username prefix: guest- en el ejemplo. Es preferible un prefijo neutro a nombres de empresa, sede o cliente que revelen información innecesaria.
2. Group: Seleccionar Guest_Internet. Los Guest users heredan las políticas de este grupo.
3. Password length: 16 en el ejemplo. Sophos permite un máximo de 50 caracteres tanto para el nombre de usuario como para la contraseña en el Captive Portal. La longitud se elige para que sea suficientemente segura y pueda utilizarse de forma fiable a través del canal de entrega previsto.
4. Password complexity: Seleccionar la opción más robusta que sea compatible con el proceso de entrega e inicio de sesión.
5. Disclaimer: Este texto se imprime debajo de las credenciales generadas. Indicar unas condiciones de uso breves, la responsabilidad y un contacto. No debe contener credenciales reales ni detalles técnicos internos. Configurar el aviso de inicio de sesión y los mensajes en Sophos Firewall explica la gestión global de los textos de administración, autenticación, SMTP y SMS.
6. Auto purge on expiry: Activar solo si los registros de usuario caducados deben eliminarse automáticamente y la evidencia operativa necesaria se conserva en otro lugar.
7. Guardar con Apply.

Auto purge on expiry elimina los datos de los usuarios invitados tras su caducidad, pero no afecta a los registros. Esta distinción es importante para la privacidad y el diagnóstico: la limpieza de cuentas y la conservación de registros son procesos separados.

Gestionar grupos de usuarios de forma segura en Sophos Firewall explica cómo interactúan las políticas de grupo, el Main Group y las excepciones de usuario. El Default Group no debe utilizarse de forma casual para invitados. Un grupo restrictivo propio facilita comprender sus efectos y revertir los cambios.

Activar el autorregistro solo cuando sea realmente necesario

El autorregistro puede activarse en Guest user registration settings. Es más complejo que la entrega controlada por un administrador o una recepción y requiere un proceso SMS fiable:

• Enable guest users registration: Activar solo si los invitados deben registrarse por sí mismos.
• SMS gateway: Seleccionar el proveedor probado previamente.
• Guest username: Utilizar el número de móvil o generar el nombre a partir de Username prefix.
• User validity: Definir la validez máxima de las cuentas autorregistradas.
• Default country code: Elegir un valor adecuado para el grupo real de usuarios.
• CAPTCHA verification: Mantener activado para dificultar los registros automatizados.
• Guardar con Apply.

El firewall admite gateways SMS basados en HTTP y HTTPS. Es preferible utilizar HTTPS para que las credenciales y los parámetros del proveedor no se transmitan sin cifrar. La URL, el método HTTP, el formato del número de móvil, los parámetros de solicitud y el formato de respuesta deben coincidir exactamente con la documentación del proveedor SMS utilizado. Las URL de ejemplo de una guía no deben copiarse a producción.

Test connection envía un mensaje de prueba a un número de móvil. Según Sophos, esta prueba puede fallar con un gateway SMS privado que tenga una dirección IP interna aunque el flujo real funcione. En ese caso no se presupone el éxito: se prueba el registro completo con un dispositivo móvil, el registro del proveedor y el mensaje SMS real.

Mapear correctamente los parámetros del gateway SMS

En Authentication > Guest user settings > SMS gateway > Add, introducir Name, URL, HTTP method con Get o Post, Cell number format y, cuando corresponda, Use country code with mobile phone number y Number prefix.

Cada parámetro de la solicitud recibe un Name y un Value; SFOS sustituye {mobileno} y {msg} por el número de móvil y el mensaje. Para la respuesta, se asignan Parameter index y Name al Response format. Los nombres de los parámetros no los define SFOS y deben coincidir exactamente con el proveedor. Este esquema utiliza exclusivamente valores de ejemplo reservados:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

Sustituir sms.example.net, mobile, message y status por los valores del proveedor SMS real. Los caracteres especiales en los valores de URL exigidos por el proveedor deben codificarse en porcentaje, por ejemplo @ como %40. Las credenciales en la URL o solicitud son secretos y no deben aparecer en capturas, tickets ni logs. Si el proveedor las exige, se utiliza únicamente HTTPS y se documenta su caducidad. En Administration > Messages > SMS customization, el mensaje también debe coincidir con la plantilla aceptada por el proveedor. Para el texto del mensaje están disponibles {username}, {password} y {expirydate}. A continuación, guardar el gateway con Save.

La prueba del proveedor es solo una comprobación parcial: En el piloto, un invitado abre Register for internet access, guarda el formulario con Save, completa el CAPTCHA y recibe realmente un SMS. A continuación, el registro debe aparecer en Authentication > Guest users y el inicio de sesión en Current activities > Live users. El tráfico debe registrarse con el usuario esperado y la Firewall Rule ID. La regla de usuario utiliza Match known users y Use web authentication for unknown users. La antigua página de ayuda de SMS todavía denomina la segunda opción Show captive portal to unknown users; en SFOS 22 prevalece la etiqueta actual. Una regla amplia con Any no sustituye esta comprobación.

Si no hay gateway SMS, responsable o protección clara de la página de registro, el autorregistro permanece desactivado. Una persona responsable crea entonces las cuentas de forma controlada.

Crear cuentas de invitado individuales o múltiples

Crear una cuenta individual con nombre y correo electrónico

Para un visitante concreto, se abre Authentication > Guest users > Add single:

1. En Name, introducir por ejemplo Visitor Zurich 2026-08-11. Es el nombre del registro, no el nombre de usuario posterior.
2. Introducir la dirección de correo electrónico del responsable. Este campo no envía las credenciales; para ello Sophos documenta Add and print o el envío por SMS.
3. Establecer Validity period en el periodo necesario, 1 day en el ejemplo.
4. Elegir Validity start de forma consciente.
5. Guardar con Add o guardar e imprimir las credenciales con Add and print.

Immediately inicia la validez al crear la cuenta. Es adecuado cuando las credenciales se entregan y utilizan inmediatamente. After first login inicia el periodo con el primer inicio de sesión correcto. Esta opción suele ser mejor para cuentas preparadas con antelación porque la validez no caduca antes de la llegada.

Después de crear la cuenta, la lista muestra el nombre de usuario generado. No se debe confundir el nombre del registro con el nombre de usuario al entregar las credenciales.

Generar varias cuentas para un evento

En Authentication > Guest users > Add multiple se definen Number of users, Validity period y Validity start. Add and print crea las cuentas y las impresiones correspondientes.

Solo deben crearse varias cuentas para un evento concreto. Las impresiones se cuentan, se guardan de forma segura y se entregan a una persona responsable. Las cuentas no utilizadas o caducadas se desactivan o purgan. Un gran inventario de credenciales sin asignar debilita las restricciones técnicas.

Comprobar el grupo, las políticas y los límites de inicio de sesión

Una nueva cuenta de invitado hereda primero el grupo seleccionado en Guest user settings. En Authentication > Guest users > Edit se comprueban el nombre, la contraseña, el número de móvil, el correo electrónico, el grupo y las políticas individuales, y se guarda con Save.

Las políticas específicas del usuario tienen prioridad sobre las políticas de grupo. Por ello, una excepción solo es adecuada cuando está documentada. Para un modelo de invitados uniforme, Access Time, Surfing Quota, Network Traffic, Traffic Shaping y Sign-in Restriction suelen mantenerse agrupados en Guest_Internet.

En el ejemplo se aplican estos límites:

• Sign-in restriction: User group nodes hereda la limitación del grupo de invitados. Para una excepción individual, limitar Selected nodes o Node range a los orígenes realmente necesarios. Any node solo encaja si los inicios de sesión desde todas las redes son intencionados y están protegidos por separado.
• Simultaneous sign-ins: 1, mientras no se autorice expresamente una cuenta para varios dispositivos.
• MAC binding: Normalmente desactivado para dispositivos de invitados cambiantes. El firewall tampoco vincula por direcciones MAC a los usuarios de VPN de acceso remoto.
• Quarantine digest: Activar solo si la cuenta utiliza realmente Mail Protection y existe un proceso de cuarentena definido.
• Remote access policies: No planificarlas como acceso VPN para Guest users.

La validez de la cuenta resuelve una tarea diferente a las políticas de tiempo y consumo:

• Validity period determina durante cuánto tiempo puede utilizarse la cuenta de invitado.
• Access Time permite o bloquea el acceso a internet en ventanas horarias recurrentes.
• Surfing Quota y Network Traffic Quota limitan el tiempo en línea o el volumen de datos.
• Una regla de firewall determina qué zonas, destinos y servicios son accesibles.

La validez de la cuenta y los límites de tiempo y consumo no sustituyen una regla de firewall restrictiva. Una cuenta válida no debe acceder a un servidor interno si la regla de firewall no lo permite expresamente.

Conectar el Captive Portal y la ruta de tráfico

Los Guest users suelen iniciar sesión a través del Captive Portal. Device Access, DNS, HTTPS, la regla de usuario y el método de autenticación seleccionado deben coincidir. El portal por sí solo no permite el acceso a internet.

Desde la red de invitados se realizan pruebas completas, tanto positivas como negativas:

1. El cliente recibe una dirección, un gateway y DNS de la red de invitados.
2. https://login.example.com:8090 es accesible y muestra el certificado correcto.
3. Una solicitud web normal conduce al portal.
4. Una cuenta de invitado válida puede iniciar sesión.
5. En Current activities > Live users aparecen el nombre de usuario y la IP de origen.
6. La prueba de internet permitida coincide con la regla de usuario y la Firewall Rule ID esperadas.
7. Un destino interno y un servicio no permitido siguen bloqueados.
8. Una cuenta caducada o desactivada, o unas credenciales introducidas deliberadamente de forma incorrecta son rechazadas.

En una red de invitados de doble pila, este proceso se prueba por separado para IPv4 e IPv6, ya que SFOS trata de forma independiente la autenticación web para destinos IPv4 e IPv6. Además, en Authentication > Web authentication > Sign out user se define y se prueba cuándo finaliza la sesión. Never no es apropiado para un acceso de invitados de duración limitada.

El procedimiento completo de reglas, Device Access y HTTPS se explica en Configurar y probar el Captive Portal de Sophos Firewall. La guía de portales Sophos distingue User Portal, VPN Portal y Captive Portal.

Entregar credenciales y operar cuentas

En Authentication > Guest users están disponibles varias acciones operativas:

• Print: Entregar las credenciales de forma controlada.
• Resend credentials: Reenviar las credenciales mediante el gateway SMS configurado.
• Change status: Establecer una cuenta como activa o inactiva.
• Change password: Asignar una nueva contraseña tras una pérdida o sospecha de exposición.
• View usage: Comprobar el uso de internet y el estado de las cuotas.
• Reset user accounting: Restablecer los contadores de consumo y reiniciar la Network Traffic Quota.

Reset user accounting cambia el estado. Antes se documentan la cuenta, el consumo actual, la hora y el motivo. No se utiliza como primer paso de diagnóstico porque modifica las evidencias y puede conceder más cuota al invitado.

Para la baja, primero se desactiva la cuenta. En Current activities > Live users, se selecciona su sesión activa y se finaliza con Disconnect; después se verifica que fallen un nuevo inicio de sesión y el acceso por la ruta de datos. A continuación se comprueban las impresiones no utilizadas, el acceso SMS y posibles excepciones específicas del usuario. El registro se elimina o se deja que Auto purge on expiry lo retire solo cuando ya no existe ninguna dependencia.

Antes del piloto se documentan la configuración global, el gateway SMS, el grupo y la regla. Para revertir los cambios, se restablece cada valor modificado; como alternativa, se desactivan el autorregistro y la regla piloto. Restaurar una copia de seguridad completa no es una operación rápida de deshacer: sustituye la configuración actual y reinicia el firewall; en HA, restaurar el Primary también provoca una interrupción. Esta opción se reserva para el procedimiento de emergencia documentado.

Diagnosticar de forma sistemática

El nombre del registro no funciona como nombre de usuario

Con Add single, Name es solo la etiqueta del registro de usuario. El nombre de usuario real se genera a partir de Guest user settings y aparece en la lista o en la impresión de credenciales. Se utiliza exactamente ese valor junto con la contraseña generada o modificada.

La cuenta es válida inmediatamente o aún no lo es

Comprobar Validity start y Validity period. Con Immediately, el tiempo empieza al crear la cuenta; con After first login, empieza con el primer inicio de sesión correcto. También se comprueban la hora y la zona horaria del firewall. Una regla de firewall más amplia no repara una cuenta caducada.

El autorregistro no envía un mensaje SMS

Comprobar si Enable guest users registration está activado, si se ha seleccionado el SMS gateway correcto y si el número de móvil, el country code, la URL, el método HTTP, los parámetros de solicitud y el formato de respuesta coinciden con el proveedor. Después se comprueban el registro del proveedor y la entrega real del SMS.

Un Test connection correcto no prueba todo el flujo de registro y Captive Portal. A la inversa, según Sophos, una prueba fallida contra un gateway interno privado no demuestra automáticamente que la ruta SMS esté rota. En ambos casos se prueba con una cuenta piloto real.

El inicio de sesión funciona, pero el acceso a internet no

En Current activities > Live users, comprobar si el invitado aparece con la IP de origen esperada. Después se revisan el grupo, las excepciones específicas del usuario, la validez, Access Time y las cuotas. En Log Viewer, el tráfico de prueba debe coincidir con la regla de usuario y la Firewall Rule ID esperadas.

Si el usuario no aparece en Live users, primero se inspecciona la ruta de inicio de sesión con access_server.log y la hora documentada de la prueba. Si el usuario es visible, el siguiente control corresponde a la regla, el enrutamiento, NAT, DNS o la política de protección. Diagnosticar errores de autenticación de forma sistemática separa estas fases.

La cuenta de invitado no puede seleccionarse para SSL VPN

Es el comportamiento esperado del producto. Guest users y Guest groups no son Policy members válidos para el acceso remoto SSL VPN ni para el acceso remoto IPsec. Para un técnico externo que necesita VPN se utiliza un usuario normal con permisos mínimos, MFA y la política de acceso remoto adecuada.

Comprobación final

• El invitado solo puede acceder a los destinos previstos; las redes internas y los servicios de administración siguen bloqueados.
• La validez, Access Time, las cuotas y las excepciones coinciden con el proceso de entrega.
• El autorregistro permanece desactivado hasta superar el piloto de SMS y CAPTCHA.
• Live users, el ID de regla y las pruebas positiva y negativa confirman la asignación esperada.
• La baja desconecta las sesiones activas y elimina las credenciales e impresiones que ya no se necesitan.
• Reset user accounting solo se ejecuta con un motivo documentado.

Preguntas frecuentes