Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Chapitre 4 : renforcement de Microsoft Windows NT 4.0
Paru le 22 novembre 2004
Certaines fonctions de sécurité incluses dans les dernières versions du système d'exploitation Microsoft Windows® ne sont pas présentes sur Microsoft Windows NT version 4.0. Ce dernier intègre cependant des fonctions et des techniques extrêmement utiles, qui améliorent considérablement la sécurité de vos systèmes. Ce chapitre couvre ces sujets en détail et explique comment utiliser ces fonctions pour renforcer vos systèmes Windows NT 4.0, qu'il s'agisse de stations de travail ou de serveurs.
Ces rubriques décrivent les procédures à suivre pour effectuer les opérations suivantes :
Installer le système d'exploitation initial et la base de correctifs.
Renforcer la séquence d’amorçage.
Installer le complément Directory Services Client.
Utiliser les stratégies système et le Gestionnaire de configuration de sécurité.
Choisir le niveau d'authentification de Windows NT LAN Manager (NTLM).
Définir des stratégies de mot de passe efficaces.
Utiliser le verrouillage de comptes et de mots de passe.
Renforcer le système de fichiers.
Renforcer les services.
Prendre d'autres mesures de renforcement.
Sur cette page
Conception de la sécurité des hôtes Windows NT
Implémentation
Test de la solution
Résumé
Conception de la sécurité des hôtes Windows NT
Le renforcement du système d'exploitation Windows NT 4.0 nécessite l'évaluation et la maîtrise de plusieurs éléments.
Installation du système d'exploitation initial et de la base de correctifs
La première étape critique dans le renforcement des systèmes basés sur Windows NT consiste à installer le dernier jeu de correctifs de sécurité pour le système d'exploitation de base. Idéalement, vous devriez avoir effectué cette opération dans le cadre du processus de gestion des correctifs normal, décrit dans le chapitre 6, "Gestion des correctifs". Ce processus doit commencer par un inventaire complet visant à déterminer les versions installées sur les différents ordinateurs. Vous pouvez utiliser Microsoft Baseline Security Analyzer (MBSA) ou Microsoft Systems Management Server (SMS) pour analyser les systèmes Windows NT 4.0, localement ou à distance. Après l'inventaire, examinez les résultats pour vous assurer que l'ensemble des mises à jour de base ont été installées sur chaque système Windows NT. Ces mises à jour doivent inclure :
Service Pack 6a (SP6a) pour Windows NT 4.0, le dernier service pack pour Windows NT 4.0 ; il contient un jeu complet de correctifs ayant subi les tests de régression, conçus pour être installés tous ensemble.
SRP (Security Rollup Package) Windows NT 4.0 postérieur au Service Pack 6a. Le SRP intègre plusieurs correctifs qui ont été publiés après la version SP6a initiale et constitue une condition préalable pour les correctifs ultérieurs provenant de Windows Update.
Un jeu de correctifs de sécurité à jour. Microsoft n'a pas publié de SRP intégré ni de service pack pour Windows NT 4.0 depuis la publication du SRP, mais des composants individuels, tels que des portions du système d'exploitation, Microsoft Internet Explorer et des utilitaires complémentaires, tels que le service Routage et accès distant (RRAS) et Internet Information Services (IIS), ont été mis à jour. Vous pouvez obtenir une liste à jour des correctifs auprès de Microsoft TechNet ou passer en revue manuellement la liste des correctifs disponibles par l'intermédiaire de Windows Update.
Une version à jour d'Internet Explorer La version courante est Internet Explorer 6.0 Service Pack 1 (SP1) ; elle intègre des centaines de correctifs de sécurité et d'améliorations publiés depuis les versions d'Internet Explorer distribuées avec les différentes versions de Windows NT. Suivant votre environnement, vous pouvez, au choix, télécharger Internet Explorer directement sur le site Web Microsoft, le commander sur CD – ROM ou l'installer sur plusieurs ordinateurs à l'aide du Kit d'Administration Internet Explorer (IEAK).
Renforcement de la séquence d'amorçage
Une fois qu'un jeu de correctifs minimum correct et complet est installé, vous devez augmenter le niveau de protection disponible pour le système au démarrage. Cette protection se présente sous deux formes : mise à zéro du délai du menu de démarrage pour compliquer la tâche d'un pirate qui essaie de démarrer à partir d'un autre système d'exploitation et utilisation de l'utilitaire Syskey intégré pour crypter les informations stockées dans la base de données du Gestionnaire de comptes de sécurité (SAM).
Windows NT Server stocke les informations des comptes utilisateur, y compris des dérivés des mots de passe, dans une portion sécurisée du Registre, protégée par le contrôle d'accès et par une fonction d'obscurcissement. Les informations des comptes dans le Registre ne sont accessibles qu'aux membres du groupe Administrateurs. Windows NT Server, à l'instar des autres systèmes d'exploitation, permet aux administrateurs d'accéder à toutes les ressources du système. Pour les installations qui souhaitent renforcer la sécurité, un cryptage fort des dérivés des mots de passe des comptes offre un niveau de sécurité supplémentaire pour empêcher les administrateurs d'accéder intentionnellement ou involontairement à ces informations avec les interfaces de programmation du Registre. Syskey protège également les données SAM contre différents types d'attaques hors connexion consistant à démarrer à partir d'un autre système d'exploitation et à accéder aux fichiers SAM.
Syskey génère une clé de cryptage aléatoire utilisée pour crypter les données SAM. Une fois que les données SAM ont été cryptées, la clé doit être chargée au démarrage et utilisée pour décrypter la copie des données SAM en mémoire. Il existe trois modes de fonctionnement pour Syskey, comme indiqué dans la Figure 4.1 :
En mode 1 (Enregistre la clé de démarrage localement), la clé de cryptage est "super" cryptée et stockée sur l'ordinateur local. Au moment du démarrage, la clé est décryptée et chargée, ce qui permet à l'ordinateur de redémarrer dans intervention de l'administrateur.
En mode 2 (bouton Mot de passe de démarrage et champs texte associés), la clé de cryptage est "super" cryptée avec une expression de passe spécifiée par l'administrateur. Au moment du démarrage, l'administrateur doit saisir l'expression de passe sur la console pour terminer l'opération. Le système ne démarrera pas tant que l'expression de passe n'aura pas été saisie.
En mode 3 (bouton Enregistre la clé de démarrage sur disquette), la clé aléatoire Syskey est stockée sur une disquette, qui doit être insérée suite à une invite pendant le cycle de démarrage. Cette disquette doit être conservée en lieu sûr.
.gif)
Figure 4.1 Boîte de dialogue de sélection du mode de Syskey
Trey a choisi de mettre en œuvre la protection Syskey sur tous ses ordinateurs exécutant Windows NT. (Syskey est déjà activée par défaut dans Windows 2000, Microsoft Windows Server™ 2003 et Windows XP.). La plupart des serveurs de Trey et toutes ses stations de travail sont configurés pour utiliser le mode 1 de Syskey ; Trey a choisi ce mode pour l'utilisation générale, car il constitue un compromis raisonnable entre la sécurité et la commodité. Pour les serveurs à haute valeur, Trey utilise le mode 2, bien qu'il nécessite la présence physique d'un administrateur pour saisir le mot de passe sur l'ordinateur à chaque redémarrage. Étant donné la nécessité de conserver une disquette de démarrage pour chaque ordinateur protégé, Trey a choisi de n'utiliser le mode 3 sur aucun de ses systèmes.
Installation du complément Directory Services Client
Les systèmes Windows NT 4.0 peuvent seulement participer pleinement aux domaines Windows NT ; s'il existe des domaines de services d'annuaire Microsoft Active Directory®, Windows 98 et Windows NT ne peuvent y participer de manière native que par le biais de l'interface NetBIOS (network basic input/output system). Windows 2000 et Windows Server 2003 assurent la compatibilité NetBIOS en émulant un contrôleur de domaine principal (PDC) Windows NT. Bien qu'Active Directory fournisse des approbations bidirectionnelles transitives, les systèmes Windows NT 4.0 ne peuvent bénéficier que des approbations unidirectionnelles explicites, qu'ils utilisent un contrôleur de domaine Active Directory ou un contrôleur secondaire de domaine (BDC) Windows NT.
Au lieu de gérer des domaines de style Windows NT, les ordinateurs exécutant Windows NT et Windows 98 peuvent participer à des domaines Active Directory en ajoutant le complément Directory Service Client (DSClient). DSClient permet à ces systèmes de participer à des domaines Active Directory. Avec un tel logiciel, ces systèmes ont accès à de nombreuses fonctions d'Active Directory ; ils peuvent, par exemple, utiliser des relations d'approbation transitives au sein de la forêt. Les relations d'approbation transitives permettent à des utilisateurs autorisés d'accéder aux ressources appropriées dans n'importe quel domaine de la forêt. La mise à jour DSClient 2003 s'exécute sur Windows NT 4.0 avec SP6a et Internet Explorer 6 SP1 ; la version de DSClient fournie avec Windows 2000 requiert également SP6, mais elle peut utiliser Internet Explorer 4.01 ou une version ultérieure. (Les conditions requises pour utiliser DSClient avec Windows 98 sont décrites dans le chapitre 5, "Renforcement de Microsoft Windows 98".)
Une fois installé, DSClient n'offre pas la prise en charge de toutes les fonctions d'Active Directory ; en particulier, il ne prend pas en charge l'authentification Kerberos, la mise en œuvre de la stratégie de groupe ni l'utilisation des noms de service ou d'utilisateur principaux (UPN) pour l'authentification. Il permet cependant de prendre en charge les fonctions d'Active Directory suivantes :
ADSI (Active Directory Service Interfaces). ADSI fournit une API de programmation commune pour les scripts et les programmes qui prennent en charge Active Directory. Avec ADSI, il est possible de générer des scripts pour de nombreuses opérations d'annuaire qui, autrement, ne seraient pas "scriptables" sous Windows NT.
Client de tolérance de pannes du système de fichiers distribués (DFS) Les partages de fichiers à tolérance de pannes et à basculement du système de fichiers distribués (DFS) fournissent des ressources de partages de fichiers distribués intégrées à Active Directory.
Page de propriétés du carnet d'adresses Windows (WAB) Active Directory. Les pages objet utilisateur, accessibles par le biais du menu Rechercher, permettent aux utilisateurs autorisés de mettre à jour les propriétés (adresses, numéros de téléphone, etc.) des objets utilisateur.
Authentification NTLM version 2. NTLM offre des fonctions d'authentification améliorées et fournit le meilleur niveau de sécurité d'authentification, mis à part Kerberos.
Connaissance des sites. Les systèmes utilisant DSClient ont connaissance des sites Active Directory et utiliseront un contrôleur de domaine sur leur site local, même pour les opérations de changement de mot de passe, si le système de noms de domaine (DNS, Domain Name System) est bien configuré et les sites correctement enregistrés dans Active Directory. Pour plus d'informations sur la façon dont DSClient influe sur l'ouverture de session et le changement de mot de passe, reportez-vous à l'article de la Base de connaissances 249841, "How Windows 98 Active Directory Client Extension uses Active Directory site information", à l'adresse http://support.microsoft.com/kb/249841.
Recherche d'objets dans Active Directory. Les utilisateurs peuvent rechercher des imprimantes et des utilisateurs dans Active Directory à partir du menu Rechercher.
Dépendance réduite par rapport au contrôleur principal de domaine (PDC). Les clients peuvent se connecter à n'importe quel contrôleur de domaine dans le domaine pour les changements de mot de passe.
Utilisation des stratégies système et du Gestionnaire de configuration de sécurité
Les stratégies système sont une mesure de gestion de la configuration spécifique qui est apparue pour la première fois dans Windows 95 et Windows NT 4.0. Ils n'améliorent pas directement la sécurité du système, mais ils vous permettent de limiter l'accès à des ressources spécifiées d'une façon qui renforce vos autres mesures de sécurité, réduisant la probabilité que des utilisateurs puissent contourner vos stratégies et vos restrictions, délibérément ou par ignorance. Lorsque ces stratégies sont conçues et appliquées correctement, elles contribue de façon déterminante à assurer l'intégrité de vos anciens systèmes. En fait, elles sont si utiles que Microsoft les a fait évoluer pour la fonctionnalité Objet de stratégie de groupe (GPO) dans Windows 2000 et les versions ultérieures.
Une stratégie système est un ensemble constitué d'une ou de plusieurs restrictions appliquées aux ruches du Registre HKEY_CURRENT_USER et HKEY_LOCAL_MACHINE. Lorsque l'utilisateur ouvre une session sur un ordinateur, une série de stratégies successives sont recherchées et appliquées (si elles sont trouvées), en fonction du nom de l'utilisateur, des appartenances au groupe global dans le domaine et des stratégies spécifiques à l'ordinateur. Les stratégies système sont destinées à être utilisées dans une implémentation de domaine Windows NT, en complément d'autres fonctionnalités compatibles avec les domaines, notamment les profils utilisateur.
Il est important de comprendre la différence entre les stratégies système et les profils utilisateur. Les profils utilisateur sont la collection de répertoires de configuration, de fichiers, de raccourcis et de ruches du Registre spécifiques à l'utilisateur chargés sous HKEY_CURRENT_USER (Ntuser.dat for Windows NT, User.dat pour Windows 98) ; ils contrôlent l'aspect du bureau, les favoris du navigateur, les signets, ainsi que d'autres options configurables par l'utilisateur dans le système d'exploitation et les applications. Inversement, les stratégies système sont un ensemble d'entrées du Registre supplémentaires qui sont appliquées à l'ordinateur une fois que le profil utilisateur a été localisé et chargé ; elles spécifient des fonctions particulières du système d'exploitation auxquelles l'utilisateur actuel ne doit pas avoir accès.
Utilisation de stratégies système
Microsoft propose un livre blanc, "Guide to Microsoft Windows NT 4.0 Profiles and Policies", qui décrit en détail les profils utilisateur et les stratégies système, leur utilisation et la façon dont ils peuvent être combinés (pour connaître l'emplacement des livres blancs, reportez-vous à la section "Informations complémentaires").
Les stratégies système fournissent de nombreux dispositifs permettant de contrôler les anciennes versions du bureau et de l'interface utilisateur. Si vous connaissez les stratégies de groupe dans Windows 2000, vous connaîtrez également les fonctions de base des stratégies système. En général, cependant, elles vous permettent d'effectuer les opérations suivantes :
Spécifier une bannière ou une clause qui sera affichée avant que les utilisateurs ne soient autorisés à se connecter, par exemple, pour leur rappeler les règles d'utilisation en vigueur sur le plan légal.
Empêcher la boîte de dialogue d'ouverture de session d'afficher des informations importantes liées à la sécurité, par exemple, le nom du précédent utilisateur ou le bouton d'arrêt.
Spécifier le comportement des scripts d'ouverture de session, des profils itinérants mis en cache, de la détection d'un réseau lent, de la bannière de démarrage et des astuces (Welcome Tips).
Spécifier l'emplacement de différents dossiers partagés dans le menu Démarrer, notamment du dossier de démarrage, pour vous assurer que des applications particulières sont toujours lancées lors de l'ouverture d'une session.
Limiter l'aspect du bureau : arrière-plans, icônes, couleurs et commandes disponibles dans le menu Démarrer.
Spécifier le comportement de diverses fonctionnalités liées au système de fichiers, telles que les extensions d'environnement, les mises à jour des temps d'accès aux fichiers en lecture seule et les noms de fichiers longs.
Limiter l'accès aux ressources réseau, les lettres de lecteur disponibles et la possibilité de mapper les lecteurs dans l'Explorateur Windows. Pour plus d'informations, reportez-vous à l'article de la Base de connaissances 156698, "Disabling Access to Network Resources Using System Policies", à l'adresse http://support.microsoft.com/kb/156698.
Limiter la création de partages de fichiers cachés.
Spécifier et limiter les paramètres d'imprimante, SNMP (Simple Network Management Protocol) et RRAS.
Limiter la capacité du shell à lancer des exécutables particuliers.
Limiter la possibilité de lancer les éditeurs du Registre et l'invite de commande.
Les stratégies système présentent de nombreuses similitudes avec les stratégies de groupe, mais il existe certaines limites et certaines différences dont vous devez tenir compte :
Les stratégies système ne sont pas hiérarchiques. Étant donné la nature du modèle de domaine Windows NT, vous ne disposez pas de la même souplesse pour définir des stratégies système complémentaires qui se recoupent qu'avec les stratégies de groupe dans Active Directory. Vous pouvez définir des stratégies pour des utilisateurs individuels, des utilisateurs par défaut, des groupes, des ordinateurs individuels et des ordinateurs par défaut. La méthode employée pour les appliquer est décrite dans l'une des sections suivantes de ce chapitre.
Les stratégies système effectuent leurs modifications directement dans la ruche du registre appropriée. Elles restent en vigueur jusqu'à ce qu'un élément, par exemple, une autre stratégie, entraîne leur changement. Les stratégies de groupe dans Active Directory effectuent leurs modifications dans une partie spéciale du Registre, que Windows utilise ensuite pour remplacer les entrées de Registre normales. Cette méthode consistant à écrire directement dans le Registre (dite "tatouage du Registre") empêche les stratégies système d'effectuer des suppositions sur l'état d'un paramètre géré.
Les stratégies système sont créées à l'aide de l'utilitaire Éditeur de stratégie système et de fichiers de modèles d’administration (.adm). Ces fichiers de modèles fournissent les catégories et sous-catégories de l'Éditeur de stratégie système, les clés et valeurs du Registre qui contrôlent les différents paramètres, ainsi que les options, restrictions et valeurs par défaut applicables. Vous pouvez créer vos propres fichiers de modèles personnalisés et ajouter des paramètres de Registre spécifiques qui ne sont pas couverts par les modèles par défaut fournis avec l'Éditeur de stratégie système.
Après avoir exécuté l'Éditeur de stratégie système et créé un groupe de paramètres qui seront ensuite associés à un utilisateur, un groupe, un ordinateur, un utilisateur par défaut ou un ordinateur par défaut, vous disposerez d'un fichier de stratégie nommé Ntconfig.pol. Par défaut, les ordinateurs exécutant Windows NT sont configurés pour télécharger les fichiers de stratégie appropriés à partir du partage NETLOGON sur les contrôleurs de domaine. Les fichiers de stratégie doivent être placés dans ce partage sur le contrôleur principal de domaine (PDC, Primary Domain Controller) ; le contenu de ce partage est ensuite répliqué sur les contrôleurs secondaires de domaine (BDC, Backup Domain Controller) par le biais du service de réplication d'annuaire (DRS, Directory Replicator Service). Les ordinateurs exécutant Windows NT peuvent télécharger toutes les stratégies applicables à partir du contrôleur de domaine qu'ils utilisent pour l'ouverture de session. Ces comportements sont les mêmes, que les contrôleurs de domaine soient Windows NT, Windows 2000 ou Windows Server 2003, car les clients Windows 2000, Windows XP et Windows Server 2003 ignoreront les fichiers de stratégie dans le partage NETLOGON et préféreront les objets de stratégie de groupe (GPO) intégrés à Active Directory.
Les stratégies système sont chargées et appliquées sur Windows NT de la façon suivante :
S'il existe une stratégie spécifique à l'utilisateur, elle est chargée, le Registre est modifié et le traitement de la stratégie passe à l'étape 4.
Si la stratégie Utilisateur par défaut existe, elle est chargée et appliquée.
S'il existe des stratégies de groupe, elles sont chargées et appliquées par ordre croissant de priorité. Si une stratégie de groupe est en conflit avec la stratégie Utilisateur par défaut, elle sera prioritaire, sauf si le paramètre stratégie de groupe est réglé sur "ignorer".
S'il existe une stratégie spécifique à l'ordinateur, elle est chargée, le Registre est modifié et le traitement de la stratégie passe à l'étape 6.
S'il existe une stratégie Ordinateur par défaut, elle est chargée et appliquée.
L'application des stratégies est terminée.
Par défaut, Windows NT est configuré pour télécharger et appliquer des stratégies système. Ce comportement est décrit dans l'article de la Base de connaissances 168231, "System Policies Are Not Applied in Windows NT", à l'adresse http://support.microsoft.com/kb/168231, et il est contrôlé par la valeur du Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet \Control\Update\UpdateMode (REG_DWORD)
Une valeur égale à 0 désactive l'application des stratégies système.
La valeur par défaut, 1, active le mode Automatique. Windows recherchera le fichier de stratégie système Ntconfig.pol sur le contrôleur de domaine qui s'authentifie, comme décrit préalablement.
Une valeur de 2 active le mode Manuel. Windows examinera la valeur NetworkPath (REG_SZ) (dans la même clé) et essaiera de trouver le fichier de stratégie situé à cet emplacement.
Il est important de vérifier le bon fonctionnement des stratégies système. L'article de la Base de connaissances 154120, "Debugging User Profiles and System Policies in Windows NT 4.0", à l'adresse http://support.microsoft.com/kb/154120, décrit le remplacement du fichier userenv.dll par la version vérifiée, ce qui vous permet de créer un fichier journal dont vous pouvez vous servir pour déboguer l'application des stratégies. Cette procédure convient pour toutes les versions et tous les niveaux de service pack de Windows NT 4.0, y compris l'édition Terminal Server.
Bien que le comportement par défaut des stratégies système dépende d'une infrastructure de domaine Windows NT fonctionnelle, les ordinateurs exécutant Windows 2000, les ordinateurs autonomes exécutant Windows NT et les utilisateurs dans la base de données des comptes locaux pourront encore bénéficier des stratégies système. L'article de la Base de connaissances 168579, "How to Set Up Locally-Based System Policies", à l'adresse http://support.microsoft.com/kb/168579, fournit des indications spécifiques sur deux méthodes permettant de configurer un système Windows NT de telle sorte qu'il puisse fournir des stratégies système pour les utilisateurs dans la base de données des comptes locaux. Si vous utilisez des ordinateurs exécutant Windows 2000, Windows XP ou Windows Server 2003 sur un domaine Windows NT, l'article de la Base de connaissances 274478, "Group Policies for Windows 2000 Professional Clients in Windows NT 4.0 Domain or Workgroups", à l'adresse http://support.microsoft.com/kb/274478, décrit le processus requis pour autoriser la distribution des stratégies compatibles avec Windows 2000 par des contrôleurs de domaine Windows NT.
Planification des considérations pour le déploiement des stratégies système
Pour assurer un niveau de sécurité optimal, ne perdez pas de vue les complications suivantes qui peuvent survenir avec les stratégies système lors de leur développement et de leur déploiement :
En raison de différents bogues liés à l'implémentation des stratégies système dans Windows NT 4.0, vous devez installer au minimum SP3 pour vous assurer que tous les correctifs importants relatifs aux stratégies système ont été appliqués à vos systèmes. En général, cela ne pose pas de problème, sauf si vous avez des besoins spécifiques pour les applications prises en charge, car les autres conditions de sécurité exigent pratiquement que SP6a soit installé sur tous vos systèmes Windows NT.
Deux ouvertures et fermetures de session peuvent s'avérer nécessaires pour s'assurer que les stratégies système sont localisées, téléchargées et appliquées.
Dans la mesure où les stratégies ne sont pas supprimées automatiquement d'un ordinateur, vous devez créer une stratégie de groupe spécifique pour vos comptes administrateur. Cette stratégie doit être définie de façon à supprimer au moins les restrictions qui pourraient empêcher les administrateurs de s'octroyer de nouveau les droits d'accès aux fonctions dont ils peuvent avoir besoin ; une stratégie de groupe Administrateur courante consiste simplement à restaurer toutes les fonctions restreintes.
Lisez attentivement les différents paramétrages de vos stratégies et veillez à analyser correctement les doubles négations potentielles. Certains paramètres devront être activés pour désactiver le comportement spécifié.
Vérifiez de nouveau l'emplacement des fichiers de vos stratégies système. Ils doivent se trouver dans votre partage NETLOGON, dont l'emplacement varie selon que le contrôleur principal de domaine exécute Windows NT 4.0, Windows 2000 ou Windows Server 2003.
Il est important de vérifier que votre service de réplication d'annuaire fonctionne correctement et que le contenu du partage NETLOGON sur le contrôleur principal de domaine (PDC) est bien copié sur tous les contrôleurs secondaires de domaine (BDC).
Assurez-vous que l'heure de modification de vos fichiers de stratégie est mise à jour chaque fois que vous modifiez et déployez une nouvelle stratégie. Certains clients équipés d'anciens service packs mettront les fichiers de stratégie en cache et utiliseront l'heure de modification comme indicateur pour actualiser un fichier. Ou encore mieux : veillez à installer au moins SP3 et, de préférence, SP6a sur tous vos ordinateurs exécutant Windows NT.
Si vous possédez à la fois des contrôleurs de domaine Windows NT 4.0 et Windows 2000 ou Windows Server 2003, il est possible de mettre en place un processus de réplication pour créer un pont entre le service de réplication d'annuaire de Windows NT et le service de réplication de fichiers de Windows 2000. Pour plus d'informations sur ce processus, reportez-vous à l'article de la Base de connaissances 317368, "HOW TO: Use Lbridge.cmd to Replicate System Policies Between Windows 2000 and Windows NT 4.0 Domain Controllers", à l'adresse http://support.microsoft.com/kb/317368.
Windows NT 4.0 Édition Terminal Server pose un ensemble de problèmes intéressants relatifs à l'utilisation des stratégies système. Pour plus d'informations, reportez-vous à l'article de la Base de connaissances 192794, "How to apply System Policy settings to Terminal Server" à l'adresse http://support.microsoft.com/kb/192794.
Il n'est pas inutile de le répéter : les stratégies système ne sauraient remplacer complètement une application correcte des listes de contrôle d'accès (ACL) du Registre et du système de fichiers ; elle ne vous permettront pas non plus de faire l'impasse sur les autres mesures de renforcement du système. Considérez, par exemple, un système avec une stratégie système qui autorise l'utilisateur uniquement à exécuter les binaires des applications Microsoft Office. L'utilisateur pourrait utiliser le menu Fichier Office standard pour créer de nouveaux dossiers, copier des exécutables tels que cmd.exe ou l'un des éditeurs de Registre à des emplacements accessibles en écriture, et les renommer avec des noms d'exécutables autorisés par la stratégie système ; cela lui permettrait de contourner la stratégie.
Il existe des zones de vulnérabilité spécifiques que vous devez considérer lorsque vous déployez des stratégies système, afin de compléter ces dernières par d'autres mesures de sécurité :
Tous les exécutables restreints dans les stratégies système doivent être spécifiés avec leur nom d'accès complet et ne doivent pas s'appuyer sur le chemin de recherche par défaut.
Songez à restreindre l'utilisation des menus Outils et Affichage dans Windows Explorer. Ces menus contiennent de nombreuses options permettant de surmonter les restrictions des stratégies.
Les fichiers du Registre (.reg) peuvent normalement être exécutés, y compris si l'accès à RegEdt32 et RegEdit a été supprimé, car l'association de l'extension de nom de fichier est toujours en place.
Le chemin de recherche par défaut ne doit jamais inclure un répertoire accessible en écriture aux utilisateurs, tel que leur répertoire temporaire et leur répertoire de profils.
Les autorisations associées à l'identificateur de sécurité (SID) World dans le Registre sont excessives. Envisagez sérieusement de limiter ces autorisations aux opérations d'interrogation, d'énumération et de lecture ; cela peut cependant interrompre des applications anciennes et nécessiter des tests complets visant à déterminer les autorisations spécifiques qui doivent être appliquer pour conserver telle fonctionnalité.
Tous les exécutables dans les répertoires système doivent être examinés avec soin. Même si vous supprimez l'autorisation Exécution de ces fichiers, un utilisateur muni d'une autorisation Lecture pourra les copier dans un emplacement accessible en écriture et essayer de les exécuter depuis cet emplacement.
Gestionnaire de configuration de sécurité.
Le Gestionnaire de configuration de sécurité (SCM) a été conçu initialement pour Windows 2000, mais Microsoft a fait en sorte qu'il soit accessible dans Windows NT 4.0 SP4 et les versions ultérieures. Il est disponible sur le CD-ROM SP6a ; vous pouvez également le télécharger sur le site FTP de Microsoft. Le principal outil du Gestionnaire de configuration de sécurité est l'Éditeur de configuration de sécurité (SCE), qui permet de créer et de gérer les modèles de sécurité et les stratégies système.
Vous pouvez vous servir du Gestionnaire de configuration de sécurité pour exécuter différentes tâches utiles. Par exemple, vous pouvez effectuer les opérations suivantes :
Créer des modèles de sécurité qui spécifient les paramètres relatifs aux audits, aux droits de l'utilisateur et à la sécurité pour les ordinateurs exécutant Windows NT.
Appliquer automatiquement des modèles à un ou plusieurs ordinateurs dans un domaine.
Analyser un ou plusieurs ordinateurs pour évaluer leurs niveaux de conformité à un modèle particulier.
Par défaut, l'installation de l’Éditeur de configuration (SCE) ajoute un ensemble de modèles dans le dossier %winnt%\security\templates. Chaque modèle est destiné à un environnement de sécurité et un type d'ordinateur particuliers :
Les modèles de base (Basic*4.inf) appliquent un niveau de sécurité standard à des ordinateurs cibles, notamment une limite d'âge de six semaines pour les mots de passe et un ensemble d'autorisations de base pour les clés du Registre, le système de fichiers et les droits de l'utilisateur.
Les modèles compatibles (Comp*4.inf) appliquent une sécurité plus forte que les modèles de base. Les paramètres de sécurité susceptibles d'interférer avec les clients ou les applications plus anciens restent cependant désactivés ; l'objectif de ce jeu de modèles est d'élever le niveau de sécurité sans générer des problèmes de compatibilité des applications.
Les modèles haute sécurité (HiSec*.inf) appliquent des stratégies de sécurité supplémentaires, notamment en augmentant la longueur minimale des mots de passe, qui passe de 7 à 8 caractères, et en utilisant un ensemble d'autorisations plus restrictives pour le système de fichiers et le Registre. Ces modèles peuvent générer des problèmes avec les anciennes applications qui dépendent des autorisations du système de fichiers ou du Registre, ou des attributions des droits de l'utilisateur.
Les modèles sûrs (Secur*.inf) sont les modèles standard les mieux protégés, mais ils activent des fonctions, notamment la signature SMB (Server Message Block), qui limitent l'interopérabilité entre les ordinateurs sécurisés et les clients Windows 95/98 qui ne sont pas configurés de la même façon.
Tableau 4.1 : Modèles prédéfinis livrés avec la boîte à outils de l'Éditeur de configuration de sécurité Windows NT (Windows NT SCE Toolset)
| Si vous souhaitez | Pour sécuriser | Utilisez |
|---|---|---|
| Sécurité de base | Contrôleurs principal/secondaire de domaine | BasicDC4.inf |
| Serveurs membres | BasicSv4.inf | |
| Stations de travail | BasicWk4.inf | |
| Sécurité améliorée avec bonne compatibilité des applications | Contrôleurs principal/secondaire de domaine | CompDC4.inf |
| Serveurs membres | CompDC4.inf | |
| Stations de travail | CompWS4.inf | |
| Haute sécurité avec compatibilité des applications réduite | Serveur membre ou contrôleur de domaine | HiSecDC4.inf |
| Station de travail | HiSecWS4.inf | |
| Haute sécurité avec connectivité Windows 98 réduite | Serveur membre ou contrôleur de domaine | SecurDC4.inf |
| Description | Étapes du test | Résultat escompté |
|---|---|---|
| Valider l'installation de Microsoft Internet Explorer 6 SP1 | Démarrez Internet Explorer. Dans le menu ? (Aide), cliquez sur À propos de Internet Explorer. | Les informations de version doivent indiquer 6.0.2800.xxxx. |
| Valider l'installation de Windows NT 4.0 (SP6a) | Exécutez l'applet Diagnostics de Windows NT dans le groupe Outils d'administration, puis sélectionnez l'onglet Version. | Les informations de version doivent indiquer SP6a. |
| Valider la séquence d'amorçage | En mode 1 (enregistrer la clé de démarrage localement pour la plupart des serveurs de Trey et toutes ses stations de travail). Au moment du démarrage, la clé est décryptée et chargée, ce qui permet à l'ordinateur de redémarrer dans intervention de l'administrateur. En mode 2 (bouton Mot de passe de démarrage et champs texte associés - pour les serveurs à valeur élevée). Au moment du démarrage, l'administrateur doit saisir l'expression de passe sur la console pour terminer l'opération. | Le client parvient à ouvrir une session. |
| S'assurer que DSClient a été correctement installé | Cliquez sur Démarrer, puis sur Rechercher et sur Des personnes. | La possibilité d'effectuer des recherches dans Active Directory indique que DSClient a été installé correctement. |
| Valider les stratégies système | Essayez d'accéder à des ressources dont l'accès est limité par les stratégies système. Revérifiez l'emplacement des stratégies système, qui se trouvent généralement dans le dossier C:\Winnt\system32\repl\import\scripts. | Vous n'avez pas accès aux ressources protégées. Des stratégies système doivent être disponibles à l'emplacement donné. |
| Valider l'authentification NTLMv2 | Configurez le contrôleur de domaine pour qu'il exige l'authentification NTLMv2. | Le client parvient à ouvrir une session. |
| Valider le Gestionnaire de configuration de sécurité. | Créez et appliquez automatiquement des modèles à un ou plusieurs ordinateurs dans un domaine. Vérifiez l'ensemble de modèles dans le dossier %winnt%\security\templates. | Vous êtes en mesure de sécuriser les serveurs et les stations de travail membres. Des modèles doivent être disponibles à l'emplacement donné. |
| Vérifier la création des noms de fichiers longs | Créez un nouveau fichier avec un nom dont la longueur dépasse le format 8.3. | Vous n'avez pas accès au fichier avec le format 8.3. |
| Valider la fonctionnalité d'exécution automatique (autorun) | Insérez les disques avec autorun dans les lecteurs de l'ordinateur. | L'exécution automatique ne fonctionne plus lorsque des disques avec autorun sont insérés dans l'ordinateur. |
| Valider le fait que les sous-systèmes OS/2 et POSIX ne fonctionneront plus | Si un utilisateur démarre un processus, puis se déconnecte, il existe un risque que le prochain utilisateur à se connecter ait accès à ce processus. | Les applications reposant sur les sous-systèmes OS/2 et POSIX ne fonctionneront plus. |
| Valider les niveaux de protection des objets | Des utilisateurs malveillants essaient de changer les attributs des objets noyau dans différentes conditions. | Le système ne doit pas autoriser les utilisateurs malveillants à d'élever leurs privilèges. |
| Empêcher les utilisateurs d'ajouter des pilotes d'imprimante | Des utilisateurs malveillants essaient d'élever leurs privilèges en ajoutant des pilotes d'imprimante. | Les membres des groupes Opérateurs d'impression et Administrateur peuvent ajouter de nouveaux pilotes d'impression. |
| Valider la désactivation de l'ouverture de session administrateur automatique est désactivée | Essayez d'ouvrir automatiquement une session en tant qu'Administrateur au redémarrage de l'ordinateur. | L'ouverture de session administrateur automatique doit être désactivée |
| Valider le délai d'amorçage | Redémarrez et vérifiez le délai d'amorçage. | Le délai d'amorçage doit être passé de 30 à 0. |
| Valider l'installation du Gestionnaire de configuration de sécurité (SCM) | Cliquez sur Démarrer, Exécuter, tapez mmc, puis appuyez sur ENTRÉE. | La console de gestion SCM Microsoft doit être disponible. |