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

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 Central 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 Central.
• 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 Central connaît le site en tant que Location.
2. Sophos Central 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 Central 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é.

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 en mode autonome. Endpoint DNS Protection nécessite Workspace Protection ainsi qu’une licence Sophos Endpoint appropriée.

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 Central

My Products > DNS Protection > Locations

1. Sélectionner Add et saisir un nom de site unique.
2. Activer Traditional DNS over IPv4.
3. Saisir l’IP WAN publique ou un FQDN DDNS stable.
4. En cas de Multi-WAN, inclure toutes les adresses de sortie réellement utilisées.
5. Enregistrer la Location.

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

Deux adresses IP DNS Protection sont indiquées sous Installers. Toujours copier ces valeurs depuis le tenant Central de l’entreprise et les utiliser 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.

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 Central.
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. Enregistrer la configuration.

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.

4. Transmettre les domaines internes

Network > DNS
DNS request route section > Add

DNS Protection ne résout pas les zones internes. DNS Request Routes est donc nécessaire 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

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. Modifier le serveur DHCP du réseau concerné.
2. Distribuer l’IP de l’interface interne du pare-feu comme serveur DNS.
3. Renouveler le bail sur un client de test.
4. Vérifier le résolveur réellement utilisé par le client.

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

Une règle DNAT facultative peut rediriger vers le pare-feu le trafic DNS classique des clients internes :

• 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
• Inbound interfaces : uniquement les interfaces correspondant aux sources internes, jamais WAN
• Position : très haut, avant les règles NAT plus générales

Les exceptions pour les serveurs DNS internes et les appareils particuliers doivent être documentées. La règle ne capture que le DNS sur UDP/TCP 53. DoH et DoT nécessitent des contrôles distincts via navigateur, MDM, endpoint ou Web Policy. Tester la résolution des noms internes, le VPN, le réseau invité et les journaux 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 attribué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 Domain Lists et des options telles que Safe Search.

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 Endpoint DNS Protection Policy est destinée aux endpoints Windows gérés qui doivent également être protégés hors du réseau de l’entreprise. Sophos Endpoint intercepte les requêtes DNS et les envoie en HTTPS à la Secure DNS Location. La Filtering Policy associée détermine le filtrage effectif.

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

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 tests suivants doivent réussir avant un déploiement étendu :

• 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.
• les journaux apparaissent dans Sophos Central après le délai de reporting attendu.
• 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 Central

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 des sorties proxy/VPN partagées, la première Location enregistrée prévaut. Un autre FQDN pointant vers la même IP ne modifie pas cette attribution.

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 sur le temps réel. Ce n’est qu’après ce délai 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.

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, vérifier également Pharming Protection, la règle HTTP/HTTPS et l’exception TLS Do not decrypt. Un VPN, Browser DoH et Apple Private Relay peuvent également contourner DNS Protection pendant le test.

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

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.