Le spoofing d'e-mail est l'une des techniques utilisées par les forces du mal pour vous convaincre que leur e-mail de spam/phishing est légitime. En résumé, le spoofing d'e-mail est utilisé par ces agents malveillants pour faire croire que leurs e-mails proviennent de sources fiables comme votre banque, votre produit préféré ou votre patron.

Les protocoles de messagerie existent depuis longtemps. Simple Mail Transport Protocol (SMTP), le principal protocole sur lequel reposent les communications par e-mail, date de 1981. Internet a beaucoup évolué, mais malheureusement, les e-mails, pas tant que ça. À l'époque de la création des e-mails, il y avait juste une fraction des utilisateurs d'aujourd'hui. À l'époque, envoyer un faux e-mail ne causait pas beaucoup de dommages. Maintenant, les e-mails sont utilisés pour presque tous les services numériques que vous pouvez imaginer et la technologie a lentement rattrapé son retard.

Commençons par expliquer comment fonctionnent les e-mails pour que tout le monde soit sur la même longueur d'onde. Accrochez-vous, c'est une simplification extrême de leur fonctionnement, mais cela m'aidera à expliquer les mécanismes pour rendre ce processus sécurisé. En gros, quand quelqu'un envoie un e-mail, cela se passe comme suit :

1. Alice (hi@alice.com) écrit un e-mail à Bob (hi@bob.com).
2. Alice envoie l'e-mail à son serveur de messagerie pour livraison.
3. Le serveur de messagerie d'Alice localise le serveur de Bob et transmet l'e-mail.
4. Chaque fois que Bob se connecte à son serveur de messagerie, il demande de nouveaux messages et un nouvel e-mail apparaît dans sa boîte de réception.

Simple ! Cependant, de nombreuses choses peuvent mal tourner lors de l'envoi d'un e-mail. Plongeons dans le sujet !

Sender Policy Framework (SPF)

Oh, mais Internet est plein d'horreurs. Imaginons qu'il y ait un acteur malveillant, appelons-le Chuck, qui veut tromper Bob pour qu'il lui envoie son mot de passe Harvest.

C'est exact, le SMTP classique ne nous dit pas si la personne qui envoie un e-mail est bien celle qu'elle prétend être.

Pour protéger nos e-mails contre ce type d'attaque, nous pouvons utiliser Sender Policy Framework (SPF). Lorsqu'un serveur de messagerie reçoit un nouvel e-mail, il demande au domaine source si l'expéditeur est autorisé à envoyer des e-mails en son nom. C'est ce que fait le SPF ; lorsque le serveur de messagerie de Bob reçoit un e-mail qui prétend venir de alice.com, il demandera d'abord à alice.com si le véritable expéditeur, chuck.com, peut envoyer quoi que ce soit en son nom.

Dans l'image ci-dessus, vous pouvez voir que le serveur de Bob effectue une requête DNS. Cette technique et toutes les autres mentionnées dans cet article reposent sur ce protocole. Quand je parle du serveur de messagerie de Bob demandant à alice.com des informations, cela signifie simplement envoyer une requête DNS à alice.com à la recherche d'enregistrements spécifiques.

Si alice.com n'a pas listé chuck.com comme l'un de ses expéditeurs autorisés, alors le serveur de messagerie de Bob pourrait marquer l'e-mail comme spam. Vous avez bien entendu, il pourrait le faire ou pas. Le serveur de Bob a toujours le dernier mot et il y a d'autres vérifications à effectuer avant de prendre une décision finale.

DomainKeys Identified Mail (DKIM)

Les e-mails devraient être sûrs maintenant, non ? Eh bien... pas tout à fait. Nous avons empêché Chuck d'envoyer de faux e-mails depuis ses propres serveurs, mais que se passerait-il s'il trouvait un moyen d'intercepter des e-mails en transit ? Que se passerait-il s'il pouvait modifier le contenu des messages d'Alice ? Rappelez-vous, le SPF ne vérifie que si l'expéditeur est autorisé à envoyer des e-mails en son nom, mais il ne dit rien sur ce qui se passe en route vers le destinataire.

C'est le scénario parfait pour utiliser des signatures. Dans le monde numérique, une signature est un mécanisme pour garantir et vérifier que le contenu de ce qui est livré n'a pas changé. Lorsque Alice envoie un e-mail à Bob, le serveur de messagerie d'Alice ajoutera maintenant une signature au contenu de l'e-mail. Si quelqu'un modifie ne serait-ce qu'un seul bit de ce message, Bob le saura. De plus, seul le serveur de messagerie d'Alice sait comment créer ces signatures. Personne d'autre ne peut le faire sans que le destinataire ne s'en aperçoive.

C'est exactement ce que fait DomainKeys Identified Mail (DKIM). En pratique, la configuration de DKIM commence dans le serveur de messagerie d'Alice :

• Il y a généralement un moyen de "commencer à authentifier" les e-mails envoyés. Cela signifie généralement simplement activer DKIM.
• Le serveur de messagerie vous demandera de publier quelques mots cryptiques dans votre DNS ; c'est la clé publique de votre signature. En termes simples, la clé publique permet à d'autres de vérifier qu'une signature qu'ils ont reçue est valide et que le message n'a pas été modifié en transit. Le serveur garde la clé privée pour être le seul à pouvoir créer des signatures.
• Une fois la clé publique publiée, le serveur de messagerie commencera à envoyer une signature avec chaque nouvel e-mail.

Comment la signature est-elle utile ? Lorsque le serveur de messagerie de Bob reçoit un e-mail avec une signature jointe, il peut valider que la signature est correcte. Pour cela, le serveur doit récupérer la clé publique et le contenu de l'e-mail. Avec seulement ces deux éléments, le serveur peut détecter s'il y a eu une modification non désirée.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Maintenant, Bob peut être assez sûr que les e-mails proviennent d'une source fiable et qu'ils n'ont pas été altérés, n'est-ce pas ? VRAI?... Si seulement c'était si simple... Chuck, notre personnage maléfique, peut toujours modifier le contenu de l'e-mail et simplement se débarrasser de la signature DKIM. Qui a besoin de ça de toute façon ? Mieux vaut avoir un contrôle neutre qu'un contrôle négatif.

Tout n'est pas perdu, cependant. Nous avons juste besoin d'un moyen d'informer le serveur de messagerie de Bob des mesures de sécurité qui ont été configurées et d'une politique qui définit quoi faire si l'une d'elles échoue. Passons à notre dernier acronyme : Domain-based Message Authentication, Reporting and Conformance (DMARC).

Avec DMARC, le serveur de messagerie de Bob dispose d'un point d'information public définissant quoi faire avec les e-mails qu'il reçoit. Plus précisément, un enregistrement DMARC décrit :

• Si le SPF ou le DKIM sont appliqués dans l'e-mail reçu
• Une adresse e-mail de rapport à des fins de surveillance
• Une politique pour décider quoi faire en cas d'échec d'une vérification. Il existe 3 politiques différentes :
• Pas de politique - Les résultats de la vérification DMARC seront ignorés. Cependant, les serveurs de messagerie enverront des rapports pour une analyse ultérieure. Cela est souvent utilisé lors de la configuration de DMARC pour voir s'il fonctionne comme prévu.
• Quarantaine - Les e-mails échouant à une vérification DMARC seront envoyés dans le dossier spam du destinataire.
• Rejeter - Les e-mails échouant à une vérification DMARC n'atteindront pas le destinataire.

DMARC est le dernier élément de notre boîte à outils, et c'est le seul qui indique spécifiquement aux serveurs de messagerie de rejeter les e-mails non conformes, et dans quelles circonstances cela se produit.

Conclusions

Nous sommes heureux de dire que Harvest utilise ces techniques pour protéger nos e-mails. Il nous a fallu des mois d'apprentissage et de collecte de données jusqu'à ce que nous arrivions enfin là où nous en sommes maintenant. Nous avons rendu très difficile pour d'autres de nous usurper et de nuire à la réputation de Harvest. C'est un accomplissement incroyable qui aura un impact positif sur nos clients.