Posts

En tant que prestataire de services de la DMARC, on nous pose souvent cette question : "Si le DMARC utilise uniquement les authentifications SPF et DKIM, pourquoi devrions-nous nous préoccuper du DMARC ? N'est-ce pas tout simplement inutile ?

En apparence, cela peut sembler ne pas faire de grande différence, mais la réalité est très différente. Le DMARC n'est pas seulement une combinaison des technologies SPF et DKIM, c'est un protocole entièrement nouveau en soi. Il possède plusieurs caractéristiques qui en font l'une des normes d'authentification du courrier électronique les plus avancées au monde, et une nécessité absolue pour les entreprises.

Mais attendez une minute. Nous ne savons pas exactement pourquoi vous avez besoin du DMARC. Qu'est-ce qu'elle offre que le SPF et le DKIM n'offrent pas ? Eh bien, c'est une réponse assez longue ; trop longue pour un seul article de blog. Alors, séparons-nous et parlons d'abord du SPF. Au cas où vous ne le sauriez pas, voici une petite introduction.

Qu'est-ce que le SPF ?

Le SPF, ou Sender Policy Framework, est un protocole d'authentification des courriers électroniques qui protège le destinataire des courriers électroniques usurpés. Il s'agit essentiellement d'une liste de toutes les adresses IP autorisées à envoyer des courriers électroniques par vos canaux (le propriétaire du domaine). Lorsque le serveur récepteur voit un message de votre domaine, il vérifie votre enregistrement SPF publié sur votre DNS. Si l'adresse IP de l'expéditeur figure dans cette "liste", le courrier électronique est livré. Sinon, le serveur rejette le courriel.

Comme vous pouvez le voir, le SPF fait un assez bon travail en empêchant l'envoi de nombreux courriels indésirables qui pourraient endommager votre appareil ou compromettre les systèmes de sécurité de votre organisation. Mais le SPF n'est pas aussi efficace que certains pourraient le penser. C'est parce qu'il présente des inconvénients majeurs. Parlons de certains de ces problèmes.

Limites du SPF

Les enregistrements SPF ne s'appliquent pas à l'adresse de départ

Les courriers électroniques ont plusieurs adresses pour identifier leur expéditeur : l'adresse "From" que vous voyez normalement et l'adresse "Return Path" qui est cachée et qui nécessite un ou deux clics pour être affichée. Lorsque le SPF est activé, le serveur de courrier électronique récepteur examine le chemin de retour et vérifie les enregistrements SPF du domaine de cette adresse.

Le problème ici est que les attaquants peuvent exploiter cela en utilisant un faux domaine dans leur adresse de retour et une adresse électronique légitime (ou d'apparence légitime) dans la section "De". Même si le destinataire vérifiait l'identifiant de l'expéditeur, il verrait d'abord l'adresse de départ et ne prendrait généralement pas la peine de vérifier la voie de retour. En fait, la plupart des gens ne savent même pas qu'il existe une adresse de retour.

Le SPF peut être assez facilement contourné en utilisant cette simple astuce, et cela laisse même les domaines sécurisés avec SPF largement vulnérables.

Les enregistrements SPF ont une limite de consultation DNS

Les enregistrements SPF contiennent une liste de toutes les adresses IP autorisées par le propriétaire du domaine à envoyer des courriels. Cependant, ils présentent un inconvénient majeur. Le serveur récepteur doit vérifier l'enregistrement pour voir si l'expéditeur est autorisé, et pour réduire la charge du serveur, les enregistrements SPF ont une limite de 10 consultations DNS.

Cela signifie que si votre organisation fait appel à plusieurs fournisseurs tiers qui envoient des courriers électroniques via votre domaine, l'enregistrement SPF peut finir par dépasser cette limite. À moins d'être correctement optimisés (ce qui n'est pas facile à faire vous-même), les enregistrements SPF auront une limite très restrictive. Lorsque vous dépassez cette limite, l'implémentation du SPF est considérée comme invalide et votre courriel échoue le SPF. Cela pourrait potentiellement nuire à vos taux de livraison de courrier électronique.

 

Le SPF ne fonctionne pas toujours lorsque le courrier électronique est transféré

Le SPF présente un autre point de défaillance critique qui peut nuire à la délivrabilité de votre courrier électronique. Lorsque vous avez mis en place un SPF sur votre domaine et que quelqu'un transfère votre courrier électronique, le courrier électronique transféré peut être rejeté en raison de votre politique de SPF.

En effet, le message transféré a changé de destinataire, mais l'adresse de l'expéditeur reste la même. Cela devient un problème car le message contient l'adresse "From" de l'expéditeur d'origine, mais le serveur de réception voit une IP différente. L'adresse IP du serveur de transfert de courrier électronique n'est pas incluse dans l'enregistrement SPF du domaine de l'expéditeur d'origine. Cela pourrait entraîner le rejet du courrier électronique par le serveur de réception.

Comment le DMARC résout ces problèmes ?

Le DMARC utilise une combinaison de SPF et de DKIM pour authentifier le courrier électronique. Un courrier électronique doit passer soit par SPF soit par DKIM pour passer par DMARC et être livré avec succès. Il ajoute également une fonction clé qui le rend beaucoup plus efficace que le SPF ou le DKIM seuls : Rapports.

Avec les rapports de la DMARC, vous obtenez un retour d'information quotidien sur l'état de vos canaux de courrier électronique. Cela comprend des informations sur votre alignement DMARC, des données sur les courriels qui ont échoué à l'authentification et des détails sur les tentatives potentielles d'usurpation d'identité.

Si vous vous demandez ce que vous pouvez faire pour éviter l'usurpation d'identité, consultez notre guide pratique sur les 5 meilleures façons d'éviter l'usurpation d'identité par courriel.

Démystifier les mythes de DMARC

Pour beaucoup de gens, l'utilité de DMARC n'est pas évidente, pas plus que la manière dont il prévient l'usurpation de domaine, l'usurpation d'identité et la fraude. Cela peut conduire à de graves idées fausses sur DMARC, sur le fonctionnement de l'authentification des e-mails et sur son intérêt pour vous. Mais comment savoir ce qui est vrai et ce qui est faux ? Et comment être sûr de l'appliquer correctement ? 

PowerDMARC est à la rescousse ! Pour vous aider à mieux comprendre le DMARC, nous avons compilé cette liste des 6 idées fausses les plus courantes sur le DMARC.

Idées fausses sur DMARC

1. Le DMARC est identique à un filtre anti-spam

C'est l'une des erreurs les plus courantes concernant DMARC. Les filtres anti-spam bloquent les courriels entrants qui arrivent dans votre boîte de réception. Il peut s'agir d'e-mails suspects envoyés depuis n'importe quel domaine, pas seulement le vôtre. DMARC, en revanche, indique aux serveurs de messagerie récepteurs comment traiter les e-mails sortants envoyés depuis votre domaine. Les filtres anti-spam comme Microsoft Office 365 ATP ne protègent pas contre de telles cyberattaques. Si votre domaine est soumis à la norme DMARC et que le courriel échoue à l'authentification, le serveur de réception le rejette.

2. Une fois que vous avez mis en place le DMARC, votre courrier électronique est en sécurité pour toujours

DMARC est l'un des protocoles d'authentification des e-mails les plus avancés, mais cela ne signifie pas qu'il soit complètement autonome. Vous devez surveiller régulièrement vos rapports DMARC pour vous assurer que les e-mails provenant de sources autorisées ne sont pas rejetés. Plus important encore, vous devez vérifier si des expéditeurs non autorisés abusent de votre domaine. Si vous constatez qu'une adresse IP tente à plusieurs reprises d'usurper votre courriel, vous devez prendre des mesures immédiates pour la mettre sur la liste noire ou la supprimer.

3. La DMARC va réduire la délivrabilité de mon courrier électronique

Lorsque vous créez le DMARC, il est important de fixer d'abord votre politique à p=none. Cela signifie que tous vos courriers électroniques seront toujours délivrés, mais vous recevrez des rapports de la DMARC indiquant si l'authentification a réussi ou échoué. Si, pendant cette période de surveillance, vous constatez que vos propres courriels ne sont pas conformes aux normes de la DMARC, vous pouvez prendre des mesures pour résoudre les problèmes. Une fois que tous vos courriels autorisés sont validés correctement, vous pouvez appliquer le DMARC avec une politique de p=quarantaine ou de p=rejet.

4. Je n'ai pas besoin d'appliquer le DMARC (p=none est suffisant)

Lorsque vous créez le DMARC sans l'appliquer (politique de p=none), tous les courriels de votre domaine, y compris ceux qui échouent au DMARC, sont livrés. Vous recevrez les rapports de DMARC mais ne protégerez pas votre domaine contre les tentatives d'usurpation. Après la période de surveillance initiale (expliquée ci-dessus), il est absolument nécessaire de définir votre politique de p=quarantaine ou de p=rejet et d'appliquer le DMARC.

5. Seules les grandes marques ont besoin du DMARC

De nombreuses petites entreprises pensent que seules les marques les plus importantes et les plus connues ont besoin d'une protection DMARC. En réalité, les cybercriminels utiliseront n'importe quel domaine d'entreprise pour lancer une attaque par usurpation. De nombreuses petites entreprises ne disposent généralement pas d'équipes spécialisées dans la cybersécurité, ce qui permet aux attaquants de cibler encore plus facilement les petites et moyennes organisations. N'oubliez pas que toute organisation qui possède un nom de domaine a besoin d'une protection DMARC !

6. Les rapports du DMARC sont faciles à lire

De nombreuses organisations mettent en œuvre le protocole DMARC et envoient les rapports dans leur propre boîte aux lettres électronique. Le problème est que les rapports DMARC se présentent sous la forme d'un fichier XML, qui peut être très difficile à lire si vous n'êtes pas familier avec ce format. L'utilisation d'une plateforme DMARC dédiée peut non seulement faciliter votre processus de configuration, mais PowerDMARC peut convertir vos fichiers XML complexes en rapports faciles à lire avec des graphiques, des tableaux et des statistiques détaillées.

 

Le courrier électronique est souvent le premier choix d'un cybercriminel au moment de son lancement, car il est si facile à exploiter. Contrairement aux attaques par force brute qui sont lourdes de conséquences sur la puissance de traitement, ou aux méthodes plus sophistiquées qui requièrent un haut niveau de compétence, l'usurpation de domaine peut être aussi facile que d'écrire un courriel en se faisant passer pour quelqu'un d'autre. Dans de nombreux cas, ce "quelqu'un d'autre" est une importante plate-forme de services logiciels sur laquelle les gens comptent pour faire leur travail.

C'est ce qui s'est passé entre le 15 et le 30 avril 2020, lorsque nos analystes de la sécurité à PowerDMARC ont découvert une nouvelle vague d'e-mails de phishing ciblant les principales compagnies d'assurance du Moyen-Orient. Cette attaque n'est qu'une parmi d'autres dans la récente augmentation des cas de phishing et de spoofing lors de la crise Covid-19. Dès février 2020, une autre grande arnaque de phishing est allée jusqu'à se faire passer pour l'Organisation mondiale de la santé, en envoyant des courriels à des milliers de personnes pour leur demander de faire des dons pour lutter contre le coronavirus.

Dans cette récente série d'incidents, les utilisateurs du service Office 365 de Microsoft ont reçu ce qui semblait être des courriels de mise à jour de routine concernant le statut de leurs comptes d'utilisateur. Ces courriels provenaient des domaines de leur propre organisation et demandaient aux utilisateurs de réinitialiser leur mot de passe ou de cliquer sur des liens pour consulter les notifications en attente.

Nous avons dressé une liste de certains des titres de courriels dont nous avons observé l'utilisation :

  • Activité de connexion inhabituelle sur un compte Microsoft
  • Vous avez (3) messages en attente de livraison sur votre portail e-Mail [email protected]* !
  • [email protected] Vous avez des messages UNSYNC en attente de Microsoft Office
  • Notification sommaire de réactivation pour [email protected]

*les détails du compte ont été modifiés pour respecter la vie privée des utilisateurs

Vous pouvez également voir un exemple d'en-tête de courrier utilisé dans un courriel usurpé envoyé à une compagnie d'assurance :

Reçu : de [...malicious_ip] (helo= domaine_malveillant)

id 1jK7RC-000uju-6x

pour [email protected] ; Thu, 02 Apr 2020 23:31:46 +0200

DKIM-Signature : v=1 ; a=rsa-sha256 ; q=dns/txt ; c=relaxed/relaxed ;

Reçu : de [xxxx] (port=58502 helo=xxxxx)

par domaine_malveillant avec l'esmtpsa (TLSv1.2:ECDHE-RSA-AES2 56-GCM-SHA384:256)

De : "Microsoft account team" 

Pour : [email protected]

Sujet : Notification de Microsoft Office pour [email protected] le 4/1/2020 23:46

Date : 2 avr 2020 22:31:45 +0100

Message-ID: <[email protected]>

Version MIME : 1.0

Type de contenu : text/html ;

charset="utf-8″

Transfert de contenu - encodage : entre guillemets

X-AntiAbuse : Cet en-tête a été ajouté pour suivre les abus, veuillez l'inclure avec tout rapport d'abus

X-AntiAbuse : Nom d'hôte principal - domaine_malveillant

X-AntiAbuse : Domaine d'origine - domaine.com

X-AntiAbuse : UID/GID de l'auteur/appelant - [47 12] / [47 12]

X-AntiAbuse : Adresse de l'expéditeur Domaine - domain.com

X-Get-Message-Sender-Via : domaine_malveillant: authenticated_id : [email protected]_malveillant

X-Authenticated-Sender : malicious_domain : [email protected]_domain

X-Source : 

X-Source-Args : 

X-Source-Dir : 

Reçu-SPF : échec ( le domaine du domaine .com ne désigne pas adresse_ip_malveillante comme expéditeur autorisé) client-ip= adresse_ip_malveillante ; enveloppe à partir de=[email protected]; helo=domaine_malveillant;

X-SPF-Résultat : le domaine de domain.com ne désigne pas adresse_ip_malveillante en tant qu'expéditeur autorisé

X-Sender-Warning : La recherche inverse du DNS a échoué pour adresse_ip_malveillante (échec)

X-DKIM-Statut : aucun / / domaine.com / / /

X-DKIM-Statut : passer / / domaine_malveillant / domaine_malveillant / / par défaut

 

Notre centre des opérations de sécurité a tracé les liens des courriels vers les URL de phishing qui visaient les utilisateurs de Microsoft Office 365. Les URL ont été redirigées vers des sites compromis situés à différents endroits dans le monde.

En regardant simplement les titres de ces courriels, il serait impossible de dire qu'ils ont été envoyés par quelqu'un qui usurpe le domaine de votre organisation. Nous sommes habitués à recevoir un flux constant de courriels relatifs à notre travail ou à nos comptes qui nous incitent à nous connecter à divers services en ligne, comme Office 365. L'usurpation de domaine en profite pour rendre les faux courriels malveillants impossibles à distinguer des vrais. Il n'y a pratiquement aucun moyen de savoir, sans une analyse approfondie du courrier électronique, s'il provient d'une source fiable. Et avec les dizaines de courriels qui arrivent chaque jour, personne n'a le temps de les examiner tous avec attention. La seule solution serait d'utiliser un mécanisme d'authentification qui vérifierait tous les courriels envoyés depuis votre domaine, et ne bloquerait que ceux qui ont été envoyés par quelqu'un qui l'a envoyé sans autorisation.

Ce mécanisme d'authentification est appelé DMARC. Et en tant que l'un des principaux fournisseurs de solutions de sécurité du courrier électronique dans le monde, nous, à PowerDMARC, nous nous sommes donné pour mission de vous faire comprendre l'importance de protéger le domaine de votre organisation. Pas seulement pour vous, mais pour tous ceux qui vous font confiance et dépendent de vous pour leur envoyer des courriels sûrs et fiables dans leur boîte de réception, à chaque fois.

Vous pouvez lire les risques de l'usurpation d'identité ici : https://powerdmarc.com/stop-email-spoofing/

Découvrez comment protéger votre domaine contre l'usurpation d'identité et renforcer votre marque ici : https://powerdmarc.com/what-is-dmarc/