Cette section met l'accent sur la sécurité à l'échelle du réseau. L'architecture IPsec (IP security) protège le réseau au niveau du paquet. IKE (Internet Key Exchange, échange de clé Internet) gère les clés pour IPsec. Oracle Solaris IP Filter contient un pare-feu.
L'architecture IPsec (IP security) offre la protection cryptographique des datagrammes IP dans les paquets réseau IPv4 et IPv6.
Le présent chapitre contient les informations suivantes :
Pour implémenter IPsec sur votre réseau, reportez-vous au Chapitre 20Configuration d'IPsec (tâches). Pour des informations de référence, reportez-vous au Chapitre 21Architecture IPsec (référence).
Solaris 10 4/09 : À partir de cette version, l'utilitaire de gestion des services (SMF) gère IPsec en tant qu'ensemble de services.
Par défaut, deux services IPsec sont activés lors de l'initialisation du système :
svc:/network/ipsec/policy:default
svc:/network/ipsec/ipsecalgs:default
Par défaut, les services de gestion des clés sont désactivés à l'initialisation du système :
svc:/network/ipsec/manual-key:default
svc:/network/ipsec/ike:default
Pour activer les stratégies IPsec sous SMF, effectuez les étapes suivantes :
Ajoutez des entrées de stratégie IPsec au fichier ipsecinit.conf.
Configurez le protocole IKE (Internet Key Exchange) ou configurez manuellement les clés.
Actualisez le service de stratégie IPsec.
Activez le service de gestion des clés.
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) et svcadm(1M).
À partir de cette version, les commandes ipsecconf et ipseckey ont une option -c permettant de vérifier la syntaxe de leurs fichiers de configuration respectifs. De plus, le profil de droits Network IPsec Management est fourni pour administrer IPsec et IKE.
Solaris 10 7/07 : À partir de cette version, IPsec implémente entièrement les tunnels en mode Tunnel et les utilitaires de prise en charge des tunnels sont modifiés.
IPsec implémente les tunnels en mode Tunnel pour les réseaux privés virtuels (VPN, Virtual Private Network). En mode Tunnel, IPsec prend en charge plusieurs clients derrière un NAT unique. En mode Tunnel, IPsec est interopérable avec les implémentations des tunnels IP-in-IP d'autres constructeurs. IPsec prend toujours en charge les tunnels en mode Transport, ce qui garantit sa compatibilité avec les versions Solaris antérieures.
La syntaxe de création d'un tunnel est simplifiée. La commande ipsecconf a été étendue à la gestion de la stratégie IPsec. La commande ifconfig ne permet plus la gestion de la stratégie IPsec.
À partir de cette version, le fichier /etc/ipnodes est supprimé. Configurez les adresses de réseau IPv6 à l'aide du fichier /etc/hosts.
Solaris10 1/06 : à partir de cette version, IKE est entièrement compatible avec la prise en charge NAT-Traversal comme décrit dans le document RFC 3947 et RFC 3948. Les opérations IKE utilisent la bibliothèque PKCS #11 à partir de la structure cryptographique, ce qui améliore les performances.
La structure cryptographique fournit un fichier keystore de clés softtoken pour les applications qui utilisent le métaconnecteur. Lorsque IKE utilise le métaconnecteur, vous avez la possibilité de stocker les clés sur un disque, sur une carte connectée ou dans le fichier keystore de clés softtoken.
Pour utiliser le fichier keystore de clés softtoken, reportez-vous à la page de manuel cryptoadm(1M).
Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10.
Pour protéger les paquets IP, IPsec les chiffre et/ou les authentifie. IPsec s'exécute au sein du module IP, bien en dessous de la couche d'application. Par conséquent, une application Internet peut tirer profit d'IPsec sans pour autant avoir à modifier sa configuration. Une utilisation à bon escient d'IPsec en fait un outil efficace de sécurisation du trafic réseau.
La protection IPsec implique cinq composants principaux :
Protocoles de sécurité : les mécanismes de protection de datagramme IP. L'en-tête d'authentification (AH, Authentication Header) signe les paquets IP et garantit leur intégrité. Bien que le contenu du datagramme ne soit pas chiffré, le destinataire est sûr que le contenu du paquet n'a subi aucune modification et que l'expéditeur a envoyé les paquets. protocole ESP chiffre les données IP et obscurcit, par conséquent, le contenu des paquets lors de leur transmission. ESP garantit également l'intégrité des données par le biais d'une option d'algorithme d'authentification.
SADB (Security Associations Database, base de données des associations de sécurité) : base de données qui associe un protocole de sécurité à une adresse IP de destination et un numéro d'indexation. Ce numéro d'indexation est appelé index du paramètre de sécurité. Ces trois éléments (protocole de sécurité, adresse de destination et SPI) identifient un seul paquet IPsec légitime. La base de données garantit que le paquet protégé est reconnu par le récepteur à son arrivée. Elle permet également au récepteur de déchiffrer la communication, de vérifier que les paquets n'ont pas été altérés, de rassembler les paquets et de livrer les paquets à leur destination finale.
Gestion des clés : génération et distribution des clés des algorithmes de chiffrement et de SPI.
Mécanismes de sécurité : algorithmes de chiffrement et d'authentification qui protègent les données des datagrammes IP.
SPD (Security Policy Database, base de données de stratégie de sécurité) : base de données indiquant le niveau de protection à appliquer à un paquet. La base de données SPD filtre le trafic IP et identifie le mode de traitement des paquets. Un paquet peut être rejeté, passé au clair ou protégé à l'aide d'IPsec. En ce qui concerne les paquets sortants, les bases de données SPD et SADB déterminent le niveau de protection à appliquer. Pour les paquets entrants, la base de données SPD permet de déterminer l'acceptabilité du niveau de protection. Si le paquet est protégé par IPsec, une consultation de la base de données SPD est effectuée après déchiffrement et vérification du paquet.
IPsec applique les mécanismes de sécurité aux datagrammes IP circulant en direction de l'adresse IP de destination. À l'aide des informations contenues dans la base de données SADB, le destinataire vérifie que les paquets entrants sont légitimes et les déchiffre. Les applications peuvent appeler IPsec pour appliquer les mécanismes aux datagrammes IP au niveau de chaque socket.
Notez que le comportement des sockets diffère en fonction des ports :
Les SA par socket remplacent leur entrée de port correspondante dans la base de données SPD.
Par ailleurs, lorsque la stratégie IPsec est appliquée à un port sur lequel un socket est déjà connecté, le trafic qui utilise ce socket ne bénéficie pas de la protection IPsec.
En revanche, les sockets ouverts sur un port après l'application de la stratégie IPsec en bénéficient aussi.
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. Tous les RFC constituent la propriété intellectuelle de l'Internet Society. Pour plus d'informations sur les RFC, reportez-vous au site Web http://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 (IKE)", novembre 1998 ;
RFC 3554, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", juillet 2003 [ non implémenté dans la version Solaris10 ].
Les documents RFC IPsec définissent un certain nombre de termes qui s'avèrent utiles lors de l'implémentation d'IPsec sur des systèmes. Les tableaux suivants répertorient les termes IPsec, leur acronyme et leur définition. Le Tableau 22–1 dresse la liste des termes de négociation de clé.
Tableau 19–1 Termes IPsec, acronymes et usages
Terme IPsec |
Acronymes |
Définition |
---|---|---|
Association de sécurité |
SA (Security Association) |
Connexion unique entre deux nœuds sur un réseau. La connexion est définie par les trois éléments suivants : un protocole de sécurité, un index de paramètre de sécurité et une destination IP. La destination IP peut être une adresse IP ou un socket. |
Base de données d'associations de sécurité |
SADB (Security Associations Database) |
Base de données contenant toutes les associations de sécurité actives. |
Index de paramètre de sécurité |
SPI (Security Parameter Index) |
Valeur d'indexation d'une association de sécurité. Une SPI est une valeur 32 bits qui différencie les SA partageant une destination IP et un protocole de sécurité. |
SPD (Security Policy Database) |
Base de données déterminant si les paquets entrants et sortants présentent le niveau de protection spécifié. |
|
Échange de clés |
|
Processus de génération de clés pour les algorithmes cryptographiques asymétriques. Les principales méthodes utilisées sont les protocoles RSA et Diffie-Hellman. |
Protocole Diffie-Hellman |
DH |
Protocole d'échange de clés impliquant la génération et l'authentification de clés et souvent appelé échange de clés authentifiées. |
Protocole RSA |
RSA |
Protocole d'échange de clés impliquant la génération et la distribution de clés, Ce protocole porte le nom de ses trois créateurs : Rivest, Shamir et Adleman. |
Association de sécurité Internet et protocole de gestion des clés |
ISAKMP (Internet Security Association and Key Management Protocol) |
Structure courante d'établissement du format des attributs SA, et de négociation, modification et suppression des SA. ISAKMP est le standard IETF de gestion des SA IPsec. |
La Figure 19–1 illustre la procédure suivie par un paquet adressé IP, en tant que partie intégrante d'un datagramme IP lors d'un appel IPsec sur un paquet sortant. Le diagramme du flux indique l'endroit auquel les en-têtes d'authentification AH et les associations de sécurité ESP sont susceptibles d'être appliqués au paquet. Les méthodes d'application de ces entités et de sélection des algorithmes sont décrites dans les sections suivantes.
La Figure 19–2 illustre le processus entrant IPsec.
Uneassociation de sécurité (SA, Security Association) IPsec spécifie les propriétés de sécurité que reconnaissent les hôtes lors de la communication. Une seule SA protège les données dans une direction. La protection s'applique à un seul hôte ou à une adresse de groupe (multidiffusion). La communication s'effectuant généralement entre homologues ou entre client et serveur, la sécurité du trafic dans les deux directions requiert la présence de deux SA.
Les trois éléments suivants identifient une SA IPsec de manière unique :
le protocole de sécurité (AH ou ESP) ;
l'adresse IP de destination ;
Le SPI, valeur arbitraire 32 bits, est transmis avec un paquet AH ou ESP. Les pages de manuel ipsecah(7P) et ipsecesp(7P) expliquent l'étendue de la protection AH et ESP. Une somme de contrôle d'intégrité permet d'authentifier un paquet. En cas d'échec de l'authentification, le paquet est rejeté.
Les associations de sécurité sont stockées dans une base de données d'associations de sécurité (SADB). Un moteur d'administration socket, l'interface PF_KEY, autorise les applications privilégiées à gérer la base de données. Par exemple, l'application IKE et la commande ipseckeys font appel à l'interface socket PF_KEY.
Pour une description détaillée de la SADB IPsec, reportez-vous à la section Base de données des associations de sécurité IPsec.
Pour plus d'informations sur la gestion de la SADB, consultez la page de manuel pf_key(7P).
Les associations de sécurité (SA) requièrent des numéros de clé pour l'authentification et le chiffrement. Le processus permettant de gérer ces numéros de clés est appelé la gestion des clés. Le protocole IKE (Internet Key Exchange, échange de clé Internet) gère les clés automatiquement. La commande ipseckey permet la gestion manuelle des clés, le cas échéant.
Les SA sur les paquets IPv4 et IPv6 peuvent recourir à chacune des méthodes. Il est recommandé d'utiliser la gestion automatique à moins d'avoir une bonne raison de préférer la gestion manuelle. Par exemple, la gestion manuelle de clés s'impose dans le cadre d'interopérations avec des systèmes autres que les systèmes Solaris.
Dans la version actuelle, l'utilitaire SMF fournit les services de gestion de clés pour IPsec :
Le service svc:/network/ipsec/ike:default correspond au service SMF utilisé pour la gestion automatique des clés. Le service ike exécute le démon in.iked pour la gestion automatique des clés. Le Chapitre 22Protocole IKE (présentation) propose une description du protocole IKE. Pour plus d'informations sur le démon in.iked, reportez-vous à la page de manuel in.iked(1M). Pour plus d'informations sur le service ike, reportez-vous à la section Utilitaire de gestion du service IKE.
Le service svc:/network/ipsec/manual-key:default correspond au service SMF utilisé pour la gestion manuelle des clés. Le service manual-key exécute la commande ipseckey avec de nombreuses options pour gérer les clés manuellement. La commande ipseckey est décrite à la section Utilitaires de génération de clés IPsec. Pour obtenir une description détaillée des options de la commande ipseckey, reportez-vous à la page de manuel ipseckey(1M).
Dans les versions antérieures à la version Solaris 10 4/09, les commandes in.iked et ipseckey permettent de gérer les numéros de clé.
Le démon in.iked permet la gestion automatique des clés. Le Chapitre 22Protocole IKE (présentation) propose une description du protocole IKE. Pour plus d'informations sur le démon in.iked, reportez-vous à la page de manuel in.iked(1M).
La commande ipseckey permet de gérer les clés manuellement. La section Utilitaires de génération de clés IPsec propose une description de cette commande. Pour obtenir une description détaillée des options de la commande ipseckey, reportez-vous à la page de manuel ipseckey(1M).
IPsec offre deux protocoles de sécurité dans le cadre de la protection des données :
AH (Authentication Header, en-tête d'authentification)
ESP (Encapsulating Security Payload, association de sécurité)
AH protège les données à l'aide d'un algorithme d'authentification. ESP protège les données à l'aide d'un algorithme de chiffrement, mais peut avoir recours à un algorithme d'authentification facultatif. On appelle mécanisme l'implémentation d'un algorithme.
L'en-tête d'authentification offre l'authentification des données, un niveau élevé d'intégrité et la protection de rediffusion des datagrammes IP. AH protège la majeure partie du datagramme IP. Comme l'illustre la figure suivante, AH est inséré entre l'en-tête IP et l'en-tête de transport.
L'en-tête de transport peut être TCP, UDP, SCTP ou ICMP. Dans le cas de l'utilisation d'un tunnel, l'en-tête de transport peut être un autre en-tête IP.
Le module protocole ESP assure la confidentialité des encapsulations ESP. ESP propose également les services AH. Toutefois, ESP n'offre sa protection qu'à la partie des datagrammes d'encapsulation ESP. ESP fournit des services d'authentification facultatifs afin d'assurer l'intégrité du paquet protégé. Du fait qu'ESP utilise une technologie de chiffrement, un système fournissant ESP peut être soumis à des lois sur le contrôle des importations et exportations.
ESP encapsule ses données de sorte à protéger uniquement les données figurant à la suite de son commencement dans le datagramme, comme illustré ci-dessous.
Dans un paquet TCP, ESP encapsule uniquement l'en-tête TCP et ses données. Si le paquet est un datagramme IP-in-IP, ESP protège le datagramme IP interne. La stratégie par socket permet l'auto-encapsulation. Ainsi, ESP peut encapsuler les options IP, le cas échéant.
Lorsque l'auto-encapsulation est définie, l'en-tête IP est copié afin de créer un datagramme IP-in-IP. Par exemple, lorsque l'auto-encapsulation n'est pas définie sur un socket TCP, le datagramme est envoyé dans le format suivant :
[ IP(a -> b) options + TCP + data ] |
Lorsque l'auto-encapsulation est définie sur ce socket TCP, le datagramme est envoyé dans le format suivant :
[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ] |
Pour de plus amples informations, reportez-vous à la section Modes Transport et Tunnel dans IPsec.
Le tableau suivant permet de comparer les protections AH et ESP.
Tableau 19–2 Protections assurées par AH et ESP dans IPsec
Les protocoles de sécurité IPsec font appel à deux types d'algorithmes : les algorithmes d'authentification et les algorithmes de chiffrement. Le module AH recourt aux algorithmes d'authentification. Le module ESP peut utiliser aussi bien les algorithmes d'authentification que les algorithmes de chiffrement. La commande ipsecalgs affiche la liste des algorithmes présents sur le système, ainsi que leurs propriétés. Pour plus d'informations, reportez-vous à la page de manuel ipsecalgs(1M) Vous pouvez aussi utiliser les fonctions décrites dans la page de manuel getipsecalgbyname(3NSL)pour obtenir les propriétés des algorithmes.
Pour accéder aux algorithmes sur un système Solaris, IPsec fait appel à la structure cryptographique Solaris. Celle-ci offre un référentiel central d'algorithmes, en plus d'autres services. Elle permet à IPsec de tirer profit des accélérateurs cryptographiques hautes performances et offre des fonctions de contrôle de ressources. Par exemple, la structure permet de limiter le temps CPU consacré aux opérations cryptographiques dans le noyau.
Pour plus d'informations, consultez les références suivantes :
Les algorithmes d'authentification génèrent une valeur de somme de contrôle d'intégrité, digest, à partir des données et d'une clé. Le module AH recourt aux algorithmes d'authentification. Le module ESP peut également y avoir recours.
Les algorithmes de chiffrement chiffrent les données à l'aide d'une clé. Dans IPsec, le module ESP fait appel aux algorithmes de chiffrement. Les algorithmes agissent sur les données dans des unités d'une taille de bloc.
Les diverses versions du SE Solaris10 offrent différents algorithmes de chiffrement par défaut.
À partir de la version Solaris 10 7/07, n'ajoutez plus Solaris Encryption Kit à votre système. Le kit effectue une mise à niveau inférieure du patch de chiffrement de votre système. Le kit n'est pas compatible avec le chiffrement de votre système.
À partir de la version Solaris 10 7/07, le contenu de Solaris Encryption Kit est installé par le support d'installation Solaris. Cette version intègre les algorithmes d'authentification SHA2 suivants : sha256, sha384 et sha512. Les implémentations SHA2 sont conformes à la spécification RFC 4868. Cette version ajoute également des groupes Diffie-Hellman plus grands : 2 048 bits (groupe 14), 3 072 bits (groupe 15) et 4 096 bits (groupe 16). Notez que les systèmes Sun alliés à la technologie CoolThreads permettent d'accélérer les groupes de 2 048 bits uniquement.
Dans les versions antérieures à Solaris 10 7/07, le support d'installation Solaris n'offre que des algorithmes de base ; toutefois, Solaris Encryption Kit vous permet d'ajouter des algorithmes plus avancés.
Par défaut, les algorithmes DES-CBC, 3DES-CBC, AES-CBC et Blowfish-CBC sont installés. Les tailles de clé prises en charge par les algorithmes AES-CBC et Blowfish-CBC ne peuvent excéder 128 bits.
Les algorithmes AES-CBC et Blowfish-CBC prenant en charge les tailles de clé supérieures à 128 bits sont disponibles dans IPsec si vous installez le kit de chiffrement Solaris. Toutefois, certains algorithmes de chiffrement ne sont pas disponibles en dehors des États-Unis. Le kit est disponible sur un CD distinct qui ne fait pas partie du coffret d'installation Solaris10. Pour l'installer, consultez le document Solaris 10 Encryption Kit Installation Guide. Pour plus d'informations, reportez-vous au centre de téléchargement Sun. Pour télécharger le kit, cliquez sur l'onglet Downloads A-Z, puis sur la lettre S. Solaris 10 Encryption Kit fait partie des 20 premières entrées.
Les stratégies de protection IPsec peuvent recourir aux mécanismes de sécurité, quels qu'ils soient. Vous pouvez appliquer les stratégies IPsec aux niveaux suivants :
à l'échelle du système ;
par socket.
IPsec applique la stratégie à l'échelle du système aux datagrammes entrants et sortants. Les datagrammes sortants sont envoyés avec ou sans protection. Si la protection est appliquée, les algorithmes sont soit spécifiques, soit non spécifiques. Vous pouvez appliquer d'autres règles aux datagrammes sortants, en raison des données supplémentaires connues du système. Les datagrammes sortants peuvent être acceptés ou rejetés. La décision d'accepter ou de rejeter un datagramme sortant est fonction de plusieurs critères qui peuvent se chevaucher et être contradictoires. Pour résoudre les conflits éventuels, il faut identifier la règle à analyser en premier. Le trafic est accepté automatiquement, sauf si une entrée de stratégie indique qu'il doit ignorer toutes les autres stratégies.
La stratégie qui protège normalement un datagramme peut être ignorée. Vous pouvez spécifier une exception dans la stratégie à l'échelle du système ou demander un contournement dans la stratégie par socket. Au niveau du trafic système, les stratégies sont mises en œuvre, mais les mécanismes de sécurité à proprement parler ne sont pas appliqués. En revanche, la stratégie sortante sur un paquet interne au système se traduit par un paquet sortant auquel ces mécanismes ont été appliqués.
La configuration des stratégies IPsec s'effectue à l'aide du fichier ipsecinit.conf et de la commande ipsecconf. La page de manuel ipsecconf(1M) contient des exemples et des explications complémentaires.
Les normes IPsec définissent deux modes distincts d'opération IPsec : le mode Transport et le mode Tunnel. Ces modes n'ont aucune incidence sur le codage des paquets. Les paquets sont protégés par AH, ESP ou ces deux protocoles dans chaque mode. L'application de la stratégie des modes est différente lorsque le paquet interne est un paquet IP :
En mode Transport, l'en-tête extérieur détermine la stratégie IPsec qui protège le paquet IP interne.
En mode Tunnel, le paquet IP interne détermine la stratégie IPsec qui protège son contenu.
En mode Transport, l'en-tête extérieur ainsi que l'en-tête suivant et tout port pris en charge par celui-ci permettent de déterminer la stratégie IPsec. En fait, IPsec peut mettre en œuvre différentes stratégies en mode Transport entre deux adresses IP au niveau d'un seul port. Par exemple, si l'en-tête suivant est un en-tête TCP, qui prend en charge les ports, la stratégie IPsec peut alors être définie pour un port TCP de l'adresse IP externe. De même, si l'en-tête suivant est IP, l'en-tête extérieur et l'en-tête IP intérieur permettent de déterminer la stratégie IPsec.
Le mode Tunnel ne fonctionne que pour les datagrammes IP-in-IP. La mise sous tunnel en mode Tunnel peut s'avérer utile lorsque des personnes travaillant à domicile se connectent à un emplacement central. En mode Tunnel, la stratégie IPsec est mise en œuvre sur le contenu du datagramme IP interne. Différentes stratégies IPsec peuvent être mises en œuvre pour différentes adresses IP internes. En d'autres termes, l'en-tête IP interne, ainsi que son en-tête suivant et les ports que ce dernier prend en charge, peuvent mettre en œuvre une stratégie. Contrairement au mode Transport, le mode Tunnel ne permet pas à l'en-tête IP extérieur de dicter la stratégie de son datagramme IP interne.
Par conséquent, en mode Tunnel, la stratégie IPsec peut être spécifiée pour les sous-réseaux d'un LAN derrière un routeur et pour les ports de ces sous-réseaux. La stratégie IPsec peut également être spécifiée pour des adresses IP données (des hôtes) sur ces sous-réseaux. Les ports de ces hôtes peuvent aussi avoir une stratégie IPsec spécifique. Toutefois, si un protocole de routage dynamique est exécuté sur un tunnel, veillez à ne pas utiliser de sélection de sous-réseau ou d'adresse, car la vue de la topologie réseau sur le réseau homologue pourrait être modifiée. Les modifications annuleraient la stratégie IPsec statique. La section Protection d'un VPN à l'aide d'IPsec contient des exemples de mises en tunnel comprenant la configuration de routes statiques.
Dans SE Solaris, le , mode Tunnel peut être appliquée uniquement dans une interface de réseau de tunnels IP. La commande ipsecconf fournit un mot-clé tunnel pour sélectionner une interface de réseau de tunnels IP. Lorsque le mot-clé tunnel figure dans une règle, tous les sélecteurs spécifiés dans cette règle s'appliquent au paquet interne.
En mode Transport, ESP et/ou AH peuvent protéger le datagramme.
La figure suivante illustre un en-tête IP avec un paquet TCP non protégé.
En mode Transport, ESP protège les données, comme illustré ci-dessous. La zone ombrée indique la partie chiffrée du paquet.
En mode Transport, AH protège les données comme illustré ci-dessous.
AH couvre en fait les données avant leur apparition dans le datagramme. Par conséquent, la protection assurée par AH, même en mode Transport, couvre en partie l'en-tête IP.
En mode Tunnel, l'intégralité du datagramme figure à l'intérieur de la protection d'un en-tête IPsec. Le datagramme de la Figure 19–3 est protégé en mode Tunnel par un en-tête IPsec externe, ESP dans ce cas, comme indiqué sur l'illustration suivante.
La commande ipsecconf inclut des mots-clés permettant de définir des tunnels en mode Tunnel ou Transport.
Pour plus d'informations sur la stratégie par socket, reportez-vous à la page de manuel ipsec(7P).
La section Utilisation d'IPsec pour protéger un serveur Web du trafic non-web. comprend un exemple de stratégie par socket.
Pour plus d'informations sur les tunnels, reportez-vous à la page de manuel ipsecconf(1M).
La section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 contient un exemple de configuration de tunnel.
Un tunnel configuré est une interface point-à-point. Le tunnel permet l'encapsulation d'un paquet IP dans un autre paquet IP. Un tunnel correctement configuré requiert une source et une destination. Pour plus d'informations, reportez-vous à la page de manuel tun(7M) et à la section Configuration de tunnels pour la prise en charge d'IPv6.
Un tunnel crée une interface physique liée à IP. L'intégrité du lien physique est fonction des protocoles de sécurité sous-jacents. La configuration sécurisée des associations de sécurité (SA) rend le tunnel digne de confiance. Les paquets sortant du tunnel doivent provenir de l'homologue spécifié dans la destination de tunnel. Si la confiance est établie, vous pouvez avoir recours au transfert IP par interface pour créer un VPN.
Vous pouvez créer un VPN à l'aide d'IPsec. IPsec sécurise la connexion. Par exemple, une organisation ayant recours à la technologie VPN pour connecter deux bureaux de réseaux distincts peut déployer IPsec pour sécuriser le trafic entre ces deux bureaux.
Dans l'illustration suivante, deux bureaux utilisent Internet pour constituer leur VPN, avec IPsec déployé sur leurs systèmes réseau.
La section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 contient un exemple détaillé de configuration.
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.
IKE peut négocier des SA IPsec dans une zone NAT Cela permet aux systèmes de se connecter en toute sécurité à partir d'un réseau distant, même lorsqu'ils résident derrière un périphérique NAT. Par exemple, les employés travaillant à domicile ou se connectant depuis un site de conférence peuvent protéger leur trafic à l'aide d'IPsec.
NAT est l'acronyme de Network Address Translation (translation d'adresse réseau). Un routeur NAT permet d'associer une adresse interne privée à une adresse Internet unique. Les routeurs NAT équipent de nombreux points d'accès publics à Internet, comme ceux qu'on trouve dans les hôtels. Pour plus d'informations, reportez-vous à la section Utilisation de la fonctionnalité NAT de Oracle Solaris IP Filter.
La capacité à utiliser IKE lorsqu'un boîtier NAT est placé entre deux systèmes communiquant est appelé NAT Traversal ou NAT-T. Dans la version Solaris10, NAT-T présente les limitations suivantes :
NAT-T fonctionne uniquement sur les réseaux IPv4.
NAT-T ne peut pas tirer profit de l'accélération ESP IPsec que procure la carte Sun Crypto Accelerator 4000. Toutefois, l'accélération IKE avec la carte Sun Crypto Accelerator 4000 fonctionne.
Le protocole AH dépend d'un en-tête IP qui ne change pas ; de ce fait, AH ne peut pas fonctionner avec NAT-T. Le protocole ESP est utilisé avec NAT-T.
Le routeur NAT n'applique pas de règles de traitement particulières. Un routeur NAT obéissant à des règles de traitement IPsec pourrait intervenir dans l'implémentation de NAT-T.
NAT-T fonctionne uniquement lorsque l'initiateur IKE est le système derrière le routeur NAT. Un répondeur IKE ne peut pas se trouver derrière un routeur NAT, à moins que celui-ci ne soit programmé pour transférer des paquets IKE au système adéquat figurant derrière lui.
Les RFC suivants décrivent la fonctionnalité NAT et les limites de NAT-T. Vous pouvez vous procurer des copies de ces RFC sur le site http://www.rfc-editor.org.
RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)", janvier 2001 ;
RFC 3715, "IPsec-Network Address Translation (NAT) Compatibility Requirements", mars 2004 ;
RFC 3947, "Negotiation of NAT-Traversal in the IKE", janvier 2005 ;
RFC 3948, "UDP Encapsulation of IPsec Packets", janvier 2005.
Pour une utilisation conjointe de IPsec et NAT, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des tâches).
Le système d'exploitation Solaris prend en charge le protocole SCTP (Streams Control Transmission Protocol). Bien que prise en charge, l'utilisation du protocole SCTP et du numéro de port SCTP dans le cadre de la spécification de la stratégie IPsec n'est pas stable. Les extensions IPsec pour SCTP spécifiées dans le document RFC 3554 ne sont pas encore implémentées. Ces restrictions peuvent être source de complications lors de la création de la stratégie IPsec pour SCPT.
SCTP peut avoir recours à plusieurs adresses source et cible dans le cadre d'une association SCTP unique. Lorsque la stratégie IPsec est appliquée à une seule adresse source ou cible, la communication peut échouer si SCTP change l'adresse source ou cible de cette association. La stratégie IPsec reconnaît uniquement l'adresse d'origine. Pour plus d'informations sur SCTP, consultez les documents RFC et Protocol SCTP.
Pour les zones IP partagées, la stratégie IPsec est configurée à partir de la zone globale. Le fichier de configuration de la stratégie IPsec, ipsecinit.conf, existe uniquement dans la zone globale. Le fichier peut contenir des entrées s'appliquant aux zones non globales et des entrées s'appliquant à la zone globale.
Pour les zones IP exclusives, la stratégie IPsec est configurée dans la zone non globale.
Pour plus d'informations à propos de l'utilisation d'IPsec avec des zones, reportez-vous à la section Protection du trafic à l'aide d'IPsec. Pour plus d'informations sur les zones, reportez-vous au Chapitre 16, Introduction aux zones Solaris du Guide d’administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris.
Le protocole IPsec fonctionne avec des domaines logiques. Le domaine logique doit être en cours d'exécution sur une version du système d'exploitation Solaris comprenant le protocole IPsec, comme la version Solaris 10.
Pour créer des domaines logiques, vous devez utiliser Oracle VM Server pour SPARC. Cette application s'appelait auparavant Sun Logical Domains. Pour savoir comment configurer des domaines logiques, reportez-vous au Logical Domains 1.2 Administration Guide ou au Oracle VM Server for SPARC 2.0 Administration Guide.
Le Tableau 19–3 décrit les fichiers, commandes et identificateurs de service utilisés pour configurer et gérer IPsec. Exhaustif, ce tableau inclut les commandes et fichiers de gestion des clés.
À partir de la version Solaris 10 4/09, IPsec est géré par SMF. Pour plus d'informations sur les identificateurs de services, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.
Pour obtenir les instructions relatives à l'implémentation IPsec sur le réseau, reportez-vous à la section Protection du trafic à l'aide d'IPsec (liste des tâches).
Pour plus d'informations sur les fichiers et utilitaires IPsec, consultez le Chapitre 21Architecture IPsec (référence).
Utilitaire IPsec, fichier ou service |
Description |
Page de manuel |
---|---|---|
svc:/network/ipsec/ipsecalgs |
Dans la version actuelle, le service SMF qui gère les algorithmes IPsec. | |
svc:/network/ipsec/manual-key |
Dans la version actuelle, le service SMF qui gère les associations de sécurité (SA) manuelles. | |
svc:/network/ipsec/policy |
Dans la version actuelle, le service SMF qui gère la stratégie IPsec. | |
svc:/network/ipsec/ike |
Dans la version actuelle, le service SMF pour la gestion automatique des SA IPsec. | |
Fichier /etc/inet/ipsecinit.conf |
Fichier de stratégie IPsec. Dans les versions antérieures à la version Solaris 10 4/09, si ce fichier existe, IPsec est activé au démarrage. Dans la version actuelle, le service policy de SMF utilise ce fichier pour configurer la stratégie IPsec lors de l'initialisation du système. | |
Commande ipsecconf |
Commande de stratégie IPsec. Utile pour afficher et modifier la stratégie IPsec actuelle, ainsi que pour effectuer des tests. Dans les versions antérieures à la version Solaris 10 4/09, les scripts d'initialisation utilisent ipsecconf pour lire le fichier /etc/inet/ipsecinit.conf et activer IPsec. Dans la version actuelle, ipsecconf est utilisé par le service policy de SMF pour configurer la stratégie IPsec lors de l'initialisation du système. | |
Interface socket PF_KEY |
SADB (Interface for Security Associations Database, interface de la base de données des associations de sécurité). Responsable de la gestion manuelle et automatique des clés. | |
Commande ipseckey |
Commandes de génération de clés pour les SA IPsec ipseckey est un point d'entrée de commandes de l'interface PF_KEY. ipseckey permet de créer, supprimer ou modifier les SA. | |
Fichier /etc/inet/secret/ipseckeys |
Clés pour SA IPsec. Dans les versions antérieures à la version Solaris 10 4/09, si le fichier ipsecinit.conf existe, le fichier ipseckeys est automatiquement lu au démarrage. Dans la version actuelle, ipseckeys est utilisé par le service manual-key de SMF pour configurer manuellement les SA à l'initialisation du système. | |
Commande ipsecalgs |
Commande d'algorithmes IPsec. Utile pour l'affichage et la modification de la liste d'algorithmes IPsec et de leurs propriétés. Dans la version actuelle, est utilisée par le service ipsecalgs de SMF pour synchroniser les algorithmes IPsec connus avec le noyau, à l'initialisation du système. | |
Fichier /etc/inet/ipsecalgs |
Contient les définitions d'algorithme et les protocoles IPsec configurés. Ce fichier est géré par la commande ipsecalgs et ne doit jamais être modifié manuellement. | |
Fichier /etc/inet/ike/config |
Fichier de configuration et de stratégie IKE. Par défaut, ce fichier n'existe pas. Dans les versions antérieures à la version Solaris 10 4/09, si ce fichier existe, le démon IKE, in.iked, permet la gestion automatique des clés. La gestion se base sur des règles et des paramètres généraux figurant dans le fichier /etc/inet/ike/config. Reportez-vous à la section Utilitaires et fichiers IKE. Dans la version actuelle, si ce fichier existe, le service svc:/network/ipsec/ike lance le démon IKE, in.iked pour la gestion automatique des clés. |
Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10. À partir de la version Solaris 9, IPsec inclut les fonctions suivantes :
Lorsqu'une carte Sun Crypto Accelerator 4000 est connectée, elle met automatiquement en cache les SA IPsec des paquets faisant appel à son interface Ethernet. La carte accélère également le traitement des SA IPsec.
IPsec peut tirer profit de la gestion automatique des clés avec IKE sur réseaux IPv6. Pour plus d'informations, reportez-vous au Chapitre 22Protocole IKE (présentation).
Pour connaître les nouvelles fonctions IKE, reportez-vous à la section Modifications apportées à IKE dans Solaris10.
L'analyseur de la commande ipseckey offre une aide plus claire. La commande ipseckey monitor indique la date et l'heure de chaque événement. Pour plus d'informations, reportez-vous à la page de manuel ipseckey(1M).
Les algorithmes IPsec proviennent désormais d'un espace de stockage central, la structure cryptographique Solaris. La page de manuel ipsecalgs(1M) décrit les caractéristiques des algorithmes disponibles. Les algorithmes sont optimisés pour l'architecture sur laquelle ils s'exécutent. Pour obtenir une description de la structure, reportez-vous au Chapitre 13, Oracle Solaris Cryptographic Framework (Overview) du System Administration Guide: Security Services.
IPsec fonctionne dans la zone globale. La stratégie IPsec est gérée dans la zone globale pour une zone non globale. Les numéros de clé sont créés et gérés manuellement dans la zone globale pour une zone non globale. IKE ne permet pas de générer des clés pour une zone non globale. Pour plus d'informations sur les zones, reportez-vous au Chapitre 16, Introduction aux zones Solaris du Guide d’administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris.
La stratégie IPsec peut fonctionner avec le protocole SCTP (Streams Control Transmission Protocol) et le numéro de port SCTP. Toutefois, l'implémentation reste incomplète. Les extensions IPsec pour SCTP spécifiées dans le document RFC 3554 ne sont pas encore implémentées. Ces restrictions peuvent être source de complications lors de la création de la stratégie IPsec pour SCPT. Pour plus d'informations, reportez-vous aux RFC. Consultez également les documents IPsec et SCTP et Protocol SCTP.
IPsec et IKE peuvent protéger le trafic généré derrière un routeur NAT. Pour en savoir plus sur les restrictions, reportez-vous à la section Passage de la translation d'adresses et IPsec. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des 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 :
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).
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).
Tâche |
Description |
Voir |
---|---|---|
Sécurisation du trafic entre deux systèmes |
Protège les paquets transmis d'un système à un autre. | |
Sécurisation d'un serveur Web à l'aide de la stratégie IPsec |
Requiert un trafic non-Web pour utiliser IPsec. Les clients Web sont identifiés par des ports particuliers : les vérifications IPsec sont ignorées. |
Utilisation d'IPsec pour protéger un serveur Web du trafic non-web. |
Affichage des stratégies IPsec |
Affiche les stratégies IPsec actuellement appliquées, dans l'ordre dans lequel elles sont mises en œuvre. | |
Génération de numéros aléatoires |
Génère des numéros aléatoires pour définir les numéros de clé afin de permettre la création manuelle d'associations de sécurité. | |
Création et remplacement manuels des associations de sécurité |
Fournit les données brutes des associations de sécurité :
| |
Vérification de la protection des paquets par IPsec |
Recherche des en-têtes spécifiques indiquant la méthode de protection des datagrammes IP dans la sortie de commande snoop. | |
(Facultatif) Création d'un rôle de sécurité réseau |
Crée un rôle pouvant configurer un réseau sécurisé, mais possédant moins de permissions que le superutilisateur. | |
Gestion d'IPsec et des numéros de clés en tant qu'ensemble de services SMF |
Décrit quand et comment utiliser les commandes permettant d'activer, de désactiver, d'actualiser et de redémarrer les services. Décrit également les commandes permettant de modifier les valeurs de propriété des services. | |
Configuration d'un réseau privé virtuel (VPN, Virtual Private Network) sécurisé |
Configure IPsec entre deux systèmes séparés par Internet. |
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.
Vous devez vous trouver dans la zone globale pour configurer la stratégie IPsec pour le système ou pour une zone IP partagée. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Les connexions à distance peuvent compromettre la sécurité du trafic de données critiques. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Exécutez la commande ssh pour assurer une connexion à distance sécurisée. Voir l' Exemple 20–1.
Sur chaque système, vérifiez les entrées d'hôte.
Dans la version actuelle, ajoutez les entrées d'hôte au fichier /etc/inet/hosts.
Sur un système exécutant une version antérieure à la version Solaris 10 7/07, insérez les entrées IPv4 et IPv6 dans le fichier /etc/inet/ipnodes. Les entrées d'un système doivent être contiguës dans le fichier. Pour de plus amples informations sur les fichiers de configuration système, reportez-vous à la section Fichiers de configuration TCP/IP et au Chapitre 11Présentation détaillée de IPv6 (référence).
Si vous connectez des systèmes utilisant exclusivement des adresses IPv4, modifiez le fichier /etc/inet/hosts. Dans cet exemple, les systèmes à connecter s'exécutent dans une version Solaris antérieure et utilisent des adresses IPv6.
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 |
Sur un système appelé partym, saisissez les lignes suivantes dans le fichier hosts ou ipnodes :
# Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 enigma |
L'utilisation de services d'assignation de noms pour des noms symboliques comporte des risques.
Sur chaque système, créez le fichier de stratégie IPsec.
Le nom de fichier est /etc/inet/ipsecinit.conf. Vous en trouverez un exemple dans le fichier /etc/inet/ipsecinit.sample.
Ajoutez une entrée de stratégie IPsec au fichier ipsecinit.conf.
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} |
Sur le système partym, ajoutez la même stratégie :
{laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
La syntaxe des entrées de stratégie IPsec est décrite dans la page de manuel ipsecconf(1M).
Sur chaque système, ajoutez une paire de SA IPsec entre les deux systèmes.
Vous pouvez configurer le protocole IKE (Internet Key Exchange, échange de clé Internet) afin de créer automatiquement les SA. Vous pouvez également ajouter les SA manuellement.
Il est recommandé d'utiliser IKE, sauf si, pour des raisons spécifiques, vous devez générer les clés et les mettre à jour manuellement. La gestion des clés à l'aide d'IKE est plus sécurisée.
Configurez IKE en suivant l'une des procédures de configuration décrites à la section Configuration du protocole IKE (liste des tâches). La syntaxe du fichier de configuration IKE est décrite à la page de manuel ike.config(4).
Pour ajouter des SA manuellement, reportez-vous à la section Création manuelle d'associations de sécurité IPsec.
Activez la stratégie IPsec.
Si vous exécutez une version antérieure à la version Solaris 10 4/09, réinitialisez le système.
# init 6 |
Reportez-vous ensuite à la section Vérification de la protection des paquets par IPsec.
À partir de la version Solaris 10 4/09, actualisez le service IPsec et activez le service de gestion des clés.
Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Corrigez les éventuelles erreurs, vérifiez la syntaxe du fichier, puis continuez.
Actualisez la stratégie IPsec.
# svcadm refresh svc:/network/ipsec/policy:default |
La stratégie IPsec est activée par défaut. Actualisez-la. Si vous avez désactivé la stratégie IPsec, activez-la.
# svcadm enable svc:/network/ipsec/policy:default |
Activez les clés pour IPsec.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Actualisez la stratégie IPsec.
# svcadm refresh svc:/network/ipsec/policy:default |
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.
Créez un fichier dans le répertoire /etc/inet pour la stratégie de serveur Web.
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.
Copiez le contenu du fichier créé lors de l'Étape 8 dans le fichier /etc/inet/ipsecinit.conf.
Protégez le fichier FichierInitWebIPsec à l'aide de permissions de lecture seule.
# chmod 400 IPsecWebInitFile |
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 |
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.
(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.
Vous pouvez afficher les stratégies configurées dans le système lorsque vous exécutez la commande ipsecconf sans argument.
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.
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.
Affichage des stratégies IPsec
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.
Affichez les entrées de stratégie IPsec dans l'ordre dans lequel les correspondances sont repérées.
$ ipsecconf -l |
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 |
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.
Générez des numéros aléatoires au format hexadécimal.
% 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.
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.
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.
La gestion manuelle des numéros de clé pour une zone IP partagée s'effectue dans la zone globale.
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.
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.
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.
Créez les SA.
Activez le mode de la commande ipseckey.
# ipseckey > |
L'invite > indique que le mode de la commande ipseckey est activé.
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é.
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.
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.
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.
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 > |
Le système homologue doit utiliser le même numéro et le même SPI.
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 > |
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.
Pour quitter le mode de la commande ipseckey, appuyez sur Ctrl-D ou tapez quit.
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.
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 |
Protégez le fichier à l'aide de permissions de lecture seule.
# chmod 400 /etc/inet/secret/ipseckeys |
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 |
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.
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 |
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.
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.
Sur un système, par exemple partym, connectez-vous en tant que superutilisateur.
% su - Password: Type root password # |
À 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) |
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 |
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 ----- ... |
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.
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.
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).
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.
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 .
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.
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 |
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 |
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 |
Si vous modifiez le tableau des protocoles IPsec et des algorithmes, actualisez le service ipsecalgs.
# svcadm refresh svc:/network/ipsec/ipsecalgs |
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.
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) .
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 |
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} |
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} |
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} |
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} |
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é.
Tâche |
Description |
Voir |
---|---|---|
Protection du trafic de tunnel en mode Tunnel sur IPv4 |
Protège le trafic en mode Tunnel entre deux systèmes Solaris10, deux systèmes Oracle Solaris ou entre un système Solaris10 et un système Oracle Solaris Express. Le système Solaris10 doit exécuter au moins la version Solaris 10 7/07. Protège également le trafic en mode Tunnel entre un système Solaris10 ou un système Oracle Solaris Express et un système exécuté sur une autre plate-forme. Le système Solaris10 doit exécuter au moins la version Solaris 10 7/07. |
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 |
Protection du trafic de tunnel en mode Tunnel sur IPv6 |
Protège le trafic en mode Tunnel entre deux systèmes Oracle Solaris utilisant le protocole IPv6. |
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv6 |
Protection du trafic de tunnel en mode Transport sur IPv4 |
Protège le trafic en mode Transport entre deux systèmes Solaris10, deux systèmes Solaris ou entre un système Solaris10 et un système Oracle Solaris. Le système Solaris10 doit exécuter au moins la version Solaris 10 7/07. Protège également le trafic en mode Transport entre un système exécutant une version antérieure de SE Solaris et un système Solaris10 ou Oracle Solaris. Le système Solaris10 doit exécuter au moins la version Solaris 10 7/07. |
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv4 |
Protège le trafic à l'aide d'une syntaxe plus ancienne et désapprouvée Cette méthode s'avère particulièrement utile pour communiquer avec un système exécutant une version antérieure du SE Solaris. Elle simplifie la comparaison des fichiers de configuration sur les deux systèmes. | ||
Protection du trafic de tunnel en mode Transport sur IPv6 |
Protège le trafic en mode Tunnel entre deux systèmes Oracle Solaris utilisant le protocole IPv6. |
Protection d'un VPN à l'aide d'un tunnel IPsec en mode Transport sur IPv6 |
Protection contre l'usurpation d'adresse IP |
Crée un service SMF afin d'empêcher le système de transmettre des paquets sur un réseau VPN sans que ceux-ci soient déchiffrés. |
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).
Comme l'illustration précédente l'indique, les procédures pour le réseau IPv4 utilisent les paramètres de configuration suivants :
Paramètre |
Europe |
Californie |
||
---|---|---|---|---|
Nom du système |
|
|
||
Interface intranet du système |
|
|
||
Adresse intranet du réseau, dite également adresse -point dans l'Étape 7 |
|
|
||
Interface Internet du système |
|
|
||
Adresse Internet du système, dite également adresse tsrc dans l'Étape 7 |
|
|
||
Nom du routeur Internet |
|
|
||
Adresse du routeur Internet |
|
|
||
Nom du tunnel |
|
|
Les adresses IPv6 sont utilisées dans les procédures. Les noms de tunnel sont identiques.
Paramètre |
Europe |
Californie |
||
---|---|---|---|---|
Adresse intranet du système |
|
|
||
Adresse Internet du système |
|
|
||
Adresse du routeur Internet |
|
|
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.
Vous devez vous trouver dans la zone globale pour configurer la stratégie IPsec pour le système ou pour une zone IP partagée. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
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.
Contrôlez le flux de paquets avant de configurer IPsec.
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).
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.
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.
Désactivez la plupart des services réseau, voire tous les services réseau.
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 |
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 |
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.
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.
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} |
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} |
(Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# svcadm refresh svc:/network/ipsec/policy:default |
Pour lire les informations du fichier de configuration du tunnel, redémarrez les services réseau.
# svcadm restart svc:/network/initial:default |
Activez le transfert IP pour l'interface hme1.
Sur le système enigma, ajoutez l'entrée de routeur au fichier /etc/hostname.hme1.
192.168.116.16 router |
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.
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname.hme0.
10.16.16.6 private |
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.
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.
Sur le système enigma, ajoutez la route suivante :
# route add default 192.168.116.4 |
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).
Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.
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 |
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# ipsecconf |
Affichez le routeur pour le tunnel.
# ifconfig ip.tun0 router up |
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.
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.
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.
Sur le système enigma, ajoutez la route suivante :
# route add default 192.168.116.4 |
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).
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 |
Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.
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 |
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 |
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.
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.
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.
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} |
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} |
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} |
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.
Paramètre |
Europe |
Californie |
||
---|---|---|---|---|
Nom du système |
|
|
||
Interface intranet du système |
|
|
||
Interface Internet du système |
|
|
||
Adresse intranet du système |
|
|
||
Adresse Internet du système |
|
|
||
Nom du routeur Internet |
|
|
||
Adresse du routeur Internet |
|
|
||
Nom du tunnel |
|
|
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.
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.
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.
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 |
Activez le multiréseau de destination strict IP.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1 |
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.
Désactivez la plupart des services réseau, voire tous les services réseau.
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 |
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 |
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.
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.
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} |
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} |
(Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :
Configurez le tunnel ip6.tun0 dans le fichier /etc/hostname.ip6.tun0.
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# svcadm refresh svc:/network/ipsec/policy:default |
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 |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
Ajoutez manuellement une route par défaut à travers hme0.
Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.
Configurez un tunnel sécurisé ip6.tun0.
Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# ipsecconf |
Affichez le routeur pour le tunnel.
# ifconfig ip6.tun0 router up |
Sur chaque système, exécutez le transfert IP pour l'interface hme1.
# ifconfig hme1 router |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
# ifconfig hme0 private |
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.
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.
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 |
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 |
Sur chaque système, configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.
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 |
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 |
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.
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.
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.
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.
Contrôlez le flux de paquets avant de configurer IPsec.
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 |
Activez le multiréseau de destination strict IP.
# ndd -set /dev/ip ip_strict_dst_multihoming 1 |
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.
Désactivez la plupart des services réseau, voire tous les services réseau.
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 |
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 |
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.
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.
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} |
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} |
(Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :
Configurez le tunnel ip.tun0 dans le fichier /etc/hostname.ip.tun0.
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# svcadm refresh svc:/network/ipsec/policy:default |
Pour lire les informations du fichier hostname.ip.tun0 dans le noyau, redémarrez les services réseau.
# svcadm restart svc:/network/initial:default |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
Ajoutez manuellement une route par défaut sur hme0.
Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.
Configurez le tunnel ip.tun0.
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 |
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# ipsecconf |
Affichez le routeur pour le tunnel.
# ifconfig ip.tun0 router up |
Activez le transfert IP pour l'interface hme1.
# ifconfig hme1 router |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
# ifconfig hme0 private |
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 |
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 |
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 |
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 |
Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.
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 |
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 |
Exécutez un protocole de routage.
# routeadm -e ipv4-routing # routeadm -u |
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} |
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 |
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.
Paramètre |
Europe |
Californie |
||
---|---|---|---|---|
Nom du système |
|
|
||
Interface intranet du système |
|
|
||
Interface Internet du système |
|
|
||
Adresse intranet du système |
|
|
||
Adresse Internet du système |
|
|
||
Nom du routeur Internet |
|
|
||
Adresse du routeur Internet |
|
|
||
Nom du tunnel |
|
|
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.
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.
Contrôlez le flux de paquets avant de configurer IPsec.
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 |
Activez le multiréseau de destination strict IP.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1 |
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.
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 |
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.
Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN.
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} |
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} |
(Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :
Configurez le tunnel ip6.tun0 dans le fichier /etc/hostname.ip6.tun0.
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# svcadm refresh svc:/network/ipsec/policy:default |
Pour lire le contenu du fichier hostname.ip6.tun0 dans le noyau, redémarrez les services réseau.
# svcadm restart svc:/network/initial:default |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
Ajoutez manuellement une route par défaut à travers hme0.
Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.
Configurez un tunnel sécurisé ip6.tun0.
Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.
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 |
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 |
Protégez le tunnel à l'aide de la stratégie IPsec créée.
# ipsecconf |
Affichez le routeur pour le tunnel.
# ifconfig ip6.tun0 router up |
Activez le transfert IP pour l'interface hme1.
# ifconfig hme1 router |
Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.
# ifconfig hme0 private |
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.
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.
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 |
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 |
Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.
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 |
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 |
Exécutez un protocole de routage.
# routeadm -e ipv6-routing # routeadm -u |
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 |
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.
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.
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>
Importez ce manifeste dans le référentiel SMF.
# svccfg import /var/svc/manifest/site/spoof_check.xml |
Activez le service ip_spoofcheck.
Utilisez le nom qui est défini dans le fichier manifeste, /site/ip_spoofcheck.
# svcadm enable /site/ip_spoofcheck |
Assurez-vous que le service ip_spoofcheck est en ligne.
# svcs /site/ip_spoofcheck |
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).
L'utilitaire de gestion des services (SMF) fournit les services suivants pour IPsec :
Le service svc:/network/ipsec/policy permet de gérer 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 est /etc/inet/ipsecinit.conf.
Le service svc:/network/ipsec/ipsecalgs permet de gérer les algorithmes disponibles pour IPsec. Par défaut, ce service est activé.
Le service svc:/network/ipsec/manual-key permet d'activer 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.
Le service svc:/network/ipsec/ike permet de gérer IKE. Par défaut, ce service est désactivé. Pour les propriétés configurables, reportez-vous à la section Utilitaire de gestion du service IKE.
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).
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 plus d'informations sur la protection des paquets transférés, reportez-vous aux pages de manuel ifconfig(1M) et tun(7M).
Pour consulter les options de stratégie IPsec, reportez-vous à la page de manuel ipsecconf(1M).
Pour obtenir les instructions relatives à la protection du trafic entre systèmes à l'aide de la commande ipsecconf, reportez-vous à la section Configuration du protocole IKE (liste des tâches).
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).
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.
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. |
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.
Votre adresse source est un hôte que vous pouvez rechercher sur le réseau.
Votre système d'attribution de nom est compromis.
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.
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.
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).
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).
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 :
Avez-vous actualisé les informations relatives à la génération de clés ? L'actualisation périodique des clés est une pratique de sécurité essentielle. Elle permet de prémunir les éventuelles défaillances de l'algorithme et des clés, et de limiter les dommages subis par une clé exposée.
Le TTY est-il connecté à un réseau ? La commande ipseckey est-elle en mode interactif ?
En mode interactif, la sécurité des informations de génération de clés constitue celle du chemin d'accès au réseau pour le trafic du TTY. Évitez d'exécuter la commande ipseckey lors d'une session rlogin ou telnet en clair.
Même les fenêtres locales sont vulnérables aux attaques d'un programme caché qui intercepte les événements de fenêtre.
Avez-vous utilisé l'option -f ? Le fichier est-il en cours d'accès sur le réseau ? Le fichier est-il accessible en lecture par tout utilisateur ?
Un utilisateur malintentionné est en mesure de lire un fichier monté sur le réseau lorsque ce fichier est en cours de lecture. Le fichier contenant les informations de génération de clés ne doit pas être lisible par tous.
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.
Votre adresse source est un hôte que vous pouvez rechercher sur le réseau.
Votre système d'attribution de nom est compromis.
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.
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.
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} |
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.
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.
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.
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.
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é.
Le protocole IKE (Internet Key Exchange, échange de clé Internet) automatise la gestion des clés pour IPsec. Ce chapitre aborde les sujets suivants :
Pour plus d'informations sur l'implémentation du protocole IKE, reportez-vous au Chapitre 23Configuration du protocole IKE (tâches). Pour obtenir des informations de référence, reportez-vous au Chapitre 24Protocole IKE (référence). Pour plus d'informations sur les protocoles IPsec, reportez-vous au Chapitre 19Architecture IPsec (présentation).
Solaris 10 4/09 : À partir de cette version, l'utilitaire de gestion des services (SMF) gère IKE en tant que service. Par défaut, le service svc:/network/ipsec/ike:default est désactivé. Par ailleurs, dans cette version, le profil de droits Network IPsec Management permet d'administrer IPsec et IKE.
Solaris 10 7/07 : à partir de cette version, le protocole IKE peut utiliser l'algorithme AES et être configuré dans la zone globale en vue de son utilisation dans des zones non globales.
L'option de socket SO_ALLZONES permet au protocole IKE de gérer le trafic dans les zones non globales.
Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10.
La gestion des numéros de clé des associations de sécurité (Security Associations, SA) pour IPsec est appelée gestion des clés. La gestion automatique des clés requiert un canal de communication sécurisé pour la création, l'authentification et l'échange des clés. Le Système d'exploitation Solaris utilise IKE pour automatiser la gestion des clés. IKE s'intègre facilement dans les environnement à grande échelle et peut fournir un canal sécurisé pour un grand volume de trafic. Les associations de sécurité IPsec sur paquets IPv4 et IPv6 peuvent utiliser le protocole IKE.
Lorsque IKE est utilisé sur un système équipé d'une carte Sun Crypto Accelerator 1000, 6000 ou Sun Crypto Accelerator 4000, les opérations de clés publiques peuvent être déchargées sur l'accélérateur. Les opérations de clés publiques n'utilisent pas les ressources du système d'exploitation. Lorsque IKE est utilisé sur un système équipé d'une carte Sun Crypto Accelerator 4000 ou Sun Crypto Accelerator 6000, les certificats et les clés publiques et privées peuvent être stockés sur la carte. Le stockage des clés hors du système fournit une couche de protection supplémentaire.
Le démon IKE in.iked négocie et authentifie les numéros de clé des associations de sécurité (SA, security associations) de façon sécurisée. Il utilise des germes de sécurité aléatoires pour les clés des fonctions internes fournies par le Système d'exploitation Solaris. Le protocole IKE assure une confidentialité de transmission parfaite (PFS, perfect forward secrecy). En mode PFS, les clés qui protègent la transmission des données ne sont pas utilisées pour générer des clés complémentaires. Les germes de sécurité employés pour créer des clés de transmission de données ne sont pas réutilisés. Reportez-vous à la page de manuel in.iked(1M).
Lorsque le démon IKE découvre la clé de chiffrement d'un système public distant, le système local peut utiliser cette clé. Il l'emploie pour chiffrer les messages, qui ne peuvent alors être lus que par ce système distant. L'intervention du démon IKE se décompose en deux phases, dites d'échange.
Le tableau ci-dessous répertorie les termes utilisés dans la négociation des clés et les acronymes les plus couramment employés. Vous y trouverez également une définition de chacun de ces termes ainsi que leur contexte d'utilisation.
Tableau 22–1 Terminologie de négociation des clés, acronymes et utilisation
Terminologie de négociation des clés |
Acronymes |
Définition et utilisation |
---|---|---|
Échange de clés |
|
Processus de génération de clés pour les algorithmes cryptographiques asymétriques. Les principales méthodes utilisées sont les protocoles RSA et Diffie-Hellman. |
Protocole Diffie-Hellman |
DH |
Protocole d'échange de clés impliquant la génération et l'authentification de clés et souvent appelé échange de clés authentifiées. |
Protocole RSA |
RSA |
Protocole d'échange de clés impliquant la génération et le transport de clés. Ce protocole porte le nom de ses trois créateurs : Rivest, Shamir et Adleman. |
PFS (perfect forward secrecy) |
Ne s'applique qu'à l'échange de clés authentifiées. Le mode PFS garantit que l'éventuelle découverte de secrets à long terme ne compromet pas les clés des communications précédentes. Perfect Forward Secrecy, secret rigoureux des transmission .Avec la fonction PFS, la clé visant à protéger la transmission des données n'est pas utilisée pour dériver d'autres clés. Il en est de même pour la source de la clé. |
|
Méthode Oakley |
|
Méthode de création sécurisée de clés pour la phase 2. Ce protocole est similaire à l'échange de clés Diffie-Hellman et implique la génération et l'authentification de clés. La méthode Oakley s'emploie pour négocier des PFS. |
La phase 1 est connue sous le nom de Main Mode (mode principal). Pendant la phase 1, IKE utilise des méthodes de chiffrement de clé publique pour s'authentifier auprès d'entités IKE homologues. Il en résulte une association de sécurité (SA, security association) ISAKMP (Internet Security Association and Key Management Protocol). Une SA ISAKMP est un canal sécurisé sur lequel IKE négocie les numéros de clé des datagrammes IP. Contrairement aux SA IPsec, les SA ISAKMP sont bidirectionnelles. Il n'est donc pas nécessaire de disposer de plus d'une association de sécurité.
La façon dont IKE négocie les numéros de clé lors de la phase 1 peut être configurée. IKE lit les informations concernant la configuration dans le fichier /etc/inet/ike/config. Ces informations incluent :
des paramètres généraux tels que le nom des certificats de clés publiques ;
l'activation ou non du mode de confidentialité de transmission parfaite (PFS) ;
les interfaces concernées ;
les protocoles de sécurité et leurs algorithmes ;
la méthode d'authentification.
Les deux méthodes d'authentification utilisent respectivement les clés prépartagées et les certificats de clés publiques. Les certificats de clés publiques peuvent être autosignés ou émis par l'autorité de certification (AC) d'un fournisseur d'infrastructures de clés publiques (PKI). telles que beTrusted, Entrust, GeoTrust, RSA Security et Verisign.
La phase 2 est connue sous le nom de Quick Mode (mode rapide). Lors de la phase 2, IKE crée et gère les SA IPsec entre les systèmes qui exécutent le démon IKE. IKE utilise le canal sécurisé qui a été créé lors de la phase 1 pour protéger la transmission des numéros de clé. Le démon IKE crée les clés à partir d'un générateur de nombres aléatoires à l'aide du périphérique /dev/random. Le démon actualise les clés à une fréquence qui peut être configurée. Les numéros de clé sont accessibles aux algorithmes spécifiés dans le fichier de configuration ipsecinit.conf de la stratégie IPsec.
Le fichier de configuration /etc/inet/ike/config contient des entrées de stratégie IKE. Pour que deux démons IKE puissent s'authentifier mutuellement, les entrées doivent être valides et les numéros de clé doivent être disponibles. Les entrées des fichiers de configuration déterminent la façon dont les numéros de clé seront utilisés pour authentifier l'échange qui a lieu lors de la phase 1. Il y a deux possibilités : les clés prépartagées ou les certificats de clés publiques.
Si l'entrée est auth_method preshared, ce sont les clés prépartagées qui sont utilisées pour authentifier l'échange. Si auth_method possède une valeur autre que preshared, l'authentification s'effectue à l'aide de certificats de clés publiques. Ces certificats peuvent être autosignés ou installés par un fournisseur de PKI. Pour plus d'informations, reportez-vous à la page de manuel ike.config(4).
Les clés prépartagées sont créées par un administrateur sur un système. Elles sont ensuite partagées hors bande avec les administrateurs de systèmes distants. Prenez soin de créer de longues clés aléatoires et de protéger le fichier et la transmission hors bande. Les clés sont placées dans le fichier /etc/inet/secret/ike.preshared de chaque système. Le fichier ike.preshared est réservé à IKE et le fichier ipseckeys à IPsec. Toute compromission des clés du fichier ike.preshared compromet toutes les clés qui en sont dérivées.
Le système de clés prépartagées doit être identique au système distant de clés correspondant. Les clés sont liées à une adresse IP donnée. Elles sont plus sécurisées lorsqu'un administrateur contrôle les systèmes communicants. Pour plus d'informations, reportez-vous à la page de manuel ike.preshared(4).
Grâce aux certificats de clés publiques, les systèmes communicants n'ont plus besoin de partager de numéros de clé secrets hors bande. Les clés publiques utilisent le protocole Diffie-Hellman (DH) pour authentifier et négocier les clés. Les certificats de clés publiques peuvent être soit autosignés, soit certifiés par une autorité de certification (AC).
Les certificats de clés publiques autosignés sont créés par l'administrateur. La commande ikecert certlocal -ks permet de créer la partie privée des biclés du système. Le certificat autosigné est ensuite émis, au format X.509, par le système distant. Le certificat du système distant est entré à l'aide de la commande ikecert certdb pour la partie publique de la clé. Les certificats autosignés résident dans le répertoire /etc/inet/ike/publickeys des systèmes communicants. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté.
Les certificats autosignés sont à mi-chemin entre les clés prépartagées et les AC. Contrairement aux clés prépartagées, les certificats autosignés peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Pour autosigner un certificat pour un système n'ayant pas de numéro fixe, utilisez un nom alternatif de DNS (www.example.org ) ou d'email (root@domain.org).
Les clés publiques peuvent être délivrées par un fournisseur de PKI ou une AC. Elles doivent être installées, avec les certificats AC qui les accompagnent, dans le répertoire /etc/inet/ike/publickeys. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté. Les fournisseurs émettent également des listes de révocation de certificats (LRC). Outre les clés et les certificats AC, vous devez également installer les LRC dans le répertoire /etc/inet/ike/crls.
Les certificats AC présentent l'avantage d'être certifiés par une organisation externe, et non par l'administrateur du site. Il s'agit en quelque sorte de certificats "certifiés". Comme les certificats autosignés, les certificats AC peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Contrairement aux certificats autosignés, ils s'intègrent facilement aux environnement à grande échelle afin de protéger un grand nombre de systèmes communicants.
Les algorithmes IKE recoupent de nombreux calculs, notamment lors de la phase 1. Les systèmes qui traitent un grand nombre d'échanges peuvent utiliser une carte Sun Crypto Accelerator 1000 pour traiter les opérations de clés publiques. Les cartes Sun Crypto Accelerator 6000 et Sun Crypto Accelerator 4000 peuvent également être utilisées pour gérer les calculs onéreux relatifs à la phase 1.
Pour plus d'informations sur la manière dont le protocole IKE doit être configuré pour décharger les calculs sur la carte d'accélération, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000 . Pour plus d'informations sur le stockage des clés, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000 et à la page de manuel cryptoadm(1M).
Les certificats de clés publiques, ainsi que les clés privées et publiques peuvent être stockés sur une carte Sun Crypto Accelerator 6000 ou &sca 4;. En chiffrement RSA, la longueur maximale des clés prise en charge par la carte Sun Crypto Accelerator 4000 est de 2 048 bits. En chiffrement DSA, elle est de 1 024 bits. La carte Sun Crypto Accelerator 6000 prend en charge les algorithmes SHA-512 et ECC.
Pour plus d'informations sur la manière dont le protocole IKE doit être configuré pour accéder à la carte, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000 . Pour plus d'informations sur l'ajout de certificats et de clés publiques à la carte, reportez-vous à la section Génération et stockage de certificats de clés publiques sur le matériel.
Vous trouverez, dans le tableau ci-dessous, une liste des fichiers de configuration de la stratégie IKE, les emplacements de stockage des clés IKE et les différentes commandes et divers services permettant d'implémenter IKE. Pour plus d'informations sur ces services, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.
Tableau 22–2 Fichiers de configuration IKE, emplacements de stockage des clés, commandes et services
À partir de Solaris 9, IKE inclut les fonctionnalités suivantes :
IKE peut être utilisé pour automatiser l'échange de clés pour IPsec via des réseaux IPv6. Pour plus d'informations, reportez-vous à la section Gestion des clés avec IKE.
IKE ne peut pas être utilisé pour gérer des clés IPsec dans une zone non globale.
Les opérations IKE relatives aux clés publiques peuvent être accélérées grâce à l'ajout d'une carte Sun Crypto Accelerator 1000 ou Sun Crypto Accelerator 4000 sur laquelle elles sont déchargées. Le déchargement accélère le chiffrement et réduit ainsi l'utilisation des ressources de système d'exploitation. Pour plus d'informations, reportez-vous à la section Protocole IKE et accélération matérielle. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches).
Les certificats de clés publiques, les clés privées et les clés publiques peuvent être stockés sur une carte Sun Crypto Accelerator 4000. Pour plus d'informations sur le stockage des clés, reportez-vous à la section Protocole IKE et stockage matériel.
IKE peut être utilisé pour automatiser l'échange de clés pour IPsec depuis un système situé derrière un boîtier NAT. Le trafic doit emprunter un réseau IPv4 et les clés IPsec de l'ESP traversant le NAT ne peuvent pas être accélérées à l'aide d'un composant matériel. Pour plus d'informations, reportez-vous à la section Passage de la translation d'adresses et IPsec. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des tâches).
Des paramètres de retransmission et de délai d'expiration des paquets ont été ajoutés au fichier /etc/inet/ike/config. Ces paramètres ajustent la négociation de la phase 1 d'IKE (Main Mode) afin de traiter les interférences réseau, les augmentations de trafic et l'interopération avec des plates-formes possédant des implémentations du protocole IKE différentes. Pour plus d'informations sur ces paramètres, reportez-vous à la page de manuel ike.config(4) Pour plus d'informations sur les procédures, reportez-vous à la section Modification des paramètres de transmission du protocole IKE (liste des tâches).
Ce chapitre décrit la procédure de configuration du protocole Internet Key Exchange (IKE) sur vos systèmes. Une fois configuré, ce protocole génère automatiquement les numéros de clé IPsec sur votre réseau. Le présent chapitre contient les informations suivantes :
Configuration du protocole IKE avec des clés prépartagées (liste des tâches)
Configuration du protocole IKE avec des certificats de clés publiques (liste des tâches)
Configuration du protocole IKE pour les systèmes portables (liste des tâches)
Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches)
Modification des paramètres de transmission du protocole IKE (liste des tâches)
Pour voir une présentation du protocole IKE, reportez-vous au Chapitre 22Protocole IKE (présentation). Pour obtenir des informations de référence sur le protocole IKE, reportez-vous au Chapitre 24Protocole IKE (référence). Pour consulter d'autres procédures, reportez-vous aux sections Exemples des pages de manuel ikeadm(1M), ikecert(1M) et ike.config(4).
L'authentification du protocole IKE peut s'effectuer à l'aide de clés prépartagées ou de certificats autosignés ou émanant d'autorités de certifications (AC). Les méthodes d'authentification IKE sont liées par une règle aux points d'extrémité protégés. Vous pouvez donc utiliser toutes les méthodes d'authentification IKE ou une seule d'entre elles sur un système. Un pointeur menant à une bibliothèque PKCS #11 permet aux certificats d'utiliser un accélérateur matériel connecté.
Une fois le protocole IKE configuré, vous devez effectuer les tâches IPsec qui utilisent cette configuration. Le tableau ci-dessous répertorie les tâches correspondant aux différentes configurations IKE.
Tâche |
Description |
Voir |
---|---|---|
Configuration du protocole IKE avec des clés prépartagées |
Protégez les communications entre deux systèmes en faisant en sorte qu'ils partagent une clé secrète. |
Configuration du protocole IKE avec des clés prépartagées (liste des tâches) |
Configuration du protocole IKE avec des certificats de clés publiques |
Protégez les communications à l'aide de certificats de clés publiques. Ces certificats peuvent être autosignés ou attestés par un fournisseur de PKI. |
Configuration du protocole IKE avec des certificats de clés publiques (liste des tâches) |
Franchissement d'un boîtier NAT |
Configurez les protocoles IPsec et IKE pour communiquer avec un système portable |
Configuration du protocole IKE pour les systèmes portables (liste des tâches) |
Configuration du protocole IKE pour générer et stocker les certificats de clés publiques sur le matériel connecté |
Accélérez les opérations IKE à l'aide d'une carte Sun Crypto Accelerator 1000 ou Sun Crypto Accelerator 4000. Vous pouvez également stocker les certificats de clés publiques sur la carte Sun Crypto Accelerator 4000. |
Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches) |
Ajustement des paramètres de négociation de la phase 1 |
Modifiez la durée des négociations de clés IKE. |
Modification des paramètres de transmission du protocole IKE (liste des tâches) |
Le tableau ci-dessous répertorie les procédures de configuration et de maintenance du protocole IKE avec des clés prépartagées.
Tâche |
Description |
Voir |
---|---|---|
Configuration du protocole IKE avec des clés prépartagées |
Créez un fichier de stratégie IKE ainsi qu'une clé à partager. | |
Actualisation des clés prépartagées sur un système IKE en cours d'exécution |
Ajoutez des numéros de clé IKE sur les systèmes communicants. | |
Ajout de clés prépartagées à un système IKE en cours d'exécution |
Ajoutez une nouvelle entrée de stratégie IKE et de nouveaux numéros de clé à un système appliquant actuellement la stratégie IKE. |
Ajout d'une clé IKE prépartagée pour une nouvelle entrée de stratégie dans ipsecinit.conf |
Vérification de la concordance des clés prépartagées |
Affichez les clés prépartagées sur les deux systèmes pour vous assurer qu'elles sont identiques. |
Méthode de vérification de la concordance des clés prépartagées IKE |
Les clés prépartagées sont la méthode d'authentification la plus simple pour IKE. Elles s'utilisent notamment lors de la configuration du protocole IKE sur deux systèmes gérés par le même administrateur. N'oubliez cependant pas que, contrairement aux certificats de clés publiques, les clés prépartagées sont liées à une adresse IP donnée et ne peuvent pas s'utiliser avec des systèmes portables ou des systèmes susceptibles d'être renumérotés. Tenez également compte du fait que, si vous utilisez des clés prépartagées, vous ne pourrez pas décharger de calculs IKE sur le matériel connecté.
La longueur des clés des algorithmes d'implémentation du protocole IKE est variable. Elle dépend du niveau de sécurité dont vous souhaitez doter le site. En règle générale, la longueur des clés est proportionnelle au niveau de sécurité.
Les noms de systèmes choisis pour illustrer cette procédure sont : enigma et partym. Remplacez enigma et partym par les noms de vos systèmes.
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.
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.
Copiez le fichier /etc/inet/ike/config.sample dans le fichier /etc/inet/ike/config sur chacun des systèmes.
Entrez les règles et paramètres globaux dans le fichier ike/config sur chacun des systèmes.
Les règles et paramètres globaux de ce fichier doivent garantir le fonctionnement de la stratégie IPsec du fichier ipsecinit.conf. Les exemples ike/config ci-dessous vont de pair avec les exemples ipsecinit.conf de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec.
Modifiez par exemple le fichier /etc/inet/ike/config sur le système enigma :
### ike/config file on enigma, 192.168.116.16 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 } |
Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.
Modifiez le fichier /etc/inet/ike/config sur le système partym :
### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 } |
Vérifiez la syntaxe du fichier sur chacun des systèmes.
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config |
Générez des nombres aléatoires que vous utiliserez comme numéros de clé.
Si votre site possède un générateur de nombres aléatoires, utilisez-le. Sur un système Solaris, vous pouvez utiliser la commande od. La commande suivante vous permet par exemple d'imprimer deux lignes de nombres hexadécimaux :
% od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d |
Pour plus de détails sur la commande od, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris et à la page de manuel od(1).
D'autres systèmes d'exploitation peuvent nécessiter des numéros de clé au format ASCII. Pour générer une clé identique dans les deux formats, hexadécimal et ASCII, reportez-vous à l'Exemple 23–1.
Créez une clé à partir du résultat de l'Étape 5.
f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e |
Pour cette procédure, l'algorithme d'authentification est SHA–1, comme indiqué à l'Étape 3. La taille du hachage, c'est-à-dire la taille de la sortie de l'algorithme d'authentification, détermine la taille minimale recommandée pour une clé prépartagée. La taille de la sortie de l'algorithme SHA–1 est de 160 bits ou 40 caractères. Dans cet exemple, la clé possède 56 caractères, ce qui permet au protocole IKE de disposer de numéros de clé supplémentaires.
Créez un fichier /etc/inet/secret/ike.preshare sur chacun des systèmes.
Placez la clé prépartagée dans chacun des fichiers.
Sur le système enigma par exemple, le fichier ike.preshared se présente comme suit :
# ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e } |
Sur le système partym, le fichier ike.preshared se présente comme suit :
# ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e } |
Les clés prépartagées doivent être identiques sur chacun des systèmes.
Le protocole IPsec de Solaris fonctionne avec d'autres systèmes d'exploitation. Si votre système communique avec un système qui requiert des clés prépartagées ASCII, vous devez générer une clé dans les deux formats, hexadécimal et ASCII.
Dans cet exemple, l'administrateur système de Solaris veut générer une clé de 56 caractères. Il utilise la commande ci-dessous pour générer une clé hexadécimale à partir d'une phrase de passe ASCII. L'option -tx1 imprime les octets un par un sur tous les systèmes Solaris.
# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \ tr -d '\n' | tr -d ' ' | awk '{print}' 7061706965726d616368652077697468206361736865777320616e64 |
Après suppression des décalages et concaténation de la sortie hexadécimale, la clé hexadécimale pour le système Solaris est 7061706965726d616368652077697468206361736865777320616e64. L'administrateur place cette valeur dans le fichier ike.preshared sur le système Solaris.
# Shared key in hex (192 bits) key 7061706965726d616368652077697468206361736865777320616e64 |
Sur le système qui requiert des clés prépartagées ASCII, la phrase de passe correspond à la clé prépartagée. L'administrateur Solaris communique la phrase de passe papiermache with cashews and à l'autre administrateur par téléphone.
Cette procédure permet de remplacer une clé prépartagée existante à intervalles réguliers.
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.
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.
Générez des nombres aléatoires et créez une clé possédant une longueur appropriée.
Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.
Remplacez la clé actuelle par une nouvelle clé.
À titre d'exemple, sur les hôtes enigma et partym, cela revient à remplacer la valeur de key stockée dans le fichier /etc/inet/secret/ike.preshared par un nouveau nombre possédant la même longueur.
Lisez la nouvelle clé dans le noyau.
À partir de la version Solaris 10 4/09 actualisez le service ike.
# svcadm refresh ike |
Si vous exécutez une version antérieure à la version Solaris 10 4/09, arrêtez et redémarrez le démon in.iked.
Vérifiez le niveau de privilège du démon in.iked.
# /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled |
Vous pouvez modifier les numéros de clé si la commande renvoie un niveau de privilège 0x1 ou 0x2. Si le niveau renvoyé est 0x0, vous ne pouvez ni modifier ni afficher les numéros de clé. Par défaut, le démon in.iked s'exécute au niveau de privilège 0x0.
Si le niveau de privilège est 0x0, arrêtez le démon et redémarrez-le.
Lorsque le démon redémarre, il lit la nouvelle version du fichier ike.preshared.
# pkill in.iked # /usr/lib/inet/in.iked |
Si le niveau de privilège est 0x1 ou 0x2, lisez la nouvelle version du fichier ike.preshared.
# ikeadm read preshared |
Par défaut, la commande ikeadm vous empêche de consulter les clés réelles dans le fichier de vidage d'une SA phase 1. L'affichage des clés est utile lors du débogage.
Pour afficher les clés réelles, vous devez augmenter le niveau de privilège du démon. Pour obtenir une description des niveaux de privilège, reportez-vous à la section Commande d'administration du protocole IKE .
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.
IKE est configuré et le service ike est en cours d'exécution.
Affichez les clés IKE prépartagées.
# ikeadm ikeadm> dump preshared |
Si une erreur se produit, vous devez augmenter le niveau de privilège du démon in.iked.
Augmentez le niveau de privilège du démon in.iked dans le référentiel SMF.
# svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat |
Augmentez le niveau de privilège du démon in.iked en cours d'exécution.
# svcadm refresh ike ; svcadm restart ike |
(Facultatif) Confirmez que le niveau de privilège est keymat.
# svcprop -p config/admin_privilege ike keymat |
Affichez les clés en exécutant de nouveau l'Étape 1.
Réappliquez le niveau de privilège de base au démon IKE.
Dans l'exemple suivant, l'administrateur affiche les clés sur un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur souhaite vérifier que les clés de ce système sont identiques aux clés du système communicant. Après avoir vérifié que les clés sont identiques sur les deux systèmes, l'administrateur rétablit le niveau de privilège sur 0.
Tout d'abord, l'administrateur détermine le niveau de privilège du démon in.iked.
adm1 # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled |
Le niveau de privilège n'étant pas 0x1 ni 0x2, l'administrateur arrête le démon in.iked, puis augmente le niveau de privilège sur 2.
adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
L'administrateur affiche les clés.
adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1). |
L'administrateur se connecte à distance au système communicant et détermine si les clés sont identiques.
L'administrateur rétablit ensuite le niveau de privilège de base.
# ikeadm set priv base |
Si vous ajoutez des entrées de stratégie IPsec pendant que IPsec and IKE sont en cours d'exécution, vous devez lire la nouvelle stratégie et les règles IKE dans le noyau. À partir de la version Solaris 10 4/09, redémarrez le service policy et actualisez le service ike une fois les nouvelles clés ajoutées.
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–3.
L'exécution de cette procédure nécessite le respect des conditions suivantes :
Le système enigma est paramétré selon la procédure décrite à la section Configuration du protocole IKE avec des clés prépartagées.
Le système enigma protégera son trafic avec un nouveau système, ada.
Le démon in.iked est exécuté sur les deux systèmes.
Les interfaces des systèmes figurent en tant qu'entrées dans le fichier /etc/hosts sur les deux systèmes. Ci-dessous un exemple d'entrée :
192.168.15.7 ada 192.168.116.16 enigma |
Cette procédure fonctionne également avec une adresse IPv6 du fichier /etc/inet/ipnodes. À partir de la version Solaris 10 6/07, les entrées IPv6 sont placées dans le fichier /etc/hosts.
Vous avez ajouté une nouvelle entrée de stratégie au fichier /etc/inet/ipsecinit.conf sur les deux systèmes. Ces entrées se présentent de la manière suivante :
# ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared} |
# ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared} |
Dans la version actuelle, vous avez vérifié la syntaxe du fichier /etc/inet/ipsecinit.conf sur les deux systèmes à l'aide de :
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
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.
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.
Sur ce système, générez des nombres aléatoires et construisez une clé de 64 ou 448 bits.
Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.
Transmettez la clé à l'administrateur du système distant.
Vous devez tous deux ajouter simultanément la même clé prépartagée. La sécurité de cette clé est directement liée à celle du moyen de transmission. Utilisez donc de préférence un moyen hors bande de type courrier recommandé ou fax protégé. Vous pouvez également utiliser une session ssh pour administrer les deux systèmes.
Créez une règle pour la gestion des clés de enigma et ada par IKE.
Sur le système enigma, ajoutez la règle suivante au fichier /etc/inet/ike/config :
### ike/config file on enigma, 192.168.116.16 ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 } |
Sur le système ada, ajoutez la règle suivante :
### ike/config file on ada, 192.168.15.7 ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 } |
Assurez-vous que les clés IKE prépartagées sont disponibles lors de la réinitialisation.
Sur le système enigma, ajoutez les informations suivantes au fichier /etc/inet/secret/ike.preshared :
# ike.preshared on enigma for the ada interface # { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } |
Sur le système ada, ajoutez les informations suivantes au fichier ike.preshared :
# ike.preshared on ada for the enigma interface # { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d } |
Sur chaque système, redémarrez le service de stratégie IPsec afin de sécuriser l'interface ajoutée.
# svcadm restart policy |
Sur chaque système, actualisez le service ike.
# svcadm refresh ike |
Assurez-vous que les systèmes peuvent communiquer entre eux.
Reportez-vous à la section Méthode de vérification de la concordance des clés prépartagées IKE.
Dans l'exemple suivant, l'administrateur ajoute une clé prépartagée à un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur suit la procédure précédente pour modifier les fichiers ike/config et ike.preshared et pour générer des clés et contacter le système distant. L'administrateur utilise différentes commandes pour lire la nouvelle stratégie IPsec et les nouvelles règles IKE dans le noyau.
Avant de générer une nouvelle clé, l'administrateur définit le niveau de privilège du démon in.iked sur 2.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
Après l'envoi de la clé à l'autre système et l'ajout d'une nouvelle clé au système, l'administrateur réduit le niveau de privilège.
# ikeadm set priv base |
Ensuite, l'administrateur lit la nouvelle stratégie IPsec dans le noyau.
# ipsecconf -a /etc/inet/ipsecinit.conf |
Enfin, l'administrateur lit les nouvelles règles IKE dans le noyau.
# ikeadm read rules |
La concordance clés prépartagées des systèmes communicants est nécessaire à l'authentification.
IPsec est configuré et a été activé entre les deux systèmes sur lesquels vous travaillez. Vous exécutez la version actuelle Solaris10.
Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.
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.
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.
Sur chaque système, vérifiez le niveau de privilège du démon in.iked.
# svcprop -p config/admin_privilege ike base |
Si le niveau de privilège est keymat, passez à l'Étape 3.
Si le niveau de privilège est base ou modkeys, augmentez le niveau de privilège.
Effectuez une actualisation, puis redémarrez le service ike.
# svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat |
Affichez, sur chacun des systèmes, les informations concernant les clés prépartagées.
# ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym). |
Comparez les résultats obtenus.
Si les clés prépartagées ne sont pas identiques, remplacez l'une d'entre elles dans le fichier /etc/inet/secret/ike.preshared.
Lorsque la vérification est terminée, rétablissez le niveau de privilège par défaut sur chacun des systèmes.
# svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike |
Le tableau ci-dessous répertorie les procédures de création de certificats de clés publiques pour IKE. Ces procédures incluent l'accélération et le stockage de certificats sur le matériel connecté.
Tâche |
Description |
Voir |
---|---|---|
Configuration du protocole IKE avec des certificats de clés publiques autosignés |
Créez et placez deux certificats sur chaque système :
|
Configuration du protocole IKE avec des certificats de clés publiques autosignés |
Configuration du protocole IKE avec un certificat PKI émanant d'une autorité de certification |
Créez une demande de certificat et placez trois certificats sur chacun des systèmes :
|
Configuration du protocole IKE avec des certificats signés par une AC |
Configuration de certificats de clés publiques sur le matériel local |
Procédez de l'une des manières suivantes :
|
Génération et stockage de certificats de clés publiques sur le matériel |
Mise à jour de la liste de révocation de certificats (LRC) d'une PKI |
Accédez à la LRC depuis un point de distribution central. |
Grâce aux certificats de clés publiques, les systèmes communicants n'ont plus besoin de partager de numéros de clé secrets hors bande. Contrairement aux clés prépartagées, les certificats de clés publiques peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté.
Les certificats de clés publiques peuvent également être stockés sur le matériel connecté. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches).
Les certificats autosignés nécessitent un temps système inférieur à celui des certificats publics émanant d'une AC, mais s'intègrent plus difficilement dans un environnement à grande échelle.
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.
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.
Ajoutez un certificat autosigné à la base de données ike.privatekeys.
# ikecert certlocal -ks|-kc -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID] |
Crée un certificat autosigné.
Crée une demande de certificat. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE avec des certificats signés par une AC.
Taille de la clé. La taille de clé peut être 512, 1 024, 2 048, 3 072 ou 4 096.
Spécifie le type d'algorithme à utiliser. Le type de clé peut être rsa-sha1, rsa-md5 ou dsa-sha1.
Nom distinctif X.509 de l'objet du certificat. Le nom distinctif se présente de la manière suivante : C=pays, O=organisation, OU=unité d'organisation, CN=nom commun. Les balises valides sont C, O, OU et CN.
Nom alternatif du certificat. Le nom alternatif se présente de la manière suivante : tag=value. Les balises valides sont IP, DNS, email et DN.
Indique la date de début de validité absolue ou relative du certificat.
Indique la date de fin de validité absolue ou relative du certificat.
Permet à un jeton matériel PKCS #11 de générer les clés. Les certificats sont alors stockés sur le matériel.
Exécutée par exemple sur le système partym, la commande se présente comme suit :
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ -A IP=192.168.13.213 Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/0. Enabling external key providers - done. Acquiring private keys for signing - done. Certificate: Proceeding with the signing operation. Certificate generated successfully (…/publickeys/0) Finished successfully. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE----- |
Exécutée sur le système enigma, elle se présente de la manière suivante :
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \ -A IP=192.168.116.16 Creating software private keys. … Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE----- |
Enregistrez le certificat et envoyez-le au système distant.
Vous pouvez le coller dans un e-mail.
Transmettez le certificat de partym à l'administrateur de enigma :
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE----- |
L'administrateur de enigma vous envoie le certificat enigma suivant :
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE----- |
Sur chaque système, ajoutez le certificat que vous avez reçu.
Copiez la clé publique que l'administrateur vous a envoyée par e-mail.
Saisissez la commande ikecert certdb -a et appuyez sur la touche Retour.
Aucune invite ne s'affiche lorsque vous appuyez sur la touche Retour.
# ikecert certdb -a Press the Return key |
Collez la clé publique, puis appuyez sur la touche Retour. Pour clore l'entrée, appuyez sur Ctrl-D.
-----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D |
Vérifiez auprès de l'autre administrateur que ce certificat est bien de lui.
Vous pouvez par exemple lui téléphoner et comparer la valeur de hachage de la clé publique. La valeur de hachage de clé publique du certificat partagé doit être identique pour les deux systèmes.
Répertoriez les certificats stockés sur votre système.
Par exemple, sur le système partym, le certificat public se trouve à l'emplacement 1 et le certificat privé à l'emplacement 0.
partym # ikecert certdb -l Certificate Slot Name: 0 Type: rsa-md5 Private Key Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2 Certificate Slot Name: 1 Type: rsa-md5 Public Certificate (Private key in certlocal slot 0) Points to certificate's private key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818 |
Comparez cette valeur avec le hachage de la clé publique sur le système enigma.
Vous pouvez communiquer la valeur de hachage par téléphone.
enigma # ikecert certdb -l Certificate Slot Name: 4 Type: rsa-md5 Private Key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0 Certificate Slot Name: 5 Type: rsa-md5 Public Certificate (Private key in certlocal slot 4) Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818 |
Approuvez les deux certificats sur chacun des systèmes.
Éditez le fichier /etc/inet/ike/config pour reconnaître les certificats.
L'administrateur du système distant fournit la valeur des paramètres cert_trust, remote_addr et remote_id.
Sur le système partym par exemple, le fichier ike/config se présente de la manière suivante :
# Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert # Verified remote address and remote ID # Verified public key hash per telephone call from administrator cert_trust "192.168.13.213" Local system's certificate Subject Alt Name cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 5 { label "US-partym to JA-enigmax" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} } |
Sur le système enigma, ajoutez les valeurs de enigma des paramètres locaux dans le fichier ike/config.
Pour les paramètres distants, utilisez les valeurs de partym. Assurez-vous que la valeur du mot-clé label est unique. Elle doit différer de la valeur label du système distant.
… { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 … |
Dans cet exemple, les administrateurs vérifient la concordance des certificats à l'aide de l'attribut Subject Name.
Le premier administrateur enregistre la sortie de la génération et du listage du certificat dans un fichier. La sortie de la commande ikecert s'imprimant en erreur standard, l'administrateur redirige l'erreur standard vers le fichier.
sys1# cd / sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \ -D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys Certificate added to database. sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys |
L'administrateur vérifie le contenu du fichier.
sys1# cat /tmp/for_co2sys Creating private key. -----BEGIN X509 CERTIFICATE----- MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2 gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN 5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180 F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE Y/cJRsK1hWbYyseqcIkjj5k= -----END X509 CERTIFICATE----- Certificate Slot Name: 2 Key Type: rsa (Private key in certlocal slot 2) Subject Name: <C=US, O=TestCo, CN=Co2Sys> Key Size: 1024 Public key hash: C46DE77EF09084CE2B7D9C70479D77FF |
Ensuite, l'administrateur envoie le fichier par courrier électronique au deuxième administrateur.
Celui-ci place le fichier dans un répertoire sécurisé, puis importe le certificat à partir du fichier.
sys2# cd / sys2# ikecert certdb -a < /sec/co2sys |
La commande ikecert importe uniquement le texte entre les lignes -----BEGIN et -----END. L'administrateur vérifie que le certificat local possède une clé de hachage publique identique à celle du fichier co2sys.
sys2# ikecert certdb -l Certificate Slot Name: 1 Key Type: rsa (Private key in certlocal slot 1) Subject Name: <C=US, O=TestCo, CN=Co2Sys> Key Size: 1024 Public key hash: C46DE77EF09084CE2B7D9C70479D77FF |
Le deuxième administrateur s'assure par téléphone que le premier administrateur a bien envoyé ce message électronique et vérifie l'attribut Subject Name du certificat.
Dans cet exemple, l'administrateur du système partym définit la période de validité du certificat. Le certificat est antidaté de 2,5 jours et sa période de validité est de 4 ans et 6 mois à compter de la date de création.
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ -A IP=192.168.13.213 \ -S -2d12h -F +4y6m |
L'administrateur du système enigma définit la période de validité du certificat. Le certificat est antidaté de 2 jours et sa période de validité s'étend jusqu'au 31 décembre 2010, minuit.
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \ -A IP=192.168.116.16 \ -S -2d -F "12/31/2010 12:00 AM" |
Les certificats publics émanant d'autorités de certification (AC) requièrent une négociation avec une organisation externe. Ces certificats s'intègrent très facilement dans les environnements à grande échelle afin protéger un grand nombre de systèmes communicants.
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.
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.
La commande ikecert certlocal -kc permet de créer une demande de certificat.
Pour consulter la description des arguments de cette commande, reportez-vous à l'Étape 2 de la section Configuration du protocole IKE avec des certificats de clés publiques autosignés.
# ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname |
La commande suivante permet par exemple de créer une demande de certificats sur le système partym :
# ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \ > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym" Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/2. Enabling external key providers - done. Certificate Request: Proceeding with the signing operation. Certificate request generated successfully (…/publickeys/0) Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST----- |
La commande suivante permet de créer une demande de certificat sur le système enigma :
# ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \ > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax" Creating software private keys. … Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … 8qlqdjaStLGfhDOO -----END CERTIFICATE REQUEST----- |
Soumettez la demande de certificat à un fournisseur de PKI.
Le fournisseur de PKI vous indiquera la procédure de soumission des demandes de certificat. Dans la plupart des cas, celle-ci s'effectue en remplissant un formulaire directement sur le site Web du fournisseur. Dans ce formulaire, vous devrez notamment indiquer la preuve de la légitimité de votre demande. Il suffit généralement de coller votre certificat dans le formulaire. Après avoir vérifié votre demande, le fournisseur émet les deux objets de certificats suivants et une liste des certificats révoqués :
Votre certificat de clé publique – Ce certificat est basé sur la demande que vous avez envoyée au fournisseur. Cette demande est intégrée au certificat, qui vous identifie de manière unique.
Un certificat AC – La signature du fournisseur. L'AC vérifie que votre certificat de clé publique est légitime.
Une liste de révocation de certificats (LRC) – La liste la plus récente des certificats révoqués par le fournisseur. Cette liste n'est pas expédiée sous la forme d'un objet de certificat séparé si l'accès à la LRC est intégré au certificat de clé publique.
Si un URI de LRC est intégré au certificat de clé publique, IKE peut récupérer automatiquement la LRC. De la même façon, si une entrée de DN (nom de répertoire sur un serveur LDAP) est intégrée au certificat de clé publique, IKE peut récupérer la LRC sur un serveur LDAP que vous avez spécifié et la mettre en cache.
Pour consulter un exemple d'URI et d'entrée de DN intégrés à un certificat de clé publique, reportez-vous à la section Traitement des listes de révocation de certificats.
Ajoutez tous les certificats sur votre système.
L'option -a de la commande ikecert certdb -a ajoute l'objet collé à la base de données de certificats correspondante de votre système. Pour plus d'informations, reportez-vous à la section IKE avec certificats de clés publiques.
Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Ajoutez le certificat de clé publique que vous avez reçu du fournisseur de PKI.
# ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D |
Ajoutez le certificat AC émanant du fournisseur de PKI.
# ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D |
Si le fournisseur de PKI vous a envoyé une liste de révocation de certificats, ajoutez-la à la base de données certrldb :
# ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D |
Le mot-clé cert_root permet d'identifier le fournisseur de PKI dans le fichier /etc/inet/ike/config.
Utilisez le nom que le fournisseur de PKI vous a indiqué.
Sur le système partym, par exemple, le fichier ike/config peut se présenter de la manière suivante :
# Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des } p2_pfs 2 { label "US-partym to JA-enigmax - Example PKI" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} } |
Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.
Créez un fichier similaire sur le système enigma.
Le fichier enigma ike/config doit :
inclure la même valeur cert_root ;
utiliser les valeurs de enigma pour les paramètres locaux ;
utiliser les valeurs de partym pour les paramètres distants ;
créer une valeur unique pour le mot-clé label. Elle doit différer de la valeur label du système distant.
… cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 … |
Spécifiez le mode de traitement des LRC par le protocole IKE.
Choisissez l'option appropriée :
Pas de LRC disponible
Si le fournisseur de PKI ne fournit pas de LRC, ajoutez le mot-clé ignore_crls au fichier ike/config.
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls … |
Le mot-clé ignore_crls indique au protocole IKE de ne pas chercher de LRC.
LRC disponible
Si le fournisseur de PKI vous communique un point de distribution central pour les LRC, vous pouvez modifier le fichier ike/config de manière à ce qu'il pointe sur cet emplacement.
Pour consulter des exemples de ce type de configuration, reportez-vous à la section Traitement des listes de révocation de certificats.
Lorsque vous utilisez auth_method rsa_encrypt dans le fichier ike/config, vous devez ajouter le certificat homologue à la base de données publickeys.
Envoyez ce certificat à l'administrateur du système distant.
Vous pouvez le coller dans un e-mail.
L'administrateur de partym envoie le message suivant :
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE----- |
L'administrateur de enigma envoie l'e-mail suivant :
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE----- |
Sur chacun des systèmes, ajoutez à la base de données publickeys locale le certificat envoyé par e-mail.
# ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D |
En cachant les identités à l'aide du protocole IKE, la méthode d'authentification utilisée en chiffrement RSA prévient les risques d'écoute électronique. Étant donné que la méthode rsa_encrypt cache l'identité de l'homologue, le protocole IKE ne peut récupérer son certificat. La méthode rsa_encrypt requiert donc que les homologues IKE connaissent leurs clés publiques respectives.
C'est pourquoi vous devez ajouter le certificat de l'homologue à la base de données publickeys lorsque vous utilisez la méthode auth_method de rsa_encrypt dans le fichier /etc/inet/ike/config. La base de données publickeys détient alors trois certificats pour chaque couple de systèmes communicants :
votre certificat de clé publique ;
le certificat AC ;
le certificat de clé publique de l'homologue.
Dépannage – La charge du protocole IKE, qui inclut les trois certificats, peut s'avérer trop importante pour le chiffrement via rsa_encrypt. L'apparition d'erreurs indiquant que l'autorisation a échoué ou que la charge n'est pas conforme peut signifier que la méthode rsa_encrypt est incapable de chiffrer la totalité de la charge. Pour réduire la charge, utilisez une autre méthode (par exemple, rsa_sig, qui ne requiert que deux certificats).
Le processus de génération et de stockage de certificats de clés publiques sur du matériel est similaire au processus de génération et de stockage de certificats de clés publiques sur un système. Dans le premier cas, il convient d'identifier le matériel à l'aide des commandes ikecert certlocal et ikecert certdb, accompagnées de l'option -T et de l'ID de jeton.
Le matériel doit être configuré.
Excepté si le mot-clé pkcs11_path du fichier /etc/inet/ike/config pointe sur une autre bibliothèque, le matériel utilise /usr/lib/libpkcs11.so. Cette bibliothèque doit être implémentée conformément aux standards suivants : RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), c'est-à-dire une bibliothèque PKCS #11.
Pour consulter les instructions de paramétrage, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000 .
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.
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.
Générez un certificat autosigné ou une demande de certificat et spécifiez l'ID de jeton.
Procédez de l'une des manières suivantes :
Pour RSA, la carte Sun Crypto Accelerator 4000 prend en charge des clés d'une longueur maximum de 2 048 bits. Pour DSA, la longueur maximum des clés est de 1 024 bits.
Pour un certificat autosigné, utilisez la syntaxe suivante :
# ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password |
L'argument de l'option -T est l'ID de jeton de la carte Sun Crypto Accelerator 4000 connectée.
Pour une demande de certificat, utilisez la syntaxe suivante :
# ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password |
Pour obtenir une description des arguments de la commande ikecert, reportez-vous à la page de manuel ikecert(1M).
Lorsque l'invite demandant le PIN s'affiche, entrez le nom de l'utilisateur de la carte Sun Crypto Accelerator 4000 suivi de deux points et du mot de passe de l'utilisateur.
Si la carte Sun Crypto Accelerator 4000 possède un utilisateur ikemgr dont le mot de passe est rgm4tigt, entrez :
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt |
La réponse est stockée en texte en clair sur le disque.
Après entrée du mot de passe, le certificat s'imprime :
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE----- |
Envoyez votre certificat aux personnes concernées.
Procédez de l'une des manières suivantes :
Envoyez le certificat autosigné au système distant.
Vous pouvez le coller dans un e-mail.
Envoyez la demande de certificat à un fournisseur de PKI.
Pour ce faire, suivez les instructions du fournisseur de PKI. Pour plus d'informations, reportez-vous à l'Étape 3 de la section Configuration du protocole IKE avec des certificats signés par une AC.
Éditez le fichier /etc/inet/ike/config sur votre système pour reconnaître les certificats.
Procédez de l'une des manières suivantes :
Utilisez les valeurs fournies par l'administrateur du système distant pour les paramètres cert_trust, remote_id et remote_addr. Sur le système enigma par exemple, le fichier ike/config se présente comme suit :
# Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.116.16" Local system's certificate Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} } |
Demande de certificat
Entrez le nom que le fournisseur de PKI vous a communiqué comme valeur du mot-clé cert_root. Sur le système enigma par exemple, le fichier ike/config peut se présenter comme suit :
# Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} } |
Placez les certificats de l'autre partie sur le matériel.
Répondez à la demande de PIN comme lors de l'Étape 3.
Vous devez ajouter les certificats de clés publiques au matériel connecté qui a généré votre clé privée.
Certificat autosigné.
Ajoutez le certificat autosigné du système distant. Dans cet exemple, il est stocké dans le fichier DCA.ACCEL.STOR.CERT.
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password |
Si le certificat autosigné a utilisé rsa_encrypt comme valeur du paramètre auth_method, ajoutez le certificat de l'homologue au magasin du matériel.
Certificats émanant d'un fournisseur de PKI.
Ajoutez le certificat généré par le fournisseur suite à votre demande et ajoutez l'AC.
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password |
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password |
Pour ajouter une liste de révocation de certificats (LRC) communiquée par un fournisseur de PKI, reportez-vous à la section Traitement des listes de révocation de certificats.
Les listes de révocation de certificats (LRC) sont émises par une AC et contiennent les certificats périmés ou compromis. Vous pouvez traiter les LRC de quatre façons :
Vous devez faire en sorte que le protocole IKE ignore les listes de révocation de certificats si votre AC n'en émet pas. Pour plus d'informations, reportez-vous à l'Étape 6 de la section Configuration du protocole IKE avec des certificats signés par une AC.
Vous pouvez faire en sorte que le protocole IKE accède aux LRC à partir d'un URI (uniform resource indicator, identificateur universel de ressources) dont l'adresse est intégrée au certificat de clé publique de l'AC.
Vous pouvez faire en sorte que le protocole IKE accède aux LRC à partir d'un serveur LDAP dont l'entrée de nom de répertoire (DN, directory name) est intégrée au certificat de clé publique de l'AC.
Vous pouvez traiter les LRC comme des arguments de la commande ikecert certrldb. Voir l'Exemple 23–7.
La section ci-dessous décrit la procédure permettant de paramétrer l'utilisation des LRC à partir d'un point de distribution central dans le protocole IKE.
Affichez le certificat que vous avez reçu de l'AC.
# ikecert certdb -lv certspec |
Liste les certificats dans la base de données de certificats IKE.
Liste les certificats en mode détaillé. Utilisez cette option avec précaution.
Modèle permettant de rechercher les certificats correspondants dans la base de données de certificats IKE.
Par exemple, le certificat ci-dessous a été émis par Sun Microsystems (les détails ont été modifiés).
# ikecert certdb -lv example-protect.sun.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com> Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> SerialNumber: 14000D93 Validity: Not Valid Before: 2002 Jul 19th, 21:11:11 GMT Not Valid After: 2005 Jul 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.sun.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.sun.com/pki/pkismica.crl#i DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access |
Notez l'entrée CRL Distribution Points. L'entrée URI indique que la LRC de cette organisation est disponible sur le Web. L'entrée DN indique que la LRC est disponible sur un serveur LDAP. Après que le protocole IKE a accédé à la LRC, celle-ci est mise en cache en vue de futures utilisations.
Pour accéder à la LRC, vous devez tout d'abord accéder à un point de distribution.
Choisissez l'une des méthodes suivantes pour accéder à la LRC depuis un point de distribution central.
Ajoutez le mot-clé use_http au fichier /etc/inet/ike/config de l'hôte. Le fichier ike/config se présente comme suit :
# Use CRL from organization's URI use_http … |
Ajoutez le mot-clé proxy au fichier ike/config. Le mot-clé proxy adopte un URL comme argument, comme indiqué ci-dessous :
# Use own web proxy proxy "http://proxy1:8080" |
Utilisez le nom du serveur LDAP comme argument du mot-clé ldap-list dans le fichier /etc/inet/ike/config de l'hôte. Le nom du serveur LDAP est fourni par votre organisation. L'entrée dans le fichier ike/config se présente comme suit :
# Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" … |
Le protocole IKE récupère la LRC et la met en cache jusqu'à ce que le certificat expire.
Si la LRC du fournisseur de PKI n'est pas disponible à partir d'un point de distribution central, vous pouvez ajouter cette liste manuellement à la base de données certrldb locale. Pour extraire la LRC dans un fichier, suivez les instructions du fournisseur de PKI, puis ajoutez la LRC à la base de données à l'aide de la commande ikecert certrldb -a.
# ikecert certrldb -a < Sun.Cert.CRL |
Le tableau ci-dessous décrit les procédures permettant de configurer le protocole IKE pour gérer des systèmes qui se connectent à distance à un site central.
Tâche |
Description |
Voir |
---|---|---|
Établissement de la communication avec un site central depuis un lieu hors site |
Permettez aux systèmes hors site de communiquer avec un site central. Ces systèmes peuvent être portables. | |
Utilisation d'un certificat racine et du protocole IKE sur un système central acceptant le trafic des systèmes portables |
Configurez un système de passerelle pour accepter le trafic IPsec d'un système ne possédant pas d'adresse IP fixe. | |
Utilisation d'un certificat racine et du protocole IKE sur un système ne possédant pas d'adresse IP fixe |
Configurez le système portable de manière à protéger son trafic avec le site central (par exemple, le siège de l'entreprise). | |
Utilisation de certificats autosignés et du protocole IKE sur un système central acceptant le trafic de systèmes portables |
Configurez un système de passerelle avec des certificats autosignés pour accepter le trafic IPsec d'un système portable. | |
Utilisation de certificats autosignés et du protocole IKE sur un système ne possédant pas d'adresse IP fixe |
Configurez un système portable avec des certificats autosignés pour protéger son trafic avec un site central. |
Lorsqu'ils sont configurés correctement, les ordinateurs portables peuvent communiquer avec les ordinateurs centraux de l'entreprise via IPsec et IKE. L'utilisation combinée d'une stratégie IPsec globale et d'une méthode d'authentification de clé publique permet de protéger le trafic des systèmes hors site avec le système central.
Les protocoles IPsec et IKE requièrent un ID unique pour identifier la source et la destination. Pour les systèmes portables hors site ne possédant pas d'adresse IP unique, vous devez utiliser un autre type d'ID permettant d'identifier un système de manière unique (par exemple, DNS, DN ou email).
Il est toujours préférable de configurer les systèmes portables ou hors site possédant une adresse IP unique avec un autre type d'ID. Par exemple, si ces systèmes tentent de se connecter à un site central par l'intermédiaire d'un boîtier NAT, leur adresse unique n'est pas utilisée. Le boîtier NAT leur assigne une adresse IP arbitraire que le système central ne reconnaît pas.
Les clés prépartagées ne sont pas, elles non plus, un moyen d'authentification approprié pour les systèmes portables, car elles requièrent une adresse IP fixe. Les certificats autosignés ou les certificats PKI permettent par contre aux systèmes portables de communiquer avec le site central.
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.
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.
Configurez le système central de manière à ce qu'il reconnaisse les systèmes portables.
Paramétrez le fichier /etc/hosts.
Il n'est pas nécessaire que le système central reconnaisse des adresses spécifiques de systèmes portables.
# /etc/hosts on central central 192.xxx.xxx.x |
Paramétrez le fichier ipsecinit.conf.
Le système central nécessite une stratégie autorisant une plage étendue d'adresses IP. Les certificats de la stratégie IKE garantissent ultérieurement la légitimité des systèmes connectés.
# /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
Paramétrez le fichier ike.config.
Le DNS identifie le système central et les certificats permettent d'authentifier le système.
## /etc/inet/ike/ike.config on central # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # List self-signed certificates - trust server and enumerated others #cert_trust "DNS=central.domain.org" #cert_trust "DNS=mobile.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=root@central.domain.org" #cert_trust "email=user1@mobile.domain.org" # # Rule for mobile systems with certificate { label "Mobile systems with certificate" local_id_type DNS # Any mobile system who knows my DNS or IP can find me. local_id "central.domain.org" local_addr 192.xxx.xxx.x # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } } |
Connectez-vous à chacun des systèmes portables et configurez-les de manière à ce qu'ils trouvent le système central.
Paramétrez le fichier /etc/hosts.
Le fichier /etc/hosts n'a pas besoin d'une adresse pour le système portable, mais peut en fournir une. Il doit contenir une adresse IP publique pour le système central.
# /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x |
Paramétrez le fichier ipsecinit.conf.
Le système portable doit être capable de trouver le système central à partir de son adresse IP publique. Les deux systèmes doivent avoir la même stratégie IPsec.
# /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
Paramétrez le fichier ike.config.
L'identificateur ne peut pas être une adresse IP. Pour les systèmes portables, les identificateurs valides sont les suivants :
DN=nom-répertoire-ldap
DNS=adresse-DNS
email=adresse-e-mail
Les certificats permettent d'authentifier le système portable.
## /etc/inet/ike/ike.config on mobile # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # Self-signed certificates - trust me and enumerated others #cert_trust "DNS=mobile.domain.org" #cert_trust "DNS=central.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=user1@domain.org" #cert_trust "email=root@central.domain.org" # # Rule for off-site systems with root certificate { label "Off-site mobile with certificate" local_id_type DNS # NAT-T can translate local_addr into any public IP address # central knows me by my DNS local_id "mobile.domain.org" local_addr 0.0.0.0/0 # Find central and trust the root certificate remote_id "central.domain.org" remote_addr 192.xxx.xxx.x p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } } |
Lisez la configuration IKE dans le noyau.
Le protocole IKE peut commencer les négociations derrière un boîtier NAT, mais il est préférable de ne pas faire intervenir de boîtier de ce type. Dans l'exemple ci-dessous, les certificats racine ont été émis par une AC. Ils ont été placés sur les deux systèmes (un système portable et un système central). Le système central accepte les négociations IPsec émanant d'un système situé derrière un boîtier NAT. main1 est le système acceptant les connexions de systèmes hors site. Pour paramétrer les systèmes hors site, reportez-vous à l'Exemple 23–9.
## /etc/hosts on main1 main1 192.168.0.100 |
## /etc/inet/ipsecinit.conf on main1 # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
## /etc/inet/ike/ike.config on main1 # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://cache1.domain.org:8080/" # # Use LDAP server ldap_server "ldap1.domain.org,ldap2.domain.org:389" # # List CA-signed certificate cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI" # # Rule for off-site systems with root certificate { label "Off-site system with root certificate" local_id_type DNS local_id "main1.domain.org" local_addr 192.168.0.100 # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1} } |
Dans l'exemple ci-dessous, les certificats racine ont été émis par une AC et placés sur le système portable et sur le système central. mobile1 se connecte au siège de l'entreprise depuis un domicile privé. Le réseau du FAI (fournisseur d'accès Internet) utilise un boîtier NAT pour pouvoir assigner une adresse privée à mobile1. Le boîtier NAT convertit l'adresse privée en une adresse IP publique partagée par d'autres nœuds du réseau du FAI. Le siège de l'entreprise ne se trouve pas derrière un boîtier NAT. Pour paramétrer l'ordinateur du siège de l'entreprise, reportez-vous à l'Exemple 23–8.
## /etc/hosts on mobile1 mobile1 10.1.3.3 main1 192.168.0.100 |
## /etc/inet/ipsecinit.conf on mobile1 # Find main1 {raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
## /etc/inet/ike/ike.config on mobile1 # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://cache1.domain.org:8080/" # # Use LDAP server ldap_server "ldap1.domain.org,ldap2.domain.org:389" # # List CA-signed certificate cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI" # # Rule for off-site systems with root certificate { label "Off-site mobile1 with root certificate" local_id_type DNS local_id "mobile1.domain.org" local_addr 0.0.0.0/0 # Find main1 and trust the root certificate remote_id "main1.domain.org" remote_addr 192.168.0.100 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } } |
Dans l'exemple ci-dessous, les certificats autosignés ont été émis par le système portable et le système central, et ont été placés sur les deux systèmes. main1 est le système acceptant les connexions de systèmes hors site. Pour paramétrer les systèmes hors site, reportez-vous à l'Exemple 23–11.
## /etc/hosts on main1 main1 192.168.0.100 |
## /etc/inet/ipsecinit.conf on main1 # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
## /etc/inet/ike/ike.config on main1 # Global parameters # # Self-signed certificates - trust me and enumerated others cert_trust "DNS=main1.domain.org" cert_trust "jdoe@domain.org" cert_trust "user2@domain.org" cert_trust "user3@domain.org" # # Rule for off-site systems with trusted certificate { label "Off-site systems with trusted certificates" local_id_type DNS local_id "main1.domain.org" local_addr 192.168.0.100 # Trust the self-signed certificates # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } } |
Dans l'exemple ci-dessous, mobile1 se connecte au siège de l'entreprise depuis un domicile privé. Les certificats ont été émis par le système portable et le système central, et ont été placés sur les deux systèmes. Le réseau du FAI utilise un boîtier NAT pour assigner une adresse privée à mobile1. Le boîtier NAT convertit l'adresse privée en une adresse IP publique partagée par d'autres nœuds du réseau du FAI. Le siège de l'entreprise ne se trouve pas derrière un boîtier NAT. Pour paramétrer l'ordinateur du siège de l'entreprise, reportez-vous à l'Exemple 23–10.
## /etc/hosts on mobile1 mobile1 10.1.3.3 main1 192.168.0.100 |
## /etc/inet/ipsecinit.conf on mobile1 # Find main1 {raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
## /etc/inet/ike/ike.config on mobile1 # Global parameters # Self-signed certificates - trust me and the central system cert_trust "jdoe@domain.org" cert_trust "DNS=main1.domain.org" # # Rule for off-site systems with trusted certificate { label "Off-site mobile1 with trusted certificate" local_id_type email local_id "jdoe@domain.org" local_addr 0.0.0.0/0 # Find main1 and trust the certificate remote_id "main1.domain.org" remote_addr 192.168.0.100 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } } |
Le tableau ci-dessous répertorie les procédures permettant de signaler au protocole IKE la connexion des composants matériels. Pour que le protocole IKE puisse utiliser un composant matériel connecté, vous devez préalablement l'informer de l'existence de ce composant. Pour utiliser le composant matériel, suivez les procédures décrites à la section Configuration du protocole IKE avec des certificats de clés publiques.
Vous n'avez pas besoin de renseigner l'IKE sur le matériel sur puce. Par exemple, le processeur UltraSPARC® T2 offre l'accélération cryptographique. Vous n'avez pas besoin de configurer IKE pour qu'il recherche les accélérateurs sur puce.
Tâche |
Description |
Voir |
---|---|---|
Déchargement des opérations de clés IKE sur la carte Sun Crypto Accelerator 1000 |
Reliez le protocole IKE à la bibliothèque PKCS #11. |
Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000 |
Déchargement des opérations de clés IKE et stockage des clés sur la carte Sun Crypto Accelerator 4000 |
Reliez le protocole IKE et la bibliothèque PKCS #11, puis répertoriez le matériel connecté. |
Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000 |
Les certificats des clés publiques peuvent également être stockés sur un matériel connecté. La carte Sun Crypto Accelerator 1000 est destinée uniquement au stockage. Les cartes Sun Crypto Accelerator 4000 et Sun Crypto Accelerator 6000 permettent le stockage, ainsi que le déchargement d'opérations de clés publiques du système vers la carte.
La procédure ci-dessous suppose que la carte Sun Crypto Accelerator 1000 est connectée au système et que le ou les logiciels correspondants ont été installés et configurés. Pour obtenir des instructions, reportez-vous au Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.
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.
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.
Assurez-vous que la bibliothèque PKCS #11 est liée.
Entrez la commande suivante pour déterminer si la bibliothèque PKCS #11 est liée :
# ikeadm get stats Phase 1 SA counts: Current: initiator: 0 responder: 0 Total: initiator: 0 responder: 0 Attempted: initiator: 0 responder: 0 Failed: initiator: 0 responder: 0 initiator fails include 0 time-out(s) PKCS#11 library linked in from /usr/lib/libpkcs11.so # |
Solaris10 1/06 : à partir de cette version, vous pouvez stocker des clés dans le fichier keystore de clés softtoken.
Pour plus d'informations sur le keystore fourni par la structure cryptographique de Solaris, reportez-vous à la page de manuel cryptoadm(1M). Pour plus d'informations sur l'utilisation du keystore, reportez-vous à l'Example 23–12.
La procédure ci-dessous suppose que la carte Sun Crypto Accelerator 4000 est connectée au système et que le ou les logiciels correspondants ont été installés et configurés. Pour obtenir des instructions, reportez-vous au Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.
Si vous utilisez une carte Sun Crypto Accelerator 6000, reportez-vous au Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide.
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.
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.
Assurez-vous que la bibliothèque PKCS #11 est liée.
IKE utilise les routines de la bibliothèque pour gérer la génération des clés et leur stockage sur la carte Sun Crypto Accelerator 4000. Entrez la commande suivante pour déterminer si une bibliothèque PKCS #11 a été liée :
$ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $ |
Pour RSA, la carte Sun Crypto Accelerator 4000 prend en charge des clés d'une longueur maximum de 2 048 bits. Pour DSA, la longueur maximum des clés est de 1 024 bits.
Déterminez l'ID de jeton de la carte Sun Crypto Accelerator 4000.
$ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot " |
La bibliothèque renvoie un ID de jeton, également appelé nom du keystore, de 32 caractères. Dans l'exemple ci-dessous, vous pouvez utiliser le jeton Sun Metaslot avec la commande ikecert pour stocker et accélérer les clés IKE.
Pour plus d'informations sur l'utilisation du jeton, reportez-vous à la section Génération et stockage de certificats de clés publiques sur le matériel.
Les espaces situés à la fin sont automatiquement remplis par la commande ikecert.
Les jetons peuvent être stockés sur un disque, sur une carte connectée ou dans le fichier keystore de clés softtoken fourni par la structure de chiffrement de Solaris. L'ID de jeton du keystore de softtoken peut se présenter comme suit :
$ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot " |
Pour créer une phrase de passe pour un keystore de softtoken, reportez-vous à la page de manuel pktool(1).
La commande ci-dessous permet d'ajouter un certificat au keystore de softtoken. Sun.Metaslot.cert est le fichier contenant le certificat AC.
# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert Enter PIN for PKCS#11 token: Type user:passphrase |
Le tableau ci-dessous répertorie les procédures permettant de configurer les paramètres de transmission du protocole IKE.
Tâche |
Description |
Voir |
---|---|---|
Amélioration de l'efficacité de la négociation des clés |
Modifiez les paramètres de négociation des clés. |
Modification de la durée de la phase 1 de la négociation des clés IKE |
Configuration de la négociation des clés pour autoriser les délais de transmission |
Allongez la durée de négociation des clés. | |
Configuration de la négociation des clés pour qu'elle s'effectue rapidement ou pour que les échecs s'affichent rapidement |
Réduisez la durée de négociation des clés. |
Lorsque le protocole IKE négocie les clés, la vitesse de transmission risque de compromettre la réussite de l'opération. En temps normal, il n'est pas nécessaire de modifier les valeurs par défaut des paramètres de transmission du protocole IKE. Dans certains cas (par exemple, optimisation de la négociation sur des lignes surchargées ou pour la reproduction d'un problème), vous pouvez toutefois juger utile de le faire.
Le fait de prolonger la durée de négociation permet à IKE de négocier les clés sur les lignes de transmission problématiques. Vous pouvez augmenter certains paramètres pour que la négociation réussisse dès la première tentative. Si elle échoue, vous pouvez espacer les tentatives suivantes pour optimiser les chances de succès.
Le fait de réduire la durée de négociation permet d'utiliser des lignes fiables. Vous pouvez relancer plus rapidement toute négociation ayant échoué. La réduction de la durée de négociation permet également d'accélérer le processus de reproduction d'un problème afin d'établir un diagnostic. Elle permet également d'utiliser les associations de sécurité (SA, security associations) de la phase 1 pendant toute leur durée de vie.
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.
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.
Modifiez la valeur par défaut des paramètres globaux de transmission sur chacun des systèmes.
Sur chacun des systèmes, modifiez les paramètres de durée de la phase 1 dans le fichier /etc/inet/ike/config.
### ike/config file on system ## Global parameters # ## Phase 1 transform defaults # #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float) |
Délai de suppression d'une tentative de négociation IKE de phase 1 en attente (en secondes). Par défaut, la tentative reste active pendant 30 secondes.
Nombre de retransmissions avant abandon de toute négociation IKE. Par défaut, IKE essaie cinq fois.
Intervalle initial entre les retransmissions. Cet intervalle est doublé jusqu'à ce que la valeur retry_timer_max soit atteinte. L'intervalle initial est de 0,5 secondes.
Intervalle maximum (en secondes) entre les retransmissions. L'intervalle de retransmission cesse d'augmenter lorsque cette limite est atteinte. Par défaut, cette limite est de 30 secondes.
Lisez la configuration modifiée dans le noyau.
Dans l'exemple ci-dessous, un système est connecté à son homologue IKE via une ligne encombrée. Les paramètres d'origine figurent en commentaires dans le fichier. Les nouveaux paramètres augmentent la durée de négociation.
### ike/config file on partym ## Global Parameters # ## Phase 1 transform defaults #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float) # expire_timer 600 retry_limit 10 retry_timer_init 2.5 retry_timer_max 180 |
Dans l'exemple ci-dessous, un système est connecté à son homologue IKE via une ligne à haut débit peu encombrée. Les paramètres d'origine figurent en commentaires dans le fichier. Les nouveaux paramètres diminuent la durée de négociation.
### ike/config file on partym ## Global Parameters # ## Phase 1 transform defaults #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float) # expire_timer 120 retry_timer_init 0.20 |
Ce chapitre aborde les sujets suivants :
Pour plus d'informations sur l'implémentation du protocole IKE, reportez-vous au Chapitre 23Configuration du protocole IKE (tâches). Pour obtenir une présentation du protocole, reportez-vous au Chapitre 22Protocole IKE (présentation).
Service svc:/network/ipsec/ike:default : l'utilitaire de gestion des services (SMF) fournit le service ike qui permet de gérer IKE. Par défaut, ce service est désactivé. Avant d'activer ce service, vous devez créer un fichier de configuration IKE, /etc/inet/ike/config.
Les propriétés suivantes du service ike sont configurables :
Propriété config_file : emplacement du fichier de configuration IKE. La valeur initiale est /etc/inet/ike/config.
Propriété debug level : niveau de débogage du démon in.iked. La valeur initiale est op, ce qui signifie opérationnelle. Pour connaître les valeurs possibles, reportez-vous au tableau sur les niveaux de débogage sous Object Types de la page de manuel ikeadm(1M).
Propriété admin_privilege : niveau de privilège du démon in.iked. La valeur initiale est base. Les autres valeurs sont modkeys et keymat. Pour plus de détails, reportez-vous à la section Commande d'administration du protocole IKE .
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).
Le démon in.iked automatise la gestion des clés cryptographiques pour IPsec sur les systèmes Solaris. Il négocie avec un système distant exécutant le même protocole pour fournir, de manière protégée, des numéros de clé authentifiés destinés aux associations de sécurité (SA). Le démon doit s'exécuter sur tous les systèmes qui sont censés communiquer en toute sécurité.
Par défaut, le service svc:/network/ipsec/ike:default n'est pas activé. Après que vous avez configuré le fichier /etc/inet/ike/config et activé le service ike, le démon in.iked se lance à l'initialisation du système.
Une fois le démon IKE en cours d'exécution, le système s'authentifie auprès de son entité IKE homologue lors de la phase 1. L'homologue, ainsi que les méthodes d'authentification, sont définis dans le fichier de stratégie IKE. Le démon crée alors les clés pour la phase 2. Les clés IKE sont actualisées automatiquement à un intervalle spécifié dans le fichier de stratégie. Le démon in.iked est à l'écoute des demandes IKE entrantes émanant du réseau et des demandes de trafic hors bande via le socket PF_KEY. Pour plus d'informations, reportez-vous à la page de manuel pf_key(7P).
Le démon IKE est pris en charge par deux commandes. La commande ikeadm peut être utilisée pour afficher et modifier temporairement la stratégie IKE. Pour modifier de manière définitive la stratégie IKE, vous devez modifier les propriétés du service ike. Pour connaître la procédure, reportez-vous à la section Affichage des clés IKE prépartagées.
et la commande ikecert d'afficher et de gérer les bases de données de clés publiques. Cette dernière gère les bases de données ike.privatekeys et publickeys locales, ainsi que les opérations de clés publiques et le stockage de ces clés sur du matériel.
Le fichier de configuration de la stratégie IKE, /etc/inet/ike/config, gère les clés des interfaces protégées dans le fichier de stratégie IPsec, /etc/inet/ipsecinit.conf. Le fichier de stratégie IKE gère les clés pour IKE et pour les SA IPsec. Le démon IKE requiert lui-même des numéros de clé lors de la phase 1.
La gestion des clés avec IKE inclut des règles et des paramètres globaux. Les règles IKE identifient les systèmes ou réseaux sécurisés par les numéros de clé. Elles spécifient également la méthode d'authentification. Les paramètres globaux incluent des éléments tels que le chemin vers un accélérateur matériel connecté. Pour consulter des exemples de fichiers de stratégie IKE, reportez-vous à la section Configuration du protocole IKE avec des clés prépartagées (liste des tâches). Pour des exemples et une description des entrées de stratégies IKE, consultez la page de manuel ike.config(4).
Les SA IPsec prises en charge par IKE protègent les datagrammes IP conformément aux stratégies paramétrées dans le fichier de configuration des stratégies IPsec, /etc/inet/ipsecinit.conf. Le fichier de stratégie IKE détermine si la confidentialité de transmission parfaite (PFS, perfect forward security) est utilisée lors de la création des SA IPsec.
Le fichier ike/config peut inclure le chemin vers une bibliothèque implémentée conformément au standard RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki). IKE utilise la bibliothèque PKCS #11 pour accéder au matériel d'accélération et de stockage des clés.
En matière de sécurité, les considérations concernant le fichier ike/config sont similaires à celles concernant le fichier ipsecinit.conf. Pour plus d'informations, reportez-vous à la section Considérations de sécurité à propos de ipsecinit.conf et ipsecconf.
La commande ikeadm permet d'effectuer les opérations suivantes :
afficher les différents aspects du processus du démon IKE ;
modifier les paramètres qui sont transmis au démon IKE ;
afficher les statistiques concernant la création de SA pendant la phase 1 ;
déboguer les processus IKE ;
afficher les différents aspects de l'état d'IKE ;
modifier les propriétés du démon IKE ;
afficher les statistiques concernant la création de SA pendant la phase 1 ;
déboguer les échanges du protocole IKE.
Pour consulter des exemples et une description complète des options de cette commande, reportez-vous à la page de manuel ikeadm(1M)
Le niveau de privilège du démon IKE en cours d'exécution détermine les aspects du démon IKE susceptibles d'être affichés et modifiés. Trois niveaux de privilège sont possibles.
Vous ne pouvez ni afficher ni modifier les numéros de clé. Le niveau base est le niveau de privilège par défaut.
À ce niveau, vous pouvez supprimer, modifier et ajouter des clés prépartagées.
Ce niveau vous permet d'afficher les numéros de clé actuels à l'aide de la commande ikeadm.
Pour modifier temporairement un privilège, vous pouvez utiliser la commande ikeadm. Pour une modification permanente, modifiez la propriété admin_privilege du service ike. Pour connaître la procédure, reportez-vous à la section Procédure de gestion des services IKE et IPsec.
En matière de sécurité, les considérations concernant la commande ikeadm sont similaires à celles concernant la commande ipseckey. Pour plus d'informations, reportez-vous à la section Considérations de sécurité pour la commande ipseckey.
Lorsque vous créez des clés manuellement, elles sont stockées dans des fichiers du répertoire /etc/inet/secret. Le fichier ike.preshared contient les clés prépartagées des SA ISAKMP (Internet Security Association and Key Management Protocol) et le fichier ipseckeys contient les clés prépartagées des SA IPsec. Ces fichiers sont protégés en mode 0600 et le répertoire secret en mode 0700.
Lorsque vous configurez le fichier ike/config pour demander des clés prépartagées, vous créez un fichier ike.preshared. Vous entrez les numéros de clé des SA ISAKMP, c'est-à-dire de l'authentification IKE, dans le fichier ike.preshared. Les clés prépartagées étant utilisées pour authentifier la phase 1, le fichier doit être valide avant le démarrage du démon in.iked.
Le fichier ipseckeys contient les numéros de clé des SA IPsec. Pour consulter des exemples de gestion manuelle de ce fichier, reportez-vous à la section Création manuelle d'associations de sécurité IPsec. Le démon IKE n'utilise pas ce fichier. Les numéros de clé générés par IKE pour les SA IPsec sont stockés dans le noyau.
Les clés prépartagées ne peuvent être stockées sur des composants matériels. Elles sont générées et stockées sur le système.
La commande ikecert permet de manipuler les bases de données de clés publiques du système local. Utilisez-la lorsque le fichier ike/config requiert des certificats de clés publiques. Ces bases de données étant utilisées par IKE pour authentifier la phase 1 de l'échange, elles doivent être alimentées avant l'activation du démon in.iked. Trois sous-commandes permettent de gérer chacune des trois bases de données : certlocal, certdb et certrldb.
La commande ikecert permet aussi de gérer le stockage des clés. Elles peuvent être stockées sur disque, sur une carte Sun Crypto Accelerator 6000 ou &sca 4; connectée, ou dans un fichier keystore de clés softtoken. Ce fichier est disponible lorsque le metaslot de la structure cryptographique de Solaris est utilisé pour communiquer avec le matériel. La commande ikecert utilise la bibliothèque PKCS #11 pour localiser le lieu de stockage des clés.
Solaris 10 1/06 : à partir de cette version, il est inutile de spécifier la bibliothèque. Par défaut, la bibliothèque PKCS #11 est /usr/lib/libpkcs11.so.
Solaris 10 : dans cette version, il est nécessaire de spécifier l'entrée de PKCS #11. pour que l'option -T de la commande ikecert fonctionne. Cette entrée se présente de la manière suivante :
pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" |
Pour plus d'informations, consultez la page de manuel ikecert(1M) Pour plus d'informations sur le metaslot et sur le fichier keystore de clés softtoken, reportez-vous à la page de manuel cryptoadm(1M).
L'argument tokens répertorie les ID de jetons disponibles. Les ID de jetons permettent aux commandes ikecert certlocal et ikecert certdb de générer des certificats de clés publiques et des demandes de certificats. Ces certificats et demandes de certificats peuvent également être stockés par la structure cryptographique dans le fichier keystore de clés softtoken ou sur une carte Sun Crypto Accelerator 6000 ou &sca 4; connectée. La commande ikecert utilise la bibliothèque PKCS #11 pour déterminer l'emplacement de stockage des certificats.
La sous-commande certlocal gère la base de données des clés privées. Les options de cette sous-commande permettent d'ajouter, d'afficher et de supprimer des clés privées. Cette sous-commande permet également de créer un certificat autosigné ou une demande de certificat. L'option -ks crée un certificat autosigné et l'option-kc une demande de certificat. Les clés sont stockées sur le système, dans le répertoire /etc/inet/secret/ike.privatekeys, ou sur un composant matériel connecté (option -T).
Lorsque vous créez une clé privée, les options de la commande ikecert certlocal doivent avoir des entrées connexes dans le fichier ike/config. Le tableau ci-dessous détaille les correspondances entre les options ikecert et les entrées ike/config.
Tableau 24–1 Correspondances entre les options ikecert et les entrées ike/config
Option ikecert |
Entréeike/config |
Description |
---|---|---|
Pseudonyme identifiant le certificat de manière unique. Il peut s'agir d'une adresse IP, d'une adresse e-mail ou d'un nom de domaine. |
||
nom-distinctif-X.509 |
Nom complet de l'autorité de certification, incluant le pays (C), le nom de l'organisation (ON), l'unité d'organisation (OU) et le nom commun (CN). |
|
Méthode d'authentification légèrement plus lente que RSA. |
||
-t rsa-md5 et -t rsa-sha1 |
auth_method rsa_sig |
Méthode d'authentification légèrement plus rapide que la méthode DSA. La clé publique RSA doit être suffisamment importante pour chiffrer la charge utile la plus lourde. Les charges les plus lourdes sont habituellement les données d'identité (par exemple, le nom distinctif X.509). |
-t rsa-md5 et -t rsa-sha1 |
Le chiffrement RSA met les identités d'IKE à l'abri des écoutes électroniques, mais implique que les homologues IKE connaissent leurs clés publiques respectives. |
|
La bibliothèque PKCS #11 prend en charge l'accélération des clés sur les cartes Sun Crypto Accelerator 1000, Sun Accelerator 6000 et Sun Crypto Accelerator 4000. La bibliothèque fournit également les jetons qui gèrent le stockage des clés sur les cartes Sun Crypto Accelerator 6000 et Sun Crypto Accelerator 4000. |
Lorsque vous émettez une demande de certificat à l'aide de la commande ikecert certlocal -kc, vous envoyez la sortie de cette commande à un fournisseur de PKI ou à une AC. Si votre entreprise possède sa propre PKI, vous envoyez cette sortie à votre administrateur de PKI. Le fournisseur de PKI, l'AC ou votre administrateur de PKI crée alors les certificats. Ceux qui vous sont transmis par le fournisseur de PKI ou l'AC sont entrés dans la sous-commande certdb. La liste de révocation de certificats (LRC) que le fournisseur de PKI vous envoie est entrée dans la sous-commande certrldb.
La sous-commande certdb gère la base de données des clés publiques. Les options de cette sous-commande vous permettent d'ajouter, d'afficher et de supprimer des certificats et des clés publiques. Cette sous-commande accepte l'entrée de certificats générés par la commande ikecert certlocal -ks sur un système distant. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE avec des certificats de clés publiques autosignés. Cette commande accepte également l'entrée de certificats émanant de fournisseurs PKI ou d'AC. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE avec des certificats signés par une AC.
Les certificats et les clés publiques sont stockés sur le système, dans le répertoire /etc/inet/ike/publickeys . L'option -T permet de stocker les certificats, les clés privées et les clés publiques sur les composants matériels connectés.
La sous-commande certrldb gère la base de données des listes de révocation de certificats (LRC), /etc/inet/ike/crls. Cette base de données met à jour les listes de révocation des clés publiques. Les certificats qui ne sont plus valides figurent dans ces listes. Lorsqu'un fournisseur de PKI vous fait parvenir une LRC, vous pouvez l'installer dans cette base de données à l'aide de la commande ikecert certrldb. Pour plus d'informations sur cette procédure, reportez-vous à la section Traitement des listes de révocation de certificats.
Le répertoire /etc/inet/ike/publickeys contient la partie publique des biclés et leur certificat, qui sont stockés dans des fichiers ou à des emplacements. Ce répertoire est protégé en mode 0755 et peut être alimenté à l'aide de la commande ikecert certdb. L'option -T permet de stocker les clés sur une carte Sun Crypto Accelerator 6000 ou &sca 4; plutôt que dans le répertoire publickeys.
Les emplacements contiennent, sous forme chiffrée, le nom distinctif X.509 des certificats qui ont été générés sur un autre système. Si vous utilisez des certificats autosignés, vous devez indiquer le certificat que l'administrateur du système distant vous a envoyé comme entrée de commande. Si vous utilisez des certificats d'une AC, vous installez deux certificats signés d'une AC dans la base de données. Vous installez un certificat basé sur la requête de signature de certificat envoyée à l'AC. Vous installez également un certificat de l'AC.
Le répertoire /etc/inet/secret/ike.privatekeys contient des fichiers de clés privées qui font partie de biclés, c'est-à-dire les numéros de clé des SA ISAKMP. Ce répertoire est protégé en mode 0700. La commande ikecert certlocal permet d'alimenter le répertoire ike.privatekeys. Les clés privées sont effectives uniquement lors de l'installation de leur clé publique homologue, de certificats autosignés ou de certificats AC. Les clés publiques homologues sont stockées dans le répertoire /etc/inet/ike/publickey s ou sur une carte Sun Crypto Accelerator 6000 ou &sca 4;.
Le répertoire /etc/inet/ike/crls contient les fichiers des listes de révocation de certificats (LRC). Chaque fichier correspond à un fichier de certificat public du répertoire /etc/inet/ike/publickeys. Les fournisseurs de PKI fournissent les LRC correspondant à leurs certificats. La commande ikecert certrldb permet d'alimenter la base de données.
Ce chapitre offre un aperçu de Oracle Solaris IP Filter. Pour plus d'informations sur les tâches de Oracle Solaris IP Filter, reportez-vous au Chapitre 26Oracle Solaris IP Filter (tâches).
Le présent chapitre contient les informations suivantes :
Recommandations concernant l'utilisation de OpenSolaris IP Filter
Utilisation des fichiers de configuration Oracle Solaris IP Filter
Utilisation des ensembles de règles Oracle Solaris IP Filter
Cette section décrit les nouvelles fonctions de Oracle Solaris IP Filter.
Vous trouverez une liste complète des nouvelles fonctionnalités de Oracle Solaris et la description des différentes versions de cette application dans le document Nouveautés apportées à Oracle Solaris 10 9/10
À partir de la version Solaris 10 7/07:, les crochets de filtre de paquets sont désormais utilisés pour filtrer les paquets dans Oracle Solaris. Cette fonctionnalité offre les avantages suivants pour l'administration du système :
Les crochets de filtre de paquets simplifient la configuration de Oracle Solaris IP Filter.
Le filtrage de paquets entre les zones est à présent pris en charge.
Les crochets de filtre améliorent les performances de Oracle Solaris IP Filter.
Pour de plus amples informations sur ces crochets, reportez-vous à la section Crochets de filtre de paquets. Pour obtenir la description des tâches associées aux crochets de filtre de paquets, reportez-vous au Chapitre 26Oracle Solaris IP Filter (tâches).
Solaris 10 6/06 : pour les administrateurs système dont une partie de l'infrastructure réseau est configurée avec le protocole IPv6, le filtrage de paquets IPv6 est dorénavant compris dans Oracle Solaris IP Filter. Ce filtrage peut se baser sur l'adresse IPv6 source/de destination, sur les pools contenant des adresses IPv6 et sur les en-têtes d'extension IPv6.
L'option -6 a été ajoutée aux commandes ipf et ipfstat pour les utiliser avec IPv6. L'interface de ligne de commande ne change pas pour les commandes ipmon et ippool, mais celles-ci prennent également en charge IPv6. La commande ipmon a été améliorée afin de permettre la journalisation des paquets IPv6 et la commande ippool prend désormais en charge l'inclusion des adresses IPv6 dans les pools.
Pour plus d'informations, reportez-vous à la section IPv6 pour Oracle Solaris IP Filter. Pour obtenir la description des tâches associées au filtrage de paquets IPv6, reportez-vous au Chapitre 26Oracle Solaris IP Filter (tâches).
Oracle Solaris IP Filter remplace le pare-feu SunScreen en tant que logiciel de pare-feu pour Oracle Solaris. Tout comme le pare-feu SunScreen, Oracle Solaris IP Filter assure un filtrage de paquets avec état, ainsi que la translation d'adresse réseau (NAT, Network Address Translation). Oracle Solaris IP Filter permet également de filtrer les paquets sans état, ainsi que la création et la gestion des pools d'adresses.
Le filtrage de paquets assure une protection de base contre les attaques potentielles via le réseau. Oracle Solaris IP Filter peut filtrer les paquets par adresse IP, port, protocole, interface réseau et direction de trafic. Oracle Solaris IP Filter peut également filtrer par adresse IP source individuelle, adresse IP de destination, plage d'adresses IP ou pool d'adresses.
Oracle Solaris IP Filter est dérivé du logiciel Open Source IP Filter. Les modalités de la licence, l'attribution et le copyright du logiciel Open Source IP Filter se trouvent par défaut à l'emplacement suivant :/usr/lib/ipf/IPFILTER.LICENCE. Si vous avez installé Oracle Solaris dans un autre emplacement que celui par défaut, modifiez le chemin afin d'accéder au fichier se trouvant à l'emplacement de l'installation.
La page d'accueil du logiciel Open Source IP Filter de Darren Reed se trouve à l'adresse http://coombs.anu.edu.au/~avalon/ip-filter.html. Ce site Web fournit des informations relatives au logiciel Open Source IP Filter, notamment un lien vers le didacticiel "IP Filter Based Firewalls HOWTO" (Brendan Conoboy et Erik Fichtner, 2002). Vous trouverez dans ce didacticiel les instructions de construction de pare-feux dans un environnement BSD UNIX, expliquées pas à pas. Bien qu'il soit destiné à un environnement BSD UNIX, ce didacticiel peut également s'appliquer à la configuration de Oracle Solaris IP Filter.
Lors du traitement d'un paquet, Oracle Solaris IP Filter exécute une série d'étapes. Le diagramme ci-dessous illustre les étapes du traitement d'un paquet et l'intégration du filtrage à la pile de protocole TCP/IP.
Le traitement d'un paquet inclut les opérations suivantes :
Translation d'adresse réseau (NAT)
Translation d'une adresse IP privée vers une adresse publique, ou définition d'alias pour plusieurs adresses privées vers une adresse publique unique. NAT (Network Address Translation, translation d'adresse réseau) permet à une organisation de résoudre le problème d'épuisement des adresses IP lorsqu'elle utilise un réseau et requiert l'accès à Internet.
Comptabilité IP
Les règles d'entrée et de sortie peuvent être configurées séparément, avec enregistrement du nombre d'octets transmis. En cas de correspondance d'une règle, le nombre d'octets du paquet est ajouté à la règle et des statistiques en cascade sont rassemblées.
Vérification du cache de fragment
Si un paquet du trafic en cours constitue un fragment et que le paquet précédent a été autorisé, le fragment de paquet est également autorisé, sans consultation de la table d'état ni vérification de règle.
Vérification de l'état du paquet
Si la règle contient l'instruction keep state, tous les paquets d'une session spécifiée sont automatiquement transmis ou bloqués, selon la spécification de la règle : pass (transmettre) ou block (bloquer).
Vérification du pare-feu
Les règles d'entrée et de sortie peuvent être configurées séparément, afin d'autoriser ou non la transmission d'un paquet, via Filtre Solaris IP , vers les routines TCP/IP du noyau ou vers le réseau.
Groupes
Les groupes permettent d'écrire des ensembles de règles selon une structure arborescente.
Fonction
Une fonction correspond à l'action à réaliser. Les fonctions sont, par exemple, block (bloquer), pass (transmettre), literal (littéral) et send ICMP response (envoyer une réponse ICMP).
FastRoute
FastRoute indique à Filtre Solaris IP de ne pas transmettre le paquet vers la pile UNIX IP pour le routage, ce qui entraîne une réduction TTL.
Authentification IP
Les paquets authentifiés ne sont transmis via les boucles du pare-feu qu'une seule fois, afin d'éviter le traitement multiple de certains paquets.
Les services SMF svc: /network/pfil et svc: /network/ipfilter gèrent OpenSolaris IP Filter. Pour une présentation complète de l'utilitaire SMF, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration. Pour une présentation étape par étape des procédures de l'utilitaire SMF, reportez-vous au Chapitre 19, Managing Services (Tasks) du System Administration Guide: Basic Administration.
OpenSolaris IP Filter nécessite la modification directe des fichiers de configuration.
OpenSolaris IP Filter est installé en tant que composant de OpenSolaris. Par défaut, OpenSolaris IP Filter n'est pas activé lorsque vous venez de terminer l'installation. Pour configurer le filtrage, vous devez modifier les fichiers de configuration et activer manuellement OpenSolaris IP Filter. Pour activer le filtrage, réinitialisez le système ou montez les interfaces à l'aide de la commande ifconfig. Pour de plus amples informations, reportez-vous à la page de manuel ifconfig(1M) Pour obtenir la description des tâches d'activation de OpenSolaris IP Filter, reportez-vous à la section Configuration de Oracle Solaris IP Filter.
Pour gérer OpenSolaris IP Filter, connectez-vous en tant que superutilisateur ou tout rôle permettant de gérer OpenSolaris IP Filter. Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
IPMP (IP Network Multipathing, multiacheminement sur réseau IP) ne prend en charge que le filtrage sans état.
Les configurations Sun Cluster ne prennent pas en charge le filtrage par OpenSolaris IP Filter.
OpenSolaris IP Filter ne prend pas actuellement en charge le filtrage entre les zones.
Oracle Solaris IP Filter peut assurer des services de pare-feu ou de translation d'adresse réseau (NAT, Network Address Translation). Vous pouvez implémenter Oracle Solaris IP Filter en chargeant des fichiers de configuration. Oracle Solaris IP Filter contient un répertoire appelé /etc/ipf. Vous pouvez créer et enregistrer les fichiers de configuration ipf.conf, ipnat.conf et ippool.conf dans le répertoire /etc/ipf. Si ces fichiers existent dans le répertoire /etc/ipf, ils sont automatiquement chargés à l'initialisation. Il est également possible d'enregistrer les fichiers de configuration à un autre emplacement, puis de les charger manuellement. Pour obtenir des exemples de fichiers de configuration, reportez-vous à la section Création et modification des fichiers de configuration Oracle Solaris IP Filter.
Pour gérer le pare-feu, vous devez spécifier des ensembles de règles à l'aide de Oracle Solaris IP Filter et filtrer le trafic réseau en fonction de ces ensembles de règles. Les types d'ensembles de règles suivants sont disponibles :
ensembles de règles de filtrage de paquets ;
ensembles de règles NAT (Network Address Translation, translation d'adresse réseau).
Par ailleurs, il est possible de créer des pools d'adresses pour référencer des groupes d'adresses IP. Ensuite, ces pools peuvent être utilisés dans un ensemble de règles. Les pools d'adresses permettent d'accélérer le traitement des règles. En outre, ils facilitent la gestion des grands groupes d'adresses.
Vous pouvez configurer le filtrage de paquets à l'aide des ensembles de règles de filtrage de paquets. La commande ipf permet d'utiliser les ensembles de règles de filtrage de paquets. Pour plus d'informations sur la commande ipf, reportez-vous à la page de manuel ipf(1M).
Vous pouvez créer des règles de filtrage de paquets via la ligne de commande, à l'aide de la commande ipf ou dans un fichier de configuration de filtrage de paquets. Si vous souhaitez charger les règles de filtrage de paquets à l'initialisation, créez le fichier de configuration /etc/ipf/ipf.conf pour y insérer les règles de filtrage de paquets. Dans le cas contraire, placez le fichier ipf.conf à un autre endroit, puis activez manuellement le filtrage de paquets à l'aide de la commande ipf.
Oracle Solaris IP Filter peut contenir deux ensembles de règles de filtrage de paquets : l'ensemble de règles actives et l'ensemble de règles inactives. Dans la plupart des cas, vous utiliserez l'ensemble de règles actif. Toutefois, la commande ipf -I permet d'appliquer une commande à la liste de règles inactives. Oracle Solaris IP Filter n'utilise pas la liste de règles inactives, sauf si vous la sélectionnez. La liste de règles inactives constitue l'emplacement auquel vous pouvez enregistrer des règles sans affecter le filtrage de paquets actif.
Oracle Solaris IP Filter traite les règles de la liste de règles du début à la fin de la liste de règles configurée et transmet ou bloque le paquet. Oracle Solaris IP Filter utilise un indicateur pour déterminer si un paquet doit être transmis ou non. Il parcourt l'intégralité de l'ensemble de règles et détermine si le paquet doit être transmis ou bloqué, en fonction de la dernière règle correspondante.
Il existe deux exceptions à ce processus. D'une part, si le paquet correspondant à une règle contenant le mot-clé quick, Si une règle inclut le mot-clé quick, l'action associée à cette règle est exécutée et les règles suivantes sont ignorées. D'autre part, si le paquet correspond à une règle contenant le mot-clé group, seules les règles portant l'indicateur de ce group sont vérifiées.
Appliquez la syntaxe suivante pour créer des règles de filtrage de paquets :
action [in|out] option mot-clé, mot-clé...
Chaque règle commence par une action. Oracle Solaris IP Filter applique l'action au paquet si celui-ci correspond à la règle. Les actions habituellement appliquées aux paquets sont répertoriées ci-dessous.
Empêche le paquet de traverser le filtre.
Permet au paquet de traverser le filtre.
Consigne le paquet sans déterminer s'il est bloqué ou transmis. Exécutez la commande ipmon pour afficher le journal.
Inclut le paquet dans les statistiques du filtre. Exécutez la commande ipfstat pour afficher les statistiques.
Le filtre saute nombre règles de filtrage.
Le paquet est authentifié par un programme utilisateur qui valide les informations qu'il contient. Le programme détermine si le paquet est transmis ou bloqué.
Le filtre détermine l'action à effectuer pour un paquet en fonction d'une liste de préauthentification.
Le mot suivant est in ou out. Votre choix détermine si la règle de filtrage de paquets est appliquée à un paquet entrant (in) ou à un paquet sortant (out).
Ensuite, vous pouvez insérer toute une liste d'options. Si vous en utilisez plusieurs, elles doivent être dans l'ordre indiqué ci-dessous.
Consigne le paquet si la règle constitue la dernière règle correspondante. Exécutez la commande ipmon pour afficher le journal.
Exécute la règle contenant l'option quick si un paquet lui correspond. Toute vérification de règle subséquente est interrompue.
Applique la règle uniquement si le paquet entre ou sort via l'interface spécifiée.
Copie le paquet et envoie la copie sur nom-interface vers une adresse IP éventuellement spécifiée.
Déplace le paquet vers une file d'attente sortante sur nom-interface.
Une fois les options spécifiées, vous avez le choix entre plusieurs mots-clés afin de déterminer si le paquet correspond à la règle. Les mots-clés doivent être utilisés dans l'ordre indiqué ci-dessous.
Par défaut, le filtre autorise la transmission de tout paquet ne correspondant à aucune règle du fichier de configuration.
Filtre les paquets en fonction de leur type de service, exprimé sous forme d'entier décimal ou hexadécimal.
Filtre les paquets en fonction de leur durée de vie. La durée de vie d'un paquet est une valeur enregistrée dans celui-ci qui indique la durée pendant laquelle le paquet peut se trouver sur le réseau avant d'être abandonné.
Les paquets correspondant à la règle sont déterminés en fonction d'un protocole spécifique. Vous pouvez employer l'un des noms de protocole spécifiés dans le fichier /etc/protocols ou un nombre décimal représentant le protocole. Le mot-clé tcp/udp peut être utilisé pour filtrer les paquets TCP ou UDP.
Filtre les paquets en fonction des éléments suivants : l'adresse IP source, l'adresse IP de destination et le numéro de port. Le mot-clé all permet d'accepter tous les paquets, quelles que soient leur source et leur destination.
Les paquets correspondant à la règle sont ceux qui sont associés à des attributs spécifiques. Insérez le mot not ou no devant le mot-clé pour indiquer qu'un paquet ne correspond à la règle qu'en l'absence de l'option.
Employé pour TCP afin de filtrer les paquets en fonction des indicateurs TCP définis. Pour plus d'informations sur les indicateurs TCP, reportez-vous à la page de manuel ipf(4).
Filtre les paquets en fonction du type d'ICMP. Ce mot-clé n'est employé que si l'option proto est définie sur icmp et que l'option flags n'est pas utilisée.
Détermine les informations conservées pour le paquet. Les options state et frags sont disponibles comme options-keep. L'option state conserve les informations relatives à la session et peuvent être conservées sur les paquets TCP, UDP et ICMP. L'option frags permet de conserver les informations sur les fragments de paquets et d'appliquer les informations aux fragments suivants. Les options-keep permettent la transmission des paquets correspondant à la règle sans passer par la liste de contrôle d'accès.
Crée un groupe pour les règles de filtrage, désigné par le numéro numéro.
Ajoute la règle au groupe de numéro numéro au lieu du groupe par défaut. Toutes les règles de filtrage sont placées dans le groupe 0 si aucun autre groupe n'est spécifié.
L'exemple suivant illustre la constitution d'une syntaxe de règle de filtrage de paquets pour créer une règle. Pour bloquer le trafic entrant à partir de l'adresse IP 192.168.0.0/16, ajoutez la règle suivante à la liste de règles :
block in quick from 192.168.0.0/16 to any |
Pour obtenir la syntaxe et la grammaire complètes utilisées pour écrire des règles de filtrage de paquets, reportez-vous à la page de manuel ipf(4) Pour une description des tâches de filtrage de paquets, reportez-vous à la section Gestion des ensembles de règles de filtrage de paquets de Oracle Solaris IP Filter. Pour une explication du schéma d'adresse IP (192.168.0.0/16) de l'exemple, reportez-vous au Chapitre 2Planification de votre réseau TCP/IP (tâches).
NAT configure des règles de mappage qui réalisent la translation des adresses IP source et de destination vers d'autres adresses Internet ou intranet. Ces règles modifient les adresses source et de destination des paquets IP entrants et sortants et envoient les paquets. Vous pouvez également utiliser NAT pour rediriger le trafic d'un port à un autre. NAT assure l'intégrité du paquet en cas de modification ou de redirection de celui-ci.
Exécutez la commande ipnat pour utiliser les listes de règles NAT. Pour plus d'informations sur la commande ipnat, reportez-vous à la page de manuel ipnat(1M).
Vous pouvez créer des règles NAT à la ligne de commande, à l'aide de la commande ipnat ou dans un fichier de configuration NAT. Les règles de configuration NAT résident dans le fichier ipnat.conf. Si vous souhaitez charger les règles NAT à l'initialisation, créez le fichier /etc/ipf/ipnat.conf afin d'y insérer les règles NAT. Dans le cas contraire, placez le fichier ipnat.conf à un autre endroit, puis activez manuellement le filtrage de paquets à l'aide de la commande ipnat.
Appliquez la syntaxe ci-dessous pour créer des règles NAT :
commande nom-interface paramètres
Toute règle commence par l'une des commandes ci-dessous :
Mappe une adresse IP ou un réseau IP vers une autre adresse IP ou un autre réseau IP selon un processus circulaire non contrôlé.
Redirige les paquets d'un couple port-adresse IP vers un autre couple port-adresse IP.
Établit une translation d'adresse réseau bidirectionnelle entre une adresse IP externe et une adresse IP interne.
Établit la translation basée sur les adresses IP statiques. Cette commande se base sur un algorithme qui force la translation des adresses vers une plage de destination.
Le mot suivant correspond au nom de l'interface, par exemple hme0.
Ensuite, vous avez le choix entre divers paramètres, afin de définir la configuration NAT. Les paramètres suivants sont disponibles :
Désigne le masque réseau.
Désigne l'adresse cible de la translation de ipmask.
Désigne les protocoles tcp, udp ou tcp/udp, ainsi qu'une plage de numéros de port.
L'exemple suivant illustre la constitution d'une syntaxe de règle NAT pour créer une règle NAT. Pour réécrire un paquet sortant sur le périphérique de0 avec l'adresse source 192.168.1.0/24 et pour afficher son adresse source comme étant 10.1.0.0/16, ajoutez la règle ci-dessous à l'ensemble de règles NAT :
map de0 192.168.1.0/24 -> 10.1.0.0/16 |
Pour obtenir la syntaxe et la grammaire complètes utilisées pour écrire des règles NAT, reportez-vous à la page de manuel ipnat(4).
Les pools d'adresses constituent une référence unique pour nommer un groupe de paires adresse/masque de réseau. Les processus fournis pas les pools d'adresses permettent de trouver plus rapidement les adresses IP correspondant aux règles. En outre, ils facilitent la gestion des grands groupes d'adresses.
Les règles de configuration de pool d'adresses sont définies dans le fichier ippool.conf. Si vous souhaitez charger le fichier de règles de pool d'adresses à l'initialisation, créez le fichier /etc/ipf/ippool.conf afin d'y insérer les règles de pool. Dans le cas contraire, placez le fichier ippool.conf à un autre endroit, puis activez manuellement le filtrage de paquets à l'aide de la commande ippool.
Pour créer un pool d'adresses, appliquez la syntaxe suivante :
table role = role-name type = storage-format number = reference-number |
Définit la référence des adresses.
Spécifie le rôle du pool dans Oracle Solaris IP Filter. À ce stade, vous ne pouvez faire référence qu'au rôle ipf.
Spécifie le format de stockage du pool.
Spécifie le numéro de référence utilisé par la règle de filtrage.
Par exemple, pour faire référence aux groupes d'adresses 10.1.1.1 et 10.1.1.2 et au réseau 192.16.1.0 à l'aide du numéro de pool 13, insérez la règle suivante dans le fichier de configuration de pool d'adresses :
table role = ipf type = tree number = 13 { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };
Ensuite, pour faire référence au numéro de pool 13 dans une règle de filtrage, élaborez une règle similaire à la suivante :
pass in from pool/13 to any |
Vous devez charger le fichier de pool avant de charger les règles contenant une référence au pool. Dans le cas contraire, le pool n'est pas défini, comme indiqué dans la sortie suivante :
# ipfstat -io empty list for ipfilter(out) block in from pool/13(!) to any |
Si vous ajoutez le pool par la suite, l'ensemble de règle du noyau n'est pas mis à jour. Vous devez également recharger le fichier de règles faisant référence au pool.
Pour obtenir la syntaxe et la grammaire complètes utilisées pour écrire des règles de filtrage de paquets, reportez-vous à la page de manuel ippool(4).
À partir de la version Solaris 10 7/07, les crochets de filtre de paquets remplacent le module pfil pour activer Oracle Solaris IP Filter. Dans les versions Oracle Solaris précédentes, une étape de configuration supplémentaire du module pfil était nécessaire pour configurer Oracle Solaris IP Filter. Cette configuration supplémentaire augmentait les risques d'erreurs entraînant le dysfonctionnement de Oracle Solaris IP Filter. L'insertion du module STREAMS pfil entre IP et le pilote de périphérique affectait également les performances. Enfin, le module pfil ne pouvait pas intercepter les paquets entre les zones.
Les crochets de filtre de paquets optimisent la procédure d'activation de Oracle Solaris IP Filter. Grâce à ces crochets, Oracle Solaris IP Filter contrôle les flux de paquet entrants et sortants du système Oracle Solaris à l'aide de seuils de filtre de préroutage (entrants) et de postroutage (sortants).
Avec les crochets de filtre de paquets, le module pfil devient inutile. Par conséquent, les composants suivants associés au module sont également supprimés.
pilote pfil ;
démon pfil ;
service SMF svc:/network/pfil.
Pour obtenir une description des tâches d'activation de Oracle Solaris IP Filter, reportez-vous au Chapitre 26Oracle Solaris IP Filter (tâches).
Le module pfil n'est utilisé avec Oracle Solaris IP Filter que dans les versions Oracle Solaris 10 suivantes :
Solaris 10 3/05 ;
Solaris 10 1/06 ;
Solaris 10 6/06 ;
Solaris 10 11/06.
À partir de la version Solaris 10 7/07, le module pfil a été remplacé par les crochets de filtre de paquets et n'est plus utilisé avec Oracle Solaris IP Filter.
Le module STREAMS pfil est nécessaire pour activer Oracle Solaris IP Filter. Toutefois, Oracle Solaris IP Filter ne contient aucun mécanisme automatique permettant d'empiler le module sur chaque interface. Au lieu de cela, le module STREAMS pfil est géré par le service SMF svc:/network/pfil. Pour activer le filtrage sur une interface réseau, vous devez tout d'abord configurer le fichier pfil.ap. Ensuite, activez le service svc:/network/pfil afin de fournir le module STREAMS pfil à l'interface réseau. Pour activer le module STREAMS, réinitialisez le système ou démontez chacune des interfaces réseau sur lesquelles vous souhaitez réaliser le filtrage, puis remontez-les. Pour activer les capacités de filtrage de paquets IPv6, vous devez monter la version inet6 de l'interface.
Si aucun module pfil n'est trouvé pour les interfaces réseau, les services SMF sont placés en état de maintenance. Cette situation est souvent due à un fichier /etc/ipf/pfil.ap modifié incorrect. Si le service est placé en mode de maintenance, l'occurrence est consignée dans les fichiers journaux de filtrage.
Pour obtenir la description des tâches associées à l'activation de Oracle Solaris IP Filter, reportez-vous à la section Configuration de Oracle Solaris IP Filter.
À partir de la version Solaris 10 6/06, le protocole IPv6 est pris en charge par Oracle Solaris IP Filter. Ce filtrage peut se baser sur l'adresse IPv6 source/de destination, sur les pools contenant des adresses IPv6 et sur les en-têtes d'extension IPv6.
De nombreux aspects de IPv6 sont similaires à IPv4. Toutefois, les en-têtes et tailles des paquets ne sont pas identiques dans les deux versions d'IP, ce qui constitue une considération de poids pour IP Filter. Les paquets IPv6 appelés jumbogrammes contiennent un datagramme de longueur supérieure à 65 535 octets. Oracle Solaris IP Filter ne prend pas en charge les jumbogrammes IPv6. Pour en savoir plus sur les autres fonctionnalités IPv6, reportez-vous à la section Fonctions principales d'IPv6.
Pour plus d'informations sur les jumbogrammes, reportez-vous au document IPv6 Jumbograms, RFC 2675 de l'IETF (Internet Engineering Task Force, groupe d'étude d'ingénierie Internet). [http://www.ietf.org/rfc/rfc2675.txt]
Les tâches IP Filter associées à IPv6 ne sont pas très différentes d'IPv4. La différence la plus notable est l'emploi de l'option -6 avec certaines commandes. Les commandes ipf et ipfstat incluent l'option -6 à utiliser avec le filtrage de paquets IPv6. Appliquez l'option -6 avec la commande ipf pour charger et vider les règles de filtrage de paquets IPv6. Pour afficher les statistiques IPv6, utilisez l'option -6 avec la commande ipfstat. Les commandes ipmon et ippool prennent également en charge IPv6, même si aucune option n'est associée à la prise en charge d'IPv6. La commande ipmon a été optimisée pour autoriser la journalisation des paquets IPv6. La commande ippool prend en charge les pools avec les adresses IPv6. Vous pouvez créer des pools d'adresses IPv4, des pools d'adresses IPv6 et des pools contenant à la fois des adresses IPv4 et IPv6.
Vous pouvez utiliser le fichier ipf6.conf pour créer des jeux de règles de filtrage de paquets pour IPv6. Par défaut, le fichier de configuration ipf6.conf figure dans le répertoire /etc/ipf. Comme pour les autres fichiers de configuration de filtrage, le fichier ipf6.conf se charge automatiquement au cours du processus d'initialisation s'il est stocké dans le répertoire /etc/ipf . Vous pouvez également créer un fichier de configuration IPv6, le conserver à un autre emplacement et le charger manuellement.
NAT ne prend pas en charge IPv6.
Une fois les règles de filtrage de paquets pour IPv6 configurées, activez les capacités de filtrage de paquets IPv6 en montant la version inet6 de l'interface.
Pour plus d'informations sur IPv6, reportez-vous au Chapitre 3Présentation d'IPv6. Pour obtenir une description des tâches associées à l'activation de Oracle Solaris IP Filter, reportez-vous au Chapitre 26Oracle Solaris IP Filter (tâches).
Le tableau suivant répertorie les pages de manuel s'appliquant à Oracle Solaris IP Filter.
Ce chapitre fournit les instructions relatives à chaque étape des tâches Filtre Solaris IP . Pour obtenir des informations générales sur Oracle Solaris IP Filter, reportez-vous au Chapitre 25Oracle Solaris IP Filter (présentation).
Le présent chapitre contient les informations suivantes :
Utilisation des ensembles de règles Oracle Solaris IP Filter
Affichage des statistiques et des informations de Oracle Solaris IP Filter
Utilisation des fichiers journaux de Oracle Solaris IP Filter
Création et modification des fichiers de configuration Oracle Solaris IP Filter
La liste des tâches suivante explique les procédures de la configuration de Oracle Solaris IP Filter.
Tableau 26–1 Configuration de Oracle Solaris IP Filter (liste des tâches)
Tâche |
Description |
Voir |
---|---|---|
Commencez par activer Oracle Solaris IP Filter. |
Par défaut, Oracle Solaris IP Filter n'est pas activé. Activez-le manuellement ou à l'aide des fichiers de configuration disponibles dans le répertoire /etc/ipf/, puis réinitialisez le système. À partir de la version Solaris 10 7/07, des crochets de filtre de paquets remplacent le module pfil pour activer Oracle Solaris IP Filter. | |
Réactivez Oracle Solaris IP Filter. |
Si Oracle Solaris IP Filter est désactivé, vous pouvez le réactiver soit en réinitialisant le système, soit en exécutant la commande ipf. | |
Activation du filtrage de loopback |
Disponible en option, le filtrage de loopback permet, par exemple, de filtrer le trafic entre les zones. |
Cette procédure permet d'activer Oracle Solaris IP Filter sur un système exécutant le SE Solaris 10 7/07 ou une version ultérieure. Si le système exécute une version Oracle Solaris 10 antérieure à la version Solaris 10 7/07, reportez-vous à la section Utilisation du module pfil pour activer Oracle Solaris IP Filter.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Créez un ensemble de règles de filtrage de paquets.
L'ensemble de règles de filtrage de paquets contient les règles de filtrage de paquets utilisées par Oracle Solaris IP Filter. Pour charger les règles de filtrage de paquets à l'initialisation, modifiez le fichier /etc/ipf/ipf.conf afin d'implémenter le filtrage de paquets IPv4. Utilisez le fichier /etc/ipf/ipf6.conf pour les règles de filtrage de paquets IPv6. Si vous ne souhaitez pas charger les règles de filtrage de paquets à l'initialisation, insérez-les dans le fichier de votre choix, puis activez manuellement le filtrage de paquets. Pour plus d'informations sur le filtrage de paquets, reportez-vous à la section Utilisation de la fonctionnalité de filtrage de paquets de Oracle Solaris IP Filter. Pour plus d'informations sur l'utilisation des fichiers de configuration, reportez-vous à la section Création et modification des fichiers de configuration Oracle Solaris IP Filter.
(Facultatif) Créez un fichier de configuration NAT (Network Address Translation, translation d'adresse réseau).
NAT ne prend pas en charge IPv6.
Créez le fichier ipnat.conf si vous souhaitez utiliser la translation d'adresse réseau. Si vous souhaitez charger les règles NAT à l'initialisation, créez le fichier /etc/ipf/ipnat.conf afin d'y insérer les règles NAT. Si vous ne souhaitez pas charger les règles NAT à l'initialisation, placez le fichier ipnat.conf dans le répertoire de votre choix, puis activez manuellement les règles NAT.
Pour plus d'informations sur la fonction NAT (Network Address Translation), reportez-vous à la section Utilisation de la fonctionnalité NAT de Oracle Solaris IP Filter.
(Facultatif) Créez un fichier de configuration de pool d'adresses.
Créez un fichier ipool.conf si vous souhaitez référencer un groupe d'adresses sous la forme d'un pool d'adresses unique. Pour charger le fichier de configuration de pool d'adresses à l'initialisation, créez le fichier /etc/ipf/ippool.conf afin d'y insérer le pool d'adresses. Si vous ne souhaitez pas charger le fichier de configuration de pool d'adresses à l'initialisation, placez le fichier ippool.conf dans le répertoire de votre choix, puis activez manuellement les règles.
Un pool d'adresses peut contenir exclusivement des adresses IPv4 ou exclusivement des adresses IPv6. Il peut également contenir à la fois des adresses IPv4 et des adresses IPv6.
Pour plus d'informations sur les pools d'adresses, reportez-vous à la section Utilisation de la fonctionnalité de pools d'adresses de Oracle Solaris IP Filter.
(Facultatif) Activez le filtrage de trafic en loopback.
Pour filtrer le trafic entre les zones configurées sur le système, le cas échéant, activez le filtrage de loopback. Reportez-vous à la section Activation du filtrage de loopback. Vous devez également définir les ensembles de règles adéquats applicables aux zones.
Activez Oracle Solaris IP Filter.
# svcadm enable network/ipfilter |
Si le filtrage de paquets a été temporairement désactivé, vous pouvez le réactiver.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Activez Oracle Solaris IP Filter et le filtrage selon l'une des méthodes ci-dessous :
Redémarrez l'ordinateur.
# reboot |
Lorsque IP Filter est activé, les fichiers suivants sont chargés après une réinitialisation s'ils sont présents : le fichier /etc/ipf/ipf.conf, le fichier /etc/ipf/ipf6.conf en cas d'utilisation d'IPv6 ou le fichier /etc/ipf/ipnat.conf.
Exécutez les commandes suivantes pour activer Oracle Solaris IP Filter et le filtrage :
Activez Oracle Solaris IP Filter.
# ipf -E |
Activez le filtrage de paquets.
# ipf -f filename |
(Facultatif) Activez NAT.
# ipnat -f filename |
NAT ne prend pas en charge IPv6.
Vous pouvez filtrer le trafic de loopback uniquement si vous exécutez la version Solaris 10 7/07&; ou une version ultérieure. Dans les versions antérieures à Oracle Solaris 10, le filtrage de loopback n'était pas pris en charge.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Arrêtez Oracle Solaris IP Filter, le cas échéant.
# svcadm disable network/ipfilter |
Ajoutez la ligne suivante au début du fichier /etc/ipf.conf ou /etc/ipf6.conf :
set intercept_loopback true; |
Cette ligne doit précéder toutes les règles de filtre IP définies dans le fichier. Toutefois, vous pouvez insérer des commentaires avant la ligne, comme dans l'exemple ci-dessous :
# # Enable loopback filtering to filter between zones # set intercept_loopback true; # # Define policy # block in all block out all <other rules> ... |
Démarrez Oracle Solaris IP Filter.
# svcadm enable network/ipfilter |
Pour vérifier le statut du filtrage de loopback, exécutez la commande ci-dessous :
# ipf —T ipf_loopback ipf_loopback min 0 max 0x1 current 1 # |
Si le filtrage de loopback est désactivé, la commande génère la sortie suivante :
ipf_loopback min 0 max 0x1 current 0 |
Vous pouvez désactiver le filtrage de paquets et NAT pour :
réaliser des tests ;
Pour dépanner des problèmes système dont Oracle Solaris IP Filter semble être à l'origine, procédez comme suit :
La liste des tâches suivante identifie les procédures de désactivation des fonctions de Oracle Solaris IP Filter.
Tableau 26–2 Désactivation de Oracle Solaris IP Filter (liste des tâches)
Tâche |
Description |
Voir |
---|---|---|
Désactivation du filtrage de paquets. |
Désactivez le filtrage de paquets à l'aide de la commande ipf. | |
Désactivation de NAT. |
Désactivez NAT à l'aide de la commande ipnat. | |
Désactivation du filtrage de paquets et de NAT. |
Désactivez le filtrage de paquets et NAT à l'aide de la commande ipf. |
La procédure suivante permet de désactiver le filtrage de paquets Oracle Solaris IP Filter en vidant les règles de filtrage de paquets de l'ensemble de règles de filtrage actif. La procédure ne désactive pas Oracle Solaris IP Filter. Vous pouvez réactiver Oracle Solaris IP Filter en ajoutant des règles à l'ensemble de règles.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Pour désactiver les règles Oracle Solaris IP Filter, utilisez l'une des méthodes suivantes :
Supprimez du noyau l'ensemble de règles actif.
# ipf -Fa |
Cette commande désactive toutes les règles de filtrage de paquets.
Supprimez les règles de filtrage appliquées aux paquets entrants.
# ipf -Fi |
Cette commande désactive les règles de filtrage de paquets appliquées aux paquets entrants.
Supprimez les règles de filtrage appliquées aux paquets sortants.
# ipf -Fo |
Cette commande désactive les règles de filtrage de paquets appliquées aux paquets sortants.
La procédure ci-dessous permet de désactiver les règles NAT de Oracle Solaris IP Filter en les vidant de l'ensemble de règles NAT actif. La procédure ne désactive pas Oracle Solaris IP Filter. Vous pouvez réactiver Oracle Solaris IP Filter en ajoutant des règles à l'ensemble de règles.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Supprimez NAT du noyau.
# ipnat -FC |
L'option -C permet de supprimer toutes les entrées de la liste de règles NAT actuelle. L'option -F permet de supprimer toutes les entrées actives de la table de translation NAT qui indique les mappages NAT actifs.
Lorsque vous exécutez cette procédure, NAT et le filtrage de paquets sont supprimés du noyau. Pour réactiver le filtrage de paquets et NAT après avoir exécuté cette procédure, le cas échéant, vous devez réactiver Filtre Solaris IP . Pour plus d'informations, reportez-vous à la section Réactivation de Oracle Solaris IP Filter.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Désactivez le filtrage de paquets et autorisez la transmission de tous les paquets sur le réseau.
# ipf –D |
La commande ipf -D vide les règles de l'ensemble de règles. Lorsque vous réactivez le filtrage, vous devez ajouter des règles à l'ensemble de règles.
Cette section explique comment utiliser le module STREAMS pfil pour activer ou désactiver Oracle Solaris IP Filter et comment afficher les statistiques pfil. Ces procédures s'appliquent uniquement aux systèmes exécutant l'une des versions de Oracle Solaris 10 suivantes :
Solaris 10 3/05 ;
Solaris 10 1/06 ;
Solaris 10 6/06 ;
Solaris 10 11/06.
La liste des tâches ci-dessous identifie les procédures associées à la configuration du module pfil.
Tableau 26–3 Utilisation du module pfil (liste des tâches)
Tâche |
Description |
Voir |
---|---|---|
Activation de Oracle Solaris IP Filter |
Par défaut, Oracle Solaris IP Filter n'est pas activé. Activez-le manuellement ou à l'aide des fichiers de configuration disponibles dans le répertoire /etc/ipf/, puis réinitialisez le système. |
Activation de Oracle Solaris IP Filter dans des versions antérieures de Oracle Solaris 10 |
Activation d'une NIC pour le filtrage de paquets |
Configurez le module pfil afin d'activer le filtrage de paquets sur une NIC (Network Interface Card, carte d'interface réseau). | |
Désactivation de Oracle Solaris IP Filter sur une carte réseau |
Retirez une NIC et autorisez la transmission de tous les paquets via la NIC. |
Désactivation de Oracle Solaris IP Filter sur une carte réseau |
Affichage des statistiques pfil |
L'affichage des statistiques du module pfil facilite le dépannage de Oracle Solaris IP Filter à l'aide de la commande ndd. |
Oracle Solaris IP Filter est installé avec Oracle Solaris. Toutefois, le filtrage de paquets n'est pas activé par défaut. Pour activer &ProductBase IP Filter, suivez la procédure suivante :
Si votre système exécute la version Solaris 10 7/07 ou une version ultérieure, suivez la procédure Activation de Oracle Solaris IP Filter utilisant des crochets de filtre de paquets.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Ouvrez le fichier /etc/ipf/pfil.ap dans l'éditeur de fichiers de votre choix.
Ce fichier contient les noms des cartes d'interface réseau (NIC, Network Interface Card) présentes sur l'hôte. Par défaut, les noms sont commentés. Annulez le commentaire des noms de périphérique correspondant au trafic réseau que vous souhaitez filtrer. Si la NIC de votre système n'est pas répertoriée, ajoutez une ligne pour la spécifier.
# vi /etc/ipf/pfil.ap # IP Filter pfil autopush setup # # See autopush(1M) manpage for more information. # # Format of the entries in this file is: # #major minor lastminor modules #le -1 0 pfil #qe -1 0 pfil hme -1 0 pfil (Device has been uncommented for filtering) #qfe -1 0 pfil #eri -1 0 pfil #ce -1 0 pfil #bge -1 0 pfil #be -1 0 pfil #vge -1 0 pfil #ge -1 0 pfil #nf -1 0 pfil #fa -1 0 pfil #ci -1 0 pfil #el -1 0 pfil #ipdptp -1 0 pfil #lane -1 0 pfil #dmfe -1 0 pfil |
Activez les modifications apportées au fichier /etc/ipf/pfil.ap en redémarrant l'instance de service network/pfil.
# svcadm restart network/pfil |
Créez un ensemble de règles de filtrage de paquets.
L'ensemble de règles de filtrage de paquets contient les règles de filtrage de paquets utilisées par Oracle Solaris IP Filter. Pour charger les règles de filtrage de paquets à l'initialisation, modifiez le fichier /etc/ipf/ipf.conf afin d'implémenter le filtrage de paquets IPv4. Utilisez le fichier /etc/ipf/ipf6.conf pour les règles de filtrage de paquets IPv6. Si vous ne souhaitez pas charger les règles de filtrage de paquets à l'initialisation, insérez-les dans le fichier de votre choix, puis activez manuellement le filtrage de paquets. Pour plus d'informations sur le filtrage de paquets, reportez-vous à la section Utilisation de la fonctionnalité de filtrage de paquets de Oracle Solaris IP Filter. Pour plus d'informations sur l'utilisation des fichiers de configuration, reportez-vous à la section Création et modification des fichiers de configuration Oracle Solaris IP Filter.
(Facultatif) Créez un fichier de configuration NAT (Network Address Translation, translation d'adresse réseau).
NAT ne prend pas en charge IPv6.
Créez le fichier ipnat.conf si vous souhaitez utiliser la translation d'adresse réseau. Si vous souhaitez charger les règles NAT à l'initialisation, créez le fichier /etc/ipf/ipnat.conf afin d'y insérer les règles NAT. Si vous ne souhaitez pas charger les règles NAT à l'initialisation, placez le fichier ipnat.conf dans le répertoire de votre choix, puis activez manuellement les règles NAT.
Pour plus d'informations sur la fonction NAT (Network Address Translation), reportez-vous à la section Utilisation de la fonctionnalité NAT de Oracle Solaris IP Filter.
(Facultatif) Créez un fichier de configuration de pool d'adresses.
Créez un fichier ipool.conf si vous souhaitez référencer un groupe d'adresses sous la forme d'un pool d'adresses unique. Pour charger le fichier de configuration de pool d'adresses à l'initialisation, créez le fichier /etc/ipf/ippool.conf afin d'y insérer le pool d'adresses. Si vous ne souhaitez pas charger le fichier de configuration de pool d'adresses à l'initialisation, placez le fichier ippool.conf dans le répertoire de votre choix, puis activez manuellement les règles.
Un pool d'adresses peut contenir exclusivement des adresses IPv4 ou exclusivement des adresses IPv6. Il peut également contenir à la fois des adresses IPv4 et des adresses IPv6.
Pour plus d'informations sur les pools d'adresses, reportez-vous à la section Utilisation de la fonctionnalité de pools d'adresses de Oracle Solaris IP Filter.
Activez Oracle Solaris IP Filter selon l'une des méthodes suivantes :
Activez IP Filter et réinitialisez la machine.
# svcadm enable network/ipfilter # reboot |
La réinitialisation est requise si l'exécution des commandes ifconfig unplumb et ifconfig plumb sur les NIC n'est pas sécurisée.
Activez les NIC à l'aide des commandes ifconfig unplumb et ifconfig plumb. Activez ensuite IP Filter. La version inet6 de l'interface doit être montée afin de permettre l'implémentation du filtrage de paquets IPv6.
# ifconfig hme0 unplumb # ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up # ifconfig hme0 inte6 unplumb # ifconfig hme0 inet6 plumb fec3:f849::1/96 up # svcadm enable network/ipfilter |
Pour de plus amples informations sur la commande ifconfig, reportez-vous à la page de manuel ifconfig(1M).
Oracle Solaris IP Filter est activé lors de l'initialisation, lorsque le fichier /etc/ipf/ipf.conf (ou le fichier /etc/ipf/ipf6.conf, si vous utilisez des adresses IPv6) est présent. Si vous devez activer le filtrage sur une carte réseau une fois Oracle Solaris IP Filter activé, suivez la procédure suivante :
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Ouvrez le fichier /etc/ipf/pfil.ap dans l'éditeur de fichiers de votre choix.
Ce fichier contient les noms des NIC présentes sur l'hôte. Par défaut, les noms sont commentés. Annulez le commentaire des noms de périphérique correspondant au trafic réseau que vous souhaitez filtrer. Si la NIC de votre système n'est pas répertoriée, ajoutez une ligne pour la spécifier.
# vi /etc/ipf/pfil.ap # IP Filter pfil autopush setup # # See autopush(1M) manpage for more information. # # Format of the entries in this file is: # #major minor lastminor modules #le -1 0 pfil #qe -1 0 pfil hme -1 0 pfil (Device has been uncommented for filtering) #qfe -1 0 pfil #eri -1 0 pfil #ce -1 0 pfil #bge -1 0 pfil #be -1 0 pfil #vge -1 0 pfil #ge -1 0 pfil #nf -1 0 pfil #fa -1 0 pfil #ci -1 0 pfil #el -1 0 pfil #ipdptp -1 0 pfil #lane -1 0 pfil #dmfe -1 0 pfil |
Activez les modifications apportées au fichier /etc/ipf/pfil.ap en redémarrant l'instance de service network/pfil.
# svcadm restart network/pfil |
Activez la NIC selon l'une des méthodes ci-dessous :
Redémarrez l'ordinateur.
# reboot |
La réinitialisation est requise si l'exécution des commandes ifconfig unplumb et ifconfig plumb sur les NIC n'est pas sécurisée.
Activez les NIC à filtrer à l'aide de la commande ifconfig avec les options unplumb et plumb. La version inet6 de chaque interface doit être montée afin de permettre l'implémentation du filtrage de paquets IPv6.
# ifconfig hme0 unplumb # ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up # ifconfig hme0 inet6 unplumb # ifconfig hme0 inet6 plumb fec3:f840::1/96 up |
Pour de plus amples informations sur la commande ifconfig, reportez-vous à la page de manuel ifconfig(1M).
Pour arrêter le filtrage des paquets sur une NIC, le cas échéant, suivez la procédure ci-dessous.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Ouvrez le fichier /etc/ipf/pfil.ap dans l'éditeur de fichiers de votre choix.
Ce fichier contient les noms des NIC présentes sur l'hôte. Le commentaire des NIC utilisées pour filtrer le trafic réseau est annulé. Commentez les noms des périphériques que vous ne souhaitez plus utiliser pour filtrer le trafic réseau.
# vi /etc/ipf/pfil.ap # IP Filter pfil autopush setup # # See autopush(1M) manpage for more information. # # Format of the entries in this file is: # #major minor lastminor modules #le -1 0 pfil #qe -1 0 pfil #hme -1 0 pfil (Commented-out device no longer filters network traffic) #qfe -1 0 pfil #eri -1 0 pfil #ce -1 0 pfil #bge -1 0 pfil #be -1 0 pfil #vge -1 0 pfil #ge -1 0 pfil #nf -1 0 pfil #fa -1 0 pfil #ci -1 0 pfil #el -1 0 pfil #ipdptp -1 0 pfil #lane -1 0 pfil #dmfe -1 0 pfil |
Désactivez la NIC selon l'une des méthodes ci-dessous :
Redémarrez l'ordinateur.
# reboot |
La réinitialisation est requise si l'exécution des commandes ifconfig unplumb et ifconfig plumb sur les NIC n'est pas sécurisée.
Désactivez les NIC à l'aide de la commande ifconfig avec les options unplumb et plumb. La version inet6 de chaque interface doit être démontée afin de permettre la désactivation du filtrage de paquets IPv6. Procédez comme suit. Le périphérique système hme est utilisé en exemple :
Identifiez le numéro majeur du périphérique à désactiver.
# grep hme /etc/name_to_major hme 7 |
Affichez la configuration autopush actuelle pour hme0.
# autopush -g -M 7 -m 0 Major Minor Lastminor Modules 7 ALL - pfil |
Supprimez la configuration autopush.
# autopush -r -M 7 -m 0 |
Ouvrez le périphérique et attribuez les adresses IP au périphérique.
# ifconfig hme0 unplumb # ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up # ifconfig hme0 inet6 unplumb # ifconfig hme0 inet6 plumb fec3:f840::1/96 up |
Pour de plus amples informations sur la commande ifconfig, reportez-vous à la page de manuel ifconfig(1M).
Vous pouvez afficher les statistiques pfil lors du dépannage de Oracle Solaris IP Filter.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichage des statistiques pfil
# ndd -get /dev/pfil qif_status |
L'exemple ci-dessous illustre l'affichage des statistiques pfil.
# ndd -get /dev/pfil qif_status ifname ill q OTHERQ num sap hl nr nw bad copy copyfail drop notip nodata notdata QIF6 0 300011247b8 300011248b0 6 806 0 4 9 0 0 0 0 0 0 0 dmfe1 3000200a018 30002162a50 30002162b48 5 800 14 171 13681 0 0 0 0 0 0 0 |
La liste des tâches ci-dessous identifie les procédures des ensembles de règles Oracle Solaris IP Filter.
Tableau 26–4 Utilisation des ensembles de règles Oracle Solaris IP Filter (liste des tâches)
Tâche |
Description |
Voir |
---|---|---|
Gestion, affichage et modification des ensembles de règles pour le filtrage de paquets Oracle Solaris IP Filter |
Gestion des ensembles de règles de filtrage de paquets de Oracle Solaris IP Filter |
|
Affichez un ensemble de règles actif pour le filtrage de paquets. |
Affichage de l'ensemble actif de règles de filtrage de paquets |
|
Affichez un ensemble de règles inactif pour le filtrage de paquets. |
Affichage de l'ensemble inactif de règles de filtrage de paquets |
|
Activez un nouvel ensemble de règles actif. |
Activation d'un nouvel ensemble de règles de filtrage de paquets ou d'un ensemble mis à jour |
|
Supprimez un ensemble de règles. | ||
Ajoutez des règles aux ensembles de règles. |
Ajout de règles à l'ensemble actif de règles de filtrage de paquets Ajout de règles à l'ensemble inactif de règles de filtrage de paquets |
|
Basculez entre les ensembles de règles actif et inactif. |
Basculement entre les ensembles actif et inactif de règles de filtrage de paquets |
|
Supprimez du noyau un ensemble de règles inactif. |
Suppression d'un ensemble inactif de règles de filtrage de paquets du noyau |
|
Gestion, affichage et modification des règles NAT de Oracle Solaris IP Filter | ||
Affichez les règles NAT actives. | ||
Supprimez les règles NAT. | ||
Ajoutez des règles aux règles NAT. | ||
Gestion, affichage et modification des pools d'adresses de Oracle Solaris IP Filter | ||
Affichez les pools d'adresses actifs. | ||
Supprimez un pool d'adresses. | ||
Ajoutez des règles à un pool d'adresses. |
Lorsque Filtre Solaris IP est activé, les ensembles actif et inactif de règles de filtrage de paquets peuvent résider dans le noyau. L'ensemble de règles actif détermine le filtrage appliqué aux paquets entrants et aux paquets sortants. L'ensemble de règles inactif contient également des règles. Ces règles ne sont pas appliquées, sauf si vous définissez l'ensemble de règles inactif comme l'ensemble de règles actif. Vous pouvez gérer, afficher et modifier les ensembles actif et inactif de règles de filtrage de paquets.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez l'ensemble actif de règles de filtrage de paquets chargé dans le noyau.
# ipfstat -io |
L'exemple ci-dessous présente la sortie de l'ensemble actif de règles de filtrage de paquets chargé dans le noyau.
# ipfstat -io empty list for ipfilter(out) pass in quick on dmfe1 from 192.168.1.0/24 to any pass in all block in on dmfe1 from 192.168.1.10/32 to any |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez l'ensemble inactif de règles de filtrage de paquets.
# ipfstat -I -io |
L'exemple ci-dessous présente la sortie d'un ensemble inactif de règles de filtrage de paquets.
# ipfstat -I -io pass out quick on dmfe1 all pass in quick on dmfe1 all |
Effectuez la procédure ci-dessous pour exécuter l'une ou l'autre des tâches suivantes :
activation d'un ensemble de règles de filtrage de paquets différent de celui utilisé actuellement par Oracle Solaris IP Filter ;
rechargement du même ensemble de règles de filtrage mis à jour.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Procédez de l'une des façons suivantes :
Si vous souhaitez activer un ensemble de règles complètement différent, créez-le dans un fichier distinct.
Pour mettre à jour l'ensemble de règles actuel, modifiez le fichier de configuration contenant l'ensemble de règles.
Supprimez l'ensemble de règles actuel et chargez le nouvel ensemble de règles.
# ipf -Fa -f filename |
La variable fichier peut correspondre à un fichier contenant un ensemble de règles complètement différent, ou au fichier contenant l'ensemble de règles actif, mis à jour.
L'ensemble de règles actif est supprimé du noyau. Les règles du fichier constituent dorénavant l'ensemble de règles actif.
Même si vous rechargez le fichier de configuration actuel, vous devez exécuter la commande. Dans le cas contraire, le système ignore l'ensemble de règles modifié défini dans le fichier de configuration mis à jour et continue d'appliquer l'ancien ensemble de règles.
N'utilisez pas de commandes telles que ipf -D ou svcadm restart pour charger l'ensemble de règles mis à jour. Ces commandes affectent la sécurité du réseau, car elles désactivent le pare-feu avant de charger le nouvel ensemble de règles.
Dans l'exemple ci-dessous, un ensemble de règles de filtrage de paquets est remplacé par un autre ensemble se trouvant dans un fichier de configuration distinct, /etc/ipf/ipf.conf.
# ipfstat -io empty list for ipfilter(out) pass in quick on dmfe all # ipf -Fa -f /etc/ipf/ipf.conf # ipfstat -io empty list for ipfilter(out) block in log quick from 10.0.0.0/8 to any |
Dans l'exemple ci-dessous, un ensemble de règles de filtrage de paquets actuellement actif est rechargé suite à sa mise à jour. Dans cet exemple, le fichier utilisé est /etc/ipf/ipf.conf.
# ipfstat -io (Optional) empty list for ipfilter (out) block in log quick from 10.0.0.0/8 to any (Edit the /etc/ipf/ipf.conf configuration file.) # ip -Fa -f /etc/ipf/ipf.conf # ipfstat -io (Optional) empty list for ipfilter (out) block in log quick from 10.0.0.0/8 to any block in quick on elx10 from 192.168.0.0/12 to any |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Supprimez l'ensemble de règles.
# ipf -F [a|i|o] |
Supprime toutes les règles de filtrage de l'ensemble de règles.
Supprime les règles de filtrage pour les paquets entrants.
Supprime les règles de filtrage pour les paquets sortants.
Dans l'exemple ci-dessous, toutes les règles de filtrage sont supprimées de l'ensemble de règles de filtrage actif.
# ipfstat -io block out log on dmf0 all block in log quick from 10.0.0.0/8 to any # ipf -Fa # ipfstat -io empty list for ipfilter(out) empty list for ipfilter(in) |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Appliquez l'une des méthodes ci-dessous pour ajouter des règles à l'ensemble de règles actif :
Pour ajouter des règles à l'ensemble de règles via la ligne de commande, exécutez la commande ipf -f -.
# echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f - |
Exécutez les commandes ci-dessous :
Créez un ensemble de règles dans le fichier de votre choix.
Ajoutez ces règles à l'ensemble de règles actif.
# ipf -f filename |
Les règles présentes dans le fichier sont ajoutées à la fin de l'ensemble de règles actif. Filtre Solaris IP appliquant un algorithme de type "dernière règle correspondante", les nouvelles règles déterminent les priorités de filtrage, sauf si l'utilisateur ajoute le mot-clé quick. Si le paquet correspond à une règle contenant le mot-clé quick, l'action associée à cette règle est exécutée et les règles suivantes sont ignorées.
Dans l'exemple ci-dessous, une règle est ajoutée à l'ensemble actif de règles de filtrage de paquets à partir de la ligne de commande.
# ipfstat -io empty list for ipfilter(out) block in log quick from 10.0.0.0/8 to any # echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f - # ipfstat -io empty list for ipfilter(out) block in log quick from 10.0.0.0/8 to any block in on dmfe1 proto tcp from 10.1.1.1/32 to any |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Créez un ensemble de règles dans le fichier de votre choix.
Ajoutez ces règles à l'ensemble de règles inactif.
# ipf -I -f filename |
Les règles présentes dans le fichier sont ajoutées à la fin de l'ensemble de règles inactif. Filtre Solaris IP appliquant un algorithme de type "dernière règle correspondante", les nouvelles règles déterminent les priorités de filtrage, sauf si l'utilisateur ajoute le mot-clé quick. Si le paquet correspond à une règle contenant le mot-clé quick, l'action associée à cette règle est exécutée et les règles suivantes sont ignorées.
Dans l'exemple ci-dessous, une règle est ajoutée à l'ensemble de règles inactif à partir d'un fichier.
# ipfstat -I -io pass out quick on dmfe1 all pass in quick on dmfe1 all # ipf -I -f /etc/ipf/ipf.conf # ipfstat -I -io pass out quick on dmfe1 all pass in quick on dmfe1 all block in log quick from 10.0.0.0/8 to any |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Basculez entre les ensembles de règles actif et inactif.
# ipf -s |
Cette commande permet de basculer entre les ensembles de règles actif et inactif dans le noyau. Si l'ensemble de règles inactif est vide, aucun filtrage de paquets n'est effectué.
Dans l'exemple ci-dessous, la commande ipf -s est exécutée. L'ensemble de règles inactif devient alors l'ensemble de règles actif, tandis que l'ensemble de règles actif devient l'ensemble de règles inactif.
Avant l'exécution de la commande ipf -s, la sortie de la commande ipfstat -I -io permet d'afficher les règles de l'ensemble de règles inactif. La sortie de la commande ipfstat -io affiche les règles de l'ensemble de règles actif.
# ipfstat -io empty list for ipfilter(out) block in log quick from 10.0.0.0/8 to any block in on dmfe1 proto tcp from 10.1.1.1/32 to any # ipfstat -I -io pass out quick on dmfe1 all pass in quick on dmfe1 all block in log quick from 10.0.0.0/8 to any |
Une fois la commande ipf -s exécutée, les sorties des commandes ipfstat -I -io et ipfstat -io indiquent que le contenu des deux ensembles de règles a été échangé.
# ipf -s Set 1 now inactive # ipfstat -io pass out quick on dmfe1 all pass in quick on dmfe1 all block in log quick from 10.0.0.0/8 to any # ipfstat -I -io empty list for inactive ipfilter(out) block in log quick from 10.0.0.0/8 to any block in on dmfe1 proto tcp from 10.1.1.1/32 to any |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Spécifiez l'ensemble de règles inactif via la commande "flush all".
# ipf -I -Fa |
Cette commande vide l'ensemble de règles inactif du noyau.
Si vous exécutez ensuite la commande ipf -s, l'ensemble de règles inactif vide devient l'ensemble de règles actif. Si l'ensemble de règles actif est vide, aucun filtrage n'est effectué.
Dans l'exemple ci-dessous, l'ensemble inactif de règles de filtrage de paquets est vidé afin de supprimer toutes les règles.
# ipfstat -I -io empty list for inactive ipfilter(out) block in log quick from 10.0.0.0/8 to any block in on dmfe1 proto tcp from 10.1.1.1/32 to any # ipf -I -Fa # ipfstat -I -io empty list for inactive ipfilter(out) empty list for inactive ipfilter(in) |
Appliquez les procédures ci-dessous pour gérer, afficher et modifier les règles NAT.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez les règles NAT actives.
# ipnat -l |
L'exemple ci-dessous présente la sortie de l'ensemble de règles NAT actif.
# ipnat -l List of active MAP/Redirect filters: map dmfe0 192.168.1.0/24 -> 20.20.20.1/32 List of active sessions: |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Supprimez les règles NAT actuelles.
# ipnat -C |
Dans l'exemple ci-dessous, les entrées des règles NAT actuelles sont supprimées.
# ipnat -l List of active MAP/Redirect filters: map dmfe0 192.168.1.0/24 -> 20.20.20.1/32 List of active sessions: # ipnat -C 1 entries flushed from NAT list # ipnat -l List of active MAP/Redirect filters: List of active sessions: |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Appliquez l'une des méthodes ci-dessous pour ajouter des règles à l'ensemble de règles actif :
Pour ajouter des règles à l'ensemble de règles NAT via la ligne de commande, exécutez la commande ipnat -f -.
# echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f - |
Exécutez les commandes ci-dessous :
Créez des règles NAT supplémentaires dans le fichier de votre choix.
Ajoutez ces règles aux règles NAT actives.
# ipnat -f filename |
Les règles présentes dans le fichier sont ajoutées à la fin des règles NAT.
Dans l'exemple ci-dessous, une règle est ajoutée à l'ensemble de règles NAT via la ligne de commande.
# ipnat -l List of active MAP/Redirect filters: List of active sessions: # echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f - # ipnat -l List of active MAP/Redirect filters: map dmfe0 192.168.1.0/24 -> 20.20.20.1/32 List of active sessions: |
Appliquez les procédures ci-dessous pour gérer, afficher et modifier les pools d'adresses.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez le pool d'adresses actif.
# ippool -l |
Dans l'exemple ci-dessous, le contenu du pool d'adresses actif est affiché.
# ippool -l table role = ipf type = tree number = 13 { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; }; |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Supprimez les entrées du pool d'adresses actuel.
# ippool -F |
Dans l'exemple ci-dessous, un pool d'adresses est supprimé.
# ippool -l table role = ipf type = tree number = 13 { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; }; # ippool -F 1 object flushed # ippool -l |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Appliquez l'une des méthodes ci-dessous pour ajouter des règles à l'ensemble de règles actif :
Pour ajouter des règles à l'ensemble de règles via la ligne de commande, exécutez la commande ippool -f -.
# echo "table role = ipf type = tree number = 13 {10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24};" | ippool -f - |
Exécutez les commandes ci-dessous :
Créez des pools d'adresses supplémentaires dans le fichier de votre choix.
Ajoutez ces règles au pool d'adresses actif.
# ippool -f filename |
Les règles présentes dans le fichier sont ajoutées à la fin du pool d'adresses actif.
Dans l'exemple ci-dessous, un pool d'adresses est ajouté à l'ensemble de règles de pool d'adresses via la ligne de commande.
# ippool -l table role = ipf type = tree number = 13 { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; }; # echo "table role = ipf type = tree number = 100 {10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24};" | ippool -f - # ippool -l table role = ipf type = tree number = 100 { 10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24; }; table role = ipf type = tree number = 13 { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; }; |
Tâche |
Description |
Voir |
---|---|---|
Affichage des tables d'état |
Affichez les tables d'état pour obtenir des informations sur le filtrage de paquets à l'aide de la commande ipfstat. | |
Affichage des statistiques d'état |
Affichez les statistiques relatives à l'état des paquets à l'aide de la commande ipfstat - s. |
Affichage des tables de statistiques de Oracle Solaris IP Filter |
Affichage des statistiques NAT |
Affichez les statistiques NAT à l'aide de la commande ipnat -s. |
Affichage des tables de statistiques de Oracle Solaris IP Filter |
Affichage des statistiques de pool d'adresses |
Affichez les statistiques de pool d'adresses à l'aide de la commande ippool -s. |
Affichage des statistiques de pool d'adresses de Oracle Solaris IP Filter |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez la table d'état.
# ipfstat |
L'option -t permet d'afficher la table d'état au format de l'utilitaire top.
Dans l'exemple ci-dessous, une table d'état est affichée.
# ipfstat bad packets: in 0 out 0 input packets: blocked 160 passed 11 nomatch 1 counted 0 short 0 output packets: blocked 0 passed 13681 nomatch 6844 counted 0 short 0 input packets logged: blocked 0 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 0 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 0 lost 0 packet state(out): kept 0 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Invalid source(in): 0 Result cache hits(in): 152 (out): 6837 IN Pullups succeeded: 0 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 IPF Ticks: 14341469 Packet log flags set: (0) none |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez les statistiques d'état.
# ipfstat -s |
Dans l'exemple ci-dessous, les statistiques d'état sont affichées.
# ipfstat -s IP states added: 0 TCP 0 UDP 0 ICMP 0 hits 0 misses 0 maximum 0 no memory 0 max bucket 0 active 0 expired 0 closed State logging enabled State table bucket statistics: 0 in use 0.00% bucket usage 0 minimal length 0 maximal length 0.000 average length |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichage des statistiques NAT
# ipnat -s |
Dans l'exemple ci-dessous, les statistiques NAT sont affichées.
# ipnat -s mapped in 0 out 0 added 0 expired 0 no memory 0 bad nat 0 inuse 0 rules 1 wilds 0 |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichage des statistiques de pool d'adresses
# ippool -s |
Dans l'exemple ci-dessous, les statistiques de pool d'adresses sont affichées.
# ippool -s Pools: 3 Hash Tables: 0 Nodes: 0 |
Tâche |
Description |
Voir |
---|---|---|
Création d'un fichier journal |
Créez un fichier journal Oracle Solaris IP Filter distinct. |
Configuration d'un fichier journal de Oracle Solaris IP Filter |
Affichage des fichiers journaux |
Affichez le fichier journal normal et les fichiers journaux d'état et NAT à l'aide de la commande ipmon. | |
Vidage du tampon de journalisation des paquets |
Supprimez le contenu du tampon de journalisation des paquets à l'aide de la commande ipmon - F. | |
Enregistrement des paquets consignés dans un fichier |
Les paquets consignés peuvent être enregistrés dans un fichier afin d'être consultés par la suite. |
Par défaut, toutes les informations des journaux de Oracle Solaris IP Filter sont enregistrées dans le fichier syslogd. Configurez un fichier journal afin de séparer les informations de trafic Oracle Solaris IP Filter enregistrées des autres données susceptibles d'être consignées dans le fichier journal par défaut. Procédez comme suit.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Ajoutez les lignes suivantes au fichier /etc/syslog.conf :
# Save IPFilter log output to its own file local0.debug /var/log/log-name |
Sur la deuxième ligne, séparez local0.debug de /var/log/ journal à l'aide de la touche de tabulation (non la barre d'espace).
Créez le fichier journal.
# touch /var/log/log-name |
Redémarrez le service de journal système.
# svcadm restart system-log |
Dans l'exemple ci-dessous, le fichier ipmon.log est créé pour archiver les informations IP Filter.
Dans /etc/syslog.conf :
# Save IPFilter log output to its own file local0.debug /var/log/ipmon.log |
Sur la ligne de commande :
# touch /var/log/ipmon.log # svcadm restart system-log |
Il est conseillé de créer un fichier journal distinct pour enregistrer les données Oracle Solaris IP Filter. Reportez-vous à la section Configuration d'un fichier journal de Oracle Solaris IP Filter.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Affichez le fichier journal normal, le fichier journal NAT ou le fichier journal d'état. Pour afficher un fichier journal, tapez la commande ci-dessous, conjointement avec l'option adéquate :
# ipmon -o [S|N|I] filename |
Affiche le fichier journal d'état.
Affiche le fichier journal NAT.
Affiche le fichier journal IP normal.
Pour afficher le fichier journal normal et les fichiers journaux d'état et NAT, appliquez les options :
# ipmon -o SNI filename |
Si, dans un premier temps, vous avez arrêté manuellement le démon ipmon, vous pouvez également exécuter la commande suivante pour afficher le fichier journal de Oracle Solaris IP Filter et les fichiers journaux d'état et NAT :
# ipmon -a filename |
N'utilisez pas la syntaxe ipmon -a si le démon ipmon est en cours d'exécution. Normalement, le démon démarre automatiquement à l'initialisation du système. Si vous exécutez la commande ipmon -a, une autre copie de ipmon s'ouvre également. Dans ce cas, les deux copies lisent les mêmes informations de journal, mais tout message du journal n'est reçu que par l'une d'elles.
Pour plus d'informations sur l'affichage des fichiers journaux, reportez-vous à la page de manuel ipmon(1M).
L'exemple ci-dessous présente la sortie du fichier /var/ipmon.log.
# ipmon -o SNI /var/ipmon.log 02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 129.146.157.145 PR icmp len 20 84 icmp echo/0 IN |
ou
# pkill ipmon # ipmon -aD /var/ipmon.log 02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 129.146.157.145 PR icmp len 20 84 icmp echo/0 IN |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Videz le tampon de journalisation des paquets.
# ipmon -F |
L'exemple ci-dessous présente la sortie obtenue en cas de suppression d'un fichier journal. Le système génère un rapport même si le fichier journal est vide, comme dans cet exemple.
# ipmon -F 0 bytes flushed from log buffer 0 bytes flushed from log buffer 0 bytes flushed from log buffer |
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Enregistrez dans un fichier les paquets consignés.
# cat /dev/ipl > filename |
Continuez la journalisation des paquets dans le fichier et interrompez la procédure en tapant Ctrl-C pour afficher de nouveau l'invite de ligne de commande.
L'exemple ci-dessous présente les résultats obtenus lorsque les paquets consignés sont enregistrés dans un fichier.
# cat /dev/ipl > /tmp/logfile ^C# # ipmon -f /tmp/logfile 02/09/2004 15:30:28.708294 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 52 -S IN 02/09/2004 15:30:28.708708 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 40 -A IN 02/09/2004 15:30:28.792611 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 70 -AP IN 02/09/2004 15:30:28.872000 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 40 -A IN 02/09/2004 15:30:28.872142 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 43 -AP IN 02/09/2004 15:30:28.872808 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 40 -A IN 02/09/2004 15:30:28.872951 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 47 -AP IN 02/09/2004 15:30:28.926792 hme0 @0:1 p 129.146.157.149,33923 -> 129.146.157.145,23 PR tcp len 20 40 -A IN . . (output truncated) |
Vous devez modifier directement les fichiers de configuration afin de créer et modifier les ensembles de règles et les pools d'adresses. Les fichiers de configuration suivent les règles de syntaxe UNIX standard :
Le signe dièse (#) indique qu'une ligne contient des commentaires.
Une ligne peut contenir à la fois des commentaires et des règles.
Vous pouvez ajouter des espaces supplémentaires afin de faciliter la lecture des règles.
La définition d'une règle peut s'étaler sur plusieurs lignes. Insérez un backslash (\) à la fin d'une ligne pour indiquer que la règle continue sur la ligne suivante.
La procédure ci-dessous décrit la configuration des :
fichiers de configuration de filtrage de paquets ;
fichiers de configuration des règles NAT ;
fichiers de configuration de pool d'adresses.
Connectez-vous en tant que superutilisateur ou prenez un rôle bénéficiant du profil des droits de gestion IP Filter.
Vous pouvez créer un rôle et lui attribuer le profil de droits de gestion IP Filter. Pour créer un rôle et l'attribuer à un utilisateur, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Lancez l'éditeur de fichiers de votre choix. Créez et modifiez le fichier de configuration de la fonction que vous souhaitez configurer.
Pour créer un fichier de configuration des règles de filtrage de paquets, modifiez le fichier ipf.conf.
Oracle Solaris IP Filter utilise les règles de filtrage de paquets spécifiées dans le fichier ipf.conf. Si vous placez le fichier de règles de filtrage de paquets dans le fichier /etc/ipf/ipf.conf, ce fichier est chargé à l'initialisation du système. Pour empêcher le chargement des règles de filtrage à l'initialisation, le cas échéant, placez-les dans le fichier de votre choix. Vous pouvez ensuite activer les règles à l'aide de la commande ipf, comme décrit à la section Activation d'un nouvel ensemble de règles de filtrage de paquets ou d'un ensemble mis à jour.
Pour plus d'informations sur la création de règles de filtrage de paquets, reportez-vous à la section Utilisation de la fonctionnalité de filtrage de paquets de Oracle Solaris IP Filter.
Si le fichier ipf.conf est vide, aucun filtrage n'est appliqué. Un fichier ipf.conf vide correspond à un ensemble de règles défini comme suit :
pass in all pass out all |
Pour créer un fichier de configuration des règles NAT, modifiez le fichier ipnat.conf.
&ProductBase IP Filter utilise les règles NAT spécifiées dans le fichier ipnat.conf. Si vous placez le fichier de règles NAT dans le fichier >/etc/ipf/ipnat.conf, ce fichier est chargé à l'initialisation du système. Pour empêcher le chargement des règles NAT à l'initialisation, le cas échéant, placez le fichier ipnat.conf dans le dossier de votre choix. Ensuite, vous pouvez activer les règles NAT à l'aide de la commande ipnat.
Pour plus d'informations sur la création de règles NAT, reportez-vous à la section Utilisation de la fonctionnalité NAT de Oracle Solaris IP Filter.
Pour créer un fichier de configuration des pools d'adresses, modifiez le fichier ippool.conf.
Oracle Solaris IP Filter utilise le pool d'adresses spécifié dans le fichier ippool.conf. Si vous placez le fichier de règles du pool d'adresses dans le fichier /etc/ipf/ippool.conf, ce fichier est chargé à l'initialisation du système. Pour empêcher le chargement du pool d'adresses à l'initialisation, le cas échéant, placez le fichier ippool.conf dans le dossier de votre choix. Ensuite, vous pouvez activer le pool d'adresses à l'aide de la commande ippool.
Pour plus d'informations sur la création de pools d'adresses, reportez-vous à la section Utilisation de la fonctionnalité de pools d'adresses de Oracle Solaris IP Filter.
Les exemples ci-dessous illustrent les règles de filtrage de paquets utilisées dans les configurations de filtrage.
Cet exemple correspond à une configuration définie sur une machine hôte avec une interface réseau elxl.
# pass and log everything by default pass in log on elxl0 all pass out log on elxl0 all # block, but don't log, incoming packets from other reserved addresses block in quick on elxl0 from 10.0.0.0/8 to any block in quick on elxl0 from 172.16.0.0/12 to any # block and log untrusted internal IPs. 0/32 is notation that replaces # address of the machine running Solaris IP Filter. block in log quick from 192.168.1.15 to <thishost> block in log quick from 192.168.1.43 to <thishost> # block and log X11 (port 6000) and remote procedure call # and portmapper (port 111) attempts block in log quick on elxl0 proto tcp from any to elxl0/32 port = 6000 keep state block in log quick on elxl0 proto tcp/udp from any to elxl0/32 port = 111 keep state |
Cet ensemble de règles commence par deux règles illimitées qui permettent à tout type de données d'entrer et sortir via l'interface elxl. Le deuxième ensemble de règles empêche tout paquet entrant issu des espaces d'adresses privées 10.0.0.0 et 172.16.0.0 de traverser la pare-feu. L'ensemble de règles suivant bloque des adresses internes spécifiques de la machine hôte. Enfin, le dernier ensemble de règles empêche l'entrée des paquets via les ports 6000 et 111.
Cet exemple présente la configuration d'une machine hôte tenant lieu de serveur Web. Cette machine possède une interface réseau eri.
# web server with an eri interface # block and log everything by default; then allow specific services # group 100 - inbound rules # group 200 - outbound rules # (0/32) resolves to our IP address) *** FTP proxy *** # block short packets which are packets fragmented too short to be real. block in log quick all with short # block and log inbound and outbound by default, group by destination block in log on eri0 from any to any head 100 block out log on eri0 from any to any head 200 # web rules that get hit most often pass in quick on eri0 proto tcp from any \ to eri0/32 port = http flags S keep state group 100 pass in quick on eri0 proto tcp from any \ to eri0/32 port = https flags S keep state group 100 # inbound traffic - ssh, auth pass in quick on eri0 proto tcp from any \ to eri0/32 port = 22 flags S keep state group 100 pass in log quick on eri0 proto tcp from any \ to eri0/32 port = 113 flags S keep state group 100 pass in log quick on eri0 proto tcp from any port = 113 \ to eri0/32 flags S keep state group 100 # outbound traffic - DNS, auth, NTP, ssh, WWW, smtp pass out quick on eri0 proto tcp/udp from eri0/32 \ to any port = domain flags S keep state group 200 pass in quick on eri0 proto udp from any port = domain to eri0/32 group 100 pass out quick on eri0 proto tcp from eri0/32 \ to any port = 113 flags S keep state group 200 pass out quick on eri0 proto tcp from eri0/32 port = 113 \ to any flags S keep state group 200 pass out quick on eri0 proto udp from eri0/32 to any port = ntp group 200 pass in quick on eri0 proto udp from any port = ntp to eri0/32 port = ntp group 100 pass out quick on eri0 proto tcp from eri0/32 \ to any port = ssh flags S keep state group 200 pass out quick on eri0 proto tcp from eri0/32 \ to any port = http flags S keep state group 200 pass out quick on eri0 proto tcp from eri0/32 \ to any port = https flags S keep state group 200 pass out quick on eri0 proto tcp from eri0/32 \ to any port = smtp flags S keep state group 200 # pass icmp packets in and out pass in quick on eri0 proto icmp from any to eri0/32 keep state group 100 pass out quick on eri0 proto icmp from eri0/32 to any keep state group 200 # block and ignore NETBIOS packets block in quick on eri0 proto tcp from any \ to any port = 135 flags S keep state group 100 block in quick on eri0 proto tcp from any port = 137 \ to any flags S keep state group 100 block in quick on eri0 proto udp from any to any port = 137 group 100 block in quick on eri0 proto udp from any port = 137 to any group 100 block in quick on eri0 proto tcp from any port = 138 \ to any flags S keep state group 100 block in quick on eri0 proto udp from any port = 138 to any group 100 block in quick on eri0 proto tcp from any port = 139 to any flags S keep state group 100 block in quick on eri0 proto udp from any port = 139 to any group 100 |
Cet exemple présente la configuration d'un routeur possédant une interface interne, ce0, et une interface externe, ce1.
# internal interface is ce0 at 192.168.1.1 # external interface is ce1 IP obtained via DHCP # block all packets and allow specific services *** NAT *** *** POOLS *** # Short packets which are fragmented too short to be real. block in log quick all with short # By default, block and log everything. block in log on ce0 all block in log on ce1 all block out log on ce0 all block out log on ce1 all # Packets going in/out of network interfaces that aren't on the loopback # interface should not exist. block in log quick on ce0 from 127.0.0.0/8 to any block in log quick on ce0 from any to 127.0.0.0/8 block in log quick on ce1 from 127.0.0.0/8 to any block in log quick on ce1 from any to 127.0.0.0/8 # Deny reserved addresses. block in quick on ce1 from 10.0.0.0/8 to any block in quick on ce1 from 172.16.0.0/12 to any block in log quick on ce1 from 192.168.1.0/24 to any block in quick on ce1 from 192.168.0.0/16 to any # Allow internal traffic pass in quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24 pass out quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24 # Allow outgoing DNS requests from our servers on .1, .2, and .3 pass out quick on ce1 proto tcp/udp from ce1/32 to any port = domain keep state pass in quick on ce0 proto tcp/udp from 192.168.1.2 to any port = domain keep state pass in quick on ce0 proto tcp/udp from 192.168.1.3 to any port = domain keep state # Allow NTP from any internal hosts to any external NTP server. pass in quick on ce0 proto udp from 192.168.1.0/24 to any port = 123 keep state pass out quick on ce1 proto udp from any to any port = 123 keep state # Allow incoming mail pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = smtp keep state # Allow outgoing connections: SSH, WWW, NNTP, mail, whois pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 22 keep state pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 22 keep state pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 80 keep state pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 80 keep state pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 443 keep state pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 443 keep state pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = nntp keep state block in quick on ce1 proto tcp from any to any port = nntp keep state pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = nntp keep state pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = smtp keep state pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = whois keep state pass out quick on ce1 proto tcp from any to any port = whois keep state # Allow ssh from offsite pass in quick on ce1 proto tcp from any to ce1/32 port = 22 keep state # Allow ping out pass in quick on ce0 proto icmp all keep state pass out quick on ce1 proto icmp all keep state # allow auth out pass out quick on ce1 proto tcp from ce1/32 to any port = 113 keep state pass out quick on ce1 proto tcp from ce1/32 port = 113 to any keep state # return rst for incoming auth block return-rst in quick on ce1 proto tcp from any to any port = 113 flags S/SA # log and return reset for any TCP packets with S/SA block return-rst in log on ce1 proto tcp from any to any flags S/SA # return ICMP error packets for invalid UDP packets block return-icmp(net-unr) in proto udp all |