Employons le bon vocabulaire

Le hollandais volant a publié un billet que je vous conseille de lire : Je ne suis pas Geek. Je vous conseille également de lire les commentaires de ce billet. Il était temps de rétablir certaines vérités.

C'est quand même regrettable de constater que seuls les passionnés d'informatiques sont perçus comme des fous asociales ou pire, comme des monstres. Exemples.

J'ai dans mon entourage un grand passionné de mécanique. La rapidité avec laquelle il vous diagnostic une panne, vous change une pièce ainsi que l'étendue de ses connaissances dans ce domaine m'ont toujours bluffés. Il a réellement le contrôle de sa voiture, largement plus que la masse que nous sommes. Il passe plus de temps dans ses garages que moi devant mon écran ... et il est bien vu.

Encore plus proche de moi, j'ai un couple passionné par le jardinage. A eux d'eux, ils forment une vraie encyclopédie des fleurs et des arbres. Là aussi, ils passent un temps monstrueux dans leur jardin et une somme d'argent conséquente dans les magasins dédiés. Et là encore, ils sont bien vu.

Pourquoi considérer que seul le passionné d'informatique est un déviant alors que les accrocs de jardinage/mécanique/que sais-je encore sont considérés comme des gens tout à fait normaux, ayant une passion respectable, alors que tous consacrent un même temps monstrueux à leur passion ?

Ceci étant dit, je vous conseille également la lecture d'un paragraphe sur Wikipédia : Confusions au sujet des geeks. Celui-ci vous permettra d'apprendre ou de revoir les différences entre un geek, un no-life, un nerd et un technophile et vous évitera de dire des âneries et de traiter n'importe qui de n'importe quoi, sans savoir.

Ensuite, il faut savoir compter correctement le temps qu'une personne voue à sa passion avant de l'attaquer sur ce sujet. Pour illustrer cela, comparons deux personnes.

La première personne rentre chez elle le soir et utilise son ordinateur pour surfer sur internet et discuter avec ses amis via la messagerie instantanée. Cette personne regarde ensuite le journal télévisé grâce à sa télévision. Elle écoute ensuite l'album d'un chanteur sur sa chaîne hi-fi. Elle poursuit sa soirée en regardant un DVD (old-school !) grâce à sa télévision et à son lecteur de DVD.

La deuxième personne rentre chez elle le soir et utilise son ordinateur pour surfer sur internet et discuter avec ses amis via la messagerie instantanée. Cette personne regarde ensuite le journal télévisé grâce à son ordinateur, qu'elle a équipé d'une carte TV. Elle écoute ensuite l'album d'un chanteur, grâce à son ordinateur, qu'elle a équipé d'une carte son haute de gamme et des enceintes adaptées. Elle poursuit sa soirée en regardant un DVD grâce à son ordinateur qui est équipé d'un lecteur de DVD.

Conclusion : la deuxième personne donne l'illusion de passer son temps devant un ordinateur. Pourtant, nos deux personnes ont fait strictement les mêmes activités. Seulement, la deuxième personne est fan de la convergence numérique. Elle pense que rien n'est plus paramétrable qu'un ordinateur, que celui-ci lui offre un plein contrôle de ses activités. De plus, la fusion de la télévision, du lecteur DVD et de la chaine hi-fi, lui permet de gagner de la place dans sa maison. Elle a donc des arguments sensés ... mais va être perçue, par la société, comme une débile qui passe son temps devant un ordinateur.

Dernière chose : il vaut mieux parfois avoir une passion dévorante, s'occuper, plutôt que de rester planter là, à longueur de journée, à s'ennuyer sans oser se l'avouer et à attaquer ceux qui font quelque chose de leur vie, même si ça paraît excessif. A bon entendeur ...

Il est peut-être temps d'appeler un chat, un chat et un chien, un chien. Il est peut-être temps, aussi, de changer certaines mentalités ...

SSH, redirection dynamique, proxychains et DNS

Table des matières

Ce billet fait suite à celui-ci : SSH : du port forwarding au VPN bon marché. J'y évoquais les problématiques de fuite des requêtes de résolution de nom via le protocole DNS. Mais je n'ai pas abordé un point sur lequel je m'interroge depuis quelques temps : je me demandais si les requêtes de résolution étaient envoyées au résolveur DNS défini dans le fichier /etc/resolv.conf du client SSH ou à celui défini dans le fichier du serveur SSH. Il paraît presque évident que c'est le résolveur définit sur le serveur qui sera utilisé.

Ayant sévèrement planté mon WRT54GL, j'en ai profité pour le flasher avec la déclinaison brcm2.4 d'OpenWRT. Cette déclinaison étant plus compact, j'ai pu installer tcpdump sur mon routeur et vérifier tout ceci.

Pourquoi ce test ?

Si votre ordinateur reçoit automatiquement l'adresse IP du résolveur DNS par le serveur DHCP du réseau insecure, que ce résolveur fait partit du réseau insecure et en admettant que les requêtes DNS sont envoyées à ce résolveur via votre serveur SSH, alors l'administrateur réseau du réseau insecure pourra faire un croisement entre l'adresse IP qui effectue les résolutions DNS sur le résolveur DNS interne (qui sera celle de votre serveur SSH) et l'adresse IP de destination du trafic SSH (là aussi, ce sera celle de votre serveur). Il pourra donc savoir quels noms de domaine vous avez résolus et par voie de conséquence, ce que vous avez fait sur internet. La redirection dynamique via SSH serait donc moins efficace. Comme déjà dit, il est peu probable que les résolutions de noms se fasse via le résolveur défini dans le fichier /etc/resolv.conf du client, mais cela ne coute rien de s'en assurer.

Mise en place du test

Évidemment, ce test ne sera pas effectué depuis un réseau dont vous n'avez pas confiance ...

D'abord, on installe tcpdump sur le WRT54GL :

opkg update
opkg install tcpdump

Sur la machine de test, on prépare un tsark/wireshark/tcpdump et un Firefox avec un proxy défini dans les paramètres et l'option network.proxy.socks_remote_dns à true dans le about:config.

Note : il n'est pas nécessaire de faire une capture du trafic réseau sur la machine de test si on est déjà convaincu que le trafic passera bien par le tunnel SSH. Je propose ici de faire une capture afin que les septiques puissent vérifier par eux-mêmes ce que je disais dans le billet sus-cité.

Ensuite, on définie un résolveur DNS différent sur le routeur et sur la machine.
Disons que sur la machine, nous utiliserons le résolveur d'OpenDNS : "nameserver 208.67.222.222" à mettre dans le fichier /etc/resolv.conf.
Disons que sur le routeur nous utiliserons le résolveur de Google : "nameserver 8.8.8.8" à mettre dans le fichier /etc/resolv.conf.

On redémarre ensuite dropbear (ou autre serveur SSH) sur le routeur :

/etc/init.d/dropbear/restart

On se déconnecte puis reconnecte au routeur via SSH, en activant la redirection dynamique.

On lance la capture, que nous appellerons capture R par la suite, sur le routeur (voici un tutoriel pour tcpdump):

tcpdump -i eth0.1 not port 22 -s0 -w capture.cap

Explication : tcpdump écoute sur l'interface wan (eth0.1), ne garde pas les messages correspondant à la session SSH, ne tronque pas les paquets et enregistre le trafic dans le fichier capture.cap.

On lance la capture, que nous appellerons capture M par la suite, sur la machine.

Dans Firefox, tentez d'accéder à n'importe quel site, de préférence un site sur lequel vous n'avez pas l'habitude d'aller.

On récupère la capture :

scp root@routeur:/root/capture.cap .

On analyse la capture avec Wireshark (vous pouvez bien sur le faire avec tsark/tcpdump. Dans ce cas là, inutile de rapatrier la capture sur votre machine) :

wireshark capture.cap

Résultat attendu

Capture M ne doit contenir que du trafic SSH et TCP (ack). Capture R doit contenir du trafic HTTP, TCP (ack) et du trafic DNS vers 8.8.8.8 et surtout pas vers 208.67.222.222.

Résultat obtenu

Exactement le résultat attendu. Firefox dirige les requêtes DNS vers le résolveur défini dans le fichier /etc/resolv.conf du serveur SSH au moment où le serveur SSH a été lancé sur la machine (d'où l'intérêt d'avoir redémarré le serveur SSH lors de la mise en place du test).

Le cas proxychains

Pour les applications ne prenant nativement pas en charge les proxy SOCKS et/ou le transfert des requêtes DNS vers ce proxy, il est, comme nous l'avons dit dans l'article sus-cité, nécessaire de faire appel à un wrapper SOCKS (proxychains, tsocks, torsocks, etc.). Le comportement envers les requêtes DNS dépendra du wrapper choisit.

Dans le cas de proxychains, les requêtes sont toutes envoyées au même résolveur : 4.2.2.2.

Vous pensez bien que je trouve cela intolérable : si j'ai installé un résolveur DNS sur mon WRT54GL, c'est pour l'utiliser (pour les raisons évoquées dans l'article linké).

Je me suis donc dis que ce résolveur devait bien être défini dans les sources de proxychains. J'avais dans l'idée de recompiler les sources après avoir changé l'adresse du résolveur utilisé.

J'ai donc téléchargé et décompressé les sources :

wget http://downloads.sourceforge.net/project/proxychains/proxychains/version%203.1/proxychains-3.1.tar.gz?r=&ts=1294602235&use_mirror=mesh
tar -xf proxychains-3.1.tar.gz

On cherche ensuite l'occurrence "4.2.2.2" dans les sources :

cd proxychains-3.1
find ./ -type f -exec bash -c "grep "4.2.2.2" {} && echo {}" \;

Find/grep trouvent un résultat dans le fichier ./proxychains/proxyresolv. On affiche son contenu :

cat ./proxychains/proxyresolv

Je vous quote le passage intéressant en vous invitant quand même à lire la suite du fichier qui est intéressante puisqu'elle permet de comprendre que proxychains résout les noms de domaine avec une méthode toute simple qui fait plaisir à voir :

#!/bin/sh
# This script is called by proxychains to resolve DNS names
 
# DNS server used to resolve names
DNS_SERVER=4.2.2.2

Tout devient clair : proxychains se sert de ce script shell pour résoudre les noms de domaine. Il doit suffire de changer le contenu de la variable DNS_SERVER pour changer de résolveur.

On se dit que ce script ne sera pas compilé et donc qu'il doit y en avoir un exemplaire sur notre machine qui sert au proxychains installé :

sudo find / -type f -name "proxyresolv"

Find nous trouve un résultat : /usr/lib/proxychains3/proxyresolv.

On modifie donc ce fichier en remplaçant 4.2.2.2 par l'adresse du résolveur DNS voulu. Pour ma part, ça sera le résolveur installé sur mon routeur donc 192.168.1.1 (adresse lan par défaut).

On refait ensuite le test effectué précédemment sauf qu'au lieu d'utiliser Firefox, on utilise un programme proxychainé ("proxychains programme").

On voit, dans la capture réseau de R, que c'est bien le résolveur déclaré dans le script /usr/lib/proxychains3/proxyresolv qui est utilisé. Pour ceux qui veulent une preuve de plus : pour peu que vous ayez lancé la commande depuis une console, vous pouvez lire quelquechose comme ça :

|S-chain|-<>-127.0.0.1:6666-<><>-192.168.1.1:53-<><>-OK"

Piwik 1.1.1

Je profite de ce premier billet de l'année pour vous souhaiter une bonne année 2011 et surtout une bonne santé.

Passons maintenant aux choses sérieuses. J'utilise Piwik depuis bientôt un an et j'en suis satisfait. Récement, la version 1.1 puis la 1.1.1 ont fait leur apparition. La 1.1 apporte son lot de bugs corrigés, de nouvelles fonctionnalités ainsi que son lot de failles de sécurité corrigées. La version 1.1.1 corrige également quelques bugs.

D'habitude, les mises à jour se font sans soucis, c'est pour cela que je n'écris jamais de billet à ce sujet. Mais cette fois-ci, j'ai eu le droit à tout les problèmes.

Après une mise à jour manuelle de la version 1.0 vers la version 1.1.1, je ne peux plus me connecter. Le titre de la page est correcte, du HTML est visible dans la source de la page mais rien ne s'affiche. Ce problème est connu mais la solution proposée ne fonctionne pas (en même temps, je n'utilise pas de reverse proxy ...). J'ai également vidé le cache de mon navigateur et supprimé les cookies, comme conseillé un peu partout, mais sans succès.

Je décide donc d'installer une version saine et complète (comprendre que ma version de production est optimisée : j'enlève un certains nombres de plugins que je juge inutiles pour mon usage, nous y reviendrons) en parallèle à ma version 1.0 de production. Cette fois-ci, la connexion fonctionne.

EDIT 06/01 23h55 : Je viens de trouver une solution à ce premier "problème" : il faut activer le javascript dans votre navigateur. Si vous utilisez une extension/widget dans le genre de NoScript, pensez à autoriser le javascript sur votre page d'authentification Piwik. Sans javascript, pas d'affichage. Lors de l'installation d'une version saine et complète, j'ai du activer le javascript sur le domaine de test, ce qui explique pourquoi le formulaire est apparu.

Mais, un deuxième problème arrive alors : je me retrouve avec des pages de texte, comme si il manquait le CSS ou les images associées et ce, sur toutes les pages. Je vérifie mon client FTP : tous les fichiers ont pourtant bien été transférés. Je regarde rapidement sur internet : un problème similaire est connu. Je tente encore une fois de vider le cache de mon navigateur et de supprimer les cookies, sans plus de succès. Le patch proposé dans le lien donné ci-dessus est sans effet : la modification était déjà effectuée dans le latest.zip que j'ai téléchargé.

Je décide de prendre la dernière révision disponible (la 3645, qui correspond a la version 1.1.2b1) sur le SVN du projet :

sudo apt-get install subversion
mkdir piwik-svn
cd piwik-svn
svn checkout http://dev.piwik.org/svn/trunk

find ./ -type d -name .svn -exec rm -rf {} \;
rm -rf ./trunk/tests

"find ./ -name ".svn" -exec rm -rf {} \;" permet de supprimer les dossiers cachés créés par subversion qui ne serviront pas. Ne tenez pas compte des messages d'erreur "Aucun fichier ou dossier de ce type" car les dossiers seront quand même supprimés.

"rm -rf ./trunk/tests" permet de supprimer le dossier "tests" qui ne sert pas non plus.

Ensuite, vous pouvez supprimer les plugins que vous ne comptez pas utiliser. A titre d'information, je supprime :

  • AnonymizeIP
  • DBStats
  • ExampleAPI
  • ExampleFeedburner
  • ExamplePlugin
  • ExampleRssWidget
  • Feedback
  • Goals
  • Live
  • MultiSites
  • PDFReports
  • SecurityInfo (à utiliser quand même une fois avant de le supprimer)
  • UserCountryMap
  • VisitorGenerator
  • Widgetize

Penser à adapter vos fichiers global.ini.php et config.ini.php : enlevez les lignes "Plugins[] = xxxxxxxx", et/ou "PluginsInstalled[] = xxxxxxxx" et/ou "Plugins_Tracker[] = xxxxxxxx" qui correspondent à des plugins que vous avez supprimés. Si vous sautez cette étape, vous obtiendrez des messages d'erreurs explicites.

Il ne vous reste plus qu'à uploader le contenu du dossier trunk sur votre serveur web et à installer Piwik en suivant l'assistant, comme lors de la première fois.

Pour la base de données, ne vous inquiétez pas : Piwik verra que les tables existent déjà et vous demandera si vous voulez les utiliser ou si vous voulez les effacer. En choisissant de les réutiliser, vous conservez vos stats.

EDIT 06/01 23h55 : Pour le premier problème et en attendant une solution officielle, une solution est donnée plus haut. Pour le deuxième problème, il semble avoir été corrigé dans la révision 3645 (et donc dans la version 1.1.2b1) puisque je ne l'ai pas rencontré de nouveau.