logo piwik

Réseau - Web - GNU/Linux

2018 14 février

Prévenir l'usurpation d'identité avec DKIM - Debian 9.0 Stretch

Rédigé par Marc GUILLAUME | 1 commentaire
Article précédent Mail façon FAI - Debian 9.0 Stretch Article suivant

Traduction de la page : https://workaround.org/ispmail/stretch/prevent-spoofing-dkim/

L'usurpation d'identité d'un expéditeur consiste à prétendre avoir le contrôle sur l'adresse mail de quelqu'un d'autre. C'est un problème très courant, en particulier avec l'hameçonnage (phishing en anglais). Des escrocs envoient fréquemment des mails avec une adresse d'expéditeur du type quelquechose@paypal.com dans l'espoir que le destinataire tombe dans le panneau et leur fasse confiance. En fait SMTP ne s'occupe pas de l'adresse d'expéditeur que vous utilisez. De nombreux fournisseurs de mail vous obligent à envoyer des mails uniquement en utilisant votre propre adresse mail. Mais certains ne le font pas. Et les spammeurs et les escrocs bien entendu ne s'en privent pas.

Du coup une nouvelle méthode d'envoi à été conçue, qui ajoute une signature chiffrée aux entêtes du mail, signature qui peut être vérifiée par le destinataire pour vérifier l'authenticité de l'expéditeur et l'intégrité du mail. La signature est créée avec une clé privée qui n'est possédée que par le serveur de mail autorisé à envoyer des mails pour le domaine de l'expéditeur. Elle peut être vérifiée par le destinataire grâce à la clé publique correspondante qu'il peut télécharger depuis la zone DNS du domaine d'expédition. Cela fonctionne de façon très similaire aux signatures PGP ou S/MIME, mais juste au niveau d'un domaine. Votre serveur de ocurrier peut signer tous les mails sortants de manière automatique. La méthode utilisée de nos jours est appellée « Domain Keys Identified Mail », soit en initiales DKIM (en français : mail identifié par des clés de domaine).

Prenons un exemple. J'ai envoyé un email depuis GMail vers mon adresse personnelle sur mon propre serveur de mail. Google utilise les signatures DKIM, du coup le mail comporte un entête supplémentaire rajouté par le serveur de mail de Google :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=/FpkZfBuKR0WWcH2fFcr9M4qgX4Z4+/0dX4dpqycK28=;
 b=fZ4Efy1TuXAl1ho2twkEuNiVP8k5GRKqlol/f/dTawaxciAv1bwinkbuTCpK4T3SoL
 ZFhdh/p82MYiIt75V5eGFtSMQfocVIKfsusggj3ZKlwUNvSbB/jd4fn3SKwGjLSyKMT0
 agJFblxF+ydGzRKYzJNPfFYhdQY3YZcMEria87SpqgVgqECCMRvuT10w7KQGIx7AsvDy
 F2coh2TnX400sRidMVF1S/9QhD85dE3xSie3ZdTfWBsP00Y7xWbos7MlSl1MnsVvXPtQ
 7bnNBVdcn1tP9x8IeNKp6qEYoLYzEeLZVp8eLB0F0AoWIgRb348FaIvMF9jYvO/h/cQ+
 YP5Q==

J'ai besoin de la clé publique DKIM de Google pour vérifier cette signature. Celle-ci est disponible dans leur zone DNS sous forme d'un enregistrement TXT qui s'appelle « 20161025._domainkey.google.com ». « 20161025 » est le sélecteur de la clé qui est mentionné dans la signature en tant que s=20161025. Vous pouvez utiliser autant de clés que vous voulez du moment que vous créez une signature avec la clé privée correspondante. La partie » _domainkey » est le sous-domaine standard pour les clés DKIM. Donc récupérons l'enregistrement MX :

dig +short 20161025._domainkey.google.com txt
“k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXNZF1j8sJPDleRjf9SPBNem0ik58kF1ilC1nUgKAttl9v7FX9hXJXPmLNhVtSKVZ8yruaeOZLeIxtgtk1s81zzIE5Mj0AiGn2wlFt4kYfqlDfYe95YLQHjynu4i7vj1Tj” “ksf62btcCbL+3XhbK+oD5PlqYhXHWuzoKoEp5L4lCihgkONvU/oy7NNeE6quqfF/y0YSLwF2WVA2Kd8L6R0Ar2dYT/3wZCFknI7xhvPqh9HNcIWBELGPwtXcsHbX1wvBlCgNQAUcdJrf2YWzAwqmZ564/1ipL1IMk1nafPJk75ktumVNz6ORuIn3jbZWp9rRpnaeI9cu/8KfSKH2EY9QIDAQAB”

Ceci est la clé publique que vous pouvez utiliser pour vérifier la signature. Une vérification automatique peut être effectuée en utilisant l'utilitaire « opendkim-testmsg ». Je peux le lancer et y coller le mail entier incluant les entêtes et le corps du message. Si il n'envoit pas de message d'erreur alors la signature est correcte.

Ça semble bien ? Alors installons ça sur votre domaine de mail.

Création de la paire de clés

Comme expliqué ci-dessus vous avez besoin d'un clé privée pour votre serveur de mail et d'une clé publique qui sera ajoutée à votre zone DNS. Un outil simple pour créer et vérifier les signatures DKIM est contenue dans le jeu d'outils d'OpenDKIM. Un autre outils très utile est dig qui vous permet d'interroger les enregistrements DNS. Il fonctionne comme nslookup avec davantage de souplesse. Installons les deux :

apt install opendkim-tools dnsutils

rspamd a son propre module de signature DKIM intégré qui est activé par défaut. Si vous placez votre fichier de clé dans /var/lib/rspamd/dkim/ en utilisant une convention de nommage appropriée il l'utilisera automatiquement. Créez le répertoire destiné à contenir la clé :

mkdir /var/lib/rspamd/dkim
chown _rspamd:_rspamd /var/lib/rspamd/dkim

Créez votre paire de clés :

opendkim-genkey -d example.org -s 2018022301

Le sélecteur (-s) que j'ai choisi est 2018022301 car c'est le le jour où je l'ai créé. La première clé (01) le 23 février 2018 (2018-02-23). Cela n'a pas d'importance cependant, vous pouvez utiliser le nom que vous voulez. Si vous êtes paresseux et peu motivé vous pouvez simplement utiliser « dkim » en tant que sélecteur et ensuite économiser un peu de travail en n'ayant pas besoin de mappages DKIM indiquant quelle clé est supposée être utilisé pour chaque domaine. « dkim » est le sélecteur par défaut si vous n'utilisez pas de mappages. Cependant si vous avez besoin de remplacer votre clé par la suite sans invalider les mails déjà envoyés, vous serez en difficulté. Donc je vous recommande de plutôt utiliser des mappages comme cela sera expliqué un peu plus bas. Cela vous donnera davantage de souplesse et est assez facile à faire.

Vous devriez maintenant avoir deux fichiers dans votre répertoire courant :

  • 2018022301.private ➠ la clé privée RSA
  • 2018022301.txt ➠ l'enregistrement DNS

Ajoutez votre enregistrement DNS

Avant de commencer à signer vos mails, vous devez vous assurer que la clé publique est correctement présente dans votre zone DNS pour le domaine pour lequel vous envoyez des mails. Sinon le destinataire sera incapable de vérifier votre signature et pourrait en déduire de manière erronée que le mail est une usurpation d'identité.

Jetez un oeil au fichier 2018022301.txt. Il devrait ressembler à quelque chose de ce genre :

2018022301._domainkey IN TXT ( “v=DKIM1; h=sha256; k=rsa; ”
“p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0n1YM3xVwwkp042w+shwyt2QFrUvumfiwOTAc464kQI1awGw96bgrDuRqWllT8rpI7w39qhwf2qBIGBu45O1EyLvZSD3gbf5Riw2HpvD1UcM6Jk0Ga0ii5NgYSA2Ua2zuSBeXj/1To4bmfvwKqgVTwkND08oLA/zplg38kyIVVRsC2OS4zFGpHeuD3q8fS+im9KIf6Oi62QcKK”
“wgmwpxYq1plagGHhi0+gLO9A6kDeoahh7nRQpqqcn9YwuU6Qy4IOmdhBRjTp4GL/zLLWQqwZXFnMAtDArAFlHpMekNKIppAfzNGIz/bBkj4DkMfo72wfOq+YapDJbnhjQyzSAREwIDAQAB” ) ; —– DKIM key 2018022301 for example.org

Si vous avez votre propre serveur DNS, vous devriez pouvoir y copier ce fichier entier et le placer dans votre zone DNS. Sinon si votre hébergeur vous fournit une interface web pour gérer vos domaines créez un nouvel enregistrement TXT avec comme nom d'hôte « 2018022301._domainkey » et et concaténez toutes les chaînes de caractères situées entre parenthèse en une seule chaîne sans aucune parenthèse, retour à la ligne ou guillemets. Dans mon exemple :

2018022301._domainkey ➠ v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0n1YM3xVwwkp042w+shwyt2QFrUvumfiwOTAc464kQI1awGw96bgrDuRqWllT8rpI7w39qhwf2qBIGBu45O1EyLvZSD3gbf5Riw2HpvD1UcM6Jk0Ga0ii5NgYSA2Ua2zuSBeXj/1To4bmfvwKqgVTwkND08oLA/zplg38kyIVVRsC2OS4zFGpHeuD3q8fS+im9KIf6Oi62QcKKwgmwpxYq1plagGHhi0+gLO9A6kDeoahh7nRQpqqcn9YwuU6Qy4IOmdhBRjTp4GL/zLLWQqwZXFnMAtDArAFlHpMekNKIppAfzNGIz/bBkj4DkMfo72wfOq+YapDJbnhjQyzSAREwIDAQAB

Suivant votre fournisseur d'accès il peut se passer plus ou moins de temps avant que le nouvel enregistrement soit visible sur Internet. Vous pouvez utiliser dig pour le vérifier :

dig +short +trace 2018022301._domainkey.example.org txt

Si vous obtenez l'entrée TXT telle que ci-dessous alors vous êtes prêt pour activer la signature DKIM dans rspamd pour ce domaine :

TXT “v=DKIM1; h=sha256; k=rsa;\194\160p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0n1YM3xVwwkp042w+shwyt2QFrUvumfiwOTAc464kQI1awGw96bgrDuRqWllT8rpI7w39qhwf2qBIGBu45O1EyLvZSD3gbf5Riw2HpvD1UcM6Jk0Ga0ii5NgYSA2Ua2zuSBeXj/1To4bmfvwKqgVTwkND08oLA/zplg38kyIVVRsC2OS4zFGpH” “euD3q8fS+im9KIf6Oi62QcKKwgmwpxYq1plagGHhi0+gLO9A6kDeoahh7nRQpqqcn9YwuU6Qy4IOmdhBRjTp4GL/zLLWQqwZXFnMAtDArAFlHpMekNKIppAfzNGIz/bBkj4DkMfo72wfOq+YapDJbnhjQyzSAREwIDAQAB” “” from server foo.bar in 24 ms.

Activer les mappages DKIM dans rspamd

Comme expliqué plus haut il est conseillé d'utiliser des mappages DKIM. Cela n'a rien d'une fantaisie. Il s'agit juste d'un simple fichier définissant quel sélecteur vous désirez utiliser pour un domaine donné. rspamd supposera que votre sélecteur est toujours « dkim » tant que vous n'en aurez pas spécifié un dans un mappage. Si vous utilisez « dkim » vous pourriez vous retrouver en difficulté quand par la suite vous désirerez remplacer votre clé. Le DNS est un système lent et la propagation d'une nouvelle clé publique DKIM peut prendre un jour. Les mails signés avec la nouvelle clé pourraient être rejetés tant que le nouvel enregistrement DNS n'est pas connu partout dans le monde.

L'utilisation des mappages est simple. La première chose à faire est de changer la configuration du selector_map du module dkim_signing. Pour ce faire créez un nouveau ficnhier dans /etc/rspamd/local.d/dkim_signing.conf et placez-y juste ces deux lignes :

path = "/var/lib/rspamd/dkim/$domain.$selector.key";
selector_map = "/etc/rspamd/dkim_selectors.map";

La configuration parle assez bien d'elle-même. rspamd recherche le mappage entre les domaines et les clés dans le fichier dkim_selectors.map. Créez ce fichier en y plaçant cette ligne :

example.org 2018022301

C'est vraiment tout. rspamd maintenant sait que chaque fois qu'il verra un mail sortant depuis une adresse nimportequi@example.org il devra prendre la clé privée située dans le fichier /var/lib/rspamd/dkim/example.org.2018022301.key et l'utiliser pour signer le mail.

Rechargez la configuration :

service rspamd reload

Cette méthode fonctionne bien si vous avez juste quelques domaines qui ne changent virtuellement jamais. Si vous servez plutôt un nombre aléatoire de domaines de clients vous devriez plutôt vous tourner vers l'utilisation d'une base de données Redis pour y stocker vos clés comme cela est décrit dans la documentation documentation.

Ajoutez la clé de domaine à rspamd

Déplacez la clé privée qui a été créée par opendkim-genkey là où rspamd s'attend à la trouver :

mv 2018022301.private /var/lib/rspamd/dkim/example.org.2018022301.key

Le nom du fichier doit avoir la forme DOMAINE + point + SELECTEUR + « .key » comme vu au dessus. Si vous commettez une erreur dans le nom du fichier vous trouverez une erreur dans votre fichier spamd.log comme « lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/dkim/example.org.dkim.key ».

Assurez-vous que seul rspamd puisse le lire :

chown _rspamd /var/lib/rspamd/dkim/*
chmod u=r,go= /var/lib/rspamd/dkim/*

rspamd va automatiquement chercher les fichiers et n'a pas besoin d'être relancé.

Envoyez un mail de test

Si vous avez un autre compte mail sur un autre serveur alors vous pouvez lui envoyer un mail de test via votre serveur de mail. Si vous jetez un oeil au mail que vous avez reçu, vous devriez avoir un entête DKIM du genre :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org;
	s=2018022301; t=1519400838;
	h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding;
	bh=kpYel1IlDvqXEUc0SyIpXbMte3XpQOCXHl+zTyHQvGc=;
	b=NEUyWUoeKEoKAYTY8g04o73j+wrYUcEGSq7uwpbsAGo0OzuuIBluEfG1MbGF/Tf6yxxJB4
	gTDD3sqb19EsQxv39QsAwgddAz01Osw5LKU0MjLZpxw6NA8zLllJUsrNdNQAYSII9ip4xX
	ImU7+KFOEF+gmxR5aseUt5H6JT/aOmhPE9xsSyg9wLf0Bikyy5Cgh+Ay7AHQLMZogbTi9W
	dAPpZZcZs0pTwhcard6SaesypJ+xZNna+BA+C1vXrGDc+9stYZVi+Zufh6zlZo1E/sQSRL
	jowB1mjv1vjINRY30aq0rh4dT8RHe38/PKFf8vQHOSOKvjIKv984UeOTIFIUHw==

Pour vérifier la signature copiez l'intégralité du mail de test (y compris les entêtes et le corps), et lancez opendkim-testmsg dans votre shell et collez-y le mail (terminez par CTRL-D).

Si aucun message n'est affiché c'est que la signature vérifiée est correcte. Mais si vous obtenez quelque chose comme « opendkim-testmsg: dkim_eom(): Unable to verify » alors revérifiez votre enregistrement DNS.

Vous pouvez également utiliser le service dkimvalidator.com pour vérifier que vos signatures fonctionnent correctement.

SPF et DMARC

Ajouter une signature DKIM est un bon premier pas. Mais vous pouvez aller plus loin en disant aux serveurs destinataires qu'ils ne devraient pas accepter de mail venant de votre domaine sans une signature valide ou depuis des serveurs sur lesquels vous n'avez pas la main. Voici deux approches qui peuvent vous aider. La plus ancienne SPF et la plus récente DMARC. Les deux impliquent de créer une chaîne lisible par un ordinateur dans un format prédéfini et d'ajouter un enregistrement TXT à votre zone DNS. Les serveurs destinataires peuvent vérifier ces enregistrements et suivre votre recommandation (en tant que possesseur du domaine) quant à ce qu'il convient de faire si les critères d'envoi du mail ne sont pas satisfaits. Il pourrait tout de même l'accepter malgré tout ou le marquer comme spam ou le rejeter complètement.

Voyons à quoi ressemble un enregistrement SPF typique :

"v=spf1 ip4:157.97.194.11 mx ~all"

Qu'est-ce que cela signifie :

  1. Il s'agit d'un enregristrement SPF de la version 1 du standard (il n'existe actuellement pas d'autre version) ;
  2. veuillez accepter les emails depuis l'adresse IP 157.97.194.11 ;
  3. de manière alternative acceptez les mails depuis tout serveur mentionné dans les enregistrements MX de notre domaine (c'est à dire les serveurs qui reçoivent les mails pour ce domaine) 
  4. Tout autre serveur de mail devrait être considéré comme suspect, il pourrait être du spam ou pire.

Il existe des sites web comme SPFwizard qui vous aident à créer votre chaîne SPF à ajouter au DNS de votre domaine. Gardez à l'esprit que :

  • Vous devriez savoir exactement quels serveurs sont susceptibles d'envoyer des mails pour votre domaine. N'oubliez-pas d'y inclure les listes de diffusion ou les services de newsletters qui envoient des courriers en votre nom ;
  • Commencez avec l'option « ~all » pour marquer comme spam les mails qui ne satisfont pas les critères exigés. Si tout se passe bien vous pourrez passer à « -all » après quelques semaines si vous voulez 
  • Notez que les transferts de mail venant de votre domaine peuvent casser les règles SPF puisque soudainement le mail semble provenir d'une adresse IP qui n'est pas autorisée. Ce phénomène a été un problème courant avec les listes de diffusion et est progressivement corrigé par la réexpédition du mail depuis le domaine du service de liste de diffusion.

J'ai indiqué que DMARC était le nouveau standard. Alors pourquoi utiliser SPF malgré tout ? Parce que certaines plateformes de mail valorisent votre effort si vous utilisez également SPF. Techniquement spécifier une entrée DMARC est suffisant. A mon avis restreindre les adresses IP susceptibles d'envoyer des mails est un peu dangereux et un peu rigide. Il est de loin plus intéressant d'exiger que les mails depuis votre domaine aient une signature DKIM valide. Un tel enregistrement ressemblerait en gros à ça :

"v=DMARC1; p=reject; adkim=s"

Cependant pour créer une entrée DMARC correcte je vous suggère d'utiliser un de ces sites web qui vous aideront et vous expliqueront les restrictions et les configurations supplémentaires.

1 commentaire

#1  - Grubshka a dit :

Il est aussi possible de générer les clés via la commande suivante :
rspamadm dkim_keygen

La commande génère et installe les clés au bon endroit, er affiche ensuite l'enregistrement DNS, c'est pratique.

Répondre

Écrire un commentaire

Quelle est la dernière lettre du mot nhuc ?

Fil RSS des commentaires de cet article

À propos

Yakati.info - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.06s  - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.info
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml