AdminII TP07 Sécurisation Service Mail - dudleydehenau/Ephec GitHub Wiki

TP7 : Sécurisation du service mail

1. Mise en place du service mail

Dans un premier temps, il a fallu configurer notre zone DNS pour ajouter notre MX et A pour notre sous-domaine mail.l2-6.ephec-ti.be.

Ensuite, nous avons configuré le reverse DNS en configurant le PTR côté OVH en spécifiant, comme PTR, l'adresse mail.l2-6.ephec-ti.be (mail envoyé à Mme Van Den Shriek, qui est l'administratrice de nos VPS).

Nous sommes prêts à déployer le service mail. Dans un premier temps, il faut déployer le conteneur. Voici le fichier Docker Compose :

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest
    container_name: mailserver
    hostname: mail.l2-6.ephec-ti.be
    env_file: mailserver.env
    ports:
      - "25:25"
      - "465:465"
      - "587:587"
      - "993:993"
    volumes:
      - ./docker-data/dms/mail-data/:/var/mail/
      - ./docker-data/dms/mail-state/:/var/mail-state/
      - ./docker-data/dms/mail-logs/:/var/log/mail/
      - ./docker-data/dms/config/:/tmp/docker-mailserver/
      - /etc/localtime:/etc/localtime:ro
      - tp05_letsencrypt:/etc/letsencrypt:ro  # Montée du volume
    restart: always
    stop_grace_period: 1m
    healthcheck:
      test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
      timeout: 3s
      retries: 0

volumes:
  tp05_letsencrypt:
    external: true

Note intéressante : nous récupérons le volume Let's Encrypt de la partie sécurisation du serveur web. Cela me permet d'avoir une unicité dans la signature de mes clés. Il est très encombrant de posséder ses clés Let's Encrypt dans plusieurs conteneurs Docker. Je l'ai aussi configuré en mode lecture seule (RO). Ayant déjà Certbot installé sur mon conteneur NGINX, il est inutile de le réinstaller ici et je risque moins de problèmes de surécriture de clés.

Ensuite, il faut créer de nouvelles clés pour mon nouveau sous-domaine.

sudo docker exec -it nginx_web certbot certonly --standalone -d mail.l2-6.ephec-ti.be

Et ces clés doivent être accessibles pour le serveur mail. La bonne pratique veut que les clés soient stockées dans /tmp/docker-mailserver/ssl/. Cependant, mes clés se trouvent dans /etc/letsencrypt. Nous allons donc créer des liens symboliques. Ainsi, je ne déplace pas mes clés et je respecte les règles de bonnes pratiques.

Dans un premier temps, dans le fichier mailserver.env, je m'assure que les lignes suivantes soient présentes :

SSL_TYPE=letsencrypt
SSL_CERT_PATH=/tmp/docker-mailserver/ssl/fullchain.pem
SSL_KEY_PATH=/tmp/docker-mailserver/ssl/privkey.pem

Je démarre le conteneur et, à l'intérieur de celui-ci, je crée mes liens symboliques :

sudo docker exec -it mailserver mkdir -p ./docker-data/dms/config/ssl
sudo docker exec -it mailserver ln -sf /etc/letsencrypt/live/mail.l2-6.ephec-ti.be/fullchain.pem /tmp/docker-mailserver/ssl/fullchain.pem
sudo docker exec -it mailserver ln -sf /etc/letsencrypt/live/mail.l2-6.ephec-ti.be/privkey.pem /tmp/docker-mailserver/ssl/privkey.pem

Et maintenant, notre machine est prête à accueillir les premiers utilisateurs :

docker exec -it mailserver setup email add [email protected]
docker exec -it mailserver setup email add [email protected]

Ainsi que l'utilisateur postmaster :

docker exec -it mailserver setup alias add [email protected] [email protected]

Après avoir adapté le pare-feu, nous pouvons maintenant tester notre serveur mail.

La première étape est de se connecter via un client mail.

Une fois connecté, je tente un premier envoi de mail.

Et il est correctement reçu :

Les échanges internes fonctionnent. Je tente ensuite d'envoyer un mail vers une boîte Google.

Il est refusé par Google car le serveur mail n'est pas authentifié.

Nous verrons cela plus tard dans le TP. J'essaie donc avec une boîte mail peu sécurisée et je reçois bien le mail :

Email-temporaire-–-Email-à-usage-unique-Email-anonyme-04-10-2025_02_27_PM

Enfin, voici ce que retourne le test avec MXToolBox de mon service :

Capture d’écran du 2025-04-10 14-30-49

Réponses aux questions

Comment sont gérés les utilisateurs ? Via les utilisateurs Unix, un fichier, une base de données ?
Les utilisateurs sont gérés via des fichiers de configuration "postfix-accounts.cf" dans le conteneur Docker Mailserver. Il n'y a ni utilisateurs Unix ni base de données.
Quel est le format de mailbox utilisé ?
Les boîtes mail utilisent le format Maildir, qui stocke les mails dans des dossiers "cur/", "new/", "tmp/" séparés par utilisateur.

2. Sécurisation du service mail

2.1. Analyse du chiffrement TLS

Réponses aux questions

Pour l'envoi, le numéro de port utilisé est le 465, et nous sommes sur du TLS implicite (reconnaissable à la présence de Client Hello et au port utilisé).

Pour la réception, le port utilisé est le 993, et nous sommes également sur du TLS implicite.

2.2. Authentification du domaine

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

Tout est OK. Tout est OK. Pas de DMARC trouvé, mais nous ne l'avons pas encore configuré.

Tout est OK.

2.2.2. SPF

Pour configurer le SPF, il suffit d'ajouter une ligne dans notre zone DNS :
@ IN TXT "v=spf1 mx -all"

J'ai tenté un envoi vers Gmail, il a bien été reçu, mais il apparaît dans les spams :

À partir d'ici, nous devrions constater que le SPF fonctionne correctement.

2.2.3. DKIM

Pour mettre en place le DKIM, il faut tout d'abord générer les clés :
docker exec -it mailserver setup config dkim

Cela crée les clés et la configuration à ajouter dans notre DNS.

On ajoute cela dans le DNS et on redémarre notre serveur mail en effectuant un docker compose down puis up -d. (Sans cette étape, cela n'a pas fonctionné pour moi.)

Et dans l'en-tête du mail, j'ai bien ma signature DKIM :

Résultat MXToolBox :

2.2.4. DMARC

Pour mettre en place le DMARC, il suffit d'ajouter une ligne dans le DNS, qui servira à savoir comment traiter les mails potentiellement malveillants. Pour ma part, j'ai décidé de les mettre en quarantaine et d'envoyer ensuite un rapport à mon adresse mail :
_dmarc.l2-6.ephec-ti.be. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

On ajoute cela dans le DNS et on redémarre le DNS et le mailserver.

Il suffit ensuite de faire un test DMARC sur MXToolBox pour vérifier si tout fonctionne.

Voici le score SpamAssassin :

Les sécurités DKIM, DMARC et SPF étant mises en place, pour l'optimiser, il suffit d'éviter d'avoir un mail ressemblant à un mail frauduleux (mot "gratuit", "promo", ... , lien douteux, en-tête modifié, ...).

2.3. Filtrage du spam

Il suffit d'activer l'option dans mailserver.env en changeant
ENABLE_SPAMASSASSIN=0 à
ENABLE_SPAMASSASSIN=1
Dans mon mail propre, rien à signaler :

Par contre, dans mon mail douteux :

J'ai un flag et un score de presque 1000 points de spam.