Postfix/TLS - Considérations de Sécurité
Les sections suivantes couvrent quelques considérations de sécurités (possibles) en ce qui concerne Postfix/TLS.
Clef privée du client/serveur
Postfix/TLS utilise l'authentification du côté serveur (obligatoire) et du côté
client (facultatif). Afin de s'authentifier,
le processus défini (smptd/smtp) doit pouvoir accéder à la clef privée,
qui doit cependant être maintenue secrète.
Car ces processus sont lancés à partir de 'master' sans possibilité d'interaction
d'utilisateur, il n'est pas possible
de fournir un mot de passe, de sorte que la clef privée ne puisse pas être chiffrée.
La seule protection peut donc venu des droits d'accès de systéme de
fichiers, qui devraient être placés
à 'root' et ' lisible pour le propriétaire seulement
-rw------- 1 root sys 887 Apr 29 1999 /etc/postfix/key.pem
Cette protection n'est valable que si votre système est protégé
contre les failles de sécurités concernant root
Vous devez aussi vous rendre compte que des personnes ayant un accés physique
à la machine peuvent voler
la clef privée si ils peuvent démarrer la machine en mode 'superutilisateur'
(single-user) sans mot de passe
ou peuvent voler le disque et le monter sur un autre système où
ils sont super-utilisateur. (Oui je sais qu'il existe
des systémes de fichiers encryptés mais ils n'ont pas encore une
large diffusion)
Antémemoire de session sur le disque
Si vous utilisez l'antémemoire de session sur le disque (par défaut)
des personnes capables mettre la main sur les fichiers
devraient pouvoir éviter les paramètres de transmission sécurisée.
Cette situation n'est cependant pas plus grave que le cas
de la clef privée décrit ci-dessus, ainsi je ne considère aucun
danger supplémentaire venant de l'enregistrement information
de session sur un peripherique de stockage
Casser le cryptage avec un système de clefs n'est qu'une affaire de temps
(même si ce temps peut être très long), les sessions
ne devraient pas être utilisées indéfiniment. La valeur par défaut
pour Postfix/TLS est 1 heure, la RFC 2246 recommande
de ne pas utiliser les sessions plus de 24 heures
Solutions pour le DNS
Un point faible dans l'authentification est l'utilisation du DNS pour découvrir
le MX. Comme nous faisons du (E)SMTP
nous avons à utiliser les enregistrements MX.
Comme nous avons à authentifier le server découvert par le MX,
quelqu'un est capable d'usurper un faux enregistrement MX
pour être capable de recevoir le mail, si son serveur peut présenter un
certificat délivré par un CA acceptable. La dernière
partie n'est pas difficile si les certificat 'standarts' sont inclus (Verisign,
Thawte,...)
Le seul moyen de se protéger contre ce problème est que, pour
les destinataires pour lesquels nous voulons imposer le
chiffrement et l'authentification, la consultation de MX doit être ignorée avec
une entrée appropriée dans la table /etc/postfix/transport
domaine.tres.important smtp:[server.du.domaine.important]