TP7 : Sécurisation du service mail

Introduction

Après le service web, nous allons nous attaquer à la sécurisation du service mail. Nous ne nous attarderons pas sur la configuration, mais creuserons plus en détails les mécanismes permettant la sécurisation du mail.

A la fin de ce TP, vous devez être capable de :

  • Comprendre les paramètres principaux de la configuration du service mail
  • Expliquez et mettre en oeuvre du chiffrement dans les mails
  • Expliquez et mettre en oeuvre l’authentification du service mail (Reverse DNS, SPF, DKIM et DMARC)
  • Expliquez et mettre en oeuvre du filtrage de spam

Lectures préalables

Les éléments théoriques liés à ce TP sont présentés dans le chapitre 7 : Gestion et sécurisation d’un service mail du support de cours.

Pré-requis pour la réalisation du TP

Avant de pouvoir réaliser ce TP, assurez-vous d’avoir :

  • sécurisé votre VPS, notamment par la mise en place de l’authentification par clé SSH (TP3)
  • mis en place votre zone DNS, notamment via la délégation. (TP4)

Environnement de travail et organisation

Ce labo se réalisera sur base d’une image Docker avec les logiciels mail pré-installés. Il y aura peu de configuration à réaliser. La partie sécurisation implique plusieurs étapes qui ne dépendent pas nécessairement les unes des autres, et qui peuvent donc être réparties entre les membres du groupe.

Comme une bonne partie des tâches à effectuer consiste à observer/analyser et faire des liens avec la matières théoriques, il est important que vous preniez notes des éléments importants de vos observations pour les partager avec l’entièreté des membres du groupe par après.

Ce labo peut se réaliser soit sur le même VPS que précédemment, soit sur un autre. C’est une bonne idée de répartir les services sur plusieurs serveurs. Notez cependant que si vous utilisez un autre VPS que pour le web, vous ne pourrez pas utiliser le certificat wildcard du serveur web (à moins de le copier avec sa clé privée, ce qui n’est pas recommandé). Dans ce cas, vous pouvez générer un certificat pour la machine mail.lx-y.ephec-ti.be qui sera donc spécifique au serveur mail.

1. Mise en place du service mail

Nous travaillerons sur base de l’image Docker docker-mail-server, disponible sur le Docker Hub. Sa documentation est très compète, et accessible ici. En cas de souci, n’hésitez pas à consulter la page d’aide au troubleshooting.

1.1. Configuration au niveau du DNS

Les étapes préliminaires demandées dans la doc nécessitent des modifications au niveau de votre zone DNS :

  • Définir un Resource Record de type MX pour indiquer le nom de votre serveur de mail
  • S’assurer de la présence d’un record A pour la machine tenant le rôle de serveur mail
  • Configurer le Resource Record PTR du VPS avec le nom du serveur MX dans le domaine (typiquement, mail.lx-y.ephec-ti.be. Dans notre cas, le PTR se configure au niveau du fournisseur du VPS (qui possède les IPs). Actuellement, ce PTR pointe vers des noms de type vps-<idd>.vps.ovh.net. Pour réaliser cette étape et changer ce nom, contactez M. Van den Schrieck par mail en lui donnait le nom souhaité pour votre MX, son IP et son nom DNS actuel (vps-<idd>.vps.ovh.net).

1.2. Récupération des fichiers du serveur mail

La documentation indique de récupérer les fichiers pour le container mail en utilisant les commandes suivantes :

DMS_GITHUB_URL="https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master" 
wget "${DMS_GITHUB_URL}/compose.yaml" 
wget "${DMS_GITHUB_URL}/mailserver.env"

Cela permet de disposer de deux fichiers :

  • Un fichier Docker Compose sur lequel vous pourrez vous baser pour configurer votre serveur
  • Un fichier mailserver.env qui permettra d’affiner la configuration via des variables d’environnement
  • Editez le fichier Compose en ajustant le champ hostname : indiquez le FQDN correspondant à votre MX
  • Prenez connaissance des paramètres liés aux volumes et aux ports. Vous pourriez être amenés à les modifier plus tard.
  • Editez également le fichier mailserver.env :
    • Mettez la variable SSL_TYPE à la valeur letsencrypt : Nous utiliserons les certificats générés par certbot

1.3. Certificats TLS

Pour la configuration SSL/TLS, il faut mettre une combinaison clé privée/certificat à disposition de votre serveur mail. Pour être conforme à la configuration SSL_TYPE, ces derniers doivent être placés dans le répertoire /etc/letsencrypt (comme cela a été fait pour le serveur mail).

  • Si votre VPS n’a pas encore de certificat à sa disposition correspondant à son nom d’hôte, générez-en un avec l’outil certbot.
  • Ajustez le fichier Compose pour créer un volume mettant les certificats à disposition du container mail.

1.4. Démarrage et test du serveur

Une fois le TLS configuré, le serveur est prêt à démarrer avec un docker compose up. Le serveur mail peut être administré via un simple script setup.sh, qui permet notamment d’ajouter des utilisateurs. Ce script peut être appelé depuis l’hôte, comme ceci : docker exec -it \<containername\> setup \<commande\>

La commande helpvous donnera une vision de l’ensemble des commandes disponibles.

Lors du démarrage, le serveur mail va demander la configuration d’une première adresse mail endéans les deux minutes. Cela peut se faire via la commande :

docker exec -ti \<CONTAINER NAME\> setup email add user@example.com

N’hésitez pas à créer un second utilisateur pour les tests ultérieurs. Le mode d’emploi du container conseille également la création d’un alias pour l’adresse postmaster:

docker exec -ti \<CONTAINER NAME\> setup alias add postmaster@example.com user@example.com

  • Démarrez le serveur web et créez deux comptes utilisateur ainsi que l’alias postmaster
  • Configurer un logiciel client mail (ex : thunderbird) sur votre PC de travail pour pouvoir consulter les deux adresses mail créées
  • Testez le serveur en envoyant des mails. Gardez un oeil sur les logs pour identifier les différentes étapes (soumission, établissement de connexion TLS, placement dans les mailboxes, …).
    • Mails entre les deux comptes de votre domaine
    • Mail entrant : depuis un autre domaine vers votre domaine
    • Mail sortant : depuis une adresse de votre domaine vers l’extérieur

Au stade actuel, nous n’avons pas mis en place de mécanisme permettant d’authentifier le domaine : il est donc possible / probable que votre mail soit rejeté (dans ce cas, vous recevrez un mail en retour) ou placé dans les spams. Vérifiez donc vos dossiers “indésirables”.

Pour apprendre à connaître un peu votre serveur mail, n’hésitez pas à parcourir les répertoires disponibles sur les volumes, ainsi que ceux à l’intérieur du container. Essayez de répondre aux questions suivantes :

  1. Comment sont gérés les utilisateurs? Via les utilisateurs Unix, un fichier, une DB?
  2. Quel est le format de mailbox utilisé?

Nous pouvons effectuer une première évaluation du service mail. Cela peut se faire via le site “MXToolbox”. Utilisez pour cela le test “Test Email Server” de l’onglet “SuperTool”. L’objectif de la section suivante sera de répondre à tous les éléments du tests.

2. Sécurisation du service mail

Nous allons travailler la sécurisation du service mail selon deux axes :

  • le chiffrement
  • la lutte contre le spam via l’authentification du domaine et l’utilisation de filtre anti-spam.

2.1. Analyse du chiffrement TLS

Normalement, le TLS a été activé pour SMTP et IMAP lors de la configuration initiale du serveur mail. Vous avez du constater son fonctionnement lors de la première analyse MXToolbox.

Vous avez également sans doute noté que notre serveur mail écoute sur plusieurs ports, étant donc ouvert à la fois au TLS implicite et explicite (vérifiez-le avec un docker psou netstat).

Démarrez une capture Wireshark sur votre poste client avant d’envoyer un message depuis un compte de votre domaine, puis de le recevoir.

  • Pour l’envoi, quel est le numéro de port utilisé? S’agit-il de TLS implicite ou explicite (voir STARTTLS) ?
  • Même question pour la réception.

Une fois que votre serveur fonctionne, étudiez la possibilité de n’utiliser que du TLS implicite (en évitant donc la commande STARTTLS, qui n’est pas entièrement sécurisée). Documentez vos tests et réflexions sur votre wiki. Gardez bien une version de backup de vos configs sur Git avant de vous lancer dans vos tests.

Notez que le chiffrement TLS ne garantit la confidentialité du traffic qu’entre deux serveurs. Les données transitent malgré tout en clair sur les MTA. Pour éviter cela, il faut mettre en place du chiffrement de bout-en-bout.

Mettez en place sur votre client mail du chiffrement de bout en bout via S-MIME ou PGP.

2.2. Authentification du domaine

Afin de garantir aux autres utilisateurs Internet que notre domaine est bien configuré pour éviter de servir pour la génération de spam, quatre étapes peuvent être suivies. La documentation du container docker-mailserver donne des explications et procédures claires pour la configuration de certaines d’entre elles, n’hésitez pas à vous y référer en cas de difficulté.

2.2.1. L’alignement des records MX-PTR-A

Pour garantir qu’une machine est bien le MX d’un domaine, les serveurs mail et logiciels anti-spam vérifient les éléments suivants lorsqu’un serveur envoie un mail :

  • Le nom du serveur mail est bien celui renvoyé par le record MX du domaine annoncé
  • L’adresse IP du record A pour le nom donné par le MX possède un record PTR correspondant.

Vous vous êtes normalement déjà occupé de cette configuration dans le point 1.1.

Vérifiez dans l’outil MXToolbox les tests effectués sur ces trois records.

2.2.2. SPF

Un second moyen de validation d’un domaine consiste à annoncer publiquement, via le service DNS, les adresses des serveurs autorisés à envoyer des mails pour le domaine. De la sorte, lorsqu’un serveur reçoit un mail via SMTP, il peut vérifier si l’IP du serveur qui le contacte est légitime pour l’envoi de ce message. Il va pour cela effectuer un requête DNS de type TXT sur le domaine de l’adresse source, et se baser sur l’information reçue pour accepter l’email ou pas.

Un record typique pour un domaine simple est le suivant :

example.com. IN TXT "v=spf1 mx -all"

Il indique que le domaine example.comenverra des emails depuis son MX uniquement. Toute autre adresse IP doit être rejetée (-all)

  • Encodez un record SPF sur votre domaine
  • Vérifiez avec l’outil “SPF Record Lookup” que ce record est accessible et correct
  • Si vous aviez précédemment tenté d’envoyer un mail vers une adresse Gmail, vous avez probablement vu votre message refusé. Réessayez à présent et voyez si cela fonctionne mieux.

2.2.3. DKIM

Afin de garantir que l’email provient bien du serveur du domaine et n’a pas été modifié, on peut demander à notre serveur mail de calculer une signature DKIM. Ce mécanisme utilise lui aussi la cryptographie asymétrique : pour vérifier la signature d’un mail, on va donc faire appel à la clé publique correspondante à la clé privée utilisée pour la signature.

Notre image Docker-mailserver intègre déjà un logiciel permettant d’effectuer cette signature. Il s’agit de l’outil OpenDKIM. Pour le configurer, il lui faut une paire de clés privée/publique. Pour les générer, on utilise la commande setupsuivante :

docker exec -it \<CONTAINER NAME\> setup config dkim

Après cela, les clés seront disponibles dans le répertoire config/dkim accessible depuis votre VPS via les volumes. Le fichier mail.txt contient le RR à placer dans la zone DNS pour mettre la clé publique à disposition des serveurs souhaitant vérifier la signature.

  • Générez une paire de clés DKIM, puis placez le RR ainsi généré dans votre zone.
  • Redémarrez le serveur web (docker compose downpuis up)
  • Testez le DKIM :
    • Sur base de MXToolbox : vérification de la disponibilité et du format du RR DKIM dans le DNS
    • Vérifiez la présence de la signature dans les en-têtes des messages envoyés
    • Utilisez le site DKIM Validator pour vérifier si vos mails sont bien signés : le site vous donne une adresse email à laquelle envoyer un message, afin que le serveur puisse analyser la signature DKIM.

2.2.4. DMARC

DMARC permet d’annoncer aux autres serveurs mail ce qu’il faut faire en cas de réception de mail “douteux” (typiquement, en passant pas les checks SPF et DKIM).

Cet outil (cliquez sur DMARC guide) propose un formulaire à remplir pour générer le record DMARC correspondant à la politique souhaitée. Des exemples de politiques DMARC classiques sont également disponibles

  • Ajoutez un record DMARC à votre zone DNS
  • Testez le résultat via l’outil MXToolbox DMARC Lookup

Normalement, après avoir mis en place ces trois éléments, votre service mail devrait obtenir un très bon score sur le test MXToolbox Email Health

Une autre manière de vérifier si notre serveur mail obtient un score d’identification de spam correct est de passé par le site DKIM Validator. Ce dernier inclut un test d’identification de spam en utilisant l’outil SpamAssassin. Un score négatif montre que le mail n’est pas du spam.

Analysez votre score SpamAssassin. Comprenez-vous les tests appliqués pour calculer ce score? Comment l’optimiser ?

2.3. Filtrage du spam

Un premier filtre anti-spam est disponible, et une série de vérifications sont effectuées à la réception d’un email. Notamment, l’outil OpenDKIM que nous avons activé sur les mails sortant s’occupe également de la vérification des signatures sur les mails entrants. - Open DKIM effectue la vérification DKIM entrante

Nous avons déjà mentionné l’outil SpamAssassin pour vérifier nos mails sortants. Nous allons à présent l’activer sur les mails entrants. Pour cela, il faut mettre la variable d’environnement ENABLE_SPAMASSASSINà 1 dans le fichier mailserver.env. N’hésitez pas à jeter un oeil aux paramètres de config SpamAssassin dans ces mêmes variables d’environnement.

  • Activez SpamAssassin sur votre serveur, et redémarrez-le
  • Envoyez un mail à une adresse de votre domaine. Affichez les entêtes du mail : vous devriez voir des champs “X-Spam-Level” et “X-Spam-Status”
  • Vérifiez ce qu’il se passe en envoyant un mail “suspect” à une adresse de votre domaine. Vous pouvez par exemple utiliser le contenu indiqué ici, fait sur mesure pour obtenir un haut score de spam.

3. Pour aller plus loin

  • Mettez en place un serveur mail secondaire