Pièges de SPF : L'encombrement 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, directeur des affaires américaines chez dmarcian, parle de quelques erreurs courantes qui entraînent un encombrement, conduisant à un enregistrement SPF moins que sécurisé.
En tant que spécialistes du déploiement DMARC, nous rencontrons une grande diversité d'organisations de tailles et de structures variées à travers le monde. L'une des choses que nous avons apprises est que le moyen le plus rapide d'évaluer la santé d'un système de messagerie d'une organisation est de commencer par l'enregistrement SPF. C'est parce que le SPF, en général, est mal géré et que ses détails sont mal compris.
Il n'est pas rare qu'une organisation ait une compréhension superficielle du SPF, ce qui peut entraîner des inclusions inutiles, ou un encombrement, dans son enregistrement. J'ai vu de nombreuses organisations qui ont déployé le SPF avec succès, mais par la suite, peu d'attention est accordée aux demandes internes d'ajout de recherches à l'enregistrement SPF.
À mesure que les organisations se développent naturellement, 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 lorsque les services changent, comme le passage à un autre fournisseur de newsletter, il n'y a souvent pas de processus interne formel de « désactivation » qui tienne compte de l'hygiène DNS. Et même dans les organisations qui adoptent un tel processus, les recherches existantes ne sont généralement pas évaluées, de sorte qu'elles restent dans l'enregistrement et sont inutilisées.
Les dangers de l'encombrement SPF
L'encombrement SPF peut non seulement provenir d'inclusions pour des services qui ne sont plus utilisés, mais aussi d'inclusions de domaines de premier niveau superflues. La plupart comprennent que si une entité envoie en leur nom, elle doit être incluse dans l'enregistrement SPF. Mais tout est basé sur le domaine de chemin de retour (return-path) utilisé, car c'est ce qui est évalué lors de 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 inclus dans la déclaration SPF du domaine de premier niveau (domain.com). Dans ce cas, inclure SendGrid dans la déclaration SPF du domaine de premier niveau n'est pas nécessaire et contribue à l'encombrement SPF et à des recherches superflues.
Étant donné que les enregistrements SPF sont publiquement visibles, un enregistrement SPF désordonné communique au monde extérieur que vous n'avez peut-être pas de visibilité sur la manière dont vos domaines de messagerie sont utilisés. Plus un enregistrement SPF contient de recherches inutilisées et d'inclusions de premier niveau superflues, plus la surface d'attaque potentielle est grande. Cela revient à autoriser des milliers d'adresses IP à envoyer des e-mails au nom de ce domaine. C'est comme aller dans une quincaillerie, faire faire un tas de doubles de clés pour votre maison, puis les distribuer à tout-va.
En sécurité de l'information, il existe le principe du moindre privilège, selon lequel une personne ou une application ne se voit accorder que le niveau de permission minimal nécessaire pour accomplir sa tâche. En ce qui concerne la gestion d'un enregistrement SPF, une considération similaire devrait être appliquée pour minimiser l'exposition et les opportunités pour les acteurs malveillants.
Éliminer l'encombrement
Je pense que le SPF a injustement mauvaise réputation parce qu'il est mal géré. Il est difficile de blâmer les organisations, car sans l'utilisation d'outils tiers, il est compliqué d'obtenir une visibilité sur les éléments de l'enregistrement SPF qui sont activement utilisés. Étant donné que l'e-mail est sortant, la seule option native serait de vérifier les journaux d'e-mails des entreprises auxquelles vous envoyez pour validation — une tâche au mieux impossible. L'ajout de DMARC et des rapports qu'il génère offre un aperçu de l'endroit où un domaine réussit ou échoue l'authentification SPF sur Internet. Des outils tiers, comme dmarcian, fournissent une visualisation et une corrélation des données brutes.
Comme je l'ai mentionné précédemment, un examen DNS incluant l'enregistrement SPF devrait faire partie du processus de désengagement d'une organisation lorsqu'il s'agit de mettre fin à une relation avec un fournisseur. Si cette politique n'est pas actuellement en place, un examen complet de l'enregistrement SPF devrait être effectué pour s'assurer que seuls les fournisseurs actifs sont inclus.
Erreurs courantes du SPF
- Inclusions de haut niveau inutiles
Comme nous l'avons mentionné ci-dessus avec l'exemple de SendGrid, les inclusions de domaines de premier niveau inutiles sont problématiques. Bien que le chemin de retour (return-path) puisse refléter un domaine de premier niveau, c'est assez rare, car la plupart des fournisseurs d'ESP utilisent des sous-domaines pour le chemin de retour. Et comme nous le constatons souvent, il est bon de rappeler que le domaine évalué pour l'authentification SPF est le domaine du chemin de retour (bounce) et non le domaine de l'expéditeur (from:). - Inclusions de passerelle inutiles
Lorsqu'une passerelle sécurisée est utilisée pour envoyer et recevoir des e-mails, et qu'il y a une inclusion SPF pour Office 365 ou Google G Suite, l'une ou l'autre de ces options est ouverte à des centaines de milliers d'adresses IP. - Méconnaissance de la limite de requêtes DNS et de leur calcul
Les enregistrements SPF ont une limite stricte de dix « requêtes » (lookups), mais la manière dont cette limite est atteinte a été une source de malentendus selon notre expérience.
Les adresses IP ne sont pas prises en compte dans cette limite de requêtes, mais tout ce qui doit être « résolu » l'est. Si un enregistrement SPF inclut un domaine qui doit ensuite être résolu en une adresse IP, alors cela compte. L'inclusion de mécanismes tels que « a » (pour les enregistrements A), « mx » (pour les enregistrements d'échange de courrier) et « ptr » (pour les requêtes de pointeur) compte également dans la limite de requêtes. 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 instruction d'inclusion (par exemple, include:vendor.com) est développée pour découvrir que d'autres instructions d'inclusion existent à l'intérieur, à l'image des poupées Matriochka (plus communément appelées poupées russes). Cela peut parfois entraîner la découverte d'autres instructions d'inclusion ou de blocs réseau totalement sans rapport. Ce type de scénario ajoute potentiellement, et peut-être à votre insu, des services et des adresses IP supplémentaires à votre enregistrement SPF.
Un exemple d'inclusions imbriquées peut être observé ci-dessous avec bluehost.com. Si nous analysons ce domaine avec notre SPF Surveyor, nous constatons qu'il contient en réalité 13 requêtes uniques.
Pour inspecter et vérifier vos enregistrements SPF, rendez-vous sur notre SPF Surveyor gratuit.
Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité e-mail et une mission visant à rendre l'e-mail et Internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation, et à implémenter et gérer DMARC sur le long terme.
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
