Conclusion de l'expérience : L'aplatissement SPF
L'« aplatissement SPF » a été inventé par dmarcian lors du lancement initial de l'SPF Surveyor. Pendant de nombreuses années, cette fonctionnalité a été marquée comme « expérimentale ». Aujourd'hui, nous mettons fin à cette expérimentation et partageons nos enseignements.
Contexte du Sender Policy Framework (SPF)
Les opérateurs de messagerie utilisent le SPF pour s'identifier et identifier leur infrastructure lors de l'envoi d'e-mails sur Internet. Le SPF a été initialement créé par des opérateurs de messagerie vers 2000 en réponse aux attaques de type Joe Job. À cette époque, les spammeurs faisaient des opérateurs de messagerie légitimes leurs victimes en se faisant passer pour eux lors de l'envoi de spam. Les opérateurs légitimes étaient blâmés pour l'envoi de spam simplement parce qu'il n'existait aucun moyen simple d'identifier les opérateurs de messagerie et leur infrastructure.
Les opérateurs de messagerie publient des enregistrements SPF pour décrire leur infrastructure de messagerie. Ces enregistrements sont des chaînes de texte formatées de manière spécifique qui résident dans le DNS. Lors de la réception d'un e-mail, un serveur de messagerie examine le domaine de l'adresse e-mail de l'opérateur expéditeur (connu sous le nom de chemin inverse, adresse de rebond, enveloppe d'expéditeur, MAIL FROM et plus encore) pour récupérer l'enregistrement SPF du domaine.
Si l'infrastructure de messagerie décrite par l'enregistrement SPF est la même infrastructure qui tente de livrer l'e-mail, alors le destinataire a réussi à identifier l'opérateur d'envoi d'e-mails et son infrastructure.
Les défis actuels du SPF
Les enregistrements SPF sont confrontés à trois défis de maintenance distincts :
- Le SPF existe depuis très longtemps.
- Le fonctionnement du SPF est largement mal compris, même par les techniciens informatiques expérimentés.
- Pour interopérer avec DMARC, le SPF exige que les opérateurs de messagerie soient associés au domaine que les utilisateurs finaux voient dans l'en-tête « De : » d'un e-mail.
Le SPF existe depuis plus de 20 ans. Pendant de nombreuses années, les gens ont fait de leur mieux pour lister leur infrastructure d'envoi d'e-mails. Les serveurs étaient ajoutés aux enregistrements SPF mais presque jamais supprimés, car il n'y avait aucun moyen simple de déterminer si un serveur était toujours utilisé.
Pour aggraver les choses, le fonctionnement du SPF est largement mal compris. Les opérateurs de messagerie sont distinctement différents des personnes qui rédigent et envoient des e-mails, mais une erreur courante est de croire que le SPF vérifie le domaine « De : » d'un e-mail au lieu du domaine de l'opérateur, connu sous le nom de chemin inverse.
Cette erreur est répandue et entraîne un gonflement des enregistrements SPF avec une infrastructure qui n'est pas réellement utilisée par un opérateur pour envoyer des e-mails. Dans les pires cas, les fournisseurs de services de messagerie s'identifient en utilisant le domaine de leurs clients, ce qui amène le client à assumer le rôle d'« opérateur de messagerie » même si le client paie spécifiquement le fournisseur de services de messagerie pour gérer les opérations de messagerie.
Avant l'arrivée de DMARC, les opérateurs de messagerie pouvaient s'identifier en utilisant un chemin inverse qui pointait vers leur propre opération. Il n'était pas nécessaire que les opérateurs de messagerie soient associés au domaine « De : » que les utilisateurs voient dans leurs applications de messagerie.
Cependant, le SPF est l'une des deux technologies qui peuvent être utilisées pour atteindre la conformité DMARC ; l'autre est DKIM. Afin d'utiliser le SPF pour établir la conformité DMARC, DMARC exige que le chemin inverse de l'opérateur de messagerie soit le même domaine ou un sous-domaine de ce que les utilisateurs voient dans l'en-tête « De : » d'un e-mail. Pour interopérer avec DMARC, trop de fournisseurs de services de messagerie finissent par s'identifier en utilisant le domaine de premier niveau de leurs clients, ce qui entraîne un gonflement supplémentaire des enregistrements SPF, comme décrit ci-dessus.
« Trop de requêtes DNS » comme symptôme
Lorsque les défis du SPF s'accumulent, les enregistrements SPF peuvent être inexacts, inutilement longs au point de dépasser les limites de traitement intégrées du SPF, et exposer une organisation à des risques en raison d'une autorisation trop large et incontrôlée.
L'SPF Surveyor de dmarcian a été le premier outil public à mettre en évidence les limites de traitement intégrées du SPF, communément appelé le problème des « trop de requêtes DNS ». En termes simples, la spécification SPF vise à protéger les serveurs de messagerie récepteurs contre les enregistrements SPF qui, autrement, forceraient le serveur récepteur à consommer trop de ressources en tentant de traiter un enregistrement SPF et de livrer l'e-mail.
Voici les raisons pour lesquelles les enregistrements SPF rencontrent le problème des trop nombreuses requêtes DNS :
- les gens ajoutent des éléments aux enregistrements SPF sans jamais supprimer d'entrées,
- il est demandé aux gens d'« inclure : » l'infrastructure dans leurs enregistrements SPF de premier niveau jusqu'à ce que les limites intégrées du SPF soient atteintes, et
- la nécessité d'interopérer avec DMARC peut entraîner un gonflement extrême des enregistrements SPF.
Chez dmarcian, nous avons compris que les enregistrements SPF volumineux et difficiles à gérer — le plus souvent rencontrés sous la forme de l'erreur « Trop de requêtes DNS » — sont un symptôme de problèmes plus vastes : une mauvaise compréhension du fonctionnement du SPF, des pratiques de gestion des fournisseurs incomplètes en ce qui concerne les fournisseurs qui envoient des e-mails au nom d'une organisation, et un manque de segmentation des e-mails selon les meilleures pratiques au sein d'une organisation.
Les dangers de l'aplatissement SPF
L'aplatissement SPF tente de contourner l'erreur « Trop de requêtes DNS » sans aborder les problèmes sous-jacents qui ont causé l'erreur en premier lieu. Faire disparaître l'erreur sans prêter attention aux problèmes sous-jacents peut mener à une situation problématique. Le personnel informatique d'une organisation se retrouve involontairement responsable du comportement et de l'infrastructure de tous les fournisseurs/opérateurs de messagerie qui envoient des e-mails en utilisant le domaine de premier niveau de l'organisation :
- D'un point de vue réputationnel, les destinataires ne peuvent pas facilement différencier les différents types d'e-mails. Par exemple, les factures et les newsletters partagent le même domaine, ce qui signifie que des newsletters indésirables peuvent entraîner l'acheminement des factures vers les dossiers de spam, simplement parce que les destinataires voient l'e-mail provenir du même domaine.
- D'un point de vue opérationnel, les fournisseurs ne reçoivent pas les signaux dont ils ont besoin pour gérer efficacement les e-mails qu'ils envoient au nom de l'organisation. Par exemple, si un fournisseur envoie un e-mail à un destinataire invalide, générant un message de rebond, ce message de rebond sera acheminé au personnel informatique et non au fournisseur. En règle générale, le personnel informatique ne transmet pas ce type de signaux à ses fournisseurs, laissant les fournisseurs « naviguer à l'aveugle » et impacter progressivement et négativement la réputation de l'organisation (voir ci-dessus).
- D'un point de vue sécurité, la sur-autorisation due à des enregistrements SPF surchargés est une autre façon de dire que « les entrées inutiles dans les enregistrements SPF créent des surfaces d'attaque ». Si un adversaire parvient à s'introduire dans (ou simplement à louer) une partie de l'infrastructure listée dans un enregistrement SPF, cet adversaire est capable d'envoyer des e-mails conformes à DMARC, contournant ainsi efficacement les contrôles et utilisant ces contrôles pour détourner la réputation de l'organisation afin de commettre des fraudes.
Étant donné le rôle prépondérant de l'e-mail dans les cyberattaques, contourner le message d'erreur symptomatique de SPF sans s'attaquer aux problèmes sous-jacents va à l'encontre de la mission des professionnels de la sécurité de l'information et de la gestion des risques.
dmarcian a résisté à la tentation de transformer l'aplatissement SPF en un produit ou un service, principalement parce que le besoin d'aplatissement SPF disparaît lorsqu'une organisation adopte les meilleures pratiques et segmente ses fournisseurs et ses flux d'e-mails. Les organisations qui s'orientent dans cette direction bénéficient de meilleurs contrôles, d'une surface d'attaque réduite, d'une efficacité opérationnelle et d'une résilience réputationnelle qui découle de la compartimentalisation des fournisseurs et de la limitation des effets de débordement potentiels d'un incident cybernétique.
La fin de l'expérimentation de l'aplatissement SPF
dmarcian a constaté que certaines équipes informatiques sont limitées dans leur capacité à apporter des changements dans des domaines qui vont au-delà du traitement des tickets ou du support des groupes existants. Ces équipes n'ont pas pour mission d'améliorer les processus métier ou de résoudre les problèmes de sécurité ou de gestion des risques, ce qui rend le déploiement des meilleures pratiques de type dmarcian (qui peuvent s'étendre à plusieurs groupes) hors de portée.
Pour ces équipes, dmarcian considère l'« aplatissement SPF » comme une solution temporaire en attendant que l'organisation puisse s'aligner pour adopter les meilleures pratiques susceptibles d'alléger la charge/les problèmes actuels rencontrés par les équipes informatiques. La partie « solution temporaire » reconnaît que les équipes informatiques dans cette situation ont besoin de temps sans erreurs SPF afin de collaborer avec d'autres groupes pour déployer des changements plus substantiels et durables.
Le danger que dmarcian identifie dans ces situations est que les équipes informatiques maintiennent la solution temporaire en place et ne parviennent jamais à résoudre les problèmes sous-jacents (qu'elles n'ont, sans doute, pas pour mission de traiter).
Utiliser les données DMARC pour éclairer les décisions
Depuis plus d'une décennie, dmarcian recommande d'utiliser les données DMARC pour évaluer l'état actuel d'une organisation, identifier les étapes nécessaires pour établir la conformité DMARC, et éclairer la planification de projets dans le but de mettre en œuvre les meilleures pratiques.
Ces étapes aident tout le monde – y compris les équipes informatiques contraintes – à prendre des décisions éclairées.
Avant de prendre les mesures extraordinaires d'utiliser l'aplatissement SPF pour contourner les limites intrinsèques de SPF, utilisez les données DMARC et la plateforme de dmarcian pour obtenir un aperçu de la situation.
Si vous avez besoin d'aide pour gérer vos enregistrements SPF, contactez-nous et n'hésitez pas à utiliser nos ressources DMARC, qui sont accessibles à tous, que vous ayez un compte dmarcian ou non.
