Gregory Colpart's blog

Voilà maintenant une semaine a été révélée la faille Heartbleed touchant certaines versions récentes de la bibliothèque OpenSSL. OpenSSL est un Logiciel Libre notamment utilisé pour les protocoles sécurisés HTTPS ou IMAPS. Cette faille a été surmédiatisée et plusieurs clients nous ont interrogé à ce sujet. Même si cela date un peu, il s’avère plus pratique et plus transparent de mettre nos réponses sur ce blog.

Qu’est-ce que la faille Heartbleed ?

Il s’agit d’une faille de sécurité touchant OpenSSL permettant d’accéder à une partie (64 Ko) quasi-aléatoire de la mémoire d’une application via le protocole SSL/TLS. Cela concerne évidemment les services utilisant SSL/TLS accessibles publiquement comme HTTPS, IMAPS, POPS, SMTPS ou encore SMTP over TLS. Cela peut aussi concerner les logiciels client faisant des requêtes via SSL/TLS sur des serveurs malicieux.

La partie de la mémoire dévoilée étant plus ou moins aléatoire, on peut considérer que de multiples requêtes permettent de révéler l’ensemble de la mémoire de l’application concernée. Cela concerne évidemment la clé privée SSL utilisée mais les autres données système et applicative chargée en mémoire par l’application (mot de passe d’une base de données, contenu de /etc/passwd, contenu d’une base de données, etc.). Certains experts affirment même que l’ensemble de la mémoire d’une machine impactée pourrait être accessible.

Mon serveur infogéré par Evolix a-t-il été concerné ?

Nous gérons des serveurs avec le système Debian GNU/Linux. Les serveurs utilisant Squeeze (Debian 6) ne sont pas impactés. Les serveurs utilisant Wheezy (Debian 7) sont directement concernés si ils ont un service HTTPS ou  POPS/IMAPS ou SMTP publiquement accessibles, et indirectement si ils peuvent faire de nombreuses requêtes SSL/TLS vers des serveurs non sûrs situés à l’extérieur.

Mon serveur infogéré par Evolix a été concerné, que dois-je faire ?

La faille a été révélée lundi 7 avril 2014 vers 21h. Nous nous sommes penchés sur cette faille à partir de 00h15 (bug signalé sur notre IRC privé, merci Arnaud) et nous avons mis à jour tous les serveurs directement concernés dans les heures qui ont suivi et le lendemain. Votre serveur n’est donc plus vulnérable. Mais il a pu l’être pendant au moins quelques heures. Une analyse du trafic réseau et des logs suspects (connexions STARTTLS via SMTP, requêtes HTTPS sans contenu, etc.) nous laissent penser qu’il n’y a pas eu d’attaque sur ce laps de temps. Cela étant dit, par principe de précaution et car dans tous les cas cela doit être fait régulièrement, nous conseillons tout de même de renouveler toutes les informations secrètes sur les serveurs directement impactés (mots de passe, clés privées, etc.). Vous devez également relancer toutes les applications qui utilisent libssl (démons en Python ou Ruby, etc.).

Et sur mon poste de travail, que dois-je faire ?

Vous devez mettre-à-jour vos postes de travail immédiatement. Avant de vous connecter à un site en HTTPS, vous pouvez vérifier qu’il n’est plus vulnérable. Il est également conseillé de renouveler vos mots de passe sur les différents services en ligne (notamment Google, Github, Facebook, Twitter, Amazon…) : de toutes façons vous devez le faire régulièrement, c’est donc une bonne occasion de le faire !

Des conclusions à tirer de cette affaire ?

Il n’y a rien de vraiment nouveau, si ce n’est qu’il est désormais difficile d’ignorer que :
– l’application régulière des mises-à-jour de sécurité est essentielle, vous ne pouvez pas vous contenter d’installer un serveur et ne pas vous en occuper, surtout si il est accessible publiquement ;
– vous devez exposer publiquement le moins de choses possibles : cela passe par un firewall qui va restreindre un maximum de services par adresse IP, et par la désactivation de tous les fonctionnalités inutiles (avez-vous vraiment besoin d’Apache/SSL si votre site web ne tourne pas en HTTPS ?  l’activation de STARTTLS sur votre Postfix est-elle vraiment nécessaire ?) ;
– toutes les informations secrètes doivent être changés régulièrement (clés privés, mots de passe, certificats, etc.) et changeables rapidement en cas de besoin… l’utilisation d’un gestionnaire de mot de passe étant indispensable.

L’équipe Evolix a récemment découvert un bug assez incroyable : les versions 5.1 à 5.6.8 de MySQL ne gèrent pas le Query Cache (un mécanisme essentiel) sur les tables InnoDB si le nom de la table ou base contient un caractère particulier, notamment le tiret (–) !! Ce n’est pas une véritable découverte car le bug a été corrigé pour la version 5.6.9 en décembre 2012, mais il a été peu « médiatisé » et surtout il impacte de nombreuses distributions Linux. Concrètement si vous avez Debian (Squeeze/Wheezy/Testing/Sid) ou Ubuntu (toutes les versions depuis 4 ans) et vous utilisez le paquet mysql-server, toutes vos bases ou tables nommées foo-bar sont impactées. Toutes vos requêtes sensées être servies par le cache MySQL ne le sont pas, et il en découle des problèmes de performance (parfois très significatifs). Au passage, pour vérifier qu’une requête MySQL utilise bien le Query Cache, vous pouvez observer le compteur de hits via show status like ‘Qcache_hits’ (parfois difficile sur des serveurs en production, mais vous avez bien sûr des serveurs de préproduction ;-).

Mise en évidence du bug avec un nom de base foo-bar :

mysql> create database `foo-bar`;
mysql> create table `foo-bar`.baz (a int) engine=InnoDB;
mysql> insert into `foo-bar`.baz values (1);
mysql> select * from `foo-bar`.baz;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+
mysql> select * from baz;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+

Mise en évidence du bug avec un nom de table baz-qux :

mysql> create database foobar;
mysql> create table foobar.`baz-qux` (a int) engine=InnoDB;
mysql> insert into foobar.`baz-qux` values (1);
mysql> select * from foobar.`baz-qux`;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+
mysql> select * from foobar.`baz-qux`;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+

Si vous n’êtes pas encore parti en courant vérifier le nom de vos bases et tables MySQL/MariaDB, je vais vous expliquer comment ce bug a été découvert et pourquoi cela illustre bien le travail d’infogérance d’Evolix. En effet, un abonnement à l’infogérance est une sorte d’assurance : outre les opérations visibles (surveillance 24/24, veille technologique, mises-à-jour, support technique), c’est aussi la garantie que l’on mettra tout en œuvre si il vous arrive un incident. Pendant plusieurs mois/années vous n’aurez peut-être pas d’incident sérieux (et tant mieux pour tout le monde), mais un jour vous aurez besoin d’une attention de plusieurs heures voire plusieurs jours. C’est ce qui est arrivé ces dernières semaines avec ce bug MySQL : un client d’Evolix a signalé une lenteur sur certaines pages d’un site d’e-commerce suite à une migration de serveurs. Après pas mal d’analyses, nous n’étions pas convaincus, la lenteur s’expliquait par des milliers de requêtes SQL faites sur chaque page, et surtout cette lenteur était également présente sur l’ancien serveur. Néanmoins, nous avons fini par découvrir que sur un très vieux serveur en Debian Lenny, les pages étaient moins lentes. Après de nombreux tests (passage en SSD, utilisation de TMPFS pour éliminer les I/O disque, tests sur différents serveurs dont un ultra puissant, strace des process, etc.), nous avons mis en évidence que l’exécution des milliers de requêtes SQL étaient tout simplement plus rapides sur le très vieux serveur en Debian Lenny. Ce constat était un peu effrayant pour nous, et presque tout l’équipe s’est mis sur ce problème. On a identifié que les requêtes n’utilisaient pas le Query Cache, et l’on a donc relu toute la documentation concernant le cache MySQL… mais rien à faire, des requêtes SQL simples n’étaient toujours pas mises en cache. Même résultats avec MySQL 5.1/5.5 ou MariaDB 5.5. Puis l’on a découvert ce fameux bug : la base concernée ayant un tiret dans son nom, on l’a fébrilement renommée et *bingo* les requêtes sont désormais cachées !

En attendant une éventuelle correction du bug par Debian, nous conseillons de renommer vos bases et tables impactées. Au passage, le tiret (–) est un caractère particulier pour MySQL et il est préférable de prendre l’habitude d’utiliser l’underscore (_) dans le nom de vos bases et tables.

J’ai le plaisir de vous informer d’une augmentation du capital social d’Evolix, passant d’un montant de 7.500 EUR à 105.000 EUR.

Cette opération a été réalisée en incorporant une partie des profits des dernières années, c’est-à-dire que la répartition du capital reste inchangée : entièrement détenu par Sébastien Dubois et moi-même. Concrètement c’est surtout un moyen de démontrer notre bonne gestion et solidité financière. Nous hébergeons et infogérons des infrastructures web critiques, et la confiance et la stabilité sont des critères importants pour nos clients actuels et futurs. Grâce à cette augmentation de capital et notre croissance régulière (CA de 650k en 2012), l’objectif est de parvenir dans les prochaines années à un chiffre d’affaires d’un million d’euro. Cette ambition maîtrisée vise à poursuivre notre évolution tout en restant fidèles à nos convictions basées sur les valeurs des Logiciels Libres et la stratégie de rester une équipe à échelle humaine : croître « lentement mais sûrement ».

Pour sa 10ème année d’existence, Evolix prouve ainsi être devenue une entreprise stable et pérenne.

Une coutume s’est installée depuis quelques années dans le monde de la messagerie : mettre en place des alias ou redirections de messagerie. Le problème c’est lorsque ces redirections sont d’un domaine vers un autre. Exemple typique : j’achète un nom de domaine “monnouveausite.com” et je crée une redirection de contact@monnouveausite.com qui renvoie vers ma messagerie Orange/Hotmail/Gmail/Free/Yahoo. C’est mal… il faut vraiment éviter de faire cela !

Pourquoi c’est mal ? Car votre alias va inévitablement finir par recevoir du spam. Et ce spam sera donc redirigé “tel quel” des serveurs gérant les MX de “monnouveausite.com” vers Orange/Hotmail/Gmail/Free/Yahoo. Du coup, Orange/Hotmail/Gmail/Free/Yahoo vont identifier les MX comme étant des relais de spams et blacklister ces serveurs ! C’est d’autant plus vrai avec les politiques antispam de plus en plus strictes d’Orange ou Yahoo par exemple.

Alors que faire ? Plusieurs éléments de réponses :
– Évitez d’avoir une messagerie chez Orange/Hotmail/Gmail/Free/Yahoo ! Hotmail ne respecte les standards, Gmail ne répond JAMAIS aux demandes sur abuse@, Yahoo et Free ont une politique antispam trop violent, etc. bref, il y a de nombreuses raisons à avoir une messagerie auto-hébergée par vous, vos amis ou des petites entreprises comme Evolix.
– Créez de vrais comptes mail pour héberger “monnouveausite.com” et récupérez les en POP/IMAP/webmail.
– Si vous désirez vraiment centraliser différentes adresses sur une seule messagerie, utiliser une récupération automatique en POP ou IMAP. Si vous avez une messagerie Open Source, vous pouvez utiliser le logiciel libre fetchmail qui récupèrera pour vous tous vos messages. À défaut, si confier vos mots de passe au FBI ne vous fait pas peur, vous pouvez utiliser un service de récupération de messages comme celui de Gmail.

Pour faire face au succès de notre nouvelle offre de location de serveurs dédiés infogérés, nous avons réfléchi depuis plusieurs mois avec un fond d’investissement qatari pour racheter l’ensemble du datacenter SFR de Marseille. Situé à quelques minutes de nos bureaux, ce datacenter est idéalement placé et va permettre une croissance rapide de nos offres d’hébergement. Nous détaillerons toutes les conséquences de cette acquisition dans les prochains jours, mais nous avons voulu partager au plus tôt l’annonce de cette opération exceptionnelle !