Base de connaissances

UN peu d'histoire

À l'origine, les bases du courriel ont étés pensées pour s'échanger entre collègues à l'intérieur d'un même réseau d'entreprise, la technologie que nous utilisons aujourd'hui n'à pas vraiment évoluée depuis ses débuts et d'origine la sécurité n'était pas au rendez vous parce que nous n'avions pas encore figuré qu'internet allait devenir ce qu'il est aujourd'hui. Au fil des années, les ingénieurs d'internet ont ajouté des mécanismes de protection destinés à augmenter le niveau de sécurité des échanges en SMTP.

Les protocoles SPF et DKIM font parti de ces mesures et sont en soit très efficaces, ils permettent entre autre de bloquer les messages n'ayant pas les validations nécessaires ou n'ayant pas été envoyés par un serveur approuvé, mais ces mécanismes ne sont pas infaillibles et peuvent facilement êtres contournées.

Pour votre apprentissage personnel:

SPF ( Sender Policy Framework):
Permet de définir quelles adresses IP sont autorisées par votre nom de domaine à envoyer des courriels.

DKIM (DomainKey Identified Mail):
Permet de s'assurer que les messages envoyé/reçu ne soient pas altérés grâce à une validation d'une clé/signature cryptographique.

Ces 2 protections sur papier sont très efficaces voir même indispensables, le SPF et le DKIM vérifient le "Mailfrom" (l'expéditeur du message), mais ils n'inspectent pas le "From" (correspond au véritable expéditeur), en soit ces 2 protections ne vérifient pas si les informations concordent réellement, ce qui laisse une porte ouverte au contournement.

Comment fonctionne le DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) à été créé pour adresser la problématique expliquée plus haut. Il s'appuie dur le principe de "l'alignement" de votre domaine. Il vient directement agir sur les messages lorsque les protocoles SPF et DKIM échouent en vérifiant autant le "Mailfrom" et le "From". Si un des 2 élément est différent le message est traité par le serveur de réception (avant même que le courriel soit envoyé dans la boite de réception du destinataire) en fonction de la politique définie par l'enregistrement DMARC configuré pour ce domaine.

Politique DMARC:

none:
On ne fait que surveiller les résultats mais on ne prend aucune mesure concernant les messages reçus. Les courriels seront reçu normalement qu'ils soient légitimes ou pas mais un rapport sera envoyé à l'administrateur du domaine lorsqu'un message non aligné est reçu si cette option est configurée.

Quarantine:
Tous les messages qui échouent la validation définie par le DMARC vont directement en quarantaine, ils peuvent être traités ultérieurement.

Reject:
Tous les messages qui échouent la validation définie par le DMARC sont directement supprimés et ne seront jamais envoyés au destinataire.

Pour être en mesure de configurer un enregistrement DMARC, vous devez absolument configurer correctement votre enregistrement SPF et définir une clé DKIM pour votre domaine sinon vous risquez de créer plus de tord que de bien.

Avec une bonne politique DMARC, vous contribuez à lutter plus efficacement contre le spam et l'hameçonnage en ligne. Si vos courriels respectent bien vos enregistrements SPF et DKIM et l'alignement, ils passeront haut la main la protection DMARC et se rendront à vos destinataires, si un individu tente d'envoyer un courriel en votre nom, ce dernier ne pourra pas respecter les règles établies et sera plus facilement identifié comme spam ou fraude.

Les réglages DMARC:

Des exemples de DMARC:

Balises obligatoires

• v : balise de version qui identifie l'enregistrement récupéré en tant que DMARC record. Sa valeur doit être DMARC1 et elle doit être la première balise dans le DMARC record.
• p : balise qui indique la règle que vous souhaitez que les opérateurs de messagerie appliquent lorsque votre message échoue à l'authentification DMARC et aux contrôles d'alignement. Cette règle s'applique à un domaine principal (example.com) et à tous ses sous-domaines (m.example.com, b.example.com, etc.), à moins que la balise sp ne soit utilisée (voir ci-dessous) avec une valeur de règle différente.
  
  Les différentes valeurs de règles sont les suivantes :
  • Aucun
  • Mettre en quarantaine
  • Rejeter

Balises facultatives, mais recommandées

• rua=mailto:address@company.com : cette balise permet aux opérateurs de messagerie de savoir où vous souhaitez recevoir vos rapports agrégés. Les rapports agrégés fournissent une visibilité de l'état de vos campagnes email en identifiant les problèmes potentiels d'authentification ou l'activité malveillante. Ces rapports contiennent un niveau d'informations plus élevé et sont envoyés quotidiennement par les opérateurs de messagerie participants.
• fo : balise qui permet aux opérateurs de messagerie de savoir que vous souhaitez recevoir des échantillons des messages qui ont échoué lors de la vérification SPF et/ou DKIM. Il existe quatre options de valeur disponibles :
  • 0 : générer un rapport d'échec DMARC si tous les mécanismes d'authentification sous-jacents (SPF et DKIM) ne produisent pas un résultat « pass » (réussite) aligné. (par défaut)
  • 1 : générer un rapport d'échec DMARC si n'importe lequel des mécanismes d'authentification sous-jacents (SPF ou DKIM) a produit un résultat autre que le « pass » aligné. (recommandé)
  • d : générer un rapport d'échec DKIM si le message contenait une signature qui a échoué à l'évaluation, quel que soit son alignement.
  • s : générer un rapport d'échec SPF si le message a échoué à l'évaluation SPF, quel que soit son alignement.

Balises facultatives

• sp : cette balise sert à indiquer une règle requise pour tous les sous-domaines où le message échoue à l'authentification DMARC et aux contrôles d'alignement. Son efficacité est optimale lorsque le propriétaire d'un domaine précise des règles différentes pour le domaine principal et tous les sous-domaines. Les options de règles sont les mêmes que pour la balise « p » mentionnée ci-dessus. Si cette balise n'est pas utilisée pour les sous-domaines, la règle définie utilisant la balise p s'appliquera au domaine principal et à tous ses sous-domaines.
• adkim : indique un alignement des identifiants DKIM « strict » ou « relaxed » (souple). La valeur par défaut est « relaxed ».
• aspf : indique un alignement des identifiants SPF « strict » ou « relaxed ». La valeur par défaut est « relaxed ».
• pct : le pourcentage des messages auxquels la règle DMARC doit être appliquée. Cette balise fournit un moyen d'implémenter et de tester progressivement l'impact de la règle.
  • Les valeurs sont des nombres entiers compris entre 1 et 100. La valeur par défaut est 100.
• ruf=mailto:address@company.com: cette balise permet aux opérateurs de messagerie de savoir où vous souhaitez recevoir vos rapports d'investigation numérique (messages). Ces rapports sont plus détaillés et sont conçus pour être remis par les opérateurs de messagerie presque immédiatement après la détection d'un échec d'authentification DMARC. Toutefois, en raison de problèmes potentiels liées à la confidentialité et à la performance, la majorité des opérateurs de messagerie ne les envoient pas.
• rf : format pour les rapports d'échec de messages. Sa valeur par défaut est Authentication Failure Reporting Format ou « afrf ». Afrf est la seule valeur prise en charge à l'heure actuelle.
• ri : le nombre de secondes écoulées entre les envois de rapports agrégés à l'expéditeur. La valeur par défaut est 86 400 secondes, ce qui équivaut à un jour. Les opérateurs de messagerie participants qui sont en mesure d'envoyer plus d'un rapport agrégé par jour fourniront des rapports plus fréquents dans la mesure du possible.

Plus d'informations sur la balise RUF:

Le RUF ou le tag de rapport d’échec (ou forensique) du DMARC a été conçu pour informer les administrateurs de domaine des courriels qui échouent aux vérifications d’authentification SPF, DKIM et DMARC.

Dans un rapport RUF, le propriétaire du domaine peut voir l’adresse IP, le domaine d’envoi, le message et les en-têtes du courriel qui a échoué.

Le rapport RUF peut aider les administrateurs à identifier et à prévenir les activités malveillantes, telles que le spoofing, le phishing ou le spam.

Cependant, certains domaines préfèrent ne pas demander de rapports RUF pour des raisons de confidentialité et de sécurité. En effet, les rapports RUF peuvent contenir des informations sensibles sur les destinataires, les contenus ou les pièces jointes des courriels, qui pourraient être exposées à des violations de données ou à des abus.

De plus, les rapports RUF peuvent être volumineux et difficiles à analyser, ce qui nécessite des ressources et des compétences supplémentaires de la part des administrateurs.
Certains secteurs d’activité, tels que la finance, la santé, l’éducation ou le gouvernement, peuvent également être soumis à des lois strictes sur la protection des données, qui limitent l’utilisation et le partage des rapports RUF.

C'est pourquoi nous ne recommandons pas l'activation du rapport RUF de base, utilisez le en connaissance de cause.