Les pièges du SPF : Le désordre obscurcit votre empreinte de sécurité
SPF peut être un outil puissant pour sécuriser un domaine de messagerie, mais il peut être mal compris. Fred Bianchi, Senior Deployment Manager de dmarcian, parle de certaines erreurs courantes qui entraînent un encombrement, conduisant à un enregistrement SPF moins sûr.
En tant que spécialistes du déploiement de DMARC, nous rencontrons une grande variété d'organisations de tailles et de structures différentes dans le monde entier. Nous avons appris que le moyen le plus rapide de juger de l'état de santé du courrier électronique d'une organisation est de commencer par l'enregistrement SPF. En effet, le SPF est généralement mal géré et les détails sont mal compris.
Il n'est pas rare qu'une organisation n'ait qu'une compréhension superficielle du SPF, ce qui peut conduire à des inclusions inutiles, ou à un encombrement, dans leur enregistrement. J'ai vu de nombreuses organisations qui ont déployé avec succès le SPF, mais qui, à l'avenir, n'accorderont pas beaucoup d'attention aux demandes internes d'ajout de vérifications à l'enregistrement SPF.
Au fur et à mesure de la croissance organique des organisations, des sources d'e-mails supplémentaires apparaissent sporadiquement. Il peut y avoir de longs cycles commerciaux entre le déploiement de la facturation en ligne et le lancement d'une newsletter. Et puis, lorsque les services changent, par exemple en changeant de fournisseur de bulletin d'information, il n'y a souvent pas de processus interne formel de "désintroduction" qui tienne compte de l'hygiène DNS. Et même dans les organisations qui adoptent un processus pour aller de l'avant, les recherches existantes ne sont généralement pas évaluées, et restent donc dans l'enregistrement et inutilisées.
Les dangers de l'encombrement des FPS
L'encombrement du SPF peut être non seulement des inclusions pour des services qui ne sont plus utilisés, mais aussi des inclusions inutiles de domaines de premier niveau. La plupart des gens comprennent que si une entité envoie en leur nom, elle doit être incluse dans l'enregistrement SPF. Mais tout est basé sur le domaine du chemin de retour qui est utilisé, car c'est ce qui est évalué pendant l'authentification SPF.
Voici un exemple : une organisation utilise SendGrid pour envoyer via un sous-domaine, comme newsletter.domain.com, puis nous découvrons que SendGrid lui-même est dans la déclaration SPF include sur le domaine de premier niveau (domain.com). Dans ce cas, inclure SendGrid dans la déclaration SPF include sur le domaine de premier niveau n'est pas nécessaire et contribue à l'encombrement du SPF et à des recherches inutiles.
Les enregistrements SPF étant visibles par le public, un enregistrement SPF désordonné indique au monde extérieur que vous n'avez peut-être pas de visibilité sur la façon dont vos domaines de messagerie sont utilisés. Plus il y a de recherches inutilisées et d'inclusions de premier niveau inutiles dans un enregistrement SPF, plus votre surface d'attaque est grande. Cela revient à autoriser des milliers d'adresses IP à envoyer des messages au nom de ce domaine. C'est comme si vous vous rendiez dans une quincaillerie pour faire faire des doubles des clés de votre maison et les distribuer à tout va.
Dans le domaine de la sécurité de l'information, il existe l'idée du principe du moindre privilège, selon lequel une personne ou une application ne se voit accorder que le niveau d'autorisation minimal nécessaire à l'exécution de la tâche. Lorsqu'il s'agit de gérer un enregistrement SPF, une considération similaire doit être donnée pour minimiser l'exposition et les opportunités pour les mauvais acteurs.
Nettoyer le désordre
Je pense que SPF a injustement une mauvaise réputation parce qu'il est mal géré. Il est difficile de blâmer les organisations, car sans utiliser d'outils tiers, il est difficile d'avoir une visibilité sur les éléments de l'enregistrement SPF qui sont activement utilisés. Puisque l'e-mail est sortant, la seule option native serait de vérifier les journaux d'e-mails des entreprises auxquelles vous envoyez des e-mails pour validation - une tâche impossible au mieux. L'ajout de DMARC et les rapports qu'il génère permettent de savoir où un domaine réussit ou échoue l'authentification SPF sur Internet. Des outils tiers, comme dmarcian, permettent de visualiser et de corréler les données brutes.
Comme je l'ai déjà mentionné, un examen du DNS qui inclut l'enregistrement SPF devrait faire partie du processus d'intégration d'une organisation lorsqu'il s'agit de mettre fin à une relation avec un fournisseur. Si cette politique n'est pas encore en place, un examen complet de l'enregistrement SPF doit être effectué pour s'assurer que seuls les fournisseurs actifs sont inclus.
Erreurs courantes en matière de FPS
- Inclusions de domaine de premier niveau inutiles
Comme nous l'avons mentionné ci-dessus avec l'exemple de SendGrid, les inclusions de domaine de premier niveau inutiles sont problématiques. Bien que le chemin de retour puisse refléter un domaine de premier niveau, c'est plutôt rare, car la plupart des fournisseurs ESP utilisent des sous-domaines pour le chemin de retour. Et comme nous le voyons souvent, il est bon de rappeler que le domaine qui est évalué pour l'authentification SPF est le domaine du chemin de retour (bounce) et non le domaine from :. - Des passerelles inutiles incluent
Lorsqu'une passerelle sécurisée est utilisée pour envoyer et recevoir des e-mails, et qu'il existe un include SPF pour Office 365 ou Google G Suite, l'un ou l'autre est ouvert à des centaines de milliers d'IP. - Ne pas comprendre la limite de consultation du DNS et la façon dont ces consultations sont calculées
Les enregistrements SPF sont limités à dix consultations, mais la façon dont cette limite est atteinte est une source de malentendus.
Les adresses IP ne sont pas prises en compte dans cette limite de consultation, mais tout ce qui doit être "résolu" l'est. Si un enregistrement SPF comprend un domaine qui doit ensuite être résolu en une adresse IP, cela compte. L'inclusion de mécanismes tels que "a" (pour les enregistrements A), "mx" (pour les enregistrements d'échangeur de courrier) et "ptr" (pour les requêtes de pointeur) compte également dans la limite de consultation. Vous pouvez trouver plus d'informations sur les mécanismes SPF ici.
Un autre point d'achoppement est le concept d'"inclusions imbriquées", lorsqu'une déclaration d'inclusion (par exemple, include:vendor.com) est développée pour découvrir que d'autres déclarations d'inclusion existent à l'intérieur, à l'instar des poupées Matryoshka (plus communément appelées poupées russes imbriquées). Cela peut parfois entraîner la découverte d'autres déclarations include ou blocs réseau sans aucun rapport. Ce genre de scénario peut potentiellement, et peut-être sans le savoir, ajouter des services et des adresses IP supplémentaires à votre enregistrement SPF.
Un exemple d'inclusions imbriquées peut être vu ci-dessous dans bluehost.com. Si nous faisons passer ce domaine par notre SPF Surveyor, nous constatons qu'il contient en fait 13 lookups uniques.
Pour inspecter et vérifier vos dossiers SPF, rendez-vous sur notre outil gratuit SPF Surveyor.
Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité du courrier électronique et une mission visant à rendre le courrier électronique et l'Internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation et à mettre en œuvre et gérer DMARC à long terme.
Vous voulez continuer la conversation ? Rendez-vous sur le forum dmarcien.
