SPF

Permet de vérifier qu’un serveur/une IP puisse envoyé des mails pour le domaine en question.

Ce n’est qu’un champ dns à ajouter.

Exemple :

• pour OVH : "v=spf1 include:mx.ovh.com ~all"
• pour Infomaniak : « v=spf1 include:spf.infomaniak.ch include:spf.mailjet.com ~all« 

Il signifie que les paramètres SPF à utiliser sont ceux du domaine « inclus ». Par exemple pour mx.ovh.com :
text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all"

ATTENTION : Le champ SPF à une limite importante, il ne faut pas dépasser les 10 DNS lookups par champ SPF. Bien faire attention également à vos « include » qui peuvent en contenir eux-même également. Vous pouvez le vérifier via mxtool.com. Le code d’erreur « PermError » peut apparaitre dans vos logs si vous dépassez cette limite.

Une très bonne source pour ce champ SPF mais aussi les 2 éléments essentiels suivants, qui sont le minimum à mettre en place.

DKIM

Permet d’authentifier que le message est bien légitime. Pour cela, le serveur mail envoi une signature faite avec sa clé privée. Le serveur client vérifie la signature via la clé publique qui se trouve dans les DNS du domaine qui envoi le mail. Cette sécurité mail permet de s’assurer que le message n’a pas été altéré ou remplacé.

Si vous êtes chez Infomaniak, vous avez tout ce qu’il faut de configuré.

Chez Microsoft, vous deviez générer une clé pour chaque domaine. Dans M365, il faut aller sur https://security.microsoft.com/ > Stratégies et règles > Stratégies de menace > sous Règles – Paramètres d’authentification des e-mails > onglet DKIM

Pour OVH, il y a 3-4ans ce n’était toujours pas d’actualité….

Si vous vous auto-hébergez, il faut générer une paire de clé sur : https://dkimcore.org

Mettre la clé privée dans le serveur mail et la clé publique dans les dns :
Key001._domainkey.mondomaine.tld.=v=DKIM1;p=xxxxxxxxxxx
Selector Key001

publier la clé dans les dns, à faire chez votre registar dns si vous êtes en auto-hébergé ou chez microsoft:

source bien détaillée

Si vous êtres chez Microsoft, je vous conseille aussi d’utiliser leur relay pour envoyés vos mails serveurs et applicatif signé par le DKIM.

DMARC

Champ txt permettant de dire aux serveurs mails distants quoi faire avec les mails incorrectement reçu de leur domaine.
3 possibilités :

• Rejeter (Reject)
• Ne rien faire (none)
• Considérer comme suspect (quarantine) pour que les mails usurpés se mettent dans les spam des destinataire mais ne sont pas supprimé

Exemple de record pour commencer :
_dmarc.mondomain.tld=v=DMARC1; p=none;

_dmarc.mondomain.tld= v=DMARC1; p=quarantine;sp=quarantine

• p: Appliquez cette politique aux e-mails qui échouent au contrôle DMARC. Cette politique peut être définie sur ‘none’ (aucune), ‘quarantine’ (quarantaine) ou ‘reject’ (rejet). ‘none’ est utilisé pour collecter le rapport DMARC et obtenir un aperçu des flux d’e-mails actuels et de leur statut ;
• sp: Cette politique doit être appliquée aux e-mails provenant d’un sous-domaine de ce domaine qui échouent au contrôle DMARC. En utilisant cette balise, les propriétaires de domaine peuvent publier une politique ‘générique’ pour tous les sous-domaines ;

Si votre infrastructure est utilisée et que vous ne savez pas si des personnes de votre entreprise utilise des systèmes de newsletter tel que mailchimp, mailjet, etc ou que vous avez peut-être des serveurs utilisés ailleurs que sur votre infrastructure, je vous conseille de commencer par un « none » ou un « quarantine ».

Vous pourrez ensuite mettre en place du monitoring de rapport DMARC pour voir si tout est ok avant de passé à « reject » comme politique.

Si vous maîtrisez tout, faites quelques tests en « quarantine » durant quelques semaines avant de passer à « reject ».

Vous avez là un bon bagage pour la sécurité mail, et pour aller plus loin, je vous conseille l’article de nextinpact sur le sujet ou microsoft avec méthode d’introduction.

L’article Sécurité mail – SPF DKIM DMARC est apparu en premier sur Mon linux.

L’utilisation d’un relais tel que Microsoft 365 facilite la sécurisation de nos échanges mails, car une intégration de DKIM et DMARC est déjà gérée nativement! Si vous avez déjà vos mails ou l’ensemble de votre active directory, c’est dans cette direction qu’il faut se diriger pour une mise en place efficace.

Je suppose qu’il est possible de faire cela également avec Infomaniak pour ceux disposant de comptes pro chez eux. Avec mon compte perso je n’ai pas vu cette option. Avec OVH, oubliez directement! Du temps où j’étais encore client chez eux, j’avais parlé DKIM DMARC au support, et on m’a posés des questions pour savoir pourquoi je veux ces fonctions etc. Vraiment comme si j’étais un extraterrestre! On était tout de même en 2020… Rien n’était fait pour le mail mutualisé donc… Longtemps client perso et pro je suis passé chez Infomaniak pour la partie mutualisée en partie pour cela. J’arrête le OFF là

Configuration dans l’Exchange 365

Il faut créer un connector dans mail flow > connectors > Add a connector :

L’authentification est faite par adresse IP ou certificat valide. Il faut savoir que votre serveur relais interne postfix va lui-même se connecter sur VOTRE_DNS.mail.protection.outlook.com et celui-ci présente un certificat valide. Votre « client » va donc authentifier le serveur de Microsoft comme valide (notre serveur relais est client par rapport au relais M365).

L’authentification par IP est déjà suffisante en soit. Mais vous pouvez décider que les serveurs relais de Microsoft n’acceptent QUE les mails si le serveur client (votre relais SMTP) présente le bon certificat client. Ce qui fait qu’il y a une identification et authentification de part et d’autre!

• Configurer une restriction par votre IP publique de sortie :

• Configurer une restriction par un certificat valide : dans ce cas cela ne doit pas forcément être le certificat *.votredomain.tld, cela peut très bien être monrelais.mondomainetechnique.tld. La seule règle étant que ce certificat soit émis par une autorité de certification reconnue.

Mettre un certbot avec let’s encrypt sur votre serveur est envisageable si vous utilisez une vérification let’s encrypt par dns.

Si vous souhaitez plus d’infos, la documentation Microsoft est bien faite.

Remarque : Les limites d’envoie pour M365 sont larges et dépendent de votre licence.

Un mot sur le serveur Postfix

Il faut tout de suite savoir que Postfix est à la fois un serveur et un client. Il faut donc bien distinguer les directives. Veillez donc bien au début qui peut être :

• smtp_tls_xxx en tant que client
• smtpd_tls_xxx en tant que serveur

Notre serveur relais est serveur par rapport à nos serveurs internes. Il est client par rapport à Microsoft 365.

Configuration de notre relais mail Postfix

J’ai distingué les directives serveurs et clients pour que la configuration soit lisible.

Pour le comportement serveur du relais SMTP :

• smtpd_tls_security_level=may permet de spécifier que notre serveur accepte une liaison client en TLS mais également en clair. Il faut penser aux copieurs ou autre matériel ne gérant pas le TLS interne à notre réseau
• smtpd_tls_loglevel permet d’avoir une trace des connexions TLS dans les logs avec les ciphers pris en compte, pratique pour voir quel client envoie encore en clair et s’il peut être modifié
• smtpd_tls_cert_file et smtpd_tls_key_file renseignent le certificat et la clé utilisé en interne
• smtpd_tls_chain_files est le nouveau format pour pouvoir contenir plusieurs clés et certificats pour différents noms de domaine. Il faut toujours la clé et puis la chaîne de certificat et le certificat final
• smtpd_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés

### SERVER ###
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1

smtpd_tls_cert_file=/etc/xxx.crt
smtpd_tls_key_file=/etc/xxx.key
#alternative
#smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all

#optionel
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache



### CLIENT ###
relayhost = your-domain.mail.protection.outlook.com
smtp_tls_security_level = encrypt # optionnel : secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
#optionnel
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_chain_files = /etc/xxx.all

Pour le comportement client du relais SMTP :

• relayhost on vient mettre le DNS de notre tenant M365
• smtp_tls_security_level le niveau de securité minimal accepté en TLS. Je vous conseille secure
• smtp_tls_mandatory_ciphers high contient un « bundle » de ciphers satisfaisant
• smtp_tls_loglevel permet d’avoir une trace des connexions TLS
• smtp_tls_CAfile permet de spécifié le fichier des CA faisant autorité. Un fichier du système contient déjà les CA connus du monde
• smtp_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
• smtp_tls_chain_files spécifiez la chaine de certificats client qui est utiliser si vous aviez choisi une restriction par un certificat client pour votre connector M365. L’ordre dans la chaine est importante : votre clé privée, suivie de votre certificat, ensuite le certificat intermédiaire et pour finir le certificat du CA

host xxx.mail.protection.outlook.com[104.47.2.7] said: 550 5.4.1 Recipient address rejected: Access denied. AS(201776281) [AB4EUR01RT057.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT TO command)

postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: matched peername: *.mail.protection.outlook.com
postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: subject_CN=mail.protection.outlook.com, issuer_CN=DigiCert Cloud Services CA-1, fingerprint=6A:DD:32:6D:2A:0C:C5:3A:9E:D7:E7:91:3D:6F:5C:F4, pkey_fingerprint=20:78:41:CD:EC:4F:19:7A:E0:B2:01:4F:3C:3D:1C:EE
postfix/smtp[71318]: Verified TLS connection established to your-domain.mail.protection.outlook.com[104.47.0.36]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Fichier main.cf d’un relais SMTP Postfix complet :

myorigin = /etc/hostname
mydomain = your-local-domain
mydestination = $myhostname, $myorigin, localhost.localdomain, localhost, localhost.your-local-domain

# Backward compatibility off
compatibility_level = 3.6
relay_domains = $mydestination
append_dot_mydomain = yes
smtputf8_enable=yes
smtpd_banner = $myhostname ESMTP
biff = no
readme_directory = no

# TLS parameters server
smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all
#alternative
#smtpd_tls_cert_file=/etc/xxx.cer
#smtpd_tls_key_file=/etc/xxx.key
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# TLS parameters client
relayhost = xxx.mail.protection.outlook.com
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Client certificat to be identified by M365
#smtp_tls_chain_files = /etc/xxx.all

smtpd_client_restrictions = permit_mynetworks reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mynetworks = 10.0.0.0/22,xxx
mailbox_size_limit = 0
message_size_limit = 29480000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

header_checks = regexp:/etc/postfix/header_checks_regexp
smtp_header_checks = regexp:/etc/postfix/replace_header_checks_regexp

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

Configuration d’un serveur client interne linux

Voici la partie TLS d’un fichier main.cf d’un postfix « satellite » qui se connecte à notre relais interne. Il dois évidement avoir le certificat serveur de notre relais ou notre CA interne de configuré dans les certificats du système ou via la directive smtp_tls_CAfile.

smtp_tls_security_level = may
smtp_tls_loglevel = 1
#optionnel
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

L’article Relais mail Postfix – envoyer ses mails sécurisés vers M365 est apparu en premier sur Mon linux.