Configurar Sophos DNS Protection com Sophos Firewall

O Sophos DNS Protection verifica consultas DNS através de um serviço cloud e gere políticas e relatórios no Sophos Central. Permite bloquear domínios maliciosos, phishing, destinos de Command-and-Control e categorias indesejadas antes de um cliente estabelecer a ligação propriamente dita.

Com o Sophos Firewall, a configuração padrão mais clara é geralmente: os clientes utilizam a firewall como resolver DNS, a firewall encaminha consultas públicas para o DNS Protection e os domínios internos seguem através de DNS Request Routes para servidores DNS internos.

O DNS Protection não substitui a Web Protection, os Threat Feeds nem o NDR e Active Threat Response. Complementa estes controlos ao nível do DNS.

Decisão e arquitetura pretendida

O DNS é uma função básica. Se o resolver for lento, instável ou demasiado restritivo, os utilizadores rapidamente interpretam o problema como uma falha geral da rede. Por isso, o DNS Protection só deve ser utilizado quando o valor das políticas do Central, categorias, registos ou proteção de clientes em roaming justificar o esforço operacional adicional.

Na perspetiva da Avanet, resolvers rápidos e redundantes, juntamente com Threat Feeds bem mantidos, são a solução mais pragmática para muitas instalações de firewall tradicionais. O DNS Protection é especialmente adequado quando:

• as consultas DNS devem ficar visíveis no Sophos Central.
• diferentes localizações precisam de políticas DNS distintas.
• as categorias devem ser bloqueadas já durante a resolução de nomes.
• os clientes não devem utilizar resolvers públicos arbitrários.
• endpoints Windows geridos devem permanecer protegidos fora da rede da empresa.

O percurso de firewall recomendado é o seguinte:

1. O Sophos Central identifica o local como Location.
2. O Sophos Central disponibiliza dois endereços IP de DNS Protection.
3. O Sophos Firewall utiliza ambos como DNS Forwarder.
4. As DNS Request Routes enviam zonas internas para servidores DNS internos.
5. O DHCP distribui a firewall aos clientes como resolver.
6. Opcionalmente, uma regra NAT força o DNS tradicional a seguir este percurso.
7. O Sophos Central regista e avalia as consultas DNS públicas.

É necessário distinguir dois métodos:

• Traditional DNS over IPv4: para firewalls, routers e resolvers locais. A Sophos associa as consultas à Location através do IP de origem público ou de um FQDN DDNS.
• Secure DNS: DNS over HTTPS (DoH) para dispositivos compatíveis. O Sophos Endpoint pode gerir este percurso em endpoints Windows suportados; Windows e macOS também podem ser configurados manualmente para Secure DNS.

Uma Location personalizada pode suportar ambos os métodos. Para o encaminhamento pela firewall, é necessário ativar Traditional DNS e indicar o IP público ou FQDN.

Antes do rollout, devem estar definidos a licença, endereços de saída públicos, zonas DNS internas, servidores DHCP e responsáveis por políticas e exceções. O Xstream Protection cobre o DNS Protection standalone. O Endpoint DNS Protection requer Workspace Protection e uma licença Sophos Endpoint adequada.

A Location predefinida Default pode ser utilizada para Secure DNS e atribuída a políticas, mas não pode ser editada nem eliminada. São permitidas no máximo 50 Locations e 100 entradas IPv4 públicas/FQDN por Location. As Locations devem, portanto, representar locais e saídas de Internet, não cada VLAN.

Configurar o DNS Protection

1. Criar uma Location no Sophos Central

My Products > DNS Protection > Locations

1. Selecionar Add e introduzir um nome inequívoco para o local.
2. Ativar Traditional DNS over IPv4.
3. Introduzir o IP WAN público ou um FQDN DDNS estável.
4. Em Multi-WAN, considerar todos os endereços de saída efetivamente utilizados.
5. Guardar a Location.

Os endereços IP privados não são válidos. A Sophos tem de reconhecer o IP de origem público pelo qual a consulta chega ao serviço. Para endereços dinâmicos, a Sophos verifica regularmente o nome DDNS, mas uma alteração ainda pode causar uma breve interrupção. No Cloudflare, o registo DDNS deve estar definido como DNS only e não pode passar pelo proxy.

Com CGNAT ou um IP partilhado do fornecedor, o endereço é associado à conta de cliente que o registar primeiro. Um FQDN não resolve o problema se apontar para o mesmo IP partilhado; é necessário um IP público exclusivo.

2. Copiar os endereços IP do DNS Protection

My Products > DNS Protection > Installers

Em Installers estão disponíveis dois endereços IP do DNS Protection. Copie sempre estes valores do seu próprio tenant do Central e utilize-os como DNS 1 e DNS 2. Um resolver externo como fallback adicional pode contornar a proteção e a visibilidade.

Os endereços IP continuam disponíveis com Secure DNS ativo. Para o percurso da firewall, é essencial que Traditional DNS também esteja configurado na Location com o endereço de saída público.

3. Configurar a firewall como DNS Forwarder

Network > DNS

1. Selecionar Static DNS.
2. Preencher DNS 1 e DNS 2 com os dois endereços do Central.
3. Deixar DNS 3 vazio, salvo um caso especial deliberadamente documentado.
4. Em IPv6, selecionar também Static DNS e não introduzir servidores DNS IPv6.
5. Ativar Choose IPv4 DNS server over IPv6.
6. Guardar a configuração.

O serviço funciona através de IPv4, mas também resolve registos AAAA e, portanto, destinos IPv6. Com SD-WAN, failover ou Policy Routing, o percurso de saída real deve corresponder a um endereço público registado na Location.

4. Encaminhar domínios internos

Network > DNS
DNS request route section > Add

O DNS Protection não resolve zonas internas. Para Active Directory, aplicações internas e pesquisas inversas são, por isso, necessárias DNS Request Routes.

Exemplo:

• Host/domain name: firma.local ou corp.example.com
• Target servers: controladores de domínio ou servidores DNS internos

O processo completo está descrito em Configurar DNS Request Routes no Sophos Firewall. Os domínios internos registados publicamente também devem ser permitidos numa lista de domínios se uma categoria como Parked Domains os bloquear.

5. Direcionar clientes para a firewall via DHCP

Network > DHCP

1. Editar o servidor DHCP da rede afetada.
2. Distribuir o IP da interface interna da firewall como servidor DNS.
3. Renovar a concessão num cliente de teste.
4. Verificar qual o resolver efetivamente utilizado.

A Sophos apresenta como exemplo o IP da firewall como Primary DNS e um IP do DNS Protection como Secondary DNS. No entanto, os clientes não tratam necessariamente a segunda entrada apenas como servidor de emergência. Consultas diretas ao DNS Protection contornam as DNS Request Routes da firewall. Em redes com Active Directory ou zonas internas, a redundância deve ser implementada no percurso do resolver, não através de um segundo DNS arbitrário no cliente.

6. Impedir o desvio direto do DNS

Uma regra DNAT opcional pode redirecionar para a firewall o tráfego DNS tradicional dos clientes internos:

• Original source: redes internas afetadas
• Original destination: grupo de hosts de saída ou Internet IPv4
• Original service: DNS
• Translated destination: IP interno da firewall
• Inbound interfaces: apenas interfaces correspondentes às origens internas, nunca WAN
• Position: no topo, antes de regras NAT mais gerais

As exceções para servidores DNS internos e dispositivos especiais devem ser documentadas. A regra abrange apenas DNS em UDP/TCP 53. DoH e DoT exigem controlos separados no browser, MDM, endpoint ou Web Policy. Antes da ativação, testar resolução interna, VPN, rede de convidados e registos. O mecanismo das regras é explicado em Compreender o NAT no Sophos Firewall.

Políticas, endpoints e páginas de bloqueio

Filtering Policy e listas de domínios

Uma Filtering Policy é atribuída a uma ou mais Locations em DNS Protection > Policies > Filtering policies. Só pode estar ativa uma Filtering Policy por Location. Além das categorias, podem ser definidas listas de domínios e opções como Safe Search.

As listas de domínios devem ter finalidade, Owner e data de revisão. Uma Allow list substitui decisões normais de categoria, mas não uma classificação SophosLabs como Threat ou Security Risk. Além disso, um domínio permitido pode continuar bloqueado se o seu destino CNAME pertencer a uma categoria bloqueada.

Estas decisões são especialmente importantes para as categorias:

• Infrastructure: normalmente permitir Content delivery, CRL e OCSP, pois atualizações e verificações de certificados podem depender destes serviços.
• Threats and liabilities: normalmente bloquear categorias como Phishing, Malware, Newly Registered Websites ou Anonymizers e resolver False Positives de forma direcionada.
• Data loss: avaliar armazenamento cloud e webmail segundo os requisitos de DLP e conformidade.
• Uncategorized: não bloquear indiscriminadamente; serviços novos, legítimos ou internos podem estar temporariamente sem categoria.
• Produtividade, Social Media e largura de banda: decidir conforme a rede e as necessidades do negócio, não como regra de segurança generalizada.

Endpoint DNS Protection

A Endpoint DNS Protection Policy destina-se a endpoints Windows geridos que também precisam de proteção fora da rede empresarial. O Sophos Endpoint interceta as consultas DNS e envia-as por HTTPS para a Secure-DNS-Location. A Filtering Policy associada determina a filtragem efetiva.

Atualmente, a política não suporta Windows Server nem macOS. Para macOS existe um percurso separado com perfil Secure DNS manual; Linux, dispositivos móveis e dispositivos especiais também exigem uma solução própria de rede, VPN ou MDM. Antes do rollout, verificar no Sophos Central os requisitos atuais do pacote Endpoint, pois podem mudar rapidamente.

As zonas internas são mantidas explicitamente como Domain Exclusions na Endpoint Policy. Isto é mais fiável do que uma repetição após NXDOMAIN e evita consultas externas desnecessárias. O DNS Protection Root Certificate pode ser distribuído automaticamente nos endpoints suportados.

Root Certificate e página de bloqueio

Para páginas de bloqueio HTTPS, os clientes têm de confiar no DNS Protection Root Certificate. Não é o mesmo certificado que a CA da firewall para TLS Inspection; a respetiva distribuição é descrita em Distribuir o certificado CA do Sophos Firewall para TLS Inspection.

O certificado e o teste de configuração estão disponíveis em DNS Protection > Installers. Além disso, blockpage.dnsprotection.sophos.com tem de estar acessível.

Em Web Proxy Mode, Pharming Protection pode interferir com a página de bloqueio. Antes de desativar funções de proteção globalmente, permita o domínio da página através de uma regra HTTP/HTTPS específica sem Web Filter e defina-o como Do not decrypt numa regra TLS.

Piloto, rollout e aceitação

Ative primeiro o DNS Protection numa pequena rede piloto. Documente zonas internas, pesquisas inversas e serviços críticos, configure DNS Request Routes e prepare um rollback claro para os resolvers anteriores. As redes de servidores precisam de uma janela de teste separada, pois licenciamento, atualizações, CRL/OCSP, backup ou comunicação do cluster podem depender do DNS.

Antes do rollout geral, estes testes têm de ser bem-sucedidos:

• um domínio público é resolvido através do resolver previsto.
• o domínio AD interno e a pesquisa inversa funcionam através de DNS Request Routes.
• o teste de configuração em Installers mostra a confirmação esperada.
• um domínio inofensivo, bloqueado intencionalmente por uma política de teste, é bloqueado e atribuído à Location correta.
• os registos aparecem no Sophos Central após o atraso de reporting esperado.
• a rede de convidados utiliza o percurso DNS planeado, mas não servidores DNS internos.
• o cliente VPN recebe resolvers e sufixos DNS adequados.
• Browser DoH, Private Relay ou perfis locais não contornam inesperadamente o controlo.
• o rollback para o resolver anterior foi testado ou está claramente documentado.

Comandos de teste para clientes

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux com systemd-resolved e dig instalado:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Substitua <firewall-ip> pelo endereço da interface interna do Sophos Firewall. Se a consulta explícita à firewall funcionar, mas a consulta normal não, a causa está geralmente no DHCP, VPN, Browser DoH ou numa configuração DNS local. Os comandos mostram o resolver utilizado pelo cliente e a respetiva resposta, mas não provam, por si só, que upstream a firewall utiliza.

Testar uma zona interna:

dig @<firewall-ip> interner-host.corp.example.com

Esta consulta tem de chegar ao servidor DNS interno através da DNS Request Route adequada.

Troubleshooting

A Location não aparece no Sophos Central

Verificar o IP WAN público, o FQDN DDNS e a saída Multi-WAN efetiva. Um IP de origem não configurado pode ser rejeitado pelo serviço DNS Protection. Para endereços dinâmicos, confirmar que o FQDN aponta externamente para o IP atual; os registos Cloudflare têm de estar definidos como DNS only.

Em My Environment > Alerts são apresentados FQDN inválidos e conflitos de IP. Com CGNAT ou saídas proxy/VPN partilhadas, prevalece a Location registada primeiro. Outro FQDN no mesmo IP não altera esta associação.

Os nomes internos deixaram de funcionar

Verificar DNS Request Routes, servidores DNS internos, zonas inversas, domínios de pesquisa e sufixos dos clientes. Garantir também que o cliente utiliza a firewall ou o resolver interno previsto, e não diretamente um IP do DNS Protection.

Um domínio interno ou legítimo é bloqueado

Verificar categorização, lista de domínios e destino CNAME. Uma exceção restrita é preferível à abertura de uma categoria inteira. As classificações SophosLabs Threat e Security Risk não podem ser substituídas por uma Allow domain list.

Os registos permanecem vazios

O dashboard e os relatórios têm um atraso de cerca de 15 a 25 minutos relativamente ao tempo real. Só depois verifique DHCP, DNS do cliente, DNS da firewall, redirecionamento NAT, resolvers alternativos, perfis VPN e associação à Location.

Com EDR, XDR ou MDR, Threat Analysis Center > Live Discover também pode analisar dados do DNS Protection como Domain, Policy Action, Location e Source IP. Os campos de utilizador e dispositivo estão disponíveis nos relatórios padrão para dados de endpoint, não no esquema DNS de firewall documentado do Live Discover.

A página de bloqueio não aparece

Verificar o DNS Protection Root Certificate, o percurso DNS e a acessibilidade de blockpage.dnsprotection.sophos.com. Em Web Proxy Mode, verificar também Pharming Protection, a regra HTTP/HTTPS e a exceção TLS Do not decrypt. VPN, Browser DoH e Apple Private Relay também podem fazer o teste contornar o DNS Protection.

DoH ou Private DNS contorna o controlo

Um redirecionamento NAT da porta 53 não abrange DoH ou DoT. As políticas do browser, sistema operativo e MDM têm de controlar estes resolvers. O Secure DNS no DNS Protection utiliza DoH; não está documentado um modo DNS Protection próprio através de DoT.

Os clientes VPN comportam-se de forma diferente dos clientes LAN

Verificar servidores DNS atribuídos, sufixos DNS, Split DNS, Full ou Split Tunnel e resolvers locais. O DNS Protection pode funcionar no escritório e continuar a ser contornado no acesso remoto. A escolha básica de VPN é explicada em Sophos Connect ou SSL VPN: qual a solução de acesso remoto adequada?.

Operação

O DNS Protection não é uma simples substituição pontual do servidor DNS. Verifique regularmente:

• Locations, endereços de saída públicos e resolução DDNS.
• definições DHCP e DNS Request Routes internas.
• políticas, listas de domínios, Owner e datas de revisão.
• principais domínios bloqueados e False Positives documentados.
• novos locais, redes de convidados, percursos VPN e plataformas endpoint.
• distribuição do certificado e acessibilidade do domínio da página de bloqueio.
• relatórios após alterações e o percurso de rollback definido.

Quem não pretender operar estes pontos permanentemente obtém frequentemente melhores resultados com resolvers robustos e controlos de proteção direcionados. O DNS Protection compensa onde as políticas, reporting e proteção dos endpoints são realmente utilizados e monitorizados.