Sécurisation du trafic entre deux systèmes à l'aide d'IPsec (Guide d'administration système : services IP)

Guide d'administration système : services IP

Sécurisation du trafic entre deux systèmes à l'aide d'IPsec

Cette procédure correspond à la configuration suivante :

Les systèmes s'appellent enigma et partym.
Chaque système possède deux adresses, une adresse IPv4 et une adresse IPv6.
Chaque système nécessite le chiffrement ESP avec l'algorithme AES, qui requiert une clé de 128 bits, ainsi que l'authentification ESP avec la synthèse des messages SHA1, qui requiert une clé de 160 bits.
Chaque système utilise des associations de sécurité partagées (SA, Security Associations).

Avec les SA partagées, une seule paire de SA est suffisante pour protéger les deux systèmes.

Avant de commencer

Vous devez vous trouver dans la zone globale pour configurer la stratégie IPsec pour le système ou pour une zone IP partagée. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale.

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.

Remarque –
Les connexions à distance peuvent compromettre la sécurité du trafic de données critiques. 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. Exécutez la commande ssh pour assurer une connexion à distance sécurisée. Voir l' Exemple 20–1.

Sur chaque système, vérifiez les entrées d'hôte.

Dans la version actuelle, ajoutez les entrées d'hôte au fichier /etc/inet/hosts.

Sur un système exécutant une version antérieure à la version Solaris 10 7/07, insérez les entrées IPv4 et IPv6 dans le fichier /etc/inet/ipnodes. Les entrées d'un système doivent être contiguës dans le fichier. Pour de plus amples informations sur les fichiers de configuration système, reportez-vous à la section Fichiers de configuration TCP/IP et au Chapitre 11Présentation détaillée de IPv6 (référence).

Si vous connectez des systèmes utilisant exclusivement des adresses IPv4, modifiez le fichier /etc/inet/hosts. Dans cet exemple, les systèmes à connecter s'exécutent dans une version Solaris antérieure et utilisent des adresses IPv6.
1. Sur un système appelé enigma, saisissez les lignes suivantes dans le fichier hosts ou ipnodes :
  # Secure communication with partym 192.168.13.213 partym 2001::eeee:3333:3333 partym
2. Sur un système appelé partym, saisissez les lignes suivantes dans le fichier hosts ou ipnodes :
  # Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 enigma
L'utilisation de services d'assignation de noms pour des noms symboliques comporte des risques.

Sur chaque système, créez le fichier de stratégie IPsec.

Le nom de fichier est /etc/inet/ipsecinit.conf. Vous en trouverez un exemple dans le fichier /etc/inet/ipsecinit.sample.

Ajoutez une entrée de stratégie IPsec au fichier ipsecinit.conf.
1. Sur le système enigma, ajoutez la stratégie ci-dessous :
  {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
2. Sur le système partym, ajoutez la même stratégie :
  {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
  La syntaxe des entrées de stratégie IPsec est décrite dans la page de manuel ipsecconf(1M).

Sur chaque système, ajoutez une paire de SA IPsec entre les deux systèmes.

Vous pouvez configurer le protocole IKE (Internet Key Exchange, échange de clé Internet) afin de créer automatiquement les SA. Vous pouvez également ajouter les SA manuellement.

Remarque –
Il est recommandé d'utiliser IKE, sauf si, pour des raisons spécifiques, vous devez générer les clés et les mettre à jour manuellement. La gestion des clés à l'aide d'IKE est plus sécurisée.
- Configurez IKE en suivant l'une des procédures de configuration décrites à la section Configuration du protocole IKE (liste des tâches). La syntaxe du fichier de configuration IKE est décrite à la page de manuel ike.config(4).
- Pour ajouter des SA manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

Activez la stratégie IPsec.
- Si vous exécutez une version antérieure à la version Solaris 10 4/09, réinitialisez le système.
  # init 6
  Reportez-vous ensuite à la section Vérification de la protection des paquets par IPsec.
- À partir de la version Solaris 10 4/09, actualisez le service IPsec et activez le service de gestion des clés.
  
  Suivez les étapes Étape 7 à Étape 10.

Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf
Corrigez les éventuelles erreurs, vérifiez la syntaxe du fichier, puis continuez.

Actualisez la stratégie IPsec.
# svcadm refresh svc:/network/ipsec/policy:default
La stratégie IPsec est activée par défaut. Actualisez-la. Si vous avez désactivé la stratégie IPsec, activez-la.
# svcadm enable svc:/network/ipsec/policy:default

Activez les clés pour IPsec.
- Si vous avez configuré le service IKE lors l'Étape 5, effectuez l'une des opérations suivantes :
  - Si le service ike n'est pas activé, activez-le.
    # svcadm enable svc:/network/ipsec/ike:default
  - Si le service ike est activé, redémarrez-le.
    # svcadm restart svc:/network/ipsec/ike:default
- Si vous avez configuré manuellement les clés lors de l'Étape 5, effectuez l'une des opérations suivantes :
  - Si le service manual-key n'est pas activé, activez-le.
    # svcadm enable svc:/network/ipsec/manual-key:default
  - Si le service manual-key est activé, actualisez-le.
    # svcadm refresh svc:/network/ipsec/manual-key:default

Assurez-vous que les paquets sont protégés.

La procédure est décrite à la section Vérification de la protection des paquets par IPsec.

Exemple 20–1 Ajout d'une stratégie IPsec lors de l'utilisation d'une connexion `ssh`

Dans cet exemple, l'administrateur en tant que superutilisateur configure la stratégie IPsec et des clés sur deux systèmes à l'aide de la commande ssh pour atteindre le second système. Pour plus d'informations, reportez-vous à la page de manuel ssh(1).

Tout d'abord, l'administrateur configure le premier système en effectuant les étapes Étape 2 à Étape 5 de la procédure précédente.
Ensuite, dans une autre fenêtre de terminal, l'administrateur utilise la commande ssh pour se connecter au deuxième système.
local-system # ssh other-system other-system #
Dans la fenêtre de terminal de la session ssh, l'administrateur configure la stratégie IPsec et les clés du second système en effectuant les étapes Étape 2 à Étape 6.
Ensuite, l'administrateur met fin à la session ssh.
other-system # exit local-system #
Enfin, l'administrateur active la stratégie IPsec sur le premier système en effectuant l'Étape 6.

La prochaine fois que les deux systèmes communiquent, y compris par le biais d'une connexion ssh, la communication est protégée par IPsec.

Exemple 20–2 Sécurisation du trafic à l'aide d'IPsec sans réinitialisation

L'exemple suivant est utile lorsque vous exécutez une version antérieure à la version Solaris 10 4/09. Dans votre version, IPsec n'est pas géré en tant que service. Cet exemple décrit l'implémentation d'IPsec dans un environnement de test. Dans un environnement de production, il est plus sécurisé de réinitialiser que d'exécuter la commande ipsecconf. Les considérations de sécurité sont indiquées à la fin de cet exemple.

Au lieu de réinitialiser à l'Étape 6, choisissez l'une des options suivantes :

Si vous utilisez IKE pour créer des numéros de clé, arrêtez le démon in.iked, puis relancez-le.
# pkill in.iked # /usr/lib/inet/in.iked
Si vous ajoutez des clés manuellement, exécutez la commande ipseckey afin d'ajouter les SA à la base de données.
# ipseckey -c -f /etc/inet/secret/ipseckeys
Ensuite, activez la stratégie IPsec à l'aide de la commande ipsecconf.
# ipsecconf -a /etc/inet/ipsecinit.conf

Considérations de sécurité : lisez l'avertissement qui s'affiche lorsque vous exécutez la commande ipsecconf. Un socket déjà verrouillé, c'est-à-dire un socket déjà utilisé, constitue une porte dérobée non sécurisée sur le système. Pour plus d'informations, reportez-vous à la section Considérations de sécurité à propos de ipsecinit.conf et ipsecconf.