Cet article fait suite à notre discussion sur le dossier, la politique et le rapport de la DMARC. Nous avons pensé qu’il serait utile de mener une discussion sur les lacunes de DMARC.
DMARC : Dépendant du FPS et du DKIM
Le DMARC aide incontestablement lorsqu’il s’agit de traiter les messages d’hameçonnage falsifiés, mais il n’est pas sans défauts. Sa dépendance au FPS et au DKIM apporte certains des vieux problèmes du FPS et du DKIM.
SPF exige que l’adresse IP du serveur d’envoi figure dans la liste des expéditeurs autorisés dans le domaine « enveloppe de ». Par conséquent, les messages relayés par les serveurs proxy échouent à la validation SPF. De même, le transfert de courriels sur serveur présente des problèmes similaires lorsque le transfert de messages ordinaires a lieu.
Un autre cas à considérer est celui des messages de retour. Les messages de retour ont généralement des en-têtes vides « enveloppe de », et SPF suggère d’utiliser l’identité HELO/EHLO dans ces cas. Cela est rarement bien mis en œuvre par les validateurs SPF, et l’identité n’est pas correctement spécifiée par les MTA. Au fur et à mesure que les entreprises se développent, leurs enregistrements TXT SPF doivent être conservés, car différents services peuvent envoyer des courriels au nom d’autres ministères. La limite de 10 recherches DNS dans SPF devrait être respectée, mais ce n’est souvent pas le cas. Ces types d’erreurs peuvent entraîner des défaillances DMARC par des MTA plus stricts qui imposent de telles limites.
DMARC et DKIM
DMARC tient compte de ces scénarios de défaillance du FPS, en exigeant que DKIM soit également configuré. Une signature DKIM peut être validée tout au long de la durée de vie du message lorsqu’il saute d’un serveur à l’autre. Cependant, DKIM est notoirement fragile, car il exige que les MTA ne modifient pas les en-têtes et le corps des messages utilisés pour créer les signatures DKIM. Tout récemment, j’ai rencontré un antivirus pare-feu qui modifiait le message cassant DKIM. Les MTA qui ajoutent des pieds de page ou modifient des liens dans le message sont susceptibles de briser DKIM si les messages ne sont relayés que par leur intermédiaire.
Enfin, les listes de diffusion et DMARC ne s’entendent pas. Les listes de diffusion modifient généralement les en-têtes comme les lignes d’objet ou ajoutent des pieds de page au corps du message. Les bons signent à nouveau le message et créent de nouvelles signatures DKIM provenant du domaine des listes de diffusion. Malheureusement, ce domaine ne s’alignera jamais sur le domaine « en-tête de ». Il y a eu plusieurs recommandations sur la façon de résoudre ce problème, mais à ce jour, la mise sur liste blanche du serveur de liste de diffusion est probablement la plus pratique.
Alignement DMARC, DKIM et SPF
Le DMARC s’attend actuellement à ce que le FPS passe explicitement si l’alignement du FPS doit se produire. SPF a cependant plusieurs états de retour qui, lorsqu’ils sont rencontrés uniquement avec SPF, nécessitent que le message soit autorisé. Un exemple courant est la TempError qui est renvoyée lors de l’apparition d’une erreur transitoire, par exemple un délai d’attente DNS dû à des problèmes de latence avec un serveur débordé. Un TempError aujourd’hui est considéré comme un échec SPF, donc si la partie DKIM échoue également, DMARC échouera pour un message potentiellement légitime.
Une autre technique d’hameçonnage courante de nos jours consiste simplement à usurper le nom affiché de la partie dans le champ « en-tête de ». Un champ d’en-tête peut être spécifié de la manière suivante : Odin Borson CEO <odin@asgard.com>. La première partie, avant l’adresse courriel entre crochets, est le nom d’affichage. Les clients de messagerie comme Outlook l’utilisent pour fournir un nom convivial à montrer à l’utilisateur final.
Alors que DMARC examine le domaine dans une adresse courriel « en-tête de », le nom d’affichage est ignoré. C’est problématique, surtout lorsque l’on lit et répond à des courriels sur un téléphone. Le plus souvent, vous ne voyez que le nom d’affichage sur le téléphone et non l’adresse courriel. Considérez donc le message suivant :
Notez les principales différences entre les lignes 11 et 12. Au lieu de se fier au champ « Répondre à » comme dans l’exemple précédent, dans l’exemple ci-dessus, la ligne 11 elle-même contient l’adresse à laquelle Loki s’attend à ce que Njord réponde. Cependant, dans ce cas, Loki a configuré un enregistrement DMARC valide pour midgard.com afin que le message passe DMARC. Loki s’appuie sur le fait que Njord répondra à Loki en pensant qu’il est Odin en se basant uniquement sur la partie du nom d’affichage (PDG d’Odin Borson) à la ligne 11. Sur les téléphones mobiles, c’est un gros problème, car il faut généralement cliquer sur les détails pour voir l’adresse courriel de la personne avec laquelle on communique. Un simple hameçonnage de nom d’affichage comme celui ici passe SPF, DKIM et DMARC car Loki possède midgard.com et les configure en conséquence.
Pratiques exemplaires
Lorsque vous configurez un enregistrement DMARC, commencez par p=aucun, puis passez à p=quarantaine lorsque vous êtes en confiance avec votre infrastructure. L’utilisation de p=reject lors de la configuration d’un enregistrement DMARC est dangereuse. Plus tôt dans cette critique, j’explique comment une erreur transitoire SPF (TempError) peut entraîner la non-livraison d’un message. En ayant p=quarantine au lieu de p=reject, votre message serait au moins livré à la quarantaine des destinataires au lieu d’être rejeté au niveau de la connexion.
La conservation constante de vos enregistrements SPF, en particulier lorsque vous avez des expéditeurs tiers ou que vous faites appel à des sociétés de marketing, est également cruciale pour réussir avec DMARC. Essayez de respecter la recherche de la limite de 10 dans DNS lors de la configuration de votre enregistrement SPF. Bien que vous puissiez avoir DKIM correctement configuré, il est préférable que le SPF et le DKIM fonctionnent de manière fiable pour que DMARC passe. Dans de tels cas, seul le FPS reste et doit donc être configuré correctement. Bien que cela devienne une tâche intimidante pour les grandes entreprises, il est essentiel de le faire.
Les rapports DMARC sont incroyables lorsque vous apportez des modifications à votre infrastructure. Les résultats des changements qui nécessitent la mise à jour de vos dossiers SPF et DKIM peuvent être surveillés dans les rapports DMARC que vous recevez quotidiennement. Mais, après un certain temps, la plupart des administrateurs informatiques finiront par les ignorer et les messages seront perdus dans leurs milliers de courriels. De plus, l’expéditeur du rapport doit être fiable. Après avoir configuré un enregistrement DMARC récemment, je me suis rendu compte que seuls les rapports des grands acteurs comme gmail.com, hotmail.com, yahoo.com etc. étaient utiles pour moi car je leur faisais plus confiance, d’autant plus qu’une plus grande quantité de messages avec un « en-tête de » utilisant mon domaine, se retrouvaient sur leurs domaines.
Tous les serveurs conformes au DMARC devraient-ils nécessairement produire des rapports? Notez que la génération de rapports peut potentiellement entraîner la génération d’un grand nombre de messages, surtout si l’enregistrement DMARC contient une adresse ruf (Reporting URI for Forensic Reports) et que cela représente une charge supplémentaire sur un MTA. Les rapports DMARC sur les serveurs chargés peuvent potentiellement générer beaucoup de courriels, assurez-vous que votre serveur peut gérer la nouvelle charge. N’utilisez pas ruf lors de la configuration de votre enregistrement DMARC. Si vous avez besoin d’une rétroaction immédiate, testez en envoyant des messages aux grands joueurs comme Gmail et examinez les détails du message. Ils ont généralement des en-têtes de résultat d’authentification où ils décrivent les résultats des vérifications SPF, DKIM et DMARC.
En fin de compte, le meilleur choix est de demander à un service de surveiller vos rapports DMARC pour détecter les changements atypiques. Chaque jour, un rapport est envoyé à l’adresse courriel indiquée dans le rua (URI de déclaration des rapports agrégés) champ. Bien qu’un administrateur informatique examine le rapport pendant quelques jours, il n’est pas réaliste de s’attendre à ce qu’il l’examine quotidiennement pendant de plus longues périodes. Les rapports DMARC sont rédigés dans un format qui permet d’automatiser facilement les lecteurs et les suivis. Un système automatisé où les changements dans les modèles de rapports déclenchent des alertes ne devrait pas être compliqué à mettre en œuvre et permettrait aux administrateurs informatiques de réagir rapidement aux changements dans leurs configurations qu’ils auraient pu manquer.
modusGate utilise DMARC pour protéger vos utilisateurs de messagerie contre les attaques d’hameçonnage et d’usurpation d’identité, tandis que Vircom offre un service modusSecurity pour vous aider à mettre en œuvre et à surveiller votre déploiement DMARC – en savoir plus ici ou en nous contactant . Abonnez-vous à notre blogue pour en savoir plus sur la sécurité des courriels!
