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).
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 :
svc:/network/ipsec/policy:default
svc:/network/ipsec/ipsecalgs:default
Par défaut, les services de gestion des clés sont désactivés à l'initialisation du système :
svc:/network/ipsec/manual-key:default
svc:/network/ipsec/ike:default
Pour activer les stratégies IPsec sous SMF, effectuez les étapes suivantes :
Ajoutez des entrées de stratégie IPsec au fichier ipsecinit.conf.
Configurez le protocole IKE (Internet Key Exchange) ou configurez manuellement les clés.
Actualisez le service de stratégie IPsec.
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.
IPsec implémente les tunnels en mode Tunnel pour les réseaux privés virtuels (VPN, Virtual Private Network). En mode Tunnel, IPsec prend en charge plusieurs clients derrière un NAT unique. En mode Tunnel, IPsec est interopérable avec les implémentations des tunnels IP-in-IP d'autres constructeurs. IPsec prend toujours en charge les tunnels en mode Transport, ce qui garantit sa compatibilité avec les versions Solaris antérieures.
La syntaxe de création d'un tunnel est simplifiée. La commande ipsecconf a été étendue à la gestion de la stratégie IPsec. La commande ifconfig ne permet plus la gestion de la stratégie IPsec.
À partir de cette version, le fichier /etc/ipnodes est supprimé. Configurez les adresses de réseau IPv6 à l'aide du fichier /etc/hosts.
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.
Pour utiliser le fichier keystore de clés softtoken, reportez-vous à la page de manuel cryptoadm(1M).
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.
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 :
Protocoles de sécurité : les mécanismes de protection de datagramme IP. L'en-tête d'authentification (AH, Authentication Header) signe les paquets IP et garantit leur intégrité. Bien que le contenu du datagramme ne soit pas chiffré, le destinataire est sûr que le contenu du paquet n'a subi aucune modification et que l'expéditeur a envoyé les paquets. protocole ESP chiffre les données IP et obscurcit, par conséquent, le contenu des paquets lors de leur transmission. ESP garantit également l'intégrité des données par le biais d'une option d'algorithme d'authentification.
SADB (Security Associations Database, base de données des associations de sécurité) : base de données qui associe un protocole de sécurité à une adresse IP de destination et un numéro d'indexation. Ce numéro d'indexation est appelé index du paramètre de sécurité. Ces trois éléments (protocole de sécurité, adresse de destination et SPI) identifient un seul paquet IPsec légitime. La base de données garantit que le paquet protégé est reconnu par le récepteur à son arrivée. Elle permet également au récepteur de déchiffrer la communication, de vérifier que les paquets n'ont pas été altérés, de rassembler les paquets et de livrer les paquets à leur destination finale.
Gestion des clés : génération et distribution des clés des algorithmes de chiffrement et de SPI.
Mécanismes de sécurité : algorithmes de chiffrement et d'authentification qui protègent les données des datagrammes IP.
SPD (Security Policy Database, base de données de stratégie de sécurité) : base de données indiquant le niveau de protection à appliquer à un paquet. La base de données SPD filtre le trafic IP et identifie le mode de traitement des paquets. Un paquet peut être rejeté, passé au clair ou protégé à l'aide d'IPsec. En ce qui concerne les paquets sortants, les bases de données SPD et SADB déterminent le niveau de protection à appliquer. Pour les paquets entrants, la base de données SPD permet de déterminer l'acceptabilité du niveau de protection. Si le paquet est protégé par IPsec, une consultation de la base de données SPD est effectuée après déchiffrement et vérification du paquet.
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 :
Les SA par socket remplacent leur entrée de port correspondante dans la base de données SPD.
Par ailleurs, lorsque la stratégie IPsec est appliquée à un port sur lequel un socket est déjà connecté, le trafic qui utilise ce socket ne bénéficie pas de la protection IPsec.
En revanche, les sockets ouverts sur un port après l'application de la stratégie IPsec en bénéficient aussi.
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 :
RFC 2411, "IP Security Document Roadmap", novembre 1998 ;
RFC 2401, "Security Architecture for the Internet Protocol", novembre 1998 ;
RFC 2402, "IP Authentication Header", novembre 1998 ;
RFC 2406, "IP Encapsulating Security Payload (ESP)", novembre 1998 ;
RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)", novembre 1998 ;
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP", novembre 1998 ;
RFC 2409, "The Internet Key Exchange (IKE)", novembre 1998 ;
RFC 3554, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", juillet 2003 [ non implémenté dans la version Solaris10 ].
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é. |
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. |
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.
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 protocole de sécurité (AH ou ESP) ;
l'adresse IP de destination ;
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.
Pour une description détaillée de la SADB IPsec, reportez-vous à la section Base de données des associations de sécurité IPsec.
Pour plus d'informations sur la gestion de la SADB, consultez la page de manuel pf_key(7P).
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 :
Le service svc:/network/ipsec/ike:default correspond au service SMF utilisé pour la gestion automatique des clés. Le service ike exécute le démon in.iked pour la gestion automatique des clés. Le Chapitre 22Protocole IKE (présentation) propose une description du protocole IKE. Pour plus d'informations sur le démon in.iked, reportez-vous à la page de manuel in.iked(1M). Pour plus d'informations sur le service ike, reportez-vous à la section Utilitaire de gestion du service IKE.
Le service svc:/network/ipsec/manual-key:default correspond au service SMF utilisé pour la gestion manuelle des clés. Le service manual-key exécute la commande ipseckey avec de nombreuses options pour gérer les clés manuellement. La commande ipseckey est décrite à la section Utilitaires de génération de clés IPsec. Pour obtenir une description détaillée des options de la commande ipseckey, reportez-vous à la page de manuel ipseckey(1M).
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é.
Le démon in.iked permet la gestion automatique des clés. Le Chapitre 22Protocole IKE (présentation) propose une description du protocole IKE. Pour plus d'informations sur le démon in.iked, reportez-vous à la page de manuel in.iked(1M).
La commande ipseckey permet de gérer les clés manuellement. La section Utilitaires de génération de clés IPsec propose une description de cette commande. Pour obtenir une description détaillée des options de la commande ipseckey, reportez-vous à la page de manuel ipseckey(1M).
IPsec offre deux protocoles de sécurité dans le cadre de la protection des données :
AH (Authentication Header, en-tête d'authentification)
ESP (Encapsulating Security Payload, association de sécurité)
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.
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.
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.
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 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.
Le tableau suivant permet de comparer les protections AH et ESP.
Tableau 19–2 Protections assurées par AH et ESP 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 :
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.
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.
À 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.
À partir de la version Solaris 10 7/07, le contenu de Solaris Encryption Kit est installé par le support d'installation Solaris. Cette version intègre les algorithmes d'authentification SHA2 suivants : sha256, sha384 et sha512. Les implémentations SHA2 sont conformes à la spécification RFC 4868. Cette version ajoute également des groupes Diffie-Hellman plus grands : 2 048 bits (groupe 14), 3 072 bits (groupe 15) et 4 096 bits (groupe 16). Notez que les systèmes Sun alliés à la technologie CoolThreads permettent d'accélérer les groupes de 2 048 bits uniquement.
Dans les versions antérieures à Solaris 10 7/07, le support d'installation Solaris n'offre que des algorithmes de base ; toutefois, Solaris Encryption Kit vous permet d'ajouter des algorithmes plus avancés.
Par défaut, les algorithmes DES-CBC, 3DES-CBC, AES-CBC et Blowfish-CBC sont installés. Les tailles de clé prises en charge par les algorithmes AES-CBC et Blowfish-CBC ne peuvent excéder 128 bits.
Les algorithmes AES-CBC et Blowfish-CBC prenant en charge les tailles de clé supérieures à 128 bits sont disponibles dans IPsec si vous installez le kit de chiffrement Solaris. Toutefois, certains algorithmes de chiffrement ne sont pas disponibles en dehors des États-Unis. Le kit est disponible sur un CD distinct qui ne fait pas partie du coffret d'installation Solaris10. Pour l'installer, consultez le document Solaris 10 Encryption Kit Installation Guide. Pour plus d'informations, reportez-vous au centre de téléchargement Sun. Pour télécharger le kit, cliquez sur l'onglet Downloads A-Z, puis sur la lettre S. Solaris 10 Encryption Kit fait partie des 20 premières entrées.
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 :
à l'échelle du système ;
par socket.
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.
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 détermine la stratégie IPsec qui protège le paquet IP interne.
En mode Tunnel, le paquet IP interne détermine la stratégie IPsec qui protège son contenu.
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é.
En mode Transport, ESP protège les données, comme illustré ci-dessous. La zone ombrée indique la partie chiffrée du paquet.
En mode Transport, AH protège les données comme illustré ci-dessous.
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.
La commande ipsecconf inclut des mots-clés permettant de définir des tunnels en mode Tunnel ou Transport.
Pour plus d'informations sur la stratégie par socket, reportez-vous à la page de manuel ipsec(7P).
La section Utilisation d'IPsec pour protéger un serveur Web du trafic non-web. comprend un exemple de stratégie par socket.
Pour plus d'informations sur les tunnels, reportez-vous à la page de manuel ipsecconf(1M).
La section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 contient un exemple de configuration de tunnel.
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.
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.
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 :
NAT-T fonctionne uniquement sur les réseaux IPv4.
NAT-T ne peut pas tirer profit de l'accélération ESP IPsec que procure la carte Sun Crypto Accelerator 4000. Toutefois, l'accélération IKE avec la carte Sun Crypto Accelerator 4000 fonctionne.
Le protocole AH dépend d'un en-tête IP qui ne change pas ; de ce fait, AH ne peut pas fonctionner avec NAT-T. Le protocole ESP est utilisé avec NAT-T.
Le routeur NAT n'applique pas de règles de traitement particulières. Un routeur NAT obéissant à des règles de traitement IPsec pourrait intervenir dans l'implémentation de NAT-T.
NAT-T fonctionne uniquement lorsque l'initiateur IKE est le système derrière le routeur NAT. Un répondeur IKE ne peut pas se trouver derrière un routeur NAT, à moins que celui-ci ne soit programmé pour transférer des paquets IKE au système adéquat figurant derrière lui.
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.
RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)", janvier 2001 ;
RFC 3715, "IPsec-Network Address Translation (NAT) Compatibility Requirements", mars 2004 ;
RFC 3947, "Negotiation of NAT-Traversal in the IKE", janvier 2005 ;
RFC 3948, "UDP Encapsulation of IPsec Packets", janvier 2005.
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).
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.
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.
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.
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.
Pour obtenir les instructions relatives à l'implémentation IPsec sur le réseau, reportez-vous à la section Protection du trafic à l'aide d'IPsec (liste des tâches).
Pour plus d'informations sur les fichiers et utilitaires IPsec, consultez le Chapitre 21Architecture IPsec (référence).
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. | |
svc:/network/ipsec/manual-key |
Dans la version actuelle, le service SMF qui gère les associations de sécurité (SA) manuelles. | |
svc:/network/ipsec/policy |
Dans la version actuelle, le service SMF qui gère la stratégie IPsec. | |
svc:/network/ipsec/ike |
Dans la version actuelle, le service SMF pour la gestion automatique des SA IPsec. | |
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. | |
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. | |
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. | |
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. | |
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. | |
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. |
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 :
Lorsqu'une carte Sun Crypto Accelerator 4000 est connectée, elle met automatiquement en cache les SA IPsec des paquets faisant appel à son interface Ethernet. La carte accélère également le traitement des SA IPsec.
IPsec peut tirer profit de la gestion automatique des clés avec IKE sur réseaux IPv6. Pour plus d'informations, reportez-vous au Chapitre 22Protocole IKE (présentation).
Pour connaître les nouvelles fonctions IKE, reportez-vous à la section Modifications apportées à IKE dans Solaris10.
L'analyseur de la commande ipseckey offre une aide plus claire. La commande ipseckey monitor indique la date et l'heure de chaque événement. Pour plus d'informations, reportez-vous à la page de manuel ipseckey(1M).
Les algorithmes IPsec proviennent désormais d'un espace de stockage central, la structure cryptographique Solaris. La page de manuel ipsecalgs(1M) décrit les caractéristiques des algorithmes disponibles. Les algorithmes sont optimisés pour l'architecture sur laquelle ils s'exécutent. Pour obtenir une description de la structure, reportez-vous au Chapitre 13, Oracle Solaris Cryptographic Framework (Overview) du System Administration Guide: Security Services.
IPsec fonctionne dans la zone globale. La stratégie IPsec est gérée dans la zone globale pour une zone non globale. Les numéros de clé sont créés et gérés manuellement dans la zone globale pour une zone non globale. IKE ne permet pas de générer des clés pour une zone non globale. 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.
La stratégie IPsec peut fonctionner avec le protocole SCTP (Streams Control Transmission Protocol) et le numéro de port SCTP. Toutefois, l'implémentation reste incomplète. 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. Pour plus d'informations, reportez-vous aux RFC. Consultez également les documents IPsec et SCTP et Protocol SCTP.
IPsec et IKE peuvent protéger le trafic généré derrière un routeur NAT. Pour en savoir plus sur les restrictions, reportez-vous à la section Passage de la translation d'adresses et IPsec. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des tâches).