7.3. Sécurisation du service mail
En passant en revue les menaces sur le service mail, les contre-mesures permettant de les mitiger ont été mentionnées. Nous allons ici les détailler plus précisément en abordant leurs aspects pratiques.
7.3.1. Le chiffrement des emails
Comme expliqué à la page précédente, le chiffrement des emails peut se faire à deux niveaux : soit entre les serveurs, soit de bout en bout.
Chiffrement TLS
Pour le chiffrement entre serveurs, TLS est utilisé entre la couche transport et la couche applicative, et permet donc de chiffrer aussi bien le SMTP que le POP ou l’IMAP. Comme la cryptographie asymétrique est utilisée, il faut garantir l’authenticité des clés publiques utilisées dans ces transferts. Des certificats TLS seront donc nécessaires pour chaque serveur. Ces derniers peuvent être obtenus auprès d’une autorité de certification, comme dans le cas du Web. Let’s Encrypt et le client ACME certbot peuvent être utilisés aussi dans ce cadre.
L’utilisation de TLS dans le cadre de l’email peut se faire de deux façons [14][15]:
- de façon explicite (aussi appelée TLS opportuniste) : la connexion s’effectue initialement de manière non sécurisée, puis le client demande un basculement sur TLS avec une commande protocolaire spécifique
- commande STARTTLS en IMAP et SMTP (la commande existe aussi pour de nombreux autres protocoles : IRC, XMPP, …)
- commande STLS pour POP3 Ce mode permet au serveur d’être accessible à la fois de manière chiffrée et non chiffrée, selon les possibilités du client. Néanmoins, comme une partie de l’échange n’est pas chiffrée, la sécurisation n’est pas idéale.
- ou bien de façon implicite ou forcée : l’utilisation d’un port spécifique implique automatiquement l’utilisation d’une connexion TLS dès le début de l’échange
Lors de l’utilisation de TLS, les services utilisent des ports TCP différents des ports non sécurisés, comme mentionné dans le tableau ci-dessous :
| Service | Port TCP (utilisable en TLS explicite) | Port pour TLS implicite |
|---|---|---|
| SMTP - relais | 25 | / |
| SMTP - soumission | 587 | 465 (SMTPS) |
| IMAP - récupération | 143 | 993 (IMAPS) |
| POP3 - récupération | 110 | 995 (POPS) |
Chiffrement de bout en bout avec S/MIME [1]
S/MIME est un content-type MIME supplémentaire, fournissant la possibilité de signer ou de chiffrer des messages emails. Il ajoute quatre nouvelles fonctions :
- La mise sous enveloppe des données via le chiffrement
- La signature numérique du message encodé en base 64
- La signature numérique du message en clair
- La mise sous enveloppe avec signature (chiffrement + signature numérique)
La figure ci-dessus montre le processus de signature et de chiffrement d’un message avec S/MIME.
Pour implémenter ces fonctions, S/MIME utilise la cryptographie asymétrique. Il est donc nécessaire d’obtenir que chaque utilisateur obtienne un certificat S/MIME auprès d’un fournisseur validé. Une fois le certificat obtenu, il faut alors que l’utilisateur configure son client mail (MUA) en lui donnant sa clé privée et le certificat S/MIME correspondant.
Chiffrement de bout en bout avec PGP [2,3]
PGP, ou Pretty Good Privacy, est un logiciel de cryptographie permettant de garantir la confidentialité et l’authentification des données. Il a été créé en 1991 par P. Zimmerman, et fut un des premiers logiciels exploitant la cryptographie à clé publique.
Il utilise la cryptographie asymétrique pour négocier une clé de session qui sera utilisée pour chiffrer les données.
PGP peut être utilisé aussi bien pour chiffrer les emails que pour leur adjoindre une signature numérique.
7.3.2. Les filtres anti-spam
Les filtres anti-spam se placent sur les serveurs et/ou les clients mail. Leur objectif est d’inspecter chaque message, et, en fonction de son contenu, de le classer comme “email autorisé/désirable” ou bien comme spam. L’algorithme d’un logiciel anti-spam se base sur plusieurs éléments [4], dont par exemple :
- Des white-lists, qui sont des listes d’adresses email source qui sont considérés comme légitimes, et pour lesquelles les emails seront normalement délivrés.
- Des black-lists, qui listent les réseaux, adresses ou serveurs considérés comme générateurs de spam. Elles se basent souvent sur le DNS (On parle de DNSBL, DNS-Based Blackhole List). Pour consulter une DNSBL, on envoie une requête DNS à son serveur sur base d’un RR correspondant à l’adresse IP (mécanisme semblable aux RR PTR). Si une réponse est reçue, cela signifie que le message peut être considéré comme du spam. Il existe de nombreuses DNSBL, mais la première connue est la Realtime Blackhole List. Créée en 1997, elle était à l’origine diffusée via le protocole BGP mais fut ensuite basculée sur le système DNSBL lorsque ce dernier apparu. Chaque liste a sa propre politique, par exemple, le système ORBS publie une liste des serveurs configurés en Open Relay. Notons que le contenu de ces listes est délicat à maintenir : comment garantir qu’une IP bannie était effectivement coupable? Que faire quand une IP ou un domaine est injustement blacklisté ? [5][6]. Notez qu’en complément des DNSBL, il existe aussi des DNS White Lists (DNSWL), basées sur le mêm système, listant les IP qui sont réputées ne pas générer de spams.
- Une analyse heuristique : des règles représentées par exemple sous forme d’expression régulière, identifiant des patterns ou des mots-clés indiquant la présence de spam. Ces analyses peuvent être enrichies via des bases de données de signatures de spam, alimentées par les utilisateurs de solutions anti-spams.
- Des filtres Bayesiens [7]: analyses statistiques adaptatives sur les fréquences des mots apparaissant dans les messages de l’utilisateur, permettant, après un apprentissage préabable, de déterminer la probabilité qu’un email soit du spam comparativement au contenu reçu de manière usuelle. Par exemple, beaucoup d’utilisateurs auront peu d’occurrence du mot “viagra” dans leurs messages, et un email le contenant aura donc une forte probabilité d’être du spam.
- Le filtrage basés sur les checksums : ce filtrage se base sur le fait qu’un spam est souvent envoyé massivement. Il va donc se baser sur des spams reçus pour en extraire des checksums permettant de les identifier lorsqu’ils seront reçus à nouveau par d’autres victimes. Ces checksums sont partagés dans des bases de données publiques, telles que la Distributed Checksum Clearinghouse.
- La présence d’URL suspectes dans le contenu du mail, pouvant indiquer une tentative de phishing
- La présence d’un enregistrement DNS PTR pour le serveur de messagerie envoyant le mail suspect, correspondant au nom du serveur mail du domaine (RR MX). Cette règle se base sur l’idée qu’un serveur de mail légitime a un nom cohérent avec le domaine qu’il gère.
- Les mécanismes SPF, DKIM et DMARC, présentés plus loin, et permettant à un serveur de mail de fournir des garanties de légitimité de ses messages.
Pour avoir un tour d’horizon plus complet et plus détaillé, la page Wikipedia ‘Anti-spam techniques’ est une bonne synthèse sur le sujet. Elle aborde également des contre-mesures / bonnes pratiques au niveau de l’utilisateur ou à destination des émetteurs massifs de mail (mailing lists, newsletters) que nous n’avons pas mentionnées ici.
Parmi les solutions anti-spam connues, le logiciel Open Source SpamAssassin [8][9] est fréquemment utilisé. Il est publié par la Apache Software Foundation. Il applique plusieurs méthodes de filtrage sur les messages reçus, et pour chaque résultat de test, attribue un score positif en cas d’indice de spam et négatif si l’email semble être légitime (on parle alors de “ham”). Un score global haut va alors déclencher une action sur le message (ajout d’un tag dans l’en-tête, envoie d’un message d’avertissement, mise en quarantaine, …).
Les méthodes utilisées par SpamAssassin sont, entre autres :
- La détection de patterns (expressions régulières)
- Les filtres bayesiens
- Les DNSBLs et DNSWLs
- SPF et DKIM
7.3.3. Assurer la légitimité de son domaine
Lorsqu’on fournit un service d’email, il est important de garantir aux autres utilisateurs et fournisseurs de services mail que notre domaine est digne de confiance, et n’est a priori pas une source de spam. Il est donc important que notre domaine ou l’IP de notre serveur web ne se retrouve pas dans blacklisté, mais à l’inverse, fasse éventuellement partie de White Lists, ou encore que les tests appliqués par les logiciels anti-spams donnent un résultat favorable.
Pour cela, il faut mettre en oeuvre une série de mécanismes et bonnes pratiques afin que le domaine passe les tests de DNSWL/DNSBL et des logiciels anti-spams. Nous allons ici en aborder quelques uns.
Eviter la configuration en Open Relay
Pour éviter d’être considéré comme un serveur “Open Relay”, il faut s’assurer que le MSA et le MTA n’acceptent que des emails originant de l’entreprise ou à destination de l’entreprise. Les contre-mesures à implémenter pour cela sont :
- Faire en sorte que le MTA n’accepte de recevoir que des emails uniquement destinés au(x) domaine(s) qu’il gère.
- Implémenter un mécanisme d’authentification lors de la soumission de mail (MSA)
- Limiter la soumission d’email aux adresses IPs autorisées, par ex. le réseau de l’entreprise, incluant le VPN.
Configurer adéquatement le Reverse DNS pour le serveur MX [10]
Un des tests appliqués par les filtres anti-spams mais également par certains serveurs MTA est le “Forward Confirmed reverse DNS (FCrDNS). Le principe est de vérifier que la correspondance nom/IP du serveur MX (RR type A) est équivalente à sa correspondance IP/Nom (RR type PTR).
Cette vérification est intéressante dans le cas du spam, car les spams sont souvent envoyés par des machines-zombies, avec des adresses source spoofées. Si on vérifie le record PTR correspondant à l’IP du serveur ayant envoyé le mail, on obtiendra vraissemblablement un nom DNS correspondant au domaine où se situe la machine zombie, et non le nom du MX du domaine de l’adresse source.
A l’inverse, si le serveur est légitime, son adresse IP aura a priori un PTR dans le domaine correspondant à l’adresse mail (excepté le cas plus complexe du fournisseur de mail qui gère plusieurs domaines).
Lorsqu’on gère un domaine mail, il est donc important de configurer un RR PTR pour le serveur MX public du domaine. Si l’IP du serveur MX appartient à un fournisseur d’accès, il importera alors de contacter ce dernier pour qu’il ajoute un PTR dans la zone reverse à laquelle l’IP appartient.
Publier les IPs autorisées pour un domaine avec SPF [11]
Une manière de permettre aux autres domaines de vérifier si un email provient bien de notre domaine consiste à leur fournir la liste (whitelist) des adresses IP qui sont autorisées à envoyer des emails. Cette technique permet de diminuer les risques d’usurpation d’identité.
Elle est implémentée par le mécanisme Sender Policy Framework (SPF). Ce mécanisme consiste à publier un Resource Record de type TXT dans le fichier de la zone correspondant au domaine de messagerie. Ce Resource Record contient une chaine de caractère explicitant la politique SPF du domaine . Cette chaîne peut contenir des IPs ou des subnets d’IP, mais elle peut également inclure des politiques SPF d’autres domaines.
(base) ➜ ~ dig -t TXT ephec.be
;; QUESTION SECTION:
;ephec.be. IN TXT
;; ANSWER SECTION:
ephec.be. 3600 IN TXT "v=spf1 ip4:176.62.168.242 ip4:176.62.168.243
ip4:193.190.65.91 ip4:137.74.73.10
include:spf.protection.outlook.com
include:spf.ymlp.com include:emsend3.com
-all"
Ci-dessus se trouve la requête dig permettant d’obtenir la politique SPF du domaine ephec.be. On peut voir que ce domaine annonce l’envoi autorisé d’emails depuis quatre adresses IPs, mais qu’il intègre également la politique SPF d’autres réseaux (outlook.com, ymlp.com et emsend3.com) susceptibles d’envoyer des emails avec une adresse source dans le domaine ephec.be. Le ‘-all’ final indique que toutes les autres IPs ne sont pas considérées comme source légitime.
Notez que SPF permet de valider l’IP du serveur mail émettant un message. Il ne permet pas, par contre de confirmer que l’adresse email source existe bien dans ce domaine!
Signer tous les emails sortant avec DKIM [12]
Une seconde manière de permettre à un externe de vérifier qu’un email provenant de notre domaine est bien valide consiste à intégrer une signature électronique à chaque message sortant. Ce principe est mis en oeuvre via le mécanisme DomainKeys Identified Mail.
Sans surprise, la cryptographie asymétrique sera exploitée pour fournir cette signature. Le serveur mail du domaine calculera, pour chaque email sortant, une signature cryptographie grâce à sa clé privée. Pour vérifier qu’un email est bien autorisé, un intervenant extérieur peut demander la clé publique du domaine à son serveur SOA, et grâce à cette clé publique, vérifier la validité de la signature.
<figcaption>
La signature cryptographie générée par DKIM est ajoutée à l’en-tête de l’email, avec d’autres informations dont le ‘sélecteur’, qui permet de récupérer les infos sur la clé publique dans la zone DNS. La valeur est quant à elle la signature elle-même.
Voici un exemple d’en-tête mail contenant une signature DKIM :
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=OgjaWk/FzMfMTcGEOFkcxiVW4jJr6pZmBpAGtzdFZQ4=;
b=gMbNKkwylZFLu6B+U2ZEvBIPLpKA3VQpOppZiSp9T9YDvYFOuZZ/bd3GbUVp2mZY8H
Nw/iFjcB0vB3d8KcZQLzPhH6r3h1Fr1nTOyL/nCw2k5HQW12tcYN+kvXX0BCh+NUdVcp
YLvYfdh6AwoRLJAeBBFZbClnbXVIypeVTAjRCnG8ppodSO/Qjk9FkMQGVGTw8fscIqdj
bkCTyepPPiCkC2+f70stI4YfkMUyhexh1HFyWupCcDAXgBLoJJ5wQqHlm889f3RtL7wJ
W+ah1Riec/BxyKAlFUy+5kkLk5rVqOMPWSLmBsob8/Jh+3CK+6nVnkgk3JvOg2Fh/1t5
RzOg==
On voit dans cet en-tête plusieurs paires clé/valeur : la clé “a” indique l’algorithme utilisé, la clé “d” renseigne le domaine concerné, la clé “s” identifie le sélecteur. La signature est, elle, identifié par la clé “b”.
Pour obtenir la clé publique permettant de vérifier cette signature, il faut interroger la zone DNS gmail.com, pour obtenir le resource record TXT associé à ce sélecteur. Voici ci-dessous la requête Dig permettant d’obtenir cela :
Garulfo:~ vvandens$ dig -t TXT 20161025._domainkey.google.com
; <<>> DiG 9.10.6 <<>> -t TXT 20161025._domainkey.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62844
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;20161025._domainkey.google.com. IN TXT
;; ANSWER SECTION:
20161025._domainkey.google.com. 59 IN TXT "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXNZF1j8sJPDleRjf9S
PBNem0ik58kF1ilC1nUgKAttl9v7FX9hXJXPmLNhVtSKVZ8yruaeOZLeIxtgtk1
s81zzIE5Mj0AiGn2wlFt4kYfqlDfYe95YLQHjynu4i7vj1Tj\" \"ksf62btcCbL+
3XhbK+oD5PlqYhXHWuzoKoEp5L4lCihgkONvU/oy7NNeE6quqfF/y0YSLwF2WVA 2Kd8L6R0Ar2dYT/3wZCFknI7xhvPqh9HNcIWBELGPwtXcsHbX1wvBlCgNQAUcdJ
rf2YWzAwqmZ564/1ipL1IMk1nafPJk75ktumVNz6ORuIn3jbZWp9rRpnaeI9cu/
8KfSKH2EY9QIDAQAB"
On retrouve le sélecteur “20161025” récupéré dans l’en-tête de l’email au niveau de la requête dig : il est utilisé pour construire le nom DNS 20161025.\_domainkey.google.com. La clé publique se retrouve au niveau de la réponse, derrière l’identifiant “p”.
Annoncer sa politique de gestion anti-spam via DMARC [13]
En complément des deux mécanismes cités ci-dessus, un domaine peut également informer le reste d’Internet de sa politique de validation des emails (SPF, DKIM ou les deux), et annoncer ce qu’il faut faire en cas d’échec d’un test de validation d’un email : Faut-il supprimer l’email fautif, le mettre en quarantaine ou le laisser passer? Envoyer une notification au domaine pour le prévenir?
Le mécanisme DMARC permet de réaliser cela, en utilisant à nouveau le DNS au travers un RR TXT.
Voici ci-dessous le RR DMARC du domaine ebay.com, obtenu via une simple requête dig :
$ dig TXT _dmarc.ebay.com
;; QUESTION SECTION:
;_dmarc.ebay.com. IN TXT
;; ANSWER SECTION:
_dmarc.ebay.com. 3599 IN TXT "v=DMARC1; p=reject; rua=mailto:ebay@rua.agari.com,mailto:dmarc_agg@auth.returnpath.net;
ruf=mailto:ebay@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net;
fo=1; rf=afrf; pct=100"
L’identifiant “p” indique la politique à appliquer en cas d’email problématique. Trois valeurs sont possibles : Approve, Quarantine ou Reject. C’est la troisième option qui est indiquée dans cet exemple. Les champs RUA et RUF (Report URI Aggregate/Forensic) permettent d’indiquer où envoyer les rapports. Les RUA sont des rapports aggrégés, reprenant des informations statistiques périodiques, tandis que les RUF sont envoyés en temps réel en cas de mail problématique.
La figure ci-dessous résume le traitement d’un email avec SPF, DKIM et DMARC :
Lorsqu’un email est rédigé par un utilisateur du domaine, une fois réceptionné par le MSA, ce dernier va en générer la signature DKIM, puis relaye le message vers le destinataire.
A la destination, les tests/filtres génériques sont appliqués. Ensuite, le serveur de destination va vérifier si le serveur mail source est bien autorisé par la politique SPF du domaine d’origine, et que la signature DKIM est bien valide, grâce à la clé publique DKIM du domaine récupérée dans le DNS. Le bilan de ces deux tests donne ensuite lieu à l’application des règles DMARC : soit le mail est approuvé, soit il est mis en quarantaine, soit il est rejeté, et les données de ce mail sont ajoutées aux statistiques destinées au rapport RUA. En cas de rejet, un rapport RUF est éventuellement envoyé. Enfin, si le mail a passé toutes les validations, il est transféré au destinataire.
Vérification de la conformité d’un domaine mail
Différents outils existent permettant de vérifier si un domaine et/ou un serveur MX répond aux exigences pour être considéré comme fiable.
Le site MXToolbox fournit ainsi de nombreux outils de diagnostic, dont plusieurs sont utiles pour valider un service mail :
-
Le test “MX Lookup, qui permet de vérifier qu’il existe bien un record MX. L’outil vérifie également la présence de politique DMARC :
-
L’outil “Test Email Server”, qui établit une connexion SMTP avec le serveur MX et vérifie s’il est bien configuré via l’application de plusieurs tests.
- L’outil SPF Record Lookup, qui permet de vérifier si le record SPF est bien configuré
- L’outil DKIM Lookup, qui permet, sur base d’un sélecteur, de vérifier qu’il existe bien une clé publique associée dans le DNS
- L’outil Blacklist, qui vous permet de vérifier que votre domaine n’est pas repris dans une DNSBL
- L’outil “Email deliverability”, qui vous permet, via l’envoi d’un mail, de vérifier que ce dernier arrive à destination.
D’autres outils intéressants sont également fournis, notamment pour la validation du DNS. N’hésitez pas à explorer l’outil et à l’exploiter au mieux.
Bibliographie
[1] IONOS Digital Guide, S/MIME pour la signature et le chiffrement des messages, février 2023, consulté en avril 2023
[2] OpenPGP, About OpenPGP, nov. 2020, consulté en avril 2023
[3] Wikipedia, Pretty Good Privacy, mars 2023, consulté en avril 2023
[4] Wikipedia, Anti-spam techniques, mars 2023, consulté en avril 2023
[5] Wikipedia, Domain Name System Blocklist, janv 2023, consulté en avril 2023
[6] IONOS Digital Guide, DNS blacklisting, juillet 2021, consulté en avril 2023
[7] Wikipedia, filtrage bayésien du spam, mars 2023, consulté en avril 2023
[8] Apache SpamAssassin, consulté en avril 2023
[9] Wikipedia, SpamAssassin, sep. 2022, consulté en avril 2023
[10] Wikipedia, Forward-confirmed reverse DNS, fev. 2022, consulté en avril 2023
[11] Julian Mehnle, Open SPF, Sender Policy Framework, avril 2010, consulté en avril 2023
[12] Roua K., Hostinger, C’est quoi DKIM? Le guide du débutant (2023), mars 2023, consulté en avril 2023
[13] DMARC.org, DMARC Overview, consulté en avril 2023
[14] IONOS, STARTTLS, consulté en mars 2024
[15] Mailtrap, STARTTLS vs SSL vs TLS, consulté en mars 2024