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 |