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

Planear antecipadamente a interrupção: Antes de Change status, documentar o estado atual, as regras afetadas e o procedimento previsto para repor o estado anterior. Realizar o teste negativo apenas num dispositivo piloto controlado e numa janela acordada: a desativação pode interromper as ligações necessárias desse dispositivo. Para o teste, criar uma nova ligação, em vez de observar apenas uma sessão já em curso. Se ocorrer um efeito inesperado, repor o estado anteriormente documentado e voltar a verificar a ligação original.

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 se verificam todos os pontos seguintes:

• 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. Este exemplo é validado com IPv4. Antes de utilizar IPv6, verificar explicitamente a associação Clientless e a configuração de regras adequada à versão do SFOS instalada; uma validação bem-sucedida com IPv4 não comprova o funcionamento com IPv6.

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 devem 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, criar um grupo próprio:

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

As políticas específicas do utilizador têm prioridade sobre as políticas do grupo atribuído. Por isso, o grupo deve 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.

MAC binding, User type and profile e as políticas de VPN de acesso remoto também não estão disponíveis para Clientless Users. Por conseguinte, a identidade clientless baseada em IP não fornece uma associação ao dispositivo nem autentica um utilizador VPN.

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, definir os campos 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.

Depois de Save, em Authentication > Clientless users, abrir Edit para o utilizador. Em Traffic shaping (quality of service), é possível selecionar uma política existente ou criar uma nova. Quarantine digest envia uma lista das mensagens de correio eletrónico em quarentena para a caixa de correio do utilizador; num dispositivo sem uma caixa de correio associada, esta função permanece desativada. Depois de guardar, voltar a verificar as políticas efetivamente aplicadas ao utilizador e ao grupo, bem como o fluxo previsto.

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.

Para um bloco aprovado, em Add range, introduzir o primeiro endereço de dispositivo em From IP, o último em To IP e selecionar o grupo Clientless previamente preparado em Group. Exemplo: de 192.0.2.50 a 192.0.2.52 corresponde a três endereços de dispositivos controlados; ambos os limites têm de ser substituídos pelos do bloco reservado na própria rede. Guardar com Save e, em seguida, abrir cada utilizador criado em Authentication > Clientless users, através de Edit, para verificar o IP, o grupo e as políticas individuais necessárias. Para cada dispositivo, verificar a associação esperada em Live Users e os fluxos permitidos e não permitidos; um teste bem-sucedido do dispositivo piloto não substitui a validação das restantes entradas.

Para verificar a lista em Authentication > Clientless users, clicar em Show additional properties e selecionar os campos necessários. É possível alterar a ordem na lista pendente arrastando e largando os campos; confirmar com Ok. Esta vista facilita a comparação das entradas, mas não substitui a abertura e a verificação da configuração individual.

API XML: distinguir Add, Add range e Update

O procedimento GUI acima não é uma receita XML. As referências da API para SFOS 22.0 e 23.0 deixam por esclarecer questões importantes sobre a representação de Add e Update:

• Add: A tabela assinala Username, Group, Name e Email como obrigatórios e define-os, tal como IP Address e Spam Digest, como ARRAY. No entanto, o exemplo mostra apenas um ClientlessUser com valores individuais, incluindo UserName e ClientLessGroup. Isto não demonstra uma associação segura entre utilizadores, IP, grupos e endereços de correio eletrónico nem um lote executável. A indicação de que os duplicados não serão ignorados não explica como são processados. Introduzir Email apenas quando necessário na GUI acima não elimina o requisito da API; Add range é um procedimento GUI distinto, não uma prova de um serializador de arrays. O exemplo coloca expressamente <!--only for Edit --> antes de QoSPolicy e Status; não deduzir daí campos de Add nem um estado predefinido.
• Update: Username, Name, Group e IP Address passam a ser SCALAR, enquanto Email continua a ser um ARRAY obrigatório. A tabela exige também Web Filter, App Filter e QOS; o exemplo não mostra tags de filtros nem demonstra a correspondência de QOS com QoSPolicy. Copiar o exemplo de Add não fornece, portanto, um Update cuja completude esteja demonstrada.
• Digest: O exemplo inclui também ApplyGroupSettings para QuarantineDigest, mas a tabela de Update só indica Disable e Enable para Spam Digest. O seu valor predefinido é literalmente Disbale: um valor incoerente na referência, não um valor predefinido confirmado em execução. Não deduzir daí a herança do grupo nem o comportamento dos campos omitidos; Add também não especifica um valor predefinido para o digest.

Esclarecer o contrato do build instalado antes de alterações pela API que dependam destes detalhes; enquanto a representação não estiver clara, utilizar o procedimento GUI suportado com Edit ou Change status. Antes de uma alteração, registar os valores anteriores reais de políticas, digest e estado. Depois, comparar com precisão a identidade, o IP, o grupo e as políticas guardados e testar novos fluxos permitidos e bloqueados. Se ocorrer um efeito inesperado, repor os valores originais em vez de restabelecer supostos valores predefinidos e verificar novamente. Estas limitações da documentação não invalidam a herança do grupo na GUI.

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, selecionar o utilizador piloto e usar 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 e verificar a respetiva Firewall Rule ID atual; uma sessão já em curso não é suficiente para este teste.

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, registar a versão e o build do firmware e planear 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 política, 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. Neste contexto, não se pressupõe que a transferência sem interrupções da associação Clientless esteja garantida. Após um failover controlado, voltar a verificar 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.

Guardar os valores de utilização antes de um reset: Com o utilizador aberto, View usage mostra a utilização da Internet registada. Reset user accounting limpa estas estatísticas; a ajuda atual da Sophos também refere o reinício da Network Traffic Quota, mas a mesma página assinala Network traffic policy como não suportada para Clientless Users. Por isso, o reset não deve ser utilizado para reparar uma quota. Primeiro, documentar os contadores e a atribuição real de políticas. Os valores individuais de Traffic shaping e Quarantine digest têm prioridade sobre as definições do grupo Clientless.

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 política 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, limitar primeiro o acesso e preservar as provas.

FAQ