▼
Scroll to page 2
of
294
Bull AIX 5L Guide de sécurité AIX REFERENCE 86 F2 22EG 00 Bull AIX 5L Guide de sécurité AIX Logiciel Octobre 2002 BULL CEDOC 357 AVENUE PATTON B.P.20845 49008 ANGERS CEDEX 01 FRANCE REFERENCE 86 F2 22EG 00 L’avis juridique de copyright ci–après place le présent document sous la protection des lois de Copyright des États–Unis d’Amérique et des autres pays qui prohibent, sans s’y limiter, des actions comme la copie, la distribution, la modification et la création de produits dérivés à partir du présent document. Copyright Bull S.A. 1992, 2002 Imprimé en France Vos suggestions sur la forme et le fond de ce manuel seront les bienvenues. Une feuille destinée à recevoir vos remarques se trouve à la fin de ce document. Pour commander d’autres exemplaires de ce manuel ou d’autres publications techniques Bull, veuillez utiliser le bon de commande également fourni en fin de manuel. Marques déposées Toutes les marques déposées sont la propriété de leurs titulaires respectifs. AIX est une marque déposée d’IBM Corp. et est utilisée sous licence. UNIX est une marque déposée licenciée exclusivement par Open Group. Les informations contenues dans le présent document peuvent être modifiées sans préavis. Bull S.A. ne pourra être tenu pour responsable des erreurs qu’il peut contenir ni des dommages accessoires ou indirects que son utilisation peut causer. Préface Le présent manuel fournit aux administrateurs système des informations relatives à l’utilisateur et au groupe, au fichier, au système et à la sécurité réseau du système d’exploitation AIX. Il contient des informations relatives à l’exécution de certaines tâches telles que la modification des permissions, la configuration des méthodes d’authentification ainsi que celle de l’environnement de la base TCB (Trusted Computing Base) et de CAPP (Controlled Access Protection Profile) avec les fonctionnalités EAL4+ (Evaluation Assurance Level 4+). Ce manuel contient les parties suivantes : Sécurité d’un système autonome, sécurité réseau et Internet, Annexes. • La première partie, Sécurité d’un système autonome, présente un guide de la sécurité AIX pour les systèmes autonomes. Elle comprend notamment l’installation d’un système autonome avec la base TCB, l’installation des fonctionnalités CAPP/EAL4+, le contrôle de la connexion, l’application des règles adéquates de mots de passe, l’implémentation de mécanismes de sécurité au niveau utilisateur, l’activation de l’option d’audit du système, ainsi que le contrôle de l’accès aux fichiers et répertoires. Cette partie traite également des informations de sécurité relatives à X11, Common Desktop Environment (CDE), LDAP (Lightweight Directory Access Protocol), etc. • La deuxième partie, Sécurité réseau et Internet, fournit des informations concernant la sécurité réseau et Internet. Elle aborde les problèmes concernant la configuration de la sécurité TCP/IP, le contrôle des services réseau, l’audit et le contrôle de la sécurité réseau, la configuration de la sécurité IP, la configuration de réseaux privés virtuels (VPN), la sécurité des e–mails, la sécurité NFS, les services de noms et Kerberos. • La troisième partie contient les annexes, qui se composent des listes de contrôle de la sécurité, des informations relatives aux outils de sécurité, des ressources de sécurité en ligne et des informations de référence concernant les services réseau et les ports de communication. A qui s’adresse ce manuel ? Ce manuel s’adresse aux administrateurs système et aux responsables de la sécurité informatique. Conventions typographiques Les conventions typographiques utilisées sont les suivantes : Préface iii Gras Identifie les commandes, les sous–programmes, les mots clés, les fichiers, les structures, les répertoires, et les autres éléments dont le nom est défini par le système. Identifie également les objets de l’interface graphique, tels que les boutons, les libellés et les icônes sélectionnés par l’utilisateur. Italique Identifier les paramètres dont les noms ou les valeurs doivent être indiqués par l’utilisateur. Espacement fixe Identifier des exemples de données, des exemples de textes similaires à ceux affichés à l’écran, des parties de code similaires à celui que vous serez susceptible de rédiger, des messages système, ou des informations que vous devez saisir. Distinction majuscules/minuscules dans AIX La distinction majuscules/minuscules s’applique à toutes les données entrées dans le système d’exploitation AIX. Par exemple, la commande ls afficher la liste des fichiers. Si vous entrez LS, le système affiche un message d’erreur indiquant que la commande entrée est introuvable. De la même manière, FICHEA, FiChea et fichea sont trois noms de fichiers distincts, même s’ils se trouvent dans le même répertoire. Pour éviter toute effet inattendu, vérifiez systématiquement que vous utilisez la casse appropriée. ISO 9000 Des systèmes homologués fabrication de ce produit. ISO 9000 ont été utilisés pour le développement et la Bibliographie Les publications suivantes contiennent des informations connexes : • AIX 5L Version 5.2 System Management Guide: Operating System and Devices • AIX 5L Version 5.2 System Management Concepts: Operating System and Devices • AIX 5L Version 5.2 System Management Guide: Communications and Networks • AIX 5L Version 5.2 Operating System Installation: Getting Started • AIX 5L Version 5.2 Référence et guide d’installation • AIX 5L Version 5.2 Commands Reference • AIX 5L Version 5.2 Files Reference • AIX 5L Version 5.2 General Programming Concepts: Writing and Debugging Programs • AIX 5L Version 5.2 System User’s Guide: Operating System and Devices • AIX 5L Version 5.2 System User’s Guide: Communications and Networks • AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide • AIX 5L Version 5.2 Guide to Printers and Printing iv Guide de sécurité Table des matières Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A qui s’adresse ce manuel ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions typographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distinction majuscules/minuscules dans AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii iii iii iv iv iv Première partie. Sécurité d’un système autonome Chapitre 1. Installation et configuration d’un système sécurisé . . . . . . . . . . . . La base TCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation d’un système avec TCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vérification de la base TCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure du fichier sysck.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de la commande tcbck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vérification des fichiers sécurisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vérification de l’arborescence du système de fichiers . . . . . . . . . . . . . . . . . . . . Ajout d’un programme sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suppression d’un programme sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration des options supplémentaires de sécurité . . . . . . . . . . . . . . . . . . . . . Restriction d’accès au terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de la clé SAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration de la clé SAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du système conforme CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . . . . . Installation d’un système CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regroupement de logiciels CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environnement physique d’un système CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . Environnement organisationnel d’un système CAPP/EAL4+ . . . . . . . . . . . . . . . . . Configuration d’un système CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du port et de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limites de ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sous–système d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Services système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mise en route d’un système distribué CAPP/EAL4+ . . . . . . . . . . . . . . . . . . . . . . Utilisation de la fonction DACinet pour le contrôle d’accès au réseau en fonction des utilisateurs et des ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation de logiciels supplémentaires sur un système CAPP/EAL4+ . . . . . Fenêtre de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration de la fenêtre de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modification du message d’accueil de l’écran de connexion . . . . . . . . . . . . . . . . . Modification de l’écran de connexion CDE (Common Desktop Environment) . . Renforcement des paramètres de connexion par défaut du système . . . . . . . . . Protection de terminaux sans surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application de la déconnexion automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gestion des problèmes sous X11 et CDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suppression du fichier /etc/rc.dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Préface 1-1 1-1 1-1 1-2 1-2 1-3 1-4 1-4 1-4 1-5 1-5 1-5 1-5 1-6 1-7 1-7 1-8 1-8 1-9 1-10 1-11 1-11 1-11 1-13 1-13 1-13 1-14 1-14 1-17 1-17 1-17 1-18 1-19 1-20 1-20 1-20 1-20 1-21 1-21 v vi Précautions à prendre pour éviter le contrôle non autorisé des serveurs X distants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activation et désactivation du contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . Désactivation des droits utilisateurs sur la commande xhost . . . . . . . . . . . . . . . . . 1-21 1-21 1-21 Chapitre 2. Utilisateurs, rôles et mots de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . Le compte Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Désactivation de la connexion root directe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rôles administratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration et maintenance des rôles à l’aide de SMIT . . . . . . . . . . . . . . . . . . . Comprendre les autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liste des commandes d’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comptes utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributs utilisateur recommandés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contrôle des comptes utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ID de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sécurisation à l’aide de listes de contrôle des accès (ACL) . . . . . . . . . . . . . . . . . . Variable d’environnement PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration d’un accès FTP anonyme avec un compte utilisateur sécurisé . . . . . Comptes utilisateurs spécifiques au système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suppression de comptes utilisateur par défaut inutiles . . . . . . . . . . . . . . . . . . . . . . Listes de contrôle des accès (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation des programmes setuid et setgid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Droits d’accès administratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Droits d’accès de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Droits d’accès étendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de liste de contrôle des accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Autorisations d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mots de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qu’est–ce qu’un bon mot de passe ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le fichier /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le fichier /etc/passwd File et les environnements réseau . . . . . . . . . . . . . . . . . . . Dissimulation des noms d’utilisateur et mots de passe . . . . . . . . . . . . . . . . . . . . . . Paramétrage des options de mot de passe recommandées . . . . . . . . . . . . . . . . . Extension des restrictions de mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentification de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ID de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du système de quotas de disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du système de quotas de disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprise après un dépassement de quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du système de quotas de disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2-1 2-1 2-2 2-2 2-4 2-4 2-7 2-8 2-8 2-9 2-10 2-10 2-10 2-11 2-15 2-16 2-17 2-18 2-19 2-19 2-19 2-20 2-20 2-21 2-23 2-23 2-24 2-25 2-25 2-25 2-29 2-30 2-30 2-30 2-31 2-31 2-32 Chapitre 3. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sous–système d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Détection des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collecte d’informations sur les événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traitement des informations sur le suivi d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sélection des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du sous–système d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collecte d’informations sur le sous–système d’audit . . . . . . . . . . . . . . . . . . . . . . . . Journalisation des audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Format des enregistrements d’audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration de la journalisation d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3-1 3-1 3-2 3-2 3-3 3-4 3-4 3-4 3-5 3-5 Guide de sécurité Sélection des événements audités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modes de suivi d’audit du noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traitement des enregistrements d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation du sous–système d’audit pour un rapide contrôle de sécurité . . . . . . Configuration de l’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sélection des événements audités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sélection des classes d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sélection du mode de collecte des données d’audit . . . . . . . . . . . . . . . . . . . . . . . . Exemple de contrôle en temps réel des modifications de fichiers . . . . . . . . . . . . . Exemple de scénario de journal d’audit générique . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 3-5 3-8 3-8 3-9 3-11 3-11 3-12 3-12 3-13 Chapitre 4. Utilisation du protocole LDAP du sous–système de sécurité . . . . Configuration d’un serveur d’informations de sécurité LDAP . . . . . . . . . . . . . . . . . . . Configuration d’un client LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gestion des utilisateurs LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contrôle d’accès par LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audit du serveur d’informations de sécurité LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commandes LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La commande mksecldap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le démon secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les commandes de gestion LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande start–secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande stop–secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande restart–secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande ls–secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande flush–secldapclntd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande sectoldif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le format de fichier ldap.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Format de fichier du mappage des attributs LDAP . . . . . . . . . . . . . . . . . . . . . . . . . Informations connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4-1 4-3 4-4 4-5 4-6 4-6 4-6 4-9 4-10 4-11 4-11 4-11 4-12 4-12 4-12 4-13 4-13 4-14 4-16 4-16 Chapitre 5. PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coprocesseur de chiffrement 4758 Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vérification du coprocesseur de chiffrement 4758 Model 2 pour une utilisation avec le sous-système PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . Configuration du sous-système PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initialisation du jeton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du PIN du responsable de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . Initialisation du PIN utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconfiguration du PIN utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du vecteur de contrôle des fonctions PKCS #11 . . . . . . . . . . . . . . . Utilisation de PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5-1 5-1 5-2 5-2 5-2 5-3 5-3 5-3 5-4 Chapitre 6. Service d’authentification de certificats X.509 et infrastructure à clef publique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du service d’authentification de certificats . . . . . . . . . . . . . . . . . . . . . . . Certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Autorités de certification et certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Format de stockage des certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Magasins de clefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mise en œuvre du service d’authentification de certificats . . . . . . . . . . . . . . . . . . . . . Création de comptes utilisateur PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flux de données d’authentification utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 6-1 6-2 6-2 6-3 6-3 6-3 6-4 6-4 Préface vii Implémentation du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implémentation du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnalités générales du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture générale du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planification du service d’authentification de certificats . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur les certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur les magasins de clefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur le registre des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le fichier acct.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nouveaux comptes actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L’utilisateur root et les mots de passe des magasins de clefs . . . . . . . . . . . . . Autres remarques sur le service d’authentification de certificats . . . . . . . . . . . . . . Modules du service d’authentification de certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation et configuration du service d’authentification de certificats . . . . . . . . . . . Installation et configuration du serveur LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation du serveur LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du serveur LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du serveur LDAP pour PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation et configuration du serveur pour le service d’authentification de certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration LDAP du serveur pour le service d’authentification de certificats . Création d’une autorité de certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Création de la clef de signature sécurisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration du client du service d’authentification de certificats . . . . . . . . . . . . Installation de la clef de signature sécurisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edition du fichier acct.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration de l’autorité de certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le fichier methods.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemples des configuration de l’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . Création d’un nouveau compte utilisateur PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . Conversion d’un compte utilisateur non–PKI en un compte utilisateur PKI . . Création et ajout d’un certificat d’authentification . . . . . . . . . . . . . . . . . . . . . . . . Modification du mot de passe par défaut du nouveau magasin de clefs . . . . . Gestion d’une clef de signature sécurisée compromise . . . . . . . . . . . . . . . . . . . Gestion d’une clef privée d’utilisateur compromise . . . . . . . . . . . . . . . . . . . . . . . Gestion d’un magasin de clefs ou d’un mot de passe de magasin de clefs compromis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Déplacement du magasin de clefs d’un utilisateur ou modification du nom de magasin de clefs d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . Déplacement du magasin de clefs d’un utilisateur ou modification du nom de magasin de clefs d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 7. Module d’extension d’authentification (PAM) . . . . . . . . . . . . . . . . . . Bibliothèque PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modules PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fichier de configuration PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajout d’un module PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modification du fichier /etc/pam.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activation du débogage PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intégration de PAM avec AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module pam_aix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Guide de sécurité 6-4 6-5 6-6 6-6 6-14 6-14 6-14 6-15 6-15 6-15 6-15 6-16 6-16 6-16 6-17 6-18 6-18 6-18 6-19 6-20 6-21 6-22 6-23 6-24 6-24 6-24 6-24 6-25 6-29 6-29 6-29 6-29 6-30 6-30 6-30 6-30 6-31 6-31 6-31 7-1 7-2 7-3 7-4 7-6 7-6 7-6 7-7 7-7 7-8 Chapitre 8. Outils OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation d’OpenSSH avec PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 8-3 Chapitre 9. Sécurité TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Système de protection du système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contrôle d’accès au réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audit de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evénements au niveau du noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evénements au niveau application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chemin d’accès sécurisé, shell sécurisé et clé SAK . . . . . . . . . . . . . . . . . . . . . . . . Sécurité des commandes TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exécution de commandes à distance (/etc/hosts.equiv) . . . . . . . . . . . . . . . . . . . . . Restrictions d’accès FTP (/etc/ftpusers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus sécurisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Base NTCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sécurité des données et protection des informations . . . . . . . . . . . . . . . . . . . . . . . . . Contrôle d’accès aux ports TCP en fonction de l’utilisateur, avec le contrôle d’accès discrétionnaire aux ports Internet . . . . . . . . . . . . . . . . . . . . Contrôle des accès aux services TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemples d’utilisation de DACinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ports privilégiés pour l’exécution des services locaux . . . . . . . . . . . . . . . . . . . . . . 9-1 9-2 9-2 9-2 9-2 9-2 9-3 9-3 9-6 9-7 9-7 9-8 9-10 9-10 9-11 9-11 9-12 Deuxième partie. Sécurité réseau et Internetz Chapitre 10. Services réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correspondance des Services réseau avec les ports de communication ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification des sockets TCP et UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 11. Sécurité IP (Internet Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sécurité IP – Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sécurité IP et système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctions de sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctions IKE (Internet Key Exchange) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liens de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gestion des clefs et tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prise en charge du tunnel IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prise en charge des tunnels manuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctions de filtrage natif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prise en charge des certificats numériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Private Networks (VPN) et sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation de la sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chargement de la fonction de sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planification de la sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accélération matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tunnels / Filtres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tunnels et liens de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur le tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paramètres et politique de la gestion des clefs . . . . . . . . . . . . . . . . . . . . . . . . . . Paramètres et politique de la gestion des données . . . . . . . . . . . . . . . . . . . . . . Choix d’un type de tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation d’IKE avec DHCP ou Dynamically Assigned Addresses (affectation dynamique des adresses) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de XML pour définir un tunnel générique de gestion des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Préface 10-1 10-1 10-4 11-1 11-1 11-1 11-2 11-3 11-3 11-4 11-4 11-5 11-5 11-6 11-6 11-6 11-7 11-7 11-8 11-9 11-11 11-11 11-13 11-14 11-15 11-15 11-15 ix Configuration d’un tunnel d’échange de clefs par Internet (IKE) . . . . . . . . . . . . . . . . Utilisation de Web-based System Manager pour la configuration de tunnels IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de l’assistant de configuration de base . . . . . . . . . . . . . . . . . . . . . . . . Configuration avancée des tunnels IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de l’interface SMIT pour la configuration d’un tunnel IKE . . . . . . . . . . Interface de la ligne de commande pour la configuration d’un tunnel IKE . . . . . . Ressemblances entre IKE et Linux sous AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scénarios de configuration d’un tunnel IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation des certificats numériques et du Key Manager . . . . . . . . . . . . . . . . . . . . . . Format des certificats numériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur la sécurité des certificats numériques . . . . . . . . . . . . . . . . . . . . . . Autorités d’accréditation et hiérarchies sécurisées . . . . . . . . . . . . . . . . . . . . . . . Listes de révocation des certificats (CRL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation des certificats numériques dans les applications Internet . . . . . . . . . . Certificats numériques et demandes de certificats . . . . . . . . . . . . . . . . . . . . . . . . . Utilitaire IBM Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Création d’un base de données de clefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajout de certificat numérique root d’une autorité d’accréditation . . . . . . . . . . . Etablissement de paramètres sécurisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suppression de certificat numérique root d’autorité d’accréditation . . . . . . . . . Demande de certificat numérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajout (Réception) d’un nouveau certificat numérique . . . . . . . . . . . . . . . . . . . . . Suppression de certificat numérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modification de mot de passe de la base de données . . . . . . . . . . . . . . . . . . . . Création de tunnels IKE avec certificats numériques . . . . . . . . . . . . . . . . . . . . . Configuration des tunnels manuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration des tunnels et des filtres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Création d’un tunnel manuel sur le premier hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . Création d’un tunnel manuel sur le second hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration des filtres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Règles de filtre statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Règles de filtre générées automatiquement et définies par l’utilisateur . . . . . . . . Règles de filtre prédéfinies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Masques de sous–réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Hôte–Pare–feu–Hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctions de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Libellés des entrées de zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification des incidents liés à la sécurité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Débogage des erreurs au niveau du tunnel manuel . . . . . . . . . . . . . . . . . . . . . . . . Débogage des erreurs au niveau des tunnels IKE . . . . . . . . . . . . . . . . . . . . . . . . . Organigramme des tunnels IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Journalisation IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonction de journalisation Parse Payload (analyse de blocs) . . . . . . . . . . . . . . Incidents liés au certificat numérique et au mode de signature . . . . . . . . . . . . Fonctions de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ipsecstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Informations de référence sur la fonction de sécurité IP . . . . . . . . . . . . . . . . . . . . . . . Liste des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liste des méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Guide de sécurité 11-17 11-17 11-17 11-18 11-20 11-20 11-23 11-23 11-24 11-25 11-26 11-27 11-27 11-27 11-28 11-28 11-29 11-30 11-31 11-31 11-32 11-32 11-33 11-34 11-34 11-36 11-36 11-37 11-38 11-39 11-39 11-43 11-44 11-44 11-44 11-45 11-49 11-50 11-50 11-53 11-53 11-54 11-54 11-58 11-61 11-61 11-62 11-62 11-62 Chapitre 12. Sécurité NIS (Network Information Service) et NIS+ . . . . . . . . . . . Méthodes de protection du système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Système de protection NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mandants NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niveaux de sécurité NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentification et données d’identification NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Données d’identification des utilisateurs et des postes . . . . . . . . . . . . . . . . . . . . . . Données d’identification locales et DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Données d’identification DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Données d’identification locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types d’utilisateurs et types de données d’identification . . . . . . . . . . . . . . . . . . Autorisation et accès NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classes d’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe Propriétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe Groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe Monde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe Personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classes d’autorisation et hiérarchie des objets NIS+ . . . . . . . . . . . . . . . . . . . . . Droits d’accès NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Droits d’administrateur et sécurité NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Informations de référence sur la sécurité NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1 12-1 12-2 12-4 12-4 12-5 12-5 12-5 12-5 12-6 12-6 12-7 12-7 12-8 12-8 12-9 12-9 12-9 12-9 12-10 12-11 Chapitre 13. Sécurité NFS (Network File System) . . . . . . . . . . . . . . . . . . . . . . . . . . Confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chiffrement DES (Data Encryption Standard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chiffrement par clé publique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentification NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chiffrement par clé publique pour NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . Règles d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accord sur l’heure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accord sur la clé DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nom des entités réseau pour l’authentification DES . . . . . . . . . . . . . . . . . . . . . . . . . . Fichier /etc/publickey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remarques sur l’amorçage des systèmes à clé publique . . . . . . . . . . . . . . . . . . . . . . Remarques sur les performances de NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . Administration de NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration de NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exportation d’un système de fichiers via NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . Montage d’un système de fichiers NFS sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1 13-1 13-2 13-2 13-3 13-3 13-3 13-4 13-4 13-4 13-5 13-6 13-6 13-6 13-7 13-7 13-8 13-9 13-10 Chapitre 14. EIM (Enterprise Identity Mapping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gestion de plusieurs registres d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Méthodes actuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilisation de l’EIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1 14-1 14-1 14-2 Préface xi Troisième partie. Annexes xii Annexe A. Vérification de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Annexe B. Sources d’informations sur la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . Sites Web concernant la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Listes de diffusion de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Références de sécurité en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 B-1 B-1 B-1 Annexe C. Résumé des principaux services système AIX . . . . . . . . . . . . . . . . . . C-1 Annexe D. Résumé des options de service réseau . . . . . . . . . . . . . . . . . . . . . . . . D-1 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1 Guide de sécurité Première partie. Sécurité d’un système autonome La présente partie fournit des informations relatives à la sécurité d’un système autonome, quelle que soit la connectivité réseau. Les chapitres qui suivent décrivent la procédure d’installation de votre système lorsque les options de sécurité sont activées, ainsi que les moyens d’empêcher des utilisateurs non autorisés d’accéder au système en configurant la sécurité d’AIX. Sécurité d’un système autonome PART 1 - 1 PART 1 - 2 Guide de sécurité Chapitre 1. Installation et configuration d’un système sécurisé Ce chapitre fournit des informations sur l’installation et la configuration d’un système sécurisé. Il contient les sections suivantes : • La Base informatique sécurisée (TCB), page 1-1 • CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+), page 1-7 • Fenêtre de connexion, page 1-17 • Gestion des problèmes sous X11 et CDE, page 1-21 La base TCB L’administrateur système doit déterminer le niveau de sécurisation qui peut être accordé à un programme donné. Cette détermination prend en compte la valeur des ressources d’information du système en décidant du niveau de confiance nécessaire à l’installation d’un programme avec privilèges. La base informatique sécurisée (TCB) est responsable de l’application des règles de sécurité du système. L’installation et l’utilisation de la base TCB permettent de définir l’accès utilisateur via un chemin d’accès sécurisé, assurant ainsi la communication sécurisée entre les utilisateurs et la base TCB. Les fonctions de la base TCB ne peuvent être activées qu’à l’installation du système d’exploitation. Pour installer la base TCB sur un poste déjà installé, il faudra effectuer une installation avec préservation. L’activation de la TCB donne accès au shell sécurisé, aux processus sécurisés et à la clé SAK (Secure Attention Key). Cette section traite des points suivants : • Installation d’un système avec TCB, page 1-1 • Vérification de la base TCB, page 1-2 • Structure du fichier sysck.cfg, page 1-2 • Utilisation de la commande tcbck, page 1-3 • Configuration des options de sécurité supplémentaires, page 1-5 Installation d’un système avec TCB La base TCB est responsable de l’application des règles de sécurité du système. Tous les matériels de l’ordinateur sont inclus dans la TCB, mais l’administrateur système doit en premier lieu s’inquiéter des composants logiciels du TCB. Si vous installez l’option TCB sur un système, vous activez le chemin et le shell sécurisés ainsi que le contrôle d’intégrité du système (commande tcbck). Ces fonctions ne peuvent être activées que lors de l’installation du BOS (Base Operating System). Si l’option TCB n’est pas sélectionnée lors de l’installation initiale, la commande tcbck est désactivée. Pour activer la commande, il faudra installer à nouveau le système, avec l’option TCB sélectionnée. Pour définir l’option TCB lors de l’installation a BOS installation, sélectionnez Options supplémentaires à partir de l’écran Installation et paramètres. Dans cet écran, la valeur Installation et configuration d’un système sécurisé 1-1 par défaut de Installation TCB est no. Pour activer la base TCB, tapez 2 puis appuyez sur Entrée. Toutes les unités faisant partie de la base TCB, elle contrôle chaque fichier du répertoire /dev. De plus, la base TCB contrôle automatiquement plus de 600 fichiers supplémentaires et stocke les informations critiques les concernant dans le fichier /etc/security/sysck.cfg. Si vous installez la base TCB, sauvegardez ce fichier dès que l’installation est terminée, sur un support amovible comme une bande, un CD ou un disque, puis conservez le support en lieu sûr. Vérification de la base TCB pour lancer l’audit de la sécurité de la base TCB, utilisez la commande tcbck. La sécurité du système d’exploitation est compromise dès lors que les fichiers TCB ne sont pas correctement protégés ou que les fichiers de configuration n’ont pas de valeurs sûres. La commande tcbck lance un audit du fichier /etc/security/sysck.cfg en le lisant. Ce fichier comporte une description de tous les fichiers TCB et de configuration, et de toutes les commandes sécurisées. Le fichier /etc/security/sysck.cfg est en ligne et peut donc être modifié par un pirate informatique. Assurez–vous de créer une copie hors–ligne en lecture seule, après chaque mise à jour de la base TCB. Copiez également ce fichier depuis le support d’archives sur un disque avant d’effectuer tout contrôle. L’installation de la base TCB et l’utilisation de la commande tcbck ne garantit pas que le système fonctionne dans un mode conforme CAPP (Controlled Access Protection Profile) ou EAL4+ (Evaluation Assurance Level 4+). Pour obtenir des informations sur les options CAPP/EAL4+, reportez–vous à la section CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+), page 1-7. Structure du fichier sysck.cfg La commande tcbck lit le fichier /etc/security/sysck.cfg pour définir quels fichiers sont à vérifier. Tout programme sécurisé du système est décrit par une strophe du fichier /etc/security/sysck.cfg. Voici les différents attributs de chaque strophe : 1-2 class Nom d’un groupe de fichiers. Cet attribut permet de vérifier plusieurs fichiers du même nom de classe en indiquant un seul argument à la commande tcbck. Vous pouvez indiquer plusieurs classes (séparées par une virgule). owner ID utilisateur ou nom du propriétaire du fichier. Si la valeur ne correspond pas au propriétaire du fichier, la commande tcbck définit l’ID propriétaire sur cette valeur. group ID de groupe ou nom de groupe du fichier. Si la valeur ne correspond pas au propriétaire du fichier, la commande tcbck définit l’ID propriétaire sur cette valeur. mode Liste de valeurs (séparées par des virgules). Les valeurs acceptées sont SUID, SGID, SVTX et TCB. La dernière valeur doit représenter les autorisations du fichier, sous forme octale ou comme chaîne de 9 caractères. Par exemple 755 ou rwxr–xr–x. Si la valeur ne correspond pas au mode réel du fichier, tcbck applique la valeur correcte. Guide de sécurité links Liste de chemins d’accès (séparés par des virgules) associés à ce fichier. Le cas échéant, tcbck crée le lien de tout chemin d’accès de la liste qui ne serait pas associé au fichier. Sans le paramètre tree, la commande tcbck imprime un message indiquant la présence de liens supplémentaires (mais sans définir leurs noms). Avec le paramètre tree, la commande tcbck imprime également tout nom de chemin d’accès supplémentaire associé au fichier. symlinks Liste liens symboliques vers ce fichier, séparés par des virgules. Le cas échéant, tcbck crée le lien symbolique de tout chemin d’accès de la liste qui ne serait pas un lien symbolique. Avec le paramètre tree, la commande tcbck imprime également tout nom de chemin d’accès supplémentaire représentant un lien symbolique avec le fichier. program Liste de valeurs (séparées par des virgules). La première valeur est le chemin d’accès d’un programme de vérification. Les valeurs supplémentaires sont passées en arguments au programme lorsqu’il est exécuté. Remarque : Le premier argument est soit –y, –n, –p ou –t, selon l’indicateur utilisé avec la commande tcbck. acl Chaîne de texte représentant la liste de contrôle d’accès associée au fichier. Son format doit être le même que celui de la sortie de la commande aclget. Si la chaîne ne correspond pas à l’ACL du fichier, sysck applique cette valeur avec la commande aclput. Remarque : Les attributs SUID, SGID, et SVTX doivent correspondre à ceux spécifiés dans le mode (le cas échéant). source Nom du fichier source à utiliser pour générer une copie avant la vérification. Si la valeur n’est pas renseignée, et s’il s’agit d’un fichier ordinaire, un répertoire ou un tube nommé, une nouvelle version vide de ce fichier est créée (sauf s’il elle existe déjà). Pour les fichiers d’unités, un nouveau fichier spécial du même type d’unité est créé. Si un ou plusieurs attributs manquent dans la strophe du fichier /etc/security/sysck.cfg, la vérification correspondante n’est pas effectuée. Utilisation de la commande tcbck La commande tcbck permet généralement de : • Vérifier l’installation des fichiers relatifs à la sécurité • Vérifier que l’arborescence du système de fichiers ne contient pas de fichiers violant la sécurité • Mettre à jour, ajouter ou supprimer des fichiers sécurisés La commande tcbck présente trois modes d’utilisation : • Normal – non interactif à l’initialisation du système – avec la commande cron • Interactif – en sélectionnant les fichiers et les classes de fichiers voulus • Paranoïde – en enregistrant le fichier sysck.cfg hors ligne et en le restaurant périodiquement pour vérifier la machine Installation et configuration d’un système sécurisé 1-3 La base TCB est dépourvue de protection cryptographique, mais elle utilise la commande UNIX sum pour vérifier ses totaux de contrôle. La base de données TCB peut être définie manuellement pour utiliser une autre commande de somme de contrôle, par exemple md5sum (comprise dans le module RPM textutils sur le CD AIX Toolbox for Linux Applications). Vérification des fichiers sécurisés Pour vérifier tous les fichiers de la base de données tcbck, rendre compte et corriger toutes les erreurs, entrez : tcbck –y ALL Cette action lance la commande tcbck pour vérifier l’installation de chaque fichier de la base de données tcbck décrit dans le fichier /etc/security/sysck.cfg. Pour lancer cette commande automatiquement pendant l’initialisation du système et générer un journal d’erreurs éventuelles, ajoutez la chaîne ci–dessus au fichier /etc/rc. Vérification de l’arborescence du système de fichiers Si vous avez des doutes sur l’intégrité du système de fichiers, vous pouvez lancer à tout moment la commande tcbck pour vérifier l’arborescence. Procédez comme suit : tcbck –t tree Avec le paramètre tree, cette commande vérifie l’installation de tous les fichiers du système (ce qui peut prendre un certain temps). Dans tout fichier trouvé risquant de compromettre la sécurité du système, vous pouvez modifier les attributs suspects. En outre, les vérifications suivantes sont effectuées sur tous les autres fichiers du système de fichiers : • S’il s’agit d’un fichier avec un propriétaire root et avec le bit SetUID défini, ce dernier est effacé. • S’il s’agit d’un fichier exécutable d’un groupe administratif, avec le bit SetGID défini, ce dernier est effacé. • Si l’attribut tcb est défini pour le fichier, il est effacé. • Si le fichier correspond à une unité (fichier spécial caractères ou blocs), il est supprimé. • Si le fichier est un lien supplémentaire avec un chemin d’accès décrit dans /etc/security/sysck.cfg, ce lien est supprimé. • Si le fichier est un lien symbolique avec un chemin d’accès décrit dans /etc/security/sysck.cfg, ce lien est supprimé. Remarque : Toutes les entrées d’unités doivent avoir été ajoutées à /etc/security/sysck.cfg avant l’exécution de la commande tcbck ; sinon, le système devient inutilisable. Pour ajouter des unités sécurisées au fichier /etc/security/sysck.cfg, utilisez l’indicateur –l. Attention : Ne lancez pas l’option tcbck –y tree. Cette option supprime et désactive les unités qui ne sont pas correctement répertoriées dans la base TCB, et peut donc désactiver votre système. Ajout d’un programme sécurisé Pour ajouter un programme spécifique au fichier /etc/security/sysck.cfg, entrez : tcbck –a CheminAccès [attribut=valeur] Seuls les attributs dont les valeurs ne sont pas déduites de l’état courant du fichier sont à spécifier dans la ligne de commande. Tous les noms d’attribut sont répertoriés dans le fichier /etc/security/sysck.cfg. Par exemple, la commande suivante enregistre un nouveau programme root SetUID appelé /usr/bin/setgroups, possédant un lien nommé /usr/bin/getgroups : tcbck –a /usr/bin/setgroups links=/usr/bin/getgroups 1-4 Guide de sécurité Pour ajouter à un audit de sécurité du fichier /usr/bin/abc les utilisateurs administrateurs jfh et jsl, ainsi que le groupe administratif développeurs, entrez : tcbck –a /usr/bin/abc setuids=jfh,jsl setgids=developers Après l’installation d’un programme, vous ne savez pas nécessairement quels nouveaux fichiers sont enregistrés dans le fichier /etc/security/sysck.cfg. La commande suivante permet de les repérer et de les ajouter : tcbck –t tree Elle affiche le nom de tout fichier à enregistrer dans /etc/security/sysck.cfg. Suppression d’un programme sécurisé La suppression d’un fichier nécessite aussi celle de sa description dans le fichier /etc/security/sysck.cfg (si elle existe). Par exemple, si vous supprimez le programme /etc/cvid, la commande suivante entraînera l’affichage d’un message d’erreur : tcbck –y ALL Le message est : 3001–020 Fichier /etc/cvid introuvable. La description de ce programme n’a pas été supprimée de /etc/security/sysck.cfg. Pour la supprimer, entrez la commande suivante : tcbck –d /etc/cvid Configuration des options supplémentaires de sécurité Vous trouverez dans les sections suivantes des informations sur la configuration des options supplémentaires pour la base TCB. Restriction d’accès au terminal Les commandes getty et shell changent le propriétaire du terminal, pour empêcher l’accès au terminal de programmes non sécurisés. Le système d’exploitation permet de configurer l’accès exclusif au terminal. Utilisation de la clé SAK Un chemin d’accès sécurisé des communications est généré par la séquence de touches SAK (Ctrl–X puis Ctrl–R). Pour sa mise en œuvre, tenez compte des éléments suivants : • Lors de la connexion au système Après activation de la clé SAK : – si un nouvel écran de connexion s’affiche, vous disposez d’un chemin d’accès sécurisé. – si l’invite du shell sécurisé s’affiche, l’écran initial de connexion était un programme non autorisé dont le but était peut–être de voler votre mot de passe. Déterminez qui utilise actuellement ce terminal à l’aide de la commande who puis déconnectez–vous. • Lorsque vous souhaitez que la commande que vous avez entrée génère un programme sécurisé. Voici quelques exemples : – en tant qu’utilisateur root. Ne passez en utilisateur root qu’après avoir établi un chemin d’accès sécurisé de communication. Cela empêchera l’exécution de programmes non sécurisés avec des droits d’accès root. – avec les commandes su, passwd et newgrp. N’exécutez ces commandes qu’après établissement d’un accès sécurisé. Attention : Soyez prudent avec SAK, qui tue tous les processus qui tentent d’accéder au terminal et les liens associés (par exemple, /dev/console peut être lié à /dev/tty0). Installation et configuration d’un système sécurisé 1-5 Configuration de la clé SAK Chaque terminal peut être configuré indépendamment pour qu’une pression de SAK sur ce terminal crée un chemin d’accès sécurisé de communications. Ceci est déterminé par l’attribut sak_enabled dans le fichier /etc/security/login.cfg. Si la valeur de cet attribut est true, la clé SAK est activée. Si vous utilisez un port de communication (par exemple, avec la commande uucp), la strophe de ce port, dans le fichier /etc/security/login.cfg comporte la ligne suivante : sak_enabled = false Cette ligne (ou l’absence d’entrée dans cette strophe) désactive la clé SAK de ce terminal. Pour activer SAK sur un terminal, ajoutez la ligne suivante à sa strophe : sak_enabled = true 1-6 Guide de sécurité CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+) Dans AIX 5.2, les administrateurs peuvent installer l’option CAPP et EAL4+ lors de l’installation du système d’exploitation de base (BOS) à partir du CD–ROM. Cette option génère des restrictions sur le logiciel installé en même temps que le BOS, ainsi que sur l’accès au réseau. Cette section traite des points suivants : • Présentation du système conforme CAPP/EAL4+, page 1-7 • Installation d’un système CAPP/EAL4+, page 1-8 • Regroupement de logiciels CAPP/EAL4+, page 1-8 • Environnement physique d’un système CAPP/EAL4+, page 1-9 • Environnement organisationnel d’un système CAPP/EAL4+, page 1-10 • Configuration d’un système CAPP/EAL4+, page 1-11 Présentation du système conforme CAPP/EAL4+ Un système CAPP a été conçu et configuré pour répondre au protocole CAPP (Controlled Access Protection Profile) sur l’évaluation de la sécurité selon des critères communs. Le CAPP définit des critères de fonctionnement identiques au précédent standard TCSEC C2 (également connu comme Orange Book). Un Common Criteria (CC) Evaluated System est un système évalué selon les critères communs de la norme ISO 15408, relative à l’évaluation de l’assurance des produits informatiques. AIX 5.2 peut répondre aux exigences du CAPP et du niveau d’assurance CC EAL4+. La configuration du système répondant à ces règles est appelé un Système CAPP/EAL4+ dans le présent manuel. L’évaluation d’un système selon les CC (critères communs) n’est valide que pour cette configuration (matérielle et logicielle). Toute modification de sa configuration de sécurité annule l’évaluation du système. Cela ne signifie pas nécessairement que la sécurité du système sera affectée, mais que la configuration n’est plus certifiée. Ce chapitre décrit les contraintes qu’un système doit remplir pour répondre au CAPP et aux règles d’évaluation CC. Ni le CAPP ni les CC ne couvrent la totalité des options de configuration de sécurité d’AIX 5.2. Certaines caractéristiques (les modules IPsec ou de vérification de mot de passe sécurisée) en sont absentes, mais permettent d’améliorer la sécurité du système. Le système CAPP/EAL4+ AIX 5.2 comprend le BOS, sur des processeurs POWER 3 et POWER 4 à 64 bits et : • Le LVM (gestionnaire de volumes logiques) et le JFS2 (système de fichiers journalisé amélioré) • Le système X–Windows avec l’interface utilisateur graphique CDE • Les fonctions réseau Telnet, FTP, rlogin et rsh/rcp dans le protocole IPv4 • Le NFS (Network File System) Un système CAPP/EAL4+ est considéré en état de sécurité dans les conditions suivantes : • Si l’audit est configuré et que le système est en mode multi–utilisateurs, alors l’audit doit être opérationnel. • Le système accepte les requêtes de connexion et de services réseau. • Pour un système distribué, les bases de données administratives sont montées par NFS à partir du serveur maître. Installation et configuration d’un système sécurisé 1-7 Pour obtenir les dernières informations concernant le CAPP/EAL4+, consultez le document AIX 5.2 Release Notes. Installation d’un système CAPP/EAL4+ Pour définir les options CAPP/EAL4+ lors d’une installation du BOS, procédez comme suit : 1. Dans l’écran Installation et paramètres, sélectionnez Options supplémentaires. 2. Dans l’écran Options supplémentaires, tapez le numéro correspondant au choix Oui ou Non pour l’option Activation de la technologie CAPP et EAL4+. La valeur par défaut est non. Cette option n’est disponible que sous les conditions suivantes : • La méthode d’installation est définie sur Installation avec remplacement total. • L’anglais est sélectionné. • Le noyau 64 bits est activé. • Le JFS2 est activé. Lorsque l’option Activation de la technologie CAPP et EAL4+ est définie sur oui, l’option Base informatique sécurisée l’est également, et les seuls choix de Bureau disponibles sont NONE (aucun) ou CDE. Si vous effectuez une installation sans invite à l’aide d’un fichier bosinst.data, définissez la zone INSTALL_TYPE sur CC_EVAL et les zones suivantes comme suit : INSTALL_TYPE = CC_EVAL INSTALL_METHOD = overwrite TCB = yes NONE ou CDE DESKTOP = Un système CAPP/EAL4+ peut également s’installer à l’aide de l’environnement NIM (Network Installation Management). Pour installer un poste client CAPP/EAL4+, le poste maître NIM doit être un système CAPP/EAL4+. Bien que les deux puissent se trouver sur le réseau, les systèmes CAPP/EAL4+ ne peuvent communiquer qu’entre eux. Pour installer un client CAPP/EAL4+, une ressource bosinst_data doit être définie et les zones modifiées comme ci–dessus. Regroupement de logiciels CAPP/EAL4+ Lorsque l’option CAPP/EAL4+ est sélectionnée, les contenus du regroupement de l’installation /usr/sys/inst.data/sys_bundles/CC_EVAL.BOS.autoi sont installés. L’option CAPP/EAL4+ permet d’installer les regroupements de logiciels graphiques et de services de documentation. Si vous sélectionnez les options Logiciels graphiques avec CAPP/EAL4+, le contenu du regroupement /usr/sys/inst.data/sys_bundles/CC_EVAL.Graphics.bnd est installé. Si vous sélectionnez les options Logiciels de services de documentation avec CAPP/EAL4+, le contenu du regroupement /usr/sys/inst.data/sys_bundles/CC_EVAL.DocServices.bnd est installé. Dès que les LPP (Programmes sous licence) ont été installés, le système modifie la configuration par défaut pour respecter les règles CAPP/EAL4+. La configuration par défaut est modifiée comme suit : • Suppression de /dev/echo du fichier /etc/pse.conf. • Instanciation d’unités streams. • L’accès aux supports amovibles est réservé aux utilisateurs root. • Suppression des entrées non CC du fichier inetd.conf. • Modification des droits de plusieurs fichiers. • Enregistrement de symlinks dans le fichier sysck.cfg. 1-8 Guide de sécurité • Enregistrement d’unités dans le fichier sysck.cfg. • Définition des attributs de port et utilisateur par défaut. • Configuration de l’application doc_search pour navigateur. • Suppression de httpdlite du fichier inittab. • Suppression de writesrv du fichier inittab. • Suppression de mkatmpvc du fichier inittab. • Suppression de atmsvcd du fichier inittab. • Désactivation de snmpd dans le fichier /etc/rc.tcpip. • Désactivation de hostmibd dans le fichier /etc/rc.tcpip. • Désactivation de snmpmibd dans le fichier /etc/rc.tcpip. • Désactivation de aixmibd dans le fichier /etc/rc.tcpip. • Désactivation de muxatmd dans le fichier /etc/rc.tcpip. • Le port NFS (2049) est doté de privilèges. • Ajout d’événements manquants dans le fichier /etc/security/audit/events. • Vérification du bon fonctionnement de l’interface de bouclage. • Création de synonymes pour /dev/console. • Application forcée des droits de connexion par défaut à un serveur X. • Modification du répertoire /var/docsearch pour permettre une lecture universelle de tous les fichiers. • Ajout de strophes ODM pour définir les droits de console. • Définition des droits 000 pour les ptys de type BSD. • Désactivation des fichiers .netrc. • Ajout du traitement du répertoire patch. Environnement physique d’un système CAPP/EAL4+ Le système CAPP/EAL4+ dispose de règles spécifiques concernant son environnement. Ces règles sont les suivantes : • L’accès physique aux systèmes doit être restreint afin que les administrateurs autorisés soient les seuls à pouvoir en utiliser les consoles. • Le Service Processor n’est pas connecté à un modem. • L’accès physique aux terminaux est limité aux utilisateurs autorisés. • Le réseau physique est sécurisé contre les écoutes et l’usurpation. Lors de communications via des lignes non sécurisées, des mesures de sécurité supplémentaires (comme le chiffrement) sont nécessaires. • La communication n’est pas autorisée avec des systèmes autres que CAPP/EAL4+ AIX 5.2 ou qui n’utilisent pas le même contrôle de gestion. • Seul l’IP version 4 sera utilisé pour communiquer avec des systèmes autres que CAPP/EAL4+ (IPv6 n’ayant pas été évalué). • Les utilisateurs ne doivent pas être autorisés à modifier l’heure du système. Installation et configuration d’un système sécurisé 1-9 Environnement organisationnel d’un système CAPP/EAL4+ Un système CAPP/EAL4+ doit répondre aux règles de procédure et d’organisation suivantes : • Seuls les utilisateurs autorisés à travailler avec les informations du système reçoivent des ID utilisateurs. • Les mots de passe doivent être de très haute qualité (aussi aléatoires que possible et sans lien direct avec l’utilisateur ou l’entreprise). Pour plus d’informations concernant les règles de définition de mots de passe, reportez–vous à la section Mots de passe, page 2-23. • Les mots de passe sont personnels et confidentiels. • Les administrateurs doivent avoir les connaissances suffisantes pour gérer les systèmes dont la sécurité est essentielle. • Ils doivent se conformer aux directives fournies dans la documentation du système, • se connecter avec leur propre ID et utiliser su – pour effectuer l’administration en mode superutilisateur. • Les mots de passe utilisateurs générés par les administrateurs doivent être transmis en toute sécurité. • Les responsables du système doivent établir et mettre en application les procédures nécessaires au fonctionnement sécurisé des systèmes. • Les administrateurs doivent s’assurer que l’accès aux ressources du système sécurisé est protégé par les bits d’autorisation et la liste de contrôle d’accès (ACL) appropriés. • Le réseau physique doit être approuvé par l’entreprise pour le transport des données les plus confidentielles. • Les procédures de maintenance doivent comprendre des diagnostics réguliers. • Les administrateurs doivent disposer de procédures qui assurent un fonctionnement sécurisé et la reprise après une panne système. • La variable d’environnement LIBPATH ne doit pas être modifiée, ce qui risquerait d’autoriser un processus sécurisé de charger une bibliothèque non sécurisée. • Les logiciels de traçage ou de dérivation (tcpdump, trace) ne doivent pas être utilisés sur un système opérationnel. • Les protocoles anonymes tels que HTTP ne serviront que pour des informations publiques (par exemple, la documentation en ligne). • Un système CAPP/EAL4+ n’utilisera que le NFS via TCP. • L’accès aux supports amovibles doit être interdit aux utilisateurs. Les fichiers d’unités doivent être protégés par des bits d’autorisation et des ACL appropriés. • L’administration AIX se fait uniquement avec les droits d’accès root. Les fonctions de délégation d’administration en fonction du rôle ou du groupe, tout comme le mécanisme de privilège d’AIX, sont exclus d’un système CAPP/EAL4+. 1-10 Guide de sécurité Configuration d’un système CAPP/EAL4+ Cette section fournit des informations sur la configuration des sous–systèmes impliqués dans un système CAPP/EAL4+. Administration Les administrateurs doivent se connecter avec leur compte personnel et utiliser la commande su pour devenir l’utilisateur root afin d’administrer le système. Pour empêcher l’identification du mot de passe du compte root, seuls les administrateurs sont autorisés à utiliser la commande su sur ce compte. Veuillez procéder comme suit : 1. Ajoutez une entrée à la strophe root du fichier /etc/security/user : root: admin = true . . . sugroups = SUADMIN 2. Un groupe doit être défini dans le fichier /etc/group avec les ID des administrateurs autorisés : system:!:0:root,paul staff:!:1:invscout,julie bin:!:2:root,bin . . . SUADMIN:!:13:paul Les administrateurs doivent également respecter les procédures suivantes : • Etablir et mettre en application des procédures pour que les matériels, logiciels et firmware qui composent le système distribué, soient partagés, installés et configurés en toute sécurité. • S’assurer que le système est configuré pour que seul l’administrateur puisse y introduire un nouveau logiciel sécurisé. • Mettre en place des procédures pour vérifier que les utilisateurs effacent leur écran avant de se déconnecter des périphériques série (par exemple, terminaux 3151). Configuration du port et de l’utilisateur Les options de configuration AIX des ports et des utilisateurs sont définies pour satisfaire aux règles de l’évaluation. La règle actuelle est que la probabilité de deviner un mot de passe soit au plus 1 sur 1 000 000, et qu’une minute d’essais répétés ne donne qu’une probabilité de 1 sur 100 000. Installation et configuration d’un système sécurisé 1-11 Les valeurs recommandées du fichier /etc/security/user sont les suivantes : default: admin = false login = true su = true daemon = true rlogin = true sugroups = ALL admgroups = ttys = ALL auth1 = SYSTEM auth2 = NONE tpath = nosak umask = 077 expires = 0 SYSTEM = ”compat” logintimes = pwdwarntime = 5 account_locked = false loginretries = 3 histexpire = 52 histsize = 20 minage = 0 maxage = 8 maxexpired = 1 minalpha = 2 minother = 2 minlen = 8 mindiff = 4 maxrepeats = 2 dictionlist = /usr/share/dict/words pwdchecks = dce_export = false root: rlogin = false login = false Les paramètres par défaut du fichier /etc/security/user ne doivent pas être écrasés pas des paramètres d’utilisateurs particuliers. Remarque : login = false dans la strophe root interdit la connexion root directe. Seuls les comptes utilisateurs dotés du droit su pour le compte root pourront se connecter en tant que root. Cependant, un Refus de service contre un système qui envoie des mots de passe utilisateur incorrects peut verrouiller tous les comptes utilisateurs. Cette action peut empêcher tous les utilisateurs (même administrateurs) de se connecter au système. Une fois son compte verrouillé, l’utilisateur ne pourra pas se connecter avant que l’administrateur ne repasse l’attribut unsuccessful_login_count correspondant, dans le fichier /etc/security/lastlog, à une valeur inférieure à l’attribut loginretries. Si tous les comptes administrateurs sont verrouillés, vous devrez redémarrer le système en mode maintenance et lancer la commande chsec. Pour de plus amples informations sur l’utilisation de la commande chsec, reportez–vous à la section Contrôle des comptes utilisateurs, page 2-9. Les valeurs recommandées du fichier /etc/security/login.cfg sont les suivantes : default: sak_enabled = false logintimes = logindisable = 4 logininterval = 60 loginreenable = 30 logindelay = 5 1-12 Guide de sécurité Limites de ressource Lors de la configuration des limites de ressources dans le fichier /etc/security/limits, vérifiez que les limites correspondent aux besoins des processus du système. En particulier, les valeurs pour stack et rss ne doivent jamais être définies sur unlimited. Une pile illimitée risque d’écraser d’autres segments du processus, et une rss illimitée permet à un processus d’utiliser toute la mémoire réelle, pouvant alors créer des problèmes de ressource pour d’autres processus. Les valeurs stack_hard et rss_hard devraient être limitées également. Sous–système d’audit Les procédures suivantes permettent de protéger le sous–système d’audit : • Configurer le sous–système d’audit pour enregistrer toutes les activités de sécurité des utilisateurs. Définir un système de fichiers dédié aux données d’audits, pour s’assurer que l’espace nécessaire à l’audit est disponible et ne sera pas utilisé par d’autres processus. • Protéger les enregistrements d’audits (tels que des suivis d’audit, fichiers bin, et toutes les autres données dans /audit) contre les utilisateurs non–root. • Pour le système CAPP/EAL4+, l’audit en mode bin doit être défini lorsque le sous–système est utilisé. Pour obtenir des informations sur la procédure de définition du sous–système d’audit, reportez–vous à la section Configuration de l’audit, page 3-9. • Le suivi d’audit requiert au moins 20 % de l’espace disque d’un système. • Si l’audit est activé, le paramètre binmode de la strophe start dans /etc/security/audit/config doit avoir pour valeur panic. Le paramètre freespace de la strophe bin doit avoir une valeur au minimum égale à 25 % de l’espace disque alloué au stockage des suivis d’audit. Les paramètres bytethreshold et binsize doivent être définis sur 65536 octets. • Archiver les enregistrements d’audit depuis le système vers un stockage permanent. Configuration réseau La configuration réseau doit utiliser le contrôle d’accès discrétionnaire aux ports Internet (DACinet) pour interdire l’utilisation anonyme des protocoles X (X11) et NFS. Pour de plus amples informations sur la commande dacinet, reportez–vous à la section Contrôle d’accès aux ports TCP en fonction de l’utilisateur, avec le contrôle d’accès discrétionnaire aux ports Internet, page 9-10. La commande dacinet permet d’éviter les situations suivantes : • Empêche un utilisateur de prendre le bureau d’un autre avec X11. • Empêche l’utilisateur d’un poste client de falsifier les requêtes vers un serveur NFS, ce qui lui permettrait de devenir utilisateur root. Généralement, un utilisateur accède à un serveur NFS distant en faisant ses requêtes au Système de fichiers logiques sur l’hôte local, qui transmet ensuite la requête (en tant que root) au serveur distant. En définissant un ACL réservé aux utilisateurs root et obligeant le passage par ce port, il sera impossible d’envoyer directement des requêtes de protocole au serveur NFS distant. Installation et configuration d’un système sécurisé 1-13 Services système Le tableau suivant présente les services système standard, actifs sur le système CAPP/EAL4+ (sans carte graphique). Tableau 1. Services système standard ID utilisateur Commande Description root /init Processus Init root /usr/sbin/syncd 60 Démon sync du système de fichiers root /usr/sbin/srcmstr Démon maître SRC root /usr/sbin/cron Fonction CRON avec support AT root /usr/ccs/bin/shlap64 Démon support de bibliothèque partagée root /usr/sbin/syslogd Démon Syslog root /usr/lib/errdemon Démon AIX error log root /usr/sbin/getty /dev/console getty / TSM root /usr/sbin/portmap Mappeur de port pour NFS et CDE root /usr/sbin/biod 6 Client NFS root /usr/sbin/rpc.lockd Démon de verrou NFS daemon /usr/sbin/rpc.statd Démon stat NFS root /usr/sbin/rpc.mountd Démon de montage NFS root /usr/sbin/nfsd Démon serveur NFS root /usr/sbin/inetd Démon maître Inetd root /usr/sbin/uprintfd Démon print du noyau root /usr/sbin/qdaemon Démon Queuing root /usr/lpp/diagnostics/bin/diagd Diagnostics Mise en route d’un système distribué CAPP/EAL4+ Pour lancer un système distribué conforme au protocole CAPP/EAL4+, tous les utilisateurs doivent avoir des ID identiques sur tous les systèmes. Bien que ceci soit possible grâce à NIS, le niveau de sécurisation est insuffisant pour CAPP/EAL4+. Cette section décrit une configuration distribuée permettant de garantir des ID utilisateurs identiques sur tous les systèmes CAPP/EAL4+. Le système maître conserve les données d’identification et d’authentification (configurations utilisateur et groupe) pour tout le système distribué. Tous les autres systèmes utilisent NFS pour monter ces données. NFS est protégé par DACinet de sorte que seuls les administrateurs aient accès aux ports NFS sur le poste maître. Les données d’authentification sont modifiables par tous les administrateurs à l’aide d’outils tels que SMIT, sur n’importe quel système. Les données modifiées sont celles du poste maître. Toutes les données partagées d’identification et d’authentification proviennent du répertoire /etc/data.shared. Les fichiers standard d’identification et d’authentification sont remplacés par des liens symboliques dans le répertoire /etc/data.shared. 1-14 Guide de sécurité Fichiers partagés du système distribué Dans un système distribué, les fichiers suivants sont partagés. Ils proviennent habituellement du répertoire /etc/security. Tableau 2. Fichiers partagés du système distribué Fichier Description /etc/security/.ids ID utilisateur et groupe suivant disponible /etc/security/.profile Fichier .profile par défaut pour les nouveaux utilisateurs /etc/security/audit/bincmds Commandes d’audit en mode bin pour cet hôte /etc/security/audit/config Configuration d’audit local /etc/security/audit/events Liste des formats et événements des audits /etc/security/audit/objects Liste des objets audités sur cet hôte /etc/security/audit/streamcmds Commandes d’audit en mode stream pour cet hôte /etc/security/environ Variables d’environnement par utilisateur /etc/group Fichier /etc/group /etc/passwd Fichier /etc/passwd /etc/security/group Informations étendues de groupe, du fichier /etc/security/group /etc/hosts Fichier /etc/hosts /etc/security/limits Limites de ressource par utilisateur /etc/security/passwd Mots de passe par utilisateur /etc/security/user Attributs de l’utilisateur par défaut et par utilisateur /etc/security/priv Les ports désignés en tant que privilégiés au démarrage du système sont répertoriés dans le fichier /etc/security/priv /etc/security/services Les ports répertoriés dans le fichier /etc/security/services ne subissent pas de contrôles ACL /etc/security/acl Le fichier /etc/security/acl conserve les définitions ACL du système des services protégés qui seront réactivés à l’amorçage suivant du système, par le fichier /etc/rc.tcpip. Installation et configuration d’un système sécurisé 1-15 Fichiers non–partagés du système distribué Les fichiers suivants, du répertoire /etc/security, ne doivent pas être partagés sur le système distribué, et doivent rester spécifiques à l’hôte : Fichier Description /etc/security/failedlogin Fichier journal pour les échecs de connexion par hôte /etc/security/lastlog Information par utilisateur concernant les dernières connexions correctes et échouées sur cet hôte /etc/security/portlog Information par port concernant les ports verrouillés sur cet hôte /etc/security/login.cfg Caractéristiques de connexion spécifique à l’hôte pour le chemin d’accès sécurisé, shells de connexion, et autres informations relatives à la connexion Les fichiers de sauvegarde des fichiers partagés, générés automatiquement, sont également non–partagés. Ces fichiers ont le même nom que le fichier original, avec un o minuscule ajouté au début. Configuration du système distribué (le système maître) Sur le poste maître, un nouveau volume logique est créé pour contenir le système de fichiers des données d’identification et d’authentification. Ce volume logique est appelé /dev/hd10sec. Il est monté sur le système maître en tant que /etc/data.master. Pour générer les modifications sur le système maître, lancez la commande mkCCadmin avec l’adresse IP et le nom d’hôte du poste maître : mkCCadmin –m –a adresseIP nomhôte Configuration du système distribué (tous les systèmes) Toutes les données à partager sont transférées dans le répertoire /etc/data.shared. Au démarrage, tous les systèmes montent le répertoire /etc/data.master du poste maître sur le répertoire /etc/data.shared. Le maître lui–même utilise un montage de bouclage. Les systèmes client sont configurés avec la commande suivante : mkCCadmin –a adresseIP nomhôte Pour que le poste client utilise un poste maître différent, utilisez la commande chCCadmin. Lorsque qu’un système a été intégré dans le système distribué d’identification et d’authentification, les entrées inittab supplémentaires suivantes sont générées : isCChost Initialise le système en mode CAPP/EAL4+. rcCC Efface tous les ACL DACinet et ouvre uniquement les ports nécessaires au mappeur de port et au NFS. Il monte ensuite le répertoire partagé. rcdacinet Charge les ACL DACinet supplémentaires que l’administrateur pourrait avoir définis. Pensez aux éléments suivants Lors de l’exécution du système distribué : • Les administrateurs doivent s’assurer que les données partagées sont montées avant de modifier les fichiers partagés de configuration, afin de garantir que les données son visibles pour tous les systèmes. • La modification du mot de passe est la seule action administrative permise lorsque le répertoire partagé n’est pas monté. 1-16 Guide de sécurité Utilisation de la fonction DACinet pour le contrôle d’accès au réseau en fonction des utilisateurs et des ports La fonction DACinet permet de limiter l’accès des utilisateurs aux ports TCP. Pour de plus amples informations sur DACinet, reportez–vous à la section Contrôle d’accès aux ports TCP en fonction de l’utilisateur, avec le contrôle d’accès discrétionnaire aux ports Internet, page 9-10. Par exemple, lorsque vous utilisez la fonction DACinet pour limiter à root l’accès au port TCP/25 entrant, seuls les utilisateurs root des hôtes CAPP/EAL4+ peuvent y accéder. Cette situation limite les possibilités d’usurpation d’e–mail par des utilisateurs standard, à l’aide d’une connexion telnet sur le port TCP/25 de la victime. Pour activer les ACL pour les connexions TCP à l’amorçage, le script /etc/rc.dacinet est lancé à partir de /etc/inittab. Il ira lire les définitions dans le fichier /etc/security/acl puis chargera les ACL dans le noyau. Les ports à ne pas protéger avec les ACL doivent être répertoriés dans /etc/security/services. Ce fichier utilise un format identique au fichier /etc/services. Par exemple, pour un sous–réseau 10.1.1.0/24 pour tous les systèmes connectés, les entrées ACL pour limiter l’accès aux utilisateurs root pour X (TCP/6000) dans /etc/security/acl seraient : 6000 10.1.1.0/0xFFFFFF00 u:root Installation de logiciels supplémentaires sur un système CAPP/EAL4+ L’administrateur peut installer des logiciels supplémentaires sur le système CAPP/EAL4+. Si le logiciel n’est pas exécuté par l’utilisateur root ou avec des privilèges root, le système restera néanmoins conforme au protocole CAPP/EAL4+. C’est par exemple le cas pour des applications de bureautique, exécutées uniquement par des utilisateurs courants, sans composants SUID. Par contre, les logiciels installés fonctionnant avec des privilèges root annulent la conformité CAPP/EAL4+. Cela signifie par exemple que les pilotes de l’ancien JFS (système de fichiers journalisé) ne doivent pas être installés puisqu’ils fonctionnent en mode noyau. D’autres démons fonctionnant en root (par exemple, un démon SNMP) annuleront également la conformité CAPP/EAL4+. Un système CAPP/EAL4+ est rarement utilisé dans la configuration qui a été évaluée, particulièrement en environnement commercial. Des services supplémentaires sont généralement nécessaires, et le système de production, bien que basé sur un système évalué, ne répond plus exactement à ses spécifications. Fenêtre de connexion Les pirates informatiques peuvent obtenir des informations importantes à partir de l’écran de connexion AIX par défaut, comme le nom de l’hôte et la version du système d’exploitation. Ces informations peuvent leur permettre de déterminer les méthodes d’intrusion à essayer. Vous modifierez donc les paramètres par défaut de l’écran de connexion, le plus rapidement possible après une installation système. Cette section traite des points suivants : • Modification du message d’accueil de l’écran de connexion, page 1-19 • Modification de l’écran de connexion Common Desktop Environment, page 1-20 • Renforcement des paramètres de connexion par défaut du système, page 1-20 • Protection des terminaux sans surveillance, page 1-20 • Application de la déconnexion automatique, page 1-20 Les bureaux KDE et GNOME partagent quelques règles identiques de sécurité. Pour plus d’information concernant KDE et GNOME, consultez le manuel AIX 5L Version 5.2 Références et guide d’installation. Installation et configuration d’un système sécurisé 1-17 Pour obtenir des informations sur les utilisateurs, les groupes et les mots de passe, reportez–vous au chapitre Utilisateurs, rôles et mots de passe, page 2-1. Configuration de la fenêtre de connexion Pour renforcer la protection du système face aux attaques par identification du mot de passe, vous pouvez configurer la fenêtre de connexion dans le fichier /etc/security/login.cfg de cette manière : 1-18 Attribut S’applique aux PtY (réseau) S’applique aux TTY Valeur recommandée Commentaires sak_enabled O O false La clé SAK est rarement nécessaire. Voir Utilisation de la clé SAK (Secure Attention Key), page 1-5. logintimes N O logindisable N O 4 Désactiver la connexion sur ce terminal après 4 échecs de connexion consécutifs. logininterval N O 60 Le terminal sera désactivé lorsque que le nombre spécifié de tentatives aura été effectué dans les 60 secondes. Guide de sécurité Indiquer ici les heures de connexions autorisées. loginreenable N O 30 Le terminal sera réactivé 30 minutes après une désactivation automatique. logindelay O O 5 Temps en seconde entre les invites de connexion. Il sera multiplié par le nombre d’échecs de connexion, par exemple 5, 10, 15, 20 secondes quand 5 est la valeur initiale. Vous devez noter que ces restrictions de port fonctionnent généralement sur des terminaux de série reliés directement, et non sur des pseudo–terminaux utilisés via des connexions réseau. Vous pouvez indiquer des terminaux explicites dans ce fichier, par exemple : /dev/tty0: logintimes = 0600–2200 logindisable = 5 logininterval = 80 loginreenable = 20 Modification du message d’accueil de l’écran de connexion Pour éviter d’afficher certaines informations sur les écrans de connexion, modifiez le paramètre herald dans le fichier /etc/security/login.cfg. Par défaut, herald contient le message d’accueil qui s’affiche avec l’invite de connexion. Pour le modifier, utilisez la commande chsec ou bien modifiez le fichier directement. La commande chsec est utilisée dans l’exemple suivant pour modifier le paramètre par défaut herald : # chsec –f /etc/security/login.cfg –a default –herald ”L’accès non autorisé est interdit.\n\nlogin: ” Pour de plus amples informations sur la commande chsec, consultez le manuel AIX 5L Version 5.2 Commands Reference, Volume 1. Pour modifier le fichier directement, ouvrez–le /etc/security/login.cfg puis modifiez le paramètre herald de cette manière : default: herald =”L’accès non autorisé est interdit\n\nlogin:” sak_enable = false logintimes = logindisable = 0 logininterval = 0 loginreenable = 0 logindelay = 0 Remarque : Pour renforcer la sécurité du système, attribuez une valeur supérieure à 0 (# > 0) aux variables logindisable et logindelay . Installation et configuration d’un système sécurisé 1-19 Modification de l’écran de connexion Common Desktop Environment Ce problème concerne également les utilisateurs du Common Desktop Environment (CDE). L’écran de connexion CDE affiche également par défaut, le nom d’hôte et la version du système d’exploitation. Pour éviter d’afficher ces informations, modifiez le fichier /usr/dt/config/$LANG/Xresources, où $LANG se réfère à la langue locale installée sur votre poste. Dans notre exemple, supposons que $LANG soit défini sur C, copiez ce fichier dans /etc/dt/config/C/Xresources. Ensuite, ouvrez le fichier /usr/dt/config/C/Xresources puis modifiez–le en supprimant les messages d’accueil qui comportent le nom d’hôte et la version du système d’exploitation. Pour de plus amples informations sur les questions de sécurité du CDE, reportez–vous à la section Gestion des problèmes sous X11 et CDE, page 1-21. Renforcement des paramètres de connexion par défaut du système Editez le fichier /etc/security/login.cfg pour définir les paramètres de connexion par défaut, comme ceux que vous pourriez définir pour un nouvel utilisateur (nombre de tentatives de connexion, réactivation de la connexion et connexion interne). Protection de terminaux sans surveillance Tous les systèmes sont vulnérables si les terminaux connectés sont laissés sans surveillance. Le plus grave étant un administrateur qui abandonne son terminal, connecté sous l’identité de l’utilisateur root. En règle générale, les utilisateurs doivent se déconnecter avant de quitter leur terminal. Un terminal connecté sans surveillance est un risque majeur. La commande lock permet de verrouiller votre terminal. Avec l’interface AIXwindows, utilisez la commande xlock. Application de la déconnexion automatique Un autre sérieux problème de sécurité provient des utilisateurs qui laissent leurs comptes sans surveillance pendant une longue période. Un intrus peut profiter de cette situation pour prendre le contrôle d’un terminal utilisateur, compromettant ainsi la sécurité du système. Pour éviter ce type de risque, vous pouvez activer une déconnexion automatique du système. Pour ce faire, éditez le fichier /etc/security/.profile pour y intégrer une valeur de déconnexion automatique pour all utilisateurs, comme dans l’exemple suivant : TMOUT=600 ; TIMEOUT=600; export readonly TMOUT TIMEOUT Dans cet exemple, 600 est en secondes, soit 10 minutes. Cependant, cette méthode ne fonctionnera qu’à partir du shell. Elle ne fonctionnera pas si l’utilisateur est dans une application, par exemple vi. Même si cette action permet d’appliquer une politique de déconnexion automatique à tous les utilisateurs, il peuvent néanmoins contourner certaines restrictions en modifiant leurs propres fichiers .profile. Pour mettre en œuvre une politique de déconnexion automatique complète, fournissez aux utilisateurs des fichiers .profile appropriés, dépourvus de droits d’écriture. 1-20 Guide de sécurité Gestion des problèmes sous X11 et CDE Cette section traite des vulnérabilités de sécurité du serveur X11 et du Common Desktop Environment (CDE). Suppression du fichier /etc/rc.dt Bien que l’interface utilisateur graphique CDE soit pratique, elle apporte son lot de problèmes de sécurité. Pour cette raison, n’exécutez pas le CDE sur des serveurs qui nécessitent un niveau élevé de sécurité. Le meilleur moyen est de ne pas installer les ensembles de fichiers CDE (dt). Si vous les avez installés sur votre système, nous vous conseillons de les désinstaller, et tout particulièrement le script /etc/rc.dt, qui démarre le CDE. Pour de plus amples informations sur le CDE, consultez le manuel AIX 5L Version 5.2 System Management Guide: Operating System and Devices. Précautions à prendre pour éviter le contrôle non autorisé des serveurs X distants Un problème important de sécurité associé au serveur X11 est une écoute discrète et non autorisée d’un serveur distant. Les commandes xwd et xwud permettent de contrôler l’activité d’un serveur X car elles peuvent capturer la frappe, ce qui permet de connaître les mots de passe et autres données confidentielles. Pour résoudre ce problème, supprimez ces exécutables s’ils ne sont pas indispensables à votre configuration, ou bien limitez ces commandes à un accès root. Les commandes xwd et xwud se trouvent dans l’ensemble de fichiers X11.apps.clients. Si vous devez les conserver, utilisez OpenSSH ou MIT Magic Cookies. Ces applications tierces facilite la prévention des risques créés par l’exécution des commandes xwd et xwud. Pour de plus amples informations sur OpenSSH et MIT Magic Cookies, consultez leurs documentations respectives. Activation et désactivation du contrôle d’accès Le serveur X permet aux hôtes distants d’utiliser la commande xhost + pour se connecter à votre système. Assurez–vous d’indiquer un nom d’hôte à la commande xhost +, car elle désactive le contrôle d’accès du serveur X. Cela permet d’autoriser l’accès à des hôtes spécifiques et facilite le contrôle des attaques potentielles du serveur X. Pour ce faire, lancez la commande xhost : # xhost + nomhôte Pour de plus amples informations sur la commande xhost, consultez AIX Commands Reference, Volume 6. Désactivation des droits utilisateurs sur la commande xhost Une autre manière de s’assurer de l’utilisation de la commande xhost, est de la limiter au superutilisateur. Pour cela, utilisez la commande chmod pour modifier les droits du /usr/bin/X11/xhost à 744. chmod 744/usr/bin/X11/xhost Assurez–vous d’indiquer un nom d’hôte à la commande xhost +, car elle désactive le contrôle d’accès du serveur X. Cela permet d’autoriser l’accès à des hôtes spécifiques et facilite le contrôle des attaques potentielles du serveur X. Si vous n’indiquez aucun nom d’hôte, l’accès sera accordé à tous les hôtes. Installation et configuration d’un système sécurisé 1-21 1-22 Guide de sécurité Chapitre 2. Utilisateurs, rôles et mots de passe Ce chapitre décrit les méthodes de gestion des rôles et utilisateurs AIX. Il traite des points suivants : • Le compte Root, page 2-1 • Rôles administratifs, page 2-2 • Comptes Utilisateurs, page 2-8 • Configuration d’un accès FTP anonyme avec un compte utilisateur sécurisé, page 2-11 • Comptes utilisateurs spécifiques au système, page 2-15 • Listes de contrôle des accès (ACL), page 2-17 • Mots de passe, page 2-23 • Authentification de l’utilisateur, page 2-30 • Présentation du système de quotas de disque, page 2-30 Le compte Root Le compte root dispose d’un accès illimité à tous les programmes, fichiers et ressources d’un système. Le compte root est plus connu sous le nom de superutilisateur. Le superutilisateur est l’utilisateur spécial dans le fichier /etc/passwd, avec un ID utilisateur (UID) de 0. Le nom d’utilisateur root lui est généralement attribué. Ce n’est donc pas le nom d’utilisateur qui rend le compte root si spécial, mais son UID de 0. Ce qui signifie que tout utilisateur possédant un UID de 0 possède les mêmes droits que le superutilisateur. Par ailleurs, le compte root est toujours authentifié au moyen des fichiers locaux de sécurité. Le compte root doit toujours posséder un mot de passe, lequel ne doit jamais être partagé. Un mot de passe doit être attribué au compte root immédiatement après l’installation du système. Seul l’administrateur système doit connaître le mot de passe root. Les administrateurs système ne peuvent utiliser root que pour effectuer des fonctions d’administration exigeant des droits d’accès root. Pour toutes les autres opérations, ils doivent reprendre leur compte utilisateur normal. L’utilisation continue du compte root peut endommager le système car il s’affranchit de nombreuses sécurités. Désactivation de la connexion root directe Une des méthodes courantes d’attaque par des pirates informatiques est d’obtenir le mot de passe du superutilisateur, ou root. Pour éviter ce type d’attaque, vous pouvez désactiver l’accès direct à votre ID root et ensuite demander à vos administrateurs système qu’ils obtiennent des droits d’accès superutilisateur à l’aide de la commande su –. Outre le fait de supprimer l’utilisateur root comme point d’attaque, la suppression de l’accès root direct vous permet de contrôler quel utilisateur a obtenu un accès superutilisateur, ainsi que la durée de son action. Pour ce faire, vous pouvez consulter le fichier /var/adm/sulog. Vous pouvez aussi activer la fonction d’audit du système, qui rendra compte de ce type d’activité. Pour désactiver l’accès distant à la connexion pour votre utilisateur root, modifiez le fichier /etc/security/user. Indiquez false pour rlogin dans l’entrée de root. Avant de désactiver la connexion root distante, réfléchissez aux situations qui empêcheraient un administrateur système de se connecter sous un ID utilisateur non–root. Par exemple, si le système de fichiers principal est saturé, l’utilisateur ne pourra alors pas Utilisateurs, rôles et mots de passe 2-1 se connecter. Si la connexion root distante est désactivée, et que l’utilisateur qui pouvait se connecter au compte root par su – a son système de fichiers principal saturé, root ne pourra jamais prendre le contrôle du système. Pour éviter ce problème, les administrateurs système peuvent se créer leurs propres systèmes de fichiers principaux disposant d’une capacité supérieure au système de fichiers standard. Pour obtenir plus d’informations sur le contrôle de la connexion root, reportez–vous aux sections Administration, page 1-11 et Configuration du port et de l’utilisateur, page 1-11. Rôles administratifs Vous pouvez attribuer certains des droits d’accès root à des utilisateurs non–root. Les diverses tâches root disposent d’autorisations distinctes, groupées par rôles. Ce sont ces rôles qui peuvent être attribués à divers utilisateurs. Cette section traite des points suivants : • Présentation des rôles, page 2-2 • Configuration et maintenance des rôles à l’aide de l’outil SMIT, page 2-4 • Comprendre les autorisations, page 2-4. Présentation des rôles Les rôles sont des autorisations qui permettent à un utilisateur d’exécuter des fonctions qui normalement exigerait des droits d’accès root. Voici la liste des rôles possibles : 2-2 Ajout et suppression d’utilisateurs Permet à tout utilisateur de tenir ce rôle root. Il peut ajouter et supprimer des utilisateurs, modifier les informations ou classes d’audit, gérer des groupes et modifier des mots de passe. Toute personne qui administre les utilisateurs doit être dans le groupe security. Modification du mot de passe des utilisateurs Permet à un utilisateur de modifier les mots de passe. Gestion des rôles Permet à un utilisateur de créer, modifier, supprimer et répertorier les rôles. L’utilisateur doit être dans le groupe security. Sauvegarde et restauration Permet à un utilisateur de sauvegarder et restaurer des systèmes de fichiers et des répertoires. Ce rôle a besoin d’autorisations pour pouvoir activer la fonction sauvegarde et restauration du système. Sauvegarde uniquement Ne permet à un utilisateur que de sauvegarder des systèmes de fichiers et des répertoires. Cet utilisateur doit posséder l’autorisation adéquate pour pouvoir activer la sauvegarde du système. Guide de sécurité Exécution de diagnostics Permet à un utilisateur ou un technicien de maintenance d’exécuter des diagnostics et de diagnostiquer des tâches. L’utilisateur doit avoir l’option system comme groupe principal, ainsi qu’un ensemble de groupes comprenant shutdown. Remarque : Les utilisateurs du rôle Exécution de diagnostics peuvent modifier la configuration du système, mettre à jour le microcode, etc. Les utilisateurs de ce rôle doivent bien en comprendre le niveau de responsabilité. Arrêt du système Permet à un utilisateur d’arrêter, de redémarrer ou de suspendre un système. Utilisateurs, rôles et mots de passe 2-3 Configuration et maintenance des rôles à l’aide de SMIT Des raccourcis SMIT (voir tableau ci-après) sont disponibles pour la mise en œuvre et la maintenance des rôles. Tableau 5. Définition et maintenance des rôles Tâche Raccourci SMIT Ajout d’un rôle smit mkrole Modification des caractéristiques d’un rôle smit chrole Affichage des caractéristiques d’un rôle smit lsrole Retrait d’un rôle smit rmrole Liste des rôles smit lsrole Comprendre les autorisations Les autorisations sont les attributs des droits d’accès d’un utilisateur. Elles permettent à un utilisateur d’exécuter certaines tâches. Par exemple, l’autorisation UserAdmin permettra d’utiliser la commande mkuser pour créer un utilisateur administratif. Un utilisateur ne disposant pas de ces droits ne peut pas procéder à cette création. Il existe deux types d’autorisation : Autorisation principale Permet d’exécuter une commande spécifique. Par exemple, l’autorisation RoleAdmin est une autorisation principale permettant à l’administrateur d’un utilisateur d’exécuter la commande chrole. Sans cette autorisation, la commande s’interrompt sans avoir modifié les définitions du rôle. Modificateur d’autorisation Augmente les droits d’un utilisateur. Par exemple, l’autorisation UserAdmin augmente les capacités d’un administrateur appartenant au groupe security. Sans cette autorisation, la commande mkuser ne crée que des utilisateurs non administratifs. Avec cette autorisation, la commande mkuser crée également des utilisateurs administratifs. Correspondance entre les autorisations et les fonctions : Backup Effectue une sauvegarde du système. La commande suivante utilise l’autorisation Backup : Backup Diagnostics Sauvegarde des fichiers et des systèmes de fichiers. L’administrateur de l’utilisateur doit posséder l’autorisation Backup. Permet à un utilisateur d’exécuter des diagnostics. Ce droit d’accès est également obligatoire pour exécuter des tâches de diagnostic directement depuis la ligne de commande. La commande suivante utilise l’autorisation Diagnostics : diag Exécute des diagnostics sur des ressources sélectionnées. Si l’administrateur de l’utilisateur ne possède pas de droits d’accès Diagnostics, la commande ne s’exécute pas. GroupAdmin Exécute les fonctions de l’utilisateur root sur les données du groupe. Les commandes suivantes utilisent l’autorisation GroupAdmin : chgroup 2-4 Guide de sécurité Modifie les informations d’un groupe. Si l’utilisateur ne possède pas d’autorisation GroupAdmin, il ne peut modifier que les informations d’un groupe non administratif. chgrpmem Administre tous les groupes. Si l’administrateur d’un groupe ne possède pas d’autorisation GroupAdmin, il ne peut modifier que l’appartenance au groupe qu’il gère ou définit un utilisateur du groupe security pour gérer un groupe non administratif. chsec Modifie les données d’un groupe administratif dans les fichiers /etc/group et /etc/security/group. L’utilisateur peut également modifier les valeurs de strophe par défaut. Si l’utilisateur ne possède pas d’autorisation GroupAdmin, il ne peut modifier que les données d’un groupe non administratif dans les fichiers /etc/group et /etc/security/group. mkgroup Crée un groupe. Si l’utilisateur ne possède pas d’autorisation GroupAdmin, il ne peut créer que des groupes non administratifs. rmgroup Supprime un groupe. Si l’utilisateur ne possède pas d’autorisation GroupAdmin, il ne peut supprimer que des groupes non administratifs. ListAuditClasses Affiche la liste des classes d’audit valides. L’administrateur utilisant cette autorisation n’a pas besoin d’être l’utilisateur root ou de faire partie du groupe audit. Le raccourci smit mkuser ou smit chuser affiche la liste des classes d’audit disponibles pour créer ou modifier un utilisateur. Entrez la liste des classes d’audit dans la zone Classes d’AUDIT. PasswdAdmin Exécute les fonctions de l’utilisateur root sur les données des mots de passe. Les commandes suivantes utilisent l’autorisation PasswdAdmin : chsec Modifie les attributs lastupdate et flags de tous les utilisateurs. Sans l’autorisation PasswdAdmin, la commande chsec ne permet à l’administrateur que de modifier les attributs lastupdate et flags des utilisateurs non administratifs. lssec Affiche les attributs lastupdate et flags de tous les utilisateurs. Sans l’autorisation PasswdAdmin, la commande lssec ne permet à l’administrateur que d’afficher les attributs lastupdate et flags des utilisateurs non administratifs. pwdadm Modifie le mot de passe de tous les utilisateurs. L’administrateur doit être dans le groupe security. PasswdManageExécute l’administration des mots de passe des utilisateurs non administratifs. La commande suivante utilise l’autorisation PasswdManage : pwdadm UserAdmin Modifie le mot de passe d’un utilisateur non administratif. L’administrateur doit être dans le groupe security ou posséder l’autorisation PasswdManage. Exécute les fonctions de l’utilisateur root sur les données de l’utilisateur. Seuls les utilisateurs disposant de l’autorisation UserAdmin peuvent modifier les informations du rôle d’un utilisateur. Cette autorisation ne permet pas d’accéder ou de modifier les informations d’audit d’un utilisateur. Les commandes suivantes utilisent l’autorisation UserAdmin : chfn Modifie la zone informations générales (gecos) d’un utilisateur. Si l’utilisateur ne possède pas d’autorisation UserAdmin mais figure dans le groupe security, il peut modifier la zone gecos de tous les Utilisateurs, rôles et mots de passe 2-5 utilisateurs non administratifs. Par ailleurs, les utilisateurs ne peuvent modifier que leur propre zone gecos. chsec Modifie les données des utilisateurs administratifs dans les fichiers /etc/passwd, /etc/security/environ, /etc/security/lastlog, /etc/security/limits et /etc/security/user contenant l’attribut des rôles. L’administrateur peut également modifier les valeurs de strophe par défaut et le fichier /usr/lib/security/mkuser.default, à l’exception des attributs auditclasses. chuser Modifie les informations des utilisateurs, sauf l’attribut auditclasses. Si l’utilisateur ne possède pas d’autorisation UserAdmin, il ne peut modifier que les informations d’un utilisateur non administratif, à l’exception des attributs rôles et auditclasses. mkuser Crée un utilisateur, excepté pour l’attribut auditclasses. Si l’utilisateur ne possède pas d’autorisation UserAdmin, il ne peut créer que des utilisateurs non administratifs, excepté pour les attributs rôles et auditclasses. rmuser Supprime un utilisateur. Si l’administrateur ne possède pas d’autorisation UserAdmin, il ne peut supprimer que des utilisateurs non administratifs. UserAudit Permet à l’utilisateur de modifier des informations d’audit. Les commandes suivantes utilisent l’autorisation UserAudit : chsec Modifie l’attribut auditclasses du fichier mkuser.default pour les utilisateurs non administratifs. Si l’utilisateur possède une autorisation UserAdmin, il peut également modifier l’attribut auditclasses du fichier mkuser.default, pour les utilisateurs administratifs et non administratifs. chuser Modifie l’attribut auditclasses d’un utilisateur non administratif. Si l’administrateur possède une autorisation UserAdmin, il peut également modifier l’attribut auditclasses de tous les utilisateurs. lsuser Affiche l’attribut auditclasses d’un utilisateur non administratif s’il s’agit de l’utilisateur root ou s’il fait partie du groupe security. Si l’utilisateur possède une autorisation UserAdmin, il peut également afficher l’attribut auditclasses de tous les utilisateurs. mkuser Crée un nouvel utilisateur et permet à l’administrateur d’attribuer l’attribut auditclasses d’un utilisateur non administratif. Si l’utilisateur possède une autorisation UserAdmin, il peut également modifier l’attribut auditclasses de tous les utilisateurs. RoleAdmin Exécute les fonctions de l’utilisateur root sur les données du rôle. Les commandes suivantes utilisent l’autorisation RoleAdmin : chrole Modifie un rôle. Si l’administrateur ne possède pas d’autorisation RoleAdmin, la commande n’a pas d’effet. lsrole Affiche un rôle. mkrole Crée un rôle. Si l’administrateur ne possède pas d’autorisation RoleAdmin, la commande se termine. rmrole Supprime un rôle. Si l’administrateur ne possède pas d’autorisation RoleAdmin, la commande se termine. Restore Exécute une restauration du système. La commande suivante utilise l’autorisation Restore : 2-6 Guide de sécurité Restore Restaure des fichiers sauvegardés. L’administrateur doit posséder une autorisation Restore. Liste des commandes d’autorisation Voici la liste des commandes et des autorisations dont elles font usage. Commande Permissions Autorisations chfn 2555 root.security UserAdmin chuser 4550 root.security UserAdmin, UserAudit diag 0550 root.system Diagnostics lsuser 4555 root.security UserAudit, UserAdmin mkuser 4550 root.security UserAdmin, UserAudit rmuser 4550 root.security UserAdmin chgroup 4550 root.security GroupAdmin lsgroup 0555 root.security mkgroup 4550 root.security GroupAdmin rmgroup 4550 root.security GroupAdmin chgrpmem 2555 root.security GroupAdmin pwdadm 4555 root.security PasswdManage, PasswdAdmin passwd 4555 root.security chsec 4550 root.security UserAdmin, GroupAdmin, PasswdAdmin, UserAudit lssec 0550 root.security PasswdAdmin chrole 4550 root.security RoleAdmin lsrole 0550 root.security mkrole 4550 root.security RoleAdmin rmrole 4550 root.security RoleAdmin backup 4555 root.system Backup restore 4555 root.system Restore Utilisateurs, rôles et mots de passe 2-7 Comptes utilisateur • Attributs utilisateur recommandés, page 2-8 • Contrôle des comptes utilisateur, page 2-9 • ID de connexion, page 2-10 • Sécurisation à l’aide de listes de contrôle des accès (ACL), page 2-10 • Variable d’environnement PATH, page 2-10 Attributs utilisateur recommandés La gestion des utilisateurs consiste à créer des utilisateurs et des groupes, et à définir leurs attributs. L’un des principaux attributs est la méthode d’authentification. Les utilisateurs sont les principaux agents du système. Leurs attributs contrôlent leurs droits d’accès, environnement, méthode d’authentification, et la façon, le moment et l’emplacement où leurs comptes sont accessibles. Les groupes sont des ensembles d’utilisateurs pouvant partager les mêmes droits d’accès à des ressources protégées. Un groupe, défini par un ID, est composé de membres et d’administrateurs. Le créateur du groupe est généralement le premier administrateur. De nombreux attributs peuvent être définis pour chaque compte utilisateur, y compris les attributs de mot de passe et de connexion. Pour obtenir une liste des attributs pouvant être définis, consultez la section Présentation du système de quotas de disque, page 2-30. Les attributs suivants sont recommandés : • Chaque utilisateur doit disposer d’un ID utilisateur unique. Les outils de gestion de comptes et mesures de sécurité ne fonctionnent que si chaque utilisateur dispose de son propre ID. • Attribuez aux utilisateurs des noms permettant de les identifier facilement sur le système. L’idéal est de choisir leurs noms réels, car la plupart des systèmes de messagerie utilisent l’ID utilisateur pour référencer le message entrant. • Ajoutez, modifiez et supprimez des utilisateurs à l’aide du Web-based System Manager ou de l’interface SMIT. Bien que vous puissiez exécuter toutes ces tâches depuis la ligne de commandes, ces interfaces permettent d’éviter certaines erreurs. • N’attribuez pas de mot de passe à un compte utilisateur avant que l’utilisateur ne soit prêt à se connecter au système. Si le champ mot de passe a pour valeur un * (astérisque) dans le fichier /etc/passwd, les informations sur les comptes sont conservées, mais il est impossible de se connecter à ce compte. • Ne modifiez pas les ID utilisateur définis par le système, nécessaires à son bon fonctionnement. Ces ID utilisateur sont énumérés dans le fichier /etc/passwd. • En général, n’attribuez au paramètre admin la valeur true pour aucun ID utilisateur. Seul l’utilisateur root peut modifier les attributs des utilisateurs, et possède admin=true dans le fichier /etc/security/user. Le système d’exploitation prend en charge les attributs utilisateur standard habituels des fichiers /etc/passwd et /etc/group, tels que : 2-8 Informations d’authentification Définit le mot de passe Données d’identification Indique l’identifiant de l’utilisateur et les ID du groupe principal et des groupes complémentaires Environnement Indique l’environnement de shell et d’accueil. Guide de sécurité Contrôle des comptes utilisateur Un ensemble d’attributs est associé à chaque compte utilisateur. Ces attributs sont créés avec des valeurs par défaut lorsqu’un utilisateur est créé avec la commande mkuser. Ils peuvent être modifiés par la commande chuser. Vous trouverez ci–dessous la liste des attributs qui ne sont pas utilisés pour contrôler des aspects non liés à la qualité du mot de passe : account_locked Pour qu’un compte soit explicitement verrouillé, attribuez la valeur true à cet attribut. Sa valeur par défaut est false admin Avec la valeur true, cet utilisateur ne peut modifier son mot de passe. Seul l’administrateur peut le modifier. admgroups Répertorie les groupes pour lesquels l’utilisateur a des droits d’administrateur. Il peut ajouter ou supprimer des membres de ces groupes. auth1 Méthode d’authentification utilisée pour permettre l’accès des utilisateurs. Généralement, il a pour valeur SYSTEM, qui utilisera alors les méthodes les plus récentes. auth2 Méthode utilisée une fois l’utilisateur authentifié par la méthode spécifiée dans auth1. Elle ne peut pas bloquer l’accès au système. Généralement, sa valeur est NONE. daemon Ce paramètre booléen indique si l’utilisateur est autorisé à lancer des démons ou sous–systèmes à l’aide de la commande startsrc. Limite également l’utilisation de cron et at. login Indique si l’utilisateur a la possibilité d’établir une connexion. logintimes Limite les périodes d’accès d’un utilisateur. Par exemple, un utilisateur peut n’avoir accès au système que durant les heures de bureau. registry Indique le registre des utilisateurs. Il peut servir à indiquer au système des informations sur les utilisateurs contenues dans les différents registres, tels que NIS, LDAP or Kerberos. rlogin Indique si l’utilisateur a la possibilité d’établir une connexion via rlogin ou telnet. su Indique si d’autres utilisateurs peuvent passer sur cet ID à l’aide de la commande su. sugroups Indique quels groupes sont autorisés à passer sur cet ID ttys Limite certains comptes à des zones physiques sécurisées expires Gère les comptes d’étudiants ou d’invités ; permet aussi de désactiver des comptes temporairement loginretries Indique le nombre maximum d’échecs de connexion successifs avant le verrouillage de l’ID utilisateur par le système. Les échecs de connexion sont consignés dans /etc/security/lastlog. umask Indique l’umask initial de l’utilisateur L’ensemble des attributs utilisateur est défini dans les fichiers /etc/security/user, /etc/security/limits, /etc/security/audit/config et /etc/security/lastlog. La valeur utilisée par défaut lors de la création d’un utilisateur à l’aide de la commande mkuser est indiquée dans le fichier /usr/lib/security/mkuser.default. Seules les options qui remplacent les valeurs par défaut dans les strophes default de /etc/security/user et /etc/securtiy/limits, ainsi que les classes d’audit, doivent être spécifiées dans le fichier mkuser.default. Certains de ces attributs contrôlent la façon dont un utilisateur peut se connecter, et peuvent être configurés pour verrouiller automatiquement le compte utilisateur (empêcher les connexions suivantes) dans certaines conditions. Utilisateurs, rôles et mots de passe 2-9 Une fois le compte utilisateur verrouillé par le système, l’utilisateur ne peut plus se connecter avant que l’administrateur système ne réinitialise son attribut unsuccessful_login_count dans le fichier /etc/security/lastlog, à une valeur soit inférieure au nombre maximum d’échecs de connexion. Il faut pour cela utiliser la commande chsec suivante : chsec –f /etc/security/lastlog –s nomutilisateur –a unsuccessful_login_count=0 La commande chsec permettra de modifier les valeurs par défaut dans la strophe default du fichier de sécurité approprié, tel que /etc/security/user ou /etc/security/limits. De nombreuses valeurs par défaut sont définies comme comportement standard. Pour spécifier explicitement des attributs définis à chaque création d’utilisateur, modifiez l’entrée user dans /usr/lib/security/mkuser.default. Pour des informations sur les attributs de mot de passe étendus, consultez la section Mots de passe, page 2-23. ID de connexion Le système d’exploitation identifie les utilisateurs grâce à leur ID de connexion. Cet ID permet au système de suivre toutes les actions d’un utilisateur. Après la connexion d’un utilisateur, mais avant l’exécution de son programme initial, le système affecte l’ID de connexion du processus à l’ID utilisateur trouvé dans la base de données. Tous les processus suivants au cours de la session de connexion sont référencés par cet ID. Ces références permettent le suivi des activités exécutées par cet ID de connexion. Au cours de la session, l’utilisateur peut réinitialiser l’ID utilisateur effectif, l’ID utilisateur réel, l’ID de groupe effectif, l’ID de groupe réel, et les autres ID de groupe, mais il ne peut pas modifier l’ID de connexion. Sécurisation à l’aide de listes de contrôle des accès (ACL) Pour atteindre un niveau de sécurité système convenable, élaborez une politique de sécurité cohérente pour la gestion de tous les comptes utilisateur. La liste de contrôle des accès (ACL) est la méthode de sécurité la plus courante. Pour des informations sur les ACL et l’élaboration d’une politique de sécurité, consultez dans ce manuel la section sur les ACL. Variable d’environnement PATH La variable d’environnement PATH est importante pour la sécurité. Elle indique les répertoires dans lesquels une commande doit être recherchée. Pour l’ensemble du système, la valeur par défaut de PATH est indiquée dans le fichier /etc/profile. Chaque utilisateur dispose normalement d’une valeur PATH dans son fichier $HOME/.profile. La valeur PATH du fichier .profile remplace la valeur PATH du système ou lui ajoute des répertoires. Les modifications non autorisées à la variable d’environnement PATH peuvent permettre à un utilisateur connecté de tromper d’autres utilisateurs (y compris les utilisateurs root). Les programmes trompeurs (ou programmes Cheval de Troie) remplacent les commandes du système puis interceptent les informations destinées à cette commande, telles que les mots de passe. Par exemple, si un utilisateur modifie la valeur PATH de façon à ce que le système commence par rechercher le répertoire /tmp lorsqu’une commande est lancée, et qu’il place dans le répertoire /tmp un programme nommé su qui demande le mot de passe root comme le fait la commande su, alors le programme /tmp/su envoie le mot de passe root à cet utilisateur et appelle la commande su réelle avant de se fermer. Dans ce cas, tout utilisateur root ayant utilisé la commande su révélerait le mot de passe root sans même s’en rendre compte. Ceci n’est qu’un exemple de méthode d’acquisition d’informations confidentielles par la modification des valeurs PATH. 2-10 Guide de sécurité Toutefois, une procédure simple suffit pour éviter des problèmes liés à la variable d’environnement PATH : • Lorsque vous avez un doute, appelez une commande par le nom de chemin complet. Lorsque vous entrez un nom de chemin entier, la variable d’environnement PATH est ignorée. • Ne placez jamais le répertoire en cours (indiqué par. (point)) dans la valeur PATH indiquée pour l’utilisateur root. Ne permettez jamais la spécification du répertoire en cours dans /etc/profile. • L’utilisateur root doit avoir sa propre spécification PATH dans son .profile privé. Généralement, la spécification dans /etc/profile répertorie les éléments minimum standard pour tous les utilisateurs, alors que l’utilisateur root peut avoir besoin de plus ou de moins de répertoires que la valeur par défaut. • Prévenez les autres utilisateurs de ne pas modifier leurs fichiers .profile sans avoir consulté l’administrateur système. Autrement, un utilisateur pourrait apporter des modifications qui permettraient un accès non souhaité. Les droits d’un fichier .profile d’utilisateur doivent être définis sur 740. • Les administrateurs système ne doivent pas utiliser la commande su pour obtenir le privilège root depuis une session utilisateur, car la valeur PATH de l’utilisateur indiquée dans le fichier .profile est alors effective. Les utilisateurs peuvent définir leurs fichiers .profile comme bon leur semble. Les administrateurs système doivent se connecter au poste de l’utilisateur en tant que root, ou mieux, avec leur propre ID, et utiliser la commande suivante : /usr/bin/su – root Ceci assure d’utiliser l’environnement root au cours de la session. Si un administrateur système travaille en tant que root dans une autre session utilisateur, il doit alors indiquer des chemins d’accès complets au cours de la session. • Protégez la variable d’environnement IFS (input field separator) contre les modifications dans le fichier /etc/profile. Méfiez–vous de tout utilisateur qui modifie la variable IFS dans le fichier .profile. Elle peut servir à modifier la valeur PATH. Configuration d’un accès FTP anonyme avec un compte utilisateur sécurisé Le présent scénario configure un accès ftp anonyme avec un compte utilisateur sécurisé, à l’aide de l’interface de ligne de commandes et d’un script. Remarque : Ce scénario ne peut pas être utilisé sur un système équipé de CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+). 1. Vérifiez que l’ensemble de fichiers bos.net.tcp.client est installé sur votre système, à l’aide de la commande : lslpp –L | grep bos.net.tcp.client Si vous ne recevez aucune sortie, l’ensemble de fichiers n’est pas installé. Pour plus d’informations sur son installation, reportez–vous au manuel AIX 5L Version 5.2 – Références et guide d’installation. 2. Vérifiez que vous disposez d’au moins 8 Mo d’espace libre dans le répertoire /home du système : df –k /home Le script de l’étape 4 ci–dessous, nécessite au moins 8 Mo d’espace libre dans le répertoire /home pour installer les fichiers et répertoires nécessaires. Si vous devez Utilisateurs, rôles et mots de passe 2-11 augmenter l’espace disponible, reportez–vous au manuel AIX 5L Version 5.2 – System Management Guide: Operating System and Devices. 3. Avec les droits d’accès root, allez dans le répertoire /usr/samples/tcpip. Par exemple : cd /usr/samples/tcpip 4. Pour configurer le compte, exécutez le script suivant : ./anon.ftp 5. Lorsque l’invite Are you sure you want to modify /home/ftp? apparaît, entrez yes. Le résultat affiché sera semblable au suivant : Added Made Made Made Made Made Made user anonymous. /home/ftp/bin directory. /home/ftp/etc directory. /home/ftp/pub directory. /home/ftp/lib directory. /home/ftp/dev/null entry. /home/ftp/usr/lpp/msg/en_US directory. 6. Passez dans le répertoire /home/ftp. Par exemple : cd /home/ftp 7. Créez un sous–répertoire home, en entrant : mkdir home 8. Changez les droits d’accès du répertoire /home/ftp/home en drwxr–xr–x, en entrant : chmod 755 home 9. Passez dans le répertoire /home/ftp/etc, en entrant : cd /home/ftp/etc 10.Créez le sous–répertoire objrepos, en entrant : mkdir objrepos 11. Changez les droits d’accès du répertoire /home/ftp/etc/objrepos en drwxrwxr–x, en entrant : chmod 775 objrepos 12.Changez le propriétaire et le groupe du répertoire /home/ftp/etc/objrepos en utilisateur root et groupe système, en entrant : chown root:system objrepos 13.Créez un sous–répertoire security, en entrant : mkdir security 14.Changez les droits d’accès du répertoire / home/ftp/etc/security en drwxr–x–––, en entrant : chmod 750 security 15.Changez le propriétaire et le groupe du répertoire /home/ftp/etc/security en utilisateur root et groupe de sécurité, en entrant : chown root:security security 16.Passez dans le répertoire / home/ftp/etc/security, en entrant : cd security 17.Ajoutez un utilisateur à l’aide du raccourci SMIT suivant : smit mkuser Dans le présent scénario, nous ajoutons l’utilisateur test. 2-12 Guide de sécurité 18.Dans les zones SMIT, entrez les valeurs suivantes : NOM utilisateur ADMINISTRATEUR ? GROUPE principal ENSEMBLE de groupes Un autre utilisateur peut UTILISER SU ? répertoire HOME [test] true [staff] [staff] true [/home/test] Après avoir entré vos modifications, appuyez sur Entrée pour créer l’utilisateur. A la fin du processus SMIT, quittez SMIT. 19.Créez un mot de passe pour l’utilisateur à l’aide de la commande suivante : passwd test A l’invite, entrez le mot de passe voulu. Vous devez le saisir une deuxième fois pour confirmation. 20.Passez dans le répertoire /home/ftp/etc, en entrant : cd /home/ftp/etc 21.Copiez le fichier /etc/passwd en /home/ftp/etc/passwd à l’aide de la commande suivante : cp /etc/passwd /home/ftp/etc/passwd 22.Avec l’éditeur de votre choix, éditez le fichier /home/ftp/etc/passwd. Par exemple : vi passwd 23.Supprimez toutes les lignes du contenu copié, sauf celles concernant les utilisateurs root, ftp et test. Après modification, le contenu du fichier doit être semblable à ce qui suit : root:!:0:0::/:/bin/ksh ftp:*:226:1::/home/ftp:/usr/bin/ksh test:!:228:1::/home/test:/usr/bin/ksh 24.Enregistrez vos modifications et quittez l’éditeur. 25.Changez les droits d’accès du fichier /home/ftp/etc/passwd en –rw–r––r––, en entrant : chmod 644 passwd 26.Changez le propriétaire et le groupe du répertoire /home/ftp/etc/passwd en utilisateur root et groupe de sécurité, en entrant : chown root:security passwd 27.Copiez le contenu du fichier /etc/security/passwd vers /home/ftp/etc/security/passwd, à l’aide de la commande suivante : cp /etc/security/passwd /home/ftp/etc/security/passwd 28.Avec l’éditeur de votre choix, éditez le fichier /home/ftp/etc/security/passwd. Par exemple : vi ./security/passwd 29.Supprimez toutes les strophes du contenu copié, sauf celle concernant l’utilisateur test. 30.Supprimez la ligne flags = ADMCHG de la strophe de l’utilisateur test. Après modification, le contenu du fichier doit être semblable à ce qui suit : test: password = 2HaAYgpDZX3Tw lastupdate = 990633278 31.Enregistrez vos modifications et quittez l’éditeur. 32.Changez les droits d’accès du fichier /home/ftp/etc/security/passwd en –rw–––––––, en entrant : Utilisateurs, rôles et mots de passe 2-13 chmod 600 ./security/passwd 33.Changez le propriétaire et le groupe du répertoire /home/ftp/etc/ security/passwd en utilisateur root et groupe de sécurité, en entrant : chown root:security ./security/passwd 34.Avec l’éditeur de votre choix, éditez le fichier /home/ftp/etc/security/group. Par exemple : vi ./security/group 35.Ajoutez les lignes suivantes au fichier : system:*:0: staff:*:1:test 36.Enregistrez vos modifications et quittez l’éditeur. 37.A l’aide des commandes suivantes, copiez le contenu approprié dans le répertoire /home/ftp/etc/objrepos : cp /etc/objrepos/CuAt ./objrepos cp /etc/objrepos/CuAt.vc ./objrepos cp /etc/objrepos/CuDep ./objrepos cp /etc/objrepos/CuDv ./objrepos cp /etc/objrepos/CuDvDr ./objrepos cp /etc/objrepos/CuVPD ./objrepos cp /etc/objrepos/Pd* ./objrepos 38.Passez dans le répertoire /home/ftp/home, en entrant : cd ../home 39.Créez un nouveau répertoire personnel pour votre utilisateur, en entrant : mkdir test Il s’agira du répertoire de travail du nouvel utilisateur ftp. 40.Changez le propriétaire et le groupe du répertoire /home/ftp/home/test en utilisateur test et en groupe système, en entrant : chown test:staff test 41.Changez les droits d’accès du fichier /home/ftp/home/test en –rwx––––––, en entrant : chmod 700 test A ce stade, une sous–connexion ftp est configurée sur votre machine. Vous pouvez la tester grâce à la procédure ci–après : 1. Avec ftp, connectez–vous à l’hôte sur lequel vous avez créé l’utilisateur test. Par exemple : ftp MyHost 2. Connectez–vous en tant qu’utilisateur anonymous. Lorsque vous êtes invité à spécifier un mot de passe, appuyez sur Entrée. 3. Basculez sur le nouvel utilisateur test, à l’aide de la commande suivante : user test A l’invite de mot de passe, utilisez celui que vous avez créé à l’étape 19 ci–dessus. 4. Servez–vous de la commande pwd pour vérifier que le répertoire personnel de l’utilisateur existe. Par exemple : ftp> pwd /home/test /home/test apparaît alors comme sous–répertoire ftp. En fait, le nom du chemin d’accès complet sur l’hôte est /home/ftp/home/test. 2-14 Guide de sécurité Comptes utilisateurs spécifiques au système AIX fournit un ensemble par défaut de comptes utilisateur spécifiques au système, qui évite à l’utilisateur root et au système de détenir tous les fichiers et systèmes de fichiers du système d’exploitation. Attention : Soyez prudent lors de la suppression d’un compte utilisateur spécifique au système. Vous pouvez désactiver un compte en insérant un astérisque (*) au début de la ligne correspondante du fichier /etc/security/passwd. Faites attention à ne pas désactiver le compte root. Si vous supprimez des comptes utilisateur spécifiques au système ou désactivez le compte root, le système d’exploitation ne fonctionnera pas. Les comptes suivants sont prédéfinis dans le système d’exploitation : root Le compte utilisateur root, UID 0, parfois appelé superutilisateur, qui permet d’exécuter les tâches de maintenance et de résoudre les problèmes du système. daemon Ce compte utilisateur sert uniquement à détenir et exécuter les processus serveur du système et les fichiers associés. Ce compte garantit que ces processus s’exécutent avec les droits appropriés d’accès aux fichiers. bin Le compte utilisateur bin détient généralement les fichiers exécutables pour la plupart des commandes utilisateur. Son rôle principal est d’aider à répartir la propriété des répertoires et fichiers système importants, afin que tout ne soit pas détenu uniquement par les comptes utilisateur root et sys. sys L’utilisateur sys détient le point de montage par défaut du cache DFS (Distributed File Service), qui doit exister préalablement à l’installation et à la configuration du DFS sur un client. Le répertoire /usr/sys sert également à stocker les images d’installation. adm Le compte utilisateur adm détient deux fonctions système de base : 1. Diagnostics, dont les outils sont stockés dans le répertoire /usr/sbin/perf/diag_tool. 2. Comptabilité, dont les outils sont stockés dans les répertoires suivants : – /usr/sbin/acct – /usr/lib/acct – /var/adm – /var/adm/acct/fiscal – /var/adm/acct/nite – /var/adm/acct/sum nobody Le compte utilisateur nobody est utilisé par le produit NFS (Network File System) pour permettre les impressions à distance. Ce compte permet à un programme d’accorder un accès root temporaire aux utilisateurs root. Par exemple, avant d’activer RPC sécurisé ou NFS sécurisé, contrôlez la clé /etc/public sur le serveur NIS maître pour vérifier si un utilisateur ne s’est pas vu attribuer une clé publique et une clé secrète. En tant qu’utilisateur root, vous pouvez créer une entrée dans la base de données pour chaque utilisateur sans affectation, en entrant : newkey –u nomutilisateur Vous pouvez aussi créer une entrée dans la base de données pour le compte utilisateur nobody, chaque utilisateur pourra alors exécuter le programme chkey pour créer ses propres entrées dans la base de données, sans se connecter en tant que root. Utilisateurs, rôles et mots de passe 2-15 Suppression de comptes utilisateur par défaut inutiles Lors de l’installation du système d’exploitation, plusieurs ID utilisateur et de groupe sont créés. Selon les applications exécutées sur votre système et selon l’emplacement de votre système sur le réseau, certains de ces ID utilisateur et de groupe peuvent devenir des éléments vulnérables qui nuisent à la sécurité. Si ces ID utilisateur et de groupe ne sont pas nécessaires, vous pouvez les retirer pour minimiser les risques. Le tableau suivant répertorie les ID utilisateur par défaut que vous pouvez le plus souvent supprimer : Tableau 6. ID utilisateur par défaut que vous pourrez souvent supprimer. ID utilisateur Description uucp, nuucp Détenteur de fichiers cachés utilisés par le protocole uucp. Le compte utilisateur uucp est utilisé pour le programme de copie UNIX–to–UNIX, lequel est un groupe de commandes, programmes, et fichiers, présent sur la plupart des systèmes UNIX, et permettant de communiquer avec un autre système UNIX via une ligne dédiée ou une ligne téléphonique. lpd Détenteur de fichiers utilisés par le sous–système d’impression imnadm Moteur de recherche IMN (utilisé par Documentation Library Search) guest Permet l’accès aux utilisateurs qui n’ont normalement pas accès aux comptes Le tableau suivant répertorie les ID de groupe que vous pouvez peut–être supprimer : Tableau 7. ID de groupe que vous pouvez peut–être supprimer. ID de groupe Description uucp Groupe auquel appartiennent les utilisateurs nuucp uucpand printq Groupe auquel appartient l’utilisateur lpd imnadm Groupe auquel appartient l’utilisateur imnadm Analysez votre système pour déterminer quels ID ne sont pas nécessaires. Il se peut que d’autres ID utilisateur ou de groupe ne soient pas nécessaires. Avant de commencer à exploiter votre système, effectuez une évaluation complète des ID disponibles. 2-16 Guide de sécurité Listes de contrôle des accès (ACL) Le contrôle des accès est assuré par des ressources protégées, qui déterminent qui est habilité à accéder à ces ressources. Le système d’exploitation permet le contrôle discrétionnaire et l’accès sélectif: Le propriétaire d’une ressource d’informations peut accorder aux autres utilisateurs des droits d’accès en lecture ou en écriture à cette ressource. Un utilisateur autorisé à accéder à un objet peut créer des copies de cet objet et accorder à un tiers l’accès à ce nouvel objet. Par contre, seul le propriétaire de l’objet peur accorder à un tiers l’accès à l’objet d’origine. Le propriétaire d’un objet et l’utilisateur root sont les seuls utilisateurs autorisés à modifier les droits d’accès à un objet. Les utilisateurs disposent de droits d’accès de type utilisateur sur les seuls objets qui leur appartiennent. D’une façon générale, les utilisateurs se voient octroyer les droits de leur groupe ou les droits par défaut sur une ressource. La principale tâche au niveau de l’administration du contrôle des accès est de définir les membres des groupes, l’appartenance à un groupe déterminant de fait l’accès aux fichiers du système (autres que ceux créés par l’utilisateur). Les ACL améliorent la qualité des contrôles d’accès aux fichiers, en créant des droits étendus, qui modifient les droits de base attribués aux individus et aux groupes. Par le biais de ces droits étendus, vous pouvez autoriser ou interdire l’accès à un fichier sans modifier les droits de base. Le contrôle d’accès comporte également la gestion des ressources protégées avec les programmes setuid et setgid et l’étiquetage des copies. Le système d’exploitation prend en charge plusieurs types de ressources de données ou objets. Ces objets permettent aux processus utilisateur de stocker ou de communiquer des données. Les principaux types d’objets sont les suivants : • Fichiers et répertoires (servant au stockage de données), • Tubes nommés, files d’attente de messages, segments de mémoire partagée et sémaphores (servant au transfert de données entre processus). Un propriétaire, un groupe et un mode sont associés à chaque objet. Le mode définit les droits d’accès du propriétaire, du groupe et des autres utilisateurs. Voici les attributs de contrôle d’accès direct pour les différents types d’objets : Utilisateurs, rôles et mots de passe 2-17 Owner Le propriétaire d’un objet spécifique contrôle ses attributs d’accès discrétionnaire. Les attributs du propriétaire sont affectés à l’ID utilisateur effectif du processus créé. Pour les objets système de fichiers, les attributs de contrôle d’accès direct d’un propriétaire ne peuvent être modifiés sans privilège root. Pour les objets SVIPC (System V InterProcess Communication), le propriétaire peut être modifié par le créateur ou par le propriétaire. Le créateur associé à ces objets possède les mêmes droits que le propriétaire (y compris l’autorisation d’accès). Le créateur ne peut être modifié, même avec les privilèges root. Group Les objets SVIPC sont initialisés à l’ID groupe effectif du processus créé. Pour les objets système de fichiers, les attributs de contrôle d’accès direct sont initialisés à l’ID groupe effectif du processus créé ou à l’ID groupe du répertoire parent (ceci est défini par l’indicateur héritage du groupe du répertoire parent). Le propriétaire d’un objet peut modifier le groupe ; le nouveau groupe est obligatoirement l’ID groupe effectif du processus créé ou l’ID groupe du répertoire parent. Le propriétaire d’un objet peut modifier le groupe ; le nouveau groupe est obligatoirement l’ID groupe effectif ou l’ID groupe supplémentaire du processus courant du propriétaire. Comme indiqué plus haut, les objets SVIPC ont un groupe de création associé qui ne peut être modifié et partage l’autorisation d’accès du groupe objet. Remarque : Une liste de contrôle des accès ne peut pas excéder une page mémoire (environ 4096 octets). Les listes de contrôle des accès sont maintenues par les commandes aclget, acledit et aclput. La commande chmod en mode numérique (avec notation octale) peut définir des droits d’accès et des attributs de base. La sous–routine chmod, appelée par la commande, désactive les droits d’accès étendus. Donc, si vous utilisez le mode numérique de la commande chmod sur un fichier doté d’une liste ACL, les droits étendus sont désactivés. Le mode symbolique de la commande chmod ne désactive pas ces droits. Pour en savoir plus sur ces modes, reportez–vous à la commande chmod. Utilisation des programmes setuid et setgid Le mécanisme de bits d’autorisation permet le contrôle d’accès effectif des ressources dans la plupart des situations. Pour un contrôle plus précis, le système d’exploitation propose les programmes setuid et setgid. La plupart des programmes sont exécutés avec les droits d’accès utilisateur et groupe de l’utilisateur qui les a appelés. Les propriétaires de programmes peuvent associer les droits d’accès de l’utilisateur qui a appelé ces programmes en transformant ces derniers en programmes setuid ou setgid, c’est–à–dire en définissant dans leur zone d’autorisation le bit setuid ou setgid. Quand le processus exécute le programme, il obtient les droits d’accès du propriétaire du programme. Un programme setuid s’exécute avec les droits d’accès de son propriétaire, tandis qu’un programme setgid a les droits d’accès de son groupe ; les deux bits peuvent être définis en fonction du mécanisme d’autorisation. Bien que les droits d’accès supplémentaires soient attribués au processus, ils sont contrôlés par le programme qui les possède. Ainsi, setuid et setgid permettent les contrôles d’accès programmés par l’utilisateur dans lesquels les droits d’accès sont attribués indirectement. Le programme fonctionne comme un sous–système sécurisé, surveillant les droits d’accès utilisateur. setuid et setgid sont très efficaces, mais peuvent mettre la sécurité en danger s’ils ne sont pas soigneusement mis en œuvre. Notamment, le programme ne doit jamais renvoyer le 2-18 Guide de sécurité contrôle à l’utilisateur s’il détient toujours les droits d’accès de son propriétaire, ce qui permettrait à l’utilisateur d’utiliser sans restriction les droits du propriétaire. Remarque : Pour des raisons de sécurité, le système d’exploitation interdit les appels setuid ou setgid depuis un script shell. Droits d’accès administratifs Le système d’exploitation fournit des droits d’accès privilégiés pour la gestion du système. Les privilèges système sont fondés sur les ID utilisateur et groupe. Sont reconnus privilégiés les utilisateurs dont l’ID utilisateur ou groupe effectif est défini à 0. Les processus avec un ID utilisateur effectif à 0 sont des processus réputés utilisateur root qui peuvent : • Lire ou écrire tout objet • Appeler toute fonction système • Effectuer certains contrôles de sous–système avec les programmes setuidroot. Il existe deux types de privilèges pour l’administration du système : le privilège de la commande su et celui du programme setuid–root. Avec la commande su, tous les programmes appelés fonctionnent comme des processus utilisateur root ; elle permet une gestion souple du système, mais n’est pas particulièrement sûre. Passer un programme en programme setuid–root signifie que le programme appartient à un utilisateur root avec le bit setuid défini. Un programme setuid–root offre des fonctions administratives à tout utilisateur sans compromettre la sécurité ; le privilège n’est pas directement accordé à l’utilisateur, il est encapsulé dans le programme. Encapsuler toutes les fonctions administratives nécessaires dans des programmes setuid–root n’est pas un procédé particulièrement simple, mais il est sûr. Droits d’accès de base Les droits de base sont constitués des droits d’accès attribués normalement au propriétaire du fichier, au groupe associé et aux autres utilisateurs. Il s’agit des droits d’accès : en lecture (r), en écriture (w) et en exécution/recherche(x). Dans une liste de contrôle des accès, les droits de base sont au format suivant, le paramètre Mode étant exprimé sous la forme rwx (un tiret indiquant l’absence de droit) : droit d’accès de base owner(nom): Mode group(groupe): Mode others: Mode Attributs Trois attributs peuvent être ajoutés à une liste de contrôle des accès: setuid (SUID) Le bit de mode Set–user–ID. Cet attribut définit les ID utilisateur enregistré et effectif du processus, avec l’ID du propriétaire du fichier exécuté. setgid (SGID) Le bit de mode Set–group–ID. Cet attribut définit les ID de groupe enregistré et effectif du processus avec l’ID de groupe du fichier exécuté. savetext (SVTX) Indique que seuls les propriétaires de fichiers peuvent créer ou supprimer des liens entre fichiers, dans le répertoire indiqué. Ces attributs sont ajoutés au format suivant : attributs : SUID, SGID, SVTX Utilisateurs, rôles et mots de passe 2-19 Droits d’accès étendus Les droits étendus sont un moyen pour le propriétaire d’un fichier d’affiner les droits d’accès à ce fichier. Ils permettent de modifier les droits de base (utilisateur, groupe et autres) en accordant, en supprimant ou en spécifiant des droits spécifiques pour des individus, des groupes ou des combinaisons de groupes. Les droits d’accès sont modifiés à l’aide de mots clés. Les mots clés permit, deny et specify sont définis comme suit : permit Accorde à l’utilisateur ou au groupe le droit spécifié sur le fichier deny Retire à l’utilisateur ou au groupe le droit spécifié sur le fichier specify Définit précisément les droits de l’utilisateur ou du groupe sur le fichier Si un droit est refusé à un utilisateur par le biais de deny ou de specify, ce refus ne peut être rétabli par aucune autre entrée. La liste de contrôle des accès (ACL) doit être activée (mot clé enabled) pour que les droits étendus prennent effet. La valeur par défaut est disabled. Dans une liste ACL, les droits étendus apparaissent sous la forme : droits d’accès étendus enabled | disabled permit Mode InfoUtil...: deny Mode InfoUtil...: specify Mode InfoUtil...: Placez chacune des entrées permit, deny et specify sur une ligne distincte. Le paramètre Mode est sous la forme rwx (un tiret indiquant l’absence de droit). Le paramètre InfoUtil est sous la forme u:NomUtilisateur ou g:NomGroupe, ou encore par une combinaison séparée par une virgule de u:NomUtilisateur et g:NomGroupe. Remarque : Si vous spécifiez plusieurs noms dans une entrée, elle ne peut être utilisée dans une décision de contrôle d’accès, un processus n’ayant qu’un seul ID utilisateur. Exemple de liste de contrôle des accès Voici un exemple d’ACL : attributes: SUID base permissions: owner(frank): rw– group(system): r–x others: ––– extended permissions: enabled permit rw– u:dhs deny r–– u:chas, g:system specify r–– u:john, g:gateway, g:mail permit rw– g:account, g:finance Voici la signification des différents éléments de cette liste : • La première ligne indique que le bit setuid est activé. • La deuxième ligne, qui introduit les droits de base, est facultative. • Les trois lignes suivantes précisent ces droits. Les noms du propriétaire et du groupe (entre parenthèses) sont donnés à titre d’information : les modifier n’a pas d’incidence sur le propriétaire réel du fichier, pas plus que sur le groupe auquel appartient le fichier. Seules les commandes chown et chgrp permettent de modifier ces attributs. • La ligne suivante, qui introduit les droits étendus, est facultative. • La ligne suivante indique que les droits étendus qui suivent sont activés. 2-20 Guide de sécurité • Les quatre dernières lignes correspondent aux droits étendus : la première accorde à l’utilisateur dhs l’accès en lecture (r) et en écriture (w) au fichier. • La deuxième interdit l’accès en lecture (r) à l’utilisateur chas lorsqu’il est membre du groupe system. • La troisième accorde à l’utilisateur john l’accès en lecture (r) tant qu’il est membre des deux groupes gateway et mail. S’il n’appartient pas à ces deux groupes, l’accès lui est refusé. • La dernière ligne, enfin, accorde à tout utilisateur membre des deux groupes account et finance l’accès en lecture (r) et en écriture (w). Remarque : Plusieurs entrées étendues peuvent s’appliquer à un processus qui demande l’accès à un objet contrôlé, les entrées restrictives ont la priorité sur les modes permissifs. Pour obtenir des détails sur la syntaxe, reportez–vous à la description de la commande acledit dans le manuel AIX 5L Version 5.2 Commands Reference. Autorisations d’accès Le propriétaire de la ressource d’informations est responsable de la gestion des droits d’accès. Les ressources sont protégées par des bits d’accès, intégrés au mode de l’objet. Ces bits définissent les droits du propriétaire de l’objet, ceux du groupe correspondant et ceux de la classe par défaut autres. Le système d’exploitation gère trois droits d’accès (lecture, écriture et exécution), qui peuvent être accordés séparément. Lorsqu’un utilisateur se connecte à un compte (via une commande login ou su), les ID utilisateur et groupe attribués au compte sont associés aux processus de cet utilisateur et en déterminent les droits d’accès. Ces ID déterminent les droits d’accès du processus. Pour les fichiers, les répertoires, les tubes nommés, et les unités (fichiers spéciaux), les accès sont définis comme suit : • Pour chaque entrée (ACE) de la liste de contrôle des accès (ACL), la liste des identificateurs est comparée aux identificateurs du processus. Si elles sont identiques, le processus se voit attribuer les droits et les interdits définis pour cette entrée. Les correspondances logiques pour les droits comme pour les interdits sont calculées pour chaque entrée concernée de l’ACL. Si le processus demandeur ne correspond à aucune entrée de l’ACL, il se voit attribuer les droits associés à l’entrée par défaut. • Si le droit d’accès demandé est autorisé (inclus dans l’union des droits) et non interdit (inclus dans l’union des interdits), l’accès est accordé. Sinon, il est refusé. Un processus doté de l’ID utilisateur 0 est dit processus utilisateur root. Ces processus ont généralement tous les droits. Mais si un processus root demande le droit d’exécution sur un programme, celui–ci ne lui est accordé que s’il est détenu par au moins un utilisateur. La liste des identificateurs d’une ACL correspond à un processus si tous ses identificateurs correspondent à l’identificateur effectif – de même type – du processus demandeur. Un identificateur de type USER correspond à un processus s’il est identique à l’ID utilisateur effectif du processus. Un identificateur de type GROUP correspond s’il est identique à l’ID groupe effectif du processus ou à l’un des ID des groupes complémentaires. Ainsi, une ACE avec la liste d’identificateurs suivante : USER:fred, GROUP:philosophers, GROUP:software_programmer correspondra au processus dont l’ID utilisateur est fred et l’ensemble de groupes : philosophers, philanthropists, software_programmer, doc_design mais pas au processus dont l’ID utilisateur est fred avec l’ensemble de groupes : philosophers, iconoclasts, hardware_developer, graphic_design Notez qu’une ACE avec la liste suivante correspond aux deux processus : USER:fred, GROUP:philosophers Utilisateurs, rôles et mots de passe 2-21 En d’autres termes, la liste d’identificateurs de l’ACE fonctionne comme un ensemble de conditions, à respecter pour que l’accès spécifié soit accordé. Tous les contrôles d’accès pour ces objets sont effectués au niveau de l’appel système, au moment du premier accès aux objets. Dans la mesure où l’accès aux objets SVIPC n’est pas nominatif, les contrôles sont effectués à chaque accès. Pour les objets avec noms de systèmes de fichiers, il est nécessaire de pouvoir résoudre le nom de l’objet réel. Les noms sont résolus de façon relative (au répertoire de travail du processus) ou absolue (par rapport au répertoire root du processus). Toute résolution de nom commence par la recherche de l’un de ces deux éléments. Le mécanisme de contrôle d’accès discrétionnaire assure un contrôle effectif de l’accès aux ressources ainsi qu’une protection distincte de la confidentialité et de l’intégrité des informations. Les mécanismes de contrôle gérés par le propriétaire ne sont effectifs que s’ils sont définis par les utilisateurs. Tous les utilisateurs doivent maîtriser le mécanisme d’octroi et de refus de droits d’accès. 2-22 Guide de sécurité Mots de passe Deviner les mots de passe est l’une des méthodes d’attaque les plus répandues. Il est donc essentiel de contrôler et surveiller votre politique de gestion des mots de passe. AIX intègre des mécanismes qui vous aideront à appliquer une politique de mots de passe plus efficace, telle que la définition de valeurs pour les données suivantes : • Nombres minimum et maximum de semaines écoulées avant et après la modification d’un mot de passe • Longueur minimum d’un mot de passe • Nombre minimum de caractères alphabétiques pouvant être utilisés lors de la sélection d’un mot de passe Cette section traite la façon dont AIX conserve et gère les mots de passe, et indique comment mettre en place une politique de mots de passe efficace. Les sujets traités dans cette section sont : • Qu’est–ce qu’un bon mot de passe ?, page 2-23 • Le fichier /etc/passwd, page 2-24 • Le fichier /etc/passwd et les environnements réseau, page 2-25 • Dissimulation des noms d’utilisateur et mots de passe, page 2-25 • Paramétrage des options de mot de passe recommandées, page 2-25 • Extension des restrictions de mot de passe, page 2-29 Qu’est–ce qu’un bon mot de passe ? Les mots de passe sont la première ligne de défense contre l’accès non autorisé aux systèmes. Pour être efficaces, ils doivent répondent aux critères suivants : • Un mélange de lettres en minuscules et majuscules. • Ils comportent des caractères alphabétiques, numériques ou de ponctuation. Il est aussi possible d’utiliser certains caractères tels que ~!@#$%^&*()–_=+[]{}|\;:’”,.?/<espace>. • Ils ne sont écrits nulle part. • Ils sont composés de sept à huit caractères, en cas d’utilisation du fichier /etc/security/passwd (d’autres règles d’authentification qui utilisent des registres, comme LDAP, autorisent des mots de passe plus longs). • Ne figurent pas dans les dictionnaires. • Ne sont pas des suites de lettres du clavier, telles que azerty. • Ne sont pas des mots réels ou suites de lettres connus, épelés à l’envers. • Ne contiennent aucune information sur vous–même, votre famille ou vos amis. • Ne ressemblent pas au précédent mot de passe • Peuvent être saisis rapidement, pour ne pas être identifiés par une personne à côté de vous. Vous pouvez également définir des règles plus strictes, interdisant l’utilisation dans les mots de passe de termes UNIX standard pouvant être devinés. Cette fonction utilise dictionlist, qui nécessite l’installation préalable des ensembles de fichiers bos.data et bos.txt. Pour mettre en place dictionlist, modifiez la ligne qui suit dans le fichier /etc/security/users : dictionlist = /usr/share/dict/words Utilisateurs, rôles et mots de passe 2-23 Le fichier /usr/share/dict/words fait appel à dictionlist pour empêcher l’utilisation des termes UNIX standard en tant que mot de passe. Le fichier /etc/passwd Habituellement, le fichier /etc/passwd est utilisé pour garder la trace de tous les utilisateurs enregistrés ayant accès au système. Le fichier /etc/passwd utilise le caractère ”:” comme séparateur. Il contient les informations suivantes : • nom d’utilisateur • mot de passe chiffré • ID utilisateur (UID) • ID du groupe de l’utilisateur (GID) • nom complet de l’utilisateur (GECOS) • répertoire personnel de l’utilisateur • shell de connexion Voici un exemple de fichier /etc/passwd : root:!:0:0::/:/usr/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: guest:!:100:100::/home/guest: nobody:!:4294967294:4294967294::/: lpd:!:9:4294967294::/: lp:*:11:11::/var/spool/lp:/bin/false invscout:*:200:1::/var/adm/invscout:/usr/bin/ksh nuucp:*:6:5:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico imnadm:*:188:188::/home/imnadm:/usr/bin/ksh paul:!:201:1::/home/paul:/usr/bin/ksh jdoe:*:202:1:John Doe:/home/jdoe:/usr/bin/ksh Au contraire d’UNIX, qui conserve les mots de passe chiffrés dans le fichier /etc/password, AIX les enregistre par défaut dans le fichier /etc/security/password, lisible uniquement par le superutilisateur. AIX utilise le mot de passe classé dans /etc/passwd pour déterminer si un mot de passe existe ou si le compte est bloqué. Le fichier /etc/passwd doit être accessible en lecture par tous les utilisateurs, et accessible en écriture uniquement par l’utilisateur root (qui en est le propriétaire). Ceci est déterminé par –rw–r––r––. Si un ID utilisateur a un mot de passe, la zone de mot de passe contiendra un ! (point d’exclamation). Dans le cas contraire, la zone de mot de passe contiendra un * (astérisque). Les mots de passe chiffrés sont conservés dans le fichier /etc/security/passwd. L’exemple qui suit montre les quatre dernières entrées du fichier /etc/security/passwd, correspondant aux entrées du fichier /etc/passwd mentionné précédemment. guest: password = * nobody: password = * lpd: password = * paul: password = eacVScDKri4s6 lastupdate = 1026394230 flags = ADMCHG Notez qu’aucune entrée ne figure dans le fichier /etc/security/passwd pour l’ID utilisateur jdoe, car il n’a aucun mot de passe défini dans le fichier /etc/passwd. 2-24 Guide de sécurité Vous pouvez contrôler la cohérence du fichier /etc/passwd à l’aide de la commande pwdck. Elle vérifie la justesse des informations relatives aux mots de passe dans les fichiers de la base de données utilisateurs, en contrôlant les définitions de tous les utilisateurs ou des utilisateurs indiqués. Le fichier /etc/passwd File et les environnements réseau Dans un environnement réseau, chaque utilisateur doit posséder un compte sur chacun des systèmes pour y avoir accès. En principe, l’utilisateur a donc une entrée dans le fichier /etc/passwd de chaque système. Toutefois, en environnement distribué, il n’est pas facile de vérifier que chaque système a le même fichier /etc/passwd. Pour résoudre ce problème, plusieurs méthodes ont été développées afin de rendre les informations du fichier /etc/passwd disponibles sur le réseau : • Système d’informations réseau (NIS) • NIS+ Ces deux méthodes sont traitées dans le chapitre NIS. Dissimulation des noms d’utilisateur et mots de passe Pour atteindre un niveau de sécurité supérieur, assurez–vous que les ID utilisateur et mots de passe ne sont pas visibles sur le système. Les fichiers .netrc contiennent les ID utilisateurs et mots de passe. Ces fichiers ne sont pas protégés par chiffrement ou codage : leur contenu est affiché en clair. Pour trouver ces fichiers, lancez la commande suivante : # find ‘awk –F: ’{print $6}’ /etc/passwd‘ –name .netrc –ls Après avoir localisé les fichiers, supprimez–les. Un moyen plus efficace d’enregistrer des mots de passe consiste à installer Kerberos. Paramétrage des options de mot de passe recommandées Seule la formation des utilisateurs peut permettre une gestion efficace des mots de passe. Pour une meilleure sécurité, le système d’exploitation propose des fonctions configurables de restriction des mots de passe. Elles permettent à l’administrateur de contrôler les mots de passe choisis par les utilisateurs, et d’imposer leur modification régulière. Les options de mot de passe et les attributs étendus d’utilisateur résident dans le fichier /etc/security/user. Ce fichier ASCII contient des strophes d’attributs pour les utilisateurs. Ces restrictions sont appliquées à chaque définition d’un nouveau mot de passe utilisateur. Toutes les restrictions de mot de passe sont définies au cas par cas. En conservant les restrictions dans la strophe par défaut du fichier /etc/security/user, les mêmes restrictions sont appliquées à tous les utilisateurs. Pour maintenir une sécurité efficace, tous les mots de passe doivent être protégés de la même façon. Le système d’exploitation procure également aux administrateurs une méthode permettant d’étendre les restrictions de mot de passe. L’attribut pwdchecks du fichier /etc/security/user, permet d’ajouter de nouvelles sous–routines (ou méthodes) au code de restriction de mot de passe. Des politiques de site peuvent donc être ajoutées et appliquées par le système d’exploitation. Reportez–vous à Extension des restrictions de mot de passe, page 2-29 Application rationnelle des restrictions de mot de passe. La mise en place de mesures trop restrictives peut au contraire diminuer la sécurité des mots de passe : un nombre de caractères trop limité permet de les deviner plus facilement, et imposer des mots de passe compliqués difficiles à mémoriser incitera les utilisateurs à les noter. Enfin, la sécurité des mots de passe dépend des utilisateurs. La meilleure politique consiste à imposer des restrictions simples, à donner des directives claires et à contrôler régulièrement l’absence de doublons. Le tableau suivant indique les valeurs recommandées pour certains attributs de sécurité liés aux mots de passe utilisateur, dans le fichier /etc/security/user. Utilisateurs, rôles et mots de passe 2-25 Tableau 8. Valeurs des attributs de sécurité recommandées pour les mots de passe utilisateur. 2-26 Attribut Description Valeur recommandée dictionlist Vérifie que les mots de passe n’incluent pas de termes UNIX. /usr/share/dict/ words histexpire Nombre de semaines avant de pouvoir réutiliser le mot de passe. 26 0 histsize Nombre de répétitions permises du mot de passe. 20 0 50 maxage Nombre maximum de semaines avant de devoir modifier le mot de passe. 8 0 52 maxexpired Nombre maximum de semaines après maxage pendant lesquelles un utilisateur peut modifier son mot de passe expiré. (Root en est dispensé.) 2 –1 52 maxrepeats Nombre maximum de caractères pouvant être répétés dans les mots de passe. 2 8 8 Guide de sécurité Valeur par défaut N/A Remarque Valeur maximale 1 N/A 260 Remarque 2 minage Nombre minimum de semaines avant de pouvoir modifier un mot de passe. Cette valeur doit être égale à zéro, à moins que les administrateurs ne puissent être joints à tout moment pour réinitialiser un mot de passe récemment modifié et compromis par accident. 0 0 52 minalpha Nombre minimum de caractères alphabétiques dans un mot de passe. 2 0 8 mindiff Nombre minimum de caractères uniques devant figurer dans un mot de passe. 4 0 8 minlen Longueur minimum du mot de passe. 6 (8 pour l’utilisateur root) 0 8 minother Nombre minimum de caractères non–alphabétiq ues devant figurer dans un mot de passe. 2 0 8 Utilisateurs, rôles et mots de passe 2-27 pwdwarntime Nombre de jours avant que le système n’émette un avertissement indiquant que la modification du mot de passe est nécessaire. pwdchecks Cette entrée ajoute à la commande passwd un code personnalisé chargé du contrôle de la qualité du mot de passe. 5 N/A N/A Pour plus d’informations, reportez–vous à la section Extension des restrictions de mot de passe, page 2-29. N/A N/A Remarques : 1. N/A signifie Non applicable. 2. Un maximum de 50 mots de passe sont mémorisés. Pour utiliser CAPP et EAL4+ (Controlled Access Protection Profile et Evaluation Assurance Level 4+) sur votre système, appliquez les valeurs recommandées à la section Configuration du port et de l’utilisateur, page 1-11. Si un traitement de texte est installé sur le système, l’administrateur peut utiliser le fichier /usr/share/dict/words comme fichier dictionnaire dictionlist. Dans ce cas, il définira l’attribut minother sur 0. En effet, la plupart des mots du dictionnaire ne satisfont pas la condition définie par l’attribut minother, le fait de définir cet attribut sur 1 ou plus élimine la grande majorité des mots du dictionnaire. La longueur minimale d’un mot de passe du système est définie par le maximum de la somme de l’attribut minother avec l’attribut minlen ou l’attribut minalpha. Le mot de passe ne doit pas dépasser 8 caractères. La valeur de l’attribut minalpha plus celle de l’attribut minother ne doit jamais être supérieure à huit. Si la valeur de minalpha plus celle de minother est supérieure à huit, la valeur de l’attribut minother est réduite à huit moins la valeur de l’attribut minalpha. Si les attributs histexpire et histsize sont définis, le système mémorise le nombre de mots de passe requis pour satisfaire les deux conditions, dans la limite système de 50 mots de passe par utilisateur. Les mots de passe vides ne sont pas mémorisés. Vous pouvez modifier le fichier /etc/security/user pour inclure toute valeur par défaut à utiliser pour administrer les mots de passe utilisateur. Une autre solution consiste à modifier les valeurs d’attribut à l’aide de la commande chuser. Avec ce fichier, vous pouvez également utiliser les commandes mkuser, lsuser, et rmuser. La commande mkuser crée dans le fichier /etc/security/user une entrée pour chaque nouvel utilisateur, et initialise ses attributs avec ceux qui ont été définis dans le fichier /usr/lib/security/mkuser.default. Pour afficher les attributs et leurs valeurs, utilisez la commande lsuser. Pour supprimer un utilisateur, utilisez la commande rmuser. 2-28 Guide de sécurité Extension des restrictions de mot de passe Les administrateurs système peuvent étendre les règles utilisées par le programme de mots de passe pour accepter et rejeter les mots de passe (restrictions de composition de mot de passe) afin de les adapter à chaque site. Les restrictions sont étendues grâce à l’ajout de sous–routines, nommées méthodes, qui sont appelées lors d’une modification de mot de passe. L’attribut pwdchecks du fichier /etc/security/user indique les méthodes appelées. Le document AIX 5L Version 5.2 Technical Reference décrit l’interface de sous–routine pwdrestrict_method, à laquelle les méthodes de restriction de mot de passe spécifiées doivent se conformer. Pour étendre correctement les restrictions de composition de mot de passe, l’administrateur système doit utiliser cette interface lorsqu’il écrit une méthode de restriction. Prenez beaucoup de précautions lorsque vous étendez des restrictions de composition de mot de passe. Ces extensions affectent directement les commandes login, passwd et su, ainsi que les autres programmes. Un code malveillant ou défectueux peut facilement nuire à la sécurité d’un système. Utilisez uniquement un code fiable. Utilisateurs, rôles et mots de passe 2-29 Authentification de l’utilisateur Identification et authentification déterminent l’identité d’un utilisateur. Chaque utilisateur doit se connecter au système. Il indique le nom d’utilisateur d’un compte et éventuellement un mot de passe (sur un système sécurisé, tous les comptes non affectés d’un mot de passe doivent être invalidés). Si le mot de passe est correct, l’utilisateur accède au compte correspondant et dispose des droits et des privilèges associés. Les fichiers /etc/passwd et /etc/security/passwd gèrent les mots de passe utilisateur. D’autres méthodes d’authentification sont intégrées au système au moyen de l’attribut SYSTEM qui figure dans /etc/security/user. Par exemple, l’environnement DCE (Distributed Computing Environment) exige une authentification par mot de passe mais valide les mots de passe d’une façon différente du modèle utilisé dans / etc/passwd et /etc/security/passwd. Les utilisateurs qui s’authentifient via DCE doivent avoir leur strophe du fichier /etc/security/user définie sur SYSTEM=DCE. Les autres valeurs de l’attribut SYSTEM sont compat, files et NONE. compat est utilisé lorsque la résolution de nom (et l’authentification qui en résulte) suit la base de données locale. Si aucune résolution n’est trouvée, une tentative est effectuée sur la base de données NIS (Network Information Service). files indique que seuls les fichiers locaux doivent être utilisés lors de l’authentification. Enfin, NONE désactive l’authentification par méthode. Pour désactiver toutes les authentifications, NONE doit apparaître dans les lignes SYSTEM et auth1 de la strophe de l’utilisateur. Vous pouvez définir d’autres valeurs valides de l’attribut SYSTEM dans /usr/lib/security/methods.cfg. Remarque : L’utilisateur root est toujours authentifié au moyen des fichiers de sécurité local system. L’attribut SYSTEM de l’utilisateur root est défini sur SYSTEM = ”compat” dans /etc/security/user. Reportez–vous au document AIX 5L Version 5.2 System User’s Guide: Operating System and Devices, pour plus d’informations sur la protection des mots de passe. ID de connexion Tous les événements d’audit enregistrés pour cet utilisateur portent cet ID. Vous pouvez les examiner lorsque vous générez des enregistrements d’audit. Reportez–vous au document AIX 5L Version 5.2 System User’s Guide: Operating System and Devices pour plus d’informations sur les ID de connexion. Présentation du système de quotas de disque Le système de quotas de disque permet aux administrateurs de contrôler le nombre de fichiers et de blocs de données pouvant être alloués à des utilisateurs ou groupes. Les sections qui suivent apportent des informations complémentaires sur le système de quotas de disque, son implémentation et son utilisation : 2-30 • Présentation du système de quotas de disque, page 2-31 • Reprise après un dépassement de quota, page 2-31 • Configuration du système de quotas de disque, page 2-32 Guide de sécurité Présentation du système de quotas de disque Le système de quotas de disque, basé sur le système Berkeley, constitue un moyen efficace de contrôler l’utilisation de l’espace disque. Le système de quotas peut être défini pour des utilisateurs individuels ou des groupes, et géré pour chaque système de fichiers journalisé. Le système de quotas de disque détermine des seuils basés sur les paramètres qui suivent, et modifiables à l’aide de la commande edquota : • Seuils d’avertissement d’un utilisateur ou d’un groupe • Seuils obligatoires d’un utilisateur ou d’un groupe • Période de tolérance du quota Le seuil d’avertissement définit le nombre de blocs de disques de 1 Ko ou de fichiers que l’utilisateur ne doit pas dépasser. Le seuil obligatoire définit le nombre maximum de blocs de disques ou de fichiers que l’utilisateur peut cumuler dans la limite des quotas disque établis. La période de tolérance de quota permet à l’utilisateur de dépasser le seuil d’avertissement pendant une courte période (la valeur par défaut est d’une semaine). Si l’utilisateur ne parvient pas à réduire son utilisation sous le seuil d’avertissement pendant la période indiquée, le système interprétera le seuil d’avertissement comme l’allocation maximum permise, et aucun espace disque supplémentaire ne sera alloué à l’utilisateur. L’utilisateur peut supprimer cette condition en supprimant un nombre suffisant de fichiers pour passer sous le seuil d’avertissement. Le système de quotas de disque enregistre le suivi des quotas utilisateur et de groupe dans les fichiers quota.user et quota.group, dans les répertoires root des systèmes de fichiers soumis aux quotas. Ces fichiers sont créés avec les commandes quotacheck et edquota et peuvent être lus avec les commandes de quota. Reprise après un dépassement de quota Vous pouvez appliquer les méthodes qui suivent pour réduire l’utilisation des systèmes de fichiers lorsque vous avez dépassé les seuils de quota : • Arrêtez le processus en cours à l’origine du dépassement de seuil, supprimez les fichiers inutiles pour passer sous le seuil autorisé et relancez le programme qui a échoué. • Si vous exécutez un éditeur tel que vi, utilisez la séquence d’échappement du shell pour contrôler l’espace réservé aux fichiers, supprimez les fichiers inutiles et reprenez la tâche sans perdre le fichier modifié. Si vous utilisez les shells C ou Korn, une autre méthode consiste à arrêter temporairement l’éditeur à l’aide de la séquence de touches Ctrl–Z, à exécuter les commandes sur le système de fichiers, et à revenir en exécutant la commande d’avant–plan fg. • Enregistrez temporairement le fichier dans un système de fichiers n’ayant pas dépassé le quota autorisé, supprimez les fichiers inutiles et replacez le fichier dans le système d’origine. Utilisateurs, rôles et mots de passe 2-31 Configuration du système de quotas de disque En principe, seuls les systèmes de fichiers qui contiennent des fichiers et répertoires personnels sont soumis aux quotas de disque. Vous devez envisager d’utiliser un système de quotas de disque dans les conditions suivantes : • L’espace disque de votre système est limité. • Vous souhaitez que vos systèmes de fichiers bénéficient d’un niveau de sécurité supérieur. • Vous utilisez le disque de façon intensive, à l’exemple des universités. Si ces conditions ne s’appliquent pas à votre environnement, vous ne souhaiterez peut–être pas limiter l’utilisation du disque via un système de quotas. Les quotas ne sont applicables qu’aux systèmes de fichiers journalisés. Remarque : N’établissez pas de quotas de disque pour le système de fichiers /tmp. Pour paramétrer le système de quotas de disque, appliquez la procédure suivante : 1. Connectez–vous en tant qu’utilisateur root. 2. Choisissez les systèmes de fichiers auxquels appliquer les quotas. Remarque : N’appliquez pas de quota au système de fichiers /tmp, nombre d’éditeurs et d’utilitaires système créant des fichiers temporaires dans /tmp. 3. Avec la commande chfs, ajoutez les attributs de configuration userquota et groupquota au fichier /etc/filesystems. L’exemple suivant utilise la commande chfs pour activer les quotas utilisateur sur le système de fichiers /home: chfs –a ”quota = userquota” /home Pour activer les quotas utilisateur et groupe dans le système de fichiers /home, entrez : chfs –a ”quota = userquota,groupquota” /home Dans le fichier /etc/filesystems, l’entrée correspondante ressemble à : /home: dev vfs log mount check quota options = = = = = = = /dev/hd1 jfs /dev/hd8 true true userquota,groupquota rw 4. La désignation d’autres noms de fichier de quotas disque est facultative. Les noms de fichiers quota.user et quota.group sont les noms par défaut situés dans les répertoires root des systèmes de fichiers soumis aux quotas. En outre, vous pouvez spécifier d’autres noms ou répertoires pour ces fichiers de quotas avec les attributs userquota et groupquota du fichier /etc/filesystems. L’exemple suivant illustre l’application de quotas utilisateur et groupe au système de fichiers /home avec la commande chfs, et nomme les fichiers de quotas myquota.user et myquota.group : chfs –a ”userquota = /home/myquota.user” –a ”groupquota = /home /myquota.group” /home 2-32 Guide de sécurité Dans le fichier /etc/filesystems, l’entrée correspondante ressemble à : /home: dev vfs log mount check quota userquota groupquota options = = = = = = = = = /dev/hd1 jfs /dev/hd8 true true userquota,groupquota /home/myquota.user /home/myquota.group rw 5. Si ce n’est pas déjà fait, montez les systèmes de fichiers spécifiés. 6. Définissez les limites de quota souhaitées pour chaque utilisateur ou groupe. Utilisez la commande edquota pour créer le seuil d’avertissement et le seuil obligatoire de chaque utilisateur ou groupe, ainsi que l’espace disque autorisé et le nombre maximum de fichiers. L’exemple suivant illustre les limites de quota pour l’utilisateur davec : Quotas for user davec: /home: blocks in use: 30, limits (soft = 100, hard = 150) inodes in use: 73, limits (soft = 200, hard = 250) davec a utilisé 30 Ko sur les 100 Ko autorisés. Sur les 200 fichiers autorisés, davec en a créé 73. Il dispose de 50 Ko de tampons et de 50 fichiers pour le stockage temporaire. Quand vous définissez des quotas disque pour plusieurs utilisateurs, utilisez l’indicateur –p avec la commande edquota pour dupliquer les quotas pour un autre utilisateur. Pour dupliquer les quotas de l’utilisateur davec pour l’utilisateur nanc, entrez : edquota –p davec nanc 7. Activez le système de quotas avec la commande quotaon. Accompagnée de l’indicateur –a, la commande quotaon active les quotas pour le système de fichiers précisé, ou pour tous les systèmes de fichiers soumis aux quotas (comme indiqué dans le fichier /etc/filesystems). 8. Utilisez la commande quotacheck pour vérifier la cohérence entre les fichiers de quotas et l’utilisation en cours du disque. Remarque : Cette procédure est recommandée à chaque activation initiale de quotas sur un système de fichiers et après redémarrage du système. Pour activer la vérification et les quotas au démarrage du système, ajoutez les lignes suivantes à la fin du fichier /etc/rc : echo ” Enabling filesystem quotas ” /usr/sbin/quotacheck –a /usr/sbin/quotaon –a Utilisateurs, rôles et mots de passe 2-33 2-34 Guide de sécurité Chapitre 3. Audit Le sous–système d’audit permet à l’administrateur système d’enregistrer des informations de sécurité, qui peuvent être analysées pour détecter des violations potentielles ou effectives de la politique de sécurité. Cette section traite des points suivants : • Sous–système d’audit, page 3-1 • Sélection des événements, page 3-3 • Configuration du sous–système d’audit, page 3-4 • Configuration de la journalisation d’audit, page 3-5 • Configuration de l’audit, page 3-9 Sous–système d’audit Les fonctions du sous–système d’audit sont les suivantes : • Détection des événements, page 3-1 • Collecte d’informations sur les événements, page 3-2 • Traitement des informations de suivi d’audit, page 3-2 L’administrateur système peut utiliser l’une de ces fonctions pour la configuration. Détection des événements La détection des événements est répartie au sein de la base TCB (Trusted Computing Base), dans le noyau (code d’état de superviseur) et dans les programmes sécurisés (code d’état d’utilisateur). Un événement auditable correspond à toute occurrence relative à la sécurité dans le système. Une occurrence relative à la sécurité correspond à toute modification de l’état de sécurité du système, toute tentative de violation ou violation réelle du contrôle d’accès du système ou des politiques de sécurité de gestion de compte, ou des deux. Les programmes et les modules de noyau qui détectent des événements auditables sont responsables de leur enregistrement dans le journal d’audit du système, qui s’exécute dans le noyau et est accessible via une sous–routine (pour l’audit des programmes sécurisés) ou un appel de procédure de noyau (pour l’audit d’état du superviseur). Les informations recueillies comprennent le nom de l’événement auditable, le succès ou l’échec de l’événement, et toute autre information spécifique à l’événement et relative à l’audit de sécurité. La configuration de la détection des événements consiste à activer et désactiver la détection, et à indiquer les événements à auditer et les utilisateurs concernés. Pour activer la détection, utilisez la commande audit, qui active ou désactive le sous–système d’audit. Le fichier /etc/security/audit/config contient les événements et utilisateurs traités par le sous–système. Audit 3-1 Collecte d’informations sur les événements Le recueil d’informations comprend la journalisation des événements auditables sélectionnés. Cette fonction est exécutée par le journal d’audit du noyau, qui fournit un appel système et une interface d’appel de procédure interne au noyau qui enregistre les événements auditables. Le journal d’audit est responsable de l’élaboration de l’enregistrement d’audit complet, composé de l’en–tête, qui contient des informations communes à tous les événements (nom de l’événement, utilisateur responsable, heure et état de retour), et du suivi, qui contient les informations spécifiques à l’événement. Le journal d’audit ajoute chaque enregistrement au suivi d’audit du noyau, qui peut être écrit dans les modes suivants : Mode BIN Le suivi est écrit sous forme de fichiers alternés, dans un but de sécurité et de stockage à long terme. Mode STREAM Le suivi est écrit dans un tampon circulaire lu de façon synchrone par une pseudo–unité d’audit. Le mode STREAM assure une réponse immédiate. La collecte des informations peut être configurée du côté de l’enregistrement des événements comme pour le traitement du suivi. L’enregistrement des événements peut être sélectionné par utilisateur. A chaque utilisateur correspond un ensemble d’événements d’audit, consignés dans le suivi lorsqu’ils se produisent. Côté traitement, les modes sont configurables individuellement, afin que l’administrateur puisse choisir le traitement le mieux adapté à l’environnement. De plus, l’audit en mode BIN peut être configuré pour générer une alerte au cas où l’espace du système de fichiers disponible pour le suivi devienne insuffisant. Traitement des informations sur le suivi d’audit Le système d’exploitation fournit plusieurs options de traitement du suivi d’audit du noyau. Le suivi en mode BIN peut être compressé, filtré, et/ou formaté avant d’être archivé, le cas échéant. La compression se fait par codage Huffman. Le filtrage se fait par une sélection des enregistrements d’audit de type SQL, à l’aide de la commande auditselect, ce qui permet un affichage et une rétention sélectifs du suivi d’audit. Le formatage des enregistrements du suivi d’audit permet d’examiner le suivi, de générer des rapports de sécurité réguliers, et d’imprimer un document de suivi d’audit. Le suivi d’audit en mode STREAM peut être contrôlé en temps réel, pour détecter immédiatement les menaces. La configuration de ces options se fait à l’aide de programmes distincts pouvant être appelés en tant que processus démons pour filtrer les suivis en mode BIN ou STREAM, bien que certains des programmes de filtrage soient mieux adaptés à un mode donné. 3-2 Guide de sécurité Sélection des événements L’ensemble des événements auditables du système définit les occurrences pouvant faire l’objet d’un audit, ainsi que la finesse de l’audit fourni. Les événements auditables doivent regrouper les événements de sécurité du système, tels que définis précédemment. Le niveau de détail utilisé dans la définition des événements auditables doit assurer l’équilibre entre un manque de détail, qui complique pour l’administrateur la compréhension des informations sélectionnées, et un excès de détails, qui entraîne le recueil de nombreuses informations inutiles. La définition des événements exploite les similitudes entre événements détectés. Un événement détecté correspond à une instance d’événement auditable. Par exemple, un événement donné peut être détecté à plusieurs emplacements. Le principe est que les événements détectés ayant les mêmes propriétés de sécurité sont sélectionnés comme un même événement auditable. La liste suivante répertorie les événements de politique de sécurité : • Evénements sujet – Création de processus – Suppression de processus – Définition des attributs de sécurité des sujets : ID utilisateur, ID de groupe – Groupe de processus, terminal de contrôle • Evénements objet – Création d’objets – Suppression d’objets – Ouverture d’objet (y compris les processus comme objets) – Fermeture d’objet (y compris les processus comme objets) – Définition des attributs de sécurité des objets : propriétaire, groupe, ACL • Evénements import/export – Import ou export d’un objet • Evénements de gestion de comptes – Ajout d’un utilisateur, modification des attributs des utilisateurs dans la base de mots de passe – Ajout d’un groupe, modification des attributs de groupes dans la base de groupes – Connexion utilisateur – Déconnexion utilisateur – Modification des informations d’authentification de l’utilisateur – Configuration du terminal de chemins d’accès sécurisés – Configuration de l’authentification – Gestion des audits : sélection des événements de suivi d’audit, activation, désactivation, définition des classes d’audit des utilisateurs • Evénements généraux de gestion système – Utilisation de privilèges – Configuration du système de fichiers – Définition et configuration des unités Audit 3-3 – Définition des paramètres de configuration du système – IPL (chargement initial) et fermeture corrects du système – Configuration RAS – Autres configurations du système • Violations (potentielles) de sécurité – Refus de droits d’accès – Echecs de privilèges – Pannes et erreurs système détectées par diagnostic – Tentatives de modification de la TCB Configuration du sous–système d’audit Le sous–système d’audit possède une variable d’état global qui indique s’il est activé. De plus, chaque processus possède une variable d’état local qui indique si le sous–système d’audit doit enregistrer des informations sur ce processus. Ces deux variables déterminent si des événements sont détectés par les modules et programmes de la base TCB (Trusted Computing Base). La désactivation de l’audit de la base TCB pour un processus donné permet à ce processus de réaliser son propre audit en respectant la politique de gestion de comptes du système. La fait de permettre à un programme sécurisé de s’auto–auditer assure un recueil d’informations plus efficace. Collecte d’informations sur le sous–système d’audit Le recueil d’informations concerne les modes sélection des événements et suivi d’audit du noyau. Il est effectué par une routine du noyau qui fournit les interfaces nécessaires à la journalisation des informations, utilisées par les composants de la base TCB qui détectent les événements auditables, et les interfaces de configuration, utilisées par le sous–système d’audit pour contrôler la routine de journalisation des audits. Journalisation des audits Les événements auditables sont journalisés par les interfaces suivantes : l’état utilisateur et l’état superviseur. La partie état utilisateur de la TCB utilise les sous–routines auditlog ou auditwrite, tandis que la partie état superviseur de la TCB utilise un ensemble d’appels de procédures du noyau. Pour chaque enregistrement, le journal des événements d’audit place un en–tête d’audit devant les informations spécifiques à l’événement. Cet en–tête indique l’utilisateur et le processus pour lesquels l’événement est audité, ainsi que l’heure de l’événement. Le code qui détecte l’événement indique le type d’événement et le code de retour ou l’état, et peut fournir des informations spécifiques à l’événement (le suivi). Les informations spécifiques à l’événement comprennent les noms d’objets (par exemple, les fichiers dont l’accès est refusé ou les tty utilisés lors des échecs de connexion), les paramètres de sous–routines, et les autres informations modifiées. Les événements sont définis par symboles plutôt que par numéros. Ceci réduit les risques de noms identiques, sans utiliser de méthode d’enregistrement des événements. Comme les sous–routines sont auditables et que la définition du noyau extensible n’a pas de numéro SVC (switched virtual circuit) fixe, il est difficile d’enregistrer des événements par numéro. Il faudrait pour cela corriger ces numéros à chaque extension ou redéfinition de l’interface du noyau. 3-4 Guide de sécurité Format des enregistrements d’audits Les enregistrements d’audit comprennent un en–tête commun, qui précède les suivis d’audit spécifiques à l’événement de l’enregistrement. Les structures des en–têtes sont définies dans le fichier /usr/include/sys/audit.h. Le format des informations dans le suivi d’audit est spécifique à chaque événement, et indiqué dans le fichier /etc/security/audit/events. Les informations de l’en–tête sont généralement recueillies par la routine de journalisation, pour garantir qu’elles correspondent aux informations des suivis d’audit fournies par le code qui détecte l’événement. Le journal d’audit ne connaît absolument pas la structure ni la sémantique des suivis d’audit. Par exemple, lorsque la commande login détecte un échec de connexion, elle enregistre cet événement avec le terminal sur lequel il s’est produit, et l’écrit dans le suivi d’audit à l’aide de la sous–routine auditlog. Le composant noyau du journal d’audit enregistre des informations spécifiques (ID utilisateur, ID de processus, heure) dans un en–tête qu’il ajoute aux autres informations. L’appelant renseigne uniquement les champs nom de l’événement et résultat de l’en–tête. Configuration de la journalisation d’audit Le journal d’audit est responsable de l’élaboration de l’enregistrement complet de l’audit. Vous devez sélectionner les événements d’audit à journaliser. Sélection des événements audités La sélection des événements audités comprend les types suivants : Audit par processus Pour définir efficacement les événements de processus, le système d’exploitation permet à l’administrateur système de définir des classes d’audit. Une classe d’audit est un sous–ensemble des événements d’audit du système. Ces classes regroupements de manière logique et pratique des événements d’audit de base. Pour chaque utilisateur du système, l’administrateur définit un ensemble de classes d’audit qui déterminent les événements de base à enregistrer. Chaque processus exécuté par un utilisateur est référencé par ses classes d’audit. Audit par objet Le système d’exploitation assure l’audit des accès aux objets par nom, c’est à dire l’audit d’objets spécifiques (normalement des fichiers). L’audit d’objets par nom évite de devoir auditer tous les accès aux objets pour couvrir ceux qui sont pertinents. De plus, le mode d’audit peut être spécifié, afin que seuls les accès du mode indiqué (read/write/execute) soient enregistrés. Modes de suivi d’audit du noyau La journalisation du noyau peut utiliser les modes BIN ou STREAM pour définir l’emplacement d’écriture du suivi d’audit. En mode BIN, le journal d’audit du noyau doit disposer (avant le début de l’audit) d’au moins un descripteur de ficher où les enregistrements seront placés. Le mode BIN écrit les enregistrements dans des fichiers alternés. Au début de l’audit, le noyau reçoit deux descripteurs de fichiers et une taille bin maximale recommandée. Il suspend le processus d’appel et lance l’écriture des enregistrements dans le premier descripteur de fichier. Lorsque la taille du premier fichier atteint son maximum, et si le Audit 3-5 deuxième descripteur de fichier est valide, il passe sur le deuxième fichier et réactive le processus d’appel. Le noyau poursuit l’écriture dans le deuxième fichier jusqu’à ce qu’il reçoive un nouvel appel avec un descripteur de fichier valide. Si à ce moment le deuxième fichier est plein, il retourne sur le premier, et le processus d’appel repart immédiatement. Sinon, le processus d’appel est suspendu, et le noyau poursuit l’écriture d’enregistrements dans le deuxième fichier jusqu’à ce qu’il soit plein. Le traitement se poursuit de la même manière jusqu’à la désactivation de l’audit. Reportez–vous à la figure suivante illustrant le mode BIN : Figure 1. Fonctionnement du mode d’audit BIN. Cette illustration présente le fonctionnement du mode d’audit BIN. Le mécanisme de casiers (ou fichiers) alternés permet de garantir que le sous–système d’audit dispose toujours d’un emplacement d’écriture lors du traitement des enregistrements d’audit. Lorsque le sous–système d’audit change de casier, il vide le précédent dans le fichier trace. Lorsqu’il faut de nouveau changer de casier, le premier est disponible. Ce mode dissocie le stockage et l’analyse des données de leur génération. Généralement, le programme auditcat sert à lire les données du casier dans lequel le noyau n’est pas en train d’écrire. Pour s’assurer que le système dispose toujours d’espace disponible pour le suivi d’audit (le résultat du programme auditcat), le paramètre freespace peut être indiqué dans le fichier /etc/security/audit/config. Si le système dispose de moins d’espace que le nombre de blocs de 512 octets spécifiés, il génère un message syslog. Si l’audit est activé, la paramètre binmode de la strophe start dans /etc/security/audit/config doit avoir pour valeur panic. Le paramètre freespace de la strophe bin doit avoir une valeur au minimum égale à 25 % de l’espace disque dédié au stockage des suivis d’audit. Les paramètres bytethreshold et binsize doivent tous deux être définis sur 65536 octets. 3-6 Guide de sécurité En mode STREAM, le noyau écrit les enregistrements dans un tampon circulaire. Une fois que le noyau atteint la fin du tampon, il continue simplement au début. Les processus lisent les informations via une pseudo–unité nommée /dev/audit. Lorsqu’un processus ouvre cette unité, un nouveau canal est créé pour ce processus. Eventuellement, les événements à lire sur le canal peuvent être indiqués comme liste des classes d’audit. Reportez–vous à la figure suivante illustrant le mode STREAM : Figure 2. Fonctionnement du mode d’audit STREAM. Cette illustration présente le fonctionnement du mode d’audit STREAM. Le but principal du mode STREAM est de permettre la lecture permanente du suivi d’audit, très utile pour contrôler les menaces en temps réel. Il sert également à créer un suivi écrit immédiatement, évitant toute altération qui pourrait se produire en cas de stockage sur un support inscriptible. Une autre méthode d’utilisation du mode STREAM est d’écrire les données d’audit dans un programme qui stocke les informations d’audit sur un système distant, permettant un traitement central en temps quasi–réel, tout en protégeant les informations d’audit contre une altération sur l’hôte qui les a émises. Audit 3-7 Traitement des enregistrements d’audit Les commandes auditselect, auditpr et auditmerge permettent de traiter les enregistrements d’audit en mode BIN ou STREAM. Elles fonctionnent comme des filtres, et peuvent donc être utilisés avec des pipes, ce qui est particulièrement pratique pour les audits en mode STREAM. auditselect Permet de sélectionner des enregistrements d’audits spécifiques avec des instructions de type SQL. Par exemple, pour ne sélectionner que des événements exec() générés par l’utilisateur afx, saisissez la commande suivante : auditselect –e ”login==afx && event==PROC_Execute” auditpr Permet de convertir les enregistrements d’audit binaires en un format plus lisible La quantité d’informations affichée dépend des indicateurs spécifiés sur la ligne de commandes. Pour obtenir toutes les informations disponibles, utilisez auditpr de la façon suivante : auditpr –v –hhelrtRpPTc Lorsque l’indicateur –v est indiqué, le suivi d’audit, qui est une chaîne spécifique à l’événement (voir le fichier /etc/security/audit/events), s’affiche en sus des informations d’audit standard fournies par le noyau pour chaque événement. auditmerge Utilisé pour fusionner des suivis d’audit binaires. Cela est particulièrement utile pour combiner des suivis d’audit de plusieurs systèmes. La commande auditmerge prend les noms des suivis de la ligne de commandes, et envoie le suivi binaire fusionné à STDOUT. Il faut donc encore utiliser auditpr pour le rendre lisible. Par exemple, auditmerge et auditptr peuvent être utilisés de la façon suivante : auditmerge trail.system1 trail.system2 | auditpr –v –hhelrRtpc Utilisation du sous–système d’audit pour un rapide contrôle de sécurité La commande watch permet de contrôler un programme suspect sans configurer le sous–système d’audit. Elle enregistre l’événement requis ou tous les événements générés par ce programme. Par exemple, utilisez la commande suivante pour voir tous les événements FILE_Open lors de l’exécution de vi /etc/hosts : watch –eFILE_Open –o /tmp/vi.watch vi /etc/hosts Le fichier /tmp/vi.watch contiendra tous les événements FILE_Open pour la session d’édition. 3-8 Guide de sécurité Configuration de l’audit La procédure suivante présente les étapes de configuration d’un sous–système d’audit. Pour plus d’informations, consultez les fichiers de configuration mentionnés pour ces étapes. 1. Sélectionnez des activités système (événements) à auditer parmi la liste du fichier /etc/security/audit/events. Si vous avez ajouté des événements d’audit aux applications ou extensions du noyau, vous devez ajouter les nouveaux événements au fichier. – Vous pouvez ajouter un événement dans ce fichier si votre programme comporte le code d’enregistrement associé (au moyen des sous–routines auditwrite ou auditlog), ou si ce code est dans une extension de noyau (par le biais des services noyau audit_svcstart, audit_svcbcopy et audit_svcfinis). – Assurez–vous que les instructions de formatage des nouveaux événements d’audit figurent dans le fichier /etc/security/audit/events. Ces indications permettent à la commande auditpr d’écrire un suivi d’audit au moment du formatage des enregistrements d’audit. 2. Regroupez les événements d’audit sélectionnés en ensembles d’éléments similaires appelés classes d’audit. Définissez ces classes d’audit dans la strophe des classes du fichier /etc/security/audit/config. 3. Affectez les classes d’audit aux utilisateurs et les événements d’audit aux fichiers (objets) à auditer, comme suit : – Pour attribuer des classes d’audit à un utilisateur donné, ajoutez une ligne dans la strophe des utilisateurs dans /etc/security/audit/config. Pour affecter des classes d’audit à un utilisateur, vous pouvez utiliser la commande chuser. – Pour affecter des événements d’audit à un objet (données ou fichier exécutable), ajoutez une strophe à ce fichier dans /etc/security/audit/objects. – Vous pouvez aussi définir des classes d’audit par défaut pour de nouveaux utilisateurs en modifiant /usr/lib/security/mkuser.default. Ce fichier contient les attributs utilisateur servant à générer les nouveaux ID utilisateur. Par exemple, utilisez la classe d’audit general pour tous les nouveaux ID utilisateur, comme suit : user: auditclasses = general pgrp = staff groups = staff shell = /usr/bin/ksh home = /home/$USER Pour obtenir tous les événements d’audit, spécifiez la classe ALL. Cela générera une immense quantité de données même sur un système dont l’activité est modérée. Il est généralement plus pratique de limiter le nombre d’événements enregistrés. Audit 3-9 4. Dans le fichier /etc/security/audit/config, configurez le type de collecte de données souhaité : BIN et/ou STREAM. Assurez–vous que les données d’audit n’entrent pas en concurrence avec d’autres données en termes d’espace de fichiers, en utilisant pour elles un système de fichiers séparé. Vous serez ainsi assuré de disposer de suffisamment d’espace pour les données d’audit. Configurez comme suit le type de collecte de données : – Pour configurer la méthode BIN : a. Définissez binmode = on dans la strophe start. b. Modifiez la strophe binmode pour configurer les casiers et le suivi, et indiquez le chemin d’accès au fichier qui contient les commandes de traitement binmode. Le fichier par défaut des commandes de traitement est /etc/security/audit/bincmds. c. Vérifiez que les casiers d’audit sont suffisamment grands et définissez freespace en conséquence pour obtenir une alerte si le système de fichiers se remplit. d. Ajoutez les commandes shell de traitement des casiers d’audit dans un tube d’audit du fichier /etc/security/audit/bincmds. – Pour utiliser la méthode STREAM a. Définissez streammode = on dans la strophe start. b. Modifiez la strophe streammode pour indiquer le chemin d’accès au fichier qui contient les commandes de traitement streammode. Le fichier par défaut qui contient ces informations est /etc/security/audit/streamcmds. c. Ajoutez les commandes shell de traitement des enregistrements continus dans un tube d’audit du fichier /etc/security/audit/streamcmds. 5. Une fois les modifications nécessaires apportées aux fichiers de configuration, activez le sous–système d’audit au moyen de la commande audit start. 6. Utilisez la commande audit query pour afficher les événements et objets audités. 7. Utilisez la commande audit shutdown pour désactiver à nouveau le sous–système d’audit. 3-10 Guide de sécurité Sélection des événements audités L’objectif d’un audit est de détecter des activités risquant de compromettre la sécurité du système. Les opérations suivantes, effectuées par un utilisateur non autorisé, constituent une violation de la sécurité du système et sont auditables : • Valider des opérations dans la base TCB • Authentifier des utilisateurs • Accéder au système • Modifier la configuration du système • Circonvenir le système d’audit • Initialiser le système • Installer des programmes • Modifier des comptes • Transférer des informations Le système d’audit ne dispose pas d’ensemble par défaut des événements à auditer. Vous devez sélectionner des événements ou classes d’événements en fonction de vos besoins. Pour auditer une activité, il est indispensable d’identifier la commande ou le processus à l’origine de l’événement et de s’assurer que cet événement est répertorié dans /etc/security/audit/events. Vous devez ensuite inclure l’événement dans la classe appropriée du fichier /etc/security/audit/config ou dans la strophe d’objets de /etc/security/audit/objects. Reportez–vous au fichier /etc/security/audit/events de votre système pour la liste des événements d’audit et les instructions de formatage du suivi. Reportez–vous à la commande auditpr pour une description des formats d’événements d’audit (écriture et exploitation). Une fois les événements à auditer sélectionnés, vous devez regrouper les événements similaires en classes d’audit. Ensuite, les classes d’audit sont affectées aux utilisateurs. Sélection des classes d’audit Vous pouvez simplifier l’affectation des événements d’audit aux utilisateurs en regroupant les événements identiques en classes d’audit. Ces classes sont définies dans la strophe des classes du fichier /etc/security/audit/config. Voici quelques classes courantes : general Evénements d’ordre général modifiant l’état du système et l’authentification des utilisateurs. Audit des tentatives de circonvenir les contrôles d’accès au système. objects Accès en écriture aux fichiers de configuration de la sécurité. kernel Les événements de la classe noyau sont générés par les fonctions de gestion des processus du noyau. Voici un exemple de strophe du fichier /etc/security/audit/config : classes: general = USER_SU,PASSWORD_Change,FILE_Unlink,FILE_Link,FILE_Rename system = USER_Change,GROUP_Change,USER_Create,GROUP_Create init = USER_Login,USER_Logout Audit 3-11 Sélection du mode de collecte des données d’audit La méthode à retenir dépend de la façon dont vous exploiterez les données d’audit. Si vous souhaitez stocker sur le long terme un volume important des données collectées, le mode BIN est préconisé. Si vous traitez les données au fur et à mesure de leur collecte, utilisez le mode STREAM. Vous pouvez aussi sélectionner les deux méthodes. Collecte Bin Stockage à long terme d’un important suivi d’audit. Les enregistrements d’audit sont écrits dans un fichier servant de casier temporaire. Quand ce fichier est saturé, le démon auditbin traite les données tandis que le sous–système d’audit écrit vers un autre fichier casier, puis les enregistrements sont stockés dans un fichier de suivi d’audit. Collecte Stream Permet le traitement des données d’audit en même temps qu’elles sont recueillies. Les enregistrements d’audit sont inscrits dans un tampon circulaire du noyau et récupérés en lisant /dev/audit. Ces enregistrements peuvent être affichés, imprimés et/ou convertis pour être compatibles avec le mode bin (avec la commande auditcat). Exemple de contrôle en temps réel des modifications de fichiers L’exemple suivant permet de contrôler en temps réel l’accès à des fichiers critiques : 1. Dressez la liste des fichiers dont les modifications sont à contrôler, par exemple tous les fichiers dans /etc et configurez–les pour les événements FILE_Write dans le fichier objects : find /etc –type f | awk ’{printf(”%s:\n\tw = FILE_Write\n\n”,$1)}’ >> /etc/security/audit/objects 2. Choisissez le mode Stream pour établir la liste de toutes les écritures sur fichiers. Cet exemple répertorie toutes les écritures sur fichiers sur la console. En environnement de production, vous souhaiterez peut–être disposer d’un back–end qui envoie les événements vers un système de détection des intrusions. Le fichier /etc/security/audit/streamcmds est similaire à l’exemple suivant : /usr/sbin/auditstream | /usr/sbin/auditselect –e ”event == FILE_Write” | auditpr –hhelpPRtTc –v > /dev/console & 3. Choisissez le mode STREAM dans /etc/security/audit/config, ajoutez une classe pour les événements d’écriture sur fichiers et configurez tous les utilisateurs à auditer avec cette classe : start: binmode = off streammode = on stream: cmds = /etc/security/audit/streamcmds classes: filemon = FILE_write users: root = filemon afx = filemon ... 4. Exécutez maintenant audit start. Tous les événements FILE_Write apparaissent sur la console. 3-12 Guide de sécurité Exemple de scénario de journal d’audit générique Dans cet exemple, on considère qu’un administrateur système veut utiliser le sous–système d’audit pour contrôler un vaste système multi–utilisateur. Aucune intégration directe vers un IDS n’est effectuée. Tous les enregistrements d’audits seront contrôlés manuellement. Seuls quelques événements d’audit essentiels sont enregistrés, afin que la quantité de données générée reste possible à traiter. Les événements d’audit pris en compte pour la sélection d’événements sont les suivants : FILE_Write Pour analyser toutes les écritures sur les fichiers de configuration. Cet événement sera utilisé avec tous les fichiers de l’arborescence /etc. PROC_SetUserIDs Toutes les modifications d’ID utilisateur AUD_Bin_Def Configuration des casiers d’audit USER_SU Commande su PASSWORD_Change Commande passwd AUD_Lost_Rec Notification en cas de perte d’enregistrements CRON_JobAdd Nouvelle tâche cron AT_JobAdd Nouvelle tâche at USER_Login Toutes les connexions PORT_Locked Tous les verrouillages de terminaux pour cause de nombreux échecs L’exemple suivant montre comment générer un journal d’audit générique : 1. Dressez la liste des fichiers critiques dont les modifications sont à contrôler, par exemple tous les fichiers dans /etc et configurez–les pour les événements FILE_Write dans le fichier objects : find /etc –type f | awk ’{printf(”%s:\n\tw = FILE_Write\n\n”,$1)}’ >> /etc/security/audit/objects 2. Utilisez la commande auditcat pour configurer l’audit en mode BIN. Le fichier /etc/security/audit/bincmds est similaire à l’exemple suivant : /usr/sbin/auditcat –p –o $trail $bin 3. Modifiez le fichier /etc/security/audit/config et ajoutez une classe pour les événements intéressants. Dressez la liste des utilisateurs et affectez–leur la classe custom. Audit 3-13 start: binmode = on streammode = off bin: cmds = /etc/security/audit/bincmds trail = /audit/trail bin1 = /audit/bin1 bin2 = /audit/bin2 binsize = 100000 freespace = 100000 classes: custom = FILE_Write,PROC_SetUser,AUD_Bin_Def,AUD_Lost_Rec,USER_SU, \ PASSWORD_Change,CRON_JobAdd,AT_JobAdd,USER_Login,PORT_Locked users: root = custom afx = custom ... 4. Ajoutez la classe d’audit custom au fichier /usr/lib/security/mkuser.default, afin que les nouveaux ID aient automatiquement le bon appel d’audit : user: auditclasses = custom pgrp = staff groups = staff shell = /usr/bin/ksh home = /home/$USER 5. Créez un nouveau système de fichiers nommé /audit à l’aide de SMIT ou de la commande crfs. Il doit être assez grand pour contenir les deux casiers et un grand suivi d’audit. 6. Exécutez maintenant audit start et observez/audit. Vous devez d’abord voir apparaître deux fichiers casiers et un fichier de suivi trail vide. Après utilisation du système, le fichier de suivi doit contenir des enregistrements d’audit, lisibles à l’aide de la commande auditpr –hhelpPRtTc –v | more Cet exemple n’utilise que peu d’événements. Pour tous les utiliser, spécifiez le nom de classe ALL pour tous les utilisateurs. Vous obtiendrez de grandes quantités de données. Vous souhaiterez peut–être ajouter tous les événements liés aux modifications d’utilisateurs et de droits à votre classe custom. 3-14 Guide de sécurité Chapitre 4. Utilisation du protocole LDAP du sous–système de sécurité Le protocole LDAP (Light Directory Access Protocol) définit une méthode standard pour accéder à des informations dans un répertoire (une base de données) et de les mettre à jour, localement ou à distance, dans un modèle client–serveur. La méthode LDAP est utilisée par un cluster d’hôtes pour permettre une authentification centralisée de la sécurité ainsi que l’accès à des informations sur les utilisateurs et les groupes. Dans un environnement de cluster, cette fonctionnalité permet d’utiliser les mêmes informations d’authentification, d’utilisateur et de groupe dans tout l’environnement. L’exploitation LDAP du sous–système de sécurité est implémentée en tant que module de chargement d’authentification LDAP. De par sa conception, elle est similaire aux autres modules de chargement tels que NIS, DCE et Kerberos 5. Ces modules sont définis dans le fichier /usr/lib/security/methods.cfg. Le module de chargement d’authentification LDAP est implémenté à bas niveau, par les bibliothèques. Une fois ce module activé pour donner des informations sur les utilisateurs et les groupes, la plupart des API de haut niveau, des commandes et des outils de gestion de systèmes fonctionnent de manière habituelle. L’indicateur –R sert pour que la plupart des commandes de haut niveau puissent utiliser différents modules de chargement. Par exemple, la commande suivante créera depuis un poste client un utilisateur LDAP nommé joe : mkuser –R LDAP joe Le système client vérifie si l’utilisateur est un utilisateur LDAP par le biais de son attribut SYSTEM dans le fichier /etc/security/user. Si cet attribut est défini sur LDAP, cet utilisateur ne peut s’authentifier que par le biais de LDAP. Si l’attribut SYSTEM de la strophe par défaut est défini sur LDAP, tous les utilisateurs dont l’attribut SYSTEM n’est pas défini sont considérés comme étant des utilisateurs LDAP. Le mot–clé LDAP peut être utilisé avec d’autres valeurs d’attribut SYSTEM comme indiqué dans la section Authentification de l’utilisateur, page 2-30. Le système client communique avec le serveur par l’intermédiaire du démon secldapclntd. Le démon accepte les requêtes des applications (par les API de bibliothèque), émet une requête vers le serveur LDAP et renvoie les données à l’application. Il est également chargé de la mise en antémémoire. Configuration d’un serveur d’informations de sécurité LDAP Pour configurer un système comme serveur d’informations de sécurité LDAP pour l’authentification, les utilisateurs et les groupes, les modules LDAP serveur et client doivent être installés. Le serveur LDAP doit être configuré comme client et comme serveur. Il nécessite également une base de données DB2. Si Secure Socket Layer (SSL) est nécessaire, le GSKit doit être installé. L’administrateur système doit créer une clé à l’aide de la commande ikeyman. Le certificat de la clé du serveur doit être transmis aux clients. La commande mksecldap peut être utilisée pour configurer un serveur d’informations de sécurité LDAP. Elle configure une base de données appelée ldapdb2, y écrit les informations sur les utilisateurs et sur les groupes obtenues de l’hôte local, et définit le nom spécifique et le mot de passe de l’administrateur du serveur LDAP. Elle peut également configurer SSL pour la communication client/serveur. mksecldap charge ensuite un plug–in serveur (libsecldap.a) et démarre le processus du serveur LDAP (slapd). La commande mksecldap ajoute également une entrée au fichier /etc/inittab pour lancer le serveur LDAP à chaque redémarrage. Toute la configuration du serveur LDAP est effectuée à l’aide de la commande mksecldap, qui met à jour les fichiers slapd.conf (SecureWay (R) Directory version 3.1) ou slapd32.conf (SecureWay Directory version 3.2). Il n’est pas nécessaire de configurer l’interface de gestion Web de LDAP. Utilisation du protocole LDAP du sous–système de sécurité 4-1 Tous les utilisateurs et les groupes du local system sont transférés vers le serveur LDAP lors de sa configuration. Pour cette étape, choisissez l’un des schémas LDAP suivants : Schéma AIX spécifique Comprend les classes d’objets aixAccount et aixAccessGroup. Ce schéma apporte un ensemble complet d’attributs pour les utilisateurs et les groupes AIX. Schéma NIS (RFC 2307) Comprend posixAccount et le compte posixGroup ; il est utilisé par les répertoires de certains éditeurs. Ce schéma ne définit qu’une petite partie des attributs utilisés par AIX. Schéma NIS avec support AIX complet Comprend les classes d’objets posixAccount et posixGroup, ainsi que les classes aixAusAccount et aixAusGroup. Ces dernières fournissent les attributs utilisés par AIX qui ne sont pas définis par le schéma NIS. Il est recommandé de configurer le serveur LDAP à l’aide du schéma NIS avec support AIX complet, sauf si vous devez utiliser un schéma LDAP particulier pour des raisons de compatibilité avec d’autres serveurs LDAP. Toutes les informations sur les utilisateurs et les groupes sont stockées dans une même arborescence (suffixe) AIX. Le suffixe par défaut est ”cn=aixsecdb”. La commande mksecldap accepte un suffixe fourni par l’utilisateur avec l’indicateur –d. Si le premier nom spécifique relatif (Relative Distinguished Name, RDN) du suffixe fourni par l’utilisateur n’est pas ”cn=aixsecdb”, mksecldap précède ce suffixe par ”cn=aixsecdb”. Cette arborescence AIX est protégée par une liste de contrôle d’accès (ACL). Pour accéder à l’arborescence AIX, un client doit établir une liaison en tant qu’administrateur du serveur LDAP. La commande mksecldap fonctionne même si un serveur LDAP a été configuré pour d’autres utilisations (pour des informations de page bleue par exemple). Dans ce cas, mksecldap ajoute l’arborescence AIX et la remplit avec les informations sur la sécurité AIX dans la base de données existante. Cette arborescence est spécifiquement protégée par une ACL. Le serveur LDAP fonctionne normalement, et sert également de serveur de sécurité LDAP AIX. Remarque : Il est conseillé de sauvegarder la base de données avant d’exécuter la commande mdsecldap et de configurer le serveur de sécurité pour l’utilisation partagée de la base de données. Une fois le serveur d’informations de sécurité LDAP configuré, il doit également être configuré en tant que client pour permettre la gestion des utilisateurs et des groupes LDAP ainsi que la connexion au serveur des utilisateurs LDAP. Si la configuration du serveur d’informations de sécurité LDAP échoue, vous pouvez l’annuler par la commande mksecldap avec l’indicateur –U. Le fichier slapd.conf (ou slapd32.conf) redevient alors tel qu’il était avant la configuration. Vous utiliserez la commande mksecldap avec l’indicateur –U après une tentative infructueuse de configuration, et avant d’essayer à nouveau la commande mksecldap. Sinon, des informations peuvent rester dans le fichier de configuration et faire échouer la configuration suivante. Pour des raisons de sécurité, l’option annulation ne modifie ni la base de données ni ses données, car cette base peut avoir existé avant l’exécution de la commande mksecldap. Vous devez supprimer manuellement toute base de données créée par la commande mksecldap. Si des données ont été ajoutées à une base de données préexistante par la commande mksecldap, vous devez décider des mesures à prendre pour corriger la tentative de configuration. A partir de la version 5.2 d’AIX, il est également possible de configurer le serveur LDAP à l’aide de la commande mknisldap. Elle configure le serveur de la même façon que la commande mksecldap et transfère les autres données NIS, ainsi que les utilisateurs et les groupes, vers le serveur LDAP. Pour en savoir plus sur la configuration d’un serveur d’informations de sécurité LDAP, reportez–vous à la commande mksecldap. 4-2 Guide de sécurité Configuration d’un client LDAP Le module client LDAP doit être installé sur chaque client. Si SSL est nécessaire, le GSKit doit être installé, une clé doit être créée et le certificat de la clé SSL du serveur LDAP doit être ajouté à cette clé. La commande mksecldap peut être utilisée pour configurer le client. Pour que ce client contacte le serveur d’informations de sécurité LDAP, le nom du serveur doit être indiqué pendant la configuration. Le nom de domaine et le mot de passe de l’administrateur du serveur sont également nécessaires pour que le client accède à l’arborescence AIX sur le serveur. La commande mksecldap sauvegarde le nom de domaine et le mot de passe de l’administrateur du serveur, le nom du serveur, le nom de domaine de l’arborescence AIX, ainsi que le chemin et le mot de passe de la clé SSL dans le fichier /etc/security/ldap/ldap.cfg. Plusieurs serveurs peuvent être fournis à la commande mksecldap pendant la configuration du client. Dans ce cas, le client contacte les serveurs dans l’ordre indiqué et se connecte au premier serveur avec lequel il réussit à établir une liaison. Si la connexion entre le client et le serveur est défaillante, une requête de reconnexion est tentée à l’aide de la même logique. Le modèle de sécurité LDAP n’assure pas la référence. Il est important que les serveurs dupliqués restent synchronisés. Le client communique avec le serveur d’informations de sécurité LDAP par le biais d’un démon côté client (secldapclntd). Si le module de chargement LDAP est activé sur ce client, les commandes de haut niveau finissent par trouver ce démon par le biais des API. Le démon interroge le serveur et renvoie les informations à celui qui les a demandées. D’autres options d’optimisation peuvent être passées à la commande mksecldap pendant la configuration du client, comme le nombre de routines utilisées par le démon, la capacité de l’entrée cache et le délai d’expiration de cache. Ces options sont réservées aux utilisateurs expérimentés. Pour la plupart des environnements, les valeurs par défaut sont suffisantes. Une liste d’utilisateurs (séparés par des virgules) peut être fournie à la commande mksecldap pendant la configuration du client. Les attributs SYSTEM de ces utilisateurs sont définis sur LDAP. Ces utilisateurs ne peuvent ensuite s’authentifier que par le biais du module de chargement LDAP. Pour éviter les ID utilisateur en double dans la base de données LDAP, la commande mksecldap n’ajoute pas ces utilisateurs au serveur d’informations de sécurité LDAP. Pour créer ces utilisateurs sur un serveur LDAP, il est recommandé d’utiliser la commande mkuser avec l’indicateur –R LDAP. Dans les étapes finales de la configuration du client, la commande mksecldap lance le démon côté client et ajoute une entrée dans le fichier /etc/inittab pour que le démon soit lancé à chaque redémarrage. Vous pouvez vérifier si la configuration a réussi en consultant le processus secldapclntd. Du moment que le serveur d’informations de sécurité LDAP est configuré et fonctionne, ce démon s’exécutera si la configuration a réussi. Utilisation du protocole LDAP du sous–système de sécurité 4-3 Gestion des utilisateurs LDAP Vous pouvez gérer des utilisateurs et des groupes sur un serveur d’informations de sécurité LDAP à partir de n’importe quel client LDAP et de commandes de haut niveau. En ajoutant l’indicateur –R à la plupart de ces commandes, vous pouvez gérer des utilisateurs et des groupes à l’aide de LDAP ainsi que d’autres modules de chargement d’authentification tels que DCE, NIS et Kerberos 5. Pour obtenir plus d’informations sur l’utilisation de l’indicateur –R, reportez–vous à chaque commande de gestion d’utilisateurs ou de groupes. Pour permettre à un utilisateur de s’authentifier par le biais de LDAP, utilisez la commande chuser pour définir sur LDAP son attribut SYSTEM. En définissant l’attribut SYSTEM selon la syntaxe définie, un utilisateur peut être authentifié par plusieurs modules de chargement (compat et LDAP par exemple). Pour obtenir plus d’informations sur les méthodes d’authentification, reportez–vous à la section Authentification de l’utilisateur, page 2-30 et à la syntaxe de l’attribut SYSTEM définie dans le fichier /etc/security/user. Un utilisateur peut devenir un utilisateur LDAP au moment de la configuration du client en exécutant la commande mksecldap avec l’indicateur –u sous l’une des formes suivantes : 1. mksecldap –c –u user1,user2,..., où user1,user2,... est la liste des utilisateurs. Ces utilisateurs peuvent être définis localement ou à distance, avec LDAP. L’attribut SYSTEM a pour valeur LDAP dans chacune des strophes d’utilisateurs ci–dessus dans le fichier /etc/security/user. Ces utilisateurs ne seront authentifiés que par LDAP. Les utilisateurs de cette liste doivent exister sur le serveur d’informations de sécurité LDAP, sinon ils ne peuvent pas se connecter à partir de cet hôte. Lancez la commande chuser pour modifier l’attribut SYSTEM et permettre l’authentification par plusieurs méthodes (locale et LDAP par exemple). 2. ”mksecldap –c –u ALL”. Cette commande donne à l’attribut SYSTEM la valeur LDAP, dans chaque strophe utilisateur du fichier /etc/security/user, pour tous les utilisateurs définis localement. Tous ces utilisateurs ne s’authentifient que par LDAP. Les utilisateurs définis localement doivent exister sur le serveur d’informations de sécurité LDAP, sinon ils ne peuvent pas se connecter à partir de cet hôte. Un utilisateur défini sur le serveur LDAP, mais pas localement, ne peut pas se connecter à partir de cet hôte. Pour permettre à un utilisateur défini à distance avec LDAP de se connecter à partir de cet hôte, lancez la commande chuser pour donner à l’attribut SYSTEM de cet utilisateur la valeur LDAP. Vous pouvez également permettre à tous les utilisateurs LDAP, qu’ils soient définis localement ou pas, de s’authentifier par le biais de LDAP sur un hôte local en modifiant la strophe “par défaut” du fichier /etc/security/user et utiliser la valeur ”LDAP”. Tous les utilisateurs dont la valeur de l’attribut SYSTEM n’est pas définie suivront celui défini dans la strophe par défaut. Par exemple, si la strophe par défaut est ”SYSTEM = ”compat””, passer à ”SYSTEM = ”compat OR LDAP”” authentifiera ces utilisateurs par AIX ou LDAP. La modification de la strophe par défaut en ”SYSTEM = ”LDAP”” impose à ces utilisateurs de s’authentifier par LDAP. Les utilisateurs pour lesquels l’attribut SYSTEM est défini ne sont pas affectés par la strophe par défaut. 4-4 Guide de sécurité Contrôle d’accès par LDAP AIX fournit à un système un contrôle d’accès à un hôte (connexion) au niveau utilisateur. Les administrateurs peuvent configurer les utilisateurs LDAP pour se connecter à un système AIX en définissant leur attribut SYSTEM sur LDAP. L’attribut SYSTEM se trouve dans le fichier /etc/security/user. La commande chuser peut être utilisée pour définir sa valeur, comme dans l’exemple suivant : # chuser –R LDAP SYSTEM=LDAP registry=LDAP foo Remarque : Avec ce type de contrôle, ne définissez pas la valeur par défaut de l’attribut SYSTEM sur LDAP, car cela autoriserait tous les utilisateurs à se connecter au système. L’attribut LDAP ainsi défini autorise l’utilisateur foo à se connecter au système. Le registre est également défini sur LDAP, ce qui permet au processus de connexion de consigner toutes les tentatives de connexion à LDAP de foo, et autorise également toutes les tâches de gestion des utilisateurs effectuées via LDAP. Pour autoriser la connexion en fonction des utilisateurs, l’administrateur doit effectuer cette configuration sur chacun des systèmes clients. Avec AIX 5.2, l’accès des utilisateurs LDAP peut désormais être limité à certains systèmes clients LDAP. Cette fonction permet la gestion centralisée des contrôles d’accès. Les administrateurs ont la possibilité de créer deux listes de contrôle d’accès pour chaque utilisateur : une liste d’accès accordés et une liste d’accès refusés. Ces deux attributs sont enregistrés avec le compte utilisateur, sur le serveur LDAP. L’utilisateur est donc autorisé à accéder aux systèmes ou réseaux répertoriés dans la liste d’accès accordés, tandis que l’accès aux systèmes et réseaux spécifiés dans la liste d’accès refusés lui est interdit. Si un système apparaît dans les deux listes, son accès est refusé à l’utilisateur. La liste d’accès accordés se définit par la commande mkuser, lors de la création du compte utilisateur, ou par la commande chuser si l’utilisateur existe déjà. Pour des raisons de compatibilité, si aucune de ces listes n’existent pour un utilisateur, l’accès à tous les systèmes clients LDAP lui est accordé par défaut. Pour bénéficier de la fonction de contrôle d’accès, il est donc fortement recommandé de mettre à niveau tous les systèmes clients LDAP vers AIX 5.2 (ou supérieur), afin que les listes d’accès accordés et refusés soient appliquées. Voici des exemples de définition de listes d’accès accordés et refusés : # mkuser –R LDAP hostsallowedlogin=host1,host2 foo L’utilisateur foo est créé, et il n’est autorisé à se connecter qu’à host1 et host2. # mkuser –R LDAP hostsdeniedlogin=host2 foo L’utilisateur foo est créé ; il est autorisé à se connecter à tous les systèmes clients LDAP, hormis host2. # chuser –R LDAP hostsallowedlogin=192.9.200.1 foo L’utilisateur foo est ici autorisé à se connecter au système client dont l’adresse est 192.9.200.1. # chuser –R LDAP hostsallowedlogin=192.9.200/24 \ hostsdeniedlogin=192.9.200.1 foo L’utilisateur foo est autorisé à se connecter à tout client appartenant au sous–réseau 192.9.200/24, excepté celui qui a pour adresse 192.9.200.1. Pour en savoir plus, reportez–vous à la commande chuser. Utilisation du protocole LDAP du sous–système de sécurité 4-5 Audit du serveur d’informations de sécurité LDAP SecureWay Directory version 3.2 offre une fonctionnalité d’enregistrement des audits serveur. Une fois activé, ce plug–in d’audit enregistre les activités du serveur LDAP dans un fichier journal. Pour plus d’informations sur ce plug–in, reportez–vous au manuel Packaging Guide for LPP Installation dans la documentation LDAP. Une fonction d’audit de serveur d’informations de sécurité LDAP a été mise en place dans AIX versions 5.1 et ultérieures, le plug–in d’audit de sécurité LDAP. Elle est indépendante du service d’audit par défaut de SecureWay Directory. Il est donc possible d’activer l’un ou l’autre sous–système d’audit, ou les deux. Le plug–in d’audit d’AIX n’enregistre que les événements qui mettent à jour ou demandent des informations sur la sécurité d’AIX sur un serveur LDAP. Il fonctionne dans le cadre d’audit du système AIX. Pour accepter LDAP, les événements audit suivants sont compris dans le fichier /etc/security/audit/event : • LDAP_Bind • LDAP_Unbind • LDAP_Add • LDAP_Delete • LDAP_Modify • LDAP_Modifydn • LDAP_Search La définition de classe d’audit ldapserver est également créée dans le fichier /etc/security/audit/config qui contient tous les événements cités ci–dessus. Pour que le serveur d’informations de sécurité LDAP subisse un audit, ajoutez la ligne suivante à chaque strophe d’utilisateur dans le fichier /etc/security/audit/config : ldap = ldapserver comme le plug–in d’audit du serveur d’informations de sécurité LDAP est implémenté dans le cadre de l’audit du système AIX, il fait partie de ce sous–système. Vous pouvez activer ou désactiver l’audit du serveur d’informations de sécurité LDAP à l’aide de commandes audit du système, comme audit start (démarrer l’audit) ou audit shutdown (arrêter l’audit). Tous les enregistrements d’audit sont ajoutés aux traces d’audit du système, qui peuvent être consultées à l’aide de la commande auditpr. Pour en savoir plus, reportez–vous à Audit, page 3-1. Commandes LDAP La commande mksecldap La commande mksecldap peut servir à configurer des serveurs et des clients SecureWay Directory pour la gestion des données de sécurité et des authentifications. Elle doit être exécutée sur le serveur, ainsi que sur tous les clients. Remarques : 1. les options clients (indicateur –c ) et serveur (indicateur –s) ne peuvent être utilisées en même temps. Au cours de la configuration d’un serveur, la commande mksecldap doit être exécutée deux fois. La première pour configurer le serveur, la deuxième pour configurer le client. 2. Pour AIX 3.2 et supérieur, le fichier de configuration de SecureWay Directory server est /etc/slapd32.conf. AIX 5.2 n’est compatible qu’avec SecureWay Directory 3.2 et plus. Pour la configuration du serveur, assurez–vous que l’ensemble de fichiers ldap.server est bien installé. L’ensemble de fichiers ldap.client et le logiciel DB2 sont automatiquement 4-6 Guide de sécurité installés lors de l’installation de l’ensemble de fichiers ldap.server. Il n’est pas nécessaire de préconfigurer DB2 pour exécuter cette commande lors de la configuration d’un serveur LDAP. La commande mksecldap effectue les opérations suivantes : 1. Création d’une instance DB2, nommée par défaut ldapdb2. 2. Création d’une base de données DB2, nommée par défaut ldapdb2. S’il existe déjà une base de données, la commande mksecldap omettra ces deux premières étapes (c’est le cas si le serveur LDAP a déjà été configuré pour un autre usage). La commande mksecldap utilisera alors la base de données existante pour stocker les données utilisateur/groupe AIX. 3. Création du DN de l’arborescence (suffixe) AIX. Si aucun DN de base n’est fourni dans la ligne de commande, le suffixe utilisé par défaut est cn=aixdata et les données utilisateur/groupe sont placées dans le DN cn=aixsecdb,cn=aixdata. Il est conseillé de conserver ces paramètres. Dans le cas contraire, la commande mksecldap utilise le DN spécifié par l’utilisateur, et y ajoute le préfixe cn=aixdata pour en faire le suffixe. Ce mécanisme est présenté dans le tableau ci–dessous. Entre parenthèses figure le DN fourni par l’utilisateur en ligne de commande. DN de ligne de CMD : [o=ibm] suffixe : cn=aixdata[,o=ibm] DN sécurité : cn=aixsecdb,cn=aixdata[,o=ibm] DN utilisateur : ou=aixuser,cn=aixsecdb,cn=aixdata[,o=ibm] DN groupe : ou=aixgroup,cn=aixsecdb,cn=aixdata[,o=ibm] Si le serveur LDAP a déjà été configuré localement, la commande mksecldap recherche le mot clé cn=aixsecdb parmi les suffixes définis dans le fichier de configuration slapd32.conf et dans la base de données. Si elle le trouve, elle considère qu’elle a déjà été exécutée et se termine, sans effectuer les étapes de configuration du DN de base et de migration des utilisateurs/groupes. Si la commande mksecldap ne trouve le mot clé cn=aixsecdb ni parmi les suffixes, ni dans la base de données, elle recherche le mot clé cn=aixdata. cn=aixdata est un DN de base commun à plusieurs composants AIX LDAP. Si la commande trouve ce mot clé, elle le compare avec le DN fourni par l’utilisateur. S’ils sont identiques, les utilisateurs/groupes seront classés sous cn=aixsecdb,cn=aixdata,[DNutilisateur]. S’ils diffèrent, la commande mksecldap émet un message d’erreur indiquant qu’il existe un DN cn=aixdata,... et ne transfère pas les utilisateurs/groupes sous le DN fourni par l’utilisateur. Vous pouvez alors utiliser le DN cn=aixdata,... existant, en lançant de nouveau la commande mksecldap avec lui. Utilisation du protocole LDAP du sous–système de sécurité 4-7 4. Migration des données figurant dans les fichiers de la base de données de sécurité locale vers la base de données LDAP. La commande mksecldap transfère les utilisateurs/groupes à l’aide de l’un des trois schémas LDAP suivants, en fonction de l’option –S : – AIX : schéma AIX (classes d’objets aixaccount et aixaccessgroup) – RFC2307 : schéma RFC 2307 (classes d’objets posixaccount, shadowaccount et posixgroup) – RFC2307AIX : schéma RFC 2307 avec support AIX complet ( classes d’objets posixaccount, shadowaccount et posixgroup, plus les classes aixauxaccount et aixauxgroup). Attention : Les systèmes configurés comme clients LDAP et sous AIX 4.3 ou AIX 5.1, ne pourront travailler qu’avec des serveurs utilisant le schéma AIX. Aucun échange ne sera possible avec des serveurs LDAP de type RFC2307 ou RFC2307AIX. 5. Définition du DN et du mot de passe administrateur du serveur LDAP. Cette combinaison nom/mot de passe est également utilisée pour le contrôle de l’accès à l’arborescence AIX. 6. Configuration de SSL (Secure Socket Layer) pour sécuriser le transfert des données entre le serveur et les clients. Pour cette opération, le GSKIT doit être installé. Remarque : pour utiliser cette option, la clé SSL doit être créée avant de lancer la commande mksecldap. Sinon, le serveur sera peut–être dans l’impossibilité de démarrer. 7. Installation du plug–in de serveur LDAP /usr/ccs/lib/libsecldapaudit.a. Ce plug–in assure la fonction d’audit AIX du serveur LDAP. 8. Démarrage/redémarrage du serveur LDAP après toutes les opérations ci–dessus. 9. Ajout du processus serveur LDAP ( slapd) à /etc/inittab pour relancer le serveur LDAP après chaque redémarrage du serveur. 10.Annulation, à l’aide de l’option –U, de la modification précédente du fichier de configuration du serveur. Lorsque vous exécutez la commande mksecldap pour la première fois, elle enregistre deux copies du fichier de configuration de serveur slapd32.conf. L’une sous le nom /etc/security/ldap/slap32.conf.save.orig et l’autre comme /etc/ security/ldap/slapd32.conf.save. Lors des exécutions suivantes de mksecldap, le fichier slapd32.conf courant est uniquement enregistré sous /etc/security/ldap/slapd32.conf.save. L’option annulation restaure le fichier /etc/slapd32.conf de configuration du serveur avec la copie enregistrée sous /etc/security/ ldap/slapd32.conf.save. Remarque : Remarque : l’option d’annulation ne s’applique qu’au fichier de configuration du serveur. Elle n’a aucun effet sur la base de données. Toute la configuration LDAP est enregistrée dans le fichier /etc/slapd32.conf de configuration du serveur LDAP. Avant de configurer le client, assurez–vous que le serveur LDAP a été configuré et qu’il fonctionne. La commande mksecldap effectue les opérations suivantes lors de la configuration d’un client : 1. Enregistrement du nom d’hôte du ou des serveurs LDAP. 2. Enregistrement du DN de base utilisateur et du DN de base groupe du serveur. En l’absence de l’option –d, mksecldap recherche sur le serveur LDAP les classes d’objets aixaccount, aixaccessgroup, posixaccount, posixgroup et aixauxaccount, pour définir les DN de base. Si le serveur comporte plusieurs bases utilisateur/groupe, vous devez fournir un RDN à l’option –d afin que la commande mksecldap puisse définir les DN de base en fonction de ceux contenus dans le RDN. 4-8 Guide de sécurité Si mksecldap trouve la classe d’objets posixaccount au cours de la configuration du client, elle recherche également sur le serveur, puis enregistre, les DN de base des entités suivantes : hôtes, réseaux, services, groupes réseaux, protocoles et RPC. 3. Identification du type de schéma utilisé par le serveur LDAP : schéma AIX spécifique, schéma RFC 2307 ou schéma RFC 2307 avec support AIX complet (voir les classes d’objet répertoriées à l’étape 2). Elle définit en conséquence les classes d’objets et les mappes d’attributs dans le fichier /etc/security/ldap/ ldap.cfg. La commande mksecldap ne reconnaît que ces types de schéma. Les clients doivent donc être configurés manuellement. 4. Configuration de SSL pour sécuriser le transfert des données entre l’hôte et le serveur LDAP. Pour cette étape, la clé et le mot de passe SSL doivent avoir été préalablement créés. De plus, le serveur doit être configuré pour utiliser SSL pour que le SSL du client fonctionne. 5. Enregistrement du DN et du mot de passe administrateur du serveur LDAP. La combinaison DN/mot de passe doit être identique à celle indiquée au cours de la configuration du serveur. 6. Définition de la taille du cache en nombre d’entrées utilisées par le démon du côté client. Les valeurs vont de 100 à 10 000 pour les utilisateurs, et de 10 à 1 000 pour les groupes. La valeur par défaut est 1 000 pour les utilisateurs et 100 pour les groupes. 7. Définition du délai d’expiration du cache pour le démon du côté client. Les valeurs admises vont de 60 à 3 600 secondes. La valeur par défaut est de 300 secondes. La valeur 0 désactive la mise en cache. 8. Définition du nombre de processus utilisés par le démon du côté client. La valeur doit être comprise entre 1 et 1 000. La valeur par défaut est 10. 9. Définition de l’intervalle (en secondes) entre deux vérifications du statut du serveur LDAP par le démon client. Les valeurs admises vont de 60 à 3 600 secondes. La valeur par défaut est 300. 10.Peut définir une liste des utilisateurs, ou tous les utilisateurs, pour qu’ils utilisent LDAP, en modifiant la ligne SYSTEM du fichier /etc/security/user. Pour en savoir plus sur l’activation de la connexion LDAP, reportez–vous à la remarque ci–dessous. 11. Démarrage du processus de démon client (secldapclntd). 12.Ajout du processus de démon côté client à /etc/inittab pour qu’il démarre après chaque redémarrage du serveur. 13.Annulation, à l’aide de l’option –U, de la précédente modification du fichier de configuration /etc/security/ldap/ldap.cfg. Remarque : Les données de configuration du client sont stockées dans le fichier /etc/security/ldap/ldap.cfg. Définir SYSTEM sur LDAP dans la strophe par défaut de /etc/security/user n’autorise que les utilisateurs LDAP à se connecter au système. Définir SYSTEM sur LDAP ou compat permet à la fois aux utilisateurs LDAP et aux utilisateurs locaux de se connecter au système. Exemples 1. Pour configurer un serveur LDAP de schéma AIX spécifique pour les utilisateurs et les groupes, saisissez : mksecldap –s –a cn=admin –p adminpwd –S aix Le serveur LDAP se voit attribuer cn=admin comme DN administrateur, et adminpwd comme mot de passe. Les données utilisateur et groupe sont transférées des fichiers locaux vers le suffixe par défaut cn=aixdata. 2. Pour configurer un serveur LDAP avec un autre DN de base que la valeur par défaut, et utilisant SSL, saisissez : Utilisation du protocole LDAP du sous–système de sécurité 4-9 mksecldap –s –a cn=admin –p adminpwd –d o=mycompany,c=us –S rfc2307 \ –k /usr/ldap/serverkey.kdb –w keypwd Le serveur LDAP se voit attribuer cn=admin comme DN administrateur et adminpwd comme mot de passe. Les données utilisateur et groupe sont transférées des fichiers locaux vers le suffixe cn=aix–data,o=mycompany,c=us. Le serveur LDAP utilise SSL pour ses communications avec la clé stockée sous /usr/ldap/serverkey.kdb. Le mot de passe de la clé, keypwd, doit également être indiqué. Les utilisateurs et les groupes sont migrés avec le schéma RFC 2307. 3. Pour annuler la configuration d’un serveur : mksecldap –s –U Cette commande annule la configuration précédemment enregistrée dans le fichier de configuration de serveur /etc/slapd32.conf. Pour des raisons de sécurité, aucune base de données et aucune entrée créée par une précédente configuration n’est supprimée. Si des bases de données ou des entrées sont devenues inutiles, supprimez–les manuellement. 4. Pour configurer un client pour qu’il utilise les serveurs LDAP server1.ibm.com et server2.ibm.com, saisissez : mksecldap –c –a cn=admin –p adminpwd –h server1.ibm.com,server2.ibm.com Le DN et le mot de passe administrateur du serveur LDAP doivent être fournis au client pour lui permettre de s’authentifier. La commande mksecldap contacte le serveur LDAP pour connaître son type de schéma, puis configure le client en conséquence. En l’absence de l’option –d dans la ligne de commande, le DIT du serveur est entièrement parcouru pour trouver les DN de base utilisateur et groupe. 5. Pour configurer le client pour qu’il communique avec le serveur LDAP server3.ibm.com en utilisant SSL, saisissez : mksecldap –c –a cn=admin –p adminpwd –h server3.ibm.com –d o=mycompany,c=us –k /usr/ldap/clientkey.kdb –w keypwd –u user1,user2 La configuration du client LDAP est similaire à celle du point 4, avec en plus l’utilisation de SSL. La commande mksecldap recherche les DN de base utilisateur et groupe dans le RDN o=mycompany,c=us. Les comptes user1 et user2 sont configurés pour s’authentifier via LDAP. Remarque : L’option –u ALL permet à tous les utilisateurs LDAP de se connecter à ce client. 6. Pour annuler la configuration d’un client : mksecldap –c –U Cette commande annule la configuration précédemment enregistrée dans le fichier /etc/security/ldap/ldap.cfg. Elle n’annule pas les entrées SYSTEM=LDAP et registry=LDAP du fichier /etc/security/user. Pour plus de détails sur la commande mksecldap, reportez–vous à mksecldap dans le manuel AIX 5L Version 5.2 Commands Reference. Le démon secldapclntd Le démon secldapclntd reçoit des requêtes de la part des modules de chargement LDAP, les transmet au serveur d’informations de sécurité LDAP, puis renvoie les résultats au module de chargement LDAP. Pendant le démarrage, il lit les informations de configuration du fichier /etc/security/ldap/ldap.cfg, s’authentifie auprès du serveur d’informations de sécurité LDAP avec le DN et le mot de passe administrateur du serveur, puis établit une connexion entre l’hôte local et le serveur. Si plusieurs serveurs sont indiqués dans le fichier /etc/security/ldap/ldap.cfg, le démon secldapclntd se connecte à tous ces serveurs. Toutefois, il ne communique qu’avec un seul serveur à la fois. Si le serveur avec lequel il est en communication ne fonctionne plus, le démon secldapclntd détecte cette panne et s’adresse automatiquement à un autre 4-10 Guide de sécurité serveur disponible. Le démon est également capable de détecter qu’un serveur est de nouveau disponible, auquel cas il rétablit la connexion avec celui–ci, sans pour autant interrompre la communication en cours. Pour cette fonction de détection automatique, le démon secldapclntd procède périodiquement à la vérification de tous les serveurs. L’intervalle entre deux vérifications est fixé par défaut à 300 secondes. Il peut être modifié lors du démarrage du démon à l’aide de la ligne de commande, ou en ajustant les valeurs correspondantes dans le fichier /etc/ security/ldap/ldap.cfg. Le démon secldapclntd tente de se connecter aux serveurs LDAP lors du démarrage. S’il ne parvient pas à se connecter à un serveur, il se met en sommeil et fait une nouvelle tentative 30 secondes plus tard. Cette procédure est répétée deux fois. Si elle échoue, le processus du démon secldapclntd se termine. Le démon secldapclntd est un programme à plusieurs unités d’exécution. Par défaut, le démon utilise 10 processus. Le nombre de processus peut être ajusté par l’administrateur pour améliorer les performances du système. Dans ce même objectif, le démon secldapclntd met en cache les informations récupérées sur le serveur d’informations de sécurité LDAP. Si les données demandées sont disponibles dans le cache et n’ont pas expiré, le démon les utilise pour répondre au demandeur. Sinon, il envoie une requête au serveur d’informations de sécurité LDAP. Le nombre d’entrées du cache va de 100 à 10 000 pour les utilisateurs (1 000 par défaut), et de 10 à 1 000 pour les groupes (100 par défaut). Le délai d’expiration du cache (TTL) peut aller de 60 secondes à 1 heure (60*60 = 3 600 secondes). Par défaut, il est de 300 secondes. Un délai de 0 désactive la mise en cache. Exemples 1. Pour démarrer le démon secldapclntd, saisissez : /usr/sbin/secldapclntd 2. Pour démarrer le démon secldapclntd avec l’utilisation de 20 unités d’exécution et un délai d’expiration du cache de 600 secondes, tapez : /usr/sbin/secldapclntd –p 20 –t 600 Il est recommandé de démarrer le démon secldapclntd à l’aide de la commande start–secldapclntd. Il est également recommandé d’indiquer ces valeurs dans le fichier /etc/security/ldap/ldap.cfg, de façon à ce qu’elles soient prises en compte à chaque démarrage du processus secldapclntd. Pour plus de détails sur le démon secldapclntd, reportez–vous à secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Les commandes de gestion LDAP Commande start–secldapclntd La commande start–secldapclntd lance le démon secldapclntd s’il n’est pas en cours d’exécution. S’il fonctionne déjà, elle n’a aucun effet. Le script supprime aussi les enregistrements du mappeur de port (le cas échéant) relatifs aux processus précédents du démon secldapclntd avant chaque nouveau démarrage. Ceci évite tout échec de démarrage du démon dû à une erreur d’enregistrement dans le mappeur de port. Exemples 1. Pour démarrer le démon secldapclntd, saisissez : /usr/sbin/start–secldapclntd 2. Pour démarrer le démon secldapclntd avec l’utilisation de 20 unités d’exécution et un délai d’expiration du cache de 600 secondes, tapez /usr/sbin/start–secldapclntd –p 20 –t 600 Utilisation du protocole LDAP du sous–système de sécurité 4-11 Il est recommandé d’indiquer ces valeurs dans le fichier /etc/security/ldap/ldap.cfg, de façon à ce qu’elles soient prises en compte à chaque démarrage du processus secldapclntd. Pour plus de détails sur la commande start–secldapclntd, reportez–vous à start–secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Commande stop–secldapclntd La commande stop–secldapclntd arrête le démon secldapclntd en cours d’exécution. S’il ne fonctionne pas, elle retourne une erreur. Exemple Pour arrêter un processus de démon secldapclntd, tapez : /usr/sbin/stop–secldapclntd Pour plus de détails sur la commande stop–secldapclntd, reportez–vous à stop–secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Commande restart–secldapclntd Le script restart–secldapclntd arrête le démon secldapclntd s’il fonctionne, puis le redémarre. Si le démon ne fonctionne pas, il se contente de le démarrer. Exemples 1. Pour redémarrer le démon secldapclntd, saisissez : /usr/sbin/restart–secldapclntd 2. Pour redémarrer secldapclntd avec 30 unités d’exécution et un délai d’expiration du cache de 500 secondes, tapez : /usr/sbin/restart–secldapclntd –p 30 –t 500 Pour plus de détails sur la commande restart–secldapclntd, reportez–vous à restart–secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Commande ls–secldapclntd La commande ls–secldapclntd affiche l’état du démon secldapclntd. Les informations suivantes sont retournées : • Le serveur LDAP auquel s’adresse le démon secldapclntd • Le numéro du port du serveur LDAP • La version du protocole LDAP utilisée • Le DN de base utilisateur • Le DN de base groupe • Le DN de base du système (ID) • La taille du cache utilisateur • L’occupation du cache utilisateur • La taille du cache groupe • L’occupation du cache groupe • Le délai d’expiration du cache (durée de vie) • La fréquence des interrogation émises par secldapclntd à destination du serveur LDAP • Le nombre d’unités d’exécution utilisés par le démon secldapclntd • La classe d’objets utilisateur utilisée par le serveur LDAP • La classe d’objets groupe utilisée par le serveur LDAP 4-12 Guide de sécurité Exemple 1. Pour afficher l’état du démon secldapclntd, saisissez : /usr/sbin/ls–secldapclntd Pour plus de détails sur la commande ls–secldapclntd, reportez–vous à ls–secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Commande flush–secldapclntd La commande flush–secldapclntd nettoie le cache pour le processus du démon secldapclntd. Exemple 1. Pour nettoyer le cache du démon secldapclntd, saisissez : /usr/sbin/flush–secldapclntd Pour plus de détails sur la commande flush–secldapclntd, reportez–vous à flush–secldapclntd dans le manuel AIX 5L Version 5.2 Commands Reference. Commande sectoldif La commande sectoldif accède aux utilisateurs et aux groupes définis localement et envoie le résultat au format ldif vers stdout. S’il est redirigé vers un fichier, le résultat peut être ajouté au serveur LDAP à l’aide de la commande ldapadd ou de la commande db2ldif. L’option –S précise le type de schéma utilisé pour la sortie ldif. La commande sectoldif accepte trois types de schéma : • AIX : schéma AIX (classes d’objets aixaccount et aixaccessgroup) • RFC2307 : schéma RFC 2307 (classes d’objets posixaccount, shadowaccount et posixgroup) • RFC2307AIX : schéma RFC 2307 avec support AIX complet ( classes d’objets posixaccount, shadowaccount et posixgroup, plus les classes aixauxaccount et aixauxgroup) Pendant la configuration du serveur LDAP, la commande mksecldap appelle la commande sectoldif pour effectuer la migration des utilisateurs et des groupes. Il convient d’être particulièrement vigilant lors d’une migration d’utilisateurs et de groupes effectuée depuis d’autres systèmes vers le serveur LDAP en utilisant la sortie de sectoldif. En effet, les commandes ldapadd et db2ldif vérifient le nom des entrées lors d’un ajout (nom de l’utilisateur ou du groupe), mais pas leurs ID numériques. La migration d’utilisateurs et de groupes effectuée à partir de la sortie de sectoldif et pour plusieurs systèmes peut aboutir à plusieurs comptes dotés du même ID numérique, ce qui constitue une violation de sécurité. Exemples 1. Pour lister tous les utilisateurs et les groupes définis localement, tapez la commande suivante : sectoldif –d cn=aixsecdb,cn=aixdata –S rfc2307aix Cette commande envoie tous les utilisateurs et les groupes définis localement vers stdout, au format ldif. Les entrées utilisateurs et groupes sont représentées selon le schéma de type RFC2307AIX. Le DN de base est défini sur cn=aixsecdb, cn=aixdata. 2. Pour n’afficher qu’un seul utilisateur défini localement, ici foo, tapez : sectoldif –d cn=aixsecdb,cn=aixdata –u foo L’utilisateur foo défini localement est envoyé vers stdout, au format ldif. En l’absence de l’option –S, le schéma par défaut AIX est utilisé pour présenter la sortie ldif. Utilisation du protocole LDAP du sous–système de sécurité 4-13 Pour plus de détails sur la commande sectoldif, reportez–vous à sectoldif dans le manuel AIX 5L Version 5.2 Commands Reference. Le format de fichier ldap.cfg Le fichier /etc/security/ldap/ldap.cfg contient les informations nécessaires au démarrage et au bon fonctionnement du démon secldapclntd, ainsi que des informations permettant d’ajuster ses performances. Il est mis à jour par la commande mksecldap lors de la configuration du client. Les champs suivants peuvent apparaître dans le fichier /etc/security/ldap/ldap.cfg : 4-14 ldapservers Indique la liste des serveurs d’informations de sécurité LDAP (séparés par des virgules). Ces serveurs peuvent être soit des serveurs primaires, soit des serveurs primaires dupliqués. ldapadmin Indique le DN administrateur des serveurs d’informations de sécurité LDAP. ldapadmpwd Indique le mot de passe du DN administrateur. useSSL Indique s’il faut utiliser une communication SSL. Les valeurs possibles sont ON et OFF. La valeur par défaut est OFF. Remarque : Pour activer cette fonction, vous aurez besoin d’une clé SSL et de son mot de passe. ldapsslkeyf Indique le chemin complet de la clé SSL. ldapsslkeypwd Indique le mot de passe de la clé SSL. Remarque : Mettez cette ligne en commentaire pour utiliser le mot de passe sécurisé (stash password). Le fichier stash de mot de passe doit se trouver dans le même répertoire que celui de la clé SSL et porter le même nom, mais avec l’extension .sth au lieu de.kdb. userattrmappath Indique le chemin d’accès à la mappe d’attributs utilisateurs AIX LDAP. groupattrmappath Indique le chemin d’accès à la mappe d’attributs groupes AIX LDAP. idattrmappath Indique le chemin d’accès à la mappe d’attributs des ID AIX LDAP. Ces ID sont utilisés par la commande mkuser lors de la création des utilisateurs LDAP. userbasedn Définit le DN de base utilisateur. groupbasedn Définit le DN de base groupe. idbasedn Définit le DN de base des ID. hostbasedn Définit le DN de base de l’hôte. servicebasedn Indique le DN de base du service. protocolbasedn Définit le DN de base du protocole. networkbasedn Définit le DN de base du réseau. Guide de sécurité netgroupbasedn Définit le DN de base du groupe réseau. rpcbasedn Définit le DN de base RPC. userclasses Définit les classes d’objets utilisées pour les entrées utilisateurs. groupclasses Définit les classes d’objets utilisées pour les entrées groupes. ldapversion Définit la version du protocole du serveur LDAP. La valeur par défaut est 3. ldapport Définit le port sur lequel écoute le serveur LDAP. La valeur par défaut est 389. ldapsslport Définit le port SSL sur lequel écoute le serveur LDAP. La valeur par défaut est 636. followaliase Indique s’il faut suivre les alias. Les valeurs possibles sont NEVER, SEARCHING, FINDING et ALWAYS. La valeur par défaut est NEVER. usercachesize Précise la taille du cache utilisateur. Les valeurs vont de 100 à 10 000 entrées. La valeur par défaut est 1 000. groupcachesize Précise la taille du cache groupe. Les valeurs vont de 10 à 1 000 entrées. La valeur par défaut est 100. cachetimeout Indique la durée de vie (TTL) du cache. Les valeurs admises vont de 60 à 3 600 secondes. La valeur par défaut est 300. La valeur 0 désactive la mise en cache. heartbeatinterval Définit l’intervalle (en secondes) entre deux vérifications par le client du statut du serveur LDAP. Les valeurs admises vont de 60 à 3 600 secondes. La valeur par défaut est 300. numberofthread Définit le nombre d’unités d’exécution utilisés par le démon secldapclntd. Les valeurs admises vont de 1 à 1 000. La valeur par défaut est 10. Pour plus de détails sur le fichier /etc/security/ldap/ldap.cfg, reportez–vous à /etc/security/ldap/ldap.cfg dans le manuel AIX 5L Version 5.2 Files Reference. Utilisation du protocole LDAP du sous–système de sécurité 4-15 Format de fichier du mappage des attributs LDAP Ces fichiers de mappage sont utilisés par le module /usr/lib/security/LDAP et le démon secldapclntd pour convertir les noms des attributs AIX en noms d’attributs LDAP. Chaque entrée dans le fichier de mappage correspond à la traduction d’un attribut. Chaque entrée comporte quatre champs séparés par des espaces : AIX_Attribute_Name AIX_Attribute_Type LDAP_Attribute_Name LDAP_Value_Type AIX_Attribute_Name Indique le nom de l’attribut AIX. AIX_Attribute_Type Indique le type de l’attribut AIX. Les valeurs admises sont SEC_CHAR, SEC_INT, SEC_LIST et SEC_BOOL. LDAP_Attribute_Name Indique le nom de l’attribut LDAP. LDAP_Value_Type Indique le type de valeur LDAP. s indique une valeur unique et m des valeurs multiples. Pour plus de détails sur le format de fichier de mappage des attributs, reportez–vous à LDAP attribute mapping file format dans le manuel AIX 5L Version 5.2 Files Reference. Informations connexes Commandes mksecldap, start–secldapclntd, stop–secldapclntd, restart–secldapclntd, ls–secldapclntd, sectoldif et flush–secldapclntd. Démon secldapclntd. Fichier /etc/security/ldap/ldap.cfg. Format de fichier de mappage des attributs LDAP. 4-16 Guide de sécurité Chapitre 5. PKCS #11 Grâce au sous-système PKCS #11, les applications disposent d’un moyen d’accéder aux unités matérielles (jetons) qui est indépendant de ces unités. Le contenu de ce chapitre est conforme à la Version 2.01 de la norme PKCS #11. Ce sous-système a été implémenté à l’aide des composants suivants : • Un démon gestionnaire de connecteurs (pkcsslotd), qui fournit au sous-système des informations sur l’état des unités matérielles disponibles. Ce démon est démarré automatiquement lors de l’installation ou du redémarrage du système. • Un objet API partagé (/usr/lib/pkcs11/pkcs11_API.so) est fourni comme interface générique des cartes pour lesquelles PKCS #11 a été implémentée. • Une bibliothèque pour chaque carte, qui fournit le support PKCS #11 spécifique. Cette conception étagée permet à l’utilisateur d’utiliser de nouvelles unités PKCS #11 lorsqu’elles sont disponibles sans avoir à recompiler des applications existantes. Ce chapitre traite des points suivants : • Coprocesseur de chiffrement 4758 Model 2, page 5-1 • Configuration du sous-système PKCS #11, page 5-2 • Utilisation de PKCS #11, page 5-4 Coprocesseur de chiffrement 4758 Model 2 Le coprocesseur de chiffrement 4758 Model 2 sécurise l’environnement informatique. Avant de tenter de configurer le sous-système PKCS #11, vérifiez que la carte a été correctement configurée avec un microcode compatible. Vérification du coprocesseur de chiffrement 4758 Model 2 pour une utilisation avec le sous-système PKCS #11 Le sous-système PKCS #11 détecte automatiquement lors de l’installation et du redémarrage les cartes acceptant les appels PKCS #11. C’est pourquoi un coprocesseur de chiffrement 4758 Model 2 qui n’est pas correctement configuré ne sera pas accessible depuis l’interface PKCS #11 et les appels envoyés échoueront. Procédez comme suit pour vérifier si votre carte est correctement configurée : 1. Assurez-vous que le logiciel de la carte est correctement installé à l’aide de la commande suivante : lsdev –Cc adapter | grep crypt Si le coprocesseur de chiffrement IBM 4758 Model 2 ne s’affiche pas dans la liste des résultats, vérifiez que la carte est correctement insérée et que le logiciel de prise en charge est correctement installé. 2. Vérifiez que le firmware approprié a été chargé sur la carte à l’aide de l’utilitaire csufclu : csufclu /tmp/l ST device_number_minor Vérifiez que l’Image Segment 3 montre l’application PKCS #11 chargée. Si ce n’est pas le cas, consultez la documentation de la carte pour obtenir les dernières informations relatives au microcode et à l’installation. Remarque : Si cet utilitaire n’est pas disponible, il faudra installer le logiciel de prise en charge. PKCS #11 5-1 Configuration du sous-système PKCS #11 Le sous-système PKCS #11 détecte automatiquement les unités compatibles. Toutefois, pour utiliser ces unités, certaines applications ont besoin d’une configuration initiale. Ces tâches sont les suivantes : • Initialisation du jeton, page 5-2 • Configuration du PIN de l’agent de sécurité, page 5-2 • Initialisation du PIN utilisateur, page 5-3 Vous pouvez effectuer ces tâches via l’API (en écrivant une application PKCS #11) ou à l’aide de l’interface SMIT. Les options SMIT de PKCS #11 sont accessibles via le sous-système Gestion du PKCS11 depuis le menu principal SMIT, ou à l’aide du raccourci smit pkcs11. Initialisation du jeton Chaque carte ou jeton PKCS #11 doit être initialisé avant de pouvoir être utilisé. Cette procédure implique la définition d’un libellé unique pour le jeton. Ce libellé permet aux applications d’identifier le jeton par un numéro d’ordre unique. Par conséquent, les libellés ne doivent pas être répétés. Toutefois, l’API ne vérifie pas si les libellés sont réutilisés ou non. Cette initialisation peut se faire par une application PKCS #11, ou par l’administrateur du système avec l’interface SMIT. Si votre jeton dispose d’un PIN du responsable de sécurité, la valeur par défaut est 87654321. Pour garantir la sécurité du sous-système PKCS #11, cette valeur doit être modifiée après l’initialisation. Pour initialiser le jeton : 1. Affichez l’écran de gestion du jeton en tapant smit pkcs11. 2. Sélectionnez Initialiser un jeton. 3. Sélectionnez une carte PKCS #11 dans la liste de celles prises en charge. 4. Appuyez sur Entrée pour confirmer votre choix. Remarque : Cette action effacera toutes informations figurant sur le jeton. 5. Entrez le PIN du responsable de sécurité (SO PIN) et un libellé unique du jeton. Si le PIN correct est entré, la carte sera initialisée ou réinitialisée une fois l’exécution de la commande terminée. Configuration du PIN du responsable de sécurité Si votre jeton dispose d’un SO PIN, vous pouvez en modifier la valeur par défaut, comme suit : 1. Tapez smit pkcs11. 2. Sélectionnez Configurer le PIN du responsable de sécurité. 3. Sélectionnez la carte initialisée pour laquelle vous voulez configurer le SO PIN. 4. Entrez le SO PIN courant et un nouveau PIN. 5. Vérifiez le nouveau PIN. 5-2 Guide de sécurité Initialisation du PIN utilisateur Une fois le jeton initialisé, vous devrez peut–être configurer le PIN utilisateur pour permettre aux applications d’accéder aux objets du jeton. Consultez la documentation spécifique à votre unité pour déterminer si elle nécessite la connexion d’un utilisateur avant de pouvoir accéder aux objets. Pour initialiser le PIN utilisateur : 1. Affichez l’écran de gestion du jeton en tapant smit pkcs11. 2. Sélectionnez Initialiser le PIN utilisateur. 3. Sélectionnez une carte PKCS #11 dans la liste. 4. Entrez le SO PIN et le PIN utilisateur. 5. Vérifiez le PIN utilisateur. 6. Après vérification, le PIN utilisateur sera modifié. Reconfiguration du PIN utilisateur Pour reconfigurer le PIN utilisateur, vous pouvez réinitialiser le PIN à l’aide du SO PIN ou définir le PIN utilisateur à l’aide de celui existant. Pour ce faire : 1. Affichez l’écran de gestion du jeton en tapant smit pkcs11. 2. Sélectionnez Définir le PIN utilisateur. 3. Sélectionnez la carte initialisée pour laquelle vous voulez configurer le PIN utilisateur. 4. Entrez le PIN utilisateur courant et un nouveau PIN. 5. Vérifiez le nouveau PIN utilisateur. Configuration du vecteur de contrôle des fonctions PKCS #11 Votre jeton n’assurera peut–être pas le chiffrement avancé sans charger un vecteur de contrôle des fonctions. Veuillez consulter la documentation de votre unité pour déterminer si votre jeton a besoin d’un vecteur de contrôle des fonctions et où le placer. Si un vecteur de contrôle des fonctions est nécessaire, vous devez posséder un fichier de clés. Pour charger le vecteur de contrôle des fonctions : 1. Affichez l’écran de gestion du jeton en tapant smit pkcs11. 2. Sélectionnez Configurer le vecteur de contrôle des fonctions. 3. Sélectionnez le connecteur PKCS #11 du jeton. 4. Entrez le chemin menant au fichier du vecteur de contrôle des fonctions. PKCS #11 5-3 Utilisation de PKCS #11 Pour qu’une application puisse utiliser le sous-système PKCS #11, le démon gestionnaire d’emplacements du sous- doit être actif, et l’application doit charger l’objet d’API partagé. Le gestionnaire d’emplacements est généralement lancé au démarrage par inittab, avec le script /etc/rc.pkcs11. Ce script vérifie les cartes du système avant de lancer le démon de gestionnaire d’emplacements. Par conséquent, ce démon n’est pas disponible avant que l’utilisateur ne soit connecté au système. Une fois le démon lancé, le sous-système intègre toutes les modifications apportées au nombre et aux types de cartes prises en charge, sans aucune intervention de l’administrateur système. L’API peut être chargée en faisant un link de l’objet au moment de l’exécution ou en utilisant une résolution différée de symboles. Par exemple, une application peut obtenir la liste des fonctions PKCS #11 de la manière suivante : d CK_RV (*pf_init)(); void *d; CK_FUNCTION_LIST *functs; d = dlopen(e, RTLD_NOW); if ( d == NULL ) { return FALSE; } pfoo = (CK_RV (*)())dlsym(d, ”C_GetFunctionList”); if (pfoo == NULL) { return FALSE; } rc = pf_init(&functs); 5-4 Guide de sécurité Chapitre 6. Service d’authentification de certificats X.509 et infrastructure à clef publique Le Service d’authentification des certificats permet au système d’exploitation AIX 5.2 d’authentifier les utilisateurs à l’aide de certificats X.509 d’infrastructure à clef publique (PKI, Public Key Infrastructure), et d’associer ces certificats à des processus pour confirmer l’identité d’un utilisateur. Pour ce faire, il utilise LAMF (Loadable Authentication Module Framework), le même mécanisme d’extension AIX utilisé pour les méthodes d’authentification DCE, Kerberos et autres. Cette section traite des points suivants : • Présentation du service d’authentification de certificats, page 6-1 • Mise en œuvre du service d’authentification de certificats, page 6-3 • Planification du service d’authentification de certificats, page 6-14 • Modules du service d’authentification de certificats, page 6-17 • Installation et configuration du service d’authentification de certificats, page 6-18 Présentation du service d’authentification de certificats Chaque compte utilisateur participant à une authentification PKI possède un certificat PKI unique. En association avec un mot de passe, ce certificat authentifie l’utilisateur lors de sa connexion. Les certificats PKI reposent sur le système de clef publique/clef privée. Ce système utilise deux clefs non symétriques pour chiffrer et déchiffrer les données. Les données chiffrées à l’aide d’une clef ne peuvent être déchiffrées qu’avec l’autre clef. L’utilisateur conserve la clef privée et l’enregistre dans un magasin de clefs privé, et publie l’autre clef, la clef publique, sous la forme d’un certificat. Les certificats sont généralement conservés sur un serveur LDAP (Lightweight Directory Access Protocol), soit pour une utilisation interne à l’entreprise, soit sur Internet pour une utilisation dans le monde entier. Pour que John puisse envoyer des données déchiffrables uniquement par Kathy, le certificat publié pour Kathy fournira à John la clef publique nécessaire pour chiffrer les données, qui pourront alors être envoyées à Kathy. Kathy déchiffrera les données envoyées par John à l’aide de sa clef privée, conservée dans son magasin de clefs privé. Ce système est également utilisé pour les signatures numériques. Pour envoyer à John des données validées par sa signature numérique, Kathy devra utiliser sa clef privée. John utilisera la clef publique contenue dans le certificat publié de Kathy pour vérifier la signature numérique attachée aux données. Dans les deux cas, la clef privée de Kathy est conservée dans un magasin de clefs privé. Il existe divers types de magasin de clefs privés, par exemple des fichiers ou des smart cards, mais tous protègent toutes les clefs privées au moyen de mots de passe ou de numéros PIN (Personal Identification Numbers). Ils assurent généralement le stockage de plusieurs clefs privées ainsi que de certificats et d’objets PKI. Les utilisateurs disposent habituellement de leurs propres magasins de clefs. Le service d’authentification de certificats utilise les signatures numériques pour authentifier un utilisateur lors de la connexion. Il repère le magasin de clefs et le certificat de l’utilisateur en fonction de son nom de compte, utilise le mot de passe de l’utilisateur pour trouver dans le magasin la clef privée correspondant au certificat, signe les données avec cette clef privée, et utilise la clef publique de l’utilisateur contenu dans le certificat pour vérifier la signature. Une fois l’utilisateur authentifié, le système enregistre le certificat en mémoire Service d’authentification de certificats X.509 et infrastructure à clef publique 6-1 protégée et l’associe à chaque processus créé par l’utilisateur. Cette association en mémoire permet l’accès rapide au certificat de l’utilisateur pour tous les processus qu’il possède, ainsi que pour ceux détenus par le noyau du système d’exploitation. Certificats Pour comprendre le service d’authentification des certificats, vous devez posséder quelques connaissances sur les certificats, leurs formats et la gestion de leur cycle de vie. Les certificats sont des objets standardisés conformes à la norme X.509, dont X.509v3 est la toute dernière version. Les certificats sont créés, signés et émis par une autorité de certification (CA), la plupart du temps un logiciel qui accepte et traite les demandes de certificats. Il existe plusieurs attributs de certificats. Certains d’entre eux sont obligatoires, d’autres sont facultatifs. Voici les attributs de certificats les plus couramment utilisés et traités dans ce document : • Version des certificats – Le numéro de version X.509 (1, 2 ou 3). • Numéro de série – Un numéro unique, qui différencie un certificat parmi tous ceux qui ont été émis par la même autorité de certification. • Nom de l’émetteur – Le nom de l’autorité de certification qui a émis le certificat. • Période de validité – La date d’activation et d’expiration du certificat. • Clef publique – La clef publique. • Utilisateur DN – Nom du propriétaire du certificat. • E–mail du nom d’utilisateur supplémentaire – Adresse e–mail du propriétaire. • URI du nom d’utilisateur supplémentaire – L’URI/URL du site Web du propriétaire. Chaque certificat possède un numéro de version, qui indique à quelle version de la norme X.509 il est conforme. Chaque certificat possède un numéro de série unique qui le différencie de tous les autres certificats émis par la même autorité de certification. Le numéro de série n’est unique que pour l’autorité de certification émettrice. Le nom d’émetteur du certificat identifie l’autorité de certification émettrice. Les certificats ne sont valides qu’entre deux dates spécifiées : la date “ Pas avant ” et la date “ Pas après ”. Les certificats peuvent donc être créés avant leur date de début de validité. La durée de vie d’un certificat est en moyenne de 3 mois à 5 ans. L’utilisateur DN indique le propriétaire du certificat, dans un format de dénomination spécial, le Nom spécifique (Distinguished Name, DN). Un DN peut indiquer le pays, l’entreprise, la ville, l’état, le nom du propriétaire et d’autres attributs associés au demandeur (généralement une personne, mais pas seulement). L’e–mail du nom d’utilisateur supplémentaire indique l’adresse e–mail du propriétaire, et l’URI du nom d’utilisateur supplémentaire permet d’indiquer l’URI/URL du site Web du propriétaire. Autorités de certification et certificats Les autorités de certification émettent, enregistrent et généralement publient les certificats. La publication des certificats se fait souvent sur un serveur LDAP, puisque LDAP offre à tous un accès facile aux données d’une communauté. Les autorités de certification assurent également la révocation des certificats et la gestion des listes de révocation de certificats (CRL). La révocation d’un certificat consiste à publier le fait qu’il n’est plus valide, pour des raisons autres que l’expiration de sa période de validité. Comme de nombreuses ces copies des certificats peuvent être conservées et utilisées indépendamment du contrôle de l’autorité de certification émettrice, les autorités de certification publient une liste des certificats révoqués dans une CRL, de sorte que des entités extérieures puisse interroger la liste. Il est alors de leur responsabilité de s’assurer que le certificat est valide, en comparant la copie du certificat à la CRL de l’autorité de certification émettrice. Une autorité de certification ne peut révoquer que des certificats qu’elle crée ou émet. Elle ne peut pas révoquer des certificats émis par d’autres autorités de certification. 6-2 Guide de sécurité Voici quelques raisons administratives justifiant la révocation d’un certificat : • Sécurité compromise de la clef privée du certificat. • Le propriétaire du certificat a quitté l’entreprise. • Sécurité compromise de l’autorité de certification. Les autorités de certification disposent également de leur propre certificat d’identification. Elles peuvent ainsi s’identifier entre elles, par exemple dans une communication pair à pair (chaînes de sécurité, etc.). De nombreuses autorités de certification utilisent le CMP (Certificate Management Protocol) pour demander et révoquer des certificats. Ce protocole dispose de plusieurs méthodes pour établir une connexion sécurisée entre un client (également appelé Entité de fin) et l’autorité de certification, mais tous les clients et autorités n’acceptent pas toutes les méthodes. L’une des méthodes courantes nécessite l’utilisation d’un numéro de référence et d’un mot de passe reconnus par l’autorité de certification pour chaque création de certificat ou demande de révocation. D’autres informations telles qu’un certificat spécial reconnu par l’autorité de certification peuvent également être requises. Les demandes de révocation peuvent nécessiter la clef privée associée au certificat à révoquer. Même si le CMP permet de créer des certificats et d’effectuer des demandes de révocation, il ne prend pas en charge les requêtes CRL. Les CRL sont généralement accessibles via des méthodes hors bande. Les CRL sont fréquemment publiées sur des serveurs LDAP, ce qui permet aux applications de les y récupérer pour les examiner. Une autre nouvelle méthode est le protocole OCSP (Online Certification Status Protocol), mais il n’est pas encore accepté par toutes les autorités de certification. Les autorités de certification sont généralement contrôlées par des organisations gouvernementales ou des entreprises privées de confiance qui visent à assurer la correspondance entre le certificat émis et la personne qui a demandé l’émission. L’expression émission d’un certificat implique la création d’un certificat, elle diffère donc d’une demande de copie d’un certificat publié. Format de stockage des certificats Le format de stockage le plus courant est ASN.1 (Abstract Syntax Notation version 1) ; il utilise les DER (Distinguished Encoding Rules). Il est donc appelé format DER. Magasins de clefs Un magasin de clefs (parfois appelé ensemble de clefs) contient les clefs privées d’un utilisateur correspondant aux clefs publiques de leurs certificats. Un libellé unique est attribué à chaque clef privée, généralement par l’utilisateur, pour faciliter l’identification. Les magasins de clefs sont protégés par un mot de passe, qui doit être saisi avant de pouvoir accéder aux clefs ou en ajouter. Les utilisateurs possèdent généralement leurs propres magasins de clefs. Il existe plusieurs formes de magasins de clefs, par exemple : smart cards, magasin sous LDAP, magasin sur fichier, etc. Les méthodes utilisées pour y accéder varient également, ainsi que les formats utilisés pour enregistrer les clefs privées. Le service d’authentification des certificats n’accepte que les magasins de clefs sur fichier. Mise en œuvre du service d’authentification de certificats Le service d’authentification de certificats fonctionne dans un modèle client/serveur. Le côté serveur consiste en une autorité de certification (CA) pour créer et conserver des certificats X.509 version 3 et des listes de révocation de certificats (CRL). (une seule autorité de certification est généralement utilisée pour l’ensemble de l’organisation.) Le côté client contient le logiciel (commandes, bibliothèques, modules de chargement et fichiers de configuration) requis par chaque système participant à une authentification PKI. Les modules d’installation du serveur sont cas.server, ceux du client sont cas.client. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-3 Création de comptes utilisateur PKI Pour créer un compte utilisateur PKI, utilisez la commande AIX mkuser. Une fois créé, chaque compte dispose d’un certificat et d’un magasin de clefs privé. (vous pouvez également transformer des comptes existants en comptes PKI, mais des étapes supplémentaires sont nécessaires.) L’administrateur fournit à chaque nouvel utilisateur le mot de passe du magasin de clefs, afin qu’il puisse se connecter au système et modifier le mot de passe de son magasin de clefs. Flux de données d’authentification utilisateur Cette section décrit comment authentifier un utilisateur PKI. Les utilisateurs peuvent associer plusieurs certificats à leurs comptes. Une valeur d’indicateur unique définie par l’utilisateur facilite l’identification de chaque certificat, mais il n’est possible de spécifier qu’un seul certificat d’authentification. Le service d’authentification de certificats utilise l’attribut auth_cert pour connaître le certificat d’authentification de chaque utilisateur. La valeur de l’attribut auth_cert correspond à la valeur de l’indicateur du certificat. Les certificats, indicateurs, emplacements de magasin de clefs correspondants, libellés de clef correspondants et autres informations connexes sont conservés sous LDAP pour chaque utilisateur. La combinaison de l’indicateur et du nom de l’utilisateur permet au service d’authentification de certificats de trouver le certificat sur le serveur LDAP. Pour plus d’informations sur la couche LDAP PKI, consultez Couche LDAP PKI (stockage des certificats), page 6-7. Lors de la connexion, les utilisateurs donnent un nom d’utilisateur et un mot de passe. A partir du nom, le système récupère l’attribut auth_cert de l’utilisateur, puis l’indicateur du certificat d’authentification. En associant le nom d’utilisateur et l’indicateur, le système récupère sur le serveur LDAP le certificat, l’emplacement du magasin de clefs et le libellé de clef correspondant de l’utilisateur. Il vérifie la période de validité indiquée dans le certificat pour déterminer s’il a expiré ou n’a pas encore atteint sa date d’activation. Le système extrait ensuite la clef privée de l’utilisateur à l’aide de l’emplacement du magasin de clefs, du libellé de clef et du mot de passe fourni. Une fois la clef privée récupérée, le système vérifie que la clef privée et le certificat correspondent à l’aide d’un processus de signature interne. Si c’est le cas, l’utilisateur a réussi l’étape d’authentification PKI de la procédure de connexion. (ce qui ne signifie pas qu’il est connecté. Plusieurs autres vérifications sont effectuées par le système AIX sur un compte utilisateur avant d’autoriser l’accès au système.) Pour utiliser un certificat comme certificat d’authentification, vous devez le signer à l’aide d’une clef de signature sécurisée. La signature est enregistrée sous LDAP avec le certificat, pour référence ultérieure. Cette mise en œuvre exige qu’un certificat possède une signature avant de pouvoir attribuer l’indicateur à auth_cert. Le processus d’authentification ne compare pas un certificat à une CRL. Cela s’explique par des raisons de performance (il faut du temps pour obtenir et examiner les CRL qui peuvent être temporairement indisponibles), mais également par les délais de publication des CRL (les autorités de certification peuvent nécessiter une heure ou plus pour indiquer la révocation d’un certificat révoqué dans une CRL, ce qui fait de la révocation de certificats une alternative limitée à la désactivation d’un compte utilisateur). Noter également que l’authentification ne nécessite pas d’autorité de certification. La majorité du travail est effectuée en local par le service d’authentification de certificats, à l’exception de l’extraction des données enregistrées sur le serveur LDAP. Implémentation du serveur Le côté serveur du service d’authentification de certificats implémente une autorité de certification écrite en Java, et contient une autorité d’inscription (Registration Authority, RA) ainsi que des fonctionnalités d’auto–audit. Il publie des certificats et des CRL qu’il crée sur un serveur LDAP. Vous pouvez configurer cette autorité de certification via un ensemble de fichiers de configuration (fichiers de propriété Java). Il contient l’application administrative runpki, dont les sous-commandes permettent entre autres de démarrer et d’arrêter le 6-4 Guide de sécurité serveur, et il prend également en charge le CMP pour créer et révoquer des certificats. L’autorité de certification a besoin de Java 1.3.1, de DB2 7.1 et de Directory 4.1. En raison des exigences de DB2, l’autorité de certification doit fonctionner sous un compte utilisateur différent de l’utilisateur root. Les commandes serveur suivantes permettent d’installer et de gérer le composant cas.server : mksecpki Utilisée lors de l’installation pour configurer les composants du serveur PKI AIX. Entre autres tâches, elle crée un compte utilisateur pour l’autorité de certification. runpki Permet à l’administrateur système de démarrer le serveur. Si les démons JavaPKI sont en cours de fonctionnement, ils doivent tout d’abord être arrêtés. La commande runpki lance le démon en arrière-plan à l’aide de la combinaison des indicateurs lb. Si les démons doivent être démarrés en mode interactif, l’administrateur peut modifier la commande runpki et utiliser l’indicateur l au lieu des indicateurs lb. runpki doit être lancée après l’exécution d’une opération su – sur le compte utilisateur sous lequel l’autorité de certification est en cours de fonctionnement. La commande est située dans le répertoire javapki sous le répertoire principal du compte utilisateur de l’autorité de certification. (la commande mksecpki crée le compte utilisateur de l’autorité de certification.) Par exemple, si le compte utilisateur de l’autorité de certification est pkiinst, entrez les commandes suivantes avec les droits root : 1. su – pkiinst 2. cd javapki 3. runpki Implémentation du client Le côté client du service d’authentification de certificats implémente les fonctions d’authentification, d’administration et de gestion des certificats de l’utilisateur. Une fois installé et configuré sur un système, le service d’authentification de certificats s’intègre aux fonctions existantes d’administration et d’authentification de l’utilisateur (comme les commandes mkuser, chuser, passwd et login) à l’aide du LAMF AIX (Loadable Authentication Module Framework). Il apporte également plusieurs commandes, bibliothèques et fichiers de configuration pour aider à gérer les magasins de clefs et les certificats de l’utilisateur. Le service d’authentification de certificats peut être utilisé en association avec la base de données LDAP AIX ou bien la base de données composée de fichiers pour enregistrer des attributs AIX standard. Le service d’authentification de certificats utilise toujours un serveur LDAP pour conserver les certificats utilisateur, même en cas d’utilisation d’une base de données composée de fichiers. Pour connaître les limitations d’utilisation d’une base de données composée de fichiers, consultez Planification du service d’authentification de certificats, page 6-14. Le côté client du service d’authentification de certificats contient le logiciel le plus orienté utilisateur. Pour cette raison, les sections suivantes décrivent comment le service d’authentification de certificats conserve et utilise les données nécessaires à l’authentification PKI. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-5 Fonctionnalités générales du client La liste suivante décrit certaines des fonctionnalités générales du service d’authentification de certificats : • Authentification utilisateur via les certificats PKI • Commandes permettant de gérer les magasins de clefs et les certificats de l’utilisateur • Prise en charge de plusieurs certificats par utilisateur • Prise en charge simultané de plusieurs autorités de certification • Intégration aux commandes existantes d’administration et authentification AIX (par exemple, login, passwd, mkuser) • Génération de certificats au moment de la création de l’utilisateur ou ajout de certificats après la création de l’utilisateur • Travaille avec une base de données utilisateur LDAP ou la base de données utilisateur sur fichiers standard AIX • Algorithmes et tailles de clef configurables • Association de certificats avec les PAG (Process Authentication Groups). Architecture générale du client L’architecture client du service d’authentification de certificats utilise une approche en couches et comprend les composants suivants : • Démon Java, page 6-6 • Couche de gestion du service, page 6-6 • Couche LDAP PKI (stockage des certificats), page 6-7 • La bibliothèque libpki.a, page 6-7 • Couche LAMF (Loadable Authentication Module Framework), page 6-8 • Commandes du client, page 6-8 • Commandes Pag (Process Authentication Group), page 6-9 • Commandes d’administration de l’utilisateur, page 6-9 • Fichiers de configuration, page 6-10 Démon Java Le côté client s’appuie sur un démon Java utilisant le logiciel de sécurité JCE. Ce démon gère les magasins de clefs utilisateur, crée des paires de clef, effectue les communications CMP et propose toutes les fonctions de hachage et de chiffrement. Les API des modules PKI de prestataires de service n’étant pas standardisées pour les applications C, une API appelée Couche de gestion de service (Service Management Layer, SML) propose aux démons et programmes une interface normalisée. Couche de gestion de service (SML) Le service SML du démon Java s’appelle /usr/lib/security/pki/JSML.sml. SML assure la création de certificats, ainsi que la création et la gestion de magasins de clefs, mais ne gère pas le stockage des certificats, lequel est assuré par le couche LDAP PKI. Stockage de clef privée via SML Le démon Java utilise les fichiers du magasin de clefs au format PKCS#12 pour stocker les clefs des utilisateurs. Ces magasins sont protégés par un seul mot de passe, utilisé pour chiffrer toutes les clefs du magasin. L’emplacement d’un magasin de clefs est indiqué comme une URI. Par défaut, le service d’authentification de certificats conserve les fichiers du magasin de clefs dans le répertoire /var/pki/security/keys. 6-6 Guide de sécurité Les magasins de clefs et leurs fichiers sont généralement limités en taille. La Couche SML fournit l’API permettant de gérer les magasins de clefs. Le service d’authentification de certificats ne gère que les magasins de clefs sur fichiers. Il n’accepte ni les smart cards ni les magasins de clefs LDAP. Vous pouvez accepter des visiteurs en plaçant les magasins de clefs sur fichiers dans un système de fichiers partagé, sur le même point de montage pour tous les systèmes. Couche LDAP PKI (stockage de certificats) Le service d’authentification de certificats stocke les certificats et autres informations relatives dans LDAP via la Couche LDAP PKI, pour chaque utilisateur. Ce service conserve les associations de certificats sur un serveur LDAP, pour chaque utilisateur. Plusieurs certificats peuvent être associés à un même compte utilisateur. Chaque association possède un indicateur unique spécifié par l’utilisateur pour faciliter l’identification et la recherche. Le service d’authentification de certificats utilise la combinaison du nom de l’utilisateur et de l’indicateur pour repérer l’association de certificats d’un utilisateur dans LDAP. Pour optimiser les performances et l’espace disque, le service d’authentification de certificats peut sauvegarder la totalité du certificat sous LDAP ou simplement une référence URI de ce certificat. Si vous utilisez une référence URI au lieu d’un certificat, le service d’authentification de certificats demande à la référence de fournir le certificat concerné. Les références sont le plus souvent utilisées en association avec une autorité de certification qui publie ses certificats sur un serveur LDAP. Les types de référence URI couramment acceptées par le service d’authentification de certificats sont des références LDAP. Le service d’authentification de certificats stocke les certificats au format DER et demande aux références URI de se reporter aux certificats au format DER. Le service d’authentification conserve également le type et l’emplacement du magasin de clefs et libellé de clef de chaque certificat, dans le même enregistrement que celui de l’association de certificats sur le serveur LDAP. Les utilisateurs peuvent ainsi disposer de plusieurs magasins de clefs, et le service d’authentification de certificats peut détecter plus rapidement la clef privée associée à un certificat. Pour gérer des visiteurs, il faut qu’un magasin de clefs se trouve au même endroit sur tous les systèmes. Le service d’authentification de certificats gère l’attribut auth_cert dans LDAP pour chaque utilisateur. Cet attribut spécifie l’indicateur du certificat utilisé pour l’authentification. Toutes les informations LDAP peuvent être consultées par les utilisateurs, à l’exception de l’attribut auth_cert qui est limité au compte LDAP ldappkiadmin. Puisque l’utilisateur root a accès au mot de passe LDAP ldappkiadmin via le fichier acct.cfg, les applications fonctionnant avec l’UID de root peuvent accéder à l’attribut auth_cert. (ceci s’applique à l’accès à l’URI de référence, pas aux données référencées par la valeur de cette URI. En général, ces données sont publiques.) L’API assurant le gestion du stockage des certificats figure dans la bibliothèque libpki.a. La bibliothèque libpki.a Outre sa fonction de centralisation des API SML et de Couche LDAP PKI, le bibliothèque libpki.a héberge plusieurs sous-routines. Les API contenues dans la bibliothèque ont les actions suivantes : • Gestion des nouveaux fichiers de configuration • Accès aux attributs spécifiques des certificats • Association de plusieurs fonctions de couche basse en fonctions de niveau supérieur • Sont communes aux services SML Remarque : Les API ne sont pas publiées. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-7 Couche LAMF (Loadable Authentication Module Framework) Outre les API SML et LDAP PKI, la couche LAMF (Loadable Authentication Module Framework) figure dans la bibliothèque. LAMF fournit des applications d’administration utilisateur et d’authentification AIX avec les API correspondantes, indépendamment du mécanisme sous-jacent (par exemple, Kerberos, LDAP, DCE, fichiers). LAMF utilise les API SML et LDAP PKI pour implémenter l’authentification PKI. Pour ce faire, il utilise des modules de chargement qui mappent l’API du LAMF vers différentes technologies d’authentification/base de données. Les commandes telles que login, telnet, passwd, mkuser et bien d’autres utilisent l’API du LAMF pour implémenter leurs fonctions ; par conséquent, elles acceptent automatiquement de nouvelles technologies d’authentification et de base de données dès l’ajout des nouveaux modules de chargement correspondants. Le service d’authentification de certificats ajoute au système un nouveau module de chargement LAMF appelé /usr/lib/security/PKI. Ce module doit être ajouté par l’administrateur système dans le fichier /usr/lib/security/methods.cfg, avant d’utiliser PKI pour l’authentification. Il doit également être associé à un type de base de données (par exemple, LDAP) dans le fichier methods.cfg avant de pouvoir être utilisé pour l’authentification. Vous trouverez un exemple du fichier methods.cfg contenant le module LAMF et la définition de la base de données à la section Le fichier methods.cfg, page 6-29. Une fois les définitions ajoutées à methods.cfg, l’administrateur peut configurer les attributs utilisateur registry et SYSTEM (définis dans le fichier /etc/security/user) sur la ou les nouvelles valeurs de strophe pour l’authentification PKI. Commandes du client Les commandes sont situées au–dessus de toutes les couches d’API (LAMF, LDAP PKI et SML). Outre les commandes AIX standard d’authentification et d’administration utilisateur pour le service d’authentification de certificats (via LAMF), il existe plusieurs commandes spécifiques à ce service. Ces commandes aident l’utilisateur à gérer les certificats et les magasins de clefs. Vous trouverez ci-dessous une liste de ces commandes accompagnée d’une brève description. certadd Ajoute un certificat au compte utilisateur dans LDAP et vérifie si le certificat est révoqué. certcreate Crée un certificat. certdelete Supprime un certificat du compte de l’utilisateur (i.e., de LDAP). certget Extrait un certificat du compte de l’utilisateur (i.e., de LDAP). certlink Ajoute dans LDAP un lien vers un certificat existant dans un référentiel distant du compte de l’utilisateur, et vérifie si le certificat est révoqué. certlist Affiche la liste des certificats associés au compte de l’utilisateur figurant dans LDAP. certrevoke Révoque un certificat. certverify Vérifie que la clef privée correspond au certificat et effectue une signature sécurisée. keyadd Ajoute un objet à un magasin de clefs. keydelete Supprime un objet d’un magasin de clefs. keylist Affiche la liste des objets d’un magasin de clefs. keypasswd Modifie le mot de passe d’un magasin de clefs. Pour de plus amples informations sur ces commandes, consultez le manuel AIX 5L Version 5.2 Commands Reference. 6-8 Guide de sécurité Commandes PAG (Process Authentication Group) Les commandes PAG (Process Authentication Group) sont nouvelles dans AIX. Les commandes PAG sont des éléments de données qui associent des données d’authentification utilisateur à des processus. Pour le service d’authentification de certificats, si le mécanisme PAG est activé, le certificat d’authentification de l’utilisateur est associé à son shell de connexion. Le PAG se propage à chaque processus fils créé par le shell. Pour pouvoir proposer cette fonctionnalité, le PAG nécessite l’activation du démon /usr/sbin/certdaemon. Par défaut, ce mécanisme n’est pas activé. Son activation n’est pas nécessaire au service d’authentification de certificats, mais ce dernier l’utilise s’il est activé. Pour activer le démon certdaemon, ajoutez la ligne suivante au fichier /etc/inittab : certdaemon:2:wait:/usr/sbin/certdaemon Vous trouverez ci-dessous une liste des commandes PAG accompagnée d’une brève description : paginit Authentifie un utilisateur et crée une association PAG. paglist Affiche une liste des informations d’authentification associées au processus courant. pagdel Supprime les associations PAG existantes dans les références du processus courant. Pour de plus amples informations sur ces commandes, consultez le manuel AIX 5L Version 5.2 Commands Reference. Commandes d’administration utilisateur Comme pour l’authentification utilisateur, le service d’authentification de certificats s’intègre aux fonctions AIX d’administration utilisateur via le LAMF AIX. Les commandes telles que chuser, lsuser, mkuser et passwd utilisent l’API du LAMF. Par conséquent, elles acceptent automatiquement de nouvelles technologies d’authentification et de base de données dès l’ajout au système de nouveaux modules de chargement. Les sous-sections suivantes décrivent plus en détail la façon dont l’authentification PKI affecte les commandes d’administration utilisateur. Les commandes suivantes sont concernées par le processus d’authentification PKI : chuser Permet à l’administrateur de modifier l’attribut utilisateur auth_cert. Cet attribut spécifie la valeur de l’indicateur du certificat utilisé pour l’authentification. Pour pouvoir utiliser le certificat comme certificat d’authentification, vous devez le signer à l’aide de la clef de signature sécurisée. (les attributs de certificat, les attributs de stockage de certificat et les attributs de magasin de clefs ne sont pas accessibles via cette commande.) lsuser Affiche la valeur de l’attribut auth_cert de l’utilisateur, ainsi que les attributs de certificats répertoriés ci-dessous. L’attribut auth_cert indique la valeur de l’indicateur du certificat utilisé pour l’authentification. (les autres attributs de certificat, attributs de stockage de certificat et attributs de magasin de clefs ne sont pas accessibles via cette commande.) Les attributs de certificat répertoriés par la commande lsuser sont les suivants : subject–DN Le nom spécifique de l’utilisateur. subject–alt–name L’e–mail du nom supplémentaire de l’utilisateur. valid–after La date à laquelle le certificat de l’utilisateur devient valide. valid–until La date à laquelle le certificat de l’utilisateur n’est plus valide. issuer Le nom spécifique de l’émetteur. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-9 mkuser Génère un certificat au moment de la création de l’utilisateur. Un administrateur peut utiliser mkuser pour générer un certificat lors de la création d’utilisateurs ne possédant pas encore de certificat d’authentification. Eventuellement, si un utilisateur possède déjà un certificat d’authentification, mais pas de compte utilisateur, l’administrateur peut créer le compte sans générer de certificat et l’ajouter (ainsi que le magasin de clefs) ultérieurement. La valeur par défaut de cette option est indiquée par l’attribut cert de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. Plusieurs valeurs par défaut sont nécessaires lors de la génération automatique d’un certificat d’authentification pour un utilisateur à l’aide la commande mkuser. La plupart sont indiquées dans la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. La strophe newuser assure un contrôle administratif de ces valeurs par défaut. Voici quelques-unes de ces valeurs par défaut : . CA . Valeur de l’attribut auth_cert . Emplacement du magasin de clefs . Mot de passe du magasin de clefs . Libellé de clef privée . Nom de domaine du champ E–mail du nom d’utilisateur supplémentaire Il existe une différence entre créer un compte utilisateur PKI ou non–PKI. Pour créer un compte utilisateur PKI, il vous faut un mot de passe pour chiffrer la clef privée, si la commande mkuser génère un certificat d’authentification pour ce compte. Mais la commande mkuser n’étant pas interactive, elle obtient donc le mot de passe du fichier policy.cfg et l’utilise comme mot de passe du magasin de clefs (le mot de passe de la clef privée) ; vous pouvez donc accéder au compte immédiatement après sa création. Lorsque vous créez un compte utilisateur non–PKI, la commande mkuser configure le mot de passe sur une valeur non valide, ce qui empêche l’accès. passwd Cette commande modifie le mot de passe du magasin de clefs de l’utilisateur lorsqu’il est utilisé sur un compte utilisateur PKI. Elle oblige à utiliser les règles de restriction du mot de passe indiquées dans le fichier /etc/security/user, l’attribut des indicateurs figurant dans le fichier /etc/security/passwd ainsi que toutes les règles requises par le prestataire de service PKI. Les magasins de clefs sur fichiers chiffrant leurs clefs privées à l’aide du mot de passe de l’utilisateur, l’utilisateur root ne peut pas réinitialiser le mot de passe d’un magasin de clefs sur fichiers s’il ne connaît pas le mot de passe courant du magasin. En cas d’oubli du mot de passe par un utilisateur, l’utilisateur root ne pourra pas le réinitialiser sauf si root le connaît. Si le mot de passe est inconnu, il faudra probablement créer un nouveau magasin de clefs et de nouveaux certificats pour l’utilisateur. Fichiers de configuration Le service d’authentification de certificats utilise des fichiers de configuration pour configurer le côté client : acct.cfg, ca.cfg et policy.cfg. L’interface SMIT gère ces fichiers de configuration. Vous trouverez dans les sections suivantes des informations sur les fichiers de configuration. 6-10 Guide de sécurité Le fichier acct.cfg Le fichier acct.cfg contient des strophes CA et LDAP. Les strophes CA contiennent des informations confidentielles ne devant pas figurer dans le fichier ca.cfg accessible au public, comme par exemple, des mots de passe et des numéros de référence du CMP. Les strophes LDAP contiennent des informations LDAP confidentielles interdites au public, comme par exemple, des mots de passe et des noms administratifs LDAP PKI. Pour chaque strophe CA du fichier ca.cfg, le fichier acct.cfg doit contenir une strophe CA de nom identique, chaque nom de strophe CA doit être unique. Les strophes LDAP sont toutes appelées ldap, ce qui explique pourquoi une strophe CA ne peut pas s’appeler ldap. De même, aucune strophe ne peut s’appeler default. Il doit y avoir une strophe LDAP, et également au moins une strophe CA appelée local. Les strophes CA contiennent les attributs suivants : capasswd Indique le mot de passe CMP de CA. La longueur du mot de passe est définie par la CA. carefnum Indique le numéro de référence CMP de la CA. keylabel Indique le libellé de la clef privée dans le magasin de clefs sécurisé utilisé pour signer les demandes de certificats. keypasswd Indique le mot de passe du magasin de clefs sécurisé. rvpasswd Indique le mot de passe de révocation utilisé pour le CMP. La longueur du mot de passe est définie par la CA rvrefnum Indique le numéro de référence de la révocation utilisé pour le CMP. La strophe LDAP contient les attributs suivants : ldappkiadmin Indique le nom de compte du serveur LDAP affiché dans la liste ldapservers. ldappkiadmpwd Indique le mot de passe du compte du serveur LDAP. ldapservers Indique le nom du serveur LDAP. ldapsuffix Indique les attributs DN ajoutés au certificat DN d’un utilisateur par la commande mkuser. Voici un exemple de fichier acct.cfg : local: carefnum = 12345678 capasswd = password1234 rvrefnum = 9478371 rvpasswd = password4321 keylabel = ”Trusted Key” keypasswd = joshua ldap: ldappkiadmin = ”cn=admin” ldappkiadmpwd = secret ldapservers = ”ldap.server.austin.ibm.com” ldapsuffix = ”ou=aix,cn=us” Pour de plus amples informations, consultez le manuel AIX 5L Version 5.2 Files Reference. Le fichier ca.cfg Le fichier ca.cfg est constitué de strophes CA. Elles contiennent des informations CA publiques utilisées par le service d’authentification de certificats pour générer des demandes de certificats et des demandes de révocation de certificats. Pour chaque strophe CA du fichier ca.cfg, le fichier acct.cfg doit contenir une strophe CA du même nom. Chaque nom de strophe CA figurant dans le fichier ca.cfg doit être unique. Il doit y avoir au moins une strophe appelée local. Il ne doit y avoir aucune strophe appelée ldap ou default. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-11 Les strophes CA contiennent les attributs suivants : algorithm Indique l’algorithme de clef publique (par exemple, RSA). crl Indique l’URI de la CRL pour la CA. dn Indique le DN de base utilisé lors de la création des certificats. keysize Indique la taille de clef minimale en bits. program Indique le nom de fichier du module de service PKI. retries Indique le nombre de tentatives de contact avec la CA. server Indique l’URI de la CA. signinghash Indique l’algorithme de hachage utilisé pour signer les certificats (par exemple, MD5). trustedkey Indique le magasin de clefs sécurisé contenant la clef de signature sécurisée utilisée pour signer les certificats d’authentification. url Indique la valeur par défaut de l’URI du nom d’utilisateur supplémentaire. La strophe CA par défaut est appelée local. Voici un exemple de fichier ca.cfg : local: program = /usr/lib/security/pki/JSML.sml trustedkey = file:/usr/lib/security/pki/trusted.p15 server = ”cmp://9.53.230.186:1077” crl = ”ldap://dracula.austin.ibm.com/o=aix,c=us” dn = ”o=aix,c=us” url = ”http://www.ibm.com/” algorithm = RSA keysize = 512 retries = 5 signinghash = MD5 Pour de plus amples informations, consultez le manuel AIX 5L Version 5.2 Files Reference. Le fichier policy.cfg Le fichier policy.cfg est composé de quatre strophes : newuser, storage, crl et comm. Ces strophes modifient le comportement de certaines commandes d’administration du système. La commande mkuser utilise la strophe newuser. La commande certlink utilise la strophe storage. Les commandes certadd et certlink utilisent les strophes comm et crl. La strophe newuser contient les attributs suivants : 6-12 ca Indique la CA utilisée par la commande mkuser lors de la génération d’un certificat. cert Indique si la commande mkuser va par défaut générer un nouveau (new) certificat ou non (get). domain Indique la partie domaine de la valeur E–mail du nom d’utilisateur supplémentaire du certificat utilisée par la commande mkuser lors de la génération d’un certificat. keysize Indique la taille minimale en bits de la clef de chiffrement utilisée par la commande mkuser lors de la génération d’un certificat. keystore Indique l’URI du magasin de clefs utilisée par la commande mkuser lors de la génération d’un certificat. keyusage Indique la valeur d’usage de la clef du certificat utilisée par la commande mkuser lors de la génération d’un certificat. label Indique le libellé de la clef privée utilisée par la commande mkuser lors de la génération d’un certificat. Guide de sécurité passwd Indique le mot de passe du magasin de clefs utilisé par la commande mkuser lors de la génération d’un certificat. subalturi Indique la valeur de l’URI du nom d’utilisateur supplémentaire utilisée par la commande mkuser lors de la génération d’un certificat. tag Indique la valeur de l’indicateur auth_cert utilisée par la commande mkuser lors de la création d’un utilisateur si cert = new. validity Indique la valeur de la période de validité du certificat utilisée par la commande mkuser lors de la génération d’un certificat. version Indique le numéro de version du certificat à créer. La valeur 3 est la seule valeur prise en charge. La strophe storage contient les attributs suivants : replicate Indique si la commande certlink sauvegarde une copie du certificat (yes) ou simplement le lien (no). La strophe crl contient l’attribut check, qui indique si les commandes certadd et certlink doivent vérifier la CRL (yes) ou non (no). La strophe comm contient l’attribut timeout qui indique le délai d’attente en secondes utilisé par certadd et certlink lors d’une demande d’informations sur un certificat à l’aide du protocole HTTP (par exemple, extraction de CRL). Voici un exemple de fichier policy.cfg : newuser: cert = new ca = local passwd = pki version = ”3” keysize = 512 keystore = ”file:/var/pki/security/keys” validity = 86400 storage: replicate = no crl: check = yes comm: timeout = 10 Pour de plus amples informations, consultez le manuel AIX 5L Version 5.2 Files Reference. Evénements du journal d’audit Le client du service d’authentification de certificats génère les événements du journal d’audit suivants : • CERT_Create • CERT_Add • CERT_Link • CERT_Delete • CERT_Get • CERT_List • CERT_Revoke • CERT_Verify • KEY_Password • KEY_List Service d’authentification de certificats X.509 et infrastructure à clef publique 6-13 • KEY_Add • KEY_Delete Evénements de trace Le client du service d’authentification de certificats génère plusieurs nouveaux événements de trace, dans la plage 3B7 – 3B8. Planification du service d’authentification de certificats Le Service d’authentification des certificats est disponible à partir d’AIX 5.2. Les configurations logicielles minimales requises sont un serveur DB2, un serveur Directory et un serveur de service d’authentification de certificats. Vous pouvez les installer sur un seul système ou sur plusieurs. Chaque entreprise doit choisir l’environnement qui lui convient le mieux. Cette section présente des informations sur la planification du service d’authentification de certificats, notamment : • Remarques sur les certificats, page 6-14 • Remarques sur les magasins de clefs, page 6-14 • Remarques sur le registre des utilisateurs, page 6-15 • Remarques sur la configuration, page 6-15 • Remarques sur la sécurité, page 6-15 • Autres remarques sur le service d’authentification de certificats, page 6-16 Remarques sur les certificats Le service d’authentification de certificats gère les certificats X.509 version 3. Il accepte également plusieurs attributs de certificat de la version 3, mais pas tous. Pour connaître la liste des attributs de certificats pris en charge, reportez-vous à la commande certcreate et au fichier ca.cfg. Le service d’authentification de certificats gère une partie de l’ensemble de caractères Teletex. Il n’accepte que le Teletex 7 bits (sous-ensemble ASCII). Remarques sur les magasins de clefs Le service d’authentification des certificats gère les fichiers de magasin de clefs. Les types de magasins de clefs smart cards, LDAP et autres ne sont pas pris en charge. Par défaut, les magasins de clefs utilisateur sont conservés dans le système de fichiers local sous le répertoire /var/pki/security/keys. Les magasins de clefs étant en local sur le système, ils ne sont pas accessibles aux autres systèmes ; par conséquent, l’authentification utilisateur sera limitée au système sur lequel figure le magasin de clefs de l’utilisateur. Pour gérer des visiteurs, vous pouvez copier le magasin de clefs de l’utilisateur vers le même emplacement local et avec le même nom de magasin de clefs sur les autres systèmes, ou bien placer les magasins de clefs sur un système de fichiers distribué. Remarque : 6-14 Guide de sécurité Vous devez faire attention à ce que les droits d’accès au magasin de clefs de l’utilisateur ne soient pas modifiés. (dans AIX, chaque certificat sur LDAP contient le chemin d’accès vers le magasin de clefs privé contenant la clef privée du certificat. Le magasin de clefs doit figurer à l’endroit du chemin d’accès indiqué dans LDAP pour pouvoir servir à l’authentification.) Remarques sur le registre des utilisateurs Le service d’authentification des certificats utilise un registre LDAP des utilisateurs. LDAP est également le type de registre utilisateur conseillé pour une utilisation avec le service d’authentification de certificats. Le service d’authentification des certificats gère également un registre des utilisateurs sur fichier. L’administrateur doit imposer certaines restrictions pour que la PKI sur fichiers puisse fonctionner. Les comptes utilisateur possédant le même nom sur différents systèmes participant à l’authentification PKI doivent faire référence au même compte. Par exemple, l’utilisateur Bob sur le système A et l’utilisateur Bob sur le système B doivent faire référence au même utilisateur Bob. Cela s’explique du fait que le service d’authentification de certificats utilise LDAP pour stocker les informations sur les certificats pour chaque utilisateur. Le nom d’utilisateur est utilisé comme clef d’indexation pour accéder à ces informations. Les registres sur fichier étant en local sur chaque système et LDAP commun à tous les systèmes, les noms d’utilisateur sur tous les systèmes participant à l’authentification PKI doivent correspondre aux noms d’utilisateur uniques dans l’espace de nom LDAP. Si l’utilisateur Bob du système A est différent de l’utilisateur Bob du système B, soit un seul des utilisateurs Bob peut participer à l’authentification PKI, ou bien chaque compte Bob doit utiliser un serveur/espace de nom LDAP différent. Remarques sur la configuration Pour simplifier la configuration, vous pourrez conserver les trois fichiers de configuration (acct.cfg, ca.cfg et policy.cfg) sur un système de fichiers distribué à l’aide de liens symboliques, pour ne pas avoir à les modifier sur chaque système. Conservez les paramètres de contrôle d’accès appropriés sur ces fichiers. C’est une situation qui peut diminuer votre sécurité, car les informations contenues par ces fichiers vont circuler sur le réseau. Remarques sur la sécurité Le fichier acct.cfg Le fichier acct.cfg contient les numéros de référence et les mots de passe de chaque CA (consultez les descriptions des attributs carefnum, capasswd, rvrefnum et rvpasswd pour acct.cfg). Ces valeurs sont utilisées uniquement pour les communications CMP avec la CA lors de la création ou de la révocation d’un certificat. En cas de sécurité compromise, l’individu à l’origine de cette situation pourrait créer ou révoquer des certificats comme bon lui semble. Pour limiter ce risque, vous ne devez appliquer la restriction de création ou de révocation de certificats qu’à un petit nombre de systèmes. Les valeurs des attributs carefnum et capasswd ne sont requises que sur les systèmes sur lesquels les certificats sont créés (via les commandes certcreate ou mkuser). Ce qui peut imposer de limiter de la création de compte utilisateur au même ensemble de systèmes. Remarque : La commande mkuser peut être configurée pour créer automatiquement un certificat lors de la création d’un utilisateur ou bien créer un compte sans lui associer de certificat, auquel cas l’administrateur devra créer et ajouter ce certificat ultérieurement. De même, les valeurs des attributs rvrefnum et rvpasswd ne sont requises que sur les systèmes sur lesquels les certificats doivent être révoqués (via la commande certrevoke). Le fichier acct.cfg contient également des informations sur chacune des clefs de signature sécurisée (consultez les descriptions des attributs keylabel et keypasswd pour le fichier acct.cfg). Ces valeurs sont utilisées uniquement dans le cadre d’opérations spéciales de vérification des certificats. En cas de sécurité compromise, l’individu à l’origine de cette situation pourrait créer des certificats vérifiés. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-15 Pour limiter ce risque, vous ne devez accorder la vérification de certificats qu’à un petit nombre de systèmes. Les valeurs des attributs keylabel et keypasswd du fichier acct.cfg ainsi que la valeur de l’attribut trustedkey du fichier ca.cfg ne sont requises que sur les systèmes sur lesquels la vérification de certificats est nécessaire. Autrement dit, sur les systèmes sur lesquels les commandes mkuser (avec la fonction de création automatique de certificats activée) et certverify sont nécessaires. Nouveaux comptes actifs Lorsque vous créez un compte utilisateur PKI, si l’attribut cert de la strophe newuser contenue dans le fichier policy.cfg est défini sur new, la commande mkuser crée un compte PKI actif ainsi qu’un mot de passe et un certificat. Le mot de passe de ce compte est indiqué par l’attribut passwd dans la strophe newuser. Les magasins de clefs exigent en effet un mot de passe pour stocker les clefs privées. Cette méthode est différente des autres types de création de compte utilisateur pour lesquels l’administrateur doit d’abord créer le compte, puis définir le mot de passe avant de pouvoir activer le compte. L’utilisateur root et les mots de passe des magasins de clefs Contrairement à d’autres types de compte pour lesquels l’utilisateur root peut modifier le mot de passe d’un compte sans le connaître, les comptes PKI ne le permettent pas. En effet, les mots de passe des comptes servent à chiffrer les magasins de clefs et ils sont nécessaires pour pouvoir les déchiffrer. Si les utilisateurs oublient leurs mots de passe, vous devez émettre de nouveaux certificats et créer de nouveaux magasins de clefs. Autres remarques sur le service d’authentification de certificats Voici quelques remarques à prendre en compte lors de la planification du service d’authentification de certificats : • Le service d’authentification de certificats contient sa propre autorité de certification (CA). Il ne prend pas en charge d’autres autorités de certification. • Plus la taille de la clef est importante, plus il faut de temps pour générer des paires de clefs et chiffrer les données. Le chiffrement matériel n’est pas pris en charge. • Le service d’authentification de certificats utilise Directory for LDAP. Il ne gère pas d’autres implémentations LDAP. • Le service d’authentification de certificats utilise DB2 comme base de données. Il n’accepte pas d’autres bases de données. • Le service d’authentification de certificats impose que toutes les commandes, bibliothèques et démons soient dans un environnement Unicode. 6-16 Guide de sécurité Modules du service d’authentification de certificats Tableau 9. Modules du service d’authentification de certificats Nom du module Ensemble de fichiers Contenu Dépendances cas.server cas.server.rte Autorité de certification (AC) • AIX 5.2 Installation Manuelle • Java131 (livré avec les supports de base AIX) • Extensions de sécurité Java131 (livré avec Expansion Pack) • Serveur Directory (LDAP) • DB2 7.1 cas.client cas.client.rte Manuelle • Commandes Cert • Module de chargement d’authentificati on PKI • libpki.a • Module SML • Fichiers de configuration • Démon Java • AIX 5.2 • Java131 (livré avec les supports de base AIX) • Extensions de sécurité Java131 (livré avec Expansion Pack) • Client Directory (LDAP) • PAG (implicite) cas.msg cas.msg.[lang].cli Catalogues de ent messages cas.client Manuelle bos bos.security.rte Non applicable Installé avec le noyau Démon et commandes PAG Le module cas.server contient la CA et s’installe dans les répertoires /usr/cas/server et /usr/cas/client. Une entreprise n’utilise généralement qu’une seule CA, et par ailleurs, ce module est installé manuellement. Ce module exige l’installation préalable du serveur Directory, db2_07_01.client, Java131.rte et Java131.ext.security. Le module Java131.rte est installé par défaut lorsque le système d’exploitation AIX 5.2 est installé, mais les autres modules sont installés manuellement. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-17 Pour que le module db2_07_01.client fonctionne, le module db2_07_01.server doit être installé sur un système du réseau. Le module cas.client contient les fichiers requis pour tous les systèmes clients prenant en charge le service d’authentification de certificats. Sans ce module, un système ne peut pas participer à l’authentification PKI AIX. Installation et configuration du service d’authentification de certificats L’installation du service d’authentification de certificats consiste à exécuter les procédures suivantes : • Installation et configuration du serveur LDAP, page 6-18 • Installation et configuration du serveur pour le service d’authentification de certificats, page 6-21 • Configuration LDAP du serveur pour le service d’authentification de certificats, page 6-22 • Configuration du client pour le service d’authentification de certificats, page 6-24 • Exemples de configuration de l’administration, page 6-29 Installation et configuration du serveur LDAP Les scénarios possible pour l’installation et la configuration de LDAP pour les données des certificats de l’utilisateur PKI sont les suivants. 1. Si le serveur LDAP n’est pas installé, exécutez les procédures suivantes : a. Installation du serveur LDAP, page 6-18 b. Configuration du serveur LDAP, page 6-19 c. Configuration du serveur LDAP pour PKI, page 6-20 2. Si le serveur LDAP est installé et configuré, mais pas pour PKI, effectuez la Configuration du serveur LDAP pour PKI, page 6-20. Installation du serveur LDAP Vous trouverez des instructions détaillées relatives à l’installation du serveur Directory dans la documentation du produit contenue dans l’ensemble de fichiers ldap.html.en_US.config. Une fois l’ensemble de fichiers ldap.html.en_US.config installé, vous pouvez afficher la documentation à l’aide d’un navigateur Web à l’URL suivante : file:/usr/ldap/web/C/getting_started.htm. La procédure d’installation du serveur LDAP est la suivante : 1. Connectez-vous en tant qu’utilisateur root. 2. Insérez le volume 1 des CD du système d’exploitation de base d’AIX dans le lecteur de CD–ROM. 3. Entrez smitty install_latest sur la ligne de commandes et appuyez sur Entrée 4. Sélectionnez Installer logiciels 5. Sélectionnez l’unité ou le répertoire contenant le logiciel serveur Directory puis appuyez sur Entrée. 6. Utilisez la touche F4 pour afficher la liste des modules dans la zone Logiciels à installer. 7. Sélectionnez le module ldap.server puis appuyez sur Entrée. 6-18 Guide de sécurité 8. Vérifiez que l’option Installation AUTOMATIQUE des logiciels dépendants est définie sur YES, puis appuyez sur Entrée. Cette option installera les ensembles de fichiers du client et du serveur LDAP ainsi que les ensembles de fichiers de la base de données DB2. Les ensembles de fichiers installés sont les suivants : – ldap.client.adt (SDK du client Directory) – ldap.client.dmt (DMT du client Directory) – ldap.client.java (Java du client Directory) – ldap.client.rte (Environnement d’exécution du client Directory) – ldap.server.rte (Environnement d’exécution du serveur Directory) – ldap.server.admin (Serveur Directory) – ldap.server.cfg (Configuration du serveur Directory) – ldap.server.com (Cadre du serveur Directory) – db2_07_01.* (Environnement d’exécution DB2 et ensembles de fichiers associés) Le module DB2, db2_07_01.jdbc, doit également être installé. Le module DB2 db2_07_01.jdbc se trouve sur le CD Expansion Pack. Utilisez la procédure d’installation affichée dans la liste ci-dessus pour installer le module db2_07_01.jdbc. Configuration du serveur LDAP Une fois les ensembles de fichiers LDAP et DB2 installés, vous devez configurer le serveur LDAP. Même si vous pouvez effectuer la configuration via la ligne de commandes et l’édition de fichiers, il est conseillé d’utiliser l’administrateur web LDAP. Cet outil nécessite un serveur web. Le serveur web Apache se trouve sur le CD AIX Toolbox for LINUX Applications. Utilisez l’interface SMIT ou la commande geninstall pour installer le serveur web Apache. Vous pouvez également utiliser d’autres serveurs web, consultez la documentation LDAP pour plus de détails. Vous trouverez des instructions détaillées relatives à la configuration LDAP dans la documentation HTML du produit. Voici une description succincte des étapes de configuration : 1. Utilisez ldapcfg pour définir le mot de passe et le DN de l’administrateur pour la base de données LDAP. L’administrateur est l’utilisateur root de la base de données LDAP. Pour configurer un DN administrateur de cn=admin avec le mot de passe secret, entrez : # ldapcfg –u cn=admin –p secret Le mot de passe et le DN vous seront demandés ultérieurement lors de la configuration de chaque client. Le DN et le mot de passe seront utilisés comme attributs ldappkiadmin et ldappkiadmpwd pour une strophe ldap dans le ficher acct.cfg. 2. Configurez l’outil de l’administrateur web en utilisant l’emplacement du fichier de configuration du serveur web : # ldapcfg –s apache –f /etc/apache/httpd.conf 3. Redémarrez le serveur web. Pour le serveur Apache, utilisez la commande : # /usr/local/bin/apachectl restart 4. Accédez à l’administrateur web à l’aide de l’URL http:// hostname/ldap. Connectez-vous ensuite à l’aide du mot de passe et du DN de l’administrateur LDAP configurés à l’étape 2. 5. A l’aide de l’outil de l’administrateur web, suivez les directives pour configurer la base de données DB2 et redémarrez le serveur LDAP. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-19 Configuration du serveur LDAP pour PKI Le service d’authentification de certificats exige deux arborescences distinctes du répertoire LDAP. L’une est utilisée par l’autorité de certification pour publier des certificats et des CRL. L’autre est utilisée par les clients pour stocker et extraire des données PKI pour chaque utilisateur. Les étapes suivantes configurent l’arborescence du répertoire LDAP utilisée pour le stockage et l’extraction des données PKI de chaque utilisateur. 1. Ajout d’une entrée de suffixe pour la configuration LDAP. Le suffixe par défaut des données PKI est cn=aixdata. Il place les données du certificat PKI en-dessous du suffixe par défaut de toutes les données AIX. Le répertoire root par défaut pour les données PKI est ou=pkidata,cn=aixdata. Toutes les données PKI sont placées à cet endroit. – Suffixe des données PKI cn=aixdata Suffixe commun pour toutes les données AIX. Il existe peut–être déjà si le serveur LDAP est utilisé pour d’autres données AIX. Vous pouvez ajouter l’entrée de configuration du suffixe via l’outil de l’administrateur web, ou en éditant directement le fichier de configuration du serveur LDAP. Pour ajouter l’entrée de configuration du suffixe à l’aide de l’administrateur Web, procédez comme suit : a. Sélectionnez Paramètres dans le menu de gauche. b. Sélectionnez Suffixes. c. Entrez le suffixe nécessaire pour les données PKI, puis cliquez sur le bouton Mettre à jour. d. Une fois le suffixe ajouté, redémarrez le serveur LDAP. Pour ajouter l’entrée de configuration du suffixe en éditant le fichier de configuration du serveur LDAP, procédez comme suit : a. Dans le fichier /usr/ldap/etc/slapd32.conf, repérez la ligne contenant ibm–slapdSuffix: cn=localhost Il s’agit du suffixe système par défaut. b. Ajoutez l’entrée ibm–slapdSuffix nécessaire pour les données PKI. Par exemple, vous pouvez ajouter une entrée de suffixe comme celle qui suit : ibm–slapdSuffix: cn=aixdata c. Sauvegardez les modifications apportées au fichier de configuration. d. Redémarrez le serveur LDAP. 2. Ajout des Entrées suffixe, répertoire Root et base de données ACL pour les données PKI. Le répertoire root des données est le point dans la structure du répertoire LDAP sous lequel se trouvent toutes les données PKI. L’ACL est la Liste de contrôle d’accès du répertoire Root des données qui définit les règles d’accès pour toutes les données PKI. Le fichier pkiconfig.ldif fourni permet d’ajouter les entrées suffix, root et ACL à la base de données. Ajoutez tout d’abord les entrées suffixe et base de données root, ainsi que le mot de passe de l’administrateur des données PKI. La première partie du fichier ajoute les entrées suffixe par défaut à la base de données et définit le mot de passe : 6-20 Guide de sécurité dn: cn=aixdata objectclass: top objectclass: container cn: aixdata dn: ou=pkidata,cn=aixdata objectclass: organizationalUnit ou: cert userPassword: <<password>> Modifiez le fichier pkiconfig.ldif et remplacez la chaîne <<password>> après l’attribut userPassword par le mot de passe pour votre administrateur de données PKI. Les valeurs de DN et de userPassword seront requises ultérieurement lors de la configuration de chaque client. Le DN ( ou=pkidata,cn=aixdata ) et la valeur du password seront utilisés pour les attributs ldappkiadmin et ldappkiadmpwd dans une strophe ldap du fichier acct.cfg. Le seconde partie du fichier modifie le propriétaire et ajoute l’ACL des données PKI : dn: ou=pkidata,cn=aixdata changetype: modify add: entryOwner entryOwner: access–id:ou=pkidata,cn=aixdata ownerPropagate: true dn: ou=pkidata,cn=aixdata changetype: modify add: aclEntry aclEntry: group:cn=anybody:normal:grant:rsc:normal:deny:w aclEntry: group:cn=anybody:sensitive:grant:rsc:sensitive:deny:w aclEntry: group:cn=anybody:critical:grant:rsc:critical:deny:w aclEntry: group:cn=anybody:object:deny:ad aclPropagate: true Remarque : N’effectuez AUCUNE modification sur les paramètres de l’ACL. Cela pourrait effectivement compromettre l’intégrité de votre implémentation PKI. Vous pouvez modifier le fichier pkiconfig.ldif pour utiliser un suffixe autre que celui par défaut, ce qui n’est toutefois conseillé qu’aux administrateurs LDAP expérimentés. Vous pouvez alors appliquer le fichier ldif à la base de données à l’aide de la commande ldapadd suivante. Remplacez les valeurs des options –D et –w par le mot de passe et le DN de votre administrateur LDAP local, comme suit : # ldapadd –c –D cn=admin –w secret –f pkiconfig.ldif 3. Redémarrage du serveur LDAP. Redémarrez le serveur LDAP à l’aide de l’outil de l’administrateur web, ou en utilisant la commande kill et en redémarrant le processus slapd. Installation et configuration du serveur pour le service d’authentification de certificats Pour installer et configurer le service d’authentification de certificats, procédez comme suit : 1. Installez les ensembles de fichiers de sécurité Java (Java131.ext.security.*) à partir du CD Expansion Pack. Les modules requis sont les suivants : – Java131.ext.security.cmp–us (Gestion des certificats Java) – Java131.ext.security.jce–us (Extension du chiffrement Java) – Java131.ext.security.jsse–us (Extension de socket Java sécurisée) – Java131.ext.security.pkcs–us (Chiffrement à clef publique Java) 2. Déplacez le fichier ibmjcaprovider.jar dans un autre répertoire que /usr/java131/jre/lib/ext. Ce fichier est incompatible avec les ensembles de fichier de Service d’authentification de certificats X.509 et infrastructure à clef publique 6-21 sécurité Java et doit être déplacé pour que le service d’authentification de certificats puisse fonctionner correctement. 3. Installez l’ensemble de fichiers du serveur pour le service d’authentification de certificats (cas.server.rte) à partir du CD Expansion Pack. Configuration LDAP du serveur pour le service d’authentification de certificats Pour configurer le serveur du service d’authentification de certificats de sorte qu’il travaille avec LDAP, effectuez les étapes suivantes : 1. Si vous ne l’avez pas déjà installé, installez le module client Directory sur le système prenant en charge le module cas.server. 2. Si vous ne l’avez pas déjà configuré, configurez le client Directory client comme suit : # ldapcfg –l /home/ldapdb2 –u ”cn=admin” –p secret –s apache \ –f /usr/local/apache/conf/httpd.conf La commande de configuration ci-dessus considère que le serveur Web est le serveur Apache. 3. Ajoutez le suffixe suivant au fichier slapd.conf : ibm–slapdSuffix: o=aix,c=us Vous pouvez indiquer un nom spécifique différent à la place de o=aix,c=us. 4. Exécutez la commande slapd : # /usr/bin/slapd –f /etc/slapd32.conf 5. Ajoutez les classes d’objet, comme suit : # ldapmodify –D cn=admin –w secret –f setup.ldif où setup.ldif contient les éléments suivants : dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.5.6.21 NAME ’pkiuser’ DESC ’auxiliary class for non–CA certificate owners’ SUP top AUXILIARY MAY userCertificate ) dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.5.6.22 NAME ’pkiCA’ DESC ’class for Cartification Authorities’ SUP top AUXILIARY MAY ( authorityRevocationList $ caCertificate $ certificateRevocationList $ crossCertificatePair ) ) dn:cn=schema changetype: modify replace: attributetypes attributetypes: ( 2.5.4.39 NAME ( ’certificateRevocationList’ ’certificateRevocationList;binary’ ) DESC ’ ’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE–VALUE ) replace:ibmattributetypes ibmattributetypes:( 2.5.4.39 DBNAME ( ’certRevocationLst’ ’certRevocationLst’ ) ACCESS–CLASS NORMAL) 6. Ajoutez les entrées : # ldapadd –D cn=admin –w secret –f addentries.ldif où addentries.ldif contient les éléments suivants : 6-22 Guide de sécurité dn: o=aix,c=us changetype: add objectclass: organization objectclass: top objectclass: pkiCA o: aix Remarque : Les modèles de fichiers addentries.ldif et setup.ldif sont fournis dans le module cas.server. 7. Arrêtez puis démarrez le démon slapd. Création d’une autorité de certification Créez l’autorité de certification comme suit : 1. Créez un fichier de référence. Le fichier de référence contient une ou plusieurs paires de mots de passe et de numéros de référence pour la création de certificat. Chaque paire indique les informations d’authentification acceptées par le serveur du service d’authentification de certificats lorsqu’un client de ce service tente de s’authentifier auprès du serveur lors de la création d’un certificat (généralement à l’aide du protocole CMP). Le format du fichier est un numéro de référence suivi d’un mot de passe, tous deux sur des lignes distinctes. Par exemple : 12345678 password1234 87654321 password4321 où 12345678 et 87654321 sont les numéros de référence, et password1234 et password4321 sont leurs mots de passe respectifs. Les lignes vides ne sont pas autorisées. Les caractères espace ne doivent pas précéder ou suivre des mots de passe ou des numéros de référence. Le fichier doit contenir au moins un mot de passe et un numéro de référence. Vous trouverez un exemple de fichier dans /usr/cas/server/iafile. Il vous faudra faire référence à ces valeurs à chaque configuration de client. 2. Configurez l’autorité de certification à l’aide de la commande mksecpki comme suit : # mksecpki –u pkiuser –f /usr/cas/server/iafile –p 1077 –H ldap.cert.mydomain.com \ –D cn=admin –w secret –i o=aix,c=us Vous trouverez ci-dessous des informations sur les indicateurs mksecpki : –u Indique un nom de compte utilisateur sur lequel le serveur du service d’authentification de certificats sera installé. –f Indique le fichier de référence créé dans l’étape précédente. –p Indique un numéro de port pour le serveur LDAP. –H Indique le nom d’hôte ou l’adresse IP du serveur LDAP. –D Indique le nom commun de l’administrateur LDAP. –w Indique le mot de passe de l’administration LDAP. –i Indique la branche LDAP sur laquelle se trouve les données des certificats utilisateur. La commande mksecpki génère automatiquement la clef de signature sécurisée avec le libellé de clef TrustedKey, le mot de passe du compte utilisateur de l’autorité de certification, et la place dans le fichier de magasin de clefs /usr/lib/security/pki/trusted.pkcs12. Vous n’avez pas besoin d’exécuter les étapes de Création de la clef de signature sécurisée, page 6-24, à moins d’avoir à générer plusieurs clefs ou de vouloir une clef de signature sécurisée avec un libellé de clef et/ou un mot de passe différent. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-23 Création de la clef de signature sécurisée La commande mksecpki génère automatiquement une clef de signature sécurisée avec le libellé de clef de TrustedKey, le mot de passe du compte utilisateur de l’autorité de certification, et la place dans le fichier de magasin de clefs /usr/lib/security/pki/trusted.pkcs12. Si vous devez générer une ou plusieurs nouvelles clefs de signature sécurisée, vous trouverez dans cette section les étapes adéquates pour une telle opération. Tous les clients du service d’authentification de certificats sur lesquels la création ou la révocation de certificats sont autorisées exigent une clef de signature sécurisée pour signer le certificat d’authentification de l’utilisateur. La clef est sauvegardée dans un magasin de clefs distinct et accessible à tous les systèmes sur lesquels des certificats peuvent être créés. Tous les systèmes peuvent utiliser une clef unique ou, pour une approche plus sécurisée, vous pouvez créer et distribuer plusieurs clefs. Pour créer une clef sécurisée, utilisez la commande /usr/java131/bin/keytool. Utilisez un nom de fichier non utilisé. La commande keytool vous invite à entrer le mot de passe d’une clef ou d’un magasin de clefs. Ces deux mots de passe peuvent être identiques pour permettre au service d’authentification de certificats d’accéder à la clef dans le magasin. Exécutez la commande keytool comme suit : keytool –genkey –dname ‘cn=trusted key’ –alias ‘TrustedKey’ –keyalg RSA \ filename .pkcs12 –storetype pkcs12ks –keystore Dans cet exemple, le libellé de clef sécurisée est TrustedKey et le mot de passe du magasin de clefs sécurisé est fourni par l’utilisateur. Notez bien ces valeurs car vous en aurez besoin lors de la configuration des clients du service d’authentification de certificats. Lorsque vous configurez un client de service d’authentification de certificats, les attributs keylabel et keypasswd du fichier acct.cfg devront être respectivement définis sur le libellé de clef sécurisé et le mot de passe du magasin de clefs sécurisé. Pour des raisons de sécurité, assurez-vous que le fichier du magasin de clefs (filename.pkcs12 ) est protégé en lecture et en écriture. Seul l’utilisateur root doit avoir accès à ce fichier. La clef sécurisée doit être le seul objet du magasin de clefs. Configuration du client du service d’authentification de certificats Il existe de nombreuses options de configuration sur le client du service d’authentification de certificats. Les sections suivantes proposent la procédure de configuration requise pour chaque système participant à l’authentification PKI. Installation de la clef de signature sécurisée Copiez le magasin de clefs sécurisé contenant la clef de signature sécurisée sur le système local. Pour plus d’informations sur la création de la clef de signature sécurisée, consultez Création de la clef de signature sécurisée, page 6-24. L’emplacement par défaut du magasin de clefs sécurisé est dans le répertoire /usr/lib/security/pki. Pour des raisons de sécurité, assurez-vous que le fichier du magasin de clefs est protégé en lecture et en écriture. Seul l’utilisateur root doit avoir accès à ce fichier. Edition du fichier acct.cfg Supprimez toutes les strophes ldap pouvant exister dans le fichier /usr/lib/security/pki/acct.cfg à l’aide d’un éditeur de texte comme vi. 6-24 Guide de sécurité Configuration de l’autorité de certification Le compte de l’autorité de certification locale doit au moins être configuré. Par défaut, il existe mais vous devez le modifier pour qu’il corresponde à votre environnement. Le service d’authentification de certificats peut utiliser plusieurs autorités de certification pour un seul système via les fichiers de configuration en strophes. local, le nom par défaut de la strophe de l’autorité de certification, est utilisé lorsqu’une autorité de certification n’est pas spécifiée par l’utilisateur ou le logiciel. Tous les systèmes doivent disposer d’une telle strophe local valide, dans les fichiers de configuration appropriés du service d’authentification de certificats. Une seule autorité de certification peut disposer du nom de strophe local. Toutes les autres autorités de certification doivent posséder un nom de strophe unique. Les noms de strophe de l’autorité de certification ne peuvent pas être ldap ou default. Les sections suivantes vous guident dans les écrans de configuration de l’outil SMIT pour configurer l’autorité de certification locale. Modification / Affichage d’une autorité de certification 1. Lancez l’outil SMIT PKI, comme suit : smitty pki 2. Sélectionnez Modification / Affichage d’une autorité de certification. 3. Tapez local pour Nom de l’autorité de certification puis appuyez sur entrée. 4. Configurez la zone Nom du module de service sur /usr/lib/security/pki/JSML.sml. Il s’agit de la valeur par défaut du module de chargement SML. Cette zone mappe vers l’attribut program du fichier /usr/lib/security/pki/ca.cfg. 5. Ignorez la zone Chemin d’accès du certificat de l’autorité de certification. Cette zone mappe vers l’attribut certfile du fichier /usr/lib/security/pki/ca.cfg. 6. Configurez la zone Chemin d’accès à la clef sécurisée de l’autorité de certification sur une URI correspondant à l’emplacement du magasin de clefs sécurisé sur le système local. Seuls les magasins de clefs sur fichiers sont pris en charge. L’emplacement habituel du magasin de clefs sécurisé est le répertoire /usr/lib/security/pki. (Consultez Installation de la clef de signature sécurisée, page 6-24.) Cette zone mappe vers l’attribut trustedkey du fichier /usr/lib/security/pki/ca.cfg. 7. Configurez la zone URI du serveur de l’autorité de certification sur une URI correspondant à l’emplacement de l’autorité de certification (cmp://myserver:1077). Cette zone mappe vers l’attribut server du fichier /usr/lib/security/pki/ca.cfg. 8. Ignorez la zone Point de distribution du certificat. Cette zone mappe vers l’attribut cdp du fichier /usr/lib/security/pki/ca.cfg. 9. Configurez la zone URI de la liste de révocation des certificats (CRL). Cette zone indique l’URI, et doit être définie sur l’emplacement de la liste de révocation des certificats de cette autorité de certification. Il s’agit généralement d’une URI LDAP, par exemple : ldap://crlserver/o= XYZ ,c= us Cette zone mappe vers l’attribut crl du fichier /usr/lib/security/pki/ca.cfg. 10.La zone Nom spécifique du certificat par défaut indique le DN de base utilisé lors de la création de certificats (par exemple, o= XYZ,c= us ). Cette zone n’est pas obligatoire. Cette zone mappe vers l’attribut dn du fichier /usr/lib/security/pki/ca.cfg. 11. La zone URI du nom d’utilisateur supplémentaire par défaut du certificat indique l’URI correspondante utilisée lors de la création de certificats si elle n’a pas été fournie au moment de la création. Cette zone n’est pas obligatoire. Cette zone mappe vers l’attribut url du fichier /usr/lib/security/pki/ca.cfg. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-25 12.La zone Algorithme de clef publique indique l’algorithme utilisé lors de la création d’un certificat. Au choix, RSA ou DSA. Si aucun n’est spécifié, le système prend comme valeur par défaut RSA. Cette zone mappe vers l’attribut algorithm du fichier /usr/lib/security/pki/ca.cfg. 13.La zone Taille de la clef publique (en bits) indique la taille en bits de l’algorithme de la clef publique. Cette zone est en bits, et non en octets, et cette valeur peut être arrondie à la valeur supérieure par le mécanisme de clef publique en cours afin d’utiliser la taille suivante en octets. (l’arrondi est utilisé pour les nombres de bits qui ne sont pas des multiples entiers de 8). Voici quelques exemples, 512, 1024 et 2048. Si cette zone n’est pas renseignée, le système prend comme valeur par défaut 1024 bits. Cette zone mappe vers l’attribut keysize du fichier /usr/lib/security/pki/ca.cfg. 14.La zone Nombre MAX. de nouvelle tentative de communication indique le nombre de tentatives du système pour contacter l’autorité de certification (lors de la création ou la révocation d’un certificat) avant abandon. Le système prend comme valeur par défaut le nombre de 5 tentatives. Cette zone mappe vers l’attribut retries du fichier /usr/lib/security/pki/ca.cfg. 15.La zone Algorithme de hachage pour signature indique l’algorithme de hachage utilisé lors de la signature d’un certificat d’authentification. Au choix, MD2, MD5 ou SHA1. Le système prend comme valeur par défaut MD5. Cette zone mappe vers l’attribut signinghash du fichier /usr/lib/security/pki/ca.cfg. 16.Appuyez sur Entrée pour valider les modifications. Modification / Affichage des comptes d’une autorité de certification 1. Lancez l’outil SMIT PKI, comme suit : smitty pki 2. Sélectionnez Modification / Affichage des comptes d’une autorité de certification. 3. Tapez local dans la zone Nom de l’autorité de certification puis appuyez sur entrée. 4. La zone Numéro de référence de création d’un certificat indique le numéro de référence utilisé pour créer un certificat. Le numéro de référence de création doit comporter au moins 7 chiffres. Le numéro de référence est défini par l’autorité de certification. (consultez Création de l’autorité de certification, page 6-23.) Cette zone mappe vers l’attribut carefnum du fichier /usr/lib/security/pki/acct.cfg. 5. La zone Mot de passe de création d’un certificat indique le mot de passe utilisé pour créer un certificat. La longueur de ce mot de passe doit être d’au moins 12 caractères de type alphanumériques ASCII 7 bits. Le mot de passe de création est défini dans l’autorité de certification et il doit être associé au numéro de référence de création mentionné ci-dessus. (consultez Création de l’autorité de certification, page 6-23.) Cette zone mappe vers l’attribut capasswd du fichier /usr/lib/security/pki/acct.cfg. 6. La zone Numéro de référence de révocation d’un certificat indique le numéro de référence utilisé pour révoquer un certificat. Le numéro de référence de création doit comporter au moins 7 chiffres. Le numéro de référence de révocation est envoyé à l’autorité de certification qui l’associe au certificat lors de chaque création. Pour révoquer un certificat, le même numéro de référence de révocation (et mot de passe de révocation) que celui envoyé lors de la création doit être envoyé lors de la révocation du certificat. Cette zone mappe vers l’attribut rvrefnum du fichier /usr/lib/security/pki/acct.cfg. 6-26 Guide de sécurité 7. La zone Mot de passe de révocation d’un certificat indique le mot de passe de référence utilisé pour révoquer un certificat. La longueur de ce mot de passe doit être d’au moins 12 caractères de type alphanumériques ASCII 7 bits Le mot de passe de révocation est envoyé à l’autorité de certification qui l’associe au certificat lors de chaque création. Pour révoquer un certificat, le même mot de passe de révocation (et numéro de référence de révocation) que celui envoyé lors de la création doit être envoyé lors de la révocation du certificat. Cette zone mappe vers l’attribut rvpasswd du fichier /usr/lib/security/pki/acct.cfg. 8. La zone Libellé de clef sécurisé indique le libellé (parfois appelé alias) de la clef de signature sécurisée située dans le magasin de clefs sécurisé. La valeur du libellé de la clef sécurisé est tirée de Création de la clef de signature sécurisée, page 6-24. Cette zone mappe vers l’attribut keylabel du fichier /usr/lib/security/pki/acct.cfg. 9. La zone Mot de passe de la clef sécurisée indique le mot de passe de la clef de signature sécurisée située dans le magasin de clefs sécurisé. La valeur du mot de passe de la clef sécurisé est tirée de Création de la clef de signature sécurisée, page 6-24. Cette zone mappe vers l’attribut keypasswd du fichier /usr/lib/security/pki/acct.cfg. 10.Appuyez sur Entrée pour valider les modifications. Ajout du compte LDAP pour l’autorité de certification 1. Lancez l’outil SMIT PKI, comme suit : smitty pki 2. Sélectionnez Ajout d’un compte LDAP. 3. La zone Nom de l’utilisateur administratif indique le DN du compte administratif LDAP. Le nom de l’utilisateur administratif du compte LDAP de l’autorité de certification est le même que celui utilisé dans Configuration du serveur LDAP, page 6-19 et Configuration LDAP du serveur pour le service d’authentification de certificats, page 6-22. La valeur doit être cn=admin. Elle permet au client de communiquer avec le serveur LDAP lors de l’accès aux données LDAP de l’autorité de certification. Cette zone mappe vers l’attribut ldappkiadmin du fichier /usr/lib/security/pki/acct.cfg. Par exemple : ldappkiadmin = ”cn=admin” 4. La zone Mot de passe administratif indique le mot de passe du compte administratif LDAP. Le mot de passe administratif est le même que celui utilisé dans Configuration du serveur LDAP, page 6-19 et Configuration LDAP du serveur pour le service d’authentification de certificats, page 6-22. Cette zone mappe vers l’attribut ldappkiadmpwd du fichier /usr/lib/security/pki/acct.cfg. Par exemple : ldappkiadmpwd = secret 5. La zone Nom du serveur indique le nom du serveur LDAP et doit être définie dans chaque strophe LDAP. La valeur est un nom de serveur LDAP unique. Cette zone mappe vers l’attribut ldapservers du fichier /usr/lib/security/pki/acct.cfg. Par exemple : ldapservers = ldapserver.mydomain.com 6. La zone Suffixe indique le suffixe DN de l’arborescence du répertoire sur lequel se trouvent les données. Le suffixe correspond à la valeur de l’attribut ibm–slapdSuffix utilisé dans Configuration LDAP du serveur pour le service d’authentification de certificats, page 6-22. Cet attribut doit être défini dans chaque strophe LDAP. Cette zone mappe vers l’attribut ldapsuffix du fichier /usr/lib/security/pki/acct.cfg. Par exemple : ldapsuffix = ”ou=aix,cn=us” 7. Appuyez sur Entrée pour valider les modifications. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-27 Ajout de PKI pour chaque compte utilisateur LDAP Exécutez les mêmes étapes que décrites dans Ajout du compte LDAP de l’autorité de certification, page 6-27, sauf que vous utilisez les valeurs utilisées dans l’étape Ajout des entrées de base de données ACL et suffixe PKI de Configuration du serveur LDAP pour PKI, page 6-20. Utilisez les valeurs suivantes : • Nom de l’utilisateur administratif ( ou=pkidata,cn=aixdata ), • Mot de passe administratif ( password ), • Nom du serveur ( spécifique au site ), • Suffixe ( ou=pkidata,cn=aixdata ). Appuyez sur Entrée pour valider les modifications. Modification / Affichage de la politique 1. Lancez l’outil SMIT PKI, comme suit : smitty pki 2. Sélectionnez Modification / Affichage de la politique. • La zone Création de certificats pour de nouveaux utilisateurs indique si la commande mkuser génère un certificat et un magasin de clefs pour le nouvel utilisateur (new), ou si l’administrateur fournit un certificat et un magasin de clefs une fois l’utilisateur créé (get). Cette zone mappe vers l’attribut cert de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Nom de l’autorité de certification indique l’autorité de certification utilisée par la commande mkuser lors de la génération d’un certificat. La valeur de cette zone doit correspondre au nom d’une strophe figurant dans le fichier ca.cfg ; par exemple, local. Cette zone mappe vers l’attribut ca de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Mot de passe utilisateur initial indique le mot de passe utilisé par la commande mkuser lors de la création du magasin de clefs d’un utilisateur. Cette zone mappe vers l’attribut passwd de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Version du certificat indique la version utilisée par la commande mkuser lors de la génération d’un certificat. Actuellement, la seule valeur prise en charge est 3, ce qui correspond à X.509v3. Cette zone mappe vers l’attribut version de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Taille de la clef publique indique la taille (en bits) de la clef publique utilisée par la commande mkuser lors de la génération d’un certificat. Cette zone mappe vers l’attribut keysize de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Emplacement du magasin de clefs indique le format URI du répertoire du magasin de clefs utilisé par la commande mkuser lors de la création d’un magasin de clefs. Cette zone mappe vers l’attribut keystore de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Période de validité indique la période de validité du certificat utilisée par la commande mkuser lors de la génération d’un certificat. La période validité demandée peut ou non être honorée par l’autorité de certification lors de la création du certificat. Cette période peut être indiquée en secondes, jours ou années. Si vous ne proposez qu’un seul nombre, on considère qu’il s’agit de secondes. Si la lettre d suit immédiatement le nombre, on considère qu’il s’agit de jours. Si la lettre y suit immédiatement le nombre, on considère qu’il s’agit d’années. Voici des exemples : – 1y (pour 1 an) – 30d (pour 30 jours) 6-28 Guide de sécurité – 2592000 (pour 30 jours en secondes). Cette zone mappe vers l’attribut validity de la strophe newuser du fichier /usr/lib/security/pki/policy.cfg. • La zone Réplication de certificats non locaux indique si la commande certlink sauvegarde une copie d’un certificat (yes) ou juste le lien vers ce certificat (no). Cette zone mappe vers l’attribut replicate de la strophe storage du fichier /usr/lib/security/pki/policy.cfg. • La zone Vérification des listes de révocation de certificats indique si les commandes certadd et certlink vérifient (yes) ou non (no) la CRL avant d’exécuter leurs tâches. Cette zone mappe vers l’attribut check de la strophe crl du fichier /usr/lib/security/pki/policy.cfg. • La zone Délai de communication par défaut indique le délai en secondes utilisée par les commandes certadd et certlink lors de la demande d’informations sur des certificats à l’aide du HTTP (par exemple, extraction des CRL). Cette zone mappe vers l’attribut timeout de la strophe comm du fichier /usr/lib/security/pki/policy.cfg. Le fichier methods.cfg Le fichier methods.cfg indique les définitions de la grammaire d’authentification utilisée par les attributs registry et SYSTEM. C’est là que la grammaire d’authentification de PKILDAP (pour PKI utilisant LDAP) et FPKI (fichiers PKI) doit être définie et ajoutée par l’administrateur système. Vous trouverez ci-dessous une définition methods.cfg type. Les noms des strophes PKI, LDAP et PKILDAP sont des noms arbitraires qui peuvent être modifiés par l’administrateur. Ces noms des strophes sont utilisées tout au long de cette section. PKI: program = /usr/lib/security/PKI options = authonly LDAP: program = /usr/lib/security/LDAP PKILDAP: options = auth=PKI,db=LDAP Pour prendre en charge des utilisateurs visiteurs, utilisez les mêmes noms de strophe methods.cfg et valeurs d’attribut sur tous les systèmes assurant cette option. Exemples des configuration de l’administration Création d’un nouveau compte utilisateur PKI Pour créer un nouveau compte utilisateur PKI, utilisez la commande mkuser et le nom de strophe /usr/lib/security/methods.cfg approprié (PKILDAP). Selon les attributs du fichier /usr/lib/security/pki/policy.cfg, la commande mkuser peut créer automatiquement un certificat pour l’utilisateur. Voici un exemple de commande mkuser qui crée le compte utilisateur bob : mkuser –R PKILDAP SYSTEM=”PKILDAP” registry=PKILDAP bob Conversion d’un compte utilisateur non–PKI en un compte utilisateur PKI Il existe deux façons pour convertir un compte utilisateur non–PKI en un compte utilisateur PKI. La première permet à l’administrateur du système d’accéder au magasin de clefs privé de l’utilisateur initial, ce qui peut ne pas être autorisé dans un environnement donné, et c’est la méthode la plus rapide. La seconde exige l’interaction entre l’utilisateur et l’administrateur du système, ce qui peut prendre plus de temps à configurer. Ces deux exemples utilisent les hypothèses suivantes : • cas.server et cas.client sont déjà installés, configurés et en cours de fonctionnement. • PKILDAP est défini dans methods.cfg comme indiqué dans Le fichier methods.cfg, page 6-29. Service d’authentification de certificats X.509 et infrastructure à clef publique 6-29 Exemple 1 : Avec l’autorité root, l’administrateur du système peut exécuter les commandes suivantes pour le compte utilisateur bob : certcreate –f cert1.der –l auth_lbl1 cn=bob bob # Créez et sauvegardez cert dans cert1.der. certadd –f cert1.der –l auth_lbl1 auth_tag1 bob # Ajoutez cert dans LDAP en tant que auth_tag1. certverify auth_tag1 bob # Vérifiez et signez cert dans LDAP. chuser SYSTEM=”PKILDAP” registry=PKILDAP bob # Modifiez le type de compte en PKILDAP. chuser –R PKILDAP auth_cert=auth_tag1 bob # Configurez le certificat auth de l’utilisateur. Modifiez ensuite le mot de passe du magasin de clefs de l’utilisateur bob à l’aide de la commande keypasswd. Exemple 2 : L’utilisateur bob doit exécuter les 3 premières commandes de l’exemple 1 ci-dessus ( certcreate, certadd, certverify ) pour créer son propre certificat et magasin de clefs. L’administrateur du système doit ensuite exécuter les deux dernières commandes chuser de l’exemple 1 ci-dessus. Création et ajout d’un certificat d’authentification Si un utilisateur PKI demande un nouveau certificat d’authentification, l’utilisateur peut créer un nouveau certificat et demander à l’administrateur du système d’en faire un certificat d’authentification. L’exemple ci-dessous montre la création d’un certificat par l’utilisateur bob, puis sa conversion par l’administrateur du système en un certificat d’authentification. # Connexion en tant que compte utilisateur bob : certcreate –f cert1.der –l auth_lbl1 cn=bob # Créez et sauvegardez cert dans cert1.der. certadd –f cert1.der –l auth_lbl1 auth_tag1 # Ajoutez cert dans LDAP en tant que auth_tag1. certverify auth_tag1 # Vérifiez et signez le cert dans LDAP. # En tant qu’administrateur du système : chuser –R PKILDAP auth_cert=auth_tag1 bob # Configurez le certificat auth de l’utilisateur. Modification du mot de passe par défaut du nouveau magasin de clefs Pour modifier le mot de passe utilisé pour créer les magasins de clefs des nouveaux utilisateurs PKI, éditez la valeur de l’attribut passwd de la strophe newuser dans le fichier /usr/lib/security/pki/policy.cfg. Gestion d’une clef de signature sécurisée compromise Le fichier qui contient la clef de signature sécurisée doit être remplacé et les certificats d’authentification de l’utilisateur doivent être de nouveau signés. Gestion d’une clef privée d’utilisateur compromise Si la clef privée d’un utilisateur est compromise, l’utilisateur ou l’administrateur doit révoquer le certificat au moyen du code de raison approprié, les autres utilisateurs utilisant la clef publique doivent en être informés et, selon l’utilisation de cette clef privée/publique, un nouveau certificat doit être émis. Si le certificat a été utilisé comme certificat d’authentification, un autre certificat (soit le nouveau, soit un certificat existant non promis détenu par l’utilisateur) doit être ajouté comme nouveau certificat d’authentification. 6-30 Guide de sécurité Gestion d’un magasin de clefs ou d’un mot de passe de magasin de clefs compromis Modifiez le mot de passe du magasin de clefs. Révoquez tous les certificats utilisateur. Créez de nouveaux certificats pour l’utilisateur, y compris un nouveau certificat d’authentification. Les clefs privées compromises peuvent toujours servir à l’utilisateur pour accéder à des données chiffrées auparavant. Déplacement du magasin de clefs d’un utilisateur ou modification du nom de magasin de clefs d’un utilisateur Si la clef privée d’un utilisateur est compromise, l’utilisateur ou l’administrateur doit révoquer le certificat au moyen du code de raison approprié, les autres utilisateurs utilisant la clef publique doivent en être informés et, selon la fonction de la clef privée et publique, un nouveau certificat doit être émis. Si le certificat a été utilisé comme certificat d’authentification, un autre certificat (soit le nouveau, soit un certificat existant non promis détenu par l’utilisateur) doit être ajouté comme nouveau certificat d’authentification. Déplacement du magasin de clefs d’un utilisateur ou modification du nom de magasin de clefs d’un utilisateur Chaque certificat utilisateur conservé dans LDAP contient l’emplacement du magasin de clefs de la clef privée correspondante. Déplacer le magasin de clefs d’un utilisateur d’un répertoire à un autre ou modifier le nom du magasin de clefs impose de modifier le nom et l’emplacement du magasin de clefs LDAP associé aux certificats de l’utilisateur. Si l’utilisateur possède plusieurs magasins de clefs, vous devez faire particulièrement attention à ne modifier que les informations LDAP des certificats concernés par cette modification. Pour déplacer un magasin de clefs de /var/pki/security/keys/user1.p12 vers /var/pki/security1/keys/user1.p12 : # En tant que root... cp /var/pki/security/keys/user1.p12 /var/pki/security1/keys/user1.p12 # Récupérez une liste de tous les certificats associés à cet utilisateur. certlist ALL user1 # # # # # # # Pour chaque certificat associé au magasin de clefs, procédez comme suit : A) Récupérez le libellé de la clef privée du certificat et son statut “ vérifié ”. B) Récupérez le certificat dans LDAP. C) Remplacez le certificat dans LDAP à l’aide du même libellé de clef privée, sans le raccourci du nouveau magasin de clefs. D) Si le certificat a été vérifié au préalable, il doit être à nouveau vérifié. (l’étape D exige le mot de passe du magasin de clefs.) # Exemple de modification d’un seul certificat. # Considérons que : # nomutilisateur : user1 # cert tag : tag1 # key label : label1 # Récupérez le libellé de la clef privée du certificat. certlist –a label tag1 user1 # Récupérez le certificat dans LDAP et placez-le dans le fichier cert.der. certget –f cert.der tag1 user1 # Remplacez le certificat dans LDAP. certadd –r –f cert.der –p /var/pki/security1/keys/user1.p12 –l label1 tag1 user1 # Faites une nouvelle vérification du certificat précédemment vérifié. # (vous devez connaître le mot de passe du magasin de clefs.) certverify tag1 user1 Service d’authentification de certificats X.509 et infrastructure à clef publique 6-31 6-32 Guide de sécurité Chapitre 7. Module d’extension d’authentification (PAM) La structure PAM (pluggable authentication module) permet d’incorporer plusieurs mécanismes d’authentification à un système à l’aide de modules d’extension. Les applications compatibles PAM peuvent bénéficier d’extensions sans devoir être modifiées. Cette souplesse permet aux administrateurs d’effectuer les tâches suivantes : • Sélectionner tout service d’authentification du système pour une application • Utiliser plusieurs mécanismes d’authentification pour un service donné • Ajouter de nouveaux modules de services d’authentification sans modifier les applications • Utiliser un mot de passe entré précédemment pour l’authentification avec plusieurs modules La structure PAM est composée d’une bibliothèque, de modules d’extension et d’un fichier de configuration. La bibliothèque PAM met en œuvre l’API PAM et sert à gérer les transactions PAM et à invoquer la SPI (service programming interface) PAM définie dans les modules d’extension. Les modules d’extension sont chargés dynamiquement par la bibliothèque, en fonction du service invoquant et de son entrée dans le fichier de configuration. Le succès dépend du module d’extension ainsi que du comportement défini pour le service. Le concept de succession permet de configurer un service d’authentification utilisant plusieurs méthodes. Le cas échéant, des modules peuvent être configurés pour utiliser un mot de passe entré précédemment plutôt que pour demander une entrée supplémentaire. L’illustration suivante montre l’interaction entre les applications, la bibliothèque PAM, le fichier de configuration et les modules PAM. Les applications PAM fictives (pam_login, pam_su, et pam_passwd) invoquent l’API PAM dans la bibliothèque PAM. La bibliothèque détermine le module à charger en fonction de l’entrée de l’application dans le fichier de configuration, et appelle la SPI PAM dans le module. Le module PAM fournit une fonction de conversation qui assure ses communications avec la bibliothèque. Le succès ou l’échec du module et le comportement défini dans le fichier de configuration déterminent ensuite s’il faut charger un autre module. Si tel est la cas, le processus se poursuit. Autrement, les données sont retournées à l’application. Module d’extension d’authentification (PAM) 7-1 Figure 3. Structure et entités PAM Cette illustration montre comment des commandes d’applications fictives utilisent la bibliothèque PAM pour accéder aux modules PAM souhaités. Bibliothèque PAM La bibliothèque PAM, /usr/lib/libpam.a, contient l’API PAM qui sert d’interface commune à toutes les applications PAM et contrôle le chargement des modules. Les modules sont chargés par la bibliothèque PAM en fonction du comportement de succession défini dans le fichier /etc/pam.conf. Les fonctions suivantes de l’API PAM invoquent la SPI PAM correspondante fournie par un module PAM. Par exemple, l’API pam_authenticate invoque la SPI pam_sm_authenticate dans un module PAM. • pam_authenticate • pam_setcred • pam_acct_mgmt • pam_open_session • pam_close_session • pam_chauthtok La bibliothèque PAM fournit aussi des fonctions permettant à une application d’invoquer des modules PAM et de leur envoyer des informations. Les API suivantes de la structure PAM sont mises en œuvre dans AIX : 7-2 pam_start Lancement d’une session PAM pam_end Fermeture d’une session PAM Guide de sécurité pam_get_data Récupération de données spécifiques au module pam_set_data Définition de données spécifiques au module pam_get_item Récupération d’informations de PAM communes pam_set_item Définition d’informations de PAM communes pam_get_user Récupération d’un nom d’utilisateur pam_strerror Obtention d’un message d’erreur standard PAM Modules PAM Les modules PAM permettent d’utiliser sur un système plusieurs mécanismes d’authentification, collectivement ou indépendamment. Un module PAM donné doit mettre en œuvre au moins l’un des quatre types de modules. Les types de modules sont décrits ci–dessous, accompagnés des SPI PAM requises pour se conformer au type de module. Modules d’authentification Authentifient les utilisateurs et définissent, rafraîchissent ou détruisent les données d’identification. Ces modules identifient l’utilisateur en fonction de son authentification et de ses données d’identification. Fonctions des modules d’authentification : . pam_sm_authenticate . pam_sm_setcred Modules de gestion de comptes Déterminent la validité du compte utilisateur et des accès suivants, après l’identification par le module d’authentification. Les vérifications effectuées par ces modules incluent généralement des restrictions de mot de passe et d’expiration de compte. Fonction du module de gestion de comptes : . pam_sm_acct_mgmt Modules de gestion de sessions Lancent et mettent fin aux sessions utilisateur. Vous pouvez aussi bénéficier d’un audit de sessions. Fonctions du module de gestion de sessions : . pam_sm_open_session . pam_sm_close_session Modules de gestion des mots de passe Ils modifient les mots de passe et gèrent les attributs liés. Fonction du module de gestion des mots de passe : . pam_sm_chauthtok Module d’extension d’authentification (PAM) 7-3 Fichier de configuration PAM Le fichier de configuration /etc/pam.conf contient des entrées de service pour chaque type de module PAM et sert à acheminer des services via un chemin d’accès défini. Les entrées du fichier se composent des zones suivantes, délimitées par des espaces : service_name module_type control_flag module_path module_options Où : service_name Indique le nom du service. Le mot clé OTHER définit le module par défaut à utiliser pour les applications non spécifiées dans une entrée. module_type Désigne le type de module pour le service. Les types de module valides sont auth, account, session et password. control_flag Désigne le comportement de succession du module. Les indicateurs de contrôle compatibles sont requis (required), suffisant (sufficient), ou facultatif (optional). module_path Désigne le chemin d’accès vers l’objet de la bibliothèque qui met en œuvre la fonctionnalité du service. Les entrées de module_path doivent commencer au répertoire root ( / ). Si l’entrée ne commence pas par /, alors /usr/lib/security est ajouté au début du nom de fichier. module_options Répertorie des options qui peuvent être transmises aux modules de services. Les valeurs de cette zone dépendent des options prises en charge par le module défini dans la zone module_path . Toutes les zones ci–dessus sont nécessaires pour chaque entrée à l’exception de la zone module_options, qui est facultative. Les entrées incorrectes ou comportant des valeurs non valides pour les zones module_type ou control_flag sont ignorées par la bibliothèque PAM. Les entrées comportant un dièse (#) au début de la ligne sont également ignorées car mises en commentaire. La succession est mise en œuvre dans le fichier de configuration par la création de plusieurs entrées avec la même zone module_type. Les modules sont invoqués dans l’ordre dans lequel ils apparaissent dans le fichier, le dernier résultat étant déterminé par la zone control_flag spécifiée pour chaque entrée. Les valeurs acceptées pour la zone control_flag et leur comportement dans la suite sont décrits ci–dessous : 7-4 Guide de sécurité required Tous les modules obligatoires d’une suite doivent être présents pour obtenir un résultat positif. Si l’un d’eux échoue, tous les modules obligatoires de la suite seront essayés, mais la première erreur d’un module obligatoire sera retournée. sufficient Si un module marqué ainsi est correct, et si aucun module obligatoire ou suffisant précédent n’a échoué, tous les modules restants dans la suite sont ignorés. optional Si aucun module de la suite n’est obligatoire et si aucun module suffisant n’a enregistré un succès, au moins l’un des modules facultatifs doit fournir un succès pour le service. Si un autre module de la suite enregistre un succès, l’échec d’un module facultatif est ignoré. Voici un exemple de fichier /etc/pam.conf qui pourrait être utilisé sur un système sur lequel d’autres modules PAM sont installés : # # Fichier de configuration PAM /etc/pam.conf # # Gestion des authentifications login auth required /usr/lib/security/pam_aix login auth required /usr/lib/security/pam_verify login auth optional /usr/lib/security/pam_test su auth sufficient /usr/lib/security/pam_aix su auth required /usr/lib/security/pam_verify OTHER auth required /usr/lib/security/pam_aix # Gestion des comptes OTHER account required /usr/lib/security/pam_aix # Gestion de sessions OTHER session required /usr/lib/security/pam_aix # Gestion des mots de passe OTHER password required /usr/lib/security/pam_aix use_first_pass Le fichier de configuration exemple contient trois entrées pour le service de connexion. Une fois les éléments obligatoires pam_aix et pam_verify spécifiés, l’utilisateur doit entrer deux mots de passe pour s’authentifier, et ces deux mots de passe doivent être corrects. La troisième entrée pour le module pam_test est facultative et son succès ou son échec n’affecteront pas la capacité de l’utilisateur à se connecter. L’option use_first_pass du module pam_test permet d’utiliser un mot de passe entré précédemment plutôt que de devoir en entrer un nouveau. La commande su se comporte de telle sorte que si pam_aix est correct, l’authentification est effectuée. Si pam_aix échoue, pam_verify doit effectuer une authentification correcte. L’utilisation du mot de passe OTHER comme nom de service permet de définir une valeur par défaut pour tout autre service non déclaré explicitement dans le fichier de configuration. La définition d’une valeur par défaut garantit que chaque cas pour un type de module donné sera couvert par au moins un module. Module d’extension d’authentification (PAM) 7-5 Ajout d’un module PAM Pour ajouter un module PAM, effectuez la procédure ci–dessous : 1. Installez le module dans le répertoire /usr/lib/security. 2. Définissez la propriété du fichier sur root et les droits sur 555. La bibliothèque PAM ne charge aucun module autre que ceux possédés par l’utilisateur root. 3. Mettez à jour le fichier de configuration /etc/pam.conf pour inclure le module dans les entrées des noms de services désirés. 4. Vérifiez que les services concernés fonctionnent correctement. Ne vous déconnectez pas du système avant d’avoir effectué un test de connexion. Modification du fichier /etc/pam.conf Lors de toute modification du fichier de configuration /etc/pam.conf, pensez aux éléments suivants : • AIX ne fournit pas de fichier /etc/pam.conf par défaut, donc le fichier doit être créé avant l’utilisation de PAM. Lorsque vous créez le fichier, définissez la propriété du fichier sur root et les droits de base sur 644. Le fichier peut alors être modifié manuellement par l’utilisateur root. • Déterminez le module par défaut à utiliser pour chaque type de module puis utilisez le mot clé OTHER pour ne pas avoir à indiquer le module pour chaque service. • Lisez la documentation fournie avec chaque module choisi, et déterminez les indicateurs de contrôle et options pris en charge, ainsi que leur effet. • Classez les modules et indicateurs de contrôle avec soin. Souvenez–vous du comportement des indicateurs de contrôle obligatoires, suffisants et facultatifs dans les successions de modules. Remarque : Une mauvaise configuration du fichier de configuration PAM peut empêcher toute connexion au système. Une fois le fichier modifié, testez systématiquement les applications concernées avant de vous déconnecter du système. Pour récupérer un système auquel il est impossible de se connecter, amorcez–le en mode maintenance et corrigez le fichier de configuration /etc/pam.conf. Activation du débogage PAM La bibliothèque PAM peut fournir des informations de débogage durant son fonctionnement. Une fois le système activé pour le recueil de sorties de débogage, les informations collectées permettent de suivre les appels à l’API PAM et de localiser les points de panne de la configuration PAM actuelle. Pour activer les sorties de débogage PAM, procédez comme suit : 1. Créez un fichier vide dans /etc/pam_debug. La bibliothèque PAM contrôle l’existence du fichier /etc/pam_debug, et active la sortie syslog. 2. Modifiez le fichier /etc/syslog.conf pour inclure les entrées nécessaires pour les niveaux de messages souhaités. 3. Relancez le démon syslogd afin que la nouvelle configuration soit reconnue. 4. Une fois l’application PAM redémarrée, les messages de débogage seront recueillis dans le fichier défini dans le fichier de configuration /etc/syslog.conf. 7-6 Guide de sécurité Intégration de PAM avec AIX L’intégration de PAM avec AIX nécessite l’utilisation d’un module d’authentification compatible avec AIX, PAM, et d’un module pam_aix. Ces modules offrent plusieurs voies d’intégration de PAM : • L’accès à PAM depuis les services de sécurité AIX est assuré par le module PAM • L’accès depuis une application PAM aux services de sécurité AIX est fourni par les modules PAM (pam_aix) Module PAM Les services de sécurité AIX peuvent être configurés pour appeler les modules PAM à l’aide de la structure de modules d’authentification existante compatible avec AIX. Lorsque le fichier /usr/lib/security/methods.cfg est configuré correctement, le module de chargement PAM achemine les services de sécurité AIX (passwd, login, etc) vers la bibliothèque PAM. La bibliothèque PAM contrôle le fichier /etc/pam.conf pour déterminer quel module PAM utiliser, puis pour exécuter l’appel de SPI PAM correspondant. Les valeurs retournées par PAM sont converties en codes d’erreur AIX et retournées au programme appelant. Figure 4. Chemin du service de sécurité AIX vers le module PAM. Cette illustration indique le chemin emprunté par un service de sécurité AIX lorsque PAM est configuré correctement. Les modules PAM indiqués (pam_krb, pam_ldap et pam_dce) sont des exemples de solutions tierces. PAM est un simple module de chargement uniquement chargé de l’authentification et installé dans le répertoire /usr/lib/security. Le module PAM doit être associé à une base de données pour former un module de chargement composé. L’exemple suivant indique les strophes pouvant être ajoutées au fichier methods.cfg pour former un module PAM composé avec une base de données nommée files. Le mot clé BUILTIN pour l’attribut db désignera la base de données en tant que fichiers UNIX. Module d’extension d’authentification (PAM) 7-7 PAM: program = /usr/lib/security/PAM PAMfiles: options = auth=PAM,db=BUILTIN L’option –R permet alors de créer et modifier les utilisateurs à l’aide des commandes de gestion, et en définissant l’attribut SYSTEM lors de la création d’un utilisateur. mkuser –R PAMfiles SYSTEM=PAMfiles registry=PAMfiles pamuser Cette action indiquera aux appels suivants aux services de sécurité AIX (login, passwd, etc) d’utiliser le module de chargement PAM pour l’authentification. Dans cet exemple, la base de données files a servi pour générer le module composé, mais d’autres bases de données peuvent aussi être utilisées, si elles sont installées, comme LDAP. La création d’utilisateurs définie précédemment entraînera le mappage suivant de la sécurité AIX en appels d’API PAM : AIX ===== authenticate chpass passwdexpired passwdrestrictions ––> ––> ––> ––> PAM API ========= pam_authenticate pam_chauthtok pam_acct_mgmt No comparable mapping exists, success returned La personnalisation du fichier /etc/pam.conf permet de diriger les appels d’API PAM vers le module PAM souhaité pour authentification. La succession peut être mise en œuvre pour obtenir un mécanisme d’authentification plus sophistiqué. Les données appelées par un service de sécurité AIX sont transmises à PAM via la fonction pam_set_item car il n’est pas possible de remplir la boîte de dialogue depuis PAM. Les modules PAM écrits pour intégration avec le module PAM devraient récupérer toutes les données à l’aide d’appels pam_get_item et ne devraient pas essayer de demander à l’utilisateur d’entrer des données, car le service de sécurité s’en charge. La détection des boucles permet de repérer de possibles erreurs de configuration qui feraient que le service de sécurité AIX serait acheminé vers PAM, puis un module PAM tenterait d’appeler le service de sécurité AIX pour exécuter l’opération. La détection de cette boucle entraînera l’échec immédiat de l’opération souhaitée. Remarque : Le fichier /etc/pam.conf ne doit PAS être configuré pour utiliser le module pam_aix lors de l’utilisation de l’intégration PAM depuis un service de sécurité AIX vers un module PAM, car cela créerait une boucle. Module pam_aix Le module pam_aix est un module PAM qui permet aux applications activées par PAM d’accéder aux services de sécurité AIX en fournissant les interfaces qui appellent les services AIX équivalents lorsqu’ils existent. Ces services sont alors exécutés par un module d’authentification compatible, ou par la fonction AIX builtin, selon la définition des utilisateurs et la configuration correspondante dans methods.cfg. Tous les codes d’erreur générés lors de l’exécution d’un service AIX sont convertis en codes PAM correspondants. Figure 5. Chemin de l’application PAM vers le sous–système de sécurité AIX. Cette illustration montre le chemin suivi par un appel d’API d’une application PAM si le fichier /etc/pam.conf est configuré pour l’utilisation du module pam_aix. L’intégration permet l’authentification des utilisateurs par tout module d’authentification chargeable (DCE, LDAP, ou KRB5) ou dans les fichiers UNIX (compat). 7-8 Guide de sécurité Le module pam_aix est installé dans le répertoire /usr/lib/security. L’intégration du module pam_aix nécessite la configuration du fichier /etc/pam.conf. La succession est toujours disponible, mais il a été choisi de ne pas la représenter dans cet exemple simple du fichier /etc/pam.conf : # # Gestion de l’authentification # OTHER auth required /usr/lib/security/pam_aix # # Gestion des comptes # OTHER account required /usr/lib/security/pam_aix # # Gestion des sessions # OTHER session required /usr/lib/security/pam_aix # # Gestion des mots de passe # OTHER password required /usr/lib/security/pam_aix Le module pam_aix prend en charge les fonctions SPI pam_sm_authenticate, pam_sm_chauthok et pam_sm_acct_mgmt. Les SPI pam_sm_setcred, pam_sm_open_session et pam_sm_close_session sont aussi prises en charge dans le module pam_aix, mais elles retournent simplement des invocations PAM_SUCCESS. Module d’extension d’authentification (PAM) 7-9 Voici un exemple de correspondance des appels SPI PAM au sous–système de sécurité AIX : PAM SPI ========= pam_sm_authenticate pam_sm_chauthtok ––> ––> AIX ===== authenticate passwdexpired, chpass Note: passwdexpired is only checked if the PAM_CHANGE_EXPIRED_AUTHTOK flag is passed in. pam_sm_acct_mgmt pam_sm_setcred PAM_SUCCESS returned pam_sm_open_session PAM_SUCCESS returned pam_sm_close_session PAM_SUCCESS returned ––> ––> loginrestrictions, passwdexpired No comparable mapping exists, ––> No comparable mapping exists, ––> No comparable mapping exists, Les données destinées à être transmises au sous–système de sécurité AIX peuvent être définies à l’aide de la fonction pam_set_item avant d’utiliser le module, ou le module pam_aix demandera les données si elles n’existent pas encore. 7-10 Guide de sécurité Chapitre 8. Outils OpenSSH Les outils OpenSSH prennent en charge les protocoles SSH1 et SSH2. Ils offrent des fonctions de shell là où le trafic réseau est chiffré et authentifié. OpenSSH s’appuie sur l’architecture client–serveur. OpenSSH exécute le démon sshd sur l’hôte AIX et attend la connexion des clients. Il assure l’authentification et le chiffrement des canaux avec les paires de clés publique et privée pour garantir des connexions réseau sécurisées et une authentification en fonction de l’hôte. Pour en savoir plus sur OpenSSH, reportez–vous au site suivant : http://www.openssh.org Il contient les informations de la page man sur les commandes OpenSSH. Pour plus d’informations sur OpenSSH sous AIX, reportez–vous au site suivant, qui propose les nouveaux modules de format installp pour AIX 5L : http://oss.software.ibm.com/developerworks/projects/opensshi Cette section explique comment installer et configurer OpenSSH sous AIX. OpenSSH est fourni dans le Bonus Pack AIX 5.2. Cette version de OpenSSH est compilée et regroupée en modules installp à l’aide du niveau openssh–3.4p1 de code source. Le programme OpenSSH contenu sur le CD–ROM du Bonus Pack est soumis aux conditions de licence de l’IPLA (International Program License Agreement) pour les programmes non garantis. OpenSSH est également disponible pour AIX 4.3.3 dans plusieurs modules RPM, fournis sur le CD AIX toolbox for Linux applications. Avant d’installer les modules OpenSSH installp, vous devez installer le logiciel OpenSSL (Open Secure Sockets Layer). OpenSSL contient la bibliothèque chiffrée. OpenSSL est disponible en modules RPM avec le CD AIX toolbox for Linux applications. Les modules d’installation comprennent les pages man et les ensembles de fichiers de messages traduits. 1. Installez le module RPM OpenSSL à l’aide de la commande geninstall : # geninstall –d/dev/cd0 R:openssl–0.9.6e Le résultat affiché sera semblable au suivant : SUCCESSES ––––––––– openssl–0.9.6e–1 2. Installez ensuite les modules OpenSSH installp à l’aide de la commande geninstall : # geninstall –I”Y” –d/dev/cd0 I:openssh.base Utilisez l’indicateur Y pour accepter l’accord de licence OpenSSH. Le résultat affiché sera semblable au suivant : Outils OpenSSH 8-1 Récapitulatif de l’installation –––––––––––––––––––– Name Level Part Event Result ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– –––– openssh.base.client 3.4.0.5200 USR APPLY SUCCESS openssh.base.server 3.4.0.5200 USR APPLY SUCCESS openssh.base.client 3.4.0.5200 ROOT APPLY SUCCESS openssh.base.server 3.4.0.5200 ROOT APPLY SUCCESS Vous pouvez aussi utiliser le raccourci SMIT install_software pour installer OpenSSL et OpenSSH. La procédure précédente installe les fichiers binaires OpenSSH suivants : ssh Similaire aux programmes client rlogin et rsh ssh–agent Un agent pouvant stocker des clés privées ssh–add Outil pour ajouter des clés à ssh–agent sftp Equivalent de FTP utilisé par les protocoles SSH1 et SSH2 scp Programme de copie de fichiers similaire à rcp ssh–keygen Outil de génération de clés ssh–keyscan Utilitaire de recueil de clés publiques depuis plusieurs hôtes ssh–keysign Utilitaire d’authentification en fonction de l’hôte sshd Démon de connection sftp–server Sous–système serveur SFTP (lancé automatiquement par le démon sshd) Les informations générales suivantes concernent OpenSSH : • Le répertoire /etc/ssh/ssh_config contient le démon sshd et les fichiers de configuration pour la commande ssh. • Le répertoire /usr/openssh contient le fichier readme et le fichier texte de licence open–source OpenSSH original. • Le démon sshd est contrôlé par AIX SRC. Les commandes suivantes permettent de lancer, arrêter et afficher le statut du démon : startsrc –s sshd stopsrc –s sshd lssrc –s sshd OU startsrc –g ssh OU stopsrc –g ssh OU lssrc –s ssh (groupe) Les commandes suivantes permettent également de lancer et d’arrêter le démon : /etc/rc .d/rc2.d/Ksshd start OU /etc/rc.d/rc2.d/Ssshd start /etc/rc.d/rc2.d/Ksshd stop OU /etc/rc.d/rc2.d/Ssshd stop 8-2 Guide de sécurité • Lorsque l’ensemble de fichiers serveur OpenSSH est installé, une entrée est ajoutée au répertoire /etc/rc.d/rc2.d. Une entrée dans inittab permet d’exécuter des processus de niveau 2 (l2:2:wait:/etc/rc.d/rc 2), afin que le démon sshd démarre automatiquement à l’amorçage. Pour empêcher le démon de démarrer à l’amorçage, retirez les fichiers /etc/rc.d/rc2.d/Ksshd et /etc/rc.d/rc2.d/Ssshd. • OpenSSH consigne des informations dans SYSLOG. • Le document Managing AIX Server Farms, disponible sur le site suivant, apporte des informations sur la configuration de OpenSSH sous AIX : http://www.redbooks.ibm.com Utilisation d’OpenSSH avec PAM A partir d’AIX 5.2, OpenSSH est compilé pour accepter PAM (Pluggable Authentication Module). PAM est une méthode d’authentification des utilisateurs. Il apporte un mécanisme adaptable d’authentification des utilisateurs AIX en permettant l’ajout d’un module écrit par l’utilisateur au processus de connexion. Un utilisateur peut rédiger son propre module ou utiliser le module pam_aix d’AIX. Le module pam_aix fournit des interfaces avec les services de sécurité AIX. Voici un exemple de fichier de configuration /etc/pam.conf utilisant le module PAM pam_aix, mais d’autres modules installés sur le système peuvent être utilisés. Créez le fichier /etc/pam.conf contenant les informations suivantes : sshd OTHER sshd OTHER sshd OTHER sshd OTHER auth auth account account password password session session required required required required required required required required /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix /usr/lib/security/pam_aix Outils OpenSSH 8-3 8-4 Guide de sécurité Chapitre 9. Sécurité TCP/IP Si vous avez installé TCP/IP (Transmission Control Protocol/Internet Protocol) et NFS (Network File System), vous pouvez configurer votre système afin de communiquer via un réseau. Ce guide ne décrit pas les concepts TCP/IP de base, mais des sujets liés à la sécurité dans TCP/IP. Pour des informations sur l’installation et la configuration initiale de TCP/IP, consultez le chapitre Transmission Control Protocol/Internet Protocol (TCP/IP) du manuel AIX 5L Version 5.2 System Management Guide: Communications and Networks. Pour diverses raisons, l’administrateur système doit assurer un certain niveau de protection. Le niveau de sécurité peut relever de la politique d’entreprise. Un système peut aussi devoir accéder à des systèmes publics, et de ce fait doit être étroitement contrôlé. Ces niveaux de sécurité peuvent s’appliquer au réseau, au système d’exploitation, aux applications, et même aux programmes développés par l’administrateur. Ce chapitre décrit le dispositif de sécurité fourni avec TCP/IP, en mode standard et sécurisé, et développe certaines notions de sécurité propres à l’environnement réseau. Une fois TCP/IP et NFS installés, utilisez Web-based System Manager ou le raccourci SMIT tcpip pour configurer le système. Ce chapitre traite des points suivants : • Système de protection du système d’exploitation, page 9-2 • Sécurité des commandes TCP/IP, page 9-3 • Processus sécurisés, page 9-7 • La Base informatique réseau sécurisée (NTCB), page 9-8 • Sécurité des données et protection des informations, page 9-10 • Contrôle d’accès aux ports TCP en fonction de l’utilisateur, avec le contrôle d’accès discrétionnaire aux ports Internet, page 9-10 Sécurité TCP/IP 9-1 Système de protection du système d’exploitation La plupart des fonctions de protection proposées pour TCP/IP sont calquées sur celles du système d’exploitation. En voici les grandes lignes. Contrôle d’accès au réseau Le dispositif de sécurité appliqué au réseau prolonge celui du système d’exploitation : • L’authentification de l’utilisateur s’opère au niveau de l’hôte distant via un nom d’utilisateur un mot de passe et (tout comme lors de la connexion au système local). Les commandes TCP/IP sécurisées, telles que ftp, rexec et telnet, subissent les mêmes contraintes et contrôles que celles du systèmes d’exploitation. • L’authentification de connexion vise à contrôler l’identité et l’adresse IP de l’hôte distant. Ainsi, tout risque d’usurpation d’identité par un hôte distant est évité. • La protection des échanges permet d’importer/exporter des données à un niveau de sécurité spécifique, entre des cartes réseau dotées de droits et de protections identiques. Par exemple des données confidentielles ne peuvent circuler qu’entre cartes du niveau de protection correspondant. Audit de réseau L’audit de réseau est réalisé par TCP/IP via le sous–système d’audit qui s’applique aux routines de réseau noyau et aux applications. Il consigne toutes les actions relatives à la sécurité et à l’utilisateur qui les effectue. L’audit s’applique aux événement suivants : Evénements au niveau du noyau • Changement de configuration • Changement d’ID hôte • Changement de route • Connexion • Création d’une prise (socket) • Exportation d’objets • Importation d’objets Evénements au niveau application • Accès au réseau • Changement de configuration • Changement d’ID hôte • Changement de route statique • Configuration du courrier • Connexion • Exportation de données • Importation de données • Ecriture de courrier dans un fichier Toute création et suppression d’objets subit un audit de la part du système d’exploitation. Les enregistrements d’audit au niveau application interrompent et relancent l’audit pour éviter leur enregistrement par l’audit du noyau. 9-2 Guide de sécurité Chemin d’accès sécurisé, shell sécurisé et clé SAK Le système d’exploitation prévoit un chemin d’accès sécurisé pour empêcher tout programme non autorisé de lire des données à partir d’un terminal utilisateur. Ce chemin est utilisé pour les communications confidentielles avec le système (par exemple, pour la modification de mots de passe ou l’entrée en communication). Un shell sécurisé (tsh) est également proposé, qui n’exécute que les programmes sécurisés, testés et contrôlés comme tels. TCP/IP prend tous ces dispositifs en charge, de même que la clé SAK ( Secure Attention Key) dont le rôle est de mettre en place l’environnement pour une communication sécurisée entre vous et le système. La clé SAK locale est accessible dès l’utilisation de TCP/IP. Par ailleurs, la commande telnet donne accès à une clé SAK distante. La clé SAK locale offre les mêmes fonctions sous telnet et sous d’autres programmes du système : elle met fin au processus telnet et à tout autre processus associé au terminal qui exécutait telnet. Toutefois, sous telnet, vous pouvez envoyer une demande de chemin d’accès sécurisé au système distant via la commande telnet send sak (en mode commande telnet). Vous pouvez aussi définir une seule clé pour l’émission d’une requête SAK à l’aide de la commande telnet set sak. Pour plus d’informations sur la base TCB, consultez le chapitre La base TCB, page 1-1. Sécurité des commandes TCP/IP Certaines commandes TCP/IP ont pour but de fournir un environnement sécurisé durant le fonctionnement. Il s’agit de ftp, rexec et telnet. ftp concerne les transferts de données. rexec s’applique à l’exécution des commandes sur un hôte étranger. telnet a trait à la connexion sur un hôte étranger. Les commandes ftp, rexec et telnet n’assurent la sécurité que pendant leur exécution. C’est–à–dire qu’elles ne définissent pas d’environnement sécurisé pour l’exécution d’autres commandes. Pour protéger votre système lors de l’exécution d’autres opérations, faites appel à la commande securetcpip. Cette commande permet de protéger le système en désactivant les applications et démons non sécurisés et en vous permettant d’activer la sécurisation de votre protocole IP. Les commandes ftp, rexec, securetcpip et telnet fournissent les garanties suivantes : Sécurité TCP/IP 9-3 ftp La commande ftp fournit un environnement sécurisé pour le transfert de fichiers. Lorsqu’un utilisateur lance la commande ftp vers un hôte étranger, il est invité à fournir un ID de connexion. Un ID de connexion par défaut s’affiche : l’ID de connexion en cours de l’utilisateur sur l’hôte local. L’utilisateur doit fournir un mot de passe pour l’hôte distant. Le processus de connexion automatique recherche, dans le fichier $HOME/.netrc de l’utilisateur local, l’ID et le mot de passe à soumettre à l’hôte étranger. Pour plus de sécurité, les droits d’accès au fichier $HOME/.netrc doivent être fixés à 600 (lecture et écriture réservées au propriétaire). A défaut, la connexion automatique échoue. Remarque : Le fichier .netrc impose de stocker les mots de passe dans un fichier non chiffré. C’est pourquoi la connexion automatique par ftp n’est pas disponible si le système est configuré avec securetcpip. Pour la réactiver, supprimez la commande ftp de la strophe tcpip du fichier /etc/security/config. Le transfert de fichiers via ftp suppose deux connexions TCP/IP : une pour le protocole et une pour le transfert des données. La connexion au protocole, principale, est une connexion fiable car établie sur des ports de communication fiables. La connexion secondaire, dédiée au transfert des données proprement dit, doit être établie sur les mêmes hôtes local et distant que la première (condition vérifiée sur chacun des hôtes). Faute de quoi, la commande ftp émet un message d’erreur indiquant que la connexion n’a pas été authentifiée, puis s’arrête. Ce contrôle vise à éviter qu’un hôte tiers n’intercepte des données qui ne lui sont pas destinées. 9-4 Guide de sécurité rexec La commande rexec s’applique à l’exécution des commandes sur un hôte étranger. L’utilisateur est invité à décliner son ID de connexion et son mot de passe. Avec le dispositif de connexion automatique, la commande rexec recherche, dans le fichier $HOME/.netrc de l’utilisateur local, l’ID et le mot de passe à soumettre à l’hôte étranger. Pour plus de sécurité, les droits d’accès au fichier $HOME/.netrc doivent être fixés à 600 (lecture et écriture réservées au propriétaire). A défaut, la connexion automatique échoue. Remarque : Le fichier .netrc impose de stocker les mots de passe dans un fichier non chiffré. C’est pourquoi la connexion automatique par rexec n’est pas disponible si le système est exploité en mode sécurisé. Pour la réactiver, supprimez l’entrée rexec de la strophe tcpip du fichier /etc/security/config. securetcpip La commande securetcpip active le système de protection de TCP/IP. L’accès aux commandes non sécurisées est supprimé du système à l’émission de cette commande. Les commandes suivantes sont supprimées par l’exécution de la commande securetcpip : • • rlogin et rlogind • • rcp, rsh et rshd • • tftp et tftpd • • trpt La commande securetcpip fait passer la sécurité du d’un niveau standard au niveau de maximal. Dès lors, vous n’aurez à relancer securetcpip que si vous réinstallez TCP/IP. telnet ou tn La commande telnet (TELNET) fournit un environnement sécurisé à la connexion sur un hôte étranger. L’utilisateur est invité à décliner son ID de connexion et son mot de passe. Le terminal de l’utilisateur est considéré comme directement connecté à l’hôte : l’accès au terminal est contrôlé par des bits d’autorisation. Les autres utilisateurs (groupe et autres) n’ont pas accès en lecture au terminal, mais ils peuvent y écrire des messages si le propriétaire les y autorise. La commande telnet donne également accès au shell sécurisé du système distant via la clé SAK (Secure Attention Key). Cette clé, qui peut être définie par la commande telnet, doit être différente de celle utilisée pour appeler le chemin d’accès sécurisé local. Sécurité TCP/IP 9-5 Exécution de commandes à distance (/etc/hosts.equiv) Les utilisateurs répertoriés dans le fichier /etc/hosts.equiv peuvent exécuter certaines commandes sur votre système sans fournir de mot de passe. Le tableau suivant fournit des informations sur le classement, l’ajout et la suppression d’hôtes distants à l’aide de Web–based System Manager, SMIT, ou de la ligne de commandes. Tâches d’accès à distance aux commandes Tâche Raccourci SMIT Commande ou fichier Web-based System Manager Management Environment Afficher la liste des hôtes qui peuvent accéder aux commandes smit lshostsequiv affichez /etc/hosts.equiv Software ––> Network ––> TCPIP (IPv4 and IPv6) ––> TCPIP Protocol Configuration ––> TCP/IP ––> Configure TCP/IP ––> Advanced Methods ––> Hosts File ––> Contents of /etc/hosts file. Ajouter un hôte distant autorisé à exécuter les commandes smit mkhostsequiv modifiez /etc/hosts.equiv Software ––> Network ––> TCPIP (IPv4 and IPv6) ––> TCPIP Protocol Configuration ––> TCP/IP ––> Configure TCP/IP ––> Advanced Methods ––> Hosts File. Dans Add/Change host entry, complétez les zones suivantes : IP Address, Host name, Alias(es) et Comment. Cliquez sur Add/Change Entry, puis cliquez sur OK. Supprimer un hôte distant smit rmhostsequiv Remarque 1 modifiez /etc/hosts.equiv Remarque 1 9-6 Guide de sécurité Software ––> Network ––> TCPIP (IPv4 and IPv6) ––> TCPIP Protocol Configuration ––> TCP/IP ––> Configure TCP/IP ––> Advanced Methods ––> Hosts File. Sélectionnez un hôte dans Contents of /etc/host file. Cliquez sur Delete Entry ––> OK. Remarques : 1. Pour plus de détails sur ces procédures, reportez–vous à la section ”hosts.equiv File Format for TCP/IP” dans le document AIX 5L Version 5.2 Files Reference. Restrictions d’accès FTP (/etc/ftpusers) Les utilisateurs répertoriés dans le fichier /etc/ftpusers sont protégés contre l’accès FTP à distance. Supposons que l’utilisateur A connecté à un système distant connaît le mot de passe de l’utilisateur B sur votre système. Si l’utilisateur B apparaît dans le fichier /etc/ftpusers , l’utilisateur A ne peut transmettre de fichiers par FTP vers ou depuis le compte de l’utilisateur B, bien qu’il connaisse son mot de passe. Le tableau suivant fournit des informations sur le classement, l’ajout et la suppression d’utilisateurs restreints à l’aide de Web–based System Manager, SMIT, ou de la ligne de commandes. Opérations relatives aux utilisateurs protégés Tâche Raccourci SMIT Commande ou fichier Web-based System Manager Management Environment Afficher la liste smit lsftpusers affichez /etc/ftpusers Software ––> Users ––> All Users. Ajouter un utilisateur smit mkftpusers modifiez /etc/ftpusers Software ––> Users ––> All Users ––> Selected ––> Add this User to Group. Sélectionnez un groupe, puis cliquez sur OK. Remarque 1 Supprimer un utilisateur smit rmftpusers modifiez /etc/ftpusers Remarque 1 Software ––> Users ––> All Users ––> Selected ––> Delete. Remarques : 1. Pour plus de détails sur ces procédures, reportez–vous à la section ”ftpusers File Format for TCP/IP” dans le document AIX 5L Version 5.2 Files Reference. Processus sécurisés Un processus (ou programme) sécurisé est un script shell, un démon ou un programme conforme aux normes de sécurité établies et révisées par des organismes agrées (aux USA, le ministère de la défense), qui certifient également certains programmes sécurisés. A ces programmes sont associés différents niveaux de sécurité : A1, B1, B2, B3, C1, C2 et D (A1 étant le niveau maximal) satisfaisant chacun à des critères spécifiques. Par exemple, le niveau C2 intègre les aspects suivants : intégrité des programmes Assure le bon fonctionnement du processus. modularité Le code des processus est divisé en modules qui ne peuvent pas être directement affectés ou accédés par d’autres modules. Sécurité TCP/IP 9-7 principe du moindre privilège Les activités utilisateur se déroulent toujours au niveau de privilège le plus faible : un utilisateur habilité à lire un fichier ne peut le modifier par inadvertance. limitation de la réutilisation d’objets Un utilisateur ne peut pas, par exemple, trouver une section de mémoire marqué pour écrasement mais non encore effacée, et qui peut contenir des informations importantes. TCP/IP contient quelques démons sécurisés et de nombreux démons non sécurisés. On trouve parmi les démons sécurisés : • ftpd • rexecd • telnetd On trouve parmi les démons non sécurisés : • rshd • rlogind • tftpd Pour qu’un système soit sécurisé, il doit fonctionner avec une base informatique sécurisée, c’est à dire que pour un hôte unique, le poste doit être sécurisé. Sur un réseau, tous les serveurs de fichiers, passerelles et autres hôtes doivent être sécurisés. Base NTCB La base NTCB (Network Trusted Computing Base) associe logiciels et matériels pour protéger le réseau. Cette section définit les différents composants de la base NTCB en relation avec TCP/IP. Les dispositifs matériels sont fournis par les cartes réseau utilisées avec TCP/IP. Ces cartes contrôlent les données entrantes en ne recevant que des données destinées au local system et diffusent les données pouvant être reçues par tous les systèmes. Le module logiciel de NTCB est constitué exclusivement de programmes sécurisés. Les programmes et fichiers associés sont indiqués ci–dessous (par répertoires). Répertoire /etc 9-8 Nom Propriétaire Groupe Mode Droits gated.conf root system 0664 rw–rw–r–– gateways root system 0664 rw–rw–r–– hosts root system 0664 rw–rw–r–– hosts.equiv root system 0664 rw–rw–r–– inetd.conf root system 0644 rw–r––r–– named.conf root system 0644 rw–r––r–– named.data root system 0664 rw–rw–r–– networks root system 0664 rw–rw–r–– protocols root system 0644 rw–r––r–– rc.tcpip root system 0774 rwxrwxr–– Guide de sécurité resolv.conf root system 0644 rw–rw–r–– services root system 0644 rw–r––r–– 3270.keys root system 0664 rw–rw–r–– 3270keys.rt root system 0664 rw–rw–r–– Nom Propriétaire Groupe Mode Droits host root system 4555 r–sr–xr–x hostid bin bin 0555 r–xr–xr–x hostname bin bin 0555 r–xr–xr–x finger root system 0755 rwxr–xr–x ftp root system 4555 r–sr–xr–x netstat root bin 4555 r–sr–xr–x rexec root bin 4555 r–sr–xr–x ruptime root system 4555 r–sr–xr–x rwho root system 4555 r–sr–xr–x talk bin bin 0555 r–xr–xr–x telnet root system 4555 r–sr–xr–x Répertoire /usr/bin Répertoire /usr/sbin Nom Propriétaire Groupe Mode Droits arp root system 4555 r–sr–xr–x fingerd root system 0554 r–xr–xr–– ftpd root system 4554 r–sr–xr–– gated root system 4554 r–sr–xr–– ifconfig bin bin 0555 r–xr–xr–x inetd root system 4554 r–sr–xr–– named root system 4554 r–sr–x–– ping root system 4555 r–sr–xr–x rexecd root system 4554 r–sr–xr–– route root system 4554 r–sr–xr–– routed root system 0554 r–xr–x––– rwhod root system 4554 r–sr–xr–– securetcpip root system 0554 r–xr–xr–– setclock root system 4555 r–sr–xr–x syslogd root system 0554 r–xr–xr–– talkd root system 4554 r–sr–xr–– telnetd root system 4554 r–sr–xr–– Sécurité TCP/IP 9-9 Répertoire /usr/ucb Nom Propriétaire Groupe Mode Droits tn root system 4555 r–sr–xr–x Répertoire /var/spool/rwho Nom Propriétaire Groupe Mode Droits rwho (répertoire) root system 0755 drwxr–xr–x Sécurité des données et protection des informations Le dispositif de sécurité sous TCP/IP ne chiffre pas les données transmises par le réseau. Il est donc recommandé de prendre des mesures pour prévenir tout risque de défaillance du système de sécurité pouvant révéler des mots de passe ou des informations confidentielles. L’utilisation de la fonction de sécurité TCP/IP dans un environnement relevant du ministère de la défense (Department of Defense DOD aux États–Unis) requiert la conformité aux normes de sécurité DOD 5200.5 et NCSD–11. Contrôle d’accès aux ports TCP en fonction de l’utilisateur, avec le contrôle d’accès discrétionnaire aux ports Internet L’accès discrétionnaire aux ports Internet (DACinet) permet le contrôle de l’accès aux ports TCP pour les communications entre hôtes AIX 5.2. AIX 5.2 peut utiliser un en–tête TCP supplémentaire pour transporter les informations sur les utilisateurs et les groupes. DACinet permet à l’administrateur du système de destination de contrôler l’accès en fonction du port de destination, de l’ID utilisateur d’origine et de l’hôte. La fonction DACinet lui permet aussi de réserver les ports locaux à l’utilisateur root. Les systèmes UNIX comme AIX traitent les ports en dessous de 1024 comme des ports privilégiés qui ne peuvent être ouverts que par l’utilisateur root. AIX 5.2 permet d’y ajouter des ports au–dessus de 1024, ce qui empêche les autres utilisateurs d’exécuter des serveurs sur des ports connus. Selon les paramètres, un système non DACinet peut ou non se connecter à un système DACinet. L’accès est refusé dans l’état initial de la fonction DACinet. Une fois la fonction DACinet activée, il est impossible de la désactiver. La commande dacinet accepte des adresses spécifiés sous forme de noms d’hôtes, adresses d’hôtes en notation décimale à point, ou adresses réseau suivies de la longueur du préfixe réseau. L’exemple suivant spécifie un hôte unique par son nom d’hôte complet host.domain.org: host.domain.org L’exemple suivant spécifie un hôte unique par son adresse IP 10.0.0.1 : 10.0.0.1 L’exemple suivant spécifie le réseau entier dont la valeur des 24 premiers bits (la longueur du préfixe de réseau) est 10.0.0.0 : 10.0.0.0/24 Ce réseau comprend toutes les adresses IP entre 10.0.0.1 et 10.0.0.254. 9-10 Guide de sécurité Contrôle des accès aux services TCP DACinet utilise le fichier de démarrage /etc/rc.dacinet et les fichiers de configuration /etc/security/priv, /etc/security/services et /etc/security/acl. Les ports répertoriés dans le fichier /etc/security/services ne subissent pas de contrôles ACL Le fichier a le même format que /etc/services. La façon la plus facile de l’initialiser est de le copier depuis /etc vers /etc/security puis de supprimer tous les ports pour lesquels des ACL sont à appliquer. Les ACL sont stockés à deux endroits. Les ACL actives sont stockées dans le noyau et peuvent être lues à l’aide de la commande dacinet aclls. Les ACL qui seront réactivées au prochain démarrage par /etc/rc.tcpip sont stockées dans /etc/security/acl. Le format suivant est utilisé : service host/prefix–length [user|group] Où le service peut être spécifié numériquement ou comme dans la liste dans /etc/services, l’hôte peut recevoir un nom d’hôte ou une adresse réseau avec un masque de sous–réseau et l’utilisateur ou le groupe est indiqué à l’aide du préfixe u: ou g: En l’absence d’indication d’utilisateur ou de groupe, l’ACL ne prend en compte que l’hôte émetteur. Le préfixe – désactive explicitement l’accès au service. Les ACL sont évaluées dans l’ordre de leur mention. Vous pouvez donc spécifier l’accès pour un groupe d’utilisateurs, mais le refuser explicitement pour un utilisateur du groupe en plaçant la règle de cet utilisateur devant la règle du groupe. Le fichier /etc/services comprend deux entrées avec des numéros de ports non pris en charge par AIX 5.2. L’administrateur système doit retirer ces deux lignes du fichier avant d’exécuter la commande mkCCadmin. Supprimez les lignes suivantes du fichier /etc/services . sco_printer sco_s5_port 70000/tcp 70001/tcp sco_spooler # For System V print IPC lpNet_s5_port # For future use Exemples d’utilisation de DACinet Lorsque vous utilisez DACinet pour réserver l’accès au port entrant TCP/25 aux utilisateurs root, seuls les utilisateurs root des autres hôtes AIX 5.2 peuvent y accéder, ce qui limite les possibilités des autres utilisateurs d’usurper des courriers électroniques par une commande telnet sur le port TCP/25 de la victime. L’exemple suivant indique comment configurer le protocole X (X11) pour un accès root uniquement. Vérifiez que l’entrée X11 est retirée de /etc/security/services, de sorte que les ACL s’appliqueront à ce service. Par exemple, pour un sous–réseau 10.1.1.0/24 pour tous les systèmes connectés, les entrées ACL pour limiter l’accès aux utilisateurs root uniquement pour X (TCP/6000) dans /etc/security/acl seraient : 6000 10.1.1.0/24 u:root Pour limiter le service Telnet aux utilisateurs du groupe friends, quel que soit leur système d’origine, utilisez l’ACL suivante après avoir supprimé l’entrée telnet de /etc/security/services: telnet 0.0.0.0/0 g:friends Pour empêcher l’utilisateur fred d’accéder au serveur web, mais autoriser tous les autres à y accéder : –80 80 0.0.0.0/0 u:fred 0.0.0.0/0 Sécurité TCP/IP 9-11 Ports privilégiés pour l’exécution des services locaux Normalement, tout utilisateur peut ouvrir chaque port au–dessus du 1024. Par exemple, un utilisateur pourrait placer un serveur sur le port 8080, souvent utilisé pour l’exécution d’une proxy Web, ou sur le 1080, qui héberge généralement un serveur SOCKS. Certains ports peuvent être désignés comme privilégiés afin d’éviter que les tous les utilisateurs puissent y exécuter des serveurs. La commande dacinet setpriv permet d’ajouter des ports privilégiés au système exécuté. Les ports désignés en tant que privilégiés au démarrage du système doivent être répertoriés dans le fichier /etc/security/priv Les ports peuvent être placés dans ce fichier sous leur nom symbolique défini dans /etc/services, ou en indiquant leur numéro. Les entrées suivantes empêchent les utilisateurs autres que root d’exécuter des serveurs SOCKS ou Lotus Notes sur leurs ports habituels : 1080 lotusnote Remarque : Cette fonction n’empêche pas l’utilisateur d’exécuter les programmes. Elle l’empêche seulement d’exécuter les services sur les ports connus où ils sont généralement placés. Pour plus d’informations sur la commande dacinet, consultez le manuel AIX 5L Version 5.2 Commands Reference. 9-12 Guide de sécurité Deuxième partie. Sécurité réseau et Internet La deuxième partie du présent manuel fournit des informations relatives aux mesures de sécurité réseau et Internet. Ces chapitres décrivent les procédures d’installation et de configuration de la sécurité IP, la procédure d’identification des services réseau obligatoires et facultatifs, l’audit et le contrôle de la sécurité réseau, etc. Sécurité réseau et Internet PART 2 - 1 PART 2 - 2 Guide de sécurité Chapitre 10. Services réseau Ce chapitre apporte des informations sur l’identification et la sécurisation des services réseau avec des ports de communication ouverts. Correspondance des Services réseau avec les ports de communication ouverts Les applications client–serveur ouvrent des ports de communication sur le serveur, afin que les applications puissent écouter les requêtes entrantes des clients. Les ports ouverts étant vulnérables aux attaques potentielles, identifiez les applications qui ont des ports ouverts et fermez les ports qui n’ont pas besoin de rester ouverts. Vous pourrez ainsi comprendre quels systèmes sont rendus disponibles à toute personne ayant accès à Internet. La procédure suivante identifie les ports ouverts : 1. Identifiez les services à l’aide de la commande netstat : # netstat –af inet Voici un exemple d’utilisation de cette commande. La dernière colonne indique l’état de chaque service. Les services qui attendent les connexions entrantes sont en état ECOUTE. Connexion Internet active (y compris serveurs) Proto File de réception File Adresse d’émission locale Adresse étrangère (état) tcp4 0 0 *.echo *.* LISTEN tcp4 0 0 *.discard *.* LISTEN tcp4 0 0 *.daytime *.* LISTEN tcp 0 0 *.chargen *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp4 0 0 *.telnet *.* LISTEN tcp4 0 0 *.smtp *.* LISTEN tcp4 0 0 *.time *.* LISTEN tcp4 0 0 *.www *.* LISTEN tcp4 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smux *.* LISTEN Services réseau 10-1 tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.login *.* LISTEN tcp4 0 0 *.shell *.* LISTEN tcp4 0 0 *.klogin *.* LISTEN udp4 0 0 *.kshell *.* LISTEN udp4 0 0 *.echo *.* udp4 0 0 *.discard *.* udp4 0 0 *.daytime *.* udp4 0 0 *.chargen *.* udp4 0 0 *.time *.* udp4 0 0 *.bootpc *.* udp4 0 0 *.sunrpc *.* udp4 0 0 255.255.255 *.* .255.ntp udp4 0 0 1.23.123.23 *.* 4.ntp udp4 0 0 localhost.d *.* omain.ntp udp4 0 0 name.domain *.* ..ntp .................................... 2. Ouvrez le fichier /etc/services et contrôlez les services IANA (Internet Assigned Numbers Authority) pour faire correspondre le service aux numéros de ports du système d’exploitation. Voici une partie du fichier /etc/services : 10-2 tcpmux 1/tcp # TCP Port Service Multiplexer tcpmux 1/tcp # TCP Port Service Multiplexer Guide de sécurité Compressnet 2/tcp # Management Utility Compressnet 2/udp # Management Utility Compressnet 3/tcp # Compression Process Compressnet 3/udp Compression Process Echo 7/tcp Echo 7/udp discard 9/tcp sink null discard 9/udp sink null rfe 5002/tcp # Radio Free Ethernet rfe 5002/udp # Radio Free Ethernet rmonitor_secure 5145/tcp rmonitor_secure 5145/udp pad12sim 5236/tcp pad12sim 5236/udp sub–process 6111/tcp # HP SoftBench Sub–Process Cntl. sub–process 6111/udp # HP SoftBench Sub–Process Cntl. xdsxdm 6558/ucp xdsxdm 6558/tcp afs3–fileserver 7000/tcp # File Server Itself afs3–fileserver 7000/udp # File Server Itself .............. Services réseau 10-3 af3–callback 7001/tcp # Callbacks to Cache Managers af3–callback 7001/udp # Callbacks to Cache Managers 3. Fermez les ports non nécessaires en supprimant les services en cours. Identification des sockets TCP et UDP Identifiez les sockets TCP à l’état LISTEN et les sockets UDP inactifs (idle) en attente de données. Utilisez la commande lsof, une variante de la commande netstat –af. A partir d’AIX 5.1, la commande lsof est sur le CD AIX Toolbox for Linux Applications. Par exemple, pour afficher les sockets TCP à l’état LISTEN et les sockets UDP IDLE, lancez la commande lsof : # lsof –i | egrep ”COMMAND|LISTEN|UDP” Le résultat de cette commande se présente comme suit : Comma PID nde USER FD TYPE DEVICE SIZE/ OFF NODE NAME dtlogi n 2122 root 5u IPv4 0x7005 3c00 0t0 UDP *:xdmc p dtlogi n 2122 root 6u IPv4 0x7005 4adc 0t0 TCP *:3276 8(LIST EN) syslog d 2730 root 4u IPv4 0x7005 3600 0t0 UDP *:sysl og X 2880 root 6u IPv4 0x7005 4adc 0t0 TCP *:3276 8(LIST EN) X 2880 root 8u IPv4 0x7005 46dc 0t0 TCP *:6000 (LISTE N) dtlogi n 3882 root 6u IPv4 0x7005 4adc 0t0 TCP *:3276 8(LIST EN) glbd 4154 root 4u IPv4 0x7003 f300 0t0 UDP *:3280 3 glbd 4154 root 9u IPv4 0x7003 f700 0t0 UDP *:3280 5 dtgreet 4656 root 6u IPv4 0t0 TCP 0x7005 4adc .......... 10-4 Guide de sécurité *:3276 8(LIST EN) Une fois l’ID de processus identifié, vous pouvez obtenir plus d’informations sur le programme à l’aide de la commande suivante : ” # ps –fp PID# ” Le résultat contient le chemin vers le nom de la commande, que vous pouvez utiliser pour accéder à la page man du programme. Services réseau 10-5 10-6 Guide de sécurité Chapitre 11. Sécurité IP (Internet Protocol) Le protocole de sécurité IP permet de sécuriser les communications sur le réseau Internet et les réseaux d’entreprise, en protégeant le flux de données au niveau de la couche IP. Il permet de protéger l’échange de données pour toutes les applications, sans avoir à les modifier. Il sécurise ainsi la transmission de tout type de données, par exemple de messagerie électronique ou d’applications. Ce chapitre traite des points suivants : • Sécurité IP – Généralités, page 11-1 • Installation de la sécurité IP, page 11-6 • Planification de la sécurité IP, page 11-7 • Configuration d’un tunnel d’échange de clefs par Internet (IKE), page 11-17 • Utilisation des certificats numériques et du Key Manager, page 11-24 • Configuration de tunnels manuels, page 11-36 • Configuration des filtres, page 11-39 • Fonctions de journalisation, page 11-45 • Identification des incidents liés à la sécurité IP, page 11-50 • Informations de référence sur la fonction de sécurité IP, page 11-62 Sécurité IP – Généralités Cette section traite des points suivants : • Sécurité IP et système d’exploitation, page 11-1 • Fonctions de sécurité IP, page 11-2 • Liens de sécurité, page 11-3 • Gestion des clefs et tunnels, page 11-4 • Fonctions de filtrage natif, page 11-5 • Prise en charge des certificats numériques, page 11-6 • Avantages d’un VPN (Virtual Private Network), page 11-6 Sécurité IP et système d’exploitation Le système d’exploitation utilise la sécurité IP (IPsec), un standard ouvert développé par l’IETF (Internet Engineering Task Force). IPsec assure la protection par le chiffrement de toutes les données au niveau de la couche de communications IP. Aucune modification des applications n’est nécessaire. IPsec est l’ossature standard de sécurité réseau choisie par l’IETF pour IP versions 4 et 6. IPsec protège votre trafic de données grâce aux techniques suivantes de chiffrement : Authentification Processus consistant à vérifier l’identité d’un hôte ou d’un point d’extrémité Contrôle d’intégrité Processus consistant à vérifier qu’aucune modification des données n’est survenue au cours de leur transfert sur le réseau Sécurité IP (Internet Protocol) 11-1 Chiffrement Processus garantissant la confidentialité par le masquage des données et des adresses IP privées en transit sur le réseau Les algorithmes d’authentification fournissent la preuve de l’identité de l’expéditeur et de l’intégrité des données, en utilisant une fonction de chiffrement par hachage qui traite un paquet de données (y compris l’en–tête IP fixe) à l’aide d’une clef privée, afin d’en produire un condensé unique. Du côté du destinataire, les données sont traitées à l’aide de la même fonction et de la même clef. Si les données ont subi une altération ou si la clef de l’émetteur est incorrecte, le datagramme est supprimé. Le chiffrement fait appel à un algorithme et une clef pour modifier et rendre apparemment aléatoires les données, qui se transforment ainsi en texte chiffré. Ces données en cours de transfert sont incompréhensibles. Lorsqu’elles arrivent à destination, les données sont rétablies à l’aide du même algorithme et de la même clef (algorithmes de chiffrement symétriques). Le chiffrement doit être utilisé en conjonction avec l’authentification, de manière à vérifier l’intégrité des données chiffrées. Ces services de base sont implémentés dans IPsec au moyen de l’encapsulation IP ESP (Encapsulating Security Payload) et de l’en–tête d’authentification AH (Authentication Header). ESP assure la confidentialité par le chiffrement du paquet IP original, la création d’un en–tête ESP, et l’insertion des données chiffrées (le texte chiffré) dans le paquet ESP. Lorsque l’authentification et le contrôle d’intégrité des données sont requis, sans confidentialité, l’en–tête d’authentification (AH) peut être utilisé seul. Avec AH, les zones fixes de l’en–tête IP et les données sont traitées par un algorithme de hachage afin de générer un condensé codé. Le destinataire utilise sa clef pour calculer et comparer le condensé, afin de vérifier que le paquet n’a pas été modifié et que l’identité de l’émetteur ne fait aucun doute. Fonctions de sécurité IP La sécurité IP de ce système d’exploitation propose les fonctions suivantes : • Accélération matérielle avec la carte PCI Ethernet 10/100 Mbits/s type II. • En–tête d’authentification (AH) de la RFC 2402, encapsulation (ESP) de la RFC 2406. • Liste de révocation des certificats (CRL) avec extraction via des serveurs HTTP ou LDAP. • Actualisation automatique des clefs à l’aide de tunnels utilisant le protocole IKE (Internet Key Exchange) de l’IETF. • Certificats numériques X.509 et clefs pré–partagées du protocole IKE, lors de la négociation des clefs. • Configuration des tunnels manuels pour garantir la compatibilité avec des systèmes qui ne prennent pas en charge les méthodes automatiques d’actualisation de clefs IKE, et pour l’utilisation de tunnels IP v6. • Utilisation des modes d’encapsulation Tunnel et Transport pour les tunnels hôte ou passerelle. • Algorithmes d’authentification HMAC (Hashed Message Authentication Code), MD5 (Message Digest 5) et HMAC SHA (Secure Hash Algorithm). • Algorithmes de chiffrement DES 56 bits (Data Encryption Standard) CBC (Cipher Block Chaining) avec IV 64 bits (initial vector), Triple DES, DES CBC 4 avec IV 32 bits. • Prise en charge de la double pile IP (IP v4 et v6). • Le trafic IP v4 et v6 peut être encapsulé et filtré. Les piles IP étant distinctes, la sécurité IP de chaque pile peut être configurée de manière indépendante. • Les tunnels IKE peuvent être créés à l’aide de fichiers de configuration Linux (AIX 5.1 et plus). 11-2 Guide de sécurité • Filtrage du trafic sécurisé et non sécurisé par un certain nombre de caractéristiques IP, telles que les adresses IP source et destination, l’interface, le protocole, les numéros de port, etc. • Génération et suppression automatique des règles de filtre avec la plupart des types de tunnels. • Utilisation de noms d’hôte pour l’adresse de destination lors de la définition des tunnels et des règles de filtre. Les noms d’hôte sont convertis automatiquement en adresses IP (si un DNS est disponible). • Journalisation des événements de sécurité IP dans syslog. • Utilisation des opérations de suivi système et de statistiques pour l’identification des incidents. • Les opérations par défaut définies par l’utilisateur lui permettent d’indiquer si le trafic doit faire l’objet d’une autorisation d’accès lorsqu’il ne correspond pas aux tunnels définis. Fonctions IKE (Internet Key Exchange) Les fonctions suivantes sont disponibles avec Internet Key Exchange (à partir d’AIX 4.3.2) : • Authentification avec clefs pré–partagées et signatures numériques X.509. • Utilisation du mode principal (identification du mode de protection) et du mode agressif. • Prise en charge des groupes Diffie Hellman 1, 2 et 5. • Chiffrement ESP pour DES, Triple DES, chiffrement Null ; authentification ESP avec HMAC MD5 et HMAC SHA1. • AH pour HMAC MD5 et HMAC SHA1. • IP versions 4 et 6. Liens de sécurité La communication sécurisée est s’appuie sur le concept de lien de sécurité. Les liens de sécurité associent un ensemble de paramètres de sécurité à un type de trafic. Avec des données protégées par IPsec, chaque direction et chaque type d’en–tête, AH ou ESP, a un lien de sécurité distinct. Le lien de sécurité comprend les informations suivantes : adresses IP des correspondants, identificateur unique SPI (Security Parameters Index), algorithmes sélectionnés et clefs d’authentification ou de chiffrement, et durée de vie des clefs. La figure suivante montre les liens de sécurité entre les hôtes A et B. Figure 6. Etablissement d’un tunnel sécurisé entre les hôtes A et B. Cette illustration présente un tunnel virtuel entre les hôtes A et B. Le lien de sécurité A est symbolisé par une flèche reliant l’hôte A à l’hôte B. Le lien de sécurité B est symbolisé par une flèche reliant l’hôte B à l’hôte A. Un lien de sécurité regroupe l’adresse de destination, le SPI, la clef, l’algorithme et le format de chiffrement, l’algorithme d’authentification et la durée de vie de la clef. Sécurité IP (Internet Protocol) 11-3 La gestion des clefs a pour objectif de négocier et générer des liens de sécurité pour la protection du trafic IP. Gestion des clefs et tunnels Pour définir une communication sécurisée entre deux hôtes, les liens de sécurité doivent être négociés et gérés lors de l’utilisation du tunnel. Les types de tunnels suivants sont pris en charge, et utilisent chacun une technique différente de gestion des clefs : • tunnels IKE (clefs dynamiques, norme IETF) • Tunnels manuels (statiques, clefs persistantes, norme IETF) Prise en charge du tunnel IKE Les tunnels IKE s’appuient sur la norme ISAKMP/Oakley (Internet Security Association and Key Management Protocol) développée par l’IETF. Dans ce protocole, les paramètres de sécurité sont négociés et actualisés, et les clefs sont échangées en toute sécurité. Les types d’authentification suivants sont pris en charge : clefs pré–partagées et signatures de certificats numériques X.509v3. La négociation s’effectue en deux phases. La première authentifie les correspondants et indique les algorithmes à utiliser pour sécuriser la communication de la deuxième étape. Au cours de la deuxième phase, les paramètres de sécurité IP à utiliser pour le transfert de données sont négociés. Les liens de sécurité et les clefs sont créés et échangés. Le tableau suivant montre les algorithmes d’authentification qui peuvent être utilisés avec les protocoles de sécurité AH et ESP pour les tunnels IKE. 11-4 Algorithme AH IP – v 4 & 6 ESP IP – v 4 & 6 HMAC MD5 X X HMAC SHA1 X X DES CBC 8 X Triple DES CBC X ESP Null X Guide de sécurité Prise en charge des tunnels manuels Les tunnels manuels fournissent la compatibilité amont, ainsi qu’avec des postes ne prenant pas en charge les protocoles de gestion de clefs IKE. L’inconvénient de ces tunnels manuels est que les valeurs de clefs sont statiques. Les clefs d’authentification et de chiffrement sont identiques pour toute la durée de vie du tunnel et doivent être mises à jour manuellement. Le tableau suivant montre les algorithmes d’authentification pouvant être utilisés avec les protocoles de sécurité AH et ESP pour les tunnels manuels. Algorithme AH IP – v 4 AH IP – v 6 ESP IP – v 4 ESP IP – v 6 HMAC MD5 X X X X HMAC SHA1 X X X X Triple DES CBC X X DES CBC 8 X X DES CBC 4 X X Grâce à l’efficacité de la sécurité de ses tunnels, IKE est la méthode de gestion des clefs la plus répandue. Fonctions de filtrage natif Le Filtrage est une fonction de base qui permet d’accepter ou de refuser les paquets entrants ou sortants en fonction de certains critères. L’utilisateur ou l’administrateur peut alors configurer l’hôte pour contrôler le trafic entre cet hôte et les autres. Le filtrage s’effectue à partir des propriétés des paquets, telles que les adresses source et de destination, la version IP (4 ou 6), les masques de sous–réseau, le protocole, le port, les propriétés de routage, la fragmentation, l’interface et la définition des tunnels. Les règles, ou règles de filtre, permettent d’associer certains trafics à un tunnel particulier. Dans une configuration de base pour tunnels manuels, lorsqu’un utilisateur définit un tunnel hôte à hôte, des règles de filtre sont générées automatiquement afin de canaliser tout le trafic de cet hôte vers le tunnel sécurisé. Si vous souhaitez avoir d’autres types de trafic plus spécifiques (sous–réseau à sous–réseau par exemple), vous pouvez modifier ou remplacer les règles de filtre pour autoriser un contrôle précis du trafic utilisant un tunnel particulier. Pour les tunnels IKE, les règles de filtre sont également générées automatiquement et insérées dans le tableau de filtre dès que le tunnel est activé. De même, lorsqu’un tunnel est modifié ou supprimé, les règles de filtre de ce tunnel sont automatiquement supprimées, ce qui simplifie considérablement la configuration de la sécurité IP et réduit le risque d’erreur humaine. Les définitions de tunnel peuvent être diffusées et partagées avec d’autres machines et pare–feu à l’aide d’utilitaires d’importation et d’exportation, ce qui contribue à simplifier l’administration d’un grand nombre de systèmes. Les règles de filtre associent des types particuliers de trafic à un tunnel, mais les données filtrées n’ont pas forcément besoin de passer par un tunnel. Ces règles permettent au système d’exploitation d’assurer des fonctions élémentaires de pare–feu pour les utilisateurs souhaitant limiter le flux de certains types de trafic avec leur machine. Ceci est particulièrement utile pour la gestion de machines au sein d’un réseau interne ou ne bénéficiant pas de la protection d’un pare–feu. Dans ce cas, les règles de filtre édifient une deuxième protection autour d’un groupe de machines. Dès que les règles de filtre sont générées, elles sont enregistrées dans un tableau puis chargées dans le noyau. Lorsqu’un échange de paquets se prépare sur le réseau, les règles de filtre sont successivement étudiées, de haut en bas, afin de déterminer si le prochain paquet doit être accepté, refusé ou envoyé via un tunnel. Les critères de la règle Sécurité IP (Internet Protocol) 11-5 et les caractéristiques des paquets sont confrontés jusqu’à ce qu’une concordance soit trouvée ou que la règle par défaut soit atteinte. La fonction de sécurité IP met également en œuvre un système de filtrage des paquets non sécurisés en fonction de critères définis par l’utilisateur avec une granularité élevée. Cela peut être utile pour le contrôle du trafic IP entre réseaux et postes n’exigeant pas le recours à la sécurité IP. Prise en charge des certificats numériques IPsec accepte les certificats numériques X.509 version 3. IBM Key Manager gère les demandes de certificat et la base de données de clefs, ainsi que d’autres fonctions administratives. Le fonctionnement des certificats numériques est décrit à la section Configuration des certificats numériques, page 11-24. IBM Key Manager et ses fonctions sont décrits à la section Utilisation d’IBM Key Manager, page 11-24 Virtual Private Networks (VPN) et sécurité IP Un réseau privé virtuel prolonge le réseau interne d’une entreprise sur un réseau public tel qu’Internet. Les VPN permettent d’échanger des informations via Internet, dans un tunnel privé, avec des utilisateurs distants, des succursales et des partenaires ou fournisseurs. L’accès à Internet par des prestataires de services Internet (ISP), via des lignes directes ou des numéros de téléphone locaux, permet d’économiser les coûteuses lignes spécialisées, les appels longue distance et les numéros gratuits. IPsec peut être utilisée pour une solution VPN, car c’est la structure de sécurité choisie par l’IETF pour les environnements IPv4 et 6, et aucune modification des applications n’est nécessaire. Une ressource recommandée pour la planification de la mise en œuvre d’un VPN dans AIX se trouve au chapitre 9 du manuel A Comprehensive Guide to Virtual Private Networks, Volume III: Cross–Platform Key and Policy Management, ISBN SG24–5309–00. Ce manuel est également disponible sur Internet à l’adresse suivante : http://www.redbooks.ibm.com/redbooks/SG245309.html. Installation de la sécurité IP La fonction de sécurité IP sous AIX s’installe et se charge séparément. Les fichiers à installer sont les suivants : • bos.net.ipsec.rte (environnement d’exécution pour l’environnement et les commandes du noyau de sécurité IP) • bos.msg.LANG.net.ipsec (où LANG correspond à la langue de votre choix, par exemple en_US) • bos.net.ipsec.keymgt • bos.net.ipsec.websm • bos.crypto–priv (fichier pour le chiffrement DES et Triple DES) Le fichier bos.crypto–priv se trouve dans Expansion Pack. Pour le support de signature numérique IKE, installez l’ensemble de fichiers gskit.rte (AIX Version 4.1) ou gskkm.rte (AIX 5.1) à partir de Expansion Pack. Une fois installée, la sécurité IP peut être chargée séparément pour IPv4 et IPv6, soit en suivant la procédure recommandée à la section Chargement de la fonction de sécurité IP, page 11-7, soit en utilisant la commande mkdev. 11-6 Guide de sécurité Chargement de la fonction de sécurité IP Attention : Le chargement de la sécurité IP active la fonction de filtrage. Avant le chargement, il est important de vérifier que les règles de filtre sont correctement créées. Sinon, toutes les communications extérieures peuvent être bloquées. Utilisez SMIT ou Web-based System Manager pour charger automatiquement les modules de sécurité IP au moment du démarrage de IP. De plus, SMIT et Web-based System Manager assurent que les extensions du noyau et les démons IKE sont chargés dans le bon ordre. Si le chargement s’est correctement déroulé, la commande lsdev indique que les unités de sécurité IP sont Available (disponibles). lsdev –C –c ipsec ipsec_v4 Available IP Version 4 Security Extension ipsec_v6 Available IP Version 6 Security Extension Une fois l’extension du noyau de sécurité IP chargée, vous pouvez configurer les tunnels et les filtres. Planification de la sécurité IP Avant de configurer IPsec, vous devez configurer les tunnels et les filtres. Si un seul tunnel est défini pour l’ensemble des échanges de données, les règles de filtre peuvent être générées automatiquement. Pour définir un système de filtres plus élaboré, les règles peuvent être configurées séparément. Vous pouvez configurer la sécurité IP à l’aide du plug–in réseau Web-based System Manager, du plug–in VPN ou du SMIT (System Management Interface Tool). Pour SMIT, vous bénéficiez des raccourcis suivants : smit ips4_basic Configuration de base pour la version 4 de IP smit ips6_basic Configuration de base pour la version 6 de IP Avant de configurer la sécurité IP sur votre site, vous devez définir la méthode à utiliser ; par exemple, l’utilisation de tunnels ou de filtres (ou les deux), le type de tunnel qui correspond le mieux à vos besoins, etc. Vous devez étudier les informations des sections suivantes avant de prendre de telles décisions : • Accélération matérielle, page 11-8 • Tunnels / Filtres, page 11-9 • Tunnels et liens de sécurité, page 11-11 • Choix d’un type de tunnel, page 11-15 • Utilisation d’IKE avec DHCP ou Dynamically Assigned Addresses (affectation dynamique des adresses), page 11-15 Sécurité IP (Internet Protocol) 11-7 Accélération matérielle La carte PCI Ethernet 10/100 Mbits/s type II (Code 4962) offre la sécurité IP. Elle est conçue assurer ces fonctions à la place du système d’exploitation AIX. Lorsque cette carte est présente dans le système AIX, la pile de sécurité IP en utilise les fonctions suivantes : • Chiffrement et déchiffrement à l’aide des algorithmes DES et Triple DES • Authentification à l’aide des algorithmes MD5 ou SHA–1 • Stockage des informations des liens de sécurité. Les fonctions de la carte sont utilisées à la place du logiciel. La carte PCI Ethernet 10/100 Mbits/s type II est disponible pour les tunnels manuels et IKE. L’accélération matérielle de la sécurité IP est disponible à partir du niveau 5.1.0.25 des ensembles de fichiers bos.net.ipsec.rte et devices.pci.1410ff01.rte. Le nombre de liens de sécurité entrants pouvant être traités par la carte réseau est limité. Pour le trafic sortant, tous les paquets qui utilisent une configuration prise en charge sont traités par la carte. Certaines configurations de tunnel ne peuvent pas être traitées. La carte PCI Ethernet 10/100 Mbits/s de type II prend en charge les éléments suivants : • Chiffrement DES, 3 DES ou NULL avec ESP • Authentification HMAC–MD5 ou HMAC–SHA–1 avec ESP ou AH, mais pas les deux. (si ESP et AH sont utilisés tous les deux, vous devez effectuer ESP en premier. Toujours vrai pour les tunnels IKE, mais l’utilisateur peut sélectionner l’ordre pour les tunnels manuels.) • Mode de transport et de tunnel • Déchargement de paquets IPv4 Remarque : La carte PCI Ethernet 10/100 Mbits/s type II ne peut pas traiter les paquets avec des options IP. Pour activer la sécurité IP avec la carte PCI Ethernet 10/100 Mbits/s type II, il faudra peut–être déconnecter l’interface réseau, puis activer la fonction de déchargement IPsec. Pour déconnecter l’interface réseau à l’aide de l’interface SMIT, procédez comme suit : 1. Connectez–vous en tant qu’utilisateur root. 2. Tapez smitty inet en ligne de commande puis appuyez sur Entrée. 3. Sélectionnez l’option Suppression d’un interface réseau puis appuyez sur Entrée. 4. Sélectionnez l’interface correspondant à la carte PCI Ethernet 10/100 Mbits/s type II puis appuyez sur Entrée. Pour activer la fonction de déchargement IPsec à l’aide de l’interface SMIT, procédez comme suit : 1. Connectez–vous en tant qu’utilisateur root. 2. Tapez smitty eadap en ligne de commande puis appuyez sur Entrée. 3. Sélectionnez Modification / Affichage des caractéristiques de l’option carte Ethernet puis appuyez sur Entrée. 4. Sélectionnez la carte PCI Ethernet 10/100 Mbits/s type II puis appuyez sur Entrée. 5. Définissez la zone Déchargement IPsec sur oui puis appuyez sur Entrée. Pour activer l’attribut de déchargement IPsec à partir de la ligne de commande, tapez : # ifconfig en 11-8 Guide de sécurité X detach Pour activer l’attribut de déchargement IPsec à partir de la ligne de commande, tapez ce qui suit : X # chdev –l ent –a ipsec_offload=yes Pour vérifier que l’attribut de déchargement IPsec a bien été activé, tapez ce qui suit sur la ligne de commande : X # lsattr –El ent detach Pour désactiver l’attribut de déchargement IPsec à partir de la ligne de commande, tapez ce qui suit : # chdev –l ent X –a ipsec_offload=no Avec la commande enstat, vous pourrez vous assurer que la configuration de votre tunnel utilise l’attribut de déchargement IPsec. La commande enstat montre toutes les statistiques des paquets IPsec reçus et transmis lorsque l’attribut déchargement IPsec est activé. Par exemple, pour une interface Ethernet ent1, tapez ce qui suit : # entstat –d ent1 Le résultat de cette commande se présente comme suit : . . . Carte PCI Ethernet 10/100 Mbps type II (1410ff01) – Statistiques spécifiques : –––––––––––––––––––––––––––––––––––––––––––– . . . Transmit IPsec packets: 3 Transmit IPsec packets dropped: 0 Receive IPsec packets: 2 Receive IPsec packets dropped: 0 Tunnels / Filtres La sécurité IP comporte deux parties distinctes, les tunnels et les filtres. Les tunnels ont besoin des filtres, mais les filtres peuvent se passer de tunnels. • Le filtrage est une fonction qui permet d’accepter ou de refuser les paquets entrants et sortants en fonction d’un certain nombre de critères, appelés règles. Ainsi, un administrateur peut configurer le système hôte afin de gérer l’échange de données entre cet hôte et d’autres systèmes hôtes. Le filtrage s’effectue à partir des propriétés des paquets, telles que les adresses source et de destination, la version IP (4 ou 6), les masques de sous–réseau, le protocole, le port, les propriétés de routage, la fragmentation, l’interface et la définition des tunnels. Ce filtrage s’effectue au niveau de la couche IP ; aucune modification ne s’impose donc au niveau des applications. • Les tunnels définissent un lien de sécurité entre deux systèmes hôtes. Ces liens de sécurité impliquent des paramètres de sécurité spécifiques qui sont partagés par les systèmes aux extrémités du tunnel. Le schéma suivant illustre la manière dont un paquet arrive de la carte réseau sur la pile IP. A partir de là, le module de filtrage est appelé pour déterminer si le paquet est autorisé ou refusé. Si un ID de tunnel est spécifié, le paquet subit un contrôle par rapport aux définitions de tunnel. Si la décapsulation du tunnel se déroule correctement, la paquet est transmis au protocole de la couche supérieure. Cette fonction s’effectue dans l’ordre inverse pour les paquets sortants. Le tunnel s’appuie sur une règle de filtre qui associe le paquet à un tunnel donné, mais la fonction de filtrage peut se produire sans transmission du paquet au tunnel. Sécurité IP (Internet Protocol) 11-9 Figure 7. Routage de paquet réseau Cette illustration présente le chemin emprunté par un paquet réseau. En provenance du réseau, le paquet entre dans la carte réseau. Il est ensuite acheminé vers la pile IP d’où il est envoyé pour aller dans le module filtre. Depuis le module filtre, le paquet est envoyé aux définitions de tunnel ou bien retourné vers la pile IP, qui le transmettra aux protocoles de la couche supérieure. 11-10 Guide de sécurité Tunnels et liens de sécurité Les tunnels servent à authentifier et/ou à chiffrer les données. Les tunnels sont définis en spécifiant un lien de sécurité entre deux systèmes hôtes. Le lien de sécurité définit les paramètres des algorithmes de chiffrement et d’authentification, et les caractéristiques du tunnel. Le schéma suivant présente un tunnel virtuel entre les hôtes A et B. Figure 8. Etablissement d’un tunnel sécurisé entre les hôtes A et B. Cette illustration présente un tunnel virtuel entre les hôtes A et B. Le lien de sécurité A est symbolisé par une flèche reliant l’hôte A à l’hôte B. Le lien de sécurité B est symbolisé par une flèche reliant l’hôte B à l’hôte A. Un lien de sécurité regroupe l’adresse de destination, le SPI, la clef, l’algorithme et le format de chiffrement, l’algorithme d’authentification et la durée de vie de la clef La valeur SPI (Security Parameter Index) et l’adresse de destination identifient un lien de sécurité unique. Ces paramètres sont nécessaires pour définir un tunnel de manière unique. Vous pouvez spécifier d’autres paramètres, comme l’algorithme de chiffrement, l’algorithme d’authentification, les clefs et la durée de vie, ou utiliser les valeurs par défaut. Remarques sur le tunnel Les tunnels IKE se distinguent des tunnels manuels dans la mesure où la politique de sécurité fait l’objet d’un processus distinct par rapport à la définition des points d’extrémité du tunnel. Dans IKE, le processus de négociation se divise en deux étapes. Chaque étape est appelée phase, et chaque phase peut avoir sa propre politique de sécurité. Lors du démarrage des négociations IKE, un tunnel sécurisé doit être défini. Cette étape est appelée phase de gestion des clefs ou phase 1. Lors de cette phase, chaque correspondant utilise des clefs pré–partagées ou des certificats numériques pour authentifier l’autre et transmettre les informations d’ID. Cette phase définit un lien de sécurité pendant lequel les deux correspondants déterminent les protections à appliquer pour communiquer en toute sécurité pendant la seconde phase. Cette phase crée un tunnel IKE ou de phase 1. La seconde étape est appelée phase de gestion de données ou phase 2. A l’aide du tunnel IKE, elle crée les liens de sécurité pour AH et ESP, lesquels protègent les échanges. La deuxième phase détermine également les données qui circuleront dans le tunnel de la sécurité IP. Par exemple, elle peut définir les éléments suivants : • Un masque de sous–réseau • Une plage d’adresse • Un numéro de port et un protocole Sécurité IP (Internet Protocol) 11-11 Figure 9. Processus de configuration du tunnel IKE Cette illustration présente les deux phases du processus de configuration d’un tunnel IKE. Dans certains cas, les extrémités du tunnel (IKE) de gestion des clefs seront identiques aux extrémités du tunnel (sécurité IP) de gestion des données. Les points d’extrémité du tunnel IKE sont les ID des postes exécutant les négociations. Les points d’extrémité du tunnel de la sécurité IP décrivent le type de trafic qui circule dans ce tunnel. Pour les tunnels hôte à hôte simples, dans lesquels tous les échanges entre deux tunnels sont protégés avec le même tunnel, les extrémités du tunnel des phases 1 et 2 sont identiques. Lorsque la négociation se déroule entre deux passerelles, ce sont elles les points d’extrémité du tunnel IKE, et les points d’extrémité du tunnel de la sécurité IP correspondent aux machines ou aux sous–réseaux (derrière les passerelles) ou bien à la plage d’adresses (derrière les passerelles) des utilisateurs du tunnel. 11-12 Guide de sécurité Paramètres et politique de la gestion des clefs La phase 1 (gestion des clefs) définit les paramètres suivants de la configuration d’un tunnel IKE : Tunnel (phase 1) de gestion des clefs Nom de ce tunnel IKE. Pour chaque tunnel, vous devez indiquer les extrémités de négociation. Ce sont les deux postes qui comptent envoyer et valider des messages IKE. Le nom du tunnel peut indiquer les extrémités telles que VPN Boston ou VPN Acme. Type d’identité de l’hôte Type d’ID qui sera utilisé lors d’un échange IKE. Le type et la valeur de l’ID doivent correspondre à la valeur de la clef pré–partagée afin de garantir une recherche correcte de clefs. Si un ID distinct est utilisé pour rechercher la valeur de clef pré–partagée, l’ID hôte est celui de la clef et son type est KEY_ID. Ce dernier est utile dans le cas d’un hôte ayant plusieurs valeurs de clefs pré–partagées. Identité de l’hôte Valeur de l’ID de l’hôte représenté en tant qu’adresse IP, un FQDN (fully qualified domain name), ou un utilisateur sur le FQDN (utilisateur@FQDN). Par exemple, [email protected]. Adresse IP Adresse IP de l’hôte distant. Cette valeur est nécessaire si le type d’ID de l’hôte est KEY_ID ou s’il ne correspond pas à un type pouvant être résolu en une adresse IP. Par exemple, si le nom d’utilisateur ne peut être résolu par le serveur de noms local, vous devez saisir l’adresse IP de la partie distante. Vous pouvez également créer une politique personnalisée en spécifiant les paramètres à utiliser lors de la négociation IKE. Par exemple, vous pouvez utiliser des politiques de gestion des clefs pour l’authentification via les clefs pré–partagées ou le mode signature. Pour la phase 1, l’utilisateur doit indiquer certaines propriétés de sécurité de gestion des clefs avec lesquelles l’échange doit se réaliser. Sécurité IP (Internet Protocol) 11-13 Paramètres et politique de la gestion des données Les paramètres de proposition de la gestion des données sont définis lors de la phase 2 de la configuration d’un tunnel IKE. Il s’agit des mêmes paramètres utilisés pour la sécurité IP dans les tunnels manuels ; ils identifient le type de protection à utiliser pour le trafic des données dans le tunnel. Vous pouvez démarrer plusieurs tunnels de phase 2 sous le même tunnel de phase 1. Les types d’ID de points d’extrémité suivants décrivent le type de données devant utiliser le tunnel de données de sécurité IP : 11-14 Host, Subnet ou Range Ces éléments précisent si le trafic de données empruntant le tunnel est destiné à un hôte, à un sous–réseau ou à une plage d’adresses. Host/Subnet ID Contient l’identité d’hôte ou de sous–réseau des systèmes locaux ou distants acheminant des données via ce tunnel. Détermine les ID envoyés au cours de la négociation de la phase 2 et les règles de filtres qui seront établies si la négociation se déroule correctement. Subnet mask Décrit toutes les adresses IP au sein du sous–réseau (par exemple, hôte 9.53.250.96 et masque 255.255.255.0) Starting IP Address Range Fournit l’adresse IP de début de la plage d’adresses qui utilisera le tunnel (par exemple, 9.53.250.96 de 9.53.250.96 à 9.53.250.93) Ending IP Address Range Fournit l’adresse IP de fin pour la plage d’adresses qui utilisera le tunnel (par exemple, 9.53.250.93 de 9.53.250.96 à 9.53.250.93) Port Décrit les données utilisant un numéro de port spécifique (par exemple, 21 ou 23) Protocol Décrit les données acheminées via un protocole spécifique (par exemple, TCP ou UDP). Détermine le protocole envoyé au cours de la négociation de phase 2 et les règles de filtres qui seront établies si la négociation se déroule correctement. Le protocole de l’extrémité locale doit correspondre à celui de l’extrémité distante. Guide de sécurité Choix d’un type de tunnel Le choix entre des tunnels manuels ou IKE dépend de la prise en charge du tunnel par le système distant situé à l’autre extrémité et du type de gestion de clef choisi. Nous vous recommandons les tunnels IKE (si disponibles) car ils assurent la négociation sécurisée des clefs et leur mise à jour. Ils bénéficient également des types d’en–tête de l’IETF, ESP et AH, et acceptent la protection contre les répétitions. Vous pouvez configurer le mode de signature pour permettre les certificats numériques. Si le système distant à l’autre extrémité utilise l’un des algorithmes nécessitant des tunnels manuels, utilisez les tunnels manuels. Ils garantissent une compatibilité avec un grand nombre d’hôtes. Mais comme les clefs sont statiques, difficiles à modifier et à mettre jour, elles ne sont pas aussi sûres. Les tunnels manuels peuvent être utilisés entre un hôte avec ce système d’exploitation et toute autre machine dotée de la sécurité IP, et proposant un ensemble commun d’algorithmes de chiffrement et d’authentification. Dans leur grande majorité, les fournisseurs proposent Keyed MD5 avec DES ou HMAC MD5 avec DES. Cette répartition fonctionne avec pratiquement toutes les implémentations d’IPsec. Lors de la configuration des tunnels manuels, la procédure varie selon que vous configurez le premier hôte du tunnel ou le deuxième, dont les paramètres doivent correspondre à la configuration du premier hôte. Si vous configurez le premier hôte, les clefs peuvent être générées automatiquement, et les algorithmes définis par défaut. Pour configurer le deuxième hôte, vous devez importer, si possible, les informations du tunnel à partir du système distant. Autre élément important : déterminer si le système distant est situé derrière un pare–feu. Si tel est le cas, la configuration doit comporter les informations sur le pare–feu en question. Utilisation d’IKE avec DHCP ou Dynamically Assigned Addresses (affectation dynamique des adresses) IPsec s’utilise couramment pour sécuriser un système d’exploitation lorsque les systèmes distants initialisent des sessions IKE avec un serveur, sans que leur identité puisse être liée à une adresse IP en particulier. C’est le cas dans un environnement LAN, lorsque vous utilisez IPsec pour vous connecter à un serveur et que vous souhaitez chiffrer les données. Il peut s’agir aussi de clients distants qui composent le numéro d’un serveur et utilisent soit un FQDN soit une adresse électronique (utilisateur@FQDN) pour identifier l’ID distant. Il est nécessaire d’utiliser un mode agressif dans le but de déterminer une politique reposant sur des informations explicites concernant l’identité distante. Dans ce cas, l’identité est envoyée dans le premier message de la négociation et peut être utilisée pour rechercher une politique dans la base de données de politiques de sécurité. Ce procédé garantit que seules les identités distantes spécialement nommées négocieront en utilisant le protocole IKE. Pendant la phase 2, lorsque les liens de sécurité IP sont créés pour chiffrer les échanges TCP ou UDP, un tunnel de gestion de clefs générique peut être configuré. Ainsi, toutes les requêtes authentifiées lors de la phase 1 utiliseront le tunnel générique pour la phase de Gestion des données définie, au cas où l’adresse IP ne serait pas configurée de façon explicite dans la base de données. Ceci permet à toute adresse de correspondre au tunnel générique et d’être utilisée aussi longtemps que la validation rigoureuse d’une sécurité reposant sur des clefs publiques aboutit pendant la phase 1. Utilisation de XML pour définir un tunnel générique de gestion des données Vous pouvez définir un tunnel générique de gestion des données à l’aide du format XML, compris par ikedb. Les tunnels génériques de gestion des données sont utilisés avec le DHCP. Le format XML utilise le nom IPSecTunnel pour ce que le Web-based System Manager appelle un tunnel de gestion des données (Data Management Tunnel). Dans d’autres contextes, on parle aussi de tunnel de phase 2. Un tunnel générique de gestion des données n’est pas un véritable tunnel, mais un IPSecProtection, utilisé si un message entrant de gestion des données (sous un tunnel spécifique de gestion des clefs) ne correspond à aucun tunnel défini pour ce tunnel de gestion des clefs. Il est utilisé Sécurité IP (Internet Protocol) 11-15 uniquement lorsque le système AIX est le répondant. L’indication d’un tunnel générique de gestion des données IPSecProtection est facultative. Le tunnel générique de gestion des données est défini dans l’élément IKEProtection, à l’aide de deux attributs XML, appelés IKE_IPSecDefaultProtectionRef et IKE_IPSecDefaultAllowedTypes. Tout d’abord, vous devez définir un IPSecProtection que vous utiliserez par défaut si aucun IPSecTunnel (tunnel de gestion des données) ne correspond. Un IPSecProtection utilisé par défaut doit avoir un IPSec_ProtectionName qui commence par _defIPSprot_. Allez ensuite sur le IKEProtection pour lequel vous souhaitez utiliser le IPSecProtection par défaut. Indiquez un attribut IKE_IPSecDefaultProtectionRef qui contient le nom du IPSec_Protection par défaut. Vous devez également indiquer une valeur pour l’attribut IKE_IPSecDefaultAllowedTypes dans ce IKEProtection. Une ou plusieurs des valeurs suivantes peuvent être attribuées (séparez les valeurs multiples par un espace) : Local_IPV4_Address Local_IPV6_Address Local_IPV4_Subnet Local_IPV6_Subnet Local_IPV4_Address_Range Local_IPV6_Address_Range Remote_IPV4_Address Remote_IPV6_Address Remote_IPV4_Subnet Remote_IPV6_Subnet Remote_IPV4_Address_Range Remote_IPV6_Address_Range Ces valeurs correspondent aux types d’ID indiqués par l’initiateur. Dans la négociation IKE, les ID actuels sont ignorés. Le IPSecProtection indiqué est utilisé si l’attribut IKE_IPSecDefaultAllowedTypes contient une chaîne commençant par Local_, correspondant au type d’ID local de l’initiateur, et une chaîne commençant par Remote_, correspondant à son type d’ID distant. En d’autres termes, vous devez avoir au minimum une valeur Local_ et une Remote_ pour chaque attribut IKE_IPSecDefaultAllowedTypes, pour pouvoir utiliser l’IPSec_Protection correspondant. Exemple Un initiateur envoie ce qui suit au système AIX dans un message de phase 2 (gestion des données) : local ID type: local ID: remote ID type: remote ID: remote netmask: IPV4_Address 192.168.100.104 IPV4_Subnet 10.10.10.2 255.255.255.192 Le système AIX ne dispose pas de tunnel de gestion des données correspondant à ces ID. Par contre, il a un IPSecProtection avec les attributs suivants : IKE_IPSecDefaultProtectionRef=”_defIPSprot_protection4” IKE_IPSecDefaultAllowedTypes=”Local_IPV4_Address Remote_IPV4_Address Remote_IPV4_Subnet Remote_IPV4_Address_Range” Le type d’ID local du message entrant, IPV4_Address, correspond à l’une des valeurs Local_ des types autorisés, Local_IPV4_Address. L’ID distant du message, IPV4_Subnet, correspond également à la valeur Remote_IPV4_Subnet. Par conséquent, la négociation du tunnel de gestion des données continuera avec _defIPSprot_protection4 en tant que IPSecProtection. Le fichier /usr/samples/ipsec/default_p2_policy.xml est un fichier XML définissant un IPSecProtection générique qui peut être utilisé comme exemple. 11-16 Guide de sécurité Configuration d’un tunnel d’échange de clefs par Internet (IKE) Cette section fournit des informations sur la configuration des tunnels d’échange de clefs par Internet (IKE) à l’aide de l’interface Web-based System Manager, du SMIT (System Management Interface Tool) ou de la ligne de commande. Utilisation de Web-based System Manager pour la configuration de tunnels IKE La section Utilisation de l’assistant de configuration de base, page 11-17, offre un moyen simple pour définir un tunnel IKE avec des clefs pré–partagées. Pour en savoir plus sur les options avancées, reportez–vous à la section Configuration avancée des tunnels IKE, page 11-18. Utilisation de l’assistant de configuration de base Web-based System Manager permet de définir un tunnel IKE utilisant la méthode d’authentification des clefs pré–partagées ou des certificats. Il ajoute au sous–système de sécurité IP de nouveaux tunnels IKE pour la gestion des clefs et des données, vous permet d’entrer un minimum de données et de choisir quelques options, et utilise les valeurs par défaut courantes pour des paramètres tels que la durée de vie du tunnel. Lors de l’utilisation de l’assistant de configuration de base, tenez compte des conditions suivantes : • Vous pouvez utiliser l’assistant uniquement pour la configuration du tunnel initial. Pour modifier, supprimer ou activer un tunnel, utilisez le plug–in Tunnel IKE ou la barre des tâches. • Le nom du tunnel doit être unique sur le système, mais peut être utilisé sur un système distant. A titre d’exemple, sur les systèmes local et distant, le nom du tunnel peut être hôteA_à_hôteB, mais les zones Adresse IP locale et Adresse IP distante (points d’extrémité) sont interverties. • Les tunnels des phases 1 et 2 sont définis avec les mêmes algorithmes de chiffrement et d’authentification. • La clef pré–partagée que vous entrez doit être en hexadécimal (sans 0x devant) ou en texte ASCII. • Si vous choisissez les certificats numériques comme méthode d’authentification, vous devez utiliser l’utilitaire Key Manager, page 11-24, pour créer un certificat numérique. • Le seul type d’ID de l’hôte accepté est IP Address. • Les noms attribués aux conversions et aux propositions que vous créez se terminent par le nom du tunnel défini par l’utilisateur. Vous pouvez examiner les conversions et les propositions dans Web-based System Manager grâce au VPN et au plug–in Tunnel IKE. Pour configurer un nouveau tunnel via l’assistant, procédez comme suit : 1. Ouvrez Web-based System Manager à l’aide de la commande wsm. 2. Sélectionnez le plug–in réseau. 3. Sélectionnez Virtual Private Networks (VPN) – Sécurité IP. 4. A partir de la zone Console, choisissez le dossier Tâches et procédure. 5. Sélectionnez Assistant de configuration de tunnel de base. Sécurité IP (Internet Protocol) 11-17 6. Pour configurer un tunnel IKE, cliquez sur Suivant dans l’écran Introduction de l’étape 1, puis suivez les instructions. L’aide en ligne est disponible. Une fois le tunnel défini via l’assistant, sa définition apparaît dans la liste des tunnels IKE de Web-based System Manager ; le tunnel peut être activé ou modifié. Configuration avancée des tunnels IKE Vous pouvez configurer séparément les tunnels de gestion des clefs et des données à l’aide des procédures suivantes. Configuration de tunnels de gestion des clefs Les tunnels IKE sont configurés à l’aide du Web–based System Manager. La procédure suivante permet d’ajouter un tunnel de gestion des clefs : 1. Ouvrez Web-based System Manager à l’aide de la commande wsm. 2. Sélectionnez le plug–in réseau. 3. Sélectionnez Virtual Private Networks (VPN) – Sécurité IP. 4. Dans la zone Console, choisissez Tâches et procédure. 5. Sélectionnez Lancer IPsec. Cette opération charge les extensions du noyau de sécurité IP et lance les démons isakmpd, tmd et cpsd. Un tunnel est créé grâce à la définition des points d’extrémité de gestion des clefs et de gestion des données ainsi qu’à la définition des conversions et propositions de sécurité associées. – La gestion des clefs est la phase d’authentification. Elle permet de définir un tunnel sécurisé pour la négociation, nécessaire avant que les paramètres de sécurité IP et les clefs ne soient calculés. – La gestion des données identifie le type de trafic admis sur un tunnel donné. Elle peut être configurée pour un seul hôte ou un groupe d’hôtes (à l’aide de sous–réseaux ou de plages d’adresses IP) en y associant un protocole et des numéros de port. Vous pouvez utiliser le même tunnel de gestion des clefs pour protéger plusieurs négociations de gestion de données et rafraîchissements de clefs, tant que ces opérations ont lieu entre les mêmes points d’extrémité (par exemple, entre deux passerelles). 6. Pour définir les points d’extrémité du tunnel de gestion des clefs, cliquez sur Tunnels d’échange de clefs par Internet (IKE) dans l’onglet Identification. 7. Entrez les informations relatives aux identités des systèmes qui font partie des négociations. Dans la plupart des cas, vous devez utiliser les adresses IP et créer une politique compatible avec la partie distante. Dans l’onglet Conversions, utilisez des conversions correspondantes des deux côtés, ou contactez l’administrateur de la partie distante pour définir une conversion correspondante. Vous pouvez créer une conversion qui comporte plusieurs choix pour plus de souplesse lors des opérations de proposition ou de correspondance. 8. Si vous utilisez des clefs pré–partagées pour l’authentification, entrez la clef pré–partagée dans l’onglet Clef. La valeur doit être identique sur le poste distant et sur le poste local. 9. Créez une conversion à associer à ce tunnel à l’aide du bouton Ajouter de l’onglet Conversions. Pour activer la prise en charge des certificats numériques et du mode signature, choisissez une méthode d’authentification Signature RSA ou Signature RSA avec vérification des listes CRL. 11-18 Guide de sécurité Pour de plus amples informations sur les certificats, reportez–vous à la section Utilisation des certificats numériques et du Key Manager, page 11-24. Configuration des tunnels de gestion des données Pour configurer les extrémités et les conversions du tunnel de gestion des données et effectuer la configuration du tunnel IKE, ouvrez le Web–based System Manager, en suivant la procédure décrite à la section Configuration de tunnels de gestion des clefs, page 11-18. Pour créer un tunnel de gestion des données, procédez comme suit : 1. Sélectionnez un tunnel de gestion des clefs puis définissez chaque option unique. Vous pouvez conserver la valeur par défaut de la plupart des options de gestion des données. 2. Vous devez spécifier les types de points d’extrémité tels que l’adresse IP, le sous–réseau ou la plage des adresses IP dans l’onglet Points d’extrémité. Vous pouvez sélectionner un numéro de port et un protocole, ou accepter les valeurs par défaut. 3. Dans l’écran Propositions, vous pouvez créer une nouvelle proposition en cliquant sur le bouton Ajouter ou sur OK. Si vous utilisez plusieurs propositions, vous pouvez utiliser les boutons Monter ou Descendre pour modifier l’ordre des recherches. Prise en charge des groupes Depuis AIX 5.1, la sécurité IP prend en charge le regroupement des ID IKE dans une définition de tunnel, pour associer plusieurs ID à une seule politique de sécurité sans avoir à créer des définitions de tunnels séparées. Le regroupement est particulièrement utile lors de la configuration de connexions à plusieurs hôtes distants, car cela permet d’éviter de configurer ou de gérer plusieurs définitions de tunnels. De plus, si une politique de sécurité doit être modifiée, il n’est pas nécessaire de modifier plusieurs définitions de tunnels. Un groupe doit être défini avant que son nom ne soit utilisé dans une définition de tunnel. La taille du groupe est limitée à 1 Ko. Un nom de groupe peut être utilisé dans les définitions des tunnels de gestion des clefs et des données, mais en tant que ID distant uniquement. Un groupe est composé d’un nom de groupe et d’une liste d’ID IKE et de types d’ID. Les ID peuvent être tous du même type ou un mélange des suivants : • Adresses IPv4 • Adresses IPv6 • FQDN • utilisateur@FQDN • Types de DN X500. Pendant une négociation de lien de sécurité, les ID dans un groupe sont recherchés dans l’ordre, jusqu’à la première correspondance. Vous pouvez utiliser Web-based System Manager pour définir un groupe à utiliser comme point d’extrémité distant d’un tunnel de gestion des clefs. Pour obtenir des informations sur la définition de groupes à partir de la ligne de commande, reportez–vous à la section Interface de ligne de commande pour la configuration d’un tunnel IKE, page 11-20. Pour définir un groupe à l’aide du Web–based System Manager, procédez comme suit : 1. Sélectionnez un tunnel de gestion des clefs dans le conteneur Tunnel IKE. 2. Ouvrez la boîte de dialogue propriétés. 3. Sélectionnez l’onglet Identification. 4. Choisissez définition de l’ID de groupe pour le type d’identité de l’hôte distant. 5. Activez le bouton Configuration de la définition de groupe puis entrez ses membres dans la fenêtre. Sécurité IP (Internet Protocol) 11-19 Utilisation de l’interface SMIT pour la configuration d’un tunnel IKE L’interface SMIT permet de configurer des tunnels IKE et d’effectuer des fonctions de base sur la base de données IKE. SMIT se sert des fonctions XML pour effectuer des ajouts, des suppressions et des modifications aux définitions de tunnel IKE. SMIT IKE permet de configurer rapidement des tunnels IKE et fournit des exemples de syntaxes XML utilisée pour créer des définitions de tunnel IKE tunnel. Les menus SMIT IKE permettent également de sauvegarder, restaurer et initialiser la base de données IKE. Pour configurer un tunnel IKE IPv4, utilisez le raccourci smitty ike4. Pour configurer un tunnel IKE IPv6, utilisez le raccourci smitty ike6. Les fonctions de la base de données IKE se trouvent dans le menu Configuration avancée de la sécurité IP. L’utilitaire Web-based System Manager permet de visualiser ou modifier toutes les entrées de la base de données IKE ajoutées avec le SMIT. Interface de la ligne de commande pour la configuration d’un tunnel IKE La commande ikedb, disponible depuis AIX 5.1, permet de récupérer, mettre à jour, supprimer, importer et exporter des informations dans la base de données IKE à l’aide d’une interface XML. La commande ikedb permet d’écrire sur (ajouter) ou de lire (récupérer) la base de données IKE. Le format d’entrée et de sortie est un fichier en XML (Extensible Markup Language). Le format d’un fichier XML est indiqué par son DTD (Définition de type de document). La commande ikedb permet de voir le DTD utilisé pour valider le fichier XML lors d’un ajout. La seule modification possible sur un DTD est l’ajout de déclarations d’entité, à l’aide de l’indicateur –e. Toute déclaration de DOCTYPE externe dans le fichier d’entrée XML sera ignorée et toute déclaration DOCTYPE interne peut engendrer une erreur. Les règles suivies pour interpréter le fichier XML à l’aide du DTD sont conformes au standard XML. Le fichier /usr/samples/ipsec est un exemple de fichier XML typique qui définit les scénarios de tunnel les plus courants. Pour obtenir des détails sur la syntaxe, reportez–vous à la description de la commande ikedb dans le manuel AIX 5L Version 5.2 Commands Reference. La commande ike permet de démarrer, arrêter et gérer les tunnels IKE. Elle commande permet également d’activer, supprimer ou répertorier les tunnels de sécurité IP et IKE. Pour obtenir des détails sur la syntaxe, reportez–vous à la description de la commande ike dans le manuel AIX 5L Version 5.2 Commands Reference. Les exemples suivants montrent comment utiliser ike, ikedb et d’autres commandes, pour configurer et vérifier l’état de votre tunnel IKE : 1. Pour lancer une négociation de tunnel (activation d’un tunnel) ou pour permettre au système de réception d’agir en tant que répondeur (selon le rôle spécifié), utilisez la commande ike associée à un numéro de tunnel : # ike cmd=activate numlist=1 Vous pouvez également utiliser des adresses IP ou d’ID distant comme dans l’exemple suivant : # ike cmd=activate remid=9.3.97.256 # ike cmd=activate ipaddr=9.3.97.100, 9.3.97.256 Le traitement des commandes pouvant prendre plusieurs secondes, le résultat est renvoyé après le début de la négociation. 2. Pour afficher l’état du tunnel, utilisez la commande ike de la manière suivante : # ike cmd=list Le résultat de cette commande se présente comme suit : Phase 1 Tunnel ID Phase 2 Tunnel ID [1] [1] Le résultat montre les tunnels des phases 1 et 2 actuellement actifs. 11-20 Guide de sécurité 3. Pour obtenir une liste plus détaillée du tunnel, utilisez la commande ike de la manière suivante : # ike cmd=list verbose Le résultat de cette commande se présente comme suit : Phase 1 Tunnel ID Local ID Type: Local ID: Remote ID Type: Remote ID: Mode: Security Policy: Role: Encryption Alg: Auth Alg: Hash Alg: Key Lifetime: Key Lifesize: Key Rem Lifetime: Key Rem Lifesize: Key Refresh Overlap: Tunnel Lifetime: Tunnel Lifesize: Tun Rem Lifetime: Status: Phase 2 Tunnel ID Local ID Type: Local ID: Local Subnet Mask: Local Port: Local Protocol: Remote ID Type: Remote ID: Remote Subnet Mask: Remote Port: Remote Protocol: Mode: Security Policy: Role: Encryption Alg: AH Transform: Auth Alg: PFS: SA Lifetime: SA Lifesize: SA Rem Lifetime: SA Rem Lifesize: Key Refresh Overlap: Tunnel Lifetime: Tunnel Lifesize: Tun Rem Lifetime: Assoc P1 Tunnel: Encap Mode: Status: 1 Fully_Qualified_Domain_Name bee.austin.ibm.com Fully_Qualified_Domain_Name ipsec.austin.ibm.com Aggressive BOTH_AGGR_3DES_MD5 Initiator 3DES–CBC Preshared Key MD5 28800 Seconds 0 Kbytes 28737 Seconds 0 Kbytes 5% 2592000 Seconds 0 Kbytes 2591937 Seconds Active 1 IPv4_Address 10.10.10.1 N/A any all IPv4_Address 10.10.10.4 N/A any all Oakley_quick ESP_3DES_MD5_SHA_TUNNEL_NO_PFS Initiator ESP_3DES N/A HMAC–MD5 No 600 Seconds 0 Kbytes 562 Seconds 0 Kbytes 15% 2592000 Seconds 0 Kbytes 2591962 Seconds 0 ESP_tunnel Active Sécurité IP (Internet Protocol) 11-21 4. Pour afficher les règles de filtres dans la table de filtre dynamique du tunnel IKE qui vient d’être activé, utilisez la commande lsfilt de la manière suivante : # lsfilt –d Le résultat de cette commande se présente comme suit : 1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 2 *** Dynamic filter placement rule *** no 0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 yes all any 0 any 0 both both no all packets 0 all *** Dynamic table *** 0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 500 eq 500 local both no all packets 0 0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no ah any 0 any 0 both inbound no all packets 0 0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no esp any 0 any 0 both inbound no all packets 0 1 permit 10.10.10.1 255.255.255.255 10.10.10.4 255.255.255.255 no all any 0 any 0 both outbound yes all packets 1 1 permit 10.10.10.4 255.255.255.255 10.10.10.1 255.255.255.255 no all any 0 any 0 both inbound yes all packets 1 Cet exemple présente un poste avec uniquement un tunnel IKE. La règle de l’emplacement du filtre dynamique (règle n°2 dans le résultat de cet exemple de la table statique) peut être déplacée pour contrôler l’emplacement en fonction des toutes les autres règles définies par l’utilisateur. Les règles de la table dynamique sont élaborées automatiquement au fur et à mesure que les tunnels sont négociés et les règles correspondantes sont insérées dans la table de filtrage. Ces règles peuvent être affichées mais ne sont pas modifiables. 5. Pour activer la journalisation des règles de filtres dynamiques, définissez l’option de journalisation de la règle n°2 sur yes, avec la commande chfilt suivante : # chfilt –v 4 –n 2 –l y Pour des informations détaillées sur la journalisation des échanges IKE, reportez–vous à la section Fonctions de journalisation, page 11-45. 6. Pour désactiver le tunnel, utilisez la commande ike comme suit : # ike cmd=remove numlist=1 7. Pour afficher les définitions du tunnel, utilisez la commande ikedb comme suit : # ikedb –g 8. Pour insérer des définitions dans la base de données IKE à partir d’un fichier XML généré par un poste homologue, et écraser tous les objets de même noms, utilisez la commande ikedb comme suit : # ikedb –pFs peer_tunnel_conf.xml Le peer_tunnel_conf.xml correspond au fichier XML généré par un poste homologue. 9. Pour obtenir la définition du tunnel de la phase 1 appelé tunnel_sys1_and_sys2, et de tous les tunnels dépendants de la phase 2 avec leurs propositions et protections respectives, utilisez la commande ikedb comme suit : # ikedb –gr –t IKETunnel –n tunnel_sys1_and_sys2 11-22 Guide de sécurité 10.Pour supprimer toutes les clefs pré–partagées de la base de données, utilisez la commande ikedb comme suit : # ikedb –d –t IKEPresharedKey Pour obtenir des informations générales sur la prise en charge du groupe de tunnel IKE, reportez–vous à la section Prise en charge des groupes, page 11-19. La commande ikedb permet de définir des groupes à partir de la ligne de commande. Ressemblances entre IKE et Linux sous AIX Pour configurer un tunnel IKE sous AIX à l’aide de fichiers de configuration Linux (AIX versions 5.1 et ultérieures), utilisez la commande ikedb avec l’indicateur –c (option de conversion), ce qui vous permet d’utiliser les fichiers de configuration Linux /etc/ipsec.conf et /etc/ipsec.secrets comme définitions de tunnels IKE. La commande ikedb analyse les fichiers de configuration Linux, crée un fichier XML et ajoute éventuellement les définitions du tunnel XML à la base de données IKE. Les définitions de tunnels peuvent ensuite être affichées à l’aide de la commande ikedb –g ou de Web–based System Manager. Scénarios de configuration d’un tunnel IKE Les scénarios suivants décrivent le type de situations les plus rencontrées lors de la configuration de tunnels. Ces scénarios peuvent être décrits comme des cas de succursales, de partenaires et d’accès à distance. • Dans le cas de succursales, le client souhaite connecter ensemble deux réseaux sécurisés : les services d’ingénierie de deux sites différents. Dans cet exemple, des passerelles sont connectées entre elles et tous les échanges qui circulent entre elles utilisent le même tunnel. Quelle que soit l’extrémité du tunnel, les échanges sont décapsulés et transférés en clair sur l’Intranet. Dans la première phase de la négociation IKE, le lien de sécurité est créé entre les deux passerelles. Les échanges qui circulent dans le tunnel de sécurité IP se font entre deux sous–réseaux. Les ID des sous–réseaux sont utilisés dans la négociation de phase 2. Un numéro de tunnel est créé dès qu’une politique de sécurité et des paramètres sont créés pour ce tunnel. Utilisez la commande ike pour démarrer le tunnel. • Dans le cadre d’un partenariat, les réseaux ne sont pas sécurisés et l’administrateur peut vouloir limiter l’accès à un petit nombre d’hôtes derrière la passerelle de sécurité. Dans ce cas, le tunnel entre les hôtes transporte le trafic protégé par la sécurité IP et circulant entre deux hôtes donnés. Le protocole du tunnel de phase 2 est AH ou ESP. Ce tunnel hôte à hôte est établi à l’intérieur d’un tunnel passerelle à passerelle. • Dans le cas de l’accès à distance, les tunnels sont configurés à la demande et un niveau de sécurité élevé est appliqué. Les adresses IP n’étant pas forcément significatives, il est préférable d’adopter des noms de domaines complets ou des adresses de type utilisateur@nom_de_domaine_complet. Vous avez la possibilité d’utiliser KEYID pour associer une clef à un ID d’hôte. Sécurité IP (Internet Protocol) 11-23 Utilisation des certificats numériques et du Key Manager Les certificats numériques relient une identité et une clef publique, avec laquelle vous pouvez vérifier l’identité de l’expéditeur ou du destinataire d’un transfert chiffré. A partir de AIX 4.3.3, la sécurité IP utilise les certificats numériques pour activer le chiffrement par clef publique, connu également sous le nom de chiffrement asymétrique ; cette fonction chiffre les données en utilisant une clef privée connue uniquement par l’utilisateur, et les déchiffre en utilisant une clef publique (partagée) associée, issue d’une paire de clefs publique–privée. Les paires de clefs sont de longues chaînes de données qui sont des clefs de chiffrement. Dans le chiffrement par clef publique, cette clef publique est disponible à toute personne avec laquelle l’utilisateur souhaite communiquer. L’expéditeur appose une signature numérique à toutes les communications à l’aide de la clef privée correspondante. Le destinataire utilise la clef publique pour vérifier la signature de l’expéditeur. Si le message est déchiffré avec succès à l’aide de la clef publique, le destinataire peut vérifier l’authenticité de l’identité de l’expéditeur. Le chiffrement par clef publique fait appel à des entités tierces accréditées, connues sous le nom d’autorités d’accréditation (CA), pour l’émission de certificats numériques fiables. C’est le destinataire qui indique quels sont les organisations ou organismes émetteurs accrédités. Le certificat est émis pour une période de temps définie ; après sa date d’expiration, il doit être remplacé. AIX 4.3.3 et les versions ultérieures incluent l’utilitaire IBM Key Manager, conçu pour la gestion des certificats numériques. Vous trouverez dans les sections suivantes des informations sur les certificats. Les tâches de gestion de ces certificats sont décrites à la section Utilisation des certificats numériques et du Key Manager, page 11-24. 11-24 Guide de sécurité Format des certificats numériques Le certificat numérique contient des informations spécifiques sur l’identité du propriétaire du certificat et sur l’autorité d’accréditation. Reportez–vous à la figure suivante pour l’illustration d’un certificat numérique. Figure 10. Contenus d’un certificat numérique Cette illustration présente les quatre parties d’un certificat numérique. En partant du haut, ce sont : nom spécifique (DN) du propriétaire, clef publique du propriétaire, nom spécifique de l’autorité d’accréditation (CA) et signature du CA. La liste suivante décrit plus en détail le contenu du certificat numérique : Nom spécifique (DN) du propriétaire Combinaison du nom usuel du propriétaire et du contexte (position) dans l’arborescence de répertoire. Dans l’exemple suivant, qui décrit une simple arborescence de répertoires, Prasad est le nom usuel du propriétaire et le contexte est country(pays)=US, organization(organisation)=ABC, lower organization(unité d’organisation)=SERV ; par conséquent le nom spécifique est : /C=US/O=ABC/OU=SERV/CN=prasad.austin.ibm.com Sécurité IP (Internet Protocol) 11-25 Figure 11. Exemple de Nom spécifique dérivé de l’arborescence de répertoires Cette illustration est une arborescence de répertoires avec en haut O=ABC et se divisant en deux parties au second niveau. Le second niveau contient OU=AIX et OU=Acctg sur des branches séparées ; chacune d’elles a une branche qui mène à une entité simple du dernier niveau. Le dernier niveau contient respectivement CN=Prasad et CN=Peltier. Clef publique du propriétaire Utilisée par les destinataires pour déchiffrer les données. Nom d’utilisateur supplémentaire Il s’agit d’un ID tel qu’une adresse IP, une adresse électronique, un nom de domaine complet, etc. Date d’émission Date à laquelle le certificat numérique a été émis. Date d’expiration Date à laquelle le certificat numérique expire. Nom spécifique (DN) de l’émetteur Nom spécifique de l’autorité d’accréditation (CA). Signature numérique de l’émetteur Signature numérique utilisée pour valider un certificat. Remarques sur la sécurité des certificats numériques La présence du certificat numérique n’est pas une preuve d’identité. Le certificat numérique permet uniquement de vérifier l’identité du propriétaire d’un certificat numérique en fournissant une clef publique nécessaire pour contrôler la signature numérique du propriétaire. L’envoi de votre clef publique à un correspondant ne comporte aucun risque car vos données ne peuvent pas être déchiffrées sans l’autre partie de la paire de clefs, à savoir la clef privée. Par conséquent, le propriétaire doit protéger la clef privée associée à la clef publique du certificat numérique. Toutes les communications du propriétaire d’un certificat numérique peuvent être déchiffrées si la clef privée est disponible. Sans la clef privée, l’utilisation illicite du certificat numérique est quasiment impossible. 11-26 Guide de sécurité Autorités d’accréditation et hiérarchies sécurisées Un certificat numérique est aussi fiable que l’autorité d’accréditation (CA) qui l’émet. Il faut donc bien comprendre les politiques d’émission des certificats qui font partie des mécanismes d’accréditation. Chaque organisation ou utilisateur doit déterminer quelles autorités d’accréditation sont fiables. L’utilitaire IBM Key Manager permet également de créer vos propres certificats auto–signés, qui peuvent être utiles pour les tests ou les environnements composés d’un nombre réduit d’utilisateurs ou de machines. Si vous utilisez un service de sécurité, vous devez connaître ses clefs publiques pour obtenir et valider tout certificat numérique. En outre, le fait de recevoir un certificat numérique ne garantit pas son authenticité. Pour en vérifier l’authenticité, vous devez détenir la clef publique de l’autorité d’accréditation qui a émis ce certificat numérique. Si vous ne possédez pas déjà une copie accréditée de la clef publique, vous devez vous procurer un certificat numérique supplémentaire pour obtenir la clef publique de l’autorité d’accréditation (CA). Listes de révocation des certificats (CRL) Un certificat numérique est supposé s’utiliser tout au long de sa période de validité. Cependant, il peut s’avérer nécessaire d’invalider un certificat avant sa date d’expiration. C’est le cas si par exemple, un employé quitte la société ou si la confidentialité d’une clef privée a été compromise. Pour invalider un certificat, vous devez informer l’autorité d’accréditation (CA) appropriée sur les circonstances. Lorsqu’une CA révoque un certificat, elle ajoute son numéro de série à la liste de révocation des certificats (CRL). Les CRL sont des structures de données signées, délivrées périodiquement et disponibles dans une base de données publique. Les CRL peuvent être récupérées à partir de serveurs HTTP ou LDAP. Chaque CRL contient l’horodatage en cours et un horodatage nextUpdate de prochaine mise à niveau. Dans la liste, chaque certificat révoqué est identifié par son numéro de série. Si vous utilisez les certificats numériques comme méthode d’authentification pour configurer un tunnel IKE, vous pouvez contrôler leur validité en sélectionnant Signature RSA avec vérification des listes CRL. Si la vérification CRL est activée, la liste est localisée et vérifiée lors de la négociation pour établir le tunnel de gestion des clefs. Remarque : Pour utiliser cette fonction de la sécurité IP, le système doit être configuré pour un serveur SOCKS (version 4 pour les serveurs HTTP), LDAP ou les deux. Si vous savez quel type de serveur SOCKS ou LDAP sera utilisé pour obtenir les listes CRL, vous pouvez effectuer la configuration nécessaire avec le Web–based System Manager. Sélectionnez Configuration CRL dans le menu Certificats numériques. Utilisation des certificats numériques dans les applications Internet Les applications Internet qui utilisent les systèmes de chiffrement à clef publique doivent utiliser les certificats numériques pour obtenir les clefs publiques. Diverses applications utilisent le chiffrement par clef publique, y compris : Virtual Private Networks (VPN) Les réseaux privés virtuels (VPN) ou tunnels sécurisés, peuvent être configurés entre des systèmes tels que les pare–feu pour réaliser des connexions chiffrées entre des réseaux sécurisés, sur des liaisons de communication non sécurisées. Tout le trafic circulant sur ces réseaux et destiné à ces systèmes sera chiffré. Les protocoles utilisés dans la configuration des tunnels répondent aux normes de la sécurité IP et IKE, ce qui permet d’obtenir une connexion chiffrée entre un client distant (par exemple, une personne travaillant en télétravail) et un hôte ou réseau sécurisé. Sécurité IP (Internet Protocol) 11-27 Secure Sockets Layer (SSL) SSL est un protocole de sécurité qui assure la confidentialité et l’intégrité des communications. Il est utilisé par les serveurs Web pour sécuriser leurs connexions avec les navigateurs Web ; par les serveurs LDAP (Lightweight Directory Access Protocol) pour sécuriser leurs connexions avec leurs clients ; et par les serveurs Host–on–Demand V.2 pour les connexions entre le client et le système hôte. Le protocole SSL utilise les certificats numériques pour l’échange des clefs, l’authentification du serveur et éventuellement, pour l’authentification du client. Secure Electronic Mail Pour chiffrer et déchiffrer les messages électroniques, les systèmes de messages sécurisés, basés sur des normes telles que PEM ou S/MIME, utilisent les certificats numériques pour les signatures numériques et l’échange de clefs. Certificats numériques et demandes de certificats Un certificat numérique signé contient les parties suivantes : nom spécifique (DN) du propriétaire, clef publique du propriétaire, nom spécifique de l’autorité d’accréditation (CA) et signature du CA. Un certificat numérique auto–signé contient le nom spécifique, la clef publique et la signature de son propriétaire. Pour demander un certificat numérique, vous devez créer une demande de certificat et l’envoyer à une autorité d’accréditation (CA). La demande de certificat contient les parties suivantes : nom spécifique, clef publique et signature du demandeur. Le CA vérifie la signature du demandeur avec la clef publique du certificat numérique pour s’assurer des conditions suivantes : • La demande de certificat n’a pas été modifiée lors du transit entre le demandeur et le CA. • Le demandeur possède la clef privée correspondant à la clef publique incluse dans la demande de certificat. Le CA est également responsable de la vérification de certains aspects concernant l’identité du demandeur. Ce type de vérification peut varier d’une certitude quasi nulle à l’assurance absolue de l’identité du propriétaire. Utilitaire IBM Key Manager L’utilitaire IBM Key Manager gère les certificats numériques, et se trouve dans le fichier gskkm.rte sur l’Expansion Pack. Cette section décrit comment utiliser IBM Key Manager pour effectuer les tâches suivantes : 1. Création d’une base de données de clefs, page 11-29 2. Ajout de certificat numérique root d’une autorité d’accréditation, page 11-30 3. Etablissement de paramètres sécurisés, page 11-31 4. Suppression de certificat numérique root d’une autorité d’accréditation, page 11-31 5. Demande de certificat numérique, page 11-32 6. Ajout (Réception) d’un nouveau certificat numérique, page 11-32 7. Suppression d’un certificat numérique, page 11-33 8. Modification de mot de passe de la base de données, page 11-34 9. Création de tunnels IKE avec certificats numériques, page 11-34 Pour définir la prise en charge des certificats et de signatures numériques, les tâches 1, 2, 3, 4, 6 et 7 sont nécessaires. Ensuite, utilisez Web-based System Manager pour créer un tunnel IKE et associer une politique au tunnel qui utilise la méthode d’authentification Signature RSA. 11-28 Guide de sécurité Vous pouvez créer et configurer une base de données de clefs à partir de la fenêtre Présentation du VPN du Web-based System Manager en sélectionnant l’option Gestion des certificats numériques, ou en utilisant la commande certmgr pour ouvrir l’utilitaire Key Manager à partir de la ligne de commande. Création d’un base de données de clefs Une base de données de clefs autorise la connexion des points d’extrémité d’un VPN, à l’aide de certificats numériques valides. Les VPN d’IPsec utilisent le format de base de données de clef *.kdb. Les types de certificats d’autorité d’accréditation suivants sont fournis avec IBM Key Manager : • Autorité d’accréditation RSA Secure Server • Autorité d’accréditation Thawte Personal Premium • Autorité d’accréditation Thawte Personal Freemail • Autorité d’accréditation Thawte Personal Basic • Autorité d’accréditation Thawte Personal Server • Autorité d’accréditation Thawte Server • Autorité d’accréditation primaire Verisign de classe 1 • Autorité d’accréditation primaire Verisign de classe 2 • Autorité d’accréditation primaire Verisign de classe 3 • Autorité d’accréditation primaire Verisign de classe 4 Les signature de ces certificats numériques permet aux clients de se connecter aux serveurs qui possèdent des certificats numériques autorisés. Après avoir créé une base de données de clefs, vous pouvez l’utiliser pour vous connecter à un serveur possédant un certificat numérique signé par l’une de ces autorités d’accréditation. Pour utiliser un certificat numérique de signature qui n’est pas sur cette liste, vous devez en faire la demande auprès de l’autorité d’accréditation et l’ajouter à votre base de données de clefs. Reportez–vous à la section Ajout de certificat numérique root d’une autorité d’accréditation, page 11-30. Pour créer une base de données de clefs à l’aide de la commande certmgr, procédez comme suit : 1. Démarrez l’utilitaire IBM Key Manager en saisissant : # certmgr 2. Sélectionnez Nouveau (New) à partir du menu déroulant Fichier de base de données de clefs (Key Database File). 3. Dans la zone Type de base de données de clefs (Key database type), choisissez la valeur par défaut, Fichier de base de données de clefs CMS (CMS key database file). 4. Entrez ce nom dans la zone Nom de fichier : ikekey.kdb 5. Entrez le chemin de la base de données dans la zone Emplacement (Location) : /etc/security Remarque : La base de données de clefs doit être nommée ikekey.kbd et se trouver dans le répertoire /etc/security. Sinon, la sécurité IP ne fonctionne pas correctement. 6. Cliquez sur OK. L’invite Mot de passe s’affiche. Sécurité IP (Internet Protocol) 11-29 7. Entrez un mot de passe dans la zone correspondante, puis une nouvelle fois dans la zone Confirmation du mot de passe. 8. Si vous voulez changer le nombre de jours avant l’expiration du mot de passe, modifiez la zone Définir le délai d’expiration ?. La valeur par défaut est 60 jours. Si souhaitez que le mot de passe n’expire jamais, laissez vide la zone Définir le délai d’expiration ?. 9. Pour sauvegarder une version chiffrée du mot de passe dans un fichier stash, sélectionnez Enregistrer le mot de passe dans un fichier stash ? (Stash the password to a file?), et entrez–y oui (yes). Remarque : Vous devez effectuer cette action pour pouvoir utiliser les certificats numériques avec IPsec. 10.Cliquez sur OK. Un écran de confirmation s’affiche pour vous permettre de vérifier que vous avez créé une base de données de clefs. 11. Cliquez à nouveau sur OK pour voir s’afficher l’écran principal Gestion des clefs. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Ajout de certificat numérique root d’une autorité d’accréditation Une fois reçu le certificat numérique root de l’autorité d’accréditation, ajoutez–le à votre base de données. La plupart des certificats numériques root sont de type *.arm, comme suit : cert.arm Pour ajouter un certificat root d’autorité d’accréditation à une base de données, procédez de la manière suivante : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. A partir de l’écran principal, sélectionnez Ouvrir (Open) dans le menu déroulant Fichier de base de données de clefs. 3. Sélectionnez le fichier auquel vous souhaitez ajouter le certificat root d’autorité d’accréditation, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, et indique qu’il est ouvert et prêt à être utilisé. 5. Sélectionnez Certificats accrédités (Signer Certificates) dans le menu déroulant Certificats accrédités/personnels (Personal/Signer Certificates). 6. Cliquez sur Ajouter (Add). 7. Sélectionnez un type de données à partir du menu déroulant correspondant, par exemple : Base64–encoded ASCII data 8. Entrez un nom de fichier de certification et un chemin d’accès pour le certificat root d’autorité d’accréditation ou cliquez sur Parcourir (Browse) pour le sélectionner. 9. Cliquez sur OK. 10.Entrez le libellé du certificat root d’autorité d’accréditation, par exemple Tester un certificat root d’autorité d’accréditation (Test CA Root Certificate), puis cliquez sur OK. Vous êtes ramené à l’écran principal Gestion des clefs. La zone Certificats accrédités affiche désormais le libellé du certificat root de l’autorité d’accréditation que vous avez ajouté. Vous pouvez alors exécuter d’autres tâches ou quitter l’utilitaire. 11-30 Guide de sécurité Etablissement de paramètres sécurisés Les certificats d’autorité d’accréditation sont définis par défaut sur sécurisé (trusted). Pour modifier cette valeur, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Ouvrir dans le menu déroulant Fichier de la base de données de clefs. 3. Sélectionnez le fichier de base de données de clefs dont vous souhaitez modifier la valeur de certificat numérique par défaut, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, indiquant que le fichier est ouvert. 5. Sélectionnez Certificats accrédités à partir du menu déroulant Certificats accrédités/personnels. 6. Sélectionnez le certificat que vous souhaitez modifier, puis cliquez sur Affichage/Modification (View/Edit) ou double–cliquez sur l’entrée. L’écran Information sur les clefs s’affiche pour le certificat sélectionné. 7. Pour qu’il devienne un certificat root sécurisé, cochez la case située à côté de Définir le certificat en tant que root sécurisée (Set the certificate as a trusted root) puis cliquez sur OK. Si le certificat n’est pas sécurisé, décochez la case puis cliquez sur OK. 8. Cliquez sur OK dans l’écran Certificats accrédités. Vous êtes ramené à l’écran principal Gestion des clefs Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Suppression de certificat numérique root d’autorité d’accréditation Si vous ne souhaitez plus prendre en compte l’une des autorités d’accréditation de la liste des certificats numériques de signature, vous devez supprimer son certificat root d’autorité d’accréditation. Remarque : Avant de supprimer un certificat root d’autorité d’accréditation, créez une copie de sauvegarde au cas où vous souhaiteriez recréer la root de l’autorité d’accréditation. Pour supprimer de la base de données un certificat root d’autorité d’accréditation, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Ouvrir du menu déroulant Fichier de la base de données des clefs 3. Sélectionnez le fichier de base de données de clefs à partir duquel vous souhaitez supprimer le certificat root d’autorité d’accréditation, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, et indique qu’il est ouvert et prêt à être modifié. 5. Sélectionnez Certificats accrédités à partir du menu déroulant Certificats accrédités/personnels. 6. Sélectionnez le certificat que vous souhaitez supprimer, puis cliquez sur Supprimer (Delete) L’écran Confirmer votre choix ? (Confirm) s’affiche. 7. Cliquez sur Oui. Vous êtes ramené à l’écran principal Gestion des clefs Le libellé du certificat root d’autorité d’accréditation n’apparaît plus dans la zone Certificats accrédités. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Sécurité IP (Internet Protocol) 11-31 Demande de certificat numérique Pour obtenir un certificat numérique, générez une demande à l’aide d’IBM Key Manager et soumettez–la à une autorité d’accréditation. Le fichier de demande est au format PKCS#10. L’autorité d’accréditation vérifie votre identité, puis vous envoie un certificat numérique. Pour demander un certificat numérique, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Ouvrir dans le menu déroulant Fichier de la base de données de clefs 3. Sélectionnez le fichier de la base de données de clefs /etc/security/ikekey.kdb à partir duquel vous souhaitez générer la demande, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, et indique qu’il est ouvert et prêt à être modifié. 5. Sélectionnez Demandes de certificat personnel (Personal Certificate Requests) dans le menu déroulant Certificats accrédités/personnels (dans AIX Version 4.1) ou sélectionnez Création d’une> nouvelle demande de certificat (Create ––> New Certificate Request, à partir de AIX 5.1). 6. Cliquez sur Nouveau. 7. A partir de l’écran qui s’affiche, saisissez un libellé de clef (Key Label) pour le certificat numérique auto–signé, par exemple : cleftest 8. Entrez un Nom (Common Name, le nom hôte par défaut) et une Organisation, puis sélectionnez un Pays (Country). Pour les zones restantes, vous pouvez accepter la valeur par défaut ou choisir d’autres valeurs. 9. Définissez un nom d’utilisateur supplémentaire (Subject Alternate). Les zones en option associées au nom d’utilisateur supplémentaire sont l’adresse électronique, l’adresse IP et le nom DNS. L’adresse IP d’un type tunnel doit être identique à celle du tunnel IKE. Pour un utilisateur@FQDN de type ID de tunnel, complétez la zone de l’adresse électronique. Pour un FQDN de type ID de tunnel, entrez un nom de domaine complet (par exemple, nomhôte.nomsociété.com) dans la zone de nom DNS. 10.En bas de l’écran, entrez un nom pour le fichier, par exemple : certreq.arm 11. Cliquez sur OK. Un écran de confirmation s’affiche pour vous permettre de vérifier que vous avez créé une demande pour un nouveau certificat numérique. 12.Cliquez sur OK. Vous êtes ramené à l’écran principal Gestion des clefs La zone Demandes de certificat personnel affiche le libellé de clef de la demande de nouveau certificat numérique (PKCS#10). 13.Envoyez le fichier de demande à l’autorité d’accréditation. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Ajout (Réception) d’un nouveau certificat numérique Lorsque vous recevez le nouveau certificat numérique de l’autorité d’accréditation, vous devez l’ajouter à la base de données de clefs qui a servi à générer votre demande. Pour ajouter (recevoir) un nouveau certificat numérique, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Ouvrir dans le menu déroulant Fichier de la base de données de clefs 11-32 Guide de sécurité 3. Sélectionnez le fichier de la base de données de clefs à partir duquel vous avez généré la demande de certificat, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, et indique qu’il est ouvert et prêt à être modifié. 5. Sélectionnez Demandes de certificat personnel à partir du menu déroulant Certificats accrédités/personnels. 6. Cliquez sur Réception (Receive) pour ajouter à la base de données le nouveau certificat numérique reçu. 7. Sélectionnez le type de données du nouveau certificat numérique à partir du menu déroulant Type de données (Data type). La valeur par défaut est Base64–encoded ASCII data. 8. Entrez le nom du fichier de certification et le chemin d’accès du nouveau certificat numérique ou cliquez sur Parcourir pour le sélectionner. 9. Cliquez sur OK. 10.Entrez un libellé descriptif pour le nouveau certificat numérique, par exemple : Certificat VPN Branch 11. Cliquez sur OK. Vous êtes ramené à l’écran principal Gestion des clefs La zone Certificats personnels affiche désormais le libellé du nouveau certificat numérique que vous avez ajouté. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Si une erreur se produit lors du chargement du certificat, vérifiez que le fichier de certificat commence par –––––BEGIN CERTIFICATE––––– et se termine par –––––END CERTIFICATE–––––. Par exemple : –––––BEGIN CERTIFICATE––––– ajdkfjaldfwwwwwwwwwwadafdw kajf;kdsajkflasasfkjafdaff akdjf;ldasjkf;safdfdasfdas kaj;fdljk98dafdas43adfadfa –––––END CERTIFICATE––––– Si ce texte ne figure pas, modifiez le fichier de manière à ce qu’il commence et finisse correctement. Suppression de certificat numérique Remarque : Avant de supprimer un certificat numérique, créez une copie de sauvegarde au cas où vous souhaiteriez le créer à nouveau. Pour supprimer de la base de données un certificat numérique, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Ouvrir dans le menu déroulant Fichier de la base de données de clefs 3. Sélectionnez le fichier de base de données de clefs à partir duquel vous souhaitez supprimer le certificat numérique, puis cliquez sur Ouvrir. 4. Entrez le mot de passe, puis cliquez sur OK. Une fois le mot de passe accepté, l’écran principal Gestion des clefs s’affiche. La barre de titre affiche le nom du fichier de la base de données de clefs sélectionné, et indique qu’il est ouvert et prêt à être modifié. 5. Sélectionnez Demandes de certificat personnel à partir du menu déroulant Certificats accrédités/personnels. Sécurité IP (Internet Protocol) 11-33 6. Sélectionnez le certificat que vous souhaitez supprimer, puis cliquez sur Supprimer (Delete). L’écran Confirmer votre choix ? s’affiche. 7. Cliquez sur Oui. Vous êtes ramené à l’écran principal Gestion des clefs Le libellé du certificat numérique que vous venez de supprimer n’apparaît plus dans la zone Certificats personnels. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Modification de mot de passe de la base de données Pour modifier une base de données de clefs, procédez comme suit : 1. Si IBM Key Manager n’est pas démarré, faites–le en saisissant : # certmgr 2. Dans l’écran principal, sélectionnez Modification du mot de passe (Change Password) dans le menu déroulant Fichier de la base de données de clefs 3. Entrez un nouveau mot de passe dans la zone correspondante, puis une nouvelle fois dans la zone Confirmation du mot de passe. 4. Si vous voulez changer le nombre de jours avant l’expiration du mot de passe, changez–le dans la zone Définir le délai d’expiration ?. La valeur par défaut est 60 jours Si souhaitez que le mot de passe n’expire jamais, laissez vide la zone Définir le délai d’expiration ? 5. Pour sauvegarder une version chiffrée du mot de passe dans un fichier stash, sélectionnez Enregistrer le mot de passe dans un fichier stash ? (Stash the password to a file?), et entrez–y oui (yes) Remarque : Vous devez effectuer cette action pour pouvoir utiliser les certificats numériques avec IPsec 6. Cliquez sur OK. Un message dans la barre d’état indique que la demande a été prise en compte. 7. Cliquez à nouveau sur OK pour voir s’afficher l’écran principal Gestion des clefs. Vous pouvez alors exécuter une autre tâche ou quitter l’utilitaire. Création de tunnels IKE avec certificats numériques Pour créer des tunnels IKE qui utilisent les certificats numériques, vous devez vous servir du Web-based System Manager et de l’utilitaire IBM Key Manager. Pour activer l’utilisation de certificats numériques lors de la définition des politiques de gestion des clefs du tunnel IKE, vous devez configurer une conversion qui utilise un mode de signature. Un Mode de signature utilise un algorithme RSA de signature pour l’authentification. IPsec fournit la boîte de dialogue “ Ajout/Modification d’une conversion ” Web-based System Manager pour sélectionner une méthode d’authentification de signature RSA, ou de signature RSA avec vérification des listes CRL. Une extrémité au moins du tunnel doit posséder une politique utilisant une conversion de mode de signature. Vous pouvez également définir d’autres conversions utilisant le mode de signature avec Web–based System Manager. Les types de tunnels de gestion des clefs IKE (zone Type d’identité de l’hôte sur l’onglet Identification) pris en charge par IPsec sont les suivants : • adresse IP • FQDN (nom de domaine complet) • utilisateur@FQDN • DN X.500 (nom spécifique) • Identificateur de la clef 11-34 Guide de sécurité Utilisez Web–based System Manager pour sélectionner les types d’identité de l’hôte dans l’onglet Identification – Propriétés du tunnel de gestion des clefs. Si vous sélectionnez les options Adresse IP, FQDN ou utilisateur@FQDN, vous devez entrez les valeurs dans Web-based System Manager et les transmettre à l’autorité d’accréditation. Ces informations sont utilisées pour le Nom d’utilisateur supplémentaire dans le certificat numérique personnel. Par exemple, si vous choisissez un type d’identité de l’hôte de DN X.500 (nom spécifique) dans la liste déroulante de l’onglet Identification de Web-based System Manager, et que vous entrez /C=US/O=ABC/OU=SERV/CN= nom.austin.ibm.com dans la zone Identité de l’hôte, vous devrez utiliser les valeurs suivantes lors d’une demande de certificat numérique avec IBM Key Manager : • Common name: nom.austin.ibm.com • Organization: ABC • Organizational unit: SERV • Country : US La valeur de la zone DN X.500 (nom spécifique) doit correspondre au nom donné lors de la configuration par votre système ou administrateur LDAP. La valeur de l’unité d’organisation est facultative. L’autorité d’accréditation utilise alors cette information lors de la création de certificat numérique. Autre exemple : si vous choisissez le type d’identité hôte Adresse IP dans la liste déroulante et une valeur de 10.10.10.1 pour l’identité hôte, vous devrez entrer les valeurs suivantes lors de votre demande de certificat numérique : • Common name: nom.austin.ibm.com • Organization: ABC • Organizational unit: SERV • Country : US • Zone Subject alternate IP address: (adresse IP du nom supplémentaire) 10.10.10.1 Une fois ces informations entrées dans le certificat numérique, l’autorité d’accréditation les utilise pour créer un certificat numérique personnel. Lors d’une demande de certificat numérique, l’autorité d’accréditation a besoin des informations suivantes : • Vous demandez un certificat X.509. • Le format de signature MD5 avec chiffrement RSA. • Si vous indiquez ou non un nom d’utilisateur supplémentaire. Les types de noms supplémentaires sont : – adresse IP – FQDN (Fully qualified domain name) – utilisateur@FQDN Les informations suivantes relatives au nom d’utilisateur supplémentaire sont comprises dans le fichier de demande de certificat. • L’utilisation prévue pour la clef (le bit de signature numérique doit être défini). • Le fichier de demande de certificat numérique d’IBM Key Manager (au format PKCS#10). Pour les tâches nécessitant l’utilisation du Key Manager pour créer une demande de certificat, reportez–vous à la section Demande de certificat numérique, page 11-32. Sécurité IP (Internet Protocol) 11-35 Avant d’activer le tunnel IKE, vous devez ajouter le certificat numérique personnel reçu de l’autorité d’accréditation dans la base de données d’IBM Key Manager, ikekey.kdb. Pour plus de détails, reportez–vous à la section Ajout (Réception) d’un nouveau certificat numérique, page 11-32. La sécurité IP prend en charge les types suivants de certificats numériques personnels : DN – Nom spécifique Le nom spécifique de l’utilisateur doit respecter le format et l’ordre suivant : /C=US/O=ABC/OU=SERV/CN= nom.austin.ibm.com L’utilitaire Key Manager ne permet qu’une seule valeur OU. DN (Nom spécifique) et Nom d’utilisateur supplémentaire comme valeur d’adresse IP Le nom spécifique et le nom de l’utilisateur supplémentaire peuvent constituer l’adresse IP, comme dans l’exemple suivant : /C=US/O=ABC/OU=SERV/CN=nom.austin.ibm.com et 10.10.10.1 DN et Nom d’utilisateur supplémentaire comme adresse FQDN Le nom spécifique et le nom de l’utilisateur supplémentaire peuvent constituer un nom de domaine complet, comme dans l’exemple suivant : /C=US/O=ABC/OU=SERV/CN=nom.austin.ibm.com et bell.austin.ibm.com. DN et Nom d’utilisateur supplémentaire comme utilisateur@FQDN Le nom spécifique et le nom d’utilisateur supplémentaire peuvent constituer une adresse utilisateur (ID_utilisateur@nom_de_domaine_complet), comme dans l’exemple suivant : /C=US/O=ABC/OU=SERV/CN=nom.austin.ibm.com et [email protected]. DN et noms multiples d’utilisateurs supplémentaires Le nom spécifique peut être associé à plusieurs noms d’utilisateurs supplémentaires, comme dans l’exemple suivant : /C=US/O=ABC/OU=SERV/CN=nom.austin.ibm.com et bell.austin.ibm.com, 10.10.10.1, et [email protected]. Configuration des tunnels manuels Les procédures suivantes permettent de configurer la sécurité IP pour l’utilisation des tunnels manuels. Configuration des tunnels et des filtres Pour installer un tunnel manuel, il n’est pas nécessaire de configurer séparément les règles de filtre. Si tout le trafic échangé entre les deux hôtes passe par le tunnel, les règles de filtre requises sont générées automatiquement. La procédure de configuration d’un tunnel consiste à définir le tunnel à une extrémité, importer la définition à l’autre extrémité, et à activer le tunnel et les règles de filtre aux deux extrémités. Le tunnel est alors prêt à l’utilisation. Les informations concernant le tunnel doivent être identiques aux deux extrémités si elles ne sont pas fournies de manière explicite. A titre d’exemple, les algorithmes de chiffrement et d’authentification spécifiés pour l’adresse source seront utilisés pour l’adresse de destination si les valeurs de destination ne sont pas spécifiées. 11-36 Guide de sécurité Création d’un tunnel manuel sur le premier hôte Vous pouvez utiliser l’application Web-based System Manager pour configurer un tunnel, le raccourci SMIT ips4_basic (pour IPv4), ou ips6_basic (pour IPv6). Vous pouvez également créer le tunnel manuellement à l’aide de la procédure suivante. L’exemple suivant illustre la commande gentun utilisée pour créer un tunnel manuel : gentun –v 4 –t manual –s 5.5.5.19 –d 5.5.5.8 \ –a HMAC_MD5 –e DES_CBC_8 –N 23567 Vous pouvez utiliser la commande lstun –v 4 pour recenser les caractéristiques du tunnel manuel créé dans l’exemple ci–dessus. Le résultat de cette commande se présente comme suit : Tunnel ID IP Version Source Destination Policy Tunnel Mode Send AH Algo Send ESP Algo Receive AH Algo Receive ESP Algo Source AH SPI Source ESP SPI Dest AH SPI Dest ESP SPI Tunnel Life Time Status Target Target Mask Replay New Header Snd ENC–MAC Algo Rcv ENC–MAC Algo : 1 : IP Version 4 : 5.5.5.19 : 5.5.5.8 : auth/encr : Tunnel : HMAC_MD5 : DES_CBC_8 : HMAC_MD5 : DES_CBC_8 : 300 : 300 : 23576 : 23576 : 480 : Inactive : – : – : No : Yes : – : – Pour activer le tunnel, tapez ce qui suit : mktun –v 4 –t1 Les règles de filtre associés au tunnel sont automatiquement générées. Pour afficher les règles de filtre, utilisez la commande lsfilt –v 4. Le résultat de cette commande se présente comme suit : Sécurité IP (Internet Protocol) 11-37 Rule 4 : Rule action Source Address Source Mask Destination Address Destination Mask Source Routing Protocol Source Port Destination Port Scope Direction Logging control Fragment control Tunnel ID number Interface Auto–Generated : : : : : : : : : : : : : : : : permit 5.5.5.19 255.255.255.255 5.5.5.8 255.255.255.255 yes all any 0 any 0 both outbound no all packets 1 all yes Rule 5 : Rule action Source Address Source Mask Destination Address Destination Mask Source Routing Protocol Source Port Destination Port Scope Direction Logging control Fragment control Tunnel ID number Interface Auto–Generated : : : : : : : : : : : : : : : : permit 5.5.5.8 255.255.255.255 5.5.5.19 255.255.255.255 yes all any 0 any 0 both inbound no all packets 1 all yes Pour activer les règles de filtre, y compris les règles de filtre par défaut, utilisez la commande mktun –v 4 –t 1. Pour configurer l’autre extrémité, lorsqu’il s’agit d’un autre poste utilisant ce système d’exploitation, la définition du tunnel peut être exportée depuis l’hôte A, puis importée sur l’hôte B. La commande suivante permet d’exporter la définition du tunnel dans un fichier nommé ipsec_tun_manu.exp, et ses règles de filtre associées dans le fichier ipsec_fltr_rule.exp, du répertoire indiqué par l’indicateur –f : exptun –v 4 –t 1 –f / tmp Création d’un tunnel manuel sur le second hôte Pour créer l’extrémité du tunnel correspondante, les fichiers d’exportation sont copiés et importés sur le système distant à l’aide de la commande : imptun –v 4 –t 1 –f / tmp où 1 Est le tunnel à importer / tmp Est le répertoire où se trouvent les fichiers importés Le numéro du tunnel est généré par le système. Vous pouvez l’obtenir à partir de la sortie de la commande gentun ou à l’aide de la commande lstun, qui répertorient les tunnels et indiquent le numéro du tunnel à importer. Si le fichier d’importation comporte un seul tunnel, ou si la totalité des tunnels doit être importée, l’option –t n’est pas nécessaire. Si le système distant ne fonctionne pas sous ce système d’exploitation, le fichier d’exportation peut servir de référence pour configurer l’algorithme, les clefs et les valeurs SPI de l’autre extrémité du tunnel. 11-38 Guide de sécurité Les fichiers exportés par un pare–feu peuvent être importés pour créer des tunnels. Pour ce faire, utilisez le paramètre –n lors de l’importation du fichier : imptun –v 4 –f / tmp –n Configuration des filtres Le filtrage peut être simple, utilisant en grande partie les règles de filtre générées automatiquement, ou élaboré en définissant des fonctions de filtre spécifiques à partir des propriétés des paquets IP. La mise en correspondance des paquets entrants s’effectue en comparant l’adresse source et de la valeur SPI avec les valeurs répertoriées dans la table des filtres. Cette paire doit donc être unique. Chaque ligne de la table des filtres est une règle. Une série de règles définit les paquets qui seront acceptés au départ et à l’arrivée du système, et leur mode de routage. Les règles de filtre peuvent contrôler différents aspects de la communication, y compris les adresses et les masques source et de destination, le protocole, le numéro de port, la direction, le contrôle des fragments, le routage source, le tunnel et l’interface. Les types de règles de filtre sont les suivants : • Les règles de filtre statiques, page 11-39, sont créées dans la table des filtres et sont destinées au filtrage général du trafic ou à l’association avec des tunnels manuels. Elles peuvent être ajoutées, supprimées, modifiées et déplacées. Une zone de texte de description peut être ajoutée pour identifier une règle spécifique. • Les règles de filtre générées automatiquement, et règles de filtre spécifiques à l’utilisateur, page 11-43, (également appelées règles de filtre générées automatiquement), sont un ensemble spécifique de règles créées pour l’utilisation des tunnels IKE. Les règles de filtre statiques et dynamiques reposent sur les informations et la négociation du tunnel de gestion des données. • Les règles de filtre prédéfinies, page 11-44, sont des règles de filtre génériques qui ne peuvent pas être modifiées, déplacées ni supprimées, par exemple tout le trafic (all traffic), ah et esp. Elles s’appliquent à l’ensemble du trafic. Les Masques de sous–réseau,page 11-44, dont les ID de groupe sont associés à une règle de filtre, et l’option de configuration hôte–pare–feu–hôte, page 11-44, sont associés à ces règles de filtre. Les sections suivantes décrivent les différents types de règles de filtre et les caractéristiques qui leur sont associées. Règles de filtre statiques Chaque règle de filtre statique contient plusieurs zones séparées par des espaces. La liste qui suit fournit le nom de chaque zone (avec entre parenthèses un exemple de la règle 1) : • Rule_number ( 1 ) • Action ( permit ) • Source_addr ( 0.0.0.0 ) • Source_mask ( 0.0.0.0 ) • Dest_addr ( 0.0.0.0 ) • Dest_mask ( 0.0.0.0 ) • Source_routing ( no ) • Protocol ( udp ) • Src_prt_operator ( eq ) • Src_prt_value ( 4001 ) • Dst_prt_operator ( eq ) Sécurité IP (Internet Protocol) 11-39 • Dst_prt_value ( 4001 ) • Scope ( both ) • Direction ( both ) • Logging ( no ) • Fragment ( all packets ) • Tunnel ( 0 ) • Interface ( all ). Les règles de filtre statiques sont expliquées plus en détail à la suite de cet exemple : 1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no ah any 0 any 0 both both no all packets 0 all 3 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no esp any 0 any 0 both both no all packets 0 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.2 255.255.255.255 no all any 0 any 0 both outbound traffic outbound no all packets 1 all 5 permit 10.0.0.2 255.255.255.255 10.0.0.1 255.255.255.255 no all any 0 any 0 both inbound no all packets 1 all 6 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp lt 1024 eq 514 local outbound yes all packets 2 all 7 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 514 lt 1024 local inbound yes all packets 2 all 8 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp/ack lt 1024 lt 1024 local outbound yes all packets 2 all 9 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp lt 1024 lt 1024 local inbound yes all packets 2 all 10 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound yes all packets 3 all 11 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound yes all packets 3 all 12 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 eq 21 local outbound yes all packets 4 all 13 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 21 gt 1023 local 11-40 Guide de sécurité inbound yes all packets 4 all 14 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp eq 20 gt 1023 local inbound yes all packets 4 all 15 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp/ack gt 1023 eq 20 local outbound yes all packets 4 all 16 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 gt 1023 local outbound yes all packets 4 all 17 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack gt 1023 gt 1023 local inbound yes all packets 4 all 18 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no all any 0 any 0 both both yes all packets Chaque règle de l’exemple précédent est décrite de la manière suivante : Règle 1 Concerne le démon de clef de session. Cette règle n’apparaît que dans les tables de filtre IPv4. Elle utilise le port 4001 pour contrôler les paquets pour actualiser la clef de session. La règle 1 illustre l’utilisation du numéro de port pour une tâche spécifique. Remarque : Ne modifiez en aucun cas cette règle de filtre, sauf dans un but de journalisation. Règles 2 et 3 Autorisent le traitement des entêtes d’authentification AH et d’encapsulation ESP. Remarque : Ne modifiez en aucun cas les règles 2 et 3, sauf dans un but de journalisation. Règles 4 et 5 Des règles générées automatiquement pour filtrer les échanges entre les adresses 10.0.0.1 et 10.0.0.2 via le tunnel 1. La règle 4 concerne le trafic sortant, la règle 5 le trafic entrant. Remarque : Règles 6 à 9 La règle 4 est définie par l’utilisateur en tant que trafic sortant. Règles définies par l’utilisateur pour filtrer les services sortants rsh, rcp, rdump, rrestore et rdist, entre les adresses 10.0.0.1 et 10.0.0.3 via le tunnel 2. A noter que la journalisation est définie sur oui et permet à l’administrateur de gérer ce type de trafic. Règles 10 et 11 Règles définies par l’utilisateur pour filtrer à la fois le trafic entrant et sortant icmp entre les adresses 10.0.0.1 et 10.0.0.4 via le tunnel 3. Règles 12 à 17 Règles définies par l’utilisateur pour filtrer le service FTP sortant depuis les adresses 10.0.0.1 et 10.0.0.5 via le tunnel 4. Règle 18 Règle générée automatiquement, toujours placée en fin de table. Dans cet exemple, elle accorde l’autorisation à tous les paquets qui ne correspondent pas aux règles précédentes. Vous pouvez cependant lui dire de refuser tous les paquets qui ne correspondent pas aux autres règles de filtre. Sécurité IP (Internet Protocol) 11-41 Chaque règle peut être affichée séparément (avec lsfilt), avec chacune de ses zones. Par exemple : Rule 1 : Rule action Source Address Source Mask Destination Address Destination Mask Source Routing Protocol Source Port Destination Port Scope Direction Logging control Fragment control Tunnel ID number Interface Auto–Generated : : : : : : : : : : : : : : : : permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 yes udp eq 4001 eq 4001 both both no all packets 0 all yes Vous trouverez ci–dessous la liste de tous les paramètres pouvant être spécifiés dans une règle de filtre : –v Version IP : 4 ou 6. –a Action : d Accès refusé p –s Adresse source. Il peut s’agir d’une adresse IP ou du nom de l’hôte. –m Masque de sous–réseau source. –d Adresse de destination. Il peut s’agir d’une adresse IP ou du nom de l’hôte. –M Masque de sous–réseau de destination. –g Contrôle de routage par la source : y ou n. –c Protocole. Les valeurs peuvent être udp, icmp, tcp, tcp/ack, ospf, pip, esp, ah et all. –o Port source ou opération de type ICMP. –p Port source ou valeur de type ICMP. –O Port de destination ou opération de code ICMP. –P Port de destination ou valeur de code ICMP. –r Routage : r Paquets retransmis l b –l Guide de sécurité Paquets origine/destination locale Les deux Gestion des journaux. y Inclure dans le journal n 11-42 Accès autorisé Ne pas inclure dans le journal. –f Fragmentation. y S’applique aux en–têtes de fragment, aux fragments et aux non fragmentés o Ne s’applique qu’aux fragments et en–têtes de fragment n Ne s’applique qu’aux non fragmentés h Ne s’applique qu’aux non fragmentés et en–têtes de fragment –t ID tunnel. –i Interface, telle que tr0 ou en0. Pour de plus amples informations, consultez les descriptions des commandes genfilt et chfilt. Règles de filtre générées automatiquement et définies par l’utilisateur Certaines règles sont générées automatiquement pour l’utilisation du filtre de sécurité IP et du code tunnel. Les règles générées automatiquement comprennent : • Les règles concernant le démon de clef de session destiné à actualiser les clefs IP version 4 dans IKE (AIX 4.3.2 et versions ultérieures) • Les règles chargées de traiter les paquets AH et ESP. Les règles de filtre sont également générées automatiquement lors de la définition des tunnels. Pour les tunnels manuels, elles spécifient les valeurs de l’adresse source et de destination et du masque, ainsi que l’ID du tunnel. Toutes les données échangées entre ces adresses transitent via le tunnel. Pour les tunnels IKE, les règles de filtre générées automatiquement déterminent le protocole et les numéros de port pendant la négociation IKE. Les règles de filtres IKE sont conservées dans une table séparée, dans laquelle les recherches s’effectuent après les règles de filtre statiques et avant les règles générées automatiquement. Les règles de filtre IKE sont insérées dans une position par défaut dans la table de filtres statiques, mais l’utilisateur peut les déplacer. Les règles générées automatiquement autorisent tous les échanges via le tunnel. Les règles définies par l’utilisateur peuvent établir des restrictions sur certains types de trafic. Ces règles définies par l’utilisateur doivent être placées avant les règles générées automatiquement car la sécurité IP utilise la première règle qui s’applique au paquet. L’exemple ci–dessous illustre des règles de filtre définies par l’utilisateur permettant de filtrer les échanges en fonction de l’opération ICMP. 1 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 8 any 0 local outbound no all packets 3 all 2 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound no all packets 3 all 3 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 8 any 0 local inbound no all packets 3 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound no all packets 3 all Les règles de filtre sont générées automatiquement lorsque les tunnels sont définis. Cela simplifie la configuration d’un seul tunnel. Cette fonction peut être supprimée avec l’indicateur –g dans gentun. Vous pouvez trouver un exemple de filtre avec les commandes genfilt pour générer les règles de filtre pour les différents services TCP/IP dans /usr/samples/ipsec/filter.sample. Sécurité IP (Internet Protocol) 11-43 Règles de filtre prédéfinies Plusieurs règles de filtre sont générées automatiquement avec certains événements. Lorsque l’unité ipsec_v4 ou ipsec_v6 est chargée, une règle prédéfinie est introduite dans la table de filtre puis activée. Par défaut, cette règle autorise tous les trafics, mais l’utilisateur peut la configurer, par exemple pour qu’elle refuse tous les paquets. Remarque : Lors d’une configuration à distance, prenez garde de ne pas activer la règle Accès refusé avant la fin de la configuration, pour éviter le verrouillage de votre session. Afin d’éviter ce cas de figure, attribuez par défaut la règle Accès autorisé ou configurez un tunnel sur la machine à distance avant d’activer IPsec. Les tables de filtre IPv4 et IPv6 ont chacune une règle prédéfinie. Chacune peut être définie sur Accès refusé, indépendamment de l’autre. Cette opération empêchera le trafic de circuler, sauf s’il est autorisé par d’autres règles de filtre. L’option chfilt avec –l est la seule autre option à modifier dans les règles prédéfinies, puisqu’elle permet la journalisation des paquets correspondants. Pour les tunnels IKE, une règle de filtre dynamique est placée dans la table de filtre IPv4. C’est l’emplacement réservé aux règles de filtre dynamique dans la table de filtre. L’utilisateur peut contrôler cet emplacement en le déplaçant dans la table de filtre, vers le haut ou vers le bas. Dès que le démon de gestion des tunnels et le démon isakmpd sont initialisés pour permettre la négociation des tunnels IKE, les règles sont automatiquement créées dans la table de filtre dynamique pour traiter aussi bien les messages IKE que les paquets AH et ESP. Masques de sous–réseau Les masques de sous–réseau sont utilisés pour regrouper un ensemble d’ID associés à une règle de filtre. Une opération AND est effectuée entre la valeur du masque et l’ID dans les règles de filtre, et comparée à l’ID spécifié dans le paquet. Par exemple, une règle de filtre comportant l’adresse IP source 10.10.10.4 et le masque de sous–réseau 255.255.255.255 impose une correspondance exacte avec l’adresse IP décimale, comme suit : Binaire Décimal Adresse IP source 1010.1010.1010.0100 10.10.10.4 Masque de sous–réseau 1111.1111.1111.1111 255.255.255.255 Un masque de sous–réseau de 10.10.10.x correspond à 1111.1111.1111.0, soit 255.255.255.0. Le masque de sous–réseau est appliqué à l’adresse entrante, puis la combinaison se comparée avec l’ID présent dans la règle de filtre. Par exemple, une adresse de 10.10.10.100 devient 10.10.10.0 après l’application du masque de sous–réseau correspondant à la règle de filtre. Un masque de sous–réseau de 255.255.255.240 autorise n’importe quelle valeur pour les 4 derniers bits de l’adresse. Configuration Hôte–Pare–feu–Hôte L’option de configuration hôte–pare–feu–hôte permet de créer un tunnel entre votre hôte et un pare–feu, puis de générer automatiquement les règles de filtre nécessaires à une communication correcte avec un hôte situé derrière le pare–feu. Les règles de filtre générées automatiquement autorisent toutes les règles entre les deux hôtes via le tunnel spécifié. Les règles par défaut (pour les en–têtes UDP, AH et ESP) devraient déjà gérer la communication hôte–pare–feu. Le pare–feu devra être paramétré de façon appropriée pour compléter la configuration. Nous vous recommandons d’utiliser le fichier d’exportation du tunnel que vous avez créé pour entrer les valeurs SPI et les clefs nécessaires au pare–feu. 11-44 Guide de sécurité Figure 12. Hôte–Pare–feu–Hôte Cette illustration présente la configuration Hôte–Pare–feu–Hôte. L’hôte A dispose d’un tunnel passant à travers un pare–feu local et sortant vers le réseau Internet. Il passe ensuite dans le pare–feu distant B, puis dans l’hôte distant C. Fonctions de journalisation Cette section décrit la configuration et le format des journaux système relatifs à la sécurité IP. Etant donné que les hôtes communiquent entre eux, les paquets transférés peuvent être journalisés sur le démon journal système, syslogd. D’autres messages importants concernant la sécurité IP s’affichent également. Un administrateur peut choisir de modifier cette information de journalisation pour effectuer des analyses de trafic et des opérations de débogage. Vous trouverez ci–après les étapes de configuration des fonctions de journalisation. 1. Modifiez le fichier /etc/syslog.conf pour ajouter l’entrée suivante : local4.debug var/adm/ipsec.log Utilisez local4 pour enregistrer les événements liés aux échanges et à la sécurité IP. Les niveaux de priorité standard du système d’exploitation s’appliquent. Nous vous recommandons de définir le niveau de priorité du débogage jusqu’à ce que le trafic soit stable et circule correctement à travers les filtres et les tunnels de sécurité IP. Remarque : La journalisation des événements de filtre peut entraîner une activité importante au niveau de l’hôte de sécurité IP et nécessiter une capacité de stockage importante. 2. Enregistrez /etc/syslog.conf. 3. Allez dans le répertoire indiqué pour le fichier journal puis créez un fichier vide portant le même nom. Dans le cas précédent, vous passeriez au répertoire /var/adm et lanceriez la commande : touch ipsec.log 4. Envoyez une commande d’actualisation au sous–système syslogd : refresh –s syslogd 5. Si vous utilisez des tunnels IKE, vérifiez que le fichier /etc/isakmpd.conf indique le niveau de journalisation isakmpd souhaité. (Pour de plus amples informations sur la journalisation IKE, reportez–vous à la section Identification des incidents liés à la sécurité IP, page 11-50.) 6. Lorsque vous créez des règles de filtre pour votre système hôte, si vous souhaitez que les paquets respectant une règle en particulier soient journalisés, attribuez la valeur Y (oui) au paramètre –l de la règle, à l’aide des commandes genfilt ou chfilt. 7. Enfin, activez la journalisation des paquets et lancez le démon ipsec_logd à l’aide de la commande suivante : mkfilt –g start Vous pouvez arrêter la journalisation avec la commande suivante : mkfilt –g stop Sécurité IP (Internet Protocol) 11-45 L’exemple de fichier journal suivant contient des entrées de trafic et de journal de sécurité IP : 1. Aug 27 08:08:40 host1 : Filter logging daemon ipsec_logd (level 2.20) initialized at 08:08:40 on 08/27/97A 2. Aug 27 08:08:46 host1 : mkfilt: Status of packet logging set to Start at 08:08:46 on 08/27/97 3. Aug 27 08:08:47 host1 : mktun: Manual tunnel 2 for IPv4, 9.3.97.244, 9.3.97.130 activated. 4. Aug 27 08:08:47 host1 : mkfilt: #:1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 4001 eq 4001 both both l=n f=y t=0 e= a= 5. Aug 27 08:08:47 host1 : mkfilt: #:2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ah any 0 any 0 both both l=n f=y t=0 e= a= 6. Aug 27 08:08:47 host1 : mkfilt: #:3 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 esp any 0 any 0 both both l=n f=y t=0 e= a= 7. Aug 27 08:08:47 host1 : mkfilt: #:4 permit 10.0.0.1 255.255.255.255 10.0.0.2 255.255.255.255 icmp any 0 any 0 local outbound l=y f=y t=1 e= a= 8. Aug 27 08:08:47 host1 : mkfilt: #:4 permit 10.0.0.2 255.255.255.255 10.0.0.1 255.255.255.255 icmp any 0 any 0 local inbound l=y f=y t=1 e= a= 9. Aug 27 08:08:47 host1 : mkfilt: #:6 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 both both l=y f=y t=0 e= a= 10. Aug 27 08:08:47 host1 : mkfilt: Filter support (level 1.00) initialized at 08:08:47 on 08/27/97 11. Aug 27 08:08:48 host1 : #:6 R:p o:10.0.0.1 s:10.0.0.1 d:10.0.0.20 p:udp sp:3327 dp:53 r:l a:n f:n T:0 e:n l:67 12. Aug 27 08:08:48 host1 : #:6 R:p i:10.0.0.1 s:10.0.0.20 d:10.0.0.1 p:udp sp:53 dp:3327 r:l a:n f:n T:0 e:n l:133 13. Aug 27 08:08:48 host1 : #:6 R:p i:10.0.0.1 s:10.0.0.15 d:10.0.0.1 p:tcp sp:4649 dp:23 r:l a:n f:n T:0 e:n l:43 14. Aug 27 08:08:48 host1 : #:6 R:p o:10.0.0.1 s:10.0.0.1 d:10.0.0.15 p:tcp sp:23 dp:4649 r:l a:n f:n T:0 e:n l:41 15. Aug 27 08:08:48 host1 : #:6 R:p i:10.0.0.1 s:10.0.0.15 d:10.0.0.1 p:tcp sp:4649 dp:23 r:l a:n f:n T:0 e:n l:40 16. Aug 27 08:08:51 host1 : #:4 R:p o:10.0.0.1 s:10.0.0.1 d:10.0.0.2 p:icmp t:8 c:0 r:l a:n f:n T:1 e:n l:84 17. Aug 27 08:08:51 host1 : #:5 R:p i:10.0.0.1 s:10.0.0.2 d:10.0.0.1 p:icmp t:0 c:0 r:l a:n f:n T:1 e:n l:84 18. Aug 27 08:08:52 host1 : #:4 R:p o:10.0.0.1 s:10.0.0.1 d:10.0.0.2 p:icmp t:8 c:0 r:l a:n f:n T:1 e:n l:84 19. Aug 27 08:08:52 host1 : #:5 R:p i:10.0.0.1 s:10.0.0.2 d:10.0.0.1 p:icmp t:0 c:0 r:l a:n f:n T:1 e:n l:84 20. Aug 27 08:32:27 host1 : Filter logging daemon terminating at 08:32:27 on 08/27/97l 11-46 Guide de sécurité Les paragraphes suivants expliquent les entrées du journal. 1 Démon de journalisation de filtre activé. 2 Journalisation de paquet de filtre activée avec la commande mkfilt –g start. 3 Activation du tunnel, affichage de l’ID du tunnel, adresse source, adresse de destination et date/heure. 4à9 Les filtres ont été activés. La journalisation montre toutes les règles de filtres chargées. 10 Message montrant l’activation des filtres. 11 et 12 Ces entrées montrent une recherche DNS d’un hôte. 13 à 15 Ces entrées correspondent partiellement à une connexion Telnet (les autres entrées ont été supprimées de cet exemple pour des raisons de place). 16 à 19 Ces entrées montrent deux Pings. 20 Démon de journalisation de filtre désactivé. L’exemple ci–dessous illustre les phases 1 et 2 de négociation d’un tunnel entre deux hôtes, du point de vue de l’hôte initiateur. (Le niveau de journalisation isakmpd a été indiqué comme isakmp_events.) 1. Dec 6 14:34:42 host1 Tunnel Manager: 0: TM is processing a Connection_request_msg 2. Dec 6 14:34:42 host1 Tunnel Manager: 1: Creating new P1 tunnel object (tid) 3. Dec 6 14:34:42 host1 isakmpd: 192.168.100.103 >>> 192.168.100.104 ( SA PROPOSAL TRANSFORM ) 4. Dec 6 14:34:42 host1 isakmpd: ::ffff:192.168.100.103 <<< 192.168.100.104 ( SA PROPOSAL TRANSFORM ) 5. Dec 6 14:34:42 host1 isakmpd: Phase I SA Negotiated 6. Dec 6 14:34:42 host1 isakmpd: 192.168.100.103 >>> 192.168.100.104 ( KE NONCE ) 7. Dec 6 14:34:42 host1 isakmpd: ::ffff:192.168.100.103 <<< 192.168.100.104 ( KE NONCE ) 8. Dec 6 14:34:42 host1 isakmpd: Encrypting the following msg to send: ( ID HASH ) 9. Dec 6 14:34:42 host1 isakmpd: 192.168.100.103 >>> 192.168.100.104 ( Encrypted Payloads ) 10. Dec 6 14:34:42 host1 isakmpd: ::ffff:192.168.100.103 <<< 192.168.100.104 ( Encrypted Payloads ) 11. Dec 6 14:34:42 host1 Tunnel Manager: 1: TM is processing a P1_sa_created_msg (tid) 12. Dec 6 14:34:42 host1 Tunnel Manager: 1: Received good P1 SA, updating P1 tunnel (tid) 13. Dec 6 14:34:42 host1 Tunnel Manager: 0: Checking to see if any P2 tunnels need to start 14. Dec 6 14:34:42 host1 isakmpd: Decrypted the following received msg: ( ID HASH ) 15. Dec 6 14:34:42 host1 isakmpd: Phase I Done !!! 16. Dec 6 14:34:42 host1 isakmpd: Phase I negotiation authenticated 17. Dec 6 14:34:44 host1 Tunnel Manager: 0: TM is processing a Connection_request_msg 18. Dec 6 14:34:44 host1 Tunnel Manager: 0: Received a connection object for an active P1 tunnel Sécurité IP (Internet Protocol) 11-47 19. Dec 6 14:34:44 host1 Tunnel Manager: 1: Created blank P2 tunnel (tid) 20. Dec 6 14:34:44 host1 Tunnel Manager: 0: Checking to see if any P2 tunnels need to start 21. Dec 6 14:34:44 host1 Tunnel Manager: 1: Starting negotiations for P2 (P2 tid) 22. Dec 6 14:34:45 host1 isakmpd: Encrypting the following msg to send: ( HASH SA PROPOSAL TRANSFORM NONCE ID ID ) 23. Dec 6 14:34:45 host1 isakmpd: 192.168.100.103 >>> 192.168.100.104 ( Encrypted Payloads ) 24. Dec 6 14:34:45 host1 isakmpd: ::ffff:192.168.100.103 <<< 192.168.100.104 ( Encrypted Payloads ) 25. Dec 6 14:34:45 host1 isakmpd: Decrypted the following received msg: ( HASH SA PROPOSAL TRANSFORM NONCE ID ID ) 26. Dec 6 14:34:45 host1 isakmpd: Encrypting the following msg to send: ( HASH ) 27. Dec 6 14:34:45 host1 isakmpd: 192.168.100.103 >>> 192.168.100.104 ( Encrypted Payloads ) 28. Dec 6 14:34:45 host1 isakmpd: Phase II SA Negotiated 29. Dec 6 14:34:45 host1 isakmpd: PhaseII negotiation complete. 30. Dec 6 14:34:45 host1 Tunnel Manager: 0: TM is processing a P2_sa_created_msg 31. Dec 6 14:34:45 host1 Tunnel Manager: 1: received p2_sa_created for an existing tunnel as initiator (tid) 32. Dec 6 14:34:45 host1 Tunnel Manager: 1: Filter::AddFilterRules: Created filter rules for tunnel 33. Dec 6 14:34:45 host1 Tunnel Manager: 0: TM is processing a List_tunnels_msg Les paragraphes suivants expliquent les entrées de journal. 11-48 1 et 2 La commande ike cmd=activate phase=1 active une connexion. 3 à 10 Le démon isakmpd négocie un tunnel de phase 1. 11 et 12 Le gestionnaire de tunnel reçoit du répondeur un lien de sécurité valide de phase 1. 13 Ce gestionnaire vérifie si la commande ike cmd=activate dispose ou non d’une valeur de phase 2 pour effectuer du travail supplémentaire. Elle n’en a pas. 14 à 16 Le démon isakmpd termine la négociation de phase 1. 17 à 21 La commande ike cmd=activate phase=2 active un tunnel de phase 2. 22 à 29 Le démon isakmpd négocie un tunnel de phase 2. 30 et 31 Le gestionnaire de tunnel reçoit lien de sécurité valide de phase 2. 32 Le gestionnaire de tunnel écrit les règles de filtre dynamiques. 33 La commande ike cmd=list affiche les tunnels IKE. Guide de sécurité Libellés des entrées de zone Les zones des entrées des journaux sont abrégées pour réduire l’espace DADS : # Numéro de la règle qui régit la journalisation de ce paquet. R Type de règle p Accès accordé d i/o Accès refusé Direction du paquet lors de son interception par le code de prise en charge du filtre. Identifie l’adresse IP de la carte associée au paquet : • Pour les paquets entrants (i), c’est l’adresse de la carte sur laquelle est arrivé le paquet. • Pour les paquets sortants (o), c’est l’adresse de la carte déterminée par la couche IP comme devant traiter la transmission du paquet. s Indique l’adresse IP de l’expéditeur du paquet (extrait de l’en–tête IP). d Indique l’adresse IP du destinataire prévu (extrait de l’en–tête IP). p Indique le protocole de haut niveau utilisé pour créer le message dans la portion de données du paquet. Peut être un nombre ou un nom, par exemple : udp, icmp, tcp, tcp/ack, ospf, pip, esp, ah, ou all. sp / t Indique le numéro de port du protocole associé à l’expéditeur du paquet (extrait de l’en–tête TCP/UDP). Pour un protocole ICMP ou OSPF, cette zone est remplacée par un t, qui précise le type d’IP. dp / c Indique le numéro de port du protocole associé au destinataire prévu (extrait de l’en–tête TCP/UDP). Pour un protocole ICMP, cette zone est remplacée par un c, qui indique le code IP. – Indique qu’aucune information n’est disponible r Indiquent une affiliation locale du paquet. f Paquets retransmis l Paquets locaux o Sortant b Les deux l Indique la taille d’un paquet en octets. f Indique si le paquet est un fragment. T Indique l’ID du tunnel. i Précise l’interface sur lequel est arrivé le paquet. Sécurité IP (Internet Protocol) 11-49 Identification des incidents liés à la sécurité IP Vous trouverez dans la présente section des conseils et astuces pour vous aider à résoudre les incidents. Il est recommandé d’activer la journalisation lors de la configuration initiale de IPSec. Les journaux sont très utiles pour identifier les incidents liés aux filtres et aux tunnels. Reportez–vous à la section Fonctions de journalisation, page 11-45 pour plus d’informations en la matière. Débogage des erreurs au niveau du tunnel manuel Erreur : La commande mktun retourne le message d’erreur suivant : insert_tun_man4(): write failed : The requested resource is busy. Problème : Le tunnel que vous souhaitez activer est déjà actif ou une collision des valeurs SPI s’est produite. Solution : Lancez la commande rmtun pour désactiver le tunnel, puis utilisez la commande mktun pour le réactiver. Vérifiez si les valeurs SPI du tunnel défaillant correspondent à un autre tunnel actif. Chaque tunnel doit posséder ses propres valeurs SPI, uniques. Erreur : La commande mktun retourne le message d’erreur suivant : Device ipsec_v4 is in Defined status. Tunnel activation for IP Version 4 not performed. Problème : Vous n’avez pas rendu disponible l’unité de sécurité IP. Solution : Lancez la commande suivante : mkdev –l ipsec –t 4 Vous devez remplacer l’option –t par 6 si la même erreur se produit lors de l’activation d’un tunnel IP Version 6. Les unités doivent être dans l’état disponible. Pour vérifiez l’état de l’unité de sécurité IP, lancez la commande suivante : lsdev –Cc ipsec 11-50 Guide de sécurité Erreur : La commande gentun retourne le message d’erreur suivant Invalid Source IP address Problème : Vous avez saisi une adresse IP incorrecte comme adresse source. Solution : Pour les tunnels IP version 4, vérifiez si vous avez indiqué une adresse IP version 4 disponible pour la machine locale. Lorsque vous générez des tunnels, vous ne pouvez pas utiliser de nom d’hôte comme adresse source. Ce n’est possible que pour l’adresse de destination. Pour les tunnels IP version 6, vérifiez si vous avez indiqué une adresse IP version 6 disponible. Si vous entrez netstat –in et qu’aucune adresse IP version 6 n’existe, exécutez /usr/sbin/autoconf6 (interface) pour générer automatiquement une adresse locale (avec l’adresse MAC) ou utilisez ifconfig pour attribuer manuellement une adresse. Erreur : La commande gentun retourne le message d’erreur suivant : Invalid Source IP address Problème : Vous avez saisi une adresse IP incorrecte comme adresse source. Solution : Pour les tunnels IP version 4, vérifiez si vous avez indiqué une adresse IP version 4 disponible pour la machine locale. Lorsque vous générez des tunnels, vous ne pouvez pas utiliser de nom d’hôte comme adresse source. Ce n’est possible que pour l’adresse de destination Pour les tunnels IP version 6, vérifiez si vous avez indiqué une adresse IP version 6 disponible. Si vous entrez netstat –in et qu’aucune adresse IP version 6 n’existe, exécutez /usr/sbin/autoconf6 (interface) pour générer automatiquement une adresse locale (avec l’adresse MAC) ou utilisez ifconfig pour attribuer manuellement une adresse. Erreur : La commande mktun retourne le message d’erreur suivant : insert_tun_man4(): write failed: A system call received a parameter that is not valid. Problème : La génération du tunnel s’est produite avec une combinaison ESP et AH incorrecte, ou sans l’utilisation du nouveau format d’en–tête lorsque nécessaire. Solution : Vérifiez la nature des algorithmes d’authentification en cours d’utilisation par le tunnel en question. N’oubliez pas que les algorithmes HMAC_MD5 et HMAC_SHA requièrent le nouveau format d’en–tête. Le nouveau format d’en–tête peut être modifié à l’aide du raccourci SMIT ips4_basic ou de l’indicateur –z associé à la commande chtun. Rappelez–vous également que DES_CBC_4 ne peut pas être utilisé avec le nouveau format d’en–tête. Sécurité IP (Internet Protocol) 11-51 Erreur : Le lancement d’IPSec à partir de Web-based System Manager génère un message d’erreur Failure. Problème : Les démons IPSec ne sont pas lancés. Solution : Vérifier quels sont les démons en cours d’exécution avec la commande ps–ef. Les démons associés à IPSec sont les suivants : • tmd • isakmpd • cpsd Le démon cpsd n’est actif que lorsque le code du certificat numérique est installé (fichiers gskit.rte ou gskkm.rte) et lorsque vous avez configuré l’utilitaire IBM Key Manager pour la prise en charge des certificats numériques. Si les démons ne sont pas actifs, arrêtez IPSec avec Web-based System Manager, puis relancez–le pour lancer automatiquement les démons appropriés. Erreur : L’utilisation d’IPSec génère le message d’erreur suivant : The installed bos.crypto is back level and must be updated. Problème : Les fichiers bos.net.ipsec.* ont été mis à jour avec une version plus récente, mais les fichiers bos.crypto.* correspondants ne l’ont pas été. Solution : Mettez les fichiers bos.crypto.* à jour avec la version correspondante aux fichiers bos.net.ipsec.* mis à jour. 11-52 Guide de sécurité Débogage des erreurs au niveau des tunnels IKE Les sections suivantes décrivent les erreurs générées lors de l’utilisation de tunnels IKE. Organigramme des tunnels IKE Les tunnels IKE sont configurés via la commande ike ou les écrans VPN du Web-based System Manager, avec les démons suivants : Tableau 10. Démons utilisés par les tunnels IKE. tmd Démon de gestion des tunnels isakmpd Démon IKE cpsd Démon de proxy de certificat Pour que les tunnels IKE soient configurés correctement, les démons tmd et isakmpd doivent être actifs. Si la fonction de sécurité IP est lancée lors du redémarrage, l’exécution de ces démons se fait automatiquement. Dans le cas contraire, ils doivent être lancés avec Web–based System Manager. Le gestionnaire de tunnels demande à isakmpd de lancer un tunnel. Si le tunnel existe déjà ou n’est pas valide (en cas d’adresse distante erronée, par exemple), un message d’erreur apparaît. Une fois la négociation lancée, son exécution peut prendre un certain temps, en fonction de la latence du réseau. La commande ike cmd=list indiquera l’état du tunnel pour savoir si la négociation s’est bien déroulée. Le gestionnaire de tunnel consigne également des événements dans le journal système syslog, au niveau des sections debug, event et information, utilisées pour surveiller l’état d’avancement de la négociation. La séquence est la suivante : 1. Utilisez Web-based System Manager ou la commande ike pour lancer un tunnel. 2. Le démon tmd envoie au démon isakmpd une demande de connexion pour la gestion de clés (phase 1). 3. Le démon isakmpd répond par le message SA created (CA créée) ou par l’affichage d’un message d’erreur. 4. Le démon tmd envoie au démon isakmpd une demande de connexion pour un tunnel de gestion des données (phase 2). 5. Le démon isakmpd répond par le message SA created ou par l’affichage d’un message d’erreur. 6. Les paramètres de tunnel sont insérés dans le cache de tunnel du noyau. 7. Les règles de filtres sont ajoutées à la table de filtres dynamique du noyau. Lorsque la machine agit comme répondeur, le démon isakmpd informe le démon tmd du gestionnaire de tunnels du bon déroulement de la négociation. Un nouveau tunnel est inséré dans le noyau. Le processus commence alors à l’étape 3 et se poursuit jusqu’à l’étape 7, sans que le démon tmd ne demande de connexion. Sécurité IP (Internet Protocol) 11-53 Journalisation IKE Les démons isakmpd, tmd et cpsd consignent des événements dans syslog. Pour le démon isakmpd, la journalisation est activée à l’aide de la commande ike cmd=log. Le fichier de configuration /etc/isakmpd.conf peut être défini pour spécifier le niveau de journalisation. Ce niveau peut prendre les valeurs none, errors, isakmp_events ou information. Remarque : Dans les versions antérieures à AIX 5.1, le démon isakmpd consignait les éléments dans un fichier séparé, spécifié dans /etc/isakmpd.conf. Le paramètre du fichier de configuration qui peut être défini pour la journalisation est log_level. Les démons IKE utilisent les niveaux de journalisation suivants : none Aucune journalisation (valeur par défaut) error Consignation uniquement des erreurs de protocole et d’API isakmp_events Consignation uniquement des événements et des erreurs de protocole IKE Information Consignation des informations de mise en œuvre et de protocole (conseillé lors d’un débogage) La syntaxe de cette option est : log_level Le démon isakmpd démarre par l’envoi d’une proposition ou répond en évaluant une proposition. Si cette proposition est acceptée, un lien de sécurité est généré et le tunnel est configuré. Si cette proposition est refusée ou si le délai de connexion expire avant la fin de la négociation, isakmpd renvoie un message d’erreur. Les entrées du journal système syslog dans tmd indiquent la réussite ou non de la négociation. Un échec pour cause de certificat non valide est consigné dans syslog. Pour déterminer la cause exacte de l’échec d’une négociation, contrôlez le fichier journal spécifié dans /etc/syslog.conf. Syslog ajoute à chaque ligne du journal un préfixe comprenant la date et l’heure, la machine et le programme. Dans l’exemple suivant, le nom de machine est googly et le nom de programme est isakmpd : Nov 20 09:53:50 googly isakmpd: ISAKMP_MSG_HEADER Nov 20 09:53:50 googly isakmpd: Icookie : 0xef06a77488f25315, Rcookie :0x0000000000000000 Nov 20 09:53:51 googly isakmpd: Next Payload : 1(SA), Maj Ver : 1, Min Ver : 0 Nov 20 09:53:51 googly isakmpd: Xchg Type : 2 (ID protected), Flag= 0, Encr : No,COMMIT : non Nov 20 09:53:51 googly isakmpd: Msg ID : 0x00000000 Pour plus de clarté, vous pouvez utiliser la commande grep pour extraire des lignes intéressantes du journal (toute la journalisation isakmpd par exemple) et la commande cut pour retirer le préfixe de chaque ligne. Les exemples de journalisation isakmpd dans le reste de cette section ont été transformé d’une manière similaire. Fonction de journalisation Parse Payload (analyse de blocs) Le lien de sécurité (SA) entre deux points terminaux est établi grâce à l’échange de messages IKE. La fonction d’analyse de blocs interprète les messages dans un format lisible par l’homme. Vous pouvez activer la journalisation en modifiant le fichier /etc/isakmpd.conf. Dans le fichier /etc/isakmpd.conf, l’entrée relative à la journalisation est semblable à la ligne suivante : information 11-54 Guide de sécurité Le type de blocs IKE consignés par l’analyse de blocs varie selon le contenu des messages IKE. Les exemples incluent les blocs SA, Key Exchange, Certificate Request, Certificate et Signature. Le journal de l’analyse de blocs de l’exemple suivant possède un en–tête ISAKMP_MSG_HEADER suivi par cinq blocs : ISAKMP_MSG_HEADER Icookie : 0x9e539a6fd4540990, Rcookie : 0x0000000000000000 Next Payload : 1(SA), Maj Ver : 1, Min Ver : 0 Xchg Type : 4 (Aggressive), Flag= 0, Encr : No,COMMIT : No Msg ID : 0x00000000 len : 0x10e(270) SA Payload: Next Payload : 4(Key Exchange), Payload len : 0x34(52) DOI : 0x1(INTERNET) bitmask : 1(SIT_IDENTITY_ONLY Proposal Payload: Next Payload : 0(NONE), Payload len : 0x28(40) Proposal # : 0x1(1), Protocol–ID : 1(ISAKMP) SPI size : 0x0(0), # of Trans : 0x1(1) Transform Payload: Next Payload : 0(NONE), Payload len : 0x20(32) Trans # : 0x1(1), Trans.ID : 1(KEY_IKE) Attr : 1(Encr.Alg ), len=0x2(2) Value=0x1(1),(DES–cbc) Attr : 2(Hash Alg ), len=0x2(2) Value=0x1(1),(MD5) Attr : 3(Auth Method ), len=0x2(2) Value=0x3(3),(RSA Signature) Attr : 4(Group Desc ), len=0x2(2) Value=0x1(1),(default 768–bit MODP group) Attr : 11(Life Type ), len=0x2(2) Value=0x1(1),(seconds) Attr : 12(Life Duration), len=0x2(2) Value=0x7080(28800) Key Payload: Next Payload : 10(Nonce), Payload len : 0x64(100) Key Data 33 17 68 a0 e1 1f 9f 13 62 8a 59 97 d9 8b 39 ab d3 5a : 10 42 aa 1f d1 39 91 c2 27 3b cb 7d 1f 10 d8 1c 39 67 ea aa e5 08 c2 5b da 8d 52 3e a4 a6 38 9d 8d 2a 05 2e a0 14 5c 55 8d 37 22 0f c3 9b 2d d3 2d 58 cf 3c a1 07 84 3e d5 50 98 e6 a3 c4 45 cc 74 98 5d ec 1a 82 7d 1a 5d a3 79 2c 95 6b Nonce Payload: Next Payload : 5(ID), Payload len : 0xc(12) Nonce Data: 6d 21 73 1d dc 60 49 93 ID Payload: Next Payload : 7(Cert.Req), Payload len : 0x49(73) ID type : 9(DER_DN), Protocol : 0, Port = 0x0(0) Certificate Request Payload: Next Payload : 0(NONE), Payload len : 0x5(5) Certificate Encoding Type: 4(X.509 Certificate – Signature) Dans chaque bloc se trouve le champ Next Payload qui renvoie au bloc suivant. Si le bloc actif est le dernier du message IKE, le champ Next Payload possède la valeur zéro (None). Chaque bloc de cet exemple contient des informations concernant les négociations en cours. A titre d’exemple, le bloc SA comporte les blocs Proposal (proposition) et Transform (conversion), lesquels à leur tour contiennent l’algorithme de chiffrement, le mode d’authentification, l’algorithme de hachage, le type de cycle SA et la durée SA que l’initiateur propose au répondant. Sécurité IP (Internet Protocol) 11-55 De plus, le Bloc SA est composé d’un ou de plusieurs bloc Proposal, et d’un ou de plusieurs blocs Transform. La valeur du champ Next Payload du bloc Proposal est 0 si ce bloc est unique, ou 2 s’il est suivi par plusieurs blocs Proposal. De même, la valeur du champ Next Payload d’un bloc Transform est 0 s’il est unique, ou 3 s’il est suivi par plusieurs blocs Transform, comme dans l’exemple suivant : ISAKMP_MSG_HEADER Icookie : 0xa764fab442b463c6, Rcookie : 0x0000000000000000 Next Payload : 1(SA), Maj Ver : 1, Min Ver : 0 Xchg Type : 2 (ID protected), Flag= 0, Encr : No,COMMIT : No Msg ID : 0x00000000 len : 0x70(112) SA Payload: Next Payload : 0(NONE), Payload len : 0x54(84) DOI : 0x1(INTERNET) bitmask : 1(SIT_IDENTITY_ONLY Proposal Payload: Next Payload : 0(NONE), Payload len : 0x48(72) Proposal # : 0x1(1), Protocol–ID : 1(ISAKMP) SPI size : 0x0(0), # of Trans : 0x2(2) Transform Payload: Next Payload : 3(Transform), Payload len : 0x20(32) Trans # : 0x1(1), Trans.ID : 1(KEY_IKE) Attr : 1(Encr.Alg ), len=0x2(2) Value=0x5(5),(3DES–cbc) Attr : 2(Hash Alg ), len=0x2(2) Value=0x1(1),(MD5) Attr : 3(Auth Method ), len=0x2(2) Value=0x1(1),(Pre–shared Key) Attr : 4(Group Desc ), len=0x2(2) Value=0x1(1),(default 768–bit MODP group) Attr : 11(Life Type ), len=0x2(2) Value=0x1(1),(seconds) Attr : 12(Life Duration), len=0x2(2) Value=0x7080(28800) Transform Payload: Next Payload : 0(NONE), Payload len : 0x20(32) Trans # : 0x2(2), Trans.ID : 1(KEY_IKE) Attr : 1(Encr.Alg ), len=0x2(2) Value=0x1(1),(DES–cbc) Attr : 2(Hash Alg ), len=0x2(2) Value=0x1(1),(MD5) Attr : 3(Auth Method ), len=0x2(2) Value=0x1(1),(Pre–shared Key) Attr : 4(Group Desc ), len=0x2(2) Value=0x1(1),(default 768–bit MODP group) Attr : 11(Life Type ), len=0x2(2) Value=0x1(1),(seconds) Attr : 12(Life Duration), len=0x2(2) Value=0x7080(28800) L’en–tête de message IKE d’un journal d’analyse de blocs montre le type d’échange – Main (principal) ou Aggressive (agressif) –, la longueur de l’ensemble du message, l’ID du message, etc. Le Bloc Certificate Request demande un certificat au répondant. Le répondant envoie le certificat dans un message séparé. L’exemple suivant montre les Blocs Certificate et Signature envoyés à un homologue lors d’une négociation SA. Les données relatives au certificat et à la signature sont au format hexadécimal. 11-56 Guide de sécurité ISAKMP_MSG_HEADER Icookie : 0x9e539a6fd4540990, Rcookie : 0xc7e0a8d937a8f13e Next Payload : 6(Certificate), Maj Ver : 1, Min Ver : 0 Xchg Type : 4 (Aggressive), Flag= 0, Encr : No,COMMIT : No Msg ID : 0x00000000 len : 0x2cd(717) Certificate Payload: Next Payload : 9(Signature), Payload len : 0x22d(557) Certificate Encoding Type: 4(X.509 Certificate – Signature) Certificate: (len 0x227(551) in bytes 82 02 24 30 82 01 8d a0 03 02 01 02 02 05 05 8e fb 3e ce 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 30 5c 31 0b 30 09 06 03 55 04 06 13 02 46 49 31 24 30 22 06 03 55 04 0a 13 1b 53 53 48 20 43 6f 6d 6d 75 6e 69 63 61 74 69 6f 6e 73 20 53 65 63 75 72 69 74 79 31 11 30 0f 06 03 55 04 0b 13 08 57 65 62 20 74 65 73 74 31 14 30 12 06 03 55 04 03 13 0b 54 65 73 74 20 52 53 41 20 43 41 30 1e 17 0d 39 39 30 39 32 31 30 30 30 30 30 30 5a 17 0d 39 39 31 30 32 31 32 33 35 39 35 39 5a 30 3f 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 55 04 0a 13 07 49 42 4d 2f 41 49 58 31 1e 30 1c 06 03 55 04 03 13 15 62 61 72 6e 65 79 2e 61 75 73 74 69 6e 2e 69 62 6d 2e 63 6f 6d 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 b2 ef 48 16 86 04 7e ed ba 4c 14 d7 83 cb 18 40 0a 3f 55 e9 ad 8f 0f be c5 b6 6d 19 ec de 9b f5 01 a6 b9 dd 64 52 34 ad 3d cd 0d 8e 82 6a 85 a3 a8 1c 37 e4 00 59 ce aa 62 24 b5 a2 ea 8d 82 a3 0c 6f b4 07 ad 8a 02 3b 19 92 51 88 fb 2c 44 29 da 72 41 ef 35 72 79 d3 e9 67 02 b2 71 fa 1b 78 13 be f3 05 6d 10 4a c7 d5 fc fe f4 c0 b8 b8 fb 23 70 a6 4e 16 5f d4 b1 9e 21 18 82 64 6d 17 3b 02 03 01 00 01 a3 0f 30 0d 30 0b 06 03 55 1d 0f 04 04 03 02 07 80 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 03 81 81 00 75 a4 ee 9c 3a 18 f2 de 5d 67 d4 1c e4 04 b4 e5 b8 5e 9f 56 e4 ea f0 76 4a d0 e4 ee 20 42 3f 20 19 d4 25 57 25 70 0a ea 41 81 3b 0b 50 79 b5 fd 1e b6 0f bc 2f 3f 73 7d dd 90 d4 08 17 85 d6 da e7 c5 a4 d6 9a 2e 8a e8 51 7e 59 68 21 55 4c 96 4d 5a 70 7a 50 c1 68 b0 cf 5f 1f 85 d0 12 a4 c2 d3 97 bf a5 42 59 37 be fe 9e 75 23 84 19 14 28 ae c4 c0 63 22 89 47 b1 b6 f4 c7 5d 79 9d ca d0 Signature Payload: Next Payload : 0(NONE), Payload len : 0x84(132) Signature: len 9d 1b 0d 90 be b4 ca a2 85 0f 5c b6 9c e2 a5 e3 a2 87 f4 7c 7d b4 8c 4e 19 f0 5a 81 58 2e 4d 19 7e e0 e7 5b cb 07 ea 36 0x80(128) in bytes aa dc 43 95 ba 65 09 15 9e 3e 8d 5f e1 f0 64 f4 ef 0b 31 c3 cb 9d 20 49 b2 39 00 fa 3a b8 70 90 88 2c cf 15 40 37 b7 c8 d6 8c c7 c2 93 42 89 46 6b e5 82 9d 70 79 9a fe b9 43 48 8e 89 5c 5f bd 00 98 7c bf 69 e2 f8 6c 6d 69 d8 d9 5d 50 8b 86 67 d8 30 b0 07 c3 7d 36 Sécurité IP (Internet Protocol) 11-57 Incidents liés au certificat numérique et au mode de signature Erreur : Le démon cpsd (Certificate Proxy Server daemon) ne démarre pas. Une entrée similaire à la suivante apparaît dans le fichier journal : Sep 21 16:02:00 ripple CPS[19950]: Init():LoadCaCerts() failed, rc=–12 Problème : Le système n’a pas pu ouvrir ou trouver la base de données des certificats. Solution : Assurez–vous que les bases de données de certificats d’IBM Key Manager se trouvent dans /etc/security. La base de données est constituée des fichiers suivants : ikekey.crl, ikekey.kdb, ikekey.rdb et ikekey.sth. Si seul ikekey.sth est manquant, c’est que l’option stash password n’a pas été sélectionnée lors de la création de la base de données d’IBM Key Manager. Le mot de passe doit être sécurisé dans le fichier stash pour activer l’utilisation des certificats numériques avec IPSec. Pour en savoir plus, reportez–vous à Création d’une base de données de clés, page 11-29.) 11-58 Guide de sécurité Erreur : Key Manager génère le message d’erreur suivant lors de la réception d’un certificat : Invalid Base64–encoded data was found Problème : Des données surnuméraires ont été trouvées dans le fichier certificat ou bien des données ont été perdues ou endommagées. Solution : Le certificat chiffré ’DER’ doit se trouver entre les chaînes de l’exemple ci–dessous. Aucun caractère ne doit figurer avant et après les chaînes BEGIN CERTIFICATE et END CERTIFICATE. –––––BEGIN CERTIFICATE––––– MIICMTCCAZqgAwIBAgIFFKZtANowDQYJKoZIhvcNAQEFBQAwXDELMAkG A1UEBhMC RkkxJDAiBgNVBAoTG1NTSCBDb21tdW5pY2F0aW9ucyBTZWN1cml0eTER MA8GA1UE CxMIV2ViIHRlc3QxFDASBgNVBAMTC1Rlc3QgUlNBIENBMB4XDTk5MDky MTAwMDAw MFoXDTk5MTAyMTIzNTk1OVowOzELMAkGA1UEBhMCVVMxDDAKBgNVBAoT A0lCTTEe MBwGA1UEAxMVcmlwcGxlLmF1c3Rpbi5pYm0uY29tMIGfMA0GCSqGSIb3 DQEBAQUA A4GNADCBiQKBgQC5EZqo6n7tZrpAL6X4L7mf4yXQSm+m/NsJLhp6afbF pPvXgYWC wq4pvOtvxgum+FHrE0gysNjbKkE4Y6ixC9PGGAKHnhM3vrmvFjnl1G6K tyEz58Lz BWW39QS6NJ1LqqP1nT+y3+Xzvfv8Eonqzno8mglCWMX09SguLmWoU1Pc ZQIDAQAB oyAwHjALBgNVHQ8EBAMCBaAwDwYDVR0RBAgwBocECQNhhzANBgkqhkiG 9w0BAQUF AOBgQA6bgp4Zay34/fyAlyCkNNAYJRrN3Vc4NHN7IGjUziN6jK5UyB5z L37FERW hT9ArPLzK7yEZs+MDNvB0bosyGWEDYPZr7EZHhYcoBP4/cd0V5rBFmA8 Y2gUthPi Ioxpi4+KZGHYyLqTrm+8Is/DVJaQmCGRPynHK35xjT6WuQtiYg== –––––END CERTIFICATE––––– Les options suivantes peuvent aider au diagnostic et à la résolution de cet incident. • Si les données ont été perdues ou endommagées, recréez le certificat. • Analysez le certificat pour en vérifier la validité à l’aide d’un analyseur de type ASN.1 (disponible sur le Web). Erreur : Key Manager génère le message d’erreur suivant lors de la réception d’un certificat personnel : No request key was found for the certificate Problème : La demande de certificat personnel du certificat en cours de réception n’existe pas. Solution : Créez à nouveau la demande de certificat personnel et demandez un nouveau certificat. Sécurité IP (Internet Protocol) 11-59 Erreur : Lors de la configuration d’un tunnel IKE, Web-based System Manager génère le message d’erreur suivant : Error 171 in the Key Management (Phase 1) Tunnel operation: PUT_IRL_FAILED Problème : Il est possible que le type d’identité de l’hôte ne soit pas valide ; ce type est configuré par la boîte de dialogue IKE (onglet Identification). Ceci a lieu lorsque le type d’identité de l’hôte sélectionné dans la liste déroulante ne correspond pas au type attendu de la zone Host Identity. A titre d’exemple, si le type d’identité de l’hôte sélectionné est X500 Distinguished Name, vous devez entrer un nom spécifique correctement formaté dans la zone Host Identity. Solution : Assurez–vous que le nom spécifique entré est correct pour le type d’identité de l’hôte sélectionné dans la liste déroulante. Erreur : Une négociation IKE échoue et une entrée similaire au message suivant apparaît dans le fichier journal : inet_cert_service::channelOpen():clientInitIPC():error,r c =2 (No such file or directory) Problème : Le démon cpsd n’est pas actif ou s’est arrêté. Solution : Lancez IPSec avec Web–based System Manager. Cette action lance également les démons appropriés. Erreur : Une négociation IKE échoue et une entrée similaire au message suivant apparaît dans le fichier journal : CertRepo::GetCertObj: DN Does Not Match: (”/C=US/O=IBM/CN=ripple.austin.ibm.com”) Problème : Le type X500 Distinguished Name (DN, nom spécifique) sélectionné lors de la définition du tunnel IKE ne correspond pas au type X500 DN du certificat personnel. Solution : Modifiez la définition du tunnel IKE dans Web-based System Manager pour la faire correspondre au nom spécifique du certificat. Erreur : Lors de la définition des tunnels IKE dans Web–based System Manager, la case Certificat numérique est désactivée dans l’onglet Méthode d’authentification. Problème : La politique associée à ce tunnel n’utilise pas l’authentification en mode signature RSA. Solution : Pour utiliser la méthode d’authentification des signatures RSA, modifiez la conversion de la politique associée. A titre d’exemple, lors de la définition d’un tunnel IKE, choisissez la politique de gestion des clés IBM_low_CertSig. 11-60 Guide de sécurité Fonctions de suivi Il s’agit d’outils de débogage utilisés pour le suivi des événements du noyau. La fonction de suivi peut être utilisée pour obtenir de plus amples informations sur les erreurs ou les événements qui se sont produits dans le filtre du noyau et le code du tunnel. SMIT possède une fonction de suivi pour la sécurité IP, disponible via le menu Configuration avancée de la sécurité IP. Parmi les informations qui entrent dans le champ d’application de cette fonction de suivi figurent les informations sur les erreurs, les filtres, les tunnels, l’encapsulation/décapsulation et le chiffrement. Par conception, le suivi d’erreurs fournit les informations les plus importantes. L’utilitaire de suivi d’informations peut générer un volume d’informations important et nuire aux performances du système. Cette opération de suivi vous fournit des indices permettant d’identifier l’incident. Les informations de suivi seront nécessaires lorsque vous serez en contact avec un mainteneur. Pour accéder à la fonction de suivi, utilisez le raccourci SMIT smit ips4_tracing (pour IPv4) ou smit ips6_tracing (pour IPv6). ipsecstat Vous pouvez lancer la commande ipsecstat pour générer l’exemple de rapport suivant. Ce rapport indique que les unités de sécurité IP sont disponibles, que trois algorithmes d’authentification et trois algorithmes de chiffrement sont installés, et qu’il existe un rapport sur l’activité des paquets. Ces informations peuvent servir à identifier l’origine d’un incident si vous cherchez à résoudre les incidents liés au trafic de sécurité IP. IP Security Devices: ipsec_v4 Available ipsec_v6 Available Authentication Algorithm: HMAC_MD5 –– Hashed MAC MD5 Authentication Module HMAC_SHA –– Hashed MAC SHA Hash Authentication Module KEYED_MD5 –– Keyed MD5 Hash Authentication Module Encryption Algorithm: CDMF –– CDMF Encryption Module DES_CBC_4 –– DES CBC 4 Encryption Module DES_CBC_8 –– DES CBC 8 Encryption Module 3DES_CBC –– Triple DES CBC Encryption Module IP Security Statistics – Total incoming packets: 1106 Incoming AH packets:326 Incoming ESP packets: 326 Srcrte packets allowed: 0 Total outgoing packets:844 Outgoing AH packets:527 Outgoing ESP packets: 527 Total incoming packets dropped: 12 Filter denies on input: 12 AH did not compute: 0 ESP did not compute:0 AH replay violation:0 ESP replay violation: 0 Total outgoing packets dropped:0 Filter denies on input:0 Tunnel cache entries added: 7 Tunnel cache entries expired: 0 Tunnel cache entries deleted: 6 Remarque : Depuis AIX 4.3.3, la prise en charge CDMF a été supprimée car DES est désormais disponible dans le monde entier. Reconfigurez tous les tunnels qui utilisent CDMF en DES ou Triple DES. Sécurité IP (Internet Protocol) 11-61 Informations de référence sur la fonction de sécurité IP Liste des commandes ike cmd=activate Démarre une négociation IKE (Internet Key Exchange) (AIX versions 4.3.2 et ultérieures) ike cmd=remove Désactive les tunnels IKE (AIX versions 4.3.2 et ultérieures) ike cmd=list Répertorie les tunnels IKE (AIX versions 4.3.2 et ultérieures) ikedb Fournit l’interface vers la base de données des tunnels IKE (AIX versions 5.1 et ultérieures) gentun Crée une définition de tunnel mktun Active une ou plusieurs définitions de tunnel chtun Change la définition d’un tunnel rmtun Supprime la définition d’un tunnel lstun Répertorie une ou plusieurs définitions de tunnel exptun Exporte une ou plusieurs définitions de tunnel imptun Importe une ou plusieurs définitions de tunnel genfilt Crée une définition de filtre mkfilt Active une ou plusieurs définitions de filtre mvfilt Déplace une règle de filtre chfilt Change une définition de filtre rmfilt Supprime une définition de filtre lsfilt Répertorie une ou plusieurs définitions de filtre expfilt Exporte une ou plusieurs définitions de filtre impfilt Importe une ou plusieurs définitions de filtre ipsec_convert Indique l’état de la sécurité IP ipsecstat Indique l’état de la sécurité IP ipsectrcbuf Indique le contenu du tampon de suivi de la sécurité IP unloadipsec Décharge un module de chiffrement Liste des méthodes 11-62 defipsec Définit une instance de sécurité IP pour IP version 4 ou IP version 6 cfgipsec Configure et charge ipsec_v4 ou ipsec_v6 ucfgipsec Supprime la configuration de ipsec_v4 ou ipsec_v6 Guide de sécurité Chapitre 12. Sécurité NIS (Network Information Service) et NIS+ Ce chapitre explique brièvement comment NIS+ protège son espace de nom. Il comprend les sections suivantes : • Méthodes de protection du système d’exploitation, page 12-1 • Système de protection NIS+, page 12-2 • Authentification et données d’identification NIS+, page 12-5 • Autorisation et accès NIS+, page 12-7 • Droits d’administrateur et sécurité NIS+, page 12-10 • Informations de référence sur la sécurité NIS+, page 12-11 Méthodes de protection du système d’exploitation La sécurité du système d’exploitation est assurée par des portes que les utilisateurs doivent franchir avant d’entrer dans l’environnement du système d’exploitation, et des tableaux de droits d’accès qui déterminent ce qu’ils sont autorisés à faire dans cet environnement. Dans certains contextes, les mots de passe RPC sécurisés sont appelés mots de passe réseau. Le système complet comprend quatre portes et deux tableaux de droits d’accès : Porte de numérotation Pour accéder à un environnement de système d’exploitation donné depuis l’extérieur à l’aide d’un modem et d’une ligne téléphonique, vous devez fournir un mot de passe de numérotation et un ID de connexion valides. Porte de connexion Pour accéder à un environnement de système d’exploitation donné, vous devez fournir un mot de passe utilisateur et un ID de connexion valides. Porte root Pour bénéficier des droits d’accès root, vous devez fournir un mot de passe utilisateur root valide. Porte RPC sécurisée Dans un environnement NIS+ fonctionnant au niveau de sécurité 2 (valeur par défaut), lorsque vous essayez d’utiliser des services NIS+ et d’accéder aux objets NIS+ (serveurs, répertoires, tables, entrées de tables, etc), NIS+ confirme votre identité à l’aide du processus RPC sécurisé. Le franchissement d’une porte RPC sécurisée nécessite un mot de passe RPC sécurisé. Votre mot de passe RPC sécurisé et votre mot de passe de connexion sont généralement identiques. Si c’est le cas, vous franchissez automatiquement la porte sans avoir à entrer de nouveau votre mot de passe. Dans certains contextes, les mots de passe RPC sécurisés sont appelés mots de passe réseau Consultez la section Secure RPC Password versus Login Password du manuel AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide, pour obtenir des informations sur l’utilisation de deux mots de passe différents.) Un ensemble de données d’identification est utilisé pour transmettre vos requêtes automatiquement via la porte RPC sécurisée. Le processus qui génère, présente et valide vos données d’identification est nommé authentification car il confirme votre identité et le fait que vous disposez d’un mot de passe RPC sécurisé valide. Cette authentification est automatiquement effectuée à chaque requête au service NIS+. Sécurité NIS (Network Information Service) et NIS+ 12-1 Dans un environnement NIS+ fonctionnant en mode de compatibilité NIS, la protection fournie par la porte RPC sécurisée est limitée. Tout le monde a les droits d’accès en lecture sur tous les objets NIS+ et les droits de modifier les entrées qui les concernent, qu’ils disposent ou non de données d’identification valides (c’est à dire, peu importe que le processus d’authentification ait ou non confirmé leur identité et validé leur mot de passe RPC sécurisé). Comme cette situation permet à tous d’accéder en lecture à tous les objets NIS+ et de modifier les entrées qui les concernent, un réseau NIS+ fonctionnant en mode de compatibilité est moins sécurisé qu’un même réseau en mode normal. En terminologie RPC sécurisé, tout utilisateur sans référence valide est considéré comme membre de la classe nobody. Consultez la section Classes d’autorisation, page 12-7 pour une description des quatre classes. Pour des détails sur la gestion des authentifications et données d’identification NIS+, consultez la section Administering NIS+ Credentials du manuel AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Tableau des fichiers et répertoires Une fois que vous avez accédé à un environnement de système d’exploitation, les droits d’accès applicables définissent votre capacité à lire, exécuter, modifier, créer et détruire des fichiers et répertoires. Tableau des objets NIS+ Une fois que vous avez été authentifié correctement par NIS+, les droits d’accès applicables régissent votre capacité à lire, exécuter, modifier, créer et détruire des objets NIS+. Ce processus est appelé autorisation NIS+. Pour des détails sur les permissions et autorisations NIS+, consultez la section Administering NIS+ Access Rights de AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Système de protection NIS+ La sécurité NIS+ est un élément essentiel de l’espace de nom NIS+. Vous ne pouvez pas configurer la sécurité indépendamment de l’espace de nom. Les instructions de configuration de la sécurité sont donc réparties dans les étapes de configuration des autres éléments de l’espace de nom. Une fois qu’un environnement de sécurité NIS+ a été configuré, vous pouvez ajouter et supprimer des utilisateurs, modifier les droits d’accès, modifier la répartition des membres de groupes, et exécuter toutes les autres tâches de gestion du réseau. Les fonctions de sécurité de NIS+ protègent la structure l’espace de nom et les informations qu’il contient contre les accès non autorisés. Sans ces fonctions, tout client NIS+ pourrait obtenir, modifier, voire endommager les informations stockées dans l’espace de nom. La sécurité NIS+ remplit deux objectifs : Authentification L’authentification permet d’identifier les mandants NIS+. Chaque fois qu’un mandant (un utilisateur ou un poste) tente d’accéder à un objet NIS+, son identité et son mot de passe RPC sécurisé sont confirmés et validés. Vous n’avez normalement pas besoin d’entrer un mot de passe dans le cadre de l’authentification. Cependant, si votre mot de passe RPC sécurisé est différent de votre mot de passe de connexion, vous devez exécuter un keylogin lors de votre première tentative d’accès aux objets ou services NIS+. Pour exécuter un keylogin, vous devez fournir un mot de passe RPC sécurisé valide. Consultez la section Secure RPC Password versus Login Password du AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Autorisation 12-2 Guide de sécurité L’autorisation permet de spécifier des droits d’accès. Chaque fois qu’un mandant NIS+ tente d’accéder à des objets NIS+, il est placé dans l’une des quatre classes d’autorisation (propriétaire, groupe, monde, personne). Le système de sécurité NIS+ permet aux administrateurs NIS+ de spécifier différents droits de lecture, modification, création, ou destruction sur les objets NIS+ pour chaque classe. Par exemple, une classe pourrait être autorisée à modifier une colonne donnée de la table passwd mais pas à lire cette colonne, ou une autre classe pourrait être autorisée à lire des entrées d’une table mais pas des autres. Par exemple, les informations d’une table NIS+ donnée peuvent être lues et modifiées par une classe, seulement lues par une autre classe, et ni lues ni modifiées par une troisième classe. Le concept est identique à celui des droits d’accès aux fichiers et répertoires du système d’exploitation. Consultez la section Classes d’autorisation, page 12-7, pour plus d’informations sur les classes. L’authentification et l’autorisation empêchent un utilisateur bénéficiant de droits d’accès root sur un poste A d’utiliser la commande su pour prendre l’identité d’un autre utilisateur non connecté, ou connecté sur un poste B, et d’accéder aux objets NIS+ avec les droits d’accès NIS+ de l’autre utilisateur. Cependant, NIS+ ne peut empêcher un utilisateur connaissant le mot de passe de connexion d’un autre utilisateur de prendre son identité et de bénéficier de ses droits d’accès NIS+. NIS+ ne peut pas non plus empêcher un utilisateur bénéficiant de droits d’accès root de prendre l’identité d’un autre utilisateur connecté depuis le même poste. La figure suivante illustre ce processus. Figure 13. Résumé du processus de sécurité NIS+ Cette illustration représente le processus de sécurité NIS+. 1. Le client/mandant envoie une requête au serveur NIS+ pour accéder à un objet NIS+. 2. Le serveur authentifie l’identité du client en examinant ses données d’identification. 3. Les clients dont les données d’identification sont valides sont placés dans la classe monde (world). 4. Les clients dont les données d’identification ne sont pas valides sont placés dans la classe personne (nobody). 5. Le serveur examine la définition de l’objet pour déterminer la classe du client. 6. Si les droits d’accès de la classe du client correspondent au type d’opération demandée, l’opération est exécutée. Sécurité NIS (Network Information Service) et NIS+ 12-3 Mandants NIS+ Les mandants NIS+ sont les entités (clients) qui envoient des requêtes de services NIS+. Un mandant NIS+ peut être une personne connectée à un poste client en tant qu’utilisateur courant ou utilisateur root, ou tout processus fonctionnant avec des droits d’accès root sur un poste client NIS+. Ainsi, un mandant NIS+ peut être un utilisateur client ou un poste de travail client. Un mandant NIS+ peut aussi être l’entité qui fournit un service NIS+ depuis un serveur NIS+. Tous les serveurs NIS+ étant aussi des clients NIS+, la plupart des sujets couverts s’appliquent aussi aux serveurs. Niveaux de sécurité NIS+ Les serveurs NIS+ fonctionnent dans l’in de deux niveaux de sécurité. Ces niveaux déterminent les types de références que les mandants doivent fournir pour authentifier leurs requêtes. NIS+ est conçu pour fonctionner au niveau de sécurité maximum, le niveau 2. Le niveau 0 ne sert que pour les tests, la configuration et le débogage. Ces niveaux de sécurité sont résumés dans le tableau suivant. Remarque : Utilisez Web–based System Manager, SMIT, ou la commande passwd pour modifier votre mot de passe indépendamment du niveau de sécurité ou de l’état des données d’identification. Niveaux de sécurité NIS+ 12-4 Niveau de sécurité Description 0 Le niveau de sécurité 0 est prévu pour les tests et la configuration de l’espace de nom NIS+ initial. Un serveur NIS+ fonctionnant au niveau 0 accorde à un mandant NIS+ des droits d’accès complets à tous les objets NIS+ du domaine. Le niveau 0 est uniquement destiné à la configuration et ne doit être utilisé que par les administrateurs et dans ce but. Le niveau 0 ne doit pas être utilisé sur des réseaux en fonctionnement normal, par des utilisateurs courants. 1 Le niveau de sécurité 1 utilise la sécurité AUTH_SYS. Ce niveau n’est pas pris en charge par NIS+ et ne doit pas être utilisé. 2 Le niveau de sécurité 2 est le niveau par défaut. C’est le plus haut niveau de sécurité de NIS+. Il n’authentifie que les requêtes qui utilisent les données d’identification DES (data encryption standard). Les requêtes sans donnée d’identification sont affectées à la classe personne et disposent des droits d’accès correspondants. Les requêtes utilisant des données d’identification DES non valides sont réessayées. Après un nouvel échec d’obtention de données d’identification DES valides, les requêtes échouent, accompagnées d’une erreur d’authentification. Une donnée d’identification peut ne pas être valide pour diverses raisons, par exemple, le mandant peut ne pas être connecté via keylogin sur le poste, les horloges peuvent être désynchronisées, il peut y avoir une non–correspondance de clef, etc. Guide de sécurité Authentification et données d’identification NIS+ Les données d’identification NIS+ authentifient l’identité de chaque mandant qui envoie une requête de service NIS+ ou accède à un objet NIS+. Le processus de d’identification/autorisation NIS+ est une implémentation du système RPC sécurisé. Le système de données d’identification/autorisation empêche un utilisateur de prendre l’identité d’un autre. Il empêche un utilisateur avec des droits d’accès root sur un poste d’utiliser la commande su pour prendre l’identité d’un autre utilisateur non connecté ou connecté sur un autre poste, et d’accéder aux objets NIS+ avec les droits d’accès NIS+ de l’autre utilisateur. Remarque : NIS+ ne peut pas empêcher un utilisateur qui connaît le mot de passe de connexion d’un autre utilisateur de prendre l’identité et les droits d’accès NIS+ de cet utilisateur. NIS+ ne peut pas non plus empêcher un utilisateur bénéficiant de droits d’accès NIS+ de prendre l’identité d’un autre utilisateur connecté depuis le même poste. Un fois un mandant authentifié par un serveur, ce serveur contrôle l’objet NIS+ auquel le mandant souhaite accéder pour savoir quelles opérations lui sont accessibles. Consultez la section Autorisation et accès NIS+, page 12-7, pour plus d’informations sur les autorisations. Données d’identification des utilisateurs et des postes Il existe deux types de mandants, les utilisateurs et les postes, et donc deux types de données d’identification : Données d’identification des utilisateurs Lorsqu’une personne est connectée à un client NIS+ en tant qu’utilisateur courant, les requêtes de services NIS+ comprennent ses données d’identification. Données d’identification des postes Lorsqu’un utilisateur est connecté à un client NIS+ en tant qu’utilisateur root, les requêtes de services utilisent les données d’identification du poste client. Données d’identification locales et DES Les mandants NIS+ peuvent avoir deux types de données d’identification : locales et DES. Données d’identification DES Les données d’identification DES (Data Encryption Standard) assurent une authentification sécurisée. Lorsque ce manuel indique que NIS+ contrôle des données d’identification pour authentifier un mandant NIS+, cela veut dire que NIS+ valide des données d’identification DES. L’utilisation de données d’identification DES n’est que l’une des méthodes d’authentification. Ne confondez pas les données d’identification DES avec les données d’identification NIS+. Chaque fois qu’un mandant demande un service NIS+ ou accède à un objet NIS+, le logiciel utilise les informations d’identification stockées pour ce mandant pour générer ses données d’identification. Les données d’identification DES sont générées à partir d’informations crées pour chaque mandant par un administrateur NIS+, comme expliqué dans la section Administering NIS+ Credentials du AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. • Une fois la validité des données d’identification DES d’un mandant confirmée par NIS+, ce mandant est authentifié. Sécurité NIS (Network Information Service) et NIS+ 12-5 • Un mandant doit être authentifié avant d’être placé dans la classe propriétaire, groupe, ou monde. C’est à dire que vous devez disposer de données d’identification DES valides pour être placé dans l’une de ces classes. Les mandants sans données d’identification DES valides sont automatiquement placés dans la classe personne. • Les informations sur les données d’identification DES sont toujours stockées dans la table cred du domaine d’accueil du mandant, que ce mandant soit un utilisateur client ou un poste de travail client. Données d’identification locales Les données d’identification locales sont une correspondance entre un numéro d’ID utilisateur et son nom de mandant NIS+ qui comprend son nom de domaine d’accueil. Lorsque des utilisateurs se connectent, le système contrôle leurs données d’identification, et identifie leur domaine d’accueil où sont stockées leurs données d’identification DES. Le système utilise ces informations pour obtenir les données d’identification DES des utilisateurs. Lorsque des utilisateurs se connectent à un domaine distant, ces requêtes utilisent leurs données d’identification locales qui font référence à leur domaine d’accueil. NIS+ interroge alors le domaine d’accueil de l’utilisateur pour obtenir ses données d’identification DES. L’utilisateur peut ainsi être authentifié sur un domaine distant bien que ses données d’identification DES n’y soient pas stockées. La figure suivante illustre ce concept. Figure 14. Données d’identification et domaines Cette illustration représente une hiérarchie de domaine. Le domaine d’accueil de l’utilisateur contient les données d’identification locales et DES. Le sous–domaine ne contient que les données d’identification locales. Le domaine d’accueil et le sous–domaine sont indiqués comme Données d’identification de l’utilisateur client. Données d’identification et domaines Les données d’identification locales peuvent être stockées dans n’importe quel domaine. Pour se connecter à un domaine distant et être authentifié, un utilisateur client doit avoir des données d’identification locales dans la table cred du domaine distant. Si ce n’est pas le cas, NIS+ ne peut pas localiser son domaine d’accueil pour obtenir ses données d’identification DES. L’utilisateur ne pourrait alors pas être authentifié et serait placé dans la classe personne. Types d’utilisateurs et types de données d’identification Un utilisateur peut disposer des deux types de données d’identification, mais un poste peut seulement avoir des données d’identification DES. Les utilisateurs root ne peuvent accéder par NIS+ aux autres postes, en tant que root, car l’UID root de chaque poste est toujours zéro. Si un utilisateur root (UID=0) du poste A tente d’accéder au poste B en tant que root, il entre en conflit avec les utilisateurs root (UID=0) du poste B. Des données d’identification locales ne sont donc pas appropriées pour un poste de travail client. Elles ne conviennent que pour les utilisateurs clients. 12-6 Guide de sécurité Autorisation et accès NIS+ La principale fonction de l’autorisation NIS+ est de préciser pour chaque mandant NIS+ les droits d’accès à chaque objet et service NIS+. Une fois authentifié, un mandant qui émet une requête NIS+ est placé dans une classe d’autorisation. Les droits d’accès (permissions) qui précisent les opérations qui peuvent être effectuées par un mandant sur un objet NIS+ donné sont définis en fonction des classes. En d’autres termes, les droits d’accès varient d’une classe d’autorisation à l’autre. Classes d’autorisation Il en existe quatre : propriétaire (owner), groupe (group), monde (world) et personne (nobody). Consultez la section Classes d’autorisation, page 12-7 pour plus d’informations sur les classes. Droits d’accès Ils sont de quatre types : création, destruction, modification et lecture. Consultez la section Droits d’accès NIS+, page 12-9 pour plus d’informations. Classes d’autorisation Les objets NIS+ ne confèrent pas directement de droit d’accès aux mandants NIS+. Ils accordent des droits d’accès sur la base des quatre classes de mandants suivants : Propriétaire Le mandant propriétaire (owner) de l’objet dispose des droits accordés à la classe des propriétaires. Groupe A chaque objet NIS+ est associé un groupe (group). Les membres du groupe d’un objet sont désignés par l’administrateur NIS+. Les mandants qui appartiennent à la classe Group d’un objet disposent des droits accordés à cette classe (ici, le terme groupe désigne les groupes NIS+, et non des groupes de système d’exploitation ou réseau ; reportez–vous à Classe Groupe, page 12-8 pour une description des groupes NIS+). Monde Cette classe (world) regroupe tous les mandants NIS+ authentifiés par un serveur C’est–à–dire tous les mandants authentifiés mais n’appartenant ni à la classe Propriétaire ni à la classe Groupe. Personne Tous les mandants font partie de cette classe (nobody), y compris ceux qui n’ont pas été authentifiés. Reportez–vous à la figure suivante pour une illustration des classes. Figure 15. Classes d’autorisation Représentation schématique des relations entre les classes d’autorisation. Le plus petit ensemble représente le groupe Propriétaire ; il est inclus dans l’ensemble Groupe. Celui–ci est inclus dans le groupe Monde, lui–même inclus dans le groupe Personne. Sécurité NIS (Network Information Service) et NIS+ 12-7 A chaque requête NIS+, le système détermine à quelle classe appartient le mandant émetteur. Celui–ci peut ensuite utiliser tous les droits dont dispose cette classe. Un objet peut accorder n’importe quelle combinaison de droits d’accès à chaque classe. En général, une classe supérieure dispose généralement des mêmes droits qu’une classe inférieure, et éventuellement de droits supplémentaires. Par exemple, un objet peut attribuer un accès en lecture aux classes Personne et Monde, un accès en lecture et modification à la classe Groupe, et un accès en lecture, modification, création et destruction à la classe Propriétaire. Les quatre classes sont décrites en détail dans les paragraphes qui suivent. Classe Propriétaire Le mandant propriétaire est unique. Les mandants qui présentent une requête d’accès à un objet NIS+ doivent être authentifiés (présenter des données d’identification DES valides) avant de se voir accorder des droits d’accès de propriétaire. Par défaut, le propriétaire d’un objet est le mandant qui l’a créé. Cependant, il peut céder cette propriété à un autre mandant des deux manières suivantes : • Le mandant définit un propriétaire différent lors de la création de l’objet (voir la section Specifying Access Rights in Commands du AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide). • Le mandant modifie le propriétaire après la création de l’objet (voir la section Specifying Access Rights in Commands du AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide). En abandonnant la propriété de l’objet, le mandant perd tous les droits afférents et ne conserve que les droits attribués par l’objet à la classe Groupe, Monde ou Personne. Classe Groupe Le groupe NIS+ d’un objet est unique (ici, le terme groupe désigne les groupes NIS+, et non des groupes de système d’exploitation ou réseau). Les mandants qui présentent une requête d’accès à un objet NIS+ doivent être authentifiés (présenter des données d’identification DES valides) et appartenir au groupe avant de se voir accorder les droits d’accès du groupe. 12-8 Guide de sécurité Un groupe NIS+ est constitué de mandants NIS+ réunis de manière à faciliter l’accès à l’espace de nom. Les droits d’accès accordés à un groupe NIS+ s’appliquent à tous les mandants membres de ce groupe. Le propriétaire d’un objet, cependant, n’a pas besoin d’appartenir au groupe de l’objet. Le créateur d’un objet peut opter pour un groupe par défaut au moment de la création. Un groupe spécifique peut être défini au moment de la création, ou créé ultérieurement. Les informations relatives aux groupes NIS+ sont stockées dans les objets du groupe NIS+, dans le sous–répertoire groups_dir de chaque domaine NIS+. Notez que les informations relatives aux groupes NIS+ sont stockées dans la table du groupe NIS+. Elle contient les informations relatives aux groupes système d’exploitation. Pour des instructions sur l’administration des groupes NIS+, reportez–vous à la section Administering NIS+ Groups du AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Classe Monde La classe Monde regroupe tous les mandants NIS+ authentifiés par NIS+, c’est–à–dire tous les membres des classes Propriétaire et Groupe, ainsi que tous les mandants présentant des données d’identification DES valides. Les droits d’accès accordés à la classe Monde s’appliquent donc à tous les mandants authentifiés. Classe Personne Cette classe contient tous les mandants, y compris ceux qui ne présentent pas de données d’identification DES valides. Classes d’autorisation et hiérarchie des objets NIS+ La sécurité NIS+ utilise des classes d’autorisation indépendamment de la hiérarchie des objets. Les objets répertoires représentent le niveau le plus élevé de la hiérarchie par défaut. Viennent ensuite les objets groupe ou table, puis les colonnes et enfin les entrées. Les définitions suivantes apportent des précisions sur chaque niveau : Niveau répertoire Chaque domaine NIS+ contient deux objets répertoires NIS+ : groups_dir et org_dir. Chaque objet répertoire groups_dir contient plusieurs groupes. Chaque objet répertoire org_dir contient plusieurs tables. Niveau groupe ou table Les groupes contiennent des entrées, éventuellement d’autres groupes. Les tables contiennent des colonnes et des entrées. Niveau colonne Un tables comporte une ou plusieurs colonnes. Niveau entrée (ligne) Chaque groupe ou tables comporte une ou plusieurs entrées. Les quatre classes d’autorisation s’appliquent à tous les niveaux. Par conséquent, un objet répertoire dispose d’un propriétaire et d’un groupe. Chaque table d’un objet répertoire dispose de son propre propriétaire et de son propre groupe, qui peuvent être différents du propriétaire et du groupe de l’objet répertoire. A l’intérieur d’une table, une colonne ou une entrée peut avoir son propre propriétaire ou son groupe, qui peuvent aussi être différents du propriétaire et du groupe de la table ou du répertoire. Droits d’accès NIS+ Les objets NIS+ définissent des droits d’accès pour les mandants NIS+, de la même façon que les fichiers définissent les permissions des utilisateurs dans un système d’exploitation. Les droits d’accès déterminent les opérations que les mandants NIS+ sont autorisés à effectuer sur les objets NIS+ (vous pouvez les consulter à l’aide de la commande niscat –o). Sécurité NIS (Network Information Service) et NIS+ 12-9 Les opérations NIS+ varient selon les différents types d’objets, mais toutes peuvent être rangées dans l’une des quatre catégories de droits d’accès : lecture, modification, création et destruction. Lecture Un mandant qui dispose de ces droits sur un objet peut lire son contenu. Modification Un mandant qui dispose de ces droits sur un objet peut en modifier le contenu. Destruction Un mandant qui dispose de ces droits sur un objet peut le détruire ou le supprimer. Création Un mandant disposant de ces droits à un certain niveau d’objet peut créer des objets à l’intérieur de ce niveau. Ainsi, si vous disposez de droits de création dans un objet répertoire NIS+, vous avez la possibilité de créer de nouvelles tables dans ce répertoire. De même, si vous disposez de droits de création dans une table NIS+, vous pouvez créer de nouvelles colonnes ou entrées dans cette table. Toutes les communications entre les clients et les serveurs NIS+ sont des requêtes pour l’exécution de l’une de ces opérations sur un objet NIS+ spécifique. Par exemple, lorsqu’un mandant NIS+ demande l’adresse IP d’un autre poste de travail, il demande en fait un accès en lecture sur l’objet table hosts, qui répertorie ce type d’informations. Lorsqu’un mandant demande au serveur d’ajouter un répertoire à l’espace de nom NIS+, il demande en fait un accès en modification à l’objet parent du répertoire. Ces droits se répercutent de manière logique vers les niveaux inférieurs, du répertoire à la table, et de la table à la colonne et à l’entrée. Par exemple, pour créer une nouvelle table, vous devez disposer de droits de création dans l’objet répertoire NIS+ dans lequel elle sera stockée. Lorsque vous créez cette table, vous en devenez le propriétaire par défaut. En tant que tel, vous pouvez vous attribuer des droits de création sur cette table, ce qui vous permettra de créer de nouvelles entrées dans celle–ci. Lorsque vous créez de nouvelles entrées dans une table, vous devenez le propriétaire par défaut de ces entrées. En tant que propriétaire de la table, vous pouvez attribuer à d’autres des droits de création au niveau de la table. Par exemple, vous pouvez attribuer à la classe Groupe de votre table des droits de création au niveau table. Dans ce cas, tout membre du groupe de la table peut créer de nouvelles entrées dans la table. Un membre du groupe qui crée une nouvelle entrée dans la table devient par défaut le propriétaire de cette entrée. Droits d’administrateur et sécurité NIS+ NIS+ n’impose pas que l’administrateur soit unique. Celui qui dispose de droits d’administration sur un objet (c’est–à–dire des droits de création et de destruction, et pour certains objets des droits de modification) est considéré comme l’administrateur NIS+ de cet objet. Les droits d’accès initiaux d’un objet NIS+ sont définis par son créateur. Si le créateur de l’objet limite les droits d’administration au propriétaire (le créateur, au départ), alors seul le propriétaire dispose de droits d’administration sur cet objet. Si le créateur accorde des droits d’administration au groupe de l’objet, alors tous les membres de ce groupe disposent de droits d’administration sur l’objet. Vous pouvez même accorder des droits d’administration à la classe Monde, voire à la classe Personne. Mais le fait d’attribuer des droits d’administration au–delà de la classe Groupe invalide la sécurité NIS+. Par conséquent, si vous attribuez des droits d’administrateur à la classe Monde ou Personne, vous allez à l’encontre du principe même de la sécurité NIS+. 12-10 Guide de sécurité Informations de référence sur la sécurité NIS+ Les commandes suivantes permettent de gérer les mots de passe, les données d’identification et les clés (pour plus de détails, reportez–vous aux descriptions des commandes) : chkey Change la paire de clés RPC sécurisée d’un mandant. Si vous ne souhaitez pas refaire le chiffrement de votre clé privée, utilisez plutôt passwd. La commande chkey n’affecte pas l’entrée du mandant, que ce soit dans la table de mots de passe ou dans le fichier /etc/passwd. keylogin Déchiffre et stocke la clé privée d’un mandant dans le démon keyserv. keylogout Supprime la clé privée stockée sur le keyserv. keyserv Autorise le serveur à stocker des clés de chiffrement privées. newkey Crée une nouvelle paire de clés dans la base de données de clés publiques. nisaddcred Crée des données d’identification pour les mandants NIS+. nisupdkeys Met à jour les clés publiques dans les objets répertoire. passwd Change et gère le mot de passe des mandants. Sécurité NIS (Network Information Service) et NIS+ 12-11 12-12 Guide de sécurité Chapitre 13. Sécurité NFS (Network File System) Le service NFS (Network File Service) s’ajoute au système standard d’authentification apporté par UNIX, et offre un moyen d’authentifier les utilisateurs et machines d’un réseau message par message. Ce système d’authentification complémentaire utilise le chiffrement DES (Data Encryption Standard) et le chiffrement par clé publique. Ce chapitre traite des points suivants : • Confidentialité, page 13-1 • Authentification NFS, page 13-3 • Noms des entités réseau pour authentification DES, page 13-6 • Fichier /etc/publickey, page 13-6 • Remarques sur l’amorçage des systèmes à clé publique, page 13-6 • Remarques sur les performances de NFS sécurisé, page 13-7 • Administration de NFS sécurisé, page 13-7 • Configuration de NFS sécurisé, page 13-8 • Exportation d’un système de fichiers via NFS sécurisé, page 13-9 • Montage d’un système de fichiers NFS sécurisé, page 13-10 Confidentialité Tout au long de l’histoire, les hommes ont cherché le moyen de communiquer de façon sécurisée, par des messages dont le contenu ne soit intelligible que par l’expéditeur et le destinataire : c’est ainsi que le chiffrement a fait son apparition. Il s’agit de convertir un texte en clair en un texte chiffré, et réciproquement. Le chiffrement est le processus de conversion d’un texte en clair en texte chiffré, et le déchiffrement, le processus inverse. L’une des premières méthodes, le code César, est attribué à Jules César. Il s’agit de substituer systématiquement une lettre par une autre. Ainsi, ’A’ devient ’C’, ’B’ devient ’D’, ..., ’Y’ devient ’A’ et ’Z’ devient ’B’. Par exemple, la phrase ATTACK AT DAWN devient CVVCEM CV FCYP. Si les Carthaginois avaient réussi à briser le code, les cryptographes romains auraient dû en inventer un autre. Cette recherche étant coûteuse, les Romains ont imaginé de définir une clef de codage, permettant d’exploiter un peu plus efficacement le chiffrement. Par exemple, au lieu d’une substitution lettre par lettre, ils ont spécifié une clé, K, K indiquant le nombre de décalage entre les lettres substituées. Ainsi, si K = 2, ’A’ devient ’C’. Si K = 4, ’A’ devient ’E’, etc. Avec ce schéma, si les Carthaginois décryptent le code, il suffit aux Romains de changer de clé. Si les Carthaginois avaient compris en quoi consistait le système de codage romain, il leur aurait suffi d’essayer les 26 valeurs possibles pour K. S’ils avaient disposé d’un ordinateur, cette tâche aurait été réduite à un exercice de programmation d’une grande simplicité. Network File System (NFS) Security 13-1 Chiffrement DES (Data Encryption Standard) Les algorithmes de chiffrement modernes sont conçus en sachant que les ordinateurs sont de puissants outils, offrant d’importants moyens de décodage. En 1977, le gouvernement américain a adopté un standard de chiffrement, le chiffrement DES (DataEncryption Standard). Il est largement utilisé dans l’industrie. Il s’agit d’un algorithme fort complexe, qui convertit le texte en clair en texte codé, par blocs de 64 bits, à l’aide d’une clé de 56 bits. Compte tenu de la complexité de l’algorithme et de la taille de la clé, DES est difficile à casser : en supposant qu’un intrus dispose d’un ordinateur capable d’analyser l’algorithme DES à la vitesse d’une clé par microseconde, il lui faudrait déjà deux mille ans pour tester toutes les clés. Chiffrement par clé publique Le point faible de tout algorithme de chiffrement est sa clé. Si l’expéditeur et le destinataire doivent communiquer en sécurité via un code de chiffrement, l’un comme l’autre doivent connaître la clé. Ils doivent se mettre d’accord sur la clé via une liaison distincte, sécurisée elle aussi bien entendu, ou directement (en personne). Pour résoudre ce problème, deux chercheurs (Diffie et Hellman) ont développé une technique grâce à laquelle émetteur et destinataire peuvent se communiquer leur clé, sans compromettre la sécurité de leurs échanges. Cette technique suppose trois règles : • Déchiffrement( Chiffrement( texte en clair, E ), D ) = texte en clair E étant la clé de chiffrement (publique) et D, la clé de déchiffrement (connue du seul destinataire). Cette règle signifie que les fonctions de chiffrement/déchiffrement sont inverses l’une de l’autre : si vous appliquez au texte codé généré par Chiffrement (texte en clair, E) la fonction Déchiffrement avec la clé D, vous obtenez le texte en clair d’origine. • Un intrus ne peut déduire la fonction Déchiffrement() de la fonction Chiffrement(). • Chiffrement() est inviolable. Voici la procédure d’envoi d’un message secret. 1. L’expéditeur demande la clé de chiffrement publique. 2. Il convertit son texte en appliquant la fonction : texte_codé = Chiffrement( texte_clair, E) 3. Il envoie le texte codé au destinataire. 4. Le destinataire reçoit le texte et le convertit par la fonction : texte_clair = Déchiffrement( texte_codé, D) Même s’il intercepte le message, un intrus ne peut le décoder puisqu’il ne possède pas la clé de déchiffrement. (L’expéditeur lui–même ne la connaît pas.) 13-2 Guide de sécurité Authentification Une des principales applications de la confidentialité est l’authentification. Le plus souvent, l’authentification fait appel aux mots de passe (l’authentification standard UNIX notamment) : un utilisateur souhaitant se connecter doit fournir un mot de passe, connu uniquement du système et de l’utilisateur. Si le mot de passe est correct, le système suppose que l’utilisateur est bien celui qu’il déclare être. Cette méthode requiert de stocker les mots de passe dans un fichier système, ce qui, même si ce fichier est codé, présente des risques. Elle suppose aussi que deux entités aient connaissance du mot de passe. Le chiffrement par clé publique offre une alternative à l’authentification par mot de passe. Soit un expéditeur souhaitant envoyant un message, et un destinataire qui a besoin d’être sûr de l’identité de l’expéditeur. Le processus est le suivant : 1. L’expéditeur chiffre un message de ”demande pour émettre” (RTS) avec la clé de chiffrement publique et envoie la demande. 2. Le destinataire reçoit le message de ”demande pour émettre” et le déchiffre à l’aide de sa clé privée. 3. Le destinataire chiffre un message ”jeton” à l’aide de la clé publique de l’expéditeur et envoie le jeton. 4. L’expéditeur reçoit le jeton, et le déchiffre à l’aide de sa clé privée. Il commencera ensuite tous les messages qu’il envoie par ce jeton, certifiant ainsi son identité. Un intrus qui tenterait d’envoyer des messages au nom de l’expéditeur les verrait rejetés par le destinataire, qui constaterait l’absence de jeton. Notez que, contrairement à l’authentification par mot de passe, le destinataire peut authentifier l’expéditeur sans connaître sa clé privée. Pour plus de détails sur les systèmes d’authentification, consultez la section Understanding RPC Authentication du manuel AIX 5L Version 5.2 Communications Programming Concepts. Authentification NFS NFS fait usage de l’algorithme DES à deux fins. NFS l’utilise pour chiffrer un horodatage dans les messages RPC transitant entre les clients et les serveurs NFS. Cet horodatage chiffré permet d’authentifier les machines de la même façon qu’un jeton pour un expéditeur. NFS pouvant authentifier n’importe quel message RPC échangé entre clients et serveurs NFS, un niveau de sécurité supplémentaire (optionnel) peut être associé à chaque système de fichiers. Par défaut, les systèmes de fichiers sont exportés avec l’authentification UNIX standard. Pour bénéficier de l’option de sécurité renforcée, spécifiez secure lorsque vous exportez un système de fichiers. Chiffrement par clé publique pour NFS sécurisé Les clés publique et privée sont toutes deux stockées et indexées par leur nom réseau dans la mappe publickey.byname. La clé privée est chiffrée via DES avec le mot de passe de connexion de l’utilisateur. La commande keylogin utilise la clé privée chiffrée, la déchiffre avec le mot de passe de connexion et la transmet à un serveur sécurisé de clés locales, pour un usage ultérieur dans les transactions RPC. Les utilisateurs ne connaissent ni leur clé publique, ni leur clé privée, car la commande yppasswd, outre le fait de modifier le mot de passe de connexion, génère les clés (publique et privée) automatiquement. Le démon keyserv est un service RPC, actif sur chaque machine NIS et NIS+. Pour des détails sur l’utilisation de keyserv par NIS+, consultez le AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Dans NIS, keyserv exécute les trois sous–routines à clef publique suivantes : Network File System (NFS) Security 13-3 • key_setsecret • key_encryptsession • key_decryptsession key_setsecret indique au serveur de clés de stocker la clé privée de l’utilisateur (SK A ) pour un usage ultérieur. Elle est normalement appelée par la commande keylogin. Le programme client appelle key_encryptsession pour générer la clé de conversation chiffrée, qui est passée à la première transaction RPC vers un serveur. Le serveur de clés recherche la clé publique du serveur et la combine à la clé privée du client (définie par une sous–routine key_setsecret précédente) pour générer la clé commune. Le serveur demande au serveur de clés de déchiffrer la clé de conversation en appelant la sous–routine key_decryptsession. Ces appels de sous–routines supposent un appelant, qui doit lui aussi être authentifié. Pour ce faire, le serveur de clés ne peut pas utiliser l’authentification DES, qui provoquerait un blocage total. Il résout le problème en stockant les clés privées par leur ID utilisateur (UID) et en ne répondant qu’aux demandes des processus root locaux. Le processus client exécute ensuite une sous–routine setuid, appartenant à l’utilisateur root, qui effectue la demande “ de la part ” du client, indiquant au serveur de clés l’UID réel du client. Règles d’authentification L’authentification sur NFS sécurisé est basée sur la capacité d’un expéditeur à chiffrer l’heure courante, que le destinataire peut déchiffrer et comparer avec sa propre horloge. Ce processus suppose : • Que les deux agents soient d’accord sur l’heure, • Qu’ils utilisent la même clé de chiffrement DES. Accord sur l’heure Si le réseau utilise la synchronisation d’horloge, le démon timed assure la synchronisation des horloges client et serveur. Sinon, le démon détermine l’heure sur la base de l’horloge du serveur. Il détermine l’heure du serveur avant d’ouvrir la session RPC, calcule le décalage entre son horloge et celle du serveur, et règle son horloge en conséquence. Si, au cours d’une session RPC, les horloges viennent à être désynchronisées au point que le serveur commence à rejeter les demandes client, il appartient au client de réitérer le réglage. Accord sur la clé DES Client et serveur déterminent la clé de chiffrement DES à l’aide du chiffrement par clé publique. Pour tout couple client A et serveur B, il existe une clé que seuls A et B peuvent déduire. Cette clé est appelée clé commune. Le client déduit la clé commune par la formule : K AB = PK @B>B @T>SK A K étant la clé commune, PK la clé publique et SK la clé privée, chaque clé étant sur 128 bits. Le serveur déduit la clé commune à l’aide de la formule : K AB = PK @B>A @T>SK B Le calcul de cette clé commune, dans lequel intervient la clé privée de chacun, ne peut être effectué que par le client et le serveur concernés. Cette clé ayant 128 bits et DES utilisant une clé de 56 bits, le client et le serveur extraient 56 bits de la clé commune pour constituer la clé DES. 13-4 Guide de sécurité Processus d’authentification Lorsqu’un client souhaite ”parler” à un serveur, il génère de façon aléatoire une clé, utilisée pour chiffrer les horodatages. Cette clé est appelée clé de conversation (CK). Le client chiffre cette clé via la clé DES commune (voir “ Règles d’authentification ”, page 13-4) et l’envoie au serveur dans la première transaction RPC. La figure suivante illustre ce processus. Figure 16. Processus d’authentification Cette figure illustre le processus d’authentification, décrit dans le texte. Cette figure montre le client A, qui se connecte au serveur B. Le terme K (dans CK) signifie que CK est chiffré à l’aide de la clé DES commune K. Dans la première demande, l’identification RPC du client contient son nom (A), la clé de conversation (CK) et la variable win (window) chiffrée via CK (dont la valeur par défaut est de 30 minutes). Le vérificateur client dans la première demande contient l’horodatage chiffré et un vérificateur chiffré de la fenêtre spécifiée, win + 1. Ce dernier vérificateur rend encore plus difficile de deviner la bonne identification, la sécurité en est accrue d’autant. Après authentification du client, le serveur enregistre dans une table les éléments suivants : • Le nom du client, A • La clé de conversation, CK • La fenêtre, • l’horodatage. Le serveur n’accepte que les horodatages postérieurs au dernier reçu, aussi les transactions répétées sont–elles rejetées. Le serveur renvoie au client dans le vérificateur un ID index dans la table d’authentification, ainsi que l’horodatage du client moins un, chiffrée avec CK. Le client sait alors que seul le serveur peut avoir envoyé ce vérificateur, car il est le seul à connaître l’horodatage envoyé par le client. La soustraction à l’horodatage qu’il n’est plus valide et ne peut plus être réutilisé comme vérificateur de client. Après la première transaction RPC, le client envoie juste son ID et un horodatage chiffré au serveur, lequel lui renvoie l’horodatage moins 1, chiffré par CK. Network File System (NFS) Security 13-5 Nom des entités réseau pour l’authentification DES L’authentification DES se base sur les noms réseau (net names). Les paragraphes suivants traitent du mode de traitement de l’authentification DES par NIS. Pour des détails sur le traitement par NIS+ de l’authentification DES, consultez le manuel AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. Un net name est une chaîne de caractères imprimables destinés à l’identification. Les clés secrètes et publiques sont stockées par nom net plutôt que par nom d’utilisateur. La mappe netid.byname place le nom net dans un UID local et une liste d’accès de groupe. Les noms d’utilisateur sont uniques dans un domaine. Les noms net sont formés par concaténation des ID système et utilisateur avec les noms de domaine NIS et Internet. Pour nommer les domaines, optez pour la convention qui consiste à ajouter le nom Internet du domaine (com, edu, gov, mil) à son nom local. Les noms net sont attribués aux machines et aux utilisateurs. Le nom net d’une machine est formé à peu près comme celui d’un utilisateur. Par exemple, un machine nommée hal dans le domaine eng.ibm.com possède le nom net [email protected]. Une authentification correcte des machines est essentielle, surtout lorsqu’il s’agit de machines sans disque qui nécessitent un accès total à leur répertoire personnel dans le réseau. Pour authentifier les utilisateurs d’un domaine distant, insérez les entrées correspondantes dans deux bases de données NIS : une entrée pour leurs clés publiques et privées, l’autre pour le mappage UID local et liste d’accès groupe. Les utilisateurs du domaine distant peuvent alors accéder à tous les services du réseau local (NFS, connexion à distance, etc.). Fichier /etc/publickey Le fichier /etc/publickey contient les noms et les clés publiques utilisées par NIS et NIS+ pour créer la mappe publickey. La mappe publickey assure la sécurité du réseau. Chaque entrée du fichier est constituée du nom d’un utilisateur du réseau (référençant un utilisateur ou un hôte), suivi de la clé publique de l’utilisateur (en hexadécimal), d’un signe deux points et de la clé privée chiffrée de l’utilisateur (également en hexadécimal). Par défaut, l’unique utilisateur inscrit dans le fichier /etc/publickey est nobody. N’utilisez pas un éditeur de texte pour modifier le fichier /etc/publickey, car il contient des clés de chiffrement. Si vous devez modifier le fichier /etc/publickey, passez plutôt par la commande chkey ou newkey. Remarques sur l’amorçage des systèmes à clé publique Lorsque vous réamorcez une machine après une coupure de courant, toutes les clés privées stockées sont perdues et aucun processus ne peut accéder aux services sécurisés du réseau (tel le montage d’un NFS). Les processus root peuvent se poursuivre, sous réserve que quelqu’un puisse indiquer le mot de passe qui déchiffre la clé privée de l’utilisateur root. La solution est de stocker la clé privée de l’utilisateur root déchiffrée dans un fichier accessible par le serveur de clés. Tous les appels setuid n’aboutissent pas. Par exemple, si setuid est appelée par le propriétaire A, qui ne s’est pas reconnecté depuis le réamorçage de la machine, elle ne peut accéder aux services réseau sécurisés en tant que A. Toutefois, la plupart des appels setuid sont la propriété de l’utilisateur root dont la clé privée est toujours enregistrée au moment de l’amorçage. 13-6 Guide de sécurité Remarques sur les performances de NFS sécurisé Travailler sous NFS sécurisé n’est pas sans incidence sur les performances du système. • Pour commencer, le client et le serveur doivent tous deux calculer la clé commune. Ce calcul demande environ 1 seconde. Autrement dit, il faut environ 2 secondes pour établir la connexion RPC initiale, le client et le serveur ayant tous deux à effectuer cette opération. Une fois cette connexion établie, le serveur conserve le résultat de l’opération en mémoire cache, ce qui évite de recalculer la clé à chaque fois. • Chaque transaction RPC nécessite les opérations de chiffrement suivantes : 1. Le client chiffre l’horodatage de la demande. 2. Le serveur la déchiffre. 3. Le serveur chiffre l’horodatage de la réponse. 4. Le client la déchiffre. Les performances du système étant diminuées par NFS, évaluez les avantages d’une sécurité accrue ainsi que les besoins de performances. Administration de NFS sécurisé Vérifiez les points suivants pour vous assurer que NFS fonctionne correctement. • Lorsque vous montez un système de fichiers sur un client, en spécifiant –secure, le nom du serveur doit correspondre au nom d’hôte du serveur tel qu’il apparaît dans le fichier /etc/hosts. Si un serveur de noms sert à la résolution des noms d’hôte, vérifiez que les informations hôte renvoyées par ce serveur correspondent à l’entrée du fichier /etc/hosts. Faute de quoi, des erreurs d’authentification risquent de se produire, car les noms net des machines sont basés sur les entrées principales du fichier /etc/hosts, et que c’est le nom net qui sert à l’accès aux clés de la mappe publickey. • Ne panachez pas montages et exportations sécurisés et non sécurisés : l’accès aux fichiers risque d’être mal déterminé. Ainsi, si une machine client monte un système de fichiers sécurisé sans option secure ou un système non sécurisé avec option secure, les utilisateurs y accéderont en tant que nobody, et non en tant qu’eux–mêmes. Cette situation se produit également si un utilisateur inconnu de NIS ou NIS+ tente de créer ou de modifier des fichiers d’un système sécurisé. • NIS doit diffuser une nouvelle mappe à chaque émission des commandes chkey et newkey, aussi ne lancez ces commandes que lorsque le réseau est peu chargé. • Ne supprimez ni le fichier /etc/keystore ni le fichier /etc/.rootkey. Si vous réinstallez, déplacez ou mettez à jour une machine, sauvegardez les fichiers /etc/keystore et /etc/.rootkey. • Dites aux utilisateurs d’employer la commande yppasswd plutôt que la commande passwd pour changer de mot de passe : mots de passe et clés privées resteront synchronisés. • La commande login ne recherchant pas de clés dans la mappe publickey pour le démon keyserv, l’utilisateur doit exécuter la commande keylogin. Vous pouvez placer la commande keylogin dans le fichier profile de chaque utilisateur pour qu’elle soit exécutée automatiquement. Notez que la commande keylogin demande à l’utilisateur de donner son mot de passe une deuxième fois. Network File System (NFS) Security 13-7 • Lorsque vous générez les clés de l’utilisateur root au niveau de chaque hôte, via la commande newkey–h ou chkey, vous devez exécuter la commande keylogin pour transmettre les nouvelles clés au démon keyserv. Les clés sont stockées dans le fichier /etc/.rootkey, lu par le démon keyserv chaque fois qu’il est lancé. • Vérifiez régulièrement que les démons yppasswdd et ypupdated sont actifs sur le serveur maître NIS. Ces démons sont requis pour maintenir la mappe publickey. • Vérifiez régulièrement que le démon keyserv est actif sur toutes machines sous NFS sécurisé. Configuration de NFS sécurisé Pour configurer NFS sécurisé sur les serveurs NIS maître et esclaves, passez par l’application Web-based System Manager ou procédez comme suit. Pour des détails sur l’utilisation de NFS avec NIS+, consultez AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. 1. Sur le serveur NIS maître, créez une entrée pour chaque utilisateur dans le fichier NIS /etc/publickey, par la commande newkey. Cette commande propose deux options. – Pour un utilisateur standard, entrez : smit newkey ou newkey –u nomutilisteur Pour un utilisateur root sur une machine hôte, entrez : newkey –h nomhôte – Les utilisateurs peuvent également définir leurs propres clés publiques via la commande chkey ou newkey. 2. Créez la mappe NIS publickey suivant les instructions du manuel AIX 5L Version 5.2 Network Information Service (NIS and NIS+) Guide. La mappe correspondante publickey.byname ne doit résider que sur les serveurs. 3. Annulez la mise en commentaire des strophes suivantes dans le fichier /etc/rc.nfs: #if [ –x /usr/sbin/keyserv ]; then # startsrc –s keyserv #fi #if [ –x /usr/lib/netsvc/yp/rpc.ypupdated –a –d /etc/yp/‘domainname‘ ]; then # startsrc –s ypupdated #fi #DIR=/etc/passwd #if [ –x /usr/lib/netsvc/yp/rpc.yppasswdd –a –f $DIR/passwd ]; then # startsrc –s yppasswdd #fi 4. Lancez les démons keyserv, ypupdated et yppasswdd à l’aide de la commande startsrc. Pour configurer NFS sécurisé sur des clients NIS, lancez le démon keyserv à l’aide de la commande startsrc. 13-8 Guide de sécurité Exportation d’un système de fichiers via NFS sécurisé Vous pouvez exporter un NFS sécurisé via l’application Web-based System Manager, ou utiliser l’une des procédures suivantes. • Pour exporter un fichier NFS sécurisé via SMIT : 1. Vérifiez que NFS est actif en lançant la commande lssrc –g nfs. La sortie doit indiquer que les démons nfsd et rpc.mountd sont actifs. 2. Vérifiez que la mappe publickey existe et que le démon keyserv est actif. Pour en savoir plus, reportez–vous à Configuration de NFS sécurisé, page 13-8. 3. Lancez le raccourci smit mknfsexp. 4. Renseignez les zones Chemin d’accès du répertoire à exporter, Mode d’accès au répertoire exporté et Exporter répertoire maintenant, initsyst. ou les deux. Spécifiez yes à la rubrique Utilisation de l’option de montage SECURE. 5. Modifiez les autres caractéristiques ou acceptez les valeurs par défaut. 6. Quittez SMIT. Si le fichier /etc/exports n’existe pas, il est créé. 7. Répétez les étapes 3 à 6 pour chaque répertoire à exporter. • Pour exporter un système de fichiers NFS sécurisé à l’aide d’un éditeur de texte : 1. Ouvrez le fichier /etc/exports avec votre éditeur favori. 2. Créez une entrée pour chaque répertoire à exporter, en indiquant son chemin d’accès complet. Répertoriez tous les répertoires à exporter en commençant à la marge gauche. Ne spécifiez pas de répertoire qui en contient un autre déjà exporté. Pour en savoir plus sur la syntaxe des entrées dans le fichier /etc/exports, reportez–vous à la documentation du fichier /etc/exports. 3. Sauvegardez et fermez le fichier /etc/exports. 4. Si NFS est actif, entrez : /usr/sbin/exportfs –a –a indique à la commande exportfs d’envoyer au noyau toutes les informations du fichier /etc/exports. • Pour exporter temporairement un système de fichiers NFS (c’est à dire sans modifier le fichier /etc/exports), entrez : exportfs –i –o secure / dirname dirname étant le nom du système de fichiers à exporter. La commande exportfs –i spécifie de ne pas rechercher le répertoire dans le fichier /etc/exports, et que toutes les options sont directement issues de la ligne de commande. Network File System (NFS) Security 13-9 Montage d’un système de fichiers NFS sécurisé Procédez comme suit pour monter explicitement un répertoire NFS sécurisé : 1. Vérifiez que le serveur NFS a exporté le répertoire à l’aide de la commande : showmount –e ServerName ServerName étant le nom du serveur NFS. Cette commande affiche le nom des répertoires exportés du serveur NFS. Si le répertoire à monter ne s’y trouve pas, exportez–le. 2. Définissez le point de montage local par la commande mkdir. La réussite d’un montage NFS suppose la présence d’un répertoire servant de point de montage. Ce répertoire doit être vide. La création de ce point de montage ne diffère en rien de celle de n’importe quel répertoire, et aucun attribut particulier ne doit être spécifié. 3. Vérifiez que la mappe publickey existe et que le démon keyserv est actif. Pour en savoir plus, reportez–vous à Configuration de NFS sécurisé, page 13-8. 4. Entrez : mount –o secure ServerName : /remote/directory /local/directory ServerName étant le nom du serveur NFS, /remote/directory, le répertoire du serveur NFS que vous souhaitez monter et /local/directory le point de montage sur le client NFS. Remarque : Seul un utilisateur root peut monter un système de fichiers NFS sécurisé. 13-10 Guide de sécurité Chapitre 14. EIM (Enterprise Identity Mapping) Les environnements réseau actuels se composent d’un groupe complexe de systèmes et d’applications. Il est donc nécessaire de gérer plusieurs registres d’utilisateurs. La présence de plusieurs registres d’utilisateurs entraîne rapidement un important problème administratif qui affecte les utilisateurs, les administrateurs et les développeurs. EIM permet aux administrateurs et aux développeurs de traiter ce problème simplement. Ce chapitre décrit les problèmes et les méthodes actuelles, y compris la méthode EIM. Gestion de plusieurs registres d’utilisateurs De nombreux administrateurs gèrent des réseaux qui incluent différents systèmes et serveurs, ayant chacun sa propre méthode de gestion des utilisateurs à l’aide de différents registres. Sur ces réseaux complexes, les administrateurs doivent gérer les identités et les mots de passe de chaque utilisateur sur plusieurs systèmes. Ils doivent souvent également synchroniser ces identités et mots de passe. Les utilisateurs doivent se souvenir de leurs nombreux mots de passe et identités et assurer leur synchronisation. Les administrateurs perdent souvent un temps précieux à résoudre les échecs de connexions et à redéfinir les mots de passe oubliés. Le problème que constitue la gestion de plusieurs registres d’utilisateurs affecte aussi les développeurs d’applications hétérogènes ou en plusieurs couches. D’importantes données d’entreprise sont réparties sur différents types de systèmes, qui ont chacun leurs propres registres d’utilisateurs. Les développeurs doivent donc créer des registres d’utilisateurs propriétaires et associer des codes de sécurité à leurs applications. Ils résolvent ainsi leur problème, mais augmentent la charge de travail des utilisateurs et administrateurs. Méthodes actuelles Il existe plusieurs méthodes pour résoudre les problèmes inhérents à la gestion de plusieurs registres d’utilisateurs, mais aucune ne fournit une solution complète. Par exemple, le protocole LDAP fournit une solution de registres d’utilisateurs répartis. Cependant, pour utiliser de telles solutions, les administrateurs doivent gérer un registre d’utilisateurs et un code de sécurité supplémentaires, ou remplacer des applications conçues pour les autres registres. Ils doivent alors gérer plusieurs systèmes de sécurité pour des ressources individuelles, augmentant ainsi leur charge de travail, ainsi que les failles potentielles au niveau de la sécurité. Lorsque plusieurs systèmes supportent une même ressource, il est fréquent de modifier une autorité pour un système et d’oublier de la modifier pour les autres systèmes. Par exemple, la sécurité peut être contournée lorsqu’un utilisateur se voit refuser l’accès de manière appropriée par une interface, mais qu’il bénéficie de l’accès via d’autres interfaces. Une fois leur travail terminé, les administrateurs comprennent qu’ils n’ont pas complètement réglé le problème. Généralement, les entreprises ont trop investi dans leurs registres d’utilisateurs actuels et dans les codes de sécurité associés pour que l’utilisation de ce type de solution soit pratique. La création d’un autre registre d’utilisateurs et du code de sécurité associé règle le problème du développeur, mais pas celui des utilisateurs ni des administrateurs. Une autre solution consiste à utiliser une méthode unique de connexion. Plusieurs produits permettent aux administrateurs de gérer des fichiers contenant tous les mots de passe et identités des utilisateurs. Cependant, cette méthode comporte plusieurs inconvénients : EIM (Enterprise Identity Mapping) 14-1 • Elle ne règle que l’un des problèmes des utilisateurs. Elle leur permet de se connecter à plusieurs systèmes en fournissant une identité et un mot de passe, mais ils doivent toujours gérer leurs mots de passe et les utiliser sur d’autres systèmes. • Elle créé un nouveau problème car des mots de passe déchiffrables ou non chiffrés sont stockés dans ces fichiers. Les mots de passe ne doivent jamais être stockés dans des fichiers non chiffrés ou accessibles facilement par d’autres personnes, y compris les administrateurs. • Elle ne résout pas les problèmes des développeurs d’applications tierces hétérogènes ou à plusieurs couches. Les développeurs doivent toujours donc créer des registres d’utilisateurs propriétaires pour leurs applications. Malgré ces inconvénients, des entreprises utilisent ces méthodes car elle simplifient en partie la gestion de plusieurs registres d’utilisateurs. Utilisation de l’EIM L’architecture EIM décrit les relations entre individus ou entités (tels que des serveurs de fichiers et d’impressions) d’une entreprise, et leurs nombreuses identités au sein de l’entreprise. EIM fournit un ensemble d’API permettant aux applications de poser des questions sur ces relations. Par exemple, connaissant l’identité utilisateur d’une personne dans un registre d’utilisateurs, vous pouvez connaître son identité dans un autre registre. Si l’utilisateur s’est authentifié avec une identité et que vous pouvez mapper cette identité avec l’identité correspondante d’un autre registre, l’utilisateur n’a pas besoin de fournir à nouveau de données d’identification. Il suffit de connaître l’identité correspondant à cet utilisateur dans un autre registre. EIM fournit un fonction généralisée de mappage d’identité dans l’entreprise. La possibilité de trouver la correspondance entre les identités d’un utilisateur dans différents registres comporte plusieurs avantages. Les applications peuvent utiliser un registre pour l’authentification et un autre registre pour les autorisations. Par exemple, un administrateur peut mapper une identité SAP (ou SAP pourrait faire le mappage lui–même) pour accéder aux ressources SAP. Le mappage d’identités nécessite que les administrateurs exécutent la procédure suivante : 1. Création d’identifiants EIM représentant les personnes ou entités dans l’entreprise. 2. Création de définitions de registres EIM décrivant les registres d’utilisateurs de l’entreprise. 3. Définition des relations entre les identités des utilisateurs dans ces registres et les identifiants EIM créés. Il est inutile de modifier les codes des registres existants. Il n’est pas nécessaire de procéder au mappage de toutes les identités d’un registre d’utilisateurs. EIM permet des mappages one–to–many (c’est à dire un utilisateur qui a plusieurs identités dans un même registre). EIM permet aussi des mappages many–to–one (c’est à dire plusieurs utilisateurs partageant la même identité dans un même registre), bien qu’ils ne soient pas recommandés pour des raisons de sécurité. Un administrateur peut représenter tout type de registre d’utilisateurs dans EIM. EIM ne nécessite pas de copier des données dans un nouveau répertoire et d’essayer d’assurer la synchronisation des deux exemplaires. Les seules nouvelles données inhérentes à EIM sont les informations sur les relations. Les administrateurs les placent dans un répertoire LDAP, pouvant ainsi les gérer à un emplacement et disposer de copies là où ces informations sont utiles. Pour en savoir plus sur l’EIM, reportez–vous au site suivant : http://publib.boulder.ibm.com/eserver/ 14-2 Guide de sécurité Troisième partie. Annexes Annexes PART 3 - 1 PART 3 - 2 Guide de sécurité Annexe A. Vérification de la sécurité Cette annexe indique les vérifications de sécurité à effectuer sur un système nouveau ou existant. Bien que cette liste ne soit pas exhaustive, elle peut servir de base à la création d’une liste complète pour votre environnement. 1. Lors de l’installation d’un nouveau système, installez AIX depuis un support de base sécurisé. Exécutez les procédures suivantes au moment de l’installation : – N’installez pas d’interfaces graphiques tels que CDE, GNOME ou KDE sur des serveurs. – Installez les correctifs de sécurité requis et les correctifs de niveau de maintenance recommandés. Reportez–vous au site des correctifs ESCALA (http://techsupport.services.ibm.com/server/fixes?view=pSeries) pour obtenir les nouvelles notes de service et informations sur les correctifs. – Sauvegardez le système au terme de l’installation initiale et stockez la sauvegarde en lieu sûr. 2. Dressez des listes de contrôle des accès pour les fichiers et répertoires réservés. 3. Désactivez les comptes utilisateur et système qui ne sont pas nécessaires, tels que démon, bin, sys, adm, lp ou uucp. Il est déconseillé de supprimer des comptes car vous perdriez des informations sur eux, telles que les ID utilisateur et noms d’utilisateurs, qui peuvent toujours être associés à des données dans les sauvegardes système. Si un utilisateur est créé avec un ID utilisateur qui a été supprimé et si la sauvegarde système est restaurée sur le système, le nouvel utilisateur risque d’avoir un accès non souhaité au système restauré. 4. Consultez régulièrement les fichiers /etc/inetd.conf, /etc/inittab, /etc/rc.nfs et /etc/rc.tcpip et retirez tous les démons et services qui ne sont pas nécessaires. 5. Vérifiez que les droits d’accès aux fichiers suivants sont définis correctement : –rw–rw–r–– root –rw–rw–r–– root –rw––––––– root –rw–r––r–– root –rw–r––r–– root –rw–rw–––– root system /etc/filesystems system /etc/hosts system /etc/inittab system /etc/vfs system /etc/security/failedlogin audit /etc/security/audit/hosts 6. Désactivez la fonction de connexion à distance du compte root. Ce compte ne doit pouvoir se connecter que depuis la console système. 7. Activez l’audit du système. Pour en savoir plus, reportez–vous à Audit, page 3-1. 8. Activez une politique de contrôle des connexions. Pour en savoir plus, reportez–vous à la section Fenêtre de connexion, page 1-17. 9. Désactivez les droits des utilisateurs pour lancer la commande xhost. Pour de plus amples informations, reportez–vous à la section Gestion des problèmes sous X11 et CDE, page 1-21. 10.Empêchez les modifications non autorisées de la variable d’environnement PATH. Pour en savoir plus, reportez–vous à la section Variable d’environnement PATH, page 2-10. 11. Désactivez telnet, rlogin, et rsh. Pour en savoir plus, reportez–vous à Sécurité TCP/IP, page 9-1. 12.Créez des contrôles de comptes utilisateur. Pour en savoir plus, reportez–vous à la section Contrôle des comptes utilisateur, page 2-9. Vérification de la sécurité A-1 13.Mettez en place une politique stricte de mots de passe. Pour en savoir plus, reportez–vous à la section Mots de passe, page 2-23. 14.Etablissez des quotas de disque pour les comptes utilisateur. Pour en savoir plus, reportez–vous à la section Reprise après un dépassement de quota, page 2-31. 15.N’autorisez que les comptes d’administration à utiliser la commande su. Contrôlez les journaux de la commande su dans le fichier /var/adm/sulog. 16.Activez le verrouillage d’écran sous X–Windows. 17.Limitez l’accès aux commandes cron et at aux seuls comptes ayant besoin d’y accéder. 18.Créez un alias de la commande ls pour afficher les fichiers et les caractères cachés dans un nom de fichier. 19.Créez un alias de la commande rm pour éviter toute suppression involontaire de fichiers du système. 20.Désactivez les services réseau qui ne sont pas nécessaires. Pour en savoir plus, reportez–vous à la section Services réseau, page 10-1. 21.Effectuez des sauvegardes système régulières et vérifiez leur intégrité. 22.Inscrivez–vous aux listes de distribution des e–mails ayant trait à la sécurité. A-2 Guide de sécurité Annexe B. Sources d’informations sur la sécurité Cette annexe fournit des informations sur les ressources concernant la sécurité. Attention, les adresses de sites Web peuvent être modifiées ou devenir obsolètes sans préavis. Sites Web concernant la sécurité Virtual Private Networks (VPN) AIX : http://www–1.ibm.com/servers/aix/products/ibmsw/security/vpn/index.html CERIAS (Center for Education and Research in Information Assurance and Security) : http://www.cerias.purdue.edu/ CERT (Computer Emergency Response Team, Carnegie Mellon University) : http://www.cert.org CIAC (Computer Incident Advisory Capability) : http://ciac.llnl.gov Computer Security Resource Clearinghouse : http://csrc.ncsl.nist.gov/ FIRST (Forum of Incident Response and Security Teams) : http://www.first.org/ eServer Security Planner : http://www–1.ibm.com/servers/security/planner/ Solutions de sécurité : http://www–3.ibm.com/security/index.shtml OpenSSH : http://www.openssh.org/ Listes de diffusion de sécurité CERT : http://www.cert.org/contact_cert/certmaillist.html Messages techniques concernant les logiciels : http://techsupport.services.ibm.com/server/listserv comp.security.unix : news:comp.security.unix Références de sécurité en ligne FAQ sur les concepts de critères communs : http://www.radium.ncsc.mil/tpep/process/faq–sect3.html Bibliothèque Rainbow : http://www.radium.ncsc.mil/tpep/library/rainbow/ FAQ : org: http://www.faqs.org/faqs/computer–security/ Centre d’informations ESCALA : http://www.bull.com/servers/open/ Sources d’informations sur la sécurité B-1 B-2 Guide de sécurité Annexe C. Résumé des principaux services système AIX Le tableau suivant répertorie les services système les plus courants sous AIX. Ce tableau servira de point de départ pour la sécurisation de votre système. Avant de commencer la sécurisation de votre système, sauvegardez tous vos fichiers de configuration, notamment : • /etc/inetd.conf • /etc/inittab • /etc/rc.nfs • /etc/rc.tcpip Service Démon Lancé par Fonction inetd/bootps inetd /etc/inetd.conf services bootp pour clients sans disque Commentaires • Nécessaire pour l’environnement NIM (Network Installation Management) et le démarrage à distance des systèmes • Fonctionne avec tftp • Désactivez dans la plupart des cas inetd/chargen inetd /etc/inetd.conf générateur de caractères (tests seulement) • Disponible en tant que service TCP et UDP • Attaques possibles par refus de service • Désactivez à moins que vous ne testiez votre réseau inetd/cmsd inetd /etc/inetd.conf service de calendrier (comme • Exécuté en tant que root, utilisé par CDE) donc problèmes de sécurité • Désactivez à moins que vous n’ayez besoin de ce service avec CDE • Désactivez sur les serveurs de bases de données back–office Résumé des principaux services système AIX C-1 inetd/comsat inetd /etc/inetd.conf Signale les messages électroniques entrants • Exécuté en tant que root, donc problèmes de sécurité • Rarement nécessaire • Désactivez inetd/daytime inetd /etc/inetd.conf service de date obsolète (tests seulement) • Exécuté en tant que root • Disponible en tant que service TCP et UDP • Possibilités d’attaques PING par refus de service • Service obsolète utilisé seulement pour les tests • Désactivez inetd/discard inetd /etc/inetd.conf service /dev/null (tests seulement) • Disponible en tant que service TCP et UDP • Utilisé lors d’attaques par refus de service • Service obsolète utilisé seulement pour les tests • Désactivez inetd/dtspc inetd /etc/inetd.conf Commande de sous–processus CDE • Ce service est lancé automatiquement par le démon inetd en réponse à une demande d’un client CDE de lancer un processus sur l’hôte du démon. Vulnérable aux attaques • Désactivez sur les serveurs de back–office sans CDE • CDE doit pouvoir fonctionner sans ce service • Désactivez à moins que vous n’en ayez absolument besoin C-2 Guide de sécurité inetd/echo inetd /etc/inetd.conf service echo (tests seulement) • Disponible en tant que service UDP et TCP • Utilisé lors d’attaques Smurf ou par refus de service • Utilisé comme echo sur un autre utilisateur pour passer un pare–feu ou lancer une attaque de données • Désactivez inetd/exec inetd /etc/inetd.conf service d’exécution à distance • Exécuté en tant que root, donc dangereux • Nécessite un ID utilisateur et un mot de passe, qui sont transmis sans protection • Un service à haut risque d’espionnage • Désactivez inetd/finger inetd /etc/inetd.conf informations sur les utilisateurs • Exécuté en tant que root, donc dangereux • Révèle des informations sur vos systèmes et utilisateurs • désactivez inetd/ftp inetd /etc/inetd.conf protocole de transfert de fichiers • Exécuté en tant qu’utilisateur root • ID utilisateur et mot de passe transmis sans protection. Risque d’espionnage • Désactivez ce service et utilisez un shell sécurisé du domaine public inetd/imap2 inetd /etc/inetd.conf Protocole d’accès au courrier électronique • Vérifiez que vous utilisez la dernière version de ce serveur • Nécessaire uniquement sur un serveur de messagerie. Sinon, désactivez • ID utilisateur et mot de passe transmis sans protection Résumé des principaux services système AIX C-3 inetd/klogin inetd/kshell inetd inetd /etc/inetd.conf /etc/inetd.conf Connexion Kerberos • Activé si votre site utilise l’authentification Kerberos Shell Kerberos • Activé si votre site utilise l’authentification Kerberos inetd/login inetd /etc/inetd.conf service rlogin • Susceptible d’être victime d’intrusion IP ou DNS • Les données, y compris les ID utilisateur et mots de passe, sont transmises sans protection. • Exécuté en tant que root, donc dangereux • Utilisez un shell sécurisé plutôt que ce service inetd/netstat inetd /etc/inetd.conf reporting de l’état du réseau • Susceptible de révéler des informations réseau aux hackers en cas d’exécution sur votre système • Désactivez inetd/ntalk inetd /etc/inetd.conf Permet aux utilisateurs de dialoguer entre eux • Exécuté en tant que root, donc dangereux • Pas nécessaire sur les serveurs de production ou de back–office • Désactivez à moins que vous en ayez absolument besoin inetd/pcnfsd inetd /etc/inetd.conf services de fichiers NFS PC • Désactivez ce service s’il n’est pas en cours d’utilisation • Si vous avez besoin d’un service similaire, envisagez Samba, car le démon pcnfsd englobe les définitions SMB de Microsoft C-4 Guide de sécurité inetd/pop3 inetd /etc/linetd.conf Protocole POP (Post Office Protocol) • Les ID utilisateur et les mots de passe sont transmis sans protection • Nécessaire si votre système est un serveur de messagerie et si certains de vos clients utilisent des applications uniquement compatibles POP3 • Préférez IMAP si vos clients l’utilisent, ou bien POP3s. Ce service dispose d’un tunnel SSL (Secure Socket Layer) • Désactivez si vous n’être pas un serveur de messagerie ou n’avez pas de client nécessitant des services POP inetd/rexd inetd /etc/inetd.conf exécution à distance • Exécuté en tant que root, donc dangereux • Associé à la commande on • Désactivez ce service • Utilisez plutôt rsh et rshd inetd/quotad inetd /etc/inetd.conf rapports sur les quotas de fichiers • Nécessaire uniquement (pour clients NFS) en cas d’exécution de services de fichiers NFS. • Désactivez ce service à moins que vous ne deviez répondre à la commande quota • Si vous devez utiliser ce service, effectuez les mises à jour et correctifs inetd/rstatd inetd /etc/inetd.conf Serveur Kernel Statistics • Si vous devez contrôler des systèmes, utilisez SNMP et désactivez ce service • Nécessaire si vous devez utiliser la commande rup Résumé des principaux services système AIX C-5 inetd/rusersd inetd /etc/inetd.conf informations sur l’utilisateur connecté • Un service non indispensable. Désactivez • Exécuté en tant que root, donc dangereux • Révèle la liste des utilisateurs en cours sur votre système ; associé à rusers inetd/rwalld inetd /etc/inetd.conf écriture à tous les utilisateurs • Exécuté en tant que root, donc dangereux • Vous devrez peut–être conserver ce service si vos systèmes comptent des utilisateurs interactifs • Ce n’est pas le cas si vos systèmes sont des serveurs de production ou de bases de données • Désactivez inetd/shell inetd /etc/inetd.conf service rsh • Désactivez si possible. Remplacez par un shell sécurisé • Si vous devez utiliser ce service, utilisez TCP Wrapper pour empêcher l’espionnage et limiter les risques • Nécessaire pour xhier inetd/sprayd inetd /etc/inetd.conf tests spray RPC • Exécuté en tant que root, donc dangereux • Peut être nécessaire pour diagnostiquer les problèmes de réseau NFS • Désactivez si vous n’utilisez pas NFS inetd/systat inetd /etc/inted.conf rapport d’état ”ps –ef” • Permet à des sites distants d’afficher l’état des processus sur votre système • Service désactivé par défaut. Vérifiez régulièrement qu’il n’a pas été activé. C-6 Guide de sécurité inetd/talk inetd /etc/inetd.conf établissement d’un partage d’écran • Service non nécessaire entre 2 utilisateurs • Utilisé avec la commande du réseau talk • Fournit le service UDP sur le port 517 • Désactivez à moins que vous ayez besoin de plusieurs sessions de chat interactives pour utilisateur UNIX inetd/ntalk inetd /etc/inetd.conf partage d’écran ”new talk” entre 2 utilisateurs du réseau • Service non nécessaire • Utilisé avec la commande talk • Fournit un service UDP sur le port 517 • Désactivez à moins que vous ayez besoin de plusieurs sessions de chat interactives pour utilisateur UNIX inetd/telnet inetd /etc/inetd.conf service telnet • Sessions de connexion à distance, ID utilisateur et mots de passe transmis sans protection • Si possible, désactivez ce service et utilisez un shell sécurisé pour l’accès à distance inetd/tftp inetd /etc/inetd.conf transfert de fichiers • Fournit un service UDP sur le port 69 • Exécuté en tant que root, risque d’intrusion • Utilisé par NIM • Désactivez à moins que vous utilisiez NIM ou que vous deviez démarrer un poste sans disque Résumé des principaux services système AIX C-7 inetd/time inetd /etc/inetd.conf service de date obsolète (tests seulement) • Fonction interne à inetd, utilisée par la commande rdate. • Disponible en tant que service TCP et UDP • Parfois utilisée pour synchroniser les horloges lors de l’amorçage • Service obsolète. Remplacez par ntpdate • Désactivez après avoir testé vos systèmes (amorçage/redémarrage) sans ce service et constaté leur bon fonctionnement inetd/ttdbserver inetd /etc/inetd.conf serveur de bases de données tool–talk (pour CDE) • rpc.ttdbserverd est exécuté en tant que root, donc problème de sécurité • Décrit comme requis pour CDE, mais CDE peut fonctionner sans • A ne pas utiliser sur des serveurs back–office ou sur des systèmes dont il faut assurer la sécurité inetd/uucp inetd /etc/inetd.conf réseau UUCP • Désactivez à moins que vous ayez une application NIM qui utilise UUCP inittab/dt init script /etc/rc.dt dans /etc/inittab connexion d’un poste de bureau à • Lance le serveur X11 sur l’environnement la console CDE • Prend en charge le protocole xdcmp (X11 Display Manager Control Protocol) pour que les autres postes X11 puissent se connecter à la même machine • Service à n’utiliser que sur les stations de travail personnelles. A ne pas utiliser pour des systèmes de back–office C-8 Guide de sécurité inittab/dt_nogb inittab/httpdlite init init /etc/inittab /etc/inittab connexion bureau à l’environnement CDE (pas d’amorçage graphique) serveur Web pour la commande docsearch • Pas d’affichage graphique avant que le système ne soit entièrement démarré • Mêmes problèmes qu’avec inittab/dt • Serveur Web par défaut pour le moteur docsearch • Désactivez à moins que votre machine soit un serveur de documentation inittab/i4ls init /etc/inittab serveurs de gestion des licences • Activez pour les serveurs de développement • Désactivez pour les serveurs de production • Activez pour les serveurs de bases de données back–office avec des conditions de licence • Gère les compilateurs, logiciels de bases de données, ou autres produits sous licence inittab/imnss init /etc/inittab moteur de recherche pour ”docsearch” • Elément du serveur Web par défaut pour le moteur docsearch • Désactivez à moins que votre machine soit un serveur de documentation inittab/imqss init /etc/inittab moteur de recherche pour ”docsearch” • Elément du serveur Web par défaut pour le moteur docsearch • Désactivez à moins que votre machine soit un serveur de documentation inittab/lpd init /etc/inittab interface d’imprimante parallèle BSD • Accepte les travaux d’impression d’autres systèmes • Vous pouvez désactiver ce service et continuer à envoyer des travaux au serveur d’impression • Désactivez une fois que vous êtes sûr que les impressions ne sont pas affectées Résumé des principaux services système AIX C-9 inittab/nfs init /etc/inittab Système de fichiers NFS/Services d’informations réseau • services NFS et NIS basés sur UDP/RPC • Authentification minimale • Devraient être inutiles sur les serveurs de bases de données back–office • Désactivez pour les serveurs de back–office inittab/piobe init /etc/inittab traitement E/S impressions • Gère la planification, la mise en cache sur disque et l’impression des travaux soumis par qdaemon • Désactivez si vous n’imprimez pas depuis votre système (car vous envoyez des travaux à un serveur) inittab/qdaemon init /etc/inittab démon de file d’attente (pour l’impression) • Soumet des travaux au démon piobe • Désactivez si vous n’imprimez pas depuis votre système inittab/uprintfd init /etc/inittab messages du noyau • Généralement pas nécessaire • Désactivez inittab/writesrv init /etc/inittab écriture de notes vers ttys • Uniquement pour les utilisateurs interactifs de stations de travail UNIX • Service à désactiver pour les serveurs, bases de données back–office et serveurs de développement • Activez pour les stations de travail C-10 Guide de sécurité inittab/xdm init /etc/inittab gestion d’affichage X11 traditionnelle • Ne pas utiliser sur des serveurs de bases de données ou de production back–office • Ne pas utiliser sur des systèmes de développement, à moins que la gestion d’affichage X11 soit requise • Acceptable sur les stations de travail si l’affichage graphique est nécessaire rc.nfs/automountd /etc/rc.nfs systèmes de fichiers à montage • Activez pour les stations automatique de travail si vous utilisez NFS • A ne pas utiliser pour le développement ou des serveurs de back–office rc.nfs/biod rc.nfs/keyserv /etc/rc.nfs /etc/rc.nfs Démon d’E/S par blocs (nécessaire pour les serveurs NFS) serveur de clés RPC sécurisé • N’activez que pour les serveurs NFS • Sinon, désactivez–le, ainsi que nfsd et rpc.mountd • Gère les clés requises pour RPC sécurisé • Important pour NIS+ • Désactivez si vous n’utilisez pas NFS et NIS et NIS+ rc.nfs/nfsd /etc/rc.nfs services NFS (nécessaire pour les serveurs NFS) • Authentification faible • Peut conduire à détruire le contexte de pile • Activez pour les serveurs de fichiers NFS • Sinon, désactivez aussi biod, nfsd et rpc.mountd Résumé des principaux services système AIX C-11 rc.nfs/rpc.lockd /etc/rc.nfs verrouillages de fichiers NFS • Désactivez si vous n’utilisez pas NFS • Désactivez si vous n’utilisez pas de verrouillages de fichiers sur le réseau • Le démon lockd est parmi les 10 principales menaces au classement SANS rc.nfs/rpc.mountd /etc/rc.nfs montages de fichiers NFS (requis pour les serveurs NFS) • Authentification faible • Peut conduire à détruire le contexte de pile • N’activez que pour les serveurs de fichiers NFS • Sinon, désactivez aussi biod, et nfsd rc.nfs/rpc.statd /etc/rc.nfs verrouillages de fichiers NFS (pour • Met en œuvre les les récupérer) verrouillages de fichiers sur NFS • Désactivez si vous n’utilisez pas NFS rc.nfs/rpc.yppassw dd /etc/rc.nfs démon de mots de passe NIS (pour le • Utilisé pour manipuler le maître NIS) fichier local des mots de passe • N’activez que sur le maître NIS rc.nfs/ypupdated /etc/rc.nfs démon de mise à jour NIS (pour esclave NIS) • Reçoit du maître NIS des mappages de bases de données NIS • Nécessaire uniquement sur les esclaves NIS rc.tcpip/autoconf6 /etc/rc.tcpip interfaces IPv6 • Désactivez si vous n’utilisez pas IPV6 rc.tcpip/dhcpcd /etc/rc.tcpip protocole DHCP (client) • Les serveurs back–office ne devraient pas utiliser DHCP. Désactivez ce service • Désactivez si votre hôte n’utilise pas DHCP C-12 Guide de sécurité rc.tcpip/dhcprd /etc/rc.tcpip protocole DHCP (relais) • Recueille des diffusions DHCP et les envoie à un serveur sur un autre réseau • Réplique d’un service trouvé sur les routeurs • Désactivez si vous n’utilisez pas DHCP ou si vous vous chargez de transmettre les informations entre réseaux rc.tcpip/dhcpsd /etc/rc.tcpip protocole DHCP (serveur) • Répond aux requêtes DHCP des clients au moment de l’amorçage. Donne des informations, telles que l’adresse de diffusion, le routeur, le masque réseau, le numéro et le nom IP • Désactivez si vous n’utilisez pas DHCP • Désactivé sur les serveurs de production et de back–office avec les hôtes qui n’utilisent pas DHCP rc.tcpip/dpid2 rc.tcpip/gated /etc/rc.tcpip /etc/rc.tcpip service SNMP obsolète routage par porte entre interfaces • A désactiver si vous n’utilisez pas SNMP • Emule les fonctions d’un router • Désactiver ce service et le remplacer par RIP ou par un routeur rc.tcpip/inetd /etc/rc.tcpip services inetd • Désactivez pour obtenir une meilleure sécurité, mais pas toujours pratique • Sa désactivation entraîne celle des services de shell distants, nécessaires pour certains serveurs Web et de messagerie Résumé des principaux services système AIX C-13 rc.tcpip/mrouted /etc/rc.tcpip routage vers plusieurs destinataires • Emule les fonctions d’un routeur pour l’envoi de paquets à plusieurs destinataires entre segments de réseau • Désactivez ce service. Remplacez par un routeur rc.tcpip/names /etc/rc.tcpip serveur de noms DNS • N’utilisez que si votre machine est un serveur de noms DNS • Désactivez pour les stations de travail, les serveurs de développement et de production rc.tcpip/ndp–host /etc/rc.tcpip hôte IPv6 • Désactivez si vous n’utilisez pas IPV6 rc.tcpip/ndp–router /etc/rc.tcpip routage IPv6 • Désactivez si vous n’utilisez pas IPV6. Envisagez de remplacer IPV6 par un routeur rc.tcpip/portmap /etc/rc.tcpip services RPC • Service requis • Les serveurs RPC s’enregistrent à l’aide du démon portmap. Les clients à la recherche d’un service RPC envoient une requête au démon portmap • Ne désactivez que si vous êtes parvenu à supprimer des services RPC de sorte que le seul restant soit portmap rc.tcpip/routed /etc/rc.tcpip routage RIP entre interfaces • Emule les fonctions d’un router • Désactivez si vous avez un routeur de paquets entre réseaux rc.tcpip/rwhod /etc/rc.tcpip Démon ”who” distant • Recueille et diffuse des données aux autres serveurs du même réseau • Désactivez ce service C-14 Guide de sécurité rc.tcpip/sendmail /etc/rc.tcpip services de messagerie • Exécuté en tant que root, donc dangereux • A l’origine de nombreux problèmes de sécurité • Désactivez si la machine n’est pas utilisée comme serveur de messagerie • Si vous le désactivez, effectuez l’une des actions suivantes : – Placez une entrée dans crontab pour vider la file d’attente. Utilisez la commande /usr/lib/sendmail –q – Configurez les services DNS afin que les messages pour votre serveur arrivent sur un autre système rc.tcpip/snmpd /etc/rc.tcpip SNMP (Simple Network Management Protocol) • Désactivez si vous ne contrôlez pas le système à l’aide d’outils SNMP • SNMP peut être requis sur des serveurs importants, mais rarement sur des stations de travail rc.tcpip/syslogd /etc/rc.tcpip journal système des événements • Ne désactivez jamais ce service • Sujet aux attaques par refus de service • Requis dans tout système rc.tcpip/timed /etc/rc.tcpip démon Old Time • Désactivez ce service et remplacez–le par xntp rc.tcpip/xntpd /etc/rc.tcpip démon New Time • Assure la synchronisation des horloges des systèmes • Désactivez ce service. • Configurez d’autres systèmes comme serveurs de temps et laissez les autres systèmes se synchroniser à eux à l’aide d’une tâche cron qui appelle ntpdate Résumé des principaux services système AIX C-15 dt login service FTP anonyme /usr/dt/config/Xacc ess CDE sans restriction user rmuser –p <nomutilisateur> ftp anonyme • Si vous ne fournissez pas la connexion CDE à un groupe de stations X11, vous pouvez limiter dtlogin à la console. • Le FTP anonyme vous empêche savoir qui utilise le FTP • Retirez l’utilisateur si ce compte existe : rmuser –p ftp • Vous pouvez augmenter la sécurité en plaçant dans le fichier /etc/ftpusers une liste des utilisateurs qui ne doivent pas accéder par ftp à votre système écritures par FTP anonyme envois par FTP anonyme • Aucun fichier ne doit appartenir à ftp. • Les envois par FTP anonyme permettent d’envoyer un code dangereux à votre système. • Placez les noms des utilisateurs à interdire dans le fichier /etc/ftpusers • Voici quelques utilisateurs créés par le système et que vous pouvez empêcher d’envoyer des données via FTP anonyme : root, daemon, bin.sys, admin.uucp, guest, nobody, lpd, nuucp, ladp, imnadm • Modifiez les droits de groupes et de propriétaires aux fichiers ftpusers : chown root:system /etc/ftpusers • Limitez les droits d’accès aux fichiers ftpusers : chmod 644 /etc/ftpusers C-16 Guide de sécurité ftp.restrict root.access ftp vers comptes système /etc/security/user rlogin/telnet vers compte root • Le fichier ftpusers ne doit autoriser aucun utilisateur extérieur à remplacer des fichiers root • Attribuez la valeur false à l’option rlogin dans le etc/security/user • Tout utilisateur se connectant comme root doit d’abord se connecter sous son propre nom puis lancer la commande su vers root. Vous obtenez ainsi un suivi d’audit snmpd.readWrite /etc/snmpd.conf communautés SNMP readWrite • Désactiver le démon SNMP si vous n’utilisez pas SNMP. • Désactivez community private et community system dans le fichier /etc/snmpd.conf • Limitez communauté ’public’ aux adresses IP qui contrôlent votre système syslog.conf configure syslogd • Désactivez ce démon si vous n’avez pas configuré /etc/syslog.conf • Ne le désactivez pas si vous utilisez syslog.conf pour consigner des messages système Résumé des principaux services système AIX C-17 C-18 Guide de sécurité Annexe D. Résumé des options de service réseau Pour obtenir une meilleure sécurité système, il existe plusieurs options de réseau que vous pouvez désactiver avec 0 ou activer avec 1. La liste suivante indique les paramètres que vous pouvez utiliser avec la commande no. Paramètre Commande Fonction bcastping /usr/sbin/no –o bcastping=0 Autorise la réponse aux paquets d’écho ICMP à l’adresse de diffusion. Désactiver cette option évite les attaques Smurf. clean_partial_conns /usr/sbin/no –o clean_partial_conns=1 Indique si oui ou non les attaques SYN (synchronisation du numéro de séquence) sont évitées. directed_broadcast /usr/sbin/no –o directed_broadcast=0 Indique si la diffusion dirigée vers une passerelle est autorisée ou non. La valeur 0 évite aux paquets dirigés d’atteindre un réseau distant. icmpaddressmask /usr/sbin/no –o icmpaddressmask=0 Indique si le système répond à une demande de masque d’adresse ICMP. Désactiver cette option empêche l’accès via des attaques par routage source. ipforwarding /usr/sbin/no –o ipforwarding=0 Indique si le noyau doit réexpédier des paquets. Désactiver cette option évite que des paquets redirigés n’atteignent un réseau distant. ipignoreredirects /usr/sbin/no –o ipignoreredirects=1 Indique s’il faut traiter ou non les redirections reçues. ipsendredirects /usr/sbin/no –o ipsendredirects=0 Indique si le noyau doit envoyer des signaux de redirection. Désactiver cette option évite que des paquets redirigés n’atteignent un réseau distant. ip6srcrouteforward /usr/sbin/no –o ip6srcrouteforward=0 Indique si le système retransmet des paquets IPv6 routés par la source. Désactiver cette option empêche l’accès via des attaques par routage source. ipsrcrouteforward /usr/sbin/no –o ipsrcrouteforward=0 Indique si le système retransmet des paquets routés par la source. Désactiver cette option empêche l’accès via des attaques par routage source. ipsrcrouterecv /usr/sbin/no –o ipsrcrouterecv=0 Indique si le système accepte des paquets routés par la source. Désactiver cette option empêche l’accès via des attaques par routage source Résumé des options de service réseau D-1 ipsrcroutesend /usr/sbin/no –o ipsrcroutesend=0 Indique si les applications peuvent envoyer des paquets routés par la source. Désactiver cette option empêche l’accès via des attaques par routage source. nonlocsroute /usr/sbin/no –o nonlocsrcroute=0 Informe le protocole Internet que seuls des paquets routés par la source peuvent être adressés aux hôtes extérieurs au réseau local. Désactiver cette option empêche l’accès via des attaques par routage source. tcp_pmtu_discover /usr/sbin/no –o tcp_pmtu_discover=0 Désactiver cette option empêche l’accès via des attaques par routage source. udp_pmtu_discover /usr/sbin/no –o udp_pmtu_discover=0 Active ou désactive la recherche de chemin MTU pour les applications TCP. Désactiver cette option empêche l’accès via des attaques par routage source. Pour de plus amples informations sur les options réseau, consultez le manuel AIX 5L Version 5.2 Performance Management Guide. D-2 Guide de sécurité Index Symboles .netrc, 9-3 /usr/lib/security/audit/config, 9-3 A ajout de certificat numérique root d’une autorité d’accréditation, 11-30 arrêt, autorisation, 2-2 audit collecte d’informations sur les événements, 3-2 commande watch, 3-8 configuration, 3-4, 3-9 détection des événements, 3-1 exemple, contrôle en temps réel des fichiers, 3-12 exemple, scénario de journal d’audit générique, 3-13 format des enregistrements, 3-5 généralités, 3-1 journalisation, sélection des événements, 3-5 journalisation des événements, description, 3-4 mode de suivi d’audit du noyau, 3-5 sélection des événements, 3-3 suivi d’audit du noyau, 3-2 traitement des enregistrements, 3-8 authentification, 12-5 Base informatique sécurisée audit, 3-4 audit de l’état de sécurité, 1-2 fichiers sécurisés, vérification, 1-4 généralités, 1-1 programme sécurisé, 1-4 système de fichiers, vérification, 1-4 vérification à l’aide de la commande tcbck, 1-3 base NTCB, 9-8 C CAPP (Controlled Access Protection Profile) et EAL4+ (Evaluation Assurance Level 4+), 1-7 certificats numériques ajout root, 11-30 création de base de données de clefs, 11-29 création de tunnels IKE avec, 11-34 demande, 11-32 gestion, 11-28 paramètres sécurisés, 11-31 réception, 11-32 suppression, 11-33 suppression de root, 11-31 changement de mot de passe de la base de données de clefs, 11-34 Chemin d’accès sécurisé des communications, utilisation, 1-5 autorisation, 12-7 autorisation, 2-4 classes, 12-7 et hiérarchie, 12-9 rôle, 2-2 chiffrement par clé publique, NFS sécurisé, 13-3 autorité d’accréditation (CA) ajout de certificat root à la base de données, 11-30 demande de certificat à, 11-32 listes des autorités d’accréditation (CA), 11-29 paramètres sécurisés, 11-31 réception d’un certificat d’une, 11-32 suppression de certificat root de la base de données, 11-31 commande keylogin, NFS sécurisé, 13-3 B base de données de clefs, établissement de paramètres sécurisés pour, 11-31 clefs création d’une base de données, 11-29 modification de mot de passe de la base de données, 11-34 commande mount, NFS sécurisé, systèmes de fichiers, 13-10 commande sectoldif, 4-13 commande tcbck configuration, 1-5 utilisation, 1-3 compte utilisateur, contrôle, 2-9 contrôle d’accès droits d’accès étendus, 2-20 liste, 2-17, 2-20 création d’une base de données de clefs, 11-29 création de tunnels IKE utilisant des certificats numériques, 11-34 critère commun, 1-7 Index X-1 D dacinet, 9-10 données d’identification, 12-5 DES, 12-5 locales, 12-6 Données d’identification DES, 12-5 IPv4, voir également sécurité IP (Internet Protocol), 11-1 IPv6, 11-1 J journalisation de la sécurité IP, 11-45 données d’identification locales, 12-6 droit d’accès base, 2-19 étendus, 2-20 droit d’accès de base, 2-19 droits d’accès, 12-7, 12-9 droits d’accès étendus, 2-20 droits d’administrateur, 12-10 E EIM, voir aussi Enterprise Identity Mapping, 14-1 EIM (Enterprise Identity Mapping), 14-1 méthode actuelle, 14-2 K Key Manager, 11-28 L LDAP audit, Serveur d’informations de sécurité, 4-6 client, configuration, 4-3 gestion des utilisateurs, 4-4 mksecldap, 4-6 serveur d’informations de sécurité, configuration, 4-1 utilisation du sous–système de sécurité, 4-1 liens de sécurité (LS), relations avec les tunnels, 11-11 F fichier /etc/publickey, 13-6 filtres règles, 11-5 relations avec les tunnels, 11-9 liens de sécurité (SA), 11-3 ls–secldapclntd, 4-12 M filtres, configuration, 11-39 mandants, sécurité, 12-4 flush–secldapclntd, 4-13 Mappage des attributs LDAP, 4-16 format de fichier ldap.cfg, 4-14 mgrsecurity, 2-1, 2-8, 2-23 mksecldap, 4-6 G mode d’accès, droit d’accès de base, 2-19 mot de passe RPC sécurisé, 12-1 gestion des clefs, et des tunnels, 11-4 gestion des utilisateurs, LDAP, 4-4 I ID de connexion, 2-10, 2-30 IKE, caractéristiques, 11-3 index des paramètres de sécurité (SPI), et lien de sécurité, 11-3 infrastructure à clef publique, 6-1 Internet Engineering Task Force (IETF), 11-1 Internet Key Exchange, voir IKE, 11-3 IP, voir Internet Protocol, 11-1 X-2 Guide de sécurité N NFS (Network File System) fichier /etc/publickey, 13-6 NFS sécurisé, 13-1 administration, 13-7 authentification, 13-3 chiffrement, 13-1 chiffrement par clé publique, 13-3 code César, 13-1 configuration, 13-8 cryptanalyse, 13-1 cryptographe, 13-1 déchiffrage, 13-1 DES (Data Encryption Standard), 13-2 entités réseau, 13-6 exportation d’un système de fichiers, 13-9 nom réseau, 13-6 performances, 13-7 règles d’authentification, 13-4 systèmes de fichiers, 13-10 texte chiffré, 13-1 texte en clair, 13-1 touche, 13-1 NFS sécurisé, 13-1 NIS+ mandants, 12-4 sécurité, 12-2 O OpenSSH, utilisation avec PAM, 8-3 P paramètres sécurisés pour base de données de clefs, établissement, 11-31 PKI, 6-1 processus de l’utilisateur root, fonctions, 2-19 programme setgid, utilisation, 2-18 programme setuid, utilisation, 2-18 protection du système d’exploitation, autorisation de modification, 2-2 Protocole Internet, sécurité, 11-1 caractéristiques, 11-2 fonctions IKE, 11-3 système d’exploitation, 11-1 protocole LDAP (Light Directory Access Protocol), voir LDAP, 4-1 R restart–secldapclntd, 4-12 généralités, 2-2 maintenance, 2-4 mots de passe, 2-2 sauvegarde, 2-2 S SAK, 1-6 secldapclntd, 4-10 Secure Attention Key, configuration, 1-6 sécurité compte root, 2-1 Internet Protocol (IP), 11-1 NIS+, 12-2 authentification, 12-2 autorisation, 12-3, 12-7 données d’identification, 12-5 droits d’administrateur, 12-10 mandants, 12-4 niveaux, 12-4 présentation, 1-1 authentification, 2-30 identification, 2-30 tâches d’administration, 2-8, 2-23 système d’exploitation, 12-1 TCP/IP, 9-1 sécurité du système d’exploitation, 12-1 ajout d’un module, 7-6 authentification, 12-1 autorisation de modification, 2-5 bibliothèque, 7-2 débogage, 7-6 extension des restrictions, 2-29 fichier de configuration, /etc/pam.conf, 7-4 intégration avec AIX, 7-7 introduction, 7-1 modification du fichier /etc/pam.conf, 7-6 modules, 7-3 mot de passe RPC sécurisé, 12-1 portes, 12-1 RPC sécurisé, 12-1 utilisation avec OpenSSH, 8-3 rôle, 2-4 arrêt, 2-2 autorisation, 2-4 généralités, 2-2 maintenance, 2-4 mots de passe, 2-2 sauvegarde, 2-2 sécurité IP certificats numériques, 11-6 filtres, 11-5 et tunnels, 11-9 gestion des clefs et tunnels, 11-4 liens de sécurité, 11-3 LS (liens de sécurité), 11-11 tunnels choix du type, 11-11 et filtres, 11-9 et liens de sécurité, 11-11 rôles administratifs, 2-4 arrêt, 2-2 autorisation, 2-4 Sécurité IP (Internet Protocol) configuration, 11-39 planification, 11-7 restauration autorisation, 2-6 rôle, 2-2 Index X-3 installation, 11-6 journalisation, 11-45 règles de filtre prédéfinies, 11-44 sécurité IP (Internet Protocol), 11-1 identification des incidents, 11-50 référence, 11-62 serveur, informations de sécurité, LDAP, 4-1 Service d’authentification de certificats, généralités, 6-1 service d’authentification de certificats, généralités, 6-1 start–secldapclntd, 4-11 stop–secldapclntd, 4-12 suppression d’un certificat numérique personnel, 11-33 suppression de certificat root d’autorité d’accréditation, 11-31 système conforme CAPP/EAL4+, 1-7 système de quotas disque configuration, 2-32 généralités, 2-30 T TCB, 1-1 TCP/IP .netrc, 9-3 /etc/ftpusers, 9-7 /etc/hosts.equiv, 9-6 /usr/lib/security/audit/config, 9-3 sécurité, 9-1 accès à distance aux commandes, 9-6 DOD, 9-10 X-4 Guide de sécurité données, 9-10 NTCB, 9-8 restriction d’accès FTP, 9-7 SAK, 9-3 shell sécurisé, 9-3 système d’exploitation, 9-2 TCP/IP, 9-3, 9-7 utilisateurs FTP restreints, 9-7 sécurité IP, 11-1 fonctions IKE, 11-3 identification des incidents, 11-50 installation, 11-6 planification, 11-7 référence, 11-62 règles de filtre prédéfinies, 11-44 voir Internet Protocol, 11-2 tunnel générique de gestion des données, utilisation de XML, 11-15 tunnels choix du type, 11-11 et clefs, gestion, 11-4 relations avec les filtres, 11-9 relations avec les liens de sécurité, 11-11 tunnels IKE, création, avec certificats numériques, 11-34 U utilisateur, 2-2, 2-5 ajout, 2-2, 2-5 V Virtual Private Network (VPN), 11-1 VPN, avantages, 11-6 Vos remarques sur ce document / Technical publication remark form Titre / Title : Bull AIX 5L Guide de sécurité Nº Référence / Reference Nº : 86 F2 22EG 00 Daté / Dated : Octobre 2002 ERREURS DETECTEES / ERRORS IN PUBLICATION AMELIORATIONS SUGGEREES / SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION Vos remarques et suggestions seront examinées attentivement. Si vous désirez une réponse écrite, veuillez indiquer ci-après votre adresse postale complète. Your comments will be promptly investigated by qualified technical personnel and action will be taken as required. If you require a written reply, please furnish your complete mailing address below. NOM / NAME : SOCIETE / COMPANY : ADRESSE / ADDRESS : Remettez cet imprimé à un responsable BULL ou envoyez-le directement à : Please give this technical publication remark form to your BULL representative or mail to: BULL CEDOC 357 AVENUE PATTON B.P.20845 49008 ANGERS CEDEX 01 FRANCE Date : Technical Publications Ordering Form Bon de Commande de Documents Techniques To order additional publications, please fill up a copy of this form and send it via mail to: Pour commander des documents techniques, remplissez une copie de ce formulaire et envoyez-la à : BULL CEDOC ATTN / Mr. L. CHERUBIN 357 AVENUE PATTON B.P.20845 49008 ANGERS CEDEX 01 FRANCE Phone / Téléphone : FAX / Télécopie E–Mail / Courrier électronique : +33 (0) 2 41 73 63 96 +33 (0) 2 41 73 60 19 [email protected] Or visit our web sites at: / Ou visitez nos sites web à: http://www.logistics.bull.net/cedoc http://www–frec.bull.com http://www.bull.com CEDOC Reference # No Référence CEDOC Qty Qté CEDOC Reference # No Référence CEDOC Qty Qté CEDOC Reference # No Référence CEDOC __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] __ __ ____ _ [__] Qty Qté [ _ _ ] : no revision number means latest revision / pas de numéro de révision signifie révision la plus récente NOM / NAME : Date : SOCIETE / COMPANY : ADRESSE / ADDRESS : PHONE / TELEPHONE : FAX : E–MAIL : For Bull Subsidiaries / Pour les Filiales Bull : Identification: For Bull Affiliated Customers / Pour les Clients Affiliés Bull : Customer Code / Code Client : For Bull Internal Customers / Pour les Clients Internes Bull : Budgetary Section / Section Budgétaire : For Others / Pour les Autres : Please ask your Bull representative. / Merci de demander à votre contact Bull. PLACE BAR CODE IN LOWER LEFT CORNER BULL CEDOC 357 AVENUE PATTON B.P.20845 49008 ANGERS CEDEX 01 FRANCE REFERENCE 86 F2 22EG 00 Utiliser les marques de découpe pour obtenir les étiquettes. Use the cut marks to get the labels. AIX AIX 5L Guide de sécurité 86 F2 22EG 00 AIX AIX 5L Guide de sécurité 86 F2 22EG 00 AIX AIX 5L Guide de sécurité 86 F2 22EG 00