Dans un cadre professionnel, j’ai du examiner les principaux mécanismes de sécurité de Dovecot. Dovecot est à la base un serveur IMAP (même si il propose un module POP3). Les variantes sécurisées IMAPS et POPS sont évidemment supportées. Elles intègrent le support de SSL pour authentifier le serveur auprès des clients et chiffrer la connexion. En effet, les protocoles de messagerie ont tendance à se reposer sur des authentification en clair. Commençons par installer Dovecot. J’ai décidé de faire ma configuration sur FreeBSD. L’installation est faite via les ports. Mes options de compilation sont les suivantes :
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for dovecot-1.2.3
_OPTIONS_READ=dovecot-1.2.3
WITH_KQUEUE=true
WITH_SSL=true
WITHOUT_IPV6=true
WITHOUT_POP3=true
WITH_LDA=true
WITHOUT_MANAGESIEVE=true
WITHOUT_GSSAPI=true
WITHOUT_VPOPMAIL=true
WITHOUT_BDB=true
WITHOUT_LDAP=true
WITHOUT_PGSQL=true
WITHOUT_MYSQL=true
WITHOUT_SQLITE=true
Comme d’habitude, il convient d’ajouter dovecot_enable=”YES” dans le rc.conf. L’essentiel de la configuration se fait dans le fichier dovecot.conf. Pour activer IMAPS :
Notre configuration va prendre un certificat autosigné côté serveur.
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out ./server.crt -keyout ./server.key
Cette commande génère une clé RSA de 2048 bits “server.key” et le certificat autosigné associé “server.crt”. Pour les déclarer dans Dovecot, il faut utiliser les primitives suivantes :
ssl_cert_file = /usr/local/etc/ssl/dovecot/server.crt
ssl_key_file = /usr/local/etc/ssl/dovecot/server.key
J’ai pour habitude des les placer dans /usr/local/etc/ssl/dovecot. Au niveau ACL du système de fichier, je retire les droits d’écriture sur la clé et le certificat pour tout le monde (user, group et other). Pour la clé, seul le propriétaire a le droit de lecture :
total 8
drwxr-xr-x 2 root wheel 512 Aug 30 16:08 .
drwxr-xr-x 4 root wheel 512 Aug 30 16:08 ..
-r--r--r-- 1 root wheel 1627 Aug 30 16:08 server.crt
-r-------- 1 root wheel 1675 Aug 30 16:08 server.key
Un aspect intéressant de Dovecot est qu’il utilise intensivement les principes de séparation et du moindre privilège. La séparation de privilèges implique un éclatement des processus pour idéalement tendre vers l’état suivant : 1 action = 1 processus système. Le moindre privilège implique que les droits du compte associé à chaque processus sont limités au strict minimum. En effet, une fois Dovecot démarré (et configuré) un seul processus tourne sous “root” :
root 61934 0.0 0.1 5652 1348 ?? SsJ 10:15PM 0:00.05 dovecot
Ce processus maitre sert uniquement à gérer les sockets réseaux liées à des ports priviligiés (ici imaps sur le 993) et à lancer le processus gérant l’authentification “dovecot-auth” ainsi que celui gérant le service IMAP jusqu’à ce que l’utilisateur s’authentifie “imap-login”. Le processus “imap-login” doit tourner sous un compte non privilégié (ici dovecot).
Pour le processus “dovecot-auth” c’est moins clair. Dans notre configuration (détaillée par la suite) il n’est pas nécessaire d’utiliser le compte root. Un compte authdovecot a donc été crée.
authdovecot 62210 0.0 0.2 7828 1516 ?? SJ 10:48PM 0:00.01 dovecot-auth
authdovecot 62211 0.0 0.1 7828 1432 ?? SJ 10:48PM 0:00.00 dovecot-auth -w
dovecot 62212 0.0 0.3 9600 2584 ?? SJ 10:48PM 0:00.01 imap-login
dovecot 62213 0.0 0.3 9600 2584 ?? SJ 10:48PM 0:00.01 imap-login
dovecot 62214 0.0 0.3 9600 2584 ?? SJ 10:48PM 0:00.01 imap-login
Enfin le processus “imap” va gérer la session IMAP après connexion de l’utilisateur. Ce processus peut tourner sous deux identités :
- Avec le compte système de l’utilisateur si celui-ci existe (notre cas).
- Avec un compte générique pour toutes les boites (le plus souvent nommé vmail) dans le cas de destinataires virtuels. Ces destinataires n’ont pas d’existence au sens système du terme c’est à dire pas d’UID (on peut vivre sans UID ?).
Dans notre configuration, un utilisateur “nico” dédié au mail existe et son compte est bloqué. De cette manière, l’utilisateur dispose d’un UID et dovecot peut invoquer “imap” sous cette identité:
nico 69094 0.0 0.2 7708 2080 ?? SJ 7:20AM 0:00.01 imap [nico 193.XXX.XXX.XXX]
Pour dovecot, deux éléments composent un utilisateur : ses informations (login, uid etc.) et sa méthode d’authentification. Cette configuration se fait dans la section “auth default” du fichier dovecot.conf :
auth default {
mechanisms = cram-md5
passdb passwd-file {
args = /usr/local/etc/cram-md5.pwd
}
userdb passwd {
args = blocking=yes
}
user = authdovecot
}Le paramètre userdb donne la base des données des utilisateurs à utiliser. Par défaut Dovecot prend les comptes systèmes locaux (du moins ceux présentés par le service NSS où équivalent). Par exemple : si on a un annuaire LDAP avec des utilisateurs au format PosixAccount, on peut toujours utiliser la userdb par défaut (si NSS est bien configuré pour, of course !). La passdb contient les mots de passes chiffrés pour les utilisateurs. Par défaut, dovecot repose sur la PAM. Cette méthode possède un défaut majeur : le mot de passe circule en clair. Même avec le support de SSL, un man in the middle sauvage peut survenir (surtout sur un réseau local). La seule trace pour l’utilisateur sera la présentation d’un certificat invalide qu’il s’empressera d’accepter. Pour mitiger ce risque, il suffit de changer le mécanisme d’authentification (ici CRAM-MD5) :
Une fois cette modification effectuée, il faut se définir un fichier de mot de passe personnalisé. Dans notre exemple /usr/local/etc/cram-md5.pwd :
passdb passwd-file {
args = /usr/local/etc/cram-md5.pwd
}Les entrées de ce fichier sont au format ‘user:{algorithme}secret’. User correspond au nom d’utilisateur, algorithme renseigne sur la fonction de chiffrement appliquée et secret représente le mot de passe chiffré.
nico:{CRAM-MD5}**********Cette configuration permet de limiter les droits de l’identité sous laquelle le processus “dovecot-auth” s’exécute. Deux point sont à prendre en compte : l’accès aux information utilisateur et l’authentification. Par défaut les utilisateurs ont le droit de récupérer la liste des comptes utilisateurs d’une machine (commande ‘getent passwd’). Coté authentification, La seule contrainte est que le compte système utilisé pour le processus ait accès en lecture sur le fichier pour faire les lookups.
-r--r----- 1 authdovecot dovecot 80 Aug 31 19:45 cram-md5.pwd
Voila c’est fini ! Dans le prochain post, nous verrons comment s’appuyer sur l’authentification CRAM-MD5 de dovecot pour réaliser un service SMTP émetteur authentifié avec postfix.
). Le “smtpd_sasl_path” donne le chemin du fichier qui va permettre à Dovecot et Postfix de parler ensemble. Ce fichier doit absolument n’être utilisable que par l’utilisateur système postfix :
!