Configurare Sophos DNS Protection con Sophos Firewall

Sophos DNS Protection controlla le richieste DNS tramite un servizio cloud e gestisce policy e report in Sophos Fusion (in precedenza Sophos Central). Consente di bloccare domini malevoli, phishing, destinazioni Command-and-Control e categorie indesiderate prima che un client stabilisca la connessione effettiva.

Con Sophos Firewall, la configurazione standard più pulita è generalmente questa: i client utilizzano il firewall come resolver DNS, il firewall inoltra le richieste pubbliche a DNS Protection e i domini interni vengono inviati ai server DNS interni tramite DNS Request Routes.

DNS Protection non sostituisce Web Protection, Threat Feeds o NDR e Active Threat Response. Integra questi controlli a livello DNS.

Questa guida rimane volutamente focalizzata su Sophos Firewall: valori Fusion, inoltro DNS, Request Routes, DHCP, NAT, collaudo e rollback. La guida alla configurazione di rete descrive l’architettura indipendente dal produttore e le autorizzazioni; la guida alle Locations ne copre l’intero ciclo di vita.

Decisione e architettura di destinazione

DNS è una funzione di base. Se il resolver è lento, instabile o troppo restrittivo, per gli utenti il problema appare rapidamente come un’interruzione generale della rete. DNS Protection dovrebbe quindi essere utilizzato solo quando il valore aggiunto delle policy Fusion, delle categorie, dei log o della protezione dei client in roaming giustifica l’ulteriore impegno operativo.

Dal punto di vista di Avanet, resolver veloci e ridondanti insieme a Threat Feeds ben mantenuti sono la soluzione più pragmatica per molte installazioni firewall tradizionali. DNS Protection è particolarmente adatto quando:

• le richieste DNS devono essere visibili in Sophos Fusion.
• sedi diverse richiedono policy DNS differenti.
• le categorie devono essere bloccate già durante la risoluzione dei nomi.
• i client non devono utilizzare resolver pubblici arbitrari.
• gli endpoint Windows gestiti devono essere protetti anche fuori dalla rete aziendale.

Scegliere prima la versione: a partire da SFOS 23.0, utilizzare il percorso DoH integrato con assegnazione del firewall descritto di seguito. I riferimenti a IP sorgente pubblico, DDNS, due forwarder statici e assegnazione della Location descrivono il percorso Traditional DNS di SFOS 22 e precedenti, non i requisiti del nuovo percorso firewall. Endpoint Secure DNS rimane separato.

Il percorso Traditional DNS su SFOS 22 e precedenti è il seguente:

1. Sophos Fusion identifica la sede come Location.
2. Sophos Fusion fornisce due indirizzi IP di DNS Protection.
3. Sophos Firewall utilizza entrambi gli indirizzi come DNS Forwarder.
4. Le DNS Request Routes inviano le zone interne ai server DNS interni.
5. DHCP distribuisce il firewall ai client come resolver.
6. Facoltativamente, una regola NAT forza il traffico DNS tradizionale su questo percorso.
7. Sophos Fusion registra e valuta le richieste DNS pubbliche.

Occorre distinguere tra due metodi:

• Traditional DNS over IPv4: per firewall, router e resolver locali. Sophos assegna le richieste alla Location in base all’IP sorgente pubblico o a un FQDN DDNS.
• Secure DNS: DNS over HTTPS (DoH) per dispositivi compatibili. Sophos Endpoint può gestire questo percorso sugli endpoint Windows supportati; Windows e macOS possono anche essere configurati manualmente per Secure DNS.

Una Location personalizzata può supportare entrambi i metodi. Per l’inoltro tramite firewall devono essere configurati Traditional DNS e l’IP pubblico o il FQDN.

Tenere distinti i quattro percorsi DNS

Per la diagnosi è essenziale sapere dove viene elaborata una query:

• Servizio DNS Protection: il resolver cloud valuta le query pubbliche con la Filtering Policy della Location rilevata. I report sono in Sophos Fusion, non nel Log Viewer del firewall.
• Firewall come resolver: il client interroga un IP di interfaccia del firewall su UDP o TCP 53. Il servizio DNS locale sceglie tra una DNS Request Route e i forwarder in Network > DNS. In Administration > Device access, DNS deve essere consentito per la zona sorgente. Una regola firewall non può autorizzare questo servizio locale.
• DNS in transito: se un client interroga direttamente l’IP di un resolver pubblico, il firewall inoltra soltanto il traffico. Si applica una regola firewall, ma non le DNS Request Routes. Il log della regola prova quindi il transito, non l’elaborazione da parte di DNS Protection.
• Endpoint DNS Protection: Sophos Endpoint intercetta le query Windows supportate e le invia tramite HTTPS alla Secure DNS Location. Una regola NAT per la porta 53 e le Request Routes del firewall non fanno parte di questo percorso. Solo i domini esclusi, o il retry NXDOMAIN opzionale, usano la risoluzione DNS locale.

Nel modello consigliato i client usano il resolver del firewall. Il transito diretto verso gli IP DNS Protection non è equivalente quando le zone interne dipendono dalle Request Routes.

Prima del rollout vanno chiariti licenza, indirizzi di uscita pubblici, zone DNS interne, server DHCP e responsabili di policy ed eccezioni. Xstream Protection copre DNS Protection standalone per il firewall. Workspace Protection copre DNS Protection per gli endpoint; sui dispositivi deve essere installato Sophos Endpoint. Entrambe le licenze includono DoH.

Affinché DNS Protection compaia come prodotto in Sophos Fusion, il firewall con licenza Xstream deve essere collegato allo stesso account Fusion. Verificare la licenza in Administration > Licensing sul firewall o nella pagina Firewall Licensing di Sophos Fusion. Sophos indica tre metodi: registrazione durante l’installazione, claim del numero di serie in Firewall Licensing o attivazione della gestione Sophos Fusion in WebAdmin.

Le decisioni sulle licenze e le autorizzazioni Fusion appartengono ai processi esistenti per le licenze Sophos Fusion e i ruoli amministrativi. Il responsabile del firewall deve accedere a DNS Protection e ai valori del tenant approvati, senza ampliare i ruoli durante questa modifica.

La Location predefinita Default può essere utilizzata per Secure DNS e assegnata alle policy, ma non può essere modificata o eliminata. Sono consentite al massimo 50 Locations e 100 voci IPv4 pubbliche/FQDN per Location. Le Locations dovrebbero quindi essere definite per sede e uscita Internet, non per ogni VLAN.

SFOS 23.0: configurare e migrare DNS Protection tramite DoH

A partire da SFOS 23.0, l’opzione integrata DNS Protection utilizza DNS over HTTPS (DoH). La Filtering Policy viene assegnata all’oggetto firewall, non più alla precedente Location IP/FQDN. Sono necessari Xstream Protection e la registrazione del firewall in Sophos Fusion; in HA devono essere registrati entrambi i firewall. Prima della modifica, documentare le impostazioni DNS precedenti, l’assegnazione della policy e i valori della Location per il rollback.

Prima della migrazione: verificare se la Location esistente rappresenta esclusivamente il percorso DNS di questo firewall oppure se viene utilizzata anche da altri resolver o da Endpoint Secure DNS. In caso di utilizzo condiviso, non rimuovere la Location dalla Filtering Policy a cui è attualmente assegnata e non eliminarla. Eseguire la sostituzione descritta di seguito solo dopo aver chiarito separatamente e preservato l’assegnazione della policy per gli altri sistemi che la utilizzano; fino ad allora, interrompere la migrazione.

Attivare la protezione e assegnare una policy

1. Sul firewall, attivare DNS Protection in Network > DNS.
2. Decidere consapevolmente se utilizzare Fall back to DNS server: se l’opzione è attiva, occorre configurare un server DNS in DNS server settings. Senza questa opzione, non è possibile configurarvi server DNS quando DNS Protection è attivo. Un resolver esterno di fallback migliora la disponibilità, ma può aggirare il filtraggio e la visibilità di DNS Protection quando il servizio non è raggiungibile. Documentare la decisione e il resolver di riserva; DoH verso un provider qualsiasi non equivale automaticamente a DNS Protection.
3. In Sophos Fusion, aprire My Products > DNS Protection > Policies > Filtering policies. Per una nuova configurazione, selezionare Add policy, scegliere il firewall in Locations and firewalls > Available e spostarlo in Assigned to this policy. Type deve indicare Firewall; il nome contiene l’etichetta del firewall e il numero di serie. Definire i filtri previsti in Settings e salvare la policy.

Sostituire un’assegnazione Traditional DNS esistente

Dopo l’aggiornamento e l’attivazione di DNS Protection, aprire la Filtering Policy esistente. In Locations and firewalls, spostare la Location creata per questo firewall da Assigned to this policy ad Available. Spostare poi il firewall da Available ad Assigned to this policy e selezionare Save. La vecchia Location può essere eliminata solo dopo il salvataggio. Avanet consiglia di conservarla fino al superamento del collaudo pilota; non eliminarla se altri resolver o dispositivi ne hanno ancora bisogno. Questa migrazione non si applica ai resolver di terze parti né a Endpoint Secure DNS.

Verificare il pilot ed eseguire il rollback

I client continuano a utilizzare il firewall come resolver. Le successive procedure per DNS Request Routes, DHCP e reindirizzamento NAT opzionale della porta 53 restano valide; non eseguire anche le vecchie procedure per Location e forwarder statici. In Network > DNS > Test name resolution, inserire un nome pubblico in Hostname or IP address e selezionare Test connection. Verificare server, protocollo utilizzato, risultato e tempo di risposta. Dal client pilota, verificare anche nomi interni, reverse lookup e un dominio innocuo bloccato appositamente dalla policy. Controllare l’assegnazione del firewall in Fusion e i report DNS Protection; la sola risoluzione riuscita non dimostra l’efficacia della Filtering Policy. Non estendere il rollout finché il pilot non ha avuto esito positivo. Questa guida non è stata testata in laboratorio su un firewall SFOS 23.

Per il rollback, riassegnare prima la Location Traditional DNS conservata alla policy precedente, rimuovere l’assegnazione del firewall e selezionare Save. Disattivare poi DNS Protection sul firewall e ripristinare la configurazione DNS precedente documentata in DNS server settings. Sono campi SFOS 23, non i nomi dei campi SFOS 22 mostrati di seguito. Conservare le Request Routes e i valori DNS dei client rimasti invariati, quindi ricontrollare risoluzione pubblica e interna e filtraggio. Se la Location è già stata eliminata, ricrearla con i valori documentati prima di questo rollback.

XML API: modifiche documentate, ma nessuna procedura sicura da copiare

La documentazione XML API di SFOS 23 per DNS List aggiunge DNSProtection con Enabled e Fallback, DNSProtocol, DNSOverHTTPS con DNSServer1 fino a DNSServer3 e con URL, IPv4Address e IPv6Address, oltre a FallbackToUnencryptedDns e DNSSecProtection. I commenti nell’esempio subordinano le impostazioni IPv4/IPv6 a UnencryptedDNS e il blocco DoH a DNSOverHTTPS; per DoH è richiesto DNSServer1 e per ogni server viene indicato un indirizzo IPv4 oppure IPv6. Queste condizioni documentate non costituiscono una procedura API completamente chiarita e testata qui.

Due conflitti rimangono irrisolti: SFOS 22 chiama il selettore DNSQueryConfiguration e usa valori testuali. La tabella di SFOS 23 indica invece DNS Query Configuration e 0, 1, 2, 3, senza mostrare nell’esempio il tag XML o la corrispondenza dei valori. Il commento su DNSProtocol indica contemporaneamente che il campo è obbligatorio e che UnencryptedDNS è il valore in caso di omissione. Da ciò non si possono dedurre un tag con spazi, una corrispondenza numerica, un’omissione sicura, una compatibilità automatica o un valore predefinito sicuro.

Percorso attuale sicuro: la procedura ambigua relativa al selettore e all’omissione è espressamente esclusa da queste indicazioni. Per SFOS 23, utilizzare il percorso WebAdmin descritto sopra in Network > DNS, decidere consapevolmente protocollo e fallback e verificare nel pilot le impostazioni salvate, il protocollo effettivamente utilizzato, l’assegnazione del firewall alla Filtering Policy, la risoluzione interna e l’efficacia del filtraggio. Se è necessaria l’automazione, interrompere l’operazione fino al chiarimento del produttore su questi campi per la versione interessata; un’interfaccia funzionante non conferma uno schema XML o REST.

DNSProtection/Fallback e DNSOverHTTPS/FallbackToUnencryptedDns sono impostazioni distinte: la prima riguarda la risoluzione alternativa quando DNS Protection non è raggiungibile, la seconda il passaggio da DoH a DNS non crittografato. La perdita di protezione e visibilità e la perdita della crittografia del trasporto sono rischi diversi. Non equipararle e non adottare valori booleani predefiniti non comprovati; verificare esplicitamente entrambe le decisioni. DoH verso un provider qualsiasi non equivale a Sophos DNS Protection e DNSSecProtection non è né DoH né un’assegnazione a una Filtering Policy. Da queste incertezze non viene generato alcun XML DNS globale eseguibile.

XML API: SFOS 22 — DNS List; SFOS 23 — DNS List.

Configurare DNS Protection

Traditional DNS su SFOS 22 e versioni precedenti: i passaggi 1–3 descrivono il precedente percorso IP/FQDN. I passaggi 4–6 restano rilevanti anche per il percorso integrato di SFOS 23.

1. Creare una Location in Sophos Fusion

My Products > DNS Protection > Locations

1. Selezionare Add e inserire un nome univoco in Name; usare preferibilmente Description per indicare uscita Internet e responsabile.
2. In Connection method, attivare Traditional DNS over IPv4.
3. In IPv4 addresses or FQDNs, inserire l’IP WAN pubblico o un FQDN DDNS stabile. Confermare ogni valore con Enter o Tab.
4. In Multi-WAN, includere tutti gli indirizzi di uscita usati. Gli indirizzi rilevati automaticamente non vengono aggiornati automaticamente dopo una modifica.
5. Selezionare Save.

Gli indirizzi IP privati non sono validi. Sophos deve riconoscere l’IP sorgente pubblico con cui la richiesta raggiunge il servizio. Per gli indirizzi dinamici, Sophos controlla regolarmente il nome DDNS, ma dopo una modifica può comunque verificarsi una breve interruzione. Con Cloudflare, il record DDNS deve essere impostato su DNS only e non deve passare dal proxy.

Con CGNAT o un IP condiviso del provider, l’indirizzo viene assegnato all’account cliente che lo registra per primo. Un FQDN non risolve il problema se punta allo stesso IP condiviso; è necessario un IP pubblico univoco.

2. Copiare gli indirizzi IP di DNS Protection

My Products > DNS Protection > Installers

In Installers, accanto a IP addresses, sono disponibili due indirizzi IP di DNS Protection. Utilizzare Copy per copiare entrambi i valori dal proprio tenant Fusion e usarli poi come DNS 1 e DNS 2. Un resolver esterno aggiunto come fallback può aggirare la protezione e la visibilità.

Gli indirizzi IP sono disponibili anche quando Secure DNS è attivo. Per il percorso firewall è determinante che nella Location sia configurato anche Traditional DNS con l’indirizzo di uscita pubblico.

Nella stessa pagina, Copy accanto a URL consente di copiare l’indirizzo di test. Se aprendolo nel browser compare il messaggio di benvenuto di DNS Protection, il percorso del resolver è configurato correttamente. Per la diagnosi successiva è particolarmente utile https://dns.access.sophos.com: se solo questo nome non viene risolto o il browser mostra un errore anziché il messaggio di benvenuto, ciò indica un DNS leak o un reindirizzamento da parte del provider.

3. Configurare il firewall come DNS Forwarder

Network > DNS

1. Selezionare Static DNS.
2. Inserire i due indirizzi Fusion in DNS 1 e DNS 2.
3. Lasciare vuoto DNS 3, salvo un caso speciale deliberatamente documentato.
4. Per IPv6 selezionare anche Static DNS e non inserire server DNS IPv6.
5. Attivare Choose IPv4 DNS server over IPv6.
6. Selezionare Apply.

Il servizio funziona tramite IPv4, ma può risolvere anche record AAAA e quindi destinazioni IPv6. Con SD-WAN, failover o Policy Routing, il percorso di uscita effettivo deve corrispondere a un indirizzo pubblico registrato nella Location.

A partire da SFOS 21.5, il DNS Protection status widget nel Control center mostra lo stato della connessione. Per la configurazione guidata e la diagnosi è inoltre disponibile Sophos Assistant. Il widget è un rapido indicatore operativo; per il collaudo del percorso completo sono più significativi l’accesso riuscito all’indirizzo di test e i report di DNS Protection.

4. Inoltrare i domini interni

Network > DNS
DNS request route > Add

DNS Protection non risolve zone interne. Per Active Directory, applicazioni interne e reverse lookup sono quindi necessarie DNS Request Routes.

Esempio:

• Host/domain name: firma.local o corp.example.com
• Target servers: controller di dominio interni o server DNS, nell’ordine desiderato; ogni route accetta al massimo otto indirizzi IP

corp.example.com è un dominio di documentazione e va sostituito con la zona realmente autoritativa all’interno. Non instradare tutto example.com se è interna solo una sottozona. Se la ricerca in cache di una route corrispondente fallisce, il firewall non interroga anche i forwarder pubblici o i root server. Ordine e raggiungibilità dei Target Servers fanno quindi parte dell’alta disponibilità.

La procedura completa è descritta in Configurare DNS Request Routes su Sophos Firewall. I domini interni registrati pubblicamente dovrebbero inoltre essere consentiti in una lista di domini se vengono bloccati da una categoria come Parked Domains.

5. Indirizzare i client al firewall tramite DHCP

Network > DHCP

1. In Server, modificare il server DHCP interessato e annotare l’indirizzo dell’Interface selezionata.
2. In DNS server, deselezionare Use device’s DNS settings.
3. Inserire l’indirizzo dell’interfaccia DHCP interna del firewall come Primary DNS.
4. Salvare, rinnovare il lease del client di test e verificare il resolver effettivamente usato.

Sophos mostra come esempio l’IP del firewall come Primary DNS e un IP di DNS Protection come Secondary DNS. Tuttavia, i client non trattano necessariamente la seconda voce come un semplice server di emergenza. Le richieste dirette a DNS Protection aggirano le DNS Request Routes del firewall. Nelle reti con Active Directory o zone interne, la ridondanza dovrebbe quindi essere realizzata nel percorso del resolver e non tramite un secondo server DNS arbitrario sul client.

6. Impedire l’aggiramento diretto del DNS

Prima verificare in Administration > Device access che DNS sia attivo per ogni zona sorgente interessata. Una regola DNAT facoltativa può quindi reindirizzare al firewall il traffico DNS tradizionale:

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

• Rule name: ad esempio redirect-client-dns-to-firewall
• Rule position: Top
• Original source: reti interne interessate
• Original destination: gruppo host in uscita o Internet IPv4
• Original service: DNS
• Translated destination: IP interno del firewall
• Translated source / Translated service: Original
• Inbound interfaces: solo le interfacce corrispondenti alle sorgenti interne, mai WAN

Internet IPv4 ha un ambito ampio ed è adatto solo se si vogliono reindirizzare tutte le destinazioni DNS esterne tradizionali. Limitare il più possibile le reti sorgente e le Inbound Interfaces. I server DNS interni e i dispositivi speciali richiedono eccezioni documentate prima di questa regola. La regola intercetta solo DNS su UDP/TCP 53. DoH e DoT richiedono controlli separati tramite browser, MDM, endpoint o Web Policy. Prima dell’attivazione, verificare la risoluzione interna, la VPN e la rete guest. Il funzionamento delle regole è spiegato più in dettaglio in Comprendere il NAT su Sophos Firewall.

Policy, endpoint e pagine di blocco

Filtering Policy e liste di domini

Una Filtering Policy viene assegnata a una o più Locations in DNS Protection > Policies > Filtering policies. Per ogni Location può essere attiva una sola Filtering Policy. Oltre alle categorie, è possibile definire liste di domini e opzioni come Safe Search.

Per il percorso Traditional DNS, questo articolo verifica l’associazione alla Location corretta; per il percorso integrato di SFOS 23, verifica l’assegnazione dell’oggetto Firewall alla Filtering Policy prevista. L’associazione della Location e lo screenshot in questa sezione mostrano il percorso precedente. Creazione, eccezioni, Safe Search, pilot e rollback della policy sono descritti in Configurare le Filtering Policies di Sophos DNS Protection.

Le liste di domini dovrebbero avere uno scopo, un Owner e una data di revisione. Una Allow list prevale sulle normali decisioni di categoria, ma non su una classificazione SophosLabs come Threat o Security Risk. Inoltre, un dominio consentito può rimanere bloccato se la sua destinazione CNAME appartiene a una categoria bloccata.

Per le categorie sono particolarmente importanti queste decisioni:

• Infrastructure: normalmente consentire Content delivery, CRL e OCSP, perché aggiornamenti e controlli dei certificati possono dipenderne.
• Threats and liabilities: in genere bloccare categorie come Phishing, Malware, Newly Registered Websites o Anonymizers e gestire in modo mirato i False Positives.
• Data loss: valutare cloud storage e webmail in base ai requisiti DLP e di conformità.
• Uncategorized: non bloccare indiscriminatamente; servizi nuovi, legittimi o interni possono essere temporaneamente senza categoria.
• Produttività, Social Media e larghezza di banda: decidere in base alla rete e alle esigenze aziendali, non trattare queste categorie come una regola di sicurezza generale.

Endpoint DNS Protection

La Endpoint DNS Protection Policy è destinata agli endpoint Windows gestiti che devono essere protetti anche fuori dalla rete aziendale. Sophos Endpoint intercetta le richieste DNS e le invia tramite HTTPS alla Secure-DNS-Location. La Filtering Policy associata determina il filtraggio effettivo.

La guida Endpoint DNS Protection gestisce configurazione, Domain Exclusions interne e assegnazione. NAT, Request Routes e DHCP del firewall non sostituiscono questo percorso endpoint.

Attualmente la policy non supporta né Windows Server né macOS. Per macOS esiste un percorso separato con profilo Secure DNS manuale; Linux, dispositivi mobili e dispositivi speciali richiedono anch’essi una soluzione propria tramite rete, VPN o MDM. Prima del rollout, verificare in Sophos Fusion i requisiti attuali del pacchetto Endpoint, perché possono cambiare rapidamente.

Le zone interne vengono gestite esplicitamente come Domain Exclusions nella Endpoint Policy. Questa soluzione è più affidabile di un retry dopo NXDOMAIN ed evita richieste esterne non necessarie. Il DNS Protection Root Certificate può essere distribuito automaticamente sugli endpoint supportati.

Root Certificate e pagina di blocco

Per le pagine di blocco HTTPS, il DNS Protection Root Certificate deve essere considerato attendibile dai client. Non è lo stesso certificato della CA del firewall per TLS Inspection; la sua distribuzione è descritta nell’articolo Distribuire il certificato CA di Sophos Firewall per TLS Inspection.

Per verificare, distribuire, ruotare e rimuovere il certificato, consultare Distribuire il certificato root di Sophos DNS Protection.

Il certificato e il test di configurazione sono disponibili in DNS Protection > Installers. Deve inoltre essere raggiungibile blockpage.dnsprotection.sophos.com.

In Web Proxy Mode, Pharming Protection può interferire con la pagina di blocco. Prima di disattivare globalmente le funzioni di protezione, consentire il dominio della pagina di blocco tramite una regola firewall HTTP/HTTPS specifica senza Web Filter e impostarlo su Do not decrypt in una regola TLS.

Pilot, rollout e accettazione

L’assegnazione della Location e i campi Location nei report della seguente checklist riguardano Traditional DNS oppure i dati endpoint. Per il percorso integrato di SFOS 23, utilizzare invece l’assegnazione del firewall e i controlli del pilot SFOS 23 riportati sopra; non dedurre che i nomi dei campi nei report o in Live Discover siano rimasti invariati.

Attivare DNS Protection prima in una piccola rete pilota. Documentare zone interne, reverse lookup e servizi critici, configurare le DNS Request Routes e preparare un rollback chiaro ai resolver precedenti. Le reti server richiedono una finestra di test separata, perché licenze, aggiornamenti, CRL/OCSP, backup o comunicazione del cluster possono dipendere dal DNS.

Prima del rollout generale devono riuscire questi controlli. I comandi client non sono stati eseguiti qui in un ambiente SFOS 22; sono comandi diagnostici in sola lettura. Il test di configurazione e i report Fusion costituiscono la prova del prodotto:

• un dominio pubblico viene risolto tramite il resolver previsto.
• il dominio AD interno e il reverse lookup funzionano tramite DNS Request Routes.
• il test di configurazione in Installers mostra la conferma prevista.
• un dominio innocuo, bloccato deliberatamente da una policy di test, viene bloccato e assegnato alla Location corretta.
• in DNS Protection > Logs & Reports, DNS usage by source mostra la Location dopo il ritardo previsto e, per i dati endpoint, anche utente e dispositivo.
• la rete guest utilizza il percorso DNS previsto, ma non server DNS interni.
• il client VPN riceve resolver e suffissi DNS appropriati.
• Browser DoH, Private Relay o profili locali non aggirano inaspettatamente il controllo.
• il rollback al resolver precedente è stato testato o è chiaramente documentato.

Comandi di test per i client

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 con systemd-resolved e dig installato:

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

Sostituire <firewall-ip> con l’indirizzo dell’interfaccia interna di Sophos Firewall. Se la richiesta esplicita al firewall funziona ma quella normale no, la causa si trova generalmente in DHCP, VPN, Browser DoH o in una configurazione DNS locale. I comandi mostrano il resolver utilizzato dal client e la relativa risposta, ma da soli non provano quale upstream utilizzi il firewall.

Verificare una zona interna:

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

Questa richiesta deve raggiungere il server DNS interno tramite la DNS Request Route appropriata.

Troubleshooting

Le verifiche di Location, IP sorgente e upstream UDP/TCP 53 in questa sezione riguardano Traditional DNS. Per il percorso integrato di SFOS 23, controllare prima DNS Protection, l’assegnazione del firewall alla policy e il protocollo utilizzato tramite Test name resolution. Seguire i controlli del pilot SFOS 23 riportati sopra; non aggiungere anche i vecchi forwarder IPv4.

La Location non appare in Sophos Fusion

Verificare l’IP WAN pubblico, il FQDN DDNS e l’uscita Multi-WAN effettiva. Un IP sorgente non configurato può essere rifiutato dal servizio DNS Protection. Per gli indirizzi dinamici, controllare che il FQDN punti esternamente all’IP corrente; i record Cloudflare devono essere impostati su DNS only.

In My Environment > Alerts vengono segnalati FQDN non validi e conflitti IP. Con CGNAT o uscite proxy/VPN condivise prevale la Location registrata per prima. Un altro FQDN sullo stesso IP non modifica l’assegnazione.

Il traffico DNS manca nonostante la Location corretta

Questo sintomo comprende anche No queries received from locations nella dashboard e DNS Protection: Connectivity Error nel Control center. Aprire prima https://dns.access.sophos.com. Se il messaggio di benvenuto non compare, testare tramite UDP e TCP 53 entrambi gli indirizzi del tenant mostrati in Installers e verificare l’uscita WAN effettiva.

Se le query raggiungono un’altra destinazione o risponde un altro resolver, il router o l’ISP potrebbe reindirizzare il DNS. Un test Standard o Extended su https://www.dnsleaktest.com/ aiuta a circoscrivere il problema: con DNS Protection, i valori nella colonna Hostname contengono il formato gw-<Nummer><Region>.dnsprotection.sophos.com; come ISP compare Amazon o una denominazione equivalente. Se il test mostra esclusivamente altri resolver, chiedere al provider di verificare un reindirizzamento DNS. Se compaiono sia resolver Sophos sia resolver esterni, controllare le impostazioni DNS di firewall, server DNS interno e client, oltre a eventuali resolver IPv6 paralleli. https://ipleak.net/ può essere usato come verifica incrociata.

Mantenere solo i due indirizzi del tenant come forwarder, controllare routing, NAT e Packet Capture e far risolvere al provider l’eventuale reindirizzamento. Un terzo resolver pubblico sarebbe soltanto un bypass non protetto.

Alcuni client usano un resolver diverso

Controllare insieme DHCPv4, DHCPv6, Router Advertisements, profilo VPN e valori statici dei client. Un server DNS IPv6 aggiuntivo può aggirare DNS Protection. DNS Protection funziona tramite IPv4 ma risolve record AAAA; le destinazioni IPv6 non richiedono quindi un resolver IPv6 separato.

I nomi interni non funzionano più

Verificare DNS Request Routes, server DNS interni, zone reverse, domini di ricerca e suffissi dei client. Assicurarsi inoltre che il client utilizzi il firewall o il resolver interno previsto e non direttamente un IP di DNS Protection.

Un dominio interno o legittimo viene bloccato

Verificare categorizzazione, lista di domini e destinazione CNAME. Un’eccezione limitata è preferibile all’apertura di un’intera categoria. Le classificazioni SophosLabs Threat e Security Risk non possono essere sovrascritte con una Allow domain list.

I log rimangono vuoti

Dashboard e report presentano un ritardo di circa 15-25 minuti. Un nome di Location o policy aggiornato può richiedere da 30 minuti a quattro ore. Solo successivamente verificare DHCP, DNS del client, DNS del firewall, reindirizzamento NAT, resolver alternativi, profili VPN e assegnazione della Location.

In DNS Protection > Logs & Reports, iniziare da DNS usage by source e filtrare per Location, Domain, Status o Source IP. Per il DNS inoltrato direttamente, una regola con Log firewall traffic può mostrare se UDP/TCP 53 ha attraversato il firewall. Per il resolver del firewall fa fede Administration > Device access; una regola firewall non prova l’autorizzazione o il rifiuto del servizio locale.

Operatori di filtro, limiti di esportazione, ritardi e Live Discover sono documentati in Analizzare i report DNS Protection e Live Discover. Per il troubleshooting del firewall, dimostrare prima il percorso del resolver e solo dopo avviare query più approfondite.

Con EDR, XDR o MDR, Threat Analysis Center > Live Discover può inoltre analizzare dati di DNS Protection come dominio, Policy Action, Location e Source IP. I campi relativi a utenti e dispositivi sono disponibili nei report standard per i dati endpoint, non nello schema firewall DNS documentato di Live Discover.

La pagina di blocco non appare

Verificare DNS Protection Root Certificate, percorso DNS e raggiungibilità di blockpage.dnsprotection.sophos.com. In Web Proxy Mode controllare inoltre Pharming Protection, la regola HTTP/HTTPS e l’eccezione TLS Do not decrypt. Anche VPN, Browser DoH e Apple Private Relay possono aggirare DNS Protection durante il test.

Per l’eccezione firewall mirata, creare un oggetto FQDN per blockpage.dnsprotection.sophos.com. Una regola Allow consente HTTP/HTTPS dalle zone e reti interne interessate alla zona WAN, usando questo oggetto come destinazione e senza Web Filter. Una regola TLS corrispondente usa gli stessi criteri con Do not decrypt. Non disattivare globalmente Pharming Protection o TLS Inspection.

DoH o Private DNS aggira il controllo

Un reindirizzamento NAT per la porta 53 non intercetta DoH o DoT. Le policy di browser, sistema operativo e MDM devono controllare questi resolver. Secure DNS in DNS Protection utilizza DoH; non è documentata una modalità DNS Protection specifica tramite DoT.

Sui dispositivi Apple, anche iCloud Private Relay può aggirare il percorso DNS previsto. Se, ad esempio, gli iPhone non hanno accesso a Internet mentre altri dispositivi nella stessa sede funzionano, disattivare innanzitutto Limit IP Address Tracking per il percorso di test interessato e riprovare. Una modifica a livello di organizzazione deve essere effettuata solo dopo questo test limitato e dopo aver concordato i requisiti di privacy.

I client VPN si comportano diversamente dai client LAN

Verificare server DNS assegnati, suffissi DNS, Split DNS, Full o Split Tunnel e resolver locali. DNS Protection può funzionare in ufficio ed essere comunque aggirato durante l’accesso remoto. La scelta VPN di base è illustrata in Sophos Connect o SSL VPN: quale soluzione di accesso remoto è adatta?.

Gestione operativa

DNS Protection non è una semplice sostituzione una tantum del server DNS. Controllare regolarmente:

• Locations, indirizzi di uscita pubblici e risoluzione DDNS.
• impostazioni DHCP e DNS Request Routes interne.
• policy, liste di domini, Owner e date di revisione.
• principali domini bloccati e False Positives documentati.
• nuove sedi, reti guest, percorsi VPN e piattaforme endpoint.
• distribuzione dei certificati e raggiungibilità del dominio della pagina di blocco.
• report dopo le modifiche e percorso di rollback definito.

Chi non intende gestire stabilmente questi aspetti ottiene spesso risultati migliori con resolver robusti e controlli di protezione mirati. DNS Protection è utile dove policy, reporting e protezione endpoint vengono realmente utilizzati e monitorati.

Rollback sicuro

Il rollback della sede descritto di seguito riguarda il precedente percorso Traditional DNS. Per una migrazione SFOS 23, utilizzare il rollback riportato sopra con l’assegnazione della policy e l’opzione DNS Protection.

Per il percorso della sede, disattivare prima il reindirizzamento DNS, così i client non vengono ancora forzati verso il firewall. Ripristinare quindi i resolver precedenti in Network > DHCP, rinnovare il lease del client di test e verificare nomi pubblici e interni. Solo dopo ripristinare il modo o i server precedenti in Network > DNS. Lasciare inizialmente le Request Routes: non ostacolano il rollback e facilitano una ripresa controllata. Eliminare la Location Fusion solo quando non ha più reti o policy necessarie assegnate.

Eseguire separatamente il rollback di Endpoint DNS Protection: in DNS Protection > Policies > Endpoint policies, rimuovere l’assegnazione o disattivare Use Sophos DNS Protection, quindi verificare sul dispositivo pilota che tornino attivi i resolver configurati dal sistema o dalle applicazioni. Il Root Certificate può essere rimosso in seguito tramite lo stesso canale gestito usato per installarlo.