Guide pratique de l'authentification des utilisateurs

Alors que je tentais d'ajouter des services réseaux (pour la plupart inutiles :) à mon réseau personnel, j'ai été confronté à de nombreuses reprises au problème de l'authentification. J'ai donc décidé de comprendre comment l'authentification fonctionne sur Linux, d'écrire un guide pratique et d'en faire mon projet de fin d'études. J'espère que ce document vous aidera à comprendre cet aspect de l'administration système souvent oublié mais néanmoins très important.

Vous trouverez la plus récente version française de ce document à l'adresse : http://www.traduc.org/docs/howto/lecture/User-Authentication-HOWTO.html.

La plus récente version de la version originale de ce document est disponible à l'adresse : http://www.linuxdoc.org.

Merci de faire parvenir en anglais à l'auteur vos questions et commentaires relatifs à la version originale de ce document à l'adresse <petehern CHEZ yahoo POINT com>.

N'hésitez pas à faire parvenir tout commentaire relatif à la version française de ce document à <commentaires CHEZ traduc POINT org> en précisant sont titre, sa date et sa version.

© 2000 Peter Hernberg pour la version originale.

© 2005 Raphaël Semeteys pour la version française.

Ce manuel peut être reproduit en tout ou partie, sans frais, en respectant les restrictions suivantes :

Merci à ma famille de me supporter depuis 18 ans. Merci aux gens de Debian de fournir une distribution si sympa avec laquelle je peux jouer. Merci à CGR de me payer à être un geek. Merci à Sandy Harris pour ses utiles suggestions. Et finalement j'aimerai remercier les fabricants de nouilles chinoises, car je ne sais comment je vivrais sans.

Je considère dans la suite de ce document que le lecteur est à l'aise avec tout ce qui touche à l'exécution en ligne de commandes et l'édition de fichiers de configuration.

Dans pratiquement toutes les distributions Linux (ainsi que les versions commerciales d'Unix), l'information sur les utilisateurs est stockée dans /etc/passwd, un fichier texte contenant le login de chaque utilisateur, son mot de passe encrypté, un identifiant numérique unique d'utilisateur (appelé l'uid), un identifiant numérique unique de groupe (appelé le gid), un champ optionnel de commentaire (contenant généralement des choses comme le nom, le numéro de téléphone, etc.), le répertoire personnel et le shell préféré. Une entrée typique de /etc/passwd ressemble à ceci :

  pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  

Comme vous pouvez le voir, c'est plutôt simple. Chaque entrée contient les six champs décrits plus haut, avec ":" comme séparateur. Si l'authentification des utilisateurs était aussi simple que cela, il n'y aurait pas besoin de ce guide.

En observant votre /etc/passwd, il y a des chances que vous ayez vu quelque chose comme ceci :

  pete:x:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  

Où est donc passé le mot de passe encrypté ? Avant de répondre, une petite explication s'impose.

Le ficher /etc/passwd, qui contient l'information sur tous les utilisateurs y compris leurs mots de passes encryptés, est consultable par tous, ce qui rend capable n'importe quel utilisateur d'obtenir le mot de passe encrypté de n'importe qui sur le système. Bien que les mots de passes soient encryptés, des programmes de piratage sont largement disponibles. Les mots de passes Shadow ont été développés afin de combattre cette menace grandissante.

Lorsque les mots de passes Shadow sont activés sur un système, le champ correspondant au mot de passe dans /etc/passwd est remplacé par un "x" et le véritable mot de passe encrypté est stocké dans /etc/shadow. Comme /etc/shadow est uniquement consultable par l'utilisateur root, les utilisateurs malicieux ne peuvent pas pirater les mots de passes des autres utilisateurs. Chaque entrée de /etc/shadow contient le login de l'utilisateur, son mot de passe crypté et un certain nombre de champs liés à l'expiration du mot de passe. Une entrée typique ressemble à ceci :

    pete:/3GJllg1o4152:11009:0:99999:7:::
   

L'information sur les groupes est stockée dans /etc/group. Le format est similaire à celui de /etc/passwd, avec chaque entrée contenant des champs pour le nom du groupe, le mot de passe, l'identifiant numérique (gid) et une liste de membres du groupe séparés par des virgules. Une entrée typique de /etc/group ressemble à ceci :

   pasta:x:103:spagetti,fettucini,linguine,vermicelli
  

Comme vous pouvez le voir, il est également possible d'utiliser des mots de passes Shadow. Bien que les groupes ne disposent pratiquement jamais de mots de passes propres, cela ne coûte rien de stocker les mots de passes Shadow des groupes dans /etc/gshadow.

Traditionnellement, les mots de passes Unix sont encryptés avec la fonction standard crypt(). (Pour plus d'information sur la fonction crypt(), se reporter à la page man crypt(3).) Au fur et à mesure que les ordinateurs sont devenus plus puissants, les mots de passes encryptés sont devenus plus faciles à pirater. Et avec l'émergence d'Internet, des outils de piratage utilisant la puissance de traitement de plusieurs ordinateurs en réseau ont fait leur apparition. De nombreuses "nouvelles" distributions offrent la possibilité d'encrypter les mots de passes avec l'algorithme de hashage MD5, qui est plus puissant. (Pour plus d'information sur l'algorithme de hashage MD5, se reporter au RFC 1321.) Bien que les mots de passes MD5 n'éliminent pas la menace du piratage, ils rendent cette tâche beaucoup plus difficile.

Comme vous pouvez le voir, il existe plusieurs manières différentes de stocker l'information d'authentification des utilisateurs sur votre système (mots de passes Shadow sans encryptage MD5, mots de passes /etc/passwd avec encryptage MD5, etc.). Comment des programmes comme login et su savent-ils comment vérifier votre mot de passe ? Pire encore, et si vous vouliez modifier la manière dont les mots de passes sont stockés dans votre système ? Comment les programmes nécessitant votre mot de passe sauront-ils que les mots de passes sont désormais stockés différemment ? La solution est PAM.

Au tout début de Linux, si un programme comme su, passwd, login ou xlock, avait besoin d'authentifier un utilisateur, il lisait simplement l'information nécessaire dans /etc/passwd. Pour modifier le mot de passe il éditait simplement /etc/passwd. Cette méthode simple mais maladroite posait de nombreux problèmes aux administrateurs systèmes et aux développeurs d'applications. Une fois MD5 et les mots de passes Shadow devenus incroyablement populaires, chaque programme nécessitant l'authentification d'un utilisateur devait savoir récupérer l'information appropriée, tout en étant capable de gérer de nombreuses configurations différentes. Lorsque vous vouliez modifier la configuration de l'authentification des utilisateurs, tous ces programmes devaient être recompilés. PAM élimine ce désordre en permettant aux programmes d'authentifier les utilisateurs de manière transparente, indépendamment de la méthode de stockage de l'information.

Voici un extrait du Guide administrateur système Linux-PAM (version anglaise) : "Le projet Linux-PAM a pour objet de séparer le développement de logiciels d'autorisation de celui de méthodes d'authentification sécurisées. Ceci est réalisé en fournissant une bibliothèque de fonctions utilisables par une application pour demander qu'un utilisateur soit authentifié". Avec PAM, peu importe que votre mot de passe soit stocké dans /etc/passwd ou sur un serveur à Hong Kong. Lorsqu'un programme a besoin d'authentifier un utilisateur, PAM fournit une bibliothèque contenant les fonctions appropriées à la méthode d'authentification utilisée. Comme cette bibliothèque est chargée dynamiquement, le changement de méthode d'authentification peut être réalisé par simple modification d'un fichier de configuration.

La souplesse est un des plus grands atouts de PAM. PAM peut être utilisé, par exemple, pour refuser à certains programmes le droit d'authentifier les utilisateurs, pour n'autoriser que certains utilisateurs à être authentifiés, pour émettre des notifications lorsque certains programmes tentent de réaliser une authentification ou même pour priver tous les utilisateurs du droit de se connecter. La conception modulaire de PAM vous donne le contrôle total sur comment sont authentifiés les utilisateurs.

Assez parlé, rentrons dans le vif du sujet.

  ~$ cd /etc/pam.d
  /etc/pam.d/$ ls
  chfn	chsh	login	other	passwd	su	xlock
  /etc/pam.d/$ 
  

  /etc/pam.d/$ cat login
  # Configuration PAM pour login
  auth       requisite  pam_securetty.so
  auth       required   pam_nologin.so
  auth       required   pam_env.so
  auth       required   pam_unix.so nullok
  account    required   pam_unix.so
  session    required   pam_unix.so
  session    optional   pam_lastlog.so
  password   required   pam_unix.so nullok obscure min=4 max=8
  

  type  contrôle  chemin-vers-le-module   arguments-du-module
  

    auth    required    pam_unix.so nullok
    

    login   auth    required    pam_unix.so nullok
    

Pour plus d'information concernant la configuration de PAM et la référence complète des modules PAM, consultez le Guide administrateur système Linux-PAM (version anglaise). Ce guide fait office de référence exhaustive et à jour au sujet de la configuration de PAM.

Chaque fichier placé dans /etc/pam.d/ contient la configuration relative à un service donné. L'exception à la règle est le fichier /etc/pam.d/other. Ce fichier contient la configuration à utiliser pour tout service ne disposant pas de son propre fichier de configuration. Par exemple, si le service (imaginaire) xyz tentait une authentification, PAM chercherait un fichier /etc/pam.d/xyz. N'en trouvant aucun, l'authentification pour xyz serait déterminée par le fichier /etc/pam.d/other. Comme /etc/pam.d/other est la configuration utilisée en dernier recours, il est important qu'elle soit sécurisée. Nous allons étudier deux configurations de /etc/pam.d/other, l'une quasi-paranoïaque et l'autre plus permissive.

    auth	    required	pam_deny.so
    auth	    required	pam_warn.so
    account	    required	pam_deny.so
    account	    required	pam_warn.so
    password	required	pam_deny.so
    password	required	pam_warn.so
    session	    required	pam_deny.so
    session	    required	pam_warn.so
    

    auth	    required	pam_unix.so
    auth	    required	pam_warn.so
    account	    required	pam_unix.so
    account	    required	pam_warn.so
    password	required	pam_deny.so
    password	required	pam_warn.so
    session	    required	pam_unix.so
    session	    required	pam_warn.so
    

Sur la plupart des systèmes Linux il existe un certain nombre de comptes utilisateurs "factices" utilisés pour attribuer des droits à des services systèmes comme serveurs ftp, Web ou les passerelles de messagerie. Disposer de ces comptes permet à votre système d'être plus sécurisé car si ces services sont compromis, un utilisateur malveillant n'obtiendra que les droits limités du compte factice, plutôt que les droits étendus d'un service système tournant sous root. Cependant, donner le droit de connexion à ces comptes constitue une faille de sécurité car ils ont généralement des mots de passes vides. L'option de configuration qui active les mots de passes vides est l'argument "nullok" transmis au module. Vous préférerez enlever cet argument de tous les modules de type "auth" des services autorisant les connexions. Il s'agit habituellement du service login, mais cela peut également inclure des services comme rlogin et ssh. Ceci implique que la ligne suivante dans /etc/pam.d/login :

   auth		required	pam_unix.so	nullok
   

doive être transformée en :

   auth		required	pam_unix.so
   

En regardant les fichiers situés dans /etc/pam.d/, vous remarquerez probablement la présence de fichiers de configuration pour un certain nombre de programmes que vous n'utilisez pas, voire même certains dont vous n'avez jamais entendu parler. Bien que le fait d'accorder l'authentification à ces services ne crée probablement pas d'énorme trou de sécurité, vous feriez mieux de leur refuser ce droit. Le meilleur moyen de désactiver l'authentification PAM pour ces programmes est de renommer ces fichiers. Ne trouvant pas le fichier nommé d'après le service, PAM appliquera la configuration par défaut /etc/pam.d/other qui est, a priori, très sécurisée. Si plus tard vous vous rendez compte avoir besoin d'un de ces programmes, vous pouvez tout simplement redonner au fichier son nom initial et tout fonctionnera comme c'est sensé le faire.

Les outils de piratage de mots de passes peuvent certes être utilisés par des utilisateurs malveillants pour mettre à mal un système, mais peuvent aussi être utilisés par les administrateurs systèmes pour vérifier le niveau de sécurité des mots de passes sur leurs systèmes. Les deux outils de piratage de mots de passes les plus utilisés sont "crack" et "John the Ripper". "Crack" est probablement déjà intégré à votre distribution favorite. "John the Ripper" peut être téléchargé sur http://www.openwall.com/john/. Lancez les outils sur votre base de mots de passes et vous serez probablement surpris par le résultat.

En outre, il existe un module PAM qui utilise la bibliothèque de "crack" pour vérifier le niveau de sécurité du mot de passe d'un utilisateur lorsqu'il est modifié. Lorsque ce module est installé, l'utilisateur peut modifier son mot de passe uniquement lorsqu'il satisfait aux exigences minimales de sécurité.

Comme déjà dit dans la première section de ce document, les mots de passes Shadow et MD5 vous permettent de sécuriser votre système. Lors de la procédure d'installation, la plupart des distributions modernes vous demanderont si vous désirez utiliser les mots de passes MD5 et/ou Shadow. A moins que vous ayez une bonne raison de ne pas le faire, vous devriez activer ces options. Le processus de conversion des mots de passe non MD5 et non Shadow est compliqué et hors du périmètre de ce document. Le Guide pratique des mots de passes Shadow (version anglaise) n'est plus vraiment à jour mais peut tout de même s'avérer utile sur le sujet.

A titre d'exemple, nous allons installer et configurer mod_auth_pam, un module Apache permet d'authentifier les utilisateurs de votre serveur Web en passant par PAM. Dans la suite de cet exemple je considèrerai qu'Apache est déjà installé. Si ce n'est pas le cas, vous devriez être capables de trouver les paquetages d'installation auprès de votre distributeur.

L'objectif est de configurer sur notre serveur Web une zone privée, le répertoire famille/, nécessitant une authentification des utilisateurs via PAM. Ce répertoire contient des informations familiales réservées uniquement aux membres du groupe "famille".

Tout d'abord, vous devez télécharger mod_auth_pam depuis http://pam.sourceforge.net/mod_auth_pam/. Utilisez les commandes suivantes pour compiler mod_auth_pam (vous devez être connectés en tant que root) :

   ~# tar xzf mod_auth_pam.tar.gz
   ~# cd mod_auth_pam-1.0a
   ~/mod_auth_pam-1.0a# make
   ~/mod_auth_pam-1.0a# make install
   

Si vous avec des problèmes lors de l'installation du module mod_auth_pam, assurez-vous d'avoir bien installé le paquetage apache-dev de votre distribution. Une fois le module installé vous devrez redémarrer Apache. Cela est habituellement fait par la commande suivante (encore une fois vous devez être root) :

   ~# /etc/init.d/apache restart
   

La configuration PAM pour Apache est stockée dans /etc/pam.d/httpd. La configuration par défaut (installée en même temps que mod_auth_pam) est sécurisée mais utilise un module (pam_pwdb.so) qui est indisponible sur de nombreux systèmes. (En outre, configurer ce module à partir de zéro sera une vraie partie de plaisir !) En conclusion, effacez le fichier /etc/pam.d/httpd et créez en un nouveau.

     auth	required	pam_unix.so
     

     auth	required	pam_unix.so
     account	required	pam_unix.so
     

Maintenant que PAM est configuré pour authentifier les requêtes d'Apache, nous allons configurer Apache afin d'utiliser PAM pour gérer l'accès au répertoire famille/. Pour ce faire, ajoutez les lignes suivantes à votre fichier httpd.conf (habituellement stocké dans le répertoire /etc/apache/ ou /etc/httpd) :

    <Directory /var/www/famille>
    AuthPAM_Enabled on
    AllowOverride None
    AuthName "Secrets de famille"
    AuthType "basic"
    require group famille
    </Directory>
    

Il se peut que vous ayez à remplacer /var/www/ par l'emplacement par défaut de vos documents Web, qui est souvent /home/httpd/. Quel que soit le répertoire concerné, vous devez y créer le sous répertoire famille.

Avant de tester notre configuration, je vais prendre quelques minutes pour expliquer la configuration Apache que vous venez de réaliser. La directive <Directory> est utilisée pour encapsuler des données de configuration pour ce répertoire. A l'intérieur de cette directive, nous avons activé l'authentification PAM ("AuthPAM_enabled on"), désactivé la surcharge de la configuration ("AllowOverride none"), nommé la zone d'authentification "Secrets de famille" (AuthName "Secrets de famille"), positionné le type de l'authentification HTTP (et non l'authentification PAM) à la valeur par défaut ("AuthType "basic"") et restreint l'accès au groupe "famille" ("require group famille").

Maintenant que tout est correctement configuré, il est temps d'admirer notre succès. Lancez votre navigateur favori et rendez vous à http://votre-domaine/famille/ (en remplaçant votre-domaine par votre nom de domaine). Ca y est, vous disposez désormais d'un système d'authentification des utilisateurs !

Beaucoup d'information peut être recueillie dans les pages du manuel de votre système. Ci suivent quelques pages man relatives à l'authentification des utilisateurs. Le nombre entre parenthèses se réfère à la section concernée de la page man. Par exemple, pour visualiser la page man passwd(5), vous devez entrer man 5 passwd.