Meilleure pratique pour l'authentification par e-mail : moyens optimaux de déploiement de SPF, DKIM et DMARC

Introduction

Ce guide décrit trois technologies prédominantes d'authentification des e-mails utilisées aujourd'hui : SPF, DKIM et DMARC, et aborde divers aspects de leur mise en oeuvre. Plusieurs situations d'architecture de messagerie sont abordées, ainsi que des directives pour les mettre en oeuvre sur l'ensemble de produits Cisco de sécurisation de la messagerie. Comme il s'agit d'un guide pratique des meilleures pratiques, certains des documents les plus complexes seront omis. Si nécessaire, certains concepts peuvent être simplifiés ou condensés pour faciliter la compréhension de la matière présentée.

Exigences en matière de connaissances sur les produits

Ce guide est un document de niveau avancé. Pour suivre le contenu présenté, le lecteur doit posséder les connaissances du produit de l'appliance de sécurité de la messagerie Cisco jusqu'au niveau de la certification Ingénieur de terrain de la sécurité de la messagerie Cisco. En outre, les lecteurs doivent avoir une bonne maîtrise du DNS et du SMTP et de leur fonctionnement. Connaître les bases de SPF, DKIM et DMARC est un plus.

Authentification par e-mail - Vue d'ensemble

Cadre de stratégie de l'expéditeur (SPF)

Sender Policy Framework a été publié pour la première fois en 2006, sous la forme RFC4408. La version actuelle est spécifiée dans RFC7208 et mise à jour dans RFC7372. Essentiellement, il fournit un moyen simple pour un propriétaire de domaine d'annoncer ses sources de messagerie légitimes aux destinataires à l'aide du DNS. Bien que SPF authentifie principalement l'adresse du chemin de retour (MAIL FROM), la spécification recommande (et fournit un mécanisme) d'authentifier également l'argument HELO/EHLO SMTP (FQDN de la passerelle de l'expéditeur tel qu'il est transmis lors de la conversation SMTP).

SPF utilise des enregistrements de ressources DNS de type TXT de syntaxe assez simple :

spirit.com       text = « v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all »

L'enregistrement Spirit Airlines ci-dessus permet aux adresses de @spirit.com de provenir d'un sous-réseau /24 particulier, de deux machines identifiées par un nom de domaine complet (FQDN) et de l'environnement Office365 de Microsoft. Le qualificatif “~all ” à la fin indique aux récepteurs de considérer toute autre source comme Échec logiciel - l'un des deux modes de défaillance du SPF. Notez que les expéditeurs ne précisent pas ce que les destinataires doivent faire des messages défaillants, mais dans quelle mesure ils échoueront.

Delta, en revanche, utilise un schéma SPF différent :

delta.com text = « v=spf1 a:smtp.hosts.delta.com include:_spf.fournisseur.delta.com -all »

Pour minimiser le nombre de requêtes DNS requises, Delta a créé un enregistrement “ A unique répertoriant toutes ses passerelles SMTP. Ils fournissent également un enregistrement SPF distinct pour leurs fournisseurs dans “_spf.fournisseur.delta.com ”. Ils incluent également des instructions pour Hard Fail tous les messages non authentifiés par SPF (qualificatif “-all ”). Nous pouvons également consulter l'enregistrement SPF des fournisseurs :

_spf.fournisseur.delta.com texte = « v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceonDemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all »

Ainsi, les courriels des expéditeurs @delta.com peuvent légitimement provenir, par exemple, des passerelles de messagerie d'Air France.

United, en revanche, utilise un schéma SPF beaucoup plus simple :

united.com text = « v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all »

Outre leurs propres passerelles de messagerie d'entreprise, elles incluent leurs fournisseurs de marketing par e-mail (“ usa.net ” et “ enviaremails.com.br ”), les anciennes passerelles Continental Air Lines, ainsi que tout ce qui est indiqué dans leurs enregistrements MX (mécanisme “ MX ”). Notez que MX (une passerelle de messagerie entrante pour un domaine) peut ne pas être la même que sortante. Bien que les petites entreprises soient généralement les mêmes, les grandes entreprises disposent d'une infrastructure distincte pour le traitement du courrier entrant et de la livraison sortante.

Il convient également de noter que tous les exemples ci-dessus font largement appel à des renvois DNS supplémentaires (“ incluent des mécanismes ”). Cependant, pour des raisons de performances, la spécification SPF limite à dix le nombre total de recherches DNS nécessaires pour récupérer un enregistrement final. Toute recherche SPF avec plus de 10 niveaux de récursivité DNS échouera.

Clés de domaine - Messagerie identifiée (DKIM)

DKIM, spécifié dans les documents RFC 5585, 6376 et 5863, est une fusion de deux propositions historiques : Clés de domaine de Yahoo et messagerie Internet identifiée de Cisco. Il fournit un moyen simple pour les expéditeurs de signer des messages sortants par chiffrement et d'inclure les signatures (ainsi que d'autres métadonnées de vérification) dans un en-tête d'e-mail (“ DKIM-Signature ”). Les expéditeurs publient leur clé publique dans le DNS, ce qui permet à n'importe quel destinataire de récupérer la clé et de vérifier les signatures. DKIM n'authentifie pas la source des messages physiques, mais s'appuie sur le fait que si la source est en possession de la clé privée de l'organisation de l'expéditeur, elle est implicitement autorisée à envoyer un e-mail en leur nom.

Pour implémenter DKIM, l'organisation émettrice générerait une ou plusieurs paires de clés publiques et publierait les clés publiques dans le DNS en tant qu'enregistrements TXT. Chaque paire de clés serait référencée par un ” de sélection “ afin que les vérificateurs DKIM puissent différencier les clés. Les messages sortants seraient signés et l'en-tête DKIM-Signature inséré :

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=uni ; d=news.united.com ; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID ; i=MileagePlus@news.united.com ; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYq 01EwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYL=

Le format de la signature est assez simple. “ une balise ” spécifie les algorithmes utilisés pour la signature, “ c ” spécifie le ou les schémas de canonicalisation utilisés [1], “ s ” est le sélecteur ou la référence de clé, “ d est le domaine de signature. Le reste de cet en-tête DKIM-Signature est spécifique au message : “ h ” liste les en-têtes signés, “ i ” liste l'identité de l'utilisateur signataire et finalement l'en-tête se termine par deux hachages distincts : “ ” bh est un hachage d'en-têtes signés, tandis que “ b ” est la valeur de hachage du corps du message.

Lors de la réception d'un message signé par DKIM, le destinataire recherche la clé publique en construisant la requête DNS suivante :

<sélecteur>._domainkey.<domaine de signature>

comme spécifié dans l'en-tête DKIM-Signature. Pour l'exemple ci-dessus, notre requête serait “ unie._domainkey.news.united.com ” :

united._domainkey.news.united.com texte = « g=*\; k=rsa\; n=" « Contact » "postmaster@responsys.com" « avec » « n'importe quelle » « question » « concernant » « cette » « signature » "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy5Qmxcuv5Awqx z9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPW h0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\; »

L'enregistrement DNS retourné contient la clé, ainsi que d'autres paramètres facultatifs. [2]

Le principal problème avec DKIM est que la spécification initiale ne permettait pas la publicité qu'un expéditeur utilise DKIM. Par conséquent, si un message est livré sans signature, il n’y a pas de moyen facile pour un destinataire de savoir qu’il aurait dû être signé et que dans ce cas, il n’est probablement pas authentique. Étant donné qu'une seule organisation peut (et le plus souvent utilisera) plusieurs sélecteurs, il n'est pas banal de “ deviner ” un domaine est compatible DKIM. Une norme distincte, intitulée Author Domain Signing Practices (Pratiques de signature de domaine d'auteur), a été mise au point pour couvrir cette question, mais en raison de la faible utilisation et d'autres problèmes ont été dépassés en 2013 sans successeur.

Authentification, génération de rapports et conformité des messages basés sur le domaine (DMARC)

DMARC est la plus jeune des trois technologies d'authentification de messagerie couvertes et a été développée spécifiquement pour combler les lacunes de SPF et DKIM. Contrairement aux deux autres, il authentifie l'en-tête à partir d'un message et établit des liens vers les vérifications précédemment effectuées par les deux autres. DMARC est spécifié dans RFC7489.

La valeur ajoutée de DMARC sur SPF et DKIM comprend :

• S'assurer que toutes les identités disponibles (HELO, MAIL FROM et/ou domaine de signature DKIM) sont alignées (exactement identiques ou subordonnées) avec l'en-tête From
• Fourniture d'un moyen pour le propriétaire du domaine de l'expéditeur de spécifier une stratégie pour les destinataires sur la manière dont ils doivent gérer les messages défaillants
• Fourniture d'une fonction de rétroaction permettant aux propriétaires de domaine d'expéditeur d'être informés de tout message d'échec, ce qui facilite l'identification des campagnes d'hameçonnage ou des erreurs dans l'affectation de stratégie SPF/DKIM/DMARC

DMARC utilise également un mécanisme de distribution de politiques basé sur DNS simple :

_dmarc.aa.com text = « v=DMARC1\; p=aucun\; fo=1\; ri=3 600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 La seule balise obligatoire dans la spécification de stratégie DMARC est “ p ”, spécifiant la stratégie à utiliser sur les messages défaillants. Il peut s'agir de l'un des trois : aucun, quarantaine, rejet.

Les paramètres facultatifs le plus souvent utilisés concernent les rapports : “ rua ” spécifie une URL (soit un mailto : ou une URL http:// à l'aide de la méthode POST) pour envoyer des rapports agrégés quotidiens sur tous les messages défectueux prétendant provenir d'un domaine particulier. “ ruf ” spécifie une URL pour envoyer des rapports d'échec détaillés immédiats sur chaque message d'échec.

Selon les spécifications, un destinataire doit respecter la politique annoncée. S'ils ne le font pas, ils doivent en informer le propriétaire du domaine de l'expéditeur dans le rapport d'agrégation.

Le concept central de DMARC est ce qu'on appelle l'alignement des identificateurs. L'alignement d'identificateur définit comment un message peut passer la vérification DMARC. Les identificateurs SPF et DKIM sont alignés séparément, et un message doit passer n'importe lequel d'entre eux pour passer DMARC dans son ensemble. Cependant, il existe une option de stratégie DMARC dans laquelle l'expéditeur peut demander qu'un rapport d'échec soit généré même si l'un des alignements réussit, mais que l'autre échoue. Nous pouvons le voir dans l'exemple ci-dessus avec “ de balise ” définie sur “ 1 ”.

Il existe deux façons pour les messages de respecter l'alignement de l'identificateur DKIM ou SPF, strict et décontracté. Une stricte adhésion signifie que le nom de domaine complet de l'en-tête De doit correspondre entièrement à l'ID de domaine de signature (étiquette “ d ”) de la signature DKIM ou au nom de domaine complet de la commande MAIL FROM SMTP pour SPF. Relaxed, d'autre part, permet Header From FQDN d'être un sous-domaine des deux mentionnés précédemment.  Cela a des implications importantes lors de la délégation de votre trafic de messagerie à des tiers, qui seront abordées plus loin dans le document.

Considérations relatives au déploiement SPF

SPF pour les récepteurs

La vérification SPF est infime à configurer sur l'appliance de sécurité de la messagerie Cisco ou les appliances virtuelles de sécurité de la messagerie cloud. Pour le reste du présent document, toute référence à l'ESA inclura également la CES.

La vérification SPF est configurée dans les stratégies de flux de messages - la façon la plus simple de l'exécuter globalement est de l'activer dans la section Paramètres de stratégie par défaut du ou des écouteurs appropriés. Si vous utilisez le même écouteur pour la collecte de messages entrants et sortants, assurez-vous que la vérification SPF de votre stratégie de flux de ” RELAIS “ est définie sur “ Désactivé ”.

Étant donné que SPF ne permet pas de spécifier l'action de politique à entreprendre, la vérification SPF (ainsi que DKIM, comme nous le verrons plus loin) vérifie uniquement le message et insère un jeu d'en-têtes pour chaque vérification SPF effectuée :

Received-SPF : Pass (mx1.hc4-93.c3s2.smtpi.com : domaine de

  united.5765@envfrm.rsys2.com désigne 12.130.136.195 comme

  expéditeur autorisé) identity=mailfrom;

  client-ip=12.130.136.195 ; récepteur=mx1.hc4-93.c3s2.smtpi.com ;

  enveloppe-from="united.5765@envfrm.rsys2.com« ;

  x-sender="united.5765@envfrm.rsys2.com« ;

  x-conformance=sidf_compatible ; x-record-type=« v=spf1 »

Received-SPF : Aucun (mx1.hc4-93.c3s2.smtpi.com : aucun expéditeur

  informations d'authenticité disponibles à partir du domaine de

  postmaster@omp.news.united.com) identity=helo ;

  client-ip=12.130.136.195 ; récepteur=mx1.hc4-93.c3s2.smtpi.com ;

  enveloppe-from="united.5765@envfrm.rsys2.com« ;

  x-sender="postmaster@omp.news.united.com« ;

  x-conformance=sidf_compatible

Notez que pour ce message, deux identités “ ” ont été vérifiées par SPF : “ mailfrom ” comme prescrit par la spécification, et “ helo ” comme recommandé par la même. Le message sera transmis officiellement au SPF, car seul le premier est pertinent pour la conformité au SPF, mais certains récepteurs peuvent sanctionner les expéditeurs qui n'incluent pas les enregistrements SPF pour leur identité HELO également. Par conséquent, il est recommandé d'inclure les noms d'hôte de vos passerelles de messagerie sortantes dans vos enregistrements SPF.

Une fois que les stratégies de flux de messages vérifient un message, il appartient aux administrateurs locaux de configurer une action à entreprendre. Cela se fait en utilisant la règle de filtre de messages SPF-status() [3], ou en créant un filtre de contenu entrant en utilisant le même et en l'appliquant aux stratégies de messagerie entrante appropriées.

Image 1 : Condition de filtre de contenu de vérification SPF

Les actions de filtrage recommandées consistent à supprimer les messages qui échouent (” de tous les “ dans l'enregistrement SPF) et les messages de quarantaine que Softfail (“~tous ” dans l'enregistrement SPF) dans une quarantaine de stratégie. Cependant, cela peut varier en fonction de vos exigences de sécurité. Certains récepteurs ne font que marquer les messages défaillants ou ne prennent aucune action visible, mais le signalent aux administrateurs.

Récemment, la popularité du SPF a augmenté de manière significative, mais de nombreux domaines publient des enregistrements SPF incomplets ou incorrects. Pour être sûr, vous pouvez mettre en quarantaine tous les messages qui échouent au SPF et surveiller la quarantaine pendant un certain temps, afin de vous assurer qu'il n'y a pas de ” de faux positifs “.

Si Vous Fournissez Des Services De Messagerie Pour D'Autres Domaines Ou Tiers

Si vous fournissez des services de livraison de courrier électronique ou d'hébergement à des tiers, ils devront ajouter des noms d'hôte et des adresses IP que vous utilisez pour transmettre leurs messages à leurs propres enregistrements SPF. Le moyen le plus simple pour cela est que le fournisseur crée un enregistrement SPF “ parapluie et que les clients utilisent “ mécanisme d'inclusion ” dans leurs enregistrements SPF.

suncountry.com text = « v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.19.66.68 ip4:198.179.134.238 ip4:107.20.247.57 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.target.com ~tous »

Comme nous pouvons le constater, Sun Country a certains de ses courriels sous son propre contrôle, mais leurs courriels marketing sont externalisés à un tiers. L'extension de l'enregistrement référencé indique une liste des adresses IP actuelles utilisées par leur fournisseur de services de publipostage marketing :

cust-spf.exactitude.target.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136. ip4:136. ip4:13. -all »

Cette flexibilité permet aux fournisseurs de services de messagerie de s'adapter sans avoir à contacter chaque client pour modifier ses enregistrements DNS.

Si vous utilisez des services de messagerie tiers

De même que le paragraphe précédent, si vous utilisez des services de messagerie tiers et souhaitez établir un flux de courrier entièrement vérifié SPF, vous devez inclure leurs propres enregistrements SPF dans le vôtre.

jetblue.com texte descriptif « v=spf1 include:_spf.qualtrics.com ?all »

JetBlue utilise le service Qualtrics Analytics et la seule chose à faire est d'inclure un enregistrement SPF correct de Qualtrics. De même, la plupart des autres fournisseurs de services ESP fournissent des enregistrements SPF à inclure dans les enregistrements de leurs clients.

Si votre ESP ou votre marqueur de messagerie ne fournit pas d'enregistrements SPF, vous devrez répertorier leurs passerelles de messagerie sortantes directement dans la vôtre. Cependant, il est de votre responsabilité de conserver ces enregistrements exacts, et si le fournisseur ajoute des passerelles supplémentaires ou modifie des adresses IP ou des noms d'hôte, votre flux de courrier peut être compromis.

Le partage des ressources représente un autre danger pour les tiers qui ne sont pas sensibles au SPF : Si un ESP utilise la même adresse IP pour envoyer des e-mails à plusieurs clients, il est techniquement possible pour un client de générer un message SPF valide prétendant être un autre client qui fournit via la même interface. C'est pourquoi, avant de mettre en place des restrictions SPF, vous devez étudier les stratégies de sécurité de votre fournisseur de services de messagerie et connaître l'authentification de la messagerie. S’ils n’ont pas de réponses à vos questions, compte tenu du fait que SPF est l’un des mécanismes de confiance de base sur Internet, il est fortement conseillé de reconsidérer votre choix de MSP.  Il ne s'agit pas seulement de sécurité : les meilleures pratiques SPF, DKIM, DMARC et d'autres expéditeurs [4] utilisées par les fournisseurs de services multimédias sont une assurance de la livrabilité. Si votre MSP ne les suit pas ou ne les suit pas correctement, cela diminuera leur fiabilité avec de grands systèmes de réception et peut-être retardera ou même bloquera vos messages.

(Sous)Domaines sans trafic de messagerie

Aujourd'hui, la plupart des entreprises possèdent plusieurs domaines à des fins de marketing, mais n'en utilisent qu'un activement pour le trafic de messagerie d'entreprise. Même si SPF est correctement déployé sur le domaine de production, les acteurs incompétents peuvent toujours utiliser d'autres domaines qui ne sont pas activement utilisés pour un e-mail pour usurper l'identité d'une organisation. SPF peut empêcher cela de se produire via un “ spécial de refuser tous les enregistrements SPF ” - pour l'un de vos domaines (et sous-domaines !) qui ne génèrent pas de trafic de messagerie, publiez “ v=spf1 -tous ” dans le DNS. Un excellent exemple est openspf.org - le site du Conseil SPF.

Étant donné que la délégation SPF n'est valide que pour un seul domaine, il est essentiel de publier également “ refuser tous les enregistrements SPF ” pour les sous-domaines que vous utilisez et qui pourraient ne pas générer d'e-mail. Même si votre domaine de production dispose d'un enregistrement SPF ” régulier “, faites un effort supplémentaire pour ajouter “ refuser tous les enregistrements ” à vos sous-domaines sans trafic. Encore une fois, n'oubliez pas que recevoir n'est pas équivalent à envoyer : Un domaine peut très bien recevoir des e-mails, mais ne sera jamais source. Cela est très vrai pour les domaines marketing à court terme (événements, promotions à durée limitée, lancements de produits...), où les e-mails entrants dans ces domaines seront envoyés à votre domaine de production, et toutes les réponses à ces e-mails seront envoyées à partir du domaine de production. Ces domaines à court terme auront un enregistrement MX valide, mais ils doivent avoir un enregistrement SPF qui les identifie comme aucune source d'e-mail.

Considérations relatives au déploiement DKIM

DKIM pour les récepteurs

La configuration de la vérification DKIM sur l'ESA est similaire à la vérification SPF. Dans les paramètres de stratégie par défaut des stratégies de flux de messagerie, activez simplement la vérification DKIM sur “ On ”. Encore une fois, puisque DKIM ne permet aucune spécification de stratégie, cela vérifiera la signature et insérera un en-tête ” Authentification-Résultats “ :

Authentication-Results : mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature vérifiée) header.i=MileagePlus@news.united.com

Toute action basée sur les résultats de la vérification DKIM doit être exécutée par les filtres de contenu :

Image 2 : Condition de filtre de contenu de vérification DKIM

Contrairement à SPF, qui est simple, DKIM manipule le texte du message réel, de sorte que certains paramètres peuvent être limités. Vous pouvez éventuellement créer des profils de vérification DKIM et affecter différents profils de vérification à différentes stratégies de flux de courrier. Ils vous permettent de limiter la taille des clés de signatures que vous accepterez, de définir les actions d'échec de récupération de clé et de configurer la profondeur de la vérification DKIM.

Lorsqu'un message passe plusieurs passerelles, il peut être signé plusieurs fois et ainsi porter plusieurs signatures. Pour qu'un message passe la vérification DKIM, toute signature doit être vérifiée. Par défaut, l'ESA vérifiera jusqu'à cinq signatures.

En raison de l'ouverture historique du SMTP et des courriels et de la réticence d'Internet à s'adapter aux changements (positifs), il existe encore plusieurs situations où les signatures DKIM peuvent légitimement échouer, comme lorsque les gestionnaires de listes de diffusion relaient directement mais modifient les messages, ou lorsque les messages sont transférés directement plutôt que comme pièces jointes à de nouveaux messages. C'est pourquoi, en général, la meilleure pratique pour les messages échouant à DKIM serait toujours de mettre en quarantaine ou de marquer, plutôt que de les abandonner.

Préparation de la signature avec DKIM

Avant d'activer la signature DKIM dans votre stratégie de flux de messagerie RELAYED, vous devez générer/importer les clés, créer des profils de signature DKIM et publier les clés publiques dans le DNS.

Si vous signez pour un seul domaine, le processus est simple. Générez la paire de clés, créez votre profil de signature unique dans la section Clés de domaine des stratégies de messagerie, puis cliquez sur l'option “ Générer ” sous “ enregistrement de texte DNS ” une fois votre profil prêt. Publiez la clé comme générée dans votre DNS. Enfin, activez la signature DKIM dans votre stratégie de flux de messagerie.

Cela devient plus compliqué si vous signez plusieurs domaines distincts. Dans ce cas, vous avez deux options :

1. Utilisez un profil de signature unique pour signer pour tous les domaines. Vous stockerez la clé publique (unique) dans la zone DNS du domaine ” principal “, et vos signatures DKIM référenceront cette clé. Cette technique a souvent été utilisée par les ESP dans le passé - elle leur permettait de signer à grande échelle, sans avoir à interagir avec l’espace DNS de chaque client [5].
2. Créez un profil de signature distinct pour chaque domaine pour lequel vous vous connectez. Cela rend la configuration initiale plus complexe, mais offre beaucoup plus de flexibilité pour aller de l'avant. Créez une paire de clés pour chaque domaine, créez un profil spécifiant un seul domaine (et ses sous-domaines) dans la section ” utilisateurs du profil “, et publiez la clé publique appropriée dans la zone DNS de ce domaine particulier.

Bien que l'option n°1 soit plus simple à utiliser, n'oubliez pas qu'elle finira par rompre DMARC. Puisque DMARC exige que l'ID de domaine de signature soit aligné sur l'en-tête De, votre alignement d'identificateur avec DKIM échouera. Vous pouvez vous en tirer si vous configurez correctement votre SPF et si vous vous fiez à l'alignement de l'identificateur SPF pour réussir la vérification DMARC.

Cependant, en implémentant l'option n°2 dès le départ, vous n'avez pas à vous inquiéter de DMARC et il est assez facile de révoquer ou de reconfigurer le service de signature pour un seul domaine.  En outre, si vous fournissez certains services de messagerie pour un domaine tiers, vous devrez probablement obtenir la clé à utiliser à partir d'eux (et l'importer dans votre ESA). Cette clé sera spécifique au domaine, vous devrez donc créer un profil distinct.

Si vous utilisez des services de messagerie tiers

En règle générale, si vous utilisez la signature DKIM et que vous déchargez une partie de votre traitement de courrier électronique (par exemple les courriels marketing) vers un tiers, vous ne voulez pas qu'ils utilisent les mêmes clés que celles que vous utilisez en production. C'est l'une des principales raisons de l'existence de Sélecteurs dans DKIM. À la place, vous devez générer une nouvelle paire de clés, publier la partie publique dans votre zone DNS et livrer la clé secrète à l'autre partie. Cela vous permettra également de révoquer rapidement cette clé en cas de problème tout en préservant l'infrastructure DKIM de production.

Bien qu'il ne soit pas nécessaire pour DKIM (les messages d'un même domaine peuvent être signés avec plusieurs clés différentes), il est recommandé de fournir un sous-domaine distinct pour tout e-mail qui est traité par un tiers. Il facilitera le suivi des messages et permettra une mise en oeuvre plus propre de DMARC ultérieurement. Prenons l'exemple des cinq en-têtes DKIM-Signature de plusieurs messages de Lufthansa :

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=lufthansa ; d=newsletter.milesandmore.com ;

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=lufthansa2 ; d=newsletter.lufthansa.com ;

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=lufthansa3 ; d=lh.lufthansa.com ;

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=lufthansa4 ; d=e.milesandmore.com

DKIM-Signature : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; s=lufthansa5 ; d=fly-lh.lufthansa.com ;  

Nous pouvons voir que Lufthansa utilise cinq clés différentes (sélecteurs) réparties sur cinq sous-domaines distincts de deux domaines de production primaire (lufthansa.com et milesandmore.com). Cela signifie que chacun d'entre eux peut être contrôlé de manière indépendante et que chacun peut être externalisé vers un fournisseur de services de messagerie différent.

Considérations relatives au déploiement DMARC

DMARC pour les récepteurs

La vérification DMARC sur l'ESA est basée sur le profil, mais contrairement à DKIM, le profil par défaut doit être modifié pour être conforme à la spécification. Le comportement par défaut de l'ESA est de ne jamais supprimer de messages, sauf instruction explicite du client, de sorte que le profil de vérification DMARC par défaut aura toutes les actions définies sur “ Aucune ” d'action. En outre, pour activer la génération correcte de rapports, vous devez modifier les paramètres globaux de la section DMARC de Politiques de messagerie.

Une fois le profil configuré, la vérification DMARC, comme les deux autres, est définie dans la section Paramètres de stratégie par défaut des stratégies de flux de courrier. Assurez-vous de cocher la case pour envoyer des rapports de commentaires agrégés - c'est sans doute la fonction la plus importante de DMARC pour l'expéditeur. Au moment de l'écriture de cet article, l'ESA ne prend pas en charge la génération de rapports d'échec par message (“ balise ruf ” de la politique DMARC).

Comme les actions de stratégie DMARC sont conseillées par l'expéditeur, contrairement à SPF ou DKIM, il n'y a aucune action spécifique configurable en dehors de la configuration du profil. Il n'est pas nécessaire de créer des filtres de contenu.

La vérification DMARC ajoutera des champs supplémentaires à l'en-tête Authentication-Results :

Authentication-Results : mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature vérifiée) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

Dans l'exemple ci-dessus, nous voyons que DMARC a été vérifié en fonction de l'alignement de l'identificateur DKIM, et l'expéditeur a demandé la stratégie “ aucun ”. Cela indique qu'ils sont actuellement dans la phase ” de surveillance “ du déploiement DMARC.

Si Vous Fournissez Des Services De Messagerie Pour D'Autres Domaines Ou Tiers

La principale préoccupation des ESP en matière de conformité DMARC est de parvenir à un alignement correct des identificateurs. Lors de la planification de DMARC, assurez-vous que votre SPF est configuré correctement, que tous les autres domaines concernés ont vos passerelles sortantes dans vos enregistrements SPF et qu'ils n'envoient pas de messages qui échoueront à l'alignement, principalement en utilisant différents domaines pour l'identité MAIL FROM et Header From. Cette erreur est le plus souvent commise par des applications qui envoient des notifications ou des avertissements par e-mail, car les auteurs d'applications ne sont généralement pas conscients des conséquences de l'incohérence de leur identité électronique.

Comme décrit précédemment, assurez-vous d'utiliser un profil de signature DKIM distinct pour chaque domaine et que votre profil de signature fait référence correctement au domaine pour lequel vous vous connectez comme utilisé dans En-tête De. Si vous utilisez vos propres sous-domaines, vous pouvez signer avec une clé unique, mais assurez-vous de définir votre adhésion à DKIM pour vous détendre dans la politique DMARC (“ adkim= ” ou ”).

En règle générale, si vous fournissez des services de messagerie à un plus grand nombre de tiers que vous n'avez pas de contrôle direct, il est recommandé de rédiger un document de référence sur la façon de soumettre un courriel qui est le plus susceptible d'être envoyé. Comme les e-mails utilisateur à utilisateur sont généralement bien gérés, ils serviront principalement de document de stratégie pour les auteurs d'applications dans les exemples mentionnés ci-dessus.

Si vous utilisez des services de messagerie tiers

Si vous utilisez des tiers pour livrer une partie de votre trafic de messagerie, la meilleure façon est de déléguer un sous-domaine distinct (ou un domaine complètement différent) au fournisseur tiers. Ils peuvent ainsi gérer les enregistrements SPF selon les besoins, disposer d'une infrastructure de signature DKIM distincte et ne pas interférer avec votre trafic de production. Ensuite, la stratégie DMARC pour les e-mails externalisés peut être différente de celle pour les e-mails internes. Comme nous l'avons déjà mentionné, lorsque vous considérez l'e-mail envoyé par un tiers, assurez-vous toujours que vos identificateurs seront alignés et que votre adhésion à DKIM et SPF est définie de manière appropriée dans votre stratégie DMARC.

(Sous)Domaines sans trafic de messagerie

Une autre amélioration de DMARC par rapport aux technologies d'authentification de messagerie précédentes réside dans la manière dont il gère les sous-domaines. Par défaut, la stratégie DMARC d'un domaine particulier s'applique à tous ses sous-domaines. Lors de la récupération des enregistrements de stratégie DMARC, si aucun enregistrement n'est trouvé au niveau En-tête du nom de domaine complet (FQDN), les destinataires sont tenus de déterminer le domaine d'organisation [6] de l'expéditeur et de rechercher un enregistrement de stratégie dans celui-ci.

Cependant, la stratégie DMARC pour un domaine d'organisation peut également spécifier une stratégie de sous-domaine distincte (étiquette sp ” d'un enregistrement DMARC “) qui s'appliquera à tous les sous-domaines qui n'ont pas publié de stratégie DMARC explicite.

Dans le scénario décrit précédemment dans le chapitre SPF, vous devez :

1. Publier un enregistrement DMARC explicite pour tous les sous-domaines qui sont des sources légitimes d'e-mails.
2. Publier une stratégie de sous-domaine de “ rejeter ” dans votre enregistrement de stratégie de domaine d'organisation pour rejeter automatiquement tous les e-mails qui usurpent des domaines non envoyés

Ce type de structuration de l'authentification de vos e-mails offre la meilleure protection possible de votre infrastructure et de votre marque.

Problèmes spécifiques à DMARC

Il y a plusieurs problèmes potentiels avec DMARC, qui viennent tous de la nature et des lacunes d'autres technologies d'authentification auxquelles il se fie. Le problème est que DMARC a fait apparaître ces problèmes en poussant activement une politique à rejeter l'e-mail, et en corrélant tous les différents identificateurs d'expéditeur dans un message.

La plupart des problèmes surviennent avec les listes de diffusion et les logiciels de gestion des listes de diffusion. Lorsqu'un e-mail est envoyé à une liste de diffusion, il est redistribué à tous ses destinataires. Cependant, l'e-mail résultant, avec l'adresse de l'expéditeur d'origine, sera livré par l'infrastructure d'hébergement du gestionnaire de listes de diffusion, ce qui échoue lors des vérifications SPF pour l'en-tête De (la plupart des gestionnaires de listes de diffusion utilisent l'adresse de liste comme Enveloppe De (MAIL FROM) et l'adresse de l'expéditeur d'origine comme En-tête De).

Puisque DMARC échouera pour SPF, nous pouvons nous fier à DKIM, cependant, la plupart des gestionnaires de listes de diffusion ajoutent également des pieds de page aux messages, ou étiquettent les sujets avec le nom de la liste, ce qui rompt la vérification de la signature DKIM.

Les auteurs de DKIM proposent plusieurs solutions au problème, qui se résument toutes aux gestionnaires de listes de diffusion qui doivent utiliser l'adresse de la liste dans toutes les adresses De, et indiquer l'adresse de l'expéditeur d'origine par un autre moyen.

Des problèmes similaires surviennent lors du transfert de messages en copiant simplement le message d'origine sur SMTP vers le nouveau destinataire. Cependant, la plupart des agents d'utilisateurs de messagerie utilisés aujourd'hui formeront correctement un nouveau message et incluront le message transféré soit en ligne soit en pièce jointe au nouveau. Les messages transmis de cette manière seront transmis à DMARC si l'utilisateur de transfert passe (bien sûr, l'authenticité du message d'origine ne peut pas être établie).

Exemple De Plan D'Action Pour Mettre En Oeuvre L'Authentification Par E-Mail

Bien que les technologies elles-mêmes soient simples, la mise en oeuvre d'une infrastructure complète d'authentification de la messagerie électronique peut être longue et sinueuse. Pour les petites entreprises et celles qui ont des flux de courrier contrôlés, ce sera assez simple, alors que les environnements plus grands peuvent trouver cela exceptionnellement difficile. Il n'est pas rare que les grandes entreprises embauchent des consultants pour gérer le projet de mise en oeuvre.

Étape 1 : DKIM

DKIM est relativement peu intrusif, car les messages non signés ne seront pas rejetés. Avant de procéder à la mise en oeuvre effective, tenez compte de tous les points mentionnés précédemment. Contactez les tiers auxquels vous pourriez déléguer la signature, assurez-vous que vos tiers prennent en charge la signature DKIM et tenez compte de votre stratégie de gestion des sélecteurs. Certaines organisations conserveraient des clés distinctes (sélecteurs) pour différentes unités organisationnelles. Vous pouvez envisager la rotation périodique des clés pour plus de sécurité, mais assurez-vous de ne pas supprimer vos anciennes clés tant que tous vos messages en transit ne sont pas remis.

Il convient de tenir compte en particulier des tailles clés. Bien qu'en général “ plus vaut mieux ”, vous devez tenir compte du fait que la création de deux signatures numériques par message (y compris la canonisation, etc.) est une tâche très coûteuse pour le CPU, et peut influencer les performances des passerelles de messagerie sortantes. En raison de la surcharge de calcul, 2 048 bits est la taille de clé pratique la plus importante qui puisse être utilisée, mais pour la plupart des déploiements, les clés 1 024 bits font un bon compromis entre les performances et la sécurité.

Pour réussir la mise en oeuvre ultérieure de DMARC, vous devez :

1. Identifier tous les domaines que vous envoyez, y compris les sous-domaines
2. générer des clés DKIM et créer des profils de signature pour chaque domaine
3. fournir des clés privées pertinentes à des tiers
4. publier toutes les clés publiques dans les zones DNS pertinentes
5. vérifier que les tiers sont prêts à commencer à signer
6. activer la connexion DKIM dans la stratégie RELAYED Mail Flow sur tous vos ESA
7. informer les tiers de commencer à signer

Étape 2 : SPF

La mise en oeuvre correcte de SPF sera probablement la partie la plus longue et la plus lourde de toute mise en oeuvre d'infrastructure d'authentification de la messagerie. Parce que le courrier électronique était très simple à utiliser et à gérer, et totalement ouvert du point de vue de la sécurité et de l'accès, les entreprises n'ont jamais appliqué de règles strictes concernant qui et comment l'utiliser. De ce fait, la plupart des entreprises n'ont pas une vue complète de toutes les sources de courrier électronique, à la fois à l'intérieur et à l'extérieur. Le plus gros problème de la mise en oeuvre de SPF est de découvrir qui envoie légitimement des courriels en votre nom.

Choses à rechercher :

1. cibles évidentes : serveurs Exchange ou d'autres serveurs groupware ou passerelles de messagerie sortantes
2. toute solution DLP ou tout autre système de traitement des e-mails pouvant générer des notifications externes
3. Systèmes CRM envoyant des informations en interaction avec les clients
4. diverses applications tierces pouvant envoyer des e-mails
5. travaux pratiques, tests ou autres serveurs pouvant envoyer des e-mails
6. ordinateurs personnels et périphériques configurés pour envoyer un e-mail externe directement

La liste ci-dessus n'est pas complète, étant donné que les organisations ont des environnements différents, mais devrait être considérée comme une ligne directrice générale sur ce qu'il faut chercher. Une fois que (la plupart) vos sources de courrier électronique ont été identifiées, vous pouvez prendre du recul et, au lieu d'autoriser chaque source existante, nettoyer la liste. Idéalement, tous vos e-mails sortants doivent être envoyés par vos passerelles de messagerie sortantes, à quelques exceptions justifiées. Si vous disposez de votre propre solution ou utilisez une solution de messagerie marketing tierce, vous devez utiliser une infrastructure distincte de celle des passerelles de messagerie de production. Si votre réseau de livraison de courrier est exceptionnellement compliqué, vous pouvez continuer à documenter l'état actuel de votre SPF, mais prenez le temps de corriger la situation à l'avenir.

Si vous desservez plusieurs domaines sur la même infrastructure, vous pouvez créer un enregistrement SPF universel unique et le référencer dans des domaines individuels à l'aide du mécanisme “ include ”. Assurez-vous que vos enregistrements SPF ne sont pas trop larges ; Par exemple, si seulement cinq machines d'un réseau /24 envoient SMTP, ajoutez ces cinq adresses IP individuelles à votre SPF, plutôt que l'ensemble du réseau. Veillez à ce que vos enregistrements soient aussi spécifiques que possible pour minimiser les risques de compromission de votre identité par des courriels malveillants.

Commencez par une option softfail pour les expéditeurs non correspondants ( “~tous les ”). Ne le changez en hardfail (-all) qu'une fois que vous êtes sûr à 100% que vous avez identifié toutes vos sources de courriels, sinon vous risquez de perdre des courriels de production. Plus tard, après avoir mis en oeuvre DMARC et l'avoir exécuté en mode surveillance pendant un certain temps, vous pourrez identifier les systèmes que vous avez manqués et mettre à jour vos enregistrements SPF pour qu'ils soient terminés. Ce n'est qu'alors qu'il sera sûr de configurer votre SPF sur hardfail.

Étape 3 : DMARC

Une fois que votre DKIM et votre SPF sont configurés aussi complètement que possible, il est temps de créer vos stratégies DMARC. Considérez toutes les situations mentionnées dans les chapitres précédents et préparez-vous à déployer plusieurs enregistrements DMARC si vous disposez d'une infrastructure de messagerie complexe.

Créez des alias de messagerie qui recevront des rapports ou créez une application Web qui peut les ingérer. Il n'y a pas d'adresse e-mail strictement définie à utiliser pour cela, mais elle peut être utile si elles sont descriptives, par exemple rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com, etc. Assurez-vous que vous avez un processus en place pour qu'un opérateur surveille ces adresses et modifie la configuration SPF, DKIM et DMARC de manière appropriée, ou avertissez l'équipe de sécurité en cas de campagne d'usurpation. Au départ, la charge de travail sera importante lorsque vous ajusterez les enregistrements pour couvrir tout ce qui aurait pu manquer lors de la configuration SPF et DKIM. Au bout d'un certain temps, les rapports indiqueront probablement uniquement les tentatives d'usurpation.

Initialement, définissez votre stratégie DMARC sur “ aucun ” et votre option d'analyse pour envoyer des rapports pour tout échec de contrôle (“ de = 1 ”) - cela détectera rapidement toute erreur dans votre SPF et DKIM sans influencer le trafic. Une fois que vous êtes satisfait du contenu des rapports soumis, modifiez la stratégie en “ ” de quarantaine ou “ rejetez ”, selon votre stratégie de sécurité et vos préférences. Là encore, assurez-vous que les opérateurs analysent en permanence vos rapports DMARC reçus pour détecter les faux positifs.

La mise en oeuvre complète et correcte de DMARC n'est pas une tâche de petite ou de courte durée. Bien que certains résultats (et la ” formelle “ mise en oeuvre de DMARC) puissent être obtenus en publiant un ensemble incomplet d'enregistrements et une politique de “ aucun ”, il est dans l'intérêt de l'organisation de l'expéditeur et de l'Internet dans son ensemble que tout le monde le met en oeuvre dans toute la mesure de ses capacités.

En ce qui concerne les délais, voici un aperçu très sommaire des étapes individuelles d'un projet type. Encore une fois, comme chaque organisation est différente, elles sont loin d'être exactes :

1. Planification et préparation de DKIM	2 à 4 semaines
2. Exécutions de test DKIM	2 semaines
3. SPF - identification légitime de l'expéditeur	2 à 4 semaines
4. Préparation de la politique DMARC	2 semaines
5. Série de tests des enregistrements SPF et DMARC	4 à 8 semaines
6. Exécution de test SPF avec hardfail	2 semaines
7. Exécution de test DMARC avec quarantaine/rejet	4 semaines
8. Surveillance des rapports DMARC et adaptation de SPF/DKIM en conséquence	continu

Les petites entreprises sont susceptibles de connaître une durée plus courte de la plupart des étapes, en particulier les étapes 3 et 4. Quelle que soit la simplicité de votre infrastructure de messagerie, allouez toujours beaucoup de temps pendant les tests et surveillez de près les rapports de rétroaction pour tout ce que vous pourriez avoir manqué.

Les grandes entreprises peuvent connaître une durée encore plus longue des mêmes étapes, avec des exigences de test plus strictes. Il n'est pas rare que les entreprises disposant d'une infrastructure de messagerie complexe embauchent de l'aide externe, non seulement pour l'aspect technique de la mise en oeuvre de l'authentification de la messagerie électronique, mais également pour gérer l'ensemble du projet et coordonner les équipes et les services.

Références supplémentaires

• Site de référence pour SPF : http://www.openspf.org
• Le Conseil DKIM : http://www.dkim.org
• Site Web principal DMARC, géré par le projet de domaine approuvé : http://www.dmarc.org
• dmarcian - un site d'aide et de ressources géré par Tim Draegen, l'un des auteurs de DMARC. N'oubliez pas de visiter la section ” Outils “ : http://www.dmarcian.com
• Outil de validation des dossiers de Online Trust Alliance : https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant - autre outil utile pour créer vos enregistrements DMARC : http://www.kitterman.com/dmarc/assistant.html
• Outils de test des enregistrements SPF : http://www.kitterman.com/spf/validate.html
• “ ne soyez pas un hameçonnage : Approfondir les techniques d'authentification de la messagerie électronique ”, une présentation Cisco Live 2014 BRKSEC-3770 : https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] La canonisation dépasse le cadre du présent document. Reportez-vous aux documents de “ section ” références supplémentaires pour plus d'informations sur la canonicalisation DKIM.

[2] Les paramètres d'enregistrement DNS DKIM sont également hors de portée de ce document.

[3] La création de filtres de messages dépasse le cadre de ce document. Pour obtenir de l'aide, reportez-vous aux guides d'utilisation d'AsyncOS pour les e-mails.

[4] Le M3AAWG a défini un excellent ensemble de pratiques exemplaires appliquées et respectées par la plupart des membres de l’industrie. Le document sur les meilleures pratiques communes des expéditeurs est disponible à l'adresse https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] Ce comportement tire parti du fait qu'à l'origine, DKIM ne vérifie pas la source du message comme indiqué dans MAIL FROM ou Header From du tout. Il vérifie uniquement que l'ID de domaine de signature (paramètre “ d ” de la signature DKIM et paramètre “ nom de domaine ” dans votre profil de signature) héberge effectivement la clé publique de la paire utilisée pour signer le message. L'authenticité de l'expéditeur est implicite en faisant signer l'en-tête “ De ”. Assurez-vous de répertorier tous les domaines (et sous-domaines) auxquels vous vous connectez dans “ section ” utilisateurs de profil.

[6] Généralement, un domaine d'un niveau inférieur à TLD ou au préfixe ccTLD approprié (.ac.uk, .com.sg, etc.)