Comme je l’évoquais brièvement dans un précédent article, les serveurs de l’entreprise de média en ligne Gawker ont été piratés récemment, avec pour conséquence immédiate la diffusion au public des logins, emails, et mots de passe chiffrés de plus d’un million d’utilisateurs. Pour plusieurs centaines de milliers d’entre eux, les mots de passe avaient même été déchiffrés avant leur diffusion.
Pour quelqu’un comme moi les dessous de l’affaire sont croustillants, et les détails techniques sont même passionnants. Mais, plus important : tout le monde a une leçon à tirer de ce fiasco monumental.
Cette leçon, et non des moindres, est la suivante : dès l’instant où vous confiez un mot de passe à quelqu’un, ce mot de passe est vulnérable. Ça paraît tout bête comme ça, on se dit “mais oui, c’est sûr qu’en donnant mon mot de passe à mon voisin, alors il n’est plus secret”. Non. Relisez bien la leçon, elle est à prendre au premier degré. Oubliez votre voisin, votre copine. Vous créez un compte chez Hotmail, vous choisissez un mot de passe pour pouvoir accéder plus tard à votre boîte mail, vous fournissez ce mot de passe à Hotmail. Ça y est, ce mot de passe n’est plus sûr. Un jour, c’est inévitable, c’est déjà arrivé, et ça arrivera à nouveau, des serveurs Hotmail seront piratés et votre mot de passe pourrait tomber dans les mains de quelqu’un.
L’affaire Gawker est bourrée d’exemples illustrants parfaitement ce principe. Les employés de chez Gawker s’échangeaient des mots de passe par chat, dont les archives des conversations ont été piratées. Le piratage des bases de données des sites de Gawker a montré que les mots de passe des utilisateurs n’étaient pas sécurisés : le chiffrement utilisé était archaïque et connu depuis des années pour être déficient, etc. etc.
Continue reading
Archives
De la sécurité de vos mots de passe
En terme de mot de passe, on nous rebat souvent les oreilles avec des recommandations sécuritaires qui tombent sous le sens. Par contre, les arguments qui sous-tendent ces recommandations sont parfois largement infondés.
Tout d’abord, on nous dit de ne pas choisir un mot de passe facile à deviner, c’est bien sûr du bon sens. On nous dit que le mot de passe doit être long, car les ordinateurs actuels permettent de tester des milliers de mots de passe par seconde. Plus le mot de passe est long, plus il sera long à trouver. Certes. C’est mathématiquement exact. Mais à quoi arrive-t-on si on force les gens à utiliser un mot de passe à la fois long et compliqué ? Ils vont utiliser le même mot de passe partout, ils vont le noter quelque part, etc.
Imaginons un instant qu’un pirate tente de deviner votre mot de passe de messagerie. Il a une très bonne connexion internet, et son ping (le délai qui s’écoule entre le moment où il envoie une requête au serveur, et le moment où le serveur dit qu’il a bien reçu cette requête) est de 10 millisecondes. Il faut ajouter à cela le temps de traitement sur le serveur, et l’envoi de la réponse. Mettons pour simplifier que la totalité de la transaction dure 20 ms. Si votre mot de passe de messagerie fait 8 caractères différents et qu’il utilise des lettres minuscules (26 possibilités), des lettres majuscules (26 possibilités), et des chiffres (10 possibilités), c’est probablement assez correct. Ce mot de passe utilise donc 8 caractères différents pris dans une série de 62. Soit un total de 136325,9 milliards de mots de passe possibles. À raison d’un mot de passe testé toutes les 20 ms, cela donne plus de 864 siècles, pour tester tous les mots de passe.
Maintenant, ajoutez des caractères parmi @#&”‘(§!)-_$*/:;.,?+ (20 possibilités), et il faudra presque 9114 siècles pour tester tous les mots de passe.
Moralité, la puissance des ordinateurs permet effectivement de tester des millions de mots de passe par heure, mais la latence des connexions internet rend ce mode d’attaque quasiment impossible, car elle ralentit terriblement le processus.
Continue reading
Installer un serveur dédié “Source” sur FreeBSD 8
Source Dedicated Server, le serveur de jeu dédié de Valve pour Team Fortress, Left 4 Dead et Counter Strike (entre autres), est un logiciel Linux ou Windows, propriétaire. Donc les choses ne se présentent pas forcément très bien pour une installation sur FreeBSD. Cependant, il n’y a pas beaucoup d’efforts à faire pour installer et faire fonctionner ce logiciel grace à la compatibilité Linux de FreeBSD.
Dans un premier temps il faut activer, si ce n’est déjà fait, la compatibilité Linux dans le noyau de FreeBSD :
# chargement manuel du module kldload /boot/kernel/linux.ko # activation du chargement automatique au démarrage echo 'linux_enable="YES"' >> /etc/rc.conf
Ensuite (et pas avant), on peut installer les librairies Linux. Pour FreeBSD 8, il faut installer la version f10 :
portinstall -PP linux_base-f10
Attention, si vous êtes en FreeBSD 64 bits (amd64), le package refusera de s’installer, il faudra alors utiliser :
portinstall linux_base-f10
On termine de préparer l’environnement de compatibilité Linux en montant le système de fichier procfs. Il faut ajouter la ligne suivante au fichier /etc/fstab
linproc /compat/linux/proc linprocfs rw 0 0
puis faire un
mount -a
Enfin, on peut installer le client steam :
portinstall linux-steam
En réalité, c’est seulement un logiciel de mise à jour du client steam qui est installé, il faut lancer la mise à jour pour que la vraie commande steam soit installée. Je fais cette étape deux fois :
cd /usr/local/steam/ ./steam # on attend la fin de l'exécution # puis on recommence ./steam
Le binaire steam est maintenant installé, à jour, et totalement fonctionnel. Via ce client, il est possible d’installer n’importe quel jeu compatible. Voilà comment procéder pour installer Left 4 Dead 2 :
./steam -command update -game left4dead2 -dir /chemin/du/jeu
On remplacera /chemin/du/jeu par le chemin du répertoire dans le quel on souhaite stocker les fichiers du jeu. Attention, pour Left 4 Dead 2 il y a environ 8 Go à télécharger. Si vous êtes sur de l’UFS, c’est donc 8 Go de stockage qui seront consommés. Si vous êtes sur un volume ZFS avec compression GZip, il faut compter environ 4,2 Go d’espace disque consommé. Le téléchargement est assez long, faites une pause, voire même, lancez la commande avant d’aller vous coucher.
Après cela, le répertoire /chemin/du/jeu contiendra un répertoire left4dead2. Dans ce dernier se trouve un script de lancement qui permet de démarrer le serveur dédié Source : srcds_run.
Voici un exemple de lancement :
cd /chemin/du/jeu/left4dead2 ./srcds_run -ip 192.168.1.1 +sv_lan 1
L’option -ip permet d’imposer l’IP sur la quelle le serveur écoute. C’est très utile car le script est d’une bêtise monumentale. En effet, pour une raison que j’ignore, le serveur dédié se lance par défaut en utilisant la toute première IP configurée dans le fichier /etc/rc.conf même si la ligne est commentée !
C’est à dire que si votre rc.conf contient les lignes suivantes :
#ifconfig_em0="inet 192.168.128.201 netmask 255.255.255.0" ifconfig_em0="inet 193.30.227.216 netmask 255.255.255.192"
et bien cet abruti de serveur tente de se lancer sur l’IP 192.168.128.201, alors que, bien sûr, l’IP n’est pas active. Épargnez votre santé mentale, imposez dès le départ une IP à srcds.
L’option +sv_lan 1 quant à elle impose un fonctionnement sur le LAN uniquement, ce qui permet aisément de tester le fonctionnement du serveur sans l’ouvrir sur le monde.
Vous devrez veiller à quelques points de détail :
- le firewall doit autoriser les connexions TCP et UDP sur les ports 26901 et 27015.
- le jeu peut (doit) être lancé avec un utilisateur non privilégié. Créez un compte pour l’occasion, avec un shell
/bin/nologin, et toute autre mesure de protection que vous jugerez nécessaire.
Attention, faire tourner le jeu avec un utilisateur non privilégié n’est pas forcément très simple, surtout si vous l’avez installé en root. J’ai découvert que lancer le jeu une première fois en root peut régler certains problèmes. - l’utilisateur en question devra notamment pouvoir écrire dans les répertoires
/chemin/du/jeu/left4dead2/update,/chemin/du/jeu/left4dead2/left4dead2et/chemin/du/jeu/left4dead2/left4dead2/{downloads,logs}et dans les fichiers/chemin/du/jeu/left4dead2/left4dead2/*.cache - il devra aussi pouvoir exécuter les fichiers
/chemin/du/jeu/left4dead2/srcds_run/chemin/du/jeu/left4dead2/srcds_linux
Pour un utilisateur non privilégié, en “nologin”, le moyen fiable de lancer le serveur est d’utiliser sudo, dans un screen pour être tranquille :
cd /chemin/du/jeu/left4dead2/ screen nice -n -5 sudo -u utilisateur_steam ./srcds_run -ip 192.168.1.1
Avec tout ceci, votre serveur doit être fonctionnel, et permet déjà de jouer. Le plus dur reste à faire, puisque de toute l’histoire de l’informatique, ce sont les serveurs de jeu qui détiennent la triste palme des logiciels les moins bien documentés au monde. Créez un fichier /chemin/du/jeu/left4dead2/left4dead2/cfg/server.cfg et testez des combinaisons jusqu’à obtenir le résultat souhaité.
Capture et analyse distante avec Wireshark
Wireshark est un outil sympathique, quand vient le moment d’analyser ce qui passe sur un réseau, qui fait quoi, quel protocole prend toute votre bande passante, etc. Malheureusement, la machine sur la quelle on voudrait faire l’analyse n’est pas toujours celle sur la quelle vous pouvez lancer le logiciel.
Il est possible facilement de capturer les paquets voulus sur une machine, et de les analyser à postériori sur une autre. Par contre, effectuer une analyse en direct et à distance nécessite d’utiliser quelques astuces.
Avant d’aller plus loin dans les explications, voici quelques pré-requis :
- Vous devez installer Wireshark sur votre machine (A)
- Vous devez aussi pouvoir vous connecter en root via SSH sur la machine que vous voulez utiliser pour la capture (B)
Dans un premier temps, il s’agit de créer un socket UNIX via mkfifo. C’est ce socket que votre Wireshark va lire en local sur la machine A.
mkfifo capture.fifo
Dans un deuxième temps, il faut ouvrir une connexion SSH de A vers B, lancer tcpdump dans cette connexion, et rediriger la sortie standard dans votre tout nouveau socket.
ssh root@machineB tcpdump -s 0 -U -n -w - -i ath0 > capture.fifo
Remplacez ath0 par le nom de l’interface réseau qui vous intéresse, et éventuellement, ajoutez aux options de tcpdump les filtres adéquats pour affiner votre analyse.
Attention, pour une connexion avec mot de passe, ssh ne vous demandera le fameux sésame qu’au moment où Wireshark ouvrira le socket. C’est à dire à l’étape suivante.
Dans un troisième et dernier temps, vous pouvez lancer Wireshark sur la machine A si ce n’est déjà fait, et le configurer pour lire votre socket capture.fifo. Pour cela, ouvrez les options de capture, et saisissez le chemin de votre socket dans le champ “interface” :
Enfin, cliquez sur “Start” pour lancer la capture, et si nécessaire, tapez votre mot de passe pour la machine B dans la fenêtre de terminal où votre connexion SSH est établie.
Concours photo “La Vie en Rose”
C’est malheureux à dire, mais une fois de plus je constate que le plaisir du plus grand nombre est gâché par la bêtise d’une minorité. Finalement ce n’est rien d’autre qu’une vraie constante de la nature humaine qui se vérifie aujourd’hui avec le concours photo “La Vie en Rose” organisé dans le cadre de la biennale de la danse.
Le but du jeu est simple : chaque personne peut envoyer jusqu’à trois photos, prises pendant le défilé de la biennale, et illustrant le thème de “la vie en rose”. Chaque visiteur (adresse IP) peut voter une fois par jour pour sa photo favorite.
Les organisateurs ont eu en plus la bonne idée de ne pas afficher toutes les photos à chaque visiteur. Ainsi, avant d’avoir voter, vous pouvez visionner un peu plus de 30 pages de 8 photos chacune sélectionnées au hasard dans la masse de photos des candidats, et présentées dans un ordre aléatoire. Vous pouvez alors voter pour un seul cliché. Après votre vote, vous pouvez visionner, si le cœur vous en dit, plus de 140 pages de photos, classées par ordre de nombre de votes.
Quelques utilisateurs sont tout de même parvenus à pervertir ce système de vote. Ce n’était pas bien compliqué, c’est certain, mais était-ce bien nécessaire ? Ils ont localisé dans le code HTML une adresse qui permet de voter pour une photo donnée sans l’étape laborieuse du visionnage. Ils ont alors sans aucun doute transmis l’URL adéquate à leurs “amis” de facebook, et c’est ainsi que la plupart des photos en tête de classement sont à la fois totalement hors sujet et complètement inintéressantes. On en voit même certaines gagner plus de 200 votes en quelques minutes. Le pire, c’est qu’il est même techniquement possible de faire voter les gens pour une photo précise à leur insu.
Je ne suis pas surpris que des types pas drôles et sans grande morale se livrent à ce genre de sport. Je suis juste un peu écœuré pour les participants honnêtes, dont les photos sont parfois très jolies et pertinentes, car ils ne seront pas récompensés.
Comment peut on encore participer de bonne foi à ce genre de concours, si on sait que de toute manière seuls les plus roublards, les plus tricheurs, les moins finauds gagneront ?
crédit photo : Thomas Gasparetto
edit : le règlement du concours a été mis à jour, le choix des gagnants sera fait par un jury. Voilà qui est une bonne nouvelle (et qui ne me laisse aucune chance ;) )
Quelques nouveautés
En ce début d’année (scolaire, puisque dans l’éducation nationale on fonctionne comme ça), j’ai décidé d’ajouter une version “mobile” à ce blog, et à ma galerie photo. Mon entourage connaît en général mon dédain plus que profond pour tout ce qui ressemble à un téléphone permettant d’accéder à internet (tous les iBidules en général, en fait). J’aurai donc pu facilement m’abstenir de passer de longues heures à ajuster une version “mobile” de mes sites. Finalement, j’ai réalisé que c’est pour moi une manière ironique et provocante d’aller au bout de ma démarche : utilisateurs de iBidules, vous aurez droit à une version amputée du site. Sans doute bien plus lisible, mais partielle.
Cela dit, et sans mauvais esprit aucun : bonne visite à tous.
Et puis, pour justifier le pluriel de mon titre : j’ai aussi cédé aux sirènes des réseaux sociaux, puisque je suis désormais inscrit sur LinkedIn et Viadeo (Shame. On. Me.).
Sylights : une idée lumineuse ?
Sylights, c’est un site web intéractif qui vous permet de construire et partager des plans d’installation de lumières pour des prises de vues. Si vous êtes photographe, et que vous travaillez souvent avec du matériel pour façonner votre lumière, vous comprenez ce dont il s’agit.
Boîtes à lumière, réflecteurs, “gobo”, fonds, flashes… tout est là, ou presque, pour vous permettre de cartographier fidèlement vos montages de prise de vue. Il manque tout de même de quoi annoter les plans, et peut être quelques éléments comme des murs.
Je pense que c’est un très bon complément à Flickr (même si je n’utilise pas ce dernier).
Sylights devrait s’étoffer rapidement, avec des fonctions d’annotation, et la possibilité de poster des photos illustrant le montage de lumière décrit (ça semble primordial !).
Un petit exemple tout simple pour la route : mon premier essai.
L’avenir nous dira si c’est une idée lumineuse ou pas. Mais quand les plans seront ré-éditables, qu’on pourra y faire des annotations, et qu’on pourra les “hot-linker” depuis un blog, ça deviendra certainement un outil de référence !
Créer un proxy personnalisé avec launchd (2/2)
Cet article est la suite de la première partie : “Créer un proxy personnalisé avec launchd (1/2)”
Coder votre proxy personnalisé.
C’est théoriquement l’étape du travail la plus intéressante, puisque c’est ici que l’on peut exprimer toute sa créativité, et surtout apporter la réponse à un de ses problèmes. Comme le programme sera lancé à la demande par launchd, et que c’est ce dernier qui va gérer le socket de communication avec le client, la tâche est simplifiée. En contrepartie, le programme ne peut pas être trop lourd, car des lancements à répétition seraient alors pénalisants pour le reste du système.
Mac OS X est livré avec de nombreux langages de script et de programmation (C, Java, PHP, Python, Ruby, Perl, Shell…). Contrairement à mon habitude, j’ai choisi de coder mon proxy en PHP. De la sorte, je pouvais réutiliser mon code dans un autre contexte au cas où le fonctionnement en proxy ne donnait pas satisfaction.
Voici le squelette de mon script PHP, à titre d’exemple :
#!/usr/bin/php
<?php
// get request from http client
$request = explode(" ", trim(fgets(STDIN)));
$MyGET = $request[1];
// curl request
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $MyGET);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($ch);
// cleanup
curl_close($ch);
// callback
function fetch_author($matches) {
../..
return $matches[1].$matches[2].$author[1]." ".$matches[3];
}
// html parsing
$apresreplace = preg_replace_callback('/.../',"fetch_author",$output);
// output
echo $apresreplace;
?>
J’ai volontairement simplifié et tronqué mon code. La seule chose qui compte est le squelette du programme. Première remarque, le script fonctionne en mode “ligne de commande”. C’est du PHP, mais il ne sera pas interprété par Apache, donc les variables intéressantes de $_SERVER, de $_GET, … n’existent pas. Je récupère la requête du client HTTP en lisant tout simplement la première ligne de STDIN.
Ensuite, j’utilise les fonctions de la librairie CURL pour aspirer le contenu distant qui correspond à l’URL transmise par le client. Puis je fais sur ce contenu un rechercher-remplacer via la fonction preg_replace_callback et via la fonction attachée que j’ai créée (dite fonction de callback).
Les détails ne sont pas importants, à ce stade ce qu’il faut bien comprendre, c’est que mon script de proxy a reçu l’URL demandée par le client. Il a téléchargé le contenu correspondant à cette URL, et il l’a enrichi selon mes besoins. La dernière ligne du script renvoie dans la sortie standard le contenu enrichi. Le client (mon lecteur de flux RSS) reçoit alors la réponse à sa requête.
Lancer le proxy à la demande
Launchd est l’outil idéal pour lancer le proxy dès qu’une connexion est initiée dans sa direction. Le fonctionnement est alors similaire à inetd (ou xinetd). La problématique est la même que dans le cas de la création d’un tunnel ssh à la demande, donc je passe sur les détails.
Voici le fichier plist de configuration qu’il faut charger dans launchd pour activer le proxy :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Debug</key>
<false/>
<key>Label</key>
<string>tld.monsuper.proxy</string>
<key>ProgramArguments</key>
<array>
<string>/chemin/du/programme/de/proxy</string>
</array>
<key>Sockets</key>
<dict>
<key>Listeners</key>
<dict>
<key>SockNodeName</key>
<string>127.0.0.1</string>
<key>SockServiceName</key>
<string>8080</string>
<key>SockType</key>
<string>stream</string>
</dict>
</dict>
<key>StandardErrorPath</key>
<string>/tmp/proxy.err</string>
<key>inetdCompatibility</key>
<dict>
<key>Wait</key>
<false/>
</dict>
</dict>
</plist>
Après avoir adapté le Label, le chemin du programme, le port de connexion, et éventuellement le fichier de stderr, il faut enregistrer ce fichier plist dans ~/Library/LaunchDaemons/ (pour vous seul) ou dans /Library/LaunchDaemon/ (pour tous les utilisateurs de la machine). Ensuite il faut le charger via launchctl load /chemin/du/fichier.plist.
C’est terminé. Toutes les briques du proxy personnalisé sont en place. Le client (si il honore bien les préférences systèmes) utilisera le proxy désigné dans le fichier .PAC. Launchd recevra la requête et la transmettra au programme du proxy. Ce dernier fera les traitements sur les données téléchargées, et renverra le résultat au client.
edit : style et coquilles
edit : ajout de l’IP 127.0.0.1 pour le bind, ça évite que le proxy puisse êtes utilisé par n’importe qui sur le réseau… :)