Configurer Sophos DNS Protection avec Sophos Firewall
Sophos DNS Protection protège les requêtes DNS via un service DNS basé sur le cloud avec des politiques et des rapports dans Sophos Central. Cette fonctionnalité peut bloquer les domaines malveillants, le phishing, les cibles de commande et de contrôle, et les catégories indésirables avant qu’un client n’établisse une connexion avec le site Web ou l’infrastructure réelle.
Avec Sophos Firewall, la configuration standard la plus propre est généralement : les clients utilisent le pare-feu comme résolveur DNS, le pare-feu redirige les requêtes DNS publiques vers DNS Protection, et les domaines internes sont envoyés aux serveurs DNS internes via des routes de requêtes DNS. Cela maintient la résolution de noms interne stable, tandis que les requêtes DNS publiques sont contrôlées et enregistrées de manière centralisée.
DNS Protection ne remplace pas la Web Protection, les Threat Feeds ou le NDR. C’est un point de protection distinct au niveau DNS. C’est pourquoi il est important de planifier cette fonctionnalité consciemment et de ne pas simplement remplacer les serveurs DNS publics.
Guide vidéo
Classification Avanet : Utiliser DNS Protection consciemment
DNS Protection est techniquement intéressant, mais ce n’est pas automatiquement le meilleur choix dans tous les environnements. Dans de nombreux projets, nous choisissons de ne pas utiliser DNS Protection par défaut, préférant des résolveurs DNS rapides et hautement disponibles et bloquant les cibles malveillantes connues via les Sophos Firewall Threat Feeds ou des sources de renseignement sur les menaces comparables sur le pare-feu.
La raison est simple : le DNS est une fonction de base. Si le DNS est lent, ne fonctionne pas de manière redondante ou génère trop de faux positifs, les utilisateurs peuvent rapidement avoir l’impression que tout le réseau est défectueux. La protection DNS doit donc être non seulement sécurisée, mais aussi stable, rapide, compréhensible et facile à gérer.
La décision dépend de l’objectif :
| Approche | Force | Limite |
|---|---|---|
| Résolveurs DNS rapides et hautement disponibles | Très bonne performance, résolution de noms robuste, peu de risques opérationnels | Pas de politique DNS centrale et pas de rapport DNS dans Sophos Central |
| Threat Feeds sur le Sophos Firewall | Les cibles malveillantes connues peuvent être bloquées au périmètre sans modifier le chemin DNS | Pas la même chose que le filtrage par catégorie DNS ; la qualité, le réglage et le processus de faux positifs sont importants |
| Sophos DNS Protection | Politiques DNS, catégories, emplacements, journaux et protection DNS des endpoints dans Sophos Central | Dépendance supplémentaire dans le chemin DNS ; le déploiement, les certificats, les exceptions et la surveillance doivent être soigneusement planifiés |
DNS Protection est donc particulièrement adapté lorsque les journaux DNS dans Sophos Central, les politiques DNS basées sur l’emplacement, le filtrage par catégorie ou la protection DNS des endpoints pour les clients itinérants sont explicitement souhaités. Si l’objectif est principalement une résolution de noms rapide et hautement disponible avec un blocage supplémentaire des cibles malveillantes connues, de bons résolveurs DNS plus des Threat Feeds sont souvent la solution la plus pragmatique.
Quand DNS Protection est-il pertinent ?
DNS Protection est particulièrement puissant lorsque de nombreux clients accèdent à Internet via un pare-feu central ou un résolveur DNS local.
Cas d’utilisation typiques :
- Les clients ne doivent pas utiliser de résolveurs DNS publics arbitraires.
- Les domaines de logiciels malveillants, de phishing et de commande et de contrôle doivent être bloqués tôt.
- Les requêtes DNS doivent être visibles dans Sophos Central.
- Différents emplacements doivent avoir leurs propres politiques DNS.
- Les noms DNS internes doivent continuer à fonctionner via des serveurs DNS locaux.
- La Web Protection doit être complétée par un contrôle DNS en amont.
Cependant, DNS Protection n’est pas un substitut à l’inspection de contenu. Si un domaine autorisé délivre plus tard un contenu malveillant ou si le trafic HTTPS doit être examiné de plus près, la Web Protection, l’inspection TLS, l’IPS, la protection des endpoints et la journalisation restent pertinentes.
DNS Protection n’est pas idéal si l’on recherche simplement un DNS-Forwarder externe rapide ou si l’on dispose déjà d’une opération DNS très stable avec des Threat Feeds séparés, une Web Protection, une protection des endpoints et une surveillance propre. Dans ce cas, il convient d’abord d’évaluer la valeur ajoutée concrète de DNS Protection et qui gère la politique, les exceptions et les faux positifs.
Architecture avec Sophos Firewall
Pour Sophos Firewall, cette configuration est généralement la plus claire :
- Sophos Central reconnaît l’emplacement comme une Location.
- Sophos Central fournit deux adresses IP de DNS Protection.
- Sophos Firewall utilise ces adresses IP comme DNS-Forwarder.
- Les domaines internes sont envoyés aux serveurs DNS internes via des routes de requêtes DNS.
- Le DHCP distribue le pare-feu comme résolveur DNS aux clients.
- Une règle NAT facultative redirige le trafic DNS sortant vers le pare-feu.
- Les journaux et rapports de DNS Protection sont analysés dans Sophos Central.
Cette configuration garantit que les clients n’ont pas besoin d’être configurés directement sur le service DNS de Sophos. Le pare-feu reste le résolveur central dans le LAN et peut mieux gérer les cas particuliers internes.
Prérequis
Avant le déploiement, ces points doivent être clarifiés :
- Accès à Sophos Central avec autorisation pour DNS Protection.
- Licence appropriée : Xstream Protection pour la protection DNS autonome ou Workspace Protection pour la protection DNS des endpoints.
- IP WAN publique ou un nom FQDN/DDNS stable pour l’emplacement.
- Sophos Firewall est utilisé comme résolveur DNS pour les réseaux concernés ou doit l’être.
- Les domaines internes, les zones Active Directory et les recherches inverses sont connus.
- Les serveurs DHCP pour les réseaux clients sont identifiés.
- Les exceptions pour les domaines internes et les services critiques sont planifiées.
- Les responsables de la politique DNS, des faux positifs et de la journalisation sont définis.
Si l’adresse IP publique change fréquemment, il convient de vérifier avant le déploiement si une configuration DDNS est suffisamment stable. Sophos DNS Protection peut également identifier les emplacements via un FQDN, mais un changement d’IP peut néanmoins entraîner des interruptions temporaires.
1. Créer une location dans Sophos Central
Dans Sophos Central, l’emplacement est d’abord créé :
My Products > DNS Protection > Locations
Procédure pratique :
- Sélectionnez
Add. - Saisissez le nom et la description de l’emplacement.
- Enregistrez l’IP WAN publique du Sophos Firewall.
- Pour plusieurs interfaces WAN, entrez toutes les adresses IP publiques pertinentes ou une plage appropriée.
- Pour une IP dynamique, utilisez un FQDN DDNS si le design s’y base.
- Enregistrez l’emplacement.
L’emplacement est important car DNS Protection doit associer les requêtes DNS entrantes au bon compte client et à la bonne politique. Si l’emplacement manque ou si l’IP publique ne correspond pas, Sophos Central ne voit pas correctement l’emplacement.
2. Copier les adresses IP de DNS Protection
Les adresses IP de DNS Protection se trouvent dans Sophos Central sous :
My Products > DNS Protection > Installers
Deux adresses IP y sont fournies. Elles sont utilisées sur le Sophos Firewall comme serveur DNS principal et secondaire. N’entrez pas d’autres serveurs DNS publics comme secours si le trafic doit passer entièrement par DNS Protection. Sinon, les serveurs DNS peuvent être utilisés en contournant DNS Protection selon le comportement du résolveur, et la protection ainsi que la visibilité sont perdues.
3. Configurer le DNS-Forwarder sur Sophos Firewall
Sur le Sophos Firewall :
Network > DNS
Procédure recommandée :
- Sélectionnez
Static DNS. - Réglez
DNS 1sur la première adresse IP de DNS Protection. - Réglez
DNS 2sur la deuxième adresse IP de DNS Protection. - Laissez
DNS 3vide, sauf en cas de cas particulier conscient. - Ne définissez pas de serveurs DNS IPv6 séparés sous IPv6 si l’emplacement doit fonctionner via les serveurs DNS-Protection basés sur IPv4.
- Enregistrez et appliquez les paramètres.
DNS Protection fonctionne comme un service DNS basé sur IPv4, mais peut également résoudre des adresses IPv6. Il n’est donc pas nécessaire d’avoir automatiquement un serveur DNS IPv6 séparé.
4. Protéger les domaines internes avec des routes de requêtes DNS
DNS Protection ne résout pas les domaines internes. Si le réseau utilise Active Directory, des applications internes, des zones locales ou des recherches inverses, ces requêtes doivent être envoyées aux serveurs DNS internes.
Pour cela, utilisez sur le Sophos Firewall :
Network > DNS > DNS request route
Exemple :
| Champ | Exemple |
|---|---|
| Nom d’hôte/domaine | entreprise.local ou corp.example.com |
| Serveurs cibles | contrôleurs de domaine internes ou serveurs DNS |
Sans ces routes, les noms internes seraient envoyés à DNS Protection et ne seraient pas résolus correctement. La procédure exacte est décrite dans Configurer des routes de requêtes DNS sur Sophos Firewall.
Pour les environnements de production, il est conseillé de prendre en compte les domaines internes dans DNS Protection en tant que liste de domaines si le domaine risque d’être bloqué par une catégorie. Des exemples typiques sont les sites ou services internes qui pourraient autrement tomber sous des catégories problématiques comme les domaines parqués.
5. Faire pointer les clients vers le pare-feu via DHCP
Les clients doivent utiliser le Sophos Firewall comme résolveur DNS, et non directement des résolveurs externes arbitraires.
Si le Sophos Firewall fournit le DHCP :
Network > DHCP
Procédure pratique :
- Modifiez le serveur DHCP de l’interface concernée.
- Distribuez l’adresse IP de l’interface du pare-feu comme serveur DNS principal.
- Ne distribuez pas de serveurs DNS externes comme DNS client alternatif si DNS Protection doit s’appliquer de manière cohérente.
- Renouvelez le bail DHCP ou reconnectez le client de test.
- Vérifiez avec un client de test quel serveur DNS est réellement utilisé.
Si un serveur DNS Windows ou un autre résolveur interne est utilisé, ce résolveur peut rediriger vers DNS Protection au lieu des clients. Il doit alors être clair où les domaines internes sont résolus et quel serveur redirige les requêtes publiques.
6. Empêcher le contournement direct du DNS
De nombreux clients utilisent le serveur DNS distribué par DHCP. Certains appareils, navigateurs, systèmes IoT ou clients configurés intentionnellement peuvent cependant utiliser leurs propres serveurs DNS.
Une contre-mesure possible est une règle NAT qui redirige le trafic DNS sortant des réseaux internes vers le pare-feu. Cela signifie pratiquement que le trafic DNS des réseaux sources internes est dirigé par DNAT vers l’adresse interne du pare-feu, afin que la requête puisse être évaluée par DNS Protection.
Important :
- Ciblez uniquement les réseaux sources internes.
- N’utilisez pas d’interfaces WAN comme interface d’entrée.
- Placez la règle très haut dans l’ordre.
- Documentez les exceptions pour les serveurs DNS internes et les cas particuliers.
- Testez ensuite si la résolution DNS interne, DNS Protection et les journaux sont toujours corrects.
Les bases du NAT sont expliquées dans Comprendre le NAT sur Sophos Firewall. Une imposition DNS ne doit pas être activée à l’aveugle, car elle peut affecter les résolveurs internes, les clients VPN, le comportement DoH/DoT ou les appareils spéciaux.
Planifier le déploiement par phases
DNS Protection ne doit pas être imposé immédiatement à tous les réseaux en même temps. Le DNS est une fonction de base : si les noms internes, les vérifications de certificats, les mises à jour logicielles ou les services SaaS ne sont plus résolus correctement, cela peut rapidement ressembler à une panne générale d’Internet.
Un déploiement contrôlé ressemble en pratique à ceci :
- Sélectionnez un réseau pilote ou un petit groupe de test.
- Documentez les domaines internes, les zones inverses et les domaines de recherche.
- Configurez les routes de requêtes DNS pour les zones internes.
- Distribuez le pare-feu comme résolveur DNS via DHCP.
- Configurez les adresses IP de DNS Protection sur le pare-feu.
- Installez le certificat de page de blocage sur les clients de test.
- Vérifiez les journaux dans Sophos Central.
- Ce n’est qu’après cela que d’autres réseaux, réseaux invités, réseaux de serveurs ou réseaux VPN doivent être ajoutés.
Pour les réseaux de serveurs, il faut être particulièrement prudent. Certains systèmes utilisent le DNS pour la vérification des licences, les mises à jour, CRL/OCSP, la sauvegarde, la surveillance ou la communication de cluster. Dans ces cas, une fenêtre de test avec retour en arrière est plus importante que pour les réseaux clients normaux.
Test d’acceptation avant le déploiement général
Avant le déploiement en production, il doit être clair comment reconnaître une mise en œuvre réussie de DNS Protection. Le lien de test Sophos ne suffit pas à lui seul.
| Test | Résultat attendu |
|---|---|
| Résolution d’un domaine public | Le client interroge le pare-feu ou le résolveur interne prévu |
| Résolution d’un domaine AD interne | La requête passe par la route de requête DNS vers les serveurs DNS internes |
| Test de recherche inverse | Les zones PTR internes fonctionnent toujours |
| Ouvrir un domaine de test bloqué | DNS Protection bloque et enregistre le coup |
| Vérifier les journaux dans Sophos Central | Les coups apparaissent au bon emplacement |
| Tester le réseau invité | Les invités utilisent le chemin DNS prévu et pas de serveurs DNS internes |
| Tester le client VPN | Split-DNS, domaines internes et domaines publics se comportent comme prévu |
| Vérifier le DoH du navigateur | Le navigateur ou le système d’exploitation ne contourne pas le contrôle de manière inattendue |
Si l’un de ces tests échoue, il ne faut pas immédiatement ouvrir la politique. Il faut d’abord clarifier si le problème vient de DHCP, des routes de requêtes DNS, de l’attribution d’emplacement, du profil client, du DoH du navigateur, du tunnel VPN ou de la catégorisation des domaines.
7. Planifier les politiques et les listes de domaines
DNS Protection peut bloquer des domaines pertinents pour la sécurité même sans politique propre si SophosLabs les classe comme menace ou risque de sécurité. Les politiques propres complètent cette base avec des directives d’entreprise.
Questions typiques de politique :
- Quels emplacements reçoivent quelle politique ?
- Quelles catégories doivent être bloquées ?
- Quelles catégories ne posent problème que pour certains emplacements ?
- Quels domaines doivent être explicitement autorisés ?
- Qui décide des faux positifs ?
- Combien de temps les exceptions restent-elles valides ?
Les listes de domaines doivent être gérées de manière stricte. Une liste d’autorisation large peut réduire l’efficacité de la protection. Une liste de blocage large peut perturber les processus métier. Chaque liste doit avoir un objectif, un propriétaire et une date de révision.
Filtering Policy ou Endpoint DNS Protection Policy ?
Dans Sophos Central, il existe deux niveaux de politique à ne pas confondre.
| Type de politique | Pour quoi conçu | Quand utiliser |
|---|---|---|
| Filtering policy | Filtrage DNS basé sur l’emplacement, le pare-feu ou le réseau | Pour les bureaux, les pare-feu, les serveurs DNS, les réseaux de serveurs, les invités, les IoT et les appareils sans Sophos Endpoint |
| Endpoint DNS Protection policy | Protection DNS basée sur l’endpoint via Sophos Endpoint | Pour les clients gérés, les ordinateurs portables et les utilisateurs qui doivent être protégés même en dehors du réseau de l’entreprise |
Une Filtering policy est créée sous DNS Protection > Policies > Filtering policies et assignée à un ou plusieurs emplacements ou pare-feu. Une seule Filtering Policy peut être active par emplacement. Dans cette politique, vous définissez les catégories, les listes de domaines et des options supplémentaires comme Safe Search.
Une Endpoint DNS Protection policy utilise Sophos Endpoint. L’endpoint intercepte le trafic DNS sur l’appareil et le redirige en toute sécurité via HTTPS vers DNS Protection. Cela signifie que vous n’avez pas besoin de configurer manuellement le client sur les adresses IP de DNS Protection. Les appareils sont assignés à une location DNS Protection dans la politique Endpoint et sont ensuite contrôlés par la Filtering Policy correspondant à cette location.
Pratiquement, cela signifie :
- Pour un bureau avec Sophos Firewall, la Location plus Filtering policy est le chemin réseau normal.
- Pour les clients itinérants, la Endpoint DNS Protection policy est utile car la protection peut s’appliquer même en dehors du réseau de l’entreprise.
- Pour les environnements mixtes, on combine les deux approches : les emplacements de pare-feu via les locations, les endpoints gérés en plus via Endpoint DNS Protection.
- Pour les domaines internes, les politiques Endpoint devraient inclure des exclusions de domaine. Sophos recommande d’exclure explicitement les zones internes plutôt que de se fier uniquement à une nouvelle tentative NXDOMAIN.
- Les pages de blocage sur les endpoints nécessitent le certificat racine DNS Protection. Avec Sophos Endpoint, le certificat peut être distribué automatiquement.
Quelles catégories peut-on bloquer ?
DNS Protection propose des catégories organisées en groupes dans Sophos Central. Certaines catégories sont plutôt liées à la productivité, d’autres sont clairement pertinentes pour la sécurité. Les noms restent intentionnellement en anglais car ils sont ainsi affichés dans Sophos Central.
| Groupe de catégories | Catégories typiques | Recommandation |
|---|---|---|
| Catégories liées à la productivité | 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, Vehicles | Selon la politique de l’entreprise, autoriser, bloquer ou restreindre uniquement pour certains réseaux. |
| Réseaux sociaux | Blogs & forums, Personals & dating, Social networks | Souvent pas une question de sécurité pure. Décider consciemment pour les réseaux productifs, plutôt que de bloquer de manière générale. |
| Catégories adultes et potentiellement inappropriées | 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, Weapons | Dans de nombreux environnements d’entreprise, bloquer. Exceptions uniquement avec une justification claire. |
| Catégories susceptibles de causer une utilisation excessive de la bande passante | Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting, Voice & video calls | Souvent pertinent pour les réseaux invités et clients. Vérifier les outils de collaboration au préalable pour que les appels légitimes ne soient pas perturbés. |
| Catégories de sites pertinents pour les affaires | General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Image search, Information technology, Job search, Military, NGOs & non-profits, Political organizations, Professional & workers organizations, Real estate, Reference, Search engines, Software updates, Translators | Généralement autoriser. Certaines catégories peuvent être restreintes dans les réseaux à haute sécurité. |
| Infrastructure | Content delivery, CRL and OCSP | Normalement autoriser. Ces catégories peuvent être importantes pour les mises à jour, la vérification des certificats et de nombreux services cloud. |
| Menaces et responsabilités | Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware, Unauthorized software stores | En règle générale, bloquer. En cas de faux positifs, travailler avec des listes de domaines ciblées, ne pas ouvrir des groupes entiers. |
| Perte de données | Business cloud apps, Personal cloud apps, Personal network storage, Web E-mail | Fortement dépendant des exigences DLP, cloud et de conformité. Traiter souvent plus strictement pour les réseaux de serveurs et d’administration que pour les utilisateurs normaux. |
| Non catégorisé | Uncategorized | Ne pas bloquer aveuglément. Évaluer d’abord, car des services légitimes nouveaux ou internes peuvent être temporairement non catégorisés. |
Les listes de domaines ont priorité sur les catégories. Un domaine autorisé dans une liste de domaines reste autorisé, même si la catégorie serait bloquée. Un domaine bloqué reste bloqué, même si la catégorie serait autorisée. C’est pourquoi les listes de domaines doivent être documentées et régulièrement vérifiées.
8. Pages de blocage et certificats
Pour les domaines bloqués, DNS Protection peut afficher une page de blocage HTTPS. Pour que les utilisateurs voient correctement cette page de blocage, le certificat racine DNS Protection doit être installé de manière fiable sur les appareils concernés.
Si l’inspection TLS ou le filtrage Web est également actif sur le pare-feu, la planification des certificats et des exceptions doit correspondre. Pour le certificat CA du pare-feu, voir Distribuer le certificat CA de Sophos Firewall pour l’inspection TLS.
Si les pages de blocage ne s’affichent pas, il ne faut pas immédiatement modifier la politique. Souvent, les certificats manquent, le client utilise un autre chemin DNS, ou blockpage.dnsprotection.sophos.com est perturbé par un autre contrôle.
Tester DNS Protection
Sophos Central fournit un lien de test sous DNS Protection > Installers. Si la configuration est correcte, le navigateur affiche une confirmation.
En outre, il convient de tester de manière pratique :
- Le client utilise le pare-feu comme serveur DNS.
- Un domaine public est résolu via DNS Protection.
- Un domaine interne est résolu correctement via la route de requête DNS.
- Un domaine de test bloqué est bloqué.
- Les journaux apparaissent dans Sophos Central.
- Les requêtes DNS apparaissent au bon emplacement.
- Les serveurs DNS alternatifs ne sont pas utilisés.
- Le réseau VPN ou invité se comporte comme prévu.
Pour une véritable analyse des erreurs, il ne faut pas seulement tester le navigateur. nslookup, dig, les journaux du pare-feu, les baux DHCP et les journaux de Sophos Central ensemble donnent une meilleure image.
Commandes de test pour les clients
Sur un client de test, il faut d’abord vérifier quel serveur DNS est réellement utilisé. Un test de navigateur réussi ne suffit pas si le client utilise parallèlement un autre résolveur, DoH ou un profil 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
Il convient de remplacer <firewall-ip> par l’adresse de l’interface interne du Sophos Firewall qui doit servir de résolveur DNS dans le réseau concerné. Si la requête contre le pare-feu fonctionne, mais que la requête normale utilise un autre résolveur, le problème se situe généralement au niveau de DHCP, du profil du système d’exploitation, du client VPN, du DoH du navigateur ou d’une configuration DNS locale.
Pour les domaines internes, un test avec une zone interne doit également être effectué :
dig @<firewall-ip> interner-host.corp.example.com
Ce test doit atterrir sur le serveur DNS interne via la route de requête DNS appropriée. Si les domaines publics fonctionnent, mais pas les noms internes, DNS Protection n’est rarement la cause réelle. Dans ce cas, les routes de requêtes DNS, les serveurs DNS internes, les domaines de recherche et les suffixes DNS des clients doivent être vérifiés.
Dépannage
L’emplacement n’apparaît pas dans Sophos Central
Vérifiez si l’IP WAN publique ou le FQDN DDNS dans l’emplacement est correct. Pour plusieurs lignes WAN, toutes les adresses de sortie pertinentes doivent être prises en compte. Pour les adresses IP dynamiques, il peut y avoir de courts délais avant que DNS Protection ne reconnaisse le changement.
Les noms internes ne fonctionnent plus
Dans ce cas, il manque généralement des routes de requêtes DNS ou les clients n’interrogent pas le résolveur attendu. Les domaines AD internes, les zones inverses et les domaines d’application doivent être explicitement redirigés vers les serveurs DNS internes.
DNS Protection bloque un domaine interne ou légitime
Clarifiez d’abord si le domaine est interne, public, mal catégorisé ou réellement risqué. Ensuite, vérifiez la liste de domaines et la politique. Ne définissez pas de règle d’autorisation large avant de connaître la cause et les utilisateurs concernés.
Les journaux restent vides
Si aucun journal n’apparaît dans Sophos Central, le client n’utilise peut-être pas DNS Protection. Vérifiez : DHCP, DNS client, DNS du pare-feu, redirection NAT, résolveurs alternatifs, profil VPN et si l’emplacement est correctement reconnu dans Sophos Central.
La page de blocage n’apparaît pas
Dans ce cas, le certificat racine DNS Protection n’est souvent pas installé, le client utilise un autre chemin DNS, ou un autre contrôle de sécurité perturbe la connexion. L’inspection TLS et la Web Protection doivent également être vérifiées.
DoH ou DNS privé contourne le contrôle
Les navigateurs et systèmes d’exploitation peuvent utiliser DNS over HTTPS ou des fonctions DNS privées. Selon l’environnement, ces fonctions doivent être contrôlées par des politiques de navigateur, MDM ou système d’exploitation. DNS Protection sur le chemin réseau n’aide que si les requêtes passent effectivement par le résolveur prévu.
Les clients VPN se comportent différemment des clients LAN
Pour les clients VPN, le comportement dépend fortement du profil. Le tunnel complet, le tunnel fractionné, les suffixes DNS, les domaines de recherche et les résolveurs locaux du client peuvent influencer la résolution de noms. Si DNS Protection fonctionne dans le LAN mais pas via VPN, il convient d’abord de vérifier le profil VPN, les serveurs DNS assignés, les suffixes DNS et les règles du pare-feu. Pour les environnements d’accès à distance, Sophos Connect ou SSL VPN : Quelle solution d’accès à distance convient ? peut également convenir.
Recommandation d’exploitation
DNS Protection doit être exploité comme un contrôle de sécurité, et non comme un simple échange de serveur DNS.
Du point de vue d’Avanet, il convient de décider honnêtement au préalable si DNS Protection est réellement l’outil approprié pour l’environnement. Pour de nombreuses installations de pare-feu classiques, des résolveurs DNS rapides et redondants plus des Threat Feeds bien entretenus sur le pare-feu sont la variante d’exploitation la plus robuste. DNS Protection vaut surtout la peine si l’exploitation souhaite également utiliser activement les politiques Central, les journaux, les catégories, les listes de domaines et la composante Endpoint.
Vérifiez régulièrement :
- Les emplacements et les adresses IP WAN sont corrects.
- DHCP distribue toujours les bons serveurs DNS.
- Les routes de requêtes DNS internes sont à jour.
- Les politiques et les listes de domaines ont un propriétaire et une date de révision.
- Les journaux sont analysés.
- Les principaux domaines bloqués sont vérifiés pour les faux positifs.
- Les nouveaux emplacements, réseaux VPN et réseaux invités sont pris en compte dans le design.
Pour les sujets de détection, Exploiter Sophos Firewall NDR et Active Threat Response peut compléter. Pour les IP, domaines et URL malveillants connus au niveau du pare-feu, les Sophos Firewall Threat Feeds restent pertinents.
Liste de contrôle
- Licence Sophos Central DNS Protection vérifiée.
- Emplacement créé comme Location.
- IP WAN publique ou FQDN DDNS correctement enregistré.
- Adresses IP de DNS Protection copiées depuis Central.
- Sophos Firewall utilise DNS Protection comme DNS-Forwarder.
- Domaines internes couverts par des routes de requêtes DNS.
- DHCP distribue le pare-feu comme résolveur DNS.
- Contournement direct du DNS vérifié et redirigé par NAT si nécessaire.
- Certificat racine DNS Protection planifié pour les pages de blocage.
- Lien de test depuis Sophos Central vérifié avec succès.
- Journaux et rapports contrôlés dans Sophos Central.
- Processus de faux positifs et révision des listes de domaines définis.