Data leak at Elinchrom

As I'm paranoid, I create a brand new email address each time I've got to register on a web site. It's easy enough and allows me to partition usages and detect abuse. If one of those dedicated addresses ends up in the wild (spammers for example), I just destroy it.

CCBY ©Yuri Samoilov via Flickr

CCBY ©Yuri Samoilov via Flickr


So, in 2010 I registered a support account on Elinchrom's web site with a tailored address : elinchrom (@patpro.net of course). Later, during September 2014, I've received a big spam at that address, neither from Elinchrom nor from one of their partner. After a quick search I've found many other spams blocked by my server. The earlier arrived in 2013.
I've contacted the company, explained the problem, and sent extracts from my mail server logs. After few days, they could find no evidence of a compromise or a data leak on their side. Fair enough, that's not the kind of things you can detect easily, especially if it's years old. On a side note: it's not impossible that I've used the same email address for a contest or event registration affiliated with Elinchrom but not run by them. My bad. At least, this time they deserved the benefit of the doubt.
Following this leak, I've changed the address email to elinchrom2014 (still @patpro.net) and changed the associated password.
The 31th of December 2015 I've received my very first email at this new address: a Paypal phishing attempt, out of a hacked web server somewhere…
Fine.

As I'm super-vigilant since 2014 not to use this address anywhere, the only possible scenario is a data leak at Elinchrom. Going back into my logs, I've found the earliest spam blocked dated from the 24th of October:

Oct 24 17:17:50 postfix/smtpd[84170]: NOQUEUE: reject: RCPT from unknown[202.71.131.54]: 550 5.7.1 Client host rejected: cannot find your hostname, [202.71.131.54]; from=<apache@corp17.net4india.com> to=<elinchrom2014@...> proto=ESMTP helo=<smtp.net4india.com>

I've immediately destroyed this email address, created a new one (longer, with random characters), changed the password again.

Elinchrom: seriously, that's ridiculous, do something. Even the user authentication does not use HTTPS. WAKE UP, it's 2016.

Un shell taillé pour le roaming, la 3G et les cages d’ascenseur

Les fans de la ligne de commande, ou ceux qui sont obligés de s'en servir, le savent : garder un shell distant ouvert et réactif peut parfois être très compliqué, voire impossible. Vous lancez une manip un peu longue mais après quelques temps vous devez changer de réseau. Vous devez intervenir d'urgence via une connexion mobile de très mauvaise qualité. Vous êtes coincé dans un ascenseur avec quelques kbps de bande passante sur un WIFI intermittent. Autant de raisons qui vous feront aimer mosh.

passer-sur-mosh
Mosh pour Mobile Shell, est un outil client et serveur qui supporte le roaming, et qui fonctionne particulièrement bien sur les connexions de mauvaise qualité.
L'architecture de mosh est bien pensée : elle ne nécessite pas d'intervention lourde sur vos serveurs pour en permettre l'utilisation et elle s'appuie sur un serveur ssh existant pour gérer l'initialisation de la connexion, dont la phase d'authentification.

Vous devez simplement installer mosh sur votre poste et sur votre serveur. À partir de là, la connexion fonctionne selon ce principe :
- vous lancez mosh en pointant sur votre login@serveur
- mosh ouvre une connexion ssh login@serveur ce qui permet de procéder à votre authentification
- dès que vous êtes authentifié, mosh lance mosh-server sur le serveur, sous votre UID
- mosh ferme la connexion ssh, et passe la main au mosh-client
- mosh-client se connecte en UDP sur votre mosh-server distant.

Bien sûr, les paquets UDP sont chiffrés, garantissant la sécurité de la connexion. Mosh dispose aussi d'une fonction local-echo très utile sur les liens à forte latence : vous voyez ce que vous tapez immédiatement, contrairement à ce qu'il se passe sur une connexion ssh, où votre entrée devra arriver sur le serveur, être traitée, être renvoyée à votre terminal puis enfin affichée. Cela ajoute un agrément très appréciable sur les lignes très lente ou de mauvaise qualité.

Aussi, l'utilisation de l'UDP, un protocole non-connecté, autorise une implémentation simple de l'itinérance. Plus de problème quand votre portable change de réseau Wifi, passe de l'ethernet à la 4G, etc. Votre connexion avec le serveur reste ouverte, et utilisable dès que le réseau est disponible.

J'encourage vivement les curieux à approfondir les aspects techniques, c'est intéressant et innovant.
Attention cependant, mosh ne supporte pas les utilisations non-intéractives de ssh : scp, les tunnels, X-Forwarding… C'est vraiment fait - actuellement - pour remplacer la bonne vieille session interactive.

Les binaires sont disponibles pour de nombreuses plateformes, même pour Mac OS X 10.5... vous n'avez plus aucune excuse.

Mamiya, me voilà !

Après m'être initié (un peu) à la photographie moyen format à l'aide d'un remarquable ARAX 6x6 j'ai longtemps cherché un bon boitier, fiable et relativement moderne pour faire du film et du numérique. Les deux appareils sérieux dans cette catégorie sont l'Hasselblad 503CW et le Mamiya 645 AFDIII.
Ainsi, pendant plusieurs années, j'ai positionné des alertes sur des sites d'annonces, je me suis abonné à des tas de flux RSS, j'ai même twitté ma détresse.
Mais ma patience a enfin été récompensée car je viens d'acquérir à un prix tout à fait honnête un boitier AFDIII et une l'optique de base 80 2.8. Il me manque désormais uniquement le dos film (HM402 ou HM401) pour pouvoir shooter en analogique, et un dos numérique (genre P25+ ou Aptus-II 7) pour pouvoir shooter en numérique.
Et donc forcément, le cirque des alertes et des flux RSS reprend de plus belle !
Mamiya_645_AFD_III
Merci à Frédéric pour la vente.

Mise à jour FreeBSD : impact sur SSL/TLS

Dans le cadre de mon travail, j'administre quelques serveurs de messagerie à fort trafic. Certains tournent sous FreeBSD. Toute modification de ces serveurs, clés de voûte de notre infrastructure de messagerie, doit se faire avec prudence et en comparant leur fonctionnement avant et après le changement. Je suis aidé en cela par Splunk, un collecteur de logs qui me permet de faire des analyses poussées.
Splunk est notamment très doué pour afficher des tendances, des évolutions, et permettre de représenter quelques secondes ou minutes vos données sous forme graphique. Notamment, à chaque mise à jour de l'antispam, de l'antivirus, de Perl ou d'autres composants critiques, il me permet de vérifier en quelques instants que le temps de traitement des messages dans les différents filtres n'est pas dégradé par la mise à jour.
La montée de version de FreeBSD 9.x vers FreeBSD 10.1 m'a notamment permis de bénéficier d'une version d'OpenSSL plus récente, et supportant TLS 1.2. Ce changement n'est pas anodin. SSL est mort, TLS 1.0 suit le même chemin, il faut donc pouvoir utiliser TLS 1.2.
Voyons l'impact de cette mise à jour sur les échanges chiffrés avec les autres serveurs de messagerie (ici, uniquement les messages sortants) :

Évolution de la version de TLS dans les échanges suite à la mise à jour du système

Évolution de la version de TLS dans les échanges suite à la mise à jour du système

Évolution des algorithmes de chiffrement dans les échanges suite à la mise à jour du système

Évolution des algorithmes de chiffrement dans les échanges suite à la mise à jour du système

Cette rapide analyse ne porte que sur les échanges chiffrés : les échanges de mails avec les serveurs ne permettant pas le chiffrement TLS ne sont pas représentés. La passerelle de messagerie dont il est question ici fait tourner trois instances postfix en "postfix-multi", et voit transiter trois à cinq millions de messages par mois selon la période de l'année.

ZFS primary cache is good

Last year I've written a post about ZFS primarycache setting, showing how it's not a good idea to mess with it. Here is a new example based on real world application.
Recently, my server crashed, and at launch-time Splunk decided it was a good idea to re-index a huge apache log file. Apart from exploding my daily index quota, this misbehavior filed the index with duplicated data. Getting rid of 1284408 events in Splunk can be a little bit resource-intensive. I won't detail the Splunk part of the operation: I've ended up having 1285 batches of delete commands that I've launched with a simple for/do/done bash loop. After a while, I noticed that the process was slow and was making lots of disk IOs. Annoying. So I checked:

# zfs get primarycache zdata/splunk
NAME          PROPERTY      VALUE         SOURCE
zdata/splunk  primarycache  metadata      local

Uncool. This setting was set locally so that my toy (Splunk) would not harvest all ARC from the server, hurting production. For efficiency's sake, I've switched back the primary cache to all:

# zfs set primarycache=all zdata/splunk

Effect was almost instantaneous: ARC filled with Splunk data and disk IOs plummeted.

primarycache # of deletes per second
metadata 10.06
all 22.08

A x2.2 speedup on a very long operation (~20 hours here) is a very good argument in favor of primarycache=all for any ZFS user.

acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

Acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

La Science Fiction de Clifford D. Simak

demain-les-chiensDe temps en temps, faute de nouvelle parution de mes auteurs favoris, je dois me tourner vers des ouvrages pris un peu au hasard dans les longs rayonnages de Trollune. Récemment j'ai découvert Clifford Simak au travers des deux chefs-d'œuvre que sont Demain les chiens, et Voisin d'ailleurs. L'écriture de Simak est agréable et sans détour, et toujours empreinte de bienveillance. Si les récits les plus anciens sont très ancrés dans les années 50, l'auteur ne reste jamais prisonnier de son époque. Contrairement à de nombreux autres, il parvient toujours à sortir ses histoires de ce qui nous apparaîtrait désormais comme une impasse dans un passé poussiéreux.
Demain les chiens est une fable composée de différents récits. Elle prend racine dans l'Amérique des années 40, et vous transporte sur plus de 10 000 ans, bien au delà de la disparition du dernier homme. J'ai abordé cette lecture avec tout le scepticisme que m'évoque un roman de Science Fiction écrit il y a 70 ans par un auteur que je ne connais pas. Après les deux premières histoires, j'étais conquis. Je n'en dirai pas plus pour ne pas gâcher le plaisir des futurs lecteurs.
Voisin d'ailleurs est un recueil de nouvelles non reliées entre elles, si ce n'est par la même énergie de l'auteur. Leur écriture s'étale sur plusieurs décennies et permet d'apprécier l'évolution du style de Simak. Le recueil se termine même par une nouvelle quasiment Lovecraftienne, ce qui n'est pas pour me déplaire. Voyageurs du futur, extraterrestres, homme préhistorique immortel, rien ne vous sera épargné, pour votre plus grand plaisir. À lire d'urgence.

Koken : le portfolio web des photographes

Depuis quelques temps je traîne un WordPress dédié à mes photos, histoire de présenter un peu ce que je fais, sans tout mélanger avec le présent blog. Le truc c'est que WordPress n'est pas fait pour ça. Sa gestion d'images, bien que très correcte pour un CMS, reste limitée. Les thèmes de présentation ne sont pas terribles, je n'en ai jamais trouvé un qui me plaise vraiment.
Puis j'en avais marre de ces failles de sécurité presque hebdomadaires : je passe plus de temps à administrer les noyaux WordPress qu'à m'en servir pour publier des choses.

Les thèmes de koken sont aussi entièrement "responsive"

Les thèmes de koken sont aussi entièrement "responsive"

Il était donc temps de changer. Après une courte recherche, je suis tombé presque par hasard sur Koken. Doté d'un scepticisme hors du commun quand il s'agit des applications web, a fortiori codées en PHP, j'ai tout d'abord cru que Koken était comme les autres : mal conçu, plein de parti-pris et de choix techniques imposés par des développeurs plutôt que par des photographes. J'ai approché l'objet avec cautèle, prêt à le vouer aux gémonies et sautant sur la moindre occasion pour râler et montrer du doigt ici un comportement inadmissible ou là une fonctionnalité mal implémentée. "Ha ! Je vous l'avais bien dit" m'apprêtais-je à exulter.

Lâs ! Mal m'en a pris, j'étais dans l'erreur. Koken c'est de la grosse bombe.

C'est tout d'abord une application vraiment bien pensée. Elle atteint un degré de fonctionnalité et d'ergonomie rarement vu sur des applications gratuites, et plus particulièrement dans ce segment (CMS/Portfolio auto-hébergé). Toute sa gestion de contenu est bien conçue, et pour ceux qui utilisent Photoshop Lightroom, l'intégration est poussée au maximum avec la possibilité de publier directement à partir de LR vers ses albums dans Koken. Je ne suis pas fan des applications web qui tentent d'imiter le fonctionnement et l'ergonomie des applications "lourdes". Là encore, je mets ma critique dans la poche, Koken réussi ce pari de fournir une expérience utilisateur quasi parfaite.

Un des principes de base de Koken est de partir de vos photos dans leur version la plus grande et lourde. En général, on publie des photos sur internet sous une taille limitée, pour qu'elles soient légères, plus vite téléchargées et affichées sur l'écran du visiteur. Ici il faut prendre le contre-pied total de cette démarche d'optimisation. En postant l'image la plus grosse possible, vous préparez l'avenir. Vous supportez dès maintenant les écrans "retina", et vous n'aurez pas besoin de republier des photos en haute définition plus tard, quand le débit des connexions aura encore grimpé.
Je viens de le faire : j'ai parcouru mon blog photo WordPress, j'ai fait l'inventaire de toutes les photos publiées, à l'époque en 800px de large, j'ai retrouvé ces photos dans Lightroom, je les ai réexportées dans Koken en grand format. J'avais déjà du le faire en 2012 en passant de PixelPost à WP, c'est incroyablement laborieux, et si mon ancien portfolio avait contenu les fichiers en haute définition j'aurai gagné un temps fou. Mais désormais je suis paré, prêt pour l'avenir.

Sur le plan technique Koken est aussi une application très abordable. Elle ravira tous les photographes qui n'aiment pas bricoler sur un serveur, configurer des bouts de machins, se battre avec des fichiers php. L'installation se fait assez simplement : vous vous assurez de disposer d'une base de données, et vous téléchargez un fichier "index.php" que vous déposez sur un serveur dans son répertoire "koken". Vous accédez ensuite à cette page via un navigateur et vous suivez les instructions.
Et c'est là ma seule et unique réserve au sujet de Koken : la manière pas très transparente qu'ils ont de collecter des informations sur l'utilisateur. En effet, pour installer réellement le logiciel à partir de la page index.php, il faut s'enregistrer (adresse email, nom, prénom, ...). Heureusement on peut toujours donner des informations bidons (même pour l'adresse email). Je trouve le procédé pas très classe. En fait, le produit est tellement bon que je pourrais payer si ça me dispensait de cette procédure d'enregistrement.
Bref, une fois enregistré, tout se fait rapidement : la dernière version de l'application est téléchargée, installée et configurée.

Le travail technique est terminé, il reste le plus dur : décider de votre workflow, de la manière dont vous allez organiser vos photos, des albums, sets, et catégories que vous allez créer pour classer votre production, et bien sûr choisir un thème. Surtout, n'hésitez pas à repousser le choix du thème à la toute fin. Dès que vous avez l'assurance que quelques uns vous plaisent, ne perdez pas de temps dessus et concentrez-vous sur les photos. Revisitez votre bibliothèque Lightroom, décidez quoi faire de vos tags, réfléchissez aux réglages d'import initial des images dans Koken, etc.
Le choix du thème peut vraiment arriver en dernier : certains utilisent les tags, d'autres pas, certains affichent le nom du fichier, d'autres pas, et souvent ils disposent de nombreux réglages, si bien qu'il est probablement plus intéressant de consolider le contenu du portfolio avant de s'attaquer à la présentation.

Pour résumer, je suis totalement conquis (et c'est rare).

Firefox mange mon CPU

Comme je suis vieux et extrémiste, j'ai décidé de ne pas adhérer aux mises à jour continuelles des systèmes d'exploitation Apple. Ce que proposent les nouvelles versions est rarement intéressant (cloud, flicage des utilisateurs, baisse des performances, App Store, etc.).
Le souci avec les vieux logiciels, c'est le manque de sécurité qu'ils offrent. Les nouveaux ne valent guère mieux, mais la mesure du risque se fait sur le nombre de failles connues, et donc à ce compte là, les anciennes versions sont toujours perdantes. Ne faisant plus évoluer mon système, mais passant mon temps sur internet, j'ai donc du m'adapter : virer mon Safari préhistorique, et installer un navigateur bien à jour, au taquet, fourni par un éditeur qui lui ne se fout pas de ma gueule (comprendre qu'il n'oblige pas les gens à acheter un nouveau Mac pour bénéficier d'un navigateur web à jour).

Bref, j'utilise Firefox.

J'en étais content, jusqu'au moment où j'ai trouvé qu'il était relativement lent, puis lent, puis très lent, puis très très lent. En fait, ce navigateur mange mon CPU. Petit à petit. Si vous êtes le genre d'utilisateur qui allume/éteint sa machine tous les jours, vous n'avez pas ce problème. Mais si vous laissez le chauffage d'appoint allumé 24/7/365, alors vous pourriez constater ce genre de chose :

firefox_cpu-580

Avec le temps qui passe Firefox consomme de plus en plus de cycles de processeur. Après une poignée d'heures, il est environ à 18%. Sans rien faire avec, 200 minutes plus tard il consomme 21% du CPU. Après 1000 minutes, il oscille entre 33 et 35% CPU.
On constate aussi que le nombre de threads de l'application gonfle tranquillement.

J'ai tenté d'accuser les extensions, mais je n'en utilise que 2 et une fois désactivées Firefox avait le même comportement. J'ai aussi tenté d'analyser le comportement du navigateur avec Instruments, sans succès. Je ne comprends pas d'où vient le souci. Peut être d'une des pages web que je garde ouvertes en permanence… Quoi qu'il en soit, c'est un peu dommage, je vais devoir programmer un redémarrage de Firefox toutes les nuits