Différences

Ci-dessous, les différences entre deux révisions de la page.

--- mails:sasl:mta-serveur [2018/11/26 14:58] – [Les binds LDAP] cdrom1
+++ mails:sasl:mta-serveur [2018/12/17 09:55] (Version actuelle) – supprimée cdrom1
@@ Ligne 1: / Ligne 1: @@
-====== SASL pour l'accès au serveur MTA ======
-Le MTA est postfix, ce service est accessible via le protocole SMTP.
-Certaines de ses fonctions comme la transmission de mails de l'extérieur vers un destinataire@picasoft.net sont publiquement accessibles.
-Cependant, d'autres sont accessibles seulement après authentification. En effet, la politique [[txs:infra-a18-1:docu#spf|SPF]] donne seulement à nos serveurs le droit d'émettre des courriels dont l'expéditeur a une adresse du type expediteur@picasoft.net, et on ne veut pas que le monde entier puisse usurper l'identité des utilisateurs@picasoft.net. On autorise donc seulement des utilisateurs authentifiés à utiliser une telle fonctionnalité.
-Il faut remarquer que la couche de sécurité qu'on va décrire dans cette page ne fait qu'interdire aux utilisateurs non authentifiés d'utiliser des adresses en @picasoft.net. Mais une qu'on est authentifié, on peut a priori utiliser l'adresse de n'importe qui. Ce n'est pas un problème fondamental car:
-  * On peut mettre en place des logs permettant de voir qui a utilisé quelle adresse
-  * Picasoft est une petite association donc on peut se faire confiance.
-A titre indicatif, la même politique est en vigueur à l'UTC: une fois qu'on a utilisé son login pour se connecter au serveur SMTP, on peut demander à ce dernier d'envoyer un mail en [n'importe quoi]@utc.fr. Ce qui fait qu'on peut usurper l'identité de quelqu'un, mais ce sera tracé et on peut remonter la piste jusqu'au login de la personne qui a utilisé le serveur.
-Cette couche de sécurité sera appelée SASL serveur, puisqu'elle protège l'accès au serveur, mais une fois qu'on est dedans on peut tout faire indépendamment de son identité.
-Nous utilisons Postfix installé sous debian avec la bibliothèque saslauthd (Cyrus). A chaque fois qu'un démon postfix (smtp pour nous) a besoin de vérifier un couple (login;mot de passe), il utilise un socket pour les cpmmuniquer à un démon saslauthd. Ce démon effectue un certain nombre d'opérations puis répond à Postfix si l'authentification a réussi ou échoué.
-Dans notre cas, on a connecté saslauthd au serveur LDAP de Picasoft. A la place de saslauthd, on aurait pu utiliser ldapdb, mais cette bibliothèque garde un cache des hashs de mot de passe, ce qui est contraire à la politique de sécurité en vigueur. D'ailleurs, saslauthd est plus modulaire, il est également possible de le connecter à PAM (framework UNIX), un serveur IMAP, etc.
-Ils ont tous des avantages respectifs:
-  * Une auth PAM permet de contrôler localement des utilisateurs, embarqués dans la machine.
-  * Une auth IMAP permet de rendre l'accès au MTA dépendant de l'accès à une boîte mail, ce qui fait que un émetteur = un destinataire.
-  * Une auth LDAP permet de contrôler finement qui a accès à quoi, cependant l'exécution des règles de sécurité se fait côté client (le MTA est seul responsable de la sécurité, le LDAP n'est pour lui qu'un annuaire).
-Pour le moment, nous avons opté pour une auth LDAP, mais pour ne pas se fermer des portes ou faciliter le debug, nous avons également mis en place des auth PAM et IMAP qu'on peut tester avec sasl-test en spécifiant en argument le paramètre ldap, pam ou imap.
-===== Les fichiers de config de saslauthd =====
-Le remplissage des fichiers de config est automatisé avec les dockerfiles, mais il peut être intéressant de les inspecter à la main. On détaille ici les paramètres importants pour saslauthd.
-Sous debian, le fichier de config saslauthd pour postfix est dans <code>/etc/postfix/sasl/smtpd.conf</code>
-On indique dans le main de Postfix un lien vers ce fichier de config de Cyrus:
-<code>
-#/etc/postfix/main.cf:
-smtpd_sasl_path = smtpd
-</code>
-Il est important que smtpd porte le même nom que le fichier de config Cyrus (sans le .conf).
-===== Le démon saslauthd =====
-Ce démon crée un socket UNIX et attend qu'on lui demande de valider des authentifications. La config par défaut de saslauthd veut que ce démon soit dans :
-<code>/var/run/saslauthd</code>
-Cependant, Postfix est //chrooted// pour des raisons de sécurité (il n'a accès qu'à une partie de l'arborescence du système de fichiers). Par conséquent, il ne peut accéder à /var/run.
-Debian recommande de créer des processus saslauthd séparés et spécifiques (nous en créons donc un pour postfix). Pour plus de détails, [[https://wiki.debian.org/PostfixAndSASL|voir cette page du wiki Debian]]. Il y a certaines manips à réaliser pour que Postfix puisse accéder au socket de saslauthd, notamment mettre l'utilisateur //postfix// dans le groupe //sasl//.
-Le socket de saslauthd-post sera finalement dans <code>/var/spool/postfix/var/run/saslauthd</code>, à l'intérieur du répertoire de travail de Postfix.
-Pour donner à Postfix l'ordre de contacter saslauthd en tant que démon de vérification de mot de passe, on modifie smtpd.conf (sous debian, dans /etc/postfix/sasl/smtpd.conf, à créer sur une install fraîche):
-<code>
-pwcheck_method: saslauthd
-mech_list: PLAIN LOGIN
-</code>.
-On voit que le login est transmis en PLAIN, c'est dû au protocole SMTP. Il faut rajouter une couche de chiffrement pour que ce soit sécurisé. Sur une prod, il faut interdire l'auth PLAIN sur du SMTP non sécurisé. (En revanche, une connexion sans authentification peut se faire en SMTP non sécurisé (typiquement pour de la réception de mails du reste du monde)).
-==== Le processus saslauthd-postf ====
-On crée un processus saslauthd spécifique qui ne sera accessible qu'à Postfix.
-Pour cela, on copie le processus par défaut et on l'édite:
-<code>~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix</code>
-<code>START=yes
-DESC="SASL Auth. Daemon for Postfix"
-NAME="saslauthd-postf"      # max. 15 char.
-# Option -m sets working dir for saslauthd (contains socket)
-OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"        # postfix/smtp in chroot()</code>
-(repris du [[https://wiki.debian.org/PostfixAndSASL|Wiki debian]]).
-Il faut faire d'autres modifications en fonction de la source d'information qui permettra de valider les logins entrés. On va couvrir 3 cas: PAM (framework d'authentification sous UNIX), LDAP (service d'annuaire en TCP), IMAP (service de boîte mail en TCP).
-=== PAM ===
-Rien de plus simple, la config par défaut de saslauthd sous debian le fait. Il suffit d'un:
-<code>
-MECHANISMS="pam"
-</code>
-Éventuellement, on peut créer un fragment PAM, qui portera le nom de smtp. Ceci est hors sujet, voir la doc de PAM.
-=== LDAP ===
-<code>
-MECHANISMS="ldap"
-</code>
-Il faut également modifier /etc/saslauthd.conf (à créer sur une install fraîche):
-<code>
-ldap_servers: <ldap uri>
-ldap_search_base: <search base>
-ldap_filter: <filter>
-etc...
-</code>
-Pour la configuration du bind LDAP, voir plus bas.
-=== IMAP ===
-<code>
-MECHANISMS="rimap"
-MECH_OPTIONS="nom-hôte-serveur-imap/port"
-</code>
-Le nom d'hôte peut aussi être une adresse IPv4. Le /port peut être omis.
-saslauthd tentera de faire un AUTH IMAP standard, et dès qu'il a une réponse il se déconnecte.
-===== Les binds LDAP =====
-Si on choisit la solution LDAP, il faut configurer des binds au niveau du serveur. Ces binds sont préalables au challenge SASL: d'abord on vérifie si un utilisateur existe, ensuite on vérifie son mot de passe.
-Cette configuration se fait dans /etc/saslauthd.conf:
-<code>
-ldap_servers: ldap://ldap.test.picasoft.net:389
-ldap_bind_dn: cn=nss,dc=picasoft,dc=net
-ldap_bind_pw: rdonly
-ldap_search_base: dc=picasoft,dc=net
-ldap_filter: cn=%u
-</code>
-  * ldap_servers : On peut en mettre plusieurs, séparés par des virgules. Le SSL est supporté, il faut rajouter des paramètres pointant vers les certificats (voir la doc complète, la référence est ci-dessous).
-  * ldap_bind_dn et ldap_bind_pw: Configure les modalités de la connexion entre saslauthd et le serveur ldap. Ici, on ne peut faire que du readonly (voir la [[infrastructure:ldap|doc LDAP]] et demander à l'adminsys de picasoft pour plus de détails).
-  * ldap_search_base: permet de spécifier un étage de l'arborescence à partir duquel on va commencer à fouiller pour voir si l'utilisateur demandé existe et vérifie les critères demandés.
-  * ldap_filter: Permet de mettre certains critères, aussi bien sur l'utilisateur que sur les groupes auxquels il appartient.
-La doc de ce fichier de config se trouve dans /usr/share/doc/cyrus-sasl2-doc/LDAP_SASLAUTHD.gz (sous debian, installer le paquet cyrus-sasl2-doc).