Dernière partie de cet article. Ici, on termine avec DMARC qui va permettre d’avoir une visibilité sur les flux de messagerie, et qui va indiquer quoi faire si un mail ne correspond pas à la politique de sécurité.

DMARC

“Une politique pour les gourvener toutes…” c’est ainsi que l’on pourrait définir DMARC (Domain-based Message Authentication, Reporting, and Conformance), que l’on pourrait traduire en “Authentification, Rapport et Conformité des Messages basés sur un Domaine”.

Pris individuellement, SPF et DKIM ne sont pas suffisants pour s’assurer que le message provient bien de l’expéditeur.
En effet, un attaquant peut très bien émettre un message conforme à SPF, en usurpant l’identité d’appleseverywhere.com à l’intérieur du message (en-tête From) vu que SPF s’appuie uniquement sur le Return-Path (ou le EHLO, selon les cas).

De la même manière, un attaquant peut acquérir le nom de domaine “apples-everywhere.com”, publier une signature DKIM sur son domaine et envoyer des messages en faisant croire à un expéditeur de chez appleseverywhere.com en manipulant le DisplayName (comme vu au début de cet article) : l’antispam ne se déclenchera pas car le message a une signature DKIM valide.

C’est ici que DMARC prend tout son sens car il vérifie l’alignement des domaines Enveloppe et Message.

DMARC indique aussi au destinataire quoi faire en cas de problème d’alignement : rien, mettre en quarantaine le message ou le rejeter.

Comment fonctionne DMARC ?

A l’instar de SPF et DKIM, DMARC est un enregistrement DNS à publier :

_dmarc    TXT "v=DMARC1; p=quarantine; aspf=r; adkim=s; ruf=mailto:dmarc@domain.com; rua=mailto:dmarc-forensics@domain.com; fo=1"

Comme SPF et DKIM, tout commence par la définition de la version : “v=DMARC1”.
Puis ‘p’ définit la politique à appliquer en cas d’échec d’alignement : none, quarantine ou reject.
‘ruf’ et ‘rua’ définissent respectivement qui recevra les rapports aggrégés et les rapports pour enquête (forensics).
‘aspf’ et ‘adkim’ déterminent la politique d’alignement attendue pour SPF et DKIM : r=relaxed, s=strict.

A réception d’un message par le serveur de messagerie du destinataire, et après avoir effectué toutes les évaluations initiales (SPF, DKIM), le moteur DMARC va vérifier le résultat des tests précédents.

Si tout au moins un des 2 tests est validé, le résultat de DMARC sera positif et le mail passera. Sinon, la politique définie dans l’enregistrement DNS sera appliquée (Quarantaine ou Rejet).

Mais ce n’est pas tout, DMARC va vérifier que le domaine indiqué dans le “MAIL FROM” soit le même que le domaine indiqué dans le message (en-tête From).
En mode Relaxed (par défaut), les domaines peuvent être parents (ex: news.mondomaine.com et mondomaine.com). En mode Strict, les domaines doivent être identiques.

Enfin, les serveurs de messagerie compatibles DMARC conservent le résultat des évaluations puis envoient un rapport (en général quotidien) à l’expéditeur. Dans l’exemple ci-dessus, c’est l’adresse ‘dmarc@domain.com’ qui recevra un rapport des messages reçus pour votre domaine.

Mais vu que DMARC laisse passer un message qui vérifie SPF ou DKIM, en quoi aide t-il contre les usurpations

Références : https://datatracker.ietf.org/doc/html/rfc6376

Si SPF, DKIM et DMARC protègent le destinataire, pourquoi m’embarrasser de ça?

On vient de voir que ces mécanismes ne protègent pas l’expéditeur mais le destinaire du message.

En réalité, l’expéditeur est protégé mais indirectement.

En effet, si le destinataire est le premier bénéficiaire de SPF, DKIM et DMARC en vérifiant la légitimité du messsage, l’expéditeur est protégé contre les tentatives d’usurpation d’identité.

Imaginons que notre société, “Apples EveryWhere”, dispose du nom de domaine “appleseverywhere.com”.
En protégeant appleseverwhere.com avec SPF, seuls les serveurs de messagerie identifiés par “Apples EveryWhere” seront reconnus comme légitimes pour délivrer du courrier en provenance de “appleseverywhere.com”.

De ce fait, lorsqu’un destinataire se protège avec SPF, il empêche par la même occasion les usurpations d’identité “d’Apples EveryWhere” – la société est donc indirectement protégée et verra donc sa réputation protégée.

Enfin, il faut savoir que les plus gros fournisseurs de messagerie (Google, Microsoft, Yahoo, …) renforcent la protection de leurs infrastuctures en déployant ces 3 protections.
Si vous souhaitez que vos emails arrivent convenablement dans les boîtes mail de vos destinataires hébergés chez eux, il est nécessaire de “montrer patte blanche” et de vous conformer à la norme!

Vous avez encore des problèmes d’envoi de vos emails ?

Si malgré toute cette lecture vous avez encore des problèmes d’envoi de vos emails, il est peut-être nécessaire de faire appel à un expert.
Je peux vous aider par le biais de ma société de consulting. N’hésitez pas à prendre contact !

Dans la Partie 3, on a vu comment SPF permettait de contrôler les serveurs qui écrivent des emails en notre nom. Maintenant, on va montrer comment se prémunir d’une manipulation de message à notre insu avec DKIM.

DKIM

DKIM est l’acronyme de “DomainKeys Identified Mail” que l’on pourrait traduire de manière maladroite par “Message identifié par des clés de Domaine”.

Cet algorithme permet de vérifier un message en contrôlant :

• Que le message n’a pas été altéré pendant le transport ;
• Que le message provient bien du domaine expéditeur.

Comment fonctionne DKIM ?

DKIM s’appuie sur le chiffrement pour pouvoir authentifier le message.

Pour cela, l’expéditeur génère une paire de clés (une clé publique, une clé privée) et publie la clé publique dans un enregistrement DNS “DKIM” :

selector1._domainkey    TXT "v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZzGCHr2p0l0U1CwaTbMkGfboCvEycCvUtBZshMrJ4uO831ehNso0GQzc6z0P9F6EZSNjThVQdoZZflawVfgL1tv2kpjawVXYjVGtOvgQjNlxy6kwR2sTLPSEYHeyhzOgyxkQexfe12zRpOsK0mybE82optqQkZVgi6OJtDIY9GwIDAQAB;"

Dans l’enregistrement, on trouve en premier lieu “v=DKIM1” indiquant la version 1 de DKIM.
Puis, ‘h’ et ‘k’ qui vont définir l’algorithme de hachage et de chiffrement qui sont utilisés par l’expéditeur.
Ensuite dans ‘p’, la clé publique qui servira aux destinataires pour déchiffrer les signatures émises par l’expéditeur. La clé est en Base64 pour être compatible avec les enregistrements DNS.

Ici, nous avons un sélecteur nommé “selector1” : en effet, le domaine peut avoir autant de clés DKIM que nécessaires. Ces dernières sont différenciées par leur “selector”.

Lorsque l’émetteur écrit à son destinataire, le serveur émetteur calcule le hash du message, le signe avec sa clé privée et le transmet au destinataire qui vérifiera la conformité à réception à l’aide de la clé publique.

Comment est déterminé le résultat du contrôle par DKIM

Sans entrer dans les détails plus complexes de l’ordre de signature des différents éléments du message (header, body), lorsqu’un message est émis par l’expéditeur :

1. Le composant DKIM de son serveur de messagerie calcule le hash du message (Body) ;
2. Il calcule le hash de plusieurs champs d’en-tête ;
3. Il signe les hash avec la clé privée ;
4. Il insère ensuite un en-tête contenant :

• Le nom des en-têtes utilisés pour le contrôle ;
• La taille prise en compte pour le calcul du hash du body ;
• Les signatures ;

D’autres éléments sont ajoutés comme le sélecteur et le domaine utilisé pour la signature.

A réception du message, le serveur de messagerie du destinataire :

1. Calcule à son tour le hash des en-têtes ;
2. Calcule le hash du body ;
3. Déchiffre les hash à l’aide de la clé publique (récupérée dans l’enregistrement DNS DKIM) ;
4. Compare les hash déchiffrés à ceux qu’il a calculés lui-même.

Si les hash concordent, cela signifie que le message provient bien du domaine expéditeur, et qu’il n’a pas été altéré ni manipulé pendant le transport.

L’IETF impose que les en-têtes à signer incluent obligatoirement le champs “From”. Ils recommandent d’exclure “Return-Path” et tout autre en-tête suceptible d’être retiré ou modifié en cours de transport.

Dans la dernière partie, nous allons étudier DMARC, où comment en finir avec les problèmes !

Dans la Partie 1, nous avons commencé à parler des flux de messagerie. Ici, nous allons nous attarder sur les en-têtes que composent un message.

En-têtes de messages

Comme nous avons pu commencer à le voir précédemment, l’email contient de nombreux en-têtes qui seront utilisés ensuite pour déterminer l’expéditeur et évaluer la légitimité du message :

• From ;
• MAIL FROM / Return-Path ;

MAIL FROM / Return-Path

C’est en-tête un peu spécial car il n’est pas généré par le client de messagerie, ni le serveur de messagerie de l’expéditeur, mais par le serveur du destinataire en réponse à la commande “MAIL FROM”.
Il correspond à l’adresse email à laquelle devront être envoyés les NDR (Non-Delivery Reports – Rapport envoyé à l’expéditeur en cas d’échec de remise du message).

Lors de la transaction SMTP, le serveur expéditeur s’identifie avec la commande “MAIL FROM” suivie de l’adresse de l’utilisateur pour la transmission du NDR, le “Reverse Path”:

EHLO PA5P264CU001.outbound.protection.outlook.com
MAIL FROM:<me@sylvaincoudeville.fr>
DATA
From: Sylvain COUDEVILLE <me@sylvaincoudeville.fr>
To: sylvaincoudeville@hotmail.com
Subject : essai 1101
Blah
.

A la réception de cette commande, le serveur de messagerie de destination ajoute l’en-tête “Return-Path”:

Return-Path: me@sylvaincoudeville.fr

En général, l’adresse de retour est la même que l’adresse de l’expéditeur, mais le serveur de l’expéditeur peut être configuré différemment et envoyer par exemple tous les rapports à l’adresse d’un administrateur pour un traitement centralisé.

From

Cet en-tête correspond à l’adresse email de l’expéditeur.
C’est l’adresse qui sera vue par l’utilisateur.

Cet en-tête est un peu spécial car il peut aussi contenir un DisplayName (nom affiché), qui se substitue dans le client de messagerie de l’utilisateur :

From: "Sylvain COUDEVILLE" <me@sylvaincoudeville.fr>

C’est de cette manière que certains pirates usurpent l’identité d’un dirigeant, en trompant l’utilisateur.
Un exemple ci-dessous, où l’attaquant fait croire qu’il écrit de la part du président :

From: "Emmanuel MACRON <macron@elysee.fr>" <nobody@gmail.com>

Le principe est détourner le DisplayName pour lui faire afficher quelque chose qui n’est pas vrai, puisque l’adresse réelle de l’expéditeur est “nobody@gmail.com” :

Reply-To

Cet en-tête correspond à l’adresse email à laquelle doivent être envoyées les réponses (à ne pas confondre avec Return-Path qui ne concerne que les NDR).

Ce champ est généralement utilisé par des systèmes automatisés ou des listes de diffusion, pour diriger les réponses vers une autre boîte ou un autre système.

Références : https://datatracker.ietf.org/doc/html/rfc7208

Dans la Partie 3, nous parlerons de SPF : un mécanisme permettant de s’assurer que le serveur ayant émit le message était bien autoriser à le faire…

Avant propos

Les flux de messagerie électronique (email) ont considérablement augmenté ces 20 dernières années.
La plupart des études s’entendent sur le fait que près de 50% du flux de message est du Spam.

Le “Spam” est un terme générique qui désigne un message indésirable. Ces messages peuvent être de plusieurs nature :

• Message publicitaire ;
• Arnaque ;
• Phishing ;
• etc.

Alors que les messages publicitaires peuvent être considérés comme des messages plus ou moins sollicités (inscription par l’utilisateur de manière forcée ou non), les autres sont des tentatives d’escroquerie dans le but de soutirer de l’argent ou des données personnelles.

Pour atteindre leur but, les pirates informatique usent de méthodes plus ou moins efficaces pour tromper les protection anti-spam, et une des méthodes les plus utilisées encore ce jour est l’usurpation d’identité.

C’est pour cela que des les méthodes de prévention et de protection SPF, DKIM et DMARC ont vu le jour.

Depuis, il peut sembler difficile de faire fonctionner un serveur de messagerie. Les messages n’arrivent pas chez certains destinataires (codes de rejet 5XX), parfois ils sont remis automatiquement en courrier indésirable…

Après la lecture de cet article, les flux de messages et les méthodes de protection n’auront plus aucun secret pour vous!

La base de toute communication email

Flux

Avant d’entrer dans le détail de toutes ces protections, il est nécessaire d’intégrer et comprendre une communication email.

Un message part de l’expéditeur. Il contient un expéditeur et un destinataire (adresses emails respectives des 2 parties) que l’on retrouvera dans l’en-tête du message:

From: Sylvain COUDEVILLE <me@sylvaincoudeville.fr>
To: Jean DUPOND <jeandupond@hotmail.com>

A partir de ce moment, nous comprenons que le dialogue s’effectuera entre le domaine sylvaincoudeville.fr et le domaine hotmail.com.

Lorsque le message arrive sur le serveur de messagerie du destinataire et s’il a activé des protections, ces dernières évaluent la qualité du message.
C’est à ce moment précis qu’interviennent SPF, DKIM et DMARC.

Dans la partie 2, nous parlerons des différents en-têtes des messages.