Filtrage DNS pour le WiFi invité : Bloquer les logiciels malveillants et les contenus inappropriés
Ce guide fournit aux responsables informatiques, architectes réseau et directeurs de sites une référence technique définitive pour le déploiement du filtrage DNS sur les réseaux WiFi invités. Il couvre l'architecture du blocage des menaces au niveau DNS, une comparaison des principaux services DNS cloud du marché, un guide de mise en œuvre étape par étape et des études de cas réels dans les secteurs de l'hôtellerie et du commerce de détail. Le filtrage DNS est la première ligne de défense la plus rentable contre les logiciels malveillants, le phishing et les contenus inappropriés sur les réseaux publics. Ce guide prépare les équipes à le déployer en toute confiance et en conformité avec les exigences PCI-DSS, GDPR et HIPAA.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de Sécurité WiFi d'Entreprise →
Résumé exécutif
Le filtrage DNS pour le WiFi invités n'est plus une amélioration de sécurité facultative - il s'agit d'un contrôle de base pour tout site exploitant un réseau public. Lorsqu'un hôtel, un stade, une chaîne de magasins ou un centre de conférences propose un WiFi invités, il assume la responsabilité du trafic qui traverse son infrastructure. Sans filtrage au niveau DNS, ce réseau est un canal ouvert pour les rappels de logiciels malveillants, les sessions de phishing et les contenus inappropriés, exposant l'entreprise à des responsabilités réglementaires, à des risques de réputation et à une compromission potentielle du réseau.
Ce guide explique le fonctionnement technique du filtrage DNS, compare les principaux services DNS cloud disponibles pour les exploitants de sites et fournit une feuille de route de mise en œuvre structurée. Il aborde l'exigence essentielle d'application - l'interception des requêtes DNS codées en dur - que la plupart des déploiements négligent, et couvre la gestion des faux positifs, l'alignement sur la conformité et le défi émergent des protocoles DNS chiffrés. Les clients Purple peuvent superposer le filtrage DNS directement sur leur infrastructure de Guest WiFi, bénéficiant ainsi à la fois de la sécurité et de la visibilité nécessaires pour corréler les événements de menace avec les données de WiFi Analytics.
Analyse technique approfondie
Comment fonctionne le filtrage DNS
Le Domain Name System (DNS) est la couche de résolution fondamentale d'Internet. Chaque fois qu'un appareil tente de se connecter à une ressource web, il émet d'abord une requête DNS pour résoudre le nom de domaine en une adresse IP. Le filtrage DNS intercepte ce processus de résolution et évalue le domaine demandé par rapport à une base de données de renseignement sur les menaces avant de renvoyer une réponse. Si le domaine est classé comme malveillant - hébergeant un malware, fonctionnant comme un site de phishing ou servant de point de contrôle et de commande (C2) de botnet - le résolveur renvoie une adresse non routable ou redirige le client vers une page de blocage. La connexion TCP/IP vers l'hôte malveillant n'est jamais établie.
Cette architecture offre un avantage d'efficacité fondamental par rapport aux pare-feu d'inspection de paquets. Un pare-feu doit inspecter les données après l'établissement d'une connexion ; le filtrage DNS empêche la connexion de démarrer. Pour les environnements de WiFi invités où des centaines d'appareils non approuvés peuvent être actifs simultanément, cette interception en amont réduit considérablement le volume de trafic malveillant qui atteint le périmètre du réseau.
Ce que le filtrage DNS peut et ne peut pas bloquer
Comprendre la portée du filtrage DNS est essentiel pour définir des attentes précises avec les parties prenantes.
| Catégorie de menace | Efficacité du filtrage DNS | Notes |
|---|---|---|
| Domaines de distribution de malwares | Élevée | Bloque le téléchargement de charges utiles malveillantes |
| Sites de phishing | Élevée | Bloque les pages de vol d'identifiants |
| Communications C2 de botnets | Élevée | Neutralise les malwares déjà présents sur l'appareil |
| Serveurs de staging de ransomware | Élevée | Empêche la récupération de la charge utile et l'échange de clés |
| Contenu adulte / inapproprié | Élevée | Filtrage par catégorie |
| Pools de minage de cryptomonnaies | Élevée | Bloque les connexions aux pools basées sur le domaine |
| Menaces basées sur l'IP (sans domaine) | Aucune | Nécessite un pare-feu ou un IPS |
| Charges utiles chiffrées en HTTPS | Aucune | Nécessite une inspection TLS |
| Trafic via tunnel VPN | Aucune | Nécessite le blocage des VPN au niveau du pare-feu |
| Mouvement latéral (LAN) | Aucune | Nécessite une segmentation réseau |
Le filtrage DNS n'est pas une solution de sécurité complète. C'est une couche au sein d'une architecture de défense en profondeur. Pour une sécurité complète du WiFi invités, il doit s'associer à la segmentation VLAN, à l'authentification par Captive Portal, aux contrôles de temporisation de session (voir Guest WiFi Session Timeouts: Balancing UX and Security) et, si nécessaire, à l'inspection TLS.
Filtrage DNS Cloud : Architecture et comparaison des services
Les services de filtrage DNS Cloud exploitent des réseaux anycast mondiaux, ce qui signifie que les requêtes DNS sont acheminées vers le centre de données le plus proche, minimisant ainsi la latence. Les quatre principaux services pertinents pour les exploitants de sites sont Cloudflare Gateway, Cisco Umbrella, Quad9 et NextDNS.
Cloudflare Gateway (qui fait partie de la plateforme Cloudflare Zero Trust) offre une latence de résolution inférieure à 20 ms à l'échelle mondiale, un filtrage par catégorie granulaire, l'application de politiques par site et un accord de traitement des données conforme au GDPR. Sa version gratuite prend en charge le blocage des menaces de base ; les versions payantes ajoutent un filtrage par catégorie avancé, des journaux d'activité et un accès API pour l'automatisation des politiques.
Cisco Umbrella est la référence d'entreprise pour les organisations disposant déjà d'une infrastructure Cisco. Il offre le flux de renseignements sur les menaces le plus complet - alimenté par Cisco Talos, l'une des plus grandes organisations commerciales de recherche sur les menaces - et prend en charge l'application de politiques par SSID, ce qui est essentiel pour les établissements exploitant plusieurs SSIDs (personnel, invités, IoT). Umbrella s'intègre au portefeuille de sécurité plus large de Cisco, y compris les points d'accès Meraki, simplifiant ainsi le déploiement pour les réseaux basés sur Meraki.
Quad9 (géré par la fondation suisse à but non lucratif Quad9) se concentre exclusivement sur le filtrage de sécurité plutôt que sur la catégorisation du contenu. Il bloque les domaines malveillants à l'aide de renseignements sur les menaces provenant de plus de 20 partenaires, n'enregistre aucune donnée personnellement identifiable et est gratuit. C'est un excellent choix pour les organisations ayant des exigences strictes en matière de souveraineté des données ou des budgets limités, bien qu'il ne dispose pas des fonctionnalités de filtrage par catégorie et de rapports des alternatives commerciales.
NextDNS propose un service DNS cloud hautement configurable avec une bibliothèque de filtrage par catégorie étendue, des profils par appareil et des journaux de requêtes détaillés. Son modèle de tarification - basé sur le volume mensuel de requêtes - le rend rentable pour les déploiements de petite et moyenne taille. Il prend en charge nativement le DNS-over-HTTPS et le DNS-over-TLS.
Filtrage DNS auto-hébergé : quand est-ce pertinent ?
Les solutions auto-hébergées - le plus souvent Pi-hole avec des listes de blocage commerciales, ou une implémentation BIND avec des zones de politique de réponse (RPZ) - offrent une souveraineté complète sur les données et un contrôle total des politiques. Elles conviennent aux organisations ayant des exigences réglementaires strictes concernant les données de requêtes DNS, ou à celles disposant d'équipes d'infrastructure capables de gérer la charge opérationnelle. Le compromis est important : les solutions auto-hébergées nécessitent un déploiement en haute disponibilité (configurations active-passive ou active-active - voir RADIUS Server High Availability: Active-Active vs. Active-Passive pour une discussion parallèle sur les modèles de haute disponibilité), des mises à jour manuelles des flux de menaces et une surveillance interne. Pour la majorité des exploitants d'établissements, le coût opérationnel dépasse les avantages.
DNS chiffré : considérations sur DoH et DoT
DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) chiffrent les requêtes DNS, protégeant ainsi la confidentialité des utilisateurs sur les réseaux non sécurisés. Cependant, ils créent également un vecteur de contournement pour le filtrage DNS. Un appareil configuré pour utiliser un résolveur DoH public (tel que https://cloudflare-dns.com/dns-query) chiffrera ses requêtes DNS au sein du trafic HTTPS sur le port 443, rendant inefficace l'interception traditionnelle sur le port 53.
La stratégie d'atténuation comporte deux éléments. Premièrement, configurez votre pare-feu ou votre contrôleur sans fil pour bloquer les connexions sortantes vers les points de terminaison de résolveurs DoH publics connus. Cloudflare, Google et d'autres fournisseurs publient leurs plages d'adresses IP de points de terminaison DoH. Deuxièmement, assurez-vous que le service de filtrage DNS choisi prend en charge nativement DoH et DoT, afin que les appareils configurés pour utiliser un DNS chiffré puissent être orientés vers votre résolveur sécurisé plutôt que vers un résolveur public. Cisco Umbrella et Cloudflare Gateway prennent tous deux en charge cette configuration.
-
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.
Guide de mise en œuvre
Étape 1 : Sélectionnez votre service de filtrage DNS
Les critères de sélection doivent être guidés par trois facteurs : l'échelle, la granularité des politiques et les exigences de conformité. Le cadre de travail suivant s'applique à la plupart des déploiements sur site.
| Échelle de déploiement | Service recommandé | Justification |
|---|---|---|
| < 100 utilisateurs simultanés | Cloudflare Gateway (gratuit) ou Quad9 | Coût nul, blocage des menaces adéquat |
| 100 à 500 utilisateurs simultanés | NextDNS (payant) ou Cloudflare Gateway | Filtrage par catégorie, tableau de bord de rapports |
| Plus de 500 utilisateurs simultanés, site unique | Cisco Umbrella Essentials | Politique par SSID, SLA entreprise |
| Entreprise multisite | Cisco Umbrella Advantage ou Cloudflare Gateway Enterprise | Gestion centralisée des politiques, automatisation par API |
| Secteur de la santé / environnements réglementés | Cisco Umbrella ou RPZ hébergé localement | Souveraineté des données, journalisation d'audit HIPAA |
Étape 2 : Configurer le DHCP sur le SSID invité
Accédez à l'interface de gestion de votre contrôleur sans fil ou de votre point d'accès et configurez la plage DHCP pour le SSID invité afin d'attribuer les adresses IP du résolveur du service de filtrage DNS. N'utilisez pas les serveurs DNS par défaut du fournisseur d'accès Internet en amont. Pour Cloudflare Gateway, utilisez les adresses IP de résolveur fournies dans votre tableau de bord Zero Trust. Pour Cisco Umbrella, utilisez les adresses IP du résolveur Umbrella (208.67.222.222 et 208.67.220.220 pour les déploiements existants ; adresses IP d'appliance virtuelle pour les déploiements modernes).
Pour les réseaux gérés par Purple, cette configuration est appliquée au niveau du contrôleur, garantissant une application cohérente des politiques sur tous les points d'accès du SSID invité.
Étape 3 : Appliquer l'interception DNS à la périphérie du réseau
Il s'agit de l'étape la plus fréquemment négligée. Configurez votre pare-feu ou votre contrôleur sans fil pour intercepter tout le trafic sortant sur le port UDP 53 et le port TCP 53 et le rediriger vers votre résolveur de filtrage DNS. Cela empêche les appareils dotés de paramètres DNS codés en dur de contourner le filtre. Sur Cisco Meraki, cela est mis en œuvre via une règle de mise en forme du trafic (traffic shaping). Sur Fortinet FortiGate, utilisez une politique de proxy DNS. Sur pfSense ou OPNsense, configurez une règle de redirection NAT. De plus, bloquez les connexions sortantes vers les points de terminaison des résolveurs DoH publics connus sur le port 443 pour empêcher le contournement du DNS chiffré. Maintenez une liste régulièrement mise à jour des plages d'adresses IP des résolveurs DoH.
Étape 4 : Définir votre politique de filtrage
Commencez par la base de sécurité - des catégories qui doivent être bloquées de manière universelle, quel que soit le type de lieu :
- Distribution de logiciels malveillants
- Phishing et collecte d'identifiants
- Commande et contrôle de botnets (C2)
- Serveurs de ransomware
- Cryptomining
Appliquez ensuite des catégories de contenu spécifiques au lieu en fonction de votre politique d'utilisation acceptable :
| Type de lieu | Catégories supplémentaires recommandées à bloquer |
|---|---|
| Commerce de détail familial / Centre commercial | Contenu pour adultes, jeux d'argent, contenu extrémiste |
| Hôtel (réseau invités) | Matériel d'abus sexuel sur enfants (obligatoire), contenu extrémiste |
| Stade / Salle de spectacle | Contenu pour adultes, contenu extrémiste, streaming illégal |
| Centre de conférence | Partage de fichiers en peer-to-peer, proxys d'anonymisation |
| Établissement de santé | Contenu pour adultes, jeux d'argent, réseaux sociaux (facultatif) |
| Secteur public / Bibliothèque | Contenu pour adultes, contenu extrémiste, jeux d'argent |
Étape 5 : Tester et valider
Avant la mise en service, validez la configuration à l'aide d'un appareil de test connecté sur le SSID invité. Tentez d'accéder à un domaine de test de logiciel malveillant connu (la plupart des services de filtrage DNS fournissent des domaines de test à cet effet). Confirmez que la page de blocage s'affiche. Tentez d'utiliser un serveur DNS codé en dur (par exemple, nslookup google.com 8.8.8.8) et confirmez que la requête est interceptée et redirigée. Testez le contournement DoH en configurant un navigateur pour utiliser un résolveur DoH public et confirmez que la connexion est bloquée.
Étape 6 : Surveiller, ajuster et générer des rapports
Examinez le tableau de bord de filtrage DNS quotidiennement pendant les quatre premières semaines. Les indicateurs clés à suivre incluent le nombre total de requêtes, les requêtes bloquées par catégorie, les principaux domaines bloqués et les rapports de faux positifs des utilisateurs. Établissez un processus d'examen de la liste blanche - tout domaine ajouté à la liste blanche doit être documenté avec une justification commerciale et examiné trimestriellement. Planifiez des rapports mensuels pour le CISO ou le directeur informatique indiquant les volumes de menaces et la répartition des catégories.
-
Bonnes pratiques
Segmentez les politiques DNS des invités et de l'entreprise. N'appliquez jamais la même politique de filtrage DNS aux SSID des invités et à ceux du personnel. Les réseaux d'invités nécessitent un filtrage de contenu plus strict ; les réseaux du personnel peuvent nécessiter l'accès à des catégories qui seraient inappropriées pour des utilisateurs publics. Cisco Umbrella et Cloudflare Gateway prennent tous deux en charge des politiques par emplacement ou par réseau.
Alignez votre politique d'utilisation acceptable avec votre configuration de filtrage DNS. La politique de filtrage affichée dans les conditions d'utilisation de votre Captive Portal doit refléter fidèlement ce qui est bloqué. Un décalage crée un risque juridique. Travaillez avec votre équipe juridique pour vous assurer que la politique d'utilisation acceptable mentionne explicitement le filtrage de contenu au niveau DNS. Le Captive Portal de Purple Guest WiFi prend en charge un texte de politique d'utilisation acceptable personnalisable à cet effet.
Implémentez des résolveurs DNS redondants. Configurez deux adresses IP de résolveur dans votre étendue DHCP - une principale et une secondaire. Les services Cloud DNS fournissent plusieurs points de terminaison de résolveur pour la redondance. Un point de défaillance unique dans la résolution DNS rendra l'ensemble du réseau WiFi invité non fonctionnel.
Enregistrez les requêtes DNS conformément à votre politique de rétention des données. Les journaux de requêtes DNS sont précieux pour les enquêtes de sécurité, mais peuvent constituer des données personnelles en vertu du GDPR s'ils peuvent être liés à un individu. Assurez-vous que l'accord de traitement des données de votre service de filtrage DNS est compatible avec vos obligations GDPR, et configurez les périodes de rétention des journaux en conséquence.
Examinez votre architecture SD-WAN pour la cohérence de la politique DNS. Pour les déploiements multi-sites, la politique de filtrage DNS doit être appliquée de manière cohérente sur tous les sites. Les plateformes SD-WAN peuvent centraliser la gestion de la politique DNS - voir The Core SD WAN Benefits for Modern Businesses pour une discussion plus large sur le rôle du SD-WAN dans la gestion des réseaux d'entreprise.
Considérez l'interaction avec les analyses de vente au détail. Dans les environnements de vente au détail Retail, les journaux de filtrage DNS peuvent compléter les données de WiFi Analytics pour identifier les schémas de comportement inhabituels des appareils. Un appareil générant un volume anormalement élevé de requêtes DNS bloquées peut indiquer un appareil compromis qui mérite une enquête.
Dépannage et atténuation des risques
Modes de défaillance courants
Contournement DNS via des résolveurs codés en dur. Symptôme : les journaux de filtrage DNS affichent de faibles volumes de requêtes par rapport au nombre d'appareils connectés. Cause racine : les appareils utilisent des serveurs DNS codés en dur qui contournent les résolveurs attribués par le DHCP. Résolution : implémentez l'interception et la redirection du port 53 au niveau du pare-feu.
Faux positifs bloquant des services légitimes. Symptôme : plaintes des utilisateurs concernant l'inaccessibilité de sites Web spécifiques. Cause racine : le service de filtrage DNS a mal catégorisé un domaine légitime. Résolution : vérifiez la catégorisation du domaine dans l'outil de recherche du service, soumettez une demande de recatégorisation et ajoutez le domaine à la liste blanche en attendant la correction.
Contournement DoH. Symptôme : certains appareils semblent contourner le filtrage malgré l'interception du port 53. Cause racine : l'appareil utilise le DNS-over-HTTPS vers un résolveur public. Résolution : bloquez les connexions sortantes vers les plages d'adresses IP des résolveurs DoH connus au niveau du pare-feu.
Échecs de validation DNSSEC. Symptôme : certains domaines renvoient des réponses SERVFAIL. Cause racine : le service de filtrage DNS effectue une validation DNSSEC et les enregistrements DNSSEC du domaine sont mal configurés. Résolution : vérifiez la configuration DNSSEC du domaine à l'aide d'un analyseur DNSSEC en ligne ; si le domaine est légitime, ajoutez-le à la liste blanche.Une latence DNS élevée entraîne des chargements de pages lents. Symptôme : les utilisateurs signalent une navigation lente malgré une bande passante adéquate. Cause d'origine : le résolveur de filtrage DNS est géographiquement éloigné ou subit une charge importante. Résolution : vérifiez que le routage anycast fonctionne correctement ; envisagez de passer à un résolveur disposant d'un centre de données plus proche de votre site.
Cadre d'atténuation des risques
Le registre des risques suivant résume les principaux risques associés au déploiement du filtrage DNS et leurs atténuations.
| Risque | Probabilité | Impact | Atténuation |
|---|---|---|---|
| Contournement du DNS via des résolveurs codés en dur | Élevée | Élevé | Interception et redirection du port 53 |
| Faux positifs bloquant des services essentiels à l'entreprise | Moyenne | Élevé | Processus de liste blanche, tests de pré-déploiement |
| Panne d'un seul résolveur entraînant une panne de réseau | Moyenne | Élevé | Configuration de résolveur redondant |
| Contournement DoH contournant le filtre | Moyenne | Moyen | Bloquer les terminaux DoH connus au niveau du pare-feu |
| Non-conformité GDPR via une journalisation DNS excessive | Faible | Élevé | Politique de rétention des données, examen de la DPA |
| Obsolescence du flux de renseignements sur les menaces (auto-hébergé) | Faible | Élevé | Mises à jour automatisées des flux, service cloud privilégié |
ROI et impact commercial
Quantification de la valeur du filtrage DNS
Le retour sur investissement du filtrage DNS sur le WiFi pour les invités est dicté par trois facteurs : l'évitement des coûts liés aux incidents, la réduction des coûts de conformité et l'efficacité opérationnelle.
L'évitement des coûts liés aux incidents est le moteur le plus important. Un seul incident de malware provenant d'un réseau d'invités - entraînant un avis d'abus de FAI, une enquête réglementaire ou des dommages à la réputation - peut coûter des dizaines de milliers de livres sterling en remédiation, frais juridiques et perte d'activité. Les services de filtrage DNS cloud coûtent entre zéro et quelques centaines de livres par mois pour la plupart des déploiements sur site. Le rapport coût-bénéfice est extrêmement convaincant.
La réduction des coûts de conformité est de plus en plus pertinente à mesure que les cadres réglementaires se renforcent. Le PCI DSS v4.0, le GDPR et l'Online Safety Act du Royaume-Uni imposent tous des obligations en matière de surveillance du réseau et de contrôle du contenu. Le filtrage DNS fournit des preuves documentées de contrôles de sécurité proactifs, ce qui réduit la portée et le coût des audits de conformité.
L'efficacité opérationnelle est un avantage moins évident mais bien réel. Le filtrage DNS réduit le volume de trafic malveillant atteignant votre pare-feu et votre infrastructure de surveillance de la sécurité, réduisant ainsi la fatigue liée aux alertes et la charge opérationnelle liée à l'investigation des fausses alertes.
Résultats attendus
Sur la base des déploiements dans les secteurs de l'Hôtellerie, du Commerce de détail, de la Santé et des Transports, les organisations qui déploient le filtrage DNS sur leur WiFi pour les invités peuvent s'attendre aux résultats suivants sous 90 jours :
| Métrique | Résultat typique |
|---|---|
| Requêtes de domaines malveillants bloquées par jour (pour 100 appareils) | 50 - 200 |
| Réduction des avis d'abus de FAI | 80 - 100 % |
| Réduction des incidents de sécurité sur le réseau invités | 60 - 80 % |
| Réduction des constatations d'audit de conformité | 20 à 40 % |
Pour les sites exploitant déjà la plateforme de Guest WiFi de Purple, l'intégration du filtrage DNS ne nécessite aucun matériel supplémentaire et un temps de configuration minimal - généralement deux à quatre heures pour un déploiement sur un site unique, et un à deux jours pour un déploiement en entreprise multi-sites avec personnalisation des politiques par site.
Définitions clés
Filtrage DNS
Un contrôle de sécurité qui intercepte les requêtes DNS et bloque la résolution des domaines classés comme malveillants ou enfreignant les règles, empêchant ainsi l'appareil client d'établir une connexion avec l'hôte cible.
Les équipes informatiques y sont confrontées lorsqu'elles évaluent les contrôles de sécurité du WiFi invité. Il s'agit de la première ligne de défense la plus rentable contre les logiciels malveillants, le phishing et les contenus inappropriés sur les réseaux ouverts au public.
Réseau Anycast
Une méthodologie de routage dans laquelle plusieurs serveurs partagent la même adresse IP, et les requêtes des clients sont automatiquement acheminées vers le serveur le plus proche en fonction de la topologie du réseau. Utilisé par les fournisseurs de DNS cloud pour minimiser la latence des requêtes à l'échelle mondiale.
Pertinent lors de l'évaluation des services de filtrage DNS basés sur le cloud. Anycast garantit que les requêtes DNS provenant d'un établissement à Manchester sont résolues par un centre de données au Royaume-Uni et non aux États-Unis, maintenant la latence en dessous de 20 ms.
Response Policy Zone (RPZ)
Extension DNS permettant à un résolveur de remplacer les réponses DNS standard en fonction d'une zone de politique définie localement. Utilisée dans les implémentations de filtrage DNS auto-hébergées pour bloquer ou rediriger les requêtes vers des domaines spécifiques.
Rencontré dans les déploiements de filtrage DNS auto-hébergés utilisant BIND ou Unbound. La zone RPZ offre un contrôle précis des réponses DNS sans nécessiter de service cloud commercial.
DNS-over-HTTPS (DoH)
Protocole qui chiffre les requêtes DNS au sein du trafic HTTPS sur le port 443, protégeant ainsi la confidentialité des requêtes, mais créant également un vecteur de contournement potentiel pour les systèmes de filtrage DNS qui reposent sur l'interception du port 53.
De plus en plus important à mesure que les navigateurs et les systèmes d'exploitation adoptent le DoH par défaut. Les équipes informatiques doivent prendre en compte le contournement du DoH lors du déploiement du filtrage DNS sur les réseaux invités.
DNS-over-TLS (DoT)
Protocole qui chiffre les requêtes DNS à l'aide de TLS sur le port 853, offrant des avantages de confidentialité similaires au DoH mais utilisant un port dédié plus facile à détecter et à gérer en périphérie de réseau.
Moins couramment utilisé que le DoH sur les appareils grand public, mais pertinent dans les environnements d'entreprise. Le trafic DoT sur le port 853 peut être bloqué ou redirigé au niveau du pare-feu plus facilement que le DoH.
Flux de renseignements sur les menaces
Base de données continuellement mise à jour contenant les domaines, adresses IP et URL malveillants connus, gérée par des chercheurs en sécurité et utilisée par les services de filtrage DNS pour classifier et bloquer les menaces en temps réel.
La qualité et la fraîcheur du flux de renseignements sur les menaces constituent le principal différenciateur entre les services de filtrage DNS. Les fournisseurs cloud comme Cisco Talos traitent des milliards de requêtes chaque jour pour maintenir la précision de leur flux.
Commande et contrôle de botnets (C2)
Serveur ou domaine utilisé par les opérateurs de logiciels malveillants pour envoyer des instructions aux appareils compromis (bots) et recevoir des données exfiltrées. Le filtrage DNS bloque la résolution de domaine C2, perturbant ainsi le fonctionnement des logiciels malveillants déjà installés sur un appareil invité.
Crucial pour la sécurité du WiFi invité car un appareil invité peut déjà être infecté avant de se connecter au réseau. Le filtrage DNS empêche le logiciel malveillant de communiquer avec ses opérateurs, limitant ainsi les dommages.
DNSSEC (DNS Security Extensions)
Suite de spécifications de l'IETF qui ajoute des signatures cryptographiques aux réponses DNS, permettant aux résolveurs de vérifier que les réponses n'ont pas été altérées en transit. Distincte du filtrage DNS mais complémentaire.
Les équipes informatiques peuvent rencontrer des échecs de validation DNSSEC lors du déploiement du filtrage DNS si le service de filtrage effectue une validation DNSSEC et que les enregistrements d'un domaine sont mal configurés. Comprendre la distinction entre DNSSEC et le filtrage DNS évite toute confusion lors du diagnostic.
Politique d'utilisation acceptable (AUP)
Document de politique formel qui définit les utilisations autorisées et interdites d'un réseau ou d'une ressource informatique. Pour le WiFi invité, cette politique est généralement présentée sur le Captive Portal et doit refléter fidèlement les catégories de filtrage DNS en vigueur.
Les équipes juridiques exigent que la politique d'utilisation acceptable fasse explicitement référence au filtrage de contenu au niveau DNS afin d'établir une position défendable en vertu du GDPR et du UK GDPR. Un décalage entre cette politique et la politique de filtrage réelle crée un risque juridique.
Politique par SSID
Capacité de configuration du filtrage DNS qui permet d'appliquer différentes politiques de filtrage à différents noms de réseaux sans fil (SSID) - par exemple, une politique de contenu stricte sur le SSID invité et une politique axée uniquement sur la sécurité sur le SSID du personnel.
Essentiel pour les établissements exploitant plusieurs SSID. Sans prise en charge d'une politique par SSID, les mêmes règles de filtrage s'appliquent à tous les réseaux, ce qui restreint excessivement l'accès du personnel ou ne protège pas assez l'accès des invités.
Exemples concrets
Un groupe hôtelier de 12 établissements (350 chambres au total) au Royaume-Uni reçoit des notifications d'abus de son FAI concernant du trafic de logiciels malveillants provenant d'appareils d'invités. Leur WiFi invité est géré via Purple. Ils doivent déployer un filtrage DNS sur l'ensemble des établissements sous 30 jours, avec un impact minimal pour les clients et sans matériel supplémentaire sur site.
L'approche recommandée consiste à déployer Cloudflare Gateway (Zero Trust) en tant que service de filtrage DNS cloud, configuré au niveau du contrôleur sans fil pour l'SSID invité sur l'ensemble des 12 établissements.
Semaine 1 - Configuration du service : Créez un compte Cloudflare Zero Trust et configurez une politique de filtrage DNS avec le socle de sécurité activé (logiciels malveillants, phishing, botnets C2, ransomwares). Ajoutez les catégories d'utilisation acceptable de l'hôtel : contenu pour adultes et matériel extrémiste. Configurez la politique pour afficher une page de blocage personnalisée aux couleurs de l'hôtel, avec son logo et un numéro de contact pour les clients qui pensent qu'un site a été bloqué par erreur.
Semaine 2 - Configuration réseau : Pour chaque établissement, accédez à l'interface de gestion du contrôleur sans fil et mettez à jour la plage DHCP pour l'SSID invité afin d'attribuer les IP de résolution de Cloudflare Gateway. Configurez le pare-feu de chaque établissement pour intercepter le trafic sortant du port 53 et le rediriger vers le résolveur Cloudflare. Enregistrez l'IP publique sortante de chaque établissement dans le tableau de bord Cloudflare Zero Trust pour associer les requêtes à la bonne politique locale.
Semaine 3 - Tests et validation : Sur deux établissements pilotes, connectez un appareil de test à l'SSID invité et validez : (a) le domaine de test malveillant est bloqué, (b) la requête DNS codée en dur est interceptée, (c) les services hôteliers légitimes (moteur de réservation, services de streaming) sont accessibles. Examinez le tableau de bord Cloudflare pour identifier les faux positifs et configurez la liste blanche si nécessaire.
Semaine 4 - Déploiement global et surveillance : Déployez sur les 10 établissements restants. Configurez des rapports hebdomadaires par e-mail depuis le tableau de bord Cloudflare vers le directeur informatique du groupe. Établissez un processus de révision de la liste blanche avec un contact désigné dans chaque établissement.
Résultat attendu : Les notifications d'abus du FAI cessent sous 30 jours. Le tableau de bord révèle une moyenne de 340 requêtes malveillantes bloquées par jour sur l'ensemble du parc. Un établissement présente un volume anormalement élevé de requêtes bloquées, localisé sur un appareil IoT compromis dans une salle de conférence, qui est alors isolé et corrigé.
Une chaîne de magasins comptant 200 points de vente à travers l'Europe rencontre deux problèmes sur son réseau WiFi invité en magasin : les clients accèdent à des contenus pour adultes et à des services de streaming vidéo, ce qui entraîne des risques pour la réputation de la marque et une congestion du réseau. Le directeur informatique a besoin d'une solution qui applique un filtrage de contenu de manière cohérente dans tous les magasins, s'intègre à l'infrastructure Cisco Meraki existante et fournit des preuves documentées de conformité avec le GDPR et la loi britannique sur la sécurité en ligne (Online Safety Act).
Déployer Cisco Umbrella Advantage, intégré à l'infrastructure Meraki existante via l'intégration Meraki-Umbrella.
Phase 1 - Conception de la politique : Définir deux politiques de filtrage DNS : (a) Politique SSID Invité - base de sécurité à laquelle s'ajoute le blocage des contenus pour adultes, du streaming vidéo, du partage de fichiers en pair à pair et des proxys d'anonymisation ; (b) Politique SSID Personnel - base de sécurité uniquement. Collaborer avec l'équipe juridique pour mettre à jour la charte d'utilisation du Captive Portal afin de faire explicitement référence au filtrage de contenu au niveau DNS.
Phase 2 - Intégration Meraki : Dans le tableau de bord Cisco Umbrella, activer l'intégration Meraki et lier l'organisation Umbrella au tableau de bord Meraki. Assigner la politique SSID Invité à tous les SSID du réseau invité sur l'ensemble des 200 magasins. L'intégration Meraki configure automatiquement le transfert DNS vers les résolveurs Umbrella - aucune configuration DHCP manuelle n'est requise par magasin.
Phase 3 - Application : Configurer Meraki pour bloquer le trafic sortant du port 53 vers les résolveurs non-Umbrella à l'aide d'une règle de modelage du trafic (traffic shaping). Activer le proxy intelligent d'Umbrella pour inspecter et bloquer le trafic DoH vers les résolveurs publics connus.
Phase 4 - Documentation de conformité : Exporter mensuellement la configuration de la politique d'Umbrella et les journaux d'audit. Les stocker dans le SMSI (Système de Management de la Sécurité de l'Information) de l'organisation comme preuve des contrôles de filtrage de contenu. S'assurer que l'accord de traitement des données d'Umbrella est signé et déposé auprès du DPO.
Résultat attendu : L'utilisation du réseau invité diminue de 35 % grâce au blocage du streaming vidéo. Zéro incident lié à des contenus pour adultes signalé au cours des 12 mois suivant le déploiement. L'audit de conformité confirme que les contrôles de filtrage documentés répondent aux obligations de la loi sur la sécurité en ligne.
Questions d'entraînement
Q1. Un exploitant de centre de conférences gère trois SSIDs : "Guest-Public" (ouvert à tous les participants), "Exhibitor-WiFi" (pour les exposants du salon professionnel traitant des paiements par carte) et "Staff-Internal" (pour le personnel du site). Il souhaite déployer un filtrage DNS. Comment doit-il structurer ses politiques de filtrage, et quelles considérations de conformité s'appliquent au SSID des exposants ?
Conseil : Prenez en compte les différents profils de risque et les exigences réglementaires pour chaque SSID. La norme PCI-DSS s'applique à tout réseau où des données de carte bancaire peuvent être présentes ou adjacentes.
Voir la réponse type
Trois politiques distinctes sont requises. Guest-Public : base de sécurité complète (malwares, phishing, C2, ransomware) plus des catégories de contenu adaptées à un environnement professionnel (contenu pour adultes, matériel extrémiste, proxys d'anonymisation). Exhibitor-WiFi : base de sécurité uniquement - ne pas appliquer de filtrage de contenu qui pourrait bloquer des outils professionnels légitimes. Point critique, ce SSID étant utilisé par des exposants traitant des paiements par carte, la norme PCI-DSS v4.0 s'applique. Le SSID doit être sur un VLAN distinct sans chemin vers l'environnement des données de titulaires de cartes, et les journaux de filtrage DNS doivent être conservés pendant au moins 12 mois dans le cadre de la piste d'audit. Envisagez de déployer Cisco Umbrella avec sa fonction de rapport de conformité PCI-DSS. Staff-Internal : base de sécurité uniquement, avec un processus d'exception documenté pour le personnel ayant besoin d'accéder à des catégories qui pourraient autrement être bloquées. La principale considération de conformité pour le SSID des exposants est que l'exigence PCI-DSS 6.4 impose la protection des applications web publiques, et l'exigence 10.2 impose la conservation des journaux d'audit - les journaux de filtrage DNS répondent en partie à cette exigence.
Q2. Un responsable informatique d'hôtel déploie Cloudflare Gateway sur le SSID invité. Après deux semaines, le tableau de bord indique que les volumes de requêtes DNS sont 40 % inférieurs à ce qui était attendu par rapport au nombre d'appareils connectés. Quelle est la cause la plus probable, et comment le responsable informatique doit-il enquêter et résoudre ce problème ?
Conseil : Pensez à ce qui pourrait amener les requêtes DNS à contourner complètement le résolveur cloud. Prenez en compte les vecteurs de contournement au niveau des appareils et du réseau.
Voir la réponse type
La cause la plus probable est qu'une proportion importante d'appareils invités utilise des résolveurs DNS codés en dur (tels que 8.8.8.8 ou 1.1.1.1) plutôt que le résolveur Cloudflare Gateway attribué par DHCP. Cela indique que la règle d'interception du port 53 au niveau du pare-feu n'a pas été configurée ou ne fonctionne pas correctement. Étapes d'investigation : (1) Sur le pare-feu, vérifiez s'il existe une règle de redirection NAT pour le trafic sortant sur le port UDP/TCP 53 depuis le VLAN invité. (2) Depuis un appareil de test sur le SSID invité, exécutez "nslookup google.com 8.8.8.8" - si cela renvoie un résultat au lieu d'être intercepté, la règle de pare-feu est manquante ou mal configurée. (3) Vérifiez les journaux du pare-feu pour le trafic sortant sur le port 53 vers des adresses IP non Cloudflare. Résolution : configurez le pare-feu pour intercepter tout le trafic sortant sur le port 53 depuis le VLAN invité et le rediriger vers les IP du résolveur Cloudflare Gateway. Après la mise en œuvre, les volumes de requêtes devraient se normaliser. De plus, vérifiez si des appareils utilisent DoH - si les volumes de requêtes restent faibles après l'interception du port 53, le contournement DoH peut être un facteur secondaire.
Q3. Le directeur informatique d'une chaîne de magasins évalue le filtrage DNS pour 200 points de vente. L'équipe de sécurité souhaite utiliser Cisco Umbrella pour son intelligence sur les menaces Talos ; l'équipe financière pousse pour une solution gratuite afin de minimiser les coûts. Les magasins utilisent des points d'accès Cisco Meraki. Comment le directeur informatique doit-il structurer l'argumentaire du ROI, et quelle est la solution recommandée ?
Conseil : Prenez en compte le coût total de possession, et pas seulement le coût des licences. Intégrez la charge opérationnelle d'une solution gratuite à grande échelle, ainsi que la valeur d'une intégration d'infrastructure native.
Voir la réponse type
Le directeur informatique doit structurer l'argument du ROI autour de trois catégories de coûts : (1) L'évitement des coûts liés aux incidents - un seul incident de malware dans un magasin, entraînant une notification d'abus du FAI, une enquête réglementaire ou la compromission d'un système de point de vente, peut coûter entre 20 000 £ et 100 000 £ en frais de remédiation et d'avocat. Sur 200 magasins, même un taux d'incident annuel de 1 % sans filtrage DNS représente un coût attendu important. (2) Le coût opérationnel - une solution gratuite comme Pi-hole nécessiterait un déploiement et une maintenance dans 200 magasins, sans gestion centralisée. À raison d'une heure de temps informatique par magasin et par trimestre, cela représente 800 heures par an, ce qui dépasse probablement le coût des licences Cisco Umbrella. (3) La valeur de l'intégration - l'intégration Meraki native de Cisco Umbrella élimine la configuration DHCP par magasin, réduit le temps de déploiement de plusieurs semaines à quelques jours et offre une gestion centralisée des règles. La solution recommandée est Cisco Umbrella Essentials ou Advantage, intégrée avec Meraki. La préoccupation de l'équipe financière concernant le coût est légitime, mais la comparaison doit porter sur le coût total de possession, et non sur le seul coût des licences. L'intégration Meraki - Umbrella est le facteur décisif : elle rend le déploiement sur 200 magasins opérationnellement viable, ce qu'aucune solution gratuite ne peut égaler à cette échelle.
Continuer la lecture de cette série
Comment segmenter de manière sécurisée les réseaux WiFi du personnel et des invités : meilleures pratiques pour les LAN d'entreprise
Ce guide fournit aux responsables informatiques et aux architectes réseau un modèle technique et indépendant des fournisseurs pour sécuriser les réseaux LAN d'entreprise en segmentant correctement le trafic WiFi du personnel et des invités. Il couvre l'authentification 802.1X, le RADIUS dans le cloud, l'isolation VLAN et la gestion du cycle de vie des identifiants nécessaires pour éliminer les phrases de passe partagées et protéger les actifs de l'entreprise.
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.
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.
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.