Particularités des récepteurs DMARC
Tomki Camp, directeur des services chez dmarcian, travaille avec les technologies d'authentification des e-mails depuis plus de deux décennies et soutient les efforts de mise en œuvre de DMARC depuis 2012. Dans cet article, il aborde les incohérences dans la manière dont certains fournisseurs donnent des retours sur DMARC, et dans certains cas, n'en fournissent pas du tout.
Les données DMARC fournies par les récepteurs sont extrêmement utiles pour aider les propriétaires de domaines à comprendre et à résoudre les problèmes d'authentification de domaine. Cependant, il faut beaucoup de travail et des connaissances de niveau expert pour interpréter les variations des données « standardisées » envoyées par les fournisseurs.
Aucun fournisseur de services similaires n'est identique, et chaque environnement d'hébergement de messagerie ou web a ses propres particularités, avec des avantages et des inconvénients connus de ses abonnés. Cependant, les outils fournis par ces entreprises ne sont généralement pas régis par des protocoles définissant leur comportement et leur présentation, ce qui entraîne d'énormes différences d'un fournisseur à l'autre.
En revanche, l'utilisation prévue de DMARC est assez bien définie, du point de vue de « comment vérifier si un message donné passe le protocole d'authentification », à « que faire d'un message qui échoue à l'authentification DMARC », et « comment les communications concernant les statistiques d'authentification DMARC doivent être présentées à l'adresse spécifiée par le propriétaire du domaine ».
Malheureusement, il existe encore un certain nombre de détails d'implémentation que certains fournisseurs négligent ou gèrent mal. Cet article n'est pas un examen exhaustif de tous les problèmes connus, et la plupart des utilisateurs finaux (propriétaires de domaines) reconnaissent rarement la plupart de ces problèmes. Cependant, ils deviennent apparents lorsqu'une entreprise comme dmarcian reçoit des centaines de milliers de fichiers de données XML individuels chaque jour, représentant des milliards de messages électroniques pour des dizaines de milliers de clients. À cette échelle, les tendances problématiques deviennent évidentes et même les plaintes de clients à faible volume ont révélé des préoccupations. Cet article vise à illustrer certains des problèmes que dmarcian rencontre dans sa démarche pour aider les utilisateurs à mieux protéger leurs domaines.
Le seul problème concernant les données fournies par cet ESP n'est en fait pas lié au format ou à la qualité des données qu'il envoie ; le problème est qu'il ne respecte pas la restriction de la spécification DMARC concernant les destinataires auxquels les données ne doivent pas être envoyées. Par exemple, si je publie un enregistrement DMARC pour tomki.com spécifiant que les rapports doivent être envoyés à [email protected], nous pouvons convenir que c'est une mauvaise chose et inapproprié.
Les auteurs de la spécification ont pris ce problème en compte et ont exigé que les fournisseurs de données DMARC (toute entité qui envoie des données RUA et/ou RUF) s'assurent d'une autorisation positive pour de tels rapports. Un enregistrement DMARC spécifiant que les rapports doivent être envoyés à une adresse au sein de son propre domaine est une évidence – aucune vérification supplémentaire n'est nécessaire. Si un enregistrement DMARC spécifie un destinataire au sein d'un domaine *extérieur* à ce domaine, alors il est requis que le générateur de rapports DMARC vérifie l'existence d'un enregistrement spécial au niveau du domaine de destination – cet enregistrement doit exister pour fournir l'autorisation positive.
Le problème avec le fait que Google n'effectue pas cette vérification est qu'il existe un potentiel pour que cela devienne un outil dans une attaque par déni de service, étant donné qu'il est possible d'inonder une adresse e-mail de rapports.
Cisco IronPort ESA
Il s'agit d'un système bien connu qui présente plusieurs problèmes graves avec ses rapports DMARC, tant du côté de l'environnement de solution hébergée (IPHMX) que des installations matérielles chez les clients.
Un problème est que les domaines et sous-domaines ne sont pas correctement agrégés pour la génération de rapports. L'enregistrement DMARC d'un domaine est hérité par tout sous-domaine qui n'a pas son propre enregistrement DMARC explicite à son niveau. Cela signifie que les données XML détaillant les transactions e-mail sur tous les sous-domaines (qui n'ont pas leur propre enregistrement DMARC) devraient figurer dans le même rapport que pour le domaine de premier niveau. Malheureusement, le Cisco ESA ne le fait pas, ce qui entraîne la génération de nombreux (potentiellement des milliers) fichiers XML supplémentaires chaque jour.
Un autre problème, plus complexe, concerne la synchronisation de la génération des données DMARC et l'heure des données dans les rapports de l'appliance de sécurité e-mail Cisco. La spécification DMARC stipule que les données quotidiennes générées et envoyées aux adresses d'enregistrement doivent respecter une fenêtre de 24 heures basée sur un fuseau horaire UTC de minuit à minuit. En d'autres termes, de 00:00 à 23:59:59 du même jour en temps UTC. Cela permet au propriétaire du domaine de bien coordonner les rapports de trafic e-mail à l'échelle mondiale. Le problème avec Cisco ESA est qu'il n'y a aucune capacité à aligner les rapports DMARC sur l'heure UTC ; toutes les données de rapport sont dans des fuseaux horaires pertinents uniquement pour l'heure définie sur cette instance ESA particulière.
Pour expliquer un peu plus en détail avec un exemple : Une campagne frauduleuse abuse d'un domaine de messagerie d'une entreprise internationale en envoyant 500 messages à des environnements aux États-Unis, 200 à des environnements dans l'UE et 300 autres en Inde. Supposons un scénario où ces messages ont tous été reçus dans des environnements hébergés par Cisco ESA utilisant des paramètres d'heure locale, ce qui est normal.
- Les 200 messages reçus dans l'UE seront rapportés le plus fidèlement à l'heure UTC.
- Les 500 messages reçus aux États-Unis seront rapportés sur des heures allant de -5 à -8 UTC.
- Les 300 messages reçus en Inde seront rapportés à l'heure +5:30 UTC.
Le résultat est que, même si la campagne d'e-mails frauduleux a duré moins de 10 minutes, selon les rapports reçus des rapporteurs DMARC qui ne respectent pas l'exigence de fuseau horaire UTC, il semble que la campagne se soit étendue sur environ 24 heures, sur deux jours distincts. L'administrateur du domaine abusé aurait du mal à dire si la campagne frauduleuse a eu lieu un jour ou l'autre, ou si elle s'est réellement étendue sur toute la période, en se basant sur les rapports reçus pour le domaine.
Récepteurs envoyant des données incorrectes
Plus souvent qu'on ne le pense, nous voyons des rapports DMARC provenant d'environnements où la représentation des données est factuellement ou logiquement incorrecte. Par exemple, lorsqu'un résultat SPF est « fail » mais que le résultat de la politique DMARC-SPF est « pass ». Par définition, la seule façon pour qu'un résultat de politique DMARC soit « pass » est que le résultat SPF soit « pass ».
Il existe une variété de problèmes de ce type, allant de l'erreur logique montrée ci-dessus, à des sections de données requises vides ou manquantes. Dans le but de pouvoir guider les utilisateurs dans leurs efforts pour renforcer l'authentification, dmarcian travaille avec ces rapporteurs pour corriger leur implémentation. Dans certains cas où nous ne parvenons pas à communiquer ou qu'un problème de rapport ne peut être résolu, les importations de données d'une source sont entièrement interrompues.
Récepteurs qui ne génèrent pas de données
Une dernière catégorie de défaillances des récepteurs ne concerne pas les problèmes de données ou de génération de données, mais plutôt leur absence.
DMARC est un standard public (RFC 7489) dont des millions de propriétaires de domaines ont littéralement tiré parti pour améliorer l'authentification du trafic e-mail de leurs domaines. Dans de nombreux cas, ces mêmes propriétaires de domaines ont pris des mesures dans DMARC pour publier des restrictions de politique contre l'utilisation frauduleuse de leurs domaines. Ces efforts apportent d'énormes avantages à tout environnement recevant des e-mails prétendant provenir de ce domaine ; un historique viable de l'authentification des e-mails et, mieux encore, une politique d'application publiée permet à un récepteur de séparer beaucoup plus fiablement le trafic e-mail légitime du trafic frauduleux.
Le travail que les propriétaires de domaines consacrent à la mise en place et à la correction des standards d'authentification e-mail (SPF, DKIM, DMARC) appliqués à leur trafic e-mail dépend énormément du feedback DMARC des environnements récepteurs. Mises à part les incertitudes connues, le feedback de Google, Yahoo, de tous les environnements Cisco ESA, Rackspace, Comcast, Mail.ru et d'autres est inestimable dans ces efforts. Plus les récepteurs participent, meilleur devient l'e-mail pour tout le monde. Cependant, certains profitent de ces standards d'authentification et fournissent des services d'authentification pour leurs propres environnements sans contribuer à l'écosystème.
Les exemples les plus importants de ce comportement non coopératif sont Proofpoint, MIMECast et Symantec.cloud. Chacun de ces environnements fournit des services d'authentification DMARC pour les messages entrants, mais n'envoie ensuite pas de rapports DMARC aux propriétaires de domaines. Sans rapports DMARC concernant l'authentification DMARC censée être appliquée dans ces environnements, un propriétaire de domaine ne peut même pas être certain qu'il effectue correctement les actions de vérification ou d'application.
Si vous êtes client de l'un de ces services, veuillez les contacter pour leur demander de fournir des rapports DMARC pour les domaines qui les sollicitent.
dmarcian s'efforce de rendre le courrier électronique plus sûr en développant la connaissance et la prise de conscience de DMARC. Si vous avez besoin d'aide pour votre projet DMARC, vous pouvez vous inscrire pour un essai gratuit ici.
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
