5.3. Sécurisation du DNS
Pour sécuriser le DNS, nous avons déjà identifié plusieurs contre-mesures :
- Garder les logiciels à jour pour patcher les failles de sécurité
- Configurer des access lists sur les serveurs pour restreindre l’acceptation des requêtes (et notamment pour la récursion)
En plus de cela, une bonne organisation des serveurs DNS de l’entreprise et l’utilisation de mécanismes cryptographiques pour garantir l’authenticité et la confidentialité du DNS permettront de minimiser les risques liés au DNS.
5.3.1. Architecture DNS sécurisée
Une architecture DNS sécurisée est une organisation des services DNS permettant de minimiser l’exposition des ressources DNS. Elle nécessite une séparation stricte entre les zones publiques et les zones internes. Elle inclut également de la redondance pour la robustesse du système.
La figure ci-dessous représente une première organisation possible. Dans ce réseau, deux serveurs primaires sont utilisés : un pour la zone publique, et un pour la zone interne.
Le SOA de la zone publique est en zone démilitarisée, et ne peut recevoir de requêtes que depuis l’Internet. Il ne possède que les informations sur les services qui doivent être accessibles de l’extérieur.
La gestion du DNS interne est assurée par un serveur qui sera situé dans une zone séparée. Ce serveur contiendra deux zones : La zone interne, et la zone publique, dans une version permettant aux clients d’obtenir une résolution vers les adresses internes des serveurs publics. Cela permet aux clients de joindre les services internes dans que leur trafic ne doive sortir sur Internet.
Un second exemple d’organisation possible est illustré ci-dessous. Dans ce cas, la politique de sécurité est beaucoup plus restrictive pour les utilisateurs : Ils ne peuvent pas accéder directement à Internet, ils doivent passer par un proxy Web, qui est un relais HTTP permettant de contrôler le trafic sortant de l’entreprise.
Cette politique a pour conséquence qu’il faut empêcher l’accès des utilisateurs au résolveur pour les noms Internet. Ce résolveur est ici placé en DMZ. Un serveur cache/forwarder est utilisé comme point d’accès au DNS pour les utilisateurs, placé dans la même zone que le proxy et le serveur DHCP.
Les trafics découlant de cette organisation sont les suivants :
- Les utilisateurs utilisent le serveur cache/forwardeur comme “résolveur”. Lorsque ce dernier reçoit une requête concernant la zone interne, il la forwarde au SOA interne. Par contre, il bloque les requêtes concernant les noms Internet : les utilisateurs ne pouvant pas gérer eux-mêmes leur trafic web, il faut les empêcher d’y avoir accès.
- Pour la navigation Internet, les utilisateurs doivent passer par le proxy HTTP. C’est ce dernier qui effectuera la résolution DNS, via le cache/forwarder. Ce dernier autorise les requêtes DNS Internet pour le proxy, et les redirige vers le résolveur en DMZ qui se chargera de trouver les réponses.
- Enfin, depuis l’Internet, les seules requêtes entrantes acceptées sont celles qui concernent la zone publique.
5.3.2. DNSSEC
Pour éviter le Cache Poisoning, il faut trouver un mécanisme permettant de garantir que l’information DNS stockée dans un serveur est bien authentique. Une manière de fournir cette garantie est de signer cette information DNS (les Resource Records) avec DNSSEC.
Le DNSSEC repose sur le principe de la cryptographie asymétrique, déjà présentée en section 4.2. Pour rappel, il s’agit d’une technique cryptographie permettant à la fois le chiffrement et la signature, grâce à une paire de clés : Une clé, appelée clé publique, est partagée publiquement, tandis que l’autre clé est conservée de manière sécurisée. Un message chiffré avec la clé publique ne peut être déchiffré qu’avec la clé privée, et inversement : un message chiffré avec la clé privée ne peut être déchiffré qu’avec la clé publique.
Cette cryptographie asymétrique va être utilisée dans DNSSEC pour signer les informations, à savoir les ressources records contenus dans les fichiers de zone. Chaque zone va donc posséder une paire de clés qu’elle utilisera pour créer des signature appelées RRSIG pour ses resources records (avec sa clé privée), afin que ses interlocuteurs puissent les valider (avec sa clé publique).
Le point critique de l’utilisation de la cryptographie asymétrique réside dans la publication des clés publiques : il faut en effet s’assurer que le propriétaire de la clé est bien la personne qu’elle prétend être, sinon le mécanisme ne sert à rien puisqu’on pourrait se retrouver à chiffrer/valider l’information reçue avec la clé de l’attaquant!
Pour éviter ça, il faut donc authentifier les clés publiques. C’est là qu’intervient le concept de chaîne de confiance. Ce mécanisme se base sur une hiérarchie, centrée sur un élément considéré comme “de confiance” : Cette racine (appelée “ancre de confiance”) valide ses élément “enfants” en signant leurs clés publiques avec sa propre clé privée. Ces éléments “enfants” valident à leur tour les clés publiques de leurs propres enfants, et ainsi de suite. Notez que ce système de validation hiérarchique des clés publiques est également utilisé par TLS (et donc HTTPS). Une clé publique signée est appelée certificat dans ce cas.
Dans le cas du DNS, il existe déjà une hiérarchie. Il est donc assez naturel de reposer dessus pour l’authentification des clés publiques. L”ancre de confiance” du DNS public est la zone root, et les résolveurs en possèdent tous la clé publique.
Lorsqu’un client DNS reçoit un RR accompagné de sa signature (RRSIG), il va commencer par demander sa clé publique (RR DNSKEY) au serveur de noms de la zone du RR signé afin de valider ce RR. Néanmoins, il doit encore vérifier l’authenticité de cette clé publique, via le hash de cette dernière (RR DS), stocké dans la zone parente et lui-même accompagné d’une signature RRSIG. Le client doit donc demander la clé publique du domaine parent pour valider ce RRSIG, clé publique qui doit à son tour être validée, et ainsi de suite jusqu’à la racine/ancre de confiance, dont l’authenticité est garantie.
Ce principe est illustré sur la figure ci-dessus, reprise de cet article de blog depuis le site de Verisign. En pratique, dans le cas du DNSSEC, les zones possèdent généralement deux paires clés :
- la KSK : Key Signing Key, dont la zone parente possède un hash signé (RR de type DS),
- la ZSK, signée par la KSK, qui sert à signer les records (ou les DS des zones enfants).
L’utilisation de deux paires est préconisée pour des raisons pratiques. Pour garantir la sécurité, il faut renouveler régulièrement les clés. Néanmoins, si ce renouvellement implique un intervenant extérieur, la procédure est plus compliquée. C’est pourquoi la KSK, signée par la zone parente, ne changera pas souvent, mais la ZSK, qui peut être signée localement par la KSK, sera elle régulièrement renouvelée.
Un autre RR souvent rencontré dans l’univers DNSSEC est le RR NSEC (Next SECure), qui servent à prouver la non-existence d’un nom DNS. Cela permet d’éviter les attaques par usurpation d’identité qui pourraient faire croire de manière fallacieuse à la non-existence d’un record DNS. Voir par exemple cet article du DNS Institute
En complément de cette introduction, vous trouverez une explication claire, détaillée et illustrée du DNSSEC sur le site de CloudFare. Si le sujet vous intéresse et que l’anglais technique ne vous fait pas peur, cet article fait le tour du sujet de manière approfondie en l’illustrant par de nombreuses manipulations pratiques.
Concrètement, pour mettre en oeuvre le DNSSEC, il faut le configurer à deux niveaux :
- Au niveau des résolveurs, qui doivent effectuer la validation des records qu’ils reçoivent, et refuser ceux dont la validation n’aboutit pas.
- Au niveau du SOA public, en effectuant les étapes suivantes :
- Générer les paires de clés KSK et ZSK
- Faire signer le hash de la KSK publique par l’autorité parente (ce dernier publie alors le hash signé sous forme de RR DS dans sa zone).
- Chiffrer les RRs de la zone en utilisant la ZSK, et ajouter les signatures (RRSIG) dans la zone.
- Chiffrer la ZSK publique avec la KSK privée, et publier la ZSK signée ainsi que la KSK publique dans la zone, sous forme de RRs DNSKEY.
Des outils existent pour toutes ces étapes, ainsi que des tutoriels. La seconde partie de ce tuto explique notamment la mise en oeuvre de DNSSEC sur un SOA Bind (note : la mise en oeuvre de DNSSEC dans Bind a été sensiblement simplifiée depuis, grâce à de l’automatisation. Cet article permet néanmoins de comprendre les étapes qui sont à présent automatisées).
5.3.3. Chiffrement du DNS
Nous avons vu que le DNSSEC permettait de garantir l’authenticité et l’intégrité des échanges DNS. Par contre, il ne garantit pas sa confidentialité : le trafic DNS est échangé en clair.
Pour résoudre ce problème, il “suffit” donc de chiffrer le trafic DNS.
Une première solution, assez classique, consiste à utiliser TLS pour chiffrer le trafic DNS. C’est la même approche que pour le chiffrement du protocole HTTP (HTTPS) et de nombreux autres protocoles. On parle alors de DNS over TLS (DoT). Le port utilisé dans ce cas est le port TCP 853.
Malheureusement, le DoT est relativement récent, et le port 853 n’est pas encore bien reconnu au niveau des équipements intermédiaires tels que les firewalls. C’est entre autre pour ça qu’une autre solution de chiffrement a été proposée, cette fois en utilisant non pas du TLS, mais du HTTPS : Cela permet d’exploiter le port 443 déjà connu. Cette fois, au lieu d’être encapsulé dans du TLS, les messages DNS sont encapsulé dans des requêtes HTTP, elles-mêmes encapsulées dans du TLS. On parle alors de DNS over HTTPS (DoH).
Ces deux protocoles sont relativement récents, et ne sont donc pas encore supportés par tous les serveurs DNS.
Vous trouverez plus d’information sur le sujet dans cet article du blog CloudFare.
Notez que la mise en oeuvre du DoH amène à des questionnements importants portant sur des trade-offs entre confidentialité et respect de la vie privée. Voir par exemple cet article sur le bloc de l’ISC.