8 avril 2021

Quand les 3 mousquetaires viennent à la rescousse des serveurs de messagerie

Les adresses e-mail sont omniprésentes de nos jours. Allant de l’ouverture de compte bancaire jusqu’à la messagerie instantanée personnelle, la nécessité d’avoir une adresse e-mail n’a jamais été aussi forte.

Cependant, l’e-mail pose de nombreux soucis en matière de sécurité. Comment s’assurer que le mail que je reçois ne provient pas d’une adresse e-mail usurpée ? Comment m’assurer que le mail reçu est 100% intègre ? Autant de question que d’inconnue que nous allons tenter d’éclaircir dans cet article. Pour ce faire, nous avons fait appel à 3 super héros des temps modernes aux acronymes barbares, mais tellement importants, je cite : SPF, DKIM et DMARC.

Quels sont les bénéfices de protéger nos serveurs de messagerie avec SPF, DKIM et DMARC ?

Comme de nombreuses personnes, vous recevez régulièrement des e-mails frauduleux vous incitant à divulguer vos mots de passe, transmettre vos identifiants bancaires, etc.. Ces e-mails frauduleux usurpent généralement des institutions de confiance (comme les services nationaux, entités bancaires, etc.) afin de vous piéger. Ce type d’attaque s’appelle du phishing.

Afin de se prémunir contre ces attaques, les protocoles SPF, DKIM et DMARC permettent notamment :

  • De stopper l’usurpation des e-mails depuis votre domaine.
  • De fournir des informations importantes sur les e-mails que vous avez envoyés, qui peuvent être utilisés pour que tous les e-mails légitimes soient correctement authentifiés.
  • D’améliorer la réputation de l’expéditeur, c’est-à-dire que vos e-mails ont plus de chance d’atterrir dans la boîte de réception du receveur plutôt que dans ses indésirables.

SPF (Sender Policy Framework)

Le SPF est le premier vrai mécanisme de sécurité implémenté pour les serveurs de messagerie. Il est apparu au début des années 2000, bien avant DKIM et DMARC.

Le SPF est une norme d’authentification permettant de corréler le nom de domaine de l’adresse e-mail avec le serveur d’envoi. Celle-ci permet de définir les serveurs autorisés à envoyer un e-mail avec le nom de domaine. Cette norme vérifie également que le mail provient bien d’un hôte (IP) autorisé par les enregistrements DNS. Le mécanisme d’authentification complet est défini dans la RFC 7208.

Comme un exemple vaut mille mots, prenons la configuration suivante :

En tant que comptable chez BSSI, nous souhaitons envoyer la fiche de paye des collaborateurs de l’entreprise par e-mail via notre adresse e-mail compta@bssi.fr. Notre nom de domaine sera donc bssi.fr

L’adresse IP du serveur SMTP d’envoi d’e-mails de bssi.fr est 10.0.0.5.

Des attaquants peu scrupuleux tentent d’usurper l’adresse e-mail de notre service comptabilité avec un serveur SMTP d’envoi d’e-mails ayant comme adresse IP 92.16.225.3.

Lorsque les attaquants enverront le mail frauduleux, leur serveur SMTP d’envoi d’e-mails se connectera au serveur mail (10.0.0.5) des destinataires (ici les collaborateurs de bssi.fr) de l’e-mail.

Une fois connecté, le serveur mail de réception va extraire le nom de domaine du chemin de retour présent dans l’en-tête du mail. Après avoir extrait le nom de domaine, le serveur mail de réception va interroger le DNS qui gère le domaine bssi.fr, et notamment la présence d’un champ TXT qui commence par « v=spf1 ». Cet enregistrement DNS TXT précise la ou les adresses IP autorisées à envoyer des e-mails pour le compte du domaine bssi.fr. Vu que seul notre serveur de messagerie SMTP en 10.0.0.5 est autorisé à envoyer des e-mails depuis le domaine bssi.fr, notre enregistrement SPF aura la forme suivante v=spf1 ip4:10.0.0.5 -all.

Pour en revenir à notre exemple, le serveur SMTP attaquant a pour adresse IP 92.16.225.3, ce qui ne correspond à aucune adresse IP référencée dans l’enregistrement SPF. De ce fait, la vérification SPF échoue. A contrario, si l’adresse IP est répertoriée, le contrôle SPF sera réussi.

Il existe de nombreuses applications web permettant de récupérer ces enregistrements SPF, notamment kitterman, MXToolBox, ou bien Mail Tester

Le mécanisme SPF est donc une protection redoutable contre l’usurpation d’adresse e-mail. Attention cependant à ne pas surestimer cette protection qui ne comble pas tous les problèmes de sécurité liée aux envois et réceptions d’e-mails. Malgré l’implémentation d’enregistrements SPF :

  • Il reste possible d’afficher un nom d’expéditeur usurpé afin de tromper les collaborateurs non attentifs.
  • Un enregistrement SPF n’est pas gage de protection ultime, même un attaquant peut implémenter un enregistrement SPF pour son nom de domaine.
  • Si un attaquant envoie un e-mail non autorisé via votre serveur de messagerie, le SPF n’interviendra pas et ne bloquera pas l’envoi de son e-mail.

Malgré son utilisation plutôt simple, il existe de bonnes pratiques élémentaires permettant de configurer au mieux SPF afin d’accroître la sécurité des différents mécanismes. La première étape consiste à garder les enregistrements SPF les plus simples et succincts possibles. Nous pouvons également noter que l’utilisation d’enregistrements de type SPF est dépréciée en faveur des enregistrements de type TXT.

De plus, il est recommandé d’inclure des blocs d’adresses IP les plus petits possibles, idéalement compris entre /16 et /30. Plus le bloc est élevé, plus le périmètre sera restreint permettant une meilleure maintenance des enregistrements ainsi qu’un accès plus réglementé. Il est possible que dans certains cas, les fournisseurs de boîte de messagerie n’acceptent pas les enregistrements SPF au-delà de /16 (65 536 adresses IP) pour des questions de légitimité.

Une autre manière de venir « durcir » l’utilisation de la protection SPF est de ne jamais utiliser le mot clé « +all », résultant en l’inclusion de l’intégralité d’Internet comme étant autorisé à envoyer des e-mails via votre nom de domaine. À l’inverse, il est recommandé d’utiliser le mot clé « –all » créant une sorte de « liste blanche » d’adresses IP autorisées à envoyer des e-mails via notre nom de domaine.

DKIM (Domain Keys Identified Mail)

DKIM est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique issue d’un consortium industriel entre le système DomainKeys de Yahoo! et le système Identified Internet Mail de Cisco.

Cette technologie a été normalisée par l’EITF dans la RFC 4871 remplacée depuis par la RFC 6376.

Le protocole permet de signer votre e-mail avec votre nom de domaine. L’objectif du protocole DKIM n’est pas uniquement de prouver que le nom de domaine n’a pas été usurpé, mais aussi que le message n’a pas été altéré durant sa transmission.

Il s’agit d’ajouter dans tous les e-mails sortants, une signature DKIM contenant une liste de « clé=valeur ». Les clés sont courtes, généralement une ou deux lettres.

Un serveur SMTP réceptionnant un e-mail signé utilise ensuite l’identifiant de domaine responsable de la signature (SDID) et le sélecteur associé annoncés dans les en-têtes de l’e-mail afin de récupérer la clé publique publiée dans le serveur DNS du SDID. Cette clé est utilisée pour vérifier la validité des signatures.

Par exemple pour un mail reçu par un collaborateur de BSSI envoyé par le domaine example.com :

Les paramètres sont décrits dans la RFC 6376. Les plus pertinents sont :

  • b pour les véritables signatures numériques des contenus (en-têtes et corps de mail) ;
  • bh pour le hachage du corps ;
  • d pour l’identifiant de domaine responsable de la signature (SDID) ;
  • s pour le sélecteur.

Un vérificateur teste l’enregistrement DNS TXT de brisbane._domainkey.example.com. Il n’y a ni autorité de certification ni système de liste noire. Le sélecteur est une méthode directe pour autoriser un signataire à ajouter ou retirer des clés quand il le souhaite, sans archivage des signatures.

Après avoir reçu l’e-mail, le destinataire peut vérifier la signature DKIM à l’aide de la clé publique enregistrée dans les enregistrements DNS. Il utilise cette clé pour déchiffrer la valeur de hachage dans l’en-tête et recalculer la valeur de hachage à partir de l’e-mail qu’il a reçu. Si ces deux signatures DKIM correspondent, le Mail Transfer Agent sait que l’e-mail n’a pas été modifié. Cela permet à l’utilisateur de confirmer que l’e-mail a bien été envoyé depuis le domaine indiqué.

L’échec de vérification de la signature n’impose pas de rejet systématique du message. En effet, ces raisons précises peuvent être rendues disponibles dans des processus en amont et en aval.

La politique de rejet d’un e-mail dont la signature DKIM ne serait pas vérifiée peut-être publiée dans une entrée DNS de type TXT DMARC (_dmarc.example.com).

Lors de l’implémentation de DKIM, plusieurs critères peuvent être changés, voici une liste des meilleures pratiques :

  • La taille de la clé recommandée est d’au moins 1024 bits pour augmenter la complexité. Une clé de 512 bits peut être résolue en moins de 72 heures grâce au service cloud.
  • Il est recommandé de changer de clé au moins deux fois par an pour réduire la période d’utilisation à des fins malveillantes.
  • L’utilisation de fonctions de hachage recommandée est nécessaire pour éviter que la clé ne soit vulnérable.
  • Le mode test (t=y) doit être utilisé sur une courte période et uniquement durant les tests pour éviter que certaines entreprises ne vérifient pas la signature DKIM lors de la détection du mode de test.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Jamais deux sans trois ! DMARC est un protocole d’authentification des e-mails qui assure la protection du canal de messagerie au niveau du domaine. L’authentification DMARC permet de détecter et d’empêcher les techniques d’usurpation d’adresses électroniques utilisées dans l’hameçonnage, la compromission du courrier électronique professionnel et d’autres attaques via courrier électronique.

S’appuyant sur les normes existantes – SPF et DKIM – DMARC est capable de rendre l’en-tête « from » du domaine digne de confiance. Le propriétaire du domaine peut publier un enregistrement DMARC dans le système de noms de domaine (DNS) et créer une politique indiquant aux destinataires ce qu’ils doivent faire avec les courriels dont l’authentification échoue.

Pour qu’un email passe l’authentification DMARC, il doit passer l’authentification SPF et DKIM. Si un message échoue à l’authentification DMARC, les expéditeurs peuvent indiquer aux destinataires ce qu’ils doivent faire avec ce message via une politique DMARC.

Il existe trois politiques que le propriétaire du domaine peut appliquer :

  • none : le message est remis au destinataire et le rapport DMARC est envoyé au propriétaire du domaine.
  • quarantine : le message est déplacé vers un dossier de quarantaine.
  • reject : le message n’est pas remis.

Exemple record DNS TXT pour DMARC :

  • _dmarc.bssi.com 3600 IN TXT  « v=DMARC1; p=none »

La politique DMARC « none » est une première étape vers une implémentation sécurisée. De cette façon, le propriétaire du domaine peut s’assurer que tous les e-mails légitimes s’authentifient correctement.

Le propriétaire du domaine reçoit des rapports DMARC qui l’aident à s’assurer que tous les e-mails légitimes sont identifiés et passent l’authentification. Une fois que le propriétaire du domaine est sûr d’avoir identifié tous les expéditeurs légitimes et d’avoir résolu les problèmes d’authentification, il peut passer à une politique de « quarantine » puis enfin « reject » et bloquer les attaques de phishing, de compromission d’e-mails d’entreprise et autres fraudes par e-mail.

En tant que destinataire du courrier électronique, une organisation peut s’assurer que sa passerelle de messagerie sécurisée applique la politique DMARC mise en œuvre auprès du propriétaire du domaine. Cela permettra de protéger les employés contre les menaces liées aux e-mails entrants.

Il existe de nombreuses autres options disponibles avec le protocole DMARC, il est ainsi nécessaire de regarder cela en fonction des besoins de l’entreprise et du serveur DNS qu’elle utilise

Voici quelques exemples de record DMARC concrets :

  • v=DMARC1 ; p=none ; rua=mailto: dmarc.reports@bssi.fr -> définir la politique DMARC en mode surveillance (p=none), ce qui permet de surveiller la livraison des e-mails, sans les avoir en tant que spam ou les rejeter. De plus, cela envoie des rapports à dmarc.reports@bssi.fr;
  • v=DMARC1 ; p=quarantine ; rua=mailto: dmarc.reports@bssi.fr -> définir la politique DMARC en mode quarantaine (p=quarantine), ce qui permet de surveiller la livraison des e-mails, et d’envoyer les e-mails qui échouent à l’authentification DMARC au spam et d’envoyer des rapports à dmarc.reports@bssi.fr;
  • v=DMARC1 ; p=reject ; rua=mailto: dmarc.reports@bssi.fr -> définir la politique DMARC en mode rejet (p=reject), ce qui permet de surveiller la livraison des e-mails et de rejeter les e-mails dont l’authentification DMARC échoue. Des rapports globaux sont ici envoyés à dmarc.reports@bssi.fr. Cela offre une protection complète des e-mails contre l’usurpation d’identité.

Conclusion

De nos jours, ces trois protections que sont SPF, DKIM et DMARC sont devenues indispensables et permettent de se prémunir contre la plupart des attaques ciblant les serveurs mails ainsi que le manque de vigilance des utilisateurs de messagerie.

Via ces mécanismes utilisés conjointement, l’identité et l’intégrité de vos e-mails restent intactes de bout en bout. Un attaquant malveillant est cependant toujours en mesure d’obtenir un domaine similaire à celui visé tel que « micorsoft.com » pour « microsoft.com » dans le but d’effectuer des attaques de type phishing.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *