Emile “iMil” Heitor ‘s home

Heureux possesseur d’un téléphone Android, j’utilise comme bon nombre de mes compères le logiciel K9-mail, probablement le meilleur MUA disponible sur cette plateforme, et qui a le bon goût d’être Libre, au contraire des centaines de milliers d’applis merdiques à 0.99€.
Jusqu’à présent, je n’utilisais K9 que pour lire mon mail, essentiellement dans le metro, “on the go”. Et puis finalement, je suis dit qu’il serait fort convivial de pouvoir utiliser mon serveur mail perso depuis un peu partout.
Mon serveur mail, est-il besoin de le préciser, est un domU NetBSD sur lequel sont executés Sendmail et dovecot.
Il y a un certain temps de cela, j’avais documenté la méthode pour FreeBSD, et assez étrangement, jamais pour NetBSD. Je vais donc corriger le tir de ce pas.

La première chose à faire est de préciser que nous souhaitons bénéficier du support TLS et SASL dans sendmail. Ceci est réalisé dans le fichier /etc/mk.conf:

PKG_OPTIONS.sendmail=   tls sasl

Je ne sais pas si cela est lié au fait que la machine sur laquelle j’ai mené l’opération est “encore” en 5.0.2, mais la compilation de cyrus-sasl a misérablement échoué dans sa configuration par défaut. Ceci:

db_ndbm.c: In function '_sasldb_getdata':
db_ndbm.c:95: warning: passing argument 3 of 'utils->getcallback' from incompatible pointer type

M’a mis sur la voie, et j’ai donc ajouté dans mon /etc/mk.conf la ligne suivante:

SASL_DBTYPE=            berkeley

Un make update clean plus loin, tout était installé. Il est à noter que, par défaut, cyrus-sasl ne fournit aucun plugin, aussi, il sera nécessaire d’en installer au moins un, par exemple:

# cd /usr/pkgsrc/security/cy2-login
# make install clean

Qui nous permettra d’utiliser le couple login/password de notre système. Deux étapes sont nécessaires pour utiliser cette méthode, tout d’abord, il faut installer le démon saslauthd, en charge des échange d’authentification plain text:

# cd /usr/pkgsrc/security/cyrus-saslauthd/
# make install clean
# cp /usr/pkg/share/examples/rc.d/saslauthd /etc/rc.d
# echo "saslauthd=YES" >> /etc/rc.conf
# /etc/rc.d/saslauthd start

Puis de préciser au plugin SASL qu’il devra utiliser le démon saslauthd pour l’authentification en provenance de sendmail.

# cat /usr/pkg/lib/sasl2/Sendmail.conf
pwcheck_method:saslauthd

Nous ajoutons maintenant à sendmail la gestion de ces deux nouvelles fonctionnalités:

# cd /usr/pkg/share/sendmail/cf
# cat monserveur.mc
[...]
dnl ### SMTP AUTH
define(`confAUTH_MECHANISMS', `LOGIN')dnl
TRUST_AUTH_MECH(`LOGIN')dnl
dnl ### STARTTLS
dnl ### Ces sertificats sont en provenance de CACert.org. Il ne s'agit pas de certificats auto-signés
define(`confCACERT_PATH',`/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/cacert.crt')
define(`confSERVER_CERT',`/etc/mail/certs/certificat_serveur.pem')dnl
define(`confSERVER_KEY',`/etc/mail/certs/certificat_privatekey.pem')dnl
[...]

Puis nous compilons et installons la nouvelle configuration:

# make install-cf CF=monserveur
rm -f monserveur.cf
m4 ../m4/cf.m4 monserveur.mc > monserveur.cf || ( rm -f monserveur.cf && exit 1 )
echo "### monserveur.mc ###" >>monserveur.cf
sed -e 's/^/# /' monserveur.mc >>monserveur.cf
chmod 444 monserveur.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/sendmail.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/submit.cf

À l’issue d’un /etc/rc.d/sendmail restart, nous devrions constater les choses suivantes:

# sendmail -d0.1 -bv root | grep SASL
                SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB XDEBUG

Et également:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220monserveur ESMTP Sendmail 8.14.5/8.14.5; Fri, 11 Nov 2011 13:13:17 +0100 (CET)
ehlo localhost
250-monserveur Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE 5000000
250-DSN
250-ETRN
250-AUTH LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

Ne reste alors qu’à configurer votre MUA pour qu’il utilise votre serveur SMTP sur le port 587 en TLS avec la méthode LOGIN, avec les login/passwd de l’utilisateur souhaité.

Enjoy.

Ce matin, j’ai mis à jour le dom0 Debian d’une de mes machines. Passionnant me direz-vous. L’opération a consisté en la migration de Lenny vers Squeeze. De plus en plus interessant hein ? L’upgrade s’est effectué sans trop de peine, après quelques apt-get -f install et autres réinstallations de packages ayant sauté dans la bataille, rien de palpitant. Me voici donc avec un kernel 2.6.35-2 sur un Xen 4 flambant neuf.

Ce dom0 accueille des domU NetBSD. Des NetBSD 5.0.2 pour être précis. Et c’est le drame: Le PR 44743 indique en effet:

Subject: Network doesn’t work on DomU NetBSD 5.1 which is run on Debian Squeeze Dom0 (Xen 4)

Ce à quoi Dieu^WManuel Bouyer répond:

No, copy mode support was added to the backend (dom0) before 5.1, but
it was added to the frontend (domU) after 5.1 was released. So you need
something newer from the netbsd-5 branch.

Vous voyez poindre le bordel ? “Mais migre, bigre de couillon” me direz-vous, et vous aurez raison, seulement cette machine construit des packages (via bulk build, voir le post précédent) pour un certain nombre d’autres machines, elles aussi en 5.0.2. Bref, rien n’est simple. J’ai donc adopté une méthode “alternative” (aussi appelée la méthode *rhon* *rhon* *huiiiiii*): patcher le noyau 5.0.2 avec les bits and pieces nécessaires en provenance de netbsd-5. Finalement, cela n’a pas été si compliqué. Il suffit de cvs up -rnetbsd-5 -dP dans src/sys/arch/xen et src/sys/arch/x86 puis de relancer un config, make depend, make pour obtenir un noyau domU 5.0.2 muni du support copy mode.

“All went better than expected”.

Foreword: this post will be written in english as many pkgin users don’t speak french. Sorry to my french readers then, and sorry also to my english readers as i’m not as fluent in english as i am in french :)

I subscribed to jmmv’s blog, The Julipedia, a while ago and found his idea of the “Kyua: Weekly status report” very inspiring, that’s a good way to keep your users informed on how the project is moving and keeps you focused on your TODO (although i hate TODO’s…). I doubt i’ll have the time to write a weekly report, but at last i’ll try to write a post whenever important updates are made to my beloved project.

So let’s begin !
As you, pkgin users, may be aware of, i’m working on the future 0.5 release, which includes massive internal changes plus some features that have been asked and i found interesting. So, in addition to the features i already listed in this mail sent to pkgsrc-users@, here are some hilights on recent changes:

• pkgin now has a new logo !
• it is now possible to export / import your keep-list, pretty much like dpkg‘s get/set-selection. The exported list is in pkg_chk‘s format. Thanks wiz@ for the idea
• pkgin install can now take a “blob” as an argument, i.e. pkgin in 'mysql-server<5.5', thanks filip@ for the idea
• pkgin now uses pkgsrc’s pkg_install for NetBSD also
• added the -t modifier, mostly for debugging purposes, in order to trace the dependency tree and impact lists
• pkg_install error logs are handled in a nicer way
• enlisted pkgin’s code to ohloh (click on “i use this” !)
• plus usual bugfixes

Yeah, these were fairly productive holidays :) Of course most of these changes are only available in CVS, see http://pkgin.net for details. Some of them have already made their way to pkgsrc-wip, i try not to insert big changes now, so wip and CVS should be sync’ed quite often.

Needs to be done:

• make pkgin’s pkgsrc package depend on pkgsrc’s pkg_install
• reproduce and fix 2 different bugs two users had
• optimize the dependency loop regarding packages that exists in many versions (i.e. bash)
• check if pkg_install is to be upgraded and then push it on top of ordered list
• test Minix 3.2.0

Hope i’ll make it to pkgsrc 2011Q4 !

Depuis que j’ai commencé la serie de billets qui parlent de tunnels, on me demande en substance “c’est chouette et tout mais… tu vas ou là ?”. Rappelez-vous, le premier billet de cette serie parlait de tunnels suédois, et bien évidemment, je ne suis pas le seul à désirer contrôler plus finement le chemin qu’empruntent les paquets IP qui sortent de mes machines. Aussi, avec quelques amis, avons nous décidé de mettre en place un réseau possiblement sécurisé, interconnecté, et hautement disponible. Ainsi, l’objectif est de pouvoir contacter nos réseaux à travers des liens cryptés, et de sortir sur le Net en utilisant differents tunnels, ces routes se construisant dynamiquement grâce au protocole BGP.
Hormis l’aspect purement pratique de la chose, le projet est passionnant et les techniques employées sont élégantes et interessantes. For teh lulz quoi.

Plus précisemment, considérons une machine, hébergée quelque part sur l’Internet. Cette machine fait office de routeur BGP à l’aide du logiciel Quagga. Ce routeur BGP est connecté à d’autres routeurs représentant autant de Systèmes Autonomes (AS), privés bien entendu, on parle ici d’EBGP (Exterior Border Gateway Protocol). À ce routeur, je connecte ma passerelle maison, qui fait partie de mon AS privé. C’est un lien IBGP (Interior Border Gateway Protocol).

Lorsqu’un noeud, que j’ai déclaré dans la configuration du routeur, se connecte à notre réseau, ce dernier annonce les routes qu’il souhaite. Par exemple un réseau d’échange ou encore une route par defaut. Un système de poids fera préférer tel ou tel chemin pour joindre un point du réseau.

Voici un exemple de configuration, très simple, de l’un des routeurs de bordure:

password trescomplique
enable password trestrescomplique
!
router bgp 65535
 bgp router-id 10.0.1.1
 network 192.168.10.0/24
 neighbor 10.0.1.2 remote-as 65535
 neighbor 10.0.2.1 remote-as 65536
!
ip forwarding

On établit ici une liaison IBGP vers 10.0.1.2 et EBGP vers 10.0.2.1, et on annonce sur ces réseaux comment joindre 192.168.10.0/24.

Comme vous vous en doutiez, ces routeurs sont tous reliés entre eux par une liaison point à point IPsec, routent leur traffic à travers des tunnels gre(4) sur les liaisons IPsec, et sortent tous par défaut sur Internet via la Suède.

Ce dernier point n’est pas anodin d’un point de vue routage; en effet, il est contre-productif qu’une partie du traffic, celui de l’infrastructure, emprunte la suède pour communiquer avec ses pairs. Pire, dans certains cas cela provoquera des cas de routage asymétrique. Aussi, il est indispensable de mettre en place des règles de gestion de routage… en amont de la table de routage ainsi que de la SPD d’IPsec. La solution ? PF bien sûr :)

Voici la configuration que j’utilise pour m’assurer que tout le traffic lié à l’infrastructure emprunte bien des chemins optimaux (explication dans la conf):

real_if="xennet0"
tun_if="tap0"
gateway="192.168.0.254"

openvpn="{ 1194 10010 10020 }"
direct_ports="{ 22 53 80 179 443 500 4500 }"
ipsec="{ 179 500 4500 }" # ipsec protocols + BGP

# comme vu dans un billet precedent, on s'assure de repondre via notre IP
# publique "reelle" lorsque l'on est interroges sur $direct_ports
pass in quick log on $real_if reply-to ($real_if $gateway) proto { tcp, udp } \
        from any to any port $direct_ports

# meme methode pour les protocoles utilises par IPsec
pass in quick log on $real_if reply-to ($real_if $gateway) proto { ah, esp } \
        from any to any

# on route les protocoles d'echange de cle (isakmp) sur l'interface
# reelle $real_if
pass out quick log route-to ($real_if $gateway) proto { tcp, udp } \
        from any to any port $ipsec
# on route tout le traffic AH/ESP via $real_if
pass out quick log route-to ($real_if $gateway) proto { ah, esp } \
        from any to any

# on bloque tout le traffic se dirigeant vers l'interface reelle $real_if
# sauf OpenVPN et les protocoles utilises par IPsec
block out log on $real_if
pass out on $real_if proto { tcp, udp } from any to any port $openvpn
pass out on $real_if proto { ah, esp } from any to any

Ces règles doivent être chargées après le chargement d’OpenVPN, on peut réaliser cette séquence très simplement à l’aide de la directive up du fichier de configuration du logiciel:

script-security 2
up /home/imil/bin/pf-up.sh

Le script en question est trivial:

#!/bin/sh

/sbin/pfctl -f /etc/pf.conf-ovpn

Moyennant quoi, à chaque démarrage d’OpenVPN, ces règles viendront s’assurer qu’aucun paquet hors contrôle ne transitera par l’IP publique “réelle” de notre serveur, tout le traffic non lié à l’infrastructure devant passer par le tunnel Suédois.

Le projet est toujours en cours de construction et il reste encore quelques boulons à serrer, mais ‘vous inquiétez pas, vous serez les permiers au courant des évolutions ;)

Un dernier mot, certains lecteurs m’envoient depuis quelque jours leur setup à debugger et m’expliquent en détail les problèmes qu’ils rencontrent, vous comprendrez aisemment que je ne peux humainement pas dépiler tout ça tout seul, mais n’oubliez pas que, modulo votre bienséance, vous êtes bienvenu sur le canal #gcu@freenode !

…so i put a tunnel in your tunnel so you can route while you route. Une fois n’est pas coutume, Xzibit résume assez bien la situation.

Mais revenons quelques heures en arrière.

Alors que nos tunnels IPsec fonctionnent sans broncher depuis nos dernières experiences, l’un des objectifs finaux de l’opération montrait le boût de son nez: router des réseaux à travers nos fâmeuses liaisons IPsec. Et “ça marche pas”(tm).
Plus précisemment, il apparaît impossible de joindre d’autres réseaux que ceux liés par IPsec, ou plus particulièrement la SPD, et en y reflechissant à deux fois, ceci est parfaitement normal. La solution ? Un tunnel par dessus le tunnel !

Fort heureusement, nos UNIX modernes bénéficient de systèmes de tunneling peu coûteux en overhead, et parmi eux, gre(4). Pourquoi gre(4) et non gif(4) ? honteuse réponse: IPsec + domU + gif == kernel panic. Si.

En réalité, la mise en place d’un tel mécanisme est beaucoup plus simple qu’il n’y parait, nous allons simplement utiliser la liaison déjà établie par IPsec, 10.0.0.1 vers 10.0.0.2 selon l’exemple du billet précédent, pour établir un tunnel qui ne sera pas soumis à la base stricte d’IPsec et nous permettra de router ce que bon nous semble d’un bout du tunnel à l’autre.

Cela est à nouveau pris en charge très natuellement par NetBSD; il suffit, pour mettre en place cette nouvelle interconnexion, de créer un fichier /etc/ifconfig.gre0 de la forme suivante:

create
inet 10.0.1.1 10.0.1.2 netmask 255.255.255.255
tunnel 10.0.0.1 10.0.0.2 up

pour que s’établisse, sur notre interconnexion IPsec (10.0.0.1 – 10.0.0.2), une nouvelle liaison (10.0.1.1 – 10.0.1.2) libre d’être utilisée comme pivot de routage.

Attention ! Afin que ce petit monde fonctionne sans soucis à chaque démarrage, il ne faudra pas utiliser /etc/ifaliases comme je l’annonçais dans le précédent billet, mais compléter le fichier /etc/ifconfig.iface de cette façon:

up
inet 1.2.3.4 netmask 0xffffff00
inet 10.0.0.1 netmask 0xffffffff alias

car autrement, les alias seront montés après les tunnels gre(4), ifaliases étant manifestement appelé à la suite de ifconfig.if.

More to come…

02 / 08 / 2011 – Mise à jour il-ne-faut-pas utiliser lo0 comme interface pivot, il ne faut pas. Pour une raison que j’ignore totalement, aucun autre protocole qu’ICMP n’a jamais fonctionné pendant nos tests, si d’aucuns ont une explication rationelle, je suis toutes ouïes. Le problème est résolu en utilisant les interfaces physiques.

IPsec. À l’évocation de ce terme technique, vous avez avalé d’un trait votre Gin Tonic, vous éteignez votre écran en espérant qu’il s’agisse d’un mauvais rève et vous décrivez des cercles dans votre bureau en vous frappant la tête avec une règle metallique.
Je le sais, j’étais pareil.

Et puis, avec l’ami mat, nous avons lu, épluché, factorisé, testé, pesté, hurlé, et finalement, je vous propose un petite petite bafouille sur l’art de mettre en place un tunnel IPsec entre deux machines NetBSD. Ouais.

Il me semble que cette configuration est assez classique, jugez plutot: une passerelle, chez vous, disposant d’un bridge vers un réseau quelconque d’opérateur qui fournit une adresse IP fixe publique (si ce n’est pas le cas, vous savez ce qu’il vous reste à faire), et de l’autre coté, une machine dédiée dont vous disposez chez l’un des multiples hébergeurs low-cost aujourd’hui disponibles.
Petite particularité, cette dernière, dans mon cas, est une machine virtuelle NetBSD, un domU hebergé par un dom0 Debian/GNU Linux.

En raison de cette particularité, la première étape consiste à manipuler iptables afin de translater les differents protocoles nécessaires à IPsec directement vers ma machine virtuelle. Sur mon dom0, j’ajoute donc les règles suivantes:

# isakmp
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.1:500
# isakmp + nat-t
-A PREROUTING -i eth0 -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.1:4500
# protocole ESP
-A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.2.1
# protocole AH
-A PREROUTING -i eth0 -p ah -j DNAT --to-destination 192.168.2.1

Nous considérerons que l’IP publique de cette machine est 1.2.3.4, l’IP privée du domU est 192.168.2.1.

Le logiciel que nous utiliserons pour établir notre tunnel IPsec, d’un coté et de l’autre, sera le fâmeux racoon.

Je vous jette en pâture la configuration simplifiée que j’utilise, cette dernière étant expliquée point par point à cette adresse:

# cat /etc/racoon/racoon.conf
path pre_shared_key "/etc/racoon/psk.txt";

padding {
    maximum_length 20;
    randomize off;
    strict_check off;
    exclusive_tail off;
}

listen
{
    isakmp 192.168.2.1 [500];
}

remote anonymous
{
    exchange_mode aggressive;
    dpd_delay 20;

    weak_phase1_check on;

    proposal
    {
        encryption_algorithm 3des;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo anonymous
{
    pfs_group 2;
    encryption_algorithm 3des;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

Notez que je fais écouter isakmp sur l’adresse privée du domU.
Il faudra créer le fichier /etc/racoon/psk.txt avec des droits stricts (0600), qui contiendra l’adresse IP du peer et une passphrase:

# cat /etc/racoon/psk.txt
5.6.7.8 unepassphrasedunfortbeaugabarit

5.6.7.8 étant l’IP publique de ma passerelle.
Coté passerelle, justement, nous créons l’exacte copie de cette configuration en remplaçant l’ip d’écoute de isakmp et l’ip publique présente dans le fichier /etc/racoon/psk.txt par l’IP publique de notre machine hébergée (1.2.3.4, donc).

Ceci étant fait, il faut maintenant indiquer au noyau pour quels sous-réseaux il est nécessaire de crypter le trafic IP. Cette indication est donnée via l’outil setkey, qui lira le fichier /etc/ipsec.conf sous NetBSD (nous y reviendrons). Un peu de concentration, voici son contenu sur la machine hébergée:

# on fait le ménage
flush;
spdflush;
# et on indique nos routes
spdadd 10.0.0.1/32 10.0.0.2/32  any -P out ipsec esp/tunnel/192.168.2.1-5.6.7.8/require;
spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec esp/tunnel/5.6.7.8-192.168.2.1/require;

Ici, 10.0.0.1 est le “réseau” (une IP unique dans mon cas) joignable à travers IPsec, via le tunnel établi entre l’IP privée de mon domU et l’IP publique de ma passerelle. De l’autre côté, le “réseau” est 10.0.0.2.
Afin de clarifier les choses, voici la configuration coté passerelle:

flush;
spdflush;
spdadd 10.0.0.2/32 10.0.0.1/32  any -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/require;
spdadd 10.0.0.1/32 10.0.0.2/32 any -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/require;

Miroir miroir, c’est suykidikihé, on observe que la configuration est l’exacte symétrie de celle présente sur la machine hébergée à cette difference près que notre passerelle s’adresse à une IP publique, le dom0, de l’autre coté, s’occuppe de translater tout ce merdier en IP privée.
Ça va, vous suivez toujours ?
Il ne reste qu’une opération à mener pour que ces réseaux se voient: router effectivement ces divers réseaux entre eux; mais voila, pour l’instant les IPs endpoint du tunnel IPsec n’existent pas, et pour pallier à cela, nous allons une fois de plus abuser de l’ami loopback nous allons utiliser des alias sur les interfaces physiques (virtuelles dans le cas du domU) . Par exemple, sur notre domU:

# ifconfig xennet0 alias 10.0.0.1 netmask 255.255.255.255

Et sur notre passerelle:

# ifconfig sip0 alias 10.0.0.2 netmask 255.255.255.255

Reste à effectivement router ces “réseaux” entre eux, par exemple sur la passerelle:

# route add -host 10.0.0.1 10.0.0.2

Avant d’automatiser tout ce petit monde, vous pouvez d’ores et déjà réaliser quelques tests “live”. Chargez d’abord vos règles SPD des deux côtés:

# setkey -f /etc/ipsec.conf

Puis démarrez racoon en mode debug + verbose, sans passer en tâche de fond:

# racoon -F -d -v -f /etc/racoon/racoon.conf

Une fois satisfaits, nous allons pouvoir automatiser ces opérations afin qu’elles soient prises en compte à chaque boot. Non, nous n’allons pas écrire un script à la con.
Tout d’abord, nous préparons nos interfaces d’alias à l’aide du fichier /etc/ifaliases, sur notre machine hebergée par exemple:

# cat /etc/ifaliases
10.0.0.1 xennet0 255.255.255.255

Puis nous mettons en place les routes statiques:

# cat /etc/route.conf
host 10.0.0.2 10.0.0.1

Enfin, nous indiquons à rc qu’il devra charger la base SPD et démarrer racoon à l’aide du fichier /etc/rc.conf:

ipsec=YES
racoon=YES

Et nous y voila, une connectique sûre, standard et bidirectionelle en un tournemain.

En terme de latence, ça donne ça:
Sans IPsec

64 bytes from 1.2.3.4: icmp_seq=0 ttl=52 time=21.770 ms

Avec IPsec

64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=21.869 ms

Tranquille hein.

Je vous livre en sus les quelques liens qui nous ont aidé à peaufiner notre configuration:

• http://www.kame.net/newsletter/20001119/
• http://www.netbsd.org/docs/network/ipsec/
• http://www.netbsd.org/docs/network/ipsec/rasvpn.html
• http://wtf.hijacked.us/wiki/index.php/IPSEC-Racoon
• http://www.mad-hacking.net/documentation/linux/networking/ipsec/nat-vpn.xml
• http://www.lacave.net/~fred/racoon/config.html

Et vous souhaite une bonne nuit.