Cette section répertorie les services IPsec, les RFC IPsec sélectionnés, ainsi que les fichiers et commandes propres à IPsec.
L'utilitaire de gestion des services (SMF) fournit les services suivants pour IPsec :
service svc:/network/ipsec/policy – gère la stratégie IPsec. Par défaut, ce service est activé. La valeur de la propriété config_file détermine l'emplacement du fichier ipsecinit.conf. La valeur initiale sur un système exécutant le profil de configuration réseau DefaultFixed est /etc/inet/ipsecinit.conf. Sur les systèmes qui ne sont pas en cours d'exécution, la valeur de la propriété ce profil est vide.
service svc:/network/ipsec/ipsecalgs – gère les algorithmes disponibles pour IPsec. Par défaut, ce service est activé.
service svc:/network/ipsec/manual-key – Active la gestion manuelle des clés. Par défaut, ce service est désactivé. La valeur de la propriété config_file détermine l'emplacement du fichier de configuration ipseckeys. La valeur initiale est /etc/inet/secret/ipseckeys.
service svc:/network/ipsec/ike – gère IKE. Par défaut, ce service est désactivé. Pour les propriétés configurables, reportez-vous à Service d'IKEv2 et Service d'IKEv1.
Pour une présentation complète de SMF, reportez-vous au Chapitre 1, Introduction à l’utilitaire de gestion des services du manuel Gestion des services système dans Oracle Solaris 11.2 . Reportez-vous aussi aux pages de manuel smf(5), svcadm(1M) et svccfg(1M).
Pour configurer la stratégie IPsec d'un hôte, vous devez exécuter la commande ipsecconf. A 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 paquets IP entrants et sortants. Paquets qui ne sont pas mis en tunnel et retransmis ne sont pas soumis aux vérifications de stratégie ajoutées à l'aide de cette commande. La commande ipsecconf gère aussi les entrées IPsec dans la base de données des stratégies de sécurité. Pour consulter les options de stratégie IPsec, reportez-vous à la page de manuel ipsecconf(1M).
Vous devez prendre le rôle root pour exécuter la commande ipsecconf. La commande peut configurer des entrées qui protègent le trafic bidirectionnel. Elle configure é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 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 s'initialise, ajoutez l'entrée de stratégie au fichier /etc/inet/ipsecinit.conf , puis actualisez ou activez le service policy. Pour obtenir des exemples, reportez-vous à la section Protection du trafic réseau à l'aide d'IPsec.
Pour activer la stratégie de sécurité IPsec lorsque vous démarrez Oracle Solaris, vous créez 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 la stratégie configurée, vous pouvez l'actualiser avec la commande svcadm refresh ipsec/policy.
Le logiciel Oracle Solaris comprend un exemple de fichier 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 :
...
# In the following simple example, outbound network traffic between the local
# host and a remote host will be encrypted. Inbound network traffic between
# these addresses is required to be encrypted as well.
#
# This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr)
# and 10.0.0.2 is the IPv4 address of the remote host (raddr).
#
{laddr 10.0.0.1 raddr 10.0.0.2} ipsec
{encr_algs aes encr_auth_algs sha256 sa shared}
# The policy syntax supports IPv4 and IPv6 addresses as well as symbolic names.
# Refer to the ipsecconf(1M) man page for warnings on using symbolic names and
# many more examples, configuration options and supported algorithms.
#
# This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr)
# and 10.0.0.2 is the IPv4 address of the remote host (raddr).
#
# The remote host will also need an IPsec (and IKE) configuration that mirrors
# this one.
#
# The following line will allow ssh(1) traffic to pass without IPsec protection:
{lport 22 dir both} bypass {}
#
# {laddr 10.0.0.1 dir in} drop {}
#
# Uncommenting the above line will drop all network traffic to this host unless
# it matches the rules above. Leaving this rule commented out will allow
# network packets that do not match the above rules to pass up the IP
# network stack. ,,,
La stratégie IPsec ne peut pas être modifiée pour les connexions établies. 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) man pages. En cas de doute, redémarrez la connexion. Pour plus d'informations, reportez-vous à la section SECURITY de la page de manuel ipsecconf(1M).
La Structure cryptographique fournit les algorithmes d'authentification et de chiffrement à 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é et ne doit jamais être modifié directement. Toutefois, si vous devez modifier le fichier, utilisez la commande ipsecalgs. 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. 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, reportez-vous au Chapitre 1, Structure cryptographique du manuel Gestion du chiffrement et des certificats dans Oracle Solaris 11.2 .
La commande ipseckey avec ses nombreuses options permet de gérer manuellement les clés pour IPsec. La commande ipseckey est décrite à la page de manuel ipseckey(1M).
La commande ipseckey permet à 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.
Pour plus d'informations, reportez-vous à la section SECURITY de la page de manuel ipseckey(1M).
La commande kstat peut afficher des statistiques sur ESP, AH et d'autres données liées à IPsec. Les options liées à IPsec sont répertoriées sous Dépannage des erreurs sémantiques dans IPsec et IKE. Reportez-vous également à la page de manuel kstat(1M).
La commande snoop peut analyser les en-têtes AH et ESP. 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, de manière que le trafic protégé par AH peut être inspecté à l'aide de la commande snoop. L'option –V de la commande signale l'utilisation d'AH sur un paquet. Pour plus de détails, reportez-vous à la page de manuel snoop(1M).
La section How to Verify That Packets Are Protected With IPsec contient un exemple détaillé de sortie Vérification de la protection des paquets par IPsec sur un paquet protégé.
Des analyseurs de réseau tiers sont également disponibles, notamment le logiciel open-source Wireshark qui est intégré à cette version.
Le groupe IETF (Internet Engineering Task Force) a publié un certain nombre de documents RFC (Request for Comments, demande de commentaires) décrivant l'architecture de sécurité de la couche IP. Pour plus d'informations sur les RFC, reportez-vous au site Web http://www.ietf.org/http://www.ietf.org/. Les références de sécurité IP les plus générales sont couvertes par les RFC suivants :
RFC 2411, "IP Security Document Roadmap", novembre 1998
RFC 2401, "Security Architecture for the Internet Protocol", novembre 1998
RFC 2402, "IP Authentication Header", novembre 1998
RFC 2406, "IP Encapsulating Security Payload (ESP)", novembre 1998
RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)", novembre 1998 ;
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP", novembre 1998 ;
RFC 2409, "The Internet Key Exchange (IKEv1)", novembre 1998
RFC 5996, "Internet Key Exchange Protocol Version 2 (IKEv2)", septembre 2010
RFC 3554, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", juillet 2003