web-dev-qa-db-fra.com

Configuration parfaitement sécurisée de Postfix MTA (SMTP)

Je veux sécuriser mon serveur racine (plus loin) service par service, en commençant par le service SMTP (Postfix MTA) comme le plus occupé. Au cours de tout configurer, j'ai beaucoup lu sur la sécurité et le cryptage et j'ai fait de mon mieux pour rassembler les informations les plus précieuses. Cependant, certains problèmes semblent persister et je ne trouve rien d'autre pour rendre la configuration parfaite.

Comportement souhaité

Je souhaite que le service soit aussi restrictif que possible, c'est-à-dire que j'utilise un cryptage sécurisé dans la mesure du possible. L'authentification ne doit être autorisée qu'après STARTTLS (soumission) avec cryptage sécurisé .

  • Communication de serveur à serveur: hautement crypté, non crypté uniquement si nécessaire
  • Communication client-serveur: hautement crypté uniquement
  • Authentification client uniquement au port 587 (facultatif?)

Différenciation

La principale préoccupation est la sécurité, le chiffrement et en particulier les paramètres liés à la sécurité pour Postfix MTA. Je ne cherche pas de conseils pour des solutions anti-spam ou anti-virus - c'est une toute autre affaire. Le chiffrement des e-mails n'est pas une option car le souci est plutôt la confidentialité que l'authenticité, ce qui ne justifie pas en fin de compte l'effort déraisonnablement élevé côté client.

Configuration actuelle

  • Serveur: Debian 7 (Wheezy)
  • MTA: Postfix 2.9.6
  • Certificat CaCert: 4096 bits/sha512-RSA

Fichier /etc/postfix/main.cf extrait:

tls_random_source=dev:/dev/urandom

# Incoming
smtpd_tls_cert_file=/etc/ssl/cacert/certs/example.com.crt
smtpd_tls_key_file=/etc/ssl/cacert/private/example.com.key
smtpd_use_tls=yes
smtpd_tls_auth_only=yes
smtpd_tls_security_level=may
smtpd_tls_mandatory_ciphers=high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# Outgoing
smtp_tls_cert_file=/etc/ssl/cacert/certs/example.com.crt
smtp_tls_key_file=/etc/ssl/cacert/private/example.com.key
smtp_use_tls=yes
smtp_tls_security_level=may
smtp_tls_mandatory_ciphers=high
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# SASL Authentication (dovecot)
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
broken_sasl_auth_clients = no

smtpd_recipient_restrictions =
   permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination

# prevent leaking valid e-mail addresses
disable_vrfy_command = yes

Fichier /etc/postfix/master.cf extrait:

smtp      inet  n       -       -       -       -       smtpd
submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Questions ouvertes

  • starttls.info déclare:

    Il existe un certificat auto-signé dans la chaîne de confiance [...] Il existe des problèmes de validité pour le certificat. Les certificats sont rarement vérifiés pour les serveurs SMTP, cela ne signifie donc pas que STARTTLS ne sera pas utilisé. De manière générale, c'est une mauvaise pratique de ne pas avoir de certificat valide, et une pratique encore pire de ne pas les vérifier. Toute tentative de communication cryptée est laissée pratiquement ouverte aux attaques de Man-in-the-Middle.

    Est-ce un problème concernant la communication de serveur à serveur? Si oui, puis-je faire quelque chose pour améliorer cela sans payer de certificat ? (Je n'ai que des clients que je connais personnellement)

  • Le même site déclare:

    Diffie-Hellman anonyme est accepté. Ceci est suspecté par les attaques de Man-in-the-Middle.

    Quel paramètre est nécessaire pour les désactiver? (voir également l'élément de liste suivant)

  • testssl.sh montre les problèmes du port 587:

    --> Testing standard cipher lists
...
 Anonymous NULL Cipher    offered (NOT ok) 
 Anonymous DH Cipher      offered (NOT ok) 
...

    Il s'agit probablement du même problème que l'élément précédent.

  • testssl.sh montre les problèmes du port 25:

    --> Testing Protocols
 SSLv3      offered (NOT ok)
...
--> Testing standard cipher lists
...
 Anonymous NULL Cipher    offered (NOT ok) 
 Anonymous DH Cipher      offered (NOT ok) 
 40 Bit encryption        offered (NOT ok) 
 56 Bit encryption        Local problem: No 56 Bit encryption configured in /usr/bin/openssl 
 Export Cipher (general)  offered (NOT ok) 
 Low (<=64 Bit)           offered (NOT ok) 
 DES Cipher               offered (NOT ok)
 Triple DES Cipher        offered
 Medium grade encryption  offered
...
RC4 seems generally available. Now testing specific ciphers...
...

    Cela s'applique-t-il uniquement à la communication de serveur à serveur? Sinon, comment est-ce possible? Au moins SSLv3 doit être désactivé selon le main.cf fichier. Comment résoudre ces problèmes?

  • ssl-tools.net indique:

    * .example.com - Le certificat ne correspond pas au nom d'hôte

    Probablement pas un problème de sécurité en soi, mais intéressant en combinaison avec le premier point ci-dessus. Quel nom d'hôte dois-je choisir si un certificat générique n'est pas correct? example.com ou Host.example.com ?

  • Que puis-je faire d'autre pour rendre la configuration parfaitement sécurisée?

encryptiontlssmtpstarttls
16
08frak

Petite tangente - SMTP n'est pas sécurisé, vous ne parlez que du MTA. Les modes de validation du certificat TLS (validation du sujet) ne sont qu'un petit sous-ensemble et peu importe si d'autres problèmes sont résolus. Par exemple, si vous utilisez SMIME ou PGP, TLS peut ne pas avoir d'importance. Cela dépend de vos menaces.

Vous dites que TLS est préféré et non chiffré si nécessaire. C'est ce qu'on appelle le chiffrement opportuniste. La plupart des MTA modernes le font.

Oui, les certificats TLS privés auto-signés sont courants et fréquemment utilisés. Vous n'avez pas à valider le certificat. Cependant, en raison de la mutualisation et d'autres problèmes, il est impossible de lier le nom de domaine au certificat lui-même.

Sachez que si vous insistez sur les connexions TLS entrantes à partir d'un domaine donné, vous manquerez les e-mails de diffusion envoyés par des publipostages autorisés par les enregistrements SPF. Je connais plusieurs banques qui envoient des alertes de sécurité via un service de diffusion qui n'utilise pas TLS pour l'évolutivité.

Il vous manque AV/AS, l'analyse de contenu/lien, la sécurité MUA, la liste blanche, DKIM, SPF, DMARC, SMIME, PGP, BATV, les attaques de récolte d'annuaire, ... la liste s'allonge encore et encore et encore.

4
goodguys_activate

Il est important de noter qu'il existe une grande différence entre les expéditeurs SMTP publics (qui peuvent utiliser le port 25 et envoyer du contenu non crypté) et la soumission du client qui est utilisée pour l'authentification et le transfert de contenu client-serveur sécurisé.

Je préfère ne pas compter sur les expéditeurs publics paranoïaques et le niveau de sécurité, mais pensez toujours à la sécurité des utilisateurs du domaine et au niveau confidentiel d'utilisateur à utilisateur.

Tout d'abord, je suggère de créer votre propre certificat de CA et de serveur de soupir avec ce certificat racine ou intermédiaire, de distribuer ce certificat entre les utilisateurs et de l'installer en tant que certificat de confiance. Cela évitera toute attaque mitm et sécurisera l'échange de données client-serveur. Deuxièmement - veuillez exclure SSLv2 et les protocoles inférieurs. J'exclus même SSLv3. Il est également préférable d'attribuer une liste de chiffrement acceptable. Voici un exemple de configuration pour postfix.

smtpd_tls_protocols = !SSLv2,!SSLv3,TLSv1,TLSv1.1,TLSv1.2
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_mandatory_ciphers =HIGH 
smtpd_tls_exclude_ciphers=aNULL:eNULL:LOW:3DES:MD5:MEDIUM:EXP:PSK:DSS:RC4:SEED:ECDSA:CAMELLIA256-SHA
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Pour les expéditeurs non sécurisés, je ferme la liste des destinataires et j'ajoute un enregistrement spf au DNS pour éviter tout relais. Vous pouvez limiter manuellement les serveurs locaux en les supprimant des "réseaux virtuels" ou en ajoutant des restrictions d'expéditeur, où les adresses d'expéditeur locales seront rejetées par défaut.

smtp  inet  n  - - - -  smtpd -o content_filter=spamassassin
   -o smtpd_sender_restrictions=permit
   -o smtpd_recipient_restrictions=permit_mynetworks,mysql:/etc/postfix/mysql-receiver.cf,reject

Quant à la partie soumission (uniquement pour les utilisateurs du domaine), il est préférable de demander un chiffrement qui évite l'envoi de mots de passe simples sur des réseaux publics non sécurisés.

submission inet n   -   n   -   -   smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_tls_security_level=may # (! possible to force, but limits mail clients list and not recommended at all - non standard) -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=/var/spool/postfix/private/dovecot-auth
  -o smtpd_sasl_security_options=noplaintext # or (!!! - use according to your paranoid level)  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_recipient_restrictions=mysql:/etc/postfix/mysql-receiver.cf,permit_mynetworks,permit_sasl_authenticated,reject_non_fqdn_recipient,reject
  -o smtpd_sasl_authenticated_header=yes

Avec la configuration présentée, nous obtenons:

  • cryptage client vers serveur et obligation d'authentification sasl du port 587
  • tls de serveur à serveur activés (mais je suggère d'utiliser des tunnels vpn pour la communication d'infrastructure de toute façon).
1
ETech