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 ? Article source Contactez-nous

3 mécanismes de protection des emails

SPF - Sender Policy Framework

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 - DomainKeys Identified Mail

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. DMARC - Domain-based Message Authentication, Reporting & Conformance

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. Exemples du drafts SPFP

Erreurs de configuration typiques

SPF
DKIM
DMARC

Regardons quelques erreurs de configuration qui pourraient rendre votre SPF ineffectif.

Weak SPF Policy

Le drapeau all indique quoi faire si le mail échoue à la vérification SPF. Il existe 4 configurations possibles:

+all: tout accepter,
-all: rejeter l’email,
~all: accepter l’email et le marquer comme spam,
?all: signifie que cette politique SPF n’est pas à prendre en compte. Si une politique SPF est configurée avec +all ou ?all, vous n’aurez aucune protection contre le spoofing de votre domaine.

Syntaxe incorrecte

Si le champ SPF n’est pas correctement formaté, selon le RFC, c’est au serveur de choisir comment l’interpréter. Le serveur peut au choix marquer le mail comme spam ou choisir d’ignorer l’entrée SPF.

Récursion excessive

Lorsqu’il parcourt la définition de l’enregistrement SPF, le serveur du destinataire requête des enregistrements DNS pour le domaine mentionné par les drapeaux include, a et mx. Si il est nécessaire de faire plus de 10 requêtes DNS, l’enregistrement SPF est considéré comme invalide et ignoré. Il faut considérer, et c’est important, que les drapeaux include du domaine sont également analysés et contribuent au score de 10 qui pourrait rendre votre enregistrement SPF invalide.

Recherches annulées

Alors que le serveur de mails du destinataire requête vos DNS pour analyser les drapeaux de votre SPF, si 2 requêtes se terminent avec l’erreur NXDOMAIN, l’enregistrement SPF est considéré comme invalide. Ce nombre de 2 est paramétrable mais considéré comme la valeur recommandée.

Enregistrements SPF en doublon

Dans le cas où plus d’un enregistrement SPF aurait été déclaré pour le domaine, le domaine est considéré comme invalide.

Utilisation de champs PTR

Le champs ptr dans les enregistrements SPF a été déprécié et son usage aujourd’hui découragé eu égard au manque de performance des requêtes PTR et à leur manque de fiabilité. Certains systèmes de mail de vos destinataires pourraient même marquer comme spam vos emails si vous utilisez ce champs PTR.

Les standards cryptographiques évoluent avec l’actualité, on se pose aujourd’hui des questions sur l’ère dite post-quantique; vous pourre prendre connaissance ce sujet de l’article publié par l’ANSSI sur la transition vers la cryptographie post-quantique.

Clef de chiffrement DKIM trop courte

Si votre clef de chiffrement DKIM est trop courte, elle sera cryptographiquement peu sûre et pourra être potentiellement cryptanalysée (cassée). Le RFC préconise aujourd’hui des clefs de 128 bytes (1024 bits) avec une fonction de hash solide. *Vous pouvez utiliser des outils du commerce ou des outils open source pour générer vos clefs DKIM. *

Faible valeur pour pct

Le drapeau pct définit le pourcentage d’emails qui doivent être filtrés, par défaut 100%. Cette valeur doit être flaggée à 100 ou elle risque de diminuer les effets de la protection fournie par DMARC. Par exemple, pct=30 signifie que seulement 30% des emails envoyés par le domaine seront filtrés par le serveur de réception.

Policy faible

Les 3 valeurs valides pour définir le drapeau p (policy) sont:

none: ne rien faire lorsqu’un test échoue, i.e. accepter le mail,
quarantine: accepter me mail mais le marquer comme spam,
reject: rejeter les emails. Si vous sélectionnez la valeur none DMARC n’apporte plus aucune protection…

Policy de sous-domaine faible

Le drapeau sp (subdomain policy) est similaire au drapeau p (Policy). Il est utilisé pour définir la politique à appliquer aux sous-domaines. Là encore, si vous sélectionnez la valeur none DMARC n’apporte plus aucune protection à vos sous-domaines.

Enregistrements DKIM/SPF incorrects

DMARC repose sur les enregistrements SPF et DKIM. Si aucun des deux n’existe ou est valide, DMARC devient inutile. Mails et sécurité: DNS-SPF-DKIM-DMARC 1/3 Mails et sécurité: résultats de l’étude et bonnes pratiques 3/3

Tous les articles