Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND

Notre serveur de mail possède une identification SPF, Sender-ID et DKIM et est sécurisé par un certificat TLS. Nous allons aujourd’hui voir comment lui adjoindre l’authentification DMARC.

Aux origines de l’authentification des emails

Les technologies d’authentification des emails SPF et DKIM ont été développées afin de fournir une plus grande assurance sur l’identité de l’expéditeur d’un message.

L’adoption de ces technologies a augmenté régulièrement mais le problème des emails frauduleux et trompeurs n’a pu etre réglé.

Il existe une multitude d’environnements et de systèmes différents pour envoyer des emails, et on fait souvent appel à des applications tierces pour gérer les envois.

S’assurer que chaque message peut être authentifié avec SPF ou DKIM n’est pas une mince affaire étant donné que le traitement des emails se fait en temps réel.

Si le propriétaire d’un domaine envoie un groupe de message et que certains peuvent être authentifiés et d’autres non, alors les récipiendaires de ces messages sont obligés de faire la distinction entre les messages légitimes qui ne sont pas authentifiés et les messages frauduleux qui ne sont pas authentifiés non plus.

Par nature, les algorithmes de spam sont sujets aux erreurs et doivent évoluer constamment pour répondre aux nouvelles tactiques des spammeurs. Au final, certains messages frauduleux parviendront toujours à atteindre la boite de réception du destinataire final.

Le seul moyen de résoudre ces problèmes est de partager l’information entre l’expéditeur et le destinataire. Les destinataires vont fournir des informations sur leur infrastructure d’authentification des messages et les expéditeurs vont dire aux destinataires quoi faire lorsqu’un message reçu n’est pas authentifié.

En 2007, Paypal a été pionnier dans cette approche et a construit un système avec l’aide de Yahoo! Mail puis Gmail. Les résultats ont été très probants, menant à une baisse du nombre des emails frauduleux qui se faisaient passer comme venant des serveurs de Paypal acceptés par les destinataires.

DMARC : un protocole d’authentification email

DMARC, qui signifie Domain-based Message Authentication, Reporting and Conformance est un protocole d’authentification email qui se base sur les protocoles SPF et DKIM – maintenant largement déployés – en ajoutant une fonction de rapport qui permet aux expéditeurs et destinataires d’améliorer et vérifier la protection du domaine contre les emails frauduleux.

DMARC se base sur le processus d’authentification des messages entrants et aide les destinataires à déterminer si les message est “aligné” avec ce que le destinataire connaît de l’expéditeur. Sinon, DMARC inclut une manière de gérer les messages “non-alignés”.

Voici le principe de fonctionnement de DMARC :

Il est important de noter que DMARC est basé à la fois sur les spécifications de DKIM (DomainKeys Identified Mail) et SPF (Sender Policy Framework) qui sont toujours en cours de développement par l’IETF.

DMARC a pour but de remplacer ADSP en ajoutant le support pour:

• des wildcards ou des politiques de sous-domaines,
• des sous-domaines non-existants,
• des implémentations lentes (par exemple avec des expérimentations avec des pourcentages),
• SPF,
• la quarantaine des emails.

DMARC cherche donc à satisfaire les besoins suivants :

• minimiser les faux-positifs,
• fournir des rapports robustes sur l’authentification,
• réduire le nombre de mails de phishing,
• minimiser la complexité,
• fonctionner à l’échelle d’Internet.

Anatomie d’un enregistrement DMARC

Voici à quoi ressemble un enregistrement DMARC complet :

_dmarc TXT ( "v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc@example.com;ruf=mailto:dmarc@example.com;rf=afrf" )Code language: JavaScript (javascript)

Intéressons-nous maintenant à la valeur de l’enregistrement:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc@example.com;ruf=mailto:dmarc@example.com;rf=afrf

Voici un petit tableau récapitulatif qui explique à quoi correspondent les tags et quelles valeurs peuvent leur être associées:

Tag	Valeur	Explication
v	v=DMARC1	Version du protocol: DMARC1.
p	quarantine	Politique à appliquer aux emails qui échouent au test DMARC. Valeurs possibles: ‘none’, ‘quarantine’, ou ‘reject’. ‘none’ est utilisé pour récupérer des statistiques.
sp	quarantine	Politique à appliquer aux emails d’un sous-domaine de l’enregistrement DMARC et qui échouent au test DMARC. Ce tag permet au détenteur du domaine de publier explicitement une politique de sous-domaine wildcard.
pct	100	Pourcentage de temps pendant lequel on applique la politique DMARC. 100% indique que l’on veut tester les emails 100% du temps. NOTE: vous devez avoir une politique ‘quarantine’ ou ‘reject’ pour que ce tag soit actif.
adkim	r	Spécifie le mode alignement pour les signatures DKIM. ‘r’ est pour Relaxed, ‘s’ pour Strict. Le mode Relaxed permet des domaines authentifiés par DKIM et qui partagent un Organizational Domain commun avec l’entête header-From: domain de passer le test DMARC avec succès. Le mode Strict demande une adéquation entre le domaine DKIM et le domaine header-From: de l’email.
aspf	r	Spécifie le mode alignement pour SPF. ‘r’ est pour Relaxed, ‘s’ pour Strict. Le mode Relaxed permet des des domaines authentifiés par SPF et qui partagent un Organizational Domain commun avec l’entête header-From: domain de passer le test DMARC avec succès. Le mode Strict demande une adéquation entre le domaine SPF et le domaine header-From: de l’email.
fo	1	Forensic reporting options. Valeurs possibles: ‘0’ pour générer des rapports lorsque tous les méchanismes d’authentification ont échoué à produire un résultat DMAC valide, ‘1’ pour générer des rapports lorsqu’un des mécanismes a échoué, ‘d’ pour générer un rapport lorsque la signature DKIM n’est pas été vérifiée, ‘s’ lorsque SPF a échoué.
ri	86400	La fréquence d’envoi des rapports agrégés en XML. Vous recevrez des rapports une fois par jour avec ou sans ce réglage.
rua	mailto:dmarc@example.com	La liste d’adresses (URI) à laquelle envoyer les rapports XML. NOTE: ce ne doit pas être une liste d’adresses emails mais une liste d’URIs sous la forme ‘mailto:address@example.org’.
ruf	mailto:dmarc@example.com	La liste d’adresses (URI) à laquelle envoyer les rapports forensics. NOTE: ce ne doit pas être une liste d’adresses emails mais une liste d’URIs sous la forme ‘mailto:address@example.org’.
rf	afrf	Le format pour les rapports individuels forensics. Soit ‘afrf’, soit ‘iodef’.

Ajout d’un enregistrement DMARC

En pré-requis, vous devez avoir implémenté l’identification SPF, Sender-ID et DKIM car DMARC est basé sur ces protocoles.

L’enregistrement DMARC est un enregistrement au niveau du serveur DNS. C’est donc une ligne à rajouter dans l’interface DNS de votre registrar, ou directement dans le fichier de votre zone DNS sous BIND.

On édite donc notre fichier de zone:

nano /etc/bind/skyminds.net.hosts

Et on y ajoute:

; DMARC record for skyminds.net
; Record should be published at _dmarc.skyminds.net
_dmarc TXT ( "v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc@skyminds.net;ruf=mailto:dmarc@skyminds.net;rf=afrf" )
_dmarc.skyminds.net TXT ( "v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc@skyminds.net;ruf=mailto:dmarc@skyminds.net;rf=afrf" )Code language: JavaScript (javascript)

Il existe un assistant en ligne, DMARC Record Assistant, qui vous permet de sélectionner vos options et de créer un enregistrement DMARC adapté à vos besoins.

Enregistrez le fichier et relancez BIND:

service bind9 restart

N’oubliez pas de resigner votre fichier de zone si vous utilisez DNSSEC.

Intégration d’OpenDMARC à Postfix

Il nous reste maintenant à intégrer opendmarc à Postfix. On installe donc le paquet opendmarc:

apt install opendmarc

On édite ensuite le fichier de configuration d’opendmarc:

nano /etc/opendmarc.conf

On y ajoute ou modifie les lignes suivantes :

    AuthservID mail.example.com
    PidFile /var/run/opendmarc.pid #Debian default
    RejectFailures false
    Syslog true
    TrustedAuthservIDs mail.example.com,mail2.example.com
    UMask 0002
    UserID opendmarc:opendmarc
    IgnoreHosts /etc/opendmarc/ignore.hosts
    HistoryFile /var/run/opendmarc/opendmarc.dat
    #for testing:
    SoftwareHeader trueCode language: PHP (php)

Explications :

AuthservID: mettez l’hostname de votre serveur (mail.example.com)

PidFile: chemin du fichier PID

RejectFailures: true or false. Si la valeur est true alors tous les messages qui ne passeront pas la vérification DMARC seront rejetés. Je préfère avoir les messages donc je garde la valeur à false.

Syslog: true or false. Active les logs ou non.

TrustedAuthservIDs: ces AuthservIDs sont considérés comme nécessitant la validation DMARC. Utile lorsque plusieurs serveurs MX sont présents et qu’ils n’ont pas tous besoin d’être validés par DMARC.

UMask: du fichier PID et du fichier de socket.

UserID: utilisateur et groupe qui gère le service dmarc.

IgnoreHosts: chemin du fichier d’exclusion.

HistoryFile: chemin du fichier d’historique. Nécessaire pour envoyer des rapports à d’autres organisations.

SoftwareHeader: ajoute un entête “Dmarc-Filter” avec la version opendmarc à chaque email traité. Utile pour la phase de test.

On crée maintenant le fichier d’exclusion :

mkdir /etc/opendmarc/
nano /etc/opendmarc/ignore.hosts

et on y ajoute la liste des réseaux et domaines de confiance. Les emails de ces domaines ne seront pas vérifiés par DMARC:

localhost
10.0.0.0/24

On configure maintenant le fichier default d’opendmarc:

nano /etc/default/opendmarcCode language: JavaScript (javascript)

avec une directive SOCKET:

SOCKET="inet:54321@localhost"Code language: JavaScript (javascript)

On demande à ce qu’opendmarc soit lancé au démarrage du serveur :

systemctl enable opendmarc

Résultat:

Synchronizing state of opendmarc.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable opendmarcCode language: JavaScript (javascript)

On démarre opendmarc :

service opendmarc start

Opendmarc est lancé, on peut maintenant passer à la configuration de Postfix:

nano /etc/postfix/main.cf

Il faut retrouver les directives milters que nous avions configurées pour OpenDKIM et ajouter les milters d’opendmarc après celles d’opendkim (très important car opendmarc a besoin des résultats du test DKIM) :

smtpd_milters = inet:localhost:12345,inet:localhost:54321
non_smtpd_milters = $smtpd_miltersCode language: PHP (php)

On sauvegarde la configuration de Postfix et on recharge sa configuration:

service postfix reload

Votre serveur de mail est maintenant capable de procéder à la vérification DMARC pour le courrier entrant.

Test de la configuration DMARC

Il nous reste maintenant à tester que notre configuration est correcte et que l’entête DMARC est bien présent dans le processus d’identification de nos messages.

DMARC Inspector par dmarcian est un très bon outil qui vous permet de visualiser l’entête, ainsi que sa configuration. Notez qu’il est beaucoup plus prudent d’expliciter chaque valeur que de se reposer sur une valeur par défaut (implicite) qui serait susceptible de changer avec le temps.

La page des outils de déploiement DMARC est très exhaustive.

Lectures complémentaires

• DMARC
• HOWTO – Define a DMARC Record
• DMARC Inspector par dmarcian
• DMARC Record Assistant

Articles conseillés :

• Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
• Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur
• 8 règles d’or pour bien déployer DNSSEC et DANE
• Serveur dédié : mise en place du protocole DANE
• Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
• Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”