Les clés prépartagées sont la méthode d'authentification la plus simple pour IKE. Elles s'utilisent notamment lors de la configuration du protocole IKE sur deux systèmes gérés par le même administrateur. N'oubliez cependant pas que, contrairement aux certificats de clés publiques, les clés prépartagées sont liées à une adresse IP donnée et ne peuvent pas s'utiliser avec des systèmes portables ou des systèmes susceptibles d'être renumérotés. Tenez également compte du fait que, si vous utilisez des clés prépartagées, vous ne pourrez pas décharger de calculs IKE sur le matériel connecté.
La longueur des clés des algorithmes d'implémentation du protocole IKE est variable. Elle dépend du niveau de sécurité dont vous souhaitez doter le site. En règle générale, la longueur des clés est proportionnelle au niveau de sécurité.
Les noms de systèmes choisis pour illustrer cette procédure sont : enigma et partym. Remplacez enigma et partym par les noms de vos systèmes.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.
Copiez le fichier /etc/inet/ike/config.sample dans le fichier /etc/inet/ike/config sur chacun des systèmes.
Entrez les règles et paramètres globaux dans le fichier ike/config sur chacun des systèmes.
Les règles et paramètres globaux de ce fichier doivent garantir le fonctionnement de la stratégie IPsec du fichier ipsecinit.conf. Les exemples ike/config ci-dessous vont de pair avec les exemples ipsecinit.conf de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec.
Modifiez par exemple le fichier /etc/inet/ike/config sur le système enigma :
### ike/config file on enigma, 192.168.116.16 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 } |
Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.
Modifiez le fichier /etc/inet/ike/config sur le système partym :
### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 } |
Vérifiez la syntaxe du fichier sur chacun des systèmes.
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config |
Générez des nombres aléatoires que vous utiliserez comme numéros de clé.
Si votre site possède un générateur de nombres aléatoires, utilisez-le. Sur un système Solaris, vous pouvez utiliser la commande od. La commande suivante vous permet par exemple d'imprimer deux lignes de nombres hexadécimaux :
% od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d |
Pour plus de détails sur la commande od, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris et à la page de manuel od(1).
D'autres systèmes d'exploitation peuvent nécessiter des numéros de clé au format ASCII. Pour générer une clé identique dans les deux formats, hexadécimal et ASCII, reportez-vous à l'Exemple 23–1.
Créez une clé à partir du résultat de l'Étape 5.
f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e |
Pour cette procédure, l'algorithme d'authentification est SHA–1, comme indiqué à l'Étape 3. La taille du hachage, c'est-à-dire la taille de la sortie de l'algorithme d'authentification, détermine la taille minimale recommandée pour une clé prépartagée. La taille de la sortie de l'algorithme SHA–1 est de 160 bits ou 40 caractères. Dans cet exemple, la clé possède 56 caractères, ce qui permet au protocole IKE de disposer de numéros de clé supplémentaires.
Créez un fichier /etc/inet/secret/ike.preshare sur chacun des systèmes.
Placez la clé prépartagée dans chacun des fichiers.
Sur le système enigma par exemple, le fichier ike.preshared se présente comme suit :
# ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e } |
Sur le système partym, le fichier ike.preshared se présente comme suit :
# ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e } |
Les clés prépartagées doivent être identiques sur chacun des systèmes.
Le protocole IPsec de Solaris fonctionne avec d'autres systèmes d'exploitation. Si votre système communique avec un système qui requiert des clés prépartagées ASCII, vous devez générer une clé dans les deux formats, hexadécimal et ASCII.
Dans cet exemple, l'administrateur système de Solaris veut générer une clé de 56 caractères. Il utilise la commande ci-dessous pour générer une clé hexadécimale à partir d'une phrase de passe ASCII. L'option -tx1 imprime les octets un par un sur tous les systèmes Solaris.
# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \ tr -d '\n' | tr -d ' ' | awk '{print}' 7061706965726d616368652077697468206361736865777320616e64 |
Après suppression des décalages et concaténation de la sortie hexadécimale, la clé hexadécimale pour le système Solaris est 7061706965726d616368652077697468206361736865777320616e64. L'administrateur place cette valeur dans le fichier ike.preshared sur le système Solaris.
# Shared key in hex (192 bits) key 7061706965726d616368652077697468206361736865777320616e64 |
Sur le système qui requiert des clés prépartagées ASCII, la phrase de passe correspond à la clé prépartagée. L'administrateur Solaris communique la phrase de passe papiermache with cashews and à l'autre administrateur par téléphone.
Cette procédure permet de remplacer une clé prépartagée existante à intervalles réguliers.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.
Générez des nombres aléatoires et créez une clé possédant une longueur appropriée.
Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.
Remplacez la clé actuelle par une nouvelle clé.
À titre d'exemple, sur les hôtes enigma et partym, cela revient à remplacer la valeur de key stockée dans le fichier /etc/inet/secret/ike.preshared par un nouveau nombre possédant la même longueur.
Lisez la nouvelle clé dans le noyau.
À partir de la version Solaris 10 4/09 actualisez le service ike.
# svcadm refresh ike |
Si vous exécutez une version antérieure à la version Solaris 10 4/09, arrêtez et redémarrez le démon in.iked.
Vérifiez le niveau de privilège du démon in.iked.
# /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled |
Vous pouvez modifier les numéros de clé si la commande renvoie un niveau de privilège 0x1 ou 0x2. Si le niveau renvoyé est 0x0, vous ne pouvez ni modifier ni afficher les numéros de clé. Par défaut, le démon in.iked s'exécute au niveau de privilège 0x0.
Si le niveau de privilège est 0x0, arrêtez le démon et redémarrez-le.
Lorsque le démon redémarre, il lit la nouvelle version du fichier ike.preshared.
# pkill in.iked # /usr/lib/inet/in.iked |
Si le niveau de privilège est 0x1 ou 0x2, lisez la nouvelle version du fichier ike.preshared.
# ikeadm read preshared |
Par défaut, la commande ikeadm vous empêche de consulter les clés réelles dans le fichier de vidage d'une SA phase 1. L'affichage des clés est utile lors du débogage.
Pour afficher les clés réelles, vous devez augmenter le niveau de privilège du démon. Pour obtenir une description des niveaux de privilège, reportez-vous à la section Commande d'administration du protocole IKE .
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.
IKE est configuré et le service ike est en cours d'exécution.
Affichez les clés IKE prépartagées.
# ikeadm ikeadm> dump preshared |
Si une erreur se produit, vous devez augmenter le niveau de privilège du démon in.iked.
Augmentez le niveau de privilège du démon in.iked dans le référentiel SMF.
# svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat |
Augmentez le niveau de privilège du démon in.iked en cours d'exécution.
# svcadm refresh ike ; svcadm restart ike |
(Facultatif) Confirmez que le niveau de privilège est keymat.
# svcprop -p config/admin_privilege ike keymat |
Affichez les clés en exécutant de nouveau l'Étape 1.
Réappliquez le niveau de privilège de base au démon IKE.
Dans l'exemple suivant, l'administrateur affiche les clés sur un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur souhaite vérifier que les clés de ce système sont identiques aux clés du système communicant. Après avoir vérifié que les clés sont identiques sur les deux systèmes, l'administrateur rétablit le niveau de privilège sur 0.
Tout d'abord, l'administrateur détermine le niveau de privilège du démon in.iked.
adm1 # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled |
Le niveau de privilège n'étant pas 0x1 ni 0x2, l'administrateur arrête le démon in.iked, puis augmente le niveau de privilège sur 2.
adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
L'administrateur affiche les clés.
adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1). |
L'administrateur se connecte à distance au système communicant et détermine si les clés sont identiques.
L'administrateur rétablit ensuite le niveau de privilège de base.
# ikeadm set priv base |
Si vous ajoutez des entrées de stratégie IPsec pendant que IPsec and IKE sont en cours d'exécution, vous devez lire la nouvelle stratégie et les règles IKE dans le noyau. À partir de la version Solaris 10 4/09, redémarrez le service policy et actualisez le service ike une fois les nouvelles clés ajoutées.
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–3.
L'exécution de cette procédure nécessite le respect des conditions suivantes :
Le système enigma est paramétré selon la procédure décrite à la section Configuration du protocole IKE avec des clés prépartagées.
Le système enigma protégera son trafic avec un nouveau système, ada.
Le démon in.iked est exécuté sur les deux systèmes.
Les interfaces des systèmes figurent en tant qu'entrées dans le fichier /etc/hosts sur les deux systèmes. Ci-dessous un exemple d'entrée :
192.168.15.7 ada 192.168.116.16 enigma |
Cette procédure fonctionne également avec une adresse IPv6 du fichier /etc/inet/ipnodes. À partir de la version Solaris 10 6/07, les entrées IPv6 sont placées dans le fichier /etc/hosts.
Vous avez ajouté une nouvelle entrée de stratégie au fichier /etc/inet/ipsecinit.conf sur les deux systèmes. Ces entrées se présentent de la manière suivante :
# ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared} |
# ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared} |
Dans la version actuelle, vous avez vérifié la syntaxe du fichier /etc/inet/ipsecinit.conf sur les deux systèmes à l'aide de :
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.
Sur ce système, générez des nombres aléatoires et construisez une clé de 64 ou 448 bits.
Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.
Transmettez la clé à l'administrateur du système distant.
Vous devez tous deux ajouter simultanément la même clé prépartagée. La sécurité de cette clé est directement liée à celle du moyen de transmission. Utilisez donc de préférence un moyen hors bande de type courrier recommandé ou fax protégé. Vous pouvez également utiliser une session ssh pour administrer les deux systèmes.
Créez une règle pour la gestion des clés de enigma et ada par IKE.
Sur le système enigma, ajoutez la règle suivante au fichier /etc/inet/ike/config :
### ike/config file on enigma, 192.168.116.16 ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 } |
Sur le système ada, ajoutez la règle suivante :
### ike/config file on ada, 192.168.15.7 ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 } |
Assurez-vous que les clés IKE prépartagées sont disponibles lors de la réinitialisation.
Sur le système enigma, ajoutez les informations suivantes au fichier /etc/inet/secret/ike.preshared :
# ike.preshared on enigma for the ada interface # { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } |
Sur le système ada, ajoutez les informations suivantes au fichier ike.preshared :
# ike.preshared on ada for the enigma interface # { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } |
Sur chaque système, redémarrez le service de stratégie IPsec afin de sécuriser l'interface ajoutée.
# svcadm restart policy |
Sur chaque système, actualisez le service ike.
# svcadm refresh ike |
Assurez-vous que les systèmes peuvent communiquer entre eux.
Reportez-vous à la section Méthode de vérification de la concordance des clés prépartagées IKE.
Dans l'exemple suivant, l'administrateur ajoute une clé prépartagée à un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur suit la procédure précédente pour modifier les fichiers ike/config et ike.preshared et pour générer des clés et contacter le système distant. L'administrateur utilise différentes commandes pour lire la nouvelle stratégie IPsec et les nouvelles règles IKE dans le noyau.
Avant de générer une nouvelle clé, l'administrateur définit le niveau de privilège du démon in.iked sur 2.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
Après l'envoi de la clé à l'autre système et l'ajout d'une nouvelle clé au système, l'administrateur réduit le niveau de privilège.
# ikeadm set priv base |
Ensuite, l'administrateur lit la nouvelle stratégie IPsec dans le noyau.
# ipsecconf -a /etc/inet/ipsecinit.conf |
Enfin, l'administrateur lit les nouvelles règles IKE dans le noyau.
# ikeadm read rules |
La concordance clés prépartagées des systèmes communicants est nécessaire à l'authentification.
IPsec est configuré et a été activé entre les deux systèmes sur lesquels vous travaillez. Vous exécutez la version actuelle Solaris10.
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.
Sur chaque système, vérifiez le niveau de privilège du démon in.iked.
# svcprop -p config/admin_privilege ike base |
Si le niveau de privilège est keymat, passez à l'Étape 3.
Si le niveau de privilège est base ou modkeys, augmentez le niveau de privilège.
Effectuez une actualisation, puis redémarrez le service ike.
# svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat |
Affichez, sur chacun des systèmes, les informations concernant les clés prépartagées.
# ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym). |
Comparez les résultats obtenus.
Si les clés prépartagées ne sont pas identiques, remplacez l'une d'entre elles dans le fichier /etc/inet/secret/ike.preshared.
Lorsque la vérification est terminée, rétablissez le niveau de privilège par défaut sur chacun des systèmes.
# svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike |