Les enjeux de la sécurisation de DNS
- Synthèse
- Principes de fonctionnement
- Quelles conséquences pour la détection d’incidents
- Conclusion
Synthèse
Le protocole DNS a été conçu dans les années 80 à une époque où la sécurité n’était pas une priorité et on n’imaginait pas les impacts et les enjeux que nous avons aujourd’hui sur la confidentialité et l’intégrité des données échangées. DNSSEC est venu combler en partie les lacunes de DNS en apportant uniquement l’authentification des résolveurs et l’intégrité des données échangées et non la confidentialité.
Depuis les déclarations d’Edward Snowden en 2013 et avec la généralisation du chiffrement des flux, le DNS est lui aussi touché par une prise de conscience générale quant à la nécessité de sécuriser les échanges réseaux.
Dans cet article, nous allons présenter deux technologies permettant de chiffrer ces échanges et possédant chacune ses propres avantages et inconvénients et les impacts que cela a sur la détection d’incident de sécurité.
Les méthodes que nous verrons ici permettent de s’assurer uniquement de la confidentialité des échanges DNS et non de leur intégrité. L’authenticité des résolveurs DNS (clients) n’est également pas assurée.
Principes de fonctionnement
Le DNS over TLS (DoT)
Dans les grandes lignes, le DNS over TLS, abrégé DoT, utilise les mêmes mécanismes que le DNS à ceci près que l’échange est initialisé avec une poignée de main TLS au préalable afin de chiffrer la suite de l’échange. La requête DNS est donc encapsulée dans un paquet TLS.
Le DoT utilise le port 853 par défaut pour communiquer. Les flux chiffrés ne doivent pas transiter sur un port réservé pour envoyer et recevoir des flux non chiffrés (53) et inversement.
Deux modes d’authentification sont disponibles :
- Strict mode : Le client DoT dispose d’une liste de certificats serveurs de confiance sur laquelle il va s’appuyer pour prendre la décision d’accepter l’échange avec le serveur ou non.
- Opportunistic mode : Le client va tenter de communiquer sur le port 853 pour tenter d’établir une connexion sécurisée. S’il n’y parvient pas, il passera par le port 53 pour établir une connexion DNS classique.
Le DNS over HTTPS (DoH)
Avec DoH, les requêtes DNS sont encapsulées dans un paquet HTTPS, le port utilisé est donc le 443.
On voit bien sur le schéma ci-dessus que le HTTPS sert de « véhicule de transport » au DNS. Le paquet TLS encapsule le paquet https qui lui-même encapsule le paquet DNS tout comme le principe des poupées russes.
Pour se faire, deux modes de transmission de la requête DNS sont possibles : soit par une requête GET, soit par une requête POST.
Méthode GET : La variable « dns » est contenue dans l’url et formatée selon le standard DNS puis en encodée en base64 (base64url – RFC 4648). Le corps de la requête est alors vide.
Méthode POST : La variable « DNS » est contenue dans le corps de la requête https.
Les requêtes et réponses utilisent actuellement le type MIME « application/dns-message ». Cela pourrait changer dans le futur et d’autres types pourraient apparaître par la suite.
⚠ Les codes de retour http ne sont valables que pour les échanges de paquets http. Un code retour 200 (favorablement donc) de la réponse http signifie seulement que les échanges http se sont déroulés avec succès et non que la réponse DNS ne contient pas d’erreur.
Quelles conséquences pour la détection d’incidents
Dans un contexte d’entreprise, l’utilisation de ces protocoles peut avoir des impacts non négligeables sur la détection et la réponse sur incidents de sécurité. En effet, les flux étant chiffrés sur les terminaux, des mesures alternatives doivent être mises à en place pour continuer d’assurer la détection sur les requêtes DNS.
Détection DNS avec DoT
Avec DNS over TLS, le flux passe sur le port 853, ce qui veut dire que même chiffré, nous pouvons continuer à superviser opérationnellement le flux (charge, bande passante par utilisateur, …). En revanche, nous ne pourrons plus inspecter le contenu des requêtes pour réaliser de la détection IOC ou bien des tunnels cachés.
En analysant la taille des requêtes DNS il est théoriquement possible de déterminer une potentielle attaque, mais cela reste approximatif et il convient de ne pas utiliser le padding EDNS(0) qui fausserait le résultat.
Dans un contexte d’entreprise, il est possible tout de même de réaliser la détection de la sorte :
- Les clients se connectent au relais DNS classiquement de manière non chiffrée
- Le relais DNS interne se sert du DoT pour se connecter au résolveur DNS externe
Dans cette configuration nous pouvons analyser les flux entre le relais DNS et les clients ainsi que tous les flux réceptionnés par le relais DNS. Les flux entre notre relais et les clients étant en clair, leur analyse ne change pas de ce qui est fait habituellement.
Cette configuration est valable tant que les clients ne contactent pas en direct de DNS à l’extérieur (DNS en clair, DoT ou DoH), la(es) seule(s) machine(s) autorisé(es) à communiquer avec les résolveurs DNS à l’extérieur étant le(s) relais DNS interne.
Le protocole ADoT (Authoritative DNS over TLS) qui concerne le chiffrement entre les résolveurs DNS et les serveurs d’autorité DNS est à ce jour en cours d’étude et de formalisation par le groupe DPRIVE qui s’est chargé de l’établissement du DoT.
Détection DNS avec DoH
Le DoH étant basé sur HTTPS, il sera plus compliqué de différencier le flux utilisé pour DNS que les autres.
L’éventualité d’utiliser JA3 pour détecter le flux DNS encapsulé dans HTTPS est à proscrire. Le nombre de faux positifs serait trop conséquent étant donné qu’il s’agit d’un flux HTTPS émis par des applications légitimes lorsqu’il s’agit de navigateurs.
La méthode la plus efficace pour détecter le flux DNS sur HTTPS et l’analyser est l’inspection TLS via une rupture du flux :
Si un client tente de communiquer avec un serveur DoH, deux cas de figure sont possibles :
- Le serveur est sur une liste d’exclusion, le flux est bloqué si besoin (on peut trouver une liste de serveurs DoH ici)
- Le serveur n’est pas sur une liste d’exclusion, l’inspection TLS va permettre de repérer le flux DNS encapsulé dans HTTPS (grâce au type MIME « application/dns-message » par exemple) permettant ainsi la détection sur DNS
Blocage de DoT et de DoH
Nous avons vu précédemment comment nous pouvions continuer à réaliser de la détection sur les paquets DNS mais il peut être nécessaire de désactiver ces protocoles en cas d’interdiction dans la PSSI.
La désactivation est possible directement dans les paramètres des navigateurs mais également par GPO. Voici en exemple, pour les navigateurs les plus utilisés, les GPO à modifier :
1. Google chrome : [DnsOverHttpsMode : disable]
- Software\Policies\Google\Chrome\DnsOverHttpsMode
2. Firefox : [DNSOverHTTPS : Disable]
- Software\Policies\Mozilla\Firefox\DNSOverHTTPS\Enabled = 0x0
- Software\Policies\Mozilla\Firefox\DNSOverHTTPS\Locked = 0x0
3. Edge : [DnsOverHttpsMode : Disable]
- SOFTWARE\Policies\Microsoft\Edge\DnsOverHttpsMode = « off »
De cette manière, tout flux DNS over HTTPS/TLS émis par une machine est illégitime et constitue une violation de la Politique de Sécurité du Système d’Informations.
Si l’inspection TLS est inenvisageable, on peut recourir au blocage des sous-domaines fournissant un service DoH tels que « cloudflare-dns.com » ou « dns.dns-over-https.com ». Le désavantage de cette méthode réside dans le fait que nous serons incapables de voir si un flux DoH illégitime circule sur le réseau.
Conclusion
Ces nouveaux protocoles apportent de la confidentialité aux utilisateurs sur un protocole qui intrinsèquement n’est pas sécurisé. C’est un gain non négligeable pour la vie privée des usagers d’(es) Internet(s) notamment dans certains États où la censure est de mise.
Cependant, les entreprises vont devoir s’adapter à ces nouvelles technologies pour trouver le juste milieu entre vie privée et détection d’incident de sécurité. S’affranchir de l’analyse des flux DNS est un risque non négligeable en termes de fuite de données ou de communication avec des C&C au même titre que tout flux chiffré sortant du SI non inspecté.
À ce titre, les entreprises sont toujours légalement responsables de la sécurité de leur(s) système(s) d’information.