Metasploit hearbleed scanner reliably crashes (some) HP ILO

Disclaimer: HP ILO Firmware involved here is NOT the latest available. ILO 3 cards were not affected.

Using Metasploit to scan my network for OpenSSL "Heartbleed" vulnerability I've been quite shocked to get a handful of alerts in my mailbox. Our HP C7000 was no longer able to talk to some of our HP Proliant blades' ILO.


Production was all good, and service was still delivered, but blade management was impossible: Metasploit's auxiliary/scanner/ssl/openssl_heartbleed.rb probe has just crashed six HP ILO 2 cards. That's funny, because the ILO firmware is not vulnerable to heartbleed, it's only vulnerable to the scanner...


I've made some tests to repeat the problem. It happens with a 100% reliability. Quite impressive.

Software versions:

Framework: 4.8.2-2013121101
Console  : 4.8.2-2013121101.15168
openssl_heartbleed.rb : downloaded on April the 22th.

HP ProLiant BL490c G6 (product ID 509316-B21), ILO 2 firmware undisclosed for security reasons.

Log aggregation and analysis: splunk

As soon as you have one server, you might be tempted to do some log analysis. That can be to get some metrics from your Apache logs, your spam filter, or whatever time-stamped data your server collects. You can easily find small tools, or even create a home-made solution to extract info from these files.
Now imagine you have 100, 200, or even thousands of servers. This home-made solution you've created no longer suits your needs.
Different powerful products exist, but I'll focus on two of them: Splunk on one side, Logstash+Elasticsearch+Kibana on the other side. This post is dedicated to Splunk. Logstash will come later.

Both softwares are tools. These are not all-in-one solution. Exactly like a spreadsheet software which is unable to calculate your taxes unless you design a specific table to do so, you must use the software to create value from your logs. Installing and feeding logs into the software is not the end of your work, it's the very beginning.

Splunk is a commercial product. It's incredibly powerful out of the box, and its documentation is very good. Every aspect of the software is covered in depth with numerous examples. It also has an official support. Unfortunately Splunk is very (very) expensive, and no official rates are available online. Hiding the cost of a software is often the promise you won't be able to afford it.
Splunk is well packaged and will run effortlessly on many common systems. At least for testing. Scaling up requires some work. I've been told that apparently, scaling up to more than few TB of daily logs can be difficult, but I don't have enough technical details to make a definitive statement about this.
Rest assured that Splunk is a very nice piece of software. It took me only an hour from the time I've installed it on a FreeBSD server, to the time I've produced a world map showing spam filter action breakdown by location:


One hour. This is very short, almost insane. The map is fully interactive, and you can click any pie chart to display the table of values and the search request allowing you to create this table:


The query syntax is quite pleasant and almost natural. The search box is very helpful and suggests "Common next commands", or "Command history" alongside with documentation and example:


Splunk has some other killing features like users management and access control, assisted (almost automated) regex design for field extraction, or its plugin system. The Field extraction "wizard" is quite impressive, as it allows you to extract new fields out of already indexed logs, without writing any regex nor re-indexing your logs. You just browse your logs, paste samples of data you want to extract, and it builds the filter for you.
Transactions are also a pretty damn great feature: they make correlation of different events possible (login and logout, for example), so that you can track complex behaviors.

More importantly, Splunk appears to be simple enough so any sysadmin wants to use it and does not get rebutted by it's complexity. It's a matter of minute(s) to get, for example, the total CPU time involved in spam filtering last month (~573 hours here). Or if you want, the total CPU time your antispam wasted analyzing incoming emails from facebook (~14.5 hours). But it's definitively a very complex software, and you have to invest a great deal of time in order to get value (analytics designed for you) from what you paid for (the license fees).

I love Splunk, but it's way too expensive for me (and for the tax payers whose I use the money). So I'm currently giving Logstash a try and I'm quite happy about it.

Le PC dans mon téléphone

Précédemment, j'ai évoqué l'ordinateur de demain. J'ai fait un test grandeur nature façon corporate. Comprendre : vous aurez du mal à faire pareil chez vous. J'utilise en effet quelques artifices comme un accès VPN au réseau de mon employeur, et au travers de cet accès une machine virtuelle VMware View.
Au final, j'ai le bureau d'une machine Windows 7 affiché sur la TV du salon, j'ai un clavier et une souris bluetooth, le tout servi par mon téléphone malin, via un tunnel VPN dans une connexion WIFI. La connexion avec la machine virtuelle se fait via le client officiel View, de VMware (donc en PCoIP).

Windows dans ma TV sur mon téléphone

Ci dessus une photo de la TV affichant le bureau de la VM dans laquelle est lancé le client VSphere (outil d'administration de datacenter VMware).

À 2m50, le texte dans l'interface n'est pas hyper lisible sur l"écran 80cm, donc pour le PC dans le canapé, on repassera, ou alors on fera des réglages spéciaux sur la machine virtuelle.

Le client View se comporte relativement bien, néanmoins, il y a comme un petit souci avec le clavier. Ce dernier fonctionne parfaitement en azerty partout, sauf à l'intérieur du Windows, où il fonctionne en qwerty. Le client View dispose d'un champs de saisie qui permet de taper du texte à l'extérieur de la VM et de l'envoyer ensuite vers cette dernière. À cet endroit, c'est bien de l'azerty. Mais le même texte tapé directement dans la VM passe en qwerty. C'est peut être du à mon téléphone, qui est paramétré tout en anglais.

Aussi, suite à un blocage logiciel sur ma VM, j'ai tenté un ctrl-alt-suppr via mon clavier bluetooth. Le programme n'a pas rendu la main, la VM n'a pas rebooté. Non. C'est le téléphone qui a rebooté. Ça m'a fait rire.

ZFS primarycache: all versus metadata

In my previous post, I wrote about tuning a ZFS storage for MySQL. For InnoDB storage engine, I've tuned the primarycache property so that only metadata would get cached by ZFS. It makes sense for this particular use, but in most cases you'll want to keep the default primarycache setting (all).
Here is a real world example showing how a non-MySQL workload is affected by this setting.

On a virtual server, 2 vCPU, 8 GB RAM, running FreeBSD 9.1-RELEASE-p7, I have a huge zpool of about 4 TB. It uses gzip compression, and stores 1.8TB of emails (compressratio 1.61x) and 1TB documents (compressratio 1.15x). Documents and emails have their own dataset, on the same zpool.
As it's a secondary backup server, isolated from production, I can easily make some tests.

I've launched clamscan (the binary part of ClamAV virus scanner) against a small branch of the email storage tree (about 1/1000 of total emails) and measured the zpool IOs, CPU usage and total runtime of the scan.
Before each run, I've rebooted the server to clear cache.
clamscan is set up so that every temporary files are written into a UFS2 filesystem (/tmp).

One run was made with property primarycache set to all, the other run was made with primarycache set to metadata.

Total runtime with default settings primarycache=all is less than 15 minutes, for 20518 files:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 892.431 sec (14 m 52 s)

Total runtime with default settings primarycache=metadata is more than 33 minutes:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 2029.921 sec (33 m 49 s)

zpool iostat every 5 seconds, with different primarycache settings, ~10 minutes range.

zpool IO stats

CPU usage for clamscan process, and for kernel{zio_read_intr_0} kernel thread. 5 seconds sampling, with different primarycache settings, ~10 minutes range.

CPU stats

In both tests, the server is freshly rebooted, cache is empty. Nevertheless, when primarycache=all the kernel{zio_read_intr_0} thread consumes very few CPU cycles, and the clamscan process run's more than twice as fast as the same process with primarycache=metadata.
More importantly, clamscan manages to read the exact same amount of data in both tests, using 10 times less IO throughput when primarycache is set to all.

There is something weird. Let's make another test:

I create 2 brand new datasets, both with primarycache=none and compression=lz4, and I copy in each one a 4.8GB file (2.05x compressratio). Then I set primarycache=all on the first one, and primarycache=metadata on the second one.
I cat the first file into /dev/null with zpool iostat running in another terminal. And finally, I cat the second file the same way.

The sum of read bandwidth column is (almost) exactly the physical size of the file on the disk (du output) for the dataset with primarycache=all: 2.44GB.
For the other dataset, with primarycache=metadata, the sum of the read bandwidth column is ...wait for it... 77.95GB.

There is some sort of voodoo under the hood that I can't explain. Feel free to comment if you have any idea on the subject.

A FreeBSD user has posted an interesting explanation to this puzzling behavior in FreeBSD forums:

clamscan reads a file, gets 4k (pagesize?) of data and processes it, then it reads the next 4k, etc.

ZFS, however, cannot read just 4k. It reads 128k (recordsize) by default. Since there is no cache (you've turned it off) the rest of the data is thrown away.

128k / 4k = 32
32 x 2.44GB = 78.08GB


MySQL on ZFS (on FreeBSD)

logofreebsdLots on FreeBSD users are coming to ZFS since the release of FreeBSD 10, as it's so easy to install the system on top of that powerful filesystem. ZFS default behavior and settings are perfect for a wide range of workloads and uses, but it's not exactly what you need for databases hosting.
I'm running a FreeBSD 9.x server hosting http, php, mysql, mail, and many other things, so a databases-only optimization would be counterproductive. After a good dive into experts do's & don't's here are few steps I've taken to tune my server.


If like me you've started hosting MySQL databases a long time ago (say ~15 years ago) you might have some DB using the old MyISAM engine, and some newer ones using InnoDB. Guess what. They use different block sizes, and they use different caching mechanisms.
On top of that, the block size for InnoDB is not the same when you deal with data files, and when you deal with log files.
In order to get the best block size and cache tuning possible, I've created 3 datasets: one for InnoDB data files, one for innodb logs, and one for everything else, including MyISAM databases.

Block size

The block size is engine dependent. MyISAM uses a 8k block size, InnoDB uses a 16k block size for data and 128k for logs. It's easy to setup datasets for a particular block size at creation with -o option, or after creation with zfs set. You must set the proper block size before putting any data on the dataset, otherwise pre-existing data won't use the desired block size.


MyISAM engine relies on the underlying filesystem caching mechanism, so you must ensure ZFS will cache both data and metadata (that's the default behavior). On the other hand, InnoDB uses an internal cache, so it would be a waste on memory to cache the same data into ZFS and InnoDB. On a dedicated MySQL server, the proper tuning would require to limit ARC size, and to disable data caching in ZFS. On a general-purpose server, ARC size should not be tweaked, but on InnoDB dedicated datasets it's easy to disable ZFS cache for data by setting the property primarycache to "metadata".

On MySQL's side

You must of course tell mysqld where to find data files and logs. I've set those values in my /var/db/mysql/my.cnf file:

innodb_data_home_dir = /var/db/mysql-innodb
innodb_log_group_home_dir = /var/db/mysql-innodb-logs

where /var/db/mysql-innodb and /var/db/mysql-innodb-logs are mount points for the dataset dedicated to InnoDB data files, and the dataset dedicated to InnoDB log files.

As my zpool is a mirror, I've added this setting too:


Step by step

I've followed this course of action:

1st step: mailing to users, "MySQL will be unavailable for about 5 minutes, hang on."
2nd step: backup /var/db/mysql and edit your my.cnf
3rd step: shutdown your mysql server

sudo service mysql-server stop

4th step: move /var/db/mysql to /var/db/mysql-origin
5th step: create appropriate datasets:

zfs create -o recordsize=16k -o primarycache=metadata zmirror/var/db/mysql-innodb
zfs create -o recordsize=128k -o primarycache=metadata zmirror/var/db/mysql-innodb-logs
zfs create -o recordsize=8k zmirror/var/db/mysql

6th step: move data from /var/db/mysql-origin to your new datasets

cd /var/db/
sudo mv mysql-origin/ib_logfile* mysql-innodb-logs/
sudo mv mysql-origin/ibdata1 mysql-innodb/
sudo mv mysql-origin/* mysql/

and set proper rights:

sudo chown mysql:mysql mysql-innodb-logs mysql-innodb mysql
sudo chmod o= mysql mysql-innodb-logs mysql-innodb

7th step: restart your mysql server

sudo service mysql-server start & tail -f mysql/${HOSTNAME}.err

8th step: mailing to users, "MySQL's back online maintenance duration 5 min 14 sec."

Further reading & references

MySQL Innodb ZFS Best Practices
A look at MySQL on ZFS
Optimizing MySQL performance with ZFS
ZFS for Databases

L’ordinateur de demain

N'en déplaise aux "power users" de l'informatique, l'ordinateur de demain c'est vraisemblablement votre téléphone malin. C'est forcément une idée qui me révulse, puisque ce sont des dispositifs fermés et - de mon point de vue - liberticides. Mais il ne s'agit pas de débattre ici du bien-fondé de mes réticences, il s'agit plutôt de faire un simple constat. En effet, on a pu constater ces dernières années que les utilisateurs sont prêts à sacrifier pas mal de choses pour gagner en mobilité : de la puissance, du stockage, de l'ergonomie, etc. En retour ils sont prêts à investir du temps et de l'argent dans leur smartphone, quitte à s'en servir comme outils de travail en dépit des contraintes énormes que cela représente.
L'ordinateur de demain c'est votre smartphone, et il y a quelques raisons pour cela :

  • La puissance des terminaux mobiles augmente très vite, permettant à des applications de plus en plus sophistiquées de voir le jour sur ces plateformes ;
  • Leur connectivité est très forte, sur des protocoles variés ;
  • On peut déjà transformer un smartphone en PC via quelques accessoires ;

slimportJe suis l'heureux détenteur d'un téléphone malin Nexus 4 (so 2012) qui dispose d'un port USB équipé de la technologie "SlimPort". C'est un détail important, car les téléphones qui disposent d'un tel port ne sont pas légion. Ce connecteur permet de brancher le smartphone à un moniteur ou à une télévision via un adaptateur DisplayPort USB vers HDMI.
Déjà, c'est sympa puisque cela me permet de regarder une vidéo HD stockée sur (ou "streamée" à partir de) mon téléphone directement sur la TV du salon. L'HDMI est ici utilisé en plein, puisque le signal sonore transite avec la vidéo et sort bien sûr des enceintes de la TV. Comme un câble HDMI n'est pas bien long, il faut bien sûr se déplacer pour interagir avec l'écran, ce qui est fastidieux.
C'est ici qu'entre en scène ce vieux protocole du début des années 2000 : Bluetooth. Il est en effet assez facile de trouver un clavier et une souris Bluetooth de nos jours : c'est ce que j'ai fait, et ça marche du tonnerre.
Ainsi, avec un Nexus 4, un clavier Bluetooth (Perixx PERIBOARD-804), une souris Bluetooth (Apple Magic Mouse qui trainait dans un carton) et le fameux adaptateur SlimPort, j'ai pu construire un petit PC de salon. Bien évidement, ce n'est pas un poste bureautique. Même si le clavier rend des tâches rédactionnelles tout à fait aisées, les applications ne sont pas forcément à la hauteur. Pour le tout-venant c'est très simple : écrire avec un vrai clavier physique (email, sms, document…), utiliser l'interface avec la souris, surfer sur internet, passer d'une application à l'autre, etc. Presque tout fonctionne parfaitement. Il n'y a que deux limites actuellement à ce que je peux faire dans cette configuration. Je ne peux pas dire au téléphone de basculer en mode paysage, je suis obligé d'aller incliner le téléphone à la main. C'est un peu pénible car si on revient sur le "bureau" du téléphone, il repasse immédiatement en orientation portrait, ce qui n'est pas la meilleure façon de tirer partie d'une TV 16/9ème. Seconde limitation : il n'est pas possible de zoomer en avant ou en arrière car la souris ne permet pas de simuler ce mouvement des doigts (bien que la souris Apple soit multitouch).

Il me semble important de faire quelques remarques sur le matériel. Le clavier Perixx PERIBOARD-804 est simple, léger, relativement petit et confortable à la frappe. Il est parfaitement compatible avec Android en français, et c'est un des rares claviers Bluetooth disponible nativement en version AZERTY, pour un prix raisonnable (nous l'avons acheté à moins de 30 euros). Si vous vous intéressez à ce matériel, vous constaterez que de nombreux acheteurs rapportent que la prise s'est enfoncée dans le clavier quand ils ont voulu brancher le câble USB fourni pour le recharger. Mon conseil : n'utilisez pas le câble fourni. Je pense que la prise femelle est quelques dixièmes de millimètres trop petite. Utilisez un autre câble pour recharger le clavier (j'utilise le câble de mon Nexus qui entre parfaitement sans forcer).
L'adaptateur SlimPort d'Analogix est de bonne facture, mais il reste fragile. SlimPort est une technologie qui permet le passage du flux HDMI sur une simple paire de câbles torsadée : le câble est donc très fin comparé à un câble HDMI. Évitez de tordre l'adaptateur, n'abusez pas de sa souplesse, et gardez-le autant que possible bien droit sans lui imposer de rotation sous peine de subir pas moment des pertes de signal.

English video review pour le clavier Perixx PERIBOARD-804

Trajets et itinéraires de la mémoire

Trajets_et-_itineraires_de-_la_memoireSerge Brussolo est un auteur intéressant. Je l'ai découvert il y a plus de 10 ans, en dévorant Le Syndrome du scaphandrier. Son univers, un peu Science Fiction mais pas trop, est riche, étrange, sur-réaliste et surtout très centré sur l'humain. C'est particulièrement sensible dans le recueil de nouvelles Trajets et itinéraires de la mémoire qui regroupe des textes du début de sa carrière. Des textes dont certains préfigurent d'ailleurs très fortement des romans ultérieurs comme Le Syndrome du scaphandrier.

Ce recueil de nouvelles fait plonger le lecteur dans des mondes durs, des mondes impitoyables où les protagonistes sont perpétuellement en position de faiblesse. La vulnérabilité est la règle, la nudité un uniforme, celle des corps bien sûr, mais celle des esprits aussi. La pitié n'existe pas, et l'humain est maltraité au fil des pages par des régimes autoritaires absurdes. La où certains voient une déshumanisation je vois plutôt une vision tourmentée de la condition humaine. Serge Brussolo plonge le lecteur dans une version noire, extrêmement fataliste de notre monde soumis à un autoritarisme déviant. La folie est partout dans cette prose mais elle n'est pas gratuite et j'aime à penser que l'auteur y dénonce une sorte d'impuissance face à la bêtise.

Les nouvelles de Trajets et itinéraires de la mémoire ne se valent pas toutes, malheureusement, et j'ai trouvé que les dernières du recueil étaient un peu en dessous des autres. Néanmoins la lecture reste très agréable, et les amoureux de l'étrange, de la folie, y trouveront leur compte. C'est délicieusement dérangeant, ça perturbe et vient titiller certaines peurs ataviques. C'est finalement profondément humain.

Collecte en aveugle

Elle est belle celle-là : […20:00:26 +0100] "GET / HTTP/1.0" 301 235 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 […20:00:28 +0100] "GET / HTTP/1.0" 404 493 […20:00:28 +0100] "GET / HTTP/1.0" 404 493 […20:00:29 +0100] "GET / HTTP/1.0" 404 493 […20:00:29 +0100] "GET / HTTP/1.0" 404 493 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 […20:00:31 +0100] "GET / HTTP/1.0" 404 493 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.