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 la 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.

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 la 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 la 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.
  • La Sophos Firewall es accesible.
  • Active Directory está conectado en Sophos Firewall.
  • Los grupos AD necesarios están importados en la firewall.
  • Client Authentication está permitido en Device Access para la zona del servidor RDS.
  • 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: SATC con Sophos Server Protection está pensado para Windows Remote Desktop Services. Sophos también menciona Citrix XenApp como escenario soportado con limitaciones; esto también se refleja en el nombre del parámetro citrix-ip en el comando CLI.
  • Límite de servidores: Sophos menciona hasta 192 Thin Client Servers en la firewall.
  • Autenticación por IP de servidor: Si una IP de servidor RDS está registrada en la firewall como Thin Client, SATC funciona como método de autenticación para esa IP. Otros métodos como Clientless User no aplican para 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 la 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 la 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.

Los programas de instalación visibles dependen de las licencias Sophos disponibles. Si Sophos Server Protection ya se ejecuta en el servidor, aun así 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

FIREWALL-IP se sustituye por la dirección IP de Sophos Firewall a la que el servidor RDS debe enviar la información SATC. El puerto estándar es 6060.

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.

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 a la firewall. Esto puede tener sentido para destinos locales de gestión, update o infraestructura, pero debería documentarse expresamente.

Formatos posibles:

192.0.2.10
192.0.2.10:443
*:443

Las excepciones deberían mantenerse estrechas. Si se excluyen destinos demasiado amplios, la firewall verá después menos contexto de usuario del esperado.

Si hay latencia de red notable entre el servidor RDS y la 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

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

Registrar el servidor RDS en la firewall

La 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 de la 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 la 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 la firewall acepte Client Authentication desde la zona del servidor, Client Authentication debe estar permitido para esa zona.

Ruta:

Administration > Device access

Bajo Client Authentication, 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 de la 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 desde la zona de servidor.
  3. Definir Source zone y Destination zone correctamente.
  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.

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 la 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. Controlar la dirección IP del servidor RDS y la asignación de sesión.
  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.

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.

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 de la firewall.
  • SatcDestinationPort coincide con el puerto esperado.
  • la ruta de red del servidor RDS a la firewall está abierta.
  • la IP del servidor RDS se registró en la firewall mediante system auth thin-client add citrix-ip.
  • la zona del servidor RDS permite Client Authentication bajo 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. La 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 la 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 a la firewall para ello. 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 la 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. Sophos confirma el error NC-178903 para actualizaciones a SFOS 22.0 GA y lo corrige con SFOS 22.0 MR2 Build 546. 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 de la firewall.
  • El servidor AD y los grupos AD están revisados en la firewall.
  • Client Authentication está permitido para la zona correcta bajo Device Access.
  • 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 la 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.