Solution complète de serveur de messagerie avec domaines et utilisateurs virtuels (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Page 10

VII. Email sécurisé

Dans un monde idéal, nos utilisateurs pourraient envoyer/recevoir des emails chaque fois qu’ils sont sur le net, de n’importe quel endroit dans le monde. Malheureusement, c’est incroyablement peu sûr… les mots de passe sont échangés en texte clair via les protocoles SMTP et IMAP, et cela signifie que quiconque le souhaite pourrait simplement “espionner” le mot de passe.

Si vos utilisateurs n’ont pas besoin d’accès direct à la solution de messagerie, alors ne leur donnez pas ! Il n’y a aucun intérêt à se stresser pour une configuration de messagerie sécurisée si tout ce dont vos utilisateurs ont besoin est Webmail ! Il suffit de sécuriser leur connexion au serveur de webmail, et de s’assurer que le serveur de webmail utilise une connexion réseau sécurisée lorsqu’il communique avec vos serveurs de messagerie. Problème résolu ! Si, en revanche, vos utilisateurs ont besoin de la capacité d’envoyer/recevoir des emails via Internet sans utiliser Webmail, eh bien, cela rend les choses plus difficiles. Pas impossible, juste difficile.

Donc, voici votre problème : SMTP et IMAP envoient des mots de passe en texte clair. Vous pouvez les faire envoyer des mots de passe en utilisant MD5, mais le MD5 de base peut être piraté. Vous pouvez les faire envoyer des mots de passe en utilisant MD5CRYPT, mais alors vous devez gérer plusieurs implémentations (sans parler du fait que tous les clients de messagerie ne prennent pas en charge les mots de passe MD5). La solution ? TLS (Transport Layer Security). Nous allons configurer notre solution pour prendre en charge une connexion cryptée sur Internet. Bien que nous puissions modifier certains de nos serveurs existants pour gérer cela, il n’y a aucun intérêt à compliquer leurs configurations. Nous allons simplement exécuter un serveur séparé pour gérer tout cela : secure-mail.example.com

NOTE : Dans le scénario original, la petite entreprise avait plusieurs adresses IP statiques. Comme c’est le cas, nous avons pu exécuter SMTP+TLS sur le port 25, si vous n’avez pas plusieurs adresses IP, alors cela n’est pas possible. La raison est assez simple : Alors que IMAPS (IMAP sécurisé) fonctionne sur un port différent (993) que l’IMAP standard (143), SMTP+TLS fonctionne sur le MÊME port que SMTP (25). Donc, utiliser un pare-feu pour router en fonction des ports vous permet d’exécuter des serveurs IMAP et IMAPS séparés, mais aucun pare-feu au monde ne peut router le port 25 vers deux machines différentes. Même avec tout cela, vous pourriez toujours exécuter SMTP+TLS sur un port non standard… après tout, cela serait même plus sécurisé.

Donc, avec tout cela en tête, nous allons configurer un serveur de messagerie sécurisé, qui utilise SMTP+TLS pour envoyer des emails, et IMAPS pour les recevoir.

A. Certificats SSL

La forme la plus simple de cryptage est d’avoir un simple certificat auto-signé sur le serveur. Cela générera un message d’avertissement lorsque les clients se connecteront pour la première fois, mais ils devraient pouvoir le sauvegarder pour une utilisation ultérieure. Ce n’est pas vraiment sécurisé, car n’importe qui peut exécuter une attaque de l’homme du milieu si vous ne sauvegardez pas le certificat.

Le niveau suivant consiste à utiliser un certificat serveur signé par une Autorité de Certification (CA), soit une commerciale, soit peut-être la CA interne de l’entreprise. De cette façon, le certificat serveur sera de confiance, et si vous recevez maintenant un avertissement, il y a potentiellement quelque chose de mauvais qui se passe.

Dernier point mais pas des moindres, l’utilisation de certificats clients pour se connecter au serveur, et l’utilisation d’un certificat serveur pour authentifier le serveur auprès des clients. C’est assez sécurisé, mais ce n’est pas pris en charge par tous les clients de messagerie. Thunderbird, entre autres, prend en charge cela.

1. Certificat serveur auto-signé

Tout d’abord, créez les répertoires, créez la clé privée, et enfin créez le certificat.

# mkdir -p /etc/ssl/example.com/mailserver/  
# cd /etc/ssl/example.com/mailserver/  
# openssl genrsa 1024 > mail-key.pem  
# chmod 400 mail-key.pem  
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Notez que “Nom commun (par exemple, VOTRE nom)” DOIT correspondre au nom du serveur, qui dans ce cas est secure-mail.example.com

2. Certificat signé par une CA

Utiliser un certificat signé par une vraie CA n’est pas différent de l’utilisation d’un certificat auto-signé. C’est juste une étape supplémentaire dans la création de la paire de clés. Si votre entreprise a sa propre CA, alors elle devrait émettre un certificat pour le serveur de messagerie. Une recherche Google pour “soyez votre propre CA” vous donnera suffisamment de réponses pour en créer un vous-même, si vous en avez besoin.