Pianificare e configurare la rete per Sophos DNS Protection

Sophos DNS Protection può proteggere un resolver DNS centrale nella sede oppure collegare direttamente i dispositivi compatibili tramite Secure DNS. La decisione più importante non riguarda quindi il produttore del firewall, ma dove avviene la risoluzione DNS, come vengono mantenute le zone interne e in che modo Sophos identifica la sede.

Percorso rapido: in una rete di sede gestita, il resolver locale esistente rimane normalmente il server DNS dei client. Inoltra solo le richieste pubbliche ai due indirizzi IP di DNS Protection visualizzati in Sophos Fusion (in precedenza Sophos Central). Le zone interne continuano a essere inviate ai server DNS interni autorevoli. Secure DNS è adatto ai singoli dispositivi gestiti e agli utenti mobili. Provare prima entrambi i percorsi con un piccolo gruppo pilota e non configurare mai un resolver pubblico non protetto come terzo fallback.

Architettura di destinazione e ambito delle responsabilità

Il percorso di rete è composto da quattro ruoli distinti:

Il client invia la richiesta al resolver assegnato tramite DHCP, VPN, MDM o configurazione locale.
Un resolver locale sceglie tra zone interne e nomi pubblici.
Firewall, router e NAT determinano l’IP sorgente pubblico e l’uscita effettiva.
DNS Protection associa la richiesta a una Location, applica la relativa policy e restituisce la risposta.

Con Secure DNS, il dispositivo invia invece la richiesta a DNS Protection tramite DNS over HTTPS (DoH). Questo percorso esclude il forwarder DNS locale. Il reindirizzamento della porta 53, la cache locale e il Conditional Forwarding non si applicano in questo caso.

Questo articolo descrive l’architettura indipendente dal produttore e i requisiti per firewall di terze parti. La configurazione specifica del dispositivo è descritta in Configurare Sophos DNS Protection con Sophos Firewall.

Prerequisiti, licenza e ruoli

Prima di modificare la rete devono essere disponibili la Location prevista e un accesso autorizzato a Sophos Fusion. Verificare in anticipo i diritti di licenza: DNS Protection standalone è incluso con Xstream Protection, mentre Endpoint DNS Protection richiede Workspace Protection e Secure DNS. Questi due modelli di implementazione utilizzano percorsi dati diversi e non devono essere considerati intercambiabili.

La Location deve essere creata prima di distribuire i dispositivi. Successivamente, la persona responsabile della rispettiva piattaforma distribuisce i valori del tenant seguendo le istruzioni appropriate per il dispositivo e configura Windows, macOS o Windows Server in base alla destinazione. I dispositivi Windows gestiti vengono affidati alla persona responsabile della policy Endpoint DNS Protection, anziché mantenere profili manuali. L’installazione, il rinnovo e la rimozione dell’attendibilità rientrano nel processo separato per il DNS Protection Root Certificate, non in questa procedura di configurazione.

Scegliere Traditional DNS o Secure DNS

Local resolver o Firewall forwarder

Scegliere questo percorso se una sede utilizza già un router, un firewall, Windows DNS o un altro Local resolver. Il resolver locale o Firewall forwarder invia le richieste pubbliche a Sophos tramite Traditional DNS over IPv4. DNS Protection riconosce la Location dall’indirizzo sorgente IPv4 pubblico o dal FQDN registrato nella Location.

I vantaggi sono cache centralizzate, un percorso uniforme per molti tipi di dispositivi e Conditional Forwarding per le zone interne. Il limite: dietro lo stesso IP sorgente pubblico, DNS Protection vede la sede, ma non automaticamente ogni utente o dispositivo. Un indirizzo di uscita variabile, condiviso o errato può impedire l’associazione.

Manual device DNS o Secure DNS

Manual device DNS configura i due indirizzi IP di DNS Protection direttamente sul dispositivo. Secure DNS, invece, utilizza DoH su HTTPS ed è adatto ai dispositivi gestiti, ai client mobili e alle reti in cui non è possibile modificare il resolver locale. Protegge il percorso del dispositivo anche fuori dall’ufficio. Tuttavia, nomi interni, split DNS della VPN e applicazioni con un resolver proprio devono essere gestiti esplicitamente. La configurazione manuale di un dispositivo non equivale all’implementazione gestita di Workspace tramite una Endpoint Policy.

Per questo percorso, aprire o creare la Location prevista, attivare Secure DNS e selezionare Save. Sophos Fusion genera quindi la DNS over HTTPS URL specifica della sede. Consegnare l’URL completa o il profilo generato alla persona responsabile di Windows, macOS o MDM. Per Sophos Endpoint, comunicare la Location e il gruppo pilota alla persona responsabile della Endpoint Policy, affinché selezioni questa Location nella policy. Non comporre autonomamente l’URL né riutilizzarne una di un’altra Location.

Scelta consigliata

Sede con Active Directory o zone interne: resolver locale con Conditional Forwarding; inviare a DNS Protection solo le richieste pubbliche.
Rete semplice senza zone interne: DHCP può distribuire direttamente i due indirizzi DNS Protection, purché la Location conosca l’IP di uscita pubblico.
Dispositivi mobili gestiti: Secure DNS, integrato con eccezioni interne definite e test VPN.
Ambiente misto: utilizzare in parallelo il percorso della sede e Secure DNS, documentando però quale sia il percorso determinante per ogni classe di dispositivi. Una doppia intercettazione complica la risoluzione dei problemi.

Inventario e regole di rete

Prima della modifica, registrare i seguenti valori:

i due indirizzi IP di DNS Protection disponibili in My Products > DNS Protection > Installers nel proprio tenant;
tutti gli indirizzi IPv4 pubblici di uscita effettivamente utilizzati dal normale funzionamento, dal failover WAN, da SD-WAN, VPN o proxy centrali;
le zone forward e reverse interne, i relativi resolver autorevoli e i suffissi di ricerca;
i valori DNS configurati tramite DHCP, VPN o in modo statico per ciascuna rete;
i dispositivi o le applicazioni con un proprio DoH, DoT, VPN o resolver configurato manualmente;
il resolver precedente, il TTL delle opzioni DHCP, le persone responsabili, la finestra di manutenzione e il percorso di ritorno.

In Installers, fare clic su Copy accanto a IP addresses e utilizzare sempre entrambi gli indirizzi visualizzati. Il download Certificate appartiene al processo separato per i certificati; per visualizzare le Block Page HTTPS, questo DNS Protection Root Certificate deve essere considerato attendibile sui dispositivi. Non deve essere confuso con una CA utilizzata dal firewall per l’ispezione HTTPS.

Per Traditional DNS, entrambi gli indirizzi del tenant devono essere raggiungibili tramite UDP 53 e TCP 53: in modalità forwarder, dai resolver locali autorizzati; in modalità client diretto, solo dalle subnet client o pilota autorizzate. UDP è il caso normale; TCP è necessario, tra l’altro, per risposte più grandi o troncate. DNS Protection è un resolver basato su IPv4, ma può risolvere record AAAA e quindi destinazioni IPv6. Nessun resolver IPv6 separato e non protetto deve poter aggirare il percorso previsto.

Per Secure DNS, i dispositivi devono poter raggiungere in uscita tramite TCP 443 le destinazioni DoH fornite da Sophos. Anche le Block Page HTTPS richiedono TCP 443 e la raggiungibilità di blockpage.dnsprotection.sophos.com. L’ispezione TLS non deve interrompere la connessione senza che ciò venga rilevato; la relativa eccezione deve essere limitata rigorosamente al percorso di destinazione Sophos documentato.

Limitare la regola per la porta 53 agli indirizzi visualizzati nel tenant come destinazioni e separare le sorgenti in base al progetto: in modalità forwarder, i resolver locali previsti; in modalità client diretto, le subnet client o pilota autorizzate. Non è necessaria alcuna regola WAN in ingresso. Un proxy DNS a monte, un reindirizzamento DNS del provider o un captive portal trasparente possono modificare le risposte e devono essere individuati durante il pilot.

Pianificare Location, uscita e ridondanza

Traditional DNS funziona solo quando l’IP sorgente pubblico visibile della richiesta corrisponde a una Location in Sophos Fusion. Gli indirizzi privati RFC 1918 non devono essere utilizzati per questa associazione. In caso di uscita dinamica è possibile utilizzare un FQDN DDNS stabile, che deve risolversi pubblicamente nell’indirizzo corrente. Con CGNAT o un IP condiviso con altri clienti non è garantita un’associazione univoca; la soluzione corretta è un IP pubblico dedicato.

In presenza di più WAN, censire ogni possibile indirizzo di uscita e registrarlo nella Location appropriata. Quindi commutare in modo controllato e provare entrambi i percorsi. Il policy routing non deve inviare il traffico DNS attraverso un’uscita sconosciuta. Se gli IP pubblici si sovrappongono tra tenant, secondo Sophos ha la precedenza l’associazione creata per prima.

Sophos fornisce due indirizzi resolver. Configurarli entrambi come coppia equivalente primario/secondario. Un terzo resolver pubblico non offre ridondanza, ma costituisce un bypass: i resolver non scelgono sempre i server alternativi solo in caso di guasto completo e possono utilizzare in parallelo quello più veloce. Una vera resilienza comprende inoltre due resolver locali, una distribuzione DHCP/VPN ridondante e un percorso di failover WAN collaudato.

Procedura di configurazione indipendente dal produttore

In Sophos Fusion, in My Products > DNS Protection > Network setup, individuare il ramo appropriato per Local resolver, Firewall forwarder, Windows DNS, Manual device DNS o Secure DNS. Quindi confermare la Location e il metodo di connessione previsti. Per Traditional DNS devono essere noti tutti gli indirizzi di uscita pubblici di produzione.
Per Traditional DNS, copiare entrambi gli indirizzi resolver dal proprio tenant in My Products > DNS Protection > Installers. Non utilizzare valori di esempio o indirizzi di un altro tenant.
Per Secure DNS, creare o modificare la Location, attivare Secure DNS, selezionare Save e copiare la DNS over HTTPS URL generata specificamente per la sede. Consegnare esattamente questa URL o il profilo generato alla persona responsabile di Windows, macOS o MDM. La persona responsabile della Sophos Endpoint Policy riceve la Location e il gruppo pilota, in modo da poter selezionare questa Location nella Endpoint Policy.
In modalità forwarder, configurare entrambi gli indirizzi Sophos come unici forwarder per le richieste pubbliche sul resolver locale o sul firewall di terze parti: uno come Primary DNS server, l’altro come Secondary DNS server. Mantenere i conditional forwarder o le stub zone per le zone forward e reverse interne. Se il prodotto prevede un terzo server DNS, non aggiungervi un resolver pubblico esterno, perché il passaggio a quest’ultimo aggirerebbe la protezione.
Separare la regola del firewall di uscita in base al progetto: in modalità forwarder, consentire UDP/TCP 53 solo dai resolver locali autorizzati verso entrambi gli indirizzi Sophos; in modalità client diretto, consentirlo solo dalle subnet client o pilota autorizzate verso entrambi gli indirizzi. Bloccare la porta 53 per tutte le altre sorgenti, in conformità con il progetto di prevenzione dei bypass documentato.
Per Secure DNS, consentire TCP 443 solo dai dispositivi autorizzati verso la destinazione DoH generata e la destinazione necessaria per le Block Page. Limitare rigorosamente le eccezioni all’ispezione TLS.
In modalità forwarder, impostare gli scope DHCP e VPN del pilot sul resolver locale. In modalità client diretto, distribuire entrambi gli indirizzi Sophos alla subnet pilota autorizzata. Censire separatamente i dispositivi statici.
Fare distribuire l’URL o il profilo Secure DNS generato esclusivamente al gruppo pilota dalla persona responsabile di Windows, macOS o MDM. Per Sophos Endpoint, la persona responsabile della policy seleziona la Location comunicata nella Endpoint Policy e assegna tale policy al gruppo pilota indicato. Documentare Location, policy, gruppo e metodo di rimozione.
Aggiornare la cache e i lease esistenti in modo controllato e solo nel pilot. Lo svuotamento globale della cache genera carico non necessario e rende più difficile il confronto.
Limitare i percorsi DNS alternativi solo dopo una convalida riuscita.

Limiti della protezione dai bypass

Il DNS classico può essere limitato consentendo UDP/TCP 53 in uscita, in modalità forwarder, solo ai resolver locali autorizzati oppure, in modalità client diretto, solo alle subnet client o pilota autorizzate. Il reindirizzamento di destinazioni esterne sulla porta 53 al proprio resolver può essere utile per dispositivi difficili da gestire, ma deve escludere i server DNS interni, le VPN, le reti guest e i dispositivi che richiedono resolver specifici. Se i client sono gestibili, il blocco è più trasparente del reindirizzamento.

Questo controllo non intercetta DoH su TCP 443, DoT su TCP 853 né la risoluzione dei nomi all’interno di un tunnel VPN di terze parti. Non bloccare indiscriminatamente TCP 443. Le policy di browser, sistema operativo, MDM ed endpoint devono controllare il Secure DNS non autorizzato; l’uso noto di DoT può essere gestito in modo mirato. Apple Private Relay e servizi analoghi per la privacy richiedono anch’essi una decisione progettuale separata.

Se solo i dispositivi iPhone non riescono ad accedere a Internet, mentre la risoluzione funziona su altri dispositivi, disattivare temporaneamente Limit IP Address Tracking per la rete interessata ed eseguire nuovamente la verifica. Apportare questa modifica consapevolmente sui dispositivi pilota, poiché incide su una funzionalità di privacy del dispositivo.

La protezione dai bypass termina al confine amministrativo. In una rete BYOD o guest, una policy documentata e meno restrittiva è spesso più solida del tentativo di imporre ogni resolver cifrato senza gestire i dispositivi.

Pilot, convalida e accettazione

Iniziare con una VLAN rappresentativa o con pochi dispositivi. Verificare almeno nomi pubblici, FQDN interni, reverse lookup, VPN, accesso guest, failover WAN e un blocco di prova innocuo.

Prima della modifica, definire una finestra di osservazione e criteri di rollback chiari. Eseguire il rollback del pilot se la risoluzione interna o tramite VPN non funziona, compare la Location o la policy errata, la connessione DoH/TLS rimane instabile oppure viene compromessa una destinazione aziendale necessaria; non ampliare il pilot finché un problema resta irrisolto.

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

Con dig installato:

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

Sostituire <resolver-ip> con il resolver locale oppure, per l’uso diretto, con un indirizzo del tenant. corp.example è una zona di documentazione e deve essere sostituita con la propria zona interna. Il test TCP conferma che non funzioni soltanto UDP.

Aprire quindi nel browser l’URL di test copiata da Installers > Check your configuration. Il messaggio di benvenuto conferma il percorso DNS Protection, ma da solo non la policy corretta. Bloccare inoltre in modo mirato un dominio di test innocuo e verificare in Sophos Fusion che richiesta, Location e policy vengano visualizzate come previsto. I report non sono necessariamente in tempo reale; pertanto, non dedurre un errore immediatamente dopo una singola richiesta.

L’accettazione richiede che:

entrambi i resolver Sophos funzionino singolarmente tramite UDP e TCP;
le zone forward e reverse interne rimangano interne;
l’uscita prevista venga associata alla Location corretta;
il blocco e le destinazioni aziendali consentite funzionino;
failover WAN, VPN e client con supporto IPv6 non creino un percorso alternativo;
il DNS non autorizzato sulla porta 53 sia bloccato o reindirizzato secondo il progetto;
i pilot Secure DNS manuali per Windows, macOS e MDM utilizzino esattamente l’URL o il profilo generato, mentre ai pilot Sophos Endpoint sia assegnata una policy con la Location prevista; entrambi devono comparire sotto la Location e la policy previste e superare i test in ufficio, in mobilità, tramite VPN, per i domini interni e durante la rimozione;
il monitoraggio e un percorso di ritorno collaudato siano documentati.

Gestione e controlli periodici

Dopo il pilot, procedere per fasi, in base alla sede o alla VLAN. Per ogni fase, monitorare errori DNS, segnalazioni all’helpdesk, domini aziendali bloccati e associazione dell’uscita. Migrare per ultimi i server statici e i dispositivi OT/IoT, in una finestra di manutenzione separata.

Dopo modifiche a WAN, NAT, DHCP, VPN, IPv6 o resolver locali, verificare nuovamente il percorso DNS. Lo stesso vale in caso di cambio del provider o di un nuovo indirizzo di uscita pubblico. Controllare periodicamente che entrambi i resolver del tenant siano ancora configurati, che le zone interne vengano risolte localmente e che nessun server DNS aggiuntivo aggiri la protezione. Integrare nel processo operativo le notifiche del prodotto in My Environment > Alerts e lo stato in My Products > DNS Protection.

Rollback o dismissione in sicurezza

Per il rollback, disattivare innanzitutto le nuove regole di blocco o reindirizzamento DNS. Quindi seguire il ramo appropriato per il metodo di implementazione:

Modalità forwarder: ripristinare attivamente sul resolver locale i forwarder precedenti documentati. Verificare quindi la risoluzione interna e pubblica.
Modalità client diretto: ripristinare i precedenti valori DNS documentati in DHCP, VPN e client statici. Rinnovare i lease sui dispositivi di test e verificare quindi la risoluzione interna e pubblica.
Secure DNS: la persona responsabile di Windows, macOS o MDM rimuove il profilo pilota; la persona responsabile della Sophos Endpoint Policy rimuove invece l’assegnazione del gruppo pilota. Ripristinare quindi lo stato DNS precedente e verificare che il percorso DoH non venga più utilizzato.

Inizialmente, mantenere i conditional forwarder e la Location in Sophos Fusion, a meno che non sia stata la Location stessa a causare il problema.

Risoluzione dei problemi per sintomo

I nomi pubblici non si risolvono affatto

Provare esplicitamente entrambi gli indirizzi Sophos tramite UDP e TCP. Controllare quindi la regola di uscita, il NAT, la route e l’IP sorgente pubblico visibile. Se l’IP sorgente non è associato ad alcuna Location o entra in conflitto con un altro tenant, DNS Protection può rifiutare le richieste. Con DDNS, verificare inoltre la risoluzione pubblica del FQDN.

I nomi interni o Active Directory non funzionano

Verificare quale resolver utilizza effettivamente il client. Controllare quindi conditional forwarder, server di destinazione autorevoli, zone reverse, suffissi di ricerca e split DNS della VPN. Un resolver DNS Protection distribuito direttamente non conosce le zone private.

Non funzionano solo le risposte di grandi dimensioni o alcuni domini

Provare TCP 53. Se UDP funziona, ma dig +tcp no, in genere manca la regola TCP oppure un prodotto intermedio interrompe la connessione. Se un dominio consentito viene comunque bloccato, controllare anche la destinazione CNAME e la classificazione di sicurezza.

Sophos Fusion non mostra alcuna Location o mostra quella errata

Determinare l’uscita effettiva anziché considerare soltanto l’indirizzo WAN configurato. SD-WAN, gateway NAT centrali, proxy e failover possono modificare l’IP sorgente. Attendere quindi un tempo sufficiente per i report e verificare che il test abbia effettivamente utilizzato il resolver previsto, anziché il DoH del browser o una VPN.

Per una Location definita tramite FQDN, verificare inoltre la risoluzione pubblica. Per un record DNS Cloudflare deve essere impostato Proxy status: DNS only; un record con proxy attivo non restituisce l’indirizzo di uscita pubblico effettivo. Un indirizzo privato o IPv6 non è un indirizzo Location valido. Se lo stesso valore pubblico è già associato a un altro cliente o il FQDN non è valido, correggere l’associazione prima di proseguire con il rollout.

La Block Page non compare, ma il blocco DNS funziona

Ciò non dimostra che il dominio sia consentito. Verificare la raggiungibilità di blockpage.dnsprotection.sophos.com, l’attendibilità del DNS Protection Root Certificate, Pharming Protection, il proxy web o filtro web e l’ispezione TLS. Se il firewall decrittografa il percorso delle Block Page, utilizzare l’azione rigorosamente limitata Do not decrypt per il percorso di destinazione Sophos documentato. Gestire sempre l’installazione e la rimozione dei certificati tramite il processo della piattaforma responsabile.

Un dominio consentito rimane bloccato

Controllare innanzitutto il nome di destinazione CNAME e la relativa categoria: un dominio di origine consentito può comunque puntare a un nome bloccato a causa della categoria o del Threat Score. Dopo una modifica della policy, attendere inoltre la scadenza del TTL DNS e delle cache locali oppure aggiornarli in modo controllato. Non accelerare il rollout introducendo eccezioni generiche e troppo ampie.

Il blocco dei bypass non funziona

Cercare nei log il traffico in uscita UDP/TCP 53, TCP 853 e le connessioni Secure DNS note. Controllare quindi browser, sistema operativo, VPN e software di sicurezza locale. Un filtro sulla porta 53 non può rilevare o impedire il DNS cifrato sulla porta 443.

Il DNS risolve i nomi, ma mancano policy e report

Verificare innanzitutto con ipconfig, nslookup oppure, su Linux e macOS, con dig quali resolver utilizza effettivamente il dispositivo. Eseguire quindi un test Standard o Extended su https://www.dnsleaktest.com/. Quando si utilizza DNS Protection, tutti i valori nella colonna Hostname contengono il modello gw-<numero>.<regione>.dnsprotection.sophos.com; come ISP compare Amazon o una denominazione equivalente. Altri resolver indicano un leak DNS o un reindirizzamento da parte dell’ISP.

Se https://dns.access.sophos.com mostra un errore del browser anziché la pagina di benvenuto, mentre contemporaneamente nel dashboard compare No queries received from locations oppure un Sophos Firewall segnala DNS Protection: Connectivity Error, correggere innanzitutto il percorso resolver errato. Controllare a tale scopo il DNS del router, DHCP e DHCPv6, le configurazioni DNS statiche, il reindirizzamento del provider e i resolver IPv6 paralleli. Solo dopo esaminare policy o report; questa procedura di controllo si applica al percorso di rete e non, senza ulteriori verifiche, a Endpoint DoH.

Guide correlate esistenti

Configurare Sophos DNS Protection con Sophos Firewall mostra l’integrazione specifica in SFOS.
Policy Endpoint DNS Protection descrive il percorso Workspace gestito separato per gli endpoint.