Avanan : à la découverte du volume d'e-mails mystérieux
Lors de l'analyse des données DMARC de votre domaine, vous pourriez constater un phénomène déroutant : un grand nombre d'e-mails envoyés au nom de vos domaines à partir d'adresses IP pointant vers *.cloud-sec-av.com, dont la plupart échouent généralement au test DMARC. Plus inquiétant encore, toutes ces données, signalées par Microsoft, pourraient indiquer que ces e-mails ont été rejetés.
Vous vous demandez peut-être pourquoi ces serveurs envoient autant d'e-mails en usurpant votre domaine, ou si votre domaine est utilisé à des fins frauduleuses pour escroquer des destinataires peu méfiants. Heureusement, il y a une explication à cela, qui met en évidence un comportement particulier de Microsoft qui mérite d'être souligné.
Qu'est-ce qu'Avanan ?
Check Point Avanan est un service de sécurité des e-mails basé sur le cloud utilisé par les entreprises qui ont adopté Microsoft 365. Dans son mode de déploiement entrant le plus courant, le « mode Protect (Inline) », Avanan ne modifie pas l'enregistrement MX du destinataire ; Microsoft 365 reste l'enregistrement MX public. Au lieu de cela, Avanan s'intègre au flux de messagerie Exchange Online en interne via des connecteurs et des règles de transport au sein du tenant M365 du destinataire.
Bruit DMARC
Lorsqu'un e-mail vous parvient, il suit le parcours suivant :
- Votre serveur de messagerie transmet le message au serveur MX du destinataire, c'est-à-dire Microsoft 365. M365 effectuera toutes les vérifications d'authentification des e-mails entrants (DMARC, SPF, DKIM) ainsi que les contrôles de sécurité pour lesquels il est configuré.
- Les règles de transport M365 acheminent le message depuis le tenant destinataire vers l'infrastructure d'analyse d'Avanan, où il est soumis à des analyses visant à détecter les logiciels malveillants, le phishing et à prévenir la perte de données (DLP). Ce processus peut parfois réécrire les URL, supprimer les pièces jointes, insérer des bannières ou modifier d'une autre manière le corps du courriel d'origine. Cela revêt une importance particulière pour la préservation de toute signature DKIM existante.
- Avanan renvoie le message, désormais modifié, vers le tenant M365 du destinataire à partir de ses propres plages d'adresses IP (*.cloud-sec-av.com).
- M365 reçoit le message une deuxième fois et effectue à nouveau les contrôles d'authentification (SPF, DKIM, DMARC) sur ce message. C'est ce deuxième contrôle d'authentification qui apparaît dans vos rapports DMARC.
Les informations trompeuses de Microsoft
La manière dont Microsoft rend compte des vérifications DMARC est souvent source de confusion chez les clients. Si votre domaine applique DMARC avec une politique de mise en quarantaine ou de rejet, les rapports indiqueront souvent que la vérification DMARC a échoué, et le sort réservé à l'e-mail reflétera la politique d'application que vous avez publiée.
Ce n'est pas ce qui s'est réellement passé avec votre courrier.
Votre message a bien été transmis à l'utilisateur !
Les adresses IP d'Avanan sont ajoutées à la liste blanche au niveau de la connexion afin de garantir la livraison, mais Microsoft effectue non seulement une vérification DMARC malgré tout, mais indique également quelle aurait été la décision prise si la liste blanche n'avait pas été en place. Les rapports DMARC comportent un mécanisme permettant aux émetteurs de signaler pourquoi ils ont pu appliquer une décision différente de votre politique publiée. Cela se fait via les fonctionnalités « Motif de dérogation » et « Commentaire de dérogation » du rapport agrégé, fonctionnalités que Microsoft, il convient de le noter, n'utilise pas.
Que devriez-vous faire à ce sujet ?
Rien.
En tant que propriétaire du domaine expéditeur, aucune action utile ne vous est proposée. En particulier :
- N'ajoutez pas les adresses IP d'Avanan à votre enregistrement SPF, sauf si vous êtes vous-même propriétaire et utilisateur d'Avanan.
- Ne modifiez pas votre politique DMARC pour les flux de messagerie indirects. Contrairement à ce qu’indique le message, il ne s’agit pas de véritables échecs de livraison, et il est fortement recommandé de ne pas intervenir. Ces échecs DMARC sont dus au relais de messages par des infrastructures situées en dehors de votre périmètre administratif ; il s’agit en fait de messages qui sont transférés après avoir été remis avec succès à leur destinataire.
- Inutile de contacter le destinataire, il ne rejette pas votre message.
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
