Saltar para o conteudo
Avanet

Configurar Sophos Firewall SATC para Remote Desktop Services

Sophos Firewall

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.

Para clientes Windows normais, o primeiro passo é configurar STAS na Sophos Firewall. SATC não substitui STAS em todos os ambientes, mas é o componente adequado para Remote Desktop Services.

Utilização e planeamento

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 em que STAS não é suficiente porque vários utilizadores partilham o mesmo endereço IP de origem

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.

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

Se STAS e SATC forem usados ao mesmo tempo, a separação conceptual sozinha não basta. Citrix XenApp e Windows Server RDS podem fazer com que STAS devolva uma identidade de utilizador incorreta para o mesmo IP de servidor, caso este não esteja excluído. Por isso, os endereços IP dos servidores Citrix/RDS devem ser incluídos na configuração STAS em Login IP Address/Network Subnet mask Exclusion List e Logoff IP Address/Network Subnet mask Exclusion List. Sem esta exclusão, STAS pode continuar a fornecer o seu próprio mapeamento de utilizador, contraditório, precisamente para os IPs de servidor que deveriam usar SATC.

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 Authentication está 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 deve estar corretamente configurada antes de implementar SATC. Se AD ainda não estiver pronto, verificar primeiro Ligar Active Directory à Sophos Firewall.

Limites importantes

SATC tem alguns limites que devem ser conhecidos antes do rollout:

  • 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. A Sophos também refere o Citrix XenApp como cenário suportado com limitações; isso também se reflete no nome do parâmetro citrix-ip no comando CLI.
  • 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.

Configuração

Visão geral do processo

O processo técnico consiste em cinco partes:

  1. Instalar Sophos Server Protection no servidor RDS.
  2. Ativar SATC por Registry no servidor RDS.
  3. Registar o IP do servidor RDS na Device Console da Sophos Firewall.
  4. Verificar servidor AD, grupos e ordem de autenticação na firewall.
  5. 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:

  1. Iniciar sessão no Sophos Central.
  2. Abrir Protect Devices.
  3. Em Server Protection, transferir o Windows Server Installer.
  4. Instalar o programa de instalação no Remote Desktop Session Host.
  5. Verificar se o servidor aparece corretamente no Sophos Central.
  6. Definir uma janela de manutenção para a ativação de SATC.

Os programas de instalação 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, este comando só de leitura mostra que valores SATC já existem:

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

Atenção: As alterações de Registry e o reinício subsequente afetam todas as sessões RDS ativas. Documentar os valores atuais, utilizar uma janela de manutenção e desativar Tamper Protection apenas de forma controlada. Depois da alteração, deve ser 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:

  1. Ativar novamente Tamper Protection.
  2. Reiniciar o servidor RDS.
  3. Após o reinício, verificar se o serviço Sophos está em execução.
  4. Executar novamente o comando só de leitura reg query e verificar os valores definidos.
  5. 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 sensíveis a maiúsculas e minúsculas.

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

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.

Em caso de latência de rede percetível entre o servidor RDS e a firewall, também é possível definir SatcPendDurationMs. O valor determina durante quanto tempo as ligações TCP IPv4 de saída são retidas, para que a associação do utilizador esteja disponível a tempo. Se o valor de Registry não existir, SATC utiliza 100 milissegundos; 0 desativa apenas este atraso da ligação, não SATC. Alterar o valor apenas perante problemas reais de latência, não por precaução.

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

Tal como nas outras alterações de registo, é necessário reiniciar o servidor RDS depois.

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:

  1. Iniciar sessão na Sophos Firewall por consola ou SSH.
  2. Abrir a opção 4. Device Console.
  3. Mostrar as entradas existentes:
system auth thin-client show
  1. Adicionar o IP do servidor RDS apenas se ainda não estiver listado:
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

Se tiver sido registado um IP incorreto, verificar novamente a lista e removê-lo de forma direcionada:

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

O comando remove apenas a entrada Thin Client da firewall; os valores de Registry e o Sophos Server Protection permanecem no servidor RDS. Num IP produtivo, a associação SATC deixa assim de existir, pelo que as regras baseadas em utilizadores podem deixar de fazer match. A Sophos não documenta como reagem as sessões já existentes. Por isso, remover a entrada apenas numa janela de manutenção e com um caminho de reversão preparado.

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:

  1. Abrir Authentication > Servers.
  2. Validar o servidor AD com Test connection.
  3. Controlar a importação de grupos.
  4. Abrir Authentication > Groups.
  5. Procurar os grupos relevantes.
  6. Abrir Authentication > Services.
  7. 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:

  1. Abrir Rules and policies > Firewall rules.
  2. Criar a regra adequada para tráfego do servidor RDS ou da zona de servidores.
  3. Definir Source zone e Destination zone corretamente.
  4. Ativar Match known users.
  5. Selecionar os utilizadores AD ou grupos AD necessários.
  6. Ativar logging, para que o teste seja depois rastreável.
  7. Guardar a regra.
  8. 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 e operação

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:

  1. Iniciar sessão de um utilizador numa sessão RDS.
  2. Gerar tráfego de teste definido, por exemplo uma ligação HTTPS permitida.
  3. Na Sophos Firewall, abrir Current activities > Live users.
  4. Verificar se o utilizador aparece com Client type Thin client.
  5. Controlar o endereço IP do servidor RDS e a associação da sessão.
  6. Abrir Log Viewer.
  7. Filtrar por Source IP do servidor RDS, utilizador e regra.
  8. Verificar se a regra esperada baseada em utilizador se aplica.

Para uma análise mais aprofundada na Advanced Shell, firewall_rule.log é relevante para o rule match e access_server.log para autenticação e autorização. O Log Viewer continua a ser a forma mais rápida de efetuar a primeira verificação.

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.

Operação e documentação

SATC deve ser operado como um componente produtivo de autenticação, não como um hack pontual no Registry.

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 responsável
  • 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. Os problemas de autenticação muitas vezes só se tornam evidentes quando as regras de utilizador ficam subitamente demasiado amplas ou deixam de se aplicar.

Troubleshooting

Nenhum utilizador Thin Client visível

Verificar:

  • O servidor RDS foi reiniciado após a alteração de Registry.
  • SendSatcEvents está definido e é diferente de 0.
  • SatcDestinationAddr aponta para o IP correto da firewall.
  • SatcDestinationPort corresponde à 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 permanece não autenticado devido a um conflito da porta de origem

Software de proxy ou segurança no servidor RDS pode alterar a Source Port. A firewall deteta então um port mismatch e trata o tráfego como não autenticado. Não confundir esta Source Port com SatcDestinationPort: o valor de Registry define a porta de destino para mensagens SATC, por predefinição 6060. Testar esse software de forma controlada ou configurá-lo adequadamente para o caminho SATC; não desativar genericamente as funções de proteção.

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 de forma planeada.

Sem acesso à Internet após uma atualização para SFOS 22.0 GA

Se o utilizador aparecer como Thin client, mas não tiver acesso à Internet desde a atualização, guardar primeiro a versão de firmware, o rule match, firewall_rule.log e access_server.log. A Sophos confirma o erro NC-178903 para atualizações para SFOS 22.0 GA e corrige-o com SFOS 22.0 MR2 Build 546. A Sophos não indica uma assinatura de log inequívoca nem um workaround separado. O enquadramento da release está disponível na visão geral do SFOS 22.0 MR2.

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, SatcDestinationAddr e SatcDestinationPort estã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 Authentication está 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?

SATC faz sentido quando vários utilizadores partilham a mesma Source IP, por exemplo num Remote Desktop Session Host. STAS é mais adequado para clientes Windows normais, em que um IP de cliente pertence normalmente a um utilizador.

O antigo Standalone SATC ainda é suportado?

Não. O caminho atual passa pelo Sophos Server Protection ou pelo Sophos Central Server Core Agent no Windows Remote Desktop Session Host.

Que versão de Windows Server é necessária para SATC?

A Sophos indica Windows Server 2016 ou posterior para SATC com Sophos Server Protection. Além disso, tem de ser um cenário de Remote Desktop Services.

Porque é que um Clientless User para o IP do servidor RDS deixa de funcionar?

Quando o IP do servidor RDS está registado na firewall como Thin Client Server, é utilizado SATC para esse endereço IP. Outros métodos de autenticação como Clientless User não se aplicam.

Como se verifica se SATC funciona?

Um utilizador inicia sessão numa sessão RDS, gera tráfego de teste e depois é verificado em Current activities > Live users com Client type Thin client. Além disso, o Log Viewer deve mostrar que regra de utilizador faz match do tráfego.