Configurare Sophos DNS Protection con Sophos Firewall

Sophos DNS Protection protegge le richieste DNS tramite un servizio DNS basato su cloud con policy e reportistica in Sophos Central. La funzione può bloccare domini malevoli, phishing, obiettivi di Command-and-Control e categorie indesiderate, prima che un client stabilisca una connessione al sito web o all’infrastruttura effettiva.

Con Sophos Firewall, la configurazione standard più pulita è generalmente: i client utilizzano il firewall come resolver DNS, il firewall inoltra le richieste DNS pubbliche a DNS Protection, e i domini interni vengono inviati ai server DNS interni tramite DNS Request Routes. In questo modo, la risoluzione dei nomi interni rimane stabile, mentre le richieste DNS pubbliche sono centralmente controllate e registrate.

DNS Protection non sostituisce Web Protection, Threat Feeds o NDR. È un punto di protezione autonomo a livello DNS. Proprio per questo motivo, la funzione dovrebbe essere pianificata consapevolmente e non semplicemente sostituendo i server DNS pubblici.

Video guida

Classificazione Avanet: utilizzare DNS Protection consapevolmente

DNS Protection è tecnicamente interessante, ma non è automaticamente la scelta migliore in ogni ambiente. In molti progetti, non utilizziamo DNS Protection come standard, ma preferiamo resolver DNS veloci e altamente disponibili e blocchiamo ulteriormente obiettivi malevoli noti tramite Sophos Firewall Threat Feeds o fonti di threat intelligence comparabili sul firewall.

Il motivo è semplice: DNS è una funzione di base. Se DNS è lento, non funziona in modo ridondante o genera troppi falsi positivi, gli utenti percepiscono rapidamente l’intera rete come difettosa. La protezione DNS deve quindi essere non solo sicura, ma anche stabile, veloce, comprensibile e ben gestibile.

La decisione dipende dall’obiettivo:

• Resolver DNS veloci e altamente disponibili: ottime prestazioni, risoluzione dei nomi robusta e basso rischio operativo. In cambio non ci sono policy DNS centrali né report DNS in Sophos Central.
• Threat Feeds su Sophos Firewall: gli obiettivi malevoli noti possono essere bloccati al perimetro senza modificare il percorso DNS. Non è però lo stesso del filtraggio DNS per categorie; qualità, tuning e processo di falsi positivi restano importanti.
• Sophos DNS Protection: policy DNS, categorie, Locations, log ed Endpoint DNS Protection vengono gestiti in Sophos Central. In cambio nasce una dipendenza aggiuntiva nel percorso DNS; rollout, certificati, eccezioni e monitoraggio devono essere pianificati con cura.

DNS Protection è quindi particolarmente adatto quando si desiderano esplicitamente log DNS in Sophos Central, policy DNS basate sulla posizione, filtrazione per categorie o protezione DNS endpoint per client in roaming. Se l’obiettivo è principalmente una risoluzione dei nomi veloce e altamente disponibile con blocco aggiuntivo di obiettivi malevoli noti, buoni resolver DNS più Threat Feeds sono spesso la soluzione più pragmatica.

Quando DNS Protection è utile

DNS Protection è particolarmente efficace quando molti client accedono a Internet tramite un firewall centrale o un resolver DNS locale.

Casi d’uso tipici:

• I client non devono utilizzare resolver DNS pubblici arbitrari.
• I domini di malware, phishing e C2 devono essere bloccati precocemente.
• Le richieste DNS devono essere visibili in Sophos Central.
• Diverse sedi devono avere proprie policy DNS.
• I nomi DNS interni devono continuare a funzionare tramite server DNS locali.
• Web Protection deve essere integrato con un controllo DNS a monte.

DNS Protection non è però un sostituto per l’ispezione dei contenuti. Se un dominio consentito fornisce successivamente contenuti dannosi o se il traffico HTTPS deve essere esaminato più da vicino, Web Protection, TLS Inspection, IPS, protezione endpoint e logging rimangono rilevanti.

DNS Protection non è ideale se si cerca semplicemente un forwarder DNS esterno veloce o se esiste già un’operazione DNS molto stabile con Threat Feeds separati, Web Protection, protezione endpoint e monitoraggio accurato. In tal caso, si dovrebbe prima verificare quale valore aggiunto concreto DNS Protection offre e chi gestisce la policy, le eccezioni e i falsi positivi.

Architettura con Sophos Firewall

Per Sophos Firewall, questa configurazione è generalmente la più chiara:

1. Sophos Central riconosce la sede come Location.
2. Sophos Central fornisce due indirizzi IP di DNS Protection.
3. Sophos Firewall utilizza questi indirizzi IP come DNS Forwarder.
4. I domini interni vengono inviati ai server DNS interni tramite DNS Request Routes.
5. DHCP distribuisce il firewall come resolver DNS ai client.
6. Facoltativamente, una regola NAT impone che il traffico DNS in uscita venga reindirizzato al firewall.
7. I log e i report di DNS Protection vengono valutati in Sophos Central.

Questa configurazione garantisce che i client non debbano essere configurati direttamente sul servizio DNS di Sophos. Il firewall rimane il resolver centrale nella LAN e può gestire meglio i casi speciali interni.

È importante distinguere tra Traditional DNS e Secure DNS:

• Traditional DNS over IPv4: per sedi firewall, router, server DNS locali o reti con IP pubblico fisso o FQDN DDNS. Sophos Central associa le richieste DNS alla Location tramite l’IP sorgente pubblico o il FQDN.
• Secure DNS: per Endpoint DNS Protection tramite Sophos Endpoint. Sophos Central genera per la Location un percorso DNS-over-HTTPS univoco.

Per una Sophos Firewall come DNS Forwarder, di norma Traditional DNS over IPv4 è il percorso corretto. Secure DNS appartiene al percorso endpoint e non dovrebbe essere confuso con le impostazioni DNS Forwarder del firewall.

Prerequisiti

Prima del rollout, dovrebbero essere chiariti questi punti:

• Accesso a Sophos Central con autorizzazione per DNS Protection.
• Licenza appropriata: Xstream Protection per DNS Protection standalone o Workspace Protection per DNS Protection endpoint.
• IP WAN pubblico o un nome FQDN/DDNS stabile per la sede.
• Decisione se la Location viene usata per Traditional DNS o Secure DNS.
• Sophos Firewall viene utilizzato come resolver DNS per le reti interessate o dovrebbe esserlo.
• Domini interni, zone Active Directory e reverse lookup sono noti.
• I server DHCP per le reti client sono identificati.
• Le eccezioni per domini interni e servizi critici sono pianificate.
• Per Endpoint DNS Protection: piattaforme endpoint supportate e gruppo di rollout verificati.
• I responsabili per la policy DNS, i falsi positivi e il logging sono definiti.

Se l’indirizzo IP pubblico cambia frequentemente, si dovrebbe chiarire prima del rollout se una configurazione DDNS è sufficientemente stabile. Sophos DNS Protection può identificare le posizioni anche tramite un FQDN, ma un cambio di IP può comunque causare interruzioni temporanee.

Per ambienti grandi, la struttura delle Location dovrebbe essere pianificata consapevolmente. Le Location sono oggetti operativi e di policy, non una struttura sostitutiva per ogni VLAN, piano o piccolo gruppo speciale. La Location predefinita Default è riservata e non può essere usata come Location di sede personalizzata. Spesso una logica per sede, firewall o tenant è più adatta di suddivisioni tecniche troppo fini.

Sophos DNS Protection consente al massimo 50 Location. Per ogni Location Traditional DNS si possono inserire più indirizzi IP pubblici o FQDN; Sophos indica un massimo di 100 voci. Sembra generoso, ma è comunque un argomento contro una struttura di Location troppo granulare. Per le policy è meglio suddividere per sede, uscita internet e responsabilità che per ogni singola VLAN.

1. Creare una Location in Sophos Central

In Sophos Central, prima si crea la sede:

My Products > DNS Protection > Locations

Procedura pratica:

1. Selezionare Add.
2. Inserire il nome e la descrizione della sede.
3. Per sedi firewall utilizzare Traditional DNS over IPv4.
4. Registrare l’IP WAN pubblico del Sophos Firewall.
5. In caso di più interfacce WAN, inserire tutti gli indirizzi IP pubblici rilevanti o un intervallo appropriato.
6. In caso di IP dinamico, utilizzare un FQDN DDNS se il design si basa su questo.
7. Salvare la Location.

La Location è importante perché DNS Protection deve associare le richieste DNS in entrata al giusto account cliente e alla giusta policy. Se manca la Location o l’IP pubblico non è corretto, Sophos Central non vede correttamente la sede.

Gli indirizzi IP privati non appartengono a una Location DNS Protection. Sophos Central deve vedere l’IP sorgente pubblico con cui le richieste DNS arrivano al servizio. Se Central rileva automaticamente un IP pubblico, si dovrebbe comunque verificare se questo indirizzo è davvero il percorso di uscita previsto del firewall. In caso di successive modifiche IP, la Location deve essere mantenuta; il rilevamento automatico non sostituisce il monitoraggio operativo.

2. Copiare gli indirizzi IP di DNS Protection

Gli indirizzi IP di DNS Protection si trovano in Sophos Central sotto:

My Products > DNS Protection > Installers

Qui vengono forniti due indirizzi IP. Questi vengono utilizzati su Sophos Firewall come server DNS primario e secondario. Non inserire altri server DNS pubblici come fallback se si desidera che il traffico passi completamente attraverso DNS Protection. Altrimenti, i server DNS possono essere utilizzati bypassando DNS Protection a seconda del comportamento del resolver, e la protezione e la visibilità vengono perse.

Con Secure DNS il processo è diverso: lì il componente endpoint lavora con una destinazione DNS-over-HTTPS, non con i classici indirizzi IP DNS Forwarder del firewall. Se in questo punto ci si aspetta indirizzi IP per il firewall ma è stata creata una Secure-DNS-Location, probabilmente è stato scelto il tipo di Location sbagliato.

3. Configurare il DNS Forwarder su Sophos Firewall

Su Sophos Firewall:

Network > DNS

Procedura consigliata:

1. Selezionare Static DNS.
2. Impostare DNS 1 sul primo indirizzo IP di DNS Protection.
3. Impostare DNS 2 sul secondo indirizzo IP di DNS Protection.
4. Lasciare DNS 3 vuoto, se non esiste un caso speciale consapevole.
5. Sotto IPv6 selezionare anche Static DNS, non inserire server DNS IPv6 e selezionare Choose IPv4 DNS server over IPv6 se la sede deve usare i server DNS Protection basati su IPv4.
6. Salvare e applicare l’impostazione.

DNS Protection funziona come servizio DNS basato su IPv4, ma può anche risolvere indirizzi IPv6. Non è quindi necessario un server DNS IPv6 separato.

Se un firewall utilizza più percorsi WAN, la Location deve corrispondere all’IP sorgente pubblico effettivamente usato in uscita. SD-WAN, failover, Policy Routing o un altro design NAT possono far uscire le richieste DNS tramite un indirizzo pubblico diverso da quello previsto. Questo dovrebbe essere testato consapevolmente nel pilota.

4. Proteggere i domini interni con DNS Request Routes

DNS Protection non risolve i domini interni. Se nella rete vengono utilizzati Active Directory, applicazioni interne, zone locali o reverse lookup, queste richieste devono essere inviate ai server DNS interni.

Per questo si utilizza su Sophos Firewall:

Network > DNS > DNS request route

Esempio:

• Host/domain name: azienda.local o corp.example.com
• Target servers: controller di dominio interni o server DNS

Senza queste rotte, i nomi interni verrebbero inviati a DNS Protection e non risolti correttamente. La procedura dettagliata è descritta in Configurare DNS Request Routes su Sophos Firewall.

Per ambienti produttivi, i domini interni dovrebbero essere considerati anche in DNS Protection come lista di domini, se il dominio potrebbe essere bloccato da una categoria. Esempi tipici sono siti o servizi interni che altrimenti potrebbero rientrare in categorie problematiche come Parked Domains.

5. Far puntare i client al firewall tramite DHCP

I client dovrebbero utilizzare Sophos Firewall come resolver DNS, non direttamente resolver esterni arbitrari.

Se Sophos Firewall fornisce DHCP:

Network > DHCP

Procedura pratica:

1. Modificare il server DHCP dell’interfaccia interessata.
2. Distribuire l’indirizzo IP dell’interfaccia del firewall come server DNS primario.
3. Decidere consapevolmente il DNS secondario.
4. Rinnovare il lease DHCP o ricollegare il client di test.
5. Verificare con un client di test quale server DNS viene effettivamente utilizzato.

Nella configurazione di esempio ufficiale Sophos mostra spesso l’IP dell’interfaccia firewall come server DNS primario e un IP di DNS Protection come DNS secondario. Questo può funzionare come fallback, ma non è la variante migliore in ogni ambiente. Se i client usano direttamente il DNS secondario, bypassano il firewall come resolver. Le DNS Request Routes interne, le zone locali speciali e i singoli punti di controllo sul firewall non si applicano quindi a queste richieste come previsto.

Se è in uso un server DNS Windows o un altro resolver interno, questo resolver può inoltrare a DNS Protection invece dei client. Tuttavia, deve essere chiaro dove vengono risolti i domini interni e quale server inoltra le richieste pubbliche.

6. Prevenire l’elusione diretta del DNS

Molti client utilizzano il server DNS distribuito tramite DHCP. Alcuni dispositivi, browser, sistemi IoT o client configurati intenzionalmente possono però utilizzare propri server DNS.

Una possibile contromisura è una regola NAT che reindirizza il traffico DNS in uscita dalle reti interne al firewall. In pratica, ciò significa che il traffico DNS dalle reti sorgente interne viene indirizzato tramite DNAT all’indirizzo interno del firewall, in modo che la richiesta possa essere valutata tramite DNS Protection.

Importante:

• Catturare solo le reti sorgente interne.
• Non utilizzare interfacce WAN come interfaccia di ingresso.
• Posizionare consapevolmente la regola molto in alto.
• Documentare le eccezioni per server DNS interni e casi speciali.
• Aspettarsi solo traffico DNS classico su UDP/TCP 53; DoH e DoT devono essere gestiti separatamente tramite controlli client, browser, MDM o Web Policy.
• Successivamente, testare se la risoluzione DNS interna, DNS Protection e i log sono ancora corretti.

Le basi del NAT sono descritte in Comprendere il NAT su Sophos Firewall. Un’imposizione DNS non dovrebbe essere attivata alla cieca, poiché può influenzare resolver interni, client VPN, comportamento DoH/DoT o dispositivi speciali.

Pianificare il rollout in fasi

DNS Protection non dovrebbe essere imposto immediatamente a tutte le reti contemporaneamente. DNS è una funzione di base: se i nomi interni, le verifiche dei certificati, gli aggiornamenti software o i servizi SaaS non vengono più risolti correttamente, sembra rapidamente un’interruzione generale di Internet.

Un rollout controllato appare in pratica così:

1. Selezionare una rete pilota o un piccolo gruppo di test.
2. Documentare i domini interni, le zone inverse e i domini di ricerca.
3. Configurare DNS Request Routes per le zone interne.
4. Distribuire il firewall come resolver DNS tramite DHCP.
5. Impostare gli indirizzi IP di DNS Protection sul firewall.
6. Installare il certificato delle pagine di blocco sui client di test.
7. Verificare i log in Sophos Central.
8. Solo successivamente includere altre reti, rete ospiti, reti server o reti VPN.

Per le reti server, si dovrebbe essere particolarmente cauti. Alcuni sistemi utilizzano DNS per la verifica delle licenze, aggiornamenti, CRL/OCSP, backup, monitoraggio o comunicazione del cluster. In questi casi, una finestra di test con rollback è più importante che per le normali reti client.

Test di accettazione prima del rollout ampio

Prima del rollout produttivo, dovrebbe essere chiaro come riconoscere un’implementazione di DNS Protection funzionante. Solo il link di test di Sophos non è sufficiente.

• Risolvere un dominio pubblico: il client interroga il firewall o il resolver interno previsto.
• Risolvere un dominio AD interno: la richiesta passa tramite DNS Request Route ai server DNS interni.
• Testare il reverse lookup: le zone PTR interne continuano a funzionare.
• Aprire un dominio di test bloccato: DNS Protection blocca e registra l’evento.
• Verificare i log in Sophos Central: gli eventi appaiono nella Location corretta.
• Testare la rete ospiti: gli ospiti utilizzano il percorso DNS pianificato e non i server DNS interni.
• Testare il client VPN: Split-DNS, domini interni e domini pubblici si comportano come previsto.
• Verificare il DoH del browser: il browser o il sistema operativo non aggirano il controllo inaspettatamente.

Se uno di questi test fallisce, non si dovrebbe aprire immediatamente la policy. Prima deve essere chiaro se il problema riguarda DHCP, DNS Request Routes, assegnazione della Location, profilo del client, DoH del browser, tunnel VPN o categorizzazione del dominio.

7. Pianificare policy e liste di domini

DNS Protection può bloccare domini rilevanti per la sicurezza anche senza una policy propria, se SophosLabs li classifica come minaccia o rischio per la sicurezza. Le policy proprie integrano questa baseline con le direttive aziendali.

Domande tipiche sulla policy:

• Quali Location ricevono quale policy?
• Quali categorie devono essere bloccate?
• Quali categorie sono problematiche solo per determinate sedi?
• Quali domini devono essere esplicitamente consentiti?
• Chi decide sui falsi positivi?
• Quanto tempo rimangono valide le eccezioni?

Le liste di domini dovrebbero essere gestite con attenzione. Una lista di permessi ampia può ridurre l’efficacia della protezione. Una lista di blocchi ampia può disturbare i processi aziendali. Ogni lista necessita di uno scopo, un proprietario e una data di revisione.

Filtering Policy o Endpoint DNS Protection Policy?

In Sophos Central ci sono due livelli di policy che non devono essere confusi.

• Filtering policy: filtraggio DNS basato su sede, firewall o rete. Usare per uffici, firewall, server DNS, reti server, ospiti, IoT e dispositivi senza Sophos Endpoint.
• Endpoint DNS Protection policy: protezione DNS basata su endpoint tramite Sophos Endpoint. Usare per client gestiti, notebook e utenti che devono essere protetti anche al di fuori della rete aziendale.

Una Filtering policy viene creata sotto DNS Protection > Policies > Filtering policies e assegnata a una o più Location o firewall. Per ogni Location può essere attiva solo una Filtering Policy. In questa policy si definiscono categorie, liste di domini e opzioni aggiuntive come Safe Search.

Una Endpoint DNS Protection policy utilizza Sophos Endpoint. L’endpoint intercetta il traffico DNS sul dispositivo e lo inoltra in modo sicuro tramite HTTPS a DNS Protection. In questo modo, non è necessario configurare manualmente il client sugli indirizzi IP di DNS Protection. I dispositivi vengono assegnati in Endpoint Policy a una Location di DNS Protection e vengono successivamente gestiti dalla Filtering Policy corrispondente a quella Location.

In pratica, ciò significa:

• Per un ufficio con Sophos Firewall, la Location più Filtering policy è il percorso di rete normale.
• Per i client in roaming, la Endpoint DNS Protection policy è utile, poiché la protezione può agire anche al di fuori della rete aziendale.
• Endpoint DNS Protection non è automaticamente disponibile per ogni sistema operativo aziendale. Sophos supporta attualmente gli endpoint Windows; Windows Server e macOS non sono supportati per questa policy. Server, macOS, Linux, dispositivi mobili e dispositivi speciali devono quindi essere valutati tramite DNS di rete, design VPN o altri controlli.
• Per ambienti misti, si combinano entrambi gli approcci: sedi firewall tramite Location, endpoint gestiti aggiuntivamente tramite Endpoint DNS Protection.
• Per i domini interni, nelle Endpoint Policies dovrebbero essere mantenute le esclusioni di dominio. Sophos consiglia di escludere esplicitamente le zone interne, anziché affidarsi solo a un retry NXDOMAIN.
• Le pagine di blocco sugli endpoint richiedono il DNS Protection Root Certificate. Con Sophos Endpoint, il certificato può essere distribuito automaticamente.

Quali categorie si possono bloccare?

DNS Protection offre categorie organizzate in gruppi in Sophos Central. Alcune categorie sono più legate alla produttività, altre sono chiaramente rilevanti per la sicurezza. I nomi rimangono intenzionalmente in inglese, poiché vengono visualizzati così anche in Sophos Central.

• Productivity-related categories: include tra l’altro Advertisements, Auctions & classified ads, Dynamic DNS & ISP sites, Entertainment, Fashion & beauty, Gambling, Games, Hobbies, Hunting & fishing, Kid’s sites, News, Online chat, Online shopping, Personal sites, Photo galleries, Portal sites, Religion & spirituality, Restaurants & dining, Sports, Stocks & trading, Surveillance, Travel, Society & culture e Vehicles. Consentire, bloccare o limitare solo per determinate reti a seconda della policy aziendale.
• Social networking: include Blogs & forums, Personals & dating e Social networks. Di solito non è una questione puramente di sicurezza; per le reti produttive decidere consapevolmente anziché bloccare in modo generale.
• Adult and potentially inappropriate categories: include tra l’altro Alcohol & tobacco, Controlled substances, Criminal activity, Download freeware & shareware, Extreme, Intellectual piracy, Intolerance & hate, Legal highs, Marijuana, Militancy & extremist, Nudity, Plagiarism, Pro-suicide & self harm, Sex education, Sexually explicit, Swimwear & lingerie e Weapons. In molti ambienti aziendali bloccare, con eccezioni solo motivate chiaramente.
• Categories likely to cause excessive bandwidth usage: include Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting e Voice & video calls. Spesso rilevante per reti ospiti e client. Verificare prima gli strumenti di collaborazione, in modo che le chiamate legittime non vengano disturbate.
• Business-relevant site categories: include tra l’altro General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Information technology, Job search, Reference, Search engines, Software updates e Translators. Di solito consentire. Alcune categorie possono essere limitate in reti ad alta sicurezza.
• Infrastructure: include Content delivery, CRL e OCSP. Normalmente consentire, perché queste categorie possono essere importanti per aggiornamenti, verifica dei certificati e molti servizi cloud.
• Threats and liabilities: include Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware e Unauthorized software stores. Di solito bloccare. In caso di falsi positivi, lavorare miratamente con liste di domini, non aprire interi gruppi.
• Data loss: include Business cloud apps, Personal cloud apps, Personal network storage e Web E-mail. Dipende molto da DLP, cloud e requisiti di compliance. Per reti server e amministrative spesso va trattato in modo più restrittivo rispetto agli utenti normali.
• Uncategorized: non bloccare alla cieca. Valutare prima, perché servizi legittimi nuovi o interni possono essere temporaneamente Uncategorized.

Le liste di domini hanno la precedenza sulle categorie. Un dominio consentito in una lista di domini rimane consentito, anche se la categoria sarebbe bloccata. Un dominio bloccato rimane bloccato, anche se la categoria sarebbe consentita. Pertanto, le liste di domini dovrebbero essere documentate e regolarmente esaminate.

8. Pagine di blocco e certificati

Per i domini bloccati, DNS Protection può mostrare una pagina di blocco HTTPS. Affinché gli utenti vedano correttamente questa pagina di blocco, il DNS Protection Root Certificate deve essere installato in modo affidabile sui dispositivi interessati.

Se è attiva anche TLS Inspection o Webfiltering sul firewall, la pianificazione dei certificati e delle eccezioni deve essere coerente. Per il certificato CA del firewall, si adatta Distribuire il certificato CA di Sophos Firewall per TLS Inspection.

Il certificato e il test della pagina di blocco si trovano in Sophos Central sotto DNS Protection > Installers. Inoltre, blockpage.dnsprotection.sophos.com dovrebbe essere raggiungibile. Se questo dominio viene disturbato da Web Protection, TLS Inspection, una policy DNS o un altro controllo, la decisione effettiva di DNS Protection può essere corretta, ma la pagina di blocco può comunque apparire in modo errato o non apparire affatto.

Se le pagine di blocco non vengono visualizzate, non si dovrebbe immediatamente modificare la policy. Spesso mancano i certificati, il client utilizza un altro percorso DNS, o blockpage.dnsprotection.sophos.com viene disturbato da un altro controllo.

Testare DNS Protection

Sophos Central fornisce un link di test sotto DNS Protection > Installers. Se la configurazione è corretta, il browser mostra una conferma.

Inoltre, si dovrebbe testare in modo pratico:

• Il client utilizza il firewall come server DNS.
• Un dominio pubblico viene risolto tramite DNS Protection.
• Un dominio interno viene risolto correttamente tramite DNS Request Route.
• Un dominio di test bloccato viene bloccato.
• I log appaiono in Sophos Central.
• Le richieste DNS appaiono nella posizione corretta.
• Non vengono utilizzati server DNS alternativi.
• La rete VPN o ospiti si comporta come previsto.

Per un’analisi degli errori reale, non si dovrebbe testare solo il browser. nslookup, dig, log del firewall, lease DHCP e log di Sophos Central insieme forniscono un quadro migliore.

Comandi di test per i client

Su un client di test, si dovrebbe prima verificare quale server DNS viene effettivamente utilizzato. Un test del browser riuscito non è sufficiente se il client utilizza parallelamente un altro resolver, DoH o un profilo VPN.

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:

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

In questo caso, <firewall-ip> dovrebbe essere sostituito con l’indirizzo dell’interfaccia interna di Sophos Firewall che dovrebbe servire come resolver DNS nella rete specifica. Se la richiesta contro il firewall funziona, ma la richiesta normale utilizza un altro resolver, il problema è solitamente nel DHCP, nel profilo del sistema operativo, nel client VPN, nel DoH del browser o in una configurazione DNS locale.

Per i domini interni, si dovrebbe inoltre eseguire un test con una zona interna:

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

Questo test deve finire tramite la DNS Request Route sul server DNS interno. Se i domini pubblici funzionano, ma i nomi interni no, DNS Protection raramente è la causa effettiva. In tal caso, si dovrebbero verificare DNS Request Routes, server DNS interni, domini di ricerca e suffissi DNS del client.

Risoluzione dei problemi

La sede non appare in Sophos Central

Verificare se l’IP WAN pubblico o il FQDN DDNS nella Location è corretto. In caso di più linee WAN, devono essere considerate tutte le indirizzi di uscita rilevanti. In caso di indirizzi IP dinamici, possono esserci brevi ritardi prima che DNS Protection riconosca la modifica.

Verificare inoltre se il tipo di Location corrisponde al design. Un firewall che invia richieste DNS classiche agli indirizzi IP forniti appartiene al percorso Traditional DNS. Endpoint DNS Protection usa invece Secure DNS tramite il componente endpoint.

Se la Location viene gestita tramite un FQDN, si dovrebbe inoltre verificare se il FQDN punta davvero dall’esterno all’IP pubblico attuale. Sophos Central può mostrare un indirizzo rilevato automaticamente, ma le modifiche successive devono essere controllate durante l’esercizio.

Se non è visibile alcuna assegnazione della Location nonostante la configurazione corretta del firewall, si dovrebbe controllare anche My Environment > Alerts in Sophos Central. Possono sorgere problemi se un FQDN non punta a un IP pubblico valido o se lo stesso IP pubblico è già usato in un’altra Location DNS Protection di un altro account cliente. Questo è particolarmente rilevante con CGNAT, indirizzi provider condivisi, uscite proxy/VPN centrali o nomi DDNS gestiti in modo errato.

I nomi interni non funzionano più

In tal caso, mancano solitamente DNS Request Routes o i client non interrogano il resolver previsto. I domini AD interni, le zone inverse e i domini delle applicazioni dovrebbero essere inoltrati esplicitamente ai server DNS interni.

DNS Protection blocca un dominio interno o legittimo

Prima chiarire se il dominio è interno, pubblico, categorizzato erroneamente o effettivamente rischioso. Successivamente, verificare la lista di domini e la policy. Non impostare una regola di permesso ampia prima di conoscere la causa e gli utenti interessati.

I log rimangono vuoti

Se non appaiono log in Sophos Central, il client potrebbe non utilizzare DNS Protection. Verificare: DHCP, DNS del client, DNS del firewall, reindirizzamento NAT, resolver alternativi, profilo VPN e se la sede viene riconosciuta correttamente in Sophos Central.

Per analisi più approfondite si può usare anche Threat Analysis Center > Live Discover, se l’ambiente utilizza le funzioni Central necessarie. Lì i dati di DNS Protection possono essere interrogati in modo più granulare rispetto ai report standard, per esempio per dominio, Policy Action, Location, utente o dispositivo. Per una normale accettazione, tuttavia, sono sufficienti innanzitutto log e report, client di test e verifica del resolver.

La pagina di blocco non appare

In tal caso, spesso manca il DNS Protection Root Certificate, il client utilizza un altro percorso DNS, o un altro controllo di sicurezza influenza la connessione. Anche TLS Inspection e Web Protection dovrebbero essere verificate.

Verificare inoltre se il dominio della pagina di blocco è raggiungibile e non viene bloccato da una policy a monte. Se un browser usa DoH, un profilo VPN o Apple Private Relay, è possibile che non si veda alcuna pagina di blocco Sophos anche se il normale percorso DNS di rete sarebbe corretto.

DoH o DNS privato aggira il controllo

Browser e sistemi operativi possono utilizzare DNS over HTTPS o funzioni DNS private. A seconda dell’ambiente, queste funzioni devono essere gestite tramite policy del browser, MDM o sistema operativo. DNS Protection sul percorso di rete aiuta solo se le richieste passano effettivamente tramite il resolver previsto.

I client VPN si comportano diversamente dai client LAN

Per i client VPN, il comportamento dipende fortemente dal profilo. Full Tunnel, Split Tunnel, suffissi DNS, domini di ricerca e resolver locali del client possono influenzare la risoluzione dei nomi. Se DNS Protection funziona nella LAN, ma non tramite VPN, si dovrebbe prima verificare il profilo VPN, i server DNS assegnati, i suffissi DNS e le regole del firewall. Per ambienti di accesso remoto, si adatta anche Sophos Connect o SSL VPN: Quale soluzione di accesso remoto è adatta?.

Raccomandazione operativa

DNS Protection dovrebbe essere gestito come un controllo di sicurezza, non come un semplice scambio di server DNS.

Dal punto di vista di Avanet, si dovrebbe decidere onestamente in anticipo se DNS Protection è effettivamente lo strumento giusto per l’ambiente. Per molte installazioni classiche di firewall, resolver DNS veloci e ridondanti più Threat Feeds ben gestiti sul firewall sono la variante operativa più robusta. DNS Protection è utile soprattutto se l’operazione intende utilizzare attivamente anche le policy Central, i log, le categorie, le liste di domini e la componente endpoint.

Verificare regolarmente:

• Le Location e gli indirizzi IP WAN sono corretti.
• DHCP distribuisce ancora i server DNS corretti.
• Le DNS Request Routes interne sono aggiornate.
• Le policy e le liste di domini hanno un proprietario e una data di revisione.
• I log vengono valutati.
• I domini principali bloccati vengono verificati per falsi positivi.
• Nuove sedi, reti VPN e reti ospiti sono considerate nel design.

Per i temi di rilevamento, può integrare Gestire Sophos Firewall NDR e Active Threat Response. Per IP, domini e URL malevoli noti a livello di firewall, rimangono rilevanti Sophos Firewall Threat Feeds.

Checklist

• Licenza Sophos Central DNS Protection verificata.
• Sede creata come Location.
• Tipo di Location scelto correttamente: Traditional DNS per sedi firewall, Secure DNS per Endpoint DNS Protection.
• IP WAN pubblico o FQDN DDNS correttamente registrato.
• Limite delle Location e voci IP/FQDN pianificati consapevolmente.
• Indirizzi IP di DNS Protection copiati da Central.
• Sophos Firewall utilizza DNS Protection come DNS Forwarder.
• Domini interni coperti con DNS Request Routes.
• DHCP distribuisce il firewall come resolver DNS.
• DNS secondario sui client deciso consapevolmente e non costruito accidentalmente come bypass.
• Elusione diretta del DNS verificata e, se necessario, reindirizzata tramite NAT.
• DoH, DoT, profili VPN e policy browser verificati separatamente.
• Certificato Root di DNS Protection pianificato per le pagine di blocco.
• Piattaforme endpoint e dispositivi non supportati valutati separatamente.
• Link di test da Sophos Central verificato con successo.
• Log e report controllati in Sophos Central.
• Processo di falsi positivi e revisione delle liste di domini definiti.

FAQ