Usar corretamente FQDN hosts e wildcard FQDNs no Sophos Firewall

Os hosts FQDN são úteis quando um destino não pode ser descrito de forma confiável com um endereço IP fixo. Exemplos típicos são serviços em nuvem, servidores de atualização, terminais de autenticação ou serviços de fornecedores cujos endereços IP podem mudar.

Um host FQDN não substitui uma política da web, nem controle total de URL e nem uma garantia de que todos os aplicativos corresponderão de forma limpa. A questão importante é como o Sophos Firewall resolve o nome ou, no caso de curingas, aprende-o a partir do tráfego DNS.

Quando os hosts FQDN fazem sentido

Os hosts FQDN atendem às regras em que um destino técnico é melhor descrito por um nome DNS do que por endereços IP individuais. Isto é especialmente útil para tráfego de saída.

Exemplos úteis:

Um servidor interno só pode se conectar a updates.vendor.example .
Um aplicativo precisa de acesso a alguns FQDNs de fornecedores conhecidos.
Um endpoint de nuvem específico deve ser usado em uma regra de firewall, regra NAT, rota SD-WAN ou configuração de VPN.
Um caso de solução de problemas deve mostrar se uma regra corresponde ao nome esperado ou a um endereço IP inesperado.

Os hosts FQDN são menos adequados para acesso amplo à Web, como “tudo em um serviço SaaS”, quando o aplicativo usa muitos domínios, CDNs, APIs, telemetria e pontos de extremidade de login. Para tráfego da web, políticas da web, grupos de URL, proteção DNS, controle de aplicativos ou inspeção TLS costumam ser a melhor camada de controle.

O Sophos Firewall pode usar hosts FQDN não apenas em regras de firewall, mas também em configurações como SD-WAN policy routes, VPN settings e objetos técnicos para servidores de e-mail, proxy, DNS, autenticação, remote access, web ou syslog. Mesmo assim, em cada uso deve-se verificar se um nome DNS é realmente mais estável que um objeto IP ou uma camada de política dedicada.

Para a regra de firewall em si, comece com entender e configurar regras do Sophos Firewall com segurança. Se uma regra não corresponder, use regra do Sophos Firewall não corresponde: verificar as causas.

Host FQDN normal ou FQDN curinga

O Sophos Firewall lida com hosts FQDN normais e FQDNs curinga de maneira diferente. Este é o detalhe operacional mais importante.

Host FQDN normal

Para um host FQDN normal, como updates.vendor.example , o firewall resolve o nome por meio de DNS. Os endereços IP retornados são usados para o objeto. Se o registro DNS tiver um TTL, o firewall atualizará a resolução depois que o TTL expirar.

No SFOS 22 aplica-se um limite IPv6 importante: os objetos host FQDN não resolvem endereços IPv6. Isto não impede DNS Lookup nem clientes normais de receber respostas AAAA, mas o próprio objeto não mantém estes destinos IPv6. Suporte IPv6 e limites na Sophos Firewall com SFOS 22 distingue este limite das restantes funções suportadas e não suportadas.

Isso funciona bem quando:

o FQDN aponta diretamente para os endereços IP necessários,
o aplicativo usa exatamente esse nome,
as respostas DNS não alternam constantemente entre muitos alvos CDN,
o teste usa a mesma resolução de nome que o firewall vê.

FQDN curinga

Para um FQDN curinga, como *.example.com , o firewall não resolve simplesmente “todos os subdomínios possíveis”. O DNS não fornece uma lista completa de todos os subdomínios.

Em vez disso, o firewall aprende endereços IP correspondentes a partir de respostas DNS. Para isso, tem de ver as respostas correspondentes; no caso de DNS em trânsito, learn-subdomains também tem de estar ativado. O tráfego DNS visível, por si só, não garante uma aprendizagem bem-sucedida. Os mecanismos de aprendizagem documentados são:

Sophos Firewall é o servidor DNS dos clientes.
Ou o tráfego DNS passa pelo firewall e é detectado pelo DPI.
De acordo com a Sophos, esse aprendizado se aplica ao tráfego DNS UDP na porta 53 para servidores DNS externos.

Se os clientes usarem DNS sobre HTTPS, DNS sobre TLS, outro caminho DNS ou um resolvedor local, o firewall poderá não ver as respostas DNS relevantes. Um FQDN curinga pode permanecer vazio ou incompleto mesmo que o domínio funcione no navegador.

Crie um host FQDN

O caminho do menu é:

Hosts and services > FQDN host > Add

Apenas alguns campos são importantes para um objeto limpo:

Name: descritivo e tecnicamente estável, por exemplo fqdn_vendor_updates ou wfqdn_example_subdomains .
FQDN: o nome completo, por exemplo updates.vendor.example ou *.example.com .
FQDN host group: opcionalmente selecionar um grupo existente ou criar um novo grupo. Um host FQDN pode pertencer a vários FQDN host groups.
Grafia: escreva FQDNs em letras minúsculas. A Sophos afirma que letras maiúsculas em hosts FQDN não são suportadas.

Depois de preencher os campos, salvar o objeto com Save.

Depois de salvar, não coloque imediatamente o objeto às cegas nas regras de produção. Execute primeiro um breve teste: o firewall resolve o nome, o Log Viewer mostra posteriormente o IP de destino esperado e esse IP corresponde à resposta DNS do cliente?

Agrupar vários hosts FQDN

Um FQDN host group reúne vários hosts FQDN existentes num único objeto reutilizável. Os grupos podem ser selecionados, entre outros locais, em regras de firewall e SD-WAN policy routes.

Aceda a Hosts and services > FQDN host group > Add. Introduza uma designação exclusiva em Name, selecione os hosts necessários e clique em Save. Para uma aplicação com endpoints separados, o grupo grp_vendor_service poderia conter login.vendor.example, api.vendor.example e updates.vendor.example. Um host pode pertencer a vários grupos. Inclua apenas os nomes necessários, porque cada host adicional alarga todas as regras que utilizam o grupo.

As listas FQDN host e FQDN host group permitem pesquisar por qualquer atributo apresentado. Antes de alterar ou eliminar um objeto, verifique separadamente que regras de firewall, SD-WAN policy routes ou outras configurações o utilizam. Uma alteração num grupo partilhado afeta todas essas utilizações.

Uso em regras de firewall

Na maioria dos designs, um host FQDN pertence às regras de saída em Destination networks . A regra então descreve quais fontes internas podem se conectar a qual destino dinâmico.

Fluxo típico:

Crie o objeto FQDN em Hosts and services > FQDN host .
Abra ou crie a regra correspondente em Rules and policies > Firewall rules .
Defina Source zones e Source networks and devices de forma restrita.
Escolha Destination zones deliberadamente, geralmente WAN .
Selecione o objeto FQDN em Destination networks .
Permita apenas as portas necessárias em Services , por exemplo HTTPS .
Habilite o registro em log.
Execute um teste real e verifique o Rule ID, IP de destino, Rule ID NAT e serviço no Log Viewer.

Um host FQDN não torna uma regra segura por si só. Se Source for Any , Service for Any e Destination for um objeto curinga amplo, o resultado pode rapidamente se tornar muito aberto. Uma regra pequena com fonte clara, serviço claro, registro ativo e finalidade documentada é melhor.

Caso especial: grupos predefinidos para regras Web Proxy

Os grupos predefinidos SafeSearch enforcement, YouTube restrictions enforcement e Google app enforcement destinam-se exclusivamente a regras que impõem SafeSearch, restrições do YouTube ou inícios de sessão no Google Workspace através do Web Proxy. Não substituem uma lista personalizada de destinos SaaS gerais.

Antes de ativar uma regra deste tipo, certifique-se de que os dispositivos do grupo-piloto confiam na CA, defina as exclusões de desencriptação adequadas e prepare testes de aceitação HTTP e HTTPS específicos. O procedimento está descrito em implementar gradualmente a TLS Inspection no Sophos Firewall.

Na regra de firewall dedicada, defina Action como Allow e Destination zones como WAN. Em Destination networks, selecione os grupos predefinidos necessários e, em Services, HTTP e HTTPS. Ative também Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering. Coloque a regra acima das regras que processam o mesmo tráfego com o motor DPI.

Depois do teste, confirme no Log Viewer e num browser que apenas o grupo piloto previsto utiliza esta regra e que a restrição necessária funciona. Para reverter, desative a nova regra proxy e confirme que o tráfego volta a ser processado pela regra DPI inferior. Elimine a regra proxy apenas depois de confirmar esse estado.

Limites e armadilhas

Muitos problemas de FQDN não vêm da lista de regras, mas do comportamento DNS de clientes ou aplicativos.

O firewall vê diferentes respostas de DNS

Se o cliente e o firewall usarem resolvedores DNS diferentes, eles poderão receber endereços IP diferentes para o mesmo nome. Isso é normal com CDNs. Uma regra pode então corresponder a um IP enquanto o cliente usa outro.

Ao solucionar problemas, compare:

Qual IP nslookup ou dig retorna no cliente?
Qual IP de destino aparece no Log Viewer?
Quais servidores DNS o cliente e o firewall usam?
O DNS está usando a porta 53 , DNS sobre HTTPS ou DNS sobre TLS?

Wildcard FQDN não aprende nada

Um FQDN curinga só funciona se o firewall detectar as respostas DNS correspondentes. Se um cliente usar DoH no navegador ou um caminho DNS que não passe pelo firewall, o firewall não poderá aprender os subdomínios. No caso de tráfego DNS que apenas atravessa o firewall, verifique também se learn-subdomains está ativado. Este é um requisito adicional, não uma garantia de sucesso.

Nesses casos, mover a regra do firewall não é a solução. Em vez disso, decida o design do DNS: use o firewall como encaminhador de DNS, roteie o tráfego DNS através do firewall de maneira controlada ou use outra camada de controle para o tráfego da web.

O FQDN é muito amplo

Um curinga como *.example.com pode incluir muito mais do que o pretendido. Os serviços SaaS modernos usam domínios de login, domínios API, CDNs de mídia, telemetria, serviços de suporte e terceiros. Às vezes, um único objeto curinga é muito grosseiro.

Se o acesso precisar ser amplo por design, uma política da Web, um grupo de URLs ou um Controle de Aplicativos geralmente será mais fácil de entender e revisar do que uma regra de firewall FQDN muito grande.

Vários domínios apontam para o mesmo IP

A Sophos documenta explicitamente que os hosts FQDN não suportam vários domínios que resolvem para o mesmo endereço IP. Um objeto FQDN trabalha com os endereços IP resolvidos e não consegue distinguir esses domínios entre si na camada IP. Por isso, não se deve esperar uma separação fiável dos domínios com este tipo de objeto.

Para decisões web baseadas em domínio, a camada web é, portanto, mais adequada do que uma regra de firewall pura baseada em IP com um objeto FQDN.

Solução de problemas

Se uma regra FQDN não se comportar conforme esperado, primeiro verifique a conexão real. O nome no objeto não é decisivo; o endereço IP usado no momento do teste é.

A regra não corresponde

Verificar:

A zona de origem corresponde?
O IP de origem ou a rede de origem correspondem?
O serviço corresponde, por exemplo, TCP 443 em vez de apenas HTTP ?
O Log Viewer mostra outro ID de regra?
O Log Viewer mostra um IP de destino que não corresponde à resposta DNS atual?
Existe uma regra mais geral ativa acima da regra FQDN?

Se o Log Viewer mostrar outra regra, a ordem das regras será mais importante do que o objeto FQDN. Se o Log Viewer não mostrar nada, a ausência de tráfego no firewall ou o registo inativo são causas possíveis, mas não as únicas. Verifique também o módulo selecionado e os filtros de tempo, campo e pesquisa. As sessões das regras de firewall só são registadas quando a ligação é encerrada com um evento Destroy recebido; se a ligação terminar sem esse evento, o registo da sessão pode estar em falta. Uma ligação ainda aberta também deve, portanto, ser tida em conta. Utilize um Packet Capture direcionado para verificar se os pacotes de teste chegam ao firewall; um Log Viewer vazio, por si só, não prova o contrário.

Wildcard FQDN permanece vazio

Verificar:

O cliente utiliza o firewall como servidor DNS?
O DNS é visível através do firewall?
O cliente usa DoH ou DoT?
O UDP 53 é usado?
No caso de DNS em trânsito, learn-subdomains está ativado? As respostas DNS visíveis, por si só, não garantem um Binding aprendido.
Existe uma rota de solicitação de DNS ou um resolvedor interno que oculta a resposta antes que o firewall a veja?

Se o DNS for roteado internamente intencionalmente, configurar DNS request routes no Sophos Firewall ajuda no design do DNS.

DNS alterado, regra reage mais tarde

Os objetos FQDN funcionam com respostas e caches DNS. Se o destino de um fornecedor for alterado, poderá haver um atraso até que o firewall use o novo estado. Para hosts FQDN normais, o TTL do registro DNS é decisivo.

Na Device Console, a Sophos disponibiliza a família de comandos de sistema set fqdn-host; esta não altera apenas um objeto host selecionado. cache-ttl utiliza dns-reply-ttl por predefinição ou pode ser definido entre 60 e 86400 segundos. idle-timeout remove bindings não utilizados após um intervalo configurável entre 60 e 86400 segundos; o valor predefinido é 3600 segundos. eviction controla se e após que intervalo são removidos os endereços IP aprendidos para subdomínios wildcard; o intervalo vai de 60 a 86400 segundos. learn-subdomains ativa ou desativa a aprendizagem destes endereços a partir do tráfego em trânsito que atravessa o firewall, mas não tem origem nem destino nele. Quando cache-ttl é alterado, o novo valor aplica-se apenas a entradas resolvidas posteriormente; as entradas já em cache mantêm o valor anterior até expirarem.

Não altere estes valores como primeira medida. Verifique primeiro se o design DNS, o caminho do resolvedor e a base de regras estão corretos. Antes de qualquer alteração, registe todos os valores atuais, altere apenas um parâmetro de cada vez e teste o efeito com novas resoluções. Para reverter, restaure o valor inicial registado; no caso do TTL predefinido, esse valor é dns-reply-ttl. O ajuste deve integrar um procedimento documentado de operação ou suporte.

Recomendação operacional

Os hosts FQDN permanecem gerenciáveis quando são tratados como dependências técnicas, e não como exceções espontâneas.

Boa prática:

Documente uma finalidade clara para cada objeto FQDN.
Use curingas com moderação.
Combine objetos FQDN com definições restritas de origem e serviço.
Habilite o registro em log para regras novas ou críticas.
Teste alterações com Log Viewer e pesquisa de DNS.
Não oculte o amplo acesso à Web em uma regra FQDN grande.
Para serviços SaaS ou em nuvem, verifique regularmente se o fornecedor exige domínios adicionais.

A documentação da CLI indica até 16.000 hosts FQDN. No entanto, para SFOS 22, a Sophos documenta um limite máximo conjunto de 16.000 hosts para todos os tipos de host; não se deve deduzir daí uma capacidade FQDN adicional e independente nem uma reserva livre. Este limite máximo não é um convite ao crescimento sem controlo. Muitas exceções FQDN antigas dificultam revisão, troubleshooting e manutenção de regras. Uma lista menor e documentada de objetos com responsável, finalidade e data de revisão é melhor.

Se um objeto foi criado apenas porque “um aplicativo não funciona”, revise-o mais tarde. Estes objectos de emergência tornam-se frequentemente excepções permanentes que são difíceis de explicar.

FAQ

Qual é a diferença entre um host FQDN e um host IP?

Um host IP descreve um endereço ou rede fixa. Um host FQDN descreve um nome DNS cujos endereços IP atuais o firewall pode usar. Isso ajuda com destinos dinâmicos, mas depende da resolução do DNS e do comportamento do cache.

`*.example.com` funciona automaticamente para todos os subdomínios?

Não como uma lista completa de domínios. O firewall deve ver as respostas DNS correspondentes e aprender os endereços IP delas. Se o DNS não estiver visível através do firewall, um FQDN curinga poderá permanecer incompleto.

Por que minha regra FQDN não corresponde?

Normalmente, o contexto da regra, a ordem ou o IP de destino realmente utilizado não coincidem. No Log Viewer, verifique qual ID de regra, IP de destino, Porta de destino e ID de regra NAT aparecem durante o teste real.

Os hosts FQDN funcionam com DNS sobre HTTPS ou DNS sobre TLS?

Os FQDNs curinga são problemáticos quando os clientes usam DoH ou DoT e o firewall não consegue ver as respostas DNS. O firewall não poderá aprender com segurança os subdomínios necessários.

Os hosts FQDN devem ser usados para filtragem da web?

Apenas seletivamente. Para um controle real da web, políticas da web, grupos de URL, proteção DNS, controle de aplicativos ou inspeção TLS geralmente são mais adequados. Os hosts FQDN são úteis para destinos técnicos em regras de rede, mas não são uma política de URL completa.