Du SSL gratuit pour tout le monde ?

letsencrypt-logoLet’s Encrypt est une initiative toute récente de Mozilla, Cisco, l'EFF, Akamai, et IdenTrust. Elle vise à permettre à tout webmaster de proposer son site en HTTPS sans surcoût. Il s'agit de proposer aux administrateurs de serveurs web la possibilité d'obtenir gratuitement, automatiquement, et sans contrainte le précieux certificat SSL nécessaire au chiffrement des échanges entre le serveur et les clients. Le certificat sera bien évidemment reconnu nativement dans les navigateurs. C'est en tout cas la promesse du projet. Si cela permet de mettre fin à un racket que je dénonçais il y a quelques semaines, cela lève aussi quelques questions.

Un des principaux arguments des Verisign et autres Thawte pour vous facturer une fortune pour chaque certificat est que la création et le maintient d'une autorité de certification (CA) est extrêmement onéreux. Cela coûte en effet assez cher : les contraintes de sécurité sont immenses, les audits nombreux, etc. En effet la moindre compromission de l'autorité de certification réduit tous les efforts à néant : l'attaquant qui parviendrait à s'infiltrer dans la CA serait capable d'émettre des faux certificats passant pour tout à fait valides dans les navigateurs. Votre belle connexion sécurisée avec "barre verte" pourrait alors être détournée sans que vous n'en ayez conscience (sécurité ≠ confiance).
Mais on le sait ces grosses CA ne sont pas forcément plus fiables que les petites. Elles ne résistent pas forcément mieux aux pressions des agences gouvernementales, ni aux détournements ou piratages. Quelques exemples par ici. Finalement, ce surcoût n'a guère de valeur. Ce qui compte vraiment c'est de savoir si on peut faire confiance à la CA, ou pas.

Dans l'initiative Let’s Encrypt, la question de confiance peut se poser. Je n'ai pas de souci avec Mozilla, et la présence de l'EFF est rassurante. Par contre celle de Cisco m'interpelle. Snowden nous a montré comment la NSA s'amuse à intercepter les livraisons de matériels de cette marque pour caviarder les firmwares et ajouter des portes dérobées. Rien, bien évidement, n'incrimine Cisco directement dans ces magouilles. Néanmoins le doute raisonnable peut naître sur leur degré de connaissance de ces agissements.
Au bout du compte je n'ai pas trop envie de faire confiance à un groupement d'entités sachant que la duplicité d'une seule d'entre elles peut réduire à néant la sécurité des certificats délivrés.

Le protocole proposé (ACME) me laisse aussi dubitatif. J'avoue n'avoir pas lu l'ensemble du brouillon. Je n'ai pas de critique fondée à son encontre mais la débauche d'automatisme (le serveur web qui commande lui même le certificat par exemple) me laisse dubitatif, et je pense que j'attendrai sagement de voir ce que ça donne chez les autres avant d'essayer moi-même.

L'outils lets-encrypt est conçu pour fonctionner assez simplement. C'est sans doute une bonne idée au départ, mais cela laisse peu de maitrise sur le processus. Bien sûr, tout comme le protocole, il faudra attendre de voir ce que ça donne, quelles plateformes sont supportées, quels logiciels aussi. Mettre du SSL dans le web c'est sympa, mettre du SSL dans du mail (smtp, pop, imap) c'est primordial. A priori la première version sera livrée à l'été 2015, donc il reste un peu de temps.

Je souhaite profondément que Let’s Encrypt réussisse son pari. Fournir des certificats SSL reconnus et gratuits, avec des outils simples, basés sur une autorité de certification et sur des protocoles sûrs est un vrai défi.

Le racket des certificats SSL

Autrefois, Internet était un peu open bar. C'était un lieu de partage où tout le monde pouvait publier, échanger, créer librement. C'était l'insouciance. Puis il y a eu l'arrivée du commerce en ligne, avec des échanges d'argent numérique. Il a alors fallu créer la confiance, car dans nos vies pressées il n'est plus question de l'acquérir sur le long terme, non, il faut la créer de toute pièce pour en disposer immédiatement.
Sont alors arrivés en masse les sites marchands (ou non) proposant des connexions sécurisées "https". Plus récemment, l'usage des connexions sécurisées par SSL/TLS s'est beaucoup élargi, non plus pour protéger vos données bancaires d'une interception mais pour protéger votre vie privée. Il est en effet primordial de pouvoir publier sa vie sur facebook ou twitter sans qu'un méchant pirate puisse espionner directement sur votre connexion ce que vous écrivez sur ces sites.

C'est bien de promouvoir la sécurité des échanges sur internet, d'encourager les gens à proposer des services chiffrés, et les initiatives ce multiplient dans ce sens, avec par exemple des navigateurs qui vont tenter de se connecter à la version https d'un site web par défaut, et se rabattre sur la version http seulement quand la version sécurisée n'existe pas.

Pour transformer un service http classique en service sécurisé https, il faut disposer d'un certificat SSL/TLS. Malheureusement seuls les gens riches peuvent proposer des services sécurisés "de confiance". En effet il existe globalement trois manières de se procurer un certificat SSL. Vous pouvez le fabriquer vous même, c'est assez simple, cela prend quelques minutes et c'est totalement gratuit. Vous pouvez demander à un opérateur libre et gratuit comme CaCert.org de vous le proposer, c'est à peine plus long et toujours gratuit. Ou alors, vous avez de l'argent (beaucoup), et vous l'achetez chez un prestataire.
Et là, nous sommes face à trois obstacles majeurs, qui sont le Certification Authority Browser Forum, les moteurs de recherche, et le prix.

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Le Certification Authority Browser Forum est un lieu d'échange entre les développeurs de navigateur d'une part et les autorités de certification d'autre part. Ces gens se mettent d'accord sur plein de détails techniques autour de l'implémentation de la sécurité des certificats dans les navigateurs. Notamment, c'est en partie là-bas qu'ils se mettent d'accord sur quelle autorité de certification (CA) va se trouvée incluse d'office dans la liste des CA valides des navigateurs. En effet, quand vous ouvrez une page web en https, le serveur présente son certificat. Ce dernier indique par quelle CA il a été signé. Si la CA est reconnue par le navigateur tout va bien, sinon l'utilisateur reçoit une alerte indiquant que la connexion n'est pas sécurisée, qu'on ne peut pas lui faire confiance, etc. Ces messages d'alerte ont d'ailleurs beaucoup évolué depuis quelques années. Actuellement, ils sont juste mensongers. Ils induisent pour son bien l'utilisateur en erreur allant jusqu'à prétendre à tort que la connexion n'est pas sécurisée. Ce mécanisme induit chez les utilisateurs une confusion (criminelle oserais-je dire) entre sécurité et confiance, en faisant passer "une confiance que l'outil ne peut vérifier" pour une "sécurité qui n'existe pas".

Confusion sécurité confiance

Confusion sécurité confiance

Les moteurs de recherche ne sont plus ce qu'ils étaient à leurs balbutiements dans les années 90. Ils intègrent désormais des algorithmes extrêmement complexes de classement (ranking) autorisant des recherches personnalisées et un placement de produits optimisé. En parallèle ils se sont arrogés le droit de surclasser ou de déclasser des résultats de recherche selon des critères tout à fait critiquables. Google a notamment décidé d'améliorer la visibilité des sites qui répondent à des critères de sécurité arbitraires. Essentiellement cela revient à surclasser les sites internet disposant d'un certificat SSL EV (extended validation, les plus chers).
Ainsi, si vous n'êtes pas en mesure de proposer votre site web en https, avec un certificat valide et de préférence un certificat EV, vous êtes déclassés au profit de la concurrence.

Comme vous l'avez compris, la seule planche de salut pour obtenir la confiance des navigateurs et donc des utilisateurs qui sont derrière est de proposer une connexion https avec un certificat acheté chez un fournisseur du commerce. Ces certificats sont excessivement chers. Et ce tarif ne permet simplement pas, même à des individus passionnés, de proposer une connexion https qui aurait les faveurs de Mozilla ou Google.
J'utilise sur ce serveur un certificat SSL de CaCert qui contient 20 noms différents (patpro.net, www.patpro.net, patpro.fr, etc.). Ce certificat ne me coûte rien, il me permet de proposer le chiffrement SSL/TLS pour mon serveur web et pour mon serveur de mail. Si je veux obtenir un certificat comparable chez les autorités de certification du commerce, il m'en coûtera 2582 euros chez Thawte ou 6280 dollars chez Verisign/Symantec, pour un certificat valide pendant une année. À ce tarif là, c'est un certificat d'entrée de gamme, qui sera reconnu dans votre navigateur, mais ne disposera pas de la belle "barre-verte-qui-stimule-la-confiance-du-visiteur-et-améliore-le-référencement".

La fameuse barre verte qui doit donner confiance aux utilisateurs

La fameuse barre verte qui doit donner confiance aux utilisateurs


Pour disposer d'une telle parure il me faut être une entreprise, montrer patte blanche, et débourser 18200 dollars chez Verisign, toujours pour 1 an et mes 20 noms de domaines.
Heureusement il existe des alternatives un peu moins coûteuses, comme chez Gandi par exemple, où je pourrai trouver un certificat répondant à mes besoins pour 210 euros par an, ou 1900 euros en version EV. C'est toujours un coût sérieux pour un individu.

Donc la situation actuelle se résume assez simplement : les gros acteurs du web, Google en tête, poussent très fort pour que les utilisateurs ne fassent pas confiance à des certificats autosignés, ou gratuits. Ils utilisent un discours tellement simpliste qu'il en devient mensonger. En trompant l'utilisateur, ils favorisent la visibilité sur internet des gens riches, au dépend de ceux qui n'ont pas les mêmes moyens. En diffusant des messages anxiogènes aux utilisateurs, ils dévoient la sécurité réelle proposée par des certificats SSL légitimes.

Giving up on Logstash

splunk-logoMore than six months away, I've put both Splunk and Logstash (plus ElasticSearch and Kibana) to trial. Since the beginning of my experiment, the difference between both products was pretty clear. I was hoping that ELK would be a nice solution to aggregate GBs of logs every day and more importantly to allow me and my team to dig into those logs.
Unfortunately, ELK failed hard on me. Mostly because of ElasticSearch: java threads on the loose eating my CPU, weird issue where a restart would fail and ES would become unavailable, no real storage tiering solution, and so on.
ElastickSearch looks like a very nice developer playground to me. It's quite badly - if at all - documented on the sysadmin side, meaning if you're not a developer and don't have weeks to spend reading API documentation you will have a hard time figuring out how to simply use/tune the product.
Also, this data storage backend has absolutely no security features (at the time I was testing Logstash). Just imagine you put valuable data into a remotely available database/storage/whatever and you're told that you are the one that should create a security layer around the storage. Imagine a product like SMB, NFS, Oracle DB, Postgres, etc. with zero access control feature, no role. Anyone who can display a pie chart in Kibana can gain full control of your ElasticSearch cluster and wipe all your data.
Logstash too has important issues: almost every setting changes require an application restart. Writing grok pattern to extract data is an horrendous process, and a new pattern won't be applied on past data. Splunk on the other hand will happily use a brand new pattern to extract values from past logs, no restart required.
Logstash misses also pipes, functions, triggers… Search in Kibana is not great. The syntax is a bit weird and you can easily find nothing just because you've forgot to enclose your search string with quotes… or is it because you put those quotes? And of course there is this strange limit that prevent you from searching in more than seven or eight months of data…

I've tried, hard. I've registered to not-so-helpful official mailing lists for Logstash and ElasticSearch and simply reading them will show you how far those products are from "production approval". I've used it alongside with Splunk, it boils down to this statement: Kibana is pretty, you can put together many fancy pie charts, tables, maps and Splunk is useful, reliable, efficient.

Yes, I'm moving to Splunk, @work and @home. My own needs are very easily covered by a Free license, and we are buying a 10 GB/day license for our +350 servers/switches/firewalls.

You might say that Splunk is expensive. That's true. But it's way less expensive to me than paying a full time experienced Java developer to dive into ElasticSearch and Logstash for at least a year. Splunk has proper ACL that will allow me to abide by regulations, a good documentation, and a large community. It support natively storage tiering, too.

ELK is a fast moving beast, it grows, evolves, but it's way behind Splunk in terms of maturity. You can't just deploy ELK like you would do for MySQL, Apache, Postfix, Oracle DB, or Splunk. Lets wait few years to see how it gets better.

L4D2: comparative benchmark between Mac OS X and Windows

Back in december 2012 I've benchmarked (shortly) native and virtualized Mac OS X against virtualized Windows.
Few days ago, I've dedicated a 250G B SSD to a Windows 7 installation, inside my Mac Pro. Weird thing for me to go back and forth between Mac OS X and Windows. I'm more accustomed to +50 days long uptime. Admittedly my various attempts to put Mac OS X into deep sleep, reboot on Windows, and go back later to a fully restored Mac OS X session right out from deep sleep, are failing. That's another story.
Nevertheless, I'm using this Windows system as a playground.

Inside this Mac Pro model 2010, I've one Xeon quad core 2.8 GHz with 24 GB RAM, and a Radeon HD 5770. One SSD is dedicated to Mac OS X 10.6.8, and one SSD is dedicated to Windows 7 Pro 64 bits (with latest stable Catalyst drivers). Both systems are using the latest Steam client with a fully updated and clean Left 4 Dead 2 install.

I've recorded a demo, and played back this file on both systems with identical video settings, recording fps numbers during the playback. The demo is 17827 frames long, and video settings are "MSAA x4", "Anisotropic 8x", "vertical sync triple", "resolution 1920x1200", "shader detail very high', "effect detail high", "model/texture detail high".

The playback is a bit laggy on Mac OS X, especially when the player is looking at fire. It would be playable, but not a very smooth experience. The playback is better on Windows.
Here is the plot of numbers of frames calculated at a given fps rate. For example, on Mac OS X (black line) a total of 4 frames were calculated at a frame rate of 10 fps. On Windows, 90 frames where calculated at a frame rate of 47 fps.

click plot to display full size

click plot to display full size

Windows 7 has better drivers, and may be the game itself is coded better. The fact is some situations in the game are not handled very well by the GPU on Mac OS X. The huge spike around 30 fps means that ~2500 frames were computed at about 30 fps. Not good. But more importantly the global shape of the plot shows a spread of fps values from as low as 10 fps to 60 fps. Note that the log scale on Y does mask isolated frames (Y=1).
Windows does a better job here, with only a handful of frames below 40 fps.

Fortunately L4D2 is an old game, and my hardware is enough to handle it nicely even on Mac OS X (I usually play at 1600x1000), but being able to push it a little further with full quality on Windows is a nice thing. I hope L4D3 will run ok too, some day, in a not too distant future.

Edit

To complete the comparison, I've made a Cinebench R15 benchmark. The OpenGL score on Windows 7 is ~64 fps, and the same test on Mac OS X 10.6.8 is ~53 fps. On CPU side both OSes score around 440.

S’envoyer des SMS multilignes via l’API de free-mobile

Free vient de mettre à disposition de ses abonnés Free-mobile un moyen simple de générer via une API accessible en ligne des SMS à soi-même. L'utilisation est globalement très simple et tient presque toutes ses promesses (actuellement il ne semble pas possible de faire du POST, seul le GET fonctionne).
Il suffit aux intéressés de se rendre sur leur interface de gestion de compte Free-mobile, dans la section "Mes options", et d'y activer (vers le bas de la page) l'option ad-hoc. Une fois l'option activée, Free vous gratifie d'un mot de passe dédié à cet usage, et vous renseigne un peu sur le fonctionnement du service :

free-mobile-notification

Une fois l'option activée, l'utilisation se résume à une requête HTTP de cette forme :

curl 'https://smsapi.free-mobile.fr/sendmsg?user=***&pass=***&msg=coucou'

Vous recevez alors sur votre téléphone Free-mobile le SMS contenant le message "coucou".

La création d'un message multiligne est un peu plus délicate. La plupart des plateforme Unix/Linux envoie en guise de séparateur de ligne un \n qui se traduit par %0a une fois "url-encodé". Malheureusement, l'API n'accepte pas ce %0a et le message sera tronqué à la première occurrence.
Par contre, le séparateur de ligne \r, encodé en %0d est bien accepté par l'API Free-mobile. Il faut donc, avant d'envoyer un message sur plusieurs lignes, traduire les \n en \r.

J'ai conçu un script shell pour mes besoins personnels. Il prend ses données en entrée standard, par exemple via un pipe :

echo "mon message" | sms.sh

Ce qui est plus souple pour moi dans bien des situations, que de devoir invoquer le script et de lui servir le message comme argument, par exemple :

autresms.sh mon message

Voici donc le code de mon script qui prend les messages via stdin, et qui converti les \n en \r. Notez que le SMS à l'arrivée ne contient pas de saut de ligne, donc prévoyez des espaces en fin de ligne si vous ne voulez pas que la fin de ligne soit collée au début de la ligne suivante.

#!/usr/local/bin/bash  
#
# push notification via smsapi.free-mobile.fr
#
LOGGEROPT="-p security.notice -t SMS"
REPLOGG=1
REPMAIL=1
MAILTO=root
USR="****"
PSW="****"
URL="https://smsapi.free-mobile.fr/sendmsg"
CURL=/usr/local/bin/curl

report() {
        [ ${REPLOGG} -eq 1 ] && echo $@ | logger ${LOGGEROPT}
        [ ${REPMAIL} -eq 1 ] && echo $@ | mail -s "SMS $@" ${MAILTO}
}

eval $(${CURL} --insecure -G --write-out "c=%{http_code} u=%{url_effective}" \
        -o /dev/null -L -d user=${USR} -d pass=${PSW} --data-urlencode msg="$(cat|tr '\n' '\r')" ${URL} 2>/dev/null | tr '&' ';')

echo ${c} ${u}\&pass=***\&msg=${msg} | logger ${LOGGEROPT}

case ${c} in
        "200")
                exit 0
                ;;
        "400")
                report "parameter missing" ; exit 400
                ;;
        "402")
                report "too many SMS..." ; exit 402
                ;;
        "403")
                report "service unavailable for user, or wrong credentials" ; exit 403
                ;;
        "500")
                report "server error, try later" ; exit 500
                ;;
        *)
                report "unexpected result" ; exit 600
                ;;
esac

Utilisation :

echo "mon message 
sur plusieurs 
lignes" | sms.sh

Il reste à faire :
- ajouter l'enregistrement dans les log système de chaque utilisation du script sms.sh
- ajouter la gestion des codes de retour HTTP autres que 200.

Attention
Pour bénéficier d'une gestion d'erreur et d'une trace dans les log de la machine j'ai utilisé une grosse ruse très sale avec eval. Cela permet de créer des variables à la volée à partir de données fournie par l'utilisateur. C'est éminemment risqué car tout ce est qui généré par c=%{http_code} u=%{url_effective} sera évalué sans distinction (avec potentiellement des exécutions de code).
Pour un système de monitoring c'est un risque négligeable : les messages sont connus et fixés par le logiciel qui les génère, sans interaction avec l'utilisateur. Pour une utilisation dans tout autre mécanisme la prudence est requise.

Une adresse email pour chaque contact ?

Depuis de nombreuses années j'ai pris l'habitude de créer une adresse email spéciale pour (presque) chaque site web sur le quel je m'inscris. D'une part cela apporte un bénéfice de sécurité immédiat car il est courant que l'adresse email soit aussi le login pour un système d'authentification sur le site en question. Donc ce login est différent pour chaque site.
D'autre part, cela me permet de cloisonner le spam, et de détruire sans aucun état d'âme toute adresse email qui serait un peu trop "publique". Au quotidien, c'est aussi un excellent moyen de savoir qui distribue votre adresse email, et qui la garde pour lui comme promis.

Le cas s'est présenté précédemment avec l'adresse email que j'utilisais pour l'association des anciens de mon école d'ingénieurs. Quand j'ai commencé à recevoir de la publicité pour du vin, j'ai détruit l'adresse. Maintenant il ne leur reste que mon adresse postale, ce qui leur pose quelques soucis. Il fallait y penser avant de faire n'importe quoi avec l'annuaire.
Le cas que je souhaite évoquer ici est un peu plus grave. Il s'agit du photographe Zack Arias et de sa liste OnelightWorkshop.
Il a créé sa liste de diffusion d'information au sujet de ses ateliers fin 2009 ou début 2010. Et je m'y suis inscrit presque aussitôt. Il annonce d'ailleurs sur son site :

Sign up on our email list for news about the workshop. We promise not to spam you or pass your information on to any third party. You can expect about 4 emails a year from us… at most.

4 emails par an, c'est à peu prêt vrai, si on s'en tient aux messages légitimes. Par contre, pour le reste, il y a comme un souci. J'hésite entre négligence criminelle, "je-m'en-foutisme", ou grossière escroquerie. Quoi qu'il en soit, moins de 15 jours après le premier message légitime, le spam a commencé à arriver. Les chiffres sont, ces derniers temps, plutôt alarmants :

spam volume per month

Le nombre de messages légitimes est juste invisible sur ce graphique, tellement la masse de spam est importante. Je ne m'en suis aperçu que très tardivement, car mon antispam fait très bien son travail, mais je vais de ce pas détruire cette adresse email.

Maintenant on peut se demander comment ce photographe protège ses clients, leurs données personnelles bien sûr, mais aussi les travaux en cours, les photo confidentielles ou qui devraient rester à jamais privées. Savoir gérer un business de nos jours, c'est aussi savoir répondre efficacement à toutes ces problématiques de sécurité des informations, de protection des données personnelles.
Je suis sûr d'une chose : je ne fournirai plus aucune donnée personnelle à M. Arias.

Log aggregation and analysis: logstash

Logstash is free software, as in beer and speech. It can use many different backends, filters, etc. It comes packaged with Elasticsearch as a backend, and Kibana as user interface, by default. It makes a pleasant package to start with, as it's readily available for the user to start feeding logs. For your personal use, demo, or testing, the package is enough. But if you want to seriously use LS+ES you must have at least a dedicated Elasticsearch cluster.

apache-log-logstash-kibana

Starting with Logstash 1.4.0, the release is no longer a single jar file. It's now a fully browsable directory tree allowing you to manipulate files more easily.
ELK (Elasticsearch+Logstash+Kibana) is quite easy to deploy, but unlike Splunk, you'll have to install prerequisites yourself (Java, for example). No big deal. But the learning curve of ELK is harder. It took me almost a week to get some interesting results. I can blame the 1.4.0 release that is a bit buggy and won't start-up agent and web as advertised, the documentation that is light years away from what Splunk provides, the modularity of the solution that makes you wonder where to find support (is this an Elasticsearch question? a Kibana problem? some kind of grok issue?), etc.

Before going further with functionalities lets take a look at how ELK works. Logstash is the log aggregator tool. It's the piece of software in the middle of the mess, taking logs, filtering them, and sending them to any output you choose. Logstash takes logs through about 40 different "inputs" advertised in the documentation. You can think of file and syslog, of course, stdin, snmptrap, and so on. You'll also find some exotic inputs like twitter. That's in Logstash that you will spend the more time initially, tuning inputs, and tuning filters.
Elasticsearch is your storage backend. It's where Logstash outputs its filtered data. Elasticsearch can be very complex and needs a bit of work if you want to use it for production. It's more or less a clustered database system.
Kibana is the user interface to Elasticsearch. Kibana does not talk to your Logstash install. It will only talk to your Elasticsearch cluster. The thing I love the most about Kibana, is that it does not require any server-side processing. Kibana is entirely HTML and Javascript. You can even use a local copy of Kibana on your workstation to send request to a remote Elasticsearch cluster. This is important. Because Javascript is accessing your Elasticsearch server directly, it means that your Elasticsearch server has to be accessible from where you stand. This is not a good idea to let the world browse your indexed logs, or worse, write into your Elasticsearch cluster.

To avoid security complications the best move is to hide your ELK install behind an HTTP proxy. I'm using Apache, but anything else is fine (Nginx for example).
Knowing that 127.0.0.1:9292 is served by "logstash web" command, and 127.0.0.1:9200 is default Elasticsearch socket, your can use those Apache directives to get remote access based on IP addresses. Feel free to use any other access control policy.

ProxyPass /KI http://127.0.0.1:9292 
ProxyPassReverse /KI http://127.0.0.1:9292 
ProxyPass /ES http://127.0.0.1:9200 
ProxyPassReverse /ES http://127.0.0.1:9200 
<Location /KI>
	Order Allow,Deny
	Allow from YOUR-IP 127.0.0.1
</Location>
<Location /ES>
	Order Allow,Deny
	Allow from YOUR-IP 127.0.0.1
</Location>

original data in µs, result in µs. Impossible to convert in hours (17h09)

original data in µs, result in µs. Impossible to convert in hours (17h09)

On the user side, ELK looks a lot like Splunk. Using queries to search through indexed logs is working the same, even if syntax is different. But Splunk allows you to pipe results into operators and math/stats/presentation functions… ELK is not really built for complex searches and the user cannot transform data with functions. The philosophy around Kibana is all about dashboards, with a very limited set of functions. You can build histograms, geoip maps, counters, compute some basic stats. You cannot make something as simple as rounding a number, or dynamically get a geolocation for an IP address. Everything has to be computed through Logstash filters, before reaching the Elasticsearch backend. So everything has to be computed before you know you need it.
Working with Logstash requires a lot of planing: breakdown of data with filters, process the result (geoip, calculation, normalization…), inject into Elasticsearch, taylor your request in Kibana, create the appropriate dashboard. And in the end, it won't allow you to mine your data as deep as I would want.
Kibana makes it very easy to save, store, share your dashboards/searches but is not very friendly with clear analysis needs.

Elasticsearch+Logstash+Kibana is an interesting product, for sure. It's also very badly documented. It looks like a free Splunk, but its only on the surface. I've been testing both for more than a month now, and I can testify they don't have a lot in common when it comes to use them on the field.

If you want pretty dashboards, and a nice web-based grep, go for ELK. It can also help a lot your command-line-illeterate colleagues. You know, those who don't know how to compute human-readable stats with a grep/awk one-liner and who gratefully rely on a dashboard printing a 61 billions microseconds figure.
If you want more than that, if you need some analytics, or even forensic, then odds are that ELK will let you down, and it makes me sad.

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.

oh-crap

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...

heartbleed

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

Software versions:

Metasploit
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.