Sujets-libres.fr

Informatique, logiciels libres, internet, humeurs et… le reste !

Bienvenue à Bonemine

Rédigé par -Fred- Aucun commentaire

Après plusieurs années de bons et loyaux services, Abraracourcix, mon modeste serveur va passer la main à Bonemine. La config de cette nouvelle machine est la suivante :

  • Athlon 5150
  • 8Go de DDR3
  • DD de 1To
  • Alim Corsair 350W
  • GNU/Linux Debian 8

La config n'est pas monstrueuse mais amplement suffisante pour accueillir plusieurs machines virtuelles. La préparation du serveur va prendre quelques jours mais je devrais pouvoir le mettre en production début juillet si tout va bien.

Un changement de machine est l'occasion de refaire les choses proprement. L'utilisation de machines virtuelles va notamment me permettre d'en dédier à certains usages et donc de mieux cloisonner les différents services que j'utilise. Ceci dit, cela fait plus de machines à administrer au quotidien. Je dois donc encore choisir l'outil qui me permettra de garder un œil sur tout ça. Aujourd'hui, j'utilise Munin pour surveiller l'activité d'Abraracourcix mais je vais quand même faire le tour des solutions existantes pour trouver la plus adaptée.

Abraracourcix ne sera pas totalement démobilisé. Une fois que Bonemine sera en production, il sera reconfiguré pour resservir au cas où Bonemine venait à défaillir (il vaut mieux prévenir que guérir :p ).

Mise à jour blog vers PluXml 5.5

Rédigé par -Fred- Aucun commentaire

Le blog évolue et passe de PluXml 5.4 à PluXml 5.5 . La mise à jour s'est effectuée sans incident. Une fois les nouveaux fichiers copiés (tous sauf les répertoires /data, /plugins et /themes, ainsi que le fichier config.php) et leurs droits vérifiés, il suffit de se rendre sur le blog et d'exécuter la mise à jour proposée afin de finaliser la migration. C'est tout.

J'apprécie toujours autant la simplicité d'utilisation de ce CMS. Merci donc aux contributeurs.

Page officielle du projet : www.pluxml.org

Blog compromis, ma réponse à l'incident

Rédigé par -Fred- 2 commentaires

Je vois peu de retours d'expérience concrets sur le net, alors je vais vous livrer le mien. Je ne suis pas spécialiste de la question. Mon analyse est donc probablement imparfaite ou incomplète. Toutefois, je le fais pour plusieurs raisons :

  • Les quelques visiteurs qui passent ici doivent savoir si mon blog est, ou a été, à risque.
  • Communiquer sur un cas réel me semble intéressant. Il est désagréable de parler de son propre cas mais au moins, j'ai accès à toutes les informations.
  • Si je suis en mesure de faire des erreurs, je ne dois pas être le seul. Expliquer quelles ont été mes erreurs pour que d'autres ne les commettent pas ne peut être que bénéfique.
  • Donner la possibilité à mes visiteurs de me faire un retour, notamment sur ma manière de réagir à cet événement, sera peut être pour moi l'occasion de progresser.

Analyse

Comment cela a été possible ?

J'ai passé un peu plus de temps à analyser mes logs et les seules informations que j'ai pu trouver se trouvent dans les logs d'apache. Rien ailleurs et pour cause, les faits datent du 5 novembre 2014. Il n'y a donc plus rien à voir dans les autres logs depuis longtemps.

Je constate donc une forte activité de la part de l'attaquant le 5 novembre 2014, date à laquelle l'un des fichiers a été déposé et exploité. Le fichier en question est un script php déposé dans un répertoire que j'avais créé manuellement à la racine de mon blog wordpress (pas grand chose dans ce dossier à part des photos présentes sur mon blog et quelques bricoles).

Je suspecte donc que l'un des plugins ou l'un des thèmes utilisé sur mon blog contenait une faille permettant l'upload de fichiers. Je précise toutefois que les plugins et thèmes utilisés proviennent tous de sources officielles (trouvés et installés via le panel d'administration du blog). J'écarte peut être trop vite Wordpress lui même mais dans le mesure où il se met à jour automatiquement, les failles connues sont comblées rapidement. Sauf à exploiter une 0 Day, c'est donc peu probable.

Certains répertoires avaient aussi des autorisations trop élevées. Je ne pense pas que ce soit du fait de l'attaquant mais plutôt moi qui a certainement un jour modifié cela (suite probablement à un problème de mise à jour wordpress).

Les logs montrent par ailleurs que pour lister les failles de mon blog et de quelques sites hébergés sur mon serveur, l'attaquant à utiliser au moins un outil open source de recherche de vulnérabilités web. L'outil en question est intéressant pour deux raisons. D'une part, il permet d'auditer ses propres sites, et d'autre part, il me permet de comprendre certains comportement étranges de mon serveur il y a quelques mois (CPU serveur chargé à presque 100% à cause d'un nombre anormal de processus apache2). J'ai donc compris que mon serveur avait fait l'objet de scans en vue d'y trouver des vulnérabilités.

A quoi servaient ces fichiers ?

Le premier fichier n'était clairement fait pour ne pas être lisible facilement (instructions codées en ascii, codes en base64, gzinflate...). Une fois décodé, il montre un peu plus ce à quoi il est destiné car il contient tout un tas de commandes permettant notamment de rechercher des fichiers sensibles du système (utilisable en environnement *nix ou windows). J'ai exécuté le fichier en machine virtuelle dans firefox (avec le module firebug) et je vois qu'il tente de se connecter à des ressources dispo sur un site externe (je continue à essayer de comprendre plus de ce côté là).

L'exécution du scripts en question en machine virtuelle montre qu'il tente de communiquer avec un serveur distant. Le domaine de ce serveur est en .ro . A ce que je peux voir rapidement, ce serveur héberge un certain nombre d'outils permettant le piratage de sites web.

Un autre fichier a été déposé plus récemment (fin juillet) et contient un exploit selinux. Un autre répertoire contient, si je comprend bien, un outil d'analyse open source. Je ne trouve pas de trace quand à l'utilisation de l'un ou l'autre de ces outils, contrairement à l'autre outil dont je parle au dessus et pour lequel je peux voir que l'attaquant l'a utilisé environ 1h sur ma machine.

Comprendre ce qui a été fait et les motivations

Je constate que l'attaquant a possiblement disposé d'une bonne vue de la structure des différents sites hébergés sur mon serveur et accessibles. Il ne me semble pourtant pas que des dégâts aient été fait. Rien non plus en base de donnée (en tout cas, s'il y a eu quelque chose à une époque, il n'en reste rien).

Actions

Actions curatives

Comme détaillé dans un billet récent, j'ai très rapidement vérifié que ma base de donnée Wordpress était saine. J'ai ensuite réinstallé une instance toute propre de Wordpress sans aucuns plugins, histoire d'avoir une solution fonctionnelle le temps de trouver une solution plus durable et plus sûre pour mon blog. La solution retenue a donc été de passer à Pluxml car l'outil correspond parfaitement à mes besoins.

Actions préventives

Pour ne pas avoir à subir un nouvel épisode de ce type, j'ai décidé d'être plus strict au niveau de la gestion de mon serveur. J'ai donc déjà nettoyé et réduit au maximum le nombre de services ouverts sur l'extérieur. Que ces autres services n'aient pas été touchés aujourd'hui ne signifie pas qu'ils ne le seront pas à l'avenir ou qu'ils ne puissent pas donner d'informations à d'éventuels attaquants. Certains services utiles ne sont plus ouverts qu'en local (munin notamment) et d'autres sont tout simplement fermés (webmail rainloop). Au niveau Web, je n'ai conservé sur l'extérieur que ce blog et deux pages statiques.

J'effectue à présent un suivi de l'activité de mon serveur de manière plus stricte. Je suis en train de réfléchir à automatiser ce qui peut l'être et qui est spécifique à mon installation. J'ai un peu chamboulé mon programme de pré-rentrée afin de remettre un peu d'ordre là où c'était nécessaire.

Conclusions

Mes erreurs ont été multiples. Je considère avoir globalement été trop laxiste, que ce soit au niveau de mes réglages apache qu'au niveau des services ouverts sur ma machine. Peu regardant aussi sur l'activité de mon blog. J'aurais, si j'avais bien fait les choses, dû voir immédiatement l'arrivée de ces fichiers.

Je considère avoir eu de la chance. Cette expérience m'a permis de connaitre l'existence d'outils intéressants d'audit de sites web. Je vois d'ailleurs mieux comment se comporte mon serveur lorsqu'il fait l'objet d'une analyse par ce type d'outil.

J'ai aussi pris conscience de l'importance des logs. Il est donc essentiel d'être réactif, sous peine de ne pas avoir de données exploitables. Se faire poutrer une fois, ça peut arriver. Ne pas avoir les éléments pour réagir, c'est l'assurance que ça arrivera une seconde fois.

Les marketeux n'ont que ça à faire

Rédigé par -Fred- 2 commentaires

Je suis tombé par hasard sur le site suivant : http://www.watchshop.fr/

Si ça vous dit, visitez ce site et si vous le faites, je pourrai vous classer dans deux catégories distinctes :

  • Celle de ceux qui n'en penseront pas grand chose, hormis que c'est un site où on vend des montres.
  • Celle de ceux qui vont voir un truc flou.

Si comme moi, cher visiteur, tu penses que ta vue a très sérieusement baissé depuis le dernier site que tu as visité, saches que tu l'as bien cherché. Oui, car tu as osé naviguer sur le web sans activer javascript...

Le procédé est assez simple : si javascript est désactivé, une css est activée et floute la page, laissant simplement deviner ce qu'on rate (flou, mais pas trop). Si vous voulez voir comment c'est fait, affichez la source de la page en question et regardez ce qui se trouve après cette balise <noscript id="nojs">. Bien entendu, le site redevient lisible lorsque l'on applique aucun style. Moche, certes, mais lisible.

Donc en gros, d'un côté javascript peut poser des problèmes de sécurité et un internaute a le droit de décider de le désactiver, quitte à perdre en fonctionnalités sur certains sites visités. De l'autre, un site qui, volontairement, devient totalement inopérant pour les visiteurs qui osent désactiver javascript. C'est potentiellement incompatible tout ça.

Pourquoi est-ce un problème ?

Je suis le seul à même de décider si j'active ou non telle ou telle fonctionnalité sur ma machine. J'ai fait le choix de désactiver javascript par défaut et de l'activer au cas par cas. Si Mme Michu désire naviguer avec javascript ou n'importe quoi d'autre d'activé en permanence, c'est son problème.

Parce que c'est totalement volontaire. Je me fout des raisons qui ont poussé à mettre un truc pareil en place. Des personnes ont dépensé de l'énergie et du temps à coder cette petite cochonnerie.

Je me met à la place de l'internaute lambda qui aura tout de même pris soin de désactiver l'exécution de javascript dans son navigateur. Comment il fait l'internaute rien que pour savoir que ce site "requiert" javascript pour simplement être lisible ? Il n'y a pas un seul message d'alerte ou quoi que ce soit d'autre à se mettre sous la dent.

Quand on y est arrivé (mettons qu'on affiche un truc lisible en désactivant la feuille de style), ce n'est écrit nul part bordel. D'ailleurs, ce n'est pas non plus écrit clairement dans la source de la page.

En bonus, c'est pas comme si appliquer un flou gaussien comme ça à la volée ça ne consommait pas un peu de ressources. Sur ma machine, Firefox utilise 100% du CPU dès que je scroll un peu sur la page floutée.

A quoi ça sert ?

J'imagine que l'amélioration de l'expérience utilisateur, encore elle, permet de justifier le procédé. J'imagine surtout que ça permet de s'assurer que le comportement de chaque visiteur sera traçable. C'est désagréable les visiteurs qui ne laissent pas autant de données que prévu lorsqu'ils visitent une boutique, n'est-ce pas ?

Fil RSS des articles de ce mot clé