Conception de l'infrastructure DNS
.gif){kind=icon}
Conception de l'infrastructure DNS
Introduction
Point de départ du chapitre
Point final du chapitre
Questions de conception
Ressources nécessaires
Conditions requises pour le système
Architecture DNS
Organigramme du Processus
DNS interne
Pourquoi fractionner ?
Plate-forme
Architecture
Matériel
Logiciels
Configuration
Serveurs
Zone racine/Transfert
Zones internes
Enregistrements DNS
Évolutivité
Sécurité
DNS externe
Plate-forme
Architecture
Attaques DNS
Modèle de service séparé
Services et serveurs
Zones externes
Hébergement de zones
Matériel
Logiciels
Configuration
Serveur d'annonce
Serveur de résolution
Zones
Évolutivité
Sécurité
Usurpation DNS
Fonctionnement de l'usurpation
Exemple d'usurpation
Quelle protection apporte le modèle de service séparé ?
DNS client
Condition requise pour DNS
Accès à Internet
Fichier « hosts » locaux
DNS client
DNS de fournisseur de services Internet
DNS ASP
Résumé
Informations complémentaires
Documents de référence
Ressources pour la résolution des problèmes
Microsoft Exchange 2000 Server
Tiré de l'article Série d'hôtes de serveurs Microsoft Exchange 2000
Volume 1 : Planification
Résumé
Ce chapitre traite de la conception du système DNS (Domain Name System, Système de nom de domaine) de votre infrastructure. Les sujets abordés concernent la configuration du système DNS interne pour le service d'annuaire Active Directory™ et la prise en charge de Microsoft® Exchange, la configuration de serveurs DNS externes et l'intégration de DNS sur le client. Ce chapitre étudie également comment intégrer l'infrastructure DNS existante d'un client.
Ce chapitre traite de la conception d'un système DNS (Domain Name System) pour prendre en charge un environnement Microsoft® Exchange 2000 hébergé.
DNS est un composant essentiel de tout domaine Microsoft Windows® 2000, car il est indispensable pour le fonctionnement correct du service d'annuaire Active Directory™. Exchange 2000 dépend de DNS pour son accès à Active Directory et pour permettre l'envoi et la réception de courrier électronique via Internet.
Les sujets de ce chapitre vous aideront à identifier les composants essentiels qui constitueront la conception de votre infrastructure DNS. Ils concernent notamment la séparation de l'infrastructure DNS en plusieurs couches et la relation entre ces couches.
Au début de ce chapitre, vous avez planifié vos composants réseau, notamment votre pare-feu de serveur ISA (Microsoft Internet Security and Acceleration). Vous devez à présent concevoir vos implémentations DNS internes et externes pour offrir des services sécurisés de résolution de noms.
À la fin de ce chapitre, vous aurez créé la structure d'un environnement DNS efficace qui traitera de façon efficace les demandes de résolution de nom internes, externes et Active Directory. Vous pourrez ensuite intégrer Active Directory dans cet environnement.
Plusieurs facteurs affectent la conception de votre infrastructure. En général, la solution développée doit répondre aux besoins DNS de Active Directory et de Exchange 2000. En particulier, votre solution doit exploiter la dépendance significative de Active Directory sur DNS comme une ressource de résolution de nom et de localisation de services, ce qui signifie que si Active Directory ne fonctionne pas, Exchange 2000 ne fonctionnera pas non plus.
L'implémentation de Exchange introduit d'autres questions relatives à DNS. La résolution externe des espaces de noms nécessite une attention particulière. Les clients doivent pouvoir se connecter à des services publiés sur l'interface externe de votre ordinateur ISA Server, de sorte qu'ils puissent résoudre un nom d'hôte pour le serveur Exchange 2000 et le mapper sur l'adresse IP (Internet Protocol) de l'interface externe de l'ordinateur ISA Server. En outre, le trafic SMTP (Simple Mail Transfer Protocol) doit fonctionner correctement dans les deux directions. Par exemple, vos serveurs frontaux SMTP doivent pouvoir se connecter au serveur DNS Internet afin de distribuer le courrier aux domaines externes.
Un point important à prendre en considération est que les clients peuvent avoir déjà mis en place diverses configurations DNS. Certains clients hébergent leurs propres serveurs DNS, tandis que d'autres peuvent utiliser un serveur DNS provenant d'un fournisseur de services Internet. D'autres encore peuvent souhaiter que vous hébergiez leur serveur DNS. Nous étudierons comment traiter ces différentes combinaisons.
Enfin, ignorez la sécurité DNS à vos risques et périls. De nombreuses organisations ont appris à leurs dépens que des procédures doivent être suivies pour se protéger des attaques de type refus de service (DoS, Denial of Service) ou des tentatives d'usurpation de DNS. Pour un fournisseur de services d'applications, le fait d'ignorer ces procédures peut s'avérer beaucoup plus gênant et lourd de conséquences que le fameux problème de la disparition d'un site Web. Vous voilà prévenu.
Dans la mesure où la conception du service DNS est la base sur laquelle repose tout le reste, vous devez impliquer au maximum votre équipe de planification à ce stade. En particulier, vous devez impliquer votre architecte DNS, votre concepteur Exchange 2000 et votre architecte Active Directory.
Microsoft recommande aux administrateurs système actuels qui ne sont pas certifiés Windows 2000 ou qui ne sont pas familiarisés avec Exchange 2000 de suivre les cours MOC (Microsoft Official Curriculum) suivants ou de suivre une formation équivalente :
Cours 1562 : Designing a Microsoft Windows 2000 Networking Services Infrastructure (Conception d'une infrastructure de services de gestion réseau Microsoft Windows 2000)
Cours 2153 : Implementing a Microsoft Windows 2000 Network Infrastructure (Implémentation d'une infrastructure de réseau Microsoft Windows 2000)
Cours 1572 : Implementing and Managing Microsoft Exchange 2000 (Implémentation et gestion de Microsoft Exchange 2000)
Avant de commencer à déployer votre architecture DNS, vous devez décider du type de service que vous allez fournir à vos clients, notamment les types de clients que vous allez déployer. Vous devez envisager les problèmes tels que la bande passante disponible et le nombre total d'utilisateurs que vous souhaitez héberger sur votre infrastructure.
La figure 5.1 illustre la disposition des différents composants qui offrent le service de résolution de noms d'hôte DNS dans Microsoft Internet Data Center.
.gif)
Figure 5.1 Composants qui offrent le service de résolution de noms d'hôte DNS dans Microsoft Internet Data Center
La figure 5.2 illustre le processus que vous devez adopter lors de la planification de votre environnement DNS.
.gif)
Dans ce chapitre consacré à la planification, nous introduisons le terme de DNS « interne ». Ce terme désigne un service DNS de portée interne. Le service DNS interne n'offre pas de services DNS à Internet ou à vos clients. Il est utilisé uniquement par vos serveurs Windows 2000 et par les autres serveurs (exécutant Exchange 2000, Active Directory, etc.) qui sont exclusivement internes à votre installation d'hébergement.
Remarque Vos ordinateurs Exchange 2000 qui servent de serveurs frontaux SMTP doivent contacter le DNS Internet. Il s'agit d'un cas spécial qui sera traité ultérieurement.
Un service DNS interne fiable et sûr est essentiel pour le bon fonctionnement de Active Directory et donc de Exchange 2000. En séparant le service DNS interne du service DNS externe utilisé par Internet et par vos clients, vous augmentez considérablement la fiabilité et la sécurité du DNS interne. Cette séparation est souvent appelée DNS « fractionné ».
Ainsi, vous séparez le service interne de résolution de noms utilisé par Active Directory et Exchange 2000 de ce qui se passe en externe, notamment la connexion de vos clients à des services publiés sur vos serveurs ISA.
Ce centre IDC (Internet Data Center) utilise vos contrôleurs de domaine Windows 2000 comme des serveurs DNS internes, hypothèse de départ pour tous les chapitres du guide de planification et de déploiement.
Cette hypothèse se base sur l'utilisation optimale des possibilités offertes par le service DNS de Windows 2000 par rapport aux besoins de Active Directory et donc de Exchange 2000. Pour en savoir plus sur ces besoins, consultez le Guide des ressources de Windows 2000 Server.
Remarque relative à la planification Bien qu'il soit techniquement possible d'utiliser des ordinateurs DNS ne fonctionnant pas sous Windows 2000 (par exemple, UNIX avec BIND version 8.2.x ou ultérieure) pour l'implémentation de votre DNS interne, le centre IDC n'utilise pas cette approche.
Ce chapitre consacré à la planification et le centre IDC supposent que vos serveurs DNS internes utilisent des zones intégrées à Active Directory.
Ces arguments pour l'utilisation de zones intégrées à Active Directory sont documentés en détail dans le « Guide des ressources de Windows 2000 Server ». Pour résumer, les zones intégrées offrent :
une fiabilité accrue grâce à la réplication multimaître ;
une sécurité avancée grâce au cryptage du transfert de zone ;
des performances améliorées, car la réplication s'effectue par propriété.
Dans une zone intégrée à Active Directory, les contrôleurs de domaine qui exécutent le service DNS utilisent les processus de réplication Active Directory pour répliquer les enregistrements DNS. Dans la mesure où il s'agit d'une réplication multi-maître, vous n'avez pas besoin de configurer un serveur DNS maître, ce qui supprime un élément de défaillance potentielle.
Dans le centre IDC, tous vos serveurs DNS internes se trouvent derrière le pare-feu ISA. Tous les autres serveurs se trouvant derrière le serveur ISA utilisent les serveurs DNS internes pour la résolution de noms interne. La raison qui conduit à placer les serveurs DNS internes ici est de s'assurer que les requêtes DNS internes n'auront pas à passer par le serveur ISA.
Les seuls serveurs se trouvant derrière le serveur ISA et qui nécessitent une résolution de noms Internet sont les serveurs frontaux SMTP. La configuration DNS de ces serveurs est étudiée plus loin dans ce chapitre. Le chapitre 7, « Planification des serveurs frontaux », détaille davantage les serveurs frontaux SMTP.
Le centre IDC combine trois ordinateurs DNS et Active Directory internes, basés sur du matériel Compaq, comme indiqué dans le chapitre 1, « Introduction ».
Les ordinateurs DNS internes nécessitent Windows 2000 Advanced Server.
Le guide de déploiement contient des instructions détaillées vous permettant d'installer le centre IDC.
Dans le centre IDC, les serveurs DNS internes sont nommés AD01, AD02 et AD03 ; il s'agit de contrôleurs de domaine du domaine Windows 2000 nwtraders.com.
Dans la mesure où ces serveurs résolvent uniquement les noms internes, vous devez les configurer de la façon suivante :
Utilisez des zones intégrées Active Directory.
Désactivez la récursivité.
Supprimez les racines du cache.
Activez l'option « Sécuriser le cache contre la pollution ».
Limitez les transferts de zone aux serveurs appropriés, c'est-à-dire aux contrôleurs de domaine.
La plupart de ces paramètres sont liés aux problèmes de sécurité, lesquels sont détaillés page 9 de ce chapitre.
Dans la mesure où vos serveurs DNS internes n'ont pas accès à Internet, vous devez les configurer avec une zone racine factice : « . ». Cette zone racine garantit que si un opérateur commet une erreur lors de la saisie d'un nom de domaine, le serveur DNS ne tentera pas d'accéder aux serveurs racine Internet et de déclencher une alerte de sécurité réseau. Par exemple, tapez la commande suivante à l'invite :
PING OWA1.NTRADERS.COM
Dans la mesure où vos serveurs DNS internes font autorité pour la zone racine, il n'est pas possible (ni nécessaire) de configurer le transfert. En effet, ils sont tous capables de contacter la zone racine que vous avez créée. Étant donné que cette zone racine factice devient désormais la racine de la hiérarchie DNS, ils ne peuvent plus transférer ailleurs les demandes de résolution de noms.
Une seule zone de recherche directe (le domaine d'hébergement) doit être configurée sur vos serveurs DNS internes. Dans le centre IDC, le domaine d'hébergement est nwtraders.com.
Comme indiqué dans l'article Q259922 de la Base de connaissances Microsoft, il est recommandé que vos serveurs DNS internes stockent des zones de recherche inverse pour chacun de vos sous-réseaux internes. Dans le centre IDC, il s'agit de :
10.168.192.in-addr-arpa
11.168.192.in-addr-arpa
12.168.192.in-addr-arpa
13.168.192.in-addr-arpa
15.168.192.in-addr-arpa
Étant donné les avantages mentionnés dans la section précédente, les zones de recherche directe et inverse doivent être configurées en tant que zones intégrées à Active Directory. En outre, vous devez configurer ces zones pour accepter uniquement les mises à jour dynamiques sécurisées. Cela permet d'éviter que des systèmes non autorisés (qui ne sont pas membres du domaine d'hébergement) mettent à jour dynamiquement leurs enregistrements hôte dans les zones.
Remarque relative à la planification Dans certains cas, d'autres domaines internes (par exemple, testing.nwtraders.com) ou des forêts Active Directory distinctes peuvent être dédiés à des clients particuliers (par exemple, fabrikam.com). Ces deux scénarios n'entrent pas dans le cadre de ce chapitre consacré à la planification.
Comme nous l'avons vu précédemment, pour garantir le fonctionnement le plus efficace de Active Directory, il est recommandé d'implémenter des enregistrements dynamiques dans votre structure DNS interne.
Votre DNS interne inclura des enregistrements d'emplacement d'hôte enregistré dynamiquement (A) et de serveur (SRV) pour tous les serveurs internes, notamment tous les serveurs de gestion, Active Directory et Exchange.
D'après les spécifications matérielles du centre IDC, il est clair qu'un serveur Windows 2000 unique servant de serveur DNS interne peut facilement faire face au faible nombre de requêtes et enregistrements internes.
Il est cependant recommandé d'utiliser les trois contrôleurs de domaine Windows 2000 pour votre DNS interne afin de permettre une configuration logicielle standard. Cela permet également d'arrêter un contrôleur de domaine unique tout en conservant les autres contrôleurs de domaine pour la tolérance DNS interne.
Remarque relative à la planification L'utilisation de deux serveurs DNS internes est techniquement possible, sous réserve que vous acceptiez le risque de défaillance qui est alors plus élevé.
Pour éviter à vos serveurs DNS internes d'être victimes d'une attaque (telle que l'usurpation DNS), vous ne devez en aucun cas laisser les requêtes DNS en provenance d'Internet passer par vos serveurs DNS internes pour la résolution, ou inversement. Le centre IDC garantit cela en plaçant les ordinateurs DNS internes derrière les serveurs ISA et en utilisant le filtrage de paquets sur les deux serveurs ISA et sur le routeur frontalier. Pour en savoir plus sur la configuration de ISA Server et sur le filtrage de paquets, concernant le DNS interne, consultez le chapitre 4, « Création de l'architecture réseau ».
La configuration des serveurs DNS internes (voir page 7 de ce chapitre) améliore la sécurité des serveurs externes de différentes façons :
en s'assurant que vos serveurs DNS internes effectuent des transferts de zone uniquement entre eux ;
en désactivant la récursivité afin d'empêcher votre DNS interne de résoudre des noms Internet ;
en supprimant les racines du cache afin d'empêcher les serveurs DNS internes d'identifier les adresses des serveurs racines Internet ;
en sécurisant le cache contre les pollutions afin d'éviter de recevoir des enregistrements d'usurpation (hors zone) en réponse à des requêtes DNS normales. Cela ne doit pas être un problème, car ces serveurs n'ont pas accès à Internet et vous avez déjà empêché la récursivité, mais on n'est jamais trop protégé ou trop riche.
Dans ce chapitre consacré à la planification, nous utilisons également le terme DNS « externe ». Il s'agit d'un service DNS avec une portée externe ; il fait partie du DNS Internet et constitue le service de résolution de noms des requêtes entrantes pour le domaine nwtraders.com.
Le DNS externe a deux objectifs :
permettre à l'environnement Exchange hébergé de résoudre des noms DNS (Internet) externes afin de distribuer des messages électroniques SMTP aux domaines externes ;
héberger des noms de domaine enregistrés et les enregistrements de ressource associés pour vos clients, si nécessaire.
Le centre IDC utilise des serveurs Windows 2000 comme serveurs DNS internes, hypothèse de départ pour tous les chapitres du guide de planification et de déploiement.
Remarque relative à la planification Si vous avez déjà investi beaucoup dans les serveurs, les compétences et les outils sur une autre plate-forme DNS, vous souhaiterez peut-être utiliser cette plate-forme plutôt que Windows 2000. Dans la mesure où les serveurs DNS externes ne sont nécessaires que pour prendre en charge les fichiers de zone RFC standard, la plupart des plates-formes doivent être adaptées.
Dans le centre IDC, les serveurs DNS externes se trouvent à l'avant du serveur ISA et présentent une connectivité directe à Internet via le routeur frontalier. Cela expose les serveurs DNS externes à Internet, ce qui les rend vulnérables face aux attaques.
L'attaque la plus courante menée par les personnes malveillantes sur Internet en direction des serveurs DNS vulnérables est l'usurpation DNS. L'usurpation DNS est basée sur la contamination du cache et est souvent utilisée par les pirates pour intercepter du courrier électronique ou pour rediriger l'accès Web vers des hôtes incorrects. Vous trouverez davantage de détails sur l'usurpation DNS dans la section « Sécurité DNS », page 16 de ce chapitre.
Vous pouvez configurer vos serveurs DNS externes qui exécutent Windows 2000 afin de fournir un degré élevé de tolérance pour l'usurpation DNS. Deux fonctionnalités contribuent à cette tolérance : il s'agit de la fonctionnalité « Sécuriser le cache contre la pollution » et le fait que le DNS Windows 2000 utilise des numéros de séquence UDP (User Datagram Protocol) DNS aléatoires.
Dans un environnement ASP, le serveur peut être sujet à des attaques moins courantes, telles que l'attaque en force sur les numéros de séquence 16 bits. Même si le risque peut être faible, l'effet d'une attaque sur vos serveurs DNS externes peut s'avérer catastrophique. Dans le cas le pire, vos clients ne pourront plus accéder à leur messagerie électronique, ni envoyer ou recevoir de courrier.
Pour offrir la meilleure protection possible contre les attaques DNS actuelles et futures, le centre IDC utilise un modèle de « service séparé ». Bien que le nom de ce modèle et la terminologie associée soient définis par Cricket Liu, ce modèle n'est pas inclus dans la version actuelle du livre DNS & BIND, dont il est le co-auteur. Remarquez que dans certaines documentations sur DNS, le modèle est appelé « modèle partagé-partagé ».
Dans la mesure où la théorie à la base du modèle de service séparé n'est actuellement documentée dans aucune publication Microsoft, cette section inclut une description approfondie de ce modèle, en rapport avec le centre IDC.
Remarque relative à la planification Bien que le DNS de service séparé ne soit pas nécessaire pour fournir des services Exchange hébergés, celui-ci est fortement recommandé.
Le modèle de service séparé offre davantage de tolérance face à l'usurpation DNS (et aux autres attaques similaires) grâce à la répartition de la structure DNS externe en services distincts d'annonce et de résolution, sur des serveurs DNS externes physiquement distincts.
Les serveurs d'annonce écoutent uniquement les requêtes en provenance d'Internet. Ces requêtes sont résolues uniquement lorsque le serveur entrant fait autorité pour la zone demandée (par exemple, contoso.com). Les serveurs d'annonce ne génèrent pas de requêtes sortantes et la récursivité n'est pas autorisée.
Les serveurs de résolution écoutent uniquement les requêtes en provenance des serveurs frontaux SMTP, via ISA Server. Ces requêtes sont résolues soit lorsque le serveur sortant fait autorité pour la zone (c'est-à-dire, un de vos clients), soit via la récursivité sur Internet pour la zone demandée (par exemple, microsoft.com).
D'après la conception définie dans ce guide, votre DNS externe inclura des zones DNS (par exemple, contoso.com) pour un maximum de 800 clients.
Dans le centre IDC, les zones intégrées à Active Directory ne sont pas utilisées sur les serveurs DNS externes. En revanche, les zones sont stockées sous forme de fichiers RFC DNS standard, sans prise en charge de l'enregistrement dynamique. La raison de cette décision est que pour prendre en charge les zones intégrées, il faudrait que les serveurs DNS externes s'exécutent en tant que contrôleurs de domaine Active Directory.
Remarque relative à la planification Bien qu'il soit techniquement possible d'autoriser l'accès à Active Directory via le serveur ISA, vous devez éviter de procéder ainsi, en raison des conséquences sur la sécurité, lesquelles ne sont pas traitées dans ce chapitre.
Lorsque cela est possible, vous devez héberger les zones DNS de vos clients, car cela facilite le changement des enregistrements de ressource, en cas de besoin. Rappelez-vous que si cela n'est pas possible, l'administrateur des zones des clients concernés devra ajouter des enregistrements de ressource qui pointent vers vos serveurs. Vous trouverez plus de détails sur ce point plus loin dans ce chapitre.
Pour réduire le risque que quelqu'un trafique vos zones hébergées, il est recommandé que l'un de vos serveurs de résolution soit le serveur principal pour toutes les zones hébergées et que vos serveurs d'annonce soient des serveurs secondaires pour toutes les zones. Dans le centre IDC, EXDNS1 est le serveur principal pour toutes les zones principales hébergées.
Le centre IDC inclut quatre serveurs DNS externes, basés sur du matériel Compaq, comme indiqué dans le chapitre 1, « Introduction ».
Les serveurs DNS externes nécessitent Windows 2000 Server. Le guide de déploiement contient des instructions détaillées et/ou des scripts vous permettant d'installer le centre IDC.
Dans le centre IDC, les serveurs DNS de résolution externes sont nommés EXDNS1 et EXDNS2. Les serveurs DNS d'annonce externes sont nommés EXDNS3 et EXDNS4. Tous les serveurs DNS externes sont des serveurs autonomes dans le groupe de travail WG11.
Dans la mesure où ces serveurs ne doivent pas résoudre de noms Internet, vous devez les configurer de la façon suivante :
Désactivez la récursivité.
Supprimez les racines du cache.
Placez chaque serveur sur un sous-réseau différent (consultez la remarque de planification qui suit).
Activez l'option « Sécuriser le cache contre la pollution ».
Limitez les transferts de zone aux serveurs appropriés.
La plupart de ces paramètres sont liés aux problèmes de sécurité, lesquels sont détaillés page 15 de ce chapitre.
Remarque relative à la planification Bien que certaines publications DNS recommandent de placer des serveurs d'annonce sur différents sous-réseaux afin de réduire le risque de certains types d'attaques, cette solution n'est pas implémentée dans la structure de référence.
Dans la mesure où ces serveurs doivent résoudre des noms Internet, vous devez les configurer de la façon suivante :
Activez la récursivité (il s'agit de la configuration par défaut).
Activez l'option « Sécuriser le cache contre la pollution ».
Limitez les transferts de zone aux serveurs appropriés.
Mettez à jour les indications de racines si elles ont changé (voir ftp://rs.internic.net/domain/named.root
.gif)
).
La plupart de ces paramètres sont liés aux problèmes de sécurité, lesquels sont détaillés page 15 de ce chapitre.
Pour chacun de vos clients qui hébergent leur serveur DNS chez vous, vous devrez ajouter une zone DNS primaire à un de vos serveurs DNS externes. Dans le centre IDC, les zones sont ajoutées au serveur de résolution (EXDNS1). Le processus normal de réplication de zones transfère alors ces zones vers les serveurs d'annonce (EXDNS3 et EXDNS4).
Ce chapitre suppose que vous allez ajouter des zones client et des enregistrements de ressources à vos serveurs DNS externes à l'aide d'un système d'approvisionnement. Pour chaque domaine client que vous ajoutez, votre système d'approvisionnement devra ajouter un enregistrement MX pour chaque domaine client, et cet enregistrement doit pointer vers vos serveurs SMTP entrants. Dans le centre IDC, il s'agit de smtp.nwtraders.com.
Remarque relative à la planification Si vous hébergez uniquement les domaines de quelques clients, le processus d'ajout de zones et d'enregistrements de ressources peut être effectué manuellement.
Vous devrez également ajouter une zone pour votre domaine hébergé. Dans le centre IDC, il s'agit du domaine nwtraders.com, lequel inclut les enregistrements de ressources répertoriés dans le tableau ci-après.
Enregistrements DNS externes pour Exchange hébergé
|
D'après les spécifications matérielles, il est clair qu'un serveur Windows 2000 unique, agissant en tant que serveur d'annonce DNS, offrirait des performances élevées, bien au-delà des 800 zones client spécifiées dans le guide de planification.
Dans le centre IDC, quatre serveurs Windows 2000 sont utilisés pour le DNS externe afin de fournir la structure de service séparé et la tolérance de panne DNS.
Remarque relative à la planification Le centre IDC a été spécifié et testé pour accepter jusqu'à 10 000 enregistrements source au total pour tous vos clients.
Le centre IDC implémente une structure de service séparé, qui offre par nature un degré élevé de protection contre les attaques en provenance des nombreux pirates qui sévissent sur Internet.
La configuration des serveurs DNS externes (voir page 13 de ce chapitre) améliore la sécurité des serveurs externes de deux façons :
en activant l'option « Sécuriser le cache contre la pollution » ;
en limitant les transferts de zone aux serveurs appropriés.
Pour protéger davantage vos serveurs DNS externes contre les risques d'attaques d'usurpation ou de type DoS, votre serveur ISA et votre routeur frontalier doivent être configurés avec soin s'agissant des requêtes DNS sur le port 53 (UDP), comme le montrent les tableaux suivants.
Configuration de ISA Server
|
Configuration du routeur frontalier
|
Nous ne pouvons pas documenter toutes les variantes d'usurpation DNS dans ce document. Pour en savoir plus sur ce sujet, consultez les sites Web de SANS Institute et CERT®. Pour connaître les adresses de ces organisations, consultez la section « Informations complémentaires » à la fin de ce chapitre.
La majorité des attaques d'usurpation a lieu parce que la plupart des serveurs DNS externes exécutent deux fonctions :
des services de résolution de noms Internet pour les hôtes sur leur emplacement, via une résolution itérative vers des serveurs de noms Internet ;
des services d'annonce pour les hôtes Internet, pour une ou plusieurs zones DNS pour lesquelles ils font autorité.
Un pirate crée d'abord une zone dans laquelle il fait autorité (par exemple, adatum.com) et place des données malveillantes dans la zone. Il inclut ensuite ces données dans la zone, il s'agit généralement d'enregistrements hors zone (souvent appelés « glue »). Un exemple consiste à inclure des enregistrements MX pour msn.com, qui pointent vers le serveur de noms de messagerie du pirate.
Le lancement de l'attaque est simple : le pirate interroge simplement la victime afin de connaître le domaine du pirate, dans ce cas adatum.com. La victime accède ensuite au domaine du pirate et met en cache les données renvoyées, y compris les données malveillantes, dans ce cas les enregistrements MX de msn.com. Cela est illustré dans le schéma ci-dessous.
Dans certains cas, les attaques ne sont pas détectées immédiatement, car le pirate usurpe uniquement les enregistrements MX et transfère ensuite tout le courrier électronique vers la destination correcte. Malheureusement pour les victimes, cela signifie que le pirate a pu intercepter et lire le courrier électronique pendant un certain temps.
La figure suivante illustre cet exemple d'usurpation.
.gif)
Figure 5.2 Exemple d'attaque d'usurpation DNS
Comme nous l'avons vu précédemment, vos serveurs d'annonce DNS acceptent les requêtes entrantes uniquement en provenance des ordinateurs d'Internet et résolvent les requêtes uniquement pour vos serveurs hébergés (par exemple, mail.contoso.com). Les serveurs d'annonce n'acceptent pas les requêtes récursives et n'interrogent pas les serveurs de noms Internet.
Cela permet d'interrompre l'attaque illustrée à l'étape 1 de la figure précédente, car le serveur d'annonce DNS ne résout pas la requête récursive pour adatum.com.
Dans ce chapitre consacré à la planification, nous introduisons le terme de DNS « client ». Il s'agit du service DNS auquel accèdent les utilisateurs de vos clients.
Dans le centre IDC, les utilisateurs de vos clients se connectent à Microsoft Outlook® Web Access (OWA) et à Exchange par l'intermédiaire de votre domaine hébergé, à savoir nwtraders.com. Comme cela est détaillé dans le chapitre 7, « Planification des serveurs frontaux », la seule condition requise pour DNS du point de vue du client concerne SMTP.
Remarque relative à la planification Si vous prévoyez d'utiliser le transfert Outlook Web Access (par exemple, http://mail.contoso.com), vous devrez ajouter un enregistrement propre au client pour OWA.
Les chapitres consacrés à la planification supposent que vos clients accèderont à votre service Exchange hébergé via Internet. Cette section détaille les solutions que vous pouvez mettre en œuvre pour offrir à vos clients un service fiable et efficace de résolution de noms pour vos serveurs.
Remarque relative à la planification Si les clients se connectent directement à votre installation d'hébergement (par l'intermédiaire de liaisons T1 ou E1, par exemple), vous ne devez pas utiliser l'option ISP.
La configuration du fichier « hosts » locaux sur chacun des postes de vos clients représente une solution potentiellement très fiable, car le client ne dépend pas de serveurs DNS locaux ou Internet. En outre, dans la mesure où la résolution de noms d'hôtes examine les entrées du fichier « hosts » avant DNS, vous ne serez pas vulnérable face aux attaques d'usurpation DNS locales ou en provenance d'Internet.
La difficulté réside dans la configuration initiale du fichier « hosts » et dans les modifications ultérieures. Bien qu'une page Web d'approvisionnement du client puisse être utilisée pour la configuration initiale du fichier « hosts », vous êtes alors confronté au problème de la mise à jour du fichier, en particulier parce que vos clients interdiront probablement l'exécution de scripts Web.
Si un client dispose d'une infrastructure DNS externe établie, fiable et sécurisée, il souhaitera peut-être continuer à gérer sa propre zone sur ses propres serveurs DNS. Dans ce cas, le client devra ajouter des enregistrements de ressources MX à sa zone pointant vers vos serveurs SMTP, par exemple smtp.nwtraders.com.
Remarque relative à la planification Si vous prévoyez d'utiliser le transfert OWA (par exemple, http://mail.contoso.com), vous devrez ajouter un enregistrement propre au client pour OWA.
En fonction des compétences d'administration DNS du client, il peut s'agir d'une solution fiable, car elle ne dépend pas des serveurs de noms Internet. Cependant, si vous apportez des modifications à votre architecture, vos clients devront mettre à jour leurs zones.
Il est souhaitable d'éviter cette solution, car elle intègre un tiers dans la structure DNS. Elle est également moins fiable, car les serveurs DNS du fournisseur peuvent être l'objet de défaillances ou d'attaques et échappent à votre contrôle (ainsi qu'à celui de vos clients). Idéalement, vous devez convaincre le client de transférer sa zone de son fournisseur existant vers votre propre installation.
Remarque relative à la planification Dans certains cas, le client peut utiliser le même fournisseur de services Internet pour héberger son site Web (par exemple, https://www.contoso.com). Cependant, le site Web est souvent un simple répertoire virtuel (http://www.contoso.adatum.com) et le fournisseur utilise le transfert Web. Dans ce cas, il peut s'avérer nécessaire que le client procède à une mise à niveau vers un serveur virtuel s'il souhaite conserver le site Web chez le fournisseur de services Internet tout en vous confiant l'hébergement de son serveur DNS.
Si votre client est décidé à conserver sa zone auprès de son fournisseur actuel, ce dernier devra ajouter (ou modifier) l'enregistrement MX du client. Vous devez avertir le client par écrit que les problèmes de serveur DNS du fournisseur risquent de l'empêcher de recevoir son courrier électronique. Vous devez également vous assurer que vos accords de niveau de service excluent la défaillance du serveur DNS du fournisseur, dans la mesure où il n'est pas sous votre contrôle.
Lorsque votre client ne dispose pas d'une infrastructure DNS fiable, la solution préférable consiste pour vous à héberger son serveur DNS externe. Cette solution peut vous apporter un revenu complémentaire, car les clients devront vous confier l'hébergement des enregistrements DNS de leurs serveurs accessibles via Internet, tels que leur site Web.
Remarque relative à la planification Idéalement, vous devez offrir un service d'approvisionnement via le Web afin de permettre au client de gérer ses enregistrements DNS complémentaires. La planification et le déploiement d'un tel service n'entrent pas dans le cadre de ce guide.
Dans cette solution, si un client dispose de ses propres serveurs DNS, il est important qu'ils n'utilisent pas le même nom de domaine en interne, car leurs clients ne pourraient pas résoudre les noms de vos serveurs. En interne, le client doit utiliser soit un sous-domaine délégué à partir de votre zone, soit un domaine totalement distinct. Par exemple, si vous hébergez contoso.com, le client peut utiliser soit corp.contoso.com (un sous-domaine), soit corp-contoso.com (un domaine distinct).
Pour éviter les dépendances de serveurs de noms Internet, les serveurs DNS du client doivent inclure des enregistrements NS (serveur de noms) et A (hôte) pour le domaine que vous hébergez pour lui.
Par exemple, si votre client utilise le domaine corp-contoso.com, il ajoutera les enregistrements suivants à sa zone :
;ASP Hosted Name servers
;
; NWTraders hosts our domain CONTOSO.COM
ns1.nwtraders.com. IN NS contoso.com.
ns2.nwtraders.com. IN NS contoso.com.
; include address so we don't rely on ISP NS
ns1.nwtraders.com. IN A 10.4.1.1
ns2.nwtraders.com. IN A 10.4.1.2
Ces enregistrements sont souvent appelés glue, car ils sont normalement utilisés pour réunir des domaines et des sous-domaines. Un enregistrement « glue » est un enregistrement de ressource qui se trouve en dehors de la zone qui fait autorité (voir DNS & BIND 3rd Edition, chapitre 9).
Dans ce chapitre, nous avons étudié les questions de planification dont vous devrez tenir compte lors de la conception de votre infrastructure DNS. Nous avons abordé les différentes implémentations de DNS que vous devrez configurer, ainsi que les approches distinctes à observer pour les serveurs DNS internes, externes et du client. Vous devez maintenant être capable de créer un environnement DNS sécurisé et tolérant, qui offrira des services efficaces de résolution de noms pour Active Directory, vos serveurs internes et les utilisateurs de vos clients.
Pour en savoir plus sur DNS et sur les différents concepts étudiés dans ce chapitre, consultez les références ci-après.
Active Directory Services for Windows 2000 Technical Reference (Services Active Directory pour Windows 2000 : référence technique), David Iseminger
Windows 2000 TCP/IP Protocols and Services Technical Reference (Protocoles et services TCP/IP Windows 2000 : référence technique), Lee Davies
Windows 2000 Server Deployment Planning Guide (Guide de planification du déploiement de Windows 2000 Server)
DNS & BIND 3rd Edition – Cricket Liu, Paul Albitz, Mike Loukides, aux éditions O'Reilly & Associates
Q255134 : Installing Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) on a Domain Controller
Outils d'assistance de Windows 2000
Les informations contenues dans ce document représentent l'opinion actuelle de Microsoft sur les points cités à la date de publication. Microsoft s'adapte aux conditions fluctuantes du marché et cette opinion ne doit pas être interprétée comme un engagement de la part de Microsoft ; de plus, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de publication.
Ce livre blanc est fourni pour information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, QUANT AUX INFORMATIONS CONTENUES DANS CE DOCUMENT.
L'utilisateur est tenu d'observer la réglementation relative aux droits d'auteur applicables dans son pays Sans restriction des droits dérivés des droits d'auteur, aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de récupération de données ou transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou dans quelque but que ce soit sans la permission expresse et écrite de Microsoft Corporation.
Les produits mentionnés dans ce document peuvent être couverts par des brevets, des dépôts de brevets en cours, des marques, des droits d'auteur ou d'autres droits de propriété intellectuelle et industrielle de Microsoft. Sauf indication expresse figurant dans un contrat de licence écrit émanant de Microsoft, la fourniture de ce document ne vous concède aucune licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.
Microsoft, Windows, Active Directory et Outlook sont des marques déposées et des marques commerciales de Microsoft Corporation aux États-Unis et/ou dans les autres pays.
Les noms de sociétés et de produits mentionnés sont des marques de leurs propriétaires respectifs.
Dernière mise à jour le lundi 22 octobre 2001
Pour en savoir plus