Sécurité du serveur de messagerie
Lorsqu’il s’agit de configurations SSL/TLS, les serveurs de messagerie sont moins visibles que les serveurs Web. Ils devraient également bénéficier d’une configuration SSL/TLS solide avec des certificats valides.
Dans les protocoles IMAP et POP3, les serveurs de messagerie complètement mal configurés sont rapidement remarqués, mais des standards inadéquats sont souvent définis dans la communication serveur-serveur. Souvent, les certificats ne sont pas valides ou aucun certificat n’est accepté parce qu’une connexion est plus importante que la sécurité.
Configuration SSL/TLS chez Postfix
Ce qui suit est un extrait de la configuration principale de Postfix, qui peut changer à tout moment. Les options très importantes sont smtpd_tls_security_level
et smtp_tls_security_level
, qui sont “none” par défaut. Cela signifie que le serveur n’utilisera jamais TLS. Par conséquent, ces options devraient toujours être réglées sur may
ou encrypt
.
# Paramètres TLS
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTHTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULLL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH
smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
Configuration SSL/TLS chez Dovecot
Ceci est un extrait de la configuration Dovecot et montre une configuration possible des paramètres SSL/TLS pour Dovecot.
# DH parameters length to use.
ssl_dh_parameters_length = 4096
# SSL protocoles à utiliser
ssl_protocols = !SSLv2 !SSLv3
# Chiffres SSL à utiliser
ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
# Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes
Cadre de politique de l’expéditeur (SPF)
A l’aide de SPF (RFC 7208), il est possible de valider si un serveur qui souhaite livrer un e-mail est également autorisé à envoyer des e-mails depuis le domaine correspondant.
Par exemple, le serveur smtp.send.send.example.com se connecte au serveur smtp.recv.recv.example.com et essaie de lui envoyer un e-mail depuis user@mail.example.com. En utilisant SPF, le serveur smtp.recv.example.com peut vérifier si le serveur smtp.send.example.com est un serveur de messagerie valide pour le domaine mail.example.com.
L’enregistrement SPF correspondant existe dans le système DNS et peut ressembler à ceci:
mail.exemple.com. IN TXT "v=spf1 ip4:192.0.0.2.0/24 ip6:2001:db8::1 a ~all".
Cela signifie que si l’une des conditions suivantes est remplie, le courriel sera accepté :
- l’adresse IP du serveur smtp.send.send.example.com est dans
192.0.2.0/24
ou2001:db8::1
- le DNS A Record mail.example.com correspond à l’adresse IP du serveur smtp.send.example.com
Dans tous les autres cas, l’e-mail doit passer par des contrôles supplémentaires (qui peuvent être définis par l’utilisateur).
Signatures DKIM (DomainKeys Identified Mail)
L’idée derrière DomainKeys Identified Mail (DKIM, RFC 6376) est de vérifier qu’un e-mail n’a pas été modifié pendant le transport. Pour ce faire, les en-têtes, le contenu et les pièces jointes d’un e-mail sont signés. Toutefois, l’en-tête entier n’est pas signé, car certains champs peuvent changer pendant le transport d’un e-mail. Le RFC vous suggère de signer les valeurs suivantes :
- From (REQUIRED)
- Reply-To
- Subject
- Date
- To, Cc
- Resent-Date, Resent-From, Resent-To, Resent-Cc
- In-Reply-To, References
- List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
Les signatures DKIM sont stockées dans l’en-tête d’un e-mail, le champ s’appelle signature DKIM
. La valeur de cette zone contient plusieurs paires de valeurs clés. Les plus importantes sont :
- v: DKIM version
- a: algorithm (e.g.
rsa-sha256
) - d: signing domain (origin Domain)
- s: selector
Un serveur de courrier électronique de réception peut utiliser le domaine et le sélecteur pour demander la clé de domaine actuelle via DNS. L’enregistrement DNS ressemble à ceci :
selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )
Si un e-mail est envoyé avec l’en-tête
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org;
s=mail; t=1498137281;
bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=;
h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;
b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=
l’entrée DNS TXT correspondante faisant référence à la clé est mail._domainkey._domainkey.example.org
.
Authentification, reporting et conformité des messages par domaine (DMARC)
Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) étend les mécanismes DKIM et SPF. Si aucun en-tête DKIM n’est présent ou si aucun enregistrement SPF n’est trouvé, rien n’est fait avec ces deux procédures et l’e-mail est traité normalement. La DMARC offre la possibilité de dire quoi faire avec un courriel qui n’a pas l’une ou l’autre de ces procédures ou les deux. DMARC est également un peu plus stricte en ce qui concerne le traitement DKIM, par exemple, l’adresse De doit correspondre au domaine dans le champ signature DKIM. Un autre point que la DMARC rend possible est le signalement des courriels envoyés incorrectement. Cela permet de demander des rapports aux serveurs de courrier électronique de réception.
Comme DKIM, DMARC est publié dans DNA. Une entrée possible ressemble à ceci :
_dmarc.example.com
IN TXT
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"
Les valeurs individuelles ont les significations suivantes :
- v : Version
- p : Politique dans ce domaine
- sp : Politique pour les sous-domaines
- pct : Pourcentage de “mauvais” courriels, à partir du moment où la politique devrait entrer en vigueur.
- rua : Rapport DMARC Adresse URI
Test
Vous pouvez tester manuellement avec openssl. Il ne s’agit que de commandes de base qui affichent le contenu du certificat de serveur sous forme de texte. Les suites de chiffrement peuvent également être testées, mais comme il s’agit de commandes longues et nombreuses, il est recommandé de le faire avec les services existants (par exemple, Hardenize). Si cela n’est pas souhaité ou techniquement impossible, Décodeur SSL peut également être installé localement, puisque le logiciel Open Source est disponible sur GitHub.
- SMTP
$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text
- IMAP
$ openssl s_client -connect example.com:143 -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text
Tester des fonctionnalités supplémentaires telles que SPF ou DMARC peut se faire très facilement en vérifiant simplement les enregistrements DNS :
# SPF Record
dig +short TXT exemple.com
"v=spf1 ip4:192.0.0.2.0/24 ip6:2001:db8::1 a ~all"
# DKIM
$ dig +short TXT mail._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB"
# DMARC
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.com"
Afin d’effectuer des tests plus complets avec une évaluation du contenu, différents fournisseurs tels que Hardenize ou MX Toolbox sont appropriés.
Poursuivant
En outre, il convient de noter que DNS-based Authentication of Named Entities (DANE) peut également être utilisé pour les serveurs de messagerie. Cependant, cela dépasse le cadre de ce billet de blog et sera traité dans un autre article. Il existe également de très bons guides d’utilisation pour les serveurs de messagerie, il convient de mentionner ici les deux suivants :