Comment configurer un système mail sécurisé pour protéger la délivrabilité et éviter l'usurpation d'identité
Configurer correctement un système de messagerie est essentiel pour garantir la délivrabilité des e-mails, prévenir l'usurpation d'identité et se protéger des cybercriminels. En début d'année, Google et Yahoo ont renforcé leurs contrôles techniques sur les e-mails, tandis que Microsoft, de son côté, continue de perfectionner ses systèmes EOP et Defender, offrant une analyse encore plus poussée du contenu des messages. Alors, quels sont les points clés à surveiller pour sécuriser vos communications par e-mail ?
L'histoire de l'email et l'évolution des menaces en ligne
Si le concept d'échange de message électronique émerge en 1961, c'est en 1982 qu'apparaît l'email basé sur le protocole SMTP tel que nous le connaissons aujourd'hui. A cette époque, il s'agissait d'envoyer des messages via le réseau ARPANET qui liait les chercheurs universitaires, les instituts de recherches et les laboratoires militaires américains entre eux. Le protocole SMTP, conçu avec une certaine naïveté, n'intégrait pas les préoccupations actuelles en matière de sécurité, car il était destiné à un réseau restreint, utilisé principalement pour l'échange de données scientifiques. Ainsi, l'expéditeur était chargé de déclarer qui il était et aucune autorité n'avait pour mission d'attester son identité. Autrement dit, l'expéditeur pouvait librement se faire passer pour bill.gates@microsoft.com ou bill.clinton@whitehouse.com et il n'existait aucun mécanisme pour permettre au destinataire de vérifier ces informations.
Pour répondre à cette problématique, des ingénieurs et sociétés privées ont inventé des mécanismes supplémentaires qui renforcent la sécurité des emails. Parmi eux, les standards SPF, DKIM et DMARC se sont imposés comme des protocoles incontournables pour assurer la protection et l'intégrité des systèmes de messagerie.
Qu'est-ce que le SPF et comment le configurer pour votre domaine ?
Le Sender Policy Framework (SPF) est un mécanisme qui permet au serveur destinataire de vérifier que le serveur SMTP expéditeur a bien été autorisé par le propriétaire du domaine à envoyer des emails. Autrement dit, un propriétaire de domaine comme microsoft.com doit déclarer les IP des serveurs SMTP autorisés à envoyer des emails.
Explication technique du mécanisme : lorsqu'un serveur SMTP reçoit un email, celui-ci interroge les DNS du domaine de l'expéditeur pour y trouver la ligne SPF. Il vérifie ainsi que l'IP du SMTP qui lui a transmis l'email est bien listée dans cet enregistrement.
Comment configurer le SPF de mon domaine ? Connectez-vous sur votre registrar ou bien sur votre serveur DNS et éditez les zones DNS. Si une ligne TXT commençant par v=spf1 existe, éditez-la, dans le cas contraire, créez-la. Assurez-vous qu'il n'y ait qu'une seule ligne SPF pour le domaine.
Si vous souhaitez autoriser un serveur dédié à envoyer des emails, ajoutez son IP comme ceci :
v=spf1 ip4:211.85.89.12 ~all
Si vous souhaitez autoriser une plage d'IP :
v=spf1 ip4:211.85.89.0/24 ~all
Pour autoriser plusieurs IP, il suffit de les écrire à la suite :
v=spf1 ip4:211.85.89.12 ip4:197.53.25.16 ip4:88.85.15.251 ~all
Autoriser une IPv6 :
v=spf1 ip6:3ffe:8007:0000:2201:0200:f8df:fe75:50df ~all
Si vous utilisez Google, Microsoft ou un autre produit pour envoyer vos mail, des enregistrements SPF sont généralement prévus et contiennent toutes les IP à autoriser. Voilà comment les ajouter :
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
Consultez la Liste des SPF des services en ligne les plus populaires.
Pour autoriser les IP de vos enregistrement A et MX à envoyer des emails, vous pouvez ajouter les arguments suivants :
v=spf1 ip4:211.85.89.12 a mx ~all
Un SPF peut donc combiner de multiples produits et serveurs autorisés à envoyer des emails pour votre domaine :
v=spf1 ip4:211.85.89.0/24 ip4:88.45.85.67 include:_spf.google.com a mx ~all
Attention : pour ne pas nuire à l'e-réputation de votre domaine, il est recommandé de ne pas excéder 10 ip/plage/spf différents. En effet, un domaine qui multiplierait les moyen d'envoi d'email pourrait être assimilé à une organisation dédiée au SPAM.
Notons que ce mécanisme présente une faiblesse non négligeable. En effet, lorsque vous autorisez les serveurs d'un outil de messagerie comme Google ou bien un outil d'e-mailing comme Mailjet à envoyer des mails pour votre domaine, les organisations cybercriminelles n'auront qu'à utiliser les mêmes systèmes pour usurper votre identité et mener leurs opérations de phishing et spoofing. C'est cette faiblesse qui justifie la création du DKIM.
Qu'est-ce que le DKIM et comment protège-t-il vos emails ?
Le DomainKeys Identified Mail (DKIM) est un mécanisme qui permet au serveur destinataire de s'assurer que le mail qu'il vient de recevoir est bien autorisé par le propriétaire du domaine. Concrètement, le serveur qui émet le mail insère une signature cryptographique générée à l'aide d'une clé privée. Le serveur qui reçoit le mail vérifie qu'un enregistrement DNS contient la clé publique correspondante et l'utilise pour décrypter la signature. Si la clé parvient à vérifier cette signature, cela signifie que le système expéditeur a bien été configuré par le propriétaire du domaine. Rappelons qu'il n'est pas possible de déduire la clé privée à partir de la clé publique.
Comment configurer le DKIM de mon domaine ? Commencez par générer une clé privée depuis le système que vous voulez autoriser à envoyer des emails.
S'il s'agit d'un serveur mail sous linux, utilisez openssl pour générer les clés privées et publiques avec les commandes suivantes.
openssl genrsa -out private.key 1024
openssl rsa -in private.key -pubout -out public.key
Pour plus d'information, vous pouvez consulter la documentation officielle de OpenSSL
Puis installez la clé privée qui se trouve dans le fichier private.key dans le produit chargé d'envoyer des emails.
S'il s'agit d'un produit comme Google Workspace ou Microsoft Office365, générez la clé à partir de l'outil.
Dans un cas comme dans l'autre, connectez-vous sur votre registrar ou bien sur votre serveur DNS et ajoutez un enregistrement de type TXT avec le sélecteur associé à l'outil.
google._domainkey.yourdomain.com
Consultez la Liste des DKIM des services en ligne les plus populaires.
Puis copiez la valeur de la clé publique contenu dans le fichier public.key ou fournie par le produit utilisé.
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB4QUAA4GNADCBiQKBgQDL6joZwa33IP8oFEQW3d1oAZxKFYXlyoXWUbSExWH8L1J
soGIhwmR30M6WM+F7U8QeYZ9PwikvccjNDtBIZK/XjfIznmOVEKFlygm/33fVpTSMI7n2P8laUcxu4G93i1J9IO0Ekmx8lhPFXJ0e
O24amjN6jlSlRsAf0/SNMJZeSwIDAQAB
Contrairement au SPF, il est nécessaire d'ajouter un enregistrement DKIM par système habilité à envoyer des emails.
Attention : certains registrar n'acceptent pas les clés au-delà de 1024 bits et en même temps, certains acteurs de l'email comme Yahoo pénalisent les clés en dessous de 1024 bits. Il semblerait donc que 1024 bits soit la configuration la plus adaptée.
Ce mécanisme semble plus robuste que le SPF mais il ne peut pas le remplacer. En effet, si un hacker venait à voler votre clé privée, sans le mécanisme SPF celui-ci pourrait l'utiliser depuis n'importe quel serveur pour ses activité criminelles. La solidité d'un système mail réside donc dans la combinaison de ces deux mécanismes et la difficulté pour un cybercriminel de corrompre les deux.
Qu'est-ce que le DMARC ?
Le Domain-based Message Authentication, Reporting & Conformance (DMARC) pourrait être défini comme la politique email voulue par le propriétaire du domaine. Ce mécanisme a un double emploi :
Le premier est de monitorer les mails reçu par tous les systèmes mails et dont l'expéditeur s'est présenté comme faisant partie de votre domaine. Vous recevrez ainsi, chaque jour, des rapports de la part de chaque système ayant reçu vos emails.
Le second est de pouvoir donner des directives aux systèmes qui reçoivent des mails avec un expéditeur de votre domaine mais une mauvaise configuration. Il est, par exemple, possible de préconiser le rejet des emails de votre domaine si ceux-ci ne matchent pas les DKIM ou les SPF.
Explication technique du mécanisme : lorsqu'un serveur SMTP reçoit un email, il vérifie sa conformité SPF et DKIM comme décrit précédemment puis il interroge à nouveau les serveurs DNS pour récupérer le DMARC et prendre connaissance de la politique d'email du propriétaire du domaine. D'un côté, le serveur destinataire adressera un rapport sur l'email qu'il a reçu à l'adresse que vous aurez spécifiée dans cet enregistrement. De l'autre, il appliquera les règles du domaine si le mail ne présente pas une conformité parfaite.
Exemple de configuration :
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=r
Ici, p désigne le sort donné au mail s'il ne respecte pas les restrictions définies avec adkim et aspf. Les valeurs possibles sont reject, quanrantine, none
rua permet de spécifier le mail qui recevra les reports. Ceux-ci seront reçus de manière groupée toutes les 24h. Ces repports sont lisibles avec des outils d'analyse spécifiques.
adkim spécifie le niveau de conformité au dkim attendu. Les valeurs possibles sont "r" (relaxed) et "s" (strict). En mode relaxed, une signature DKIM est valide si le sous-domaine de l'expéditeur correspond au domaine DKIM signé. En mode strict, seule une correspondance exacte du domaine est acceptée.
aspf spécifie le niveau de conformité au spf attendu. Les valeurs possibles sont "r" (relaxed) et "s" (strict). En mode relaxed, un e-mail est considéré comme conforme si l'expéditeur appartient au même domaine principal. En mode strict, seul un enregistrement SPF avec une correspondance exacte du domaine est accepté.
Attention : si les DMARC sont des directives voulues par les propriétaires de domaines, ils ne sont en aucun cas une obligation d'exécution. Le serveur destinataire peut ainsi décider d'appliquer des règles plus sévères ou plus clémentes que celles définies dans les DNS.
Le contenu de l'email joue-t-il un rôle dans la sécurité ?
Afin de lutter activement contre la cybercriminalité, de nouveaux mécanismes voient le jour. C'est le cas, par exemple, chez Microsoft qui développe les outils Exchange Online Protection (EOP) et Defender, qui exercent une seconde batterie de contrôles focalisée sur le contenu de l'email. Ainsi, les liens contenus dans les mails et les fichiers en pièces jointes sont scannés pour y trouver du contenu malveillant.
Dans cette même optique, les analyses sémantiques se généralisent afin de détecter les SPAM et les tentatives d'escroquerie. Il est donc recommandé d'éviter le champs lexical qu'utiliserait une organisation malveillante comme : « Gratuit », « Gagner de l'argent », « Urgent », « Cliquer ici », « Offre spéciale » et les symboles excessifs comme des series de points d'exclamation ou des majuscules pour attirer l'attention « GRATUIT !!! ».
En conclusion
En conclusion, le protocole mail est né à une époque d'insouciance et n'a donc pas été doté de mécanismes performants permettant l'identification de l'expéditeur. Ces mécanismes ont été ajoutés par plusieurs couches au fil du temps avec SPF, DKIM et DMARC qui visent à garantir l'authenticité des messages et à réduire le phishing et le spam.
SPF permet de définir les serveurs autorisés à envoyer des e-mails pour un domaine, DKIM assure l'intégrité du message grâce à une signature cryptographique, et DMARC orchestre ces deux protocoles en fournissant des règles de validation et des rapports de conformité.
Cependant, leur mise en place et leur gestion nécessitent une configuration rigoureuse pour éviter des faux positifs ou des échecs de livraison légitimes. Dans un contexte où les cyberattaques sont de plus en plus sophistiquées, ces technologies sont devenues essentielles pour toute organisation soucieuse de la sécurité et de la fiabilité de ses communications électroniques.
En savoir plus
SPF (Sender Policy Framework)
Initiative : Meng Weng Wong est à l'origine du développement de SPF en 2000. Wong est un entrepreneur et expert en sécurité informatique qui a créé SPF pour lutter contre l'usurpation d'identité par email (phishing) et le spam.
Organisation : SPF a été initialement développé par Pobox.com, un fournisseur de services d'email fondé par Meng Weng Wong. Il a ensuite été pris en charge par une communauté de développeurs et normalisé via la RFC4408 en 2006. En 2014 une mise à jour a été publiée sous le RFC7208
DKIM (DomainKeys Identified Mail)
Initiative : DKIM est issu de la fusion de deux technologies précédentes :
DomainKeys, développé par Yahoo! en 2004.
Identified Internet Mail, développé par Cisco Systems.
Organisation : DKIM a été conçu pour signer numériquement les emails, assurant que l'email provient du domaine déclaré et qu'il n'a pas été modifié en transit. En 2007, la norme DKIM a été publiée sous la RFC 4871 et adoptée par l'Internet Engineering Task Force (IETF). Une premiere mise à jour a été publiée en 2009 sous la RFC5672 puis en 2011, la RFC6376 est publiée.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Initiative : DMARC a été développé par un consortium d'entreprises incluant :
> Google
> Yahoo!
> AOL
> Microsoft
> Facebook
> PayPal (notamment Brett McDowell, un expert en sécurité de PayPal, qui a joué un rôle clé dans le développement initial).
Organisation : Le développement de DMARC a commencé en 2011, et il a été officiellement publié en janvier 2012. Le but était d'améliorer la compatibilité de SPF et DKIM et d'offrir un mécanisme de reporting permettant aux propriétaires de domaines d'indiquer aux serveurs récepteurs comment gérer les emails échouant aux vérifications d'authenticité. DMARC est un standard publie dans la RFC7489 et sur le site officiel DMARC.org
Cette situation déstabilisante peut arriver à toute organisation honnête. Dans un premier temps, il faut garder son sang froid et analyser progressivement les causes de ce rejets. Voici la démarche à suivre :
> Google
> Yahoo!
> AOL
> Microsoft
Pour vérifier la configuration SPF, DKIM et DMARC il existe 2 méthodes simples.
Méthode 1 : envoyez un email depuis le système à tester vers une adresse Google (une simple adresse gratuite GMail suffit).
Depuis le mail reçu, cliquez sur les 3 points en haut à droite puis sur "Show original"
Puis vérifiez que les 3 lignes SPF, DKIM et DMARC sont bien qualifées en "PASS"
Méthode 2 : Le site Mail Tester permet de tester sa configuration en envoyant un email vers un alias créé à la volée. Rendez-vous sur le lien suivant et suivez les instructions : Mail Tester
Nos experts analyseront votre système et vous donneront le support nécessaire pour le remettre en conformité et sortir votre organisation d'une situation de crise.
Besoin d'aide pour configurer votre système mail ?
L'équipe de Syskeo est composée de professionnels passionnés et expérimentés. Notre équipe multidisciplinaire travaille en synergie pour offrir des solutions de haute qualité, basées sur les dernières avancées technologiques et les meilleures pratiques de l'industrie.