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
  1. Ouvrez la console MMC Serveur DNS, cliquez avec le bouton droit sur le serveur DNS, puis sélectionnez Propriétés.
  2. 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
  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 « DatabaseDirectory ».
  3. 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 nouveau bail.

Généralement, les attaques en déni de service contre un serveur DHCP ne peuvent être effectuées que par des pirates internes, lesquels sont sans doute moins susceptibles de s'en prendre à des serveurs d'infrastructure qu'à des systèmes contenant des données sensibles, plus intéressantes à dérober.

Contre-mesure

Configurez les serveurs DHCP par paires et partagez les adresses IP affectées sur les serveurs conformément à la règle de bonne pratique 80/20. Pour plus de détails sur la règle 80/20 et le protocole DHCP, voyez le site : http://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_ogjw.asp

Vous pouvez également augmenter la durée du bail sur les étendues DHCP. Ainsi, un plus grand nombre de clients peuvent tolérer une éventuelle indisponibilité pendant une période plus longue. Cependant, cette mesure ne protège pas directement de l'indisponibilité du serveur si un client demande un bail DHCP immédiat, par exemple lors du démarrage d'un nouvel ordinateur sur le réseau local.

Vous pouvez également surveiller les performances et la disponibilité du serveur Windows 2000 et du service DHCP. De plus, vous pouvez configurer la mise en clusters DHCP, qui contribue à atténuer les attaques en déni de service si l'un des hôtes individuels subit lui-même une attaque, et non la ressource DHCP en cluster.

Enfin, vous pouvez implémenter plusieurs serveurs DHCP distincts qui affectent des adresses IP à des sous-réseaux différents dans votre environnement. Chaque serveur DHCP affecte dans ce cas toutes les adresses IP d'un sous-réseau donné. Cette approche isole complètement les sous-réseaux des problèmes que pourrait rencontrer un serveur DHCP affecté à un autre sous-réseau, mais ne procure pas la tolérance de panne nécessaire dans la plupart des environnements d'entreprise.

Impact potentiel

L'impact potentiel est l'accroissement de charge qu'implique la gestion de serveurs supplémentaires. En outre, si vous n'avez pas fait preuve de discernement en configurant les affectations 80/20 des adresses IP de plusieurs serveurs DHCP, il se peut que des serveurs mal configurés affectent la même adresse IP à plusieurs clients. L'augmentation de la durée du bail DHCP peut aussi entraîner l'épuisement, pendant certaines périodes, de l'espace d'adressage DHCP, ce qui constitue simplement un autre type d'attaque de refus de service.

Scénario Contoso

Dans le scénario Contoso, chaque site compte deux serveurs DHCP, configurés selon la règle 80/20 pour l'affectation des adresses IP. La durée de bail par défaut de 8 jours a été jugée suffisante pour tenir compte de périodes, même longues, d'indisponibilité du service DHCP.

Pour modifier la durée du bail DHCP

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

2.       Cliquez avec le bouton droit sur l'étendue dont vous voulez modifier la durée du bail et choisissez Propriétés.

3.       Sous Durée de l'allocation pour les clients DHCP dans l'onglet Général, modifiez les valeurs de l'option Limitée à pour définir la période souhaitée. Vous pouvez également sélectionner l'option de durée de bail Illimitée, mais ce paramètre n'est conseillé que dans des circonstances particulières, et généralement pas pour des déploiements DHCP en entreprise.

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 peuvent 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 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.8. Carte du trafic réseau IPSec pour les serveurs DHCP

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 DHCP

UDP

68

67

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 : Les adresses IP d'hôte de destination indiquées dans le tableau 7.8 doivent correspondre à l'adresse IP configurée sur votre serveur.

Toutes les règles citées ci-dessous doivent de préférence ê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 DHCP. Une configuration de sécurité très stricte sur le serveur DHCP permettrait de bloquer des ports supplémentaires. Toutefois, ces ports ont été ouverts pour assurer une administration plus conviviale des ordinateurs. Même avec cette fonctionnalité additionnelle, toute la gestion de DHCP 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 vont entraîner le blocage de tout 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.21+*:53:TCP -f 192.168.100.21+*:53:UDP -n PASS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     -f 192.168.100.21+*:123:TCP -f 192.168.100.21+*: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.21+*:389:TCP -f 192.168.100.21+*:389:UDP

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

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

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

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

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

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

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

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

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

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

     -f *:68:UDP+192.168.100.21:67:UDP -n PASS

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

     -f *+192.168.100.21 -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 pouvoir se connecter à l'aide d'un client des services 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 se peut qu'il faille 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 DHCP.


Rôle de serveur de fichiers et d'impression

Les serveurs qui assument le rôle de serveurs de fichiers et d'impression peuvent se révéler difficiles à sécuriser, parce que les services les plus essentiels qu'ils délivrent nécessitent les protocoles Windows liés à NetBIOS. Les protocoles pour SMB et CIFS peuvent fournir quantité d'informations à des utilisateurs non authentifiés. C'est pourquoi il est souvent recommandé de les désactiver dans des environnements Windows à haute sécurité.

Stratégie de groupe incrémentielle des serveurs de fichiers et d'impression

La stratégie de groupe incrémentielle des serveurs de fichiers et d'impression effectue les deux actions suivantes :

·         Elle active le service Spouleur, utilisé pour l'impression.

·         Elle désactive le paramètre d'option de sécurité : Signer numériquement les communications serveur (toujours). S'il n'est pas désactivé, les clients seront en mesure d'imprimer mais sans pouvoir consulter la file d'attente d'impression. Lorsqu'ils essaieront de visualiser la file d'attente, ils recevront le message : « Impossible de se connecter. Accès refusé. »

Remarque : Pour que les clients d'impression prennent en charge la consultation des files d'attente d'impression sur un serveur de fichiers et d'impression Windows 2000, l'option Signer numériquement les communications client (toujours) doit être désactivée sur les ordinateurs clients.

Services système

Tout service ou application est une cible potentielle d'attaque. Par conséquent, tous les services ou fichiers exécutables dont vous n'avez pas besoin doivent être désactivés ou supprimés. Dans la stratégie de base des serveurs membres, ces services facultatifs et d'autres services superflus sont désactivés. Cependant, le rôle de serveur de fichiers et d'impression a besoin de l'un de ces services désactivés : le Spouleur d'impression. Voilà pourquoi la valeur Automatique a été attribuée au mode de démarrage de ce service dans la stratégie de groupe de serveurs de fichiers et d'impression.  

Remarque : Le service Spouleur est également utilisé sur tous les systèmes clients qui envoient, ou initient, un travail d'impression sur un serveur d'impression. Comme la stratégie de base des serveurs membres désactive le service Spouleur, vous ne pourrez pas émettre de travaux d'impression au départ de serveurs autres que les serveurs de fichiers et d'impression. Si vous voulez imprimer à partir d'autres serveurs, vous devez activer le service Spouleur dans la stratégie de groupe correspondante.

Il existe des services supplémentaires qui sont souvent activés sur les serveurs de fichiers et d'impression Windows 2000, mais qui ne sont pas essentiels. Ces services sont désactivés dans le scénario Contoso, mais leur emploi et leur sécurité font souvent l'objet de discussions. Il se peut donc que les recommandations relatives à ce rôle de serveur présentées dans ce guide ne soient pas applicables à votre environnement. Vous devez optimiser les paramètres de la stratégie de groupe des serveurs de fichiers et d'impression en fonction des besoins de votre organisation.

Système de fichiers distribués (DFS)

Le système de fichiers distribué (DFS, Distributed File System) intègre des partages de fichiers disparates en un seul espace de noms logique. Il gère des volumes logiques distribués sur un réseau local (LAN) ou étendu (WAN), et il est nécessaire pour le partage SYSVOL Active Directory.

Cet espace de noms est une représentation logique des ressources de stockage réseau disponibles pour les utilisateurs du réseau. Si le système DFS est désactivé, les utilisateurs ne peuvent pas accéder aux données réseau via l'espace de noms logique. Pour y accéder, ils doivent absolument connaître les noms de tous les serveurs et partages de l'espace de noms et accéder à ces cibles une par une.

Dans le scénario Contoso, le système DFS n'est pas pris en charge dans le rôle Serveur de fichiers et d'impression. Il est donc désactivé dans la stratégie de groupe des serveurs de fichiers et d'impression. Si votre organisation utilise DFS sur des serveurs de fichiers pour simplifier l'accès aux ressources distribuées, il vous faudra soit modifier la stratégie de groupe des serveurs de fichiers et d'impression, soit créer un nouvel objet Stratégie de groupe pour activer ce service et l'appliquer ensuite aux serveurs de fichiers au niveau desquels DFS doit être activé.

Service de réplication de fichiers NT

Le service de réplication de fichiers NT (NTFRS, NT File Replication Service) garantit la synchronisation du contenu des répertoires de fichiers sur plusieurs serveurs. Ce service de réplication automatique des fichiers de Windows 2000 est employé pour gérer les copies simultanées de fichiers sur plusieurs serveurs et pour répliquer le volume système de Windows 2000, SYSVOL, sur tous les contrôleurs de domaines.

NTFRS peut être configuré pour répliquer les fichiers sur d'autres cibles associées au système de fichiers distribués (DFS) à tolérance de panne. S'il est désactivé, la réplication des fichiers n'a pas lieu et les données de serveur ne sont pas synchronisées.

Dans le scénario Contoso, NTFRS n'est pas pris en charge dans le rôle Serveur de fichiers et d'impression. Il est donc désactivé dans la stratégie de groupe des serveurs de fichiers et d'impression. Si votre organisation utilise NTFRS sur des serveurs de fichiers pour répliquer les données entre plusieurs serveurs, vous devez soit modifier la stratégie de groupe des serveurs de fichiers et d'impression, soit créer un nouvel objet Stratégie de groupe pour activer ce service et l'appliquer ensuite aux serveurs de fichiers au niveau desquels il doit être activé.

Paramètres de sécurité supplémentaires

Réinitialiser les autorisations sur les partages de fichiers par défaut

Vulnérabilité

Par défaut, les membres des groupes locaux Administrateurs, Utilisateurs avec pouvoir et Opérateurs de serveur peuvent créer de nouveaux partages de fichiers et d'imprimantes. Sur les nouveaux partages de fichiers, l'autorisation de partage par défaut Contrôle total est accordée au groupe prédéfini spécial Tout le monde. Cette situation crée une vulnérabilité potentielle. En effet, des membres distraits de l'équipe informatique pourraient créer accidentellement de nouveaux partages, ce qui permettrait à toute personne en mesure de se connecter au partage de dossier d'obtenir le contrôle total sur les objets qu'ils contiennent.  

Remarque : Le groupe prédéfini Utilisateurs avec pouvoir n'est pas disponible sur les contrôleurs de domaines, mais ces derniers contiennent un groupe présentant des privilèges similaires, Opérateurs de serveur.

Contre-mesure

Formez tous les administrateurs capables de créer de nouveaux partages de fichiers à configurer manuellement les autorisations de partage, afin de limiter l'accès aux partages aux seuls utilisateurs en ayant besoin, mais aussi à les définir de telle sorte qu'elles soient aussi restrictives que possible.

Impact potentiel

Les utilisateurs qui créent et gèrent des dossiers partagés vont devoir configurer manuellement les autorisations sur ces partages.

Scénario Contoso

Tous les partages de fichiers créés sur le serveur de fichiers et d'impression ont été configurés de manière à octroyer l'autorisation Modifier aux Utilisateurs authentifiés. De plus, les dossiers et fichiers partagés ont été correctement sécurisés au moyen d'autorisations NTFS.

Pour modifier manuellement les autorisations des nouveaux partages
  1. Ouvrez le composant logiciel enfichable MMC Gestion de l'ordinateur, accédez à Dossiers partagés, puis au nœud Partages.
  2. Cliquez avec le bouton droit sur Partages, choisissez Nouveau partage de fichiers, puis cliquez sur le bouton Parcourir pour accéder au dossier à partager (par exemple, E:\Users). Attribuez un nom au partage dans la boîte de dialogue Nom du partage.
  3. Dans la fenêtre Créer un dossier partagé, activez la case d'option Personnaliser les autorisations pour les partages et les dossiers et cliquez sur le bouton Personnaliser.
  4. Cliquez sur le bouton Supprimer pour supprimer l'entrée de liste Tout le monde. Cliquez sur le bouton Ajouter, tapez Utilisateurs authentifiés dans la zone de texte inférieure (<< Entrez des noms séparés par des points-virgules ou choisissez à partir de la liste >>) et cliquez sur OK.
  5. Activez la case à cocher Modifier sous la colonne Autoriser, cliquez sur OK, puis sur le bouton Terminer. Choisissez Non dans la boîte de message.

Audit des autorisations sur les partages de fichiers existants

Vulnérabilité

Comme indiqué précédemment, sur les nouveaux partages de fichiers, l'autorisation de partage par défaut Contrôle total est accordée au groupe prédéfini spécial Tout le monde. Il se peut donc que des dossiers partagés existants sur votre réseau accordent le contrôle total au groupe Tout le monde.

Contre-mesure

Auditez tous les dossiers partagés de votre organisation pour vous assurer que les autorisations appropriées leur sont affectées. Cette mesure peut être implémentée manuellement, en accédant à chaque serveur de fichiers, ou en utilisant des commandes telles que net view ou des outils tiers afin de documenter automatiquement les autorisations sur tous les partages de fichiers.

Impact potentiel

La correction des autorisations sur des dossiers partagés peut bloquer l'accès de certains utilisateurs légitimes à ces ressources. Les problèmes de ce genre doivent être résolus au cas par cas, à mesure qu'ils se présentent.

Ils peuvent affecter tout spécialement les utilisateurs dont l'accès repose sur des autorisations anciennes qui permettent toujours d'accéder aux ID de sécurité (SID) stockés dans leur attribut SIDHistory. Un SID est une valeur qui identifie de façon unique chaque utilisateur, groupe, compte d'ordinateur et ouverture de session sur un réseau.

Lorsque des comptes d'utilisateur Windows sont migrés à partir de domaines Windows NT 4.0 plus anciens ou de domaines Windows 2000 extérieurs à la forêt Active Directory, cette opération est souvent effectuée à l'aide d'outils qui conservent les autorisations des utilisateurs, en utilisant l'attribut SIDHistory du compte d'utilisateur du nouveau domaine. L'attribut SIDHistory enregistre les anciens SID du compte migré afin de préserver l'accès aux ressources sécurisées existantes.

Le plus souvent, SIDHistory est employé pour conserver l'accès existant aux partages de fichiers et d'imprimantes sans qu'il soit nécessaire de mettre à jour toutes leurs ACL.

Il se peut que les autorisations sur les partages de fichiers et d'imprimantes existants n'aient pas encore été mises à jour pour permettre l'accès aux groupes ou comptes d'utilisateurs actuels, et que les utilisateurs dépendent encore sans le savoir des autorisations relatives aux SID dans leurs attributs SIDHistory.

Pour les administrateurs ignorant tout des comptes migrés et des attributs SIDHistory, les ACL des partages de fichiers et d'imprimantes peuvent sembler contenir des entrées superflues ou ne correspondant pas à des utilisateurs et à des groupes existants dans le domaine. Or, si ces entrées sont supprimées, les utilisateurs qui dépendent de SIDHistory ne bénéficieront plus de l'accès qu'il procure, et au pire ne pourront plus du tout accéder aux partages de fichiers et d'imprimantes.

Si votre environnement comprend des serveurs de fichiers et d'imprimantes qui étaient en production avant une migration de comptes d'utilisateur à partir d'anciens domaines Windows, vous devez soigneusement documenter les autorisations existantes sur les partages de fichiers et d'imprimantes, avant de modifier les ACL. Soyez prêt à créer de nouvelles ACL qui octroieront le même accès, ou à restaurer le serveur de fichiers et d'impression à partir de supports de sauvegarde afin de rétablir les entrées d'ACL supprimées.

Scénario Contoso

Comme l'environnement Contoso ne comprend aucun serveur de fichiers préexistant, il n'a pas été nécessaire de mettre à jour les autorisations de partage de fichiers existants. Tous les nouveaux partages de fichiers ont été configurés manuellement de façon à n'accorder aux utilisateurs que les autorisations minimales nécessaires.

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 peut limiter 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 peuvent 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.

Les serveurs de fichiers et d'impression sont quelque peu différents des autres rôles de serveur, en cela que le trafic RPC est nécessaire pour que ces serveurs fonctionnent dans un scénario de clients mixtes. Voilà pourquoi plusieurs éléments distincts doivent être pris en compte, conformément à ce que montre la carte de trafic réseau ci-dessous.

Tableau 7.9. Carte du trafic réseau IPSec pour les serveurs de fichiers et d'impression

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)

Ports RPC

TCP

N’importe lequel (ANY)

Plage RPC

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.9 doit correspondre à l'adresse IP configurée sur votre serveur.

Comme le serveur de fichiers et d'impression nécessite de nombreuses connexions RPC pour prendre en charge l'accès client aux ressources de fichiers et d'impression, une plage de ports doit être désignée spécifiquement pour l'emploi de RPC. Si RPC est limité dans votre environnement à un certain nombre de ports, la plage choisie doit comprendre des numéros de port supérieurs à 50 000. Vous pouvez effectuer cette configuration en définissant les paramètres de Registre suivants :

Créez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet si elle n'existe pas encore.

Créez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\Ports et configurez-la en tant que REG_MULTI_SZ, avec une valeur représentant la plage de ports à ouvrir.

Créez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\PortsInternetAvailable et configurez-la en tant que REG_SZ avec une valeur égale à Y.

Créez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\UseInternetPorts et configurez-la en tant que REG_SZ avec une valeur égale à Y.

Après avoir modifié le Registre comme indiqué ci-dessus, redémarrez le serveur.

Ces modifications sont susceptibles de détériorer les performances et doivent faire l'objet de tests avant toute mise en œuvre dans un environnement de production. Le nombre exact de ports à ouvrir dépendra de l'utilisation et des fonctionnalités du 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 de fichiers et d'impression. Une configuration de sécurité très stricte sur le serveur de fichiers et d'impression permettrait de bloquer des ports supplémentaires. Toutefois, ces ports ont été ouverts pour assurer une administration plus conviviale des ordinateurs. Même avec cette fonctionnalité additionnelle, toute la gestion de DHCP 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

L'utilitaire IPSecPol est limité dans la mesure où il ne peut ajouter qu'un port à la fois. Comme RPC impose d'ouvrir une plage de ports, la manière la plus rapide d'y parvenir est de recourir à un script qui générera automatiquement un fichier batch contenant toutes les commandes nécessaires, sur la base du nombre de ports à ouvrir.

Le code exemple ci-dessous va générer un fichier appelé c:\ipsec.bat qui contient une liste distincte pour chaque port à ajouter dans la stratégie IPSec. La variable PORT_START définit le premier port dans la plage RPC et la variable PORT_END définit la fin de la plage. POLICY_NAME est le nom de la stratégie IPSec à laquelle les filtres de port seront ajoutés. La valeur IP_ADDR doit être modifiée pour correspondre à l'adresse IP du serveur sur lequel la stratégie sera implémentée.

PORT_START = 57901

PORT_END = 57950

POLICY_NAME = "Packet Filter"

RULE_NAME = "RPC Ports"

IP_ADDR = "192.168.100.31"

BATCH_FILE = "c:\ipsec.bat"

 

Dim fso

Dim tf

Const ForWriting = 2

Set fso = CreateObject("Scripting.FileSystemObject")

Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)

 

tf.Write "ipsecpol -w REG -p " & chr(34) & POLICY_NAME & chr(34) & " -r " &

chr(34) & RULE_NAME & chr(34)

For i = PORT_START TO PORT_END

tf.Write " -f *+" & IP_ADDR & ":" & i & ":TCP"

Next

tf.WriteLine " -n PASS"

tf.Close

Vous pourriez utiliser du code similaire pour générer un fichier batch qui exécuterait et appliquerait les stratégies IPSec avec très peu d'intervention manuelle. Ce fichier batch servirait à définir les plages référencées dans le tableau comme « Plage RPC ». Les autres ports devraient être définis par des méthodes semblables à celles évoquées dans le cadre des explications sur les autres rôles de serveur.

Une fois qu'une plage de ports est déterminée et que les instructions IPSecPol servant à implémenter les filtres sont créées, ces instructions et les commandes restantes doivent être exécutées sur le serveur. Voici l’exemple d'un ensemble complet de commandes. Cet ensemble 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.31+*:53:TCP -f 192.168.100.31+*:53:UDP -n PASS

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

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

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

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

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

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

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

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

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

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

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

     -f *+192.168.100.31:57901:TCP -f *+192.168.100.31:57902:TCP

     -f *+192.168.100.31:57903:TCP -f *+192.168.100.31:57904:TCP

     -f *+192.168.100.31:57905:TCP -f *+192.168.100.31:57906:TCP

     -f *+192.168.100.31:57907:TCP -f *+192.168.100.31:57908:TCP

     -f *+192.168.100.31:57909:TCP -f *+192.168.100.31:57910:TCP

     -f *+192.168.100.31:57911:TCP -f *+192.168.100.31:57912:TCP

     -f *+192.168.100.31:57913:TCP -f *+192.168.100.31:57914:TCP

     -f *+192.168.100.31:57915:TCP -f *+192.168.100.31:57916:TCP

     -f *+192.168.100.31:57917:TCP -f *+192.168.100.31:57918:TCP

     -f *+192.168.100.31:57919:TCP -f *+192.168.100.31:57920:TCP

     -f *+192.168.100.31:57921:TCP -f *+192.168.100.31:57922:TCP

     -f *+192.168.100.31:57923:TCP -f *+192.168.100.31:57924:TCP

     -f *+192.168.100.31:57925:TCP -f *+192.168.100.31:57926:TCP

     -f *+192.168.100.31:57927:TCP -f *+192.168.100.31:57928:TCP

     -f *+192.168.100.31:57929:TCP -f *+192.168.100.31:57930:TCP

     -f *+192.168.100.31:57931:TCP -f *+192.168.100.31:57932:TCP

     -f *+192.168.100.31:57933:TCP -f *+192.168.100.31:57934:TCP

     -f *+192.168.100.31:57935:TCP -f *+192.168.100.31:57936:TCP

     -f *+192.168.100.31:57937:TCP -f *+192.168.100.31:57938:TCP

     -f *+192.168.100.31:57939:TCP -f *+192.168.100.31:57940:TCP

     -f *+192.168.100.31:57941:TCP -f *+192.168.100.31:57942:TCP

     -f *+192.168.100.31:57943:TCP -f *+192.168.100.31:57944:TCP

     -f *+192.168.100.31:57945:TCP -f *+192.168.100.31:57946:TCP

     -f *+192.168.100.31:57947:TCP -f *+192.168.100.31:57948:TCP

     -f *+192.168.100.31:57949:TCP -f *+192.168.100.31:57950:TCP -n PASS

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

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

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

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

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

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

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

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

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

     -f 192.168.100.31+*:123:TCP -f 192.168.100.31+*: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.31+*:389:TCP -f 192.168.100.31+*:389:UDP

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

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

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

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

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

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

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

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

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

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

     -f *+192.168.100.31 -n BLOCK

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

Impact potentiel

Comme ces paramètres autorisent toujours le trafic RPC, le serveur fonctionne pratiquement comme si le paramètre n'était pas appliqué. Le principal avantage de cette configuration est que le trafic RPC est limité à une plage donnée. Cependant, elle peut entraîner des problèmes de performances, en fonction du nombre d'utilisateurs qui se connectent à l'ordinateur et du nombre de connexions RPC devant être établies. Il est nécessaire d'effectuer de nombreux tests avant d'implémenter ces filtres dans votre environnement. Les stratégies ci-dessus peuvent être renforcées pour limiter cette fonctionnalité, mais l'administration du serveur risque de devenir problématique.

Comme indiqué précédemment, l'implémentation de ce nombre relativement réduit de stratégies IPSec ne doit théoriquement pas avoir d'impact notable sur les performances du serveur. Cependant, il est nécessaire d'effectuer des tests approfondis avant d'implémenter ces filtres dans votre environnement, pour vous assurer que les fonctionnalités et les performances ne sont pas affectées. Il se peut qu'il faille 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 de fichiers et d'impression.

Rôle de serveur IIS

Des études récentes ont révélé qu'un serveur IIS sur neuf est sensible à l'une ou l'autre forme d'attaque. Internet Information Services 5.0 (IIS) est installé par défaut sur tous les serveurs Windows 2000. IIS 5.0 active un certain nombre de fonctionnalités d'application en installation standard et représente dès lors un bon exemple de service d'application conviviale mais vulnérable en termes de sécurité. Cette vulnérabilité a été exploitée par le ver Nimda.

Un renforcement de la sécurité se traduira vraisemblablement par un léger sacrifice au niveau de la convivialité d'IIS. IIS 5.0 est extrêmement souple, dans le sens où il comprend un grand nombre de fonctionnalités activées dans le cadre de l'installation par défaut. Comme pour tout serveur, plus le nombre de services et fonctionnalités activés est élevé, plus la surface d'attaque de la ressource est importante.

Cependant, il est possible de mieux verrouiller IIS tout en préservant la vaste majorité de ses fonctionnalités essentielles. Le verrouillage de serveurs IIS, autrefois long et fastidieux, a été simplifié par l'emploi d'outils tels que IISLockdown et URLScan.

IISLockdown est un utilitaire Microsoft qui désactive les fonctionnalités non employées dans les produits Microsoft dépendant d'IIS, réduisant ainsi la surface d'attaque. URLScan est un filtre ISAPI (Internet Server Application Programming Interface) qui analyse les paquets HTTP entrants et peut rejeter des demandes Web en fonction de règles que vous définissez.

Ces outils, alliés à une bonne architecture de serveur et à l'application de filtres IPSec sur l'interface réseau exposée aux clients du serveur IIS, peuvent offrir une solution extrêmement sécurisée.

Application de correctifs sur le serveur

Première étape dans la sécurisation des serveurs IIS de votre environnement : il est impératif d'appliquer tous les Service Packs et correctifs logiciels de sécurité disponibles. Les procédures requises sont décrites au chapitre 8, « Gestion des correctifs ».

En appliquant immédiatement ces correctifs au serveur, avant même son introduction sur le réseau, le risque d'infection par un ver ou un autre exploit tel que Code Red ou Nimda s'en voit fortement réduit. Il est donc recommandé d'appliquer au serveur autant de correctifs et de mesures de sécurisation que possible avant de l'introduire sur le réseau.

IISLockdown

Après avoir appliqué les correctifs nécessaires, la deuxième étape du renforcement de la sécurité d'un serveur IIS consiste à configurer le serveur au moyen des outils automatisés recommandés, tels que IISLockdown et URLScan.

Présentation

Les serveurs IIS peuvent assurer un grand nombre de fonctionnalités. Toutefois, pour les sécuriser, il est indispensable de limiter ces fonctionnalités au strict nécessaire. La méthode la plus simple pour ce faire est de recourir à l'utilitaire IISLockdown.

IISLockdown est un utilitaire configurable qui vous permet de définir le rôle de votre serveur IIS (par exemple, serveur Web dynamique ou serveur Exchange). Il supprime ensuite toute fonctionnalité qui n'est pas nécessaire pour assurer le rôle spécifié. Vous devez tester minutieusement toutes les modifications avant de les implémenter dans un environnement de production.

Remarque : IISLockdown est disponible dans le jeu d’outils Security Toolkit et sur le site Web de Microsoft Security. Pour plus d'informations, reportez-vous à la section « Informations complémentaires » en fin de chapitre.

IISLockdown peut effectuer de nombreuses tâches dans la procédure de sécurisation des serveurs Web, et notamment :

·         désactivation de services et de composants ;

·         installation de l'outil URLScan ;

·         suppression des mappages superflus de scripts de DLL ISAPI ;

·         suppression des répertoires superflus ;

·         modification des ACL des fichiers et dossiers.

Vous pouvez utiliser IISLockdown pour sécuriser de nombreux types de rôles de serveur IIS. Vous devez choisir le rôle le mieux adapté aux applications hébergées sur chaque serveur IIS dans votre environnement.

Installation d'IISLockdown

Dans l'environnement Contoso, IIS est généralement utilisé en tant que serveur Web dynamique servant à prendre en charge l'emploi d'Active Server Pages (ASP). La version 2.1 d'IISLockdown a été utilisée pour sécuriser les serveurs dans l'environnement Contoso. Il s'agissait de la dernière version de l'utilitaire au moment de la rédaction de ce guide. Il est possible que les versions plus anciennes ne fonctionnent pas aussi bien, et que des versions futures prennent en charge de nouvelles fonctionnalités qui ne sont pas décrites ici.

Pour sécuriser un serveur Web dynamique à l'aide de IISLockdown

1.       Démarrez iislockd.exe.

2.       Cliquez sur Next.

3.       Sélectionnez I agree, puis cliquez sur Next.

4.       Choisissez Dynamic Web server (ASP enabled), puis cliquez sur Next.

5.       Vérifiez que l'option Install URLScan filter on the server est sélectionnée et cliquez sur Next.

6.       Cliquez sur Next.

7.       Si la boîte de dialogue Digital Signature Not Found s'affiche, cliquez sur Yes.

8.       Cliquez sur Next.

9.       Cliquez sur Finish.

Remarque : Vous pouvez également exécuter IISLockdown en mode sans assistance pour automatiser le déploiement des paramètres choisis. Pour plus de détails, consultez le fichier d'aide RunLockdUnattended.doc inclus dans le fichier ZIP à extraction automatique iislockd.exe.  

Si vous configurez le serveur IIS en tant que serveur Web dynamique, conformément à la procédure ci-dessus, les modifications suivantes sont apportées :

·         Le service FTP est désactivé.

·         Le service de messagerie (SMTP) est désactivé.

·         Le service NNTP (Network News Transport Protocol) est désactivé.

·         Le mappage de script Index Server Web Interface (.idq, .htw, .ida) est désactivé.

·         Le mappage de script SSI (.shtml, .shtm, .stm) est désactivé.

·         Le mappage de script Internet Data Connector (.idc) est désactivé.

·         Le mappage de script HTR (.htr) est désactivé.

·         Le mappage de script d'impression Internet (.printer) est désactivé.

·         Le répertoire virtuel de l'imprimante est supprimé.

·         Le répertoire virtuel IIS Samples est supprimé.

·         Le répertoire virtuel Scripts est supprimé.

·         Le répertoire virtuel MSADC est supprimé.

·         Le répertoire virtuel IISAdmin est supprimé.

·         Le site Web IISAdmin est supprimé.

·         Le répertoire virtuel IISHelp est supprimé.

·         Des autorisations sur les fichiers sont définies pour empêcher les utilisateurs IIS anonymes d'exécuter les utilitaires système.

·         Des autorisations sur les fichiers sont définies pour empêcher les utilisateurs IIS anonymes d'écrire dans les répertoires du contenu.

·         WebDAV (Web Distributed Authoring And Versioning) est désactivé.

·         Le filtre URLScan est installé sur le serveur.

Remarque : Si un modèle de sécurité IISLockdown différent est requis, ou s'il faut personnaliser les paramètres choisis, il peut être nécessaire de réactiver des services supplémentaires désactivés par la stratégie de groupe des serveurs membres. Il peut s'agir par exemple des services SMTP, NNTP ou FTP. Sachez toutefois qu'il ne suffit pas d'exécuter IISLockdown et de sélectionner l'un de ces services pour le réactiver de manière permanente : en effet, la stratégie de groupe IIS désactivera à nouveau le service à la prochaine actualisation de stratégie. Les services doivent être activés manuellement dans la stratégie de groupe IIS que vous avez déployée dans l'unité d'organisation Web.  

Services

Vulnérabilité

Tout service ou application en cours d'exécution est une cible potentielle d'attaque ; les services et composants non exécutés, en revanche, 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 d'attaque des serveurs IIS dans l'environnement.

Contre-mesure

Employez l'utilitaire IISLockdown pour désactiver les services SMTP et FTP, installés par défaut. NNTP doit également être désactivé s'il a été installé avec IIS.

Vous pouvez aussi recourir à IISLockdown pour désinstaller ces services.

Impact potentiel

Le paramètre UninstallServices dans le fichier iislockd.ini mérite une attention toute particulière. Ce paramètre a la valeur FALSE pour tous les modèles préconfigurés fournis avec la version 2.1 de IISLockdown. Si vous modifiez le fichier iislockd.ini pour lui affecter la valeur TRUE, ces services ne seront plus installés sur le serveur auquel IISLockdown a été appliqué. Pour réactiver l'un de ces services sur un serveur, vous devez le réinstaller manuellement via Ajout/Suppression de programmes ou reconstruire le serveur en fonction de sa méthodologie de déploiement.

Scénario Contoso

IISLockdown a été utilisé dans le scénario Contoso pour désactiver les services NNTP, FTP et SMTP sur les serveurs IIS de l'organisation, non pour les désinstaller.

Pour désinstaller les services NNTP, FTP et SMTP de serveurs IIS en utilisant un fichier IISLockd.ini personnalisé

1.       Ouvrez IISLockd.exe avec un utilitaire de décompression tel que WinZip et extrayez tous les fichiers sur votre disque dur.

2.       Ouvrez iislockd.ini dans le Bloc-notes.

3.       Trouvez la section correspondant au rôle à configurer (par exemple, [dynamicweb] pour le rôle de serveur Web dynamique) et modifiez le paramètre UninstallServices de cette section pour lui attribuer la valeur TRUE.

4.       Sous la section [Info], configurez le paramètre UnattendedServerType en tapant le nom qui correspond au modèle de serveur que vous voulez utiliser. Par exemple, si vous voulez appliquer le modèle dynamicweb, modifiez UnattendedServerType pour lui affecter la valeur dynamicweb.

5.       Attribuez au paramètre Unattended la valeur TRUE.

6.       Enregistrez le fichier iislockd.ini.

7.       Exécutez iislockd.exe à partir d'une ligne de commande ou d'un script.

Désactivation des mappages de script

Vulnérabilité

Les mappages de script liés à IIS sont une excellente illustration du principe selon lequel une augmentation de la fonctionnalité peut entraîner une détérioration de la sécurité. Si les mappages de script sont très puissants et peuvent conférer une énorme valeur ajoutée à un site Web, pratiquement tous ont été exploités à un moment ou à un autre par des menaces de sécurité depuis la sortie de Windows 2000.

Les mappages de script .IDA et .IDQ sont des extensions ISAPI qui assurent une fonctionnalité étendue aux serveurs d'index. Entre autres vulnérabilités, un tampon non vérifié dans le fichier idq.dll a introduit une vulnérabilité qui pouvait permettre à un pirate de prendre le contrôle total du serveur. Cette vulnérabilité a été particulièrement exploitée, comme on le sait, par le ver Code Red. Pour plus de détails à ce propos, consultez le bulletin de sécurité Microsoft MS01-033.

Le filtre ISAPI .HTW assure une fonctionnalité supplémentaire à Microsoft Index Server. À cause d'une vulnérabilité dans le fichier associé webhits.dll, il peut arriver qu'un utilisateur ouvre malencontreusement un lien hostile sur un navigateur ou un client de messagerie acceptant le format HTML, ce qui peut entraîner l'exécution de contenu actif comme Javascript. Pour plus de détails à ce propos, consultez le bulletin de sécurité Microsoft MS01-025.

Le mappage .SHTML est l'interprète Smart HTML, qui fait partie des extensions serveur de Microsoft® FrontPage® utilisées pour prendre en charge SSI (Server Side Include). Le fichier ssiinc.dll contenait une vulnérabilité qui pouvait être exploitée pour envoyer du contenu spécifié par un pirate et situé sur le serveur Web, à destination du navigateur. Pour plus de détails à ce propos, consultez le bulletin de sécurité Microsoft MS00-060.

Le mappage .IDC peut être exploité par l'intermédiaire d'une vulnérabilité de script intersite, qui renvoie l'URL tout entière dans une page d'erreur, ce qui permet aux auteurs d'attaques d'exécuter du code de script arbitraire sur le serveur. Ce problème a été résolu dans le Service Pack 3 de Windows 2000.

L'extension ISAPI .HTR est une technologie de script de première génération pour les développeurs ASAP, qui n'a toutefois jamais rencontré de grand succès. Une vulnérabilité dans le fichier ism.dll peut être exploitée pour révéler le code source de fichiers ASP. Pour plus de détails à ce propos, consultez les bulletins de sécurité Microsoft MS00-031 et MS01-014.

L'extension ISAPI .PRINTER a été créée pour assurer l'impression sur des protocoles Internet. Une vulnérabilité dans msw3prt.dll peut être exploitée pour fournir à un pirate une console distante sur le système IIS cible. Pour plus de détails à ce propos, consultez le bulletin de sécurité Microsoft MS01-023.

Contre-mesure

Tous les filtres ISAPI et les mappages superflus doivent être supprimés du système.

Les mappages de script superflus doivent être redirigés vers le fichier 404.dll. Ce fichier est un filtre ISAPI qui répond par une simple page d'erreur 404 aux demandes interceptées par l'un de ces mappages de script inutilisés.

Remarque : La redirection du mappage d'une extension inutilisée vers 404.dll vaut mieux que sa suppression pure et simple. Si le mappage est supprimé et qu'un fichier est laissé par erreur sur le serveur (ou copié là par inadvertance), il sera affiché en clair s'il est demandé, ou peut-être accidentellement remappé.

Les fichiers et dossiers associés de chaque mappage de script doivent aussi être supprimés du système de fichiers. Cette procédure ne s'effectue pas à l'aide de l'utilitaire IISLockdown, mais est détaillée à la section « Suppression de répertoires virtuels et d'exemples d'applications », ci-dessous.

Impact potentiel

L'impact potentiel du remappage de ces scripts est la désactivation de fonctionnalités que ces mappages rendaient possibles. Si certaines applications Web ont besoin des mappages de script, il est possible alors qu'elles ne fonctionnent plus.

Scénario Contoso

IISLockdown a été utilisé dans le scénario Contoso pour supprimer tous les filtres ISAPI superflus des serveurs IIS de l'organisation. Seuls les fichiers .ASP et le contenu statique sont toujours activés sur les serveurs IIS. Chaque mappage de script a été automatiquement redirigé vers le filtre 404.dll.

Le mappage sur 404.dll peut également s'effectuer manuellement en cas de nouvelles extensions ou si vous n'utilisez pas IISLockdown.

Pour mapper manuellement des extensions sur 404.dll
  1. Démarrez le composant logiciel enfichable MMC Gestionnaire des services Internet.
  2. Cliquez avec le bouton droit sur votre serveur (c’est-à-dire le site principal) dans le volet gauche et cliquez sur Propriétés.
  3. Vérifiez que le service WWW est sélectionné dans la liste déroulante Propriétés principales, puis cliquez sur le bouton Modifier adjacent.
  4. Cliquez sur l'onglet Répertoire de base.
  5. Cliquez sur Configuration.
  6. Sélectionnez l'une des extensions dans la liste des mappages, puis cliquez sur Modifier.
  7. Cliquez sur Parcourir et naviguez jusqu'à c:\winnt\system32\inetsrv\404.dll.
  8. Cliquez sur Ouvrir, puis sur OK.
  9. Répétez les étapes 6, 7 et 8 pour toutes les extensions de fichier restantes.

Impression Internet

Windows 2000 Server permet d'imprimer à partir d'Internet. Des imprimantes sont attachées au serveur et administrées par l'intermédiaire d'une page Web.

Vulnérabilité

La fonctionnalité d'impression Internet accroît la surface d'attaque d'un serveur IIS. En outre, si elle est désactivée à partir du Gestionnaire des services Internet, et qu'un administrateur redémarre le serveur ou ferme une session, la stratégie de groupe qui active la fonctionnalité la redémarre.

Il est important de s'assurer que l'impression Internet est désactivée par l'intermédiaire d'un objet Stratégie de groupe qui contrôle le serveur avant son déploiement. La stratégie de groupe par défaut n'active ni ne désactive l'impression Internet.

Contre-mesure

Désactivez l'impression Internet via une stratégie de groupe, en recourant à la procédure utilisée dans le scénario Contoso.

Vous pouvez aussi la désactiver à l'aide du Gestionnaire des services Internet. S'il existe un conflit entre les paramètres de la stratégie de groupe et ceux du Gestionnaire des services Internet, les premiers sont prioritaires.

Si l'impression Internet est supprimée à l'aide du Gestionnaire des services Internet (IIS), vérifiez qu'elle n'est pas réactivée par des stratégies de groupe locales ou du domaine. Pour plus de détails, reportez-vous à la procédure du scénario Contoso.

Impact potentiel

Tous les clients qui impriment sur des imprimantes partagées au départ de ce serveur IIS via le protocole IPP (Internet Printing Protocol) ne seront plus en mesure d'exploiter IPP pour imprimer à partir d'imprimantes partagées sur le Web.

Scénario Contoso

IISLockdown a été utilisé dans l'environnement Contoso pour désactiver l'impression Internet. Aucune imprimante n'est partagée au départ des serveurs IIS.

Pour désactiver l'impression Internet au moyen de la stratégie de groupe

1.       Lancez Utilisateurs et ordinateurs Active Directory en tant qu'utilisateur autorisé à modifier l'objet Stratégie de groupe dans lequel vous souhaitez désactiver IPP.

2.       Cliquez avec le bouton droit sur l'unité d'organisation qui contient l'objet Stratégie de groupe et choisissez Propriétés.

3.       Choisissez l'onglet Stratégie de groupe, cliquez sur l'objet Stratégie de groupe à modifier, puis sur le bouton Modifier.

4.       Double-cliquez sur le dossier Configuration ordinateur, puis sur Modèles d'administration et sur Imprimantes.

5.       Double-cliquez sur le paramètre Impression basée sur le Web, activez la case à cocher Désactivé et cliquez sur OK.

Suppression de répertoires virtuels et d'exemples d'applications

Vulnérabilité

IIS 5.0 comprend un grand nombre d'exemples d'applications qui ne sont pas installés par défaut, mais qui sont disponibles dans le cadre de l'installation complète d'IIS. De plus, il inclut divers répertoires virtuels contenant des exemples d'applications IIS.

Ces applications exemples qui font partie de l'installation par défaut d'IIS 5.0 n'ont pas été développées pour être hébergées sur des serveurs IIS de production à haute sécurité. Il est possible qu'un pirate puisse exploiter une faiblesse intrinsèque dans une application de ce genre ou dans sa configuration, afin d'attaquer un site Web. En supprimant les exemples d'applications, vous pouvez réduire la surface d'attaque du serveur Web.

Les répertoires virtuels eux-mêmes ne sont pas configurés pour offrir un niveau de sécurité élevé. Par exemple, le répertoire \Scripts par défaut permet à n'importe qui d'exécuter les programmes qu'il contient.

Contre-mesure

Les répertoires virtuels doivent être supprimés d'IIS manuellement ou à l'aide de l'utilitaire IISLockdown. Les fichiers et dossiers sous-jacents de ces répertoires virtuels doivent eux aussi être supprimés manuellement.

Pour supprimer un exemple d'application

1.       Ouvrez le composant logiciel enfichable MMC IIS pour supprimer le répertoire virtuel approprié.

2.       Utilisez l'Explorateur Windows pour supprimer physiquement le dossier sous-jacent.

Pour supprimer l'application d'administration IIS à distance

1.       Utilisez le composant logiciel enfichable MMC IIS pour arrêter le site Web d'administration.

2.       Employez le composant logiciel enfichable pour supprimer le répertoire virtuel.

3.       Utilisez l'Explorateur Windows pour supprimer physiquement le dossier sous-jacent.

Impact potentiel

Il ne doit logiquement y avoir aucun impact, à moins que, ce qui est peu probable, vous n'ayez utilisé l'un des exemples d'applications dans un environnement de production.

Scénario Contoso

IISLockdown a été utilisé dans le scénario Contoso pour supprimer tous les répertoires virtuels exemples. Les exemples d'applications et tous les autres fichiers superflus ont été supprimés manuellement, y compris les répertoires suivants :

C:\inetpub\scripts

C:\inetpub\iissamples

C:\Program Files\Common files\system\msadc

C:\winnt\help\iishelp

C:\Winnt\system32\inetsrv\iisadmin

Verrouillage des autorisations de fichiers des utilisateurs IIS

Vulnérabilité

Il se peut qu'un pirate, après avoir accédé à un système sans autorisation, puisse utiliser des commandes système pour exécuter des actions ou consulter des données sur un serveur Web distant. Grâce à ces mêmes commandes système, un pirate pourrait transmettre et exécuter d'autres applications sur le serveur.

Contre-mesure

Appliquez les deux contre-mesures suivantes :

·         Ajoutez une entrée de contrôle d'accès (ACE) à tous les fichiers exécutables dans C:\WINNT et à tous les sous-dossiers (en d'autres termes, ajoutez l'ACE à la liste ACL existante). L'ACE doit refuser les privilèges d'exécution à tous les comptes d'utilisateur anonyme configurés sur l'ordinateur (y compris IUSR_nomd'ordinateur), de même qu'à tous les comptes du serveur utilisés pour exécuter des applications Web (dont IWAM_nomd'ordinateur).

·         Ajoutez une ACE à l'ACL existante sur tous les fichiers référencés par des répertoires virtuels, et incluez les fichiers et dossiers situés sur des ordinateurs distants. L'ACE doit refuser les privilèges d'écriture à tous les comptes d'utilisateur anonyme configurés sur l'ordinateur (y compris IUSR_nomd'ordinateur), de même qu'à tous les comptes du serveur utilisés pour exécuter des applications Web (dont IWAM_nomd'ordinateur).

Ces deux actions peuvent être exécutées automatiquement à l'aide d'IISLockdown.

Impact potentiel

Aucune application Web Microsoft ne doit logiquement souffrir des contre-mesures ci-dessus, mais il est possible qu'une application personnalisée dépende des autorisations qui ont été refusées. Toutes les applications personnalisées doivent être testées en environnement de laboratoire, après apport de ces modifications, avant d'implémenter ces dernières sur des serveurs IIS de production.

Scénario Contoso

IISLockdown a été utilisé dans le scénario Contoso pour configurer les paramètres ACE Refuser sur les fichiers et répertoires spécifiés.

Désactivation de WebDAV

Vulnérabilité

WebDAV peut être exploité pour exécuter un script qui fonctionne dans le contexte de sécurité de la thread WebDAV. Cela signifie qu'un pirate pourrait parcourir l'intranet de votre organisation et éventuellement accéder à des informations confidentielles uniquement accessibles au compte de service WebDAV. Pour plus de détails à ce propos, consultez le bulletin de sécurité Microsoft MS01-022.

Contre-mesure

Désactivez cette fonctionnalité WebDAV. Configurez une entrée ACE sur la DLL qui implémente la fonctionnalité WebDAV (Httpext.Dll) pour empêcher le chargement de cette DLL dans le processus IIS. IISLockdown peut effectuer cette tâche automatiquement. Certaines applications, tels Exchange 2000 et Microsoft® SharePoint™ Portal Server 2001, nécessitent WebDAV pour assurer la fonctionnalité du produit. Dans ce cas, il vaut mieux appliquer le dernier Service Pack pour s'assurer que la fonctionnalité WebDAV est totalement corrigée.

Impact potentiel

Toute application dépendant de WebDAV serait désactivée par cette mesure. Testez toutes les applications dont vous pensez qu'elles peuvent contenir une fonctionnalité WebDAV dans un environnement de laboratoire après avoir apporté ces modifications, et avant d'implémenter ces dernières sur des serveurs IIS de production.

Scénario Contoso

IISLockdown a été utilisé dans le scénario Contoso pour supprimer la fonctionnalité WebDAV de tous les serveurs, dans la mesure où aucune application WebDAV n'est déployée.

URLScan

URLScan est un filtre ISAPI qui est installé soit quand vous exécutez IISLockdown, soit séparément après avoir extrait les fichiers de l'exécutable d'IISLockdown. URLScan permet aux administrateurs de sites Web de limiter le type de demandes HTTP que le serveur traitera. En bloquant des demandes HTTP spécifiques, le filtre URLScan empêche des demandes potentiellement préjudiciables d'atteindre le serveur et de causer des dommages.

Présentation

URLScan bloque de nombreux types de demandes HTTP inhabituelles ou potentiellement dommageables, particulièrement celles qui contiennent des caractères utilisés par le passé pour exploiter des vulnérabilités, comme « .. », employé pour les attaques de parcours de répertoires. Ces demandes sont consignées dans le répertoire %systemroot%\system32\inetsrv\urlscan.

Même si c'est une URL d'application Web légitime qui contient ces caractères dans son chemin d'accès, URLScan rejette la demande et une réponse 404 « introuvable » est renvoyée au client. Si vous devez autoriser ces caractères pour la prise en charge de votre application Web, attribuez la valeur 1 au paramètre AllowDotInPath dans le fichier de configuration urlscan.ini (situé dans le dossier %systemroot%\system32\inetsrv\urlscan\). Il est important de savoir que la modification du jeu de caractères par défaut autorisés par URLScan risque de réduire la sécurité du système.

Configuration d'URLScan

La majeure partie des tâches de configuration d'URLScan sont effectuées par la manipulation du fichier URLScan.ini, qui se trouve dans le répertoire %systemroot%\system32\inetsrv\urlscan. Ce fichier contient plusieurs sections de paramètres, répertoriées ci-dessous.

Options

La section Options du fichier urlscan.ini contient seize paramètres employés par URLScan. Certains de ces paramètres se réfèrent à la configuration de sous-paramètres dans le fichier urlscan.ini. Il s'agit de :

·         UseAllowVerbs

·         UseAllowExtensions

·         NormalizeUrlBeforeScan

·         VerifyNormalization

·         AllowHighBitCharacters

·         AllowDotInPath

·         RemoveServerHeader

·         AlternateServerName

·         EnableLogging

·         PerProcessLogging

·         PerDayLogging

·         LogLongUrls

·         LoggingDirectory

·         AllowLateScanning

·         RejectResponseUrl

·         UseFastPathReject.

La plupart de ces paramètres ne prennent que la valeur 1 (vrai) ou 0 (faux). Une partie d'entre eux nécessite une configuration plus détaillée, comme expliqué ci-dessous. Pour plus d'informations, consultez l'article 326444 de la Base de connaissances, « HOW TO: Configure the URLScan Tool » (en anglais).

Verbes autorisés et refusés

Les verbes sont une composante critique des demandes HTTP. GET et HEAD sont les verbes les plus couramment utilisés par les navigateurs Web, pour la navigation simple. Par exemple, un navigateur Web utilise une commande GET pour extraire des informations de l'URL spécifiée.

Les navigateurs peuvent employer d'autres verbes, comme PUT, POST et REPLY, pour modifier le contenu de sites Web. Par exemple, les extensions serveur FrontPage utilisent les verbes POST et OPTIONS pour publier du contenu Web.

Le paramètre UseAllowVerbs dans la section Options détermine si la section des verbes autorisés (AllowVerbs) du fichier .INI sera traitée. Si la valeur de UseAllowVerbs est 1, URLScan examine uniquement la section AllowVerbs et ignore la section DenyVerbs du fichier .INI.

Si la valeur de UseAllowVerbs est 0, URLScan considère la section DenyVerbs et ignore toute entrée de la section AllowVerbs. IIS est plus sécurisé quand tous les verbes HTTP sont refusés et que seules des exceptions sont indiquées. C'est d'ailleurs le paramètre par défaut pour URLScan (UseAllowVerbs = 1).

Cette fonctionnalité est utile pour limiter les activités des utilisateurs sur votre site Web.

Autorisations autorisées et refusées

Les sections AllowExtensions et DenyExtensions du fichier URLScan.ini fonctionnent comme les sections AllowVerbs et DenyVerbs. Elles contrôlent cependant les extensions de fichier spécifiques auxquelles les demandes entrantes sont autorisées à accéder.

Ce paramètre permet aux administrateurs d'activer l'accès à des types de fichiers Web courants, mais d'empêcher l'exécution de fichiers de script ou exécutables.

La configuration la plus sûre consiste à définir UseAllowExtensions sur 1 et à indiquer les extensions autorisées dans la section AllowExtensions. Elle bloque toutes les autres extensions. Le paramètre par défaut est UseAllowExtensions = 0, qui interdit uniquement les extensions spécifiées.

En-têtes refusés

La section DenyHeaders du fichier permet de spécifier les en-têtes de demandes de clients qu'URLScan va autoriser ou refuser. Par exemple, vous pouvez utiliser cette section pour refuser l'en-tête Translate, lequel permet d'exploiter une vulnérabilité spécifique dans une version d'IIS 5.0 qui n'a pas encore été corrigée.

Implémentation d'URLScan

Vulnérabilité

URLScan résout un trop grand nombre de vulnérabilités pour que nous puissions les aborder en détail dans cette section. Cependant, l'une des plus courantes concerne le parcours de système de fichiers IIS. Dans le scénario Contoso, ce risque a été considéré comme l'un des plus importants auxquels est soumis l'environnement.

Le parcours de système de fichiers peut permettre à un pirate non seulement de visualiser l'organisation du système de fichiers sur un serveur IIS mais aussi de consulter les données contenues dans les fichiers ou d'accéder sans autorisation au serveur. Un pirate pourrait même aller jusqu'à exécuter des commandes à distance sur l'ordinateur.

Contre-mesure

La première contre-mesure destinée à pallier cette vulnérabilité consiste à déplacer les répertoires qui contiennent les racines du serveur virtuel vers un lecteur autre que le lecteur système. Il n'existe pour l'instant aucune méthode connue qui permettrait à un pirate d'effectuer un parcours au-delà des partitions système pour exécuter des commandes. En déplaçant les fichiers de données d'applications Web vers un lecteur qui ne contient aucun exécutable de commandes système, vous empêchez le pirate d'agir.

URLScan peut aussi être implémenté pour limiter les caractères spéciaux autorisés dans les URL demandées. URLScan peut spécifier la normalisation de l'URL avant son traitement, une mesure qui élimine la plupart des exploits de parcours de système de fichiers les plus courants.

Impact potentiel

L'installation des fichiers de données sur des lecteurs non-système n'a aucun impact connu sur les applications Microsoft. Toutefois, il se peut que des applications personnalisées rencontrent des problèmes inattendus si leurs fichiers sont installés ailleurs qu'à leur emplacement par défaut. En outre, la plupart des applications nécessitent une reconfiguration si leurs fichiers sont déplacés après installation.

Toutes les applications doivent être testées en environnement de laboratoire, après l’apport de ces modifications et avant d'implémenter ces dernières sur des serveurs IIS de production.

Scénario Contoso

Dans le scénario Contoso, le répertoire inetpub et tous les répertoires virtuels ont été installés sur des partitions de disque différentes de la partition système. Contoso a aussi implémenté URLScan pour limiter les URL et les exécutables autorisés pour exécution sur le système.

Stratégie de groupe IIS incrémentielle

La stratégie de sécurité de base étudiée au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base », garantit une meilleure sécurisation des serveurs qu'après une installation par défaut. Cependant, comme pour les autres rôles de serveurs, des paramètres supplémentaires sont nécessaires pour ajouter des fonctionnalités tout en renforçant la sécurité d'autres éléments de l'ordinateur.

Services système

Le rôle de serveur IIS ajoute une fonctionnalité de serveur Web à la stratégie de base des serveurs Windows 2000. Quels que soient les autres services hébergés sur un serveur IIS, les deux services ci-dessous doivent être activés pour prendre en charge une quelconque fonctionnalité de serveur Web. Le service IISAdmin est nécessaire non seulement pour administrer les sites Web IIS, mais aussi parce qu'il constitue le point de contact initial pour tout le trafic Web sur un serveur IIS. La désactivation de ce service entraînerait donc la désactivation de tous les sites Web ainsi que de FTP, SMTP et NNTP dans votre environnement. Ces services ont été activés dans la stratégie IIS incrémentielle.

Tableau 7.10. Paramètres de services de la stratégie IIS incrémentielle

Paramètre de service

Type de démarrage

Justification

IISAdmin

Automatique

Administration du serveur Web

W3SVC

Automatique

Fonctionnalités de serveur Web

Configuration manuelle de la sécurité

Outre la stratégie IIS incrémentielle, des mesures de remédiation existent qui exigent une implémentation manuelle. Il s'agit notamment des mesures suivantes :

·         déplacement des répertoires de contenu Web ;

·         déplacement et sécurisation des fichiers journaux ;

·         restriction des autorisations sur la métabase ;

·         désactivation de l'emplacement de contenu dans les réponses HTTP ;

·         désactivation des messages d'erreur ASP détaillés ;

·         suppression des extensions serveur FrontPage 2000 ;

·         suppression des serveurs virtuels supplémentaires ;

·         configuration des filtres IPSec.

Déplacement des répertoires de contenu Web

Vulnérabilité

L'on sait de longue date qu'IIS, dans son installation par défaut, est vulnérable aux attaques de type parcours de répertoires. Un parcours de répertoires se produit quand un pirate dépasse le dossier racine Web et demande ou transmet des fichiers extérieurs aux dossiers Web. Lorsque des applications IIS sont vulnérables à ce type d'attaque, l'installation IIS par défaut permet aux auteurs d'attaques d'accéder à des fichiers et à des dossiers dans la partition système, y compris à de nombreuses commandes système et à de nombreux dossiers qui autorisent l'écriture. Il n'existe pour l'instant aucune méthode qui utiliserait une syntaxe HTTP connue pour demander des fichiers au-delà des partitions système.

Contre-mesure

Pour prévenir les attaques de parcours de répertoires, déplacez le répertoire \inetpub et tous les répertoires virtuels vers une partition de disque différente de la partition système.

Grâce à cette mesure, un pirate ne pourra même pas accéder à des commandes système de base telles que cmd.exe s'il exploite un problème de canonisation inattendu, et il ne pourra écrire sur aucun des répertoires autorisant l'écriture sur la partition système, par exemple \inetpub\Scripts.

Impact potentiel

Minime. L'administrateur du serveur Web doit s'assurer que la configuration d'IIS est enregistrée, pour garantir que les sites virtuels sont réinscrits au nouvel emplacement.

Scénario Contoso

Le site Web Recherche de Contoso a été utilisé pour fournir un exemple. La racine virtuelle du site Web était C:\Inetpub\wwwroot\research sur le serveur Web Recherche. Pour déplacer ses fichiers vers une partition non-système (comme E), la procédure suivante a été exécutée :

Pour déplacer tous les répertoires de contenu du site Web Recherche :
  1. Démarrez le composant logiciel enfichable MMC IIS.
  2. Cliquez avec le bouton droit sur le site Web et choisissez Arrêter. (Cette action déverrouille tous les fichiers.)
  3. Ouvrez une invite de commandes.
  4. Tapez la commande suivante : xcopy c:\inetpub\wwwroot\research d:\wwwroot\research /s /i /o
  5. Retournez au composant logiciel enfichable MMC IIS.

6.       Cliquez avec le bouton droit sur le site Web et choisissez Propriétés.

  1. Cliquez sur l'onglet Répertoire de base, puis cliquez sur le bouton Parcourir et choisissez le nouveau répertoire vers lequel les fichiers viennent d'être copiés (par exemple d:\wwwroot\research).
  2. Cliquez avec le bouton droit sur le site Web et choisissez Démarrer.

Déplacement et sécurisation des fichiers journaux

Vulnérabilité

Si vous déplacez et sécurisez les fichiers journaux IIS, il devient bien plus difficile pour les pirates d'effacer toute trace de leur passage en supprimant ces fichiers journaux ou certaines de leurs entrées individuelles.

Contre-mesure

Déplacez le répertoire des fichiers journaux IIS vers une partition distincte de la partition système et de celle qui contient les fichiers de données du site Web. Définissez ensuite des autorisations NTFS strictes afin d'améliorer la sécurisation des fichiers journaux. Enfin, assurez-vous que les champs de journalisation recommandés sont configurés.

Options de fichier journal supplémentaires :

·         Pour faciliter l'analyse en ligne des fichiers journaux IIS, vous pouvez utiliser un script afin d'automatiser le déplacement sécurisé des fichiers journaux de chaque serveur IIS. Les fichiers journaux doivent être supprimés des serveurs IIS au moins toutes les 24 heures et enregistrés sur un serveur central.

·         Vous pouvez créer un script automatisé qui utilise les protocoles FTP, SMTP, HTTP ou SMB afin de transférer les fichiers journaux d'un ordinateur, mais cette opération doit être sécurisée pour ne pas prêter le flanc à d'autres opportunités d'attaques. Vous pouvez recourir à une stratégie IPSec pour sécuriser les ports et les hôtes autorisés pour ces protocoles.

·         Vous pouvez stocker les fichiers journaux IIS sur CD, en utilisant des graveurs de CD réinscriptibles pour écrire plusieurs fois sur le même support. Vous pourriez ainsi enregistrer vos entrées de journal IIS à un emplacement de stockage impossible à supprimer après écriture. Les auteurs d'attaques ne seront alors plus en mesure de masquer les traces de leur passage.

·         Vous pouvez aussi stocker les fichiers journaux IIS dans un partage UNC (Universal Naming Convention) centralisé (par exemple, le répertoire des fichiers journaux pourrait être \\serveur\partage\iislogs plutôt que %Windir%\system32\logfiles). Cela permettrait de sauvegarder ces fichiers journaux quotidiennement à partir d'un référentiel central.

·         Enfin, vous pouvez enregistrer les entrées de journal IIS dans une base de données ODBC (Open Database Connectivity). Les entrées sont placées dans un emplacement centralisé, sur lequel des autorisations plus granulaires peuvent être définies (par exemple, lecture/écriture, mais pas de suppression). Elles présenteraient ainsi déjà un format idéal pour les analyses.

Impact potentiel

Aucun.

Scénario Contoso

Les fichiers journaux IIS des serveurs Web de Contoso ont été déplacés vers une partition non-système, sur laquelle la journalisation étendue et sécurisée a été activée.

Pour déplacer les fichiers journaux IIS vers une partition non-système
  1. Démarrez le composant logiciel enfichable IIS.
  2. Cliquez avec le bouton droit sur le site Web et choisissez Propriétés.
  3. Dans l'onglet Site Web, cliquez sur le bouton Propriétés dans la section Activer l'enregistrement.
  4. Dans l'onglet Propriétés générales, cliquez sur le bouton Parcourir et sélectionnez le lecteur et le dossier où doivent être enregistrés les fichiers journaux IIS (par exemple, E:\IISLogs).

Remarque : Veillez à avoir préalablement créé le dossier pour pouvoir le sélectionner dans cette procédure.

5.       Cliquez sur OK, puis à nouveau sur OK.

Remarque : Si des fichiers journaux IIS se trouvent déjà à l'emplacement d'origine (%Windir%\System32\logfiles), vous devez les déplacer manuellement vers le nouvel emplacement. IIS ne le fera pas à votre place.

Pour définir les autorisations recommandées sur l'emplacement des fichiers journaux IIS (par exemple, E:\IISLogs)

1.       Ouvrez une invite de commandes.

2.       Tapez la commande suivante : cacls e:\iislogs /t /g administrateurs:F system:F tout le monde:R

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

Pour configurer l'audit des journaux IIS au format étendu du W3C
  1. Démarrez le composant logiciel enfichable MMC IIS.
  2. Cliquez avec le bouton droit sur votre serveur dans le volet gauche et cliquez sur Propriétés.
  3. Vérifiez que le service WWW est sélectionné dans la liste déroulante Propriétés principales, puis cliquez sur le bouton Modifier adjacent.
  4. Sélectionnez Activer l'enregistrement et vérifiez que la liste déroulante Format de journal actif contient la valeur Format de fichier journal étendu du W3C.
  5. Cliquez sur Propriétés.
  6. Activez la case d'option Quand la taille du fichier atteint et spécifiez une taille de 500 Mo.
  7. Modifiez le répertoire du fichier journal par défaut. Il est recommandé d'employer une partition non-système différente de celle de vos sites Web.
  8. Cliquez sur l'onglet Propriétés étendues.
  9. Outre les champs par défaut sélectionnés par IIS, choisissez aussi l'entrée État Win32.
  10. Cliquez sur OK trois fois pour fermer les zones de liste de la boîte de dialogue de propriétés.

Remarque : Un audit de ce type n'empêche pas les attaques système, mais constitue une aide précieuse dans l'identification d'intrus, la détection d'attaques en cours et le diagnostic des traces laissées par les attaques.

Restriction des autorisations sur la métabase

Vulnérabilité

Les paramètres de configuration IIS, entre autres ceux relatifs à la sécurité, sont conservés dans la métabase IIS. Les autorisations de fichier par défaut pourraient permettre à un pirate de modifier directement le fichier de métabase. Il faut renforcer les autorisations NTFS sur le fichier de métabase IIS (et sa copie de sauvegarde) pour s'assurer qu'aucun pirate ne peut modifier la configuration IIS de quelque façon que ce soit. Par exemple, un utilisateur malveillant pourrait essayer de désactiver l'authentification pour un répertoire virtuel donné en modifiant des paramètres de métabase appropriés.

Contre-mesure

Sécurisez les fichiers de métabase pour que les autorisations Contrôle total ne soient octroyées qu'aux comptes Administrateurs et SYSTEM.

Impact potentiel

Le seul impact potentiel est l'instauration d'autorisations trop restrictives sur les fichiers de métabase, ce qui empêcherait le système ou les administrateurs de lire et de mettre à jour le fichier.

Scénario Contoso

La stratégie IIS incrémentielle a été appliquée pour sécuriser les fichiers de métabase, où ont été enregistrées les autorisations appropriées.

Pour renforcer manuellement les autorisations NTFS sur la métabase

1.       Ouvrez une invite de commandes.

2.       Tapez la commande suivante : cacls

%systemroot%\system32\inetsrv\metabase.bin /g administrateurs:F system:F

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

4.       Tapez la commande suivante : cacls %systemroot%\system32\inetsrv\metaback /g administrateurs:F system:F

5.       À l'invite, tapez O pour continuer. Ces paramètres sont inclus dans le modèle de sécurité MSS IIS Role.inf, accompagnant ce guide.

Désactivation de l'emplacement de contenu dans les réponses HTTP

Vulnérabilité

Quand une page HTML statique (c’est-à-dire une page non-ASP) est extraite, un en-tête d'emplacement de contenu est ajouté à la réponse par IIS. Par défaut, cet en-tête de contenu se réfère à l'adresse IP, et pas au nom de domaine complet (FQDN) du site Web actuel. Cela crée une vulnérabilité dans la mesure où votre adresse IP interne est malencontreusement exposée.

Contre-mesure

Masquez l'emplacement de contenu renvoyé par défaut dans les en-têtes de réponses HTTP. Vous pouvez pour ce faire changer la valeur UseHostName dans la métabase IIS afin de modifier le comportement par défaut : l'adresse IP ne sera plus exposée puisque c'est le nom de domaine complet (FQDN) qui sera envoyé.

Impact potentiel

Aucun.

Scénario Contoso

Dans le scénario Contoso, le paramètre UseHostName a été reconfiguré sur la valeur True au moyen du script Adsutil.vbs. La syntaxe requise est la suivante :

cscript Adsutil.vbs set w3svc/UseHostName True

Le script Adsutil.vbs se trouve dans le répertoire des scripts d'administration IIS sur le serveur IIS, par défaut C:\Inetpub\Adminscripts.

Remarque : Pour plus d'informations sur les procédures manuelles qu'implique cette mesure, consultez l'article 218180 de la Base de connaissances, intitulé « Internet Information Server renvoie l'adresse IP dans l'entête HTTP (Emplacement de contenu) ».

Désactivation des messages d'erreur ASP détaillés

Vulnérabilité

Par défaut, IIS envoie des messages d'erreur ASP détaillés au navigateur client chaque fois que des erreurs d'application internes se produisent. Si une telle pratique est très utile pour le débogage d'applications, elle peut exposer les détails internes du fonctionnement de l'application, ce qui donne au pirate une idée plus précise des méthodes possibles pour l'attaquer.

Contre-mesure

Désactivez les messages d'erreur ASP détaillés sur les serveurs IIS de production dans votre environnement.

Impact potentiel

Il peut être plus difficile de résoudre les problèmes des applications Web, car les erreurs consignées par IIS dans le journal des événements Application ne donnent pas autant d'informations que les messages d'erreur ASP détaillés. Si vous rencontrez des erreurs ASP reproductibles, vous avez le choix entre deux solutions : déployer un environnement de développement miroir pour tester des correctifs (et activez dans cet environnement les messages d'erreur ASP détaillés), ou activer temporairement les messages d'erreurs ASP détaillés en production, le temps de résoudre le problème.

Scénario Contoso

Les serveurs IIS de production des départements de recherche et des ressources humaines ont été reconfigurés de manière à désactiver les messages d'erreur ASP détaillés, au moyen des paramètres du script adsutil.vbs détaillés ci-dessous.

Pour désactiver les messages d'erreur ASP détaillés
  1. Démarrez le composant logiciel enfichable MMC Gestionnaire des services Internet.
  2. Cliquez avec le bouton droit sur votre serveur (c’est-à-dire le site principal) dans le volet gauche et cliquez sur Propriétés.
  3. Vérifiez que le service WWW est sélectionné dans la liste déroulante Propriétés principales, puis cliquez sur le bouton Modifier adjacent.
  4. Cliquez sur l'onglet Répertoire de base.
  5. Cliquez sur Configuration.
  6. Sélectionnez l'une des extensions dans la liste, puis cliquez sur Modifier.
  7. Cliquez sur Parcourir et naviguez jusqu'à c:\winnt\system32\inetsrv\404.dll
  8. Cliquez sur Ouvrir, puis sur OK.
  9. Répétez les étapes 6, 7 et 8 pour toutes les extensions de fichier restantes.

Vous pouvez également utiliser pour ce faire le script Adsutil.vbs. La syntaxe requise est la suivante :

cscript Adsutil.vbs set w3svc/AspScriptErrorSentToBrowser False

Suppression des extensions serveur FrontPage 2000

Vulnérabilité

Les extensions serveur FrontPage 2000 fournissent des méthodes pratiques pour établir une collaboration entre équipes d'utilisateurs d'Office et pour manipuler à distance du contenu de pages Web. Ces fonctionnalités de gestion à distance ne sont généralement pas nécessaires pour les sites Web ne comptant qu'un administrateur, et ces extensions peuvent être exploitées par des pirates habiles comme point d'attaque sur des sites Web.

Contre-mesure

Désactivez les extensions serveur FrontPage 2000 sur tous les serveurs IIS de production.

Impact potentiel

Si vous devez déléguer la gestion de certains sites Web virtuels à des personnes qui ne sont pas des administrateurs, vous pouvez avoir besoin des extensions serveur FrontPage 2000. Dans ce cas, veillez à bien déployer tous les correctifs disponibles des extensions serveur FrontPage 2000.

Scénario Contoso

Dans l'environnement Contoso, les sites Web IIS sont tous administrés par de petites équipes de personnel informatique. Les équipes peuvent utiliser le composant logiciel enfichable MMC Gestionnaire des services Internet à la console, via les services Terminal Server, ou via le réseau. Dès lors, les extensions serveur FrontPage 2000 ont été désactivées manuellement sur tous les serveurs IIS de production.

Pour supprimer manuellement les extensions serveur FrontPage 2000
  1. Lancez l'applet Ajout/Suppression de programmes, puis sélectionnez Ajouter/Supprimer des composants Windows.
  2. Sélectionnez Services Internet (IIS) et cliquez sur le bouton Détails.
  3. Désactivez la case à cocher Extensions serveur FrontPage 2000, cliquez sur OK, puis sur Suivant.
  4. Si la boîte de dialogue Installation des services Terminal Server s'affiche, cliquez sur Suivant.

Ou bien, si la boîte de dialogue Fichiers nécessaires s'affiche, cliquez sur Parcourir pour spécifier l'emplacement à partir duquel vous avez installé Windows 2000 à l'origine, et cliquez sur OK.

  1. À l'invite, cliquez sur Terminer.
  2. Si nécessaire, supprimez les répertoires serveur FrontPage, y compris :

·         C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40

·         C:\Inetpub\wwwroot\_private

·         C:\Inetpub\wwwroot\_vti_cnf

·         C:\Inetpub\wwwroot\_vti_log

·         C:\Inetpub\wwwroot\_vti_pvt

·         C:\Inetpub\wwwroot\_vti_script

Suppression des serveurs virtuels supplémentaires

Vulnérabilité

L'installation par défaut d'IIS crée Site FTP par défaut, Site Web par défaut et Site Web d'administration. Ces sites contiennent souvent du code exemple ; ils constituent également un point d'entrée potentiel à des attaques distantes qui nécessitent une instance non sécurisée de ces services. Lorsqu'ils ne sont pas requis pour votre environnement de production, il est conseillé dans le cadre des bonnes pratiques de supprimer ou de désactiver ces sites par défaut.

Contre-mesure

Supprimez le Site FTP par défaut, le Site Web d'administration et empêchez le Site Web par défaut de répondre aux demandes Web.

Impact potentiel

Il se peut que vous ayez installé certaines applications Web dans l'un des sites Web par défaut. Avant de supprimer ces sites, assurez-vous que vous avez migré ces applications sur de nouveaux sites Web sur le serveur Web IIS. Si, pour une raison quelconque, vous ne pouvez pas supprimer ces sites, supprimez au moins le code exemple qui y figure. Utilisez IISLockdown pour ce faire.

Scénario Contoso

Dans l'environnement Contoso, les sites Web par défaut n'étaient pas nécessaires pour prendre en charge des fonctionnalités de production : chacun des sites Web de production ont été installés dans de nouveaux sites Web virtuels. Les sites par défaut ont donc été supprimés ou arrêtés.

Pour supprimer manuellement le Site FTP par défaut
  1. Démarrez le composant logiciel enfichable MMC Gestionnaire des services Internet.
  2. Cliquez avec le bouton droit sur Site FTP par défaut, choisissez Supprimer et cliquez sur Oui.
Pour supprimer manuellement le Site Web d'administration
  1. Démarrez le composant logiciel enfichable Gestionnaire des services Internet.
  2. Cliquez avec le bouton droit sur Site Web d'administration, choisissez Supprimer et cliquez sur Oui.
Pour arrêter manuellement le Site Web par défaut
  1. Démarrez le composant logiciel enfichable Gestionnaire des services Internet.
  2. Cliquez avec le bouton droit sur le Site Web par défaut et choisissez Arrêter.

Autres considérations liées aux paramètres des serveurs IIS

Désactivation du compte IUSR

L'installation IIS par défaut crée un compte Windows, qui sert à représenter les utilisateurs Internet anonymes, appelé IUSR_ORDINATEUR. ORDINATEUR représente ici le nom NetBIOS de votre serveur au moment de l'installation d'IIS. Si vous n'autorisez pas l'accès anonyme à votre site Web, désactivez ce compte pour utilisateurs anonymes.

Vous pouvez accorder un accès anonyme par l'intermédiaire de n'importe quel autre compte ; ce compte-ci n'est en somme que celui qui est créé par défaut lors de l'installation d'IIS. Inversement, la désactivation ou la suppression de ce compte ne supprime pas les possibilités d'accès anonyme d'IIS, car IIS peut être configuré pour utiliser tout autre compte à cette fin.

Ce compte est employé par la majorité des sites Web publics sur lesquels l'accès anonyme au contenu est pris en charge ou sur lesquels l'application effectue sa propre authentification, par exemple par formulaires.

Remarque : Si votre serveur Web héberge plusieurs applications Web, il se peut que vous vouliez utiliser plusieurs comptes anonymes (un par application) afin de sécuriser et d'auditer les opérations de chaque application de manière indépendante.

Audits réguliers de l'appartenance aux groupes

Contrôlez régulièrement les membres des différents groupes d'utilisateur. Cette mesure est particulièrement importante en ce qui concerne les groupes dotés de privilèges, par exemple le groupe Administrateurs. N'affectez à celui-ci que le nombre de membres minimal requis. De plus, formez correctement les utilisateurs (particulièrement les nouvelles recrues) avant de les ajouter au groupe Administrateurs.

Recommandations supplémentaires pour la sécurisation des utilisateurs et des groupes

·         Créez des groupes spécifiques pour des tâches d'administration spécifiques, et cataloguez les membres autorisés de groupes dotés de privilèges, comme Opérateurs de serveur.

·         Surveillez périodiquement l'appartenance aux groupes.

·         Avant d'ajouter une personne au groupe Administrateurs, appliquez des critères d'embauche stricts et faites passer des entretiens pour vous assurer de ses compétences.

Désactivation du paramètre des chemins parents ASP

La configuration de la métabase IIS empêche l'emploi de « .. » (deux points consécutifs) dans les appels d'applications et de scripts à des fonctions telles que MapPath. Cette mesure permet de se protéger contre les attaques potentielles de parcours de répertoires.

Pour désactiver manuellement le paramètre des chemins parents
  1. Cliquez avec le bouton droit sur la racine du site Web à sécuriser, puis cliquez sur Propriétés.
  2. Cliquez sur l'onglet Répertoire de base.
  3. Cliquez sur Configuration.
  4. Cliquez sur l'onglet Options de l'application.
  5. Désactivez la case à cocher Activer les chemins d'accès relatifs au répertoire parent.

Remarque : Si vous utilisez le site d'administration d'Application Center 2002, consultez l'article 288309 de la Base de connaissances, « PRB: Disabling Parent Paths Breaks User Interface » (en anglais).

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 peuvent 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 qui pourraient recevoir des requêtes ou faire l'objet d'attaques.

Tableau 7.11. Carte du trafic réseau IPSec pour les serveurs IIS incrémentiels

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)