Guide à l'installation d'une infrastructure de courriel basée sur des composantes de logiciel libre

Transcription

1 Guide à l'installation d'une infrastructure de courriel basée sur des composantes de logiciel libre Version 1.0 Steve Johnson Victrix 28 février 2005

2 Table des Matières PRÉFACE... 4 LOGICIELS UTILISÉS... 6 AUTHENTIFICATION... 8 OpenLDAP...8 Configuration du serveur OpenLDAP...8 Configuration du client OpenLDAP...10 Population de l annuaire OpenLDAP...11 Création des comptes administratifs dans l annuaire...12 PAM...13 SASLAUTHD...14 SERVEUR DE RELAIS SMTP Postfix...16 Création du RPM...16 Configuration...16 FILTRAGE DE COURRIELS INDÉSIRABLES ClamAV...22 clamd...22 freshclam...23 SpamAssassin...23 Razor Entraînement de SpamAssassin...24 amavisd-new...25 Concept...25 Pré-requis...25 Configuration...26 Intégration...27 SERVEUR PRINCIPAL SMTP SERVEUR IMAP ET POP Cyrus IMAPD...30 Création des RPM...30 Configuration des services de Cyrus...31 Configuration du service IMAP...31 Gestion des boîtes de courriels

3 INTERFACE IMAP WEB SquirrelMail...34 Sécurisation via SSL...35 ANNEXE 1 : FICHIERS DE CONFIGURATION DE SASLAUTHD ANNEXE 2 : FICHIERS DE CONFIGURATION DE OPENLDAP ANNEXE 3 : FICHIERS DE CONFIGURATION DU SERVEUR SMTP RELAIS ANNEXE 3 : FICHIERS DE CONFIGURATION DU SERVEUR SMTP INTERNE ANNEXE 4 : FICHIERS DE CONFIGURATION DE CYRUS IMAPD ANNEXE 5 : FICHIERS DE CONFIGURATION DE CLAMAV ANNEXE 6 : FICHIERS DE CONFIGURATION POUR SPAMASSASSIN ANNEXE 7 : FICHIERS DE CONFIGURATION POUR AMAVISD-NEW RÉFÉRENCES

4 Préface Ce document a été rédigé afin de servir de guide à l'installation d'une infrastructure de courriel basée sur des composantes de logiciel libre. Il vise à aider dans l'établissement d'une infrastructure typique et sécuritaire, mais qui devrait être adaptée aux besoins de votre établissement. Comme les ressources disponibles, les environnements de travail, les systèmes d'authentification, les architectures réseau et autres facteurs peuvent varier énormément d'un établissement à l'autre, il est impossible de rédiger une référence absolue pouvant ou devant s'appliquer partout. Ce document est donc un aide à la mise en place et à la configuration d'une bonne infrastructure de courriel pouvant être déployée relativement facilement, et surtout à des coûts beaucoup plus modiques que des solutions offertes par les grands manufacturiers de logiciels. N'ayez cependant crainte, ce sont tous des logiciels sécuritaires et dont la stabilité a fait ses preuves dans de grands établissements depuis plusieurs années, particulièrement à l'intérieur des grandes universités. Une expérience de base d administration de Linux, avec RedHat ou autre distribution, est requise. Ce guide est basé sur une installation sur RedHat Enterprise 3 AS, ce pourquoi une expérience avec cette distribution est souhaitable. Cependant, tous les éléments peuvent très bien s adaptés aux autres distributions avec de légers changements, principalement au niveau de l installation des logiciels ainsi que de l emplacement des fichiers de configuration. Une connaissance de base des protocoles et applications des services DNS et SMTP est également requise à la mise en place de cette solution. Si vous ne possédez pas cette expérience, il est tout de même possible de mettre en place cette solution suite à la lecture de certains ouvrages, tels des livres sur l administration de systèmes Linux suggérés dans les ouvrages de référence à la fin de ce document. 4

5 Mise en situation Le schéma ci-dessous illustre la situation représentée dans ce document. Tous les serveurs ayant des accès publics sont dans la zone démilitarizée afin d accentuer le niveau de sécurité. Ceci est un exemple d une situation sécuritaire, mais peut être adaptée à votre environnement. Internet Coupe-Feu Zone Démilitarizée Zone Interne Serveur SMTP Relais - Relais SMTP pour le serveur SMTP principal - Filtrage de courriels entrant de l Internet - Dois avoir accès au serveur LDAP - Services: Postfix, Amavisdnew, Clamav, Cyrus SASL, SpamAssassin, client LDAP Serveur SMTP Principal - Serveur SMTP principal utilisé par les applications et les utilisateurs internes. Transmet les courriels pour les domaines hébergés aux serveur IMAP - Filtrage de courriels entrant des services et usagers internes - Dois avoir accès au serveurs LDAP et IMAP - Services: Postfix, Amavisd-new, Clamav, Cyrus SASL, SpamAssassin, client LDAP Serveur Web - Serveur Web public pour l accès IMAP via le Web - Dois avoir accès au serveur IMAP Interne - Services: Apache Serveur IMAP - Reçoit les courriels du serveur SMTP principal - Héberge les boîtes de courriels - Doit communiquer avec le serveur LDAP, le serveur SMTP principal ainsi que le serveur Web - Services: Cyrus IMAP, Cyrus SASL - Serveur principal contenant l arbre LDAP - Services: OpenLDAP Serveur LDAP Primaire Serveur LDAP Secondaire - Réplicat du serveur principal contenant l arbre LDAP - Services: OpenLDAP 5

6 Logiciels utilisés Comme la majorité de ces logiciels sont disponibles à même la majorité des distributions de Linux, nous vous conseillons de les installer via les méthodes propres à votre distribution. Ceci permet une gestion des serveurs plus efficace que de tout maintenir sois-même avec les sources de chacun des logiciels. Les tests ont été effectuer sur des systèmes installés avec RedHat Enterprise 3.0 AS, mais les guides de configuration peuvent s'appliquer à toutes les distributions. Il est évident qu'il pourrait toutefois y avoir certains changements applicables, surtout au niveau des chemins d'accès. Dans ces cas, référez-vous à la documentation de votre distribution pour y appliquer les changements nécessaires. Voici donc la liste des logiciels clés utilisés à l'intérieur de ce guide : OpenSSL Fonction : Libraries et utilitaires d'encryption Site Web : Version testée : 0.9.7a Berkeley DB Fonction : Serveur de base de données Site Web : Version testée : Prérequis : OpenSSL OpenLDAP Fonction : Procurer des outils et librairies d'authentification pour Postfix et Cyrus-IMAPd Site Web : Version testée : Prérequis : OpenSSL, Berkeley DB Apache Fonction : Serveur Web Site Web : Version testée : Prérequis : OpenSSL PHP Fonction : Language interprété Site Web : Version testée : Perl Fonction : Language interprété Site Web : Version testée : PostgreSQL Fonction : Serveur de base de données Site Web : Version testée : nss_ldap Fonction : Modules pour intégrer LDAP comme module de résolution de noms Site Web : Version testée : pam_ldap (parfois inclus dans nss_ldap) Fonction : Modules PAM pour authentification via LDAP Site Web : 6

7 Cyrus SASL Fonction : Procurer des outils et librairies d'authentification pour Postfix et Cyrus-IMAPD Site Web : Version testée : Prérequis : nss_ldap, pam_ldap Cyrus IMAPD server Fonction : Serveur IMAP/POP Site Web : Version testée : Prérequis : OpenSSL, Cyrus-SASL Postfix Fonction : Serveur SMTP Site Web : Version testée : Prérequis : OpenLDAP, OpenSSL, Cyrus-SASL ClamAV Fonction : Antivirus en logiciel libre Site Web : Version testée : 0.80 SpamAssassin Fonction : Filtre de pourriels Site Web : Version testée : 2.55 Prérequis : Perl amavisd-new Fonction : Engin de gestion de filtres de courriels Site Web : Version testée : Pré-Requis: Perl et les modules suivant: IO::Wrap, IO::Stringy, Unix::Syslog, Mail::Field, Mail::Address, Mail::Header, Mail::Internet, MIME::Words, MIME::Head, MIME::Body, MIME::Entity, MIME::Parser, Net::Server, Net::Server::PreForkSimple, MIME::Decoder::Base64, MIME::Decoder::Binary, MIME::Decoder::Gzip64, MIME::Decoder::NBit, MIME::Decoder::QuotedPrint, MIME::Decoder::UU, BerkeleyDB, Convert::TNEF, Convert::UUlib, Archive::Zip SquirrelMail Fonction : Client Web pour IMAP Site Web : Version testée : 1.4.3a Prérequis : Apache, PHP 7

8 Authentification OpenLDAP Afin de permettre une authentification centralisée, nous avons choisi de baser l authentification sur les services d annuaires LDAP, reposant sur le serveur OpenLDAP. Afin d utiliser tous les services sur RedHat, il vous faut les progiciels suivants : - openldap - openldap-servers - openldap-clients - openldap-devel - nss_ldap Puisque l administration du serveur OpenLDAP peut être une tâche assez complète lorsque vous n en êtes pas familier, je conseille fortement de consulter le livre de Gérald Carter, LDAP System Administration, publié par O Reilly. Configuration du serveur OpenLDAP Le démon qui fait office de serveur LDAP dans OpenLDAP est slapd et sa configuration s effectue dans le fichier slapd.conf, qui se trouve dans le répertoire /etc/openldap. Inclusion de schémas LDAP Le premier élément à configurer est la liste de schémas à inclure dans le serveur. Les schémas sont les listes de définitions d attributs que l on peut définir à chacun des objets de l annuaire. Pour pouvoir utiliser les schémas, il faut cependant les inclure dans la configuration de slapd. Il faut donc définir l inclusion des schémas désirés dans la configuration de slapd : include include include include include /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /etc/openldap/schema/misc.schema Définition l arbre de l annuaire Par la suite, il faut définir l arbre de notre annuaire LDAP. Ceci inclut le type de base de données utilisée (database), la définition de la racine de l arbre de notre annuaire (suffix), l utilisateur maître de l arbre (rootdn) ainsi que le répertoire où seront conservées les données (directory). Voici donc les entrées à définir dans la configuration de slapd pour cela : database suffix rootdn rootpw directory bdb "dc=example,dc=com" "cn=manager,dc=example,dc=com" {MD5}CY9rzUYh03PK3k6DJie09g== /var/lib/ldap Remplacez le suffix par vos propres informations de domaines. Cette configuration serait valide pour le domaine example.com. Le rootdn est l équivalent de l utilisateur root au niveau de la base LDAP. Le nom de Manager a été utilisé, mais il est possible de définir n importe quel nom à cet administrateur, mais il est important de ne l utiliser que pour la gestion de l annuaire, puisqu il y a tous les droits. 8

9 Le rootpw est le mot de passe de l utilisateur administrateur, défini dans rootdn. Bien que le mot de passe pourrait être noté en texte clair, il est très fortement recommandé qu il soit conservé de manière encryptée. Afin de générer un mot de passe encrypté, vous pouvez utiliser l utilitaire slappasswd(8), qui peut chiffrer les mots de passe à l aide des algorithmes CRYPT, MD5, SMD5, SSHA et SSHA. L algorithme par défaut est SSHA. # slappasswd h {MD5} New password: Re-enter new password: Pour ce qui est du répertoire contenant la base de données, le répertoire par défaut de RedHat, /var/lib/ldap, a été utilisé. Création des index Afin d accélérer les recherches dans l annuaire, il est fortement recommandé de créer des index sur les éléments les plus recherchés. Vous pouvez toujours ajuster les index selon vos critères, mais voici les index suggérés pour cet exemple : index objectclass index ou,mail,maillocaladdress eq,pres eq,pres,sub Si jamais vous décidez de modifier les index après la configuration initiale, il est important de recréer les index. Pour ce faire, utiliser la commande slapindex. Pour plus d informations, consultez sa page de manuel, slapindex(8c). Création de Liste d accès Afin de limiter l accès aux informations de l annuaire, vous pouvez utiliser des listes d accès dans la configuration du démon slapd. Les listes d accès fonctionnent sous un ordre de «première règle effective», ce qui veut dire que la première règle de la liste qui s applique une situation donnée sera celle qui sera effective. Il est donc important de bien bâtir vos règles en conséquence de cela. access to * by self write by anonymous auth by dn.base="uid=mail,dc=example,dc=com" write by * none Encore une fois, il est important de modifier vos règles selon votre schéma. Sécurisation des transactions via SSL Afin d éviter que les informations importantes circulent en texte clair sur le réseau, il est également recommandé d effectuer des connexions sécurisées via SSL sur le serveur LDAP. Pour cela, il faut permettre les connexions encryptées dans la configuration de slapd. Avant de pouvoir configurer les fonctions SSL dans slapd, il faut tout d abord créer les certificats SSL nécessaires en format PEM. Pour cela, la première étape est de créer des certificats SSL en format PEM. Si vous avez déjà des certificats SSL signés par des autorités de certification (CA) tels que VeriSign ou Thawte, vous pouvez les utiliser sans avoir à en générer de nouveaux. Bien entendu, les certificats existants doivent être reliés au nom de domaine sous lequel votre serveur LDAP va fonctionner. Si vous désirez créer des certificats qui seront signés par des autorités de certification, il faudra suivre les étapes suivantes : 1- Créer une clé privée qui sera utilisée pour la création de certificats. mkdir /etc/postfix/ssl chmod 700 /etc/openldap/ssl chown root:root /etc/openldap/ssl openssl genrsa out /etc/openldap/ssl/privkey.pem

10 chmod 700 /etc/openldap/ssl/privkey.pem 2- Créer une demande de signature de certificat (CSR). Ce fichier sera envoyé à une authorité de certification afin de recevoir un certificat signé. openssl req -new -key /etc/openldap/ssl/privkey.pem \ -out /etc/openldap/ssl/mailreq.csr 3- Une fois que vous aurez reçu votre certificat de l autorité de certification, vous pouvez le placer dans un répertoire sécurisé, tel /etc/postfix/ssl/ Si vous ne désirez pas utiliser un certificat signé par une autorité de certification, il est possible de créer ses propres certificats SSL, en suivant les étapes suivantes : 1- Créer une clé privée qui sera utilisée pour la création de certificats. mkdir /etc/openldap/ssl chmod 700 /etc/openldap/ssl chown root:root /etc/openldap/ssl openssl genrsa out /etc/openldap/ssl/privkey.pem 2048 chmod 600 /etc/openldap/ssl/privkey.pem 2- Créer un certificat de format PEM, à l aide de la clé privée : openssl req -new -x509 -key /etc/openldap/ssl/privkey.pem \ -out /etc/openldap/ssl/cacert.pem -days 1095 Une fois les certificats créés, vous pouvez les ajouter à la configuration de slapd à l aide des paramètres suivants: TLSCACertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateKeyFile /etc/openldap/ssl/privkey.pem Configuration du client OpenLDAP Deux fichiers doivent être configurés pour que les applications utilisant OpenLDAP puissent communiquer avec le serveur OpenLDAP, soit /etc/ldap.conf et /etc/openldap/ldap.conf. Le premier, /etc/ldap.conf est utilisé par pam_ldap et nss_ldap. C est donc à l intérieur de celui-ci qu il faut inclure tous les éléments relatifs à la configuration de ces modules. Un utilisateur «mail», qui a des droits de lectures sur l annuaire, afin de ne pas permettre de requêtes anonymes, a également été créé. Voici donc les paramètres relatifs à la connexion au serveur LDAP : # Definition des requêtes de schéma host ldap.example.com base dc=example,dc=com ssl yes ldap_version 3 # Utilisateur pour la connexion au serveur LDAP binddn uid=mail,dc=testzone,dc=com bindpw query scope sub # Utilisateur pour les commandes effectuées par l'utilisateur root rootbinddn cn=manager,dc=testzone,dc=com Afin d augmenter le niveau de sécurité en limitant le nombre de compte d usagers sur nos serveurs, nous désirons utiliser des utilisateurs virtuels. Ceci facilite également l hébergement de plusieurs domaines sur le même systeme. 10

11 Cependant, pour se faire, les filtres de PAM de ces systèmes doivent être modifiés. La configuration par défaut effectue l authentification uniquement au niveau du nom de l utilisateur, alors que l utilisation d utilisateur virtuels est normalement effectuée sur l adresse de courriel complète afin de permettre d avoir des utilisateurs identiques sur des domaines différents. Par exemple : les noms d utilisateurs test@exemple.com et test@exemple2.com au lieu d avoir simplement le nom d utilisateur test. Voici donc les modifications à faire sur les filtres de PAM : # Définition des paramètres de PAM # Attribut contenant le nom de l utilisateur pam_login_attribute maillocaladdress # Attribut contenant le filtre de recherche supplémentaire pam_filter objectclass=inetorgperson # Définition du type d encryption des mots de passe pam_password md5 Il faut par la suite créer le fichier de configuration utilisé par les utilitaires d OpenLDAP, soit /etc/openldap/ldap.conf. Ce fichier doit simplement contenir les paramètres à la connection au serveur LDAP désiré : # Definition des requêtes de schéma URI ldaps://ldap.example.com BASE dc=example,dc=com # Configuration des certificats SSL TLS_CACERT /etc/openldap/ssl/cacert.pem TLS_CERT /etc/openldap/ssl/cacert.pem TLS_KEY /etc/openldap/ssl/privkey.pem Population de l annuaire OpenLDAP Afin de faire les modifications initiales à la base de données LDAP, nous pouvons utiliser l utilitaire slapadd, qui permet de faire l ajout d entrées LDAP à l aide de fichiers LDIF. Les fichiers LDIF sont simplement des fichiers textes contenant toutes les informations nécessaires à l entrée de données LDAP. Avant de commencer à entrer des ressources à l intérieur de l annuaire, il faut tout d abord créer son arborescence. Pour les besoins de l exemple, l arborescence sera très simpliste, mais évidemment, il est fortement recommandé de l organiser selon vos besoins. L arborescence utilisée sera pour le domaine example.com, et tous les utilisateurs seront créés dans l unité organisationnelle people. dc=example,dc=com ou=people Pour créer cette entrée, il est possible d utiliser le fichier basearbre.ldif suivant : # Creer la racine de l'arbre dn: dc=example,dc=com dc: example objectclass: dcobject objectclass: organizationalunit ou: Example # Creer le ou "People" dn: ou=people,dc=example,dc=com ou: people objectclass: organizationalunit 11

12 Il est ensuite possible de l ajouter à la base LDAP avec la commande suivante : slapadd -l basearbre.ldif Par la suite, il faudra ajouter les utilisateurs à l intérieur de la structure LDAP. Voici donc un exemple qui ajoute un utilisateur test, avec une adresse de courriel test@example.com, ainsi qu un alias, qui envoie les courriels de testalias@example.com à test@example.com : # Entree pour l'utilisateur test dn: uid=test,ou=people,dc=example,dc=com uid: test cn: Utilisateur Test objectclass: account objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: top userpassword: {MD5}CY9rzUYh03PK3k6DJie09g== sn: Account mail: test@example.com maillocaladdress: test@example.com # Entree pour alias de courriel testalias vers test dn: uid=testalias,ou=people,dc=example,dc=com uid: testalias cn: Utilisateur Test objectclass: inetorgperson objectclass: inetlocalmailrecipient sn: Account mail: testalias@example.com maillocaladdress: test@example.com À regarder ce fichier, vous vous demandez probablement pourquoi l adresse de courriel est nécessaire à deux endroits dans le cas des usagers. Comme tous nos utilisateurs sont considérés comme des utilisateurs virtuels, toutes les adresses de réception seront évaluées par Postfix comme si elles étaient des alias. L attribut mail est donc l adresse pour laquelle le serveur Postfix reçoit un courriel, et maillocaladdress est l adresse à laquelle Postfix enverra le courriel au serveur IMAP. Donc, si l adresse de réception est la même que celle d envoi, simplement inscrire la même adresse pour les deux attributs. Pour les alias, simplement indiquer les bonnes adresses de source et de destination. De plus, comme les alias ne sont pas des vrais utilisateurs, il n est pas nécessaire de leur inclure les attributs relatifs à l authentification, comme userpassword. Il est donc possible d ajouter ces entrées à l aide de la commande suivante : slapadd -l test.ldif Par la suite, vous pourrez ajouter tous vos utilisateurs à l intérieur d un ou plusieurs fichiers ldif de cette manière. Cependant, si votre serveur LDAP est opérationnel, il faut ajouter vos utilisateurs à l aide de la commande ldapadd ou ldapmodify au lieu de la commande slapadd, puisque celle-ci est réservée pour les opérations où l annuaire LDAP n est pas ouvert. Création des comptes administratifs dans l annuaire Un minimum de deux comptes administratifs seront nécessaire dans l annuaire. Le premier compte est celui pour l utilisateur mail, qui fera les requêtes dans la base de données. Il peut être créé à partir du fichier ldif suivant : # Entree pour l'utilisateur administratif mail dn: uid=mail,ou=people,dc=example,dc=com uid: test cn: Utilisateur mail objectclass: account objectclass: inetorgperson objectclass: top userpassword: {MD5}CY9rzUYh03PK3k6DJie09g== 12

13 sn: Account Vous aurez également besoin d un utilisateur qui sera administrateur des boîtes de courriels à l intérieur de cyrus, et ce, pour chacun des domaines que vous désirez héberger. Chaque utilisateur Cyrus ayant un nom d utilisateur associé à un domaine (cyrus@domaine) ne peut être administrateur que de son propre domaine, ce pour quoi il est nécessaire d en avoir un par domaine hébergé. Voici donc l entrée ldif pour l utilisateur Cyrus du domaine example.com : # Entree pour l'utilisateur test dn: uid=test,ou=people,dc=example,dc=com uid: test cn: Utilisateur Test objectclass: account objectclass: inetorgperson objectclass: top userpassword: {MD5}CY9rzUYh03PK3k6DJie09g== sn: Account mail: test@example.com Comme il est important que l utilisateur administratif des boîtes de courriel ne reçoive pas de courriels afin d éviter les failles possibles de sécurité résultant de l utilisation d un utilisateur actif en tant qu administrateur, nous n allons pas lui spécifier de classe d objets inetlocalmailrecipient ni d attributs maillocaladdress. L attribut mail est cependant nécessaire, puisque ce sera son nom d authentification. PAM L'élément clé au niveau de l'authentification via les serveurs LDAP se situe au niveau de PAM, plus précisément à l'aide du module pam_ldap. Avec RedHat, pam_ldap fait partie du progiciel nss_ldap, donc vous devez être certain qu'il est installé. Pour les autres distributions, vérifiez la documentation de celle-ci. Une fois que les fichiers clients d OpenLDAP, soit /etc/ldap.conf et /etc/openldap/ldap.conf, sont bien configuré (voir section précédente pour plus d'informations), la partie la plus complexe de la configuration est déjà complétée. Il vous reste simplement à modifier la configuration des fichiers d'authentifications de PAM pour qu'ils quérissent les serveurs LDAP, et ce, pour chacun des services que vous désirez utiliser pam_ldap. Dans le cas des serveurs de courriels, les seuls services requis sont SMTP, IMAP et si désiré, POP3. Si vos services sont isolés sur différents serveurs, changez seulement la configuration pour les services actifs sur chaque système. Les fichiers de configurations se trouvent dans le répertoire /etc/pam.d/ et les fichiers à modifier sont smtp, imap et pop3. Vous devez donc modifier chacun des fichiers pour qu'ils contiennent les lignes suivantes: auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_ldap.so auth required /lib/secudity/pam_unix.so shado nullok use_first_pass account sufficient account required /lib/security/pam_ldap.so /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so nullok use_authok shadow session required session optional /lib/security/pam_unix.so /lib/security/pam_console.so Ces changements vont s'assurer que PAM va authentifier uniquement au niveau du serveur LDAP. Si vous avez besoin d'utiliser des mécanismes d'authentification additionnels, vous n'avez qu'à ajouter les bonnes options de configuration à l'intérieur de ces fichiers. Puisque les services utilisés ne s'authentifient pas directement à travers PAM, mais plutôt à l'aide de SASLAUTHD, il faut donc configurer ce dernier avant de pouvoir tester l'authentification. 13

14 SASLAUTHD SASLAUTHD est un démon qui utilise les diverses librairies d'authentification de SASL. Il est notamment utilisé pour l'authentification sous Postfix et Cyrus-IMAPd. Il peut s'interfacer avec beaucoup de différents mécanismes, mais dans notre cas, nous voulons qu'il se rabatte sur PAM, qui s'occupera des vérifications auprès du serveur LDAP. Pour se faire, il faut donc légèrement modifier la configuration du démon SASLAUTHD, en lui passant certains paramètres au démarrage. Le premier élément est de lui spécifier que l'on veut une authentification via PAM, ce qui se fait à l'aide du paramètre -a pam. Ensuite, puisque nous voulons faire opérer le démon de Postfix sous un chroot, nous devons lui dire que son socket doit se retrouver à l'intérieur du chroot de Postfix. Ceci ce fait avec l'option -m /chemin/du/socket. Pour configurer ces options avec RedHat Enterprise, simplement qu'à modifier un seul fichier, soit /etc/sysconfig/saslauthd, et d'y ajouter les options suivantes: # # Changer l'authentification de saslauthd a PAM # MECH=PAM # # Changer le répertoire du socket pour l'inclure dans le chroot de postfix # SOCKETDIR=/var/spool/postfix/var/run/saslauthd Le script d'initialisation de SASLAUTHD, /etc/init.d/saslauthd va automatiquement aller lire le fichier /etc/sysconfig/saslauthd et remplacer les variables par les bonnes options. Pour les autres distributions, vérifier la documentation pour y appliquer ces changements. Une fois ces modifications terminées, vous pouvez démarrer le service saslauthd, à l'aide de la commande suivante: /etc/init.d/saslauthd start Vous pouvez vérifier qu'il est démarré avec les bonnes options à l'aide de la commande suivante: ps x grep saslauthd Vous devriez voir un résultat similaire à celui-ci: 14185? S 0:00 /usr/sbin/saslauthd -m /var/spool/postfix/var/run/saslauthd -a pam 14186? S 0:00 /usr/sbin/saslauthd -m /var/spool/postfix/var/run/saslauthd -a pam 14187? S 0:00 /usr/sbin/saslauthd -m /var/spool/postfix/var/run/saslauthd -a pam 14188? S 0:00 /usr/sbin/saslauthd -m /var/spool/postfix/var/run/saslauthd -a pam 14189? S 0:00 /usr/sbin/saslauthd -m /var/spool/postfix/var/run/saslauthd -a pam pts/1 S 0:00 grep saslauthd Vous êtes maintenant prêts à tester l'authentification via SASL, LDAP et PAM. SASL offre un utilitaire qui permet de tester l'authentification pour chacun des services, testsaslauthd, qui s'utilise de la façon suivante: testsaslauthd -s [service name] -u [username] -p [password] Par exemple, pour tester l'authentification SASL de l'usager test sur le service smtp, il faudrait utiliser cette commande: testsaslauthd -s smtp -u test -p testpassword # testsaslauthd -s smtp -u test -p testpassword 0: OK "Success." Cet outil est essentiel afin de vérifier la fonctionnalité de l'authentification au niveau de SASL. Il pourra arriver à plusieurs reprises lors de l'implémentation que vous devrez déboguer le processus d'authentification. À l'aide de cette commande, vous pourrez facilement déterminer si le problème se situe au niveau de PAM/SASL/LDAP ou encore si c'est un problème relié à l'interaction entre les démons SMTP et IMAP avec SASLAUTHD. Si les tests avec testsaslauthd échouent, il est inutile de vérifier par exemple la configuration de Postfix, tant et aussi longtemps que les résultats ne seront pas positifs. Quelques notes sur les messages d'erreur possibles: 14

15 connect() : No such file or directory Assurez-vous que le service SASLAUTHD est opérationnel. S'il est démarré, il est peut-être dans un état non fonctionnel. Essayez de le redémarrer. Une autre cause possible serait qu'il n'arrive pas à contacter le socket, donc vérifiez les chemins d'accès. Vous pouvez toujours forcer le bon chemin d'accès à l'aide de l'option -f /chemin/du/répertoire/du/mutex, ce qui, dans notre cas, serait -f /var/spool/postfix/var/run/saslauthd. 0: NO "authentication failed" Vérifiez les journaux relatifs à saslauthd. Il se pourrait que la configuration des fichiers clients LDAP soient incorrecte, que le service slapd ne soit pas fonctionnel ou encore que les fichiers de PAM modifiés précédemment soient incorrects. 15

16 Serveur de relais SMTP Postfix Création du RPM L'installation de Postfix a été faite à l'aide du SRPM de Simon J. Mudd ( Ceci est un progiciel spécial qui contient les sources du logiciel et les outils permettant d en faire un progiciel en format binaire une fois compilé. La première étape à la création du progiciel final consiste en installer le SRPM, ce qui se fait à l aide de la commande suivante : rpm -ivh postfix src.rpm Tous les fichiers sources se trouveront alors sous l arborescence de /usr/src/redhat. Cependant, pour que le RPM final de Postfix puisse avoir les options désirées, il faut modifier le fichier SPEC du SRPM pour le compiler avec les bonnes options. Le fichier à modifier est /usr/src/redhat/specs/postfix.spec et les options à modifier sont les suivantes : %define with_cdb 0 %define with_ipv6 0 %define with_ldap 1 %define with_mysql 0 %define with_mysql_redhat 0 %define with_pcre 1 %define with_pgsql 0 %define with_sasl 2 %define with_spf 0 %define with_tls 1 %define with_tlsfix 2 %define with_vda 0 Après cela il sera possible de compiler le RPM avec toutes les options nécessaires à l aide de la commande suivante : rpmbuild -bb postfix.spec Par la suite, simplement à installer le RPM à l aide de la commande suivante : rpm ivh /usr/src/redhat/rpms/i386épostfix rhel3.i386.rpm Configuration La majeure partie de la configuration de Postfix s'effectue dans le répertoire /etc/postfix. Dans ce répertoire, vous y trouverez tous les fichiers de configuration, y compris les deux principaux, soit master.cf et main.cf. Contrôle des démons et services: master.cf Barrer Postfix dans un chroot Le fichier master.cf est celui qui contrôle les différents démons et services de Postfix. Les lignes principales auxquelles il faut s'attarder sont les suivantes: # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd Afin de sécuriser Postfix encore plus, il y a un changement qu'il faut appliquer à cette ligne, afin de barrer le service smtpd dans un chroot. Un chroot est une sorte de prison pour un utilisateur, qui nous bloque à une source précise 16

17 dans le système de fichiers du système. Par exemple, barrer postfix dans un chroot /var/spool/postfix fait en sorte que sa racine («/») devient /var/spool/postfix et il n aura pas accès à aucun fichier qui ne se trouve pas en dessous de cette arborescence. Ceci limite donc énormément les risques de sécurité advenant une brèche du service. Comme vous pouvez le voir dans l'extrait ci-haut, il faut modifier la cinquième colonne pour cela, en changeant le n pour un -, puisque comme les commentaires l'indiquent, par défaut, Postfix est configuré pour rouler en chroot. Toutefois, c'est une propriété que RedHat a décidé de changer, probablement aux fins de simplicité. Il faut donc la modifier comme suit pour récupérer cette addition de sécurité. # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n smtpd Pour que Postfix puisse opérer dans le chroot, il faut cependant copier plusieurs fichiers dans son chroot, puisqu'il ne pourrait y accéder autrement. Il faut donc créer l'arborescence suivante, qu'il est possible de faire aisément à l'aide du script de création de chroot qui vient avec le RPM de Postfix de Simon J. Mudd ( # setup chroot directory structure /var/spool/postfix/etc /var/spool/postfix/lib /var/spool/postfix/usr/lib/zoneinfo /var/spool/postfix/usr/share/zoneinfo /var/spool/postfix/usr/lib/sasl2 copy system files into chroot /etc/localtime -> /var/spool/postfix/etc /etc/host.conf -> /var/spool/postfix/etc /etc/resolv.conf -> /var/spool/postfix/etc /etc/nsswitch.conf -> /var/spool/postfix/etc /etc/hosts -> /var/spool/postfix/etc /etc/services -> /var/spool/postfix/etc copy (cleaned) /etc/passwd into chroot copy LDAP libraries into chroot /usr/lib/libldap.so -> /var/spool/postfix/usr/lib/ /usr/lib/libldap.so.2 -> /var/spool/postfix/usr/lib/ /usr/lib/libldap.so > /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so -> /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so.2 -> /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so > /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so -> /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so.2 -> /var/spool/postfix/usr/lib/ /usr/lib/libldap_r.so > /var/spool/postfix/usr/lib/ /usr/lib/liblber.so -> /var/spool/postfix/usr/lib/ /usr/lib/liblber.so.2 -> /var/spool/postfix/usr/lib/ /usr/lib/liblber.so > /var/spool/postfix/usr/lib/ copy SASL libraries and files into chroot /usr/lib/sasl2/smtpd.conf -> /var/spool/postfix/usr/lib/sasl2/ /usr/lib/sasl2/libplain.* -> /var/spool/postfix/usr/lib/sasl2/ /usr/lib/sasl2/liblogin.* -> /var/spool/postfix/usr/lib/sasl2/ copy db library (libdb-4.1.so) into chroot /lib/libdb-4.1.so -> /var/spool/postfix/lib/ copy system files into chroot /lib/libnss_compat so -> /var/spool/postfix/lib/ /lib/libnss_compat.so.2 -> /var/spool/postfix/lib/ /lib/libnss_dns so -> /var/spool/postfix/lib/ /lib/libnss_dns.so.2 -> /var/spool/postfix/lib/ /lib/libnss_files so -> /var/spool/postfix/lib/ /lib/libnss_files.so.2 -> /var/spool/postfix/lib/ /lib/libnss_ldap so -> /var/spool/postfix/lib/ /lib/libnss_ldap.so.2 -> /var/spool/postfix/lib/ /lib/libnss_nis so -> /var/spool/postfix/lib/ /lib/libnss_nis.so.2 -> /var/spool/postfix/lib/ /lib/libnss_nisplus so -> /var/spool/postfix/lib/ /lib/libnss_nisplus.so.2 -> /var/spool/postfix/lib/ /lib/libnss_winbind.so -> /var/spool/postfix/lib/ /lib/libnss_winbind.so.2 -> /var/spool/postfix/lib/ 17

18 /lib/libnss_wins.so -> /var/spool/postfix/lib/ /lib/libnss_wins.so.2 -> /var/spool/postfix/lib/ /lib/libresolv so -> /var/spool/postfix/lib/ backing up /etc/postfix/master.cf to /etc/postfix/master.cf-old.9750 Journalisation accrue pour déboggage La ligne du service smtp est également spécialement utile pour fin de débogages, puisqu'en ajoutant -v à la fin, il est possible d'avoir des journaux beaucoup plus verbaux, ce qui rend la résolution de problèmes beaucoup plus efficace. smtp inet n smtpd -v Configuration du service: main.cf Une fois que les divers démons de Postfix sont bien configurés, toute la configuration du fonctionnement des services se fait via le fichier main.cf. Certaine parties de configurations sont dans d autres fichiers, mais ils sont tous référencés par main.cf. Identification du système La première étape à la configuration de Postfix est de bien configurer l identité des services smtp et smtpd. Ceci ce fait à l aide des options suivantes : myhostname : Le nom de domaine respecter certains éléments : complet du système, ex : mail.example.com. Le nom spécifié ici doit s assurer de Son nom de domaine doit avoir un entrée DNS publique de type A pour le domaine spécifié Son adresse IP doit être reliée au nom de domaine à l aide d une entrée DNS publique de type PTR zone de reverse lookup Le nom de domaine doit être spécifié comme record MX pour chacun des domaines qu il dessert Ces éléments sont essentiels afin de respecter les standards établis pour le protocole SMTP. Même s il serait possible faire fonctionner votre serveur de courriels sans que ces conditions soient remplies, il se pourrait que beaucoup de courriels que vous enverriez seraient bloqués par d autres serveurs de courriels qui font des vérifications très strictes sur les courriels entrant. dans la Pourquoi faire des vérifications aussi strictes? À cause de l émergence grandissante de courriels indésirables, les pourriels. Puisque la grande majorité des serveurs qui envoient des pourriels ne respectent pas ces standards, il est donc possible d en bloquer une très grande partie en faisant ces vérifications plus accrues sur les configurations DNS des serveurs nous envoyant des courriels. Dans certains cas, il est même possible de bloquer jusqu à 90% des pourriels simplement avec ces vérifications. mydomain : Le nom du domaine principal desservi par le serveur de courriel, ex : example.com. Si vous hébergez plusieurs domaines, la liste des autres domaines se trouvera dans relay_domains si vous utilisez un serveur de relais ou dans virtual_domain_maps si votre serveur de front est également votre serveur principal. mynetworks : La liste des réseaux pour lesquels le serveur pourra être utilisé comme relais. Il est important de mettre la liste de tous les réseaux d où les utilisateurs de ce serveur SMTP pourrait y accéder, sans nécessiter d authentification myorigin : L origine de tout courriel non complet passant par se serveur. Ex. un mail envoyé à l utilisateur jean devient jean@myorigin. mydestination : La liste des domaines pour lesquels se serveur est la destination finale smtpd_banner : La banière affichée par le serveur lors de l initiation d une connection SMTP. Il est obligatoire d y incrire le nom de domaine complet du système, tel $myhostname. Il est également recommandé de ne pas afficher la version du logiciel, pour rendre l exploitation de failles plus complexe. L ajout de NO UCE va permetre de bloquer certains systèmes de pourriels «gentils» qui vont s abstenir d envoyer des pourriels aux systèmes ayant cela dans la banière. Cependant, soyez avisés que ces systèmes sont très rares. 18

19 # Identification du système myhostname = mail.example.com mydomain = example.com mynetworks = /24, /8 myorigin = $mydomain mydestination = $myhostname, localhost.$mydomain, localhost smtpd_banner = $myhostname ESMTP NO UCE Relais de courriels Comme ce système de courriels est seulement utilisé aux fins de relais, il faut lui spécifier où envoyer les courriels pour les domaines desquels nous désirons recevoir du courriel. Ceci est établi à l aide des règles de transport de Postfix, qui est géré à l aide des paramètres suivants : relay_domains : Liste des domaines pour lesquels nous désirons relayer du courriel. Il est recommandé de le faire pointer à un fichier externe pour en simplifier l administration. relay_recipient_maps : Liste des personnes pouvant recevoir du courriel sur les domaines relayés. Ceci doit pointer sur la liste complète des usagers, puisque si le serveur ne reconnaît pas le destinataire du courriel entrant, il va le refuser. Comme la liste des usagers se trouve sur le serveur LDAP, il faut pointer cette requête à un des serveurs LDAP contenant cette information. transport_maps : Pointe à un fichier décrivant les directives d envois de courriels, par domaine. Lire la page de manuel transport(5) pour plus d informations. Voici un exemple de configuration de ces paramètres dans main.cf : # Options de relais de courriels relay_domains = hash:/etc/postfix/maps/relay_domains relay_recipient_maps = ldap:/etc/postfix/maps/relay_recipients transport_maps = hash:/etc/postfix/maps/transport Des exemples du format de ces fichiers sont disponibles dans les annexes. /etc/postfix/maps/relay_domains : Ce fichier fait simplement lister les différents domaines pour lesquels on veut relayer du courriel. Comme chaque fichier de type hash de postfix doit avoir 2 colonnes, simplement à mettre un commentaire dans la deuxième colonne pour son bon fonctionnement. Par exemple : example.com /etc/postfix/maps/relay_recipients : Ce fichier sert à configurer la requète LDAP pour la recherche d usagers et d alias. Soyez certain d ajuster ces paramètres en fonction des informations de votre annuaire LDAP. Consultez les annexes pour un exemple de configuration. /etc/postfix/maps/transport : Pour créer ce fichier, simplement à inscrire le domaine pour lequel vous désirez relayer les courriels, et le serveur de destination, précéder du mode de transport. Comme nous faisons du relais, le mode de transport est relais. Ex. : exemple.com #example.com relay:[mailint.example.com] Après avoir complété l édition des fichiers, il faut créer les tables fichiers de type hash. postmap /etc/postfix/maps/relay_domains postmap /etc/postfix/maps/transport de hash avec la fonction postmap pour chacun des 19

20 Filtrage de courriels ne respectant pas les normes Afin de limiter la quantité de pourriels, ainsi que d éviter la permission de courriels forgés, il est recommandé de bloquer les courriels ne respectant pas certains standards établis par le protocole SMTP. Pour cela, il est recommandé d utiliser les paramètres de configuration suivants dans Postfix : header_checks = regexp:/etc/postfix/header_checks mime_header_checks = regexp:/etc/postfix/mime_header_checks body_checks = regexp:/etc/postfix/body_checks strict_rfc821_envelopes = yes disable_vrfy_command = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_helo_access hash:/etc/postfix/maps/access_helo, reject_unknown_sender_domain, reject_unauth_pipelining, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_non_fqdn_hostname, check_relay_domains Puisque ce type de filtrage peut être encore plus strict afin de limiter davantage l entrée de pourriels, je recommande fortement de lire les informations relatives à ces paramètres dans la page de manuel postconf(5). De plus, pour un guide très bien détaillé sur le sujet, incluant d excellents exemples de configuration très stricte, incluant l utilisation de listes de trous noirs en temps réels (RBL), je suggère de lire l article de Jeffrey Posluns sur le filtrage de pourriels par l entremise de Postfix, disponible à l adresse suivante : Il faut cependant prendre note qu il est fort possible que certains courriels légitimes, provenant de serveurs ou de domaines mal configurés soient bloqués à l aide de ces règles, alors il sera a vous de juger quelles règles sont suffisantes selon vos politiques. La meilleure solution est de les implémenter graduellement et d en vérifier les effets. Utilisation de TLS pour authentification encryptée Afin de seulement permettre aux gens de s authentifier au serveur SMTP via une session encryptée à l aide de TLS, il faut configurer Postfix pour lui permettre de gérer les sessions TLS, qui sont des sessions encryptées à l aide de SSL. Pour cela, la première étape est de créer des certificats SSL en format PEM. Vérifier la section relative à la création de certificats SSL dans l installation d OpenLDAP afin de créer les certificats de Postfix. Les procédures sont les mêmes, excepté que vous devrez les mettre à l endroit suivant : /etc/postfix/ssl/. Une fois que les certificats sont installés, il ne reste qu à configurer Postfix pour qu il les utilise. Ceci se fait à l aide des options suivantes dans le main.cf : smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/postfix/ssl/privkey.pem smtpd_tls_cert_file = /etc/postfix/ssl/cacert.pem tls_random_source = dev:/dev/urandom Authentification SMTP via SASL Afin de permettre aux utilisateurs externes d utiliser votre serveur SMTP, il est possible d effectuer de l authentification SMTP via SASL. Ceci vous permet donc de limiter l utilisation externe de votre serveur aux personnes authentifiées et éviter de devenir un relais ouvert. Afin d éviter que les mots de passe des utilisateurs soient propagés sur Internet, nous désirons également permettre l authentification seulement si une connexion sécurisée via TLS est établie. De plus, l authenfication sera effectuée à l aide de SASLAUTHD pour permettre l authentification envers le serveur LDAP. 20