L’anti-relayage
Pour éviter que l’on utilise votre serveur smtp comme relai de messagerie, vous devez configurer le paramètre smtp_recipient_restrictions dans le fichier principal de configuration /etc/postfix/main.cf. Il regarde en fait le champ RCPT TO.
smtpd_recipient_restrictions = permit_mynetworks,check_relay_domains
La valeur permit_mynetworks autorise postfix à relayer les mails... Ce qui n’est pas une mauvaise solution. La valeur permit_mynetworks signifie que postfix autorise à relayer les mails venant d’adresses IP contenues dans $mynetworks. La valeur check_relay_domains elle, permet soit de relayer des messages venant d’adresses IP contenues dans $relay_domains, soit à destination de $relay_domains, ou bien si la destination est $inet_interfaces, $mydestination, ou $virtual_maps. Reste a définir ces valeurs toujours dans main.cf :
mynetworks = 192.168.0.0/24, 127.0.0.0/8
relay_domain = domain.fr
D’autres valeurs existent. Par exemple, reject_unknown_recipient_domain permet de rejeter les mails si le domaine de l’adresse mail du destinataire n’est pas resolvable. Beaucoup d’autres valeurs existent. La
documentation html/uce.html vous en dira plus sur ces valeurs.
Chrooter le démon
Plutôt qu’une longue explication, voici une définition du chroot :
" Commande modifiant l’emplacement de la racine du système de fichier, par exemple pour leurrer un programme afin que des utilisateurs malintentionnés ne puissent pas s’aventurer dans la vraie racine. Surtout utilisé pour les serveurs FTP."
Le fait de chrooter Postfix ne rend pas notre système impénétrable, mais limite tout de même les possibilités d’intrusion. Nous avons deux solutions pour mettre en place le chroot. Soit nous utilisons le script examples/chroot_setup/LINUX2 et nous l’adaptons éventuellement, soit nous faisons tout manuellement. Dans les deux cas, les répertoires etc, usr/lib, lib sont créés dans le répertoire /var/spool/postfix, certains fichiers sont copiés et postfix est rechargé. Personnellement, j’ai utilisé le script qui fonctionnait très bien chez moi.
Le fichier de configuration /etc/postfix/master.cf doit ensuite être adapté pour définir la façon dont sont executés les différents progammes de Postfix :
#
# Postfix master process configuration file. Each line describes how
# a mailer component program should be run. The fields that make up
# each line are described below. A "-" field value requests that a
# default value be used for that field.
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
# ==========================================================================
smtp inet n - y - - smtpd
pickup fifo n n y 60 1 pickup
cleanup unix - - y - 0 cleanup
qmgr fifo n - y 300 1 qmgr
#qmgr fifo n - y 300 1 nqmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - n - 0 bounce
flush unix - - y 1000? 0 flush
smtp unix - - y - - smtp
showq unix n - y - - showq
error unix - - n - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
cyrus unix - n n - - pipe
flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=F. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
Ce fichier de configuration décrit la facon dont chaque programme de Postfix est lancé. Pour cela, le champ chroot est mis à 'y' pour chaque service que nous utilisons et que nous voulons chrooter. Les autres services peuvent rester par défaut. Un petit reload de postfix s'impose:
$postfix reload
L’anti-spam
Là encore, Postfix se distingue par sa simplicité de configuration. Pour éviter le spam, vous avez deux paramètres à configurer dans le fichier main.cf : smtpd_client_restrictions et smtpd_sender_restrictions. Le premier agit au niveau de la connexion d’un client sur le serveur de mail, tandis que le deuxième vérifie le champ MAIL FROM du mail.
Voici la facon dont j’ai configuré ces deux paramètres :
smtpd_client_restrictions = reject_unknown_client, permit_mynetworks, \
check_client_access hash:/etc/postfix/access, \
reject_maps_rbl
smtpd_sender_restrictions = reject_unknown_sender_domain, check_sender_access \
hash:/etc/postfix/access, \
reject_non_fqdn_sender, reject_maps_rbl
Note : Les anti-slashes signifient que les valeurs doivent etre sur la meme ligne. En ce qui concerne smtpd_client_restrictions :
reject_unknown_client signifie que le serveur rejète le client si son adresse IP n’a pas d’enregistrement PTR (enregistrement qui établit une relation entre l’addresse IP et le nom complet d’un hote ou fqdn) dans le DNS.
permit_mynetworks a été vu précédemment
check_client_access signifie que le serveur accepte ou rejète le client selon les régles du fichier spécifie hash :/etc/postfix/access (hash représente le type du fichier). Nous verrons plus loin la façon de configurer ce fichier.
reject_maps_rbl signifie que le client sera rejeté s’il fait partie des black-lists que nous devons spécifier dans le paramètre maps_rbl_domains.
Quant à smtpd_sender_restrictions :
reject_unknown_sender_domain signifie que le serveur rejète la requête si l’adresse email de l’émetteur n’a pas d’enregistrement A (enregistrement qui établit une relation entre le nom d’hote et l’adresse IP) ou MX (enregistrement qui détermine le serveur de mail du domaine) dans le DNS.
check_sender_access signifie que le serveur accepte ou rejète la requête selon les règles du fichier /etc/postfix/access.
reject_non_fqdn_sender signifie que la requête est rejetée si l’adresse email n’est pas un nom de domaine complet.
reject_maps_rbl a déja été vu.
Reste donc à paramétrer le fichier /etc/postfix/access :
$/bin/cat /etc/postfix/access
valide@domain.com OK
non-valide@domain.com REJECT
spam.com REJECT
Un ’man 5 access’ vous donne plus de précisions sur ce fichier et la façon de le configurer.
Une fois terminé, et à chaque modification ultérieure de ce fichier, il faut reconstruire la base de données correspondante :
$postmap /etc/postfix/access
$ls -l /etc/postfix/access*
-rw-r--r-- 1 root root 17 May 1 21:39 /etc/postfix/access
-rw-r--r-- 1 root root 4096 May 1 21:39 /etc/postfix/access.db
Filtrage des headers
Nous venons de voir que Postfix permet de filtrer les mails entrants. Il permet en plus le filtrage des headers des messages à l’aide d’expressions régulières. Tout ce qu’il vous suffit de faire est de paramétrer header_checks dans le fichier main.cf :
header_checks = regexp:/etc/postfix/regexp
ou le fichier /etc/postfix/regexp contient par exemple :
/^postmaster@.*$/ OK
/^To: foobar/ REJECT
Un ’man 5 regexp_table’ vous donnera de plus amples renseignements au sujet de ce fichier.
Ce qu’il reste à faire
Quelques paramètres restent à configurer pour que notre serveur mail soit assez sécurisé. Le paramètre mail_name dans main.cf définit le nom du logiciel de mail dans l’entête "Receveid :". L’intérêt ici est de diffuser le moins d’information possible. Donc si nous mettons mail_name = Microsoft Exchange, voila ce qui apparaitra dans les entêtes des mails :
Received : by neptune.galaxie.fr (Microsoft Exchange , from userid 1000)
id F0A42C946 ; Wed, 2 May 2001 00:18:32 +200 (CEST)
C’est aussi possible de configurer la bannière :
mail_version = 5.5
smtpd_banner = ESMTP $mail_name ($mail_version)
Voici ce que nous obtenons :
$telnet localhost 25
Trying 127.0.0.1...
Connected to neptune.
Escape character is '^]'.
220 ESMTP Microsoft Exchange (5.5)
Dernier paramètre à configurer, disable_vrfy_command toujours dans le fichier main.cf. Il suffit de le mettre à ’yes’ pour désactiver la commande vrfy. Cette commande sert à vérifier les utilisateurs valides. Pour la commande expn, il n’y a rien à faire car elle n’est pas implémentée dans Postfix.
Autre point important, le démon syslogd. Vous devez le configurer pour qu’il prenne en compte les logs de votre serveur de mail. Rajoutez donc dans votre syslog.conf, les lignes suivantes :
mail.* /var/log/mail.log
mail.info /var/log/mail.info
mail.warn /var/log/mail.warn
mail.err /var/log/mail.err
Et relancez le démon syslogd.
Conclusion
Toutes les fonctionnalités de Postfix n’ont pu être abordées dans ce document. Des sujets tels que l’intégration d’OpenLDAP, ou de TLS dans Postfix (serveur de mail sécurisé) auraient été très interessants à étudier. Une dernière chose qu’il est utile de préciser : aucune vulnérabilité à ma connaissance sur Postfix ne semble avoir été découverte.