Planear e configurar a rede para o Sophos DNS Protection

O Sophos DNS Protection pode proteger um resolvedor DNS central de uma localização ou ligar diretamente dispositivos compatíveis através de Secure DNS. Assim, a decisão principal não é o fabricante da firewall, mas onde o DNS é resolvido, como se mantêm as zonas internas e como a Sophos identifica a Location.

Percurso rápido: numa rede gerida de uma localização, o resolvedor local existente deve normalmente continuar a ser o servidor DNS dos clientes. Este encaminha apenas consultas públicas para os dois endereços IP do DNS Protection apresentados no Sophos Fusion (anteriormente Sophos Central). As zonas internas continuam a ser encaminhadas para os servidores DNS internos autoritativos. O Secure DNS é adequado a dispositivos individuais geridos e utilizadores móveis. Teste primeiro ambos os percursos com um pequeno grupo-piloto e nunca configure um resolvedor público desprotegido como terceira alternativa.

Arquitetura de destino e âmbito de responsabilidade

O percurso de rede tem quatro funções distintas:

O cliente envia a consulta para o resolvedor atribuído por DHCP, VPN, MDM ou configuração local.
Um resolvedor local escolhe entre zonas internas e nomes públicos.
A firewall, o router e o NAT determinam o IP de origem público e a saída real.
O DNS Protection associa a consulta a uma Location, aplica a respetiva policy e devolve a resposta.

Com Secure DNS, o dispositivo envia a consulta ao DNS Protection por DNS over HTTPS (DoH). Este percurso ignora o forwarder DNS local. O redirecionamento da porta 53, a cache local e o conditional forwarding não se aplicam neste caso.

Este artigo descreve a arquitetura independente do fabricante e os requisitos para firewalls de terceiros. A configuração específica do dispositivo encontra-se em Configurar o Sophos DNS Protection com o Sophos Firewall.

Pré-requisitos, licença e funções

Antes de alterar a rede, é necessário que existam a Location prevista e um acesso autorizado ao Sophos Fusion. Confirme antecipadamente o direito de utilização: o DNS Protection autónomo aplica-se com Xstream Protection, enquanto o Endpoint DNS Protection requer Workspace Protection e Secure DNS. Estes dois modelos de implementação utilizam percursos de dados diferentes e não devem ser tratados como intercambiáveis.

A Location tem de ser criada antes da implementação nos dispositivos. Em seguida, o responsável por cada plataforma distribui os valores do tenant com base nas instruções adequadas para o dispositivo e configura Windows, macOS ou Windows Server, conforme o destino. Os dispositivos Windows geridos são encaminhados para o responsável pela Endpoint DNS Protection Policy, em vez de se manterem perfis manuais. A instalação, renovação e remoção da confiança pertencem ao processo separado do DNS Protection Root Certificate, não a este procedimento de configuração.

Escolher Traditional DNS ou Secure DNS

Local resolver ou Firewall forwarder

Escolha este percurso quando uma localização já utiliza um router, uma firewall, Windows DNS ou outro Local resolver. O resolvedor local ou Firewall forwarder envia as consultas públicas para a Sophos por Traditional DNS over IPv4. O DNS Protection identifica a Location pelo endereço IPv4 de origem público ou pelo FQDN guardado na Location.

As vantagens são caches centrais, um percurso uniforme para vários tipos de dispositivo e conditional forwarding para zonas internas. A limitação: por trás do mesmo IP de origem público, o DNS Protection vê a localização, mas não automaticamente cada utilizador ou dispositivo. Um endereço de saída variável, partilhado ou incorreto pode impedir a associação.

Manual device DNS ou Secure DNS

Manual device DNS configura diretamente no dispositivo os dois endereços IP do DNS Protection. Secure DNS, por sua vez, utiliza DoH sobre HTTPS e é adequado a dispositivos geridos, clientes móveis e redes onde não seja possível alterar o resolvedor local. Protege o percurso do dispositivo também fora do escritório. Contudo, nomes internos, split DNS da VPN e aplicações com resolvedor próprio têm de ser considerados explicitamente. Uma configuração manual do dispositivo não equivale à implementação gerida do Workspace através de uma Endpoint Policy.

Para este percurso, abra ou crie a Location prevista, ative Secure DNS e selecione Save. O Sophos Fusion gera então o DNS over HTTPS URL específico da localização. Entregue o URL completo ou o perfil gerado ao responsável por Windows, macOS ou MDM. Para Sophos Endpoint, o responsável pela Endpoint Policy recebe a Location e o grupo-piloto para selecionar essa Location na policy. Não construa o URL nem utilize um URL de outra Location.

Escolha recomendada

Localização com Active Directory ou zonas internas: resolvedor local com conditional forwarding; encaminhe apenas consultas públicas para o DNS Protection.
Rede simples sem zonas internas: o DHCP pode distribuir diretamente os dois endereços do DNS Protection, desde que a Location conheça o IP de saída público.
Dispositivos móveis geridos: Secure DNS, complementado por exceções internas definidas e testes de VPN.
Ambiente misto: utilize o percurso da localização e Secure DNS em paralelo, mas documente qual é o percurso determinante para cada classe de dispositivo. A interceção dupla dificulta a resolução de problemas.

Inventário e regras de rede

Antes da alteração, registe estes valores:

os dois endereços IP do DNS Protection em My Products > DNS Protection > Installers no seu próprio tenant;
todos os endereços IPv4 públicos de saída realmente utilizados em operação normal, failover WAN, SD-WAN, VPN ou proxies centrais;
zonas forward e reverse internas, os respetivos resolvedores autoritativos e sufixos de pesquisa;
valores DNS de DHCP, VPN e configurações estáticas em cada rede;
dispositivos ou aplicações com DoH, DoT, VPN ou resolvedor fixo próprios;
o resolvedor anterior, o TTL das opções DHCP, os responsáveis, a janela de manutenção e o percurso de retorno.

Em Installers, clique em Copy junto de IP addresses e utilize sempre os dois endereços apresentados. O download Certificate pertence ao processo separado de certificados; para apresentar Block Pages HTTPS, este DNS Protection Root Certificate tem de ser considerado fidedigno nos dispositivos. Não deve ser confundido com uma CA para a inspeção HTTPS da firewall.

Para Traditional DNS, ambos os endereços do tenant têm de estar acessíveis por UDP 53 e TCP 53: a partir dos resolvedores locais autorizados no modo com forwarder ou apenas das sub-redes cliente ou piloto autorizadas no modo de cliente direto. UDP é o caso normal; TCP é necessário, entre outros casos, para respostas maiores ou truncadas. O DNS Protection é um resolvedor baseado em IPv4, mas consegue resolver registos AAAA e, consequentemente, destinos IPv6. Nenhum resolvedor IPv6 separado e desprotegido pode contornar o percurso planeado.

Para Secure DNS, os dispositivos necessitam de TCP 443 de saída para os destinos DoH fornecidos pela Sophos. As Block Pages HTTPS também requerem TCP 443 e acesso a blockpage.dnsprotection.sophos.com. A inspeção TLS não pode interromper silenciosamente a ligação; a exceção concreta tem de ser estritamente limitada ao percurso de destino Sophos documentado.

Restrinja a regra da porta 53 aos endereços apresentados no tenant como destinos e separe as origens conforme o desenho: os resolvedores locais previstos no modo com forwarder ou as sub-redes cliente ou piloto autorizadas no modo de cliente direto. Não é necessária uma regra WAN de entrada. Um proxy DNS a montante, um redirecionamento DNS do ISP ou um captive portal transparente pode alterar as respostas e tem de ser detetado durante o piloto.

Planear Location, saída e redundância

Traditional DNS só funciona quando o IP de origem público visível da consulta corresponde a uma Location no Sophos Fusion. Os endereços privados RFC 1918 não devem ser utilizados nesta associação. Para uma saída dinâmica, pode utilizar-se um FQDN DDNS estável, mas este tem de resolver publicamente para o endereço atual. Com CGNAT ou um IP partilhado com outros clientes, não é possível garantir uma associação inequívoca; um IP público exclusivo é a solução correta.

Em multi-WAN, inventarie todos os endereços de saída possíveis e adicione-os à Location adequada. Em seguida, comute de forma controlada e teste ambos os percursos. O policy routing não pode enviar DNS por uma saída desconhecida. Se os IP públicos se sobrepuserem entre tenants, a Sophos indica que a associação criada primeiro tem prioridade.

A Sophos fornece dois endereços de resolvedor. Configure ambos como um par primário/secundário equivalente. Um terceiro resolvedor público não oferece redundância, mas constitui um desvio: os resolvedores nem sempre reservam os servidores alternativos para uma falha total e podem utilizar em paralelo o servidor mais rápido. A verdadeira resiliência inclui também dois resolvedores locais, distribuição DHCP/VPN redundante e um percurso de failover WAN testado.

Procedimento de configuração independente do fabricante

No Sophos Fusion, em My Products > DNS Protection > Network setup, escolha a opção adequada entre Local resolver, Firewall forwarder, Windows DNS, Manual device DNS e Secure DNS. Em seguida, confirme a Location e o método de ligação previstos. Para Traditional DNS, todos os endereços públicos de saída utilizados em produção têm de ser conhecidos.
Para Traditional DNS, copie ambos os endereços de resolvedor do seu próprio tenant em My Products > DNS Protection > Installers. Não utilize valores de exemplo nem endereços de outro tenant.
Para Secure DNS, crie ou edite a Location, ative Secure DNS, selecione Save e copie o DNS over HTTPS URL gerado especificamente para a localização. Entregue exatamente esse URL ou o perfil gerado ao responsável por Windows, macOS ou MDM. O responsável pela Sophos Endpoint Policy recebe a Location e o grupo-piloto para selecionar essa Location na Endpoint Policy.
No modo com forwarder, configure os dois endereços Sophos como os únicos forwarders para consultas públicas no resolvedor local ou na firewall de terceiros: um como Primary DNS server e o outro como Secondary DNS server. Mantenha conditional forwarders ou stub zones para as zonas forward e reverse internas. Se o produto disponibilizar um terceiro servidor DNS, não adicione aí outro resolvedor público, pois a mudança para este contornaria a proteção.
Separe a regra da firewall de saída conforme o desenho: no modo com forwarder, permita UDP/TCP 53 apenas dos resolvedores locais autorizados para ambos os endereços Sophos; no modo de cliente direto, apenas das sub-redes piloto ou cliente autorizadas para ambos os endereços. Bloqueie a porta 53 para todas as outras origens de acordo com o desenho documentado de prevenção de desvios.
Para Secure DNS, permita TCP 443 apenas dos dispositivos autorizados para o destino DoH gerado e para o destino necessário das Block Pages. Limite estritamente as exceções à inspeção TLS.
No modo com forwarder, direcione os âmbitos DHCP e VPN do piloto para o resolvedor local. No modo de cliente direto, distribua os dois endereços Sophos à sub-rede piloto autorizada. Inventarie separadamente os dispositivos estáticos.
O responsável por Windows, macOS ou MDM deve distribuir o URL ou perfil Secure DNS gerado apenas ao grupo-piloto. Para Sophos Endpoint, o responsável pela policy seleciona a Location fornecida na Endpoint Policy e atribui essa policy ao grupo-piloto fornecido. Documente a Location, a policy, o grupo e o método de remoção.
Renove a cache e as leases existentes apenas no piloto e de forma controlada. Uma limpeza global da cache gera carga desnecessária e dificulta a comparação.
Restrinja percursos DNS alternativos apenas após uma validação bem-sucedida.

Limites da prevenção de desvios

O DNS clássico pode ser limitado permitindo UDP/TCP 53 de saída apenas aos resolvedores locais autorizados no modo com forwarder ou às sub-redes cliente ou piloto autorizadas no modo de cliente direto. Redirecionar destinos desconhecidos da porta 53 para o resolvedor próprio pode ajudar com dispositivos difíceis de gerir, mas deve excluir servidores DNS internos, VPN, redes de convidados e dispositivos que exijam resolvedores específicos. Quando os clientes são geríveis, bloquear é mais transparente do que redirecionar.

Este controlo não abrange DoH em TCP 443, DoT em TCP 853 nem a resolução de nomes dentro de um túnel VPN de terceiros. Não bloqueie indiscriminadamente TCP 443. As policies do browser, do sistema operativo, do MDM e do endpoint têm de controlar Secure DNS não autorizado; a utilização conhecida de DoT pode ser tratada especificamente. O Apple Private Relay e serviços de privacidade semelhantes também requerem uma decisão de desenho própria.

Se apenas dispositivos iPhone ficarem sem acesso à Internet, apesar de a resolução funcionar noutros dispositivos, desative Limit IP Address Tracking a título de teste para a rede afetada e volte a testar. Efetue esta alteração deliberadamente apenas em dispositivos-piloto, pois afeta uma funcionalidade de privacidade do dispositivo.

A prevenção de desvios termina na fronteira administrativa. Numa rede BYOD ou de convidados, uma policy documentada e menos restritiva é frequentemente mais robusta do que tentar impor todos os resolvedores cifrados sem gestão dos dispositivos.

Piloto, validação e aceitação

Comece com uma VLAN representativa ou alguns dispositivos. Teste, pelo menos, nomes públicos, FQDN internos, pesquisas inversas, VPN, acesso de convidados, failover WAN e um bloqueio de teste inofensivo.

Antes da alteração, defina uma janela de observação e critérios explícitos de reversão. Reverta o piloto se a resolução interna ou da VPN falhar, surgir a Location ou policy errada, a ligação DoH/TLS permanecer instável ou um destino empresarial necessário for afetado; não expanda a implementação enquanto um destes critérios continuar ativo.

nslookup example.com <resolver-ip>
nslookup internal-host.corp.example <resolver-ip>

Com dig instalado:

dig @<resolver-ip> example.com A
dig @<resolver-ip> example.com AAAA
dig @<resolver-ip> internal-host.corp.example
dig +tcp @<resolver-ip> example.com

Substitua <resolver-ip> pelo resolvedor local ou, para utilização direta, por um endereço do tenant. corp.example é uma zona de documentação e tem de ser substituída pela sua zona interna. O teste TCP confirma que não funciona apenas UDP.

Em seguida, abra num browser o URL de teste copiado em Installers > Check your configuration. A mensagem de boas-vindas confirma o percurso do DNS Protection, mas não confirma por si só a policy correta. Bloqueie também deliberadamente um domínio de teste inofensivo e confirme no Sophos Fusion se a consulta, a Location e a policy aparecem como esperado. Os relatórios não são necessariamente apresentados em tempo real; por isso, não conclua que existe uma falha imediatamente após uma única consulta.

A aceitação exige que:

os dois resolvedores Sophos funcionem separadamente por UDP e TCP;
as zonas forward e reverse internas permaneçam internas;
a saída esperada seja associada à Location correta;
o bloqueio e os destinos empresariais permitidos funcionem;
failover WAN, VPN e clientes compatíveis com IPv6 não criem um percurso alternativo;
o DNS não autorizado na porta 53 seja bloqueado ou redirecionado conforme o desenho;
os pilotos Secure DNS manuais para Windows, macOS e MDM utilizem exatamente o URL ou perfil gerado, enquanto os pilotos Sophos Endpoint estão atribuídos a uma policy com a Location prevista; ambos aparecem na Location e policy previstas e passam os testes no escritório, em roaming, por VPN, para domínios internos e durante a remoção;
a monitorização e um percurso de retorno testado estejam documentados.

Operação e verificação regular

Após o piloto, implemente por fases, localização ou VLAN. Em cada fase, monitorize erros DNS, pedidos ao suporte técnico, domínios empresariais bloqueados e a associação da saída. Migre por último servidores estáticos e dispositivos OT/IoT, numa janela de manutenção própria.

Após alterações à WAN, NAT, DHCP, VPN, IPv6 ou aos resolvedores locais, volte a verificar o percurso DNS. O mesmo se aplica ao mudar de ISP ou ao utilizar um novo endereço público de saída. Confirme regularmente se ambos os resolvedores do tenant continuam configurados, se as zonas internas são resolvidas localmente e se nenhum servidor DNS adicional contorna a proteção. Inclua os avisos em My Environment > Alerts e o estado em My Products > DNS Protection no processo operacional.

Reversão segura ou desativação

Para reverter, desative primeiro as novas regras que bloqueiam ou redirecionam DNS. Em seguida, execute a opção adequada ao tipo de implementação:

Modo com forwarder: reponha ativamente no resolvedor local os forwarders anteriores documentados. Em seguida, verifique a resolução interna e pública.
Modo de cliente direto: reponha os valores DNS anteriores documentados no DHCP, na VPN e nos clientes estáticos. Renove as leases nos dispositivos de teste e, em seguida, verifique a resolução interna e pública.
Secure DNS: o responsável por Windows, macOS ou MDM remove o perfil piloto; o responsável pela Sophos Endpoint Policy remove, por sua vez, a atribuição do grupo-piloto. Em seguida, reponha o estado DNS anterior e confirme que o percurso DoH já não é utilizado.

Mantenha inicialmente os conditional forwarders e a Location no Sophos Fusion, exceto se a própria Location tiver causado o incidente.

Resolução de problemas por sintoma

Os nomes públicos não são resolvidos

Teste explicitamente os dois endereços Sophos por UDP e TCP. Em seguida, verifique a regra de saída, o NAT, a rota e o IP de origem público visível. Se o IP de origem não estiver associado a uma Location ou entrar em conflito com outro tenant, o DNS Protection pode rejeitar as consultas. Com DDNS, confirme também a resolução pública do FQDN.

Os nomes internos ou o Active Directory falham

Confirme qual o resolvedor realmente utilizado pelo cliente. Em seguida, verifique os conditional forwarders, servidores de destino autoritativos, zonas reverse, sufixos de pesquisa e split DNS da VPN. Um resolvedor DNS Protection distribuído diretamente não conhece zonas privadas.

Só falham respostas grandes ou alguns domínios

Teste TCP 53. Se UDP funcionar, mas dig +tcp não, normalmente falta a regra TCP ou um produto intermédio descarta a ligação. Se um domínio permitido continuar bloqueado, confirme também o destino CNAME e a classificação de segurança.

O Sophos Fusion não mostra a Location ou mostra a errada

Determine a saída real em vez de consultar apenas o endereço WAN configurado. SD-WAN, gateways NAT centrais, proxies e failover podem alterar o IP de origem. Em seguida, aguarde tempo suficiente para os relatórios e confirme que o teste utilizou o resolvedor previsto, não DoH do browser ou uma VPN.

Para uma Location definida por FQDN, confirme também a resolução pública. Num registo DNS da Cloudflare, tem de estar selecionado Proxy status: DNS only; um registo com proxy não devolve o verdadeiro endereço público de saída. Um endereço privado ou IPv6 não é um endereço válido para uma Location. Se o mesmo valor público já estiver associado a outro cliente ou se o FQDN for inválido, corrija a associação antes de prosseguir com a implementação.

A Block Page não aparece, embora o bloqueio DNS funcione

Isto não prova que o domínio foi permitido. Verifique o acesso a blockpage.dnsprotection.sophos.com, a confiança no DNS Protection Root Certificate, o Pharming Protection, o proxy ou filtro Web e a inspeção TLS. Se a firewall desencriptar o percurso da Block Page, utilize a ação estritamente limitada Do not decrypt para o percurso de destino Sophos documentado. A instalação e a remoção do certificado devem ser sempre geridas através do processo da plataforma responsável.

Um domínio permitido continua bloqueado

Confirme primeiro o nome de destino CNAME e a respetiva categoria: um domínio inicial permitido pode continuar a apontar para um nome bloqueado devido à categoria ou ao Threat Score. Após uma alteração da policy, aguarde também pelo TTL do DNS e pelas caches locais ou renove-as de forma controlada. Não acelere a implementação com exceções genéricas e abrangentes.

O controlo contra desvios não funciona

Procure nos registos tráfego UDP/TCP 53, TCP 853 e ligações Secure DNS conhecidas de saída. Em seguida, verifique o browser, o sistema operativo, a VPN e o software de segurança local. Um filtro na porta 53 não consegue detetar nem impedir DNS cifrado em 443.

O DNS é resolvido, mas faltam a policy e os relatórios

Comece por utilizar ipconfig, nslookup ou, em Linux e macOS, dig para confirmar quais os resolvedores realmente utilizados pelo dispositivo. Em seguida, execute um teste Standard ou Extended em https://www.dnsleaktest.com/. Ao utilizar o DNS Protection, todos os valores da coluna Hostname contêm o padrão gw-<número>.<região>.dnsprotection.sophos.com; como ISP aparece Amazon ou uma designação correspondente. Outros resolvedores indicam uma fuga de DNS ou um redirecionamento pelo ISP.

Se https://dns.access.sophos.com apresentar um erro no browser em vez da página de boas-vindas e, ao mesmo tempo, o dashboard mostrar No queries received from locations ou uma Sophos Firewall comunicar DNS Protection: Connectivity Error, corrija primeiro o percurso de resolvedor divergente. Para isso, verifique o DNS do router, DHCP e DHCPv6, entradas DNS estáticas, redirecionamento do ISP e resolvedores IPv6 paralelos. Só depois deve investigar a policy ou os relatórios; este procedimento de teste aplica-se ao percurso de rede, não ao Endpoint DoH sem uma verificação específica.

Instruções relacionadas existentes

Configurar o Sophos DNS Protection com o Sophos Firewall mostra a integração concreta no SFOS.
Endpoint DNS Protection Policy descreve o percurso Workspace gerido separado para endpoints.