mise en place idéale de la sécu mail - MachiganMC/Woodytoys GitHub Wiki
Analyse idéale sécu mail
Explication du problème
Notre implémentation réseau se base sur une machine virtuelle Microsoft Azure. Cependant Microsoft, dans un soucis de sécurité, bloque les ports SMTP sur son service de VM. Cela s'est prouvé problématique quand il fallut mettre en place le web public.
Ce qui marche
Nous avons testé toutes les cause potentielles du non-fonctionnement du service mail public:
Résolution dns:
Notre ordinateur personel peut faire un ping vers le serveur mail
Par conséquent ça n'est pas un problème de résolution dns vers le serveur en lui-même
MX record
Pour établir un échange mail avec un ordinateur d'un autre serveur, cet ordinateur a besoin de savoir qui est le serveur responsable de la réception de mails. L'outil en ligne https://dnschecker.org/ nous a permis de confirmer que notre soa public communique bel et bien une adresse vers notre serveur mail
Par conséquent nous confirmons bel et bien qu'un ordinateur externe sais à qui s'adresser pour envoyer un mail et comment le joindre.
Connection au serveur mail via telnet
Une autre possibilité pourrait être que le service SMTP en lui-même ne permet pas la connexion, donc un ordinateur distant pourrait arriver jusqu'au serveur, mais se voir refuser toute communication au niveau applicatif. Nous avons testé cela en se connectant directement au serveur mail via son port en telnet. Le serveur est exposé sur le port 2525 comme tentative de contourner les limitations de Azure
Nous constatons que le mail à bel et bien été envoyé
Envoi de mail avec outlook
Utilisons la même adresse mail, mais via outlook cette fois
Ce mail-ci n'arrive jamais à destination
essayons a présent un envoi depuis le conteneur sur Azure
Même résultat
Conclusion des tests
Il est clair que le serveur mail est fonctionnel, mais les moyens conventionnels d'envoi de mail ne fonctionnent pas. Il y a donc fort a supposer que c'est dû a Azure qui bloque la communication.
Mise en place de la sécurité dans un contexte idéal
Les deux mécanismes de sécurité que nous devrions mettre en place sont SPF et DKIM.
SPF [1][2]:
SPF est un mécanisme de sécurité visant à avertir les autres serveurs mails qu'un mail que eux perçoivent comme venant de notre domaine proviens bel et bien de notre serveur mail. Sans SPF, quelqu'un connaissant notre nom de domaine peut facilement prétendre venir de notre domaine pour bypasser des listes anti-spam.
Pour mettre en place SPF
SPF consiste en quelques lignes ajoutées au fichier de zone du SOA public, plus précisément le fichier de zone que les serveurs web d'internet pourront questionner.
La ligne en question serait celle-ci: "m2-1.ephec-ti.be IN TXT v=spf1 a mx -all"
Qui se comprend comme suit: Pour le domaine m2-1.ephec-ti.be est associé un RR TXT utilisant la version 1 de SPF et informant que l'adresse de la machine courante (a) et l'adresse du serveur mx du réseau sont autorisés à envoyer des mail avec ce nom de domaine, tout les autres adresses doivent être rejetées.
Ainsi, lorsque un serveur mail reçoit un mail venant du domaine "m2-1.ephec-ti.be" il pourra vérifier grâce a ce RR TXT si l'adresse IP qui lui à envoyé ce mail est bien une adresse que nous avons jugée légitime.
Cette ligne au dessus est très basique et limitée, un serveur mail plus complet peut désigner certains relais mail acceptés, etc...
DKIM [3][4]:
Si SPF permet d'éviter que n'importe qui utilise notre nom de domaine, DKIM lui permet de protéger les adresses mail de notre domaine directement. Pour cela il utilise une forme de cryptographie asymétrique qui permet de signer les mails envoyés. Ce qui assure donc que l'expéditeur du mail est bel et bien authentique. Lors de l'envoi d'un mail, DKIM crée un en-tête au mail contenant les informations nécessaire au hashage et permettant au serveur destinataire d'effectuer l'authentification.
Tout comme SPF, DKIM doit avoir un enregistement DNS dans notre SOA:
par exemple: dkim._domainkey 1000 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgegxIM+FCbsQq1yn1xTI+NcMlbXZorrlpxBWF6h7YzI5sjZXh7KiZNabl7B6zqdbHCinmsjxGZB/0GvqyyFKtOs4ZPIDNrSQbhK/h/4jSbkDT9c1NhmSELVTl0ZZMaj+hnNhlgVLF3zP4TD0bx9tF/4tZlA/ezmhaP56i4C07swIDAQAB;"
Mais comment en arriver jusque là? Analysons le RR
"dkim._domainkey":
- "dkim" est ce qu'on appelle le "selecteur", c'est un mot que l'on peut choisir (dkim étant par défaut le plus compréhensible) qui sera placé dans l'en-tête du mail envoyé. Cela permettra au serveur de reception d'aller demander au SOA ce selecteur, auquel est associé le reste du RR.
- "_domainkey" indique que l'enregistrement DNS concerne DKIM
"v=DKIM1; k= rsa;":
Ce sont deux des différents tags que l'on peut ajouter a un Record DKIM. "v" indique la version de DKIM et "k" insique le type de clé utilisée.
Enfin la partie la plus important, la clé publique:
Comme dans toute cryptographie asymétrique, le serveur à besoin de deux clés, une publique et une privée. Ces clés peuvent être générées de plusieurs façon, dans notre cas, une méthode facile et fiable est "openssl"
Avant de generer les clés avec openssl, il faut d'abord installer opendkim, qui permet de configurer DKIM sur notre serveur mail.
RUN apt-get install opendkim
#par défaut, opendkim s'installe dans /etc, il est préférable de le déplacer dans /etc/opendkim
RUN mkdir -p /etc/opendkim/
RUN mv /etc/opendkim.conf /etc/opendkim/
RUN ln -s /etc/opendkim/opendkim.conf /etc/opendkim.conf
Ensuite, nous générons les clés et les associons aux fichiers de opendkim, pour qu'il puisse les utiliser
RUN openssl genrsa -out /etc/opendkim/opendkim.key 1024 #génere les clés
RUN openssl rsa -in /etc/opendkim/opendkim.key -pubout -out /etc/opendkim/opendkim.pub.key #place les clés pub et priv dans leur fichiers utilisable par opendkim
RUN chmod "u=rw,o=,g=" /etc/opendkim/opendkim.key #donne les autorisations a opendkim
RUN chown opendkim:opendkim /etc/opendkim/opendkim.key
Une fois la paire de clé publique et privée générée, il faut mettre la clé publique dans le RR. Ainsi, lors d'un envoi de mail, DKIM signera le mail envoyé avec sa clé privée, et le serveur de réception pourra récupérer la clé publique et vérifier que le mail est bien légitime.