Configurer Sophos DNS Protection avec Sophos Firewall

Sophos DNS Protection vérifie les requêtes DNS via un service cloud et gère les politiques ainsi que les rapports dans Sophos Fusion (anciennement Sophos Central). Il permet de bloquer les domaines malveillants, le phishing, les cibles de commande et de contrôle et les catégories indésirables avant que le client n’établisse la connexion proprement dite.

Avec Sophos Firewall, l’architecture standard la plus propre est généralement la suivante : les clients utilisent le pare-feu comme résolveur DNS, le pare-feu transmet les requêtes publiques à DNS Protection et les domaines internes sont envoyés aux serveurs DNS internes via DNS Request Routes.

DNS Protection ne remplace ni Web Protection, ni les Threat Feeds, ni NDR et Active Threat Response. Il complète ces contrôles au niveau DNS.

Ce guide reste volontairement centré sur Sophos Firewall : valeurs Fusion, transfert DNS, Request Routes, DHCP, NAT, validation et retour arrière. Le guide de configuration réseau décrit l’architecture indépendante du fabricant et les autorisations ; le guide des Locations couvre leur cycle de vie complet.

Décision et architecture cible

Le DNS est un service essentiel. Si le résolveur est lent, instable ou trop restrictif, les utilisateurs ont rapidement l’impression que tout le réseau est en panne. DNS Protection ne doit donc être utilisé que si les avantages des politiques, catégories et journaux Fusion ou de la protection des clients itinérants justifient la charge d’exploitation supplémentaire.

Du point de vue d’Avanet, des résolveurs rapides et redondants associés à des Threat Feeds correctement entretenus constituent la solution la plus pragmatique pour de nombreuses installations de pare-feu classiques. DNS Protection convient particulièrement lorsque :

• les requêtes DNS doivent être visibles dans Sophos Fusion.
• les sites nécessitent des politiques DNS différentes.
• des catégories doivent être bloquées dès la résolution de noms.
• les clients ne doivent pas utiliser librement des résolveurs publics.
• les endpoints Windows gérés doivent également être protégés hors du réseau de l’entreprise.

Le chemin recommandé pour le pare-feu est le suivant :

1. Sophos Fusion connaît le site en tant que Location.
2. Sophos Fusion fournit deux adresses IP DNS Protection.
3. Sophos Firewall utilise les deux adresses comme DNS Forwarders.
4. DNS Request Routes envoie les zones internes vers les serveurs DNS internes.
5. DHCP distribue le pare-feu comme résolveur aux clients.
6. Une règle NAT facultative force le trafic DNS classique à suivre ce chemin.
7. Sophos Fusion journalise et évalue les requêtes DNS publiques.

Il faut distinguer deux méthodes :

• Traditional DNS over IPv4 : pour les pare-feu, routeurs et résolveurs locaux. Sophos attribue les requêtes à la Location à partir de l’IP source publique ou d’un FQDN DDNS.
• Secure DNS : DNS over HTTPS (DoH) pour les appareils compatibles. Sophos Endpoint peut gérer ce chemin sur les endpoints Windows pris en charge ; Windows et macOS peuvent également être configurés manuellement pour Secure DNS.

Une Location personnalisée peut prendre en charge les deux méthodes. Pour le transfert par le pare-feu, Traditional DNS doit être activé et l’IP publique ou le FQDN doit être enregistré.

Ne pas confondre les quatre chemins DNS

Pour le dépannage, il faut savoir où la requête est traitée :

• Service DNS Protection : le résolveur cloud évalue les requêtes publiques selon la Filtering Policy de la Location détectée. Ses rapports se trouvent dans Sophos Fusion, pas dans le Log Viewer du pare-feu.
• Pare-feu comme résolveur : le client interroge une IP d’interface du pare-feu sur UDP ou TCP 53. Le service DNS local choisit entre une DNS Request Route et les forwarders sous Network > DNS. Sous Administration > Device access, DNS doit être autorisé pour la zone source. Une règle de pare-feu ne peut pas autoriser ce service local.
• DNS en transit : si un client interroge directement l’IP d’un résolveur public, le pare-feu ne fait que transmettre le trafic. Une règle de pare-feu s’applique, mais pas les DNS Request Routes. Le journal de la règle prouve donc le transport, pas le traitement par DNS Protection.
• Endpoint DNS Protection : Sophos Endpoint intercepte les requêtes Windows prises en charge et les envoie en HTTPS à la Secure DNS Location. Une règle NAT sur le port 53 et les Request Routes du pare-feu ne font pas partie de ce chemin. Seuls les domaines exclus, ou la nouvelle tentative NXDOMAIN facultative, utilisent la résolution DNS locale.

Dans l’architecture recommandée pour un site, les clients utilisent le résolveur du pare-feu. Un accès direct aux IP DNS Protection n’est pas équivalent lorsque des zones internes dépendent de Request Routes.

Avant le déploiement, il faut clarifier la licence, les adresses de sortie publiques, les zones DNS internes, les serveurs DHCP et les responsables des politiques et exceptions. Xstream Protection couvre DNS Protection autonome pour le pare-feu. Workspace Protection couvre DNS Protection pour les endpoints ; Sophos Endpoint doit être installé sur les appareils. Les deux licences incluent DoH.

Pour que DNS Protection apparaisse comme produit dans Sophos Fusion, le pare-feu sous licence Xstream doit être lié au même compte Fusion. Vérifiez la licence sous Administration > Licensing sur le pare-feu ou sur la page Firewall Licensing de Sophos Fusion. Sophos documente trois méthodes de liaison : enregistrement lors de l’installation, revendication du numéro de série sous Firewall Licensing ou activation de la gestion Sophos Fusion dans WebAdmin.

Les décisions de licence et les autorisations Fusion relèvent des processus existants de licence Sophos Fusion et de rôles administratifs. Le responsable du pare-feu doit disposer de l’accès à DNS Protection et aux valeurs approuvées du tenant, sans élargir les rôles dans le cadre de ce changement.

La Location prédéfinie Default peut être utilisée pour Secure DNS et recevoir des politiques ; elle ne peut simplement pas être modifiée ou supprimée. La limite est de 50 Locations et de 100 entrées IPv4/FQDN publiques par Location. Les Locations doivent donc être organisées par site et sortie Internet, et non par VLAN.

Configurer DNS Protection

1. Créer une Location dans Sophos Fusion

My Products > DNS Protection > Locations

1. Sélectionner Add et saisir un nom unique sous Name ; utiliser idéalement Description pour identifier la sortie Internet et le responsable.
2. Sous Connection method, activer Traditional DNS over IPv4.
3. Sous IPv4 addresses or FQDNs, saisir l’IP WAN publique ou un FQDN DDNS stable. Valider chaque valeur avec Enter ou Tab.
4. En Multi-WAN, inclure toutes les adresses de sortie utilisées. Les adresses de pare-feu détectées automatiquement ne sont pas mises à jour automatiquement après un changement.
5. Sélectionner Save.

Les adresses IP privées ne sont pas valides. Sophos doit reconnaître l’IP source publique par laquelle la requête atteint le service. Pour les adresses dynamiques, Sophos vérifie régulièrement le nom DDNS, mais une modification peut tout de même provoquer une brève interruption. Avec Cloudflare, l’enregistrement DDNS doit être réglé sur DNS only et ne doit pas passer par le proxy.

Avec CGNAT ou une IP partagée par le fournisseur, l’adresse est attribuée au premier compte client qui l’a enregistrée. Un FQDN ne résout pas ce problème s’il pointe vers la même IP partagée ; une IP publique unique est nécessaire.

2. Copier les adresses IP DNS Protection

My Products > DNS Protection > Installers

Sous Installers, deux adresses IP DNS Protection figurent à côté de IP addresses. Utilisez Copy pour copier les deux valeurs depuis le tenant Fusion de l’entreprise, puis employez-les comme DNS 1 et DNS 2. Un résolveur tiers comme solution de repli supplémentaire peut contourner la protection et la visibilité.

Les adresses IP restent disponibles lorsque Secure DNS est activé. Pour le chemin du pare-feu, il est essentiel que Traditional DNS soit également configuré dans la Location avec l’adresse de sortie publique.

Sur la même page, Copy, à côté de URL, permet de copier l’adresse de test. Si son ouverture dans un navigateur affiche le message de bienvenue DNS Protection, le chemin du résolveur est correctement configuré. https://dns.access.sophos.com est particulièrement utile pour le dépannage ultérieur : si seul ce nom ne se résout pas ou si le navigateur affiche une erreur à la place du message de bienvenue, cela indique une fuite DNS ou une redirection par le fournisseur.

3. Configurer le pare-feu comme DNS Forwarder

Network > DNS

1. Sélectionner Static DNS.
2. Renseigner DNS 1 et DNS 2 avec les deux adresses Fusion.
3. Laisser DNS 3 vide, sauf exception délibérément documentée.
4. Sous IPv6, sélectionner également Static DNS et ne saisir aucun serveur DNS IPv6.
5. Activer Choose IPv4 DNS server over IPv6.
6. Sélectionner Apply.

Le service fonctionne via IPv4, mais peut également résoudre les enregistrements AAAA et donc les destinations IPv6. Avec SD-WAN, le failover ou Policy Routing, le chemin de sortie réel doit utiliser une adresse publique enregistrée dans la Location.

À partir de SFOS 21.5, le DNS Protection status widget du Control center affiche l’état de la connexion. Le Sophos Assistant est également disponible pour la configuration guidée et le dépannage. Le widget constitue un indicateur opérationnel rapide ; pour valider le chemin complet, l’accès réussi à l’adresse de test et les rapports DNS Protection sont plus probants.

4. Transmettre les domaines internes

Network > DNS
DNS request route > Add

DNS Protection ne résout pas les zones internes. Les DNS Request Routes sont donc nécessaires pour Active Directory, les applications internes et les recherches inversées.

Exemple :

• Host/domain name : firma.local ou corp.example.com
• Target servers : contrôleurs de domaine ou serveurs DNS internes, dans l’ordre d’interrogation voulu ; une route accepte au maximum huit adresses IP

corp.example.com est un domaine de documentation à remplacer par la zone réellement autoritative en interne. Ne pas router tout example.com si une seule sous-zone est interne. Si la recherche en cache d’une route correspondante échoue, le pare-feu n’interroge pas ensuite ses forwarders publics ni les serveurs racine. L’ordre et l’accessibilité des Target Servers font donc partie de la disponibilité.

La procédure complète est décrite dans Configurer DNS Request Routes sur Sophos Firewall. Les domaines enregistrés publiquement mais utilisés en interne doivent également être autorisés dans une Domain List si une catégorie telle que Parked Domains les bloque.

5. Diriger les clients vers le pare-feu via DHCP

Network > DHCP

1. Sous Server, modifier le serveur DHCP concerné et noter l’adresse de l’Interface sélectionnée.
2. Sous DNS server, désactiver Use device’s DNS settings.
3. Saisir l’adresse de l’interface DHCP interne du pare-feu comme Primary DNS.
4. Enregistrer, renouveler le bail du client de test et vérifier le résolveur réellement utilisé.

Dans son exemple, Sophos indique l’IP du pare-feu comme Primary DNS et une IP DNS Protection comme Secondary DNS. Les clients ne considèrent toutefois pas nécessairement la deuxième entrée comme un simple serveur de secours. Les requêtes directes vers DNS Protection contournent DNS Request Routes du pare-feu. Dans les réseaux avec Active Directory ou des zones internes, la redondance doit donc être assurée dans le chemin du résolveur et non par un deuxième serveur DNS client quelconque.

6. Empêcher le contournement direct du DNS

Vérifier d’abord sous Administration > Device access que DNS est activé pour chaque zone source concernée. Une règle DNAT facultative peut ensuite rediriger le trafic DNS classique vers le pare-feu :

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

• Rule name : par exemple redirect-client-dns-to-firewall
• Rule position : Top
• Original source : réseaux internes concernés
• Original destination : groupe d’hôtes sortant ou Internet IPv4
• Original service : DNS
• Translated destination : IP interne du pare-feu
• Translated source / Translated service : Original
• Inbound interfaces : uniquement les interfaces correspondant aux sources internes, jamais WAN

Internet IPv4 est large et ne convient que si toutes les destinations DNS externes classiques doivent être redirigées. Restreindre au maximum les réseaux sources et Inbound Interfaces. Les serveurs DNS internes et appareils particuliers nécessitent des exceptions documentées placées avant cette règle. Elle ne capture que le DNS sur UDP/TCP 53. DoH et DoT exigent des contrôles distincts via navigateur, MDM, endpoint ou Web Policy. Tester la résolution interne, le VPN et le réseau invité avant l’activation. Le fonctionnement de la règle est détaillé dans Comprendre NAT sur Sophos Firewall.

Politiques, endpoints et Block Pages

Filtering Policy et Domain Lists

Une Filtering Policy est affectée à une ou plusieurs Locations sous DNS Protection > Policies > Filtering policies. Une seule Filtering Policy peut être active par Location. Outre les catégories, il est possible de définir des listes de domaines et des options telles que Safe Search.

Cet article vérifie uniquement que le chemin du pare-feu atteint la bonne Location et donc la politique attendue. La création, les exceptions, Safe Search, le pilote et le retour arrière sont traités dans Configurer les Filtering Policies de Sophos DNS Protection.

Les Domain Lists doivent avoir un objectif, un responsable et une date de révision. Une Allow List prévaut sur les décisions normales de catégorie, mais pas sur la classification SophosLabs comme Threat ou Security Risk. Un domaine autorisé peut également rester bloqué si sa cible CNAME appartient à une catégorie bloquée.

Les décisions suivantes sont particulièrement importantes pour les catégories :

• Infrastructure : autoriser normalement Content delivery, CRL et OCSP, car les mises à jour et la validation des certificats peuvent en dépendre.
• Threats and liabilities : bloquer en général les catégories telles que Phishing, Malware, Newly Registered Websites ou Anonymizers et résoudre précisément les faux positifs.
• Data loss : évaluer le stockage cloud et la messagerie Web selon les exigences DLP et de conformité.
• Uncategorized : ne pas bloquer sans analyse ; des services légitimes nouveaux ou internes peuvent être temporairement non catégorisés.
• Productivité, réseaux sociaux et bande passante : décider selon le réseau et les besoins métier, et non comme règle de sécurité globale.

Endpoint DNS Protection

La politique Endpoint DNS Protection est destinée aux endpoints Windows administrés qui doivent également être protégés en dehors du réseau de l’entreprise. Sophos Endpoint intercepte les requêtes DNS et les envoie via HTTPS à la Secure DNS Location. La Filtering Policy associée détermine le filtrage effectif.

Le guide Endpoint DNS Protection couvre la configuration, les Domain Exclusions internes et l’affectation. Le NAT, les Request Routes et DHCP du pare-feu ne remplacent pas ce chemin Endpoint.

La politique ne prend actuellement en charge ni Windows Server ni macOS. Pour macOS, il existe un chemin de profil Secure DNS manuel distinct ; Linux, les appareils mobiles et les équipements spéciaux nécessitent également leur propre solution réseau, VPN ou MDM. Vérifier les exigences actuelles du package Endpoint dans Sophos Fusion avant le déploiement, car elles peuvent évoluer rapidement.

Les zones internes sont explicitement configurées comme Domain Exclusions dans la Endpoint Policy. Cette méthode est plus fiable qu’une nouvelle tentative NXDOMAIN et évite les requêtes externes inutiles. Le DNS Protection Root Certificate peut être distribué automatiquement aux endpoints compatibles.

Root Certificate et Block Page

Pour les Block Pages HTTPS, les clients doivent faire confiance au DNS Protection Root Certificate. Il ne s’agit pas du même certificat que la CA du pare-feu pour TLS Inspection ; sa distribution est décrite dans Distribuer le certificat CA Sophos Firewall pour TLS Inspection.

Pour vérifier, déployer, effectuer la rotation et supprimer le certificat, consultez Déployer le certificat racine Sophos DNS Protection.

Le certificat et le test de configuration sont disponibles sous DNS Protection > Installers. En outre, blockpage.dnsprotection.sophos.com doit être accessible.

En Web Proxy Mode, Pharming Protection peut perturber la Block Page. Avant de désactiver globalement les fonctions de protection, autoriser le domaine de la Block Page via une règle de pare-feu HTTP/HTTPS spécifique sans Web Filtering et le définir sur Do not decrypt dans une règle TLS.

Pilote, déploiement et validation

Activer d’abord DNS Protection dans un petit réseau pilote. Documenter les zones internes, les recherches inversées et les services critiques, configurer DNS Request Routes et préparer un retour clair vers les résolveurs précédents. Les réseaux de serveurs nécessitent une fenêtre de test distincte, car la validation des licences, les mises à jour, CRL/OCSP, les sauvegardes ou la communication de cluster peuvent dépendre du DNS.

Les contrôles suivants doivent réussir avant un déploiement étendu. Les commandes client n’ont pas été exécutées ici sur un environnement SFOS 22 ; ce sont des commandes de diagnostic en lecture seule. Le test de configuration et les rapports Fusion constituent la preuve produit :

• un domaine public est résolu via le résolveur prévu.
• un domaine AD interne et une recherche inversée fonctionnent via DNS Request Routes.
• le test de configuration sous Installers affiche la confirmation attendue.
• un domaine inoffensif volontairement bloqué par une politique de test est bloqué et attribué à la bonne Location.
• sous DNS Protection > Logs & Reports, DNS usage by source affiche la Location après le délai prévu et, pour les données Endpoint, l’utilisateur et l’appareil.
• le réseau invité utilise le chemin DNS prévu, mais aucun serveur DNS interne.
• le client VPN reçoit les résolveurs et suffixes DNS appropriés.
• Browser DoH, Private Relay ou des profils locaux ne contournent pas le contrôle de manière inattendue.
• le retour au résolveur précédent a été testé ou clairement documenté.

Commandes de test pour les clients

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 avec systemd-resolved et dig installé :

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

Remplacer <firewall-ip> par l’adresse de l’interface interne de Sophos Firewall. Si la requête explicite vers le pare-feu fonctionne mais pas la requête normale, la cause se trouve généralement dans DHCP, le VPN, Browser DoH ou une configuration DNS locale. Les commandes montrent le résolveur client utilisé et sa réponse, mais ne prouvent pas à elles seules quel upstream le pare-feu utilise.

Tester une zone interne :

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

Cette requête doit atteindre le serveur DNS interne via la DNS Request Route appropriée.

Dépannage

La Location n’apparaît pas dans Sophos Fusion

Vérifier l’IP WAN publique, le FQDN DDNS et la sortie Multi-WAN réelle. Une IP source non configurée peut être rejetée par le service DNS Protection. Pour les adresses dynamiques, vérifier que le FQDN se résout publiquement vers l’IP actuelle ; les enregistrements Cloudflare doivent être définis sur DNS only.

Les FQDN non valides et les conflits d’IP apparaissent sous My Environment > Alerts. Avec CGNAT ou une sortie proxy/VPN partagée, la première Location enregistrée l’emporte. Un autre FQDN pointant vers la même IP ne modifie pas cette attribution.

Le trafic DNS manque malgré une Location correcte

Ce symptôme inclut également No queries received from locations dans le tableau de bord et DNS Protection: Connectivity Error dans le Control center. Ouvrez d’abord https://dns.access.sophos.com. Si le message de bienvenue ne s’affiche pas, testez en UDP et TCP 53 les deux adresses du tenant affichées sous Installers, puis vérifiez la sortie WAN réelle.

Si les requêtes atteignent une autre destination ou qu’un autre résolveur répond, le routeur ou le fournisseur peut rediriger le DNS. Un test Standard ou Extended sur https://www.dnsleaktest.com/ permet de préciser le diagnostic : avec DNS Protection, les valeurs de la colonne Hostname contiennent le motif gw-<Nummer><Region>.dnsprotection.sophos.com ; le FAI indiqué est Amazon ou une appellation correspondante. Si le test affiche uniquement d’autres résolveurs, demandez au fournisseur de vérifier une éventuelle redirection DNS. Si des résolveurs Sophos et tiers sont mélangés, contrôlez les paramètres DNS du pare-feu, du serveur DNS interne et des clients, ainsi que les résolveurs IPv6 parallèles. https://ipleak.net/ peut servir de contre-vérification.

Conservez uniquement les deux adresses du tenant comme forwarders, contrôlez routage, NAT et capture de paquets, puis faites corriger la redirection par le fournisseur. Un troisième résolveur public ne serait qu’un contournement non protégé.

Certains clients utilisent un autre résolveur

Vérifiez ensemble DHCPv4, DHCPv6, les Router Advertisements, le profil VPN et les valeurs statiques des clients. Un serveur DNS IPv6 supplémentaire peut contourner DNS Protection. DNS Protection fonctionne en IPv4 mais résout les enregistrements AAAA ; les destinations IPv6 ne nécessitent donc pas de résolveur IPv6 distinct.

Les noms internes ne fonctionnent plus

Vérifier DNS Request Routes, les serveurs DNS internes, les zones inverses, les domaines de recherche et les suffixes clients. Vérifier également que le client utilise le pare-feu ou le résolveur interne prévu et n’interroge pas directement une IP DNS Protection.

Un domaine interne ou légitime est bloqué

Vérifier la catégorisation, la Domain List et la cible CNAME. Une exception précise est préférable à l’ouverture d’une catégorie entière. Les classifications Threat et Security Risk de SophosLabs ne peuvent pas être remplacées par une Allow Domain List.

Les journaux restent vides

Le tableau de bord et les rapports accusent un retard d’environ 15 à 25 minutes. Un nouveau nom de Location ou de politique peut prendre de 30 minutes à quatre heures pour apparaître. Ce n’est qu’après ces délais qu’il faut vérifier DHCP, le DNS client, le DNS du pare-feu, la redirection NAT, les résolveurs alternatifs, les profils VPN et l’attribution de la Location.

Sous DNS Protection > Logs & Reports, commencez par DNS usage by source et filtrez par Location, Domain, Status ou Source IP. Pour le DNS directement transféré, une règle de pare-feu avec Log firewall traffic peut en outre indiquer si UDP/TCP 53 a traversé le pare-feu. Pour le résolveur du pare-feu, Administration > Device access fait foi ; une règle de pare-feu ne prouve pas que ce service local a été autorisé ou refusé.

Les opérateurs de filtre, limites d’export, délais et Live Discover sont documentés dans Analyser les rapports DNS Protection et Live Discover. Pour le dépannage du pare-feu, prouvez d’abord le chemin du résolveur avant de lancer des requêtes de rapport plus poussées.

Avec EDR, XDR ou MDR, Threat Analysis Center > Live Discover peut également analyser des données DNS Protection telles que le domaine, Policy Action, la Location et l’IP source. Les champs utilisateur et appareil sont disponibles pour les données Endpoint dans les rapports standard, mais pas dans le schéma DNS de pare-feu documenté pour Live Discover.

La Block Page ne s’affiche pas

Vérifier le DNS Protection Root Certificate, le chemin DNS et l’accessibilité de blockpage.dnsprotection.sophos.com. En Web Proxy Mode, contrôler également Pharming Protection, la règle HTTP/HTTPS et l’exception TLS Do not decrypt. VPN, Browser DoH et Apple Private Relay peuvent aussi faire passer le test à côté de DNS Protection.

Pour une exception de pare-feu étroite, créez un objet FQDN pour blockpage.dnsprotection.sophos.com. Une règle Allow autorise HTTP/HTTPS depuis les zones et réseaux internes concernés vers la zone WAN, avec cet objet comme destination et sans filtrage Web. Une règle TLS correspondante reprend les mêmes critères avec Do not decrypt. Ne désactivez pas globalement Pharming Protection ou TLS Inspection.

DoH ou Private DNS contourne le contrôle

Une redirection NAT pour le port 53 ne capture ni DoH ni DoT. Les politiques de navigateur, de système d’exploitation et MDM doivent contrôler ces résolveurs. Secure DNS dans DNS Protection utilise DoH ; aucun mode DNS Protection spécifique via DoT n’est documenté.

Sur les appareils Apple, iCloud Private Relay peut également contourner le chemin DNS prévu. Par exemple, si les iPhone n’ont pas accès à Internet alors que d’autres appareils du même site fonctionnent, désactivez d’abord Limit IP Address Tracking pour le chemin de test concerné, puis recommencez le test. N’appliquez un changement à toute l’organisation qu’après ce test limité et après concertation sur les exigences de confidentialité.

Les clients VPN se comportent différemment des clients LAN

Vérifier les serveurs DNS attribués, les suffixes DNS, Split DNS, Full ou Split Tunnel et les résolveurs locaux. DNS Protection peut fonctionner au bureau tout en étant contourné pour Remote Access. Les options VPN de base sont expliquées dans Sophos Connect ou SSL VPN : quelle solution Remote Access choisir ?.

Exploitation

DNS Protection n’est pas un simple remplacement ponctuel du serveur DNS. Vérifier régulièrement :

• les Locations, les adresses de sortie publiques et la résolution DDNS.
• les paramètres DHCP et les DNS Request Routes internes.
• les politiques, les Domain Lists, les responsables et les dates de révision.
• les principaux domaines bloqués et les faux positifs documentés.
• les nouveaux sites, réseaux invités, chemins VPN et plateformes Endpoint.
• la distribution du certificat et l’accessibilité du domaine de la Block Page.
• les rapports après les modifications et le chemin de retour défini.

Si ces tâches ne peuvent pas être assurées durablement, des résolveurs robustes et des contrôles de sécurité ciblés sont souvent préférables. DNS Protection est pertinent lorsque les politiques, le reporting et la protection Endpoint sont réellement utilisés et surveillés.

Revenir en arrière en toute sécurité

Pour le chemin du site, désactiver d’abord la redirection DNS afin de ne plus forcer les clients vers le pare-feu pendant le retour. Restaurer ensuite les anciens résolveurs sous Network > DHCP, renouveler le bail du client de test et vérifier les noms publics et internes. Une fois ce chemin validé, restaurer le mode ou les serveurs précédents sous Network > DNS. Conserver d’abord les Request Routes : elles ne gênent pas le retour et facilitent une reprise contrôlée. Ne supprimer la Location Fusion que lorsqu’aucun réseau ou aucune politique nécessaire ne lui est encore attribué.

Revenir séparément sur Endpoint DNS Protection : sous DNS Protection > Policies > Endpoint policies, retirer l’attribution concernée ou désactiver Use Sophos DNS Protection, puis vérifier sur le poste pilote que les résolveurs du système ou des applications sont de nouveau utilisés. Il n’est pas nécessaire de supprimer le Root Certificate dans la même fenêtre ; le retirer ultérieurement par le même canal administré que celui utilisé pour son installation.