Configurar y probar Clientless Users en Sophos Firewall

Una impresora, un servidor u otro dispositivo fijo a menudo no puede iniciar sesión en el firewall. Clientless Users proporciona aun así una identidad comprensible a ese tráfico: Sophos Firewall asigna un nombre de usuario configurado a la IP de origen visible y puede usar esa identidad en reglas, Live Users y logs.

Esto no es autenticación. Quien tome la IP configurada o aparezca detrás de la misma dirección NAT puede recibir la misma asignación. Por tanto, Clientless Users solo es adecuado para dispositivos con dirección estable y controlados. Para dispositivos personales cambiantes, IP compartidas o accesos privilegiados, un método de inicio de sesión real es la mejor opción.

⚠️ Clientless Users no es Clientless SSL VPN. Clientless Users asigna internamente una IP a una identidad. En cambio, Clientless SSL VPN publica bookmarks RDP, SSH o de servidores de archivos en VPN Portal.

Clientless User en ocho pasos

1. Definir el dispositivo, el responsable, los destinos necesarios y la IP de origen visible para el firewall.
2. Configurar la dirección de forma estática o vincularla inequívocamente mediante una reserva DHCP.
3. En Authentication > Groups, crear un grupo pequeño de tipo Clientless.
4. En Authentication > Clientless users > Add, crear exactamente un usuario piloto con esa IP.
5. Crear una regla de firewall propia y con logging, con el origen exacto, Match known users y el grupo clientless.
6. Comprobar el usuario en Current activities > Live users y el flujo real en Log Viewer.
7. Establecer brevemente el usuario como Inactive y confirmar que la regla de identidad deja de coincidir.
8. Reactivar el usuario, volver a validar la regla y documentar la asignación, el responsable y la fecha de revisión.

Cuándo es adecuado Clientless Users

Clientless Users resulta útil cuando una regla de firewall o un informe necesita una identidad estable del dispositivo, pero este no puede realizar un inicio de sesión de usuario. Los candidatos habituales son impresoras, appliances de monitorización, equipos de laboratorio o servidores de infraestructura muy restringidos.

La función solo es adecuada si se cumplen todos los puntos siguientes:

• El firewall ve siempre la misma IP de origen inequívoca para el tráfico.
• La dirección es estática o está vinculada mediante una reserva DHCP controlada.
• Detrás de la dirección no hay varios dispositivos mediante NAT o proxy.
• La identidad solo recibe acceso a los destinos y servicios que el dispositivo necesita realmente.
• Otro dispositivo no puede asumir la dirección sin que se detecte.
• Es posible realizar una prueba positiva y otra negativa con un flujo de datos real.

Para clientes de dominio normales, STAS suele ser más adecuado. Si el acceso de red ya genera RADIUS Accounting, RADIUS SSO Accounting puede crear dinámicamente la asignación entre usuario e IP. Captive Portal ofrece un inicio de sesión interactivo.

Clientless Users no es un atajo para suplir una segmentación inexistente. Una impresora sigue perteneciendo a una zona apropiada o a una red separada y necesita una regla restrictiva. La identidad basada en IP complementa este control, pero no lo sustituye.

Funcionamiento y límite de seguridad

Sophos Firewall muestra un Clientless User activo como Live User sin inicio de sesión interactivo. Cuando un paquete coincide con la IP configurada, el nombre de usuario asignado queda disponible para reglas basadas en usuario y para informes.

Esto no aporta una prueba criptográfica del dispositivo o de la persona:

• No hay contraseña ni segundo factor.
• La asignación no verifica una sesión personal de Windows o Entra.
• Un cambio de IP no se interpreta automáticamente como un cambio de dispositivo.
• Una IP NAT o proxy compartida no permite distinguir endpoints individuales.
• Un Clientless User no es un usuario de VPN de acceso remoto.

Si se necesitan reglas personales, Clientless Users solo debería usarse en casos excepcionales bien controlados. Para una persona con un puesto fijo, la asignación DHCP debe ser estable, pero la identidad sigue describiendo la IP y no a la persona frente a la pantalla.

Ejemplo y valores sustituibles

El procedimiento utiliza una impresora que solo puede acceder a DNS, NTP y a un servidor de impresión interno:

• Username: Printer-Accounting
• dirección IP visible: 192.0.2.50
• grupo clientless: Clientless-Devices
• regla de firewall: Printer-Accounting_to_Services
• Source network: objeto host Printer-Accounting_192.0.2.50
• destino: servicio DNS/NTP interno y servidor de impresión previsto
• revisión: responsable y próxima fecha de revisión en la descripción de la regla

192.0.2.50 pertenece al rango oficial de documentación IPv4 y no es una dirección de dispositivo productiva. Debe sustituirse por la IP fija que el firewall ve como origen del flujo real. Para IPv6 se necesita una dirección IPv6 fija, una regla IPv6 independiente y una validación separada.

Los nombres del ejemplo muestran el propósito, pero no son una especificación del producto. En un entorno real, el usuario, el grupo, el objeto host y la regla deberían seguir un esquema de nombres coherente.

Preparar la dirección y el grupo

Confirmar la IP de origen visible

Antes de configurar la identidad, se genera exactamente un flujo de datos controlado desde el dispositivo. En Log Viewer o Packet Capture, se registran al menos Source IP, In interface, destino, servicio y la Firewall Rule ID anterior.

Si el origen visible es una dirección NAT, proxy o gateway compartida, hay que detenerse aquí. Esa dirección no debe asignarse a un único Clientless User. De lo contrario, todos los dispositivos situados detrás recibirían la misma identidad.

Con DHCP, se crea una reserva para ese dispositivo concreto. No basta con introducir en el firewall una dirección libre del pool: si el servidor DHCP la asigna después a otro cliente, ese cliente heredará la identidad y posiblemente los permisos de la regla.

Crear un grupo clientless

En Authentication > Groups > Add, se crea un grupo propio:

1. Introducir Clientless-Devices como Name.
2. Seleccionar Clientless como Group type.
3. Establecer solo las políticas de grupo necesarias.
4. Guardar con Save.

Las políticas específicas del usuario tienen prioridad sobre las políticas del grupo asignado. Por ello, el grupo debería tener un propósito base común y comprensible. Las desviaciones de un usuario individual se documentan y se prueban por separado.

Los Clientless Users no admiten Surfing quota, Access time ni Network traffic policy. Si un dispositivo fijo solo debe comunicarse a determinadas horas, se utiliza un horario en la regla de firewall con alcance limitado. Access Time para usuarios y grupos, en cambio, se aplica a usuarios normales, grupos y usuarios invitados. Surfing Quota y Network Traffic Quota también requieren una asignación compatible de usuario o grupo.

Gestionar correctamente los grupos de usuarios y el grupo principal en Sophos Firewall explica por qué los grupos Normal, importados y Clientless representan modelos de identidad distintos. Este artículo se mantiene centrado en el procedimiento Clientless completo basado en IP.

Añadir un Clientless User individual

En Authentication > Clientless users > Add, los campos se configuran así:

1. Username: Printer-Accounting
2. IP address: la dirección fija del dispositivo confirmada previamente
3. Group: Clientless-Devices
4. Name: un nombre descriptivo comprensible para el dispositivo
5. Email: introducir una dirección real del responsable solo si se necesita para funciones como Quarantine Digest
6. Quarantine digest: activarlo solo de forma consciente; para una impresora normal suele permanecer desactivado
7. Guardar con Save.

Después se puede volver a abrir el usuario y añadir configuraciones específicas compatibles. Un cambio solo se considera correcto cuando Live Users, la coincidencia de la regla y el tráfico real vuelven a ser correctos.

Usar Add range solo con una justificación clara

Authentication > Clientless users > Add range crea Clientless Users individuales para todas las direcciones entre From IP y To IP. Sophos asigna el grupo seleccionado y después permite editar por separado cada usuario generado.

Un pool DHCP normal no es un candidato adecuado. Un rango trataría de antemano como identidad conocida cada dirección que se asigne posteriormente. Add range solo resulta apropiado para un bloque de direcciones totalmente reservado y documentado, con propósito común, asignación controlada y revisión individual posterior. Para el primer despliegue, Add con una sola IP sigue siendo la opción segura.

Crear una regla de firewall restrictiva

Comprender y configurar reglas de Sophos Firewall de forma segura explica la mecánica general. Para este ejemplo se crea una regla propia por encima de una regla más general de impresoras o LAN:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: activado
• Source zone: la zona real del dispositivo
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zona de los servicios previstos
• Destination networks: solo el destino DNS/NTP y el servidor de impresión
• Services: solo los puertos necesarios
• Match known users: activado
• Users or groups: Clientless-Devices o el usuario piloto individual

La IP de origen y la condición de usuario pueden utilizarse juntas de forma deliberada. La IP limita el origen técnico y la identidad hace comprensible la regla y el reporting. Para un dispositivo fijo no es necesario un origen Any ni un destino Any amplios.

Después de guardar, se comprueba que ninguna regla más general situada por encima coincida primero. Solo la Firewall Rule ID en Log Viewer o Packet Capture muestra qué regla procesa el flujo real. Probar una regla de Sophos Firewall ofrece el procedimiento guiado.

Prueba positiva y negativa

Comprobar la identidad y el flujo permitido

1. En Current activities > Live users, buscar Printer-Accounting y la IP esperada.
2. Generar exactamente un flujo previsto desde el dispositivo.
3. En Log Viewer, comparar usuario, Source IP, Firewall Rule ID, nombre de regla, servicio y acción.
4. Comprobar que el destino recibe la solicitud y que la ruta de retorno funciona.
5. Probar un servicio o destino no previsto y confirmar el drop esperado.

La entrada en Live Users no basta por sí sola. Confirma la asignación activa, pero no la posición de la regla, el servicio permitido ni la ruta de datos.

Usar el cambio de estado como prueba negativa

Un Clientless User no debe cerrarse con Disconnect en Live Users. En Authentication > Clientless users, se selecciona el usuario piloto y se utiliza Change status para establecerlo como Inactive.

Después ya no debe aparecer como Clientless User en Live Users. Una nueva conexión de prueba tampoco debe coincidir con la regla piloto basada en usuario usando esa identidad. A continuación, se vuelve a establecer el usuario como Active y se repite la prueba positiva.

Esta prueba no debe generar un allow inesperado mediante una regla más general. Si la conexión debe seguir permitida tras la desactivación, la regla de fallback prevista debe documentarse y probarse también de forma consciente.

Diagnosticar de forma sistemática

El usuario no aparece en Live Users

• Comprobar que el estado en Authentication > Clientless users es Active.
• Comparar la IP configurada con el origen realmente visible en el paquete.
• Buscar un Username duplicado o una IP ya utilizada.
• Analizar por separado el tráfico IPv4 e IPv6.
• Si existen muchos objetos de usuario y grupo, comprobar la User ID interna concreta. El límite de User ID no se diagnostica a partir de un recuento aproximado de objetos.

Según la ayuda actual de SFOS, Clientless Users aparece directamente en Live Users después de configurarse. Un reinicio de servicio, una intervención en la base de datos o el borrado y recreación repetidos no forman parte del procedimiento normal.

El usuario es visible, pero coincide la regla equivocada

• Comprobar Match known users, el usuario o grupo seleccionado y el estado de la regla.
• Comparar Source zone, Source network, Destination zone, destino y servicio con el flujo real.
• Revisar la posición de la regla y cualquier regla más general situada por encima.
• En Log Viewer, no filtrar solo por el nombre de usuario; comparar también Firewall Rule ID y Source IP.
• Crear una conexión nueva, porque las sesiones existentes no se vuelven a evaluar automáticamente.

La regla de firewall no coincide ofrece la lógica de diagnóstico detallada.

El dispositivo equivocado recibe la identidad

La asignación de IP no está suficientemente controlada. Se revisan lease DHCP, reserva, configuración estática, IP duplicada, NAT y proxy. La regla se desactiva o el Clientless User se establece como Inactive hasta saber con certeza qué dispositivo usa la dirección de origen.

No se debe crear un rango mayor para capturar direcciones cambiantes. Eso amplía la suposición de confianza incorrecta y dificulta la atribución posterior.

QoS no se aplica con muchos Clientless Users

Sophos documenta NC-148705 como corregido en SFOS 22.0 MR1 Build 490: una QoS Policy no se aplicaba cuando había más de 3000 Clientless Users. Las notas de la versión no indican un intervalo de versiones afectadas.

Si coincide exactamente este síntoma, se registran la versión y el build del firmware y se planifica una actualización compatible al menos a MR1 Build 490 o posterior. Un problema de QoS con menos usuarios o en otro build no demuestra NC-148705; deben revisarse normalmente la asignación de políticas, la coincidencia de la regla y Traffic Shaping.

Interpretar logs y HA

access_server.log contiene eventos de autenticación, autorización y accounting. Para el flujo de datos siguen siendo decisivos el log del firewall, Log Viewer y Packet Capture. Logs de servicios de Sophos Firewall explica la asignación de logs.

En un clúster HA, la configuración y el funcionamiento se realizan en el Primary actual. Sophos no documenta ninguna garantía de que los estados de Live Users o de las sesiones de Clientless Users sobrevivan a un failover sin interrupción. Después de un failover controlado se vuelven a comprobar el Clientless User, la coincidencia de la regla, el flujo real y los logs locales del nodo que procesó el evento.

Operación y rollback

Cada Clientless User necesita un responsable, un propósito y una fecha de revisión. Cuando se sustituye el dispositivo, cambia de red o deja de necesitar la regla, la asignación no debe permanecer sin control.

El rollback controlado:

1. Documentar la regla, el grupo, los informes y las dependencias de Traffic Shaping afectados.
2. Establecer el Clientless User como Inactive.
3. Comprobar negativamente el estado de Live Users y el flujo de datos real.
4. Cambiar la regla o la condición de usuario al estado sucesor previsto.
5. Eliminar el Clientless User cuando ya no sea necesario.
6. Eliminar el grupo solo cuando ningún otro usuario o política lo necesite.
7. Limpiar por separado la reserva DHCP, el objeto host y la documentación.

Una identidad productiva no se elimina durante un incidente abierto antes de conservar Source IP, Rule ID y logs. Si la asignación no está clara, primero se limita el acceso y se conservan las pruebas.

FAQ