Afficher/cacher Sommaire
URL: https://linuxfr.org/users/raphj/journaux/sur-l-interet-des-systemes-de-protections-des-courriers-electroniques-dkim-spf-et-dmarc Title: Sur l’intérêt des systèmes de protections des courriers électroniques (DKIM, SPF et DMARC) Authors: raphj Date: 2019-01-06T15:15:50+01:00 License: CC by-sa Tags: dkim, dmarc, spf, spam et email Score: 50
J’héberge mon propre courrier électronique. Le faire correctement n’est pas une chose triviale à faire et on est amené à apprendre l’existence de plusieurs mécanismes. Ce matin, j’ai reçu un courriel de non-livraison étrange de la part de Gmail et c’est l’occasion de parler de ces mécanismes, puis on décortiquera ce courriel étrange.
SPF, DKIM, et DMARC
Ces trois technologies servent à lutter contre le courrier indésirable.
SPF : Sender Policy Framework
SPF prend la forme d’un enregistrement DNS sur un nom de domaine. Cet enregistrement définit la liste des adresses IP autorisées à envoyer du courriel en utilisant ce nom de domaine. On peut être plus ou moins strict.
Voici par exemple mon entrée SPF, anonymisée :
$ dig example.org TXT
[…]
example.org. 600 IN TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -all
[…]
Je donne mon adresse IPv4, mon adresse IPv6, et -all indique que n’importe quel autre expéditeur doit être rejeté, et de façon stricte à cause du tiret « - ».
Si j’avais voulu dire « Si vous recevez un courriel d’une autre adresse, peut-être que celui-ci est illégitime », j’aurais plutôt mis un tilde « ~ ».
Pour plus de détails, voir par exemple [https://fr.wikipedia.org/wiki/Sender_Policy_Framework].
DKIM : DomainKeys Identified Mail
DKIM fonctionne avec un système de clé privée et prend également la forme d’un enregistrement DNS.
$ dig default._domainkey.example.org TXT
[…]
default._domainkey.example.org. 3600 IN TXT "v=DKIM1; k=rsa; s=email; h=sha256; p=LONGUE_CLEF_PUBLIQUE" "QAB"
[…]
Sur le serveur d’envoi, certains entêtes et le contenu du courriel sont signés avec la clé privée puis le serveur destinataire peut vérifier que le contenu et les entêtes n’ont pas été modifiés à l’aide de la clé publique.
Pour plus de détails, voir par exemple [https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail
DMARC : Domain Message Authentication Reporting & Conformance
DMARC prend également la forme d’un enregistrement DNS.
$ dig _dmarc.example.org TXT
[…]
_dmarc.example.org. 3600 IN TXT "v=DMARC1; p=reject;adkim=s; aspf=s; fo=1; rua=mailto:dmark-report@example.org; ruf=mailto:dmark-report@example.org"[…]
DMARC indique aux serveurs destinataires que faire avec les mails (illégitimes) entrant : à quel point les règles DKIM et SPF doivent être respectés, et comment (rejet du message ?). DMARC est aussi un mécanisme de rapport : un rapport est envoyé par les serveurs destinataires implémentant cette fonctionnalité à l’adresse indiquée pour tous les courriels qui concernent le nom de domaine concerné. La manière dont le rapport est envoyé est également spécifié.
Voici un exemple de rapport envoyé par Yahoo (un peu adapté pour faire apparaître du courriel valide) :
Pour : dmarc-report@example.org
Sujet : Report Domain: example.org Submitter: yahoo.fr Report-ID: <1546565007.991476>
Contenu : This is an aggregate report from Oath
Pièce jointe : yahoo.fr!example.org!1546473600!1546559999.xml
<?xml version="1.0"?>
<feedback>
<report_metadata>
<org_name>Yahoo! Inc.</org_name>
<email>postmaster@dmarc.yahoo.com</email>
<report_id>1546565007.991476</report_id>
<date_range>
<begin>1546473600</begin>
<end>1546559999 </end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.org</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>YYY.YYY.YYY.YYY</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>reject</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>domaine-spammeux.fr</domain>
<result>neutral</result>
</dkim>
<spf>
<domain>domaine-spammeux.fr</domain>
<result>softfail</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx</source_ip>
<count>5</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.org</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>example.org</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
On voit qu’un courriel a été rejeté parce qu’il provenait d’une mauvaise adresse IP et avait une signature DKIM invalide. 5 courriels valides ont été acceptés.
Digression
Ces mécanismes sont utiles et heureusement qu’ils sont là. Ils évitent des usurpations d’identités et permettent de bloquer du courrier indésirable. Ils posent des problèmes avec les listes de diffusions et les transferts de courrier. Des gens se penchent sur ces problèmes avec un mécanisme en court de standardisation : ARC.
Décorticage
Revenons sur ce courriel de non-livraison étrange, intitulé « Delivery Status Notification (Delay) » de la part de Gmail. Dans la suite, on va considérer que example.org est mon domaine.
En ouvrant le courriel, on voit :
Delivery incomplete There was a temporary problem delivering your message to xxxx@[HIDDEN].fr. Gmail will retry for 140 more hours. You’ll be notified if the delivery fails permanently. LEARN MORE The response was:
The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720 [XX.YY.ZZ.AA XX.YY.ZZ.AA: 421 No SMTP service here ]
J’ai censuré l’adresse destinataire du courriel original, certainement valide.
On découvre que Gmail a essayé d’envoyer un message à l’adresse IP XX.YY.ZZ.AA, celle qui est derrière l’hôte mail.[HIDDEN].fr, et s’est fait jeté.
Le contenu du message est bien spammesque et un peu obscure. L’adresse d’expédition (nom changé), d’après le champ FROM du mail, est:
From: Jean Bidon <BidonJean@nl.champagne-ardenne.cci.fr>
Regardons le champ SPF :
[…]
$ dig nl.champagne-ardenne.cci.fr TXT
nl.champagne-ardenne.cci.fr. 3501 IN TXT "spf2.0/mfrom mx ip4:83.206.208.128/25 ip4:81.252.92.0/23 ip4:86.64.210.0/23 ip4:195.62.74.0/23 ~all"
nl.champagne-ardenne.cci.fr. 3501 IN TXT "v=spf1 mx ip4:83.206.208.128/25 ip4:81.252.92.0/23 ip4:86.64.210.0/23 ip4:195.62.74.0/23 ~all"
nl.champagne-ardenne.cci.fr. 3501 IN TXT "google-site-verification=ix9iAaNJuQ-0jzi-p8Na6bE0r3S4X9-h1W-gu03Mbj0" ""
[…]
Une résolution de ces adresses IP donne des fournisseurs Orange, SFR et NP6. Gmail n’est pas impliqué.
Regardons l’enregistrement DMARC :
$ dig _dmarc.nl.champagne-ardenne.cci.fr TXT
[…]
_dmarc.nl.champagne-ardenne.cci.fr. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@mailperformance.com"
[…]
p=none: Un mail illégitime ne sera pas bloqué avec le mécanisme DMARC.
L’adresse To est cassée (j’ai changé le nom et un peu le nom de domaine (la partie bidon), au cas où la personne existe réellement, et le nom de domaine d’origine existe bien).
To: "Marie Dupont" <@bidon-habitat.fr>
Bon, pour l’instant, je ne suis pas impliqué alors. Et Gmail non plus, en regardant les enregistrements SPF derrière bidon-habitat.fr.
Mon domaine example.org apparaît dans quelques entêtes :
Received-From-MTA: dns; leypond.smufkat.choossfroost-criftfruch-@example.org
ARC-Authentication-Results: i=1; mx.google.com;
dkim=temperror (no key for signature) header.i=@example.org header.s=trantpiy header.b=rh7rWrS4;
spf=fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) smtp.mailfrom=leypond.smufkat.choossfroost-criftfruch-@example.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nl.champagne-ardenne.cci.fr
Return-Path: <leypond.smufkat.choossfroost-criftfruch-@example.org>
Received: from example.org ([EE.FF.GG.HH])
by mx.google.com with ESMTP id w11si16063308plz.327.2019.01.04.21.22.34
for <xxxx@[HIDDEN].fr>;
Fri, 04 Jan 2019 21:22:36 -0800 (PST)
Received-SPF: fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) client-ip=EE.FF.GG.HH;
Authentication-Results: mx.google.com;
dkim=temperror (no key for signature) header.i=@example.org header.s=trantpiy header.b=rh7rWrS4;
spf=fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) smtp.mailfrom=leypond.smufkat.choossfroost-criftfruch-@example.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nl.champagne-ardenne.cci.fr
OK, on apprend que c’est certainement un spammeur qui a pris mon nom de domaine comme adresse de retour, a utilisé une adresse complètement farfelue et qui a essayé de forger une signature DKIM avec mon nom de domaine. Bien sûr, ça a fait râler Gmail (« Authentication-Results: mx.google.com; dkim=temperror (no key for signature) »).
La vérification SPF a également échoué bien sûr, puisque le courriel vient d’une autre IP que la mienne (et en voyant ça, ça m’a rassuré, j’ai écarté l’hypothèse « mon serveur s’est fait piraté »).
De ce que j’ai compris, le serveur EE.FF.GG.HH (qui s’est certainement fait piraté ou est le serveur d’un spammeur) essaie d’envoyer un mail via Gmail à xxxx@[HIDDEN].fr en se faisant passer pour mon nom de domaine. Tordu. [HIDDEN].fr bloque la tentative de connexion de Gmail. Gmail m’informe que sa tentative de connexion a échoué à l’adresse leypond.smufkat.choossfroost-criftfruch-@example.org à cause de l’entête Return-Path.
C’est original. Ça ressemble à du pourriel horriblement mal géré. Pourquoi le spammeur s’est servi de mon nom de domaine et comment il est tombé dessus ? Mystère complet ! Est-ce une tentative d’envoyer un spam en pervertissant le mécanisme de Return-Path ? S’il faut se fader le déchiffrage des entêtes et décoder du base64, c’est quand même poussé !! Et puis je n’ai rien à faire avec xxxx@[HIDDEN].fr ni avec la CCI de Champagne Ardennes qui n’existe plus…