Pianificare e configurare la rete per Sophos DNS Protection

Sophos DNS Protection può proteggere un resolver DNS centrale della sede oppure collegare direttamente i dispositivi compatibili tramite Secure DNS. La decisione principale non riguarda quindi il produttore del firewall, ma dove avviene la risoluzione DNS, come restano disponibili le zone interne e come Sophos identifica la Location.

Percorso rapido: in una rete aziendale gestita, i client dovrebbero normalmente continuare a usare il resolver locale. Questo inoltra solo le richieste pubbliche ai due indirizzi IP DNS Protection mostrati in Sophos Central, mentre le zone interne continuano a usare i server DNS autorevoli interni. Secure DNS è adatto a dispositivi gestiti e utenti mobili. Eseguire prima un pilot su un piccolo gruppo e non aggiungere mai un resolver pubblico non protetto come terzo fallback.

Architettura di destinazione e ambito

Il percorso di rete ha quattro ruoli distinti:

Il client invia la richiesta al resolver assegnato tramite DHCP, VPN, MDM o configurazione locale.
Il 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: reindirizzamento della porta 53, cache locale e conditional forwarding non si applicano.

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

Il responsabile della piattaforma distribuisce i valori del tenant seguendo la guida appropriata: prima creare e gestire la Location, quindi usare le istruzioni per Windows manuale, macOS o Windows Server. Per Windows gestito, passare la responsabilità al referente della policy Endpoint DNS Protection invece di mantenere profili manuali.

Verificare il diritto d’uso nella guida alle licenze Sophos Central: DNS Protection standalone si applica con Xstream Protection, mentre Endpoint DNS Protection richiede Workspace Protection e Secure DNS. Le autorizzazioni dei ruoli Sophos Central regolano l’accesso e si assegnano tramite il processo RBAC. Installazione, rinnovo e rimozione della fiducia appartengono alla guida DNS Protection Root Certificate, non a questo runbook di rete.

Scegliere Traditional DNS o Secure DNS

Traditional DNS over IPv4

Scegliere questo percorso se la sede usa già un router, un firewall, Windows DNS o un altro resolver locale. DNS Protection riconosce la Location dall’indirizzo sorgente IPv4 pubblico o dal FQDN registrato per la Location.

I vantaggi sono cache centrale, un solo percorso per molti tipi di dispositivo e conditional forwarding per le zone interne. Il limite è l’identità: dietro un singolo IP pubblico DNS Protection vede la sede, ma non automaticamente ogni utente o dispositivo. Un’uscita variabile, condivisa o errata può impedire l’associazione.

Secure DNS

Secure DNS usa DoH su HTTPS ed è indicato per dispositivi gestiti, client mobili e reti in cui il resolver locale non può essere modificato. Protegge il dispositivo anche fuori sede. Nomi interni, split DNS della VPN e applicazioni con un resolver proprio devono però essere gestiti esplicitamente.

Per predisporre questo percorso, aprire o creare la Location, attivare Secure DNS e selezionare Save. Central genera quindi la DNS over HTTPS URL specifica della Location. Consegnare l’URL completa o il profilo generato al responsabile Windows, macOS o MDM. Per Sophos Endpoint, consegnare Location e gruppo pilota al responsabile della policy Endpoint, affinché selezioni quella Location nella policy. Non costruire l’URL né riutilizzare quella di un’altra Location.

Scelta pratica

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 con esclusioni interne definite e test VPN.
Ambiente misto: usare in parallelo il percorso di sede e Secure DNS, documentando quello autorevole per ogni classe di dispositivi. Una doppia intercettazione complica la diagnosi.

Prerequisiti e accesso di rete

Prima della modifica registrare:

i due indirizzi IP in My Products > DNS Protection > Installers nel proprio tenant;
tutti gli IPv4 pubblici realmente usati da esercizio normale, failover WAN, SD-WAN, VPN o proxy centrali;
zone forward e reverse interne, resolver autorevoli e suffissi di ricerca;
valori DNS distribuiti da DHCP/VPN o configurati staticamente in ogni rete;
dispositivi e applicazioni con DoH, DoT, VPN o resolver fisso propri;
resolver precedente, durata delle opzioni DHCP, responsabile, finestra di manutenzione e percorso di ritorno.

Per Traditional DNS, entrambi gli indirizzi del tenant devono essere raggiungibili su UDP 53 e TCP 53: dai resolver locali autorizzati in modalità con forwarder oppure soltanto dalle subnet client o pilota approvate in modalità client diretto. UDP è il percorso normale; TCP è necessario, tra l’altro, per risposte grandi o troncate. DNS Protection è basato su IPv4, ma restituisce record AAAA e risolve quindi destinazioni IPv6. Un resolver IPv6 separato non protetto non deve aggirare il progetto.

Per Secure DNS, i dispositivi richiedono TCP 443 in uscita verso le destinazioni DoH fornite da Sophos. Anche le Block Page HTTPS richiedono TCP 443 e l’accesso a blockpage.dnsprotection.sophos.com. L’ispezione TLS non deve interrompere la connessione senza evidenza; limitare qualsiasi eccezione allo specifico percorso Sophos documentato.

Limitare la regola della porta 53 agli indirizzi del tenant come destinazioni e distinguere le sorgenti secondo il progetto: i resolver locali previsti in modalità con forwarder oppure le subnet client o pilota approvate in modalità client diretto. Non serve una regola WAN in ingresso. Proxy DNS a monte, redirect DNS dell’ISP o captive portal trasparenti possono modificare le risposte e vanno rilevati nel pilot.

Pianificare Location, uscita e ridondanza

Traditional DNS funziona solo quando l’IP sorgente pubblico visibile coincide con una Location in Sophos Central. Gli indirizzi privati RFC 1918 non appartengono a questa associazione. Per un’uscita dinamica si può usare un FQDN DDNS stabile, che deve risolvere pubblicamente nell’indirizzo corrente. Con CGNAT o IP condiviso tra clienti l’associazione non è affidabile; un IP pubblico univoco è la soluzione corretta.

In un ambiente multi-WAN, censire ogni possibile uscita e aggiungerla alla Location corretta. Commutare poi intenzionalmente e provare entrambi i percorsi. Il policy routing non deve inviare il DNS da un’uscita sconosciuta. Se gli IP pubblici si sovrappongono tra tenant, Sophos dichiara che prevale la Location creata per prima.

Sophos fornisce due indirizzi resolver. Configurarli come coppia primario/secondario. Un terzo resolver pubblico non offre ridondanza ma un bypass: alcuni resolver interrogano server in parallelo o scelgono la risposta più veloce. La vera resilienza comprende anche due resolver locali, distribuzione DHCP/VPN ridondante e failover WAN collaudato.

Runbook di configurazione indipendente dal produttore

Confermare in Sophos Central la Location e il metodo di connessione. Per Traditional DNS devono essere note tutte le uscite pubbliche di produzione.
Per Traditional DNS, copiare entrambi gli indirizzi dal proprio tenant in My Products > DNS Protection > Installers. Non usare esempi o valori 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 per quella Location. Consegnare esattamente quell’URL o il profilo generato al responsabile Windows, macOS o MDM. Consegnare Location e gruppo pilota al responsabile della policy Sophos Endpoint, affinché selezioni quella Location nella policy Endpoint.
In modalità con forwarder, impostare entrambi gli indirizzi Sophos come unici forwarder delle richieste pubbliche sul resolver locale. Conservare conditional forwarder o stub zone per le zone interne forward e reverse.
Distinguere la regola del firewall di uscita in base al progetto: in modalità con forwarder, consentire UDP/TCP 53 solo dai resolver locali autorizzati verso entrambi gli indirizzi Sophos; in modalità client diretto, solo dalle subnet pilota o client approvate verso entrambi gli indirizzi. Bloccare la porta 53 per tutte le altre sorgenti secondo il progetto di bypass documentato.
Per Secure DNS, consentire TCP 443 solo dai dispositivi approvati verso la destinazione DoH generata e la destinazione Block Page richiesta. Limitare strettamente ogni eccezione all’ispezione TLS.
In modalità con forwarder, puntare gli scope DHCP e VPN pilota al resolver locale. In modalità client diretto, distribuire entrambi gli indirizzi Sophos alla subnet pilota approvata. Inventariare separatamente i dispositivi statici.
Far distribuire URL o profilo Secure DNS solo al gruppo pilota dal responsabile Windows, macOS o MDM. Per Sophos Endpoint, il responsabile seleziona la Location fornita nella policy Endpoint e assegna tale policy al gruppo pilota indicato. Documentare Location, policy, gruppo e metodo di rimozione.
Rinnovare cache e lease solo nel pilot e in modo controllato. Uno svuotamento globale genera carico e rende difficile il confronto.
Limitare percorsi DNS alternativi solo dopo la validazione.

Limiti della prevenzione dei bypass

Il DNS classico può essere limitato consentendo UDP/TCP 53 in uscita solo ai resolver locali autorizzati in modalità con forwarder, oppure alle subnet client o pilota approvate in modalità client diretto. Reindirizzare destinazioni sconosciute sulla porta 53 al resolver locale può aiutare con dispositivi difficili da gestire, ma deve escludere DNS interni, VPN, reti guest e dispositivi che richiedono uno specifico resolver. Se i client sono gestibili, il blocco è più trasparente del redirect.

Questo controllo non intercetta DoH su TCP 443, DoT su TCP 853 né la risoluzione dentro un tunnel VPN di terze parti. Non bloccare indiscriminatamente TCP 443. Policy di browser, sistema operativo, MDM ed endpoint devono controllare Secure DNS non approvato; l’uso noto di DoT può essere gestito in modo mirato. Apple Private Relay e servizi simili richiedono una decisione separata.

La prevenzione termina al confine amministrativo. In reti BYOD o guest, una policy documentata meno rigida è spesso più solida del tentativo di imporre ogni resolver cifrato senza gestione del dispositivo.

Pilot, validazione e accettazione

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

Prima della modifica definire una finestra di osservazione e trigger espliciti di rollback. Eseguire il rollback se la risoluzione interna o VPN non funziona, compare una Location o policy errata, la connettività DoH/TLS resta instabile o viene interrotta una destinazione aziendale necessaria; non ampliare il pilot finché un trigger è aperto.

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 o, per l’uso diretto, con un indirizzo del tenant. corp.example è una zona di documentazione da sostituire. Il test TCP conferma che non funzioni soltanto UDP.

Aprire poi nel browser l’URL copiato da Installers > Check your configuration. Il messaggio di benvenuto conferma il percorso DNS Protection, ma da solo non la policy corretta. Bloccare anche intenzionalmente un dominio di test innocuo e verificare in Central richiesta, Location e policy. I report non sono necessariamente in tempo reale: non diagnosticare un guasto subito dopo una sola richiesta.

L’accettazione richiede che:

entrambi i resolver Sophos funzionino separatamente su UDP e TCP;
le zone forward e reverse interne restino interne;
l’uscita prevista sia associata alla Location corretta;
blocchi e destinazioni aziendali consentite funzionino;
failover WAN, VPN e client IPv6 non creino un percorso alternativo;
DNS non autorizzato sulla porta 53 sia bloccato o reindirizzato come previsto;
i pilot Secure DNS manuali per Windows, macOS e MDM usano esattamente l’URL o il profilo generato, mentre ai pilot Sophos Endpoint è assegnata una policy che seleziona la Location prevista; entrambi compaiono nella Location e policy previste e superano i test in ufficio, in mobilità, su VPN, per i domini interni e durante la rimozione;
monitoraggio e ritorno collaudato siano documentati.

Rollout e rollback controllati

Dopo il pilot, distribuire per ondate, sede o VLAN. Per ogni ondata monitorare errori DNS, ticket, domini aziendali bloccati e associazione dell’uscita. Migrare per ultimi server statici e dispositivi OT/IoT, in una finestra separata.

Per il rollback, disattivare prima le nuove regole che bloccano o reindirizzano il DNS. In modalità con forwarder o client diretto, ripristinare i resolver precedenti documentati in DHCP, VPN e client statici, rinnovare i lease sui dispositivi di test e verificare la risoluzione interna e pubblica prima di ripristinare i forwarder del resolver locale. Per Secure DNS, il responsabile Windows, macOS o MDM rimuove il profilo pilota, mentre il responsabile della policy Sophos Endpoint rimuove l’assegnazione del gruppo pilota. Ripristinare lo stato DNS precedente e verificare che il percorso DoH non sia più usato. Lasciare inizialmente conditional forwarder e Location in Central, salvo che la Location stessa abbia causato l’incidente.

Risoluzione dei problemi per sintomo

I nomi pubblici non si risolvono

Provare esplicitamente entrambi gli indirizzi Sophos su UDP e TCP. Controllare poi regola di uscita, NAT, route e IP sorgente pubblico visibile. DNS Protection può rifiutare un IP senza Location o in conflitto con un altro tenant. Con DDNS verificare anche la risoluzione pubblica del FQDN.

Nomi interni o Active Directory non funzionano

Verificare quale resolver usa realmente il client. Controllare quindi conditional forwarder, target autorevoli, zone reverse, suffissi di ricerca e split DNS VPN. Un resolver DNS Protection assegnato direttamente non conosce le zone private.

Falliscono solo risposte grandi o singoli domini

Provare TCP 53. Se UDP funziona ma dig +tcp no, spesso manca la regola TCP o un intermediario interrompe la connessione. Se un dominio consentito resta bloccato, verificare anche destinazione CNAME e classificazione di sicurezza.

Central non mostra la Location o ne mostra una errata

Individuare l’uscita reale, non solo l’indirizzo WAN configurato. SD-WAN, gateway NAT centrali, proxy e failover possono cambiare l’IP sorgente. Attendere i report e confermare che il test abbia usato il resolver previsto, non DoH del browser o una VPN.

La Block Page manca ma il blocco DNS funziona

Non dimostra che il dominio sia consentito. Controllare blockpage.dnsprotection.sophos.com, attendibilità del DNS Protection Root Certificate, ispezione TLS e filtro web. Installazione e rimozione del certificato devono sempre seguire il processo della piattaforma responsabile.

Il controllo anti-bypass non funziona

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