Vidéo : DMARC – Vue d'ensemble technique
Nous avons préparé une courte vue d'ensemble technique de DMARC :
Cette vidéo fait partie d'une série de vidéos plus complète sur tout ce qui concerne DMARC.
Voici la transcription :
Cette courte vidéo est une vue d'ensemble technique de DMARC – Domain-based Message Authentication, Reporting, and Conformance.
DMARC tente de créer un lien entre le contenu d'un e-mail et un domaine en utilisant soit SPF, soit DKIM. Pour les spectateurs curieux, SPF et DKIM sont traités dans des vidéos distinctes.
Le contenu d'e-mail qui intéresse DMARC est le domaine trouvé dans l'en-tête From:. L'en-tête From: est pratiquement la seule information qui indique qui ou d'où provient un e-mail et qui est requise dans ce qui est considéré comme un « e-mail bien formé ». Pour cette raison, DMARC se base sur le domaine trouvé dans l'en-tête From:.
DMARC ne se base sur aucun autre en-tête, y compris l'en-tête Sender:. Il s'avère que l'autorisation de multiples clés de politique entraîne beaucoup de confusion et peut même nuire à l'utilité de DMARC lui-même, c'est pourquoi DMARC se base uniquement sur le domaine trouvé dans l'en-tête From:.
SPF et DKIM sont deux technologies qui produisent des identifiants stables au niveau du domaine. SPF et DKIM sont des spécifications techniques librement disponibles qui ont été largement implémentées par de nombreux fournisseurs de messagerie. Même si elles fonctionnent de différentes manières, DMARC ne se soucie que des résultats qu'elles produisent, et si ces résultats ont un rapport avec le domaine trouvé dans l'en-tête From:. Les résultats produits par SPF et DKIM sont appelés « Identifiants Authentifiés » dans le monde de DMARC.
Un concept clé de DMARC est l'« Alignement des Identifiants ». C'est simplement une façon élaborée de dire que les résultats de SPF et DKIM doivent être liés au domaine DMARC pour être utiles. La raison principale en est que les récepteurs ont besoin d'un moyen simple de comprendre si les résultats de SPF et DKIM sont pertinents pour le domaine sur lequel DMARC se base.
Au cours des prochaines diapositives de cette vidéo, nous examinerons différentes combinaisons d'identifiants authentifiés dans le but d'illustrer l'importance de l'alignement des identifiants du point de vue d'un récepteur d'e-mails.
Dans ce premier exemple, un récepteur d'e-mails a reçu un courriel où le domaine DMARC (qui est le domaine trouvé dans l'en-tête From:) est « bank.com ». De plus, la vérification SPF a donné un domaine de « bank.com ». Il n'y avait pas de signature DKIM sur ce courriel, donc notre ligne est marquée « none ». Le récepteur d'e-mails recherche tout signal positif indiquant que le courriel peut être rattaché au domaine « bank.com », et le récepteur d'e-mails ne se soucie pas de savoir si ce signal provient de SPF ou de DKIM — tant que le signal est présent. Dans cet exemple, l'identifiant authentifié provenant de SPF était « bank.com », et cela correspond exactement au domaine DMARC, de sorte que le courriel est conforme à DMARC.
Dans cet exemple suivant, tout est très similaire, sauf que l'identifiant authentifié fourni par SPF est un sous-domaine de bank.com — mail.bank.com. Pour un être humain, les deux domaines sont évidemment liés. Cependant, il s'avère qu'il n'existe pas de méthode standard sur Internet pour déterminer si bank.com est un domaine de premier niveau comme .com ou .org, ou s'il s'agit d'un domaine de second niveau. Il n'y a pas de moyen standard de le déterminer. Un autre exemple est bank.co.uk. Il n'existe pas de moyen standard pour indiquer aux machines que « co.uk » est le domaine de premier niveau. Dans le monde de DMARC, ce qui est un domaine de second niveau est appelé le Domaine Organisationnel. En utilisant certaines ressources d'Internet — spécifiquement la liste des suffixes publics maintenue par la Fondation Mozilla — un récepteur d'e-mails peut déterminer que bank.com est le Domaine Organisationnel, et que mail.bank.com est un sous-domaine qui partage le même Domaine Organisationnel que bank.com. Dans ce cas, le courriel est conforme à DMARC.
Ce 3ème exemple montre quelque chose d'intéressant. Au lieu que SPF fournisse un identifiant authentifié de bank.com ou un sous-domaine de bank.com, l'identifiant authentifié est banknewsletter.com. Pour autant que nous sachions, banknewsletter.com est un domaine réel, détenu et exploité par la même entité que bank.com. OU… banknewsletter.com est détenu et exploité par des criminels qui veulent tromper les gens en leur faisant croire qu'ils sont légitimes. Il n'existe tout simplement pas de moyen fiable de maintenir et de communiquer de telles associations entre domaines — que ce soit par les expéditeurs eux-mêmes créant des bases de données d'associations ou par les récepteurs gérant les leurs — ces deux tâches seraient sujettes à des inexactitudes et saperaient fondamentalement l'utilité de DMARC. Et donc, ce courriel n'est PAS conforme à DMARC et serait affecté par une politique DMARC publiée.
Pour poursuivre avec le 4ème exemple, le courriel est le même, sauf que nous voyons maintenant une signature DKIM pour la première fois. Dans cet exemple, DKIM a fourni un identifiant authentifié de bank.com, ce qui rend l'exemple conforme à DMARC. C'est-à-dire que le récepteur d'e-mails examine l'identifiant authentifié provenant de SPF et constate que banknewsletter.com n'a rien à voir avec bank.com et l'ignore simplement. Étant donné que le récepteur recherche tout signal positif indiquant que le message provient réellement de bank.com et que DKIM fournit un tel signal, le courriel passe la vérification DMARC.
Ce 5ème exemple montre un courriel entièrement conforme à DMARC. SPF et DKIM ont tous deux fourni des identifiants authentifiés de bank.com. Le récepteur ne se soucie que de trouver un signal positif, donc avoir deux signaux positifs est doublement bon, mais ne signifie rien de plus qu'un « signal positif ». La raison d'envoyer des courriels où SPF et DKIM donnent tous deux les bons résultats est que la disponibilité des deux technologies permet au courriel de rester conforme à DMARC même si l'une ou l'autre — pour quelque raison que ce soit — est indisponible ou échoue.
Ce 6ème exemple montre la même chose, à la différence que « news.bank.com » est l'identifiant authentifié pour SPF et DKIM. Il est assez courant pour les grandes organisations de déléguer un sous-domaine à un fournisseur de services de messagerie afin que ce dernier puisse envoyer des courriels au nom de l'organisation. Dans cet exemple, les propriétaires de bank.com pourraient avoir délégué le sous-domaine « news » à leur fournisseur marketing afin que ce dernier puisse envoyer des courriels conformes à DMARC en utilisant bank.com.
Cet exemple artificiel montre que n'importe qui peut enregistrer des domaines et mettre en place SPF et DKIM. Ne serait-il pas agréable que les acteurs malveillants utilisent des domaines aussi évidents ? Cependant, le simple fait que SPF et DKIM réussissent et fournissent un identifiant authentifié ne signifie pas que le courriel est bon ou désiré.
Le dernier exemple ici montre que SPF a fourni un identifiant authentifié de « bark.com »… comme le son que fait un chien. Il s'agit d'une attaque bien connue que certains fraudeurs utilisent pour tromper les humains qui inspectent manuellement les courriels afin de déterminer leur légitimité. Un coup d'œil rapide pourrait tromper l'œil et faire croire à quelqu'un que « bark » est en fait « bank ». Pire encore, il est possible d'utiliser des astuces d'encodage de caractères pour que les glyphes rendus ressemblent exactement au domaine visé. Les machines ne sont pas dupées par ce genre de supercherie, c'est pourquoi les machines devraient effectuer les vérifications d'alignement des identifiants, et non les humains.
Avant d'aborder l'apparence et les fonctionnalités des enregistrements DMARC, nous aborderons brièvement la manière dont les enregistrements DMARC sont découverts.
Lorsqu'un récepteur d'e-mails traite un courriel dans le contexte de DMARC, le récepteur extraira le domaine trouvé dans l'en-tête From:. Ce domaine constitue la base de la recherche par le récepteur de tout enregistrement DMARC correspondant. Le récepteur ajoutera un préfixe _dmarc au domaine et interrogera le DNS pour un enregistrement TXT.
Dans l'exemple présenté ici, le domaine extrait est EUROPE.ENG.EXAMPLE.ORG. Le récepteur ajouterait _dmarc à ce domaine et interrogerait le DNS pour tenter de trouver un enregistrement TXT. Mais que se passe-t-il si la requête ne donne rien ou un enregistrement TXT dont le contenu n'a rien à voir avec DMARC ? Le récepteur extrairait alors le Domaine Organisationnel du domaine… dans ce cas EXAMPLE.ORG, et essaierait à nouveau de trouver un enregistrement DMARC en ajoutant _dmarc devant le domaine et en interrogeant un enregistrement TXT.
De cette manière, la découverte des enregistrements DMARC est limitée à seulement 2 requêtes DNS. Il y a aussi des ramifications astucieuses à cela. Vous pouvez publier un seul enregistrement DMARC au niveau du Domaine Organisationnel et le faire couvrir tous les sous-domaines. Peu importe si un spammeur invente ses propres sous-domaines, vous pouvez toujours publier un enregistrement DMARC qui les couvre sans avoir à publier des enregistrements DMARC explicites pour tous les sous-domaines imaginables. L'autre aspect astucieux est que vous pouvez publier des enregistrements DMARC pour tous vos sous-domaines réels, et ces enregistrements DMARC remplaceront ce qui est publié au niveau du Domaine Organisationnel.
Bien, passons maintenant à l'apparence et aux fonctionnalités des enregistrements DMARC.
Les enregistrements DMARC sont de simples listes de paires balise/valeur. Dans cet exemple, le domaine qui a publié cet enregistrement DMARC… nous pouvons dire que c'est un enregistrement DMARC car il commence par « v=DMARC1; »… publie une politique « none » et demande que tous les rapports agrégés basés sur XML soient envoyés à [email protected] pour traitement. DMARC a été conçu pour permettre aux domaines de collecter des informations sans impacter les courriels… et c'est ainsi que cela se fait — en publiant une politique p=none.
En ce qui concerne les fonctionnalités des enregistrements DMARC, les options sont assez simples. Tous les enregistrements DMARC doivent commencer par une balise de version de protocole. Après cela, la politique peut être configurée, vous pouvez configurer une politique qui sera appliquée à tous les sous-domaines…. par exemple, si vous savez que votre domaine n'utilise jamais de sous-domaine, vous pouvez publier une politique sp=reject immédiatement tout en ne collectant des données sur votre Domaine Organisationnel qu'avec p=none. La balise pct est comme un curseur qui va de 0 à 100 afin que toute politique publiée puisse être déployée progressivement… si vous définissez pct=1, alors seulement 1 courriel sur 100 qui aurait autrement été affecté par une politique DMARC sera impacté.
Vous pouvez également configurer si les identifiants authentifiés fournis par SPF et DKIM doivent correspondre exactement au domaine DMARC. Le mode par défaut « relaxed » est préféré dans presque tous les cas, mais en « mode strict », vous pouvez interdire l'alignement des identifiants basé sur les sous-domaines, peut-être si vous êtes dans un environnement où vous n'avez pas le contrôle sur les courriels envoyés via des sous-domaines délégués.
Les deux balises suivantes, rua et ruf, sont utilisées pour indiquer où envoyer les rapports pour le domaine. Étant donné que les rapports sont différents, les gens envoient les rapports à différentes adresses e-mail pour la collecte et l'analyse.
Les dernières balises concernent la configuration des formats de rapport, des intervalles et du moment d'envoyer des copies expurgées des courriels individuels qui échouent à DMARC. Les deux premières balises n'ont qu'une seule valeur et sont donc un peu inutiles, et la dernière option semble désactiver la génération de rapports par certains fournisseurs de rapports en raison de bugs logiciels, il est donc préférable de les omettre si vous souhaitez les collecter.
Bien, nous terminerons cet aperçu avec les différentes politiques que DMARC autorise et un bref examen des 2 types de rapports de feedback que DMARC fournit.
Les options de politique de DMARC sont très simples. Vous pouvez publier une politique « none » qui signifie simplement « veuillez m'envoyer des rapports sans agir sur les courriels qui échouent à la vérification DMARC ». Vous pouvez publier une politique de « quarantine » qui ordonne aux récepteurs de placer dans le dossier de spam tout courriel qui échoue à la vérification DMARC. Si un dossier de spam n'existe pas, le récepteur pourrait faire tout son possible pour traiter le message avec un degré de suspicion plus élevé, comme augmenter l'agressivité de l'analyse anti-spam.
La dernière politique qui peut être appliquée est la politique « reject », qui ordonne aux récepteurs de bloquer — ou de refuser d'accepter — les courriels qui échouent à la vérification DMARC. À l'écran, vous verrez un peu plus sur la balise pct, et comment, si vous l'utilisez avec une politique de rejet en place, alors tout pourcentage de courriels qui ne sont pas rejetés en raison de la balise de pourcentage sera plutôt mis en quarantaine.
Dernière chose, les 2 formes de rapports de feedback que DMARC peut fournir sont très différentes. Les rapports agrégés basés sur XML sont générés sur un cycle de 24 heures et incluent des statistiques complètes sur la façon dont un récepteur d'e-mails voit votre domaine être utilisé — y compris tous les courriels qui ont entièrement passé DMARC. Le deuxième type de feedback consiste en des copies expurgées de courriels individuels qui ont échoué à SPF, DKIM ou aux deux. Ces rapports ne sont pas toujours disponibles en raison de préoccupations de confidentialité, de volume, ou de l'avis qu'ils ne sont pas nécessaires pour déployer DMARC avec précision.
dmarcian traite les deux types de feedback pour faciliter le déploiement de DMARC. Les questions concernant DMARC ou le service dmarcian recevront une réponse avec plaisir.
Pour commencer avec DMARC, visitez dmarcian.com.
Des questions ? Contactez [email protected]. Merci de votre attention !
