Conclure l'expérience : Aplatissement du SPF

"L'aplatissement des FPS" a été inventé par dmarcian dans le cadre de la version initiale du SPF Surveyor. Pendant de nombreuses années, la fonctionnalité a été signalée comme "expérimentale". Aujourd'hui, nous concluons cette expérience et partageons ce que nous avons appris.

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é créé à l'origine par les opérateurs de messagerie vers 2000 en réponse aux attaques de Joe Job. À cette époque, les spammeurs faisaient des victimes parmi les opérateurs de messagerie légitimes en se faisant passer pour eux lors de l'envoi de spam. Les opérateurs légitimes étaient accusés d'envoyer du spam simplement parce qu'il n'y avait pas de moyen facile 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 spécialement formatées qui se trouvent dans le DNS. Lorsqu'il reçoit un courriel, un serveur de courriel examine le domaine de l'adresse de courriel de l'opérateur d'envoi (connu sous le nom de chemin inverse, adresse de rebond, enveloppe de, MAIL FROM et autres) pour récupérer l'enregistrement SPF du domaine.

Si l'infrastructure de messagerie décrite par l'enregistrement SPF est la même que celle qui tente de délivrer le courrier électronique, alors le récepteur a réussi à identifier l'opérateur d'envoi du courrier électronique et son infrastructure.

Les défis SPF d'aujourd'hui

Les enregistrements SPF sont confrontés à trois problèmes de maintenance distincts :

1. Le FPS existe depuis très longtemps.
2. Le fonctionnement du FPS est largement incompris, même par les techniciens informatiques expérimentés.
3. Pour interagir avec DMARC, SPF exige que les opérateurs de messagerie soient associés au domaine que les utilisateurs finaux voient dans l'en-tête "From :" d'un courriel.

Le SPF existe depuis plus de 20 ans. Pendant de nombreuses années, les gens faisaient de leur mieux pour répertorier leur infrastructure d'envoi d'e-mails. Les serveurs étaient ajoutés aux enregistrements SPF mais n'étaient presque jamais supprimés car il n'y avait pas de moyen facile de déterminer si un serveur était toujours utilisé.

Pour aggraver les choses, le fonctionnement de SPF est largement incompris. Les opérateurs de messagerie sont très différents des personnes qui écrivent et envoient des courriels, mais un malentendu courant est que SPF vérifie le domaine "From :" d'un courriel au lieu du domaine de l'opérateur, connu sous le nom de "reverse-path".

Ce malentendu est très répandu et fait que les enregistrements SPF sont gonflés par une infrastructure qui n'est pas réellement utilisée par un opérateur pour envoyer du courrier électronique. Dans le pire des cas, les fournisseurs de messagerie s'identifient en utilisant le domaine de leurs clients, ce qui amène le client à endosser le rôle d'"opérateur de messagerie" alors que le client paie spécifiquement le fournisseur de messagerie pour s'occuper des opérations de messagerie.

Avant l'arrivée de DMARC, les opérateurs de messagerie pouvaient s'identifier à l'aide d'un chemin inverse qui pointait vers leur propre opération. Les opérateurs de messagerie n'avaient pas besoin d'être associés au domaine "From :" que les gens voient dans leurs applications de messagerie.

Cependant, SPF est l'une des deux technologies qui peuvent être utilisées pour assurer la conformité DMARC, l'autre étant DKIM. Pour utiliser SPF afin d'assurer la conformité DMARC, il faut que le chemin inverse de l'opérateur de messagerie soit le même domaine ou un sous-domaine de ce que les gens voient dans l'en-tête "From :" d'un courriel. Pour interopérer avec DMARC, trop de fournisseurs 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 recherches DNS" comme symptôme

Lorsque l'on additionne les défis posés par SPF, les enregistrements SPF peuvent être inexacts, inutilement longs au point de dépasser les limites de traitement intégrées à SPF, et exposer une organisation à des risques en raison d'une autorisation trop large et non contrôlée.

SPF Surveyor de dmarcian a été le premier outil public à mettre en évidence les limites de traitement intégrées de SPF, communément appelées "Too many DNS lookups". En termes simples, la spécification SPF tente de protéger les serveurs de messagerie récepteurs contre les enregistrements SPF qui obligeraient le serveur récepteur à consommer trop de ressources lorsqu'il tente de traiter un enregistrement SPF et de délivrer le courrier électronique.

Voici les raisons pour lesquelles les enregistrements SPF rencontrent le problème du "Too Many DNS Lookups" :

• les gens ajoutent des choses aux enregistrements SPF sans jamais supprimer les entrées,
• les gens sont invités à inclure l'infrastructure "include :" dans leurs enregistrements SPF de premier niveau jusqu'à ce que les limites intégrées de 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 l'erreur " Too Many DNS Lookups " - sont le symptôme de problèmes plus importants : une mauvaise compréhension du fonctionnement du SPF, des pratiques incomplètes de gestion des fournisseurs qui envoient des e-mails au nom d'une organisation, et un manque de bonnes pratiques de segmentation des e-mails au sein d'une organisation.

Les dangers de l'aplatissement du SPF

SPF Flattening tente de contourner l'erreur "Too Many DNS Lookups" sans s'attaquer aux problèmes sous-jacents qui ont provoqué l'erreur en premier lieu. Faire disparaître l'erreur sans prêter attention aux problèmes sous-jacents peut conduire à un mauvais endroit. 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 :

• Du point de vue de la réputation, les destinataires ne peuvent pas facilement faire la différence entre les différents types d'e-mails. Par exemple, les factures et les bulletins d'information partagent le même domaine, ce qui signifie que les bulletins d'information spammés peuvent faire atterrir les factures dans les dossiers de spam, simplement parce que les destinataires voient que l'e-mail provient 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 courriel à un mauvais destinataire et qu'il génère un message de rebond, ce message de rebond sera transmis 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 ces derniers "voler de leurs propres ailes" et nuire progressivement à la réputation de l'organisation (voir ci-dessus).
• Du point de vue de la sécurité, la sur-autorisation due à des enregistrements SPF gonflé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 est capable de s'introduire dans (ou simplement de louer) n'importe quel élément d'infrastructure répertorié dans un enregistrement SPF, il est en mesure 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 et commettre des fraudes.

Étant donné le rôle dominant du courrier électronique 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é à l'envie de faire de SPF Flattening un produit ou un service, principalement parce que le besoin de SPF Flattening disparaît lorsqu'une organisation adopte les meilleures pratiques et segmente ses fournisseurs et ses flux d'e-mails. Les organisations qui s'engagent dans cette voie bénéficient de meilleurs contrôles, d'une surface d'attaque réduite, d'une efficacité opérationnelle et d'une résilience de leur réputation grâce au cloisonnement des fournisseurs et à la limitation des retombées d'un éventuel cyberincident.

La fin de l'expérience d'aplatissement du SPF

dmarcian a appris que certaines équipes informatiques sont limitées dans leur capacité à apporter des changements dans des domaines qui vont au-delà de la gestion des tickets ou du soutien aux groupes existants. Ces équipes ne sont pas chargées d'améliorer les processus commerciaux ou de traiter les questions de sécurité ou de gestion des risques, ce qui met hors de portée le déploiement des meilleures pratiques de type dmarcian (qui peuvent s'étendre à plusieurs groupes).

Pour ces équipes, dmarcian considère "SPF Flattening" comme une solution provisoire jusqu'à ce que l'organisation puisse s'aligner pour adopter les meilleures pratiques qui peuvent alléger la charge/les problèmes actuels des équipes informatiques. La partie "palliative" 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 voit dans ces situations est que les équipes informatiques laissent la solution provisoire en place et ne s'attaquent jamais aux problèmes sous-jacents (pour lesquels elles ne sont pas habilitées à intervenir).

Utilisez les données DMARC pour éclairer vos décisions

Depuis plus de dix ans, dmarcian recommande d'utiliser les données DMARC pour évaluer l'état actuel d'une organisation, identifier les étapes nécessaires à la mise en conformité DMARC, et informer 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 limitées - à prendre des décisions en connaissance de cause.

Avant de prendre des mesures extraordinaires en utilisant SPF Flattening pour contourner les limites intégrées de SPF, utilisez les données DMARC et la plateforme de dmarcian pour mieux comprendre 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 disponibles pour tous, que vous ayez un compte dmarcian ou non.