Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe
Annexe A : Présentation des concepts relatifs à la stratégie IPSec
Dernière mise à jour le 16-02-2005
Cette annexe présente en détail les termes, processus et concepts liés à IPSec. Elle vise à fournir le niveau préalable de compréhension d'IPSec nécessaire à la lecture du guide Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe.
Le contenu de cette annexe a été initialement publié dans le Livre blanc « Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server .gif)
» (Utilisation de Microsoft Windows IPSec pour la sécurisation d'un serveur de réseau d'entreprise interne) (disponible à l'adresse www.microsoft.com/ipsec), rédigé conjointement par Microsoft et Foundstone Strategic Security.
Les informations supplémentaires du Livre blanc décrivent le premier modèle d'utilisation d'IPSec pour la sécurisation de l'accès réseau à des serveurs internes Microsoft® Windows® utilisés pour le traitement ou le stockage de données sensibles. Bien que ces informations complémentaires ne soient pas indispensables à la compréhension du guide Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe, elles constituent des informations générales utiles.
Sur cette page
Introduction
Filtres de stratégie IPSec
Processus de négociation IKE
Méthodes de sécurité
Modes d'encapsulation IPSec et formats du protocole IPSec
Authentification IKE
Ordre de préférence des méthodes d'authentification et des méthodes de sécurité IKE
Options de négociation de sécurité
Introduction
Lorsque vous créez une stratégie IPSec, vous configurez des règles IPSec (qui déterminent le comportement d'IPSec) et des paramètres (appliqués quelles que soient les règles configurées). Après avoir configuré une stratégie IPSec, vous devez l'attribuer à un ordinateur pour qu'elle soit mise en application. Bien qu'il soit possible d'avoir plusieurs stratégies IPSec sur un ordinateur, il n'est possible d'attribuer qu'une seule stratégie IPSec à la fois à un ordinateur.
Une règle IPSec détermine le type de trafic à analyser, si le trafic est autorisé, bloqué ou si la sécurité est négociée, la méthode d'authentification d'un homologue IPSec, ainsi que d'autres paramètres. Lorsque vous configurez une règle IPSec, vous configurez une liste de filtres comprenant un ou plusieurs filtres, une action de filtrage, des méthodes d'authentification, un type de connexion et un mode d'encapsulation IPSec (mode transport ou mode tunnel). Une règle IPSec est en principe configurée dans un but spécifique (par exemple, « Bloquer tout le trafic entrant en provenance d'Internet sur le port TCP 135 »).
Les filtres définissent le trafic que vous souhaitez inspecter, comme pour une règle de pare-feu, avec les adresses IP source et de destination, les protocoles et les numéros de port, le cas échéant. Une action de filtrage définit les exigences de sécurité qui s'appliquent au trafic du réseau. Vous pouvez configurer une action de filtrage pour autoriser ou bloquer le trafic, ou négocier la sécurité (négocier IPSec). Si vous configurez une action de filtrage pour négocier la sécurité, vous devez également configurer des méthodes de sécurité d'échange de clés (ainsi que leur ordre de préférence), indiquer s'il faut accepter le trafic initial entrant non sécurisé, s'il faut autoriser les communications non sécurisées avec des ordinateurs ne prenant pas en charge IPSec, et s'il faut utiliser la confidentialité de transmission parfaite (PFS, Perfect Forward Secrecy).
Les méthodes et les paramètres relatifs à l'échange de clés déterminent les formats du protocole IPSec (AH (Authentication header) ou ESP (Encapsulated Security Payload)), les algorithmes de chiffrement et de hachage, la durée de vie des clés, ainsi que d'autres paramètres requis pour la configuration du mode principal de l'association de clés Internet (IKE, Internet Key Association) et des associations de sécurité IPSec (SA). Une association de sécurité (SA) correspond à l'accord des paramètres de sécurité associés aux ressources de génération de clé. La SA créée lors de la première phase de négociation IKE est appelée SA de mode principal IKE (également appelée SA de mode principal ISAKMP). La SA de mode principal IKE protège la négociation IKE proprement dite. Les SA créées lors de la seconde phase de négociation IKE sont appelées SA IPSec (également appelées SA de mode rapide IKE car chaque négociation en mode rapide IKE négocie la SA IPSec pour chaque sens). Les SA IPSec protègent le trafic applicatif.
Cette section fournit des informations sur les concepts importants relatifs aux stratégies IPSec suivants :
Processus de négociation IKE
Filtres de stratégie IPSec
Méthodes de sécurité
Formats du protocole IPSec
Authentification IKE
Ordre de préférence des méthodes d'authentification et des méthodes de sécurité IKE
Options de négociation de la sécurité
Pour plus d'informations sur les concepts relatifs aux stratégies IPSec, consultez le Centre d'aide et de support de Microsoft Windows Server™ 2003.
Filtres de stratégie IPSec
Les filtres occupent une place capitale dans une stratégie IPSec. Si vous ne spécifiez pas les filtres appropriés dans les stratégies de client ou de serveur, ou si les adresses IP changent avant la mise à jour des filtres de la stratégie, la sécurité peut être compromise. Les filtres IPSec sont intégrés dans la couche IP de la pile du protocole de gestion de réseau TCP/IP de l'ordinateur afin d'analyser (filtrer) l'ensemble des paquets IP entrants ou sortants. Hormis un bref délai, requis pour négocier une relation de sécurité entre deux ordinateurs, IPSec est transparent pour les applications et les services du système d'exploitation de l'utilisateur final. Les filtres sont associés à une action de filtrage correspondante par la règle de sécurité d'une stratégie IPSec. Windows IPSec prend en charge le mode tunnel IPSec et le mode transport IPSec en tant qu'options de la règle. La configuration du mode tunnel IPSec est très différente de celle du mode transport IPSec.
Les règles de filtrage associées à une stratégie IPSec s'apparentent aux règles utilisées pour les pare-feu. Lorsque vous recourez à l'interface utilisateur graphique fournie par le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP, vous pouvez configurer IPSec pour qu'il autorise ou bloque des types spécifiques de trafic en fonction de paires d'adresses source et de destination, et de protocoles et ports spécifiques.
Remarque : Windows IPSec n'est pas un pare-feu pour hôte complet, et il ne prend pas en charge les fonctions de filtrage dynamique ou avec état, telles que le suivi du bit établi lors de la négociation TCP pour contrôler le sens dans lequel les communications peuvent s'effectuer.
Présentation du filtrage IPSec
Les listes de filtres sont simplement des listes de sous-réseaux connus et d'adresses IP d'infrastructure. Il est important de comprendre comment tous les filtres contenus dans l'ensemble des règles s'associent pour fournir les contrôles d'accès entrant et sortant requis. Cette section fournit les détails les plus importants pour comprendre l'impact des filtres IPSec sur le traitement des paquets.
Le composant logiciel enfichable MMC Moniteur IPSec de Windows Server 2003 offre la vue la plus détaillée de l'ordre des filtres IPSec. Lorsque le service IPSec traite un jeu de règles de stratégie IPSec, les filtres sont copiés dans deux types afin de permettre le contrôle des deux phases de négociation IKE :
Filtres de mode principal IKE. Ces filtres utilisent uniquement l'adresse source et de destination des filtres définis dans la stratégie IPSec pour contrôler le mode principal IKE. Les filtres spécifiques au mode principal IKE ont chacun une stratégie de négociation en mode principal IKE qui leur est associée. Cette dernière définit :
les méthodes de sécurité de mode principal IKE définies pour la stratégie IPSec dans les paramètres d'échange de clés, comme la puissance de la clé principale Diffie Hellman et les algorithmes de chiffrement et d'intégrité utilisés pour protéger la négociation IKE ;
les durées de vie du mode principal IKE et les limites du nombre de clés de session générées à partir de la clé principale ;
les méthodes d'authentification.
Filtres du mode rapide IKE. Ces filtres contiennent l'intégralité des informations de filtrage liées aux adresses, protocoles et ports. Le mode rapide IKE négocie cette définition de filtre pour déterminer le trafic à sécuriser au sein d'une paire d'associations de sécurité IPSec. Chaque filtre spécifique dispose d'un poids correspondant et d'un ensemble de méthodes de sécurité qui définissent :
les options pour l'encapsulation AH ou ESP en mode transport ou mode tunnel ;
une liste d'algorithmes de chiffrement et d'intégrité ;
la durée de vie des associations de sécurité IPSec en kilo-octets et en secondes ;
les paramètres de sécurité relatifs à la confidentialité de transmission parfaite.
Les filtres spécifiques au mode rapide IKE sont la liste des filtres fournis au pilote IPSec pour qu'il les mette en œuvre. Le pilote IPSec fait correspondre tout le trafic IP entrant et sortant avec ces filtres, dans l'ordre spécifié par le poids le plus élevé. La section suivante, consacrée au processus de négociation IKE, décrit la manière dont l'IKE négocie et gère les associations de sécurité IPSec à l'aide de ces contrôles de stratégie.
Les filtres définis dans la stratégie IPSec sont considérés comme des filtres « génériques » car ils peuvent être amenés à être interprétés par le service IPSec lors de l'application de la stratégie. Le service IPSec interprète tous les filtres génériques en filtres spécifiques au moment où la stratégie IPSec (ou la modification) est appliquée à l'ordinateur. Les filtres spécifiques ont un algorithme intégré de calcul du poids (ou ordre), qui intervient également lors de la sélection du trafic pour indiquer le degré de spécificité du filtre. Une valeur de poids élevée correspond à un filtre plus spécifique. Tous les filtres spécifiques sont triés en fonction de leur poids. Le poids du filtre est évalué en premier lieu sur l'adresse IP, puis sur les protocoles, et enfin sur les ports qui peuvent être définis dans le filtre. Cette approche garantit que l'ordre des règles d'une stratégie, ainsi que l'ordre des filtres dans les différentes listes de filtres, n'affectent pas le comportement de filtrage mis en œuvre par le pilote IPSec lors du traitement des paquets. Les paquets sont d'abord mis en correspondance avec les filtres les plus spécifiques afin de réduire la durée requise pour traiter chaque paquet par rapport à l'ensemble des filtres. L'action de filtrage associée au filtre le plus spécifique correspondant à un paquet est la seule action entreprise pour ce paquet. Le filtre le plus générique pouvant être défini est celui qui correspondrait à toute adresse IP et à tous les protocoles et ports. Par exemple, examinons les quatre définitions de filtre suivantes :
Toute adresse IP <-> Toute adresse IP, tout protocole
Toute adresse IP <-> 192.168.1.0/24, tout protocole
Toute adresse IP <-> 192.168.1.10/24, tout protocole
Toute adresse IP <-> 192.168.1.10/24, tout port TCP source, port de destination 25
Le filtre « Toute adresse IP vers toute adresse IP » est le filtre le plus générique qu'il est possible de définir. Il est uniquement pris en charge par Windows Server 2003 et Windows XP Service Pack 2 (SP2). En règle générale, ce filtre est utilisé avec une action de blocage pour induire un comportement par défaut de rejet total (« Refuser tous les trafics »). Si ce filtre est utilisé pour bloquer la totalité du trafic, les autres filtres plus spécifiques peuvent être considérés comme des exceptions au premier filtre. Pour Windows 2000, le filtre le plus générique pris en charge est le suivant : Toute adresse IP <-> sous-réseau, tout protocole, ou Toute adresse IP <-> Mon adresse IP si aucun sous-réseau n'est utilisé.
Les quatre filtres correspondent alors au trafic entrant provenant de toute adresse IP vers 192.168.1.10 par le port TCP 25 et les réponses sortantes correspondantes émises à partir du port 25. Le quatrième filtre est le plus spécifique car il spécifie une adresse IP de destination, un protocole et un numéro de port. Lorsque les quatre filtres sont mis en application par le pilote IPSec, un paquet entrant destiné au port TCP 25 correspond uniquement au quatrième filtre le plus spécifique. Si un système distant envoie du trafic TCP sur n'importe quel port autre que le port 25 vers 192.168.1.10, c'est le troisième filtre qui s'applique. Enfin, si du trafic est envoyé à n'importe quelle adresse IP du sous-réseau 192.168.1.0 à l'exception de l'adresse 192.168.1.10, le second filtre est alors le plus spécifique pour ce trafic.
Problèmes potentiels de conception des filtres
Lors de la conception des filtres, certaines associations d'options d'adresses source et de destination sont à proscrire. Comme indiqué plus haut, les filtres qui spécifient le critère Toute adresse IP vers toute adresse IP doivent être évités pour les hôtes exécutant Windows 2000.
En général, plus une stratégie contient de filtres, plus les performances du traitement des paquets diminuent. Cela se traduit par un débit réduit, une utilisation accrue de la mémoire du noyau du pool non paginé et une charge accrue de l'unité centrale. L'impact précis sur les performances est difficile à estimer car il dépend du volume global du trafic, de la quantité de trafic sécurisé par IPSec en cours de traitement et de la charge de l'unité centrale sur l'ordinateur. Par conséquent, les tests de performances des différents modèles de conception de stratégie IPSec doivent être intégrés au processus de planification. L'impact de plusieurs centaines de filtres passerait sans doute inaperçu, sauf sur des ordinateurs à très haut débit.
Windows 2000 ne dispose pas des optimisations requises pour traiter un grand nombre de filtres. Le pilote IPSec doit analyser l'intégralité de la liste des filtres de façon séquentielle pour trouver une correspondance.
Sous Windows XP et Windows Server 2003, de nombreuses optimisations ont été intégrées pour accélérer le traitement des filtres afin de rendre possible l'utilisation d'un nombre élevé de filtres dans la stratégie IPSec. Les filtres au format De <adresse IP> à <adresse IP> (indépendamment du protocole ou des ports utilisés) ont été optimisés par l'utilisation du pilote de classification de paquets générique (GPC) qui effectue des recherches extrêmement rapides. Le GPC peut traiter pratiquement n'importe quel nombre de ces filtres sans affecter la qualité du débit. Ainsi, les listes d'exemptions volumineuses utilisant Mon adresse IP vers <adresse IP d'exemption spécifique> sont facilement prises en charge, à condition qu'il y ait suffisamment de mémoire du noyau non paginé pour contenir la liste de filtres complète. Les filtres n'ayant pas d'adresse IP spécifique à la fois pour la source et la destination ne peuvent pas être optimisés par le GPC ; les filtres de type Toute adresse IP <-> adresse IP spécifique (ou sous-réseau) nécessitent alors une recherche séquentielle. En revanche, la mise en œuvre est améliorée à partir de Windows 2000.
L'utilisation de Mon adresse IP peut être appropriée dans de nombreux cas, mais elle peut également poser problème pour les hôtes regroupant un grand nombre d'adresses IP, comme un serveur Web hébergeant de nombreux sites Web virtuels. Elle peut aussi entraîner un délai dans la disponibilité du filtrage des paquets par le pilote IPSec si un grand nombre de filtres utilisent Mon adresse IP. Le service IPSec les traite au démarrage du service et lorsqu'un événement de changement d'adresse intervient. Le délai peut provoquer l'apparition d'une vulnérabilité ou des délais de connexion sécurisée avec IPSec. Là encore, un test de performances doit confirmer si les conséquences d'une conception de stratégie sont acceptables.
Le meilleur cas de figure pour l'utilisation de Mon adresse IP est probablement l'autorisation ou le rejet du trafic destiné à un port ou protocole spécifique. Par exemple, dans la conception de stratégie IPSec pour Woodgrove Bank, les filtres Mon adresse IP sont utilisés pour créer un filtre plus spécifique autorisant l'envoi et la réception de trafic ICMP (Internet Control Message Protocol) en texte clair sur tous les ordinateurs.
Si un client mobile de l'organisation se voit attribuer une règle de type Mon adresse IP <-> Toute adresse IP et est ensuite placé sur un réseau externe, ce client peut ne pas réussir à communiquer dans cet environnement. Si le client dispose du droit Communiquer en texte clair, il subit des délais de trois secondes ou plus pour se connecter à chaque destination. Si la destination répond par une réponse IKE, la négociation IKE échoue car l'IKE ne parvient pas à procéder à l'authentification à l'aide de l'approbation de domaine (Kerberos). Naturellement, si les adresses privées RFC 1918 sont utilisées en tant que sous-réseaux de réseau interne, les clients mobiles sont affectés lors de leur connexion à des réseaux d'hôtels, des réseaux domestiques, et parfois même à d'autres réseaux internes. Si des clients mobiles rencontrent des problèmes de connexion, ils peuvent avoir besoin de droits d'administrateur local pour arrêter le service IPSec lorsqu'ils sont connectés à d'autres réseaux. En conséquence, un script de connexion au domaine peut être requis pour vérifier si le service IPSec est en cours d'exécution lorsqu'ils se connectent au réseau interne.
À l'origine, Windows 2000 n'était pas conçu pour fournir des fonctions de filtrage pour les paquets utilisant des adresses de multidiffusion et de diffusion car ce trafic ne pouvait pas être sécurisé à l'aide de la négociation IKE. Ainsi, les types de paquets de multidiffusion et de diffusion faisaient partie des exemptions par défaut initiales qui ignoraient les filtres IPSec. Consultez l'article 811832 de la Base de connaissances Microsoft « IPSec Default Exemptions Can Be Used to Bypass IPSec Protection in Some Scenarios » (Exemptions par défaut IPSec vous permettent d'ignorer la protection IPSec dans certains scénarios), à l'adresse http://support.microsoft.com/kb/811832, pour obtenir des explications détaillées sur les répercussions des exemptions par défaut sur la sécurité et les modifications implémentées par le Service Pack 3 pour en retirer certaines par défaut. L'intégration du protocole TCP/IP avec IPSec dans Windows XP et Windows Server 2003 a été améliorée pour filtrer tous les types de paquets IP. Néanmoins, du fait que l'IKE ne peut pas négocier la sécurité pour le trafic de multidiffusion et de diffusion, ces systèmes offrent des capacités de filtrage limitées. Consultez l'article 810207 de la Base connaissances « IPSec default exemptions are removed in Windows Server 2003 » (Exemptions par défaut IPSec sont supprimées à Windows Server 2003), à l'adresse http://support.microsoft.com/kb/810207, pour obtenir des détails sur la suppression des exemptions par défaut et sur le niveau de filtrage pris en charge pour le trafic de multidiffusion et de diffusion. Windows XP SP2 offre les mêmes fonctions de filtrage Toute adresse IP <-> Toute adresse IP que Windows Server 2003.
Processus de négociation IKE
Le protocole IKE permet d'établir de façon sécurisée une relation d'approbation entre les différents ordinateurs, de négocier les options de sécurité et de générer de façon dynamique des ressources de génération de clés cryptographiques, secrètes et partagées. Afin d'assurer des communications réussies et sécurisées, l'IKE procède à une opération en deux phases : négociation Phase 1 (mode principal) et négociation Phase 2 (mode rapide). La confidentialité et l'authentification peuvent être assurées dans chacune de ces phases par l'utilisation d'algorithmes de chiffrement et d'authentification approuvés par les deux ordinateurs lors des négociations de sécurité.
Négociation en mode principal
Lors de la négociation en mode principal, les deux ordinateurs établissent une voie sécurisée et authentifiée. Tout d'abord, les paramètres de stratégie IPSec suivants sont négociés : algorithme de chiffrement (DES ou 3DES), algorithme d'intégrité (MD5 ou SHA1), groupe Diffie-Hellman à utiliser pour les ressources de génération de clé de base (Groupe 1, Groupe 2, ou, dans Windows Server 2003, Groupe 2048) et méthode d'authentification (protocole Kerberos version 5, certificat de clé publique ou clé pré-partagée). Une fois la négociation des paramètres de stratégie IPSec effectuée, l'échange de valeurs publiques Diffie-Hellman est terminé. L'algorithme Diffie-Hellman permet de générer des clés partagées, symétriques et secrètes entre des ordinateurs. Une fois l'échange Diffie-Hellman terminé, le service IKE de chaque ordinateur génère la clé principale utilisée pour la protection de l'authentification. La clé principale permet, en association avec les algorithmes et méthodes de négociation, d'authentifier les identités. L'initiateur de la communication présente alors une offre d'association de sécurité potentielle au répondeur. Le répondeur envoie une réponse indiquant qu'il accepte l'offre ou répond en proposant d'autres associations. Le résultat d'une négociation en mode principal IKE réussie est une SA de mode principal.
Négociation en mode rapide
Lors d'une négociation en mode rapide, une paire de SA IPSec est établie afin de protéger le trafic applicatif, qui peut contenir des paquets envoyés sur TCP, UDP (User Datagram Protocol) et d'autres protocoles. Tout d'abord, les paramètres de stratégie suivants sont négociés : format du protocole IPSec (AH ou ESP), algorithme de hachage pour l'intégrité et l'authentification (MD5 ou SHA1), et algorithme pour le chiffrement (DES ou 3DES), si le chiffrement est requis. Pendant ce temps, un accord commun est atteint pour le type de paquets IP à transporter dans la paire de SA IPSec établie. Une fois la négociation des paramètres de stratégie IPSec effectuée, les ressources de génération de clés de session (clés cryptographiques et durée de vie des clés, en secondes et en kilo-octets, pour chaque algorithme) sont actualisées ou échangées.
Chaque SA IPSec est identifiée par un index de paramètres de sécurité (SPI), inséré dans l'en-tête IPSec de chaque paquet envoyé. Un SPI identifie la SA IPSec entrante ; l'autre identifie la SA IPSec sortante.
SA de mode principal IKE et SA IPSec
Chaque fois qu'IPSec est utilisé pour permettre la sécurisation du trafic, une SA de mode principal et deux SA IPSec sont établies. Dans l'exemple de scénario suivant, pour que les communications soient établies entre CORPCLI et CORPSRV, les SA ci-après sont créées :
CORPCLI [IP1] <-------- SA mode principal IKE [IP1, IP2] -----> [IP2] CORPSRV
CORPCLI [IP1] ---------- SA IPSec [SPI=x] ------------------> [IP2] CORPSRV
CORPCLI [IP1] <-------- SA IPSec [SPI=y] --------------- [IP2] CORPSRV
où :
IP1 est l'adresse IP de CORPCLI.
IP2 est l'adresse IP de CORPSRV.
x est le SPI qui identifie la SA IPSec entrante pour CORPSRV depuis CORPCLI.
y est le SPI qui identifie la SA IPSec sortante pour CORPSRV vers CORPCLI.
Comme l'indique ce résumé, la SA de mode principal IKE entre CORPCLI et CORPSRV est bidirectionnelle. L'un ou l'autre des ordinateurs peut initier une négociation en mode rapide à l'aide de la protection fournie par la SA de mode principal IKE. Les SA IPSec ne dépendent pas de l'état des protocoles de niveau supérieur. Par exemple, les connexions TCP peuvent être établies et prendre fin alors que les SA IPSec sont toujours actives ; à l'inverse, les SA IPSec peuvent expirer avant la fin d'une connexion TCP. IKE tente une nouvelle négociation, à l'aide de la négociation en mode rapide pour établir deux nouvelles paires de SA IPSec avant la fin de la durée de vie de la paire de SA existante, afin d'éviter l'interruption d'une connexion. Bien que ce processus soit couramment considéré comme une régénération des clés de la SA IPSec, deux nouvelles SA IPSec sont en fait établies. La durée de vie de la SA de mode principal IKE se mesure uniquement en fonction du temps et du nombre de SA IPSec ayant été tentées (et non du nombre d'octets de données transférés dans le protocole IKE). L'expiration de la SA de mode principal IKE se produit indépendamment de la paire de SA IPSec. Si une nouvelle paire de SA IPSec est requise, une SA de mode principal IKE est automatiquement renégociée si nécessaire (lorsqu'une SA de mode principal est arrivée à expiration). D'après la conception définie par l'Internet Engineering Task Force (IETF),l'IKE doit être capable de régénérer les clés de la SA de mode principal et de négocier le mode rapide IKE dans les deux sens. Ainsi, la méthode d'authentification configurée dans la stratégie IPSec des deux ordinateurs pour la SA de mode principal IKE doit permettre la réussite de l'authentification dans le sens à partir duquel la négociation en mode principal IKE est initiée. De même, les paramètres de stratégie IPSec de l'action de filtrage pour le mode rapide doivent permettre la réussite de la négociation bidirectionnelle en mode rapide.
Méthodes de sécurité
Les méthodes de sécurité sont utilisées lors de la négociation en mode principal IKE pour définir les algorithmes de chiffrement et de hachage, ainsi que le groupe Diffie-Hellman utilisé pour créer la SA de mode principal, et permettre la sécurisation de la voie de négociation IKE. Les méthodes de sécurité sont également utilisées lors de la négociation en mode rapide pour définir le mode d'encapsulation (transport ou tunnel), le format du protocole IPSec (AH ou ESP), les algorithmes de chiffrement et de hachage et la durée de vie des clés utilisés pour créer les SA de mode rapide entrantes et sortantes.
Modes d'encapsulation IPSec et formats du protocole IPSec
IPSec permet de protéger les données contenues dans un paquet IP en fournissant la protection cryptographique d'une charge utile IP. La protection fournie dépend du mode d'utilisation d'IPSec et du format du protocole. Vous pouvez utiliser IPSec en mode transport ou en mode tunnel.
Modes d'encapsulation IPSec
Le mode tunnel IPSec** est généralement utilisé pour protéger le trafic intersite (également appelé passerelle à passerelle ou interrouteur) transitant entre des réseaux, par exemple, dans le cadre de la gestion de réseau site à site via Internet. Quand le mode tunnel IPSec est utilisé, la passerelle émettrice encapsule la totalité du paquet IP initial en créant un nouveau paquet IP qui est ensuite protégé par l'un des formats du protocole IPSec (AH ou ESP). Pour plus d'informations sur IPSec en mode tunnel, reportez-vous au chapitre « Deploying IPSec » (Déploiement d'IPSec) du manuel Deploying Network Services (Déploiement de services réseau) du Kit de déploiement de Windows Server 2003 , à l'adresse http://go.microsoft.com/fwlink/?LinkId=8195.
Le mode transport IPSec permet de protéger les communications d'hôte à hôte ; c'est le mode par défaut pour Windows IPSec. Quand le mode transport IPSec est utilisé, IPSec chiffre uniquement la charge utile IP ; l'en-tête IP n'est pas chiffré. Windows IPSec est utilisé en mode transport principalement pour permettre la protection des communications de bout en bout (comme des communications entre clients et serveurs).
Formats du protocole IPSec
IPSec prend en charge deux formats de protocole : AH ou ESP. Le mode transport IPSec encapsule la charge utile IP initiale avec un en-tête IPSec (AH ou ESP).
AH
AH assure l'authentification de l'origine des données, l'intégrité des données et la protection anti-relecture pour l'ensemble du paquet (à la fois l'en-tête IP et la charge utile de données transportée dans le paquet), à l'exception des champs de l'en-tête IP autorisés à être modifiés lors du transit. AH ne garantit aucune confidentialité des données, ce qui signifie qu'il ne chiffre pas les données. Les données sont lisibles mais protégées contre les attaques de type modification et usurpation d'identité des paquets. Comme le montre la figure suivante, l'insertion de l'en-tête AH entre l'en-tête IP et les données TCP permet d'assurer l'intégrité et l'authentification.
.gif)
Figure A.1 En-tête d'authentification d'un paquet
Pour utiliser le protocole AH, dans les propriétés de la règle appropriée, dans la boîte de dialogue Paramètres personnalisés de la méthode de sécurité, activez la case à cocher Intégrité des adresses et des données sans chiffrement (AH), puis spécifiez l'algorithme d'intégrité à utiliser.
ESP
ESP assure l'authentification de l'origine des données, l'intégrité des données ainsi qu'une protection anti-relecture, et l'option de confidentialité pour la charge utile IP uniquement est disponible. En mode transport, ESP ne protège pas la totalité du paquet à l'aide d'un total de contrôle cryptographique. L'en-tête IP n'est pas protégé. Comme le montre la figure suivante, l'en-tête ESP est placé avant les données TCP ; un code de fin ainsi qu'un code de fin d'authentification ESP sont placés après les données TCP.
.gif)
Figure A.2 Données ESP d'un paquet
Pour utiliser le protocole ESP, dans les propriétés de la règle appropriée, dans la boîte de dialogue Paramètres personnalisés de la méthode de sécurité, activez la case à cocher Chiffrement et intégrité des données (ESP), puis spécifiez les algorithmes d'intégrité et de chiffrement à utiliser.
Authentification IKE
L'IKE utilise l'authentification mutuelle entre les ordinateurs pour établir des communications approuvées et nécessite l'utilisation de l'une des méthodes d'authentification suivantes : protocole Kerberos version 5, certificat d'infrastructure de clés publiques (PKI) X.509 version 3 (pour ordinateur) ou clé pré-partagée. Les deux points de terminaison de la communication doivent disposer d'au moins une méthode d'authentification commune, sinon la communication échoue.
Processus d'authentification IKE
Lors de la négociation IKE, l'initiateur IKE propose une liste de méthodes d'authentification au répondeur IKE. Le répondeur utilise l'adresse IP source de l'initiateur pour identifier le filtre qui contrôle la négociation IKE. La liste de méthodes d'authentification correspondant au filtre de la stratégie IPSec du répondeur est utilisée pour sélectionner une méthode d'authentification dans la liste de l'initiateur. Le répondeur répond ensuite pour informer l'initiateur de la méthode d'authentification adoptée. Si la méthode d'authentification sélectionnée échoue, l'IKE ne fournit pas de méthode pour tenter une méthode d'authentification différente. Si l'authentification réussit et que la négociation en mode principal se termine avec succès, la SA de mode principal dure huit heures. Si des données sont toujours en cours de transmission à la fin des huit heures, la SA de mode principal est automatiquement renégociée.
Méthodes d'authentification IKE
Il est important de choisir une méthode d'authentification adaptée à votre stratégie IPSec. La règle d'une stratégie IPSec associe chaque adresse IP d'un filtre à une liste de méthodes d'authentification afin que l'IKE détermine la liste de méthodes d'authentification à utiliser avec chaque adresse IP.
Authentification par le biais du protocole Kerberos Version 5
Le protocole Kerberos version 5 est la norme d'authentification utilisée par défaut dans les domaines Active Directory de Windows 2000 et Windows Server 2003. Tout ordinateur du domaine ou d'un domaine approuvé peut utiliser cette méthode d'authentification.
Lorsque l'authentification Kerberos est utilisée, chaque homologue IPSec envoie l'identité de son ordinateur dans un format chiffré à l'autre homologue lors de la négociation en mode principal. L'identité de l'ordinateur est déchiffrée jusqu'à ce que le chiffrement de la totalité de la charge utile de l'identité prenne place lors de la phase d'authentification de la négociation en mode principal. Un pirate peut envoyer un paquet IKE qui conduit l'homologue IPSec répondeur à exposer l'identité de son ordinateur et son appartenance de domaine. C'est pourquoi, afin d'optimiser la sécurisation des ordinateurs connectés à Internet, nous recommandons l'authentification par certificat.
Par défaut, dans Windows 2000 (jusqu'au Service Pack 3) et dans Windows XP, le trafic soumis au protocole Kerberos ne bénéficie pas du filtrage IPSec. Pour supprimer l'exemption existant pour le trafic soumis au protocole Kerberos, vous devez modifier le Registre puis ajouter un filtre IPSec approprié afin d'optimiser la sécurisation de ce trafic. Pour plus d'informations sur les exemptions par défaut dans Windows 2000 et Windows Server 2003, consultez les considérations spécifiques sur IPSec - Creating, modifying, and assigning IPSec policies (Création, modification et attribution de stratégies IPSec) sur le site Web Microsoft, à l'adresse suivante :
www.microsoft.com/resources/documentation/WindowsServ/
2003/standard/proddocs/en-us/sag_IPSECbpSpecial.asp.
Authentification par certificat de clé publique
Dans Windows 2000 Server, vous pouvez utiliser les services de certificats pour gérer automatiquement les certificats d'ordinateur pour IPSec tout au long du cycle de vie des certificats. Les services de certificats sont intégrés à Active Directory et à la Stratégie de groupe ; ils simplifient le déploiement des certificats en permettant l'inscription automatique et le renouvellement de certificats et en fournissant plusieurs modèles de certificats par défaut, compatibles avec IPSec. Pour utiliser des certificats pour l'authentification IKE, vous devez définir une liste ordonnée d'autorités de certification (CA) racine acceptables à utiliser ; il ne s'agit pas d'indiquer le certificat spécifique à utiliser. Les deux ordinateurs doivent posséder une autorité de certification racine commune dans la configuration de leur stratégie IPSec, et les clients doivent posséder un certificat d'ordinateur associé.
Au cours du processus de sélection de certificat, l'IKE procède à une série de vérifications afin de s'assurer que les exigences spécifiques sont respectées pour le certificat d'ordinateur. Par exemple, le certificat d'ordinateur doit avoir une longueur de clé publique supérieure à 512 bits et utiliser une clé de signature numérique.
Remarque : les certificats obtenus auprès des services de certificats avec l'option avancée définie sur Activer la protection par clé privée forte ne fonctionnent pas pour l'authentification IKE car vous ne pouvez pas entrer le numéro d'identification personnel (PIN) requis pour accéder à la clé privée d'un certificat d'ordinateur lors de la négociation IKE.
Clés pré-partagées
Si vous n'utilisez pas l'authentification Kerberos et n'avez pas accès à une autorité de certification, vous pouvez utiliser une clé pré-partagée. Par exemple, un ordinateur autonome intégré à un réseau doit parfois utiliser une clé pré-partagée car ni l'authentification Kerberos (via le compte de domaine de l'ordinateur), ni les certificats émis par une autorité de certification, ne peuvent permettre une authentification IKE satisfaisante dans certains cas de figure.
Important : les clés pré-partagées sont facilement implémentées mais peuvent être compromises si elles ne sont pas correctement utilisées. Microsoft vous déconseille d'utiliser l'authentification par clé pré-partagée dans Active Directory car la valeur de la clé n'est pas stockée de manière sécurisée ; il est ainsi difficile de la garder secrète. La valeur de la clé pré-partagée est stockée en texte clair dans une stratégie IPSec. Tout membre du groupe Administrateurs local peut visualiser une stratégie IPSec locale, et une stratégie IPSec locale peut être lue par tout service système disposant de droits d'utilisateur Système local. Par défaut, tout utilisateur authentifié du domaine peut visualiser une clé pré-partagée si elle est stockée dans une stratégie IPSec basée sur Active Directory. En outre, si des pirates parviennent à capturer des paquets de négociation IKE, des méthodes publiées peuvent permettre aux pirates de déceler les valeurs des clés pré-partagées.
Pour plus d'informations, consultez l'article « Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets » (Vulnérabilités de l'authentification sans IKE et Xauth avec des secrets pré-partagés), à l'adresse http://go.microsoft.com/fwlink/?LinkId=18769.
L'authentification par clé pré-partagée est proposée à des fins d'interopérabilité et de conformité avec les normes RFC. Si vous devez utiliser l'authentification par clé pré-partagée, utilisez une valeur de clé aléatoire de 25 caractères ou plus, et créez une clé pré-partagée différente pour chaque paire d'adresses IP. Ces pratiques permettent d'instaurer des règles de sécurité différentes pour chaque destination et de garantir que seuls les ordinateurs partageant la clé sont compromis en cas de compromission d'une clé pré-partagée.
Vérification de la liste de révocation de certificats IPSec
Si vous utilisez l'authentification basée sur des certificats, vous pouvez également activer la vérification de la liste de révocation de certificats IPSec. Dans Windows 2000, les listes de révocation de certificats ne sont pas automatiquement vérifiées par défaut lors de l'authentification IKE par certificat.
Pour activer la vérification des listes de révocation de certificats IPSec
Attention : toute erreur lors de la modification du Registre peut gravement endommager votre système. Avant de modifier le Registre, sauvegardez les données importantes de votre ordinateur.
Dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\PolicyAgent\, ajoutez une nouvelle clé Oakley, avec une entrée DWORD appelée StrongCrlCheck.
Attribuez à cette entrée une valeur comprise entre 0 et 2, où :
La valeur 0 désactive la vérification des listes de révocation de certificats (valeur par défaut dans Windows 2000).
La valeur 1 provoque une tentative de vérification des listes de révocation de certificats et l'échec de la validation du certificat uniquement si le certificat est révoqué (valeur par défaut dans Windows XP et Windows Server 2003). D'autres incidents qui se produisaient lors de la vérification des listes de révocation de certificats (comme l'impossibilité d'accéder à l'URL de révocation) ne provoquent pas l'échec de la validation du certificat.
La valeur 2 entraîne une vérification stricte des listes de révocation de certificats (CRL), ce qui signifie que la vérification des CRL est obligatoire et que la validation du certificat échoue si une erreur se produit lors du traitement des CRL. Définissez cette valeur du Registre si vous souhaitez renforcer la sécurité.
Effectuez l'une des opérations suivantes :
Redémarrez l’ordinateur.
Arrêtez, puis redémarrez le service IPSec en exécutant les commandes net stop policyagent et net start policyagent à l'invite de commande.
Remarque : la vérification des listes de révocation de certificats IPSec ne garantit pas l'échec immédiat de la validation du certificat après la révocation d'un certificat. Il y a un délai entre le moment où le certificat révoqué est placé dans une liste de révocation de certificats à jour et publiée et le moment où l'ordinateur qui procède à la vérification des CRL IPSec récupère cette CRL. L'ordinateur récupère une nouvelle CRL uniquement lorsque la CRL actuelle est arrivée à expiration ou à la publication suivante de la CRL. Les CRL sont mises en mémoire cache et stockées dans \Documents and Settings\Nom_utilisateur\Local Settings\Temporary Internet Files par CryptoAPI. Dans la mesure où les listes de révocation de certificats persistent entre les différents redémarrages de l'ordinateur, si un problème survient au niveau de la mémoire cache des listes, le redémarrage de l'ordinateur ne résout pas le problème.
Ordre de préférence des méthodes d'authentification et des méthodes de sécurité IKE
Vous pouvez configurer une règle IPSec afin de spécifier une seule méthode d'authentification ou méthode de sécurité. Vous pouvez également choisir de spécifier une liste préférée de méthodes d'authentification et de sécurité. L'ordre de préférence s'applique aux méthodes d'authentification et de sécurité pour que vous puissiez spécifier chaque méthode selon un ordre de préférence décroissant. Par exemple, vous pouvez spécifier comme méthodes d'authentification à la fois l'authentification par le biais du protocole Kerberos version 5 et l'authentification par certificat de clé publique, mais vous pouvez attribuer la préférence la plus élevée au protocole Kerberos, comme l'illustre la figure suivante.
.gif)
Figure A.3 Ordre de préférence des méthodes d'authentification
Si un client tente de se connecter à CORPSRV mais n'accepte que les certificats de clé publique pour l'authentification, CORPSRV utilise cette méthode d'authentification et continue à établir la communication. L'authentification IKE doit réussir à l'aide de cette méthode d'authentification, sinon la communication est bloquée. L'IKE ne tente pas d'utiliser une autre méthode d'authentification si la négociation échoue. Le même principe s'applique aux méthodes de sécurité, lorsque ESP a priorité sur AH, par exemple.
Options de négociation de sécurité
Vous pouvez définir si une stratégie IPSec autorise les options Communiquer en texte clair (passage à une communication non sécurisée), Relais entrant et Clé de session PFS (Perfect Forward Secrecy) sous l'onglet Méthodes de sécurité**, dans les propriétés d'une action de filtrage. Vous pouvez configurer l'option Clé principale PFS (Perfect Forward Secrecy) dans la boîte de dialogue Paramètres d'échange de clés, dans les propriétés générales d'une règle.
Communiquer en texte clair
Lorsque l'option Communiquer en texte clair est autorisée, le trafic est sécurisé par IPSec lorsque cela est possible (si l'ordinateur à l'autre extrémité de la connexion prend en charge IPSec avec une action de filtrage supplémentaire et un filtre dans sa stratégie), mais le trafic peut être envoyé de manière non sécurisée si l'homologue ne dispose pas d'une stratégie IPSec pour répondre à la demande de négociation de sécurité. Si l'homologue ne répond pas à la demande de négociation de sécurité dans les trois secondes, une SA pour le trafic en texte clair (ou SA logicielle) est créée. Les SA logicielles autorisent des communications TCP/IP normales, sans encapsulation IPSec. N'oubliez pas que, bien qu'IPSec ne permette pas de sécuriser ce type de trafic, une autre application peut contribuer à la sécurisation du trafic (par exemple, le trafic peut être sécurisé par des mécanismes de chiffrement LDAP (Lightweight Directory Access Protocol) ou d'authentification par appel de procédure distante (RPC)). Si l'homologue ne répond pas dans les trois secondes et que la négociation de sécurité échoue, la communication correspondant au filtre associé est bloquée.
Le paramètre Communiquer en texte clair permet l'interopérabilité avec les éléments suivants :
Ordinateurs exécutant des systèmes d'exploitation antérieurs à Windows 2000
Ordinateurs exécutant Windows 2000 ou systèmes plus récents n'ayant pas de stratégie IPSec configurée
Ordinateurs exécutant des systèmes d'exploitation non-Windows ne prenant pas en charge IPSec
Pour activer ou désactiver l'option Communiquer en texte clair, sous l'onglet Méthodes de sécurité**, dans les propriétés d'une action de filtrage, activez ou désactivez la case à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec.
Pour une stratégie client, vous pouvez soit activer, soit désactiver cette option. Si vous activez cette option et que le serveur ne répond pas à la demande de négociation de la sécurité émise par le client, vous pouvez autoriser le client à communiquer en texte clair. Si vous désactivez cette case à cocher et que le serveur ne répond pas à la demande de négociation de sécurité émise par le client, la communication est bloquée. Dans certains cas, il est utile d'activer l'option Communiquer en texte clair. Cependant, IKE autorise cette option uniquement en l'absence de réponse. Pour des raisons de sécurité, Windows IPSec n'autorise pas de communications non sécurisées si la négociation IKE échoue ou si une erreur survient lors d'une négociation IKE (après réponse), comme un échec d'authentification ou une absence d'accord sur des paramètres de sécurité.
Pour les déploiements initiaux, il est recommandé d'activer cette case afin que le client puisse communiquer en texte clair et que la connexion initiale puisse être établie lorsque IPSec est désactivé sur le serveur.
Relais entrant
Quand l'option de relais entrant est activée, le trafic TPC/IP entrant normal (trafic non sécurisé par IPSec, par exemple, paquet TCP SYN) est accepté s'il correspond au filtre associé à l'action de filtrage. Le paquet de réponse du protocole de niveau supérieur (par exemple, paquet ACK TCP SYN) correspond au filtre sortant associé et déclenche une négociation de sécurité. Deux SA IPSec sont alors négociées et le trafic est sécurisé par IPSec dans les deux sens. L'option Relais entrant permet à un serveur d'utiliser la règle de réponse par défaut pour initier la négociation de sécurité vers les clients. Lorsque vous activez la règle de réponse par défaut dans la stratégie IPSec des clients, ces derniers n'ont pas besoin de conserver un filtre contenant l'adresse IP du serveur. Si vous n'activez pas la règle de réponse par défaut dans la stratégie IPSec des clients, vous n'avez pas besoin d'activer l'option Relais entrant dans la stratégie IPSec du serveur. Notez par ailleurs que vous ne devez jamais activer cette option sur des ordinateurs connectés à Internet.
Pour activer ou désactiver l'option Relais entrant, sous l'onglet Méthodes de sécurité**, dans les propriétés d'une action de filtrage, activez ou désactivez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec.
Clé de session et clé principale PFS
La confidentialité PFS est un mécanisme qui détermine si les ressources de génération de clé existantes pour une clé principale peuvent être utilisées pour dériver une nouvelle clé de session. La confidentialité PFS permet de garantir que la compromission d'une seule clé permet uniquement l'accès aux données protégées par la PFS, et pas nécessairement à la communication entière. À cet effet, la PFS garantit qu'une clé utilisée pour protéger une transmission ne peut pas être utilisée pour générer des clés supplémentaires. L'option de clé de session PFS peut être utilisée sans nouvelle authentification et consomme moins de ressources que l'option de clé principale PFS. Lorsque l'option de clé de session PFS est activée, un nouvel échange de clés Diffie-Hellman se produit pour générer de nouvelles informations de génération de clé pour la clé principale.
Si vous activez la clé de session PFS dans la stratégie du serveur, vous devez aussi l'activer dans la stratégie des clients. Vous pouvez activer la clé de session PFS en activant la case à cocher Utiliser la session de clé principale PFS (Perfect Forward Secrecy), dans la boîte de dialogue Paramètres d'échange de clés, dans les propriétés générales d'une règle. La clé principale PFS requiert une nouvelle authentification et consomme une grande quantité de ressources. Elle nécessite une nouvelle négociation en mode principal pour chaque négociation en mode rapide qui se produit. Vous pouvez configurer la clé principale PFS en activant la case à cocher Clé principale PFS (Perfect Forward Secrecy). Si vous activez la clé principale PFS dans la stratégie du serveur, vous n'avez pas besoin de l'activer dans la stratégie des clients. Dans la mesure où l'activation de cette option entraîne un temps de traitement important, il est recommandé d'activer la clé de session PFS ou la clé principale PFS uniquement dans des environnements hostiles, dans lesquels le trafic risque d'être exposé à des attaques sophistiquées visant à compromettre la protection cryptographique puissante qu'offre IPSec.
Télécharger la solution complète
Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe