Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe

Chapitre  5 : Création de stratégies IPSec pour les groupes d'isolation

Dernière mise à jour le 16-02-2005

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

Sur cette page

Connaissances préalables requises pour ce chapitre
Création de stratégies IPSec dans Active Directory
Autorisation de l'accès en entrée à un groupe d'isolation
Autres considérations relatives à IPSec
Résumé

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 :

• 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, reportez-vous à 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.

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

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 NAT-Traversal (NAT-T), Windows XP SP2 et Windows Server 2003 en tant que membres de domaines.

• Compatibilité de ces plates-formes 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 pare-feu 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).

• Compatibilité d'IPSec ESP (Encapsulated Security Payload) NAT-T 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é.

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 ci-dessous 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 sous-ré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 l'organisation à des fins de dépannage.

La liste des sous-réseaux sécurisés répertorie tous les sous-ré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 sous-ré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 non-IPSec ne doit figurer sur ces sous-ré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 plate-forme 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é.

• Une adresse IP spécifique. Cette option compare le trafic avec l'adresse IP spécifiée dans le filtre.

• Un sous-ré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 sous-ré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 sous-ré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 plates-formes, 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é, reportez-vous à 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 pare-feu basé sur un hôte (par exemple, le pare-feu 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 <-> sous-réseaux pour le scénario de la Woodgrove Bank. Une liste composée de plusieurs filtres N'importe quelle adresse IP <-> Un sous-réseau IP spécifique est créée, répertoriant de manière explicite tous les sous-réseaux de l'organisation. Cette approche permet à l'administrateur de définir les sous-réseaux spécifiques à sécuriser. Tout le trafic circulant en dehors des sous-ré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, reportez-vous à 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 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 eux-mê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 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. Reportez-vous aux articles 811832  (https://support.microsoft.com/?kbid=811832) et 810207  (https://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 ci-dessous.

Tableau 5.2 : Exemples de listes de filtres de la Woodgrove Bank

Liste de filtres	Filtres définis	Protocole ou port
Secure Subnets (Sous-ré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 de contrôleurs de domaine)	N'importe lequel <-> 192.168.1.21 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	Toutes
WINS Exemption List (Liste d'exemptions WINS)	N'importe lequel <-> 192.168.1.22	Toutes
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 sous-ré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 sous-ré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.

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 :

• 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 ci-aprè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é	Options cryptographiques	Description
Authentification de l'en-tête (AH)	MD5 SHA-1	Garantit à la fois l'authenticité et l'intégrité de la charge utile IP (données) et de l'en-tête IP (adresse) sans chiffrement. AH ne peut pas traverser les périphériques utilisant la traduction d'adresses réseau (NAT).
ESP – Intégrité	<Aucune> MD5 SHA-1	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.
ESP – chiffrement	<Aucune> 3DES DES	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 NAT-T pour ESP en mode de transport IPSec, en plus de la prise en charge de NAT-T pour les tunnels clients VPN L2TP/IPSec. La mise à jour NAT-T est requise pour Windows 2000 SP4. La prise en charge de NAT-T 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 (Path-MTU) 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 en-tête UDP après l'en-tête IP pour encapsuler ESP. IKE détecte automatiquement l'existence de NAT dans le chemin et utilise UDP-ESP 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.

• SHA-1. 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 SHA-1 est longue, plus la sécurité est élevée mais la charge requise pour le traitement est, elle aussi, plus importante. SHA-1 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 ESP-Null, 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'en-tê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é SHA-1 et un chiffrement ESP–3DES. Si seule l'intégrité des données est requise, vous pouvez alors utiliser ESP-Null avec SHA-1.

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'en-tê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 ESP-Null, mais l'action de filtrage peut contenir également une méthode de négociation pour ESP-3DES. Cette approche permet au système de négocier une connexion de chiffrement 3DES si celle-ci 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éga-octets (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 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 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, reportez-vous à 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=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en.

Actions de filtrage IPSec de la Woodgrove Bank

Le tableau ci-aprè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.
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 non-IPSec. 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 non-IPSec. 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 ci-dessous suffisent à la mise en place de son environnement :

Tableau 5.5 : Méthodes de sécurité prises en charge

Action de filtrage	Méthodes de sécurité prises en charge
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode de requête - Accepter le trafic entrant, Autoriser le trafic sortant)	ESP – SHA-1, <Aucune> ESP – SHA-1, 3DES
IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound) (Mode de requête sécurisée - Ignorer le trafic entrant, Autoriser le trafic sortant)	ESP – SHA-1, <Aucune> ESP – SHA-1, 3DES
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound) (Mode requis complet - Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)	ESP – SHA-1, <Aucune> ESP – SHA-1, 3DES
IPSec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) (Mode de chiffrement requis - Ignorer le trafic entrant, Ne pas autoriser le trafic sortant)	ESP – SHA-1, 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 SHA-1 (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.

Souvenez-vous 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 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 sous-réseaux internes. Vous pouvez regrouper les exigences décrites ci-dessus en deux comportements de base :

• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sous-ré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 ESP-Null et inclure ESP–SHA-1–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 sous-ré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–SHA-1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportez-vous à 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 ESP-Null avec l'algorithme SHA-1.

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 pare-feu. Les associations de sécurité logicielles autorisent tout le trafic correspondant au filtre associé. Pour plus d'informations sur ce processus, reportez-vous à 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.

• 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 sous-ré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 sous-ré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 ESP-Null et inclure ESP–SHA-1–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 SHA-1 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.

• 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 sous-ré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 sous-ré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 ESP-Null et inclure ESP–SHA-1–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 sous-ré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, reportez-vous à 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 SHA-1 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 SHA-1 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.

• 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 sous-ré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 sous-réseaux internes) ; déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec ESP–SHA-1–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 sous-réseaux internes) ; les ignorer. Accepter uniquement les demandes de négociation IKE issues d'hôtes approuvés autorisant IPSec ESP–SHA-1–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 :

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

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 ci-dessous 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 non-IPSec. 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 de chiffrement)	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 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 ci-aprè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	Toutes
Domain Controllers Exemption List (Liste d'exemptions de contrôleurs de domaine)	IPSEC – Permit (Autoriser)	Aucun	Aucun	Toutes
Liste d'exemptions WINS (WINS Exemptions List)	IPSEC – Permit (Autoriser)	Aucun	Aucun	Toutes
DHCP, Negotiation Traffic (DHCP, trafic de négociation)	IPSEC – Permit (Autoriser)	Aucun	Aucun	Toutes
ICMP, All Traffic (ICMP, tout le trafic)	IPSEC – Permit (Autoriser)	Aucun	Aucun	Toutes

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 ci-aprè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	Action de filtrage
IPSEC – Isolation Domain IPSec Policy (1.0.041001.1600) (Stratégie IPSec de domaine d'isolation)	Sous-réseaux sécurisés de Woodgrove Bank	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)	Sous-ré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)	Sous-ré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)	Sous-ré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 au-delà 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 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. Utilisez-la 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 kilo-octets 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.

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é (SHA-1 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 elle-même et la protection des données IPSec dépend de la puissance du groupe Diffie-Hellman sur lequel les nombres premiers sont fondés. Trois options sont proposées pour le groupe Diffie-Hellman :

• Haute (3) – puissance de clé 2048 bits. Cette option correspond à la norme IETF RFC 3526 du groupe Diffie-Hellman 14. Cette puissance de clé est indispensable pour que 3DES bénéficie d'un niveau de chiffrement maximal. Reportez-vous à 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 ci-dessous 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 Diffie-Hellman
3DES	SHA-1	Haute (3) 2048 bits
3DES	SHA-1	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 plates-formes 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>.<Date:yymmdd>.<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"

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 <DomainName>\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

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. Reportez-vous à 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 https://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 sous-tâ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.

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, reportez-vous à 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, reportez-vous à 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.

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é « glisser-dé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 eux-mê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, reportez-vous 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=0A6D4C24-8CBD-4B35-9272-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.

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 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 ci-aprè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 non-IPSec 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.

• 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 eux-mê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 ci-dessous 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 eux-mê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 (Stratégie de groupe de limite)	CG_BoundaryIG_computers	Autoriser Lecture et 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.

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 sous-ensemble 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 IPS-ST-XP-05 du domaine client autorisé est ajouté au groupe d'accès réseau ANAG_EncryptedResourceAccess_Computers. Les comptes IPS-SQL-DFS-01 et IPS-SQL-DFS-02 des serveurs de chiffrement sont également ajoutés. 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 IPS-ST-XP-05 pour accéder au serveur IPS-SQL-DFS-01 ou au serveur IPS-SQL-DFS-02. L'ordinateur IPS-ST-XP-05 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.

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.

NAT-Traversal (NAT-T)

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 Windows Server 2003 placés derrière un traducteur d'adresses réseau utilisant la technologie NAT-T IPSec. Par défaut, Windows XP SP2 ne prend plus en charge les associations de sécurité NAT-T 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 NAT-T IPSec sur un serveur placé sur un réseau configuré NAT (Serveur 1).

2. Un client étranger au réseau NAT (Client 1) utilise NAT-T 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 NAT-T 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 NAT-T 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 NAT-T 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 NAT-T 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 sous-clé 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.

   • 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 ci-dessous pour savoir comment vous procurer Windows Server 2003 Service Pack 1  :

https://go.microsoft.com/fwlink/?LinkId=41652

Remarque : pour plus d'informations, reportez-vous à l'article 885348 de la Base de connaissances Microsoft, « IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators  », (IPSec NAT-T est déconseillé pour les ordinateurs Windows Server 2003 situés derrière des traducteurs d'adresses réseau) disponible à l'adresse https://support.microsoft.com/default.aspx?
scid=kb;en-us;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 elle-mê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 sous-clé 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 NAT-T nécessitent l'installation du correctif fourni avec l'article 818043 de la Base de connaissances Microsoft, « L2TP/IPSec NAT-T update for Windows XP and Windows 2000  » (Mise à jour NAT-T L2TP/IPSec pour Windows XP et Windows 2000) pour fonctionner correctement.

Pour plus d'informations, reportez-vous aux articles suivants de la Base de connaissances :

• 885407, « The default behavior of IPSec NAT traversal (NAT-T) is changed in Windows XP Service Pack 2  » (Le comportement par défaut d'IPSec NAT-T (NAT-Traversal) est modifié dans Service Pack 2 Windows XP), sur le site Web du support Microsoft à l'adresse https://support.microsoft.com/kb/885407.

• 818043, « L2TP/IPSec NAT-T 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 https://support.microsoft.com/kb/818043.

IPSec et Pare-feu Windows

Le Pare-feu 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 pare-feu Windows. Lorsqu'une stratégie IPSec est active, les composants IPSec de Windows XP SP2 sollicitent le Pare-feu 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 Pare-feu Windows. Pour plus d'informations, reportez-vous à l'annexe A du livre blanc, « Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2  » (Déploiement des paramètres du Pare-feu Windows pour Microsoft Windows XP Service Pack 2) disponible à l'adresse https://download.microsoft.com/download/
6/8/a/68a81446-cd73-4a61-8665-8a67781ac4e8/wf_xpsp2.doc.

IPSec et Pare-feu de connexion Internet (ICF)

Pour les ordinateurs Windows XP non équipés du SP2, le Pare-feu de connexion Internet (ICF) répondra mieux aux exigences de sécurité qu'impose le filtrage du trafic. Le Pare-feu 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 Pare-feu de connexion Internet et qu'IKE intervient au-dessus du Pare-feu 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 Pare-feu 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

• 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/en-us/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.

Télécharger la solution complète

Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe