DNS Over HTTPS (DoH) : implications pour le filtrage du WiFi public

Bienvenue dans cette fiche technique de Purple. Je serai votre hôte pour la session d'aujourd'hui, et nous allons passer les dix prochaines minutes sur un sujet qui compromet discrètement les politiques de filtrage de contenu sur des milliers de déploiements de WiFi public en ce moment même : le DNS over HTTPS, ou DoH. Si vous gérez un WiFi pour invités dans un hôtel, un espace de vente au détail, un stade ou un établissement du secteur public, et que vous n'avez pas spécifiquement traité le DoH dans votre architecture réseau, il y a de fortes chances que votre politique de filtrage présente une faille importante. Voyons précisément en quoi consiste cette faille, pourquoi elle est importante et ce que vous pouvez faire pour y remédier. Première partie - contexte et énoncé du problème. Commençons par un rappel rapide du fonctionnement du filtrage DNS traditionnel, car pour comprendre le mécanisme de contournement, il faut d'abord comprendre ce qui est contourné. Lorsqu'un appareil invité se connecte à votre WiFi et tente de visiter un site Web, la première chose qu'il fait est d'envoyer une requête DNS - en demandant essentiellement quelle est l'adresse IP de ce domaine. Cette requête voyage via UDP ou TCP sur le port 53. Votre infrastructure réseau intercepte cette requête, l'oriente vers le résolveur DNS de votre choix, et ce résolveur compare le domaine à votre politique de filtrage. Si le domaine figure sur une liste de blocage - logiciels malveillants, contenu pour adultes, jeux d'argent, quel que soit ce que spécifie votre politique d'utilisation acceptable - le résolveur refuse de renvoyer l'adresse IP et la connexion n'a jamais lieu. C'est le fondement de tout déploiement de filtrage de contenu basé sur le DNS. C'est rentable, cela n'a pas d'impact sur le débit, et c'est l'approche standard pour les exploitants de sites depuis près d'une décennie. Le DNS over HTTPS brise ce modèle. Voici comment. Le DoH encapsule les requêtes DNS dans le trafic HTTPS standard sur le port 443. Du point de vue de votre réseau, cela ressemble exactement à n'importe quel autre trafic Web chiffré. Il n'y a aucun moyen de distinguer une requête DoH d'un utilisateur chargeant une page Web, visionnant une vidéo en streaming ou accédant à une application bancaire. La requête va directement à un résolveur DoH externe - le 8.8.8.8 de Google, le 1.1.1.1 de Cloudflare, ou bien d'autres - via un canal chiffré que votre filtre DNS ne peut pas inspecter. Le résultat ? Votre politique de filtrage DNS soigneusement configurée est totalement contournée. L'appareil résout le domaine directement, sans que votre résolveur ne voie jamais la requête. Pour autant, il ne s'agit pas d'une attaque délibérée de la part de vos invités. Dans la plupart des cas, c'est entièrement passif. Firefox a activé le DoH par défaut depuis 2020. Chrome met automatiquement à niveau les requêtes DNS vers le DoH si le résolveur configuré le prend en charge. Android 9 et versions ultérieures prennent en charge le DNS privé avec DNS over TLS par défaut. iOS prend en charge les profils de configuration DoH depuis iOS 14. Ce sont des appareils grand public courants qui font ce que leurs fabricants ont prévu. Vos invités n'essaient pas de contourner votre filtrage. Leurs appareils le font simplement de manière automatique. Deuxième partie - analyse technique approfondie. Entrons dans les détails du mécanisme. Il existe deux principaux modèles d'implémentation du DoH que vous rencontrerez sur le terrain. Le premier est le DoH au niveau de l'application, où l'application - généralement un navigateur - gère sa propre configuration DoH indépendamment des paramètres DNS du système d'exploitation. Firefox en est l'exemple type. Lorsque Firefox est installé et que le DoH est activé, il ignore complètement le résolveur DNS du système et envoie toutes ses requêtes DNS à son fournisseur DoH configuré, qui est Cloudflare par défaut. Votre serveur DNS attribué par DHCP n'a plus d'importance. Vos règles d'interception sur le port 53 n'ont plus d'importance. Firefox mène une conversation DNS totalement distincte sur le port 443 que vous ne pouvez pas voir. Le second modèle est le DoH au niveau du système d'exploitation, où le système d'exploitation lui-même gère la mise à niveau. Chrome, Windows 10 et Windows 11 adoptent cette approche. Ils vérifient si le résolveur DNS configuré sur le système - celui attribué par votre serveur DHCP - possède un point de terminaison DoH correspondant. Si c'est le cas, ils passent automatiquement au DoH. C'est ce qu'on appelle le DoH opportuniste. Si vous attribuez 8.8.8.8 comme serveur DNS invité, Chrome utilisera automatiquement le point de terminaison DoH de Google. Si vous attribuez 1.1.1.1, il utilisera le point de terminaison DoH de Cloudflare. La distinction est importante pour votre stratégie d'atténuation, sur laquelle nous reviendrons bientôt. Il existe un troisième vecteur qui mérite d'être mentionné : le DNS over TLS, ou DoT. Celui-ci fonctionne sur le port 853 et chiffre les requêtes DNS en utilisant TLS plutôt que de les encapsuler dans du HTTPS. Il est plus facile à bloquer que le DoH car il utilise un port dédié, mais il est de plus en plus courant sur les appareils Android avec le DNS privé activé. Votre stratégie d'atténuation doit traiter ces deux aspects. Voyons maintenant pourquoi il s'agit d'un risque opérationnel et de conformité, et pas seulement d'une curiosité technique. Sous le GDPR, si votre charte d'utilisation stipule que vous filtrez certaines catégories de contenu, et que vos contrôles techniques n'appliquent pas réellement cette politique, il existe un fossé entre vos engagements déclarés en matière de protection des données et de gouvernance du contenu et votre mise en œuvre technique réelle. C'est un problème de défendabilité si vous devez un jour faire face à une enquête réglementaire ou à un incident. En vertu de l'Online Safety Act du Royaume-Uni, les exploitants de sites proposant un accès public à Internet ont des obligations concernant la protection des utilisateurs - en particulier les mineurs - contre les contenus nocifs. Si le DoH contourne silencieusement votre filtrage de contenu, vous risquez de ne pas respecter ces obligations. Pour les établissements qui entrent dans le champ d'application de la norme PCI-DSS - en particulier ceux où les données de cartes de paiement transitent sur des réseaux adjacents au WiFi invité - la version 4.0 de la norme PCI-DSS exige que vous surveilliez et contrôliez le trafic DNS dans le cadre de vos contrôles de sécurité réseau. Un trafic DoH non surveillé constitue une faille dans ce cadre de contrôle. Et d'un point de vue purement sécuritaire, le DoH a été activement exploité par des logiciels malveillants. Des acteurs malveillants ont utilisé le DoH comme canal de commande et de contrôle car il se fond dans le trafic HTTPS normal. Le cheval de troie GodLua a utilisé le DoH pour ses communications de commande et de contrôle. Le logiciel malveillant PsiXBot a utilisé le service DoH de Google. Si votre surveillance de sécurité s'appuie sur la visibilité du DNS pour détecter les activités malveillantes, les zones d'ombre créées par le DoH représentent une menace réelle. Section trois - recommandations de mise en œuvre. Très bien, passons à la pratique. Il existe trois principales stratégies d'atténuation, et dans la plupart des déploiements sur site, vous voudrez mettre en œuvre une combinaison de ces trois méthodes. Stratégie un : bloquer les endpoints des résolveurs DoH connus au niveau du pare-feu. Il s'agit de votre première ligne de défense et de l'option la plus immédiatement déployable. Maintenez une liste de blocage des adresses IP et des domaines de résolveurs DoH connus - Google, Cloudflare, Quad9, NextDNS, AdGuard, et d'autres - et refusez le trafic HTTPS sortant vers ces endpoints depuis votre VLAN invité. L'IETF et divers fournisseurs de sécurité publient et maintiennent ces listes. Le projet curl sur GitHub maintient une liste complète de résolveurs DoH connus qui constitue un bon point de départ. Cette approche traite la majorité du trafic DoH car, comme l'ont montré les recherches du Software Engineering Institute de Carnegie Mellon, la majeure partie du trafic DoH est dirigée vers un petit nombre de résolveurs bien connus. Les utilisateurs qui s'y connaissent suffisamment en DNS pour configurer un résolveur DoH personnalisé représentent une infime minorité. La limite de cette approche est qu'il s'agit d'une liste de blocage, et que les listes de blocage nécessitent de la maintenance. De nouveaux résolveurs DoH apparaissent régulièrement. Mais combinée aux autres stratégies, elle offre une couverture solide. Stratégie deux : inspection TLS sur votre pare-feu de nouvelle génération. Les pare-feu de nouvelle génération de fournisseurs tels que Palo Alto Networks, Fortinet, Check Point, et Cisco Firepower prennent en charge l'inspection TLS - également appelée inspection SSL ou inspection approfondie des paquets. Lorsqu'elle est activée, le pare-feu agit comme un intermédiaire (man-in-the-middle) pour le trafic HTTPS, en le décryptant, en inspectant la charge utile, puis en le re-chiffrant avant de le transmettre. Cela permet au pare-feu d'identifier le trafic DoH même lorsqu'il est dirigé vers un résolveur inconnu. L'App-ID de Palo Alto peut identifier spécifiquement le trafic DoH et lui appliquer une politique. Le FortiGate de Fortinet dispose d'une capacité similaire. L'étape de configuration clé consiste à s'assurer que le trafic de votre VLAN invité est acheminé via la politique d'inspection. La considération opérationnelle ici est la confiance dans les certificats. Pour que l'inspection TLS fonctionne sur les appareils invités, ces derniers doivent faire confiance à votre certificat d'inspection. Sur les appareils d'entreprise gérés, c'est simple : vous déployez le certificat via une MDM. Sur les appareils invités non gérés, c'est plus complexe. L'approche pratique pour le WiFi invité consiste à utiliser le flux d'acceptation du Captive Portal pour informer les utilisateurs que le trafic peut être inspecté à des fins de filtrage de contenu, et à s'appuyer sur la combinaison du blocage des résolveurs DoH et de l'interception DNS comme contrôles principaux, avec l'inspection TLS comme couche secondaire pour les environnements à plus haut risque. Stratégie trois : forcer l'interception et la redirection DNS. Configurez votre pare-feu ou votre contrôleur sans fil pour intercepter tout le trafic DNS sortant sur les ports UDP et TCP 53 et le rediriger vers votre résolveur DNS conforme. Cela n'arrête pas le DoH, mais cela garantit que tout trafic DNS qui bascule sur le port 53 - parce que le DoH a échoué ou n'était pas disponible - est capturé et filtré. Combinez cela avec le blocage du port 853 sortant depuis le VLAN invité pour empêcher le DNS over TLS de contourner vos contrôles. Pour les terminaux gérés - appareils d'entreprise, appareils du personnel - vous disposez d'une option supplémentaire : la configuration d'une stratégie de groupe ou d'un MDM pour désactiver le DoH au niveau du navigateur et du système d'exploitation. Dans Firefox, la préférence network.trr.mode définie sur 5 désactive complètement le DoH. Dans Chrome, l'indicateur disable-features égal à DnsOverHttps produit le même effet. Windows 10 et 11 disposent de paramètres de stratégie de groupe pour contrôler le comportement du DoH. Il s'agit du contrôle le plus fiable pour les appareils gérés, mais il ne s'applique pas aux appareils invités non gérés. Section quatre - pièges de mise en œuvre. Quelques problèmes fréquemment rencontrés sur le terrain. Le mode de défaillance le plus fréquent est l'interception incomplète du port 53. Les équipes configurent correctement leur service de filtrage DNS mais oublient d'ajouter la règle de pare-feu qui redirige tout le trafic sortant du port 53. Les appareils dotés de paramètres DNS codés en dur - 8.8.8.8, 1.1.1.1 - contournent complètement le filtre. Vérifiez toujours que cette règle est en place et testez-la en configurant un appareil de test avec un serveur DNS codé en dur et en confirmant que les domaines filtrés sont toujours bloqués. La deuxième erreur courante est de ne pas prendre en compte l'IPv6. Les requêtes DNS sur IPv6 sont de plus en plus courantes, et de nombreuses règles de pare-feu sont écrites uniquement pour l'IPv4. Assurez-vous que votre interception du port 53 et vos listes de blocage de résolveurs DoH couvrent à la fois les adresses IPv4 et IPv6. Troisièmement : les listes de blocage de résolveurs DoH obsolètes. Si vous gérez une liste de blocage statique d'adresses IP de résolveurs DoH, elle deviendra rapidement obsolète. Automatisez le processus de mise à jour ou utilisez un service de filtrage DNS qui gère cette liste pour vous. Cloudflare Gateway, Cisco Umbrella et d'autres services DNS d'entreprise similaires incluent la détection du contournement DoH en tant que fonctionnalité gérée. Quatrièmement : la dépendance excessive à l'égard d'une seule couche d'atténuation. L'atténuation du DoH est un problème de défense en profondeur. Aucun contrôle unique n'est suffisant. Le blocage des résolveurs connus gère la plupart des cas. L'inspection TLS gère les cas particuliers. L'interception DNS fournit un filet de sécurité. Superposez les trois. Section cinq - questions rapides. L'atténuation du DoH nuit-elle aux outils de confidentialité légitimes ? Potentiellement, oui. Si un utilisateur utilise une configuration de navigateur légitime axée sur la confidentialité, votre blocage du DoH le forcera à utiliser votre résolveur DNS. Votre politique d'utilisation acceptable doit préciser que le résolveur DNS de l'établissement est utilisé à des fins de filtrage de contenu. Il s'agit d'une pratique standard et juridiquement défendable. Le DoH peut-il être utilisé pour exfiltrer des données de mon réseau ? Oui, et c'est un vecteur de menace bien réel. Le tunnel DNS via DoH a été démontré dans la pratique. La fonctionnalité de détection DoH de votre pare-feu de nouvelle génération doit inclure une détection d'anomalies pour les volumes de requêtes anormalement élevés ou les modèles de requêtes correspondant à un tunnel. Qu'en est-il des applications mobiles qui utilisent DoH ? C'est le cas le plus difficile. Les applications mobiles qui implémentent leur propre pile DoH - plutôt que d'utiliser les paramètres DNS du système d'exploitation - sont difficiles à contrôler sans inspection TLS. Votre meilleure mesure d'atténuation est la combinaison du blocage des résolveurs connus et de l'inspection TLS. Le WPA3 est-il pertinent ici ? Le WPA3 améliore le chiffrement sans fil et assure la confidentialité persistante, ce qui est excellent pour la confidentialité des invités. Mais le WPA3 ne traite pas le DoH - il s'agit d'un problème de protocole applicatif de couche 7, et non d'un problème de sécurité sans fil de couche 2. Ce sont des contrôles complémentaires qui traitent des vecteurs de menace différents. Section six - ROI et impact commercial. Permettez-moi de conclure avec l'analyse de rentabilité pour traiter ce sujet correctement. Le coût de la non-prise en compte du DoH est asymétrique. Un seul incident - un invité accédant à un contenu illégal sur votre réseau, un rappel de malware non détecté parce que votre surveillance DNS avait un angle mort, une enquête réglementaire sur votre conformité en matière de filtrage de contenu - peut coûter considérablement plus cher que l'investissement dans une atténuation appropriée. Pour un groupe hôtelier exploitant 20 propriétés, le déploiement de l'atténuation DoH implique généralement un effort de configuration unique de deux à quatre heures par propriété pour les règles de pare-feu et la configuration de l'interception DNS, plus un coût opérationnel continu de maintenance des listes de blocage de résolveurs - ce qui est largement automatisé si vous utilisez un service géré de filtrage DNS. L'investissement total est modeste par rapport à la réduction des risques. Pour les chaînes de vente au détail opérant sous PCI-DSS, l'avantage en matière de conformité est directement quantifiable. Démontrer que vos contrôles de sécurité réseau incluent l'atténuation du DoH réduit le risque d'une anomalie lors d'un audit PCI-DSS et les coûts de remédiation associés. Pour les établissements du secteur public et ceux opérant sous l'Online Safety Act, l'atténuation documentée du DoH fait partie de vos éléments de preuve démontrant que vous avez pris des mesures techniques raisonnables pour appliquer votre politique de filtrage de contenu. L'essentiel : le DoH n'est pas un problème futur. C'est un problème actuel. Firefox, Chrome, Android et iOS déploient tous des configurations compatibles DoH sur les appareils de vos invités en ce moment même. Si vous n'avez pas audité votre architecture de filtrage DNS pour détecter les vecteurs de contournement DoH au cours des 12 derniers mois, cet audit devrait figurer sur votre feuille de route à court terme. Pour résumer les points clés de la séance d'information d'aujourd'hui. Premièrement : le DoH chiffre les requêtes DNS dans HTTPS sur le port 443, les rendant invisibles pour le filtrage DNS traditionnel sur le port 53. Cela se produit par défaut sur les navigateurs et systèmes d'exploitation grand public. Deuxièmement : la stratégie d'atténuation à trois niveaux - bloquer les adresses IP des résolveurs DoH connus, implémenter l'inspection TLS sur votre pare-feu de nouvelle génération et appliquer l'interception du port 53 - offre une couverture de défense en profondeur pour les appareils invités gérés et non gérés. Troisièmement : il s'agit d'un problème de conformité, et pas seulement technique. Le GDPR, l'Online Safety Act et le PCI-DSS ont tous des implications pour les établissements où le DoH contourne silencieusement les politiques de filtrage de contenu. Quatre : La cause d'échec de mise en œuvre la plus fréquente est une interception incomplète du port 53. Testez-la. Vérifiez-la. Ne supposez pas qu'elle fonctionne. Cinq : Les services managés de filtrage DNS - Cloudflare Gateway, Cisco Umbrella et similaires - intègrent de plus en plus la détection du contournement DoH en tant que fonctionnalité managée, ce qui réduit la charge opérationnelle liée à la maintenance de listes de blocage statiques. C'est tout pour ce briefing technique Purple. Si vous souhaitez auditer votre architecture de filtrage DNS actuelle ou déployer une atténuation du DoH sur l'ensemble de vos sites, la plateforme Purple fournit l'intelligence réseau et la couche de gestion du WiFi invité nécessaires pour accompagner ce déploiement. Merci pour votre écoute, et à bientôt pour une prochaine session.