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.
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 re