Configurar o Client Authentication Agent na Sophos Firewall

O Client Authentication Agent, ou CAA, é adequado para endpoints Windows, macOS ou Linux individuais em que o utilizador inicia sessão conscientemente na firewall. Após um login bem-sucedido, a identidade aparece como Authentication agent em Current activities > Live users. As regras de firewall e web baseadas em utilizadores ou grupos podem então associar o tráfego a essa identidade.

O agente não substitui todas as arquiteturas SSO. Um servidor de terminais com vários utilizadores simultâneos precisa de SATC, enquanto o STAS pode assumir o login sem agente de endpoint num domínio Windows. O CAA é especialmente indicado para um número controlável de dispositivos individuais em que o login manual do utilizador seja aceitável.

Importante: O agente tem de alcançar o caminho de autenticação documentado pela Sophos. Em Administration > Device access, o serviço local Clients tem, por isso, de ser permitido para a zona de origem. O CAA utiliza TCP 9922; uma VPN, outra rota predefinida ou um router anterior pode desviar da firewall o caminho para 1.2.3.4. Antes de um rollout amplo, devem ser testados num dispositivo a Local Service ACL, a rota, a CA TLS, o login piloto e a correspondência real da regra.

CAA em dez passos

1. Confirmar que o endpoint representa um único utilizador ativo; utilizar SATC para RDS, Citrix ou outros hosts multiutilizador.
2. Documentar o servidor de autenticação, o grupo de utilizadores, a política de firewall e um método local de recuperação.
3. Em Administration > Device access, permitir Clients para a zona de origem. Através de TCP 9922, verificar o caminho para 1.2.3.4 em Windows e macOS ou para o IP da firewall definido em caa.conf em Linux.
4. Em Authentication > Client downloads, descarregar o agente adequado e a respetiva Server CA.
5. Para uma distribuição Windows em massa, planear em conjunto Download MSI e Download CA for MSI; os instaladores individuais incluem o agente e a CA.
6. Instalar o agente num dispositivo-piloto, mas sem o distribuir amplamente nesta fase.
7. Em Authentication > Services > Firewall authentication methods, verificar o servidor de autenticação previsto e a respetiva ordem.
8. Iniciar sessão com um utilizador-piloto e confirmar o tipo de cliente Authentication agent em Current activities > Live users.
9. Executar um fluxo permitido e outro bloqueado e verificar utilizador, política e Firewall Rule ID no Log Viewer.
10. Só depois documentar deployment, comportamento do MFA, teste HA, processo de suporte e rollback.

Quando o Client Authentication Agent é adequado

O CAA envia o login do utilizador do endpoint para a firewall. É especialmente adequado para:

• endpoints individuais geridos que não pertencem ao domínio;
• ambientes pequenos sem infraestrutura STAS;
• dispositivos em que uma mudança de utilizador deve provocar deliberadamente um novo login do agente;
• políticas que precisam de um nome de utilizador real e não apenas de um IP de origem.

O agente não é uma solução geral para vários utilizadores simultâneos atrás do mesmo IP de host. SATC em sistemas Remote Desktop explica a abordagem por sessão para Citrix, RDS e servidores de terminais. Num ambiente AD, STAS na Sophos Firewall é a alternativa sem cliente.

O CAA autentica o utilizador, mas não cria uma autorização de rede. Regras de firewall, Web Policies, grupos, quotas e Access-Time-Policies permanecem níveis separados. Um Live User visível ainda não comprova que o tráfego pretendido corresponde à regra correta.

Exemplo e requisitos

O piloto utiliza:

• IP LAN da firewall: 10.20.30.1
• Dispositivo-piloto: 10.20.30.50
• Utilizador-piloto: fw-user-pilot
• Grupo de utilizadores: CAA-Pilot
• Destino do agente: 1.2.3.4
• Porta TCP: 9922

10.20.30.1 e 10.20.30.50 são valores privados de documentação e têm de ser substituídos pelos endereços reais. Em contrapartida, 1.2.3.4 e TCP 9922 são o caminho do agente documentado pela Sophos para Windows e macOS e não são substituídos como valores normais do ambiente. Para Linux, as instruções do User Portal utilizam um ficheiro de configuração próprio e exigem o IP real da firewall.

Antes da instalação, é necessário esclarecer estes pontos:

• O dispositivo-piloto utiliza a Sophos Firewall como gateway ou possui um caminho comprovado para o destino do agente.
• Nenhuma VPN full-tunnel nem rota externa desvia 1.2.3.4 do gateway SFOS previsto.
• Em Administration > Device access, Clients está permitido na coluna da zona de origem real. Uma regra de firewall não substitui esta Local Service ACL.
• O utilizador existe localmente ou num servidor selecionado em Firewall authentication methods.
• O grupo e as políticas estão preparados; o piloto não recebe preventivamente direitos mais amplos.
• A Authentication Server CA correspondente ao instalador é obtida apenas na própria firewall.
• Durante o piloto continua disponível outro método de autenticação funcional.
• Se o MFA estiver ativo, o token está registado e o comportamento do agente é testado separadamente.

Para o SFOS 22, o limite de sistemas operativos suportados pelo Client Authentication Agent inclui Windows 10 e posterior, Ubuntu 16.4 e posterior e macOS Catalina 10.15 e posterior. Este limite de produto, associado a uma versão específica, não garante o suporte de todas as versões futuras dos sistemas operativos; por isso, a versão exata do endpoint deve ser testada antes da implementação.

A Avanet recomenda testar primeiro num dispositivo a combinação exata de build SFOS, pacote do agente, versão do endpoint e proteção do endpoint. O teste negativo posterior e o comportamento HA também são recomendações operacionais; a Sophos não documenta assim uma sessão ininterrupta durante um failover.

Preparar a autenticação na firewall

Em Authentication > Services > Firewall authentication methods, é selecionado pelo menos um servidor adequado ou a base de dados local. Com vários servidores, o SFOS encaminha o pedido pela ordem apresentada. Default Group, grupo importado e estado do utilizador têm, por isso, de estar definidos antes do teste do agente.

O CAA é um serviço de autenticação local da firewall. Em Administration > Device access, ativa-se Clients na coluna da zona de origem. Segundo a Sophos, esta entrada inclui CAA em TCP 9922 e STAS e SATC em UDP 6060. As regras de firewall normais não permitem Local Services. Numa Custom Zone, o acesso também pode ser controlado em Network > Zones.

Para contas-piloto locais, consulte criar e testar utilizadores locais em segurança. Em AD, LDAP ou RADIUS, testa-se primeiro o respetivo servidor com o diálogo normal do serviço. Contudo, um Test connection verde não comprova o posterior caminho CAA a partir do endpoint.

Se o MFA estiver ativado para o User portal, a Sophos indica que este requisito também se aplica aos Client Authentication Agents. O registo e a introdução do token são, por isso, testados com o mesmo utilizador-piloto. O MFA não é ativado inesperadamente apenas depois do rollout.

Descarregar o agente e a Server CA

Os administradores descarregam os pacotes aqui:

Authentication > Client downloads

A Sophos fornece estas variantes:

• Download MSI: agente Windows para distribuição automatizada;
• Download CA for MSI: Authentication Server CA separada para deployment MSI;
• Download for Windows: instalador individual com agente e CA;
• Download for macOS: instalador individual com agente e CA;
• Download for Linux 32 ou Download for Linux 64: arquivo com agente, configuração e CA.

Em alternativa, utilizadores autorizados podem descarregar os pacotes no User Portal em Download client > Authentication clients. Para este caminho, seleciona-se pelo menos o servidor adequado em Authentication > Services > User portal authentication methods e ativa-se User portal em Administration > Device access apenas para a zona de origem prevista. A porta predefinida é TCP 4443. A Sophos desaconselha a permissão do User Portal a partir da zona WAN; não é necessária uma autorização WAN ampla apenas para o download.

Após um factory reset, a firewall volta a gerar a CA. Os utilizadores têm então de reinstalar a Authentication Server CA. Um agente antigo com uma CA antiga não é reparado desativando a validação de certificados ou introduzindo uma CA externa; o pacote atual deve ser novamente descarregado da firewall correta.

Instalar o agente no dispositivo-piloto

Windows e macOS

Em Windows, executa-se client_auth_agent.exe a partir do User Portal. No assistente, escolhem-se a localização de instalação e a pasta do menu Iniciar; Install instala o cliente e Finish fecha o assistente e inicia o agente. Num deployment MSI gerido, o agente e Download CA for MSI têm de ser distribuídos em conjunto. O agente isolado sem a CA correspondente não implementa o caminho TLS documentado.

Em macOS, abre-se Client+Authentication+Agent.dmg. Arrastam-se ambos os ícones para as respetivas pastas, fecha-se o instalador e inicia-se Client Authentication Agent em Applications. Também aqui a CA integrada tem de provir da firewall em que o utilizador iniciará sessão posteriormente.

O piloto é instalado primeiro de forma interativa. A distribuição do pacote, o arranque automático e o comportamento de atualização só são automatizados após um teste end-to-end bem-sucedido. Não se reutiliza um agente antigo de um backup ou appliance diferente.

Linux

Para Linux, a Sophos indica o seguinte caminho de extração, substituindo <FILENAME> pelo arquivo descarregado:

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Em seguida, verifica-se a configuração fornecida em $HOME/.caa/caa.conf. A ajuda do User Portal exige, em Linux, que o valor após Copernicus host seja substituído pelo endereço IP real da firewall e que sejam introduzidos o nome de utilizador e a palavra-passe. Uma palavra-passe real não é colocada num script de deployment, ticket ou exemplo público. A Sophos indica que o agente cifra a palavra-passe inicialmente guardada em texto simples na primeira execução.

Antes do arranque, são verificados permissões, proprietário e conteúdo de $HOME/.caa/README. Depois, executa-se caa como piloto. Como as instruções Linux utilizam um valor de destino diferente do caminho geral Windows e macOS, os procedimentos das plataformas não são misturados.

Autenticar o piloto e testar políticas

O piloto inicia sessão no agente com o nome de utilizador e a palavra-passe previstos para a firewall. Com autenticação externa, esta grafia exata tem de corresponder à configuração do servidor. Uma indicação positiva do agente é apenas o primeiro teste.

Na firewall, verifica-se então:

1. fw-user-pilot aparece em Current activities > Live users.
2. O tipo de cliente é Authentication agent.
3. O IP de origem e o grupo correspondem ao dispositivo-piloto e ao mapeamento previsto.
4. Um fluxo permitido corresponde à regra esperada baseada no utilizador ou grupo.
5. Um destino deliberadamente não autorizado permanece bloqueado.
6. O log da firewall mostra utilizador, regra, ação e Firewall Rule ID.
7. Após Disconnect em Live users, o agente recebe a notificação documentada e o tráfego é novamente avaliado.

Para a regra de teste não se cria uma política Any ampla. As regras existentes são ampliadas apenas de forma controlada com o utilizador ou grupo piloto. O processo geral encontra-se em testar sistematicamente regras da Sophos Firewall.

Verificar logs e HA

Abre-se o Log viewer no canto superior direito da consola WebAdmin. No módulo Authentication, utiliza-se Add filter ou a pesquisa de texto livre para o utilizador, IP de origem e momento do teste. A entrada tem de corresponder ao login do agente; no módulo Firewall, verificam-se também o tráfego real, a ação e a Firewall Rule ID. Log firewall traffic tem de estar ativo na regra em causa para o teste aparecer. Uma sessão pode ser registada apenas quando termina, pelo que se deve fechar corretamente o fluxo de teste ou atualizar a vista após uma breve espera.

Para uma correlação mais profunda são relevantes access_server.log para autenticação e autorização, juntamente com o Log Viewer ou o destino Syslog configurado. Um único estado do cliente sem a entrada correspondente no log da firewall não é uma prova completa de sucesso.

Em HA, não se pressupõe que um login existente do agente continue sem interrupção. Após um failover controlado, voltam a ser testados um novo login, Live User, a correspondência de política e o tráfego real. Os logs residem no node que processou o evento; se o momento não for claro, verificam-se ambos os nodes ou uma vista consolidada.

Delimitar erros por sintoma

O agente não alcança a firewall

Primeiro, verifica-se em Administration > Device access se Clients está ativo para a zona de origem. Depois, verificam-se o routing e TCP 9922. Em Diagnostics > Packet capture > Configure, introduz-se host 1.2.3.4 and port 9922 em Enter BPF string; a captura mostra se o tráfego do agente chega à Sophos Firewall. Para Linux, utiliza-se o IP da firewall configurado em caa.conf em vez de 1.2.3.4.

Se o problema só começar após a ligação de outro cliente VPN, verifica-se se a respetiva rota full-tunnel assume o destino do agente. A solução não é um comando host route aplicado sem validação: split tunnel, routing e efeito de segurança são primeiro avaliados no desenho real. Se o caminho de autenticação continuar incerto, o rollout é interrompido.

Surge um erro TLS ou de CA

O instalador e a CA têm de provir da mesma firewall ativa. Após um factory reset, a CA antiga fica inválida e é substituída pelo pacote atual. A validação de certificados, a proteção do endpoint ou TLS não são desativados como correção rápida.

A palavra-passe funciona no portal, mas não no agente

Em Firewall authentication methods, verificam-se a ordem dos servidores, Default Group e o estado do utilizador. Depois controlam-se o requisito MFA, a grafia do nome de utilizador, uma vinculação de IP de origem ou MAC e a mensagem do log Authentication. Um login bem-sucedido no portal não comprova automaticamente o mesmo método ou caminho do agente.

O utilizador está live, mas aplica-se a regra errada

Verificar a ordem das regras, Match known users, o utilizador ou grupo selecionado, o serviço, o destino e a Firewall Rule ID. Primeiro identifica-se a regra realmente correspondente; uma regra allow ampla não substitui o diagnóstico.

Num servidor de terminais aparece apenas uma identidade

O CAA não é a abordagem adequada para este caminho multiutilizador. Várias instâncias paralelas do agente não transformam o host num sistema sensível a sessões. Para RDS ou Citrix utiliza-se SATC e valida-se separadamente.

Para um diagnóstico transversal aos métodos, consulte verificar sistematicamente a autenticação da Sophos Firewall.

Rollback e operação

Se o piloto falhar, o agente é parado ou removido no dispositivo-piloto. As alterações temporárias de utilizador, grupo, portal e regras são repostas no estado anterior documentado. Se Clients tiver sido permitido especificamente para o piloto, só é desativado quando nenhuma outra instalação CAA, STAS ou SATC nessa zona precisar dele. Depois, o método de autenticação anterior é novamente testado com um novo login e tráfego real.

A Authentication Server CA não é eliminada globalmente enquanto outras instalações CAA a utilizarem. Antes de factory reset, reimage ou substituição do appliance, planeia-se atualizar a CA recém-gerada em todos os endpoints afetados.

No mínimo, são documentados estes detalhes operacionais:

• responsável pelo pacote do agente e pelo deployment;
• versões de sistemas operativos autorizadas;
• origem e renovação da Authentication Server CA;
• caminho esperado para o destino do agente e TCP 9922;
• processo de MFA e palavra-passe;
• testes piloto e negativo após alterações de SFOS, endpoint ou VPN;
• desativação de acesso e remoção de Live Sessions existentes.

Lista de verificação

• endpoint de um único utilizador confirmado em vez de host multiutilizador
• servidor de autenticação e ordem documentados
• Clients ativo na Local Service ACL apenas para a zona de origem necessária
• caminho do agente através da Sophos Firewall comprovado
• agente e Authentication Server CA descarregados da mesma firewall
• MSI e CA separada planeados em conjunto
• limites das plataformas e caminho específico Linux considerados
• utilizador-piloto preparado com grupo e política mínimos
• comportamento MFA testado
• Live User mostra Authentication agent
• tráfego real permitido e bloqueado testado
• utilizador, ação e Firewall Rule ID confirmados no log
• comportamento VPN e HA testado com novo login
• impacto do factory reset na CA e rollback documentados

Perguntas frequentes