Table des matières
Qu’est-ce que DMARC ?
DMARC (Domain-based Message Authentication, Reporting and Conformance) est une norme qui permet de surveiller les problèmes liés à l’authentification des emails et à l’usage abusif des noms de domaine.
L’objectif est de lutter contre le spam et le phishing (cf. usurpation d’identité). DMARC utilise les systèmes d’authentification SPF et DKIM pour appliquer en cas d’échec une politique (policy) de sécurité et d’avertir le propriétaire du message via un mécanisme de retour d’information et un monitoring de délivrabilité.
DMARC s’assure aussi de la cohérence et de la légitimité des noms de domaines utilisés pour envoyer le message (voir plus loin pour plus de détails à ce sujet).
Contexte et enjeux
En 2018, 75% des entreprises ont subi au moins une attaque de phishing au cours des deux dernières années.
Un constat alarmant
En 2018, selon une étude réalisée par ProofPoint (Leader de la sécurisation des flux emails dans les grandes entreprises) sur la fraude par e-mail, 75% des entreprises ont subi au moins une attaque de phishing au cours des deux dernières années. Ces attaques de phishing sont dirigées à la fois contre les employés de ces entreprises, et contre leurs clients.
Il ne faut pas oublier que le canal email reste la principale source de spam et d’usurpation d’identité dans le monde. Le protocole SMTP (Simple Mail Transfer Protocol – protocole par lequel transite vos emails), conçu dans les années 80, soit 9 ans avant le web, n’a pas été élaboré avec des normes de sécurité forte. Il est facile pour une personne mal intentionnée de se faire passer pour celui qu’il n’est pas.
Mise en place de systèmes d’authentification
Pour sécuriser un peu plus le canal email, tous les acteurs du marché ont mis successivement en place des normes d’authentification – nous parlons ici de SPF et DKIM – dont l’objectif est de protéger au maximum les bons expéditeurs et de refuser les emails détectés comme frauduleux ou illégitimes.
Malheureusement SPF et DKIM ont chacun leur limite et c’est en 2015 que DMARC (Domain-based Message Authentication, Reporting and Conformance) apparaît afinde réduire ce volume de spam et d’emails frauduleux en fournissant aux expéditeurs d’emails des rapports sur l’utilisation de leurs domaines et de leur permettre d’appliquer une règle de sécurité en cas d’échec de SPF et DKIM.
Même si l’arrivée de DMARC permet d’identifier ces sources illégitimes, son déploiement n’est malheureusement pas encore une priorité pour beaucoup d’entreprises.
Pourquoi ce guide ?
Nous avons réalisé une étude sur le déploiement de DMARC chez les entreprises du CAC40 et du TOP 100 E-commerce français et nous avons constaté qu’une minorité d’entreprises n’avaient toujours pas déployé DMARC sur leur domaine principal.
Il ne faut pas oublier que le canal email reste la principale source de spam et d’usurpation d’identité dans le monde. Le protocole SMTP (Simple Mail Transfer Protocol – protocole par lequel transite vos emails), conçu dans les années 80, soit 9 ans avant le web, n’a pas été élaboré avec des normes de sécurité forte. Il est facile pour une personne mal intentionnée de se faire passer pour celui qu’il n’est pas.
L’initiative de ce guide pour nous est triple :
- Prendre conscience qu’aucune société n’est à l’abri d’une tentative de phishing
- Prendre conscience de l’utilité d’implémenter DMARC au plus vite sur toutes les infrastructures de routage afin d’identifier tout le trafic de vos domaines
- Exploiter les données transmises par les différents rapports DMARC afin de réduire les emails frauduleux.
Objectifs
Compte-tenu du risque majeur pour la sécurité de son écosystème, le déploiement de DMARC sur tous les domaines d’envoi de l’entreprise devient un objectif majeur. Ce déploiement permettrait de :
- Minimiser les risques de faux positifs (cf. emails considérés à tort comme du spam ou du phishing par les filtres Antis-Spam ou par vos clients) grâce à la validation des systèmes d’authentifications SPF/DKIM et de la conformité de DMARC.
- Récupérer des rapports d’authentification détaillés pour identifier le trafic illégitime d’une part et le trafic légitime mal authentifié d’autre part.
- Faire valoir la politique de l’expéditeur auprès des destinataires (via la politique de sécurité définie dans la policy DMARC).
- Réduire la livraison des emails frauduleux auprès des employés et des clients/fournisseurs.
Il ne faut pas oublier également les multiples enjeux de l’entreprise :
- Protéger leurs noms de domaine d’une utilisation frauduleuse.
- Protéger leurs employés de faux emails venant soi-disant de la direction.
- Protéger leurs clients/fournisseurs de vols d’informations personnelles.
- Protéger leur réputation et identité.
Lutter contre le phishing avec DMARC
Le principal intérêt de DMARC reste bien entendu de lutter contre le phishing. Son implémentation vous permettra rapidement de savoir qui utilise à votre insu votre nom de domaine.
L’action ayant le plus d’impact va être le durcissement de la policy. Après une période de monitoring, d’analyse et de mise en conformité, vous passerez votre policy de “none” (aucune action) à “quarantine” (mise en spam) pour finir à “reject” (refus de l’email non conforme). Ce passage à “reject” vous permettra de réduire considérablement les risques d’usurpation d’identité sur vos domaines et sous-domaines.
Pour arriver à ce résultat, il est important de travailler avec tous vos partenaires, afin de mettre en conformité l’ensemble de vos domaines et flux emails. Une fois la « policy » passée à « reject », tous les emails utilisant votre nom de domaine et ne respectant pas les règles de conformité DMARC seront refusés par les messageries.
Attention toutefois, DMARC a une limite d’exploitation, seuls les FAI / Webmails/ Filtres Anti-Spam sachant interpréter DMARC seront capables d’appliquer la “policy” (entre autres Gmail, Microsoft, Yahoo, La Poste, …).
Quelles sont les fonctionnalités DMARC ?
Nous avons déjà, brièvement, introduit DMARC au début de ce guide. Mais dans le détail, quelles sont les possibilités offertes par DMARC ?
Déclaration d’une policy
La première fonctionnalité est l’application d’une politique de sécurité.
Pour que DMARC soit efficace, une politique de sécurité doit être définie en amont par l’administrateur du domaine. En cas d’échec de SPF et/ou DKIM, cette politique sera appliquée par l’organisme recevant l’email. Il existe 3 niveaux de paramétrage :
- «none» : rien de spécial ne se passe, le serveur de réception du message fait comme d’habitude, comme si aucun enregistrement DMARC n’était présent. Seuls les feedbacks sont envoyés à l’exéditeur.
- «quarantine» : cette mention demande au serveur de réception d’inspecter l’email avec un plus grand niveau d’attention que d’habitude. En cas d’échec, l’email devra être mis en courrier indésirable.
- «reject» : cette policy demande au serveur de réception de rejeter l’email qui lui est adressé s’il ne respecte pas SPF, DKIM ou les règles d’alignement des domaines.
Pour continuer la petite étude que nous avons mené sur le déploiement de DMARC chez les entreprises du CAC40 et du TOP 100 E-commerce, nous avons regardé quelle politique de sécurité DMARC est appliqué au domaine principal de chaque entreprise :
Encore aujourd’hui, peu d’entreprises ont franchi le cap et ont passé leur politique de sécurité en “reject”.
Analyse des rapports DMARC
La seconde fonctionnalité de DMARC permet de recevoir des rapports détaillés concernant les résultats des authentifications SPF et DKIM.
Ces rapports permettent aux propriétaires des domaines de suivre et d’analyser l’activité légitime et illégitime générée par le trafic email de leurs domaines. Cette mécanique offre donc la possibilité d’intervenir rapidement en cas d’incident majeur comme une attaque de phishing ou perte d’authentification sur une source légitime.
Les rapports sont envoyés par email au format XML, mais de nombreux outils de monitoring DMARC permettent d’analyse simplement les résultats et de générer des alertes automatiques.
DMARC… C’est cool ! BIMI… C’est mieux ?
Toujours dans l’optique d’aller plus loin et de protéger les marques et les utilisateurs de messagerie, un nouveau standard a été créé et est apparu il y a quelques mois, il s’appelle BIMI !
L’intérêt de BIMI est d’afficher un logo de la marque dans la boîte aux lettres du destinataire … si celui-ci a une bonne réputation !
Le critère le plus important reste néanmoins l’implémentation de DMARC. Celui-ci devra être correctement déployé sur vos domaines avec une politique de sécurité DMARC restrictive à “quarantine” (au minimum) ou à “reject” (fortement conseillé).
Comprenez par-là que vous ne pourrez implémenter BIMI que si DMARC est déjà bien en place. Aujourd’hui, Yahoo (Verizon) & Google (depuis le printemps 2020) sont déjà capables d’interpréter BIMI ! D’autres devraient suivre dans le courant de l’année puis en 2021.
Vous l’aurez compris, BIMI est une sorte de carotte afin d’inciter les marketers à sécuriser leurs flux emails : « Si tu sécurises tes emails, tu auras droit à un beau logo dans mon webmail ! »
Focus sur la notion d’alignement des domaines
Pour rendre conforme l’ensemble des flux emails avec SPF & DKIM, un alignement des domaines est nécessaire. Malheureusement, SPF & DKIM ne se basent pas sur le même domaine. SPF authentifie le domaine “MailFROM” et/ou le domaine “Helo/Ehlo) (non visible de l’utilisateur) alors que DKIM authentifie le domaine “From” (adresse expéditrice).
Alignement SPF
Authentification-Results:mx.google.com;
dkim=pass header.i=@badsender.com header.s=selector2 header.b=S0W1FpEi;
arc=pass (i=1 spf=pass spfdomain=badsender.com dkim=pass dkdomain=badsender.com dmarc=pass fromdomain=badsender.com);
spf=pass (google.com: domain of sfi@badsender.com designates 40.107.5.62 as permitted sender) smtp.mailform=sfi@badsender.com;
dmarc=pass (p=QUARANTINE sp=NONE) header.from=badsender.com
From : “Sébastien Fischer” <sfi@badsender.com>
To: Badsender Deliv Team <*>
Subjet: Alignement DMARC
Date : Tue, 11 Aug 2020 14:18:20 +0000
Exemple n°1 : L’adresse expéditrice (From) est yesreply@badsender.com, l’adresse déclarée dans le MailFRom est yesreply@badsender.com
=> Les domaines sont alignés pour SPF (domaines FROM et MAILFROM sont identiques) la politique d’alignement “strict” doit être paramétrée (cf. aspf=”s”).
Exemple n°2 : L’adresse expéditrice (From) est yesreply@badsender.com, l’adresse déclarée dans le MailFRom est yesreply@emailing.badsender.com
=> Même si le domaine FROM est différent du domaine MAILFROM (pourtant ils font partie de la même infrastructure), il sera considéré aligné en mode “relâché”, mais ce ne sera pas le cas en mode “strict”.
Alignement DKIM
Authentification-Results:mx.google.com;
dkim=pass header.i=@badsender.com header.s=selector2 header.b=S0W1FpEi;
arc=pass (i=1 spf=pass spfdomain=badsender.com dkim=pass dkdomain=badsender.com dmarc=pass fromdomain=badsender.com);
spf=pass (google.com: domain of sfi@badsender.com designates 40.107.5.62 as permitted sender) smtp.mailform=sfi@badsender.com;
dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=badsender.com
From : “Sébastien Fischer” <sfi@badsender.com>
To: Badsender Deliv Team <*>
Subjet: Alignement DMARC
Date : Tue, 11 Aug 2020 14:18:20 +0000
Exemple n°1 : L’adresse expéditrice (From) est yesreply@badsender.com, le tag “d” déclaré dans la clé publique DKIM est [d=badsender.com](http://d%3Dbadsender.com/).
=> Les domaines sont alignés pour DKIM (domaines FROM et « d= » sont identiques) la politique d’alignement “strict” doit être paramétrée (cf. adkim=”s”).
Exemple n°2 : L’adresse expéditrice (From) est yesreply@badsender.com, , le tag “d” déclaré dans la clé publique DKIM est [d=emailing.badsender.com](http://d%3Demailing.badsender.com/).
=> Même si le domaine FROM est différent du domaine déclaré dans “d=” (pourtant ils font partie de la même infrastructure), il sera considéré aligné en mode “relâché”, ce qui ne sera pas le cas en mode “strict”.
Pour une sécurisation maximale de l’infrastructure, une politique d’alignement “strict” est fortement conseillée.
Comment déployer DMARC ?
Prendre son temps : Le déploiement de DMARC et la mise à niveau de la policy doivent se faire au fur à mesure.
Vous ne pourrez pas directement appliquer une policy “reject” du jour au lendemain sans avoir un impact désastreux sur des pans entiers de votre trafic légitime qui seraient mal paramétrés.
Il faut donc prendre le temps d’analyser les rapports reçus afin de corriger l’ensemble des problèmes touchant le trafic légitime. Une fois que l’ensemble du trafic légitime est correctement authentifié et respecte les règles d’alignement des domaines, vous pourrez progressivement appliquer une politique de sécurité de plus en plus restrictive “None” puis “Quarantine” puis “Reject”.
Vous aurez de toute façon la possibilité de paramétrer les policies restrictives (quarantine & reject) de DMARC qu’à une portion du trafic pendant ces périodes de transition avant de les appliquer à 100%.
Pensez aux attaques n’utilisant pas vos domaines : les domaines Look-a-like
DMARC n’est efficace contre les attaques de phishing que si celles-ci utilisent vos noms de domaines sur lesquels est configuré DMARC. Mais il ne faut surtout pas oublier que nos “ami-e-s” les spammeurs et les pirates sont souvent… très bon dans leurs activités… surtout quand il s’agit de tromper des tiers. Imaginons une attaque de phishing faite avec le domaine “mail.pay-pal.fr”. Ce domaine n’appartenant pas à Paypal, celui-ci n’aura aucun moyen, via DMARC, d’être alerté de cette attaque.
Il est donc important d’utiliser d’autres techniques d’analyse, reposant par exemple sur le monitoring en masse des domaines proches du vôtre afin de vérifier s’ils apparaissent dans des listes noires ou s’ils sont visibles par des réseaux de spamtraps.
Evaluer la taille et complexité de l’infrastructure
Cette première étape doit avoir lieu avant la configuration initiale de DMARC et de la solution de monitoring qui sera utilisée pour l’implémentation et le suivi.
L’objectif est de lister l’ensemble des domaines à monitorer et pour lesquels vous désirez utiliser une policy “reject”.
N’OUBLIEZ PAS : Vos domaines sont parfois utilisés par des partenaires pour envoyer des emails. Ces derniers devront également paramétrer DMARC et appliquer la même policy que vous afin de protéger tous les flux d’emails qui vous concernent.
1ère analyse des données collectives
Lorsque DMARC sera implémenté et opérationnel sur tous vos domaines (avec un policy « none » dans un premier temps), les rapports arriveront très rapidement. Ceux-ci devront être étudiés afin de disposer d’une première base pour évaluer la situation et permettre de répondre aux questions suivantes :
- Quelles sont les différentes sources d’emails pour vos domaines ?
- Quel est le niveau de conformité des sources en question ?
- Quelles sources sont identifiées comme légitimes ?
- Dans les sources non-identifiées comme légitimes, quelles sont celles qui proviennent de partenaires et quelles sont celles qui proviennent d’attaques ?
- Quels sont les problèmes majeurs ? Manque d’authentification, problèmes d’alignement, …
En cas d’identification de problèmes graves (exemple : une IP inconnue se situant dans un pays d’Asie et utilisant votre adresse expéditrice), vous aurez la possibilité d’agir immédiatement en contactant l’hébergeur de l’IP de cette usurpation mais aussi d’alerter les organismes de lutte contre le spam (comme Signal-Spam).
Identification des chantiers prioritaires
En fonction de l’analyse de la complexité de l’infrastructure à sécuriser, des premières données collectées et potentiellement de l’ampleur des dégâts causée par les domaines “look-a-like », vous pourrez alors définir un plan précis sur le paramétrage de DMARC qu’il vous faudra déployer.
- Définir une politique de sécurité à “quarantine” ou “reject”.
- Définir un alignement “strict” ou “relâché” (ou souple).
- Définir la stratégie pour les partenaires utilisant vos domaines : devez-vous les basculer sur d’autres domaines ou leur demander d’utiliser le même paramétrage DMARC que vous ?
- Définir quelles actions réaliser en cas de détection de phishing.
Mise en conformité
La mise en conformité est l’action de rendre votre trafic email compatible avec DMARC (authentification et alignement des domaines principalement). Celle-ci ne se fera pas en un jour, elle risque même de vous prendre plusieurs semaines voire plusieurs mois (tout va dépendre de la complexité de l’infrastructure et des procédures internes).
Durant cette période de transition, vous aurez la tâche d’analyser, via la collecte des données des rapports, d’identifier tout trafic légitime n’ayant pas une conformité suffisante pour un passage à la “policy reject”. Vous devrez alors contacter les différentes sources légitimes afin de les accompagner dans les changements nécessaires. Une fois les corrections apportées, vous devrez les vérifier et vous assurer que le trafic est devenu conforme à DMARC. Si ce n’est pas le cas, il faudra continuer à échanger avec les différentes sources jusqu’à leur mise en conformité.
Déploiement de la policy=reject
Dès que la conformité sera atteinte, il faudra alors passer progressivement votre “policy” à “reject”. L’avantage de DMARC est que vous allez pouvoir définir un pourcentage de trafic non-conforme (et non authentifié) sur lequel sera appliqué la policy DMARC.
Exemple n°1 : Seulement 10% du trafic qui ne sera pas conforme avec le domaine badsender.com sera mis en courrier indésirable.
v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@dmarc.250ok.net; ruf=mailto:dmarc_fr@dmarc.250ok.net; fo=1; adkim=r; aspf=r; rf=afrf; pct=10; sp=none;
Exemple n°2 : 100% du trafic qui ne sera pas conforme avec le domaine badsender.com sera mis en courrier indésirable.
v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@dmarc.250ok.net; ruf=mailto:dmarc_fr@dmarc.250ok.net; fo=1; adkim=r; aspf=r; rf=afrf; pct=100; sp=none;
Ainsi, la mise en place d’un plan de déploiement sur plusieurs semaines/mois est souhaitable (voir indispensable) pour s’assurer que tout est bien conforme :
- 1ème à 2ème semaine : paramétrage à «quarantine» à 5%
- 3ème à 4ème semaine : paramétrage à «quarantine» à 25%
- 5ème à 6ème semaine : paramétrage à «quarantine» à 50%
- 7ème à 8ème semaine : paramétrage à «quarantine» à 100%
- 9ème à 10ème semaine : paramétrage à «reject» à 5%
- 11ème à 12ème semaine : paramétrage à «reject» à 25%
- 13ème à 14ème semaine : paramétrage à «reject» à 50%
Déploiement de BIMI
Une fois la “policy reject” appliquée à 100%, le paramétrage de BIMI pourra être mis en place sur vos serveurs DNS (même si en théorie, dès le passage en “quarantine”, BIMI pourra être déployé).
La seule vérification qui devra être réalisée est que le logo s’affiche correctement dans les messageries supportant BIMI à ce moment-là (Yahoo ! et Gmail à date).
Maintenance et monitoring
Après l’adoption de la politique de sécurité “reject”, vous devrez néanmoins continuer de surveiller pour au moins 6 mois d’éventuels soucis de conformité (et les corriger si nécessaire), sans oublier bien sûr de continuer le suivi des attaques (qui lui sera permanent car les spammeurs ne prennent jamais de vacances).
Question fréquemment posées sur DMARC
Est-ce que les rapports DMARC remontent à l’enregistrement DMARC du domaine racine ?
Si dans la logique de DMARC il y a une logique d’héritage du domaine racine vers les sous-domaines, l’inverse n’est pas vrai.
Par exemples, si le domaine badsender.com possède un enregistrement de ce type :
v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com; ruf=mailto:dmarc@badsender.com; fo=1;Mais que le sous-domaine email.badsender.com possède un enregistrement DMARC de ce type :
v=DMARC1; p=reject; rua=mailto:dmarc-subdomain@badsender.com; ruf=mailto:dmarc-subdomain@badsender.com; fo=1;Alors les rapports DMARC générés pour le sous-domaine email.badsender.com arriveront à l’adresse dmarc-subdomain@badsender.com et non à l’adresse dmarc@badsender.com.
Par contre, un sous-domaine qui n’aurait pas son propre enregistrement DMARC verra ses rapports envoyés vers dmarc@badsender.com.
