Sécurisation des emails
Après avoir présenté la problématique dans un premier article, quels sont les protocoles permettant de limiter les impacts du spam et du phishing ?
3 mécanismes de protection des emails
SPF est une méthode permettant de valider l’adresse d’expédition en vérifiant l’adresse ip depuis le domaine d’expédition lui-même.
Avec SPF on peut autoriser certains serveurs de mail à envoyer des mails au titre du domaine concerné. Par exemple g-echo.fr avec son MX smtp.g-echo.fr, adresse ipv4 91.197.138.21.
Exemple SPF dans le RFC de l'IETF
SPF (si utilisé seul) se limite à détecter que le domaine de l’expéditeur est bien autorisé à envoyer des emails.
Voici à quoi ressemble un enregistrement SPF dans votre zone DNS d’un site exemple.com si vous hébergez vos mails chez gmail:
v=spf1 include:spf.gmail.com ipv4:8.8.8.8 ~all
La configuration ci-dessus impose que seule l’adresse ipv4 8.8.8.8 ne soie autorisée à envoyer des mails pour ce domaine.
D’autres conditions peuvent être mentionnées dans l’enregistrement SPF de spf.example.com pour être interprétées par le serveur du destinataire.
Le drapeau ~all préconise au récepteur de marquer l’email comme spam si ces conditions ne sont pas réunies. Si on change ce drapeau avec -a le mail sera rejeté purement et simplement.
L’enregistrement SPF empêche le spoofing des champs “mail-from” et “reply-to” qu’on retrouve dans le header du mail et que vous avez peut-être déjà remarqué dans des mails de campagnes marketing, de services client, de newsletters, etc…
Voici quelques flags que l’on retrouve dans l’enregistrement spf:
Version (v): version du protocole, exemple v=spf1,
Include (p): le serveur de réception peut vérifier la politique SPF du domaine cité dans ce flasg (votre zone en exemple.com peut demander de valider également votre SPF pour le exemple.fr),
ipv4/ipv6: adresses ip autorisées à envoyer du courriel pour le domaine de cette zone,
all: choix de l’action si la vérification échoue.
DKIM est un standard de sécurité permettant de garantir que le contenu d’un email n’a pas été altéré depuis que l’envoyeur l’a transmis au destinataire. On garantit grâce à DKIM l’intégrité du contenu du message.
DKIM est spécifié par le RFC 6376.
Voici un enregistrement typique DKIM dans une zone DNS:
v=DKIM1; p=MIGfMA9GCSqGSIb3DQSBAQUAA4TNADCBiQKBgQC1TaNgLlSyQMNWVLRLvyY/neDgaL2oqQE8T5illJqCgDtFHc6eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;
Les champs utilisés ici sont:
Version (v): donne la version de protocole DKIM1 utilisée (ici v=dkim1),
Clef publique (p): la clef publique permettant de vérifier que le contenu des mails est intègre.
On sait maintenant que SPF nous permet de rendre visibles les serveurs autorisés à l’envoi de mails pour notre domaine.
Et que DKIM nous garantit que le contenu de notre email ne sera pas altéré entre nous et le récepteur en apposant une signature numérique liée à un nom de domaine DNS, signature unique pour chaque email sortant de nos serveurs.
DMARC vient renforcer ces mesures de sécurité en apportant une authentification, un reporting et une conformité liés au nom de domaine.
Un exemple d’entrée DMARC dans une zone dns:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Une entrée DMARC bien configurée empêche le spoofing du champ from dans les entêtes de vos emails.
Voici les drapeaux standard de l’entrée DMARC de votre zone DNS:
Version (v): version de DMARC de l’entrée (ex: v=DMARC1),
Policy (p): politique à appliquer par le serveur qui reçoit le message parmi node (rien de requis par la policy de l’envoyeur), quarantine (mettre en quarantaine, mail suspect), reject (rejeter) les emails,
Subdomain policy (sp): par défaut, la même politique que p s’applique sauf si une autre politique est définie ici pour les sous-domaines,
Report Email Address(s) (rua): liste des mails vers lesquels rediriger le rapport de a forme rua=mailto:support@example.com,
Failure reporting options (fo): 0, 1, d ou s qui précise le type de rapport à générer,
ASPF (aspf): relaxed (r) par défaut, définit la manière dont l’alignement SPF doit être considéré (relaxed ou strict),
ADKIM (adkim): idem que aspf pour le dkim,
Report format (rf): liste de formats de rapports souhaités par le domaine émetteur du mail en cas d’échec sur SPF ou DKIM,
Report interval (ri): ce drapeau permet de préciser une fréquence exprimée en secondes,
Percentage (pct): pourcentage des emails du domaine sujets au filtrage.
IETF Drafts
Les drafts de SPF, DKIM, DMARC sont disponibles en ligne, précisent le contexte d'implémentation de ces protocoles.
Les drafts fournissent de nombreux exemples permettant de les comprendre et les mettre en oeuvre.