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, aux architectes réseau et aux é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, de la vente au détail et du secteur public. Purple Shield bloque les logiciels malveillants, les botnets et les contenus inappropriés au niveau du DNS sur plus de 80 000 sites actifs.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
Enterprise DNS Filtering Sizing & Security Policy Advisor
Model real-world DNS query throughput, QPS spikes, malicious domain blocking rates, and CIPA compliance posture for guest and enterprise WiFi fleets with Purple Shield.
DNS Query Sizing & Edge Threat Mitigation Breakdown
Monthly WAN Bandwidth Savings
By sinkholing malware, malicious advertisements, and unauthorized streaming domains at the UDP resolution phase, the network prevents full TCP handshakes and payload downloads.
IT Administration Hours Saved
Managed threat intelligence feeds, no manual blocklist maintenance, and audit exports take repetitive resolver and firewall work off the service desk. The figure tracks the volume actually blocked, and is capped at 120 hours a month.
| Metric / Parameter | Current Model | Industry Benchmark | Status |
|---|---|---|---|
| Active Endpoint Concurrency | 3,825 devices | Peak concurrency 75%–90% | Sized |
| Resolver Response Latency | 12 ms | Target < 20 ms | Optimal |
| Total Monthly Queries Processed | 252,450,000 queries | High-density venue scale | Protected |
| DoH / DoT Bypass Containment | Active (Port 853 + ACL) | RFC 8484 / RFC 7858 block | Enforced |
Synthèse opérationnelle
Pour les responsables informatiques qui gèrent des réseaux publics de grande envergure, la sécurisation de l'environnement de navigation est un impératif opérationnel, et non une option agréable à avoir. Le WiFi invité dans l'hôtellerie, le commerce de détail et les lieux publics est un environnement intrinsèquement non approuvé. 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 créent 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), qui est gourmande en ressources, le filtrage DNS intercepte la demande 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. Cela en fait la seule méthode de contrôle du contenu pratique pour les environnements à haute densité desservant des milliers d'appareils non gérés simultanément.
Ce guide couvre 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 sur HTTPS (DoH). Il aborde également la conformité avec PCI-DSS et 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 demande 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 à des règles de sécurité aux appareils sur le 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 par catégorie (contenu pour adultes, jeux d'argent, piratage) et registres de domaines de commande et contrôle 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 signalé comme malveillant ou enfreint votre charte d'utilisation acceptable, le moteur renvoie soit une adresse IP non routable (sinkholing), soit redirige l'utilisateur vers une page de blocage personnalisée. Le point clé : cette intervention se produit avant tout échange de données entre l'appareil et le serveur de destination.
Avantages en matière de performances et d'évolutivité
Le filtrage DNS est architecturalement supérieur au DPI pour les environnements publics à haute densité. Le DPI exige 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 espace 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 intervient au tout début du cycle de vie de la connexion. Il évalue un seul paquet UDP léger. Une fois la résolution effectuée, le transfert de données se fait 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 reste constamment inférieur à deux millisecondes, quel que soit le nombre d'utilisateurs simultanés.
Comme le filtrage DNS s'effectue 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 majeur par rapport au filtrage basé sur les URL, qui n'inspecte que le trafic HTTP/HTTPS.
L'avantage d'une détection des menaces anticipée de 10 jours
La sécurité DNS traditionnelle 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, puis 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, puis 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'intelligence artificielle pour analyser les schémas d'enregistrement des 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 Purple, 2026). Dans un environnement où un seul lien malveillant sur un appareil invité peut conduire à un rançongiciel, cette fenêtre de détection est d'une importance opérationnelle cruciale.
Guide d'implémentation : 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 d'isoler le trafic des invités des systèmes opérationnels. Placez les appareils des invités sur un VLAN dédié (par exemple, 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 impose d'isoler les environnements de données des titulaires de cartes 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 ne suffit pas. 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 complètement 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 indicatif en un contrôle appliqué.
Étape 4 : Atténuation du DNS sur 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 complètement 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 force 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) traite spécifiquement du DoH en tant que considération de sécurité DNS d'entreprise.
É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 sur la manière dont les réseaux WiFi invités, WiFi personnel et IoT doivent être structurés, consultez Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
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 hameçonnage, le contrôle et commande de botnets, le contenu pour adultes, les jeux d'argent, le streaming illégal et le partage de fichiers en pair-à-pair. Les politiques basées sur les catégories sont plus faciles à maintenir et capturent automatiquement les nouveaux domaines à mesure que les informations sur les menaces sont mises à jour.
Fréquence de mise à jour des informations sur les menaces
Sélectionnez un fournisseur de filtrage DNS qui met à jour les informations sur les 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 à flux rapide. Purple Shield met à jour ses informations sur les menaces en continu, reflétant la même détection basée sur l'IA qui offre un avantage de 10 jours sur les 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 facilite également les audits de conformité, démontrant aux évaluateurs PCI-DSS et aux auditeurs GDPR que vous avez mis en place des contrôles actifs.
La plateforme de WiFi Analytics de Purple s'intègre à Shield pour fournir 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 qu'ils accèdent à des contenus qui devraient être bloqués. Les journaux du pare-feu affichent des requêtes DNS vers 8.8.8.8 ou 1.1.1.1 depuis le 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.
Solution : Implémentez une règle de pare-feu rejetant tout le trafic sortant des ports UDP/TCP 53 depuis le VLAN invité vers toute adresse IP autre que celle de votre moteur de filtrage.
Échec d'authentification sur le Captive Portal
Symptôme : Les invités ne peuvent pas terminer le processus de connexion. La page du Captive Portal ne se charge pas ou les boutons de connexion via les réseaux sociaux 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 figurent sur une liste de catégories bloquées.
Solution : 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 processus de connexion dans un environnement de pré-production avant de déployer des 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 entièrement le filtrage.
Cause : Les navigateurs ou les applications utilisent DoH, acheminant des requêtes DNS chiffrées sur le port 443 vers des résolveurs externes.
Solution : 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 de résolveurs DoH connus.
Perturbation du VLAN opérationnel
Symptôme : Les terminaux de point de vente ou les systèmes de gestion de propriété perdent la 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 à des 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 : Bloquer le streaming illégal, le partage en pair-à-pair et le trafic de botnets automatisés 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 garantir la sécurité des données) et soutient les exigences de la certification Cyber Essentials en matière de protection contre les logiciels malveillants.
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'accueil 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 pour la marque et d'une considération juridique dans de nombreuses juridictions.
Pour obtenir des conseils de déploiement spécifiques à votre 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 threat intelligence 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 point de terminaison 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 de botnet sans alerter le logiciel malveillant de sa détection.
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 flux de connexion au captive portal.
Doit inclure tous les domaines de fournisseurs d'identité (Microsoft Entra ID, Google Workspace, Okta) et les ressources du captive portal 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 à l'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 de DoH afin de 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.
Crucial pour isoler le trafic invité des systèmes opérationnels. L'exigence PCI DSS 1.3 stipule que les environnements de données de titulaires de cartes doivent être séparés des réseaux non sécurisés, y compris le 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 capture de données de première partie.
Nécessite une configuration minutieuse du Walled Garden pour fonctionner correctement en parallèle 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 au niveau d'un point d'inspection, permettant un filtrage sensible au contenu mais introduisant une surcharge de traitement importante.
Peu pratique pour les réseaux d'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 threat intelligence
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 threat intelligence déterminent la rapidité avec laquelle un filtre DNS réagit aux nouvelles menaces zero-day.
Domaine zero-day
Un domaine récemment enregistré utilisé dans une campagne de logiciels malveillants ou de phishing avant qu'il n'apparaisse sur une liste de blocage standard.
Les campagnes d'attaque modernes utilisent des domaines jetables 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 signalements.
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 portail captif et son système de gestion hôtelière (PMS) fonctionne sur la même infrastructure de commutateurs physiques. Après avoir activé le filtrage DNS, les invités 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 la résoudre ?
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 invités ne s'authentifient, créant une situation de blocage où les invités 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 aux locataires. 2. Vérifiez que le propre domaine du portail captif 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 de blocage de contenu restrictif uniquement aux sessions post-authentification sur le VLAN invité (VLAN 20). 5. Testez l'ensemble du flux de connexion sur chaque propriété concernée avant de clôturer l'incident.
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 l'étendue 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 n'indiquent aucune requête bloquée de la part de ces appareils. Quel est le défaut architectural 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 configurés en dur (8.8.8.8, 1.1.1.1) ou en utilisant le DNS over HTTPS. Étant donné que 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 adresse IP autre que les adresses IP approuvées du moteur de filtrage. 2. Identifiez et bloquez les plages IP des principaux fournisseurs de DoH (Cloudflare, Google, NextDNS) au niveau du pare-feu pour empêcher tout 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.
Questions d'entraînement
Q1. Une chaîne de vente au détail déploie un filtre DNS cloud dans 150 magasins. Ils mettent à jour l'étendue DHCP sur tous les VLAN d'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 en provenance de ces magasins. Quelle est la cause la plus probable et quelle est la solution ?
Conseil : Réfléchissez à la manière 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 en utilisant 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 IP approuvées du moteur de filtrage. De plus, bloquez les plages d'adresses IP des fournisseurs de 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 la phase de test, les participants ne parviennent pas à terminer le processus 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 finalisé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 d'authentification et de protocole OAuth de Google Workspace requis à la liste d'autorisation de pré-authentification dans la politique de filtrage DNS. Le propre domaine du Captive Portal ainsi que toutes les ressources de type CDN doivent également être ajoutés à la liste d'autorisation. Appliquez la politique restrictive de filtrage de contenu 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 son site d'une capacité de 60 000 places. L'équipe réseau s'inquiète de la latence lors des pics d'événements. Quelle approche est la plus appropriée et pourquoi ?
Conseil : Prenez en compte 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, à l'échelle de 60 000 utilisateurs simultanés, introduirait une latence importante et exigerait un matériel excessivement coûteux à 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 aux trafics 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 : La section PCI DSS Requirement 1.3 couvre les contrôles d'accès réseau entre réseaux de confiance et réseaux 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 cartes) ne peut pas être accédé depuis le VLAN 20 (réseau invité), ce qui satisfait à la section PCI DSS Requirement 1.3. 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, prouvant l'application forcée du filtrage DNS. 4. La documentation de la politique du filtre DNS démontrant que les catégories de blocage des logiciels malveillants et des réseaux de robots (botnets) sont actives sur le VLAN 20. 5. Les journaux du filtre DNS montrant les événements de requêtes bloquées, prouvant que le contrôle est actif et surveillé.
Questions fréquentes
How does enterprise DNS filtering protect guest and corporate WiFi networks?
Enterprise DNS filtering secures networks at the resolution layer before an HTTP or TCP connection is established. When a user or background application requests an IP address for a domain, the recursive resolver evaluates the query against real-time threat intelligence. Malicious domains associated with malware, ransomware command-and-control (C2), or phishing are instantly sinkholed, protecting unmanaged guest devices and corporate assets with negligible latency.
How does DNS filtering prevent DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) security bypasses?
Modern mobile devices and browsers often default to encrypted DoH or DoT, which bypasses local network DNS forwarders. Enterprise venues counter this by blocking outbound TCP port 853 (DoT) and enforcing Layer 7 firewall rules or Access Control Lists (ACLs) that drop traffic to known public DoH resolver IPs (such as Cloudflare 1.1.1.1 and Google 8.8.8.8), forcing client devices to use the venue protective DNS resolver.
What is the difference between recursive DNS resolution and Anycast protective DNS filtering?
Standard recursive DNS queries travel through multi-tier root and authoritative nameservers without security evaluation, exposing networks to poisoned cache entries and malicious destinations. Anycast protective DNS routes queries to globally distributed Anycast data center nodes that cross-reference domains against real-time threat feeds, returning cached results in under 15ms while neutralizing cyber threats and policy violations at the edge.
How does DNS filtering enforce CIPA (Children's Internet Protection Act) compliance across venues?
Under CIPA and educational safe-browsing mandates, venues providing public access must block visual depictions of obscenity, child sexual abuse material (CSAM), and harmful content. Protective DNS enforces these requirements network-wide without installing device certificates or endpoint software, categorizing billions of domains and enforcing Google and YouTube SafeSearch restrictions across all connected devices.
Can DNS filtering reduce venue internet bandwidth consumption and firewall compute load?
Yes. By blocking malicious payload downloads, high-bandwidth streaming domains, and intrusive ad-tracking networks at the initial DNS lookup phase, the network prevents large TCP payload transfers before they start. Venues deploying protective DNS typically observe a 6% to 12% reduction in overall WAN traffic and substantially reduced deep-packet inspection (DPI) processing load on edge firewalls.
How does Purple Shield integrate with existing enterprise routers, access points, and captive portals?
Purple Shield operates independently of access point hardware, integrating directly via DHCP nameserver assignment or DNS forwarders on Cisco Meraki, HPE Aruba, Fortinet, Ruckus, and Ubiquiti systems. For guest WiFi, it pairs with Purple Captive Portals to enforce strict pre-authentication walled gardens, allowing authentication traffic while shielding the venue from unauthorized outbound browsing.
Continuer la lecture de cette série
Conformité CIPA : liste de contrôle de conformité pour les exploitants de sites
Vous serez en mesure de déterminer si la CIPA s'applique à votre WiFi, puis de segmenter les réseaux, d'acheminer le DNS via Purple Shield et de bloquer les voies de contournement. Vous saurez également quelles preuves conserver pour la certification du Form 486 ou du Form 479. La liste de contrôle attribue un responsable à chaque exigence, afin de garantir que rien ne manque pour la certification de votre prochaine année de financement.
Échecs de connexion en mode de transition WPA3 : une checklist de déploiement pour Cisco Meraki, HPE Aruba et Ruckus
Utilisez cette checklist pour diagnostiquer pourquoi des appareils échouent à se connecter sur un SSID en mode de transition WPA3 SAE et résoudre le problème sur Cisco Meraki, HPE Aruba ou Ruckus. Vous ferez correspondre les codes d'état 802.11 aux causes, isolerez les problèmes de PMF, 802.11r et 6GHz, et déciderez quand passer à un SSID WPA3 uniquement.
Le guide de l'entreprise sur SCEP : Déployer Simple Certificate Enrollment Protocol pour une sécurité WiFi automatisée des campus
Ce guide de référence technique fournit un schéma d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi d'entreprise via SCEP. Il aborde les différences critiques entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, ainsi que les stratégies de mitigation des risques réels pour les responsables IT.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.