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

Planificar de antemano la interrupción: Antes de Change status, documentar el estado actual, las reglas afectadas y el procedimiento previsto para volver al estado anterior. Realizar la prueba negativa únicamente con un dispositivo piloto controlado y dentro de una ventana de tiempo acordada: desactivarlo puede interrumpir sus conexiones necesarias. Para la prueba, generar una conexión nueva en lugar de limitarse a observar una sesión ya en curso. Si se produce un efecto inesperado, restaurar el estado documentado previamente y volver a comprobar la conexión original.

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. Este ejemplo se valida con IPv4. Antes de utilizar IPv6, comprobar expresamente la asociación Clientless y la configuración de reglas adecuada para la versión de SFOS instalada; una validación satisfactoria con IPv4 no demuestra el funcionamiento con IPv6.

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.

MAC binding, User type and profile y las políticas de VPN de acceso remoto tampoco están disponibles para Clientless Users. Por tanto, la identidad clientless basada en IP no proporciona vinculación con un dispositivo ni autentica a un usuario VPN.

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.

Después de Save, en Authentication > Clientless users, abrir Edit para el usuario. En Traffic shaping (quality of service) se puede seleccionar una política existente o crear una nueva. Quarantine digest envía al buzón del usuario una lista de los correos electrónicos retenidos en cuarentena; para un dispositivo sin un buzón asociado a su responsable, esta función permanece desactivada. Después de guardar, volver a comprobar las políticas realmente aplicadas al usuario y al grupo, así como el flujo previsto.

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.

Para un bloque autorizado, en Add range, introducir la primera dirección de dispositivo en From IP, la última en To IP y seleccionar el grupo clientless preparado en Group. Ejemplo: de 192.0.2.50 a 192.0.2.52 representa tres direcciones de dispositivos controlados; ambos extremos deben sustituirse por los del bloque reservado propio. Guardar con Save y, después, abrir cada usuario generado en Authentication > Clientless users mediante Edit para comprobar la IP, el grupo y las políticas individuales necesarias. Para cada dispositivo, comprobar la asignación esperada en Live Users y los flujos permitido y no permitido; una prueba satisfactoria del piloto no sustituye la validación de las demás entradas.

Para revisar la lista en Authentication > Clientless users, hacer clic en Show additional properties y seleccionar los campos necesarios. El orden se puede cambiar arrastrando y soltando los campos en la lista desplegable; confirmar con Ok. Esta vista facilita la comparación de las entradas, pero no sustituye la apertura y revisión de cada configuración individual.

API XML: distinguir Add, Add range y Update

El procedimiento GUI anterior no es una receta XML. Las referencias de la API para SFOS 22.0 y 23.0 dejan abiertas cuestiones importantes sobre la representación de Add y Update:

• Add: La tabla marca Username, Group, Name y Email como obligatorios y los define, junto con IP Address y Spam Digest, como ARRAY. Sin embargo, el ejemplo solo muestra un ClientlessUser con valores individuales, incluidos UserName y ClientLessGroup. Esto no establece una asociación segura entre usuarios, IP, grupos y direcciones de correo ni un lote ejecutable. La indicación de que los duplicados no se ignoran no explica cómo se procesan. Introducir Email solo cuando sea necesario en la GUI anterior no anula el requisito de la API; Add range es un procedimiento GUI independiente, no una prueba de un serializador de arrays. El ejemplo sitúa expresamente <!--only for Edit --> antes de QoSPolicy y Status; no deducir de ello campos de Add ni un estado predeterminado.
• Update: Username, Name, Group e IP Address pasan a ser SCALAR, mientras que Email sigue siendo un ARRAY obligatorio. La tabla también exige Web Filter, App Filter y QOS; el ejemplo no muestra etiquetas de filtros ni demuestra la correspondencia de QOS con QoSPolicy. Por tanto, copiar el ejemplo de Add no produce un Update cuya integridad esté demostrada.
• Digest: El ejemplo también incluye ApplyGroupSettings para QuarantineDigest, pero la tabla de Update solo incluye Disable y Enable para Spam Digest. Su valor predeterminado es literalmente Disbale: un valor incoherente de la referencia, no un valor predeterminado confirmado en ejecución. No deducir de ello la herencia del grupo ni el comportamiento de los campos omitidos; Add tampoco especifica un valor predeterminado para el digest.

Aclarar el contrato del build instalado antes de realizar cambios por API que dependan de estos detalles; mientras la representación no esté clara, utilizar el procedimiento GUI compatible con Edit o Change status. Antes de un cambio, registrar los valores anteriores reales de políticas, digest y estado. Después, comparar con precisión la identidad, IP, grupo y políticas guardados y probar nuevos flujos permitidos y bloqueados. Si se produce un efecto inesperado, restaurar los valores originales en lugar de restablecer supuestos valores predeterminados y volver a comprobar. Estas limitaciones de la documentación no invalidan la herencia del grupo en la GUI.

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 y comprobar su Firewall Rule ID actual; una sesión ya en curso no basta para esta prueba.

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. Aquí no se da por garantizada la transferencia sin interrupciones de la asociación Clientless. 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.

Conservar los valores de uso antes de un reset: Con el usuario abierto, View usage muestra el uso de Internet registrado. Reset user accounting borra estas estadísticas; la ayuda actual de Sophos también habla de reiniciar la Network Traffic Quota, pero la misma página marca Network traffic policy como no compatible con Clientless Users. Por tanto, el reset no se utiliza para reparar una cuota. Primero se documentan los contadores y la asignación real de políticas. Los valores individuales de Traffic shaping y Quarantine digest tienen prioridad sobre los ajustes del grupo Clientless.

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