Bull AIX 5.2 Manuel utilisateur

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,
jdoe@studentmail.ut.edu.
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 nom@austin.ibm.com.
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 utilisateur@nom.austin.ibm.com.
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 unix.hal@eng.ibm.com. 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
srv.Cedoc@franp.bull.fr
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
">