Configurar e testar Clientless Users na Sophos Firewall

Uma impressora, um servidor ou outro dispositivo fixo muitas vezes não consegue iniciar sessão na firewall. Clientless Users fornece mesmo assim uma identidade compreensível a esse tráfego: a Sophos Firewall associa um nome de utilizador configurado ao IP de origem visível e pode usar essa identidade em regras, Live Users e logs.

Isto não é autenticação. Quem assumir o IP configurado ou aparecer atrás do mesmo endereço NAT pode receber a mesma associação. Por isso, Clientless Users só é adequado para dispositivos com endereços estáveis e controlados. Para dispositivos pessoais variáveis, IP partilhados ou acesso privilegiado, um verdadeiro método de login é a melhor escolha.

⚠️ Clientless Users não é Clientless SSL VPN. Clientless Users associa internamente um IP a uma identidade. Em contrapartida, Clientless SSL VPN publica bookmarks RDP, SSH ou de servidores de ficheiros no VPN Portal.

Clientless User em oito passos

1. Definir o dispositivo, o responsável, os destinos necessários e o IP de origem visível para a firewall.
2. Configurar o endereço de forma estática ou associá-lo inequivocamente através de uma reserva DHCP.
3. Em Authentication > Groups, criar um pequeno grupo do tipo Clientless.
4. Em Authentication > Clientless users > Add, criar exatamente um utilizador piloto com este IP.
5. Criar uma regra de firewall própria e com logging, com a origem exata, Match known users e o grupo clientless.
6. Verificar o utilizador em Current activities > Live users e o fluxo real no Log Viewer.
7. Definir brevemente o utilizador como Inactive e confirmar que a regra de identidade deixa de corresponder.
8. Reativar o utilizador, validar novamente a regra e documentar a associação, o responsável e a data de revisão.

Quando Clientless Users é adequado

Clientless Users é útil quando uma regra de firewall ou um relatório necessita de uma identidade estável do dispositivo, mas este não consegue realizar um login de utilizador. Os candidatos típicos são impressoras, appliances de monitorização, equipamentos de laboratório ou servidores de infraestrutura fortemente limitados.

A função só é adequada quando todos os pontos seguintes são verdadeiros:

• A firewall vê sempre o mesmo IP de origem inequívoco para o tráfego.
• O endereço é estático ou está associado através de uma reserva DHCP controlada.
• O endereço não representa vários dispositivos atrás de NAT ou proxy.
• A identidade só recebe acesso aos destinos e serviços realmente necessários ao dispositivo.
• Outro dispositivo não consegue assumir o endereço sem que isso seja detetado.
• É possível realizar um teste positivo e um negativo com um fluxo de dados real.

Para clientes de domínio normais, STAS é geralmente mais adequado. Se o acesso de rede já produzir RADIUS Accounting, RADIUS SSO Accounting pode criar dinamicamente a associação entre utilizador e IP. O Captive Portal oferece um login interativo.

Clientless Users não é um atalho para compensar a falta de segmentação. Uma impressora continua a pertencer a uma zona apropriada ou a uma rede separada e necessita de uma regra restrita. A identidade baseada em IP complementa este controlo, mas não o substitui.

Funcionamento e limite de segurança

A Sophos Firewall apresenta um Clientless User ativo como Live User sem login interativo. Quando um pacote corresponde ao IP configurado, o nome de utilizador associado fica disponível para regras baseadas no utilizador e reporting.

Isto não fornece uma prova criptográfica do dispositivo ou da pessoa:

• Não existe palavra-passe nem segundo fator.
• A associação não verifica uma sessão pessoal do Windows ou Entra.
• Uma alteração do IP não é interpretada automaticamente como uma mudança de dispositivo.
• Um IP NAT ou proxy partilhado não consegue distinguir endpoints individuais.
• Um Clientless User não é um utilizador de Remote Access VPN.

Se forem necessárias regras pessoais, Clientless Users só deveria ser usado em casos excecionais bem controlados. Para uma pessoa com um posto fixo, a associação DHCP tem de ser estável, mas a identidade continua a descrever o IP e não a pessoa em frente ao ecrã.

Exemplo e valores substituíveis

O procedimento utiliza uma impressora que só pode aceder a DNS, NTP e a um servidor de impressão interno:

• Username: Printer-Accounting
• endereço IP visível: 192.0.2.50
• grupo clientless: Clientless-Devices
• regra de firewall: Printer-Accounting_to_Services
• Source network: objeto host Printer-Accounting_192.0.2.50
• destino: serviço DNS/NTP interno e servidor de impressão previsto
• revisão: responsável e próxima data de revisão na descrição da regra

192.0.2.50 pertence ao intervalo oficial de documentação IPv4 e não é um endereço de dispositivo produtivo. Deve ser substituído pelo IP fixo que a firewall vê como origem do fluxo real. Para IPv6, são necessários um endereço IPv6 fixo, uma regra IPv6 separada e uma validação distinta.

Os nomes do exemplo mostram o propósito, mas não são requisitos do produto. Num ambiente real, o utilizador, o grupo, o objeto host e a regra deveriam seguir um esquema de nomenclatura consistente.

Preparar o endereço e o grupo

Confirmar o IP de origem visível

Antes de configurar a identidade, é gerado exatamente um fluxo de dados controlado a partir do dispositivo. No Log Viewer ou Packet Capture, são registados pelo menos Source IP, In interface, destino, serviço e a Firewall Rule ID anterior.

Se a origem visível for um endereço NAT, proxy ou gateway partilhado, é necessário parar aqui. Este endereço não deve ser associado a um único Clientless User. Caso contrário, todos os dispositivos atrás dele receberão a mesma identidade.

Com DHCP, cria-se uma reserva para este dispositivo específico. Não basta introduzir na firewall um endereço livre do pool: se o servidor DHCP o atribuir posteriormente a outro cliente, esse cliente herdará a identidade e possivelmente as permissões da regra.

Criar um grupo clientless

Em Authentication > Groups > Add, é criado um grupo próprio:

1. Introduzir Clientless-Devices como Name.
2. Selecionar Clientless como Group type.
3. Definir apenas as policies de grupo necessárias.
4. Guardar com Save.

As policies específicas do utilizador têm prioridade sobre as policies do grupo atribuído. Por isso, o grupo deveria ter um propósito base comum e compreensível. As exceções para um utilizador individual são documentadas e testadas separadamente.

Os Clientless Users não suportam Surfing quota, Access time nem Network traffic policy. Se um dispositivo fixo só deve comunicar a determinadas horas, utiliza-se um Schedule na regra de firewall com âmbito restrito. Access Time para utilizadores e grupos aplica-se, pelo contrário, a utilizadores normais, grupos e utilizadores convidados. Surfing Quota e Network Traffic Quota também exigem uma atribuição de utilizador ou grupo suportada.

Gerir corretamente grupos de utilizadores e o grupo principal na Sophos Firewall explica por que razão os grupos Normal, importados e Clientless representam modelos de identidade diferentes. Este artigo continua centrado no procedimento Clientless completo baseado em IP.

Adicionar um único Clientless User

Em Authentication > Clientless users > Add, os campos são definidos da seguinte forma:

1. Username: Printer-Accounting
2. IP address: o endereço fixo do dispositivo confirmado anteriormente
3. Group: Clientless-Devices
4. Name: um nome de apresentação compreensível para o dispositivo
5. Email: introduzir um endereço real do responsável apenas se for necessário para funções como Quarantine Digest
6. Quarantine digest: ativar apenas de forma consciente; para uma impressora normal, a função permanece geralmente desativada
7. Guardar com Save.

Em seguida, o utilizador pode ser novamente aberto e complementado com definições específicas suportadas. Uma alteração só é considerada bem-sucedida quando Live Users, a correspondência da regra e o tráfego real voltarem a estar corretos.

Usar Add range apenas com justificação clara

Authentication > Clientless users > Add range cria Clientless Users individuais para todos os endereços entre From IP e To IP. A Sophos atribui o grupo selecionado; cada utilizador gerado pode depois ser editado individualmente.

Um pool DHCP normal não é adequado. Um intervalo trataria antecipadamente como identidade conhecida cada endereço atribuído mais tarde. Add range só é apropriado para um bloco de endereços totalmente reservado e documentado, com uma finalidade homogénea, atribuição controlada e revisão individual posterior. Para o primeiro rollout, Add com exatamente um IP continua a ser a opção segura.

Criar uma regra de firewall restrita

Compreender e configurar regras da Sophos Firewall em segurança explica o funcionamento geral das regras. Para este exemplo, é criada uma regra própria acima de uma regra mais geral de impressoras ou LAN:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: ativado
• Source zone: a zona real do dispositivo
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zona dos serviços previstos
• Destination networks: apenas o destino DNS/NTP e o servidor de impressão
• Services: apenas as portas necessárias
• Match known users: ativado
• Users or groups: Clientless-Devices ou o utilizador piloto individual

O IP de origem e a condição de utilizador podem ser usados em conjunto de forma consciente. O IP limita a origem técnica, enquanto a identidade torna a regra e o reporting compreensíveis. Uma origem ampla Any ou um destino Any não são necessários para um dispositivo fixo.

Depois de guardar, confirma-se que nenhuma regra mais geral acima corresponde primeiro. Apenas a Firewall Rule ID no Log Viewer ou Packet Capture mostra qual regra processa o fluxo real. Testar uma regra da Sophos Firewall fornece o procedimento guiado.

Teste positivo e negativo

Verificar a identidade e o fluxo permitido

1. Em Current activities > Live users, procurar Printer-Accounting e o IP esperado.
2. Gerar exatamente um fluxo previsto a partir do dispositivo.
3. No Log Viewer, comparar utilizador, Source IP, Firewall Rule ID, nome da regra, serviço e ação.
4. Verificar se o destino recebe o pedido e se o caminho de retorno funciona.
5. Testar um serviço ou destino não previsto e confirmar o drop esperado.

A entrada em Live Users, por si só, não é suficiente. Confirma a associação ativa, mas não a posição da regra, o serviço permitido ou o caminho dos dados.

Usar a alteração de estado como teste negativo

Um Clientless User não deve ser terminado com Disconnect em Live Users. Em Authentication > Clientless users, seleciona-se o utilizador piloto e usa-se Change status para o definir como Inactive.

Depois, o utilizador já não deve aparecer como Clientless User em Live Users. Uma nova ligação de teste também já não deve corresponder à regra piloto baseada no utilizador com esta identidade. Em seguida, volta-se a definir o utilizador como Active e repete-se o teste positivo.

Este teste não deve resultar num allow inesperado através de uma regra mais geral. Se a ligação tiver de continuar permitida após a desativação, a regra de fallback prevista deve ser documentada e também testada conscientemente.

Diagnosticar de forma sistemática

O utilizador não aparece em Live Users

• Verificar se o estado em Authentication > Clientless users é Active.
• Comparar o IP configurado com a origem realmente visível no pacote.
• Procurar um Username duplicado ou um IP já utilizado.
• Analisar separadamente o tráfego IPv4 e IPv6.
• Com muitos objetos de utilizador e grupo, verificar a User ID interna concreta. O limite de User ID não é diagnosticado a partir de uma contagem aproximada de objetos.

De acordo com a ajuda atual do SFOS, Clientless Users fica visível em Live Users diretamente após a configuração. Um reinício de serviço, intervenção na base de dados ou eliminação e recriação repetidas não fazem parte do procedimento normal.

O utilizador está visível, mas corresponde a regra errada

• Verificar Match known users, o utilizador ou grupo selecionado e o estado da regra.
• Comparar Source zone, Source network, Destination zone, destino e serviço com o fluxo real.
• Verificar a posição da regra e qualquer regra mais geral acima.
• No Log Viewer, não filtrar apenas pelo nome de utilizador; comparar também Firewall Rule ID e Source IP.
• Criar uma nova ligação, porque as sessões existentes não são reavaliadas automaticamente.

A regra de firewall não corresponde fornece a lógica de diagnóstico aprofundada.

O dispositivo errado recebe a identidade

A associação de IP não está suficientemente controlada. Verificar lease DHCP, reserva, configuração estática, IP duplicado, NAT e proxy. A regra é desativada ou o Clientless User é definido como Inactive até ficar claro qual dispositivo utiliza o endereço de origem.

Não se deve criar um intervalo maior para capturar endereços variáveis. Isso amplia a suposição de confiança incorreta e dificulta a atribuição posterior.

QoS não é aplicado com muitos Clientless Users

A Sophos documenta NC-148705 como corrigido no SFOS 22.0 MR1 Build 490: uma QoS Policy não era aplicada quando existiam mais de 3000 Clientless Users. As notas de versão não indicam um intervalo de versões afetadas.

Se o sintoma corresponder exatamente, são registados a versão e o build do firmware e é planeada uma atualização suportada pelo menos para MR1 Build 490 ou uma versão compatível posterior. Um problema de QoS com menos utilizadores ou noutro build não prova NC-148705; a atribuição da policy, a correspondência da regra e o Traffic Shaping devem ser verificados normalmente.

Interpretar logs e HA

access_server.log contém eventos de autenticação, autorização e accounting. Para o fluxo de dados, o log da firewall, Log Viewer e Packet Capture continuam a ser decisivos. Logs de serviços da Sophos Firewall explica a associação dos logs.

Num cluster HA, a configuração e a operação são realizadas no Primary atual. A Sophos não documenta qualquer garantia de que os estados Live Users ou de sessão dos Clientless Users sobrevivam a um failover sem interrupção. Após um failover controlado, voltam a verificar-se Clientless User, correspondência da regra, fluxo real e logs locais do nó que processou o evento.

Operação e rollback

Cada Clientless User necessita de um responsável, uma finalidade e uma data de revisão. Quando um dispositivo é substituído, muda de rede ou deixa de necessitar da regra, a associação não deve simplesmente permanecer.

O rollback controlado:

1. Documentar a regra, o grupo, os relatórios e as dependências de Traffic Shaping afetados.
2. Definir o Clientless User como Inactive.
3. Testar negativamente o estado de Live Users e o fluxo de dados real.
4. Alterar a regra ou condição de utilizador para o estado sucessor previsto.
5. Eliminar o Clientless User quando já não for necessário.
6. Remover o grupo apenas quando nenhum outro utilizador ou policy precisar dele.
7. Limpar separadamente a reserva DHCP, o objeto host e a documentação.

Uma identidade produtiva não deve ser eliminada durante um incidente aberto antes de preservar Source IP, Rule ID e logs. Se a associação não estiver clara, primeiro limita-se o acesso e preservam-se as provas.

FAQ