Configurar Sophos Firewall SATC para Remote Desktop Services
Sophos Authentication for Thin Client, abreviado SATC, ajuda em regras de utilizador para Remote Desktop Services. Isto é importante sempre que vários utilizadores acedem à rede ou à Internet através do mesmo Windows Remote Desktop Session Host. Nesses casos, o STAS clássico vê muitas vezes apenas o endereço IP do terminal server. SATC, pelo contrário, fornece à Sophos Firewall informações de utilizador das sessões RDS individuais.
Este artigo explica quando SATC faz sentido, que limites se aplicam, como ativar SATC através do Sophos Server Protection e como verificar depois se os utilizadores aparecem corretamente na Sophos Firewall.
Para clientes Windows normais, Configurar STAS na Sophos Firewall é primeiro relevante. SATC não substitui STAS em todos os ambientes, mas é o componente adequado para Remote Desktop Services.
Quando SATC faz sentido
SATC é adequado quando os utilizadores não passam pela firewall diretamente a partir do seu próprio cliente, mas utilizam aplicações ou browsers num Remote Desktop Session Host.
Cenários típicos:
- Remote Desktop Services com vários utilizadores simultâneos
- terminal servers onde os utilizadores precisam de acesso web ou acesso a aplicações
- regras de firewall baseadas em utilizador para utilizadores RDS
- reporting em que não deve ser visível apenas o endereço IP do servidor RDS
- ambientes onde STAS não é suficiente de forma limpa por causa de uma Source IP partilhada
SATC não é o ponto de partida correto para clientes de domínio normais, utilizadores VPN ou cenários puros de Captive Portal. Nesses casos, deve-se primeiro escolher corretamente o modelo de autenticação: STAS, Captive Portal, autenticação VPN, RADIUS ou Microsoft Entra ID SSO.
Separar STAS e SATC corretamente
A diferença mais importante é a associação de IP.
| Cenário | Abordagem adequada |
|---|---|
| Um cliente Windows pertence normalmente a um utilizador | STAS |
| Muitos utilizadores partilham o mesmo IP de servidor RDS | SATC |
| Utilizadores autenticam-se no browser para que as regras se apliquem | Captive Portal |
| Utilizadores chegam através de Remote Access VPN | autenticação VPN ou Entra ID SSO |
| Tráfego passa por servidores técnicos sem relação com utilizador | regras de firewall normais sem utilizador |
Se um terminal server for representado incorretamente através de STAS ou Clientless User, criam-se rapidamente expectativas erradas. Uma regra parece ser baseada em utilizador, mas na realidade a firewall vê apenas um IP de servidor partilhado. SATC resolve exatamente este problema, mas exige uma configuração própria no Windows Server e na firewall.
Pré-requisitos
Antes da configuração, estes pontos devem estar esclarecidos:
- Sophos Server Protection pode ser utilizado no Remote Desktop Session Host.
- O Windows Server funciona como Remote Desktop Session Host.
- É usado Windows Server 2016 ou posterior.
- A Sophos Firewall está acessível.
- Active Directory está ligado à Sophos Firewall.
- Os grupos AD necessários estão importados na firewall.
Client Authenticationestá permitido em Device Access para a zona do servidor RDS.- As regras de firewall podem trabalhar posteriormente com Match known users.
- Existe uma janela de manutenção para alteração de Registry e reinício do servidor RDS.
A integração AD não deve ser criada de passagem. Se AD ainda não estiver configurado de forma limpa, verificar primeiro Ligar Active Directory à Sophos Firewall.
Limites importantes
SATC tem alguns limites que devem ser conhecidos antes do rollout:
| Ponto | Significado |
|---|---|
| Standalone SATC | Já não é suportado pela Sophos Firewall. |
| Implementação | SATC funciona através do Sophos Server Protection ou do Sophos Central Server Core Agent. |
| Plataforma | SATC com Sophos Server Protection destina-se a Windows Remote Desktop Services. |
| Limite de servidores | A Sophos indica até 192 Thin Client Servers na firewall. |
| Autenticação por IP de servidor | Se um IP de servidor RDS estiver registado na firewall como Thin Client, SATC funciona como método de autenticação para esse IP. Outros métodos como Clientless User não se aplicam a esse IP. |
O último ponto é especialmente importante. Não se devem adicionar IPs de terminal servers produtivos apenas para teste sem compreender o conjunto de regras e o caminho de retorno. Assim que o IP é tratado como origem SATC, mudam as expectativas em relação à associação de utilizadores e ao matching de regras.
Visão geral do processo
O processo técnico consiste em cinco partes:
- Instalar Sophos Server Protection no servidor RDS.
- Ativar SATC por Registry no servidor RDS.
- Registar o IP do servidor RDS na Device Console da Sophos Firewall.
- Verificar servidor AD, grupos e ordem de autenticação na firewall.
- Validar Device Access, regra de firewall e Live Users.
SATC não deve ser apenas instalado, mas também testado. Uma instalação bem-sucedida no servidor ainda não prova que a firewall verá mais tarde o utilizador correto na regra correta.
Instalar Sophos Server Protection
A instalação é feita através do Sophos Central.
Procedimento:
- Iniciar sessão no Sophos Central.
- Abrir Protect Devices.
- Em Server Protection, transferir o Windows Server Installer.
- Instalar o installer no Remote Desktop Session Host.
- Verificar se o servidor aparece corretamente no Sophos Central.
- Definir uma janela de manutenção para a ativação de SATC.
Os installers visíveis dependem das licenças Sophos existentes. Se Sophos Server Protection já estiver instalado no servidor, ainda assim deve-se verificar se o agente está atualizado e se Tamper Protection pode ser desativado de forma controlada e depois novamente ativado.
Ativar SATC por Registry
SATC é controlado no servidor RDS por valores de Registry neste caminho:
HKLM\Software\Sophos\Sophos Network Threat Protection\Application
Antes da alteração, devem ser documentadas as definições atuais. Se Tamper Protection estiver ativo no servidor, deve ser desativado de forma controlada para a alteração e depois novamente ativado.
A configuração básica pode ser definida numa linha de comandos administrativa:
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 é substituído pelo endereço IP da Sophos Firewall para o qual o servidor RDS deve enviar as informações SATC. A porta padrão é 6060.
Depois:
- Ativar novamente Tamper Protection.
- Reiniciar o servidor RDS.
- Após o reinício, verificar se o serviço Sophos está em execução.
- Só depois continuar com a configuração da firewall e os testes.
Excluir contas locais e destinos
Por predefinição, contas locais como SYSTEM ou Administrator também podem gerar eventos SATC. Isto normalmente não ajuda em regras de utilizador e pode sujar desnecessariamente os logs.
Com SatcExcludedUsers é possível excluir utilizadores. As entradas são case-sensitive.
Exemplo:
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0Administrator" /f
Com SatcExcludedAddresses é possível excluir destinos para os quais não devem ser enviadas informações SATC à firewall. Isto pode fazer sentido para destinos locais de gestão, atualização ou infraestrutura, mas deve ser documentado conscientemente.
Formatos possíveis:
192.0.2.10
192.0.2.10:443
*:443
As exceções devem ser mantidas restritas. Se destinos demasiado amplos forem excluídos, a firewall verá mais tarde menos contexto de utilizador do que esperado.
Registar o servidor RDS na firewall
A firewall tem de saber que servidores fornecem informações SATC. Isto é feito na Device Console, não na Advanced Shell.
Procedimento:
- Iniciar sessão na Sophos Firewall por consola ou SSH.
- Abrir a opção
4. Device Console. - Adicionar o IP do servidor RDS:
system auth thin-client add citrix-ip <RDS-SERVER-IP>
<RDS-SERVER-IP> é substituído pelo endereço IP do Remote Desktop Session Host.
Se existirem vários servidores RDS, cada servidor deve ser registado individualmente e documentado. Depois deve estar claro:
- que servidores contam como origens SATC
- que zona estes servidores usam
- que regras de firewall avaliam utilizadores destes servidores
- quem aprova alterações à lista de servidores RDS
Verificar Active Directory e grupos
SATC fornece informações de utilizador. Para que a firewall possa usar estas informações em regras, a integração AD e os grupos têm de estar corretos.
Verificar:
- Abrir Authentication > Servers.
- Validar o servidor AD com Test connection.
- Controlar a importação de grupos.
- Abrir Authentication > Groups.
- Procurar os grupos relevantes.
- Abrir Authentication > Services.
- Verificar o servidor AD na ordem correta dos Firewall authentication methods.
Se os utilizadores aparecerem na área Live Users, mas as regras não se aplicarem, a causa muitas vezes não está no próprio SATC, mas sim na importação de grupos, grupo predefinido, critério da regra ou posição da regra.
Definir Device Access e regra de firewall
Para que a firewall aceite Client Authentication a partir da zona do servidor, Client Authentication tem de estar permitido para essa zona.
Caminho:
Administration > Device access
Em Client Authentication, ativar a zona do servidor RDS. Não se deve abrir cegamente WAN ou uma zona ampla e insegura. Device Access controla serviços locais da firewall e faz parte do hardening de gestão.
Depois, o tráfego propriamente dito precisa de uma regra de firewall.
Procedimento típico:
- Abrir Rules and policies > Firewall rules.
- Criar a regra adequada para tráfego do servidor RDS ou da zona de servidores.
- Definir Source zone e Destination zone corretamente.
- Ativar Match known users.
- Selecionar os utilizadores AD ou grupos AD necessários.
- Ativar logging, para que o teste seja depois rastreável.
- Guardar a regra.
- Gerar tráfego de teste a partir de uma sessão RDS.
Logging é importante para troubleshooting posterior. Se uma regra de utilizador for criada sem logging, torna-se mais difícil perceber se o problema está em SATC, matching de grupos, ordem de regras ou outro caminho.
Validação após a configuração
Depois da configuração, não se deve verificar apenas se um utilizador tem acesso à Internet. O essencial é saber se a firewall vê o utilizador correto e se a regra correta faz match.
Teste prático:
- Iniciar sessão de um utilizador numa sessão RDS.
- Gerar tráfego de teste definido, por exemplo uma ligação HTTPS permitida.
- Na Sophos Firewall, abrir Current activities > Live users.
- Verificar se o utilizador aparece com Client type
Thin client. - Controlar o endereço IP do servidor RDS e a associação da sessão.
- Abrir Log Viewer.
- Filtrar por Source IP do servidor RDS, utilizador e regra.
- Verificar se a regra esperada baseada em utilizador se aplica.
Se o tráfego não correr como esperado, ajuda também Testar regra de firewall com Log Viewer, Policy Test e Packet Capture. Se os utilizadores estiverem visíveis, mas grupos ou utilizadores individuais não fizerem match, Regra da Sophos Firewall não faz match é o próximo caminho de validação adequado.
Troubleshooting
Nenhum utilizador Thin Client visível
Verificar:
- O servidor RDS foi reiniciado após a alteração de Registry.
SendSatcEventsestá definido e é diferente de0.SatcDestinationAddraponta para o IP correto da firewall.SatcDestinationPortcorresponde à porta esperada.- O caminho de rede do servidor RDS para a firewall está aberto.
- O IP do servidor RDS foi registado na firewall com
system auth thin-client add citrix-ip. - A zona do servidor RDS permite Client Authentication em Device Access.
O utilizador aparece, mas a regra não faz match
Verificar:
- O utilizador ou grupo está importado na firewall.
- A regra usa Match known users.
- O grupo AD correto está selecionado na regra.
- A posição da regra está correta.
- Não existe uma regra anterior que faça match do mesmo tráfego sem referência a utilizador.
- O Log Viewer mostra o mesmo utilizador, a mesma Source IP e o mesmo serviço.
Contas locais aparecem nos logs
Verificar SatcExcludedUsers e acrescentar contas técnicas. Candidatos frequentes são administradores locais, serviços e contas de sistema. A lista, porém, não deve ficar tão ampla que exclua acidentalmente utilizadores reais.
Alguns destinos não recebem contexto de utilizador
Verificar SatcExcludedAddresses. Se um destino ou porta tiver sido excluído, SATC não envia informações de autenticação à firewall para esse destino. Isto pode ser intencional, mas causa facilmente confusão em regras de utilizador.
Após registar o IP do servidor, um Clientless User antigo deixa de se aplicar
Isto é esperado. Se o IP do servidor RDS foi registado como Thin Client Server, SATC deve ser o modelo de autenticação para esse IP. Workarounds antigos com Clientless Users devem ser removidos ou substituídos conscientemente.
Operação e documentação
SATC deve ser operado como um componente produtivo de autenticação, não como um hack de Registry único.
Documentar:
- servidores RDS e endereços IP
- IP da firewall utilizado e porta SATC
- valores de Registry definidos
- utilizadores e destinos excluídos
- regras de firewall afetadas
- grupos AD e owner
- utilizador de teste e match de regra esperado
- janela de manutenção e momento do reinício
Após atualizações de Sophos Server Protection, Windows Server, Sophos Firewall ou AD, SATC deve ser testado de forma direcionada com um utilizador de teste. A autenticação muitas vezes só chama a atenção quando regras de utilizador ficam subitamente demasiado amplas ou deixam de se aplicar.
Checklist
- O cenário RDS é realmente adequado para SATC e não para STAS normal.
- Sophos Server Protection está instalado no Remote Desktop Session Host.
- A versão do Windows Server e a função RDS foram verificadas.
- Tamper Protection foi desativado apenas de forma controlada e depois novamente ativado.
SendSatcEvents,SatcDestinationAddreSatcDestinationPortestão definidos.- O servidor RDS foi reiniciado.
- O IP do servidor RDS foi registado na Device Console da firewall.
- O servidor AD e os grupos AD foram verificados na firewall.
Client Authenticationestá permitido para a zona correta em Device Access.- A regra de firewall usa Match known users e tem logging ativo.
- O utilizador aparece em Current activities > Live users com Client type
Thin client. - O Log Viewer mostra o utilizador esperado e a regra esperada.
FAQ
Quando é necessário SATC em vez de STAS?
O antigo Standalone SATC ainda é suportado?
Que versão de Windows Server é necessária para SATC?
Porque é que um Clientless User para o IP do servidor RDS deixa de funcionar?
Como se verifica se SATC funciona?
Thin client. Além disso, o Log Viewer deve mostrar que regra de utilizador faz match do tráfego.