Ipsec
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Ipsec as PDF for free.
More details
- Words: 110,576
- Pages: 230
Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe Présentation Paru le 17/03/2005 Microsoft a parfaitement conscience que la sécurisation des réseaux constitue pour les grandes entreprises un défi de plus en plus complexe. Au fur et à mesure que les entreprises se développent et que les relations commerciales évoluent, le contrôle de l'accès physique à un réseau relève presque d'une mission impossible. Vos clients, fournisseurs et consultants peuvent avoir besoin, pour des raisons commerciales valables, de connecter leurs périphériques mobiles à votre réseau. L'apparition des technologies de réseau et de connexion sans fil a simplifié plus que jamais l'accès réseau. Cette connectivité améliorée signifie que les membres d'un réseau interne sont de plus en plus exposés aux risques non négligeables que constituent les autres ordinateurs de ce réseau interne, sans compter les brèches éventuelles dans le périmètre de sécurité. Le concept d'isolation logique présenté dans ce guide englobe deux solutions : l'isolation de serveurs, pour qu'un serveur accepte uniquement les connexions réseau des membres du domaine approuvés ou d'un groupe spécifique de membres du domaine, et l'isolation de domaines, pour isoler les membres du domaine des connexions non approuvées. Ces solutions peuvent être utilisées séparément ou ensemble, dans le cadre d'une solution d'isolation logique globale. L'isolation de serveurs et de domaines permet aux administrateurs du système informatique de restreindre les communications TCP/IP des membres du domaine identifiés comme ordinateurs approuvés. Les ordinateurs approuvés peuvent être configurés pour autoriser uniquement les connexions entrantes des autres ordinateurs approuvés ou d'un groupe spécifique d'ordinateurs approuvés. Pour contrôler les droits de connexion réseau, les contrôles d'accès sont gérés de façon centralisée par les stratégies de groupes de Microsoft® Active Directory®. La plupart des connexions TCP/IP peuvent être sécurisées sans avoir à modifier les applications. En effet, IPSec fonctionne au niveau de la couche réseau située sous la couche des applications, pour assurer une authentification et une sécurité par paquet, de bout en bout entre les ordinateurs. Le trafic réseau peut être authentifié, ou authentifié et chiffré, dans divers scénarios personnalisables.
Avantages métier Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, les suivants : •Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les ordinateurs gérés du réseau.
•Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise en œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à l'ensemble des ressources du réseau. •Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution d'isolation physique. •Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au système d'informations d'une entreprise, tous les périphériques doivent devenir des systèmes gérés pour autoriser l'accès à leurs utilisateurs. •Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants. La solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à des ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un ordinateur non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est procuré un nom d'utilisateur et un mot de passe valides. •Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de demander le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés. •Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant d'isoler rapidement et de façon efficace des ressources spécifiques du réseau. •Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources gérées.
Présentation de ce guide L'objectif de ce guide est de vous aider à mettre en place une solution d'isolation de serveurs et de domaines tout au long du cycle de vie informatique, de la phase initiale d'évaluation et d'approbation, au déploiement, au test et à la gestion de l'implémentation. Pour cette raison, les chapitres de ce guide ont été rédigés de façon à répondre aux besoins des différents lecteurs. Cette section présente brièvement le contenu des différents chapitres du guide Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe.
Chapitre 1 : Introduction à l'isolation de serveurs et de domaines Le premier chapitre (celuici) est constitué d'une synthèse et d'une brève introduction présentant le contenu des chapitres de ce guide. Il présente le concept d'isolation logique ainsi que différentes approches de l'isolation de serveurs et de domaines pour une entreprise, met en évidence l'intérêt commercial et illustre l'intégration de ces approches dans une infrastructure informatique type. Ce chapitre donne également des informations sur le scénario de la Woodgrove National Bank, adopté à des fins de démonstration, de conception et de test.
Chapitre 2 : Présentation de l'isolation de serveurs et de domaines Le chapitre 2 définit le concept des hôtes approuvés et explique comment utiliser l'approbation pour créer des solutions d'isolation de domaines ou de serveurs. Il décrit les relations entre le concept d'isolation de serveurs et de domaines, IPSec et les stratégies de groupe. Ce guide comprend des explications techniques détaillées de l'objectif attendu de la solution, en ce qui concerne les menaces
2
de sécurité qu'elle prévient. Il explique également les problèmes techniques éventuels liés à l'utilisation d'IPSec pour créer une solution d'isolation de domaines et de serveurs.
Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique Avant d'entreprendre un projet, les concepteurs de la solution doivent impérativement avoir connaissance d'informations précises, à jour, sur l'infrastructure informatique actuelle. Ils doivent notamment connaître l'état actuel de tous les systèmes réseau, des configurations des serveurs et des stations de travail, et des approbations de domaine. Ce chapitre aborde également les répercutions éventuelles sur d'autres technologies de réseau, telles que NAT, les clients VPN distants basés sur IPSec, les proxies et les parefeu internes, et le filtrage de ports internes. Il donne aussi des explications sur les informations requises dans le cadre de la planification et présente les étapes permettant d'obtenir ces informations.
Chapitre 4 : Conception et planification de groupes d'isolation Ce chapitre explique comment intégrer les besoins de l'entreprise dans la conception de l'isolation de serveurs et de domaines. Il présente une approche détaillée vous permettant de créer un groupe d'isolation qui répond aux besoins de sécurité de votre entreprise en matière d'isolation. Ce chapitre décrit également plusieurs approches de déploiement qui peuvent vous servir à limiter les conséquences sur l'entreprise lors du déploiement et à optimiser les chances de réussite de l'implémentation. Toutes les étapes et les procédures de ce chapitre sont illustrées par des exemples basés sur le scénario de la Woodgrove Bank.
Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation La stratégie IPSec est le mécanisme que vous utilisez pour appliquer les règles qui autorisent les ordinateurs à communiquer entre eux. Ces règles sont affectées et distribuées aux membres du domaine approuvé par le biais d'objets de stratégie de groupe (GPO). Ce chapitre contient les informations indispensables à la création des stratégies IPSec, et il explique comment déployer ces dernières sur les ordinateurs des destinataires.
Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines Une fois la solution implémentée et opérationnelle, vous devez comprendre et noter un certain nombre de processus qui vous aideront à assurer au quotidien une prise en charge et une gestion correcte de la solution. Ce chapitre inclut un modèle de prise en charge et présente plusieurs processus et procédures de gestion à utiliser dans le cadre d'une structure de fonctionnement plus vaste, telle que Microsoft Operations Framework (MOF). Pour plus d'informations sur MOF, reportezvous au site Web Microsoft Operations Framework , à l'adresse www.microsoft.com/mof.
Chapitre 7 : Dépannage d'IPSec Des problèmes surviendront forcément durant le déploiement et l'utilisation de la solution. Ce chapitre présente des procédures de dépannage d'IPSec, des tâches, des outils et des conseils qui vous permettront de savoir si IPSec est à l'origine des problèmes rencontrés, puis de les résoudre, le cas échéant. Outre les principaux chapitres, ce guide comprend des supports de référence, des aides pour les travaux ainsi que des scripts utilisés, au cours de l'élaboration de ce guide, dans la planification, le
3
test et le déploiement de l'environnement du laboratoire de test chez Microsoft. Les informations figurant dans ces annexes peuvent vous aider à implémenter vos propres solutions d'isolation de serveurs et de domaines. Elles sont destinées à vous aider durant toutes les phases du projet, depuis l'idée initiale de la solution jusqu'au fonctionnement au quotidien d'une solution entièrement déployée.
4
Table des matières Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe ........................ 1 Présentation ........................................................................................................................................... 1 Avantages métier .................................................................................................................................... 1 Présentation de ce guide ........................................................................................................................ 2 Table des matières ................................................................................................................................. 5 Chapitre 1 : Introduction à l'isolation de serveurs et de domaines ................................................. 8 Synthèse ................................................................................................................................................. 8 Défi métier .............................................................................................................................................. 9 Création d'une équipe de projet ............................................................................................................ 12 Présentation du scénario ...................................................................................................................... 13 Résumé ................................................................................................................................................ 18 Chapitre 2 : Présentation de l'isolation de serveurs et de domaines ............................................. 19 Connaissances préalables requises pour ce chapitre ........................................................................... 19 À qui s'adresse ce chapitre ................................................................................................................... 20 Exigences au niveau de l'entreprise ..................................................................................................... 20 Identifications des ordinateurs approuvés ............................................................................................ 24 Comment l'isolation de serveurs et de domaines s'intègretelle dans ma stratégie de sécurité réseau globale ? ............................................................................................................................................... 29 Rappel terminologique .......................................................................................................................... 32 Comment l'isolation de serveurs et de domaines peutelle être mise en place ? .................................. 36 De quoi nous protège l'isolation de serveurs et domaines ? ................................................................. 45 Comment déployer l'isolation de serveurs et de domaines ? ................................................................ 46 Résumé ................................................................................................................................................ 47 Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique ......................... 48 Connaissances préalables requises pour ce chapitre ........................................................................... 48 À qui s'adresse ce chapitre ................................................................................................................... 50 Analyse de l'état actuel ......................................................................................................................... 50 Considérations relatives à la capacité ................................................................................................. 61 Problèmes de prédéploiement .............................................................................................................. 62 Définition de l'approbation .................................................................................................................... 65 Identification des coûts de mise à niveau des hôtes actuels ................................................................ 69 Résumé ................................................................................................................................................ 71 Chapitre 4 : Conception et planification de groupes d'isolation .................................................... 73 Connaissances préalables requises pour ce chapitre ........................................................................... 73 Création de la conception d'isolation de serveurs et de domaines ....................................................... 74 Méthodes d'implémentation de groupe ................................................................................................. 92 Implémentation des groupes pour Woodgrove Bank ............................................................................ 96 Résumé ................................................................................................................................................ 96 Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation ....................................... 99 Connaissances préalables requises pour ce chapitre ........................................................................... 99 Création de stratégies IPSec dans Active Directory ........................................................................... 101 Autorisation de l'accès en entrée à un groupe d'isolation ................................................................... 136 Autres considérations relatives à IPSec ............................................................................................. 137 Résumé .............................................................................................................................................. 141 Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines .................... 143 Connaissances préalables requises pour ce chapitre ......................................................................... 143 Gestion des modifications ................................................................................................................... 144 Considérations relatives à la sauvegarde et la récupération .............................................................. 160
5
Réduction des risques d'infection sur le réseau .................................................................................. 162 Résumé .............................................................................................................................................. 164 Chapitre 7 : Dépannage d'IPSec ...................................................................................................... 166 Niveaux de support et transfert des incidents ..................................................................................... 166 Dépannage de niveau 1 ...................................................................................................................... 167 Préparation du dépannage de niveau 2 .............................................................................................. 175 Processus de dépannage d'IPSec ...................................................................................................... 184 Dépannage de niveau 3 ..................................................................................................................... 227 Résumé .............................................................................................................................................. 228
6
7
Chapitre 1 : Introduction à l'isolation de serveurs et de domaines Pendant bon nombre d'années il était courant d'isoler physiquement les ordinateurs et les réseaux, pour éviter de compromettre les données et les communications. L'isolation physique pose cependant un problème : elle ne permet pas de protéger facilement derrière des limites physiques l'infrastructure informatique d'un grand nombre d'entreprises. La forte croissance des clients mobiles et la nature des environnements réseau distribués rendent ces limites physiques trop rigides à implémenter et à utiliser. Avec l'isolation de serveurs et de domaines, il est possible de créer une couche de sécurité pour isoler logiquement le trafic réseau entre des ordinateurs ou des réseaux. Si une personne malveillante parvient à accéder physiquement au réseau interne d'une entreprise et si elle tente d'accéder à un serveur contenant des ressources stratégiques, l'isolation de serveurs et de domaines est en mesure de bloquer cet accès, tout simplement parce que l'ordinateur utilisé dans le cadre de cette attaque ne fait pas partie des systèmes approuvés de l'entreprise, même si la personne malveillante a utilisé un compte d'utilisateur et un mot de passe valides. L'isolation logique via des techniques d'isolation de serveurs et de domaines permet d'élaborer une solution d'isolation souple, évolutive et gérable, qui garantit la sécurité de l'isolation tout en évitant le coût et la rigidité des limites physiques.
Synthèse Microsoft a parfaitement conscience que la sécurisation des réseaux constitue pour les grandes entreprises un défi de plus en plus complexe. Au fur et à mesure que les entreprises se développent et que les relations commerciales évoluent, le contrôle de l'accès physique au réseau relève presque d'une mission impossible. Tous les jours, pour des raisons commerciales valables, vos clients, fournisseurs et consultants connectent leurs équipements mobiles à votre réseau. L'apparition des technologies de réseau et de connexion sans fil, telles que GPRS et Bluetooth, a simplifié plus que jamais l'accès réseau. Cette connectivité améliorée signifie que les membres d'un réseau interne sont de plus en plus exposés aux risques non négligeables que constituent les autres ordinateurs de ce réseau interne, sans compter les brèches éventuelles dans le périmètre de sécurité. Les parefeu personnels ou basés sur l'hôte participent à la protection des clients lors d'une connexion à Internet, mais ils ne permettent pas encore de protéger les clients et les serveurs internes. L'isolation de serveurs et de domaines est intéressante pour l'entreprise. Elle offre avant tout une couche de sécurité réseau qui réduit considérablement le risque qu'un hôte non approuvé accède aux membres du domaine approuvés du réseau interne d'une entreprise. L'isolation de serveurs et de domaines peut jouer un rôle stratégique important dans le cadre de la lutte contre la propagation des virus, de la protection contre les pirates internes, contre les utilisations erronées de la part des employés et contre le vol d'informations. En outre, elle peut être utilisée pour demander l'appartenance au domaine de tous les clients cherchant à accéder à des ressources approuvées, qu'il s'agisse de clients ou de serveurs, de sorte qu'elles puissent être mieux gérées par le personnel informatique. L'isolation de serveurs et de domaines peut également servir de stratégie principale ou complémentaire pour répondre aux besoins en matière de protection ou de confidentialité des données sur le réseau, sans avoir à modifier les applications Microsoft® Windows® existantes ou à déployer un tunnel VPN sur le réseau.
8
L'isolation de serveurs et de domaines permet aux administrateurs du système informatique de restreindre les communications TCP/IP des membres du domaine identifiés comme ordinateurs approuvés. Les ordinateurs approuvés peuvent être configurés pour autoriser uniquement les connexions entrantes à partir des autres ordinateurs approuvés ou d'un groupe spécifique d'ordinateurs approuvés. Pour contrôler les droits de connexion réseau, les contrôles d'accès sont gérés de façon centralisée par les stratégies de groupe Active Directory®. La plupart des connexions TCP/IP peuvent être sécurisées sans avoir à modifier les applications. En effet, IPSec (Internet Protocol security) fonctionne au niveau de la couche réseau située sous la couche des applications, pour assurer une authentification et une sécurité de pointe par paquet, de bout en bout entre les ordinateurs. Le trafic réseau peut être authentifié, ou authentifié et chiffré, dans divers scénarios personnalisables. Les configurations d'IPSec et des stratégies de groupe sont gérées de façon centralisée dans Active Directory. Le concept d'isolation logique présenté dans ce guide englobe deux solutions : l'isolation de domaines pour isoler les membres du domaine des connexions non approuvées, et l'isolation de serveurs pour qu'un serveur accepte uniquement les connexions réseau des membres du domaine approuvés ou d'un groupe de membres du domaine spécifique. Ces solutions peuvent être utilisées séparément ou ensemble, dans le cadre d'une solution d'isolation logique globale. La solution testée présentée dans ce guide requiert la configuration minimale suivante pour les différentes platesformes :
• Windows 2000 avec le Service Pack 4 ou ultérieur • Microsoft Windows Server™ 2003 • Windows XP avec Service Pack 2 ou ultérieur Ces configurations garantissent le niveau de révision requis pour les composants d'IPSec. Les communications avec les platesformes nonWindows ou avec des systèmes non approuvés sont contrôlées via la configuration d'IPSec, répertoriant les exemptions et/ou étant autorisée à revenir à des communications en texte clair (nonIPSec). Avec les nouvelles fonctions transversales de traduction d'adresses réseau (NAT), les traducteurs d'adresses réseau n'empêchent plus l'utilisation d'IPSec sur le réseau local. Ce guide utilise le scénario de la Woodgrove National Bank pour illustrer l'implémentation de l'isolation de serveurs et de domaines dans un environnement de laboratoire représentatif. Il présente également l'expérience acquise par Microsoft lors de l'implémentation de ces deux solutions en interne, ainsi que dans des environnements clients. Ce guide a été conçu par une équipe d'experts de Microsoft. Il a ensuite été contrôlé par le personnel informatique de Microsoft et par des clients via un programme bêta. Comme les scénarios d'isolation de serveurs et de domaines ont tous deux été implémentés dans le réseau interne mondial de Microsoft, l'entreprise dépend véritablement de la sécurité de ces solutions. Par ailleurs, en recommandant ces solutions à ses clients, Microsoft soutient les entreprises qui ciblent à long terme une infrastructure véritablement sécurisée et gérable, pour un environnement informatique plus sûr.
Défi métier Aujourd'hui, la nature même des entreprises connectées et des équipements réseau mobiles est susceptible de mettre en péril l'infrastructure informatique de votre entreprise. Ces risques peuvent avoir diverses origines. Ils peuvent notamment provenir de l'ordinateur d'un client, d'un vendeur ou d'un employé mobile, outre les ordinateurs distants des petites succursales et les ordinateurs domestiques des employés. Dans bon nombre de cas, ces risques consistent principalement en
9
l'attaque d'un logiciel malveillant (également appelé malware), tel qu'un virus ou un vers, téléchargé ou installé par inadvertance sur l'ordinateur d'un utilisateur crédule. L'isolation logique ne peut pas être considérée comme une protection antivirus. Elle peut toutefois s'intégrer dans une solution antivirus plus vaste, car elle met en place une couche de sécurité complémentaire qui réduit les risques d'attaque et leurs effets. Par exemple, un client de passage dans votre entreprise qui connecte son ordinateur portable à votre réseau pour vous présenter une feuille de calcul introduit un risque dans l'infrastructure informatique de votre entreprise. En se connectant directement à votre réseau physique, ce client a contourné le périmètre de sécurité mis en place pour lutter contre les attaques réseau. Si le réseau auquel se connecte ce client n'autorise pas l'accès direct aux serveurs de votre entreprise, le risque est limité. La question qui se pose est la suivante : comment autoriser l'accès à ces ressources de l'entreprise uniquement aux ordinateurs qui en ont besoin ? Avec l'isolation de serveurs et de domaines ! Cette technique permet d'identifier et d'authentifier un ordinateur afin de déterminer les ressources auxquelles il est autorisé à accéder. L'authentification a lieu avant que l'utilisateur se connecte, et elle reste active une fois l'ordinateur connecté. Avec cette approche, il est possible de réduire le risque que constituent pour vos données stratégiques les ordinateurs non identifiés et non gérés qui se connectent à votre réseau. Remarque : pour plus d'informations sur les logiciels malveillants et pour connaître les moyens spécifiques à mettre en place afin de vous protéger, consultez la page The Antivirus DefenseinDepth Guide (Guide de défense antivirus renforcée), sur le site Web de TechNet, à l'adresse http://go.microsoft.com/fwlink/?LinkId=28732.
Avantages métier Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, les suivants :
• Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les ordinateurs gérés du réseau.
• Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise en œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à l'ensemble des ressources du réseau.
• Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution d'isolation physique.
• Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au
système d'informations d'une entreprise, tous les systèmes doivent devenir des systèmes gérés pour autoriser l'accès à leurs utilisateurs.
• Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants.
La solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à des ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un ordinateur non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est procuré un nom d'utilisateur et un mot de passe valides.
• Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de demander le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés.
• Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant d'isoler rapidement et de façon efficace des ressources spécifiques du réseau.
10
• Protection des connexions réseau en accès libre. Certains points de connexion réseau, tels que les points de connexion dans un « hall », n'offrent pas un accès direct à l'ensemble des ressources de votre réseau.
• Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources gérées.
Défi technologique Il n'est facile de protéger une infrastructure informatique moderne contre les attaques tout en permettant aux employés de travailler de la façon la plus souple possible et d'être aussi productifs que possible. Le fait de comprendre l'ensemble des technologies qui contribuent à sécuriser un environnement est déjà suffisamment complexe pour bon nombre de personnes. Il convient de repérer précisément où se situe la solution d'isolation dans une infrastructure informatique type et de comprendre de quelle manière elle complète les solutions de protection réseau existantes. La figure suivante présente une infrastructure réseau type constituée d'un certain nombre de couches de protection réseau. Elle indique à quel endroit intervient l'isolation logique dans un environnement type :
Figure 1.1 Zones de l'infrastructure et couches de protection réseau
La figure 1.1 illustre simplement les diverses technologies que vous pouvez mettre en œuvre pour sécuriser en profondeur une infrastructure réseau type. Ce type d'infrastructure comprend généralement les éléments suivants :
• Travailleurs et réseaux distants. Ces entités distantes utilisent généralement des réseaux privés virtuels (VPN) pour se connecter au réseau interne de l'entreprise et accéder à son infrastructure informatique.
• Internet. Le réseau interne de l'entreprise est souvent connecté à Internet via un ou plusieurs
parefeu de périmètre. Ces périphériques résident en général dans un réseau de périmètre qui fournit un niveau de protection élevé contre les menaces externes liées aux connexions Internet.
11
• Réseau de périmètre. Ce réseau est sciemment placé à l'écart pour les serveurs et les systèmes qui ont besoin d'un accès direct à Internet ou auxquels il doit être possible d'accéder à partir d'Internet. Ils sont, par conséquent, plus exposés aux attaques.
• Réseau interne. En général, ce réseau regroupe les réseaux de l'entreprise situés physiquement
sur les sites qui lui appartiennent et gérés comme partie intégrante de l'infrastructure informatique.
• Réseau de quarantaine. Ce réseau est un nouveau composant qui offre une connexion limitée
aux ordinateurs qui ne répondent pas aux conditions minimales requises par l'entreprise en matière de normes de sécurité. Une fois que les tests exigés ont été menés à bien, l'ordinateur et l'utilisateur sont autorisés à accéder à l'ensemble du réseau interne. En cas d'échec des tests, le réseau de quarantaine leur accorde une connexion suffisante pour télécharger et installer les éléments requis qui leur permettront de mener à bien les tests. Grâce à la protection de l'accès au réseau (NAP, Network Access Protection), Microsoft offre de nouvelles possibilités aux ordinateurs distants mis en quarantaine. Pour plus d'informations, reportezvous à la page Network Access Protection du site de Microsoft, à l'adresse www.microsoft.com/nap.
• Réseaux partenaires. Compte tenu que ces réseaux n'appartiennent pas à l'entreprise ou que celleci ne les gère pas, un contrôle d'accès strict est généralement appliqué pour autoriser l'exécution de processus ou d'applications spécifiques de l'entreprise via un tunnel VPN ou un routeur de périmètre diffusant des communications extranet.
La figure 1.1 illustre le fait que l'isolation logique est axée directement sur les communications des hôtes du réseau interne. Les VPN sont gérés par les services d'accès à distance (RAS) pour autoriser la connexion sécurisée du trafic des travailleurs et réseaux distants. Les parefeu réseau latéraux protègent les communications entre Internet et les réseaux internes. Les services RAS et la protection NAP permettent de gérer les connexions des travailleurs distants par le biais d'un réseau de quarantaine. À l'heure actuelle, ces couches de protection réseau sont en général installées et gérées en tant que composants distincts d'un réseau de protection renforcée. Toutefois, dans les années à venir, ces composants seront probablement intégrés dans une solution de protection réseau commune susceptible d'être implémentée comme solution unique, de bout en bout. Aujourd'hui, ce qui manque souvent dans bon nombre de réseaux, c'est la possibilité de protéger les ordinateurs du réseau interne les uns des autres. Parfois, les réseaux internes étendus prennent en charge plusieurs organisations, et dans certains cas, plusieurs services informatiques doivent gérer les ordinateurs et les points d'accès physiques. Par conséquent, il ne faut pas considérer le réseau interne simplement comme un réseau dans lequel tous les ordinateurs physiquement connectés sont approuvés et bénéficient d'une connexion réseau complète entre eux. L'isolation logique vise à segmenter et à isoler le réseau interne afin de fournir un niveau de sécurité supérieur sans avoir recours aux limites physiques. Le véritable défi technologique de l'isolation logique consiste à mettre en œuvre la solution de sorte qu'elle soit à la fois gérable et évolutive. Si votre conception est trop complexe et restrictive, elle risque d'empêcher les utilisateurs d'effectuer leurs tâches, ce qui peut être pire que l'absence d'une solution d'isolation. Vous devez réaliser une planification et des tests avant et pendant le déploiement de la solution. Grâce à ce guide, vous avez la possibilité de mettre en place une solution évolutive et gérable, susceptible d'être déployée de façon contrôlée, et qui permet d'effectuer des tests à différents stades de la phase de déploiement. Lorsque l'isolation logique est en place, la couche de sécurité complémentaire contribue à réduire les risques qu'encourent vos ressources d'informations sur le réseau, et ce, sans restreindre les possibilités d'action des clients autorisés.
Création d'une équipe de projet 12
Cette solution peut avoir une incidence sur l'ensemble des communications du réseau interne de l'entreprise, ce qui risque par conséquent d'affecter tous les services et toutes les personnes qui utilisent ces communications. Par conséquent, il est primordial que les attentes et les besoins de l'organisation soient communiqués, répertoriés, compris et pris en compte à chaque étape de ce projet. Dans la mesure où une seule personne ne peut pas réaliser toutes les tâches requises dans un projet d'une telle ampleur dans une entreprise type, il est vivement recommandé de mettre en place une équipe de projet. Cette équipe de projet doit être constituée de représentants de tous les services de l'entreprise, et elle doit intégrer les principaux secteurs de technologie de l'infrastructure informatique actuelle. Étant donné que ce guide n'a pas pour but d'expliquer le fonctionnement d'une équipe de projet, nous partons du principe qu'une équipe de projet convenable est mise en place et que les parties prenantes et les utilisateurs sont informés des exigences et des objectifs de la solution tout au long du projet. Pour plus d'informations sur l'organisation d'un projet comme celuici, reportezvous au site Web Microsoft Solutions Framework (MSF) , à l'adresse www.microsoft.com/msf.
Présentation du scénario Les solutions d'isolation de serveurs et de domaines ont toutes deux été déployées en interne sur le réseau interne de Microsoft. Toutefois, nous avons également testé une implémentation de laboratoire physique représentative, basée sur le scénario client de la Woodgrove Bank, pour proposer un modèle public et concret pour cette solution. Pour élaborer ce guide, les besoins de l'entreprise et les exigences techniques de cette organisation fictive ont été ajoutés à ceux de Microsoft. Ce guide contient des techniques de gestion et de prise en charge utilisées régulièrement par les administrateurs du système informatique interne de Microsoft. Des notes particulières ont été ajoutées lorsque les exigences et le personnel de la Woodgrove Bank différaient de ceux de la conception propre à Microsoft.
Qu'estce que la Woodgrove Bank ? La Woodgrove National Bank est une organisation fictive de démonstration utilisée par Microsoft comme exemple de client tangible pour vous aider à déployer la solution. Microsoft a tiré parti de sa longue expérience avec ses clients professionnels pour dresser la liste des exigences de la Woodgrove Bank. Comme la Woodgrove Bank est une banque, elle s'appuie sur une solution de sécurité pour assurer la sécurité de ses ressources monétaires et des données privées de ses clients. La Woodgrove Bank doit également respecter les obligations réglementaires émises par le gouvernement et les groupes industriels. Dans cet exemple, les obligations réglementaires et législatives ne sont pas abordées pour éviter que la solution présentée ne soit spécifique à un pays ou une région. La Woodgrove Bank est une importante banque d'investissement mondiale au service d'instituts, d'entreprises, du gouvernement et de particuliers dans son rôle d'intermédiaire financier. Ses activités incluent les hypothèques, les ventes et le commerce, les services de conseil financier, la recherche de placements, le capital de risque et les services de courtage pour les institutions financières. La Woodgrove Bank est une filiale appartenant intégralement à la société WG, entreprise de services financiers mondiale majeure, dont le siège social est basé à Londres (Angleterre). La société WG possède les cinq entreprises suivantes : Woodgrove National Bank, Northwind Trading, Contoso, Ltd., Litware Financials et Humongous Insurance. Toutes les entreprises de la société WG sont de vastes organisations, comptant chacune plus de 5 000 personnes.
13
Situation géographique La Woodgrove Bank emploie plus de 15 000 personnes, dans plus de 60 bureaux répartis dans le monde entier. Elle possède des sièges sociaux (sites satellites) qui comptent un grand nombre d'employés, à New York (5 000 personnes), à Londres (5 200 personnes) et à Tokyo (500 personnes). Chaque site satellite prend en charge des sites secondaires de petite taille (par exemple, le siège de New York prend en charge les sites de Boston et d'Atlanta). Outre ses sites satellites, la Woodgrove Bank possède également deux autres sites principaux, respectivement basés à Sydney et à Johannesburg, chacun possédant ses propres serveurs de fichiers dédiés, d'impression et d'applications. Connectivité entre les sites Tokyo et Londres sont connectées aux sièges de l'entreprise à New York via des connexions Internet privées. Les bandes passantes allouées sont respectivement de 6 mégabits par seconde (Mbits/s) et de 10 Mbits/s. Tous les sites satellites sont connectés aux sièges et bénéficient d'une connexion de 2 à 10 mégaoctets (Mo). Les filiales autonomes bénéficient d'une connexion de 2 Mo. Les microfililales ont généralement une connexion de réseau étendu (WAN) de 1 Mo. La figure 3.1 du chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », de ce guide détaille ces connexions.
Défis informatiques de l'entreprise La Woodgrove Bank est confrontée aux mêmes défis que la plupart des entreprises. Elle souhaite en effet augmenter son chiffre d'affaires et réduire les coûts tout en diminuant le coût des immobilisations. Ces défis ont toujours des répercutions sur les services informatiques. La Woodgrove Bank est confrontée à un certain nombre d'initiatives d'entreprise qui affectent également les services informatiques. Parmi ces initiatives figurent les suivantes :
• Conquérir de nouveaux marchés via des fusions et des acquisitions • Gagner la satisfaction des clients • Améliorer la productivité des employés • Améliorer les processus et le fonctionnement • Fournir un environnement sécurisé Ces initiatives affectent les services informatiques, mais les responsables informatiques sont également confrontés à d'autres défis spécifiques, tels que les suivants :
• Réduire le coût global des services informatiques. • Réduire les frais d'exploitation ; améliorer la gestion et réduire ses coûts ; réduire le nombre de serveurs dans l'environnement ; regrouper des applications et services hétérogènes sur des serveurs uniques. • Tirer parti des investissements informatiques existants. • Créer une infrastructure informatique souple.
• Améliorer le retour sur investissement. • Accroître l'utilisation. • Améliorer la disponibilité et la fiabilité. • Exploiter de nouvelles platesformes matérielles.
• S'assurer que les employés, partenaires et clients utilisent l'environnement le plus sûr.
14
• Autoriser les accords sur le niveau de service (en interne et en externe). • Améliorer la souplesse de l'entreprise en fournissant un véritable accès en temps réel aux informations, quel que soit l'endroit.
Profil informatique de l'organisation La Woodgrove Bank est dotée d'un environnement serveur mixte sous Windows et UNIX, mais son infrastructure est exécutée sur une dorsale Windows Server. Elle compte au total 1 712 serveurs Windows. La plupart d'entre eux exécutent Windows 2000 ou une version ultérieure :
• Serveurs de fichiers et d'impression • Serveurs Web • Serveurs d'infrastructure • Serveurs Microsoft Exchange • Serveurs Microsoft SQL Server™ • Serveurs de développement • Serveurs d'analyse • Autres (Lotus Notes, Oracle)
785 123 476 98 73 73 33 51
La plupart des serveurs sont répartis dans les trois sièges sociaux de l'entreprise (New York, Londres et Tokyo). Environnement PC La plupart des employés de la Woodgrove Bank possèdent au moins un ordinateur personnel. Les employés sont généralement équipés d'ordinateurs de bureau. Quant aux commerciaux, ils sont équipés d'ordinateurs portables. Au total, la Woodgrove Bank possède plus de 17 000 ordinateurs personnels. Environ 85 % de ces ordinateurs sont des ordinateurs de bureau et 15 % sont des ordinateurs portables. Plus de 95 % des ordinateurs personnels sont dotés de la technologie Intel et exécutent une version de Windows. Pour les applications LOB (Line of Business), des services spécifiques utilisent des postes de travail Macintosh et quelques postes de travail UNIX.
Présentation de l'architecture du système et de l'architecture de gestion Le réseau de la Woodgrove Bank est constitué de plusieurs zones informatiques : un centre de données d'entreprise, deux sites satellites, deux succursales et un réseau de périmètre permettant d'assurer la prise en charge des utilisateurs distants. Pour centraliser la gestion des serveurs et des ordinateurs de bureau à New York, la Woodgrove Bank applique un modèle de gestion centralisée (voir figure cidessous).
15
Figure 1.2 Modèle de gestion informatique centralisée de la Woodgrove Bank
Service d'annuaire Pour sa structure Active Directory, la Woodgrove Bank a opté pour un modèle de forêt du fournisseur de service. Ce modèle offre en effet la possibilité de mettre en place une forêt pour le périmètre et une forêt partagée distincte pour les ressources internes. Cette souplesse permet de répondre aux exigences d'isolation des serveurs dans le réseau de périmètre. La Woodgrove Bank n'a pas choisi le modèle de forêt unique car celuici ne permet pas d'isoler les serveurs du périmètre des données stratégiques de l'entreprise. La figure suivante représente la structure logique Active Directory utilisée par la Woodgrove Bank :
Figure 1.3 Configuration du service Active Directory de la Woodgrove Bank
La forêt du périmètre utilise le modèle de domaine de forêt unique. Il suffit en effet à assurer la gestion des serveurs du périmètre. Dans le périmètre, les exigences de réplication sont faibles ; il n'est donc pas nécessaire de mettre en place des limites de réplication ou d'avoir recours au modèle de domaines régionaux multiples pour segmenter la forêt. Notez bien que la Woodgrove Bank a choisi cette configuration uniquement pour la gestion des serveurs du périmètre. Si les comptes d'utilisateurs avaient été placés dans le périmètre et que ce dernier s'était trouvé dans plusieurs sites, une autre configuration de domaine aurait été requise.
16
La forêt interne est basée sur un modèle de domaines régionaux multiples. La Woodgrove Bank a créé trois domaines régionaux : Amérique, Europe et Asie. Par ailleurs, la Woodgrove Bank a implémenté une racine de forêt dédiée pour gérer les fonctionnalités au niveau de la forêt. Ce modèle permet de gérer la topologie de la réplication et de déléguer à chaque région l'administration de l'autonomie au niveau du domaine. La topologie de site de la Woodgrove Bank est partagée en trois zones régionales : Amérique, Europe et Asie (AsiePacifique). New York, Londres et Tokyo sont les routeurs principaux de l'ensemble de la topologie. Les concepteurs de la configuration de la Woodgrove Bank ont opté pour une unité d'organisation (UO) principalement orientée objet. La structure d'UO est répliquée dans son intégralité dans chaque domaine régional, et un sousensemble de la structure d'UO est créé dans la racine de la forêt. La figure 3.2 du chapitre 3 de ce guide représente en détail la structure d'UO utilisée par la Woodgrove Bank. Stratégie de déploiement de l'isolation de serveurs et de domaines de la Woodgrove Bank Pour définir au mieux la configuration qui répond à ses attentes, la Woodgrove Bank a créé un projet de laboratoire. Ce projet consiste en l'implémentation d'un petit laboratoire qui permettra de tester la configuration prévue par la Woodgrove Bank (voir figure suivante).
Figure 1.4 Configuration expérimentale de la Woodgrove Bank
Ce schéma représente le sousensemble des ordinateurs utilisés dans le scénario de la Woodgrove Bank pour tester les scénarios présentés dans ce guide. L'objectif de ce projet de démonstration était de fournir une diversité de configuration suffisamment importante dans le 17
laboratoire pour s'assurer que la solution fonctionne comme prévu, tout en évitant les répercutions sur les serveurs de production et les utilisateurs. Les exemples proposés dans ce guide sont basés sur les résultats de l'infrastructure expérimentale représentée dans la figure 1.4. Remarque : comme l'isolation modifie plusieurs aspects du réseau, Microsoft recommande vivement de tester, dans un premier temps, chaque scénario d'isolation dans un environnement de laboratoire afin d'éviter les répercutions sur les environnements de production. Les administrateurs du système informatique doivent se reporter aux chapitres 6 et 7 pour obtenir des informations sur la prise en charge, les procédures opérationnelles et le dépannage. Lorsqu'un projet d'implémentation en laboratoire s'était déroulé avec succès, un groupe de serveurs était identifié pour implémenter un scénario élémentaire d'isolation de serveurs. Ces serveurs correspondent à ceux qui ont le moins de répercutions sur l'entreprise, en cas problème de connexion. Les administrateurs du système informatique et les techniciens du support technique ont suivi un entraînement aux techniques de dépannage. Ces serveurs ont été étroitement surveillés pour mesurer l'impact de l'implémentation sur les performances et sur les appels au support technique. Les rôles de gestion organisationnelle, les processus et les méthodes de support ont été testés. Ensuite, l'un des plus petits domaines de la Woodgrove Bank a été choisi pour tester l'isolation de domaines. Il a été possible de réduire l'impact de ce projet d'isolation de domaines en utilisant IPSec uniquement pour les sousensembles du réseau dans lesquels se trouvait la majorité des membres du domaine. Par ailleurs, il a également été possible de réduire l'impact sur l'entreprise en autorisant les communications nonIPSec lorsque les membres de ce domaine communiquaient avec des ordinateurs n'appartenant pas au projet expérimental. Une fois ces tests terminés, l'équipe de projet possédait toutes les informations nécessaires à la création et à l'implémentation d'une configuration complète pour l'ensemble de l'organisation.
Résumé Ce chapitre constitue une introduction à l'isolation logique. Il explique comment l'isolation de serveurs et de domaines peut être utilisée pour créer une solution de niveau entreprise avec IPSec et des stratégies de groupe. En outre, il comprend une synthèse et une brève description de chaque chapitre de ce guide. Grâce à l'ensemble des informations de ce chapitre, vous pouvez comprendre les avantages que représente cette solution pour votre entreprise, comprendre comment elle s'intègre dans une infrastructure informatique type et cerner les compétences nécessaires à la réussite de sa mise en œuvre.
18
Chapitre 2 : Présentation de l'isolation de serveurs et de domaines À l'époque où les réseaux locaux (LAN) devenaient la norme, les professionnels de l'informatique rivalisaient d'efforts pour proposer des services réactifs, hautement disponibles, tout en maintenant un niveau de sécurité adéquat. Un grand nombre de technologies ont été mises au point pour fonctionner avec TCP/IP, afin de répondre au problème de l'implémentation de la sécurité au niveau des couches réseau et de transport. Parmi ces technologies figurent notamment IPv6, 802.1X, les commutateurs réseau, la segmentation du réseau local virtuel (VLAN) et IPSec (Internet Protocol security). Le résultat indirect de l'introduction de ces technologies n'est autre qu'une sécurité réseau basée sur plusieurs couches. Ces couches peuvent permettre de séparer, de segmenter ou d'isoler un ou plusieurs hôtes ou réseaux d'autres hôtes ou réseaux. L'objectif de ce chapitre consiste à organiser la couche de sécurité IPSec en fonction des autres couches et à expliquer son fonctionnement avec les stratégies de groupe dans une solution d'isolation gérable et évolutive dans un environnement à l'échelle de l'entreprise.
Connaissances préalables requises pour ce chapitre Avant d'exploiter les informations fournies dans ce chapitre, vous devez parfaitement maîtriser les technologies et les concepts suivants. Vous pouvez tirer parti de ce guide sans ces connaissances préalables, mais si vous les maîtrisez, la réussite de l'implémentation sera pratiquement garantie.
Connaissances requises Vous devez posséder des connaissances sur les éléments suivants de Microsoft® Windows Server™ 2003 :
• concepts du service d'annuaire Active Directory® (notamment la structure et les outils
Active Directory, manipulation d'utilisateurs, de groupes et d'autres objets Active Directory, et utilisation des stratégies de groupe) ;
• concepts d'authentification, notamment l'utilisation du protocole Kerberos version 5 et de l'infrastructure de clés publiques (PKI) ;
• sécurité du système Microsoft Windows® ; concepts de sécurité tels que les utilisateurs, les
groupes, l'audit et les listes de contrôle d'accès (ACL) ; utilisation des modèles de sécurité ; concepts d'authentification mutuelle ; méthodes et concepts standards de résolution de noms tels que le système de noms de domaine (DNS, Domain Name System) et le service WINS (Windows Internet Naming Service) ; outils de diagnostic et concepts de dépannage standards Windows ; utilisation des stratégies de groupe ou des outils de ligne de commande pour appliquer des modèles de sécurité ;
• protocole TCP/IP, notamment l'organisation des sousréseaux, les masques réseau et le routage ; fonctionnalités de bas niveau, protocoles et termes tels que ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol) et unité maximale de transfert (MTU, Maximum Transmission Unit).
• principes de gestion des risques de sécurité.
19
Remarque : le chapitre 6, « Deploying IPSec » (Déploiement d'IPSec) du Kit de déploiement de Windows Server 2003 présente des scénarios relatifs au mode de transport IPSec qui n'étaient auparavant pas recommandés. Toutefois, le travail réalisé par Microsoft dans le cadre de son propre déploiement interne d'IPSec et la disponibilité de conseils supplémentaires ont aujourd'hui permis de modifier ces recommandations. Le trafic de diffusion et de multidiffusion ne peut pas encore utiliser IPSec, mais tous les types de trafic IP monodiffusion peuvent être sécurisés via IPSec. Chaque client doit mesurer les avantages du déploiement d'IPSec dans des scénarios d'isolation de domaines ou de serveurs par rapport aux coûts, aux impacts et à d'autres compromis. Microsoft recommande et encourage désormais la généralisation de l'utilisation d'IPSec sur les réseaux de ses clients conformément à ce guide.
Conditions requises pour l'organisation La planification de la sécurité d'une organisation ne peut pas être affectée à une seule personne. Les informations qui permettent de déterminer les exigences exactes d'une organisation proviennent souvent de plusieurs sources de l'organisation. Contactez d'autres personnes de votre entreprise susceptibles d'être concernées par la planification de l'isolation, notamment les personnes suivantes :
• les dirigeants ; • Représentants de groupes d'utilisateurs • les personnes chargées de l'audit et de la sécurité ; • Groupe de gestion des risques • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • Personnel technique, d'administration et des opérations DNS, du serveur Web et du réseau Remarque : selon la structure de votre organisation informatique, plusieurs personnes peuvent occuper un même poste, ou une personne peut occuper plusieurs postes. L'étendue d'un projet d'isolation de serveurs et de domaines nécessite l'intervention d'une équipe complète de personnes afin de bien cerner les exigences de l'entreprise, les problèmes techniques, l'impact sur les utilisateurs et le processus du projet dans son ensemble. Il peut être intéressant qu'une personne faisant preuve d'autorité joue le rôle de contact principal pour ce projet lorsque des observations à plus grande échelle sont requises, telles que celles du personnel de support ou des utilisateurs qui seront affectés au cours du déploiement. Une planification et une communication insuffisantes sont les deux principales causes d'échec des projets complexes. L'équipe de projet doit comprendre ces risques éventuels et s'assurer que des mesures ont été prises pour les limiter.
À qui s'adresse ce chapitre Ce chapitre s'adresse aux architectes et décisionnaires techniques chargés de concevoir une solution personnalisée d'isolation de serveurs et de domaines pour une organisation. Pour exploiter au mieux ce chapitre, il est souhaitable de posséder de solides connaissances techniques sur les technologies abordées et sur l'infrastructure actuelle de l'entreprise.
Exigences au niveau de l'entreprise Vous devez bien comprendre que ce sont les exigences de l'entreprise qui influent sur la solution. L'isolation peut être définie comme une séparation logique ou physique entre un ou plusieurs ordinateurs et d'autres ordinateurs, les empêchant ainsi de communiquer entre eux sur un réseau. Les
20
restrictions de sécurité affecteront nécessairement le travail quotidien des employés au sein d'une organisation. Les modifications apportées dans le cadre de la solution modifieront la façon dont les ordinateurs communiquent les uns avec les autres et avec les ordinateurs non approuvés. Pour la conception de cette solution, l'équipe de projet a besoin de temps pour planifier et analyser la faisabilité de l'implémentation, le personnel de support informatique doit suivre une formation, et au moins un programme d'information des employés doit être mis en place. Les services de sécurité supplémentaires destinés au trafic réseau peuvent nécessiter de la mémoire serveur supplémentaire, voire des cartes réseau d'accélération matérielle. Il est également possible d'avoir recours à d'autres solutions pour atteindre ou les mêmes objectifs d'isolation ou des objectifs similaires. Par conséquent, il est important de déterminer l'impact financier de la solution sur l'entreprise.
Garantie du respect des réglementations Plus les informations personnelles sont stockées dans les ordinateurs, plus l'intérêt pour la confidentialité des données est grand. Le contrôle de l'accès aux informations des clients et des employés n'est plus seulement une bonne pratique commerciale. Selon les lois en vigueur dans chaque pays, une entreprise qui ne respecte pas ses obligations en termes de protection des informations confidentielles devient vulnérable à des attaques financières et légales. Par exemple, les organisations travaillant aux ÉtatsUnis pourraient avoir à respecter (intégralement ou partiellement) les réglementations suivantes :
• FISMA (Federal Information Security Management Act) • SarbanesOxley Public Company Accounting Reform and Investor Protection Act • GLBA (GrammLeachBliley Financial Services Modernization Act) • HIPAA (Health Insurance Portability and Accountability Act) La réglementation HIPAA comporte des directives strictes sur la façon dont les organismes de santé doivent gérer les informations médicales personnelles électroniques (ePHI). Elle n'oblige et ne recommande pas de technologie particulière ; elle indique simplement les caractéristiques requises pour être en conformité avec la protection des ePHI et comment limiter les risques. Considérez l'isolation de domaines ou de serveurs avec protection IPSec comme une mesure de protection technique pour répondre aux exigences des sections de l'HIPAA suivantes :
• Contrôle d'accès 164.312(a)(1) : protéger l'accès réseau entrant vers des ordinateurs approuvés
via des autorisations de stratégie de groupe et utiliser le chiffrement pour empêcher la divulgation des EPHI sur le trafic réseau.
• Contrôles d'audit 164.312(b) : auditer les ordinateurs qui communiquent entre eux. • Intégrité 164.312(c)(1) : limiter l'accès réseau entrant vers des ordinateurs abritant des ePHI
uniquement à un groupe spécifique d'ordinateurs et d'utilisateurs autorisés et approuvés. Empêcher l'altération des ePHI lors des transmissions réseau en assurant l'intégrité et l'authenticité de tous les paquets réseau des connexions applicatives.
• Authentification des personnes ou des entités164.312(d) : requérir l'authentification et l'autorisation des ordinateurs approuvés pour l'accès réseau entrant vers d'autres ordinateurs approuvés.
• Sécurité des transmissions 164.312(e)(1) : assurer l'authenticité, l'intégrité et le chiffrement. En général, vous pouvez répondre à ces exigences en utilisant le protocole SSL (Secure Sockets Layer) et TLS (Transport Layer Security). Pour être en conformité avec les réglementations de sécurité de l'HIPAA, les applications peuvent, par exemple, avoir recours à la technologie Microsoft .NET avec SSL/TLS. Pour plus d'informations, reportezvous au Livre blanc « Healthcare Without Boundaries: IntegrationTechnology for the New Healthcare Economy » à l'adresse suivante : www.microsoft.com/Resources/Healthcare/HealthcareEconomy.aspx.
21
Les communications entre applications doivent toutefois intégrer correctement les contrôles d'algorithme et l'utilisation de SSL/TLS. Les principaux avantages d'une solution d'isolation IPSec sont les suivants : une protection de toutes les applications et du système d'exploitation des ordinateurs hôtes, et une sécurité du trafic réseau pour les applications existantes, sans avoir à les modifier. Pour plus d'informations, reportezvous à la section « Comparaison entre SSL/TLS et IPSec », plus loin dans ce chapitre. Conformité de cette solution avec les réglementations du gouvernement américain Le 16 décembre 2003, l'Office of Management and Budget (OMB) du gouvernement américain a publié un mémorandum sur l'« EAuthentication Guidance for Federal Agencies », disponible à l'adresse suivante : http://www.whitehouse.gov/omb/memoranda/fy04/m0404.pdf. Ce mémorandum indique que le niveau de risque d'une altération de l'authentification correspond au niveau auquel l'authentification électronique (eauthentification) est requise. La publication spéciale 80063 du NIST (National Institute of Standards and Technology) « Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology » (Guide de l'authentification électronique : recommandations du NIST), identifie les exigences techniques des niveaux d'authentification 14. Dans de nombreux cas, les niveaux élevés (3 et 4) d'authentification de l'utilisateur requièrent une réécriture ou un remplacement des applications. Si les risques de sécurité peuvent être réduits dans leur ensemble, vous pouvez utiliser une solution d'authentification de l'utilisateur moins onéreuse pour assurer l'accès aux informations très sensibles de votre organisation. Sur la plateforme Windows, les solutions d'isolation de serveurs et de domaines ajoutent une première couche d'authentification des ordinateurs approuvés, de contrôle d'accès, d'authentification du trafic réseau et de chiffrement, en amont de l'authentification de l'utilisateur au niveau de la couche application. Ainsi, l'utilisation d'une solution d'isolation de serveurs peut permettre de réduire ou de temporiser les modifications d'application requises et contribuer à répondre aux obligations en matière de gestion des risques. Pour être conforme aux réglementations gouvernementales relatives aux produits d'assurance des informations, la société Microsoft s'est engagée à suivre plusieurs processus de certification. Windows 2000 est certifié conforme aux critères communs pour l'évaluation de la sécurité des technologies de l'information (Common Criteria for IT Security Evaluation) (norme ISO 15408) niveau d'assurance 4 (EAL4), avec ALC_FLR.3 (Systematic Flaw Remediation). Cette certification s'applique aux systèmes d'exploitation et aux catégories de protection des données sensibles. Remarque : au moment de la rédaction de cet article, les platesformes Windows XP et Windows Server 2003 étaient en cours de certification. Les composants cryptographiques IPSec de Windows 2000, Windows XP et Windows Server 2003 sont certifiés et répondent aux exigences cryptographiques de la norme FIPS 1401. Ainsi, les solutions d'isolation de serveurs et de domaines peuvent être utilisées pour des applications militaires ou gouvernementales et dans des environnements informatiques associés. Pour plus d'informations, reportezvous aux liens suivants :
• NSTISSP No. 11 Fact Sheet: National
Information Assurance Acquisition Policy nstissp_11_revised_factsheet.pdf
, à l'adresse suivante : http://niap.nist.gov/ccscheme/
• Validated Products List (by Technology Type)
, à l'adresse suivante : http://niap.nist.gov/cc
scheme/vpl/vpl_type.html
• Overview: Windows 2000 Common Criteria Certification
, à l'adresse suivante : www.microsoft.com/technet/security/prodtech/Windows2000/ w2kccwp.mspx
22
• FIPS 140 Evaluation
, à l'adresse suivante : www.microsoft.com/technet/archive/security/topics/
issues/fipseval.mspx
Les informations de cette section concernent uniquement les organisations basées aux ÉtatsUnis. Toutefois, des réglementations connexes voient le jour dans le monde entier, comme en témoignent des lois telles que la directive européenne sur la protection des données (1988) et la loi canadienne sur la protection des renseignements personnels et les documents électroniques (PIPEDA), qui imposent toutes deux des instructions strictes concernant la gestion des identités et la confidentialité des données.
Évaluation des risques liés à l'infrastructure informatique L'évaluation des risques de l'entreprise consiste à identifier la dépendance entre l'entreprise et son infrastructure informatique. L'évaluation des risques de sécurité informatique consiste à identifier et à définir un ordre de priorité des risques liés à l'intégrité des informations et à la stabilité des services. L'évaluation des risques de sécurité doit justifier la nécessité de prévention de ces risques et évaluer les coûts liés à la nonanticipation de ces risques. Les évaluations des coûts jouent un rôle très important dans l'évaluation des différentes solutions techniques, et ce pour chaque problème. Étant donné qu'une seule solution ne permet pas d'éviter 100 % des risques, comparez les solutions et leurs différents coûts. Les décisionnaires peuvent, par exemple, évaluer le coût d'une solution d'isolation en termes de réduction des risques liés à un service dégradé ou interrompu suite à l'attaque d'un virus ou d'un vers. Pour certaines organisations, lorsqu'un pirate parvient à accéder à leurs données stratégiques, l'impact et les coûts résultant de l'attaque peuvent être dramatiques. Remarque : dans certains pays et dans certains états, la loi oblige les entreprises à informer leurs clients des violations de sécurité éventuelles dont ils pourraient être victimes. Pour obtenir des réponses aux questions juridiques relatives à votre organisation, contactez votre organisme public local ou un conseiller juridique. Les catégories suivantes peuvent vous aider à évaluer le coût total d'un incident de sécurité :
• Coût occasionné par une perte de service. Pour déterminer le coût total qu'occasionne une perte de service sur un serveur réseau, faites la somme des coûts suivants :
• Temps de réponse requis par le personnel de support en cas d'incident jklhl kjhlkj hkjlh lkjh kjlh kjh kjh ljkh • Manque à gagner suite à l'interruption de l'application • Perte de productivité interne
• Coût occasionné par le vol d'informations. Pour déterminer le coût total qu'occasionne le vol d'informations enregistrées sur un serveur réseau interne, faites la somme des coûts suivants :
• Perte de la propriété intellectuelle requise pour développer l'information • Perte des recettes à venir sur tous les produits, en raison d'une perte de confiance des clients (suite à la médiatisation du vol) • Perte de valeur marchande, en raison d'une perte de confiance des investisseurs (suite à la médiatisation du vol) • Temps de réponse requis en interne par les services de marketing et de développement • Perte de recettes éventuelles, en raison d'efforts de réponse en interne • Temps nécessaire pour limiter l'utilisation malveillante des informations à l'encontre de l'entreprise, des employés ou des clients
23
• Coût occasionné par la compromission des informations d'identification d'administration
sur le serveur. Pour déterminer le coût total qu'occasionne la compromission des informations d'identification d'administration sur un serveur réseau interne, faites la somme des coûts suivants : • Efforts requis en interne pour répondre à l'attaque et remplacer le serveur • Protection en interne des ordinateurs susceptibles d'être attaqués suite à la compromission des informations d'identification d'administration sur le serveur
• Coût occasionné par des mesures de réglementation ou des actions juridiques ultérieures. Pour déterminer le coût total qu'occasionnent les exigences d'une action en justice, faites la somme des coûts suivants :
• Coût d'une action en justice si l'attaquant a été identifié mais la décision de la cour vous est défavorable • Coût d'une action en justice si l'attaquant a été identifié et la décision de la cour vous est favorable, mais l'accusé est dans l'impossibilité de payer le montant des dommages • Coût des amendes, audits, restrictions et autres efforts visant à restaurer l'environnement de travail actuel
Investissement dans des solutions de sécurité des informations sur le long terme La protection de l'accès au réseau (NAP, Microsoft Network Access Protection) constitue un moyen efficace de contrôler si les périphériques qui se connectent au réseau ou les uns aux autres sont conformes aux stratégies. La mise en quarantaine des accès à distance et l'isolation de serveurs et de domaines sont deux moyens allant en ce sens et pouvant désormais être implémentés sous Windows 2000 et des platesformes ultérieures. En associant les atouts du périmètre et de l'isolation en interne, l'organisation est armée pour lutter contre les infections et tout autre type d'attaque lancés à partir d'ordinateurs non approuvés et découlant d'informations d'identification compromises. Pour plus d'informations sur l'initiative NAP, reportezvous à la page Network Access Protection site Microsoft à l'adresse : www.microsoft.com/nap.
du
Pour plus d'informations sur les réseaux privés virtuels (VPN) et le contrôle d'accès des quarantaines, reportezvous à la page Virtual Private Networks for Windows Server 2003 du site Microsoft à l'adresse : www.microsoft.com/vpn. Dans les prochaines versions de Windows, Microsoft prévoit de proposer une protection d'accès réseau encore plus facile à gérer et plus complète. Pour plus d'informations, reportezvous au Livre blanc « Introduction to Network Access Protection », à l'adresse : www.microsoft.com/windowsserver2003/techinfo/ overview/napoverview.mspx.
Identifications des ordinateurs approuvés L'approbation et le fonctionnement de l'approbation avec les ordinateurs est un point important de l'isolation de serveurs et de domaines. L' isolation permet à n'importe quel hôte approuvé de définir les personnes autorisées à accéder au réseau. Quel que soit le type de connexion établi entre les ordinateurs distants et l'extrémité distante de la connexion (par exemple, une connexion sans fil, de réseau local ou Internet), l'ordinateur distant doit utiliser IPSec pour négocier l'approbation et sécuriser le trafic TCP/IP de bout en bout avec l'ordinateur de destination. Ce modèle de sécurité de bout en bout offre un niveau de protection des communications réseau que ne proposent pas les autres technologies de sécurité et de contrôle d'accès réseau (par exemple, VPN, 802.1x, 802.11 WEP).
24
Pour empêcher le vol, l'altération ou l'utilisation malveillante des informations d'identification, il est primordial d'approuver d'abord l'ordinateur distant. Dans le cadre de cette solution, l'approbation permet à une organisation d'être presque certaine qu'un ordinateur est dans un état connu et qu'il répond aux exigences minimales de sécurité définies par l'organisation. Ces exigences peuvent être d'ordre technique, axées sur la sécurité, liées à l'activité professionnelle de l'entreprise ou à plusieurs de ces points. Ces exigences déterminent également l'état dans lequel doit se trouver un ordinateur avant d'établir une communication avec d'autres ordinateurs. Microsoft recommande que la spécification des ordinateurs approuvés inclue une liste à jour des mises à jour de sécurité et des services packs requis. Dans l'idéal, vous devez gérer et appliquer ces mises à jour via un système de gestion des correctifs tel que le service Windows Update ou Microsoft Systems Management Server (SMS). La fréquence d'application de ces mises à jour dépend de la durée nécessaire à votre organisation pour tester et déployer chaque mise à jour. Cependant, pour une sécurité optimale, vous devez appliquer les mises à jour de votre environnement dès que possible. Les ordinateurs non approuvés sont des ordinateurs susceptibles de ne pas répondre aux exigences de sécurité. En règle générale, un ordinateur n'est pas approuvé s'il n'est pas géré ou s'il n'est pas sécurisé. L'isolation de serveur et de domaine vise à limiter les risques qu'encourent les ressources approuvées de l'entreprise, en implémentant des outils, des technologies et des processus chargés de les protéger. La solution garantit que :
• seuls les ordinateurs approuvés (ceux qui répondent à des exigences de sécurité spécifiques) peuvent accéder à des ressources approuvées ;
• les ordinateurs non approuvés n'ont pas accès aux ressources approuvées, sauf si une raison professionnelle précise justifie de courir le risque.
Vous devez autoriser, par défaut, l'accès réseau aux ressources approuvées uniquement à partir d'autres ressources approuvées. Par ailleurs, vous devez contrôler l'accès à la couche réseau, en utilisant les fonctions d'accord ou de refus d'autorisation et les listes de contrôle d'accès (ACL) pour des utilisateurs et des ordinateurs spécifiques au sein de l'environnement approuvé. En créant cet environnement approuvé et en limitant les communications autorisées à l'intérieur et à l'extérieur de cet environnement, l'entreprise limite l'ensemble des risques qu'encourent ses données. Parmi les autres avantages métier figurent notamment les suivants :
• grande compréhension du flux des données dans des zones spécifiques du réseau ; • meilleure adoption des programmes de sécurité utilisés pour obtenir le statut « approuvé » ; • création d'un inventaire, à jour, des hôtes et périphériques réseau. Par exemple, dans le scénario Woodgrove Bank, les ordinateurs approuvés sont tous les ordinateurs qui exécutent Windows 2000 Service Pack (SP) 4, Windows XP SP2 ou une version ultérieure, ou Windows Server 2003 ou ultérieur dans l'un des domaines appartenant à la Woodgrove Bank et gérés par cette dernière. En outre, les ressources approuvées, notamment tous les ordinateurs (exécutant Windows 2000 ou une version ultérieure) qui utilisent des stratégies de groupe pour fournir des paramètres de sécurité, sont régulièrement examinées par le personnel informatique pour vérifier qu'elles restent conformes aux exigences minimales. Le personnel informatique examine également les ressources approuvées pour vérifier que l'installation et la configuration des logiciels de sécurité spécialisés (tel qu'un antivirus) sont contrôlées de façon centralisée selon les exigences de sécurité propres à la Woodgrove Bank. Pour plus d'informations sur l'identification des ordinateurs approuvés
25
dans le cadre de la solution, reportezvous à la section « Définition de l'approbation » du chapitre 3 « Détermination de l'état actuel de votre infrastructure informatique » de ce guide.
Ordinateurs non gérés Un ordinateur non géré est un ordinateur dont les paramètres de sécurité ne sont pas contrôlés de façon centralisée par le service informatique. En outre, tout ordinateur qui ne présente pas les fonctionnalités de gestion de sécurité requises est également considéré comme non géré. Les ordinateurs non gérés sont considérés comme non approuvés car l'organisation ne peut pas garantir qu'ils répondent aux exigences de sécurité des ordinateurs approuvés auxquels ils essaient d'accéder.
Ordinateurs non sécurisés Les ordinateurs non approuvés incluent également les ordinateurs qui exécutent un système d'exploitation qui n'est pas configuré, ou ne peut pas être configuré, pour atteindre le niveau de sécurité requis. Les ordinateurs non sécurisés peuvent entrer dans l'une des quatre catégories suivantes :
• Faible niveau de sécurité du système d'exploitation. Cette catégorie inclut les ordinateurs qui
exécutent un système d'exploitation ne possédant pas le niveau d'infrastructure de sécurité requis. Parmi ces systèmes d'exploitation figurent notamment : Windows 9x, Microsoft Windows NT® et Windows CE. En général, les fonctionnalités requises pour l'infrastructure de sécurité sont présentes dans les systèmes d'exploitation plus récents, comme Windows XP et Windows Server 2003. Ces fonctionnalités incluent : les contrôles d'accès (par exemple, les autorisations sur les fichiers), les fonctions de sécurité réseau de chiffrement des paquets, et d'authentification et d'autorisation renforcées, différents niveaux de privilège (utilisateur et administrateur), la prise en charge d'une gestion centralisée des paramètres de sécurité, la prise en charge permettant d'assurer la confidentialité et l'intégrité des données, et la prise en charge d'autres technologies de sécurité (comme le protocole d'authentification Kerberos et les services de certificats).
• Configuration incorrecte. Même les systèmes d'exploitation les plus fiables peuvent être configurés de façon incorrecte, et donc à la merci d'une attaque. Ces ordinateurs doivent également être considérés comme des périphériques non sécurisés.
• Absence d'un niveau de mise à jour requis. Comme la sécurité informatique est en constante
évolution, la plupart des éditeurs de logiciels proposent des mises à jour logicielles pour corriger les vulnérabilités de leurs produits. Une organisation peut définir un niveau minimum de mise à jour pour considérer un hôte comme approuvé. Dans ce cas, les ordinateurs qui ne possèdent pas le niveau de mise à jour requis sont considérés comme des périphériques non sécurisés.
• Ordinateurs approuvés pouvant être compromis. Il est possible qu'un ordinateur approuvé soit compromis, en général, par une personne malveillante à laquelle vous faisiez confiance. Lorsque la sécurité d'un ordinateur approuvé est compromise, l'ordinateur n'est plus considéré comme approuvé tant que cette situation de risque n'a pas été résolue. Comprenez bien que si vous n'avez pas confiance en l'utilisateur d'un ordinateur, vous ne pouvez pas avoir confiance en son ordinateur.
Les périphériques qui entrent dans l'une de ces quatre catégories sont considérés comme étant non approuvés car l'organisation n'a pas la certitude qu'ils n'ont pas été compromis d'une manière ou d'une autre. Ils représentent donc un risque significatif pour les ordinateurs approuvés auxquels ils tentent d'accéder.
26
Isolation de serveurs et de domaines : objectifs directement réalisables Avant toute chose, l'isolation de serveurs et de domaines vise à limiter les risques d'accès non autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. Avec les platesformes actuelles, l'isolation d'un ordinateur distant en limitant l'accès réseau entrant repose sur la possibilité d'authentifier avec succès un ordinateur comme membre du domaine par le biais du protocole de négociation de sécurité IKE (Internet Key Exchange) d'IPSec. L'authentification de l'utilisateur intervient uniquement une fois l'authentification de l'ordinateur réussie et lorsque les associations de sécurité IPSec protègent toutes les connexions d'applications et de protocoles de niveau supérieur entre deux ordinateurs. L'isolation de serveurs et de domaines vous permet donc d'atteindre les objectifs suivants :
• Isoler les ordinateurs membres du domaine approuvé des périphériques non approuvés au niveau du réseau.
• Vérifier que l'accès réseau entrant à un membre du domaine approuvé sur le réseau interne requiert l'utilisation d'un autre membre du domaine approuvé.
• Autoriser les membres du domaine approuvé à limiter l'accès réseau entrant à un groupe spécifique d'ordinateurs membres du domaine.
• Concentrer les risques d'attaque sur un petit nombre d'hôtes, constituant une barrière de protection du domaine approuvé, où les stratégies de minimisation des risques maximum (journalisation, surveillance, détection d'intrusion, etc.) peuvent être appliquées de façon plus efficace.
• Mettre l'accent et la priorité sur la surveillance proactive et les efforts de conformité avant toute attaque.
• Se concentrer sur les efforts de réparation et de récupération, avant, pendant et après toute attaque, et être plus rapide sur ces points.
• Améliorer la sécurité en ajoutant l'authentification mutuelle par paquet renforcée, l'intégrité, l'anti relecture et le chiffrement, sans avoir à modifier les applications et les protocoles de niveau supérieur, tels que SMB (Server Message Block) ou NetBT.
L'isolation de serveurs et de domaines vise à protéger tous les services réseau sur l'hôte approuvé contre toute attaque ou accès réseau non approuvé. L'isolation de serveurs et de domaines rend les hôtes moins vulnérables aux failles et aux erreurs présentes dans d'autres types de sécurité réseau, et aux failles de protection des informations d'identification de l'utilisateur. Enfin, les solutions d'isolation de serveurs et de domaines permettent d'éviter des menaces réseau similaires, mais elles fournissent des niveaux de contrôle d'accès réseau et de protection du trafic différents de ceux des autres types de technologie de sécurité réseau. Par exemple, une solution d'isolation de serveurs et de domaines peut autoriser l'accès entrant à des ordinateurs hôtes approuvés spécifiques en fonction de l'identité du domaine de l'utilisateur et de l'hôte, ce qui garantit la protection de bout en bout de la communication autorisée. Les autres technologies de sécurité réseau, quant à elles, ne prennent généralement en charge que l'identité de l'utilisateur.
Isolation de serveurs et de domaines : risques évités Le tout premier risque que permet d'éviter l'isolation de serveurs et de domaines est celui de l'accès non autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. La solution seule ne permet pas de limiter complètement tous les risques de sécurité. Si ces risques de sécurité ne sont pas pris en charge par des processus et technologies de sécurité complémentaires, il est possible que vous ne tiriez pas parti des avantages de la solution d'isolation. Il existe plusieurs risques de sécurité graves que cette solution ne permet pas d'éviter directement, par exemple :
27
• Risque de vol ou de divulgation de données sensibles par des utilisateurs approuvés. La
solution d'isolation permet de contrôler les communications des ordinateurs au sein du réseau interne, mais les administrateurs peuvent compromettre ce contrôle. Cette solution ne permet pas de réduire le risque qu'un utilisateur approuvé copie ou divulgue des données sensibles.
• Risque de compromission des informations d'identification des utilisateurs approuvés. Pour protéger les informations de connexion réseau, un administrateur peut décider de chiffrer la plus grande partie du trafic IPSec, mais la protection IPSec du trafic d'ouverture de session utilisateur vers les contrôleurs de domaine n'est pas prise en charge. L'isolation de serveurs et de domaines peut obliger une personne malveillante à utiliser un hôte approuvé pour attaquer d'autres hôtes approuvés. Une personne malveillante peut également attaquer des hôtes approuvés en utilisant des informations d'identification compromise d'hôtes qui sont dispensés d'utiliser IPSec avec des hôtes approuvés (par exemple, des contrôleurs de domaine et des serveurs DNS) ou d'hôtes qui acceptent des connexions entrantes d'ordinateurs non approuvés. Un administrateur peut déterminer si les hôtes approuvés communiquent vers l'extérieur, vers des hôtes non approuvés, mais la solution ne permet pas de limiter le risque qu'un utilisateur approuvé perde ses informations d'identification en se laissant abuser par un attaquant l'ayant incité à divulguer son mot de passe.
• Utilisateurs malveillants. Cette catégorie inclut les utilisateurs légitimes qui profitent de leurs
droits d'accès. Par exemple, cette solution ne permet pas de réduire le risque qu'un utilisateur contrarié décide de voler des informations en utilisant les hôtes approuvés auxquels son poste dans l'entreprise lui donne accès. L'accès physique à un ordinateur hôte approuvé peut permettre à une personne malveillante d'obtenir un accès non autorisé et administratif à cet hôte. Comme les administrateurs peuvent désactiver la protection d'isolation de serveurs et de domaines, il est primordial de limiter l'accès et le nombre d'administrateurs (y compris les administrateurs de l'entreprise, les administrateurs de domaine et les administrateurs locaux sur des stations de travail ou des serveurs membres).
• Risque que des ordinateurs non approuvés accèdent à d'autres ordinateurs non approuvés. Cette solution ne permet pas de limiter le risque que des ordinateurs non approuvés utilisés par une personne malveillante s'en prennent à d'autres ordinateurs non approuvés.
• Risque que des ordinateurs non approuvés attaquent certains ordinateurs approuvés. Les
solutions d'isolation de serveurs et de domaines sont conçues pour protéger les hôtes approuvés. Cependant, pour des raisons pratiques de déploiement, cette solution identifie les membres du domaine approuvés qui, pour diverses raisons, n'ont pas recours à IPSec pour négocier un accès approuvé à d'autres hôtes approuvés. Ces ordinateurs approuvés, mais nonIPSec, font partie d'une liste d'exemptions (par exemple, les contrôleurs de domaine). Cette solution identifie également des hôtes approuvés auxquels peuvent accéder des ordinateurs non approuvés pour fournir des services de limite pour le domaine d'isolation. Une personne malveillante qui parvient à obtenir le contrôle d'un hôte exempté ou d'un hôte de limite peut attaquer tous les autres hôtes approuvés se trouvant dans le domaine d'isolation.
• Garantie que les hôtes approuvés sont conformes aux exigences de sécurité. Cette solution donne des conseils sur la définition de l'approbation des hôtes et requiert surtout qu'ils soient membres d'un domaine Windows 2000 ou Windows Server 2003. Cette solution dépend uniquement de la réussite de l'authentification IPSec IKE basée sur le domaine (Kerberos) pour établir l'approbation et la connectivité protégée par IPSec. Avec le temps, les hôtes approuvés peuvent, pour diverses raisons, ne plus répondre totalement aux critères exigés des hôtes approuvés mais être toujours en mesure de s'authentifier avec succès comme membres du domaine. Les systèmes et processus de gestion informatique de l'organisation doivent s'assurer que les membres du domaine sont conformes à la définition des hôtes approuvés.
Pour résoudre ces problèmes, les configurations et modèles recommandés de renforcement de la sécurité ont été appliqués à tous les systèmes dans l'environnement de laboratoire de la Woodgrove Bank. Pour plus d'informations sur les procédures de gestion et les technologies de
28
sécurité de la plateforme Windows, reportezvous à la page TechNet Security Resource Center du site Web Microsoft, à l'adresse : www.microsoft.com/technet/security/.
Comment l'isolation de serveurs et de domaines s'intègretelle dans ma stratégie de sécurité réseau globale ? L'isolation de serveurs et de domaines est utilisée en complément d'autres mécanismes préventifs et réactifs pour protéger le réseau et les périphériques qui y connectés, y compris les ordinateurs. Comme la sécurité est un problème complexe nécessitant une protection à plusieurs couches, il peut être utile de rappeler en quoi consiste une protection renforcée, ainsi que les concepts importants qui y sont rattachés. Une stratégie de sécurité réseau complète applique les technologies appropriées pour réduire les risques les plus importants sans dépendance significative visàvis des points de défaillance uniques. Par exemple, si le périmètre de sécurité échoue suite à une configuration incorrecte ou à l'intervention d'un employé malveillant, quelle autre couche de protection peut empêcher les hôtes approuvés internes de subir des infections et attaques réseau ? Qu'estce qui pourrait permettre de bloquer des attaques ciblant les hôtes approuvés d'Europe et d'Asie, alors que la personne malveillante est connecté à un port Ethernet, dans une salle de réunion de n'importe quel bureau américain ?
Protection renforcée La protection renforcée peut être définie comme une approche par couche permettant de protéger un ordinateur, au lieu de se fier à un dispositif de protection unique. Pour mettre en place des couches de protection efficaces, il est indispensable d'identifier avant tout les sources d'infection et les adversaires susceptibles d'attaquer une organisation, ainsi que leurs cibles potentielles. Par exemple, un adversaire peut être un concurrent louant les services d'une société d'espionnage industriel pour subtiliser des informations sur un nouveau produit ou un nouveau service en cours de développement. Lorsque vous avez cerné vos adversaires potentiels et leurs cibles probables, vous devez appliquer des procédures de réponse aux incidents pour les ordinateurs susceptibles d'être compromis. L'authentification, l'autorisation, la confidentialité et la nonrépudiation comptent notamment parmi ces méthodes. Une organisation qui respecte la pratique recommandée protectiondétectionréaction prend conscience que des attaques peuvent survenir et comprend que la détection anticipée de ces attaques et la réduction des interruptions de service ou des pertes de données sont primordiales. Étant donné que les probabilités d'attaque sont élevées, la méthode protectiondétectionréaction permet de comprendre qu'il est nécessaire de concentrer davantage les efforts sur la protection des données et des ressources plutôt que sur la prévention des attaques. En règle générale, il est plus rentable de se protéger d'une attaque que de réparer les dégâts qu'elle peut occasionner. Tous les dispositifs de protection des informations mettent l'accent sur les personnes, les processus et les technologies. L'isolation tient compte de l'ensemble de ces trois facteurs : elle se réalise via une identification précise des risques, des exigences et des ressources à protéger. Cette identification englobe les facteurs « personnes » et « processus ». En outre, l'isolation requiert des connaissances sur l'état actuel du réseau et de ses périphériques, sur les exigences de communication qui définissent l'interaction entre ordinateurs, et sur les exigences de sécurité qui risquent de limiter les exigences visant à obtenir le parfait équilibre entre sécurité et communication. Pour plus d'informations sur ce sujet reportezvous au Livre blanc « Defense in Depth renforcée) de la NSA (National Security Agency), à l'adresse : http://www.nsa.gov/snac/support/defenseindepth.pdf.
29
» (protection
Pour plus d'informations et des exemples pratiques pour l'exécution de ce processus, reportezvous au chapitre Enterprise Design (Configuration entreprise) du guide Windows Server System Reference Architecture (Architecture de référence des systèmes de serveurs Windows) sur le site Web de Technet, à l'adresse www.microsoft.com/technet/itsolutions/wssra/ raguide/Security_Architecture_1.mspx. La figure suivante illustre l'intégration d'une solution d'isolation logique dans une approche de protection renforcée utilisée dans l'architecture de référence des systèmes de serveurs Windows :
Figure 2.1 Protection renforcée avec l'isolation logique
Dans cette figure, il est important de comprendre que la couche de sécurité de l'isolation logique sécurise directement l'ordinateur hôte via le contrôle des communications réseau. Il s'agit d'un rôle très similaire à celui d'un parefeu pour hôte. Toutefois, au lieu d'autoriser et de bloquer les services sur les ports comme un parefeu pour hôte, IPSec autorise et bloque les services et négocie les services d'accès réseau approuvés. Une fois l'accès accordé, IPSec peut sécuriser tous les paquets entre les deux ordinateurs. Comme indiqué dans le cadre de cette solution, une solution d'« isolation logique » telle que l'isolation de serveurs et de domaines :
• ne sécurise pas les périphériques réseau, comme les routeurs ; • n'offre pas un contrôle d'accès réseau physique (ex. : définition des ordinateurs autorisés à établir une connexion VPN d'accès à distance) ou les protections que proposent les parefeu réseau ;
• ne sécurise pas les liaisons réseau, telles que 802.1x pour les contrôles d'accès et le
chiffrement 802.11 WEP pour les liaisons sans fil. IPSec offre toutefois une protection de bout en bout sur toutes les liaisons réseau entre l'adresse IP source et l'adresse IP de destination ;
30
• ne sécurise pas l'ensemble des hôtes sur le réseau, mais uniquement ceux qui sont inclus dans la solution d'isolation ;
• ne sécurise pas les chemins du niveau application, tels que le chemin de bout en bout via lequel
sont acheminés les messages électroniques et .NET, ni les requêtes HTTP (Hypertext Transmission Protocol) pouvant être en proxy à plusieurs reprises entre le client et la destination du serveur Web.
Vous devez considérer la sécurité au niveau de chaque couche comme une partie intégrante de l'analyse de réduction des risques de sécurité informatique. Par exemple, si un ordinateur n'est pas autorisé à accéder à un serveur au niveau de la couche d'isolation logique, l'utilisateur qui se connecte à cet ordinateur importe peu. Tous les utilisateurs, même les administrateurs, se verront refuser l'accès au serveur.
Comparaison entre SSL/TLS et IPSec IPSec n'est pas destiné à remplacer la sécurité de niveau application, telle que SSL/TLS. L'un des principaux avantages d'IPSec est qu'il permet de sécuriser le trafic réseau pour les applications existantes, sans avoir à les modifier. L'utilisation d'IPSec dans des environnements dans lesquels des applications utilisent SSL/TLS offre les avantages suivants :
• Il aide à protéger l'ensemble des applications et le système d'exploitation des attaques lancées depuis des ordinateurs non approuvés et d'autres périphériques.
• Il met en place une protection renforcée contre toute utilisation inappropriée ou non conforme de SSL/TLS (par exemple, si toutes les données eHPI ne sont pas chiffrées et authentifiées).
• Il contribue à empêcher la saisie des informations d'identification de l'utilisateur sur des ordinateurs non approuvés, car les utilisateurs ne sont pas invités à se connecter à un site Web SSL/TLS interne tant qu'IPSec établit une approbation mutuelle entre le client et le serveur.
• Il offre une sécurité lorsque vous ne pouvez pas utiliser les paramètres du registre de Windows
pour sélectionner des algorithmes SSL/TLS conformes à la réglementation. Windows 2000, Windows XP et Windows Server 2003 fournissent des contrôles de clé de registre pour les algorithmes SSL/TLS, présentés dans l'article 245030 « How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll » (Comment limiter l'utilisation de certains protocoles et algorithmes de chiffrement dans Schannel.dll) de la Base de connaissances Microsoft, à l'adresse suivante : http://support.microsoft.com/?kbid=245030.
• Il offre une sécurité lorsque les certificats ne sont pas disponibles. IPSec sécurise le trafic entre les adresses IP source et de destination. SSL/TLS peut sécuriser le trafic sur tout le chemin de l'application (par exemple, d'un navigateur Web, via un proxy Web, vers un serveur Web). L'institut NIST (National Institute for Standards and Technology) développe actuellement un guide d'utilisation de TLS. La publication spéciale 80052, « Guidelines on the Selection and Use of Transport Layer Security » (Guide de sélection et d'utilisation de TLS) est un guide sur l'implémentation de TLS dans un gouvernement fédéral. Pour plus d'informations sur ce guide, reportezvous au site Web de la NIST Computer Security Division , à l'adresse http://csrc.nist.gov/publications/index.html. Il n'existe pas de guide similaire pour l'utilisation d'IPSec. Toutefois, la NSA a publié des guides sur l'utilisation d'IPSec avec Windows 2000. Ces guides sont disponibles sur le site Web de la NSA , à l'adresse http://nsa2.www.conxion.com/win2k/download.htm. Les organisations qui sont dans l'obligation de se conformer aux recommandations de la NSA doivent analyser cette solution et consulter les guides de la NSA.
31
IPSec avec l'authentification par certificat offre une protection similaire à SSL/TLS, à quelques différences près. Windows IPSec prend en charge un petit sousensemble des algorithmes de chiffrement gérés par TLS et recommandés dans la publication spéciale 80052 de la NIST (par exemple, 3DES, SHA1 et DiffieHellman éphémère 1024 bits). La solution présentée dans ce guide utilise les signatures de protocole Kerberos pour l'authentification IKE entre membres du domaine, et non les signatures basées sur les certificats. La négociation IKE Windows IPSec établit l'approbation mutuelle entre les ordinateurs qui utilisent le protocole Kerberos et l'authentification basée sur les certificats. Comme l'authentification IKE n'est pas intégrée dans les applications, elle ne peut pas vérifier si le nom de l'ordinateur de destination correspond bien à celui de l'ordinateur auquel doit se connecter l'application. De ce fait, une attaque du type « maninthemiddle » lancée depuis un autre hôte approuvé peut avoir lieu. Mais comme l'application s'intègre à SSL/TLS, le nom de l'ordinateur de destination est authentifié (approuvé) et peut également être comparé au nom de l'ordinateur auquel doit se connecter l'application.
Rappel terminologique Avant de poursuivre ce chapitre, il peut être intéressant de revoir certains termes qui sont souvent utilisés dans le cadre de cette solution. Si vous connaissez déjà la signification de ces termes, vous pouvez passer directement à la section suivante. En revanche, si vous ne connaissez pas vraiment ces termes, vous risquez de ne pas bien comprendre certaines explications fournies dans ce guide.
Termes relatifs à l'isolation Les termes suivants sont uniquement employés pour le concept d'isolation logique. Assurezvous de bien comprendre ces termes avant de poursuivre la lecture de ce chapitre :
• Isolation. Séparation logique entre un ou plusieurs ordinateurs et d'autres ordinateurs. • Isolation de domaines. Ce terme définit le type d'isolation qui vise à séparer les ordinateurs
approuvés des ordinateurs non approuvés. Pour être isolé, un ordinateur doit posséder des informations d'identification valides et être authentifié avec succès via IKE. Le domaine peut être n'importe quel domaine dans le chemin d'accès à l'approbation, accessible via une approbation bidirectionnelle entre les deux hôtes tentant de sécuriser leurs communications.
• Isolation de serveurs. Ce terme définit la manière dont les serveurs peuvent limiter l'accès entrant à un groupe spécifique d'ordinateurs approuvés, en utilisant IPSec et l'autorisation « Accéder à cet ordinateur à partir du réseau ».
• Isolation logique. Il s'agit d'un terme plus général utilisé pour les technologies d'isolation. Il peut notamment inclure l'isolation de domaines, l'isolation de serveurs et la protection de l'accès au réseau (NAP) pour isoler des ordinateurs au niveau de la couche réseau.
• Groupe d'isolation. Regroupement logique d'ordinateurs hôtes approuvés partageant les mêmes
stratégies de sécurité des communications, notamment et principalement les mêmes exigences en termes de trafic réseau entrant et sortant. Vous pouvez implémenter les contrôles d'accès entrant et sortant d'un groupe d'isolation à l'aide d'une stratégie IPSec en utilisant des actions autoriser/bloquer, ou en faisant en sorte qu'IPSec négocie la sécurité conjointement avec les droits de connexion réseau de la stratégie de groupe (et éventuellement avec d'autres paramètres de configuration ou de connexion réseau). Les applications, services réseau et protocoles doivent bénéficier d'une configuration spécifique pour répondre aux exigences de trafic au niveau de leur couche. Par exemple, un groupe de serveur Exchange requiert qu'un ordinateur client ou serveur soit membre du domaine pour établir une connexion TCP/IP entrante. Ce groupe, qui n'est pas autorisé à établir des connexions TCP/IP sortantes vers des membres n'appartenant pas au domaine (sauf certaines exceptions) est appelé groupe d'isolation Exchange Server.
32
• Domaine d'isolation. Il s'agit d'un groupe d'isolation dans lequel les membres du groupe sont les
mêmes que ceux du domaine Windows. Si le domaine possède des domaines approuvés bidirectionnels, les membres de ces domaines appartiennent au domaine d'isolation. Comme dans un groupe d'isolation, les exigences en termes de trafic réseau entrant et sortant sont simples : les connexions entrantes ne peuvent provenir que d'autres membres du domaine de l'hôte approuvé. Un serveur placé dans le groupe d'isolation de serveurs peut avoir des clients qui appartiennent au domaine isolé.
• Groupe d'accès réseau. Ce terme fait référence au groupe de sécurité de domaine de Windows, utilisé pour contrôler l'accès réseau à un ordinateur, en utilisant des paramètres de sécurité de stratégie de groupe pour les droits de connexion réseau. Ces paramètres sont créés pour appliquer les exigences d'accès entrant pour les groupes d'isolation. Chaque groupe d'isolation peut comprendre un groupe d'accès réseau autorisé (ANAG, Allow network access group) et un groupe d'accès réseau refusé (DNAG, Deny network access group).
• Approbation. Ce terme est utilisé pour définir le fait qu'un ordinateur accepte l'identité validée via
le processus d'authentification. L'approbation de domaine implique que tous les membres du domaine approuvent le contrôleur de domaine pour établir l'identité et fournir correctement les informations d'appartenance au groupe à cette identité. L'approbation est nécessaire pour communiquer avec un ordinateur distant en utilisant IPSec. L'approbation signifie également qu'un utilisateur ou un ordinateur est considéré comme un élément avec lequel il est possible de communiquer et ne présentant vraisemblablement qu'un faible risque de menace.
• Hôte de confiance. Ce terme désigne un ordinateur susceptible d'être configuré pour répondre
aux exigences de sécurité minimales d'une organisation, mais pouvant être, ou non, un hôte approuvé. Il est primordial de connaître les ordinateurs dignes de confiance lors de la planification des membres d'un groupe d'isolation approuvé.
• Hôte approuvé. Ce terme fait référence à une plateforme exécutant Windows 2000, Windows XP
ou Windows Server 2003, appartenant au moins à un domaine de sécurité de Windows 2000 et capable d'appliquer une stratégie IPSec. Les hôtes approuvés sont en général définis pour répondre à des exigences de gestion et de sécurité supplémentaires. La configuration de l'hôte est contrôlée de façon à ce que les risques de sécurité de l'hôte soient faibles et gérables. Les hôtes approuvés sont moins susceptibles d'être à l'origine d'une infection ou d'un acte malveillant. Pour plus d'informations à ce sujet, reportezvous au chapitre 3 de ce guide « Détermination de l'état actuel de votre infrastructure informatique ».
• Hôte non approuvé. Ordinateur hôte qui n'est pas un hôte approuvé. Cet ordinateur possède une configuration inconnue ou non gérée. Il ne peut être garanti que l'hôte (ou utilisateur de l'hôte) ne sera pas à l'origine d'une source d'infection ou d'un acte de malveillance en cas de connexion au réseau.
• Hôte de limite. Hôte approuvé qui est exposé au trafic réseau d'hôtes approuvés et non
approuvés. Il doit par conséquent faire l'objet d'une surveillance plus étroite et être doté de moyens de protection plus importants que les autres hôtes approuvés pour lutter contre les attaques. Il doit y avoir le minimum d'hôtes de limite possible car ces derniers constituent une menace importante pour les autres hôtes approuvés.
• Exemption. Ordinateur faisant partie ou non d'un domaine et n'utilisant pas IPSec. Il existe deux
types d'exemptions. Nous avons, d'une part, les ordinateurs qui utilisent une adresse IP statique dont les adresses sont incluses dans la « liste d'exemptions », de sorte que les hôtes approuvés n'utilisent pas IPSec avec ces ordinateurs. Et d'autre part, nous avons les ordinateurs exemptés d'utiliser la stratégie IPSec pour négocier des connexions sécurisées. Cette dernière catégorie peut apparaître ou non dans la liste d'exemptions. Une exemption peut répondre aux exigences d'un hôte approuvé, mais n'utilise pas la protection IPSec pour communiquer avec les autres hôtes approuvés du domaine d'isolation.
Termes relatifs à la sécurité 33
Assurezvous de bien comprendre les termes suivants :
• Autorisation. Il s'agit d'une autorisation accordée à une personne, un ordinateur, un processus ou un périphérique pour accéder à des informations, des services ou des fonctionnalités spécifiques. L'autorisation est octroyée selon l'identité de la personne, de l'ordinateur, du processus ou du périphérique demandant l'accès. Cette identité est vérifiée lors de l'authentification.
• Authentification. Il s'agit d'un processus de validation des informations d'identification d'une
personne, d'un processus informatique ou d'un périphérique. Pour être authentifié(e), la personne, le processus ou le périphérique effectuant cette requête doit fournir une représentation des informations permettant de prouver son identité. Les informations d'identification les plus courantes sont les clés privées pour les certificats numériques, un secret configuré par l'administrateur sur deux périphériques (clé prépartagée), un mot de passe secret de connexion de l'utilisateur ou de l'ordinateur au domaine, ou un élément biologique tel qu'une empreinte digitale ou une analyse rétinienne.
• Usurpation. Dans ce guide, l'usurpation désigne l'attaque consistant à usurper l'identité d'une
adresse IP autorisée dans le but d'interrompre les communications ou d'intercepter des données.
• Nonrépudiation. Cette technique est utilisée pour garantir qu'une personne effectuant une action
sur un ordinateur ne peut nier qu'elle a effectué cette action. La nonrépudiation offre la preuve irréfutable qu'un utilisateur ou un périphérique a effectué une action spécifique comme un transfert d'argent, une autorisation d'achat ou l'envoi d'un message.
• Texte chiffré. Il s'agit des données qui ont été chiffrées. Le texte chiffré est le résultat du
processus de chiffrement. Il peut retrouver une forme lisible (en texte clair) grâce à la clé de déchiffrement appropriée.
• Texte clair (ou texte en clair). Il s'agit des communications et des données dans leur format non chiffré.
• Hachage. Il s'agit d'un résultat de taille fixe obtenu en appliquant une fonction mathématique
unidirectionnelle (parfois appelée algorithme de hachage) à un volume arbitraire de données d'entrée. En cas de modification des données d'entrée, le hachage change. Les fonctions de hachage sont choisies de sorte que la probabilité que deux entrées produisent le même résultat de hachage soit extrêmement faible. Le hachage peut être utilisé dans de nombreuses opérations, notamment dans l'authentification et la signature numérique. Il est également appelé « résumé du message ».
Termes relatifs au réseau Les termes suivants font référence aux éléments réseau de cette solution :
• Initiateur. Ordinateur qui initialise la communication réseau avec un autre ordinateur. • Répondeur. Ordinateur qui répond à la demande de communication sur le réseau. • Chemin de communication. Chemin de connexion mis en place pour le trafic réseau qui a lieu entre un initiateur et un répondeur.
Termes relatifs aux stratégies de groupe Les termes suivants sont associés aux stratégies de groupe de Windows :
• GPO (ou objet de stratégie de groupe). Les paramètres de stratégie de groupe que vous créez se trouvent dans un objet de stratégie de groupe (GPO). En associant un GPO aux conteneurs système d'Active Directory sélectionnés (sites, domaines et unités d'organisation (UO)), vous 34
pouvez appliquer les paramètres de stratégie de l'objet de stratégie de groupe aux utilisateurs et ordinateurs présents dans ces conteneurs Active Directory. Pour créer un GPO, utilisez l'Éditeur d'objets de stratégie de groupe, et la console de gestion des stratégies de groupe pour gérer les GPO au sein d'une entreprise.
• Stratégie de domaine. Stratégie stockée de façon centralisée dans Active Directory. • Stratégie locale. Stratégie stockée sur un ordinateur.
Termes élémentaires relatifs à IPSec Assurezvous de bien comprendre les termes suivants :
• Stratégie de sécurité IP. Ensemble des règles de sécurité permettant de traiter le trafic réseau au niveau de la couche IP. Une règle de sécurité contient des filtres de paquets associés aux actions autoriser, bloquer ou négocier. Lorsque la négociation est requise, la stratégie de sécurité IP contient des méthodes d'authentification et de sécurité qui lui permettent de négocier avec l'ordinateur homologue.
• Stratégie de sécurité IP persistante. Type de sécurité IP introduit dans Windows XP et
Windows Server 2003, permettant d'appliquer les paramètres de stratégie IPSec de façon persistante. La stratégie persistante s'applique d'abord au démarrage du service IPSec, afin de pouvoir remplacer les paramètres de la stratégie IPSec locale ou du domaine.
• Négociation IKE. Processus qui a lieu au lancement d'une connexion réseau, pour déterminer si un ordinateur utilisant IPSec autorise la connexion.
• Associations de sécurité. Accords définis entre deux hôtes concernant la façon d'utiliser IPSec pour communiquer et les divers paramètres qui définissent cette négociation.
• Associations de sécurité en mode principal. Ces associations de sécurité sont établies avant les autres lors de la négociation IKE entre l'initiateur et le répondeur.
• Associations de sécurité en mode rapide. Ces associations sont négociées une fois les
associations de sécurité en mode principal établies pour chaque session de communication entre les hôtes.
• Communiquer en texte clair. Cette option permet à un initiateur IKE d'autoriser un trafic TCP/IP
normal (nonIKE ou nonIPSec) si le répondeur ne renvoie pas de réponse IKE. Il s'agit de l'option Autoriser une communication non sécurisée avec un ordinateur qui n'utilise pas IPSec disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie IPSec.
• Relais entrant. Cette option autorise un ordinateur IPSec à accepter un paquet entrant TCP/IP
normal (nonIKE ou nonIPSec) d'un ordinateur distant. La réponse normale du protocole de niveau supérieur est un paquet sortant qui lance une initiation IKE vers l'ordinateur distant. Il s'agit de l'option Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec, disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie IPSec.
Remarque : Si le relais entrant est activé, mais que l'option Communiquer en texte clair n'est pas activée sur un répondeur, celuici ne parviendra pas à communiquer avec un initiateur qui n'utilise pas IPSec. Il est également très important de comprendre les termes spécifiques aux éléments d'IPSec. L'annexe A, « Présentation des concepts relatifs à la stratégie IPSec », de ce guide définit les termes relatifs à IPSec et explique le processus IPSec global que les ordinateurs des groupes d'isolation créés dans cette solution vont utiliser.
35
Comment l'isolation de serveurs et de domaines peutelle être mise en place ? L'idée d'isoler les ordinateurs des risques n'a rien de nouveau. L'utilisation de parefeu pour permettre la segmentation, la mise en place de filtres et de contrôles d'accès au niveau des routeurs et la segmentation physique du trafic réseau font partie des techniques qui fournissent un niveau d'isolation. La solution présentée dans ce guide est conçue pour fonctionner avec les techniques et périphériques existants de votre infrastructure réseau. Pour implémenter l'isolation, il faut apporter des modifications au logiciel hôte existant dans Windows 2000 et sur des platesformes ultérieures. Les technologies et procédures telles que la segmentation réseau, les réseaux locaux virtuels (VLAN), les contrôles d'accès au réseau de périmètre, la mise en quarantaine réseau et la détection d'intrusions dans le périmètre du réseau peuvent être mises en place en implémentant ou en modifiant la configuration des périphériques réseau. L'isolation de serveurs et de domaines complète l'ensemble de ces techniques existantes et offre un niveau de protection supplémentaire pour les membres du domaine Windows gérés. Les administrateurs du système informatique Windows peuvent implémenter l'isolation de serveurs et de domaines en ne modifiant que très peu, voire pas du tout, les méthodes de connexion et chemins d'accès existants, les applications, et avec une infrastructure de domaine Windows 2000 ou Windows Server 2003 existante.
Composants de l'isolation de serveurs et de domaines L'isolation de serveurs et de domaines intègre des composants importants qui, ensemble, constituent la solution. Les soussections ciaprès présentent ces composants. Hôtes approuvés Les hôtes approuvés sont des ordinateurs que l'organisation informatique peut gérer pour répondre aux exigences minimales de sécurité. En général, vous pouvez obtenir le statut « approuvé » uniquement si l'ordinateur exécute un système d'exploitation fiable et géré, un antivirus et les mises à jour les plus récentes des applications et du système d'exploitation. Une fois l'ordinateur identifié comme « approuvé », le composant suivant de la solution est chargé de confirmer le statut de l'ordinateur, via l'authentification. Pour plus d'informations sur l'identification de l'état, reportezvous au chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique ». Remarque : IPSec n'est pas capable de déterminer si un ordinateur est conforme aux critères d'un hôte donné. Une technologie de surveillance est requise pour déterminer la configuration élémentaire d'un ordinateur et signaler toute modification de cette configuration. Authentification de l'hôte Le mécanisme d'authentification de l'hôte permet de déterminer si l'ordinateur qui tente de lancer une session possède des informations d'authentification valides, telles que les informations d'identification du ticket Kerberos, un certificat ou une clé prépartagée. À l'heure actuelle, deux technologies permettent de réaliser ce type d'authentification pour les ordinateurs Windows. Les sections ciaprès présentent ces deux technologies. Le protocole 802.1X Le protocole 802.1X est un protocole d'authentification des utilisateurs et des périphériques basé sur des standards. Il autorise ou non la connexion via un port réseau de couche de liaison, tel qu'une
36
connexion sans fil 802.11ou un port Ethernet 802.3. Il permet de contrôler les opérations des utilisateurs (à des fins de facturation), les autorisations et d'autres fonctions. Ce protocole requiert un ou plusieurs serveurs dédiés, par exemple, le service RADIUS (Remote Authentication DialIn User Service), et une infrastructure réseau qui prend en charge le protocole. Le protocole 802.1X est conçu pour permettre de contrôler l'accès réseau et les clés de chiffrement pour le chiffrement WEP (Wired Equivalent Privacy) 802.11 du trafic sans fil entre le client et le point d'accès sans fil. Lorsque le périphérique est autorisé à accéder au réseau, il bénéficie en général d'un accès à l'ensemble du réseau interne. Les données sont déchiffrées au point d'accès sans fil, puis transférées au format TCP/IP normal en texte clair vers leur destination, susceptible d'être sécurisée par divers mécanismes de couche application. La sécurité de la Woodgrove Bank requiert la protection de tous les hôtes approuvés contre les ordinateurs non approuvés du réseau interne. Le protocole 802.1X pourrait imposer que seuls les ordinateurs approuvés bénéficient d'un accès via une connexion sans fil ou filaire, mais les commutateurs utilisés pour la plupart des ports Ethernet 802.3 internes ne peuvent pas effectuer l'authentification 802.1X. Un coût non négligeable d'achat matériel et d'installation aurait pu être requis pour mettre à niveau toutes les prises LAN murales physiques et tous les bureaux répartis dans les différents pays. La Woodgrove Bank a décidé d'utiliser le protocole 802.1X pour la sécurité sans fil, mais pas pour les ports Ethernet câblés. Une des autres exigences de sécurité de la Woodgrove Bank consistait à chiffrer le trafic de bout en bout entre les clients approuvés et les serveurs de chiffrement. Le protocole 802.1X n'a pas été mis au point pour permettre le chiffrement des connexions câblées, mais uniquement celui des connexions sans fil. Même lorsque les connexions sans fil sont chiffrées, les données ne sont pas protégées lorsque les paquets sont transférés sur le réseau local interne, après avoir été déchiffrés par le point d'accès sans fil. Par conséquent le protocole 802.1X ne permet pas de répondre à l'exigence de chiffrement de bout en bout. Bien que le protocole 802.1X ne permette pas de répondre à l'ensemble des exigences de la Woodgrove Bank, il est toutefois utilisé pour la sécurité sans fil. Microsoft recommande d'utiliser le protocole 802.1X pour sécuriser les réseaux sans fil et permettre, lorsque cela est possible, un contrôle d'accès pour les réseaux filaires. Pour plus d'informations sur l'utilisation du protocole 802.1X, reportezvous à la page WiFi du site Web de Microsoft, à l'adresse http://www.microsoft.com/wifi. IPSec IPSec est le protocole de sécurité standard de l'IETF (Internet Engineering Task Force) pour le protocole IP. Il s'agit d'un mécanisme général de sécurité de couche IP basé sur des stratégies. Il convient parfaitement pour l'authentification hôte par hôte. Une stratégie IPSec possède des règles et paramètres de sécurité qui contrôlent sur un hôte le flux du trafic IP entrant et sortant. La stratégie peut être gérée de façon centralisée dans Active Directory en utilisant des objets de stratégie de groupe (GPO) pour l'attribution des stratégies aux membres du domaine. IPSec permet d'établir des communications sécurisées entre les hôtes. IPSec utilise le protocole de négociation IKE (Internet Key Exchange) pour négocier entre deux hôtes des options relatives à la communication sécurisée à l'aide d'IPSec. Les accords définis entre deux hôtes concernent la façon d'utiliser IPSec pour communiquer, et les divers paramètres qui définissent cette négociation constituent des associations de sécurité. La négociation IKE établit une association de sécurité en mode principal (également appelée association de sécurité ISAKMP) et une paire d'associations de sécurité en mode rapide (également appelées associations de sécurité IPSec), l'une pour le trafic entrant et l'autre pour le trafic sortant. IKE requiert une authentification mutuelle pour établir l'association de sécurité en mode principal. Windows IKE peut utiliser l'une des trois méthodes suivantes :
• protocole d'authentification Kerberos version 5 ;
37
• un certificat numérique X.509 avec la paire de clés RSA (Rivest, Shamir et Adleman) publique et privée correspondante ;
• une clé prépartagée (une phrase de passe, pas véritablement un mot de passe). Bon nombre de personnes ne souhaitent pas déployer IPSec car elles estiment, à tort, qu'IPSec requiert des certificats d'infrastructure de clés publiques (PKI), souvent difficiles à déployer. Pour éviter d'avoir recours à une infrastructure de clés publiques, Microsoft a intégré l'authentification de domaine (Kerberos) de Windows 2000 dans le protocole de négociation IKE. La négociation Windows IKE peut être configurée pour autoriser les communications avec un ordinateur ne répondant pas à la requête de négociation IKE. Cette caractéristique correspond à Communiquer en texte clair. Elle est d'une grande utilité lors du déploiement d'IPSec. Dans le cadre d'un fonctionnement normal, il est pratique de pouvoir autoriser des hôtes approuvés à communiquer avec des ordinateurs ou périphériques non approuvés, uniquement lorsque l'hôte approuvé lance la requête de connexion. IPSec utilise l'expression association de sécurité logicielle pour désigner une communication qu'IPSec ne peut pas protéger en utilisant les formats d'entête d'authentification (AH) ou d'encapsulation de charge utile de sécurité (ESP). IPSec enregistre cette communication dans le journal de sécurité comme audit de succès avec l'adresse IP de destination, et contrôle l'activité du trafic. Lorsque le trafic cesse après une durée d'inactivité (5 min par défaut) une nouvelle tentative de négociation de sécurité est requise lorsque de nouvelles connexions sortantes sont établies. IPSec ne prend pas en charge le filtrage dynamique du trafic sortant, qu'il s'agisse du trafic dans une association de sécurité AH ou ESP, ou du trafic en texte clair impliqué dans une association de sécurité logicielle. Ainsi, lorsque vous utilisez les modèles de stratégie IPSec présentés dans ce guide pour l'isolation de domaines et de serveurs, l'hôte approuvé peut recevoir des connexions entrantes lancées depuis un ordinateur non approuvé sur n'importe quel port, par le biais de l'association de sécurité logicielle. Ceci constitue une vulnérabilité et par conséquent un point d'attaque potentiel. Mais il existe également un modèle prenant en charge des protocoles qui négocient les ports ouverts pour recevoir des connexions entrantes. Il est possible d'utiliser le filtrage dynamique des connexions sortantes pour compléter la protection IPSec, notamment à l'aide d'un parefeu pour hôte tel que Pare feu Windows. Le trafic réseau bénéficiant de la protection IPSec AH ou ESP sans chiffrement n'est pas considéré comme étant en texte clair car il n'est pas authentifié ni protégé contre l'usurpation et la modification. Comme IPSec encapsule les paquets IP normaux dans un format sécurisé, les paquets n'apparaissent plus comme des paquets TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) lorsqu'ils transitent sur le réseau. La tentative de déploiement d'IPSec dans le cas de la Woodgrove Bank a montré que la plupart des outils de gestion réseau considéraient que les applications pouvaient être directement identifiées par leur numéro de port TCP ou UDP (par exemple, le port 25 pour le trafic de la messagerie électronique et le port 80 pour le trafic Web). Lorsque vous utilisez IPSec, le trafic devient plus complexe et les routeurs et le système de détection des intrusions réseau ne parviennent ni à identifier les applications en cours d'utilisation ni à inspecter les données du paquet. Ce facteur crée un problème de gestion réseau, car il déprécie la valeur des outils actuellement utilisés pour surveiller le trafic, filtrer la sécurité, mettre en file d'attente de façon juste et pondérée, et classer la qualité des services. Malheureusement, cette hypothèse sur la visibilité du trafic n'est pas tout à fait juste et devient même rapidement obsolète, même sans utiliser IPSec. La relation entre les numéros de port et les applications est de plus en plus fine. Il est par exemple possible d'exécuter un serveur Web sur un numéro de port arbitraire et d'indiquer le numéro de port dans l'URL du site. Il est également possible de contourner les efforts de filtrage de messagerie électronique entrepris par certains fournisseurs d'accès Internet (FAI), en exécutant un service de messagerie sur un numéro de port différent. Un grand nombre d'applications homologueàhomologue (P2P) sont astucieuses dans la gestion des ports. Elles choisissent en réalité des numéros de port au hasard pour éviter d'être détectées. Les
38
applications basées sur les services d'appel de procédure distante (RPC) sont également habiles dans la gestion des ports. En effet, les services RPC choisissent au hasard des numéros de port éphémères (supérieurs à 1024) pour différents services. L'utilisation croissante de services Web va très probablement accélérer les problèmes d'identification du trafic, car le trafic pour ces services s'exécute audessus du protocole HTTP ou HTTPS, via le port 80 ou 443. Les clients et les serveurs utilisent ensuite l'URL HTTP pour identifier le trafic. Toutes les applications déplacées vers une architecture de services Web apparaissent comme un flux de données indifférencié unique pour les routeurs, car le trafic de ces services Web est exécuté sur un seul port ou sur un petit nombre de ports. Chaque application ou service n'est pas exécuté sur un numéro de port distinct. L'utilisation de SSL et de TLS pour les connexions HTTPS et le chiffrement RPC déprécie la valeur de l'inspection du réseau en tant que dispositif de défense contre les attaques. Comme les applications de gestion réseau étaient toujours capables d'analyser les adresses des paquets et qu'elles bénéficiaient d'une visibilité suffisante pour tous les autres trafics non protégés par IPSec, la Woodgrove Bank a décidé que la perte de certaines fonctionnalités de gestion réseau n'était pas suffisamment significative pour modifier les plans de ce projet. En outre, certains fournisseurs d'outils de gestion réseau souhaitaient modifier leurs outils pour analyser les formes non chiffrées de paquets IPSec. La plupart des applications basées sur l'hôte n'ont pas besoin d'être modifiées pour fonctionner correctement alors qu'IPSec sécurise l'ensemble du trafic entre les adresses IP. L'objectif de cette solution n'est pas d'utiliser IPSec uniquement pour des applications ou des protocoles spécifiques, car il existe des risques d'attaque réseau sur d'autres services réseau. Si des applications ne fonctionnent pas correctement avec IPSec, l'administrateur a la possibilité d'autoriser ce trafic sans la protection IPSec et en fonction des adresses IP utilisées pour les serveurs. Il n'est pas recommandé d'autoriser des applications en fonction d'un port connu car cela ouvre une brèche d'entrée statique aux personnes malveillantes qui peuvent ainsi établir des connexions entrantes sur n'importe quel port ouvert, annihilant de ce fait l'objectif de l'isolation. Les applications qui utilisent des ports alloués dynamiquement ne peuvent pas être autorisées sans protection IPSec. Les applications qui utilisent l'adressage IP de multidiffusion et de diffusion risquent de rencontrer des problèmes avec IPSec dans le cadre de l'isolation de serveurs et de domaines. Windows IPSec peut autoriser tout le trafic de multidiffusion et de diffusion, à l'exception de certains types. Si vous rencontrez des problèmes de compatibilité avec certaines applications, renseignezvous auprès du fournisseur de l'application concernée pour savoir si un correctif ou une mise à niveau est disponible pour résoudre ce problème. Si l'application ne peut pas être mise à jour ou remplacée par une application qui serait compatible, les ordinateurs qui doivent utiliser cette application risquent de ne pas pouvoir être intégrés dans l'isolation de domaines ou de groupes. Outre ses fonctionnalités d'authentification, IPSec offre également deux autres services très utiles de communication hôte : la vérification de l'intégrité des adresses et le chiffrement du trafic réseau.
• Vérification de l'intégrité des adresses. IPSec peut utiliser des entêtes d'authentification (AH)
pour assurer l'intégrité des données et des adresses pour chaque paquet. Les AH de Windows utilisent un mécanisme de hachage avec clé dans le pilote Windows IPSec. L'utilisation des AH permet d'éviter que des attaques par relecture ne se produisent, et elle offre une intégrité renforcée en confirmant qu'aucun des paquets reçus n'a été modifié, de l'envoi à la réception effective. Un AH ne fonctionnera pas correctement s'il passe par un périphérique qui effectue une traduction d'adresses réseau (NAT), car la technologie NAT remplace l'adresse source dans l'entête IP, violant ainsi la sécurité mise en place par IPSec AH.
• Chiffrement du trafic réseau. IPSec assure la confidentialité et l'intégrité des données grâce au
chiffrement, en utilisant l'option d'encapsulation de charge utile de sécurité (ESP) pour le protocole IP. Bien que l'ESP n'assure pas l'intégrité des adresses (sauf lorsqu'elle est utilisée avec les AH), il est possible de faire en sorte qu'elle traverse avec succès un périphérique NAT en utilisant une encapsulation UDP. Si les réseaux internes sont segmentés avec des périphériques qui utilisent NAT, l'ESP est le choix logique qui s'impose car l'encapsulation de charge utile de sécurité 39
n'impose pas le chiffrement des paquets. Windows IPSec prend en charge RFC 2410, qui définit l'utilisation de l'ESP avec chiffrement nul (ESP/null). ESP/null permet d'assurer l'authentification, l'intégrité et l'antirelecture des données, sans requérir de chiffrement. Le Moniteur réseau de Windows Server 2003 est capable d'analyser une ESP non chiffrée pour exposer les protocoles de niveau supérieur TCP/IP normaux. Si le chiffrement ESP est utilisé, la surveillance des paquets n'est possible que si l'ordinateur utilise une carte réseau d'accélération matérielle IPSec, qui déchiffre d'abord les paquets entrants. Remarque : l'ESP avec chiffrement ou utilisant le chiffrement null permet des relations poste à poste IPSec renforcées avec authentification, tout comme les entêtes d'authentification. Elle offre également une protection contre les relectures et peut traverser correctement un périphérique NAT. Pour ces raisons, la Woodgrove Bank a choisi de ne pas implémenter d'entête d'authentification. Elle utilise uniquement ESP/null et ESP avec chiffrement sur son réseau d'entreprise. IPSec peut fonctionner dans les deux modes suivants : le mode de tunnel et le mode de transport :
• Mode de transport IPSec. Le mode de transport IPSec est l'option recommandée pour sécuriser
le trafic entre des hôtes de bout en bout. Le pilote IPSec ajoute simplement un entête IPSec après l'entête IP d'origine. L'entête IP d'origine est conservé et les paquets restants sont sécurisés via un processus de chiffrement AH ou ESP. Les filtres IPSec contrôlent le trafic bloqué, autorisé ou encapsulé par IPSec. Les filtres IPSec spécifient les adresses IP (ou sousréseaux) source et destination, le protocole (ICMP ou TCP, par exemple) et les ports source et de destination. Les filtres peuvent donc s'appliquer spécifiquement à un ordinateur ou à tous les protocoles et adresses de destination possibles. Le mode de transport avait été conçu pour les adresses IP dynamiques, en mettant à jour automatiquement les filtres configurés avec « Mon adresse IP ». Il est moins surchargé et, dans l'ensemble, plus simple à utiliser que le mode de tunnel IPSec. Le mode de transport de négociation IKE constitue un moyen efficace d'autorisatio n des co nnexions entrantes protégées par IPSec. Les problèmes liés à l'utilisation du mode de transport IPSec sont les suivants : • Délai initial. Il doit s'écouler de une à deux secondes avant qu'IKE ne puisse lancer et réaliser une négociation complète réussie. Alors que la communication est en cours, IKE tente d'actualiser les clés de chiffrement qui protègent automatiquement le trafic. • Ordre de priorité prédéfini des filtres. Les filtres de stratégie IPSec peuvent se chevaucher et ainsi suivre un ordre de priorité prédéfini, le plus spécifique en premier. Pour cela, les deux parties en communication doivent posséder, pour la négociation IKE, un ensemble de filtres de mode de transport IPSec compatibles. Par exemple, cette solution utilise un filtre plus général pour « tout le trafic » qui négocie la sécurité IPSec et un filtre plus spécifique pour autoriser uniquement le trafic ICMP plutôt que de sécuriser ce trafic avec IPSec. • Consommation importante de puissance de calcul. Le chiffrement du mode de transport ESP IPSec peut consommer énormément de puissance de calcul. La copie d'un fichier chiffré peut nécessiter l'utilisation de 80 à 100 % des ressources de processeur. Windows 2000, Windows XP et Windows Server 2003 possèdent des interfaces de cartes réseau qui permettent d'accélérer au niveau matériel les opérations de chiffrement IPSec.
• Mode de tunnel IPSec. Le mode de tunnel IPSec est en général utilisé pour les tunnels VPN de
passerelle à passerelle entre des adresses IP statiques de passerelles VPN. Le mode de tunnel crée un nouvel entête IP avec un entête IPSec. Le paquet d'origine doté de l'entête IP d'origine est encapsulé intégralement pour former un paquet tunnel. Dans les scénarios de l'isolation de serveurs et de domaines, le mode de tunnel peut être utilisé pour sécuriser le trafic d'un serveur IP statique vers un routeur prenant en charge IPSec. Cela peut même s'avérer nécessaire si l'hôte de destination ne prend pas en charge IPSec. La Woodgrove Bank n'a pas utilisé de scénario nécessitant l'utilisation du mode de tunnel.
40
Pour plus d'informations techniques sur le mode de transport et le mode de tunnel dans IPSec, reportezvous à la section « Determining Your IPSec Needs » (Détermination de vos besoins IPSec) du chapitre « Deploying IPSec » (Déploiement d'IPSec) dans la partie « Deploying Network Services » (Déploiement de services réseau) du Kit de déploiement de Windows Server 2003, à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/ enus/dnsbj_ips_wclw.asp. Autorisation de l'hôte Lorsque l'hôte a déterminé que la communication qu'il reçoit provient d'une source vérifiable, il doit déterminer s'il doit ou non autoriser l'accès à l'ordinateur source et à l'utilisateur. Cela est très important car ce n'est pas parce qu'un périphérique peut être authentifié qu'il sera pour autant autorisé à accéder à un hôte donné. L'approche que recommande Microsoft consiste à utiliser des groupes Windows standards afin de limiter les possibilités d'accès des utilisateurs et des ordinateurs aux ressources des autres ordinateurs de l'organisation. Cette méthode crée une nouvelle couche d'autorisation pour les comptes ordinateur et utilisateur au niveau de la couche réseau et application en utilisant les autorisations des attributions des droits de l'utilisateur de la stratégie locale sur l'hôte auquel l'accès doit être accordé. En utilisant les attributions des droits de l'utilisateur « Accéder à cet ordinateur à partir du réseau » (AUTORISER) et « Interdire l'accès à cet ordinateur à partir du réseau » (REFUSER), il est possible de restreindre l'accès d'un ordinateur ou d'un utilisateur à une ressource, même s'ils partagent des paramètres de stratégie IPSec communs et si l'utilisateur connecté possède le droit d'accéder à la ressource. Ce niveau de contrôle supplémentaire est fondamental dans l'approche de l'isolation présentée dans cette solution. Les privilèges des groupes d'Active Directory classent les ordinateurs et les utilisateurs de telle sorte qu'il est possible d'assigner les niveaux d'autorisation requis de façon simple et évolutive. Pour faciliter la distinction entre les groupes créés spécifiquement pour obtenir l'autorisation d'accès à l'hôte et les groupes bénéficiant d'autorisations d'accès standard au partage, ce guide utilise le terme groupes d'accès réseau. La figure suivante illustre les principales étapes du processus global d'autorisation hôte/utilisateur de la solution.
41
Figure 2.2 Processus d'autorisation utilisateur/hôte
Le processus en cinq étapes (détaillées ciaprès) illustré par la figure 2.2 est suivi pour toutes les communications réseau, une fois la solution d'isolation en place.
1. Un utilisateur tente d'accéder à un partage situé sur un serveur départemental. Un utilisateur connecté à l'ordinateur client tente d'accéder à un partage sur un hôte approuvé, dans la solution d'isolation logique. L'ordinateur client tente donc de se connecter à l'hôte approuvé en utilisant le protocole de partage de fichiers (en général, le protocole SMB, via le port de destination TCP 445). Dans le cadre de la solution, une stratégie IPSec est affectée au client. La requête de connexion TCP sortante lance une négociation IKE vers le serveur. Le client IKE obtient un ticket Kerberos lui permettant d'être authentifié par le serveur.
2. Négociation de mode principal IKE. Lorsque le serveur reçoit la requête de communication IKE initiale émise par l'ordinateur client, il procède à l'authentification du ticket Kerberos. Pendant le processus d'authentification, IKE vérifie que l'ordinateur client possède les droits d'accès à l'hôte requis, qui doivent être conformes aux droits d'utilisateurs AUTORISER ou REFUSER de la stratégie de groupe. Si l'ordinateur client possède l'attribution des droits utilisateur requise, la négociation IKE se termine et une association de sécurité en mode principal IPSec est établie.
3. Négociation de la méthode de sécurité IPSec. Une fois la négociation de l'association de sécurité en mode principal IKE terminée, les méthodes de sécurité de la stratégie IPSec sont vérifiées afin de négocier une connexion en utilisant les méthodes de sécurité des associations de sécurité IPSec acceptables par les deux hôtes. L'organigramme suivant illustre le processus complet de l'étape 2 à l'étape 3 :
42
Figure 2.3 Processus de vérification des autorisations d'accès à l'hôte de l'ordinateur
4. Vérifications des autorisations d'accès à l'hôte de l'utilisateur. Une fois la communication protégée par IPSec établie, le protocole SMB procède à l'authentification en utilisant le compte utilisateur du client. Sur le serveur, le compte utilisateur est analysé pour vérifier qu'il bénéficie bien des autorisations d'accès à l'hôte requises, qui doivent être conformes aux droits d'utilisateurs AUTORISER et REFUSER de la stratégie de groupe pour l'hôte approuvé. Le diagramme suivant illustre ce processus :
43
Figure 2.4 Processus de vérification des autorisations d'accès à l'hôte de l'utilisateur.
Si le compte d'utilisateur bénéficie de l'attribution des droits utilisateur requise, le processus se termine et le jeton de connexion utilisateur est créé. Une fois ce processus terminé, les vérifications de sécurité de la solution d'isolation logique sont terminées.
5. Vérifications des autorisations d'accès aux fichiers et au partage. Enfin, le serveur vérifie les autorisations d'accès aux fichiers et au partage Windows standard pour contrôler que l'utilisateur est membre d'un groupe bénéficiant des autorisations requises pour accéder aux données demandées par l'utilisateur. L'utilisation de groupes d'accès réseau permet de bénéficier d'un niveau de contrôle très élevé dans la solution. Le scénario suivant donne un exemple pratique des étapes de la solution d'isolation logique : Au cours d'une réunion, une soustraitante connecte son ordinateur portable à un point de connexion d'une salle de réunion, pour copier des données sur un partage situé sur le serveur RH d'un employé. Dominique, membre du service des RH, indique au soustraitant le chemin d'accès au partage du serveur RH. Comme l'ordinateur portable du soustraitant n'est pas un hôte connu ou approuvé, le service informatique ne gère pas l'ordinateur et le niveau de sécurité mis en place dans l'ordinateur portable n'est pas connu. Par conséquent, il est possible que les fichiers contiennent un logiciel malveillant susceptible d'infecter les ordinateurs internes. Lorsque l'ordinateur du soustraitant tente de se connecter au serveur RH, les ordinateurs échouent à l'étape 2 du processus. Les ordinateurs ne peuvent pas négocier une association de sécurité en mode principal IKE car l'ordinateur portable n'est pas en mesure de fournir le ticket Kerberos requis pour permettre la vérification des informations d'identification de l'ordinateur. L'ordinateur portable n'appartient pas à un domaine approuvé. Les exigences de la stratégie IPSec du groupe d'isolation auquel appartient le serveur RH n'autorisent pas le serveur à communiquer avec un hôte qui n'utilise pas IPSec. Par conséquent, toutes les tentatives
44
de communication émises par cet ordinateur non approuvé sont bloquées. En résumé, la solution d'isolation logique aide à protéger l'infrastructure informatique des menaces que peuvent représenter des ordinateurs non approuvés et non gérés, même lorsque ceuxci bénéficient d'un accès physique au réseau interne. Cet exemple explique comment implémenter l'isolation selon une approche hôte par hôte. La proposition d'une isolation à des coûts administratifs réduits fait également partie des exigences importantes de la solution. Il est possible de regrouper des ordinateurs, tout comme cela est possible pour les utilisateurs, puis d'attribuer à ces groupes les droits d'utilisateur AUTORISER ou REFUSER dans toutes les stratégies locales des ordinateurs. Cette approche est toutefois difficile à gérer et n'évolue pas correctement sans utiliser la fonction de centralisation de la stratégie de groupe et d'Active Directory, et sans une compréhension solide des chemins de communication requis. En outre, cette approche seule ne permet pas de réaliser une authentification fiable ou de chiffrer les données. Lorsque ces autorisations d'accès à l'hôte sont associées à IPSec et que les hôtes sont organisés dans des groupes d'isolation, les relations entre les groupes sont plus claires et les chemins de communication, plus faciles à définir (une fois les exigences clairement répertoriées). Pour plus d'informations sur la configuration et la structure des groupes d'isolation, reportezvous au chapitre 4, « Conception et planification de groupes d'isolation ».
De quoi nous protège l'isolation de serveurs et domaines ? L'isolation de serveurs et de domaines consiste à mettre en place des limites de communication entre des ordinateurs et d'autres ordinateurs ou périphériques tentant d'établir les communications. Ces limites ou frontières permettent de limiter les communications en définissant le niveau auquel un périphérique est considéré comme approuvé. La mise en place de limites comme l'authentification, l'autorisation et l'emplacement réseau autour d'un hôte en utilisant une stratégie IPSec est un excellent moyen de réduire bon nombre de menaces. IPSec ne constitue pas une stratégie de sécurité complète mais ajoute une couche de protection supplémentaire dans une stratégie de sécurité globale. La section suivante présente des menaces types et évoque brièvement la modélisation des menaces. Pour plus d'informations sur les périphériques approuvés dans le scénario de Woodgrove Bank et sur le processus de conception utilisé par la Woodgrove Bank pour identifier et classer les ordinateurs comme dignes de confiance, reportezvous à la section « Définition de l'approbation » du chapitre 3 « Détermination de l'état actuel de votre infrastructure informatique ».
Modélisation et classification des menaces Ces dernières années, les attaques ciblant les applications et serveurs réseau sont devenues de plus en plus fréquentes et complexes. Ce qui est intéressant, c'est que les styles et types d'attaque ainsi que les méthodes élémentaires permettant de les déjouer n'ont pas véritablement évolué. Certaines fonctions et méthodes d'implémentation de ces défenses sont toutefois différentes. Pour être en mesure de déterminer la planification que requiert une solution d'isolation de serveurs et de domaines, votre organisation doit d'abord entreprendre une analyse détaillée des risques de menace présents et comprendre comment déjouer ces risques en faisant appel à plusieurs technologies et processus. Les processus permettant d'identifier, de classer et de répertorier les menaces encourues par une organisation sont à l'heure actuelle bien connus. Cette documentation présente une méthodologie pouvant être utilisée pour la modélisation des menaces commerciales, environnementales et techniques communes auxquelles doivent faire face les organisations. Pour la modélisation de la menace, Microsoft utilise la méthode STRIDE. STRIDE représente les catégories de menace contre lesquelles se protéger. Ces catégories sont les suivantes :
45
S usurpation T falsification R répudiation I divulgation d'informations D refus de service E élévation de privilèges Il est primordial de consacrer le temps et les ressources nécessaires à la définition, la plus précise possible, d'un modèle de menace, pour assurer la protection de toutes les ressources à protéger. Pour obtenir plus d'informations sur les menaces et attaques spécifiques que l'isolation de serveurs et de domaines aide à limiter, reportezvous à l'annexe D, « Catégories de menaces informatiques », de ce guide. Pour une présentation détaillée des modèles de menace, reportezvous au chapitre 2, « Defining the Security Landscape » (Définition du paysage de sécurité), de la solution Microsoft Solution for Securing Windows 2000 Server pouvant être téléchargée à l'adresse suivante : www.microsoft.com/technet/security/prodtech/ win2000/secwin2k/02defsls.mspx.
Comment déployer l'isolation de serveurs et de domaines ? Lorsque vous avez pris connaissance des menaces auxquelles doit faire face votre organisation et que vous avez compris comment la solution permet de réduire ces risques, étudiez un déploiement possible de la solution. Cette section décrit le processus de déploiement.
Collecte d'informations Avant même de commencer le processus de conception, vérifiez que vous disposez d'une représentation à jour et précise de l'état actuel du réseau de votre organisation, notamment des configurations des stations de travail et serveurs, et des chemins de communication. Il est impossible de développer une solution d'isolation logique efficace sans connaître de façon précise les éléments que la solution doit protéger. Le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », décrit de façon détaillée les moyens qui vous permettent d'obtenir des informations sur l'état actuel de votre réseau et sur les périphériques qui y sont connectés. Ce processus fournit toutes les informations requises dans les chapitres suivants de cette solution et offre un grand intérêt pour les autres projets entrepris dans l'organisation. Ce processus permet avant tout à l'organisation d'analyser et d'examiner avec soin les chemins de communication requis pour ses systèmes d'information et d'effectuer des choix judicieux quant aux compromis éventuels sur les risques, les exigences de communication et les exigences de l'entreprise.
Présentation du processus de déploiement d'IPSec Lorsque vous avez choisi et créé une conception, vous devez mettre en place un processus d'implémentation de cette conception dans l'organisation, de sorte que l'implémentation soit gérable et qu'elle ait peu de répercutions sur les utilisateurs. Le chapitre 4, « Conception et planification de
46
groupes d'isolation », présente de façon détaillée plusieurs approches dont vous pouvez vous inspirer. Le processus élémentaire peut être résumé comme suit : Tester la conception et les stratégies IPSec dans un laboratoire de validation technique. Testez les stratégies IPSec envisagées dans un environnement hors production, isolé, pour vous assurer que la conception fonctionne comme prévu et pour tester les problèmes susceptibles de survenir dans les paramètres de la stratégie ou dans les mécanismes de déploiement.
1. Expérimenter la configuration testée et approuvée. Lorsque l'équipe est convaincue que la conception fonctionne comme prévu dans l'environnement du laboratoire, l'étape suivante du processus consiste à identifier dans un environnement de production un petit nombre d'ordinateurs à inclure dans un déploiement expérimental de la solution. Pour s'assurer que les problèmes susceptibles de survenir pendant le test auront le moins d'impact possible sur l'activité des utilisateurs, un support préventif doit être dispensé aux ordinateurs et aux utilisateurs identifiés.
2. Implémenter un déploiement progressif de la solution. La dernière étape du processus consiste à planifier le déploiement de la conception pour l'ensemble de l'organisation. Ce processus est très important ! Vous devez être extrêmement prudent lorsque vous planifiez cette étape. Il est possible de mettre en œuvre (après la simple modification d'un paramètre de la stratégie IPSec) une conception qui peut priver bon nombre d'ordinateurs de l'accès aux ressources réseau. Testez et organisez votre plan de déploiement pour que les modifications introduites par la solution soient implémentées de sorte qu'il soit possible de retrouver rapidement un état de fonctionnement satisfaisant, au cas où une erreur de conception ou de configuration n'aurait pas été détectée lors de la phase de test. Le chapitre 4, « Conception et planification de groupes d'isolation », donne des informations détaillées sur le processus de conception de domaines d'isolation et présente des options de déploiement progressif de la solution.
Résumé Ce chapitre décrit les objectifs et les processus de la solution présentée dans ce guide. Depuis de nombreuses années déjà, les professionnels de l'informatique ont compris les avantages d'IPSec, toutefois, en raison de la nature complexe de cette technologie, rares en sont les implémentations. L'implémentation d'IPSec peut entraîner de graves problèmes si la solution ne bénéficie pas d'une conception solide, d'un déploiement parfaitement planifié et d'une méthodologie de test fiable. Les informations présentées dans ce chapitre montrent que l'isolation logique est une couche de sécurité supplémentaire qui exploite les techniques d'isolation de serveurs et de domaines, et les fonctions de la plateforme Windows, d'IPSec, des stratégies de groupe et d'Active Directory pour constituer une solution d'entreprise gérable et évolutive, capable de réduire les risques auxquels sont exposées les données. Les informations présentées dans les chapitres suivants mettent l'accent sur les étapes requises pour la planification et l'implémentation de la solution. Le chapitre 6, « Gestion d'un environnement d'isolation de serveurs et de domaines », présente des procédures à implémenter dans le cadre du fonctionnement quotidien d'un environnement d'exploitation utilisant l'isolation de serveurs et de domaines. Le chapitre 7, « Dépannage d'IPSec », contient des informations relatives à la prise en charge et au dépannage d'IPSec.
47
Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique Ce chapitre explique comment obtenir les informations nécessaires à la planification et au déploiement d'une solution d'isolation de serveurs et de domaines. Un déploiement réussi exige une connaissance à jour et précise de votre infrastructure informatique. Après avoir lu le présent chapitre, vous serez parfaitement au fait des informations nécessaires à la mise en place d'une solution d'isolation de serveurs et de domaines. La dernière partie du chapitre explique comment maîtriser et documenter les ordinateurs identifiés et susceptibles de fonctionner comme ordinateurs « approuvés » au sein de la solution. Ces informations seront utiles à l'équipe chargée de la mise en place de la solution au moment de planifier cette dernière.
Connaissances préalables requises pour ce chapitre Avant d'exploiter les informations contenues dans ce chapitre, assurezvous que vous et votre organisation respectez les exigences suivantes. Les instructions fournies dans ce chapitre sont spécifiquement adaptées aux besoins d'une organisation répondant de manière stricte à ces exigences. L'absence de conformité à l'ensemble des conditions requises n'a pas nécessairement un impact négatif sur votre projet mais en respectant ces exigences, vous donnerez d'autant plus de valeur aux instructions qui vous sont fournies.
Connaissances requises Vous devez être familiarisé avec les concepts liés à IPSec et disposer de connaissances solides dans les domaines suivants :
• Authentification Microsoft® Windows® (plus précisément, le protocole d'authentification Kerberos version 5)
• Concepts relatifs au service d'annuaire Active Directory® (notamment les outils et la structure
Active Directory), la manipulation d'utilisateurs, de groupes et d'autres objets Active Directory et enfin l'utilisation de la stratégie de groupe
• Sécurité du système Windows, notamment les concepts de sécurité, tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès
• Conventions système d'attribution de noms de l'organisation • Emplacements physiques et logiques de l'organisation • Méthodes de gestion des risques adoptées dans l'organisation • Concepts réseau clés, notamment le filtrage de port à l'aide de parefeu Avant de poursuivre la lecture de ce chapitre, lisez également les chapitres précédents de ce guide pour bien comprendre les concepts de la solution proposée en termes d'architecture et de conception.
48
Conditions requises pour l'organisation En règle générale, la planification de groupes d'isolation dans une organisation implique plusieurs intervenants aux compétences diverses. Les informations nécessaires à une évaluation rigoureuse des exigences proviennent souvent de diverses sources disséminées dans l'organisation. Vous devez consulter les membres de votre organisation susceptibles de participer au processus de planification de ces groupes, notamment les personnes suivantes :
• les cadres exécutifs ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les propriétaires d'applications, de serveurs Web et de domaines DNS (Domain Name System) ; • le personnel des opérations et d'administration réseau ; • le personnel de formation et d'assistance interne. Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles. Outre les informations recueillies auprès des personnes citées ciavant, un point crucial à retenir est la mise à jour des pratiques opérationnelles actuellement en vigueur avec l'introduction d'IPSec dans l'environnement concerné. Il est possible que des composants logiciels et matériels, notamment le BIOS et les microprogrammes des périphériques réseau, exigent aussi une mise à jour. Enfin, des outils réseau supplémentaires seront peutêtre nécessaires afin de faciliter la prise en charge et le dépannage de l'environnement IPSec.
Configuration requise pour l'infrastructure informatique Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :
• Un domaine Microsoft Windows Server™ 2003 Active Directory fonctionnant en mode mixte ou
natif. Cette solution utilise des groupes universels pour l'application des objets Stratégie de groupe (GPO). Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en us/ipsec_whatsnew.asp.
• Les outils et les compétences requis pour surveiller le réseau, analyser les données de
surveillance et prendre des décisions de planification de capacité sur la base de ces données.
Remarque : l'usage des outils de surveillance réseau est soumis à des restrictions dans de nombreuses organisations. Soyez vigilant et assurezvous que les procédures opérationnelles suivies lors de l'utilisation de ces outils sont les bonnes.
49
• Un outil déjà installé et capable de recueillir des données de configuration réseau sur les hôtes du
réseau. Par exemple, vous pouvez faire appel à des systèmes de gestion des ressources pour collecter ces informations. Pour plus d'informations, consultez la section « Détection d'hôtes » plus loin dans ce chapitre.
À qui s'adresse ce chapitre Ce chapitre s'adresse aux professionnels informatiques chargés de créer l'infrastructure informatique que les architectes et les concepteurs de solutions utiliseront. Ces professionnels sont généralement des membres du personnel du support ou des opérations de l'organisation concernée. Pour tirer le meilleur parti des informations figurant dans ce chapitre, vous devez disposer d'un bon de niveau de connaissance technique des outils et des technologies impliqués dans le processus de recueil des informations ainsi que de l'infrastructure actuelle de l'organisation.
Analyse de l'état actuel Recueillir et tenir à jour des données fiables sur les ordinateurs, les logiciels et les périphériques réseau d'une organisation est un défi informatique classique. La réussite d'un projet dépend des informations relevées au cours de ce processus. Avant d'entamer la planification d'un projet d'isolation de serveurs et de domaines, vous devez recueillir et analyser des données mises à jour sur les ordinateurs, le réseau et les services d'annuaire déjà déployés au sein de l'organisation. Ces données vous permettront de concevoir une solution qui tient compte de tous les éléments possibles de l'infrastructure existante. Si les informations recueillies manquent de précision, des problèmes liés à des périphériques et des ordinateurs non pris en compte au cours de la phase de planification peuvent survenir lors de l'implémentation. Les sections suivantes décrivent les informations requises dans chaque domaine et fournissent des exemples issus des informations recueillies dans le cadre de la solution d'isolation de serveurs et de domaines développée pour la Woodgrove Bank.
Détection réseau L'aspect le plus primordial de la planification d'une solution d'isolation de serveurs et de domaines est l'architecture réseau, puisque le protocole de sécurité IPSec intervient au niveau du protocole Internet (IP). Une maîtrise partielle ou erronée du réseau se traduira par l'échec de toute solution d'isolation. La compréhension de l'agencement des sousréseaux, des schémas d'adressage IP et des modèles de trafic est une condition qui participe à cet effort mais les deux composants suivants sont indispensables pour mener à terme la phase de planification du projet :
• Documentation de la segmentation du réseau • Documentation du modèle de trafic réseau actuel L'objectif recherché est de disposer de suffisamment d'informations pour identifier une ressource en fonction de son emplacement sur le réseau, en plus de son emplacement physique. Il est préférable de débuter avec une architecture réseau soigneusement pensée, dotée de plages d'adresses facilement identifiables et du nombre le plus réduit possible de chevauchements ou de plages discontinues. Il est possible que certains impératifs commerciaux ou circonstances (par exemple, dans le cas de fusions et d'acquisitions) ne permettent pas la mise en place d'un réseau « rationalisé » mais en prenant soin de documenter et de comprendre l'état actuel, vous faciliterez votre travail d'identification du réseau et des ressources qu'il gère. N'utilisez pas un réseau complexe et mal documenté comme point structurel de départ ; il risque de laisser un trop grand nombre de domaines non identifiés susceptibles de causer des problèmes lors de l'implémentation.
50
Ces instructions sont un moyen d'obtenir les informations les plus pertinentes pour la planification d'une solution d'isolation de serveurs et de domaines mais n'ont pas pour vocation de chercher à résoudre d'autres problèmes, notamment les questions de masque de sousréseau de longueur variable et d'adressage TCP/IP, de segmentation de réseau local virtuel (VLAN) ou d'autres méthodes et techniques d'optimisation des réseaux. Les informations obtenues servent à formuler les composants opérationnels et d'implémentation de la solution d'isolation de serveurs et de domaines. Documentation de la segmentation du réseau Si l'architecture actuelle de votre organisation n'est pas documentée et disponible en guise de référence, vous devez vous procurer les documents nécessaires dès que possible avant de poursuivre la mise en œuvre de la solution. Si les informations documentées ne sont pas à jour ou n'ont pas été récemment validées, deux options simples vous sont proposées :
• Accepter le fait que les informations exposent le projet à des risques. • Engager un processus de détection et de découverte, soit manuellement, soit par le biais d'un outil d'analyse réseau capable de fournir les informations nécessaires à la documentation de la topologie réseau actuelle.
Les informations requises peuvent être présentées de différentes façons, mais une série de représentations schématiques s'avère souvent la méthode la plus efficace pour illustrer et expliquer la configuration actuelle du réseau. Lorsque vous créez le schéma d'un réseau, évitez d'y insérer trop d'informations. Si nécessaire, utilisez plusieurs schémas illustrant différents niveaux de détail. Prenons pour exemple le scénario imaginé pour la Woodgrove Bank. Le schéma créé et illustré ci dessous offre une vision détaillée de son réseau étendu et de l'environnement du site :
Figure 3.1 Réseau étendu et architecture du site de la Woodgrove Bank
51
Après avoir développé ce schéma, l'équipe de la Woodgrove Bank a entrepris de créer des schémas détaillés de chaque site, puis de chaque sousréseau à l'intérieur de chaque site. Tout en documentant votre réseau, vous rencontrerez peutêtre des applications et des services réseau incompatibles avec IPSec. Parmi les risques d'incompatibilité actuels figurent les points suivants :
• Sur les routeurs, la technologie Cisco NetFlow ne peut pas analyser les paquets entre des membres IPSec à partir du protocole ou du port.
• La qualité de service (QoS) mise en place sur le routeur ne peut pas utiliser les ports ou les
protocoles pour définir la priorité du trafic. L'utilisation d'adresses IP spécifiques reste néanmoins possible pour la hiérarchisation du trafic. Par exemple, tandis qu'une règle attribuant la priorité de « quiconque à quiconque utilisant le port 80 » ne fonctionnerait pas, une règle définissant une priorité de « quiconque à 10.0.1.10 » ne serait nullement affectée.
• Certains équipements ne prennent pas en charge ou n'autorisent pas le protocole IP 50, le port adopté par le protocole ESP (Encapsulating Security Payload).
• La technique WFQ (Weighted Fair Queuing) et d'autres méthodes de définition de la priorité du trafic sur routeur fondées sur le flux peuvent échouer.
• Les moniteurs réseau peuvent être incapables d'analyser les paquets ESP non chiffrés (ESPNull). Remarque : le Moniteur réseau Microsoft a ajouté un analyseur ESP à la version 2.1 destiné à faciliter la résolution des problèmes liés aux paquets IPSec non chiffrés. L'outil Moniteur réseau est fourni avec Microsoft Systems Management Server (SMS). Pour plus d'informations, consultez la page Microsoft Systems Management Server sur le site www.microsoft.com/smserver/.
• Si le système ne peut pas procéder à une analyse ESP, aucune liste de contrôle d'accès (ACL) spécifiant des règles de port ou de protocole n'est traitée dans les paquets ESP.
• Si le système dispose d'un analyseur ESP et utilise le chiffrement, les listes de contrôle d'accès qui spécifient des règles de port ou de protocole ne sont pas traitées dans les paquets ESP.
IPSec annule la définition des priorités fondées sur le réseau et la gestion du trafic fondée sur les ports et les protocoles lorsque des ports et des protocoles sont utilisés. Il n'existe malheureusement aucune solution alternative pour les paquets chiffrés. Si la gestion du trafic ou la définition des priorités doit être fondée sur les ports ou le protocole, l'hôte luimême doit être en mesure d'assumer ces fonctions de gestion du trafic et de hiérarchisation. Enfin, il est primordial d'enregistrer avec exactitude les informations nécessaires pour les divers périphériques du réseau. Périphériques de l'infrastructure réseau Les périphériques qui composent l'infrastructure réseau (routeurs, commutateurs, équilibreurs de charge et parefeu) communiquent avec IPSec après l'implémentation de la solution. C'est pourquoi il est primordial d'examiner les caractéristiques suivantes des périphériques du réseau pour s'assurer de leur capacité à gérer les exigences techniques et matérielles de la conception :
• Marque/modèle. Vous pouvez utiliser ces informations pour déterminer les fonctionnalités prises en charge par le périphérique. De plus, vérifiez le BIOS ou le logiciel exécuté sur le périphérique pour être certain qu'IPSec est pris en charge.
• Quantité de mémoire vive (RAM). Cette information peut être précieuse lorsque vous souhaitez évaluer la capacité ou l'impact d'IPSec sur le périphérique.
52
• Analyse du trafic. Ces informations (heure d'utilisation maximale et tendances quotidiennes et
hebdomadaires indiquant le taux d'utilisation journalier du périphérique) peuvent toujours s'avérer utiles. En rapport avec IPSec, les informations fournies offrent un aperçu du périphérique et de son utilisation sur une période donnée. Si des problèmes surgissent après l'implémentation d'IPSec, ces mêmes informations peuvent permettre de déterminer si les causes sont liées à une utilisation intensive du périphérique.
• Listes de contrôle d'accès (ACL) affectant directement IPSec. Les listes de contrôle d'accès
ont un impact direct sur la capacité de fonctionnement de certains protocoles. Par exemple, si vous n'autorisez pas le protocole Kerberos (protocole UDP (User Datagram Protocol) et port TCP 88) ou le protocole IP (le protocole, pas le port) 50 ou 51, IPSec ne fonctionnera pas. Les périphériques doivent également être configurés pour permettre la circulation du trafic IKE (UDP 500 et 4500) lorsque vous utilisez la traduction d'adresses réseau NATTraversal (NATT).
• Réseaux/sousréseaux connectés à des interfaces de périphériques. Ces informations vous
permettent d'effectuer la meilleure analyse possible de la structure du réseau interne. La définition des limites du réseau à partir d'une plage d'adresses est une opération simple et permet d'identifier si d'autres adresses sont non gérées ou étrangères au réseau interne (par exemple, les adresses Internet). Ces informations sont nécessaires pour les décisions de stratégies IPSec prises au cours des chapitres suivants du présent guide.
• Le périphérique autorise ou non la traduction d'adresses réseau (NAT). La traduction
d'adresses réseau est fréquemment utilisée pour soumettre une plage d'adresses tout entière en tant qu'adresse IP unique à un réseau connecté ou à Internet. Le planificateur de solutions doit savoir où ce processus intervient sur le réseau.
Remarque : l'article 818043 de la Base de connaissances Microsoft, « Mise à jour NATT pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000 » (http://support.microsoft.com/kb/818043) propose la fonctionnalité NATT en tant que correctif téléchargeable pour Windows XP Service Pack (SP) 1 et Windows 2000 SP4. En revanche, aucun répondeur IPSec ne fonctionnera correctement si vous n'avez pas installé Windows XP SP2 ou Windows Server 2003 SP1.
• Segmentation des réseaux locaux virtuels (VLAN). En déterminant le mode d'implémentation
actuel des réseaux locaux virtuels (VLAN) sur le réseau, vous comprendrez mieux les modèles de trafic ou les exigences de sécurité existantes et pourrez déterminer comment IPSec augmentera ces exigences ou sera potentiellement amené à interférer avec elles.
• Liens de connexion du périphérique. Ces informations vous permettront de détecter les
connexions que le périphérique entretient entre des réseaux spécifiques. Elles peuvent également être utilisées pour identifier le réseau logique et les connexions à divers emplacements d'une interface donnée.
• Taille de l'unité de transmission maximale (MTU) sur les interfaces des périphériques.
L'unité de transmission maximale (MTU) désigne le plus grand datagramme qu'il est possible de transmettre sur une interface donnée sans le diviser en plus petites unités de transmission (processus également appelé « fragmentation »). Dans les communications IPSec, le MTU a pour but de déterminer les zones dans lesquelles la fragmentation aura lieu. Le routeur doit suivre la fragmentation des paquets afin de détecter le protocole ISAKMP (Internet Security Association and Key Management Protocol). IPSec configure la taille MTU de la session selon le MTU minimal détecté dans le chemin de communication utilisé, puis définit le bit DF (Do not Fragment) à 1.
Remarque : si la découverte du PMTU (Path MTU) est activée et fonctionne comme il se doit, vous n'avez pas besoin de recueillir la taille MTU sur les interfaces des périphériques. Certaines sources, notamment le Windows Server 2003 Hardening Guide (Guide de renforcement de la sécurité de Windows Server 2003), recommandent de désactiver la fonction de découverte PMTU. En revanche, cette fonction doit être activée pour permettre à IPSec de fonctionner correctement.
53
Notez également qu'IPSec peut affecter un système IDS (système de détection d'intrusion) puisqu'un analyseur spécifique est nécessaire à l'interprétation des données à l'intérieur des paquets. Si le système IDS n'est pourvu d'aucun analyseur, il ne peut pas examiner les données de ces paquets pour déterminer si une session particulière est une menace potentielle. Dans ce cas, la décision d'utiliser IPSec indique que votre organisation a davantage besoin d'IPSec que du système IDS. Les informations identifiées dans cette section sont essentielles à la réussite du projet puisqu'elles vous permettent de comprendre la configuration actuelle et la santé de l'infrastructure du réseau avant même de configurer l'utilisation d'IPSec sur les périphériques concernés (ou d'y placer une charge supplémentaire s'ils sont déjà configurés pour la circulation du trafic IPSec). Par l'étude des informations relatives aux pics de charge, vous pouvez déterminer si le périphérique est en mesure d'utiliser IPSec dans son état actuel ou s'il exige une mise à niveau de la mémoire ou du microprogramme afin de supporter la charge attendue. Les informations sur la marque et le modèle s'avéreront utiles au moment de vous procurer le matériel de mise à niveau des périphériques (si nécessaire). Les informations sur les paramètres de configuration ou les fonctionnalités propres à cette marque et ce modèle peuvent également vous être utiles. Le nombre de listes de contrôle d'accès configurées sur les périphériques vous aidera à estimer l'effort requis pour configurer les périphériques afin de prendre en charge IPSec. Si aucun périphérique du réseau n'est configuré pour autoriser le trafic IPSec et que le réseau dispose d'un grand nombre de routeurs, la configuration des périphériques risque de représenter une importante charge de travail. Une fois ces informations à votre disposition, vous pouvez rapidement déterminer s'il est nécessaire ou non de mettre à niveau les périphériques afin qu'ils répondent aux exigences du projet, de modifier les listes de contrôle d'accès ou de prendre d'autres mesures pour vous assurer que les périphériques seront capables de gérer les charges qui leur seront confiées. Analyse du modèle de trafic réseau actuel Après avoir recueilli les informations d'adressage et d'infrastructure réseau, l'étape suivante consiste logiquement à examiner avec soin le flux des communications. Par exemple, si un service comme celui des ressources humaines s'étend sur plusieurs bâtiments et si vous souhaitez utiliser IPSec pour chiffrer les informations de ce service, vous devez savoir comment les bâtiments concernés sont connectés pour déterminer le niveau de « confiance » envers la connexion. Un bâtiment hautement sécurisé relié par un câble en cuivre à un autre bâtiment sans protection peut être la proie d'une écoute clandestine ou d'une attaque par relecture de données. Si une attaque de ce type représente une menace, IPSec peut fournir une authentification mutuelle renforcée et le chiffrement du trafic des hôtes approuvés. Néanmoins, la solution ne résout pas le fait qu'un manque de sécurité physique sur les hôtes approuvés constitue toujours une menace. Au moment d'examiner le flux de trafic, regardez de près comment tous les périphériques gérés et non gérés interagissent, y compris les périphériques nonWindows, tels que Linux, UNIX et Mac, ainsi que les versions Windows antérieures à Windows 2000 SP4. Posezvous certaines questions, notamment : certaines communications ontelles lieu au niveau du port ou du protocole ou bien existe til un grand nombre de sessions intervenant entre les mêmes hôtes sur un large éventail de protocoles ? Comment les serveurs et les clients communiquentils ensemble ? Existetil des systèmes de sécurité ou des projets actuellement mis en œuvre ou planifiés susceptibles d'avoir un impact sur le projet d'isolation ? Par exemple, l'utilisation de Windows XP SP2 et du Parefeu Windows pour "verrouiller" certains ports, tels que le port UDP 500, risque de provoquer l'échec de la négociation IKE. Lorsque vous appliquez le processus de modélisation des menaces décrit dans le chapitre 2 (« Présentation de l'isolation de serveurs et de domaines ») afin d'examiner les différents types de trafic réseau, vous pouvez aisément rechercher les protocoles et les applications qui génèrent un trafic devant être protégé contre les périphériques non approuvés ou non gérés. Certains des protocoles et des applications les plus fréquemment rencontrés sont les suivants :
54
• NetBIOS sur TCP/IP (NetBT) et SMB (Server Message Block). Dans un réseau local, on trouve souvent les ports 137, 138 et 139 activés pour NetBT et le port 445 activé pour SMB. En plus d'autres fonctionnalités, ces ports offrent des services de résolution des noms NetBIOS. Malheureusement, ils entraînent aussi la création de sessions NULL. Une session NULL est une session établie sur un hôte qui n'utilise pas le contexte de sécurité d'une entité ou d'un utilisateur connu. Ces sessions sont souvent anonymes.
• Appel de procédure distante (RPC). En règle générale, l'appel de procédure distante opère en
présentant un port d'écoute à une application (également appelé « mappeur de point de terminaison », port TCP 135) qui suggère alors à « l'appelant » (souvent une autre application) d'engager la communication sur un autre port de la plage éphémère. Dans un réseau segmenté par des parefeu, cette communication RPC soulève un véritable défi en termes de configuration puisqu'elle implique d'ouvrir le port d'écoute RPC et tous les ports audessus du port 1024. L'ouverture de tous ces ports augmente la surface exposée aux attaques sur la totalité du réseau et réduit l'efficacité des parefeu. En revanche, l'avantage de l'appel de procédure distante (RPC) est qu'il fournit les fonctionnalités des couches 1 à 4 du modèle OSI (Open Systems Interconnection) pour les applications qui l'utilisent, ce qui évite aux développeurs d'effectuer des appels de bas niveau sur le réseau pour leurs applications distribuées. Du fait que de nombreuses applications dépendent de l'appel de procédure distante (RPC) pour leurs fonctionnalités de base, la stratégie IPSec devra tenir compte du service RPC. Pour plus d'informations sur la création d'une stratégie IPSec, consultez le chapitre 5, « Création de stratégies IPSec pour les groupes d'isolation ».
• Autre trafic. IPSec peut sécuriser les transmissions entre hôtes en authentifiant les paquets en plus de chiffrer les données qu'ils contiennent. L'important est d'identifier ce qui doit être protégé et les risques à minimiser. Tout autre trafic ou type de trafic à sécuriser doit être examiné et modélisé comme il se doit. Il peut, par exemple, s'agir d'une base de données visant un objectif précis et à laquelle seuls quelques clients sont autorisés à accéder, ou bien d'une application spécialisée destinée aux ressources humaines et exclusivement réservée aux cadres de ce service. Après avoir documenté le réseau logique et physique, la prochaine étape consiste à examiner les modèles de trafic actuels et à répondre aux questions suivantes :
• Disposezvous à l'heure actuelle de sousréseaux dédiés à des types spécifiques de trafic (par exemple, des stations de travail Mac et UNIX ou des connexions entre ordinateur central et terminal) ?
• Avezvous besoin de séparer les différents types de trafic ou le trafic d'un emplacement à un autre ?
Active Directory Après le réseau, Active Directory est le deuxième élément clé à partir duquel il vous faudra rassembler des données. Vous devrez comprendre la structure des forêts, notamment l'agencement des domaines, l'architecture des unités d'organisation et la topologie du site. Ces informations permettent de connaître la position actuelle des ordinateurs, leur configuration et l'impact des modifications apportées à Active Directory suite à l'implémentation d'IPSec. La liste cidessous décrit les informations nécessaires à la réalisation de cette étape du processus de découverte.
• Nombre de forêts. Étant donné que la forêt est la limite de sécurité dans une implémentation Active Directory, il est nécessaire de comprendre l'architecture Active Directory actuelle pour déterminer les hôtes à isoler et les modalités de l'isolation.
• Noms et nombre de domaines. L'authentification IPSec intervient suite au processus de
négociation IKE. Dans cette solution, la méthode d'authentification est le protocole Kerberos. Ce protocole suppose que les ordinateurs sont associés à des domaines et qu'ils répondent aux
55
exigences de version requises en matière de système d'exploitation (Windows 2000, Windows XP ou Windows Server 2003).
• Nombre et types d'approbations. Connaître le nombre et les types d'approbations est crucial puisque les approbations affectent les limites logiques de l'isolation et permettent de définir la manière dont peut (ou doit) survenir l'authentification IKE dans la solution.
• Noms et nombre de sites. L'architecture du site s'aligne généralement sur la topologie du réseau. En maîtrisant le mode de définition des sites dans Active Directory, vous comprendrez mieux la réplication et d'autres processus. Dans cette solution, l'architecture du site offre une description plus approfondie de l'implémentation Active Directory tel qu'elle existe à l'heure actuelle.
• Structure d'unités d'organisation. Lorsque vous créez une structure d'unités d'organisation, un
minimum de planification permet d'augmenter considérablement l'efficacité opérationnelle. Les unités d'organisation sont des constructions logiques. Elles peuvent donc être modelées pour répondre à divers objectifs et exigences. La structure d'unités d'organisation est le laboratoire idéal à partir duquel vous pouvez examiner l'utilisation de la stratégie de groupe et l'agencement des unités d'organisation. Les chapitres 4 et 5 de cette solution décrivent l'architecture des unités d'organisation et expliquent en détail comment en faire usage pour appliquer la stratégie IPSec.
• Utilisation actuelle de la stratégie IPSec. L'objectif ultime de ce projet étant l'implémentation de
la stratégie IPSec, il est primordial que vous sachiez comment votre réseau exploite actuellement IPSec (si tel est le cas). Que vous utilisiez de simples filtres IPSec (comme ceux prescrits dans un guide de renforcement de la sécurité) ou implémentiez des stratégies complètes, la connaissance de votre utilisation actuelle et des conditions mêmes de cette utilisation permettront une intégration plus efficace dans la solution.
Le scénario de la Woodgrove Bank présente une seule et unique forêt (corp.woodgrovebank.com) composée de quatre domaines répartis sur cinq sites. Chaque site peut comporter un contrôleur de domaine (DC), un contrôleur principal de domaine (PDC) ou un serveur de catalogue global (GC) comme le montre le tableau cidessous. Tableau 3.1 : Informations Active Directory de la Woodgrove Bank Site physique
Domaine
Utilisateurs
Type de contrôleur de domaine
New York, NY
corp.woodgrovebank.com, americas.corp.woodgrovebank.com
5 000
Catalogue global racine de la forêt PDC GC régional, Amériques DC régional, Europe DC régional, Asie
Chicago, IL
americas.corp.woodgrovebank.com
750
GC régional, Amériques
Atlanta, GA
americas.corp.woodgrovebank.com
1 450
GC régional, Amériques
Boston, MA
americas.corp.woodgrovebank.com
480
GC régional, Amériques
San Francisco, CA
americas.corp.woodgrovebank.com
250
GC régional, Amériques
Pittsburgh, PA
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Phoenix, AZ
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Miami, FL
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Washington, DC
americas.corp.woodgrovebank.com
75
GC régional, Amériques
Cambridge, MA
americas.corp.woodgrovebank.com
36
GC régional, Amériques
Toronto, Canada
americas.corp.woodgrovebank.com
25
GC régional, Amériques
56
Londres, R.U.
europe.corp.woodgrovebank.com, corp.woodgrovebank.com
5 200
GC racine de la forêt Émulateur PDC GC régional, Europe DC régional, Amériques DC régional, Asie
Genève, Suisse
europe.corp.woodgrovebank.com
350
GC régional, Europe
Amsterdam, Pays Bas
europe.corp.woodgrovebank.com
295
GC régional, Europe
Munich, Allemagne
europe.corp.woodgrovebank.com
149
GC régional, Europe
Rome, Italie
europe.corp.woodgrovebank.com
80
GC régional, Europe
Dublin, Irlande
europe.corp.woodgrovebank.com
79
GC régional, Europe
Édimbourg, Écosse
europe.corp.woodgrovebank.com
40
GC régional, Europe
Johannesburg, Afrique du Sud
europe.corp.woodgrovebank.com
37
GC régional, Europe
Tokyo, Japon
asia.corp.woodgrovebank.com, corp.woodgrovebank.com
500
GC racine de la forêt Émulateur PDC GC régional, Asie DC régional, Europe DC régional, Amériques
HongKong, Chine
asia.corp.woodgrovebank.com
100
GC régional, Asie
Bangkok, Thaïlande
asia.corp.woodgrovebank.com
150
GC régional, Asie
Singapour
asia.corp.woodgrovebank.com
210
GC régional, Asie
Sydney, Australie
asia.corp.woodgrovebank.com
45
GC régional, Asie
Bangalore, Inde
asia.corp.woodgrovebank.com
35
GC régional, Asie
Taipei, Taïwan
asia.corp.woodgrovebank.com
65
GC régional, Asie
La structure Active Directory de la Woodgrove Bank utilisait les relations d'approbation bidirectionnelle automatiquement créées par la forêt. Aucune approbation supplémentaire entre forêts ou externe n'était disponible. La figure suivante donne un exemple de la structure d'unités d'organisation de haut niveau adoptée à la Woodgrove Bank. Cette structure a fait l'objet d'une utilisation cohérente sur les trois domaines régionaux principaux (Amériques, Europe et Asie).
57
Figure 3.2 Exemple de structure d'unités d'organisation Woodgrove Bank
Le projet d'isolation de serveurs et de domaines étant la première implémentation IPSec réalisée par la Woodgrove Bank, aucune stratégie IPSec active et existante n'était en place.
Détection d'hôtes L'avantage le plus précieux d'un projet de découverte des ressources est la quantité considérable de données recueillies sur les hôtes (stations de travail et serveurs) du réseau. Les décisions prises et décrites au chapitre 4, « Conception et planification de groupes d'isolation », exigeront des informations précises sur l'état de l'ensemble des hôtes afin de garantir leur aptitude à participer aux communications IPSec de la solution. Données requises concernant les hôtes Cette section décrit les informations nécessaires sur les hôtes et explique comment les représenter de manière physique et logique.
• Nom de l'ordinateur. Il s'agit du nom NetBIOS ou DNS de l'ordinateur permettant d'identifier ce
dernier sur le réseau. Du fait qu'un ordinateur peut disposer de plusieurs adresses MAC (Media Access Control) et/ou IP, le nom d'ordinateur constitue l'un des critères en fonction desquels vous pouvez déterminer l'unicité sur le réseau. Les noms des ordinateurs peuvent être dupliqués dans certaines circonstances de sorte que l'unicité ne soit pas jugée comme absolue.
• Adresse(s) IP de chaque carte d'interface réseau. L'adresse IP désigne l'adresse utilisée avec le masque de sousréseau pour identifier un hôte sur le réseau. Une adresse IP n'est pas une méthode efficace d'identification d'une ressource parce qu'elle est change fréquemment.
• Adresse MAC de chaque carte d'interface réseau. L'adresse MAC est une adresse 48 bits unique utilisée pour identifier une interface réseau. Elle peut servir à différencier plusieurs interfaces réseau sur le même périphérique.
• Système d'exploitation, service pack et versions de correctifs. La version du système
d'exploitation est un facteur clé permettant de déterminer l'aptitude d'un hôte à communiquer avec IPSec. Il est également primordial de contrôler l'état actuel des service packs et des correctifs susceptibles d'être installés car ces éléments sont souvent utilisés pour déterminer si les normes de sécurité minimales sont respectées.
• Appartenance au domaine. Ces informations sont utilisées pour déterminer si un ordinateur peut se procurer la stratégie IPSec à partir d'Active Directory ou s'il doit utiliser une stratégie IPSec locale.
58
• Emplacement physique. Cette information représente simplement l'emplacement du périphérique de votre organisation. Vous pouvez l'utiliser pour déterminer si un périphérique doit participer à un groupe d'isolation particulier en fonction de son emplacement ou de l'emplacement des périphériques avec lesquels il communique régulièrement.
• Type/rôle du matériel. Ces informations ne sont parfois pas accessibles via un processus
automatisé. Certains outils de détection d'hôtes peuvent permettre de les obtenir en sondant les informations liées au matériel, puis en exécutant des applications pour déterminer le type (serveur, station de travail ou Tablet PC). Vous pouvez également exploiter ces données afin d'évaluer le droit d'un ordinateur spécifique à participer au processus d'isolation et de définir le groupe d'isolation dans lequel le placer.
Remarque : les informations ayant trait au type de matériel sont obtenues par interpolation des données ou par le biais d'un logiciel soumettant des requêtes en vue de se procurer ces informations. Par exemple, il est évident qu'un HP Evo n800 est un ordinateur portable. Si vous avez la possibilité de soumettre une requête au niveau du matériel (ou de le munir d'une étiquette d'inventaire l'identifiant en tant que tel), vous pouvez plus facilement déterminer la stratégie IPSec appropriée à attribuer au périphérique. Après avoir collecté toutes ces informations et les avoir regroupées dans une base de données, procédez à intervalles réguliers à des opérations de détection afin de les tenir à jour. Vous aurez besoin d'un état complet et à jour des hôtes gérés sur les réseaux pour concevoir une solution conforme aux exigences de votre organisation. Vous pouvez employer diverses méthodes pour recueillir des données sur les hôtes du réseau. Il peut s'agir de systèmes haut de gamme entièrement automatisés ou bien d'un processus d'extraction des données entièrement manuel. En règle générale, le recours aux méthodes automatisées de recueil des données est préférable aux méthodes manuelles pour des raisons de vitesse et de sécurité. Néanmoins, quelle que soit la méthode adoptée, les informations requises restent les mêmes. La seule différence concerne le temps nécessaire à l'obtention de ces données. Les processus manuels soulèvent généralement plusieurs difficultés : risque d'informations en double, portée de l'effort engagé (tous les réseaux ontils été analysés ? Les informations recueillies concernentelles tous les hôtes ou simplement les sousréseaux de clients ?) et recueil des données en temps utile. L'étude de tous les éléments d'un audit complet du système informatique dépasse le cadre de ce projet. Cependant, il est important de comprendre que ces informations d'audit jouent un rôle crucial pour l'organisation, un rôle qui dépasse largement les seuls besoins de cette solution. Le suivi des ressources et la gestion des risques de sécurité sont deux exemples de processus clés qui justifient la nécessité d'un inventaire système actualisé et minutieux. Détection automatisée L'emploi d'un système de gestion réseau avec audit automatisé, tel que SMS, permet d'obtenir des informations précieuses sur l'état actuel de l'infrastructure informatique. Les systèmes automatisés posent cependant un problème lié au fait que les hôtes hors connexion, débranchés ou en état d'incapacité physique (ou logique) de répondre à des demandes d'information n'apparaissent pas dans la base de données finale. Même les systèmes les plus automatisés exigent un degré de gestion manuelle pour s'assurer que les hôtes sont accessibles et pris en compte comme il se doit. Nombre de produits et d'outils sont, dans ce domaine, proposés par divers fournisseurs. Certaines méthodes font appel à un mécanisme d'analyse centralisé, d'autres utilisent des agents installés sur les ordinateurs clients. L'objectif du présent guide n'est pas de comparer et de conseiller des produits à acheter mais la solution exige que les données de découverte et de détection détaillées dans ce chapitre soient disponibles pour les considérations de conception émises dans les chapitres 4 et 5. Pour plus d'informations sur la manière dont SMS 2003 peut contribuer à la gestion des ressources (ou aider à recueillir les informations nécessaires à ce projet), accédez à la démonstration et à la fiche
59
technique consacrée à la gestion des ressources à partir de la page SMS 2003 Asset Management (Gestion du parc informatique avec Systems Management Server 2003) à l'adressewww.microsoft.com/smserver/evaluation/capabilities/asset.asp. Détection manuelle La différence majeure entre les méthodes de détection manuelles et les méthodes automatisées est le temps. L'obtention manuelle des données requises pour ce projet peut mobiliser une bonne dizaine de personnes et exiger des jours ou des semaines, voire peutêtre plus dans une entreprise de plus grande échelle. Si vous envisagez de recourir à une méthode manuelle pour procéder à un audit de l'état actuel de votre infrastructure, il est primordial que les informations recueillies soient disponibles dans un format électronique (par exemple, dans une feuille de calcul ou une base de données). Le volume de données susceptible d'être généré peut rendre le processus de filtrage et d'analyse très fastidieux si vous ne parvenez pas à soumettre avec rapidité et précision des requêtes spécifiques capables de renvoyer les informations requises. Qui plus est, vous pouvez faire appel aux administrateurs informatiques pour vous procurer les informations ou valider toutes les informations recueillies précédemment. Même si votre organisation ne bénéficie pas d'un outil d'audit automatisé, il existe toujours une part d'automatisation possible via les interfaces de script et de gestion à distance standards disponibles sur la plateforme Windows. La principale difficulté liée à l'utilisation de ces outils est de veiller à n'oublier aucun client simplement parce qu'il n'est pas compatible avec le script ou l'outil de gestion. Vous pouvez utiliser l'environnement d'exécution de scripts Windows, Microsoft Visual Basic® Scripting Edition (VBScript) et Windows Management Instrumentation (WMI) pour créer un fichier de script capable de collecter des informations de configuration système. Le tableau cidessous décrit la disponibilité de VBScript et WMI par plateforme. Tableau 3.2 : Disponibilité de VBScript et WMI par plateforme Plateforme
VBScript
WMI
Windows 95
Installer WSH 5.6
Installer WMI CORE 1.5
Windows 98
Intégré
Installer WMI CORE 1.5
Windows Millennium
Intégré
Intégré
Microsoft Windows NT® version 4.0
Installer WSH 5.6
Installer WMI CORE 1.5
Windows 2000
Intégré
Intégré
Windows XP
Intégré
Intégré
Windows Server 2003
Intégré
Intégré
Remarque : vous pouvez télécharger la mise à jour de Microsoft Windows Script 5.6 depuis la page Microsoft Windows Script Downloads (téléchargements de Microsoft Windows Script) à l'adresse http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp. Vous pouvez télécharger également le fichier d'installation de Windows Management Instrumentation (WMI) CORE 1.5 depuis le Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46e2134cbf9c5b fbf236e0e875&DisplayLang=en.
60
Un exemple VBScript intitulé Discovery.vbs est fourni dans le dossier Tools and Templates de cette solution. Ce script utilise le service WMI pour extraire l'ensemble des données répertoriées dans la section « Données requises concernant les hôtes » de ce chapitre, à l'exception du rôle et de l'emplacement physique. Les informations sont rassemblées dans le fichier texte C:\Discovery\<systemname>_info.txt sur l'ordinateur local. Vous pouvez modifier le script pour collecter d'autres informations ou placer les informations collectées sur un partage de fichiers distant. Si WMI ou VBScript n'est pas disponible sur l'ordinateur hôte, vous pouvez recueillir certaines informations à l'aide d'un script de commandes et d'outils externes. La difficulté vient du fait que le langage de commandes est extrêmement limité en termes de fonctionnalités et que les informations de configuration ne sont pas faciles à extraire de la ligne de commande dans les versions antérieures de Windows. Pour procéder à une détection d'hôtes, il est nécessaire d'interroger les hôtes et de fournir un emplacement pour stocker les résultats obtenus. Que vous optiez pour une méthode de collecte des données manuelle, automatique ou hybride, l'une des plus grandes difficultés pour garantir la validité de la conception consiste à connaître les modifications survenues entre l'analyse d'inventaire d'origine et le début de l'implémentation. Une fois la première analyse terminée, vous devez informer votre personnel de support que toutes les modifications futures doivent être enregistrées et les mises à jour consignées dans l'inventaire. Cet inventaire est indispensable à la planification et l'implémentation des stratégies IPSec (sujets abordés dans les chapitres suivants).
Considérations relatives à la capacité Une fois le processus de collecte des informations achevé, vous devez vous intéresser à l'impact d'IPSec, notamment en termes de planification de la capacité. Cette section décrit certains des éléments essentiels d'une planification en bonne et due forme d'IPSec dans votre environnement.
Impact d'IPSec Du fait des diverses techniques cryptographiques auxquelles il fait appel, IPSec peut entraîner une consommation importante des ressources de l'ordinateur. Les scénarios qui exigeront une analyse plus profonde sont ceux qui préconiseront un chiffrement. Par exemple, un scénario peut envisager l'utilisation des algorithmes 3DES (Triple Data Encryption Standard) et SHA1 (Secure Hash Algorithm) pour vérifier l'intégrité dans des situations qui exigent la plus forte protection disponible en termes d'échange de clés et de chiffrement. Un autre scénario impliquera la négociation de l'association de sécurité. Vous pouvez opter pour une durée plus courte pour l'association de sécurité en mode principal (par exemple, trois heures) mais comme dans toutes considérations ayant trait à la sécurité, soyez prêt à faire des compromis. Chaque association de sécurité en mode principal consomme environ 5 Ko de mémoire vive (RAM). Une situation dans laquelle un serveur est contraint de négocier des dizaines de milliers de connexions simultanées peut entraîner une consommation abusive. D'autres facteurs concernent l'utilisation du processeur sur les serveurs de l'infrastructure réseau, la consommation accrue des ressources sur les serveurs et les stations de travail exécutant IPSec (surtout les serveurs puisque, dans la plupart des cas, ils comportent un plus grand nombre d'associations de sécurité en mode principal que les clients) et le temps de réponse du réseau plus long résultant de la négociation IPSec. Remarque : dans le cadre de son propre scénario de déploiement de cette solution, Microsoft a constaté qu'une augmentation possible (de l'ordre de un à trois pour cent) de la charge réseau est tout à fait normale. Cette augmentation est une conséquence directe de l'utilisation d'IPSec.
61
Un autre problème majeur concerne les réseaux reliés par un périphérique de traduction d'adresses réseau (NAT). Il vient du fait que la traduction d'adresses réseau (NAT) n'autorise pas les conversations d'authentification de l'entête (AH) entre les hôtes parce qu'elle est contraire au principe même du protocole AH : l'authentification d'un paquet inchangé, y compris l'entête. Si des périphériques NAT existent sur le réseau interne, préférez le protocole ESP au protocole AH. Le protocole ESP offre la possibilité de chiffrer les données mais n'exige pas le chiffrement. Ce facteur est essentiel en terme d'évaluation de la capacité puisque le chiffrement implique une surcharge dont il faut tenir compte pendant les phases de planification et de conception du projet. Le protocole ESP peut également être implémenté sans chiffrement et, ainsi, offrir la communication homologue à homologue la plus forte sans rompre les communications avec la traduction d'adresses réseau (NAT). Utilisé sans chiffrement, son impact serait donc plus faible qu'une solution ESP avec chiffrement.
Impact de la stratégie La stratégie IPSec et la stratégie de groupe ont toutes les deux un impact sur les temps de démarrage des ordinateurs et sur le temps nécessaire aux utilisateurs pour se connecter. Lors de la phase de recueil des données, il peut être utile de relever les temps de démarrage des ordinateurs et les temps de connexion des utilisateurs avant d'implémenter la solution. L'enregistrement de ces données fournira un élément de base avec lequel vous pourrez comparer les systèmes testés lors de l'étape pilote afin de déterminer l'impact sur le temps global nécessaire à un utilisateur pour se connecter.
Problèmes de prédéploiement Les sections précédentes décrivaient les informations à recueillir à partir du réseau, d'Active Directory et des hôtes pour garantir le succès d'un projet d'isolation. Cette section signale les domaines de préoccupation à examiner de près avant de déployer IPSec.
Infrastructure réseau Le recueil d'informations vous permet de planifier une isolation IPSec sur un réseau. Une fois ces informations collectées, vous pourrez procéder à une analyse minutieuse des données qui révèlera la majorité des problèmes auxquels vous serez confronté lors de la phase pilote et du déploiement. Bien que les éléments suivants ne soient pas exhaustifs, il est important de les prendre en considération au moment d'entamer l'analyse des informations recueillies avant les tests et le déploiement. Périphériques surexploités Vous devrez peutêtre mettre à niveau ou reconfigurer les commutateurs ou les routeurs exploités actuellement à plus de 75 pour cent pour permettre un trafic accru sur le périphérique et garantir une marge d'utilisation supplémentaire en cas de pointes de trafic. Dans le contexte d'une implémentation IPSec, la planification en bonne et due forme de la capacité est plus une affaire de tests et de charges de trafic anticipées que de calculs précis. Parce qu'il est fort improbable que le scénario, les modèles de trafic, les groupements d'utilisateurs et les applications soient les mêmes pour deux clients, une planification appropriée et la prise en compte de l'impact sur les périphériques du réseau sont indispensables. Par exemple, certains aspects d'IPSec sont totalement prévisibles. Chaque paquet utilisant IPSec avec ESP sera exactement 36 octets plus volumineux que le même paquet n'utilisant pas IPSec. Savoir que la création d'une seule association de sécurité en mode principal exige six messages permet de se représenter plus facilement quel sera l'impact de son utilisation sur un périphérique donné. Vous pouvez utiliser des outils tels que l'application PROVISO de Quallaby (disponible sur www.quallaby.com), ou d'autres solutions d'analyse réseau pour faciliter votre travail de planification de la capacité IPSec dans votre environnement informatique.
62
Périphériques incompatibles Les périphériques qui ne sont pas compatibles avec IPSec ne peuvent pas participer aux communications IPSec. Si ces périphériques ont besoin de communiquer avec un périphérique géré, placezles dans la liste d'exemptions IPSec. Une autre solution consiste à mettre à niveau le matériel ou les logiciels des périphériques afin qu'ils prennent en charge IPSec. Une autre encore est de permettre à ces périphériques non gérés de communiquer avec des ordinateurs voisins lorsqu'ils communiquent en texte clair pour leurs communications sortantes. Périphériques mal configurés Des périphériques mal configurés peuvent augmenter le risque d'échec des communications et de charge accrue sur le périphérique, mais aussi compromettre leur intégrité. Les méthodes de configuration, d'administration et de sécurité conseillées ciaprès permettront de réduire les risques. Adressage IP Parce que les adresses IP constituent la pierre d'angle d'une solution IPSec, il est primordial que l'adressage soit aussi net que possible. Des espaces d'adresses se chevauchant, des adresses en double, des masques de sousréseau incorrects et bien d'autres problèmes peuvent compliquer les opérations réseau classiques. L'apport d'IPSec à un réseau de ce type ne fera que compliquer le dépannage et incitera les utilisateurs à penser qu'IPSec est la source de tous ces problèmes. La croissance des entreprises, les fusions et les acquisitions, et bien d'autres facteurs encore, peuvent rapidement contribuer au développement d'une image fausse et obsolète de l'adressage IP sur un réseau. Pour éviter les problèmes majeurs liés à IPSec, assurezvous que le réseau est divisé en sousréseaux qui ne se chevauchent pas, que les tables de routage sont récapitulées comme il se doit et que l'agrégation par adresses est facile à déterminer.
Informations Active Directory Si l'implémentation actuelle d'Active Directory fonctionne correctement (résolutions des noms, DHCP (Dynamic Host Configuration Protocol), application de la stratégie de groupe, relations d'approbation, etc.), rien ne saurait affecter IPSec. Surveillez attentivement les modifications effectuées entre le moment où Active Directory a été examiné et le début du projet d'isolation pour vous assurer qu'aucun problème de compatibilité ne surviendra.
Informations concernant les hôtes Grâce aux sections précédentes, vous avez pu recueillir suffisamment d'informations sur les hôtes de votre réseau. Après avoir déterminé les clients et les serveurs aptes à utiliser IPSec, réfléchissez sur la manière de les isoler et aux applications nécessaires pour évaluer avec soin l'impact que la solution d'isolation peut avoir sur eux. Évaluation de la participation client/serveur Une fois les informations concernant les hôtes rassemblées, il est relativement simple de sélectionner les hôtes susceptibles d'être intégrés à la solution d'isolation. Par exemple, seuls des ordinateurs Windows 2000, Windows Server 2003 et Windows XP peuvent communiquer avec IPSec. Toutefois, tous les clients aptes à participer ne doivent pas nécessairement le faire. Une étape clé du processus de conception consiste à déterminer à partir des informations recueillies dans ce chapitre quels ordinateurs et périphériques seront inclus dans la solution et dans quel groupe ils résideront.
63
Définition des services devant être isolés Dans le contexte d'un projet d'isolation de serveurs et de domaines, un service désigne une application (par exemple, Microsoft Exchange Server, Microsoft SQL Server™ ou Internet Information Services/IIS) qui offre ses services à des clients du réseau. Vous devez évaluer ces services de manière individuelle afin de déterminer s'ils sont des candidats à l'isolation de serveurs et de domaines. Plusieurs raisons peuvent justifier l'intégration de ces services dans la solution. Cela peut être une question de stratégie d'organisation, d'exigence réglementaire ou d'impératif commercial. Par exemple, une stratégie de l'organisation peut stipuler que toutes les communications entre les serveurs de messagerie doivent être sécurisées avec IPSec, mais pas les communications entre les clients et les serveurs. Le chapitre 4, « Conception et planification de groupes d'isolation », aborde le processus d'isolation plus en détail. Lorsque vous tentez d'isoler des services, examinez avec soin les serveurs qui font intervenir plusieurs services, comme dans le cas d'un serveur de fichiers offrant des services Web et un service FTP (File Transfer Protocol) et faisant également office de serveur de messagerie. Équilibrage de la charge réseau et clusters Les organisations qui utilisent l'isolation de serveurs et de domaines peuvent choisir d'exclure les ordinateurs ayant recours à l'équilibrage de la charge réseau et aux clusters. IPSec n'est pas compatible avec l'équilibrage de la charge réseau en mode « sans affinité » puisqu'il empêche différents ordinateurs d'exploiter la même connexion cliente. Du fait de cette incompatibilité, il est préférable d'éviter l'équilibrage de la charge réseau en mode « sans affinité » avec IPSec. Gestion des exceptions La gestion des exceptions est une étape essentielle de la planification IPSec. Savoir où utiliser les ordinateurs qui autoriseront l'accès depuis les hôtes non approuvés et comment contrôler l'accès entre les ordinateurs gérés et non gérés est un paramètre essentiel de l'isolation. La meilleure méthode conseillée dans ce domaine est de maintenir le nombre d'exceptions aussi réduit que possible. Les besoins techniques peuvent exiger que certains ordinateurs ou services soient exemptés d'IPSec, notamment les contrôleurs de domaine et les serveurs DHCP, DNS et WINS. Étant donné la nécessité de gérer en permanence ces ordinateurs, le risque encouru est plus faible que d'autoriser les ordinateurs non gérés à communiquer avec des ordinateurs gérés et approuvés. Périphériques nonWindows La plupart des réseaux d'entreprise ne sont pas homogènes. Vous devez tenir compte de la diversité des éléments, tels que les systèmes d'exploitation, l'infrastructure réseau et les platesformes matérielles lorsque vous planifiez le déploiement d'IPSec. Si votre organisation possède des ordinateurs exécutant un système autre que Windows, vous devez comprendre que la consommation de la stratégie IPSec hors du domaine Windows n'est actuellement pas possible. Une organisation peut décider de faire face à cette restriction en traitant certaines platesformes comme approuvées mais la solution d'isolation de serveurs et de domaines ne les protègera pas puisque ces plates formes sont dans l'incapacité d'exploiter la stratégie IPSec. La section qui suit explique comment déterminer l'approbation. Périphériques de gestion et de contrôle Un aspect d'IPSec souvent ignoré lors de la phase de planification initiale est son impact sur la gestion et le contrôle du trafic du réseau. Parce qu'IPSec exige une authentification et autorise le chiffrement, certains périphériques ne sont plus en mesure de contrôler ou de gérer les ordinateurs activés avec IPSec. Dans certains cas exigeant un chiffrement, une organisation peut supposer que la sécurité est plus importante que le besoin opérationnel de contrôler les données tandis qu'elles transitent sur le réseau. Dans d'autres cas, il sera nécessaire d'évaluer les modifications que vous 64
pouvez apporter à une application ou un périphérique pour activer le contrôle IPSec (par exemple, un analyseur ESP capable d'examiner le trafic ESP). S'il s'avère impossible de mettre à niveau les périphériques de contrôle ou de gestion pour la prise en charge d'IPSec, il est crucial alors que vous enregistriez ces informations. L'architecte de la solution et l'équipe qui l'entoure auront besoin de ces informations au chapitre 4, « Conception et planification de groupes d'isolation ».
Définition de l'approbation Après avoir rassemblé des informations sur les périphériques hôtes qui composent actuellement votre infrastructure informatique, vous devez déterminer de manière fondamentale ce qui affecte directement la capacité d'un hôte à participer à la solution. L'objectif est de décider jusqu'à quel point un hôte peut être considéré comme approuvé. Le terme « approuvé » peut signifier différentes choses pour différentes personnes ; il est donc important de parvenir à une définition précise afin de la communiquer à toutes les parties prenantes. Ne pas le faire, c'est risquer d'exposer la sécurité de l'environnement approuvé à des problèmes puisque la sécurité globale ne peut aller audelà du niveau de sécurité défini par le client le moins sécurisé autorisé à adopter l'état approuvé. Pour comprendre ce concept, tenez compte des quatre états de base applicables aux hôtes d'une infrastructure informatique classique. Ces états sont (par degré de risque, avec le risque le plus faible en premier) les suivants :
1. Approuvé 2. Digne de confiance 3. Connu, non approuvé 4. Inconnu, non approuvé Le reste de cette section définit ces états et explique comment déterminer dans votre organisation quels hôtes appartiennent à quel état.
État Approuvé Le classement d'un hôte comme approuvé ne signifie pas que l'hôte en question est parfaitement sécurisé ou invulnérable. Fondamentalement, « approuvé » signifie que les risques de sécurité de l'hôte sont gérés. La responsabilité de cet état géré revient aux administrateurs et aux utilisateurs informatiques responsables de la configuration de l'hôte. Un hôte approuvé mal géré peut devenir une faiblesse et mettre en péril la solution tout entière. Lorsqu'un hôte est considéré comme approuvé, les autres hôtes approuvés doivent pouvoir légitimement partir du principe que cet hôte ne commettra aucun acte malveillant. Par exemple, des hôtes approuvés ne peuvent s'attendre à une attaque de virus de la part d'autres hôtes puisque tous les hôtes approuvés doivent recourir à des mécanismes (notamment un logiciel antivirus) visant à minimiser les risques de virus. La communication entre hôtes approuvés ne doit pas être gênée par l'infrastructure du réseau. Par exemple, si un hôte approuvé peut librement partir du principe qu'aucun autre hôte approuvé ne commettra d'acte malveillant à son encontre, le blocage des paquets au niveau IP destiné à limiter l'accès d'autres hôtes approuvés n'est généralement pas nécessaire. Vous devez appliquer toutes les restrictions nécessaires au contrôle des communications des hôtes par port ou protocole en utilisant un parefeu basé sur l'hôte sur l'ordinateur luimême, pas en utilisant IPSec. Dans le scénario imaginé pour la Woodgrove Bank, l'équipe de la sécurité a défini les cinq objectifs clés suivants afin de planifier les technologies nécessaires à l'hôte pour atteindre l'état approuvé : 65
• L'identité de l'ordinateur ou de l'utilisateur n'a pas été compromise. • Les ressources requises sont sécurisées et disponibles, quel que soit leur emplacement dans l'environnement géré.
• Une ressource jugée sécurisée est protégée contre tout risque de falsification, de virus ou de tentative d'accès non autorisé. • Une ressource signalée comme étant disponible respecte ou dépasse les niveaux attendus de durée active et est protégée contre toute faille de sécurité. • Un environnement considéré comme géré dispose d'ordinateurs dotés de Windows 2000 SP4 (ou une version ultérieure) et de la configuration et des correctifs appropriés.
• Les données et les communications sont privées, ce qui signifie que seuls les destinataires concernés peuvent lire et utiliser ces informations.
• Le propriétaire ou l'opérateur du dispositif comprend et accepte de se conformer aux stratégies et aux procédures afin de maintenir la confiance accordée à l'environnement.
• La réaction face aux risques et aux menaces intervient en temps utile. Forte de ces objectifs, l'équipe du support de la Woodgrove Bank a pu définir un ensemble d'exigences technologiques permettant de déterminer si un hôte peut être considéré comme approuvé. Au moment de définir l'état approuvé, assurezvous que les propriétaires des ressources impliquées sont libres de définir des conditions de sécurité supplémentaires répondant aux besoins commerciaux d'une ressource ou d'un actif donné. Par exemple, votre service des ressources humaines peut exiger un mécanisme d'ouverture de session biométrique pour des serveurs spécifiques. Cette exigence n'aura aucune incidence sur la confiance à accorder aux serveurs dans le contexte de cette solution. Néanmoins, vous devez rester vigilant et veiller à ce que les exigences d'une ressource particulière n'entrent pas en conflit avec celles de l'état approuvé. Consacrez un peu de temps à la définition des objectifs et des besoins technologiques que votre organisation juge convenables en tant que configuration minimale pour l'octroi de l'état approuvé à un hôte. Par exemple, l'équipe de conception a dressé cidessous la liste des exigences technologiques requises dans le cadre du scénario de la Woodgrove Bank.
• Système d'exploitation. Un hôte approuvé doit exécuter Windows XP SP2 ou Windows Server 2003, ou au minimum Windows 2000 SP4.
• Appartenance au domaine. Un hôte approuvé appartient à un domaine géré, ce qui signifie que le service informatique doit posséder des droits de gestion de la sécurité.
• Client de gestion. Tous les hôtes approuvés doivent exécuter un client de gestion réseau
spécifique pour permettre une gestion centralisée et un contrôle des stratégies de sécurité, des configurations et des logiciels.
• Logiciel antivirus. Tous les clients approuvés doivent être dotés d'un logiciel antivirus configuré
en vue de mettre à jour automatiquement et quotidiennement les derniers fichiers de signatures de virus.
• Système de fichiers. Tous les hôtes approuvés seront configurés avec le système de fichiers NTFS.
• Paramètres du BIOS. Tous les ordinateurs portables approuvés seront configurés avec un mot de passe au niveau du BIOS contrôlé par l'équipe du support informatique.
66
• Conditions requises pour les mots de passe. Les clients approuvés doivent utiliser des mots de passe forts.
Un élément essentiel à comprendre est le fait que l'état approuvé n'est pas constant. C'est un état de transition soumis à des normes de sécurité qui évoluent et au besoin de se conformer à ces normes. De nouvelles menaces et de nouveaux principes de défense apparaissent constamment. C'est pourquoi il est impératif que les systèmes de gestion de l'organisation vérifient en permanence les hôtes approuvés pour garantir une conformité continue. Qui plus est, ces systèmes doivent être capables d'émettre des mises à jour ou des changements de configuration s'ils sont chargés de maintenir l'état approuvé. Un hôte apte à répondre en permanence à l'ensemble des exigences de sécurité peut être considéré comme approuvé. Néanmoins, il est fort probable que la plupart des ordinateurs hôtes identifiés au cours du processus de détection et de découverte abordé plus haut dans ce chapitre ne répondent pas à ces exigences. Il est donc primordial de distinguer les hôtes qui peuvent être approuvés de ceux qui ne le peuvent pas (considérés alors comme non approuvés). Pour faciliter ce processus, vous pouvez définir un état Digne de confiance intermédiaire. Le reste de cette section aborde les différents états et leurs implications.
État Digne de confiance Si nécessaire, il peut être utile d'identifier au plus vite dans votre infrastructure actuelle les hôtes aptes à devenir approuvés. Un état Digne de confiance peut être attribué à l'hôte actuel pour confirmer son aptitude physique à devenir approuvé en effectuant les modifications requises au niveau des logiciels et de la configuration. Pour chaque ordinateur auquel vous attribuez un état Digne de confiance, pensez à ajouter une note de configuration consignant les conditions permettant à l'hôte d'atteindre l'état approuvé. Ces informations revêtent une importance toute particulière pour l'équipe de conception du projet (afin d'estimer les coûts résultant de l'ajout de l'hôte à la solution) et le personnel du support (pour pouvoir appliquer la configuration requise). En règle générale, les hôtes dignes de confiance tombent dans l'un des deux groupes suivants :
• Configuration requise. Le matériel utilisé, le système d'exploitation et le logiciel actuels
permettent à l'hôte d'atteindre un état Digne de confiance. En revanche, des changements de configuration supplémentaires sont nécessaires avant de parvenir aux niveaux de sécurité requis. Par exemple, si l'organisation exige un système de fichiers sécurisé avant de pouvoir considérer un hôte comme approuvé, un hôte avec un disque dur de format FAT32 ne pourra pas satisfaire cette exigence.
• Mise à niveau requise. Ce groupe d'ordinateurs exige des mises à niveau système avant d'être considéré comme approuvé. La liste suivante fournit quelques exemples sur le type de mise à niveau que les ordinateurs de ce groupe peuvent exiger :
• Mise à niveau du système d'exploitation requise. Si le système d'exploitation actuel de l'hôte n'est pas capable de prendre en charge les exigences de sécurité de l'organisation, une mise à niveau sera nécessaire pour que l'hôte puisse accéder à l'état approuvé. • Logiciel requis. Un hôte non doté de l'application de sécurité requise (par exemple, un outil d'analyse antivirus ou un client de gestion) ne peut être considéré comme approuvé tant que les applications nécessaires n'ont pas été installées et activées. • Mise à niveau matérielle requise. Dans certains cas, un hôte peut exiger une mise à niveau matérielle spécifique avant d'être déclaré comme approuvé. Il s'agit généralement d'une mise à niveau du système d'exploitation ou d'un logiciel supplémentaire forçant la mise à niveau matérielle requise. Par exemple, un logiciel de sécurité nécessitant un espace de stockage supplémentaire exigera davantage d'espace sur le disque dur.
67
• Changement d'ordinateur requis. Cette catégorie est réservée aux hôtes inaptes à satisfaire les exigences de sécurité de la solution du fait de leur incapacité matérielle à prendre en charge la configuration minimale acceptable. Il peut s'agir d'un ordinateur incapable d'exécuter un système d'exploitation sécurisé parce qu'il est doté d'un processeur trop ancien (par exemple, un ordinateur x86 de 100 mégahertz). Utilisez ces groupes pour répartir les coûts d'implémentation de la solution sur des ordinateurs exigeant des mises à niveau.
État Connu, non approuvé Lors du processus de catégorisation des hôtes d'une organisation, vous identifierez certains hôtes incapables de parvenir à un état approuvé pour des raisons bien connues et clairement définies. Ces raisons peuvent être de type suivant :
• Financier. Les fonds nécessaires à la mise à niveau du matériel ou des logiciels de cet hôte ne sont pas disponibles.
• Politique. L'hôte doit demeurer dans un état non approuvé en raison d'une situation politique ou
commerciale qui ne lui permet pas de satisfaire les exigences de sécurité minimales dictées par l'organisation. Nous vous conseillons alors fortement de contacter le responsable de l'entreprise ou le fournisseur de logiciels indépendant de l'hôte pour débattre de la valeur ajoutée de l'isolation de serveurs et de domaines.
• Fonctionnel. L'hôte a besoin d'exécuter un système d'exploitation non sécurisé ou d'opérer de
manière non sécurisée pour accomplir son rôle. Par exemple, l'hôte doit peutêtre être utilisé avec un système d'exploitation plus ancien en raison d'une série d'applications commerciales spécifiques ne fonctionnant que sur ce système.
Beaucoup de raisons fonctionnelles peuvent justifier le maintien d'un hôte en état connu non approuvé. La liste suivante présente quelques exemples de motifs fonctionnels susceptibles de justifier un classement dans cet état :
• Ordinateurs dotés de Windows 9x ou Windows Millennium Edition. Les ordinateurs munis de
ces versions particulières du système d'exploitation Windows ne peuvent pas être classées comme dignes de confiance car ces systèmes d'exploitation ne prennent en charge aucune infrastructure de sécurité de base. En fait, de par leur conception, ces systèmes ne disposent d'aucune infrastructure de sécurité. Qui plus est, les fonctions de gestion centrale rudimentaires dont ils sont pourvus ne concernent que des configurations informatiques pour utilisateurs (via la stratégie système et les scripts d'ouverture de session). Pour finir, ces systèmes d'exploitation n'offrent aucune des fonctionnalités requises pour la gestion de la sécurité.
• Ordinateurs dotés de Windows NT. Les ordinateurs dotés de Windows NT ne peuvent pas être
classés comme dignes de confiance dans le contexte de l'isolation de serveurs et de domaines puisque ce système ne prend pas intégralement en charge une infrastructure de sécurité élémentaire. Par exemple, Windows NT ne prend pas en charge les listes de contrôle d'accès de refus dans les ressources locales, toute méthode visant à garantir la confidentialité et l'intégrité des communications réseau, les cartes à puce pour une authentification renforcée ou une gestion centralisée des configurations d'ordinateurs (bien qu'une gestion centralisée limitée des configurations d'utilisateurs soit possible). Windows NT n'offre aucun moyen de protéger la confidentialité des données et de maintenir leur intégrité, tel que le système EFS (Encrypting File System) de Windows 2000.
En outre, il ne prend pas en charge l'ensemble des fonctionnalités de sécurité requises. Par exemple, il ne prend pas en charge la stratégie de groupe ou les stratégies IPSec et ne fournit aucun mécanisme garantissant un accès au niveau Administrateur local si cela est nécessaire. Enfin, ses
68
configurations de sécurité n'étant pas réappliquées régulièrement, il n'existe aucune garantie qu'elles demeurent effectives. Remarque : la description de Windows NT comme système n'étant pas digne de confiance se limite strictement au contexte de l'isolation de serveurs et de domaines et ne concerne d'aucune manière son utilisation en tant que système d'exploitation dans le sens large du terme. Pour les serveurs de ce projet, la mise à niveau vers la plateforme Windows Server 2003 représente la solution la plus sûre et la plus facile à gérer.
• Ordinateurs autonomes. Les ordinateurs dotés d'une version quelconque de Windows et
configurés comme ordinateurs autonomes ou en qualité de membres d'un groupe de travail sont, en règle générale, incapables de parvenir à un état digne de confiance. Même si ces systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, il est peu probable que les fonctionnalités requises pour la gestion de la sécurité soient garanties lorsque l'ordinateur n'est pas membre d'un domaine approuvé.
• Ordinateurs dans un domaine non approuvé. Un ordinateur membre d'un domaine qui n'est pas approuvé par le service informatique d'une organisation ne peut pas être classé comme approuvé. Un domaine non approuvé est un domaine qui n'offre pas les fonctionnalités de sécurité requises à ses membres. Même si les systèmes d'exploitation des ordinateurs membres de ce domaine non approuvé prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne peuvent pas être garanties à 100 % lorsque les ordinateurs ne résident pas dans un domaine approuvé. Par exemple, dans un domaine non approuvé, il n'existe aucun mécanisme garantissant l'octroi d'un accès de niveau Administrateur local pour un utilisateur approuvé. De même, les configurations de sécurité (y compris celles qui peuvent être gérées de manière centrale) peuvent facilement être remplacées par les administrateurs du domaine non approuvé. Enfin, le respect de la configuration de sécurité, des logiciels, des stratégies et des normes ne peut être garanti et les mesures chargées de contrôler de manière efficace toutes les règles de conformité ne sont pas disponibles.
• Ordinateurs dans un domaine Windows NT. Les ordinateurs membres d'un domaine fondé sur Windows NT ne peuvent pas être classés comme étant approuvés. Même si leurs systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne sont pas entièrement prises en charge lorsque les ordinateurs appartiennent à un domaine Windows NT.
Néanmoins, si l'hôte doit être pris en compte lors de la conception parce qu'il joue un rôle indispensable pour l'organisation, il est préférable que vous lui affectiez un état connu, non approuvé. Cela signifie alors que la solution a identifié un risque qu'elle ne peut minimiser. Vous devez faire appel à d'autres techniques pour répondre à cette menace connue. En raison de la nature variée des hôtes appartenant à cette catégorie, aucune instruction spécifique concernant ces techniques ne peut être fournie. Néanmoins, l'objectif de ces techniques doit être de minimiser les risques posés par cet hôte.
État Inconnu, non approuvé L'état Inconnu, non approuvé doit être utilisé comme état par défaut pour tous les hôtes. Du fait de la configuration inconnue des hôtes affichant cet état, aucune confiance ne peut leur être accordée. Le processus tout entier de planification des hôtes dans cet état doit partir du principe que l'hôte risquait ou risque d'être compromis et constitue, par conséquent, un risque inacceptable pour l'organisation. Les personnes chargées de concevoir la solution doivent s'efforcer de minimiser l'impact potentiel des ordinateurs dotés de cet état sur leurs organisations.
Identification des coûts de mise à niveau des hôtes actuels 69
L'ultime étape de ce chapitre concerne le processus d'enregistrement du coût approximatif de la mise à niveau des ordinateurs en vue de rendre ces derniers aptes à contribuer à la solution. Plusieurs décisions seront à prendre lors de la phase de conception du projet et exigeront que vous répondiez aux questions suivantes :
• L'ordinateur répondil aux exigences de configuration matérielle requises pour l'isolation ? • L'ordinateur répondil aux exigences de configuration logicielle requises pour l'isolation ? • Quelles modifications devezvous apporter à la configuration pour intégrer cet ordinateur à la solution d'isolation ?
• Quel coût prévisionnel ou impact suite aux modifications proposées peut permettre de parvenir à un état approuvé ?
En répondant à ces questions, vous pouvez rapidement déterminer le niveau d'effort et le coût approximatif requis pour intégrer un hôte ou un groupe d'hôtes particulier à l'échelle du projet. Il est fort probable qu'aucune personne, voire plusieurs personnes dans un seul rôle, ne rassemble toutes ces données. Certaines de ces données peuvent être recueillies par des techniciens du support technique ou d'un service de terrain ; d'autres exigeront le point de vue d'un architecte ou d'un membre de la direction. Gardez toujours à l'esprit que l'état d'un ordinateur est transitif et qu'en entreprenant les actions correctives présentées, vous pouvez changer l'état d'un ordinateur et le faire passer de non approuvé à approuvé. Après avoir décidé si un ordinateur doit être approuvé ou non, vous êtes p rêt à entamer le proce ssus de planification et de conception, thèmes que le chapitre 4 (« Conception et planification de groupes d'isolation ») aborde plus loin dans ce guide. Le tableau cidessous est un exemple de fiche à l'aide de laquelle vous pouvez identifier l'état actuel d'un hôte et les conditions de son passage à un état approuvé. Tableau 3.3 : Exemple de données collectées sur l'hôte Nom de l'hôte
Config. matérielle conforme
Config. logicielle conforme
Configuration. Détails requise
Coût prévisionnel
HOSTNYC 001
Non
Non
Mise à niveau matérielle et logicielle
Le système d'exploitation actuel est Windows NT 4.0. L'ancien matériel n'est pas compatible avec Windows XP SP2 .
$XXX.
SERVER LON001
Oui
Non
Intégrer Aucun logiciel domaine antivirus présent. approuvé, mettre à niveau de NT 4 vers Windows 2000 ou ultérieur.
$XXX.
La liste suivante explique chaque colonne du tableau 3.3 :
70
• Nom de l'hôte. Nom du dispositif hôte sur le réseau. • Configuration matérielle conforme. Indique si un ordinateur répond aux exigences de configuration matérielle requises pour participer à la solution.
• Configuration logicielle conforme. Indique si un ordinateur répond aux exigences de
configuration logicielle requises pour participer à la solution. Le minimum requis pour la Woodgrove Bank est Windows 2000 SP4, Windows XP SP2 ou Windows Server 2003, ainsi que tous les correctifs de sécurité requis pour chaque système d'exploitation. De plus, tous les ordinateurs doivent appartenir à un domaine approuvé (soit un domaine géré centralement par le personnel informatique de la Woodgrove Bank) et fournir de manière spécifique aux administrateurs informatiques un accès à l'ordinateur.
• Configuration requise. Indique quelle action entreprendre pour permettre à l'ordinateur d'atteindre l'état approuvé.
• Détails. Décrit les raisons pour lesquelles l'ordinateur n'affiche actuellement pas un état approuvé. • Coût prévisionnel. Indique le coût prévisionnel qui permettra au périphérique d'accéder à un état
approuvé. Ce coût doit inclure des estimations portant sur les logiciels, le matériel, la perte de productivité et le support. Ces informations permettront de déterminer s'il est pratique ou valable du point de vue commercial d'ajouter à la solution un ordinateur particulier en tant qu'ordinateur approuvé.
Dans le tableau précédent, l'hôte HOSTNYC001 est actuellement « connu, non approuvé ». Néanmoins, il peut être considéré comme digne de confiance si les mises à niveau requises sont possibles. Cependant, si un grand nombre d'ordinateurs exigent les mêmes mises à niveau, le coût global de la solution peut considérablement augmenter. L'hôte SERVERLON001 répond aux conditions matérielles requises mais doit être mis à niveau vers un système d'exploitation capable d'exploiter la stratégie IPSec et associé à un domaine. Il requiert également un logiciel antivirus. Le coût prévisionnel correspond à la somme des efforts requis pour mettre à niveau le système d'exploitation et installer des logiciels antivirus, plus le coût des licences du système d'exploitation et des logiciels antivirus. Après vous être procuré les informations décrites dans le tableau 3.3, enregistrezles avec les autres informations rassemblées au cours de ce chapitre afin que l'architecte ou l'équipe de conception puisse les exploiter. Ces informations constitueront la base des efforts entrepris au chapitre 4 qui se concentre sur la conception des groupes d'isolation. Notez que les coûts identifiés dans cette section concernent uniquement le coût prévisionnel des mises à niveau des hôtes. Beaucoup d'autres coûts liés à la conception, au support, aux tests et à la formation viendront se greffer au projet. Ces coûts supplémentaires devront être pris en compte dans le plan global du projet si un coût précis doit être évalué pour le projet.
Résumé Ce chapitre offre un aperçu des informations requises pour mener un projet d'isolation de serveurs et de domaines, notamment les considérations d'impact. Vous pouvez utiliser les instructions de ce chapitre pour effectuer les opérations suivantes :
• Identifier les ressources sur le réseau. • Rassembler des informations sur le réseau. • Rassembler des informations sur les hôtes.
71
• Définir les données du trafic actuel. • Examiner l'architecture Active Directory actuelle et recueillir des informations pertinentes la concernant.
• Examiner les éléments à considérer en terme de capacité IPSec. • Afficher les considérations de prédéploiement pour IPSec. • Expliquer ce que sont des dispositifs dignes ou non dignes de confiance et comment ils ont été classés dans le scénario imaginé pour la Woodgrove Bank.
La réalisation de ces tâches permettra de réunir toutes les informations dont vous aurez besoin pour lancer la conception de groupes d'isolation au chapitre suivant.
Informations complémentaires Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de l'implémentation de cette solution :
• Pour plus d'informations sur la configuration des parefeu pour la prise en charge d'IPSec pour
Windows Server 2003, consultez la page Configuring Firewalls (Configuration des parefeu) de la documentation Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/enus/dnsbj_ips_schx.asp.
• Vous pouvez télécharger le pack d'installation de Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46e2134cbf9c5b fbf236e0e875&DisplayLang=en.
• Pour plus d'informations sur WMI, consultez la documentation Windows Management
Instrumentation sur MSDN® à l'adresse http://msdn.microsoft.com/library/enus/wmisdk/ wmi/wmi_start_page.asp.
• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 2000 et XP
depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx? FamilyId=C717D9437E4B462286EB95A22B832CAA&displaylang=en.
• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 98, Windows Millennium Edition et Windows NT 4.0 depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyId=0A8A18F6249C4A72BFCF FC6AF26DC390&displaylang=en.
• Vous pouvez télécharger la documentation de Windows Script 5.6
depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx? FamilyId=01592C48207D4BE18A761C4099D7BBB9&displaylang=en.
72
Chapitre 4 : Conception et planification de groupes d'isolation Ce chapitre détaille la définition de groupes d'isolation répondant aux exigences de sécurité commerciale décrites dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ». Cette solution utilise une combinaison de l'identité de l'ordinateur dans le domaine de service d'annuaire Active Directory®, de la stratégie IPSec pour authentifier cette identité et de la stratégie de sécurité Microsoft® Windows® pour définir et appliquer des groupes d'isolation. Les administrateurs informatiques peuvent utiliser le concept de groupes d'isolation pour gérer le trafic dans leurs réseaux internes de manière sécurisée transparente aux applications. Cette possibilité peut réduire sensiblement la menace de dommages provenant d'infections et d'attaques via le réseau. Par le biais du scénario Woodgrove Bank, ce guide fournit les principaux détails sur la manière dont une organisation peut transformer ses exigences de sécurité en groupes d'isolation déployés. Il indique également comment IPSec peut être combiné à d'autres paramètres de sécurité pour élaborer une solution d'isolation de serveurs et de domaines détaillée, maniable et évolutive. Chaque organisation devra élaborer la solution en fonction des exigences qui lui sont propres, et les modèles utilisés dans ce guide ne sont pas destinés à être suivis sans question ni modification. Les organisations utilisant ce guide devront déterminer ce qui est requis et possible dans leur propre environnement, et apporter les modifications appropriées à la conception du modèle de groupe d'isolation en vue de l'adapter au mieux aux exigences spécifiques de leur activité.
Connaissances préalables requises pour ce chapitre Cette section contient des informations qui vous aideront à déterminer l'approche de votre organisation par rapport à la solution d'isolation de serveurs et de domaines. La réussite de la solution dépend des conditions préalables requises identifiées dans cette section.
Connaissances requises Vous devez connaître les concepts et la terminologie associés à IPSec. Il est également important d'avoir des connaissances concernant Microsoft Windows Server™ 2003 dans les domaines suivants :
• Stratégie et filtres IPSec, actions de filtrage et listes de filtres • Concepts relatifs à Active Directory (notamment la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et d'autres objets Active Directory, les services de résolution de noms et utilisation d'une stratégie de groupe)
• Concepts d'authentification, comprenant le processus d'ouverture de session de Windows et le protocole Kerberos version 5
• Sécurité du système Windows (concepts de sécurité tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande).
Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les chapitres précédents de ce guide.
73
Conditions requises pour l'organisation Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans l'implémentation de cette solution, notamment :
• les cadres exécutifs ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau et du DNS (Domain Name System).
Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles. Cependant, il est important d'identifier un seul point de contact pour aider à coordonner les efforts des équipes d'organisation à travers les diverses phases du projet. Ce chapitre suppose également que vous avez satisfait les exigences répertoriées dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines », et le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », notamment la collecte d'informations à partir des hôtes, du réseau et d'Active Directory. Le recensement des exigences commerciales et l'obtention du support de la direction sont également abordés. Enfin, vous devez disposer d'un plan en place pour former les divers personnels d'assistance et de support aux nouveaux concepts, terminologies et technologies de cette solution. Cette solution affectant de nombreux domaines de l'organisation, le personnel de support doit être formé pour gérer tout problème apparaissant durant le déploiement.
Configuration requise pour l'infrastructure informatique Ce chapitre suppose l'existence de l'infrastructure informatique suivante :
• Un domaine Active Directory Windows Server 2003 fonctionnant en mode mixte ou natif. Cette
solution utilise des groupes universels pour l'application de l'objet Stratégie de groupe. Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de groupes globaux et locaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ipsec_whatsnew.asp.
Création de la conception d'isolation de serveurs et de domaines La conception de la solution dépend largement des exigences de l'entreprise et des informations collectées dans les chapitres précédents. Le chapitre 2, « Présentation de l'isolation de serveurs et de domaines », et l'annexe D, « Catégories de menaces informatiques », décrivent les composants de la
74
solution et identifient les menaces auxquelles elle peut ou non répondre. Le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », fournit des informations sur la manière de collecter des données de planification, telles que l'architecture réseau actuelle et les ressources d'hôtes sur le réseau. Ce chapitre utilise les informations et exigences collectées pour Woodgrove Bank, qui sont enregistrées en détail dans le fichier Business_Requirements.xls (disponible dans le dossier Tools and Templates). Reportezvous à ce fichier durant le processus de conception détaillé dans ce chapitre pour mieux comprendre les choix effectués pour la conception de la solution. Le processus de conception de la solution implique les principales tâches suivantes :
• Modélisation de groupes de base • Planification des groupes d'ordinateurs et d'accès au réseau • Création de groupes d'isolation supplémentaires • Modélisation des exigences de trafic réseau • Affectation de membres au groupe d'ordinateurs et au groupe d'accès réseau Les sections suivantes expliquent chacune de ces tâches.
Modélisation de groupes de base Pour la plupart des implémentations, il est recommandé de se baser sur un point de départ commun pour les groupes d'isolation initiaux. L'illustration suivante présente les deux groupes d'isolation initiaux à envisager.
Figure 4.1 Groupes d'isolation de base
Les groupes de base offrent des conteneurs logiques constituant un excellent point de départ pour la conception de groupes d'isolation.
75
Systèmes non approuvés Conceptuellement, le mieux est de commencer par les ordinateurs non détenus, ni gérés, voire ceux dont l'existence est inconnue du service informatique de l'organisation. Ces ordinateurs sont généralement désignés comme hôtes non approuvés ou non gérés et sont les premiers systèmes à identifier dans la conception. Ils ne feront pas partie de la solution car ils ne seront pas en mesure d'utiliser les stratégies IPSec affectées par le domaine. Exemples d'ordinateurs rattachés à ce groupe :
• Ordinateurs et périphériques non Windows. Les stations de travail Macintosh et UNIX ainsi que les assistants numériques personnels (PDA) peuvent ne pas disposer de fonctionnalités IPSec prêtes à l'emploi.
• Anciennes versions du système d'exploitation Windows. Les ordinateurs exploitant Microsoft Windows NT® version 4.0 et Windows 9x ne peuvent pas utiliser IPSec basé sur une stratégie de groupe.
• Ordinateurs Windows non rattachés à un domaine approuvé. Les ordinateurs autonomes ne
seront pas en mesure de s'authentifier à l'aide d'une approbation de domaine Kerberos dans Internet Key Exchange (IKE). Un ordinateur rattaché à un domaine non approuvé par la forêt utilisée comme limite sécurisée pour l'authentification IKE ne sera pas en mesure de participer à la solution d'isolation de domaines ou de serveurs.
• Autres clients VPN ou d'accès distant non Microsoft. Si un client de réseau privé virtuel (VPN)
IPSec non Microsoft est utilisé pour une solution d'accès distant d'une organisation, l'installation a probablement désactivé le service IPSec Windows natif. Si le service IPSec Windows natif ne peut pas être utilisé, l'hôte ne pourra pas participer à cette solution.
Même si le service IPSec Windows natif est actif, le client VPN doit permettre la communication IKE et IPSec de bout en bout via la connexion de tunnel VPN. Si IPSec de bout en bout ne fonctionne pas via la connexion VPN, il est possible de créer une exemption pour tous les sousréseaux IP utilisés pour l'accès distant. Lorsque ce client distant se reconnecte au réseau interne, il peut à nouveau participer à la solution d'isolation. Domaine d'isolation Le domaine d'isolation offre le premier conteneur logique pour les hôtes approuvés. Les hôtes de ce groupe utilisent une stratégie IPSec pour contrôler les communications entrantes et sortantes autorisées. Le terme domaine est utilisé dans ce contexte pour représenter une zone de confiance plutôt que pour suggérer un domaine Windows. Dans cette solution, les deux constructions sont très similaires car l'authentification de domaine Windows (Kerberos) est requise pour accepter les connexions entrantes d'hôtes approuvés. Cependant, de nombreux domaines (ou forêts) Windows peuvent être liés à des relations de confiance pour fournir un seul domaine d'isolation logique. Ils ne doivent donc pas être confondus. L'objectif des caractéristiques de communications du domaine d'isolation est de fournir les règles « normales » ou standards pour la majorité des ordinateurs de l'organisation. Ainsi, pour la plupart des implémentations, un domaine d'isolation contiendra le plus grand nombre d'ordinateurs. D'autres groupes d'isolation peuvent être créés pour la solution si leurs exigences de communication sont différentes de celles du domaine d'isolation. Conceptuellement, un domaine d'isolation est juste un type de groupe d'isolation.
76
Groupe de limite Presque toutes les organisations comprennent un certain nombre de stations de travail, ou serveurs, incapables de communiquer via IPSec. C'est par exemple probablement le cas des ordinateurs tels que les stations de travail Mac ou UNIX. Ces ordinateurs doivent souvent communiquer dans l'entreprise avec des hôtes approuvés du domaine d'isolation. Dans un monde idéal, tous les hôtes du réseau interne seraient en mesure d'être approuvés au même niveau et d'utiliser IPSec, et la conception serait plus simple. Cependant, dans la réalité, tous les systèmes d'exploitation n'offrent pas le même degré de prise en charge d'IPSec. Dans cette situation, il est recommandé de créer un groupe d'isolation (désigné comme groupe de limite dans ce guide) contenant les hôtes qui seront autorisés à communiquer avec des systèmes non approuvés. Ces hôtes seront exposés à un niveau de risque supérieur, car ils peuvent recevoir des communications entrantes provenant directement d'ordinateurs non approuvés. Les ordinateurs du groupe de limite sont des hôtes approuvés pouvant communiquer à la fois avec d'autres hôtes approuvés et avec des hôtes non approuvés. Les hôtes du groupe de limite tenteront de communiquer à l'aide d'IPSec en lançant une négociation IKE avec l'ordinateur d'origine. Si aucune réponse IKE n'est reçue dans les trois secondes, l'hôte communique en texte clair et tente alors d'établir des communications en texte clair sans IPSec. Les hôtes du groupe de limite peuvent avoir une adresse IP dynamique car ils utilisent une stratégie IPSec comme tout autre hôte approuvé du domaine d'isolation. Puisque ces hôtes du groupe de limite seront autorisés à communiquer avec des hôtes approuvés utilisant des communications réseau sécurisées par IPSec et des hôtes non approuvés utilisant les communications en texte clair, ils doivent être hautement sécurisés par d'autres moyens. La compréhension et l'atténuation de ce risque supplémentaire doivent constituer une part importante du processus de décision du placement éventuel d'un ordinateur dans le groupe de limite. Par exemple, la définition d'un processus de justification d'entreprise formel pour chaque ordinateur avant de convenir de le placer dans ce groupe peut aider à garantir que toutes les parties concernées comprennent pourquoi ce risque supplémentaire doit être pris. L'illustration suivante montre un exemple de processus pouvant faciliter une telle décision.
77
Figure 4.2 Organigramme décisionnel d'exemple de processus d'appartenance au groupe de limite
L'objectif de ce processus est de déterminer si le risque d'ajout d'un hôte au groupe de limite peut être atténué à un niveau acceptable pour l'organisation. En dernier ressort, il doit être supposé que si le risque ne peut pas être atténué, l'appartenance au groupe doit être refusée.
78
Création de listes d'exemptions Les modèles de sécurité d'isolation de serveurs et de domaines subissent tous quelques contraintes lorsqu'ils sont implémentés dans un environnement réel. Les principaux serveurs d'infrastructure tels que les contrôleurs de domaine et les serveurs DNS et DHCP (Dynamic Host Configuration Protocol) sont généralement disponibles pour tous les systèmes du réseau interne. Il est évident qu'ils doivent être sécurisés au maximum contre les attaques réseau. Cependant, comme ils sont disponibles pour tous les systèmes du réseau, et non simplement les membres du domaine, ces services de serveur ne peuvent pas exiger IPSec pour l'accès entrant, ni profiter de l'utilisation de la protection du mode de transport IPSec pour tout leur trafic. Parce qu'un délai de basculement en clair de trois secondes pour accéder à ces services, en particulier DNS, aurait un sérieux impact sur les performances de tout l'accès au réseau interne, ils ne sont pas candidats pour le groupe de limite. De plus, les hôtes approuvés exigent un accès au serveur DHCP pour obtenir une adresse IP (Internet Protocol) durant le démarrage de l'ordinateur ou lorsque le câble ou la carte réseau est branché(e) sur un ordinateur portable. Les hôtes approuvés exigent également DNS pour localiser les contrôleurs de domaine afin de pouvoir se connecter au domaine et recevoir des informations d'identification Kerberos. Par conséquent, une liste de serveurs et de services (protocoles) exempts d'utiliser IPSec sera requise pour qu'IPSec fonctionne correctement, ainsi que pour permettre à tous les hôtes internes de partager l'infrastructure commune de réseau interne. La liste d'ordinateurs qui ne peuvent pas être sécurisés avec IPSec est appelée liste d'exemptions et est implémentée dans chaque stratégie IPSec conçue. Il peut également y avoir d'autres serveurs sur le réseau auxquels des hôtes approuvés ne peuvent pas accéder à l'aide d'IPSec, qui doivent être ajoutés à la liste d'exemptions. En général, un hôte doit figurer dans la liste d'exemptions s'il répond à l'une des conditions suivantes :
• L'hôte est un ordinateur auquel des hôtes approuvés doivent accéder, mais qui ne possède pas d'implémentation IPSec compatible.
• L'hôte fournit des services pour des hôtes non approuvés et approuvés, mais ne répond pas aux critères d'appartenance du groupe d'isolation de limite.
• L'hôte est utilisé pour une application affectée par le délai de 3 secondes avant retour à la communication en clair ou par l'encapsulation IPSec du trafic de l'application.
• L'hôte prend en charge plusieurs milliers de clients simultanément et il a été déterminé qu'IPSec ne pouvait pas être utilisé en raison de l'impact sur les performances.
• L'hôte gère des hôtes approuvés de différents domaines d'isolation ne s'approuvant pas mutuellement.
• L'hôte est un contrôleur de domaine, car IPSec n'est actuellement pas pris en charge entre un
contrôleur de domaine et un membre de domaine. Cependant, les contrôleurs de domaine satisfont d'autres critères de cette liste et offrent également la stratégie IPSec aux membres du domaine et l'authentification Kerberos sur laquelle est basé le concept d'isolation.
• L'hôte gère des hôtes approuvés et non approuvés, mais il n'utilisera jamais IPSec pour sécuriser des communications avec des hôtes approuvés.
L'implémentation IPSec de Windows gère uniquement le filtrage statique, et non dynamique (ou avec état). Par conséquent, une exemption statique pour le trafic sortant est également une exemption statique pour le trafic entrant. Les hôtes exemptés disposent par conséquent d'un accès entrant non authentifié sur chaque hôte, approuvé ou non. Ainsi, le nombre d'hôtes exemptés doit être aussi restreint que possible, et ces hôtes doivent être gérés de près et renforcés autant que possible contre les attaques et infections. Pour aider à atténuer le risque d'attaques entrantes provenant d'hôtes de la liste d'exemptions, un parefeu de filtrage avec état basé sur l'hôte, tel que le Parefeu Windows, peut être utilisé. Windows XP Service Pack (SP) 2 a fourni des contrôles de stratégie de groupe basée sur le domaine pour la configuration du parefeu. Le Parefeu Windows prend également en charge la possibilité d'autoriser uniquement certains ordinateurs via le parefeu lors de la protection par IPSec, à l'aide du paramètre de stratégie « Parefeu Windows : autoriser à ignorer la sécurité IPSec 79
authentifiée ». Woodgrove Bank a choisi de ne pas implémenter le Parefeu Windows. Cependant, d'autres environnements peuvent trouver nécessaire d'atteindre des niveaux de sécurité élevés dans un domaine ou un groupe isolé. Pour plus d'informations, reportezvous au livre blanc « Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 » (Déploiement de paramètres du Parefeu Windows pour Microsoft Windows XP avec Service Pack 2) depuis le centre de téléchargement de Microsoft à l'adresse http://go.microsoft.com/fwlink/?LinkId=23277. Dans les organisations de taille importante, la liste d'exemptions peut s'allonger considérablement si toutes les exemptions sont implémentées par une stratégie IPSec pour l'ensemble du domaine ou pour toutes les forêts approuvées. Une longue liste produit un certain nombre d'effets indésirables sur chaque ordinateur recevant la stratégie, notamment :
• Elle réduit l'efficacité globale de l'isolation. • Elle alourdit la charge de gestion (suite aux fréquentes mises à jour). • Elle augmente la taille de la stratégie, ce qui signifie qu'elle consomme plus de mémoire et de ressources processeur, ralentit le débit du réseau, et allonge le délai de téléchargement et d'application de la stratégie.
Pour maintenir le nombre d'exemptions aussi bas que possible, vous avez plusieurs possibilités :
• N'utilisez pas d'exemption si les communications peuvent résister au délai de 3 secondes avant retour à la communication en clair. Cette option ne s'applique pas aux contrôleurs de domaine.
• Considérez avec soin les exigences de communications de chaque groupe d'isolation, en
particulier des groupes serveur uniquement. Ils peuvent ne pas avoir à communiquer avec chaque exemption de la stratégie de niveau domaine des clients.
• Consolidez les fonctions de serveur. Si plusieurs services exempts peuvent résider sur la même adresse IP, le nombre de filtres sera réduit.
• Consolidez des hôtes exemptés sur le même sousréseau. Lorsque le volume de trafic réseau l'autorise, les serveurs peuvent résider sur un sousréseau exempté, au lieu d'utiliser des exemptions pour chaque adresse IP.
Comme pour la définition du groupe de limite, un processus formel est souhaitable pour approuver les hôtes ajoutés à la liste d'exemptions. Reportezvous à l'organigramme décisionnel de l'illustration précédente comme modèle pour le traitement des demandes d'exemptions.
Planification des groupes d'accès aux ordinateurs et au réseau Le domaine d'isolation et chaque groupe d'isolation doivent avoir des spécifications claires et complètes des exigences de sécurité réseau. La feuille de calcul Business_Requirements.xls du dossier Tools and Templates fournit un modèle de la manière dont les exigences peuvent être référencées. Une fois les exigences entrantes et sortantes décrites, vous pouvez concevoir les mécanismes d'implémentation des contrôles d'accès. À ce stade du processus, il est conseillé de commencer à recenser les nouveaux groupes Active Directory qui seront requis pour répondre aux exigences de groupe d'isolation. Pour chaque groupe d'isolation, vous devrez créer jusqu'à trois groupes Active Directory spécialisés. La section suivante explique le rôle de chacun de ces groupes.
80
Groupes d'ordinateurs Chaque groupe d'isolation nécessitera la création d'un groupe d'ordinateurs qui sera utilisé pour contenir les membres du groupe d'isolation. Ceci est requis car les exigences de sécurité d'un groupe d'isolation sont remplies par plusieurs types de paramètres de sécurité dans des objets Stratégie de groupe affectés dans le domaine. Par exemple, cette solution utilise un filtrage de groupe de sécurité sur les objets Stratégie de groupe pour fournir une stratégie IPSec aux ordinateurs d'un groupe d'isolation particulier. Les comptes d'ordinateurs membres du groupe d'ordinateurs se verront affecter la stratégie IPSec associée lors du traitement de l'objet Stratégie de groupe. Ceci évite d'avoir à changer ou créer une nouvelle structure d'unité d'organisation (UO) basée sur l'appartenance à un groupe d'isolation pour appliquer les objets Stratégie de groupe corrects. Si la structure d'UO peut être modifiée pour refléter l'appartenance au groupe d'isolation, ces groupes de sécurité d'ordinateurs ne sont pas requis pour contrôler l'application de la stratégie de groupe. Tableau 4.1 : Groupes d'ordinateurs Woodgrove Bank Nom du groupe d'ordinateurs
Description
CG_IsolationDomain_Computers
Ce groupe universel contiendra tous les ordinateurs faisant partie du domaine d'isolation.
CG_BoundaryIG_Computers
Ce groupe contiendra tous les ordinateurs autorisés à accepter une communication de systèmes non approuvés.
Groupes d'accès au réseau L'utilisation d'IPSec et de Kerberos seuls fournit une limite d'authentification approuvée et non approuvée. Pour aider à différencier ce groupe de tout autre, ce guide désigne ces groupes en tant que groupes d'accès réseau. Vous pouvez créer deux types de groupes d'accès réseau : Autoriser et Refuser. Ces groupes contrôlent la capacité d'autres systèmes approuvés à autoriser ou refuser explicitement l'accès. Ce contrôle est obtenu en utilisant le droit d'utilisateur « Interdire l'accès à cet ordinateur à partir du réseau » (REFUSER) ou « Accéder à cet ordinateur à partir du réseau » (AUTORISER) dans la stratégie de groupe. Techniquement, ce contrôle d'accès par droit d'utilisateur s'applique uniquement aux services réseau recevant des informations d'identification de connexion pour authentifier le compte pour l'ouverture de session réseau. Le « compte » peut être un compte d'ordinateur, d'utilisateur ou de service. Lorsque la stratégie IPSec est configurée pour protéger tout le trafic, IKE confirmera que l'ordinateur distant possède un droit de connexion réseau. Par conséquent, le droit de connexion réseau contrôle désormais la possibilité pour un ordinateur distant d'établir des connexions protégées par IPSec. Une fois ce contrôle d'accès de niveau IP vérifié, les protocoles de niveau supérieur normaux (par exemple, le partage de fichiers) authentifient en général l'utilisateur, ce qui évalue à nouveau les droits de connexion réseau de l'identité d'utilisateur. Enfin, les autorisations spécifiques au service (telles que les listes de contrôle d'accès au partage de fichiers) sont évaluées à l'aide de l'identité de l'utilisateur. Pour plus d'informations, reportezvous au diagramme Protection renforcée avec l'isolation logique dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ». Par défaut, le droit d'utilisateur AUTORISER contient le groupe Tout le monde, qui autorise tous les utilisateurs et ordinateurs authentifiés à accéder à l'ordinateur. Durant l'implémentation de cette solution, le groupe Tout le monde sera remplacé via l'affectation de droits d'utilisateur de stratégie de groupe par des groupes d'accès réseau contenant des ordinateurs ou utilisateurs et groupes spécifiques, selon les exigences de l'organisation. De même, le droit d'utilisateur REFUSER
81
contiendra des ordinateurs non supposés disposer d'un accès entrant protégé par IPSec. Bien qu'il soit possible d'utiliser un seul groupe pour contenir les comptes d'utilisateurs et d'ordinateurs, Microsoft recommande l'utilisation de groupes distincts, un pour les utilisateurs et un pour les ordinateurs. Cette approche améliore la possibilité de gérer et prendre en charge ces stratégies et groupes en continu. La configuration de l'affectation des droits d'utilisateur AUTORISER et REFUSER complète les directives fournies par les guides de sécurité des platesformes Windows antérieures, qui ne traitaient pas spécifiquement de l'authentification des ordinateurs exigée par IPSec. Les groupes d'accès réseau peuvent implémenter les exigences suivantes :
• Bloquer l'accès réseau aux serveurs sensibles à partir d'hôtes limites ou d'hôtes approuvés situés dans des zones publiques.
• Limiter l'accès aux serveurs des cadres supérieurs aux seuls ordinateurs clients utilisés par ces cadres.
• Isoler les hôtes approuvés d'un projet de recherche et développement de tous les autres hôtes approuvés du domaine.
Dans le scénario Woodgrove Bank, une exigence commerciale limite la quantité de nouveau matériel informatique pouvant être acheté au cours d'une année. Un serveur d'impression était requis pour permettre à la fois aux hôtes approuvés et non approuvés d'imprimer. Bien que Woodgrove aurait préféré acheter un nouveau serveur que seuls les ordinateurs non approuvés utiliseraient pour l'impression, il a été décidé qu'un seul serveur pourrait satisfaire les besoins des deux types d'hôtes. La société a par conséquent créé un serveur limite comme serveur d'impression. Le serveur d'impression étant soumis à un risque plus élevé d'infections et d'attaques d'ordinateurs non approuvés, le reste des hôtes approuvés devaient bloquer l'accès entrant à partir de ce serveur. Les hôtes approuvés devaient toujours pouvoir établir des connexions sortantes avec le serveur d'impression au besoin. En conséquence, Woodgrove a déterminé la nécessité d'un groupe d'accès réseau REFUSER pour implémenter cette exigence. À ce stade du processus de conception, l'affectation de membres au groupe d'accès réseau n'est pas requise. Il convient juste d'identifier et de documenter les groupes d'accès réseau requis par la conception. Les concepteurs de Woodgrove Bank ont identifié la nécessité de créer le groupe d'accès réseau suivant : Tableau 4.2 : Groupes d'accès réseau de Woodgrove Bank Nom du groupe d'accès réseau
Description
DNAG_IsolationDomain_Computers
Ce groupe comprend tout compte d'ordinateur de domaine non autorisé à établir des connexions entrantes protégées par IPSec avec tous les hôtes approuvés du domaine d'isolation.
Création de groupes d'isolation supplémentaires À ce stade du processus de conception, il existe deux groupes d'isolation : le groupe Domaine d'isolation et le groupe de limite. Si les exigences commerciales de votre organisation peuvent être satisfaites par cette conception, vous pouvez passer à la section suivante de ce chapitre pour définir les modèles de trafic pour ces deux groupes d'isolation. Cependant, si votre organisation exige que certains hôtes approuvés disposent d'une protection du trafic ou de contrôles d'accès réseau entrant ou sortant différents, des groupes d'isolation seront requis pour chaque série d'exigences.
82
L'objectif de cette section est de vous aider à comprendre quand des groupes supplémentaires seront requis. La première chose à faire consiste à identifier les ordinateurs ayant des exigences de protection du trafic ou d'isolation spécifiques qui ne sont pas satisfaites par les paramètres du domaine d'isolation. L'objectif doit être de maintenir le nombre de ces hôtes aussi réduit que possible, car chaque nouveau groupe augmente la complexité de la conception globale, et complique par conséquent sa prise en charge et sa gestion. Citons parmi les exemples types d'exigences pouvant mener à la création d'un nouveau groupe :
• Exigences de chiffrement • Accès hôte ou utilisateur limité requis au niveau du réseau • Exigences de protection ou de flux de trafic réseau sortant ou entrant différentes du domaine d'isolation
Bien souvent, l'accès entrant aux serveurs contenant des données sensibles est limité à un sous ensemble d'hôtes approuvés du domaine. Dans d'autres cas, les hôtes approuvés peuvent ne pas être autorisés à établir des connexions sortantes vers des ordinateurs non approuvés pour réduire le risque de fuite d'informations ou pour garantir le respect des réglementations en matière de protection du trafic réseau. Par exemple, dans le scénario Woodgrove Bank, les concepteurs ont identifié des exigences pouvant uniquement être satisfaites par la création des deux groupes d'isolation supplémentaires suivants :
• Le groupe de chiffrement contenait un petit groupe de serveurs d'application contenant des
données très sensibles et exigeant le niveau de protection maximal. Seul un sousensemble spécifique de clients approuvés seraient autorisés à effectuer une connexion entrante sur ces serveurs. Tout le trafic réseau avec ces serveurs exigeait un chiffrement de niveau 128 bits conforme aux réglementations fédérales américaines en matière de protection des données financières. Enfin, ces serveurs n'étaient pas autorisés à établir des connexions sortantes avec des hôtes non approuvés, ni à recevoir des connexions entrantes d'hôtes limites.
• Le groupe Sans basculement était requis pour un certain nombre d'hôtes approuvés du domaine d'isolation dont les communications réseau avec des systèmes non approuvés devaient être restreintes.
Bien que le second groupe n'exige aucun basculement, il ne possède pas l'ensemble d'exigences complet des serveurs d'applications. Ainsi, ces deux séries d'exigences différentes indiquaient que deux groupes d'isolation supplémentaires étaient requis. Le nombre total de groupes pour Woodgrove Bank passait donc à quatre. L'illustration suivante montre comment ces groupes se présentaient dans la conception finale des groupes d'isolation de Woodgrove Bank :
83
Figure 4.3 Conception finale des groupes de Woodgrove Bank
Les quatre groupes suivants exigent une stratégie pour atteindre les exigences de conception :
• Domaine d'isolation. Il s'agit du groupe par défaut pour tous les ordinateurs approuvés. • Groupe d'isolation de limite. Ce groupe est affecté aux ordinateurs auxquels des hôtes non approuvés doivent pouvoir accéder.
• Groupe d'isolation de chiffrement. Ce groupe autorise uniquement les communications via un chemin chiffré approuvé.
• Groupe d'isolation sans basculement. Ce groupe contient des ordinateurs ayant une exigence de sécurité supérieure qui les empêche d'initier des communications avec des hôtes non approuvés directement.
Woodgrove Bank ayant identifié deux groupes supplémentaires exigeant des stratégies IPSec, elle a défini des groupes d'ordinateurs supplémentaires pour contrôler l'application de ces nouvelles stratégies. Tableau 4.3 : Groupes d'ordinateurs Woodgrove Bank supplémentaires Nom du groupe d'ordinateurs
Description
CG_NoFallbackIG_Computers
Ce groupe contient tous les ordinateurs non autorisés à communiquer en clair.
CG_EncryptionIG_Computers
Ce groupe contient tous les ordinateurs devant utiliser un chiffrement.
En conséquence, Woodgrove a déterminé que des groupes d'accès réseau seraient requis pour autoriser l'accès entrant dans le sousensemble d'hôtes approuvés. Les concepteurs de Woodgrove Bank ont créé les groupes d'accès réseau suivants : Tableau 4.4 : Groupes d'accès réseau de Woodgrove Bank
84
Nom du groupe d'accès réseau
Description
ANAG_EncryptedResourceAccess_Users
Ce groupe comprend tous les utilisateurs autorisés à accéder aux serveurs du groupe d'isolation de chiffrement.
ANAG_EncryptedResourceAccess_Computers
Ce groupe contient tous les ordinateurs autorisés à avoir un accès réseau entrant sur les serveurs du groupe d'isolation de chiffrement.
DNAG_EncryptionIG_Computers
Ce groupe comprend des groupes de comptes d'ordinateur dont l'accès doit être refusé sur les hôtes du groupe d'isolation de chiffrement.
Collecte des exigences de trafic réseau À ce stade du processus de conception, vous devez documenter les exigences de trafic de communications qui seront autorisées à passer entre les groupes, ainsi que la forme que prendront les communications. Il existe de nombreuses manières de documenter les exigences de trafic des groupes. Cependant, l'équipe de support informatique de Microsoft a découvert, avec l'expérience, que la création d'un diagramme constituait la méthode la plus efficace pour communiquer des exigences précises. L'illustration suivante décrit les chemins de communications généralement autorisés entre les groupes de base, les hôtes non approuvés et les listes d'exemptions. Pour simplifier ce modèle, les listes d'exemptions figurent sous la forme d'un seul regroupement. C'est généralement le cas pour les services d'infrastructure, tels que les contrôleurs de domaine ou les serveurs DNS. Cependant, les groupes d'isolation peuvent avoir comme exigence commerciale d'exempter des ordinateurs spécifiques juste pour les ordinateurs de ce groupe. Dans ce cas, le groupe d'isolation contiendrait alors une liste d'exemptions supplémentaire des ordinateurs devant être exemptés en plus des exemptions communes. Microsoft recommande de restreindre au maximum les entrées de la liste d'exemptions, car elles exemptent explicitement des systèmes de participer à l'infrastructure IPSec. Dans l'illustration, toutes les flèches noires continues utilisent IPSec pour leurs communications ; les lignes en pointillés indiquent des communications autorisées sans IPSec. Une ligne en tirets gras indique qu'une stratégie IPSec est affectée aux ordinateurs de ce groupe.
85
Figure 4.4 Chemins de communications généralement autorisés pour les groupes d'isolation de base
Le tableau suivant répertorie les chemins de communications autorisés pour le trafic parmi les groupes de base, les systèmes non sécurisés et les listes d'exemptions : Tableau 4.5 : Options de communication autorisées pour les groupes d'isolation de base Chemin d'accès
De
À
Bidirectionnel
Essayer IKE/IPSec
Basculement
Chiffrer
1
DI
EX
Oui
Non
Non
Non
2
DI
LI
Oui
Oui
Non
Non
3
DI
NA
Non
Oui
Oui
Non
4
LI
EX
Oui
Non
Non
Non
5
LI
NA
Non
Oui
Oui
Non
6
NA
LI
Non
Non
Non
Non
7
NA
EX
Oui
Non
Non
Non
Le tableau précédent enregistre les exigences de communications pour chaque chemin de communications autorisé dans la conception initiale de groupes d'isolation. La liste suivante décrit chaque colonne :
• Chemin. Numéro affecté au chemin de communications illustré dans le diagramme de groupe. • De. Groupe contenant les initiateurs du trafic. • À. Groupe contenant les répondeurs qui seront contactés via le chemin de communication autorisé.
86
• Bidirectionnel. Indique si le chemin autorise l'inversion des rôles de l'initiateur et du répondeur de sorte que le trafic peut partir du groupe De ou À.
• Essayer IKE/IPSec. Indique si ce chemin tente d'utiliser IPSec pour sécuriser les communications. • Basculer. Indique si les communications peuvent renoncer à utiliser IPSec si la négociation IKE n'aboutit pas.
• Chiffrer. Indique si ce chemin exige le chiffrement des communications à l'aide d'un algorithme défini dans la stratégie IPSec.
Les formes abrégées des noms de groupe ont été utilisées pour garder les informations du tableau aussi concises que possible. En utilisant cette forme de documentation, il est possible de créer une représentation très concise des communications de la solution. En supposant que tout le trafic réseau est rejeté s'il n'est pas spécifiquement identifié dans ce tableau, le processus d'identification du trafic qui sera protégé dans le cadre de la solution devient bien plus clair. L'exemple de l'illustration précédente décrit chacun des chemins autorisés suivants :
• Les chemins de trafic 1, 4 et 7 illustrent les communications réseau spécifiquement autorisées pour tous les hôtes répertoriés par les listes d'exemptions de leur stratégie IPSec. Les exemptions spécifiques peuvent être différentes pour les groupes d'isolation.
• Le chemin de trafic 2 représente les communications entre le domaine d'isolation et les groupes
Limite. Ce chemin tente d'utiliser IPSec pour protéger le trafic. Le trafic peut exiger un chiffrement, selon les exigences de sécurité. Si la négociation IKE échoue, les communications échoueront car il n'y a pas d'option de communication en texte clair dans ce cas.
• Le chemin 3 montre que les hôtes du domaine d'isolation sont en mesure d'initier des
communications avec des hôtes non approuvés. Ceci est possible parce que la stratégie de ce groupe autorisera les hôtes du domaine d'isolation à communiquer en texte clair en l'absence de réponse à la demande de négociation IKE initiale. Les systèmes non approuvés qui tentent d'établir des connexions non IPSec avec des hôtes approuvés sont bloqués par les filtres entrants IPSec.
• Les chemins de trafic 5 et 6 décrivent les communications autorisées entre le groupe de limite et
les systèmes non approuvés. Le chemin 4 montre que le groupe de limite est autorisé à établir des communications sortantes avec des hôtes non approuvés en clair. Si la négociation IKE ne reçoit pas de réponse, l'hôte revient à des communications en clair. Le chemin 5 couvre le trafic initié à partir des hôtes non approuvés vers le groupe de limite. Bien que cette flèche ressemble au chemin 4, les détails du tableau montrent que les hôtes non approuvés ne tentent pas de négociation IKE avec le groupe de limite. Ils utilisent des connexions TCP/IP en clair.
Une fois les communications de base documentées, des groupes supplémentaires peuvent être ajoutés au plan général et leurs exigences de communications enregistrées de la même manière. Par exemple, les deux groupes supplémentaires requis par le scénario Woodgrove Bank ont mené à un diagramme de communications plus complexe, comme le montre l'illustration suivante.
87
Figure 4.5 Chemins de communications autorisés par Woodgrove Bank pour les groupes d'isolation
Le tableau suivant répertorie les chemins de communications autorisés pour le trafic dans les groupes supplémentaires du scénario Woodgrove Bank. Tableau 4.6 : Options de communication autorisées pour les groupes d'isolation supplémentaires Chemin d'accès
De
À
Bidirectionnel
Essayer IKE/IPSec
Basculement
Chiffrer
8
CR
EX
Oui
Non
Non
Non
9
CR
DI
Oui
Oui
Non
Oui
10
CR
SB
Oui
Oui
Non
Oui
11
CR
LI
Non
Oui
Non
Oui
12
SB
DI
Oui
Oui
Non
Non
13
SB
EX
Oui
Non
Non
Non
14
SB
LI
Oui
Oui
Non
Non
L'exemple de l'illustration précédente décrit dans le tableau explique chacun des chemins supplémentaires autorisés suivants :
• Les chemins 8 et 13 correspondent aux communications en clair pour tout le trafic exempté. • Les chemins 9 et 10 montrent les communications IPSec chiffrées par ESP (Encapsulating
Security Payload) requises entre les groupes Chiffrement, Sans basculement et Domaine d'isolation. Si la négociation IKE ne parvient pas à sécuriser la communication par chiffrement, la tentative de communication échoue.
88
• Le trafic du chemin 11 est légèrement différent car il autorise uniquement que des communications soient initiées à partir du groupe de chiffrement vers le groupe de limite, et non l'inverse. Ceci est dû au fait que Woodgrove Bank a placé des données sensibles dans le groupe de chiffrement et ne veut pas que ces données soient exposées à des ordinateurs auxquels accèdent directement des ressources non approuvées.
• Les chemins de trafic 12 et 14 pourraient être implémentés par le mode de transport IPSec AH ou IPSec ESP, qui est authentifié mais sans chiffrement (ESPNull).
Comme le montre cet exemple, l'ajout de groupes peut avoir un impact exponentiel sur la complexité de la solution. C'est pourquoi il est recommandé de limiter autant que possible le nombre de groupes, en particulier durant les premières étapes d'un déploiement, lorsque la plupart des changements sont introduits.
Affectation de membres au groupe d'ordinateurs et au groupe d'accès réseau Une fois les exigences de trafic détaillées et décrites dans la conception, la tâche suivante consiste à identifier les hôtes qui seront les membres des groupes d'ordinateurs ou des groupes d'accès réseau. Comme mentionné précédemment, les groupes d'ordinateurs sont utilisés dans cette solution pour appliquer l'objet Stratégie de groupe contenant la stratégie IPSec associée. Une fois déterminé qu'un ordinateur doit appartenir à un groupe d'isolation donné, le compte de cet ordinateur est ajouté au groupe d'ordinateurs de ce groupe d'isolation. Pour le domaine d'isolation, cette étape n'est pas nécessaire, car tous les ordinateurs du domaine appartiennent implicitement au groupe d'ordinateurs du domaine d'isolation. L'appartenance à un groupe d'accès réseau sera basée sur l'autorisation entrante que le groupe d'accès réseau implémente. Par exemple, s'il existe un groupe d'accès réseau pour limiter la communication d'un serveur donné vers un ensemble connu de clients, les comptes d'ordinateur client doivent être placés dans le groupe d'accès réseau approprié. Les groupes d'accès réseau ne sont créés qu'en fonction des besoins et ne possèdent par conséquent aucune configuration par défaut. Appartenance au groupe d'ordinateurs Il est important qu'un hôte ne soit pas représenté dans plusieurs groupes d'ordinateurs, car le groupe d'ordinateurs sert à définir les objets Stratégie de groupe applicables. Bien qu'il soit théoriquement possible de modifier les stratégies pour permettre à un hôte d'appartenir à plusieurs groupes d'ordinateurs, la complexité d'une telle approche rendrait rapidement la solution insoutenable. La tâche de détermination des membres d'un groupe d'ordinateurs n'est généralement pas compliquée, mais elle peut être longue. Il est conseillé d'utiliser les informations générées à partir d'un audit tel que celui effectué dans le chapitre 3 de ce guide, « Détermination de l'état actuel de votre infrastructure informatique », pour placer chaque hôte dans un groupe d'ordinateurs en fonction du groupe d'isolation dont il est membre. Vous pouvez déterminer ce placement en ajoutant une colonne Groupe pour y noter l'appartenance à un groupe d'ordinateurs pour la conception finale, comme indiqué dans le tableau suivant : Tableau 4.7 : Exemple de données collectées sur l'hôte Nom de l'hôte
Config. matérielle conforme ?
Config. logicielle conforme ?
Configuration requise
89
Détails
Coût prévisionnel
Groupe
HOST NYC001
Non
Non
Mises à niveau matérielle et logicielle
Le système d'exploitation actuel est Windows NT 4.0. Ancien matériel non compatible avec Windows XP.
SERVER LON001
Oui
Non
Intégrer Aucun logiciel domaine antivirus approuvé, présent. mettre à niveau de NT 4 vers Windows 2000 ou ultérieur
$XXX.
DI
$XXX.
CR
Appartenance au groupe d'accès réseau La dernière étape de ce processus de conception consiste à définir les membres des groupes d'accès réseau identifiés précédemment dans ce chapitre. Bien qu'un hôte approuvé ne doive appartenir qu'à un seul groupe d'ordinateurs, il est possible qu'il soit membre de plusieurs groupes d'accès réseau. Essayez d'utiliser aussi peu de groupes d'accès réseau que possible pour limiter la complexité de la solution. Lors de l'affectation de comptes d'utilisateurs à un groupe d'accès réseau, décidez du degré souhaité de contrôle d'accès. Pour qu'une ressource utilisant déjà des autorisations de fichiers et de partage standards assure le niveau correct de contrôle, le moyen le plus simple de définir l'appartenance serait d'attribuer l'appartenance du groupe d'accès réseau de l'utilisateur au groupe Utilisa. du domaine de chaque domaine approuvé de la forêt devant accéder à la ressource. Cette approche rétablit pratiquement le comportement de la valeur par défaut d'origine d'Utilisateurs authentifiés, sans inclure de comptes d'utilisateurs locaux. Si des comptes d'utilisateurs ou de services locaux sont requis, un objet Stratégie de groupe basé sur le domaine n'est peutêtre pas la meilleure approche pour configurer des droits de connexion réseau AUTORISER et REFUSER. L'affectation de droits d'utilisateur AUTORISER et REFUSER ne fusionne pas les paramètres parmi plusieurs objets Stratégie de groupe. Par conséquent, cet ordinateur ne doit pas être autorisé à posséder le droit AUTORISER et REFUSER de l'objet Stratégie de groupe basé sur le domaine, et doit utiliser un objet Stratégie de groupe local personnalisé. Si l'objet Stratégie de groupe basé sur le domaine qui fournit l'affectation de stratégie IPSec est différent de l'objet Stratégie de groupe utilisé pour fournir les droits de connexion réseau, l'objet Stratégie de groupe basé sur le domaine pour l'affectation de stratégie IPSec peut encore être utilisé. De plus, décidez comment implémenter les exigences d'accès entrant à l'aide d'un groupe d'accès réseau AUTORISER ou REFUSER, voire les deux. Le choix du type de groupe d'accès réseau à créer est basé exclusivement sur le comportement attendu et sur ce qui minimise l'effort administratif. Il peut s'avérer utile d'avoir un groupe d'accès réseau REFUSER préexistant mais vide pour les utilisateurs et un groupe d'accès réseau REFUSER pour les ordinateurs possédant déjà le droit « Interdire l'accès à cet ordinateur à partir du réseau » de l'objet Stratégie de groupe. Dans les scénarios de sécurité élevée, l'appartenance des groupes d'accès réseau utilisateur peut être affectée à des utilisateurs ou groupes spécifiques. Si cette méthode est utilisée, il faut comprendre que les utilisateurs qui ne sont pas membres de ce groupe verront leur accès à l'ordinateur bloqué sur le réseau, même s'ils sont membres du groupe des administrateurs locaux et disposent d'un contrôle total sur toutes les autorisations de partage et de fichiers.
90
Pour le scénario Woodgrove Bank, l'appartenance à NAG_EncryptedResourceAccess_Users a été affectée à Utilisateurs du domaine et enregistrée comme le montre le tableau suivant : Tableau 4.8 : Groupes d'accès réseau de Woodgrove Bank avec appartenance définie Nom du groupe d'accès réseau
Appartenance
Description
ANAG_EncryptedResourceAcces s_Users
User7
Ce groupe correspond à tous les utilisateurs autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
ANAG_EncryptedResourceAcces s_Computers
IPSSQLDFS01 IPSSQLDFS02 IPSSTXP05
Ce groupe contient tous les ordinateurs autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
DNAG_EncryptionIG_Computers
CG_BoundaryIG_Computers
Ce groupe contient tous les ordinateurs non autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
Remarque : l'appartenance à un groupe d'accès réseau ne détermine pas le niveau de protection du trafic IPSec. Les paramètres de stratégie IPSec commandent les méthodes de sécurité utilisées pour protéger le trafic et sont indépendants de l'identité authentifiée par IKE. La négociation IKE est uniquement consciente de la réussite ou de l'échec du processus d'authentification de l'identité de l'ordinateur Kerberos. Elle ne peut pas implémenter une stratégie « chiffrer si user3 se connecte » ou « chiffrer si hôte approuvé IPSSQLDFS01 ou IPSSQLDFS02 ». L'administrateur doit obtenir le comportement attendu en utilisant une stratégie IPSec pour les serveurs du groupe d'isolation de chiffrement exigeant un « chiffrement pour toute connexion entrante d'hôte approuvé » et de manière similaire un « chiffrement pour toute connexion sortante vers un hôte approuvé ». Jusqu'ici, ce processus de conception n'a pas revu les détails de la conception de stratégie IPSec. Le chapitre 5 fournira des détails relatifs à la conception de la stratégie IPSec pour Woodgrove. À ce stade du processus de conception, vous avez terminé les tâches requises pour transformer vos exigences en conception préliminaire. Cette section vous a aidé à mettre au point la conception et la documentation requises pour la création des stratégies IPSec. Limitations pouvant affecter votre conception Les problèmes suivants peuvent affecter votre conception et doivent par conséquent être pris en compte avant que votre conception puisse être considérée comme terminée :
• Nombre maximal de connexions simultanées par des hôtes uniques sur des serveurs
utilisant IPSec. Le nombre de connexions simultanées est un facteur crucial pour déterminer si une implémentation IPSec sur des serveurs d'usage élevé se déroulera sans problèmes ou surchargera le processeur avec le traitement IKE ou IPSec. Chaque négociation IKE réussie établit des associations de sécurité occupant environ 5 kilooctets de mémoire de mode utilisateur. Des ressources processeur sont requises pour maintenir les états d'association de sécurité IKE courants avec tous les homologues connectés simultanément. Pour plus d'informations sur
91
l'évolutivité, consultez le livre blanc « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) à l'adresse www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx.
• Limitation de la taille de jeton Kerberos maximale pour les hôtes utilisant IPSec. Il existe une
limite pratique d'environ 1 000 groupes par utilisateur, et si cette valeur est dépassée, l'application de l'objet Stratégie de groupe peut ne pas se produire. Pour plus d'informations à ce sujet, consultez les articles 327825 de la Base de connaissances Microsoft « New Resolution for Problems That Occur When Users Belong to Many Groups » (Nouvelle résolution de problèmes se produisant lorsque des utilisateurs appartiennent à de nombreux groupes) à l'adresse http://support.microsoft.com/?kbid=327825 et 306259 « Members of an Extremely Large Number of Groups Cannot Log On to the Domain » (Des membres d'un nombre très élevé de groupes ne peuvent pas se connecter au domaine) à l'adresse http://support.microsoft.com/?kbid=306259.
Bien que ces articles mentionnent des utilisateurs spécifiquement, le problème existe également pour les comptes d'ordinateurs, car le paramètre Kerberos MaxTokenSize s'applique aussi aux comptes d'ordinateurs. Bien que cette limite soit rarement atteinte dans la plupart des implémentations, vous devez être conscient de ce problème si vous décidez de placer un ordinateur (peutêtre un client) dans un grand nombre de groupes d'accès réseau. Si votre conception sera affectée par ces problèmes, vous devrez revisiter le processus de conception pour y répondre. Par exemple, vous pouvez répondre au problème du nombre maximal de connexions simultanées en déplaçant un serveur très lourdement chargé dans les listes d'exemptions. Vous pouvez répondre à la limitation de la taille de jeton Kerberos maximale en réduisant le nombre de groupes d'accès réseau que votre conception utilisera. Si ces limitations n'affecteront pas votre conception, la tâche suivante consiste à considérer la manière dont la conception sera déployée dans l'organisation.
Méthodes d'implémentation de groupe Une fois la conception initiale créée, vous devez considérer attentivement le processus de déploiement d'IPSec. Ce n'est que dans les environnements les plus petits qu'il est possible de déployer simplement les stratégies sur tous les ordinateurs et d'espérer un fonctionnement sans heurts d'IPSec avec un impact relativement faible sur les utilisateurs. Dans les organisations étendues, la complexité et le risque nécessitent un déploiement progressif. En utilisant une telle approche, l'organisation peut aider à atténuer le risque associé à un tel changement fondamental de l'environnement. Sans planification soignée, les appels au support technique et la perte de productivité augmenteront rapidement le coût du déploiement. Il existe différentes manières de déployer IPSec dans une organisation. Les facteurs suivants aident à déterminer la méthode de déploiement :
• les états de départ et de fin de l'environnement ; • la complexité de configuration des groupes ; • la complexité de la structure de domaines ; • la tolérance de risque de l'organisation ; • les exigences de sécurité.
92
Les méthodes de déploiement suivantes ne comprennent pas tout, mais elles sont des exemples d'approches possibles. Vous pouvez également utiliser une combinaison de ces approches. En général, les organisations ne doivent pas déployer initialement des stratégies IPSec limitant ou bloquant la communication, afin de garantir qu'elles disposent de suffisamment de temps pour résoudre les problèmes et réduire la coordination de gestion dans les environnements complexes. Quelle que soit l'approche choisie pour déployer IPSec, il est fortement recommandé de tester soigneusement le scénario de déploiement dans un environnement de laboratoire, y compris la séquence et le déroulement spécifiques des étapes de déploiement et des changements de stratégie. De plus, utilisez une action de filtre demandant une fonctionnalité IPSec, mais acceptant la communication en texte clair en utilisant la fonction Communiquer en texte clair. Cette approche aidera à minimiser l'impact du déploiement initial. Une fois le déploiement terminé, passez à des modes de fonctionnement plus sécurisés exigeant que le trafic soit protégé par IPSec. Pour un déploiement dans un environnement de production, un pilote initial est fortement recommandé à chaque grande phase du déploiement. Il est particulièrement important d'analyser l'impact des changements de stratégie IPSec, car ils prendront effet dans l'environnement de production suite aux durées de vie des tickets Kerberos, et aux intervalles d'interrogation de stratégie de groupe et de stratégie IPSec. Il est conseillé de mettre en œuvre un processus formel de contrôle des modifications indiquant les stratégies et les critères d'annulation pour s'assurer que toutes les organisations informatiques concernées sont conscientes du changement et de son impact, et savent comment coordonner les commentaires vers les décideurs.
Déployer par groupe La méthode Déployer par groupe utilise des stratégies IPSec entièrement définies, mais contrôle l'application des stratégies par l'utilisation de groupes et de listes de contrôle d'accès sur les objets Stratégie de groupe fournissant les stratégies. Dans la méthode Déployer par groupe, les stratégies IPSec sont créées dans Active Directory dans leur configuration finale. Toutes les exemptions et tous les sousréseaux sécurisés sont définis et les actions de filtre appropriées sont activées dans chaque stratégie IPSec. Les administrateurs de stratégie IPSec créent alors des objets Stratégie de groupe pour chaque stratégie IPSec. De plus, des groupes d'ordinateurs sont créés dans le domaine pour gérer et appliquer ces nouveaux objets Stratégie de groupe. Les listes de contrôle d'accès des objets Stratégie de groupe sont modifiées pour que les membres du groupe Utilisateurs authentifiés n'aient plus le droit « Appliquer ». Les groupes d'utilisateurs de l'administrateur approprié pour la gestion et l'application de la stratégie reçoivent également des droits sur l'objet Stratégie de groupe. Les stratégies IPSec appropriées sont ensuite affectées à l'objet Stratégie de groupe correspondant. De plus, l'objet Stratégie de groupe est lié à l'objet approprié dans Active Directory. À ce stade, aucun des ordinateurs de l'environnement ne doit recevoir la stratégie, car les listes de contrôle d'accès contrôlant l'affectation de l'objet Stratégie de groupe (possibilité de lire l'objet Stratégie de groupe) sont vides. Enfin, les ordinateurs qui recevront les stratégies sont identifiés et leurs comptes d'ordinateurs sont placés dans les groupes d'ordinateurs appropriés avec accès en lecture à l'objet Stratégie de groupe. Une fois les tickets Kerberos de l'ordinateur mis à jour avec les informations d'appartenance de groupe, l'objet Stratégie de groupe, ainsi que la stratégie IPSec correspondante, s'appliquent à l'intervalle d'interrogation de stratégie de groupe suivant.
93
Remarque : les listes de contrôle d'accès qui empêchent les ordinateurs du domaine de lire les objets de stratégie IPSec ou le conteneur de stratégie IPSec dans Active Directory ne sont pas recommandées. Considérez une organisation ayant défini deux stratégies IPSec, IPSec standard et IPSec chiffrement. La stratégie IPSec standard est la stratégie par défaut ; elle exige que le trafic entrant utilise IPSec, mais permet aux systèmes de communiquer en clair s'ils initient une connexion vers un ordinateur non basé sur IPSec. La stratégie IPSec chiffrement exige la négociation IPSec chiffré à tous moments. Dans cet exemple, l'administration de l'organisation crée deux objets Stratégie de groupe dans Active Directory : IPSec standard et IPSec chiffré. De plus, elle identifie les groupes dans le tableau suivant : Tableau 4.9 : Groupes d'administration IPSec Nom de groupe
Type de groupe
Description
IPSecSTD
Universel
Contrôle l'application de la stratégie IPSec standard
IPSecENC
Universel
Contrôle l'application de la stratégie IPSec chiffré
Les listes de contrôle d'accès des deux objets Stratégie de groupe nouvellement créés sont mises à jour de sorte qu'elles ne sont pas automatiquement appliquées au groupe Utilisateurs authentifiés et que les groupes d'application et de gestion appropriés reçoivent les droits corrects. L'administration a modifié les listes de contrôle d'accès pour les deux objets Stratégie de groupe en fonction des informations du tableau suivant : Tableau 4.10 : Droits de groupes sur les objets Stratégie de groupe Groupe
Objet Stratégie de groupe IPSec standard
Objet Stratégie de groupe IPSec chiffré
Utilisateurs authentifiés
Lecture
Lecture
IPSecENC
Aucun
Lecture Appliquer la stratégie de groupe
IPSecSTD
Lecture Appliquer la stratégie de groupe
Aucun
Remarque : ce tableau montre uniquement les autorisations ajoutées ou modifiées. Il y aura également des groupes supplémentaires avec des autorisations. Les administrateurs ont lié les deux objets Stratégie de groupe au domaine dans Active Directory. Cette approche garantit que la stratégie s'appliquera à tout ordinateur du domaine sans modifier son emplacement (à moins que l'ordinateur se situe dans une UO bloquant les stratégies). À mesure que les ordinateurs sont identifiés, leurs comptes sont ajoutés au groupe IPSecSTD ou IPSecEnc. Passé un certain délai, la stratégie IPSec correspondante s'appliquera et sera effective. Cette méthode exige une planification soignée pour s'assurer que les communications ne sont pas perturbées. Par exemple, si un serveur a été placé dans le groupe IPSecEnc, mais que plusieurs clients dépendant de ce serveur n'ont pas pu négocier IPSec, les communications entre ces clients et le serveur seraient perturbées.
94
Déployer par élaboration de stratégies Cette méthode utilise une technique dans laquelle les stratégies IPSec peuvent être créées de toutes pièces durant le déploiement. L'avantage de cette méthode est qu'IPSec est négocié uniquement pour un petit pourcentage du trafic TCP/IP total, et non pour tous les sousréseaux internes de la méthode de déploiement par groupe. Elle permet également de tester tous les chemins du réseau interne vers ce sousréseau cible pour vérifier l'absence de problèmes avec la transmission réseau de la négociation IKE et du trafic protégé par IPSec. Un autre avantage est que l'intervalle d'interrogation pour IPSec peut fournir plus rapidement des mises à jour de stratégie IPSec (y compris d'annulation) au lieu de devoir dépendre des changements de membres de groupe dans le ticket d'octroi d'autorisations (TGT) Kerberos ou les tickets de service. L'inconvénient de cette méthode est qu'elle s'applique à tous les ordinateurs du groupe ou domaine d'isolation, et non à des ordinateurs spécifiques comme dans la méthode de déploiement par groupe. De plus, tous les ordinateurs disposeront d'un délai de 3 secondes avant retour à la communication en clair à un moment donné lors de la communication avec les sousréseaux spécifiés. Dans cette méthode de déploiement, les stratégies IPSec n'incluent que des exceptions initialement ; il n'existe aucune règle pour la négociation de la sécurité par les ordinateurs dans la stratégie IPSec. Cette méthode teste et vérifie d'abord que toutes les stratégies IPSec locales existant précédemment et pouvant être en cours d'utilisation sont supprimées. L'équipe d'administration doit pouvoir identifier les hôtes qui utilisaient des stratégies IPSec définies localement à l'avance pour gérer ces systèmes avec un processus spécial. Si une stratégie IPSec locale est remplacée par une stratégie de domaine, il peut se produire des interruptions dans les communications et une perte de sécurité pour les ordinateurs affectés. Contrairement aux stratégies locales remplacées par l'application de stratégie de domaine, les stratégies persistantes sous Windows Server 2003 fusionnent avec le résultat de l'application de la stratégie de domaine. Un système contenant une stratégie persistante peut sembler fonctionner, mais la configuration de la stratégie persistante peut changer le comportement ou diminuer en fait la sécurité fournie par la stratégie de domaine, ou peut perturber les communications une fois des règles de sousréseau sécurisé ajoutées à la stratégie. Vous pouvez ensuite créer une règle de sécurité avec un filtre affectant uniquement un seul sous réseau dans le réseau de l'organisation, par exemple « Tout le trafic à partir de n'importe quelle adresse IP vers Sousréseau A, négocier ». Cette règle aurait une action de filtre pour accepter le texte clair entrant et déclencher des négociations pour tout le trafic sortant vers ce sousréseau avec la communication en texte clair activée. À mesure que le déploiement dans tous les domaines de cette stratégie IPSec prend effet, les communications passeront peu à peu d'associations de sécurité logicielles à des associations de sécurité IPSec normales pour les hôtes approuvés juste sur ce sous réseau. Tout échec de négociation IKE est étudié et résolu. Toutes incompatibilité d'application est identifiée et corrigée. IPSec sécurisera la communication entre les hôtes approuvés dans ce sous réseau. La communication avec des hôtes approuvés en dehors de ce sousréseau repassera en clair après le délai de trois secondes. Des sousréseaux supplémentaires sont ajoutés à la règle sécurisée jusqu'à ce que la stratégie soit constituée à son état final. Considérez une organisation ayant une seule stratégie IPSec définie, appelée stratégie IPSec standard, qui demande une négociation IPSec, mais accepte le retour à la communication en texte clair en cas d'échec. La stratégie est créée dans Active Directory et ne contient que des règles d'exemption. L'objet Stratégie de groupe IPSec standard est créé et lié de sorte qu'il s'applique à tous les ordinateurs de l'environnement. De plus, la stratégie IPSec standard est affectée à ce nouvel objet Stratégie de groupe. Tous les ordinateurs recevront finalement la stratégie IPSec. Tous problèmes avec des stratégies IPSec locales seront détectés car cette stratégie de domaine supplantera les stratégies locales
95
existantes. Les problèmes sont continuellement résolus jusqu'à ce que tous les sousréseaux apparaissent dans la liste de filtres de sousréseaux sécurisés.
Implémentation des groupes pour Woodgrove Bank Woodgrove Bank a choisi d'implémenter son déploiement de production en déplaçant d'abord tous les ordinateurs vers le groupe de limite à l'aide de la méthode d'élaboration. Cette approche a permis aux administrateurs d'avancer peu à peu et de résoudre tous les problèmes en suspens sans trop affecter les communications entre tous les systèmes. En déployant d'abord une stratégie sans sousréseaux sécurisés, l'équipe d'administration a pu identifier les systèmes auxquels était affectée une stratégie IPSec locale et prendre également ces informations en considération. Alors que des sousréseaux ont été ajoutés à la stratégie, tous les conflits supplémentaires détectés ont été résolus. Une fois que les ordinateurs fonctionnaient selon la stratégie de groupe de limite, l'équipe a implémenté les groupes Domaine d'isolation, Sans basculement et Chiffrement. Le déploiement de ces groupes utilisait la méthode Déployer par groupe. Un ensemble d'ordinateurs a été sélectionné pour un pilote et ajouté aux groupes appropriés contrôlant les nouvelles stratégies. Les problèmes ont été résolus à mesure de leur découverte, et des ordinateurs supplémentaires ont été ajoutés aux groupes jusqu'à ce qu'ils soient totalement remplis. Le tableau suivant répertorie les groupes d'ordinateurs et d'accès réseau ainsi que leurs membres une fois la solution totalement déployée : Tableau 4.11 : Appartenance au groupe d'ordinateurs et au groupe d'accès réseau Groupe d'ordinateurs ou d'accès réseau
Membres
CG_IsolationDomain_Computers
Ordinateurs du domaine
CG_BoundaryIG_Computers
IPSPRINTS01
CG_NoFallbackIG_Computers
IPSLTXP01
CG_EncryptionIG_Computers
IPSSQLDFS01 IPSSQLDFS02
ANAG_EncryptedResourceAccess_Users
User7
ANAG_EncryptedResourceAccess_Computers
IPSSQLDFS01 IPSSQLDFS02 IPSSTXP05
DNAG_EncryptionIG_Computers
CG_BoundaryIG_Computers
Notez que le groupe ANAG_EncryptedResourceAccess_Computers contient les serveurs se trouvant dans le groupe d'isolation de chiffrement. Ceci leur permettra de communiquer selon les besoins. Si cette communication n'est pas nécessaire pour ces serveurs, il est inutile de les ajouter dans ce groupe.
Résumé Ce chapitre décrit le processus de conception d'une solution d'isolation de serveurs et de domaines. Les tâches comprenaient l'identification des groupes d'ordinateurs et des groupes d'accès réseau requis, la compréhension des groupes d'isolation de base, l'ajout de groupes d'isolation
96
supplémentaires, l'élaboration d'un modèle de trafic, l'affectation de membres aux groupes, ainsi que la planification de la méthode de déploiement. Ce chapitre utilisait également l'implémentation IPSec de Woodgrove Bank, une organisation fictive, pour aider à illustrer le processus de conception en action et éprouver la conception dans les laboratoires de test Microsoft. La conception de groupes était basée sur les exigences commerciales et les informations de découverte obtenues à partir des deux chapitres précédents et documentées dans la feuille de calcul Business_Requirements.xls (disponible dans le dossier Tools and Templates). Une appréciation de l'impact d'IPSec sur un réseau était également une considération importante. Après avoir lu ce chapitre, vous devez disposer de suffisamment d'informations pour commencer à planifier des groupes d'isolation, à documenter les exigences de communication entre ces groupes, et à planifier la stratégie IPSec de niveau supérieur. Ces tâches vous prépareront pour le chapitre 5, « Création de stratégies IPSec pour les groupes d'isolation ».
Informations complémentaires Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de l'implémentation de cette solution. IPSec Les liens suivants offrent une grande variété d'informations relatives à IPSec sous Windows :
• Le livre blanc « Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network
Server » (Utilisation de Microsoft Windows IPSec pour aider à sécuriser un serveur de réseau d'entreprise interne) présente le premier modèle d'utilisation d'IPSec pour sécuriser l'accès réseau aux serveurs internes traitant ou stockant des informations sensibles. Ce livre blanc peut être téléchargé sur www.microsoft.com/downloads/ details.aspx?FamilyID=a774012aac254a1d8851b7a09e3f1dc9&displaylang=en.
• Le déploiement Microsoft d'IPSec pour protéger tous les membres du domaine est décrit dans
l'étude de cas « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) sur www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx.
• Page IPSec for Windows 2000
(IPSec pour Windows 2000) à l'adresse www.microsoft.com/windows2000/technologies/communications/ipsec/.
• Page Microsoft Windows Server 2003 IPSec
à l'adresse www.microsoft.com/windowsserver2003/technologies/networking/ipsec/.
Sécurité
• L'approche d'évaluation des risques de sécurité informatique de Microsoft est documentée dans le livre blanc « IT Security at Microsoft Overview » (Présentation de la sécurité informatique chez Microsoft) à l'adresse www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx.
Windows Server 2003 Active Directory Pour plus d'informations sur Active Directory, consultez :
97
• La page Windows Server 2003 Active Directory
à l'adresse www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/.
98
Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation L'objectif de ce chapitre est de fournir des instructions relatives à l'implémentation de la conception d'isolation de serveurs et de domaines. Les chapitres précédents expliquent le processus de conception et les raisons qui justifient les instructions du présent chapitre. Si cela n'est déjà fait, nous vous conseillons vivement de lire ces chapitres avant de poursuivre. Ce chapitre détaille l'implémentation des exigences de sécurité des groupes d'isolation de serveurs et de domaines conçus au chapitre 4, « Conception et planification de groupes d'isolation ». La combinaison des éléments suivants permettra la mise en place de ces exigences :
• Exigences d'accès entrant et sortant pour le domaine d'isolation et les groupes d'isolation : • Stratégie IPSec (Internet Protocol security) conçue spécialement pour le groupe d'isolation nécessitant une négociation IKE (Internet Key Exchange) IPSec pour les connexions entrantes et sortantes. • Groupes de sécurité basés sur les domaines, appelés groupes d'accès réseau, pour autoriser ou refuser l'accès réseau lors de l'utilisation d'un trafic protégé par IPSec.
• Exigences de protection du trafic réseau pour le domaine d'isolation et les groupes d'isolation : • Filtres de stratégie IPSec conçus pour identifier correctement le trafic à sécuriser. • Actions de filtrage IPSec chargées de négocier le niveau d'authentification et de chiffrement requis pour le trafic identifié par les filtres. • Paramètres des actions de filtrage IPSec afin de contrôler si les communications en texte clair sont autorisées lorsque des hôtes approuvés établissent des connexions sortantes. Ce guide aborde la préparation de la solution à l'aide de la stratégie de groupe et des stratégies IPSec dans le service d'annuaire Active Directory® sous Microsoft® Windows Server™ 2003, ainsi que la configuration des membres des domaines avec Windows Server 2003 et Microsoft Windows® XP. Ce chapitre décrit aussi les solutions conceptuelles alternatives et les options de déploiement. Des listes de vérification finales sont proposées afin de s'assurer que le processus de conception respecte toutes les exigences commerciales et de sécurité.
Connaissances préalables requises pour ce chapitre Cette section renferme des informations qui vous permettront de vérifier que votre organisation est prête à implémenter la solution IPSec (« Prête » s'entend au sens logistique et non au sens commercial – la motivation de l'entreprise pour l'implémentation de cette solution est traitée au chapitre 1, « Introduction à l'isolation de serveurs et de domaines », du présent guide).
Connaissances requises Il est préférable de connaître les principes généraux d'IPSec et, plus particulièrement, les techniques Microsoft d'implémentation d'IPSec. Une connaissance de base de Windows Server 2003 est également requise dans les domaines suivants :
99
• Concepts relatifs à Active Directory, notamment la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et autres objets Active Directory, et l'utilisation de la stratégie de groupe.
• Sécurité du système Windows : concepts de sécurité tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande.
• Maîtrise des principes réseau et IPSec fondamentaux Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les instructions de planification fournies dans les chapitres précédents du guide et bien comprendre l'architecture et la conception de la solution. Vous devez aussi avoir défini et documenté les besoins commerciaux de la solution dans le cadre de la définition des exigences de la solution.
Conditions requises pour l'organisation Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans l'implémentation de cette solution, notamment
• les dirigeants ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau, du serveur Web et du DNS (Domain Name System).
Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles.
Configuration requise pour l'infrastructure informatique Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :
• Un domaine Active Directory Microsoft Windows Server 2003 fonctionnant en mode mixte ou natif.
Cette solution fait appel à des groupes universels pour l'application des objets Stratégie de groupe. Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ipsec_whatsnew.asp.
• Licences, clés de produit et CD d'installation de Windows 2000 Server, Windows Server 2003 Standard Edition et Windows Server 2003 Enterprise Edition.
Ce chapitre exige aussi une maîtrise complète de l'infrastructure informatique existante pour garantir que les stratégies appropriées sont déployées sur les hôtes concernés de l'environnement. Le chapitre 3 (« Détermination de l'état actuel de votre infrastructure informatique ») décrit les
100
informations requises et comment vous les procurer. N'entamez pas la procédure décrite dans ce chapitre tant que vous ne disposez pas des informations suivantes :
• La définition des groupes d'isolation de la conception. Chacun des groupes d'isolation requis doit bénéficier d'une instruction claire signalant les exigences de sécurité et identifiant les ressources auxquelles ces exigences s'appliquent (soit l'appartenance à un groupe d'isolation).
• Une description détaillée de la manière dont les stratégies IPSec sont utilisées pour implémenter les groupes d'isolation, avec la liste des différentes stratégies IPSec requises et leur mode d'attribution.
• Un résumé général de l'impact d'IPSec pour l'application des groupes d'isolation. Ce résumé peut être accompagné d'une liste de problèmes et de solutions pour les éviter.
• Une description détaillée de l'évolution des stratégies IPSec dans le temps et une liste des
procédures nécessitant des modifications de ces stratégies. Cette liste peut inclure des procédures telles que le traitement des incidents de sécurité, l'ajout de composants réseau et l'ajout de clients ou de serveurs à un groupe d'isolation quelconque.
• Une bonne connaissance de la topologie du réseau et des schémas d'adressage IP de l'organisation.
Création de stratégies IPSec dans Active Directory Le processus visant à créer les stratégies nécessaires à la prise en charge des groupes d'isolation requis implique les tâches principales suivantes :
• Création des listes de filtres. • Création des actions de filtrage. • Création des stratégies IPSec pour l'implémentation des groupes d'isolation. Avant d'entreprendre le processus de création de ces composants, il est primordial que vous vous procuriez les schémas et les tableaux des modèles de trafic du chapitre 4 (« Conception et planification de groupes d'isolation »), tout comme les tableaux de correspondance réseau et hôtes. Ces tableaux fournissent les informations nécessaires pour garantir que les stratégies offrent les fonctionnalités requises et sont attribuées aux groupes d'isolation appropriés. La figure suivante décrit la configuration réseau utilisée pour simuler le scénario de la Woodgrove Bank.
101
Figure 5.1 Configuration réseau de la Woodgrove Bank
La configuration du laboratoire de test de la Woodgrove Bank fait apparaître les fonctions clés suivantes de la solution :
• Isolation des domaines à l'aide de groupes d'accès réseau afin de contenir certains hôtes à haut risque mais approuvés dans le domaine lorsque vous utilisez IPSec.
• Isolation des serveurs à l'aide de groupes d'accès réseau afin de définir et limiter les clients hôtes approuvés autorisés à se connecter via IPSec.
De plus, cet environnement de laboratoire permet de dégager les fonctionnalités Windows IPSec requises suivantes et d'évaluer la compatibilité avec d'autres technologies de sécurité susceptibles d'être employées dans des environnements réels :
• Compatibilité des ordinateurs dotés de Windows 2000 Service Pack (SP) 4 (avec mise à jour de la traduction d'adresses réseau NATTraversal (NATT), Windows XP SP2 et Windows Server 2003 en tant que membres de domaines.
• Compatibilité de ces platesformes lorsque vous les sécurisez à partir des techniques de
renforcement préconisées dans les guides de sécurité Microsoft Windows. Les cartes de trafic utilisées pour autoriser et bloquer le trafic à l'aide de filtres IPSec n'ont pas été intégrées à cette solution puisque l'isolation ne présente pas les mêmes exigences de protection. D'autres raisons ont abouti à la décision de ne pas intégrer les cartes de trafic, notamment le besoin de minimiser la complexité des stratégies IPSec d'isolation de serveurs et le fait que le parefeu Windows est souvent mieux adapté au filtrage d'autorisation/blocage (indépendamment de la capacité d'IPSec à fournir une sécurité de bout en bout pour chaque paquet).
• Capacité de l'application IPSec à sécuriser le service Web (HTTP), SQL Server, le système de
fichiers distribués (DFS), le partage de fichiers et d'imprimantes, Microsoft Operations Manager (MOM) et les serveurs et le trafic SMS (Microsoft Systems Management Server).
102
• Compatibilité d'IPSec ESP (Encapsulated Security Payload) NATT par encapsulation UDP (User Datagram Protocol)ESP pour les deux conditions suivantes :
• Accès sortant depuis des membres de domaine derrière NAT par authentification IKE Kerberos • Accès entrant à un membre de domaine derrière NAT par authentification IKE Kerberos Le scénario du laboratoire illustré dans la figure 5.1 a été utilisé pour vérifier que les fonctionnalités recherchées étaient obtenues dans tous les groupes d'isolation de la solution. Au total, quatre stratégies IPSec ont été créées et attribuées aux groupes d'isolation entourés de tirets gras dans la figure (soit le domaine d'isolation, le groupe d'isolation de chiffrement, le groupe d'isolation sans basculement et le groupe d'isolation de limite). Les sections suivantes expliquent comment ces stratégies ont été créées.
Présentation des composants de la stratégie IPSec Une stratégie IPSec désigne un nombre de composants utilisés pour appliquer les exigences de sécurité IPSec de l'organisation. La figure suivante décrit les divers composants d'une stratégie IPSec et expliquent comment ils sont associés entre eux.
Figure 5.2 Composants de la stratégie IPSec
La stratégie IPSec joue le rôle d'un conteneur identifiant l'ensemble des règles qui déterminent quel trafic de communication réseau est autorisé et sous quelle forme. Chaque règle se compose d'une liste de filtres et d'une action associée. La liste de filtres désigne un groupe de filtres. Chaque trafic mis en correspondance avec un filtre spécifique déclenche une action de filtrage associée. Les règles permettent également de définir les méthodes d'authentification à appliquer entre les hôtes. Ce schéma présente la structure descendante des composants de la stratégie. Néanmoins, la méthode la plus efficace pour créer des stratégies est de débuter avec des filtres et des listes de filtres car ils constituent le bloc fondamental qui permet de contrôler et déterminer quel trafic est sécurisé.
103
Listes de filtres IPSec Les listes de filtres IPSec sont des ensembles d'un ou plusieurs filtres utilisés pour structurer le trafic réseau selon des critères définis pour chaque filtre. Chaque filtre répertorié dans la liste des filtres définit les éléments suivants :
• Réseaux ou adresses source et de destination • Protocole(s) • Ports TCP (Transmission Control Protocol) ou UDP source et de destination Les listes de filtres et les actions de filtrage ont été conçues pour être partagées entre les stratégies IPSec. Cette approche permet de conserver une liste de filtres pour un type d'exemption donné et de l'utiliser dans une stratégie IPSec indépendante pour chaque groupe d'isolation. En revanche, les filtres qui composent les listes de filtres ne peuvent être partagés d'une liste à l'autre. Si deux listes de filtres contiennent des filtres identiques, les filtres devront être créés deux fois, soit un pour chaque liste de filtres. L'administrateur IPSec devra être particulièrement vigilant pour éviter les filtres en double dans une stratégie IPSec car les filtres peuvent correspondre à des actions distinctes. Le service IPSec peut modifier l'ordre des filtres en double en traitement par paquets et produire des résultats incohérents. Vous pouvez recourir aux filtres en double lorsqu'ils impliquent exactement la même action (par exemple, action d'autorisation ou de blocage) et que les performances restent inchangées. Les informations de réseau recueillies précédemment sont utilisées pour identifier les divers modèles de trafic que l'administrateur souhaite sécuriser. Elles permettent aussi d'identifier toutes les données en circulation pouvant bénéficier d'une exemption pour les restrictions IPSec. Le tableau cidessous décrit certaines listes de filtres élémentaires susceptibles d'être utilisées dans une organisation classique. Selon les besoins commerciaux et la conception du réseau de l'organisation, d'autres listes de filtres peuvent être nécessaires. Tableau 5.1 : Listes de filtres de la solution Liste de filtres
Description
Secure Subnets List (Liste des sous réseaux sécurisés)
Contient tous les sousréseaux de l'organisation à sécuriser avec IPSec.
DNS Exemption List (Liste d'exemptions DNS)
Contient les adresses IP des serveurs DNS qui seront autorisés à communiquer sans IPSec.
Domain Controllers Exemption List (Liste d'exemptions de contrôleurs de domaine)
Contient les adresses IP des contrôleurs de domaine qui seront autorisés à communiquer sans IPSec.
WINS Exemption List (Liste d'exemptions WINS)
Contient les adresses IP des serveurs WINS (Windows Internet Naming Service) qui seront autorisés à communiquer sans IPSec.
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
Contient le filtre permettant au trafic de négociation DHCP (Dynamic Host Configuration Protocol) d'avoir lieu sur le port UDP 68.
ICMP, All Traffic (ICMP, tout le trafic)
Contient le filtre qui permet au protocole ICMP (Internet Control Message Protocol) d'être utilisé au sein de
104
l'organisation à des fins de dépannage. La liste des sousréseaux sécurisés répertorie tous les sousréseaux disponibles sur le réseau interne de l'organisation. Cette liste de filtres est associée à une action de filtrage chargée d'implémenter les actions requises pour un groupe d'isolation spécifique. Cette action constitue l'action de sécurité la plus étendue pour l'ensemble du trafic réseau de ce sousréseau (par exemple, négociation IPSec) ; les autres filtres, notamment le filtre ICMP, seront plus spécifiques et nécessiteront une action différente (par exemple, autorisation). Un point primordial à retenir est que cette approche signifie qu'aucun hôte non approuvé ou nonIPSec ne doit figurer sur ces sousréseaux. Les filtres doivent implémenter à la fois des exigences de sécurité en entrée et en sortie. Au moment de les définir, vous devez les configurer en miroir. La mise en miroir garantit que le filtre est appliqué au trafic dont les adresses source et de destination sont exactement inverses. Lorsque vous définissez des filtres, le symbole « <> » est employé pour signaler que le filtre est mis en miroir. Vous devez utiliser des filtres en miroir chaque fois que l'action de filtrage négocie les méthodes de sécurité pour l'encapsulation IPSec. Adresses source et de destination Chaque filtre dispose d'un paramètre désignant à la fois les adresses source et de destination. Windows XP et Windows Server 2003 offrent plus d'options que Windows 2000 pour les adresses. Utilisez donc les paramètres Windows 2000 uniquement si cette plateforme est membre du domaine. Les paramètres Windows 2000 se présentent comme suit :
• Mon adresse IP. Cette option a été conçue afin d'appliquer une stratégie IPSec commune dans
Active Directory à plusieurs ou à l'ensemble des ordinateurs, qu'ils disposent d'une adresse IP statique ou d'une adresse attribuée par le serveur DHCP. Pour permettre la gestion centralisée des stratégies à partir du domaine, IPSec ne prend pas en charge la configuration des filtres pour les interfaces de réseau physique mais uniquement des interfaces réseau de type réseau local ou étendu ou des interfaces d'accès réseau à distance ou de réseau privé virtuel (VPN). Lorsque vous sélectionnez l'option Mon adresse IP, les filtres génériques de la stratégie IPSec sont copiés dans un filtre spécifique contenant chaque adresse IP utilisée par l'ordinateur au moment où le service IPSec s'apprête à appliquer la stratégie. Elle permet aussi au service IPSec de détecter toutes les modifications apportées aux adresses ou toute nouvelle interface réseau afin de conserver le nombre approprié de filtres. Si un ordinateur dispose d'une carte réseau pour laquelle deux adresses IP ont été configurées, deux filtres IPSec spécifiques différents sont créés à partir des deux adresses IP distinctes.
• N'importe quelle adresse IP. Cette option permet d'appliquer les filtres IPSec à n'importe quelle adresse IP.
• Un nom DNS spécifique. Grâce à cette option, IPSec peut évaluer l'adresse IP du nom DNS
spécifié, puis créer les filtres à partir de cette ou ces adresses IP. Le résultat obtenu est le même que si l'administrateur avait entré les adresses IP dans les filtres. Lors de la création du premier filtre, le nom DNS est résolu et les adresses IP correspondantes sont placées dans le filtre. Si le serveur DNS dispose d'un enregistrement de ressource incorrect pour le nom DNS spécifié dans le filtre, l'adresse IP erronée est ajoutée au filtre.
Remarque : le nom DNS n'est jamais évalué après la création initiale des filtres au sein de la stratégie. L'option de nom DNS est utile lorsque vous avez besoin de créer un grand nombre de filtres, car le nom DNS correspond à de nombreuses adresses IP, notamment pour chaque contrôleur de domaine appartenant au domaine. Il n'existe aucune méthode de création automatique de filtres dont la liste d'adresses IP peut être actualisée pour un nom DNS donné.
105
• Une adresse IP spécifique. Cette option compare le trafic avec l'adresse IP spécifiée dans le filtre.
• Un sousréseau IP spécifique. Cette option permet à l'administrateur de configurer un sous
réseau spécifique. N'importe quelle adresse IP au sein du sousréseau spécifié correspondra au filtre. Manipulez cette option avec soin, surtout si vous avez défini une exemption pour un sous réseau (tout utilisateur malveillant s'emparant d'une adresse IP de ce sousréseau sera, lui aussi, exempté).
Remarque : Windows XP et Windows Server 2003 ont été améliorés en vue de fournir des options d'adresse supplémentaires et d'autres options prises en charge dans ces versions. Si la même stratégie IPSec est appliquée à plusieurs platesformes, l'administrateur doit s'assurer que seules les options de Windows 2000 sont utilisées dans l'élaboration de la stratégie. Protocoles Outre les adresses source et de destination, chaque filtre peut être configuré pour rechercher un protocole ou un port spécifique. Par défaut, le filtre s'appliquera au trafic sur tous les protocoles et tous les ports. Si un protocole spécifique prenant en charge les ports est sélectionné en tant que critère de filtrage, l'administrateur a également la possibilité de configurer les ports source et de destination. Ports source et de destination Bien que les filtres puissent être configurés afin d'être adaptés aux ports TCP ou UDP, cette solution ne recommande pas la création de filtres spécifiques aux ports. Le filtrage par port augmente considérablement la charge administrative et la complexité de la configuration des filtres IPSec et peut exiger un effort de coordination complexe entre les stratégies client et serveur pour permettre une négociation correcte de la sécurité par IKE. Puisque cette solution part du principe que la communication entre les ordinateurs approuvés est en fait approuvée, les filtres autorisent IPSec à sécuriser tout le trafic (sauf le trafic ICMP). Si le filtrage par port s'avère nécessaire sur l'hôte approuvé, reportezvous à la feuille de calcul Business_Requirements.xls pour connaître les conditions de sécurité liées à l'utilisation combinée d'IPSec et d'un parefeu basé sur un hôte (par exemple, le parefeu Windows) superposé sur la couche IPSec. Pour éviter certains des problèmes mentionnés dans l'annexe A et inhérents au comportement des filtres avec l'option « Mon adresse IP », cette solution utilise des filtres N'importe quelle adresse IP <> sousréseaux pour le scénario de la Woodgrove Bank. Une liste composée de plusieurs filtres N'importe quelle adresse IP <> Un sousréseau IP spécifique est créée, répertoriant de manière explicite tous les sousréseaux de l'organisation. Cette approche permet à l'administrateur de définir les sousréseaux spécifiques à sécuriser. Tout le trafic circulant en dehors des sousréseaux spécifiés ne correspond à aucun filtre IPSec et est envoyé en clair à l'hôte de destination. Pour connaître d'autres méthodes conseillées pour la création de filtres, reportezvous à la section « Best Practices » (Meilleures pratiques) du livre blanc « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) sur Microsoft TechNet à l'adresse www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx. Considérations relatives aux listes d'exemptions Pour des raisons de support, techniques ou commerciales, certains types de trafic ne peuvent pas être protégés par IPSec. De même, la prise en charge d'IPSec n'est pas garantie sur les ordinateurs non dotés du système d'exploitation Windows et son déploiement peut s'y avérer délicat. Les
106
ordinateurs munis d'anciennes versions de Windows, notamment Microsoft Windows NT® version 4.0, Windows 95 et Windows 98, ne peuvent pas gérer une structure IPSec fondée sur la stratégie de groupe. Enfin, les ordinateurs non gérés équipés de Windows 2000 (ou ultérieur) peuvent uniquement participer à la négociation IPSec si la stratégie est déployée manuellement sur chaque ordinateur et qu'une forme d'authentification autre que le protocole Kerberos version 5 (par exemple, une clé pré partagée ou un certificat) est utilisée. Qui plus est, un ordinateur équipé de Windows 2000 (ou ultérieur) nécessite une connectivité réseau et doit être en mesure de se procurer une stratégie IPSec à partir du domaine avant d'implémenter IPSec. À l'heure actuelle, la connexion au réseau, l'identification d'un contrôleur de domaine et l'obtention de la stratégie exigent que les services de l'infrastructure de soutien soient exemptés de la sécurité IPSec. Il peut s'agir de services d'attribution de noms, tels que les services DNS et WINS, et des contrôleurs de domaine euxmêmes. Outre ces services d'infrastructure, d'autres services ne prenant pas en charge IPSec peuvent être présents dans l'organisation. Par exemple, les clients légers ou d'autres clients d'amorçage (BOOTP) cherchant à télécharger une image depuis des services ADS (Advanced Deployment Services) ou des services d'installation à distance (RIS) ne prennent pas en charge IPSec. Si des serveurs fournissant ces services existent sur votre réseau, vous devez les examiner et envisager de les intégrer dans une liste d'exemptions ou bien les affecter en tant que membres du groupe d'isolation de limite afin qu'ils puissent accepter les communications réseau provenant des hôtes inaptes à utiliser IPSec. Remarque : la décision d'inclure ou non les serveurs dotés de services ADS, RIS ou d'autres services répertoriés dans les listes d'exemptions, ou celle de les définir en tant que membres du groupe d'isolation de limite, dépend de critères de risque et de facilité de gestion. Dans un cas comme dans l'autre, vous devez tester avec soin l'approche choisie. Si un client est inapte à participer à l'infrastructure IPSec mais doit, pour des besoins commerciaux, accéder à un serveur qui utilise IPSec, vous devez implémenter une méthode permettant d'établir un chemin de communication. La solution de ce guide fait appel à des listes d'exemptions pour contrôler ces exigences de trafic par le biais d'autorisations. Les listes d'exemptions sont créées dans l'infrastructure IPSec pour s'assurer que toutes les communications requises avec les hôtes ont lieu, même si l'utilisation de négociations IPSec est impossible. Leur but est d'empêcher le trafic (de manière sélective) de participer à l'infrastructure IPSec en autorisant seulement le trafic correspondant aux filtres des listes d'exemptions. Ces listes doivent être établies avec soin puisqu'elles ne sont pas soumises aux mécanismes de sécurité mis en place par IPSec. Par exemple, si vous placez un serveur généralement sécurisé par chiffrement (protection des informations propriétaires) dans un filtre d'exemption, les ordinateurs invités pourront communiquer directement avec le serveur sans l'aide d'IPSec. Les listes d'exemptions sont implémentées en tant que listes de filtres afin de réduire la taille des listes et faciliter la configuration de l'interface utilisateur. Par exemple, vous devez disposer d'une liste de filtres contenant les filtres de tous les contrôleurs de domaine ou des contrôleurs de domaine figurant dans chaque domaine. Un autre avantage à disposer de plusieurs listes de filtres réside dans le fait que vous pouvez aisément désactiver/activer la règle d'autorisation dans la stratégie IPSec. Lorsque vous concevez une règle pour définir une exemption dans la stratégie IPSec, il est préférable d'autoriser la quantité de trafic la plus infime possible à ne plus être protégé par IPSec. Néanmoins, la complexité et la taille de la stratégie IPSec, face aux gains de sécurité que représente l'emploi des filtres les plus spécifiques, implique des compromis. Notez que toutes les adresses IP des contrôleurs de domaine dans toutes les forêts approuvées doivent être exemptées afin que les clients d'un domaine ou d'une forêt puissent se procurer des tickets Kerberos pour les serveurs d'une autre forêt ou d'un autre domaine approuvé. Pour ses propres contrôleurs de domaine et ceux d'autres domaines, le client Windows Kerberos doit disposer des éléments suivants : ICMP, LDAP (Lightweight
107
Directory Access Protocol) sur port UDP 389 et le trafic Kerberos sur les ports UDP 88 et TCP 88. Les membres des domaines exigent d'autres types de trafic pour les contrôleurs de domaine de leur propre domaine, notamment SMB (Server Message Block) sur TCP 445, l'appel de procédure distante (RPC) et LDAP sur TCP 389. Lorsque les exigences de sécurité ne sont pas trop importantes, l'exemption est définie pour « tout le trafic » avec les adresses IP des contrôleurs de domaine pour simplifier les choses et réduire le nombre de filtres. Il peut être tentant d'exempter une application particulière par port, plutôt que par adresse de destination, pour éviter d'avoir à entretenir une liste d'adresses (par exemple, un trafic Telnet sortant utilisant le port TCP 23 pour accéder à des systèmes UNIX). Par exemple, imaginons l'exemption sortante suivante : Mon adresse IP à N'importe quelle adresse IP, TCP, src port N'importe lequel, dst port 23, miroir Le filtre entrant correspondant se présente comme suit : N'importe quelle adresse IP à Mon adresse IP, TCP, src port 23, dst port N'importe lequel Ce filtre entrant permettrait d'obtenir des réponses aux demandes de connexion Telnet, mais un attaquant pourrait également contourner les exigences d'authentification IPSec et accéder à n'importe quel port ouvert sur l'hôte. Les organisations devront évaluer avec soin les risques de sécurité d'une éventuelle attaque de ce type avant d'utiliser un tel filtre. Les risques sont sans doute réduits si vous spécifiez l'adresse IP de destination. Cette même situation peut se produire si l'exemption par défaut du protocole d'authentification Kerberos n'est pas désactivée. Reportezvous aux articles 811832 (http://support.microsoft.com/?kbid=811832) et 810207 (http://support.microsoft.com/? kbid=810207) de la Base de connaissances Microsoft pour obtenir des informations détaillées sur l'impact des exemptions par défaut en termes de conception et de sécurité. Vous devez concevoir les stratégies IPSec en partant du principe qu'aucune exemption par défaut n'est activée. L'insertion d'adresses système dans une liste d'exemptions exempte bel et bien ces systèmes de participer en tant qu'hôtes IPSec dans toutes les stratégies IPSec qui mettent en œuvre la liste d'exemptions. Du fait que la plupart des clients de l'organisation (y compris les clients invités) nécessitent habituellement un accès aux services d'infrastructure, notamment DHCP, DNS ou WINS, les serveurs fournissant ces services sont, en règle générale, implémentés de cette manière. Listes de filtres de la Woodgrove Bank Après avoir analysé les exigences de trafic décrites au chapitre 4, les administrateurs de la Woodgrove Bank ont élaboré les listes de filtres dans le tableau cidessous. Tableau 5.2 : Exemples de listes de filtres de la Woodgrove Bank Liste de filtres
Filtres définis
Secure Subnets (Sousréseaux sécurisés)
N'importe lequel <> 192.168.1.0/24
N'importe lequel <> 172.10.1.0/24
Toutes
DNS Exemption List (Liste d'exemptions DNS)
N'importe lequel <> 192.168.1.21
N'importe lequel <> 192.168.1.22
Toutes
Domain Controllers Exemption List (Liste d'exemptions N'importe lequel <> de contrôleurs de domaine) 192.168.1.21
108
Protocole ou port
N'importe lequel <> 192.168.1.22
Toutes
LOB Application Servers Exemption List (Liste d'exemptions de serveurs d'application commerciales)
N'importe lequel <> 192.168.1.10
Tous
WINS Exemption List (Liste d'exemptions WINS)
N'importe lequel <> 192.168.1.22
Tous
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
Mon adresse IP <> N'importe lequel
UDP source 68, dest 67
ICMP, All Traffic (ICMP, tout le trafic)
Mon adresse IP <> N'importe lequel
ICMP uniquement
Les concepteurs de la Woodgrove Bank ont suivi les instructions fournies dans ce chapitre pour créer les listes de filtres. La première liste, celle des sousréseaux sécurisés, comporte deux filtres :
• N'importe lequel <> 192.168.1.0/24 • N'importe lequel <> 172.10.1.0/24 Ces filtres de sousréseaux sont mis en miroir pour correspondre à la fois au trafic entrant et sortant et sont configurés pour être déclenchés sur n'importe quel protocole. Cette liste de filtres, une fois associée à l'action de filtrage appropriée, procèdera à l'implémentation des groupes d'isolation. Les concepteurs de la Woodgrove Bank ont choisi d'implémenter ensuite une liste d'exemptions pour le trafic réseau ICMP. Cette liste de filtres comprend un filtre miroir unique (Mon adresse IP <> N'importe lequel) configuré exclusivement pour le trafic réseau ICMP. Cette approche permet aux administrateurs d'utiliser l'utilitaire Ping en tant qu'outil de dépannage au sein de l'environnement, sans se soucier de savoir si une association de sécurité IPSec a été négociée ou non. Cette approche s'avérait également nécessaire du fait que la solution exige la découverte du PMTU (Path MTU) pour fonctionner correctement. Pour le trafic DHCP, les concepteurs de la Woodgrove Bank ont créé un nouveau filtre pour le port UDP 68 afin de permettre aux clients DHCP de recevoir le trafic provenant du serveur DHCP. De plus, la Woodgrove Bank dispose de quelques applications commerciales sur des serveurs inaptes à participer à l'infrastructure IPSec. Pour adapter ces services, ils ont créé une nouvelle liste de filtres d'exemption (LOB Application Servers Exemption List) et ajouté un filtre N'importe lequel <> 192.168.1.10 pour le système hébergeant l'application commerciale. Pour finir, l'équipe de conception de la Woodgrove Bank a identifié ses services d'infrastructure et créé les listes de filtres d'exemption correspondantes pour permettre à tous les clients de communiquer directement avec les serveurs fournissant ces services, quels que soient les paramètres IPSec des groupes d'isolation. Des listes d'exemptions spécifiques ont été créées pour les services suivants :
• DNS. Cette liste exempte les serveurs DNS afin que tous les clients du réseau puissent procéder à des recherches de noms de domaines.
• Contrôleurs de domaine. Cette liste permet aux systèmes associés à des domaines de s'authentifier avec un contrôleur de domaine.
• WINS. Cette liste permet surtout aux périphériques hôtes de rechercher des noms NetBIOS sur un serveur WINS.
109
Ces listes de filtres sont composées de filtres mis en miroir (de type N'importe lequel <> Une adresse IP spécifique) configurés pour se déclencher sur n'importe quel protocole. Le nombre d'ordinateurs inscrits dans les listes de filtres d'exemption doit rester aussi réduit que possible puisque tout le trafic est exempté sur ces ordinateurs et que tous les ordinateurs de la liste d'exemptions bénéficient d'un accès TCP/IP intégral à tous les hôtes approuvés du domaine d'isolation. Cette approche peut, par conséquent, élargir la surface d'attaque potentielle. Consultez la feuille de calcul Business_Requirements.xls (dossier Tools and Templates) pour obtenir des détails sur les exigences d'atténuation des risques liés au trafic entrant depuis les adresses IP exemptées. La Woodgrove Bank a choisi de gérer deux listes séparées pour les serveurs DNS et les contrôleurs de domaine, même si les adresses IP sont identiques. La Woodgrove Bank a opté pour cette approche parce que les deux listes de filtres présenteront exactement la même action (autoriser). De plus, le réseau de production Woodgrove utilise les serveurs DNS dans certains domaines où ils ne sont pas également des contrôleurs de domaine. Au lieu d'utiliser des adresses IP de destination spécifiques, le filtre DHCP a été conçu pour s'appliquer à l'ensemble du trafic sortant des clients DHCP. La copie miroir de ce filtre autorise les réponses des serveurs DHCP. Comme nous l'avons déjà indiqué, il peut également autoriser des attaques entrantes depuis n'importe quelle adresse IP utilisant le port source 67. En revanche, l'attaque entrante est limitée au port de destination 68 sur le client, ce que le client DHCP utilise. La Woodgrove Bank a utilisé cette conception pour éviter de créer des filtres pour chaque serveur DHCP et parce que son évaluation des risques a conclu que les risques d'attaques entrantes sur le port du client DHCP ou les risques de serveurs DHCP non autorisés n'étaient pas très élevés. Cette section ne fournit pas une description complète de chaque filtre. Néanmoins, nous vous conseillons d'utiliser le champ de description du filtre pour définir avec soin chaque filtre puisque le moniteur IPSec et les outils de ligne de commande affichent la description de chaque filtre, pas les informations dans la liste de filtres.
Actions de filtrage IPSec Les actions de filtrage définissent la manière dont les paquets IP sont gérés après qu'ils aient été reconnus par un filtre de la liste des filtres. Les actions de filtrage sont à la base de l'implémentation des divers groupes d'isolation. Bien que le système d'exploitation Windows propose trois actions de filtrage par défaut, nous vous conseillons de les retirer et de créer d'autres actions de filtrage conformes à cette approche pour veiller à ce que seules les actions que vous créez dans le cadre de votre solution soient utilisées. Chaque action de filtrage est composée d'un nom, d'une description et d'une méthode de sécurité. Nom Donnez un nom significatif à l'action de filtrage, qui reflète ce qu'elle fait. Description Tapez une description détaillée de l'action de filtrage dans le champ de description. Méthodes de sécurité Les méthodes de sécurité implémentées dans l'action de filtrage sont déterminées par les exigences de traitement des paquets correspondant aux filtres associés dans la liste de filtres. Les trois options disponibles sont les suivantes :
110
• Bloquer. Les paquets IP correspondant au filtre associé sont bloqués, ce qui signifie qu'ils sont ignorés.
• Autoriser. Les paquets IP correspondant au filtre associé sont autorisés à traverser la couche IPSec sans traitement supplémentaire dans IPSec.
• Négocier. Si les paquets sortants répondent aux critères du filtre, IPSec tente de négocier l'une
des méthodes de sécurité inscrites dans l'action de filtrage selon leur ordre relatif. Plus la méthode de sécurité est haut dans la liste, plus la priorité qui lui est accordée est grande. Chaque méthode de sécurité peut déterminer s'il faut utiliser l'outil d'intégrité, activer le chiffrement et quels algorithmes de cryptographie sont implémentés. Le traitement des paquets entrants correspondant à un filtre doté d'une action de négociation (négocier) est fonction du paramètre défini pour l'option Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec.
Le tableau ciaprès répertorie les options cryptographiques possibles pour chaque méthode de sécurité : Tableau 5.3 : Options cryptographiques et de sécurité Méthode de sécurité Authentification de l'entête (AH)
Options cryptographiques MD5 SHA1
ESP – Intégrité
MD5 SHA1
ESP – chiffrement
3DES DES
Description Garantit à la fois l'authenticité et l'intégrité de la charge utile IP (données) et de l'entête IP (adresse) sans chiffrement. AH ne peut pas traverser les périphériques utilisant la traduction d'adresses réseau (NAT). Garantit l'intégrité et l'authenticité des données de la charge utile IP (données) uniquement. Elle peut être utilisée avec ou sans chiffrement. L'utilisation d'ESP sans authentification est déconseillée. Avec DES ou 3DES, fournit le chiffrement de la charge utile IP (données). Peut être utilisée avec un algorithme de chiffrement nul lorsque le chiffrement n'est pas nécessaire.
Les implémentations IPSec dans Windows 2000 SP4, Windows XP SP2 et Windows Server 2003 prennent désormais en charge les techniques NATT pour ESP en mode de transport IPSec, en plus de la prise en charge de NATT pour les tunnels clients VPN L2TP/IPSec. La mise à jour NATT est requise pour Windows 2000 SP4. La prise en charge de NATT en mode de transport IPSec dans Windows 2000 et Windows XP est limitée aux versions Windows 2000 et Windows XP antérieures au SP2 puisque la fonctionnalité de détection PMTU (PathMTU) TCP n'est pas prise en charge pour le trafic TCP protégé par IPSec. Windows Server 2003 offre cette prise en charge. Les techniques NAT T utilisent un entête UDP après l'entête IP pour encapsuler ESP. IKE détecte automatiquement l'existence de NAT dans le chemin et utilise UDPESP si ESP est autorisé dans la liste des méthodes de sécurité. Un point également à noter est que les implémentations IPSec Windows actuelles ne prennent pas en charge la norme AES (Advanced Encryption Standard) du gouvernement fédéral américain. Cela sera corrigé dans les versions prochaines de Windows. Les options cryptographiques disponibles pour AH et ESP sont les suivantes :
• MD5. Cet algorithme de hachage utilise une clé de chiffrement de 128 bits pour générer un résumé du contenu du paquet. MD5 n'est pas un algorithme adapté à des scénarios de sécurité du gouvernement fédéral américain.
• SHA1. Cet algorithme de hachage utilise une clé de chiffrement de 160 bits pour générer un
résumé du contenu du paquet. Plus la clé de SHA1 est longue, plus la sécurité est élevée mais la
111
charge requise pour le traitement est, elle aussi, plus importante. SHA1 est un algorithme adapté aux réglementations de sécurité du gouvernement fédéral américain. Vous pouvez configurer ESP afin qu'il n'utilise aucun algorithme de chiffrement, auquel cas seules l'authenticité et l'intégrité des données sont appliquées. Cette configuration, couramment appelée ESPNull, offre la possibilité d'authentifier les hôtes avant d'établir une connexion et d'effectuer une vérification de l'intégrité de la section des données du paquet IP transporté au sein du paquet ESP. ESP peut également chiffrer la section des données du paquet IP. Les deux options cryptographiques disponibles sont les suivantes :
• DES. Cette option utilise une clé 56 bits et traite chaque bloc une seule fois. DES offre une conformité RFC (Request for Comment). Les attaquants étant de plus en plus capables de compromettre le chiffrement DES, l'utilisation de l'option DES n'est pas conseillée.
• 3DES. Cette option traite chaque bloc trois fois à l'aide de trois clés 56 bits uniques. Bien que
l'option DES soit prise en charge, il est vivement recommandé d'utiliser l'option plus sécurisée 3DES. En revanche, 3DES est un peu plus lent et exige une capacité de traitement plus élevée que DES.
Vous pouvez combiner les protocoles AH et ESP s'ils doivent répondre à des exigences de sécurité optimales. Par exemple, si votre infrastructure exige clairement l'intégrité de l'entête IP en plus du chiffrement des données, vous pouvez configurer la méthode de sécurité afin qu'elle utilise le protocole AH avec une intégrité SHA1 et un chiffrement ESP–3DES. Si seule l'intégrité des données est requise, vous pouvez alors utiliser ESPNull avec SHA1. Bien que vous puissiez choisir une combinaison quelconque d'options de sécurité, il faut savoir que le protocole AH garantit à la fois l'intégrité des données et de l'entête d'adresse. L'utilisation combinée des protocoles AH et ESP ne renforce pas la protection de l'intégrité des données des paquets. Elle augmente simplement la charge de travail associée au traitement du paquet. Qui plus est, ESP associé à AH ne résout pas les problèmes de barrière NAT auxquels le protocole AH est confronté. L'utilisation du protocole AH avec ESP ne convient donc qu'aux environnements de haute sécurité. Une planification minutieuse est nécessaire pour définir les méthodes de sécurité des actions de filtrage. Pour mener à bien la négociation de deux ordinateurs, ces derniers doivent disposer au moins d'une méthode de sécurité en commun dans leurs actions de filtrage respectives. Chaque action de filtrage peut contenir plusieurs méthodes de négociation en vue de s'adapter à différents types de négociation. Par exemple, un système négocie souvent uniquement ESPNull, mais l'action de filtrage peut contenir également une méthode de négociation pour ESP3DES. Cette approche permet au système de négocier une connexion de chiffrement 3DES si celleci est nécessaire. Outre le choix des méthodes de sécurité, vous pouvez au besoin définir les paramètres de la clé de session pour chaque méthode de sécurité. Dans le paramètre par défaut, la durée de vie des associations de sécurité IPSec est fixée au moment où 100 mégaoctets (Mo) de données sont transmises ou au bout d'une heure de temps passé. Ces paramètres détectent chaque nouvelle paire d'associations de sécurité IPSec renégociée en mode rapide IKE. Bien que le processus du mode rapide IKE soit appelé « régénération des clés », il ne se contente pas d'actualiser les clés d'une paire d'associations de sécurité IPSec. IPSec doit ignorer les paquets si la durée de vie expire ; il s'efforce donc de renégocier comme il se doit avant que la durée de vie en octets ou en secondes n'expire. Si la durée de vie définie est trop faible, les paquets risquent d'être perdus. De même, vous pouvez augmenter le taux d'utilisation du processeur pour les serveurs chargés d'entretenir les associations de sécurité IPSec avec un grand nombre de clients. Le renouvellement des associations de sécurité IPSec garantit qu'aucun attaquant ne peut déchiffrer l'ensemble de la communication même s'il parvient à déterminer l'une des clés de la session. À mesure que la durée de vie augmente, l'attaquant obtient davantage d'informations sur la clé de la session. Par conséquent, il est préférable que vous
112
ne changiez pas la durée de vie sauf si des besoins opérationnels l'exigent. Vous pouvez également rédiger des exigences de sécurité spécifiques qui définissent un niveau approprié de protection contre des attaques cryptographiques élaborées. Options de négociation de sécurité Vous pouvez définir les options de négociation de sécurité suivantes pour les stratégies IPSec :
• Relais entrant • Communiquer en texte clair • Utiliser la session de clé principale PFS (Perfect Forward Secrecy) Relais entrant L'option Relais entrant a été conçue pour être utilisée dans une stratégie serveur interne afin que la stratégie client puisse adopter la règle de « réponse par défaut » non intrusive. Une fois cette option activée, toute demande de connexion soumise en texte clair et correspondant à un filtre entrant sera acceptée. La réponse de connexion du serveur correspond au filtre sortant pour déclencher une demande de négociation IKE en mode principal au client. Il est préférable de ne pas activer cette option sur des ordinateurs reliés à Internet en raison des attaques entrantes qu'elle laisse circuler à travers la couche IPSec. Elle force également le serveur à tenter une négociation d'association de sécurité IPSec sur l'adresse IP source de tout paquet entrant. En prenant le contrôle des adresses IP source, l'attaquant peut provoquer un refus de service sur le serveur tandis qu'IKE tente de négocier avec des centaines ou des milliers d'adresses IP non valides. Pour activer l'option Relais entrant, activez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec dans la boîte de dialogue Gérer les actions de filtrage. Remarque : si les stratégies attribuées aux clients n'activent pas la règle de réponse par défaut, vous devez désactiver cette option puisqu'il n'y aura aucune réponse pour la communication IPSec. De plus, elle peut être utilisée comme vecteur d'attaque de refus de service. Communiquer en texte clair L'option Communiquer en texte clair avec les ordinateurs qui ne prennent pas en charge IPSec contrôle la capacité de l'ordinateur (source) à transmettre le trafic sans protection IPSec si la négociation IKE initiale en mode normal n'obtient aucune réponse d'un ordinateur de destination cible. Les hôtes qui ne prennent pas en charge IPSec ne seront pas en mesure de répondre (via IKE) à la demande de négociation IKE. Dans le cas de ces hôtes, on parle d'ordinateurs qui n'utilisent pas IPSec. Néanmoins, l'absence de réponse IKE en mode principal ne signifie pas nécessairement que l'ordinateur n'est pas compatible avec IPSec. Il peut s'agir d'un ordinateur IPSec qui ne dispose pas d'une stratégie IPSec active. La stratégie IPSec active peut aussi n'effectuer que des actions autoriser et bloquer. Elle peut également ne pas avoir été conçue pour négocier avec l'adresse IP de l'ordinateur source. En terminologie IPSec, le trafic réseau qui n'utilise pas IPSec est appelé trafic en texte clair. Si l'ordinateur cible ne répond pas sous trois secondes, une association de sécurité logicielle (SA logicielle) est créée et la communication est entamée en texte clair. Pour vos premiers déploiements, nous vous conseillons d'activer cette option afin que les clients puissent communiquer avec les hôtes sur lesquels IPSec n'est pas activé. De même, le recours à cette option permet aussi d'établir à nouveau une connectivité provisoire en texte clair lorsque vous arrêtez le service IPSec à des fins de dépannage. Si l'ordinateur cible fournit une réponse IKE et qu'un échec de la
113
négociation IKE survient pour une raison quelconque, IPSec ignore les paquets sortants sur l'ordinateur source et bloque véritablement la communication. Pour activer l'option Communiquer en texte clair, activez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans la boîte de dialogue Gérer les actions de filtrage. Remarque : le mode de fonctionnement de cette option a évolué sur les ordinateurs fonctionnant sous Windows 2000 SP3 (ou ultérieur), Windows XP SP1 ou Windows Server 2003. Si vous activez uniquement cette option, le système pourra lancer une communication sécurisée mais n'acceptera aucune demande de communication de systèmes n'utilisant pas IPSec. Si le système doit répondre à des demandes en provenance de systèmes qui n'utilisent pas IPSec et établir une communication avec ces systèmes, vous devez activer à la fois les cases à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec et Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec. Si le système fonctionne sous Windows 2000 ou Windows XP sans les service packs appropriés, le client accepte les demandes de communication non sécurisée dès que vous sélectionnez l'option Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec, même si la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec est désactivée. Ce comportement se produit parce que lorsque vous activez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec, IPSec traite le filtre entrant associé en tant que filtre relais entrant (le même comportement que lorsque vous activez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec). Utiliser la session de clé principale PFS (Perfect Forward Secrecy) L'option Utiliser la session de clé principale PFS (Perfect Forward Secrecy) permet de déterminer si la clé principale peut générer toutes les clés de session ou seulement la première. En activant cette option, vous ne pourrez utiliser la clé principale qu'une seule fois et chaque renégociation de clé de session supplémentaire exigera un nouvel échange de clés pour générer une nouvelle clé principale avant de générer la clé de session. Cette exigence garantit qu'en cas de clé principale compromise, l'attaquant ne peut générer aucune clé de session supplémentaire lui permettant de déchiffrer le flux de trafic. Nous vous déconseillons d'activer cette option en raison de la charge supplémentaire qu'implique un échange de clés à chaque intervalle de renouvellement de clé de session. Pour plus d'informations sur les options Relais entrant, Communiquer en texte clair et les options de clé de session et de clé principale PFS, reportezvous à la section « Security Negotiation Options » (Options de négociation de sécurité) du document Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server (Utilisation de Microsoft Windows IPSec pour aider à sécuriser un serveur de réseau d'entreprise interne) disponible depuis le Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?familyid=a774012aac254a1d8851 b7a09e3f1dc9&displaylang=en. Actions de filtrage IPSec de la Woodgrove Bank Le tableau ciaprès fournit les noms et les descriptions des actions de filtrage utilisées pour l'implémentation des divers groupes d'isolation intervenant dans le scénario de la Woodgrove Bank. Tableau 5.4 : Actions de filtrage IPSec et descriptions Action de filtrage
Description
IPSec – Block (Bloquer)
Bloque le trafic correspondant au filtre.
114
IPSec – Permit (Autoriser)
Autorise le trafic correspondant au filtre.
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant)
Un hôte accepte les paquets entrants qui sont soit de type IPSec, soit en texte clair. Pour le trafic sortant, il déclenche une négociation IKE et autorise l'option Communiquer en texte clair s'il ne reçoit aucune réponse. Cette action de filtrage est utilisée pour la configuration du groupe d'isolation de limite.
IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant)
Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les paquets sont sécurisés par IPSec et ignore les paquets entrants nonIPSec. Pour le trafic sortant, il déclenche une négociation IKE et autorise l'option Communiquer en texte clair s'il ne reçoit aucune réponse. Ce filtre sert à l'implémentation du domaine d'isolation dans lequel les connexions sortantes vers les hôtes approuvés sont autorisées.
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) (Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
Un hôte exige des communications sécurisées IPSec pour les paquets entrants comme pour les paquets sortants. Cette action de filtrage permet d'implémenter le groupe d'isolation sans basculement dans lequel toutes les communications sont protégées par IPSec.
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les paquets sont sécurisés par chiffrement ESP 3DES IPSec et ignore les paquets entrants nonIPSec. Pour le trafic sortant, il déclenche une négociation IKE exigeant un chiffrement ESP 3DES IPSec. Cette action de filtrage est utilisée pour la configuration du groupe d'isolation de chiffrement.
Les deux premières actions de filtrage sont simples à réaliser. L'action de filtrage Bloquer ignore tout le trafic correspondant au filtre d'une liste de filtres associée à l'action. L'action de filtrage Autoriser autorise le trafic pour n'importe quelle liste de filtres associée contenant le filtre correspondant. Les quatre dernières actions de filtrage présentées dans le tableau 5.4 sont utilisées pour l'implémentation des groupes d'isolation dans le scénario de la Woodgrove Bank. Les administrateurs de la Woodgrove Bank ont quatre groupes d'isolation de sécurité à implémenter. Pour déployer cette configuration, vous devez définir au minimum trois actions de filtrage dotées de méthodes de négociation de sécurité personnalisées en plus des actions de filtrage Autoriser et Bloquer. La Woodgrove Bank n'impose aucune exigence supplémentaire pour l'isolation mutuelle des ordinateurs au sein d'un groupe d'isolation de sécurité spécifique. La Woodgrove Bank a établi que les quatre actions de filtrage négociées dans le tableau cidessous suffisent à la mise en place de son environnement : Tableau 5.5 : Méthodes de sécurité prises en charge Action de filtrage IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant) IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant) IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) 115
Méthodes de sécurité prises en charge ESP – SHA1, ESP – SHA1, 3DES ESP – SHA1, ESP – SHA1, 3DES ESP – SHA1,
(Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
ESP – SHA1, 3DES
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
ESP – SHA1, 3DES
La Woodgrove Bank utilise IPSec ESP au lieu du protocole AH en raison de la présence de périphériques réseau utilisant la traduction d'adresses réseau (NAT) dans l'organisation. La Woodgrove Bank exige également le chiffrement de certains serveurs de l'organisation. Par conséquent, toutes les stratégies nécessitent la possibilité de recourir au chiffrement. C'est pourquoi la Woodgrove Bank a choisi de développer sa sécurité uniquement sur la base du protocole IPSec ESP. Pour l'intégrité ESP, Woodgrove Bank a opté pour l'algorithme SHA1 (au lieu de MD5) parce qu'il offre une meilleure sécurité mais aussi parce qu'elle doit respecter les réglementations du gouvernement américain relatives au traitement de données financières, impliquant l'usage d'algorithmes approuvés. La Woodgrove Bank a décidé de ne pas implémenter le service PFS (Perfect Forward Secrecy) dans toutes les actions de filtrage car aucune menace de sécurité spécifique n'exigeait l'utilisation de ce service. Woodgrove cherche également à éviter l'impact de la renégociation des clés sur les performances des ordinateurs. Action de filtrage du domaine d'isolation Pour implémenter le domaine d'isolation, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage « IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) ». Pour diverses raisons commerciales, les hôtes du domaine d'isolation et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du domaine d'isolation doivent donc effectuer les actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 du présent guide :
• Établir des communications avec les hôtes du groupe d'isolation sans basculement. • Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du groupe d'isolation de chiffrement. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec les hôtes du groupe d'isolation de limite. • Accepter les communications provenant des hôtes du groupe d'isolation de limite. • Établir une communication avec des systèmes non approuvés Les clients du domaine d'isolation ne peuvent pas accepter des communications provenant de systèmes non approuvés. Souvenezvous que la stratégie IPSec utilise des filtres et des actions de filtrage pour intercepter et contrôler les paquets IP entrants et sortants. Bien qu'IKE authentifie les deux ordinateurs, l'appartenance à un groupe d'un ordinateur utilisant une adresse IP donnée n'est pas connue au moment de l'envoi de la demande initiale de connexion. Par conséquent, IPSec et IKE ne peuvent pas être spécifiquement configurés pour établir des communications d'une manière précise avec une identité ou un groupe d'isolation particulier. De même, les ordinateurs membres de ces groupes
116
d'isolation peuvent résider n'importe où sur le réseau interne. Vous ne pouvez donc pas utiliser des adresses IP pour définir de manière précise ou approximative les groupes d'isolation. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites cidessus en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ; ignorer le trafic s'il n'est pas déjà sécurisé dans des paquets IPSec ESP valides.
Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de sécurité incluent les méthodes de sécurité (algorithmes ESP–SHA1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportezvous à la section « Action de filtrage du groupe d'isolation de chiffrement » plus loin dans ce chapitre. Pour le trafic au sein du domaine d'isolation et avec les groupes d'isolation de limite et sans basculement, la Woodgrove Bank utilise ESPNull avec l'algorithme SHA1. Vous devez désactiver la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSecdans l'action de filtrage afin que les communications entrantes en texte clair soit ignorées. Cette approche garantit que les hôtes du domaine d'isolation n'accepteront pas le trafic d'un ordinateur qui ne participe pas à l'environnement IPSec. L'action de filtrage IPSEC – Secure Request Security (Ignore Inbound, Allow Outbound) est configurée afin de permettre aux membres du domaine d'isolation d'établir des communications avec des systèmes non approuvés. Vous pouvez opter pour ce comportement en activant la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans l'action de filtrage. Si un hôte approuvé du domaine d'isolation établit une connexion sortante avec un hôte non approuvé (ou un autre système n'utilisant pas IPSec), l'association de sécurité logicielle IPSec est établie et demeure active pendant cinq minutes après l'arrêt du trafic. Pendant ce laps de temps, le système non approuvé est donc capable d'établir de nouvelles connexions en texte clair dans l'hôte approuvé. Une fois le délai de l'association de sécurité logicielle expiré, l'hôte approuvé ne pourra plus accepter aucun trafic en texte clair provenant de ce système. La prise en charge du filtrage IPSec et des associations de sécurité logicielles n'a pas été conçue en vue de fournir des mesures de protection spécifiques aux connexions (par exemple, le filtrage avec état), comme c'est le cas avec un grand nombre de parefeu. Les associations de sécurité logicielles autorisent tout le trafic correspondant au filtre associé. Pour plus d'informations sur ce processus, reportezvous à la section « SA de mode principal IKE et SA IPSec» de l'annexe A (« Présentation des concepts relatifs à la stratégie IPSec »). Action de filtrage du groupe d'isolation de limite Pour implémenter le groupe d'isolation de limite, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage IPSEC – Request Mode (Accept Inbound, Allow Outbound). Pour diverses raisons commerciales, les hôtes du groupe d'isolation de limite et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de limite doivent donc effectuer les actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 :
• Établir des communications avec les hôtes du groupe d'isolation sans basculement. 117
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec des systèmes non approuvés. • Accepter des communications provenant de systèmes non approuvés. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, accepter les paquets en texte clair adaptés aux filtres correspondants (tous les sous réseaux internes).
Pour répondre aux exigences d'établissement et d'acceptation du trafic vers et depuis le domaine d'isolation et le groupe d'isolation sans basculement, la Woodgrove Bank s'est assurée que les méthodes de négociation de sécurité pour le domaine d'isolation et le groupe d'isolation sans basculement étaient présentes dans l'action de filtrage. La méthode de négociation de sécurité commune retenue par la Woodgrove Bank est ESP avec l'algorithme SHA1 pour la vérification de l'intégrité. Les hôtes du groupe d'isolation de limite sont autorisés à communiquer avec des systèmes non approuvés. Pour faciliter cette fonction, l'équipe administrative de la Woodgrove Bank a activé à la fois les cases à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec et Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec pour cette action de filtrage. En activant ces deux options, la Woodgrove Bank a la garantie que les hôtes accepteront le trafic entrant non sécurisé et pourront communiquer en texte clair pour le trafic sortant non sécurisé. Action de filtrage du groupe d'isolation sans basculement Pour l'implémentation du groupe d'isolation sans basculement, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound). Pour diverses raisons commerciales, les hôtes du groupe d'isolation sans basculement et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation sans basculement peuvent donc effectuer les actions suivantes :
• Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Établir des communications avec les hôtes du groupe d'isolation de chiffrement. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec les hôtes du groupe d'isolation de limite.
118
• Accepter les communications provenant des hôtes du groupe d'isolation de limite. Les clients du groupe d'isolation sans basculement ne peuvent ni établir, ni accepter des communications provenant de systèmes non approuvés. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Ne pas autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sousréseaux internes) ; les ignorer.
Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de négociation de sécurité incluent les méthodes de négociation de chiffrement (algorithmes ESP–SHA 1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportezvous à la section « Action de filtrage du groupe d'isolation de chiffrement » plus loin dans ce chapitre. Pour le trafic vers les groupes d'isolation de limite et sans basculement, la Woodgrove Bank utilise ESP avec l'algorithme SHA1 comme méthode de négociation de sécurité pour vérifier l'intégrité. La case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec dans l'action de filtrage est désactivée pour créer le groupe d'isolation sans basculement. Cette approche garantit que les hôtes du groupe d'isolation sans basculement sécurisent tout le trafic entrant et sortant avec IPSec. Tout trafic provenant d'un ordinateur qui ne participe pas à l'environnement IPSec est ainsi refusé. L'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) ne permet pas à un ordinateur qui utilise cette action d'établir une communication avec un ordinateur qui ne participe pas à l'infrastructure IPSec. La case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec a été désactivée pour appliquer cette exigence. Action de filtrage du groupe d'isolation de chiffrement La Woodgrove Bank a choisi ESP en tant que protocole d'intégrité de base et l'algorithme SHA1 en tant qu'option cryptographique. De plus, les hôtes du groupe d'isolation de chiffrement ont besoin de communiquer avec ceux du domaine d'isolation et du groupe d'isolation sans basculement. L'action de filtrage a été configurée afin d'inclure les méthodes de négociation de sécurité chargées de chiffrer les informations. Pour diverses raisons commerciales, les hôtes du groupe d'isolation de chiffrement et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de chiffrement peuvent donc effectuer les actions suivantes du tableau 4.6 :
• Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Établir des communications avec les hôtes du groupe d'isolation sans basculement.
119
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du groupe d'isolation de limite. Les ordinateurs du groupe d'isolation de chiffrement ne sont pas autorisés à accepter des communications en provenance d'hôtes du groupe d'isolation de limite. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec ESP–SHA1– 3DES uniquement. Ne pas autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sousréseaux internes) ; les ignorer. Accepter uniquement les demandes de négociation IKE issues d'hôtes approuvés autorisant IPSec ESP–SHA1–3DES.
Les clients du groupe d'isolation de chiffrement ne peuvent pas accepter de communications en provenance du groupe d'isolation de limite, ni accepter ou établir de communications issues de systèmes non approuvés. Pour permettre les communications avec le domaine d'isolation, les méthodes de négociation de sécurité de chiffrement adoptées pour l'action de chiffrement IPSEC – Require Encryption Mode (Ignore Inbound, Disallow Outbound) sont également disponibles dans les actions de filtrage IPSEC – Secure Request (Ignore Inbound, Allow Outbound) et IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound). Woodgrove Bank utilise la méthode de chiffrement 3DES qui offre une meilleure sécurité que la méthode DES, mais représente une charge plus élevée. Pour répondre à la nécessité de ne pas accepter ou établir de communications avec des systèmes non approuvés, la Woodgrove Bank n'a pas activé la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec. Cette configuration garantit que les hôtes du groupe d'isolation de chiffrement n'accepteront pas le trafic d'un ordinateur qui ne participe pas à l'environnement IPSec. De plus, l'option Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec a elle aussi été désactivée pour empêcher des ordinateurs de chercher à établir des communications avec un autre ordinateur ne participant pas à l'environnement IPSec. Le blocage des communications IPSec à partir des ordinateurs du groupe d'isolation de limite impliquait d'autres tâches de configuration. Les administrateurs de la Woodgrove Bank ont attribué le droit « Refuser l'accès à cet ordinateur à partir du réseau » à l'objet Stratégie de groupe chargé de fournir la stratégie IPSec aux ordinateurs du groupe d'isolation de chiffrement. Ce droit a été appliqué à un groupe comprenant tous les comptes d'ordinateurs des systèmes participant au groupe d'isolation de limite. Si l'un de ces ordinateurs tentait d'établir des communications avec un système du groupe d'isolation de chiffrement, l'authentification IKE aboutirait à un refus d'autorisation et la communication serait bloquée.
Stratégies IPSec Les stratégies IPSec permettent de configurer des ordinateurs Windows pour qu'ils fonctionnent dans un environnement IPSec. Une stratégie IPSec désigne un ensemble de règles appliquées au trafic. Il existe trois types de stratégies IPSec pour Windows 2000 :
120
• Stratégie locale • Stratégie de domaine Active Directory • Stratégie dynamique Windows XP et Windows Server 2003 prennent en charge les types de stratégies supplémentaires suivants :
• Stratégie IPSec de démarrage. Stockée et gérée dans le Registre local. Prise en charge
uniquement sous Windows XP SP2 ou ultérieur. Elle est appliquée dès que l'ordinateur obtient une adresse IP, ce qui peut survenir avant le démarrage du service IPSec. Elle est remplacée lorsque le service applique une stratégie persistante.
• Stratégie IPSec persistante. Stockée et gérée dans le Registre de l'ordinateur local. Configurée à l'aide de l'outil de ligne de commande. Elle est appliquée en premier au démarrage du service IPSec. Elle remplace la stratégie de démarrage.
• Stratégie IPSec locale. Stockée et gérée dans l'ordinateur local. Configurée à l'aide du composant logiciel enfichable MMC (Microsoft Management Console) Gestion de stratégie IPSec ou de l'outil de ligne de commande. Elle est appliquée en plus de la stratégie persistante si aucune stratégie de domaine n'est définie.
• Stratégie IPSec de domaine Active Directory. Stockée dans Active Directory. Gérée par le
composant logiciel enfichable MMC Gestion de stratégie IPSec ou l'outil de ligne de commande. Elle remplace toutes les stratégies locales susceptibles d'être attribuées. Les stratégies IPSec Active Directory sont affectées à un objet Stratégie de groupe par l'intermédiaire du composant logiciel enfichable MMC Éditeur de stratégies de groupe ou la console de gestion des stratégies de groupe (GPMC) disponible sous Paramètres Windows, Paramètres de sécurité et Stratégies IPSec.
• Stratégie IPSec dynamique. Stockée uniquement en mémoire. Configurée à l'aide de l'outil de ligne de commande. Elle permet d'ajouter de manière dynamique des éléments à la stratégie existante. La stratégie dynamique est ignorée dès l'arrêt du service IPSec.
Pour des raisons de simplicité, le présent guide s'intéresse uniquement à l'utilisation de la stratégie IPSec dans le domaine Active Directory. Lorsque vous définissez des stratégies IPSec, il est préférable d'essayer de créer une stratégie générique qui sera la base de l'infrastructure IPSec pour tous les ordinateurs. Vous pouvez ensuite créer des stratégies supplémentaires pour appliquer des paramètres plus stricts aux systèmes exigeant une configuration de sécurité supplémentaire. Chaque stratégie supplémentaire doit cibler le plus grand nombre possible d'ordinateurs devant répondre à des exigences commerciales ou techniques particulières. En limitant le nombre total des stratégies, vous faciliterez la gestion des stratégies et la résolution des problèmes qui en découlent. Les stratégies IPSec sont composées d'un nom, d'une description, d'un ensemble de règles, de paramètres de configuration pour les fréquences d'interrogation, ainsi que de paramètres et de méthodes d'échange de clés. La section qui suit aborde tous ces éléments en détail. Nom Tout comme pour les actions de filtrage, vous devez attribuer des noms significatifs aux stratégies afin de faciliter la gestion et la résolution des problèmes liés à la solution pendant les phases d'implémentation et d'exploitation du projet.
121
Description Une description détaillée de la stratégie permettra aux administrateurs d'identifier l'objectif de la stratégie sans avoir à l'ouvrir et étudier les règles qui la définissent. Règles Une règle IPSec se compose d'une liste de filtres unique, d'une action de filtrage associée, des méthodes d'authentification employées pour établir le niveau d'approbation entre les ordinateurs, d'un type de connexion et du type de tunnel (le cas échéant). Chaque règle définit une ou plusieurs méthodes d'authentification à utiliser pour établir le niveau d'approbation entre les hôtes. Les options proposées sont le protocole Kerberos version 5, des certificats provenant d'une autorité de certification précise et des clés prépartagées. Le type de connexion définit les connexions auxquelles la stratégie IPSec s'applique. Vous pouvez configurer la stratégie pour l'appliquer à l'ensemble des connexions, à des connexions au réseau local ou à des connexions d'accès à distance. Le type de tunnel détermine si la stratégie IPSec définit un tunnel IPSec. Si le type de tunnel est désactivé, IPSec utilise le mode de transport. Pour prendre en charge les groupes d'isolation de sécurité identifiés plus haut dans ce guide, la Woodgrove Bank a mis en place quatre stratégies IPSec. Elle a les toutes configurées afin qu'elles utilisent le protocole d'authentification Kerberos version 5, soient appliquées à l'ensemble des connexions et ne définissent pas un tunnel IPSec. Le tableau cidessous décrit les stratégies adoptées dans le scénario de la Woodgrove Bank : Tableau 5.6 : Stratégies IPSec de la Woodgrove Bank Nom de stratégie
Description
IPSEC – Isolation Domain IPSec Policy (1.0.041001.1600) (Stratégie IPSec de domaine d'isolation)
Cette stratégie définit le domaine d'isolation. Les hôtes de ce groupe d'isolation ont la capacité de communiquer en texte clair lorsqu'ils établissent des communications avec des hôtes nonIPSec. Elle configure les hôtes pour qu'ils exigent une communication IPSec. Si la négociation échoue entre les clients utilisant IPSec, la communication échoue elle aussi.
IPSEC – Boundary Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de limite)
Cette stratégie définit le groupe d'isolation de limite. Elle configure les hôtes pour qu'ils demandent des communications IPSec mais leur permet de communiq uer en t exte cla ir si le s commun ications doivent être établies avec un hôte n'utilisant pas IPSec.
IPSEC – No Fallback Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation sans basculement)
Cette stratégie définit le groupe d'isolation sans basculement. Elle configure les hôtes pour qu'ils exigent une communication IPSec. Si la négociation échoue ou en cas de tentative de communication avec un client qui n'utilise pas IPSec, la communication échoue.
IPSEC – Encryption Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation
Cette stratégie définit le groupe d'isolation de chiffrement. Elle configure les hôtes pour qu'ils exigent une communication et un chiffrement IPSec. Si la négociation échoue ou en cas de tentative de communication avec un client qui n'utilise pas IPSec, la
122
de chiffrement)
communication échoue.
Le nombre associé à chaque nom de stratégie correspond à un numéro de version, comme expliqué plus loin dans la section « Versions des stratégies ». Chacune des stratégies de la Woodgrove Bank renferme les mêmes listes d'exemptions puisqu'il n'existe aucune exigence d'exemption d'un ensemble spécial d'ordinateurs pour un groupe d'isolation particulier. Le tableau ciaprès présente les règles activées et communes aux quatre stratégies identifiées dans le tableau précédent : Tableau 5.7 : Règles communes définies dans les stratégies IPSec de la Woodgrove Bank Liste de filtres
Action de filtrage
Méthodes d'authentification
Point de sortie du tunnel
Type de connexion
DNS Exemption List (Liste d'exemptions DNS)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
Domain Controllers Exemption IPSEC – List (Liste d'exemptions de Permit contrôleurs de domaine) (Autoriser)
Aucun
Aucun
Tous
Liste d'exemptions WINS (WINS Exemptions List)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
ICMP, All Traffic (ICMP, tout le IPSEC – trafic) Permit (Autoriser)
Aucun
Aucun
Tous
En plus des règles énumérées dans ce tableau, la règle de réponse client par défaut est désactivée dans chaque stratégie. Les quatre stratégies définies par la Woodgrove Bank diffèrent uniquement dans leur manière de gérer le trafic qui n'est traité par aucune des listes de filtres d'exemption. Pour chacune de ces règles, la méthode d'authentification employée est le protocole Kerberos version 5, le point de sortie du tunnel est défini à None (Aucun) et le type de connexion est All (Toutes). Le tableau ciaprès affiche les règles d'implémentation des quatre groupes d'isolation de la Woodgrove Bank : Table 5.8: Règles d'implémentation de base des groupes d'isolation de la Woodgrove Bank Nom de stratégie
Liste de filtres
IPSEC – Isolation Domain IPSec Policy Sousréseaux (1.0.041001.1600) (Stratégie IPSec de sécurisés de domaine d'isolation) Woodgrove Bank
123
Action de filtrage IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant)
IPSEC – Boundary Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de limite)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant)
IPSEC – No Fallback Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation sans basculement)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) (Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
IPSEC – Encryption Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de chiffrement)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
La Woodgrove Bank a choisi d'utiliser le protocole Kerberos version 5 comme unique protocole d'authentification. Elle n'utilise pas de clés prépartagées puisque la valeur de clé d'authentification peut être lue par des administrateurs locaux du Registre et par n'importe quels utilisateur authentifié et ordinateur sur le domaine. Elle n'a pas choisi non plus de certificats puisqu'elle ne dispose pas d'une infrastructure de clés publiques (PKI) déployée. Grâce au protocole Kerberos version 5, tous les ordinateurs associés à des domaines peuvent participer à l'infrastructure IPSec puisqu'ils peuvent authentifier et se procurer une stratégie. Les ordinateurs qui ne sont pas associés à des domaines ne peuvent pas facilement participer à l'environnement IPSec en raison de l'absence d'un mécanisme d'authentification et d'un système de distribution des stratégies. Si ces ordinateurs répondent aux critères des hôtes approuvés, vous pouvez configurer une stratégie IPSec locale à l'aide de l'authentification de certificats pour leur permettre de communiquer avec d'autres hôtes approuvés. Pour l'heure, la Woodgrove Bank traite les ordinateurs n'appartenant pas à des domaines en tant qu'ordinateurs non approuvés. Remarque : l'utilisation du protocole Kerberos version 5 pour l'authentification IKE n'empêche pas les ordinateurs qui n'appartiennent pas à des domaines de participer à l'environnement IPSec. Par exemple, si un système UNIX est correctement configuré pour l'utilisation d'Active Directory comme domaine Kerberos et si la structure IKE mise en place prend en charge l'authentification Kerberos, il peut alors participer au domaine d'isolation. Néanmoins, une configuration de ce type va audelà de la portée du présent document et n'a pas été testée par Microsoft. Fréquences d'interrogation Deux fréquences d'interrogation sont à prendre en compte : la fréquence d'interrogation de la stratégie de groupe et celle du service IPSec. Le paramètre par défaut de fréquence d'interrogation de modification de stratégie du service IPSec est de 180 minutes entre deux interrogations consécutives pour les changements des stratégies IPSec Active Directory. Ces interrogations vérifient uniquement les modifications apportées à la stratégie IPSec ; elles ne détectent pas les changements d'appartenance à un domaine ou une unité d'organisation ou bien l'affectation ou la suppression d'une stratégie IPSec dans un objet Stratégie de groupe. La détection des modifications d'appartenance à l'unité d'organisation d'un ordinateur et de l'affectation d'objets Stratégie de groupe s'effectue par interrogation du service Stratégie de groupe toutes les 90 minutes par défaut. La Woodgrove Bank a choisi de définir ces deux fréquences d'interrogation à 60 minutes afin que, si la nécessité d'une réponse de sécurité se présente, les stratégies puissent être mises à jour et déployées en une heure pour minimiser les risques. Cette fréquence d'interrogation accrue ajoute un trafic d'interrogation supplémentaire sous la forme de requêtes LDAP soumises par le client pour
124
vérifier les valeurs d'horodatage dans les stratégies IPSec. Même si cette augmentation ne se traduit pas par une charge significative dans le scénario de la Woodgrove Bank, elle peut être considérable dans des déploiements impliquant un grand nombre de clients. Paramètres d'échange de clés Les paramètres d'échange de clés suivants définissent le mode d'obtention des nouvelles clés et leur fréquence de renouvellement. Le terme « clé principale » désigne la clé secrète partagée Diffie Hellman générée en mode principal IKE. Le terme « clé de session » se rapporte aux clés générées en mode rapide IKE en vue d'être utilisées dans les algorithmes de chiffrement et d'intégrité IPSec. Les clés de session sont dérivées de la clé principale.
• PFS (Perfect Forward Secrecy). Il existe deux types de composants PFS dans IKE : la clé
principale PFS (soit le mode principal PFS) et la clé de session PFS (mode rapide PFS). Le mode principal PFS n'est pas conseillé car les fonctionnalités sont dupliquées par d'autres paramètres d'échange de clés pris en charge. Le mode principal PFS exige qu'IKE réauthentifie et négocie une nouvelle clé principale chaque fois qu'un mode rapide est exécuté pour actualiser les clés de session. Cette condition garantit à chaque fois qu'une clé de chiffrement doit être actualisée, les deux ordinateurs repartent de zéro avec une nouvelle négociation en mode rapide et en mode principal IKE. Cette protection supplémentaire implique une charge supplémentaire. La clé de session PFS génère une nouvelle clé principale en mode rapide (sans authentification en mode principal), puis extrait les nouvelles clés de session à partir de la nouvelle clé principale. Cette fonctionnalité garantit qu'un grand nombre de données (voire la totalité des données) de la communication ne sont pas uniquement protégées par une seule valeur de clé principale et qu'une quantité infime de données chiffrées serait dévoilée si un attaquant parvenait à découvrir la clé principale. La clé de session PFS est disponible sous la forme d'une case à cocher dans les méthodes de sécurité d'une action de filtrage. Utilisezla uniquement là où le trafic protégé IPSec est exposé à des risques d'attaques cryptographiques complexes dans la clé principale Diffie Hellman.
• Authentifier et générer une nouvelle clé toutes les <nombre> minutes. Cette valeur définit la
durée de vie de l'association de sécurité en mode principal IKE (fixée à 480 minutes par défaut). Elle contrôle la durée d'utilisation de la clé principale et de la relation d'approbation avant leur renégociation. La première connexion TCP/IP entre un client unique et l'hôte entraîne la création d'une nouvelle association de sécurité en mode principal IKE. Contrairement aux associations de sécurité logicielles, les associations de sécurité en mode principal ne sont pas supprimées de l'hôte après cinq minutes d'inactivité. Les associations de sécurité en mode principal exigent environ 5 kilooctets de mémoire chacune. En ajustant cette valeur, l'administrateur peut optimiser la charge processeur et la capacité mémoire requises par IKE. En réduisant la durée de vie, vous réduisez le nombre d'associations de sécurité en mode principal actives sur le serveur. Cela permet d'économiser de la mémoire et du temps de traitement IKE, en maintenant moins d'associations de sécurité. Néanmoins, vous pouvez augmenter la charge processeur requise pour renégocier les associations de sécurité en mode principal pour les clients qui communiquent fréquemment.
• Authentifier et générer une nouvelle clé toutes les <nombre> sessions. Ce paramètre contrôle le nombre maximal d'opérations en mode rapide IKE autorisées pendant la durée de vie d'une association de sécurité en mode principal, limitant ainsi le nombre de clés de session qu'il est possible de générer à partir de la même clé principale. Une fois cette limite atteinte, une nouvelle association de sécurité en mode principal IKE est négociée pour la création d'une nouvelle clé principale. Le paramètre par défaut est 0, ce qui signifie l'absence de limite. La clé principale est donc uniquement actualisée lorsque la durée de vie de l'association de sécurité en mode principal IKE arrive à expiration, à moins que vous n'utilisiez le mode rapide PFS. Pour obtenir le même comportement que le paramètre de la clé principale PFS, cette option est définie à 1.
125
La Woodgrove Bank a choisi de ne pas recourir à la clé principale PFS puisque aucune exigence de sécurité spécifique ne le justifie. De même, le service PFS en mode rapide IKE n'a pas été utilisé dans les actions de filtrage. La durée de vie des associations de sécurité en mode principal IKE est passée de 480 minutes à 180 minutes pour supprimer plus rapidement les associations de sécurité en mode principal sur les serveurs occupés dans tous les groupes d'isolation, à l'exception du groupe d'isolation de limite. Pour ce dernier, les administrateurs de la Woodgrove Bank ont réduit la durée de vie des associations de sécurité en mode principal IKE à 20 minutes pour diminuer la surface d'attaque exposée par les associations de sécurité en mode principal résidentes qui ont été négociées avec le groupe d'isolation de chiffrement. Bien que les hôtes du groupe d'isolation de limite ne puissent pas entamer de nouvelles négociations IKE avec les hôtes du groupe d'isolation de chiffrement, l'inverse peut se produire. Une fois l'association de sécurité en mode principal établie, un hôte du groupe d'isolation de limite peut l'utiliser pour négocier des associations de sécurité en mode rapide pour la protection du trafic entrant sur le système correspondant dans le groupe d'isolation de chiffrement jusqu'à ce que l'association de sécurité en mode principal soit supprimée. Vous pouvez minimiser les risques en forçant la suppression à intervalles plus réguliers des associations de sécurité en mode principal sur les serveurs du groupe de limite. Le nombre de sessions pour lesquelles vous pouvez utiliser la clé principale pour la création d'une clé de session est resté à 0 (paramètre par défaut). Méthodes d'échange de clés Les méthodes d'échange de clés permettent de contrôler les méthodes de sécurité employées lors de la négociation IKE en mode principal. Les options de configuration concernent l'intégrité (SHA1 et MD5), la confidentialité ou le chiffrement (3DES et DES) et la longueur des nombres premiers de base adoptés lors du processus d'échange de clés. Remarque : pour utiliser 3DES, les ordinateurs équipés de Windows 2000 doivent disposer du pack de chiffrement élevé ou de SP2 (ou ultérieur). La puissance de chiffrement des clés utilisées pour l'intégrité et le chiffrement de la négociation IKE ellemême et la protection des données IPSec dépend de la puissance du groupe DiffieHellman sur lequel les nombres premiers sont fondés. Trois options sont proposées pour le groupe DiffieHellman :
• Haute (3) – puissance de clé 2048 bits. Cette option correspond à la norme IETF RFC 3526 du
groupe DiffieHellman 14. Cette puissance de clé est indispensable pour que 3DES bénéficie d'un niveau de chiffrement maximal. Reportezvous à la norme IETF RFC 3526 pour plus d'informations.
• Moyenne (2) – puissance de clé 1024 bits. • Faible (1) – puissance de clé 768 bits. La configuration Haute concerne exclusivement les systèmes dotés de Windows XP SP2 et Windows Server 2003. La configuration Moyenne offre une interopérabilité avec Windows 2000 et Windows XP SP1. La configuration Faible est fournie pour une compatibilité descendante. Du fait de sa faiblesse relative, il est préférable d'éviter de l'utiliser. Le tableau cidessous répertorie par ordre de préférence les méthodes de sécurité d'échange de clés que la Woodgrove Bank a choisi d'implémenter : Tableau 5.9 : Méthodes de sécurité d'échange de clés par défaut Chiffrement
Intégrité
Groupe DiffieHellman
3DES
SHA1
Haute (3) 2048 bits
126
3DES
SHA1
Moyenne (2) 1024 bits
3DES
MD5
Moyenne (2) 1024 bits
Remarque : l'utilisation du groupe 2048 bits dans la stratégie IPSec exige que vous configuriez cette dernière à l'aide des outils de gestion de Windows Server 2003, notamment le composant logiciel enfichable MMC Gestion de stratégie IPSec ou l'utilitaire de ligne de commande Netsh IPSec. Vous pouvez affecter cette stratégie au domaine sur les platesformes Windows 2000, ce qui exclut l'utilisation de l'option 2048 bits. Versions des stratégies Il est probable que la conception des stratégies IPSec change plusieurs fois au cours de la planification initiale, des tests en laboratoire, des déploiements pilote et pendant l'utilisation opérationnelle. Si vous utilisez des scripts, des feuilles de calcul ou d'autres documents pour créer des stratégies IPSec, vous devez gérer ces fichiers à l'aide d'un système de contrôle des versions semblable à Microsoft Visual SourceSafe®. Il est difficile d'identifier les versions des stratégies IPSec dans Active Directory en examinant les attributs de la stratégie. Lors du dépannage, vous devrez être en mesure de déterminer la version de la stratégie IPSec active sur l'ordinateur. C'est pourquoi nous vous conseillons de stocker les informations sur les versions sous une forme quelconque à la fois dans le nom et dans les règles de la stratégie. Une méthode simple consiste à créer un ID de version fondé sur la formule suivante : <Major Change>.<Minor Change>..<Time:24 Hour> Par exemple, 1.0.041001.1600 correspond à la version 1.0 créée le 10/01/04 à 16 heures. Vous devez ensuite placer cet ID de version à la fin du nom créé pour la stratégie. Par exemple, IPSEC – Boundary IPSec Policy (1.0.041001.1600). Vous pouvez également l'ajouter au nom ou à la description des listes de filtres fréquemment sujettes à modifications. La stratégie de groupe extrait le nom de la stratégie IPSec et la place dans le Registre local sous HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPSec\GPTIPSECPolicy où elle est stockée sous forme de valeur de chaîne sous la clé DSIPSECPolicyName. Bien que le processus d'interrogation du service IPSec vérifie les changements intervenus dans tous les objets Stratégie affectés, il ne met pas à jour le nom de la stratégie affectée stockée par la stratégie de groupe. La stratégie de groupe ne met pas à jour le nom dans le Registre local tant que l'objet Stratégie de groupe n'a pas été modifié. L'équipe de recherche informatique de Microsoft a établi qu'une règle inutilisée au sein de la stratégie IPSec était un moyen efficace pour stocker les informations de version des stratégies. Par exemple, vous pouvez créer une liste de filtres contenant des adresses non valides et associée à une action de filtrage Autoriser, comme dans l'exemple suivant : Nom de la liste de filtres : stratégie IPSec ver 1.0.041001.1600 Description de la liste de filtres : stratégie IPSec ver 1.0.041001.1600 1.1.1.1 <> 1.1.1.2, ICMP, description = "stratégie IPSec ver ID 1.0.041001.1600"
127
Après avoir créé cette liste de filtres dans Active Directory, vous pouvez identifier le nom unique de l'objet de version de la liste de filtres à l'aide du composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory fonctionnant en mode avancé. Vous pouvez rechercher l'objet liste de filtres dans l'arborescence\System\IP Security et l'identifier grâce à sa description. Dès que vous connaissez le nom unique de l'objet de version, vous pouvez le comparer par programmation avec les objets IPSec stockés dans le Registre sous HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Cache pour déterminer s'il se trouve dans le cache. En recherchant le nom unique de l'objet de version dans le cache, vous pouvez comparer les noms des stratégies de l'objet stocké dans Active Directory et de l'objet stocké dans l'ordinateur local. Si les noms sont identiques, les stratégies de domaine et les stratégies locales sont synchronisées. Les noms et les descriptions de chaque liste de filtres sont également stockés dans le cache des stratégies IPSec, ce qui permet d'identifier et de savoir quelles versions de ces objets sont actuellement attribuées. Le service IPSec conserve en mémoire le texte descriptif de chaque filtre (et non la liste de filtres) afin que le composant logiciel enfichable MMC Moniteur IPSec et les outils de ligne de commande puissent accéder à ces informations. Un script peut permettre d'automatiser la vérification des versions des stratégies, notamment le script Detect_IPSec_Policy.vbs fourni à titre d'exemple dans le dossier Tools and Templates (outils et modèles) de cette solution. À mesure que vous modifiez les stratégies sur une période donnée, vous devez mettre à jour les noms de filtres correspondants afin qu'ils tiennent compte des modifications apportées.
Procédure d'application des stratégies IPSec à des ordinateurs individuels L'étape finale de l'activation d'IPSec consiste à déployer les stratégies sur les hôtes. Il existe deux méthodes de déploiement des stratégies. L'une consiste à appliquer directement les stratégies sur les ordinateurs hôtes individuels ; l'autre passe par l'utilisation des objets Stratégie de groupe et d'Active Directory. L'application des stratégies via Active Directory est abordée dans la section « Application des stratégies IPSec à l'aide d'objets Stratégie de groupe » plus loin dans ce chapitre. Deux méthodes vous permettent d'appliquer des stratégies IPSec sur des ordinateurs individuels : via le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec ou par le biais de la ligne de commande en exécutant l'outil Netsh (pour Windows Server 2003), Ipseccmd.exe (pour Windows XP) ou Ipsecpol.exe (pour Windows 2000). Le composant logiciel enfichable MMC fournit une interface utilisateur graphique qui permet à l'administrateur d'appliquer manuellement la stratégie ou d'importer une stratégie IPSec définie au préalable et exportée depuis un autre ordinateur. Outre la manipulation de la stratégie sur l'ordinateur local, le composant logiciel enfichable permet aux administrateurs de gérer une stratégie sur un ordinateur distant. Des informations détaillées sur les outils de ligne de commande sont disponibles à partir des ressources suivantes :
• Aide et support Windows Server 2003 pour Netsh • Documentation des outils de support Windows XP pour Ipseccmd.exe • Kit de ressources Windows 2000 Server pour Ipsecpol.exe
128
Vous pouvez vous procurer la dernière version du kit de ressources et des outils de support à partir du Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/search.aspx? Microsoft fournit un outil IPSeccmd mis à jour et d'autres outils de support pour Windows XP SP2. Reportezvous à l'article 838079 de la Base de connaissances Microsoft, « Windows XP Service Pack 2 Support Tools » (Outils de support du Service Pack 2 Windows XP), à l'adresse http://support.microsoft.com/?kbid=838079. Les informations détaillées sur l'utilisation de ces outils dépassent le cadre du présent guide. Les exemples donnés dans ce dernier concernent l'utilisation de l'outil Netsh sur des serveurs fonctionnant sous Windows Server 2003.
Application des stratégies IPSec à l'aide d'objets Stratégie de groupe La stratégie de groupe Active Directory sert de mécanisme de distribution et d'attribution des stratégies IPSec aux ordinateurs associés à des domaines. Pour répartir les stratégies via les mécanismes de distribution de la stratégie de groupe dans Active Directory, vous devez avant toute chose configurer les objets Stratégie de groupe qui seront utilisés pour appliquer les stratégies IPSec sur les ordinateurs hôtes. Remarque : bien que la section suivante aborde le chargement des stratégies IPSec directement dans Active Directory, vous devez partir du principe que les stratégies ont été créées et testées sur un système local, dans un laboratoire de test et dans le cadre de projets pilote à petite échelle avant d'être déployées au sein d'un environnement de production. Procédure de chargement des stratégies IPSec dans Active Directory La première tâche à effectuer pour l'implémentation des stratégies IPSec via Active Directory est de créer les listes de filtres, les actions de filtrage et les stratégies IPSec dans le service d'annuaire. Vous pouvez le faire à l'aide du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec ou par le biais d'un outil de ligne de commande tel que Netsh. Quel que soit l'outil que vous choisissez, vous devez effectuer les trois soustâches suivantes pour implémenter les stratégies IPSec :
1. Créer les listes de filtres et les filtres identifiés dans la section « Listes de filtres IPSec » de ce chapitre.
2. Créer les actions de filtrage identifiées dans la section « Actions de filtrage IPSec » de ce chapitre.
3. Créer les stratégies IPSec identifiées dans la section « Stratégies IPSec » de ce chapitre. Utilisation du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec Le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec est un outil d'interface graphique utilisateur à l'aide duquel les administrateurs peuvent créer, configurer et modifier des stratégies IPSec sur des ordinateurs locaux, des ordinateurs distants ou des domaines. La configuration des composants IPSec est un processus manuel qui implique de modifier directement les objets créés, dirigé par des assistants. Après avoir défini les stratégies IPSec localement ou dans Active Directory, l'administrateur peut les exporter (avec toutes les listes de filtres et les actions de filtrage) dans un fichier dont le nom se termine par une extension .ipsec. Vous pouvez copier ce fichier sur un autre support à titre de sauvegarde.
129
Si une sauvegarde des stratégies IPSec est déjà disponible, vous pouvez utiliser l'outil pour importer les stratégies sauvegardées dans Active Directory. Vous pouvez opter pour cette approche à des fins de récupération ou pour déplacer les fichiers de stratégies IPSec d'une forêt de test vers une forêt de production sans avoir à recréer chaque liste de filtres, action de filtrage et stratégie manuellement. Examinez avec soin la conception des stratégies récupérées à partir des copies de sauvegarde. Il est conseillé d'effectuer des tests afin d'évaluer l'impact de l'application des anciens paramètres dans l'environnement actuel. Un ancien fichier de sauvegarde peut contenir des paramètres de stratégie (notamment des listes de filtres ou des actions de filtrage) non valides et susceptibles de faire échouer toute communication s'ils ont été affectés aux membres actuels du domaine. Pour plus d'informations sur l'utilisation du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec, reportezvous à la rubrique « Définition des stratégies IPSec » du Centre d'aide et de support de Windows Server 2003. Utilisation de l'outil Netsh Vous pouvez faire appel à l'outil Netsh au lieu du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec pour configurer des stratégies IPSec dans un domaine Active Directory Windows Server 2003. L'exécution de cet outil de ligne de commande peut avoir lieu en mode interactif ou en mode de traitement par lot. Lorsqu'il fonctionne en mode interactif, Netsh exige que l'administrateur tape chaque commande dans l'invite de commandes Netsh. Avant créer les listes de filtres, les actions de filtrage et les stratégies IPSec, vous devez configurer l'outil pour qu'il pointe sur Active Directory. Pour que Netsh pointe sur Active Directory, tapez la commande suivante à l'invite Netsh : ipsec static set store location=domain L'administrateur peut ensuite entrer les listes de filtres, les filtres, les actions de filtrage et les stratégies IPSec manuellement via l'invite de commandes Netsh. Tout comme l'outil GUI, Netsh prend en charge l'exportation et l'importation des fichiers de stratégies IPSec pour les scénarios de sauvegarde et de récupération. L'exécution de Netsh en mode de traitement par lot nécessite la création d'un fichier script contenant les commandes Netsh. Ce fichier script doit contenir la commande permettant de cibler le domaine ainsi que toutes les commandes de configuration des listes de filtres, des filtres, des actions de filtrage et des stratégies IPSec. Vous pouvez ensuite créer les informations des stratégies IPSec dans Active Directory en démarrant l'outil Netsh, puis en exécutant le fichier script. La syntaxe de la ligne de commande pour le lancement de Netsh et l'exécution d'un fichier script se présente comme suit : netsh –f <scriptfile> Pour plus d'informations sur l'utilisation de Netsh, reportezvous à la rubrique « Netsh » de la section « Outils d'administration et de script » du Centre d'aide et de support de Windows Server 2003. Remarque : Netsh fonctionne uniquement avec des stratégies IPSec sur des ordinateurs exécutant Windows Server 2003. La manipulation depuis la ligne de commande des stratégies IPSec sur des ordinateurs exécutant Windows 2000 ou Windows XP exige respectivement l'outil Ipsecpol.exe ou Ipseccmd.exe. De plus, Netsh consigne une commande dump dans le contexte IPSec de l'outil. Bien qu'elle soit répertoriée dans l'aide, cette fonction n'a pas été implémentée. De plus, contrairement à l'outil GUI, Netsh ne prend pas en charge les connexions à distance.
130
Création d'objets Stratégie de groupe pour la distribution des stratégies IPSec Les objets Stratégie de groupe (GPO) sont stockés dans Active Directory et définissent un ensemble de paramètres à appliquer à un ordinateur. Les stratégies IPSec ne sont pas stockées directement dans les objets Stratégie de groupe. À la place, les objets Stratégie de groupe maintiennent une liaison DN LDAP avec la stratégie IPSec. Les stratégies IPSec sont stockées à l'emplacement cn=IP Security, cn=System, dc=<domain> dans Active Directory. Les objets Stratégie de groupe sont attribués aux sites, aux domaines ou aux unités d'organisation dans Active Directory. Les ordinateurs situés à ces emplacements ou dans ces conteneurs reçoivent la stratégie définie par l'objet Stratégie de groupe, sauf si d'autres paramètres l'empêchent. L'équipe de conception IPSec doit consulter l'équipe Active Directory afin de discuter de la possibilité d'utiliser les objets Stratégie de groupe existants pour fournir leurs stratégies IPSec. Si cette approche s'avère impossible ou exige une modification à grande échelle des méthodes de gestion, vous pouvez définir de nouveaux objets Stratégie de groupe pour chaque ensemble de stratégies IPSec à déployer. La solution décrite dans ce guide fait appel à de nouveaux objets Stratégie de groupe pour le déploiement des stratégies IPSec. Bien que vous puissiez créer les objets Stratégie de groupe via l'outil Utilisateurs et ordinateurs Active Directory ou l'outil Sites et services Active Directory, nous vous conseillons de les créer à l'aide de la console de gestion des stratégies de groupe (GPMC). La création d'une stratégie avec les outils Active Directory permet de lier automatiquement l'objet Stratégie de groupe à l'objet en cours d'exploration. En faisant appel à la console GPMC pour créer les objets Stratégie de groupe, l'administrateur peut s'assurer que les objets Stratégie de groupe sont créés dans Active Directory mais ne sont pas appliqués aux ordinateurs tant que chaque objet Stratégie de groupe n'est pas explicitement lié à un site, un domaine ou une unité d'organisation. La console GPMC est un utilitaire complémentaire destiné aux ordinateurs sous Windows XP Service Pack 1 (ou ultérieur) ou Windows Server 2003. Elle permet aux administrateurs de gérer la stratégie de groupe pour plusieurs domaines et sites dans une ou plusieurs forêts via une interface utilisateur simplifiée prenant en charge la fonctionnalité « glisserdéplacer ». Ses fonctions clés couvrent notamment la sauvegarde, la restauration, l'importation, la copie des objets Stratégie de groupe et la création de rapports les concernant. Ces opérations sont entièrement scriptables, ce qui permet aux administrateurs de personnaliser et d'automatiser la gestion. Notez que ces techniques de gestion des objets Stratégie de groupe s'appliquent à la gestion des objets de stratégie IPSec euxmêmes. Vous devez développer une stratégie de gestion afin de gérer la stratégie IPSec en coordination avec les objets Stratégie de groupe chargés d'attribuer les stratégies IPSec. Pour plus d'informations sur l'utilisation de la console GPMC, reportezvous au livre blanc « Administering Group Policy with the GPMC » (Administration de la stratégie de groupe à l'aide de la console GPMC) disponible sur le site Web de Microsoft à l'adresse www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx. Vous pouvez télécharger la console de gestion des stratégies de groupe avec Service Pack 1 partir de www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C248CBD4B359272 DD3CBFC81887&displaylang=en.
à
Grâce à la console GPMC, l'administrateur peut créer un objet Stratégie de groupe pour chaque stratégie IPSec en procédant comme suit : Pour créer un nouvel objet Stratégie de groupe
1. Développez l'arborescence du domaine, cliquez avec le bouton droit sur le conteneur Objets de stratégie de groupe, puis sélectionnez Nouveau.
131
2. Tapez le nom d'un nouvel objet Stratégie de groupe, puis cliquez sur OK. Tout comme pour les actions de filtrage et les stratégies IPSec, vous devez développer une norme d'attribution de noms pour les objets Stratégie de groupe en incluant le numéro de version de la stratégie car les informations de version des objets Active Directory ne sont pas faciles à obtenir. L'ajout d'un numéro de version dans le nom de la stratégie permet aux administrateurs d'identifier rapidement la stratégie actuellement en vigueur. Microsoft recommande l'utilisation de la même convention d'attribution de noms que celle décrite plus haut dans ce chapitre pour les actions de filtrage et les stratégies IPSec. Par exemple, un objet Stratégie de groupe intitulé « GPO IPSec de domaine d'isolation ver 1.0.040601.1600 » désigne la version 1.0 créée le 06/01/04 à 16 heures. Une fois l'objet Stratégie de groupe créé, l'administrateur doit le configurer pour qu'il utilise la stratégie IPSec appropriée. Pour attribuer une stratégie IPSec à un objet Stratégie de groupe
1. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe, puis sélectionnez Modifier pour lancer l'Éditeur de stratégies de groupe.
2. Les stratégies IPSec qu'il est possible d'attribuer sont disponibles sous Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies de sécurité IP dans Active Directory.
3. Pour attribuer une stratégie IPSec, cliquez avec le bouton droit sur le nom de la stratégie dans le volet droit, puis sélectionnez Attribuer. • Une seule stratégie IPSec peut être attribuée à un objet Stratégie de groupe.
4. Pour enregistrer les modifications de l'objet Stratégie de groupe, fermez l'Éditeur de stratégies de groupe. La stratégie IPSec est appliquée aux ordinateurs hôtes via les paramètres de configuration ordinateur de l'objet Stratégie de groupe. Si vous utilisez l'objet Stratégie de groupe uniquement en vue d'appliquer des stratégies IPSec, nous vous conseillons de le configurer en désactivant les paramètres de configuration utilisateur. En désactivant ces paramètres, vous pourrez passer outre l'évaluation des options de configuration utilisateur et raccourcirez ainsi le temps de traitement de l'objet Stratégie de groupe. Pour désactiver la configuration utilisateur dans l'objet Stratégie de groupe
1. Ouvrez l'outil GPMC. 2. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe dans la console GPMC. 3. Sélectionnez État GPO, puis Paramètres de configuration utilisateurs désactivés. Si les paramètres de configuration utilisateur sont modifiés dans l'objet Stratégie de groupe par la suite, l'administrateur devra réactiver le traitement de ces paramètres afin qu'ils s'appliquent. Groupes de sécurité de domaine Les groupes de sécurité de domaine remplissent deux fonctions. La première est d'identifier les comptes d'ordinateurs de domaine membres d'un groupe d'isolation ; la deuxième est d'identifier les comptes d'ordinateurs de domaine membres d'un groupe d'accès réseau. Tous les membres d'un groupe d'isolation doivent recevoir la même stratégie IPSec. Par conséquent, vous pouvez créer des groupes de sécurité de domaine pour l'application et la gestion des stratégies 132
IPSec au lieu d'utiliser des conteneurs d'unités d'organisation pour contrôler l'attribution des stratégies. Les groupes universels constituent la meilleure option de contrôle de l'attribution des stratégies puisque vous pouvez les appliquer à la forêt tout entière et réduire ainsi le nombre de groupes à gérer. En revanche, si ces groupes universels ne sont pas disponibles, vous pouvez utiliser les groupes globaux de domaine à la place. Les groupes locaux de domaine sont utilisés pour les groupes d'accès réseau abordés plus loin dans ce guide. Le tableau ciaprès répertorie les groupes qui ont été créés pour le scénario de la Woodgrove Bank afin de gérer l'environnement IPSec et contrôler l'application des stratégies. Tableau 5.10 : Noms des groupes IPSec Nom de groupe
Description
No IPSec
Groupe universel de comptes d'ordinateurs ne participant pas à l'environnement IPSec Il s'agit généralement de comptes d'ordinateurs issus de l'infrastructure.
CG_IsolationDomain_computers Groupe universel de comptes d'ordinateurs membres du domaine d'isolation. CG_BoundaryIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation de limite et, par conséquent, autorisés à communiquer avec des systèmes non approuvés.
CG_NoFallbackIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation sans basculement non autorisés à établir des communications non authentifiées sortantes.
CG_EncryptionIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation de chiffrement et qui, par conséquent, exigent le chiffrement de leurs communications.
Outre les groupes énumérés, d'autres groupes ont peutêtre été créés et exploités en vue de restreindre l'application des stratégies lors de la phase de déploiement initiale. Au moment de déployer IPSec, il n'est pas recommandé de se contenter de créer les objets Stratégie de groupe et les stratégies IPSec et de les attribuer en même temps à tous les ordinateurs du domaine. Vous pouvez utiliser un groupe de sécurité de domaine pour contrôler avec précision les ordinateurs capables de lire les objets Stratégie de groupe et, donc, de recevoir la stratégie IPSec correspondante. Les objets Stratégie de groupe offrant la stratégie IPSec peuvent tous être attribués à l'ensemble du domaine. Le processus de déploiement doit soigneusement examiner si la stratégie IPSec a été correctement conçue, attribuée et récupérée sur tous les nœuds sensés négocier IPSec. La conception de la stratégie du groupe de limite est généralement employée pour autoriser les communications nonIPSec entrantes et sortantes sur des ordinateurs qui n'ont pas encore reçu leur stratégie IPSec. Distribution des stratégies IPSec via Active Directory Trois méthodes, seules ou combinées, vous permettent de contrôler les objets Stratégie de groupe que vous pouvez appliquer à des ordinateurs dans Active Directory.
• Utilisation d'unités d'organisation avec des objets Stratégie de groupe liés. • Intégration de comptes d'ordinateurs dans des groupes de sécurité référencés dans des listes de contrôle d'accès appliquées aux objets Stratégie de groupe.
133
• Utilisation de filtres WMI (Windows Management Instrumentation) dans les objets Stratégie de groupe.
Le contrôle de l'application des objets Stratégie de groupe par le biais d'unités d'organisation avec objets Stratégie de groupe liés est la méthode d'application de stratégies la plus répandue dans Active Directory. Elle vous permet de créer des unités d'organisation dans Active Directory et de lier des objets Stratégie de groupe à des sites, des domaines ou des unités d'organisation. La stratégie est attribuée aux ordinateurs en fonction de leur emplacement dans Active Directory. Si vous déplacez un ordinateur d'une unité d'organisation vers une autre, la stratégie liée à la deuxième unité d'organisation entre effectivement en vigueur lorsque la stratégie de groupe détecte des modifications lors de l'interrogation. La deuxième méthode utilise les paramètres de sécurité des objets Stratégie de groupe euxmêmes. Un groupe est ajouté à la liste de contrôle d'accès de l'objet Stratégie de groupe dans Active Directory. Des autorisations de lecture et d'application sont attribuées au groupe dans la stratégie à appliquer aux ordinateurs du groupe. De plus, d'autres autorisations spécifiques sont refusées au groupe dans les stratégies non applicables aux ordinateurs de ce groupe. La stratégie est ensuite liée au niveau du domaine. La troisième méthode fait appel aux filtres WMI de la stratégie pour contrôler de manière dynamique l'étendue d'application de la stratégie. Un filtre SQL WMI est créé et lié à la stratégie. Si la condition interrogée est vraie (true), la stratégie est appliquée ; sinon, elle est ignorée. Les ordinateurs dotés de Windows 2000 ignorent le filtrage WMI et appliquent la stratégie. Les requêtes WMI peuvent ralentir le traitement des objets Stratégie de groupe et doivent être utilisées uniquement si elles sont nécessaires. La Woodgrove Bank a opté pour l'utilisation des groupes de sécurité pour contrôler l'application des stratégies plutôt que de les lier directement à une unité d'organisation. Si elle a choisi cette approche, c'est pour faciliter l'intégration des stratégies IPSec dans l'environnement et éviter de les imposer à plusieurs emplacements ou de forcer le déplacement d'ordinateurs d'une unité d'organisation vers une autre pour obtenir la stratégie appropriée. À moins que les listes de contrôle d'accès de l'objet Stratégie de groupe soient extrêmement longues, cette méthode n'ajoute aucune charge par rapport à la première méthode puisque, dans les deux cas, les listes de contrôle d'accès doivent faire l'objet d'une évaluation. La Woodgrove Bank n'a pas opté pour le filtrage WMI en raison des systèmes Windows 2000 qu'abrite l'environnement. Le tableau cidessous indique la configuration finale des listes de contrôle d'accès de la stratégie de groupe. Notez que les listes de contrôle d'accès dans les objets de stratégie IPSec euxmêmes ne sont pas utilisées et sont déconseillées. Tableau 5.11 : Autorisations GPO de la Woodgrove Bank Nom de l’objet Stratégie de groupe
Nom du groupe de sécurité
Autorisations attribuées
IPSEC – Isolation Domain Policy (Stratégie de domaine d'isolation)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Isolation Domain Policy (Stratégie de domaine d'isolation)
CG_IsolationDomain_computers
Autoriser Lecture et Appliquer la stratégie de groupe
IPSEC – Boundary Group Policy (Stratégie de groupe de limite)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Boundary Group Policy
CG_BoundaryIG_computers
Autoriser Lecture et
134
(Stratégie de groupe de limite)
Appliquer la stratégie de groupe
IPSEC – No Fallback Isolation Group Policy (Stratégie de groupe d'isolation sans basculement)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – No Fallback Isolation Group Policy (Stratégie de groupe d'isolation sans basculement)
CG_NoFallbackIG_computers
Autoriser Lecture et Appliquer la stratégie de groupe
IPSEC – Encryption Isolation Group Policy (Stratégie de groupe d'isolation de chiffrement)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Encryption Isolation Group Policy (Stratégie de groupe d'isolation de chiffrement)
CG_EncryptionIG_computers
Autoriser Lecture et Appliquer la stratégie de groupe
Domaine d'isolation La Woodgrove Bank a choisi de lier la stratégie Domaine d'isolation au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_IsolationDomain_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. La stratégie Domaine d'isolation Domain est la stratégie que tous les ordinateurs de l'organisation utilisent en tant que stratégie de sécurité IPSec par défaut. Par conséquent, le groupe Ordinateurs du domaine se voit accorder un droit d'accès en lecture à la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Lors de la phase de déploiement initiale, le groupe Ordinateurs du domaine a été supprimé de la liste de contrôle d'accès et un autre groupe de sécurité provisoire a été utilisé pour contrôler et déterminer les destinataires de cette stratégie. Cette approche a permis un déploiement par étapes de cette stratégie. Groupe d'isolation de limite La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de limite au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_BoundaryIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Si, pour des besoins commerciaux, un système doit accepter des communications provenant de systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du système au groupe de sécurité CG_BoundaryIG_computers. Groupe d'isolation sans basculement La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation sans basculement au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_NoFallbackIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie.
135
Si, pour des besoins commerciaux, un système ne doit pas être en mesure d'établir des communications avec des systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du système au groupe CG_NoFallbackIG_computers. Groupe d'isolation de chiffrement La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de chiffrement au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_EncryptionIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Si, pour des besoins commerciaux, un système doit communiquer uniquement avec du trafic chiffré, vous pouvez ajouter le compte d'ordinateur du système au groupe CG_EncryptionIG_computers.
Autorisation de l'accès en entrée à un groupe d'isolation Selon les exigences de la Woodgrove Bank, l'accès réseau en entrée aux serveurs du groupe d'isolation de chiffrement peut uniquement être autorisé à un sousensemble d'hôtes approuvés. Pour respecter ces exigences, les groupes d'accès réseau suivants ont été définis (voir le tableau 4.8 du chapitre 4) :
• ANAG_EncryptedResourceAccess_Users • ANAG_EncryptedResourceAccess_Computers • DNAG_EncryptedResourceAccess_Computers Lorsqu'un client démarre IKE sur un serveur de chiffrement, IKE doit se procurer un ticket de service Kerberos dans lequel figure l'identificateur du groupe de sécurité du domaine indiquant si l'ordinateur client est membre du groupe ANAG et/ou peutêtre du groupe DNAG. Si tous les ordinateurs du groupe d'isolation de chiffrement sont membres du même domaine, vous pouvez alors créer ces groupes d'accès réseau en tant que groupes de sécurité locaux du domaine. Si les ordinateurs du groupe d'isolation de chiffrement sont membres de domaines approuvés séparés, vous pouvez alors utiliser un ensemble de groupes globaux de domaine pour les groupes d'accès réseau ou bien créer des groupes locaux dans chaque domaine. Le scénario imaginé pour la Woodgrove Bank fait intervenir un seul et unique domaine ; il fait donc appel à des groupes locaux du domaine pour ces groupes d'accès réseau. L'objet Stratégie de groupe supplémentaire suivant a été créé afin de définir des droits de type Accéder à cet ordinateur à partir du réseau permettant d'implémenter l'autorisation entrante :
• EncryptionIG GPO d'autorisation d'entrée sur le réseau Le groupe CG_EncryptionIG_Computers se voit accorder les droits Lecture et Appliquer pour cet objet Stratégie de groupe. Le droit d'accès en lecture est retiré au groupe Utilisateurs authentifiés ; cet objet Stratégie de groupe est alors uniquement appliqué aux ordinateurs membres du groupe d'isolation de chiffrement. Comme l'illustre le tableau 4.8 du chapitre 4, le compte d'ordinateur IPSSTXP05 du domaine client autorisé est ajouté au groupe d'accès réseau ANAG_EncryptedResourceAccess_Computers. Les comptes IPSSQLDFS01 et IPSSQLDFS02 des serveurs de chiffrement sont également ajoutés.
136
Néanmoins, le même résultat aurait été obtenu plus aisément en faisant appel au groupe CG_EncryptionIG_computers pour gérer une liste plus volumineuse. Les comptes doivent, d'une manière ou d'une autre, bénéficier du droit Accéder à cet ordinateur à partir du réseau, que ce soit du fait de l'appartenance au groupe ANAG, par intégration directe de leur groupe CG_EncryptionIG_computers ou par une liste explicite des comptes d'ordinateurs ajoutée au droit. Dans le cas contraire, les comptes ne seront pas en mesure d'établir des connexions protégées par IPSec entre eux, condition qu'exigent leurs applications. Pour simuler un environnement de domaine à grande échelle, les groupes ANAG sont les seuls groupes qui autorisent l'accès en entrée dans le scénario de la Woodgrove Bank. Du fait que le groupe Utilisateurs authentifiés inclut tous les ordinateurs du domaine, le droit Accéder à cet ordinateur à partir du réseau doit lui être retiré. Les utilisateurs autorisés du domaine doivent désormais bénéficier d'une autorisation explicite qu'il est possible de définir à l'aide du groupe intégré Utilisateurs du domaine. Cependant, la Woodgrove Bank cherchait à tirer parti de la possibilité de définir des restrictions d'accès réseau entrant pour les utilisateurs et les ordinateurs. Elle a donc créé un groupe de sécurité local de domaine intitulé « ANAG_EncryptedResourceAccess_Users » en y intégrant les comptes des utilisateurs d'applications autorisés (par exemple, User7) ainsi que le groupe des administrateurs locaux et les groupes des administrateurs de domaine. Ces restrictions d'accès réseau définies au niveau de l'utilisateur interviennent lors des demandes d'authentification des protocoles de niveau supérieur (notamment RPC, SMB et SQL) après qu'une connectivité IPSec ESP 3DES a été établie avec succès. Les groupes de sécurité de domaine suivants ont été créés en vue de définir des droits de connexion réseau pour les serveurs de chiffrement. Ils résident dans l'objet Stratégie de groupe sous Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies locales, Attribution des droits utilisateur, autorisation Accéder à cet ordinateur à partir du réseau :
• ANAG_EncryptedResourceAccess_Computers • ANAG_EncryptedResourceAccess_Users Le groupe suivant est configuré pour le même objet Stratégie de groupe, Interdire l'accès à cet ordinateur à partir du réseau :
• DNAG_EncryptedResourceAccess_Computers En supposant qu'il ne parvienne pas à ouvrir directement une session sur les serveurs de chiffrement, l'utilisateur User7 doit utiliser l'ordinateur client IPSSTXP05 pour accéder au serveur IPSSQLDFS 01 ou au serveur IPSSQLDFS02. L'ordinateur IPSSTXP05 doit disposer d'un compte d'ordinateur de domaine valide et d'une stratégie IPSec active capable de soumettre une négociation IKE sur les adresses IP des serveurs de chiffrement. Notez que les utilisateurs et les ordinateurs restants du domaine sont exclus de tout accès puisque l'autorisation Accéder à cet ordinateur à partir du réseau leur est intentionnellement retirée. Seuls les ordinateurs du groupe d'isolation de limite se voient explicitement refuser l'accès, par le biais du groupe DNAG. C'est une mesure de défense renforcée contre toutes les modifications d'appartenance à un groupe susceptibles d'être apportées à l'avenir et d'inclure un compte d'ordinateur de limite dans un groupe ANAG. Un paramètre de refus explicite remplace toutes les formes d'autorisation.
Autres considérations relatives à IPSec Outre la définition des stratégies IPSec, d'autres éléments indispensables à une implémentation réussie d'IPSec sont à prendre en compte. La feuille de calcul Business_Requirements.xls (dossier Tools and Templates) fournit des informations détaillées sur les contraintes liées à l'utilisation d'IPSec.
137
Exemptions par défaut Dans Windows 2000 et Windows XP, les types de trafic suivants sont, par défaut, exemptés du filtrage :
• Diffusion • Multidiffusion • Protocole d'authentification Kerberos • IKE (Internet Key Exchange) • RSVP (Resource Reservation Protocol) Dans les systèmes d'exploitation de la famille Windows Server 2003, le trafic de diffusion, multidiffusion, RVSP et d'authentification Kerberos n'est, par défaut, pas exempt du filtrage (seul le trafic IKE l'est). Les paquets de diffusion et de multidiffusion sont ignorés s'ils correspondent à un filtre muni d'une action de filtrage visant à négocier la sécurité. Par défaut, Windows Server 2003 offre une prise en charge limitée pour le filtrage du trafic de diffusion et de multidiffusion. Un filtre doté d'une adresse source de type N'importe quelle adresse IP s'appliquera aux adresses de diffusion et de multidiffusion. Un filtre doté d'une adresse source de type N'importe quelle adresse IP et d'une adresse de destination N'importe quelle adresse IP s'appliquera à des adresses de multidiffusion entrantes et sortantes. Vous pouvez utiliser ce type de filtre pour bloquer l'ensemble du trafic. En revanche, les filtres unidirectionnels à utiliser pour bloquer ou autoriser un trafic de diffusion ou de multidiffusion spécifique ne sont pas pris en charge. La modification du comportement d'exemption par défaut de l'implémentation d'IPSec dans la famille Windows Server 2003 doit vous inciter à vérifier le comportement des stratégies IPSec élaborées pour Windows 2000 ou Windows XP et à déterminer si des filtres explicites doivent être configurés pour autoriser des types de trafic spécifiques. Pour rétablir le comportement par défaut de Windows 2000 et Windows XP pour les stratégies IPSec, vous pouvez utiliser la commande Netsh ou modifier le Registre. Pour rétablir le comportement de filtrage par défaut de Windows 2000 et Windows XP dans le pilote IPSec à l'aide de la commande Netsh
1. Tapez la commande suivante à l'invite Netsh, puis appuyez sur Entrée : netsh ipsec dynamic set config ipsecexempt 0
2. Redémarrez l’ordinateur. Pour exempter tout le trafic de diffusion, multidiffusion et IKE du filtrage IPSec en modifiant le Registre
1. Donnez au paramètre HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\IPSEC\NoDefaultExempt DWORD du Registre la valeur 1. La clé NoDefaultExempt n'existe pas par défaut et doit être créée.
2. Redémarrez l’ordinateur.
NATTraversal (NATT) En raison du mode de fonctionnement des traducteurs d'adresses réseau, les clients peuvent être confrontés à des résultats inattendus avec des serveurs Windows 2000 Server ou
138
Windows Server 2003 placés derrière un traducteur d'adresses réseau utilisant la technologie NATT IPSec. Par défaut, Windows XP SP2 ne prend plus en charge les associations de sécurité NATT IPSec avec ces serveurs. L'objectif de cette modification est d'éviter un risque de sécurité prévisible dans une situation où les événements consécutifs suivants se produisent :
1. Un traducteur d'adresses réseau est configuré afin de faire correspondre le trafic IKE et le trafic NATT IPSec sur un serveur placé sur un réseau configuré NAT (Serveur 1).
2. Un client étranger au réseau NAT (Client 1) utilise NATT avec IPSec pour établir des associations de sécurité bidirectionnelles avec le Serveur 1.
3. Un client appartenant au réseau NAT (Client 2) utilise NATT avec IPSec pour établir des associations de sécurité bidirectionnelles avec le Client 1.
4. Une condition contraint le Client 1 à rétablir les associations de sécurité avec le Client 2 en raison des paramètres du traducteur d'adresses réseau qui fait correspondre le trafic IKE et le trafic IPSec NATT sur le Serveur 1. Cette condition peut provoquer un routage incorrect du trafic de négociation des associations de sécurité IPSec (transmis par le Client 1et destiné au Client 2) vers le Serveur 1. Bien que cette situation soit peu probable, le comportement par défaut sur des ordinateurs Windows XP SP2 empêche toute association de sécurité IPSec NATT avec des serveurs situés derrière un traducteur d'adresses réseau afin de garantir que cette situation ne se produise jamais. Si des communications IPSec sur NAT sont requises, nous vous conseillons d'utiliser des adresses IP publiques pour tous les serveurs qu'il est possible de connecter directement depuis Internet. Si cette configuration n'est pas possible, vous pouvez alors modifier le comportement par défaut de Windows XP SP2 pour activer les associations de sécurité IPSec NATT avec les serveurs situés derrière un traducteur d'adresses réseau. Pour créer et configurer la valeur de Registre AssumeUDPEncapsulationContextOnSendRule
1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK. 2. Recherchez, puis cliquez sur la sousclé suivante du Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD. 4. Dans la zone Nouvelle valeur #1, tapez ce qui suit, puis appuyez sur Entrée : AssumeUDPEncapsulationContextOnSendRule Remarque : le nom de cette valeur tient compte de la casse.
5. Cliquez avec le bouton droit sur AssumeUDPEncapsulationContextOnSendRule, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez l'une des valeurs suivantes : • 0 (par défaut). Une valeur 0 (zéro) configure Windows de sorte qu'il ne puisse pas établir d'associations de sécurité avec des serveurs situés derrière des traducteurs d'adresses réseau. • 1. Une valeur 1 configure Windows de sorte qu'il puisse établir des associations de sécurité avec des serveurs situés derrière des traducteurs d'adresses réseau.
139
• 2. Une valeur 2 configure Windows de sorte qu'il puisse établir des associations de sécurité lorsque le serveur et l'ordinateur client Windows XP SP2 sont situés derrière des traducteurs d'adresses réseau. Remarque : la configuration que représente la valeur 2 existe dans la version d'origine de Windows XP et dans Windows XP Service Pack 1 (SP1).
7. Cliquez sur OK, puis fermez l'Éditeur du Registre. 8. Redémarrez l’ordinateur. Une fois AssumeUDPEncapsulationContextOnSendRule défini à une valeur 1 ou 2, Windows XP SP2 peut se connecter à un serveur situé derrière un traducteur d'adresses réseau. Les serveurs Windows Server 2003 doivent également être mis à jour pour fonctionner comme il se doit avec IPSec lorsqu'ils sont placés derrière un dispositif NAT. Consultez l'URL cidessous pour savoir comment vous procurer Windows Server 2003 Service Pack 1 : http://go.microsoft.com/fwlink/?LinkId=41652 Remarque : pour plus d'informations, reportezvous à l'article 885348 de la Base de connaissances Microsoft, « IPSec NATT is not recommended for Windows Server 2003 computers that are behind network address translators », (IPSec NATT est déconseillé pour les ordinateurs Windows Server 2003 situés derrière des traducteurs d'adresses réseau) disponible à l'adresse http://support.microsoft.com/default.aspx?scid=kb;enus;885348. Cet article présente les risques de sécurité liés à l'utilisation de ce scénario. Chaque client doit comparer les avantages de l'utilisation d'IPSec dans ce scénario avec les risques de sécurité que cela implique. Bien que Microsoft ne recommande pas le scénario en raison des risques de sécurité qui y sont associés, ce scénario est pris en charge avec la configuration décrite dans cette solution. Pour que les connexions NAT entrantes fonctionnent correctement, la découverte PMTU doit être activée et ellemême fonctionner. Certaines sources, notamment le Windows XP Hardening Guide et le Windows Server 2003 Hardening Guide (Guides de renforcement de la sécurité de Windows XP et de Windows Server 2003) recommandent de désactiver la découverte PMTU et fournissent, dans certains cas, des modèles de stratégies permettant de désactiver cette fonctionnalité. Pour activer la découverte du PMTU (Path MTU)
1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK. 2. Recherchez, puis cliquez sur la sousclé suivante du Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\tcpip\parameters
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD. 4. Dans la zone Nouvelle valeur #1, tapez EnablePMTUDiscovery, puis appuyez sur Entrée. 5. Cliquez avec le bouton droit sur EnablePMTUDiscovery, puis cliquez sur Modifier. 6. Dans la zone Données de la valeur, tapez 1. 7. Cliquez sur OK, puis fermez l'Éditeur du Registre. 8. Redémarrez l’ordinateur. De plus, les hôtes équipés de Windows 2000 et intervenant dans un scénario NATT nécessitent l'installation du correctif fourni avec l'article 818043 de la Base de connaissances Microsoft, « L2TP/IPSec NATT update for Windows XP and Windows 2000 » (Mise à jour NATT L2TP/IPSec pour Windows XP et Windows 2000) pour fonctionner correctement.
140
Pour plus d'informations, reportezvous aux articles suivants de la Base de connaissances :
• 885407, « The default behavior of IPSec NAT traversal (NATT) is changed in Windows XP Service Pack 2 » (Le comportement par défaut d'IPSec NATT (NATTraversal) est modifié dans Service Pack 2 Windows XP), sur le site Web du support Microsoft à l'adresse http://support.microsoft.com/kb/885407.
• 818043, « L2TP/IPSec NATT update for Windows XP and Windows 2000
» (Mise à jour NAT T L2TP/IPSec pour Windows XP et Windows 2000), sur le site Web du support Microsoft à l'adresse http://support.microsoft.com/kb/818043.
IPSec et Parefeu Windows Le Parefeu Windows sur des ordinateurs Windows XP SP2 offre une protection supplémentaire contre les attaques en bloquant le trafic entrant non sollicité. Sous Windows XP SP2, IPSec utilise le parefeu Windows. Lorsqu'une stratégie IPSec est active, les composants IPSec de Windows XP SP2 sollicitent le Parefeu Windows afin qu'il ouvre les ports UDP 500 et 4500 pour autoriser le trafic IKE. Une autre fonctionnalité prise en charge avec IPSec est la possibilité de préciser via la stratégie de groupe que tout le trafic protégé par IPSec ignore le traitement du Parefeu Windows. Pour plus d'informations, reportezvous à l'annexe A du livre blanc, « Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 » (Déploiement des paramètres du Parefeu Windows pour Microsoft Windows XP Service Pack 2) disponible à l'adresse http://download.microsoft.com/download/ 6/8/a/68a81446cd734a6186658a67781ac4e8/wf_xpsp2.doc.
IPSec et Parefeu de connexion Internet (ICF) Pour les ordinateurs Windows XP non équipés du SP2, le Parefeu de connexion Internet (ICF) répondra mieux aux exigences de sécurité qu'impose le filtrage du trafic. Le Parefeu de connexion Internet offre en effet une fonction de filtrage et permet de bloquer le trafic de diffusion et de multidiffusion entrant dans Windows XP SP1. En revanche, il ne reconnaît pas le trafic protégé par IPSec au format AH ou ESP en mode transport ou en mode tunnel. Du fait qu'IPSec opère dans la couche réseau sous le Parefeu de connexion Internet et qu'IKE intervient audessus du Parefeu de connexion Internet, vous devez définir une autorisation statique (port UDP 500) pour le trafic entrant. Si IPSec bloque le trafic, le journal des paquets ignorés par le Parefeu de connexion Internet ne contiendra pas les paquets ignorés par IPSec.
Résumé Ce chapitre contient les informations requises pour créer et déployer des stratégies IPSec à partir de la conception des groupes d'isolation créée au chapitre 4. Ces informations ont été divisées en sept tâches élémentaires :
• Identification et création de listes de filtres • Identification et création d'actions de filtrage • Identification et création de règles • Identification et création de stratégies IPSec • Définition d'un mécanisme de distribution des stratégies IPSec • Définition d'une méthode de déploiement des stratégies IPSec
141
• Définition d'autorisations pour le contrôle de l'accès entrant par configuration des droits de connexion réseau de la stratégie de groupe
Ces tâches complètent les phases de conception et de planification de la solution d'isolation de serveurs et de domaines. La prochaine phase du projet consiste à déployer un environnement test ou pilote afin de valider la conception. Microsoft a procédé à cette vérification dans ses laboratoires de test et utilisé le scénario de la Woodgrove Bank en tant que pilote. Si vous souhaitez recréer cet environnement ou étudier les phases de déploiement, l'annexe C du présent guide contient des instructions détaillées relatives au processus de déploiement adopté dans les laboratoires de Microsoft pour valider la conception du scénario.
Informations complémentaires Cette section propose des liens vers d'autres informations relatives aux technologies mentionnées dans ce chapitre. Informations générales sur IPSec
• La page d'accueil IPSec sur le site Web de Microsoft : www.microsoft.com/ipsec • La page Page IPSec for Windows 2000
(IPSec pour Windows 2000) sur le site Web de Microsoft fournit une grande variété d'informations relatives à IPSec sous Windows 2000 : www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp.
• La page IPSec
de la section Windows Server 2003 du site Web de Microsoft fournit une grande variété d'informations relatives à IPSec sous Windows Server 2003 : www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx.
• Le chapitre Deploying IPSec
(Déploiement d'IPSec) du Windows Server 2003 Deployment Kit (Kit de déploiement de Windows Server 2003) : www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/enus/DNSBJ_IPS_OVERVIEW.asp.
Informations complémentaires
• La page Windows Server 2003 Group Policy
(Stratégie de groupe dans Windows Server 2003) sur le site Web de Microsoft offre une grande variété d'informations sur la gestion des systèmes Windows à l'aide de la stratégie de groupe dans Active Directory : www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx.
• L'article paru en octobre 2004 dans The Cable Guy, « Problems with Using Network Address
Translators » (Problèmes liés à l'utilisation de traducteurs d'adresses réseau), apporte des informations supplémentaires sur les problèmes spécifiques liés à NAT et IPSec. Cet article est disponible sur le site Web de Microsoft à l'adresse suivante : www.microsoft.com/technet/community/columns/cableguy/cg1004.mspx.
142
Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines Dernière mise à jour le 16022005 Ce chapitre fournit des conseils destinés à faciliter la gestion d'une solution d'isolation de serveurs et de domaines déployée efficacement dans un environnement de production. Il est important que l'équipe du support technique comprenne que la solution d'isolation apporte une couche de sécurité supplémentaire, et qu'il faut plus qu'une simple connexion réseau et une adresse IP pour qu'un hôte réussisse à se connecter à une ressource. De même, les personnes chargées des stratégies IPSec et de la stratégie de groupe doivent avoir conscience qu'une seule option mal définie peut nuire aux performances des hôtes auxquels s'appliquent ces stratégies. C'est pourquoi il convient de mettre en place un ensemble de procédures et de processus de gestion correctement documentés et communiqués, qui seront utilisés par les équipes du support après la mise en service de la solution. Les informations fournies dans ce chapitre sont destinées à faciliter l'élaboration de ces processus de gestion de la solution. Il est conseillé de personnaliser autant que possible ces informations afin de refléter les besoins de votre propre environnement. La réussite de la gestion d'une solution d'isolation de serveurs et de domaines repose sur vos capacités à anticiper.
Connaissances préalables requises pour ce chapitre Avant d'utiliser les informations fournies dans ce chapitre, vous devez être familiarisé avec les concepts utilisés dans Microsoft® Operations Framework (MOF) et les concepts IPSec. Vous devez également posséder des connaissances sur les éléments suivants de Windows® 2000 Server (ou version ultérieure) :
• opérations et maintenance de base sur Microsoft Windows Server™ 2003, y compris l'utilisation d'outils tels que l'Observateur d'événements, la Gestion de l'ordinateur et NTBackup ;
• service d'annuaire Active Directory®, y compris la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et autres objets Active Directory, et utilisation de la stratégie de groupe ;
• concepts de sécurité du système Windows (utilisateurs, groupes, audit, listes de contrôle d'accès), utilisation des modèles de sécurité, application des modèles de sécurité à l'aide d'une stratégie de groupe ou d'un outil de ligne de commande ;
• concepts clés de la mise en réseau, notamment ceux relatifs à IPSec et au protocole TCP/IP ; • environnement Windows Scripting Host et langage Microsoft Visual Basic® Scripting Edition
(VBScript) afin d'exploiter au mieux les scripts fournis (toutefois, ces connaissances ne sont pas essentielles).
Avant de poursuivre la lecture de ce chapitre, vous devez lire le reste de ce guide et bien comprendre l'architecture et la conception de la solution.
143
Gestion des modifications L'un des objectifs clés du processus de gestion des modifications est de garantir que toutes les parties concernées par une modification imminente ont conscience de l'impact de cette dernière et le comprennent. Dans la mesure où la plupart des systèmes sont étroitement liés, toute modification apportée à un composant d'un système est susceptible d'avoir un impact important sur un autre. Pour réduire ou éliminer les effets négatifs potentiels, la fonction de gestion des modifications tente d'identifier tous les systèmes et processus affectés avant le déploiement de la modification. En règle générale, l'environnement cible (ou géré) est l'environnement de production, mais il convient également d'inclure les environnements clés d'intégration, de test et intermédiaires. Toutes les modifications apportées à un environnement IPSec doivent suivre le processus de gestion des modifications MOF standard suivant :
1. Demande de modification. Initiation formelle d'une modification par la soumission d'une requête de modification (RFC).
2. Classification de la modification. Affectation d'une priorité et d'une catégorie à la modification, en utilisant comme critères son urgence et son impact sur l'infrastructure ou les utilisateurs. Cette classification conditionne la vitesse et la voie de mise en œuvre de la modification.
3. Autorisation de la modification. Prise en considération de la modification, ainsi que son approbation ou sa désapprobation par le responsable des modifications et le comité d'approbation des modifications (CAB), qui comprend des représentants commerciaux et informatiques.
4. Développement de la modification. Planification et développement de la modification, processus dont la portée peut varier énormément et qui inclut des révisions à des étapes clés intermédiaires.
5. Diffusion de la modification. Diffusion et déploiement de la modification dans l'environnement de production.
6. Révision de la modification. Processus postimplémentation qui analyse si la modification a répondu aux objectifs fixés et qui détermine s'il convient de conserver la modification ou de l'annuler. La section suivante décrit les procédures de développement de modification adaptées à certaines modifications clés que vous serez probablement amené à effectuer régulièrement dans votre environnement IPSec. Chaque procédure de développement de modification est accompagnée d'une procédure de diffusion, expliquant comment la modification doit être déployée en production.
Modification de la stratégie IPSec Il est important de comprendre dans quelle mesure les modifications apportées à la stratégie IPSec affecteront les communications. Comme pour le déploiement initial, la première préoccupation concerne la chronologie des modifications, car cette dernière a des conséquences sur la capacité à implémenter une modification et sur le délai d'annulation de la modification. Délais d'application de la stratégie Lorsque l'attribution d'une stratégie IPSec dans un objet Stratégie de groupe est remplacée par une nouvelle stratégie IPSec, certains délais peuvent se produire. Il s'agit notamment du délai de réplication Active Directory de l'attribut Stratégie de groupe contenant l'attribution dans le domaine, et du délai d'interrogation des clients de la Stratégie de groupe membres du domaine requis pour 144
détecter la modification au niveau de l'objet Stratégie de groupe. Ces délais peuvent durer moins d'une minute pour un petit site, et plusieurs heures pour l'ensemble d'une entreprise. Microsoft vous recommande de tester et de documenter ces délais (minimum, maximum et moyen) pour votre propre environnement afin que, lorsqu'une modification est introduite, le temps requis pour le premier impact et la durée totale du déploiement puissent être prévus. Lorsque le contenu d'une stratégie IPSec déjà attribuée est modifié, les mêmes délais se produisent. Il faut s'attendre notamment à un délai de réplication Active Directory des objets de la stratégie IPSec, ainsi qu'à un délai d'interrogation du service de stratégie IPSec sur les ordinateurs membres. Il est possible de créer une condition dans laquelle la réplication de l'attribution de la stratégie dans l'objet Stratégie de groupe se produit avant la réplication de la stratégie IPSec ; cela induirait chez les clients un comportement identique à celui engendré par l'attribution d'une stratégie IPSec basée sur un domaine (sans possibilité de récupérer cette stratégie). Dans ce cas, les hôtes Windows 2000 et Windows XP ne parviendraient tout simplement pas à appliquer la stratégie basée sur un domaine. De même, ils n'appliqueraient aucune stratégie locale éventuellement attribuée. Pour prendre en charge les délais de réplication Active Directory de manière appropriée, veillez d'abord à créer tous les objets (objet Stratégie de groupe, stratégie IPSec, etc.), puis procédez à l'attribution de la stratégie IPSec dans l'objet Stratégie de groupe. Modifications affectant la connectivité IPSec Plusieurs éléments peuvent affecter la connectivité au sein des stratégies et des groupes qui constituent une solution IPSec. Cette section fournit des informations sur la manière dont des modifications courantes peuvent affecter la connectivité IPSec dans le cadre de la modification d'une stratégie de serveur avec des clients ne possédant pas toujours la dernière mise à jour. Si une modification provoque un échec du mode IKE (Internet Key Exchange) principal ou rapide, le trafic est interrompu dès le début de l'inactivité des associations de sécurité IPSec ou à la fin de leur durée de vie en octets ou en secondes. Cette présentation traite de l'impact qu'ont la plupart des modifications sur les fonctionnalités client serveur IPSec. Elle n'est pas uniquement basée sur les modèles de stratégie IPSec de Woodgrove Bank. Ici, les clients peuvent avoir une stratégie proche de celle du modèle de Woodgrove Bank (impliquant des filtres côté clients pour initier IKE sur le serveur), ou ils peuvent utiliser uniquement la règle de réponse par défaut (non utilisée dans le modèle de Woodgrove Bank). Modifications en mode principal La modification d'une méthode d'authentification ou d'une méthode de sécurité de mode principal entraîne la suppression des modes principaux existants par l'IKE, sans affecter les associations de sécurité IPSec de mode rapide établies. Les nouvelles associations de sécurité de mode principal sont générées lorsque la régénération de clé de mode rapide suivante se produit. En règle générale, la modification de la stratégie de serveur n'affecte pas la capacité des clients existants à générer une nouvelle clé de mode principal. Néanmoins, certaines modifications côté serveur peuvent provoquer l'échec de la négociation en mode principal IKE avec les clients, notamment :
• Mise en place d'une nouvelle méthode d'authentification (certificats uniquement) sans inclure les anciennes méthodes d'authentification que le client peut utiliser.
• Passage à 3DES/SHA1/DH1 ou DH2 comme méthode de sécurité de mode principal alors que les clients ont été configurés uniquement pour utiliser DES/SHA1/DH1.
145
• Activation de la confidentialité de transmission parfaite (PFS) de mode principal sans mettre à jour la stratégie du client et du serveur afin que les deux utilisent la PFS de mode principal.
• Activation de la confidentialité de transmission parfaite (PFS) de mode rapide sans mettre à jour la stratégie du client et du serveur afin que les deux utilisent la PFS de mode rapide.
Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer une nouvelle clé pour les associations de sécurité de mode principal :
• Intervalle d'interrogation pour les modifications de stratégie (car il ne s'agit pas d'un paramètre IKE de mode principal)
• Clés de session utilisant la même clé principale (par exemple, nombre de modes rapides IKE par mode principal)
• Ajout d'une nouvelle méthode de sécurité non connue des clients • Modification des paramètres avancés d'échange de clés de la stratégie IPSec pour les paramètres de durée de vie Authentifier et générer une nouvelle clé pour l'association de sécurité de mode principal IKE
Modifications en mode rapide Toute modification d'une action de filtrage étant utilisée pour une association de sécurité IPSec provoque la suppression des associations de sécurité IPSec existantes établies avec ces paramètres de stratégie. Ainsi, en présence de trafic, le système tente d'établir un nouveau mode rapide. Une partie du trafic peut être perdue au cours de ce processus de modification, mais les connexions TCP doivent être rétablies. Cependant, pour les transferts de données à haute vitesse, la suppression immédiate des associations de sécurité IPSec provoque le rejet du trafic sortant jusqu'à l'établissement du nouveau mode rapide. Par exemple, une salve de paquets d'un flux de données vidéo, suite à laquelle TCP n'a pu être rétabli, provoquera une réinitialisation de la connexion pour l'application vidéo. Les modifications de stratégie de serveur affectant la capacité des clients IPSec actifs à générer une nouvelle clé de mode rapide sont les suivantes :
• Passage d'un filtre plus général à un filtre plus spécifique. Par exemple, lorsqu'un serveur démarre avec un filtre de type tout le trafic, puis le supprime, en laissant un filtre TCP uniquement. Pour éviter les problèmes, laissez le filtre plus générique en place lorsque vous ajoutez le filtre plus spécifique. Par exemple, si les clients ont une stratégie de réponse par défaut et qu'un serveur a une stratégie passant de « tout le trafic » à « TCP uniquement », le filtre plus spécifique sera soumis au trafic sortant sur le serveur, qui établira une nouvelle association de sécurité IPSec pour TCP uniquement lorsque les clients auront une réponse par défaut. Le filtre « tout le trafic » appliqué à tous les clients finira par être supprimé (après deux heures) et pourra ensuite être retiré en toute sécurité de la stratégie du serveur. Si le serveur ajoute un filtre plus spécifique avec une action d'autorisation, ce trafic sera immédiatement autorisé et pourra être rejeté par le client ayant un filtre plus général de réponse par défaut IPSec. Exemple : un filtre d'exemption ICMP (Internet Control Message Protocol) est ajouté à un serveur, mais les clients sont déjà sécurisés pour tout le trafic vers le serveur. Dans ce cas, le client va sécuriser son trafic ICMP sortant, recevoir une réponse ICMP en texte clair en retour et rejeter le paquet, car le filtre de réponse par défaut IPSec indique que tout le trafic doit être sécurisé. Cet exemple n'affecterait pas le trafic autre que le trafic ICMP entre le serveur et le client, et il représente un comportement attendu qui provoque toujours une perte de trafic ICMP après la demande de sécurisation de l'ensemble du trafic avec le client par le serveur. Cela peut, ou non, affecter considérablement les performances du service.
146
• Modifications de méthodes de sécurité ou de types d'encapsulation incompatibles. Par
exemple, passage du mode de transport 3DES/SHA1 pour ESP uniquement au mode de transport 3DES/MD5 pour ESP uniquement. Vous pouvez éviter les échecs de négociation en mode rapide IKE provoqués par ce type de modification en incluant les anciennes méthodes de sécurité ou les anciens types d'encapsulation en tant que dernier choix dans la nouvelle méthode de sécurité. Une fois que toutes les associations de sécurité IPSec utilisent la nouvelle méthode d'encapsulation, vous pouvez supprimer l'ancienne méthode au bas de la liste des méthodes de sécurité.
• Désactivation totale d'une règle dont les clients avaient besoin pour établir le mode
principal ou le mode rapide IKE. En mode rapide, le filtre est supprimé afin qu'un filtre différent (ou aucun) contrôle la négociation en mode principal ou en mode rapide IKE.
• Modification totale d'une action de filtrage du type Négocier la sécurité au type Autoriser ou Bloquer. Le trafic étant explicitement autorisé ou bloqué ne nécessite pas la régénération de clé dans la mesure où ce trafic ne transitera plus sur une voie de communication protégée par IPSec.
• Désactivation de la case à cocher Communiquer en texte clair. Cette action conserve la
connectivité des clients connectés pour toute la durée de l'association de sécurité logicielle. Une fois l'association de sécurité arrivée à expiration ou inactive, une augmentation du trafic sortant du serveur conduit l'IKE à tenter une nouvelle négociation en mode principal et à reconnaître les nouveaux paramètres afin d'éviter toute redirection. Les clients qui ne peuvent pas répondre positivement à la négociation IKE ne parviendront pas à se connecter. Cela peut être le but recherché.
• Désactivation de la case à cocher Autoriser une connexion non sécurisée. Cette action
provoque la déconnexion des clients s'ils ne disposent pas de filtres IPSec pour déclencher une initiation en mode principal IKE sortant. Les clients disposant d'une règle de réponse par défaut restent connectés jusqu'à ce que leur filtre dynamique de réponse par défaut devienne inactif après deux heures d'absence de trafic vers le serveur, après quoi ils ne sont plus à même de se reconnecter.
Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer une nouvelle clé de mode rapide :
• L'ajout d'un filtre ne correspondant pas au trafic se trouvant déjà dans les associations de sécurité IPSec actuelles n'affecte pas ce trafic. Par exemple, si des filtres de type autorisation sont ajoutés à la stratégie d'un serveur pour l'adresse IP d'un nouveau contrôleur de domaine.
• Modification de la durée de vie de l'association de sécurité IPSec de l'action de filtrage, en octets ou en temps.
• Modification de l'action de filtrage du type Autoriser à Négocier la sécurité. Si les clients peuvent répondre, ils seront toujours en mesure de négocier une connexion sécurisée pour ce trafic.
Procédures de modification de stratégie IPSec Les sections suivantes décrivent les procédures permettant de modifier les stratégies IPSec délivrées à l'aide des objets Stratégie de groupe. Bien que les étapes présentées pour chaque tâche utilisent le composant logiciel enfichable de la console MMC (Microsoft Management Console) Stratégie de sécurité IP, chacune de ces tâches peut également être accomplie à l'aide de l'outil de ligne de commande Netsh sur un système Windows Server 2003. Microsoft recommande la plateforme Windows Server 2003 comme station de gestion des stratégies car elle offre les meilleures fonctionnalités pour les scripts et la surveillance. L'importation et l'exportation des stratégies IPSec Windows sont destinées à la sauvegarde et à la restauration. La fonction d'exportation copie tous les objets de stratégie IPSec à l'emplacement de 147
stockage pour garantir que tous les objets associés sont capturés dans la sauvegarde. L'exportation est la méthode recommandée pour déplacer l'ensemble de la stratégie de domaine actuelle sur un support de stockage local à des fins de test. En raison du risque d'erreur, veillez à bien supprimer tous les objets inutiles (y compris les stratégies, les listes de filtres et les actions de filtrage) contenus sur le support de stockage local avant d'utiliser la fonction d'exportation. Microsoft déconseille l'utilisation d'un magasin local exporté pour l'importation dans le domaine car des anciennes versions d'objet peuvent écraser des versions de domaine plus récentes et rompre ainsi les liens entre les objets. Les scripts de lignes de commande sont la méthode recommandée pour créer une stratégie IPSec et pour réaliser des ajouts importants aux objets existants, comme l'ajout de filtres à une liste de filtres existants, par exemple. En règle générale, ces modifications importantes dans une stratégie IPSec doivent être effectuées via la création d'une nouvelle version de stratégie IPSec. Une fois la stratégie créée, vous pouvez utiliser des scripts ou le composant logiciel enfichable MMC Gestion des stratégies IPSec pour apporter des modifications. Après la création et la mise en service de la stratégie IPSec, le composant logiciel enfichable MMC Gestion des stratégies IPSec est recommandé pour effectuer des modifications mineures. Dans la mesure où l'outil de ligne de commande Ipsecpol.exe de Windows 2000 prend uniquement en charge la création d'une stratégie, le composant logiciel enfichable MMC peut être utilisé pour gérer les modifications dans Windows 2000 Active Directory. L'ajout d'un nouvel objet du même nom n'est pas autorisé dans les commandes d'ajout de Netsh. Pour cette raison, et parce que les scripts sont souvent exécutés de trop nombreuses fois, les scripts Netsh doivent inclure les étapes initiales permettant de supprimer les objets de stratégie existant déjà avant que de nouveaux objets soient ajoutés. La suppression d'un objet qui n'existe pas a pour effet de renvoyer un message d'erreur inattendue, qui n'interrompt pas l'exécution du script. La suppression d'une stratégie de domaine IPSec déjà attribuée à un objet Stratégie de groupe rendra le lien de l'objet en question non valide. L'objet Stratégie de groupe doit être édité pour réattribuer la dernière version de la stratégie IPSec. Remarque : bien que la section suivante explique comment modifier des stratégies IPSec directement dans Active Directory, nous partons du principe que toutes les modifications ont été testées sur un système local ou un environnement de test avant d'être déployées dans un environnement de production. Modification de l'attribution de la stratégie IPSec pour un groupe d'isolation Pour modifier la stratégie IPSec attribuée à un groupe d'isolation, vous pouvez remplacer la stratégie IPSec actuelle par une nouvelle. La console GPMC (Group Policy Management Console) permet de modifier la stratégie IPSec qu'un objet Stratégie de groupe particulier distribue. Après avoir identifié la nouvelle stratégie IPSec et l'objet Stratégie de groupe qui distribue la stratégie actuelle, procédez comme suit. Pour modifier la stratégie IPSec attribuée à un groupe d'isolation
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Nom d'objet de stratégie de groupe, puis cliquez sur Modifier. 148
5. Développez Configuration ordinateur, développez Paramètres Windows, développez
Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory (nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Attribuer.
7. Vérifiez que la stratégie est attribuée, puis fermez l'éditeur d'objets GPO, puis la console GPMC.
Modification d'une stratégie IPSec existante dans le domaine Compte tenu que les fonctionnalités IPSec ont été étendues dans Windows XP, puis à nouveau dans Windows Server 2003, le format de stockage des stratégies IPSec a été modifié pour inclure les paramètres correspondants à ces améliorations. Veillez à ne pas utiliser un composant logiciel enfichable MMC Gestion des stratégies IPSec d'une version antérieure pour afficher ou modifier une stratégie intégrant ces fonctionnalités ajoutées. Si vous cliquez sur OK lors de l'affichage d'un composant de stratégie, les paramètres existants sont écrasés par les paramètres enregistrés dans la mémoire actuelle, même si vous n'avez effectué aucune modification. Des mises à jour ont été ajoutées aux Service Packs de Windows XP et à Windows 2000 Service Pack 4 (SP4) pour détecter les nouvelles versions de stratégie afin d'éviter ce problème potentiel. Néanmoins, le composant logiciel enfichable MMC ne parvient pas à enregistrer les modifications, comme si l'accès en modification était refusé ; il utilise les messages d'erreur qui existaient à la sortie du produit. De même, si l'utilisateur exécutant le composant logiciel enfichable MMC ne dispose que de droits de lecture sur les objets de stratégie IPSec, les modifications sont perdues lorsqu'une erreur d'accès refusé apparaît. Utilisez le mode lecture seule du composant logiciel enfichable MMC Gestion des stratégies IPSec dans Windows Server 2003 chaque fois que vous ne souhaitez pas effectuer de modification. Enfin, le composant logiciel enfichable MMC ne permet pas d'entrer un ID d'utilisateur et un mot de passe différents lors de la connexion à un ordinateur ou domaine distant. L'utilisateur doit être connecté sur le Bureau en tant qu'utilisateur disposant d'autorisations appropriées pour effectuer les modifications souhaitées. Modification de la liste de filtres d'une règle existante Il est parfois nécessaire de modifier la liste de filtres d'une règle existante pour ajouter, supprimer ou modifier un élément de filtre. Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour effectuer cette modification. N'oubliez pas que l'ordre d'un filtre dans une liste de filtres n'a aucune incidence sur l'ordre dans lequel le pilote IPSec traitera les paquets. Les filtres de toutes les listes de filtres dans toutes les règles d'une stratégie IPSec sont ordonnés à l'aide d'un algorithme interne de pondération. Pour effectuer une modification, vous devez vérifier manuellement que vous n'êtes pas en train de créer un filtre dupliqué pour un autre filtre utilisé dans la stratégie IPSec. Dans le cadre du processus de test de la modification, la stratégie doit être attribuée localement sur un ordinateur afin que la sortie du composant logiciel enfichable MMC Moniteur IPSec ou de la ligne de commande puisse être utilisée pour afficher l'ordre exact des filtres et détecter les filtres dupliqués. Pour ajouter un ordinateur à une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
149
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter. 7. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP. 8. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique. 9. Dans la zone de texte Adresse IP, tapez l'adresse IP spécifique. 10. Vérifiez que la case à cocher Miroir est activée. 11. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre. 12. Cliquez sur OK, puis de nouveau sur OK. 13. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Remarque : une fois le nouveau système ajouté à une liste de filtres d'exemptions, le compte d'ordinateur doit être ajouté au groupe de sécurité Sans IPSec. Pour modifier une entrée d'ordinateur dans une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 6. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>, puis cliquez sur Modifier.
7. Dans la zone de texte Adresse IP, remplacez l'entrée par la nouvelle adresse IP. 8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Pour supprimer une entrée dans une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>. 6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Supprimer. 150
7. Cliquez sur Oui pour supprimer l'élément de filtre. 8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Remarque : une fois le système supprimé de la liste de filtres d'exemptions, le compte d'ordinateur doit être retiré du groupe de sécurité Sans IPSec. Modification de l'action de filtrage d'une règle existante Chaque règle d'une stratégie IPSec dispose d'une action de filtrage correspondante qui est exécutée lorsque les conditions de la règle sont satisfaites. Bien qu'il soit possible d'attribuer une nouvelle stratégie IPSec aux ordinateurs qui présentent la nouvelle combinaison de règle et d'action de filtrage, il est plus judicieux de modifier l'action de filtrage associée à une règle de stratégie IPSec qui existe déjà. Par exemple, si une stratégie IPSec personnalisée existe pour un ensemble d'ordinateurs, il est plus logique de modifier l'action de filtrage attribuée à la règle plutôt que de générer une nouvelle stratégie IPSec. Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour configurer une règle dans une stratégie IPSec pour utiliser une nouvelle action de filtrage. Pour modifier l'action de filtrage d'une règle existante
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Propriétés.
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier. 5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur <nouvelle action de filtrage> pour sélectionner le bouton adjacent.
6. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 7. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Modification de la méthode d'authentification d'une règle existante La méthode d'authentification par défaut des stratégies IPSec utilise le protocole Kerberos, version 5. Avec le temps, il peut s'avérer nécessaire de modifier une méthode d'authentification associée à une règle existante. Par exemple, une infrastructure de clés publiques (PKI) peut être déployée pour permettre l'utilisation de certificats pour authentifier les ordinateurs. Bien que des informations différentes soient requises pour chaque méthode d'authentification pouvant être choisie, les étapes générales pour l'ajout d'une méthode d'authentification sont semblables. Par exemple, pour utiliser une clé prépartagée, vous devez identifier la clé, et, pour utiliser les certificats, l'autorité de certification doit être connue. Pour ajouter une nouvelle option d'authentification à une règle IPSec existante, procédez comme suit. Pour ajouter une option à une règle existante
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine.
151
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Propriétés.
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier. 5. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter. 6. Cliquez sur le bouton correspondant à la nouvelle option d'authentification souhaitée, puis configurez les options requises.
7. Cliquez sur OK. 8. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons Monter et Descendre pour créer l'ordre de préférence des méthodes d'authentification. Remarque : pour supprimer une méthode d'authentification, cliquez dessus dans la liste Ordre de préférence des méthodes d'authentification, puis cliquez sur Supprimer.
9. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 10. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Ajout d'une nouvelle règle à une stratégie IPSec existante L'ajout de nouvelles règles à des stratégies IPSec existantes permet de restreindre ou d'élargir davantage les communications entre les ordinateurs de l'environnement. Par exemple, si un système prenant en charge IPSec doit communiquer avec des systèmes placés dans un groupe d'isolation particulier mais ne reçoit pas sa stratégie de l'infrastructure IPSec, vous pouvez effectuer des modifications sur le groupe d'isolation afin d'autoriser les communications. Dans cet exemple, il faut appliquer à l'hôte IPSec non géré une stratégie autorisant les communications. En outre, il faut choisir une méthode d'authentification partagée (soit des certificats, soit une clé prépartagée). Une nouvelle règle peut alors être créée dans la stratégie IPSec existante afin de permettre au groupe d'isolation d'autoriser le trafic une fois que la méthode d'authentification a été acceptée. Les étapes nécessaires sont les suivantes : créer une nouvelle liste de filtres dans le répertoire, associer la nouvelle liste de filtres à la stratégie existante, puis configurer les mécanismes d'authentification afin qu'ils incluent la nouvelle méthode d'authentification choisie. Pour créer une nouvelle liste de filtres afin de permettre tout le trafic vers un ordinateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, cliquez sur Ajouter. 5. Dans la zone de texte Nom, tapez un nom de liste de filtres approprié. 6. Dans la zone de texte Description, tapez une description appropriée pour la liste de filtres.
152
7. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 8. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter. 9. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP. 10. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique. 11. Dans la zone de texte Adresse IP, tapez l'adresse IP de l'ordinateur spécifique. 12. Vérifiez que la case à cocher Miroir est activée. Remarque : par défaut, cette procédure crée une règle examinant tout le trafic provenant d'une adresse IP quelconque sur une adresse IP spécifique. Si la correspondance doit être effectuée sur un port ou une base de protocole spécifique, des opérations de configuration supplémentaires doivent être effectuées sous l'onglet Protocole.
13. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre. 14. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. Pour modifier une stratégie IPSec afin d'utiliser une nouvelle liste de filtres et une action de filtrage
1. Cliquez avec le bouton droit de la souris sur, puis cliquez sur Propriétés.
2. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 3. Cliquez sur Ajouter. 4. Sous l'onglet Liste de filtres IP, dans la liste Filtres IP, cliquez sur la case d'option Nouvelle liste de filtres IP.
5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur la case d'option Action de filtrage.
6. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter. 7. Cliquez sur le bouton correspondant à la méthode d'authentification souhaitée, puis configurez les options requises. Remarque : la méthode d'authentification choisie doit être négociable par l'initiateur et le répondeur (clé prépartagée ou certificats, par exemple). Si nécessaire, supprimez le protocole de la liste en le sélectionnant, puis en cliquant sur le bouton Supprimer.
8. Cliquez sur OK. 9. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons Monter et Descendre pour sélectionner l'ordre de préférence des méthodes d'authentification si la liste en contient plusieurs.
10. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 11. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.
Déplacement d'hôtes entre différents groupes d'isolation Pour plusieurs raisons, les hôtes doivent régulièrement être déplacés d'un groupe à un autre. Il est important de comprendre les implications des modifications apportées aux appartenances de groupe
153
sur les communications. Les sections suivantes décrivent les étapes requises pour ajouter ou supprimer des hôtes dans les groupes. Ajout ou suppression d'un hôte dans une liste d'exemptions Vous pouvez ajouter ou supprimer un hôte dans la liste d'exemptions en modifiant les listes de filtres d'exemptions IPSec et le groupe de sécurité Sans IPSec. Pour ce faire, suivez les étapes décrites dans la section « Modification de la liste de filtres d'une règle existante », plus haut dans ce chapitre. La liste de filtres d'exemption, le nom de l'hôte, ainsi que son adresse IP doivent être connus pour réaliser cette tâche.
Ajout ou suppression d'hôtes et d'utilisateurs dans des groupes existants Lorsque vous ajoutez ou supprimez un hôte dans un groupe d'accès réseau (NAG), les étapes sont spécifiques au rôle joué par l'hôte dans le groupe. Si l'hôte fait office d'initiateur, son ajout ou sa suppression dans le groupe d'accès réseau associé suffit. En revanche, s'il fait office de répondeur, la stratégie qui contrôle la mise à jour du droit « Accéder à cet ordinateur à partir du réseau » doit être appliquée ou supprimée. Si le système fait office d'initiateur et de répondeur, les deux étapes doivent être exécutées. Ajout ou suppression d'initiateurs dans un groupe d'accès réseau existant Vous pouvez ajouter ou supprimer un initiateur dans un groupe d'accès réseau en utilisant les outils standards de gestion de groupes pour modifier le groupe de sécurité associé. Pour modifier un groupe d'accès réseau lié à un ordinateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Propriétés.
4. Pour ajouter un ordinateur au groupe : • Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. • Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez sur OK. • Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom_ordinateur>, puis cliquez sur OK. • Cliquez sur OK.
5. Pour supprimer un ordinateur du groupe : • • • •
Cliquez sur l’onglet Membres. Dans la liste Membres, cliquez sur <nom_ordinateur>, puis cliquez sur Supprimer. Cliquez sur Oui pour supprimer le compte <nom_ordinateur>. Cliquez sur OK.
Remarque : il y aura un délai entre le moment où le compte de l'hôte sera ajouté au groupe et le moment où l'hôte pourra accéder à la ressource restreinte. Ce délai est dû aux délais de réplication et
154
au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la ressource restreinte (si le ticket est mis en cache).
Ajout ou suppression d'utilisateurs dans un groupe d'accès réseau existant Bien que les groupes d'isolation aient été créés pour limiter l'initiation par des hôtes de communications vers la ressource restreinte, ils peuvent également être utilisés pour permettre de restreindre l'accès à cette ressource par des utilisateurs. Si aucune exigence n'est spécifiée pour restreindre l'accès à une ressource d'une manière similaire à un groupe d'accès réseau, le groupe Utilisateurs du domaine se voit accorder le droit « Accéder à cet ordinateur à partir du réseau » sur les répondeurs. Si une exigence est spécifiée pour restreindre l'accès à une ressource, un groupe Utilisateurs NAG est créé. Vous pouvez ajouter ou supprimer un utilisateur avec accès restreint dans un groupe Utilisateurs NAG en recourant aux outils standards de gestion de groupes pour modifier le groupe de sécurité associé. Cette procédure est uniquement requise si un groupe Utilisateurs NAG a été créé et attribué au groupe d'accès réseau ; si le groupe Utilisateurs du domaine est en cours d'utilisation, cette procédure n'est pas nécessaire. Pour modifier un groupe Utilisateurs NAG lié à un utilisateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Propriétés.
4. Pour ajouter un utilisateur au groupe d'accès réseau : • Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. • Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de l'utilisateur>, puis cliquez sur OK.
• Cliquez sur OK. 5. Pour supprimer un utilisateur du groupe d'accès réseau : • Cliquez sur l’onglet Membres. • Dans la liste Membres, cliquez sur le <nom de l'utilisateur> spécifique, puis cliquez sur Supprimer. • Cliquez sur Oui pour supprimer le compte <nom de l'utilisateur>. • Cliquez sur OK.
Remarque : il y aura un délai entre le moment où le compte de l'utilisateur sera ajouté au groupe et le moment où l'utilisateur pourra accéder à la ressource restreinte. Ce délai est dû aux délais de réplication et au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la ressource restreinte (si le ticket est mis en cache).
155
Ajout ou suppression de répondeurs dans un groupe d'accès réseau existant Pour supprimer un hôte répondeur d'un groupe d'accès réseau, vous pouvez supprimer l'attribution de l'objet Stratégie de groupe qui configure le droit « Accéder à cet ordinateur à partir du réseau » sur le répondeur. L'application de l'objet Stratégie de groupe peut être contrôlée par n'importe quel moyen standard permettant de garantir l'application des stratégies avec Active Directory. Néanmoins, l'approche utilisée dans ce guide a attribué l'objet Stratégie de groupe à une unité d'organisation qui a été créée pour contenir les comptes d'ordinateurs de domaine des répondeurs. Le simple déplacement du compte d'ordinateur en dehors de l'unité d'organisation des répondeurs l'empêchera de recevoir l'objet Stratégie de groupe attribué, et l'accès ne sera plus restreint. L'ordinateur reviendra ainsi à la stratégie de domaine d'isolation. (Si le compte d'ordinateur appartenait aussi à un groupe de sécurité de domaine local composé de groupes d'accès réseau, il doit également être supprimé de ce groupe.) Vous devez vous assurer que les hôtes appartenant à plusieurs groupes d'accès réseau sont toujours capables de communiquer avec les autres groupes d'accès réseau après avoir été supprimés de l'un de ces groupes.
Ajout de nouveaux groupes d'accès réseau La création d'un groupe d'accès réseau est un processus relativement simple. Vous devez tout d'abord créer un groupe de domaine local pour contrôler l'accès à la ressource, ainsi qu'un objet Stratégie de groupe pour mettre à jour le droit « Accéder à cet ordinateur à partir du réseau » sur les hôtes qui agissent en tant que serveurs dans le groupe d'accès réseau. Vous devez ensuite appliquer cet objet Stratégie de groupe aux serveurs, et identifier les hôtes qui appartiennent au groupe. Seuls les initiateurs doivent être membres du groupe d'accès réseau. En d'autres termes, si deux serveurs se trouvent dans le même groupe d'isolation et ne communiqueront jamais ensemble, ils n'ont pas besoin d'être ajoutés au groupe d'accès réseau pour leur groupe d'isolation. En revanche, si ces deux serveurs sont amenés à communiquer, ils doivent être ajoutés au groupe d'accès réseau comme le sont tous les autres initiateurs. Si un serveur agit en tant que répondeur au sein de plusieurs groupes d'accès réseau, vous devez vous assurer que tous les groupes de sécurité des groupes d'accès réseau auxquels le serveur appartient sont présents sur le droit « Accéder à cet ordinateur à partir du réseau » de ce système après que l'objet Stratégie de groupe a été appliqué. Si nécessaire, des objets Stratégie de groupe supplémentaires peuvent être requis afin que les ordinateurs remplissent cette exigence. Création d'un nouveau groupe d'accès réseau pour les ordinateurs initiateurs Procédez comme indiqué ciaprès pour créer un nouveau groupe d'accès réseau. Pour créer un nouveau groupe d'accès réseau pour les ordinateurs initiateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe. 4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK. 5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez sur Propriétés.
156
6. Dans la zone de texte Description, tapez une description appropriée pour le groupe. 7. Cliquez sur OK. Ajout de comptes d'ordinateurs initiateurs à un groupe d'accès réseau Procédez comme indiqué ciaprès pour constituer un nouveau groupe d'accès réseau avec des comptes d'initiateurs. Pour constituer le nouveau groupe d'accès réseau des initiateurs avec des comptes d'initiateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Initiateurs NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. 5. Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez sur OK.
6. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le <nom de l'initiateur>, puis cliquez sur OK.
7. Cliquez sur OK. Si vous avez besoin de restreindre encore les utilisateurs du domaine autorisés à accéder à la ressource restreinte, un groupe doit être créé pour les utilisateurs NAG avec accès restreint. À défaut, le groupe Utilisateurs du domaine peut être utilisé à la place. Création d'un nouveau groupe d'accès réseau pour les utilisateurs avec accès restreint Procédez comme indiqué ciaprès pour créer un groupe d'accès réseau pour les utilisateurs avec accès restreint. Pour créer un groupe d'accès réseau pour des comptes d'utilisateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe. 4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK. 5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez sur Propriétés.
6. Dans la zone de texte Description, tapez une description appropriée pour le groupe. 7. Cliquez sur OK.
157
Ajout de comptes d'utilisateurs avec accès restreint à un groupe d'accès réseau Procédez comme indiqué ciaprès pour constituer un nouveau groupe d'accès réseau avec des utilisateurs avec accès restreint. Pour constituer le nouveau groupe d'accès réseau avec des comptes d'utilisateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Utilisateurs NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. 5. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de l'utilisateur>, puis cliquez sur OK.
6. Cliquez sur OK. Création d'un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à partir du réseau » Un objet Stratégie de groupe permet d'attribuer le droit « Accéder à cet ordinateur à partir du réseau » aux groupes d'accès réseau appropriés. Le tableau suivant fournit un exemple d'implémentation, par un objet Stratégie de groupe, d'un groupe d'accès réseau et des noms de groupe associés auxquels le droit « Accéder à cet ordinateur à partir du réseau » doit être accordé. Tableau 6.1 : Exemple de définition de stratégie de groupe d'accès réseau Nom de l’objet Stratégie de groupe
Nom de groupe
Administrateurs Opérateurs de sauvegarde Utilisateurs NAG ou Utilisateurs du domaine
Remarque : les groupes répertoriés représentent les groupes minimaux à ajouter. L'administrateur devra déterminer s'il doit accorder ce droit à des groupes supplémentaires. Le groupe Utilisateurs du domaine est ajouté en tant que groupe par défaut. Si l'administrateur souhaite également restreindre l'accès pour certains utilisateurs en plus des ordinateurs, un groupe Utilisateurs NAG devra être créé de la même manière que celui dédié aux comptes d'ordinateurs (contenant les comptes d'utilisateurs sélectionnés). Pour créer un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à partir du réseau »
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC.
158
3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Objets de stratégie de groupe, puis cliquez sur Nouveau.
5. Dans la zone de texte Nom, tapez, puis cliquez sur OK. 6. Cliquez avec le bouton droit de la souris sur , puis cliquez sur Modifier.
7. Développez Configuration ordinateur, développez Paramètres Windows, développez Paramètres de sécurité, développez Stratégies locales, puis cliquez sur Attribution des droits utilisateur.
8. Dans le volet de droite, cliquez avec le bouton droit de la souris sur « Accéder à cet ordinateur à partir du réseau », puis cliquez sur Propriétés.
9. Activez la case à cocher Définir ces paramètres de stratégie. 10. Cliquez sur le bouton Ajouter un utilisateur ou un groupe. 11. Cliquez sur le bouton Parcourir. 12. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le nom de tous les groupes répertoriés dans le tableau précédent, séparés par des pointsvirgules. Cliquez ensuite sur OK.
13. Cliquez sur OK. 14. Fermez l'éditeur d'objets GPO puis la console GPMC. Déploiement d'objets Stratégie de groupe d'un groupe d'accès réseau Pour déployer les objets Stratégie de groupe d'un groupe d'accès réseau, ces derniers doivent tout d'abord être liés à un emplacement dans l'environnement du domaine afin qu'ils puissent être appliqués aux répondeurs appropriés du groupe d'accès réseau. L'application de l'objet Stratégie de groupe peut être contrôlée par n'importe quelle méthode standard permettant de garantir l'application des stratégies avec Active Directory. L'explication détaillée des étapes correspondantes n'entre pas dans le cadre de ce guide et dépend de la structure des unités d'organisation et des méthodes de gestion utilisées au sein de l'organisation.
Désactivation d'IPSec dans un groupe d'isolation Vous pouvez désactiver une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. Pour désactiver la stratégie IPSec, l'objet Stratégie de groupe est configuré pour que les paramètres d'ordinateur soient désactivés. Pour désactiver les paramètres d'ordinateur de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur, cliquez sur État GPO, puis cliquez sur Paramètres de configuration ordinateurs désactivés.
159
5. Fermez la console GPMC.
Réactivation d'IPSec dans un groupe d'isolation Vous pouvez réactiver des stratégies IPSec ayant été désactivées en modifiant l'objet Stratégie de groupe qui distribue la stratégie. Pour réactiver une stratégie IPSec désactivée, l'objet Stratégie de groupe est configuré de sorte que les paramètres d'ordinateur soient activés. Pour activer les paramètres d'ordinateur de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur, cliquez sur État GPO, puis cliquez sur Activé.
5. Fermez la console GPMC.
Suppression d'IPSec dans un groupe d'isolation Vous pouvez supprimer une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. Pour supprimer la stratégie IPSec, l'objet Stratégie de groupe est configuré de sorte que la stratégie IPSec ne soit plus attribuée. Pour supprimer l'attribution de la stratégie IPSec de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur, puis cliquez sur Modifier.
5. Développez Configuration ordinateur, développez Paramètres Windows, développez Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory (nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur, puis cliquez sur Supprimer l'attribution.
7. Vérifiez que la stratégie n'est plus attribuée, puis fermez l'éditeur d'objets GPO, puis la console GPMC.
Considérations relatives à la sauvegarde et la récupération Cette section fournit des informations sur l'évaluation des processus qui couvrent spécifiquement la sauvegarde et la restauration des composants de la solution d'isolation de serveurs et de domaines.
160
Sauvegarde Active Directory Les stratégies IPSec ne sont pas stockées dans les objets Stratégie de groupe utilisés pour distribuer les stratégies. Les fonctions de sauvegarde et de restauration de la stratégie de groupe capturent uniquement les informations sur lesquelles est basée l'attribution des stratégies IPSec aux objets Stratégie de groupe, et non les informations réelles relatives aux stratégies IPSec. Bien qu'une sauvegarde complète de l'état du système d'un contrôleur de domaine capture les informations relatives aux stratégies IPSec, il est également possible d'utiliser les commandes de menu Exporter des stratégies et Importer des stratégies du composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour sauvegarder et restaurer les stratégies IPSec. Remarque : il est important de sécuriser les sauvegardes de vos stratégies IPSec. Néanmoins, la sauvegarde est un fichier qui hérite des autorisations du système de fichiers NTFS du répertoire dans lequel il est stocké, et les données du fichier ne sont ni chiffrées ni signées. Vous devez protéger les informations de configuration IPSec contenues dans ces fichiers en utilisant les autorisations ou procédures de sécurité appropriées. Seuls les administrateurs IPSec autorisés doivent avoir accès à ces fichiers de sauvegarde. Pour plus d'informations sur la sauvegarde des données d'état du système sur un ordinateur exécutant Windows Server 2003, consultez la page To back up System State data (Sauvegarde des données d'état du système) sur le site Microsoft.com, à l'adresse www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en us/ntbackup_backup_sysstate.asp.
Restauration de systèmes hôtes Sur les ordinateurs pour lesquels une stratégie IPSec a été restaurée à partir d'une sauvegarde (sauvegarde sur bande ou sauvegarde à partir d'une image), la stratégie IPSec appliquée peut être une copie mise en cache de la stratégie IPSec basée sur Active Directory ou une stratégie IPSec locale. Si l'ordinateur se voit attribuer la stratégie IPSec basée sur Active Directory, le service IPSec tente de récupérer à partir d'Active Directory la copie la plus récente de la stratégie attribuée avant d'appliquer la copie mise en cache de la stratégie basée sur Active Directory. Au cours de cette opération, le service IPSec commence par interroger le système DNS (Domain Name System) pour obtenir la liste actuelle des adresses IP de tous les contrôleurs de domaine. Si les objets de stratégie IPSec ont été supprimés d'Active Directory, la copie mise en cache de la stratégie basée sur Active Directory est appliquée à la place. La liste des adresses IP des contrôleurs de domaine de la copie mise en cache de la stratégie IPSec basée sur Active Directory peut avoir considérablement changé depuis la création de la sauvegarde de la stratégie IPSec (par exemple, de nouveaux contrôleurs de domaine peuvent avoir été ajoutés). Si tel est le cas, la communication peut être bloquée avec les contrôleurs de domaine actuels ; ainsi, les authentifications basées sur le protocole Kerberos échoueront lors des tentatives d'établissement de connexions sécurisées à l'aide d'IPSec à distance. En outre, l'ordinateur risque de ne pas être en mesure de recevoir les mises à jour de la stratégie de groupe. Ce problème peut être résolu à l'aide de la procédure suivante :
1. Accédez à l'ordinateur localement et arrêtez le service IPSec sur cet ordinateur. 2. Redémarrez l'ordinateur en Mode sans échec avec prise en charge réseau, et configurez le service IPSec pour un démarrage manuel ou désactivez le service IPSec pour permettre les
161
communications sécurisées à l'aide d'IPSec avec les adresses IP des nouveaux contrôleurs de domaine.
Réduction des risques d'infection sur le réseau Dans certains cas, il peut s'avérer nécessaire d'interrompre rapidement les communications afin d'assurer la sécurité de l'environnement, en cas d'attaques virales ou de violations de la sécurité, par exemple. Les sections suivantes présentent les différentes méthodes pouvant être appliquées pour isoler les hôtes prenant part à des communications authentifiées. Ces méthodes ont été conçues pour ne pas isoler l'infrastructure ni les serveurs exemptés. Il est en effet primordial de ne pas isoler les serveurs d'infrastructure afin d'éviter que les systèmes perdent leur capacité à mettre à jour leurs stratégies IPSec à partir du domaine. Remarque : bien que ces méthodes d'isolation soient techniquement sûres, elles n'ont pas été testées dans un environnement de laboratoire. Il est fortement recommandé de les tester dans un environnement de laboratoire avant de les mettre en application.
Isolation du domaine d'isolation Les hôtes du domaine d'isolation sont autorisés à initier des communications avec des hôtes non approuvés. S'il est nécessaire de bloquer rapidement ce type de trafic, l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisée (Ignorer le trafic entrant, Autoriser le trafic sortant) peut être modifiée pour que le droit « Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec » soit désactivé. Au terme de la période d'interrogation IPSec, tous les hôtes du domaine d'isolation doivent cesser de communiquer avec des systèmes non intégrés à l'environnement IPSec. Pour modifier l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisé (Ignorer le trafic entrant, Autoriser le trafic sortant)
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gérer les actions de filtrage, cliquez sur l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisé (Ignorer le trafic entrant, Autoriser le trafic sortant), puis cliquez sur Modifier.
5. Activez ou désactivez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec.
6. Cliquez sur OK. 7. Cliquez sur OK. Une fois cette option définie, la stratégie bloque tout le trafic réseau destiné à des hôtes non approuvés. Une fois le problème résolu, la communication peut être rétablie en réactivant l'option.
Blocage des ports
162
Les stratégies IPSec déployées sur les ordinateurs d'un réseau local interne à une organisation sont configurés pour autoriser toutes les communications sur l'ensemble des ports. Cette approche simplifie la configuration et la gestion de l'environnement. Cependant, si un hôte utilisant IPSec se trouve infecté par un logiciel malveillant (virus ou ver, par exemple), il va très probablement transmettre l'infection aux autres ordinateurs. En fonction des stratégies que l'ordinateur utilise, l'infection peut toucher les hôtes approuvés et non approuvés. Les stratégies IPSec peuvent permettre de limiter la contamination par un blocage explicite des ports que le logiciel malveillant utilise. La limite principale que rencontre cette approche est le délai nécessaire aux ordinateurs pour détecter la modification apportée à la stratégie pour y intégrer des filtres de blocage. En outre, certains vers ont envahi le réseau et ont rendu difficile la récupération des modifications relatives à la stratégie IPSec. De plus, certains vers ont utilisé des ports également utilisés par des services vitaux, tels que le système DNS, ce qui rendrait difficile la mise à jour de la stratégie après l'application des filtres de blocage sur l'hôte. Le blocage peut être effectué en créant une règle qui bloque le trafic provenant d'adresses IP quelconques, destiné au port spécifique utilisé par un certain type de logiciels malveillants. Cette règle est ajoutée à toutes les stratégies appliquées à l'environnement. Une fois le logiciel malveillant éliminé, la règle peut être retirée des stratégies. Après avoir identifié les ports et les protocoles utilisés par un certain type de logiciels malveillants, créez une liste de filtres correspondant aux critères relatifs à la communication des logiciels malveillants en suivant les étapes de la procédure « Ajout d'une nouvelle règle à une stratégie IPSec existante », dans la section « Modification de la stratégie IPSec » plus haut dans ce chapitre. L'intervalle d'interrogation de la stratégie IPSec doit être réduit immédiatement après la décision d'utiliser le blocage de ports dans la stratégie de domaine. L'intervalle d'interrogation peut être augmenté à nouveau, une fois la menace écartée. Néanmoins, au lieu de créer un filtre qui utilise une adresse IP en direction d'une adresse IP spécifique, créez un filtre qui utilise « Mon adresse IP » vers n'importe quelle adresse IP. En principe, les filtres en miroir ne sont pas utilisés. Il faut utiliser une liste de filtres contenant deux filtres unidirectionnels (un pour le trafic entrant à destination d'un port connu, et un autre pour le trafic sortant à destination d'un port connu). Par exemple, les filtres suivants bloquent le port SQL 1433 exploité par le ver SQLSlammer : De toute adresse IP > Mon adresse IP, TCP, src *, dst 1433, sans miroir De Mon adresse IP > Toute adresse IP, TCP, src *, dst 1433, sans miroir Naturellement, ces filtres bloquent également les connexions de l'application SQL et doivent être retirés une fois que la menace de contamination par ver a disparu. Veillez à ne pas bloquer l'accès aux ports d'infrastructure essentiels comme DNS, sauf en cas de nécessité absolue. Ces filtres sont plus spécifiques que les filtres du sousréseau Woodgrove qui négocient IPSec pour l'ensemble du trafic transitant sur le réseau interne car ils intègrent une adresse IP spécifique. Une fois le filtre créé, ajoutez une règle à toutes les stratégies IPSec du domaine d'isolation et de groupe pour associer la liste de filtres à l'action de filtrage IPSec – Block (IPSec – Bloquer). Vous souhaiterez peutêtre inclure dans la conception de votre stratégie une règle qui associe déjà une liste de filtres IPSec vierge utilisée pour les ports bloqués à l'aide de l'action de blocage. Cette liste de filtres vierge peut être utilisée par les règles présentes dans l'ensemble des stratégies IPSec et activée de sorte que tous les membres du domaine vérifient cette liste à chaque intervalle d'interrogation. La règle peut également être désactivée ; dans ce cas, l'interrogation du service IPSec détecte quand la règle est activée dans chaque stratégie de groupe d'isolation. Si, pour quelque raison que ce soit, le blocage des ports empêche IPSec d'accéder à Active Directory pour obtenir une stratégie mise à jour, le service IPSec peut être arrêté et redémarré sur l'ordinateur par un administrateur, ou l'ordinateur peut être redémarré. Lorsque le service IPSec démarre, ce
163
dernier tente de télécharger la version la plus récente de la stratégie IPSec attribuée avant d'appliquer l'ancienne version contenue dans la mémoire cache.
Isolation dans le domaine enfant uniquement Si un domaine entier doit être isolé du reste des domaines de la forêt, la stratégie appliquée à ce domaine peut être configurée pour utiliser une clé prépartagée plutôt que le protocole Kerberos. Cette approche permet aux ordinateurs situés dans le domaine enfant de maintenir des communications avec d'autres systèmes du même domaine, mais les communications avec les systèmes extérieurs au domaine auquel ils ont normalement accès sont bloquées. Chaque stratégie du domaine enfant doit être modifiée afin d'utiliser uniquement une clé prépartagée pour la règle IPSec – Secure Organization Subnets (IPSec – Sousréseaux sécurisés de l'organisation). Toutes les méthodes d'authentification existantes, comme le protocole Kerberos, devront être supprimées. Pour configurer les méthodes d'authentification, suivez les étapes décrites dans la section « Modification de la méthode d'authentification d'une règle existante », plus haut dans ce chapitre. Si d'autres règles intégrant l'authentification existent dans la stratégie, elles doivent également être configurées pour utiliser une clé prépartagée. Toutes les stratégies du domaine enfant devant être isolé doivent être configurées de cette façon. Pour réduire les risques d'échec d'authentification de mode principal IKE lors du déploiement de la stratégie, la méthode d'authentification par clé pré partagée peut être placée au premier rang dans la liste des méthodes d'authentification, suivie par la méthode reposant sur le protocole Kerberos. Une fois que tous les ordinateurs disposent de la stratégie mise à jour, la méthode d'authentification Kerberos peut être supprimée. Un processus similaire est utilisé pour restaurer l'authentification pour le protocole Kerberos et supprimer la clé pré partagée une fois la menace écartée.
Isolation dans des groupes prédéfinis Bien que les groupes d'accès réseau constituent une implémentation unique pouvant être utilisée pour isoler un groupe prédéfini d'ordinateurs, il est également possible d'utiliser des clés prépartagées ou des certificats pour réaliser la même isolation. La principale différence par rapport aux groupes d'accès réseau est le fait que vous devrez créer des stratégies distinctes pour chaque groupe d'ordinateurs pour sécuriser le trafic entre les ordinateurs disposant d'une clé prépartagée ou d'un certificat. Cette solution nécessite un processus de planification des communications supplémentaire, notamment si un système appartient à plusieurs groupes. L'inconvénient majeur des clés prépartagées est le fait qu'elles sont stockées en clair dans la stratégie, ce qui les rend facilement détectables (la confidentialité est alors compromise) depuis un client du domaine. Cet inconvénient peut ne pas être gênant si la valeur de la clé prépartagée est uniquement utilisée pour une isolation temporaire lors d'une infection par ver. En raison d'une restriction, IKE vérifie les contraintes de certificat au niveau de l'autorité de certification racine et non de l'autorité émettrice ; il faudrait alors déployer une autorité de certification racine unique pour chaque groupe.
Résumé Ce chapitre fournit des informations, des processus et des procédures nécessaires à la gestion, la maintenance et la modification d'une solution d'isolation de serveurs et de domaines après le déploiement et la mise en service effectifs de cette dernière.
164
Les processus et procédures décrits ici doivent être correctement expliqués et communiqués au personnel susceptible d'être impliqué dans la gestion quotidienne des hôtes de l'environnement. Dans la mesure où la modification, même mineure, d'une stratégie IPSec peut désactiver une voie de communication protégée, ces processus et procédures doivent être conçus de manière à éviter tout risque d'erreur pouvant résulter d'une mauvaise compréhension des conséquences d'une telle modification.
165
Chapitre 7 : Dépannage d'IPSec Ce chapitre fournit des informations relatives au dépannage d'IPSec (Internet Protocol security), dans le cadre d'une isolation de serveurs et de domaines, par exemple. Il est basé sur l'expérience et les processus de l'équipe Service informatique (IT) de Microsoft. Lorsque cela est possible, ce chapitre fait référence aux procédures de dépannage Microsoft existantes ainsi qu'aux informations associées. Le support informatique de Microsoft repose sur un modèle de prise en charge multiniveaux, et le support technique est communément appelé support de niveau 1. Les procédures de remontée des incidents permettent aux techniciens du support technique de transférer les incidents nécessitant l'intervention de spécialistes. Les procédures de ce chapitre font référence à trois niveaux de support : niveau 1, niveau 2 et niveau 3. Pour garantir des conseils aussi pratiques et précis que possible, la majeure partie du contenu se situe au niveau 2. Les conseils de niveau 1 permettent d'aider les entreprises à déterminer aussi rapidement que possible si un problème est lié à IPSec et, si tel est le cas, à générer les informations requises pour aider les ingénieurs du support de niveau 2 à résoudre le problème. Les informations extrêmement détaillées et complexes qui sont nécessaires à la résolution des problèmes de niveau 3 ne sont pas traitées dans ce chapitre. Si les informations proposées dans ce chapitre ne permettent pas de résoudre un problème lié à IPSec, Microsoft vous recommande de contacter Microsoft® Product Support Services (services de support technique) pour obtenir une assistance supplémentaire. La plupart des procédures de support, des outils et des scripts utilisés par Microsoft sont fournis dans ce chapitre à titre de référence. Ces recommandations et outils sont généralement adaptés et répondent aux besoins spécifiques de votre entreprise. Lorsque IPSec est utilisé pour sécuriser le trafic sur le réseau via les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol), les procédures et outils de dépannage réseau TCP/IP traditionnels peuvent se révéler inefficaces. C'est pourquoi il est important de planifier et d'élaborer des techniques de dépannage spécifiques à IPSec qui pourront être utilisées si un problème se présente sur les ordinateurs qui utilisent ou (tentent d'utiliser) IPSec pour leurs communications.
Niveaux de support et transfert des incidents Le support de l'isolation de serveurs et de domaines est un service standard proposé par Microsoft, qui est défini par les accords sur les niveaux de service (service level agreement, SLA). Le support de l'isolation est fourni par les niveaux suivants :
• Niveau 1 : support technique. Le support technique constitue le point d'entrée à la fois pour les problèmes client associés et non associés à un domaine. Le support technique prend également en charge les serveurs gérés par les services informatiques centraux. (Les autres serveurs peuvent être gérés par des équipes de gestion des applications d'entreprise ou des groupes de produits). Les membres du support technique sont formés pour utiliser une taxinomie et divers organigrammes de classification des problèmes liés à l'isolation de serveurs et de domaines.
Au cours de la phase pilote de la solution d'isolation de Microsoft, les problèmes rencontrés par les clients ont été transférés au service de sécurité informatique d'entreprise. Cependant, après le déploiement de la solution dans l'étape de production, les problèmes client ont été traités par les équipes de support de niveau 2.
166
• Niveau 2 : exploitation du centre de données, centre d'exploitation du réseau global,
support des applications d'entreprise et support de messagerie/collaboration. Ces groupes sont des équipes d'exploitation quotidienne qui surveillent et gèrent les services informatiques et leurs ressources associées. Lors des phases pilote d'isolation de serveurs et de domaines, ces équipes ont été le point de départ de transfert des problèmes de serveur et du dépannage pour le support technique et le service de sécurité informatique d'entreprise. Chaque groupe possède un expert en isolation de serveurs et de domaines, ainsi que des procédures de dépannage détaillées.
• Niveau 3 : services d'infrastructure et de réseau Windows. Lors des phases pilote d'isolation
de serveurs et de domaines, ce groupe a défini une équipe d'experts en dépannage des composants architecturaux et des technologies inhérentes à la solution, comme IPSec, le traitement des paquets TCP/IP, les comptes d'ordinateurs et les droits de connexion au réseau. Si un autre niveau de transfert est nécessaire au sein de Microsoft, le niveau 3 fonctionne directement avec les équipes de développement Windows jusqu'à ce que le problème soit clos. Hors du cadre de Microsoft, ce niveau fonctionne avec les services de support technique Microsoft en cas de nécessité.
La section suivante résume les techniques de dépannage pouvant être utilisées par le personnel du support technique dans l'organisation du support de niveau 1.
Dépannage de niveau 1 Cette section présente le processus général de dépannage des problèmes liés à IPSec qui est utilisé par le personnel du support technique chargé du support de niveau 1. En général, le personnel du support de niveau 1 est composé d'opérateurs téléphoniques qui tentent de diagnostiquer les problèmes à distance.
Le problème estil lié à IPSec ? Le support technique est susceptible de recevoir des appels du type « J'ai réussi à me connecter au serveur x jusqu'à l'activation d'IPSec » ou « Tout fonctionnait parfaitement hier, mais je n'arrive pas à me connecter aujourd'hui ». D'après l'expérience des équipes informatiques de Microsoft, le déploiement d'IPSec a entraîné l'augmentation des volumes d'appels pour tous les types de problèmes de connectivité réseau et les incidents « d'accès refusé » car les utilisateurs étaient plus attentifs aux comportements des applications et du réseau. Si un utilisateur pensait que le problème était lié à IPSec, il appelait le support technique. Un plan d'implémentation de l'isolation de serveurs et de domaines doit inclure un système de classification des appels afin que le personnel du support technique puisse fournir des rapports précis sur le volume et la nature des problèmes liés à IPSec. Une fois que l'appelant a fourni toutes les informations d'administration utiles, le personnel du support technique doit suivre un processus de dépannage défini. Étant donné que les répercutions des stratégies IPSec sur les communications peuvent varier et que le processus de déploiement peut prendre plusieurs jours (voire plusieurs semaines), il est vivement recommandé de définir un organigramme et de le mettre à jour pour chaque ensemble de modifications d'isolation mis en place. Le personnel de gestion du support technique doit être impliqué dans ce processus de planification. L'objectif du support technique est de classer le problème dans une catégorie afin de pouvoir lui appliquer des solutions adaptées. Si ces tentatives ne permettent pas de résoudre le problème, le support technique doit s'assurer qu'il a bien reçu les informations requises, puis il doit transférer le problème au support de niveau 2. Par exemple, le support technique doit être en mesure d'identifier divers types de problèmes de la manière suivante :
• Connectivité réseau. Utilisez les messages ping et tracert du protocole ICMP (Internet Control Message Protocol) pour tester les chemins du réseau.
167
• Résolution de noms. Utilisez les commandes ping <nom destination> et nslookup. • Applications. Certaines applications fonctionnent (par exemple, net view), alors que d'autres ne fonctionnent pas lorsqu'elles communiquent avec la même destination.
• Services. Par exemple, déterminez si le serveur exécute le service de routage et d'accès distant (Routing and Remote Access, RRAS), lequel crée une stratégie IPSec automatique conflictuelle avec le protocole L2TP.
• Ordinateur de l'appelant. Déterminez s'il peut accéder à n'importe quel ordinateur hôte ou à un
ordinateur de destination approuvé spécifique qui est utilisé par le support technique pour les tests et les diagnostics.
• Ordinateur cible. Déterminez si l'ordinateur de l'appelant peut accéder à tous les ordinateurs du support technique utilisés pour les tests et s'il ne peut pas accéder à certains ordinateurs de destination.
En fonction de l'entreprise, le support technique peut utiliser l'Assistance à distance ou le Bureau à distance pour se connecter à l'ordinateur de l'appelant. Les instructions fournies dans ce chapitre ne nécessitent pas un accès à distance, mais elles peuvent s'avérer utiles pour le personnel du support technique qui peut s'en servir plutôt que de guider l'appelant dans le composant logiciel enfichable MMC (Microsoft Management Console) Moniteur IPSec ou la visionneuse du journal des événements. Dans des scénarios où l'isolation de serveurs est utilisée sans isolation de domaines, le personnel du support technique doit savoir quels serveurs font partie du groupe d'isolation. Détermination de l'étendue et de la gravité L'une des premières questions auxquelles le support de niveau 1 doit répondre est la suivante : « qui est concerné par le problème ? » En effet, le personnel technique doit savoir si d'autres utilisateurs rencontrent le même problème et, le cas échéant, le nombre d'utilisateurs concernés et leur emplacement. Le personnel technique doit ensuite s'intéresser à l'étendue du problème. Par exemple, cela affectetil la connectivité d'un seul serveur ou existetil d'autres problèmes de type échec de connexion ou d'authentification sur des zones importantes du réseau ? Les problèmes de connectivité peuvent impliquer de nombreuses couches et technologies utilisées dans les communications réseau. Les ingénieurs du support technique doivent connaître le fonctionnement général des communications réseau TCP/IP Windows, ainsi que les problèmes spécifiques liés à la solution. Cette section détaille les différents types de problèmes courants que chaque support de niveau 1 doit traiter.
• Problèmes spécifiques à l'ordinateur. Les communications protégées par IPSec requièrent une
authentification IKE (Internet Key Exchange) mutuelle des ordinateurs. Les ordinateurs qui débutent des communications et ceux qui y répondent doivent posséder des comptes de domaine valides et avoir accès aux contrôleurs de leur domaine. En outre, pour que les attributions de stratégie IPSec et que les contrôles d'accès au réseau fonctionnent, il est nécessaire que les comptes d'ordinateur soient dans les groupes de domaine appropriés. D'autres problèmes spécifiques peuvent affecter le comportement d'IPSec : • Le système d'exploitation ne dispose pas du Service Pack ou du correctif approprié, ou la configuration de la clé du registre est incorrecte. • Un logiciel ou des services particuliers sont installés et en cours d'exécution sur l'ordinateur. • La connexion réseau utilise une adresse IP spécifique ou communique à l'aide d'un chemin réseau particulier.
168
En raison de ces types de problèmes, certains ordinateurs peuvent rencontrer des problèmes de connectivité et d'autres non. Remarque : tous les outils de dépannage d'IPSec mentionnés dans ce chapitre nécessitent des privilèges du groupe des administrateurs locaux.
• Problèmes d'emplacement réseau et problèmes spécifiques au chemin. Dans une solution
d'isolation de serveurs et de domaines ou de déploiement à grande échelle d'IPSec, il est probable que la totalité du trafic TCP et UDP sera encapsulée. Par conséquent, les périphériques réseau du chemin ne voient que les protocoles IKE, IPSec et ICMP. S'il existe des problèmes réseau au niveau de la transmission de ces trois protocoles entre la source et la destination, il est possible que la communication soit bloquée entre les deux ordinateurs.
• Problèmes spécifiques à l'utilisateur. Le déploiement d'IPSec, dans le cas d'une isolation de
serveurs et de domaines, par exemple, peut avoir des répercutions sur les droits de connexion au réseau des utilisateurs d'un domaine. Par exemple, le problème peut concerner uniquement les utilisateurs qui ne font pas partie d'un groupe autorisé à accéder au réseau, ou il peut concerner un utilisateur autorisé qui ne parvient pas à obtenir les informations d'authentification Kerberos contenant les appartenances de groupe correctes. Il peut exister des différences de comportement entre les comptes de domaine et d'utilisateur local ou les comptes de service.
Deux autres caractéristiques de l'isolation de serveurs et de domaines sont fréquentes lors des déploiements d'IPSec en entreprise : il s'agit de l'utilisation de filtres de sousréseau pour définir les intervalles d'adresses utilisés sur le réseau interne et l'application de stratégies IPSec basées sur l'appartenance au domaine et au groupe qui ne tiennent pas compte de l'emplacement d'un ordinateur sur le réseau interne. C'est pourquoi, en cas de problème avec la conception des filtres de sous réseau ou le chemin réseau utilisé par cet ordinateur pour communiquer avec les autres, des problèmes de connectivité peuvent survenir uniquement dans certaines zones du réseau lors de l'utilisation d'une adresse IP particulière (une adresse sans fil au lieu d'une adresse LAN), ou sur certains ordinateurs uniquement.
Organigrammes de dépannage Les organigrammes de gestion des appels de cette section ont été élaborés par les équipes informatiques de Microsoft pour faciliter le classement des problèmes de support d'IPSec de niveau 1. Outre les outils standards, deux des organigrammes font référence à un script d'actualisation de la stratégie IPSec, dont une description est fournie dans la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre. La figure 7.1 est utilisée pour réaliser un diagnostic initial et pour déterminer le type de problème :
• S'agitil d'un problème de connectivité réseau ? Si oui, procédez à une action de dépannage réseau de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.
• S'agitil d'un problème de résolution de noms ? Si oui, procédez à une action de dépannage de
résolution de noms de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.
• S'agitil d'un problème lié à l'application ? Si oui, transférez le problème au support de niveau 2. • S'agitil d'un problème IPSec lié à l'ordinateur de l'appelant ? Si oui, reportezvous à la figure 7.2.
• S'agitil d'un problème IPSec lié à l'ordinateur cible que l'appelant tente de contacter ? Si oui, reportezvous à la figure 7.3.
169
Figure 7.1 Processus de dépannage en cas d'échec de communication avec l'ordinateur cible
Remarque : cet organigramme part du principe que l'ordinateur de l'appelant exécute IPSec et que les zones DNS de recherche inversée sont configurées pour permettre le bon fonctionnement de la commande ping –a. La figure 7.2 permet d'identifier les problèmes liés à l'ordinateur de l'appelant. Outre les diagnostics, cet organigramme référence l'utilisation d'un script d'actualisation de stratégie IPSec (reportezvous à la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre), qui peut résoudre le problème sans nécessairement l'identifier. Les étapes illustrées dans la figure 7.2 vous aident à déterminer les éventuels problèmes suivants liés à l'ordinateur de l'appelant :
• S'agitil d'un problème de routage et d'accès distant ? Si oui, arrêtez le service RRAS (s'il n'est pas requis) ou transférez le problème au support de niveau 2.
• S'agitil d'un problème de stratégie ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec.
• S'agitil d'un problème lié au compte de domaine ? Si oui, créez un compte de domaine pour l'ordinateur de l'appelant.
• S'agitil d'un problème autre que ceux énoncés cidessus ? Si l'actualisation de la stratégie IPSec et/ou la création d'un compte de domaine n'ont pas permis de résoudre le problème, transférez le problème au support de niveau 2.
170
Figure 7.2 Dépannage d'IPSec sur l'ordinateur de l'appelant – problèmes connexes
La figure 7.3 permet d'identifier les problèmes liés à un ordinateur cible spécifique. Notez que cet organigramme référence également l'utilisation d'un script d'actualisation de stratégie IPSec qui peut résoudre le problème sans nécessairement l'identifier. La figure 7.3 vous aide à déterminer les éventuels problèmes suivants liés à l'ordinateur cible (ou vous indique le chemin d'accès à cet ordinateur) :
• S'agitil d'un problème RRAS ? Si oui, transférez le problème au support de niveau 2. • S'agitil d'un problème de stratégie IPSec ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec. Vérifiez ensuite la connectivité réseau.
• S'agitil d'un problème de connectivité réseau ? Si oui, transférez le problème au support de niveau 2.
• S'agitil d'un problème de droits de connexion ? Si oui, transférez le problème au support de niveau 2.
171
Figure 7.3 Dépannage d'IPSec sur l'ordinateur cible – problèmes connexes
Une fois que le personnel du support de niveau 1 a étudié le problème par rapport aux organigrammes, l'un des états suivants est attribué au problème :
• Résolution complète. Cet état indique que le problème a été résolu et que sa cause a peutêtre été déterminée.
• Résolution partielle. Cet état signifie que le problème a été résolu mais que sa cause n'a pas été totalement comprise. Par exemple, l'actualisation d'une stratégie IPSec peut résoudre le problème mais n'explique pas forcément pourquoi une mauvaise stratégie ou aucune stratégie n'a été appliquée.
• Non résolu. Cet état indique que le problème est toujours en attente d'une résolution mais que sa cause a probablement été identifiée. Le problème est transféré au support de niveau 2.
Prévention des attaques de manipulation
172
Dans une solution d'isolation, le personnel du support technique peut avoir connaissance de certaines zones spécifiques de l'environnement informatique non protégées par IPSec, comme les ordinateurs appartenant à la liste d'exemption. Ces zones ne doivent pas être utilisées pour protéger des informations confidentielles, car en général, les autres solutions de sécurité ne donnent accès à ces informations qu'aux équipes de support de niveau supérieur. C'est pour cette raison que le personnel du support technique doit être formé à la détection et à la prévention des manipulations. Une attaque de manipulation se manifeste lorsqu'une personne peu fiable tente d'obtenir des informations sur le fonctionnement de la sécurité et sur les points faibles du système de sécurité, en profitant simplement de la tendance des gens à faire confiance aux autres. Le personnel du support technique doit contrôler attentivement les informations suivantes :
• Membres de la liste d'exemption. La liste des adresses IP dans les filtres de la liste d'exemption
est à la disposition des administrateurs locaux sur tous les hôtes approuvés lors de l'utilisation du composant logiciel enfichable MMC Moniteur IPSec ou lors de l'affichage du cache de la stratégie IPSec dans le registre local. De plus, les paramètres de sécurité utilisés dans l'entreprise sont susceptibles de donner aux utilisateurs non administratifs un accès en lecture au cache. Une fois que l'isolation du domaine est entièrement implémentée, les pirates analysent le réseau pour détecter les ordinateurs exemptés qui seront capables de répondre aux requêtes de connexion TCP et UDP. Notez que les serveurs DNS, DHCP et WINS sont facilement identifiables à partir de la configuration DHCP et que les contrôleurs de domaine sont faciles à localiser par l'utilisation d'une requête DNS ou UDP LDAP (Light Directory Access Protocol).
• Ordinateurs de l'entreprise ne faisant pas partie de la solution d'isolation. Par exemple, certains types de serveurs ou domaines peuvent ne pas être inclus dans la solution.
• Ordinateurs qui utilisent l'isolation de serveurs ou qui requièrent un contrôle d'accès basé
sur les machines. Les serveurs contenant les informations les plus sensibles sont généralement dotés des protections de sécurité les plus efficaces.
• Utilisateurs qui sont des administrateurs ou qui jouent un rôle spécial dans le service
informatique. Les noms de connexion ou les adresses électroniques sont divulgués lorsqu'ils sont utilisés dans les noms complets ou partiels des ordinateurs.
• Sousréseaux utilisés à des fins spécifiques ou par certaines entreprises. Si ces informations sont connues, un pirate peut alors concentrer son attaque sur les points les plus importants du réseau.
• Autres mesures de sécurité basées sur le réseau qui sont utilisées. Par exemple, il est
extrêmement utile pour un pirate de savoir s'il existe des parefeu, si les filtres de routeur autorisent certains trafics ou si la détection d'intrus sur le réseau est utilisée.
Les agents du support technique doivent également être vigilents si des appelants leur demandent de se connecter à l'adresse IP de leur ordinateur pour détecter un problème ; par exemple, un pirate demande à une personne du support technique de se connecter à son ordinateur en utilisant le partage de fichiers, le Bureau à distance, Telnet ou un autre protocole réseau. Si l'agent du support technique effectue la connexion sans IPSec, l'ordinateur pirate peut obtenir des informations sur le mot de passe ou (dans certains cas, comme avec Telnet) « dérober » le mot de passe. Cette situation peut se produire car certains protocoles réseau des clients ne procèdent pas à l'authentification de l'ordinateur de destination, ni n'établissent de relation d'approbation, ou encore, ils ne requièrent pas de protection par mot de passe fiable avant de révéler des informations sur l'identité de l'utilisateur ou des données sur le mot de passe.
Exemples de scripts de prise en charge
173
Dans la plupart des scénarios de dépannage, il est possible de trouver rapidement une solution lorsque les informations appropriées ont été identifiées. Pour ce faire, vous pouvez utiliser divers outils Windows, comme ceux déisngés dans les organigrammes. Dans la solution Woodgrove Bank, plusieurs scripts ont été développés pour fournir des informations clés, sans que le personnel du support de niveau 1 ne connaisse en détail le fonctionnement des outils et la syntaxe. Ces scripts sont disponibles dans le dossier de téléchargement Tools and Templates de ce guide. Scripts disponibles pour le support de niveau 1 Si l'utilisateur est également l'administrateur local de son ordinateur, le personnel du support technique peut lui demander d'exécuter l'un des trois scripts fournis dans le cadre de cette solution. Ces scripts sont des exemples des scripts personnalisés utilisés dans l'environnement Woodgrove Bank détaillé dans ce guide. Ils sont décrits dans ce chapitre pour illustrer la manière dont les scripts peuvent être utilisés dans le processus de dépannage. Remarque : ces scripts sont des exemples testés, mais ils ne sont pas pris en charge par Microsoft. Ils doivent être utilisés par une entreprise comme base pour l’élaboration d'une solution personnalisée. IPSec_Debug.vbs Ce script fournit des informations de débogage et peut résoudre certains problèmes. Il arrête et redémarre le service IPSec (qui supprime toutes les associations de sécurité IKE et IPSec actuelles), force une actualisation de stratégie de groupe à recharger la stratégie IPSec actuellement affectée au domaine à partir du service d'annuaire Active Directory® et met à jour le cache de la stratégie. Pour éviter la perte de connectivité des sessions de bureau à distance, le script doit être téléchargé sur l'ordinateur de l'appelant et exécuté localement par un compte disposant de privilèges administratifs. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript IPSec_Debug.vbs Le script effectue les fonctions suivantes :
• détection de la version du système d'exploitation ; • appel du script Detect_IPSec_Policy.vbs ; • augmentation de la journalisation de la stratégie de groupe ; • augmentation de la journalisation du protocole d'authentification Kerberos version 5 ; • purge des tickets actuels du protocole Kerberos ; • actualisation de la stratégie de groupe ; • activation de la journalisation IPSec ; • exécution de tests PING et SMB (Net View) ; • détection des versions de fichier IPSec ; • exécution de tests de diagnostic de la stratégie et du réseau ; • copie des événements IPSec 547 dans un fichier texte ; • désactivation de la journalisation IPSec ; • restauration de la journalisation du protocole Kerberos ; • restauration de la journalisation de la stratégie de groupe. 174
Ce script active également tous les journaux liés à IPSec en vue du dépannage par le support de niveau 2. Detect_IPSec_Policy.vbs Ce script détermine si l'ordinateur exécute la stratégie IPSec appropriée en vérifiant les informations sur la version de la stratégie IPSec de domaine dans le cache du registre local actuel. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript Detect_IPSec_Policy.vbs Remarque : ce script est également appelé à partir du script IPSec_Debug.vbs ; il n'est donc pas nécessaire de l'exécuter en complément de ce dernier. Refresh_IPSec_Policy.vbs Il s'agit du script d'actualisation de la stratégie IPSec référencé dans les organigrammes de dépannage. Il actualise les tickets du protocole d'authentification Kerberos sur l'ordinateur ainsi que la stratégie de groupe et peut résoudre le problème si ce dernier est provoqué par une attribution de stratégie IPSec incorrecte ou par un échec lors du téléchargement de la stratégie de groupe. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript Refresh_IPSec_Policy.vbs
Transfert des problèmes Lorsque le personnel du support technique doit transférer un problème IPSec, le personnel du niveau 1 doit collecter les informations suivantes et les transmettre avec la requête de service :
• les fichiers journaux générés avec le script IPSec_Debug.vbs ; • le nom de l'ordinateur de l'appelant afin que le niveau de support technique suivant puisse identifier le fichier journal généré par le script ;
• l'ordinateur de destination auquel l'accès est refusé, afin que le problème soit transféré au groupe de support compétent.
Les scénarios d'isolation de serveurs disposent souvent de leur propre équipe technique pour identifier l'appartenance des groupes d'accès au réseau.
Préparation du dépannage de niveau 2 Le support de niveau 2 a deux rôles principaux. Tout d'abord, en tant que destinataire des transferts de niveau 1, le niveau 2 valide les problèmes et passe en revue les étapes effectuées par le niveau 1 pour s'assurer qu'aucune étape de dépannage n'a été omise. Dans cette optique, le niveau 2 doit confirmer que les problèmes transférés sont véritablement liés à IPSec et qu'il ne s'agit pas d'une erreur de diagnostic. Ensuite, en tant qu'ingénieurs de support réseau qualifiés, les membres du support de niveau 2 doivent utiliser leurs compétences et leur expérience (voir la section suivante) pour résoudre le problème grâce à l'analyse du journal et sans obtenir le contrôle administratif de l'ordinateur. Toutefois, les fichiers journaux ne font que capturer les informations, et les actions correctives nécessitent un accès administratif. En principe, un membre du support technique de niveau 2 n'est pas administrateur de domaine et n'est pas chargé d'apporter des modifications à une stratégie IPSec basée sur un domaine ni aux appartenances de groupe.
175
Compétences du support de niveau 2 Le personnel technique chargé du support IPSec de niveau 2 doit posséder des compétences et de l'expérience dans les domaines suivants :
• Stratégie de groupe. Il doit connaître les stratégies à attribuer, savoir comment elles sont attribuées et être en mesure d'effectuer les tâches suivantes :
• vérifier les listes de contrôle d’accès (Access control lists, ACL) sur les objets de la stratégie de groupe (Group policy objects, GPO) ; • vérifier les paramètres GPO ; • vérifier les appartenances des ordinateurs et des utilisateurs aux divers groupes.
• Expérience des logiciels tiers utilisés par l'entreprise. • Identification des échecs d'authentification. • Le personnel technique doit être capable de vérifier que le compte d'un ordinateur appartenant à un domaine est correct en utilisant les utilitaires netdiag et nltest.
• Configuration IPSec. Le personnel technique doit être capable d'effectuer les tâches suivantes : • vérifier les configurations du filtre IPSec ; • recharger la stratégie de domaine IPSec ; • désactiver entièrement IPSec ou uniquement la stratégie de domaine afin d'utiliser la stratégie locale pour des tests ; • dépanner le processus de négociation IKE d'IPSec et les protocoles de sécurité.
• Réseau. Le personnel technique doit être capable d'effectuer les tâches suivantes : • dépanner la pile de protocole réseau sur un ordinateur hôte ; • comprendre et résoudre les informations collectées dans un fichier de suivi réseau ; • dépanner des problèmes de chemin d'accès au réseau, y compris les solutions de recherche de l'unité maximale de transfert (Maximum Transmission Unit, MTU) du chemin TCP et les solutions d'accès distant au réseau privé virtuel (virtual private network, VPN).
Problèmes inhérents à l'utilisation d'IPSec Comme nous l'avons mentionné dans la section précédente, dans le cas d'une solution d'isolation de serveurs et de domaines, le personnel du support de niveau 2 a besoin de connaître les détails relatifs aux communications protégées par IPSec, mais il doit aussi être capable d'isoler les problèmes associés à d'autres composants. Pour établir une communication IPSec entre deux ordinateurs, ceuxci nécessitent généralement une stratégie IPSec compatible. Par exemple, une stratégie IPSec peut bloquer la communication si l'ordinateur distant ne dispose pas d'une stratégie IPSec adéquate. Bien que ce comportement soit intentionnel ou acceptable lors du déploiement d'un changement de stratégie, le fait qu'il bloque la connectivité réseau entre un ou plusieurs ordinateurs et provoque l'apparition d'avertissements ou d'erreurs dans une application n'est pas forcément visible immédiatement. Dans le pire des cas, un administrateur peut accidentellement attribuer une stratégie IPSec à tous les membres d'un domaine qui bloque la totalité du trafic. Il est difficile d'interrompre la réplication de la stratégie préjudiciable, sauf si l'erreur est immédiatement réparée avec une attribution qui réplique rapidement l'attribution d'origine. Ce type d'erreur entraîne une situation dans laquelle les communications entre un client et un contrôleur de domaine sont nécessaires à l'utilisation d'IPSec. Étant donné que l'authentification utilisée dans cette solution repose sur le protocole Kerberos, les clients qui héritent de cette stratégie ne sont pas en mesure d'effectuer le processus de connexion, car ils ne sont pas capables d'obtenir le ticket Kerberos requis pour sécuriser les communications. Les administrateurs doivent planifier avec
176
minutie toute modification de la stratégie et s'assurer que des mesures de protection existent pour minimiser les risques de ce type de situation. Des informations générales sur le dépannage du protocole TCP/IP sont fournies dans les guides de dépannage répertoriés à la section « Informations complémentaires » à la fin de ce chapitre. Cependant, plusieurs procédures mentionnées dans ces guides fonctionnent uniquement si IPSec assure la connectivité. Si IKE ou IPSec sont défaillants, alors la plupart de ces procédures et outils deviennent inopérants. Dans un scénario d'isolation de serveurs et de domaines, il est possible que certaines procédures indiquées dans ces guides ne fonctionnent pas du tout, même si IPSec assure la connectivité. Un service de support technique doit mettre à jour et personnaliser ses outils et procédures de dépannage afin qu'ils soient efficaces dans un environnement d'isolation de serveurs et de domaines. Comme il existe différentes manières de déployer des stratégies IPSec pour contrôler et sécuriser le trafic réseau, il est peu vraisemblable que les entreprises puissent uniquement utiliser les procédures existantes et un jeu d'outils générique. Il est important que le personnel du support dispose d'exemples documentés sur les résultats escomptés des outils de dépannage réseau qui sont obtenus à partir d'un laboratoire où l'isolation de serveurs et de domaines ou le déploiement d'IPSec fonctionnent correctement. Dans la plupart des cas, les outils de diagnostic réseau n'attendent pas le délai de trois secondes pour passer en communication en texte clair ou les brefs délais requis pour la négociation IKE initiale des associations de sécurité (security associations, SA) d'IPSec. Par conséquent, les outils peuvent afficher un résultat lors de leur exécution initiale et afficher un autre résultat s'ils sont exécutés quelques secondes plus tard. En outre, lorsque l'accès au réseau est délibérément refusé par IPSec, les outils signalent des échecs. Le type d'échec dépend de l'outil utilisé et de l'environnement IPSec. Remarque : dans la section consacrée au support de niveau 1, les termes appelant et cible ont été utilisés pour aider le personnel du support technique à résoudre les problèmes courants. Dans la section relative au support de niveau 2, il est préférable d'utiliser les termes IPSec initiateur et répondeur pour que les processus de dépannage avancé soient plus clairs. Le reste de ce chapitre utilise ces termes IPSec. Stratégie de groupe et appartenance aux groupes La stratégie IPSec basée sur le domaine dépend de la stratégie de groupe et du téléchargement des GPO. Si le système de stratégie de groupe du client rencontre des erreurs lors de la détection de changements GPO ou lors de leur téléchargement, la connectivité IPSec peut s'en trouver affectée. Si l'attribution de la stratégie de groupe est contrôlée par l'appartenance à une unité d'organisation (UO) et que les comptes d'ordinateurs sont par inadvertance déplacés vers une autre UO, supprimés ou recréés dans une UO inappropriée, il est possible qu'une stratégie IPSec inadéquate soit attribuée. Cette solution utilise les groupes de sécurité des domaines pour contrôler les attributions de stratégies et l'accès au réseau. L'appartenance aux groupes est contenue dans les tickets (tickets TGT et de service) du protocole d'authentification Kerberos version 5. La durée de vie de ces tickets est assez longue. Ainsi, les administrateurs doivent prévoir le temps nécessaire aux ordinateurs pour recevoir les informations d'identification des nouveaux tickets TGT et de service Kerberos contenant les mises à jour des appartenances aux groupes. Le protocole Kerberos permet très difficilement de déterminer si les tickets Kerberos d'un ordinateur contiennent les appartenances aux groupes appropriées. Il s'agit d'une difficulté liée à la conception des tickets, car toutes les informations sur l'appartenance à un groupe sont stockées sous forme chiffrée dans le ticket. L'appartenance à un groupe doit être déterminée par l'utilisation des informations du service d'annuaire, et non par l'utilisation des tickets. Authentification Kerberos La conception de l'isolation de serveurs et de domaines utilise le protocole Kerberos version 5 pour l'authentification IKE. Étant donné que le protocole Kerberos requiert une connectivité réseau et un
177
service disponible à partir du DNS et des contrôleurs de domaine, le manque de connectivité entraîne l'échec de l'authentification Kerberos et d'IKE. (IKE échoue également si Kerberos échoue.) Ainsi, des problèmes de connectivité entre un ordinateur A et un ordinateur B peuvent être provoqués par une connectivité réseau bloquée entre l'ordinateur A et l'ordinateur C. Ces problèmes sont causés par l'incapacité du protocole Kerberos de s'authentifier auprès d'un contrôleur de domaine. Dans ce type de situation, les informations fournies dans les événements 547 des journaux d'audit et de sécurité de Windows offrent généralement des conseils très précieux sur la source du problème. Trafic entrant protégé par IPSec requis Cette solution d'isolation de serveurs et de domaines spécifie que des communications protégées par IPSec sont requises pour l'accès entrant. Cette condition a pour conséquence d'obliger les outils de surveillance à distance exécutés sur des ordinateurs non approuvés ou sur des périphériques de surveillance réseau dédiés à signaler qu'il est impossible de contacter un ordinateur distant. Si ces ordinateurs ou périphériques ne peuvent pas intégrer l'environnement « approuvé », ils ne seront pas capables de jouer un rôle de surveillance sauf si des exemptions spécifiques sont ajoutées à la conception. Le dépannage est compliqué par le fait qu'IPSec peut être requis pour établir la connectivité vers un hôte approuvé, ce qui signifie qu'un administrateur risque de ne pas pouvoir se connecter à un hôte approuvé, ni de pouvoir interrompre le service IPSec sans perdre la connectivité. Si la stratégie IPSec de l'administrateur autorise la communication en texte clair, alors la connexion à distance subit un délais de trois à quatre secondes après l'interruption du service sur l'ordinateur distant. Toutefois, l'arrêt du service IPSec sur un ordinateur distant supprime les associations de sécurité IPSec utilisées par tous les autres ordinateurs actuellement connectés. Si les autres ordinateurs ne sont pas en mesure d'établir la communication en texte clair, alors les communications sont interrompues et les connexions TCP sont hors délais. Comme les ruptures soudaines des communications TCP peuvent entraîner la corruption des données de certaines applications, l'arrêt du service IPSec doit uniquement être utilisé comme dernier recours du processus de dépannage. Avant l'arrêt du service IPSec, il est préférable de préparer la mise hors tension de l'ordinateur afin que tous les utilisateurs connectés puissent mettre fin correctement aux communications. Problèmes de direction des communications L'un des scénarios de dépannage courants présente une communication réussie dans une direction mais qui échoue dans la direction opposée. L'authentification IKE requiert généralement l'authentification mutuelle des ordinateurs. Si un ordinateur ne peut pas obtenir de ticket Kerberos lorsqu'il initie le mode IKE principal pour un ordinateur distant, alors IKE échoue. Cette situation peut se produire si le client Kerberos de l'initiateur ne peut pas accéder à un contrôleur du domaine de l'ordinateur de destination. Si les ordinateurs font partie de domaines qui ne sont pas mutuellement approuvés (approbation bidirectionnelle), alors les négociations IKE en mode principal réussissent lorsqu'un seul ordinateur démarre et échoue si l'autre ordinateur démarre. De la même manière, les droits de connexion au réseau peuvent être différents sur deux ordinateurs. Il est possible que les négociations IKE en mode principal et en mode rapide échouent dans une direction pour ces raisons, mais également si les conceptions des stratégies IPSec ne sont pas compatibles. Les parefeu pour hôte qui interceptent le trafic audessus de la couche IPSec peuvent imposer la direction des connexions. Certains parefeu pour hôte interceptent le trafic sous la couche IPSec. Une fois que la communication IPSec est établie, le trafic protégé par IPSec sera vraisemblablement autorisé dans les deux directions pendant une certaine durée. Le filtrage avec état par un routeur réseau ou un parefeu peut également bloquer les actions IKE de recomposition ou le flux du trafic IPSec sans influencer les autres protocoles de diagnostic comme le protocole ICMP. Il est possible que les ports TCP et UDP ne soient pas accessibles sur un ordinateur parce qu'un service n'est pas exécuté ou parce qu'un périphérique qui fonctionne audessus de la couche IPSec (un parefeu Windows ou un routeur réseau, par exemple) bloque l'accès.
178
Suivis des réseaux et dépannage avancé du chemin d'accès au réseau Les échecs de la négociation IKE entraînent souvent l'interruption de réponse à la négociation IKE de la part de l'ordinateur qui subit l'échec ou, dans certains cas, entraînent le renvoi du dernier message de bon fonctionnement jusqu'à ce que la limite de nouvelles tentatives expire. IKE doit être capable d'envoyer des datagrammes UDP fragmentés contenant les tickets Kerberos, car ces paquets dépassent souvent l'unité maximale de transfert d'un chemin (path maximum transmission unit, PMTU) pour l'adresse IP de destination. Si la fragmentation n'est pas correctement prise en charge, de tels fragments peuvent être abandonnés par les périphériques réseau dans un chemin donné. En outre, il est possible que le réseau ne transmette pas les paquets du protocole IPSec ou les fragments des paquets IPSec correctement. L'intégration d'IPSec à TCP permet à TCP de réduire la taille des paquets afin de recevoir la surcharge des entêtes IPSec. Cependant, la négociation TCP de la taille maximale du segment (maximum segment size, MSS) lors de la liaison TCP ne prend pas en compte la surcharge IPSec. D'où le besoin croissant de recherche de l'unité PMTU ICMP sur le réseau afin de garantir que les communications TCP réussies sont protégées par IPSec. Ainsi, le dépannage des échecs de connectivité peut nécessiter les suivis des réseaux des deux côtés de la communication ou d'un seul, ainsi que les fichiers journaux des deux côtés de la communication. Les ingénieurs du support technique doivent savoir lire les fichiers du suivi réseau et comprendre la négociation IKE. Les serveurs doivent être équipés du logiciel Moniteur réseau de Windows. Le Moniteur réseau de Windows 2000 permet l'analyse d'IPSec AH et d'IKE. Windows Server 2003 ajoute la prise en charge de l'analyse IPSec ESP null, l'analyse d'ESP lorsque le chiffrement est déchargé et l'analyse de l'encapsulation UDPESP utilisée pour NAT traversal.
Jeu d'outils de dépannage Avant de commencer les opérations de dépannage, il est important d'identifier les utilitaires capables de fournir des informations en vue de faciliter le processus de dépannage. Cette section ne vise pas à dupliquer les informations disponibles dans l'aide de Windows 2000, Windows XP ou Windows Server 2003 accessible via la page Troubleshooting tools (Outils de dépannage) du site Web de Microsoft Windows Server™ 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ sag_IPSec_tools.asp. Les informations détaillées sur les outils sont uniquement fournies dans cette section pour le cas où elles ne seraient pas facilement accessibles dans la page Troubleshooting tools ou lorsqu'il est utile de disposer de résumés sur les différentes versions des systèmes d'exploitation. Composant logiciel enfichable MMC Gestion de stratégie de sécurité IP Le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP permet de créer et de gérer les stratégies IPSec locales ou les stratégies IPSec stockées dans le service d'annuaire Active Directory. Il sert également à modifier la stratégie IPSec sur les ordinateurs distants. Le composant MMC Gestion de stratégie de sécurité IP est inclus dans les systèmes d'exploitation Windows Server 2003, Windows XP, Windows 2000 Server et Windows 2000 Édition Professionnel, et il peut être utilisé pour afficher et modifier les détails de la stratégie IPSec, les filtres, les listes de filtres et les actions de filtrage IPSec, ainsi que pour attribuer ou supprimer l'attribution de stratégies IPSec. Composant logiciel enfichable MMC Moniteur de sécurité IP Le composant MMC Moniteur de sécurité IP affiche les statistiques IPSec et les associations de sécurité actives. Il permet également d'afficher des informations sur les composants IPSec suivants :
179
• le mode principal et le mode rapide IKE ; • les stratégies IPSec locales ou de domaine ; • les filtres IPSec qui s'appliquent à l'ordinateur. Bien que ce composant logiciel enfichable fasse partie des systèmes d'exploitation Windows XP et Windows Server 2003, il existe des différences dans les fonctionnalités et les interfaces de ces deux versions. En outre, la version Windows Server 2003 possède les fonctions supplémentaires suivantes :
• Windows Server 2003 propose des détails sur la stratégie IPSec active : nom, description, date de dernière modification, emplacement, chemin, UO et nom d'objet de stratégie de groupe. Pour obtenir ces informations sous Windows XP, vous devez utiliser l'utilitaire de ligne de commande IPSeccmd (décrit ultérieurement).
• Des statistiques sont fournies séparément pour le mode principal et le mode rapide dans des dossiers situés sous chaque mode, et non dans un seul affichage.
Remarque : sous Windows 2000, l'outil Moniteur de sécurité IP est un programme exécutable indépendant (IPSecmon.exe) disposant de sa propre interface graphique utilisateur. Vous trouverez des informations sur cet outil et son utilisation dans l'article 257225 Basic IPSec troubleshooting in Microsoft Windows 2000 Server (Résolution élémentaire des problèmes liés à IPSec sous Windows 2000) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/kb/257225. Une mise à jour de ce composant logiciel enfichable est disponible pour Windows XP en tant que partie de la mise à jour décrite dans l'article 818043 L2TP/IPSec NATT update for Windows XP and Windows 2000 (Mise à jour NATT pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/? kbid=818043. Grâce à cette mise à jour, il est possible d'afficher les ordinateurs Windows Server 2003 à partir de Windows XP. Le composant logiciel enfichable MMC Moniteur de sécurité IP mis à jour peut également lire les fonctions avancées créées sous Windows Server 2003 (par exemple, les informations sur le groupe 2048 DiffieHellman, les mappages de certificats et les filtres dynamiques), mais il ne peut pas les modifier. Pour plus d’informations, reportezvous à l’article de la Base de connaissances référencé. Netsh Netsh est un utilitaire de script de ligne de commande qui vous permet d'afficher ou de modifier la configuration réseau. Vous pouvez l'utiliser localement ou à distance. Netsh est disponible sous Windows 2000, Windows XP et Windows Server 2003. De plus, la version Windows Server 2003 a été améliorée afin de fournir des fonctions de gestion et de diagnostic IPSec. Les commandes Netsh pour IPSec sont uniquement disponibles pour Windows Server 2003 ; elles remplacent les commandes Ipseccmd de Windows XP et Netdiag de Windows 2000. Ipseccmd Vous pouvez utiliser l'utilitaire de ligne de commande Ipseccmd à la place du composant logiciel enfichable MMC Stratégie de sécurité IP. Il est uniquement disponible pour Windows XP. Windows XP Service Pack 2 fournit des fonctionnalités supplémentaires pour cet outil. Ipseccmd doit être installé à partir du dossier Outils de support du CD d'installation de Windows XP. Une version mise à jour est disponible avec Windows XP SP2 et doit être installée à partir du dossier Outils de support du CD d'installation de Windows XP SP2. La version précédant la version SP2 ne
180
fonctionne pas sur les ordinateurs mis à jour, et la version mise à jour ne fonctionne pas sur les ordinateurs antérieurs à SP2. L'utilitaire Ipseccmd mis à jour est doté des fonctionnalités suivantes :
• il active et désactive la journalisation d'IKE de façon dynamique ; • il affiche des informations sur une stratégie actuellement attribuée ; • il vous permet de créer une stratégie IPSec de longue durée ; • il peut afficher la stratégie IPSec actuellement attribuée et active. Pour plus d'informations sur l'utilitaire Ipseccmd mis à jour, reportezvous à l'article 818043 (cité plus haut) de la Base de connaissances Microsoft. Pour afficher tous les paramètres de la stratégie IPSec et les statistiques de diagnostic, utilisez la syntaxe suivante : ipseccmd show all Pour afficher les stratégies IPSec actuellement attribuées et actives (locales ou placées dans Active Directory), utilisez la syntaxe suivante : ipseccmd show gpo Remarque : cette commande fonctionne uniquement avec la version SP2. Pour activer la journalisation du débogage sur Windows XP SP2, utilisez la syntaxe suivante : ipseccmd set logike (le redémarrage du service IPSec n'est pas requis) Pour désactiver la journalisation du débogage, utilisez la syntaxe suivante : ipseccmd set dontlogike (le redémarrage du service IPSec n'est pas requis) Remarque : seul Ipseccmd vous permet d'activer la journalisation Oakley sous Windows XP SP2 ; les commandes cidessus ne fonctionnent pas sur des ordinateurs antérieurs à la version SP2. Netdiag Netdiag est un utilitaire de ligne de commande d'exécution de diagnostics utilisé pour tester la connectivité et la configuration réseau, y compris les informations IPSec. Netdiag est disponible avec Windows 2000, Windows XP et Windows Server 2003, mais sa fonctionnalité change en fonction de la version du système d'exploitation. Sous Windows Server 2003, Netdiag n'inclut plus la fonctionnalité IPSec, mais vous pouvez utiliser le contexte netsh ipsec à la place et utiliser Netsh pour les tests réseau de base. Vous devez vous assurer que vous utilisez la version la plus récente de votre système d'exploitation en procédant à une vérification via le Centre de téléchargement Microsoft. Netdiag doit être installé à partir du dossier Outils de support du CD du système d'exploitation utilisé. Remarque : Netdiag n'est pas mis à jour lors de l'installation de Windows XP SP2. La pertinence du dépannage d'IPSec par Netdiag dépend de la version du système d'exploitation. Les différences en termes de fonctionnalités sont décrites dans le tableau suivant.
181
Tableau 7.1: Fonctionnalité Netdiag IPSec sous différents systèmes d'exploitation Commande
Description
Windows2000 ?
WindowsXP ?
Windows2003 ?
netdiag /test:ipsec
Affiche la stratégie IPSec attribuée
Oui
Oui
Non**
netdiag /test:ipsec /debug
Affiche la stratégie IPSec active, les filtres et les statistiques du mode rapide
Oui
Oui*
Non**
netdiag /test:ipsec /v
Affiche la stratégie IPSec active, les filtres et les statistiques du mode principal
Oui
Oui*
Non**
* Fournit des diagnostics réseau, mais affiche le nom de la stratégie IPSec uniquement. L'utilisation d'Ipseccmd permet d'obtenir des informations IPSec supplémentaires. ** Fournit des diagnostics réseau, mais n'affiche aucune information IPSec. Vous devez utiliser la syntaxe suivante : netsh ipsec dynamic show all. Autres outils utiles à la prise en charge d'IPSec En plus des outils spécifiques à IPSec cités précédemment, le tableau cidessous répertorie d'autres outils qui peuvent se révéler utiles et qui doivent être inclus à votre jeu d'outils de dépannage de niveau 2.
Tableau 7.2 : Outils divers permettant le dépannage d'IPSec Outil
Systèmes d'exploitation pris en charge
Obtention
Rôle
Informations complémentaires
Ipsecpol.exe
Windows 2000 uniquement
Kit de ressources de Windows 2000
Configure les stratégies IPSec dans l'annuaire ou un registre
Aide contenue dans les outils du kit de ressources de Windows 2000
Gpresult
Windows 2000, Windows Server 2003, Windows XP
Kit de ressources Windows 2000 ; pour Windows XP et Windows Server 2003, Gpresult fait partie du système d'exploitation
Indique quand la stratégie de groupe a été appliquée pour la dernière fois
Aide contenue dans les outils du kit de ressources de Windows 2000, Aide de Windows XP et de Windows Server 20 03
Composant logiciel
Windows
Inclus dans le
Affiche la stratégie
Windows
182
enfichable MMC Jeu de stratégie résultant (Resultant Set of Policy, RSoP)
Server 2003, Windows XP
système d'exploitation
IPSec d'un ordinateur ou des membres d'un conteneur de stratégie de groupe
Server 2003
Srvinfo
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows 2000 et Windows Server 2003
Fournit des informations sur les services, pilotes de périphériques et protocoles
Aide contenue dans les outils du kit de ressources de Windows Server 2003
PortQry
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows Server 2003
Génère des rapports sur l'état des ports réseau
http://support.micro soft.com/kb/310099
NLTest
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Outils de support
Teste les relations d'approbation et les canaux Netlogon sécurisés
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Klist
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows 2000 et Windows Server 2003
Génère des rapports sur les tickets Kerberos
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Pathping
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Inclus dans le système d'exploitation
Teste les chemins d'accès et la connectivité réseau
Aide de Windows
LDP
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Outils de support
Teste le client LDAP pour Active Directory
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Utilisation d'outils ICMP avec IPSec Les outils Ping, Pathping et Tracert de Windows XP et de Windows Server 2003 reconnaissent IPSec, mais ils peuvent ne pas fonctionner correctement tant que des associations de sécurité n'ont pas été établies (si la communication en texte clair est autorisée). Si des associations de sécurité IPSec étaient négociées avec succès pour encapsuler le trafic ICMP utilisé par ces utilitaires, elles ne seraient pas en mesure de détecter des sauts (routeur) intermédiaires entre le client et la destination. Les calculs relatifs à la perte de paquets concernant l'outil Ping peuvent indiquer les paquets perdus pendant la durée requise par IKE pour négocier avec succès une association de sécurité IPSec avec la cible. Les calculs sur la perte de paquets pour chaque saut intermédiaire ne sont pas disponibles lorsque le trafic ICMP est encapsulé par IPSec. Ces utilitaires ICMP sont conçus pour détecter si le pilote IPSec correspondait à un filtre IPSec pour le paquet de demande d'écho ICMP sortant et nécessitait ainsi une négociation de sécurité IKE. Lorsque cela se produit, le message « Négociation de la sécurité IP » est affiché par l'utilitaire. Un bogue
183
connu de Windows 2000 empêche l'utilitaire Ping d'attendre autant que nécessaire avant de tenter une nouvelle demande d'écho, ce qui signifie que la commande peut s'achever immédiatement au lieu d'attendre trois secondes pour que la SA logicielle soit établie. L'utilitaire Ping de Windows XP et de Windows Server 2003 attend le temps nécessaire avant d'envoyer la demande d'écho suivante. Le message « Négociation de la sécurité IP » ne s'affiche pas lorsque :
• le pilote IPSec abandonne le paquet ICMP sortant en raison d'un filtre bloquant ; • le pilote IPSec autorise le transfert du paquet ICMP non sécurisé en raison d'un filtre d'autorisation ou d'une SA logicielle ;
• le pilote IPSec ne détecte pas le paquet sortant (par exemple, s'il a été abandonné par les couches situées audessus du pilote).
Remarque : certains outils utilisant ICMP ne sont pas capables de détecter qu'IPSec négocie la sécurité et peuvent produire des résultats incohérents ou erronés.
Processus de dépannage d'IPSec Si le support de niveau 1 a clairement identifié un problème, le support de niveau 2 sera en mesure de trouver rapidement la procédure de dépannage appropriée dans les sections suivantes. Dans ce modèle, le support de niveau 1 traite principalement les problèmes d'accès du client. En général, les propriétaires administratifs de serveurs sont capables d'effectuer des diagnostics de connectivité réseau de base et peuvent ignorer le niveau 1. Cependant, chaque entreprise doit ajuster le modèle en fonction de son environnement de support. Le support de niveau 2 doit se concentrer sur l'identification du point d'échec de la communication, puis rechercher des causes associées dans l'architecture du système. Si votre entreprise utilise les scripts fournis dans le cadre du processus de dépannage, vous aurez accès à un certain nombre de fichiers journaux au format texte qui vous aideront à diagnostiquer le problème. Le tableau suivant présente la description des fichiers générés par le script. Tableau 7.3 : Fichiers générés par le script IPSec_Debug.vbs Nom de fichier
Description
_FileVer.txt
Liste des versions de fichier de plusieurs DLL associées à IPSec.
_gpresult.txt
Résultat de la commande gpresult.
_ipsec_547_events.txt
Affiche le résultat de n'importe quelle erreur IPSEC 547 dans le journal des événements de sécurité.
_ipsec_policy_version.txt
Résultat du script Detect_IPSec_Policy.vbs. Affiche la version de la stratégie actuelle et indique si elle correspond à la stratégie Active Directory.
_ipseccmd_show_all.txt
Uniquement pour Windows XP. Ce fichier capture le résultat de la commande ipseccmd.
_kerberos_events.txt
Affiche le résultat de n'importe quel événement Kerberos dans le journal des événements système.
_klist_purge_mt.txt
Résultat de KList lors de la purge des tickets d'ordinateur.
184
_lsass.log
Copie du fichier lsass.log, s'il est présent.
_netdiag.txt
Résultat de l'exécution de netdiag.
_netsh_show_all.txt
Uniquement sur les platesformes serveur. Résultat de l'exécution de la commande show all dans netsh.
_netsh_show_gpo.txt
Uniquement sur les platesformes serveur. Résultat de l'exécution de la commande show gpo dans netsh.
_oakley.log
Copie du fichier Oakley.log, s'il est présent.
_OSInfo.txt
Sortie des informations du système d'exploitation actuel.
_RegDefault.txt
Résultat des valeurs de la clé de registre d'origine avant leur modification. Peut être utilisé pour rétablir manuellement les valeurs précédentes du registre si le script échoue.
_userenv.log
Copie du fichier userenv.log, s'il est présent.
_<SrvName>_netview.txt
Résultat de l'exécution de la commande net view sur.
_<SrvName>_ping.txt
Résultat de l'exécution de la commande ping sur.
_winlogon.log
Copie du fichier winlogon.log, s'il est présent.
Étant donné qu'il existe plusieurs points d'échec potentiels, cette section traite chaque composant architectural dans l'ordre, à commencer par la connectivité réseau. Les procédures définies vous aideront à effectuer les tâches suivantes :
• vérifier la configuration du réseau IP, la connectivité réseau et le service avec les contrôleurs de domaine ainsi que la connectivité du chemin client/serveur pour les protocoles liés à IPSec ;
• vérifier que les stratégies de groupe et IPSec sont correctement appliquées sur le client et le serveur ;
• identifier les problèmes liés à la négociation IKE et à la communication protégée par IPSec ; • identifier la cause d'un problème en vue du transfert vers le support de niveau 3, si nécessaire. Prenons l'exemple suivant : un client indique qu'il est capable d'exécuter une commande ping sur un serveur mais qu'il ne peut pas se connecter à un partage de fichiers sur ce serveur. Il s'agit du seul serveur auquel le client ne peut pas accéder. Une recherche rapide dans le journal de sécurité de l'événement 547 (échec de la négociation IKE) contenant l'adresse IP du serveur indique que le client a une stratégie IPSec et qu'IKE est en cours d'initialisation. Si l'événement 547 indique que le délai de négociation IKE du client a expiré, cela signifie que la négociation IKE du serveur a certainement échoué. Le support de niveau 2 doit alors effectuer des recherches dans la base de données d'événements MOM relatives aux événements 547 collectés à partir du serveur spécifié, lesquels contiennent l'adresse IP du client actuel.
Avertissement Démarrage et arrêt du service IPSec Le document Windows Server 2003 TCP/IP Troubleshooting (Dépannage de TCP/IP sous Windows Server 2003) ainsi que les autres références expliquent comment savoir si IPSec est responsable d'un problème de connectivité en arrêtant le service IPSec. Cet arrêt interrompt le filtrage IPSec sur l'ordinateur, désactive la protection fournie par IPSec, expose l'ordinateur à un accès réseau non approuvé et désactive la protection des paquets. En outre, dans un environnement
185
d'isolation de domaines, le trafic TCP et UDP non protégé par IPSec sera abandonné par les autres membres du domaine. Si IPSec est désactivé sur un ordinateur, cela entraînera des interruptions de connectivité avec les ordinateurs distants disposant actuellement d'associations de sécurité IPSec. Lorsque le service IPSec est interrompu, IKE envoie des notifications de suppression pour toutes les associations de sécurité IPSec et pour l'association de sécurité IKE à tous les ordinateurs connectés. Les ordinateurs distants disposant d'une stratégie IPSec autorisant les communications en texte clair rétablissent la connectivité après un délai de trois secondes. Les ordinateurs distants disposant d'une stratégie IPSec n'autorisant pas les communications en texte clair ne seront pas en mesure de communiquer. C'est pourquoi il est important d'utiliser les techniques citées dans les sections suivantes pour résoudre les problèmes d'isolation sans interrompre le service IPSec. Le service IPSec doit être désactivé uniquement en dernier recours pour éliminer les problèmes liés à IPSec dans les situations suivantes :
• environnements de trafic de diffusion et de multidiffusion ; • connexions à des ordinateurs distants ne nécessitant pas IPSec pour un accès entrant (par exemple, les ordinateurs membres de la liste d'exemption).
Sous Windows 2000, l'arrêt du service IPSec dissocie le pilote IPSec de TCP/IP et décharge le pilote IPSec de la mémoire. Sous Windows XP et Windows Server 2003, l'arrêt du service IPSec supprime tous les filtres du pilote IPSec et définit le mode du pilote sur AUTORISER. Le pilote IPSec n'est pas déchargé de la mémoire. Pour éviter le chargement du pilote IPSec, il faut que le service IPSec soit désactivé et que l'ordinateur ait redémarré. Sous Windows 2000 et Windows XP SP1, la journalisation d'IKE dans le fichier Oakley.log requiert le redémarrage du service IPSec. L'arrêt du service n'est pas nécessaire pour activer et désactiver la journalisation d'IKE dans le fichier Oakley.log sous Windows XP SP2 et Windows Server 2003. La toute dernière mise à jour d'Ipseccmd pour Windows XP SP2 propose la syntaxe ipseccmd set logike et ipseccmd set dontlogike qui permettent d'activer/désactiver la journalisation d'IKE dans le fichier Oakley.log. La journalisation d'IKE sous Windows Server 2003 peut être activée dynamiquement par l'utilisation des commandes Netsh décrites dans l'aide en ligne.
Vérification de la connectivité réseau Si le support de niveau 1 identifie d'éventuels problèmes de connectivité réseau, alors la première étape consiste à déterminer si une connectivité réseau de base existe. Pour ce faire, vous devez vérifier que la configuration IP appropriée est utilisée, que le chemin réseau entre l'ordinateur initiateur et l'ordinateur répondant est valide et que les services de résolution de noms fonctionnent. Problèmes de configuration de l'adresse IP du réseau Si la configuration IP dynamique n'a pas réussi ou si les communications sont bloquées après le redémarrage de l'ordinateur (ou dans des conditions normales d'utilisation), le problème peut être dû à IPSec. Sous Windows Server 2003, ce type de problème peut être lié au comportement à tolérance de pannes d'IPSec (par exemple, si l'ordinateur est démarré en mode sans échec ou en mode de récupération Active Directory). Remarque : pour obtenir des détails sur le comportement à tolérance de pannes de Windows Server 2003, reportezvous à la section Understanding IPSec Protection During Computer Startup (Comprendre la protection IPSec au démarrage de l'ordinateur) du module Deploying
186
IPSec (Déploiement d'IPSec) du kit de déploiement de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en us/dnsbj_ips.asp. Windows Server 2003 a recours au comportement à tolérance de pannes si le service IPSec ne peut pas démarrer correctement ou s'il ne peut pas appliquer la stratégie attribuée. Le comportement à tolérance de pannes s'applique uniquement lorsqu'une stratégie IPSec est attribuée à l'ordinateur et que le service IPSec n'est pas désactivé. Cela signifie que la connectivité vers ou à partir d'un ordinateur pourrait échouer dans des conditions normales car le pilote IPSec n'applique pas la stratégie IPSec basée sur domaine. Une fois que vous avez déterminé quel trafic est autorisé et bloqué par le mode d'amorçage et les configurations persistantes, un échec de communication peut être facile à expliquer. Pour obtenir d'autres informations ou des informations complémentaires, vous pouvez interroger l'état actuel à partir de la ligne de commande à l'aide de la syntaxe suivante : netsh ipsec dynamic show config Sous Windows Server 2003, le pilote IPSec est chargé au démarrage de l'ordinateur avec le pilote TCP/IP. Par conséquent, pour supprimer le comportement à tolérance de pannes du pilote IPSec, vous devez désactiver le service IPSec et redémarrer l'ordinateur. Le chapitre cité plus haut qui est consacré au déploiement d'IPSec présente la configuration recommandée des exemptions d'amorçage afin d'exempter les connexions RDP (Remote Desktop Protocol, protocole bureau distant) entrantes, ce qui permet de garantir que l'accès distant au serveur est disponible lorsque tout autre trafic est bloqué. Dans une solution d'isolation de serveurs et de domaines, le trafic de diffusion et le trafic vers les serveurs DHCP est exempt pour garantir que la configuration IP dynamique fonctionne correctement. Cependant, la liste d'exemption doit être mise à jour manuellement et peut devenir obsolète. Si un ordinateur ne peut pas obtenir de configuration DHCP correcte (par exemple, s'il utilise une adresse IP de configuration automatique 169.254.x.x) ou s'il rencontre des problèmes de renouvellement de bail, vous devez alors étudier la stratégie IPSec pour déterminer les exemptions appropriées. Lorsque le service IPSec est en cours d'exécution, utilisez la commande Ipconfig pour confirmer qu'il n'y a aucun problème d'obtention d'adresse :
• Pour les clients DHCP, ouvrez une fenêtre de commande et tapez ipconfig /release suivi de ipconfig /renew.
Si les problèmes de configuration d'adresses se produisent uniquement au démarrage de l'ordinateur sous Windows XP SP2 et Windows Server 2003, la configuration des exemptions (exemptions par défaut et exemptions d'amorçage par défaut) doit être examinée. Problèmes de résolution de noms La conception de stratégie IPSec utilisée dans les scénarios d'isolation de serveurs et de domaines ne doit pas interférer avec les procédures types utilisées pour déterminer si la résolution de noms fonctionne. Par exemple, dans le scénario Woodgrove Bank, la conception de stratégie IPSec exempt tout le trafic vers les serveurs DNS et WINS. Toutefois, il est possible que les serveurs DNS et WINS soient configurés pour ne pas répondre aux requêtes Ping. Répondez aux questions suivantes pour confirmer que la résolution de noms fonctionne correctement lorsque le service IPSec est en cours d'exécution :
• Le client peutil envoyer une requête ping à l'adresse IP du serveur DNS indiquée dans sa configuration IP ?
• La commande nslookup permetelle de trouver un serveur DNS ?
187
• Le client peutil envoyer une requête ping au nom DNS complet de l'ordinateur cible ? • Le client peutil envoyer une requête ping au nom DNS ou NetBIOS abrégé de l'ordinateur cible ? À l'origine des problèmes potentiels de résolution de noms figurent la configuration incorrecte et l'activation du fichier HOSTS, la configuration incorrecte de l'entrée du serveur DNS dans les propriétés IP, des enregistrements DNS incorrects, des problèmes de mise à jour des fichiers de zone, des problèmes de réplication Active Directory, la communication en texte clair utilisée pour les serveurs DNS et des problèmes de mise à jour automatique de DHCP. Les raisons possibles des échecs de la résolution de noms NetBIOS sont la configuration incorrecte et l'activation du fichier LMHOSTS, la configuration incorrecte de l'entrée du serveur WINS dans les propriétés IP, l'indisponibilité du serveur WINS, l'enregistrement WINS incorrect, des problèmes de réplication WINS, des échecs du proxy WINS et des délais d'expiration réseau pour le serveur WINS. Pour consulter des procédures d'aide au dépannage du DNS intégré à Active Directory, reportezvous à la page Troubleshooting Active Directory Related DNS Problems (Dépannage d'Active Directory Problèmes DNS connexes) sur le site de Microsoft.com à l'adresse www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsg uide/part1/adogd10.mspx. Certains environnements exigeant une sécurité élevée peuvent nécessiter la protection des serveurs DNS et WINS par IPSec, ce qui peut entraîner des problèmes de résolution de noms. Par exemple, si le DNS est intégré à Active Directory et s'il existe des filtres dupliqués pour la même adresse IP dans la stratégie IPSec, un filtre peut négocier la sécurité pour le serveur DNS et l'autre exempter les contrôleurs de domaine. Pour plus d'informations, reportezvous à la section Dépannage de la stratégie IPSec plus loin dans ce chapitre. Si le problème de résolution de noms persiste, vous pouvez obtenir la liste des filtres de l'initiateur et vérifier s'il existe des filtres dupliqués. Vous pouvez utiliser les options de ligne de commande suivantes pour afficher les listes de filtres pour cette tâche : Ipseccmd show filters Netsh ipsec static show all Si le problème de résolution de noms persiste, arrêtez brièvement le service IPSec (si possible) lorsque les tests sur la résolution de noms sont répétés. Si les tests de résolution de noms échouent uniquement lorsque le service IPSec est en cours d'exécution, vous devez continuer vos recherches pour savoir quelle stratégie IPSec est appliquée (voir les explications plus loin dans cette section). Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine Étant donné que la transmission de la stratégie IPSec, l'authentification IKE et les protocoles de niveau supérieur dépendent de l'accès aux contrôleurs de domaine, des tests de connectivité réseau et de bon fonctionnement des services d'authentification doivent être réalisés avant les étapes de dépannage d'IPSec spécifiques (voir la section suivante). Dans le scénario Woodgrove Bank, la conception de la stratégie IPSec exempt tout le trafic vers tous les contrôleurs de domaine ; les tests de connectivité réseau pour les contrôleurs de domaine ne devraient donc pas être affectés par IPSec. Toutefois, la liste des adresses IP du contrôleur de domaine de la liste d'exemption doit être mise à jour manuellement. Si la négociation IKE est visible pour une adresse IP de contrôleur de domaine, alors la stratégie IPSec peut ne pas être correctement attribuée ou ne pas être mise à jour. Pour dépanner l'accès aux services réseau dans Active Directory
188
• Assurezvous que le client peut envoyer une requête ping à chaque adresse IP du contrôleur de domaine. Si ce n'est pas le cas, reportezvous aux étapes de connectivité réseau cidessus.
• Identifiez les adresses IP utilisées pour les contrôleurs du membre du domaine. Utilisez la
commande nslookup <nom domaine> pour obtenir la liste complète des adresses IP. Un scénario d'isolation de serveurs et de domaines doit prévoir un filtre spécifique au mode rapide avec une stratégie de négociation (action de filtrage) autoriser pour chacune de ces adresses.
• Utilisez l'outil portqry.exe version 2.0 ou ultérieure ou l'outil PortQueryUI pour tester l'accès aux
ports UDP, LDAP et RPC du contrôleur de domaine. Les messages du protocole UDP utilisés par l'outil portqry ne requièrent généralement pas l'authentification du protocole de niveau supérieur ; ils peuvent donc vérifier la disponibilité du service même si l'authentification n'est pas disponible. Ces étapes sont expliquées à la page HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues (COMMENT FAIRE : Utilisation du Portqry pour la résolution des problèmes de connectivité de Active Directory) , disponible à l'adresse http://support.microsoft.com/? kbid=816103.
• Lorsque vous êtes connecté au réseau interne, utilisez la commande netdiag /v >outputfile.txt pour
effectuer divers tests de connectivité liés à DNS et au contrôleur de domaine. L'utilitaire Netdiag utilise plusieurs connexions réseau et protocoles pour réaliser les tests ; si l'une de ces connexions déclenche des négociations IKE et que l'authentification échoue parce que IKE ne réussit pas à localiser un contrôleur de domaine pour l'authentification IKE, l'erreur de l'événement 547 peut être consignée dans le journal de sécurité.
L'outil de support klist.exe de Windows peut être utilisé pour vérifier que la connexion et l'authentification Kerberos ont réussi. L'outil Klist doit être exécuté dans le contexte du système local pour que vous puissiez afficher les tickets Kerberos de l'ordinateur. Pour afficher les tickets de service Kerberos pour l'utilisateur de domaine connecté
• Ouvrez une invite de commande et tapez ce qui suit : klist tickets Pour afficher les tickets de l'ordinateur du domaine
1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.
2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit : at 4:38pm /interactive cmd /k klist tickets Notez que la barre de titre de la fenêtre de commande contient C:\Windows\System32\svchost.exe. Bien que les tickets Kerberos contiennent des informations sur le groupe de l'utilisateur ou de l'ordinateur, ces informations sont chiffrées afin qu'il soit impossible d'afficher les groupes. Par conséquent, les appartenances aux groupes doivent être confirmées manuellement par l'inspection des appartenances de groupe dans le service Active Directory. Pour vous assurer que les ordinateurs possèdent les informations d'appartenance aux groupes les plus récentes sur leurs tickets Kerberos, utilisez klist afin de purger les tickets Kerberos actuels. Lors de la nouvelle tentative de négociation IKE, les nouveaux tickets Kerberos seront obtenus automatiquement. Pour purger les tickets Kerberos d'un ordinateur (Les étapes 1 à 4 doivent être réalisées dans le contexte d'un système local.)
189
1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.
2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit : at 4:38pm /interactive cmd
3. Tapez klist purge et appuyez sur O pour chaque type de ticket afin de supprimer tous les tickets Kerberos.
4. Tapez klist tickets pour confirmer qu'il n'existe aucun ticket. 5. Si cette procédure fait partie du dépannage de l'échec des négociations IKE, attendez une minute pour que le délai de négociation IKE soit écoulé puis reéssayez d'accéder au serveur cible avec l'application. Les nouvelles négociations IKE en mode principal nécessitent de nouveaux tickets d'attribution de tickets (ticketgranting ticket, TGT) Kerberos et des tickets de service pour l'ordinateur de destination, lequel disposera des informations les plus récentes sur les groupes. Veillez à ne pas exécuter l'application à partir de la fenêtre de commande exécutée dans le contexte du système local. Vous trouverez des procédures détaillées supplémentaires sur le dépannage de Kerberos dans les Livres blancs suivants : •Troubleshooting Kerberos Errors (Dépannage des erreurs Kerberos) à l'adresse www.microsoft.com/downloads/details.aspx? FamilyID=7dfeb015604347db8238dc7af89c93f1&displaylang=en •Troubleshooting Kerberos Delegation (Dépannage de la délégation Kerberos) à l'adresse www.microsoft.com/downloads/details.aspx? FamilyID=99b0f94fe28a4726bffe2f64ae2f59a2&displaylang=en
Vérification des autorisations et de l'intégrité de la stratégie IPSec dans Active Directory Il peut s'avérer nécessaire de vérifier les informations relatives au conteneur de la stratégie IPSec dans le service Active Directory. La procédure suivante utilise l'outil de support ldp.exe. Pour vérifier les informations sur le conteneur de la stratégie IPSec
1. Cliquez sur Démarrer, Exécuter, tapez ldp.exe et appuyez sur ENTRÉE. 2. Sélectionnez Connexion, puis Connecter. Indiquez le nom du domaine cible. 3. Sélectionnez Connexion, puis Liaison. Indiquez les informations de connexion pour le domaine cible.
4. Sélectionnez Afficher, puis Arborescence. Vous pouvez soit n'indiquer aucun nom de domaine de base et rechercher le conteneur de la stratégie IPSec, soit spécifier le nom du domaine LDAP pour le conteneur de la stratégie IPSec comme emplacement de base.
5. Cliquez sur le symbole + en regard du nœud du conteneur dans l'arborescence. Si vous possédez des autorisations en lecture sur le conteneur, tous les objets de la stratégie IPSec qu'il contient s'affichent. Remarque : selon la configuration des autorisations, il est possible que certains utilisateurs de domaine ne disposent pas des autorisations en lecture. Pour plus d'informations, reportezvous à l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003 (Autorisations de stratégie IPSec dans Windows 2000 et Windows Server 2003) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=329194. 190
Pour effectuer un dépannage avancé des problèmes d'extraction et de corruption de la stratégie, vous pouvez utiliser ldp.exe pour inspecter manuellement le contenu du conteneur IPSec et les relations existant entre les objets de la stratégie IPSec. Windows 2000, Windows XP et Windows Server 2003 utilisent le même schéma d'annuaire de base pour la stratégie IPSec, affiché dans le diagramme de la structure de la stratégie IPSec de la référence technique How IPSec Works (Fonctionnement d'IPSec) de Windows Server 2003 disponible à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_ipsec_how.asp. Le tableau suivant décrit les relations existant entre le nom de l'objet Active Directory et le nom du composant de la stratégie IPSec configuré dans le composant logiciel enfichable MMC Gestion de stratégie IPSec : Tableau 7.4 : Association entre le nom du composant de la stratégie IPSec et le nom de l'objet Active Directory Nom du composant de la stratégie IPSec
Nom de l'objet Active Directory
Stratégie de sécurité IP
ipsecPolicy{GUID}
Méthodes de sécurité Échange de clés IKE
ipsecISAKMPPolicy{GUID}
Règle IPSec
ipsecNFA{GUID}
Liste de filtres IPSec
ipsecFilter{GUID}
Action de filtrage IPSec
ipsecNegotiationPolicy{GUID}
L'utilitaire Ldp.exe permet de savoir à quel moment les objets de la stratégie IPSec ont été modifiés pour la dernière fois, ce qui peut aider à résoudre les problèmes de version d'objet et de réplication. Vous pouvez le lancer depuis une fenêtre de commande dans le contexte du système local afin de résoudre les problèmes d'autorisation en lecture du service IPSec. Attention : il est fortement recommandé d'attribuer les mêmes permissions à tous les objets du conteneur de sécurité IP. Microsoft vous déconseille d'attribuer des autorisations aux objets de la stratégie IPSec sur une base individuelle. Pour contrôler l'accès en lecture et en modification de la stratégie IPSec, il est nécessaire de gérer les autorisations dans le conteneur IPSec, comme l'explique l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003 de la Base de connaissances à l'adresse http://support.microsoft.com/?kbid=329194. La corruption de la stratégie de sécurité IP est la cause la plus courante à l'origine de situations dans lesquelles un objet IPSec contient une référence DN (Domain Name, nom de domaine) à un objet qui n'existe plus. Cependant, la corruption peut également se produire si des caractères de contrôle deviennent partie intégrante du nom d'un objet, si des objets individuels ne peuvent pas être lus en raison de problèmes d'autorisation ou si des noms identiques d'objets entraînent une conception inadéquate de la stratégie IPSec (par exemple, deux versions de la même liste de filtres). Reportez vous à la section suivante sur le dépannage du service IPSec pour plus d'informations sur le dépannage de la corruption de la stratégie IPSec. Remarque : les détails de conception de ces objets sont considérés comme une structure de données interne privée et ne sont pas publiés par Microsoft. Des différences existent au niveau du format de ces objets dans les diverses versions de Windows ; Microsoft est susceptible d'apporter des modifications à ces formats à tout moment. C'est pourquoi ces objets doivent uniquement être gérés à l'aide du composant logiciel enfichable MMC Gestion de stratégie IPSec et des outils de ligne de commande disponibles sur chaque plateforme. Vous ne devez supprimer des objets au moyen de LDP qu'en dernier recours, lorsque la corruption empêche l'utilisation du composant MMC Gestion de stratégie IPSec ou des outils de ligne de commande.
191
Connectivité du chemin réseau Microsoft vous recommande d'exempter le protocole ICMP dans le cadre de solutions d'isolation de serveurs et de domaines. Il existe plusieurs raisons à cette recommandation, notamment la nécessité d'utiliser ICMP pour tester le chemin réseau à l'aide des utilitaires Ping, Pathping et Tracert, par exemple. Ces utilitaires doivent par conséquent fonctionner correctement et ne pas afficher le message « Négociation de la sécurité IP ». Si ce message s'affiche, cela signifie qu'une stratégie IPSec inappropriée a peutêtre été attribuée. Pour déterminer si le problème est lié à une configuration réseau de base ou à la connectivité du chemin
• Le client peutil envoyer une requête ping à sa propre adresse IP ou à l'adresse de boucle
locale 127.0.0.1 ? Si la réponse est non, cela peut signifier qu'il existe un problème de configuration TCP/IP, qu'un parefeu tiers a été installé, que l'utilitaire Ping est manquant ou que la configuration IP n'est pas valide. Utilisez d'autres procédures de dépannage de la configuration TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping à la passerelle par défaut affichée dans sa
configuration IP ? Si la réponse est non, cela peut signifier que la configuration IP du client est inopérante, que l'interface locale n'est pas connectée ou que sa connectivité est limitée, que des filtres réseau ou locaux bloquent le trafic ou que le chemin réseau vers la passerelle par défaut est interrompu. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping aux serveurs DNS affichés dans sa configuration IP ? Si la réponse est non, cela peut signifier que les serveurs DNS ne s'autorisent pas à recevoir des messages de demande d'écho ICMP, que la stratégie IPSec n'exempt pas les adresses IP du serveur DNS appropriées ou que vous êtes en présence de l'un des problèmes mentionnés précédemment. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping à une adresse IP de la liste d'exemption, un contrôleur de domaine, par exemple ? Si la réponse est non, cela signifie que le problème n'est pas lié à IPSec ou que IPSec ne possède pas de filtre pour cette adresse IP exemptée. Cette dernière hypothèse peut être confirmée par l'examen de la configuration des filtres. Reportezvous à la section sur la stratégie IPSec plus loin dans ce chapitre.
• Le client peutil envoyer une requête ping à l'adresse IP de la destination cible ? Si la réponse est oui, alors une connectivité réseau de base existe entre le client et la cible sans IPSec. Si la réponse est non, exécutez l'outil tracert sur l'adresse IP de la cible et d'autres adresses IP de destination pour déterminer le degré de validité du réseau. Utilisez d'autres procédures de dépannage du réseau et du protocole TCP/IP pour résoudre le problème.
Les tests de connectivité du chemin réussissent peutêtre pour ICMP, sauf lors de l'utilisation des protocoles IKE ou IPSec. En particulier, la charge d'IPSec pour les paquets d'authentification en mode principal IKE contenant le ticket Kerberos est souvent plus importante que l'unité PMTU pour l'adresse IP de destination, qui requiert une fragmentation. Ainsi, les parefeu pour hôte, le filtrage des routeurs, les parefeu pour réseau et les filtres de l'hôte cible doivent être ouverts aux protocoles et ports suivants et prendre en charge la fragmentation :
• IKE. Port source UDP 500, port de destination 500 et fragments • IKE/IPSec NATT. Port source UDP 4500, port de destination 4500 • IPSec ESP. Protocole IP 50 et fragments
192
• IPSec AH. Protocole IP 51 et fragments Le filtrage avec état du chemin n'est pas recommandé Le filtrage avec état peut entraîner des problèmes de connectivité pour IKE, AH et ESP car l'état est généralement basé sur des délais d'expiration d'activité. Les périphériques ne peuvent pas inspecter le trafic IKE pour savoir quand les associations de sécurité IPSec sont supprimées car ces messages sont chiffrés par IKE. Par définition, IKE est requis pour permettre la recomposition dans l'une ou l'autre direction, ce qui signifie que les messages de suppression peuvent être envoyés dans l'une ou l'autre direction. Si un message de suppression n'est pas reçu par l'une des extrémités, cette dernière risque de penser qu'une association de sécurité IPSec existe toujours alors que son homologue ne la reconnaît plus et rejette les paquets qui l'utilisent. La direction de la recomposition IKE est basée sur la direction du trafic qui utilise la durée de vie basée sur les octets plus rapidement, sur les petits décalages de recomposition lors de l'expiration des durées de vie basées sur le temps et sur la direction du flux des paquets après la suppression des SA IPSec inactives. Le filtrage avec état basé sur l'hôte du trafic IKE sur les clients qui initient les connexions (et donc les négociations IKE) via le parefeu Windows ne provoque généralement pas de problème. Le parefeu Windows ne filtre pas les paquets IPSec, car le pilote IPSec traite les paquets sur une couche inférieure à celle sur laquelle le filtrage du parefeu est réalisé. Cependant, les ports IKE doivent être configurés « ouverts » dans le parefeu hôte afin de recevoir les négociations IKE entrantes pour les connexions de protocole de niveau supérieur autorisées via le parefeu (par exemple, pour le partage de fichiers utilisant le protocole SMB sur le port TCP 445). Prise en charge de l'unité PMTU ICMP requise par le protocole TCP Le paramètre par défaut sous Windows 2000 et les versions ultérieures pour chaque paquet TCP est le bit Ne pas fragmenter défini dans l'entête IP. Ce paramètre est conservé lorsque le mode de transport AH ou ESP IPSec est utilisé pour sécuriser le paquet. Par conséquent, un paquet trop important sera abandonné au niveau du routeur qui renverra un message ICMP destination inaccessible indiquant la taille maximale autorisée. Ce comportement est appelé recherche de l'unité maximale de transfert (MTU) du chemin TCP. L'ordinateur client et l'ordinateur cible doivent être capables de recevoir des messages PMTU ICMP pour les paquets IPSec trop volumineux. Il est important que le trafic protégé par IPSec évite la fragmentation, car l'accélération matérielle ne traite généralement pas les paquets fragmentés. Les paquets IPSec fragmentés doivent être traités par le pilote IPSec du logiciel. Windows 2000 et Windows XP ne prennent pas en charge la recherche PMTU ICMP pour les paquets du mode de transport IPSec qui utilisent l'encapsulation NAT traversal (port UDP 4500). Windows Server 2003 prend en charge ce processus de recherche. Reportezvous à la page Troubleshooting Translational Bridging (Dépannage du pont de conversion) dans la section TCP/IP Troubleshooting (Dépannage TCP/IP) de la documentation en ligne de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/Windows/ 2000/server/reskit/enus/cnet/cnbd_trb_gdhe.asp pour connaître les options et outils qui fonctionnent sans la recherche PMTU. Remarque : il existe un problème connu qui nécessite l'activation de la détection PMTU TCP pour que IPSec sécurise le trafic dans un scénario NAT traversal où les connexions UDPESP d'IPSec sont initiées par un hôte situé à l'extérieur du NAT vers un hôte situé derrière un NAT. Si ce scénario est requis, confirmez que la détection PMTU TCP est activée en vous assurant que la clé de registre suivante n'est pas définie ou qu'elle est définie sur 1 aux deux extrémités : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\EnablePMTUDiscovery=1 (Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.) Le modèle de stratégie de sécurité de base du serveur membre sous Microsoft Windows Server 2003
193
ainsi que les configurations tierces peuvent configurer cette clé de registre pour désactiver PMTU TCP. Prise en charge requise de la fragmentation Les chemins réseau et les filtres doivent prendre en charge la transmission de fragments pour les protocoles IKE, IPSec, AH et ESP. IKE utilise les paquets UDP et leur permet d'être fragmentés selon les besoins. L'implémentation NAT traversal d'IPSec ajoute la prise en charge de l'évitement de la fragmentation IKE uniquement lorsque IKE s'authentifie au moyen de certificats (par exemple, dans des scénarios de réseau privé virtuel L2TP/IPSec). L'authentification IKE qui utilise Kerberos ne prend pas en charge l'évitement de la fragmentation et doit être capable d'envoyer et de recevoir des paquets UDP fragmentés contenant le ticket Kerberos. Le chemin réseau doit prendre en charge la transmission des fragments pour les protocoles AH et ESP car IPSec sécurise le paquet IP d'origine complet avant la fragmentation sortante au niveau de la couche IP. IPSec est intégré à TCP afin que, dans le cas où les paquets TCP sont définis sur Ne pas fragmenter (paramètre par défaut), TCP réduise la taille de ses paquets pour recevoir les octets supplémentaires ajoutés par l'encapsulation d'IPSec. IPSec n'est pas intégré à UDP et les applications UDP ne possèdent aucun moyen de détecter si IPSec protège leur trafic. Par conséquent, lorsque AH ou ESP IPSec est appliqué, les paquets UDP qui utilisent la taille totale de l'unité maximale de transfert sont fragmentés par l'hôte au moment de la transmission. D'une manière similaire, si les filtres de la stratégie IPSec n'exemptent pas ICMP, l'utilisation de l'outil Ping peut générer des paquets ICMP qui apparaissent en tant que paquets AH ou ESP IPSec fragmentés sur le réseau. Pour plus d'informations, reportezvous à l'article 233256 How to Enable IPSec Traffic Through a Firewall (Trafic via un parefeu) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=233256. Prise en charge requise pour le trafic de diffusion et de multidiffusion La conception de la stratégie IPSec dans le cadre de l'isolation de serveurs et de domaines utilise des filtres N'importe lequel <> Sousréseau. Ainsi, le filtre sortant Sousréseau > N'importe lequel correspondra au trafic de diffusion et de multidiffusion sortant envoyé par les hôtes à l'aide d'une adresse IP de sousréseau interne. Toutefois, étant donné qu'IPSec ne peut pas sécuriser le trafic de diffusion ou de multidiffusion, il doit ignorer ce trafic s'il correspond au filtre. Le trafic de multidiffusion entrant ainsi que la plupart des trafics de diffusion ne correspondent pas au filtre entrant N'importe lequel > Sousréseau. Si le trafic de diffusion et de multidiffusion est requis, vous pouvez définir la clé de registre sur NoDefaultExempt=1, ce qui permet au trafic de diffusion et de multidiffusion d'éviter le filtrage IPSec sous Windows XP et Windows Server 2003. Cette configuration empêche l'apparition de problèmes connus avec les clients RTC (Real Time Communications, communications en temps réel) et le serveur Windows Media, qui utilisent tous deux le trafic de multidiffusion. Pour obtenir des détails sur l'utilisation et les implications en termes de sécurité de la clé de registre NoDefaultExempt, reportezvous aux articles suivants de la Base de connaissances : •810207 IPSec default exemptions are removed in Windows Server 2003 (Les exemptions par défaut IPSec sont supprimées de Windows Server 2003) à l'adresse http://support.microsoft.com/? kbid=810207 • 811832 IPSec Default Exemptions Can Be Used to Bypass IPSec Protection in Some Scenarios (Les exemptions par défaut IPSec vous permettent d'ignorer la protection IPSec dans certains scénarios) à l'adresse http://support.microsoft.com/?kbid=811832
194
Remarque : Windows XP SP2 utilise les mêmes exemptions par défaut que Windows Server 2003. La clé de registre peut être définie pour contrôler les exemptions par défaut sur toutes les plates formes, selon les besoins. Le filtrage IPSec ne prend pas en charge la configuration des adresses de destination de diffusion ou de multidiffusion spécifiques. Les diagnostics des périphériques réseau peuvent être inutiles Avec l'utilisation de l'encapsulation IPSec, les applications qui supposent que le trafic TCP/IP est en texte clair ne peuvent plus inspecter le trafic du réseau. Il est peu probable que les outils de diagnostic réseau qui inspectent ou fournissent des rapports basés sur les ports TCP et UDP soient capables d'interpréter les paquets encapsulés par IPSec, même si le chiffrement AH ou ESP n'est pas utilisé. Des mises à jour de ces outils seront peutêtre requises de la part des fournisseurs pour permettre l'inspection des paquets IPSec AH ou ESPnull. Problèmes de carte d'interface réseau et de pilote La perte de paquets IPSec peut parfois être provoquée par des cartes d'interface réseau (network interface cards, NIC) qui exécutent des fonctions spéciales. Vous devez tester les cartes qui effectuent des mises en cluster ou des regroupements pour savoir si elles sont compatibles avec IPSec. Les pilotes NIC qui accélèrent les fonctions non IPSec risquent de rencontrer des problèmes avec le trafic protégé par IPSec. Les cartes d'interface réseau qui accélèrent les fonctions TCP peuvent prendre en charge le calcul du total de contrôle TCP et la validation (déchargement du total de contrôle), ainsi que la possibilité d'envoyer efficacement des tampons de données TCP volumineux (déchargement d'envoi important). Windows 2000 et les versions ultérieures désactivent automatiquement ces fonctions de déchargement TCP dans la pile TCP/IP lorsque le pilote IPSec possède des filtres, même si IPSec effectue uniquement des fonctions autoriser et bloquer. Les pilotes de cartes réseau qui ne sont pas certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel (WHQL) risquent de provoquer des problèmes lorsque IPSec est utilisé pour protéger le trafic. Un jeu de tests étendu est utilisé par WHQL pour certifier les pilotes NIC conçus pour reconnaître le déchargement d'IPSec. Pour faciliter le dépannage, la pile TCP/IP de Windows 2000, Windows XP et Windows Server 2003 prend en charge une option de clé de registre permettant de désactiver toutes les formes de déchargement TCP/IP. Certains pilotes NIC prennent également en charge la désactivation du déchargement en utilisant les propriétés avancées de la connexion réseau. Vous devrez peutêtre redémarrer votre ordinateur pour que les modifications de la configuration du pilote prennent effet. Dépannage de la perte de paquets dans les protocoles IPSec Les paquets peuvent être rejetés ou perdus, ce qui peut affecter la connectivité de l'application. Cette section détaille les cas courants de rejet des paquets par IPSec. Comme mentionné précédemment, certains périphériques réseau n'autorisent pas la transmission du protocole IP 50 ou 51 ou des ports UDP 500 ou 4500. De même, certains paquets encapsulés par IPSec peuvent se fragmenter et ne pas traverser le réseau. Dans ce cas de figure, un suivi de la surveillance réseau est généralement requis de la part des deux côtés de la communication pour permettre d'identifier et d'établir une corrélation entre les paquets envoyés et ceux reçus. Recherchez les transmissions signalées par des paquets de même taille apparaissant à plusieurs reprises. Il peut s'avérer nécessaire de réaliser un suivi du comportement type du protocole sans IPSec, puis de le comparer avec le comportement du protocole du trafic protégé par IPSec. Erreur de l'événement 4285 Titre de l'événement : Échec d'authentification de hachage
195
IKE et IPSec offrent une protection contre la modification des paquets pendant qu'ils traversent le réseau. Si un périphérique modifie une partie du paquet protégé par un hachage d'intégrité, alors le pilote IKE ou IPSec récepteur rejettera ce paquet, ce qui entraînera l'erreur d'échec d'authentification de hachage consignée dans le journal système en tant qu'événement 4285. L'expérience a montré que certains périphériques, pilotes réseau et processeurs tiers de paquets endommagent parfois les paquets d'une taille donnée, ceux qui possèdent un certain nombre de fragments, ceux d'un certain type de protocole ou lorsque certaines conditions sont réunies (lorsque le périphérique est saturé, qu'il surveille le trafic ou qu'il redémarre). Cette erreur peut également être due à une attaque du paquet par une application malveillante ou par une application qui ignorait qu'il était protégé. Elle peut aussi indiquer une attaque par refus de service. Vous pouvez utiliser les techniques suivantes pour détecter le rejet des paquets corrompus par IPSec. Cependant, il est également important d'établir une corrélation entre ces observations et le suivi de la surveillance du réseau pour permettre de détecter la source de la corruption.
• Examinez le compteur Paquets IPSec non authentifiés. Sous Windows Server 2003, vous
pouvez vérifier ce compteur à l'aide du compteur IPSec de l'analyseur de performances, de la commande netsh ipsec dynamic show stats ou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows XP, vous pouvez vérifier ce compteur à l'aide de la commande ipseccmd show stats ou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows 2000, ce compteur apparaît dans l'affichage graphique d'ipsecmon.exe ou lorsque vous utilisez la commande netdiag /test:ipsec /v .
• Activez la journalisation du pilote IPSec et recherchez l'événement 4285 dans le journal système à partir d'IPSec source. Consultez la section Jeu d'outils de ce chapitre pour obtenir des détails sur la manière d'activer la journalisation du pilote IPSec. Le texte de l'événement sera similaire à ce qui suit :
Échec lors de l'authentification du hachage de 5 paquet(s) reçu(s) de 192.168.0.10. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur. Bien que le texte de l'événement suggère un redémarrage du service IPSec pour résoudre le problème, l'origine de la perte de la plupart des paquets n'est pas liée au système IPSec. Le redémarrage du service ne permettra pas de résoudre le problème et risque d'engendrer davantage de difficultés. Le service IPSec ne doit être arrêté qu'en dernier recours pour déterminer si un problème est lié à IPSec ou non. La résolution de cette erreur requiert des recherches pour identifier un modèle des adresses IP source, des heures de la journée, des cartes réseau ou des conditions dans lesquelles l'erreur se produit. Si le nombre de paquets est peu élevé, il n'est peutêtre pas utile d'effectuer des recherches. Il est important de commencer par exclure les sources de la corruption du système local. Désactivez le déchargement d'IPSec, essayez de désactiver les fonctions avancées ou de performances du pilote en utilisant la configuration fournie dans les propriétés avancées et procurezvous les pilotes NIC les plus récents auprès de votre fournisseur. Utilisez de préférence des pilotes certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel. Étudiez ensuite les caractéristiques des chemins réseau via lesquels le paquet sera transmis. Recherchez d'autres preuves de la corruption du paquet dans les statistiques de rejet des paquets TCP/IP et sur les autres ordinateurs utilisant la même configuration. Le compteur IP des Datagrammes reçus et rejetés augmente chaque fois qu'IPSec rejette un paquet. Remarque : pour désactiver la fonctionnalité de déchargement TCP/IP, utilisez la clé de registre suivante sur les ordinateurs exécutant Windows 2000, Windows XP ou Windows Server 2003 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\ Valeur de registre EnableOffload DWORD définie sur 0
196
(Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.) Redémarrez ensuite l'ordinateur. Erreur de l'événement 4268 Titre de l'événement : Paquets reçus avec un index des paramètres de sécurité (Security Parameters Index, SPI) erroné L'implémentation d'IKE sous Windows 2000 et Windows XP (y compris SP1) génère un problème connu qui entraîne la perte de paquets dans certaines conditions. Ce problème a été résolu pour Windows Server 2003 et Windows XP SP2. L'impact sur les communications du protocole de niveau supérieur est généralement négligeable car les protocoles subissent habituellement quelques pertes de paquets pour diverses autres raisons. Ce problème peut être identifié par les caractéristiques suivantes :
• Augmentation lente mais régulière des valeurs du compteur SPI erroné. • Messages de l'événement 4268 dans le journal système (si activé). Par défaut, Windows 2000
consigne ces messages dans le journal système en tant qu'événement 4268. Windows XP ne consigne pas cet événement par défaut ; il faut que la journalisation du pilote soit activée. Le texte de l'événement est similaire à ce qui suit :
<nombre> paquet(s) reçu(s) de avec un index des paramètres de sécurité erroné. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur. Bien que le texte de l'événement suggère un redémarrage du service IPSec pour résoudre le problème, l'origine de ce type de perte de paquets fait partie de la conception du système IPSec. Le redémarrage du service ne permettra pas de résoudre le problème et risque d'engendrer davantage de difficultés. Comme indiqué plus haut, le service IPSec ne doit être arrêté qu'en dernier recours pour déterminer si un problème est lié à IPSec ou non. L'index des paramètres de sécurité IPSec est un indicateur du paquet qui informe le répondeur de l'association de sécurité à utiliser pour traiter le paquet. Si un SPI n'est pas reconnu, il est appelé « SPI erroné ». Cette erreur signale que l'ordinateur récepteur a reçu des paquets formatés par IPSec alors qu'il ne disposait pas d'une association de sécurité IPSec pour les traiter. Par conséquent, l'ordinateur doit rejeter les paquets. Ces messages d'erreur sont anodins, même si les paquets sont rejetés. Le nombre d'événements SPI erronés générés dépend du niveau d'activité des ordinateurs et de la rapidité de transmission des données protégées par IPSec au moment de la recomposition. Les conditions suivantes sont susceptibles de générer davantage d'événements de ce type :
• transfert de volumes importants de trafic IPSec via des connexions de 1 gigabit ou plus ; • serveurs très encombrés (lents) et ordinateurs clients rapides ; • clients lents communiquant avec un serveur rapide ; • multiples clients actifs pour un serveur, ce qui oblige IKE à une recomposition constante avec plusieurs clients simultanément.
Par conséquent, une connexion TCP protégée par IPSec va ralentir pendant quelques secondes pour retransmettre les données perdues. Si plusieurs paquets sont perdus, TCP risque de passer en mode d'évitement de saturation pour cette connexion. Après quelques secondes, la connexion doit retrouver
197
sa vitesse normale. Pour les applications de copie de fichiers, Telnet, Terminal Server ainsi que les autres applications basées sur TCP, la perte de ces paquets passe inaperçue. Cependant, il peut arriver que TCP perde un groupe de paquets sur une liaison rapide et qu'il doive rétablir la connexion. Lorsque la connexion est rétablie, le socket est fermé et les applications sont averties de la rupture de connexion, ce qui peut interrompre les transferts de fichiers. La cause la plus courante de cette erreur est un problème connu relatif à Windows 2000 qui implique le mode de synchronisation de la recomposition de la SA IPSec par IKE. Lorsque l'initiateur du mode rapide IKE est plus rapide que le répondeur, l'initiateur peut envoyer les nouveaux paquets sécurisés de l'association de sécurité IPSec plus rapidement que le répondeur ne peut les recevoir. Comme l'indique le document RFC (Requests for Comment, demande de commentaires) de l'IETF (Internet Engineering Task Force) relatif à IPSec, lorsque IKE établit une nouvelle association de sécurité IPSec, l'initiateur doit utiliser la nouvelle SA IPSec sortante pour transmettre les données alors que le répondeur plus lent reçoit le trafic protégé par IP qu'il ne reconnaît pas encore. Étant donné que la recomposition IKE dépend à la fois du temps écoulé et de la quantité de données envoyées sous la protection d'une SA IPSec, il est possible que des événements SPI erronés apparaissent périodiquement (mais pas nécessairement à des intervalles spécifiques). Dans des scénarios d'interopérabilité de client tiers, une erreur de SPI erroné peut indiquer qu'un IPSec pair n'a pas accepté un message de suppression et ne l'a pas traité ou qu'il a rencontré des problèmes pour exécuter la dernière étape de la négociation du mode rapide IKE. Cette erreur peut également signifier qu'un attaquant submerge un ordinateur de paquets IPSec usurpés ou injectés. Le pilote IPSec compte ces événements et les consigne pour conserver un enregistrement de l'activité du SPI erroné. La clé de registre LogInterval peut être utilisée pour identifier et minimiser ces événements. Lors du dépannage, définissezla sur la valeur minimum (toutes les 60 secondes) pour que les événements soient enregistrés rapidement. Sous Windows 2000, vous pouvez arrêter et redémarrer le service Agent de stratégie IPSec pour recharger le pilote IPSec. Sous Windows XP et Windows Server 2003, vous devez redémarrer l'ordinateur pour recharger les pilotes TCP/IP et IPSec. Sous Windows 2000, ces événements ne peuvent pas être supprimés par les paramètres de clé de registre actuels ou des correctifs. Par défaut, sous Windows XP et Windows Server 2003 ces événements ne sont pas signalés. Vous pouvez activer les rapports de ces événements en utilisant la configuration IPSecDiagnostics via l'option de ligne de commande netsh ipsec ou directement via la clé de registre. Les techniques suivantes peuvent vous aider à minimiser ces erreurs :
• Ajustez les paramètres de la stratégie IPSec. Augmentez la durée de vie du mode rapide (si les
exigences de sécurité le permettent) à 21 ou 24 heures (les associations de sécurité IPSec inactives sont effacées au bout de 5 minutes si elles ne sont pas utilisées). Pour éviter l'apparition de faiblesses potentielles au niveau de la sécurité due à l'utilisation de la même clé pour chiffrer trop de données, ne définissez pas une durée de vie supérieure à 100 Mo lorsque vous utilisez le chiffrement ESP.
• Utilisez la confidentialité de transmission parfaite (perfect forward secrecy, PFS) du mode principal ou du mode rapide qui ne provoque pas ce problème pour l'association de sécurité spécifique en cours de négociation. Cependant, ces paramètres augmentent considérablement la charge de l'ordinateur qui traite les requêtes de plusieurs clients et risquent ainsi de contribuer à accroître le délai de réponse aux autres négociations.
• Ajoutez un processeur ou un matériel permettant d'augmenter les performances ou de réduire les charges sur l'application.
198
• Installez une carte réseau d'accélération matérielle IPSec si l'ordinateur n'en dispose pas. Ces cartes réduisent considérablement l'utilisation du processeur par IPSec lors des transferts de données à débit élevé.
• Si l'utilisation du processeur reste élevée, pensez à utiliser un produit accélérateur de matériel pour accélérer les calculs DiffieHellman. Il s'agit en général d'une carte PCI dotée de la capacité de déchargement de l'élévation à la puissance DiffieHellman qui accélère les calculs DiffieHellman. Cette accélération est également bénéfique aux opérations de clé publique et de clé privée qui utilisent le protocole SSL (Secure Sockets Layer). Vérifiez auprès de votre fournisseur que sa carte prend en charge l'interface ModExpoOffload sous CAPI pour les calculs DiffieHellman.
• Si possible, créez un filtre qui autorise certains trafics à haute vitesse ne nécessitant pas la
protection IPSec (par exemple, le trafic de sauvegarde d'un serveur sur un réseau local dédié).
Si ces options ne fonctionnent pas et que la mise à niveau vers Windows XP SP2 ou Windows Server 2003 est impossible, contactez les services de support technique Microsoft pour savoir s'il existe d'autres options disponibles. Erreur de l'événement 4284 Titre de l'événement : Paquets en clair nécessitant une sécurisation Cet événement indique qu'une association de sécurité IPSec a été établie à un moment où des paquets ont été reçus en clair alors qu'ils auraient dû faire partie de l'association de sécurité IPSec. Ces paquets ont été rejetés afin d'éviter toute attaque par injection de paquets sur les connexions sécurisées par IPSec. Bien que le compteur IP des Datagrammes reçus et rejetés augmente, IPSec ne possède pas de valeur de compteur qui enregistre le nombre de paquets rejetés pour cette raison. Ce problème peut uniquement être identifié à partir de l'événement 4284 du journal système : <nombre> paquet(s) reçu(s) en clair de alors qu'elles devraient être sécurisées. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur. Comme pour les erreurs précédentes, la suggestion contenue dans l'événement ne doit pas être suivie. En effet, il est peu probable que le redémarrage du service IPSec permette de corriger l'erreur. Cette erreur est probablement due à un problème de configuration de stratégie qui entraîne l'envoi du trafic en clair dans une direction à cause d'un filtre d'autorisation sortant plus spécifique. Par exemple, si le client possède un filtre pour sécuriser tout le trafic avec un serveur et que la stratégie du serveur possède un filtre plus spécifique qui autorise les réponses HTTP en texte clair, le serveur va sécuriser la totalité du trafic vers le client à l'exception des paquets HTTP sortants. Le client reçoit ces paquets, puis les rejette pour des raisons de sécurité car il s'attend à ce que la totalité du trafic vers/en provenance du serveur soit sécurisé dans la paire de l'association de sécurité IPSec. Cet événement peut aussi se produire dans des conditions de fonctionnement normales et dans des cas d'interopérabilité de clients tiers lorsqu'un pair supprime une association de sécurité IPSec ou un filtre du pilote IPSec alors que le trafic circule entre les ordinateurs. Par exemple, l'une des extrémités de la communication peut supprimer l'attribution d'une stratégie IPSec ou réaliser une mise à jour de la stratégie qui supprime les actions de sécurité IPSec et les filtres. Puisqu'un pair a déjà supprimé le filtre alors qu'une communication du protocole de niveau supérieur a lieu, le message de suppression IKE risque de ne pas arriver et de ne pas être traité par l'autre pair avant l'arrivée des paquets en texte clair, ce qui provoque l'erreur. De même, le temps nécessaire au traitement du message de suppression dépend de la charge actuelle de l'ordinateur pair.
199
Le message d'erreur peut également apparaître lorsqu'une stratégie volumineuse est chargée, car les associations de sécurité IPSec peuvent être établies avant que le jeu complet de filtres ne soit appliqué au pilote IPSec. Si cette situation se produit, les associations de sécurité IPSec peuvent être négociées pour le trafic qui sera exempté une fois le chargement de la stratégie terminé. Ce message d'erreur peut aussi révéler la présence d'une attaque par injection à l'endroit où le trafic en texte clair est envoyé correspondant (délibérément ou par hasard) aux sélecteurs de trafic d'une association de sécurité entrante active spécifique. Ce problème doit être transféré au concepteur de la stratégie IPSec. Délais d'expiration IPSec NATT lors de la connexion à des réseaux sans fil Un problème récemment détecté provoque l'expiration des connexions lorsque des ordinateurs clients Windows Server 2003 ou Windows XP tentent de se connecter à un serveur sur un réseau sans fil utilisant IPSec NATT. Pour plus d'informations, reportezvous à l'article 885267 de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=885267.
Vérification de la stratégie IPSec appropriée Cette section décrit les étapes de la détection de problèmes concernant l'attribution et l'interprétation de la stratégie IPSec. Les filtres d'une stratégie IPSec correctement interprétée doivent se trouver dans le pilote IPSec pour que IPSec puisse autoriser et bloquer les paquets, mais aussi déclencher la négociation par IKE des associations de sécurité IPSec avec les adresses IP distantes pour sécuriser le trafic. Des filtres appropriés doivent aussi être mis en place pour guider IKE en tant que répondeur. Dans cette solution, la conception de la stratégie IPSec requiert que tout le trafic (sauf ICMP) soit sécurisé par IPSec. La stratégie contient des filtres pour chaque adresse IP de la liste d'exemption. Remarque : sous Windows 2000, le service IPSec est appelé Agent de stratégie IPSec ; sous Windows XP et Windows Server 2003, il est appelé Service IPSec. Les ingénieurs du support technique doivent être familiarisés avec l'utilisation de la stratégie de groupe par IPSec, la priorité de la stratégie IPSec et son interprétation. Vous trouverez des références aux informations contenues dans ces rubriques dans la section Informations complémentaires à la fin de ce chapitre. Dépannage de la stratégie de groupe pour IPSec La stratégie de groupe fournit le mécanisme d'attribution d'une stratégie IPSec de domaine à un membre du domaine. L'extraction d'objets GPO attribués par le membre du domaine permet d'attribuer la stratégie IPSec à un ordinateur hôte. Par conséquent, en cas de problème avec l'extraction des GPO, les ordinateurs n'appliquent pas la stratégie IPSec adéquate. Les problèmes courants concernant la stratégie de groupe pour la gestion de la stratégie IPSec incluent :
• retards de réplication de divers composants de configuration dans Active Directory ; • problèmes liés au sondage de la stratégie de groupe et au processus de téléchargement ; • manque de clarté par rapport à la version de la stratégie IPSec attribuée ; • service IPSec non exécuté ; • extraction de la stratégie IPSec impossible dans Active Directory, utilisation d'une copie mise en cache à la place ;
200
• retards dus au sondage de la stratégie IPSec pour extraire une stratégie IPSec actuellement attribuée.
La réplication peut être retardée en raison du nombre d'objets liés à IPSec dans Active Directory, comme les stratégies IPSec, les GPO, les changements d'attribut dans les attributions de la stratégie IPSec aux GPO et dans la stratégie IPSec ainsi que les informations sur les appartenances aux groupes de sécurité. La planification doit tenir compte de l'impact d'un changement dans la configuration IPSec qui influence progressivement les membres du domaine. Pour obtenir des informations sur les procédures de dépannage de la stratégie de groupe, consultez les livres blancs suivants :
• Troubleshooting Group Policy in Windows 2000 (Dépannage de la stratégie de groupe sous Windows 2000)
à l'adresse http://support.microsoft.com/?kbid=810739.
• Troubleshooting Group Policy in Microsoft Windows Server
(Dépannage de la stratégie de groupe sous Microsoft Windows Server) à l'adresse www.microsoft.com/downloads/details.aspx FamilyId=B24BF2D50D7A4FC5A14DE91D211C21B2&displaylang=en.
L'attribution d'une stratégie IPSec basée sur le domaine est implémentée par deux composants :
• le composant logiciel enfichable MMC Gestion de stratégie IPSec (une extension du composant logiciel MMC Stratégie de sécurité) pour l'attribution d'une stratégie IPSec dans le GPO ;
• l'extension côté client (client side extension, CSE) de la stratégie de groupe pour IPSec (implémentée dans gptext.dll) qui traite les informations liées à IPSec dans le GPO.
Le composant logiciel enfichable MMC Gestion de stratégie IPSec attribue une stratégie à un objet GPO en stockant les informations sur la stratégie IPSec sélectionnée dans le composant IPSec de l'objet GPO, référencé en tant que nom unique (Distinguished Name, DN) LDAP : CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID}, CN=Stratégies,CN=Système,DC=domaine,DC=Woodgrove,DC=com Le nom unique LDAP de la stratégie IPSec attribuée est stocké dans l'attribut du GPO ipsecOwnersReference. Lorsque la stratégie de groupe extrait la liste d'objets GPO qui s'appliquent à l'ordinateur, les GPO contenant les attributions de la stratégie IPSec sont stockés dans le registre sous le GUID (Globally unique identifier, identifiant unique global) de l'extension IPSec côté client à l'emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Group Policy \History\{e437bc1caa7d11d2a38200c04f991e27} L'extension IPSec côté client est activée par la CSE de la stratégie de sécurité chaque fois qu'une attribution de stratégie IPSec existe dans un objet GPO. S'il existe des problèmes de traitement de la stratégie de sécurité, il risque également d'y avoir des problèmes de traitement de la stratégie IPSec. Pour localiser le GUID de chaque extension de stratégie de groupe, consultez l'emplacement suivant dans le registre : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \WindowsNT\CurrentVersion\WinLogon\GPExtensions
201
Les GUID liés au déploiement d'IPSec pour les CSE de stratégie de groupe se présentent comme suit :
• Sécurité. {827D319E6EAC11D2A4EA00C04F79F83A} • Sécurité IP.{E437BC1CAA7D11D2A38200C04F991E27} • Scripts. {42B5FAAE653611D2AE5A0000F87571E3} La CSE IPSec copie le numéro unique LDAP ainsi que les informations associées sur la stratégie IPSec attribuée dans la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy Si plusieurs objets GPO contiennent des attributions de stratégie IPSec, alors la CSE IPSec est appelée pour chaque GPO. Les règles de priorité des GPO s'appliquent selon l'ordre dans lequel la CSE IPSec reçoit les GPO à traiter. L'ordre peut également être influencé par les paramètres des objets GPO et par les listes de contrôle d'accès (Access control list, ACL) en lecture qui empêchent l'extraction de certains objets GPO attribués. Chaque fois qu'une CSE IPSec est appelée, les informations IPSec associées situées dans le GPO (y compris le nom unique) sont écrasées dans la clé de registre. Une fois que tous les GPO ont été traités, la CSE avertit le service IPSec qu'une stratégie IPSec basée sur le domaine est attribuée. Le service IPSec lit ensuite la valeur GPTIPSecPolicy\DSIPSECPolicyPath afin d'extraire la stratégie IPSec appropriée. Le service IPSec continue à rechercher les éventuels changements apportés à la stratégie IPSec attribuée en fonction de l'heure de la dernière mise à jour de l'un des objets d'annuaire de la stratégie IPSec attribuée. Ce service entretient la stratégie IP mise en cache et la considère comme la stratégie de domaine la plus récente. Il existe un problème connu qui autorise le nom de la stratégie IPSec attribuée à ne plus être synchronisé avec le nom de la stratégie IPSec en cours d'utilisation (et mise en cache). Le service IPSec ne met pas à jour les informations de la clé de registre GPTIPSecPolicy, telles que DSIPSECPolicyName, et le nom de la stratégie IPSec change uniquement lorsque la CSE IPSec est appelée. Toutefois, la CSE IPSec n'est pas appelée à moins qu'il se produise un changement dans l'attribut de nom unique de la stratégie IPSec dans l'objet GPO. Cette valeur de registre est utilisée par le composant logiciel enfichable MMC Moniteur IPSec et les outils de ligne de commande pour indiquer le nom de la stratégie IPSec actuellement attribuée. Ainsi, les outils IPSec peuvent signaler le nom de la stratégie IPSec traitée en dernier par la CSE, et non celui de la stratégie en cours d'utilisation. Il existe plusieurs solutions pour éviter ce bogue. Pour plus d'informations, reportezvous à la section Versions des stratégies du chapitre 5, Création de stratégies IPSec pour les groupes d'isolation de ce guide. Remarque : Microsoft recommande que les conventions de dénomination des stratégies IPSec incluent un numéro de version dans le nom, afin qu'il soit plus aisé de retrouver la version de la stratégie actuellement appliquée. Il est impossible de détecter des changements de version si le nom d'une stratégie reste identique. Si la stratégie IPSec correcte n'est pas attribuée, même après une actualisation forcée de la stratégie de groupe, les erreurs du journal des applications des sources Userenv ou SceCli signaleront des problèmes de traitement de la stratégie de groupe. Il est nécessaire que la journalisation de la stratégie de groupe soit activée pour que vous puissiez étudier ce problème en détail. Il existe différents types de journaux de stratégie de groupe et différents niveaux de journalisation. Les journaux de la CSE de sécurité sont nécessaires pour connaître les erreurs de traitement de la stratégie de sécurité ainsi que les erreurs signalées par la CSE IPSec. Il n'existe pas de journal
202
spécifique à l'extension côté client IPSec. Les suivis de la surveillance réseau seront peutêtre requis pour capturer le trafic au moment de l'actualisation de la stratégie de groupe pour confirmer quelle adresse IP de contrôleur de domaine est utilisée pour l'extraction de chaque objet. Vous pouvez rencontrer les difficultés suivantes :
• des problèmes de réplication ou de retard conduisant à l'impossibilité de trouver des objets ; • la logique de l'équilibrage de charge du localisateur du contrôleur de domaine peut entraîner
l'extraction d'un objet GPO à partir d'un contrôleur de domaine alors que la requête LDAP de la stratégie IPSec attribuée est extraite à partir d'un autre contrôleur de domaine du même site.
Pour créer un fichier journal détaillé de la CSE de sécurité, utilisez la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \WindowsNT\CurrentVersion\CurrentVersion\Winlogon \GpExtensions\{827d319e6eac11d2a4ea00c04f79f83a}\ Définissez l'entrée ExtensionDebugLevel sur une valeur REG_DWORD de 0x2. Le fichier journal sera créé à l'emplacement %windir%\Security\Logs\Winlogon.log. Remarque : une entrée DNS non valide peut signifier que les stratégies de groupe ne sont pas téléchargées depuis Active Directory, même si les connexions de l'utilisateur et de l'ordinateur ont réussi. Pour plus d'informations sur les problèmes DNS, reportezvous à la section Problèmes de résolution de noms, plus haut dans ce chapitre. Dépannage du service IPSec Il n'est pas nécessaire que le service IPSec soit en cours d'exécution pour que vous puissiez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec. Cependant, si un administrateur attribue par la suite une stratégie locale, la colonne Stratégie attribuée affiche une erreur. Les problèmes courants suivants peuvent entraîner l'échec du service IPSec au démarrage :
• L'ordinateur a démarré en mode sans échec ou en mode de récupération Active Directory.
Dans ces deux cas, le pilote IPSec fournit une communication sortante avec état par défaut si une stratégie IPSec est attribuée. La connectivité entrante sera bloquée jusqu'à ce qu'une exemption d'amorçage soit configurée.
• IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 et 4500. Utilisez la commande
netstat –bov pour afficher les processus et les modules de code de chaque port. La commande portqry –local –v offre davantage de détails. Il est possible que des fournisseurs de services superposés (Layered Service Providers, LSP) Winsock installés interfèrent avec IPSec. Pour plus d'informations sur les LSP et IPSec, reportezvous à la section Dépannage des problèmes liés aux applications plus loin dans ce chapitre.
• Corruption de la stratégie IPSec. La stratégie IP attribuée ne peut pas être lue ou appliquée en
totalité, ce qui oblige le service IPSec à signaler des erreurs. Ces erreurs ne provoquent pas l'échec du service, mais peuvent entraîner des échecs de communication de plusieurs façons, en bloquant la stratégie de groupe et en empêchant le service IPSec d'extraire les stratégies corrigées, par exemple. Sous Windows XP et Windows Server 2003, vous devez veiller à ce que la conception d'une stratégie persistante ou locale soit « fiable » afin qu'elle soit appliquée en cas d'erreurs survenant lorsqu'une stratégie de domaine est appliquée. Les stratégies persistantes et les stratégies de démarrage de l'ordinateur (exemptions du mode d'amorçage) doivent faire partie des investigations de dépannage. Ces stratégies doivent autoriser l'accès distant à l'ordinateur par
203
d'autres moyens dans le cas où elles sont les seules stratégies appliquées en raison d'autres conditions d'échec. L'implémentation d'IPSec sous Windows 2000 utilise un module appelé Magasin de stratégies IPSec (polstore.dll) afin que les composants logiciels enfichables MMC Agent de stratégie IPSec et Gestion de stratégie IPSec puissent utiliser un module pour accéder aux trois emplacements de stockage des stratégies pris en charge : local, ordinateur distant et Active Directory. Cette conception a été modifiée et améliorée sous Windows XP et Windows Server 2003 avec l'ajout de nouveaux types de stratégies IPSec (stratégie de démarrage et persistante) et du composant Base de données de stratégies de sécurité (Security Policy Database, SPD), qui gère l'état d'exécution de la stratégie IPSec pour les requêtes de surveillance IPSec et les requêtes IKE. Cette modification d'ordre architectural signifie que le texte des événements IPSec consignés sous Windows 2000 a changé sous Windows XP et Windows Server 2003. Elle signifie également que des changements importants ont dû être apportés aux interfaces RPC utilisées pour la gestion à distance. Pour Windows Server 2003, les interfaces RPC ont subi d'importantes mises à jour. C'est pourquoi le composant logiciel enfichable MMC Gestion de stratégie IPSec n'est pas capable de se connecter à des ordinateurs distants qui ne possèdent pas la même version de système d'exploitation. En outre, le modèle de sécurité pour Windows XP SP2 et Windows Server 2003 SP1 a été radicalement modifié pour limiter les connexions RPC distantes et pour activer le parefeu Windows par défaut. Pour plus d'informations, reportezvous à Changes to Functionality in Microsoft Windows XP Service Pack 2 Part 2: Network Protection Technologies (Modifications apportées à Microsoft Windows XP Service Pack 2 Partie 2 : technologies de protection des réseau) à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/ maintain/sp2netwk.mspx. En raison de ces changements, les interfaces RPC distantes du service IPSec ont été désactivées par mesure de sécurité. Par conséquent, les composants logiciels enfichables MMC Moniteur IPSec et Gestion de stratégie IPSec ne peuvent pas réaliser de surveillance à distance sur ces ordinateurs. La gestion distante d'IPSec doit être effectuée à l'aide de connexions Bureau à distance (Terminal Server), qui exécutent les composants logiciels enfichables MMC IPSec en tant que processus locaux. Sous Windows 2000, le pilote IPSec est chargé par défaut à la fin du processus de démarrage par le service Agent de stratégie. Le pilote IPSec ne participe pas au traitement des paquets IP jusqu'à la première fois où le service Agent de stratégie informe le pilote IPSec d'une stratégie active. S'il n'existe pas de stratégie IPSec active, le pilote IPSec n'est pas inclus dans le traitement du trafic IP entrant et sortant. Sous Windows XP et Windows Server 2003, cette conception a été améliorée pour que le pilote IPSec soit chargé par le pilote TCP/IP au cours du processus de démarrage. Le pilote ne traite pas les paquets avant que des filtres soient chargés par le service IPSec. Sous Windows 2000, il est possible que des erreurs soient consignées par l'Agent de stratégie IPSec pour des problèmes de démarrage du service. Ces erreurs sont les suivantes :
• L'Agent de stratégie de la sécurité IP n'a pas pu démarrer. Aucune stratégie de sécurité IP
ne sera appliquée. Cette erreur est probablement due aux problèmes rencontrés par l'Agent de stratégie IPSec lors de son enregistrement auprès du soussystème RPC. Elle peut aussi provenir de l'échec d'initialisation d'IKE en raison de LSP Winsock tiers.
• Le Serveur RPC de l'Agent de stratégie n'a pas pu... • • • • • •
enregistrer la séquence de protocoles enregistrer l'interface enregistrer les liens d'interface enregistrer le point de fin d'interface enregistrer les mécanismes d'authentification écouter
204
Ces erreurs peuvent être dues à des changements apportés aux paramètres de sécurité avancés ou à des problèmes inhérents au service RPC qui ne permettent pas à l'Agent de stratégie IPSec de s'initialiser correctement au démarrage du service. Par conséquent, l'Agent de stratégie IPSec ne fonctionnera pas correctement, risquera de se bloquer ou de s'arrêter.
• L'Agent de stratégie n'a pas pu démarrer. Impossible de se connecter à la base de données SCM. Erreur :. Le service IPSec ne peut pas ouvrir la base de données du gestionnaire de contrôle des services (Service Control Manager, SCM), ce qui peut être dû au fait que le service IPSec a été configuré pour être exécuté en tant que compte de service sans privilèges. Il doit être exécuté en tant que système local. Pour rechercher la cause de problèmes, utilisez le gestionnaire de contrôle des services.
• L'Agent de stratégie n'a pas pu se connecter au pilote IPSEC. Le pilote IPSec n'a pas pu être
chargé ni interfacé correctement avec la pile TCP/IP. Windows 2000 est conçu pour réaliser cette opération lorsque le service IPSec démarre. Il est possible qu'un logiciel tiers désactive la connexion ou que le système d'exploitation ne dispose pas de tous les modules de codes requis pour cette fonctionnalité.
• L'Agent de stratégie n'a pas pu charger les stratégies IPSEC. Une erreur s'est produite
pendant que l'agent de stratégie IPSec chargeait tous les filtres dans le pilote IPSec. Cette erreur peut provenir d'un manque de mémoire du noyau ou de la mauvaise initialisation du pilote IPSec. Si le problème persiste, contactez les services de support technique Microsoft.
• L'Agent de stratégie n'a pas pu démarrer le service ISAKMP. Cette erreur se produit
généralement car IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 ou 4500 étant donné qu'ils sont utilisés par un autre service. Elle peut aussi être provoquée par un logiciel de sécurité tiers qui empêche l'allocation des ports réseau ou parce que le service IPSec n'est pas exécuté dans le contexte du système local.
• Impossible de déterminer le nom principal SSPI pour le service ISAKMP/Oakley.
Windows 2000 enregistre ce message lorsque l'appel de la fonction QueryCredentialsAttributes de l'interface du fournisseur de prise en charge de la sécurité (security support provider interface, SSPI) échoue. Cette échec peut signifier que l'ordinateur n'a pas réussi à se connecter au domaine.
• Impossible d'obtenir les informations d'identification du serveur Kerberos pour le service
ISAKMP/Oakley. Ce message d'erreur de Windows 2000 apparaît couramment lorsque le service IPSec démarre (peutêtre au démarrage de l'ordinateur) sur un réseau distant où une stratégie IPSec est attribuée (peutêtre depuis le cache du registre de la stratégie de domaine) et nécessite l'authentification Kerberos alors qu'un contrôleur de domaine n'est pas disponible. C'est pourquoi l'authentification Kerberos ne fonctionne pas. Sur le réseau interne, cet événement est consigné sur un ordinateur non membre du domaine ou qui ne peut pas communiquer avec les contrôleurs de domaine à l'aide du protocole Kerberos lors de l'initialisation du service IPSec.
• Une stratégie de communication sécurisée ne peut pas être appliquée car le pilote de sécurité IP
n'a pas pu démarrer. Contactez votre administrateur système immédiatement. Cette erreur est provoquée par un problème de chargement du pilote IPSec, sa liaison à la pile TCP/IP ou son initialisation avant l'ajout de la stratégie. La corruption de fichiers ou les autorisations peuvent être à l'origine de cette erreur. Vérifiez que les paramètres de sécurité ou un logiciel tiers ne désactivent pas le chargement du pilote. Si les signatures internes FIPS.sys ne peuvent pas être vérifiées au cours de l'initialisation, le chargement du pilote IPSec échoue également. L'échec de la signature FIPS.sys requiert le remplacement du fichier binaire signé d'origine ou un nouveau fichier binaire de Microsoft. Redémarrez l’ordinateur. Si le problème persiste, contactez les services de support technique Microsoft.
Sous Windows XP et Windows Server 2003, les événements d'erreur du service IPSec suivants indiquent que le service ne peut pas démarrer :
205
• Les services IPSec n'ont pas pu initialiser le pilote IPSec, code d'erreur :. Les services IPSec n'ont pas pu démarrer. Le pilote IPSec n'a pas pu se charger. Si le problème persiste, contactez les services de support technique Microsoft.
• Les services IPSec n'ont pas pu initialiser le module IKE, code d'erreur :. Les services
IPSec n'ont pas pu démarrer. Ce problème est fréquemment dû à des LSP Winsock tiers qui empêchent IKE d'utiliser certaines options de socket. Cette erreur est également signalée lorsque IKE ne peut pas obtenir l'accès exclusif des ports UDP 500 et 4500.
• Les services IPSec n'ont pas pu initialiser le serveur RPC, code d'erreur :. Les services IPSec n'ont pas pu démarrer. Le service IPSec dépend du soussystème RPC pour la communication interprocessus entre IKE, le composant SPD et l'Agent de stratégie. Utilisez les techniques de dépannage RPC pour confirmer que le serveur RPC fonctionne correctement. Si le problème persiste après le redémarrage de l'ordinateur, contactez les services de support technique Microsoft.
• Les services IPSec ont expérimenté une défaillance critique et se sont arrêtés avec le code
d'erreur :. L'arrêt des services IPSec peut représenter un risque potentiel pour la sécurité de cet ordinateur. Contactez l'administrateur de votre ordinateur pour redémarrer le service. Le service IPSec a rencontré une erreur indiquée par le dans le texte de l'événement et ne fonctionne plus. Le pilote IPSec est toujours chargé et utilise le mode normal (applique les filtres de la stratégie IPSec) ou le mode de blocage. Un événement distinct indiquerait que le pilote IPSec a été placé en mode de blocage. Si le pilote est en mode normal, alors les actions de filtrage autoriser et bloquer continuent à fonctionner comme prévu. Les filtres dotés d'une action négocier abandonnent tout simplement le trafic car IKE n'est pas disponible.
• Les services IPSec mettent le pilote IPSec en mode de blocage à cause du code d'erreur de
défaillances. Ce message signifie que le pilote IPSec a été placé en mode de blocage (utilisé en tant que comportement à tolérance de pannes) en raison des erreurs rencontrées au cours du traitement de la stratégie IPSec. Ce comportement est disponible sous Windows Server 2003 uniquement. Le mode de blocage permet néanmoins les exemptions entrantes configurées avec la commande netsh ipsec.
Dépannage de l'extraction de la stratégie IPSec Le service IPSec utilise une requête LDAP TCT authentifiée et chiffrée pour télécharger la stratégie IPSec attribuée pour toutes les platesformes. Il existe des options permettant de signer et de sceller LDAP à l'aide de la clé de session Kerberos. Ainsi, le service IPSec exécuté en tant que système local doit être capable d'obtenir un ticket de service Kerberos pour le service LDAP sur le serveur Active Directory. Si la stratégie IPSec correcte est attribuée et que son stockage par la CSE IPSec est confirmé sous la clé de registre GPTIPSecPolicy et que le service fonctionne, alors les problèmes suivants risquent d'empêcher IPSec d'extraire la stratégie depuis Active Directory :
• problèmes de communication avec les contrôleurs de domaine ; • problèmes de connexion des comptes de l'ordinateur à un contrôleur de domaine ; • problèmes d'émission de tickets Kerberos ; • problèmes liés à la disponibilité du service LDAP ; • problèmes de recherche de la stratégie IPSec ou des objets de composant spécifiques requis dans la requête LDAP ;
• problèmes d'autorisation en lecture pour n'importe quel objet de la stratégie IPSec requis ; • corruption de la stratégie en raison de problèmes lors de l'enregistrement d'objets dans le magasin ou en raison de la suppression accidentelle ou intentionnelle d'objets du magasin.
206
Remarque : une stratégie IPSec créée dans Windows XP ou Windows Server 2003 et qui utilise de nouvelles fonctions alors disponibles dans ces versions risque de voir ces fonctions supprimées silencieusement si une stratégie est ultérieurement modifiée et enregistrée par le composant logiciel enfichable MMC Gestion de stratégie IPSec sous Windows 2000. Cependant, si un système Windows 2000 extrait une stratégie IPSec dotée de fonctions supplémentaires, il les ignore, ce qui peut, soit changer le comportement de la stratégie IPSec lorsqu'elle est utilisée sur un système Windows 2000, soit avoir aucun impact sur le comportement de la stratégie. Un problème connu relatif au composant logiciel enfichable MMC Gestion de stratégie IPSec se produit lors de la gestion de la stratégie IPSec dans Active Directory ou sur un ordinateur distant. Si le composant logiciel MMC est exécuté sur une liaison lente, l'enregistrement de tous les changements d'une stratégie volumineuse peut être long. Si la fenêtre du composant logiciel MMC est fermée, tous les objets ou changements d'une stratégie IPSec qui ne sont pas encore enregistrés sont perdus. Cette fonctionnalité peut entraîner la corruption de la stratégie IPSec. Si le composant logiciel enfichable MMC Gestion de stratégie IPSec est exécuté sur une liaison lente, utilisez une session Bureau à distance pour exécuter le composant en tant que processus local. Généralement, tout script d'outil de ligne de commande permettant de créer une stratégie IPSec doit être testé. Pour ce faire, créez une stratégie dans le magasin local et affichezla en utilisant le composant MMC Gestion de stratégie IPSec pour vérifier son intégrité. Des ordinateurs de test doivent appliquer la stratégie locale et étudier les détails dans le composant MMC Moniteur IPSec pour confirmer l'ordre de filtrage attendu. Les procédures permettant de dépanner et de résoudre des erreurs de lecture et de corruption de la stratégie IPSec dépendent de l'emplacement de stockage. Cette solution utilise une stratégie IPSec basée sur domaine uniquement, mais d'autres types de stratégies IPSec ont pu être configurés de façons qui entraînent des problèmes. Les procédures de dépannage de chaque type de stratégie sont décrites dans le reste de cette section. Généralement, le support de niveau 2 doit être capable d'utiliser les outils de la ligne de commande ou les outils de l'interface graphique utilisateur pour confirmer que la stratégie IPSec appropriée est en cours d'extraction et que cette stratégie est correctement interprétée. Les étapes de la suppression de chaque type de stratégie sont indiquées ici. L'objectif de l'actualisation de la stratégie est d'installer une stratégie correcte. S'il est impossible d'extraire ou d'installer une stratégie correcte à partir des scripts, alors le problème est transféré au support de niveau 3. Stratégie IPSec au démarrage L'utilitaire Netsh permet la configuration d'options de mode d'amorçage et d'exemption d'amorçage prises en charge par Windows Server 2003 uniquement. La configuration est stockée dans les clés de registre suivantes avec les valeurs par défaut affichées :
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ OperationMode=3 (avec état)
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ BootExemptList = (exemption pour DHCP entrant, voir cidessous)
La valeur OperationMode par défaut nécessite que le pilote IPSec procède au filtrage avec état du trafic sortant. Si le service IPSec est en cours d'exécution, utilisez la commande Netsh ipsec dynamic show config pour afficher la configuration de démarrage. Si le service IPSec n'est pas en cours d'exécution (par exemple, dans le cas d'un démarrage en mode sans échec), vous pouvez utiliser les outils du registre pour examiner la valeur de la clé du registre et la modifier.
207
Pour résoudre les problèmes de trafic provoqués par le filtrage avec état d'IPSec au démarrage, définissez le pilote IPSec afin qu'il autorise le trafic au démarrage au lieu d'effectuer le filtrage avec état. Si le service IPSec est en cours d'exécution, utilisez netsh ipsec dynamic set config bootmode value=permit pour définir le mode de démarrage sur autoriser. Si le service IPSec n'est pas en cours d'exécution, utilisez un outil de registre pour modifier la valeur d'autorisation OperationsMode=1. En outre, le pilote IPSec n'applique pas le mode de sécurité au démarrage si le service IPSec est configuré pour un démarrage manuel ou s'il est désactivé. Une fois que le service est configuré pour un démarrage manuel ou qu'il est désactivé, redémarrez l'ordinateur pour que le pilote IPSec soit chargé en mode autoriser. Stratégie IPSec persistante La stratégie persistante est prise en charge par Windows XP et Windows Server 2003. L'une des situations d'erreur les plus courantes survient lorsqu'une stratégie persistante existante n'est pas supprimée avant la définition d'une nouvelle stratégie persistante et que cette dernière entre en conflit avec des paramètres déjà attribués. La solution décrite dans ce guide n'utilise pas la stratégie persistante. Cependant, puisque cette stratégie est utilisée dans certains environnements, des instructions de dépannage sont fournies dans ce chapitre. La clé de registre de la stratégie persistante existe par défaut et est vide : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Persistent Sous Windows XP, le meilleur moyen de détecter une stratégie persistante est de constater que la clé de registre n'est pas vide. La commande ipseccmd show indique la stratégie active contenue dans le service IPSec et ne signale pas qu'un paramètre particulier a été généré par la stratégie persistante. Le service IPSec supprime le nom des règles de la stratégie persistante lorsqu'il interprète la stratégie avec les paramètres actifs. Étant donné que la commande ipseccmd ne fournit pas le nom des filtres et des actions de filtrage, il n'est pas possible d'utiliser des conventions de dénomination pour indiquer les filtres et les actions de filtrage issus de la stratégie persistante. Les filtres portent des noms de type « text2pol{GUID} » chaque fois qu'ils sont créés par les outils ipsecpol.exe ou ipseccmd.exe, qui incluent des entrées de la stratégie persistante. Toutefois, les stratégies locales ou de domaine créées à l'aide de scripts pourront aussi porter ces noms. La stratégie persistante est appliquée en premier et fusionne avec la stratégie IPSec locale ou de domaine. Ainsi, vous devez supprimer l'attribution des stratégies locale et de domaine avant de pouvoir afficher les paramètres persistants. Utilisez ipseccmd show all pour afficher toutes les stratégies actives, y compris les paramètres persistants, lorsque le service IPSec est démarré. Pour supprimer tous les objets (règles, listes de filtres et actions de filtrage) associés à une stratégie persistante particulière, indiquez le nom de cette stratégie dans la commande suivante : ipseccmd.exe -w PERS -p "policy name" –o Pour vous assurer qu'une stratégie persistante est supprimée, supprimez toutes les sousclés de la clé Persistent. Cependant, si vous supprimez la clé Persistent, puis que vous lancez de nouvelles commandes ipseccmd pour créer une stratégie persistante, cellesci échoueront. Pour résoudre le problème de corruption des stratégies persistantes et les conflits, supprimez tous les objets présents dans le magasin de la stratégie persistante, puis reéxécutez le script ipseccmd pour recréer la stratégie. Sous Windows Server 2003, la stratégie persistante possède des fonctionnalités de gestion complètes semblables à celles des stratégies IPSec locales et de domaine. La stratégie persistante est stockée à l'emplacement du registre référencé précédemment. Le script de commande Netsh suivant permet 208
d'afficher la stratégie persistante configurée à l'aide des commandes du fichier show_persistent.netsh : Netsh –f show_persistent.netsh Le fichier show_persistent.netsh est un fichier texte contenant les lignes suivantes : Pushd ipsec static Set store persistent show all exit Le script de commande Netsh suivant sert à supprimer toutes les stratégies persistantes : pushd ipsec static set store persistent delete all exit Stratégie IPSec locale La stratégie IPSec locale est prise en charge par Windows 2000, Windows XP et Windows Server 2003, et elle est stockée sous la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local Si une stratégie locale est attribuée, celleci sera stockée dans la clé de la manière suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local\ActivePolicy Si aucune stratégie de domaine n'est attribuée, alors la stratégie locale attribuée sera ajoutée à une stratégie persistante configurée afin de devenir la stratégie active. Pour faciliter considérablement le dépannage, il est recommandé de modifier les stratégies IPSec créées par les scripts ipsecpol ou ipseccmd au moyen du composant logiciel enfichable MMC Gestion de stratégie IPSec afin de définir un nom pour chaque filtre avant de les utiliser dans des environnements de production. Vous pouvez aussi utiliser la commande netsh ipsec pour créer la stratégie sur un système Windows Server 2003, puis l'exporter vers un fichier compatible avec des systèmes Windows 2000 et Windows XP ou l'importer dans un domaine après que la stratégie aura été testée. Sous Windows 2000, utilisez la commande netdiag /test:ipsec /debug pour afficher les détails de l'attribution de la stratégie et la stratégie active. Vous devez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec ou les outils du registre pour supprimer les objets de la stratégie IPSec situés dans le magasin local. Pour forcer le rechargement de la stratégie IPSec attribuée, arrêtez puis redémarrez le service. Sous Windows XP, utilisez la commande ipseccmd show gpo ou netdiag /test:ipsec pour afficher les détails de l'attribution de la stratégie et la stratégie active. Utilisez le composant logiciel enfichable MMC Gestion de stratégie IPSec, les outils du registre ou la commande ipseccmd.exe w REG p "<policy_name>" –o pour supprimer la stratégie IPSec nommée. Pour supprimer facilement une stratégie locale, supprimez toutes les sousclés de l'emplacement de stockage précédemment référencé.
209
Pour obliger le service IPSec à recharger la stratégie, arrêtez le service IPSec, puis redémarrezle ou supprimez l'attribution de la stratégie IPSec, puis attribuezla de nouveau à l'aide du composant logiciel MMC Gestion de stratégie IPSec. Il est également possible d'utiliser la commande sc policyagent control 130 pour recharger la stratégie. Une fois la stratégie rechargée, toutes les associations de sécurité IKE et IPSec sont supprimées, ce qui peut entraîner des retards ou des interruptions de connectivité sur les ordinateurs qui utilisaient activement les SA IPSec pour transmettre et recevoir le trafic. Sous Windows Server 2003, utilisez la commande, netsh ipsec static show gpoassignedpolicy le composant logiciel enfichable MMC Gestion de stratégie IPSec ou le nœud Stratégie active du moniteur IPSec pour afficher la stratégie locale actuellement attribuée. Utilisez la commande netsh ipsec dynamic show all pour afficher la configuration de la stratégie active. Vous pouvez aussi utiliser le Moniteur IPSec pour inspecter différentes parties de la stratégie active. Pour supprimer puis recharger la stratégie locale sous Windows Server 2003, utilisez les mêmes commandes que celles répertoriées pour Windows XP. La commande netsh ipsec peut servir à supprimer l'attribution d'une stratégie, à l'attribuer de nouveau et à la supprimer. Stratégie IPSec Active Directory Cette stratégie est prise en charge par Windows 2000, Windows XP et Windows Server 2003. La stratégie IPSec de domaine attribuée est stockée dans le registre local à l'emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy Le cache du registre local de la stratégie de domaine est stocké sous : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Cache Le magasin d'annuaire doit être géré par le composant logiciel enfichable MMC Gestion de stratégie IPSec ou par la commande netsh ipsec exécutée en tant que processus local dans Active Directory. Il n'existe aucun outil qui vous permette d'afficher directement le contenu du cache. Vous devez utiliser un outil du registre pour savoir si le cache existe et s'il possède le contenu approprié. De la même manière, les outils du registre servent à supprimer la stratégie de domaine en supprimant les clés de registre GPTIPSecPolicy et Cache. Ensuite, vous devez soit redémarrer le service IPSec, soit utiliser la commande de contrôle de services pour forcer le rechargement de la stratégie IPSec sans la stratégie de domaine. Pour actualiser l'attribution de la stratégie IPSec de domaine, recharger la stratégie IPSec et mettre à jour le contenu du cache, utilisez la commande gpudpate /force. Pour bloquer temporairement l'application de la stratégie de domaine à l'ordinateur local, vous pouvez configurer les autorisations sur les clés de registre GPTIPSecPolicy et Cache afin de refuser l'accès en lecture au compte système local. Le composant logiciel enfichable MMC Moniteur de sécurité IPSec et les outils de ligne de commande continueront à indiquer que la stratégie de domaine est attribuée car ces outils lisent les informations GPTIPSecPolicy exécutées dans le contexte de l'administrateur local. Pour un blocage à plus long terme de la stratégie IPSec basée sur le domaine, vous devez empêcher l'ordinateur de lire l'objet GPO approprié dans Active Directory.
210
Sous Windows 2000, vous pouvez rencontrer les erreurs suivantes en cas de problème lié à la stratégie :
• Impossible d'effectuer la liaison avec le schéma de l'annuaire. Le service Agent de stratégie
IPSec n'a pas pu effectuer de liaison LDAP authentifiée au conteneur de stratégies de sécurité IP Active Directory. Cette erreur est probablement apparue parce que le compte de l'ordinateur n'a pas réussi à se connecter et à obtenir les informations d'identification Kerberos, ou parce que le protocole Kerberos ne réussit pas à émettre le ticket du service LDAP pour le service Agent de stratégie IPSec.
• Impossible d'effectuer la liaison avec l'objet Stockage de stratégie IPSEC. Un objet a été
défini dans la stratégie IPSec (une règle ou une liste de filtrage, par exemple) qui n'existe pas. Il est possible que la stratégie IPSec ou la stratégie de stockage Active Directory soit corrompue, ou que l'objet ait été supprimé (bien que les stratégies IPSec existantes continuent à le référencer). Étudiez la stratégie IPSec en utilisant le composant logiciel enfichable MMC Gestion de stratégie IPSec pour voir si toutes les règles de la stratégie sont intactes et si les propriétés Échange de clés (de l'onglet Général) peuvent être affichées correctement.
• Impossible de trouver le contrôleur de domaine. Assurezvous que l'ordinateur est membre du domaine et vérifiez la connectivité réseau. Le module de stockage de la stratégie IPSec n'a pas réussi à trouver un annuaire LDAP à partir duquel extraire la stratégie IPSec basée sur le domaine.
• Impossible de communiquer avec le service d'annuaire sur le contrôleur de domaine.
Contactez votre administrateur système. Le module de stockage IPSec n'a pas réussi à utiliser les fonctions de signature et de scellement de LDAP pour télécharger la stratégie IPSec attribuée.
• Impossible de trouver l'objet dans l'emplacement de stockage. Cette erreur est généralement
grave, car elle signifie que la stratégie IPSec ne peut pas être extraite en totalité et donc ne fonctionnera pas correctement. Le module Stockage de la stratégie IPSec n'a pas réussi à trouver le GUID de l'objet (règle, liste de filtres, action de filtrage ou paramètres ISAKMP) contenu dans la stratégie IPSec ou l'une des règles en utilisant un appel LDAP ou un appel de registre distant. Cette erreur peut être provoquée par : • des retards de réplication au cours desquels l'objet « référençant » arrive avant l'objet référencé ou des requêtes sont dirigées vers deux contrôleurs de domaine différents ; • la suppression de l'objet alors qu'il était toujours utilisé par la stratégie IPSec ; • des autorisations qui ne permettent pas d'énumérer ou de lire l'objet, ou le stockage de la stratégie IPSec a été restauré à une heure antérieure à la création de l'objet ; • la corruption de la stratégie IPSec qui génère un GUID incorrect dans la requête ; • l'indisponibilité de la connectivité réseau pour l'adresse IP de destination ; • l'indisponibilité du service LDAP ou du registre distant.
• Impossible de terminer l'opération requise. Le stockage de stratégie n'est pas ouvert. Il est impossible d'ouvrir le magasin Active Directory, de l'ordinateur distant ou de l'ordinateur local. Cette erreur est généralement causée par un échec d'autorisation ou d'authentification.
• L'utilisation de la stratégie de registre local actif, du fait que (i) il n'y a pas de stratégie de stockage Active Directory ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache. Cet événement indique que la stratégie IPSec est définie localement sur l'ordinateur et que la stratégie de domaine n'a pas pu être appliquée pour la remplacer.
• N'utiliser aucune stratégie Ipsec, du fait que (i) il n'y a pas de stockage Active Directory ou de stratégie de registre local active ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache ou pas de stratégie de registre local active. Cet événement identifie l'état par défaut dans lequel aucune stratégie n'est attribuée à l'ordinateur.
211
Sous Windows XP et Windows Server 2003, les événements suivants indiquent que le service IPSec n'a pas réussi à retrouver un type de stratégie spécifique. Si une stratégie locale ne peut pas être lue sous Windows Server 2003 et Windows XP SP2, elle est ignorée et la stratégie attribuée suivante dans l'ordre de persistance est lue.
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage persistant sur l'ordinateur
pour <nomstratégie> avec le code d'erreur. Le service IPSec a détecté qu'une stratégie persistante était attribuée et stockée dans le registre local, mais n'a pas réussi à lire le contenu d'au moins un des objets de la stratégie persistante. Vérifiez les autorisations dans les clés de registre. La stratégie est peutêtre corrompue. Supprimez la stratégie persistante, puis recréezla.
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage locale sur l'ordinateur pour
<nomstratégie> avec le code d'erreur. Le service IPSec a détecté qu'une stratégie locale était attribuée et a tenté de la lire, mais une erreur s'est produite lors de la lecture d'au moins un des objets associés à la stratégie attribuée. Vérifiez les autorisations dans les clés de registre. La stratégie est peutêtre corrompue : vous devez la supprimer, puis la recréer.
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage d'annuaire sur l'ordinateur
pour <nomstratégie> avec le code d'erreur. Le service IPSec a rencontré au moins une erreur lors de la lecture de la stratégie IPSec attribuée à partir d'Active Directory. Ce problème peut être causé par une erreur de connectivité réseau avant que tous les objets aient pu être extraits ou par des objets absents de la stratégie IPSec ou par des objets ne possédant pas d'autorisation en lecture.
• Le moteur PAStore a effectué un sondage pour détecter des modifications apportées à la stratégie
IPSec Active Directory, a détecté que Active Directory est inaccessible et a migré vers l'utilisation de la copie mise en cache de la stratégie IPSec Active Directory. Toutes les modifications apportées à la stratégie IPSec Active Directory depuis le dernier sondage n'ont pas été appliquées. Ce message indique simplement qu'à un intervalle de sondage régulier, le service IPSec n'a pas réussi à contacter Active Directory (par exemple, en raison de la perte du service DNS) et qu'aucune modification n'a été apportée à la stratégie IPSec active. La connectivité à Active Directory était disponible à l'origine lorsque la stratégie active était appliquée et que le service IPSec avait extrait et stocké la version la plus récente dans le cache. Par conséquent, le service IPSec considère à présent le cache du registre de la stratégie de domaine IPSec comme la source principale de stratégie. Le sondage en vue de contacter l'annuaire va continuer.
Dépannage de l'interprétation de la stratégie IPSec L'interprétation de la stratégie IPSec a lieu après l'extraction de la stratégie complète de l'emplacement de stockage approprié. Les adresses IP actuelles de l'interface réseau sont utilisées pour développer les filtres génériques de la stratégie en filtres spécifiques. Ensuite, la liste des filtres entrants et sortants spécifiques est chargée dans le pilote IPSec en vue du traitement des paquets. Les événements de modification de l'interface sont signalés au service IPSec, qui ajuste la configuration du filtre IPSec dans le pilote IPSec aussi rapidement que possible, si nécessaire (par exemple, pour les filtres Mon adresse IP). Sous Windows 2000, les messages suivants peuvent indiquer un problème d'interprétation ou de configuration des composants IPSec pour appliquer la stratégie :
• L'attribut Type de données spécifie un format de données non reconnu. Une partie de la
stratégie IPSec contient un format de données que le moteur de stockage de la stratégie ne reconnaît pas. Cette erreur est le signe d'une corruption de la stratégie ou peut indiquer un problème futur de version de la stratégie. Les fonctions de la stratégie IPSec de Windows XP et Windows Server 2003 sont conçues pour être transparentes pour l'Agent de stratégie IPSec de Windows 2000.
212
• Impossible de lire des données à partir du blob. Le format de données de l'attribut IPSecData dans un objet de stratégie IPSec ne correspond pas au format prévu. Cette erreur indique pratiquement toujours une corruption de la stratégie ou un problème de version. Vous devez la corriger avant de pouvoir appliquer tous les paramètres de la stratégie IPSec comme vous le souhaitez.
• L'Agent de stratégie n'a pas de liste d'interfaces. L'Agent de stratégie n'a pas trouvé d'interface réseau IP à filtrer. Notez que l'erreur dans le texte de ce message provient directement du code source Windows, et elle apparaîtra de la manière illustrée ici.
• L'Api d'aide publique Ip n'a pas pu obtenir la table d'interfaces. Les filtres basés sur les
interfaces ne seront pas étendus et connectés au pilote Ipsec. Une erreur s'est produite lorsque l'Agent de stratégie a tenté d'énumérer la liste des interfaces de l'ordinateur. Il est possible qu'il n'y ait pas d'interface réseau ou qu'il existe une erreur dans le gestionnaire des interfaces réseau. Des périphériques qui ne sont pas complètement compatibles PnP, la corruption des fichiers ou des problèmes liés au pilote NIC ou à d'autres composants réseau de Windows peuvent être à l'origine de cette erreur : les filtres IPSec basés sur le type d'interface, comme ceux configurés dans une règle pour un type de connexion particulier (l'accès à distance, par exemple) plutôt que pour toutes les connexions. Si le problème persiste après le redémarrage de l'ordinateur, contactez les services de support technique Microsoft.
• L'Api d'aide publique Ip n'a pas pu obtenir la table d'adresse IP. Les filtres basés sur les interfaces ne seront pas étendus et connectés au pilote Ipsec. Une erreur s'est produite lorsque l'Agent de stratégie IPSec a tenté d'énumérer toutes les adresses IP de l'ordinateur en utilisant un appel de fonction de l'API de l'application d'assistance IP. Il est possible qu'aucune adresse IP ne soit configurée ou qu'il existe des problèmes semblables à ceux mentionnés ci dessus.
• L'index d'entrée de l'adresse IP n'a pas été trouvé dans la table d'interfaces. Rejet de
l'adresse IP. L'Agent de stratégie IPSec confirme que toutes les adresses IP apparaissent dans la liste des interfaces réseau. Ce problème est dû à des conditions passagères lorsqu'une nouvelle interface réseau est ajoutée ou supprimée. Ce message indique que le service IPSec ne va pas créer de filtres spécifiques pour cette adresse IP rejetée, pour les filtres génériques Mon adresse IP de la stratégie, ce qui pourrait apparaître comme un comportement de connectivité inattendu lors de l'utilisation de cette adresse IP. Cette erreur peut également révéler un problème de l'état interne de la configuration de l'interface IP que les services de support technique Microsoft devront examiner en détail. Puisque l'adresse IP est rejetée par l'Agent de stratégie IPSec (non par la pile TCP/IP), aucun filtre IPSec ne sera créé pour cette adresse IP. Ainsi, aucune action de sécurité (de type autoriser ou bloquer, par exemple) et aucune négociation des associations de sécurité IPSec ne sera réalisée pour le trafic au moyen de cette adresse IP.
• Un miroir de filtre correspondant existe dans la liste des filtres. Cette erreur signale une
condition de filtre dupliqué dans la stratégie IPSec. Vous devez analyser la conception de la stratégie IPSec pour vous assurer que les filtres spécifiques au mode rapide pour les directions entrante et sortante ne sont pas dupliqués.
• Aucun filtre n'a été ajouté à la liste de filtres principale. L'Agent de stratégie IPSec n'a trouvé
aucun filtre dans la stratégie IPSec extraite du stockage. Il est possible que celleci contienne uniquement la règle de réponse par défaut ou que des erreurs soient survenues lors de la lecture des règles ou des listes de filtrage.
• Zéro offre pour la phase 1. Rejet de la stratégie ISAKMP. Si aucune méthode de sécurité en mode principal IKE n'a été trouvée (objets de stratégie ISAKMP), cela signifie que la stratégie IPSec est probablement corrompue.
• Zéro offre pour la phase 2. Rejet de la stratégie de négociation. Sans aucune méthode de
sécurité dans l'action de filtrage (offres de la phase 2 du mode rapide IKE), IKE ne réussira pas les négociations en mode rapide pour le trafic adapté aux filtres correspondants. La stratégie IPSec est probablement corrompue. 213
• La stratégie ne contient pas d'offres valides. La stratégie IPSec ne contient aucune méthode de sécurité valide dans l'action de filtrage d'une règle ou ne contient aucun paramètre pour le mode principal IKE (paramètres Échange de clés configurés sous l'onglet Général).
• L'Agent de stratégie a tenté d'insérer un filtre existant dans IPSEC. Le pilote IPSec a détecté
un filtre dupliqué et rejette le doublon. Cette situation est sans conséquence si le filtre dupliqué possède la même action que celui déjà traité par le pilote IPSec. Toutefois, si les actions des filtres sont différentes, la conception de la stratégie IPSec n'est pas prise en charge. Les résultats peuvent différer après une période donnée et dépendent de l'ordre dans lequel le changement de stratégie est traité. La stratégie IPSec doit être conçue de manière à éviter les filtres dupliqués.
• Impossible d'ajouter une entrée à la table de stratégies IPSEC. L'Agent de stratégie IPSec n'a pas réussi à ajouter un nouveau filtre au pilote IPSec. Cette erreur signifie que tout le trafic correspondant à ce filtre ne sera pas sécurisé. Elle peut avoir pour origine une condition de mémoire noyau faible. Si l'erreur persiste, contactez les services de support technique Microsoft.
• L'Agent de stratégie n'a pas pu insérer ou mettre à jour un filtre dans IPSEC. Comme pour le message précédent sur l'ajout d'un filtre, la liste des filtres du pilote IPSec ne correspond pas aux besoins de la stratégie IPSec appliquée. C'est pourquoi le niveau de sécurité offert n'est pas approprié.
• L'utilisation de la stratégie de cache, en tant que stratégie de stockage Active Directory n'a
pas pu être appliquée correctement (réseau non joignable, intégrité de la stratégie non valide, etc.). Lorsqu'une stratégie IPSec de domaine est attribuée, l'Agent de stratégie IPSec tente de lire la toute dernière stratégie depuis Active Directory en premier lieu. Ce message indique que l'Agent n'a pas pu extraire la stratégie IPSec du service d'annuaire et qu'il applique la stratégie de la dernière stratégie de domaine, mise en cache dans le registre.
Sous Windows Server 2003, les événements suivants indiquent qu'un problème d'interprétation de la stratégie IPSec a pu se produire. Dans la plupart des cas, Windows XP utilise le même texte d'événement. Ces problèmes doivent être résolus pour que la stratégie IPSec fonctionne correctement.
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage persistante sur l'ordinateur
pour <nomstratégie> avec le code d'erreur :. Le service IPSec a trouvé la stratégie persistante configurée dans le registre mais n'a pas réussi à l'appliquer. Toute stratégie persistante déjà appliquée est supprimée, et le pilote IPSec sera programmé en mode de blocage (avec des exemptions d'heure de démarrage) comme indiqué dans un message distinct.
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage du Registre local sur
l'ordinateur pour <nomstratégie> avec le code d'erreur. Ce message indique que le service a rencontré au moins une erreur lors de l'application de la stratégie IPSec locale à partir du registre local. Il peut aussi signifier que la stratégie est corrompue ou que les autorisations sont incorrectes.
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage Active Directory sur
l'ordinateur pour le DN. Le service IPSec a trouvé la stratégie de domaine spécifiée par le nom de domaine dans la clé de registre GPTIPSecPolicy mais n'a pas réussi à l'appliquer. Il s'agit d'un message informatif qui indique dans la plupart des cas que les clients mobiles ne peuvent pas contacter le contrôleur de domaine ; ce message doit être suivi par une application réussie de la stratégie mise en cache (si elle existe). Cependant, il peut aussi indiquer qu'un objet GPO fournit une stratégie IPSec qui n'existe pas, qui ne peut pas être lue ou qui est corrompue.
• Le moteur PAStore n'a pas pu appliquer la copie mise en cache localement de la stratégie IPSec
de stockage Active Directory sur l'ordinateur pour <nomstratégie> avec le code d'erreur :. Ce message signale que le service IPSec sait que la stratégie de domaine doit être attribuée et qu'il a déjà échoué dans l'application de la stratégie extraite d'Active Directory.
214
Il a maintenant rencontré au moins une erreur lors de l'application de la copie mise en cache de la stratégie de domaine attribuée à partir du registre local. Cette erreur peut signifier que le cache est corrompu ou que les autorisations sont incorrectes. Cette condition est grave car aucune stratégie de domaine n'a pu être appliquée, ce qui pourrait affecter la connectivité avec les autres membres du domaine d'isolation. La stratégie locale (si elle est définie) est la suivante dans l'ordre de priorité.
• Le moteur PAStore n'a pas pu appliquer certaines règles de la stratégie IPSec active
<nomstratégie> sur l'ordinateur avec le code d'erreur :. Exécutez le composant logiciel enfichable Moniteur IPSec pour diagnostiquer le problème. Ce problème se produit généralement en combinaison avec d'autres problèmes cités ici, lorsqu'il n'existe pas de méthode (offre) de sécurité en mode rapide, par exemple.
• Les services IPSec n'ont pas pu obtenir la liste complète des interfaces réseau de cet ordinateur.
Cela peut représenter un risque potentiel pour la sécurité de cet ordinateur car certaines interfaces réseau n'obtiendront peutêtre pas la protection telle qu'elle était voulue par les filtres IPSec appliqués. Exécutez le composant logiciel enfichable Moniteur IPSec pour diagnostiquer ce problème. Ce message remplace les différents messages de l'API de l'application d'assistance IP utilisés sous Windows 2000. Il s'agit d'une erreur bénigne si elle se produit lors de l'ajout et de la suppression d'interfaces ou lorsque l'état de la connexion change (quand un réseau sans fil n'est plus dans l'intervalle valide, par exemple). Elle est aussi sans importance si elle intervient durant une reprise après l'utilisation des modes Mise en veille ou Mise en veille prolongée et qu'une configuration d'interface réseau différente existe et est détectée au cours de l'étape de reprise.
Problèmes de configuration de la stratégie avec le réseau privé virtuel RRAS Comme nous l'avons mentionné dans la section consacrée au support de niveau 1 plus haut dans ce chapitre, le service RRAS est une source courante de conflits avec la stratégie IPSec dans certaines entreprises. Cette section explique pourquoi la stratégie IPSec intégrée aux serveurs VPN L2TP/IPSec crée un conflit avec la stratégie de domaine utilisée dans cette solution. Cette situation décrit le problème d'un filtre dupliqué. Dans la discussion suivante, la conception de la stratégie IPSec utilisée dans le scénario Woodgrove Bank est utilisée pour illustrer les problèmes. Toutefois, les principes s'appliquent à de nombreux déploiements d'IPSec en entreprise. La stratégie IPSec pour les serveurs L2TP/IPSec est automatiquement générée par le service du gestionnaire RAS (RASMAN) et comprend les filtres suivants :
• Depuis Toute adresse IP à Mon adresse IP, UDP, source 1701, dest N'importe laquelle (entrante) • Depuis Mon adresse IP à Toute adresse IP, UDP, source N'importe laquelle, dest 1701 (sortante) Remarque : pour plus d'informations sur cette stratégie, reportezvous à l'article 248750 de la Base de connaissances, Description of the IPSec policy created for L2TP/IPSec (Description de la stratégie IPSec créée pour L2TP/IPSec) à l'adresse http://support.microsoft.com/?kbid=248750. Par conséquent, le filtre spécifique au mode principal qui contrôle la réponse de la négociation IKE à ce serveur est l'adresse du filtre entrant :
• Depuis Toute adresse IP à Mon adresse IP > Authentification par certificat Notez que l'utilisation de Mon adresse IP provoque le développement du filtre entrant pour chaque adresse IP du serveur VPN. En supposant que le serveur VPN possède une adresse IP d'interface
215
externe pour la connectivité Internet et une interface interne pour la connectivité LAN, les filtres entrants spécifiques au mode principal IKE sont :
• Depuis Toute adresse IP à > Authentification par certificat • Depuis Toute adresse IP à > Authentification par certificat Le second filtre (pour l'interface LAN interne) est plus spécifique que le filtre entrant du mode principal IKE de l'isolation de serveurs et de domaines, c'estàdire :
• Depuis Toute adresse IP à Sousréseau > Authentification Kerberos Par conséquent; lorsqu'un administrateur utilise un client approuvé pour gérer le serveur VPN, il initie IKE pour l'adresse IP interne du serveur VPN. La recherche de stratégie IKE entrante correspondra au filtre plus spécifique du mode principal et répondra avec les paramètres du mode principal IKE pour L2TP. L'authentification par certificat sera utilisée à la place de l'authentification Kerberos utilisée pour cette solution. Un second cas de conflit peut survenir si le client VPN Internet utilise les fonctions de mise en quarantaine du client Gestionnaire de connexion. Ce client doit transmettre une « clé de quarantaine » à l'adresse IP LAN interne du serveur VPN pour mettre fin à la quarantaine et obtenir l'accès VPN total au réseau. Dans ce scénario, la stratégie IPSec de domaine du client VPN est appliquée à partir du cache lorsque le portable démarre. Lorsque la connexion de quarantaine VPN est établie, une adresse IP interne est attribuée au client VPN. L'adresse IP interne du client peut être dissimulée par l'un des filtres de sousréseau (N'importe lequel <> Sousréseau interne) défini dans la stratégie IPSec de l'isolation de domaines. Ce filtre est requis pour que les clients VPN disposent d'un accès authentifié par IPSec de bout en bout via le tunnel VPN aux serveurs internes et aux autres stations de travail auxquelles ils accèdent. Cependant, les filtres de sousréseau de cette solution initient une négociation IKE à partir de l'adresse IP interne de l'interface virtuelle du tunnel VPN du client vers l'interface LAN interne du serveur VPN. Le mode principal IKE échouera car le serveur répondra pour accepter uniquement l'authentification par certificat, laquelle n'est pas compatible avec la stratégie utilisée pour l'isolation de domaines et de serveurs. Même si la stratégie n'a pas permis l'authentification par certificat, le mode rapide IKE du client proposera le filtre pour tout le trafic, et le serveur VPN échouera la négociation car le filtre proposé est trop général. Le serveur VPN n'acceptera que les filtres en mode rapide spécifiques à L2TP : UDP source 1701, destination N'importe laquelle ou UDP source 1701, destination 1701. Vous pouvez utiliser les options suivantes pour résoudre le conflit entre la stratégie L2TP/IPSec du serveur RRAS et la stratégie d'isolation.
• Ajoutez les adresses IP LAN internes du serveur RRAS à la liste d'exemptions. • Désactivez les ports L2TP sur les serveurs VPN. Utilisez uniquement les ports PPTP (Point to Point Tunneling Protocol, Protocole de tunnel point à point).
• Désactivez la stratégie IPSec automatique pour L2TP en utilisant la clé de registre ProhibitIPSec
pour RASMAN. Personnalisez manuellement la configuration de la stratégie IPSec pour L2TP afin qu'elle utilise uniquement l'adresse IP externe pour l'authentification par certificat pour le trafic UDP 1701 et uniquement l'adresse IP interne pour l'authentification Kerberos pour le trafic d'isolation de domaines.
Remarque : pour plus d'informations sur cette configuration, reportezvous à l'article 240262 de la Base de connaissances How to Configure a L2TP/IPSec Connection Using Preshared Key
216
Authentication (Comment faire pour configurer une connexion L2TP/IPSec en utilisant l'authentification par clé prépartagée) à l'adresse http://support.microsoft.com/kb/240262. La solution la plus simple de cette liste est la première, qui exempt la carte réseau interne du serveur RRAS d'utiliser IPSec.
Dépannage d'IKE L'échec d'IKE et d'IPSec lors du déploiement initial est principalement dû au filtrage réseau qui n'autorise pas les paquets du protocole UDP 500 ou IPSec. C'est pourquoi il est utile d'établir une station de travail IP ou un serveur IP statique pour les tests de stratégie simple, comme dans l'exemple de la stratégie prédéfinie de serveur (requête) qui utilise une clé prépartagée. L'audit doit être activé pour capturer les événements d'audit IKE. Une stratégie IP de domaine par défaut est déployée pour tous les membres de domaine qui s'authentifient avec la même clé prépartagée et contient une règle avec un filtre pour la totalité du trafic (y compris ICMP) pour tester l'adresse IP de l'ordinateur. Ensuite, le script de connexion est déployé pour exécuter une requête ping ou nbtstat –n , qui déclenchera la négociation IKE à partir de tous les membres de domaine en vue de tester le serveur. En analysant et en résumant les adresses IP dans les audits des succès du mode principal IKE, vous pouvez déterminer si tous les ordinateurs reçoivent la stratégie et vérifier que toutes les zones de votre réseau peuvent accéder à l'ordinateur test en utilisant les protocoles IKE et IPSec. Un test plus avancé confirmerait que l'encapsulation IPSec fonctionne avec la fragmentation pour chaque zone du réseau à l'aide de ping –l 5000 depuis le serveur test à destination des ordinateurs situés dans chaque zone. L'option –l 5000 entraîne la création d'une surchage de paquet ICMP de 5 000 octets par l'utilitaire Ping. Ce paquet IP complet sera encapsulé par le protocole IPSec, puis fragmenté par la couche IP avant d'être placé sur le réseau. Tous les fragments doivent être reçus à destination ; une réponse consistant en un nombre égal de fragments est renvoyée. L'expérience a montré que les périphériques encombrés ou servant de limite entre des réseaux aux vitesses différentes (par exemple, les réseaux Ethernet de 1 et 100 mégabits) peuvent rencontrer des problèmes de transmission des fragments. De la même manière, les hôtes résidant sur des liaisons MTU différentes, (comme le mode ATM (Asynchronous Transfer Mode, mode de transfert asynchrone), l'interface FDDI (Fiber Distributed Data Interface, interface de transmission de données réparties via fibre optique) et le mode Token Ring) requièrent des messages PMTU ICMP pour découvrir correctement l'unité MTU du chemin réseau pour les paquets TCP protégés par IPSec. Reportezvous à l'article 314496 Default MTU Size for Different Network Topology (Taille de MTU par défaut pour différentes topologies de réseaux) de la Base de connaissances à l'adresse http://support.microsoft.com/kb/314496 pour obtenir des informations sur les différentes valeurs MTU réseau par défaut. Dépannage de la négociation IKE Il peut s'avérer difficile de dépanner IKE car certaines erreurs peuvent se produire dans certaines conditions uniquement, par exemple, lorsque le mode rapide IKE est initié à partir d'un ordinateur qui est le répondeur. Les erreurs peuvent également être provoquées par des échecs du système d'authentification (erreurs du protocole Kerberos, par exemple) ou lorsque des conceptions de stratégie incompatibles ou des stratégies préexistantes fusionnent avec la stratégie de domaine. Les défaillances d'IKE entraînent l'arrêt de la participation à la négociation IKE de l'ordinateur qui subit l'échec, alors que l'autre ordinateur participant à la négociation va tenter de se connecter jusqu'à épuisement du nombre de tentatives alloué. Si IKE échoue, étudiez cet échec et les journaux sans effectuer de modification. Vous pouvez activer l'audit standard de façon dynamique sans changer la configuration IPSec ou l'état d'exécution du service. Toutefois, sous Windows 2000, vous devez redémarrer le service IPSec pour activer la journalisation détaillée d'IKE dans le fichier Oakley.log. 217
Sous Windows XP SP2 et Windows Server 2003, vous pouvez activer et désactiver la journalisation d'IKE via la ligne de commande lorsque cela est nécessaire. Dans certaines situations, il est nécessaire d'arrêter puis de redémarrer le service IPSec afin d'étudier le trafic réseau et de capturer les résultats du fichier Oakley.log à partir d'un état sain. Lorsque le service IPSec est arrêté manuellement ou en tant que partie du redémarrage ou de l'arrêt de l'ordinateur, IKE tente d'envoyer des messages de suppression pour nettoyer l'état de l'association de sécurité IPSec sur tous les pairs connectés. Parfois, le système d'exploitation désactive la fonction d'envoi des paquets avant qu'IKE ait terminé l'envoi des messages de suppression à tous les ordinateurs pairs actifs ; ainsi, l'ordinateur pair conserve l'état de l'association de sécurité IPSec. Lorsque cela se produit, l'ordinateur pair peut « penser » qu'il est connecté de façon sécurisée à l'ordinateur redémarré. Après le redémarrage, si l'ordinateur n'initie pas une nouvelle négociation IKE avec le pair, ce dernier devra patienter cinq minutes pour que les associations de sécurité IPSec soient hors délai avant de tenter de les rétablir. Pour rétablir les associations de sécurité, une négociation en mode rapide est d'abord tentée pendant une minute, suivie d'une initiation en mode principal IKE. La journalisation IKE a été améliorée dans toutes les versions à partir de Windows 2000. Les événements documentés dans cette section s'appliquent à Windows XP et à Windows Server 2003, bien que les événements Windows 2000 soient similaires. Le journal de sécurité Windows est recommandé comme point de départ lorsque vous essayez de déterminer la raison d'un échec de négociation IKE. Pour afficher les événements IKE, l'audit des échecs et des succès doit être activé dans le paramètre de la stratégie de sécurité de groupe Auditer les événements de connexion. Une fois que l'audit est activé, le service IKE crée des entrées d'audit et offre une explication à l'échec de la négociation. Toutefois, l'explication des échecs de la négociation IKE est pratiquement toujours signalée comme un échec de l'événement 547, et il peut exister plusieurs causes possibles pour le même message d'erreur. La liste des échecs de l'événement 547 et les causes potentielles sont décrites en détail dans les sections suivantes. Sous Windows XP SP2 et Windows Server 2003, vous pouvez désactiver tous les audits IKE grâce à la clé de registre DisableIKEAudits. Pensez à vérifier cette valeur sur les ordinateurs contrôlés. Vous pouvez désactiver les audits IKE lorsque ceuxci génèrent trop d'événements de succès ou d'échec et que cela empêche les événements de la catégorie connexion/déconnexion d'être contrôlés de façon efficace. Les valeurs du code d'erreur sont souvent signalées dans les événements d'audit IKE et les détails du journal. Vous trouverez une description de ces valeurs dans Microsoft MSDN®, à la page System Code Errors (1200015999) (Erreurs du code système (1200015999)) à l'adresse http://msdn.microsoft.com/library/enus/debug/base/system_error_codes__1200015999_.asp. Le dépannage de la négociation IKE requiert une connaissance approfondie du comportement attendu de la conception de la stratégie IPSec, du processus de négociation IKE et des événements d'échec IKE. Cette section décrit uniquement les événements les plus courants associés au scénario d'isolation de domaine Woodgrove Bank. Elle ne traite pas tous les événements d'audit IKE ni toutes les conditions d'échec. Une fois que le processus de négociation IKE est bien compris, un suivi réseau depuis au moins un côté de la communication doit être obtenu (si possible) afin d'identifier les problèmes liés à IKE avant de tenter de remplir un fichier Oakley.log. Dans des scénarios d'isolation de serveurs et de domaines, les serveurs déployés doivent disposer de la possibilité d'effectuer un suivi à l'aide du Moniteur réseau. Le fichier Oakley.log propose la journalisation la plus détaillée possible et peut être requis par les deux côtés de la négociation (avec des heures synchronisées). Cependant, si vous activez ce fichier
218
journal, la négociation IKE risque d'être ralentie, ce qui va modifier les conditions de synchronisation et entraîner la perte de l'état existant si le service est redémarré pour lire de nouveau la clé de registre (requis sous Windows 2000 et Windows XP SP1). À l'heure actuelle, il n'existe pas d'instructions publiées permettant d'interpréter le fichier Oakley.log. Dans ce guide, cette interprétation est considérée comme partie intégrante de l'ensemble des compétences de niveau 3. En raison de contraintes liées à l'espace, les extraits issus des détails du journal fournis ici ne concernent que quelques erreurs. Pour obtenir de l'aide sur l'interprétation du fichier Oakley.log, contactez les services de support technique Microsoft. Les quatre fichiers journaux suivants sont créés pour IKE :
• Oakley.log. Journal actuel d'IKE, limité à 50 000 lignes. • Oakley.log.bak. Une fois que le fichier Oakley.log contient 50 000 lignes, ce fichier est créé et un nouveau fichier Oakley.log vide est utilisé. Ce fichier continue à être écrasé autant de fois que nécessaire par le nouveau fichier Oakley.log tant que le service IPSec est exécuté.
• Oakley.log.sav. Le fichier Oakley.log précédent est enregistré sous ce nom lorsque le service IPSec démarre.
• Oakley.log.bak.sav. Le fichier Oakley.log.bak précédent est enregistré sous ce nom lorsque le service IPSec démarre.
Au cours des opérations de dépannage, il arrive fréquemment que l'heure des deux ordinateurs sur lesquels sont effectués la journalisation et le suivi réseau ne soit pas synchronisée. Cette erreur rend la corrélation des journaux difficile, mais pas impossible. La corrélation entre les messages IKE et les paquets du suivi réseau doit faire l'objet d'une vérification croisée à l'aide des cookies d'entête ISAKMP et des champs d'ID de message en mode rapide IKE. Comportements IKE attendus Si l'initiation du mode principal IKE ne peut pas contacter l'adresse IP de destination souhaitée en raison d'un blocage réseau, la communication sécurisée par IPSec ne peut pas être négociée. Si l'initiateur n'est pas configuré pour la communication en texte clair, alors l'échec du contact de la destination apparaîtra en tant qu'événement d'audit 547 dans le journal de sécurité avec l'une des entrées de texte suivantes :
• Pas de réponse du pair • Le délai d'attente a expiré pour la négociation. • SA IKE supprimée avant que l'établissement ait été terminé Cependant, pour les clients d'isolation de domaines, il est possible que cette condition n'apparaisse pas comme un échec si leur stratégie autorise la communication en clair. Un événement 541 de succès en mode principal IKE est créé lorsqu'une association de sécurité logicielle est établie. Vous savez qu'un événement 541 affiche une SA logicielle lorsque le SPI sortant est égal à zéro et que tous les algorithmes sont affichés sous la forme Aucun. L'exemple suivant montre comment ces paramètres apparaissent dans un événement 541 : ESP Algorithm None HMAC Algorithm None AH Algorithm None Encapsulation None InboundSpi 31311481 (0x1ddc679) OutBoundSpi 0 (0x0) Lifetime (sec) <whatever is configured for QM lifetime>
219
Lifetime (kb) 0 Remarque : les événements des SA logicielles vers la même adresse IP de destination porteront des dates différentes et des valeurs SPI entrantes différentes. Des délais de connectivité d'une minute sont observés chaque fois que deux ordinateurs ne sont plus synchronisés parce qu'un mode principal IKE actif existe peutêtre entre eux. Des délais de cinq minutes peuvent être observés si l'un des ordinateurs considère qu'il existe une paire d'associations de sécurité IPSec active entre eux et que l'autre ordinateur (un serveur, par exemple) a supprimé ces associations de sécurité et n'est pas en train d'initier une recomposition en mode rapide. Windows 2000 IKE prenait en charge des messages de suppression uniques qui étaient parfois perdus. Windows XP et Windows Server 2003 disposent d'une prise en charge fiable de la fonction de suppression sous la forme de messages de suppression multiples qui agissent comme une mesure de protection contre les paquets abandonnés. Cette situation type se produit lorsque l'utilisateur d'un portable d'isolation de domaine retire l'ordinateur de la station d'accueil pour se rendre à une réunion. La station d'accueil possède une connexion Ethernet filaire, et le fait de retirer cette interface réseau nécessite le retrait de tous les filtres qui lui sont associés (s'il s'agit de filtres développés à partir de Mon adresse IP). Toutefois, aucun filtre ayant une action de négociation n'utilise Mon adresse IP dans la solution d'isolation de domaines ; il s'agit de filtres de type N'importe lequel <> Sousréseau. Par conséquent, les états de l'association de sécurité IPSec et de l'association de sécurité IKE restent actifs sur le portable car ces filtres ne sont pas supprimés lors des changements d'adresse. Si les filtres avaient été développés depuis Mon adresse IP, ils auraient été supprimés au moment de la disparition de l'adresse IP. Chaque fois qu'un filtre de type N'importe lequel est supprimé du pilote IPSec, ce dernier informe IKE que toutes les associations de sécurité IKE et IPSec utilisant cette adresse IP doivent également être effacées. IKE tentera d'envoyer des messages de suppression pour ces SA, puis les supprimera de façon interne. Ces messages de suppression auront la même adresse IP source que celle utilisée pour les SA IKE, même s'il est possible qu'une autre adresse IP source soit présente sur l'interface connectée au moment de l'envoi du message de suppression. L'adresse IP source n'est pas importante pour l'ordinateur distant si la paire de cookies d'entête ISAKMP est reconnue et que les vérifications cryptographiques du paquet sont valides. Cependant, il arrive fréquemment que les messages de suppression ne soient pas envoyés car il n'y a pas de connectivité réseau dans les secondes suivant la déconnexion (retrait du portable). Dans le cas particulier de filtres N'importe lequel <> Sousréseau, les filtres ne sont jamais supprimés, ce qui signifie que les associations de sécurité IKE et IPSec ne sont pas immédiatement supprimées. Pendant ce temps, les SA IPSec expirent sur les ordinateurs distants auparavant connectés, et les messages de suppression en mode rapide IKE sont envoyés à l'adresse précédente du portable. Les SA en mode rapide IKE continuent à exister pendant 8 heures (par défaut) sur ces ordinateurs distants, mais peuvent être effacées à tout moment avant l'expiration de ce délai pour des raisons IKE internes. Bien entendu, les messages IKE de suppression des SA ne parviennent plus à l'ancienne adresse IP du portable. Lorsque le portable est finalement reconnecté à la station d'accueil, il reçoit de nouveau la même adresse IP. Les applications de partage de fichiers, clients de messagerie et autres se reconnectent généralement aux mêmes destinations. Cependant, il est maintenant possible qu'il existe une différence d'état IKE entre le portable et ces destinations distantes. Si le portable dispose toujours d'un mode principal IKE, il tentera de négocier en mode rapide IKE. Le mode rapide utilise un état cryptographique que le pair distant a supprimé, c'est pourquoi il ne reconnaît pas ces messages et n'y répond pas. Sur le portable, le nombre maximal de tentatives arrive à expiration au bout d'une minute ; IKE tente alors une nouvelle négociation en mode principal qui cette fois réussit. Par conséquent, l'utilisateur du portable peut remarquer un délai d'une minute lorsqu'il se reconnecte aux ressources distantes. Microsoft s'attache à améliorer ce
220
comportement dans les futures mises à jour de toutes les versions de Windows prenant en charge IPSec. La négociation IKE peut signaler l'expiration d'un délai pour diverses raisons. L'événement « Le délai d'attente a expiré pour la négociation » survient lors de l'échec des étapes de la négociation IKE (excepté l'étape de communication en clair) en raison de l'expiration du nombre limite de tentatives, sauf lorsque IKE termine la négociation par un événement « SA IKE supprimée avant que l'établissement ait été terminé ». Ces deux événements sont pratiquement identiques. Ils sont souvent courants, bénins et attendus au cours du fonctionnement normal des clients mobiles, qui modifient fréquemment et rapidement les états de la connectivité réseau lorsque les événements suivants se produisent :
• Les utilisateurs insèrent et retirent les ordinateurs portables des stations d'accueil. • Les utilisateurs débranchent une connexion filaire. • Les ordinateurs portables sont en mode de veille ou de veille prolongée. • La plage attribuée à la connexion sans fil est dépassée. • Une connexion VPN est déconnectée. • Une carte réseau PCMCIA est éjectée alors qu'elle est connectée. Pour un ordinateur distant, ces événements donnent l'impression que le pair vient de se déconnecter du réseau. L'ordinateur distant va tenter de recomposer ou de renégocier jusqu'à ce que le délai de négociation IKE expire. Les échecs dus à l'expiration de la durée de négociation ont été améliorés dans Windows Server 2003 dans le but d'identifier le moment de la négociation IKE où le délai d'expiration a lieu par l'identification de la dernière étape réussie de la négociation. Ces événements peuvent également être provoqués par la traduction des adresses réseau (Network address translation, NAT) lorsque IKE négocie sans les fonctions NATT. Cependant, le délai de négociation IKE expire aussi si le pair distant rencontre un problème qui entraîne l'échec de la négociation IKE. Ainsi, dans tous les cas d'expiration des délais de négociation et d'apparition d'événements « SA IKE supprimée avant que l'établissement ait été terminé », le support de niveau 2 doit identifier si l'ordinateur distant est responsable de l'échec en vérifiant les événements 547 d'audit des échecs sur cet ordinateur jusqu'à la minute précédant l'enregistrement de l'expiration du délai par IKE. Événements de succès de la négociation IKE Si la négociation IKE réussit, les SA en mode principal IKE s'affichent dans le composant logiciel enfichable Moniteur IPSec et via les outils d'interrogation de la ligne de commande. Pour afficher la liste des associations de sécurité actives en mode principal IKE
• Sous Windows 2000 : ipsecmon.exe, netdiag /test:ipsec /v Remarque : cette commande affiche uniquement les associations de sécurité IPSec, et non les associations de sécurité en mode principal IKE.
• Sous Windows XP : IPSec monitor snapin, ipseccmd show sas
221
• Sous Windows Server 2003 : Remarque : la ligne a été divisée en plusieurs lignes pour des raisons de lisibilité. Cependant, lorsque vous entrez cette commande dans un système, veillez à l'entrer sur une seule ligne. IPSec monitor snapin, netsh ipsec dynamic show [mmsas | qmsas] Les SA réussies en mode principal et en mode rapide génèrent les événements suivants dans le journal de sécurité si l'audit est activé.
• 541. Mode principal IKE ou mode rapide IKE établi • 542. Mode rapide IKE supprimé • 543. Mode principal IKE supprimé Messages d'information du journal en mode principal IKE Pour déterminer s'il existe un problème d'échange du mode principal, recherchez les événements consignés suivants dans les journaux des événements des ordinateurs : Tableau 7.5 : Messages d'information du journal en mode principal IKE Texte du journal
Description
La nouvelle stratégie a invalidé les SA formés avec l'ancienne stratégie
Message de Windows 2000 indiquant que la modification d'une stratégie IPSec a entraîné la suppression des associations de sécurité IKE ou IPSec actuelles. Cette erreur est sans conséquence. Les nouvelles associations de sécurité IPSec seront formées selon le flux de trafic actuel qui utilise la nouvelle stratégie IPSec.
IKE a un grand nombre de requêtes d'établissement d'association de sécurité en attente, et démarre le mode de prévention de refus de service.
Cette condition peut être normale, causée par une surcharge de l'ordinateur, et/ou un grand nombre de tentatives de connexions client. Cela pourrait également être le résultat d'une attaque de refus de service contre IKE. Si tel est le cas, il y aura plusieurs audits de négociations IKE ayant échoué vers des adresses IP factices. Dans le cas contraire, cela signifie simplement que l'ordinateur est extrêmement surchargé.Ce message indique que IKE pense avoir été submergé de requêtes d'établissement de SA en mode principal IKE. La stratégie de réponse à l'attaque de refus de service va consister pour IKE à rejeter la plupart de ces requêtes.
IKE ne subit plus le mode de prévention de refus de service et a repris un fonctionnement normal.
IKE a récupéré après ce qu'il considérait comme une condition d'attaque de refus de service, et a repris un fonctionnement normal.
La présence de ces entrées n'indique pas un échec de communication. Il s'agit de données informatives qui peuvent servir à fournir des informations supplémentaires en vue de déterminer la vraie cause d'un problème. Événements 547 relatifs à l'échec de la négociation en mode principal IKE
222
Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode principal IKE échoue :
• Pas de réponse du pair. Cet événement est attendu pour les connexions sortantes aux
ordinateurs qui n'utilisent pas IPSec et qui ne sont pas membres de la liste d'exemption. Toutefois, le support de niveau 2 doit être conscient des problèmes de connectivité qui bloquent la négociation IKE, qui génèrent également cet événement.
• Aucune stratégie configurée. Cet événement signale un problème si l'adresse IP source est
située dans les sousréseaux internes ou signale la présence d'un jeu de filtres incompatible. Il peut être prévu que les ordinateurs n'aient pas de règle pour négocier avec certaines plages d'adresses ou sousréseaux. Les ordinateurs de ces sousréseaux peuvent tenter une initiation IKE, mais n'obtiendront aucune réponse car aucune stratégie n'est configurée.
• Les attributs de sécurité IKE ne sont pas acceptables. Cet événement ne doit pas se produire
sur les systèmes correctement configurés. Réalisez les procédures de la section Vérification de la stratégie IPSec appropriée pour trouver l'origine du problème.
Les messages d'expiration de délai suivants peuvent être attendus pour les raisons mentionnées précédemment. Ils peuvent également indiquer que l'ordinateur distant a échoué la négociation IKE. En général, le support de niveau 2 se concentre sur la recherche des causes de l'échec IKE sur l'ordinateur distant, plutôt que sur l'expiration des délais de négociation (très fréquente sur les ordinateurs déconnectés) et sur l'incompatibilité de la conception de la stratégie dans laquelle le répondeur à une négociation en mode principal IKE ou en mode rapide IKE ne trouve pas de filtre spécifique correspondant à la requête entrante.
• Le délai d'attente a expiré pour la négociation. • Le délai d'attente a expiré pour la négociation. Première charge utile (SA) traitée. Répondeur durée Delta 63.
• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Initiateur durée Delta 63.
• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Répondeur Échecs d'audit en mode rapide IKE (547) Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode rapide IKE échoue :
• Aucune stratégie configurée. Troisième charge utile (ID) traitée. Initiateur • Échec de la négociation d'association de sécurité dû à la non correspondance d'attributs. • Erreur de traitement générale. • Impossible d'obtenir un nouveau SPI pour la SA entrante à partir du pilote Ipsec. • Le pilote IPSEC n'a pas réussi la négociation Oakley avec car aucun filtre n'existe. • Impossible d'ajouter une association de sécurité au pilote IPSec. • Le délai d'attente a expiré pour la négociation. Le mode rapide IKE ne doit pas échouer pour les stratégies IPSec correctement conçues et les charges de travail ordinaires. Si vous recevez l'une de ces erreurs, le support de niveau 2 doit en premier lieu suivre les étapes de la section Vérification de la stratégie IPSec appropriée. Il doit ensuite
223
tenter d'établir une corrélation entre ces événements et des conditions de performances inhabituelles, comme une utilisation à 100 % du processeur ou des conditions de mémoire du noyau très faibles. Notez que des échecs du mode rapide IKE avec expiration du délai de négociation seraient attendus si l'ordinateur n'utilisait plus sa précédente adresse IP pour l'une des raisons expliquées précédemment. Dépannage des échecs IKE provoqués par l'authentification Les messages suivants sont associés aux échecs de l'authentification IKE :
• La cible spécifiée est inconnue / Aucune autorité n'a pu être contactée pour l'authentification. • La cible spécifiée est inconnue ou inaccessible. Première charge utile (SA) traitée. Initiateur durée Delta 0.
• Les informations d'authentification IKE ne sont pas acceptables. • La tentative d'ouverture de session a échoué. • Échec de l'authentification dans l'utilisation de Kerberos. • IKE n'a pas trouvé de certificat ordinateur valide. Les deux premiers messages indiquent que l'identité Kerberos de l'ordinateur distant ne peut pas être utilisée pour obtenir un ticket de service pour l'ordinateur distant. Cette situation a pu se produire parce qu'il n'existe pas d'approbation de domaine ou parce que l'accès aux contrôleurs de domaine n'est pas disponible. Si une négociation IKE entrante échoue en raison des paramètres Accéder à cet ordinateur à partir du réseau, la négociation IKE depuis l'ordinateur chargé des droits d'accès signalera un événement 547 Échec de l'authentification dans l'utilisation de Kerberos, comme expliqué plus haut. Cet événement n'indique pas de manière spécifique que le problème est l'échec lorsque les paramètres Accéder à cet ordinateur à partir du réseau sont vérifiés ; c'est pourquoi vous devez obtenir le fichier Oakley.log du serveur pour rechercher l'erreur spécifique générée. L'appartenance de l'initiateur IKE à un groupe doit être vérifiée pour déterminer s'il fait partie d'un groupe autorisé. Si l'ordinateur fait partie d'un groupe disposant d'un accès, il est possible qu'il ne possède pas les tickets Kerberos reflétant son appartenance au nouveau groupe ou qu'il ne soit pas en mesure d'obtenir les tickets Kerberos adéquats. Complétez les procédures traitées dans la section Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine, plus haut dans ce chapitre.
Dépannage des problèmes liés aux applications Cette section explique pourquoi la conception des applications peut interagir avec l'utilisation d'IPSec sous Microsoft Windows. Le concepteur de la stratégie IPSec ainsi que le personnel du support doivent comprendre ces impacts afin de pouvoir aider à la classification et à l'identification rapide du problème. L'application de la stratégie IPSec doit être transparente pour les applications. Cependant, dans certaines circonstances où la stratégie IPSec est attribuée ou protège le trafic, l'application peut se comporter de manière inhabituelle. Les sections suivantes illustrent ces situations dans le contexte du scénario d'isolation de domaine Woodgrove Bank. ICMP autorisé, mais IPSec requis par les protocoles TCP et UDP Certaines applications utilisent un message de demande d'écho (Ping) ICMP pour déterminer si une adresse de destination est accessible. Par exemple, comme IPSec ne protège pas le trafic ICMP de cette solution, une application peut recevoir une réponse ICMP depuis une destination cible.
224
Cependant, l'application ne pourra peutêtre pas se connecter à la destination cible à l'aide du trafic TCP et UDP protégé par IPSec lorsque la négociation IKE échoue. Délai de connexion initial La négociation IKE nécessite davantage de traitement et plus de temps pour s'exécuter qu'un processus de connexion en trois étapes ou qu'un seul paquet de requête/réponse Nbtstat non authentifié. Les applications qui attendent une réponse de connexion TCP ou UDP rapide de la part de la destination cible peuvent considérer que la destination ne répond pas et entreprendre une autre action, comme signaler une erreur ou essayer de se connecter à une autre destination. Les négociations IKE à l'aide de l'authentification Kerberos réussissent généralement au bout d'une à deux secondes. Cependant, ce délai dépend de plusieurs facteurs, notamment l'utilisation du processeur sur les deux ordinateurs et la perte des paquets réseau. La communication en texte clair requiert toujours trois secondes avant d'autoriser l'envoi du premier paquet TCP non protégé. L'application se bloque en attendant la réponse du réseau Certaines applications sont conçues pour supposer que le délai de connexion ou de réception d'un message d'erreur est très bref. Ces applications attendent que la connexion soit effective (opération de liaison au socket terminée) avant d'afficher les modifications dans l'interface utilisateur. Lorsque le trafic de cette application est protégé par IPSec, l'application peut se bloquer brièvement lors de connexions réussies. Ce phénomène peut continuer jusqu'à ce que l'application soit fermée ou qu'elle rencontre d'autres erreurs inhabituelles si la connexion ne réussit pas en raison d'un échec de négociation IKE ou d'un filtre bloquant IPSec. La couche du socket réseau ne reconnaît pas les filtres IPSec et ne sait pas que IKE négocie la sécurité du trafic. L'application interprète généralement ces conditions comme une panne de l'hôte distant ou une défaillance du réseau. Cependant, les applications peuvent également interpréter les échecs de connexion aux contrôleurs de domaine par l'indisponibilité de l'ordinateur de destination ou le refus de la connexion. Traitement des paquets réseau en mode noyau affecté Les applications qui impliquent des pilotes réseau ou le traitement de paquets au niveau du noyau risquent de ne pas fonctionner correctement lorsque IPSec sécurise le trafic. Ces applications peuvent apporter des modifications au paquet, ce qui entraînera l'abandon du paquet par IPSec. Ou encore, l'application peut ne pas comprendre les modifications d'IPSec, ce qui peut se traduire par une erreur système (écran bleu). Analyse réseau de la part des hôtes d'un domaine d'isolation affectée Les outils hôtes qui tentent de sonder rapidement les adresses IP distantes ou les ports ouverts du réseau peuvent fonctionner beaucoup plus lentement si IPSec tente de sécuriser leur trafic. Le trafic destiné au sondage peut provoquer un refus de service sur l'hôte local en déclenchant l'initiation de centaines d'adresses IP par IKE en quelques secondes ou minutes. Certains outils basés sur SNMP dépendent de l'envoi d'événements d'interruption SNMP à des hôtes non approuvés qui agissent en tant que collecteurs d'événements. Même si IPSec est autorisé à utiliser les communications en clair, les paquets d'interruption SNMP sortants risquent d'être rejetés par le pilote IPSec avant que l'association de sécurité logicielle ne soit établie. De la même manière, certaines applications basées sur le protocole UDP (comme NTP et le localisateur de contrôleur de domaine Windows) attendent trois secondes seulement qu'une réponse soit reçue, ce qui entraîne l'échec de l'application ou des rapports erronés indiquant qu'une destination ne peut pas être contactée.
225
Problèmes liés au fournisseur de services superposés Winsock Certaines applications légitimes (comme les parefeu personnels) et malveillantes (comme les logiciels espions) peuvent causer des problèmes en insérant leurs propres fonctions d'inspection du trafic, appelées services superposés Winsock (LSP). Le composant IKE de l'implémentation Microsoft d'IPSec utilise une fonction API Winsock étendue dont le pointeur de fonction est déterminé par l'appel de WSAIoctl(). Si l'appel de cette fonction n'est pas autorisé à traverser les LSP installés, IKE ne peut pas contrôler les ports UDP requis. Sous Windows Server 2003, IPSec interprète cela comme une incapacité du composant à faire appliquer la stratégie de sécurité, et il réagit de façon défensive. La fonction Échec du mode sécurisé est appelée et le pilote IPSec est placé en mode de blocage. L'administrateur doit se connecter en utilisant une connexion de bureau pour pouvoir arrêter le service IPSec et restaurer la connectivité. Si le service IPSec ne répond pas à la requête d'interruption, il doit être configuré comme désactivé, et l'ordinateur doit être redémarré. Même si IKE a été correctement initialisé, la capacité de l'ordinateur à envoyer et à recevoir des protocoles IKE et IPSec peut être bloquée par le LSP ou un programme tiers. Pour le support de niveau 2, le dépannage du LSP Winsock consiste à identifier l'existence de LSP. Le support de niveau 3 doit ensuite mener d'autres investigations visant à identifier l'application qui a installé les LSP, puis à les organiser ou à les supprimer si le service IPSec ou IKE ne rencontre plus de difficulté. Outils permettant de détecter les fournisseurs de services superposés Winsock :
• Sporder.exe. Il s'agit d'une applet permettant d'afficher les LSP dans la partie Winsock 2.0 du kit de développement logiciel (Software Development Kit, SDK) de la plateforme Windows.
• Netdiag /debug. Clients tiers de réseau privé virtuel IPSec Des problèmes peuvent survenir lorsqu'une implémentation IPSec tierce est installée dans le cadre d'un client VPN d'accès à distance. En général, ces clients désactivent le service IPSec et n'entrent pas en conflit avec le service IPSec Windows natif. Toutefois, pour les membres du domaine approuvé de cette solution, le service IPSec natif est requis. C'est pourquoi les implémentations IPSec tierces peuvent créer des conflits pour les raisons suivantes :
• Les deux implémentations IKE ont besoin du port UDP 500. • Le traitement des paquets du noyau IPSec nécessite le protocole ESP pour les deux ordinateurs. • Les fonctions LSP Winsock sont installées dans le cadre du client. • La fonction de parefeu est fournie par le client VPN. • La superposition empêche les paquets IKE et IPSec natifs encapsulés d'être transmis via le tunnel IPSec tiers.
Les fournisseurs VPN permettent généralement de savoir si les VPN prennent en charge le service IPSec Windows natif activé et s'ils prennent en charge le trafic en mode transport protégé par IPSec de bout en bout via leur connexion d'accès à distance. Dans certains cas, la passerelle du fournisseur VPN prend en charge les clients VPN L2TP/IPSec et PPTP sous Windows 2000 et Windows XP. Les clients VPN Windows natifs sont compatibles avec le mode de transport IPSec de bout en bout via le tunnel VPN. Haut de page
226
Dépannage de niveau 3 Si le dépannage réalisé par le niveau 2 ne permet pas de résoudre un problème, un niveau d'expertise supplémentaire est requis pour analyser le problème et trouver une solution. Ce niveau d'expertise est appelé support de niveau 3. Dans plusieurs cas, ce support est fourni par des spécialistes IPSec contractuels ou des entreprises de support technique, comme les services de support technique Microsoft. Le support IPSec de niveau 3 requiert une connaissance approfondie du fonctionnement d'IPSec et de la pile TCP/IP de Microsoft. Les membres du personnel du support de niveau 3 ont besoin d'une formation avancée sur IPSec et son utilisation dans des scénarios d'isolation de serveurs et de domaines. Grâce aux compétences acquises, le personnel du support de niveau 3 peut devenir responsable de la formation du personnel technique des niveaux inférieurs et concevoir de la documentation d'assistance ; par exemple, des résumés techniques, des Livres blancs, des guides de maintenance, des questions fréquentes et des informations sur l'architecture IPSec et la classification. Le support de niveau 3 peut aussi être chargé d'élaborer et de documenter des plans de récupération d'urgence.
Intervention des services de support technique Microsoft Si les procédures de dépannage décrites dans ce chapitre ne vous aident pas à résoudre le problème ou si votre entreprise ne dispose pas des compétences requises pour utiliser les techniques de dépannage avancées, vous devrez peutêtre transférer le problème aux services de support technique Microsoft. Il est important de recueillir autant d'informations de diagnostic que possible, comme les fichiers journaux et les données de surveillance réseau avant de contacter les services de support technique. Utilisez cette liste pour réunir les informations nécessaires au support de niveau 3 ou aux services de support technique Microsoft pour analyser le problème :
• Conditions de sécurité requises pour l'authentification entrante et sortante et l'autorisation de chaque ordinateur. Vous devez disposer d'une brève description expliquant comment la configuration IPSec et la stratégie de groupe de l'ordinateur remplissent ces conditions.
• Diagramme représentatif du scénario, affichant le nom des ordinateurs source et cible, leur adresse IP au moment de la collecte des fichiers journaux et la version de leur système d'exploitation (y compris des informations sur le Service Pack). Pensez également à noter l'adresse IP des serveurs DNS, WINS et des contrôleurs de domaine.
• Suivi par le Moniteur réseau des communications de chaque côté pendant que la stratégie IPSec
est active, de préférence simultanément pour que les paquets puissent facilement être mis en corrélation dans les deux fichiers de suivi. Les suivis réseau doivent inclure tout le trafic entrant et sortant sur chaque ordinateur (si possible) pour que les demandes d'authentification, les recherches DNS et tout autre trafic associé puissent être identifiés. De même, si les communications échouent alors que la stratégie IPSec est active et qu'elles réussissent lorsqu'elle est désactivée ou que le service est arrêté, un suivi du trafic réseau lorsque IPSec est inactif doit également être disponible. Il est très important que l'heure du système soit synchronisée entre ces systèmes afin qu'il soit possible d'établir une corrélation entre les fichiers journaux et les fichiers de suivi.
• Sous Windows 2000, Windows XP et Windows Server 2003, exécutez
netdiag /debug >netdiagdebugcomputername.txt juste avant ou juste après la capture du suivi réseau. (Netdiag génère un trafic réseau important, qui n'a pas besoin de faire partie du suivi réseau.) Sous Windows XP et Windows Server 2003, exécutez également portqry v local >portqryvcomputername.txt.
227
• Les fichiers Oakley.log IKE de chaque côté de la communication sont collectés au moment où le
problème survient et au moment où les suivis du moniteur réseau sont enregistrés. Le nom de ces fichiers doit indiquer le nom de l'ordinateur. Si un client RAS ou VPN Windows est concerné, vous devez utiliser l'outil RASDIAG pour collecter les informations.
• Les journaux système, de sécurité et des applications complets de chaque ordinateur au moment où les fichiers Oakley.log et les fichiers de suivi réseau sont collectés.
• Tous les fichiers journaux spécifiques à la stratégie de groupe créés au moment où les fichiers Oakley.log et de suivi réseau sont capturés.
• Les détails de la stratégie IPSec de chaque ordinateur. Si les stratégies IPSec qui s'appliquent à
chaque ordinateur peuvent être facilement enregistrées, elles doivent être incluses. Cependant, la stratégie IPSec active de l'ordinateur est souvent une combinaison de plusieurs types de stratégies IPSec et pas uniquement une stratégie de domaine ou locale. Pour analyser la stratégie active d'un ordinateur, répertoriez les filtres spécifiques au mode principal IKE et les filtres spécifiques au mode rapide IKE à partir du composant logiciel enfichable MMC Moniteur IPSec.
Pour créer un fichier texte mis en forme à partir de ces filtres
1. Cliquez avec le bouton droit de la souris sur le nœud Filtres spécifiques du mode rapide IKE dans le volet gauche de l'arborescence.
2. Sélectionnez Exporter la liste. 3. Enregistrez le fichier texte délimité par des tabulations sous IKEqm<nomordinateur
spécifique>.txt ou sous une convention de dénomination similaire comprenant le nom de l'ordinateur.
Un fichier texte délimité par des tabulations comprenant tous les détails du filtrage peut être importé dans une feuille de calcul ou un document de traitement de texte. Haut de page
Résumé Ce chapitre vous a fourni des informations détaillées sur les processus qui aident le support de niveau 1 (support technique) et le support de niveau 2 (spécialistes informatiques du support réseau) à résoudre les problèmes de communication IPSec courants. Il est impossible de fournir des informations sur toutes les erreurs potentielles, car le fonctionnement d'IPSec et la sécurité réseau sont trop complexes pour permettre de répertorier toutes les variantes. Lorsque cela est possible, les développeurs de ce chapitre ont souligné les options possibles pour mettre l'accent sur les zones susceptibles de rencontrer des problèmes dans le type d'environnement d'isolation de serveurs et de domaines détaillé dans ce guide. Les exemples de scripts fournis dans ce guide ont été testés au cours de l'implémentation test du scénario Woodgrove Bank afin de prouver leur efficacité. Toutefois, ces scripts sont conçus pour être personnalisés en fonction des besoins d'une entreprise et ne sont donc pas pris en charge par Microsoft. Aux yeux du lecteur, le dépannage d'IPSec doit sembler techniquement complexe et requiert des compétences dans divers domaines technologiques autres qu'IPSec, comme les réseaux, Active Directory et les stratégies de groupe. Cependant, les informations fournies dans ce chapitre doivent permettre au lecteur de résoudre une grande partie des problèmes rencontrés, sauf les plus compliqués qui peuvent affecter la solution d'isolation de serveurs et de domaines.
228
Pour les lecteurs qui souhaitent développer leurs connaissances et entrer dans la catégorie du support de niveau 3, la section suivante répertorie d'autres sources de documentation qui pourront les occuper pendant quelques années !
Informations complémentaires • Pour obtenir des informations de base sur IPSec, reportezvous à la référence technique How IPSec Works de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/all/techref/enus/w2k3tr_IPSec_how.asp
• Pour obtenir des informations détaillées sur la résolution des problèmes liés à TCP/IP, reportez vous aux références techniques suivantes :
• TCP/IP in Windows 2000 Professional
(TCP/IP sous Windows 2000 Édition Professionnel) à l'adresse www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en us/prork/prcc_tcp_slnb.asp
• Chapitre TCP/IP Troubleshooting
(Dépannage du protocole TCP/IP) du kit de ressources Windows XP à l'adresse www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en us/prcc_tcp_gfhp.asp
• How to troubleshoot TCP/IP connectivity with Windows XP (Dépannage de la connectivité TCP/IP sous Windows XP)
à l'adresse http://support.microsoft.com/?kbid=314067
• Windows Server 2003 TCP/IP Troubleshooting
à l'adresse www.microsoft.com/technet/prodtechnol/windowsserver2003/operations/system/tcpiptrb.mspx
Pour consulter l'aide en ligne et la documentation du kit de ressources concernant le dépannage d'IPSec sous Windows 2000, Windows XP et Windows Server 2003, reportezvous aux références suivantes :
• Basic IPSec troubleshooting in Microsoft Windows 2000 Server
à l'adresse
http://support.microsoft.com/?kbid=257225
• Microsoft Windows 2000 Advanced Documentation
(Documentation avancée de Microsoft Windows 2000) à l'adresse www.microsoft.com/windows2000/en/advanced/help/sag_ipsectrouble.htm?id=3352
• Basic L2TP/IPSec Troubleshooting in Windows XP
(Résolution élémentaire des problèmes liés à IPSec sous Windows XP) à l'adresse http://support.microsoft.com/?kbid=314831
• Aide de Windows Server 2003 – Troubleshooting tools
(Outils de dépannage) IPSec à l'adresse www.microsoft.com/technet//prodtechnol/windowsserver2003/proddocs/standard/ sag_ipsec_tools.asp?frame=true#iketrace_enable
• Diagramme de présentation de l'architecture dans le Livre blanc Windows 2000 TCP/IP
Implementation Details (Informations de l'implémentation TCP/IP) sous Windows 2000 à l'adresse www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/ tcpip_implement.asp
• Windows 2000 Network Architecture
(Architecture réseau sous Windows 2000), figure B.1 à l'adresse www.microsoft.com/resources/documentation/windows/2000/server/reskit/en us/cnet/cnad_arc_jypf.asp
229
• How TCP/IP Works
(Fonctionnement de TCP/IP) à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_tcpip_how.asp
• How IPSec Works
(Fonctionnement d'IPSec) à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_ipsec_how.asp
230
Avantages métier Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, les suivants : •Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les ordinateurs gérés du réseau.
•Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise en œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à l'ensemble des ressources du réseau. •Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution d'isolation physique. •Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au système d'informations d'une entreprise, tous les périphériques doivent devenir des systèmes gérés pour autoriser l'accès à leurs utilisateurs. •Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants. La solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à des ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un ordinateur non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est procuré un nom d'utilisateur et un mot de passe valides. •Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de demander le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés. •Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant d'isoler rapidement et de façon efficace des ressources spécifiques du réseau. •Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources gérées.
Présentation de ce guide L'objectif de ce guide est de vous aider à mettre en place une solution d'isolation de serveurs et de domaines tout au long du cycle de vie informatique, de la phase initiale d'évaluation et d'approbation, au déploiement, au test et à la gestion de l'implémentation. Pour cette raison, les chapitres de ce guide ont été rédigés de façon à répondre aux besoins des différents lecteurs. Cette section présente brièvement le contenu des différents chapitres du guide Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe.
Chapitre 1 : Introduction à l'isolation de serveurs et de domaines Le premier chapitre (celuici) est constitué d'une synthèse et d'une brève introduction présentant le contenu des chapitres de ce guide. Il présente le concept d'isolation logique ainsi que différentes approches de l'isolation de serveurs et de domaines pour une entreprise, met en évidence l'intérêt commercial et illustre l'intégration de ces approches dans une infrastructure informatique type. Ce chapitre donne également des informations sur le scénario de la Woodgrove National Bank, adopté à des fins de démonstration, de conception et de test.
Chapitre 2 : Présentation de l'isolation de serveurs et de domaines Le chapitre 2 définit le concept des hôtes approuvés et explique comment utiliser l'approbation pour créer des solutions d'isolation de domaines ou de serveurs. Il décrit les relations entre le concept d'isolation de serveurs et de domaines, IPSec et les stratégies de groupe. Ce guide comprend des explications techniques détaillées de l'objectif attendu de la solution, en ce qui concerne les menaces
2
de sécurité qu'elle prévient. Il explique également les problèmes techniques éventuels liés à l'utilisation d'IPSec pour créer une solution d'isolation de domaines et de serveurs.
Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique Avant d'entreprendre un projet, les concepteurs de la solution doivent impérativement avoir connaissance d'informations précises, à jour, sur l'infrastructure informatique actuelle. Ils doivent notamment connaître l'état actuel de tous les systèmes réseau, des configurations des serveurs et des stations de travail, et des approbations de domaine. Ce chapitre aborde également les répercutions éventuelles sur d'autres technologies de réseau, telles que NAT, les clients VPN distants basés sur IPSec, les proxies et les parefeu internes, et le filtrage de ports internes. Il donne aussi des explications sur les informations requises dans le cadre de la planification et présente les étapes permettant d'obtenir ces informations.
Chapitre 4 : Conception et planification de groupes d'isolation Ce chapitre explique comment intégrer les besoins de l'entreprise dans la conception de l'isolation de serveurs et de domaines. Il présente une approche détaillée vous permettant de créer un groupe d'isolation qui répond aux besoins de sécurité de votre entreprise en matière d'isolation. Ce chapitre décrit également plusieurs approches de déploiement qui peuvent vous servir à limiter les conséquences sur l'entreprise lors du déploiement et à optimiser les chances de réussite de l'implémentation. Toutes les étapes et les procédures de ce chapitre sont illustrées par des exemples basés sur le scénario de la Woodgrove Bank.
Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation La stratégie IPSec est le mécanisme que vous utilisez pour appliquer les règles qui autorisent les ordinateurs à communiquer entre eux. Ces règles sont affectées et distribuées aux membres du domaine approuvé par le biais d'objets de stratégie de groupe (GPO). Ce chapitre contient les informations indispensables à la création des stratégies IPSec, et il explique comment déployer ces dernières sur les ordinateurs des destinataires.
Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines Une fois la solution implémentée et opérationnelle, vous devez comprendre et noter un certain nombre de processus qui vous aideront à assurer au quotidien une prise en charge et une gestion correcte de la solution. Ce chapitre inclut un modèle de prise en charge et présente plusieurs processus et procédures de gestion à utiliser dans le cadre d'une structure de fonctionnement plus vaste, telle que Microsoft Operations Framework (MOF). Pour plus d'informations sur MOF, reportezvous au site Web Microsoft Operations Framework , à l'adresse www.microsoft.com/mof.
Chapitre 7 : Dépannage d'IPSec Des problèmes surviendront forcément durant le déploiement et l'utilisation de la solution. Ce chapitre présente des procédures de dépannage d'IPSec, des tâches, des outils et des conseils qui vous permettront de savoir si IPSec est à l'origine des problèmes rencontrés, puis de les résoudre, le cas échéant. Outre les principaux chapitres, ce guide comprend des supports de référence, des aides pour les travaux ainsi que des scripts utilisés, au cours de l'élaboration de ce guide, dans la planification, le
3
test et le déploiement de l'environnement du laboratoire de test chez Microsoft. Les informations figurant dans ces annexes peuvent vous aider à implémenter vos propres solutions d'isolation de serveurs et de domaines. Elles sont destinées à vous aider durant toutes les phases du projet, depuis l'idée initiale de la solution jusqu'au fonctionnement au quotidien d'une solution entièrement déployée.
4
Table des matières Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe ........................ 1 Présentation ........................................................................................................................................... 1 Avantages métier .................................................................................................................................... 1 Présentation de ce guide ........................................................................................................................ 2 Table des matières ................................................................................................................................. 5 Chapitre 1 : Introduction à l'isolation de serveurs et de domaines ................................................. 8 Synthèse ................................................................................................................................................. 8 Défi métier .............................................................................................................................................. 9 Création d'une équipe de projet ............................................................................................................ 12 Présentation du scénario ...................................................................................................................... 13 Résumé ................................................................................................................................................ 18 Chapitre 2 : Présentation de l'isolation de serveurs et de domaines ............................................. 19 Connaissances préalables requises pour ce chapitre ........................................................................... 19 À qui s'adresse ce chapitre ................................................................................................................... 20 Exigences au niveau de l'entreprise ..................................................................................................... 20 Identifications des ordinateurs approuvés ............................................................................................ 24 Comment l'isolation de serveurs et de domaines s'intègretelle dans ma stratégie de sécurité réseau globale ? ............................................................................................................................................... 29 Rappel terminologique .......................................................................................................................... 32 Comment l'isolation de serveurs et de domaines peutelle être mise en place ? .................................. 36 De quoi nous protège l'isolation de serveurs et domaines ? ................................................................. 45 Comment déployer l'isolation de serveurs et de domaines ? ................................................................ 46 Résumé ................................................................................................................................................ 47 Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique ......................... 48 Connaissances préalables requises pour ce chapitre ........................................................................... 48 À qui s'adresse ce chapitre ................................................................................................................... 50 Analyse de l'état actuel ......................................................................................................................... 50 Considérations relatives à la capacité ................................................................................................. 61 Problèmes de prédéploiement .............................................................................................................. 62 Définition de l'approbation .................................................................................................................... 65 Identification des coûts de mise à niveau des hôtes actuels ................................................................ 69 Résumé ................................................................................................................................................ 71 Chapitre 4 : Conception et planification de groupes d'isolation .................................................... 73 Connaissances préalables requises pour ce chapitre ........................................................................... 73 Création de la conception d'isolation de serveurs et de domaines ....................................................... 74 Méthodes d'implémentation de groupe ................................................................................................. 92 Implémentation des groupes pour Woodgrove Bank ............................................................................ 96 Résumé ................................................................................................................................................ 96 Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation ....................................... 99 Connaissances préalables requises pour ce chapitre ........................................................................... 99 Création de stratégies IPSec dans Active Directory ........................................................................... 101 Autorisation de l'accès en entrée à un groupe d'isolation ................................................................... 136 Autres considérations relatives à IPSec ............................................................................................. 137 Résumé .............................................................................................................................................. 141 Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines .................... 143 Connaissances préalables requises pour ce chapitre ......................................................................... 143 Gestion des modifications ................................................................................................................... 144 Considérations relatives à la sauvegarde et la récupération .............................................................. 160
5
Réduction des risques d'infection sur le réseau .................................................................................. 162 Résumé .............................................................................................................................................. 164 Chapitre 7 : Dépannage d'IPSec ...................................................................................................... 166 Niveaux de support et transfert des incidents ..................................................................................... 166 Dépannage de niveau 1 ...................................................................................................................... 167 Préparation du dépannage de niveau 2 .............................................................................................. 175 Processus de dépannage d'IPSec ...................................................................................................... 184 Dépannage de niveau 3 ..................................................................................................................... 227 Résumé .............................................................................................................................................. 228
6
7
Chapitre 1 : Introduction à l'isolation de serveurs et de domaines Pendant bon nombre d'années il était courant d'isoler physiquement les ordinateurs et les réseaux, pour éviter de compromettre les données et les communications. L'isolation physique pose cependant un problème : elle ne permet pas de protéger facilement derrière des limites physiques l'infrastructure informatique d'un grand nombre d'entreprises. La forte croissance des clients mobiles et la nature des environnements réseau distribués rendent ces limites physiques trop rigides à implémenter et à utiliser. Avec l'isolation de serveurs et de domaines, il est possible de créer une couche de sécurité pour isoler logiquement le trafic réseau entre des ordinateurs ou des réseaux. Si une personne malveillante parvient à accéder physiquement au réseau interne d'une entreprise et si elle tente d'accéder à un serveur contenant des ressources stratégiques, l'isolation de serveurs et de domaines est en mesure de bloquer cet accès, tout simplement parce que l'ordinateur utilisé dans le cadre de cette attaque ne fait pas partie des systèmes approuvés de l'entreprise, même si la personne malveillante a utilisé un compte d'utilisateur et un mot de passe valides. L'isolation logique via des techniques d'isolation de serveurs et de domaines permet d'élaborer une solution d'isolation souple, évolutive et gérable, qui garantit la sécurité de l'isolation tout en évitant le coût et la rigidité des limites physiques.
Synthèse Microsoft a parfaitement conscience que la sécurisation des réseaux constitue pour les grandes entreprises un défi de plus en plus complexe. Au fur et à mesure que les entreprises se développent et que les relations commerciales évoluent, le contrôle de l'accès physique au réseau relève presque d'une mission impossible. Tous les jours, pour des raisons commerciales valables, vos clients, fournisseurs et consultants connectent leurs équipements mobiles à votre réseau. L'apparition des technologies de réseau et de connexion sans fil, telles que GPRS et Bluetooth, a simplifié plus que jamais l'accès réseau. Cette connectivité améliorée signifie que les membres d'un réseau interne sont de plus en plus exposés aux risques non négligeables que constituent les autres ordinateurs de ce réseau interne, sans compter les brèches éventuelles dans le périmètre de sécurité. Les parefeu personnels ou basés sur l'hôte participent à la protection des clients lors d'une connexion à Internet, mais ils ne permettent pas encore de protéger les clients et les serveurs internes. L'isolation de serveurs et de domaines est intéressante pour l'entreprise. Elle offre avant tout une couche de sécurité réseau qui réduit considérablement le risque qu'un hôte non approuvé accède aux membres du domaine approuvés du réseau interne d'une entreprise. L'isolation de serveurs et de domaines peut jouer un rôle stratégique important dans le cadre de la lutte contre la propagation des virus, de la protection contre les pirates internes, contre les utilisations erronées de la part des employés et contre le vol d'informations. En outre, elle peut être utilisée pour demander l'appartenance au domaine de tous les clients cherchant à accéder à des ressources approuvées, qu'il s'agisse de clients ou de serveurs, de sorte qu'elles puissent être mieux gérées par le personnel informatique. L'isolation de serveurs et de domaines peut également servir de stratégie principale ou complémentaire pour répondre aux besoins en matière de protection ou de confidentialité des données sur le réseau, sans avoir à modifier les applications Microsoft® Windows® existantes ou à déployer un tunnel VPN sur le réseau.
8
L'isolation de serveurs et de domaines permet aux administrateurs du système informatique de restreindre les communications TCP/IP des membres du domaine identifiés comme ordinateurs approuvés. Les ordinateurs approuvés peuvent être configurés pour autoriser uniquement les connexions entrantes à partir des autres ordinateurs approuvés ou d'un groupe spécifique d'ordinateurs approuvés. Pour contrôler les droits de connexion réseau, les contrôles d'accès sont gérés de façon centralisée par les stratégies de groupe Active Directory®. La plupart des connexions TCP/IP peuvent être sécurisées sans avoir à modifier les applications. En effet, IPSec (Internet Protocol security) fonctionne au niveau de la couche réseau située sous la couche des applications, pour assurer une authentification et une sécurité de pointe par paquet, de bout en bout entre les ordinateurs. Le trafic réseau peut être authentifié, ou authentifié et chiffré, dans divers scénarios personnalisables. Les configurations d'IPSec et des stratégies de groupe sont gérées de façon centralisée dans Active Directory. Le concept d'isolation logique présenté dans ce guide englobe deux solutions : l'isolation de domaines pour isoler les membres du domaine des connexions non approuvées, et l'isolation de serveurs pour qu'un serveur accepte uniquement les connexions réseau des membres du domaine approuvés ou d'un groupe de membres du domaine spécifique. Ces solutions peuvent être utilisées séparément ou ensemble, dans le cadre d'une solution d'isolation logique globale. La solution testée présentée dans ce guide requiert la configuration minimale suivante pour les différentes platesformes :
• Windows 2000 avec le Service Pack 4 ou ultérieur • Microsoft Windows Server™ 2003 • Windows XP avec Service Pack 2 ou ultérieur Ces configurations garantissent le niveau de révision requis pour les composants d'IPSec. Les communications avec les platesformes nonWindows ou avec des systèmes non approuvés sont contrôlées via la configuration d'IPSec, répertoriant les exemptions et/ou étant autorisée à revenir à des communications en texte clair (nonIPSec). Avec les nouvelles fonctions transversales de traduction d'adresses réseau (NAT), les traducteurs d'adresses réseau n'empêchent plus l'utilisation d'IPSec sur le réseau local. Ce guide utilise le scénario de la Woodgrove National Bank pour illustrer l'implémentation de l'isolation de serveurs et de domaines dans un environnement de laboratoire représentatif. Il présente également l'expérience acquise par Microsoft lors de l'implémentation de ces deux solutions en interne, ainsi que dans des environnements clients. Ce guide a été conçu par une équipe d'experts de Microsoft. Il a ensuite été contrôlé par le personnel informatique de Microsoft et par des clients via un programme bêta. Comme les scénarios d'isolation de serveurs et de domaines ont tous deux été implémentés dans le réseau interne mondial de Microsoft, l'entreprise dépend véritablement de la sécurité de ces solutions. Par ailleurs, en recommandant ces solutions à ses clients, Microsoft soutient les entreprises qui ciblent à long terme une infrastructure véritablement sécurisée et gérable, pour un environnement informatique plus sûr.
Défi métier Aujourd'hui, la nature même des entreprises connectées et des équipements réseau mobiles est susceptible de mettre en péril l'infrastructure informatique de votre entreprise. Ces risques peuvent avoir diverses origines. Ils peuvent notamment provenir de l'ordinateur d'un client, d'un vendeur ou d'un employé mobile, outre les ordinateurs distants des petites succursales et les ordinateurs domestiques des employés. Dans bon nombre de cas, ces risques consistent principalement en
9
l'attaque d'un logiciel malveillant (également appelé malware), tel qu'un virus ou un vers, téléchargé ou installé par inadvertance sur l'ordinateur d'un utilisateur crédule. L'isolation logique ne peut pas être considérée comme une protection antivirus. Elle peut toutefois s'intégrer dans une solution antivirus plus vaste, car elle met en place une couche de sécurité complémentaire qui réduit les risques d'attaque et leurs effets. Par exemple, un client de passage dans votre entreprise qui connecte son ordinateur portable à votre réseau pour vous présenter une feuille de calcul introduit un risque dans l'infrastructure informatique de votre entreprise. En se connectant directement à votre réseau physique, ce client a contourné le périmètre de sécurité mis en place pour lutter contre les attaques réseau. Si le réseau auquel se connecte ce client n'autorise pas l'accès direct aux serveurs de votre entreprise, le risque est limité. La question qui se pose est la suivante : comment autoriser l'accès à ces ressources de l'entreprise uniquement aux ordinateurs qui en ont besoin ? Avec l'isolation de serveurs et de domaines ! Cette technique permet d'identifier et d'authentifier un ordinateur afin de déterminer les ressources auxquelles il est autorisé à accéder. L'authentification a lieu avant que l'utilisateur se connecte, et elle reste active une fois l'ordinateur connecté. Avec cette approche, il est possible de réduire le risque que constituent pour vos données stratégiques les ordinateurs non identifiés et non gérés qui se connectent à votre réseau. Remarque : pour plus d'informations sur les logiciels malveillants et pour connaître les moyens spécifiques à mettre en place afin de vous protéger, consultez la page The Antivirus DefenseinDepth Guide (Guide de défense antivirus renforcée), sur le site Web de TechNet, à l'adresse http://go.microsoft.com/fwlink/?LinkId=28732.
Avantages métier Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, les suivants :
• Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les ordinateurs gérés du réseau.
• Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise en œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à l'ensemble des ressources du réseau.
• Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution d'isolation physique.
• Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au
système d'informations d'une entreprise, tous les systèmes doivent devenir des systèmes gérés pour autoriser l'accès à leurs utilisateurs.
• Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants.
La solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à des ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un ordinateur non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est procuré un nom d'utilisateur et un mot de passe valides.
• Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de demander le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés.
• Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant d'isoler rapidement et de façon efficace des ressources spécifiques du réseau.
10
• Protection des connexions réseau en accès libre. Certains points de connexion réseau, tels que les points de connexion dans un « hall », n'offrent pas un accès direct à l'ensemble des ressources de votre réseau.
• Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources gérées.
Défi technologique Il n'est facile de protéger une infrastructure informatique moderne contre les attaques tout en permettant aux employés de travailler de la façon la plus souple possible et d'être aussi productifs que possible. Le fait de comprendre l'ensemble des technologies qui contribuent à sécuriser un environnement est déjà suffisamment complexe pour bon nombre de personnes. Il convient de repérer précisément où se situe la solution d'isolation dans une infrastructure informatique type et de comprendre de quelle manière elle complète les solutions de protection réseau existantes. La figure suivante présente une infrastructure réseau type constituée d'un certain nombre de couches de protection réseau. Elle indique à quel endroit intervient l'isolation logique dans un environnement type :
Figure 1.1 Zones de l'infrastructure et couches de protection réseau
La figure 1.1 illustre simplement les diverses technologies que vous pouvez mettre en œuvre pour sécuriser en profondeur une infrastructure réseau type. Ce type d'infrastructure comprend généralement les éléments suivants :
• Travailleurs et réseaux distants. Ces entités distantes utilisent généralement des réseaux privés virtuels (VPN) pour se connecter au réseau interne de l'entreprise et accéder à son infrastructure informatique.
• Internet. Le réseau interne de l'entreprise est souvent connecté à Internet via un ou plusieurs
parefeu de périmètre. Ces périphériques résident en général dans un réseau de périmètre qui fournit un niveau de protection élevé contre les menaces externes liées aux connexions Internet.
11
• Réseau de périmètre. Ce réseau est sciemment placé à l'écart pour les serveurs et les systèmes qui ont besoin d'un accès direct à Internet ou auxquels il doit être possible d'accéder à partir d'Internet. Ils sont, par conséquent, plus exposés aux attaques.
• Réseau interne. En général, ce réseau regroupe les réseaux de l'entreprise situés physiquement
sur les sites qui lui appartiennent et gérés comme partie intégrante de l'infrastructure informatique.
• Réseau de quarantaine. Ce réseau est un nouveau composant qui offre une connexion limitée
aux ordinateurs qui ne répondent pas aux conditions minimales requises par l'entreprise en matière de normes de sécurité. Une fois que les tests exigés ont été menés à bien, l'ordinateur et l'utilisateur sont autorisés à accéder à l'ensemble du réseau interne. En cas d'échec des tests, le réseau de quarantaine leur accorde une connexion suffisante pour télécharger et installer les éléments requis qui leur permettront de mener à bien les tests. Grâce à la protection de l'accès au réseau (NAP, Network Access Protection), Microsoft offre de nouvelles possibilités aux ordinateurs distants mis en quarantaine. Pour plus d'informations, reportezvous à la page Network Access Protection du site de Microsoft, à l'adresse www.microsoft.com/nap.
• Réseaux partenaires. Compte tenu que ces réseaux n'appartiennent pas à l'entreprise ou que celleci ne les gère pas, un contrôle d'accès strict est généralement appliqué pour autoriser l'exécution de processus ou d'applications spécifiques de l'entreprise via un tunnel VPN ou un routeur de périmètre diffusant des communications extranet.
La figure 1.1 illustre le fait que l'isolation logique est axée directement sur les communications des hôtes du réseau interne. Les VPN sont gérés par les services d'accès à distance (RAS) pour autoriser la connexion sécurisée du trafic des travailleurs et réseaux distants. Les parefeu réseau latéraux protègent les communications entre Internet et les réseaux internes. Les services RAS et la protection NAP permettent de gérer les connexions des travailleurs distants par le biais d'un réseau de quarantaine. À l'heure actuelle, ces couches de protection réseau sont en général installées et gérées en tant que composants distincts d'un réseau de protection renforcée. Toutefois, dans les années à venir, ces composants seront probablement intégrés dans une solution de protection réseau commune susceptible d'être implémentée comme solution unique, de bout en bout. Aujourd'hui, ce qui manque souvent dans bon nombre de réseaux, c'est la possibilité de protéger les ordinateurs du réseau interne les uns des autres. Parfois, les réseaux internes étendus prennent en charge plusieurs organisations, et dans certains cas, plusieurs services informatiques doivent gérer les ordinateurs et les points d'accès physiques. Par conséquent, il ne faut pas considérer le réseau interne simplement comme un réseau dans lequel tous les ordinateurs physiquement connectés sont approuvés et bénéficient d'une connexion réseau complète entre eux. L'isolation logique vise à segmenter et à isoler le réseau interne afin de fournir un niveau de sécurité supérieur sans avoir recours aux limites physiques. Le véritable défi technologique de l'isolation logique consiste à mettre en œuvre la solution de sorte qu'elle soit à la fois gérable et évolutive. Si votre conception est trop complexe et restrictive, elle risque d'empêcher les utilisateurs d'effectuer leurs tâches, ce qui peut être pire que l'absence d'une solution d'isolation. Vous devez réaliser une planification et des tests avant et pendant le déploiement de la solution. Grâce à ce guide, vous avez la possibilité de mettre en place une solution évolutive et gérable, susceptible d'être déployée de façon contrôlée, et qui permet d'effectuer des tests à différents stades de la phase de déploiement. Lorsque l'isolation logique est en place, la couche de sécurité complémentaire contribue à réduire les risques qu'encourent vos ressources d'informations sur le réseau, et ce, sans restreindre les possibilités d'action des clients autorisés.
Création d'une équipe de projet 12
Cette solution peut avoir une incidence sur l'ensemble des communications du réseau interne de l'entreprise, ce qui risque par conséquent d'affecter tous les services et toutes les personnes qui utilisent ces communications. Par conséquent, il est primordial que les attentes et les besoins de l'organisation soient communiqués, répertoriés, compris et pris en compte à chaque étape de ce projet. Dans la mesure où une seule personne ne peut pas réaliser toutes les tâches requises dans un projet d'une telle ampleur dans une entreprise type, il est vivement recommandé de mettre en place une équipe de projet. Cette équipe de projet doit être constituée de représentants de tous les services de l'entreprise, et elle doit intégrer les principaux secteurs de technologie de l'infrastructure informatique actuelle. Étant donné que ce guide n'a pas pour but d'expliquer le fonctionnement d'une équipe de projet, nous partons du principe qu'une équipe de projet convenable est mise en place et que les parties prenantes et les utilisateurs sont informés des exigences et des objectifs de la solution tout au long du projet. Pour plus d'informations sur l'organisation d'un projet comme celuici, reportezvous au site Web Microsoft Solutions Framework (MSF) , à l'adresse www.microsoft.com/msf.
Présentation du scénario Les solutions d'isolation de serveurs et de domaines ont toutes deux été déployées en interne sur le réseau interne de Microsoft. Toutefois, nous avons également testé une implémentation de laboratoire physique représentative, basée sur le scénario client de la Woodgrove Bank, pour proposer un modèle public et concret pour cette solution. Pour élaborer ce guide, les besoins de l'entreprise et les exigences techniques de cette organisation fictive ont été ajoutés à ceux de Microsoft. Ce guide contient des techniques de gestion et de prise en charge utilisées régulièrement par les administrateurs du système informatique interne de Microsoft. Des notes particulières ont été ajoutées lorsque les exigences et le personnel de la Woodgrove Bank différaient de ceux de la conception propre à Microsoft.
Qu'estce que la Woodgrove Bank ? La Woodgrove National Bank est une organisation fictive de démonstration utilisée par Microsoft comme exemple de client tangible pour vous aider à déployer la solution. Microsoft a tiré parti de sa longue expérience avec ses clients professionnels pour dresser la liste des exigences de la Woodgrove Bank. Comme la Woodgrove Bank est une banque, elle s'appuie sur une solution de sécurité pour assurer la sécurité de ses ressources monétaires et des données privées de ses clients. La Woodgrove Bank doit également respecter les obligations réglementaires émises par le gouvernement et les groupes industriels. Dans cet exemple, les obligations réglementaires et législatives ne sont pas abordées pour éviter que la solution présentée ne soit spécifique à un pays ou une région. La Woodgrove Bank est une importante banque d'investissement mondiale au service d'instituts, d'entreprises, du gouvernement et de particuliers dans son rôle d'intermédiaire financier. Ses activités incluent les hypothèques, les ventes et le commerce, les services de conseil financier, la recherche de placements, le capital de risque et les services de courtage pour les institutions financières. La Woodgrove Bank est une filiale appartenant intégralement à la société WG, entreprise de services financiers mondiale majeure, dont le siège social est basé à Londres (Angleterre). La société WG possède les cinq entreprises suivantes : Woodgrove National Bank, Northwind Trading, Contoso, Ltd., Litware Financials et Humongous Insurance. Toutes les entreprises de la société WG sont de vastes organisations, comptant chacune plus de 5 000 personnes.
13
Situation géographique La Woodgrove Bank emploie plus de 15 000 personnes, dans plus de 60 bureaux répartis dans le monde entier. Elle possède des sièges sociaux (sites satellites) qui comptent un grand nombre d'employés, à New York (5 000 personnes), à Londres (5 200 personnes) et à Tokyo (500 personnes). Chaque site satellite prend en charge des sites secondaires de petite taille (par exemple, le siège de New York prend en charge les sites de Boston et d'Atlanta). Outre ses sites satellites, la Woodgrove Bank possède également deux autres sites principaux, respectivement basés à Sydney et à Johannesburg, chacun possédant ses propres serveurs de fichiers dédiés, d'impression et d'applications. Connectivité entre les sites Tokyo et Londres sont connectées aux sièges de l'entreprise à New York via des connexions Internet privées. Les bandes passantes allouées sont respectivement de 6 mégabits par seconde (Mbits/s) et de 10 Mbits/s. Tous les sites satellites sont connectés aux sièges et bénéficient d'une connexion de 2 à 10 mégaoctets (Mo). Les filiales autonomes bénéficient d'une connexion de 2 Mo. Les microfililales ont généralement une connexion de réseau étendu (WAN) de 1 Mo. La figure 3.1 du chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », de ce guide détaille ces connexions.
Défis informatiques de l'entreprise La Woodgrove Bank est confrontée aux mêmes défis que la plupart des entreprises. Elle souhaite en effet augmenter son chiffre d'affaires et réduire les coûts tout en diminuant le coût des immobilisations. Ces défis ont toujours des répercutions sur les services informatiques. La Woodgrove Bank est confrontée à un certain nombre d'initiatives d'entreprise qui affectent également les services informatiques. Parmi ces initiatives figurent les suivantes :
• Conquérir de nouveaux marchés via des fusions et des acquisitions • Gagner la satisfaction des clients • Améliorer la productivité des employés • Améliorer les processus et le fonctionnement • Fournir un environnement sécurisé Ces initiatives affectent les services informatiques, mais les responsables informatiques sont également confrontés à d'autres défis spécifiques, tels que les suivants :
• Réduire le coût global des services informatiques. • Réduire les frais d'exploitation ; améliorer la gestion et réduire ses coûts ; réduire le nombre de serveurs dans l'environnement ; regrouper des applications et services hétérogènes sur des serveurs uniques. • Tirer parti des investissements informatiques existants. • Créer une infrastructure informatique souple.
• Améliorer le retour sur investissement. • Accroître l'utilisation. • Améliorer la disponibilité et la fiabilité. • Exploiter de nouvelles platesformes matérielles.
• S'assurer que les employés, partenaires et clients utilisent l'environnement le plus sûr.
14
• Autoriser les accords sur le niveau de service (en interne et en externe). • Améliorer la souplesse de l'entreprise en fournissant un véritable accès en temps réel aux informations, quel que soit l'endroit.
Profil informatique de l'organisation La Woodgrove Bank est dotée d'un environnement serveur mixte sous Windows et UNIX, mais son infrastructure est exécutée sur une dorsale Windows Server. Elle compte au total 1 712 serveurs Windows. La plupart d'entre eux exécutent Windows 2000 ou une version ultérieure :
• Serveurs de fichiers et d'impression • Serveurs Web • Serveurs d'infrastructure • Serveurs Microsoft Exchange • Serveurs Microsoft SQL Server™ • Serveurs de développement • Serveurs d'analyse • Autres (Lotus Notes, Oracle)
785 123 476 98 73 73 33 51
La plupart des serveurs sont répartis dans les trois sièges sociaux de l'entreprise (New York, Londres et Tokyo). Environnement PC La plupart des employés de la Woodgrove Bank possèdent au moins un ordinateur personnel. Les employés sont généralement équipés d'ordinateurs de bureau. Quant aux commerciaux, ils sont équipés d'ordinateurs portables. Au total, la Woodgrove Bank possède plus de 17 000 ordinateurs personnels. Environ 85 % de ces ordinateurs sont des ordinateurs de bureau et 15 % sont des ordinateurs portables. Plus de 95 % des ordinateurs personnels sont dotés de la technologie Intel et exécutent une version de Windows. Pour les applications LOB (Line of Business), des services spécifiques utilisent des postes de travail Macintosh et quelques postes de travail UNIX.
Présentation de l'architecture du système et de l'architecture de gestion Le réseau de la Woodgrove Bank est constitué de plusieurs zones informatiques : un centre de données d'entreprise, deux sites satellites, deux succursales et un réseau de périmètre permettant d'assurer la prise en charge des utilisateurs distants. Pour centraliser la gestion des serveurs et des ordinateurs de bureau à New York, la Woodgrove Bank applique un modèle de gestion centralisée (voir figure cidessous).
15
Figure 1.2 Modèle de gestion informatique centralisée de la Woodgrove Bank
Service d'annuaire Pour sa structure Active Directory, la Woodgrove Bank a opté pour un modèle de forêt du fournisseur de service. Ce modèle offre en effet la possibilité de mettre en place une forêt pour le périmètre et une forêt partagée distincte pour les ressources internes. Cette souplesse permet de répondre aux exigences d'isolation des serveurs dans le réseau de périmètre. La Woodgrove Bank n'a pas choisi le modèle de forêt unique car celuici ne permet pas d'isoler les serveurs du périmètre des données stratégiques de l'entreprise. La figure suivante représente la structure logique Active Directory utilisée par la Woodgrove Bank :
Figure 1.3 Configuration du service Active Directory de la Woodgrove Bank
La forêt du périmètre utilise le modèle de domaine de forêt unique. Il suffit en effet à assurer la gestion des serveurs du périmètre. Dans le périmètre, les exigences de réplication sont faibles ; il n'est donc pas nécessaire de mettre en place des limites de réplication ou d'avoir recours au modèle de domaines régionaux multiples pour segmenter la forêt. Notez bien que la Woodgrove Bank a choisi cette configuration uniquement pour la gestion des serveurs du périmètre. Si les comptes d'utilisateurs avaient été placés dans le périmètre et que ce dernier s'était trouvé dans plusieurs sites, une autre configuration de domaine aurait été requise.
16
La forêt interne est basée sur un modèle de domaines régionaux multiples. La Woodgrove Bank a créé trois domaines régionaux : Amérique, Europe et Asie. Par ailleurs, la Woodgrove Bank a implémenté une racine de forêt dédiée pour gérer les fonctionnalités au niveau de la forêt. Ce modèle permet de gérer la topologie de la réplication et de déléguer à chaque région l'administration de l'autonomie au niveau du domaine. La topologie de site de la Woodgrove Bank est partagée en trois zones régionales : Amérique, Europe et Asie (AsiePacifique). New York, Londres et Tokyo sont les routeurs principaux de l'ensemble de la topologie. Les concepteurs de la configuration de la Woodgrove Bank ont opté pour une unité d'organisation (UO) principalement orientée objet. La structure d'UO est répliquée dans son intégralité dans chaque domaine régional, et un sousensemble de la structure d'UO est créé dans la racine de la forêt. La figure 3.2 du chapitre 3 de ce guide représente en détail la structure d'UO utilisée par la Woodgrove Bank. Stratégie de déploiement de l'isolation de serveurs et de domaines de la Woodgrove Bank Pour définir au mieux la configuration qui répond à ses attentes, la Woodgrove Bank a créé un projet de laboratoire. Ce projet consiste en l'implémentation d'un petit laboratoire qui permettra de tester la configuration prévue par la Woodgrove Bank (voir figure suivante).
Figure 1.4 Configuration expérimentale de la Woodgrove Bank
Ce schéma représente le sousensemble des ordinateurs utilisés dans le scénario de la Woodgrove Bank pour tester les scénarios présentés dans ce guide. L'objectif de ce projet de démonstration était de fournir une diversité de configuration suffisamment importante dans le 17
laboratoire pour s'assurer que la solution fonctionne comme prévu, tout en évitant les répercutions sur les serveurs de production et les utilisateurs. Les exemples proposés dans ce guide sont basés sur les résultats de l'infrastructure expérimentale représentée dans la figure 1.4. Remarque : comme l'isolation modifie plusieurs aspects du réseau, Microsoft recommande vivement de tester, dans un premier temps, chaque scénario d'isolation dans un environnement de laboratoire afin d'éviter les répercutions sur les environnements de production. Les administrateurs du système informatique doivent se reporter aux chapitres 6 et 7 pour obtenir des informations sur la prise en charge, les procédures opérationnelles et le dépannage. Lorsqu'un projet d'implémentation en laboratoire s'était déroulé avec succès, un groupe de serveurs était identifié pour implémenter un scénario élémentaire d'isolation de serveurs. Ces serveurs correspondent à ceux qui ont le moins de répercutions sur l'entreprise, en cas problème de connexion. Les administrateurs du système informatique et les techniciens du support technique ont suivi un entraînement aux techniques de dépannage. Ces serveurs ont été étroitement surveillés pour mesurer l'impact de l'implémentation sur les performances et sur les appels au support technique. Les rôles de gestion organisationnelle, les processus et les méthodes de support ont été testés. Ensuite, l'un des plus petits domaines de la Woodgrove Bank a été choisi pour tester l'isolation de domaines. Il a été possible de réduire l'impact de ce projet d'isolation de domaines en utilisant IPSec uniquement pour les sousensembles du réseau dans lesquels se trouvait la majorité des membres du domaine. Par ailleurs, il a également été possible de réduire l'impact sur l'entreprise en autorisant les communications nonIPSec lorsque les membres de ce domaine communiquaient avec des ordinateurs n'appartenant pas au projet expérimental. Une fois ces tests terminés, l'équipe de projet possédait toutes les informations nécessaires à la création et à l'implémentation d'une configuration complète pour l'ensemble de l'organisation.
Résumé Ce chapitre constitue une introduction à l'isolation logique. Il explique comment l'isolation de serveurs et de domaines peut être utilisée pour créer une solution de niveau entreprise avec IPSec et des stratégies de groupe. En outre, il comprend une synthèse et une brève description de chaque chapitre de ce guide. Grâce à l'ensemble des informations de ce chapitre, vous pouvez comprendre les avantages que représente cette solution pour votre entreprise, comprendre comment elle s'intègre dans une infrastructure informatique type et cerner les compétences nécessaires à la réussite de sa mise en œuvre.
18
Chapitre 2 : Présentation de l'isolation de serveurs et de domaines À l'époque où les réseaux locaux (LAN) devenaient la norme, les professionnels de l'informatique rivalisaient d'efforts pour proposer des services réactifs, hautement disponibles, tout en maintenant un niveau de sécurité adéquat. Un grand nombre de technologies ont été mises au point pour fonctionner avec TCP/IP, afin de répondre au problème de l'implémentation de la sécurité au niveau des couches réseau et de transport. Parmi ces technologies figurent notamment IPv6, 802.1X, les commutateurs réseau, la segmentation du réseau local virtuel (VLAN) et IPSec (Internet Protocol security). Le résultat indirect de l'introduction de ces technologies n'est autre qu'une sécurité réseau basée sur plusieurs couches. Ces couches peuvent permettre de séparer, de segmenter ou d'isoler un ou plusieurs hôtes ou réseaux d'autres hôtes ou réseaux. L'objectif de ce chapitre consiste à organiser la couche de sécurité IPSec en fonction des autres couches et à expliquer son fonctionnement avec les stratégies de groupe dans une solution d'isolation gérable et évolutive dans un environnement à l'échelle de l'entreprise.
Connaissances préalables requises pour ce chapitre Avant d'exploiter les informations fournies dans ce chapitre, vous devez parfaitement maîtriser les technologies et les concepts suivants. Vous pouvez tirer parti de ce guide sans ces connaissances préalables, mais si vous les maîtrisez, la réussite de l'implémentation sera pratiquement garantie.
Connaissances requises Vous devez posséder des connaissances sur les éléments suivants de Microsoft® Windows Server™ 2003 :
• concepts du service d'annuaire Active Directory® (notamment la structure et les outils
Active Directory, manipulation d'utilisateurs, de groupes et d'autres objets Active Directory, et utilisation des stratégies de groupe) ;
• concepts d'authentification, notamment l'utilisation du protocole Kerberos version 5 et de l'infrastructure de clés publiques (PKI) ;
• sécurité du système Microsoft Windows® ; concepts de sécurité tels que les utilisateurs, les
groupes, l'audit et les listes de contrôle d'accès (ACL) ; utilisation des modèles de sécurité ; concepts d'authentification mutuelle ; méthodes et concepts standards de résolution de noms tels que le système de noms de domaine (DNS, Domain Name System) et le service WINS (Windows Internet Naming Service) ; outils de diagnostic et concepts de dépannage standards Windows ; utilisation des stratégies de groupe ou des outils de ligne de commande pour appliquer des modèles de sécurité ;
• protocole TCP/IP, notamment l'organisation des sousréseaux, les masques réseau et le routage ; fonctionnalités de bas niveau, protocoles et termes tels que ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol) et unité maximale de transfert (MTU, Maximum Transmission Unit).
• principes de gestion des risques de sécurité.
19
Remarque : le chapitre 6, « Deploying IPSec » (Déploiement d'IPSec) du Kit de déploiement de Windows Server 2003 présente des scénarios relatifs au mode de transport IPSec qui n'étaient auparavant pas recommandés. Toutefois, le travail réalisé par Microsoft dans le cadre de son propre déploiement interne d'IPSec et la disponibilité de conseils supplémentaires ont aujourd'hui permis de modifier ces recommandations. Le trafic de diffusion et de multidiffusion ne peut pas encore utiliser IPSec, mais tous les types de trafic IP monodiffusion peuvent être sécurisés via IPSec. Chaque client doit mesurer les avantages du déploiement d'IPSec dans des scénarios d'isolation de domaines ou de serveurs par rapport aux coûts, aux impacts et à d'autres compromis. Microsoft recommande et encourage désormais la généralisation de l'utilisation d'IPSec sur les réseaux de ses clients conformément à ce guide.
Conditions requises pour l'organisation La planification de la sécurité d'une organisation ne peut pas être affectée à une seule personne. Les informations qui permettent de déterminer les exigences exactes d'une organisation proviennent souvent de plusieurs sources de l'organisation. Contactez d'autres personnes de votre entreprise susceptibles d'être concernées par la planification de l'isolation, notamment les personnes suivantes :
• les dirigeants ; • Représentants de groupes d'utilisateurs • les personnes chargées de l'audit et de la sécurité ; • Groupe de gestion des risques • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • Personnel technique, d'administration et des opérations DNS, du serveur Web et du réseau Remarque : selon la structure de votre organisation informatique, plusieurs personnes peuvent occuper un même poste, ou une personne peut occuper plusieurs postes. L'étendue d'un projet d'isolation de serveurs et de domaines nécessite l'intervention d'une équipe complète de personnes afin de bien cerner les exigences de l'entreprise, les problèmes techniques, l'impact sur les utilisateurs et le processus du projet dans son ensemble. Il peut être intéressant qu'une personne faisant preuve d'autorité joue le rôle de contact principal pour ce projet lorsque des observations à plus grande échelle sont requises, telles que celles du personnel de support ou des utilisateurs qui seront affectés au cours du déploiement. Une planification et une communication insuffisantes sont les deux principales causes d'échec des projets complexes. L'équipe de projet doit comprendre ces risques éventuels et s'assurer que des mesures ont été prises pour les limiter.
À qui s'adresse ce chapitre Ce chapitre s'adresse aux architectes et décisionnaires techniques chargés de concevoir une solution personnalisée d'isolation de serveurs et de domaines pour une organisation. Pour exploiter au mieux ce chapitre, il est souhaitable de posséder de solides connaissances techniques sur les technologies abordées et sur l'infrastructure actuelle de l'entreprise.
Exigences au niveau de l'entreprise Vous devez bien comprendre que ce sont les exigences de l'entreprise qui influent sur la solution. L'isolation peut être définie comme une séparation logique ou physique entre un ou plusieurs ordinateurs et d'autres ordinateurs, les empêchant ainsi de communiquer entre eux sur un réseau. Les
20
restrictions de sécurité affecteront nécessairement le travail quotidien des employés au sein d'une organisation. Les modifications apportées dans le cadre de la solution modifieront la façon dont les ordinateurs communiquent les uns avec les autres et avec les ordinateurs non approuvés. Pour la conception de cette solution, l'équipe de projet a besoin de temps pour planifier et analyser la faisabilité de l'implémentation, le personnel de support informatique doit suivre une formation, et au moins un programme d'information des employés doit être mis en place. Les services de sécurité supplémentaires destinés au trafic réseau peuvent nécessiter de la mémoire serveur supplémentaire, voire des cartes réseau d'accélération matérielle. Il est également possible d'avoir recours à d'autres solutions pour atteindre ou les mêmes objectifs d'isolation ou des objectifs similaires. Par conséquent, il est important de déterminer l'impact financier de la solution sur l'entreprise.
Garantie du respect des réglementations Plus les informations personnelles sont stockées dans les ordinateurs, plus l'intérêt pour la confidentialité des données est grand. Le contrôle de l'accès aux informations des clients et des employés n'est plus seulement une bonne pratique commerciale. Selon les lois en vigueur dans chaque pays, une entreprise qui ne respecte pas ses obligations en termes de protection des informations confidentielles devient vulnérable à des attaques financières et légales. Par exemple, les organisations travaillant aux ÉtatsUnis pourraient avoir à respecter (intégralement ou partiellement) les réglementations suivantes :
• FISMA (Federal Information Security Management Act) • SarbanesOxley Public Company Accounting Reform and Investor Protection Act • GLBA (GrammLeachBliley Financial Services Modernization Act) • HIPAA (Health Insurance Portability and Accountability Act) La réglementation HIPAA comporte des directives strictes sur la façon dont les organismes de santé doivent gérer les informations médicales personnelles électroniques (ePHI). Elle n'oblige et ne recommande pas de technologie particulière ; elle indique simplement les caractéristiques requises pour être en conformité avec la protection des ePHI et comment limiter les risques. Considérez l'isolation de domaines ou de serveurs avec protection IPSec comme une mesure de protection technique pour répondre aux exigences des sections de l'HIPAA suivantes :
• Contrôle d'accès 164.312(a)(1) : protéger l'accès réseau entrant vers des ordinateurs approuvés
via des autorisations de stratégie de groupe et utiliser le chiffrement pour empêcher la divulgation des EPHI sur le trafic réseau.
• Contrôles d'audit 164.312(b) : auditer les ordinateurs qui communiquent entre eux. • Intégrité 164.312(c)(1) : limiter l'accès réseau entrant vers des ordinateurs abritant des ePHI
uniquement à un groupe spécifique d'ordinateurs et d'utilisateurs autorisés et approuvés. Empêcher l'altération des ePHI lors des transmissions réseau en assurant l'intégrité et l'authenticité de tous les paquets réseau des connexions applicatives.
• Authentification des personnes ou des entités164.312(d) : requérir l'authentification et l'autorisation des ordinateurs approuvés pour l'accès réseau entrant vers d'autres ordinateurs approuvés.
• Sécurité des transmissions 164.312(e)(1) : assurer l'authenticité, l'intégrité et le chiffrement. En général, vous pouvez répondre à ces exigences en utilisant le protocole SSL (Secure Sockets Layer) et TLS (Transport Layer Security). Pour être en conformité avec les réglementations de sécurité de l'HIPAA, les applications peuvent, par exemple, avoir recours à la technologie Microsoft .NET avec SSL/TLS. Pour plus d'informations, reportezvous au Livre blanc « Healthcare Without Boundaries: IntegrationTechnology for the New Healthcare Economy » à l'adresse suivante : www.microsoft.com/Resources/Healthcare/HealthcareEconomy.aspx.
21
Les communications entre applications doivent toutefois intégrer correctement les contrôles d'algorithme et l'utilisation de SSL/TLS. Les principaux avantages d'une solution d'isolation IPSec sont les suivants : une protection de toutes les applications et du système d'exploitation des ordinateurs hôtes, et une sécurité du trafic réseau pour les applications existantes, sans avoir à les modifier. Pour plus d'informations, reportezvous à la section « Comparaison entre SSL/TLS et IPSec », plus loin dans ce chapitre. Conformité de cette solution avec les réglementations du gouvernement américain Le 16 décembre 2003, l'Office of Management and Budget (OMB) du gouvernement américain a publié un mémorandum sur l'« EAuthentication Guidance for Federal Agencies », disponible à l'adresse suivante : http://www.whitehouse.gov/omb/memoranda/fy04/m0404.pdf. Ce mémorandum indique que le niveau de risque d'une altération de l'authentification correspond au niveau auquel l'authentification électronique (eauthentification) est requise. La publication spéciale 80063 du NIST (National Institute of Standards and Technology) « Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology » (Guide de l'authentification électronique : recommandations du NIST), identifie les exigences techniques des niveaux d'authentification 14. Dans de nombreux cas, les niveaux élevés (3 et 4) d'authentification de l'utilisateur requièrent une réécriture ou un remplacement des applications. Si les risques de sécurité peuvent être réduits dans leur ensemble, vous pouvez utiliser une solution d'authentification de l'utilisateur moins onéreuse pour assurer l'accès aux informations très sensibles de votre organisation. Sur la plateforme Windows, les solutions d'isolation de serveurs et de domaines ajoutent une première couche d'authentification des ordinateurs approuvés, de contrôle d'accès, d'authentification du trafic réseau et de chiffrement, en amont de l'authentification de l'utilisateur au niveau de la couche application. Ainsi, l'utilisation d'une solution d'isolation de serveurs peut permettre de réduire ou de temporiser les modifications d'application requises et contribuer à répondre aux obligations en matière de gestion des risques. Pour être conforme aux réglementations gouvernementales relatives aux produits d'assurance des informations, la société Microsoft s'est engagée à suivre plusieurs processus de certification. Windows 2000 est certifié conforme aux critères communs pour l'évaluation de la sécurité des technologies de l'information (Common Criteria for IT Security Evaluation) (norme ISO 15408) niveau d'assurance 4 (EAL4), avec ALC_FLR.3 (Systematic Flaw Remediation). Cette certification s'applique aux systèmes d'exploitation et aux catégories de protection des données sensibles. Remarque : au moment de la rédaction de cet article, les platesformes Windows XP et Windows Server 2003 étaient en cours de certification. Les composants cryptographiques IPSec de Windows 2000, Windows XP et Windows Server 2003 sont certifiés et répondent aux exigences cryptographiques de la norme FIPS 1401. Ainsi, les solutions d'isolation de serveurs et de domaines peuvent être utilisées pour des applications militaires ou gouvernementales et dans des environnements informatiques associés. Pour plus d'informations, reportezvous aux liens suivants :
• NSTISSP No. 11 Fact Sheet: National
Information Assurance Acquisition Policy nstissp_11_revised_factsheet.pdf
, à l'adresse suivante : http://niap.nist.gov/ccscheme/
• Validated Products List (by Technology Type)
, à l'adresse suivante : http://niap.nist.gov/cc
scheme/vpl/vpl_type.html
• Overview: Windows 2000 Common Criteria Certification
, à l'adresse suivante : www.microsoft.com/technet/security/prodtech/Windows2000/ w2kccwp.mspx
22
• FIPS 140 Evaluation
, à l'adresse suivante : www.microsoft.com/technet/archive/security/topics/
issues/fipseval.mspx
Les informations de cette section concernent uniquement les organisations basées aux ÉtatsUnis. Toutefois, des réglementations connexes voient le jour dans le monde entier, comme en témoignent des lois telles que la directive européenne sur la protection des données (1988) et la loi canadienne sur la protection des renseignements personnels et les documents électroniques (PIPEDA), qui imposent toutes deux des instructions strictes concernant la gestion des identités et la confidentialité des données.
Évaluation des risques liés à l'infrastructure informatique L'évaluation des risques de l'entreprise consiste à identifier la dépendance entre l'entreprise et son infrastructure informatique. L'évaluation des risques de sécurité informatique consiste à identifier et à définir un ordre de priorité des risques liés à l'intégrité des informations et à la stabilité des services. L'évaluation des risques de sécurité doit justifier la nécessité de prévention de ces risques et évaluer les coûts liés à la nonanticipation de ces risques. Les évaluations des coûts jouent un rôle très important dans l'évaluation des différentes solutions techniques, et ce pour chaque problème. Étant donné qu'une seule solution ne permet pas d'éviter 100 % des risques, comparez les solutions et leurs différents coûts. Les décisionnaires peuvent, par exemple, évaluer le coût d'une solution d'isolation en termes de réduction des risques liés à un service dégradé ou interrompu suite à l'attaque d'un virus ou d'un vers. Pour certaines organisations, lorsqu'un pirate parvient à accéder à leurs données stratégiques, l'impact et les coûts résultant de l'attaque peuvent être dramatiques. Remarque : dans certains pays et dans certains états, la loi oblige les entreprises à informer leurs clients des violations de sécurité éventuelles dont ils pourraient être victimes. Pour obtenir des réponses aux questions juridiques relatives à votre organisation, contactez votre organisme public local ou un conseiller juridique. Les catégories suivantes peuvent vous aider à évaluer le coût total d'un incident de sécurité :
• Coût occasionné par une perte de service. Pour déterminer le coût total qu'occasionne une perte de service sur un serveur réseau, faites la somme des coûts suivants :
• Temps de réponse requis par le personnel de support en cas d'incident jklhl kjhlkj hkjlh lkjh kjlh kjh kjh ljkh • Manque à gagner suite à l'interruption de l'application • Perte de productivité interne
• Coût occasionné par le vol d'informations. Pour déterminer le coût total qu'occasionne le vol d'informations enregistrées sur un serveur réseau interne, faites la somme des coûts suivants :
• Perte de la propriété intellectuelle requise pour développer l'information • Perte des recettes à venir sur tous les produits, en raison d'une perte de confiance des clients (suite à la médiatisation du vol) • Perte de valeur marchande, en raison d'une perte de confiance des investisseurs (suite à la médiatisation du vol) • Temps de réponse requis en interne par les services de marketing et de développement • Perte de recettes éventuelles, en raison d'efforts de réponse en interne • Temps nécessaire pour limiter l'utilisation malveillante des informations à l'encontre de l'entreprise, des employés ou des clients
23
• Coût occasionné par la compromission des informations d'identification d'administration
sur le serveur. Pour déterminer le coût total qu'occasionne la compromission des informations d'identification d'administration sur un serveur réseau interne, faites la somme des coûts suivants : • Efforts requis en interne pour répondre à l'attaque et remplacer le serveur • Protection en interne des ordinateurs susceptibles d'être attaqués suite à la compromission des informations d'identification d'administration sur le serveur
• Coût occasionné par des mesures de réglementation ou des actions juridiques ultérieures. Pour déterminer le coût total qu'occasionnent les exigences d'une action en justice, faites la somme des coûts suivants :
• Coût d'une action en justice si l'attaquant a été identifié mais la décision de la cour vous est défavorable • Coût d'une action en justice si l'attaquant a été identifié et la décision de la cour vous est favorable, mais l'accusé est dans l'impossibilité de payer le montant des dommages • Coût des amendes, audits, restrictions et autres efforts visant à restaurer l'environnement de travail actuel
Investissement dans des solutions de sécurité des informations sur le long terme La protection de l'accès au réseau (NAP, Microsoft Network Access Protection) constitue un moyen efficace de contrôler si les périphériques qui se connectent au réseau ou les uns aux autres sont conformes aux stratégies. La mise en quarantaine des accès à distance et l'isolation de serveurs et de domaines sont deux moyens allant en ce sens et pouvant désormais être implémentés sous Windows 2000 et des platesformes ultérieures. En associant les atouts du périmètre et de l'isolation en interne, l'organisation est armée pour lutter contre les infections et tout autre type d'attaque lancés à partir d'ordinateurs non approuvés et découlant d'informations d'identification compromises. Pour plus d'informations sur l'initiative NAP, reportezvous à la page Network Access Protection site Microsoft à l'adresse : www.microsoft.com/nap.
du
Pour plus d'informations sur les réseaux privés virtuels (VPN) et le contrôle d'accès des quarantaines, reportezvous à la page Virtual Private Networks for Windows Server 2003 du site Microsoft à l'adresse : www.microsoft.com/vpn. Dans les prochaines versions de Windows, Microsoft prévoit de proposer une protection d'accès réseau encore plus facile à gérer et plus complète. Pour plus d'informations, reportezvous au Livre blanc « Introduction to Network Access Protection », à l'adresse : www.microsoft.com/windowsserver2003/techinfo/ overview/napoverview.mspx.
Identifications des ordinateurs approuvés L'approbation et le fonctionnement de l'approbation avec les ordinateurs est un point important de l'isolation de serveurs et de domaines. L' isolation permet à n'importe quel hôte approuvé de définir les personnes autorisées à accéder au réseau. Quel que soit le type de connexion établi entre les ordinateurs distants et l'extrémité distante de la connexion (par exemple, une connexion sans fil, de réseau local ou Internet), l'ordinateur distant doit utiliser IPSec pour négocier l'approbation et sécuriser le trafic TCP/IP de bout en bout avec l'ordinateur de destination. Ce modèle de sécurité de bout en bout offre un niveau de protection des communications réseau que ne proposent pas les autres technologies de sécurité et de contrôle d'accès réseau (par exemple, VPN, 802.1x, 802.11 WEP).
24
Pour empêcher le vol, l'altération ou l'utilisation malveillante des informations d'identification, il est primordial d'approuver d'abord l'ordinateur distant. Dans le cadre de cette solution, l'approbation permet à une organisation d'être presque certaine qu'un ordinateur est dans un état connu et qu'il répond aux exigences minimales de sécurité définies par l'organisation. Ces exigences peuvent être d'ordre technique, axées sur la sécurité, liées à l'activité professionnelle de l'entreprise ou à plusieurs de ces points. Ces exigences déterminent également l'état dans lequel doit se trouver un ordinateur avant d'établir une communication avec d'autres ordinateurs. Microsoft recommande que la spécification des ordinateurs approuvés inclue une liste à jour des mises à jour de sécurité et des services packs requis. Dans l'idéal, vous devez gérer et appliquer ces mises à jour via un système de gestion des correctifs tel que le service Windows Update ou Microsoft Systems Management Server (SMS). La fréquence d'application de ces mises à jour dépend de la durée nécessaire à votre organisation pour tester et déployer chaque mise à jour. Cependant, pour une sécurité optimale, vous devez appliquer les mises à jour de votre environnement dès que possible. Les ordinateurs non approuvés sont des ordinateurs susceptibles de ne pas répondre aux exigences de sécurité. En règle générale, un ordinateur n'est pas approuvé s'il n'est pas géré ou s'il n'est pas sécurisé. L'isolation de serveur et de domaine vise à limiter les risques qu'encourent les ressources approuvées de l'entreprise, en implémentant des outils, des technologies et des processus chargés de les protéger. La solution garantit que :
• seuls les ordinateurs approuvés (ceux qui répondent à des exigences de sécurité spécifiques) peuvent accéder à des ressources approuvées ;
• les ordinateurs non approuvés n'ont pas accès aux ressources approuvées, sauf si une raison professionnelle précise justifie de courir le risque.
Vous devez autoriser, par défaut, l'accès réseau aux ressources approuvées uniquement à partir d'autres ressources approuvées. Par ailleurs, vous devez contrôler l'accès à la couche réseau, en utilisant les fonctions d'accord ou de refus d'autorisation et les listes de contrôle d'accès (ACL) pour des utilisateurs et des ordinateurs spécifiques au sein de l'environnement approuvé. En créant cet environnement approuvé et en limitant les communications autorisées à l'intérieur et à l'extérieur de cet environnement, l'entreprise limite l'ensemble des risques qu'encourent ses données. Parmi les autres avantages métier figurent notamment les suivants :
• grande compréhension du flux des données dans des zones spécifiques du réseau ; • meilleure adoption des programmes de sécurité utilisés pour obtenir le statut « approuvé » ; • création d'un inventaire, à jour, des hôtes et périphériques réseau. Par exemple, dans le scénario Woodgrove Bank, les ordinateurs approuvés sont tous les ordinateurs qui exécutent Windows 2000 Service Pack (SP) 4, Windows XP SP2 ou une version ultérieure, ou Windows Server 2003 ou ultérieur dans l'un des domaines appartenant à la Woodgrove Bank et gérés par cette dernière. En outre, les ressources approuvées, notamment tous les ordinateurs (exécutant Windows 2000 ou une version ultérieure) qui utilisent des stratégies de groupe pour fournir des paramètres de sécurité, sont régulièrement examinées par le personnel informatique pour vérifier qu'elles restent conformes aux exigences minimales. Le personnel informatique examine également les ressources approuvées pour vérifier que l'installation et la configuration des logiciels de sécurité spécialisés (tel qu'un antivirus) sont contrôlées de façon centralisée selon les exigences de sécurité propres à la Woodgrove Bank. Pour plus d'informations sur l'identification des ordinateurs approuvés
25
dans le cadre de la solution, reportezvous à la section « Définition de l'approbation » du chapitre 3 « Détermination de l'état actuel de votre infrastructure informatique » de ce guide.
Ordinateurs non gérés Un ordinateur non géré est un ordinateur dont les paramètres de sécurité ne sont pas contrôlés de façon centralisée par le service informatique. En outre, tout ordinateur qui ne présente pas les fonctionnalités de gestion de sécurité requises est également considéré comme non géré. Les ordinateurs non gérés sont considérés comme non approuvés car l'organisation ne peut pas garantir qu'ils répondent aux exigences de sécurité des ordinateurs approuvés auxquels ils essaient d'accéder.
Ordinateurs non sécurisés Les ordinateurs non approuvés incluent également les ordinateurs qui exécutent un système d'exploitation qui n'est pas configuré, ou ne peut pas être configuré, pour atteindre le niveau de sécurité requis. Les ordinateurs non sécurisés peuvent entrer dans l'une des quatre catégories suivantes :
• Faible niveau de sécurité du système d'exploitation. Cette catégorie inclut les ordinateurs qui
exécutent un système d'exploitation ne possédant pas le niveau d'infrastructure de sécurité requis. Parmi ces systèmes d'exploitation figurent notamment : Windows 9x, Microsoft Windows NT® et Windows CE. En général, les fonctionnalités requises pour l'infrastructure de sécurité sont présentes dans les systèmes d'exploitation plus récents, comme Windows XP et Windows Server 2003. Ces fonctionnalités incluent : les contrôles d'accès (par exemple, les autorisations sur les fichiers), les fonctions de sécurité réseau de chiffrement des paquets, et d'authentification et d'autorisation renforcées, différents niveaux de privilège (utilisateur et administrateur), la prise en charge d'une gestion centralisée des paramètres de sécurité, la prise en charge permettant d'assurer la confidentialité et l'intégrité des données, et la prise en charge d'autres technologies de sécurité (comme le protocole d'authentification Kerberos et les services de certificats).
• Configuration incorrecte. Même les systèmes d'exploitation les plus fiables peuvent être configurés de façon incorrecte, et donc à la merci d'une attaque. Ces ordinateurs doivent également être considérés comme des périphériques non sécurisés.
• Absence d'un niveau de mise à jour requis. Comme la sécurité informatique est en constante
évolution, la plupart des éditeurs de logiciels proposent des mises à jour logicielles pour corriger les vulnérabilités de leurs produits. Une organisation peut définir un niveau minimum de mise à jour pour considérer un hôte comme approuvé. Dans ce cas, les ordinateurs qui ne possèdent pas le niveau de mise à jour requis sont considérés comme des périphériques non sécurisés.
• Ordinateurs approuvés pouvant être compromis. Il est possible qu'un ordinateur approuvé soit compromis, en général, par une personne malveillante à laquelle vous faisiez confiance. Lorsque la sécurité d'un ordinateur approuvé est compromise, l'ordinateur n'est plus considéré comme approuvé tant que cette situation de risque n'a pas été résolue. Comprenez bien que si vous n'avez pas confiance en l'utilisateur d'un ordinateur, vous ne pouvez pas avoir confiance en son ordinateur.
Les périphériques qui entrent dans l'une de ces quatre catégories sont considérés comme étant non approuvés car l'organisation n'a pas la certitude qu'ils n'ont pas été compromis d'une manière ou d'une autre. Ils représentent donc un risque significatif pour les ordinateurs approuvés auxquels ils tentent d'accéder.
26
Isolation de serveurs et de domaines : objectifs directement réalisables Avant toute chose, l'isolation de serveurs et de domaines vise à limiter les risques d'accès non autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. Avec les platesformes actuelles, l'isolation d'un ordinateur distant en limitant l'accès réseau entrant repose sur la possibilité d'authentifier avec succès un ordinateur comme membre du domaine par le biais du protocole de négociation de sécurité IKE (Internet Key Exchange) d'IPSec. L'authentification de l'utilisateur intervient uniquement une fois l'authentification de l'ordinateur réussie et lorsque les associations de sécurité IPSec protègent toutes les connexions d'applications et de protocoles de niveau supérieur entre deux ordinateurs. L'isolation de serveurs et de domaines vous permet donc d'atteindre les objectifs suivants :
• Isoler les ordinateurs membres du domaine approuvé des périphériques non approuvés au niveau du réseau.
• Vérifier que l'accès réseau entrant à un membre du domaine approuvé sur le réseau interne requiert l'utilisation d'un autre membre du domaine approuvé.
• Autoriser les membres du domaine approuvé à limiter l'accès réseau entrant à un groupe spécifique d'ordinateurs membres du domaine.
• Concentrer les risques d'attaque sur un petit nombre d'hôtes, constituant une barrière de protection du domaine approuvé, où les stratégies de minimisation des risques maximum (journalisation, surveillance, détection d'intrusion, etc.) peuvent être appliquées de façon plus efficace.
• Mettre l'accent et la priorité sur la surveillance proactive et les efforts de conformité avant toute attaque.
• Se concentrer sur les efforts de réparation et de récupération, avant, pendant et après toute attaque, et être plus rapide sur ces points.
• Améliorer la sécurité en ajoutant l'authentification mutuelle par paquet renforcée, l'intégrité, l'anti relecture et le chiffrement, sans avoir à modifier les applications et les protocoles de niveau supérieur, tels que SMB (Server Message Block) ou NetBT.
L'isolation de serveurs et de domaines vise à protéger tous les services réseau sur l'hôte approuvé contre toute attaque ou accès réseau non approuvé. L'isolation de serveurs et de domaines rend les hôtes moins vulnérables aux failles et aux erreurs présentes dans d'autres types de sécurité réseau, et aux failles de protection des informations d'identification de l'utilisateur. Enfin, les solutions d'isolation de serveurs et de domaines permettent d'éviter des menaces réseau similaires, mais elles fournissent des niveaux de contrôle d'accès réseau et de protection du trafic différents de ceux des autres types de technologie de sécurité réseau. Par exemple, une solution d'isolation de serveurs et de domaines peut autoriser l'accès entrant à des ordinateurs hôtes approuvés spécifiques en fonction de l'identité du domaine de l'utilisateur et de l'hôte, ce qui garantit la protection de bout en bout de la communication autorisée. Les autres technologies de sécurité réseau, quant à elles, ne prennent généralement en charge que l'identité de l'utilisateur.
Isolation de serveurs et de domaines : risques évités Le tout premier risque que permet d'éviter l'isolation de serveurs et de domaines est celui de l'accès non autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. La solution seule ne permet pas de limiter complètement tous les risques de sécurité. Si ces risques de sécurité ne sont pas pris en charge par des processus et technologies de sécurité complémentaires, il est possible que vous ne tiriez pas parti des avantages de la solution d'isolation. Il existe plusieurs risques de sécurité graves que cette solution ne permet pas d'éviter directement, par exemple :
27
• Risque de vol ou de divulgation de données sensibles par des utilisateurs approuvés. La
solution d'isolation permet de contrôler les communications des ordinateurs au sein du réseau interne, mais les administrateurs peuvent compromettre ce contrôle. Cette solution ne permet pas de réduire le risque qu'un utilisateur approuvé copie ou divulgue des données sensibles.
• Risque de compromission des informations d'identification des utilisateurs approuvés. Pour protéger les informations de connexion réseau, un administrateur peut décider de chiffrer la plus grande partie du trafic IPSec, mais la protection IPSec du trafic d'ouverture de session utilisateur vers les contrôleurs de domaine n'est pas prise en charge. L'isolation de serveurs et de domaines peut obliger une personne malveillante à utiliser un hôte approuvé pour attaquer d'autres hôtes approuvés. Une personne malveillante peut également attaquer des hôtes approuvés en utilisant des informations d'identification compromise d'hôtes qui sont dispensés d'utiliser IPSec avec des hôtes approuvés (par exemple, des contrôleurs de domaine et des serveurs DNS) ou d'hôtes qui acceptent des connexions entrantes d'ordinateurs non approuvés. Un administrateur peut déterminer si les hôtes approuvés communiquent vers l'extérieur, vers des hôtes non approuvés, mais la solution ne permet pas de limiter le risque qu'un utilisateur approuvé perde ses informations d'identification en se laissant abuser par un attaquant l'ayant incité à divulguer son mot de passe.
• Utilisateurs malveillants. Cette catégorie inclut les utilisateurs légitimes qui profitent de leurs
droits d'accès. Par exemple, cette solution ne permet pas de réduire le risque qu'un utilisateur contrarié décide de voler des informations en utilisant les hôtes approuvés auxquels son poste dans l'entreprise lui donne accès. L'accès physique à un ordinateur hôte approuvé peut permettre à une personne malveillante d'obtenir un accès non autorisé et administratif à cet hôte. Comme les administrateurs peuvent désactiver la protection d'isolation de serveurs et de domaines, il est primordial de limiter l'accès et le nombre d'administrateurs (y compris les administrateurs de l'entreprise, les administrateurs de domaine et les administrateurs locaux sur des stations de travail ou des serveurs membres).
• Risque que des ordinateurs non approuvés accèdent à d'autres ordinateurs non approuvés. Cette solution ne permet pas de limiter le risque que des ordinateurs non approuvés utilisés par une personne malveillante s'en prennent à d'autres ordinateurs non approuvés.
• Risque que des ordinateurs non approuvés attaquent certains ordinateurs approuvés. Les
solutions d'isolation de serveurs et de domaines sont conçues pour protéger les hôtes approuvés. Cependant, pour des raisons pratiques de déploiement, cette solution identifie les membres du domaine approuvés qui, pour diverses raisons, n'ont pas recours à IPSec pour négocier un accès approuvé à d'autres hôtes approuvés. Ces ordinateurs approuvés, mais nonIPSec, font partie d'une liste d'exemptions (par exemple, les contrôleurs de domaine). Cette solution identifie également des hôtes approuvés auxquels peuvent accéder des ordinateurs non approuvés pour fournir des services de limite pour le domaine d'isolation. Une personne malveillante qui parvient à obtenir le contrôle d'un hôte exempté ou d'un hôte de limite peut attaquer tous les autres hôtes approuvés se trouvant dans le domaine d'isolation.
• Garantie que les hôtes approuvés sont conformes aux exigences de sécurité. Cette solution donne des conseils sur la définition de l'approbation des hôtes et requiert surtout qu'ils soient membres d'un domaine Windows 2000 ou Windows Server 2003. Cette solution dépend uniquement de la réussite de l'authentification IPSec IKE basée sur le domaine (Kerberos) pour établir l'approbation et la connectivité protégée par IPSec. Avec le temps, les hôtes approuvés peuvent, pour diverses raisons, ne plus répondre totalement aux critères exigés des hôtes approuvés mais être toujours en mesure de s'authentifier avec succès comme membres du domaine. Les systèmes et processus de gestion informatique de l'organisation doivent s'assurer que les membres du domaine sont conformes à la définition des hôtes approuvés.
Pour résoudre ces problèmes, les configurations et modèles recommandés de renforcement de la sécurité ont été appliqués à tous les systèmes dans l'environnement de laboratoire de la Woodgrove Bank. Pour plus d'informations sur les procédures de gestion et les technologies de
28
sécurité de la plateforme Windows, reportezvous à la page TechNet Security Resource Center du site Web Microsoft, à l'adresse : www.microsoft.com/technet/security/.
Comment l'isolation de serveurs et de domaines s'intègretelle dans ma stratégie de sécurité réseau globale ? L'isolation de serveurs et de domaines est utilisée en complément d'autres mécanismes préventifs et réactifs pour protéger le réseau et les périphériques qui y connectés, y compris les ordinateurs. Comme la sécurité est un problème complexe nécessitant une protection à plusieurs couches, il peut être utile de rappeler en quoi consiste une protection renforcée, ainsi que les concepts importants qui y sont rattachés. Une stratégie de sécurité réseau complète applique les technologies appropriées pour réduire les risques les plus importants sans dépendance significative visàvis des points de défaillance uniques. Par exemple, si le périmètre de sécurité échoue suite à une configuration incorrecte ou à l'intervention d'un employé malveillant, quelle autre couche de protection peut empêcher les hôtes approuvés internes de subir des infections et attaques réseau ? Qu'estce qui pourrait permettre de bloquer des attaques ciblant les hôtes approuvés d'Europe et d'Asie, alors que la personne malveillante est connecté à un port Ethernet, dans une salle de réunion de n'importe quel bureau américain ?
Protection renforcée La protection renforcée peut être définie comme une approche par couche permettant de protéger un ordinateur, au lieu de se fier à un dispositif de protection unique. Pour mettre en place des couches de protection efficaces, il est indispensable d'identifier avant tout les sources d'infection et les adversaires susceptibles d'attaquer une organisation, ainsi que leurs cibles potentielles. Par exemple, un adversaire peut être un concurrent louant les services d'une société d'espionnage industriel pour subtiliser des informations sur un nouveau produit ou un nouveau service en cours de développement. Lorsque vous avez cerné vos adversaires potentiels et leurs cibles probables, vous devez appliquer des procédures de réponse aux incidents pour les ordinateurs susceptibles d'être compromis. L'authentification, l'autorisation, la confidentialité et la nonrépudiation comptent notamment parmi ces méthodes. Une organisation qui respecte la pratique recommandée protectiondétectionréaction prend conscience que des attaques peuvent survenir et comprend que la détection anticipée de ces attaques et la réduction des interruptions de service ou des pertes de données sont primordiales. Étant donné que les probabilités d'attaque sont élevées, la méthode protectiondétectionréaction permet de comprendre qu'il est nécessaire de concentrer davantage les efforts sur la protection des données et des ressources plutôt que sur la prévention des attaques. En règle générale, il est plus rentable de se protéger d'une attaque que de réparer les dégâts qu'elle peut occasionner. Tous les dispositifs de protection des informations mettent l'accent sur les personnes, les processus et les technologies. L'isolation tient compte de l'ensemble de ces trois facteurs : elle se réalise via une identification précise des risques, des exigences et des ressources à protéger. Cette identification englobe les facteurs « personnes » et « processus ». En outre, l'isolation requiert des connaissances sur l'état actuel du réseau et de ses périphériques, sur les exigences de communication qui définissent l'interaction entre ordinateurs, et sur les exigences de sécurité qui risquent de limiter les exigences visant à obtenir le parfait équilibre entre sécurité et communication. Pour plus d'informations sur ce sujet reportezvous au Livre blanc « Defense in Depth renforcée) de la NSA (National Security Agency), à l'adresse : http://www.nsa.gov/snac/support/defenseindepth.pdf.
29
» (protection
Pour plus d'informations et des exemples pratiques pour l'exécution de ce processus, reportezvous au chapitre Enterprise Design (Configuration entreprise) du guide Windows Server System Reference Architecture (Architecture de référence des systèmes de serveurs Windows) sur le site Web de Technet, à l'adresse www.microsoft.com/technet/itsolutions/wssra/ raguide/Security_Architecture_1.mspx. La figure suivante illustre l'intégration d'une solution d'isolation logique dans une approche de protection renforcée utilisée dans l'architecture de référence des systèmes de serveurs Windows :
Figure 2.1 Protection renforcée avec l'isolation logique
Dans cette figure, il est important de comprendre que la couche de sécurité de l'isolation logique sécurise directement l'ordinateur hôte via le contrôle des communications réseau. Il s'agit d'un rôle très similaire à celui d'un parefeu pour hôte. Toutefois, au lieu d'autoriser et de bloquer les services sur les ports comme un parefeu pour hôte, IPSec autorise et bloque les services et négocie les services d'accès réseau approuvés. Une fois l'accès accordé, IPSec peut sécuriser tous les paquets entre les deux ordinateurs. Comme indiqué dans le cadre de cette solution, une solution d'« isolation logique » telle que l'isolation de serveurs et de domaines :
• ne sécurise pas les périphériques réseau, comme les routeurs ; • n'offre pas un contrôle d'accès réseau physique (ex. : définition des ordinateurs autorisés à établir une connexion VPN d'accès à distance) ou les protections que proposent les parefeu réseau ;
• ne sécurise pas les liaisons réseau, telles que 802.1x pour les contrôles d'accès et le
chiffrement 802.11 WEP pour les liaisons sans fil. IPSec offre toutefois une protection de bout en bout sur toutes les liaisons réseau entre l'adresse IP source et l'adresse IP de destination ;
30
• ne sécurise pas l'ensemble des hôtes sur le réseau, mais uniquement ceux qui sont inclus dans la solution d'isolation ;
• ne sécurise pas les chemins du niveau application, tels que le chemin de bout en bout via lequel
sont acheminés les messages électroniques et .NET, ni les requêtes HTTP (Hypertext Transmission Protocol) pouvant être en proxy à plusieurs reprises entre le client et la destination du serveur Web.
Vous devez considérer la sécurité au niveau de chaque couche comme une partie intégrante de l'analyse de réduction des risques de sécurité informatique. Par exemple, si un ordinateur n'est pas autorisé à accéder à un serveur au niveau de la couche d'isolation logique, l'utilisateur qui se connecte à cet ordinateur importe peu. Tous les utilisateurs, même les administrateurs, se verront refuser l'accès au serveur.
Comparaison entre SSL/TLS et IPSec IPSec n'est pas destiné à remplacer la sécurité de niveau application, telle que SSL/TLS. L'un des principaux avantages d'IPSec est qu'il permet de sécuriser le trafic réseau pour les applications existantes, sans avoir à les modifier. L'utilisation d'IPSec dans des environnements dans lesquels des applications utilisent SSL/TLS offre les avantages suivants :
• Il aide à protéger l'ensemble des applications et le système d'exploitation des attaques lancées depuis des ordinateurs non approuvés et d'autres périphériques.
• Il met en place une protection renforcée contre toute utilisation inappropriée ou non conforme de SSL/TLS (par exemple, si toutes les données eHPI ne sont pas chiffrées et authentifiées).
• Il contribue à empêcher la saisie des informations d'identification de l'utilisateur sur des ordinateurs non approuvés, car les utilisateurs ne sont pas invités à se connecter à un site Web SSL/TLS interne tant qu'IPSec établit une approbation mutuelle entre le client et le serveur.
• Il offre une sécurité lorsque vous ne pouvez pas utiliser les paramètres du registre de Windows
pour sélectionner des algorithmes SSL/TLS conformes à la réglementation. Windows 2000, Windows XP et Windows Server 2003 fournissent des contrôles de clé de registre pour les algorithmes SSL/TLS, présentés dans l'article 245030 « How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll » (Comment limiter l'utilisation de certains protocoles et algorithmes de chiffrement dans Schannel.dll) de la Base de connaissances Microsoft, à l'adresse suivante : http://support.microsoft.com/?kbid=245030.
• Il offre une sécurité lorsque les certificats ne sont pas disponibles. IPSec sécurise le trafic entre les adresses IP source et de destination. SSL/TLS peut sécuriser le trafic sur tout le chemin de l'application (par exemple, d'un navigateur Web, via un proxy Web, vers un serveur Web). L'institut NIST (National Institute for Standards and Technology) développe actuellement un guide d'utilisation de TLS. La publication spéciale 80052, « Guidelines on the Selection and Use of Transport Layer Security » (Guide de sélection et d'utilisation de TLS) est un guide sur l'implémentation de TLS dans un gouvernement fédéral. Pour plus d'informations sur ce guide, reportezvous au site Web de la NIST Computer Security Division , à l'adresse http://csrc.nist.gov/publications/index.html. Il n'existe pas de guide similaire pour l'utilisation d'IPSec. Toutefois, la NSA a publié des guides sur l'utilisation d'IPSec avec Windows 2000. Ces guides sont disponibles sur le site Web de la NSA , à l'adresse http://nsa2.www.conxion.com/win2k/download.htm. Les organisations qui sont dans l'obligation de se conformer aux recommandations de la NSA doivent analyser cette solution et consulter les guides de la NSA.
31
IPSec avec l'authentification par certificat offre une protection similaire à SSL/TLS, à quelques différences près. Windows IPSec prend en charge un petit sousensemble des algorithmes de chiffrement gérés par TLS et recommandés dans la publication spéciale 80052 de la NIST (par exemple, 3DES, SHA1 et DiffieHellman éphémère 1024 bits). La solution présentée dans ce guide utilise les signatures de protocole Kerberos pour l'authentification IKE entre membres du domaine, et non les signatures basées sur les certificats. La négociation IKE Windows IPSec établit l'approbation mutuelle entre les ordinateurs qui utilisent le protocole Kerberos et l'authentification basée sur les certificats. Comme l'authentification IKE n'est pas intégrée dans les applications, elle ne peut pas vérifier si le nom de l'ordinateur de destination correspond bien à celui de l'ordinateur auquel doit se connecter l'application. De ce fait, une attaque du type « maninthemiddle » lancée depuis un autre hôte approuvé peut avoir lieu. Mais comme l'application s'intègre à SSL/TLS, le nom de l'ordinateur de destination est authentifié (approuvé) et peut également être comparé au nom de l'ordinateur auquel doit se connecter l'application.
Rappel terminologique Avant de poursuivre ce chapitre, il peut être intéressant de revoir certains termes qui sont souvent utilisés dans le cadre de cette solution. Si vous connaissez déjà la signification de ces termes, vous pouvez passer directement à la section suivante. En revanche, si vous ne connaissez pas vraiment ces termes, vous risquez de ne pas bien comprendre certaines explications fournies dans ce guide.
Termes relatifs à l'isolation Les termes suivants sont uniquement employés pour le concept d'isolation logique. Assurezvous de bien comprendre ces termes avant de poursuivre la lecture de ce chapitre :
• Isolation. Séparation logique entre un ou plusieurs ordinateurs et d'autres ordinateurs. • Isolation de domaines. Ce terme définit le type d'isolation qui vise à séparer les ordinateurs
approuvés des ordinateurs non approuvés. Pour être isolé, un ordinateur doit posséder des informations d'identification valides et être authentifié avec succès via IKE. Le domaine peut être n'importe quel domaine dans le chemin d'accès à l'approbation, accessible via une approbation bidirectionnelle entre les deux hôtes tentant de sécuriser leurs communications.
• Isolation de serveurs. Ce terme définit la manière dont les serveurs peuvent limiter l'accès entrant à un groupe spécifique d'ordinateurs approuvés, en utilisant IPSec et l'autorisation « Accéder à cet ordinateur à partir du réseau ».
• Isolation logique. Il s'agit d'un terme plus général utilisé pour les technologies d'isolation. Il peut notamment inclure l'isolation de domaines, l'isolation de serveurs et la protection de l'accès au réseau (NAP) pour isoler des ordinateurs au niveau de la couche réseau.
• Groupe d'isolation. Regroupement logique d'ordinateurs hôtes approuvés partageant les mêmes
stratégies de sécurité des communications, notamment et principalement les mêmes exigences en termes de trafic réseau entrant et sortant. Vous pouvez implémenter les contrôles d'accès entrant et sortant d'un groupe d'isolation à l'aide d'une stratégie IPSec en utilisant des actions autoriser/bloquer, ou en faisant en sorte qu'IPSec négocie la sécurité conjointement avec les droits de connexion réseau de la stratégie de groupe (et éventuellement avec d'autres paramètres de configuration ou de connexion réseau). Les applications, services réseau et protocoles doivent bénéficier d'une configuration spécifique pour répondre aux exigences de trafic au niveau de leur couche. Par exemple, un groupe de serveur Exchange requiert qu'un ordinateur client ou serveur soit membre du domaine pour établir une connexion TCP/IP entrante. Ce groupe, qui n'est pas autorisé à établir des connexions TCP/IP sortantes vers des membres n'appartenant pas au domaine (sauf certaines exceptions) est appelé groupe d'isolation Exchange Server.
32
• Domaine d'isolation. Il s'agit d'un groupe d'isolation dans lequel les membres du groupe sont les
mêmes que ceux du domaine Windows. Si le domaine possède des domaines approuvés bidirectionnels, les membres de ces domaines appartiennent au domaine d'isolation. Comme dans un groupe d'isolation, les exigences en termes de trafic réseau entrant et sortant sont simples : les connexions entrantes ne peuvent provenir que d'autres membres du domaine de l'hôte approuvé. Un serveur placé dans le groupe d'isolation de serveurs peut avoir des clients qui appartiennent au domaine isolé.
• Groupe d'accès réseau. Ce terme fait référence au groupe de sécurité de domaine de Windows, utilisé pour contrôler l'accès réseau à un ordinateur, en utilisant des paramètres de sécurité de stratégie de groupe pour les droits de connexion réseau. Ces paramètres sont créés pour appliquer les exigences d'accès entrant pour les groupes d'isolation. Chaque groupe d'isolation peut comprendre un groupe d'accès réseau autorisé (ANAG, Allow network access group) et un groupe d'accès réseau refusé (DNAG, Deny network access group).
• Approbation. Ce terme est utilisé pour définir le fait qu'un ordinateur accepte l'identité validée via
le processus d'authentification. L'approbation de domaine implique que tous les membres du domaine approuvent le contrôleur de domaine pour établir l'identité et fournir correctement les informations d'appartenance au groupe à cette identité. L'approbation est nécessaire pour communiquer avec un ordinateur distant en utilisant IPSec. L'approbation signifie également qu'un utilisateur ou un ordinateur est considéré comme un élément avec lequel il est possible de communiquer et ne présentant vraisemblablement qu'un faible risque de menace.
• Hôte de confiance. Ce terme désigne un ordinateur susceptible d'être configuré pour répondre
aux exigences de sécurité minimales d'une organisation, mais pouvant être, ou non, un hôte approuvé. Il est primordial de connaître les ordinateurs dignes de confiance lors de la planification des membres d'un groupe d'isolation approuvé.
• Hôte approuvé. Ce terme fait référence à une plateforme exécutant Windows 2000, Windows XP
ou Windows Server 2003, appartenant au moins à un domaine de sécurité de Windows 2000 et capable d'appliquer une stratégie IPSec. Les hôtes approuvés sont en général définis pour répondre à des exigences de gestion et de sécurité supplémentaires. La configuration de l'hôte est contrôlée de façon à ce que les risques de sécurité de l'hôte soient faibles et gérables. Les hôtes approuvés sont moins susceptibles d'être à l'origine d'une infection ou d'un acte malveillant. Pour plus d'informations à ce sujet, reportezvous au chapitre 3 de ce guide « Détermination de l'état actuel de votre infrastructure informatique ».
• Hôte non approuvé. Ordinateur hôte qui n'est pas un hôte approuvé. Cet ordinateur possède une configuration inconnue ou non gérée. Il ne peut être garanti que l'hôte (ou utilisateur de l'hôte) ne sera pas à l'origine d'une source d'infection ou d'un acte de malveillance en cas de connexion au réseau.
• Hôte de limite. Hôte approuvé qui est exposé au trafic réseau d'hôtes approuvés et non
approuvés. Il doit par conséquent faire l'objet d'une surveillance plus étroite et être doté de moyens de protection plus importants que les autres hôtes approuvés pour lutter contre les attaques. Il doit y avoir le minimum d'hôtes de limite possible car ces derniers constituent une menace importante pour les autres hôtes approuvés.
• Exemption. Ordinateur faisant partie ou non d'un domaine et n'utilisant pas IPSec. Il existe deux
types d'exemptions. Nous avons, d'une part, les ordinateurs qui utilisent une adresse IP statique dont les adresses sont incluses dans la « liste d'exemptions », de sorte que les hôtes approuvés n'utilisent pas IPSec avec ces ordinateurs. Et d'autre part, nous avons les ordinateurs exemptés d'utiliser la stratégie IPSec pour négocier des connexions sécurisées. Cette dernière catégorie peut apparaître ou non dans la liste d'exemptions. Une exemption peut répondre aux exigences d'un hôte approuvé, mais n'utilise pas la protection IPSec pour communiquer avec les autres hôtes approuvés du domaine d'isolation.
Termes relatifs à la sécurité 33
Assurezvous de bien comprendre les termes suivants :
• Autorisation. Il s'agit d'une autorisation accordée à une personne, un ordinateur, un processus ou un périphérique pour accéder à des informations, des services ou des fonctionnalités spécifiques. L'autorisation est octroyée selon l'identité de la personne, de l'ordinateur, du processus ou du périphérique demandant l'accès. Cette identité est vérifiée lors de l'authentification.
• Authentification. Il s'agit d'un processus de validation des informations d'identification d'une
personne, d'un processus informatique ou d'un périphérique. Pour être authentifié(e), la personne, le processus ou le périphérique effectuant cette requête doit fournir une représentation des informations permettant de prouver son identité. Les informations d'identification les plus courantes sont les clés privées pour les certificats numériques, un secret configuré par l'administrateur sur deux périphériques (clé prépartagée), un mot de passe secret de connexion de l'utilisateur ou de l'ordinateur au domaine, ou un élément biologique tel qu'une empreinte digitale ou une analyse rétinienne.
• Usurpation. Dans ce guide, l'usurpation désigne l'attaque consistant à usurper l'identité d'une
adresse IP autorisée dans le but d'interrompre les communications ou d'intercepter des données.
• Nonrépudiation. Cette technique est utilisée pour garantir qu'une personne effectuant une action
sur un ordinateur ne peut nier qu'elle a effectué cette action. La nonrépudiation offre la preuve irréfutable qu'un utilisateur ou un périphérique a effectué une action spécifique comme un transfert d'argent, une autorisation d'achat ou l'envoi d'un message.
• Texte chiffré. Il s'agit des données qui ont été chiffrées. Le texte chiffré est le résultat du
processus de chiffrement. Il peut retrouver une forme lisible (en texte clair) grâce à la clé de déchiffrement appropriée.
• Texte clair (ou texte en clair). Il s'agit des communications et des données dans leur format non chiffré.
• Hachage. Il s'agit d'un résultat de taille fixe obtenu en appliquant une fonction mathématique
unidirectionnelle (parfois appelée algorithme de hachage) à un volume arbitraire de données d'entrée. En cas de modification des données d'entrée, le hachage change. Les fonctions de hachage sont choisies de sorte que la probabilité que deux entrées produisent le même résultat de hachage soit extrêmement faible. Le hachage peut être utilisé dans de nombreuses opérations, notamment dans l'authentification et la signature numérique. Il est également appelé « résumé du message ».
Termes relatifs au réseau Les termes suivants font référence aux éléments réseau de cette solution :
• Initiateur. Ordinateur qui initialise la communication réseau avec un autre ordinateur. • Répondeur. Ordinateur qui répond à la demande de communication sur le réseau. • Chemin de communication. Chemin de connexion mis en place pour le trafic réseau qui a lieu entre un initiateur et un répondeur.
Termes relatifs aux stratégies de groupe Les termes suivants sont associés aux stratégies de groupe de Windows :
• GPO (ou objet de stratégie de groupe). Les paramètres de stratégie de groupe que vous créez se trouvent dans un objet de stratégie de groupe (GPO). En associant un GPO aux conteneurs système d'Active Directory sélectionnés (sites, domaines et unités d'organisation (UO)), vous 34
pouvez appliquer les paramètres de stratégie de l'objet de stratégie de groupe aux utilisateurs et ordinateurs présents dans ces conteneurs Active Directory. Pour créer un GPO, utilisez l'Éditeur d'objets de stratégie de groupe, et la console de gestion des stratégies de groupe pour gérer les GPO au sein d'une entreprise.
• Stratégie de domaine. Stratégie stockée de façon centralisée dans Active Directory. • Stratégie locale. Stratégie stockée sur un ordinateur.
Termes élémentaires relatifs à IPSec Assurezvous de bien comprendre les termes suivants :
• Stratégie de sécurité IP. Ensemble des règles de sécurité permettant de traiter le trafic réseau au niveau de la couche IP. Une règle de sécurité contient des filtres de paquets associés aux actions autoriser, bloquer ou négocier. Lorsque la négociation est requise, la stratégie de sécurité IP contient des méthodes d'authentification et de sécurité qui lui permettent de négocier avec l'ordinateur homologue.
• Stratégie de sécurité IP persistante. Type de sécurité IP introduit dans Windows XP et
Windows Server 2003, permettant d'appliquer les paramètres de stratégie IPSec de façon persistante. La stratégie persistante s'applique d'abord au démarrage du service IPSec, afin de pouvoir remplacer les paramètres de la stratégie IPSec locale ou du domaine.
• Négociation IKE. Processus qui a lieu au lancement d'une connexion réseau, pour déterminer si un ordinateur utilisant IPSec autorise la connexion.
• Associations de sécurité. Accords définis entre deux hôtes concernant la façon d'utiliser IPSec pour communiquer et les divers paramètres qui définissent cette négociation.
• Associations de sécurité en mode principal. Ces associations de sécurité sont établies avant les autres lors de la négociation IKE entre l'initiateur et le répondeur.
• Associations de sécurité en mode rapide. Ces associations sont négociées une fois les
associations de sécurité en mode principal établies pour chaque session de communication entre les hôtes.
• Communiquer en texte clair. Cette option permet à un initiateur IKE d'autoriser un trafic TCP/IP
normal (nonIKE ou nonIPSec) si le répondeur ne renvoie pas de réponse IKE. Il s'agit de l'option Autoriser une communication non sécurisée avec un ordinateur qui n'utilise pas IPSec disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie IPSec.
• Relais entrant. Cette option autorise un ordinateur IPSec à accepter un paquet entrant TCP/IP
normal (nonIKE ou nonIPSec) d'un ordinateur distant. La réponse normale du protocole de niveau supérieur est un paquet sortant qui lance une initiation IKE vers l'ordinateur distant. Il s'agit de l'option Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec, disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie IPSec.
Remarque : Si le relais entrant est activé, mais que l'option Communiquer en texte clair n'est pas activée sur un répondeur, celuici ne parviendra pas à communiquer avec un initiateur qui n'utilise pas IPSec. Il est également très important de comprendre les termes spécifiques aux éléments d'IPSec. L'annexe A, « Présentation des concepts relatifs à la stratégie IPSec », de ce guide définit les termes relatifs à IPSec et explique le processus IPSec global que les ordinateurs des groupes d'isolation créés dans cette solution vont utiliser.
35
Comment l'isolation de serveurs et de domaines peutelle être mise en place ? L'idée d'isoler les ordinateurs des risques n'a rien de nouveau. L'utilisation de parefeu pour permettre la segmentation, la mise en place de filtres et de contrôles d'accès au niveau des routeurs et la segmentation physique du trafic réseau font partie des techniques qui fournissent un niveau d'isolation. La solution présentée dans ce guide est conçue pour fonctionner avec les techniques et périphériques existants de votre infrastructure réseau. Pour implémenter l'isolation, il faut apporter des modifications au logiciel hôte existant dans Windows 2000 et sur des platesformes ultérieures. Les technologies et procédures telles que la segmentation réseau, les réseaux locaux virtuels (VLAN), les contrôles d'accès au réseau de périmètre, la mise en quarantaine réseau et la détection d'intrusions dans le périmètre du réseau peuvent être mises en place en implémentant ou en modifiant la configuration des périphériques réseau. L'isolation de serveurs et de domaines complète l'ensemble de ces techniques existantes et offre un niveau de protection supplémentaire pour les membres du domaine Windows gérés. Les administrateurs du système informatique Windows peuvent implémenter l'isolation de serveurs et de domaines en ne modifiant que très peu, voire pas du tout, les méthodes de connexion et chemins d'accès existants, les applications, et avec une infrastructure de domaine Windows 2000 ou Windows Server 2003 existante.
Composants de l'isolation de serveurs et de domaines L'isolation de serveurs et de domaines intègre des composants importants qui, ensemble, constituent la solution. Les soussections ciaprès présentent ces composants. Hôtes approuvés Les hôtes approuvés sont des ordinateurs que l'organisation informatique peut gérer pour répondre aux exigences minimales de sécurité. En général, vous pouvez obtenir le statut « approuvé » uniquement si l'ordinateur exécute un système d'exploitation fiable et géré, un antivirus et les mises à jour les plus récentes des applications et du système d'exploitation. Une fois l'ordinateur identifié comme « approuvé », le composant suivant de la solution est chargé de confirmer le statut de l'ordinateur, via l'authentification. Pour plus d'informations sur l'identification de l'état, reportezvous au chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique ». Remarque : IPSec n'est pas capable de déterminer si un ordinateur est conforme aux critères d'un hôte donné. Une technologie de surveillance est requise pour déterminer la configuration élémentaire d'un ordinateur et signaler toute modification de cette configuration. Authentification de l'hôte Le mécanisme d'authentification de l'hôte permet de déterminer si l'ordinateur qui tente de lancer une session possède des informations d'authentification valides, telles que les informations d'identification du ticket Kerberos, un certificat ou une clé prépartagée. À l'heure actuelle, deux technologies permettent de réaliser ce type d'authentification pour les ordinateurs Windows. Les sections ciaprès présentent ces deux technologies. Le protocole 802.1X Le protocole 802.1X est un protocole d'authentification des utilisateurs et des périphériques basé sur des standards. Il autorise ou non la connexion via un port réseau de couche de liaison, tel qu'une
36
connexion sans fil 802.11ou un port Ethernet 802.3. Il permet de contrôler les opérations des utilisateurs (à des fins de facturation), les autorisations et d'autres fonctions. Ce protocole requiert un ou plusieurs serveurs dédiés, par exemple, le service RADIUS (Remote Authentication DialIn User Service), et une infrastructure réseau qui prend en charge le protocole. Le protocole 802.1X est conçu pour permettre de contrôler l'accès réseau et les clés de chiffrement pour le chiffrement WEP (Wired Equivalent Privacy) 802.11 du trafic sans fil entre le client et le point d'accès sans fil. Lorsque le périphérique est autorisé à accéder au réseau, il bénéficie en général d'un accès à l'ensemble du réseau interne. Les données sont déchiffrées au point d'accès sans fil, puis transférées au format TCP/IP normal en texte clair vers leur destination, susceptible d'être sécurisée par divers mécanismes de couche application. La sécurité de la Woodgrove Bank requiert la protection de tous les hôtes approuvés contre les ordinateurs non approuvés du réseau interne. Le protocole 802.1X pourrait imposer que seuls les ordinateurs approuvés bénéficient d'un accès via une connexion sans fil ou filaire, mais les commutateurs utilisés pour la plupart des ports Ethernet 802.3 internes ne peuvent pas effectuer l'authentification 802.1X. Un coût non négligeable d'achat matériel et d'installation aurait pu être requis pour mettre à niveau toutes les prises LAN murales physiques et tous les bureaux répartis dans les différents pays. La Woodgrove Bank a décidé d'utiliser le protocole 802.1X pour la sécurité sans fil, mais pas pour les ports Ethernet câblés. Une des autres exigences de sécurité de la Woodgrove Bank consistait à chiffrer le trafic de bout en bout entre les clients approuvés et les serveurs de chiffrement. Le protocole 802.1X n'a pas été mis au point pour permettre le chiffrement des connexions câblées, mais uniquement celui des connexions sans fil. Même lorsque les connexions sans fil sont chiffrées, les données ne sont pas protégées lorsque les paquets sont transférés sur le réseau local interne, après avoir été déchiffrés par le point d'accès sans fil. Par conséquent le protocole 802.1X ne permet pas de répondre à l'exigence de chiffrement de bout en bout. Bien que le protocole 802.1X ne permette pas de répondre à l'ensemble des exigences de la Woodgrove Bank, il est toutefois utilisé pour la sécurité sans fil. Microsoft recommande d'utiliser le protocole 802.1X pour sécuriser les réseaux sans fil et permettre, lorsque cela est possible, un contrôle d'accès pour les réseaux filaires. Pour plus d'informations sur l'utilisation du protocole 802.1X, reportezvous à la page WiFi du site Web de Microsoft, à l'adresse http://www.microsoft.com/wifi. IPSec IPSec est le protocole de sécurité standard de l'IETF (Internet Engineering Task Force) pour le protocole IP. Il s'agit d'un mécanisme général de sécurité de couche IP basé sur des stratégies. Il convient parfaitement pour l'authentification hôte par hôte. Une stratégie IPSec possède des règles et paramètres de sécurité qui contrôlent sur un hôte le flux du trafic IP entrant et sortant. La stratégie peut être gérée de façon centralisée dans Active Directory en utilisant des objets de stratégie de groupe (GPO) pour l'attribution des stratégies aux membres du domaine. IPSec permet d'établir des communications sécurisées entre les hôtes. IPSec utilise le protocole de négociation IKE (Internet Key Exchange) pour négocier entre deux hôtes des options relatives à la communication sécurisée à l'aide d'IPSec. Les accords définis entre deux hôtes concernent la façon d'utiliser IPSec pour communiquer, et les divers paramètres qui définissent cette négociation constituent des associations de sécurité. La négociation IKE établit une association de sécurité en mode principal (également appelée association de sécurité ISAKMP) et une paire d'associations de sécurité en mode rapide (également appelées associations de sécurité IPSec), l'une pour le trafic entrant et l'autre pour le trafic sortant. IKE requiert une authentification mutuelle pour établir l'association de sécurité en mode principal. Windows IKE peut utiliser l'une des trois méthodes suivantes :
• protocole d'authentification Kerberos version 5 ;
37
• un certificat numérique X.509 avec la paire de clés RSA (Rivest, Shamir et Adleman) publique et privée correspondante ;
• une clé prépartagée (une phrase de passe, pas véritablement un mot de passe). Bon nombre de personnes ne souhaitent pas déployer IPSec car elles estiment, à tort, qu'IPSec requiert des certificats d'infrastructure de clés publiques (PKI), souvent difficiles à déployer. Pour éviter d'avoir recours à une infrastructure de clés publiques, Microsoft a intégré l'authentification de domaine (Kerberos) de Windows 2000 dans le protocole de négociation IKE. La négociation Windows IKE peut être configurée pour autoriser les communications avec un ordinateur ne répondant pas à la requête de négociation IKE. Cette caractéristique correspond à Communiquer en texte clair. Elle est d'une grande utilité lors du déploiement d'IPSec. Dans le cadre d'un fonctionnement normal, il est pratique de pouvoir autoriser des hôtes approuvés à communiquer avec des ordinateurs ou périphériques non approuvés, uniquement lorsque l'hôte approuvé lance la requête de connexion. IPSec utilise l'expression association de sécurité logicielle pour désigner une communication qu'IPSec ne peut pas protéger en utilisant les formats d'entête d'authentification (AH) ou d'encapsulation de charge utile de sécurité (ESP). IPSec enregistre cette communication dans le journal de sécurité comme audit de succès avec l'adresse IP de destination, et contrôle l'activité du trafic. Lorsque le trafic cesse après une durée d'inactivité (5 min par défaut) une nouvelle tentative de négociation de sécurité est requise lorsque de nouvelles connexions sortantes sont établies. IPSec ne prend pas en charge le filtrage dynamique du trafic sortant, qu'il s'agisse du trafic dans une association de sécurité AH ou ESP, ou du trafic en texte clair impliqué dans une association de sécurité logicielle. Ainsi, lorsque vous utilisez les modèles de stratégie IPSec présentés dans ce guide pour l'isolation de domaines et de serveurs, l'hôte approuvé peut recevoir des connexions entrantes lancées depuis un ordinateur non approuvé sur n'importe quel port, par le biais de l'association de sécurité logicielle. Ceci constitue une vulnérabilité et par conséquent un point d'attaque potentiel. Mais il existe également un modèle prenant en charge des protocoles qui négocient les ports ouverts pour recevoir des connexions entrantes. Il est possible d'utiliser le filtrage dynamique des connexions sortantes pour compléter la protection IPSec, notamment à l'aide d'un parefeu pour hôte tel que Pare feu Windows. Le trafic réseau bénéficiant de la protection IPSec AH ou ESP sans chiffrement n'est pas considéré comme étant en texte clair car il n'est pas authentifié ni protégé contre l'usurpation et la modification. Comme IPSec encapsule les paquets IP normaux dans un format sécurisé, les paquets n'apparaissent plus comme des paquets TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) lorsqu'ils transitent sur le réseau. La tentative de déploiement d'IPSec dans le cas de la Woodgrove Bank a montré que la plupart des outils de gestion réseau considéraient que les applications pouvaient être directement identifiées par leur numéro de port TCP ou UDP (par exemple, le port 25 pour le trafic de la messagerie électronique et le port 80 pour le trafic Web). Lorsque vous utilisez IPSec, le trafic devient plus complexe et les routeurs et le système de détection des intrusions réseau ne parviennent ni à identifier les applications en cours d'utilisation ni à inspecter les données du paquet. Ce facteur crée un problème de gestion réseau, car il déprécie la valeur des outils actuellement utilisés pour surveiller le trafic, filtrer la sécurité, mettre en file d'attente de façon juste et pondérée, et classer la qualité des services. Malheureusement, cette hypothèse sur la visibilité du trafic n'est pas tout à fait juste et devient même rapidement obsolète, même sans utiliser IPSec. La relation entre les numéros de port et les applications est de plus en plus fine. Il est par exemple possible d'exécuter un serveur Web sur un numéro de port arbitraire et d'indiquer le numéro de port dans l'URL du site. Il est également possible de contourner les efforts de filtrage de messagerie électronique entrepris par certains fournisseurs d'accès Internet (FAI), en exécutant un service de messagerie sur un numéro de port différent. Un grand nombre d'applications homologueàhomologue (P2P) sont astucieuses dans la gestion des ports. Elles choisissent en réalité des numéros de port au hasard pour éviter d'être détectées. Les
38
applications basées sur les services d'appel de procédure distante (RPC) sont également habiles dans la gestion des ports. En effet, les services RPC choisissent au hasard des numéros de port éphémères (supérieurs à 1024) pour différents services. L'utilisation croissante de services Web va très probablement accélérer les problèmes d'identification du trafic, car le trafic pour ces services s'exécute audessus du protocole HTTP ou HTTPS, via le port 80 ou 443. Les clients et les serveurs utilisent ensuite l'URL HTTP pour identifier le trafic. Toutes les applications déplacées vers une architecture de services Web apparaissent comme un flux de données indifférencié unique pour les routeurs, car le trafic de ces services Web est exécuté sur un seul port ou sur un petit nombre de ports. Chaque application ou service n'est pas exécuté sur un numéro de port distinct. L'utilisation de SSL et de TLS pour les connexions HTTPS et le chiffrement RPC déprécie la valeur de l'inspection du réseau en tant que dispositif de défense contre les attaques. Comme les applications de gestion réseau étaient toujours capables d'analyser les adresses des paquets et qu'elles bénéficiaient d'une visibilité suffisante pour tous les autres trafics non protégés par IPSec, la Woodgrove Bank a décidé que la perte de certaines fonctionnalités de gestion réseau n'était pas suffisamment significative pour modifier les plans de ce projet. En outre, certains fournisseurs d'outils de gestion réseau souhaitaient modifier leurs outils pour analyser les formes non chiffrées de paquets IPSec. La plupart des applications basées sur l'hôte n'ont pas besoin d'être modifiées pour fonctionner correctement alors qu'IPSec sécurise l'ensemble du trafic entre les adresses IP. L'objectif de cette solution n'est pas d'utiliser IPSec uniquement pour des applications ou des protocoles spécifiques, car il existe des risques d'attaque réseau sur d'autres services réseau. Si des applications ne fonctionnent pas correctement avec IPSec, l'administrateur a la possibilité d'autoriser ce trafic sans la protection IPSec et en fonction des adresses IP utilisées pour les serveurs. Il n'est pas recommandé d'autoriser des applications en fonction d'un port connu car cela ouvre une brèche d'entrée statique aux personnes malveillantes qui peuvent ainsi établir des connexions entrantes sur n'importe quel port ouvert, annihilant de ce fait l'objectif de l'isolation. Les applications qui utilisent des ports alloués dynamiquement ne peuvent pas être autorisées sans protection IPSec. Les applications qui utilisent l'adressage IP de multidiffusion et de diffusion risquent de rencontrer des problèmes avec IPSec dans le cadre de l'isolation de serveurs et de domaines. Windows IPSec peut autoriser tout le trafic de multidiffusion et de diffusion, à l'exception de certains types. Si vous rencontrez des problèmes de compatibilité avec certaines applications, renseignezvous auprès du fournisseur de l'application concernée pour savoir si un correctif ou une mise à niveau est disponible pour résoudre ce problème. Si l'application ne peut pas être mise à jour ou remplacée par une application qui serait compatible, les ordinateurs qui doivent utiliser cette application risquent de ne pas pouvoir être intégrés dans l'isolation de domaines ou de groupes. Outre ses fonctionnalités d'authentification, IPSec offre également deux autres services très utiles de communication hôte : la vérification de l'intégrité des adresses et le chiffrement du trafic réseau.
• Vérification de l'intégrité des adresses. IPSec peut utiliser des entêtes d'authentification (AH)
pour assurer l'intégrité des données et des adresses pour chaque paquet. Les AH de Windows utilisent un mécanisme de hachage avec clé dans le pilote Windows IPSec. L'utilisation des AH permet d'éviter que des attaques par relecture ne se produisent, et elle offre une intégrité renforcée en confirmant qu'aucun des paquets reçus n'a été modifié, de l'envoi à la réception effective. Un AH ne fonctionnera pas correctement s'il passe par un périphérique qui effectue une traduction d'adresses réseau (NAT), car la technologie NAT remplace l'adresse source dans l'entête IP, violant ainsi la sécurité mise en place par IPSec AH.
• Chiffrement du trafic réseau. IPSec assure la confidentialité et l'intégrité des données grâce au
chiffrement, en utilisant l'option d'encapsulation de charge utile de sécurité (ESP) pour le protocole IP. Bien que l'ESP n'assure pas l'intégrité des adresses (sauf lorsqu'elle est utilisée avec les AH), il est possible de faire en sorte qu'elle traverse avec succès un périphérique NAT en utilisant une encapsulation UDP. Si les réseaux internes sont segmentés avec des périphériques qui utilisent NAT, l'ESP est le choix logique qui s'impose car l'encapsulation de charge utile de sécurité 39
n'impose pas le chiffrement des paquets. Windows IPSec prend en charge RFC 2410, qui définit l'utilisation de l'ESP avec chiffrement nul (ESP/null). ESP/null permet d'assurer l'authentification, l'intégrité et l'antirelecture des données, sans requérir de chiffrement. Le Moniteur réseau de Windows Server 2003 est capable d'analyser une ESP non chiffrée pour exposer les protocoles de niveau supérieur TCP/IP normaux. Si le chiffrement ESP est utilisé, la surveillance des paquets n'est possible que si l'ordinateur utilise une carte réseau d'accélération matérielle IPSec, qui déchiffre d'abord les paquets entrants. Remarque : l'ESP avec chiffrement ou utilisant le chiffrement null permet des relations poste à poste IPSec renforcées avec authentification, tout comme les entêtes d'authentification. Elle offre également une protection contre les relectures et peut traverser correctement un périphérique NAT. Pour ces raisons, la Woodgrove Bank a choisi de ne pas implémenter d'entête d'authentification. Elle utilise uniquement ESP/null et ESP avec chiffrement sur son réseau d'entreprise. IPSec peut fonctionner dans les deux modes suivants : le mode de tunnel et le mode de transport :
• Mode de transport IPSec. Le mode de transport IPSec est l'option recommandée pour sécuriser
le trafic entre des hôtes de bout en bout. Le pilote IPSec ajoute simplement un entête IPSec après l'entête IP d'origine. L'entête IP d'origine est conservé et les paquets restants sont sécurisés via un processus de chiffrement AH ou ESP. Les filtres IPSec contrôlent le trafic bloqué, autorisé ou encapsulé par IPSec. Les filtres IPSec spécifient les adresses IP (ou sousréseaux) source et destination, le protocole (ICMP ou TCP, par exemple) et les ports source et de destination. Les filtres peuvent donc s'appliquer spécifiquement à un ordinateur ou à tous les protocoles et adresses de destination possibles. Le mode de transport avait été conçu pour les adresses IP dynamiques, en mettant à jour automatiquement les filtres configurés avec « Mon adresse IP ». Il est moins surchargé et, dans l'ensemble, plus simple à utiliser que le mode de tunnel IPSec. Le mode de transport de négociation IKE constitue un moyen efficace d'autorisatio n des co nnexions entrantes protégées par IPSec. Les problèmes liés à l'utilisation du mode de transport IPSec sont les suivants : • Délai initial. Il doit s'écouler de une à deux secondes avant qu'IKE ne puisse lancer et réaliser une négociation complète réussie. Alors que la communication est en cours, IKE tente d'actualiser les clés de chiffrement qui protègent automatiquement le trafic. • Ordre de priorité prédéfini des filtres. Les filtres de stratégie IPSec peuvent se chevaucher et ainsi suivre un ordre de priorité prédéfini, le plus spécifique en premier. Pour cela, les deux parties en communication doivent posséder, pour la négociation IKE, un ensemble de filtres de mode de transport IPSec compatibles. Par exemple, cette solution utilise un filtre plus général pour « tout le trafic » qui négocie la sécurité IPSec et un filtre plus spécifique pour autoriser uniquement le trafic ICMP plutôt que de sécuriser ce trafic avec IPSec. • Consommation importante de puissance de calcul. Le chiffrement du mode de transport ESP IPSec peut consommer énormément de puissance de calcul. La copie d'un fichier chiffré peut nécessiter l'utilisation de 80 à 100 % des ressources de processeur. Windows 2000, Windows XP et Windows Server 2003 possèdent des interfaces de cartes réseau qui permettent d'accélérer au niveau matériel les opérations de chiffrement IPSec.
• Mode de tunnel IPSec. Le mode de tunnel IPSec est en général utilisé pour les tunnels VPN de
passerelle à passerelle entre des adresses IP statiques de passerelles VPN. Le mode de tunnel crée un nouvel entête IP avec un entête IPSec. Le paquet d'origine doté de l'entête IP d'origine est encapsulé intégralement pour former un paquet tunnel. Dans les scénarios de l'isolation de serveurs et de domaines, le mode de tunnel peut être utilisé pour sécuriser le trafic d'un serveur IP statique vers un routeur prenant en charge IPSec. Cela peut même s'avérer nécessaire si l'hôte de destination ne prend pas en charge IPSec. La Woodgrove Bank n'a pas utilisé de scénario nécessitant l'utilisation du mode de tunnel.
40
Pour plus d'informations techniques sur le mode de transport et le mode de tunnel dans IPSec, reportezvous à la section « Determining Your IPSec Needs » (Détermination de vos besoins IPSec) du chapitre « Deploying IPSec » (Déploiement d'IPSec) dans la partie « Deploying Network Services » (Déploiement de services réseau) du Kit de déploiement de Windows Server 2003, à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/ enus/dnsbj_ips_wclw.asp. Autorisation de l'hôte Lorsque l'hôte a déterminé que la communication qu'il reçoit provient d'une source vérifiable, il doit déterminer s'il doit ou non autoriser l'accès à l'ordinateur source et à l'utilisateur. Cela est très important car ce n'est pas parce qu'un périphérique peut être authentifié qu'il sera pour autant autorisé à accéder à un hôte donné. L'approche que recommande Microsoft consiste à utiliser des groupes Windows standards afin de limiter les possibilités d'accès des utilisateurs et des ordinateurs aux ressources des autres ordinateurs de l'organisation. Cette méthode crée une nouvelle couche d'autorisation pour les comptes ordinateur et utilisateur au niveau de la couche réseau et application en utilisant les autorisations des attributions des droits de l'utilisateur de la stratégie locale sur l'hôte auquel l'accès doit être accordé. En utilisant les attributions des droits de l'utilisateur « Accéder à cet ordinateur à partir du réseau » (AUTORISER) et « Interdire l'accès à cet ordinateur à partir du réseau » (REFUSER), il est possible de restreindre l'accès d'un ordinateur ou d'un utilisateur à une ressource, même s'ils partagent des paramètres de stratégie IPSec communs et si l'utilisateur connecté possède le droit d'accéder à la ressource. Ce niveau de contrôle supplémentaire est fondamental dans l'approche de l'isolation présentée dans cette solution. Les privilèges des groupes d'Active Directory classent les ordinateurs et les utilisateurs de telle sorte qu'il est possible d'assigner les niveaux d'autorisation requis de façon simple et évolutive. Pour faciliter la distinction entre les groupes créés spécifiquement pour obtenir l'autorisation d'accès à l'hôte et les groupes bénéficiant d'autorisations d'accès standard au partage, ce guide utilise le terme groupes d'accès réseau. La figure suivante illustre les principales étapes du processus global d'autorisation hôte/utilisateur de la solution.
41
Figure 2.2 Processus d'autorisation utilisateur/hôte
Le processus en cinq étapes (détaillées ciaprès) illustré par la figure 2.2 est suivi pour toutes les communications réseau, une fois la solution d'isolation en place.
1. Un utilisateur tente d'accéder à un partage situé sur un serveur départemental. Un utilisateur connecté à l'ordinateur client tente d'accéder à un partage sur un hôte approuvé, dans la solution d'isolation logique. L'ordinateur client tente donc de se connecter à l'hôte approuvé en utilisant le protocole de partage de fichiers (en général, le protocole SMB, via le port de destination TCP 445). Dans le cadre de la solution, une stratégie IPSec est affectée au client. La requête de connexion TCP sortante lance une négociation IKE vers le serveur. Le client IKE obtient un ticket Kerberos lui permettant d'être authentifié par le serveur.
2. Négociation de mode principal IKE. Lorsque le serveur reçoit la requête de communication IKE initiale émise par l'ordinateur client, il procède à l'authentification du ticket Kerberos. Pendant le processus d'authentification, IKE vérifie que l'ordinateur client possède les droits d'accès à l'hôte requis, qui doivent être conformes aux droits d'utilisateurs AUTORISER ou REFUSER de la stratégie de groupe. Si l'ordinateur client possède l'attribution des droits utilisateur requise, la négociation IKE se termine et une association de sécurité en mode principal IPSec est établie.
3. Négociation de la méthode de sécurité IPSec. Une fois la négociation de l'association de sécurité en mode principal IKE terminée, les méthodes de sécurité de la stratégie IPSec sont vérifiées afin de négocier une connexion en utilisant les méthodes de sécurité des associations de sécurité IPSec acceptables par les deux hôtes. L'organigramme suivant illustre le processus complet de l'étape 2 à l'étape 3 :
42
Figure 2.3 Processus de vérification des autorisations d'accès à l'hôte de l'ordinateur
4. Vérifications des autorisations d'accès à l'hôte de l'utilisateur. Une fois la communication protégée par IPSec établie, le protocole SMB procède à l'authentification en utilisant le compte utilisateur du client. Sur le serveur, le compte utilisateur est analysé pour vérifier qu'il bénéficie bien des autorisations d'accès à l'hôte requises, qui doivent être conformes aux droits d'utilisateurs AUTORISER et REFUSER de la stratégie de groupe pour l'hôte approuvé. Le diagramme suivant illustre ce processus :
43
Figure 2.4 Processus de vérification des autorisations d'accès à l'hôte de l'utilisateur.
Si le compte d'utilisateur bénéficie de l'attribution des droits utilisateur requise, le processus se termine et le jeton de connexion utilisateur est créé. Une fois ce processus terminé, les vérifications de sécurité de la solution d'isolation logique sont terminées.
5. Vérifications des autorisations d'accès aux fichiers et au partage. Enfin, le serveur vérifie les autorisations d'accès aux fichiers et au partage Windows standard pour contrôler que l'utilisateur est membre d'un groupe bénéficiant des autorisations requises pour accéder aux données demandées par l'utilisateur. L'utilisation de groupes d'accès réseau permet de bénéficier d'un niveau de contrôle très élevé dans la solution. Le scénario suivant donne un exemple pratique des étapes de la solution d'isolation logique : Au cours d'une réunion, une soustraitante connecte son ordinateur portable à un point de connexion d'une salle de réunion, pour copier des données sur un partage situé sur le serveur RH d'un employé. Dominique, membre du service des RH, indique au soustraitant le chemin d'accès au partage du serveur RH. Comme l'ordinateur portable du soustraitant n'est pas un hôte connu ou approuvé, le service informatique ne gère pas l'ordinateur et le niveau de sécurité mis en place dans l'ordinateur portable n'est pas connu. Par conséquent, il est possible que les fichiers contiennent un logiciel malveillant susceptible d'infecter les ordinateurs internes. Lorsque l'ordinateur du soustraitant tente de se connecter au serveur RH, les ordinateurs échouent à l'étape 2 du processus. Les ordinateurs ne peuvent pas négocier une association de sécurité en mode principal IKE car l'ordinateur portable n'est pas en mesure de fournir le ticket Kerberos requis pour permettre la vérification des informations d'identification de l'ordinateur. L'ordinateur portable n'appartient pas à un domaine approuvé. Les exigences de la stratégie IPSec du groupe d'isolation auquel appartient le serveur RH n'autorisent pas le serveur à communiquer avec un hôte qui n'utilise pas IPSec. Par conséquent, toutes les tentatives
44
de communication émises par cet ordinateur non approuvé sont bloquées. En résumé, la solution d'isolation logique aide à protéger l'infrastructure informatique des menaces que peuvent représenter des ordinateurs non approuvés et non gérés, même lorsque ceuxci bénéficient d'un accès physique au réseau interne. Cet exemple explique comment implémenter l'isolation selon une approche hôte par hôte. La proposition d'une isolation à des coûts administratifs réduits fait également partie des exigences importantes de la solution. Il est possible de regrouper des ordinateurs, tout comme cela est possible pour les utilisateurs, puis d'attribuer à ces groupes les droits d'utilisateur AUTORISER ou REFUSER dans toutes les stratégies locales des ordinateurs. Cette approche est toutefois difficile à gérer et n'évolue pas correctement sans utiliser la fonction de centralisation de la stratégie de groupe et d'Active Directory, et sans une compréhension solide des chemins de communication requis. En outre, cette approche seule ne permet pas de réaliser une authentification fiable ou de chiffrer les données. Lorsque ces autorisations d'accès à l'hôte sont associées à IPSec et que les hôtes sont organisés dans des groupes d'isolation, les relations entre les groupes sont plus claires et les chemins de communication, plus faciles à définir (une fois les exigences clairement répertoriées). Pour plus d'informations sur la configuration et la structure des groupes d'isolation, reportezvous au chapitre 4, « Conception et planification de groupes d'isolation ».
De quoi nous protège l'isolation de serveurs et domaines ? L'isolation de serveurs et de domaines consiste à mettre en place des limites de communication entre des ordinateurs et d'autres ordinateurs ou périphériques tentant d'établir les communications. Ces limites ou frontières permettent de limiter les communications en définissant le niveau auquel un périphérique est considéré comme approuvé. La mise en place de limites comme l'authentification, l'autorisation et l'emplacement réseau autour d'un hôte en utilisant une stratégie IPSec est un excellent moyen de réduire bon nombre de menaces. IPSec ne constitue pas une stratégie de sécurité complète mais ajoute une couche de protection supplémentaire dans une stratégie de sécurité globale. La section suivante présente des menaces types et évoque brièvement la modélisation des menaces. Pour plus d'informations sur les périphériques approuvés dans le scénario de Woodgrove Bank et sur le processus de conception utilisé par la Woodgrove Bank pour identifier et classer les ordinateurs comme dignes de confiance, reportezvous à la section « Définition de l'approbation » du chapitre 3 « Détermination de l'état actuel de votre infrastructure informatique ».
Modélisation et classification des menaces Ces dernières années, les attaques ciblant les applications et serveurs réseau sont devenues de plus en plus fréquentes et complexes. Ce qui est intéressant, c'est que les styles et types d'attaque ainsi que les méthodes élémentaires permettant de les déjouer n'ont pas véritablement évolué. Certaines fonctions et méthodes d'implémentation de ces défenses sont toutefois différentes. Pour être en mesure de déterminer la planification que requiert une solution d'isolation de serveurs et de domaines, votre organisation doit d'abord entreprendre une analyse détaillée des risques de menace présents et comprendre comment déjouer ces risques en faisant appel à plusieurs technologies et processus. Les processus permettant d'identifier, de classer et de répertorier les menaces encourues par une organisation sont à l'heure actuelle bien connus. Cette documentation présente une méthodologie pouvant être utilisée pour la modélisation des menaces commerciales, environnementales et techniques communes auxquelles doivent faire face les organisations. Pour la modélisation de la menace, Microsoft utilise la méthode STRIDE. STRIDE représente les catégories de menace contre lesquelles se protéger. Ces catégories sont les suivantes :
45
S usurpation T falsification R répudiation I divulgation d'informations D refus de service E élévation de privilèges Il est primordial de consacrer le temps et les ressources nécessaires à la définition, la plus précise possible, d'un modèle de menace, pour assurer la protection de toutes les ressources à protéger. Pour obtenir plus d'informations sur les menaces et attaques spécifiques que l'isolation de serveurs et de domaines aide à limiter, reportezvous à l'annexe D, « Catégories de menaces informatiques », de ce guide. Pour une présentation détaillée des modèles de menace, reportezvous au chapitre 2, « Defining the Security Landscape » (Définition du paysage de sécurité), de la solution Microsoft Solution for Securing Windows 2000 Server pouvant être téléchargée à l'adresse suivante : www.microsoft.com/technet/security/prodtech/ win2000/secwin2k/02defsls.mspx.
Comment déployer l'isolation de serveurs et de domaines ? Lorsque vous avez pris connaissance des menaces auxquelles doit faire face votre organisation et que vous avez compris comment la solution permet de réduire ces risques, étudiez un déploiement possible de la solution. Cette section décrit le processus de déploiement.
Collecte d'informations Avant même de commencer le processus de conception, vérifiez que vous disposez d'une représentation à jour et précise de l'état actuel du réseau de votre organisation, notamment des configurations des stations de travail et serveurs, et des chemins de communication. Il est impossible de développer une solution d'isolation logique efficace sans connaître de façon précise les éléments que la solution doit protéger. Le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », décrit de façon détaillée les moyens qui vous permettent d'obtenir des informations sur l'état actuel de votre réseau et sur les périphériques qui y sont connectés. Ce processus fournit toutes les informations requises dans les chapitres suivants de cette solution et offre un grand intérêt pour les autres projets entrepris dans l'organisation. Ce processus permet avant tout à l'organisation d'analyser et d'examiner avec soin les chemins de communication requis pour ses systèmes d'information et d'effectuer des choix judicieux quant aux compromis éventuels sur les risques, les exigences de communication et les exigences de l'entreprise.
Présentation du processus de déploiement d'IPSec Lorsque vous avez choisi et créé une conception, vous devez mettre en place un processus d'implémentation de cette conception dans l'organisation, de sorte que l'implémentation soit gérable et qu'elle ait peu de répercutions sur les utilisateurs. Le chapitre 4, « Conception et planification de
46
groupes d'isolation », présente de façon détaillée plusieurs approches dont vous pouvez vous inspirer. Le processus élémentaire peut être résumé comme suit : Tester la conception et les stratégies IPSec dans un laboratoire de validation technique. Testez les stratégies IPSec envisagées dans un environnement hors production, isolé, pour vous assurer que la conception fonctionne comme prévu et pour tester les problèmes susceptibles de survenir dans les paramètres de la stratégie ou dans les mécanismes de déploiement.
1. Expérimenter la configuration testée et approuvée. Lorsque l'équipe est convaincue que la conception fonctionne comme prévu dans l'environnement du laboratoire, l'étape suivante du processus consiste à identifier dans un environnement de production un petit nombre d'ordinateurs à inclure dans un déploiement expérimental de la solution. Pour s'assurer que les problèmes susceptibles de survenir pendant le test auront le moins d'impact possible sur l'activité des utilisateurs, un support préventif doit être dispensé aux ordinateurs et aux utilisateurs identifiés.
2. Implémenter un déploiement progressif de la solution. La dernière étape du processus consiste à planifier le déploiement de la conception pour l'ensemble de l'organisation. Ce processus est très important ! Vous devez être extrêmement prudent lorsque vous planifiez cette étape. Il est possible de mettre en œuvre (après la simple modification d'un paramètre de la stratégie IPSec) une conception qui peut priver bon nombre d'ordinateurs de l'accès aux ressources réseau. Testez et organisez votre plan de déploiement pour que les modifications introduites par la solution soient implémentées de sorte qu'il soit possible de retrouver rapidement un état de fonctionnement satisfaisant, au cas où une erreur de conception ou de configuration n'aurait pas été détectée lors de la phase de test. Le chapitre 4, « Conception et planification de groupes d'isolation », donne des informations détaillées sur le processus de conception de domaines d'isolation et présente des options de déploiement progressif de la solution.
Résumé Ce chapitre décrit les objectifs et les processus de la solution présentée dans ce guide. Depuis de nombreuses années déjà, les professionnels de l'informatique ont compris les avantages d'IPSec, toutefois, en raison de la nature complexe de cette technologie, rares en sont les implémentations. L'implémentation d'IPSec peut entraîner de graves problèmes si la solution ne bénéficie pas d'une conception solide, d'un déploiement parfaitement planifié et d'une méthodologie de test fiable. Les informations présentées dans ce chapitre montrent que l'isolation logique est une couche de sécurité supplémentaire qui exploite les techniques d'isolation de serveurs et de domaines, et les fonctions de la plateforme Windows, d'IPSec, des stratégies de groupe et d'Active Directory pour constituer une solution d'entreprise gérable et évolutive, capable de réduire les risques auxquels sont exposées les données. Les informations présentées dans les chapitres suivants mettent l'accent sur les étapes requises pour la planification et l'implémentation de la solution. Le chapitre 6, « Gestion d'un environnement d'isolation de serveurs et de domaines », présente des procédures à implémenter dans le cadre du fonctionnement quotidien d'un environnement d'exploitation utilisant l'isolation de serveurs et de domaines. Le chapitre 7, « Dépannage d'IPSec », contient des informations relatives à la prise en charge et au dépannage d'IPSec.
47
Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique Ce chapitre explique comment obtenir les informations nécessaires à la planification et au déploiement d'une solution d'isolation de serveurs et de domaines. Un déploiement réussi exige une connaissance à jour et précise de votre infrastructure informatique. Après avoir lu le présent chapitre, vous serez parfaitement au fait des informations nécessaires à la mise en place d'une solution d'isolation de serveurs et de domaines. La dernière partie du chapitre explique comment maîtriser et documenter les ordinateurs identifiés et susceptibles de fonctionner comme ordinateurs « approuvés » au sein de la solution. Ces informations seront utiles à l'équipe chargée de la mise en place de la solution au moment de planifier cette dernière.
Connaissances préalables requises pour ce chapitre Avant d'exploiter les informations contenues dans ce chapitre, assurezvous que vous et votre organisation respectez les exigences suivantes. Les instructions fournies dans ce chapitre sont spécifiquement adaptées aux besoins d'une organisation répondant de manière stricte à ces exigences. L'absence de conformité à l'ensemble des conditions requises n'a pas nécessairement un impact négatif sur votre projet mais en respectant ces exigences, vous donnerez d'autant plus de valeur aux instructions qui vous sont fournies.
Connaissances requises Vous devez être familiarisé avec les concepts liés à IPSec et disposer de connaissances solides dans les domaines suivants :
• Authentification Microsoft® Windows® (plus précisément, le protocole d'authentification Kerberos version 5)
• Concepts relatifs au service d'annuaire Active Directory® (notamment les outils et la structure
Active Directory), la manipulation d'utilisateurs, de groupes et d'autres objets Active Directory et enfin l'utilisation de la stratégie de groupe
• Sécurité du système Windows, notamment les concepts de sécurité, tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès
• Conventions système d'attribution de noms de l'organisation • Emplacements physiques et logiques de l'organisation • Méthodes de gestion des risques adoptées dans l'organisation • Concepts réseau clés, notamment le filtrage de port à l'aide de parefeu Avant de poursuivre la lecture de ce chapitre, lisez également les chapitres précédents de ce guide pour bien comprendre les concepts de la solution proposée en termes d'architecture et de conception.
48
Conditions requises pour l'organisation En règle générale, la planification de groupes d'isolation dans une organisation implique plusieurs intervenants aux compétences diverses. Les informations nécessaires à une évaluation rigoureuse des exigences proviennent souvent de diverses sources disséminées dans l'organisation. Vous devez consulter les membres de votre organisation susceptibles de participer au processus de planification de ces groupes, notamment les personnes suivantes :
• les cadres exécutifs ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les propriétaires d'applications, de serveurs Web et de domaines DNS (Domain Name System) ; • le personnel des opérations et d'administration réseau ; • le personnel de formation et d'assistance interne. Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles. Outre les informations recueillies auprès des personnes citées ciavant, un point crucial à retenir est la mise à jour des pratiques opérationnelles actuellement en vigueur avec l'introduction d'IPSec dans l'environnement concerné. Il est possible que des composants logiciels et matériels, notamment le BIOS et les microprogrammes des périphériques réseau, exigent aussi une mise à jour. Enfin, des outils réseau supplémentaires seront peutêtre nécessaires afin de faciliter la prise en charge et le dépannage de l'environnement IPSec.
Configuration requise pour l'infrastructure informatique Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :
• Un domaine Microsoft Windows Server™ 2003 Active Directory fonctionnant en mode mixte ou
natif. Cette solution utilise des groupes universels pour l'application des objets Stratégie de groupe (GPO). Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en us/ipsec_whatsnew.asp.
• Les outils et les compétences requis pour surveiller le réseau, analyser les données de
surveillance et prendre des décisions de planification de capacité sur la base de ces données.
Remarque : l'usage des outils de surveillance réseau est soumis à des restrictions dans de nombreuses organisations. Soyez vigilant et assurezvous que les procédures opérationnelles suivies lors de l'utilisation de ces outils sont les bonnes.
49
• Un outil déjà installé et capable de recueillir des données de configuration réseau sur les hôtes du
réseau. Par exemple, vous pouvez faire appel à des systèmes de gestion des ressources pour collecter ces informations. Pour plus d'informations, consultez la section « Détection d'hôtes » plus loin dans ce chapitre.
À qui s'adresse ce chapitre Ce chapitre s'adresse aux professionnels informatiques chargés de créer l'infrastructure informatique que les architectes et les concepteurs de solutions utiliseront. Ces professionnels sont généralement des membres du personnel du support ou des opérations de l'organisation concernée. Pour tirer le meilleur parti des informations figurant dans ce chapitre, vous devez disposer d'un bon de niveau de connaissance technique des outils et des technologies impliqués dans le processus de recueil des informations ainsi que de l'infrastructure actuelle de l'organisation.
Analyse de l'état actuel Recueillir et tenir à jour des données fiables sur les ordinateurs, les logiciels et les périphériques réseau d'une organisation est un défi informatique classique. La réussite d'un projet dépend des informations relevées au cours de ce processus. Avant d'entamer la planification d'un projet d'isolation de serveurs et de domaines, vous devez recueillir et analyser des données mises à jour sur les ordinateurs, le réseau et les services d'annuaire déjà déployés au sein de l'organisation. Ces données vous permettront de concevoir une solution qui tient compte de tous les éléments possibles de l'infrastructure existante. Si les informations recueillies manquent de précision, des problèmes liés à des périphériques et des ordinateurs non pris en compte au cours de la phase de planification peuvent survenir lors de l'implémentation. Les sections suivantes décrivent les informations requises dans chaque domaine et fournissent des exemples issus des informations recueillies dans le cadre de la solution d'isolation de serveurs et de domaines développée pour la Woodgrove Bank.
Détection réseau L'aspect le plus primordial de la planification d'une solution d'isolation de serveurs et de domaines est l'architecture réseau, puisque le protocole de sécurité IPSec intervient au niveau du protocole Internet (IP). Une maîtrise partielle ou erronée du réseau se traduira par l'échec de toute solution d'isolation. La compréhension de l'agencement des sousréseaux, des schémas d'adressage IP et des modèles de trafic est une condition qui participe à cet effort mais les deux composants suivants sont indispensables pour mener à terme la phase de planification du projet :
• Documentation de la segmentation du réseau • Documentation du modèle de trafic réseau actuel L'objectif recherché est de disposer de suffisamment d'informations pour identifier une ressource en fonction de son emplacement sur le réseau, en plus de son emplacement physique. Il est préférable de débuter avec une architecture réseau soigneusement pensée, dotée de plages d'adresses facilement identifiables et du nombre le plus réduit possible de chevauchements ou de plages discontinues. Il est possible que certains impératifs commerciaux ou circonstances (par exemple, dans le cas de fusions et d'acquisitions) ne permettent pas la mise en place d'un réseau « rationalisé » mais en prenant soin de documenter et de comprendre l'état actuel, vous faciliterez votre travail d'identification du réseau et des ressources qu'il gère. N'utilisez pas un réseau complexe et mal documenté comme point structurel de départ ; il risque de laisser un trop grand nombre de domaines non identifiés susceptibles de causer des problèmes lors de l'implémentation.
50
Ces instructions sont un moyen d'obtenir les informations les plus pertinentes pour la planification d'une solution d'isolation de serveurs et de domaines mais n'ont pas pour vocation de chercher à résoudre d'autres problèmes, notamment les questions de masque de sousréseau de longueur variable et d'adressage TCP/IP, de segmentation de réseau local virtuel (VLAN) ou d'autres méthodes et techniques d'optimisation des réseaux. Les informations obtenues servent à formuler les composants opérationnels et d'implémentation de la solution d'isolation de serveurs et de domaines. Documentation de la segmentation du réseau Si l'architecture actuelle de votre organisation n'est pas documentée et disponible en guise de référence, vous devez vous procurer les documents nécessaires dès que possible avant de poursuivre la mise en œuvre de la solution. Si les informations documentées ne sont pas à jour ou n'ont pas été récemment validées, deux options simples vous sont proposées :
• Accepter le fait que les informations exposent le projet à des risques. • Engager un processus de détection et de découverte, soit manuellement, soit par le biais d'un outil d'analyse réseau capable de fournir les informations nécessaires à la documentation de la topologie réseau actuelle.
Les informations requises peuvent être présentées de différentes façons, mais une série de représentations schématiques s'avère souvent la méthode la plus efficace pour illustrer et expliquer la configuration actuelle du réseau. Lorsque vous créez le schéma d'un réseau, évitez d'y insérer trop d'informations. Si nécessaire, utilisez plusieurs schémas illustrant différents niveaux de détail. Prenons pour exemple le scénario imaginé pour la Woodgrove Bank. Le schéma créé et illustré ci dessous offre une vision détaillée de son réseau étendu et de l'environnement du site :
Figure 3.1 Réseau étendu et architecture du site de la Woodgrove Bank
51
Après avoir développé ce schéma, l'équipe de la Woodgrove Bank a entrepris de créer des schémas détaillés de chaque site, puis de chaque sousréseau à l'intérieur de chaque site. Tout en documentant votre réseau, vous rencontrerez peutêtre des applications et des services réseau incompatibles avec IPSec. Parmi les risques d'incompatibilité actuels figurent les points suivants :
• Sur les routeurs, la technologie Cisco NetFlow ne peut pas analyser les paquets entre des membres IPSec à partir du protocole ou du port.
• La qualité de service (QoS) mise en place sur le routeur ne peut pas utiliser les ports ou les
protocoles pour définir la priorité du trafic. L'utilisation d'adresses IP spécifiques reste néanmoins possible pour la hiérarchisation du trafic. Par exemple, tandis qu'une règle attribuant la priorité de « quiconque à quiconque utilisant le port 80 » ne fonctionnerait pas, une règle définissant une priorité de « quiconque à 10.0.1.10 » ne serait nullement affectée.
• Certains équipements ne prennent pas en charge ou n'autorisent pas le protocole IP 50, le port adopté par le protocole ESP (Encapsulating Security Payload).
• La technique WFQ (Weighted Fair Queuing) et d'autres méthodes de définition de la priorité du trafic sur routeur fondées sur le flux peuvent échouer.
• Les moniteurs réseau peuvent être incapables d'analyser les paquets ESP non chiffrés (ESPNull). Remarque : le Moniteur réseau Microsoft a ajouté un analyseur ESP à la version 2.1 destiné à faciliter la résolution des problèmes liés aux paquets IPSec non chiffrés. L'outil Moniteur réseau est fourni avec Microsoft Systems Management Server (SMS). Pour plus d'informations, consultez la page Microsoft Systems Management Server sur le site www.microsoft.com/smserver/.
• Si le système ne peut pas procéder à une analyse ESP, aucune liste de contrôle d'accès (ACL) spécifiant des règles de port ou de protocole n'est traitée dans les paquets ESP.
• Si le système dispose d'un analyseur ESP et utilise le chiffrement, les listes de contrôle d'accès qui spécifient des règles de port ou de protocole ne sont pas traitées dans les paquets ESP.
IPSec annule la définition des priorités fondées sur le réseau et la gestion du trafic fondée sur les ports et les protocoles lorsque des ports et des protocoles sont utilisés. Il n'existe malheureusement aucune solution alternative pour les paquets chiffrés. Si la gestion du trafic ou la définition des priorités doit être fondée sur les ports ou le protocole, l'hôte luimême doit être en mesure d'assumer ces fonctions de gestion du trafic et de hiérarchisation. Enfin, il est primordial d'enregistrer avec exactitude les informations nécessaires pour les divers périphériques du réseau. Périphériques de l'infrastructure réseau Les périphériques qui composent l'infrastructure réseau (routeurs, commutateurs, équilibreurs de charge et parefeu) communiquent avec IPSec après l'implémentation de la solution. C'est pourquoi il est primordial d'examiner les caractéristiques suivantes des périphériques du réseau pour s'assurer de leur capacité à gérer les exigences techniques et matérielles de la conception :
• Marque/modèle. Vous pouvez utiliser ces informations pour déterminer les fonctionnalités prises en charge par le périphérique. De plus, vérifiez le BIOS ou le logiciel exécuté sur le périphérique pour être certain qu'IPSec est pris en charge.
• Quantité de mémoire vive (RAM). Cette information peut être précieuse lorsque vous souhaitez évaluer la capacité ou l'impact d'IPSec sur le périphérique.
52
• Analyse du trafic. Ces informations (heure d'utilisation maximale et tendances quotidiennes et
hebdomadaires indiquant le taux d'utilisation journalier du périphérique) peuvent toujours s'avérer utiles. En rapport avec IPSec, les informations fournies offrent un aperçu du périphérique et de son utilisation sur une période donnée. Si des problèmes surgissent après l'implémentation d'IPSec, ces mêmes informations peuvent permettre de déterminer si les causes sont liées à une utilisation intensive du périphérique.
• Listes de contrôle d'accès (ACL) affectant directement IPSec. Les listes de contrôle d'accès
ont un impact direct sur la capacité de fonctionnement de certains protocoles. Par exemple, si vous n'autorisez pas le protocole Kerberos (protocole UDP (User Datagram Protocol) et port TCP 88) ou le protocole IP (le protocole, pas le port) 50 ou 51, IPSec ne fonctionnera pas. Les périphériques doivent également être configurés pour permettre la circulation du trafic IKE (UDP 500 et 4500) lorsque vous utilisez la traduction d'adresses réseau NATTraversal (NATT).
• Réseaux/sousréseaux connectés à des interfaces de périphériques. Ces informations vous
permettent d'effectuer la meilleure analyse possible de la structure du réseau interne. La définition des limites du réseau à partir d'une plage d'adresses est une opération simple et permet d'identifier si d'autres adresses sont non gérées ou étrangères au réseau interne (par exemple, les adresses Internet). Ces informations sont nécessaires pour les décisions de stratégies IPSec prises au cours des chapitres suivants du présent guide.
• Le périphérique autorise ou non la traduction d'adresses réseau (NAT). La traduction
d'adresses réseau est fréquemment utilisée pour soumettre une plage d'adresses tout entière en tant qu'adresse IP unique à un réseau connecté ou à Internet. Le planificateur de solutions doit savoir où ce processus intervient sur le réseau.
Remarque : l'article 818043 de la Base de connaissances Microsoft, « Mise à jour NATT pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000 » (http://support.microsoft.com/kb/818043) propose la fonctionnalité NATT en tant que correctif téléchargeable pour Windows XP Service Pack (SP) 1 et Windows 2000 SP4. En revanche, aucun répondeur IPSec ne fonctionnera correctement si vous n'avez pas installé Windows XP SP2 ou Windows Server 2003 SP1.
• Segmentation des réseaux locaux virtuels (VLAN). En déterminant le mode d'implémentation
actuel des réseaux locaux virtuels (VLAN) sur le réseau, vous comprendrez mieux les modèles de trafic ou les exigences de sécurité existantes et pourrez déterminer comment IPSec augmentera ces exigences ou sera potentiellement amené à interférer avec elles.
• Liens de connexion du périphérique. Ces informations vous permettront de détecter les
connexions que le périphérique entretient entre des réseaux spécifiques. Elles peuvent également être utilisées pour identifier le réseau logique et les connexions à divers emplacements d'une interface donnée.
• Taille de l'unité de transmission maximale (MTU) sur les interfaces des périphériques.
L'unité de transmission maximale (MTU) désigne le plus grand datagramme qu'il est possible de transmettre sur une interface donnée sans le diviser en plus petites unités de transmission (processus également appelé « fragmentation »). Dans les communications IPSec, le MTU a pour but de déterminer les zones dans lesquelles la fragmentation aura lieu. Le routeur doit suivre la fragmentation des paquets afin de détecter le protocole ISAKMP (Internet Security Association and Key Management Protocol). IPSec configure la taille MTU de la session selon le MTU minimal détecté dans le chemin de communication utilisé, puis définit le bit DF (Do not Fragment) à 1.
Remarque : si la découverte du PMTU (Path MTU) est activée et fonctionne comme il se doit, vous n'avez pas besoin de recueillir la taille MTU sur les interfaces des périphériques. Certaines sources, notamment le Windows Server 2003 Hardening Guide (Guide de renforcement de la sécurité de Windows Server 2003), recommandent de désactiver la fonction de découverte PMTU. En revanche, cette fonction doit être activée pour permettre à IPSec de fonctionner correctement.
53
Notez également qu'IPSec peut affecter un système IDS (système de détection d'intrusion) puisqu'un analyseur spécifique est nécessaire à l'interprétation des données à l'intérieur des paquets. Si le système IDS n'est pourvu d'aucun analyseur, il ne peut pas examiner les données de ces paquets pour déterminer si une session particulière est une menace potentielle. Dans ce cas, la décision d'utiliser IPSec indique que votre organisation a davantage besoin d'IPSec que du système IDS. Les informations identifiées dans cette section sont essentielles à la réussite du projet puisqu'elles vous permettent de comprendre la configuration actuelle et la santé de l'infrastructure du réseau avant même de configurer l'utilisation d'IPSec sur les périphériques concernés (ou d'y placer une charge supplémentaire s'ils sont déjà configurés pour la circulation du trafic IPSec). Par l'étude des informations relatives aux pics de charge, vous pouvez déterminer si le périphérique est en mesure d'utiliser IPSec dans son état actuel ou s'il exige une mise à niveau de la mémoire ou du microprogramme afin de supporter la charge attendue. Les informations sur la marque et le modèle s'avéreront utiles au moment de vous procurer le matériel de mise à niveau des périphériques (si nécessaire). Les informations sur les paramètres de configuration ou les fonctionnalités propres à cette marque et ce modèle peuvent également vous être utiles. Le nombre de listes de contrôle d'accès configurées sur les périphériques vous aidera à estimer l'effort requis pour configurer les périphériques afin de prendre en charge IPSec. Si aucun périphérique du réseau n'est configuré pour autoriser le trafic IPSec et que le réseau dispose d'un grand nombre de routeurs, la configuration des périphériques risque de représenter une importante charge de travail. Une fois ces informations à votre disposition, vous pouvez rapidement déterminer s'il est nécessaire ou non de mettre à niveau les périphériques afin qu'ils répondent aux exigences du projet, de modifier les listes de contrôle d'accès ou de prendre d'autres mesures pour vous assurer que les périphériques seront capables de gérer les charges qui leur seront confiées. Analyse du modèle de trafic réseau actuel Après avoir recueilli les informations d'adressage et d'infrastructure réseau, l'étape suivante consiste logiquement à examiner avec soin le flux des communications. Par exemple, si un service comme celui des ressources humaines s'étend sur plusieurs bâtiments et si vous souhaitez utiliser IPSec pour chiffrer les informations de ce service, vous devez savoir comment les bâtiments concernés sont connectés pour déterminer le niveau de « confiance » envers la connexion. Un bâtiment hautement sécurisé relié par un câble en cuivre à un autre bâtiment sans protection peut être la proie d'une écoute clandestine ou d'une attaque par relecture de données. Si une attaque de ce type représente une menace, IPSec peut fournir une authentification mutuelle renforcée et le chiffrement du trafic des hôtes approuvés. Néanmoins, la solution ne résout pas le fait qu'un manque de sécurité physique sur les hôtes approuvés constitue toujours une menace. Au moment d'examiner le flux de trafic, regardez de près comment tous les périphériques gérés et non gérés interagissent, y compris les périphériques nonWindows, tels que Linux, UNIX et Mac, ainsi que les versions Windows antérieures à Windows 2000 SP4. Posezvous certaines questions, notamment : certaines communications ontelles lieu au niveau du port ou du protocole ou bien existe til un grand nombre de sessions intervenant entre les mêmes hôtes sur un large éventail de protocoles ? Comment les serveurs et les clients communiquentils ensemble ? Existetil des systèmes de sécurité ou des projets actuellement mis en œuvre ou planifiés susceptibles d'avoir un impact sur le projet d'isolation ? Par exemple, l'utilisation de Windows XP SP2 et du Parefeu Windows pour "verrouiller" certains ports, tels que le port UDP 500, risque de provoquer l'échec de la négociation IKE. Lorsque vous appliquez le processus de modélisation des menaces décrit dans le chapitre 2 (« Présentation de l'isolation de serveurs et de domaines ») afin d'examiner les différents types de trafic réseau, vous pouvez aisément rechercher les protocoles et les applications qui génèrent un trafic devant être protégé contre les périphériques non approuvés ou non gérés. Certains des protocoles et des applications les plus fréquemment rencontrés sont les suivants :
54
• NetBIOS sur TCP/IP (NetBT) et SMB (Server Message Block). Dans un réseau local, on trouve souvent les ports 137, 138 et 139 activés pour NetBT et le port 445 activé pour SMB. En plus d'autres fonctionnalités, ces ports offrent des services de résolution des noms NetBIOS. Malheureusement, ils entraînent aussi la création de sessions NULL. Une session NULL est une session établie sur un hôte qui n'utilise pas le contexte de sécurité d'une entité ou d'un utilisateur connu. Ces sessions sont souvent anonymes.
• Appel de procédure distante (RPC). En règle générale, l'appel de procédure distante opère en
présentant un port d'écoute à une application (également appelé « mappeur de point de terminaison », port TCP 135) qui suggère alors à « l'appelant » (souvent une autre application) d'engager la communication sur un autre port de la plage éphémère. Dans un réseau segmenté par des parefeu, cette communication RPC soulève un véritable défi en termes de configuration puisqu'elle implique d'ouvrir le port d'écoute RPC et tous les ports audessus du port 1024. L'ouverture de tous ces ports augmente la surface exposée aux attaques sur la totalité du réseau et réduit l'efficacité des parefeu. En revanche, l'avantage de l'appel de procédure distante (RPC) est qu'il fournit les fonctionnalités des couches 1 à 4 du modèle OSI (Open Systems Interconnection) pour les applications qui l'utilisent, ce qui évite aux développeurs d'effectuer des appels de bas niveau sur le réseau pour leurs applications distribuées. Du fait que de nombreuses applications dépendent de l'appel de procédure distante (RPC) pour leurs fonctionnalités de base, la stratégie IPSec devra tenir compte du service RPC. Pour plus d'informations sur la création d'une stratégie IPSec, consultez le chapitre 5, « Création de stratégies IPSec pour les groupes d'isolation ».
• Autre trafic. IPSec peut sécuriser les transmissions entre hôtes en authentifiant les paquets en plus de chiffrer les données qu'ils contiennent. L'important est d'identifier ce qui doit être protégé et les risques à minimiser. Tout autre trafic ou type de trafic à sécuriser doit être examiné et modélisé comme il se doit. Il peut, par exemple, s'agir d'une base de données visant un objectif précis et à laquelle seuls quelques clients sont autorisés à accéder, ou bien d'une application spécialisée destinée aux ressources humaines et exclusivement réservée aux cadres de ce service. Après avoir documenté le réseau logique et physique, la prochaine étape consiste à examiner les modèles de trafic actuels et à répondre aux questions suivantes :
• Disposezvous à l'heure actuelle de sousréseaux dédiés à des types spécifiques de trafic (par exemple, des stations de travail Mac et UNIX ou des connexions entre ordinateur central et terminal) ?
• Avezvous besoin de séparer les différents types de trafic ou le trafic d'un emplacement à un autre ?
Active Directory Après le réseau, Active Directory est le deuxième élément clé à partir duquel il vous faudra rassembler des données. Vous devrez comprendre la structure des forêts, notamment l'agencement des domaines, l'architecture des unités d'organisation et la topologie du site. Ces informations permettent de connaître la position actuelle des ordinateurs, leur configuration et l'impact des modifications apportées à Active Directory suite à l'implémentation d'IPSec. La liste cidessous décrit les informations nécessaires à la réalisation de cette étape du processus de découverte.
• Nombre de forêts. Étant donné que la forêt est la limite de sécurité dans une implémentation Active Directory, il est nécessaire de comprendre l'architecture Active Directory actuelle pour déterminer les hôtes à isoler et les modalités de l'isolation.
• Noms et nombre de domaines. L'authentification IPSec intervient suite au processus de
négociation IKE. Dans cette solution, la méthode d'authentification est le protocole Kerberos. Ce protocole suppose que les ordinateurs sont associés à des domaines et qu'ils répondent aux
55
exigences de version requises en matière de système d'exploitation (Windows 2000, Windows XP ou Windows Server 2003).
• Nombre et types d'approbations. Connaître le nombre et les types d'approbations est crucial puisque les approbations affectent les limites logiques de l'isolation et permettent de définir la manière dont peut (ou doit) survenir l'authentification IKE dans la solution.
• Noms et nombre de sites. L'architecture du site s'aligne généralement sur la topologie du réseau. En maîtrisant le mode de définition des sites dans Active Directory, vous comprendrez mieux la réplication et d'autres processus. Dans cette solution, l'architecture du site offre une description plus approfondie de l'implémentation Active Directory tel qu'elle existe à l'heure actuelle.
• Structure d'unités d'organisation. Lorsque vous créez une structure d'unités d'organisation, un
minimum de planification permet d'augmenter considérablement l'efficacité opérationnelle. Les unités d'organisation sont des constructions logiques. Elles peuvent donc être modelées pour répondre à divers objectifs et exigences. La structure d'unités d'organisation est le laboratoire idéal à partir duquel vous pouvez examiner l'utilisation de la stratégie de groupe et l'agencement des unités d'organisation. Les chapitres 4 et 5 de cette solution décrivent l'architecture des unités d'organisation et expliquent en détail comment en faire usage pour appliquer la stratégie IPSec.
• Utilisation actuelle de la stratégie IPSec. L'objectif ultime de ce projet étant l'implémentation de
la stratégie IPSec, il est primordial que vous sachiez comment votre réseau exploite actuellement IPSec (si tel est le cas). Que vous utilisiez de simples filtres IPSec (comme ceux prescrits dans un guide de renforcement de la sécurité) ou implémentiez des stratégies complètes, la connaissance de votre utilisation actuelle et des conditions mêmes de cette utilisation permettront une intégration plus efficace dans la solution.
Le scénario de la Woodgrove Bank présente une seule et unique forêt (corp.woodgrovebank.com) composée de quatre domaines répartis sur cinq sites. Chaque site peut comporter un contrôleur de domaine (DC), un contrôleur principal de domaine (PDC) ou un serveur de catalogue global (GC) comme le montre le tableau cidessous. Tableau 3.1 : Informations Active Directory de la Woodgrove Bank Site physique
Domaine
Utilisateurs
Type de contrôleur de domaine
New York, NY
corp.woodgrovebank.com, americas.corp.woodgrovebank.com
5 000
Catalogue global racine de la forêt PDC GC régional, Amériques DC régional, Europe DC régional, Asie
Chicago, IL
americas.corp.woodgrovebank.com
750
GC régional, Amériques
Atlanta, GA
americas.corp.woodgrovebank.com
1 450
GC régional, Amériques
Boston, MA
americas.corp.woodgrovebank.com
480
GC régional, Amériques
San Francisco, CA
americas.corp.woodgrovebank.com
250
GC régional, Amériques
Pittsburgh, PA
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Phoenix, AZ
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Miami, FL
americas.corp.woodgrovebank.com
50
GC régional, Amériques
Washington, DC
americas.corp.woodgrovebank.com
75
GC régional, Amériques
Cambridge, MA
americas.corp.woodgrovebank.com
36
GC régional, Amériques
Toronto, Canada
americas.corp.woodgrovebank.com
25
GC régional, Amériques
56
Londres, R.U.
europe.corp.woodgrovebank.com, corp.woodgrovebank.com
5 200
GC racine de la forêt Émulateur PDC GC régional, Europe DC régional, Amériques DC régional, Asie
Genève, Suisse
europe.corp.woodgrovebank.com
350
GC régional, Europe
Amsterdam, Pays Bas
europe.corp.woodgrovebank.com
295
GC régional, Europe
Munich, Allemagne
europe.corp.woodgrovebank.com
149
GC régional, Europe
Rome, Italie
europe.corp.woodgrovebank.com
80
GC régional, Europe
Dublin, Irlande
europe.corp.woodgrovebank.com
79
GC régional, Europe
Édimbourg, Écosse
europe.corp.woodgrovebank.com
40
GC régional, Europe
Johannesburg, Afrique du Sud
europe.corp.woodgrovebank.com
37
GC régional, Europe
Tokyo, Japon
asia.corp.woodgrovebank.com, corp.woodgrovebank.com
500
GC racine de la forêt Émulateur PDC GC régional, Asie DC régional, Europe DC régional, Amériques
HongKong, Chine
asia.corp.woodgrovebank.com
100
GC régional, Asie
Bangkok, Thaïlande
asia.corp.woodgrovebank.com
150
GC régional, Asie
Singapour
asia.corp.woodgrovebank.com
210
GC régional, Asie
Sydney, Australie
asia.corp.woodgrovebank.com
45
GC régional, Asie
Bangalore, Inde
asia.corp.woodgrovebank.com
35
GC régional, Asie
Taipei, Taïwan
asia.corp.woodgrovebank.com
65
GC régional, Asie
La structure Active Directory de la Woodgrove Bank utilisait les relations d'approbation bidirectionnelle automatiquement créées par la forêt. Aucune approbation supplémentaire entre forêts ou externe n'était disponible. La figure suivante donne un exemple de la structure d'unités d'organisation de haut niveau adoptée à la Woodgrove Bank. Cette structure a fait l'objet d'une utilisation cohérente sur les trois domaines régionaux principaux (Amériques, Europe et Asie).
57
Figure 3.2 Exemple de structure d'unités d'organisation Woodgrove Bank
Le projet d'isolation de serveurs et de domaines étant la première implémentation IPSec réalisée par la Woodgrove Bank, aucune stratégie IPSec active et existante n'était en place.
Détection d'hôtes L'avantage le plus précieux d'un projet de découverte des ressources est la quantité considérable de données recueillies sur les hôtes (stations de travail et serveurs) du réseau. Les décisions prises et décrites au chapitre 4, « Conception et planification de groupes d'isolation », exigeront des informations précises sur l'état de l'ensemble des hôtes afin de garantir leur aptitude à participer aux communications IPSec de la solution. Données requises concernant les hôtes Cette section décrit les informations nécessaires sur les hôtes et explique comment les représenter de manière physique et logique.
• Nom de l'ordinateur. Il s'agit du nom NetBIOS ou DNS de l'ordinateur permettant d'identifier ce
dernier sur le réseau. Du fait qu'un ordinateur peut disposer de plusieurs adresses MAC (Media Access Control) et/ou IP, le nom d'ordinateur constitue l'un des critères en fonction desquels vous pouvez déterminer l'unicité sur le réseau. Les noms des ordinateurs peuvent être dupliqués dans certaines circonstances de sorte que l'unicité ne soit pas jugée comme absolue.
• Adresse(s) IP de chaque carte d'interface réseau. L'adresse IP désigne l'adresse utilisée avec le masque de sousréseau pour identifier un hôte sur le réseau. Une adresse IP n'est pas une méthode efficace d'identification d'une ressource parce qu'elle est change fréquemment.
• Adresse MAC de chaque carte d'interface réseau. L'adresse MAC est une adresse 48 bits unique utilisée pour identifier une interface réseau. Elle peut servir à différencier plusieurs interfaces réseau sur le même périphérique.
• Système d'exploitation, service pack et versions de correctifs. La version du système
d'exploitation est un facteur clé permettant de déterminer l'aptitude d'un hôte à communiquer avec IPSec. Il est également primordial de contrôler l'état actuel des service packs et des correctifs susceptibles d'être installés car ces éléments sont souvent utilisés pour déterminer si les normes de sécurité minimales sont respectées.
• Appartenance au domaine. Ces informations sont utilisées pour déterminer si un ordinateur peut se procurer la stratégie IPSec à partir d'Active Directory ou s'il doit utiliser une stratégie IPSec locale.
58
• Emplacement physique. Cette information représente simplement l'emplacement du périphérique de votre organisation. Vous pouvez l'utiliser pour déterminer si un périphérique doit participer à un groupe d'isolation particulier en fonction de son emplacement ou de l'emplacement des périphériques avec lesquels il communique régulièrement.
• Type/rôle du matériel. Ces informations ne sont parfois pas accessibles via un processus
automatisé. Certains outils de détection d'hôtes peuvent permettre de les obtenir en sondant les informations liées au matériel, puis en exécutant des applications pour déterminer le type (serveur, station de travail ou Tablet PC). Vous pouvez également exploiter ces données afin d'évaluer le droit d'un ordinateur spécifique à participer au processus d'isolation et de définir le groupe d'isolation dans lequel le placer.
Remarque : les informations ayant trait au type de matériel sont obtenues par interpolation des données ou par le biais d'un logiciel soumettant des requêtes en vue de se procurer ces informations. Par exemple, il est évident qu'un HP Evo n800 est un ordinateur portable. Si vous avez la possibilité de soumettre une requête au niveau du matériel (ou de le munir d'une étiquette d'inventaire l'identifiant en tant que tel), vous pouvez plus facilement déterminer la stratégie IPSec appropriée à attribuer au périphérique. Après avoir collecté toutes ces informations et les avoir regroupées dans une base de données, procédez à intervalles réguliers à des opérations de détection afin de les tenir à jour. Vous aurez besoin d'un état complet et à jour des hôtes gérés sur les réseaux pour concevoir une solution conforme aux exigences de votre organisation. Vous pouvez employer diverses méthodes pour recueillir des données sur les hôtes du réseau. Il peut s'agir de systèmes haut de gamme entièrement automatisés ou bien d'un processus d'extraction des données entièrement manuel. En règle générale, le recours aux méthodes automatisées de recueil des données est préférable aux méthodes manuelles pour des raisons de vitesse et de sécurité. Néanmoins, quelle que soit la méthode adoptée, les informations requises restent les mêmes. La seule différence concerne le temps nécessaire à l'obtention de ces données. Les processus manuels soulèvent généralement plusieurs difficultés : risque d'informations en double, portée de l'effort engagé (tous les réseaux ontils été analysés ? Les informations recueillies concernentelles tous les hôtes ou simplement les sousréseaux de clients ?) et recueil des données en temps utile. L'étude de tous les éléments d'un audit complet du système informatique dépasse le cadre de ce projet. Cependant, il est important de comprendre que ces informations d'audit jouent un rôle crucial pour l'organisation, un rôle qui dépasse largement les seuls besoins de cette solution. Le suivi des ressources et la gestion des risques de sécurité sont deux exemples de processus clés qui justifient la nécessité d'un inventaire système actualisé et minutieux. Détection automatisée L'emploi d'un système de gestion réseau avec audit automatisé, tel que SMS, permet d'obtenir des informations précieuses sur l'état actuel de l'infrastructure informatique. Les systèmes automatisés posent cependant un problème lié au fait que les hôtes hors connexion, débranchés ou en état d'incapacité physique (ou logique) de répondre à des demandes d'information n'apparaissent pas dans la base de données finale. Même les systèmes les plus automatisés exigent un degré de gestion manuelle pour s'assurer que les hôtes sont accessibles et pris en compte comme il se doit. Nombre de produits et d'outils sont, dans ce domaine, proposés par divers fournisseurs. Certaines méthodes font appel à un mécanisme d'analyse centralisé, d'autres utilisent des agents installés sur les ordinateurs clients. L'objectif du présent guide n'est pas de comparer et de conseiller des produits à acheter mais la solution exige que les données de découverte et de détection détaillées dans ce chapitre soient disponibles pour les considérations de conception émises dans les chapitres 4 et 5. Pour plus d'informations sur la manière dont SMS 2003 peut contribuer à la gestion des ressources (ou aider à recueillir les informations nécessaires à ce projet), accédez à la démonstration et à la fiche
59
technique consacrée à la gestion des ressources à partir de la page SMS 2003 Asset Management (Gestion du parc informatique avec Systems Management Server 2003) à l'adressewww.microsoft.com/smserver/evaluation/capabilities/asset.asp. Détection manuelle La différence majeure entre les méthodes de détection manuelles et les méthodes automatisées est le temps. L'obtention manuelle des données requises pour ce projet peut mobiliser une bonne dizaine de personnes et exiger des jours ou des semaines, voire peutêtre plus dans une entreprise de plus grande échelle. Si vous envisagez de recourir à une méthode manuelle pour procéder à un audit de l'état actuel de votre infrastructure, il est primordial que les informations recueillies soient disponibles dans un format électronique (par exemple, dans une feuille de calcul ou une base de données). Le volume de données susceptible d'être généré peut rendre le processus de filtrage et d'analyse très fastidieux si vous ne parvenez pas à soumettre avec rapidité et précision des requêtes spécifiques capables de renvoyer les informations requises. Qui plus est, vous pouvez faire appel aux administrateurs informatiques pour vous procurer les informations ou valider toutes les informations recueillies précédemment. Même si votre organisation ne bénéficie pas d'un outil d'audit automatisé, il existe toujours une part d'automatisation possible via les interfaces de script et de gestion à distance standards disponibles sur la plateforme Windows. La principale difficulté liée à l'utilisation de ces outils est de veiller à n'oublier aucun client simplement parce qu'il n'est pas compatible avec le script ou l'outil de gestion. Vous pouvez utiliser l'environnement d'exécution de scripts Windows, Microsoft Visual Basic® Scripting Edition (VBScript) et Windows Management Instrumentation (WMI) pour créer un fichier de script capable de collecter des informations de configuration système. Le tableau cidessous décrit la disponibilité de VBScript et WMI par plateforme. Tableau 3.2 : Disponibilité de VBScript et WMI par plateforme Plateforme
VBScript
WMI
Windows 95
Installer WSH 5.6
Installer WMI CORE 1.5
Windows 98
Intégré
Installer WMI CORE 1.5
Windows Millennium
Intégré
Intégré
Microsoft Windows NT® version 4.0
Installer WSH 5.6
Installer WMI CORE 1.5
Windows 2000
Intégré
Intégré
Windows XP
Intégré
Intégré
Windows Server 2003
Intégré
Intégré
Remarque : vous pouvez télécharger la mise à jour de Microsoft Windows Script 5.6 depuis la page Microsoft Windows Script Downloads (téléchargements de Microsoft Windows Script) à l'adresse http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp. Vous pouvez télécharger également le fichier d'installation de Windows Management Instrumentation (WMI) CORE 1.5 depuis le Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46e2134cbf9c5b fbf236e0e875&DisplayLang=en.
60
Un exemple VBScript intitulé Discovery.vbs est fourni dans le dossier Tools and Templates de cette solution. Ce script utilise le service WMI pour extraire l'ensemble des données répertoriées dans la section « Données requises concernant les hôtes » de ce chapitre, à l'exception du rôle et de l'emplacement physique. Les informations sont rassemblées dans le fichier texte C:\Discovery\<systemname>_info.txt sur l'ordinateur local. Vous pouvez modifier le script pour collecter d'autres informations ou placer les informations collectées sur un partage de fichiers distant. Si WMI ou VBScript n'est pas disponible sur l'ordinateur hôte, vous pouvez recueillir certaines informations à l'aide d'un script de commandes et d'outils externes. La difficulté vient du fait que le langage de commandes est extrêmement limité en termes de fonctionnalités et que les informations de configuration ne sont pas faciles à extraire de la ligne de commande dans les versions antérieures de Windows. Pour procéder à une détection d'hôtes, il est nécessaire d'interroger les hôtes et de fournir un emplacement pour stocker les résultats obtenus. Que vous optiez pour une méthode de collecte des données manuelle, automatique ou hybride, l'une des plus grandes difficultés pour garantir la validité de la conception consiste à connaître les modifications survenues entre l'analyse d'inventaire d'origine et le début de l'implémentation. Une fois la première analyse terminée, vous devez informer votre personnel de support que toutes les modifications futures doivent être enregistrées et les mises à jour consignées dans l'inventaire. Cet inventaire est indispensable à la planification et l'implémentation des stratégies IPSec (sujets abordés dans les chapitres suivants).
Considérations relatives à la capacité Une fois le processus de collecte des informations achevé, vous devez vous intéresser à l'impact d'IPSec, notamment en termes de planification de la capacité. Cette section décrit certains des éléments essentiels d'une planification en bonne et due forme d'IPSec dans votre environnement.
Impact d'IPSec Du fait des diverses techniques cryptographiques auxquelles il fait appel, IPSec peut entraîner une consommation importante des ressources de l'ordinateur. Les scénarios qui exigeront une analyse plus profonde sont ceux qui préconiseront un chiffrement. Par exemple, un scénario peut envisager l'utilisation des algorithmes 3DES (Triple Data Encryption Standard) et SHA1 (Secure Hash Algorithm) pour vérifier l'intégrité dans des situations qui exigent la plus forte protection disponible en termes d'échange de clés et de chiffrement. Un autre scénario impliquera la négociation de l'association de sécurité. Vous pouvez opter pour une durée plus courte pour l'association de sécurité en mode principal (par exemple, trois heures) mais comme dans toutes considérations ayant trait à la sécurité, soyez prêt à faire des compromis. Chaque association de sécurité en mode principal consomme environ 5 Ko de mémoire vive (RAM). Une situation dans laquelle un serveur est contraint de négocier des dizaines de milliers de connexions simultanées peut entraîner une consommation abusive. D'autres facteurs concernent l'utilisation du processeur sur les serveurs de l'infrastructure réseau, la consommation accrue des ressources sur les serveurs et les stations de travail exécutant IPSec (surtout les serveurs puisque, dans la plupart des cas, ils comportent un plus grand nombre d'associations de sécurité en mode principal que les clients) et le temps de réponse du réseau plus long résultant de la négociation IPSec. Remarque : dans le cadre de son propre scénario de déploiement de cette solution, Microsoft a constaté qu'une augmentation possible (de l'ordre de un à trois pour cent) de la charge réseau est tout à fait normale. Cette augmentation est une conséquence directe de l'utilisation d'IPSec.
61
Un autre problème majeur concerne les réseaux reliés par un périphérique de traduction d'adresses réseau (NAT). Il vient du fait que la traduction d'adresses réseau (NAT) n'autorise pas les conversations d'authentification de l'entête (AH) entre les hôtes parce qu'elle est contraire au principe même du protocole AH : l'authentification d'un paquet inchangé, y compris l'entête. Si des périphériques NAT existent sur le réseau interne, préférez le protocole ESP au protocole AH. Le protocole ESP offre la possibilité de chiffrer les données mais n'exige pas le chiffrement. Ce facteur est essentiel en terme d'évaluation de la capacité puisque le chiffrement implique une surcharge dont il faut tenir compte pendant les phases de planification et de conception du projet. Le protocole ESP peut également être implémenté sans chiffrement et, ainsi, offrir la communication homologue à homologue la plus forte sans rompre les communications avec la traduction d'adresses réseau (NAT). Utilisé sans chiffrement, son impact serait donc plus faible qu'une solution ESP avec chiffrement.
Impact de la stratégie La stratégie IPSec et la stratégie de groupe ont toutes les deux un impact sur les temps de démarrage des ordinateurs et sur le temps nécessaire aux utilisateurs pour se connecter. Lors de la phase de recueil des données, il peut être utile de relever les temps de démarrage des ordinateurs et les temps de connexion des utilisateurs avant d'implémenter la solution. L'enregistrement de ces données fournira un élément de base avec lequel vous pourrez comparer les systèmes testés lors de l'étape pilote afin de déterminer l'impact sur le temps global nécessaire à un utilisateur pour se connecter.
Problèmes de prédéploiement Les sections précédentes décrivaient les informations à recueillir à partir du réseau, d'Active Directory et des hôtes pour garantir le succès d'un projet d'isolation. Cette section signale les domaines de préoccupation à examiner de près avant de déployer IPSec.
Infrastructure réseau Le recueil d'informations vous permet de planifier une isolation IPSec sur un réseau. Une fois ces informations collectées, vous pourrez procéder à une analyse minutieuse des données qui révèlera la majorité des problèmes auxquels vous serez confronté lors de la phase pilote et du déploiement. Bien que les éléments suivants ne soient pas exhaustifs, il est important de les prendre en considération au moment d'entamer l'analyse des informations recueillies avant les tests et le déploiement. Périphériques surexploités Vous devrez peutêtre mettre à niveau ou reconfigurer les commutateurs ou les routeurs exploités actuellement à plus de 75 pour cent pour permettre un trafic accru sur le périphérique et garantir une marge d'utilisation supplémentaire en cas de pointes de trafic. Dans le contexte d'une implémentation IPSec, la planification en bonne et due forme de la capacité est plus une affaire de tests et de charges de trafic anticipées que de calculs précis. Parce qu'il est fort improbable que le scénario, les modèles de trafic, les groupements d'utilisateurs et les applications soient les mêmes pour deux clients, une planification appropriée et la prise en compte de l'impact sur les périphériques du réseau sont indispensables. Par exemple, certains aspects d'IPSec sont totalement prévisibles. Chaque paquet utilisant IPSec avec ESP sera exactement 36 octets plus volumineux que le même paquet n'utilisant pas IPSec. Savoir que la création d'une seule association de sécurité en mode principal exige six messages permet de se représenter plus facilement quel sera l'impact de son utilisation sur un périphérique donné. Vous pouvez utiliser des outils tels que l'application PROVISO de Quallaby (disponible sur www.quallaby.com), ou d'autres solutions d'analyse réseau pour faciliter votre travail de planification de la capacité IPSec dans votre environnement informatique.
62
Périphériques incompatibles Les périphériques qui ne sont pas compatibles avec IPSec ne peuvent pas participer aux communications IPSec. Si ces périphériques ont besoin de communiquer avec un périphérique géré, placezles dans la liste d'exemptions IPSec. Une autre solution consiste à mettre à niveau le matériel ou les logiciels des périphériques afin qu'ils prennent en charge IPSec. Une autre encore est de permettre à ces périphériques non gérés de communiquer avec des ordinateurs voisins lorsqu'ils communiquent en texte clair pour leurs communications sortantes. Périphériques mal configurés Des périphériques mal configurés peuvent augmenter le risque d'échec des communications et de charge accrue sur le périphérique, mais aussi compromettre leur intégrité. Les méthodes de configuration, d'administration et de sécurité conseillées ciaprès permettront de réduire les risques. Adressage IP Parce que les adresses IP constituent la pierre d'angle d'une solution IPSec, il est primordial que l'adressage soit aussi net que possible. Des espaces d'adresses se chevauchant, des adresses en double, des masques de sousréseau incorrects et bien d'autres problèmes peuvent compliquer les opérations réseau classiques. L'apport d'IPSec à un réseau de ce type ne fera que compliquer le dépannage et incitera les utilisateurs à penser qu'IPSec est la source de tous ces problèmes. La croissance des entreprises, les fusions et les acquisitions, et bien d'autres facteurs encore, peuvent rapidement contribuer au développement d'une image fausse et obsolète de l'adressage IP sur un réseau. Pour éviter les problèmes majeurs liés à IPSec, assurezvous que le réseau est divisé en sousréseaux qui ne se chevauchent pas, que les tables de routage sont récapitulées comme il se doit et que l'agrégation par adresses est facile à déterminer.
Informations Active Directory Si l'implémentation actuelle d'Active Directory fonctionne correctement (résolutions des noms, DHCP (Dynamic Host Configuration Protocol), application de la stratégie de groupe, relations d'approbation, etc.), rien ne saurait affecter IPSec. Surveillez attentivement les modifications effectuées entre le moment où Active Directory a été examiné et le début du projet d'isolation pour vous assurer qu'aucun problème de compatibilité ne surviendra.
Informations concernant les hôtes Grâce aux sections précédentes, vous avez pu recueillir suffisamment d'informations sur les hôtes de votre réseau. Après avoir déterminé les clients et les serveurs aptes à utiliser IPSec, réfléchissez sur la manière de les isoler et aux applications nécessaires pour évaluer avec soin l'impact que la solution d'isolation peut avoir sur eux. Évaluation de la participation client/serveur Une fois les informations concernant les hôtes rassemblées, il est relativement simple de sélectionner les hôtes susceptibles d'être intégrés à la solution d'isolation. Par exemple, seuls des ordinateurs Windows 2000, Windows Server 2003 et Windows XP peuvent communiquer avec IPSec. Toutefois, tous les clients aptes à participer ne doivent pas nécessairement le faire. Une étape clé du processus de conception consiste à déterminer à partir des informations recueillies dans ce chapitre quels ordinateurs et périphériques seront inclus dans la solution et dans quel groupe ils résideront.
63
Définition des services devant être isolés Dans le contexte d'un projet d'isolation de serveurs et de domaines, un service désigne une application (par exemple, Microsoft Exchange Server, Microsoft SQL Server™ ou Internet Information Services/IIS) qui offre ses services à des clients du réseau. Vous devez évaluer ces services de manière individuelle afin de déterminer s'ils sont des candidats à l'isolation de serveurs et de domaines. Plusieurs raisons peuvent justifier l'intégration de ces services dans la solution. Cela peut être une question de stratégie d'organisation, d'exigence réglementaire ou d'impératif commercial. Par exemple, une stratégie de l'organisation peut stipuler que toutes les communications entre les serveurs de messagerie doivent être sécurisées avec IPSec, mais pas les communications entre les clients et les serveurs. Le chapitre 4, « Conception et planification de groupes d'isolation », aborde le processus d'isolation plus en détail. Lorsque vous tentez d'isoler des services, examinez avec soin les serveurs qui font intervenir plusieurs services, comme dans le cas d'un serveur de fichiers offrant des services Web et un service FTP (File Transfer Protocol) et faisant également office de serveur de messagerie. Équilibrage de la charge réseau et clusters Les organisations qui utilisent l'isolation de serveurs et de domaines peuvent choisir d'exclure les ordinateurs ayant recours à l'équilibrage de la charge réseau et aux clusters. IPSec n'est pas compatible avec l'équilibrage de la charge réseau en mode « sans affinité » puisqu'il empêche différents ordinateurs d'exploiter la même connexion cliente. Du fait de cette incompatibilité, il est préférable d'éviter l'équilibrage de la charge réseau en mode « sans affinité » avec IPSec. Gestion des exceptions La gestion des exceptions est une étape essentielle de la planification IPSec. Savoir où utiliser les ordinateurs qui autoriseront l'accès depuis les hôtes non approuvés et comment contrôler l'accès entre les ordinateurs gérés et non gérés est un paramètre essentiel de l'isolation. La meilleure méthode conseillée dans ce domaine est de maintenir le nombre d'exceptions aussi réduit que possible. Les besoins techniques peuvent exiger que certains ordinateurs ou services soient exemptés d'IPSec, notamment les contrôleurs de domaine et les serveurs DHCP, DNS et WINS. Étant donné la nécessité de gérer en permanence ces ordinateurs, le risque encouru est plus faible que d'autoriser les ordinateurs non gérés à communiquer avec des ordinateurs gérés et approuvés. Périphériques nonWindows La plupart des réseaux d'entreprise ne sont pas homogènes. Vous devez tenir compte de la diversité des éléments, tels que les systèmes d'exploitation, l'infrastructure réseau et les platesformes matérielles lorsque vous planifiez le déploiement d'IPSec. Si votre organisation possède des ordinateurs exécutant un système autre que Windows, vous devez comprendre que la consommation de la stratégie IPSec hors du domaine Windows n'est actuellement pas possible. Une organisation peut décider de faire face à cette restriction en traitant certaines platesformes comme approuvées mais la solution d'isolation de serveurs et de domaines ne les protègera pas puisque ces plates formes sont dans l'incapacité d'exploiter la stratégie IPSec. La section qui suit explique comment déterminer l'approbation. Périphériques de gestion et de contrôle Un aspect d'IPSec souvent ignoré lors de la phase de planification initiale est son impact sur la gestion et le contrôle du trafic du réseau. Parce qu'IPSec exige une authentification et autorise le chiffrement, certains périphériques ne sont plus en mesure de contrôler ou de gérer les ordinateurs activés avec IPSec. Dans certains cas exigeant un chiffrement, une organisation peut supposer que la sécurité est plus importante que le besoin opérationnel de contrôler les données tandis qu'elles transitent sur le réseau. Dans d'autres cas, il sera nécessaire d'évaluer les modifications que vous 64
pouvez apporter à une application ou un périphérique pour activer le contrôle IPSec (par exemple, un analyseur ESP capable d'examiner le trafic ESP). S'il s'avère impossible de mettre à niveau les périphériques de contrôle ou de gestion pour la prise en charge d'IPSec, il est crucial alors que vous enregistriez ces informations. L'architecte de la solution et l'équipe qui l'entoure auront besoin de ces informations au chapitre 4, « Conception et planification de groupes d'isolation ».
Définition de l'approbation Après avoir rassemblé des informations sur les périphériques hôtes qui composent actuellement votre infrastructure informatique, vous devez déterminer de manière fondamentale ce qui affecte directement la capacité d'un hôte à participer à la solution. L'objectif est de décider jusqu'à quel point un hôte peut être considéré comme approuvé. Le terme « approuvé » peut signifier différentes choses pour différentes personnes ; il est donc important de parvenir à une définition précise afin de la communiquer à toutes les parties prenantes. Ne pas le faire, c'est risquer d'exposer la sécurité de l'environnement approuvé à des problèmes puisque la sécurité globale ne peut aller audelà du niveau de sécurité défini par le client le moins sécurisé autorisé à adopter l'état approuvé. Pour comprendre ce concept, tenez compte des quatre états de base applicables aux hôtes d'une infrastructure informatique classique. Ces états sont (par degré de risque, avec le risque le plus faible en premier) les suivants :
1. Approuvé 2. Digne de confiance 3. Connu, non approuvé 4. Inconnu, non approuvé Le reste de cette section définit ces états et explique comment déterminer dans votre organisation quels hôtes appartiennent à quel état.
État Approuvé Le classement d'un hôte comme approuvé ne signifie pas que l'hôte en question est parfaitement sécurisé ou invulnérable. Fondamentalement, « approuvé » signifie que les risques de sécurité de l'hôte sont gérés. La responsabilité de cet état géré revient aux administrateurs et aux utilisateurs informatiques responsables de la configuration de l'hôte. Un hôte approuvé mal géré peut devenir une faiblesse et mettre en péril la solution tout entière. Lorsqu'un hôte est considéré comme approuvé, les autres hôtes approuvés doivent pouvoir légitimement partir du principe que cet hôte ne commettra aucun acte malveillant. Par exemple, des hôtes approuvés ne peuvent s'attendre à une attaque de virus de la part d'autres hôtes puisque tous les hôtes approuvés doivent recourir à des mécanismes (notamment un logiciel antivirus) visant à minimiser les risques de virus. La communication entre hôtes approuvés ne doit pas être gênée par l'infrastructure du réseau. Par exemple, si un hôte approuvé peut librement partir du principe qu'aucun autre hôte approuvé ne commettra d'acte malveillant à son encontre, le blocage des paquets au niveau IP destiné à limiter l'accès d'autres hôtes approuvés n'est généralement pas nécessaire. Vous devez appliquer toutes les restrictions nécessaires au contrôle des communications des hôtes par port ou protocole en utilisant un parefeu basé sur l'hôte sur l'ordinateur luimême, pas en utilisant IPSec. Dans le scénario imaginé pour la Woodgrove Bank, l'équipe de la sécurité a défini les cinq objectifs clés suivants afin de planifier les technologies nécessaires à l'hôte pour atteindre l'état approuvé : 65
• L'identité de l'ordinateur ou de l'utilisateur n'a pas été compromise. • Les ressources requises sont sécurisées et disponibles, quel que soit leur emplacement dans l'environnement géré.
• Une ressource jugée sécurisée est protégée contre tout risque de falsification, de virus ou de tentative d'accès non autorisé. • Une ressource signalée comme étant disponible respecte ou dépasse les niveaux attendus de durée active et est protégée contre toute faille de sécurité. • Un environnement considéré comme géré dispose d'ordinateurs dotés de Windows 2000 SP4 (ou une version ultérieure) et de la configuration et des correctifs appropriés.
• Les données et les communications sont privées, ce qui signifie que seuls les destinataires concernés peuvent lire et utiliser ces informations.
• Le propriétaire ou l'opérateur du dispositif comprend et accepte de se conformer aux stratégies et aux procédures afin de maintenir la confiance accordée à l'environnement.
• La réaction face aux risques et aux menaces intervient en temps utile. Forte de ces objectifs, l'équipe du support de la Woodgrove Bank a pu définir un ensemble d'exigences technologiques permettant de déterminer si un hôte peut être considéré comme approuvé. Au moment de définir l'état approuvé, assurezvous que les propriétaires des ressources impliquées sont libres de définir des conditions de sécurité supplémentaires répondant aux besoins commerciaux d'une ressource ou d'un actif donné. Par exemple, votre service des ressources humaines peut exiger un mécanisme d'ouverture de session biométrique pour des serveurs spécifiques. Cette exigence n'aura aucune incidence sur la confiance à accorder aux serveurs dans le contexte de cette solution. Néanmoins, vous devez rester vigilant et veiller à ce que les exigences d'une ressource particulière n'entrent pas en conflit avec celles de l'état approuvé. Consacrez un peu de temps à la définition des objectifs et des besoins technologiques que votre organisation juge convenables en tant que configuration minimale pour l'octroi de l'état approuvé à un hôte. Par exemple, l'équipe de conception a dressé cidessous la liste des exigences technologiques requises dans le cadre du scénario de la Woodgrove Bank.
• Système d'exploitation. Un hôte approuvé doit exécuter Windows XP SP2 ou Windows Server 2003, ou au minimum Windows 2000 SP4.
• Appartenance au domaine. Un hôte approuvé appartient à un domaine géré, ce qui signifie que le service informatique doit posséder des droits de gestion de la sécurité.
• Client de gestion. Tous les hôtes approuvés doivent exécuter un client de gestion réseau
spécifique pour permettre une gestion centralisée et un contrôle des stratégies de sécurité, des configurations et des logiciels.
• Logiciel antivirus. Tous les clients approuvés doivent être dotés d'un logiciel antivirus configuré
en vue de mettre à jour automatiquement et quotidiennement les derniers fichiers de signatures de virus.
• Système de fichiers. Tous les hôtes approuvés seront configurés avec le système de fichiers NTFS.
• Paramètres du BIOS. Tous les ordinateurs portables approuvés seront configurés avec un mot de passe au niveau du BIOS contrôlé par l'équipe du support informatique.
66
• Conditions requises pour les mots de passe. Les clients approuvés doivent utiliser des mots de passe forts.
Un élément essentiel à comprendre est le fait que l'état approuvé n'est pas constant. C'est un état de transition soumis à des normes de sécurité qui évoluent et au besoin de se conformer à ces normes. De nouvelles menaces et de nouveaux principes de défense apparaissent constamment. C'est pourquoi il est impératif que les systèmes de gestion de l'organisation vérifient en permanence les hôtes approuvés pour garantir une conformité continue. Qui plus est, ces systèmes doivent être capables d'émettre des mises à jour ou des changements de configuration s'ils sont chargés de maintenir l'état approuvé. Un hôte apte à répondre en permanence à l'ensemble des exigences de sécurité peut être considéré comme approuvé. Néanmoins, il est fort probable que la plupart des ordinateurs hôtes identifiés au cours du processus de détection et de découverte abordé plus haut dans ce chapitre ne répondent pas à ces exigences. Il est donc primordial de distinguer les hôtes qui peuvent être approuvés de ceux qui ne le peuvent pas (considérés alors comme non approuvés). Pour faciliter ce processus, vous pouvez définir un état Digne de confiance intermédiaire. Le reste de cette section aborde les différents états et leurs implications.
État Digne de confiance Si nécessaire, il peut être utile d'identifier au plus vite dans votre infrastructure actuelle les hôtes aptes à devenir approuvés. Un état Digne de confiance peut être attribué à l'hôte actuel pour confirmer son aptitude physique à devenir approuvé en effectuant les modifications requises au niveau des logiciels et de la configuration. Pour chaque ordinateur auquel vous attribuez un état Digne de confiance, pensez à ajouter une note de configuration consignant les conditions permettant à l'hôte d'atteindre l'état approuvé. Ces informations revêtent une importance toute particulière pour l'équipe de conception du projet (afin d'estimer les coûts résultant de l'ajout de l'hôte à la solution) et le personnel du support (pour pouvoir appliquer la configuration requise). En règle générale, les hôtes dignes de confiance tombent dans l'un des deux groupes suivants :
• Configuration requise. Le matériel utilisé, le système d'exploitation et le logiciel actuels
permettent à l'hôte d'atteindre un état Digne de confiance. En revanche, des changements de configuration supplémentaires sont nécessaires avant de parvenir aux niveaux de sécurité requis. Par exemple, si l'organisation exige un système de fichiers sécurisé avant de pouvoir considérer un hôte comme approuvé, un hôte avec un disque dur de format FAT32 ne pourra pas satisfaire cette exigence.
• Mise à niveau requise. Ce groupe d'ordinateurs exige des mises à niveau système avant d'être considéré comme approuvé. La liste suivante fournit quelques exemples sur le type de mise à niveau que les ordinateurs de ce groupe peuvent exiger :
• Mise à niveau du système d'exploitation requise. Si le système d'exploitation actuel de l'hôte n'est pas capable de prendre en charge les exigences de sécurité de l'organisation, une mise à niveau sera nécessaire pour que l'hôte puisse accéder à l'état approuvé. • Logiciel requis. Un hôte non doté de l'application de sécurité requise (par exemple, un outil d'analyse antivirus ou un client de gestion) ne peut être considéré comme approuvé tant que les applications nécessaires n'ont pas été installées et activées. • Mise à niveau matérielle requise. Dans certains cas, un hôte peut exiger une mise à niveau matérielle spécifique avant d'être déclaré comme approuvé. Il s'agit généralement d'une mise à niveau du système d'exploitation ou d'un logiciel supplémentaire forçant la mise à niveau matérielle requise. Par exemple, un logiciel de sécurité nécessitant un espace de stockage supplémentaire exigera davantage d'espace sur le disque dur.
67
• Changement d'ordinateur requis. Cette catégorie est réservée aux hôtes inaptes à satisfaire les exigences de sécurité de la solution du fait de leur incapacité matérielle à prendre en charge la configuration minimale acceptable. Il peut s'agir d'un ordinateur incapable d'exécuter un système d'exploitation sécurisé parce qu'il est doté d'un processeur trop ancien (par exemple, un ordinateur x86 de 100 mégahertz). Utilisez ces groupes pour répartir les coûts d'implémentation de la solution sur des ordinateurs exigeant des mises à niveau.
État Connu, non approuvé Lors du processus de catégorisation des hôtes d'une organisation, vous identifierez certains hôtes incapables de parvenir à un état approuvé pour des raisons bien connues et clairement définies. Ces raisons peuvent être de type suivant :
• Financier. Les fonds nécessaires à la mise à niveau du matériel ou des logiciels de cet hôte ne sont pas disponibles.
• Politique. L'hôte doit demeurer dans un état non approuvé en raison d'une situation politique ou
commerciale qui ne lui permet pas de satisfaire les exigences de sécurité minimales dictées par l'organisation. Nous vous conseillons alors fortement de contacter le responsable de l'entreprise ou le fournisseur de logiciels indépendant de l'hôte pour débattre de la valeur ajoutée de l'isolation de serveurs et de domaines.
• Fonctionnel. L'hôte a besoin d'exécuter un système d'exploitation non sécurisé ou d'opérer de
manière non sécurisée pour accomplir son rôle. Par exemple, l'hôte doit peutêtre être utilisé avec un système d'exploitation plus ancien en raison d'une série d'applications commerciales spécifiques ne fonctionnant que sur ce système.
Beaucoup de raisons fonctionnelles peuvent justifier le maintien d'un hôte en état connu non approuvé. La liste suivante présente quelques exemples de motifs fonctionnels susceptibles de justifier un classement dans cet état :
• Ordinateurs dotés de Windows 9x ou Windows Millennium Edition. Les ordinateurs munis de
ces versions particulières du système d'exploitation Windows ne peuvent pas être classées comme dignes de confiance car ces systèmes d'exploitation ne prennent en charge aucune infrastructure de sécurité de base. En fait, de par leur conception, ces systèmes ne disposent d'aucune infrastructure de sécurité. Qui plus est, les fonctions de gestion centrale rudimentaires dont ils sont pourvus ne concernent que des configurations informatiques pour utilisateurs (via la stratégie système et les scripts d'ouverture de session). Pour finir, ces systèmes d'exploitation n'offrent aucune des fonctionnalités requises pour la gestion de la sécurité.
• Ordinateurs dotés de Windows NT. Les ordinateurs dotés de Windows NT ne peuvent pas être
classés comme dignes de confiance dans le contexte de l'isolation de serveurs et de domaines puisque ce système ne prend pas intégralement en charge une infrastructure de sécurité élémentaire. Par exemple, Windows NT ne prend pas en charge les listes de contrôle d'accès de refus dans les ressources locales, toute méthode visant à garantir la confidentialité et l'intégrité des communications réseau, les cartes à puce pour une authentification renforcée ou une gestion centralisée des configurations d'ordinateurs (bien qu'une gestion centralisée limitée des configurations d'utilisateurs soit possible). Windows NT n'offre aucun moyen de protéger la confidentialité des données et de maintenir leur intégrité, tel que le système EFS (Encrypting File System) de Windows 2000.
En outre, il ne prend pas en charge l'ensemble des fonctionnalités de sécurité requises. Par exemple, il ne prend pas en charge la stratégie de groupe ou les stratégies IPSec et ne fournit aucun mécanisme garantissant un accès au niveau Administrateur local si cela est nécessaire. Enfin, ses
68
configurations de sécurité n'étant pas réappliquées régulièrement, il n'existe aucune garantie qu'elles demeurent effectives. Remarque : la description de Windows NT comme système n'étant pas digne de confiance se limite strictement au contexte de l'isolation de serveurs et de domaines et ne concerne d'aucune manière son utilisation en tant que système d'exploitation dans le sens large du terme. Pour les serveurs de ce projet, la mise à niveau vers la plateforme Windows Server 2003 représente la solution la plus sûre et la plus facile à gérer.
• Ordinateurs autonomes. Les ordinateurs dotés d'une version quelconque de Windows et
configurés comme ordinateurs autonomes ou en qualité de membres d'un groupe de travail sont, en règle générale, incapables de parvenir à un état digne de confiance. Même si ces systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, il est peu probable que les fonctionnalités requises pour la gestion de la sécurité soient garanties lorsque l'ordinateur n'est pas membre d'un domaine approuvé.
• Ordinateurs dans un domaine non approuvé. Un ordinateur membre d'un domaine qui n'est pas approuvé par le service informatique d'une organisation ne peut pas être classé comme approuvé. Un domaine non approuvé est un domaine qui n'offre pas les fonctionnalités de sécurité requises à ses membres. Même si les systèmes d'exploitation des ordinateurs membres de ce domaine non approuvé prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne peuvent pas être garanties à 100 % lorsque les ordinateurs ne résident pas dans un domaine approuvé. Par exemple, dans un domaine non approuvé, il n'existe aucun mécanisme garantissant l'octroi d'un accès de niveau Administrateur local pour un utilisateur approuvé. De même, les configurations de sécurité (y compris celles qui peuvent être gérées de manière centrale) peuvent facilement être remplacées par les administrateurs du domaine non approuvé. Enfin, le respect de la configuration de sécurité, des logiciels, des stratégies et des normes ne peut être garanti et les mesures chargées de contrôler de manière efficace toutes les règles de conformité ne sont pas disponibles.
• Ordinateurs dans un domaine Windows NT. Les ordinateurs membres d'un domaine fondé sur Windows NT ne peuvent pas être classés comme étant approuvés. Même si leurs systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne sont pas entièrement prises en charge lorsque les ordinateurs appartiennent à un domaine Windows NT.
Néanmoins, si l'hôte doit être pris en compte lors de la conception parce qu'il joue un rôle indispensable pour l'organisation, il est préférable que vous lui affectiez un état connu, non approuvé. Cela signifie alors que la solution a identifié un risque qu'elle ne peut minimiser. Vous devez faire appel à d'autres techniques pour répondre à cette menace connue. En raison de la nature variée des hôtes appartenant à cette catégorie, aucune instruction spécifique concernant ces techniques ne peut être fournie. Néanmoins, l'objectif de ces techniques doit être de minimiser les risques posés par cet hôte.
État Inconnu, non approuvé L'état Inconnu, non approuvé doit être utilisé comme état par défaut pour tous les hôtes. Du fait de la configuration inconnue des hôtes affichant cet état, aucune confiance ne peut leur être accordée. Le processus tout entier de planification des hôtes dans cet état doit partir du principe que l'hôte risquait ou risque d'être compromis et constitue, par conséquent, un risque inacceptable pour l'organisation. Les personnes chargées de concevoir la solution doivent s'efforcer de minimiser l'impact potentiel des ordinateurs dotés de cet état sur leurs organisations.
Identification des coûts de mise à niveau des hôtes actuels 69
L'ultime étape de ce chapitre concerne le processus d'enregistrement du coût approximatif de la mise à niveau des ordinateurs en vue de rendre ces derniers aptes à contribuer à la solution. Plusieurs décisions seront à prendre lors de la phase de conception du projet et exigeront que vous répondiez aux questions suivantes :
• L'ordinateur répondil aux exigences de configuration matérielle requises pour l'isolation ? • L'ordinateur répondil aux exigences de configuration logicielle requises pour l'isolation ? • Quelles modifications devezvous apporter à la configuration pour intégrer cet ordinateur à la solution d'isolation ?
• Quel coût prévisionnel ou impact suite aux modifications proposées peut permettre de parvenir à un état approuvé ?
En répondant à ces questions, vous pouvez rapidement déterminer le niveau d'effort et le coût approximatif requis pour intégrer un hôte ou un groupe d'hôtes particulier à l'échelle du projet. Il est fort probable qu'aucune personne, voire plusieurs personnes dans un seul rôle, ne rassemble toutes ces données. Certaines de ces données peuvent être recueillies par des techniciens du support technique ou d'un service de terrain ; d'autres exigeront le point de vue d'un architecte ou d'un membre de la direction. Gardez toujours à l'esprit que l'état d'un ordinateur est transitif et qu'en entreprenant les actions correctives présentées, vous pouvez changer l'état d'un ordinateur et le faire passer de non approuvé à approuvé. Après avoir décidé si un ordinateur doit être approuvé ou non, vous êtes p rêt à entamer le proce ssus de planification et de conception, thèmes que le chapitre 4 (« Conception et planification de groupes d'isolation ») aborde plus loin dans ce guide. Le tableau cidessous est un exemple de fiche à l'aide de laquelle vous pouvez identifier l'état actuel d'un hôte et les conditions de son passage à un état approuvé. Tableau 3.3 : Exemple de données collectées sur l'hôte Nom de l'hôte
Config. matérielle conforme
Config. logicielle conforme
Configuration. Détails requise
Coût prévisionnel
HOSTNYC 001
Non
Non
Mise à niveau matérielle et logicielle
Le système d'exploitation actuel est Windows NT 4.0. L'ancien matériel n'est pas compatible avec Windows XP SP2 .
$XXX.
SERVER LON001
Oui
Non
Intégrer Aucun logiciel domaine antivirus présent. approuvé, mettre à niveau de NT 4 vers Windows 2000 ou ultérieur.
$XXX.
La liste suivante explique chaque colonne du tableau 3.3 :
70
• Nom de l'hôte. Nom du dispositif hôte sur le réseau. • Configuration matérielle conforme. Indique si un ordinateur répond aux exigences de configuration matérielle requises pour participer à la solution.
• Configuration logicielle conforme. Indique si un ordinateur répond aux exigences de
configuration logicielle requises pour participer à la solution. Le minimum requis pour la Woodgrove Bank est Windows 2000 SP4, Windows XP SP2 ou Windows Server 2003, ainsi que tous les correctifs de sécurité requis pour chaque système d'exploitation. De plus, tous les ordinateurs doivent appartenir à un domaine approuvé (soit un domaine géré centralement par le personnel informatique de la Woodgrove Bank) et fournir de manière spécifique aux administrateurs informatiques un accès à l'ordinateur.
• Configuration requise. Indique quelle action entreprendre pour permettre à l'ordinateur d'atteindre l'état approuvé.
• Détails. Décrit les raisons pour lesquelles l'ordinateur n'affiche actuellement pas un état approuvé. • Coût prévisionnel. Indique le coût prévisionnel qui permettra au périphérique d'accéder à un état
approuvé. Ce coût doit inclure des estimations portant sur les logiciels, le matériel, la perte de productivité et le support. Ces informations permettront de déterminer s'il est pratique ou valable du point de vue commercial d'ajouter à la solution un ordinateur particulier en tant qu'ordinateur approuvé.
Dans le tableau précédent, l'hôte HOSTNYC001 est actuellement « connu, non approuvé ». Néanmoins, il peut être considéré comme digne de confiance si les mises à niveau requises sont possibles. Cependant, si un grand nombre d'ordinateurs exigent les mêmes mises à niveau, le coût global de la solution peut considérablement augmenter. L'hôte SERVERLON001 répond aux conditions matérielles requises mais doit être mis à niveau vers un système d'exploitation capable d'exploiter la stratégie IPSec et associé à un domaine. Il requiert également un logiciel antivirus. Le coût prévisionnel correspond à la somme des efforts requis pour mettre à niveau le système d'exploitation et installer des logiciels antivirus, plus le coût des licences du système d'exploitation et des logiciels antivirus. Après vous être procuré les informations décrites dans le tableau 3.3, enregistrezles avec les autres informations rassemblées au cours de ce chapitre afin que l'architecte ou l'équipe de conception puisse les exploiter. Ces informations constitueront la base des efforts entrepris au chapitre 4 qui se concentre sur la conception des groupes d'isolation. Notez que les coûts identifiés dans cette section concernent uniquement le coût prévisionnel des mises à niveau des hôtes. Beaucoup d'autres coûts liés à la conception, au support, aux tests et à la formation viendront se greffer au projet. Ces coûts supplémentaires devront être pris en compte dans le plan global du projet si un coût précis doit être évalué pour le projet.
Résumé Ce chapitre offre un aperçu des informations requises pour mener un projet d'isolation de serveurs et de domaines, notamment les considérations d'impact. Vous pouvez utiliser les instructions de ce chapitre pour effectuer les opérations suivantes :
• Identifier les ressources sur le réseau. • Rassembler des informations sur le réseau. • Rassembler des informations sur les hôtes.
71
• Définir les données du trafic actuel. • Examiner l'architecture Active Directory actuelle et recueillir des informations pertinentes la concernant.
• Examiner les éléments à considérer en terme de capacité IPSec. • Afficher les considérations de prédéploiement pour IPSec. • Expliquer ce que sont des dispositifs dignes ou non dignes de confiance et comment ils ont été classés dans le scénario imaginé pour la Woodgrove Bank.
La réalisation de ces tâches permettra de réunir toutes les informations dont vous aurez besoin pour lancer la conception de groupes d'isolation au chapitre suivant.
Informations complémentaires Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de l'implémentation de cette solution :
• Pour plus d'informations sur la configuration des parefeu pour la prise en charge d'IPSec pour
Windows Server 2003, consultez la page Configuring Firewalls (Configuration des parefeu) de la documentation Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/enus/dnsbj_ips_schx.asp.
• Vous pouvez télécharger le pack d'installation de Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46e2134cbf9c5b fbf236e0e875&DisplayLang=en.
• Pour plus d'informations sur WMI, consultez la documentation Windows Management
Instrumentation sur MSDN® à l'adresse http://msdn.microsoft.com/library/enus/wmisdk/ wmi/wmi_start_page.asp.
• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 2000 et XP
depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx? FamilyId=C717D9437E4B462286EB95A22B832CAA&displaylang=en.
• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 98, Windows Millennium Edition et Windows NT 4.0 depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyId=0A8A18F6249C4A72BFCF FC6AF26DC390&displaylang=en.
• Vous pouvez télécharger la documentation de Windows Script 5.6
depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx? FamilyId=01592C48207D4BE18A761C4099D7BBB9&displaylang=en.
72
Chapitre 4 : Conception et planification de groupes d'isolation Ce chapitre détaille la définition de groupes d'isolation répondant aux exigences de sécurité commerciale décrites dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ». Cette solution utilise une combinaison de l'identité de l'ordinateur dans le domaine de service d'annuaire Active Directory®, de la stratégie IPSec pour authentifier cette identité et de la stratégie de sécurité Microsoft® Windows® pour définir et appliquer des groupes d'isolation. Les administrateurs informatiques peuvent utiliser le concept de groupes d'isolation pour gérer le trafic dans leurs réseaux internes de manière sécurisée transparente aux applications. Cette possibilité peut réduire sensiblement la menace de dommages provenant d'infections et d'attaques via le réseau. Par le biais du scénario Woodgrove Bank, ce guide fournit les principaux détails sur la manière dont une organisation peut transformer ses exigences de sécurité en groupes d'isolation déployés. Il indique également comment IPSec peut être combiné à d'autres paramètres de sécurité pour élaborer une solution d'isolation de serveurs et de domaines détaillée, maniable et évolutive. Chaque organisation devra élaborer la solution en fonction des exigences qui lui sont propres, et les modèles utilisés dans ce guide ne sont pas destinés à être suivis sans question ni modification. Les organisations utilisant ce guide devront déterminer ce qui est requis et possible dans leur propre environnement, et apporter les modifications appropriées à la conception du modèle de groupe d'isolation en vue de l'adapter au mieux aux exigences spécifiques de leur activité.
Connaissances préalables requises pour ce chapitre Cette section contient des informations qui vous aideront à déterminer l'approche de votre organisation par rapport à la solution d'isolation de serveurs et de domaines. La réussite de la solution dépend des conditions préalables requises identifiées dans cette section.
Connaissances requises Vous devez connaître les concepts et la terminologie associés à IPSec. Il est également important d'avoir des connaissances concernant Microsoft Windows Server™ 2003 dans les domaines suivants :
• Stratégie et filtres IPSec, actions de filtrage et listes de filtres • Concepts relatifs à Active Directory (notamment la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et d'autres objets Active Directory, les services de résolution de noms et utilisation d'une stratégie de groupe)
• Concepts d'authentification, comprenant le processus d'ouverture de session de Windows et le protocole Kerberos version 5
• Sécurité du système Windows (concepts de sécurité tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande).
Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les chapitres précédents de ce guide.
73
Conditions requises pour l'organisation Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans l'implémentation de cette solution, notamment :
• les cadres exécutifs ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau et du DNS (Domain Name System).
Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles. Cependant, il est important d'identifier un seul point de contact pour aider à coordonner les efforts des équipes d'organisation à travers les diverses phases du projet. Ce chapitre suppose également que vous avez satisfait les exigences répertoriées dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines », et le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », notamment la collecte d'informations à partir des hôtes, du réseau et d'Active Directory. Le recensement des exigences commerciales et l'obtention du support de la direction sont également abordés. Enfin, vous devez disposer d'un plan en place pour former les divers personnels d'assistance et de support aux nouveaux concepts, terminologies et technologies de cette solution. Cette solution affectant de nombreux domaines de l'organisation, le personnel de support doit être formé pour gérer tout problème apparaissant durant le déploiement.
Configuration requise pour l'infrastructure informatique Ce chapitre suppose l'existence de l'infrastructure informatique suivante :
• Un domaine Active Directory Windows Server 2003 fonctionnant en mode mixte ou natif. Cette
solution utilise des groupes universels pour l'application de l'objet Stratégie de groupe. Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de groupes globaux et locaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ipsec_whatsnew.asp.
Création de la conception d'isolation de serveurs et de domaines La conception de la solution dépend largement des exigences de l'entreprise et des informations collectées dans les chapitres précédents. Le chapitre 2, « Présentation de l'isolation de serveurs et de domaines », et l'annexe D, « Catégories de menaces informatiques », décrivent les composants de la
74
solution et identifient les menaces auxquelles elle peut ou non répondre. Le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », fournit des informations sur la manière de collecter des données de planification, telles que l'architecture réseau actuelle et les ressources d'hôtes sur le réseau. Ce chapitre utilise les informations et exigences collectées pour Woodgrove Bank, qui sont enregistrées en détail dans le fichier Business_Requirements.xls (disponible dans le dossier Tools and Templates). Reportezvous à ce fichier durant le processus de conception détaillé dans ce chapitre pour mieux comprendre les choix effectués pour la conception de la solution. Le processus de conception de la solution implique les principales tâches suivantes :
• Modélisation de groupes de base • Planification des groupes d'ordinateurs et d'accès au réseau • Création de groupes d'isolation supplémentaires • Modélisation des exigences de trafic réseau • Affectation de membres au groupe d'ordinateurs et au groupe d'accès réseau Les sections suivantes expliquent chacune de ces tâches.
Modélisation de groupes de base Pour la plupart des implémentations, il est recommandé de se baser sur un point de départ commun pour les groupes d'isolation initiaux. L'illustration suivante présente les deux groupes d'isolation initiaux à envisager.
Figure 4.1 Groupes d'isolation de base
Les groupes de base offrent des conteneurs logiques constituant un excellent point de départ pour la conception de groupes d'isolation.
75
Systèmes non approuvés Conceptuellement, le mieux est de commencer par les ordinateurs non détenus, ni gérés, voire ceux dont l'existence est inconnue du service informatique de l'organisation. Ces ordinateurs sont généralement désignés comme hôtes non approuvés ou non gérés et sont les premiers systèmes à identifier dans la conception. Ils ne feront pas partie de la solution car ils ne seront pas en mesure d'utiliser les stratégies IPSec affectées par le domaine. Exemples d'ordinateurs rattachés à ce groupe :
• Ordinateurs et périphériques non Windows. Les stations de travail Macintosh et UNIX ainsi que les assistants numériques personnels (PDA) peuvent ne pas disposer de fonctionnalités IPSec prêtes à l'emploi.
• Anciennes versions du système d'exploitation Windows. Les ordinateurs exploitant Microsoft Windows NT® version 4.0 et Windows 9x ne peuvent pas utiliser IPSec basé sur une stratégie de groupe.
• Ordinateurs Windows non rattachés à un domaine approuvé. Les ordinateurs autonomes ne
seront pas en mesure de s'authentifier à l'aide d'une approbation de domaine Kerberos dans Internet Key Exchange (IKE). Un ordinateur rattaché à un domaine non approuvé par la forêt utilisée comme limite sécurisée pour l'authentification IKE ne sera pas en mesure de participer à la solution d'isolation de domaines ou de serveurs.
• Autres clients VPN ou d'accès distant non Microsoft. Si un client de réseau privé virtuel (VPN)
IPSec non Microsoft est utilisé pour une solution d'accès distant d'une organisation, l'installation a probablement désactivé le service IPSec Windows natif. Si le service IPSec Windows natif ne peut pas être utilisé, l'hôte ne pourra pas participer à cette solution.
Même si le service IPSec Windows natif est actif, le client VPN doit permettre la communication IKE et IPSec de bout en bout via la connexion de tunnel VPN. Si IPSec de bout en bout ne fonctionne pas via la connexion VPN, il est possible de créer une exemption pour tous les sousréseaux IP utilisés pour l'accès distant. Lorsque ce client distant se reconnecte au réseau interne, il peut à nouveau participer à la solution d'isolation. Domaine d'isolation Le domaine d'isolation offre le premier conteneur logique pour les hôtes approuvés. Les hôtes de ce groupe utilisent une stratégie IPSec pour contrôler les communications entrantes et sortantes autorisées. Le terme domaine est utilisé dans ce contexte pour représenter une zone de confiance plutôt que pour suggérer un domaine Windows. Dans cette solution, les deux constructions sont très similaires car l'authentification de domaine Windows (Kerberos) est requise pour accepter les connexions entrantes d'hôtes approuvés. Cependant, de nombreux domaines (ou forêts) Windows peuvent être liés à des relations de confiance pour fournir un seul domaine d'isolation logique. Ils ne doivent donc pas être confondus. L'objectif des caractéristiques de communications du domaine d'isolation est de fournir les règles « normales » ou standards pour la majorité des ordinateurs de l'organisation. Ainsi, pour la plupart des implémentations, un domaine d'isolation contiendra le plus grand nombre d'ordinateurs. D'autres groupes d'isolation peuvent être créés pour la solution si leurs exigences de communication sont différentes de celles du domaine d'isolation. Conceptuellement, un domaine d'isolation est juste un type de groupe d'isolation.
76
Groupe de limite Presque toutes les organisations comprennent un certain nombre de stations de travail, ou serveurs, incapables de communiquer via IPSec. C'est par exemple probablement le cas des ordinateurs tels que les stations de travail Mac ou UNIX. Ces ordinateurs doivent souvent communiquer dans l'entreprise avec des hôtes approuvés du domaine d'isolation. Dans un monde idéal, tous les hôtes du réseau interne seraient en mesure d'être approuvés au même niveau et d'utiliser IPSec, et la conception serait plus simple. Cependant, dans la réalité, tous les systèmes d'exploitation n'offrent pas le même degré de prise en charge d'IPSec. Dans cette situation, il est recommandé de créer un groupe d'isolation (désigné comme groupe de limite dans ce guide) contenant les hôtes qui seront autorisés à communiquer avec des systèmes non approuvés. Ces hôtes seront exposés à un niveau de risque supérieur, car ils peuvent recevoir des communications entrantes provenant directement d'ordinateurs non approuvés. Les ordinateurs du groupe de limite sont des hôtes approuvés pouvant communiquer à la fois avec d'autres hôtes approuvés et avec des hôtes non approuvés. Les hôtes du groupe de limite tenteront de communiquer à l'aide d'IPSec en lançant une négociation IKE avec l'ordinateur d'origine. Si aucune réponse IKE n'est reçue dans les trois secondes, l'hôte communique en texte clair et tente alors d'établir des communications en texte clair sans IPSec. Les hôtes du groupe de limite peuvent avoir une adresse IP dynamique car ils utilisent une stratégie IPSec comme tout autre hôte approuvé du domaine d'isolation. Puisque ces hôtes du groupe de limite seront autorisés à communiquer avec des hôtes approuvés utilisant des communications réseau sécurisées par IPSec et des hôtes non approuvés utilisant les communications en texte clair, ils doivent être hautement sécurisés par d'autres moyens. La compréhension et l'atténuation de ce risque supplémentaire doivent constituer une part importante du processus de décision du placement éventuel d'un ordinateur dans le groupe de limite. Par exemple, la définition d'un processus de justification d'entreprise formel pour chaque ordinateur avant de convenir de le placer dans ce groupe peut aider à garantir que toutes les parties concernées comprennent pourquoi ce risque supplémentaire doit être pris. L'illustration suivante montre un exemple de processus pouvant faciliter une telle décision.
77
Figure 4.2 Organigramme décisionnel d'exemple de processus d'appartenance au groupe de limite
L'objectif de ce processus est de déterminer si le risque d'ajout d'un hôte au groupe de limite peut être atténué à un niveau acceptable pour l'organisation. En dernier ressort, il doit être supposé que si le risque ne peut pas être atténué, l'appartenance au groupe doit être refusée.
78
Création de listes d'exemptions Les modèles de sécurité d'isolation de serveurs et de domaines subissent tous quelques contraintes lorsqu'ils sont implémentés dans un environnement réel. Les principaux serveurs d'infrastructure tels que les contrôleurs de domaine et les serveurs DNS et DHCP (Dynamic Host Configuration Protocol) sont généralement disponibles pour tous les systèmes du réseau interne. Il est évident qu'ils doivent être sécurisés au maximum contre les attaques réseau. Cependant, comme ils sont disponibles pour tous les systèmes du réseau, et non simplement les membres du domaine, ces services de serveur ne peuvent pas exiger IPSec pour l'accès entrant, ni profiter de l'utilisation de la protection du mode de transport IPSec pour tout leur trafic. Parce qu'un délai de basculement en clair de trois secondes pour accéder à ces services, en particulier DNS, aurait un sérieux impact sur les performances de tout l'accès au réseau interne, ils ne sont pas candidats pour le groupe de limite. De plus, les hôtes approuvés exigent un accès au serveur DHCP pour obtenir une adresse IP (Internet Protocol) durant le démarrage de l'ordinateur ou lorsque le câble ou la carte réseau est branché(e) sur un ordinateur portable. Les hôtes approuvés exigent également DNS pour localiser les contrôleurs de domaine afin de pouvoir se connecter au domaine et recevoir des informations d'identification Kerberos. Par conséquent, une liste de serveurs et de services (protocoles) exempts d'utiliser IPSec sera requise pour qu'IPSec fonctionne correctement, ainsi que pour permettre à tous les hôtes internes de partager l'infrastructure commune de réseau interne. La liste d'ordinateurs qui ne peuvent pas être sécurisés avec IPSec est appelée liste d'exemptions et est implémentée dans chaque stratégie IPSec conçue. Il peut également y avoir d'autres serveurs sur le réseau auxquels des hôtes approuvés ne peuvent pas accéder à l'aide d'IPSec, qui doivent être ajoutés à la liste d'exemptions. En général, un hôte doit figurer dans la liste d'exemptions s'il répond à l'une des conditions suivantes :
• L'hôte est un ordinateur auquel des hôtes approuvés doivent accéder, mais qui ne possède pas d'implémentation IPSec compatible.
• L'hôte fournit des services pour des hôtes non approuvés et approuvés, mais ne répond pas aux critères d'appartenance du groupe d'isolation de limite.
• L'hôte est utilisé pour une application affectée par le délai de 3 secondes avant retour à la communication en clair ou par l'encapsulation IPSec du trafic de l'application.
• L'hôte prend en charge plusieurs milliers de clients simultanément et il a été déterminé qu'IPSec ne pouvait pas être utilisé en raison de l'impact sur les performances.
• L'hôte gère des hôtes approuvés de différents domaines d'isolation ne s'approuvant pas mutuellement.
• L'hôte est un contrôleur de domaine, car IPSec n'est actuellement pas pris en charge entre un
contrôleur de domaine et un membre de domaine. Cependant, les contrôleurs de domaine satisfont d'autres critères de cette liste et offrent également la stratégie IPSec aux membres du domaine et l'authentification Kerberos sur laquelle est basé le concept d'isolation.
• L'hôte gère des hôtes approuvés et non approuvés, mais il n'utilisera jamais IPSec pour sécuriser des communications avec des hôtes approuvés.
L'implémentation IPSec de Windows gère uniquement le filtrage statique, et non dynamique (ou avec état). Par conséquent, une exemption statique pour le trafic sortant est également une exemption statique pour le trafic entrant. Les hôtes exemptés disposent par conséquent d'un accès entrant non authentifié sur chaque hôte, approuvé ou non. Ainsi, le nombre d'hôtes exemptés doit être aussi restreint que possible, et ces hôtes doivent être gérés de près et renforcés autant que possible contre les attaques et infections. Pour aider à atténuer le risque d'attaques entrantes provenant d'hôtes de la liste d'exemptions, un parefeu de filtrage avec état basé sur l'hôte, tel que le Parefeu Windows, peut être utilisé. Windows XP Service Pack (SP) 2 a fourni des contrôles de stratégie de groupe basée sur le domaine pour la configuration du parefeu. Le Parefeu Windows prend également en charge la possibilité d'autoriser uniquement certains ordinateurs via le parefeu lors de la protection par IPSec, à l'aide du paramètre de stratégie « Parefeu Windows : autoriser à ignorer la sécurité IPSec 79
authentifiée ». Woodgrove Bank a choisi de ne pas implémenter le Parefeu Windows. Cependant, d'autres environnements peuvent trouver nécessaire d'atteindre des niveaux de sécurité élevés dans un domaine ou un groupe isolé. Pour plus d'informations, reportezvous au livre blanc « Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 » (Déploiement de paramètres du Parefeu Windows pour Microsoft Windows XP avec Service Pack 2) depuis le centre de téléchargement de Microsoft à l'adresse http://go.microsoft.com/fwlink/?LinkId=23277. Dans les organisations de taille importante, la liste d'exemptions peut s'allonger considérablement si toutes les exemptions sont implémentées par une stratégie IPSec pour l'ensemble du domaine ou pour toutes les forêts approuvées. Une longue liste produit un certain nombre d'effets indésirables sur chaque ordinateur recevant la stratégie, notamment :
• Elle réduit l'efficacité globale de l'isolation. • Elle alourdit la charge de gestion (suite aux fréquentes mises à jour). • Elle augmente la taille de la stratégie, ce qui signifie qu'elle consomme plus de mémoire et de ressources processeur, ralentit le débit du réseau, et allonge le délai de téléchargement et d'application de la stratégie.
Pour maintenir le nombre d'exemptions aussi bas que possible, vous avez plusieurs possibilités :
• N'utilisez pas d'exemption si les communications peuvent résister au délai de 3 secondes avant retour à la communication en clair. Cette option ne s'applique pas aux contrôleurs de domaine.
• Considérez avec soin les exigences de communications de chaque groupe d'isolation, en
particulier des groupes serveur uniquement. Ils peuvent ne pas avoir à communiquer avec chaque exemption de la stratégie de niveau domaine des clients.
• Consolidez les fonctions de serveur. Si plusieurs services exempts peuvent résider sur la même adresse IP, le nombre de filtres sera réduit.
• Consolidez des hôtes exemptés sur le même sousréseau. Lorsque le volume de trafic réseau l'autorise, les serveurs peuvent résider sur un sousréseau exempté, au lieu d'utiliser des exemptions pour chaque adresse IP.
Comme pour la définition du groupe de limite, un processus formel est souhaitable pour approuver les hôtes ajoutés à la liste d'exemptions. Reportezvous à l'organigramme décisionnel de l'illustration précédente comme modèle pour le traitement des demandes d'exemptions.
Planification des groupes d'accès aux ordinateurs et au réseau Le domaine d'isolation et chaque groupe d'isolation doivent avoir des spécifications claires et complètes des exigences de sécurité réseau. La feuille de calcul Business_Requirements.xls du dossier Tools and Templates fournit un modèle de la manière dont les exigences peuvent être référencées. Une fois les exigences entrantes et sortantes décrites, vous pouvez concevoir les mécanismes d'implémentation des contrôles d'accès. À ce stade du processus, il est conseillé de commencer à recenser les nouveaux groupes Active Directory qui seront requis pour répondre aux exigences de groupe d'isolation. Pour chaque groupe d'isolation, vous devrez créer jusqu'à trois groupes Active Directory spécialisés. La section suivante explique le rôle de chacun de ces groupes.
80
Groupes d'ordinateurs Chaque groupe d'isolation nécessitera la création d'un groupe d'ordinateurs qui sera utilisé pour contenir les membres du groupe d'isolation. Ceci est requis car les exigences de sécurité d'un groupe d'isolation sont remplies par plusieurs types de paramètres de sécurité dans des objets Stratégie de groupe affectés dans le domaine. Par exemple, cette solution utilise un filtrage de groupe de sécurité sur les objets Stratégie de groupe pour fournir une stratégie IPSec aux ordinateurs d'un groupe d'isolation particulier. Les comptes d'ordinateurs membres du groupe d'ordinateurs se verront affecter la stratégie IPSec associée lors du traitement de l'objet Stratégie de groupe. Ceci évite d'avoir à changer ou créer une nouvelle structure d'unité d'organisation (UO) basée sur l'appartenance à un groupe d'isolation pour appliquer les objets Stratégie de groupe corrects. Si la structure d'UO peut être modifiée pour refléter l'appartenance au groupe d'isolation, ces groupes de sécurité d'ordinateurs ne sont pas requis pour contrôler l'application de la stratégie de groupe. Tableau 4.1 : Groupes d'ordinateurs Woodgrove Bank Nom du groupe d'ordinateurs
Description
CG_IsolationDomain_Computers
Ce groupe universel contiendra tous les ordinateurs faisant partie du domaine d'isolation.
CG_BoundaryIG_Computers
Ce groupe contiendra tous les ordinateurs autorisés à accepter une communication de systèmes non approuvés.
Groupes d'accès au réseau L'utilisation d'IPSec et de Kerberos seuls fournit une limite d'authentification approuvée et non approuvée. Pour aider à différencier ce groupe de tout autre, ce guide désigne ces groupes en tant que groupes d'accès réseau. Vous pouvez créer deux types de groupes d'accès réseau : Autoriser et Refuser. Ces groupes contrôlent la capacité d'autres systèmes approuvés à autoriser ou refuser explicitement l'accès. Ce contrôle est obtenu en utilisant le droit d'utilisateur « Interdire l'accès à cet ordinateur à partir du réseau » (REFUSER) ou « Accéder à cet ordinateur à partir du réseau » (AUTORISER) dans la stratégie de groupe. Techniquement, ce contrôle d'accès par droit d'utilisateur s'applique uniquement aux services réseau recevant des informations d'identification de connexion pour authentifier le compte pour l'ouverture de session réseau. Le « compte » peut être un compte d'ordinateur, d'utilisateur ou de service. Lorsque la stratégie IPSec est configurée pour protéger tout le trafic, IKE confirmera que l'ordinateur distant possède un droit de connexion réseau. Par conséquent, le droit de connexion réseau contrôle désormais la possibilité pour un ordinateur distant d'établir des connexions protégées par IPSec. Une fois ce contrôle d'accès de niveau IP vérifié, les protocoles de niveau supérieur normaux (par exemple, le partage de fichiers) authentifient en général l'utilisateur, ce qui évalue à nouveau les droits de connexion réseau de l'identité d'utilisateur. Enfin, les autorisations spécifiques au service (telles que les listes de contrôle d'accès au partage de fichiers) sont évaluées à l'aide de l'identité de l'utilisateur. Pour plus d'informations, reportezvous au diagramme Protection renforcée avec l'isolation logique dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ». Par défaut, le droit d'utilisateur AUTORISER contient le groupe Tout le monde, qui autorise tous les utilisateurs et ordinateurs authentifiés à accéder à l'ordinateur. Durant l'implémentation de cette solution, le groupe Tout le monde sera remplacé via l'affectation de droits d'utilisateur de stratégie de groupe par des groupes d'accès réseau contenant des ordinateurs ou utilisateurs et groupes spécifiques, selon les exigences de l'organisation. De même, le droit d'utilisateur REFUSER
81
contiendra des ordinateurs non supposés disposer d'un accès entrant protégé par IPSec. Bien qu'il soit possible d'utiliser un seul groupe pour contenir les comptes d'utilisateurs et d'ordinateurs, Microsoft recommande l'utilisation de groupes distincts, un pour les utilisateurs et un pour les ordinateurs. Cette approche améliore la possibilité de gérer et prendre en charge ces stratégies et groupes en continu. La configuration de l'affectation des droits d'utilisateur AUTORISER et REFUSER complète les directives fournies par les guides de sécurité des platesformes Windows antérieures, qui ne traitaient pas spécifiquement de l'authentification des ordinateurs exigée par IPSec. Les groupes d'accès réseau peuvent implémenter les exigences suivantes :
• Bloquer l'accès réseau aux serveurs sensibles à partir d'hôtes limites ou d'hôtes approuvés situés dans des zones publiques.
• Limiter l'accès aux serveurs des cadres supérieurs aux seuls ordinateurs clients utilisés par ces cadres.
• Isoler les hôtes approuvés d'un projet de recherche et développement de tous les autres hôtes approuvés du domaine.
Dans le scénario Woodgrove Bank, une exigence commerciale limite la quantité de nouveau matériel informatique pouvant être acheté au cours d'une année. Un serveur d'impression était requis pour permettre à la fois aux hôtes approuvés et non approuvés d'imprimer. Bien que Woodgrove aurait préféré acheter un nouveau serveur que seuls les ordinateurs non approuvés utiliseraient pour l'impression, il a été décidé qu'un seul serveur pourrait satisfaire les besoins des deux types d'hôtes. La société a par conséquent créé un serveur limite comme serveur d'impression. Le serveur d'impression étant soumis à un risque plus élevé d'infections et d'attaques d'ordinateurs non approuvés, le reste des hôtes approuvés devaient bloquer l'accès entrant à partir de ce serveur. Les hôtes approuvés devaient toujours pouvoir établir des connexions sortantes avec le serveur d'impression au besoin. En conséquence, Woodgrove a déterminé la nécessité d'un groupe d'accès réseau REFUSER pour implémenter cette exigence. À ce stade du processus de conception, l'affectation de membres au groupe d'accès réseau n'est pas requise. Il convient juste d'identifier et de documenter les groupes d'accès réseau requis par la conception. Les concepteurs de Woodgrove Bank ont identifié la nécessité de créer le groupe d'accès réseau suivant : Tableau 4.2 : Groupes d'accès réseau de Woodgrove Bank Nom du groupe d'accès réseau
Description
DNAG_IsolationDomain_Computers
Ce groupe comprend tout compte d'ordinateur de domaine non autorisé à établir des connexions entrantes protégées par IPSec avec tous les hôtes approuvés du domaine d'isolation.
Création de groupes d'isolation supplémentaires À ce stade du processus de conception, il existe deux groupes d'isolation : le groupe Domaine d'isolation et le groupe de limite. Si les exigences commerciales de votre organisation peuvent être satisfaites par cette conception, vous pouvez passer à la section suivante de ce chapitre pour définir les modèles de trafic pour ces deux groupes d'isolation. Cependant, si votre organisation exige que certains hôtes approuvés disposent d'une protection du trafic ou de contrôles d'accès réseau entrant ou sortant différents, des groupes d'isolation seront requis pour chaque série d'exigences.
82
L'objectif de cette section est de vous aider à comprendre quand des groupes supplémentaires seront requis. La première chose à faire consiste à identifier les ordinateurs ayant des exigences de protection du trafic ou d'isolation spécifiques qui ne sont pas satisfaites par les paramètres du domaine d'isolation. L'objectif doit être de maintenir le nombre de ces hôtes aussi réduit que possible, car chaque nouveau groupe augmente la complexité de la conception globale, et complique par conséquent sa prise en charge et sa gestion. Citons parmi les exemples types d'exigences pouvant mener à la création d'un nouveau groupe :
• Exigences de chiffrement • Accès hôte ou utilisateur limité requis au niveau du réseau • Exigences de protection ou de flux de trafic réseau sortant ou entrant différentes du domaine d'isolation
Bien souvent, l'accès entrant aux serveurs contenant des données sensibles est limité à un sous ensemble d'hôtes approuvés du domaine. Dans d'autres cas, les hôtes approuvés peuvent ne pas être autorisés à établir des connexions sortantes vers des ordinateurs non approuvés pour réduire le risque de fuite d'informations ou pour garantir le respect des réglementations en matière de protection du trafic réseau. Par exemple, dans le scénario Woodgrove Bank, les concepteurs ont identifié des exigences pouvant uniquement être satisfaites par la création des deux groupes d'isolation supplémentaires suivants :
• Le groupe de chiffrement contenait un petit groupe de serveurs d'application contenant des
données très sensibles et exigeant le niveau de protection maximal. Seul un sousensemble spécifique de clients approuvés seraient autorisés à effectuer une connexion entrante sur ces serveurs. Tout le trafic réseau avec ces serveurs exigeait un chiffrement de niveau 128 bits conforme aux réglementations fédérales américaines en matière de protection des données financières. Enfin, ces serveurs n'étaient pas autorisés à établir des connexions sortantes avec des hôtes non approuvés, ni à recevoir des connexions entrantes d'hôtes limites.
• Le groupe Sans basculement était requis pour un certain nombre d'hôtes approuvés du domaine d'isolation dont les communications réseau avec des systèmes non approuvés devaient être restreintes.
Bien que le second groupe n'exige aucun basculement, il ne possède pas l'ensemble d'exigences complet des serveurs d'applications. Ainsi, ces deux séries d'exigences différentes indiquaient que deux groupes d'isolation supplémentaires étaient requis. Le nombre total de groupes pour Woodgrove Bank passait donc à quatre. L'illustration suivante montre comment ces groupes se présentaient dans la conception finale des groupes d'isolation de Woodgrove Bank :
83
Figure 4.3 Conception finale des groupes de Woodgrove Bank
Les quatre groupes suivants exigent une stratégie pour atteindre les exigences de conception :
• Domaine d'isolation. Il s'agit du groupe par défaut pour tous les ordinateurs approuvés. • Groupe d'isolation de limite. Ce groupe est affecté aux ordinateurs auxquels des hôtes non approuvés doivent pouvoir accéder.
• Groupe d'isolation de chiffrement. Ce groupe autorise uniquement les communications via un chemin chiffré approuvé.
• Groupe d'isolation sans basculement. Ce groupe contient des ordinateurs ayant une exigence de sécurité supérieure qui les empêche d'initier des communications avec des hôtes non approuvés directement.
Woodgrove Bank ayant identifié deux groupes supplémentaires exigeant des stratégies IPSec, elle a défini des groupes d'ordinateurs supplémentaires pour contrôler l'application de ces nouvelles stratégies. Tableau 4.3 : Groupes d'ordinateurs Woodgrove Bank supplémentaires Nom du groupe d'ordinateurs
Description
CG_NoFallbackIG_Computers
Ce groupe contient tous les ordinateurs non autorisés à communiquer en clair.
CG_EncryptionIG_Computers
Ce groupe contient tous les ordinateurs devant utiliser un chiffrement.
En conséquence, Woodgrove a déterminé que des groupes d'accès réseau seraient requis pour autoriser l'accès entrant dans le sousensemble d'hôtes approuvés. Les concepteurs de Woodgrove Bank ont créé les groupes d'accès réseau suivants : Tableau 4.4 : Groupes d'accès réseau de Woodgrove Bank
84
Nom du groupe d'accès réseau
Description
ANAG_EncryptedResourceAccess_Users
Ce groupe comprend tous les utilisateurs autorisés à accéder aux serveurs du groupe d'isolation de chiffrement.
ANAG_EncryptedResourceAccess_Computers
Ce groupe contient tous les ordinateurs autorisés à avoir un accès réseau entrant sur les serveurs du groupe d'isolation de chiffrement.
DNAG_EncryptionIG_Computers
Ce groupe comprend des groupes de comptes d'ordinateur dont l'accès doit être refusé sur les hôtes du groupe d'isolation de chiffrement.
Collecte des exigences de trafic réseau À ce stade du processus de conception, vous devez documenter les exigences de trafic de communications qui seront autorisées à passer entre les groupes, ainsi que la forme que prendront les communications. Il existe de nombreuses manières de documenter les exigences de trafic des groupes. Cependant, l'équipe de support informatique de Microsoft a découvert, avec l'expérience, que la création d'un diagramme constituait la méthode la plus efficace pour communiquer des exigences précises. L'illustration suivante décrit les chemins de communications généralement autorisés entre les groupes de base, les hôtes non approuvés et les listes d'exemptions. Pour simplifier ce modèle, les listes d'exemptions figurent sous la forme d'un seul regroupement. C'est généralement le cas pour les services d'infrastructure, tels que les contrôleurs de domaine ou les serveurs DNS. Cependant, les groupes d'isolation peuvent avoir comme exigence commerciale d'exempter des ordinateurs spécifiques juste pour les ordinateurs de ce groupe. Dans ce cas, le groupe d'isolation contiendrait alors une liste d'exemptions supplémentaire des ordinateurs devant être exemptés en plus des exemptions communes. Microsoft recommande de restreindre au maximum les entrées de la liste d'exemptions, car elles exemptent explicitement des systèmes de participer à l'infrastructure IPSec. Dans l'illustration, toutes les flèches noires continues utilisent IPSec pour leurs communications ; les lignes en pointillés indiquent des communications autorisées sans IPSec. Une ligne en tirets gras indique qu'une stratégie IPSec est affectée aux ordinateurs de ce groupe.
85
Figure 4.4 Chemins de communications généralement autorisés pour les groupes d'isolation de base
Le tableau suivant répertorie les chemins de communications autorisés pour le trafic parmi les groupes de base, les systèmes non sécurisés et les listes d'exemptions : Tableau 4.5 : Options de communication autorisées pour les groupes d'isolation de base Chemin d'accès
De
À
Bidirectionnel
Essayer IKE/IPSec
Basculement
Chiffrer
1
DI
EX
Oui
Non
Non
Non
2
DI
LI
Oui
Oui
Non
Non
3
DI
NA
Non
Oui
Oui
Non
4
LI
EX
Oui
Non
Non
Non
5
LI
NA
Non
Oui
Oui
Non
6
NA
LI
Non
Non
Non
Non
7
NA
EX
Oui
Non
Non
Non
Le tableau précédent enregistre les exigences de communications pour chaque chemin de communications autorisé dans la conception initiale de groupes d'isolation. La liste suivante décrit chaque colonne :
• Chemin. Numéro affecté au chemin de communications illustré dans le diagramme de groupe. • De. Groupe contenant les initiateurs du trafic. • À. Groupe contenant les répondeurs qui seront contactés via le chemin de communication autorisé.
86
• Bidirectionnel. Indique si le chemin autorise l'inversion des rôles de l'initiateur et du répondeur de sorte que le trafic peut partir du groupe De ou À.
• Essayer IKE/IPSec. Indique si ce chemin tente d'utiliser IPSec pour sécuriser les communications. • Basculer. Indique si les communications peuvent renoncer à utiliser IPSec si la négociation IKE n'aboutit pas.
• Chiffrer. Indique si ce chemin exige le chiffrement des communications à l'aide d'un algorithme défini dans la stratégie IPSec.
Les formes abrégées des noms de groupe ont été utilisées pour garder les informations du tableau aussi concises que possible. En utilisant cette forme de documentation, il est possible de créer une représentation très concise des communications de la solution. En supposant que tout le trafic réseau est rejeté s'il n'est pas spécifiquement identifié dans ce tableau, le processus d'identification du trafic qui sera protégé dans le cadre de la solution devient bien plus clair. L'exemple de l'illustration précédente décrit chacun des chemins autorisés suivants :
• Les chemins de trafic 1, 4 et 7 illustrent les communications réseau spécifiquement autorisées pour tous les hôtes répertoriés par les listes d'exemptions de leur stratégie IPSec. Les exemptions spécifiques peuvent être différentes pour les groupes d'isolation.
• Le chemin de trafic 2 représente les communications entre le domaine d'isolation et les groupes
Limite. Ce chemin tente d'utiliser IPSec pour protéger le trafic. Le trafic peut exiger un chiffrement, selon les exigences de sécurité. Si la négociation IKE échoue, les communications échoueront car il n'y a pas d'option de communication en texte clair dans ce cas.
• Le chemin 3 montre que les hôtes du domaine d'isolation sont en mesure d'initier des
communications avec des hôtes non approuvés. Ceci est possible parce que la stratégie de ce groupe autorisera les hôtes du domaine d'isolation à communiquer en texte clair en l'absence de réponse à la demande de négociation IKE initiale. Les systèmes non approuvés qui tentent d'établir des connexions non IPSec avec des hôtes approuvés sont bloqués par les filtres entrants IPSec.
• Les chemins de trafic 5 et 6 décrivent les communications autorisées entre le groupe de limite et
les systèmes non approuvés. Le chemin 4 montre que le groupe de limite est autorisé à établir des communications sortantes avec des hôtes non approuvés en clair. Si la négociation IKE ne reçoit pas de réponse, l'hôte revient à des communications en clair. Le chemin 5 couvre le trafic initié à partir des hôtes non approuvés vers le groupe de limite. Bien que cette flèche ressemble au chemin 4, les détails du tableau montrent que les hôtes non approuvés ne tentent pas de négociation IKE avec le groupe de limite. Ils utilisent des connexions TCP/IP en clair.
Une fois les communications de base documentées, des groupes supplémentaires peuvent être ajoutés au plan général et leurs exigences de communications enregistrées de la même manière. Par exemple, les deux groupes supplémentaires requis par le scénario Woodgrove Bank ont mené à un diagramme de communications plus complexe, comme le montre l'illustration suivante.
87
Figure 4.5 Chemins de communications autorisés par Woodgrove Bank pour les groupes d'isolation
Le tableau suivant répertorie les chemins de communications autorisés pour le trafic dans les groupes supplémentaires du scénario Woodgrove Bank. Tableau 4.6 : Options de communication autorisées pour les groupes d'isolation supplémentaires Chemin d'accès
De
À
Bidirectionnel
Essayer IKE/IPSec
Basculement
Chiffrer
8
CR
EX
Oui
Non
Non
Non
9
CR
DI
Oui
Oui
Non
Oui
10
CR
SB
Oui
Oui
Non
Oui
11
CR
LI
Non
Oui
Non
Oui
12
SB
DI
Oui
Oui
Non
Non
13
SB
EX
Oui
Non
Non
Non
14
SB
LI
Oui
Oui
Non
Non
L'exemple de l'illustration précédente décrit dans le tableau explique chacun des chemins supplémentaires autorisés suivants :
• Les chemins 8 et 13 correspondent aux communications en clair pour tout le trafic exempté. • Les chemins 9 et 10 montrent les communications IPSec chiffrées par ESP (Encapsulating
Security Payload) requises entre les groupes Chiffrement, Sans basculement et Domaine d'isolation. Si la négociation IKE ne parvient pas à sécuriser la communication par chiffrement, la tentative de communication échoue.
88
• Le trafic du chemin 11 est légèrement différent car il autorise uniquement que des communications soient initiées à partir du groupe de chiffrement vers le groupe de limite, et non l'inverse. Ceci est dû au fait que Woodgrove Bank a placé des données sensibles dans le groupe de chiffrement et ne veut pas que ces données soient exposées à des ordinateurs auxquels accèdent directement des ressources non approuvées.
• Les chemins de trafic 12 et 14 pourraient être implémentés par le mode de transport IPSec AH ou IPSec ESP, qui est authentifié mais sans chiffrement (ESPNull).
Comme le montre cet exemple, l'ajout de groupes peut avoir un impact exponentiel sur la complexité de la solution. C'est pourquoi il est recommandé de limiter autant que possible le nombre de groupes, en particulier durant les premières étapes d'un déploiement, lorsque la plupart des changements sont introduits.
Affectation de membres au groupe d'ordinateurs et au groupe d'accès réseau Une fois les exigences de trafic détaillées et décrites dans la conception, la tâche suivante consiste à identifier les hôtes qui seront les membres des groupes d'ordinateurs ou des groupes d'accès réseau. Comme mentionné précédemment, les groupes d'ordinateurs sont utilisés dans cette solution pour appliquer l'objet Stratégie de groupe contenant la stratégie IPSec associée. Une fois déterminé qu'un ordinateur doit appartenir à un groupe d'isolation donné, le compte de cet ordinateur est ajouté au groupe d'ordinateurs de ce groupe d'isolation. Pour le domaine d'isolation, cette étape n'est pas nécessaire, car tous les ordinateurs du domaine appartiennent implicitement au groupe d'ordinateurs du domaine d'isolation. L'appartenance à un groupe d'accès réseau sera basée sur l'autorisation entrante que le groupe d'accès réseau implémente. Par exemple, s'il existe un groupe d'accès réseau pour limiter la communication d'un serveur donné vers un ensemble connu de clients, les comptes d'ordinateur client doivent être placés dans le groupe d'accès réseau approprié. Les groupes d'accès réseau ne sont créés qu'en fonction des besoins et ne possèdent par conséquent aucune configuration par défaut. Appartenance au groupe d'ordinateurs Il est important qu'un hôte ne soit pas représenté dans plusieurs groupes d'ordinateurs, car le groupe d'ordinateurs sert à définir les objets Stratégie de groupe applicables. Bien qu'il soit théoriquement possible de modifier les stratégies pour permettre à un hôte d'appartenir à plusieurs groupes d'ordinateurs, la complexité d'une telle approche rendrait rapidement la solution insoutenable. La tâche de détermination des membres d'un groupe d'ordinateurs n'est généralement pas compliquée, mais elle peut être longue. Il est conseillé d'utiliser les informations générées à partir d'un audit tel que celui effectué dans le chapitre 3 de ce guide, « Détermination de l'état actuel de votre infrastructure informatique », pour placer chaque hôte dans un groupe d'ordinateurs en fonction du groupe d'isolation dont il est membre. Vous pouvez déterminer ce placement en ajoutant une colonne Groupe pour y noter l'appartenance à un groupe d'ordinateurs pour la conception finale, comme indiqué dans le tableau suivant : Tableau 4.7 : Exemple de données collectées sur l'hôte Nom de l'hôte
Config. matérielle conforme ?
Config. logicielle conforme ?
Configuration requise
89
Détails
Coût prévisionnel
Groupe
HOST NYC001
Non
Non
Mises à niveau matérielle et logicielle
Le système d'exploitation actuel est Windows NT 4.0. Ancien matériel non compatible avec Windows XP.
SERVER LON001
Oui
Non
Intégrer Aucun logiciel domaine antivirus approuvé, présent. mettre à niveau de NT 4 vers Windows 2000 ou ultérieur
$XXX.
DI
$XXX.
CR
Appartenance au groupe d'accès réseau La dernière étape de ce processus de conception consiste à définir les membres des groupes d'accès réseau identifiés précédemment dans ce chapitre. Bien qu'un hôte approuvé ne doive appartenir qu'à un seul groupe d'ordinateurs, il est possible qu'il soit membre de plusieurs groupes d'accès réseau. Essayez d'utiliser aussi peu de groupes d'accès réseau que possible pour limiter la complexité de la solution. Lors de l'affectation de comptes d'utilisateurs à un groupe d'accès réseau, décidez du degré souhaité de contrôle d'accès. Pour qu'une ressource utilisant déjà des autorisations de fichiers et de partage standards assure le niveau correct de contrôle, le moyen le plus simple de définir l'appartenance serait d'attribuer l'appartenance du groupe d'accès réseau de l'utilisateur au groupe Utilisa. du domaine de chaque domaine approuvé de la forêt devant accéder à la ressource. Cette approche rétablit pratiquement le comportement de la valeur par défaut d'origine d'Utilisateurs authentifiés, sans inclure de comptes d'utilisateurs locaux. Si des comptes d'utilisateurs ou de services locaux sont requis, un objet Stratégie de groupe basé sur le domaine n'est peutêtre pas la meilleure approche pour configurer des droits de connexion réseau AUTORISER et REFUSER. L'affectation de droits d'utilisateur AUTORISER et REFUSER ne fusionne pas les paramètres parmi plusieurs objets Stratégie de groupe. Par conséquent, cet ordinateur ne doit pas être autorisé à posséder le droit AUTORISER et REFUSER de l'objet Stratégie de groupe basé sur le domaine, et doit utiliser un objet Stratégie de groupe local personnalisé. Si l'objet Stratégie de groupe basé sur le domaine qui fournit l'affectation de stratégie IPSec est différent de l'objet Stratégie de groupe utilisé pour fournir les droits de connexion réseau, l'objet Stratégie de groupe basé sur le domaine pour l'affectation de stratégie IPSec peut encore être utilisé. De plus, décidez comment implémenter les exigences d'accès entrant à l'aide d'un groupe d'accès réseau AUTORISER ou REFUSER, voire les deux. Le choix du type de groupe d'accès réseau à créer est basé exclusivement sur le comportement attendu et sur ce qui minimise l'effort administratif. Il peut s'avérer utile d'avoir un groupe d'accès réseau REFUSER préexistant mais vide pour les utilisateurs et un groupe d'accès réseau REFUSER pour les ordinateurs possédant déjà le droit « Interdire l'accès à cet ordinateur à partir du réseau » de l'objet Stratégie de groupe. Dans les scénarios de sécurité élevée, l'appartenance des groupes d'accès réseau utilisateur peut être affectée à des utilisateurs ou groupes spécifiques. Si cette méthode est utilisée, il faut comprendre que les utilisateurs qui ne sont pas membres de ce groupe verront leur accès à l'ordinateur bloqué sur le réseau, même s'ils sont membres du groupe des administrateurs locaux et disposent d'un contrôle total sur toutes les autorisations de partage et de fichiers.
90
Pour le scénario Woodgrove Bank, l'appartenance à NAG_EncryptedResourceAccess_Users a été affectée à Utilisateurs du domaine et enregistrée comme le montre le tableau suivant : Tableau 4.8 : Groupes d'accès réseau de Woodgrove Bank avec appartenance définie Nom du groupe d'accès réseau
Appartenance
Description
ANAG_EncryptedResourceAcces s_Users
User7
Ce groupe correspond à tous les utilisateurs autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
ANAG_EncryptedResourceAcces s_Computers
IPSSQLDFS01 IPSSQLDFS02 IPSSTXP05
Ce groupe contient tous les ordinateurs autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
DNAG_EncryptionIG_Computers
CG_BoundaryIG_Computers
Ce groupe contient tous les ordinateurs non autorisés à établir des connexions entrantes protégées par IPSec avec les ordinateurs du groupe d'isolation de chiffrement.
Remarque : l'appartenance à un groupe d'accès réseau ne détermine pas le niveau de protection du trafic IPSec. Les paramètres de stratégie IPSec commandent les méthodes de sécurité utilisées pour protéger le trafic et sont indépendants de l'identité authentifiée par IKE. La négociation IKE est uniquement consciente de la réussite ou de l'échec du processus d'authentification de l'identité de l'ordinateur Kerberos. Elle ne peut pas implémenter une stratégie « chiffrer si user3 se connecte » ou « chiffrer si hôte approuvé IPSSQLDFS01 ou IPSSQLDFS02 ». L'administrateur doit obtenir le comportement attendu en utilisant une stratégie IPSec pour les serveurs du groupe d'isolation de chiffrement exigeant un « chiffrement pour toute connexion entrante d'hôte approuvé » et de manière similaire un « chiffrement pour toute connexion sortante vers un hôte approuvé ». Jusqu'ici, ce processus de conception n'a pas revu les détails de la conception de stratégie IPSec. Le chapitre 5 fournira des détails relatifs à la conception de la stratégie IPSec pour Woodgrove. À ce stade du processus de conception, vous avez terminé les tâches requises pour transformer vos exigences en conception préliminaire. Cette section vous a aidé à mettre au point la conception et la documentation requises pour la création des stratégies IPSec. Limitations pouvant affecter votre conception Les problèmes suivants peuvent affecter votre conception et doivent par conséquent être pris en compte avant que votre conception puisse être considérée comme terminée :
• Nombre maximal de connexions simultanées par des hôtes uniques sur des serveurs
utilisant IPSec. Le nombre de connexions simultanées est un facteur crucial pour déterminer si une implémentation IPSec sur des serveurs d'usage élevé se déroulera sans problèmes ou surchargera le processeur avec le traitement IKE ou IPSec. Chaque négociation IKE réussie établit des associations de sécurité occupant environ 5 kilooctets de mémoire de mode utilisateur. Des ressources processeur sont requises pour maintenir les états d'association de sécurité IKE courants avec tous les homologues connectés simultanément. Pour plus d'informations sur
91
l'évolutivité, consultez le livre blanc « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) à l'adresse www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx.
• Limitation de la taille de jeton Kerberos maximale pour les hôtes utilisant IPSec. Il existe une
limite pratique d'environ 1 000 groupes par utilisateur, et si cette valeur est dépassée, l'application de l'objet Stratégie de groupe peut ne pas se produire. Pour plus d'informations à ce sujet, consultez les articles 327825 de la Base de connaissances Microsoft « New Resolution for Problems That Occur When Users Belong to Many Groups » (Nouvelle résolution de problèmes se produisant lorsque des utilisateurs appartiennent à de nombreux groupes) à l'adresse http://support.microsoft.com/?kbid=327825 et 306259 « Members of an Extremely Large Number of Groups Cannot Log On to the Domain » (Des membres d'un nombre très élevé de groupes ne peuvent pas se connecter au domaine) à l'adresse http://support.microsoft.com/?kbid=306259.
Bien que ces articles mentionnent des utilisateurs spécifiquement, le problème existe également pour les comptes d'ordinateurs, car le paramètre Kerberos MaxTokenSize s'applique aussi aux comptes d'ordinateurs. Bien que cette limite soit rarement atteinte dans la plupart des implémentations, vous devez être conscient de ce problème si vous décidez de placer un ordinateur (peutêtre un client) dans un grand nombre de groupes d'accès réseau. Si votre conception sera affectée par ces problèmes, vous devrez revisiter le processus de conception pour y répondre. Par exemple, vous pouvez répondre au problème du nombre maximal de connexions simultanées en déplaçant un serveur très lourdement chargé dans les listes d'exemptions. Vous pouvez répondre à la limitation de la taille de jeton Kerberos maximale en réduisant le nombre de groupes d'accès réseau que votre conception utilisera. Si ces limitations n'affecteront pas votre conception, la tâche suivante consiste à considérer la manière dont la conception sera déployée dans l'organisation.
Méthodes d'implémentation de groupe Une fois la conception initiale créée, vous devez considérer attentivement le processus de déploiement d'IPSec. Ce n'est que dans les environnements les plus petits qu'il est possible de déployer simplement les stratégies sur tous les ordinateurs et d'espérer un fonctionnement sans heurts d'IPSec avec un impact relativement faible sur les utilisateurs. Dans les organisations étendues, la complexité et le risque nécessitent un déploiement progressif. En utilisant une telle approche, l'organisation peut aider à atténuer le risque associé à un tel changement fondamental de l'environnement. Sans planification soignée, les appels au support technique et la perte de productivité augmenteront rapidement le coût du déploiement. Il existe différentes manières de déployer IPSec dans une organisation. Les facteurs suivants aident à déterminer la méthode de déploiement :
• les états de départ et de fin de l'environnement ; • la complexité de configuration des groupes ; • la complexité de la structure de domaines ; • la tolérance de risque de l'organisation ; • les exigences de sécurité.
92
Les méthodes de déploiement suivantes ne comprennent pas tout, mais elles sont des exemples d'approches possibles. Vous pouvez également utiliser une combinaison de ces approches. En général, les organisations ne doivent pas déployer initialement des stratégies IPSec limitant ou bloquant la communication, afin de garantir qu'elles disposent de suffisamment de temps pour résoudre les problèmes et réduire la coordination de gestion dans les environnements complexes. Quelle que soit l'approche choisie pour déployer IPSec, il est fortement recommandé de tester soigneusement le scénario de déploiement dans un environnement de laboratoire, y compris la séquence et le déroulement spécifiques des étapes de déploiement et des changements de stratégie. De plus, utilisez une action de filtre demandant une fonctionnalité IPSec, mais acceptant la communication en texte clair en utilisant la fonction Communiquer en texte clair. Cette approche aidera à minimiser l'impact du déploiement initial. Une fois le déploiement terminé, passez à des modes de fonctionnement plus sécurisés exigeant que le trafic soit protégé par IPSec. Pour un déploiement dans un environnement de production, un pilote initial est fortement recommandé à chaque grande phase du déploiement. Il est particulièrement important d'analyser l'impact des changements de stratégie IPSec, car ils prendront effet dans l'environnement de production suite aux durées de vie des tickets Kerberos, et aux intervalles d'interrogation de stratégie de groupe et de stratégie IPSec. Il est conseillé de mettre en œuvre un processus formel de contrôle des modifications indiquant les stratégies et les critères d'annulation pour s'assurer que toutes les organisations informatiques concernées sont conscientes du changement et de son impact, et savent comment coordonner les commentaires vers les décideurs.
Déployer par groupe La méthode Déployer par groupe utilise des stratégies IPSec entièrement définies, mais contrôle l'application des stratégies par l'utilisation de groupes et de listes de contrôle d'accès sur les objets Stratégie de groupe fournissant les stratégies. Dans la méthode Déployer par groupe, les stratégies IPSec sont créées dans Active Directory dans leur configuration finale. Toutes les exemptions et tous les sousréseaux sécurisés sont définis et les actions de filtre appropriées sont activées dans chaque stratégie IPSec. Les administrateurs de stratégie IPSec créent alors des objets Stratégie de groupe pour chaque stratégie IPSec. De plus, des groupes d'ordinateurs sont créés dans le domaine pour gérer et appliquer ces nouveaux objets Stratégie de groupe. Les listes de contrôle d'accès des objets Stratégie de groupe sont modifiées pour que les membres du groupe Utilisateurs authentifiés n'aient plus le droit « Appliquer ». Les groupes d'utilisateurs de l'administrateur approprié pour la gestion et l'application de la stratégie reçoivent également des droits sur l'objet Stratégie de groupe. Les stratégies IPSec appropriées sont ensuite affectées à l'objet Stratégie de groupe correspondant. De plus, l'objet Stratégie de groupe est lié à l'objet approprié dans Active Directory. À ce stade, aucun des ordinateurs de l'environnement ne doit recevoir la stratégie, car les listes de contrôle d'accès contrôlant l'affectation de l'objet Stratégie de groupe (possibilité de lire l'objet Stratégie de groupe) sont vides. Enfin, les ordinateurs qui recevront les stratégies sont identifiés et leurs comptes d'ordinateurs sont placés dans les groupes d'ordinateurs appropriés avec accès en lecture à l'objet Stratégie de groupe. Une fois les tickets Kerberos de l'ordinateur mis à jour avec les informations d'appartenance de groupe, l'objet Stratégie de groupe, ainsi que la stratégie IPSec correspondante, s'appliquent à l'intervalle d'interrogation de stratégie de groupe suivant.
93
Remarque : les listes de contrôle d'accès qui empêchent les ordinateurs du domaine de lire les objets de stratégie IPSec ou le conteneur de stratégie IPSec dans Active Directory ne sont pas recommandées. Considérez une organisation ayant défini deux stratégies IPSec, IPSec standard et IPSec chiffrement. La stratégie IPSec standard est la stratégie par défaut ; elle exige que le trafic entrant utilise IPSec, mais permet aux systèmes de communiquer en clair s'ils initient une connexion vers un ordinateur non basé sur IPSec. La stratégie IPSec chiffrement exige la négociation IPSec chiffré à tous moments. Dans cet exemple, l'administration de l'organisation crée deux objets Stratégie de groupe dans Active Directory : IPSec standard et IPSec chiffré. De plus, elle identifie les groupes dans le tableau suivant : Tableau 4.9 : Groupes d'administration IPSec Nom de groupe
Type de groupe
Description
IPSecSTD
Universel
Contrôle l'application de la stratégie IPSec standard
IPSecENC
Universel
Contrôle l'application de la stratégie IPSec chiffré
Les listes de contrôle d'accès des deux objets Stratégie de groupe nouvellement créés sont mises à jour de sorte qu'elles ne sont pas automatiquement appliquées au groupe Utilisateurs authentifiés et que les groupes d'application et de gestion appropriés reçoivent les droits corrects. L'administration a modifié les listes de contrôle d'accès pour les deux objets Stratégie de groupe en fonction des informations du tableau suivant : Tableau 4.10 : Droits de groupes sur les objets Stratégie de groupe Groupe
Objet Stratégie de groupe IPSec standard
Objet Stratégie de groupe IPSec chiffré
Utilisateurs authentifiés
Lecture
Lecture
IPSecENC
Aucun
Lecture Appliquer la stratégie de groupe
IPSecSTD
Lecture Appliquer la stratégie de groupe
Aucun
Remarque : ce tableau montre uniquement les autorisations ajoutées ou modifiées. Il y aura également des groupes supplémentaires avec des autorisations. Les administrateurs ont lié les deux objets Stratégie de groupe au domaine dans Active Directory. Cette approche garantit que la stratégie s'appliquera à tout ordinateur du domaine sans modifier son emplacement (à moins que l'ordinateur se situe dans une UO bloquant les stratégies). À mesure que les ordinateurs sont identifiés, leurs comptes sont ajoutés au groupe IPSecSTD ou IPSecEnc. Passé un certain délai, la stratégie IPSec correspondante s'appliquera et sera effective. Cette méthode exige une planification soignée pour s'assurer que les communications ne sont pas perturbées. Par exemple, si un serveur a été placé dans le groupe IPSecEnc, mais que plusieurs clients dépendant de ce serveur n'ont pas pu négocier IPSec, les communications entre ces clients et le serveur seraient perturbées.
94
Déployer par élaboration de stratégies Cette méthode utilise une technique dans laquelle les stratégies IPSec peuvent être créées de toutes pièces durant le déploiement. L'avantage de cette méthode est qu'IPSec est négocié uniquement pour un petit pourcentage du trafic TCP/IP total, et non pour tous les sousréseaux internes de la méthode de déploiement par groupe. Elle permet également de tester tous les chemins du réseau interne vers ce sousréseau cible pour vérifier l'absence de problèmes avec la transmission réseau de la négociation IKE et du trafic protégé par IPSec. Un autre avantage est que l'intervalle d'interrogation pour IPSec peut fournir plus rapidement des mises à jour de stratégie IPSec (y compris d'annulation) au lieu de devoir dépendre des changements de membres de groupe dans le ticket d'octroi d'autorisations (TGT) Kerberos ou les tickets de service. L'inconvénient de cette méthode est qu'elle s'applique à tous les ordinateurs du groupe ou domaine d'isolation, et non à des ordinateurs spécifiques comme dans la méthode de déploiement par groupe. De plus, tous les ordinateurs disposeront d'un délai de 3 secondes avant retour à la communication en clair à un moment donné lors de la communication avec les sousréseaux spécifiés. Dans cette méthode de déploiement, les stratégies IPSec n'incluent que des exceptions initialement ; il n'existe aucune règle pour la négociation de la sécurité par les ordinateurs dans la stratégie IPSec. Cette méthode teste et vérifie d'abord que toutes les stratégies IPSec locales existant précédemment et pouvant être en cours d'utilisation sont supprimées. L'équipe d'administration doit pouvoir identifier les hôtes qui utilisaient des stratégies IPSec définies localement à l'avance pour gérer ces systèmes avec un processus spécial. Si une stratégie IPSec locale est remplacée par une stratégie de domaine, il peut se produire des interruptions dans les communications et une perte de sécurité pour les ordinateurs affectés. Contrairement aux stratégies locales remplacées par l'application de stratégie de domaine, les stratégies persistantes sous Windows Server 2003 fusionnent avec le résultat de l'application de la stratégie de domaine. Un système contenant une stratégie persistante peut sembler fonctionner, mais la configuration de la stratégie persistante peut changer le comportement ou diminuer en fait la sécurité fournie par la stratégie de domaine, ou peut perturber les communications une fois des règles de sousréseau sécurisé ajoutées à la stratégie. Vous pouvez ensuite créer une règle de sécurité avec un filtre affectant uniquement un seul sous réseau dans le réseau de l'organisation, par exemple « Tout le trafic à partir de n'importe quelle adresse IP vers Sousréseau A, négocier ». Cette règle aurait une action de filtre pour accepter le texte clair entrant et déclencher des négociations pour tout le trafic sortant vers ce sousréseau avec la communication en texte clair activée. À mesure que le déploiement dans tous les domaines de cette stratégie IPSec prend effet, les communications passeront peu à peu d'associations de sécurité logicielles à des associations de sécurité IPSec normales pour les hôtes approuvés juste sur ce sous réseau. Tout échec de négociation IKE est étudié et résolu. Toutes incompatibilité d'application est identifiée et corrigée. IPSec sécurisera la communication entre les hôtes approuvés dans ce sous réseau. La communication avec des hôtes approuvés en dehors de ce sousréseau repassera en clair après le délai de trois secondes. Des sousréseaux supplémentaires sont ajoutés à la règle sécurisée jusqu'à ce que la stratégie soit constituée à son état final. Considérez une organisation ayant une seule stratégie IPSec définie, appelée stratégie IPSec standard, qui demande une négociation IPSec, mais accepte le retour à la communication en texte clair en cas d'échec. La stratégie est créée dans Active Directory et ne contient que des règles d'exemption. L'objet Stratégie de groupe IPSec standard est créé et lié de sorte qu'il s'applique à tous les ordinateurs de l'environnement. De plus, la stratégie IPSec standard est affectée à ce nouvel objet Stratégie de groupe. Tous les ordinateurs recevront finalement la stratégie IPSec. Tous problèmes avec des stratégies IPSec locales seront détectés car cette stratégie de domaine supplantera les stratégies locales
95
existantes. Les problèmes sont continuellement résolus jusqu'à ce que tous les sousréseaux apparaissent dans la liste de filtres de sousréseaux sécurisés.
Implémentation des groupes pour Woodgrove Bank Woodgrove Bank a choisi d'implémenter son déploiement de production en déplaçant d'abord tous les ordinateurs vers le groupe de limite à l'aide de la méthode d'élaboration. Cette approche a permis aux administrateurs d'avancer peu à peu et de résoudre tous les problèmes en suspens sans trop affecter les communications entre tous les systèmes. En déployant d'abord une stratégie sans sousréseaux sécurisés, l'équipe d'administration a pu identifier les systèmes auxquels était affectée une stratégie IPSec locale et prendre également ces informations en considération. Alors que des sousréseaux ont été ajoutés à la stratégie, tous les conflits supplémentaires détectés ont été résolus. Une fois que les ordinateurs fonctionnaient selon la stratégie de groupe de limite, l'équipe a implémenté les groupes Domaine d'isolation, Sans basculement et Chiffrement. Le déploiement de ces groupes utilisait la méthode Déployer par groupe. Un ensemble d'ordinateurs a été sélectionné pour un pilote et ajouté aux groupes appropriés contrôlant les nouvelles stratégies. Les problèmes ont été résolus à mesure de leur découverte, et des ordinateurs supplémentaires ont été ajoutés aux groupes jusqu'à ce qu'ils soient totalement remplis. Le tableau suivant répertorie les groupes d'ordinateurs et d'accès réseau ainsi que leurs membres une fois la solution totalement déployée : Tableau 4.11 : Appartenance au groupe d'ordinateurs et au groupe d'accès réseau Groupe d'ordinateurs ou d'accès réseau
Membres
CG_IsolationDomain_Computers
Ordinateurs du domaine
CG_BoundaryIG_Computers
IPSPRINTS01
CG_NoFallbackIG_Computers
IPSLTXP01
CG_EncryptionIG_Computers
IPSSQLDFS01 IPSSQLDFS02
ANAG_EncryptedResourceAccess_Users
User7
ANAG_EncryptedResourceAccess_Computers
IPSSQLDFS01 IPSSQLDFS02 IPSSTXP05
DNAG_EncryptionIG_Computers
CG_BoundaryIG_Computers
Notez que le groupe ANAG_EncryptedResourceAccess_Computers contient les serveurs se trouvant dans le groupe d'isolation de chiffrement. Ceci leur permettra de communiquer selon les besoins. Si cette communication n'est pas nécessaire pour ces serveurs, il est inutile de les ajouter dans ce groupe.
Résumé Ce chapitre décrit le processus de conception d'une solution d'isolation de serveurs et de domaines. Les tâches comprenaient l'identification des groupes d'ordinateurs et des groupes d'accès réseau requis, la compréhension des groupes d'isolation de base, l'ajout de groupes d'isolation
96
supplémentaires, l'élaboration d'un modèle de trafic, l'affectation de membres aux groupes, ainsi que la planification de la méthode de déploiement. Ce chapitre utilisait également l'implémentation IPSec de Woodgrove Bank, une organisation fictive, pour aider à illustrer le processus de conception en action et éprouver la conception dans les laboratoires de test Microsoft. La conception de groupes était basée sur les exigences commerciales et les informations de découverte obtenues à partir des deux chapitres précédents et documentées dans la feuille de calcul Business_Requirements.xls (disponible dans le dossier Tools and Templates). Une appréciation de l'impact d'IPSec sur un réseau était également une considération importante. Après avoir lu ce chapitre, vous devez disposer de suffisamment d'informations pour commencer à planifier des groupes d'isolation, à documenter les exigences de communication entre ces groupes, et à planifier la stratégie IPSec de niveau supérieur. Ces tâches vous prépareront pour le chapitre 5, « Création de stratégies IPSec pour les groupes d'isolation ».
Informations complémentaires Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de l'implémentation de cette solution. IPSec Les liens suivants offrent une grande variété d'informations relatives à IPSec sous Windows :
• Le livre blanc « Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network
Server » (Utilisation de Microsoft Windows IPSec pour aider à sécuriser un serveur de réseau d'entreprise interne) présente le premier modèle d'utilisation d'IPSec pour sécuriser l'accès réseau aux serveurs internes traitant ou stockant des informations sensibles. Ce livre blanc peut être téléchargé sur www.microsoft.com/downloads/ details.aspx?FamilyID=a774012aac254a1d8851b7a09e3f1dc9&displaylang=en.
• Le déploiement Microsoft d'IPSec pour protéger tous les membres du domaine est décrit dans
l'étude de cas « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) sur www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx.
• Page IPSec for Windows 2000
(IPSec pour Windows 2000) à l'adresse www.microsoft.com/windows2000/technologies/communications/ipsec/.
• Page Microsoft Windows Server 2003 IPSec
à l'adresse www.microsoft.com/windowsserver2003/technologies/networking/ipsec/.
Sécurité
• L'approche d'évaluation des risques de sécurité informatique de Microsoft est documentée dans le livre blanc « IT Security at Microsoft Overview » (Présentation de la sécurité informatique chez Microsoft) à l'adresse www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx.
Windows Server 2003 Active Directory Pour plus d'informations sur Active Directory, consultez :
97
• La page Windows Server 2003 Active Directory
à l'adresse www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/.
98
Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation L'objectif de ce chapitre est de fournir des instructions relatives à l'implémentation de la conception d'isolation de serveurs et de domaines. Les chapitres précédents expliquent le processus de conception et les raisons qui justifient les instructions du présent chapitre. Si cela n'est déjà fait, nous vous conseillons vivement de lire ces chapitres avant de poursuivre. Ce chapitre détaille l'implémentation des exigences de sécurité des groupes d'isolation de serveurs et de domaines conçus au chapitre 4, « Conception et planification de groupes d'isolation ». La combinaison des éléments suivants permettra la mise en place de ces exigences :
• Exigences d'accès entrant et sortant pour le domaine d'isolation et les groupes d'isolation : • Stratégie IPSec (Internet Protocol security) conçue spécialement pour le groupe d'isolation nécessitant une négociation IKE (Internet Key Exchange) IPSec pour les connexions entrantes et sortantes. • Groupes de sécurité basés sur les domaines, appelés groupes d'accès réseau, pour autoriser ou refuser l'accès réseau lors de l'utilisation d'un trafic protégé par IPSec.
• Exigences de protection du trafic réseau pour le domaine d'isolation et les groupes d'isolation : • Filtres de stratégie IPSec conçus pour identifier correctement le trafic à sécuriser. • Actions de filtrage IPSec chargées de négocier le niveau d'authentification et de chiffrement requis pour le trafic identifié par les filtres. • Paramètres des actions de filtrage IPSec afin de contrôler si les communications en texte clair sont autorisées lorsque des hôtes approuvés établissent des connexions sortantes. Ce guide aborde la préparation de la solution à l'aide de la stratégie de groupe et des stratégies IPSec dans le service d'annuaire Active Directory® sous Microsoft® Windows Server™ 2003, ainsi que la configuration des membres des domaines avec Windows Server 2003 et Microsoft Windows® XP. Ce chapitre décrit aussi les solutions conceptuelles alternatives et les options de déploiement. Des listes de vérification finales sont proposées afin de s'assurer que le processus de conception respecte toutes les exigences commerciales et de sécurité.
Connaissances préalables requises pour ce chapitre Cette section renferme des informations qui vous permettront de vérifier que votre organisation est prête à implémenter la solution IPSec (« Prête » s'entend au sens logistique et non au sens commercial – la motivation de l'entreprise pour l'implémentation de cette solution est traitée au chapitre 1, « Introduction à l'isolation de serveurs et de domaines », du présent guide).
Connaissances requises Il est préférable de connaître les principes généraux d'IPSec et, plus particulièrement, les techniques Microsoft d'implémentation d'IPSec. Une connaissance de base de Windows Server 2003 est également requise dans les domaines suivants :
99
• Concepts relatifs à Active Directory, notamment la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et autres objets Active Directory, et l'utilisation de la stratégie de groupe.
• Sécurité du système Windows : concepts de sécurité tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande.
• Maîtrise des principes réseau et IPSec fondamentaux Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les instructions de planification fournies dans les chapitres précédents du guide et bien comprendre l'architecture et la conception de la solution. Vous devez aussi avoir défini et documenté les besoins commerciaux de la solution dans le cadre de la définition des exigences de la solution.
Conditions requises pour l'organisation Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans l'implémentation de cette solution, notamment
• les dirigeants ; • les personnes chargées de l'audit et de la sécurité ; • les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ; • les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau, du serveur Web et du DNS (Domain Name System).
Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles.
Configuration requise pour l'infrastructure informatique Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :
• Un domaine Active Directory Microsoft Windows Server 2003 fonctionnant en mode mixte ou natif.
Cette solution fait appel à des groupes universels pour l'application des objets Stratégie de groupe. Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportezvous à la page New features for IPSec (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ipsec_whatsnew.asp.
• Licences, clés de produit et CD d'installation de Windows 2000 Server, Windows Server 2003 Standard Edition et Windows Server 2003 Enterprise Edition.
Ce chapitre exige aussi une maîtrise complète de l'infrastructure informatique existante pour garantir que les stratégies appropriées sont déployées sur les hôtes concernés de l'environnement. Le chapitre 3 (« Détermination de l'état actuel de votre infrastructure informatique ») décrit les
100
informations requises et comment vous les procurer. N'entamez pas la procédure décrite dans ce chapitre tant que vous ne disposez pas des informations suivantes :
• La définition des groupes d'isolation de la conception. Chacun des groupes d'isolation requis doit bénéficier d'une instruction claire signalant les exigences de sécurité et identifiant les ressources auxquelles ces exigences s'appliquent (soit l'appartenance à un groupe d'isolation).
• Une description détaillée de la manière dont les stratégies IPSec sont utilisées pour implémenter les groupes d'isolation, avec la liste des différentes stratégies IPSec requises et leur mode d'attribution.
• Un résumé général de l'impact d'IPSec pour l'application des groupes d'isolation. Ce résumé peut être accompagné d'une liste de problèmes et de solutions pour les éviter.
• Une description détaillée de l'évolution des stratégies IPSec dans le temps et une liste des
procédures nécessitant des modifications de ces stratégies. Cette liste peut inclure des procédures telles que le traitement des incidents de sécurité, l'ajout de composants réseau et l'ajout de clients ou de serveurs à un groupe d'isolation quelconque.
• Une bonne connaissance de la topologie du réseau et des schémas d'adressage IP de l'organisation.
Création de stratégies IPSec dans Active Directory Le processus visant à créer les stratégies nécessaires à la prise en charge des groupes d'isolation requis implique les tâches principales suivantes :
• Création des listes de filtres. • Création des actions de filtrage. • Création des stratégies IPSec pour l'implémentation des groupes d'isolation. Avant d'entreprendre le processus de création de ces composants, il est primordial que vous vous procuriez les schémas et les tableaux des modèles de trafic du chapitre 4 (« Conception et planification de groupes d'isolation »), tout comme les tableaux de correspondance réseau et hôtes. Ces tableaux fournissent les informations nécessaires pour garantir que les stratégies offrent les fonctionnalités requises et sont attribuées aux groupes d'isolation appropriés. La figure suivante décrit la configuration réseau utilisée pour simuler le scénario de la Woodgrove Bank.
101
Figure 5.1 Configuration réseau de la Woodgrove Bank
La configuration du laboratoire de test de la Woodgrove Bank fait apparaître les fonctions clés suivantes de la solution :
• Isolation des domaines à l'aide de groupes d'accès réseau afin de contenir certains hôtes à haut risque mais approuvés dans le domaine lorsque vous utilisez IPSec.
• Isolation des serveurs à l'aide de groupes d'accès réseau afin de définir et limiter les clients hôtes approuvés autorisés à se connecter via IPSec.
De plus, cet environnement de laboratoire permet de dégager les fonctionnalités Windows IPSec requises suivantes et d'évaluer la compatibilité avec d'autres technologies de sécurité susceptibles d'être employées dans des environnements réels :
• Compatibilité des ordinateurs dotés de Windows 2000 Service Pack (SP) 4 (avec mise à jour de la traduction d'adresses réseau NATTraversal (NATT), Windows XP SP2 et Windows Server 2003 en tant que membres de domaines.
• Compatibilité de ces platesformes lorsque vous les sécurisez à partir des techniques de
renforcement préconisées dans les guides de sécurité Microsoft Windows. Les cartes de trafic utilisées pour autoriser et bloquer le trafic à l'aide de filtres IPSec n'ont pas été intégrées à cette solution puisque l'isolation ne présente pas les mêmes exigences de protection. D'autres raisons ont abouti à la décision de ne pas intégrer les cartes de trafic, notamment le besoin de minimiser la complexité des stratégies IPSec d'isolation de serveurs et le fait que le parefeu Windows est souvent mieux adapté au filtrage d'autorisation/blocage (indépendamment de la capacité d'IPSec à fournir une sécurité de bout en bout pour chaque paquet).
• Capacité de l'application IPSec à sécuriser le service Web (HTTP), SQL Server, le système de
fichiers distribués (DFS), le partage de fichiers et d'imprimantes, Microsoft Operations Manager (MOM) et les serveurs et le trafic SMS (Microsoft Systems Management Server).
102
• Compatibilité d'IPSec ESP (Encapsulated Security Payload) NATT par encapsulation UDP (User Datagram Protocol)ESP pour les deux conditions suivantes :
• Accès sortant depuis des membres de domaine derrière NAT par authentification IKE Kerberos • Accès entrant à un membre de domaine derrière NAT par authentification IKE Kerberos Le scénario du laboratoire illustré dans la figure 5.1 a été utilisé pour vérifier que les fonctionnalités recherchées étaient obtenues dans tous les groupes d'isolation de la solution. Au total, quatre stratégies IPSec ont été créées et attribuées aux groupes d'isolation entourés de tirets gras dans la figure (soit le domaine d'isolation, le groupe d'isolation de chiffrement, le groupe d'isolation sans basculement et le groupe d'isolation de limite). Les sections suivantes expliquent comment ces stratégies ont été créées.
Présentation des composants de la stratégie IPSec Une stratégie IPSec désigne un nombre de composants utilisés pour appliquer les exigences de sécurité IPSec de l'organisation. La figure suivante décrit les divers composants d'une stratégie IPSec et expliquent comment ils sont associés entre eux.
Figure 5.2 Composants de la stratégie IPSec
La stratégie IPSec joue le rôle d'un conteneur identifiant l'ensemble des règles qui déterminent quel trafic de communication réseau est autorisé et sous quelle forme. Chaque règle se compose d'une liste de filtres et d'une action associée. La liste de filtres désigne un groupe de filtres. Chaque trafic mis en correspondance avec un filtre spécifique déclenche une action de filtrage associée. Les règles permettent également de définir les méthodes d'authentification à appliquer entre les hôtes. Ce schéma présente la structure descendante des composants de la stratégie. Néanmoins, la méthode la plus efficace pour créer des stratégies est de débuter avec des filtres et des listes de filtres car ils constituent le bloc fondamental qui permet de contrôler et déterminer quel trafic est sécurisé.
103
Listes de filtres IPSec Les listes de filtres IPSec sont des ensembles d'un ou plusieurs filtres utilisés pour structurer le trafic réseau selon des critères définis pour chaque filtre. Chaque filtre répertorié dans la liste des filtres définit les éléments suivants :
• Réseaux ou adresses source et de destination • Protocole(s) • Ports TCP (Transmission Control Protocol) ou UDP source et de destination Les listes de filtres et les actions de filtrage ont été conçues pour être partagées entre les stratégies IPSec. Cette approche permet de conserver une liste de filtres pour un type d'exemption donné et de l'utiliser dans une stratégie IPSec indépendante pour chaque groupe d'isolation. En revanche, les filtres qui composent les listes de filtres ne peuvent être partagés d'une liste à l'autre. Si deux listes de filtres contiennent des filtres identiques, les filtres devront être créés deux fois, soit un pour chaque liste de filtres. L'administrateur IPSec devra être particulièrement vigilant pour éviter les filtres en double dans une stratégie IPSec car les filtres peuvent correspondre à des actions distinctes. Le service IPSec peut modifier l'ordre des filtres en double en traitement par paquets et produire des résultats incohérents. Vous pouvez recourir aux filtres en double lorsqu'ils impliquent exactement la même action (par exemple, action d'autorisation ou de blocage) et que les performances restent inchangées. Les informations de réseau recueillies précédemment sont utilisées pour identifier les divers modèles de trafic que l'administrateur souhaite sécuriser. Elles permettent aussi d'identifier toutes les données en circulation pouvant bénéficier d'une exemption pour les restrictions IPSec. Le tableau cidessous décrit certaines listes de filtres élémentaires susceptibles d'être utilisées dans une organisation classique. Selon les besoins commerciaux et la conception du réseau de l'organisation, d'autres listes de filtres peuvent être nécessaires. Tableau 5.1 : Listes de filtres de la solution Liste de filtres
Description
Secure Subnets List (Liste des sous réseaux sécurisés)
Contient tous les sousréseaux de l'organisation à sécuriser avec IPSec.
DNS Exemption List (Liste d'exemptions DNS)
Contient les adresses IP des serveurs DNS qui seront autorisés à communiquer sans IPSec.
Domain Controllers Exemption List (Liste d'exemptions de contrôleurs de domaine)
Contient les adresses IP des contrôleurs de domaine qui seront autorisés à communiquer sans IPSec.
WINS Exemption List (Liste d'exemptions WINS)
Contient les adresses IP des serveurs WINS (Windows Internet Naming Service) qui seront autorisés à communiquer sans IPSec.
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
Contient le filtre permettant au trafic de négociation DHCP (Dynamic Host Configuration Protocol) d'avoir lieu sur le port UDP 68.
ICMP, All Traffic (ICMP, tout le trafic)
Contient le filtre qui permet au protocole ICMP (Internet Control Message Protocol) d'être utilisé au sein de
104
l'organisation à des fins de dépannage. La liste des sousréseaux sécurisés répertorie tous les sousréseaux disponibles sur le réseau interne de l'organisation. Cette liste de filtres est associée à une action de filtrage chargée d'implémenter les actions requises pour un groupe d'isolation spécifique. Cette action constitue l'action de sécurité la plus étendue pour l'ensemble du trafic réseau de ce sousréseau (par exemple, négociation IPSec) ; les autres filtres, notamment le filtre ICMP, seront plus spécifiques et nécessiteront une action différente (par exemple, autorisation). Un point primordial à retenir est que cette approche signifie qu'aucun hôte non approuvé ou nonIPSec ne doit figurer sur ces sousréseaux. Les filtres doivent implémenter à la fois des exigences de sécurité en entrée et en sortie. Au moment de les définir, vous devez les configurer en miroir. La mise en miroir garantit que le filtre est appliqué au trafic dont les adresses source et de destination sont exactement inverses. Lorsque vous définissez des filtres, le symbole « <> » est employé pour signaler que le filtre est mis en miroir. Vous devez utiliser des filtres en miroir chaque fois que l'action de filtrage négocie les méthodes de sécurité pour l'encapsulation IPSec. Adresses source et de destination Chaque filtre dispose d'un paramètre désignant à la fois les adresses source et de destination. Windows XP et Windows Server 2003 offrent plus d'options que Windows 2000 pour les adresses. Utilisez donc les paramètres Windows 2000 uniquement si cette plateforme est membre du domaine. Les paramètres Windows 2000 se présentent comme suit :
• Mon adresse IP. Cette option a été conçue afin d'appliquer une stratégie IPSec commune dans
Active Directory à plusieurs ou à l'ensemble des ordinateurs, qu'ils disposent d'une adresse IP statique ou d'une adresse attribuée par le serveur DHCP. Pour permettre la gestion centralisée des stratégies à partir du domaine, IPSec ne prend pas en charge la configuration des filtres pour les interfaces de réseau physique mais uniquement des interfaces réseau de type réseau local ou étendu ou des interfaces d'accès réseau à distance ou de réseau privé virtuel (VPN). Lorsque vous sélectionnez l'option Mon adresse IP, les filtres génériques de la stratégie IPSec sont copiés dans un filtre spécifique contenant chaque adresse IP utilisée par l'ordinateur au moment où le service IPSec s'apprête à appliquer la stratégie. Elle permet aussi au service IPSec de détecter toutes les modifications apportées aux adresses ou toute nouvelle interface réseau afin de conserver le nombre approprié de filtres. Si un ordinateur dispose d'une carte réseau pour laquelle deux adresses IP ont été configurées, deux filtres IPSec spécifiques différents sont créés à partir des deux adresses IP distinctes.
• N'importe quelle adresse IP. Cette option permet d'appliquer les filtres IPSec à n'importe quelle adresse IP.
• Un nom DNS spécifique. Grâce à cette option, IPSec peut évaluer l'adresse IP du nom DNS
spécifié, puis créer les filtres à partir de cette ou ces adresses IP. Le résultat obtenu est le même que si l'administrateur avait entré les adresses IP dans les filtres. Lors de la création du premier filtre, le nom DNS est résolu et les adresses IP correspondantes sont placées dans le filtre. Si le serveur DNS dispose d'un enregistrement de ressource incorrect pour le nom DNS spécifié dans le filtre, l'adresse IP erronée est ajoutée au filtre.
Remarque : le nom DNS n'est jamais évalué après la création initiale des filtres au sein de la stratégie. L'option de nom DNS est utile lorsque vous avez besoin de créer un grand nombre de filtres, car le nom DNS correspond à de nombreuses adresses IP, notamment pour chaque contrôleur de domaine appartenant au domaine. Il n'existe aucune méthode de création automatique de filtres dont la liste d'adresses IP peut être actualisée pour un nom DNS donné.
105
• Une adresse IP spécifique. Cette option compare le trafic avec l'adresse IP spécifiée dans le filtre.
• Un sousréseau IP spécifique. Cette option permet à l'administrateur de configurer un sous
réseau spécifique. N'importe quelle adresse IP au sein du sousréseau spécifié correspondra au filtre. Manipulez cette option avec soin, surtout si vous avez défini une exemption pour un sous réseau (tout utilisateur malveillant s'emparant d'une adresse IP de ce sousréseau sera, lui aussi, exempté).
Remarque : Windows XP et Windows Server 2003 ont été améliorés en vue de fournir des options d'adresse supplémentaires et d'autres options prises en charge dans ces versions. Si la même stratégie IPSec est appliquée à plusieurs platesformes, l'administrateur doit s'assurer que seules les options de Windows 2000 sont utilisées dans l'élaboration de la stratégie. Protocoles Outre les adresses source et de destination, chaque filtre peut être configuré pour rechercher un protocole ou un port spécifique. Par défaut, le filtre s'appliquera au trafic sur tous les protocoles et tous les ports. Si un protocole spécifique prenant en charge les ports est sélectionné en tant que critère de filtrage, l'administrateur a également la possibilité de configurer les ports source et de destination. Ports source et de destination Bien que les filtres puissent être configurés afin d'être adaptés aux ports TCP ou UDP, cette solution ne recommande pas la création de filtres spécifiques aux ports. Le filtrage par port augmente considérablement la charge administrative et la complexité de la configuration des filtres IPSec et peut exiger un effort de coordination complexe entre les stratégies client et serveur pour permettre une négociation correcte de la sécurité par IKE. Puisque cette solution part du principe que la communication entre les ordinateurs approuvés est en fait approuvée, les filtres autorisent IPSec à sécuriser tout le trafic (sauf le trafic ICMP). Si le filtrage par port s'avère nécessaire sur l'hôte approuvé, reportezvous à la feuille de calcul Business_Requirements.xls pour connaître les conditions de sécurité liées à l'utilisation combinée d'IPSec et d'un parefeu basé sur un hôte (par exemple, le parefeu Windows) superposé sur la couche IPSec. Pour éviter certains des problèmes mentionnés dans l'annexe A et inhérents au comportement des filtres avec l'option « Mon adresse IP », cette solution utilise des filtres N'importe quelle adresse IP <> sousréseaux pour le scénario de la Woodgrove Bank. Une liste composée de plusieurs filtres N'importe quelle adresse IP <> Un sousréseau IP spécifique est créée, répertoriant de manière explicite tous les sousréseaux de l'organisation. Cette approche permet à l'administrateur de définir les sousréseaux spécifiques à sécuriser. Tout le trafic circulant en dehors des sousréseaux spécifiés ne correspond à aucun filtre IPSec et est envoyé en clair à l'hôte de destination. Pour connaître d'autres méthodes conseillées pour la création de filtres, reportezvous à la section « Best Practices » (Meilleures pratiques) du livre blanc « Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec) » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec par Microsoft IT) sur Microsoft TechNet à l'adresse www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx. Considérations relatives aux listes d'exemptions Pour des raisons de support, techniques ou commerciales, certains types de trafic ne peuvent pas être protégés par IPSec. De même, la prise en charge d'IPSec n'est pas garantie sur les ordinateurs non dotés du système d'exploitation Windows et son déploiement peut s'y avérer délicat. Les
106
ordinateurs munis d'anciennes versions de Windows, notamment Microsoft Windows NT® version 4.0, Windows 95 et Windows 98, ne peuvent pas gérer une structure IPSec fondée sur la stratégie de groupe. Enfin, les ordinateurs non gérés équipés de Windows 2000 (ou ultérieur) peuvent uniquement participer à la négociation IPSec si la stratégie est déployée manuellement sur chaque ordinateur et qu'une forme d'authentification autre que le protocole Kerberos version 5 (par exemple, une clé pré partagée ou un certificat) est utilisée. Qui plus est, un ordinateur équipé de Windows 2000 (ou ultérieur) nécessite une connectivité réseau et doit être en mesure de se procurer une stratégie IPSec à partir du domaine avant d'implémenter IPSec. À l'heure actuelle, la connexion au réseau, l'identification d'un contrôleur de domaine et l'obtention de la stratégie exigent que les services de l'infrastructure de soutien soient exemptés de la sécurité IPSec. Il peut s'agir de services d'attribution de noms, tels que les services DNS et WINS, et des contrôleurs de domaine euxmêmes. Outre ces services d'infrastructure, d'autres services ne prenant pas en charge IPSec peuvent être présents dans l'organisation. Par exemple, les clients légers ou d'autres clients d'amorçage (BOOTP) cherchant à télécharger une image depuis des services ADS (Advanced Deployment Services) ou des services d'installation à distance (RIS) ne prennent pas en charge IPSec. Si des serveurs fournissant ces services existent sur votre réseau, vous devez les examiner et envisager de les intégrer dans une liste d'exemptions ou bien les affecter en tant que membres du groupe d'isolation de limite afin qu'ils puissent accepter les communications réseau provenant des hôtes inaptes à utiliser IPSec. Remarque : la décision d'inclure ou non les serveurs dotés de services ADS, RIS ou d'autres services répertoriés dans les listes d'exemptions, ou celle de les définir en tant que membres du groupe d'isolation de limite, dépend de critères de risque et de facilité de gestion. Dans un cas comme dans l'autre, vous devez tester avec soin l'approche choisie. Si un client est inapte à participer à l'infrastructure IPSec mais doit, pour des besoins commerciaux, accéder à un serveur qui utilise IPSec, vous devez implémenter une méthode permettant d'établir un chemin de communication. La solution de ce guide fait appel à des listes d'exemptions pour contrôler ces exigences de trafic par le biais d'autorisations. Les listes d'exemptions sont créées dans l'infrastructure IPSec pour s'assurer que toutes les communications requises avec les hôtes ont lieu, même si l'utilisation de négociations IPSec est impossible. Leur but est d'empêcher le trafic (de manière sélective) de participer à l'infrastructure IPSec en autorisant seulement le trafic correspondant aux filtres des listes d'exemptions. Ces listes doivent être établies avec soin puisqu'elles ne sont pas soumises aux mécanismes de sécurité mis en place par IPSec. Par exemple, si vous placez un serveur généralement sécurisé par chiffrement (protection des informations propriétaires) dans un filtre d'exemption, les ordinateurs invités pourront communiquer directement avec le serveur sans l'aide d'IPSec. Les listes d'exemptions sont implémentées en tant que listes de filtres afin de réduire la taille des listes et faciliter la configuration de l'interface utilisateur. Par exemple, vous devez disposer d'une liste de filtres contenant les filtres de tous les contrôleurs de domaine ou des contrôleurs de domaine figurant dans chaque domaine. Un autre avantage à disposer de plusieurs listes de filtres réside dans le fait que vous pouvez aisément désactiver/activer la règle d'autorisation dans la stratégie IPSec. Lorsque vous concevez une règle pour définir une exemption dans la stratégie IPSec, il est préférable d'autoriser la quantité de trafic la plus infime possible à ne plus être protégé par IPSec. Néanmoins, la complexité et la taille de la stratégie IPSec, face aux gains de sécurité que représente l'emploi des filtres les plus spécifiques, implique des compromis. Notez que toutes les adresses IP des contrôleurs de domaine dans toutes les forêts approuvées doivent être exemptées afin que les clients d'un domaine ou d'une forêt puissent se procurer des tickets Kerberos pour les serveurs d'une autre forêt ou d'un autre domaine approuvé. Pour ses propres contrôleurs de domaine et ceux d'autres domaines, le client Windows Kerberos doit disposer des éléments suivants : ICMP, LDAP (Lightweight
107
Directory Access Protocol) sur port UDP 389 et le trafic Kerberos sur les ports UDP 88 et TCP 88. Les membres des domaines exigent d'autres types de trafic pour les contrôleurs de domaine de leur propre domaine, notamment SMB (Server Message Block) sur TCP 445, l'appel de procédure distante (RPC) et LDAP sur TCP 389. Lorsque les exigences de sécurité ne sont pas trop importantes, l'exemption est définie pour « tout le trafic » avec les adresses IP des contrôleurs de domaine pour simplifier les choses et réduire le nombre de filtres. Il peut être tentant d'exempter une application particulière par port, plutôt que par adresse de destination, pour éviter d'avoir à entretenir une liste d'adresses (par exemple, un trafic Telnet sortant utilisant le port TCP 23 pour accéder à des systèmes UNIX). Par exemple, imaginons l'exemption sortante suivante : Mon adresse IP à N'importe quelle adresse IP, TCP, src port N'importe lequel, dst port 23, miroir Le filtre entrant correspondant se présente comme suit : N'importe quelle adresse IP à Mon adresse IP, TCP, src port 23, dst port N'importe lequel Ce filtre entrant permettrait d'obtenir des réponses aux demandes de connexion Telnet, mais un attaquant pourrait également contourner les exigences d'authentification IPSec et accéder à n'importe quel port ouvert sur l'hôte. Les organisations devront évaluer avec soin les risques de sécurité d'une éventuelle attaque de ce type avant d'utiliser un tel filtre. Les risques sont sans doute réduits si vous spécifiez l'adresse IP de destination. Cette même situation peut se produire si l'exemption par défaut du protocole d'authentification Kerberos n'est pas désactivée. Reportezvous aux articles 811832 (http://support.microsoft.com/?kbid=811832) et 810207 (http://support.microsoft.com/? kbid=810207) de la Base de connaissances Microsoft pour obtenir des informations détaillées sur l'impact des exemptions par défaut en termes de conception et de sécurité. Vous devez concevoir les stratégies IPSec en partant du principe qu'aucune exemption par défaut n'est activée. L'insertion d'adresses système dans une liste d'exemptions exempte bel et bien ces systèmes de participer en tant qu'hôtes IPSec dans toutes les stratégies IPSec qui mettent en œuvre la liste d'exemptions. Du fait que la plupart des clients de l'organisation (y compris les clients invités) nécessitent habituellement un accès aux services d'infrastructure, notamment DHCP, DNS ou WINS, les serveurs fournissant ces services sont, en règle générale, implémentés de cette manière. Listes de filtres de la Woodgrove Bank Après avoir analysé les exigences de trafic décrites au chapitre 4, les administrateurs de la Woodgrove Bank ont élaboré les listes de filtres dans le tableau cidessous. Tableau 5.2 : Exemples de listes de filtres de la Woodgrove Bank Liste de filtres
Filtres définis
Secure Subnets (Sousréseaux sécurisés)
N'importe lequel <> 192.168.1.0/24
N'importe lequel <> 172.10.1.0/24
Toutes
DNS Exemption List (Liste d'exemptions DNS)
N'importe lequel <> 192.168.1.21
N'importe lequel <> 192.168.1.22
Toutes
Domain Controllers Exemption List (Liste d'exemptions N'importe lequel <> de contrôleurs de domaine) 192.168.1.21
108
Protocole ou port
N'importe lequel <> 192.168.1.22
Toutes
LOB Application Servers Exemption List (Liste d'exemptions de serveurs d'application commerciales)
N'importe lequel <> 192.168.1.10
Tous
WINS Exemption List (Liste d'exemptions WINS)
N'importe lequel <> 192.168.1.22
Tous
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
Mon adresse IP <> N'importe lequel
UDP source 68, dest 67
ICMP, All Traffic (ICMP, tout le trafic)
Mon adresse IP <> N'importe lequel
ICMP uniquement
Les concepteurs de la Woodgrove Bank ont suivi les instructions fournies dans ce chapitre pour créer les listes de filtres. La première liste, celle des sousréseaux sécurisés, comporte deux filtres :
• N'importe lequel <> 192.168.1.0/24 • N'importe lequel <> 172.10.1.0/24 Ces filtres de sousréseaux sont mis en miroir pour correspondre à la fois au trafic entrant et sortant et sont configurés pour être déclenchés sur n'importe quel protocole. Cette liste de filtres, une fois associée à l'action de filtrage appropriée, procèdera à l'implémentation des groupes d'isolation. Les concepteurs de la Woodgrove Bank ont choisi d'implémenter ensuite une liste d'exemptions pour le trafic réseau ICMP. Cette liste de filtres comprend un filtre miroir unique (Mon adresse IP <> N'importe lequel) configuré exclusivement pour le trafic réseau ICMP. Cette approche permet aux administrateurs d'utiliser l'utilitaire Ping en tant qu'outil de dépannage au sein de l'environnement, sans se soucier de savoir si une association de sécurité IPSec a été négociée ou non. Cette approche s'avérait également nécessaire du fait que la solution exige la découverte du PMTU (Path MTU) pour fonctionner correctement. Pour le trafic DHCP, les concepteurs de la Woodgrove Bank ont créé un nouveau filtre pour le port UDP 68 afin de permettre aux clients DHCP de recevoir le trafic provenant du serveur DHCP. De plus, la Woodgrove Bank dispose de quelques applications commerciales sur des serveurs inaptes à participer à l'infrastructure IPSec. Pour adapter ces services, ils ont créé une nouvelle liste de filtres d'exemption (LOB Application Servers Exemption List) et ajouté un filtre N'importe lequel <> 192.168.1.10 pour le système hébergeant l'application commerciale. Pour finir, l'équipe de conception de la Woodgrove Bank a identifié ses services d'infrastructure et créé les listes de filtres d'exemption correspondantes pour permettre à tous les clients de communiquer directement avec les serveurs fournissant ces services, quels que soient les paramètres IPSec des groupes d'isolation. Des listes d'exemptions spécifiques ont été créées pour les services suivants :
• DNS. Cette liste exempte les serveurs DNS afin que tous les clients du réseau puissent procéder à des recherches de noms de domaines.
• Contrôleurs de domaine. Cette liste permet aux systèmes associés à des domaines de s'authentifier avec un contrôleur de domaine.
• WINS. Cette liste permet surtout aux périphériques hôtes de rechercher des noms NetBIOS sur un serveur WINS.
109
Ces listes de filtres sont composées de filtres mis en miroir (de type N'importe lequel <> Une adresse IP spécifique) configurés pour se déclencher sur n'importe quel protocole. Le nombre d'ordinateurs inscrits dans les listes de filtres d'exemption doit rester aussi réduit que possible puisque tout le trafic est exempté sur ces ordinateurs et que tous les ordinateurs de la liste d'exemptions bénéficient d'un accès TCP/IP intégral à tous les hôtes approuvés du domaine d'isolation. Cette approche peut, par conséquent, élargir la surface d'attaque potentielle. Consultez la feuille de calcul Business_Requirements.xls (dossier Tools and Templates) pour obtenir des détails sur les exigences d'atténuation des risques liés au trafic entrant depuis les adresses IP exemptées. La Woodgrove Bank a choisi de gérer deux listes séparées pour les serveurs DNS et les contrôleurs de domaine, même si les adresses IP sont identiques. La Woodgrove Bank a opté pour cette approche parce que les deux listes de filtres présenteront exactement la même action (autoriser). De plus, le réseau de production Woodgrove utilise les serveurs DNS dans certains domaines où ils ne sont pas également des contrôleurs de domaine. Au lieu d'utiliser des adresses IP de destination spécifiques, le filtre DHCP a été conçu pour s'appliquer à l'ensemble du trafic sortant des clients DHCP. La copie miroir de ce filtre autorise les réponses des serveurs DHCP. Comme nous l'avons déjà indiqué, il peut également autoriser des attaques entrantes depuis n'importe quelle adresse IP utilisant le port source 67. En revanche, l'attaque entrante est limitée au port de destination 68 sur le client, ce que le client DHCP utilise. La Woodgrove Bank a utilisé cette conception pour éviter de créer des filtres pour chaque serveur DHCP et parce que son évaluation des risques a conclu que les risques d'attaques entrantes sur le port du client DHCP ou les risques de serveurs DHCP non autorisés n'étaient pas très élevés. Cette section ne fournit pas une description complète de chaque filtre. Néanmoins, nous vous conseillons d'utiliser le champ de description du filtre pour définir avec soin chaque filtre puisque le moniteur IPSec et les outils de ligne de commande affichent la description de chaque filtre, pas les informations dans la liste de filtres.
Actions de filtrage IPSec Les actions de filtrage définissent la manière dont les paquets IP sont gérés après qu'ils aient été reconnus par un filtre de la liste des filtres. Les actions de filtrage sont à la base de l'implémentation des divers groupes d'isolation. Bien que le système d'exploitation Windows propose trois actions de filtrage par défaut, nous vous conseillons de les retirer et de créer d'autres actions de filtrage conformes à cette approche pour veiller à ce que seules les actions que vous créez dans le cadre de votre solution soient utilisées. Chaque action de filtrage est composée d'un nom, d'une description et d'une méthode de sécurité. Nom Donnez un nom significatif à l'action de filtrage, qui reflète ce qu'elle fait. Description Tapez une description détaillée de l'action de filtrage dans le champ de description. Méthodes de sécurité Les méthodes de sécurité implémentées dans l'action de filtrage sont déterminées par les exigences de traitement des paquets correspondant aux filtres associés dans la liste de filtres. Les trois options disponibles sont les suivantes :
110
• Bloquer. Les paquets IP correspondant au filtre associé sont bloqués, ce qui signifie qu'ils sont ignorés.
• Autoriser. Les paquets IP correspondant au filtre associé sont autorisés à traverser la couche IPSec sans traitement supplémentaire dans IPSec.
• Négocier. Si les paquets sortants répondent aux critères du filtre, IPSec tente de négocier l'une
des méthodes de sécurité inscrites dans l'action de filtrage selon leur ordre relatif. Plus la méthode de sécurité est haut dans la liste, plus la priorité qui lui est accordée est grande. Chaque méthode de sécurité peut déterminer s'il faut utiliser l'outil d'intégrité, activer le chiffrement et quels algorithmes de cryptographie sont implémentés. Le traitement des paquets entrants correspondant à un filtre doté d'une action de négociation (négocier) est fonction du paramètre défini pour l'option Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec.
Le tableau ciaprès répertorie les options cryptographiques possibles pour chaque méthode de sécurité : Tableau 5.3 : Options cryptographiques et de sécurité Méthode de sécurité Authentification de l'entête (AH)
Options cryptographiques MD5 SHA1
ESP – Intégrité
ESP – chiffrement
Description Garantit à la fois l'authenticité et l'intégrité de la charge utile IP (données) et de l'entête IP (adresse) sans chiffrement. AH ne peut pas traverser les périphériques utilisant la traduction d'adresses réseau (NAT). Garantit l'intégrité et l'authenticité des données de la charge utile IP (données) uniquement. Elle peut être utilisée avec ou sans chiffrement. L'utilisation d'ESP sans authentification est déconseillée. Avec DES ou 3DES, fournit le chiffrement de la charge utile IP (données). Peut être utilisée avec un algorithme de chiffrement nul lorsque le chiffrement n'est pas nécessaire.
Les implémentations IPSec dans Windows 2000 SP4, Windows XP SP2 et Windows Server 2003 prennent désormais en charge les techniques NATT pour ESP en mode de transport IPSec, en plus de la prise en charge de NATT pour les tunnels clients VPN L2TP/IPSec. La mise à jour NATT est requise pour Windows 2000 SP4. La prise en charge de NATT en mode de transport IPSec dans Windows 2000 et Windows XP est limitée aux versions Windows 2000 et Windows XP antérieures au SP2 puisque la fonctionnalité de détection PMTU (PathMTU) TCP n'est pas prise en charge pour le trafic TCP protégé par IPSec. Windows Server 2003 offre cette prise en charge. Les techniques NAT T utilisent un entête UDP après l'entête IP pour encapsuler ESP. IKE détecte automatiquement l'existence de NAT dans le chemin et utilise UDPESP si ESP est autorisé dans la liste des méthodes de sécurité. Un point également à noter est que les implémentations IPSec Windows actuelles ne prennent pas en charge la norme AES (Advanced Encryption Standard) du gouvernement fédéral américain. Cela sera corrigé dans les versions prochaines de Windows. Les options cryptographiques disponibles pour AH et ESP sont les suivantes :
• MD5. Cet algorithme de hachage utilise une clé de chiffrement de 128 bits pour générer un résumé du contenu du paquet. MD5 n'est pas un algorithme adapté à des scénarios de sécurité du gouvernement fédéral américain.
• SHA1. Cet algorithme de hachage utilise une clé de chiffrement de 160 bits pour générer un
résumé du contenu du paquet. Plus la clé de SHA1 est longue, plus la sécurité est élevée mais la
111
charge requise pour le traitement est, elle aussi, plus importante. SHA1 est un algorithme adapté aux réglementations de sécurité du gouvernement fédéral américain. Vous pouvez configurer ESP afin qu'il n'utilise aucun algorithme de chiffrement, auquel cas seules l'authenticité et l'intégrité des données sont appliquées. Cette configuration, couramment appelée ESPNull, offre la possibilité d'authentifier les hôtes avant d'établir une connexion et d'effectuer une vérification de l'intégrité de la section des données du paquet IP transporté au sein du paquet ESP. ESP peut également chiffrer la section des données du paquet IP. Les deux options cryptographiques disponibles sont les suivantes :
• DES. Cette option utilise une clé 56 bits et traite chaque bloc une seule fois. DES offre une conformité RFC (Request for Comment). Les attaquants étant de plus en plus capables de compromettre le chiffrement DES, l'utilisation de l'option DES n'est pas conseillée.
• 3DES. Cette option traite chaque bloc trois fois à l'aide de trois clés 56 bits uniques. Bien que
l'option DES soit prise en charge, il est vivement recommandé d'utiliser l'option plus sécurisée 3DES. En revanche, 3DES est un peu plus lent et exige une capacité de traitement plus élevée que DES.
Vous pouvez combiner les protocoles AH et ESP s'ils doivent répondre à des exigences de sécurité optimales. Par exemple, si votre infrastructure exige clairement l'intégrité de l'entête IP en plus du chiffrement des données, vous pouvez configurer la méthode de sécurité afin qu'elle utilise le protocole AH avec une intégrité SHA1 et un chiffrement ESP–3DES. Si seule l'intégrité des données est requise, vous pouvez alors utiliser ESPNull avec SHA1. Bien que vous puissiez choisir une combinaison quelconque d'options de sécurité, il faut savoir que le protocole AH garantit à la fois l'intégrité des données et de l'entête d'adresse. L'utilisation combinée des protocoles AH et ESP ne renforce pas la protection de l'intégrité des données des paquets. Elle augmente simplement la charge de travail associée au traitement du paquet. Qui plus est, ESP associé à AH ne résout pas les problèmes de barrière NAT auxquels le protocole AH est confronté. L'utilisation du protocole AH avec ESP ne convient donc qu'aux environnements de haute sécurité. Une planification minutieuse est nécessaire pour définir les méthodes de sécurité des actions de filtrage. Pour mener à bien la négociation de deux ordinateurs, ces derniers doivent disposer au moins d'une méthode de sécurité en commun dans leurs actions de filtrage respectives. Chaque action de filtrage peut contenir plusieurs méthodes de négociation en vue de s'adapter à différents types de négociation. Par exemple, un système négocie souvent uniquement ESPNull, mais l'action de filtrage peut contenir également une méthode de négociation pour ESP3DES. Cette approche permet au système de négocier une connexion de chiffrement 3DES si celleci est nécessaire. Outre le choix des méthodes de sécurité, vous pouvez au besoin définir les paramètres de la clé de session pour chaque méthode de sécurité. Dans le paramètre par défaut, la durée de vie des associations de sécurité IPSec est fixée au moment où 100 mégaoctets (Mo) de données sont transmises ou au bout d'une heure de temps passé. Ces paramètres détectent chaque nouvelle paire d'associations de sécurité IPSec renégociée en mode rapide IKE. Bien que le processus du mode rapide IKE soit appelé « régénération des clés », il ne se contente pas d'actualiser les clés d'une paire d'associations de sécurité IPSec. IPSec doit ignorer les paquets si la durée de vie expire ; il s'efforce donc de renégocier comme il se doit avant que la durée de vie en octets ou en secondes n'expire. Si la durée de vie définie est trop faible, les paquets risquent d'être perdus. De même, vous pouvez augmenter le taux d'utilisation du processeur pour les serveurs chargés d'entretenir les associations de sécurité IPSec avec un grand nombre de clients. Le renouvellement des associations de sécurité IPSec garantit qu'aucun attaquant ne peut déchiffrer l'ensemble de la communication même s'il parvient à déterminer l'une des clés de la session. À mesure que la durée de vie augmente, l'attaquant obtient davantage d'informations sur la clé de la session. Par conséquent, il est préférable que vous
112
ne changiez pas la durée de vie sauf si des besoins opérationnels l'exigent. Vous pouvez également rédiger des exigences de sécurité spécifiques qui définissent un niveau approprié de protection contre des attaques cryptographiques élaborées. Options de négociation de sécurité Vous pouvez définir les options de négociation de sécurité suivantes pour les stratégies IPSec :
• Relais entrant • Communiquer en texte clair • Utiliser la session de clé principale PFS (Perfect Forward Secrecy) Relais entrant L'option Relais entrant a été conçue pour être utilisée dans une stratégie serveur interne afin que la stratégie client puisse adopter la règle de « réponse par défaut » non intrusive. Une fois cette option activée, toute demande de connexion soumise en texte clair et correspondant à un filtre entrant sera acceptée. La réponse de connexion du serveur correspond au filtre sortant pour déclencher une demande de négociation IKE en mode principal au client. Il est préférable de ne pas activer cette option sur des ordinateurs reliés à Internet en raison des attaques entrantes qu'elle laisse circuler à travers la couche IPSec. Elle force également le serveur à tenter une négociation d'association de sécurité IPSec sur l'adresse IP source de tout paquet entrant. En prenant le contrôle des adresses IP source, l'attaquant peut provoquer un refus de service sur le serveur tandis qu'IKE tente de négocier avec des centaines ou des milliers d'adresses IP non valides. Pour activer l'option Relais entrant, activez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec dans la boîte de dialogue Gérer les actions de filtrage. Remarque : si les stratégies attribuées aux clients n'activent pas la règle de réponse par défaut, vous devez désactiver cette option puisqu'il n'y aura aucune réponse pour la communication IPSec. De plus, elle peut être utilisée comme vecteur d'attaque de refus de service. Communiquer en texte clair L'option Communiquer en texte clair avec les ordinateurs qui ne prennent pas en charge IPSec contrôle la capacité de l'ordinateur (source) à transmettre le trafic sans protection IPSec si la négociation IKE initiale en mode normal n'obtient aucune réponse d'un ordinateur de destination cible. Les hôtes qui ne prennent pas en charge IPSec ne seront pas en mesure de répondre (via IKE) à la demande de négociation IKE. Dans le cas de ces hôtes, on parle d'ordinateurs qui n'utilisent pas IPSec. Néanmoins, l'absence de réponse IKE en mode principal ne signifie pas nécessairement que l'ordinateur n'est pas compatible avec IPSec. Il peut s'agir d'un ordinateur IPSec qui ne dispose pas d'une stratégie IPSec active. La stratégie IPSec active peut aussi n'effectuer que des actions autoriser et bloquer. Elle peut également ne pas avoir été conçue pour négocier avec l'adresse IP de l'ordinateur source. En terminologie IPSec, le trafic réseau qui n'utilise pas IPSec est appelé trafic en texte clair. Si l'ordinateur cible ne répond pas sous trois secondes, une association de sécurité logicielle (SA logicielle) est créée et la communication est entamée en texte clair. Pour vos premiers déploiements, nous vous conseillons d'activer cette option afin que les clients puissent communiquer avec les hôtes sur lesquels IPSec n'est pas activé. De même, le recours à cette option permet aussi d'établir à nouveau une connectivité provisoire en texte clair lorsque vous arrêtez le service IPSec à des fins de dépannage. Si l'ordinateur cible fournit une réponse IKE et qu'un échec de la
113
négociation IKE survient pour une raison quelconque, IPSec ignore les paquets sortants sur l'ordinateur source et bloque véritablement la communication. Pour activer l'option Communiquer en texte clair, activez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans la boîte de dialogue Gérer les actions de filtrage. Remarque : le mode de fonctionnement de cette option a évolué sur les ordinateurs fonctionnant sous Windows 2000 SP3 (ou ultérieur), Windows XP SP1 ou Windows Server 2003. Si vous activez uniquement cette option, le système pourra lancer une communication sécurisée mais n'acceptera aucune demande de communication de systèmes n'utilisant pas IPSec. Si le système doit répondre à des demandes en provenance de systèmes qui n'utilisent pas IPSec et établir une communication avec ces systèmes, vous devez activer à la fois les cases à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec et Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec. Si le système fonctionne sous Windows 2000 ou Windows XP sans les service packs appropriés, le client accepte les demandes de communication non sécurisée dès que vous sélectionnez l'option Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec, même si la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec est désactivée. Ce comportement se produit parce que lorsque vous activez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec, IPSec traite le filtre entrant associé en tant que filtre relais entrant (le même comportement que lorsque vous activez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec). Utiliser la session de clé principale PFS (Perfect Forward Secrecy) L'option Utiliser la session de clé principale PFS (Perfect Forward Secrecy) permet de déterminer si la clé principale peut générer toutes les clés de session ou seulement la première. En activant cette option, vous ne pourrez utiliser la clé principale qu'une seule fois et chaque renégociation de clé de session supplémentaire exigera un nouvel échange de clés pour générer une nouvelle clé principale avant de générer la clé de session. Cette exigence garantit qu'en cas de clé principale compromise, l'attaquant ne peut générer aucune clé de session supplémentaire lui permettant de déchiffrer le flux de trafic. Nous vous déconseillons d'activer cette option en raison de la charge supplémentaire qu'implique un échange de clés à chaque intervalle de renouvellement de clé de session. Pour plus d'informations sur les options Relais entrant, Communiquer en texte clair et les options de clé de session et de clé principale PFS, reportezvous à la section « Security Negotiation Options » (Options de négociation de sécurité) du document Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server (Utilisation de Microsoft Windows IPSec pour aider à sécuriser un serveur de réseau d'entreprise interne) disponible depuis le Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?familyid=a774012aac254a1d8851 b7a09e3f1dc9&displaylang=en. Actions de filtrage IPSec de la Woodgrove Bank Le tableau ciaprès fournit les noms et les descriptions des actions de filtrage utilisées pour l'implémentation des divers groupes d'isolation intervenant dans le scénario de la Woodgrove Bank. Tableau 5.4 : Actions de filtrage IPSec et descriptions Action de filtrage
Description
IPSec – Block (Bloquer)
Bloque le trafic correspondant au filtre.
114
IPSec – Permit (Autoriser)
Autorise le trafic correspondant au filtre.
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant)
Un hôte accepte les paquets entrants qui sont soit de type IPSec, soit en texte clair. Pour le trafic sortant, il déclenche une négociation IKE et autorise l'option Communiquer en texte clair s'il ne reçoit aucune réponse. Cette action de filtrage est utilisée pour la configuration du groupe d'isolation de limite.
IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant)
Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les paquets sont sécurisés par IPSec et ignore les paquets entrants nonIPSec. Pour le trafic sortant, il déclenche une négociation IKE et autorise l'option Communiquer en texte clair s'il ne reçoit aucune réponse. Ce filtre sert à l'implémentation du domaine d'isolation dans lequel les connexions sortantes vers les hôtes approuvés sont autorisées.
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) (Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
Un hôte exige des communications sécurisées IPSec pour les paquets entrants comme pour les paquets sortants. Cette action de filtrage permet d'implémenter le groupe d'isolation sans basculement dans lequel toutes les communications sont protégées par IPSec.
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les paquets sont sécurisés par chiffrement ESP 3DES IPSec et ignore les paquets entrants nonIPSec. Pour le trafic sortant, il déclenche une négociation IKE exigeant un chiffrement ESP 3DES IPSec. Cette action de filtrage est utilisée pour la configuration du groupe d'isolation de chiffrement.
Les deux premières actions de filtrage sont simples à réaliser. L'action de filtrage Bloquer ignore tout le trafic correspondant au filtre d'une liste de filtres associée à l'action. L'action de filtrage Autoriser autorise le trafic pour n'importe quelle liste de filtres associée contenant le filtre correspondant. Les quatre dernières actions de filtrage présentées dans le tableau 5.4 sont utilisées pour l'implémentation des groupes d'isolation dans le scénario de la Woodgrove Bank. Les administrateurs de la Woodgrove Bank ont quatre groupes d'isolation de sécurité à implémenter. Pour déployer cette configuration, vous devez définir au minimum trois actions de filtrage dotées de méthodes de négociation de sécurité personnalisées en plus des actions de filtrage Autoriser et Bloquer. La Woodgrove Bank n'impose aucune exigence supplémentaire pour l'isolation mutuelle des ordinateurs au sein d'un groupe d'isolation de sécurité spécifique. La Woodgrove Bank a établi que les quatre actions de filtrage négociées dans le tableau cidessous suffisent à la mise en place de son environnement : Tableau 5.5 : Méthodes de sécurité prises en charge Action de filtrage IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant) IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant) IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) 115
Méthodes de sécurité prises en charge ESP – SHA1,
(Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
ESP – SHA1, 3DES
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
ESP – SHA1, 3DES
La Woodgrove Bank utilise IPSec ESP au lieu du protocole AH en raison de la présence de périphériques réseau utilisant la traduction d'adresses réseau (NAT) dans l'organisation. La Woodgrove Bank exige également le chiffrement de certains serveurs de l'organisation. Par conséquent, toutes les stratégies nécessitent la possibilité de recourir au chiffrement. C'est pourquoi la Woodgrove Bank a choisi de développer sa sécurité uniquement sur la base du protocole IPSec ESP. Pour l'intégrité ESP, Woodgrove Bank a opté pour l'algorithme SHA1 (au lieu de MD5) parce qu'il offre une meilleure sécurité mais aussi parce qu'elle doit respecter les réglementations du gouvernement américain relatives au traitement de données financières, impliquant l'usage d'algorithmes approuvés. La Woodgrove Bank a décidé de ne pas implémenter le service PFS (Perfect Forward Secrecy) dans toutes les actions de filtrage car aucune menace de sécurité spécifique n'exigeait l'utilisation de ce service. Woodgrove cherche également à éviter l'impact de la renégociation des clés sur les performances des ordinateurs. Action de filtrage du domaine d'isolation Pour implémenter le domaine d'isolation, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage « IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) ». Pour diverses raisons commerciales, les hôtes du domaine d'isolation et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du domaine d'isolation doivent donc effectuer les actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 du présent guide :
• Établir des communications avec les hôtes du groupe d'isolation sans basculement. • Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du groupe d'isolation de chiffrement. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec les hôtes du groupe d'isolation de limite. • Accepter les communications provenant des hôtes du groupe d'isolation de limite. • Établir une communication avec des systèmes non approuvés Les clients du domaine d'isolation ne peuvent pas accepter des communications provenant de systèmes non approuvés. Souvenezvous que la stratégie IPSec utilise des filtres et des actions de filtrage pour intercepter et contrôler les paquets IP entrants et sortants. Bien qu'IKE authentifie les deux ordinateurs, l'appartenance à un groupe d'un ordinateur utilisant une adresse IP donnée n'est pas connue au moment de l'envoi de la demande initiale de connexion. Par conséquent, IPSec et IKE ne peuvent pas être spécifiquement configurés pour établir des communications d'une manière précise avec une identité ou un groupe d'isolation particulier. De même, les ordinateurs membres de ces groupes
116
d'isolation peuvent résider n'importe où sur le réseau interne. Vous ne pouvez donc pas utiliser des adresses IP pour définir de manière précise ou approximative les groupes d'isolation. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites cidessus en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ; ignorer le trafic s'il n'est pas déjà sécurisé dans des paquets IPSec ESP valides.
Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de sécurité incluent les méthodes de sécurité (algorithmes ESP–SHA1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportezvous à la section « Action de filtrage du groupe d'isolation de chiffrement » plus loin dans ce chapitre. Pour le trafic au sein du domaine d'isolation et avec les groupes d'isolation de limite et sans basculement, la Woodgrove Bank utilise ESPNull avec l'algorithme SHA1. Vous devez désactiver la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSecdans l'action de filtrage afin que les communications entrantes en texte clair soit ignorées. Cette approche garantit que les hôtes du domaine d'isolation n'accepteront pas le trafic d'un ordinateur qui ne participe pas à l'environnement IPSec. L'action de filtrage IPSEC – Secure Request Security (Ignore Inbound, Allow Outbound) est configurée afin de permettre aux membres du domaine d'isolation d'établir des communications avec des systèmes non approuvés. Vous pouvez opter pour ce comportement en activant la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans l'action de filtrage. Si un hôte approuvé du domaine d'isolation établit une connexion sortante avec un hôte non approuvé (ou un autre système n'utilisant pas IPSec), l'association de sécurité logicielle IPSec est établie et demeure active pendant cinq minutes après l'arrêt du trafic. Pendant ce laps de temps, le système non approuvé est donc capable d'établir de nouvelles connexions en texte clair dans l'hôte approuvé. Une fois le délai de l'association de sécurité logicielle expiré, l'hôte approuvé ne pourra plus accepter aucun trafic en texte clair provenant de ce système. La prise en charge du filtrage IPSec et des associations de sécurité logicielles n'a pas été conçue en vue de fournir des mesures de protection spécifiques aux connexions (par exemple, le filtrage avec état), comme c'est le cas avec un grand nombre de parefeu. Les associations de sécurité logicielles autorisent tout le trafic correspondant au filtre associé. Pour plus d'informations sur ce processus, reportezvous à la section « SA de mode principal IKE et SA IPSec» de l'annexe A (« Présentation des concepts relatifs à la stratégie IPSec »). Action de filtrage du groupe d'isolation de limite Pour implémenter le groupe d'isolation de limite, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage IPSEC – Request Mode (Accept Inbound, Allow Outbound). Pour diverses raisons commerciales, les hôtes du groupe d'isolation de limite et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de limite doivent donc effectuer les actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 :
• Établir des communications avec les hôtes du groupe d'isolation sans basculement. 117
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec des systèmes non approuvés. • Accepter des communications provenant de systèmes non approuvés. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, accepter les paquets en texte clair adaptés aux filtres correspondants (tous les sous réseaux internes).
Pour répondre aux exigences d'établissement et d'acceptation du trafic vers et depuis le domaine d'isolation et le groupe d'isolation sans basculement, la Woodgrove Bank s'est assurée que les méthodes de négociation de sécurité pour le domaine d'isolation et le groupe d'isolation sans basculement étaient présentes dans l'action de filtrage. La méthode de négociation de sécurité commune retenue par la Woodgrove Bank est ESP avec l'algorithme SHA1 pour la vérification de l'intégrité. Les hôtes du groupe d'isolation de limite sont autorisés à communiquer avec des systèmes non approuvés. Pour faciliter cette fonction, l'équipe administrative de la Woodgrove Bank a activé à la fois les cases à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec et Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec pour cette action de filtrage. En activant ces deux options, la Woodgrove Bank a la garantie que les hôtes accepteront le trafic entrant non sécurisé et pourront communiquer en texte clair pour le trafic sortant non sécurisé. Action de filtrage du groupe d'isolation sans basculement Pour l'implémentation du groupe d'isolation sans basculement, les administrateurs de la Woodgrove Bank ont créé l'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound). Pour diverses raisons commerciales, les hôtes du groupe d'isolation sans basculement et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation sans basculement peuvent donc effectuer les actions suivantes :
• Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Établir des communications avec les hôtes du groupe d'isolation de chiffrement. • Accepter des communications avec les hôtes du groupe d'isolation de chiffrement. • Établir des communications avec les hôtes du groupe d'isolation de limite.
118
• Accepter les communications provenant des hôtes du groupe d'isolation de limite. Les clients du groupe d'isolation sans basculement ne peuvent ni établir, ni accepter des communications provenant de systèmes non approuvés. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, utiliser de préférence ESPNull et inclure ESP–SHA1–3DES. Ne pas autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sousréseaux internes) ; les ignorer.
Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de négociation de sécurité incluent les méthodes de négociation de chiffrement (algorithmes ESP–SHA 1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportezvous à la section « Action de filtrage du groupe d'isolation de chiffrement » plus loin dans ce chapitre. Pour le trafic vers les groupes d'isolation de limite et sans basculement, la Woodgrove Bank utilise ESP avec l'algorithme SHA1 comme méthode de négociation de sécurité pour vérifier l'intégrité. La case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec dans l'action de filtrage est désactivée pour créer le groupe d'isolation sans basculement. Cette approche garantit que les hôtes du groupe d'isolation sans basculement sécurisent tout le trafic entrant et sortant avec IPSec. Tout trafic provenant d'un ordinateur qui ne participe pas à l'environnement IPSec est ainsi refusé. L'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) ne permet pas à un ordinateur qui utilise cette action d'établir une communication avec un ordinateur qui ne participe pas à l'infrastructure IPSec. La case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec a été désactivée pour appliquer cette exigence. Action de filtrage du groupe d'isolation de chiffrement La Woodgrove Bank a choisi ESP en tant que protocole d'intégrité de base et l'algorithme SHA1 en tant qu'option cryptographique. De plus, les hôtes du groupe d'isolation de chiffrement ont besoin de communiquer avec ceux du domaine d'isolation et du groupe d'isolation sans basculement. L'action de filtrage a été configurée afin d'inclure les méthodes de négociation de sécurité chargées de chiffrer les informations. Pour diverses raisons commerciales, les hôtes du groupe d'isolation de chiffrement et d'autres groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de chiffrement peuvent donc effectuer les actions suivantes du tableau 4.6 :
• Établir des communications avec les hôtes du domaine d'isolation. • Accepter les communications provenant des hôtes du domaine d'isolation. • Établir des communications avec les hôtes du groupe d'isolation sans basculement.
119
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement. • Établir des communications avec les hôtes du groupe d'isolation de limite. Les ordinateurs du groupe d'isolation de chiffrement ne sont pas autorisés à accepter des communications en provenance d'hôtes du groupe d'isolation de limite. Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui fonctionnera avec la liste de filtres spécifiant tous les sousréseaux internes. Vous pouvez regrouper les exigences décrites en deux comportements de base :
• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sousréseaux internes) ;
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec ESP–SHA1– 3DES uniquement. Ne pas autoriser la communication en texte clair si un hôte de destination cible ne répond pas avec IKE.
• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sousréseaux internes) ; les ignorer. Accepter uniquement les demandes de négociation IKE issues d'hôtes approuvés autorisant IPSec ESP–SHA1–3DES.
Les clients du groupe d'isolation de chiffrement ne peuvent pas accepter de communications en provenance du groupe d'isolation de limite, ni accepter ou établir de communications issues de systèmes non approuvés. Pour permettre les communications avec le domaine d'isolation, les méthodes de négociation de sécurité de chiffrement adoptées pour l'action de chiffrement IPSEC – Require Encryption Mode (Ignore Inbound, Disallow Outbound) sont également disponibles dans les actions de filtrage IPSEC – Secure Request (Ignore Inbound, Allow Outbound) et IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound). Woodgrove Bank utilise la méthode de chiffrement 3DES qui offre une meilleure sécurité que la méthode DES, mais représente une charge plus élevée. Pour répondre à la nécessité de ne pas accepter ou établir de communications avec des systèmes non approuvés, la Woodgrove Bank n'a pas activé la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec. Cette configuration garantit que les hôtes du groupe d'isolation de chiffrement n'accepteront pas le trafic d'un ordinateur qui ne participe pas à l'environnement IPSec. De plus, l'option Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec a elle aussi été désactivée pour empêcher des ordinateurs de chercher à établir des communications avec un autre ordinateur ne participant pas à l'environnement IPSec. Le blocage des communications IPSec à partir des ordinateurs du groupe d'isolation de limite impliquait d'autres tâches de configuration. Les administrateurs de la Woodgrove Bank ont attribué le droit « Refuser l'accès à cet ordinateur à partir du réseau » à l'objet Stratégie de groupe chargé de fournir la stratégie IPSec aux ordinateurs du groupe d'isolation de chiffrement. Ce droit a été appliqué à un groupe comprenant tous les comptes d'ordinateurs des systèmes participant au groupe d'isolation de limite. Si l'un de ces ordinateurs tentait d'établir des communications avec un système du groupe d'isolation de chiffrement, l'authentification IKE aboutirait à un refus d'autorisation et la communication serait bloquée.
Stratégies IPSec Les stratégies IPSec permettent de configurer des ordinateurs Windows pour qu'ils fonctionnent dans un environnement IPSec. Une stratégie IPSec désigne un ensemble de règles appliquées au trafic. Il existe trois types de stratégies IPSec pour Windows 2000 :
120
• Stratégie locale • Stratégie de domaine Active Directory • Stratégie dynamique Windows XP et Windows Server 2003 prennent en charge les types de stratégies supplémentaires suivants :
• Stratégie IPSec de démarrage. Stockée et gérée dans le Registre local. Prise en charge
uniquement sous Windows XP SP2 ou ultérieur. Elle est appliquée dès que l'ordinateur obtient une adresse IP, ce qui peut survenir avant le démarrage du service IPSec. Elle est remplacée lorsque le service applique une stratégie persistante.
• Stratégie IPSec persistante. Stockée et gérée dans le Registre de l'ordinateur local. Configurée à l'aide de l'outil de ligne de commande. Elle est appliquée en premier au démarrage du service IPSec. Elle remplace la stratégie de démarrage.
• Stratégie IPSec locale. Stockée et gérée dans l'ordinateur local. Configurée à l'aide du composant logiciel enfichable MMC (Microsoft Management Console) Gestion de stratégie IPSec ou de l'outil de ligne de commande. Elle est appliquée en plus de la stratégie persistante si aucune stratégie de domaine n'est définie.
• Stratégie IPSec de domaine Active Directory. Stockée dans Active Directory. Gérée par le
composant logiciel enfichable MMC Gestion de stratégie IPSec ou l'outil de ligne de commande. Elle remplace toutes les stratégies locales susceptibles d'être attribuées. Les stratégies IPSec Active Directory sont affectées à un objet Stratégie de groupe par l'intermédiaire du composant logiciel enfichable MMC Éditeur de stratégies de groupe ou la console de gestion des stratégies de groupe (GPMC) disponible sous Paramètres Windows, Paramètres de sécurité et Stratégies IPSec.
• Stratégie IPSec dynamique. Stockée uniquement en mémoire. Configurée à l'aide de l'outil de ligne de commande. Elle permet d'ajouter de manière dynamique des éléments à la stratégie existante. La stratégie dynamique est ignorée dès l'arrêt du service IPSec.
Pour des raisons de simplicité, le présent guide s'intéresse uniquement à l'utilisation de la stratégie IPSec dans le domaine Active Directory. Lorsque vous définissez des stratégies IPSec, il est préférable d'essayer de créer une stratégie générique qui sera la base de l'infrastructure IPSec pour tous les ordinateurs. Vous pouvez ensuite créer des stratégies supplémentaires pour appliquer des paramètres plus stricts aux systèmes exigeant une configuration de sécurité supplémentaire. Chaque stratégie supplémentaire doit cibler le plus grand nombre possible d'ordinateurs devant répondre à des exigences commerciales ou techniques particulières. En limitant le nombre total des stratégies, vous faciliterez la gestion des stratégies et la résolution des problèmes qui en découlent. Les stratégies IPSec sont composées d'un nom, d'une description, d'un ensemble de règles, de paramètres de configuration pour les fréquences d'interrogation, ainsi que de paramètres et de méthodes d'échange de clés. La section qui suit aborde tous ces éléments en détail. Nom Tout comme pour les actions de filtrage, vous devez attribuer des noms significatifs aux stratégies afin de faciliter la gestion et la résolution des problèmes liés à la solution pendant les phases d'implémentation et d'exploitation du projet.
121
Description Une description détaillée de la stratégie permettra aux administrateurs d'identifier l'objectif de la stratégie sans avoir à l'ouvrir et étudier les règles qui la définissent. Règles Une règle IPSec se compose d'une liste de filtres unique, d'une action de filtrage associée, des méthodes d'authentification employées pour établir le niveau d'approbation entre les ordinateurs, d'un type de connexion et du type de tunnel (le cas échéant). Chaque règle définit une ou plusieurs méthodes d'authentification à utiliser pour établir le niveau d'approbation entre les hôtes. Les options proposées sont le protocole Kerberos version 5, des certificats provenant d'une autorité de certification précise et des clés prépartagées. Le type de connexion définit les connexions auxquelles la stratégie IPSec s'applique. Vous pouvez configurer la stratégie pour l'appliquer à l'ensemble des connexions, à des connexions au réseau local ou à des connexions d'accès à distance. Le type de tunnel détermine si la stratégie IPSec définit un tunnel IPSec. Si le type de tunnel est désactivé, IPSec utilise le mode de transport. Pour prendre en charge les groupes d'isolation de sécurité identifiés plus haut dans ce guide, la Woodgrove Bank a mis en place quatre stratégies IPSec. Elle a les toutes configurées afin qu'elles utilisent le protocole d'authentification Kerberos version 5, soient appliquées à l'ensemble des connexions et ne définissent pas un tunnel IPSec. Le tableau cidessous décrit les stratégies adoptées dans le scénario de la Woodgrove Bank : Tableau 5.6 : Stratégies IPSec de la Woodgrove Bank Nom de stratégie
Description
IPSEC – Isolation Domain IPSec Policy (1.0.041001.1600) (Stratégie IPSec de domaine d'isolation)
Cette stratégie définit le domaine d'isolation. Les hôtes de ce groupe d'isolation ont la capacité de communiquer en texte clair lorsqu'ils établissent des communications avec des hôtes nonIPSec. Elle configure les hôtes pour qu'ils exigent une communication IPSec. Si la négociation échoue entre les clients utilisant IPSec, la communication échoue elle aussi.
IPSEC – Boundary Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de limite)
Cette stratégie définit le groupe d'isolation de limite. Elle configure les hôtes pour qu'ils demandent des communications IPSec mais leur permet de communiq uer en t exte cla ir si le s commun ications doivent être établies avec un hôte n'utilisant pas IPSec.
IPSEC – No Fallback Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation sans basculement)
Cette stratégie définit le groupe d'isolation sans basculement. Elle configure les hôtes pour qu'ils exigent une communication IPSec. Si la négociation échoue ou en cas de tentative de communication avec un client qui n'utilise pas IPSec, la communication échoue.
IPSEC – Encryption Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation
Cette stratégie définit le groupe d'isolation de chiffrement. Elle configure les hôtes pour qu'ils exigent une communication et un chiffrement IPSec. Si la négociation échoue ou en cas de tentative de communication avec un client qui n'utilise pas IPSec, la
122
de chiffrement)
communication échoue.
Le nombre associé à chaque nom de stratégie correspond à un numéro de version, comme expliqué plus loin dans la section « Versions des stratégies ». Chacune des stratégies de la Woodgrove Bank renferme les mêmes listes d'exemptions puisqu'il n'existe aucune exigence d'exemption d'un ensemble spécial d'ordinateurs pour un groupe d'isolation particulier. Le tableau ciaprès présente les règles activées et communes aux quatre stratégies identifiées dans le tableau précédent : Tableau 5.7 : Règles communes définies dans les stratégies IPSec de la Woodgrove Bank Liste de filtres
Action de filtrage
Méthodes d'authentification
Point de sortie du tunnel
Type de connexion
DNS Exemption List (Liste d'exemptions DNS)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
Domain Controllers Exemption IPSEC – List (Liste d'exemptions de Permit contrôleurs de domaine) (Autoriser)
Aucun
Aucun
Tous
Liste d'exemptions WINS (WINS Exemptions List)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
DHCP, Negotiation Traffic (DHCP, trafic de négociation)
IPSEC – Permit (Autoriser)
Aucun
Aucun
Tous
ICMP, All Traffic (ICMP, tout le IPSEC – trafic) Permit (Autoriser)
Aucun
Aucun
Tous
En plus des règles énumérées dans ce tableau, la règle de réponse client par défaut est désactivée dans chaque stratégie. Les quatre stratégies définies par la Woodgrove Bank diffèrent uniquement dans leur manière de gérer le trafic qui n'est traité par aucune des listes de filtres d'exemption. Pour chacune de ces règles, la méthode d'authentification employée est le protocole Kerberos version 5, le point de sortie du tunnel est défini à None (Aucun) et le type de connexion est All (Toutes). Le tableau ciaprès affiche les règles d'implémentation des quatre groupes d'isolation de la Woodgrove Bank : Table 5.8: Règles d'implémentation de base des groupes d'isolation de la Woodgrove Bank Nom de stratégie
Liste de filtres
IPSEC – Isolation Domain IPSec Policy Sousréseaux (1.0.041001.1600) (Stratégie IPSec de sécurisés de domaine d'isolation) Woodgrove Bank
123
Action de filtrage IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée Ignorer le trafic entrant, Autoriser le trafic sortant)
IPSEC – Boundary Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de limite)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête Accepter le trafic entrant, Autoriser le trafic sortant)
IPSEC – No Fallback Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation sans basculement)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) (Mode requis complet Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
IPSEC – Encryption Isolation Group IPSec Policy (1.0.041001.1600) (Stratégie IPSec de groupe d'isolation de chiffrement)
Sousréseaux sécurisés de Woodgrove Bank
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)
La Woodgrove Bank a choisi d'utiliser le protocole Kerberos version 5 comme unique protocole d'authentification. Elle n'utilise pas de clés prépartagées puisque la valeur de clé d'authentification peut être lue par des administrateurs locaux du Registre et par n'importe quels utilisateur authentifié et ordinateur sur le domaine. Elle n'a pas choisi non plus de certificats puisqu'elle ne dispose pas d'une infrastructure de clés publiques (PKI) déployée. Grâce au protocole Kerberos version 5, tous les ordinateurs associés à des domaines peuvent participer à l'infrastructure IPSec puisqu'ils peuvent authentifier et se procurer une stratégie. Les ordinateurs qui ne sont pas associés à des domaines ne peuvent pas facilement participer à l'environnement IPSec en raison de l'absence d'un mécanisme d'authentification et d'un système de distribution des stratégies. Si ces ordinateurs répondent aux critères des hôtes approuvés, vous pouvez configurer une stratégie IPSec locale à l'aide de l'authentification de certificats pour leur permettre de communiquer avec d'autres hôtes approuvés. Pour l'heure, la Woodgrove Bank traite les ordinateurs n'appartenant pas à des domaines en tant qu'ordinateurs non approuvés. Remarque : l'utilisation du protocole Kerberos version 5 pour l'authentification IKE n'empêche pas les ordinateurs qui n'appartiennent pas à des domaines de participer à l'environnement IPSec. Par exemple, si un système UNIX est correctement configuré pour l'utilisation d'Active Directory comme domaine Kerberos et si la structure IKE mise en place prend en charge l'authentification Kerberos, il peut alors participer au domaine d'isolation. Néanmoins, une configuration de ce type va audelà de la portée du présent document et n'a pas été testée par Microsoft. Fréquences d'interrogation Deux fréquences d'interrogation sont à prendre en compte : la fréquence d'interrogation de la stratégie de groupe et celle du service IPSec. Le paramètre par défaut de fréquence d'interrogation de modification de stratégie du service IPSec est de 180 minutes entre deux interrogations consécutives pour les changements des stratégies IPSec Active Directory. Ces interrogations vérifient uniquement les modifications apportées à la stratégie IPSec ; elles ne détectent pas les changements d'appartenance à un domaine ou une unité d'organisation ou bien l'affectation ou la suppression d'une stratégie IPSec dans un objet Stratégie de groupe. La détection des modifications d'appartenance à l'unité d'organisation d'un ordinateur et de l'affectation d'objets Stratégie de groupe s'effectue par interrogation du service Stratégie de groupe toutes les 90 minutes par défaut. La Woodgrove Bank a choisi de définir ces deux fréquences d'interrogation à 60 minutes afin que, si la nécessité d'une réponse de sécurité se présente, les stratégies puissent être mises à jour et déployées en une heure pour minimiser les risques. Cette fréquence d'interrogation accrue ajoute un trafic d'interrogation supplémentaire sous la forme de requêtes LDAP soumises par le client pour
124
vérifier les valeurs d'horodatage dans les stratégies IPSec. Même si cette augmentation ne se traduit pas par une charge significative dans le scénario de la Woodgrove Bank, elle peut être considérable dans des déploiements impliquant un grand nombre de clients. Paramètres d'échange de clés Les paramètres d'échange de clés suivants définissent le mode d'obtention des nouvelles clés et leur fréquence de renouvellement. Le terme « clé principale » désigne la clé secrète partagée Diffie Hellman générée en mode principal IKE. Le terme « clé de session » se rapporte aux clés générées en mode rapide IKE en vue d'être utilisées dans les algorithmes de chiffrement et d'intégrité IPSec. Les clés de session sont dérivées de la clé principale.
• PFS (Perfect Forward Secrecy). Il existe deux types de composants PFS dans IKE : la clé
principale PFS (soit le mode principal PFS) et la clé de session PFS (mode rapide PFS). Le mode principal PFS n'est pas conseillé car les fonctionnalités sont dupliquées par d'autres paramètres d'échange de clés pris en charge. Le mode principal PFS exige qu'IKE réauthentifie et négocie une nouvelle clé principale chaque fois qu'un mode rapide est exécuté pour actualiser les clés de session. Cette condition garantit à chaque fois qu'une clé de chiffrement doit être actualisée, les deux ordinateurs repartent de zéro avec une nouvelle négociation en mode rapide et en mode principal IKE. Cette protection supplémentaire implique une charge supplémentaire. La clé de session PFS génère une nouvelle clé principale en mode rapide (sans authentification en mode principal), puis extrait les nouvelles clés de session à partir de la nouvelle clé principale. Cette fonctionnalité garantit qu'un grand nombre de données (voire la totalité des données) de la communication ne sont pas uniquement protégées par une seule valeur de clé principale et qu'une quantité infime de données chiffrées serait dévoilée si un attaquant parvenait à découvrir la clé principale. La clé de session PFS est disponible sous la forme d'une case à cocher dans les méthodes de sécurité d'une action de filtrage. Utilisezla uniquement là où le trafic protégé IPSec est exposé à des risques d'attaques cryptographiques complexes dans la clé principale Diffie Hellman.
• Authentifier et générer une nouvelle clé toutes les <nombre> minutes. Cette valeur définit la
durée de vie de l'association de sécurité en mode principal IKE (fixée à 480 minutes par défaut). Elle contrôle la durée d'utilisation de la clé principale et de la relation d'approbation avant leur renégociation. La première connexion TCP/IP entre un client unique et l'hôte entraîne la création d'une nouvelle association de sécurité en mode principal IKE. Contrairement aux associations de sécurité logicielles, les associations de sécurité en mode principal ne sont pas supprimées de l'hôte après cinq minutes d'inactivité. Les associations de sécurité en mode principal exigent environ 5 kilooctets de mémoire chacune. En ajustant cette valeur, l'administrateur peut optimiser la charge processeur et la capacité mémoire requises par IKE. En réduisant la durée de vie, vous réduisez le nombre d'associations de sécurité en mode principal actives sur le serveur. Cela permet d'économiser de la mémoire et du temps de traitement IKE, en maintenant moins d'associations de sécurité. Néanmoins, vous pouvez augmenter la charge processeur requise pour renégocier les associations de sécurité en mode principal pour les clients qui communiquent fréquemment.
• Authentifier et générer une nouvelle clé toutes les <nombre> sessions. Ce paramètre contrôle le nombre maximal d'opérations en mode rapide IKE autorisées pendant la durée de vie d'une association de sécurité en mode principal, limitant ainsi le nombre de clés de session qu'il est possible de générer à partir de la même clé principale. Une fois cette limite atteinte, une nouvelle association de sécurité en mode principal IKE est négociée pour la création d'une nouvelle clé principale. Le paramètre par défaut est 0, ce qui signifie l'absence de limite. La clé principale est donc uniquement actualisée lorsque la durée de vie de l'association de sécurité en mode principal IKE arrive à expiration, à moins que vous n'utilisiez le mode rapide PFS. Pour obtenir le même comportement que le paramètre de la clé principale PFS, cette option est définie à 1.
125
La Woodgrove Bank a choisi de ne pas recourir à la clé principale PFS puisque aucune exigence de sécurité spécifique ne le justifie. De même, le service PFS en mode rapide IKE n'a pas été utilisé dans les actions de filtrage. La durée de vie des associations de sécurité en mode principal IKE est passée de 480 minutes à 180 minutes pour supprimer plus rapidement les associations de sécurité en mode principal sur les serveurs occupés dans tous les groupes d'isolation, à l'exception du groupe d'isolation de limite. Pour ce dernier, les administrateurs de la Woodgrove Bank ont réduit la durée de vie des associations de sécurité en mode principal IKE à 20 minutes pour diminuer la surface d'attaque exposée par les associations de sécurité en mode principal résidentes qui ont été négociées avec le groupe d'isolation de chiffrement. Bien que les hôtes du groupe d'isolation de limite ne puissent pas entamer de nouvelles négociations IKE avec les hôtes du groupe d'isolation de chiffrement, l'inverse peut se produire. Une fois l'association de sécurité en mode principal établie, un hôte du groupe d'isolation de limite peut l'utiliser pour négocier des associations de sécurité en mode rapide pour la protection du trafic entrant sur le système correspondant dans le groupe d'isolation de chiffrement jusqu'à ce que l'association de sécurité en mode principal soit supprimée. Vous pouvez minimiser les risques en forçant la suppression à intervalles plus réguliers des associations de sécurité en mode principal sur les serveurs du groupe de limite. Le nombre de sessions pour lesquelles vous pouvez utiliser la clé principale pour la création d'une clé de session est resté à 0 (paramètre par défaut). Méthodes d'échange de clés Les méthodes d'échange de clés permettent de contrôler les méthodes de sécurité employées lors de la négociation IKE en mode principal. Les options de configuration concernent l'intégrité (SHA1 et MD5), la confidentialité ou le chiffrement (3DES et DES) et la longueur des nombres premiers de base adoptés lors du processus d'échange de clés. Remarque : pour utiliser 3DES, les ordinateurs équipés de Windows 2000 doivent disposer du pack de chiffrement élevé ou de SP2 (ou ultérieur). La puissance de chiffrement des clés utilisées pour l'intégrité et le chiffrement de la négociation IKE ellemême et la protection des données IPSec dépend de la puissance du groupe DiffieHellman sur lequel les nombres premiers sont fondés. Trois options sont proposées pour le groupe DiffieHellman :
• Haute (3) – puissance de clé 2048 bits. Cette option correspond à la norme IETF RFC 3526 du
groupe DiffieHellman 14. Cette puissance de clé est indispensable pour que 3DES bénéficie d'un niveau de chiffrement maximal. Reportezvous à la norme IETF RFC 3526 pour plus d'informations.
• Moyenne (2) – puissance de clé 1024 bits. • Faible (1) – puissance de clé 768 bits. La configuration Haute concerne exclusivement les systèmes dotés de Windows XP SP2 et Windows Server 2003. La configuration Moyenne offre une interopérabilité avec Windows 2000 et Windows XP SP1. La configuration Faible est fournie pour une compatibilité descendante. Du fait de sa faiblesse relative, il est préférable d'éviter de l'utiliser. Le tableau cidessous répertorie par ordre de préférence les méthodes de sécurité d'échange de clés que la Woodgrove Bank a choisi d'implémenter : Tableau 5.9 : Méthodes de sécurité d'échange de clés par défaut Chiffrement
Intégrité
Groupe DiffieHellman
3DES
SHA1
Haute (3) 2048 bits
126
3DES
SHA1
Moyenne (2) 1024 bits
3DES
MD5
Moyenne (2) 1024 bits
Remarque : l'utilisation du groupe 2048 bits dans la stratégie IPSec exige que vous configuriez cette dernière à l'aide des outils de gestion de Windows Server 2003, notamment le composant logiciel enfichable MMC Gestion de stratégie IPSec ou l'utilitaire de ligne de commande Netsh IPSec. Vous pouvez affecter cette stratégie au domaine sur les platesformes Windows 2000, ce qui exclut l'utilisation de l'option 2048 bits. Versions des stratégies Il est probable que la conception des stratégies IPSec change plusieurs fois au cours de la planification initiale, des tests en laboratoire, des déploiements pilote et pendant l'utilisation opérationnelle. Si vous utilisez des scripts, des feuilles de calcul ou d'autres documents pour créer des stratégies IPSec, vous devez gérer ces fichiers à l'aide d'un système de contrôle des versions semblable à Microsoft Visual SourceSafe®. Il est difficile d'identifier les versions des stratégies IPSec dans Active Directory en examinant les attributs de la stratégie. Lors du dépannage, vous devrez être en mesure de déterminer la version de la stratégie IPSec active sur l'ordinateur. C'est pourquoi nous vous conseillons de stocker les informations sur les versions sous une forme quelconque à la fois dans le nom et dans les règles de la stratégie. Une méthode simple consiste à créer un ID de version fondé sur la formule suivante : <Major Change>.<Minor Change>.
127
Après avoir créé cette liste de filtres dans Active Directory, vous pouvez identifier le nom unique de l'objet de version de la liste de filtres à l'aide du composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory fonctionnant en mode avancé. Vous pouvez rechercher l'objet liste de filtres dans l'arborescence
Procédure d'application des stratégies IPSec à des ordinateurs individuels L'étape finale de l'activation d'IPSec consiste à déployer les stratégies sur les hôtes. Il existe deux méthodes de déploiement des stratégies. L'une consiste à appliquer directement les stratégies sur les ordinateurs hôtes individuels ; l'autre passe par l'utilisation des objets Stratégie de groupe et d'Active Directory. L'application des stratégies via Active Directory est abordée dans la section « Application des stratégies IPSec à l'aide d'objets Stratégie de groupe » plus loin dans ce chapitre. Deux méthodes vous permettent d'appliquer des stratégies IPSec sur des ordinateurs individuels : via le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec ou par le biais de la ligne de commande en exécutant l'outil Netsh (pour Windows Server 2003), Ipseccmd.exe (pour Windows XP) ou Ipsecpol.exe (pour Windows 2000). Le composant logiciel enfichable MMC fournit une interface utilisateur graphique qui permet à l'administrateur d'appliquer manuellement la stratégie ou d'importer une stratégie IPSec définie au préalable et exportée depuis un autre ordinateur. Outre la manipulation de la stratégie sur l'ordinateur local, le composant logiciel enfichable permet aux administrateurs de gérer une stratégie sur un ordinateur distant. Des informations détaillées sur les outils de ligne de commande sont disponibles à partir des ressources suivantes :
• Aide et support Windows Server 2003 pour Netsh • Documentation des outils de support Windows XP pour Ipseccmd.exe • Kit de ressources Windows 2000 Server pour Ipsecpol.exe
128
Vous pouvez vous procurer la dernière version du kit de ressources et des outils de support à partir du Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/search.aspx? Microsoft fournit un outil IPSeccmd mis à jour et d'autres outils de support pour Windows XP SP2. Reportezvous à l'article 838079 de la Base de connaissances Microsoft, « Windows XP Service Pack 2 Support Tools » (Outils de support du Service Pack 2 Windows XP), à l'adresse http://support.microsoft.com/?kbid=838079. Les informations détaillées sur l'utilisation de ces outils dépassent le cadre du présent guide. Les exemples donnés dans ce dernier concernent l'utilisation de l'outil Netsh sur des serveurs fonctionnant sous Windows Server 2003.
Application des stratégies IPSec à l'aide d'objets Stratégie de groupe La stratégie de groupe Active Directory sert de mécanisme de distribution et d'attribution des stratégies IPSec aux ordinateurs associés à des domaines. Pour répartir les stratégies via les mécanismes de distribution de la stratégie de groupe dans Active Directory, vous devez avant toute chose configurer les objets Stratégie de groupe qui seront utilisés pour appliquer les stratégies IPSec sur les ordinateurs hôtes. Remarque : bien que la section suivante aborde le chargement des stratégies IPSec directement dans Active Directory, vous devez partir du principe que les stratégies ont été créées et testées sur un système local, dans un laboratoire de test et dans le cadre de projets pilote à petite échelle avant d'être déployées au sein d'un environnement de production. Procédure de chargement des stratégies IPSec dans Active Directory La première tâche à effectuer pour l'implémentation des stratégies IPSec via Active Directory est de créer les listes de filtres, les actions de filtrage et les stratégies IPSec dans le service d'annuaire. Vous pouvez le faire à l'aide du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec ou par le biais d'un outil de ligne de commande tel que Netsh. Quel que soit l'outil que vous choisissez, vous devez effectuer les trois soustâches suivantes pour implémenter les stratégies IPSec :
1. Créer les listes de filtres et les filtres identifiés dans la section « Listes de filtres IPSec » de ce chapitre.
2. Créer les actions de filtrage identifiées dans la section « Actions de filtrage IPSec » de ce chapitre.
3. Créer les stratégies IPSec identifiées dans la section « Stratégies IPSec » de ce chapitre. Utilisation du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec Le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec est un outil d'interface graphique utilisateur à l'aide duquel les administrateurs peuvent créer, configurer et modifier des stratégies IPSec sur des ordinateurs locaux, des ordinateurs distants ou des domaines. La configuration des composants IPSec est un processus manuel qui implique de modifier directement les objets créés, dirigé par des assistants. Après avoir défini les stratégies IPSec localement ou dans Active Directory, l'administrateur peut les exporter (avec toutes les listes de filtres et les actions de filtrage) dans un fichier dont le nom se termine par une extension .ipsec. Vous pouvez copier ce fichier sur un autre support à titre de sauvegarde.
129
Si une sauvegarde des stratégies IPSec est déjà disponible, vous pouvez utiliser l'outil pour importer les stratégies sauvegardées dans Active Directory. Vous pouvez opter pour cette approche à des fins de récupération ou pour déplacer les fichiers de stratégies IPSec d'une forêt de test vers une forêt de production sans avoir à recréer chaque liste de filtres, action de filtrage et stratégie manuellement. Examinez avec soin la conception des stratégies récupérées à partir des copies de sauvegarde. Il est conseillé d'effectuer des tests afin d'évaluer l'impact de l'application des anciens paramètres dans l'environnement actuel. Un ancien fichier de sauvegarde peut contenir des paramètres de stratégie (notamment des listes de filtres ou des actions de filtrage) non valides et susceptibles de faire échouer toute communication s'ils ont été affectés aux membres actuels du domaine. Pour plus d'informations sur l'utilisation du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec, reportezvous à la rubrique « Définition des stratégies IPSec » du Centre d'aide et de support de Windows Server 2003. Utilisation de l'outil Netsh Vous pouvez faire appel à l'outil Netsh au lieu du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec pour configurer des stratégies IPSec dans un domaine Active Directory Windows Server 2003. L'exécution de cet outil de ligne de commande peut avoir lieu en mode interactif ou en mode de traitement par lot. Lorsqu'il fonctionne en mode interactif, Netsh exige que l'administrateur tape chaque commande dans l'invite de commandes Netsh. Avant créer les listes de filtres, les actions de filtrage et les stratégies IPSec, vous devez configurer l'outil pour qu'il pointe sur Active Directory. Pour que Netsh pointe sur Active Directory, tapez la commande suivante à l'invite Netsh : ipsec static set store location=domain L'administrateur peut ensuite entrer les listes de filtres, les filtres, les actions de filtrage et les stratégies IPSec manuellement via l'invite de commandes Netsh. Tout comme l'outil GUI, Netsh prend en charge l'exportation et l'importation des fichiers de stratégies IPSec pour les scénarios de sauvegarde et de récupération. L'exécution de Netsh en mode de traitement par lot nécessite la création d'un fichier script contenant les commandes Netsh. Ce fichier script doit contenir la commande permettant de cibler le domaine ainsi que toutes les commandes de configuration des listes de filtres, des filtres, des actions de filtrage et des stratégies IPSec. Vous pouvez ensuite créer les informations des stratégies IPSec dans Active Directory en démarrant l'outil Netsh, puis en exécutant le fichier script. La syntaxe de la ligne de commande pour le lancement de Netsh et l'exécution d'un fichier script se présente comme suit : netsh –f <scriptfile> Pour plus d'informations sur l'utilisation de Netsh, reportezvous à la rubrique « Netsh » de la section « Outils d'administration et de script » du Centre d'aide et de support de Windows Server 2003. Remarque : Netsh fonctionne uniquement avec des stratégies IPSec sur des ordinateurs exécutant Windows Server 2003. La manipulation depuis la ligne de commande des stratégies IPSec sur des ordinateurs exécutant Windows 2000 ou Windows XP exige respectivement l'outil Ipsecpol.exe ou Ipseccmd.exe. De plus, Netsh consigne une commande dump dans le contexte IPSec de l'outil. Bien qu'elle soit répertoriée dans l'aide, cette fonction n'a pas été implémentée. De plus, contrairement à l'outil GUI, Netsh ne prend pas en charge les connexions à distance.
130
Création d'objets Stratégie de groupe pour la distribution des stratégies IPSec Les objets Stratégie de groupe (GPO) sont stockés dans Active Directory et définissent un ensemble de paramètres à appliquer à un ordinateur. Les stratégies IPSec ne sont pas stockées directement dans les objets Stratégie de groupe. À la place, les objets Stratégie de groupe maintiennent une liaison DN LDAP avec la stratégie IPSec. Les stratégies IPSec sont stockées à l'emplacement cn=IP Security, cn=System, dc=<domain> dans Active Directory. Les objets Stratégie de groupe sont attribués aux sites, aux domaines ou aux unités d'organisation dans Active Directory. Les ordinateurs situés à ces emplacements ou dans ces conteneurs reçoivent la stratégie définie par l'objet Stratégie de groupe, sauf si d'autres paramètres l'empêchent. L'équipe de conception IPSec doit consulter l'équipe Active Directory afin de discuter de la possibilité d'utiliser les objets Stratégie de groupe existants pour fournir leurs stratégies IPSec. Si cette approche s'avère impossible ou exige une modification à grande échelle des méthodes de gestion, vous pouvez définir de nouveaux objets Stratégie de groupe pour chaque ensemble de stratégies IPSec à déployer. La solution décrite dans ce guide fait appel à de nouveaux objets Stratégie de groupe pour le déploiement des stratégies IPSec. Bien que vous puissiez créer les objets Stratégie de groupe via l'outil Utilisateurs et ordinateurs Active Directory ou l'outil Sites et services Active Directory, nous vous conseillons de les créer à l'aide de la console de gestion des stratégies de groupe (GPMC). La création d'une stratégie avec les outils Active Directory permet de lier automatiquement l'objet Stratégie de groupe à l'objet en cours d'exploration. En faisant appel à la console GPMC pour créer les objets Stratégie de groupe, l'administrateur peut s'assurer que les objets Stratégie de groupe sont créés dans Active Directory mais ne sont pas appliqués aux ordinateurs tant que chaque objet Stratégie de groupe n'est pas explicitement lié à un site, un domaine ou une unité d'organisation. La console GPMC est un utilitaire complémentaire destiné aux ordinateurs sous Windows XP Service Pack 1 (ou ultérieur) ou Windows Server 2003. Elle permet aux administrateurs de gérer la stratégie de groupe pour plusieurs domaines et sites dans une ou plusieurs forêts via une interface utilisateur simplifiée prenant en charge la fonctionnalité « glisserdéplacer ». Ses fonctions clés couvrent notamment la sauvegarde, la restauration, l'importation, la copie des objets Stratégie de groupe et la création de rapports les concernant. Ces opérations sont entièrement scriptables, ce qui permet aux administrateurs de personnaliser et d'automatiser la gestion. Notez que ces techniques de gestion des objets Stratégie de groupe s'appliquent à la gestion des objets de stratégie IPSec euxmêmes. Vous devez développer une stratégie de gestion afin de gérer la stratégie IPSec en coordination avec les objets Stratégie de groupe chargés d'attribuer les stratégies IPSec. Pour plus d'informations sur l'utilisation de la console GPMC, reportezvous au livre blanc « Administering Group Policy with the GPMC » (Administration de la stratégie de groupe à l'aide de la console GPMC) disponible sur le site Web de Microsoft à l'adresse www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx. Vous pouvez télécharger la console de gestion des stratégies de groupe avec Service Pack 1 partir de www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C248CBD4B359272 DD3CBFC81887&displaylang=en.
à
Grâce à la console GPMC, l'administrateur peut créer un objet Stratégie de groupe pour chaque stratégie IPSec en procédant comme suit : Pour créer un nouvel objet Stratégie de groupe
1. Développez l'arborescence du domaine, cliquez avec le bouton droit sur le conteneur Objets de stratégie de groupe, puis sélectionnez Nouveau.
131
2. Tapez le nom d'un nouvel objet Stratégie de groupe, puis cliquez sur OK. Tout comme pour les actions de filtrage et les stratégies IPSec, vous devez développer une norme d'attribution de noms pour les objets Stratégie de groupe en incluant le numéro de version de la stratégie car les informations de version des objets Active Directory ne sont pas faciles à obtenir. L'ajout d'un numéro de version dans le nom de la stratégie permet aux administrateurs d'identifier rapidement la stratégie actuellement en vigueur. Microsoft recommande l'utilisation de la même convention d'attribution de noms que celle décrite plus haut dans ce chapitre pour les actions de filtrage et les stratégies IPSec. Par exemple, un objet Stratégie de groupe intitulé « GPO IPSec de domaine d'isolation ver 1.0.040601.1600 » désigne la version 1.0 créée le 06/01/04 à 16 heures. Une fois l'objet Stratégie de groupe créé, l'administrateur doit le configurer pour qu'il utilise la stratégie IPSec appropriée. Pour attribuer une stratégie IPSec à un objet Stratégie de groupe
1. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe, puis sélectionnez Modifier pour lancer l'Éditeur de stratégies de groupe.
2. Les stratégies IPSec qu'il est possible d'attribuer sont disponibles sous Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies de sécurité IP dans Active Directory.
3. Pour attribuer une stratégie IPSec, cliquez avec le bouton droit sur le nom de la stratégie dans le volet droit, puis sélectionnez Attribuer. • Une seule stratégie IPSec peut être attribuée à un objet Stratégie de groupe.
4. Pour enregistrer les modifications de l'objet Stratégie de groupe, fermez l'Éditeur de stratégies de groupe. La stratégie IPSec est appliquée aux ordinateurs hôtes via les paramètres de configuration ordinateur de l'objet Stratégie de groupe. Si vous utilisez l'objet Stratégie de groupe uniquement en vue d'appliquer des stratégies IPSec, nous vous conseillons de le configurer en désactivant les paramètres de configuration utilisateur. En désactivant ces paramètres, vous pourrez passer outre l'évaluation des options de configuration utilisateur et raccourcirez ainsi le temps de traitement de l'objet Stratégie de groupe. Pour désactiver la configuration utilisateur dans l'objet Stratégie de groupe
1. Ouvrez l'outil GPMC. 2. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe dans la console GPMC. 3. Sélectionnez État GPO, puis Paramètres de configuration utilisateurs désactivés. Si les paramètres de configuration utilisateur sont modifiés dans l'objet Stratégie de groupe par la suite, l'administrateur devra réactiver le traitement de ces paramètres afin qu'ils s'appliquent. Groupes de sécurité de domaine Les groupes de sécurité de domaine remplissent deux fonctions. La première est d'identifier les comptes d'ordinateurs de domaine membres d'un groupe d'isolation ; la deuxième est d'identifier les comptes d'ordinateurs de domaine membres d'un groupe d'accès réseau. Tous les membres d'un groupe d'isolation doivent recevoir la même stratégie IPSec. Par conséquent, vous pouvez créer des groupes de sécurité de domaine pour l'application et la gestion des stratégies 132
IPSec au lieu d'utiliser des conteneurs d'unités d'organisation pour contrôler l'attribution des stratégies. Les groupes universels constituent la meilleure option de contrôle de l'attribution des stratégies puisque vous pouvez les appliquer à la forêt tout entière et réduire ainsi le nombre de groupes à gérer. En revanche, si ces groupes universels ne sont pas disponibles, vous pouvez utiliser les groupes globaux de domaine à la place. Les groupes locaux de domaine sont utilisés pour les groupes d'accès réseau abordés plus loin dans ce guide. Le tableau ciaprès répertorie les groupes qui ont été créés pour le scénario de la Woodgrove Bank afin de gérer l'environnement IPSec et contrôler l'application des stratégies. Tableau 5.10 : Noms des groupes IPSec Nom de groupe
Description
No IPSec
Groupe universel de comptes d'ordinateurs ne participant pas à l'environnement IPSec Il s'agit généralement de comptes d'ordinateurs issus de l'infrastructure.
CG_IsolationDomain_computers Groupe universel de comptes d'ordinateurs membres du domaine d'isolation. CG_BoundaryIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation de limite et, par conséquent, autorisés à communiquer avec des systèmes non approuvés.
CG_NoFallbackIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation sans basculement non autorisés à établir des communications non authentifiées sortantes.
CG_EncryptionIG_computers
Groupe universel de comptes d'ordinateurs membres du groupe d'isolation de chiffrement et qui, par conséquent, exigent le chiffrement de leurs communications.
Outre les groupes énumérés, d'autres groupes ont peutêtre été créés et exploités en vue de restreindre l'application des stratégies lors de la phase de déploiement initiale. Au moment de déployer IPSec, il n'est pas recommandé de se contenter de créer les objets Stratégie de groupe et les stratégies IPSec et de les attribuer en même temps à tous les ordinateurs du domaine. Vous pouvez utiliser un groupe de sécurité de domaine pour contrôler avec précision les ordinateurs capables de lire les objets Stratégie de groupe et, donc, de recevoir la stratégie IPSec correspondante. Les objets Stratégie de groupe offrant la stratégie IPSec peuvent tous être attribués à l'ensemble du domaine. Le processus de déploiement doit soigneusement examiner si la stratégie IPSec a été correctement conçue, attribuée et récupérée sur tous les nœuds sensés négocier IPSec. La conception de la stratégie du groupe de limite est généralement employée pour autoriser les communications nonIPSec entrantes et sortantes sur des ordinateurs qui n'ont pas encore reçu leur stratégie IPSec. Distribution des stratégies IPSec via Active Directory Trois méthodes, seules ou combinées, vous permettent de contrôler les objets Stratégie de groupe que vous pouvez appliquer à des ordinateurs dans Active Directory.
• Utilisation d'unités d'organisation avec des objets Stratégie de groupe liés. • Intégration de comptes d'ordinateurs dans des groupes de sécurité référencés dans des listes de contrôle d'accès appliquées aux objets Stratégie de groupe.
133
• Utilisation de filtres WMI (Windows Management Instrumentation) dans les objets Stratégie de groupe.
Le contrôle de l'application des objets Stratégie de groupe par le biais d'unités d'organisation avec objets Stratégie de groupe liés est la méthode d'application de stratégies la plus répandue dans Active Directory. Elle vous permet de créer des unités d'organisation dans Active Directory et de lier des objets Stratégie de groupe à des sites, des domaines ou des unités d'organisation. La stratégie est attribuée aux ordinateurs en fonction de leur emplacement dans Active Directory. Si vous déplacez un ordinateur d'une unité d'organisation vers une autre, la stratégie liée à la deuxième unité d'organisation entre effectivement en vigueur lorsque la stratégie de groupe détecte des modifications lors de l'interrogation. La deuxième méthode utilise les paramètres de sécurité des objets Stratégie de groupe euxmêmes. Un groupe est ajouté à la liste de contrôle d'accès de l'objet Stratégie de groupe dans Active Directory. Des autorisations de lecture et d'application sont attribuées au groupe dans la stratégie à appliquer aux ordinateurs du groupe. De plus, d'autres autorisations spécifiques sont refusées au groupe dans les stratégies non applicables aux ordinateurs de ce groupe. La stratégie est ensuite liée au niveau du domaine. La troisième méthode fait appel aux filtres WMI de la stratégie pour contrôler de manière dynamique l'étendue d'application de la stratégie. Un filtre SQL WMI est créé et lié à la stratégie. Si la condition interrogée est vraie (true), la stratégie est appliquée ; sinon, elle est ignorée. Les ordinateurs dotés de Windows 2000 ignorent le filtrage WMI et appliquent la stratégie. Les requêtes WMI peuvent ralentir le traitement des objets Stratégie de groupe et doivent être utilisées uniquement si elles sont nécessaires. La Woodgrove Bank a opté pour l'utilisation des groupes de sécurité pour contrôler l'application des stratégies plutôt que de les lier directement à une unité d'organisation. Si elle a choisi cette approche, c'est pour faciliter l'intégration des stratégies IPSec dans l'environnement et éviter de les imposer à plusieurs emplacements ou de forcer le déplacement d'ordinateurs d'une unité d'organisation vers une autre pour obtenir la stratégie appropriée. À moins que les listes de contrôle d'accès de l'objet Stratégie de groupe soient extrêmement longues, cette méthode n'ajoute aucune charge par rapport à la première méthode puisque, dans les deux cas, les listes de contrôle d'accès doivent faire l'objet d'une évaluation. La Woodgrove Bank n'a pas opté pour le filtrage WMI en raison des systèmes Windows 2000 qu'abrite l'environnement. Le tableau cidessous indique la configuration finale des listes de contrôle d'accès de la stratégie de groupe. Notez que les listes de contrôle d'accès dans les objets de stratégie IPSec euxmêmes ne sont pas utilisées et sont déconseillées. Tableau 5.11 : Autorisations GPO de la Woodgrove Bank Nom de l’objet Stratégie de groupe
Nom du groupe de sécurité
Autorisations attribuées
IPSEC – Isolation Domain Policy (Stratégie de domaine d'isolation)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Isolation Domain Policy (Stratégie de domaine d'isolation)
CG_IsolationDomain_computers
Autoriser Lecture et Appliquer la stratégie de groupe
IPSEC – Boundary Group Policy (Stratégie de groupe de limite)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Boundary Group Policy
CG_BoundaryIG_computers
Autoriser Lecture et
134
(Stratégie de groupe de limite)
Appliquer la stratégie de groupe
IPSEC – No Fallback Isolation Group Policy (Stratégie de groupe d'isolation sans basculement)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – No Fallback Isolation Group Policy (Stratégie de groupe d'isolation sans basculement)
CG_NoFallbackIG_computers
Autoriser Lecture et Appliquer la stratégie de groupe
IPSEC – Encryption Isolation Group Policy (Stratégie de groupe d'isolation de chiffrement)
No IPSec
Refuser Appliquer la stratégie de groupe
IPSEC – Encryption Isolation Group Policy (Stratégie de groupe d'isolation de chiffrement)
CG_EncryptionIG_computers
Autoriser Lecture et Appliquer la stratégie de groupe
Domaine d'isolation La Woodgrove Bank a choisi de lier la stratégie Domaine d'isolation au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_IsolationDomain_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. La stratégie Domaine d'isolation Domain est la stratégie que tous les ordinateurs de l'organisation utilisent en tant que stratégie de sécurité IPSec par défaut. Par conséquent, le groupe Ordinateurs du domaine se voit accorder un droit d'accès en lecture à la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Lors de la phase de déploiement initiale, le groupe Ordinateurs du domaine a été supprimé de la liste de contrôle d'accès et un autre groupe de sécurité provisoire a été utilisé pour contrôler et déterminer les destinataires de cette stratégie. Cette approche a permis un déploiement par étapes de cette stratégie. Groupe d'isolation de limite La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de limite au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_BoundaryIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Si, pour des besoins commerciaux, un système doit accepter des communications provenant de systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du système au groupe de sécurité CG_BoundaryIG_computers. Groupe d'isolation sans basculement La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation sans basculement au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_NoFallbackIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie.
135
Si, pour des besoins commerciaux, un système ne doit pas être en mesure d'établir des communications avec des systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du système au groupe CG_NoFallbackIG_computers. Groupe d'isolation de chiffrement La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de chiffrement au niveau du domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche quiconque n'étant pas membre du groupe CG_EncryptionIG_computers d'appliquer la stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle d'accès de la stratégie. Si, pour des besoins commerciaux, un système doit communiquer uniquement avec du trafic chiffré, vous pouvez ajouter le compte d'ordinateur du système au groupe CG_EncryptionIG_computers.
Autorisation de l'accès en entrée à un groupe d'isolation Selon les exigences de la Woodgrove Bank, l'accès réseau en entrée aux serveurs du groupe d'isolation de chiffrement peut uniquement être autorisé à un sousensemble d'hôtes approuvés. Pour respecter ces exigences, les groupes d'accès réseau suivants ont été définis (voir le tableau 4.8 du chapitre 4) :
• ANAG_EncryptedResourceAccess_Users • ANAG_EncryptedResourceAccess_Computers • DNAG_EncryptedResourceAccess_Computers Lorsqu'un client démarre IKE sur un serveur de chiffrement, IKE doit se procurer un ticket de service Kerberos dans lequel figure l'identificateur du groupe de sécurité du domaine indiquant si l'ordinateur client est membre du groupe ANAG et/ou peutêtre du groupe DNAG. Si tous les ordinateurs du groupe d'isolation de chiffrement sont membres du même domaine, vous pouvez alors créer ces groupes d'accès réseau en tant que groupes de sécurité locaux du domaine. Si les ordinateurs du groupe d'isolation de chiffrement sont membres de domaines approuvés séparés, vous pouvez alors utiliser un ensemble de groupes globaux de domaine pour les groupes d'accès réseau ou bien créer des groupes locaux dans chaque domaine. Le scénario imaginé pour la Woodgrove Bank fait intervenir un seul et unique domaine ; il fait donc appel à des groupes locaux du domaine pour ces groupes d'accès réseau. L'objet Stratégie de groupe supplémentaire suivant a été créé afin de définir des droits de type Accéder à cet ordinateur à partir du réseau permettant d'implémenter l'autorisation entrante :
• EncryptionIG GPO d'autorisation d'entrée sur le réseau Le groupe CG_EncryptionIG_Computers se voit accorder les droits Lecture et Appliquer pour cet objet Stratégie de groupe. Le droit d'accès en lecture est retiré au groupe Utilisateurs authentifiés ; cet objet Stratégie de groupe est alors uniquement appliqué aux ordinateurs membres du groupe d'isolation de chiffrement. Comme l'illustre le tableau 4.8 du chapitre 4, le compte d'ordinateur IPSSTXP05 du domaine client autorisé est ajouté au groupe d'accès réseau ANAG_EncryptedResourceAccess_Computers. Les comptes IPSSQLDFS01 et IPSSQLDFS02 des serveurs de chiffrement sont également ajoutés.
136
Néanmoins, le même résultat aurait été obtenu plus aisément en faisant appel au groupe CG_EncryptionIG_computers pour gérer une liste plus volumineuse. Les comptes doivent, d'une manière ou d'une autre, bénéficier du droit Accéder à cet ordinateur à partir du réseau, que ce soit du fait de l'appartenance au groupe ANAG, par intégration directe de leur groupe CG_EncryptionIG_computers ou par une liste explicite des comptes d'ordinateurs ajoutée au droit. Dans le cas contraire, les comptes ne seront pas en mesure d'établir des connexions protégées par IPSec entre eux, condition qu'exigent leurs applications. Pour simuler un environnement de domaine à grande échelle, les groupes ANAG sont les seuls groupes qui autorisent l'accès en entrée dans le scénario de la Woodgrove Bank. Du fait que le groupe Utilisateurs authentifiés inclut tous les ordinateurs du domaine, le droit Accéder à cet ordinateur à partir du réseau doit lui être retiré. Les utilisateurs autorisés du domaine doivent désormais bénéficier d'une autorisation explicite qu'il est possible de définir à l'aide du groupe intégré Utilisateurs du domaine. Cependant, la Woodgrove Bank cherchait à tirer parti de la possibilité de définir des restrictions d'accès réseau entrant pour les utilisateurs et les ordinateurs. Elle a donc créé un groupe de sécurité local de domaine intitulé « ANAG_EncryptedResourceAccess_Users » en y intégrant les comptes des utilisateurs d'applications autorisés (par exemple, User7) ainsi que le groupe des administrateurs locaux et les groupes des administrateurs de domaine. Ces restrictions d'accès réseau définies au niveau de l'utilisateur interviennent lors des demandes d'authentification des protocoles de niveau supérieur (notamment RPC, SMB et SQL) après qu'une connectivité IPSec ESP 3DES a été établie avec succès. Les groupes de sécurité de domaine suivants ont été créés en vue de définir des droits de connexion réseau pour les serveurs de chiffrement. Ils résident dans l'objet Stratégie de groupe sous Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies locales, Attribution des droits utilisateur, autorisation Accéder à cet ordinateur à partir du réseau :
• ANAG_EncryptedResourceAccess_Computers • ANAG_EncryptedResourceAccess_Users Le groupe suivant est configuré pour le même objet Stratégie de groupe, Interdire l'accès à cet ordinateur à partir du réseau :
• DNAG_EncryptedResourceAccess_Computers En supposant qu'il ne parvienne pas à ouvrir directement une session sur les serveurs de chiffrement, l'utilisateur User7 doit utiliser l'ordinateur client IPSSTXP05 pour accéder au serveur IPSSQLDFS 01 ou au serveur IPSSQLDFS02. L'ordinateur IPSSTXP05 doit disposer d'un compte d'ordinateur de domaine valide et d'une stratégie IPSec active capable de soumettre une négociation IKE sur les adresses IP des serveurs de chiffrement. Notez que les utilisateurs et les ordinateurs restants du domaine sont exclus de tout accès puisque l'autorisation Accéder à cet ordinateur à partir du réseau leur est intentionnellement retirée. Seuls les ordinateurs du groupe d'isolation de limite se voient explicitement refuser l'accès, par le biais du groupe DNAG. C'est une mesure de défense renforcée contre toutes les modifications d'appartenance à un groupe susceptibles d'être apportées à l'avenir et d'inclure un compte d'ordinateur de limite dans un groupe ANAG. Un paramètre de refus explicite remplace toutes les formes d'autorisation.
Autres considérations relatives à IPSec Outre la définition des stratégies IPSec, d'autres éléments indispensables à une implémentation réussie d'IPSec sont à prendre en compte. La feuille de calcul Business_Requirements.xls (dossier Tools and Templates) fournit des informations détaillées sur les contraintes liées à l'utilisation d'IPSec.
137
Exemptions par défaut Dans Windows 2000 et Windows XP, les types de trafic suivants sont, par défaut, exemptés du filtrage :
• Diffusion • Multidiffusion • Protocole d'authentification Kerberos • IKE (Internet Key Exchange) • RSVP (Resource Reservation Protocol) Dans les systèmes d'exploitation de la famille Windows Server 2003, le trafic de diffusion, multidiffusion, RVSP et d'authentification Kerberos n'est, par défaut, pas exempt du filtrage (seul le trafic IKE l'est). Les paquets de diffusion et de multidiffusion sont ignorés s'ils correspondent à un filtre muni d'une action de filtrage visant à négocier la sécurité. Par défaut, Windows Server 2003 offre une prise en charge limitée pour le filtrage du trafic de diffusion et de multidiffusion. Un filtre doté d'une adresse source de type N'importe quelle adresse IP s'appliquera aux adresses de diffusion et de multidiffusion. Un filtre doté d'une adresse source de type N'importe quelle adresse IP et d'une adresse de destination N'importe quelle adresse IP s'appliquera à des adresses de multidiffusion entrantes et sortantes. Vous pouvez utiliser ce type de filtre pour bloquer l'ensemble du trafic. En revanche, les filtres unidirectionnels à utiliser pour bloquer ou autoriser un trafic de diffusion ou de multidiffusion spécifique ne sont pas pris en charge. La modification du comportement d'exemption par défaut de l'implémentation d'IPSec dans la famille Windows Server 2003 doit vous inciter à vérifier le comportement des stratégies IPSec élaborées pour Windows 2000 ou Windows XP et à déterminer si des filtres explicites doivent être configurés pour autoriser des types de trafic spécifiques. Pour rétablir le comportement par défaut de Windows 2000 et Windows XP pour les stratégies IPSec, vous pouvez utiliser la commande Netsh ou modifier le Registre. Pour rétablir le comportement de filtrage par défaut de Windows 2000 et Windows XP dans le pilote IPSec à l'aide de la commande Netsh
1. Tapez la commande suivante à l'invite Netsh, puis appuyez sur Entrée : netsh ipsec dynamic set config ipsecexempt 0
2. Redémarrez l’ordinateur. Pour exempter tout le trafic de diffusion, multidiffusion et IKE du filtrage IPSec en modifiant le Registre
1. Donnez au paramètre HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\IPSEC\NoDefaultExempt DWORD du Registre la valeur 1. La clé NoDefaultExempt n'existe pas par défaut et doit être créée.
2. Redémarrez l’ordinateur.
NATTraversal (NATT) En raison du mode de fonctionnement des traducteurs d'adresses réseau, les clients peuvent être confrontés à des résultats inattendus avec des serveurs Windows 2000 Server ou
138
Windows Server 2003 placés derrière un traducteur d'adresses réseau utilisant la technologie NATT IPSec. Par défaut, Windows XP SP2 ne prend plus en charge les associations de sécurité NATT IPSec avec ces serveurs. L'objectif de cette modification est d'éviter un risque de sécurité prévisible dans une situation où les événements consécutifs suivants se produisent :
1. Un traducteur d'adresses réseau est configuré afin de faire correspondre le trafic IKE et le trafic NATT IPSec sur un serveur placé sur un réseau configuré NAT (Serveur 1).
2. Un client étranger au réseau NAT (Client 1) utilise NATT avec IPSec pour établir des associations de sécurité bidirectionnelles avec le Serveur 1.
3. Un client appartenant au réseau NAT (Client 2) utilise NATT avec IPSec pour établir des associations de sécurité bidirectionnelles avec le Client 1.
4. Une condition contraint le Client 1 à rétablir les associations de sécurité avec le Client 2 en raison des paramètres du traducteur d'adresses réseau qui fait correspondre le trafic IKE et le trafic IPSec NATT sur le Serveur 1. Cette condition peut provoquer un routage incorrect du trafic de négociation des associations de sécurité IPSec (transmis par le Client 1et destiné au Client 2) vers le Serveur 1. Bien que cette situation soit peu probable, le comportement par défaut sur des ordinateurs Windows XP SP2 empêche toute association de sécurité IPSec NATT avec des serveurs situés derrière un traducteur d'adresses réseau afin de garantir que cette situation ne se produise jamais. Si des communications IPSec sur NAT sont requises, nous vous conseillons d'utiliser des adresses IP publiques pour tous les serveurs qu'il est possible de connecter directement depuis Internet. Si cette configuration n'est pas possible, vous pouvez alors modifier le comportement par défaut de Windows XP SP2 pour activer les associations de sécurité IPSec NATT avec les serveurs situés derrière un traducteur d'adresses réseau. Pour créer et configurer la valeur de Registre AssumeUDPEncapsulationContextOnSendRule
1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK. 2. Recherchez, puis cliquez sur la sousclé suivante du Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD. 4. Dans la zone Nouvelle valeur #1, tapez ce qui suit, puis appuyez sur Entrée : AssumeUDPEncapsulationContextOnSendRule Remarque : le nom de cette valeur tient compte de la casse.
5. Cliquez avec le bouton droit sur AssumeUDPEncapsulationContextOnSendRule, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez l'une des valeurs suivantes : • 0 (par défaut). Une valeur 0 (zéro) configure Windows de sorte qu'il ne puisse pas établir d'associations de sécurité avec des serveurs situés derrière des traducteurs d'adresses réseau. • 1. Une valeur 1 configure Windows de sorte qu'il puisse établir des associations de sécurité avec des serveurs situés derrière des traducteurs d'adresses réseau.
139
• 2. Une valeur 2 configure Windows de sorte qu'il puisse établir des associations de sécurité lorsque le serveur et l'ordinateur client Windows XP SP2 sont situés derrière des traducteurs d'adresses réseau. Remarque : la configuration que représente la valeur 2 existe dans la version d'origine de Windows XP et dans Windows XP Service Pack 1 (SP1).
7. Cliquez sur OK, puis fermez l'Éditeur du Registre. 8. Redémarrez l’ordinateur. Une fois AssumeUDPEncapsulationContextOnSendRule défini à une valeur 1 ou 2, Windows XP SP2 peut se connecter à un serveur situé derrière un traducteur d'adresses réseau. Les serveurs Windows Server 2003 doivent également être mis à jour pour fonctionner comme il se doit avec IPSec lorsqu'ils sont placés derrière un dispositif NAT. Consultez l'URL cidessous pour savoir comment vous procurer Windows Server 2003 Service Pack 1 : http://go.microsoft.com/fwlink/?LinkId=41652 Remarque : pour plus d'informations, reportezvous à l'article 885348 de la Base de connaissances Microsoft, « IPSec NATT is not recommended for Windows Server 2003 computers that are behind network address translators », (IPSec NATT est déconseillé pour les ordinateurs Windows Server 2003 situés derrière des traducteurs d'adresses réseau) disponible à l'adresse http://support.microsoft.com/default.aspx?scid=kb;enus;885348. Cet article présente les risques de sécurité liés à l'utilisation de ce scénario. Chaque client doit comparer les avantages de l'utilisation d'IPSec dans ce scénario avec les risques de sécurité que cela implique. Bien que Microsoft ne recommande pas le scénario en raison des risques de sécurité qui y sont associés, ce scénario est pris en charge avec la configuration décrite dans cette solution. Pour que les connexions NAT entrantes fonctionnent correctement, la découverte PMTU doit être activée et ellemême fonctionner. Certaines sources, notamment le Windows XP Hardening Guide et le Windows Server 2003 Hardening Guide (Guides de renforcement de la sécurité de Windows XP et de Windows Server 2003) recommandent de désactiver la découverte PMTU et fournissent, dans certains cas, des modèles de stratégies permettant de désactiver cette fonctionnalité. Pour activer la découverte du PMTU (Path MTU)
1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK. 2. Recherchez, puis cliquez sur la sousclé suivante du Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\tcpip\parameters
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD. 4. Dans la zone Nouvelle valeur #1, tapez EnablePMTUDiscovery, puis appuyez sur Entrée. 5. Cliquez avec le bouton droit sur EnablePMTUDiscovery, puis cliquez sur Modifier. 6. Dans la zone Données de la valeur, tapez 1. 7. Cliquez sur OK, puis fermez l'Éditeur du Registre. 8. Redémarrez l’ordinateur. De plus, les hôtes équipés de Windows 2000 et intervenant dans un scénario NATT nécessitent l'installation du correctif fourni avec l'article 818043 de la Base de connaissances Microsoft, « L2TP/IPSec NATT update for Windows XP and Windows 2000 » (Mise à jour NATT L2TP/IPSec pour Windows XP et Windows 2000) pour fonctionner correctement.
140
Pour plus d'informations, reportezvous aux articles suivants de la Base de connaissances :
• 885407, « The default behavior of IPSec NAT traversal (NATT) is changed in Windows XP Service Pack 2 » (Le comportement par défaut d'IPSec NATT (NATTraversal) est modifié dans Service Pack 2 Windows XP), sur le site Web du support Microsoft à l'adresse http://support.microsoft.com/kb/885407.
• 818043, « L2TP/IPSec NATT update for Windows XP and Windows 2000
» (Mise à jour NAT T L2TP/IPSec pour Windows XP et Windows 2000), sur le site Web du support Microsoft à l'adresse http://support.microsoft.com/kb/818043.
IPSec et Parefeu Windows Le Parefeu Windows sur des ordinateurs Windows XP SP2 offre une protection supplémentaire contre les attaques en bloquant le trafic entrant non sollicité. Sous Windows XP SP2, IPSec utilise le parefeu Windows. Lorsqu'une stratégie IPSec est active, les composants IPSec de Windows XP SP2 sollicitent le Parefeu Windows afin qu'il ouvre les ports UDP 500 et 4500 pour autoriser le trafic IKE. Une autre fonctionnalité prise en charge avec IPSec est la possibilité de préciser via la stratégie de groupe que tout le trafic protégé par IPSec ignore le traitement du Parefeu Windows. Pour plus d'informations, reportezvous à l'annexe A du livre blanc, « Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 » (Déploiement des paramètres du Parefeu Windows pour Microsoft Windows XP Service Pack 2) disponible à l'adresse http://download.microsoft.com/download/ 6/8/a/68a81446cd734a6186658a67781ac4e8/wf_xpsp2.doc.
IPSec et Parefeu de connexion Internet (ICF) Pour les ordinateurs Windows XP non équipés du SP2, le Parefeu de connexion Internet (ICF) répondra mieux aux exigences de sécurité qu'impose le filtrage du trafic. Le Parefeu de connexion Internet offre en effet une fonction de filtrage et permet de bloquer le trafic de diffusion et de multidiffusion entrant dans Windows XP SP1. En revanche, il ne reconnaît pas le trafic protégé par IPSec au format AH ou ESP en mode transport ou en mode tunnel. Du fait qu'IPSec opère dans la couche réseau sous le Parefeu de connexion Internet et qu'IKE intervient audessus du Parefeu de connexion Internet, vous devez définir une autorisation statique (port UDP 500) pour le trafic entrant. Si IPSec bloque le trafic, le journal des paquets ignorés par le Parefeu de connexion Internet ne contiendra pas les paquets ignorés par IPSec.
Résumé Ce chapitre contient les informations requises pour créer et déployer des stratégies IPSec à partir de la conception des groupes d'isolation créée au chapitre 4. Ces informations ont été divisées en sept tâches élémentaires :
• Identification et création de listes de filtres • Identification et création d'actions de filtrage • Identification et création de règles • Identification et création de stratégies IPSec • Définition d'un mécanisme de distribution des stratégies IPSec • Définition d'une méthode de déploiement des stratégies IPSec
141
• Définition d'autorisations pour le contrôle de l'accès entrant par configuration des droits de connexion réseau de la stratégie de groupe
Ces tâches complètent les phases de conception et de planification de la solution d'isolation de serveurs et de domaines. La prochaine phase du projet consiste à déployer un environnement test ou pilote afin de valider la conception. Microsoft a procédé à cette vérification dans ses laboratoires de test et utilisé le scénario de la Woodgrove Bank en tant que pilote. Si vous souhaitez recréer cet environnement ou étudier les phases de déploiement, l'annexe C du présent guide contient des instructions détaillées relatives au processus de déploiement adopté dans les laboratoires de Microsoft pour valider la conception du scénario.
Informations complémentaires Cette section propose des liens vers d'autres informations relatives aux technologies mentionnées dans ce chapitre. Informations générales sur IPSec
• La page d'accueil IPSec sur le site Web de Microsoft : www.microsoft.com/ipsec • La page Page IPSec for Windows 2000
(IPSec pour Windows 2000) sur le site Web de Microsoft fournit une grande variété d'informations relatives à IPSec sous Windows 2000 : www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp.
• La page IPSec
de la section Windows Server 2003 du site Web de Microsoft fournit une grande variété d'informations relatives à IPSec sous Windows Server 2003 : www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx.
• Le chapitre Deploying IPSec
(Déploiement d'IPSec) du Windows Server 2003 Deployment Kit (Kit de déploiement de Windows Server 2003) : www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/enus/DNSBJ_IPS_OVERVIEW.asp.
Informations complémentaires
• La page Windows Server 2003 Group Policy
(Stratégie de groupe dans Windows Server 2003) sur le site Web de Microsoft offre une grande variété d'informations sur la gestion des systèmes Windows à l'aide de la stratégie de groupe dans Active Directory : www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx.
• L'article paru en octobre 2004 dans The Cable Guy, « Problems with Using Network Address
Translators » (Problèmes liés à l'utilisation de traducteurs d'adresses réseau), apporte des informations supplémentaires sur les problèmes spécifiques liés à NAT et IPSec. Cet article est disponible sur le site Web de Microsoft à l'adresse suivante : www.microsoft.com/technet/community/columns/cableguy/cg1004.mspx.
142
Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de domaines Dernière mise à jour le 16022005 Ce chapitre fournit des conseils destinés à faciliter la gestion d'une solution d'isolation de serveurs et de domaines déployée efficacement dans un environnement de production. Il est important que l'équipe du support technique comprenne que la solution d'isolation apporte une couche de sécurité supplémentaire, et qu'il faut plus qu'une simple connexion réseau et une adresse IP pour qu'un hôte réussisse à se connecter à une ressource. De même, les personnes chargées des stratégies IPSec et de la stratégie de groupe doivent avoir conscience qu'une seule option mal définie peut nuire aux performances des hôtes auxquels s'appliquent ces stratégies. C'est pourquoi il convient de mettre en place un ensemble de procédures et de processus de gestion correctement documentés et communiqués, qui seront utilisés par les équipes du support après la mise en service de la solution. Les informations fournies dans ce chapitre sont destinées à faciliter l'élaboration de ces processus de gestion de la solution. Il est conseillé de personnaliser autant que possible ces informations afin de refléter les besoins de votre propre environnement. La réussite de la gestion d'une solution d'isolation de serveurs et de domaines repose sur vos capacités à anticiper.
Connaissances préalables requises pour ce chapitre Avant d'utiliser les informations fournies dans ce chapitre, vous devez être familiarisé avec les concepts utilisés dans Microsoft® Operations Framework (MOF) et les concepts IPSec. Vous devez également posséder des connaissances sur les éléments suivants de Windows® 2000 Server (ou version ultérieure) :
• opérations et maintenance de base sur Microsoft Windows Server™ 2003, y compris l'utilisation d'outils tels que l'Observateur d'événements, la Gestion de l'ordinateur et NTBackup ;
• service d'annuaire Active Directory®, y compris la structure et les outils Active Directory, la
manipulation des utilisateurs, des groupes et autres objets Active Directory, et utilisation de la stratégie de groupe ;
• concepts de sécurité du système Windows (utilisateurs, groupes, audit, listes de contrôle d'accès), utilisation des modèles de sécurité, application des modèles de sécurité à l'aide d'une stratégie de groupe ou d'un outil de ligne de commande ;
• concepts clés de la mise en réseau, notamment ceux relatifs à IPSec et au protocole TCP/IP ; • environnement Windows Scripting Host et langage Microsoft Visual Basic® Scripting Edition
(VBScript) afin d'exploiter au mieux les scripts fournis (toutefois, ces connaissances ne sont pas essentielles).
Avant de poursuivre la lecture de ce chapitre, vous devez lire le reste de ce guide et bien comprendre l'architecture et la conception de la solution.
143
Gestion des modifications L'un des objectifs clés du processus de gestion des modifications est de garantir que toutes les parties concernées par une modification imminente ont conscience de l'impact de cette dernière et le comprennent. Dans la mesure où la plupart des systèmes sont étroitement liés, toute modification apportée à un composant d'un système est susceptible d'avoir un impact important sur un autre. Pour réduire ou éliminer les effets négatifs potentiels, la fonction de gestion des modifications tente d'identifier tous les systèmes et processus affectés avant le déploiement de la modification. En règle générale, l'environnement cible (ou géré) est l'environnement de production, mais il convient également d'inclure les environnements clés d'intégration, de test et intermédiaires. Toutes les modifications apportées à un environnement IPSec doivent suivre le processus de gestion des modifications MOF standard suivant :
1. Demande de modification. Initiation formelle d'une modification par la soumission d'une requête de modification (RFC).
2. Classification de la modification. Affectation d'une priorité et d'une catégorie à la modification, en utilisant comme critères son urgence et son impact sur l'infrastructure ou les utilisateurs. Cette classification conditionne la vitesse et la voie de mise en œuvre de la modification.
3. Autorisation de la modification. Prise en considération de la modification, ainsi que son approbation ou sa désapprobation par le responsable des modifications et le comité d'approbation des modifications (CAB), qui comprend des représentants commerciaux et informatiques.
4. Développement de la modification. Planification et développement de la modification, processus dont la portée peut varier énormément et qui inclut des révisions à des étapes clés intermédiaires.
5. Diffusion de la modification. Diffusion et déploiement de la modification dans l'environnement de production.
6. Révision de la modification. Processus postimplémentation qui analyse si la modification a répondu aux objectifs fixés et qui détermine s'il convient de conserver la modification ou de l'annuler. La section suivante décrit les procédures de développement de modification adaptées à certaines modifications clés que vous serez probablement amené à effectuer régulièrement dans votre environnement IPSec. Chaque procédure de développement de modification est accompagnée d'une procédure de diffusion, expliquant comment la modification doit être déployée en production.
Modification de la stratégie IPSec Il est important de comprendre dans quelle mesure les modifications apportées à la stratégie IPSec affecteront les communications. Comme pour le déploiement initial, la première préoccupation concerne la chronologie des modifications, car cette dernière a des conséquences sur la capacité à implémenter une modification et sur le délai d'annulation de la modification. Délais d'application de la stratégie Lorsque l'attribution d'une stratégie IPSec dans un objet Stratégie de groupe est remplacée par une nouvelle stratégie IPSec, certains délais peuvent se produire. Il s'agit notamment du délai de réplication Active Directory de l'attribut Stratégie de groupe contenant l'attribution dans le domaine, et du délai d'interrogation des clients de la Stratégie de groupe membres du domaine requis pour 144
détecter la modification au niveau de l'objet Stratégie de groupe. Ces délais peuvent durer moins d'une minute pour un petit site, et plusieurs heures pour l'ensemble d'une entreprise. Microsoft vous recommande de tester et de documenter ces délais (minimum, maximum et moyen) pour votre propre environnement afin que, lorsqu'une modification est introduite, le temps requis pour le premier impact et la durée totale du déploiement puissent être prévus. Lorsque le contenu d'une stratégie IPSec déjà attribuée est modifié, les mêmes délais se produisent. Il faut s'attendre notamment à un délai de réplication Active Directory des objets de la stratégie IPSec, ainsi qu'à un délai d'interrogation du service de stratégie IPSec sur les ordinateurs membres. Il est possible de créer une condition dans laquelle la réplication de l'attribution de la stratégie dans l'objet Stratégie de groupe se produit avant la réplication de la stratégie IPSec ; cela induirait chez les clients un comportement identique à celui engendré par l'attribution d'une stratégie IPSec basée sur un domaine (sans possibilité de récupérer cette stratégie). Dans ce cas, les hôtes Windows 2000 et Windows XP ne parviendraient tout simplement pas à appliquer la stratégie basée sur un domaine. De même, ils n'appliqueraient aucune stratégie locale éventuellement attribuée. Pour prendre en charge les délais de réplication Active Directory de manière appropriée, veillez d'abord à créer tous les objets (objet Stratégie de groupe, stratégie IPSec, etc.), puis procédez à l'attribution de la stratégie IPSec dans l'objet Stratégie de groupe. Modifications affectant la connectivité IPSec Plusieurs éléments peuvent affecter la connectivité au sein des stratégies et des groupes qui constituent une solution IPSec. Cette section fournit des informations sur la manière dont des modifications courantes peuvent affecter la connectivité IPSec dans le cadre de la modification d'une stratégie de serveur avec des clients ne possédant pas toujours la dernière mise à jour. Si une modification provoque un échec du mode IKE (Internet Key Exchange) principal ou rapide, le trafic est interrompu dès le début de l'inactivité des associations de sécurité IPSec ou à la fin de leur durée de vie en octets ou en secondes. Cette présentation traite de l'impact qu'ont la plupart des modifications sur les fonctionnalités client serveur IPSec. Elle n'est pas uniquement basée sur les modèles de stratégie IPSec de Woodgrove Bank. Ici, les clients peuvent avoir une stratégie proche de celle du modèle de Woodgrove Bank (impliquant des filtres côté clients pour initier IKE sur le serveur), ou ils peuvent utiliser uniquement la règle de réponse par défaut (non utilisée dans le modèle de Woodgrove Bank). Modifications en mode principal La modification d'une méthode d'authentification ou d'une méthode de sécurité de mode principal entraîne la suppression des modes principaux existants par l'IKE, sans affecter les associations de sécurité IPSec de mode rapide établies. Les nouvelles associations de sécurité de mode principal sont générées lorsque la régénération de clé de mode rapide suivante se produit. En règle générale, la modification de la stratégie de serveur n'affecte pas la capacité des clients existants à générer une nouvelle clé de mode principal. Néanmoins, certaines modifications côté serveur peuvent provoquer l'échec de la négociation en mode principal IKE avec les clients, notamment :
• Mise en place d'une nouvelle méthode d'authentification (certificats uniquement) sans inclure les anciennes méthodes d'authentification que le client peut utiliser.
• Passage à 3DES/SHA1/DH1 ou DH2 comme méthode de sécurité de mode principal alors que les clients ont été configurés uniquement pour utiliser DES/SHA1/DH1.
145
• Activation de la confidentialité de transmission parfaite (PFS) de mode principal sans mettre à jour la stratégie du client et du serveur afin que les deux utilisent la PFS de mode principal.
• Activation de la confidentialité de transmission parfaite (PFS) de mode rapide sans mettre à jour la stratégie du client et du serveur afin que les deux utilisent la PFS de mode rapide.
Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer une nouvelle clé pour les associations de sécurité de mode principal :
• Intervalle d'interrogation pour les modifications de stratégie (car il ne s'agit pas d'un paramètre IKE de mode principal)
• Clés de session utilisant la même clé principale (par exemple, nombre de modes rapides IKE par mode principal)
• Ajout d'une nouvelle méthode de sécurité non connue des clients • Modification des paramètres avancés d'échange de clés de la stratégie IPSec pour les paramètres de durée de vie Authentifier et générer une nouvelle clé pour l'association de sécurité de mode principal IKE
Modifications en mode rapide Toute modification d'une action de filtrage étant utilisée pour une association de sécurité IPSec provoque la suppression des associations de sécurité IPSec existantes établies avec ces paramètres de stratégie. Ainsi, en présence de trafic, le système tente d'établir un nouveau mode rapide. Une partie du trafic peut être perdue au cours de ce processus de modification, mais les connexions TCP doivent être rétablies. Cependant, pour les transferts de données à haute vitesse, la suppression immédiate des associations de sécurité IPSec provoque le rejet du trafic sortant jusqu'à l'établissement du nouveau mode rapide. Par exemple, une salve de paquets d'un flux de données vidéo, suite à laquelle TCP n'a pu être rétabli, provoquera une réinitialisation de la connexion pour l'application vidéo. Les modifications de stratégie de serveur affectant la capacité des clients IPSec actifs à générer une nouvelle clé de mode rapide sont les suivantes :
• Passage d'un filtre plus général à un filtre plus spécifique. Par exemple, lorsqu'un serveur démarre avec un filtre de type tout le trafic, puis le supprime, en laissant un filtre TCP uniquement. Pour éviter les problèmes, laissez le filtre plus générique en place lorsque vous ajoutez le filtre plus spécifique. Par exemple, si les clients ont une stratégie de réponse par défaut et qu'un serveur a une stratégie passant de « tout le trafic » à « TCP uniquement », le filtre plus spécifique sera soumis au trafic sortant sur le serveur, qui établira une nouvelle association de sécurité IPSec pour TCP uniquement lorsque les clients auront une réponse par défaut. Le filtre « tout le trafic » appliqué à tous les clients finira par être supprimé (après deux heures) et pourra ensuite être retiré en toute sécurité de la stratégie du serveur. Si le serveur ajoute un filtre plus spécifique avec une action d'autorisation, ce trafic sera immédiatement autorisé et pourra être rejeté par le client ayant un filtre plus général de réponse par défaut IPSec. Exemple : un filtre d'exemption ICMP (Internet Control Message Protocol) est ajouté à un serveur, mais les clients sont déjà sécurisés pour tout le trafic vers le serveur. Dans ce cas, le client va sécuriser son trafic ICMP sortant, recevoir une réponse ICMP en texte clair en retour et rejeter le paquet, car le filtre de réponse par défaut IPSec indique que tout le trafic doit être sécurisé. Cet exemple n'affecterait pas le trafic autre que le trafic ICMP entre le serveur et le client, et il représente un comportement attendu qui provoque toujours une perte de trafic ICMP après la demande de sécurisation de l'ensemble du trafic avec le client par le serveur. Cela peut, ou non, affecter considérablement les performances du service.
146
• Modifications de méthodes de sécurité ou de types d'encapsulation incompatibles. Par
exemple, passage du mode de transport 3DES/SHA1 pour ESP uniquement au mode de transport 3DES/MD5 pour ESP uniquement. Vous pouvez éviter les échecs de négociation en mode rapide IKE provoqués par ce type de modification en incluant les anciennes méthodes de sécurité ou les anciens types d'encapsulation en tant que dernier choix dans la nouvelle méthode de sécurité. Une fois que toutes les associations de sécurité IPSec utilisent la nouvelle méthode d'encapsulation, vous pouvez supprimer l'ancienne méthode au bas de la liste des méthodes de sécurité.
• Désactivation totale d'une règle dont les clients avaient besoin pour établir le mode
principal ou le mode rapide IKE. En mode rapide, le filtre est supprimé afin qu'un filtre différent (ou aucun) contrôle la négociation en mode principal ou en mode rapide IKE.
• Modification totale d'une action de filtrage du type Négocier la sécurité au type Autoriser ou Bloquer. Le trafic étant explicitement autorisé ou bloqué ne nécessite pas la régénération de clé dans la mesure où ce trafic ne transitera plus sur une voie de communication protégée par IPSec.
• Désactivation de la case à cocher Communiquer en texte clair. Cette action conserve la
connectivité des clients connectés pour toute la durée de l'association de sécurité logicielle. Une fois l'association de sécurité arrivée à expiration ou inactive, une augmentation du trafic sortant du serveur conduit l'IKE à tenter une nouvelle négociation en mode principal et à reconnaître les nouveaux paramètres afin d'éviter toute redirection. Les clients qui ne peuvent pas répondre positivement à la négociation IKE ne parviendront pas à se connecter. Cela peut être le but recherché.
• Désactivation de la case à cocher Autoriser une connexion non sécurisée. Cette action
provoque la déconnexion des clients s'ils ne disposent pas de filtres IPSec pour déclencher une initiation en mode principal IKE sortant. Les clients disposant d'une règle de réponse par défaut restent connectés jusqu'à ce que leur filtre dynamique de réponse par défaut devienne inactif après deux heures d'absence de trafic vers le serveur, après quoi ils ne sont plus à même de se reconnecter.
Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer une nouvelle clé de mode rapide :
• L'ajout d'un filtre ne correspondant pas au trafic se trouvant déjà dans les associations de sécurité IPSec actuelles n'affecte pas ce trafic. Par exemple, si des filtres de type autorisation sont ajoutés à la stratégie d'un serveur pour l'adresse IP d'un nouveau contrôleur de domaine.
• Modification de la durée de vie de l'association de sécurité IPSec de l'action de filtrage, en octets ou en temps.
• Modification de l'action de filtrage du type Autoriser à Négocier la sécurité. Si les clients peuvent répondre, ils seront toujours en mesure de négocier une connexion sécurisée pour ce trafic.
Procédures de modification de stratégie IPSec Les sections suivantes décrivent les procédures permettant de modifier les stratégies IPSec délivrées à l'aide des objets Stratégie de groupe. Bien que les étapes présentées pour chaque tâche utilisent le composant logiciel enfichable de la console MMC (Microsoft Management Console) Stratégie de sécurité IP, chacune de ces tâches peut également être accomplie à l'aide de l'outil de ligne de commande Netsh sur un système Windows Server 2003. Microsoft recommande la plateforme Windows Server 2003 comme station de gestion des stratégies car elle offre les meilleures fonctionnalités pour les scripts et la surveillance. L'importation et l'exportation des stratégies IPSec Windows sont destinées à la sauvegarde et à la restauration. La fonction d'exportation copie tous les objets de stratégie IPSec à l'emplacement de 147
stockage pour garantir que tous les objets associés sont capturés dans la sauvegarde. L'exportation est la méthode recommandée pour déplacer l'ensemble de la stratégie de domaine actuelle sur un support de stockage local à des fins de test. En raison du risque d'erreur, veillez à bien supprimer tous les objets inutiles (y compris les stratégies, les listes de filtres et les actions de filtrage) contenus sur le support de stockage local avant d'utiliser la fonction d'exportation. Microsoft déconseille l'utilisation d'un magasin local exporté pour l'importation dans le domaine car des anciennes versions d'objet peuvent écraser des versions de domaine plus récentes et rompre ainsi les liens entre les objets. Les scripts de lignes de commande sont la méthode recommandée pour créer une stratégie IPSec et pour réaliser des ajouts importants aux objets existants, comme l'ajout de filtres à une liste de filtres existants, par exemple. En règle générale, ces modifications importantes dans une stratégie IPSec doivent être effectuées via la création d'une nouvelle version de stratégie IPSec. Une fois la stratégie créée, vous pouvez utiliser des scripts ou le composant logiciel enfichable MMC Gestion des stratégies IPSec pour apporter des modifications. Après la création et la mise en service de la stratégie IPSec, le composant logiciel enfichable MMC Gestion des stratégies IPSec est recommandé pour effectuer des modifications mineures. Dans la mesure où l'outil de ligne de commande Ipsecpol.exe de Windows 2000 prend uniquement en charge la création d'une stratégie, le composant logiciel enfichable MMC peut être utilisé pour gérer les modifications dans Windows 2000 Active Directory. L'ajout d'un nouvel objet du même nom n'est pas autorisé dans les commandes d'ajout de Netsh. Pour cette raison, et parce que les scripts sont souvent exécutés de trop nombreuses fois, les scripts Netsh doivent inclure les étapes initiales permettant de supprimer les objets de stratégie existant déjà avant que de nouveaux objets soient ajoutés. La suppression d'un objet qui n'existe pas a pour effet de renvoyer un message d'erreur inattendue, qui n'interrompt pas l'exécution du script. La suppression d'une stratégie de domaine IPSec déjà attribuée à un objet Stratégie de groupe rendra le lien de l'objet en question non valide. L'objet Stratégie de groupe doit être édité pour réattribuer la dernière version de la stratégie IPSec. Remarque : bien que la section suivante explique comment modifier des stratégies IPSec directement dans Active Directory, nous partons du principe que toutes les modifications ont été testées sur un système local ou un environnement de test avant d'être déployées dans un environnement de production. Modification de l'attribution de la stratégie IPSec pour un groupe d'isolation Pour modifier la stratégie IPSec attribuée à un groupe d'isolation, vous pouvez remplacer la stratégie IPSec actuelle par une nouvelle. La console GPMC (Group Policy Management Console) permet de modifier la stratégie IPSec qu'un objet Stratégie de groupe particulier distribue. Après avoir identifié la nouvelle stratégie IPSec et l'objet Stratégie de groupe qui distribue la stratégie actuelle, procédez comme suit. Pour modifier la stratégie IPSec attribuée à un groupe d'isolation
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Nom d'objet de stratégie de groupe, puis cliquez sur Modifier. 148
5. Développez Configuration ordinateur, développez Paramètres Windows, développez
Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory (nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
7. Vérifiez que la stratégie
Modification d'une stratégie IPSec existante dans le domaine Compte tenu que les fonctionnalités IPSec ont été étendues dans Windows XP, puis à nouveau dans Windows Server 2003, le format de stockage des stratégies IPSec a été modifié pour inclure les paramètres correspondants à ces améliorations. Veillez à ne pas utiliser un composant logiciel enfichable MMC Gestion des stratégies IPSec d'une version antérieure pour afficher ou modifier une stratégie intégrant ces fonctionnalités ajoutées. Si vous cliquez sur OK lors de l'affichage d'un composant de stratégie, les paramètres existants sont écrasés par les paramètres enregistrés dans la mémoire actuelle, même si vous n'avez effectué aucune modification. Des mises à jour ont été ajoutées aux Service Packs de Windows XP et à Windows 2000 Service Pack 4 (SP4) pour détecter les nouvelles versions de stratégie afin d'éviter ce problème potentiel. Néanmoins, le composant logiciel enfichable MMC ne parvient pas à enregistrer les modifications, comme si l'accès en modification était refusé ; il utilise les messages d'erreur qui existaient à la sortie du produit. De même, si l'utilisateur exécutant le composant logiciel enfichable MMC ne dispose que de droits de lecture sur les objets de stratégie IPSec, les modifications sont perdues lorsqu'une erreur d'accès refusé apparaît. Utilisez le mode lecture seule du composant logiciel enfichable MMC Gestion des stratégies IPSec dans Windows Server 2003 chaque fois que vous ne souhaitez pas effectuer de modification. Enfin, le composant logiciel enfichable MMC ne permet pas d'entrer un ID d'utilisateur et un mot de passe différents lors de la connexion à un ordinateur ou domaine distant. L'utilisateur doit être connecté sur le Bureau en tant qu'utilisateur disposant d'autorisations appropriées pour effectuer les modifications souhaitées. Modification de la liste de filtres d'une règle existante Il est parfois nécessaire de modifier la liste de filtres d'une règle existante pour ajouter, supprimer ou modifier un élément de filtre. Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour effectuer cette modification. N'oubliez pas que l'ordre d'un filtre dans une liste de filtres n'a aucune incidence sur l'ordre dans lequel le pilote IPSec traitera les paquets. Les filtres de toutes les listes de filtres dans toutes les règles d'une stratégie IPSec sont ordonnés à l'aide d'un algorithme interne de pondération. Pour effectuer une modification, vous devez vérifier manuellement que vous n'êtes pas en train de créer un filtre dupliqué pour un autre filtre utilisé dans la stratégie IPSec. Dans le cadre du processus de test de la modification, la stratégie doit être attribuée localement sur un ordinateur afin que la sortie du composant logiciel enfichable MMC Moniteur IPSec ou de la ligne de commande puisse être utilisée pour afficher l'ordre exact des filtres et détecter les filtres dupliqués. Pour ajouter un ordinateur à une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
149
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter. 7. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP. 8. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique. 9. Dans la zone de texte Adresse IP, tapez l'adresse IP spécifique. 10. Vérifiez que la case à cocher Miroir est activée. 11. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre. 12. Cliquez sur OK, puis de nouveau sur OK. 13. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Remarque : une fois le nouveau système ajouté à une liste de filtres d'exemptions, le compte d'ordinateur doit être ajouté au groupe de sécurité Sans IPSec. Pour modifier une entrée d'ordinateur dans une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 6. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>, puis cliquez sur Modifier.
7. Dans la zone de texte Adresse IP, remplacez l'entrée par la nouvelle adresse IP. 8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Pour supprimer une entrée dans une liste de filtres
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>. 6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Supprimer. 150
7. Cliquez sur Oui pour supprimer l'élément de filtre. 8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Remarque : une fois le système supprimé de la liste de filtres d'exemptions, le compte d'ordinateur doit être retiré du groupe de sécurité Sans IPSec. Modification de l'action de filtrage d'une règle existante Chaque règle d'une stratégie IPSec dispose d'une action de filtrage correspondante qui est exécutée lorsque les conditions de la règle sont satisfaites. Bien qu'il soit possible d'attribuer une nouvelle stratégie IPSec aux ordinateurs qui présentent la nouvelle combinaison de règle et d'action de filtrage, il est plus judicieux de modifier l'action de filtrage associée à une règle de stratégie IPSec qui existe déjà. Par exemple, si une stratégie IPSec personnalisée existe pour un ensemble d'ordinateurs, il est plus logique de modifier l'action de filtrage attribuée à la règle plutôt que de générer une nouvelle stratégie IPSec. Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour configurer une règle dans une stratégie IPSec pour utiliser une nouvelle action de filtrage. Pour modifier l'action de filtrage d'une règle existante
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier. 5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur <nouvelle action de filtrage> pour sélectionner le bouton adjacent.
6. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 7. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Modification de la méthode d'authentification d'une règle existante La méthode d'authentification par défaut des stratégies IPSec utilise le protocole Kerberos, version 5. Avec le temps, il peut s'avérer nécessaire de modifier une méthode d'authentification associée à une règle existante. Par exemple, une infrastructure de clés publiques (PKI) peut être déployée pour permettre l'utilisation de certificats pour authentifier les ordinateurs. Bien que des informations différentes soient requises pour chaque méthode d'authentification pouvant être choisie, les étapes générales pour l'ajout d'une méthode d'authentification sont semblables. Par exemple, pour utiliser une clé prépartagée, vous devez identifier la clé, et, pour utiliser les certificats, l'autorité de certification doit être connue. Pour ajouter une nouvelle option d'authentification à une règle IPSec existante, procédez comme suit. Pour ajouter une option à une règle existante
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine.
151
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier. 5. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter. 6. Cliquez sur le bouton correspondant à la nouvelle option d'authentification souhaitée, puis configurez les options requises.
7. Cliquez sur OK. 8. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons Monter et Descendre pour créer l'ordre de préférence des méthodes d'authentification. Remarque : pour supprimer une méthode d'authentification, cliquez dessus dans la liste Ordre de préférence des méthodes d'authentification, puis cliquez sur Supprimer.
9. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 10. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP. Ajout d'une nouvelle règle à une stratégie IPSec existante L'ajout de nouvelles règles à des stratégies IPSec existantes permet de restreindre ou d'élargir davantage les communications entre les ordinateurs de l'environnement. Par exemple, si un système prenant en charge IPSec doit communiquer avec des systèmes placés dans un groupe d'isolation particulier mais ne reçoit pas sa stratégie de l'infrastructure IPSec, vous pouvez effectuer des modifications sur le groupe d'isolation afin d'autoriser les communications. Dans cet exemple, il faut appliquer à l'hôte IPSec non géré une stratégie autorisant les communications. En outre, il faut choisir une méthode d'authentification partagée (soit des certificats, soit une clé prépartagée). Une nouvelle règle peut alors être créée dans la stratégie IPSec existante afin de permettre au groupe d'isolation d'autoriser le trafic une fois que la méthode d'authentification a été acceptée. Les étapes nécessaires sont les suivantes : créer une nouvelle liste de filtres dans le répertoire, associer la nouvelle liste de filtres à la stratégie existante, puis configurer les mécanismes d'authentification afin qu'ils incluent la nouvelle méthode d'authentification choisie. Pour créer une nouvelle liste de filtres afin de permettre tout le trafic vers un ordinateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, cliquez sur Ajouter. 5. Dans la zone de texte Nom, tapez un nom de liste de filtres approprié. 6. Dans la zone de texte Description, tapez une description appropriée pour la liste de filtres.
152
7. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 8. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter. 9. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP. 10. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique. 11. Dans la zone de texte Adresse IP, tapez l'adresse IP de l'ordinateur spécifique. 12. Vérifiez que la case à cocher Miroir est activée. Remarque : par défaut, cette procédure crée une règle examinant tout le trafic provenant d'une adresse IP quelconque sur une adresse IP spécifique. Si la correspondance doit être effectuée sur un port ou une base de protocole spécifique, des opérations de configuration supplémentaires doivent être effectuées sous l'onglet Protocole.
13. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre. 14. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. Pour modifier une stratégie IPSec afin d'utiliser une nouvelle liste de filtres et une action de filtrage
1. Cliquez avec le bouton droit de la souris sur
2. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée. 3. Cliquez sur Ajouter. 4. Sous l'onglet Liste de filtres IP, dans la liste Filtres IP, cliquez sur la case d'option Nouvelle liste de filtres IP.
5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur la case d'option Action de filtrage.
6. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter. 7. Cliquez sur le bouton correspondant à la méthode d'authentification souhaitée, puis configurez les options requises. Remarque : la méthode d'authentification choisie doit être négociable par l'initiateur et le répondeur (clé prépartagée ou certificats, par exemple). Si nécessaire, supprimez le protocole de la liste en le sélectionnant, puis en cliquant sur le bouton Supprimer.
8. Cliquez sur OK. 9. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons Monter et Descendre pour sélectionner l'ordre de préférence des méthodes d'authentification si la liste en contient plusieurs.
10. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante. 11. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.
Déplacement d'hôtes entre différents groupes d'isolation Pour plusieurs raisons, les hôtes doivent régulièrement être déplacés d'un groupe à un autre. Il est important de comprendre les implications des modifications apportées aux appartenances de groupe
153
sur les communications. Les sections suivantes décrivent les étapes requises pour ajouter ou supprimer des hôtes dans les groupes. Ajout ou suppression d'un hôte dans une liste d'exemptions Vous pouvez ajouter ou supprimer un hôte dans la liste d'exemptions en modifiant les listes de filtres d'exemptions IPSec et le groupe de sécurité Sans IPSec. Pour ce faire, suivez les étapes décrites dans la section « Modification de la liste de filtres d'une règle existante », plus haut dans ce chapitre. La liste de filtres d'exemption, le nom de l'hôte, ainsi que son adresse IP doivent être connus pour réaliser cette tâche.
Ajout ou suppression d'hôtes et d'utilisateurs dans des groupes existants Lorsque vous ajoutez ou supprimez un hôte dans un groupe d'accès réseau (NAG), les étapes sont spécifiques au rôle joué par l'hôte dans le groupe. Si l'hôte fait office d'initiateur, son ajout ou sa suppression dans le groupe d'accès réseau associé suffit. En revanche, s'il fait office de répondeur, la stratégie qui contrôle la mise à jour du droit « Accéder à cet ordinateur à partir du réseau » doit être appliquée ou supprimée. Si le système fait office d'initiateur et de répondeur, les deux étapes doivent être exécutées. Ajout ou suppression d'initiateurs dans un groupe d'accès réseau existant Vous pouvez ajouter ou supprimer un initiateur dans un groupe d'accès réseau en utilisant les outils standards de gestion de groupes pour modifier le groupe de sécurité associé. Pour modifier un groupe d'accès réseau lié à un ordinateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
4. Pour ajouter un ordinateur au groupe : • Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. • Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez sur OK. • Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom_ordinateur>, puis cliquez sur OK. • Cliquez sur OK.
5. Pour supprimer un ordinateur du groupe : • • • •
Cliquez sur l’onglet Membres. Dans la liste Membres, cliquez sur <nom_ordinateur>, puis cliquez sur Supprimer. Cliquez sur Oui pour supprimer le compte <nom_ordinateur>. Cliquez sur OK.
Remarque : il y aura un délai entre le moment où le compte de l'hôte sera ajouté au groupe et le moment où l'hôte pourra accéder à la ressource restreinte. Ce délai est dû aux délais de réplication et
154
au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la ressource restreinte (si le ticket est mis en cache).
Ajout ou suppression d'utilisateurs dans un groupe d'accès réseau existant Bien que les groupes d'isolation aient été créés pour limiter l'initiation par des hôtes de communications vers la ressource restreinte, ils peuvent également être utilisés pour permettre de restreindre l'accès à cette ressource par des utilisateurs. Si aucune exigence n'est spécifiée pour restreindre l'accès à une ressource d'une manière similaire à un groupe d'accès réseau, le groupe Utilisateurs du domaine se voit accorder le droit « Accéder à cet ordinateur à partir du réseau » sur les répondeurs. Si une exigence est spécifiée pour restreindre l'accès à une ressource, un groupe Utilisateurs NAG est créé. Vous pouvez ajouter ou supprimer un utilisateur avec accès restreint dans un groupe Utilisateurs NAG en recourant aux outils standards de gestion de groupes pour modifier le groupe de sécurité associé. Cette procédure est uniquement requise si un groupe Utilisateurs NAG a été créé et attribué au groupe d'accès réseau ; si le groupe Utilisateurs du domaine est en cours d'utilisation, cette procédure n'est pas nécessaire. Pour modifier un groupe Utilisateurs NAG lié à un utilisateur spécifique
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
4. Pour ajouter un utilisateur au groupe d'accès réseau : • Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. • Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de l'utilisateur>, puis cliquez sur OK.
• Cliquez sur OK. 5. Pour supprimer un utilisateur du groupe d'accès réseau : • Cliquez sur l’onglet Membres. • Dans la liste Membres, cliquez sur le <nom de l'utilisateur> spécifique, puis cliquez sur Supprimer. • Cliquez sur Oui pour supprimer le compte <nom de l'utilisateur>. • Cliquez sur OK.
Remarque : il y aura un délai entre le moment où le compte de l'utilisateur sera ajouté au groupe et le moment où l'utilisateur pourra accéder à la ressource restreinte. Ce délai est dû aux délais de réplication et au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la ressource restreinte (si le ticket est mis en cache).
155
Ajout ou suppression de répondeurs dans un groupe d'accès réseau existant Pour supprimer un hôte répondeur d'un groupe d'accès réseau, vous pouvez supprimer l'attribution de l'objet Stratégie de groupe qui configure le droit « Accéder à cet ordinateur à partir du réseau » sur le répondeur. L'application de l'objet Stratégie de groupe peut être contrôlée par n'importe quel moyen standard permettant de garantir l'application des stratégies avec Active Directory. Néanmoins, l'approche utilisée dans ce guide a attribué l'objet Stratégie de groupe à une unité d'organisation qui a été créée pour contenir les comptes d'ordinateurs de domaine des répondeurs. Le simple déplacement du compte d'ordinateur en dehors de l'unité d'organisation des répondeurs l'empêchera de recevoir l'objet Stratégie de groupe attribué, et l'accès ne sera plus restreint. L'ordinateur reviendra ainsi à la stratégie de domaine d'isolation. (Si le compte d'ordinateur appartenait aussi à un groupe de sécurité de domaine local composé de groupes d'accès réseau, il doit également être supprimé de ce groupe.) Vous devez vous assurer que les hôtes appartenant à plusieurs groupes d'accès réseau sont toujours capables de communiquer avec les autres groupes d'accès réseau après avoir été supprimés de l'un de ces groupes.
Ajout de nouveaux groupes d'accès réseau La création d'un groupe d'accès réseau est un processus relativement simple. Vous devez tout d'abord créer un groupe de domaine local pour contrôler l'accès à la ressource, ainsi qu'un objet Stratégie de groupe pour mettre à jour le droit « Accéder à cet ordinateur à partir du réseau » sur les hôtes qui agissent en tant que serveurs dans le groupe d'accès réseau. Vous devez ensuite appliquer cet objet Stratégie de groupe aux serveurs, et identifier les hôtes qui appartiennent au groupe. Seuls les initiateurs doivent être membres du groupe d'accès réseau. En d'autres termes, si deux serveurs se trouvent dans le même groupe d'isolation et ne communiqueront jamais ensemble, ils n'ont pas besoin d'être ajoutés au groupe d'accès réseau pour leur groupe d'isolation. En revanche, si ces deux serveurs sont amenés à communiquer, ils doivent être ajoutés au groupe d'accès réseau comme le sont tous les autres initiateurs. Si un serveur agit en tant que répondeur au sein de plusieurs groupes d'accès réseau, vous devez vous assurer que tous les groupes de sécurité des groupes d'accès réseau auxquels le serveur appartient sont présents sur le droit « Accéder à cet ordinateur à partir du réseau » de ce système après que l'objet Stratégie de groupe a été appliqué. Si nécessaire, des objets Stratégie de groupe supplémentaires peuvent être requis afin que les ordinateurs remplissent cette exigence. Création d'un nouveau groupe d'accès réseau pour les ordinateurs initiateurs Procédez comme indiqué ciaprès pour créer un nouveau groupe d'accès réseau. Pour créer un nouveau groupe d'accès réseau pour les ordinateurs initiateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe. 4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK. 5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez sur Propriétés.
156
6. Dans la zone de texte Description, tapez une description appropriée pour le groupe. 7. Cliquez sur OK. Ajout de comptes d'ordinateurs initiateurs à un groupe d'accès réseau Procédez comme indiqué ciaprès pour constituer un nouveau groupe d'accès réseau avec des comptes d'initiateurs. Pour constituer le nouveau groupe d'accès réseau des initiateurs avec des comptes d'initiateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Initiateurs NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. 5. Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez sur OK.
6. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le <nom de l'initiateur>, puis cliquez sur OK.
7. Cliquez sur OK. Si vous avez besoin de restreindre encore les utilisateurs du domaine autorisés à accéder à la ressource restreinte, un groupe doit être créé pour les utilisateurs NAG avec accès restreint. À défaut, le groupe Utilisateurs du domaine peut être utilisé à la place. Création d'un nouveau groupe d'accès réseau pour les utilisateurs avec accès restreint Procédez comme indiqué ciaprès pour créer un groupe d'accès réseau pour les utilisateurs avec accès restreint. Pour créer un groupe d'accès réseau pour des comptes d'utilisateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe. 4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK. 5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez sur Propriétés.
6. Dans la zone de texte Description, tapez une description appropriée pour le groupe. 7. Cliquez sur OK.
157
Ajout de comptes d'utilisateurs avec accès restreint à un groupe d'accès réseau Procédez comme indiqué ciaprès pour constituer un nouveau groupe d'accès réseau avec des utilisateurs avec accès restreint. Pour constituer le nouveau groupe d'accès réseau avec des comptes d'utilisateurs
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine, puis lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs. 3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Utilisateurs NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter. 5. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de l'utilisateur>, puis cliquez sur OK.
6. Cliquez sur OK. Création d'un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à partir du réseau » Un objet Stratégie de groupe permet d'attribuer le droit « Accéder à cet ordinateur à partir du réseau » aux groupes d'accès réseau appropriés. Le tableau suivant fournit un exemple d'implémentation, par un objet Stratégie de groupe, d'un groupe d'accès réseau et des noms de groupe associés auxquels le droit « Accéder à cet ordinateur à partir du réseau » doit être accordé. Tableau 6.1 : Exemple de définition de stratégie de groupe d'accès réseau Nom de l’objet Stratégie de groupe
Nom de groupe
Remarque : les groupes répertoriés représentent les groupes minimaux à ajouter. L'administrateur devra déterminer s'il doit accorder ce droit à des groupes supplémentaires. Le groupe Utilisateurs du domaine est ajouté en tant que groupe par défaut. Si l'administrateur souhaite également restreindre l'accès pour certains utilisateurs en plus des ordinateurs, un groupe Utilisateurs NAG devra être créé de la même manière que celui dédié aux comptes d'ordinateurs (contenant les comptes d'utilisateurs sélectionnés). Pour créer un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à partir du réseau »
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC.
158
3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Objets de stratégie de groupe, puis cliquez sur Nouveau.
5. Dans la zone de texte Nom, tapez
7. Développez Configuration ordinateur, développez Paramètres Windows, développez Paramètres de sécurité, développez Stratégies locales, puis cliquez sur Attribution des droits utilisateur.
8. Dans le volet de droite, cliquez avec le bouton droit de la souris sur « Accéder à cet ordinateur à partir du réseau », puis cliquez sur Propriétés.
9. Activez la case à cocher Définir ces paramètres de stratégie. 10. Cliquez sur le bouton Ajouter un utilisateur ou un groupe. 11. Cliquez sur le bouton Parcourir. 12. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le nom de tous les groupes répertoriés dans le tableau précédent, séparés par des pointsvirgules. Cliquez ensuite sur OK.
13. Cliquez sur OK. 14. Fermez l'éditeur d'objets GPO puis la console GPMC. Déploiement d'objets Stratégie de groupe d'un groupe d'accès réseau Pour déployer les objets Stratégie de groupe d'un groupe d'accès réseau, ces derniers doivent tout d'abord être liés à un emplacement dans l'environnement du domaine afin qu'ils puissent être appliqués aux répondeurs appropriés du groupe d'accès réseau. L'application de l'objet Stratégie de groupe peut être contrôlée par n'importe quelle méthode standard permettant de garantir l'application des stratégies avec Active Directory. L'explication détaillée des étapes correspondantes n'entre pas dans le cadre de ce guide et dépend de la structure des unités d'organisation et des méthodes de gestion utilisées au sein de l'organisation.
Désactivation d'IPSec dans un groupe d'isolation Vous pouvez désactiver une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. Pour désactiver la stratégie IPSec, l'objet Stratégie de groupe est configuré pour que les paramètres d'ordinateur soient désactivés. Pour désactiver les paramètres d'ordinateur de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur
159
5. Fermez la console GPMC.
Réactivation d'IPSec dans un groupe d'isolation Vous pouvez réactiver des stratégies IPSec ayant été désactivées en modifiant l'objet Stratégie de groupe qui distribue la stratégie. Pour réactiver une stratégie IPSec désactivée, l'objet Stratégie de groupe est configuré de sorte que les paramètres d'ordinateur soient activés. Pour activer les paramètres d'ordinateur de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur
5. Fermez la console GPMC.
Suppression d'IPSec dans un groupe d'isolation Vous pouvez supprimer une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. Pour supprimer la stratégie IPSec, l'objet Stratégie de groupe est configuré de sorte que la stratégie IPSec ne soit plus attribuée. Pour supprimer l'attribution de la stratégie IPSec de l'objet Stratégie de groupe
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez la console GPMC. 3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez <nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur
5. Développez Configuration ordinateur, développez Paramètres Windows, développez Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory (nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur
7. Vérifiez que la stratégie
Considérations relatives à la sauvegarde et la récupération Cette section fournit des informations sur l'évaluation des processus qui couvrent spécifiquement la sauvegarde et la restauration des composants de la solution d'isolation de serveurs et de domaines.
160
Sauvegarde Active Directory Les stratégies IPSec ne sont pas stockées dans les objets Stratégie de groupe utilisés pour distribuer les stratégies. Les fonctions de sauvegarde et de restauration de la stratégie de groupe capturent uniquement les informations sur lesquelles est basée l'attribution des stratégies IPSec aux objets Stratégie de groupe, et non les informations réelles relatives aux stratégies IPSec. Bien qu'une sauvegarde complète de l'état du système d'un contrôleur de domaine capture les informations relatives aux stratégies IPSec, il est également possible d'utiliser les commandes de menu Exporter des stratégies et Importer des stratégies du composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour sauvegarder et restaurer les stratégies IPSec. Remarque : il est important de sécuriser les sauvegardes de vos stratégies IPSec. Néanmoins, la sauvegarde est un fichier qui hérite des autorisations du système de fichiers NTFS du répertoire dans lequel il est stocké, et les données du fichier ne sont ni chiffrées ni signées. Vous devez protéger les informations de configuration IPSec contenues dans ces fichiers en utilisant les autorisations ou procédures de sécurité appropriées. Seuls les administrateurs IPSec autorisés doivent avoir accès à ces fichiers de sauvegarde. Pour plus d'informations sur la sauvegarde des données d'état du système sur un ordinateur exécutant Windows Server 2003, consultez la page To back up System State data (Sauvegarde des données d'état du système) sur le site Microsoft.com, à l'adresse www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en us/ntbackup_backup_sysstate.asp.
Restauration de systèmes hôtes Sur les ordinateurs pour lesquels une stratégie IPSec a été restaurée à partir d'une sauvegarde (sauvegarde sur bande ou sauvegarde à partir d'une image), la stratégie IPSec appliquée peut être une copie mise en cache de la stratégie IPSec basée sur Active Directory ou une stratégie IPSec locale. Si l'ordinateur se voit attribuer la stratégie IPSec basée sur Active Directory, le service IPSec tente de récupérer à partir d'Active Directory la copie la plus récente de la stratégie attribuée avant d'appliquer la copie mise en cache de la stratégie basée sur Active Directory. Au cours de cette opération, le service IPSec commence par interroger le système DNS (Domain Name System) pour obtenir la liste actuelle des adresses IP de tous les contrôleurs de domaine. Si les objets de stratégie IPSec ont été supprimés d'Active Directory, la copie mise en cache de la stratégie basée sur Active Directory est appliquée à la place. La liste des adresses IP des contrôleurs de domaine de la copie mise en cache de la stratégie IPSec basée sur Active Directory peut avoir considérablement changé depuis la création de la sauvegarde de la stratégie IPSec (par exemple, de nouveaux contrôleurs de domaine peuvent avoir été ajoutés). Si tel est le cas, la communication peut être bloquée avec les contrôleurs de domaine actuels ; ainsi, les authentifications basées sur le protocole Kerberos échoueront lors des tentatives d'établissement de connexions sécurisées à l'aide d'IPSec à distance. En outre, l'ordinateur risque de ne pas être en mesure de recevoir les mises à jour de la stratégie de groupe. Ce problème peut être résolu à l'aide de la procédure suivante :
1. Accédez à l'ordinateur localement et arrêtez le service IPSec sur cet ordinateur. 2. Redémarrez l'ordinateur en Mode sans échec avec prise en charge réseau, et configurez le service IPSec pour un démarrage manuel ou désactivez le service IPSec pour permettre les
161
communications sécurisées à l'aide d'IPSec avec les adresses IP des nouveaux contrôleurs de domaine.
Réduction des risques d'infection sur le réseau Dans certains cas, il peut s'avérer nécessaire d'interrompre rapidement les communications afin d'assurer la sécurité de l'environnement, en cas d'attaques virales ou de violations de la sécurité, par exemple. Les sections suivantes présentent les différentes méthodes pouvant être appliquées pour isoler les hôtes prenant part à des communications authentifiées. Ces méthodes ont été conçues pour ne pas isoler l'infrastructure ni les serveurs exemptés. Il est en effet primordial de ne pas isoler les serveurs d'infrastructure afin d'éviter que les systèmes perdent leur capacité à mettre à jour leurs stratégies IPSec à partir du domaine. Remarque : bien que ces méthodes d'isolation soient techniquement sûres, elles n'ont pas été testées dans un environnement de laboratoire. Il est fortement recommandé de les tester dans un environnement de laboratoire avant de les mettre en application.
Isolation du domaine d'isolation Les hôtes du domaine d'isolation sont autorisés à initier des communications avec des hôtes non approuvés. S'il est nécessaire de bloquer rapidement ce type de trafic, l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisée (Ignorer le trafic entrant, Autoriser le trafic sortant) peut être modifiée pour que le droit « Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec » soit désactivé. Au terme de la période d'interrogation IPSec, tous les hôtes du domaine d'isolation doivent cesser de communiquer avec des systèmes non intégrés à l'environnement IPSec. Pour modifier l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisé (Ignorer le trafic entrant, Autoriser le trafic sortant)
1. Connectezvous à un contrôleur de domaine en tant qu'administrateur de domaine. 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrezle sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gérer les actions de filtrage, cliquez sur l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisé (Ignorer le trafic entrant, Autoriser le trafic sortant), puis cliquez sur Modifier.
5. Activez ou désactivez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec.
6. Cliquez sur OK. 7. Cliquez sur OK. Une fois cette option définie, la stratégie bloque tout le trafic réseau destiné à des hôtes non approuvés. Une fois le problème résolu, la communication peut être rétablie en réactivant l'option.
Blocage des ports
162
Les stratégies IPSec déployées sur les ordinateurs d'un réseau local interne à une organisation sont configurés pour autoriser toutes les communications sur l'ensemble des ports. Cette approche simplifie la configuration et la gestion de l'environnement. Cependant, si un hôte utilisant IPSec se trouve infecté par un logiciel malveillant (virus ou ver, par exemple), il va très probablement transmettre l'infection aux autres ordinateurs. En fonction des stratégies que l'ordinateur utilise, l'infection peut toucher les hôtes approuvés et non approuvés. Les stratégies IPSec peuvent permettre de limiter la contamination par un blocage explicite des ports que le logiciel malveillant utilise. La limite principale que rencontre cette approche est le délai nécessaire aux ordinateurs pour détecter la modification apportée à la stratégie pour y intégrer des filtres de blocage. En outre, certains vers ont envahi le réseau et ont rendu difficile la récupération des modifications relatives à la stratégie IPSec. De plus, certains vers ont utilisé des ports également utilisés par des services vitaux, tels que le système DNS, ce qui rendrait difficile la mise à jour de la stratégie après l'application des filtres de blocage sur l'hôte. Le blocage peut être effectué en créant une règle qui bloque le trafic provenant d'adresses IP quelconques, destiné au port spécifique utilisé par un certain type de logiciels malveillants. Cette règle est ajoutée à toutes les stratégies appliquées à l'environnement. Une fois le logiciel malveillant éliminé, la règle peut être retirée des stratégies. Après avoir identifié les ports et les protocoles utilisés par un certain type de logiciels malveillants, créez une liste de filtres correspondant aux critères relatifs à la communication des logiciels malveillants en suivant les étapes de la procédure « Ajout d'une nouvelle règle à une stratégie IPSec existante », dans la section « Modification de la stratégie IPSec » plus haut dans ce chapitre. L'intervalle d'interrogation de la stratégie IPSec doit être réduit immédiatement après la décision d'utiliser le blocage de ports dans la stratégie de domaine. L'intervalle d'interrogation peut être augmenté à nouveau, une fois la menace écartée. Néanmoins, au lieu de créer un filtre qui utilise une adresse IP en direction d'une adresse IP spécifique, créez un filtre qui utilise « Mon adresse IP » vers n'importe quelle adresse IP. En principe, les filtres en miroir ne sont pas utilisés. Il faut utiliser une liste de filtres contenant deux filtres unidirectionnels (un pour le trafic entrant à destination d'un port connu, et un autre pour le trafic sortant à destination d'un port connu). Par exemple, les filtres suivants bloquent le port SQL 1433 exploité par le ver SQLSlammer : De toute adresse IP > Mon adresse IP, TCP, src *, dst 1433, sans miroir De Mon adresse IP > Toute adresse IP, TCP, src *, dst 1433, sans miroir Naturellement, ces filtres bloquent également les connexions de l'application SQL et doivent être retirés une fois que la menace de contamination par ver a disparu. Veillez à ne pas bloquer l'accès aux ports d'infrastructure essentiels comme DNS, sauf en cas de nécessité absolue. Ces filtres sont plus spécifiques que les filtres du sousréseau Woodgrove qui négocient IPSec pour l'ensemble du trafic transitant sur le réseau interne car ils intègrent une adresse IP spécifique. Une fois le filtre créé, ajoutez une règle à toutes les stratégies IPSec du domaine d'isolation et de groupe pour associer la liste de filtres à l'action de filtrage IPSec – Block (IPSec – Bloquer). Vous souhaiterez peutêtre inclure dans la conception de votre stratégie une règle qui associe déjà une liste de filtres IPSec vierge utilisée pour les ports bloqués à l'aide de l'action de blocage. Cette liste de filtres vierge peut être utilisée par les règles présentes dans l'ensemble des stratégies IPSec et activée de sorte que tous les membres du domaine vérifient cette liste à chaque intervalle d'interrogation. La règle peut également être désactivée ; dans ce cas, l'interrogation du service IPSec détecte quand la règle est activée dans chaque stratégie de groupe d'isolation. Si, pour quelque raison que ce soit, le blocage des ports empêche IPSec d'accéder à Active Directory pour obtenir une stratégie mise à jour, le service IPSec peut être arrêté et redémarré sur l'ordinateur par un administrateur, ou l'ordinateur peut être redémarré. Lorsque le service IPSec démarre, ce
163
dernier tente de télécharger la version la plus récente de la stratégie IPSec attribuée avant d'appliquer l'ancienne version contenue dans la mémoire cache.
Isolation dans le domaine enfant uniquement Si un domaine entier doit être isolé du reste des domaines de la forêt, la stratégie appliquée à ce domaine peut être configurée pour utiliser une clé prépartagée plutôt que le protocole Kerberos. Cette approche permet aux ordinateurs situés dans le domaine enfant de maintenir des communications avec d'autres systèmes du même domaine, mais les communications avec les systèmes extérieurs au domaine auquel ils ont normalement accès sont bloquées. Chaque stratégie du domaine enfant doit être modifiée afin d'utiliser uniquement une clé prépartagée pour la règle IPSec – Secure Organization Subnets (IPSec – Sousréseaux sécurisés de l'organisation). Toutes les méthodes d'authentification existantes, comme le protocole Kerberos, devront être supprimées. Pour configurer les méthodes d'authentification, suivez les étapes décrites dans la section « Modification de la méthode d'authentification d'une règle existante », plus haut dans ce chapitre. Si d'autres règles intégrant l'authentification existent dans la stratégie, elles doivent également être configurées pour utiliser une clé prépartagée. Toutes les stratégies du domaine enfant devant être isolé doivent être configurées de cette façon. Pour réduire les risques d'échec d'authentification de mode principal IKE lors du déploiement de la stratégie, la méthode d'authentification par clé pré partagée peut être placée au premier rang dans la liste des méthodes d'authentification, suivie par la méthode reposant sur le protocole Kerberos. Une fois que tous les ordinateurs disposent de la stratégie mise à jour, la méthode d'authentification Kerberos peut être supprimée. Un processus similaire est utilisé pour restaurer l'authentification pour le protocole Kerberos et supprimer la clé pré partagée une fois la menace écartée.
Isolation dans des groupes prédéfinis Bien que les groupes d'accès réseau constituent une implémentation unique pouvant être utilisée pour isoler un groupe prédéfini d'ordinateurs, il est également possible d'utiliser des clés prépartagées ou des certificats pour réaliser la même isolation. La principale différence par rapport aux groupes d'accès réseau est le fait que vous devrez créer des stratégies distinctes pour chaque groupe d'ordinateurs pour sécuriser le trafic entre les ordinateurs disposant d'une clé prépartagée ou d'un certificat. Cette solution nécessite un processus de planification des communications supplémentaire, notamment si un système appartient à plusieurs groupes. L'inconvénient majeur des clés prépartagées est le fait qu'elles sont stockées en clair dans la stratégie, ce qui les rend facilement détectables (la confidentialité est alors compromise) depuis un client du domaine. Cet inconvénient peut ne pas être gênant si la valeur de la clé prépartagée est uniquement utilisée pour une isolation temporaire lors d'une infection par ver. En raison d'une restriction, IKE vérifie les contraintes de certificat au niveau de l'autorité de certification racine et non de l'autorité émettrice ; il faudrait alors déployer une autorité de certification racine unique pour chaque groupe.
Résumé Ce chapitre fournit des informations, des processus et des procédures nécessaires à la gestion, la maintenance et la modification d'une solution d'isolation de serveurs et de domaines après le déploiement et la mise en service effectifs de cette dernière.
164
Les processus et procédures décrits ici doivent être correctement expliqués et communiqués au personnel susceptible d'être impliqué dans la gestion quotidienne des hôtes de l'environnement. Dans la mesure où la modification, même mineure, d'une stratégie IPSec peut désactiver une voie de communication protégée, ces processus et procédures doivent être conçus de manière à éviter tout risque d'erreur pouvant résulter d'une mauvaise compréhension des conséquences d'une telle modification.
165
Chapitre 7 : Dépannage d'IPSec Ce chapitre fournit des informations relatives au dépannage d'IPSec (Internet Protocol security), dans le cadre d'une isolation de serveurs et de domaines, par exemple. Il est basé sur l'expérience et les processus de l'équipe Service informatique (IT) de Microsoft. Lorsque cela est possible, ce chapitre fait référence aux procédures de dépannage Microsoft existantes ainsi qu'aux informations associées. Le support informatique de Microsoft repose sur un modèle de prise en charge multiniveaux, et le support technique est communément appelé support de niveau 1. Les procédures de remontée des incidents permettent aux techniciens du support technique de transférer les incidents nécessitant l'intervention de spécialistes. Les procédures de ce chapitre font référence à trois niveaux de support : niveau 1, niveau 2 et niveau 3. Pour garantir des conseils aussi pratiques et précis que possible, la majeure partie du contenu se situe au niveau 2. Les conseils de niveau 1 permettent d'aider les entreprises à déterminer aussi rapidement que possible si un problème est lié à IPSec et, si tel est le cas, à générer les informations requises pour aider les ingénieurs du support de niveau 2 à résoudre le problème. Les informations extrêmement détaillées et complexes qui sont nécessaires à la résolution des problèmes de niveau 3 ne sont pas traitées dans ce chapitre. Si les informations proposées dans ce chapitre ne permettent pas de résoudre un problème lié à IPSec, Microsoft vous recommande de contacter Microsoft® Product Support Services (services de support technique) pour obtenir une assistance supplémentaire. La plupart des procédures de support, des outils et des scripts utilisés par Microsoft sont fournis dans ce chapitre à titre de référence. Ces recommandations et outils sont généralement adaptés et répondent aux besoins spécifiques de votre entreprise. Lorsque IPSec est utilisé pour sécuriser le trafic sur le réseau via les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol), les procédures et outils de dépannage réseau TCP/IP traditionnels peuvent se révéler inefficaces. C'est pourquoi il est important de planifier et d'élaborer des techniques de dépannage spécifiques à IPSec qui pourront être utilisées si un problème se présente sur les ordinateurs qui utilisent ou (tentent d'utiliser) IPSec pour leurs communications.
Niveaux de support et transfert des incidents Le support de l'isolation de serveurs et de domaines est un service standard proposé par Microsoft, qui est défini par les accords sur les niveaux de service (service level agreement, SLA). Le support de l'isolation est fourni par les niveaux suivants :
• Niveau 1 : support technique. Le support technique constitue le point d'entrée à la fois pour les problèmes client associés et non associés à un domaine. Le support technique prend également en charge les serveurs gérés par les services informatiques centraux. (Les autres serveurs peuvent être gérés par des équipes de gestion des applications d'entreprise ou des groupes de produits). Les membres du support technique sont formés pour utiliser une taxinomie et divers organigrammes de classification des problèmes liés à l'isolation de serveurs et de domaines.
Au cours de la phase pilote de la solution d'isolation de Microsoft, les problèmes rencontrés par les clients ont été transférés au service de sécurité informatique d'entreprise. Cependant, après le déploiement de la solution dans l'étape de production, les problèmes client ont été traités par les équipes de support de niveau 2.
166
• Niveau 2 : exploitation du centre de données, centre d'exploitation du réseau global,
support des applications d'entreprise et support de messagerie/collaboration. Ces groupes sont des équipes d'exploitation quotidienne qui surveillent et gèrent les services informatiques et leurs ressources associées. Lors des phases pilote d'isolation de serveurs et de domaines, ces équipes ont été le point de départ de transfert des problèmes de serveur et du dépannage pour le support technique et le service de sécurité informatique d'entreprise. Chaque groupe possède un expert en isolation de serveurs et de domaines, ainsi que des procédures de dépannage détaillées.
• Niveau 3 : services d'infrastructure et de réseau Windows. Lors des phases pilote d'isolation
de serveurs et de domaines, ce groupe a défini une équipe d'experts en dépannage des composants architecturaux et des technologies inhérentes à la solution, comme IPSec, le traitement des paquets TCP/IP, les comptes d'ordinateurs et les droits de connexion au réseau. Si un autre niveau de transfert est nécessaire au sein de Microsoft, le niveau 3 fonctionne directement avec les équipes de développement Windows jusqu'à ce que le problème soit clos. Hors du cadre de Microsoft, ce niveau fonctionne avec les services de support technique Microsoft en cas de nécessité.
La section suivante résume les techniques de dépannage pouvant être utilisées par le personnel du support technique dans l'organisation du support de niveau 1.
Dépannage de niveau 1 Cette section présente le processus général de dépannage des problèmes liés à IPSec qui est utilisé par le personnel du support technique chargé du support de niveau 1. En général, le personnel du support de niveau 1 est composé d'opérateurs téléphoniques qui tentent de diagnostiquer les problèmes à distance.
Le problème estil lié à IPSec ? Le support technique est susceptible de recevoir des appels du type « J'ai réussi à me connecter au serveur x jusqu'à l'activation d'IPSec » ou « Tout fonctionnait parfaitement hier, mais je n'arrive pas à me connecter aujourd'hui ». D'après l'expérience des équipes informatiques de Microsoft, le déploiement d'IPSec a entraîné l'augmentation des volumes d'appels pour tous les types de problèmes de connectivité réseau et les incidents « d'accès refusé » car les utilisateurs étaient plus attentifs aux comportements des applications et du réseau. Si un utilisateur pensait que le problème était lié à IPSec, il appelait le support technique. Un plan d'implémentation de l'isolation de serveurs et de domaines doit inclure un système de classification des appels afin que le personnel du support technique puisse fournir des rapports précis sur le volume et la nature des problèmes liés à IPSec. Une fois que l'appelant a fourni toutes les informations d'administration utiles, le personnel du support technique doit suivre un processus de dépannage défini. Étant donné que les répercutions des stratégies IPSec sur les communications peuvent varier et que le processus de déploiement peut prendre plusieurs jours (voire plusieurs semaines), il est vivement recommandé de définir un organigramme et de le mettre à jour pour chaque ensemble de modifications d'isolation mis en place. Le personnel de gestion du support technique doit être impliqué dans ce processus de planification. L'objectif du support technique est de classer le problème dans une catégorie afin de pouvoir lui appliquer des solutions adaptées. Si ces tentatives ne permettent pas de résoudre le problème, le support technique doit s'assurer qu'il a bien reçu les informations requises, puis il doit transférer le problème au support de niveau 2. Par exemple, le support technique doit être en mesure d'identifier divers types de problèmes de la manière suivante :
• Connectivité réseau. Utilisez les messages ping et tracert du protocole ICMP (Internet Control Message Protocol) pour tester les chemins du réseau.
167
• Résolution de noms. Utilisez les commandes ping <nom destination> et nslookup. • Applications. Certaines applications fonctionnent (par exemple, net view), alors que d'autres ne fonctionnent pas lorsqu'elles communiquent avec la même destination.
• Services. Par exemple, déterminez si le serveur exécute le service de routage et d'accès distant (Routing and Remote Access, RRAS), lequel crée une stratégie IPSec automatique conflictuelle avec le protocole L2TP.
• Ordinateur de l'appelant. Déterminez s'il peut accéder à n'importe quel ordinateur hôte ou à un
ordinateur de destination approuvé spécifique qui est utilisé par le support technique pour les tests et les diagnostics.
• Ordinateur cible. Déterminez si l'ordinateur de l'appelant peut accéder à tous les ordinateurs du support technique utilisés pour les tests et s'il ne peut pas accéder à certains ordinateurs de destination.
En fonction de l'entreprise, le support technique peut utiliser l'Assistance à distance ou le Bureau à distance pour se connecter à l'ordinateur de l'appelant. Les instructions fournies dans ce chapitre ne nécessitent pas un accès à distance, mais elles peuvent s'avérer utiles pour le personnel du support technique qui peut s'en servir plutôt que de guider l'appelant dans le composant logiciel enfichable MMC (Microsoft Management Console) Moniteur IPSec ou la visionneuse du journal des événements. Dans des scénarios où l'isolation de serveurs est utilisée sans isolation de domaines, le personnel du support technique doit savoir quels serveurs font partie du groupe d'isolation. Détermination de l'étendue et de la gravité L'une des premières questions auxquelles le support de niveau 1 doit répondre est la suivante : « qui est concerné par le problème ? » En effet, le personnel technique doit savoir si d'autres utilisateurs rencontrent le même problème et, le cas échéant, le nombre d'utilisateurs concernés et leur emplacement. Le personnel technique doit ensuite s'intéresser à l'étendue du problème. Par exemple, cela affectetil la connectivité d'un seul serveur ou existetil d'autres problèmes de type échec de connexion ou d'authentification sur des zones importantes du réseau ? Les problèmes de connectivité peuvent impliquer de nombreuses couches et technologies utilisées dans les communications réseau. Les ingénieurs du support technique doivent connaître le fonctionnement général des communications réseau TCP/IP Windows, ainsi que les problèmes spécifiques liés à la solution. Cette section détaille les différents types de problèmes courants que chaque support de niveau 1 doit traiter.
• Problèmes spécifiques à l'ordinateur. Les communications protégées par IPSec requièrent une
authentification IKE (Internet Key Exchange) mutuelle des ordinateurs. Les ordinateurs qui débutent des communications et ceux qui y répondent doivent posséder des comptes de domaine valides et avoir accès aux contrôleurs de leur domaine. En outre, pour que les attributions de stratégie IPSec et que les contrôles d'accès au réseau fonctionnent, il est nécessaire que les comptes d'ordinateur soient dans les groupes de domaine appropriés. D'autres problèmes spécifiques peuvent affecter le comportement d'IPSec : • Le système d'exploitation ne dispose pas du Service Pack ou du correctif approprié, ou la configuration de la clé du registre est incorrecte. • Un logiciel ou des services particuliers sont installés et en cours d'exécution sur l'ordinateur. • La connexion réseau utilise une adresse IP spécifique ou communique à l'aide d'un chemin réseau particulier.
168
En raison de ces types de problèmes, certains ordinateurs peuvent rencontrer des problèmes de connectivité et d'autres non. Remarque : tous les outils de dépannage d'IPSec mentionnés dans ce chapitre nécessitent des privilèges du groupe des administrateurs locaux.
• Problèmes d'emplacement réseau et problèmes spécifiques au chemin. Dans une solution
d'isolation de serveurs et de domaines ou de déploiement à grande échelle d'IPSec, il est probable que la totalité du trafic TCP et UDP sera encapsulée. Par conséquent, les périphériques réseau du chemin ne voient que les protocoles IKE, IPSec et ICMP. S'il existe des problèmes réseau au niveau de la transmission de ces trois protocoles entre la source et la destination, il est possible que la communication soit bloquée entre les deux ordinateurs.
• Problèmes spécifiques à l'utilisateur. Le déploiement d'IPSec, dans le cas d'une isolation de
serveurs et de domaines, par exemple, peut avoir des répercutions sur les droits de connexion au réseau des utilisateurs d'un domaine. Par exemple, le problème peut concerner uniquement les utilisateurs qui ne font pas partie d'un groupe autorisé à accéder au réseau, ou il peut concerner un utilisateur autorisé qui ne parvient pas à obtenir les informations d'authentification Kerberos contenant les appartenances de groupe correctes. Il peut exister des différences de comportement entre les comptes de domaine et d'utilisateur local ou les comptes de service.
Deux autres caractéristiques de l'isolation de serveurs et de domaines sont fréquentes lors des déploiements d'IPSec en entreprise : il s'agit de l'utilisation de filtres de sousréseau pour définir les intervalles d'adresses utilisés sur le réseau interne et l'application de stratégies IPSec basées sur l'appartenance au domaine et au groupe qui ne tiennent pas compte de l'emplacement d'un ordinateur sur le réseau interne. C'est pourquoi, en cas de problème avec la conception des filtres de sous réseau ou le chemin réseau utilisé par cet ordinateur pour communiquer avec les autres, des problèmes de connectivité peuvent survenir uniquement dans certaines zones du réseau lors de l'utilisation d'une adresse IP particulière (une adresse sans fil au lieu d'une adresse LAN), ou sur certains ordinateurs uniquement.
Organigrammes de dépannage Les organigrammes de gestion des appels de cette section ont été élaborés par les équipes informatiques de Microsoft pour faciliter le classement des problèmes de support d'IPSec de niveau 1. Outre les outils standards, deux des organigrammes font référence à un script d'actualisation de la stratégie IPSec, dont une description est fournie dans la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre. La figure 7.1 est utilisée pour réaliser un diagnostic initial et pour déterminer le type de problème :
• S'agitil d'un problème de connectivité réseau ? Si oui, procédez à une action de dépannage réseau de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.
• S'agitil d'un problème de résolution de noms ? Si oui, procédez à une action de dépannage de
résolution de noms de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.
• S'agitil d'un problème lié à l'application ? Si oui, transférez le problème au support de niveau 2. • S'agitil d'un problème IPSec lié à l'ordinateur de l'appelant ? Si oui, reportezvous à la figure 7.2.
• S'agitil d'un problème IPSec lié à l'ordinateur cible que l'appelant tente de contacter ? Si oui, reportezvous à la figure 7.3.
169
Figure 7.1 Processus de dépannage en cas d'échec de communication avec l'ordinateur cible
Remarque : cet organigramme part du principe que l'ordinateur de l'appelant exécute IPSec et que les zones DNS de recherche inversée sont configurées pour permettre le bon fonctionnement de la commande ping –a. La figure 7.2 permet d'identifier les problèmes liés à l'ordinateur de l'appelant. Outre les diagnostics, cet organigramme référence l'utilisation d'un script d'actualisation de stratégie IPSec (reportezvous à la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre), qui peut résoudre le problème sans nécessairement l'identifier. Les étapes illustrées dans la figure 7.2 vous aident à déterminer les éventuels problèmes suivants liés à l'ordinateur de l'appelant :
• S'agitil d'un problème de routage et d'accès distant ? Si oui, arrêtez le service RRAS (s'il n'est pas requis) ou transférez le problème au support de niveau 2.
• S'agitil d'un problème de stratégie ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec.
• S'agitil d'un problème lié au compte de domaine ? Si oui, créez un compte de domaine pour l'ordinateur de l'appelant.
• S'agitil d'un problème autre que ceux énoncés cidessus ? Si l'actualisation de la stratégie IPSec et/ou la création d'un compte de domaine n'ont pas permis de résoudre le problème, transférez le problème au support de niveau 2.
170
Figure 7.2 Dépannage d'IPSec sur l'ordinateur de l'appelant – problèmes connexes
La figure 7.3 permet d'identifier les problèmes liés à un ordinateur cible spécifique. Notez que cet organigramme référence également l'utilisation d'un script d'actualisation de stratégie IPSec qui peut résoudre le problème sans nécessairement l'identifier. La figure 7.3 vous aide à déterminer les éventuels problèmes suivants liés à l'ordinateur cible (ou vous indique le chemin d'accès à cet ordinateur) :
• S'agitil d'un problème RRAS ? Si oui, transférez le problème au support de niveau 2. • S'agitil d'un problème de stratégie IPSec ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec. Vérifiez ensuite la connectivité réseau.
• S'agitil d'un problème de connectivité réseau ? Si oui, transférez le problème au support de niveau 2.
• S'agitil d'un problème de droits de connexion ? Si oui, transférez le problème au support de niveau 2.
171
Figure 7.3 Dépannage d'IPSec sur l'ordinateur cible – problèmes connexes
Une fois que le personnel du support de niveau 1 a étudié le problème par rapport aux organigrammes, l'un des états suivants est attribué au problème :
• Résolution complète. Cet état indique que le problème a été résolu et que sa cause a peutêtre été déterminée.
• Résolution partielle. Cet état signifie que le problème a été résolu mais que sa cause n'a pas été totalement comprise. Par exemple, l'actualisation d'une stratégie IPSec peut résoudre le problème mais n'explique pas forcément pourquoi une mauvaise stratégie ou aucune stratégie n'a été appliquée.
• Non résolu. Cet état indique que le problème est toujours en attente d'une résolution mais que sa cause a probablement été identifiée. Le problème est transféré au support de niveau 2.
Prévention des attaques de manipulation
172
Dans une solution d'isolation, le personnel du support technique peut avoir connaissance de certaines zones spécifiques de l'environnement informatique non protégées par IPSec, comme les ordinateurs appartenant à la liste d'exemption. Ces zones ne doivent pas être utilisées pour protéger des informations confidentielles, car en général, les autres solutions de sécurité ne donnent accès à ces informations qu'aux équipes de support de niveau supérieur. C'est pour cette raison que le personnel du support technique doit être formé à la détection et à la prévention des manipulations. Une attaque de manipulation se manifeste lorsqu'une personne peu fiable tente d'obtenir des informations sur le fonctionnement de la sécurité et sur les points faibles du système de sécurité, en profitant simplement de la tendance des gens à faire confiance aux autres. Le personnel du support technique doit contrôler attentivement les informations suivantes :
• Membres de la liste d'exemption. La liste des adresses IP dans les filtres de la liste d'exemption
est à la disposition des administrateurs locaux sur tous les hôtes approuvés lors de l'utilisation du composant logiciel enfichable MMC Moniteur IPSec ou lors de l'affichage du cache de la stratégie IPSec dans le registre local. De plus, les paramètres de sécurité utilisés dans l'entreprise sont susceptibles de donner aux utilisateurs non administratifs un accès en lecture au cache. Une fois que l'isolation du domaine est entièrement implémentée, les pirates analysent le réseau pour détecter les ordinateurs exemptés qui seront capables de répondre aux requêtes de connexion TCP et UDP. Notez que les serveurs DNS, DHCP et WINS sont facilement identifiables à partir de la configuration DHCP et que les contrôleurs de domaine sont faciles à localiser par l'utilisation d'une requête DNS ou UDP LDAP (Light Directory Access Protocol).
• Ordinateurs de l'entreprise ne faisant pas partie de la solution d'isolation. Par exemple, certains types de serveurs ou domaines peuvent ne pas être inclus dans la solution.
• Ordinateurs qui utilisent l'isolation de serveurs ou qui requièrent un contrôle d'accès basé
sur les machines. Les serveurs contenant les informations les plus sensibles sont généralement dotés des protections de sécurité les plus efficaces.
• Utilisateurs qui sont des administrateurs ou qui jouent un rôle spécial dans le service
informatique. Les noms de connexion ou les adresses électroniques sont divulgués lorsqu'ils sont utilisés dans les noms complets ou partiels des ordinateurs.
• Sousréseaux utilisés à des fins spécifiques ou par certaines entreprises. Si ces informations sont connues, un pirate peut alors concentrer son attaque sur les points les plus importants du réseau.
• Autres mesures de sécurité basées sur le réseau qui sont utilisées. Par exemple, il est
extrêmement utile pour un pirate de savoir s'il existe des parefeu, si les filtres de routeur autorisent certains trafics ou si la détection d'intrus sur le réseau est utilisée.
Les agents du support technique doivent également être vigilents si des appelants leur demandent de se connecter à l'adresse IP de leur ordinateur pour détecter un problème ; par exemple, un pirate demande à une personne du support technique de se connecter à son ordinateur en utilisant le partage de fichiers, le Bureau à distance, Telnet ou un autre protocole réseau. Si l'agent du support technique effectue la connexion sans IPSec, l'ordinateur pirate peut obtenir des informations sur le mot de passe ou (dans certains cas, comme avec Telnet) « dérober » le mot de passe. Cette situation peut se produire car certains protocoles réseau des clients ne procèdent pas à l'authentification de l'ordinateur de destination, ni n'établissent de relation d'approbation, ou encore, ils ne requièrent pas de protection par mot de passe fiable avant de révéler des informations sur l'identité de l'utilisateur ou des données sur le mot de passe.
Exemples de scripts de prise en charge
173
Dans la plupart des scénarios de dépannage, il est possible de trouver rapidement une solution lorsque les informations appropriées ont été identifiées. Pour ce faire, vous pouvez utiliser divers outils Windows, comme ceux déisngés dans les organigrammes. Dans la solution Woodgrove Bank, plusieurs scripts ont été développés pour fournir des informations clés, sans que le personnel du support de niveau 1 ne connaisse en détail le fonctionnement des outils et la syntaxe. Ces scripts sont disponibles dans le dossier de téléchargement Tools and Templates de ce guide. Scripts disponibles pour le support de niveau 1 Si l'utilisateur est également l'administrateur local de son ordinateur, le personnel du support technique peut lui demander d'exécuter l'un des trois scripts fournis dans le cadre de cette solution. Ces scripts sont des exemples des scripts personnalisés utilisés dans l'environnement Woodgrove Bank détaillé dans ce guide. Ils sont décrits dans ce chapitre pour illustrer la manière dont les scripts peuvent être utilisés dans le processus de dépannage. Remarque : ces scripts sont des exemples testés, mais ils ne sont pas pris en charge par Microsoft. Ils doivent être utilisés par une entreprise comme base pour l’élaboration d'une solution personnalisée. IPSec_Debug.vbs Ce script fournit des informations de débogage et peut résoudre certains problèmes. Il arrête et redémarre le service IPSec (qui supprime toutes les associations de sécurité IKE et IPSec actuelles), force une actualisation de stratégie de groupe à recharger la stratégie IPSec actuellement affectée au domaine à partir du service d'annuaire Active Directory® et met à jour le cache de la stratégie. Pour éviter la perte de connectivité des sessions de bureau à distance, le script doit être téléchargé sur l'ordinateur de l'appelant et exécuté localement par un compte disposant de privilèges administratifs. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript IPSec_Debug.vbs Le script effectue les fonctions suivantes :
• détection de la version du système d'exploitation ; • appel du script Detect_IPSec_Policy.vbs ; • augmentation de la journalisation de la stratégie de groupe ; • augmentation de la journalisation du protocole d'authentification Kerberos version 5 ; • purge des tickets actuels du protocole Kerberos ; • actualisation de la stratégie de groupe ; • activation de la journalisation IPSec ; • exécution de tests PING et SMB (Net View) ; • détection des versions de fichier IPSec ; • exécution de tests de diagnostic de la stratégie et du réseau ; • copie des événements IPSec 547 dans un fichier texte ; • désactivation de la journalisation IPSec ; • restauration de la journalisation du protocole Kerberos ; • restauration de la journalisation de la stratégie de groupe. 174
Ce script active également tous les journaux liés à IPSec en vue du dépannage par le support de niveau 2. Detect_IPSec_Policy.vbs Ce script détermine si l'ordinateur exécute la stratégie IPSec appropriée en vérifiant les informations sur la version de la stratégie IPSec de domaine dans le cache du registre local actuel. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript Detect_IPSec_Policy.vbs Remarque : ce script est également appelé à partir du script IPSec_Debug.vbs ; il n'est donc pas nécessaire de l'exécuter en complément de ce dernier. Refresh_IPSec_Policy.vbs Il s'agit du script d'actualisation de la stratégie IPSec référencé dans les organigrammes de dépannage. Il actualise les tickets du protocole d'authentification Kerberos sur l'ordinateur ainsi que la stratégie de groupe et peut résoudre le problème si ce dernier est provoqué par une attribution de stratégie IPSec incorrecte ou par un échec lors du téléchargement de la stratégie de groupe. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande : cscript Refresh_IPSec_Policy.vbs
Transfert des problèmes Lorsque le personnel du support technique doit transférer un problème IPSec, le personnel du niveau 1 doit collecter les informations suivantes et les transmettre avec la requête de service :
• les fichiers journaux générés avec le script IPSec_Debug.vbs ; • le nom de l'ordinateur de l'appelant afin que le niveau de support technique suivant puisse identifier le fichier journal généré par le script ;
• l'ordinateur de destination auquel l'accès est refusé, afin que le problème soit transféré au groupe de support compétent.
Les scénarios d'isolation de serveurs disposent souvent de leur propre équipe technique pour identifier l'appartenance des groupes d'accès au réseau.
Préparation du dépannage de niveau 2 Le support de niveau 2 a deux rôles principaux. Tout d'abord, en tant que destinataire des transferts de niveau 1, le niveau 2 valide les problèmes et passe en revue les étapes effectuées par le niveau 1 pour s'assurer qu'aucune étape de dépannage n'a été omise. Dans cette optique, le niveau 2 doit confirmer que les problèmes transférés sont véritablement liés à IPSec et qu'il ne s'agit pas d'une erreur de diagnostic. Ensuite, en tant qu'ingénieurs de support réseau qualifiés, les membres du support de niveau 2 doivent utiliser leurs compétences et leur expérience (voir la section suivante) pour résoudre le problème grâce à l'analyse du journal et sans obtenir le contrôle administratif de l'ordinateur. Toutefois, les fichiers journaux ne font que capturer les informations, et les actions correctives nécessitent un accès administratif. En principe, un membre du support technique de niveau 2 n'est pas administrateur de domaine et n'est pas chargé d'apporter des modifications à une stratégie IPSec basée sur un domaine ni aux appartenances de groupe.
175
Compétences du support de niveau 2 Le personnel technique chargé du support IPSec de niveau 2 doit posséder des compétences et de l'expérience dans les domaines suivants :
• Stratégie de groupe. Il doit connaître les stratégies à attribuer, savoir comment elles sont attribuées et être en mesure d'effectuer les tâches suivantes :
• vérifier les listes de contrôle d’accès (Access control lists, ACL) sur les objets de la stratégie de groupe (Group policy objects, GPO) ; • vérifier les paramètres GPO ; • vérifier les appartenances des ordinateurs et des utilisateurs aux divers groupes.
• Expérience des logiciels tiers utilisés par l'entreprise. • Identification des échecs d'authentification. • Le personnel technique doit être capable de vérifier que le compte d'un ordinateur appartenant à un domaine est correct en utilisant les utilitaires netdiag et nltest.
• Configuration IPSec. Le personnel technique doit être capable d'effectuer les tâches suivantes : • vérifier les configurations du filtre IPSec ; • recharger la stratégie de domaine IPSec ; • désactiver entièrement IPSec ou uniquement la stratégie de domaine afin d'utiliser la stratégie locale pour des tests ; • dépanner le processus de négociation IKE d'IPSec et les protocoles de sécurité.
• Réseau. Le personnel technique doit être capable d'effectuer les tâches suivantes : • dépanner la pile de protocole réseau sur un ordinateur hôte ; • comprendre et résoudre les informations collectées dans un fichier de suivi réseau ; • dépanner des problèmes de chemin d'accès au réseau, y compris les solutions de recherche de l'unité maximale de transfert (Maximum Transmission Unit, MTU) du chemin TCP et les solutions d'accès distant au réseau privé virtuel (virtual private network, VPN).
Problèmes inhérents à l'utilisation d'IPSec Comme nous l'avons mentionné dans la section précédente, dans le cas d'une solution d'isolation de serveurs et de domaines, le personnel du support de niveau 2 a besoin de connaître les détails relatifs aux communications protégées par IPSec, mais il doit aussi être capable d'isoler les problèmes associés à d'autres composants. Pour établir une communication IPSec entre deux ordinateurs, ceuxci nécessitent généralement une stratégie IPSec compatible. Par exemple, une stratégie IPSec peut bloquer la communication si l'ordinateur distant ne dispose pas d'une stratégie IPSec adéquate. Bien que ce comportement soit intentionnel ou acceptable lors du déploiement d'un changement de stratégie, le fait qu'il bloque la connectivité réseau entre un ou plusieurs ordinateurs et provoque l'apparition d'avertissements ou d'erreurs dans une application n'est pas forcément visible immédiatement. Dans le pire des cas, un administrateur peut accidentellement attribuer une stratégie IPSec à tous les membres d'un domaine qui bloque la totalité du trafic. Il est difficile d'interrompre la réplication de la stratégie préjudiciable, sauf si l'erreur est immédiatement réparée avec une attribution qui réplique rapidement l'attribution d'origine. Ce type d'erreur entraîne une situation dans laquelle les communications entre un client et un contrôleur de domaine sont nécessaires à l'utilisation d'IPSec. Étant donné que l'authentification utilisée dans cette solution repose sur le protocole Kerberos, les clients qui héritent de cette stratégie ne sont pas en mesure d'effectuer le processus de connexion, car ils ne sont pas capables d'obtenir le ticket Kerberos requis pour sécuriser les communications. Les administrateurs doivent planifier avec
176
minutie toute modification de la stratégie et s'assurer que des mesures de protection existent pour minimiser les risques de ce type de situation. Des informations générales sur le dépannage du protocole TCP/IP sont fournies dans les guides de dépannage répertoriés à la section « Informations complémentaires » à la fin de ce chapitre. Cependant, plusieurs procédures mentionnées dans ces guides fonctionnent uniquement si IPSec assure la connectivité. Si IKE ou IPSec sont défaillants, alors la plupart de ces procédures et outils deviennent inopérants. Dans un scénario d'isolation de serveurs et de domaines, il est possible que certaines procédures indiquées dans ces guides ne fonctionnent pas du tout, même si IPSec assure la connectivité. Un service de support technique doit mettre à jour et personnaliser ses outils et procédures de dépannage afin qu'ils soient efficaces dans un environnement d'isolation de serveurs et de domaines. Comme il existe différentes manières de déployer des stratégies IPSec pour contrôler et sécuriser le trafic réseau, il est peu vraisemblable que les entreprises puissent uniquement utiliser les procédures existantes et un jeu d'outils générique. Il est important que le personnel du support dispose d'exemples documentés sur les résultats escomptés des outils de dépannage réseau qui sont obtenus à partir d'un laboratoire où l'isolation de serveurs et de domaines ou le déploiement d'IPSec fonctionnent correctement. Dans la plupart des cas, les outils de diagnostic réseau n'attendent pas le délai de trois secondes pour passer en communication en texte clair ou les brefs délais requis pour la négociation IKE initiale des associations de sécurité (security associations, SA) d'IPSec. Par conséquent, les outils peuvent afficher un résultat lors de leur exécution initiale et afficher un autre résultat s'ils sont exécutés quelques secondes plus tard. En outre, lorsque l'accès au réseau est délibérément refusé par IPSec, les outils signalent des échecs. Le type d'échec dépend de l'outil utilisé et de l'environnement IPSec. Remarque : dans la section consacrée au support de niveau 1, les termes appelant et cible ont été utilisés pour aider le personnel du support technique à résoudre les problèmes courants. Dans la section relative au support de niveau 2, il est préférable d'utiliser les termes IPSec initiateur et répondeur pour que les processus de dépannage avancé soient plus clairs. Le reste de ce chapitre utilise ces termes IPSec. Stratégie de groupe et appartenance aux groupes La stratégie IPSec basée sur le domaine dépend de la stratégie de groupe et du téléchargement des GPO. Si le système de stratégie de groupe du client rencontre des erreurs lors de la détection de changements GPO ou lors de leur téléchargement, la connectivité IPSec peut s'en trouver affectée. Si l'attribution de la stratégie de groupe est contrôlée par l'appartenance à une unité d'organisation (UO) et que les comptes d'ordinateurs sont par inadvertance déplacés vers une autre UO, supprimés ou recréés dans une UO inappropriée, il est possible qu'une stratégie IPSec inadéquate soit attribuée. Cette solution utilise les groupes de sécurité des domaines pour contrôler les attributions de stratégies et l'accès au réseau. L'appartenance aux groupes est contenue dans les tickets (tickets TGT et de service) du protocole d'authentification Kerberos version 5. La durée de vie de ces tickets est assez longue. Ainsi, les administrateurs doivent prévoir le temps nécessaire aux ordinateurs pour recevoir les informations d'identification des nouveaux tickets TGT et de service Kerberos contenant les mises à jour des appartenances aux groupes. Le protocole Kerberos permet très difficilement de déterminer si les tickets Kerberos d'un ordinateur contiennent les appartenances aux groupes appropriées. Il s'agit d'une difficulté liée à la conception des tickets, car toutes les informations sur l'appartenance à un groupe sont stockées sous forme chiffrée dans le ticket. L'appartenance à un groupe doit être déterminée par l'utilisation des informations du service d'annuaire, et non par l'utilisation des tickets. Authentification Kerberos La conception de l'isolation de serveurs et de domaines utilise le protocole Kerberos version 5 pour l'authentification IKE. Étant donné que le protocole Kerberos requiert une connectivité réseau et un
177
service disponible à partir du DNS et des contrôleurs de domaine, le manque de connectivité entraîne l'échec de l'authentification Kerberos et d'IKE. (IKE échoue également si Kerberos échoue.) Ainsi, des problèmes de connectivité entre un ordinateur A et un ordinateur B peuvent être provoqués par une connectivité réseau bloquée entre l'ordinateur A et l'ordinateur C. Ces problèmes sont causés par l'incapacité du protocole Kerberos de s'authentifier auprès d'un contrôleur de domaine. Dans ce type de situation, les informations fournies dans les événements 547 des journaux d'audit et de sécurité de Windows offrent généralement des conseils très précieux sur la source du problème. Trafic entrant protégé par IPSec requis Cette solution d'isolation de serveurs et de domaines spécifie que des communications protégées par IPSec sont requises pour l'accès entrant. Cette condition a pour conséquence d'obliger les outils de surveillance à distance exécutés sur des ordinateurs non approuvés ou sur des périphériques de surveillance réseau dédiés à signaler qu'il est impossible de contacter un ordinateur distant. Si ces ordinateurs ou périphériques ne peuvent pas intégrer l'environnement « approuvé », ils ne seront pas capables de jouer un rôle de surveillance sauf si des exemptions spécifiques sont ajoutées à la conception. Le dépannage est compliqué par le fait qu'IPSec peut être requis pour établir la connectivité vers un hôte approuvé, ce qui signifie qu'un administrateur risque de ne pas pouvoir se connecter à un hôte approuvé, ni de pouvoir interrompre le service IPSec sans perdre la connectivité. Si la stratégie IPSec de l'administrateur autorise la communication en texte clair, alors la connexion à distance subit un délais de trois à quatre secondes après l'interruption du service sur l'ordinateur distant. Toutefois, l'arrêt du service IPSec sur un ordinateur distant supprime les associations de sécurité IPSec utilisées par tous les autres ordinateurs actuellement connectés. Si les autres ordinateurs ne sont pas en mesure d'établir la communication en texte clair, alors les communications sont interrompues et les connexions TCP sont hors délais. Comme les ruptures soudaines des communications TCP peuvent entraîner la corruption des données de certaines applications, l'arrêt du service IPSec doit uniquement être utilisé comme dernier recours du processus de dépannage. Avant l'arrêt du service IPSec, il est préférable de préparer la mise hors tension de l'ordinateur afin que tous les utilisateurs connectés puissent mettre fin correctement aux communications. Problèmes de direction des communications L'un des scénarios de dépannage courants présente une communication réussie dans une direction mais qui échoue dans la direction opposée. L'authentification IKE requiert généralement l'authentification mutuelle des ordinateurs. Si un ordinateur ne peut pas obtenir de ticket Kerberos lorsqu'il initie le mode IKE principal pour un ordinateur distant, alors IKE échoue. Cette situation peut se produire si le client Kerberos de l'initiateur ne peut pas accéder à un contrôleur du domaine de l'ordinateur de destination. Si les ordinateurs font partie de domaines qui ne sont pas mutuellement approuvés (approbation bidirectionnelle), alors les négociations IKE en mode principal réussissent lorsqu'un seul ordinateur démarre et échoue si l'autre ordinateur démarre. De la même manière, les droits de connexion au réseau peuvent être différents sur deux ordinateurs. Il est possible que les négociations IKE en mode principal et en mode rapide échouent dans une direction pour ces raisons, mais également si les conceptions des stratégies IPSec ne sont pas compatibles. Les parefeu pour hôte qui interceptent le trafic audessus de la couche IPSec peuvent imposer la direction des connexions. Certains parefeu pour hôte interceptent le trafic sous la couche IPSec. Une fois que la communication IPSec est établie, le trafic protégé par IPSec sera vraisemblablement autorisé dans les deux directions pendant une certaine durée. Le filtrage avec état par un routeur réseau ou un parefeu peut également bloquer les actions IKE de recomposition ou le flux du trafic IPSec sans influencer les autres protocoles de diagnostic comme le protocole ICMP. Il est possible que les ports TCP et UDP ne soient pas accessibles sur un ordinateur parce qu'un service n'est pas exécuté ou parce qu'un périphérique qui fonctionne audessus de la couche IPSec (un parefeu Windows ou un routeur réseau, par exemple) bloque l'accès.
178
Suivis des réseaux et dépannage avancé du chemin d'accès au réseau Les échecs de la négociation IKE entraînent souvent l'interruption de réponse à la négociation IKE de la part de l'ordinateur qui subit l'échec ou, dans certains cas, entraînent le renvoi du dernier message de bon fonctionnement jusqu'à ce que la limite de nouvelles tentatives expire. IKE doit être capable d'envoyer des datagrammes UDP fragmentés contenant les tickets Kerberos, car ces paquets dépassent souvent l'unité maximale de transfert d'un chemin (path maximum transmission unit, PMTU) pour l'adresse IP de destination. Si la fragmentation n'est pas correctement prise en charge, de tels fragments peuvent être abandonnés par les périphériques réseau dans un chemin donné. En outre, il est possible que le réseau ne transmette pas les paquets du protocole IPSec ou les fragments des paquets IPSec correctement. L'intégration d'IPSec à TCP permet à TCP de réduire la taille des paquets afin de recevoir la surcharge des entêtes IPSec. Cependant, la négociation TCP de la taille maximale du segment (maximum segment size, MSS) lors de la liaison TCP ne prend pas en compte la surcharge IPSec. D'où le besoin croissant de recherche de l'unité PMTU ICMP sur le réseau afin de garantir que les communications TCP réussies sont protégées par IPSec. Ainsi, le dépannage des échecs de connectivité peut nécessiter les suivis des réseaux des deux côtés de la communication ou d'un seul, ainsi que les fichiers journaux des deux côtés de la communication. Les ingénieurs du support technique doivent savoir lire les fichiers du suivi réseau et comprendre la négociation IKE. Les serveurs doivent être équipés du logiciel Moniteur réseau de Windows. Le Moniteur réseau de Windows 2000 permet l'analyse d'IPSec AH et d'IKE. Windows Server 2003 ajoute la prise en charge de l'analyse IPSec ESP null, l'analyse d'ESP lorsque le chiffrement est déchargé et l'analyse de l'encapsulation UDPESP utilisée pour NAT traversal.
Jeu d'outils de dépannage Avant de commencer les opérations de dépannage, il est important d'identifier les utilitaires capables de fournir des informations en vue de faciliter le processus de dépannage. Cette section ne vise pas à dupliquer les informations disponibles dans l'aide de Windows 2000, Windows XP ou Windows Server 2003 accessible via la page Troubleshooting tools (Outils de dépannage) du site Web de Microsoft Windows Server™ 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/enus/ sag_IPSec_tools.asp. Les informations détaillées sur les outils sont uniquement fournies dans cette section pour le cas où elles ne seraient pas facilement accessibles dans la page Troubleshooting tools ou lorsqu'il est utile de disposer de résumés sur les différentes versions des systèmes d'exploitation. Composant logiciel enfichable MMC Gestion de stratégie de sécurité IP Le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP permet de créer et de gérer les stratégies IPSec locales ou les stratégies IPSec stockées dans le service d'annuaire Active Directory. Il sert également à modifier la stratégie IPSec sur les ordinateurs distants. Le composant MMC Gestion de stratégie de sécurité IP est inclus dans les systèmes d'exploitation Windows Server 2003, Windows XP, Windows 2000 Server et Windows 2000 Édition Professionnel, et il peut être utilisé pour afficher et modifier les détails de la stratégie IPSec, les filtres, les listes de filtres et les actions de filtrage IPSec, ainsi que pour attribuer ou supprimer l'attribution de stratégies IPSec. Composant logiciel enfichable MMC Moniteur de sécurité IP Le composant MMC Moniteur de sécurité IP affiche les statistiques IPSec et les associations de sécurité actives. Il permet également d'afficher des informations sur les composants IPSec suivants :
179
• le mode principal et le mode rapide IKE ; • les stratégies IPSec locales ou de domaine ; • les filtres IPSec qui s'appliquent à l'ordinateur. Bien que ce composant logiciel enfichable fasse partie des systèmes d'exploitation Windows XP et Windows Server 2003, il existe des différences dans les fonctionnalités et les interfaces de ces deux versions. En outre, la version Windows Server 2003 possède les fonctions supplémentaires suivantes :
• Windows Server 2003 propose des détails sur la stratégie IPSec active : nom, description, date de dernière modification, emplacement, chemin, UO et nom d'objet de stratégie de groupe. Pour obtenir ces informations sous Windows XP, vous devez utiliser l'utilitaire de ligne de commande IPSeccmd (décrit ultérieurement).
• Des statistiques sont fournies séparément pour le mode principal et le mode rapide dans des dossiers situés sous chaque mode, et non dans un seul affichage.
Remarque : sous Windows 2000, l'outil Moniteur de sécurité IP est un programme exécutable indépendant (IPSecmon.exe) disposant de sa propre interface graphique utilisateur. Vous trouverez des informations sur cet outil et son utilisation dans l'article 257225 Basic IPSec troubleshooting in Microsoft Windows 2000 Server (Résolution élémentaire des problèmes liés à IPSec sous Windows 2000) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/kb/257225. Une mise à jour de ce composant logiciel enfichable est disponible pour Windows XP en tant que partie de la mise à jour décrite dans l'article 818043 L2TP/IPSec NATT update for Windows XP and Windows 2000 (Mise à jour NATT pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/? kbid=818043. Grâce à cette mise à jour, il est possible d'afficher les ordinateurs Windows Server 2003 à partir de Windows XP. Le composant logiciel enfichable MMC Moniteur de sécurité IP mis à jour peut également lire les fonctions avancées créées sous Windows Server 2003 (par exemple, les informations sur le groupe 2048 DiffieHellman, les mappages de certificats et les filtres dynamiques), mais il ne peut pas les modifier. Pour plus d’informations, reportezvous à l’article de la Base de connaissances référencé. Netsh Netsh est un utilitaire de script de ligne de commande qui vous permet d'afficher ou de modifier la configuration réseau. Vous pouvez l'utiliser localement ou à distance. Netsh est disponible sous Windows 2000, Windows XP et Windows Server 2003. De plus, la version Windows Server 2003 a été améliorée afin de fournir des fonctions de gestion et de diagnostic IPSec. Les commandes Netsh pour IPSec sont uniquement disponibles pour Windows Server 2003 ; elles remplacent les commandes Ipseccmd de Windows XP et Netdiag de Windows 2000. Ipseccmd Vous pouvez utiliser l'utilitaire de ligne de commande Ipseccmd à la place du composant logiciel enfichable MMC Stratégie de sécurité IP. Il est uniquement disponible pour Windows XP. Windows XP Service Pack 2 fournit des fonctionnalités supplémentaires pour cet outil. Ipseccmd doit être installé à partir du dossier Outils de support du CD d'installation de Windows XP. Une version mise à jour est disponible avec Windows XP SP2 et doit être installée à partir du dossier Outils de support du CD d'installation de Windows XP SP2. La version précédant la version SP2 ne
180
fonctionne pas sur les ordinateurs mis à jour, et la version mise à jour ne fonctionne pas sur les ordinateurs antérieurs à SP2. L'utilitaire Ipseccmd mis à jour est doté des fonctionnalités suivantes :
• il active et désactive la journalisation d'IKE de façon dynamique ; • il affiche des informations sur une stratégie actuellement attribuée ; • il vous permet de créer une stratégie IPSec de longue durée ; • il peut afficher la stratégie IPSec actuellement attribuée et active. Pour plus d'informations sur l'utilitaire Ipseccmd mis à jour, reportezvous à l'article 818043 (cité plus haut) de la Base de connaissances Microsoft. Pour afficher tous les paramètres de la stratégie IPSec et les statistiques de diagnostic, utilisez la syntaxe suivante : ipseccmd show all Pour afficher les stratégies IPSec actuellement attribuées et actives (locales ou placées dans Active Directory), utilisez la syntaxe suivante : ipseccmd show gpo Remarque : cette commande fonctionne uniquement avec la version SP2. Pour activer la journalisation du débogage sur Windows XP SP2, utilisez la syntaxe suivante : ipseccmd set logike (le redémarrage du service IPSec n'est pas requis) Pour désactiver la journalisation du débogage, utilisez la syntaxe suivante : ipseccmd set dontlogike (le redémarrage du service IPSec n'est pas requis) Remarque : seul Ipseccmd vous permet d'activer la journalisation Oakley sous Windows XP SP2 ; les commandes cidessus ne fonctionnent pas sur des ordinateurs antérieurs à la version SP2. Netdiag Netdiag est un utilitaire de ligne de commande d'exécution de diagnostics utilisé pour tester la connectivité et la configuration réseau, y compris les informations IPSec. Netdiag est disponible avec Windows 2000, Windows XP et Windows Server 2003, mais sa fonctionnalité change en fonction de la version du système d'exploitation. Sous Windows Server 2003, Netdiag n'inclut plus la fonctionnalité IPSec, mais vous pouvez utiliser le contexte netsh ipsec à la place et utiliser Netsh pour les tests réseau de base. Vous devez vous assurer que vous utilisez la version la plus récente de votre système d'exploitation en procédant à une vérification via le Centre de téléchargement Microsoft. Netdiag doit être installé à partir du dossier Outils de support du CD du système d'exploitation utilisé. Remarque : Netdiag n'est pas mis à jour lors de l'installation de Windows XP SP2. La pertinence du dépannage d'IPSec par Netdiag dépend de la version du système d'exploitation. Les différences en termes de fonctionnalités sont décrites dans le tableau suivant.
181
Tableau 7.1: Fonctionnalité Netdiag IPSec sous différents systèmes d'exploitation Commande
Description
Windows2000 ?
WindowsXP ?
Windows2003 ?
netdiag /test:ipsec
Affiche la stratégie IPSec attribuée
Oui
Oui
Non**
netdiag /test:ipsec /debug
Affiche la stratégie IPSec active, les filtres et les statistiques du mode rapide
Oui
Oui*
Non**
netdiag /test:ipsec /v
Affiche la stratégie IPSec active, les filtres et les statistiques du mode principal
Oui
Oui*
Non**
* Fournit des diagnostics réseau, mais affiche le nom de la stratégie IPSec uniquement. L'utilisation d'Ipseccmd permet d'obtenir des informations IPSec supplémentaires. ** Fournit des diagnostics réseau, mais n'affiche aucune information IPSec. Vous devez utiliser la syntaxe suivante : netsh ipsec dynamic show all. Autres outils utiles à la prise en charge d'IPSec En plus des outils spécifiques à IPSec cités précédemment, le tableau cidessous répertorie d'autres outils qui peuvent se révéler utiles et qui doivent être inclus à votre jeu d'outils de dépannage de niveau 2.
Tableau 7.2 : Outils divers permettant le dépannage d'IPSec Outil
Systèmes d'exploitation pris en charge
Obtention
Rôle
Informations complémentaires
Ipsecpol.exe
Windows 2000 uniquement
Kit de ressources de Windows 2000
Configure les stratégies IPSec dans l'annuaire ou un registre
Aide contenue dans les outils du kit de ressources de Windows 2000
Gpresult
Windows 2000, Windows Server 2003, Windows XP
Kit de ressources Windows 2000 ; pour Windows XP et Windows Server 2003, Gpresult fait partie du système d'exploitation
Indique quand la stratégie de groupe a été appliquée pour la dernière fois
Aide contenue dans les outils du kit de ressources de Windows 2000, Aide de Windows XP et de Windows Server 20 03
Composant logiciel
Windows
Inclus dans le
Affiche la stratégie
Windows
182
enfichable MMC Jeu de stratégie résultant (Resultant Set of Policy, RSoP)
Server 2003, Windows XP
système d'exploitation
IPSec d'un ordinateur ou des membres d'un conteneur de stratégie de groupe
Server 2003
Srvinfo
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows 2000 et Windows Server 2003
Fournit des informations sur les services, pilotes de périphériques et protocoles
Aide contenue dans les outils du kit de ressources de Windows Server 2003
PortQry
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows Server 2003
Génère des rapports sur l'état des ports réseau
http://support.micro soft.com/kb/310099
NLTest
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Outils de support
Teste les relations d'approbation et les canaux Netlogon sécurisés
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Klist
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Windows 2000 et Windows Server 2003
Génère des rapports sur les tickets Kerberos
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Pathping
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Inclus dans le système d'exploitation
Teste les chemins d'accès et la connectivité réseau
Aide de Windows
LDP
Kits de ressources Windows 2000, Windows Server 2003, Windows XP
Outils de support
Teste le client LDAP pour Active Directory
Aide contenue dans les outils du kit de ressources de Windows Server 2003
Utilisation d'outils ICMP avec IPSec Les outils Ping, Pathping et Tracert de Windows XP et de Windows Server 2003 reconnaissent IPSec, mais ils peuvent ne pas fonctionner correctement tant que des associations de sécurité n'ont pas été établies (si la communication en texte clair est autorisée). Si des associations de sécurité IPSec étaient négociées avec succès pour encapsuler le trafic ICMP utilisé par ces utilitaires, elles ne seraient pas en mesure de détecter des sauts (routeur) intermédiaires entre le client et la destination. Les calculs relatifs à la perte de paquets concernant l'outil Ping peuvent indiquer les paquets perdus pendant la durée requise par IKE pour négocier avec succès une association de sécurité IPSec avec la cible. Les calculs sur la perte de paquets pour chaque saut intermédiaire ne sont pas disponibles lorsque le trafic ICMP est encapsulé par IPSec. Ces utilitaires ICMP sont conçus pour détecter si le pilote IPSec correspondait à un filtre IPSec pour le paquet de demande d'écho ICMP sortant et nécessitait ainsi une négociation de sécurité IKE. Lorsque cela se produit, le message « Négociation de la sécurité IP » est affiché par l'utilitaire. Un bogue
183
connu de Windows 2000 empêche l'utilitaire Ping d'attendre autant que nécessaire avant de tenter une nouvelle demande d'écho, ce qui signifie que la commande peut s'achever immédiatement au lieu d'attendre trois secondes pour que la SA logicielle soit établie. L'utilitaire Ping de Windows XP et de Windows Server 2003 attend le temps nécessaire avant d'envoyer la demande d'écho suivante. Le message « Négociation de la sécurité IP » ne s'affiche pas lorsque :
• le pilote IPSec abandonne le paquet ICMP sortant en raison d'un filtre bloquant ; • le pilote IPSec autorise le transfert du paquet ICMP non sécurisé en raison d'un filtre d'autorisation ou d'une SA logicielle ;
• le pilote IPSec ne détecte pas le paquet sortant (par exemple, s'il a été abandonné par les couches situées audessus du pilote).
Remarque : certains outils utilisant ICMP ne sont pas capables de détecter qu'IPSec négocie la sécurité et peuvent produire des résultats incohérents ou erronés.
Processus de dépannage d'IPSec Si le support de niveau 1 a clairement identifié un problème, le support de niveau 2 sera en mesure de trouver rapidement la procédure de dépannage appropriée dans les sections suivantes. Dans ce modèle, le support de niveau 1 traite principalement les problèmes d'accès du client. En général, les propriétaires administratifs de serveurs sont capables d'effectuer des diagnostics de connectivité réseau de base et peuvent ignorer le niveau 1. Cependant, chaque entreprise doit ajuster le modèle en fonction de son environnement de support. Le support de niveau 2 doit se concentrer sur l'identification du point d'échec de la communication, puis rechercher des causes associées dans l'architecture du système. Si votre entreprise utilise les scripts fournis dans le cadre du processus de dépannage, vous aurez accès à un certain nombre de fichiers journaux au format texte qui vous aideront à diagnostiquer le problème. Le tableau suivant présente la description des fichiers générés par le script. Tableau 7.3 : Fichiers générés par le script IPSec_Debug.vbs Nom de fichier
Description
Liste des versions de fichier de plusieurs DLL associées à IPSec.
Résultat de la commande gpresult.
Affiche le résultat de n'importe quelle erreur IPSEC 547 dans le journal des événements de sécurité.
Résultat du script Detect_IPSec_Policy.vbs. Affiche la version de la stratégie actuelle et indique si elle correspond à la stratégie Active Directory.
Uniquement pour Windows XP. Ce fichier capture le résultat de la commande ipseccmd.
Affiche le résultat de n'importe quel événement Kerberos dans le journal des événements système.
Résultat de KList lors de la purge des tickets d'ordinateur.
184
Copie du fichier lsass.log, s'il est présent.
Résultat de l'exécution de netdiag.
Uniquement sur les platesformes serveur. Résultat de l'exécution de la commande show all dans netsh.
Uniquement sur les platesformes serveur. Résultat de l'exécution de la commande show gpo dans netsh.
Copie du fichier Oakley.log, s'il est présent.
Sortie des informations du système d'exploitation actuel.
Résultat des valeurs de la clé de registre d'origine avant leur modification. Peut être utilisé pour rétablir manuellement les valeurs précédentes du registre si le script échoue.
Copie du fichier userenv.log, s'il est présent.
Résultat de l'exécution de la commande net view sur
Résultat de l'exécution de la commande ping sur
Copie du fichier winlogon.log, s'il est présent.
Étant donné qu'il existe plusieurs points d'échec potentiels, cette section traite chaque composant architectural dans l'ordre, à commencer par la connectivité réseau. Les procédures définies vous aideront à effectuer les tâches suivantes :
• vérifier la configuration du réseau IP, la connectivité réseau et le service avec les contrôleurs de domaine ainsi que la connectivité du chemin client/serveur pour les protocoles liés à IPSec ;
• vérifier que les stratégies de groupe et IPSec sont correctement appliquées sur le client et le serveur ;
• identifier les problèmes liés à la négociation IKE et à la communication protégée par IPSec ; • identifier la cause d'un problème en vue du transfert vers le support de niveau 3, si nécessaire. Prenons l'exemple suivant : un client indique qu'il est capable d'exécuter une commande ping sur un serveur mais qu'il ne peut pas se connecter à un partage de fichiers sur ce serveur. Il s'agit du seul serveur auquel le client ne peut pas accéder. Une recherche rapide dans le journal de sécurité de l'événement 547 (échec de la négociation IKE) contenant l'adresse IP du serveur indique que le client a une stratégie IPSec et qu'IKE est en cours d'initialisation. Si l'événement 547 indique que le délai de négociation IKE du client a expiré, cela signifie que la négociation IKE du serveur a certainement échoué. Le support de niveau 2 doit alors effectuer des recherches dans la base de données d'événements MOM relatives aux événements 547 collectés à partir du serveur spécifié, lesquels contiennent l'adresse IP du client actuel.
Avertissement Démarrage et arrêt du service IPSec Le document Windows Server 2003 TCP/IP Troubleshooting (Dépannage de TCP/IP sous Windows Server 2003) ainsi que les autres références expliquent comment savoir si IPSec est responsable d'un problème de connectivité en arrêtant le service IPSec. Cet arrêt interrompt le filtrage IPSec sur l'ordinateur, désactive la protection fournie par IPSec, expose l'ordinateur à un accès réseau non approuvé et désactive la protection des paquets. En outre, dans un environnement
185
d'isolation de domaines, le trafic TCP et UDP non protégé par IPSec sera abandonné par les autres membres du domaine. Si IPSec est désactivé sur un ordinateur, cela entraînera des interruptions de connectivité avec les ordinateurs distants disposant actuellement d'associations de sécurité IPSec. Lorsque le service IPSec est interrompu, IKE envoie des notifications de suppression pour toutes les associations de sécurité IPSec et pour l'association de sécurité IKE à tous les ordinateurs connectés. Les ordinateurs distants disposant d'une stratégie IPSec autorisant les communications en texte clair rétablissent la connectivité après un délai de trois secondes. Les ordinateurs distants disposant d'une stratégie IPSec n'autorisant pas les communications en texte clair ne seront pas en mesure de communiquer. C'est pourquoi il est important d'utiliser les techniques citées dans les sections suivantes pour résoudre les problèmes d'isolation sans interrompre le service IPSec. Le service IPSec doit être désactivé uniquement en dernier recours pour éliminer les problèmes liés à IPSec dans les situations suivantes :
• environnements de trafic de diffusion et de multidiffusion ; • connexions à des ordinateurs distants ne nécessitant pas IPSec pour un accès entrant (par exemple, les ordinateurs membres de la liste d'exemption).
Sous Windows 2000, l'arrêt du service IPSec dissocie le pilote IPSec de TCP/IP et décharge le pilote IPSec de la mémoire. Sous Windows XP et Windows Server 2003, l'arrêt du service IPSec supprime tous les filtres du pilote IPSec et définit le mode du pilote sur AUTORISER. Le pilote IPSec n'est pas déchargé de la mémoire. Pour éviter le chargement du pilote IPSec, il faut que le service IPSec soit désactivé et que l'ordinateur ait redémarré. Sous Windows 2000 et Windows XP SP1, la journalisation d'IKE dans le fichier Oakley.log requiert le redémarrage du service IPSec. L'arrêt du service n'est pas nécessaire pour activer et désactiver la journalisation d'IKE dans le fichier Oakley.log sous Windows XP SP2 et Windows Server 2003. La toute dernière mise à jour d'Ipseccmd pour Windows XP SP2 propose la syntaxe ipseccmd set logike et ipseccmd set dontlogike qui permettent d'activer/désactiver la journalisation d'IKE dans le fichier Oakley.log. La journalisation d'IKE sous Windows Server 2003 peut être activée dynamiquement par l'utilisation des commandes Netsh décrites dans l'aide en ligne.
Vérification de la connectivité réseau Si le support de niveau 1 identifie d'éventuels problèmes de connectivité réseau, alors la première étape consiste à déterminer si une connectivité réseau de base existe. Pour ce faire, vous devez vérifier que la configuration IP appropriée est utilisée, que le chemin réseau entre l'ordinateur initiateur et l'ordinateur répondant est valide et que les services de résolution de noms fonctionnent. Problèmes de configuration de l'adresse IP du réseau Si la configuration IP dynamique n'a pas réussi ou si les communications sont bloquées après le redémarrage de l'ordinateur (ou dans des conditions normales d'utilisation), le problème peut être dû à IPSec. Sous Windows Server 2003, ce type de problème peut être lié au comportement à tolérance de pannes d'IPSec (par exemple, si l'ordinateur est démarré en mode sans échec ou en mode de récupération Active Directory). Remarque : pour obtenir des détails sur le comportement à tolérance de pannes de Windows Server 2003, reportezvous à la section Understanding IPSec Protection During Computer Startup (Comprendre la protection IPSec au démarrage de l'ordinateur) du module Deploying
186
IPSec (Déploiement d'IPSec) du kit de déploiement de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en us/dnsbj_ips.asp. Windows Server 2003 a recours au comportement à tolérance de pannes si le service IPSec ne peut pas démarrer correctement ou s'il ne peut pas appliquer la stratégie attribuée. Le comportement à tolérance de pannes s'applique uniquement lorsqu'une stratégie IPSec est attribuée à l'ordinateur et que le service IPSec n'est pas désactivé. Cela signifie que la connectivité vers ou à partir d'un ordinateur pourrait échouer dans des conditions normales car le pilote IPSec n'applique pas la stratégie IPSec basée sur domaine. Une fois que vous avez déterminé quel trafic est autorisé et bloqué par le mode d'amorçage et les configurations persistantes, un échec de communication peut être facile à expliquer. Pour obtenir d'autres informations ou des informations complémentaires, vous pouvez interroger l'état actuel à partir de la ligne de commande à l'aide de la syntaxe suivante : netsh ipsec dynamic show config Sous Windows Server 2003, le pilote IPSec est chargé au démarrage de l'ordinateur avec le pilote TCP/IP. Par conséquent, pour supprimer le comportement à tolérance de pannes du pilote IPSec, vous devez désactiver le service IPSec et redémarrer l'ordinateur. Le chapitre cité plus haut qui est consacré au déploiement d'IPSec présente la configuration recommandée des exemptions d'amorçage afin d'exempter les connexions RDP (Remote Desktop Protocol, protocole bureau distant) entrantes, ce qui permet de garantir que l'accès distant au serveur est disponible lorsque tout autre trafic est bloqué. Dans une solution d'isolation de serveurs et de domaines, le trafic de diffusion et le trafic vers les serveurs DHCP est exempt pour garantir que la configuration IP dynamique fonctionne correctement. Cependant, la liste d'exemption doit être mise à jour manuellement et peut devenir obsolète. Si un ordinateur ne peut pas obtenir de configuration DHCP correcte (par exemple, s'il utilise une adresse IP de configuration automatique 169.254.x.x) ou s'il rencontre des problèmes de renouvellement de bail, vous devez alors étudier la stratégie IPSec pour déterminer les exemptions appropriées. Lorsque le service IPSec est en cours d'exécution, utilisez la commande Ipconfig pour confirmer qu'il n'y a aucun problème d'obtention d'adresse :
• Pour les clients DHCP, ouvrez une fenêtre de commande et tapez ipconfig /release suivi de ipconfig /renew.
Si les problèmes de configuration d'adresses se produisent uniquement au démarrage de l'ordinateur sous Windows XP SP2 et Windows Server 2003, la configuration des exemptions (exemptions par défaut et exemptions d'amorçage par défaut) doit être examinée. Problèmes de résolution de noms La conception de stratégie IPSec utilisée dans les scénarios d'isolation de serveurs et de domaines ne doit pas interférer avec les procédures types utilisées pour déterminer si la résolution de noms fonctionne. Par exemple, dans le scénario Woodgrove Bank, la conception de stratégie IPSec exempt tout le trafic vers les serveurs DNS et WINS. Toutefois, il est possible que les serveurs DNS et WINS soient configurés pour ne pas répondre aux requêtes Ping. Répondez aux questions suivantes pour confirmer que la résolution de noms fonctionne correctement lorsque le service IPSec est en cours d'exécution :
• Le client peutil envoyer une requête ping à l'adresse IP du serveur DNS indiquée dans sa configuration IP ?
• La commande nslookup permetelle de trouver un serveur DNS ?
187
• Le client peutil envoyer une requête ping au nom DNS complet de l'ordinateur cible ? • Le client peutil envoyer une requête ping au nom DNS ou NetBIOS abrégé de l'ordinateur cible ? À l'origine des problèmes potentiels de résolution de noms figurent la configuration incorrecte et l'activation du fichier HOSTS, la configuration incorrecte de l'entrée du serveur DNS dans les propriétés IP, des enregistrements DNS incorrects, des problèmes de mise à jour des fichiers de zone, des problèmes de réplication Active Directory, la communication en texte clair utilisée pour les serveurs DNS et des problèmes de mise à jour automatique de DHCP. Les raisons possibles des échecs de la résolution de noms NetBIOS sont la configuration incorrecte et l'activation du fichier LMHOSTS, la configuration incorrecte de l'entrée du serveur WINS dans les propriétés IP, l'indisponibilité du serveur WINS, l'enregistrement WINS incorrect, des problèmes de réplication WINS, des échecs du proxy WINS et des délais d'expiration réseau pour le serveur WINS. Pour consulter des procédures d'aide au dépannage du DNS intégré à Active Directory, reportezvous à la page Troubleshooting Active Directory Related DNS Problems (Dépannage d'Active Directory Problèmes DNS connexes) sur le site de Microsoft.com à l'adresse www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsg uide/part1/adogd10.mspx. Certains environnements exigeant une sécurité élevée peuvent nécessiter la protection des serveurs DNS et WINS par IPSec, ce qui peut entraîner des problèmes de résolution de noms. Par exemple, si le DNS est intégré à Active Directory et s'il existe des filtres dupliqués pour la même adresse IP dans la stratégie IPSec, un filtre peut négocier la sécurité pour le serveur DNS et l'autre exempter les contrôleurs de domaine. Pour plus d'informations, reportezvous à la section Dépannage de la stratégie IPSec plus loin dans ce chapitre. Si le problème de résolution de noms persiste, vous pouvez obtenir la liste des filtres de l'initiateur et vérifier s'il existe des filtres dupliqués. Vous pouvez utiliser les options de ligne de commande suivantes pour afficher les listes de filtres pour cette tâche : Ipseccmd show filters Netsh ipsec static show all Si le problème de résolution de noms persiste, arrêtez brièvement le service IPSec (si possible) lorsque les tests sur la résolution de noms sont répétés. Si les tests de résolution de noms échouent uniquement lorsque le service IPSec est en cours d'exécution, vous devez continuer vos recherches pour savoir quelle stratégie IPSec est appliquée (voir les explications plus loin dans cette section). Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine Étant donné que la transmission de la stratégie IPSec, l'authentification IKE et les protocoles de niveau supérieur dépendent de l'accès aux contrôleurs de domaine, des tests de connectivité réseau et de bon fonctionnement des services d'authentification doivent être réalisés avant les étapes de dépannage d'IPSec spécifiques (voir la section suivante). Dans le scénario Woodgrove Bank, la conception de la stratégie IPSec exempt tout le trafic vers tous les contrôleurs de domaine ; les tests de connectivité réseau pour les contrôleurs de domaine ne devraient donc pas être affectés par IPSec. Toutefois, la liste des adresses IP du contrôleur de domaine de la liste d'exemption doit être mise à jour manuellement. Si la négociation IKE est visible pour une adresse IP de contrôleur de domaine, alors la stratégie IPSec peut ne pas être correctement attribuée ou ne pas être mise à jour. Pour dépanner l'accès aux services réseau dans Active Directory
188
• Assurezvous que le client peut envoyer une requête ping à chaque adresse IP du contrôleur de domaine. Si ce n'est pas le cas, reportezvous aux étapes de connectivité réseau cidessus.
• Identifiez les adresses IP utilisées pour les contrôleurs du membre du domaine. Utilisez la
commande nslookup <nom domaine> pour obtenir la liste complète des adresses IP. Un scénario d'isolation de serveurs et de domaines doit prévoir un filtre spécifique au mode rapide avec une stratégie de négociation (action de filtrage) autoriser pour chacune de ces adresses.
• Utilisez l'outil portqry.exe version 2.0 ou ultérieure ou l'outil PortQueryUI pour tester l'accès aux
ports UDP, LDAP et RPC du contrôleur de domaine. Les messages du protocole UDP utilisés par l'outil portqry ne requièrent généralement pas l'authentification du protocole de niveau supérieur ; ils peuvent donc vérifier la disponibilité du service même si l'authentification n'est pas disponible. Ces étapes sont expliquées à la page HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues (COMMENT FAIRE : Utilisation du Portqry pour la résolution des problèmes de connectivité de Active Directory) , disponible à l'adresse http://support.microsoft.com/? kbid=816103.
• Lorsque vous êtes connecté au réseau interne, utilisez la commande netdiag /v >outputfile.txt pour
effectuer divers tests de connectivité liés à DNS et au contrôleur de domaine. L'utilitaire Netdiag utilise plusieurs connexions réseau et protocoles pour réaliser les tests ; si l'une de ces connexions déclenche des négociations IKE et que l'authentification échoue parce que IKE ne réussit pas à localiser un contrôleur de domaine pour l'authentification IKE, l'erreur de l'événement 547 peut être consignée dans le journal de sécurité.
L'outil de support klist.exe de Windows peut être utilisé pour vérifier que la connexion et l'authentification Kerberos ont réussi. L'outil Klist doit être exécuté dans le contexte du système local pour que vous puissiez afficher les tickets Kerberos de l'ordinateur. Pour afficher les tickets de service Kerberos pour l'utilisateur de domaine connecté
• Ouvrez une invite de commande et tapez ce qui suit : klist tickets Pour afficher les tickets de l'ordinateur du domaine
1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.
2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit : at 4:38pm /interactive cmd /k klist tickets Notez que la barre de titre de la fenêtre de commande contient C:\Windows\System32\svchost.exe. Bien que les tickets Kerberos contiennent des informations sur le groupe de l'utilisateur ou de l'ordinateur, ces informations sont chiffrées afin qu'il soit impossible d'afficher les groupes. Par conséquent, les appartenances aux groupes doivent être confirmées manuellement par l'inspection des appartenances de groupe dans le service Active Directory. Pour vous assurer que les ordinateurs possèdent les informations d'appartenance aux groupes les plus récentes sur leurs tickets Kerberos, utilisez klist afin de purger les tickets Kerberos actuels. Lors de la nouvelle tentative de négociation IKE, les nouveaux tickets Kerberos seront obtenus automatiquement. Pour purger les tickets Kerberos d'un ordinateur (Les étapes 1 à 4 doivent être réalisées dans le contexte d'un système local.)
189
1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.
2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit : at 4:38pm /interactive cmd
3. Tapez klist purge et appuyez sur O pour chaque type de ticket afin de supprimer tous les tickets Kerberos.
4. Tapez klist tickets pour confirmer qu'il n'existe aucun ticket. 5. Si cette procédure fait partie du dépannage de l'échec des négociations IKE, attendez une minute pour que le délai de négociation IKE soit écoulé puis reéssayez d'accéder au serveur cible avec l'application. Les nouvelles négociations IKE en mode principal nécessitent de nouveaux tickets d'attribution de tickets (ticketgranting ticket, TGT) Kerberos et des tickets de service pour l'ordinateur de destination, lequel disposera des informations les plus récentes sur les groupes. Veillez à ne pas exécuter l'application à partir de la fenêtre de commande exécutée dans le contexte du système local. Vous trouverez des procédures détaillées supplémentaires sur le dépannage de Kerberos dans les Livres blancs suivants : •Troubleshooting Kerberos Errors (Dépannage des erreurs Kerberos) à l'adresse www.microsoft.com/downloads/details.aspx? FamilyID=7dfeb015604347db8238dc7af89c93f1&displaylang=en •Troubleshooting Kerberos Delegation (Dépannage de la délégation Kerberos) à l'adresse www.microsoft.com/downloads/details.aspx? FamilyID=99b0f94fe28a4726bffe2f64ae2f59a2&displaylang=en
Vérification des autorisations et de l'intégrité de la stratégie IPSec dans Active Directory Il peut s'avérer nécessaire de vérifier les informations relatives au conteneur de la stratégie IPSec dans le service Active Directory. La procédure suivante utilise l'outil de support ldp.exe. Pour vérifier les informations sur le conteneur de la stratégie IPSec
1. Cliquez sur Démarrer, Exécuter, tapez ldp.exe et appuyez sur ENTRÉE. 2. Sélectionnez Connexion, puis Connecter. Indiquez le nom du domaine cible. 3. Sélectionnez Connexion, puis Liaison. Indiquez les informations de connexion pour le domaine cible.
4. Sélectionnez Afficher, puis Arborescence. Vous pouvez soit n'indiquer aucun nom de domaine de base et rechercher le conteneur de la stratégie IPSec, soit spécifier le nom du domaine LDAP pour le conteneur de la stratégie IPSec comme emplacement de base.
5. Cliquez sur le symbole + en regard du nœud du conteneur dans l'arborescence. Si vous possédez des autorisations en lecture sur le conteneur, tous les objets de la stratégie IPSec qu'il contient s'affichent. Remarque : selon la configuration des autorisations, il est possible que certains utilisateurs de domaine ne disposent pas des autorisations en lecture. Pour plus d'informations, reportezvous à l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003 (Autorisations de stratégie IPSec dans Windows 2000 et Windows Server 2003) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=329194. 190
Pour effectuer un dépannage avancé des problèmes d'extraction et de corruption de la stratégie, vous pouvez utiliser ldp.exe pour inspecter manuellement le contenu du conteneur IPSec et les relations existant entre les objets de la stratégie IPSec. Windows 2000, Windows XP et Windows Server 2003 utilisent le même schéma d'annuaire de base pour la stratégie IPSec, affiché dans le diagramme de la structure de la stratégie IPSec de la référence technique How IPSec Works (Fonctionnement d'IPSec) de Windows Server 2003 disponible à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_ipsec_how.asp. Le tableau suivant décrit les relations existant entre le nom de l'objet Active Directory et le nom du composant de la stratégie IPSec configuré dans le composant logiciel enfichable MMC Gestion de stratégie IPSec : Tableau 7.4 : Association entre le nom du composant de la stratégie IPSec et le nom de l'objet Active Directory Nom du composant de la stratégie IPSec
Nom de l'objet Active Directory
Stratégie de sécurité IP
ipsecPolicy{GUID}
Méthodes de sécurité Échange de clés IKE
ipsecISAKMPPolicy{GUID}
Règle IPSec
ipsecNFA{GUID}
Liste de filtres IPSec
ipsecFilter{GUID}
Action de filtrage IPSec
ipsecNegotiationPolicy{GUID}
L'utilitaire Ldp.exe permet de savoir à quel moment les objets de la stratégie IPSec ont été modifiés pour la dernière fois, ce qui peut aider à résoudre les problèmes de version d'objet et de réplication. Vous pouvez le lancer depuis une fenêtre de commande dans le contexte du système local afin de résoudre les problèmes d'autorisation en lecture du service IPSec. Attention : il est fortement recommandé d'attribuer les mêmes permissions à tous les objets du conteneur de sécurité IP. Microsoft vous déconseille d'attribuer des autorisations aux objets de la stratégie IPSec sur une base individuelle. Pour contrôler l'accès en lecture et en modification de la stratégie IPSec, il est nécessaire de gérer les autorisations dans le conteneur IPSec, comme l'explique l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003 de la Base de connaissances à l'adresse http://support.microsoft.com/?kbid=329194. La corruption de la stratégie de sécurité IP est la cause la plus courante à l'origine de situations dans lesquelles un objet IPSec contient une référence DN (Domain Name, nom de domaine) à un objet qui n'existe plus. Cependant, la corruption peut également se produire si des caractères de contrôle deviennent partie intégrante du nom d'un objet, si des objets individuels ne peuvent pas être lus en raison de problèmes d'autorisation ou si des noms identiques d'objets entraînent une conception inadéquate de la stratégie IPSec (par exemple, deux versions de la même liste de filtres). Reportez vous à la section suivante sur le dépannage du service IPSec pour plus d'informations sur le dépannage de la corruption de la stratégie IPSec. Remarque : les détails de conception de ces objets sont considérés comme une structure de données interne privée et ne sont pas publiés par Microsoft. Des différences existent au niveau du format de ces objets dans les diverses versions de Windows ; Microsoft est susceptible d'apporter des modifications à ces formats à tout moment. C'est pourquoi ces objets doivent uniquement être gérés à l'aide du composant logiciel enfichable MMC Gestion de stratégie IPSec et des outils de ligne de commande disponibles sur chaque plateforme. Vous ne devez supprimer des objets au moyen de LDP qu'en dernier recours, lorsque la corruption empêche l'utilisation du composant MMC Gestion de stratégie IPSec ou des outils de ligne de commande.
191
Connectivité du chemin réseau Microsoft vous recommande d'exempter le protocole ICMP dans le cadre de solutions d'isolation de serveurs et de domaines. Il existe plusieurs raisons à cette recommandation, notamment la nécessité d'utiliser ICMP pour tester le chemin réseau à l'aide des utilitaires Ping, Pathping et Tracert, par exemple. Ces utilitaires doivent par conséquent fonctionner correctement et ne pas afficher le message « Négociation de la sécurité IP ». Si ce message s'affiche, cela signifie qu'une stratégie IPSec inappropriée a peutêtre été attribuée. Pour déterminer si le problème est lié à une configuration réseau de base ou à la connectivité du chemin
• Le client peutil envoyer une requête ping à sa propre adresse IP ou à l'adresse de boucle
locale 127.0.0.1 ? Si la réponse est non, cela peut signifier qu'il existe un problème de configuration TCP/IP, qu'un parefeu tiers a été installé, que l'utilitaire Ping est manquant ou que la configuration IP n'est pas valide. Utilisez d'autres procédures de dépannage de la configuration TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping à la passerelle par défaut affichée dans sa
configuration IP ? Si la réponse est non, cela peut signifier que la configuration IP du client est inopérante, que l'interface locale n'est pas connectée ou que sa connectivité est limitée, que des filtres réseau ou locaux bloquent le trafic ou que le chemin réseau vers la passerelle par défaut est interrompu. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping aux serveurs DNS affichés dans sa configuration IP ? Si la réponse est non, cela peut signifier que les serveurs DNS ne s'autorisent pas à recevoir des messages de demande d'écho ICMP, que la stratégie IPSec n'exempt pas les adresses IP du serveur DNS appropriées ou que vous êtes en présence de l'un des problèmes mentionnés précédemment. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.
• Le client peutil envoyer une requête ping à une adresse IP de la liste d'exemption, un contrôleur de domaine, par exemple ? Si la réponse est non, cela signifie que le problème n'est pas lié à IPSec ou que IPSec ne possède pas de filtre pour cette adresse IP exemptée. Cette dernière hypothèse peut être confirmée par l'examen de la configuration des filtres. Reportezvous à la section sur la stratégie IPSec plus loin dans ce chapitre.
• Le client peutil envoyer une requête ping à l'adresse IP de la destination cible ? Si la réponse est oui, alors une connectivité réseau de base existe entre le client et la cible sans IPSec. Si la réponse est non, exécutez l'outil tracert sur l'adresse IP de la cible et d'autres adresses IP de destination pour déterminer le degré de validité du réseau. Utilisez d'autres procédures de dépannage du réseau et du protocole TCP/IP pour résoudre le problème.
Les tests de connectivité du chemin réussissent peutêtre pour ICMP, sauf lors de l'utilisation des protocoles IKE ou IPSec. En particulier, la charge d'IPSec pour les paquets d'authentification en mode principal IKE contenant le ticket Kerberos est souvent plus importante que l'unité PMTU pour l'adresse IP de destination, qui requiert une fragmentation. Ainsi, les parefeu pour hôte, le filtrage des routeurs, les parefeu pour réseau et les filtres de l'hôte cible doivent être ouverts aux protocoles et ports suivants et prendre en charge la fragmentation :
• IKE. Port source UDP 500, port de destination 500 et fragments • IKE/IPSec NATT. Port source UDP 4500, port de destination 4500 • IPSec ESP. Protocole IP 50 et fragments
192
• IPSec AH. Protocole IP 51 et fragments Le filtrage avec état du chemin n'est pas recommandé Le filtrage avec état peut entraîner des problèmes de connectivité pour IKE, AH et ESP car l'état est généralement basé sur des délais d'expiration d'activité. Les périphériques ne peuvent pas inspecter le trafic IKE pour savoir quand les associations de sécurité IPSec sont supprimées car ces messages sont chiffrés par IKE. Par définition, IKE est requis pour permettre la recomposition dans l'une ou l'autre direction, ce qui signifie que les messages de suppression peuvent être envoyés dans l'une ou l'autre direction. Si un message de suppression n'est pas reçu par l'une des extrémités, cette dernière risque de penser qu'une association de sécurité IPSec existe toujours alors que son homologue ne la reconnaît plus et rejette les paquets qui l'utilisent. La direction de la recomposition IKE est basée sur la direction du trafic qui utilise la durée de vie basée sur les octets plus rapidement, sur les petits décalages de recomposition lors de l'expiration des durées de vie basées sur le temps et sur la direction du flux des paquets après la suppression des SA IPSec inactives. Le filtrage avec état basé sur l'hôte du trafic IKE sur les clients qui initient les connexions (et donc les négociations IKE) via le parefeu Windows ne provoque généralement pas de problème. Le parefeu Windows ne filtre pas les paquets IPSec, car le pilote IPSec traite les paquets sur une couche inférieure à celle sur laquelle le filtrage du parefeu est réalisé. Cependant, les ports IKE doivent être configurés « ouverts » dans le parefeu hôte afin de recevoir les négociations IKE entrantes pour les connexions de protocole de niveau supérieur autorisées via le parefeu (par exemple, pour le partage de fichiers utilisant le protocole SMB sur le port TCP 445). Prise en charge de l'unité PMTU ICMP requise par le protocole TCP Le paramètre par défaut sous Windows 2000 et les versions ultérieures pour chaque paquet TCP est le bit Ne pas fragmenter défini dans l'entête IP. Ce paramètre est conservé lorsque le mode de transport AH ou ESP IPSec est utilisé pour sécuriser le paquet. Par conséquent, un paquet trop important sera abandonné au niveau du routeur qui renverra un message ICMP destination inaccessible indiquant la taille maximale autorisée. Ce comportement est appelé recherche de l'unité maximale de transfert (MTU) du chemin TCP. L'ordinateur client et l'ordinateur cible doivent être capables de recevoir des messages PMTU ICMP pour les paquets IPSec trop volumineux. Il est important que le trafic protégé par IPSec évite la fragmentation, car l'accélération matérielle ne traite généralement pas les paquets fragmentés. Les paquets IPSec fragmentés doivent être traités par le pilote IPSec du logiciel. Windows 2000 et Windows XP ne prennent pas en charge la recherche PMTU ICMP pour les paquets du mode de transport IPSec qui utilisent l'encapsulation NAT traversal (port UDP 4500). Windows Server 2003 prend en charge ce processus de recherche. Reportezvous à la page Troubleshooting Translational Bridging (Dépannage du pont de conversion) dans la section TCP/IP Troubleshooting (Dépannage TCP/IP) de la documentation en ligne de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/Windows/ 2000/server/reskit/enus/cnet/cnbd_trb_gdhe.asp pour connaître les options et outils qui fonctionnent sans la recherche PMTU. Remarque : il existe un problème connu qui nécessite l'activation de la détection PMTU TCP pour que IPSec sécurise le trafic dans un scénario NAT traversal où les connexions UDPESP d'IPSec sont initiées par un hôte situé à l'extérieur du NAT vers un hôte situé derrière un NAT. Si ce scénario est requis, confirmez que la détection PMTU TCP est activée en vous assurant que la clé de registre suivante n'est pas définie ou qu'elle est définie sur 1 aux deux extrémités : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\EnablePMTUDiscovery=1 (Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.) Le modèle de stratégie de sécurité de base du serveur membre sous Microsoft Windows Server 2003
193
ainsi que les configurations tierces peuvent configurer cette clé de registre pour désactiver PMTU TCP. Prise en charge requise de la fragmentation Les chemins réseau et les filtres doivent prendre en charge la transmission de fragments pour les protocoles IKE, IPSec, AH et ESP. IKE utilise les paquets UDP et leur permet d'être fragmentés selon les besoins. L'implémentation NAT traversal d'IPSec ajoute la prise en charge de l'évitement de la fragmentation IKE uniquement lorsque IKE s'authentifie au moyen de certificats (par exemple, dans des scénarios de réseau privé virtuel L2TP/IPSec). L'authentification IKE qui utilise Kerberos ne prend pas en charge l'évitement de la fragmentation et doit être capable d'envoyer et de recevoir des paquets UDP fragmentés contenant le ticket Kerberos. Le chemin réseau doit prendre en charge la transmission des fragments pour les protocoles AH et ESP car IPSec sécurise le paquet IP d'origine complet avant la fragmentation sortante au niveau de la couche IP. IPSec est intégré à TCP afin que, dans le cas où les paquets TCP sont définis sur Ne pas fragmenter (paramètre par défaut), TCP réduise la taille de ses paquets pour recevoir les octets supplémentaires ajoutés par l'encapsulation d'IPSec. IPSec n'est pas intégré à UDP et les applications UDP ne possèdent aucun moyen de détecter si IPSec protège leur trafic. Par conséquent, lorsque AH ou ESP IPSec est appliqué, les paquets UDP qui utilisent la taille totale de l'unité maximale de transfert sont fragmentés par l'hôte au moment de la transmission. D'une manière similaire, si les filtres de la stratégie IPSec n'exemptent pas ICMP, l'utilisation de l'outil Ping peut générer des paquets ICMP qui apparaissent en tant que paquets AH ou ESP IPSec fragmentés sur le réseau. Pour plus d'informations, reportezvous à l'article 233256 How to Enable IPSec Traffic Through a Firewall (Trafic via un parefeu) de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=233256. Prise en charge requise pour le trafic de diffusion et de multidiffusion La conception de la stratégie IPSec dans le cadre de l'isolation de serveurs et de domaines utilise des filtres N'importe lequel <> Sousréseau. Ainsi, le filtre sortant Sousréseau > N'importe lequel correspondra au trafic de diffusion et de multidiffusion sortant envoyé par les hôtes à l'aide d'une adresse IP de sousréseau interne. Toutefois, étant donné qu'IPSec ne peut pas sécuriser le trafic de diffusion ou de multidiffusion, il doit ignorer ce trafic s'il correspond au filtre. Le trafic de multidiffusion entrant ainsi que la plupart des trafics de diffusion ne correspondent pas au filtre entrant N'importe lequel > Sousréseau. Si le trafic de diffusion et de multidiffusion est requis, vous pouvez définir la clé de registre sur NoDefaultExempt=1, ce qui permet au trafic de diffusion et de multidiffusion d'éviter le filtrage IPSec sous Windows XP et Windows Server 2003. Cette configuration empêche l'apparition de problèmes connus avec les clients RTC (Real Time Communications, communications en temps réel) et le serveur Windows Media, qui utilisent tous deux le trafic de multidiffusion. Pour obtenir des détails sur l'utilisation et les implications en termes de sécurité de la clé de registre NoDefaultExempt, reportezvous aux articles suivants de la Base de connaissances : •810207 IPSec default exemptions are removed in Windows Server 2003 (Les exemptions par défaut IPSec sont supprimées de Windows Server 2003) à l'adresse http://support.microsoft.com/? kbid=810207 • 811832 IPSec Default Exemptions Can Be Used to Bypass IPSec Protection in Some Scenarios (Les exemptions par défaut IPSec vous permettent d'ignorer la protection IPSec dans certains scénarios) à l'adresse http://support.microsoft.com/?kbid=811832
194
Remarque : Windows XP SP2 utilise les mêmes exemptions par défaut que Windows Server 2003. La clé de registre peut être définie pour contrôler les exemptions par défaut sur toutes les plates formes, selon les besoins. Le filtrage IPSec ne prend pas en charge la configuration des adresses de destination de diffusion ou de multidiffusion spécifiques. Les diagnostics des périphériques réseau peuvent être inutiles Avec l'utilisation de l'encapsulation IPSec, les applications qui supposent que le trafic TCP/IP est en texte clair ne peuvent plus inspecter le trafic du réseau. Il est peu probable que les outils de diagnostic réseau qui inspectent ou fournissent des rapports basés sur les ports TCP et UDP soient capables d'interpréter les paquets encapsulés par IPSec, même si le chiffrement AH ou ESP n'est pas utilisé. Des mises à jour de ces outils seront peutêtre requises de la part des fournisseurs pour permettre l'inspection des paquets IPSec AH ou ESPnull. Problèmes de carte d'interface réseau et de pilote La perte de paquets IPSec peut parfois être provoquée par des cartes d'interface réseau (network interface cards, NIC) qui exécutent des fonctions spéciales. Vous devez tester les cartes qui effectuent des mises en cluster ou des regroupements pour savoir si elles sont compatibles avec IPSec. Les pilotes NIC qui accélèrent les fonctions non IPSec risquent de rencontrer des problèmes avec le trafic protégé par IPSec. Les cartes d'interface réseau qui accélèrent les fonctions TCP peuvent prendre en charge le calcul du total de contrôle TCP et la validation (déchargement du total de contrôle), ainsi que la possibilité d'envoyer efficacement des tampons de données TCP volumineux (déchargement d'envoi important). Windows 2000 et les versions ultérieures désactivent automatiquement ces fonctions de déchargement TCP dans la pile TCP/IP lorsque le pilote IPSec possède des filtres, même si IPSec effectue uniquement des fonctions autoriser et bloquer. Les pilotes de cartes réseau qui ne sont pas certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel (WHQL) risquent de provoquer des problèmes lorsque IPSec est utilisé pour protéger le trafic. Un jeu de tests étendu est utilisé par WHQL pour certifier les pilotes NIC conçus pour reconnaître le déchargement d'IPSec. Pour faciliter le dépannage, la pile TCP/IP de Windows 2000, Windows XP et Windows Server 2003 prend en charge une option de clé de registre permettant de désactiver toutes les formes de déchargement TCP/IP. Certains pilotes NIC prennent également en charge la désactivation du déchargement en utilisant les propriétés avancées de la connexion réseau. Vous devrez peutêtre redémarrer votre ordinateur pour que les modifications de la configuration du pilote prennent effet. Dépannage de la perte de paquets dans les protocoles IPSec Les paquets peuvent être rejetés ou perdus, ce qui peut affecter la connectivité de l'application. Cette section détaille les cas courants de rejet des paquets par IPSec. Comme mentionné précédemment, certains périphériques réseau n'autorisent pas la transmission du protocole IP 50 ou 51 ou des ports UDP 500 ou 4500. De même, certains paquets encapsulés par IPSec peuvent se fragmenter et ne pas traverser le réseau. Dans ce cas de figure, un suivi de la surveillance réseau est généralement requis de la part des deux côtés de la communication pour permettre d'identifier et d'établir une corrélation entre les paquets envoyés et ceux reçus. Recherchez les transmissions signalées par des paquets de même taille apparaissant à plusieurs reprises. Il peut s'avérer nécessaire de réaliser un suivi du comportement type du protocole sans IPSec, puis de le comparer avec le comportement du protocole du trafic protégé par IPSec. Erreur de l'événement 4285 Titre de l'événement : Échec d'authentification de hachage
195
IKE et IPSec offrent une protection contre la modification des paquets pendant qu'ils traversent le réseau. Si un périphérique modifie une partie du paquet protégé par un hachage d'intégrité, alors le pilote IKE ou IPSec récepteur rejettera ce paquet, ce qui entraînera l'erreur d'échec d'authentification de hachage consignée dans le journal système en tant qu'événement 4285. L'expérience a montré que certains périphériques, pilotes réseau et processeurs tiers de paquets endommagent parfois les paquets d'une taille donnée, ceux qui possèdent un certain nombre de fragments, ceux d'un certain type de protocole ou lorsque certaines conditions sont réunies (lorsque le périphérique est saturé, qu'il surveille le trafic ou qu'il redémarre). Cette erreur peut également être due à une attaque du paquet par une application malveillante ou par une application qui ignorait qu'il était protégé. Elle peut aussi indiquer une attaque par refus de service. Vous pouvez utiliser les techniques suivantes pour détecter le rejet des paquets corrompus par IPSec. Cependant, il est également important d'établir une corrélation entre ces observations et le suivi de la surveillance du réseau pour permettre de détecter la source de la corruption.
• Examinez le compteur Paquets IPSec non authentifiés. Sous Windows Server 2003, vous
pouvez vérifier ce compteur à l'aide du compteur IPSec de l'analyseur de performances, de la commande netsh ipsec dynamic show stats ou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows XP, vous pouvez vérifier ce compteur à l'aide de la commande ipseccmd show stats ou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows 2000, ce compteur apparaît dans l'affichage graphique d'ipsecmon.exe ou lorsque vous utilisez la commande netdiag /test:ipsec /v .
• Activez la journalisation du pilote IPSec et recherchez l'événement 4285 dans le journal système à partir d'IPSec source. Consultez la section Jeu d'outils de ce chapitre pour obtenir des détails sur la manière d'activer la journalisation du pilote IPSec. Le texte de l'événement sera similaire à ce qui suit :
Échec lors de l'authentification du hachage de 5 paquet(s) reçu(s) de 192.168.0.10. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur. Bien que le texte de l'événement suggère un redémarrage du service IPSec pour résoudre le problème, l'origine de la perte de la plupart des paquets n'est pas liée au système IPSec. Le redémarrage du service ne permettra pas de résoudre le problème et risque d'engendrer davantage de difficultés. Le service IPSec ne doit être arrêté qu'en dernier recours pour déterminer si un problème est lié à IPSec ou non. La résolution de cette erreur requiert des recherches pour identifier un modèle des adresses IP source, des heures de la journée, des cartes réseau ou des conditions dans lesquelles l'erreur se produit. Si le nombre de paquets est peu élevé, il n'est peutêtre pas utile d'effectuer des recherches. Il est important de commencer par exclure les sources de la corruption du système local. Désactivez le déchargement d'IPSec, essayez de désactiver les fonctions avancées ou de performances du pilote en utilisant la configuration fournie dans les propriétés avancées et procurezvous les pilotes NIC les plus récents auprès de votre fournisseur. Utilisez de préférence des pilotes certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel. Étudiez ensuite les caractéristiques des chemins réseau via lesquels le paquet sera transmis. Recherchez d'autres preuves de la corruption du paquet dans les statistiques de rejet des paquets TCP/IP et sur les autres ordinateurs utilisant la même configuration. Le compteur IP des Datagrammes reçus et rejetés augmente chaque fois qu'IPSec rejette un paquet. Remarque : pour désactiver la fonctionnalité de déchargement TCP/IP, utilisez la clé de registre suivante sur les ordinateurs exécutant Windows 2000, Windows XP ou Windows Server 2003 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\ Valeur de registre EnableOffload DWORD définie sur 0
196
(Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.) Redémarrez ensuite l'ordinateur. Erreur de l'événement 4268 Titre de l'événement : Paquets reçus avec un index des paramètres de sécurité (Security Parameters Index, SPI) erroné L'implémentation d'IKE sous Windows 2000 et Windows XP (y compris SP1) génère un problème connu qui entraîne la perte de paquets dans certaines conditions. Ce problème a été résolu pour Windows Server 2003 et Windows XP SP2. L'impact sur les communications du protocole de niveau supérieur est généralement négligeable car les protocoles subissent habituellement quelques pertes de paquets pour diverses autres raisons. Ce problème peut être identifié par les caractéristiques suivantes :
• Augmentation lente mais régulière des valeurs du compteur SPI erroné. • Messages de l'événement 4268 dans le journal système (si activé). Par défaut, Windows 2000
consigne ces messages dans le journal système en tant qu'événement 4268. Windows XP ne consigne pas cet événement par défaut ; il faut que la journalisation du pilote soit activée. Le texte de l'événement est similaire à ce qui suit :
<nombre> paquet(s) reçu(s) de
• transfert de volumes importants de trafic IPSec via des connexions de 1 gigabit ou plus ; • serveurs très encombrés (lents) et ordinateurs clients rapides ; • clients lents communiquant avec un serveur rapide ; • multiples clients actifs pour un serveur, ce qui oblige IKE à une recomposition constante avec plusieurs clients simultanément.
Par conséquent, une connexion TCP protégée par IPSec va ralentir pendant quelques secondes pour retransmettre les données perdues. Si plusieurs paquets sont perdus, TCP risque de passer en mode d'évitement de saturation pour cette connexion. Après quelques secondes, la connexion doit retrouver
197
sa vitesse normale. Pour les applications de copie de fichiers, Telnet, Terminal Server ainsi que les autres applications basées sur TCP, la perte de ces paquets passe inaperçue. Cependant, il peut arriver que TCP perde un groupe de paquets sur une liaison rapide et qu'il doive rétablir la connexion. Lorsque la connexion est rétablie, le socket est fermé et les applications sont averties de la rupture de connexion, ce qui peut interrompre les transferts de fichiers. La cause la plus courante de cette erreur est un problème connu relatif à Windows 2000 qui implique le mode de synchronisation de la recomposition de la SA IPSec par IKE. Lorsque l'initiateur du mode rapide IKE est plus rapide que le répondeur, l'initiateur peut envoyer les nouveaux paquets sécurisés de l'association de sécurité IPSec plus rapidement que le répondeur ne peut les recevoir. Comme l'indique le document RFC (Requests for Comment, demande de commentaires) de l'IETF (Internet Engineering Task Force) relatif à IPSec, lorsque IKE établit une nouvelle association de sécurité IPSec, l'initiateur doit utiliser la nouvelle SA IPSec sortante pour transmettre les données alors que le répondeur plus lent reçoit le trafic protégé par IP qu'il ne reconnaît pas encore. Étant donné que la recomposition IKE dépend à la fois du temps écoulé et de la quantité de données envoyées sous la protection d'une SA IPSec, il est possible que des événements SPI erronés apparaissent périodiquement (mais pas nécessairement à des intervalles spécifiques). Dans des scénarios d'interopérabilité de client tiers, une erreur de SPI erroné peut indiquer qu'un IPSec pair n'a pas accepté un message de suppression et ne l'a pas traité ou qu'il a rencontré des problèmes pour exécuter la dernière étape de la négociation du mode rapide IKE. Cette erreur peut également signifier qu'un attaquant submerge un ordinateur de paquets IPSec usurpés ou injectés. Le pilote IPSec compte ces événements et les consigne pour conserver un enregistrement de l'activité du SPI erroné. La clé de registre LogInterval peut être utilisée pour identifier et minimiser ces événements. Lors du dépannage, définissezla sur la valeur minimum (toutes les 60 secondes) pour que les événements soient enregistrés rapidement. Sous Windows 2000, vous pouvez arrêter et redémarrer le service Agent de stratégie IPSec pour recharger le pilote IPSec. Sous Windows XP et Windows Server 2003, vous devez redémarrer l'ordinateur pour recharger les pilotes TCP/IP et IPSec. Sous Windows 2000, ces événements ne peuvent pas être supprimés par les paramètres de clé de registre actuels ou des correctifs. Par défaut, sous Windows XP et Windows Server 2003 ces événements ne sont pas signalés. Vous pouvez activer les rapports de ces événements en utilisant la configuration IPSecDiagnostics via l'option de ligne de commande netsh ipsec ou directement via la clé de registre. Les techniques suivantes peuvent vous aider à minimiser ces erreurs :
• Ajustez les paramètres de la stratégie IPSec. Augmentez la durée de vie du mode rapide (si les
exigences de sécurité le permettent) à 21 ou 24 heures (les associations de sécurité IPSec inactives sont effacées au bout de 5 minutes si elles ne sont pas utilisées). Pour éviter l'apparition de faiblesses potentielles au niveau de la sécurité due à l'utilisation de la même clé pour chiffrer trop de données, ne définissez pas une durée de vie supérieure à 100 Mo lorsque vous utilisez le chiffrement ESP.
• Utilisez la confidentialité de transmission parfaite (perfect forward secrecy, PFS) du mode principal ou du mode rapide qui ne provoque pas ce problème pour l'association de sécurité spécifique en cours de négociation. Cependant, ces paramètres augmentent considérablement la charge de l'ordinateur qui traite les requêtes de plusieurs clients et risquent ainsi de contribuer à accroître le délai de réponse aux autres négociations.
• Ajoutez un processeur ou un matériel permettant d'augmenter les performances ou de réduire les charges sur l'application.
198
• Installez une carte réseau d'accélération matérielle IPSec si l'ordinateur n'en dispose pas. Ces cartes réduisent considérablement l'utilisation du processeur par IPSec lors des transferts de données à débit élevé.
• Si l'utilisation du processeur reste élevée, pensez à utiliser un produit accélérateur de matériel pour accélérer les calculs DiffieHellman. Il s'agit en général d'une carte PCI dotée de la capacité de déchargement de l'élévation à la puissance DiffieHellman qui accélère les calculs DiffieHellman. Cette accélération est également bénéfique aux opérations de clé publique et de clé privée qui utilisent le protocole SSL (Secure Sockets Layer). Vérifiez auprès de votre fournisseur que sa carte prend en charge l'interface ModExpoOffload sous CAPI pour les calculs DiffieHellman.
• Si possible, créez un filtre qui autorise certains trafics à haute vitesse ne nécessitant pas la
protection IPSec (par exemple, le trafic de sauvegarde d'un serveur sur un réseau local dédié).
Si ces options ne fonctionnent pas et que la mise à niveau vers Windows XP SP2 ou Windows Server 2003 est impossible, contactez les services de support technique Microsoft pour savoir s'il existe d'autres options disponibles. Erreur de l'événement 4284 Titre de l'événement : Paquets en clair nécessitant une sécurisation Cet événement indique qu'une association de sécurité IPSec a été établie à un moment où des paquets ont été reçus en clair alors qu'ils auraient dû faire partie de l'association de sécurité IPSec. Ces paquets ont été rejetés afin d'éviter toute attaque par injection de paquets sur les connexions sécurisées par IPSec. Bien que le compteur IP des Datagrammes reçus et rejetés augmente, IPSec ne possède pas de valeur de compteur qui enregistre le nombre de paquets rejetés pour cette raison. Ce problème peut uniquement être identifié à partir de l'événement 4284 du journal système : <nombre> paquet(s) reçu(s) en clair de
199
Le message d'erreur peut également apparaître lorsqu'une stratégie volumineuse est chargée, car les associations de sécurité IPSec peuvent être établies avant que le jeu complet de filtres ne soit appliqué au pilote IPSec. Si cette situation se produit, les associations de sécurité IPSec peuvent être négociées pour le trafic qui sera exempté une fois le chargement de la stratégie terminé. Ce message d'erreur peut aussi révéler la présence d'une attaque par injection à l'endroit où le trafic en texte clair est envoyé correspondant (délibérément ou par hasard) aux sélecteurs de trafic d'une association de sécurité entrante active spécifique. Ce problème doit être transféré au concepteur de la stratégie IPSec. Délais d'expiration IPSec NATT lors de la connexion à des réseaux sans fil Un problème récemment détecté provoque l'expiration des connexions lorsque des ordinateurs clients Windows Server 2003 ou Windows XP tentent de se connecter à un serveur sur un réseau sans fil utilisant IPSec NATT. Pour plus d'informations, reportezvous à l'article 885267 de la Base de connaissances Microsoft à l'adresse http://support.microsoft.com/?kbid=885267.
Vérification de la stratégie IPSec appropriée Cette section décrit les étapes de la détection de problèmes concernant l'attribution et l'interprétation de la stratégie IPSec. Les filtres d'une stratégie IPSec correctement interprétée doivent se trouver dans le pilote IPSec pour que IPSec puisse autoriser et bloquer les paquets, mais aussi déclencher la négociation par IKE des associations de sécurité IPSec avec les adresses IP distantes pour sécuriser le trafic. Des filtres appropriés doivent aussi être mis en place pour guider IKE en tant que répondeur. Dans cette solution, la conception de la stratégie IPSec requiert que tout le trafic (sauf ICMP) soit sécurisé par IPSec. La stratégie contient des filtres pour chaque adresse IP de la liste d'exemption. Remarque : sous Windows 2000, le service IPSec est appelé Agent de stratégie IPSec ; sous Windows XP et Windows Server 2003, il est appelé Service IPSec. Les ingénieurs du support technique doivent être familiarisés avec l'utilisation de la stratégie de groupe par IPSec, la priorité de la stratégie IPSec et son interprétation. Vous trouverez des références aux informations contenues dans ces rubriques dans la section Informations complémentaires à la fin de ce chapitre. Dépannage de la stratégie de groupe pour IPSec La stratégie de groupe fournit le mécanisme d'attribution d'une stratégie IPSec de domaine à un membre du domaine. L'extraction d'objets GPO attribués par le membre du domaine permet d'attribuer la stratégie IPSec à un ordinateur hôte. Par conséquent, en cas de problème avec l'extraction des GPO, les ordinateurs n'appliquent pas la stratégie IPSec adéquate. Les problèmes courants concernant la stratégie de groupe pour la gestion de la stratégie IPSec incluent :
• retards de réplication de divers composants de configuration dans Active Directory ; • problèmes liés au sondage de la stratégie de groupe et au processus de téléchargement ; • manque de clarté par rapport à la version de la stratégie IPSec attribuée ; • service IPSec non exécuté ; • extraction de la stratégie IPSec impossible dans Active Directory, utilisation d'une copie mise en cache à la place ;
200
• retards dus au sondage de la stratégie IPSec pour extraire une stratégie IPSec actuellement attribuée.
La réplication peut être retardée en raison du nombre d'objets liés à IPSec dans Active Directory, comme les stratégies IPSec, les GPO, les changements d'attribut dans les attributions de la stratégie IPSec aux GPO et dans la stratégie IPSec ainsi que les informations sur les appartenances aux groupes de sécurité. La planification doit tenir compte de l'impact d'un changement dans la configuration IPSec qui influence progressivement les membres du domaine. Pour obtenir des informations sur les procédures de dépannage de la stratégie de groupe, consultez les livres blancs suivants :
• Troubleshooting Group Policy in Windows 2000 (Dépannage de la stratégie de groupe sous Windows 2000)
à l'adresse http://support.microsoft.com/?kbid=810739.
• Troubleshooting Group Policy in Microsoft Windows Server
(Dépannage de la stratégie de groupe sous Microsoft Windows Server) à l'adresse www.microsoft.com/downloads/details.aspx FamilyId=B24BF2D50D7A4FC5A14DE91D211C21B2&displaylang=en.
L'attribution d'une stratégie IPSec basée sur le domaine est implémentée par deux composants :
• le composant logiciel enfichable MMC Gestion de stratégie IPSec (une extension du composant logiciel MMC Stratégie de sécurité) pour l'attribution d'une stratégie IPSec dans le GPO ;
• l'extension côté client (client side extension, CSE) de la stratégie de groupe pour IPSec (implémentée dans gptext.dll) qui traite les informations liées à IPSec dans le GPO.
Le composant logiciel enfichable MMC Gestion de stratégie IPSec attribue une stratégie à un objet GPO en stockant les informations sur la stratégie IPSec sélectionnée dans le composant IPSec de l'objet GPO, référencé en tant que nom unique (Distinguished Name, DN) LDAP : CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID}, CN=Stratégies,CN=Système,DC=domaine,DC=Woodgrove,DC=com Le nom unique LDAP de la stratégie IPSec attribuée est stocké dans l'attribut du GPO ipsecOwnersReference. Lorsque la stratégie de groupe extrait la liste d'objets GPO qui s'appliquent à l'ordinateur, les GPO contenant les attributions de la stratégie IPSec sont stockés dans le registre sous le GUID (Globally unique identifier, identifiant unique global) de l'extension IPSec côté client à l'emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Group Policy \History\{e437bc1caa7d11d2a38200c04f991e27} L'extension IPSec côté client est activée par la CSE de la stratégie de sécurité chaque fois qu'une attribution de stratégie IPSec existe dans un objet GPO. S'il existe des problèmes de traitement de la stratégie de sécurité, il risque également d'y avoir des problèmes de traitement de la stratégie IPSec. Pour localiser le GUID de chaque extension de stratégie de groupe, consultez l'emplacement suivant dans le registre : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \WindowsNT\CurrentVersion\WinLogon\GPExtensions
201
Les GUID liés au déploiement d'IPSec pour les CSE de stratégie de groupe se présentent comme suit :
• Sécurité. {827D319E6EAC11D2A4EA00C04F79F83A} • Sécurité IP.{E437BC1CAA7D11D2A38200C04F991E27} • Scripts. {42B5FAAE653611D2AE5A0000F87571E3} La CSE IPSec copie le numéro unique LDAP ainsi que les informations associées sur la stratégie IPSec attribuée dans la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy Si plusieurs objets GPO contiennent des attributions de stratégie IPSec, alors la CSE IPSec est appelée pour chaque GPO. Les règles de priorité des GPO s'appliquent selon l'ordre dans lequel la CSE IPSec reçoit les GPO à traiter. L'ordre peut également être influencé par les paramètres des objets GPO et par les listes de contrôle d'accès (Access control list, ACL) en lecture qui empêchent l'extraction de certains objets GPO attribués. Chaque fois qu'une CSE IPSec est appelée, les informations IPSec associées situées dans le GPO (y compris le nom unique) sont écrasées dans la clé de registre. Une fois que tous les GPO ont été traités, la CSE avertit le service IPSec qu'une stratégie IPSec basée sur le domaine est attribuée. Le service IPSec lit ensuite la valeur GPTIPSecPolicy\DSIPSECPolicyPath afin d'extraire la stratégie IPSec appropriée. Le service IPSec continue à rechercher les éventuels changements apportés à la stratégie IPSec attribuée en fonction de l'heure de la dernière mise à jour de l'un des objets d'annuaire de la stratégie IPSec attribuée. Ce service entretient la stratégie IP mise en cache et la considère comme la stratégie de domaine la plus récente. Il existe un problème connu qui autorise le nom de la stratégie IPSec attribuée à ne plus être synchronisé avec le nom de la stratégie IPSec en cours d'utilisation (et mise en cache). Le service IPSec ne met pas à jour les informations de la clé de registre GPTIPSecPolicy, telles que DSIPSECPolicyName, et le nom de la stratégie IPSec change uniquement lorsque la CSE IPSec est appelée. Toutefois, la CSE IPSec n'est pas appelée à moins qu'il se produise un changement dans l'attribut de nom unique de la stratégie IPSec dans l'objet GPO. Cette valeur de registre est utilisée par le composant logiciel enfichable MMC Moniteur IPSec et les outils de ligne de commande pour indiquer le nom de la stratégie IPSec actuellement attribuée. Ainsi, les outils IPSec peuvent signaler le nom de la stratégie IPSec traitée en dernier par la CSE, et non celui de la stratégie en cours d'utilisation. Il existe plusieurs solutions pour éviter ce bogue. Pour plus d'informations, reportezvous à la section Versions des stratégies du chapitre 5, Création de stratégies IPSec pour les groupes d'isolation de ce guide. Remarque : Microsoft recommande que les conventions de dénomination des stratégies IPSec incluent un numéro de version dans le nom, afin qu'il soit plus aisé de retrouver la version de la stratégie actuellement appliquée. Il est impossible de détecter des changements de version si le nom d'une stratégie reste identique. Si la stratégie IPSec correcte n'est pas attribuée, même après une actualisation forcée de la stratégie de groupe, les erreurs du journal des applications des sources Userenv ou SceCli signaleront des problèmes de traitement de la stratégie de groupe. Il est nécessaire que la journalisation de la stratégie de groupe soit activée pour que vous puissiez étudier ce problème en détail. Il existe différents types de journaux de stratégie de groupe et différents niveaux de journalisation. Les journaux de la CSE de sécurité sont nécessaires pour connaître les erreurs de traitement de la stratégie de sécurité ainsi que les erreurs signalées par la CSE IPSec. Il n'existe pas de journal
202
spécifique à l'extension côté client IPSec. Les suivis de la surveillance réseau seront peutêtre requis pour capturer le trafic au moment de l'actualisation de la stratégie de groupe pour confirmer quelle adresse IP de contrôleur de domaine est utilisée pour l'extraction de chaque objet. Vous pouvez rencontrer les difficultés suivantes :
• des problèmes de réplication ou de retard conduisant à l'impossibilité de trouver des objets ; • la logique de l'équilibrage de charge du localisateur du contrôleur de domaine peut entraîner
l'extraction d'un objet GPO à partir d'un contrôleur de domaine alors que la requête LDAP de la stratégie IPSec attribuée est extraite à partir d'un autre contrôleur de domaine du même site.
Pour créer un fichier journal détaillé de la CSE de sécurité, utilisez la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \WindowsNT\CurrentVersion\CurrentVersion\Winlogon \GpExtensions\{827d319e6eac11d2a4ea00c04f79f83a}\ Définissez l'entrée ExtensionDebugLevel sur une valeur REG_DWORD de 0x2. Le fichier journal sera créé à l'emplacement %windir%\Security\Logs\Winlogon.log. Remarque : une entrée DNS non valide peut signifier que les stratégies de groupe ne sont pas téléchargées depuis Active Directory, même si les connexions de l'utilisateur et de l'ordinateur ont réussi. Pour plus d'informations sur les problèmes DNS, reportezvous à la section Problèmes de résolution de noms, plus haut dans ce chapitre. Dépannage du service IPSec Il n'est pas nécessaire que le service IPSec soit en cours d'exécution pour que vous puissiez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec. Cependant, si un administrateur attribue par la suite une stratégie locale, la colonne Stratégie attribuée affiche une erreur. Les problèmes courants suivants peuvent entraîner l'échec du service IPSec au démarrage :
• L'ordinateur a démarré en mode sans échec ou en mode de récupération Active Directory.
Dans ces deux cas, le pilote IPSec fournit une communication sortante avec état par défaut si une stratégie IPSec est attribuée. La connectivité entrante sera bloquée jusqu'à ce qu'une exemption d'amorçage soit configurée.
• IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 et 4500. Utilisez la commande
netstat –bov pour afficher les processus et les modules de code de chaque port. La commande portqry –local –v offre davantage de détails. Il est possible que des fournisseurs de services superposés (Layered Service Providers, LSP) Winsock installés interfèrent avec IPSec. Pour plus d'informations sur les LSP et IPSec, reportezvous à la section Dépannage des problèmes liés aux applications plus loin dans ce chapitre.
• Corruption de la stratégie IPSec. La stratégie IP attribuée ne peut pas être lue ou appliquée en
totalité, ce qui oblige le service IPSec à signaler des erreurs. Ces erreurs ne provoquent pas l'échec du service, mais peuvent entraîner des échecs de communication de plusieurs façons, en bloquant la stratégie de groupe et en empêchant le service IPSec d'extraire les stratégies corrigées, par exemple. Sous Windows XP et Windows Server 2003, vous devez veiller à ce que la conception d'une stratégie persistante ou locale soit « fiable » afin qu'elle soit appliquée en cas d'erreurs survenant lorsqu'une stratégie de domaine est appliquée. Les stratégies persistantes et les stratégies de démarrage de l'ordinateur (exemptions du mode d'amorçage) doivent faire partie des investigations de dépannage. Ces stratégies doivent autoriser l'accès distant à l'ordinateur par
203
d'autres moyens dans le cas où elles sont les seules stratégies appliquées en raison d'autres conditions d'échec. L'implémentation d'IPSec sous Windows 2000 utilise un module appelé Magasin de stratégies IPSec (polstore.dll) afin que les composants logiciels enfichables MMC Agent de stratégie IPSec et Gestion de stratégie IPSec puissent utiliser un module pour accéder aux trois emplacements de stockage des stratégies pris en charge : local, ordinateur distant et Active Directory. Cette conception a été modifiée et améliorée sous Windows XP et Windows Server 2003 avec l'ajout de nouveaux types de stratégies IPSec (stratégie de démarrage et persistante) et du composant Base de données de stratégies de sécurité (Security Policy Database, SPD), qui gère l'état d'exécution de la stratégie IPSec pour les requêtes de surveillance IPSec et les requêtes IKE. Cette modification d'ordre architectural signifie que le texte des événements IPSec consignés sous Windows 2000 a changé sous Windows XP et Windows Server 2003. Elle signifie également que des changements importants ont dû être apportés aux interfaces RPC utilisées pour la gestion à distance. Pour Windows Server 2003, les interfaces RPC ont subi d'importantes mises à jour. C'est pourquoi le composant logiciel enfichable MMC Gestion de stratégie IPSec n'est pas capable de se connecter à des ordinateurs distants qui ne possèdent pas la même version de système d'exploitation. En outre, le modèle de sécurité pour Windows XP SP2 et Windows Server 2003 SP1 a été radicalement modifié pour limiter les connexions RPC distantes et pour activer le parefeu Windows par défaut. Pour plus d'informations, reportezvous à Changes to Functionality in Microsoft Windows XP Service Pack 2 Part 2: Network Protection Technologies (Modifications apportées à Microsoft Windows XP Service Pack 2 Partie 2 : technologies de protection des réseau) à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/ maintain/sp2netwk.mspx. En raison de ces changements, les interfaces RPC distantes du service IPSec ont été désactivées par mesure de sécurité. Par conséquent, les composants logiciels enfichables MMC Moniteur IPSec et Gestion de stratégie IPSec ne peuvent pas réaliser de surveillance à distance sur ces ordinateurs. La gestion distante d'IPSec doit être effectuée à l'aide de connexions Bureau à distance (Terminal Server), qui exécutent les composants logiciels enfichables MMC IPSec en tant que processus locaux. Sous Windows 2000, le pilote IPSec est chargé par défaut à la fin du processus de démarrage par le service Agent de stratégie. Le pilote IPSec ne participe pas au traitement des paquets IP jusqu'à la première fois où le service Agent de stratégie informe le pilote IPSec d'une stratégie active. S'il n'existe pas de stratégie IPSec active, le pilote IPSec n'est pas inclus dans le traitement du trafic IP entrant et sortant. Sous Windows XP et Windows Server 2003, cette conception a été améliorée pour que le pilote IPSec soit chargé par le pilote TCP/IP au cours du processus de démarrage. Le pilote ne traite pas les paquets avant que des filtres soient chargés par le service IPSec. Sous Windows 2000, il est possible que des erreurs soient consignées par l'Agent de stratégie IPSec pour des problèmes de démarrage du service. Ces erreurs sont les suivantes :
• L'Agent de stratégie de la sécurité IP n'a pas pu démarrer. Aucune stratégie de sécurité IP
ne sera appliquée. Cette erreur est probablement due aux problèmes rencontrés par l'Agent de stratégie IPSec lors de son enregistrement auprès du soussystème RPC. Elle peut aussi provenir de l'échec d'initialisation d'IKE en raison de LSP Winsock tiers.
• Le Serveur RPC de l'Agent de stratégie n'a pas pu... • • • • • •
enregistrer la séquence de protocoles enregistrer l'interface enregistrer les liens d'interface enregistrer le point de fin d'interface enregistrer les mécanismes d'authentification écouter
204
Ces erreurs peuvent être dues à des changements apportés aux paramètres de sécurité avancés ou à des problèmes inhérents au service RPC qui ne permettent pas à l'Agent de stratégie IPSec de s'initialiser correctement au démarrage du service. Par conséquent, l'Agent de stratégie IPSec ne fonctionnera pas correctement, risquera de se bloquer ou de s'arrêter.
• L'Agent de stratégie n'a pas pu démarrer. Impossible de se connecter à la base de données SCM. Erreur :
• L'Agent de stratégie n'a pas pu se connecter au pilote IPSEC. Le pilote IPSec n'a pas pu être
chargé ni interfacé correctement avec la pile TCP/IP. Windows 2000 est conçu pour réaliser cette opération lorsque le service IPSec démarre. Il est possible qu'un logiciel tiers désactive la connexion ou que le système d'exploitation ne dispose pas de tous les modules de codes requis pour cette fonctionnalité.
• L'Agent de stratégie n'a pas pu charger les stratégies IPSEC. Une erreur s'est produite
pendant que l'agent de stratégie IPSec chargeait tous les filtres dans le pilote IPSec. Cette erreur peut provenir d'un manque de mémoire du noyau ou de la mauvaise initialisation du pilote IPSec. Si le problème persiste, contactez les services de support technique Microsoft.
• L'Agent de stratégie n'a pas pu démarrer le service ISAKMP. Cette erreur se produit
généralement car IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 ou 4500 étant donné qu'ils sont utilisés par un autre service. Elle peut aussi être provoquée par un logiciel de sécurité tiers qui empêche l'allocation des ports réseau ou parce que le service IPSec n'est pas exécuté dans le contexte du système local.
• Impossible de déterminer le nom principal SSPI pour le service ISAKMP/Oakley.
Windows 2000 enregistre ce message lorsque l'appel de la fonction QueryCredentialsAttributes de l'interface du fournisseur de prise en charge de la sécurité (security support provider interface, SSPI) échoue. Cette échec peut signifier que l'ordinateur n'a pas réussi à se connecter au domaine.
• Impossible d'obtenir les informations d'identification du serveur Kerberos pour le service
ISAKMP/Oakley. Ce message d'erreur de Windows 2000 apparaît couramment lorsque le service IPSec démarre (peutêtre au démarrage de l'ordinateur) sur un réseau distant où une stratégie IPSec est attribuée (peutêtre depuis le cache du registre de la stratégie de domaine) et nécessite l'authentification Kerberos alors qu'un contrôleur de domaine n'est pas disponible. C'est pourquoi l'authentification Kerberos ne fonctionne pas. Sur le réseau interne, cet événement est consigné sur un ordinateur non membre du domaine ou qui ne peut pas communiquer avec les contrôleurs de domaine à l'aide du protocole Kerberos lors de l'initialisation du service IPSec.
• Une stratégie de communication sécurisée ne peut pas être appliquée car le pilote de sécurité IP
n'a pas pu démarrer. Contactez votre administrateur système immédiatement. Cette erreur est provoquée par un problème de chargement du pilote IPSec, sa liaison à la pile TCP/IP ou son initialisation avant l'ajout de la stratégie. La corruption de fichiers ou les autorisations peuvent être à l'origine de cette erreur. Vérifiez que les paramètres de sécurité ou un logiciel tiers ne désactivent pas le chargement du pilote. Si les signatures internes FIPS.sys ne peuvent pas être vérifiées au cours de l'initialisation, le chargement du pilote IPSec échoue également. L'échec de la signature FIPS.sys requiert le remplacement du fichier binaire signé d'origine ou un nouveau fichier binaire de Microsoft. Redémarrez l’ordinateur. Si le problème persiste, contactez les services de support technique Microsoft.
Sous Windows XP et Windows Server 2003, les événements d'erreur du service IPSec suivants indiquent que le service ne peut pas démarrer :
205
• Les services IPSec n'ont pas pu initialiser le pilote IPSec, code d'erreur :
• Les services IPSec n'ont pas pu initialiser le module IKE, code d'erreur :
IPSec n'ont pas pu démarrer. Ce problème est fréquemment dû à des LSP Winsock tiers qui empêchent IKE d'utiliser certaines options de socket. Cette erreur est également signalée lorsque IKE ne peut pas obtenir l'accès exclusif des ports UDP 500 et 4500.
• Les services IPSec n'ont pas pu initialiser le serveur RPC, code d'erreur :
• Les services IPSec ont expérimenté une défaillance critique et se sont arrêtés avec le code
d'erreur :
• Les services IPSec mettent le pilote IPSec en mode de blocage à cause du code d'erreur de
défaillances
Dépannage de l'extraction de la stratégie IPSec Le service IPSec utilise une requête LDAP TCT authentifiée et chiffrée pour télécharger la stratégie IPSec attribuée pour toutes les platesformes. Il existe des options permettant de signer et de sceller LDAP à l'aide de la clé de session Kerberos. Ainsi, le service IPSec exécuté en tant que système local doit être capable d'obtenir un ticket de service Kerberos pour le service LDAP sur le serveur Active Directory. Si la stratégie IPSec correcte est attribuée et que son stockage par la CSE IPSec est confirmé sous la clé de registre GPTIPSecPolicy et que le service fonctionne, alors les problèmes suivants risquent d'empêcher IPSec d'extraire la stratégie depuis Active Directory :
• problèmes de communication avec les contrôleurs de domaine ; • problèmes de connexion des comptes de l'ordinateur à un contrôleur de domaine ; • problèmes d'émission de tickets Kerberos ; • problèmes liés à la disponibilité du service LDAP ; • problèmes de recherche de la stratégie IPSec ou des objets de composant spécifiques requis dans la requête LDAP ;
• problèmes d'autorisation en lecture pour n'importe quel objet de la stratégie IPSec requis ; • corruption de la stratégie en raison de problèmes lors de l'enregistrement d'objets dans le magasin ou en raison de la suppression accidentelle ou intentionnelle d'objets du magasin.
206
Remarque : une stratégie IPSec créée dans Windows XP ou Windows Server 2003 et qui utilise de nouvelles fonctions alors disponibles dans ces versions risque de voir ces fonctions supprimées silencieusement si une stratégie est ultérieurement modifiée et enregistrée par le composant logiciel enfichable MMC Gestion de stratégie IPSec sous Windows 2000. Cependant, si un système Windows 2000 extrait une stratégie IPSec dotée de fonctions supplémentaires, il les ignore, ce qui peut, soit changer le comportement de la stratégie IPSec lorsqu'elle est utilisée sur un système Windows 2000, soit avoir aucun impact sur le comportement de la stratégie. Un problème connu relatif au composant logiciel enfichable MMC Gestion de stratégie IPSec se produit lors de la gestion de la stratégie IPSec dans Active Directory ou sur un ordinateur distant. Si le composant logiciel MMC est exécuté sur une liaison lente, l'enregistrement de tous les changements d'une stratégie volumineuse peut être long. Si la fenêtre du composant logiciel MMC est fermée, tous les objets ou changements d'une stratégie IPSec qui ne sont pas encore enregistrés sont perdus. Cette fonctionnalité peut entraîner la corruption de la stratégie IPSec. Si le composant logiciel enfichable MMC Gestion de stratégie IPSec est exécuté sur une liaison lente, utilisez une session Bureau à distance pour exécuter le composant en tant que processus local. Généralement, tout script d'outil de ligne de commande permettant de créer une stratégie IPSec doit être testé. Pour ce faire, créez une stratégie dans le magasin local et affichezla en utilisant le composant MMC Gestion de stratégie IPSec pour vérifier son intégrité. Des ordinateurs de test doivent appliquer la stratégie locale et étudier les détails dans le composant MMC Moniteur IPSec pour confirmer l'ordre de filtrage attendu. Les procédures permettant de dépanner et de résoudre des erreurs de lecture et de corruption de la stratégie IPSec dépendent de l'emplacement de stockage. Cette solution utilise une stratégie IPSec basée sur domaine uniquement, mais d'autres types de stratégies IPSec ont pu être configurés de façons qui entraînent des problèmes. Les procédures de dépannage de chaque type de stratégie sont décrites dans le reste de cette section. Généralement, le support de niveau 2 doit être capable d'utiliser les outils de la ligne de commande ou les outils de l'interface graphique utilisateur pour confirmer que la stratégie IPSec appropriée est en cours d'extraction et que cette stratégie est correctement interprétée. Les étapes de la suppression de chaque type de stratégie sont indiquées ici. L'objectif de l'actualisation de la stratégie est d'installer une stratégie correcte. S'il est impossible d'extraire ou d'installer une stratégie correcte à partir des scripts, alors le problème est transféré au support de niveau 3. Stratégie IPSec au démarrage L'utilitaire Netsh permet la configuration d'options de mode d'amorçage et d'exemption d'amorçage prises en charge par Windows Server 2003 uniquement. La configuration est stockée dans les clés de registre suivantes avec les valeurs par défaut affichées :
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ OperationMode=3 (avec état)
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\ BootExemptList = (exemption pour DHCP entrant, voir cidessous)
La valeur OperationMode par défaut nécessite que le pilote IPSec procède au filtrage avec état du trafic sortant. Si le service IPSec est en cours d'exécution, utilisez la commande Netsh ipsec dynamic show config pour afficher la configuration de démarrage. Si le service IPSec n'est pas en cours d'exécution (par exemple, dans le cas d'un démarrage en mode sans échec), vous pouvez utiliser les outils du registre pour examiner la valeur de la clé du registre et la modifier.
207
Pour résoudre les problèmes de trafic provoqués par le filtrage avec état d'IPSec au démarrage, définissez le pilote IPSec afin qu'il autorise le trafic au démarrage au lieu d'effectuer le filtrage avec état. Si le service IPSec est en cours d'exécution, utilisez netsh ipsec dynamic set config bootmode value=permit pour définir le mode de démarrage sur autoriser. Si le service IPSec n'est pas en cours d'exécution, utilisez un outil de registre pour modifier la valeur d'autorisation OperationsMode=1. En outre, le pilote IPSec n'applique pas le mode de sécurité au démarrage si le service IPSec est configuré pour un démarrage manuel ou s'il est désactivé. Une fois que le service est configuré pour un démarrage manuel ou qu'il est désactivé, redémarrez l'ordinateur pour que le pilote IPSec soit chargé en mode autoriser. Stratégie IPSec persistante La stratégie persistante est prise en charge par Windows XP et Windows Server 2003. L'une des situations d'erreur les plus courantes survient lorsqu'une stratégie persistante existante n'est pas supprimée avant la définition d'une nouvelle stratégie persistante et que cette dernière entre en conflit avec des paramètres déjà attribués. La solution décrite dans ce guide n'utilise pas la stratégie persistante. Cependant, puisque cette stratégie est utilisée dans certains environnements, des instructions de dépannage sont fournies dans ce chapitre. La clé de registre de la stratégie persistante existe par défaut et est vide : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Persistent Sous Windows XP, le meilleur moyen de détecter une stratégie persistante est de constater que la clé de registre n'est pas vide. La commande ipseccmd show indique la stratégie active contenue dans le service IPSec et ne signale pas qu'un paramètre particulier a été généré par la stratégie persistante. Le service IPSec supprime le nom des règles de la stratégie persistante lorsqu'il interprète la stratégie avec les paramètres actifs. Étant donné que la commande ipseccmd ne fournit pas le nom des filtres et des actions de filtrage, il n'est pas possible d'utiliser des conventions de dénomination pour indiquer les filtres et les actions de filtrage issus de la stratégie persistante. Les filtres portent des noms de type « text2pol{GUID} » chaque fois qu'ils sont créés par les outils ipsecpol.exe ou ipseccmd.exe, qui incluent des entrées de la stratégie persistante. Toutefois, les stratégies locales ou de domaine créées à l'aide de scripts pourront aussi porter ces noms. La stratégie persistante est appliquée en premier et fusionne avec la stratégie IPSec locale ou de domaine. Ainsi, vous devez supprimer l'attribution des stratégies locale et de domaine avant de pouvoir afficher les paramètres persistants. Utilisez ipseccmd show all pour afficher toutes les stratégies actives, y compris les paramètres persistants, lorsque le service IPSec est démarré. Pour supprimer tous les objets (règles, listes de filtres et actions de filtrage) associés à une stratégie persistante particulière, indiquez le nom de cette stratégie dans la commande suivante : ipseccmd.exe -w PERS -p "policy name" –o Pour vous assurer qu'une stratégie persistante est supprimée, supprimez toutes les sousclés de la clé Persistent. Cependant, si vous supprimez la clé Persistent, puis que vous lancez de nouvelles commandes ipseccmd pour créer une stratégie persistante, cellesci échoueront. Pour résoudre le problème de corruption des stratégies persistantes et les conflits, supprimez tous les objets présents dans le magasin de la stratégie persistante, puis reéxécutez le script ipseccmd pour recréer la stratégie. Sous Windows Server 2003, la stratégie persistante possède des fonctionnalités de gestion complètes semblables à celles des stratégies IPSec locales et de domaine. La stratégie persistante est stockée à l'emplacement du registre référencé précédemment. Le script de commande Netsh suivant permet 208
d'afficher la stratégie persistante configurée à l'aide des commandes du fichier show_persistent.netsh : Netsh –f show_persistent.netsh Le fichier show_persistent.netsh est un fichier texte contenant les lignes suivantes : Pushd ipsec static Set store persistent show all exit Le script de commande Netsh suivant sert à supprimer toutes les stratégies persistantes : pushd ipsec static set store persistent delete all exit Stratégie IPSec locale La stratégie IPSec locale est prise en charge par Windows 2000, Windows XP et Windows Server 2003, et elle est stockée sous la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local Si une stratégie locale est attribuée, celleci sera stockée dans la clé de la manière suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Local\ActivePolicy Si aucune stratégie de domaine n'est attribuée, alors la stratégie locale attribuée sera ajoutée à une stratégie persistante configurée afin de devenir la stratégie active. Pour faciliter considérablement le dépannage, il est recommandé de modifier les stratégies IPSec créées par les scripts ipsecpol ou ipseccmd au moyen du composant logiciel enfichable MMC Gestion de stratégie IPSec afin de définir un nom pour chaque filtre avant de les utiliser dans des environnements de production. Vous pouvez aussi utiliser la commande netsh ipsec pour créer la stratégie sur un système Windows Server 2003, puis l'exporter vers un fichier compatible avec des systèmes Windows 2000 et Windows XP ou l'importer dans un domaine après que la stratégie aura été testée. Sous Windows 2000, utilisez la commande netdiag /test:ipsec /debug pour afficher les détails de l'attribution de la stratégie et la stratégie active. Vous devez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec ou les outils du registre pour supprimer les objets de la stratégie IPSec situés dans le magasin local. Pour forcer le rechargement de la stratégie IPSec attribuée, arrêtez puis redémarrez le service. Sous Windows XP, utilisez la commande ipseccmd show gpo ou netdiag /test:ipsec pour afficher les détails de l'attribution de la stratégie et la stratégie active. Utilisez le composant logiciel enfichable MMC Gestion de stratégie IPSec, les outils du registre ou la commande ipseccmd.exe w REG p "<policy_name>" –o pour supprimer la stratégie IPSec nommée. Pour supprimer facilement une stratégie locale, supprimez toutes les sousclés de l'emplacement de stockage précédemment référencé.
209
Pour obliger le service IPSec à recharger la stratégie, arrêtez le service IPSec, puis redémarrezle ou supprimez l'attribution de la stratégie IPSec, puis attribuezla de nouveau à l'aide du composant logiciel MMC Gestion de stratégie IPSec. Il est également possible d'utiliser la commande sc policyagent control 130 pour recharger la stratégie. Une fois la stratégie rechargée, toutes les associations de sécurité IKE et IPSec sont supprimées, ce qui peut entraîner des retards ou des interruptions de connectivité sur les ordinateurs qui utilisaient activement les SA IPSec pour transmettre et recevoir le trafic. Sous Windows Server 2003, utilisez la commande, netsh ipsec static show gpoassignedpolicy le composant logiciel enfichable MMC Gestion de stratégie IPSec ou le nœud Stratégie active du moniteur IPSec pour afficher la stratégie locale actuellement attribuée. Utilisez la commande netsh ipsec dynamic show all pour afficher la configuration de la stratégie active. Vous pouvez aussi utiliser le Moniteur IPSec pour inspecter différentes parties de la stratégie active. Pour supprimer puis recharger la stratégie locale sous Windows Server 2003, utilisez les mêmes commandes que celles répertoriées pour Windows XP. La commande netsh ipsec peut servir à supprimer l'attribution d'une stratégie, à l'attribuer de nouveau et à la supprimer. Stratégie IPSec Active Directory Cette stratégie est prise en charge par Windows 2000, Windows XP et Windows Server 2003. La stratégie IPSec de domaine attribuée est stockée dans le registre local à l'emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\GPTIPSECPolicy Le cache du registre local de la stratégie de domaine est stocké sous : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ IPSec\Policy\Cache Le magasin d'annuaire doit être géré par le composant logiciel enfichable MMC Gestion de stratégie IPSec ou par la commande netsh ipsec exécutée en tant que processus local dans Active Directory. Il n'existe aucun outil qui vous permette d'afficher directement le contenu du cache. Vous devez utiliser un outil du registre pour savoir si le cache existe et s'il possède le contenu approprié. De la même manière, les outils du registre servent à supprimer la stratégie de domaine en supprimant les clés de registre GPTIPSecPolicy et Cache. Ensuite, vous devez soit redémarrer le service IPSec, soit utiliser la commande de contrôle de services pour forcer le rechargement de la stratégie IPSec sans la stratégie de domaine. Pour actualiser l'attribution de la stratégie IPSec de domaine, recharger la stratégie IPSec et mettre à jour le contenu du cache, utilisez la commande gpudpate /force. Pour bloquer temporairement l'application de la stratégie de domaine à l'ordinateur local, vous pouvez configurer les autorisations sur les clés de registre GPTIPSecPolicy et Cache afin de refuser l'accès en lecture au compte système local. Le composant logiciel enfichable MMC Moniteur de sécurité IPSec et les outils de ligne de commande continueront à indiquer que la stratégie de domaine est attribuée car ces outils lisent les informations GPTIPSecPolicy exécutées dans le contexte de l'administrateur local. Pour un blocage à plus long terme de la stratégie IPSec basée sur le domaine, vous devez empêcher l'ordinateur de lire l'objet GPO approprié dans Active Directory.
210
Sous Windows 2000, vous pouvez rencontrer les erreurs suivantes en cas de problème lié à la stratégie :
• Impossible d'effectuer la liaison avec le schéma de l'annuaire. Le service Agent de stratégie
IPSec n'a pas pu effectuer de liaison LDAP authentifiée au conteneur de stratégies de sécurité IP Active Directory. Cette erreur est probablement apparue parce que le compte de l'ordinateur n'a pas réussi à se connecter et à obtenir les informations d'identification Kerberos, ou parce que le protocole Kerberos ne réussit pas à émettre le ticket du service LDAP pour le service Agent de stratégie IPSec.
• Impossible d'effectuer la liaison avec l'objet Stockage de stratégie IPSEC. Un objet a été
défini dans la stratégie IPSec (une règle ou une liste de filtrage, par exemple) qui n'existe pas. Il est possible que la stratégie IPSec ou la stratégie de stockage Active Directory soit corrompue, ou que l'objet ait été supprimé (bien que les stratégies IPSec existantes continuent à le référencer). Étudiez la stratégie IPSec en utilisant le composant logiciel enfichable MMC Gestion de stratégie IPSec pour voir si toutes les règles de la stratégie sont intactes et si les propriétés Échange de clés (de l'onglet Général) peuvent être affichées correctement.
• Impossible de trouver le contrôleur de domaine. Assurezvous que l'ordinateur est membre du domaine et vérifiez la connectivité réseau. Le module de stockage de la stratégie IPSec n'a pas réussi à trouver un annuaire LDAP à partir duquel extraire la stratégie IPSec basée sur le domaine.
• Impossible de communiquer avec le service d'annuaire sur le contrôleur de domaine.
Contactez votre administrateur système. Le module de stockage IPSec n'a pas réussi à utiliser les fonctions de signature et de scellement de LDAP pour télécharger la stratégie IPSec attribuée.
• Impossible de trouver l'objet dans l'emplacement de stockage. Cette erreur est généralement
grave, car elle signifie que la stratégie IPSec ne peut pas être extraite en totalité et donc ne fonctionnera pas correctement. Le module Stockage de la stratégie IPSec n'a pas réussi à trouver le GUID de l'objet (règle, liste de filtres, action de filtrage ou paramètres ISAKMP) contenu dans la stratégie IPSec ou l'une des règles en utilisant un appel LDAP ou un appel de registre distant. Cette erreur peut être provoquée par : • des retards de réplication au cours desquels l'objet « référençant » arrive avant l'objet référencé ou des requêtes sont dirigées vers deux contrôleurs de domaine différents ; • la suppression de l'objet alors qu'il était toujours utilisé par la stratégie IPSec ; • des autorisations qui ne permettent pas d'énumérer ou de lire l'objet, ou le stockage de la stratégie IPSec a été restauré à une heure antérieure à la création de l'objet ; • la corruption de la stratégie IPSec qui génère un GUID incorrect dans la requête ; • l'indisponibilité de la connectivité réseau pour l'adresse IP de destination ; • l'indisponibilité du service LDAP ou du registre distant.
• Impossible de terminer l'opération requise. Le stockage de stratégie n'est pas ouvert. Il est impossible d'ouvrir le magasin Active Directory, de l'ordinateur distant ou de l'ordinateur local. Cette erreur est généralement causée par un échec d'autorisation ou d'authentification.
• L'utilisation de la stratégie de registre local actif, du fait que (i) il n'y a pas de stratégie de stockage Active Directory ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache. Cet événement indique que la stratégie IPSec est définie localement sur l'ordinateur et que la stratégie de domaine n'a pas pu être appliquée pour la remplacer.
• N'utiliser aucune stratégie Ipsec, du fait que (i) il n'y a pas de stockage Active Directory ou de stratégie de registre local active ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache ou pas de stratégie de registre local active. Cet événement identifie l'état par défaut dans lequel aucune stratégie n'est attribuée à l'ordinateur.
211
Sous Windows XP et Windows Server 2003, les événements suivants indiquent que le service IPSec n'a pas réussi à retrouver un type de stratégie spécifique. Si une stratégie locale ne peut pas être lue sous Windows Server 2003 et Windows XP SP2, elle est ignorée et la stratégie attribuée suivante dans l'ordre de persistance est lue.
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage persistant sur l'ordinateur
pour <nomstratégie> avec le code d'erreur
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage locale sur l'ordinateur pour
<nomstratégie> avec le code d'erreur
• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage d'annuaire sur l'ordinateur
pour <nomstratégie> avec le code d'erreur
• Le moteur PAStore a effectué un sondage pour détecter des modifications apportées à la stratégie
IPSec Active Directory, a détecté que Active Directory est inaccessible et a migré vers l'utilisation de la copie mise en cache de la stratégie IPSec Active Directory. Toutes les modifications apportées à la stratégie IPSec Active Directory depuis le dernier sondage n'ont pas été appliquées. Ce message indique simplement qu'à un intervalle de sondage régulier, le service IPSec n'a pas réussi à contacter Active Directory (par exemple, en raison de la perte du service DNS) et qu'aucune modification n'a été apportée à la stratégie IPSec active. La connectivité à Active Directory était disponible à l'origine lorsque la stratégie active était appliquée et que le service IPSec avait extrait et stocké la version la plus récente dans le cache. Par conséquent, le service IPSec considère à présent le cache du registre de la stratégie de domaine IPSec comme la source principale de stratégie. Le sondage en vue de contacter l'annuaire va continuer.
Dépannage de l'interprétation de la stratégie IPSec L'interprétation de la stratégie IPSec a lieu après l'extraction de la stratégie complète de l'emplacement de stockage approprié. Les adresses IP actuelles de l'interface réseau sont utilisées pour développer les filtres génériques de la stratégie en filtres spécifiques. Ensuite, la liste des filtres entrants et sortants spécifiques est chargée dans le pilote IPSec en vue du traitement des paquets. Les événements de modification de l'interface sont signalés au service IPSec, qui ajuste la configuration du filtre IPSec dans le pilote IPSec aussi rapidement que possible, si nécessaire (par exemple, pour les filtres Mon adresse IP). Sous Windows 2000, les messages suivants peuvent indiquer un problème d'interprétation ou de configuration des composants IPSec pour appliquer la stratégie :
• L'attribut Type de données spécifie un format de données non reconnu. Une partie de la
stratégie IPSec contient un format de données que le moteur de stockage de la stratégie ne reconnaît pas. Cette erreur est le signe d'une corruption de la stratégie ou peut indiquer un problème futur de version de la stratégie. Les fonctions de la stratégie IPSec de Windows XP et Windows Server 2003 sont conçues pour être transparentes pour l'Agent de stratégie IPSec de Windows 2000.
212
• Impossible de lire des données à partir du blob. Le format de données de l'attribut IPSecData dans un objet de stratégie IPSec ne correspond pas au format prévu. Cette erreur indique pratiquement toujours une corruption de la stratégie ou un problème de version. Vous devez la corriger avant de pouvoir appliquer tous les paramètres de la stratégie IPSec comme vous le souhaitez.
• L'Agent de stratégie n'a pas de liste d'interfaces. L'Agent de stratégie n'a pas trouvé d'interface réseau IP à filtrer. Notez que l'erreur dans le texte de ce message provient directement du code source Windows, et elle apparaîtra de la manière illustrée ici.
• L'Api d'aide publique Ip n'a pas pu obtenir la table d'interfaces. Les filtres basés sur les
interfaces ne seront pas étendus et connectés au pilote Ipsec. Une erreur s'est produite lorsque l'Agent de stratégie a tenté d'énumérer la liste des interfaces de l'ordinateur. Il est possible qu'il n'y ait pas d'interface réseau ou qu'il existe une erreur dans le gestionnaire des interfaces réseau. Des périphériques qui ne sont pas complètement compatibles PnP, la corruption des fichiers ou des problèmes liés au pilote NIC ou à d'autres composants réseau de Windows peuvent être à l'origine de cette erreur : les filtres IPSec basés sur le type d'interface, comme ceux configurés dans une règle pour un type de connexion particulier (l'accès à distance, par exemple) plutôt que pour toutes les connexions. Si le problème persiste après le redémarrage de l'ordinateur, contactez les services de support technique Microsoft.
• L'Api d'aide publique Ip n'a pas pu obtenir la table d'adresse IP. Les filtres basés sur les interfaces ne seront pas étendus et connectés au pilote Ipsec. Une erreur s'est produite lorsque l'Agent de stratégie IPSec a tenté d'énumérer toutes les adresses IP de l'ordinateur en utilisant un appel de fonction de l'API de l'application d'assistance IP. Il est possible qu'aucune adresse IP ne soit configurée ou qu'il existe des problèmes semblables à ceux mentionnés ci dessus.
• L'index d'entrée de l'adresse IP n'a pas été trouvé dans la table d'interfaces. Rejet de
l'adresse IP. L'Agent de stratégie IPSec confirme que toutes les adresses IP apparaissent dans la liste des interfaces réseau. Ce problème est dû à des conditions passagères lorsqu'une nouvelle interface réseau est ajoutée ou supprimée. Ce message indique que le service IPSec ne va pas créer de filtres spécifiques pour cette adresse IP rejetée, pour les filtres génériques Mon adresse IP de la stratégie, ce qui pourrait apparaître comme un comportement de connectivité inattendu lors de l'utilisation de cette adresse IP. Cette erreur peut également révéler un problème de l'état interne de la configuration de l'interface IP que les services de support technique Microsoft devront examiner en détail. Puisque l'adresse IP est rejetée par l'Agent de stratégie IPSec (non par la pile TCP/IP), aucun filtre IPSec ne sera créé pour cette adresse IP. Ainsi, aucune action de sécurité (de type autoriser ou bloquer, par exemple) et aucune négociation des associations de sécurité IPSec ne sera réalisée pour le trafic au moyen de cette adresse IP.
• Un miroir de filtre correspondant existe dans la liste des filtres. Cette erreur signale une
condition de filtre dupliqué dans la stratégie IPSec. Vous devez analyser la conception de la stratégie IPSec pour vous assurer que les filtres spécifiques au mode rapide pour les directions entrante et sortante ne sont pas dupliqués.
• Aucun filtre n'a été ajouté à la liste de filtres principale. L'Agent de stratégie IPSec n'a trouvé
aucun filtre dans la stratégie IPSec extraite du stockage. Il est possible que celleci contienne uniquement la règle de réponse par défaut ou que des erreurs soient survenues lors de la lecture des règles ou des listes de filtrage.
• Zéro offre pour la phase 1. Rejet de la stratégie ISAKMP. Si aucune méthode de sécurité en mode principal IKE n'a été trouvée (objets de stratégie ISAKMP), cela signifie que la stratégie IPSec est probablement corrompue.
• Zéro offre pour la phase 2. Rejet de la stratégie de négociation. Sans aucune méthode de
sécurité dans l'action de filtrage (offres de la phase 2 du mode rapide IKE), IKE ne réussira pas les négociations en mode rapide pour le trafic adapté aux filtres correspondants. La stratégie IPSec est probablement corrompue. 213
• La stratégie ne contient pas d'offres valides. La stratégie IPSec ne contient aucune méthode de sécurité valide dans l'action de filtrage d'une règle ou ne contient aucun paramètre pour le mode principal IKE (paramètres Échange de clés configurés sous l'onglet Général).
• L'Agent de stratégie a tenté d'insérer un filtre existant dans IPSEC. Le pilote IPSec a détecté
un filtre dupliqué et rejette le doublon. Cette situation est sans conséquence si le filtre dupliqué possède la même action que celui déjà traité par le pilote IPSec. Toutefois, si les actions des filtres sont différentes, la conception de la stratégie IPSec n'est pas prise en charge. Les résultats peuvent différer après une période donnée et dépendent de l'ordre dans lequel le changement de stratégie est traité. La stratégie IPSec doit être conçue de manière à éviter les filtres dupliqués.
• Impossible d'ajouter une entrée à la table de stratégies IPSEC. L'Agent de stratégie IPSec n'a pas réussi à ajouter un nouveau filtre au pilote IPSec. Cette erreur signifie que tout le trafic correspondant à ce filtre ne sera pas sécurisé. Elle peut avoir pour origine une condition de mémoire noyau faible. Si l'erreur persiste, contactez les services de support technique Microsoft.
• L'Agent de stratégie n'a pas pu insérer ou mettre à jour un filtre dans IPSEC. Comme pour le message précédent sur l'ajout d'un filtre, la liste des filtres du pilote IPSec ne correspond pas aux besoins de la stratégie IPSec appliquée. C'est pourquoi le niveau de sécurité offert n'est pas approprié.
• L'utilisation de la stratégie de cache, en tant que stratégie de stockage Active Directory n'a
pas pu être appliquée correctement (réseau non joignable, intégrité de la stratégie non valide, etc.). Lorsqu'une stratégie IPSec de domaine est attribuée, l'Agent de stratégie IPSec tente de lire la toute dernière stratégie depuis Active Directory en premier lieu. Ce message indique que l'Agent n'a pas pu extraire la stratégie IPSec du service d'annuaire et qu'il applique la stratégie de la dernière stratégie de domaine, mise en cache dans le registre.
Sous Windows Server 2003, les événements suivants indiquent qu'un problème d'interprétation de la stratégie IPSec a pu se produire. Dans la plupart des cas, Windows XP utilise le même texte d'événement. Ces problèmes doivent être résolus pour que la stratégie IPSec fonctionne correctement.
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage persistante sur l'ordinateur
pour <nomstratégie> avec le code d'erreur :
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage du Registre local sur
l'ordinateur pour <nomstratégie> avec le code d'erreur
• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage Active Directory sur
l'ordinateur pour le DN
• Le moteur PAStore n'a pas pu appliquer la copie mise en cache localement de la stratégie IPSec
de stockage Active Directory sur l'ordinateur pour <nomstratégie> avec le code d'erreur :
214
Il a maintenant rencontré au moins une erreur lors de l'application de la copie mise en cache de la stratégie de domaine attribuée à partir du registre local. Cette erreur peut signifier que le cache est corrompu ou que les autorisations sont incorrectes. Cette condition est grave car aucune stratégie de domaine n'a pu être appliquée, ce qui pourrait affecter la connectivité avec les autres membres du domaine d'isolation. La stratégie locale (si elle est définie) est la suivante dans l'ordre de priorité.
• Le moteur PAStore n'a pas pu appliquer certaines règles de la stratégie IPSec active
<nomstratégie> sur l'ordinateur avec le code d'erreur :
• Les services IPSec n'ont pas pu obtenir la liste complète des interfaces réseau de cet ordinateur.
Cela peut représenter un risque potentiel pour la sécurité de cet ordinateur car certaines interfaces réseau n'obtiendront peutêtre pas la protection telle qu'elle était voulue par les filtres IPSec appliqués. Exécutez le composant logiciel enfichable Moniteur IPSec pour diagnostiquer ce problème. Ce message remplace les différents messages de l'API de l'application d'assistance IP utilisés sous Windows 2000. Il s'agit d'une erreur bénigne si elle se produit lors de l'ajout et de la suppression d'interfaces ou lorsque l'état de la connexion change (quand un réseau sans fil n'est plus dans l'intervalle valide, par exemple). Elle est aussi sans importance si elle intervient durant une reprise après l'utilisation des modes Mise en veille ou Mise en veille prolongée et qu'une configuration d'interface réseau différente existe et est détectée au cours de l'étape de reprise.
Problèmes de configuration de la stratégie avec le réseau privé virtuel RRAS Comme nous l'avons mentionné dans la section consacrée au support de niveau 1 plus haut dans ce chapitre, le service RRAS est une source courante de conflits avec la stratégie IPSec dans certaines entreprises. Cette section explique pourquoi la stratégie IPSec intégrée aux serveurs VPN L2TP/IPSec crée un conflit avec la stratégie de domaine utilisée dans cette solution. Cette situation décrit le problème d'un filtre dupliqué. Dans la discussion suivante, la conception de la stratégie IPSec utilisée dans le scénario Woodgrove Bank est utilisée pour illustrer les problèmes. Toutefois, les principes s'appliquent à de nombreux déploiements d'IPSec en entreprise. La stratégie IPSec pour les serveurs L2TP/IPSec est automatiquement générée par le service du gestionnaire RAS (RASMAN) et comprend les filtres suivants :
• Depuis Toute adresse IP à Mon adresse IP, UDP, source 1701, dest N'importe laquelle (entrante) • Depuis Mon adresse IP à Toute adresse IP, UDP, source N'importe laquelle, dest 1701 (sortante) Remarque : pour plus d'informations sur cette stratégie, reportezvous à l'article 248750 de la Base de connaissances, Description of the IPSec policy created for L2TP/IPSec (Description de la stratégie IPSec créée pour L2TP/IPSec) à l'adresse http://support.microsoft.com/?kbid=248750. Par conséquent, le filtre spécifique au mode principal qui contrôle la réponse de la négociation IKE à ce serveur est l'adresse du filtre entrant :
• Depuis Toute adresse IP à Mon adresse IP > Authentification par certificat Notez que l'utilisation de Mon adresse IP provoque le développement du filtre entrant pour chaque adresse IP du serveur VPN. En supposant que le serveur VPN possède une adresse IP d'interface
215
externe pour la connectivité Internet et une interface interne pour la connectivité LAN, les filtres entrants spécifiques au mode principal IKE sont :
• Depuis Toute adresse IP à
• Depuis Toute adresse IP à Sousréseau > Authentification Kerberos Par conséquent; lorsqu'un administrateur utilise un client approuvé pour gérer le serveur VPN, il initie IKE pour l'adresse IP interne du serveur VPN. La recherche de stratégie IKE entrante correspondra au filtre plus spécifique du mode principal et répondra avec les paramètres du mode principal IKE pour L2TP. L'authentification par certificat sera utilisée à la place de l'authentification Kerberos utilisée pour cette solution. Un second cas de conflit peut survenir si le client VPN Internet utilise les fonctions de mise en quarantaine du client Gestionnaire de connexion. Ce client doit transmettre une « clé de quarantaine » à l'adresse IP LAN interne du serveur VPN pour mettre fin à la quarantaine et obtenir l'accès VPN total au réseau. Dans ce scénario, la stratégie IPSec de domaine du client VPN est appliquée à partir du cache lorsque le portable démarre. Lorsque la connexion de quarantaine VPN est établie, une adresse IP interne est attribuée au client VPN. L'adresse IP interne du client peut être dissimulée par l'un des filtres de sousréseau (N'importe lequel <> Sousréseau interne) défini dans la stratégie IPSec de l'isolation de domaines. Ce filtre est requis pour que les clients VPN disposent d'un accès authentifié par IPSec de bout en bout via le tunnel VPN aux serveurs internes et aux autres stations de travail auxquelles ils accèdent. Cependant, les filtres de sousréseau de cette solution initient une négociation IKE à partir de l'adresse IP interne de l'interface virtuelle du tunnel VPN du client vers l'interface LAN interne du serveur VPN. Le mode principal IKE échouera car le serveur répondra pour accepter uniquement l'authentification par certificat, laquelle n'est pas compatible avec la stratégie utilisée pour l'isolation de domaines et de serveurs. Même si la stratégie n'a pas permis l'authentification par certificat, le mode rapide IKE du client proposera le filtre pour tout le trafic, et le serveur VPN échouera la négociation car le filtre proposé est trop général. Le serveur VPN n'acceptera que les filtres en mode rapide spécifiques à L2TP : UDP source 1701, destination N'importe laquelle ou UDP source 1701, destination 1701. Vous pouvez utiliser les options suivantes pour résoudre le conflit entre la stratégie L2TP/IPSec du serveur RRAS et la stratégie d'isolation.
• Ajoutez les adresses IP LAN internes du serveur RRAS à la liste d'exemptions. • Désactivez les ports L2TP sur les serveurs VPN. Utilisez uniquement les ports PPTP (Point to Point Tunneling Protocol, Protocole de tunnel point à point).
• Désactivez la stratégie IPSec automatique pour L2TP en utilisant la clé de registre ProhibitIPSec
pour RASMAN. Personnalisez manuellement la configuration de la stratégie IPSec pour L2TP afin qu'elle utilise uniquement l'adresse IP externe pour l'authentification par certificat pour le trafic UDP 1701 et uniquement l'adresse IP interne pour l'authentification Kerberos pour le trafic d'isolation de domaines.
Remarque : pour plus d'informations sur cette configuration, reportezvous à l'article 240262 de la Base de connaissances How to Configure a L2TP/IPSec Connection Using Preshared Key
216
Authentication (Comment faire pour configurer une connexion L2TP/IPSec en utilisant l'authentification par clé prépartagée) à l'adresse http://support.microsoft.com/kb/240262. La solution la plus simple de cette liste est la première, qui exempt la carte réseau interne du serveur RRAS d'utiliser IPSec.
Dépannage d'IKE L'échec d'IKE et d'IPSec lors du déploiement initial est principalement dû au filtrage réseau qui n'autorise pas les paquets du protocole UDP 500 ou IPSec. C'est pourquoi il est utile d'établir une station de travail IP ou un serveur IP statique pour les tests de stratégie simple, comme dans l'exemple de la stratégie prédéfinie de serveur (requête) qui utilise une clé prépartagée. L'audit doit être activé pour capturer les événements d'audit IKE. Une stratégie IP de domaine par défaut est déployée pour tous les membres de domaine qui s'authentifient avec la même clé prépartagée et contient une règle avec un filtre pour la totalité du trafic (y compris ICMP) pour tester l'adresse IP de l'ordinateur. Ensuite, le script de connexion est déployé pour exécuter une requête ping
Sous Windows XP SP2 et Windows Server 2003, vous pouvez activer et désactiver la journalisation d'IKE via la ligne de commande lorsque cela est nécessaire. Dans certaines situations, il est nécessaire d'arrêter puis de redémarrer le service IPSec afin d'étudier le trafic réseau et de capturer les résultats du fichier Oakley.log à partir d'un état sain. Lorsque le service IPSec est arrêté manuellement ou en tant que partie du redémarrage ou de l'arrêt de l'ordinateur, IKE tente d'envoyer des messages de suppression pour nettoyer l'état de l'association de sécurité IPSec sur tous les pairs connectés. Parfois, le système d'exploitation désactive la fonction d'envoi des paquets avant qu'IKE ait terminé l'envoi des messages de suppression à tous les ordinateurs pairs actifs ; ainsi, l'ordinateur pair conserve l'état de l'association de sécurité IPSec. Lorsque cela se produit, l'ordinateur pair peut « penser » qu'il est connecté de façon sécurisée à l'ordinateur redémarré. Après le redémarrage, si l'ordinateur n'initie pas une nouvelle négociation IKE avec le pair, ce dernier devra patienter cinq minutes pour que les associations de sécurité IPSec soient hors délai avant de tenter de les rétablir. Pour rétablir les associations de sécurité, une négociation en mode rapide est d'abord tentée pendant une minute, suivie d'une initiation en mode principal IKE. La journalisation IKE a été améliorée dans toutes les versions à partir de Windows 2000. Les événements documentés dans cette section s'appliquent à Windows XP et à Windows Server 2003, bien que les événements Windows 2000 soient similaires. Le journal de sécurité Windows est recommandé comme point de départ lorsque vous essayez de déterminer la raison d'un échec de négociation IKE. Pour afficher les événements IKE, l'audit des échecs et des succès doit être activé dans le paramètre de la stratégie de sécurité de groupe Auditer les événements de connexion. Une fois que l'audit est activé, le service IKE crée des entrées d'audit et offre une explication à l'échec de la négociation. Toutefois, l'explication des échecs de la négociation IKE est pratiquement toujours signalée comme un échec de l'événement 547, et il peut exister plusieurs causes possibles pour le même message d'erreur. La liste des échecs de l'événement 547 et les causes potentielles sont décrites en détail dans les sections suivantes. Sous Windows XP SP2 et Windows Server 2003, vous pouvez désactiver tous les audits IKE grâce à la clé de registre DisableIKEAudits. Pensez à vérifier cette valeur sur les ordinateurs contrôlés. Vous pouvez désactiver les audits IKE lorsque ceuxci génèrent trop d'événements de succès ou d'échec et que cela empêche les événements de la catégorie connexion/déconnexion d'être contrôlés de façon efficace. Les valeurs du code d'erreur sont souvent signalées dans les événements d'audit IKE et les détails du journal. Vous trouverez une description de ces valeurs dans Microsoft MSDN®, à la page System Code Errors (1200015999) (Erreurs du code système (1200015999)) à l'adresse http://msdn.microsoft.com/library/enus/debug/base/system_error_codes__1200015999_.asp. Le dépannage de la négociation IKE requiert une connaissance approfondie du comportement attendu de la conception de la stratégie IPSec, du processus de négociation IKE et des événements d'échec IKE. Cette section décrit uniquement les événements les plus courants associés au scénario d'isolation de domaine Woodgrove Bank. Elle ne traite pas tous les événements d'audit IKE ni toutes les conditions d'échec. Une fois que le processus de négociation IKE est bien compris, un suivi réseau depuis au moins un côté de la communication doit être obtenu (si possible) afin d'identifier les problèmes liés à IKE avant de tenter de remplir un fichier Oakley.log. Dans des scénarios d'isolation de serveurs et de domaines, les serveurs déployés doivent disposer de la possibilité d'effectuer un suivi à l'aide du Moniteur réseau. Le fichier Oakley.log propose la journalisation la plus détaillée possible et peut être requis par les deux côtés de la négociation (avec des heures synchronisées). Cependant, si vous activez ce fichier
218
journal, la négociation IKE risque d'être ralentie, ce qui va modifier les conditions de synchronisation et entraîner la perte de l'état existant si le service est redémarré pour lire de nouveau la clé de registre (requis sous Windows 2000 et Windows XP SP1). À l'heure actuelle, il n'existe pas d'instructions publiées permettant d'interpréter le fichier Oakley.log. Dans ce guide, cette interprétation est considérée comme partie intégrante de l'ensemble des compétences de niveau 3. En raison de contraintes liées à l'espace, les extraits issus des détails du journal fournis ici ne concernent que quelques erreurs. Pour obtenir de l'aide sur l'interprétation du fichier Oakley.log, contactez les services de support technique Microsoft. Les quatre fichiers journaux suivants sont créés pour IKE :
• Oakley.log. Journal actuel d'IKE, limité à 50 000 lignes. • Oakley.log.bak. Une fois que le fichier Oakley.log contient 50 000 lignes, ce fichier est créé et un nouveau fichier Oakley.log vide est utilisé. Ce fichier continue à être écrasé autant de fois que nécessaire par le nouveau fichier Oakley.log tant que le service IPSec est exécuté.
• Oakley.log.sav. Le fichier Oakley.log précédent est enregistré sous ce nom lorsque le service IPSec démarre.
• Oakley.log.bak.sav. Le fichier Oakley.log.bak précédent est enregistré sous ce nom lorsque le service IPSec démarre.
Au cours des opérations de dépannage, il arrive fréquemment que l'heure des deux ordinateurs sur lesquels sont effectués la journalisation et le suivi réseau ne soit pas synchronisée. Cette erreur rend la corrélation des journaux difficile, mais pas impossible. La corrélation entre les messages IKE et les paquets du suivi réseau doit faire l'objet d'une vérification croisée à l'aide des cookies d'entête ISAKMP et des champs d'ID de message en mode rapide IKE. Comportements IKE attendus Si l'initiation du mode principal IKE ne peut pas contacter l'adresse IP de destination souhaitée en raison d'un blocage réseau, la communication sécurisée par IPSec ne peut pas être négociée. Si l'initiateur n'est pas configuré pour la communication en texte clair, alors l'échec du contact de la destination apparaîtra en tant qu'événement d'audit 547 dans le journal de sécurité avec l'une des entrées de texte suivantes :
• Pas de réponse du pair • Le délai d'attente a expiré pour la négociation. • SA IKE supprimée avant que l'établissement ait été terminé Cependant, pour les clients d'isolation de domaines, il est possible que cette condition n'apparaisse pas comme un échec si leur stratégie autorise la communication en clair. Un événement 541 de succès en mode principal IKE est créé lorsqu'une association de sécurité logicielle est établie. Vous savez qu'un événement 541 affiche une SA logicielle lorsque le SPI sortant est égal à zéro et que tous les algorithmes sont affichés sous la forme Aucun. L'exemple suivant montre comment ces paramètres apparaissent dans un événement 541 : ESP Algorithm None HMAC Algorithm None AH Algorithm None Encapsulation None InboundSpi 31311481 (0x1ddc679) OutBoundSpi 0 (0x0) Lifetime (sec) <whatever is configured for QM lifetime>
219
Lifetime (kb) 0 Remarque : les événements des SA logicielles vers la même adresse IP de destination porteront des dates différentes et des valeurs SPI entrantes différentes. Des délais de connectivité d'une minute sont observés chaque fois que deux ordinateurs ne sont plus synchronisés parce qu'un mode principal IKE actif existe peutêtre entre eux. Des délais de cinq minutes peuvent être observés si l'un des ordinateurs considère qu'il existe une paire d'associations de sécurité IPSec active entre eux et que l'autre ordinateur (un serveur, par exemple) a supprimé ces associations de sécurité et n'est pas en train d'initier une recomposition en mode rapide. Windows 2000 IKE prenait en charge des messages de suppression uniques qui étaient parfois perdus. Windows XP et Windows Server 2003 disposent d'une prise en charge fiable de la fonction de suppression sous la forme de messages de suppression multiples qui agissent comme une mesure de protection contre les paquets abandonnés. Cette situation type se produit lorsque l'utilisateur d'un portable d'isolation de domaine retire l'ordinateur de la station d'accueil pour se rendre à une réunion. La station d'accueil possède une connexion Ethernet filaire, et le fait de retirer cette interface réseau nécessite le retrait de tous les filtres qui lui sont associés (s'il s'agit de filtres développés à partir de Mon adresse IP). Toutefois, aucun filtre ayant une action de négociation n'utilise Mon adresse IP dans la solution d'isolation de domaines ; il s'agit de filtres de type N'importe lequel <> Sousréseau. Par conséquent, les états de l'association de sécurité IPSec et de l'association de sécurité IKE restent actifs sur le portable car ces filtres ne sont pas supprimés lors des changements d'adresse. Si les filtres avaient été développés depuis Mon adresse IP, ils auraient été supprimés au moment de la disparition de l'adresse IP. Chaque fois qu'un filtre de type N'importe lequel est supprimé du pilote IPSec, ce dernier informe IKE que toutes les associations de sécurité IKE et IPSec utilisant cette adresse IP doivent également être effacées. IKE tentera d'envoyer des messages de suppression pour ces SA, puis les supprimera de façon interne. Ces messages de suppression auront la même adresse IP source que celle utilisée pour les SA IKE, même s'il est possible qu'une autre adresse IP source soit présente sur l'interface connectée au moment de l'envoi du message de suppression. L'adresse IP source n'est pas importante pour l'ordinateur distant si la paire de cookies d'entête ISAKMP est reconnue et que les vérifications cryptographiques du paquet sont valides. Cependant, il arrive fréquemment que les messages de suppression ne soient pas envoyés car il n'y a pas de connectivité réseau dans les secondes suivant la déconnexion (retrait du portable). Dans le cas particulier de filtres N'importe lequel <> Sousréseau, les filtres ne sont jamais supprimés, ce qui signifie que les associations de sécurité IKE et IPSec ne sont pas immédiatement supprimées. Pendant ce temps, les SA IPSec expirent sur les ordinateurs distants auparavant connectés, et les messages de suppression en mode rapide IKE sont envoyés à l'adresse précédente du portable. Les SA en mode rapide IKE continuent à exister pendant 8 heures (par défaut) sur ces ordinateurs distants, mais peuvent être effacées à tout moment avant l'expiration de ce délai pour des raisons IKE internes. Bien entendu, les messages IKE de suppression des SA ne parviennent plus à l'ancienne adresse IP du portable. Lorsque le portable est finalement reconnecté à la station d'accueil, il reçoit de nouveau la même adresse IP. Les applications de partage de fichiers, clients de messagerie et autres se reconnectent généralement aux mêmes destinations. Cependant, il est maintenant possible qu'il existe une différence d'état IKE entre le portable et ces destinations distantes. Si le portable dispose toujours d'un mode principal IKE, il tentera de négocier en mode rapide IKE. Le mode rapide utilise un état cryptographique que le pair distant a supprimé, c'est pourquoi il ne reconnaît pas ces messages et n'y répond pas. Sur le portable, le nombre maximal de tentatives arrive à expiration au bout d'une minute ; IKE tente alors une nouvelle négociation en mode principal qui cette fois réussit. Par conséquent, l'utilisateur du portable peut remarquer un délai d'une minute lorsqu'il se reconnecte aux ressources distantes. Microsoft s'attache à améliorer ce
220
comportement dans les futures mises à jour de toutes les versions de Windows prenant en charge IPSec. La négociation IKE peut signaler l'expiration d'un délai pour diverses raisons. L'événement « Le délai d'attente a expiré pour la négociation » survient lors de l'échec des étapes de la négociation IKE (excepté l'étape de communication en clair) en raison de l'expiration du nombre limite de tentatives, sauf lorsque IKE termine la négociation par un événement « SA IKE supprimée avant que l'établissement ait été terminé ». Ces deux événements sont pratiquement identiques. Ils sont souvent courants, bénins et attendus au cours du fonctionnement normal des clients mobiles, qui modifient fréquemment et rapidement les états de la connectivité réseau lorsque les événements suivants se produisent :
• Les utilisateurs insèrent et retirent les ordinateurs portables des stations d'accueil. • Les utilisateurs débranchent une connexion filaire. • Les ordinateurs portables sont en mode de veille ou de veille prolongée. • La plage attribuée à la connexion sans fil est dépassée. • Une connexion VPN est déconnectée. • Une carte réseau PCMCIA est éjectée alors qu'elle est connectée. Pour un ordinateur distant, ces événements donnent l'impression que le pair vient de se déconnecter du réseau. L'ordinateur distant va tenter de recomposer ou de renégocier jusqu'à ce que le délai de négociation IKE expire. Les échecs dus à l'expiration de la durée de négociation ont été améliorés dans Windows Server 2003 dans le but d'identifier le moment de la négociation IKE où le délai d'expiration a lieu par l'identification de la dernière étape réussie de la négociation. Ces événements peuvent également être provoqués par la traduction des adresses réseau (Network address translation, NAT) lorsque IKE négocie sans les fonctions NATT. Cependant, le délai de négociation IKE expire aussi si le pair distant rencontre un problème qui entraîne l'échec de la négociation IKE. Ainsi, dans tous les cas d'expiration des délais de négociation et d'apparition d'événements « SA IKE supprimée avant que l'établissement ait été terminé », le support de niveau 2 doit identifier si l'ordinateur distant est responsable de l'échec en vérifiant les événements 547 d'audit des échecs sur cet ordinateur jusqu'à la minute précédant l'enregistrement de l'expiration du délai par IKE. Événements de succès de la négociation IKE Si la négociation IKE réussit, les SA en mode principal IKE s'affichent dans le composant logiciel enfichable Moniteur IPSec et via les outils d'interrogation de la ligne de commande. Pour afficher la liste des associations de sécurité actives en mode principal IKE
• Sous Windows 2000 : ipsecmon.exe, netdiag /test:ipsec /v Remarque : cette commande affiche uniquement les associations de sécurité IPSec, et non les associations de sécurité en mode principal IKE.
• Sous Windows XP : IPSec monitor snapin, ipseccmd show sas
221
• Sous Windows Server 2003 : Remarque : la ligne a été divisée en plusieurs lignes pour des raisons de lisibilité. Cependant, lorsque vous entrez cette commande dans un système, veillez à l'entrer sur une seule ligne. IPSec monitor snapin, netsh ipsec dynamic show [mmsas | qmsas] Les SA réussies en mode principal et en mode rapide génèrent les événements suivants dans le journal de sécurité si l'audit est activé.
• 541. Mode principal IKE ou mode rapide IKE établi • 542. Mode rapide IKE supprimé • 543. Mode principal IKE supprimé Messages d'information du journal en mode principal IKE Pour déterminer s'il existe un problème d'échange du mode principal, recherchez les événements consignés suivants dans les journaux des événements des ordinateurs : Tableau 7.5 : Messages d'information du journal en mode principal IKE Texte du journal
Description
La nouvelle stratégie a invalidé les SA formés avec l'ancienne stratégie
Message de Windows 2000 indiquant que la modification d'une stratégie IPSec a entraîné la suppression des associations de sécurité IKE ou IPSec actuelles. Cette erreur est sans conséquence. Les nouvelles associations de sécurité IPSec seront formées selon le flux de trafic actuel qui utilise la nouvelle stratégie IPSec.
IKE a un grand nombre de requêtes d'établissement d'association de sécurité en attente, et démarre le mode de prévention de refus de service.
Cette condition peut être normale, causée par une surcharge de l'ordinateur, et/ou un grand nombre de tentatives de connexions client. Cela pourrait également être le résultat d'une attaque de refus de service contre IKE. Si tel est le cas, il y aura plusieurs audits de négociations IKE ayant échoué vers des adresses IP factices. Dans le cas contraire, cela signifie simplement que l'ordinateur est extrêmement surchargé.Ce message indique que IKE pense avoir été submergé de requêtes d'établissement de SA en mode principal IKE. La stratégie de réponse à l'attaque de refus de service va consister pour IKE à rejeter la plupart de ces requêtes.
IKE ne subit plus le mode de prévention de refus de service et a repris un fonctionnement normal.
IKE a récupéré après ce qu'il considérait comme une condition d'attaque de refus de service, et a repris un fonctionnement normal.
La présence de ces entrées n'indique pas un échec de communication. Il s'agit de données informatives qui peuvent servir à fournir des informations supplémentaires en vue de déterminer la vraie cause d'un problème. Événements 547 relatifs à l'échec de la négociation en mode principal IKE
222
Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode principal IKE échoue :
• Pas de réponse du pair. Cet événement est attendu pour les connexions sortantes aux
ordinateurs qui n'utilisent pas IPSec et qui ne sont pas membres de la liste d'exemption. Toutefois, le support de niveau 2 doit être conscient des problèmes de connectivité qui bloquent la négociation IKE, qui génèrent également cet événement.
• Aucune stratégie configurée. Cet événement signale un problème si l'adresse IP source est
située dans les sousréseaux internes ou signale la présence d'un jeu de filtres incompatible. Il peut être prévu que les ordinateurs n'aient pas de règle pour négocier avec certaines plages d'adresses ou sousréseaux. Les ordinateurs de ces sousréseaux peuvent tenter une initiation IKE, mais n'obtiendront aucune réponse car aucune stratégie n'est configurée.
• Les attributs de sécurité IKE ne sont pas acceptables. Cet événement ne doit pas se produire
sur les systèmes correctement configurés. Réalisez les procédures de la section Vérification de la stratégie IPSec appropriée pour trouver l'origine du problème.
Les messages d'expiration de délai suivants peuvent être attendus pour les raisons mentionnées précédemment. Ils peuvent également indiquer que l'ordinateur distant a échoué la négociation IKE. En général, le support de niveau 2 se concentre sur la recherche des causes de l'échec IKE sur l'ordinateur distant, plutôt que sur l'expiration des délais de négociation (très fréquente sur les ordinateurs déconnectés) et sur l'incompatibilité de la conception de la stratégie dans laquelle le répondeur à une négociation en mode principal IKE ou en mode rapide IKE ne trouve pas de filtre spécifique correspondant à la requête entrante.
• Le délai d'attente a expiré pour la négociation. • Le délai d'attente a expiré pour la négociation. Première charge utile (SA) traitée. Répondeur durée Delta 63.
• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Initiateur durée Delta 63.
• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Répondeur Échecs d'audit en mode rapide IKE (547) Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode rapide IKE échoue :
• Aucune stratégie configurée. Troisième charge utile (ID) traitée. Initiateur • Échec de la négociation d'association de sécurité dû à la non correspondance d'attributs. • Erreur de traitement générale. • Impossible d'obtenir un nouveau SPI pour la SA entrante à partir du pilote Ipsec. • Le pilote IPSEC n'a pas réussi la négociation Oakley avec car aucun filtre n'existe. • Impossible d'ajouter une association de sécurité au pilote IPSec. • Le délai d'attente a expiré pour la négociation. Le mode rapide IKE ne doit pas échouer pour les stratégies IPSec correctement conçues et les charges de travail ordinaires. Si vous recevez l'une de ces erreurs, le support de niveau 2 doit en premier lieu suivre les étapes de la section Vérification de la stratégie IPSec appropriée. Il doit ensuite
223
tenter d'établir une corrélation entre ces événements et des conditions de performances inhabituelles, comme une utilisation à 100 % du processeur ou des conditions de mémoire du noyau très faibles. Notez que des échecs du mode rapide IKE avec expiration du délai de négociation seraient attendus si l'ordinateur n'utilisait plus sa précédente adresse IP pour l'une des raisons expliquées précédemment. Dépannage des échecs IKE provoqués par l'authentification Les messages suivants sont associés aux échecs de l'authentification IKE :
• La cible spécifiée est inconnue / Aucune autorité n'a pu être contactée pour l'authentification. • La cible spécifiée est inconnue ou inaccessible. Première charge utile (SA) traitée. Initiateur durée Delta 0.
• Les informations d'authentification IKE ne sont pas acceptables. • La tentative d'ouverture de session a échoué. • Échec de l'authentification dans l'utilisation de Kerberos. • IKE n'a pas trouvé de certificat ordinateur valide. Les deux premiers messages indiquent que l'identité Kerberos de l'ordinateur distant ne peut pas être utilisée pour obtenir un ticket de service pour l'ordinateur distant. Cette situation a pu se produire parce qu'il n'existe pas d'approbation de domaine ou parce que l'accès aux contrôleurs de domaine n'est pas disponible. Si une négociation IKE entrante échoue en raison des paramètres Accéder à cet ordinateur à partir du réseau, la négociation IKE depuis l'ordinateur chargé des droits d'accès signalera un événement 547 Échec de l'authentification dans l'utilisation de Kerberos, comme expliqué plus haut. Cet événement n'indique pas de manière spécifique que le problème est l'échec lorsque les paramètres Accéder à cet ordinateur à partir du réseau sont vérifiés ; c'est pourquoi vous devez obtenir le fichier Oakley.log du serveur pour rechercher l'erreur spécifique générée. L'appartenance de l'initiateur IKE à un groupe doit être vérifiée pour déterminer s'il fait partie d'un groupe autorisé. Si l'ordinateur fait partie d'un groupe disposant d'un accès, il est possible qu'il ne possède pas les tickets Kerberos reflétant son appartenance au nouveau groupe ou qu'il ne soit pas en mesure d'obtenir les tickets Kerberos adéquats. Complétez les procédures traitées dans la section Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine, plus haut dans ce chapitre.
Dépannage des problèmes liés aux applications Cette section explique pourquoi la conception des applications peut interagir avec l'utilisation d'IPSec sous Microsoft Windows. Le concepteur de la stratégie IPSec ainsi que le personnel du support doivent comprendre ces impacts afin de pouvoir aider à la classification et à l'identification rapide du problème. L'application de la stratégie IPSec doit être transparente pour les applications. Cependant, dans certaines circonstances où la stratégie IPSec est attribuée ou protège le trafic, l'application peut se comporter de manière inhabituelle. Les sections suivantes illustrent ces situations dans le contexte du scénario d'isolation de domaine Woodgrove Bank. ICMP autorisé, mais IPSec requis par les protocoles TCP et UDP Certaines applications utilisent un message de demande d'écho (Ping) ICMP pour déterminer si une adresse de destination est accessible. Par exemple, comme IPSec ne protège pas le trafic ICMP de cette solution, une application peut recevoir une réponse ICMP depuis une destination cible.
224
Cependant, l'application ne pourra peutêtre pas se connecter à la destination cible à l'aide du trafic TCP et UDP protégé par IPSec lorsque la négociation IKE échoue. Délai de connexion initial La négociation IKE nécessite davantage de traitement et plus de temps pour s'exécuter qu'un processus de connexion en trois étapes ou qu'un seul paquet de requête/réponse Nbtstat non authentifié. Les applications qui attendent une réponse de connexion TCP ou UDP rapide de la part de la destination cible peuvent considérer que la destination ne répond pas et entreprendre une autre action, comme signaler une erreur ou essayer de se connecter à une autre destination. Les négociations IKE à l'aide de l'authentification Kerberos réussissent généralement au bout d'une à deux secondes. Cependant, ce délai dépend de plusieurs facteurs, notamment l'utilisation du processeur sur les deux ordinateurs et la perte des paquets réseau. La communication en texte clair requiert toujours trois secondes avant d'autoriser l'envoi du premier paquet TCP non protégé. L'application se bloque en attendant la réponse du réseau Certaines applications sont conçues pour supposer que le délai de connexion ou de réception d'un message d'erreur est très bref. Ces applications attendent que la connexion soit effective (opération de liaison au socket terminée) avant d'afficher les modifications dans l'interface utilisateur. Lorsque le trafic de cette application est protégé par IPSec, l'application peut se bloquer brièvement lors de connexions réussies. Ce phénomène peut continuer jusqu'à ce que l'application soit fermée ou qu'elle rencontre d'autres erreurs inhabituelles si la connexion ne réussit pas en raison d'un échec de négociation IKE ou d'un filtre bloquant IPSec. La couche du socket réseau ne reconnaît pas les filtres IPSec et ne sait pas que IKE négocie la sécurité du trafic. L'application interprète généralement ces conditions comme une panne de l'hôte distant ou une défaillance du réseau. Cependant, les applications peuvent également interpréter les échecs de connexion aux contrôleurs de domaine par l'indisponibilité de l'ordinateur de destination ou le refus de la connexion. Traitement des paquets réseau en mode noyau affecté Les applications qui impliquent des pilotes réseau ou le traitement de paquets au niveau du noyau risquent de ne pas fonctionner correctement lorsque IPSec sécurise le trafic. Ces applications peuvent apporter des modifications au paquet, ce qui entraînera l'abandon du paquet par IPSec. Ou encore, l'application peut ne pas comprendre les modifications d'IPSec, ce qui peut se traduire par une erreur système (écran bleu). Analyse réseau de la part des hôtes d'un domaine d'isolation affectée Les outils hôtes qui tentent de sonder rapidement les adresses IP distantes ou les ports ouverts du réseau peuvent fonctionner beaucoup plus lentement si IPSec tente de sécuriser leur trafic. Le trafic destiné au sondage peut provoquer un refus de service sur l'hôte local en déclenchant l'initiation de centaines d'adresses IP par IKE en quelques secondes ou minutes. Certains outils basés sur SNMP dépendent de l'envoi d'événements d'interruption SNMP à des hôtes non approuvés qui agissent en tant que collecteurs d'événements. Même si IPSec est autorisé à utiliser les communications en clair, les paquets d'interruption SNMP sortants risquent d'être rejetés par le pilote IPSec avant que l'association de sécurité logicielle ne soit établie. De la même manière, certaines applications basées sur le protocole UDP (comme NTP et le localisateur de contrôleur de domaine Windows) attendent trois secondes seulement qu'une réponse soit reçue, ce qui entraîne l'échec de l'application ou des rapports erronés indiquant qu'une destination ne peut pas être contactée.
225
Problèmes liés au fournisseur de services superposés Winsock Certaines applications légitimes (comme les parefeu personnels) et malveillantes (comme les logiciels espions) peuvent causer des problèmes en insérant leurs propres fonctions d'inspection du trafic, appelées services superposés Winsock (LSP). Le composant IKE de l'implémentation Microsoft d'IPSec utilise une fonction API Winsock étendue dont le pointeur de fonction est déterminé par l'appel de WSAIoctl(). Si l'appel de cette fonction n'est pas autorisé à traverser les LSP installés, IKE ne peut pas contrôler les ports UDP requis. Sous Windows Server 2003, IPSec interprète cela comme une incapacité du composant à faire appliquer la stratégie de sécurité, et il réagit de façon défensive. La fonction Échec du mode sécurisé est appelée et le pilote IPSec est placé en mode de blocage. L'administrateur doit se connecter en utilisant une connexion de bureau pour pouvoir arrêter le service IPSec et restaurer la connectivité. Si le service IPSec ne répond pas à la requête d'interruption, il doit être configuré comme désactivé, et l'ordinateur doit être redémarré. Même si IKE a été correctement initialisé, la capacité de l'ordinateur à envoyer et à recevoir des protocoles IKE et IPSec peut être bloquée par le LSP ou un programme tiers. Pour le support de niveau 2, le dépannage du LSP Winsock consiste à identifier l'existence de LSP. Le support de niveau 3 doit ensuite mener d'autres investigations visant à identifier l'application qui a installé les LSP, puis à les organiser ou à les supprimer si le service IPSec ou IKE ne rencontre plus de difficulté. Outils permettant de détecter les fournisseurs de services superposés Winsock :
• Sporder.exe. Il s'agit d'une applet permettant d'afficher les LSP dans la partie Winsock 2.0 du kit de développement logiciel (Software Development Kit, SDK) de la plateforme Windows.
• Netdiag /debug. Clients tiers de réseau privé virtuel IPSec Des problèmes peuvent survenir lorsqu'une implémentation IPSec tierce est installée dans le cadre d'un client VPN d'accès à distance. En général, ces clients désactivent le service IPSec et n'entrent pas en conflit avec le service IPSec Windows natif. Toutefois, pour les membres du domaine approuvé de cette solution, le service IPSec natif est requis. C'est pourquoi les implémentations IPSec tierces peuvent créer des conflits pour les raisons suivantes :
• Les deux implémentations IKE ont besoin du port UDP 500. • Le traitement des paquets du noyau IPSec nécessite le protocole ESP pour les deux ordinateurs. • Les fonctions LSP Winsock sont installées dans le cadre du client. • La fonction de parefeu est fournie par le client VPN. • La superposition empêche les paquets IKE et IPSec natifs encapsulés d'être transmis via le tunnel IPSec tiers.
Les fournisseurs VPN permettent généralement de savoir si les VPN prennent en charge le service IPSec Windows natif activé et s'ils prennent en charge le trafic en mode transport protégé par IPSec de bout en bout via leur connexion d'accès à distance. Dans certains cas, la passerelle du fournisseur VPN prend en charge les clients VPN L2TP/IPSec et PPTP sous Windows 2000 et Windows XP. Les clients VPN Windows natifs sont compatibles avec le mode de transport IPSec de bout en bout via le tunnel VPN. Haut de page
226
Dépannage de niveau 3 Si le dépannage réalisé par le niveau 2 ne permet pas de résoudre un problème, un niveau d'expertise supplémentaire est requis pour analyser le problème et trouver une solution. Ce niveau d'expertise est appelé support de niveau 3. Dans plusieurs cas, ce support est fourni par des spécialistes IPSec contractuels ou des entreprises de support technique, comme les services de support technique Microsoft. Le support IPSec de niveau 3 requiert une connaissance approfondie du fonctionnement d'IPSec et de la pile TCP/IP de Microsoft. Les membres du personnel du support de niveau 3 ont besoin d'une formation avancée sur IPSec et son utilisation dans des scénarios d'isolation de serveurs et de domaines. Grâce aux compétences acquises, le personnel du support de niveau 3 peut devenir responsable de la formation du personnel technique des niveaux inférieurs et concevoir de la documentation d'assistance ; par exemple, des résumés techniques, des Livres blancs, des guides de maintenance, des questions fréquentes et des informations sur l'architecture IPSec et la classification. Le support de niveau 3 peut aussi être chargé d'élaborer et de documenter des plans de récupération d'urgence.
Intervention des services de support technique Microsoft Si les procédures de dépannage décrites dans ce chapitre ne vous aident pas à résoudre le problème ou si votre entreprise ne dispose pas des compétences requises pour utiliser les techniques de dépannage avancées, vous devrez peutêtre transférer le problème aux services de support technique Microsoft. Il est important de recueillir autant d'informations de diagnostic que possible, comme les fichiers journaux et les données de surveillance réseau avant de contacter les services de support technique. Utilisez cette liste pour réunir les informations nécessaires au support de niveau 3 ou aux services de support technique Microsoft pour analyser le problème :
• Conditions de sécurité requises pour l'authentification entrante et sortante et l'autorisation de chaque ordinateur. Vous devez disposer d'une brève description expliquant comment la configuration IPSec et la stratégie de groupe de l'ordinateur remplissent ces conditions.
• Diagramme représentatif du scénario, affichant le nom des ordinateurs source et cible, leur adresse IP au moment de la collecte des fichiers journaux et la version de leur système d'exploitation (y compris des informations sur le Service Pack). Pensez également à noter l'adresse IP des serveurs DNS, WINS et des contrôleurs de domaine.
• Suivi par le Moniteur réseau des communications de chaque côté pendant que la stratégie IPSec
est active, de préférence simultanément pour que les paquets puissent facilement être mis en corrélation dans les deux fichiers de suivi. Les suivis réseau doivent inclure tout le trafic entrant et sortant sur chaque ordinateur (si possible) pour que les demandes d'authentification, les recherches DNS et tout autre trafic associé puissent être identifiés. De même, si les communications échouent alors que la stratégie IPSec est active et qu'elles réussissent lorsqu'elle est désactivée ou que le service est arrêté, un suivi du trafic réseau lorsque IPSec est inactif doit également être disponible. Il est très important que l'heure du système soit synchronisée entre ces systèmes afin qu'il soit possible d'établir une corrélation entre les fichiers journaux et les fichiers de suivi.
• Sous Windows 2000, Windows XP et Windows Server 2003, exécutez
netdiag /debug >netdiagdebugcomputername.txt juste avant ou juste après la capture du suivi réseau. (Netdiag génère un trafic réseau important, qui n'a pas besoin de faire partie du suivi réseau.) Sous Windows XP et Windows Server 2003, exécutez également portqry v local >portqryvcomputername.txt.
227
• Les fichiers Oakley.log IKE de chaque côté de la communication sont collectés au moment où le
problème survient et au moment où les suivis du moniteur réseau sont enregistrés. Le nom de ces fichiers doit indiquer le nom de l'ordinateur. Si un client RAS ou VPN Windows est concerné, vous devez utiliser l'outil RASDIAG pour collecter les informations.
• Les journaux système, de sécurité et des applications complets de chaque ordinateur au moment où les fichiers Oakley.log et les fichiers de suivi réseau sont collectés.
• Tous les fichiers journaux spécifiques à la stratégie de groupe créés au moment où les fichiers Oakley.log et de suivi réseau sont capturés.
• Les détails de la stratégie IPSec de chaque ordinateur. Si les stratégies IPSec qui s'appliquent à
chaque ordinateur peuvent être facilement enregistrées, elles doivent être incluses. Cependant, la stratégie IPSec active de l'ordinateur est souvent une combinaison de plusieurs types de stratégies IPSec et pas uniquement une stratégie de domaine ou locale. Pour analyser la stratégie active d'un ordinateur, répertoriez les filtres spécifiques au mode principal IKE et les filtres spécifiques au mode rapide IKE à partir du composant logiciel enfichable MMC Moniteur IPSec.
Pour créer un fichier texte mis en forme à partir de ces filtres
1. Cliquez avec le bouton droit de la souris sur le nœud Filtres spécifiques du mode rapide IKE dans le volet gauche de l'arborescence.
2. Sélectionnez Exporter la liste. 3. Enregistrez le fichier texte délimité par des tabulations sous IKEqm<nomordinateur
spécifique>.txt ou sous une convention de dénomination similaire comprenant le nom de l'ordinateur.
Un fichier texte délimité par des tabulations comprenant tous les détails du filtrage peut être importé dans une feuille de calcul ou un document de traitement de texte. Haut de page
Résumé Ce chapitre vous a fourni des informations détaillées sur les processus qui aident le support de niveau 1 (support technique) et le support de niveau 2 (spécialistes informatiques du support réseau) à résoudre les problèmes de communication IPSec courants. Il est impossible de fournir des informations sur toutes les erreurs potentielles, car le fonctionnement d'IPSec et la sécurité réseau sont trop complexes pour permettre de répertorier toutes les variantes. Lorsque cela est possible, les développeurs de ce chapitre ont souligné les options possibles pour mettre l'accent sur les zones susceptibles de rencontrer des problèmes dans le type d'environnement d'isolation de serveurs et de domaines détaillé dans ce guide. Les exemples de scripts fournis dans ce guide ont été testés au cours de l'implémentation test du scénario Woodgrove Bank afin de prouver leur efficacité. Toutefois, ces scripts sont conçus pour être personnalisés en fonction des besoins d'une entreprise et ne sont donc pas pris en charge par Microsoft. Aux yeux du lecteur, le dépannage d'IPSec doit sembler techniquement complexe et requiert des compétences dans divers domaines technologiques autres qu'IPSec, comme les réseaux, Active Directory et les stratégies de groupe. Cependant, les informations fournies dans ce chapitre doivent permettre au lecteur de résoudre une grande partie des problèmes rencontrés, sauf les plus compliqués qui peuvent affecter la solution d'isolation de serveurs et de domaines.
228
Pour les lecteurs qui souhaitent développer leurs connaissances et entrer dans la catégorie du support de niveau 3, la section suivante répertorie d'autres sources de documentation qui pourront les occuper pendant quelques années !
Informations complémentaires • Pour obtenir des informations de base sur IPSec, reportezvous à la référence technique How IPSec Works de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/ WindowsServ/2003/all/techref/enus/w2k3tr_IPSec_how.asp
• Pour obtenir des informations détaillées sur la résolution des problèmes liés à TCP/IP, reportez vous aux références techniques suivantes :
• TCP/IP in Windows 2000 Professional
(TCP/IP sous Windows 2000 Édition Professionnel) à l'adresse www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en us/prork/prcc_tcp_slnb.asp
• Chapitre TCP/IP Troubleshooting
(Dépannage du protocole TCP/IP) du kit de ressources Windows XP à l'adresse www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en us/prcc_tcp_gfhp.asp
• How to troubleshoot TCP/IP connectivity with Windows XP (Dépannage de la connectivité TCP/IP sous Windows XP)
à l'adresse http://support.microsoft.com/?kbid=314067
• Windows Server 2003 TCP/IP Troubleshooting
à l'adresse www.microsoft.com/technet/prodtechnol/windowsserver2003/operations/system/tcpiptrb.mspx
Pour consulter l'aide en ligne et la documentation du kit de ressources concernant le dépannage d'IPSec sous Windows 2000, Windows XP et Windows Server 2003, reportezvous aux références suivantes :
• Basic IPSec troubleshooting in Microsoft Windows 2000 Server
à l'adresse
http://support.microsoft.com/?kbid=257225
• Microsoft Windows 2000 Advanced Documentation
(Documentation avancée de Microsoft Windows 2000) à l'adresse www.microsoft.com/windows2000/en/advanced/help/sag_ipsectrouble.htm?id=3352
• Basic L2TP/IPSec Troubleshooting in Windows XP
(Résolution élémentaire des problèmes liés à IPSec sous Windows XP) à l'adresse http://support.microsoft.com/?kbid=314831
• Aide de Windows Server 2003 – Troubleshooting tools
(Outils de dépannage) IPSec à l'adresse www.microsoft.com/technet//prodtechnol/windowsserver2003/proddocs/standard/ sag_ipsec_tools.asp?frame=true#iketrace_enable
• Diagramme de présentation de l'architecture dans le Livre blanc Windows 2000 TCP/IP
Implementation Details (Informations de l'implémentation TCP/IP) sous Windows 2000 à l'adresse www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/ tcpip_implement.asp
• Windows 2000 Network Architecture
(Architecture réseau sous Windows 2000), figure B.1 à l'adresse www.microsoft.com/resources/documentation/windows/2000/server/reskit/en us/cnet/cnad_arc_jypf.asp
229
• How TCP/IP Works
(Fonctionnement de TCP/IP) à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_tcpip_how.asp
• How IPSec Works
(Fonctionnement d'IPSec) à l'adresse WindowsServ/2003/all/techref/enus/w2k3tr_ipsec_how.asp
230
