Emile “iMil” Heitor ’s home

L’année dernière, je mettais en place dspam, sur mon serveur dédié. Naïf, je me disais que pour gerer mes propres mails, le backend sqlite serait amplement suffisant, et finalement tout ce petit monde a parfaitement fonctionné pendant quelques mois. Et puis la database a grossi, grossi, grossi au point d’etre lente à crever et provoquer ce type de réaction :

pid 71865 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72017 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72289 (dspam), uid 0: exited on signal 6 (core dumped)

Après que 2 attaques massives de spams aient écroulé la machine, je me suis enfin décidé à changer de backend… et la différence est simplement indescriptible.

L’opération s’est avérée plus simple que je ne l’imaginais. Tout d’abord, il est nécessaire de re-installer le port dspam en y ajoutant le support MySQL à l’aide de la commane make config

Un make deinstall reinstall plus loin, le binaire supporte les deux backends (sqlite et MySQL), et avant d’apporter les modifications à la configuration de dspam, nous nous assurons de créer une database dspam et de peupler cette dernière avec les commandes SQL fournies dans le package dspam :

$ mysql -u dspam -p dspam < /usr/local/share/examples/dspam/mysql/mysql_objects-4.1.sql

Nous pouvons alors modifier le fichier dspam.conf :

StorageDriver /usr/local/lib/libmysql_drv.so
# [...]
MySQLServer     /path/vers/mysql.sock
MySQLUser               dspam
MySQLPass               mangeducacaspammer
MySQLDb                 dspam
MySQLConnectionCache    10
MySQLUIDInSignature    on

Et redémarrer le serveur :

# /usr/local/etc/rc.d/dspam restart

Reste à nourrir notre nouvelle database à l’aide de deux corpus spam et ham d’environ 1000 mails chacun (voir le post de l’année dernière).

Pour finir, j’ajoute un cron-job qui nettoie la base de données tous les soirs, à l’aide d’un jeu de commandes SQL fourni par le package dspam :

30 01 * * * /usr/local/bin/mysql -u dspam --password=mangeducacaspammer dspam < /usr/local/share/examples/dspam/mysql/purge-4.1.sql

Et mon gentil dédié ne souffre plus.

Notez par ailleurs que devant une telle recrudescence, j'avais fini par réinstaller l'excellent milter-greylist du sieur Emmanuel Dreyfus, et que le résultat est sans appel: si certains MTAs tolèrent mal les codes 4xx et ne renvoient le mail que plusieurs heures plus tard, mon ratio de spams, lui, est passé de 800 / jour en moyenne à 30 / jour en moyenne. Le choix est vite fait...

J’ai topé ça dans une boutique à Montréal :

Vraiment pas mal. Si l’on possede quelques notions de C et de système, l’auteur nous fait manipuler du module kernel FreeBSD dès la 10eme page, et nous apprend à ruser dès la vingtieme. Je regrette qu’il soit si petit (à peine 130 pages), j’en aurait bien avalé le triple.

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.

y’a mon bouquetin et 2/3 autres qui me demandent la conf du kimloli, et plus particulièrement la conf des jails. Voici en quelques mots les divers points clé du bestiau. Rien de super novateur, mais ça me servira aussi de pense bête.

Tout d’abord, les jails. Ayant fait crouter la machine en utilisant les scripts rc.d fournis, et même si le bug a été corrigé recemment dans la branche FreeBSD 6.2, ça m’a refroidi d’utiliser les scripts officiels. Sur les conseils du sieur ic, je me suis donc rabattu sur jailctl, qui permet moult opérations sur les jails. Mon jails.conf ressemble à ceci :

IF="lo0"
JAIL_HOME="/home/jails/"
ROOT_PW='$1$blablapwetpwettoussa'
PROCFS="FALSE"
LINPROCFS="FALSE"
BACKUPDIR=$JAIL_HOME
BACKUP_EXCLUDE="--exclude ./usr/ports/* --exclude ./tmp/* --exclude ./var/tmp/* --exclude ./usr/src/*"
JAILS="web1:192.168.0.1"
INSTALLWORLD_FLAGS=""
RC_CONF='sendmail_enable="NONE" sshd_enable="YES" portmap_enable="NO" network_interfaces="" tcp_keepalive="NO" inetd_enable="YES"'
NAMESERVER="ip.du.kimloli"
BEFORESTATUS_HOOKS="/usr/bin/true"
AFTERSTATUS_HOOKS="/usr/bin/true"
BEFORESTART_HOOKS="/usr/bin/true"
AFTERSTART_HOOKS="/usr/bin/true"
BEFORESTOP_HOOKS="/usr/bin/true"
AFTERSTOP_HOOKS="/usr/bin/true"

Après avoir préparé un world dans le host en suivant cette documentation (et sans passer par la case make install*), on installe son environnement jailé via jailctl create nomdujail. Il sera de bon ton de manger cette doc avant de se lancer.
J’ai choisi d’”aliaser” mes interfaces jail sur le loopback plutot que sur l’interface NIC elle même simplement parce que j’ai été refroidi par la déconvenue sus-citée lors de l’utilisation d’/etc/rc.d/jail.

On appréciera la possibilité de fine-tuner la post-installation en utilisant les scripts et templates situés dans /home/jails/addons.

Comme il est assez probable qu’on voudra que notre jail puisse “sortir” sur Internet, nous devons mener deux opérations :

1. s’assurer que le host peut forwarder
2. lui faire faire du NAT des adresses jailées

Ce qui se traduit par :

$ grep forw /etc/sysctl.conf
net.inet.ip.forwarding=1

et

# /etc/pf.conf

int="vr0"
# NAT
# jails
nat pass on $int from 192.168.0.0/24 to any -> $int

De plus, la finalité étant de faire en sorte que ce soient nos jails qui répondent, par exemple, aux requetes HTTP, nous plaçons la redirection suivante :

# /etc/pf.conf

rdr pass on $int proto tcp from any to any port 80 -> 192.168.0.1 port 80

Reste maintenant à démarrer notre jail via la commande jailctl start nomdujail, puis à l’administrer comme un environnement classique. Dans la variable RC_CONF du fichier jails.conf, nous avons signifié qu’il fallait démarrer sshd, nous pouvons donc nous connecter à notre environnement restreint par ce biais. Pensez tout de même à désactiver le PermitRootLogin.

Afin de ne pas me trimballer deux arbres de ports, je mount /usr/ports via nullfs en read-only :

/usr/ports on /home/jails/web1/usr/ports (nullfs, local, read-only)

Puis dans le jail je configure ces quelques variables dans le make.conf

WRKDIRPREFIX=/var/ports/obj
PACKAGES=/var/ports/packages

Afin de me laisser la possibilité de compiler un port si besoin.
En fait, dans le jail, j’utilise simplement pkg_add et peuple donc l’environnement de packages binaires. Je spécifie ces variables dans mon ~/.cshrc :

setenv PACKAGEROOT ftp://ftp.fr.freebsd.org
setenv PACKAGES /var/ports/packages

afin de :

. récupérer des packages distants sur un miroir proche (pkg_add -vr)
. ajouter des packages locaux depuis un repertoire ad’hoc (pkg_create -b sur le host puis pkg_add -v dans le jail)

J’imagine actuellement un processus simple, basé sur un bête script shell, qui me permettra de tenir à jour les packages binaires du jail par rapport aux ports compilés sur le host. Si quelqun connait un projet similaire, qu’il me fasse signe ;)

c’est du vil propriétaire, donc je posterai pas ca dans le jardin magique, mais comme je sais que vous etes nombreux à utiliser skype malgré tout, voici un petit howto-skype-on-FreeBSD

Pour FreeBSD 5 / 6
Pour FreeBSD 4

Et si tu te demandes quel peut bien etre l’interet de la manip étant donné qu’il existe déjà un port, regarde un peu la gueule des fontes par defaut…

Et c’est au tour d’apache. Très très simple :

cd /usr/ports/www/mod_vhost_ldap/
make install clean

Si votre apache n’est pas compilé avec le support LDAP vous vous ferez insulter.
À noter que, contrairement à ce que dit le port :

## WITH_LDAP: Enable LDAP support (mod_auth_ldap) (implies WITH_LDAP_MODULES)

Si je ne place pas explicitement WITH_LDAP=yes et WITH_LDAP_MODULES=yes, je me prend un unresolved symbol au démarrage d’apache.

Ajoutez maintenant dans votre httpd.conf (dans cet ordre) :

LoadModule ldap_module libexec/apache2/mod_ldap.so
LoadModule vhost_ldap_module libexec/apache2/mod_vhost_ldap.so

puis

VhostLDAPEnabled on
VhostLDAPUrl "ldap://127.0.0.1/ou=votre,dc=basedn"
VhostLdapBindDN "cn=utilisateur,ou=qui,dc=binde"
VhostLDAPBindPassword "mot de passe convivial"


Copiez le schéma fourni /usr/local/share/doc/mod_vhost_ldap/mod_vhost_ldap.schema dans /usr/local/etc/openldap/schema/ et ajoutez

include /usr/local/etc/openldap/schema/mod_vhost_ldap.schema

dans votre slapd.conf

Evidemment, redémarrez slapd et httpd.

Il ne vous reste plus qu’à provisionner avec votre editeur LDAP favori. Les attributs sont triviaux, par exemple :

# jard.in, apache, jardin
dn: apacheServerName=jard.in,ou=apache,dc=jardin
objectClass: top
objectClass: apacheConfig
apacheServerName: jard.in
apacheDocumentRoot: /home/www

Je regrette toutefois que l’auteur n’ait pas prévu des champs relatifs aux logfiles, j’ai du utiliser une vieille bidouille à base de LogFormat :

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /var/log/httpd-access-vhosts.log combined

Pour faire passer sur le fichier httpd-access-vhosts.log le script split-logfile fourni avec apache2 qui sépare ce type de log fonction du vhost. Par très classe.