Le meilleur filtrage DNS : un guide complet pour les entreprises

Ce guide de référence technique explique comment le filtrage DNS d'entreprise sécurise les réseaux publics en bloquant les domaines malveillants au niveau de la couche de résolution - avant même qu'une connexion ne soit établie. Il fournit aux directeurs informatiques, architectes réseau et équipes d'exploitation des sites l'architecture de déploiement, la configuration du pare-feu et le contexte de conformité nécessaires pour protéger le WiFi invité dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Purple Shield bloque les logiciels malveillants, les botnets et les contenus inappropriés au niveau DNS sur plus de 80 000 sites actifs.

📖 8 min de lecture📝 1,807 mots🔧 2 exemples concrets❓ 4 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast

Bienvenue dans cette présentation technique de Purple. Aujourd'hui, nous nous penchons sur un composant essentiel de la sécurité des réseaux d'entreprise : le filtrage DNS.

Si vous êtes directeur informatique ou architecte réseau et que vous gérez des réseaux publics dans les secteurs de l'hôtellerie, de la vente au détail ou des grands sites événementiels, vous savez que fournir du WiFi est un service de base. Tout comme l'électricité ou le chauffage, c'est un service que les visiteurs s'attendent simplement à voir fonctionner dès qu'ils entrent dans un bâtiment. Mais du point de vue de la sécurité, ce service crée une surface d'attaque massive et non gérée.

Lorsque vous offrez un accès ouvert à un réseau, vous invitez des appareils non gérés sur votre infrastructure. Vous ne pouvez pas installer de protection des terminaux sur l'appareil personnel d'un invité. Les périmètres de sécurité traditionnels sont insuffisants. C'est pourquoi le filtrage DNS est devenu la couche la plus critique d'une suite de sécurité moderne. Il déplace la défense vers la toute première étape d'une connexion numérique.

Commençons par une analyse technique approfondie. Comment fonctionne réellement le filtrage DNS ?

Le Domain Name System, ou DNS, est l'annuaire d'internet. Lorsqu'un invité se connecte à votre WiFi et saisit une adresse de site web dans son navigateur, son appareil doit traduire ce domaine lisible par l'homme en une adresse IP lisible par la machine. Dans une configuration standard, cette requête va vers un résolveur par défaut, souvent fourni par le FAI.

Dans une architecture sécurisée utilisant le filtrage DNS, le serveur DHCP attribue un résolveur DNS sécurisé et spécifique à l'appareil de l'invité. Lorsque la requête atteint ce moteur de filtrage, elle ne se contente pas de résoudre l'adresse IP. Elle évalue le domaine par rapport à des flux de renseignements sur les menaces en temps réel et à vos politiques d'entreprise spécifiques.

Si le domaine est sain, l'IP est renvoyée et la connexion se poursuit. Cela se produit en quelques millisecondes. En revanche, si le domaine est signalé comme malveillant - comme un site de phishing connu ou un serveur de commande et de contrôle de botnet - ou s'il enfreint votre politique de contenu, le moteur intervient. Soit il renvoie une adresse IP non routable, une technique appelée sinkholing, soit il redirige l'utilisateur vers une page de blocage personnalisée.

Pourquoi cette approche est-elle supérieure aux alternatives comme le Deep Packet Inspection ou le filtrage par proxy ? Tout est question de performance et d'échelle.

Le Deep Packet Inspection exige que le matériel réseau inspecte la charge utile de chaque paquet. Dans un environnement dense comme un stade avec cinquante mille utilisateurs simultanés, le DPI introduit une latence massive et nécessite un matériel incroyablement coûteux. Le filtrage DNS, en revanche, fonctionne au tout début du cycle de vie de la connexion. Il évalue un paquet UDP léger. Une fois la résolution DNS terminée, le transfert de données réel se fait directement entre le client et le serveur sécurisé. Le moteur de filtrage n'a pas besoin de traiter la lourde charge utile des données. Cela se traduit par un impact sur la latence proche de zéro, généralement inférieur à deux millisecondes.

De plus, comme le filtrage DNS fonctionne avant que la connexion ne soit établie, il est totalement agnostique vis-à-vis des protocoles. Il bloque la connexion, que l'application tente d'utiliser HTTP, HTTPS, FTP ou un port personnalisé.

Prenons maintenant un exemple concret. Soit une chaîne d'hôtels de luxe de cinq cents chambres. Elle est confrontée à une utilisation excessive de la bande passante en raison du streaming illégal, et a reçu des plaintes concernant l'accès à du contenu inapproprié dans les espaces publics. Leur système de gestion hôtelière partage la même infrastructure physique via des VLAN.

La bonne approche consiste à déployer une solution de filtrage DNS basée sur le cloud et à configurer la plage DHCP spécifiquement pour le VLAN du WiFi invités afin d'attribuer les adresses IP du DNS cloud. De plus, il est crucial de mettre en place des règles de pare-feu sur la passerelle pour bloquer le trafic sortant des ports UDP et TCP cinquante-trois du VLAN invités vers toute adresse IP externe autre que les serveurs DNS approuvés. Vous créez ensuite une politique bloquant les catégories de contenu pour adultes, de piratage et de logiciels malveillants. La décision d'architecture clé consiste à s'assurer que le VLAN du système de gestion hôtelière continue d'utiliser des serveurs DNS internes, isolant ainsi complètement la politique de filtrage au réseau invités.

Abordons maintenant les pièges de mise en œuvre.

L'étape fondamentale est la configuration du réseau. Vous devez configurer votre passerelle ou votre serveur DHCP pour distribuer les adresses IP de votre service de filtrage DNS à tous les clients du VLAN invités.

Mais voici la règle d'or essentielle : bloquez le port cinquante-trois, sinon tout est accessible.

Si vous vous contentez d'attribuer les serveurs DNS via DHCP, les utilisateurs avertis ou les applications malveillantes peuvent contourner le filtre en configurant manuellement leurs propres paramètres DNS, comme le huit-huit-huit-huit de Google ou le un-un-un-un de Cloudflare. Pour empêcher ce contournement, vous devez implémenter des règles de pare-feu au niveau de la passerelle afin de bloquer tout trafic sortant sur le port cinquante-trois, en UDP comme en TCP, vers toute adresse IP autre que vos serveurs de filtrage désignés.

Un autre piège majeur concerne les Captive Portals. Nous constatons souvent cela dans les déploiements destinés au commerce de détail et à l'hôtellerie. Un établissement met en place un filtrage DNS strict, et soudainement, les invités ne peuvent plus se connecter. Pourquoi ? Parce que le Captive Portal s'appuie sur des domaines externes pour l'authentification - par exemple, des fournisseurs OAuth pour la connexion via les réseaux sociaux. Si votre filtre DNS bloque ces domaines avant que l'utilisateur ne soit authentifié, vous créez une impasse. L'utilisateur ne peut pas accéder à Internet pour s'authentifier, et il ne peut pas s'authentifier pour accéder à Internet.

La solution consiste à s'assurer que votre Walled Garden est correctement configuré. Vous devez explicitement autoriser dans la politique de filtrage DNS les domaines requis pour le fonctionnement du Captive Portal.
Un deuxième scénario réel : un grand centre commercial souhaite proposer un WiFi public gratuit avec un Captive Portal pour la capture de données démographiques, tout en respectant des politiques d'entreprise strictes et adaptées aux familles. L'intégration du filtrage DNS avec le Captive Portal nécessite l'ajout des domaines d'authentification, tels que Microsoft Entra ID ou Google Workspace, à la liste d'autorisation de pré-authentification. La politique de filtrage de contenu n'est ensuite appliquée qu'une fois que l'utilisateur s'est authentifié avec succès. Cette approche transforme un conflit technique potentiel en une expérience visiteur fluide.

Passons maintenant à une session rapide de questions - réponses basée sur des scénarios courants.

Question un : Pouvons-nous utiliser l'inspection HTTPS transparente au lieu du filtrage DNS pour notre réseau invité ?

Non. L'inspection HTTPS transparente nécessite le déploiement d'un certificat racine personnalisé sur l'appareil final pour déchiffrer le trafic. Vous ne pouvez pas déployer de certificats sur des appareils invités non gérés. Cela perturberait leur expérience de navigation en affichant de graves avertissements de sécurité. Le filtrage DNS est l'approche correcte pour les environnements de type bring-your-own-device.

Question deux : Comment le filtrage DNS gère-t-il le DNS over HTTPS, ou DoH ?

Le DoH chiffre la requête DNS, ce qui peut contourner l'interception classique au niveau du réseau. La meilleure pratique consiste à identifier et à bloquer les adresses IP des fournisseurs de DoH connus au niveau du pare-feu, obligeant le client à se rabattre sur un DNS standard et filtrable.

Question trois : Le filtrage DNS aide-t-il à la conformité ?

Absolument. Pour des cadres comme PCI DSS, il est obligatoire de démontrer une segmentation du réseau et des contrôles d'accès robustes. Bien que les réseaux invités doivent toujours être segmentés des réseaux de paiement, empêcher l'exécution de logiciels malveillants sur le réseau invité réduit le profil de risque global du site. Pour les besoins du GDPR, démontrer que vous avez pris des mesures techniques raisonnables pour empêcher l'utilisation abusive de votre réseau est un indicateur positif de conformité.

Pour résumer le briefing d'aujourd'hui. Le filtrage DNS n'est pas seulement une meilleure pratique de sécurité. C'est une nécessité opérationnelle pour les réseaux publics d'entreprise. Il fournit un mécanisme évolutif et à faible latence pour bloquer les menaces malveillantes et appliquer les politiques d'utilisation acceptable.

Les points clés à retenir sont les suivants. Premièrement, le filtrage DNS intercepte les requêtes de domaine avant qu'une connexion ne soit établie, ajoutant moins de deux millisecondes de latence. Deuxièmement, bloquez toujours le port de sortie cinquante-trois au niveau du pare-feu pour empêcher le contournement via des paramètres DNS personnalisés. Troisièmement, configurez soigneusement votre Walled Garden pour vous assurer que les domaines d'authentification du Captive Portal ne sont pas bloqués. Quatrièmement, utilisez la segmentation VLAN pour appliquer les politiques de filtrage exclusivement au trafic invité, protégeant ainsi les systèmes opérationnels. Et cinquièmement, le filtrage DNS soutient la conformité avec PCI DSS et GDPR en démontrant des contrôles d'accès réseau robustes.

Vos prochaines étapes : auditez la configuration DNS actuelle de votre réseau invité, vérifiez que le port de sortie cinquante-trois est restreint, et passez en revue le Walled Garden de votre Captive Portal par rapport à votre politique de filtrage DNS active.

Merci d'avoir écouté ce briefing technique Purple. Pour obtenir des guides de déploiement et des modèles d'architecture plus détaillés, visitez purple.ai.

Points clés à retenir

✓Le filtrage DNS intercepte les requêtes de résolution de domaine avant qu'une connexion ne soit établie, ajoutant moins de 2 ms de latence - ce qui en fait la seule méthode pratique de contrôle de contenu pour les réseaux invités à haute densité.
✓L'attribution DHCP seule ne constitue pas une mise en application. Bloquez le port sortant 53 (UDP et TCP) au niveau du pare-feu pour empêcher les utilisateurs et les logiciels malveillants de contourner le filtre avec des paramètres DNS personnalisés.
✓Configurez le Walled Garden avant d'appliquer toute politique de blocage. Les domaines des fournisseurs d'identité (Microsoft Entra ID, Google Workspace, Okta) doivent être autorisés pour que l'authentification du Captive Portal fonctionne.
✓Limitez les politiques de filtrage DNS au seul VLAN invité. Les VLAN opérationnels exécutant les systèmes POS et PMS doivent utiliser des résolveurs DNS internes pour éviter les pannes et les échecs de conformité PCI-DSS.
✓Bloquez les plages d'IP des fournisseurs de DoH connus au niveau du pare-feu pour empêcher le contournement du DNS chiffré sur les navigateurs et appareils modernes.
✓Le filtrage DNS prend en charge l'exigence 1.3 de la norme PCI-DSS (segmentation du réseau) et l'article 32 du GDPR (mesures de sécurité techniques), fournissant des preuves documentées pour les audits de conformité.
✓Purple Shield identifie et bloque les menaces zero-day jusqu'à 10 jours plus rapidement que les fournisseurs réactifs de listes noires, en utilisant une analyse de domaine basée sur l'IA plutôt que d'attendre que les sites malveillants soient signalés.

Résumé exécutif

Pour les responsables informatiques gérant des réseaux publics à grande échelle, la sécurisation de l'environnement de navigation est un impératif opérationnel, et non une simple option. Le WiFi invité dans l'hôtellerie, le commerce de détail et les lieux publics est un environnement intrinsèquement non fiable. Sans contrôles robustes, il devient un vecteur de distribution de logiciels malveillants, d'activité de botnets et d'accès à des contenus inappropriés qui nuisent à la réputation de la marque et exposent à des risques de non-conformité.

Le filtrage DNS est le mécanisme le plus efficace pour appliquer les politiques de contenu et bloquer les menaces à la périphérie du réseau. Contrairement à l'inspection approfondie des paquets (DPI), très gourmande en ressources, le filtrage DNS intercepte la requête de résolution de domaine avant tout échange de données. Il évalue un paquet UDP léger par rapport à des renseignements sur les menaces en temps réel et renvoie soit une adresse IP valide, soit un trou noir (sinkhole), ajoutant moins de deux millisecondes de latence. C'est donc la seule méthode pratique de contrôle du contenu pour les environnements à haute densité desservant des milliers d'appareils non gérés simultanés.

Ce guide présente l'architecture technique requise pour déployer le filtrage DNS sur des sites d'entreprise distribués, y compris la segmentation VLAN, l'application du port 53, l'intégration du Captive Portal et la prévention du contournement via le DNS over HTTPS (DoH). Il aborde également la conformité avec PCI-DSS et le GDPR, et explique comment Purple Shield s'intègre dans les infrastructures matérielles existantes de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet, sans nécessiter de remplacement de matériel.

Analyse technique approfondie : fonctionnement du filtrage DNS

Le Domain Name System (DNS) traduit les noms de domaine lisibles par l'homme en adresses IP lisibles par les machines. Chaque connexion internet commence par une requête de résolution DNS. Dans un réseau standard, les appareils interrogent un résolveur par défaut attribué par le FAI. Dans une architecture sécurisée, le serveur DHCP attribue un résolveur DNS soumis à une politique de sécurité aux appareils connectés au VLAN invité.

Lorsqu'un appareil interroge ce résolveur sécurisé, le moteur de filtrage évalue le domaine par rapport à plusieurs sources de données simultanément : flux de renseignements sur les menaces en temps réel, listes de blocage de catégories (contenu pour adultes, jeux d'argent, piratage) et registres de serveurs de commande et de contrôle (C2) de botnets. La décision se prend en quelques millisecondes.

Si le domaine est sûr, le moteur renvoie l'adresse IP correcte et la connexion se poursuit normalement. Si le domaine est identifié comme malveillant ou enfreint votre politique d'utilisation acceptable, le moteur renvoie une adresse IP non routable (sinkholing) ou redirige l'utilisateur vers une page de blocage personnalisée. Point clé : cette intervention se produit avant tout échange de données entre l'appareil et le serveur de destination.

Avantages de performance et d'évolutivité

Le filtrage DNS est architecturalement supérieur au DPI pour les environnements publics à haute densité. Le DPI nécessite que le matériel réseau inspecte la charge utile de chaque paquet. Dans un lieu accueillant 50 000 utilisateurs simultanés - un stade, un centre de conférences ou un grand domaine commercial - le DPI introduit une latence importante et nécessite un matériel coûteux et spécialisé à chaque point d'inspection.

Le filtrage DNS fonctionne au début du cycle de vie de la connexion. Il évalue un seul paquet UDP léger. Une fois la résolution terminée, les données sont transférées directement entre le client et le serveur de destination. Le moteur de filtrage ne traite jamais la charge utile des données. L'impact sur la latence est constamment inférieur à deux millisecondes, quel que soit le nombre d'utilisateurs simultanés.

Comme le filtrage DNS fonctionne avant l'établissement de la connexion, il est indépendant du protocole. Il bloque les connexions, que l'application utilise HTTP, HTTPS, FTP ou un port personnalisé. C'est un avantage considérable par rapport au filtrage basé sur les URL, qui n'inspecte que le trafic HTTP/HTTPS.

L'avantage de 10 jours en détection des menaces

La sécurité DNS existante repose sur une mise sur liste noire réactive : un domaine est identifié comme malveillant, signalé à une autorité centrale, ajouté à une base de données, et finalement distribué à votre filtre - un processus qui peut prendre plusieurs jours. Les campagnes de logiciels malveillants modernes exploitent ce décalage. Les attaquants enregistrent de nouveaux domaines, exécutent une campagne dans un intervalle de 24 heures et abandonnent le domaine avant qu'il n'atteigne une liste de blocage standard.

Purple Shield utilise une détection des menaces basée sur l'IA pour analyser les schémas d'enregistrement de domaines, la réputation des adresses IP et les signatures cryptographiques en temps réel. Cette approche identifie et bloque les menaces émergentes de type "zero-day" jusqu'à 10 jours plus rapidement que les fournisseurs réactifs traditionnels (données internes de Purple, 2026). Dans un environnement où un seul lien malveillant sur un appareil invité peut mener à un rançongiciel, cette fenêtre de détection est d'une importance opérationnelle majeure.

Guide de mise en œuvre : architecture et déploiement

Déployer correctement le filtrage DNS nécessite une configuration réseau précise à trois niveaux : DHCP, pare-feu et Captive Portal.

Étape 1 : Segmentation VLAN

Segmentez votre réseau afin que le trafic invité soit isolé des systèmes opérationnels. Placez les appareils invités sur un VLAN dédié (par exemple, le VLAN 20) et conservez les terminaux de point de vente, les systèmes de gestion immobilière et les appareils du personnel sur des VLAN distincts avec des résolveurs DNS internes. Cela garantit que votre politique de filtrage DNS s'applique exclusivement au trafic invité non approuvé et ne perturbe pas les systèmes opérationnels.

Cette segmentation répond également à l'exigence 1.3 de la norme PCI-DSS, qui exige que les environnements de données des titulaires de cartes soient isolés des réseaux non approuvés. Le WiFi invité ne doit jamais partager un VLAN avec l'infrastructure de paiement.

Étape 2 : Configuration de la plage DHCP

Configurez la plage DHCP pour le VLAN invité afin d'attribuer les adresses IP de votre service de filtrage DNS cloud comme serveurs DNS principal et secondaire. Cela garantit que chaque appareil qui rejoint le réseau invité reçoit automatiquement le bon résolveur.

Étape 3 : Application du port 53 au niveau du pare-feu

L'attribution DHCP seule est insuffisante. Un utilisateur peut contourner les paramètres DNS fournis par le DHCP en configurant manuellement son appareil pour utiliser un résolveur public tel que Google (8.8.8.8) ou Cloudflare (1.1.1.1). Les logiciels malveillants codent souvent en dur les paramètres DNS pour contourner entièrement les contrôles réseau.

Vous devez implémenter une règle de pare-feu qui rejette tout le trafic sortant sur le port 53 (à la fois UDP et TCP) du VLAN invité vers toute adresse IP autre que vos serveurs de filtrage désignés. Cela transforme le filtre DNS d'un contrôle consultatif en un contrôle appliqué.

Étape 4 : Atténuation du DNS over HTTPS (DoH)

Les navigateurs et applications modernes utilisent de plus en plus le DoH, qui chiffre les requêtes DNS au sein du trafic HTTPS standard sur le port 443. Cela contourne entièrement l'interception du port 53. Pour maintenir la couverture, configurez votre pare-feu pour bloquer les plages d'adresses IP connues des principaux fournisseurs de DoH. Cela oblige les appareils clients à se rabattre sur le DNS non chiffré standard, que votre moteur de filtrage peut inspecter. La norme NIST SP 800-81r3 (publiée en mars 2026) aborde spécifiquement le DoH en tant que considération de sécurité DNS pour les entreprises.

Étape 5 : Configuration du Walled Garden du Captive Portal

Si vous exploitez un Captive Portal pour l'authentification des invités, vous devez configurer un Walled Garden avant d'appliquer toute politique de blocage. Le Walled Garden est une liste de domaines auxquels les appareils peuvent accéder avant de s'être authentifiés. Il doit inclure tous les domaines requis pour le fonctionnement du Captive Portal : le propre domaine de votre portail, tous les fournisseurs d'identité (Microsoft Entra ID, Okta, Google Workspace) et tous les points de terminaison OAuth de connexion sociale.

Si ces domaines sont bloqués avant l'authentification, les utilisateurs ne peuvent pas terminer le flux de connexion. Il en résulte une expérience d'intégration interrompue et des invités frustrés. Configurez d'abord le Walled Garden, puis appliquez votre politique de filtrage de contenu uniquement aux sessions authentifiées.

Pour en savoir plus sur l'architecture SSID et la structuration des réseaux Guest WiFi, Staff WiFi et IoT, consultez Trois SSID pour régner sur tous : guest, Passpoint, et IoT WiFi .

Bonnes pratiques : conception des politiques et gestion continue

Blocage par catégorie

Organisez votre politique de filtrage DNS autour de catégories de contenu plutôt que de listes de blocage de domaines individuels. Les catégories comprennent généralement : les logiciels malveillants et le phishing, le commandement et contrôle de botnets, le contenu pour adultes, les jeux d'argent, le streaming illégal et le partage de fichiers en peer-to-peer. Les politiques basées sur des catégories sont plus faciles à maintenir et capturent automatiquement les nouveaux domaines au fur et à mesure des mises à jour des renseignements sur les menaces.

Fréquence de mise à jour des renseignements sur les menaces

Sélectionnez un fournisseur de filtrage DNS qui met à jour l'intelligence des menaces en temps réel ou quasi réel. Les listes de blocage statiques mises à jour quotidiennement sont insuffisantes face aux campagnes modernes de logiciels malveillants fast-flux. Purple Shield met à jour son intelligence des menaces en continu, reflétant la même détection alimentée par l'IA qui offre l'avantage de 10 jours par rapport aux fournisseurs réactifs.

Déploiement indépendant du matériel

Purple Shield fonctionne comme une surcouche cloud, ce qui signifie qu'il s'intègre à votre infrastructure de points d'accès existante sans remplacement de matériel. Il est compatible avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. La politique de filtrage est appliquée au niveau de la couche DNS, de sorte que le matériel du point d'accès n'a qu'à transférer les requêtes DNS vers le bon résolveur.

Analyses et rapports

Le filtrage DNS génère des journaux de requêtes détaillés qui offrent une visibilité sur le comportement du réseau. Utilisez ces journaux pour identifier les tendances : un pic de tentatives de phishing bloquées à partir d'un point d'accès spécifique peut indiquer une attaque ciblée. L'examen régulier des rapports de catégories bloquées soutient également les audits de conformité, démontrant aux évaluateurs PCI-DSS et aux auditeurs GDPR que vous avez des contrôles actifs en place.

La plateforme WiFi Analytics de Purple s'intègre à Shield pour offrir une visibilité unifiée sur les événements de sécurité et les performances du réseau.

Dépannage et atténuation des risques

Contournement du filtre via un DNS personnalisé

Symptôme : Les utilisateurs signalent avoir accès à du contenu qui devrait être bloqué. Les journaux du pare-feu affichent des requêtes DNS vers 8.8.8.8 ou 1.1.1.1 à partir du VLAN invité.

Cause : Le port 53 n'est pas bloqué au niveau du pare-feu. Les utilisateurs ignorent les paramètres DNS attribués par DHCP.

Correction : Implémentez une règle de pare-feu rejetant tout le trafic sortant UDP/TCP du port 53 depuis le VLAN invité vers toute adresse IP autre que votre moteur de filtrage.

Échec d'authentification du Captive Portal

Symptôme : Les invités ne peuvent pas terminer le flux de connexion. La page du Captive Portal ne se charge pas ou les boutons de connexion sociale ne répondent pas.

Cause : Le filtre DNS bloque les domaines des fournisseurs d'identité avant l'authentification. Microsoft Entra ID, Google Workspace ou le propre domaine de votre portail figure sur une liste de catégories bloquées.

Correction : Auditez votre configuration de Walled Garden. Ajoutez tous les domaines d'authentification requis à la liste d'autorisation de pré-authentification. Testez l'intégralité du flux de connexion dans un environnement de test avant de déployer les modifications de politique.

Contournement DoH

Symptôme : Les journaux du filtre DNS affichent un faible volume de requêtes malgré une utilisation élevée du réseau. Certains appareils semblent contourner complètement le filtrage.

Cause : Les navigateurs ou les applications utilisent DoH, acheminant les requêtes DNS chiffrées via le port 443 vers des résolveurs externes.

Correction : Bloquez les plages d'adresses IP connues des principaux fournisseurs DoH au niveau du pare-feu. Vérifiez la couverture en surveillant les connexions HTTPS vers les adresses IP des résolveurs DoH connus.

Perturbation du VLAN opérationnel

Symptôme : Les terminaux de point de vente ou les systèmes de gestion immobilière perdent leur connectivité après le déploiement du filtre DNS.

Cause : La politique de filtrage DNS a été appliquée au mauvais VLAN, ou le DHCP attribue le résolveur DNS cloud aux appareils opérationnels.

Solution : Vérifiez le marquage VLAN sur tous les ports de commutateur et points d'accès. Confirmez que les VLAN des appareils opérationnels sont configurés pour utiliser uniquement des résolveurs DNS internes.

ROI et impact commercial

Le filtrage DNS offre des retours mesurables sur trois dimensions.

Récupération de bande passante : Le blocage du streaming illégal, du partage peer-to-peer et du trafic automatisé de botnets permet de récupérer une bande passante importante. Dans un environnement hôtelier, cela peut réduire l'utilisation du VLAN invité de 20 à 40 %, améliorant ainsi les performances pour les utilisateurs légitimes sans nécessiter de mise à niveau des circuits.

Réduction des coûts de conformité : Démontrer des contrôles actifs au niveau DNS réduit la portée et le coût des évaluations PCI-DSS. Cela fournit également des preuves documentées pour l'article 32 du GDPR (mesures techniques pour assurer la sécurité des données) et soutient les exigences de certification Cyber Essentials pour la protection contre les malwares.

Protection de la marque et de la responsabilité : L'application de politiques de navigation adaptées aux familles dans les environnements de vente au détail et d'hôtellerie empêche l'affichage public de contenus inappropriés. Dans les espaces accueillant des enfants - centres commerciaux, hôtels familiaux, stades - il s'agit à la fois d'une exigence de marque et d'une considération légale dans de nombreuses juridictions.

Pour des conseils de déploiement spécifiques à chaque secteur, consultez nos pages sectorielles pour l' Hôtellerie , le Commerce de détail , la Santé et les Transports .

Définitions clés

Filtrage DNS

Une technique de sécurité qui intercepte les requêtes de résolution de domaine et les évalue par rapport à des flux de renseignements sur les menaces et des politiques de contenu avant d'autoriser ou de bloquer une connexion.

La principale méthode de contrôle du contenu pour les appareils invités non gérés sur les réseaux publics. Aucun agent de terminal n'est requis.

Sinkholing

Retourner une adresse IP non routable (telle que 0.0.0.0) en réponse à une requête DNS pour un domaine malveillant, empêchant ainsi l'appareil d'établir une connexion.

Utilisé pour bloquer discrètement le trafic de commande et de contrôle des botnets sans alerter le malware qu'il a été détecté.

Walled Garden

Un environnement réseau restreint de pré-authentification qui permet d'accéder à un ensemble spécifique de domaines approuvés avant qu'un utilisateur ne termine le processus de connexion au Captive Portal.

Doit inclure tous les domaines des fournisseurs d'identité (Microsoft Entra ID, Google Workspace, Okta) et les ressources du portail captif pour éviter les échecs d'authentification.

DNS over HTTPS (DoH)

Un protocole qui chiffre les requêtes DNS au sein du trafic HTTPS standard sur le port 443, masquant le domaine de destination de toute inspection au niveau du réseau.

De plus en plus utilisé par défaut dans les navigateurs modernes. Nécessite un blocage au niveau du pare-feu des plages d'adresses IP des fournisseurs DoH pour maintenir la couverture du filtrage DNS.

Segmentation VLAN

Division d'un réseau physique unique en plusieurs réseaux logiques isolés à l'aide du marquage 802.1Q.

Cruciale pour isoler le trafic invité des systèmes opérationnels. La norme PCI DSS requiert que les environnements de données de titulaires de carte soient séparés des réseaux non fiables, y compris du WiFi invité.

Captive Portal

Une page web avec laquelle les appareils doivent interagir avant d'obtenir un accès complet au réseau, utilisée pour l'authentification, l'acceptation des conditions d'utilisation et la collecte de données de première partie.

Nécessite une configuration minutieuse du Walled Garden pour fonctionner correctement aux côtés du filtrage DNS.

Deep Packet Inspection (DPI)

Une méthode de filtrage réseau qui examine l'intégralité de la charge utile des paquets à un point d'inspection, permettant un filtrage sensible au contenu mais introduisant une surcharge de traitement importante.

Peu pratique pour les réseaux invités à haute densité en raison de la latence et du coût du matériel. Le filtrage DNS est l'alternative privilégiée pour les environnements d'appareils non gérés.

Flux de renseignements sur les menaces

Une base de données continuellement mise à jour d'adresses IP, de domaines et de modèles d'URL malveillants connus, utilisée pour alimenter les décisions de filtrage DNS en temps réel.

La qualité et la fréquence de mise à jour du flux de renseignements sur les menaces déterminent la rapidité avec laquelle un filtre DNS répond aux nouvelles menaces zero-day.

Domaine zero-day

Un domaine nouvellement enregistré utilisé dans une campagne de malware ou de phishing avant d'apparaître sur une liste de blocage standard.

Les campagnes d'attaque modernes utilisent des domaines jetables qui sont actifs pendant moins de 24 heures. La détection des menaces basée sur l'IA identifie ces domaines en analysant les modèles d'enregistrement plutôt qu'en attendant des rapports.

Exemples concrets

Une chaîne hôtelière de 400 chambres déploie un WiFi invité sur 12 propriétés. Elle utilise Microsoft Entra ID pour l'authentification sur le Captive Portal et son système de gestion de propriété (PMS) fonctionne sur la même infrastructure de commutateur physique. Après avoir activé le filtrage DNS, les clients de trois propriétés signalent qu'ils ne peuvent pas terminer le processus de connexion. Quelle est la cause racine et comment l'équipe doit-elle résoudre ce problème ?

La cause racine est une configuration incomplète du Walled Garden. Le filtre DNS bloque les domaines d'authentification Microsoft Entra ID avant que les clients ne s'authentifient, créant une situation de blocage où les clients ne peuvent pas charger la page de connexion. Étapes de résolution : 1. Dans le tableau de bord de filtrage DNS, créez une politique de pré-authentification qui autorise explicitement tous les domaines Microsoft Entra ID, y compris login.microsoftonline.com, login.live.com et tous les domaines spécifiques au locataire. 2. Vérifiez que le propre domaine du Captive Portal et tous les éléments du CDN qu'il charge sont également autorisés. 3. Confirmez que le VLAN du PMS (VLAN 10) est configuré pour utiliser des résolveurs DNS internes, et non le moteur de filtrage cloud. 4. Appliquez la politique restrictive de blocage de contenu uniquement aux sessions post-authentification sur le VLAN invité (VLAN 20). 5. Testez l'ensemble du processus de connexion sur chaque propriété concernée avant de clôturer l'incident.

Commentaire de l'examinateur : Il s'agit de la défaillance de déploiement de filtrage DNS la plus courante dans le secteur de l'hôtellerie. Le correctif est simple mais nécessite de comprendre que le filtrage DNS s'applique à toutes les requêtes DNS d'un appareil, y compris celles effectuées avant l'authentification. Le Walled Garden doit être configuré avant l'activation de toute politique de blocage. Le problème d'isolation du PMS est une découverte secondaire mais critique - le mélange des politiques DNS opérationnelles et des invités sur le même résolveur crée un risque de conformité avec l'exigence 1.3 de la norme PCI-DSS.

Une grande chaîne de vente au détail exploite 200 magasins, chacun disposant d'un réseau WiFi invité. Leur équipe de sécurité informatique déploie un filtre DNS cloud et met à jour la plage DHCP sur tous les VLAN invités. Deux semaines plus tard, un test d'intrusion révèle que 18 % des appareils invités parviennent à résoudre des domaines malveillants connus. Les journaux du filtre DNS ne montrent aucune requête bloquée pour ces appareils. Quel est le défaut d'architecture et quel est le correctif ?

Le défaut est que le port 53 n'est pas bloqué au niveau du pare-feu. Les 18 % d'appareils contournent les serveurs DNS attribués par DHCP en utilisant des résolveurs codés en dur (8.8.8.8, 1.1.1.1) ou en utilisant le DNS over HTTPS. Comme leurs requêtes DNS n'atteignent jamais le moteur de filtrage, aucune requête bloquée n'apparaît dans les journaux. Correctif : 1. Implémentez une règle de pare-feu sur la passerelle du VLAN invité qui rejette tout le trafic sortant UDP et TCP sur le port 53 vers toute IP autre que les IP approuvées du moteur de filtrage. 2. Identifiez et bloquez les plages d'adresses IP des principaux fournisseurs DoH (Cloudflare, Google, NextDNS) au niveau du pare-feu pour empêcher le contournement chiffré. 3. Exécutez à nouveau le test d'intrusion pour confirmer la couverture. 4. Surveillez les journaux de rejet du pare-feu pour le trafic du port 53 afin de vérifier que la règle est active.

Commentaire de l'examinateur : Le DHCP est une suggestion, pas un mécanisme d'application. La règle de pare-feu est la véritable couche d'application. Cette distinction est essentielle et fréquemment oubliée lors des déploiements initiaux. Le contournement par DoH est un vecteur secondaire qui nécessite une atténuation distincte. Ensemble, ces deux contrôles - le blocage du port 53 et le blocage des IP des fournisseurs DoH - ferment les principales voies d'évitement.

Questions d'entraînement

Q1. Une chaîne de magasins déploie un filtre DNS cloud dans 150 points de vente. Ils mettent à jour l'étendue DHCP sur tous les VLAN invités pour attribuer les IP du moteur de filtrage. Une semaine plus tard, les directeurs de magasin signalent que les clients peuvent toujours accéder aux catégories de contenu bloquées. Le tableau de bord du filtre DNS indique un volume de requêtes très faible de la part de ces magasins. Quelle est la cause la plus probable et quelle est la solution ?

Conseil : Réfléchissez à la façon dont un appareil peut résoudre le DNS sans utiliser le serveur attribué par DHCP.

Voir la réponse type

La cause la plus probable est que le port de sortie 53 n'est pas bloqué au niveau du pare-feu. Les appareils contournent les serveurs DNS attribués par DHCP avec des résolveurs publics codés en dur. Le faible volume de requêtes dans le tableau de bord confirme que les requêtes n'atteignent pas le moteur de filtrage. La solution consiste à implémenter une règle de pare-feu rejetant tout trafic UDP et TCP sortant sur le port 53 depuis le VLAN invité vers toute IP autre que les adresses IP approuvées du moteur de filtrage. De plus, bloquez les plages d'adresses IP des fournisseurs DoH connus pour empêcher le contournement du DNS chiffré.

Q2. Un centre de conférence déploie le filtrage DNS pour la première fois. Ils utilisent Google Workspace pour l'authentification des participants sur leur Captive Portal. Pendant les tests, les participants ne peuvent pas terminer le flux de connexion - la page de connexion Google ne se charge pas. Quelle étape de configuration a été manquée et comment doit-elle être corrigée ?

Conseil : L'authentification a lieu avant que l'appareil n'ait un accès complet à Internet. Quels domaines doivent être accessibles avant que l'authentification ne soit terminée ?

Voir la réponse type

Le Walled Garden n'a pas été configuré avant l'application de la politique de filtrage DNS. Le filtre DNS bloque les domaines d'authentification Google Workspace (accounts.google.com, oauth2.googleapis.com) avant que les participants ne puissent s'authentifier. La solution consiste à ajouter tous les domaines OAuth et d'authentification Google Workspace requis à la liste d'autorisation de pré-authentification dans la politique de filtrage DNS. Le propre domaine du Captive Portal et toutes les ressources du CDN doivent également être mis sur liste d'autorisation. Appliquez la politique de contenu restrictive uniquement aux sessions post-authentification.

Q3. L'équipe informatique d'un stade évalue le filtrage DNS par rapport à l'inspection approfondie des paquets (DPI) pour leur site d'une capacité de 60 000 personnes. L'équipe réseau s'inquiète de la latence lors des pics d'affluence. Quelle approche est la plus appropriée et pourquoi ?

Conseil : Tenez compte de la surcharge de traitement de chaque méthode à l'échelle de 60 000 utilisateurs simultanés.

Voir la réponse type

Le filtrage DNS est le choix approprié. Il fonctionne au niveau de la couche de résolution, en évaluant un seul paquet UDP léger avant qu'une connexion ne soit établie, ajoutant moins de deux millisecondes de latence quel que soit le nombre d'utilisateurs simultanés. La DPI nécessite d'inspecter l'intégralité de la charge utile de chaque paquet, ce qui, avec 60 000 utilisateurs simultanés, introduirait une latence importante et nécessiterait un matériel prohibitif à chaque point d'inspection. Le filtrage DNS est également indépendant du protocole, bloquant les connexions sur n'importe quel port, tandis que la DPI est généralement limitée au trafic HTTP et HTTPS.

Q4. Un directeur informatique d'un groupe hôtelier souhaite confirmer que son déploiement de filtrage DNS répond aux exigences PCI-DSS. Leurs terminaux de paiement sont sur le VLAN 10 et le WiFi invité est sur le VLAN 20. Le filtre DNS est appliqué uniquement au VLAN 20. Quelles preuves supplémentaires doivent-ils documenter pour leur évaluateur PCI-DSS ?

Conseil : L'exigence 1.3 de la norme PCI-DSS couvre les contrôles d'accès réseau entre les réseaux approuvés et non approuvés.

Voir la réponse type

Le directeur informatique doit documenter : 1. Les règles de pare-feu confirmant que le VLAN 10 (environnement des données de titulaires de carte) n'est pas accessible depuis le VLAN 20 (réseau invité), satisfaisant à l'exigence 1.3 de la norme PCI-DSS. 2. La configuration DHCP montrant que les appareils du VLAN 10 utilisent des résolveurs DNS internes, et non le moteur de filtrage cloud. 3. Les règles de pare-feu bloquant le port sortant 53 du VLAN 20 vers des IP non approuvées, démontrant un filtrage DNS appliqué. 4. La documentation de la politique de filtrage DNS montrant les catégories actives de blocage des logiciels malveillants et des botnets sur le VLAN 20. 5. Les journaux du filtre DNS montrant les événements de requêtes bloquées, démontrant que le contrôle est actif et surveillé.

Continuer la lecture de cette série

Comment segmenter en toute sécurité les réseaux WiFi des employés et des invités

Ce guide technique de référence fournit aux responsables informatiques des stratégies exploitables pour segmenter en toute sécurité les réseaux WiFi des employés, des invités et de l'IoT à l'aide de VLAN et du protocole 802.1X. Il détaille comment sécuriser l'infrastructure d'entreprise, maintenir la conformité PCI-DSS et exploiter les portails captifs pour capturer des données de première main.

Comprendre Cisco SUDI : L'identité ancrée dans le matériel pour le contrôle d'accès réseau sécurisé

Ce guide explique comment Cisco SUDI fournit une identité sécurisée par cryptographie et ancrée dans le matériel pour l'infrastructure réseau d'entreprise. Découvrez comment remplacer les adresses MAC falsifiables par des certificats 802.1AR immuables afin de sécuriser le contrôle d'accès réseau de votre site.

Comment configurer SCEP pour l'enrôlement automatisé de certificats WiFi d'entreprise

Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi d'entreprise, couvrant l'architecture complète depuis la PKI et le NDES jusqu'au déploiement de profils MDM et à la validation RADIUS. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de vente au détail, de stades, de centres de conférence et d'organisations du secteur public qui souhaitent dépasser les clés pré-partagées et mettre en œuvre une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud overlay de Purple, indépendante du matériel, s'intègre directement à cette architecture, fournissant la couche WiFi pour les invités et le BYOD qui coexiste avec votre réseau d'employés authentifié par certificat.