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 Fusion (anteriormente 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.

Este guia mantém-se deliberadamente centrado no Sophos Firewall: valores do Fusion, encaminhamento DNS, Request Routes, DHCP, NAT, aceitação e rollback. O guia de configuração de rede explica a arquitetura independente do fabricante e as permissões; o guia de Locations cobre todo o respetivo ciclo de vida.

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 Fusion, 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 Fusion.
• 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 Fusion identifica o local como Location.
2. O Sophos Fusion 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 Fusion 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.

Não confundir os quatro percursos DNS

Para diagnosticar, é essencial saber onde cada consulta é processada:

• Serviço DNS Protection: o resolver cloud avalia consultas públicas segundo a Filtering Policy da Location detetada. Os relatórios ficam no Sophos Fusion, não no Log Viewer da firewall.
• Firewall como resolver: o cliente consulta um IP de interface da firewall por UDP ou TCP 53. O DNS local escolhe entre uma DNS Request Route e os forwarders em Network > DNS. Em Administration > Device access, DNS deve estar permitido para a zona de origem. Uma regra de firewall não autoriza este serviço local.
• DNS em trânsito: se um cliente consultar diretamente um resolver público, a firewall apenas encaminha tráfego. Aplica-se uma regra de firewall, mas não as DNS Request Routes. O log da regra prova o transporte, não o processamento pelo DNS Protection.
• Endpoint DNS Protection: o Sophos Endpoint interceta consultas Windows suportadas e envia-as por HTTPS para a Secure DNS Location. Uma regra NAT da porta 53 e as Request Routes da firewall não fazem parte deste percurso. Só domínios excluídos, ou a repetição NXDOMAIN opcional, usam a resolução DNS local.

No desenho recomendado, os clientes usam o resolver da firewall. O trânsito direto para os IPs de DNS Protection não é equivalente quando zonas internas dependem de Request Routes.

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. Xstream Protection cobre DNS Protection standalone para a firewall. Workspace Protection cobre DNS Protection para endpoints; o Sophos Endpoint tem de estar instalado. Ambas as licenças incluem DoH.

Para DNS Protection aparecer como produto no Sophos Fusion, a firewall com licença Xstream tem de estar associada à mesma conta Fusion. Verifique a licença em Administration > Licensing na firewall ou na página Firewall Licensing do Sophos Fusion. A Sophos documenta três métodos: registo durante a instalação, claim do número de série em Firewall Licensing ou ativação da gestão pelo Sophos Fusion no WebAdmin.

As decisões de licenciamento e as permissões do Fusion pertencem aos processos existentes de licenciamento do Sophos Fusion e funções administrativas. O responsável pela firewall precisa de acesso ao DNS Protection e aos valores aprovados do tenant, mas não deve ampliar funções como parte desta alteração.

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 Fusion

My Products > DNS Protection > Locations

1. Selecionar Add e introduzir um nome único em Name; usar Description para indicar a saída de Internet e o responsável.
2. Em Connection method, ativar Traditional DNS over IPv4.
3. Em IPv4 addresses or FQDNs, introduzir o IP WAN público ou um FQDN DDNS estável. Confirmar cada valor com Enter ou Tab.
4. Em Multi-WAN, incluir todos os endereços de saída usados. Os endereços detetados automaticamente não são atualizados após uma alteração.
5. Selecionar Save.

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, junto a IP addresses, estão disponíveis dois endereços IP do DNS Protection. Use Copy para copiar ambos os valores do seu próprio tenant do Fusion e utilize-os depois 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.

Na mesma página, use Copy junto a URL para copiar o endereço de teste. Se, ao abri-lo no browser, aparecer a mensagem de boas-vindas do DNS Protection, o percurso do resolver está corretamente configurado. Para diagnóstico posterior, https://dns.access.sophos.com é especialmente relevante: se apenas este nome não resolver ou o browser mostrar um erro em vez da mensagem de boas-vindas, isso indica uma fuga de DNS ou um redirecionamento pelo fornecedor.

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 Fusion.
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. Selecionar Apply.

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.

A partir do SFOS 21.5, o DNS Protection status widget no Control center mostra o estado da ligação. O Sophos Assistant também está disponível para configuração guiada e diagnóstico. O widget é um indicador operacional rápido; para validar o percurso completo, o acesso bem-sucedido ao endereço de teste e os relatórios do DNS Protection são mais conclusivos.

4. Encaminhar domínios internos

Network > DNS
DNS request route > 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, pela ordem pretendida; cada rota aceita até oito endereços IP

corp.example.com é um domínio de documentação e deve ser substituído pela zona realmente autoritativa internamente. Não encaminhe todo example.com se apenas uma subzona for interna. Se a pesquisa em cache de uma rota correspondente falhar, a firewall não consulta depois os forwarders públicos nem os root servers. A ordem e disponibilidade dos Target Servers fazem parte da resiliência.

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. Em Server, editar o servidor DHCP e anotar o endereço da Interface selecionada.
2. Em DNS server, desativar Use device’s DNS settings.
3. Introduzir o endereço da interface DHCP interna da firewall como Primary DNS.
4. Guardar, renovar a concessão do cliente de teste e verificar o resolver 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

Primeiro, em Administration > Device access, confirme que DNS está ativo para cada zona de origem afetada. Depois, uma regra DNAT opcional pode redirecionar o DNS tradicional para a firewall:

Rules and policies > NAT rules > IPv4 > Add NAT rule > New NAT rule

• Rule name: por exemplo redirect-client-dns-to-firewall
• Rule position: Top
• 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
• Translated source / Translated service: Original
• Inbound interfaces: apenas interfaces correspondentes às origens internas, nunca WAN

Internet IPv4 tem um âmbito amplo e só é adequado quando se pretende redirecionar todos os destinos DNS externos tradicionais. Restrinja ao máximo as redes de origem e as Inbound Interfaces. Os servidores DNS internos e dispositivos especiais precisam de exceções documentadas antes desta regra. 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, teste a resolução interna, a VPN e a rede de convidados. 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.

Este artigo verifica apenas se o percurso da firewall chega à Location correta e, assim, à política esperada. Criação, exceções, Safe Search, piloto e rollback estão em Configurar Filtering Policies do Sophos DNS Protection.

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.

O guia de Endpoint DNS Protection trata da configuração, Domain Exclusions internas e atribuição. O NAT, as Request Routes e o DHCP da firewall não substituem este percurso de endpoint.

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

Para verificar, distribuir, efetuar a rotação e remover o certificado, consulte Distribuir o certificado raiz do Sophos DNS Protection.

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 controlos têm de ser bem-sucedidos. Os comandos de cliente não foram executados aqui num ambiente SFOS 22; são comandos de diagnóstico só de leitura. O teste de configuração e os relatórios do Fusion fornecem a evidência do produto:

• 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.
• em DNS Protection > Logs & Reports, DNS usage by source mostra a Location após o atraso previsto e, para dados de endpoint, também o utilizador e o dispositivo.
• 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 Fusion

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.

Falta tráfego DNS apesar de a Location estar correta

Este sintoma inclui também No queries received from locations no dashboard e DNS Protection: Connectivity Error no Control center. Abra primeiro https://dns.access.sophos.com. Se a mensagem de boas-vindas não aparecer, teste por UDP e TCP 53 os dois endereços do tenant apresentados em Installers e confirme a saída WAN real.

Se as consultas chegarem a outro destino ou outro resolver responder, o router ou o ISP poderá estar a redirecionar DNS. Um teste Standard ou Extended em https://www.dnsleaktest.com/ ajuda a delimitar o problema: com DNS Protection, os valores na coluna Hostname contêm o padrão gw-<Nummer><Region>.dnsprotection.sophos.com; como ISP aparece Amazon ou uma designação correspondente. Se o teste mostrar exclusivamente outros resolvers, peça ao fornecedor para verificar um redirecionamento DNS. Se aparecerem resolvers Sophos e externos misturados, verifique as definições DNS da firewall, do servidor DNS interno e dos clientes, bem como resolvers IPv6 paralelos. https://ipleak.net/ pode servir de contraprova.

Mantenha apenas os dois endereços do tenant como forwarders, verifique routing, NAT e Packet Capture e resolva o redirecionamento com o fornecedor. Um terceiro resolver público seria apenas um bypass sem proteção.

Alguns clientes usam outro resolver

Verifique em conjunto DHCPv4, DHCPv6, Router Advertisements, perfil VPN e valores estáticos dos clientes. Um servidor DNS IPv6 adicional pode desviar consultas do DNS Protection. O DNS Protection funciona através de IPv4, mas resolve registos AAAA; destinos IPv6 não precisam de um resolver IPv6 separado.

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. Um nome de Location ou política alterado pode demorar de 30 minutos a quatro horas. Só depois verifique DHCP, DNS do cliente, DNS da firewall, redirecionamento NAT, resolvers alternativos, perfis VPN e associação à Location.

Em DNS Protection > Logs & Reports, comece por DNS usage by source e filtre por Location, Domain, Status ou Source IP. Para DNS encaminhado diretamente, uma regra com Log firewall traffic pode confirmar a passagem de UDP/TCP 53. Para o resolver da firewall, Administration > Device access é determinante; uma regra de firewall não prova a autorização ou recusa deste serviço local.

Os operadores de filtro, limites de exportação, atrasos e Live Discover estão documentados em Analisar relatórios do DNS Protection e Live Discover. No diagnóstico da firewall, confirme primeiro o percurso do resolver e só depois execute consultas de relatório mais profundas.

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.

Para a exceção restrita na firewall, crie um objeto FQDN para blockpage.dnsprotection.sophos.com. Uma regra Allow permite HTTP/HTTPS das zonas e redes internas afetadas para a zona WAN, usando este objeto como destino e sem Web Filter. Uma regra TLS correspondente usa os mesmos critérios com Do not decrypt. Não desative globalmente Pharming Protection nem TLS Inspection.

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.

Nos dispositivos Apple, o iCloud Private Relay também pode contornar o percurso DNS previsto. Por exemplo, se os iPhones não tiverem acesso à Internet, mas outros dispositivos no mesmo local funcionarem, desative primeiro Limit IP Address Tracking para o percurso de teste afetado e volte a testar. Uma alteração em toda a organização só deve ser feita depois deste teste limitado e da coordenação dos requisitos de privacidade.

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.

Rollback seguro

No percurso do local, desative primeiro o redirecionamento DNS para deixar de forçar os clientes para a firewall. Depois, restaure os resolvers anteriores em Network > DHCP, renove a lease do cliente de teste e verifique nomes públicos e internos. Só então restaure o modo ou servidores anteriores em Network > DNS. Mantenha inicialmente as Request Routes; não impedem o rollback e facilitam uma retoma controlada. Elimine a Location no Fusion apenas quando já não tiver redes ou políticas necessárias atribuídas.

Reverta Endpoint DNS Protection separadamente: em DNS Protection > Policies > Endpoint policies, remova a atribuição ou desative Use Sophos DNS Protection e confirme no dispositivo piloto que os resolvers do sistema ou das aplicações voltam a ser usados. O Root Certificate pode ser removido mais tarde pelo mesmo canal gerido usado na instalação.