Editions ENI Livres | Vidéos | e-Formations
Le réseau sous Active Directory
Rôles du service DNS dans l’AD
1. Introduction
Après avoir exploré les fondamentaux du DNS et son fonctionnement global dans les précédents chapitres, nous nous concentrons maintenant spécifiquement sur son rôle crucial au sein d’Active Directory (AD).
Ce chapitre mettra en lumière pourquoi et comment le DNS est indispensable pour le bon fonctionnement d’AD.
Le rôle du service DNS dans un domaine AD ne se limite pas à une simple résolution de noms comme illustré dans le schéma ci-dessous ; il s’étend à des fonctions essentielles qui sont le pilier de la connectivité et de la gestion de réseau dans un environnement AD.
Examinons maintenant de plus près ces rôles clés et leur impact significatif sur la gestion et l’efficacité d’Active Directory.
2. Localisation des services AD
Le service DNS joue un rôle fondamental dans la localisation des contrôleurs de domaine (Domain Controller) dans un environnement Active Directory (AD), facilitant ainsi des processus clés tels que l’intégration au domaine et l’authentification.
Localisation des contrôleurs de domaine
Les enregistrements SRV présents dans la zone DNS du domaine AD sont spécialement conçus pour localiser les services AD, y compris les contrôleurs de domaine. Lorsqu’un client démarre, il interroge le serveur DNS pour localiser le DC le plus proche ou disponible grâce aux enregistrements du type SRV.
Ces enregistrements indiquent non seulement l’adresse des contrôleurs de domaine, mais aussi des services spécifiques tels que le service Kerberos ou LDAP. Ces informations se trouvent au niveau du sous-domaine _msdcs (Microsoft Domain Controller Services) créé lors de la promotion du contrôleur de domaine.
Intégration au domaine
Lorsqu’une machine tente de joindre un domaine AD, elle utilise le serveur DNS pour localiser un contrôleur de domaine capable de traiter sa demande.
Une résolution DNS efficace est donc essentielle pour une intégration réussie au domaine.
Une réponse précise du serveur DNS garantit que la machine se connecte au contrôleur de domaine approprié pour le domaine spécifié.
Processus...
Configuration et bonnes pratiques DNS dans AD
Avec une compréhension préalable de l’importance du service DNS dans le bon fonctionnement d’une infrastructure Active Directory, il est essentiel de s’assurer que cette fondation solide ne soit pas compromise par une configuration incorrecte. Dans cette section, nous explorerons un ensemble de recommandations et de bonnes pratiques visant à prévenir les problèmes qui peuvent survenir, en particulier lorsque l’environnement compte un grand nombre de sites, de contrôleurs de domaine ou de domaines. Notre objectif est de garantir la stabilité et l’efficacité du DNS au sein de votre infrastructure AD, tout en assurant une gestion optimale même dans des environnements complexes.
1. Ordre DNS sur les machines
Il est essentiel de maintenir un ordre DNS cohérent sur les machines et les serveurs qui dépendent d’une résolution continue des noms DNS pour assurer une communication efficace au sein du réseau. Cette configuration doit être méthodique et logique. Il est ainsi recommandé de configurer les hôtes de manière à interroger en priorité les serveurs DNS les plus proches de leur site géographique. Vous pouvez mettre en place cette configuration soit au niveau du service DHCP en spécifiant l’ordre des serveurs DNS dans les paramètres, soit en configurant manuellement les serveurs DNS sur les machines.
Cela garantit une résolution DNS efficace en privilégiant les serveurs DNS locaux, une réduction de la latence et une amélioration des performances réseau. En outre, cela contribue à maintenir une structure de réseau organisée et à éviter les problèmes de résolution DNS causés par une configuration incohérente ou inadéquate.
Ci-dessous un schéma présentant un exemple de l’ordre de priorité des serveurs DNS à configurer sur les systèmes clients :
Pour mieux illustrer ce point, prenons l’exemple de sites qui ne sont pas situés seulement dans des villes différentes, mais dans des pays distincts. Est-il pratique que les machines situées dans le site A (France) effectuent continuellement des requêtes DNS vers le contrôleur...
Sauvegarde et restauration de la zone DNS
Nous avons étudié dans les précédentes sections l’importance du service DNS pour garantir une communication fluide et efficace, tant dans les réseaux internes qu’externes, que ce soit dans un environnement Windows avec Active Directory ou non.
Sans un service DNS fiable, les applications et les machines devraient mémoriser les adresses IP de tous les serveurs, en espérant que ces dernières restent statiques.
L’authentification et la réplication AD dépendent aussi largement du DNS. Par conséquent, une erreur mineure ou la suppression accidentelle d’un enregistrement peut causer des dysfonctionnements et interrompre certains services.
Il est donc prudent de sauvegarder régulièrement toutes les zones DNS de nos serveurs y compris celles intégrées dans l’Active Directory, pour pouvoir effectuer une comparaison ou une restauration en cas de problème, un processus que nous allons effectuer ensemble.
1. Sauvegarde d’une zone DNS
Sur les serveurs Windows, la sauvegarde des zones DNS s’effectue exclusivement en ligne de commande, et est spécifique à chaque zone.
Avec les commandes par défaut, il n’est pas possible de sauvegarder simultanément toutes les zones DNS. Pour y parvenir, il est nécessaire soit de spécifier chaque zone individuellement, soit d’utiliser un script.
Les fichiers de sauvegarde sont créés par défaut dans C:\windows\system32\dns. Une attention particulière est nécessaire pour éviter d’écraser des sauvegardes antérieures, ou il peut être nécessaire de déplacer ces fichiers pour ne pas avoir d’erreur.
En plus, il est important de noter que les zones DNS intégrées à l’Active Directory peuvent être récupérées via la corbeille AD, offrant une sécurité supplémentaire en cas de problème avec la sauvegarde.
Microsoft propose les commandes dnscmd et Export-DNSServerZone pour la sauvegarde, cette dernière étant une version avancée en PowerShell, souvent privilégiée pour sa facilité d’utilisation et sa flexibilité.
Ci-dessous la syntaxe par défaut de la commande :...
Sécuriser le protocole DNS
1. Les attaques sur le protocole DNS
Que ce soit dans les communications sur les réseaux locaux ou sur Internet, le protocole DNS joue un rôle essentiel. Cependant, de par sa conception, le protocole DNS est vulnérable à certaines attaques.
Le service DNS est directement ciblé par plusieurs types d’attaques, parmi lesquelles ces deux méthodes :
-
L’empoisonnement DNS (appelée aussi Cache Poisoning et DNS Spoofing) qui consiste à détourner le trafic afin d’acheminer l’utilisateur vers un serveur malveillant.
Lorsque le cache d’un serveur DNS est empoisonné, cela signifie que l’adresse IP associée à un nom d’hôte a été modifiée par l’attaquant.
Lorsqu’un utilisateur va chercher à contacter un hôte, la machine de l’utilisateur va solliciter le serveur DNS afin de résoudre le nom, et ce dernier va lui renvoyer l’information qu’il a dans son cache. C’est le fonctionnement classique du DNS, le cache étant là pour améliorer les temps de réponse et réduire la charge des serveurs DNS.
S’il s’agit d’un enregistrement DNS empoisonné, l’utilisateur sera redirigé vers un hôte contrôlé par l’attaquant, à la place du serveur de confiance. Ce type d’attaque peut s’appliquer à un site web, à un serveur en entreprise, etc. Et elle est transparente pour l’utilisateur.
-
L’amplification DNS est une attaque de type déni de service distribué (DDoS) où l’on va s’appuyer sur le protocole DNS pour émettre du trafic à destination d’une cible. L’objectif étant d’envoyer une quantité de trafic importante à destination d’une cible (un serveur, par exemple) dans le but de le surcharger et de le rendre inaccessible ou de le ralentir.
Généralement, les attaquants vont s’appuyer sur un botnet, c’est-à-dire un réseau d’appareils infectés pour mener à bien cette attaque. La taille d’un botnet est très variable car ce groupe d’appareils peut contenir quelques milliers ou des dizaines de milliers de machines infectées.
Dans...
Se protéger des attaques DoS
1. Attaque DoS et contre-mesures
Nous avons précédemment examiné les diverses options et configurations permettant de sécuriser les zones DNS. Cependant, ces mesures restent insuffisantes pour contrer et atténuer certaines attaques telles que les DDoS (Distributed Denial of Service - Déni de service distribué).
Pour réduire les risques d’attaques de type dénis de service, Microsoft a introduit la fonctionnalité RRL (Response Rate Limiting) disponible à partir de Windows Server 2016. Cette fonctionnalité vise à limiter le taux de réponse du serveur DNS. Autrement dit, si un utilisateur malveillant envoie sans cesse la même requête au serveur DNS, ce dernier ne va pas répondre à l’ensemble des sollicitations car le RRL va agir comme une bride.
2. Rappel du principe de l’attaque
Une attaque par déni de service (Denial of Service - DoS) vise à rendre un service ou un système indisponible pour ses utilisateurs en interrompant son fonctionnement normal. Cela peut se faire en submergeant la cible de requêtes, saturant sa bande passante, ou épuisant ses ressources système telles que la mémoire et le CPU. Les attaques DDoS peuvent prendre diverses formes, y compris les attaques volumétriques, d’épuisement des ressources, et d’applications.
Contrairement aux attaques DoS qui proviennent d’une seule source, les attaques DDoS proviennent de nombreuses sources distribuées, telles qu’un botnet.
Les conséquences des attaques DDoS peuvent être graves, entraînant des temps d’arrêt coûteux pour des services majeurs tels que le DNS ou les services web.
Source image : https://learn.microsoft.com/en-us/archive/blogs/teamdhcp/response-rate-limiting-in-windows-dns-server
a. Quelques exemples d’attaques DoS
SYN Flood : l’attaquant envoie un flux massif de requêtes SYN pour épuiser les ressources du serveur, l’empêchant de répondre aux demandes légitimes.
DNS Amplification : l’attaquant manipule les serveurs DNS pour envoyer des réponses amplifiées à la victime, saturant sa bande passante avec un trafic excessif.
UDP Flood : l’attaquant envoie un grand...