Messagerie migrée dans le Cloud, politique DMARC en mode reject, vous croyez avoir atteint le Graal ? Pas tout à fait..

Comme on peut le constater dans leurs déclarations SPF, de plus en plus d'entreprises utilisent des messageries mutualisées (G Suite, Office 365, ...). Suivant les recommandations de ces opérateurs elles authentifient leurs flux sortants en ajoutant dans leurs déclarations SPF leurs mécanismes include, par exemple :

include:_spf.google.com

include:spf.protection.outlook.com

Cependant, faire figurer des adresses IP mutualisées dans une déclaration SPF est fondamentalement une mauvaise pratique : cela augmente la surface d'attaque et autorise des plages IP accessibles par des tiers à émettre en votre nom. Par exemple, il est assez facile de créer un compte malveillant chez un de ces opérateurs, d'y whitelister un serveur pirate afin de passer outre les contrôles, puis d'utiliser une règle de routage adhoc vers la cible tout en conservant le domaine d'enveloppe. Un courriel usurpant votre domaine émis initialement depuis une adresse pirate peut donc se doter au passage d'une adresse autorisée dans votre propre déclaration SPF. En bout de chaîne les contrôles d'authentification SPF et DMARC opérés sur le courriel pirate sont valides bien qu'il ait initialement été émis par une source invalide, seule l'analyse des en têtes complets permet de voir la supercherie.

L'expérience prouve malheureusement que ce genre de tour de passe passe fonctionne, je vous recommande donc si vous utilisez une solution de messagerie mutualisée de router vos flux sortants via une passerelle dédiée (simple à configurer sur G Suite et Office 365) et ne faire figurer que cette passerelle dans votre déclaration SPF.