test

Guide d'administration système : services IP

Chapitre 21 Architecture IPsec (référence)

Ce chapitre contient les informations de référence suivante :

Pour obtenir les instructions relatives à l'implémentation d'IPsec sur votre réseau, reportez-vous au Chapitre 20Configuration d'IPsec (tâches). Pour une présentation d'IPsec, reportez-vous au Chapitre 19Architecture IPsec (présentation).

Utilitaire de gestion du service IPsec

L'utilitaire de gestion des services (SMF) fournit les services suivants pour IPsec :

Pour plus d'informations sur l'utilitaire SMF, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration. Voir aussi les pages de manuel smf(5), svcadm(1M) et svccfg(1M).

Commande ipsecconf

Pour configurer la stratégie IPsec d'un hôte, vous devez exécuter la commande ipsecconf. À l'exécution de la commande de configuration de la stratégie, le système crée des entrées de stratégie IPsec dans le noyau. Elles lui permettent de vérifier la stratégie appliquée à tous les datagrammes IP entrants et sortants. Les datagrammes transférés ne sont pas soumis aux vérifications de stratégie ajoutées à l'aide de cette commande. La commande ipsecconf configure également la base de données de stratégie de sécurité (SPD, Security Policy Database).

Pour exécuter la commande ipsecconf, vous devez prendre le rôle de superutilisateur ou un rôle équivalent. La commande accepte les entrées qui protègent le trafic bidirectionnel. Elle accepte également celles qui protègent le trafic unidirectionnel.

Les entrées de stratégie au format d'adresse locale et d'adresse distante peuvent protéger le trafic dans les deux directions à l'aide d'une entrée de stratégie unique. Par exemple, les entrées de modèles laddr host1 et raddr host2 protègent le trafic dans les deux directions quand aucune direction n'est spécifiée pour l'hôte nommé. Par conséquent, une seule entrée de stratégie est nécessaire pour chaque hôte.

Les entrées de stratégie au format adresse source vers adresse de destination protège le trafic dans une seule direction. Par exemple, une entrée de stratégie suivant le modèle saddr host1 daddr host2 protège le trafic entrant ou le trafic sortant, non le trafic bidirectionnel. Par conséquent, pour protéger le trafic dans les deux directions, vous devez appliquer la commande ipsecconf à une autre entrée, saddr host2 daddr host1, par exemple.

Pour garantir l'activation de la stratégie IPsec au démarrage de la machine, vous pouvez créer le fichier de stratégie IPsec /etc/inet/ipsecinit.conf. Ce fichier est lu au démarrage des services réseau. Pour obtenir les instructions relatives à la création du fichier de stratégie IPsec, reportez-vous à la section Protection du trafic à l'aide d'IPsec (liste des tâches).

À partir de la version Solaris 10 4/09, avec l'option -c, la commande ipsecconf vérifie la syntaxe du fichier de stratégie IPsec que vous fournissez en argument.

Les entrées de stratégie ajoutées par le biais de la commande ipsecconf ne sont pas conservées après la réinitialisation du système. Pour vous assurer que la stratégie IPsec est active lorsque le système démarre, ajoutez l'entrée de stratégie au fichier /etc/inet/ipsecinit.conf. Dans la version actuelle, actualisez ou activez le service policy. Dans une version antérieure à la version Solaris 10 4/09, réinitialisez ou utilisez la commande ipsecconf. Pour des exemples, reportez-vous à la section Protection du trafic à l'aide d'IPsec (liste des tâches).

Fichier ipsecinit.conf

Pour appeler les stratégies de sécurité IPsec au démarrage du Système d'exploitation Solaris (SE Solaris), vous devez créer un fichier de configuration pour initialiser IPsec avec vos entrées de stratégie IPsec spécifiques. Le nom par défaut de ce fichier est /etc/inet/ipsecinit.conf. Reportez-vous à la page de manuel ipsecconf(1M) pour plus d'informations sur les entrées d'une stratégie et leur format. Une fois les stratégies configurées, vous pouvez exécuter la commande ipsecconf pour consulter ou modifier la configuration existante. À partir de la version Solaris 10 4/09, vous actualisez le service policy pour modifier la configuration existante.

Fichier exemple ipsecinit.conf

Le logiciel Solaris inclut le fichier exemple de stratégie IPsec, ipsecinit.sample. Vous pouvez l'utiliser comme modèle pour créer votre propre fichier ipsecinit.conf. Le fichier ipsecinit.sample contient les exemples suivants :


#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

Considérations de sécurité à propos de ipsecinit.conf et ipsecconf

Prenez la plus grande précaution lorsque vous transmettez une copie du fichier ipsecinit.conf sur un réseau. Un utilisateur malintentionné est en mesure de lire un fichier monté sur le réseau lorsque ce fichier est en cours de lecture. Par exemple, si le fichier /etc/inet/ipsecinit.conf est ouvert ou copié à partir d'un système de fichiers monté via NFS, un utilisateur malintentionné peut modifier la stratégie qu'il contient.

Veillez à configurer les stratégies IPsec avant de démarrer toute communication. En effet, les nouvelles entrées de stratégie peuvent affecter les connexions existantes. De même, ne modifiez pas les stratégies au milieu d'une communication.

En particulier, vous ne pouvez pas modifier la stratégie IPsec des sockets SCTP, TCP ou UDP sur lesquels un appel de fonction connect() ou accept() a été émis. Un socket dont la stratégie ne peut pas être modifiée est appelé un socket verrouillé. Les nouvelles entrées de stratégie ne protègent pas les sockets qui sont déjà verrouillés. Pour plus d'informations, reportez-vous aux pages de manuel connect(3SOCKET) et accept(3SOCKET).

Protégez votre système d'attribution de nom. Lorsque les deux conditions suivantes sont vérifiées, vos noms d'hôtes ne sont plus fiables.

Les défaillances de sécurité proviennent souvent d'une mauvaise utilisation des outils, non des outils eux-mêmes. Utilisez la commande ipsecconf avec prudence. Une console ou autre TTY connecté offrent les modes d'opération les plus sûrs.

Commande ipsecalgs

La structure cryptographique de Solaris fournit des algorithmes d'authentification et de chiffrement pour IPsec. La commande ipsecalgs permet d'établir la liste des algorithmes pris en charge par chacun des protocoles IPsec. La configuration ipsecalgs est stockée dans le fichier /etc/inet/ipsecalgs. En général, ce fichier n'a pas besoin d'être modifié. Cependant, si le fichier doit être modifié, utilisez la commande ipsecalgs. Le fichier ne doit jamais être édité directement. Dans la version actuelle, les algorithmes pris en charge sont synchronisés avec le noyau à l'initialisation du système par le service svc:/network/ipsec/ipsecalgs:default.

Les protocoles et algorithmes IPsec valides sont décrits par le DOI, ISAKMP, traité dans le document RFC 2407. Au sens global, un DOI (Domain of Interpretation, domaine d'interprétation) définit les formats de données, les types d'échange du trafic réseau ainsi que les conventions d'appellation des informations liées à la sécurité. Les stratégies de sécurité, les algorithmes et les modes de chiffrement sont toutes des informations ayant trait à la sécurité.

En particulier, le DOI ISAKMP définit les conventions d'attribution de nom et de numéro des algorithmes IPsec valides et de leurs protocoles, PROTO_IPSEC_AH et PROTO_IPSEC_ESP. Chaque algorithme est associé à exactement un protocole. Ces définitions DOI ISAKMP figurent dans le fichier /etc/inet/ipsecalgs. Les numéros d'algorithme et de protocole sont définis par l'IANA (Internet Assigned Numbers Authority). La commande ipsecalgs permet d'allonger la liste des algorithmes IPsec.

Pour plus d'informations sur les algorithmes, reportez-vous à la page de manuel ipsecalgs(1M) Pour plus d'informations sur la structure cryptographique Solaris, reportez-vous au Chapitre 13, Oracle Solaris Cryptographic Framework (Overview) du System Administration Guide: Security Services.

Base de données des associations de sécurité IPsec

Les informations sur les numéros de clés des services de sécurité IPsec sont conservées dans la base de données des associations de sécurité (SADB). Les associations de sécurité (SA) protègent les paquets entrants et sortants. Les SADB sont gérées par un processus utilisateur, éventuellement par plusieurs processus de coopération, qui envoient des messages sur un socket de type spécial. Ce mode de gestion des SADB s'apparente à la méthode décrite à la page de manuel route(7P) Seuls les superutilisateurs ou les utilisateurs ayant un rôle équivalent ont accès à la base de données.

Le démon in.iked et la commande ipseckey utilisent l'interface socket PF_KEY dans le cadre de la gestion des SADB. Pour plus d'informations sur la gestion des requêtes et des messages par les SADB, reportez-vous à la page de manuel pf_key(7P).

Utilitaires de génération de clés IPsec

Le protocole IKE permet la gestion automatique des clés pour les adresses IPv4 et IPv6. Pour obtenir les instructions relatives à la configuration IKE, reportez-vous au Chapitre 23Configuration du protocole IKE (tâches). L'utilitaire de génération manuelle de clés est la commande ipseckey, décrite à la page de manuel ipseckey(1M).

Utilisez la commande ipseckey pour remplir manuellement la base de données des associations de sécurité (SADB). En règle générale, les SA sont générées manuellement lorsqu'IKE n'est pas disponible pour une raison quelconque. Cependant, si les valeurs SPI sont uniques, la génération manuelle des SA et IKE peuvent être utilisés en même temps.

La commande ipseckey permet d'afficher toutes les SA connues du système, que les clés aient été ajoutées manuellement ou par le biais d'IKE. À partir de la version Solaris 10 4/09, avec l'option -c, la commande ipseckey permet de vérifier la syntaxe du fichier de clés que vous spécifiez en tant qu'argument.

Les SA IPsec qui sont ajoutées par le biais de la commande ipseckey ne sont pas conservées après la réinitialisation du système. Dans la version actuelle, pour activer manuellement les SA ajoutés à l'initialisation du système, ajoutez des entrées au fichier /etc/inet/secret/ipseckeys, puis activez le service svc:/network/ipsec/manual-key:default. Pour connaître la procédure, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.

Bien qu'elle présente un nombre limité d'options générales, la commande ipseckey prend en charge un langage de commande enrichi. Si vous le souhaitez, une interface de programmation de génération manuelle de clés peut transmettre les requêtes. Pour de plus amples informations, reportez-vous à la page de manuel pf_key(7P).

Considérations de sécurité pour la commande ipseckey

La commande ipseckey permet au superutilisateur ou à un rôle auquel a été attribué le profil de droits Network Security ou Network IPsec Management de saisir des informations de clés cryptographiques confidentielles. Un utilisateur malintentionné accédant à ces informations peut compromettre la sécurité du trafic IPsec.

Prenez en considération les points suivants lorsque vous gérez des informations de génération de clés à l'aide de la commande ipseckey :

Les défaillances de sécurité proviennent souvent d'une mauvaise utilisation des outils, non des outils eux-mêmes. Utilisez la commande ipseckey avec prudence. Une console ou autre TTY connecté offrent les modes d'opération les plus sûrs.

Extensions IPsec d'autres utilitaires

La commande ifconfig offre des options de gestion de la stratégie IPsec sur une interface tunnel. La commande snoop peut analyser les en-têtes AH et ESP.

IPsec et commande ifconfig

Dans les versions Solaris10, Solaris10 7/05, Solaris10 1/06, et Solaris10 11/06 : Pour prendre en charge IPsec, la commande ifconfig offre les options de sécurité suivantes : Dans la version Solaris 10 7/07, ces options de sécurité sont gérées par la commande ipsecconf.

Vous devez indiquer toutes les options de sécurité IPsec d'un tunnel dans un appel unique. Par exemple, si la protection du trafic se limite à l'utilisation d'ESP, vous devez configurer le tunnel ip.tun0 une seule fois avec les deux options de sécurité, comme illustré ci-dessous :


# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

De la même manière, une entrée ipsecinit.conf configure le tunnel une fois avec les deux options de sécurité, comme illustré ci-dessous :


# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

Option de sécurité auth_algs

Cette option active AH IPsec pour un tunnel dont vous spécifiez l'algorithme d'authentification. L'option auth_algs présente le format suivant :


auth_algs authentication-algorithm

En ce qui concerne l'algorithme, vous pouvez indiquer un numéro ou un nom, y compris le paramètre any pour n'exprimer aucune préférence d'algorithme spécifique. Pour désactiver la sécurité du tunnel, spécifiez l'option suivante :


auth_algs none

Pour obtenir la liste des algorithmes d'authentification disponibles, exécutez la commande ipsecalgs.

Remarque –

L'option auth_algs n'est pas compatible avec NAT-Traversal. Pour plus d'informations, reportez-vous à la section Passage de la translation d'adresses et IPsec.

Option de sécurité encr_auth_algs

Cette option active ESP IPsec pour un tunnel dont vous spécifiez l'algorithme d'authentification. L'option encr_auth_algs présente le format suivant :


encr_auth_algs authentication-algorithm

En ce qui concerne l'algorithme, vous pouvez indiquer un numéro ou un nom, y compris le paramètre any pour n'exprimer aucune préférence d'algorithme spécifique. Si vous indiquez un algorithme de chiffrement ESP sans algorithme d'authentification, la valeur de l'algorithme d'authentification ESP est définie par défaut sur le paramètre any.

Pour obtenir la liste des algorithmes d'authentification disponibles, exécutez la commande ipsecalgs.

Option de sécurité encr_algs

Cette option active ESP IPsec pour un tunnel dont vous spécifiez l'algorithme de chiffrement. L'option encr_algs présente le format suivant :


encr_algs encryption-algorithm

En ce qui concerne l'algorithme, vous pouvez indiquer un nom ou un numéro. Pour désactiver la sécurité du tunnel, spécifiez l'option suivante :


encr_algs none

Si vous spécifiez un algorithme d'authentification ESP sans algorithme de chiffrement, la valeur de chiffrement d'ESP est définie par défaut sur le paramètre null.

Pour obtenir la liste des algorithmes de chiffrement disponibles, exécutez la commande ipsecalgs.

IPsec et commande snoop

La commande snoop permet l'analyse des en-têtes ESP et AH. En raison du chiffrement des données ESP, la commande snoop ne détecte pas les en-têtes chiffrés et protégés par ESP. AH ne chiffre pas les données. Par conséquent, la commande snoop peut contrôler le trafic protégé par AH. L'option -V de la commande signale l'utilisation d'AH sur un paquet. Pour plus d'informations, reportez-vous à la page de manuel snoop(1M).

La section Vérification de la protection des paquets par IPsec contient un exemple détaillé de sortie snoop sur un paquet protégé.