Emile “iMil” Heitor ’s home

Sur mon serveur perso, par définition, y’a des trucs perso. De plus, à l’approche d’une société nouvelle, il n’est pas superflu de prendre quelques mesures afin de préserver un semblant d’intimité.
Pour cela, les bons génies de l’Internet on créé, il y a bien longtemps, SSL.
Mais voila, il y a d’autres trucs et bidules que je souhaite pouvoir exposer en place publique. J’entreprend donc de jouer avec les directives de lighttpd pour créer des exclusions et autres redirections.
Le lien qui eclaire tout, c’est celui là. En substance, nous allons rediriger tout ce qui matche mon.host.magique et faire passer ce traffic en SSL.
Voici la conf :

On déclare le serveur TLS :

$SERVER["socket"] == "mon.host.magique:443" {
  ssl.engine = "enable"
  ssl.pemfile = "/etc/ssl/certs/lighttpd.pem"
  server.document-root = "/vers/www/magique"
  server.name = "mon.host.magique"
  auth.backend.htpasswd.userfile = "/path/vers/lighttpd-htpasswd.user"
  auth.require = ( "/" =>
    (
       "method" => "basic",
       "realm" => "ce ne sont pas ces droïdes que vous recherchez.",
       "require" => "valid-user"
    )
  )
}

Puis la redirection, tout ce qui arrive sur le port 80 du host “mon.host.magique” sera redirigé vers son équivalent en HTTPS. On note les regexps compatibles Perl qui nous permettent de récupérer l’URL complète.

$SERVER["socket"] == "mon.host.magique:80" {
  $HTTP["host"] == "mon.host.magique" {
    url.redirect = ( "^/(.*)" => "https://mon.host.magique/$1" )
    server.name = "mon.host.magique"
  }
}

Et enfin les restrictions gentilles, on n’applique pas de restrictions à host1.host.magique, unautre.host.magique et blip.host.magique car ils ont leur propre déclaration dans le fichier lighttpd.conf. Pour le reste, seuls la racine, le repertoire public ainsi que les fichiers .php et .jpg sont autorisés.

$HTTP["host"] !~ "(host1|unautre|blip).host.magique" {
  server.document-root = "/var/ou/c/est/mignon"
  $HTTP["url"] !~ "(^/$|^/public|php$|jpg$)" { url.access-deny = ( "" ) }
}

C’est quand même un peu bien.

note: cette nouvelle est sujette à modifications en fonction de mon avancement dans la mise en place et la configuration de ma plateforme

Quelques liens glânés de-ci de-la pour monter une plate-forme mail couillue :

. SMTP Auth avec sendmail et FreeBSD
. SMTP Auth, la doc officielle de sendmail.org
. Un overview de l’integration SASL par l’ami asyd
. l’excellent projet MiniVisp de l’ami Hug
. FABULEUSE doc sur l’interfacage sendmail / LDAP
. Sendmail + Auth + TLS
. Utilisation de STARTTLS avec sendmail et l’accessdb
. la liste des parametres compris par confLDAP_DEFAULT_SPEC (binddn, password…)
. à la fin de ce tuto vous trouverez de bons exemples de virtuser LDAP
. FreeBSD fast and secure mail server using sendmail and imap-uw (eeeet si)
. Secure Email Using Cyrus IMAP, Sendmail, and SASLv2
. Le classique mais toujours efficace OpenLDAP QuickStart Guide
. Le NSS / PAM LDAP HOWTO pour FreeBSD 5.x
. saslauthd + LDAP
. Des astuces pour rendre sendmail plus agressif
. les migration tools de padl.com
. OpenLDAP TLS HOWTO
. Installer le milter DomainKey
. Encore une doc sur domainkey

Voici la partie relative de mon /etc/make.conf

SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 -DLDAPMAP -DSTARTTLS
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2 -lldap -llber

Et les parties reliées de mon sendmail.mc

define(`confLDAP_DEFAULT_SPEC', ` -h localhost -b dc=imil,dc=net')
FEATURE(ldap_routing)
LDAPROUTE_DOMAIN(`mail.imil.net')

[...]

TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 LOGIN')
define(`confDEF_AUTH_INFO', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 LOGIN')
dnl p: uniquement TLS pour l'authentification type Login
dnl A: Use the AUTH= parameter for the MAIL FROM command only when authentication succeeded.
define(`confAUTH_OPTIONS', `A p')

[...]

define(`confCACERT_PATH', `/etc/mail/ssl')dnl
define(`confCACERT', `/etc/mail/ssl/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/ssl/sendmail.pem')dnl
define(`confSERVER_KEY', `/etc/mail/ssl/sendmail.pem')dnl
define(`confCLIENT_CERT', `/etc/mail/ssl/sendmail.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/ssl/sendmail.pem')dnl


Quelques trucs :

Dans le saslauthd.conf, ne pas oublier :

ldap_search_base: dc=domaine,dc=com
ldap_filter: uid=%u
# pour activer TLS
ldap_start_tls: yes


Pour bénéficier de toutes les propriétés nécessaires, s’assurer d’avoir les includes suivants dans son slapd.conf :

include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/misc.schema


Le module ldap_routing de sendmail communique par defaut en LDAPv2, il faut ajouter l’option “-w 3″ à votre confLDAP_DEFAULT_SPEC pour le faire communiquer en LDAPv3.

Mon /etc/ldap.conf, linké à /usr/local/etc/ldap.conf et à /usr/local/etc/nss_ldap.conf

host 127.0.0.1
base dc=imil,dc=net
uri ldap://127.0.0.1/
ldap_version 3
binddn cn=user,dc=imil,dc=net
bindpw unpass
port 389
pam_password clear
# activer le TLS
ssl start_tls


J’utilise dovecot pour l’acces pop / imap, j’ai eu l’agréable surprise de voir qu’il créait seul les mailboxes des utilisateurs à leur premier login, de fait, en settant “/repertoire_en_777/utilisateur” comme homedir dans l’entrée LDAP de l’utilisateur, on se retrouve avec un systeme de provisionning automatique du meilleur gout.

Addon

Après avoir migré l’ensemble des services en TLS, j’ai constaté que dovecot ne permettait malheureusement pas de réaliser l’authentification LDAP sur TLS. Sur les conseils de mon ami Eric, j’ai pondu un rapide patch qui rend ce fonctionnement possible après avoir ajouté :

start_tls = 1

dans le dovecot-ldap.conf

Add-on

Au sujet de domainkey et DKIM, ne pas oublier d’ajouter l’option -i /path/vers/les/hosts/locaux (man dkim-milter), le cas échéant seuls les les mails en provenance de 127.0.0.1 seront signés.

Pour finir, la seule application “standalone” (comprendre, qui n’a pas besoin d’apache / php et tous leurs amis) convenable pour manipuler une database LDAP reste “gq”. J’aurais imaginé que les choses avaient un peu évolué depuis 5 ans mais finalement non.

Add-on

N’oubliez pas de placer la directive :

define(`confLDAP_CLUSTER', `nom-convivial')

Et de renseigner le champs “sendmailMTACluster” dans toutes vos entrées LDAP.

le cas échéant les queries LDAP sont tout simplement ignorées.

De plus, il est inutile de protéger l’accès au subtree ou=sendmail, la doc OpenLDAP nous montre comment libérer ce scope :

access to dn.subtree="ou=sendmail,dc=dotpure,dc=net" by * read