Emile “iMil” Heitor ’s home

Témoignage

Hier, alors que je parcourais la zone privée de mon DNS interne, je constate la présence d’une entrée ajoutée par dhcpd que je ne connais pas. Elle était de la forme :

a0b1e67834a1    A    192.168.0.102

Intrigué, je nmap l’IP en question pour m’apercevoir qu’il s’agit d’une machine windows, exposant fièrement ses ports 135 et 139. Cette fois c’était sur, il ne s’agissait pas d’une machine de mon réseau.

Evidemment, mon premier suspect était l’access point privé de mon réseau. Bien qu’il n’autorise que le WPA et que sa clé ne soit pas triviale, il me semblait clair que l’intru provenait des airs. Dans la hâte, j’éteins l’OpenWrt que j’avais migré en Kamikaze 8.09.2 quelques heures auparavant, et m’aperçois que je ping toujours mon “invité”.

Et puis m’apparait une autre porte d’entrée à mon réseau privé: le CPL.

J’avais acheté des boitiers CPL Netgear voila quelques mois; d’abord utilisés pour mon réseau Wifi public, j’utilisais de temps en temps ces derniers pour accueillir des portables invités ne bénéficiant pas de cartes Wifi. Ni une ni deux, je débranche le boitier CPL de mon switch. Le constat est sans appel, le ping cesse immédiatement, et avec lui, les miliers de paquets impurs à destinations d’adresses en *.ru en UDP, probablement une de ces saloperies de machine windows infectées jusqu’à l’os.

J’avais lu que la technologie CPL ne permettait pas à quelqu’un qui ne se trouvait pas sur le même disjoncteur de se brancher sur mon réseau, il s’agit manifestement d’une vaste supercherie, car logs à l’appui, je suis maintenant certain que l’intrus arrivait sur ma passerelle par ce biais. Le seul élément rassurant, c’est qu’il semble que la machine zombie en question s’invitait sur mon réseau involontairement. Mon voisin (quel qu’il soit) branchait probablement sa machine à un autre boitier CPL, effectuait une requète DHCP à laquelle mon serveur dhcpd répondait, ce dernier enregistrant ensuite l’IP affectée sur mon DNS.

Mes boitiers CPL servent désormais de décoration au fond d’une corbeille.

Pour des raisons évidentes, j’ai décidé de rendre un peu moins aisée (i.e. pas immédiate) la découverte de mon IP. Plus précisemment, pour certains protocoles et pour certaines machines, je veux que l’IP vue par mon/mes peers ne soit pas directement l’IP que mon fournisseur d’accès m’affecte.

J’ajoute, mais cela n’a evidemment aucun rapport avec cet article, que certains pays intellectuellement plus développés ont recemment confirmé que le partage de fichiers sur le réseau n’était pas illégal sur leur sol.

Le postulat est donc le suivant: seules certaines machines de mon réseau privé devront “sortir” sur une passerelle differente, et uniquement pour certains ports et protocoles.

Pour réaliser cette petite tambouille, j’ai à ma disposition :

• Un serveur dédié ou virtuel hébergé “ailleurs”, possédant une interface sur une DMZ
• Le serveur en question fonctionne sous GNU/Linux, on gère donc le NAT et le firewalling grâce à iptables
• Une passerelle qui me relie à l’Internet par le biais de mon fournisseur d’accès
• Cette passerelle fonctionne sous NetBSD 5.0.2, on gère le NAT et le firewalling grâce à pf (notez qu’ipf ne permettrait pas, à ma connaissance, d’utiliser les fonctions qui nous seront nécessaires)

La première étape consiste à établir un lien VPN entre la passerelle et le serveur dédié. J’ai utilisé OpenVPN, solution de choix de par sa simplicité, sa souplesse et sa grande stabilité. Étant donné qu’il existe un nombre incalculable de documentations sur cet outil, je colle ici mes configurations client et serveur sans plus de détails :

Sur le serveur :

tls-server

port 4444
dev tun
proto udp
local mon.serveur.dedie

cd /home/imil/etc/openvpn
ca keys/ca.crt
cert keys/dedie.crt
key keys/dedie.key
dh keys/dh1024.pem

client-config-dir ccd

server 10.20.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client
route 192.168.1.0 255.255.255.0

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

status openvpn-status.log

verb 3

Sur le client :

tls-client

proto udp
dev tun0

remote mon.serveur.dedie 4444

nobind

cd /usr/pkg/etc/openvpn/dedie-keys
ca ca.crt
cert monhost.crt
key monhost.key

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

pull

verb 3
log /var/log/openvpn.log

Une fois OpenVPN démarré sur chaque point, une interface tun0 monte, avec coté serveur une IP du type 10.20.0.1 et côté client, 10.20.0.6.
Notez que, coté serveur dédié, on verra arriver une machine depuis la passerelle avec son IP réelle sur le réseau domestique, soit ici 192.168.1.0/24. Ainsi, c’est ce sous-réseau que nous devons NATer sur le dédié GNU/Linux.

Une particularité de mon montage est que je ne souhaite pas utiliser l’IP publique principale de mon serveur public car celle-ci possède un reverse sur mon domaine et est facilement identifiable. Par chance, mon hébergeur me donne la possibilité d’ajouter des alias IP routés sur l’interface publique. En l’occurence, c’est précisemment sur cet alias que j’effectue un source NAT plutot que du MASQUERADING :

### règles INPUT
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # j'autorise en entrée les connexions établies et connexes
# iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # j'autorise l'echo-request
# iptables -A INPUT -p udp -m udp --dport 4444 -j ACCEPT # j'autorise la connexion vers OpenVPN
# iptables -A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable # et je rejette tout le reste sur l'interface eth0
### règles de NAT
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source mon.alias.ip.public

Désormais, si sur ma passerelle je plaçais une route par defaut sur 10.20.0.1 (le boût du tunnel sur le serveur dédié), les machines de mon réseau 192.168.1.0/24 apparaîtraient avec l’IP mon.alias.ip.public.
Cependant, seulement certaines machines, et surtout certains protocoles devront être soumis à cette politique, et c’est grâce à pf, et en particulier la directive route-to, que nous allons mettre en place ce routage conditionnel. Voici les lignes corresponsantes du fichier pf.conf de notre passerelle NetBSD :

int_if="xennet0"

[...]

pass in on $int_if route-to (tun0 10.20.0.1) proto tcp from 192.168.1.10 \
        to any port 80
pass in on $int_if route-to (tun0 10.20.0.1) proto udp from 192.168.1.10 \
        to any port > 10000

Décodage: Concernant le traffic qui arrive sur l’interface interne $int_if, toute demande en provenance de l’IP 192.168.1.10 à destination du protocole HTTP devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.
toute demande en provenance de l’IP 192.168.1.10 à destination de ports UDP supérieurs à 10000 devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.

J’utilise ce routage depuis hier soir, l’overhead du lien VPN est minimal et l’ensemble se comporte correctement. Je ne prétend pas, avec ce système, bénéficier d’un anonymat hors du commun, mais il me permet au moins de ne pas exposer mon IP publique.

SL10, c’est fini, et on va encore se faire plein d’amis !

Merci à llaumgui pour la photo ci-dessus et au mysterieux Monsieur J pour cette idée simplement géniale :)

C’est remarquable cette propension des petits lutins bleus de la nuit à aller bousiller les seules machines qui ne sont pas backupées, ils savent tout, ils voient tout, et ce sont de sacrés petits pervers de merde.

Hier matin, alors que je m’apprétais à faire le tour de mes mails avant de partir au boulot, je constate avec effroi que “je ne sors plus”. Comportement plus qu’étrange, ma passerelle récupère bien l’IP publique Free via DHCP, le ping passe quelques secondes, puis s’arrête, plus rien. Inévitablement, je commence à blâmer Free -bien qu’objectivement, je n’ai pas recontré de problèmes majeurs depuis des mois-, puis par acquis de conscience, teste le lien sur une machine differente. Ça passe.

Mon ancienne passerelle était un peu bancale, il faut l’avouer; il s’agissait d’une Sun Netra X1 gracieusement léguée par monsieur ange pendant Solutions Linux 2008, qui faisait tourner un OpenBSD 4.1 qui paniquait environ tous les trois mois.

Il ne m’en fallait pas plus pour plancher sur une nouvelle gateway, sous NetBSD cette fois. M’est alors apparu l’idée de faire fonctionner cette passerelle dans un domU, après tout, en bridgeant l’interface qui reçoit le réseau Free à une interface Xen, et de la même manière, en bridgeant l’interface raccordée à mon LAN, cela devrait fonctionner sans accroc: et bien c’est le cas.

Voici les fichiers impliqués dans ce mic-mac:

Sur le dom0, je déclare mes interfaces comme suit :

$ cat /etc/ifconfig.fxp0 # LAN
inet 192.168.0.10 netmask 255.255.255.0
$ cat /etc/ifconfig.fxp1 # Free
up

Puis je déclare des bridges sur ces interfaces :

$ cat /etc/ifconfig.bridge0 # LAN
create
!brconfig $int add fxp0 up
$ cat /etc/ifconfig.bridge1 # Free
create
!brconfig $int add fxp1 up

Ce qui nous donne, dans la configuration du domU :

$ cat /usr/pkg/etc/xen/exar
#kernel = "/home/imil/xen/netbsd-5.0.2-INSTALL_XEN3_DOMU.gz"
kernel = "/home/imil/xen/netbsd-5.0.2-XEN3_DOMU-pf.gz"
memory = 256
name = "exar"
vcpus = 1
disk = [ 'file:/home/imil/xen/exar.img,0x03,w' ]
disk += [ 'file:/home/imil/iso/amd64cd-5.0.2.iso,0x04,r' ]
vif = [ 'bridge=bridge0' ]
vif += [ 'bridge=bridge1' ]
bootdev = "/dev/xbd0a"

Notez le nom du noyau qui sert à faire booter cette VM, netbsd-5.0.2-XEN3_DOMU-pf.gz. En effet, un modload /usr/lkm/pf.o fait misérablement crasher le domU, il est donc nécessaire de se fendre d’une recompilation du noyau domU en incluant à la configuration :

pseudo-device   pf                      # PF packet filter
pseudo-device   pflog                   # PF log if

Sur le domU-passerelle, on constate la présence des deux interfaces :

$ ifconfig -a
xennet0: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]
xennet1: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]

Leur configuration est triviale :

exar$ cat /etc/ifconfig.xennet0 # LAN
inet 192.168.0.254 netmask 255.255.255.0
exar$ cat /etc/ifconfig.xennet1 # Free
up
!dhclient $int

Et voila !

On active le NAT gràce à pf :

ext_if="xennet1"
int_if="xennet0"

nat on $ext_if from !($ext_if) -> ($ext_if:0)

Et me voila à nouveau en mesure de raconter ma vie trépidante sur l’Intarwebz.

Dernière étape de la migration des services de l’ancien iMil.net vers son nouveau foyer: icecast.

Alors que je me préparais à l’enfermer dans un chroot comme quelques-uns de ses petits camarades, je me suis souvenu que icecast supportait déjà cette fonction. Sa configuration est une promenade de santé.

Après l’avoir installé via un bête pkgin in icecast-2, l’édition de son fichier de configuration, si l’on fait abstraction de cette saloperie de format XML, est assez rapide, voici les sections qu’il vous faudra renseigner dans le fichier /usr/pkg/etc/icecast/icecast.xml afin de rapidement diffuser du son sur l’intarwebz :

[...]
    <authentication>
        <!-- Sources log in with username 'source' -->
        <source -password>motdepassecomplique</source>
        <!-- Relays log in username 'relay' -->
        <relay -password>motdepassecomplique</relay>

        <!-- Admin logs in with the username given below -->
        <admin -user>admin</admin>
        <admin -password>motdepasseencorepluscomplique</admin>
    </authentication>
[...]
    <hostname>ta.radio.quidemonte.net</hostname>
[...]
    <paths>
                <!-- basedir is only used if chroot is enabled -->
        <basedir>/var/chroot/icecast</basedir>
        <!-- Note that if <chroot> is turned on below, these paths must both
             be relative to the new root, not the original root -->
        <logdir>log/</logdir>
        <webroot>web/</webroot>
        <adminroot>admin/</adminroot>
        <pidfile>/var/chroot/icecast/icecast.pid</pidfile>
[...]
    <security>
        <chroot>1</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>

</paths>

On notera que la directive chroot est à 1 et que les path sont relatifs au chroot, ce qui nous donne /var/chroot/icecast/{web,log,admin}. Il sera enfin nécessaire de copier le contenu des repertoires /usr/pkg/share/icecast/{web,admin} dans leurs équivalents chrootés, puis de configurer le démarrage automatique d’icecast :

# cp /usr/pkg/share/examples/rc.d/icecast /etc/rc.d/
# echo "icecast=YES" >> /etc/rc.conf
# /etc/rc.d/icecast start

À toutes fins utiles, je colle ici la configuration du client ices2, qui permet le streaming effectif d’une source audio :

$ cat etc/ices2.xml
< ?xml version="1.0"?>
<ices>

    <!-- run in background  -->
    <background>0</background>
    <!-- where logs go. -->
    <logpath>/var/log/ices</logpath>
    <logfile>ices.log</logfile>
    <!-- size in kilobytes -->
    <logsize>2048</logsize>
    <!-- 1=error, 2=warn, 3=infoa ,4=debug -->
    <loglevel>4</loglevel>
    <!-- logfile is ignored if this is set to 1 -->
    <consolelog>0</consolelog>

    <!-- optional filename to write process id to -->
    <!-- <pidfile>/home/ices/ices.pid -->

    <stream>
        <!-- metadata used for stream listing -->
        <metadata>
            <name>Du bon SON</name>
            <genre>Du qui tape</genre>
            <description>Du qui fait que tu put tes hands in the air</description>
            <url>http://ta.radio.quidemonte.net:8000</url>
        </metadata>

        <!--    Input module.

            This example uses the 'oss' module. It takes input from the
            OSS audio device (e.g. line-in), and processes it for live
            encoding.  -->
        <input />
            <module>alsa</module>
            <param name="rate">48000</param>
            <param name="channels">2</param>
            <param name="device">hw:0,0</param>
            <!-- Read metadata (from stdin by default, or -->
            <!-- filename defined below (if the latter, only on SIGUSR1) -->
            <param name="metadata">1</param>
            <param name="metadatafilename">test</param>

        <!--    Stream instance.

            You may have one or more instances here.  This allows you to
            send the same input data to one or more servers (or to different
            mountpoints on the same server). Each of them can have different
            parameters. This is primarily useful for a) relaying to multiple
            independent servers, and b) encoding/reencoding to multiple
            bitrates.

            If one instance fails (for example, the associated server goes
            down, etc), the others will continue to function correctly.
            This example defines a single instance doing live encoding at
            low bitrate.  -->

        <instance>
            <!--    Server details.

                You define hostname and port for the server here, along
                with the source password and mountpoint.  -->

            <hostname>ta.radio.quidemonte.net</hostname>
            <port>8000</port>
            <password>motdepassecomplique</password>
            <mount>/jumpjump.ogg</mount>
            <yp>0</yp>   <!-- allow stream to be advertised on YP, default 0 -->

            <!--    Live encoding/reencoding:

                channels and samplerate currently MUST match the channels
                and samplerate given in the parameters to the oss input
                module above or the remsaple/downmix section below.  -->

            <encode>
                <quality>0</quality>
                <samplerate>48000</samplerate>
                <channels>2</channels>
            </encode>

            <!-- stereo->mono downmixing, enabled by setting this to 1 -->
            <downmix>0</downmix>

            <!-- resampling.

                Set to the frequency (in Hz) you wish to resample to, -->

            <!--resample>
                <in -rate>44100</in>
                <out -rate>44100</out>
            </resample -->
        </instance>

    </stream>
</ices>

Et voila ! Ton petit monde peut désormais écouter tes exploits sur http://ta.radio.quidemonte.net:8000/jumpjump.ogg

Je rappelle également que dans 2 semaines, c’est la Miami Winter Conference 2010, que c’est le 25ème anniversaire de cette grand messe, et qu’ILS y seront.

Ça y est. Enfin. Ça va recommencer.

Contre toute attente, la migration de mon IPBX perso a été parfaitement sans douleur. Après l’installation de la toute dernière version d’Asterisk sur mon domU NetBSD à l’aide de pkgin (puisqu’aucune option particulière ne m’était nécessaire), je me suis souvenu d’un article que j’avais initialement écrit sur le site Freephonie.org, dans lequel j’expliquais les diverses manipulations pour monter un Asterisk fonctionnel derrière du NAT.
Comme souvent, l’article a été peaufiné par quelques contributeurs, et son contenu est tout à fait valide pour la configuration d’un Asterisk 1.6.

Ainsi, mon dom0 GNU/Linux possède les règles suivantes :

# on accepte le traffic SIP et une plage destinée au RTP
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 10000:10100 -j ACCEPT
# On accepte le forward pour ces memes ports vers le domU qui accueille le PBX
-A FORWARD -d 10.20.30.1/32 -i eth0 -p udp -m udp --dport 5060 -j ACCEPT
-A FORWARD -d 10.20.30.1/32 -i eth0 -p udp -m udp --dport 10000:10100 -j ACCEPT
# On reroute le traffic vers ces ports sur le domU adéquat
-A PREROUTING -i eth0 -p udp -m udp --dport 5060 -j DNAT --to-destination 10.20.30.1
-A PREROUTING -i eth0 -p udp -m udp --dport 10000:10100 -j DNAT --to-destination 10.20.30.1

Sur le domU en question, ma configuration n’a guère changé, si ce n’est que j’ai réduit le pool de ports RTP dans le fichier rtp.conf :

; ces ports correspondent aux ports reroutés par iptables sur le dom0
rtpstart=10000
rtpend=10100

Le reste de la configuration est strictement identique à la documentation visible sur Freephonie.org.
Notez qu’afin de pouvoir débugger tranquillement avec votre utilisateur, grace à la commande asterisk -r, et pour pouvoir éditer les fichiers de configuration d’Asterisk sans peine, pensez à vous ajouter au groupe “asterisk”, autoriser l’ecriture pour le groupe dans /usr/pkg/etc/asterisk, et modifier les champs suivants dans le fichier asterisk.conf :

runuser = asterisk ; The user to run as
rungroup = asterisk ; The group to run as

[files]
astctlpermissions = 0660
astctlowner = asterisk
astctlgroup = asterisk
astctl = asterisk.ctl

Et enfin: “Allo Bob ? c’est Paul !”