Chapitre 20 Configuration d'IPsec (tâches)

Ce chapitre fournit les procédures d'implémentation d'IPsec sur votre réseau. Les procédures sont décrites dans la liste des tâches ci-dessous :

• Protection du trafic à l'aide d'IPsec (liste des tâches)

• Protection d'un VPN à l'aide d'IPsec (liste des tâches)

Vous trouverez une présentation d'IPsec au Chapitre 19Architecture IPsec (présentation). Des informations de référence sur IPsec sont fournies au Chapitre 21Architecture IPsec (référence).

Protection du trafic à l'aide d'IPsec (liste des tâches)

La liste des tâches ci-dessous répertorie les procédures de configuration d'IPsec sur un ou plusieurs systèmes. En outre, vous trouverez des procédures utiles dans les sections d'exemples des pages de manuel ipsecconf(1M), ipseckey(1M) et ifconfig(1M).

Protection du trafic à l'aide d'IPsec

Cette section décrit les procédures permettant de sécuriser le trafic entre deux systèmes et de sécuriser un serveur Web. Pour protéger un VPN, reportez-vous à la section Protection d'un VPN à l'aide d'IPsec (liste des tâches) . Des procédures supplémentaires fournissent des numéros de clé et des associations de sécurité et vérifient que IPsec fonctionne tel qu'il est configuré.

Les informations ci-dessous s'appliquent à toutes les tâches de configuration IPsec :

• IPsec et zones : pour gérer les clés et la stratégie IPsec dans le cas d'une zone non globale IP partagée, créez le fichier de stratégie IPsec dans la zone globale, puis exécutez les commandes de configuration IPsec à partir de la zone globale. Utilisez l'adresse source correspondant à la zone non globale à configurer. Vous pouvez également configurer les clés et la stratégie IPsec dans la zone globale pour la zone globale. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale. À partir de la version Solaris 10 7/07, vous pouvez gérer les clés dans une zone non globale à l'aide d'IKE.

• IPsec et RBAC : pour utiliser les rôles afin d'administrer IPsec, reportez-vous au Chapitre 9, Using Role-Based Access Control (Tasks) du System Administration Guide: Security Services. La section Configuration d'un rôle pour la sécurité réseau présente un exemple.

• IPsec et SCTP : vous pouvez utiliser IPsec pour protéger les associations SCTP (Streams Control Transmission Protocol, protocole de transmission de contrôle de flux), mais avec prudence. Pour de plus amples informations, reportez-vous à la section IPsec et SCTP.

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.

1. 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.

   ---

2. 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.

3. 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.

4. 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).

5. 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.

6. 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.

7. 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.

8. 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

9. 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

10. 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.

Utilisation d'IPsec pour protéger un serveur Web du trafic non-web.

Un serveur Web sécurisé permet aux clients Web de communiquer avec le service Web. Sur un serveur Web sécurisé, le trafic non Web doit passer des tests de sécurité. La procédure suivante inclut les contournements pour le trafic Web. En outre, ce serveur Web peut effectuer des requêtes client DNS non sécurisées. Tout autre trafic requiert ESP avec les algorithmes AES et SHA-1.

Avant de commencer

Vous devez configurer la stratégie IPsec dans la zone globale. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale. Vous avez effectué les étapes de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec afin que les conditions suivantes soient remplies :

• La communication entre les deux systèmes est protégée par IPsec.

• Les numéros de clé sont en cours de création, soit manuellement, soit par le biais d'IKE.

• Vous avez vérifié que les paquets sont protégés.

1. 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 –

   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. Exécutez la commande ssh pour assurer une connexion à distance sécurisée.

   ---

2. Déterminez les services qui doivent ignorer les vérifications de stratégie de sécurité.

   Pour un serveur Web, ces services incluent les ports TCP 80 (HTTP) et 443 (HTTP sécurisé). Si le serveur Web assure la recherche de noms DNS, le serveur doit peut-être inclure également le port 53 pour TCP et UDP.

3. Créez une stratégie IPsec pour le serveur Web et activez-la.

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 4 à Étape 7.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 8 à Étape 11.

   L'Étape 12 est facultative dans toutes les versions de Solaris.

4. Ajoutez la stratégie du serveur Web au fichier de stratégie IPsec.

   Ajoutez les lignes suivantes dans le fichier /etc/inet/ipsecinit.conf :

   # Web traffic that web server should bypass. {lport 80 ulp tcp dir both} bypass {} {lport 443 ulp tcp dir both} bypass {} # Outbound DNS lookups should also be bypassed. {rport 53 dir both} bypass {} # Require all other traffic to use ESP with AES and SHA-1. # Use a unique SA for outbound traffic from the port {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   Cette configuration permet uniquement au trafic sécurisé d'accéder au système, avec les exceptions de contournement décrites à l'Étape 4.

5. Vérifiez la syntaxe du fichier de stratégie IPsec.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

6. Actualisez la stratégie IPsec.

   # svcadm refresh svc:/network/ipsec/policy:default

7. Actualisez les clés pour IPsec.

   • Si vous avez configuré le service IKE lors de l'Étape 5 de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec, relancez le service IKE.

     # svcadm restart svc:/network/ipsec/ike

   • Si vous avez configuré manuellement des clés lors de l'Étape 5 de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec, actualisez le service manual-key.

     # svcadm refresh svc:/network/ipsec/manual-key:default

   Votre installation est terminée. Si vous le souhaitez, vous pouvez effectuer l'Étape 12.

8. Créez un fichier dans le répertoire /etc/inet pour la stratégie de serveur Web.

   ---

   Remarque –

   Les étapes ci-dessous permettent de configurer un serveur Web exécutant une version antérieure à la version Solaris 10 4/09.

   ---

   Attribuez au fichier un nom indiquant son objectif, par exemple FichierInitWebIPsec. Tapez les lignes suivantes dans ce fichier :

   # Web traffic that web server should bypass. {lport 80 ulp tcp dir both} bypass {} {lport 443 ulp tcp dir both} bypass {} # Outbound DNS lookups should also be bypassed. {rport 53 dir both} bypass {} # Require all other traffic to use ESP with AES and SHA-1. # Use a unique SA for outbound traffic from the port {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   Cette configuration permet uniquement au trafic sécurisé d'accéder au système, avec les exceptions de contournement décrites à l'Étape 4.

9. Copiez le contenu du fichier créé lors de l'Étape 8 dans le fichier /etc/inet/ipsecinit.conf.

10. Protégez le fichier FichierInitWebIPsec à l'aide de permissions de lecture seule.

    # chmod 400 IPsecWebInitFile

11. Sécurisez le serveur Web sans réinitialiser.

    Procédez de l'une des manières suivantes :

    • Si vous effectuez la gestion des clés à l'aide d'IKE, arrêtez le démon in.iked, puis relancez-le.

      # pkill in.iked # /usr/lib/inet/in.iked

    • Si vous gérez manuellement les clés, exécutez les commandes ipseckey et ipsecconf.

      Utilisez le fichier FichierInitWebIPsec en argument de la commande ipsecconf. Si vous utilisez le fichier ipsecinit.conf en argument, la commande ipsecconf génère des erreurs lorsque les stratégies du fichier sont déjà implémentées sur le système.

      # ipseckey -c -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/IPsecWebInitFile

    ---

    Attention –

    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. Le même avertissement s'applique au redémarrage du démon in.iked.

    ---

    Vous pouvez également réinitialiser. La réinitialisation assure la mise en œuvre de la stratégie IPsec sur toutes les connexions TCP. À la réinitialisation, les connexions TCP utilisent la stratégie du fichier de stratégie IPsec.

12. (Facultatif) Autorisez un système distant à communiquer avec le serveur Web pour le trafic non-Web.

    Tapez la stratégie ci-dessous dans le fichier ipsecinit.conf d'un système distant :

    # Communicate with web server about nonweb stuff # {laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Un système distant peut communiquer de manière sécurisée avec le serveur Web pour le trafic non-Web uniquement lorsque les stratégies IPsec des systèmes sont identiques.

Affichage des stratégies IPsec

Vous pouvez afficher les stratégies configurées dans le système lorsque vous exécutez la commande ipsecconf sans argument.

Avant de commencer

Vous devez exécuter la commande ipsecconf dans la zone globale. Dans une zone IP exclusive, vous devez exécuter la commande ipsecconf dans la zone non globale.

1. Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil Network IPsec Management (gestion IPsec du réseau).

   Si vous exécutez une version antérieure à la version Solaris 10 4/09, le profil Network IPsec Management n'est pas disponible. Utilisez le profil Network Security.

   Pour créer un rôle incluant un profil de sécurité réseau et attribuer ce rôle à un utilisateur, reportez-vous à la section Configuration d'un rôle pour la sécurité réseau.

2. Affichage des stratégies IPsec

   1. Affichez les entrées de stratégie IPsec globales dans l'ordre dans lequel les entrées ont été insérées.

      $ ipsecconf

      La commande affiche chaque entrée avec un index suivi d'un numéro.

   2. Affichez les entrées de stratégie IPsec dans l'ordre dans lequel les correspondances sont repérées.

      $ ipsecconf -l

   3. Affichez les entrées de stratégie IPsec, y compris les entrées définies par tunnel, dans l'ordre dans lequel les correspondances sont repérées.

      $ ipsecconf -L

Génération de numéros aléatoires sur un système Solaris

Si vous spécifiez les clés manuellement, leurs numéros doivent être aléatoires. Dans un système Solaris, les numéros de clé sont au format hexadécimal. D'autres systèmes d'exploitation peuvent nécessiter des numéros de clé au format ASCII. Si vous souhaitez générer des numéros de clé pour un système Solaris qui communique avec un système d'exploitation requérant le format ASCII, reportez-vous à l'Exemple 23–1.

Si votre site possède un générateur de nombres aléatoires, utilisez-le. Dans le cas contraire, vous pouvez utiliser la commande od avec le périphérique Solaris /dev/random en entrée. Pour de plus amples informations, reportez-vous à la page de manuel od(1).

Dans la version Solaris 10 4/09, vous pouvez également utiliser la commande pktool. La syntaxe de cette commande est plus simple que la syntaxe de la commande od. Pour plus de détails, reportez-vous à la section How to Generate a Symmetric Key by Using the pktool Command du System Administration Guide: Security Services.

1. Générez des numéros aléatoires au format hexadécimal.

   % od -x|-X -A n file | head -n

   -x

   Affiche le vidage octal au format hexadécimal. Le format hexadécimal s'avère utile pour les numéros de clé. Le numéro hexadécimal obtenu s'imprime par blocs de 4 caractères.

   -X

   Affiche le vidage octal au format hexadécimal. Le numéro hexadécimal obtenu s'imprime par blocs de 8 caractères.

   -A n

   Supprime la base de décalage d'entrée de l'affichage.

   fichier

   Constitue la source des numéros aléatoires.

   head -n

   Limite l'affichage aux n premières lignes de la sortie de commande.

2. Combinez la sortie afin de créer une clé de longueur adéquate.

   Supprime les espaces entre les numéros sur une ligne afin de créer des clés de 32 caractères. Une clé de 32 caractères correspond à 128 bits. Tout index de paramètre de sécurité (SPI, Security Parameter Index) doit être défini à l'aide d'une clé de 8 caractères. La clé doit utiliser le préfixe 0x.

Exemple 20–3 Génération de numéros de clé pour IPsec

Dans l'exemple suivant, deux lignes de clés s'affichent par groupes de huit caractères hexadécimaux chacun.

% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

En combinant les quatre numéros de la première ligne, vous pouvez créer une clé de 32 caractères. Un numéro de 8 caractères précédé de 0x (0xf3447465, par exemple) définit une valeur de SPI adéquate.

Dans l'exemple suivant, deux lignes de clés s'affichent par groupes de quatre caractères hexadécimaux chacun.

% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

En combinant les huit numéros de la première ligne, vous pouvez créer une clé de 32 caractères.

Création manuelle d'associations de sécurité IPsec

La procédure suivante fournit les numéros de clé de la procédure : Sécurisation du trafic entre deux systèmes à l'aide d'IPsec. Vous générez des clés pour deux systèmes, partym et enigma. Vous générez des clés sur un système, puis utilisez les clés du premier système sur les deux systèmes.

Avant de commencer

La gestion manuelle des numéros de clé pour une zone IP partagée s'effectue dans la zone globale.

1. Générez les numéros de clé pour les SA.

   Il vous faut trois numéros aléatoires hexadécimaux pour le trafic sortant et trois autres numéros aléatoires hexadécimaux pour le trafic entrant.

   Un système doit donc générer les numéros suivants :

   • deux numéros aléatoires hexadécimaux comme valeur du mot-clé spi : un numéro pour le trafic sortant et un numéro pour le trafic entrant. Chaque numéro peut comporter huit caractères maximum.

   • Deux numéros aléatoires hexadécimaux pour l'algorithme SHA1 pour authentification. Pour une clé de 160 bits, chaque numéro doit comporter 40 caractères. L'un d'eux est dédié à dst enigma, l'autre à dst partym.

   • Deux numéros aléatoires hexadécimaux pour l'algorithme AES pour chiffrement. Pour une clé de 256 bits, chaque numéro doit comporter 64 caractères. L'un d'eux est dédié à dst enigma, l'autre à dst partym.

   Si un générateur de nombres aléatoires est disponible sur votre site, utilisez-le. Vous pouvez également exécuter la commande od. La procédure est décrite à la section Génération de numéros aléatoires sur un système Solaris.

2. Connectez-vous à la console système de l'un des systèmes en tant qu'administrateur principal ou en tant que 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 –

   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. Exécutez la commande ssh pour assurer une connexion à distance sécurisée.

   ---

3. Créez les SA.

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 8 à Étape 10.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 4 à Étape 9.

4. Activez le mode de la commande ipseckey.

   # ipseckey >

   L'invite > indique que le mode de la commande ipseckey est activé.

5. Lors du remplacement de SA existantes, videz les SA actuelles.

   > flush >

   Pour éviter qu'un concurrent ait le temps de déceler vos SA, remplacez les numéros de clé.

   ---

   Remarque –

   Vous devez coordonner les remplacements des clés sur les systèmes en communication. Lorsque vous remplacez les SA sur un système, vous devez également les remplacer sur le système distant.

   ---

6. Pour créer des SA, tapez la commande ci-dessous.

   > add protocol spi random-hex-string \ src addr dst addr2 \ protocol-prefix_alg protocol-algorithm \ protocol-prefixkey random-hex-string-of-algorithm-specified-length

   Cette syntaxe permet également de remplacer les SA après les avoir vidées.

   protocole

   Défini sur esp ou ah.

   chaîne-hex-aléatoire

   Spécifie un numéro aléatoire de huit caractères maximum au format hexadécimal. Les caractères sont précédés de 0x. Si les numéros saisis dépassent la limite définie par le SPI, le système ignore les numéros en trop. Si le nombre de numéros n'atteint pas la limite du SPI, le système complète l'entrée.

   adr

   Spécifie l'adresse IP d'un système.

   adr2

   Spécifie l'adresse IP du système homologue de adr.

   préfixe-protocole

   Défini sur encr ou auth. Le préfixe encr est utilisé avec le protocole esp. Le préfixe auth est utilisé avec le protocole ah, ainsi que pour l'authentification du protocole esp.

   algorithme-protocole

   Spécifie un algorithme pour ESP ou AH. Chaque algorithme requiert une clé d'une longueur spécifique.

   MD5 et SHA1 sont des algorithmes d'authentification. SHA256 et SHA512 sont pris en charge depuis version la Solaris 10 4/09. DES, 3DES, AES et Blowfish sont des algorithmes de chiffrement.

   chaîne-hex-aléatoire-longueur-requise-par-algorithme

   Définit un numéro hexadécimal aléatoire de la longueur requise par l'algorithme. Par exemple, l'algorithme MD5 requiert une chaîne de 32 caractères pour sa clé de 128 bits. L'algorithme 3DES requiert une chaîne de 48 caractères pour sa clé de 192 bits.

   1. Protégez les paquets sortants sur le système enigma, par exemple.

      Utilisez les numéros aléatoires générés à l'Étape 1.

      Pour Solaris10 1/06 :

      > add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff >

      ---

      Remarque –

      Le système homologue doit utiliser le même numéro et le même SPI.

      ---

   2. Toujours dans le mode de la commande ipseckey sur le système enigma, protégez les paquets sortants.

      Tapez les commandes suivantes pour protéger les paquets :

      > add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745 >

      ---

      Remarque –

      Les clés et SPI peuvent être différents pour chaque SA. Vous devez attribuer différentes clés et un SPI différent à chaque SA.

      ---

7. Pour quitter le mode de la commande ipseckey, appuyez sur Ctrl-D ou tapez quit.

8. Ajoutez les numéros de clé requis au fichier /etc/inet/secret/ipseckeys.

   Dans les versions antérieures à la version Solaris 10 4/09, cette étape permet de s'assurer que les numéros de clé requis sont disponibles pour IPsec au moment de la réinitialisation.

   Les lignes du fichier /etc/inet/secret/ipseckeys sont identiques à celles de la ligne de commande ipseckey.

   1. Par exemple, le fichier /etc/inet/secret/ipseckeys du système enigma serait similaire à l'exemple ci-dessous :

      # ipseckeys - This file takes the file format documented in # ipseckey(1m). # Note that naming services might not be available when this file # loads, just like ipsecinit.conf. # # for outbound packets on enigma add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff # # for inbound packets add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

   2. Protégez le fichier à l'aide de permissions de lecture seule.

      # chmod 400 /etc/inet/secret/ipseckeys

9. Répétez la procédure sur le système partym.

   Utilisez les mêmes numéros de clé que sur enigma.

   Les numéros de clés utilisés sur chacun des systèmes doivent être identiques. Comme illustré dans l'exemple ci-dessous, les commentaires du fichier ipseckeys constituent la seule différente. Les commentaires sont différents parce que dst enigma correspond à du trafic entrant sur le système enigma et à du trafic sortant sur le système partym.

   # partym ipseckeys file # # for inbound packets add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff # # for outbound packets add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

10. Activez le service manual-key.

    # svcadm enable svc:/network/ipsec/manual-key

    Pour remplacer des clés dans la version actuelle, reportez-vous à l'Exemple 20–4.

Exemple 20–4 Remplacement des SA IPsec

Dans cet exemple, l'administrateur configure un système exécutant la version actuelle Solaris10. L'administrateur crée de nouvelles clés, modifie les informations de clé dans le fichier ipseckeys, puis redémarre le service.

• Tout d'abord, l'administrateur génère les clés en effectuant la procédure de la section Génération de numéros aléatoires sur un système Solaris.

• Ensuite, l'administrateur utilise les clés générées dans le fichier /etc/inet/secret/ipseckeys.

  L'administrateur a utilisé les mêmes algorithmes. Par conséquent, l'administrateur change les valeurs de SPI, encrkey et authkey uniquement :

  add esp spi 0x8xzy1492 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey 0a1f3886b06ebd7d39f6f89e4c29c93f2741c6fa598a38af969907a29ab1b42a \ authkey a7230aabf513f35785da73e33b064608be41f69a # # add esp spi 0x177xce34\ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey 4ef5be40bf93498017b2151d788bb37e372f091add9b11149fba42435fefe328 \ authkey 0e1875d9ff8e42ab652766a5cad49f38c9152821

• Enfin, l'administrateur redémarre le service manual-key. La commande remet à zéro les anciennes clés avant l'ajout de nouvelles clés.

  # svcadm restart manual-key

Vérification de la protection des paquets par IPsec

Pour vérifier que les paquets sont protégés, testez la connexion à l'aide de la commande snoop. Les préfixes suivants peuvent apparaître dans la sortie snoop :

• Le préfixe AH: indique que AH protège les en-têtes. AH: s'affiche si le trafic est protégé à l'aide d'auth_alg.

• Le préfixe ESP: indique le transfert de données chiffrées. ESP: s'affiche si le trafic est protégé à l'aide d'encr_auth_alg ou d'encr_alg.

Avant de commencer

Pour créer la sortie snoop, vous devez être superutilisateur ou prendre un rôle équivalent. Vous devez avoir accès aux deux systèmes afin de tester la connexion.

1. Sur un système, par exemple partym, connectez-vous en tant que superutilisateur.

   % su - Password: Type root password #

2. À partir du système partym, préparez l'analyse des paquets à l'aide de la commande snoop à partir d'un système distant.

   Dans une fenêtre de terminal sur partym, analysez les paquets du système enigma.

   # snoop -v enigma Using device /dev/hme (promiscuous mode)

3. Envoyez un paquet à partir du système distant.

   Dans une autre fenêtre de terminal, connectez-vous à distance au système enigma. Tapez le mot de passe. Ensuite, connectez-vous en tant que superutilisateur et envoyez un paquet du système enigma vers le système partym. Le paquet doit être capturé à l'aide de la commande snoop -v enigma.

   % ssh enigma Password: Type your password % su - Password: Type root password # ping partym

4. Examinez la sortie de la commande snoop.

   Sur le système partym, la sortie devrait contenir les informations AH et ESP après les informations d'en-tête IP initiales. Les informations AH et ESP semblables à l'exemple ci-dessous indiquent que les paquets sont protégés :

   IP: Time to live = 64 seconds/hops IP: Protocol = 51 (AH) IP: Header checksum = 4e0e IP: Source address = 192.168.116.16, enigma IP: Destination address = 192.168.13.213, partym IP: No options IP: AH: ----- Authentication Header ----- AH: AH: Next header = 50 (ESP) AH: AH length = 4 (24 bytes) AH: <Reserved field = 0x0> AH: SPI = 0xb3a8d714 AH: Replay = 52 AH: ICV = c653901433ef5a7d77c76eaa AH: ESP: ----- Encapsulating Security Payload ----- ESP: ESP: SPI = 0xd4f40a61 ESP: Replay = 52 ESP: ....ENCRYPTED DATA.... ETHER: ----- Ether Header ----- ...

Configuration d'un rôle pour la sécurité réseau

Si vous administrez vos systèmes selon le modèle RBAC (Role-Based Access Control, contrôle d'accès à base de rôles), suivez cette procédure pour générer un rôle de gestion ou de sécurité du réseau.

1. Recherchez les profils de droit réseau dans la base de données prof_attr.

   Dans la version actuelle, le résultat est semblable à ce qui suit :

   % cd /etc/security % grep Network prof_attr Network IPsec Management:::Manage IPsec and IKE... Network Link Security:::Manage network link security... Network Management:::Manage the host and network configuration... Network Security:::Manage network and host security... Network Wifi Management:::Manage wifi network configuration... Network Wifi Security:::Manage wifi network security...

   Si vous exécutez une version antérieure à la version Solaris 10 4/09, la sortie est semblable à ce qui suit :

   % cd /etc/security % grep Network prof_attr Network Management:::Manage the host and network configuration   Network Security:::Manage network and host security   System Administrator::: Network Management

   Le profil de gestion du réseau est un profil supplémentaire inclus dans le profil d'administrateur système. Si vous avez attribué le profil de droits d'administrateur système à un rôle, alors ce dernier permet d'exécuter les commandes définies dans le profil de gestion du réseau.

2. Déterminez les commandes incluses dans le profil de droits de gestion du réseau.

   % grep "Network Management" /etc/security/exec_attr Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config … Network Management:suser:cmd:::/usr/sbin/snoop:uid=0

   Les commandes de stratégie solaris s'exécutent avec un privilège ( privs=sys_net_config). Les commandes de stratégie suser s'exécutent en tant que superutilisateur (uid=0).

3. Choisissez l'étendue des rôles de sécurité réseau sur votre site.

   Basez votre choix sur les profils de droits définis lors de l'Étape 1.

   • Pour créer un rôle qui gère l'ensemble de la sécurité du réseau, utilisez le profil de droits Network Security.

   • Dans la version actuelle, pour créer un rôle qui gère IPsec et IKE uniquement, utilisez le profil de droits Network IPsec Management.

4. Créez un rôle de sécurité réseau incluant le profil de droits Network Management.

   Un rôle auquel est appliqué le profil de droits Network Security ou Network IPsec Management, en plus du profil Network Management, peut exécuter les commandes ifconfig, snoop, ipsecconf et ipseckey, entre autres, avec les privilèges appropriés.

   Pour créer un rôle et l'attribuer à un utilisateur, ainsi que pour enregistrer les modifications avec le service de noms, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services .

Exemple 20–5 Répartition des responsabilités de sécurité réseau entre les rôles

Dans cet exemple, l'administrateur répartit les responsabilités de sécurité réseau entre deux rôles. Un rôle peut administrer la sécurité des connexions Wi-Fi et des liens et un autre rôle administrer IPsec et IKE. Chaque rôle est assigné à trois personnes, une personne par période de travail.

Ces rôles sont créés par l'administrateur comme suit :

• L'administrateur nomme le premier rôle LinkWifi.

  • L'administrateur attribue au rôle les profils de droits Network Wifi, Network Link Security et Network Management.

  • Ensuite, l'administrateur attribue le rôle LinkWifi aux utilisateurs appropriés.

• L'administrateur nomme le deuxième rôle Administrateur IPsec.

  • L'administrateur attribue au rôle les profils de droits Network IPsec Management et Network Management.

  • Ensuite, l'administrateur attribue le rôle d'administrateur IPsec aux utilisateurs appropriés.

Procédure de gestion des services IKE et IPsec

Les étapes suivantes présentent les utilisations les plus probables des services SMF pour IPsec, IKE et la gestion manuelle des clés. Par défaut, les services policy et ipsecalgs sont activés. Également par défaut, les services ike et manual-key sont désactivés.

1. Pour gérer la stratégie IPsec, effectuez l'une des opérations suivantes :

   • Après l'ajout de nouvelles stratégies au fichier .conf, actualisez le service policy.

     # svcadm refresh svc:/network/ipsec/policy

   • Après la modification de la valeur d'une propriété du service, affichez la valeur de la propriété, puis actualisez et redémarrez le service policy.

     # svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf # svcprop -p config/config_file policy /etc/inet/MyIpsecinit.conf # svcadm refresh svc:/network/ipsec/policy # svcadm restart svc:/network/ipsec/policy

2. Pour gérer automatiquement les clés, effectuez l'une des opérations suivantes :

   • Après l'ajout d'entrées dans le fichier /etc/inet/ike/config, activez le service ike.

     # svcadm enable svc:/network/ipsec/ike

   • Après modification des entrées dans le fichier /etc/inet/ike/config, actualisez le service ike.

     # svcadm refresh svc:/network/ipsec/ike

   • Après la modification de la valeur d'une propriété du service, affichez la valeur de la propriété, puis actualisez et redémarrez le service.

     # svccfg -s ike setprop config/admin_privilege=modkeys # svcprop -p config/admin_privilege ike modkeys # svcadm refresh svc:/network/ipsec/ike # svcadm restart svc:/network/ipsec/ike

   • Pour arrêter le service ike, désactivez-le.

     # svcadm disable svc:/network/ipsec/ike

3. Pour gérer manuellement les clés, effectuez l'une des opérations suivantes :

   • Après l'ajout d'entrées pour le fichier /etc/inet/secret/ipseckeys, activez le service manual-key.

     # svcadm enable svc:/network/ipsec/manual-key

   • Une fois que vous avez modifié le fichier ipseckeys, actualisez le service.

     # svcadm refresh manual-key

   • Après la modification de la valeur d'une propriété du service, affichez la valeur de la propriété, puis actualisez et redémarrez le service.

     # svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile # svcprop -p config/config_file manual-key /etc/inet/secret/MyIpseckeyfile # svcadm refresh svc:/network/ipsec/manual-key # svcadm restart svc:/network/ipsec/manual-key

   • Pour empêcher la gestion manuelle des clés, désactivez le service manual-key.

     # svcadm disable svc:/network/ipsec/manual-key

4. Si vous modifiez le tableau des protocoles IPsec et des algorithmes, actualisez le service ipsecalgs.

   # svcadm refresh svc:/network/ipsec/ipsecalgs

Erreurs fréquentes

Pour connaître l'état d'un service, utilisez la commande de service svcs. Si le service est en mode maintenance, suivez les suggestions de débogage dans la sortie de la commande de service svcs -x.

Protection d'un VPN à l'aide d'IPsec

Les tunnels IPsec peuvent protéger un VPN. Dans la version Solaris 10 7/07, un tunnel peut être en mode Tunnel ou en mode Transport. Le mode Tunnel est compatible avec l'implémentation d'IPsec par d'autres fournisseurs. Le mode Transport est compatible avec les versions précédentes du SE Solaris. Les modes de tunnel sont expliqués à la section Modes Transport et Tunnel dans IPsec.

Les tunnels en mode Tunnel permettent un contrôle plus détaillé du trafic. En mode Tunnel, vous pouvez spécifier la protection particulière à appliquer pour une adresse IP interne, selon un niveau de détail allant jusqu'au port.

• Des exemples de stratégies IPsec pour les tunnels en mode Tunnel sont fournis à la section Protection d'un VPN à l'aide d'IPsec via des tunnels en mode Tunnel (exemple).

• Les procédures de protection d'un VPN sont décrites à la section Protection d'un VPN à l'aide d'IPsec (liste des tâches) .

Protection d'un VPN à l'aide d'IPsec via des tunnels en mode Tunnel (exemple)

Figure 20–1 Diagramme de tunnel IPsec

Les exemples ci-dessous considèrent que le tunnel est configuré pour tous les sous-réseaux des LAN :

## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10

Exemple 20–6 Création d'un tunnel utilisable par tous les sous-réseaux

Dans cet exemple, l'intégralité du trafic issu des LAN locaux du LAN Central de la Figure 20–1 peut être mis en tunnel du routeur 1 au routeur 2, puis fourni à tous les LAN locaux du LAN Overseas. Le trafic est chiffré à l'aide d'AES.

## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Exemple 20–7 Création d'un tunnel connectant deux sous-réseaux

Dans cet exemple, seul le trafic entre le sous-réseau 10.1.2.0/24 du LAN Central et le sous-réseau 10.2.3.0/24 du LAN Overseas est mis en tunnel et chiffré. En l'absence d'autres stratégies IPsec pour Central, si le LAN Central tente de transmettre des données pour d'autres LAN via ce tunnel, le trafic est abandonné au niveau du routeur 1.

## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}

Exemple 20–8 Création d'un tunnel pour le trafic d'e-mail entre deux sous-réseaux

Dans cet exemple, un tunnel est créé pour les échanges d'e-mail exclusivement. Le trafic est fourni à partir du sous-réseau 10.1.2.0/24 du LAN Central vers le serveur de courrier sur le sous-réseau 10.2.3.0/24 du LAN Overseas. L'e-mail est chiffré à l'aide de Blowfish. Les stratégies s'appliquent aux ports de courrier locaux et distants. La stratégie rport protège l'e-mail envoyé par Central au port de courrier distant d'Overseas. La stratégie lport protège l'e-mail reçu par Central en provenance d'Overseas sur le port local 25.

## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

Exemple 20–9 Création d'un tunnel pour le trafic FTP pour tous les sous-réseaux

Dans cet exemple, la stratégie IPsec protège les ports FTP de la Figure 20–1 à l'aide d'AES pour tous les sous-réseaux du LAN Central vers tous les sous-réseaux du LAN Overseas. Cette configuration fonctionne pour le mode actif de FTP.

## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Protection d'un VPN à l'aide d'IPsec (liste des tâches)

La liste des tâches suivante fait référence aux procédures de configuration d'IPsec dans le cadre de la protection du trafic sur Internet. Ces procédures permettent de configurer un VPN (Virtual Private Network, réseau privé virtuel) sécurisé entre deux systèmes séparés par Internet. Grâce à cette technologie, vous pouvez notamment protéger le trafic de données entre les employés travaillant à domicile et le site de la société.

Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN

Les procédures suivant cette section sont définies pour la configuration ci-dessous. Le réseau est illustré sur la Figure 20–2.

• Chaque système utilise un espace d'adressage IPv4.

  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.

• Chaque système possède deux interfaces. L'interface hme0 se connecte à Internet. Dans cet exemple, les adresses IP Internet commencent par 192.168. L'interface hme1 se connecte au LAN de la société, son intranet. Dans cet exemple, les adresses IP intranet commencent par le numéro 10.

• Chaque système nécessite l'authentification ESP avec l'algorithme SHA–1. L'algorithme SHA–1 requiert une clé de 160 bits.

• Chaque système nécessite le chiffrement ESP avec l'algorithme AES. L'algorithme AES utilise une clé de 128 ou 256 bits.

• Chaque système peut se connecter à un routeur bénéficiant d'un accès direct à Internet.

• Chaque système utilise des associations de sécurité partagées (SA, Security Associations).

Figure 20–2 Exemple de VPN entre plusieurs sites séparés par Internet

Comme l'illustration précédente l'indique, les procédures pour le réseau IPv4 utilisent les paramètres de configuration suivants :

enigma

partym

hme1

hme1

10.16.16.6

10.1.3.3

hme0

hme0

192.168.116.16

192.168.13.213

router-E

router-C

192.168.116.4

192.168.13.5

ip.tun0

ip.tun0

Les adresses IPv6 sont utilisées dans les procédures. Les noms de tunnel sont identiques.

6000:6666::aaaa:1116

6000:3333::eeee:1113

2001::aaaa:6666:6666

2001::eeee:3333:3333

2001::aaaa:0:4

2001::eeee:0:1

Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4

En mode Tunnel, le paquet IP interne détermine la stratégie IPsec qui protège son contenu.

Cette procédure prolonge la procédure Sécurisation du trafic entre deux systèmes à l'aide d'IPsec. La configuration est décrite à la section Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN.

Effectuez cette procédure sur les deux systèmes.

Outre la connexion de deux systèmes, vous connectez deux intranets qui leur sont connectés. Les systèmes de cette procédure fonctionnent comme des passerelles.

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.

1. 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 –

   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.

   ---

2. Contrôlez le flux de paquets avant de configurer IPsec.

   1. Assurez-vous que le transfert IP et le routage dynamique IP sont désactivés.

      # routeadm Configuration Current Current Option Configuration System State -------------------------------------------------- IPv4 forwarding disabled disabled IPv4 routing default (enabled) enabled …

      Si le transfert IP et le routage dynamique IP sont activés, vous pouvez les désactiver en tapant :

      # routeadm -d ipv4-routing -d ipv4-forwarding # routeadm -u

      La désactivation du transfert IP évite le transfert des paquets d'un réseau à un autre via ce système. La commande routeadm est décrite à la page de manuel routeadm(1M).

   2. Activez le multiréseau de destination strict IP.

      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      L'activation du multiréseau de destination strict IP assure que les paquets de l'une des adresses de destination du système arrivent à l'adresse de destination adéquate.

      Lorsque le multiréseau de destination strict est activé, les paquets arrivant sur une interface particulière doivent être adressés à l'une des adresses IP locales de cette interface. Tous les autres paquets sont abandonnés, même les paquets envoyés vers d'autres adresses locales du système.

      ---

      Attention –

      Par défaut, lors de l'initialisation du système, la valeur multiréseau est désélectionnée. Pour rendre persistante la valeur modifiée, reportez-vous à la section Protection contre l'usurpation d'adresse IP.

      ---

   3. Désactivez la plupart des services réseau, voire tous les services réseau.

      ---

      Remarque –

      Si le système a été installé avec le profil SMF "limité", vous pouvez ignorer cette étape. Tous les services réseau sont désactivés, à l'exception de Solaris Secure Shell.

      ---

      La désactivation des services réseau évite que le système soit affecté par les paquets IP. Par exemple, vous pouvez utiliser un démon SNMP, une connexion telnet ou une connexion rlogin.

      Procédez de l'une des manières suivantes :

      • Si vous exécutez Solaris10 11/06 ou une version supérieure, exécutez le profil SMF "limité".

        # netservices limited

      • Dans le cas contraire, désactivez les services réseau un à un.

        # svcadm disable network/ftp:default # svcadm disable network/finger:default # svcadm disable network/login:rlogin # svcadm disable network/nfs/server:default # svcadm disable network/rpc/rstat:default # svcadm disable network/smtp:sendmail # svcadm disable network/telnet:default

   4. Assurez-vous que la plupart des services réseau sont désactivés.

      Assurez-vous que les montages en loopback et le service ssh sont en cours d'exécution.

      # svcs | grep network online Aug_02 svc:/network/loopback:default … online Aug_09 svc:/network/ssh:default

3. Ajoutez une paire de SA entre les deux systèmes.

   Procédez de l'une des manières suivantes :

   • Configurez IKE de manière à gérer les clés pour les SA. Suivez l'une des procédures de la section Configuration du protocole IKE (liste des tâches) afin de configurer IKE pour le VPN.

   • Si, pour une raison particulière, vous souhaitez gérer les clés manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

4. Ajoutez une stratégie IPsec.

   Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN. Pour renforcer la stratégie, reportez-vous à l'Exemple 20–12. Vous trouverez d'autres exemples à la section Protection d'un VPN à l'aide d'IPsec via des tunnels en mode Tunnel (exemple).

   Dans cette stratégie, la protection IPsec n'est pas requise entre les systèmes du réseau local et l'adresse IP interne de la passerelle, d'où l'ajout d'une déclaration bypass.

   1. Sur le système enigma, saisissez l'entrée suivante dans le fichier ipsecinit.conf :

      # LAN traffic to and from this host can bypass IPsec. {laddr 10.16.16.6 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   2. Sur le système partym, tapez l'entrée suivante dans le fichier ipsecinit.conf :

      # LAN traffic to and from this host can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

5. (Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

6. Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 7 à Étape 13, puis exécutez le protocole de routage tel qu'indiqué à l'Étape 22.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 14 à Étape 22.

7. Configurez le tunnel ip.tun0 dans le fichier /etc/hostname.ip.tun0.

   La syntaxe du fichier est la suivante :

   system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

   1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

   2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

8. Protégez le tunnel à l'aide de la stratégie IPsec créée.

   # svcadm refresh svc:/network/ipsec/policy:default

9. Pour lire les informations du fichier de configuration du tunnel, redémarrez les services réseau.

   # svcadm restart svc:/network/initial:default

10. Activez le transfert IP pour l'interface hme1.

    1. Sur le système enigma, ajoutez l'entrée de routeur au fichier /etc/hostname.hme1.

       192.168.116.16 router

    2. Sur le système partym, ajoutez l'entrée de routeur au fichier /etc/hostname.hme1.

       192.168.13.213 router

    Le transfert IP signifie que les paquets arrivant peuvent être transférés. Le transfert IP signifie également que les paquets quittant l'interface peuvent provenir d'un autre emplacement. Pour que le transfert de paquet s'effectue sans erreur, vous devez activer le transfert IP à la fois sur l'interface réceptrice et sur l'interface émettrice.

    Étant donné que l'interface hme1 se trouve dans l'intranet, le transfert IP doit être activé pour hme1. Comme ip.tun0 connecte les deux systèmes via Internet, le transfert IP doit être activé pour ip.tun0.

    Le transfert IP de l'interface hme0 est désactivé afin d'éviter toute injection de paquets par un concurrent externe dans l'intranet protégé. Le terme externe fait référence à Internet.

11. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    1. Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname.hme0.

       10.16.16.6 private

    2. Sur le système partym, ajoutez l'indicateur private au fichier /etc/hostname.hme0.

       10.1.3.3 private

    Même si le transfert de l'IP de hme0 est désactivé, l'implémentation d'un protocole de routage peut permettre d'annoncer l'interface. Par exemple, le protocole in.routed peut encore annoncer que hme0 est disponible pour transférer des paquets à ses homologues dans l'intranet. Pour éviter ces annonces, définissez l'indicateur private de l'interface.

12. Ajoutez manuellement une route par défaut sur l'interface hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :

       # route add default 192.168.13.5

       Même si l'interface hme0 ne fait pas partie de l'intranet, hme0 n'a pas besoin de passer par Internet pour atteindre le système homologue. Pour trouver son homologue, hme0 requiert des informations sur le routage Internet. Pour le reste d'Internet, le système VPN apparaît comme étant un hôte, non un routeur. Par conséquent, vous pouvez utiliser un routeur par défaut ou exécuter le protocole de recherche de routeur pour rechercher le système. Pour de plus amples informations, reportez-vous aux pages de manuel route(1M) et in.routed(1M).

13. Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.

14. Configurez le tunnel ip.tun0.

    ---

    Remarque –

    Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.

    ---

    Utilisez les commandes ifconfig pour créer l'interface point à point :

    # ifconfig ip.tun0 plumb # ifconfig ip.tun0 system1-point system2-point \ tsrc system1-taddr tdst system2-taddr

    1. Sur le système enigma, saisissez les commandes ci-dessous :

       # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213

    2. Sur le système partym, tapez les commandes ci-dessous :

       # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16

15. Protégez le tunnel à l'aide de la stratégie IPsec créée.

    # ipsecconf

16. Affichez le routeur pour le tunnel.

    # ifconfig ip.tun0 router up

17. Activez le transfert IP pour l'interface hme1.

    # ifconfig hme1 router

    Le transfert IP signifie que les paquets arrivant peuvent être transférés. Le transfert IP signifie également que les paquets quittant l'interface peuvent provenir d'un autre emplacement. Pour que le transfert de paquet s'effectue sans erreur, vous devez activer le transfert IP à la fois sur l'interface réceptrice et sur l'interface émettrice.

    Comme l'interface hme1 se trouve dans l'intranet, le transfert IP doit être activé pour hme1. Comme ip.tun0 connecte les deux systèmes via Internet, le transfert IP doit être activé pour ip.tun0.

    Le transfert IP de l'interface hme0 est désactivé afin d'éviter toute injection de paquets par un concurrent externe dans l'intranet protégé. Le terme externe fait référence à Internet.

18. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    # ifconfig hme0 private

    Même si le transfert IP de hme0 est désactivé, l'implémentation d'un protocole de routage est susceptible d'annoncer l'interface. Par exemple, le protocole in.routed peut encore annoncer que hme0 est disponible pour transférer des paquets à ses homologues dans l'intranet. Pour éviter ces annonces, définissez l'indicateur private de l'interface.

19. Ajoutez manuellement une route par défaut à travers hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :

       # route add default 192.168.13.5

       Même si l'interface hme0 ne fait pas partie de l'intranet, hme0 n'a pas besoin de passer par Internet pour atteindre le système homologue. Pour trouver son homologue, hme0 requiert des informations sur le routage Internet. Pour le reste d'Internet, le système VPN apparaît comme étant un hôte, non un routeur. Par conséquent, vous pouvez utiliser un routeur par défaut ou exécuter le protocole de recherche de routeur pour rechercher le système. Pour de plus amples informations, reportez-vous aux pages de manuel route(1M) et in.routed(1M).

20. Assurez-vous que le VPN démarre à la réinitialisation en ajoutant une entrée au fichier /etc/hostname.ip.tun0.

    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

       10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

       10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

21. Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.

    1. Sur le système enigma, modifiez les fichiers /etc/hostname. interface.

       # cat /etc/hostname.hme0 ## enigma 10.16.16.6 private

       # cat /etc/hostname.hme1 ## enigma 192.168.116.16 router

    2. Sur le système partym, modifiez les fichiers /etc/hostname. interface.

       # cat /etc/hostname.hme0 ## partym 10.1.3.3 private

       # cat /etc/hostname.hme1 ## partym 192.168.13.213 router

22. Exécutez un protocole de routage.

    # routeadm -e ipv4-routing # routeadm -u

    Vous devrez peut-être configurer le protocole de routage avant de l'exécuter. Pour plus d'informations, reportez-vous à la section Protocoles de routage dans Oracle Solaris. La procédure est décrite à la section Configuration d'un routeur IPv4.

Exemple 20–10 Création temporaire des tunnels lors du test

Dans cet exemple, l'administrateur teste la création d'un tunnel sur un système Solaris 10 4/09. Par la suite, l'administrateur utilise la procédure Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 pour rendre les tunnels permanents. Lors du test, l'administrateur effectue les séries d'actions suivantes sur les systèmes system1 et system2 :

• Sur les deux systèmes, l'administrateur exécute les cinq premières étapes de la procédure décrite à la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

• L'administrateur utilise la commande ifconfig pour monter et configurer un tunnel temporaire.

  system1 # ifconfig ip.tun0 plumb system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 # ssh system2 Password: admin-password-on-system2 system2 # ifconfig ip.tun0 plumb system2 # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16

• L'administrateur active la stratégie IPsec sur le tunnel. La stratégie a été créée à l'Étape 4 de la procédure Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

  system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default

• L'administrateur convertit l'interface Internet en routeur et empêche les protocoles de routage d'accéder à l'interface intranet.

  system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private

• L'administrateur ajoute manuellement le routage et exécute sur les deux systèmes le protocole de routage en effectuant l'Étape 12 et l'Étape 22 de la procédure décrite à la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

Exemple 20–11 Création d'un tunnel sur un système Solaris de version antérieure en utilisant la ligne de commande

Dans la version Solaris 10 7/07, la syntaxe de la commande ifconfig a été simplifiée. Dans cet exemple, l'administrateur teste la création d'un tunnel sur un système exécutant une version de Solaris antérieure à la version Solaris 10 7/07. À l'aide de la syntaxe d'origine de la commande ifconfig, l'administrateur peut utiliser les mêmes commandes sur les deux systèmes communicants. Ensuite, l'administrateur doit effectuer la procédure de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 pour rendre les tunnels permanents.

Lors du test, l'administrateur doit effectuer les étapes suivantes sur les systèmes system1 et system2 :

• Sur les deux systèmes, l'administrateur doit exécuter les cinq premières étapes de la procédure décrite à la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

• L'administrateur monte et configure le tunnel.

  system1 # ifconfig ip.tun0 plumb system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 \ encr_algs aes encr_auth_algs sha1 system1 # ifconfig ip.tun0 router up

  # ssh system2 Password: admin-password-on-system2 system2 # ifconfig ip.tun0 plumb system2 # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16 \ encr_algs aes encr_auth_algs sha1 system2 # ifconfig ip.tun0 router up

• L'administrateur active la stratégie IPsec sur le tunnel. La stratégie a été créée à l'Étape 4 de la procédure Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

  system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default

• L'administrateur convertit l'interface Internet en routeur et empêche les protocoles de routage d'accéder à l'interface intranet.

  system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private

• L'administrateur ajoute le routage sur les deux systèmes en exécutant l'Étape 12 et l'Étape 22 de la procédure de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

Exemple 20–12 Requête de stratégie IPsec sur tous les systèmes sur un LAN

Dans cet exemple, l'administrateur met en commentaire la stratégie bypass configurée à l'Étape 4, ce qui renforce la protection. Avec cette configuration de stratégie, chaque système du LAN doit activer IPsec afin de communiquer avec le routeur.

# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}

Exemple 20–13 Utilisation d'IPsec pour protéger le trafic Telnet différemment du trafic SMTP

Dans cet exemple, la première règle protège le trafic telnet sur le port 23 avec Blowfish et SHA-1. La deuxième règle protège le trafic SMTP sur le port 25 avec AES et MD5.

{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}

Exemple 20–14 Utilisation d'un tunnel IPsec en mode Tunnel pour protéger un sous-réseau différemment d'un autre trafic réseau

La configuration de tunnel ci-dessous protège l'intégralité du trafic du sous-réseau 10.1.3.0/24 via le tunnel :

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Les configurations de tunnel ci-dessous protègent le trafic du sous-réseau 10.1.3.0/24 vers d'autres sous-réseaux via le tunnel. Les sous-réseaux dont le numéro commence par 10.2.x.x traversent le tunnel.

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv6

Les étapes de configuration d'un VPN sur un réseau IPv6 sont identiques à celles de la configuration d'un VPN sur un réseau IPv4. Toutefois, la syntaxe des commandes est légèrement différente. Les raisons pour lesquelles des commandes spécifiques sont requises sont expliquées en détail aux étapes correspondantes de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

Effectuez cette procédure sur les deux systèmes.

Cette procédure utilise les paramètres de configuration ci-dessous.

enigma

partym

hme1

hme1

hme0

hme0

6000:6666::aaaa:1116

6000:3333::eeee:1113

2001::aaaa:6666:6666

2001::eeee:3333:3333

router-E

router-C

2001::aaaa:0:4

2001::eeee:0:1

ip6.tun0

ip6.tun0

1. 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 –

   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.

   ---

2. Contrôlez le flux de paquets avant de configurer IPsec.

   Les effets de ces commandes sont décrits à l'Étape 2 de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

   1. Assurez-vous que le transfert IP et le routage dynamique IP sont désactivés.

      # routeadm Configuration Current Current Option Configuration System State -------------------------------------------------- … IPv6 forwarding disabled disabled IPv6 routing disabled disabled

      Si le transfert IP et le routage dynamique IP sont activés, vous pouvez les désactiver en tapant :

      # routeadm -d ipv6-forwarding -d ipv6-routing # routeadm -u

   2. Activez le multiréseau de destination strict IP.

      # ndd -set /dev/ip ip6_strict_dst_multihoming 1

      ---

      Attention –

      La valeur par défaut de ip6_strict_dst_multihoming est rétablie lors de l'initialisation du système. Pour rendre persistante la valeur modifiée, reportez-vous à la section Protection contre l'usurpation d'adresse IP.

      ---

   3. Désactivez la plupart des services réseau, voire tous les services réseau.

      ---

      Remarque –

      Si le système a été installé avec le profil SMF "limité", vous pouvez ignorer cette étape. Tous les services réseau sont désactivés, à l'exception de Solaris Secure Shell.

      ---

      La désactivation des services réseau évite que le système soit affecté par les paquets IP. Par exemple, vous pouvez utiliser un démon SNMP, une connexion telnet ou une connexion rlogin.

      Procédez de l'une des manières suivantes :

      • Si vous exécutez Solaris10 11/06 ou une version supérieure, exécutez le profil SMF "limité".

        # netservices limited

      • Dans le cas contraire, désactivez les services réseau un à un.

        # svcadm disable network/ftp:default # svcadm disable network/finger:default # svcadm disable network/login:rlogin # svcadm disable network/nfs/server:default # svcadm disable network/rpc/rstat:default # svcadm disable network/smtp:sendmail # svcadm disable network/telnet:default

   4. Assurez-vous que la plupart des services réseau sont désactivés.

      Assurez-vous que les montages en loopback et le service ssh sont en cours d'exécution.

      # svcs | grep network online Aug_02 svc:/network/loopback:default ... online Aug_09 svc:/network/ssh:default

3. Ajoutez une paire de SA entre les deux systèmes.

   Procédez de l'une des manières suivantes :

   • Configurez IKE de manière à gérer les clés pour les SA. Suivez l'une des procédures de la section Configuration du protocole IKE (liste des tâches) afin de configurer IKE pour le VPN.

   • Si, pour une raison particulière, vous souhaitez gérer les clés manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

4. Ajoutez la stratégie IPsec pour le réseau VPN.

   Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN.

   1. Sur le système enigma, saisissez l'entrée suivante dans le fichier ipsecinit.conf :

      # IPv6 Neighbor Discovery messages bypass IPsec. {ulp ipv6-icmp type 133-137 dir both} pass {} # LAN traffic to and from this host can bypass IPsec. {laddr 6000:6666::aaaa:1116 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip6.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   2. Sur le système partym, tapez l'entrée suivante dans le fichier ipsecinit.conf :

      # IPv6 Neighbor Discovery messages bypass IPsec. {ulp ipv6-icmp type 133-137 dir both} pass {} # LAN traffic to and from this host can bypass IPsec. {laddr 6000:3333::eeee:1113 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip6.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

5. (Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

6. Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 7 à Étape 13, puis exécutez le protocole de routage tel qu'indiqué à l'Étape 22.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 14 à Étape 22.

7. Configurez le tunnel ip6.tun0 dans le fichier /etc/hostname.ip6.tun0.

   1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip6.tun0 :

      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

   2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip6.tun0 :

      6000:3333::eeee:1113 6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

8. Protégez le tunnel à l'aide de la stratégie IPsec créée.

   # svcadm refresh svc:/network/ipsec/policy:default

9. Pour lire les informations du fichier de configuration du tunnel dans le noyau, redémarrez les services réseau.

   # svcadm restart svc:/network/initial:default

10. Activez le transfert IP pour l'interface hme1.

    1. Sur le système enigma, ajoutez l'entrée de routeur au fichier /etc/hostname6.hme1.

       2001::aaaa:6666:6666 inet6 router

    2. Sur le système partym, ajoutez l'entrée de routeur au fichier /etc/hostname6.hme1.

       2001::eeee:3333:3333 inet6 router

11. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    1. Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname6.hme0.

       6000:6666::aaaa:1116 inet6 private

    2. Sur le système partym, ajoutez l'indicateur private au fichier /etc/hostname6.hme0.

       6000:3333::eeee:1113 inet6 private

12. Ajoutez manuellement une route par défaut à travers hme0.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add -inet6 default 2001::aaaa:0:4

    2. Sur le système partym, ajoutez la route suivante :

       # route add -inet6 default 2001::eeee:0:1

13. Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.

14. Configurez un tunnel sécurisé ip6.tun0.

    ---

    Remarque –

    Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.

    ---

    1. Sur le système enigma, saisissez les commandes ci-dessous :

       # ifconfig ip6.tun0 inet6 plumb # ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333

    2. Sur le système partym, tapez les commandes ci-dessous :

       # ifconfig ip6.tun0 inet6 plumb # ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666

15. Protégez le tunnel à l'aide de la stratégie IPsec créée.

    # ipsecconf

16. Affichez le routeur pour le tunnel.

    # ifconfig ip6.tun0 router up

17. Sur chaque système, exécutez le transfert IP pour l'interface hme1.

    # ifconfig hme1 router

18. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    # ifconfig hme0 private

19. Ajoutez manuellement une route par défaut à travers hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add -inet6 default 2001::aaaa:0:4

    2. Sur le système partym, ajoutez la route suivante :

       # route add -inet6 default 2001::eeee:0:1

20. Assurez-vous que le VPN démarre à la réinitialisation en ajoutant une entrée au fichier /etc/hostname6.ip6.tun0.

    L'entrée réplique les paramètres spécifiés dans la commande ifconfig lors de l'Étape 14.

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname6.ip6.tun0 :

       6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname6.ip6.tun0 :

       6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

21. Sur chaque système, configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.

    1. Sur le système enigma, modifiez les fichiers /etc/hostname6. interface.

       # cat /etc/hostname6.hme0 ## enigma 6000:6666::aaaa:1116 inet6 private

       # cat /etc/hostname6.hme1 ## enigma 2001::aaaa:6666:6666 inet6 router

    2. Sur le système partym, modifiez les fichiers /etc/hostname6. interface.

       # cat /etc/hostname6.hme0 ## partym 6000:3333::eeee:1113 inet6 private

       # cat /etc/hostname6.hme1 ## partym 2001::eeee:3333:3333 inet6 router

22. Exécutez un protocole de routage.

    # routeadm -e ipv6-routing # routeadm -u

    Vous devrez peut-être configurer le protocole de routage avant de l'exécuter. Pour plus d'informations, reportez-vous à la section Protocoles de routage dans Oracle Solaris. Pour connaître la procédure, reportez-vous à la section Configuration d'un routeur IPv6.

Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv4

En mode Transport, l'en-tête extérieur détermine la stratégie IPsec qui protège le paquet IP interne.

Cette procédure prolonge la procédure Sécurisation du trafic entre deux systèmes à l'aide d'IPsec. Outre la connexion de deux systèmes, vous connectez deux intranets qui leur sont connectés. Les systèmes de cette procédure fonctionnent comme des passerelles.

La configuration utilisée pour cette procédure est décrite à la section Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN. Les raisons pour lesquelles des commandes spécifiques sont requises sont expliquées en détail aux étapes correspondantes de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

Effectuez cette procédure sur les deux systèmes.

1. 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 –

   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.

   ---

2. Contrôlez le flux de paquets avant de configurer IPsec.

   1. Assurez-vous que le transfert IP et le routage dynamique IP sont désactivés.

      # routeadm Configuration Current Current Option Configuration System State -------------------------------------------------- IPv4 forwarding disabled disabled IPv4 routing default (enabled) enabled …

      Si le transfert IP et le routage dynamique IP sont activés, vous pouvez les désactiver en tapant :

      # routeadm -d ipv4-routing -d ipv4-forwarding # routeadm -u

   2. Activez le multiréseau de destination strict IP.

      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      ---

      Attention –

      La valeur par défaut de ip_strict_dst_multihoming est rétablie lors de l'initialisation du système. Pour rendre persistante la valeur modifiée, reportez-vous à la section Protection contre l'usurpation d'adresse IP.

      ---

   3. Désactivez la plupart des services réseau, voire tous les services réseau.

      ---

      Remarque –

      Si le système a été installé avec le profil SMF "limité", vous pouvez ignorer cette étape. Tous les services réseau sont désactivés, à l'exception de Solaris Secure Shell.

      ---

      La désactivation des services réseau évite que le système soit affecté par les paquets IP. Par exemple, vous pouvez utiliser un démon SNMP, une connexion telnet ou une connexion rlogin.

      Procédez de l'une des manières suivantes :

      • Si vous exécutez Solaris10 11/06 ou une version supérieure, exécutez le profil SMF "limité".

        # netservices limited

      • Dans le cas contraire, désactivez les services réseau un à un.

        # svcadm disable network/ftp:default # svcadm disable network/finger:default # svcadm disable network/login:rlogin # svcadm disable network/nfs/server:default # svcadm disable network/rpc/rstat:default # svcadm disable network/smtp:sendmail # svcadm disable network/telnet:default

   4. Assurez-vous que la plupart des services réseau sont désactivés.

      Assurez-vous que les montages en loopback et le service ssh sont en cours d'exécution.

      # svcs | grep network online Aug_02 svc:/network/loopback:default … online Aug_09 svc:/network/ssh:default

3. Ajoutez une paire de SA entre les deux systèmes.

   Procédez de l'une des manières suivantes :

   • Configurez IKE de manière à gérer les clés pour les SA. Suivez l'une des procédures de la section Configuration du protocole IKE (liste des tâches) afin de configurer IKE pour le VPN.

   • Si, pour une raison particulière, vous souhaitez gérer les clés manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

4. Ajoutez une stratégie IPsec.

   Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN. Pour renforcer la stratégie, reportez-vous à l'Exemple 20–15.

   1. Sur le système enigma, saisissez l'entrée suivante dans le fichier ipsecinit.conf :

      # LAN traffic to and from this host can bypass IPsec. {laddr 10.16.16.6 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   2. Sur le système partym, tapez l'entrée suivante dans le fichier ipsecinit.conf :

      # LAN traffic to and from this host can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

5. (Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

6. Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 7 à Étape 13, puis exécutez le protocole de routage tel qu'indiqué à l'Étape 22.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 14 à Étape 22.

7. Configurez le tunnel ip.tun0 dans le fichier /etc/hostname.ip.tun0.

   1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

   2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

8. Protégez le tunnel à l'aide de la stratégie IPsec créée.

   # svcadm refresh svc:/network/ipsec/policy:default

9. Pour lire les informations du fichier hostname.ip.tun0 dans le noyau, redémarrez les services réseau.

   # svcadm restart svc:/network/initial:default

10. Activez le transfert IP pour l'interface hme1.

    1. Sur le système enigma, ajoutez l'entrée du routeur au fichier /etc/hostname.hme1.

       192.168.116.16 router

    2. Sur le système partym, ajoutez l'entrée du routeur au fichier /etc/hostname.hme1.

       192.168.13.213 router

11. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    1. Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname.hme0.

       10.16.16.6 private

    2. Sur le système partym, ajoutez l'indicateur private au fichier /etc/hostname.hme0.

       10.1.3.3 private

12. Ajoutez manuellement une route par défaut sur hme0.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :

       # route add default 192.168.13.5

13. Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.

14. Configurez le tunnel ip.tun0.

    ---

    Remarque –

    Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.

    ---

    Utilisez les commandes ifconfig pour créer l'interface point à point :

    # ifconfig ip.tun0 plumb # ifconfig ip.tun0 system1-point system2-point \ tsrc system1-taddr tdst system2-taddr

    1. Sur le système enigma, saisissez les commandes ci-dessous :

       # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213

    2. Sur le système partym, tapez les commandes ci-dessous :

       # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16

15. Protégez le tunnel à l'aide de la stratégie IPsec créée.

    # ipsecconf

16. Affichez le routeur pour le tunnel.

    # ifconfig ip.tun0 router up

17. Activez le transfert IP pour l'interface hme1.

    # ifconfig hme1 router

18. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    # ifconfig hme0 private

19. Ajoutez manuellement une route par défaut à travers hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    # route add default router-on-hme0-subnet

    1. Sur le système enigma, ajoutez la route suivante :

       # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :

       # route add default 192.168.13.5

20. Assurez-vous que le VPN démarre à la réinitialisation en ajoutant une entrée au fichier /etc/hostname.ip.tun0.

    system1-point system2-point tsrc system1-taddr \ tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

       10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \ tdst 192.168.13.213 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :

       10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \ tdst 192.168.116.16 router up

21. Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.

    1. Sur le système enigma, modifiez les fichiers /etc/hostname. interface.

       # cat /etc/hostname.hme0 ## enigma 10.16.16.6 private

       # cat /etc/hostname.hme1 ## enigma 192.168.116.16 router

    2. Sur le système partym, modifiez les fichiers /etc/hostname. interface.

       # cat /etc/hostname.hme0 ## partym 10.1.3.3 private

       # cat /etc/hostname.hme1 ## partym 192.168.13.213 router

22. Exécutez un protocole de routage.

    # routeadm -e ipv4-routing # routeadm -u

Exemple 20–15 Requête de stratégie IPsec sur tous les systèmes en mode Transport

Dans cet exemple, l'administrateur met en commentaire la stratégie bypass configurée à l'Étape 4, ce qui renforce la protection. Avec cette configuration de stratégie, chaque système du LAN doit activer IPsec afin de communiquer avec le routeur.

# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}

Exemple 20–16 Configuration d'un tunnel IPsec en mode Transport à l'aide d'une syntaxe désapprouvée

Dans cet exemple, l'administrateur connecte un système Solaris 10 7/07 à un système exécutant la version Solaris10. Par conséquent, l'administrateur utilise la syntaxe Solaris10 dans le fichier de configuration et inclut les algorithmes IPsec à la commande ifconfig.

L'administrateur suit la procédure décrite à la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv4, à l'exception des modifications syntaxiques ci-dessous.

• Pour l'Étape 4, la syntaxe du fichier ipsecinit.conf est la suivante :

  # LAN traffic to and from this address can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {} ipsec {encr_algs aes encr_auth_algs sha1}

• Pour les étapes Étape 14 à Étape 16, la syntaxe permettant de configurer un tunnel sécurisé est la suivante :

  # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 \ encr_algs aes encr_auth_algs sha1 # ifconfig ip.tun0 router up

  # ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 \ encr_algs aes encr_auth_algs sha1

  La stratégie IPsec utilisée dans les commandes ifconfig doit correspondre à celle qui est spécifiée dans le fichier ipsecinit.conf. À la réinitialisation, chaque système lit le fichier ipsecinit.conf pour connaître sa stratégie.

• Pour l'Étape 20, la syntaxe du fichier hostname.ip.tun0 est la suivante :

  10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \ tdst 192.168.13.213 encr_algs aes encr_auth_algs sha1 router up

Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv6

Les étapes de configuration d'un VPN sur un réseau IPv6 sont identiques à celles de la configuration d'un VPN sur un réseau IPv4. Toutefois, la syntaxe des commandes est légèrement différente. Les raisons pour lesquelles des commandes spécifiques sont requises sont expliquées en détail aux étapes correspondantes de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4.

Effectuez cette procédure sur les deux systèmes.

Cette procédure utilise les paramètres de configuration ci-dessous.

enigma

partym

hme1

hme1

hme0

hme0

6000:6666::aaaa:1116

6000:3333::eeee:1113

2001::aaaa:6666:6666

2001::eeee:3333:3333

router-E

router-C

2001::aaaa:0:4

2001::eeee:0:1

ip6.tun0

ip6.tun0

1. 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 –

   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.

   ---

2. Contrôlez le flux de paquets avant de configurer IPsec.

   1. Assurez-vous que le transfert IP et le routage dynamique IP sont désactivés.

      # routeadm Configuration Current Current Option Configuration System State -------------------------------------------------- … IPv6 forwarding disabled disabled IPv6 routing disabled disabled

      Si le transfert IP et le routage dynamique IP sont activés, vous pouvez les désactiver en tapant :

      # routeadm -d ipv6-forwarding -d ipv6-routing # routeadm -u

   2. Activez le multiréseau de destination strict IP.

      # ndd -set /dev/ip ip6_strict_dst_multihoming 1

      ---

      Attention –

      La valeur par défaut de ip6_strict_dst_multihoming est rétablie lors de l'initialisation du système. Pour rendre persistante la valeur modifiée, reportez-vous à la section Protection contre l'usurpation d'adresse IP.

      ---

   3. Assurez-vous que la plupart des services réseau sont désactivés.

      Assurez-vous que les montages en loopback et le service ssh sont en cours d'exécution.

      # svcs | grep network online Aug_02 svc:/network/loopback:default … online Aug_09 svc:/network/ssh:default

3. Ajoutez une paire de SA entre les deux systèmes.

   Procédez de l'une des manières suivantes :

   • Configurez IKE de manière à gérer les clés pour les SA. Suivez l'une des procédures de la section Configuration du protocole IKE (liste des tâches) afin de configurer IKE pour le VPN.

   • Si, pour une raison particulière, vous souhaitez gérer les clés manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

4. Ajoutez une stratégie IPsec.

   Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN.

   1. Sur le système enigma, saisissez l'entrée suivante dans le fichier ipsecinit.conf :

      # IPv6 Neighbor Discovery messages bypass IPsec. {ulp ipv6-icmp type 133-137 dir both} pass {} # LAN traffic can bypass IPsec. {laddr 6000:6666::aaaa:1116 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip6.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}

   2. Sur le système partym, tapez l'entrée suivante dans le fichier ipsecinit.conf :

      # IPv6 Neighbor Discovery messages bypass IPsec. {ulp ipv6-icmp type 133-137 dir both} pass {} # LAN traffic can bypass IPsec. {laddr 6000:3333::eeee:1113 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip6.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}

5. (Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

6. Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :

   • À partir de la version Solaris 10 4/09, suivez les étapes Étape 7 à Étape 13, puis exécutez le protocole de routage tel qu'indiqué à l'Étape 22.

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 14 à Étape 22.

7. Configurez le tunnel ip6.tun0 dans le fichier /etc/hostname.ip6.tun0.

   1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip6.tun0 :

      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

   2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip6.tun0 :

      6000:3333::eeee:1113 6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

8. Protégez le tunnel à l'aide de la stratégie IPsec créée.

   # svcadm refresh svc:/network/ipsec/policy:default

9. Pour lire le contenu du fichier hostname.ip6.tun0 dans le noyau, redémarrez les services réseau.

   # svcadm restart svc:/network/initial:default

10. Activez le transfert IP pour l'interface hme1.

    1. Sur le système enigma, ajoutez l'entrée de routeur au fichier /etc/hostname6.hme1.

       2001::aaaa:6666:6666 inet6 router

    2. Sur le système partym, ajoutez l'entrée de routeur au fichier /etc/hostname6.hme1.

       2001::eeee:3333:3333 inet6 router

11. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    1. Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname6.hme0.

       6000:6666::aaaa:1116 inet6 private

    2. Sur le système partym, ajoutez l'indicateur private au fichier /etc/hostname6.hme0.

       6000:3333::eeee:1113 inet6 private

12. Ajoutez manuellement une route par défaut à travers hme0.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add -inet6 default 2001::aaaa:0:4

    2. Sur le système partym, ajoutez la route suivante :

       # route add -inet6 default 2001::eeee:0:1

13. Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.

14. Configurez un tunnel sécurisé ip6.tun0.

    ---

    Remarque –

    Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.

    ---

    1. Sur le système enigma, saisissez les commandes ci-dessous :

       # ifconfig ip6.tun0 inet6 plumb # ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333

    2. Sur le système partym, tapez les commandes ci-dessous :

       # ifconfig ip6.tun0 inet6 plumb # ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666

15. Protégez le tunnel à l'aide de la stratégie IPsec créée.

    # ipsecconf

16. Affichez le routeur pour le tunnel.

    # ifconfig ip6.tun0 router up

17. Activez le transfert IP pour l'interface hme1.

    # ifconfig hme1 router

18. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    # ifconfig hme0 private

19. Sur chaque système, ajoutez manuellement une route par défaut à travers hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :

       # route add -inet6 default 2001::aaaa:0:4

    2. Sur le système partym, ajoutez la route suivante :

       # route add -inet6 default 2001::eeee:0:1

20. Sur chaque système, assurez-vous que le VPN démarre à la réinitialisation en ajoutant une entrée au fichier /etc/hostname6.ip6.tun0.

    L'entrée réplique les paramètres spécifiés dans la commande ifconfig lors de l'Étape 14.

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname6.ip6.tun0 :

       6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname6.ip6.tun0 :

       6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

21. Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.

    1. Sur le système enigma, modifiez les fichiers /etc/hostname6. interface.

       # cat /etc/hostname6.hme0 ## enigma 6000:6666::aaaa:1116 inet6 private

       # cat /etc/hostname6.hme1 ## enigma 2001::aaaa:6666:6666 inet6 router

    2. Sur le système partym, modifiez les fichiers /etc/hostname6. interface.

       # cat /etc/hostname6.hme0 ## partym 6000:3333::eeee:1113 inet6 private

       # cat /etc/hostname6.hme1 ## partym2001::eeee:3333:3333 inet6 router

22. Exécutez un protocole de routage.

    # routeadm -e ipv6-routing # routeadm -u

Exemple 20–17 Configuration d'IPsec en mode Transport sur IPv6 à l'aide d'une syntaxe désapprouvée

Dans cet exemple, l'administrateur connecte un système Solaris 10 7/07 à un système exécutant la version Solaris10. Par conséquent, l'administrateur utilise la syntaxe Solaris10 dans le fichier de configuration et inclut les algorithmes IPsec à la commande ifconfig.

La procédure suivie par l'administrateur est identique à celle de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv6, à l'exception des modifications syntaxiques ci-dessous.

• Pour l'Étape 4, la syntaxe du fichier ipsecinit.conf est la suivante :

  # IPv6 Neighbor Discovery messages bypass IPsec. {ulp ipv6-icmp type 133-137 dir both} pass {} # LAN traffic can bypass IPsec. {laddr 6000:3333::eeee:1113 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {} ipsec {encr_algs aes encr_auth_algs sha1}

• Pour les étapes Étape 14 à Étape 17, la syntaxe permettant de configurer un tunnel sécurisé est la suivante :

  # ifconfig ip6.tun0 inet6 plumb # ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 \ encr_algs aes encr_auth_algs sha1 # ifconfig ip6.tun0 inet6 router up

  La stratégie IPsec utilisée dans les commandes ifconfig doit correspondre à celle qui est spécifiée dans le fichier ipsecinit.conf. À la réinitialisation, chaque système lit le fichier ipsecinit.conf pour connaître sa stratégie.

• Pour l'Étape 20, la syntaxe du fichier hostname6.ip6.tun0 est la suivante :

  6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 \ encr_algs aes encr_auth_algs sha1 router up

Protection contre l'usurpation d'adresse IP

Afin d'empêcher le système de transmettre des paquets vers une autre interface sans tenter de les déchiffrer, le système doit contrôler les éventuelles usurpations d'adresse IP. Une méthode de prévention consiste à définir un paramètre multiréseau strict de destination IP, par le biais de la commande ndd. Lorsque ce paramètre est défini dans un manifeste SMF, le paramètre est défini lors du redémarrage du système.

Effectuez cette procédure sur les deux systèmes.

1. 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.

2. Créez un manifeste SMF spécifique à un site afin de vérifier la présence d'éventuelles usurpations d'adresse IP.

   Utilisez l'exemple de script suivant, /var/svc/manifest/site/spoof_check.xml.

   <?xml version="1.0"?>
   <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
   
   <service_bundle type='manifest' name='Custom:ip_spoof_checking'>
   
   <!--    This is a custom smf(5) manifest for this system. Place this
           file in /var/svc/manifest/site, the directory for local
           system customizations. The exec method uses an unstable
           interface to provide a degree of protection against IP
           spoofing attacks when this system is acting as a router.
   
           IP spoof protection can also be achieved by using ipfilter(5).
           If ipfilter is configured, this service can be disabled.
   
           Note: Unstable interfaces might be removed in later
           releases.  See attributes(5).
   -->
   
   <service
           name='site/ip_spoofcheck'
           type='service'
           version='1'>
   
           <create_default_instance enabled='false' />
           <single_instance />
   
           <!--    Don't enable spoof protection until the
                   network is up.
           -->
           <dependency
                   name='basic_network'
                   grouping='require_all'
                   restart_on='none'
                   type='service'>
           <service_fmri value='svc:/milestone/network' />
           </dependency>
   
           <exec_method
                   type='method'
                   name='start'
                   exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
   <!--    
        For an IPv6 network, use the IPv6 version of this command, as in:
                   exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
   -->
                   timeout_seconds='60'
           />
   
           <exec_method
                   type='method'
                   name='stop'
                   exec=':true'
                   timeout_seconds='3'
           />
   
           <property_group name='startd' type='framework'>
                   <propval
                           name='duration'
                           type='astring'
                           value='transient'
                   />
           </property_group>
   
           <stability value='Unstable' />
   
   </service>
   </service_bundle>

3. Importez ce manifeste dans le référentiel SMF.

   # svccfg import /var/svc/manifest/site/spoof_check.xml

4. Activez le service ip_spoofcheck.

   Utilisez le nom qui est défini dans le fichier manifeste, /site/ip_spoofcheck.

   # svcadm enable /site/ip_spoofcheck

5. Assurez-vous que le service ip_spoofcheck est en ligne.

   # svcs /site/ip_spoofcheck