Windows Server 2012: Signer vos zones avec DNSSEC


Patrice2012Bonjour tout le monde,

Dans un post précédent, nous avons vu comment installer DNS intégré aux services de domaine AD DS.

Lors d’un récent post, nous avons vu rapidement ce qu’est DNS et comment installer le rôle sur Windows Server 2012. DNS, conçu en 1983, est le service réseau, qui permet de résoudre les noms de domaine recherchés (plus facile à retenir pour les utilisateurs) en des séries de chiffres – adresses IP – (plus facile à traiter par les machines). Lorsqu’une machine en recherche une autre, elle transmets un nom unique qui est traduit par DNS en son équivalent numérique, adresse composée de 4 séries de 3 chiffres (adresse IP) pour la norme IPv4 et jusqu’à 8 séries de 4 caractères hexadécimaux pour la norme IPv6.

En  clair, un ordinateur adresse le nom d’un serveur hôte distant, DNS lui répond, s’il possède la réponse dans sa base de données, avec l’adresse IP équivalente. Dans la négative, il interroge récursivement d’autres DNS jusqu’à trouver la réponse adéquate.
On dit alors que DNS est utilisé pour localiser des ordinateurs et des services à l’aide de noms conviviaux, laissant leur équivalence en adresses numériques – IPv4 – ou alphanumériques – IPv6 – au traitement de résolution machine.

Lorsque le système DNS recherche un ordinateur à la requête d’une machine, il scrute le premier niveau de l’annuaire : la zone racine.
Pour reprendre l’exemple de
www.rueWindows.fr, DNS cherche dans ".fr" géré par l’AFNIC (Pour le .eu c’est l’EURID qui gère). La recherche suivante se fera vers le second niveau  ".rueWindows.fr". Lorsque la réponse est correcte, il renvoie l’adresse complète trouvée à l’ordinateur qui lui a adressé la demande.
A l’évidence, on remarque que cette zone racine est de la première importance puisque la base de la recherche de noms de domaine repose sur elle.

Lorsque l’on intègre le rôle DNS aux Services de domaine imageActive Directory (AD DS), des fichiers de zone sont créés. Ces zones sont des bases de données de stockage dans laquelle on trouve les enregistrements du domaine ou du sous-domaine géré.
Ce sont ces zones qui vont occuper la suite de cet article car, c’est sur elles que reposent tous les problèmes liés à l’empoisonnement du cache du système de résolution.

Depuis quelques années, des failles du systèmes ont été répertoriées dans une RFC (http://tools.ietf.org/html/rfc3833 ) disponible auprès de l’IETF. La principale faille mise au jour était la possibilité pour des utilisateurs malveillants d’intercepter les paquets émis de manière peu sécurisée.

Même si la sécurisation de DNS a commencé vers 1995, ce n’est vraiment qu’à partir de 2008 que DNSSEC trouve son intérêt avec la révélation de la faille Kaminsky. Ensuite, les récentes vulnérabilités mises en évidence par les attaques sur le système DNS ont poussé les différents acteurs à protéger de bout en bout la communication entre machines. Le protocole de sécurité DNSSEC (DNS Security Extensions) palie au manque de sécurité de DNS.

Pour cela, DNSSEC signe numériquement et asymétriquement les enregistrements des zones DNS à l’aide de deux clefs : une publique, et l’autre privée. En signant les données de l’annuaire, ce protocole garantit  l’authenticité de la réponse du serveur aux machines ayant lancé les requêtes deAFNIC recherche de noms. Ainsi, l’utilisateur final aura l’assurance de se connecter sur le bon site.

En pratique, chaque niveau de l’annuaire possède ses propres clés. Lors de la lecture des informations, une validation s’opère où chaque clé d’un niveau valide celle du niveau immédiatement supérieur, ainsi de suite jusqu’au niveau racine.
Ce protocole utilise donc 2 clés :

  • KSK (Private Key Signing Key) nécessaire à la validation d’un enregistrement de zone et pour signer la clé ZSK,
  • ZSK (Public Zone Signing Key) nécessaire pour signer les enregistrements de zone.

La clef privée génère le chiffrage, alors que la clef publique permet de la lire. La clef privée est nécessaire pour générer une clef publique. De ce fait, si la clef publique ou si le chiffrage de l’enregistrement est altéré, il ne sera pas possible de lire l’information.
Selon la pratique adoptée et notamment Microsoft, il est recommandé de changer la ZSK tous les 3 mois et la KSK tous les ans.

Dans le cas du DNSSEC, l’administrateur ajoute donc à sa zone un chiffrage (RRSIG) de chacun des champs DNS à l’aide de sa clef privée, et rend disponible une clef publique (DNSKEY), afin de pouvoir les lire. Il est transmis en plus une empreinte de la clef au registre (DS).

Mise en œuvre de DNSSEC

A l’aide du clic droit de la souris sur le premier enregistrement de ressource de la zone, sélectionnez DNSSEC puis, Signer la zone…

Signer1

Après avoir pris connaissance du but de l’Assistant Signature de zone, vous avez la possibilité de ne plus afficher la page dans le futur, en cochant la case et d’obtenir plus d’informations sur le protocole DNSSEC (liens également à la fin de cet article). Cliquez sur Suivant pour démarrer la procédure…

Signer2

Aucune zone n’étant signée, choisissez l’option Personnalisez les paramètres de signature de zone puis, cliquez sur Suivant… Dans le cas contraire et pour signer les enregistrements d’une autre zone, nous sélectionnerons la deuxième option ou la troisième si vous ne voulez pas modifier les paramètres.

Signer3

Ici, le maitre des clés est le serveur pré-sélectionné. Cliquez sur Suivant pour poursuivre…

Signer4

La première clé KSK, clé privée, va être générée. Elle servira à signer la clé publique ZSK. Cliquez sur Suivant pour continuer…

Signer5

Nous allons configurer une nouvelle clé KSK. Cliquez sur Ajouter pour démarrer le traitement…

Signer6

Une nouvelle clé est proposée. Sélectionnez l’algorithme de chiffrement; vous pouvez utiliser celui proposé par défaut. Il est conseillé de remplacer cette clé au moins une fois par an. Cliquez sur OK une fois votre choix réalisé puis, sur Suivant pour générer la clé ZSK…

Signer8

Une nouvelle clé est proposée. Sélectionnez l’algorithme de chiffrement; vous pouvez utiliser celui proposé par défaut. Il est conseillé de remplacer cette clé au moins une fois tous les 3 mois. Cliquez sur OK une fois votre choix réalisé…

Signer9

Choisissez le protocole de chiffrement puis cliquez sur Suivant pour continuer… NSEC3 a pour objectif de lutter contre les attaques de type "énumération de zone". Mais attention : une zone peut être signée soit, avec NSEC soit, avec NSEC3 mais, pas avec les deux.

Signer10

Configurez ensuite la distribution des ancres d’approbation. Cliquez sur Suivant pour poursuivre…

Signer11

Paramétrez les valeurs pour la signature des enregistrements et l’interrogation. Cliquez sur Suivant pour continuer…

image

L’assistant a rassemblé les informations pour la signature. Cliquez sur Suivant pour démarrer la signature de l’élément…
Un message vous annonce que la zone a été signée. Cliquez sur Terminer pour quitter l’assistant signature de zone et passer à une autre zone.

Signer13

Vous pouvez ouvrir l’observateur d’évènements DNS, depuis le gestionnaire DNS, et apercevoir le message ID:7646 vous informant que la zone est signée avec DNSSEC.

Vu de la console DNS, ces signatures se présentent sous la forme de nouveaux enregistrements. La finalité en est une taille des messages ainsi qu’un nombre d’échanges plus élevés, dans le but de vérifier les signatures et clés utilisées.
Il apparait évident que DNSSEC engendre plus de ressources machine ainsi que des versions à jour de logiciels DNS.
De plus, il faut bien avoir à l’esprit que :
- DNSSEC n’assure pas la confidentialité des échanges réseaux, ne protège pas contre le phishing et les malwares,
- Les enregistrements signés ne peuvent être authentifiés que si la clé de la zone a été publiée dans la zone parente,
- Il n’y a pas de sécurité mise en œuvre si le résolveur n’a pas, lui-même, mis en œuvre DNSSEC.

On voit bien l’enjeu de ces échanges réseaux qui nécessitent une gestion sans faille des signatures au risque de voir les résolutions de zone bloquées à cause de signatures expirées.

Et après ?

Ensuite, vous devrez signer de nouveau une zone lorsque :

  • Des données d’une zone ont été modifiées, ajoutées ou supprimer. Vous pourrez utiliser les clés existantes,
  • Des clés sont compromises ou invalides. En cas de compromission, vous devrez générer à nouveau les clés,
  • Si une zone enfant est signée après que la signature de la zone parente ait été signée, puis les enregistrements DS de la zone enfant ajoutés à la zone parente alors, la zone parente doit être également signée à nouveau.


Pas à pas : illustrer DNSSEC dans un laboratoire de test  http://technet.microsoft.com/fr-fr/library/hh831411
Introduction à DNSSEC : http://technet.microsoft.com/fr-fr/library/ee649205(v=ws.10).aspx

Bonne lecture.
Patrice.

Comments are closed.

(c) 2014 - Patrice A. BONNEFOY - Microsoft MVP Windows Expert IT-Pro since 2005.