Sécuriser un annuaire OpenLDAP

Introduction

La sécurité est évidemment importante dans le monde de l’informatique et encore plus depuis que les ordinateurs sont interconnectés en réseau et reliés à Internet. Les annuaires sont donc tout aussi concernés, car ils sont susceptibles de contenir des informations sensibles qui doivent être protégées des accès non autorisés et de modifications (sous-entendu de la destruction d’information). Mais la sécurité concerne également la façon dont les données sont transmises et transitent sur le réseau, car elles peuvent être interceptées ou bien modifiées, et aussi le besoin de savoir qui se connecte à notre annuaire.

OpenLDAP possède donc des mécanismes intégrés qui permettent de répondre à toutes les problématiques évoquées précédemment :

Par des mécanismes d’authentification : afin de s’assurer que le client LDAP est bien celui qu’il prétend être par la validation d’une combinaison "utilisateur/mot de passe" et s’appuyant sur l’utilisation de mécanismes SASL, d’architectures Kerberos ou bien à l’aide de certificats x509.
Par l’application de politique de mots de passe : c’est un ensemble de règles qui contrôlent...

Authentification (ou ouverture de session LDAP)

Comme pour toute application, afin de pouvoir l’utiliser, il faut d’abord s’y connecter.

Ainsi, un client LDAP souhaitant parcourir les données contenues dans l’annuaire devra ouvrir une session sécurisée sur celui-ci. Cette opération de connexion à l’annuaire est nommée Bind (du verbe "lier" en français) et est apparue avec le protocole LDAPv3 qui impose à un client LDAP de s’authentifier auprès de l’annuaire ciblé afin d’accéder aux données de celui-ci. Cette étape est critique, car les données échangées ne doivent en aucun cas être interceptées pour ainsi être utilisées à des fins frauduleuses. L’annuaire OpenLDAP intègre donc ses propres mécanismes d’authentification et en propose d’autres bien plus sécurisés.

1. L’authentification de base ou simple

L’authentification de base (ou simple), comme son nom l’indique, est celle utilisée par le protocole LDAPv3 et offre tel quel, bien peu de sécurité, car l’opération d’authentification (l’échange de l’utilisateur et du mot de passe) s’effectue "en clair" sur le réseau... et ceci n’est donc évidemment plus recommandé. Cependant, il sera expliqué plus loin dans ce chapitre, qu’il est possible de faire appel à un protocole de couche inférieure (SSL/TLS) qui permet de réaliser le cryptage de l’opération d’authentification et même de l’échange des données.

Ce mode d’authentification offre la possibilité de se connecter à l’annuaire par trois méthodes :

Avec une combinaison "utilisateur/mot de passe" connue de l’annuaire (user/password authenticated) .
Avec seulement le nom de l’utilisateur, mais sans le mot de passe (unauthenticated) .
Et enfin, de manière anonyme (anonymous).

L’authentification classique dite "authentifiée" par transmission d’un identifiant utilisateur et d’un mot de passe permet donc de s’assurer de l’identité des personnes qui accèdent à l’annuaire et de parcourir...

La politique de mot de passe

Les annuaires LDAP étant utilisés à 90 % pour centraliser les authentifications d’utilisateurs auprès de nombreux systèmes et applications, cela signifie donc qu’il contiendra un grand nombre de mots de passe. Ces mots de passe, bien que chiffrés dans l’annuaire, peuvent être compromis soit parce qu’ils sont trop simples (attaque par dictionnaire), soit par leur interception (attaque du type "Man in the middle") ou bien soit tout simplement par une personne de l’entreprise qui l’aurait vu ou connu d’une manière scrupuleuse ou pas.

Ainsi, pour éviter ce type de désagrément, il conviendra toujours de mettre en place une politique de mot de passe exigeant de le complexifier par l’obligation d’insérer un nombre minimum de caractères comportant des caractères spéciaux et aussi des "majuscules/minuscules". Cette politique de mot de passe peut et doit également comprendre des règles d’expiration (par exemple, un mot de passe doit expirer tous les trois mois), de rotation (afin de ne pas mettre toujours le même mot de passe lors de son renouvellement) et sur le nombre de tentatives maximum autorisé avant verrouillage du compte (permet de contrer les attaques de type dictionnaire).

L’application d’une politique de mot de passe est disponible...

Le stockage des mots de passe

Les mots de passe des utilisateurs stockés dans l’annuaire LDAP sont généralement contenus dans l’attribut userPassword.

Cet attribut peut exister localement dans l’annuaire LDAP où se trouve l’utilisateur, ou bien faire référence à un attribut userPassword distant situé sur un autre annuaire LDAP grâce au mécanisme PTA.

De plus, cet attribut étant bien entendu très sensible en termes de sécurité, car confidentiel et propre à chaque utilisateur, il devient donc important de le chiffrer afin de le cacher aux yeux de toutes personnes y compris du "Super LDAP administrateur".

En effet, il n’est pas obligatoire, mais fortement conseillé de choisir de le chiffrer par un algorithme de type "empreinte cryptographique" qui est indéchiffrable, car irréversible : aucune clé n’existe pour le déchiffrer.

Ainsi, l’annuaire LDAP ne conservera que l’empreinte du mot de passe appelé "hash", "hashing" ou bien "condensé" du mot de passe.

L’annuaire OpenLDAP permet dans son schéma de contenir des condensés de type SHA, MD5 et d’autres. Il utilise par défaut SSHA qui est jusqu’à présent le plus robuste.

Attention : OpenLDAP, par défaut, ne condense pas les mots de passe qui lui sont transmis en clair. En effet, il accepte les condensés transmis par les clients LDAP, mais lui n’en générera pas. À moins de le forcer au travers d’une politique de mot de passe via l’attribut olcPPolicyHashCleartext = TRUE (cf. chapitre traitant des overlays).

Même en étant connecté en "Super LDAP administrateur" souvent nommé cn=root, il est impossible d’avoir accès à la valeur de l’attribut userPassword, car l’annuaire ne stocke que l’empreinte des mots de passe.

1. Rappel sur les algorithmes de cryptage de type condensé

Il existe deux types d’algorithmes de cryptage : ceux dont le message initial est brouillé, mais peut être ensuite décrypté, et ceux dont le brouillage est à sens unique et donc non réversible. Ces derniers sont généralement nommés "empreinte, condensé...

La configuration réseau

Une fois la topologie réseau choisie, il faudra penser à intégrer l’annuaire LDAP dans le réseau de l’entreprise actuel.

Il conviendra donc de déterminer l’interface physique sur laquelle le démon "slapd" du serveur LDAP va écouter les connexions clientes entrantes, de déterminer ses ports d’écoute (389/TCP pour des connexions non sécurisées et 636/TCP pour des connexions sécurisées LDAPS) et enfin, de s’assurer que le serveur LDAP est accessible depuis tous les clients LDAP envisagés (nécessitant des ouvertures de ports sur les pare-feu et des opérations de NAT à définir avec l’équipe réseau de l’entreprise).

1. Sélectionner son (ou ses) interface(s) réseau et son (ou ses) port(s) d’écoute(s)

Par défaut, le démon "slapd" écoute sur toutes les interfaces réseaux définies sur le serveur, pour toutes les adresses en IPv4 et IPv6 et pour tous les ports TCP LDAP standards : 389 pour les connexions non sécurisées et 636 pour les connexions sécurisées.


[root@ldap01 ldap]# netstat -atunp |grep -i slapd |grep LISTEN 
tcp       0      0 0.0.0.0:636      0.0.0.0:*      LISTEN      1818/slapd ...

Fixer des limites aux opérations LDAP

Le service d’annuaire LDAP étant en libre-service et proposé à tous clients voulant utiliser ses services, il convient donc d’imposer des règles appelées "limites" afin qu’un seul client trop actif ne monopolise l’intégralité de l’activité du serveur LDAP. En effet, ceci peut apparaître volontairement par l’activité d’un hacker qui voudrait provoquer un arrêt ou une dégradation du service LDAP (on parle alors de "déni de service") par émission d’un grand nombre de requêtes LDAP et/ou trop complexes engendrant ainsi une suractivité de l’annuaire. Mais ce cas de figure pourrait également apparaître à cause d’un problème de configuration du client LDAP.

1. Le type de limites

OpenLDAP fournit ainsi deux sortes de limites qui seront appliquées aux requêtes LDAP, en provenance des différents clients de l’entreprise, entrantes dans l’annuaire :

Une limite de taille qui permettra de restreindre le nombre d’entrées qu’un client peut récupérer en une seule opération.
Et une limite de temps qui permettra de stopper la requête après un temps de traitement trop long.

2. Les limites hard ou soft

Pour chacune des limites (taille ou temps)...

Confidentialité et intégrité des communications

Une fois que le serveur et le client LDAP se sont mutuellement identifiés, en justifiant de manière plus ou moins poussée (simple mot de passe ou certificats) qu’ils étaient bien ceux qu’ils prétendaient être, ils peuvent désormais commencer à communiquer entre eux. Seulement, il faut maintenant s’assurer que cette communication ne puisse pas être interceptée, modifiée ou tronquée. Un annuaire LDAP étant destiné principalement à centraliser l’authentification de divers équipements informatiques (applications et systèmes) dans des environnements souvent vastes et complexes, il est donc difficile de l’isoler avec ses différents clients (par exemple dans des VLANS) afin de garantir qu’aucune personne de l’extérieur ne puisse intercepter les communications échangées. Ceci n’est donc pas envisageable dans un monde où les réseaux sont ouverts... Il convient donc de se tourner vers des protocoles de chiffrement qui garantissent aussi bien la confidentialité des données par l’utilisation d’algorithmes de chiffrement très complexes que l’intégrité de celles-ci en apportant une signature électronique pour chaque communication échangée. OpenLDAP donne la possibilité de s’offrir les services de TLS et SSL qui seront donc en charge de cette mission, mais aussi de certains mécanismes SASL qui peuvent également assurer ce service de chiffrement.

OpenLDAP offre la possibilité d’utiliser SSL/TLS et StartTLS. Il est fortement conseillé d’utiliser ces protocoles de sécurisation des échanges, en particulier lors des phases d’authentification de type simple avec transmission des mots de passe en clair sur le réseau.

1. Présentation de SSL et TLS

SSL et TLS sont des protocoles de sécurisation des échanges sur des réseaux ouverts tels qu’Internet. D’ailleurs, ces protocoles sont très utilisés sur Internet et iconisés par un cadenas dans nos explorateurs Internet.

SSL (Secure Sockets Layer) a été développé par Netscape puis standardisé par l’IETF...

Configuration du LDAPS avec SSL/TLS

Il a été défini dans le cahier des charges de cette infrastructure LDAP de démonstration d’utiliser le protocole LDAPS, dans la mesure où tous les clients LDAP seraient compatibles.

Afin de réaliser cette opération de configuration du protocole LDAPS, il faut au préalable créer un certificat personnel pour le serveur LDAP (nommé CSR), et l’émettre à une autorité de certification officielle, reconnue sur la toile (Verisign, Digicert), afin qu’il soit signé. Le certificat ainsi obtenu (CRT, PEM, DER) pourra être appliqué dans la configuration du serveur LDAP.

Voici ci-dessous un exemple réalisé sous RHEL6 à l’aide des commandes openssl.


# Création du certificat avec une clé RSA de 2048 bits (le minimum à mettre) 
# On produit donc la clé privée dans le fichier : ldap01.key 
# Et le CSR dans le fichier :  ldap01.csr 
# Lors de la création de ce CSR, plusieurs informations seront  
demandées telles que ' Country Name,  Locality Name, etc. 
# Portez une attention particulière sur « Common Name », car c'est ce champ 
qui sera utilisé pour vérifier l'identité de votre serveur sur Internet et 
devra donc correspondre avec l'entrée DNS publiée sur le Net. 
 
[root@ldap01]# openssl req -new -newkey rsa:2048 -nodes -keyout ldap01.key 
-out ldap01.csr 
Generating a 2048 bit RSA private key 
....................+++ 
.....................................................................+++ 
writing new private key to 'ldap01.key' 
----- 
You are about to be asked to enter information that will be incorporated 
into your certificate request. 
What you are about to enter is what is called a Distinguished Name or a DN. 
There are quite a few fields but you can leave some blank 
For some fields there will be a default value, 
If you enter '.', the field will be left blank. 
----- 
Country Name (2 letter code) [XX]:FR 
State or Province Name (full name) []: 
 
Locality Name (eg, city) [Default City]:MONACO 
Organization Name (eg, company) [Default Company Ltd]:Entreprise SA 
Organizational Unit Name (eg, section) []:GGS...