test

Guide d'administration système : services IP

Chapitre 19 Architecture IPsec (présentation)

L'architecture IPsec (IP security) offre la protection cryptographique des datagrammes IP dans les paquets réseau IPv4 et IPv6.

Le présent chapitre contient les informations suivantes :

Pour implémenter IPsec sur votre réseau, reportez-vous au Chapitre 20Configuration d'IPsec (tâches). Pour des informations de référence, reportez-vous au Chapitre 21Architecture IPsec (référence).

Nouveautés IPsec

Solaris 10 4/09 : À partir de cette version, l'utilitaire de gestion des services (SMF) gère IPsec en tant qu'ensemble de services.

Par défaut, deux services IPsec sont activés lors de l'initialisation du système :

Par défaut, les services de gestion des clés sont désactivés à l'initialisation du système :

Pour activer les stratégies IPsec sous SMF, effectuez les étapes suivantes :

  1. Ajoutez des entrées de stratégie IPsec au fichier ipsecinit.conf.

  2. Configurez le protocole IKE (Internet Key Exchange) ou configurez manuellement les clés.

  3. Actualisez le service de stratégie IPsec.

  4. Activez le service de gestion des clés.

Pour plus d'informations sur l'utilitaire SMF, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration. Voir aussi les pages de manuel smf(5) et svcadm(1M).

À partir de cette version, les commandes ipsecconf et ipseckey ont une option -c permettant de vérifier la syntaxe de leurs fichiers de configuration respectifs. De plus, le profil de droits Network IPsec Management est fourni pour administrer IPsec et IKE.

Solaris 10 7/07 : À partir de cette version, IPsec implémente entièrement les tunnels en mode Tunnel et les utilitaires de prise en charge des tunnels sont modifiés.

Solaris10 1/06 : à partir de cette version, IKE est entièrement compatible avec la prise en charge NAT-Traversal comme décrit dans le document RFC 3947 et RFC 3948. Les opérations IKE utilisent la bibliothèque PKCS #11 à partir de la structure cryptographique, ce qui améliore les performances.

La structure cryptographique fournit un fichier keystore de clés softtoken pour les applications qui utilisent le métaconnecteur. Lorsque IKE utilise le métaconnecteur, vous avez la possibilité de stocker les clés sur un disque, sur une carte connectée ou dans le fichier keystore de clés softtoken.

Introduction à IPsec

Pour protéger les paquets IP, IPsec les chiffre et/ou les authentifie. IPsec s'exécute au sein du module IP, bien en dessous de la couche d'application. Par conséquent, une application Internet peut tirer profit d'IPsec sans pour autant avoir à modifier sa configuration. Une utilisation à bon escient d'IPsec en fait un outil efficace de sécurisation du trafic réseau.

La protection IPsec implique cinq composants principaux :

IPsec applique les mécanismes de sécurité aux datagrammes IP circulant en direction de l'adresse IP de destination. À l'aide des informations contenues dans la base de données SADB, le destinataire vérifie que les paquets entrants sont légitimes et les déchiffre. Les applications peuvent appeler IPsec pour appliquer les mécanismes aux datagrammes IP au niveau de chaque socket.

Notez que le comportement des sockets diffère en fonction des ports :

RFC IPsec

Le groupe IETF (Internet Engineering Task Force) a publié un certain nombre de documents RFC (Request for Comments, demande de commentaires) décrivant l'architecture de sécurité de la couche IP. Tous les RFC constituent la propriété intellectuelle de l'Internet Society. Pour plus d'informations sur les RFC, reportez-vous au site Web http://ietf.org/. Les références de sécurité IP les plus générales sont couvertes par les RFC suivants :

Terminologie IPsec

Les documents RFC IPsec définissent un certain nombre de termes qui s'avèrent utiles lors de l'implémentation d'IPsec sur des systèmes. Les tableaux suivants répertorient les termes IPsec, leur acronyme et leur définition. Le Tableau 22–1 dresse la liste des termes de négociation de clé.

Tableau 19–1 Termes IPsec, acronymes et usages

Terme IPsec 

Acronymes 

Définition 

Association de sécurité 

SA (Security Association) 

Connexion unique entre deux nœuds sur un réseau. La connexion est définie par les trois éléments suivants : un protocole de sécurité, un index de paramètre de sécurité et une destination IP. La destination IP peut être une adresse IP ou un socket. 

Base de données d'associations de sécurité 

SADB (Security Associations Database) 

Base de données contenant toutes les associations de sécurité actives. 

Index de paramètre de sécurité 

SPI (Security Parameter Index) 

Valeur d'indexation d'une association de sécurité. Une SPI est une valeur 32 bits qui différencie les SA partageant une destination IP et un protocole de sécurité. 

Base de données de stratégie de sécurité

SPD (Security Policy Database) 

Base de données déterminant si les paquets entrants et sortants présentent le niveau de protection spécifié. 

Échange de clés 

 

Processus de génération de clés pour les algorithmes cryptographiques asymétriques. Les principales méthodes utilisées sont les protocoles RSA et Diffie-Hellman. 

Protocole Diffie-Hellman 

DH 

Protocole d'échange de clés impliquant la génération et l'authentification de clés et souvent appelé échange de clés authentifiées.

Protocole RSA 

RSA 

Protocole d'échange de clés impliquant la génération et la distribution de clés, Ce protocole porte le nom de ses trois créateurs : Rivest, Shamir et Adleman. 

Association de sécurité Internet et protocole de gestion des clés 

ISAKMP (Internet Security Association and Key Management Protocol) 

Structure courante d'établissement du format des attributs SA, et de négociation, modification et suppression des SA. ISAKMP est le standard IETF de gestion des SA IPsec. 

Flux de paquets IPsec

La Figure 19–1 illustre la procédure suivie par un paquet adressé IP, en tant que partie intégrante d'un datagramme IP lors d'un appel IPsec sur un paquet sortant. Le diagramme du flux indique l'endroit auquel les en-têtes d'authentification AH et les associations de sécurité ESP sont susceptibles d'être appliqués au paquet. Les méthodes d'application de ces entités et de sélection des algorithmes sont décrites dans les sections suivantes.

La Figure 19–2 illustre le processus entrant IPsec.

Figure 19–1 Application d'IPsec au processus de paquet sortant

Le diagramme du flux indique que le paquet sortant est protégé d'abord par ESP, puis par AH. Le paquet se dirige ensuite vers un tunnel ou une interface physique.

Figure 19–2 Application d'IPsec au processus de paquet entrant

Le diagramme du flux indique qu'IPsec traite d'abord l'en-tête AH, puis l'en-tête ESP sur les paquets entrants. Tout paquet dont la protection est insuffisante est abandonné.

Associations de sécurité IPsec

Uneassociation de sécurité (SA, Security Association) IPsec spécifie les propriétés de sécurité que reconnaissent les hôtes lors de la communication. Une seule SA protège les données dans une direction. La protection s'applique à un seul hôte ou à une adresse de groupe (multidiffusion). La communication s'effectuant généralement entre homologues ou entre client et serveur, la sécurité du trafic dans les deux directions requiert la présence de deux SA.

Les trois éléments suivants identifient une SA IPsec de manière unique :

Le SPI, valeur arbitraire 32 bits, est transmis avec un paquet AH ou ESP. Les pages de manuel ipsecah(7P) et ipsecesp(7P) expliquent l'étendue de la protection AH et ESP. Une somme de contrôle d'intégrité permet d'authentifier un paquet. En cas d'échec de l'authentification, le paquet est rejeté.

Les associations de sécurité sont stockées dans une base de données d'associations de sécurité (SADB). Un moteur d'administration socket, l'interface PF_KEY, autorise les applications privilégiées à gérer la base de données. Par exemple, l'application IKE et la commande ipseckeys font appel à l'interface socket PF_KEY.

Gestion des clés dans IPsec

Les associations de sécurité (SA) requièrent des numéros de clé pour l'authentification et le chiffrement. Le processus permettant de gérer ces numéros de clés est appelé la gestion des clés. Le protocole IKE (Internet Key Exchange, échange de clé Internet) gère les clés automatiquement. La commande ipseckey permet la gestion manuelle des clés, le cas échéant.

Les SA sur les paquets IPv4 et IPv6 peuvent recourir à chacune des méthodes. Il est recommandé d'utiliser la gestion automatique à moins d'avoir une bonne raison de préférer la gestion manuelle. Par exemple, la gestion manuelle de clés s'impose dans le cadre d'interopérations avec des systèmes autres que les systèmes Solaris.

Dans la version actuelle, l'utilitaire SMF fournit les services de gestion de clés pour IPsec :

Dans les versions antérieures à la version Solaris 10 4/09, les commandes in.iked et ipseckey permettent de gérer les numéros de clé.

Mécanismes de protection IPsec

IPsec offre deux protocoles de sécurité dans le cadre de la protection des données :

AH protège les données à l'aide d'un algorithme d'authentification. ESP protège les données à l'aide d'un algorithme de chiffrement, mais peut avoir recours à un algorithme d'authentification facultatif. On appelle mécanisme l'implémentation d'un algorithme.

En-tête Authentification

L'en-tête d'authentification offre l'authentification des données, un niveau élevé d'intégrité et la protection de rediffusion des datagrammes IP. AH protège la majeure partie du datagramme IP. Comme l'illustre la figure suivante, AH est inséré entre l'en-tête IP et l'en-tête de transport.

Dans le diagramme, l'en-tête AH apparaît entre les en-têtes IP et TCP.

L'en-tête de transport peut être TCP, UDP, SCTP ou ICMP. Dans le cas de l'utilisation d'un tunnel, l'en-tête de transport peut être un autre en-tête IP.

ESP (Encapsulating Security Payload, association de sécurité)

Le module protocole ESP assure la confidentialité des encapsulations ESP. ESP propose également les services AH. Toutefois, ESP n'offre sa protection qu'à la partie des datagrammes d'encapsulation ESP. ESP fournit des services d'authentification facultatifs afin d'assurer l'intégrité du paquet protégé. Du fait qu'ESP utilise une technologie de chiffrement, un système fournissant ESP peut être soumis à des lois sur le contrôle des importations et exportations.

ESP encapsule ses données de sorte à protéger uniquement les données figurant à la suite de son commencement dans le datagramme, comme illustré ci-dessous.

Dans le diagramme, l'en-tête ESP apparaît entre les en-têtes IP et TCP. L'en-tête TCP est chiffré par l'en-tête ESP.

Dans un paquet TCP, ESP encapsule uniquement l'en-tête TCP et ses données. Si le paquet est un datagramme IP-in-IP, ESP protège le datagramme IP interne. La stratégie par socket permet l'auto-encapsulation. Ainsi, ESP peut encapsuler les options IP, le cas échéant.

Lorsque l'auto-encapsulation est définie, l'en-tête IP est copié afin de créer un datagramme IP-in-IP. Par exemple, lorsque l'auto-encapsulation n'est pas définie sur un socket TCP, le datagramme est envoyé dans le format suivant :


[ IP(a -> b) options + TCP + data ]

Lorsque l'auto-encapsulation est définie sur ce socket TCP, le datagramme est envoyé dans le format suivant :


[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]

Pour de plus amples informations, reportez-vous à la section Modes Transport et Tunnel dans IPsec.

Considérations de sécurité lors de l'utilisation de AH et ESP

Le tableau suivant permet de comparer les protections AH et ESP.

Tableau 19–2 Protections assurées par AH et ESP dans IPsec

Protocole 

Paquets protégés 

Protection 

Attaques contrées 

AH 

Protection des paquets de l'en-tête IP jusqu'à l'en-tête de transport 

Intégrité élevée, authentification des données : 

  • réception garantie des données exactes envoyées par l'expéditeur

  • attaques par rejeu possibles lorsqu'un AH n'active pas la protection par rejeu

Rejeu, couper-coller 

fournisseur de services aux entreprises 

Protection des paquets figurant à la suite du début d'ESP dans le datagramme 

Chiffrement du datagramme IP à l'aide de l'option de chiffrement Confidentialité garantie 

Écoute électronique 

Protection identique à la protection AH à l'aide de l'option d'authentification 

Rejeu, couper-coller 

Intégrité élevée, authentification des données et confidentialité à l'aide des deux options 

Rejeu, couper-coller, écoute électronique 

Authentification et chiffrement dans IPsec

Les protocoles de sécurité IPsec font appel à deux types d'algorithmes : les algorithmes d'authentification et les algorithmes de chiffrement. Le module AH recourt aux algorithmes d'authentification. Le module ESP peut utiliser aussi bien les algorithmes d'authentification que les algorithmes de chiffrement. La commande ipsecalgs affiche la liste des algorithmes présents sur le système, ainsi que leurs propriétés. Pour plus d'informations, reportez-vous à la page de manuel ipsecalgs(1M) Vous pouvez aussi utiliser les fonctions décrites dans la page de manuel getipsecalgbyname(3NSL)pour obtenir les propriétés des algorithmes.

Pour accéder aux algorithmes sur un système Solaris, IPsec fait appel à la structure cryptographique Solaris. Celle-ci offre un référentiel central d'algorithmes, en plus d'autres services. Elle permet à IPsec de tirer profit des accélérateurs cryptographiques hautes performances et offre des fonctions de contrôle de ressources. Par exemple, la structure permet de limiter le temps CPU consacré aux opérations cryptographiques dans le noyau.

Pour plus d'informations, consultez les références suivantes :

Algorithmes d'authentification dans IPsec

Les algorithmes d'authentification génèrent une valeur de somme de contrôle d'intégrité, digest, à partir des données et d'une clé. Le module AH recourt aux algorithmes d'authentification. Le module ESP peut également y avoir recours.

Algorithmes de chiffrement dans IPsec

Les algorithmes de chiffrement chiffrent les données à l'aide d'une clé. Dans IPsec, le module ESP fait appel aux algorithmes de chiffrement. Les algorithmes agissent sur les données dans des unités d'une taille de bloc.

Les diverses versions du SE Solaris10 offrent différents algorithmes de chiffrement par défaut.

Attention – Attention –

À partir de la version Solaris 10 7/07, n'ajoutez plus Solaris Encryption Kit à votre système. Le kit effectue une mise à niveau inférieure du patch de chiffrement de votre système. Le kit n'est pas compatible avec le chiffrement de votre système.

Stratégies de protection IPsec

Les stratégies de protection IPsec peuvent recourir aux mécanismes de sécurité, quels qu'ils soient. Vous pouvez appliquer les stratégies IPsec aux niveaux suivants :

IPsec applique la stratégie à l'échelle du système aux datagrammes entrants et sortants. Les datagrammes sortants sont envoyés avec ou sans protection. Si la protection est appliquée, les algorithmes sont soit spécifiques, soit non spécifiques. Vous pouvez appliquer d'autres règles aux datagrammes sortants, en raison des données supplémentaires connues du système. Les datagrammes sortants peuvent être acceptés ou rejetés. La décision d'accepter ou de rejeter un datagramme sortant est fonction de plusieurs critères qui peuvent se chevaucher et être contradictoires. Pour résoudre les conflits éventuels, il faut identifier la règle à analyser en premier. Le trafic est accepté automatiquement, sauf si une entrée de stratégie indique qu'il doit ignorer toutes les autres stratégies.

La stratégie qui protège normalement un datagramme peut être ignorée. Vous pouvez spécifier une exception dans la stratégie à l'échelle du système ou demander un contournement dans la stratégie par socket. Au niveau du trafic système, les stratégies sont mises en œuvre, mais les mécanismes de sécurité à proprement parler ne sont pas appliqués. En revanche, la stratégie sortante sur un paquet interne au système se traduit par un paquet sortant auquel ces mécanismes ont été appliqués.

La configuration des stratégies IPsec s'effectue à l'aide du fichier ipsecinit.conf et de la commande ipsecconf. La page de manuel ipsecconf(1M) contient des exemples et des explications complémentaires.

Modes Transport et Tunnel dans IPsec

Les normes IPsec définissent deux modes distincts d'opération IPsec : le mode Transport et le mode Tunnel. Ces modes n'ont aucune incidence sur le codage des paquets. Les paquets sont protégés par AH, ESP ou ces deux protocoles dans chaque mode. L'application de la stratégie des modes est différente lorsque le paquet interne est un paquet IP :

En mode Transport, l'en-tête extérieur ainsi que l'en-tête suivant et tout port pris en charge par celui-ci permettent de déterminer la stratégie IPsec. En fait, IPsec peut mettre en œuvre différentes stratégies en mode Transport entre deux adresses IP au niveau d'un seul port. Par exemple, si l'en-tête suivant est un en-tête TCP, qui prend en charge les ports, la stratégie IPsec peut alors être définie pour un port TCP de l'adresse IP externe. De même, si l'en-tête suivant est IP, l'en-tête extérieur et l'en-tête IP intérieur permettent de déterminer la stratégie IPsec.

Le mode Tunnel ne fonctionne que pour les datagrammes IP-in-IP. La mise sous tunnel en mode Tunnel peut s'avérer utile lorsque des personnes travaillant à domicile se connectent à un emplacement central. En mode Tunnel, la stratégie IPsec est mise en œuvre sur le contenu du datagramme IP interne. Différentes stratégies IPsec peuvent être mises en œuvre pour différentes adresses IP internes. En d'autres termes, l'en-tête IP interne, ainsi que son en-tête suivant et les ports que ce dernier prend en charge, peuvent mettre en œuvre une stratégie. Contrairement au mode Transport, le mode Tunnel ne permet pas à l'en-tête IP extérieur de dicter la stratégie de son datagramme IP interne.

Par conséquent, en mode Tunnel, la stratégie IPsec peut être spécifiée pour les sous-réseaux d'un LAN derrière un routeur et pour les ports de ces sous-réseaux. La stratégie IPsec peut également être spécifiée pour des adresses IP données (des hôtes) sur ces sous-réseaux. Les ports de ces hôtes peuvent aussi avoir une stratégie IPsec spécifique. Toutefois, si un protocole de routage dynamique est exécuté sur un tunnel, veillez à ne pas utiliser de sélection de sous-réseau ou d'adresse, car la vue de la topologie réseau sur le réseau homologue pourrait être modifiée. Les modifications annuleraient la stratégie IPsec statique. La section Protection d'un VPN à l'aide d'IPsec contient des exemples de mises en tunnel comprenant la configuration de routes statiques.

Dans SE Solaris, le , mode Tunnel peut être appliquée uniquement dans une interface de réseau de tunnels IP. La commande ipsecconf fournit un mot-clé tunnel pour sélectionner une interface de réseau de tunnels IP. Lorsque le mot-clé tunnel figure dans une règle, tous les sélecteurs spécifiés dans cette règle s'appliquent au paquet interne.

En mode Transport, ESP et/ou AH peuvent protéger le datagramme.

La figure suivante illustre un en-tête IP avec un paquet TCP non protégé.

Figure 19–3 Paquet IP non protégé transportant des informations TCP

Dans le diagramme, l'en-tête IP est suivi de l'en-tête TCP. L'en-tête TCP n'est pas protégé.

En mode Transport, ESP protège les données, comme illustré ci-dessous. La zone ombrée indique la partie chiffrée du paquet.

Figure 19–4 Paquet IP protégé transportant des informations TCP

Dans le diagramme, l'en-tête ESP apparaît entre les en-têtes IP et TCP. L'en-tête TCP est chiffré par l'en-tête ESP.

En mode Transport, AH protège les données comme illustré ci-dessous.

Figure 19–5 Paquet protégé par un en-tête d'authentification

Dans le diagramme, l'en-tête AH apparaît entre les en-têtes IP et TCP.

AH couvre en fait les données avant leur apparition dans le datagramme. Par conséquent, la protection assurée par AH, même en mode Transport, couvre en partie l'en-tête IP.

En mode Tunnel, l'intégralité du datagramme figure à l'intérieur de la protection d'un en-tête IPsec. Le datagramme de la Figure 19–3 est protégé en mode Tunnel par un en-tête IPsec externe, ESP dans ce cas, comme indiqué sur l'illustration suivante.

Figure 19–6 Paquet IPsec protégé en mode Tunnel

Le diagramme illustre l'en-tête ESP après l'en-tête IP et avant un en-tête IP et un en-tête TCP. Les deux derniers en-têtes sont protégés par chiffrement.

La commande ipsecconf inclut des mots-clés permettant de définir des tunnels en mode Tunnel ou Transport.

Réseaux privés virtuels et IPsec

Un tunnel configuré est une interface point-à-point. Le tunnel permet l'encapsulation d'un paquet IP dans un autre paquet IP. Un tunnel correctement configuré requiert une source et une destination. Pour plus d'informations, reportez-vous à la page de manuel tun(7M) et à la section Configuration de tunnels pour la prise en charge d'IPv6.

Un tunnel crée une interface physique liée à IP. L'intégrité du lien physique est fonction des protocoles de sécurité sous-jacents. La configuration sécurisée des associations de sécurité (SA) rend le tunnel digne de confiance. Les paquets sortant du tunnel doivent provenir de l'homologue spécifié dans la destination de tunnel. Si la confiance est établie, vous pouvez avoir recours au transfert IP par interface pour créer un VPN.

Vous pouvez créer un VPN à l'aide d'IPsec. IPsec sécurise la connexion. Par exemple, une organisation ayant recours à la technologie VPN pour connecter deux bureaux de réseaux distincts peut déployer IPsec pour sécuriser le trafic entre ces deux bureaux.

Dans l'illustration suivante, deux bureaux utilisent Internet pour constituer leur VPN, avec IPsec déployé sur leurs systèmes réseau.

Figure 19–7 Réseau privé virtuel

Dans le diagramme, les bureaux 1 et 2 communiquent par le biais de l'interface hme0. Chaque bureau utilise hme1 pour la communication interne.

La section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 contient un exemple détaillé de configuration.

Un exemple similaire avec des adresses IPv6 est fourni à la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv6.

Passage de la translation d'adresses et IPsec

IKE peut négocier des SA IPsec dans une zone NAT Cela permet aux systèmes de se connecter en toute sécurité à partir d'un réseau distant, même lorsqu'ils résident derrière un périphérique NAT. Par exemple, les employés travaillant à domicile ou se connectant depuis un site de conférence peuvent protéger leur trafic à l'aide d'IPsec.

NAT est l'acronyme de Network Address Translation (translation d'adresse réseau). Un routeur NAT permet d'associer une adresse interne privée à une adresse Internet unique. Les routeurs NAT équipent de nombreux points d'accès publics à Internet, comme ceux qu'on trouve dans les hôtels. Pour plus d'informations, reportez-vous à la section Utilisation de la fonctionnalité NAT de Oracle Solaris IP Filter.

La capacité à utiliser IKE lorsqu'un boîtier NAT est placé entre deux systèmes communiquant est appelé NAT Traversal ou NAT-T. Dans la version Solaris10, NAT-T présente les limitations suivantes :

Les RFC suivants décrivent la fonctionnalité NAT et les limites de NAT-T. Vous pouvez vous procurer des copies de ces RFC sur le site http://www.rfc-editor.org.

Pour une utilisation conjointe de IPsec et NAT, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des tâches).

IPsec et SCTP

Le système d'exploitation Solaris prend en charge le protocole SCTP (Streams Control Transmission Protocol). Bien que prise en charge, l'utilisation du protocole SCTP et du numéro de port SCTP dans le cadre de la spécification de la stratégie IPsec n'est pas stable. Les extensions IPsec pour SCTP spécifiées dans le document RFC 3554 ne sont pas encore implémentées. Ces restrictions peuvent être source de complications lors de la création de la stratégie IPsec pour SCPT.

SCTP peut avoir recours à plusieurs adresses source et cible dans le cadre d'une association SCTP unique. Lorsque la stratégie IPsec est appliquée à une seule adresse source ou cible, la communication peut échouer si SCTP change l'adresse source ou cible de cette association. La stratégie IPsec reconnaît uniquement l'adresse d'origine. Pour plus d'informations sur SCTP, consultez les documents RFC et Protocol SCTP.

IPsec et les zones Solaris

Pour les zones IP partagées, la stratégie IPsec est configurée à partir de la zone globale. Le fichier de configuration de la stratégie IPsec, ipsecinit.conf, existe uniquement dans la zone globale. Le fichier peut contenir des entrées s'appliquant aux zones non globales et des entrées s'appliquant à la zone globale.

Pour les zones IP exclusives, la stratégie IPsec est configurée dans la zone non globale.

Pour plus d'informations à propos de l'utilisation d'IPsec avec des zones, reportez-vous à la section Protection du trafic à l'aide d'IPsec. Pour plus d'informations sur les zones, reportez-vous au Chapitre 16, Introduction aux zones Solaris du Guide d’administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris.

IPsec et domaines logiques

Le protocole IPsec fonctionne avec des domaines logiques. Le domaine logique doit être en cours d'exécution sur une version du système d'exploitation Solaris comprenant le protocole IPsec, comme la version Solaris 10.

Pour créer des domaines logiques, vous devez utiliser Oracle VM Server pour SPARC. Cette application s'appelait auparavant Sun Logical Domains. Pour savoir comment configurer des domaines logiques, reportez-vous au Logical Domains 1.2 Administration Guide ou au Oracle VM Server for SPARC 2.0 Administration Guide.

Fichiers et utilitaires IPsec

Le Tableau 19–3 décrit les fichiers, commandes et identificateurs de service utilisés pour configurer et gérer IPsec. Exhaustif, ce tableau inclut les commandes et fichiers de gestion des clés.

À partir de la version Solaris 10 4/09, IPsec est géré par SMF. Pour plus d'informations sur les identificateurs de services, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.

Tableau 19–3 Liste des utilitaires et fichiers IPsec sélectionnés

Utilitaire IPsec, fichier ou service 

Description 

Page de manuel 

svc:/network/ipsec/ipsecalgs

Dans la version actuelle, le service SMF qui gère les algorithmes IPsec. 

smf(5), ipsecalgs(1M)

svc:/network/ipsec/manual-key

Dans la version actuelle, le service SMF qui gère les associations de sécurité (SA) manuelles.  

smf(5), ipseckey(1M)

svc:/network/ipsec/policy

Dans la version actuelle, le service SMF qui gère la stratégie IPsec.

smf(5), ipsecconf(1M)

svc:/network/ipsec/ike

Dans la version actuelle, le service SMF pour la gestion automatique des SA IPsec.  

smf(5), in.iked(1M)

Fichier /etc/inet/ipsecinit.conf

Fichier de stratégie IPsec. Dans les versions antérieures à la version Solaris 10 4/09, si ce fichier existe, IPsec est activé au démarrage.

Dans la version actuelle, le service policy de SMF utilise ce fichier pour configurer la stratégie IPsec lors de l'initialisation du système.

ipsecconf(1M)

Commande ipsecconf

Commande de stratégie IPsec. Utile pour afficher et modifier la stratégie IPsec actuelle, ainsi que pour effectuer des tests. Dans les versions antérieures à la version Solaris 10 4/09, les scripts d'initialisation utilisent ipsecconf pour lire le fichier /etc/inet/ipsecinit.conf et activer IPsec.

Dans la version actuelle, ipsecconf est utilisé par le service policy de SMF pour configurer la stratégie IPsec lors de l'initialisation du système.

ipsecconf(1M)

Interface socket PF_KEY

SADB (Interface for Security Associations Database, interface de la base de données des associations de sécurité). Responsable de la gestion manuelle et automatique des clés.

pf_key(7P)

Commande ipseckey

Commandes de génération de clés pour les SA IPsec ipseckey est un point d'entrée de commandes de l'interface PF_KEY. ipseckey permet de créer, supprimer ou modifier les SA.

ipseckey(1M)

Fichier /etc/inet/secret/ipseckeys

Clés pour SA IPsec. Dans les versions antérieures à la version Solaris 10 4/09, si le fichier ipsecinit.conf existe, le fichier ipseckeys est automatiquement lu au démarrage.

Dans la version actuelle, ipseckeys est utilisé par le service manual-key de SMF pour configurer manuellement les SA à l'initialisation du système.

 

Commande ipsecalgs

Commande d'algorithmes IPsec. Utile pour l'affichage et la modification de la liste d'algorithmes IPsec et de leurs propriétés.

Dans la version actuelle, est utilisée par le service ipsecalgs de SMF pour synchroniser les algorithmes IPsec connus avec le noyau, à l'initialisation du système.

ipsecalgs(1M)

Fichier /etc/inet/ipsecalgs

Contient les définitions d'algorithme et les protocoles IPsec configurés. Ce fichier est géré par la commande ipsecalgs et ne doit jamais être modifié manuellement.

 

Fichier /etc/inet/ike/config

Fichier de configuration et de stratégie IKE. Par défaut, ce fichier n'existe pas. Dans les versions antérieures à la version Solaris 10 4/09, si ce fichier existe, le démon IKE, in.iked, permet la gestion automatique des clés. La gestion se base sur des règles et des paramètres généraux figurant dans le fichier /etc/inet/ike/config. Reportez-vous à la section Utilitaires et fichiers IKE.

Dans la version actuelle, si ce fichier existe, le service svc:/network/ipsec/ike lance le démon IKE, in.iked pour la gestion automatique des clés.

ike.config(4)

Modifications IPsec dans la version Solaris10

Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10. À partir de la version Solaris 9, IPsec inclut les fonctions suivantes :