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

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 Central, 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 Central.
• 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.

Il percorso firewall consigliato è il seguente:

1. Sophos Central identifica la sede come Location.
2. Sophos Central 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 Central 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.

Prima del rollout devono essere chiariti licenza, indirizzi di uscita pubblici, zone DNS interne, server DHCP e responsabili di policy ed eccezioni. Xstream Protection copre DNS Protection standalone. Endpoint DNS Protection richiede Workspace Protection e anche una licenza Sophos Endpoint adeguata.

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.

Configurare DNS Protection

1. Creare una Location in Sophos Central

My Products > DNS Protection > Locations

1. Selezionare Add e inserire un nome univoco per la sede.
2. Attivare Traditional DNS over IPv4.
3. Inserire l’indirizzo WAN pubblico o un FQDN DDNS stabile.
4. In caso di Multi-WAN, considerare tutti gli indirizzi di uscita effettivamente utilizzati.
5. Salvare la Location.

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 sono disponibili due indirizzi IP di DNS Protection. Copiare sempre questi valori dal proprio tenant Central e utilizzarli 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.

3. Configurare il firewall come DNS Forwarder

Network > DNS

1. Selezionare Static DNS.
2. Inserire i due indirizzi Central 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. Salvare la configurazione.

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.

4. Inoltrare i domini interni

Network > DNS
DNS request route section > 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

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. Modificare il server DHCP della rete interessata.
2. Distribuire come server DNS l’IP dell’interfaccia interna del firewall.
3. Rinnovare il lease su un client di test.
4. Verificare il resolver effettivamente utilizzato.

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

Una regola DNAT facoltativa può reindirizzare al firewall il traffico DNS tradizionale dei client interni:

• Original source: reti interne interessate
• Original destination: gruppo host in uscita o Internet IPv4
• Original service: DNS
• Translated destination: IP interno del firewall
• Inbound interfaces: solo le interfacce corrispondenti alle sorgenti interne, mai WAN
• Position: in alto, prima delle regole NAT più generiche

Le eccezioni per server DNS interni e dispositivi speciali devono essere documentate. 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 risoluzione interna, VPN, rete guest e log. 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.

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.

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

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

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 essere superati questi controlli:

• 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.
• i log vengono visualizzati in Sophos Central dopo il ritardo di reporting previsto.
• 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

La Location non appare in Sophos Central

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.

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 rispetto al tempo reale. Solo successivamente verificare DHCP, DNS del client, DNS del firewall, reindirizzamento NAT, resolver alternativi, profili VPN e assegnazione della Location.

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.

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.

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.