Emile “iMil” Heitor ‘s home

Au boulot, ce sont des routeurs Juniper J2350 qui se chargent d’acheminer les lutins de l’internet vers nos équipements. Depuis quelques temps, les routeurs en question s’occuppent entre autres d’annoncer nos plages d’IPs grâce au protocole BGP.

Si l’établissement des sessions eBGP avec nos fournisseurs d’accès n’a posé aucun problème, l’établissement de la session iBGP entre nos differents routeurs montrait une charge CPU, mais surtout une consommation mémoire anormales, jusqu’à provoquer recemment le crash de l’un d’entre eux.

J’ai toujours été fasciné par l’inutilité des services support des constructeurs ou autres grosses structures, et Juniper ne déroge pas à la règle. De fait, je décide donc d’exposer mon problème non pas au support officiel, qui mettra déjà une bonne 15aine de jours à comprendre ce que je veux bien dire par “iBGP”, mais plutot aux forums communautaires du fabriquant. Bien evidemment, comme dans tous les forums de la terre, on obtient en premier lieu quelques réponses des “know-it-all” qui vous ressortent le contenu d’une plaquette marketing: “I would agree, a J2320 is not designed to take a full set of routes.”, mais avec un minimum de patience, on finit par tomber sur quelqun qui sait de quoi il parle.

Un utilisateur catégorisé “Recognized Expert” me dit la chose suivante : “I have used also J2320 routers with 2x full feed on them. Works good. But I downgraded to the last JUNOS 9.3 that runs only in packet mode. That saves a couple of RAM.”

Et c’est là le tournant de l’histoire. En effet, lorsque je reçus mes jouets, je m’aperçus qu’ils tournaient sur une version bien ancienne de JunOS (le système d’exploitation dérivé de FreeBSD qui fait fonctionner ces routeurs), et comme tout bon administrateur impatient, je me jette sur les mises à jours. Grossière erreur. Ce que m’explique le monsieur du forum, c’est que depuis les releases 9.3R4 de JunOS, le démon en charge du forwarding de paquets n’est plus fwdd mais flowd_hm, une nouvelle mouture qui ne fonctionne plus en simple “mode paquet”, mais établit des sessions (stateful) afin d’inspecter le traffic (l’explication ici).

Le downgrade m’effrayant un peu, je tente 1001 méthodes pour alléger ce démon, mais rien n’y fait, ses 481M de taille font toujours souffrir mes routeurs. La seule solution: downgrader.

Bien évidemment, cette opération s’est réalisée dans la douleur; en effet, ce fameux mode flow based a impliqué des entrées dans la configuration du routeur qui ne sont pas backward compatibles. En particulier, une section zones qui définit des zones de sécurité, et plus précisemment, qui a le droit de “sortir” ou pas, et dans les versions supérieures à 9.3R3, sans cette section, le routeur est aveugle et ne peut pas récupérer sa mise à jour. L’espace du disque flash équipant le J2350 étant limité, il n’était pas possible de télécharger la mise à jour pour l’appliquer localement, j’étais donc obligé d’effectuer l’upgrade à travers le réseau, mais cette opération était vouée à l’échec puisque la mise à jour échouait en raison de l’incompatibilité de la configuration en place avec les versions antérieures. Quadrature du cercle.

Mais voila: JunOS est un UNIX, et Juniper a eu la bonne idée de laisser l’accès à cet UNIX (FreeBSD, donc) par le biais de la commande start shell.

Ainsi, tout en gardant la configuration running activée, je m’en vais modifier le fichier /config/juniper.conf.gz pour en retirer la section security, incompatible avec le downgrade. Un gunzip -c, vi, gzip plus tard, je peux tranquillement invoquer la commande CLI:

foo> request system software add validate no-copy unlink ftp://serveur/junos-jseries-9.3R3.8-domestic.tgz

Et constater que la “mise à jour” s’effectue parfaitement.

Notez qu’afin de ne pas générer de la charge inutile, j’ai au préalable désactivé les annonces vers mes voisins BGP grâce à la commande :

foo# deactivate protocol bgp group ma-session neighbor ip.de.mon.voisin
foo# commit

Un foo> request system reboot plus tard, j’admire :

--- JUNOS 9.3R3.8 built 2009-05-12 22:33:43 UTC

Et constate que cette pourriture de démon flowd_hm a disparu, avantageusement remplacé par fwdd, et que le routeur répond désormais au quart de tour, même avec toutes ses sessions BGP chargées.

Morale de l’histoire: avant de te jeter sur la dernière version d’un soft, vérifie que t’en as bien besoin… (version longue de “if it works, don’t fix it”).

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…