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.

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. Isso funciona de maneira confiável quando o firewall consegue ver o tráfego DNS:

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?

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.

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.

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 ressalta que os hosts FQDN não se destinam a distinguir claramente vários domínios quando eles resolvem para o mesmo endereço IP. Na camada IP, o firewall nem sempre pode saber qual domínio um aplicativo usará posteriormente.

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, o tráfego não alcança o firewall ou o log não está ativo.

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

A Sophos oferece opções CLI para hosts FQDN, como cache-ttl, idle-timeout, eviction e learn-subdomains. cache-ttl pode usar o TTL da resposta DNS ou um valor entre 60 e 86400 segundos. idle-timeout remove bindings não usados por padrão após 3600 segundos. eviction controla quando endereços IP aprendidos de subdomínios wildcard são removidos. Quando cache-ttl é alterado, o novo valor vale apenas para novas resoluções; entradas já em cache mantêm o valor anterior até expirarem.

Esses valores não devem ser alterados como primeira reação. Primeiro deve-se verificar se o design DNS, o caminho do resolvedor e a base de regras estão corretos. O ajuste pertence a 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 Sophos indica até 16.000 hosts FQDN, mas isso não é um convite ao crescimento sem controle. 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.