Partie I Introduction à l'administration système : services IP
1. Suite de protocoles réseau TCP/IP Oracle Solaris (présentation)
Partie II Administration TCP/IP
2. Planification de votre réseau TCP/IP (tâches)
4. Planification d'un réseau IPv6 (tâches)
5. Configuration des services réseau TCP/IP et de l'adressage IPv4 (tâches)
6. Administration d'interfaces réseau (tâches)
7. Configuration d'un réseau IPv6 (tâches)
8. Gestion d'un réseau TCP/IP (tâches)
9. Dépannage des problèmes de réseau (tâches)
10. Présentation détaillée de TCP/IP et IPv4 (référence)
11. Présentation détaillée de IPv6 (référence)
12. À propos de DHCP (présentation)
13. Planification pour le service DHCP (liste des tâches)
14. Configuration du service DHCP (tâches)
15. Administration de DHCP (tâches)
16. Configuration et administration du client DHCP
17. Résolution des problèmes DHCP (référence)
18. Commandes et fichiers DHCP (référence)
19. Architecture IPsec (présentation)
20. Configuration d'IPsec (tâches)
Protection du trafic à l'aide d'IPsec (liste des tâches)
Protection du trafic à l'aide d'IPsec
Sécurisation du trafic entre deux systèmes à l'aide d'IPsec
Utilisation d'IPsec pour protéger un serveur Web du trafic non-web.
Affichage des stratégies IPsec
Génération de numéros aléatoires sur un système Solaris
Création manuelle d'associations de sécurité IPsec
Vérification de la protection des paquets par IPsec
Protection d'un VPN à l'aide d'IPsec
Protection d'un VPN à l'aide d'IPsec via des tunnels en mode Tunnel (exemple)
Protection d'un VPN à l'aide d'IPsec (liste des tâches)
Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv6
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv4
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv6
Protection contre l'usurpation d'adresse IP
21. Architecture IPsec (référence)
22. Protocole IKE (présentation)
23. Configuration du protocole IKE (tâches)
25. IP Filter dans Oracle Solaris (présentation)
28. Administration de Mobile IP (tâches)
29. Fichiers et commandes de Mobile IP (références)
31. Administration d'IPMP (tâches)
Partie VII Qualité de service IP (IPQoS)
32. Présentation d'IPQoS (généralités)
33. Planification d'un réseau IPQoS (tâches)
34. Création du fichier de configuration IPQoS (tâches)
35. Démarrage et maintenance d'IPQoS (tâches)
36. Utilisation de la comptabilisation des flux et de la collecte statistique (tâches)
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.
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.
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, Utilisation de la console de gestion Solaris (tâches) du Guide d’administration système : administration de base.
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.
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.
# Secure communication with partym 192.168.13.213 partym 2001::eeee:3333:3333 partym
# 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.
Le nom de fichier est /etc/inet/ipsecinit.conf. Vous en trouverez un exemple dans le fichier /etc/inet/ipsecinit.sample.
{laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{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).
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.
# init 6
Reportez-vous ensuite à la section Vérification de la protection des paquets par IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf
Corrigez les éventuelles erreurs, vérifiez la syntaxe du fichier, puis continuez.
# 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
# svcadm enable svc:/network/ipsec/ike:default
# svcadm restart svc:/network/ipsec/ike:default
# svcadm enable svc:/network/ipsec/manual-key:default
# svcadm refresh svc:/network/ipsec/manual-key:default
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.
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.
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, Utilisation de la console de gestion Solaris (tâches) du Guide d’administration système : administration de base.
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.
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.
L'Étape 12 est facultative dans toutes les versions de Solaris.
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.
# ipsecconf -c -f /etc/inet/ipsecinit.conf
# svcadm refresh svc:/network/ipsec/policy:default
# svcadm restart svc:/network/ipsec/ike
# svcadm refresh svc:/network/ipsec/manual-key:default
Votre installation est terminée. Si vous le souhaitez, vous pouvez effectuer l'Étape 12.
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.
# chmod 400 IPsecWebInitFile
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.
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.
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.
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.
$ ipsecconf
La commande affiche chaque entrée avec un index suivi d'un numéro.
$ ipsecconf -l
$ ipsecconf -L
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.
% od -x|-X -A n file | head -n
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.
Affiche le vidage octal au format hexadécimal. Le numéro hexadécimal obtenu s'imprime par blocs de 8 caractères.
Supprime la base de décalage d'entrée de l'affichage.
Constitue la source des numéros aléatoires.
Limite l'affichage aux n premières lignes de la sortie de commande.
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.
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.
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.
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, Utilisation de la console de gestion Solaris (tâches) du Guide d’administration système : administration de base.
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.
# ipseckey >
L'invite > indique que le mode de la commande ipseckey est activé.
> 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.
> 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.
Défini sur esp ou ah.
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.
Spécifie l'adresse IP d'un système.
Spécifie l'adresse IP du système homologue de adr.
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.
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.
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.
Utilisez les numéros aléatoires générés à l'Étape 1.
Pour Solaris 10 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.
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.
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.
# 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
# chmod 400 /etc/inet/secret/ipseckeys
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
# 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 Solaris 10. 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
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.
% su - Password: Type root password #
Dans une fenêtre de terminal sur partym, analysez les paquets du système enigma.
# snoop -v enigma Using device /dev/hme (promiscuous mode)
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
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 ----- ...
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.
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.
% 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).
Basez votre choix sur les profils de droits définis lors de l'Étape 1.
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.
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.
# svcadm refresh svc:/network/ipsec/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
# svcadm enable svc:/network/ipsec/ike
# svcadm refresh svc:/network/ipsec/ike
# 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
# svcadm disable svc:/network/ipsec/ike
# svcadm enable svc:/network/ipsec/manual-key
# svcadm refresh manual-key
# 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
# svcadm disable svc:/network/ipsec/manual-key
# 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.