Ir al contenido
Avanet

Configurar Sophos Firewall SATC para Remote Desktop Services

Sophos Firewall

Sophos Authentication for Thin Client, abreviado SATC, ayuda con las reglas de usuario en Remote Desktop Services. Esto es importante cuando varios usuarios acceden a la red o a Internet a través del mismo Windows Remote Desktop Session Host. En estos casos, el STAS clásico suele ver solo la dirección IP del servidor de terminales. SATC, en cambio, entrega a Sophos Firewall información de usuario de las distintas sesiones RDS.

Para clientes Windows normales, el primer paso es configurar STAS en Sophos Firewall. SATC no sustituye a STAS en todos los entornos, sino que es el componente adecuado para Remote Desktop Services.

Uso y planificación

Cuándo SATC tiene sentido

SATC encaja cuando los usuarios no pasan por el firewall directamente desde su propio cliente, sino que usan aplicaciones o navegadores en un Remote Desktop Session Host.

Escenarios típicos:

  • Remote Desktop Services con varios usuarios simultáneos
  • servidores de terminales en los que los usuarios necesitan acceso web o acceso a aplicaciones
  • reglas de firewall basadas en usuarios para usuarios RDS
  • reporting en el que no debe verse solo la dirección IP del servidor RDS
  • entornos en los que STAS no basta porque varios usuarios comparten una IP de origen

SATC no es el punto de partida correcto para clientes de dominio normales, usuarios VPN o escenarios puros de Captive Portal. Ahí conviene elegir primero el modelo de autenticación adecuado: STAS, Captive Portal, autenticación VPN, RADIUS o Microsoft Entra ID SSO.

En un endpoint individual que no pertenece al dominio, el Client Authentication Agent puede proporcionar un inicio de sesión deliberado. No sustituye a SATC en un host multiusuario, porque varias sesiones comparten la misma IP de origen.

Si un host multiusuario solo necesita distinguir HTTP y HTTPS mediante un proxy explícito, Per-Connection AD SSO a través de Direct Web Proxy puede ser suficiente sin un agente SATC. En cuanto RDP, SMB u otro tráfico sin proxy también necesite una identidad por sesión de usuario, SATC sigue siendo el diseño adecuado.

Separar claramente STAS y SATC

La diferencia más importante es la asignación de IP.

  • Un cliente Windows suele pertenecer a un usuario: STAS.
  • Muchos usuarios comparten la misma IP de servidor RDS: SATC.
  • Los usuarios inician sesión en el navegador para que apliquen reglas: Captive Portal.
  • Los usuarios entran por Remote Access VPN: autenticación VPN o Entra ID SSO.
  • El tráfico pasa por servidores técnicos sin referencia de usuario: reglas de firewall normales sin usuario.

Si un servidor de terminales se representa erróneamente mediante STAS o Clientless User, surgen rápidamente expectativas equivocadas. Una regla parece estar basada en usuarios, pero en realidad el firewall solo ve una IP de servidor compartida. SATC resuelve exactamente este problema, pero necesita una configuración propia en el Windows Server y en el firewall.

Si STAS y SATC se usan al mismo tiempo, la separación conceptual por sí sola no basta. Citrix XenApp y Windows Server RDS pueden hacer que STAS entregue una identidad de usuario incorrecta para la misma IP de servidor si no está excluida. Por eso, las direcciones IP de los servidores Citrix/RDS deben incluirse en la configuración de STAS bajo Login IP Address/Network Subnet mask Exclusion List y Logoff IP Address/Network Subnet mask Exclusion List. Sin esta exclusión, STAS puede seguir entregando su propia asignación de usuario, contradictoria, precisamente para las IPs de servidor que deberían usar SATC.

Requisitos

Antes de la configuración deberían aclararse estos puntos:

  • Sophos Server Protection puede usarse en el Remote Desktop Session Host.
  • El Windows Server funciona como Remote Desktop Session Host.
  • Se usa Windows Server 2016 o posterior.
  • Sophos Firewall es accesible.
  • Active Directory está conectado en Sophos Firewall.
  • Los grupos AD necesarios están importados en el firewall.
  • En Administration > Device access, la zona del servidor RDS está permitida en la fila Clients.
  • El servidor RDS puede alcanzar la IP del firewall mediante UDP 6060; cualquier firewall de host o de red intermedio permite esta ruta.
  • Las reglas de firewall podrán trabajar después con Match known users.
  • Existe una ventana de mantenimiento para el cambio de Registry y el reinicio del servidor RDS.

La conexión AD debe estar correctamente configurada antes de implementar SATC. Si AD aún no está listo, conviene revisar primero conectar Active Directory con Sophos Firewall.

Límites importantes

SATC tiene algunos límites que conviene conocer antes del rollout:

  • SATC standalone: Ya no está soportado por Sophos Firewall.
  • Despliegue: SATC funciona mediante Sophos Server Protection o el Sophos Central Server Core Agent.
  • Plataforma: Según Sophos, la configuración actual con Sophos Server Protection solo admite Windows Remote Desktop Services. La descripción general anterior aún menciona Citrix XenApp en el contexto del conflicto con STAS y el parámetro CLI sigue llamándose citrix-ip. Ninguno de estos detalles constituye una prueba actual de soporte para un nuevo rollout de Citrix. Conviene confirmar con Sophos Support cualquier despliegue Citrix existente antes de modificarlo y no crear uno nuevo a partir de esta guía para RDS.
  • Servicios del sistema: SATC solo asigna una identidad de directorio a las conexiones creadas por procesos de usuario. Los procesos iniciados por servicios del sistema de Windows permanecen sin identidad de usuario y necesitan una regla de máquina separada y limitada con Match known users desactivado. Esta regla no debe utilizarse como fallback amplio para el resto del tráfico RDS.
  • Límite de servidores: Sophos menciona hasta 192 Thin Client Servers en el firewall.
  • Autenticación por IP de servidor: Si una IP de servidor RDS está registrada en el firewall como Thin Client, SATC funciona como método de autenticación para esa IP. Otros métodos como Clientless User no se aplican a esa IP.

El último punto es especialmente importante. No conviene registrar IPs productivas de servidores de terminales solo para probar, sin entender las reglas y la ruta de retorno. En cuanto la IP se trata como fuente SATC, cambian las expectativas sobre asignación de usuarios y rule matching.

Configuración

Resumen del procedimiento

El proceso técnico consta de cinco partes:

  1. Instalar Sophos Server Protection en el servidor RDS.
  2. Activar SATC mediante Registry en el servidor RDS.
  3. Registrar la IP del servidor RDS en la Device Console de Sophos Firewall.
  4. Revisar servidor AD, grupos y orden de autenticación en el firewall.
  5. Validar Device Access, regla de firewall y Live Users.

SATC no solo debe instalarse, sino también probarse. Una instalación correcta en el servidor no demuestra todavía que el firewall vaya a ver después el usuario correcto en la regla correcta.

Instalar Sophos Server Protection

La instalación se realiza mediante Sophos Central.

Procedimiento:

  1. Iniciar sesión en Sophos Central.
  2. Abrir Protect Devices.
  3. Descargar el Windows Server Installer bajo Server Protection.
  4. Instalar el programa de instalación en el Remote Desktop Session Host.
  5. Comprobar si el servidor aparece correctamente en Sophos Central.
  6. Definir una ventana de mantenimiento para la activación de SATC.

SATC forma parte del Sophos Central Server Core Agent y, según Sophos, está disponible con cualquier licencia de Server Protection. Los programas de instalación que aparecen realmente en Sophos Central siguen dependiendo de las licencias disponibles. Si Sophos Server Protection ya se ejecuta en el servidor, también conviene comprobar si el agente está actualizado y si Tamper Protection puede desactivarse de forma controlada y volver a activarse después.

Activar SATC mediante Registry

SATC se controla en el servidor RDS mediante valores de Registry bajo esta ruta:

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Antes del cambio, este comando de solo lectura muestra qué valores SATC ya existen:

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Atención: Los cambios de Registry y el posterior reinicio afectan a todas las sesiones RDS activas. Documentar los valores actuales, usar una ventana de mantenimiento y desactivar Tamper Protection solo de forma controlada. Después del cambio debe volver a activarse.

La configuración básica puede definirse en un símbolo del sistema administrativo:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

Sustituir FIREWALL-IP por la dirección IPv4 de Sophos Firewall accesible desde la zona del servidor RDS. Sophos documenta UDP 6060 para SATC, por lo que 6060 permanece sin cambios en el ejemplo. No usar una dirección WAN pública cuando el servidor y el firewall se comuniquen por una interfaz interna.

Recomendación de Avanet: Conectar primero un solo host RDS y permitir UDP 6060 exclusivamente entre ese host y el firewall. Así, un error queda limitado al servidor piloto antes de añadir más Session Hosts.

Después:

  1. Volver a activar Tamper Protection.
  2. Reiniciar el servidor RDS.
  3. Tras el reinicio, comprobar si el servicio Sophos se está ejecutando.
  4. Volver a ejecutar el comando de solo lectura reg query y comprobar los valores definidos.
  5. Solo después continuar con la configuración de firewall y las pruebas.

Excluir cuentas locales y destinos

Por defecto, cuentas locales como SYSTEM o Administrator también pueden generar eventos SATC. Esto normalmente no ayuda a las reglas de usuario y puede ensuciar los logs innecesariamente.

Con SatcExcludedUsers se pueden excluir usuarios. Las entradas distinguen entre mayúsculas y minúsculas, por lo que los nombres deben respetar exactamente la grafía utilizada en el sistema.

Ejemplo:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0administrator" /f

Con SatcExcludedAddresses se pueden excluir destinos para los que no se deben enviar datos SATC al firewall. Esto puede tener sentido para destinos locales de gestión, actualización o infraestructura, pero debería documentarse expresamente.

Formatos posibles:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 es una dirección de documentación y debe sustituirse por la IP real del destino. La segunda entrada solo se aplica al puerto 443 de ese destino, mientras que *:443 cubre ese puerto para todos los destinos. Una excepción tan amplia retiraría prácticamente todo el tráfico HTTPS de la asignación SATC y no es adecuada para reglas de usuario normales.

Recomendación de Avanet: Empezar sin excepciones y añadirlas solo después de un hallazgo concluyente en los logs. Asignar a cada excepción un responsable, una finalidad y una fecha de revisión.

Si hay latencia de red notable entre el servidor RDS y el firewall, también se puede configurar SatcPendDurationMs. El valor determina cuánto tiempo se retienen las conexiones TCP IPv4 salientes para que la asignación de usuario esté disponible a tiempo. Si el valor de Registry no existe, SATC usa 100 milisegundos; 0 desactiva solo este retraso de conexión, no SATC. Modificarlo únicamente ante problemas reales de latencia, no como precaución.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

300 es un ejemplo de diagnóstico adaptable, no un nuevo valor predeterminado recomendado. Aumenta el retraso respecto al valor predeterminado documentado de 100 milisegundos para cada conexión TCP IPv4 saliente afectada. Medir antes y después con el mismo usuario y destino. Si no aporta mejoras, el siguiente comando administrativo restaura el valor predeterminado eliminando el valor opcional:

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /f

Como con los demás cambios de registro, después es necesario reiniciar el servidor RDS.

Registrar el servidor RDS en el firewall

El firewall debe saber qué servidores entregan información SATC. Esto se hace en la Device Console, no en la Advanced Shell.

Procedimiento:

  1. Iniciar sesión en Sophos Firewall por consola o SSH.
  2. Abrir la opción 4. Device Console.
  3. Mostrar las entradas existentes:
system auth thin-client show
  1. Añadir la IP del servidor RDS solo si aún no aparece:
system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> se sustituye por la dirección IP del Remote Desktop Session Host.

Si existen varios servidores RDS, registrar cada servidor por separado y documentarlo. Después debería quedar claro:

  • qué servidores cuentan como fuentes SATC
  • qué zona usan estos servidores
  • qué reglas de firewall evalúan usuarios de estos servidores
  • quién aprueba cambios en la lista de servidores RDS

Si se ha registrado una IP incorrecta, volver a comprobar la lista y eliminarla de forma específica:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

El comando elimina únicamente la entrada Thin Client del firewall; los valores de Registry y Sophos Server Protection permanecen en el servidor RDS. En una IP productiva se pierde así la asignación SATC, por lo que las reglas basadas en usuarios pueden dejar de hacer match. Sophos no documenta cómo reaccionan las sesiones ya existentes. Por tanto, eliminarla solo durante una ventana de mantenimiento y con una ruta de retorno preparada.

Revisar Active Directory y grupos

SATC entrega información de usuario. Para que el firewall pueda usar esta información en reglas, la conexión AD y los grupos deben ser correctos.

Revisar:

  1. Abrir Authentication > Servers.
  2. Comprobar el servidor AD con Test connection.
  3. Controlar la importación de grupos.
  4. Abrir Authentication > Groups.
  5. Buscar los grupos relevantes.
  6. Abrir Authentication > Services.
  7. Revisar el servidor AD en el orden correcto de los firewall authentication methods.

Si los usuarios aparecen en el área Live Users, pero las reglas no aplican, la causa a menudo no está en SATC, sino en la importación de grupos, el grupo predeterminado, el criterio de regla o la posición de la regla.

Configurar Device Access y regla de firewall

Para que el firewall acepte mensajes SATC desde la zona del servidor, el servicio local Clients debe estar permitido para esa zona. SFOS 22 documenta UDP 6060; Clients también comprende STAS y Client Authentication Agent en su propio puerto.

Ruta:

Administration > Device access

En la fila Clients, activar la zona del servidor RDS. No se debería abrir a ciegas WAN ni una zona amplia e insegura. Device Access controla servicios locales del firewall y forma parte del hardening de gestión.

Después, el tráfico real necesita una regla de firewall.

Procedimiento típico:

  1. Abrir Rules and policies > Firewall rules.
  2. Crear una regla adecuada para tráfico desde el servidor RDS o la zona de servidor. Como ejemplo adaptable, la regla RDS-Web-Users puede permitir inicialmente solo el servicio HTTPS necesario desde el objeto de host RDSH-01 en LAN hacia WAN.
  3. Adaptar Source zones, Source networks and devices, Destination zones y Services a la topología. RDSH-01, LAN, WAN y HTTPS son ejemplos, no requisitos del producto.
  4. Activar Match known users.
  5. Seleccionar los usuarios AD o grupos AD necesarios.
  6. Activar logging para que la prueba sea trazable después.
  7. Guardar la regla.
  8. Generar tráfico de prueba desde una sesión RDS.

Recomendación de Avanet: Hacer la regla piloto más restrictiva que la futura regla de producción y colocarla justo encima de una regla de bloqueo documentada. Ampliar servicios o grupos de usuarios solo después de una prueba correcta con dos usuarios RDS distintos.

Para la resolución de problemas posterior, logging es importante. Si se crea una regla de usuario sin logging, resulta más difícil reconocer si el problema está en SATC, group matching, el orden de reglas u otra ruta.

Validación y operación

Validación después de la configuración

Después de la configuración no conviene comprobar solo si un usuario tiene acceso a Internet. Lo decisivo es si el firewall ve el usuario correcto y hace match con la regla correcta.

Prueba práctica:

  1. Iniciar sesión con un usuario en una sesión RDS.
  2. Generar tráfico de prueba definido, por ejemplo una conexión HTTPS permitida.
  3. En Sophos Firewall, abrir Current activities > Live users.
  4. Comprobar si el usuario aparece con Client type Thin client.
  5. Comprobar que la dirección IP del servidor RDS aparece con un identificador de sesión único para cada usuario.
  6. Abrir Log Viewer.
  7. Filtrar por Source IP del servidor RDS, usuario y regla.
  8. Comprobar si aplica la regla esperada basada en usuario.

Repetir la prueba con un segundo usuario y la misma conexión de destino. El éxito no significa solo que ambas conexiones estén permitidas: Live users debe mostrar dos identidades con la misma IP del servidor RDS, pero con identificadores de sesión distintos, y Log Viewer debe mostrar el usuario correcto en cada caso. Probar también un servicio del sistema documentado si se creó una regla de máquina separada; este tráfico no debe atribuirse erróneamente a un usuario conectado.

Para un análisis más profundo en Advanced Shell, firewall_rule.log es relevante para el rule match y access_server.log para la autenticación y autorización. Log Viewer sigue siendo la vía inicial más rápida.

Si el tráfico no funciona como se espera, ayuda además probar una regla de firewall con Log Viewer, Policy Test y Packet Capture. Si los usuarios son visibles, pero los grupos o usuarios individuales no hacen match, la regla de Sophos Firewall no hace match encaja como siguiente ruta de revisión.

Operación y documentación

SATC debería operarse como un componente productivo de autenticación, no como un hack de Registry de una sola vez.

Documentar:

  • servidores RDS y direcciones IP
  • IP de firewall utilizada y puerto SATC
  • valores de Registry definidos
  • usuarios y destinos excluidos
  • reglas de firewall afectadas
  • grupos AD y responsable
  • usuario de prueba y rule match esperado
  • ventana de mantenimiento y momento del reinicio

Después de updates de Sophos Server Protection, Windows Server, Sophos Firewall o AD, conviene probar SATC de forma dirigida con un usuario de prueba. Los problemas de autenticación suelen hacerse visibles solo cuando las reglas de usuario de repente se aplican de forma demasiado amplia o dejan de aplicarse.

Rollback en una ventana de mantenimiento

Sophos documenta que SendSatcEvents solo activa SATC cuando el valor existe y es distinto de 0, y que la entrada Thin Client desplaza otros métodos de autenticación para esa IP de servidor. Esto proporciona una ruta de retorno planificada, pero no restaura automáticamente el método de identidad anterior.

  1. Registrar previamente la consulta del Registry, la salida de system auth thin-client show, las reglas afectadas y el modelo de autenticación anterior.
  2. Cerrar las sesiones RDS activas durante la ventana de mantenimiento, desactivar Tamper Protection de forma controlada y desactivar SendSatcEvents en un símbolo del sistema administrativo:
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 0 /f
  1. Volver a activar Tamper Protection y reiniciar el servidor RDS.
  2. En Device Console, comprobar la entrada con system auth thin-client show y después eliminarla de forma específica:
system auth thin-client delete citrix-ip <RDS-SERVER-IP>
  1. Restaurar el modelo de reglas y autenticación documentado anteriormente y validarlo con un usuario de prueba. No activar sin pruebas un Clientless User ni una regla de máquina amplia como sustitución.

Recomendación de Avanet: No eliminar todos los valores de Registry antes de aclarar la causa. El valor 0 conserva la dirección de destino y las listas de exclusión para una reactivación controlada; una exportación del Registry también conserva el estado inicial exacto.

Troubleshooting

No aparece ningún usuario Thin Client

Revisar:

  • el servidor RDS se reinició después del cambio de Registry.
  • SendSatcEvents está definido y es distinto de 0.
  • SatcDestinationAddr apunta a la IP correcta del firewall.
  • SatcDestinationPort coincide con el puerto esperado.
  • la ruta de red del servidor RDS al firewall está abierta para UDP 6060.
  • la IP del servidor RDS se registró en el firewall mediante system auth thin-client add citrix-ip.
  • la zona del servidor RDS está permitida en la fila Clients de Device Access.

El usuario permanece sin autenticar por un conflicto de puerto de origen

El software proxy o de seguridad del servidor RDS puede modificar el Source Port. El firewall detecta entonces un port mismatch y trata el tráfico como no autenticado. No confundir este Source Port con SatcDestinationPort: el valor de Registry define el puerto de destino para los mensajes SATC, de forma predeterminada 6060. Probar este software de forma controlada o configurarlo adecuadamente para la ruta SATC; no desactivar las funciones de protección de forma general.

El usuario aparece, pero la regla no hace match

Revisar:

  • el usuario o grupo está importado en el firewall.
  • la regla usa Match known users.
  • el grupo AD correcto está seleccionado en la regla.
  • la posición de la regla es adecuada.
  • no existe una regla anterior que haga match con el mismo tráfico sin referencia de usuario.
  • Log Viewer muestra el mismo usuario, la misma Source IP y el mismo servicio.

Cuentas locales aparecen en los logs

Revisar SatcExcludedUsers y añadir cuentas técnicas. Candidatos habituales son administradores locales, servicios y cuentas de sistema. Pero la lista no debería hacerse tan amplia que se excluyan usuarios reales por error.

Algunos destinos no reciben contexto de usuario

Revisar SatcExcludedAddresses. Si se ha excluido un destino o puerto, SATC no envía información de autenticación al firewall para ese destino. Esto puede ser intencionado, pero en reglas de usuario genera confusión fácilmente.

Tras registrar la IP del servidor, un Clientless User antiguo ya no aplica

Esto es esperable. Si la IP del servidor RDS se registró en el firewall como Thin Client Server, SATC debería ser el modelo de autenticación para esa IP. Los workarounds antiguos con Clientless Users deberían eliminarse o sustituirse de forma planificada.

Sin acceso a Internet tras una actualización a SFOS 22.0 GA

Si el usuario aparece como Thin client, pero no tiene acceso a Internet desde la actualización, guardar primero la versión de firmware, el rule match, firewall_rule.log y access_server.log. Las notas de la versión oficiales de SFOS 22.0 incluyen NC-178903 en SFOS 22.0 MR2 Build 546 como problema corregido para actualizaciones a SFOS 22.0 GA. Sophos no indica una firma de log inequívoca ni un workaround separado. La clasificación del release se encuentra en el resumen de SFOS 22.0 MR2.

Checklist

  • El escenario RDS realmente corresponde a SATC y no a STAS normal.
  • Sophos Server Protection está instalado en el Remote Desktop Session Host.
  • Se han revisado la versión de Windows Server y el rol RDS.
  • Tamper Protection se desactivó solo de forma controlada y después se volvió a activar.
  • SendSatcEvents, SatcDestinationAddr y SatcDestinationPort están definidos.
  • El servidor RDS se reinició.
  • La IP del servidor RDS se registró en la Device Console del firewall.
  • El servidor AD y los grupos AD están revisados en el firewall.
  • Clients está permitido para la zona correcta bajo Device Access y UDP 6060 es accesible.
  • La regla de firewall usa Match known users y tiene logging activo.
  • El usuario aparece bajo Current activities > Live users con Client type Thin client.
  • Log Viewer muestra el usuario esperado y la regla esperada.

FAQ

¿Cuándo se necesita SATC en lugar de STAS?

SATC tiene sentido cuando varios usuarios comparten la misma IP de origen, por ejemplo en un Remote Desktop Session Host. STAS encaja mejor con clientes Windows normales, en los que una IP de cliente suele pertenecer a un usuario.

¿Se sigue soportando el SATC standalone antiguo?

No. La ruta actual funciona mediante Sophos Server Protection o el Sophos Central Server Core Agent en el Windows Remote Desktop Session Host.

¿Qué versión de Windows Server necesita SATC?

Sophos menciona Windows Server 2016 o posterior para SATC con Sophos Server Protection. Además, debe tratarse de un escenario de Remote Desktop Services.

¿Por qué ya no funciona un Clientless User para la IP del servidor RDS?

Si la IP del servidor RDS está registrada en el firewall como Thin Client Server, para esa IP se utiliza SATC. Otros métodos de autenticación como Clientless User no se aplican a ella.

¿Cómo se comprueba si SATC funciona?

Un usuario inicia sesión en una sesión RDS, genera tráfico de prueba y después se revisa bajo Current activities > Live users con Client type Thin client. Además, Log Viewer debería mostrar qué regla de usuario hace match con el tráfico.