Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.
De nos jours, les emails sont une forme de communication massivement utilisée. Par conséquent, ils sont aussi massivement utilisés comme vecteur d’attaque. 75 % des organisations dans le monde auraient subi du phishing en 2020, et jusqu’à 95 % des attaques d’ingénierie sociale pourraient être délivrées par email. Bien sûr, il n’y a pas de solution miracle pour empêcher toutes ces attaques, mais il existe quelques mécanismes qui peuvent aider à empêcher des personnes malveillantes de se faire passer pour vous par email. Ces mécanismes ne nécessitent que quelques entrées DNS (sauf si vous gérez votre propre serveur de messagerie, ce que nous ne couvrirons pas ici). Encore mieux, configurer ces entrées DNS améliorera également la délivrabilité de vos emails, car ils seront moins susceptibles d’être signalés comme spam.
Sender Policy Framework (SPF)#
En termes simples, SPF permet de lister les serveurs autorisés à envoyer des emails en utilisant un nom de domaine. Lorsqu’un email est envoyé, le serveur destinataire interrogera l’entrée SPF du domaine de l’expéditeur (récupéré depuis le envelope-from) et la comparera avec le serveur depuis lequel il reçoit l’email. Si cela ne correspond pas, l’email pourrait être signalé ou rejeté (en fin de compte, c’est le serveur destinataire qui décide de ce qu’il veut faire).
La configuration est assez simple, car il suffit d’ajouter une entrée TXT à votre configuration DNS. Par exemple, ce qui suit (contenu d’une entrée DNS TXT) autorise tous les emails provenant de 1.1.1.1, 192.168.0.1/8, et l’enregistrement A de example.com, et indique que les autres serveurs ne sont pas autorisés à envoyer des emails pour ce nom de domaine. Notez qu’une règle ne peut pas avoir plus de 10 lookups (par exemple, la résolution d’entrées a).
v=spf1 ip4:1.1.1.1 ip4:192.168.0.1/8 a:example.com -all
En plus d’autoriser les adresses et plages IP v4, les noms de domaine, de nombreuses autres options telles que l’IP v6 et MX sont disponibles.
Au lieu d’utiliser -all pour faire échouer la vérification SPF si les emails ne sont pas envoyés depuis un serveur autorisé, ~all pourrait être utilisé pour produire un soft-fail, ?all pour indiquer que rien ne peut être dit sur les adresses non explicitement marquées. +all pourrait aussi être utilisé pour signaler que tout serveur est autorisé à envoyer des emails au nom de notre nom de domaine.
Tout cela est bien, mais SPF n’est pas parfait. Disons que vous avez configuré votre boîte mail email@example.com pour transférer automatiquement les emails vers email@example.net. Si j’envoie un email depuis une IP non autorisée par SPF à email@example.com, email@example.net ne verra pas que le SPF original est invalide.
Domain Keys Identified Mail (DKIM)#
Nous avons mentionné dans la partie précédente que SPF seul ne suffit pas à garantir l’authentification des emails pour des raisons telles que le fait d’être ignoré lorsque les emails sont transférés. DKIM est une autre option pour authentifier les emails, et il a l’avantage de ne pas être perdu lorsque les emails sont transférés.
Le fonctionnement de DKIM est assez simple. Le domaine de l’expéditeur doit avoir une entrée DNS (vous devrez vous référer à votre fournisseur d’hébergement de messagerie pour voir comment il attend que les choses soient configurées) avec une clé publique. La clé privée correspondante sera utilisée pour signer les emails envoyés. Lorsqu’un email est reçu, le serveur destinataire récupérera la clé publique depuis les enregistrements DNS du nom de domaine utilisé par l’expéditeur, et vérifiera que la signature est correcte.
Regardons un exemple. Ce qui suit fait partie de l’en-tête d’un email reçu qui a été envoyé depuis un serveur utilisant DKIM.
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=haveibeenpwned.com;
h=content-type:from:mime-version:to:subject:list-unsubscribe;
s=s1; bh=XnUR5B4bb9/iGnKkBNkjeCE5H9eTJoZZhuc28eSwj/Y=; b=CwFiOJD
nrpW8docGIVBd/A+bPcOjmmVg0letY5gf43QQTSD3V1bJ4wkt3l1LSBT1uDqhkzK
QxBQttzZIxnmcYY5E/sP/tj1UseO0KEBq/s6Mt1X5AHtvDScaIJgoTfeay3sIU+O
6Edb/G0uCDhSW6JY8gAnXgVKFcooGBp43+yk=Nous pouvons voir plusieurs champs :
a=rsa-sha256nous donne les algorithmes utilisés pour signer le messagec=relaxed/relaxeddéfinit la posture de canonicalisation du domaine expéditeur. Ici, la configuration effectuera un certain reformatage avant de hacher le message, comme mettre les noms d’en-têtes en minuscules, supprimer les espaces en fin de ligne et autres. Une autre option serait d’utiliserstrictau lieu derelaxed, ce qui exigerait que le contenu soit 100 % identique, sous peine de voir la validation échouer. Par exemple,c=relaxed/strictautoriserait le reformatage des en-têtes de l’email, mais exigerait que le corps reste strictement inchangé. L’optionrelaxedest pratique pour éviter les échecs inutiles, car les serveurs de messagerie peuvent parfois reformater les en-têtes pendant le traitementd=haveibeenpowned.comnous indique pour quel domaine la signature a été faiteh=[...]liste les en-têtes qui étaient présents lorsque le message a été signé (et qui ont donc été inclus dans le hash)s=s1indique que le sélecteur pour la clé publique du domaine ests1. Il sera expliqué plus tardbh=[...]contient le hash en base64 du corps canonicalisé du message. Notez qu’une optionlpourrait être fournie dans les paramètres, pour spécifier la longueur maximale du corps utilisée pour calculer le hash. Cela signifie que du contenu pourrait être ajouté après la longueurlet le DKIM serait toujours valideb=[...]contient la signature en base64
Lorsque le serveur destinataire reçoit le message, il essaiera de voir si la signature fournie dans b est valide. Pour cela, il effectuera une requête DNS pour obtenir la clé du domaine qui a envoyé l’email, et recevra ce qui suit :
user@Host ~ % dig TXT s1._domainkey.haveibeenpwned.com
[...]
;; ANSWER SECTION:
s1._domainkey.haveibeenpwned.com. 300 IN CNAME s1.domainkey.u3489673.wl174.sendgrid.net.
s1.domainkey.u3489673.wl174.sendgrid.net. 474 IN TXT "k=rsa; t=s; p=[key]"Vous remarquerez le s1 dans la requête dig. C’est la valeur du sélecteur qui se trouvait dans le champ s de l’en-tête DKIM de l’email. Les entrées DKIM seront toujours stockées pour [sélecteur]._domainkey.domain.tld.
Une fois qu’il a obtenu la clé fournie dans la réponse DNS, le serveur destinataire vérifiera que la signature est valide et correspond au contenu. Si ce n’est pas le cas, la vérification échoue. Sinon, quelque chose ressemblant à ce qui suit sera ajouté aux en-têtes de l’email.
Authentication-Results: mailin007.protonmail.ch; dkim=pass (1024-bit key)
header.d=haveibeenpwned.com header.i=@haveibeenpwned.com header.b="EwFk1JDn"Domain-based Message Authentication, Reporting and Conformance (DMARC)#
Si vous avez suivi tout jusqu’ici, l’adresse de votre serveur de messagerie fait maintenant partie d’une entrée SPF, et vos messages sont signés grâce à DKIM. C’est bien, mais que se passe-t-il si un attaquant décide de forger un message et de l’envoyer depuis son serveur (sans inclure de DKIM) ? Dans ce scénario, l’email sera probablement accepté par le serveur destinataire et finira dans la boîte du destinataire.
C’est là que DMARC entre en jeu. Ce mécanisme a les avantages suivants :
- Il permet de donner des directives aux serveurs de messagerie destinataires sur la façon de traiter les emails échouant aux vérifications SPF ou DKIM (même s’il n’y a aucune obligation pour les serveurs de les appliquer)
- Il permet des options supplémentaires pour gérer SPF avec les sous-domaines (notez que les serveurs correspondant à ~all seront marqués comme un échec)
- Il permet d’obtenir des retours sur les emails envoyés en utilisant notre nom de domaine, ce qui est pratique pour le débogage ou la détection d’activité malveillante
- DMARC vérifie que l’en-tête Mailfrom du RFC5321 et l’en-tête Mailfrom du RFC5322 correspondent pour combler une faiblesse de DMARC et SPF
Comme pour les deux autres éléments, DMARC est configuré via un seul champ DNS TXT qui sera situé à _dmarc.domain.com. L’extrait suivant montre un exemple de configuration.
v=DMARC1; p=reject; sp=reject; ruf=mailto:security@example.com; aspf=s; adkim=s; fo=1;Examinons les différents champs :
v(obligatoire) est la version DMARC (toujoursDMARC1)p(obligatoire) définit la politique pour le domaine envoyé depuisexample.comdans le cas où la vérification SPF ou DKIM échoue. S’il est défini àreject, rien ne finira dans les boîtes mail des utilisateurs,quarantineenverra les emails dans le spam, etnonene fera rienpofait la même chose quepmais pour les sous-domainesrufpermet de définir une adresse email qui recevra des rapports forensiques lorsque des emails échouent à la validation.ruaest une option similaire qui enverra des rapports agrégés quotidiens (moins détaillés) de l’activité impliquant notre domaine (par exemple, si vous envoyez des emails à Gmail pendant la journée, Gmail vous enverra un rapport agrégeant les différentes opérations à la fin de la journée). Notez que certains serveurs n’enverront pas de rapportsaspfpermet de définir une politique supplémentaire pour le SPF. Elle peut être stricte (s) ou souple (r). Dans le cas où vous avez un enregistrement SPF pourexample.com, un email envoyé depuismail@test.example.coméchouera à la validation SPF si la politique est stricte, sinon il réussira si la politique est souple.adkimfait la même chose queaspfmais pour DKIMfopermet de définir le niveau de journalisation lorsque des emails échouent à la validation.0(par défaut) enverra des rapports si SPF et DKIM échouent tous les deux,1enverra des rapports si l’un des deux échoue,denverra un email si DKIM échoue, etssi c’est le SPF. Notez qu’il est possible de combiner les règles, par exemplefo=0:d;.
Outils utiles#
Voici une liste d’outils que je considère utiles pour la configuration des entrées DNS de messagerie.
- mxtoolbox.com - Divers outils en ligne permettant de vérifier votre configuration de messagerie
- mail-tester.com - attribuera une note aux emails envoyés depuis votre serveur de messagerie, et vous dira si des choses ne fonctionnent pas ou devraient être améliorées
- whatsmydns.net - permet de vérifier si les entrées DNS sont correctement propagées