7. Renforcement de la sécurité pour des rôles de serveur spécifiques

Dans le chapitre précédent, nous avons expliqué dans le détail comment mettre au point et déployer une stratégie de sécurité de base à l'aide d'une stratégie de groupe pour les serveurs Microsoft® Windows® 2000 Server, dans le scénario Contoso. Lorsque vous avez défini une stratégie de base pour ces serveurs, vous devez étudier les méthodes de sécurisation de chaque serveur en fonction de leur rôle dans l'infrastructure de votre organisation.

Ce chapitre présente les paramètres de sécurité recommandés afin de sécuriser l'environnement des quatre principaux rôles de serveurs suivants, présents dans la plupart des organisations exécutant des serveurs Windows 2000 Server :

contrôleur de domaine du service d'annuaire Microsoft® Active Directory® ;

serveur d'infrastructure, fournissant des services DHCP (Dynamic Host Configuration Protocol) et WINS (Windows Internet Naming Services) ;

serveur de fichiers et d'impression ;

serveur IIS (Internet Information Services).

Chaque serveur de votre environnement héberge une série de services d'applications, lesquelles, pour offrir une disponibilité et une fiabilité maximales, imposent la mise en œuvre de paramètres de sécurité supplémentaires. Ces groupes de paramètres de sécurité assurent la protection des données accessibles au départ de ces serveurs. Comme expliqué dans la section traitant de la stratégie de base des serveurs membres au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base », la stratégie de groupe sert à appliquer autant de mesures de sécurité que possible aux serveurs Windows 2000 d'un environnement.

Pour chaque rôle de serveur, les paramètres de stratégie de groupe sont enregistrés dans des modèles de sécurité individuels, eux-mêmes importés dans un objet Stratégie de groupe correspondant. Un objet Stratégie de groupe est un ensemble de paramètres de stratégie de groupe utilisés pour définir des paramètres de sécurité dans un environnement Windows 2000.

Par exemple, pour sécuriser les serveurs IIS dans ce scénario, les paramètres de stratégie de groupe décrits sont enregistrés dans le modèle de sécurité MSS IIS Role.inf. Ce modèle est importé dans l'objet Stratégie de groupe pour la stratégie de groupe IIS liée à l'unité d'organisation Web, dans le domaine enfant créé pour Contoso.

L'emplacement des objets Stratégie de groupe de Contoso au sein d'Active Directory est mis en évidence dans la figure suivante :

Figure 7.1.

Les modèles de sécurité pour chaque rôle de serveur sont importés dans l'objet Stratégie de groupe pertinent lié à l'unité d'organisation de ce rôle.

Les paramètres du modèle de sécurité correspondant à chaque rôle de serveur illustré ci-dessus sont définis dans ce chapitre. Néanmoins, certaines procédures de renforcement de la sécurité ne peuvent pas être automatisées par une stratégie de groupe. Lorsque c'est le cas, les procédures spécifiques recommandées sont développées plus loin dans le chapitre.

Le modèle de sécurité MSS Baseline.inf, détaillé au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base », sert également de fondement au modèle de sécurité appelé MSS DCBaseline Role.inf. Les différences entre ces deux modèles sont expliquées dans ce chapitre, à la section traitant de la stratégie de groupe des contrôleurs de domaines.

Rôle de contrôleur de domaine Active Directory

La protection du rôle de serveur contrôleur de domaine est cruciale dans un environnement d'entreprise Windows 2000 Active Directory. En effet, la perte ou la compromission des contrôleurs de domaines aurait un effet dévastateur sur les clients, serveurs et applications qui recourent à des services tels que l'authentification, les stratégies de groupe et l'annuaire central LDAP (Lightweight Directory Access Protocol).

En raison de leur importance, les contrôleurs de domaines doivent être placés dans des locaux sécurisés, accessibles exclusivement au personnel administratif qualifié. Si vous n'avez d'autre choix que de les installer dans des locaux non sécurisés, par exemple dans des succursales, vous pouvez définir des paramètres de sécurité particuliers afin de limiter l'impact de potentiels dégâts physiques. Le cas échéant, des recommandations spécifiques aux contrôleurs de domaine non protégés physiquement seront présentées dans ce chapitre.

Stratégie de base des contrôleurs de domaines

À la différence des autres stratégies spécifiques aux rôles de serveurs détaillées dans ce chapitre, la stratégie de groupe destinée au rôle de contrôleur de domaine est une stratégie de base, ce qui la place dans la même catégorie que la stratégie de base des serveurs membres, définie au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ». En d'autres termes, la stratégie de groupe des contrôleurs de domaines revient à appliquer uniquement deux stratégies de sécurité par défaut, la stratégie de domaine par défaut, héritée du conteneur Domaine, et la stratégie des contrôleurs de domaines par défaut, définie dans l'unité d'organisation Contrôleurs de domaine.

Comme la stratégie de base des contrôleurs de domaines se fonde sur la stratégie de base des serveurs membres, vous devez lire le chapitre 6 pour comprendre un grand nombre des paramètres communs à ces deux types de stratégies. Une grande partie de la première est une copie directe de la seconde. Tous les paramètres de la stratégie de base des contrôleurs de domaines qui diffèrent de la stratégie de base des serveurs membres sont exposés dans cette section.

Remarque : La question de la protection du service d'annuaire (contenu d'Active Directory, notamment ses objets, classes et attributs) est abordée au chapitre 5, « Sécurisation de l'infrastructure du domaine ».

Paramètres de stratégie d'audit

Les paramètres de la stratégie d'audit associée à la stratégie de base des contrôleurs de domaines sont identiques à ceux spécifiés pour les serveurs membres. Les paramètres de la stratégie de base garantissent que toutes les informations d'audit de sécurité pertinentes sont consignées dans un journal sur les contrôleurs de domaines, y compris l'accès aux services d'annuaire.

Paramètres du journal des événements

Les paramètres du journal des événements dans la stratégie de base des contrôleurs de domaines sont identiques à ceux spécifiés pour les serveurs membres.

Affectation des droits d'utilisateur

La stratégie des contrôleurs de domaines par défaut spécifie un certain nombre d'affectations de droits d'utilisateur pour les contrôleurs de domaines. Outre ces paramètres par défaut, il existe deux droits d'utilisateur dont la sécurité doit être renforcée dans le cas des contrôleurs de domaines :

· Ouvrir une session localement

· Arrêter le système

Les paramètres recommandés pour ces droits sont précisés dans le tableau suivant.

Tableau 7.1. Paramètres de droits d'utilisateur pour la stratégie de base des contrôleurs de domaines

Droit d'utilisateur dans l'interface

Groupes affectés

Recommandation

Ouvrir une session localement

Administrateurs

Opérateurs de sauvegarde

Opérateurs de serveur

Supprimez les groupes Opérateurs de compte et Opérateurs d'impression car ils ne sont employés que pour la gestion des comptes. Les partages d'imprimantes ne doivent pas être autorisés au départ des contrôleurs de domaines.

Arrêter le système

Administrateurs

Opérateurs de serveur

Supprimez les groupes Opérateurs de compte, Opérateurs de sauvegarde et Opérateurs d'impression, car ils ne doivent pas être autorisés à arrêter les contrôleurs de domaines.

Ouvrir une session localement

Vulnérabilité

Tout compte disposant du droit Ouvrir une session localement peut être employé pour se connecter à la console d'un contrôleur de domaine. Lorsqu'une personne utilise les services Terminal Server sur le réseau, le compte exige aussi de bénéficier du droit Ouvrir une session localement. Si un utilisateur tente d'ouvrir une session sur le serveur au moyen des services Terminal Server, elle doit recourir à un compte bénéficiant également des autorisations Accès Invité ou Accès Utilisateur pour le protocole RDP (Remote Desktop Protocol) des services Terminal Server.

Dans le cadre des bonnes pratiques, il est recommandé d'interdire aux utilisateurs non autorisés d'ouvrir une session localement. Dans le cas des contrôleurs de domaines, cette bonne pratique s'applique généralement aux groupes Opérateurs de compte et Opérateurs d'impression. L'octroi de ce privilège offre à des utilisateurs non autorisés la possibilité de télécharger, de consulter, voire d'installer du nouveau code, qui peut par la suite être utilisé pour exploiter les vulnérabilités d'élévation de privilèges nécessitant un accès local.

Contre-mesure

Supprimez les deux groupes par défaut suivants : Opérateurs de compte et Opérateurs d'impression. Aucun de ces groupes par défaut n'a réellement besoin d'ouvrir une session sur les contrôleurs de domaines de votre environnement. Effectuez cette opération par l'intermédiaire de la stratégie de base des contrôleurs de domaines.

Vous pouvez également ajouter ces groupes au privilège Refuser les ouvertures de session locales, dans la stratégie de base des contrôleurs de domaines. Ce paramètre de privilège se configure dans le modèle de stratégie de base des contrôleurs de domaines.

Impact potentiel

La suppression de ces groupes par défaut peut limiter les activités déléguées de certains rôles d'utilisateur attribués dans votre environnement. Vérifiez donc que les activités ayant fait l'objet d'une délégation ne s'en trouvent pas affectées.

Scénario Contoso

Seuls les groupes Administrateurs, Opérateurs de sauvegarde et Opérateurs de serveur disposent du privilège Ouvrir une session localement sur les contrôleurs de domaines de Contoso. Les opérateurs de sauvegarde ont besoin de ce privilège pour utiliser les logiciels de sauvegarde, qui nécessitent des comptes de service. Les opérateurs de serveur, quant à eux, doivent en bénéficier pour pouvoir arrêter les contrôleurs de domaines, car il est également nécessaire d'ouvrir une session sur un contrôleur de domaine pour être en mesure de l'arrêter.

Dans la configuration mise en œuvre, ces groupes par défaut ont été supprimés dans le modèle de stratégie de base des contrôleurs de domaines.

Arrêter le système

Vulnérabilité

L'autorisation d'arrêter les contrôleurs de domaines doit être réservée à un très petit nombre d'administrateurs de confiance. Même si l'arrêt du système exige de pouvoir ouvrir une session sur le serveur, vous devez être très prudent quant aux comptes et aux groupes que vous autorisez à arrêter un contrôleur de domaine. Pour plus de détails à ce propos, reportez-vous au chapitre 6, plus particulièrement à la section traitant du paramètre Permet au système d'être arrêté sans avoir à se connecter.

Lorsqu'un contrôleur de domaine est arrêté, il ne peut plus exécuter des fonctions telles que le traitement des ouvertures de session, l'application de stratégies de groupe ou la réponse aux requêtes LDAP. L'arrêt de contrôleurs de domaines jouant des rôles de maître des opérations pourrait désactiver des fonctionnalités clés du domaine, comme le traitement des ouvertures de session pour de nouveaux mots de passe (rôle d'émulateur PDC).

Contre-mesure

Supprimez les trois groupes par défaut suivants de toute stratégie de base des contrôleurs de domaines qui accorde le privilège Arrêter le système : Opérateurs de compte, Opérateurs de sauvegarde et Opérateurs d'impression. Ces groupes par défaut ne devraient pas avoir besoin d'arrêter des contrôleurs de domaines.

En revanche, vous pouvez toujours déléguer le droit d'arrêter des contrôleurs de domaines à d'autres groupes. Gardez cependant à l'esprit qu'il n'est généralement pas souhaitable d'arrêter les bases de données centrales d'authentification dans la mesure où les utilisateurs ne pourront plus être authentifiés par le domaine.

Impact potentiel

La suppression de ces groupes par défaut peut restreindre les activités déléguées de certains rôles d'utilisateur attribués dans votre environnement. Vérifiez donc que les activités ayant fait l'objet d'une délégation ne s'en trouvent pas affectées.

Scénario Contoso

Seuls les groupes Administrateurs et Opérateurs de serveur disposent du privilège Arrêter le système sur les contrôleurs de domaines de Contoso. Les opérateurs de sauvegarde n'ont pas besoin de ce privilège pour utiliser les logiciels de sauvegarde. Les opérateurs de serveur, en revanche, doivent en bénéficier parce qu'ils sont souvent chargés, par délégation, d'arrêter les contrôleurs de domaines sans pour autant appartenir au groupe Administrateurs. La suppression dees groupes par défaut a été configurée dans le modèle de stratégie de base des contrôleurs de domaines.

Options de sécurité

Le tableau ci-dessous présente les options de sécurité qui diffèrent des paramètres de la stratégie de base des serveurs membres, ou qui nécessitent une configuration particulière dans le cas d'un contrôleur de domaine. Aucun de ces paramètres n'exige une quelconque modification de la configuration par défaut des clients pour prendre en charge la connectivité avec les contrôleurs de domaines.

Tableau 7.2. Options de sécurité de la stratégie de base des contrôleurs de domaines

Option de sécurité dans l'interface utilisateur	Recommandation	Commentaire
Restrictions supplémentaires pour les connexions anonymes	Ne pas autoriser l'énumération des comptes et partages SAM	Identique au commentaire relatif à la stratégie de base des serveurs membres, au chapitre 6. Cet élément est particulièrement important pour les contrôleurs de domaines.
Permet aux opérateurs de serveur de planifier des tâches (Contrôleurs de domaine uniquement)	Désactivé	Les opérateurs de serveur ne nécessitent pas ce niveau de privilège sur les contrôleurs de domaines.
Signer numériquement les communications client (toujours)	Activé	Identique au commentaire relatif à la stratégie de base des serveurs membres, au chapitre 6. L'activation de ce paramètre a un impact non négligeable sur les performances des serveurs.
Signer numériquement les communications serveur (toujours)	Désactivé	Identique au commentaire relatif à la stratégie de base des serveurs membres, au chapitre 6. L'activation de ce paramètre a un impact non négligeable sur les performances des serveurs.
Niveau d'authentification Lan Manager	Envoyer uniquement les réponses NTLM v. 2	Identique au commentaire relatif à la stratégie de base des serveurs membres, au chapitre 6. Requis pour la prise en charge des clients Windows 98 SE.
Nombre d'ouvertures de session précédentes dans le cache (au cas où le contrôleur de domaine ne serait pas disponible)	0 ouverture de session	Il n'y a aucune raison de prendre en charge les ouvertures de session de compte de domaine mises en cache, puisque ces serveurs sont eux-mêmes les contrôleurs de domaines.
Canal sécurisé : crypter ou signer numériquement les données des canaux sécurisés (toujours)	Activé	Identique au commentaire relatif à la stratégie de base des serveurs membres, au chapitre 6. Requis pour la prise en charge des clients Windows 98 SE et de tout contrôleur de domaine Microsoft® Windows NT® 4.0 Service Pack 5 ou antérieur, dans des domaines locaux et approuvés.

Certaines des options de sécurité indiquées dans le tableau 7.2 méritent de plus amples explications. Le reste de la section présente les raisons justifiant l'implémentation de tels paramètres sur les contrôleurs de domaines du scénario Contoso.

Restrictions supplémentaires pour les connexions anonymes

Les contrôleurs de domaines sont particulièrement sensibles aux besoins en termes d’accès anonyme de certains clients. Pour cette raison, ils doivent permettre les connexions anonymes afin de prendre en charge les types de fonctionnalités suivantes :

· relations d'approbation interforêts ;

· relations d'approbation avec des domaines Windows NT 4.0 ;

· serveurs RRAS (Routing and Remote Access Services) Windows NT 4.0 aux fins de recherche d'appartenance aux groupes pour les comptes d'utilisateur de domaine ;

· clients Windows 98 SE et Windows NT 4.0 avec connexions via un canal sécurisé pour les ouvertures de session de domaine.

Permettre aux opérateurs de serveur de planifier des tâches (Contrôleurs de domaine uniquement)

Vulnérabilité

Des utilisateurs légitimes appartenant au groupe Opérateurs de serveur pourraient planifier des tâches dans le groupe Contrôleurs de domaine. Comme le service Planificateur de tâches s'exécute par défaut en tant que système, un pirate qui serait membre du groupe Opérateurs de serveur pourrait exploiter ce privilège. À titre d'exemple, il pourrait planifier une tâche qui ajouterait son compte au groupe Administrateurs du domaine.

Contre-mesure

Attribuez la valeur Désactivé à l'option Permet aux opérateurs de serveur de planifier des tâches (Contrôleurs de domaine uniquement).

Impact potentiel

Seuls des utilisateurs disposant de privilèges d'administrateur de domaine pourront planifier des tâches via le service Planificateur de tâches sur les contrôleurs de domaines.

Scénario Contoso

Dans le scénario Contoso, la planification de tâches sur les contrôleurs de domaines est exclusivement réservée aux administrateurs. La stratégie de groupe a été utilisée pour affecter la valeur Désactivé à l'option Permet aux opérateurs de serveur de planifier des tâches (Contrôleurs de domaine uniquement).

Signer numériquement les communications client/serveur

Le paramètre corollaire Signer numériquement les communications client (lorsque cela est possible) doit être activé sur tous les ordinateurs clients avant que soit activée l'option Signer numériquement les communications client (toujours) sur vos contrôleurs de domaines. Ces paramètres doivent être activés dans cet ordre pour permettre aux clients du domaine de communiquer correctement avec vos contrôleurs de domaines.

Niveau d'authentification Lan Manager

Pour le contrôleur de domaine Windows 2000, il est particulièrement important que tous les clients puissent s'authentifier auprès d'un contrôleur de domaine dans un premier temps, pour rejoindre le domaine et, par la suite, en faire partie. Il est également essentiel que les contrôleurs de domaines s'authentifient auprès de contrôleurs d'autres domaines (domaines interforêts ou Windows NT 4.0) afin de valider les informations d'authentification à l'extérieur de la forêt. Ces deux opérations nécessitent une forme quelconque d'authentification LAN Manager (c’est-à-dire avec un protocole d'authentification différent de Kerberos version 5).

Tous les clients Windows (y compris Windows 2000 et Microsoft® Windows® XP) sont configurés par défaut pour envoyer des réponses d'authentification LM (LAN Manager) et NTLM (à l'exception des clients Windows 9x, qui envoient uniquement des réponses LM). Ils n'envoient pas de réponses d'authentification NTLMv2 par défaut. C'est pourquoi la mise en œuvre de l'authentification NTLMv2 sur un contrôleur de domaine Windows 2000 n'est possible que lorsque tous les clients (et contrôleurs de domaines extérieurs à la forêt impliqués dans des relations d'approbation) sont reconfigurés de manière à envoyer des réponses NTLMv2.

Nombre d'ouvertures de session précédentes dans le cache

Vulnérabilité

S'il est habituel d'autoriser les ouvertures de session mises en cache sur les clients d'un domaine Windows, il est fondamentalement inutile de mettre en cache les ouvertures de session de domaine sur un contrôleur de domaine. En effet, il est impossible pour le contrôleur de domaine de ne pas valider ses propres informations d'identification de domaine.

Contre-mesure

Pour les contrôleurs de domaine, attribuez la valeur 0 au paramètre Nombre d'ouvertures de session précédentes dans le cache (au cas où le contrôleur de domaine ne serait pas disponible).

Impact potentiel

En désactivant cette option, il devient impossible d'authentifier, sur un contrôleur de domaine, les comptes d'autres domaines précédemment authentifiés, dans le cas où les contrôleurs de ces domaines seraient tous inaccessibles. Par exemple, dans le domaine enfant de Contoso, si tous les contrôleurs du domaine racine de Contoso sont inaccessibles, il est possible que des comptes tels que Administrateurs de l'entreprise soient incapables d'ouvrir une session sur les contrôleurs du domaine enfant. L'impact d'une telle situation est temporaire et celle-ci se résout dès que l'accès aux contrôleurs de domaines inaccessibles est restauré.

Scénario Contoso

La stratégie de groupe a été utilisée pour attribuer la valeur 0 au paramètre Nombre d'ouvertures de session précédentes dans le cache (au cas où le contrôleur de domaine ne serait pas disponible) dans la stratégie de base des contrôleurs de domaines.

Canal sécurisé : crypter ou signer numériquement les données des canaux sécurisés (toujours)

Le cryptage et la signature numérique du « canal sécurisé » constituent une solution à envisager lorsqu'ils sont pris en charge. Toutefois, le cryptage et la signature du canal sécurisé sont pris en charge uniquement par Windows NT 4 Service Pack 6a ou ultérieur, et non par les clients Windows 9x. Par conséquent, ce paramètre ne peut être activé sur les contrôleurs de domaines devant prendre en charge des clients Windows 9x en tant que membres du domaine.

Ce paramètre met en œuvre le cryptage ou la signature uniquement si l'un des autres paramètres « lorsque cela est possible » a été appliqué au contrôleur de domaine. Si ce n'est pas le cas, le paramètre n'a aucun effet sur le contrôleur de domaine. Cependant, une fois que l'un de ces autres paramètres est activé sur le contrôleur de domaine, les conditions décrites ci-dessous doivent être réunies pour que vous puissiez implémenter ce paramètre.

À titre d'exemple d'impact potentiel, citons l'impossibilité de créer ou de supprimer des relations d'approbation de niveau inférieur, la désactivation des ouvertures de session de clients de niveau inférieur et l'incapacité d'authentifier les utilisateurs d'autres domaines à partir d'un domaine approuvé de niveau inférieur.

Ce paramètre doit être activé sur vos contrôleurs de domaines uniquement lorsque toutes les conditions suivantes sont respectées :

· Il n'existe plus aucun client Windows 9x dans le domaine.

· Tous les contrôleurs de domaine, serveurs et clients Windows NT 4 (des domaines autorisés à approuver et approuvés) ont été mis à niveau avec le Service Pack 6a.

· Les options Canal sécurisé : crypter numériquement les données des canaux sécurisés (lorsque cela est possible) et Canal sécurisé : crypter numériquement les données des canaux sécurisés (lorsque cela est possible) sont activées sur tous les clients Windows. L’un au moins de ces paramètres doit être activé sur les contrôleurs de domaines.

Services système

Voici un récapitulatif des services système prescrits devant être activés sur tous les contrôleurs de domaines Windows 2000. Les services système sont configurés dans le modèle de sécurité SCI DCBaseline Role.inf, qui est ensuite importé dans l'objet Stratégie de groupe Contrôleurs de domaine.

Tableau 7.3. Services obligatoires pour les contrôleurs de domaines dans la stratégie de groupe

Nom du service dans l'interface	Type de démarrage	Commentaire
Système de fichiers distribués (DFS)	Automatique	Requis pour le partage Sysvol dans Active Directory.
Réplication de fichiers	Automatique	Requis pour la réplication de fichiers entre contrôleurs de domaines.
Service de messagerie inter-sites	Automatique	Requis pour prendre en charge la réplication Active Directory.
Centre de distribution de clés Kerberos	Automatique	Permet aux utilisateurs d'ouvrir une session sur le réseau en utilisant le protocole Kerberos version 5.
Localisateur d'appels de procédure distante (RPC)	Automatique	Permet au contrôleur de domaine de fournir le service de noms RPC.

Certains services supplémentaires sont habituellement activés sur les contrôleurs de domaines Windows 2000 mais, selon le type de l'organisation, ils ne sont pas toujours essentiels. Les paramètres recommandés pour ces services sont adaptés au scénario Contoso. Toutefois leur utilisation est souvent discutée et peut s'avérer inappropriée pour votre environnement.

Tableau 7.4. Autres considérations liées aux services des contrôleurs de domaines

Nom du service dans l'interface	Type de démarrage	Commentaire
Serveur DNS	Automatique	Un système DNS intégré à Active Directory est utilisé dans l'environnement Contoso.
Service d'administration IIS	Désactivé	La réplication Active Directory SMTP n'est pas activée dans l'environnement Contoso ; ce service n'est donc pas requis.
Fournisseur de la prise en charge de sécurité LM NT	Automatique	Sécurise les programmes utilisant l'appel de procédure distante (RPC, Remote Procedure Call) et des transports autres que des canaux nommés.
Simple Mail Transport Protocol (SMTP)	Désactivé	La réplication Active Directory SMTP n'est pas activée dans l'environnement Contoso.

Remarque : Si vous exécutez l'utilitaire DCDiag à partir des outils de support de Windows 2000, il vérifie si tous les services normalement exécutés sur les contrôleurs de domaines de votre environnement ont été démarrés. Étant donné que certains services sont désactivés dans la stratégie de base des contrôleurs de domaines (IISADMIN, SMTPSVC et TrkSvr notamment), DCDiag.exe fait état d'erreurs. Cela est normal et n'indique pas un dysfonctionnement de votre configuration.

Serveur DNS

Vulnérabilité

Le service Serveur DNS est nécessaire pour prendre en charge les services DNS intégrés à Active Directory. Il est utilisé pour assurer la prise en charge du protocole de mise à jour DNS dynamique sur Windows 2000 Server.

Tout service ou application en cours d'exécution est une cible potentielle d'attaque ; les services et composants non exécutés ne peuvent pas être atteints. Dès lors, pour renforcer la sécurité des systèmes, il est recommandé de désactiver toute fonctionnalité non utilisée, afin de réduire la « surface » potentiellement exposée aux attaques.

Contre-mesure

Aucune. Ce service est nécessaire. Cependant, si l'intégration du système DNS à Active Directory n'est pas requise, il peut être désactivé sur les contrôleurs de domaines et activé au niveau du rôle de serveur d'infrastructure. Le rôle de serveur d'infrastructure pourrait dans ce cas exécuter le service Serveur DNS en tant que serveur DNS principal ou secondaire.

Impact potentiel

La désactivation de services DNS intégrés à Active Directory là où c'est nécessaire entraînera l'échec de toutes les opérations du domaine, y compris celles associées à la réplication, à l'ouverture de session et à la stratégie de groupe. Elle provoquera également des échecs dans les applications intégrées à Active Directory, comme Microsoft® Exchange 2000.

Scénario Contoso

L'environnement Contoso nécessite un système DNS intégré à Active Directory ; dès lors, le type de démarrage du service Serveur DNS a été défini avec la valeur Automatique.

Service Messagerie inter-sites

Vulnérabilité

Ce service est requis par le vérificateur de cohérence des données (KCC, Knowledge Consistency Checker) Active Directory. Il est également employé pour prendre en charge la réplication Active Directory SMTP entre les sites. Chaque transport utilisé dans le cadre de la réplication est défini dans une bibliothèque de liaison dynamique (DLL) complémentaire distincte. Ces DLL complémentaires sont chargées dans le service Messagerie inter-sites.

Celui-ci dirige les demandes d'envoi et de réception vers les DLL de transport complémentaires appropriées, lesquelles routent ensuite les messages vers le service Messagerie inter-sites de l'ordinateur de destination. Si vous utilisez SMTP pour réaliser une réplication dans votre environnement, vous devez activer ce service.

Tout service ou application en cours d'exécution est une cible potentielle d'attaque. Inversement, les services et composants non exécutés ne peuvent pas être atteints. Dès lors, pour renforcer la sécurité des systèmes, il est recommandé de désactiver toute fonctionnalité non utilisée, afin de réduire la « surface » potentiellement exposée aux attaques.

Contre-mesure

Il est recommandé d'attribuer le type de démarrage Automatique au service Messagerie inter-sites dans la stratégie de base des contrôleurs de domaines. Si, en revanche, vous voulez générer des topologies de réplication manuelles et n'avez en conséquence pas besoin de prendre en charge le KCC, vous pouvez désactiver ce service.

Impact potentiel

Aucun.

Scénario Contoso

Dans la mesure où l'environnement Contoso dépend du KCC pour le calcul des topologies de réplication, le service Messagerie inter-sites est nécessaire ; c'est pourquoi il a été activé dans la stratégie de base des contrôleurs de domaines.

Service d'administration IIS

Vulnérabilité

Le service d'administration IIS doit être activé si le service SMTP l'est, car il existe une relation de dépendance entre les deux. Comme nous l'avons précédemment souligné, tout service ou application en cours d'exécution est une cible potentielle d'attaque. Dès lors, pour renforcer la sécurité des systèmes, il est recommandé de désactiver les fonctionnalités et options non utilisées dans votre environnement.

Contre-mesure

Attribuez la valeur Désactivé au service Administration IIS dans la stratégie de base des contrôleurs de domaines. En revanche, si la réplication SMTP est nécessaire, il est conseillé de lui affecter le type de démarrage Automatique dans la stratégie de base des contrôleurs de domaines.

Impact potentiel

Comme le service d'administration IIS est requis pour l'exécution correcte du service SMTP, sa désactivation entraîne celle de la réplication SMTP des informations Active Directory. Si la réplication SMTP est requise pour parcourir des liaisons lentes ou à forte latence, alors ce paramètre empêchera toute réplication Active Directory de ce type. Voilà pourquoi vous devez attribuer à ce service la valeur Automatique.

Scénario Contoso

Comme l'environnement Contoso est constitué de liaisons à grande vitesse entre sites Active Directory, la réplication SMTP n'est pas nécessaire. Ce service a donc été désactivé.

Fournisseur de la prise en charge de sécurité LM NT

Vulnérabilité

Ce service assure la prise en charge de l'interface NTLM SSPI (Security Support Provider Interface) pour les applications RPC ayant recours à SSPI pour la sécurité des messages RPC. Ce service est considéré comme essentiel au fonctionnement des serveurs Windows 2000. L'interface SSPI NTLM offre la possibilité aux applications RPC de s'authentifier auprès du contrôleur de domaine qui utilise les protocoles d'authentification plus faibles LM ou NTLM, plutôt que le protocole d'authentification NTLMv2.

Contre-mesure

Aucune. Ce service, activé par défaut, peut être requis pour des raisons de compatibilité d'applications. Il peut être désactivé dans certaines circonstances, mais il est considéré comme essentiel à la prise en charge de certaines applications plus anciennes exécutées sur Windows 2000. Si vous voulez le désactiver, il est vivement recommandé de tester au préalable toutes les applications qui sont exécutées sur vos contrôleurs de domaines ou qui y accèdent, afin de vous assurer que l'absence de l'interface SSPI NTLM n'entraîne pas leur échec. Pesez soigneusement votre décision d'éliminer l'authentification LM et NTLM (en faveur de protocoles d'authentification plus forts NTLMv2 et Kerberos) dans votre environnement par une étude approfondie de ses conséquences ainsi que par une planification et des tests rigoureux. Consultez avant toute chose les articles suivants de la Base de connaissances :

· 147706, « Procédure pour désactiver l'authentification LanManager sur Windows NT » ;

· 239869, « Procédure pour activer l'authentification NTLM 2 sous Windows 95/98/2000 et NT ».

Impact potentiel

L'activation de ce service permet aux protocoles relativement faibles LM et NTLM d'assurer l'authentification auprès des contrôleurs de domaines de votre organisation. Les risques associés à un tel choix peuvent être contenus par l'emploi de NTLMv2 sur les clients des contrôleurs de domaines.

Scénario Contoso

Le service Fournisseur de la prise en charge de sécurité NTLM est nécessaire pour prendre en charge de nombreux scénarios dans l'environnement Contoso. Il a donc été activé dans la stratégie de base des contrôleurs de domaines.

Simple Mail Transport Protocol (SMTP)

Vulnérabilité

Sur un contrôleur de domaine, le service SMTP permet à d'autres contrôleurs de domaines de répliquer des mises à jour Active Directory entre sites via le protocole SMTP, et non via le protocole RPC par défaut. Il est utile lorsque la réplication s'effectue sur des liaisons réseau très lentes ou à forte latence, entre des sites contenant des contrôleurs de domaines. De plus, il est nécessaire lorsqu'une organisation ne permet pas à RPC de franchir des limites réseau internes telles que des pare-feu. La réplication intersite peut utiliser RPC ou SMTP. Vous devez activer le service SMTP si vous utilisez SMTP à cette fin dans votre environnement. Celui-ci présente deux vulnérabilités potentielles :

1. En sa qualité de service supplémentaire qui écoute à distance et agit sur les données qui lui sont soumises, SMTP peut être la cible de dépassements de tampon.

2. Le serveur SMTP peut authentifier des demandes SMTP entrantes grâce à des comptes d'utilisateur du domaine. Toutefois, comme le serveur SMTP n'applique pas la logique de verrouillage de compte classique mise en œuvre par la stratégie de mot de passe Active Directory, un auteur d'attaque peut essayer à de nombreuses reprises de forcer les mots de passe des comptes du domaine, sans que ne se produisent les dépassements de délai ou verrouillages habituels.

Contre-mesure

Si la réplication Active Directory SMTP n'est pas nécessaire dans votre environnement, il est conseillé d'attribuer au service SMTP la valeur Désactivé dans la stratégie de groupe des contrôleurs de domaines.

Si vous ne souhaitez pas désactiver le service SMTP, vous pouvez envisager la sécurisation du service lui-même, à l'aide de filtres Accès/Connexion (propriétés de Serveur SMTP, onglet Accès, bouton Connexion), ou à l'aide de filtres IPSec (Internet Protocol Security) qui bloquent les connexions sur le port TCP 25 pour toutes les adresses IP à l'exception de celles qui sont spécifiées. IPSec est une norme en cours de développement sur la sécurité au niveau de la couche réseau ou de la couche de traitement des paquets de la communication réseau. Il est utile dans l'implémentation de réseaux privés virtuels (VPN, Virtual Private Network) et pour l'authentification ou le cryptage de données IP entre hôtes IP individuels.

Envisagez également de n'activer le service SMTP que sur les partenaires de réplication qui effectuent cette opération entre domaines nécessitant une réplication SMTP des informations Active Directory.

Remarque : Si vous voulez activer la réplication SMTP, vous devez configurer des certificats numériques sur chaque contrôleur de domaine qui participera au partenariat de réplication SMTP. Pour plus de détails, reportez-vous à l'annexe F, « Configuration de certificats numériques sur des contrôleurs de domaine pour sécuriser LDAP et la réplication SMTP ».

Impact potentiel

L'impact potentiel de la désactivation de SMTP sur les contrôleurs de domaines est minime, à moins que la réplication Active Directory SMTP soit configurée pour être gérée par ces contrôleurs de domaines : dans ce cas, la réplication échoue.

Scénario Contoso

La réplication Active Directory dans l'environnement Contoso est configurée pour se dérouler via le transport IP (ici, RPC). Le service SMTP a donc été désactivé.

Listes de contrôle d'accès aux fichiers

Vulnérabilité

Les ACL d'autorisations de fichiers pour tous les volumes nouvellement créés autres que %SystemDrive% (généralement la partition C) sont définies par défaut avec la valeur Tout le monde : Contrôle total. Cela signifie que tous les fichiers ou dossiers ajoutés à ces volumes vont généralement hériter des autorisations Tout le monde : Contrôle total.

Par conséquent, dans tous les partages de fichiers créés sur de tels volumes, les fichiers partagés seront soumis à ces autorisations de fichiers par défaut. Ces fichiers sont donc exposés aux types de menaces « divulgation d'informations » et « falsification des données », telles que définies dans le modèle STRIDE, acronyme de Spoofing (usurpation d'identité), Tampering (falsification des données), Repudiation (répudiation), Information disclosure (divulgation d'informations), Denial of service (déni de service) et Elevation of privilege (élévation de privilèges). Pour une description détaillée de ces menaces, reportez-vous au chapitre 2, « Définition du paysage de sécurité », et plus précisément à la section « Classification des menaces ».

Les seules modifications des listes ACL d'autorisations de fichiers activées dans la stratégie de base des contrôleurs de domaines sont celles qui concernent le volume %SystemDrive%.

Vous devez mettre à jour les autorisations de fichiers sur tous les volumes supplémentaires non amovibles créés en même temps que %SystemDrive% (par exemple les partitions D, E et F). C'est particulièrement vrai pour la partition qui contient la base de données Active Directory, les fichiers journaux DNS et tous les autres fichiers de données sensibles.

Contre-mesure

Configurez les autorisations par défaut pour toutes les partitions de disque non-système, en activant les autorisations héritables Contrôle total pour Administrateurs, CREATEUR PROPRIETAIRE et SYSTEM. N'accordez aucune autorisation aux autres groupes ou utilisateurs. L'octroi de telles autorisations au compte CREATEUR PROPRIETAIRE permet au système d'affecter l'appartenance à des administrateurs individuels plutôt qu'au simple groupe Administrateurs.

Une autre solution consiste à choisir des autorisations différentes pour la racine de chaque volume. Cependant, vous devez vous assurer au moins que les autorisations sur les dossiers pour les journaux DNS et la base de données et fichiers journaux Active Directory sont verrouillés, pour n'accorder l'autorisation Contrôle total qu'aux comptes Administrateurs et SYSTEM.

Impact potentiel

Il se peut que toutes les applications déjà installées sur ces partitions non-système ne fonctionnent plus correctement si les autorisations existantes sont remplacées. En effet, certaines applications Windows sont configurées de manière à définir leurs propres autorisations explicites dans les répertoires où elles sont installées. Voilà pourquoi il est recommandé de tester dans un environnement de laboratoire l'impact, sur ces applications, des modifications d'autorisations recommandées ici.

Scénario Contoso

Les autorisations à la racine de %SystemDrive% (généralement la partition C) ont été configurées dans la stratégie de base des contrôleurs de domaines de manière à accorder l'autorisation Contrôle total uniquement aux comptes Administrateurs, CREATEUR PROPRIETAIRE et SYSTEM. De plus, les autorisations sont héritées par les fichiers et dossiers enfants et propagées à ces derniers. Pour d'autres partitions de disques, ces autorisations ont été configurées manuellement.

Pour modifier manuellement les autorisations de dossier racine sur des partitions de disque non-système (par exemple la partition E)

1. Ouvrez une invite de commandes.

2. Tapez la commande suivante : cacls e:\ /t /g administrateurs:F system:F "createur proprietaire":F

3. À l'invite, tapez O pour continuer.

Paramètres de sécurité supplémentaires — Services d'annuaire

Désactivation du paramètre NoLmHash sur les contrôleurs de domaines

Vulnérabilité

Le paramètre NoLMHash réduit la vulnérabilité du stockage de condensés LMhash dans la base de comptes et empêche l'utilisation de l'authentification par stimulation/réponse LM.

Cependant, si le paramètre NoLmHash a été activé dans la stratégie de base des serveurs membres, il est impossible, dans le scénario Contoso, de l'activer sur les contrôleurs de domaines.

En effet, Contoso doit prendre en charge les clients Windows 98 incapables d'effectuer une authentification NTLM ou NTLMv2. Comme les clients Windows 98 de Contoso peuvent uniquement utiliser le protocole d'authentification LM, les contrôleurs de domaines doivent eux aussi pouvoir continuer à authentifier les machines à l'aide de LM. Cela implique malheureusement de conserver une version stockée du condensé LMHash sur les contrôleurs de domaines, ce qui empêche l'utilisation du paramètre NoLMHash sur les contrôleurs de domaines de Contoso.

Contre-mesure

Vérifiez que la clé de Registre NoLmHash n'existe pas sur vos contrôleurs de domaines.

Impact potentiel

Lorsque la création du condensé LMHash n'est pas désactivée, une valeur de condensé LMHash représentant les mots de passe des utilisateurs est toujours stockée dans Active Directory. Cependant, le risque que des pirates accèdent à ces codages plus faibles est généralement moindre sur des contrôleurs de domaines que sur des serveurs et des stations de travail, car l'accès physique aux contrôleurs est habituellement plus difficile. Pour plus d'informations sur la limitation des attaques d'accès physique, voir la section sur l'emploi de Syskey plus loin dans ce chapitre. Si vous ne désactivez pas la création du condensé LMHash, l'exécution sur le réseau de l'authentification par stimulation/réponse LM, la plus faible des méthodes d'authentification par stimulation/réponse Windows, devient possible. Cette méthode est nécessaire pour assurer la prise en charge des clients Windows 98 SE, mais devient inutile une fois qu'il n'existe plus de clients Windows 9x dans l'environnement de domaine.

Scénario Contoso

La modification manuelle permettant de désactiver la création du condensé LMHash n'a pas été effectuée sur les contrôleurs de domaines. La clé NoLmHash n'a pas été ajoutée à la clé de Registre HKLM\SYSTEM\CurrentControlSet\Lsa dans le Registre des contrôleurs de domaines.

Déplacement de données — Base de données et fichiers journaux Active Directory

Vulnérabilité

La base de données et les fichiers journaux (ntds.dit, edb.log et temp.edb) sont toujours verrouillés en mode exclusif lorsque le service d'annuaire est en ligne ; en d'autres termes, il est impossible de lire ces fichiers ou d'y écrire directement. Toutefois, il est théoriquement possible de les détourner, en accédant d'une quelconque façon aux fichiers par l'intermédiaire du processus (lsass.exe) qui les verrouille. Dans le cadre des bonnes pratiques, il est recommandé, afin d'améliorer les performances des contrôleurs de domaines, de déplacer la base de données et les fichiers journaux Active Directory vers un volume de disque non-système, de préférence un volume agrégé par bandes ou par bandes/miroir. En termes de sécurité, il est en outre conseillé de ne pas stocker des fichiers aussi sensibles que ceux-là sur le volume système, et donc de les déplacer afin de réduire autant que possible le risque d'attaques de type parcours de répertoires.

Contre-mesure

Lors de l'installation du contrôleur de domaine Active Directory, veillez bien à stocker les répertoires de la base de données et des journaux sur un volume non-système (généralement pas le volume C). La meilleure solution est un volume de disque à hautes performances comme une pile de disques agrégés par bande ou par bandes/mis en miroir. Pour les contrôleurs de domaines déjà existants (en partant du principe que vous n'avez pas encore déplacé ces fichiers de la partition système), vous pouvez déplacer la base de données et les fichiers journaux Active Directory en procédant comme suit :

Modifiez l'ACL associée à ces fichiers dans la partition non-système.

Remarque : Si vous définissez les ACL conformément aux instructions de la section précédente, Listes de contrôle d'accès aux fichiers, cette procédure n'est alors plus nécessaire, car les ACL plus sûres seront propagées au départ des autorisations de dossier racine.

Modifiez l'ACL pour le fichier boot.ini qui protège la configuration de redémarrage de l'ordinateur, afin d'empêcher un pirate informatique d’utiliser l'option Mode restauration Active Directory comme option de redémarrage par défaut pour redémarrer le serveur.

Impact potentiel

Le stockage de la base de données et des journaux sur un volume non-système défini à l'installation n'a qu'un impact minime, voire inexistant, à condition de choisir un volume de taille et de performances suffisantes. Le déplacement de la base de données et des journaux sur un contrôleur de domaine existant peut avoir impact significatif. En effet, d'une part, le système devra être mis hors ligne au cours de l'opération ; d'autre part, il existe toujours le risque minime d'une défaillance matérielle durant la procédure de déplacement. Créez toujours une sauvegarde de l'état du système avant d'exécuter une opération de ce type. Pour obtenir des instructions complètes concernant la procédure suivante, reportez-vous à l'article 257420 de la Base de connaissances, « COMMENT FAIRE : Déplacer le fichier Ntds.dit ou des fichiers journaux ».

Scénario Contoso

Dans l'environnement Contoso, la base de données et les journaux ont été installés sur un volume non-système au cours du processus d'installation.

Pour modifier l'emplacement de la base de données et des journaux Active Directory lors de l'installation d'un contrôleur de domaine

1. Lancez Dcpromo.exe et effectuez les configurations requises dans la boîte de dialogue Emplacement de la base de données et du journal.

2. Tapez le nouvel emplacement choisi pour la base de données (par exemple, D:\NTDS) et les journaux (par exemple, E:\NTDSLogs).

3. Poursuivez la procédure de l'utilitaire DCPROMO.

Pour déplacer la base de données et les journaux sur un contrôleur de domaine existant

1. Redémarrez le contrôleur de domaine.

2. Dans le menu de démarrage, appuyez sur F8, choisissez Mode restauration Active Directory, puis ouvrez une session en tant qu'administrateur à l'invite.

3. Lancez l'utilitaire ntdsutil.exe, puis tapez files à l'invite ntdsutil.

4. À l'invite File Maintenance, utilisez l'une des procédures suivantes, ou les deux :

a. Pour déplacer une base de données, tapez move db to %s (où %s est le lecteur et le dossier de destination).

b. Pour déplacer des fichiers journaux, tapez move logs to %s (où %s est le lecteur et le dossier de destination).

5. Pour visualiser les fichiers journaux ou la base de données, tapez info ; pour vérifier l'intégrité de la base de données à son nouvel emplacement, tapez integrity.

6. Tapez quit, puis quit encore pour revenir à l'invite de commandes.

7. Redémarrez le système en mode Normal.

Remarque : Sur un contrôleur de domaine promu, les autorisations suivantes sont affectées par défaut à la structure de dossiers Ntds : Administrateurs et SYSTEM = Contrôle total. Aucun verrouillage supplémentaire de ces fichiers n'est recommandé.

Sécurisation du groupe Accès compatible pré-Windows 2000

Vulnérabilité

Sur la plupart des objets Active Directory, les autorisations par défaut accordent un accès en lecture au groupe Accès compatible Pre-Windows 2000. Tous les objets utilisateur et groupe disposent de cette autorisation, et la partition de domaine accorde l'autorisation Lister le contenu à ce groupe. Si le groupe spécial Tout le Monde devient membre du groupe Accès compatible Pre-Windows 2000 dans un domaine Active Directory, alors tous les objets utilisateur et groupe peuvent devenir la cible d'opérations de lecture effectuées par des utilisateurs anonymes, ainsi que, par extension, par les membres des groupes liés à chaque objet utilisateur. Ces utilisateurs anonymes peuvent aussi lister le contenu du domaine.

Contre-mesure

Dans un domaine existant, supprimez l'alias Tout le monde du groupe Accès compatible Pre-Windows 2000.

Dans le cas de nouveaux domaines, choisissez le paramètre Autorisations compatibles uniquement avec les serveurs Windows 2000 dans la boîte de dialogue Autorisations lors du processus DCPROMO pour le premier contrôleur de domaine.

En théorie, vous pourriez supprimer du conteneur Domaine les autorisations héritées pour le groupe Accès compatible Pre-Windows 2000. Cependant, la suppression d'autorisations génériques de ce type crée un risque encore plus grand. En effet, cette solution alternative n'a pas encore fait l'objet de tests exhaustifs chez Microsoft et elle élimine de surcroît toute possibilité d'exploiter l'autorisation concernée par la suite.

Soulignons en outre que la modification de ces autorisations sur des objets Active Directory ne renforce pas plus la sécurité de votre environnement que le fait de vider le groupe Accès compatible Pre-Windows 2000.

Impact potentiel

Toute application nécessitant un accès anonyme à Active Directory ne pourra plus fonctionner comme prévu. Les services et applications dont on sait qu'ils sont affectés par la suppression de Tout le monde du groupe Accès compatible Pre-Windows 2000 sont les suivants :

· service d'accès distant (RAS, Remote Access Service) exécuté sur des contrôleurs secondaires de domaine Windows NT 4.0 ;

· service Routage et accès distant (RRAS, Routing and Remote Access Service) exécuté sur des serveurs Windows NT 4.0 ;

· Microsoft® SQL Server™ 2000 pour résolution en mode batch de l'appartenance aux groupes des utilisateurs ;

Remarque : Il est possible d'octroyer à SQL Server 2000 exécuté sur des serveurs membres Active Directory l'accès dont il a besoin, en plaçant le compte d'ordinateur du serveur membre dans le groupe Accès compatible Pre-Windows 2000, plutôt qu'en ajoutant le groupe Tout le monde.

· procédure permettant de visualiser les listes d'utilisateurs et de groupes provenant de domaines approuvés (sinon, le nom du groupe doit être tapé manuellement).

Scénario Contoso

Dans le scénario Contoso, l'alias Tout le monde a été supprimé du groupe Accès compatible Pre-Windows 2000 pour chaque domaine, en recourant à la procédure ci-dessous.

Pour supprimer l'alias Tout le monde du groupe Accès compatible Pre-Windows 2000

1. Lancez une invite de commandes sur un contrôleur de domaine, dans le domaine où ce groupe doit être supprimé.

2. Tapez la commande suivante : net localgroup "Accès compatible Pre-Windows 2000" Tout le monde /DELETE

3. Tapez net localgroup "Accès compatible Pre-Windows 2000" pour confirmer que le groupe est à présent vide. Les résultats ci-dessous doivent s'afficher :

C:\>net localgroup "Accès compatible Pre-Windows 2000"

Nom alias Accès compatible Pre-Windows 2000

Commentaire Un groupe de compatibilité descendante qui autorise un accès lecture sur

Membres

----------------------------------------------------------------------

La commande s'est terminée correctement.

4. Redémarrez tous les contrôleurs de domaines dans le domaine pour que le paramètre soit appliqué.

Suppression du droit Ajouter des stations de travail au domaine

Vulnérabilité

Par défaut, tous les utilisateurs authentifiés peuvent ajouter jusqu'à dix comptes d'ordinateur à un domaine Windows 2000. Ces nouveaux comptes d'ordinateur sont créés dans le conteneur Ordinateurs.

Contrairement au modèle de domaine Windows NT 4.0, dans un domaine Windows 2000, chaque compte d'ordinateur est une entité de sécurité à part entière, disposant de la possibilité en tant qu'ordinateur d'authentifier des ressources de domaine et d'y accéder. Certaines organisations souhaitent limiter le nombre d'ordinateurs dans l'environnement Active Directory afin d'assurer la cohérence de leur construction et de leur gestion.

Permettre aux utilisateurs d'ajouter des stations de travail au domaine risque d'aller à l'encontre de cette volonté d'harmonisation. En outre, le fait de laisser les utilisateurs créer des ordinateurs de domaine sans autorisation rend plus difficile le suivi de leurs activités.

Enfin, quand un système existant s'arrête normalement, il désinscrit son nom principal de service (SPN, Service Principal Name) d'Active Directory. Pendant toute la période d'inactivité du système (par exemple, après une attaque de refus de service), un pirate pourrait inscrire son ordinateur avec ce SPN et ensuite intercepter tout le trafic destiné au serveur légitime.

Contre-mesure

Supprimez le groupe Utilisateurs authentifiés du droit d'utilisateur Ajouter des stations de travail au domaine dans la stratégie des contrôleurs de domaines par défaut.

Si vous voulez autoriser un autre groupe d'utilisateurs, plus restreint, à créer des comptes d'ordinateur, vous pouvez modifier la valeur du droit Ajouter des stations de travail au domaine dans la stratégie des contrôleurs de domaines par défaut. Par exemple, vous pourriez créer un nouveau groupe de domaine appelé Créateurs de comptes d'ordinateur, le peupler avec les comptes des utilisateurs devant disposer du droit Ajouter des stations de travail au domaine, puis ajouter ce nouveau groupe au droit de domaine dans la stratégie des contrôleurs de domaines par défaut.

Vous pouvez également accorder les autorisations Créer des comptes d'ordinateur et Supprimer des comptes d'ordinateur sur n'importe quelle unité d'organisation (ou le conteneur Domaine) du domaine Active Directory à des groupes d'utilisateurs spécifiques. Les utilisateurs bénéficiant de ces autorisations sur un conteneur donné (par exemple l'unité d'organisation d'une succursale) peuvent créer autant de comptes d'ordinateur qu'ils le souhaitent dans celui-ci.

Par exemple, un groupe de sécurité appelé « Équipe de gestion des serveurs » pourrait se voir accorder les autorisations Créer des comptes d'ordinateur et Supprimer des comptes d'ordinateur sur l'unité d'organisation Serveurs membres. Tout membre du groupe Équipe de gestion des serveurs aurait la possibilité de créer un nombre indéfini de comptes d'ordinateur dans l'unité d'organisation Serveurs membres. Pour plus d'informations à propos de la création de comptes d'ordinateur dans les unités d'organisation, reportez-vous à l'article 251335 de la Base de connaissances, « Les utilisateurs d'un domaine ne peuvent pas joindre une station de travail ou un serveur à un domaine ».

Enfin, si vous voulez toujours autoriser tous les utilisateurs authentifiés à créer des comptes d'ordinateur par l'intermédiaire du droit Ajouter des stations de travail au domaine, mais en nombre inférieur à la valeur par défaut de dix comptes, vous pouvez réduire la valeur de l'attribut ms-DS-MachineAccountQuota à un nombre décimal inférieur. Attribuez la valeur 0 pour désactiver ce privilège. Pour plus d'informations, reportez-vous à l'article Q243327 de la Base de connaissances, « Default Limit to Number of Workstations a User Can Join to the Domain » (en anglais).

Impact potentiel

Les utilisateurs qui pouvaient par le passé ajouter leurs propres stations de travail au domaine ne pourront plus effectuer cette opération. Cela peut avoir un impact sur les tâches qui leur étaient habituellement dévolues, en particulier s'ils créaient fréquemment des comptes d'ordinateur.

La solution adoptée ici peut accroître la charge de l'environnement, car il devient nécessaire de prévoir et créer à l'avance des comptes d'ordinateur pour les machines futures. Elle augmente en outre la nécessité de coordonner les déploiements d'ordinateurs au moyen d'une équipe de gestion des versions informatiques centralisée, qui devra créer les comptes d'ordinateur à la demande.

La création anticipée de comptes d'ordinateur pour les nouvelles machines crée une nouvelle vulnérabilité. Plus la période d'inutilisation des nouveaux comptes est longue, plus le risque augmente de voir un intrus s'approprier un de ces comptes, en ajoutant un ordinateur non autorisé au domaine et en l'enregistrant sous le nom d'un compte non attribué. Ce type d'attaque est rendu possible par le fait que Windows 2000 utilise un mot de passe de compte d'ordinateur par défaut relativement prévisible. En effet, le mot de passe par défaut pour chaque compte inutilisé enregistré dans Active Directory reste le même jusqu'à ce qu'un nouvel ordinateur en définisse un, lorsqu'il se joint au domaine.

Le « vol » du compte d'ordinateur doit normalement être constaté au moment où l'utilisateur légitime se trouve dans l'impossibilité de rejoindre le domaine avec son ordinateur. Cependant, le pirate peut utiliser l'ordinateur de domaine au cours de cette période intermédiaire.

Scénario Contoso

Dans le scénario Contoso, tous les ajouts au réseau d'entreprise sont effectués par du personnel informatique qui possède des autorisations Créer/Supprimer sur les unités d'organisation pertinentes. Aucun utilisateur n'est autorisé à ajouter des stations de travail au domaine ; le privilège a donc été révoqué pour tous les utilisateurs. Le groupe Utilisateurs authentifiés a été supprimé du droit d'utilisateur Ajouter des stations de travail au domaine dans le modèle MSS DCBaseline Role.inf, au moyen de la procédure suivante :

Pour modifier les groupes disposant du privilège Ajouter des stations de travail au domaine

1. Lancez Utilisateurs et ordinateurs Active Directory en tant qu'utilisateur disposant de l'autorisation de modifier l'objet Stratégie des contrôleurs de domaine par défaut.

2. Cliquez avec le bouton droit sur Contrôleurs de domaine et choisissez Propriétés.

3. Choisissez l'onglet Stratégie de groupe, cliquez sur l'objet Stratégie des contrôleurs de domaine par défaut, puis cliquez sur le bouton Modifier.

4. Double-cliquez sur le dossier Paramètres, choisissez Paramètres de sécurité, Stratégies locales, puis Attribution des droits utilisateur.

5. Double-cliquez sur le droit Ajouter des stations de travail au domaine.

6. Pour supprimer un membre, cliquez dessus (par exemple, Utilisateurs authentifiés), puis cliquez sur le bouton Supprimer.

7. Pour ajouter un membre, cliquez sur le bouton Ajouter, sélectionnez l'utilisateur ou le groupe, puis cliquez sur OK.

Protection contre les attaques de refus de service sur Kerberos/TCP

Vulnérabilité

Sous certaines conditions précises, les contrôleurs de domaines Windows 2000 arrêtent temporairement d'accepter les demandes du protocole Kerberos via TCP. C'est un problème connu, résolu par un correctif logiciel (hotfix) postérieur au Service Pack 3. Un correctif logiciel est un package cumulatif composé d'un ou de plusieurs fichiers permettant de résoudre un défaut présent dans un produit. Il pallie des situations problématiques spécifiques d'un client et ne peut pas être distribué à l'extérieur de l'organisation de celui-ci sans le consentement écrit de Microsoft.

Cette vulnérabilité est décrite dans le détail dans l'article de la Base de connaissances Q320903, « Clients Cannot Log On by Using Kerberos over TCP » (en anglais).

Le risque de voir des contrôleurs de domaines, même fort sollicités, rencontrer ce problème dans le cadre d'une utilisation légitime est pratiquement nul. Cependant, il est possible qu'un assaillant exploite cette condition de refus de service et épuise temporairement la capacité d'un contrôleur de domaine à desservir des demandes Kerberos via TCP.

Par défaut et par conception, le trafic du protocole d'authentification Kerberos est envoyé et reçu sur le port UDP 88 (User Datagram Protocol). Si les paquets de protocole Kerberos dépassent les 2 000 octets (limite de taille par défaut), Windows 2000 utilisera à la place le port TCP 88.

Certaines organisations opteront pour une configuration de leurs clients Windows 2000 et Windows XP dans laquelle TCP sera toujours utilisé pour le trafic de protocole Kerberos. L'article 244474 de la Base de connaissances, « Obligation pour Kerberos d'utiliser TCP au lieu de UDP dans Windows 2000 », explique la situation la plus courante qui justifie une telle modification.

Contre-mesure

Si vous estimez que votre environnement est susceptible d'être la cible de ce type d'attaque, ou si vous êtes dans la situation décrite dans l'article Q320903 de la Base de connaissances, procurez-vous le correctif logiciel (hotfix), déjà cité, auprès de Microsoft et déployez-le sur tous les contrôleurs de domaines affectés.

Vous pouvez également surveiller les appels à votre service d'assistance technique concernant des durées d'ouverture de session excessives. Ce peut être un indice révélateur de ce type de problème. Cependant, des temps d'ouverture de session plus lents que la normale peuvent résulter de nombreux autres problèmes. Or, déterminer la cause de ce ralentissement est, on le sait, fort difficile.

Vous pouvez également limiter l'utilisation de la solution détaillée dans l'article Q244474 pour réduire autant que possible le volume de trafic Kerberos via TCP. Cependant, l'article Q244474 décrit un problème d'échecs d'ouvertures de session, qui sont souvent dus à des fragments de paquets perdus. Les problèmes connexes sont beaucoup plus difficiles à résoudre sans utiliser TCP. Si vous avez délibérément opté pour l'emploi de TCP, il est peu probable que vous puissiez réutiliser UDP.

De plus, de nombreuses organisations choisissent d'accroître la fiabilité de leur authentification avec le protocole Kerberos, parce que cette méthode devient essentielle à leurs applications d'entreprise, et que la transition vers TCP constitue un moyen décisif d'augmenter cette fiabilité. Pour toutes ces raisons, il n’est pas recommandé de limiter de l'emploi de TCP pour réduire la probabilité d'une attaque de refus de service.

Impact potentiel

L'impact potentiel est identique à celui de tout autre correctif logiciel (hotfix). Comme toujours, veillez à effectuer les tests pertinents avant de déployer le correctif dans votre environnement de production.

Scénario Contoso

Dans le scénario Contoso, les temps d'ouverture de session sont un facteur sensible et il existe un risque potentiel d'attaques réseau internes. Le correctif logiciel relatif au problème souligné dans l'article Q320903 de la Base de connaissances a donc été déployé en tant que mesure préventive.

Pour obtenir et déployer le correctif logiciel pour le problème de l’article Q320903

1. Contactez le support technique ou le centre d'assistance téléphonique de Microsoft et demandez le correctif indiqué dans l'article Q320903 de la Base de connaissances.

2. Testez et déployez le correctif en fonction des procédures existantes de test et de déploiement des correctifs au sein de votre organisation.

Paramètres de sécurité supplémentaires — DNS intégré à Active Directory

Microsoft recommande d'utiliser un système DNS intégré à Active Directory, en partie parce que l'intégration des zones à Active Directory simplifie la sécurisation de l'infrastructure DNS.

Protection des serveurs DNS

Vulnérabilité

Quand un serveur DNS est soumis à une attaque, il se peut que l'auteur de celle-ci vise le contrôle des informations de DNS retournées en réponse aux requêtes des clients DNS. Ainsi, ces clients pourraient être redirigés frauduleusement et à leur insu vers des ordinateurs non autorisés. L'usurpation d'adresses IP et la corruption de cache sont des exemples de ce type d'attaque.

Dans l'usurpation d'adresses IP, une transmission reçoit l'adresse IP d'un utilisateur autorisé afin d'obtenir l'accès à un ordinateur ou réseau. La corruption de cache se produit lorsque, par défaut, les noms ajoutés à partir de réponses de référence sont mis en cache pour faciliter la résolution des requêtes DNS subséquentes.

Quand les clients abusés commencent à communiquer avec des ordinateurs non autorisés, ces deniers peuvent essayer d'accéder aux informations stockées sur les clients.

Les attaques ne se cantonnent pas à l'usurpation d'identité des serveurs DNS. Certaines attaques de refus de service peuvent altérer les enregistrements DNS de serveurs DNS légitimes, afin de fournir des adresses non valides en réponses à des requêtes de clients. Comme le serveur répond en communiquant des adresses non valides, les clients et les serveurs sont dans l'incapacité de localiser les ressources dont ils ont besoin pour fonctionner, comme les contrôleurs de domaines, les serveurs Web ou les partages de fichiers. Cette question est abordée plus loin dans ce chapitre, à la section « Sécurisation du conteneur de données DNS ».

Contre-mesure

Comme toutes les configurations de clients DNS sont basées sur les adresses IP, configurez tous les routeurs pour qu'ils ignorent les paquets IP usurpés et ainsi garantir que d'autres ordinateurs n'usurpent pas les adresses IP des serveurs DNS.

Vous pouvez également limiter les dommages causés à vos serveurs DNS par de telles attaques en surveillant les performances de ces serveurs.

Impact potentiel

Aucun.

Scénario Contoso

Comme les serveurs DNS de Contoso (contrôleurs de domaines) dans le domaine Ameriquenord ont une priorité de ressource relativement élevée, tous les routeurs de l'environnement Contoso ont été configurés de manière à empêcher l'usurpation d'adresses IP. Tous les clients de Contoso ne sont pas capables d'utiliser IPSec ; dès lors, la signature ou le cryptage IPSec n'ont pas été activés sur les serveurs DNS. Cependant, des filtres de blocage IPSec l’ont été, pour diverses raisons. Pour plus d'informations à ce propos, consultez la section « Blocage de ports à l'aide de filtres IPSec », plus loin dans ce chapitre. Les performances des contrôleurs de domaines et des serveurs DNS font l'objet d'un suivi par Microsoft Operations Manager (MOM).

Configuration des mises à jour dynamiques sécurisées

Vulnérabilité

Les clients et les serveurs DNS Windows 2000 prennent en charge les mises à jour DDNS, qui permettent aux systèmes clients d'ajouter des enregistrements DNS directement dans la base de données sur des serveurs DNS qui l'acceptent. Il est possible qu'un serveur DNS Windows 2000 subisse des mises à jour DDNS non autorisées si :

· l'auteur de l'attaque utilise un client qui exploite le protocole DDNS ;

· le serveur DNS est configuré pour accepter les mises à jour non sécurisées.

Pour le moins, un pirate pourrait ajouter de fausses entrées dans la base de données DNS. Dans un scénario plus pessimiste, il pourrait écraser ou supprimer des entrées légitimes dans cette base. Certaines des conséquences possibles de ce type d'attaque sont les suivantes :

· Clients dirigés vers des contrôleurs de domaines non autorisés.

Quand un client soumet une requête DNS recherchant l'adresse d'un contrôleur de domaine, un serveur DNS compromis pourrait, s'il est configuré pour le faire, renvoyer l'adresse d'un serveur non autorisé. Ensuite, par le recours à des attaques autres que celles liées à DNS, le client pourrait être abusé et transmettre sans s'en rendre compte des informations sécurisées au faux serveur.

· Réponse à des requêtes DNS avec des adresses non valides.

Les clients et les serveurs sont alors incapables de se trouver. Les clients, s'ils ne sont pas en mesure de trouver les serveurs, ne pourront pas accéder à l'annuaire. Et si les contrôleurs de domaines ne parviennent pas à trouver d'autres contrôleurs de domaines, la réplication de l'annuaire s'arrête.

· Création d'une condition de refus de service dans les circonstances suivantes :

o L'espace disque du serveur est saturé par la génération d'une énorme zone remplie de faux enregistrements.

o Un très grand nombre d'entrées (par exemple plus de 50 000) sont créées dans le conteneur de zone de l'annuaire, ralentissant ainsi fortement la réplication.

Contre-mesure

Pour empêcher un auteur d'attaques d'inscrire des enregistrements incorrects, vous devez recourir à des mises à jour dynamiques sécurisées. Si vous employez des mises à jour DDNS sécurisées, les demandes d'inscription ne sont traitées que dans le cas où elles émanent de clients valides de la forêt. Une attaque de ce type est alors plus difficile à mener car le pirate doit accéder au préalable à une station de travail membre de la forêt.

Vous pouvez aussi désactiver les mises à jour DDNS, ce qui empêcherait les types d'exploits détaillés plus haut. Cependant, une telle décision augmenterait de manière significative le coût de la tenue à jour des enregistrements DNS, car toutes les mises à jour devraient être traitées manuellement. Dans un environnement Windows 2000, le nombre d'enregistrements DNS dont il faut assurer la maintenance est vraisemblablement plus élevé que celui habituellement géré par les administrateurs DNS dans des environnements plus anciens.

Pour plus d'informations, consultez les articles suivants de la Base de connaissances :

· 246804, « Procédures pour activer/désactiver les inscriptions DNS dynamiques de Windows 2000 » ;

· 198767, « How to Prevent Domain Controllers from Dynamically Registering DNS Names ».

Impact potentiel

Il est possible que certains systèmes non-Windows 2000 ne puissent pas enregistrer des entrées DDNS dans les zones DNS intégrées à Active Directory, une fois ces zones sécurisées. Le problème peut être atténué pour les clients DHCP (Dynamic Host Configuration Protocol), en activant des serveurs DHCP Windows 2000 qui inscrivent les enregistrements DNS pour le compte des clients DHCP.

Toutefois, l'emploi de serveurs DHCP pour l'inscription d'enregistrements DDNS ne sera d'aucune utilité pour les clients non-DHCP. Pour les systèmes ne prenant pas en charge les mises à jour DDNS sécurisées ou obtenant leurs informations d'adresse IP d'un serveur DHCP Windows 2000, mais devant inscrire leurs informations DNS dans les zones DNS sécurisées intégrées à Active Directory, ces enregistrements doivent être inscrits manuellement.

Scénario Contoso

Dans le scénario Contoso, les serveurs DNS intégrés à Active Directory ont été configurés manuellement de manière à n'accepter que des mises à jour DDNS sécurisées.

Pour activer les mises à jour DDNS sécurisées pour chaque zone DNS (zone de recherche directe et zone de recherche inversée)

1. Ouvrez le composant logiciel enfichable MMC Serveur DNS, puis le dossier pertinent (Zone de recherche directe ou Zone de recherche inversée).

2. Cliquez avec le bouton droit sur la zone concernée (par exemple ameriquenord.entrep.contoso.com) et choisissez Propriétés.

3. Dans l'onglet Général de la boîte de dialogue Autoriser les mises à jour dynamiques ?, assurez-vous que l'option Uniquement les mises à jour sécurisées est sélectionnée.

Remarque : Cette procédure part du principe que, dans l'onglet Général de la zone pertinente, le type a la valeur Intégrée à Active Directory.

Sécurisation du conteneur de données DNS

Vulnérabilité

Il est possible de définir des ACL sur les conteneurs de zone afin de limiter l'accès aux utilisateurs qui essayeraient de les modifier par le truchement d'outils tels que le composant logiciel enfichable DNS ou ADSIEdit. Les groupes Administrateurs, Administrateurs du domaine, Administrateurs de l'entreprise et Administrateurs DNS bénéficient par défaut de l'autorisation Contrôle total sur tous les composants DNS. Tous les autres comptes disposent d'un accès en lecture.

Si les ACL par défaut sont modifiées, vous risquez d'être confronté à une menace non intentionnelle, de la part d'utilisateurs qui recevraient sans le vouloir l'autorisation de modifier les conteneurs de données DNS. Cela pourrait entraîner la modification des propriétés du serveur DNS ou des données enregistrées dans les zones DNS intégrées. Ces attaques non intentionnelles sont généralement le fait d'employés sans réelles connaissances informatiques qui n'ont pas conscience des vulnérabilités et des menaces posées à la sécurité.

Contre-mesure

Limitez les ACL sur le conteneur DNS dans tout domaine utilisant un système DNS intégré à Active Directory à la configuration par défaut de celles-ci.

Vous pourriez également limiter l'appartenance aux groupes qui, par défaut, peuvent modifier ces paramètres et données (c’est-à-dire Administrateurs, Administrateurs du domaine, Administrateurs de l'entreprise et Administrateurs DNS).

Impact potentiel

Des paramètres d'autorisation incorrects sur le conteneur DNS Microsoft ou n'importe laquelle des zones DNS intégrées pourraient avoir des conséquences très graves pour votre organisation. Des autorisations trop laxistes pourraient laisser le champ libre à des utilisateurs non autorisés pour causer des dommages à vos serveurs DNS ou à leurs données de zone. Inversement, des autorisations trop restrictives pourraient théoriquement créer une condition de refus de service lors de tentatives de chargement des données au départ de l'annuaire, ou d'ajout de nouvelles mises à jour dynamiques.

Remarque : Dans tous les cas, veillez à ce que le compte SYSTEM ait l'autorisation Contrôle total.

Scénario Contoso

Dans le scénario Contoso, les autorisations par défaut sur le système DNS Microsoft et les zones subordonnées ont été confirmées.

Pour afficher ou modifier les autorisations pour le DNS intégré à Active Directory

1. Ouvrez la console MMC Serveur DNS, cliquez avec le bouton droit sur le serveur DNS, puis sélectionnez Propriétés.

2. Cliquez sur l'onglet Sécurité, puis sur le bouton Avancé.

Configuration de la protection contre la corruption de cache DNS

Vulnérabilité

Il est possible d'ajouter des entrées non autorisées directement dans le cache d'un serveur DNS, de telle sorte que les clients soient redirigés frauduleusement vers des emplacements non autorisés. Il s'agit de cas de pollution de cache.

Contre-mesure

Sur tous les serveurs DNS, définissez l'option Sécuriser le cache contre la pollution avec la valeur Activé. Quand cette fonctionnalité est activée, le serveur peut déterminer si les noms référencés sont potentiellement polluants ou non sécurisés, et les ignorer. Il établit s'il faut mettre ou non en cache chaque référence sur la base de son identification en tant que partie de l'arborescence exacte de nom de domaine DNS associée, enregistrée dans la requête d'origine. Pour plus d'informations, reportez-vous à l'article 316786 de la Base de connaissances, « Description of the DNS Server Secure Cache Against Pollution Setting » (en anglais).

Impact potentiel

Minime.

Scénario Contoso

Les serveurs DNS intégrés à Active Directory ont été sécurisés contre la pollution de cache dans le scénario Contoso.

Pour activer la sécurité contre la pollution de cache de serveur DNS

Ouvrez la console MMC Serveur DNS, cliquez avec le bouton droit sur le serveur DNS, puis sélectionnez Propriétés.
Sélectionnez l'onglet Avancé et vérifiez que la case à cocher Sécuriser le cache contre la pollution est activée.

Sécurisation des répertoires des données et des journaux DNS

Vulnérabilité

Les serveurs DNS Windows 2000 qui sont intégrés à Active Directory enregistrent leurs données de zone dans Active Directory. Cependant, les serveurs DNS configurés en tant que serveurs principaux ou secondaires stockent leurs données de zone, par défaut, dans un fichier texte situé dans le répertoire %SystemRoot%\system32\dns.

En outre, si les journaux de débogage sont configurés sur le serveur DNS, ils sont, par défaut, eux aussi enregistrés dans un fichier texte du répertoire %SystemRoot%\system32\dns.

Les autorisations par défaut sur ces deux types de fichiers accordent un accès en lecture et en exécution au groupe Utilisateurs, et un accès en modification aux Utilisateurs avec pouvoir.

Les données du serveur DNS pourraient être compromises si ce serveur est exposé à des attaques de dépassement de tampon ou de parcours de répertoires, qui peuvent permettre d'accéder aux données sur le volume système. Un dépassement de tampon est un type d'exploit employé par les auteurs d'attaques pour accéder à un système.

Contre-mesure

Limitez les autorisations sur le dossier %SystemRoot%\system32\dns pour que seuls les comptes Administrateurs et SYSTEM disposent d'autorisations sur ces fichiers.

Vous pouvez également déplacer la base de données et les fichiers journaux vers un volume de disque distinct ou vers un autre répertoire, moins connu des pirates que l'emplacement par défaut. Cependant, le déplacement des fichiers ne change en rien leurs autorisations, ce qui veut dire qu'ils présentent toujours une vulnérabilité potentielle dans le cas où ils seraient localisés par une personne malveillante (qui identifierait par exemple leur emplacement spécifié dans le Registre).

Impact potentiel

Comme seuls les comptes Administrateurs et System doivent accéder à ces fichiers, l'impact potentiel est minime. Vous pourriez déléguer la gestion des services DNS à un nouveau groupe qui ne ferait pas partie du groupe Administrateurs sur le serveur DNS. Dans ce cas, veillez à ce que ce nouveau groupe dispose des autorisations permettant à ses membres d'accéder à ces fichiers pour accomplir leurs tâches.

Scénario Contoso

Dans le scénario Contoso, toutes les données DNS proviennent d'Active Directory, donc aucune modification d'autorisations de système de fichiers n'a dû être mise en œuvre.

Pour limiter les autorisations sur le répertoire par défaut des fichiers DNS

1. Ouvrez une invite de commandes.

2. Tapez la commande suivante : cacls.exe %systemroot%\system32\dns /t / g administrateurs:F system:F

3. À l'invite, tapez O pour continuer.

Remarque : N'oubliez pas de modifier le répertoire spécifié dans la commande cacls.exe ci-dessus si vous déplacez les fichiers DNS vers un nouveau répertoire non sécurisé.

Déplacement des répertoires des données et des journaux DNS

Vulnérabilité

Les serveurs DNS Windows 2000 qui sont intégrés à Active Directory enregistrent leurs données de zone dans Active Directory. Cependant, les serveurs DNS configurés en tant que serveurs principaux stockent leurs données de zone, par défaut, dans un fichier texte situé dans le répertoire %SystemRoot%\system32\dns.

En outre, si les journaux de débogage sont configurés sur le serveur DNS, ils sont, par défaut, eux aussi enregistrés dans un fichier texte placé dans %SystemRoot%\system32\dns.

Ces données pourraient être lues ou compromises si ce serveur est exposé à des attaques de dépassement de tampon ou de parcours de répertoires, qui peuvent permettre d'accéder aux données sur le volume système.

Contre-mesure

Déplacez les fichiers de données de zone DNS et les fichiers journaux vers une partition de disque non-système.

Vous pouvez également réduire le niveau d'autorisations dans le répertoire par défaut des fichiers DNS, figurant dans le répertoire %SystemRoot%\system32\dns. Cependant, cette mesure ne limite pas toujours la probabilité d'attaques contre ces fichiers, car certaines peuvent être provoquées par l'intermédiaire de services compromis s'exécutant en tant que comptes de niveau administrateur ou en tant que compte SYSTEM.

Impact potentiel

Si vous n'indiquez pas à votre équipe de gestion du stockage le nouvel emplacement de ces fichiers, ces derniers risquent de ne pas être couverts par les sauvegardes planifiées. Vous pouvez éviter tout problème de disponibilité en vous assurant que votre logiciel de sauvegarde est configuré de manière à sauvegarder ces fichiers à leur nouvel emplacement.

Scénario Contoso

Dans le scénario Contoso, les données de zone DNS sont intégrées à Active Directory ; dès lors, aucun fichier de données n'est stocké sur disque. Aucune modification n'a été nécessaire.

Dans le scénario Contoso, la journalisation de débogage pour les serveurs DNS n'est pas activée. Cependant, dans la perspective d'un emploi de cette fonctionnalité de journalisation dans le futur, l'emplacement du journal de débogage a été défini sur un disque distinct.

Pour déplacer les fichiers de données de zone DNS

Lancez Regedit.exe, puis accédez à HKLM\System\CurrentControlSet\Services\DNS\Parameters.
Choisissez le menu Edition, sélectionnez Nouveau, Valeur chaîne, et attribuez-lui le nom « DatabaseDirectory ».
Double-cliquez sur la nouvelle entrée de valeur DatabaseDirectory, puis, dans la zone de texte Données de la valeur, tapez le chemin d'accès complet où vous voulez enregistrer les fichiers de données de zone.

Remarque : DNS ne déplace pas plus qu'il ne maintient la base de données d'origine lorsque vous apportez cette modification au Registre.

4. Arrêtez le service Serveur DNS.

5. Si une base de données DNS se trouve déjà dans le dossier %SystemRoot%\system32\dns, vous devez la déplacer manuellement vers le nouvel emplacement. Déplacez les fichiers et dossiers situés dans le répertoire %SystemRoot%\system32\dns vers le nouveau dossier situé sur une autre unité (par exemple D:\DNS).

6. Démarrez le service Serveur DNS.

Pour déplacer les fichiers journaux de débogage DNS

1. Lancez Regedit.exe, puis accédez à HKLM\System\CurrentControlSet\Services\DNS\Parameters.

2. Choisissez le menu Edition, sélectionnez Nouveau, Valeur chaîne, et attribuez-lui le nom « LogFilePath ».

3. Double-cliquez sur la nouvelle valeur LogFilePath, puis, dans la zone de texte Données de la valeur, tapez le chemin d'accès complet vers le dossier et le nom de fichier sous lesquels vous voulez enregistrer les fichiers journaux de débogage.

4. Redémarrez le service Serveur DNS.

Limitation des transferts de zone aux systèmes autorisés

Vulnérabilité

Outre les serveurs DNS intégrés à Active Directory, il existe des serveurs DNS qui agissent en tant que serveurs principaux ou secondaires. Les serveurs secondaires transfèrent généralement le fichier de zone tout entier au départ du serveur principal, afin d'en synchroniser le contenu. Un serveur DNS qui n'est pas paramétré pour limiter les transferts de zone aux seuls ordinateurs autorisés laisserait effectuer le transfert de la zone DNS tout entière à quiconque en ferait la demande. Ce type d'attaque est facilement réalisé à l'aide d'outils comme nslookup.exe. Le jeu de données DNS du domaine tout entier s'en trouverait exposé, y compris des éléments tels que l'identité des contrôleurs de domaines, les serveurs Web intégrés à Active Directory ou les bases de données SQL Server 2000.

Contre-mesure

Configurez les serveurs DNS pour n'autoriser les transferts de zone qu'aux ordinateurs connus (c’est-à-dire uniquement aux serveurs DNS secondaires).

Vous pouvez aussi totalement interdire les transferts de zone. Cependant, une telle mesure pourrait être difficile à justifier dans un vaste réseau distribué, si vous avez ou prévoyez d'instaurer une hiérarchie de serveurs DNS et que vous configurez des serveurs DNS secondaires plus proches de grandes populations distantes d'utilisateurs.

Impact potentiel

Cette configuration pourrait limiter les services qui doivent pouvoir demander la zone DNS tout entière tout de suite. Elle pourrait en outre ralentir les temps de réponse des clients DNS alors contraints d'interroger d'autres serveurs DNS. Enfin, elle pourrait provoquer l'échec de certaines requêtes DNS, selon votre infrastructure DNS.

Scénario Contoso

Dans le scénario Contoso, il existe des zones DNS secondaires configurées sur les contrôleurs de domaines du domaine enfant, qui assurent la mise en cache de la zone _msdcs.entrep.contoso.com du domaine racine. Les contrôleurs de domaines du domaine racine ont été configurés pour n'accorder l'autorisation de transfert pour cette zone qu'aux contrôleurs de domaines du domaine enfant, en fonction des adresses IP des serveurs DNS autorisés. Toutes les autres zones intégrées à Active Directory ont conservé la configuration par défaut, à savoir que les transferts de zone sont interdits.

Pour limiter les transferts de zone aux serveurs connus

1. Lancez l'outil d'administration DNS, cliquez avec le bouton droit sur la zone pour laquelle vous voulez configurer les transferts de zone, puis sélectionnez Propriétés.

2. Assurez-vous que l'option Autoriser les transferts de zone est activée, puis sélectionnez soit Uniquement vers les serveurs suivants, soit Uniquement vers les serveurs listés dans l'onglet Serveurs de noms.

a. Si vous choisissez Uniquement vers les serveurs suivants, complétez les adresses IP de ces serveurs DNS autorisés dans la boîte de dialogue. (Il s'agit du paramètre choisi pour Contoso ; les adresses IP des contrôleurs du domaine enfant ont été ajoutées.)

b. Si vous choisissez Uniquement vers les serveurs listés dans l'onglet Serveurs de noms, sélectionnez l'onglet Serveurs de noms et complétez les informations relatives aux serveurs de noms (serveurs DNS) autorisés à demander des transferts de zone secondaires à partir de ce serveur DNS, et faisant autorité pour cette zone.

Blocage de ports à l'aide de filtres IPSec

Vulnérabilité

La réduction du nombre de ports ouverts et à l'écoute sur les serveurs de votre organisation va grandement limiter la surface d'attaque potentielle de chaque ordinateur. La surface d'attaque est la zone exposée des ordinateurs clients/serveurs dans votre environnement qui est vulnérable aux attaques. Souvent, les ports ouverts peuvent offrir aux pirates une véritable « rampe de lancement » pour des attaques contre un autre serveur de l'organisation. Par exemple, un ver et un cheval de Troie peuvent installer des applications qui se lient à des ports non autorisés sur le serveur et écoutent les commandes entrantes.

Contre-mesure

Configurez des filtres de blocage IPSec qui n'autorisent que le trafic réseau spécifié ci-dessous. Cette mesure permet de réduire le nombre d'applications inattendues et non autorisées qui pourraient recevoir des requêtes ou faire l'objet d'attaques.

Les contrôleurs de domaines ont besoin du trafic RPC pour exécuter différentes fonctions, comme l'indique la carte de trafic. Voilà pourquoi plusieurs éléments distincts doivent être pris en considération, comme le montre cette carte.

Chaque service est divisé en fonctionnalités client et serveur. Il ne s'agit pas forcément ici d'une référence à une station de travail cliente et au serveur, mais plutôt d'une indication du filtre IPSec correspondant qui doit être créé pour utiliser ou fournir le service mentionné.

Par exemple, la stratégie de clients DNS doit être appliquée à tout ordinateur qui a besoin d'une fonctionnalité de services de noms. Les règles de serveur DNS ne sont alors appliquées que sur l'ordinateur qui fournit les services DNS. D'autres services, comme SNTP, sont parfois plus difficiles à appréhender, parce que des ports sont autorisés pour le serveur SNMP, mais pas pour le client SNMP. SNMP agit comme un service serveur sur le contrôleur de domaine afin de fournir des informations à la console d’interrogation distante.

Tableau 7.5. Carte du trafic réseau IPSec pour les contrôleurs de domaines

Service	Protocole	Port source	Port de destination	Adresse source	Adresse de destination	Action
Client DNS	TCP	N'importe lequel (ANY)	53	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	53	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur SNMP	TCP	N'importe lequel (ANY)	161	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	161	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client CIFS/SMB	TCP	N'importe lequel (ANY)	445	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	445	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur CIFS/SMB	TCP	N'importe lequel (ANY)	445	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	445	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client RPC	TCP	N'importe lequel (ANY)	135	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	135	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur RPC	TCP	N'importe lequel (ANY)	135	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	135	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Réplication FRS/AD – ports de sortie	TCP	N'importe lequel (ANY)	57951	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	57952	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Réplication FRS/AD – ports d'entrée	TCP	N'importe lequel (ANY)	57951	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	57952	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client NetBIOS	TCP	N'importe lequel (ANY)	137	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	137	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	139	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	138	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur NetBIOS	TCP	N'importe lequel (ANY)	137	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	137	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	139	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	138	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client NTP	TCP	N'importe lequel (ANY)	123	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	123	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Client de surveillance	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe lequel (ANY)	Adresse IP de l'hôte	Serveur MOM	Autoriser (ALLOW)
Client LDAP	TCP	N'importe lequel (ANY)	389	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	389	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	636	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	636	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Client Kerberos	TCP	N'importe lequel (ANY)	88	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	88	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Services Terminal Server	TCP	N'importe lequel (ANY)	3389	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client de catalogue global	TCP	N'importe lequel (ANY)	3268	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	3269	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur de catalogue global	TCP	N'importe lequel (ANY)	3268	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	3269	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Serveur DNS	TCP	N'importe lequel (ANY)	53	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	53	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Serveur Kerberos	TCP	N'importe lequel (ANY)	88	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	88	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Serveur LDAP	TCP	N'importe lequel (ANY)	389	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	389	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	636	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	636	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Serveur NTP	TCP	N'importe lequel (ANY)	123	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	123	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	ICMP	N'importe lequel (ANY)	N'importe lequel (ANY)	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Tout le trafic entrant	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe laquelle (ANY)	Adresse IP de l'hôte	Bloquer (BLOCK)

Remarque : L'adresse IP de l'hôte de destination indiquée dans le tableau 7.5 doit correspondre à l'adresse IP configurée sur votre serveur.

Il est également important de souligner que le filtre Kerberos n'est nécessaire que si vous avez implémenté le paramètre NoDefaultExempt spécifié dans l'article 254728 de la Base de connaissances, « Trafic Kerberos entre les contrôleurs de domaine non sécurisé par IPSec ».

Toutes les règles citées dans ce tableau doivent normalement être mises en miroir lors de leur implémentation. Ainsi, tout trafic entrant sur le contrôleur de domaine pourra retourner au serveur d'origine.

Comme nous l'avons vu, un certain nombre de ports et de services ont été ouverts sur le contrôleur de domaine. Une configuration de sécurité très stricte sur le contrôleur de domaine permettrait de bloquer d'autres ports. Cependant, des ports supplémentaires ont été ouverts en raison des besoins de résolution de noms NetBIOS (Network Basic Input/Output System) de clients en aval, ainsi que pour assurer une administration plus conviviale des ordinateurs.

Les recommandations de l'article 319533 de la Base de connaissances, « How to Restrict FRS Replication to a Specific Static Port » (en anglais), ont été mises en œuvre pour garantir que toute la réplication FRS fonctionne sur un seul et même port. Contoso a choisi le port 57951. Vous devez choisir un numéro de port aléatoire supérieur à 50 000 pour votre environnement.

Les recommandations de l'article Q224196, « Restricting Active Directory Replication Traffic to a Specific Port », ont, elles aussi, été appliquées aux contrôleurs de domaine. Cette mesure garantit que la réplication NTDS se produit sur un port spécifique. Contoso a choisi le port 57 952 pour ce trafic. Ici aussi, vous devez choisir un numéro de port aléatoire supérieur à 50 000.

Après l'implémentation des procédures décrites dans ces articles de la Base de connaissances, vous devez redémarrer les serveurs pour que les modifications soient appliquées.

Enfin, notez que Contoso a implémenté un serveur MOM dans son environnement. En raison de l'interaction constante entre le serveur MOM et le client OnePoint (l'application cliente qui envoie ses rapports à la console MOM), tout le trafic réseau est autorisé entre le serveur et le serveur MOM.

Commandes de script

Les commandes suivantes doivent être implémentées sur le contrôleur de domaine. Elles servent à bloquer tout trafic non explicitement autorisé.

Cet ensemble de commandes est également inclus dans un fichier de commandes qui accompagne ce guide.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"

-f 192.168.100.11+*:53:TCP -f 192.168.100.11+*:53:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"

-f *+192.168.100.11:161:TCP -f *+192.168.100.11:161:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Client"

-f 192.168.100.11+*:445:TCP -f 192.168.100.11+*:445:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Server"

-f *+192.168.100.11:445:TCP -f *+192.168.100.11:445:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Client"

-f 192.168.100.11+*:135:TCP -f 192.168.100.11+*:135:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Server"

-f *+192.168.100.11:135:TCP -f *+192.168.100.11:135:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Ports IN"

-f *+192.168.100.11:57951:TCP -f *+192.168.100.11:57952:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Ports OUT"

-f 192.168.100.11+*:57951:TCP -f 192.168.100.11:+*:57952:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"

-f 192.168.100.11+*:137:TCP -f 192.168.100.11+*:137:UDP

-f 192.168.100.11+*:139:TCP -f 192.168.100.11+*:138:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"

-f *+192.168.100.11:137:TCP -f *+192.168.100.11:137:UDP

-f *+192.168.100.11:139:TCP -f *+192.168.100.11:138:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NTP Client"

-f 192.168.100.11+*:123:TCP -f 192.168.100.11+*:123:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Monitoring"

-f 192.168.100.31+192.168.100.73 -n PASS

ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"

-f 192.168.100.11+*:389:TCP -f 192.168.100.11+*:389:UDP

-f 192.168.100.11+*:636:TCP -f 192.168.100.11+*:636:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"

-f 192.168.100.11+*:88:TCP -f 192.168.100.11+*:88:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"

-f *+192.168.100.11:3389:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "GC Client"

-f 192.168.100.11+*:3268:TCP -f 192.168.100.11+*:3269:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "ICMP"

-f 192.168.100.11+*:*:ICMP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "GC Server"

-f *+192.168.100.11:3268:TCP -f *+192.168.100.11:3269:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "DNS Server"

-f *+192.168.100.11:53:TCP -f *+192.168.100.11:53:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server"

-f *+192.168.100.11:88:TCP -f *+192.168.100.11:88:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "LDAP Server"

-f *+192.168.100.11:389:TCP -f *+192.168.100.11:389:UDP

-f *+192.168.100.11:636:TCP -f *+192.168.100.11:636:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NTP Server"

-f *+192.168.100.11:123:TCP -f *+192.168.100.11:123:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"

-f *+192.168.100.11 -n BLOCK

ipsecpol -w REG -p "Packet Filter" -x

Impact potentiel

Comme ces paramètres n'autorisent pas le transit du trafic par des ports supérieurs aléatoires, le trafic RPC ne sera pas autorisé. Cela peut compliquer la gestion du serveur. Toutefois, grâce à l'emploi de CIFS (Common Internet File System) et des ports NetBIOS de base, l'administration du serveur retrouve en grande partie sa convivialité. Le protocole CIFS définit une norme d'accès aux fichiers à distance. CIFS permet aux utilisateurs disposant de différents ordinateurs et plates-formes de partager des fichiers sans qu'il soit nécessaire d'installer de nouveaux logiciels.

Les administrateurs doivent normalement pouvoir se connecter à l'aide d'un client Terminal Server pour effectuer des tâches d'administration à distance. Sur le contrôleur de domaine, ils doivent pouvoir mapper des lecteurs au départ du contrôleur sur des ordinateurs distants. En outre, ils peuvent mapper des lecteurs d'autres ordinateurs au serveur. Les stratégies ci-dessus peuvent être renforcées pour limiter cette fonctionnalité, mais l'administration du serveur peut alors devenir problématique.

L'implémentation de ce nombre relativement réduit de stratégies IPSec ne doit pas avoir d'impact notable sur les performances du serveur. Cependant, il est nécessaire d'effectuer de nombreux tests avant d'implémenter ces filtres dans votre environnement, pour vous assurer que fonctionnalités et performances ne sont pas affectées. Il se peut également qu'il faille ajouter des règles supplémentaires pour assurer la prise en charge d'autres applications dans votre environnement.

Scénario Contoso

Dans le scénario Contoso, les filtres IPSec spécifiés ci-dessus ont été implémentés sur les contrôleurs de domaines de l'entreprise. L'adresse IP listée a été remplacée dans les scripts et les lignes de commande de façon pertinente pour chaque contrôleur de domaine.

Questions relatives à la sécurité d'Active Directory

Utilisation de Syskey

Syskey est activé sur tous les serveurs Windows 2000 en mode 1 (clé obscurcie). De nombreuses recommandations préconisent l'emploi de Syskey en mode 3 (stockage sur disquette du mot de passe Syskey) ou en mode 2 (mot de passe de console) pour tout contrôleur de domaine exposé à des menaces de sécurité physiques. Vous pouvez également créer une disquette de réparation pour votre contrôleur de domaine et la stocker dans un emplacement sécurisé pour détenir une copie de sauvegarde supplémentaire du mot de passe Syskey en mode 2.

Par exemple, le mode 2 ou le mode 3 sont souvent recommandés pour les contrôleurs de domaines situés dans des succursales dépourvues d'un système de sécurité performant en termes de stockage physique pour les contrôleurs de domaines. Du point de vue de la sécurité, cela semble à première vue logique car le contrôleur de domaine pourrait être redémarré par un auteur d'attaque ayant un accès physique à celui-ci, ce qui, en mode 1, permettrait au pirate de lire et de modifier le contenu de l'annuaire.

Néanmoins, les contraintes de fonctionnement visant à assurer la disponibilité des contrôleurs de domaines via des redémarrages peuvent compliquer la prise en charge des modes Syskey 2 ou 3. Pour tirer parti de la protection supplémentaire qu'offre Syskey, vous devez être prêt à implémenter des procédures opérationnelles supplémentaires dans votre environnement pour répondre aux spécifications de disponibilité de vos contrôleurs de domaines.

En premier lieu, la logistique de gestion des disquettes ou mots de passe Syskey peut s'avérer relativement complexe, particulièrement dans des succursales. À titre d'exemple, demander à l'un de vos directeurs de succursale ou à un membre du personnel administratif local de se rendre dans les bureaux de l'entreprise à 3 heures du matin pour entrer les mots de passe, ou pour insérer une disquette qui permettra à d'autres utilisateurs d'employer le système, entraîne des coûts non négligeables. De plus, ce type de logistique rend extrêmement compliquée l'application de contrats de niveaux de service exigeant une haute disponibilité.

Une autre solution, qui consiste à autoriser votre personnel informatique chargé des opérations centralisées à fournir le mot de passe Syskey à distance, nécessite du matériel supplémentaire : certains fournisseurs de matériel proposent des solutions matérielles complémentaires pour accéder à distance à la console du serveur, ce qui est indispensable dans ce cas.

Enfin, la perte de la disquette ou du mot de passe Syskey rend impossible le redémarrage de votre contrôleur de domaine. Il n'existe pas de méthode permettant de récupérer un contrôleur de domaine en cas de perte du mot de passe ou de la disquette Syskey. Si une telle situation se produit, le contrôleur de domaine doit être reconstruit.

Rôle de serveur d'infrastructure

Dans le scénario Contoso, le rôle de serveur d'infrastructure est assumé soit par un serveur DHCP (Dynamic Host Configuration Protocol), soit par un serveur WINS (Windows Internet Name Service).

Il existe une différence entre la définition du serveur d'infrastructure proposée dans ce guide et le rôle homonyme décrit dans le guide Microsoft Systems Architecture Enterprise Data Center (MSA EDC) : dans le cas qui nous préoccupe, le rôle ne comprend pas le DNS. En effet, dans le scénario Contoso, tout le système DNS est intégré à Active Directory et hébergé sur des contrôleurs de domaines.

Il existe néanmoins des entreprises qui ne souhaitent pas intégrer leur DNS à Active Directory, ou qui veulent héberger une zone principale ou secondaire sur un serveur distinct de leurs contrôleurs de domaines. Si c'est le cas pour votre environnement, notez les conseils dispensés dans la section précédente de ce chapitre, « Paramètres de sécurité supplémentaires — DNS intégré à Active Directory », et appliquez les alternatives et les remarques mentionnées à l'intention des organisations implémentant un DNS non intégré.

Stratégie incrémentielle des serveurs d'infrastructure

La stratégie incrémentielle des serveurs d'infrastructure comprend des paramètres relatifs à des services système requis sur le serveur d'infrastructure.

Services système

Le tableau ci-dessous constitue un récapitulatif des services système prescrits devant être activés ou désactivés sur un serveur d'infrastructure Windows 2000. Ces services sont configurés dans le modèle de sécurité MSS Infrastructure Role.inf, qui est ensuite importé dans l'objet Stratégie de groupe Stratégie d'infrastructure.

Tableau 7.6. Paramètres de services de la stratégie incrémentielle de serveurs d'infrastructure

Paramètre du service dans l'interface	Type de démarrage	Commentaire
DHCPServer	Automatique	Pour fournir des services DHCP aux clients.
NTLMSSP	Automatique	Pour sécuriser les programmes RPC utilisant des transports autres que des canaux nommés.
WINS	Automatique	Pour fournir des services WINS aux clients.

Remarque : Dans le scénario Contoso, le service Serveur DNS est désactivé pour le serveur d'infrastructure parce qu'il est exécuté sur les contrôleurs de domaines.

Certaines organisations qui ont choisi de ne pas utiliser le DNS intégré à Active Directory souhaiteront sans doute exécuter leur serveur DNS principal ou secondaire sur un serveur d'infrastructure.

Dans ce cas, le modèle de stratégie de groupe incrémentielle pour serveurs d'infrastructure doit être modifié pour que le type de démarrage du service soit Automatique.

Si ce type de configuration est nécessaire dans votre organisation, reportez-vous à la section « Paramètres de sécurité supplémentaires — DNS intégré à Active Directory » dans ce chapitre pour consulter des recommandations sur la sécurisation d'un serveur DNS Windows 2000.

Paramètres de sécurité supplémentaires — WINS

Blocage de ports à l'aide de filtres IPSec

Vulnérabilité

Comme nous l'avons dit précédemment, la réduction du nombre de ports ouverts et à l'écoute sur les serveurs de votre organisation limite grandement la surface d'attaque potentielle de chaque ordinateur. Souvent, les ports peuvent offrir aux pirates une véritable rampe de lancement pour une attaque dirigée contre un autre serveur de l'organisation. Par exemple, un ver et un cheval de Troie pourraient installer des applications qui se lient à des ports non autorisés sur le serveur, et écouter les commandes entrantes.

Contre-mesure

Configurez des filtres de blocage IPSec qui n'autorisent que le trafic réseau spécifié ci-dessous. Cette mesure va réduire le nombre d'applications inattendues et non autorisées susceptibles de recevoir des requêtes ou de faire l'objet d'attaques.

Tableau 7.7. Carte du trafic réseau IPSec pour les serveurs WINS

Service	Protocole	Port source	Port de destination	Adresse source	Adresse de destination	Action
Client DNS	TCP	N'importe lequel (ANY)	53	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	53	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur SNMP	TCP	N'importe lequel (ANY)	161	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	161	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client CIFS	TCP	N'importe lequel (ANY)	445	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	445	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur CIFS	TCP	N'importe lequel (ANY)	445	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	445	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client RPC	TCP	N'importe lequel (ANY)	135	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	135	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur RPC	TCP	N'importe lequel (ANY)	135	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	135	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Ports RPC de sortie supplémentaires	TCP	N'importe lequel (ANY)	57952	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Client NetBIOS	TCP	N'importe lequel (ANY)	137	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	137	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	139	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	138	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur NetBIOS	TCP	N'importe lequel (ANY)	137	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	137	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	139	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	138	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client NTP	TCP	N'importe lequel (ANY)	123	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	123	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Client de surveillance	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe lequel (ANY)	Adresse IP de l'hôte	Serveur MOM	Autoriser (ALLOW)
Client LDAP	TCP	N'importe lequel (ANY)	389	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	389	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	636	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	636	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Client Kerberos	TCP	N'importe lequel (ANY)	88	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	88	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Services Terminal Server	TCP	N'importe lequel (ANY)	3389	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client de catalogue global	TCP	N'importe lequel (ANY)	3268	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	TCP	N'importe lequel (ANY)	3269	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur de résolution WINS	TCP	N'importe lequel (ANY)	1512	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	1512	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
Client de réplication WINS	TCP	N'importe lequel (ANY)	42	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	42	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Serveur de réplication WINS	TCP	N'importe lequel (ANY)	42	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
	UDP	N'importe lequel (ANY)	42	N'importe laquelle (ANY)	Adresse IP de l'hôte	Autoriser (ALLOW)
ICMP	ICMP	N'importe lequel (ANY)	N'importe lequel (ANY)	Adresse IP de l'hôte	N'importe laquelle (ANY)	Autoriser (ALLOW)
Tout le trafic entrant	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe lequel (ANY)	N'importe laquelle (ANY)	Adresse IP de l'hôte	Bloquer (BLOCK)

Remarque : L'adresse IP de l'hôte de destination indiquée dans le tableau 7.7 doit correspondre à l'adresse IP configurée sur votre serveur.

Toutes les règles citées ci-dessous doivent normalement être mises en miroir lors de leur implémentation. De cette façon, tout trafic entrant sur le serveur pourra retourner au serveur d'origine.

Comme nous l'avons vu, un certain nombre de ports et de services ont été ouverts sur le serveur WINS. Une configuration de sécurité très stricte sur le serveur WINS permettrait de bloquer des ports supplémentaires. Toutefois, ces ports supplémentaires ont été ouverts pour assurer une administration plus conviviale des ordinateurs. Même avec cette fonctionnalité additionnelle, toute la gestion de WINS et des serveurs sera effectuée à l'aide des services Terminal Server.

Notez en outre que Contoso a implémenté un serveur MOM dans son environnement. En raison de l'interaction constante entre le serveur MOM et le client OnePoint (l'application cliente qui envoie ses rapports à la console MOM), tout le trafic réseau est autorisé entre le serveur et le serveur MOM.

Commandes de script

Les commandes suivantes doivent être implémentées sur le serveur. Ces commandes bloquent tout le trafic réseau non explicitement autorisé. Cet ensemble de commandes est également inclus dans un fichier de commandes qui accompagne ce guide.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"

-f 192.168.100.22+*:53:TCP -f 192.168.100.22+*:53:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"

-f *+192.168.100.22:161:TCP -f *+192.168.100.22:161:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"

-f 192.168.100.22+*:445:TCP -f 192.168.100.22+*:445:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"

-f *+192.168.100.22:445:TCP -f *+192.168.100.22:445:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Client"

-f 192.168.100.22+*:135:TCP -f 192.168.100.22+*:135:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Server"

-f *+192.168.100.22:135:TCP -f *+192.168.100.22:135:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"

-f 192.168.100.22+*:57952:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"

-f 192.168.100.22+*:137:TCP -f 192.168.100.22+*:137:UDP -f

192.168.100.22+*:139:TCP -f 192.168.100.22+*:138:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"

-f *+192.168.100.22:137:TCP -f *+192.168.100.22:137:UDP

-f *+192.168.100.22:139:TCP -f *+192.168.100.22:138:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "NTP Client"

-f 192.168.100.22+*:123:TCP -f 192.168.100.22+*:123:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Monitoring"

-f 192.168.100.22+192.168.100.73 -n PASS

ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"

-f 192.168.100.22+*:389:TCP -f 192.168.100.22+*:389:UDP

-f 192.168.100.22+*:636:TCP -f 192.168.100.22+*:636:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"

-f 192.168.100.22+*:88:TCP -f 192.168.100.22+*:88:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"

-f *+192.168.100.22:3389:TCP -f -n PASS

ipsecpol -w REG -p "Packet Filter" -r "GC Client"

-f 192.168.100.22+*:3268:TCP -f 192.168.100.22+*:3269:TCP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "ICMP"

-f 192.168.100.22+*:*:ICMP -f *+192.168.100.22:*:ICMP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server"

-f *+192.168.100.22:1512:TCP -f *+192.168.100.22:1512:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client"

-f 192.168.100.22+*:42:TCP -f 192.168.100.22+*:42:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server"

-f *+192.168.100.22:42:TCP -f *+192.168.100.22:42:UDP -n PASS

ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"

-f *+192.168.100.22 -n BLOCK

ipsecpol -w REG -p "Packet Filter" –x

Impact potentiel

Comme ces paramètres n'autorisent pas le transit du trafic réseau par des ports supérieurs aléatoires, le trafic RPC ne sera pas autorisé. Cela peut compliquer la gestion du serveur. Toutefois, grâce à l'emploi de CIFS et des ports NetBIOS de base, l'administration du serveur retrouve en grande partie sa convivialité. Les administrateurs doivent normalement pouvoir se connecter à l'aide d'un client Terminal Server pour effectuer des tâches d'administration à distance. En ayant ouvert une session sur le serveur, ils doivent être en mesure de mapper des lecteurs sur des ordinateurs distants. En outre, ils peuvent mapper des lecteurs d'autres ordinateurs sur le serveur. Les stratégies ci-dessus peuvent être renforcées pour limiter cette fonctionnalité, mais l'administration du serveur risque de devenir problématique.

L'implémentation de ce nombre relativement réduit de stratégies IPSec ne doit logiquement pas avoir d'impact notable sur les performances du serveur. Cependant, il est nécessaire d'effectuer de nombreux tests avant d'implémenter ces filtres dans votre environnement, pour vous assurer que les fonctionnalités et performances requises par votre organisation ne sont pas affectées. Il faudra peut-être ajouter des règles supplémentaires pour assurer la prise en charge d'autres applications dans votre environnement.

Scénario Contoso

Contoso a implémenté les filtres IPSec comme spécifié ci-dessus pour ses serveurs WINS.

Paramètres de sécurité supplémentaires — DHCP

Configuration de la journalisation

Vulnérabilité

Il est souvent difficile d'assurer le suivi des clients DHCP dans les entrées de journal, car les seules informations enregistrées dans la plupart des journaux d'événements sont les noms d'ordinateur, et non les adresses IP. Les journaux d'audit DHCP peuvent constituer un atout supplémentaire dans votre recherche des sources d'attaques internes ou d'activités non intentionnelles.

Les informations de ces journaux sont loin d'être toujours fiables, car les noms d'hôte et les adresses MAC (Media Access Control) peuvent être falsifiés ou usurpés. Cependant, dans tous les cas, il est intéressant de collecter ces informations, pour obtenir un peu plus d'éléments qu'une adresse IP et un enregistrement permettant de déterminer l’emploi de cette adresse IP dans un laps de temps assez court. La fonction de journalisation d'audit DHCP n'étant pas, par défaut, activée, ces informations ne sont normalement pas collectées.

Contre-mesure

Sélectionnez l'option Activer l'enregistrement d'audit DHCP.

Impact potentiel

Ces informations peuvent être utilisées de façon abusive ou altérées par des personnes ayant un accès privilégié aux fichiers journaux. Les autorisations sur ces fichiers doivent aussi être limitées.

S'il est en théorie possible que les journaux d'audit DHCP puissent saturer le disque sur lequel ils sont enregistrés, la configuration par défaut de la vérification de l'espace disque pour ces journaux est suffisante pour empêcher ce cas de figure. Contrôlez les paramètres pour vous assurer que l'espace disque disponible est suffisant pour vos autres applications. Pour plus d'informations sur le paramètre DhcpLogMinSpaceOnDisk, consultez l'entrée à ce propos dans le Kit de Ressources Techniques Windows 2000 à l'adresse : http://www.microsoft.com/windows2000/techinfo/reskit/en-us/regentry/46692.asp

Scénario Contoso

Dans le scénario Contoso, ces informations n'ont pas été considérées comme dommageables ou potentiellement utiles dans le cadre de l'audit des activités utilisateur.

Pour activer la journalisation d'audit DHCP

1. Démarrez le composant logiciel enfichable Gestionnaire DHCP.

2. Cliquez avec le bouton droit sur le nom du serveur, cliquez sur Propriétés et sélectionnez l'onglet Général.

3. Activez la case à cocher de l'option Activer l'enregistrement d'audit DHCP.

4. Redémarrez le service Serveur DHCP.

Protection contre les attaques en déni de service sur DHCP

Vulnérabilité

Les serveurs DHCP constituent une ressource centrale, et les attaques en déni de service à leur encontre peuvent avoir des conséquences importantes. Si un serveur DHCP est attaqué et ne peut plus répondre aux demandes DHCP, les clients DHCP ne pourront plus en fin de compte acquérir de baux. Ils perdront alors leur bail IP existant, ainsi que leur capacité à accéder aux ressources réseau.

Il n'est pas très difficile d'écrire un script d'attaque qui demande toutes les adresses disponibles sur un serveur DHCP. Cela épuise la réserve d'adresses IP disponibles, au détriment des demandes légitimes subséquentes de clients DHCP. Il est également possible pour un utilisateur mal intentionné de configurer toutes les adresses IP DHCP sur la carte réseau d'un ordinateur qu'il administre : le serveur DHCP détecte alors des conflits d'adresses IP pour toutes les adresses de son étendue et refuse d'allouer des baux DHCP.

De plus, comme c'est le cas pour les autres services réseau, une attaque en déni de service (par exemple l'épuisement des capacités processeur ou le remplissage du tampon du port d'écoute DHCP), qui épuise la capacité du serveur DHCP à répondre à du trafic légitime, peut rendre impossible l'octroi de baux et de renouvellements aux clients DHCP. Pour consulter des recommandations concernant l'atténuation des risques d'attaques réseau en déni de service, consultez la section « Considérations de sécurité en matière d'attaques réseau » du chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ».

Fort heureusement, le comportement des clients DHCP est tel que des indisponibilités périodiques sont en général tolérées, sauf lors du démarrage du client, moment où celui-ci ne dispose pas d'un bail valide. Si le serveur DHCP ne répond pas lors de l'envoi de l'un des premiers messages de renouvellement DHCP, le client réessaie ultérieurement, et poursuit ses tentatives jusqu'à obtenir un renouvellement ou un