Sujets-libres.fr

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

Planet auto-hébergement

L'auto-hébergement garde-t-il du sens si le plus important n'y est pas ?

Rédigé par -Fred- / 04 janvier 2017 / 13 commentaires

Récemment, Genma a publié un article au sujet de l'impact de diverses coupures électriques sur son activité auto-hébergée : Coupure-de-courant-et-auto-hebergement. Diverses idées sont développées dans ce billet mais celle qui a retenu mon attention est la suivante : L'auto-hébergement c'est bien mais il ne faut pas le faire pour les services sensibles et desquels on est fortement dépendant. J'ai bien entendu laissé un commentaire sur son blog mais je trouvais justifié de développer un peu plus mon point de vue ici.

En gros, le blog et le mail seraient à ne pas héberger derrière une ligne ADSL car on ne peut se permettre soit un blog inaccessible, soit la non réception de ses mails. On a chacun des priorités variables mais je conçois aussi que ces deux usages soient importants. Dans le cas des coupures électriques à répétition il est évident que ça perturbe fortement l'activité de ces services et que si c'est prolongé, ça fini par causer des pertes définitives de données. Typiquement, vous commencez à perdre des messages si votre serveur mail n'est pas en mesure de les réceptionner pendant plusieurs jours d'affilée et dans la mesure du possible, il est préférable d'éviter ça. A l'inverse les divers services moins importants peuvent être auto-hébergés.

J'ai en fait une approche diamétralement opposée et forcement, j'en arrive à préconiser à peu près l'inverse. J'ai décidé de m'auto-héberger, non pas pour tester des services mais parce que j'ai éprouvé le besoin de reprendre le contrôle de mes données personnelles, notamment le mail. J'ai alors décidé de m'auto-héberger. Forcement de mon point de vue, l'auto-hébergement perd fortement de son sens si on décide de ne pas y stocker les données que l'on a de plus précieuses.

Alors oui, le faire soit même présente des risques car on a rien sans rien. Il faut cependant se donner les moyens de ses ambitions. Dans des billets de blog divers et variés, je vois que certains peuvent utiliser des machines peu fiables pour faire de l'auto-hébergement (typiquement des Raspberry Pi avec un système sur carte SD). Sur le principe bon, pourquoi pas, c'est amusant et très formateur. Le côté Geek en plus, c'est cool aussi.

Pourtant quand on se lance là dedans pour vraiment rapatrier ses données personnelles, le jeu doit être pensé sérieusement dès le départ. Grossièrement, il faut déjà penser à se faire son analyse de risques puis identifier ceux qui sont les plus impactants et corriger ce qui doit vraiment l'être par des actions les plus efficientes possible. Et comme on pense à l'avenir, et bien on planifie ce qui n'aura pas pu être mené immédiatement tout en prévoyant des mesures palliatives si d'aventure le pire devait arriver.

Dans le cas de multiples coupures électriques de quelques heures il est assez simple d'évaluer l'impact que ça peut avoir sur ses services auto-hébergé. On peut alors apprécier les risques encourus : perdre des visiteurs de blog ? voir ses mails arriver avec 1 jour de retard ? Perdre carrément des mails ? Risquer de la casse matérielle ? Perte définitive des données stockées ? Risque très probable d'avoir d'autres priorités que les services auto-hébergés à gérer lorsque la coupure survient ? Tout ça est prévisible et si on pense son auto-hébergement sérieusement on peut immédiatement éliminer certains risques, atténuer les effets encourus par d'autres risques et dans tout les cas avoir une meilleure vue sur l'ensemble des risques résiduels. Le tout encore une fois, c'est de penser ce jeu de manière sérieuse car le risque, ça se gère.

Je pense que différentes motivations poussent à s'auto-héberger. Je me garderai bien d'être catégorique sur ce qu'il convient ou non de faire. La seule chose sur laquelle il faut à mon sens être clair quand on parle d'auto-hébergement, ce sont justement les motivations qui conduisent à s'y essayer. Ça aide à mettre en perspective les propos des uns et des autres et à les replacer dans le bon contexte. Les propos de Genma sont tout à fait pertinent dans son contexte et, à mesure que j'y réfléchi, pas du tout dans le mien.

Ce que je n'hébergerai pas sur mon serveur

Rédigé par -Fred- / 12 septembre 2016 / 6 commentaires

Souvent, les auto-hébergés (comme moi) partagent leurs dernières trouvailles et en règle générale tout ce qui peut présenter un intérêt pour d'autres dans ce domaine. J'ai donc trouvé amusant de prendre un peu le contre-pied de cette approche et de parler de ce que je n'hébergerai pas (ou plus) chez moi.

Un webmail

Il n'y a pas si longtemps, j'en utilisais. D'abord Roundcube durant quelques années, puis ensuite Rainloop pendant quelques mois. L'un et l'autre faisaient le boulot. J'ai toutefois repensé un peu mon utilisation du mail et je suis arrivé à la conclusion que je n'avais pas besoin d'accéder à mes mails en dehors de chez moi. J'en reçois finalement assez peu et je n'ai jamais d'urgence à y accéder dans l'heure. Du coup, je n'y accède aujourd'hui qu'avec un client lourd, uniquement depuis un seul poste fixe chez moi. Ça peut sembler être très limité vu comme ça mais c'est très bien.

J'ajoute qu'avant, même si je n'avais pas un besoin vital de lire mes mails, je me connectais quand même à mon webmail depuis un peu partout. On se rend compte après coup que l'on consulte machinalement sa boite et que ça devient presque un TOC. Quelque part, c'est aussi une façon de montrer qu'on est pas l'esclave de ses mails.

Un CMS lourd

J'utilisais Wordpress précédemment mais là, ce dont je parle est plus global.

Ces outils offrent beaucoup de fonctionnalités, trop en tout cas par rapport à ce dont j'ai vraiment besoin. La question de leur pertinence vis à vis de mes usages propres s'est posée. Clairement, mon blog perso tel que je l'envisage, c'est pour y mettre du texte, quelques photos et de temps à autre, un petite vidéo ou deux. Pas besoin d'une usine à gaz pour le faire (ici par exemple, PluXML fait l'affaire sans soucis).

De base, ces outils sont complexes et donc plus sujets aux failles de sécurité (j'en ai fait les frais sur Wordpress). Constater qu'un outil qui se met à jour automatiquement et qui n'utilise que deux ou trois plugins officiels est tout de même piraté, c'est peu rassurant...

Un gros CMS peut devenir vraiment lourd, notamment si on lui ajoute de nombreux plugins ou quelques plugins mal configurés. L'intérêt d'un gros CMS tient pour beaucoup dans les grosses possibilités de configuration et de personnalisation qu'ils offrent. Le revers de la médaille, c'est que ces outils deviennent ainsi potentiellement plus sujets aux bugs, aux failles et plus consommateurs de ressources, ce qui peut dans ce dernier cas entraîner des lenteurs de chargement (dans certains cas extrêmes, ça peut rendre un blog totalement impraticable).

Des services, sur un coup de tête

On peut être tenté d'installer tout et n'importe quoi sur sa machine de prod, le temps d'essayer et de se forger un avis. Aujourd'hui, je peux faire mes tests sur une machine virtuelle dédiée, c'est plus propre et ne risque pas de mettre en péril l'activité des machines de prod.

En fait, si je décide de supprimer quelque chose que j'ai installé sur un coup de tête sur une machine en prod, je ne suis jamais certain que je retrouverai son serveur dans l'état exact d'avant installation. D'une part, je ne me fais pas à moi même une confiance absolue. Je suis un humain câblé à peu près normalement et je fais des erreurs. Je peux donc involontairement mal désinstaller une application ou laisser traîner un reliquat de configuration de l'application en question. D'autre part, si par le jeu des dépendances, l'installation d'un paquet a entraîné l'installation de d'autres paquets, je vais très probablement ne pas penser à les virer eux aussi lorsque j'aurai décidé de désinstaller le premier paquet. Ce n'est pas très propre.

Pour les services qui restent installés, il faut déjà penser à tous les tenir à jour. Plus il y en a, plus ça fait du boulot et plus ça augmente la surface d'attaque sur mon système auto-hébergé. Réduire la voilure n'est pas déconnant en fait..

Une connaissance

L'auto-hébergement, c'est en principe héberger ses propres données chez soit, sur un système qui est accessible depuis n'importe où sur internet. On le fait sur une machine qui est rarement exploitée à fond. Il est donc possible de fournir, à titre gracieux par exemple, un peu d'espace disque et des ressources diverses sur cette machine à d'autres personnes.

C'est ce que j'ai fait une fois il y a un certain temps et que je ne referai plus, tant cela s'est mal passé. En effet, cela demande parfois du temps (dont on ne dispose pas toujours) et de la patience (dont on s'aperçois qu'elle s'amenuise au fur et à mesure des demandes incessantes de la personne).

Dans le cas où ça se passe bien (ce qui doit quand même se passer en temps normal), l'idée même d'héberger quelqu'un d'autre sur mon serveur a fini par me poser un problème de principe. L'auto-hébergé, c'est moi, uniquement moi, pas celui que j'héberge. Conceptuellement, il n'y a presque pas de différence pour une connaissance entre héberger ses données chez moi ou chez un hébergeur ayant pignon sur rue. Enfin si, il y en a une de taille. Je peux le faire ponctuellement mais il est très probable que je connaisse déjà avant celui que j'héberge (IRL ou par un autre biais). Ce n'est pas le cas pour le fournisseur d'hébergement classique qui lui ne verra qu'un client comme un autre, noyé dans la masse. Tout le problème est là. Je peux avoir un intérêt particulier à accéder aux données de celui que j'héberge et même si je ne le fais pas, j'en ai techniquement la possibilité. Une connaissance que j'héberge ne peux pas avoir la certitude que je n'abuse pas de mon pouvoir. Cela donc n'est pas sain.

Conclusion

Ce que j'énumère ici n'est pas exhaustif mais à travers ça, je montre un peu mon approche de l'auto-hébergement. Je cherche à ne pas oublier que même si j'ai commencé à le faire de manière artisanale, cela reste un système en production, sur lequel j'ai les pleins pouvoir et que je dois conserver en état de fonctionnement.

Anticiper les ennuis en auto-hébergement

Rédigé par -Fred- / 25 avril 2016 / 4 commentaires

Introduction

L'auto-hébergement permet de retrouver un certain contrôle sur ses données et c'est le gros intérêt de la démarche. Mais, l'auto-hébergement implique, et c'est le revers de la médaille, d'assumer seul plusieurs risques supplémentaires. Il est donc utile de se poser quelques questions à un moment.

Précisions

Précision importante, l'auto-hébergement dont je parle ici est typiquement celui mis en œuvre par un particulier dans un cadre privé par exemple. C'est la forme qui m'intéresse là.

Venons en à mon cas

Google, Yahoo!, ou n'importe quel autre fournisseur habituel de mail n'est pas responsable si mon serveur de mail n'est plus accessible ou si mes données sont perdues par exemple. Les ressources physiques sous mon contrôle sont sous ma responsabilité. Cela couvre à la fois les problèmes logiciels et les problèmes matériels qui pourraient intervenir.

Méthode d'analyse

Je ne passe pas vraiment par une méthode particulière mais par simplement un peu de bon sens. L'idée, c'est d'anticiper ce que je peux et d'avoir déjà des réponses à apporter lorsque je me trouverai réellement en situation. Avant de proposer des réponses, il faut se poser les bonnes questions et pour se poser les bonnes questions. Je vais donc procéder comme suit :

  • Identifier le système sur lequel je veux agir.
  • Estimer les impacts des défaillances sur ce système complet.
  • Indiquer ce qui est déjà prévu en cas de défaillance.
  • Identifier les "trous dans la raquette".
  • Identifier les actions à mener afin de combler ces faiblesses.

Vue assez fidèle de mon réseau :

note : pour ce schéma, j'ai utilisé dia et les icônes de Jean Cartier.

Estimation de l'impact des défaillances :

Chaque élément sur ce réseau peut tomber en panne. Que le problème soit d'origine logiciel ou matériel importe peu, la seule chose importante est que l'élément considéré peut ne plus fonctionner à un moment donné. Élément par élément, quels sont donc les impacts d'une panne sur le système entier ? C'est aussi l'occasion d'estimer le niveau de gravité des impacts causés par chaque panne. J'en profite donc pour classifier chaque impact avec un niveau allant de 1 (impact mineur) à 3 (impact majeur). J'ai estimé qu'il était possible de fonctionner avec un effet de niveau 1. Pour les effets de niveau 2, j'ai considéré qu'une gène était visible que ce soit à l'intérieur ou à l'extérieur de mon réseau et qu'il n'était de fait pas possible de fonctionner en l'état. Enfin, les effets de niveau 3 traduisent un risque irréversible de perte de donnée. Voyons voir :

Modem ADSL HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus visible de l'extérieur.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (1) Téléphonie fixe non fonctionnelle.
Parefeu HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 16 ports HS :
  • (2) Plus de connexion à internet possible pour le serveur auto-hébergé, le serveur NAS et les autres postes sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 8 ports HS :
  • (2) Plus de connexion à internet possible les postes bureautique sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible en local.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
  • (1) Impression sur l'imprimante réseau locale impossible.
Serveur public HS :
  • (2) Services auto-hébergé non fonctionnels.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (3) Selon la panne du serveur, risque possible de perte des données stockées dessus.
Serveur NAS HS :
  • (2) Serveur NAS inaccessible en local.
  • (3) Selon la panne du NAS, risque possible de perte des données stockées dessus.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Reprendre l'ensemble des points listés précédemment.

Je ne traite pas le cas d'une panne sur la box OVH car la maintenance de cet appareil n'est pas à ma charge. En cas de défaillance, le problème est à traiter par OVH.

On peut déjà voir que certains éléments sont plus critiques que d'autres mais ils ont tous ou presque la possibilité d'entrainer des pertes de données. Si je n'en avais pas conscience avant, au moins là, c'est clairement établi. A y regarder de plus près, je vois deux types de problèmes sur les données. La non récupération de données externe et la perte de données préalablement récupérées. Dans le premier cas, c'est la conséquence d'une défaillance réseau et dans le second cas, il s'agit de la défaillance du système de stockage.

Ce qui est prévu en cas de défaillance :

S'il me faut maintenant assumer la défaillance d'un équipement, comment est-ce que j'ai prévu de réagir ? Voici ma réponse élément par élément :

Modem ADSL :
  • J'ai un modem équivalent de rechange.
Parefeu :
  • Aie ! Pas de machine de remplacement.
  • Configuration sauvegardée.
Switch 16 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Switch 8 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Serveur public :
  • Aie ! Pas de machine identique de remplacement.
  • Sauvegarde journalière des données importantes sur DD USB externe
  • Sauvegarde journalière des données importantes sur le NAS
Serveur NAS :
  • Aie ! Pas de machine identique de remplacement.
  • NAS deux baies en RAID 1. Réduction du risque de perte des données.
  • Les données les plus importantes stockées sur le NAS sont aussi sauvegardées sur une machine bureautique.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Aie ! Pas de solution de remplacent de matériel.
  • Perte de toutes mes données.

Comme on peut le voir, je ne dispose pratiquement pas d'équipements "sur étagère" afin d'intervenir immédiatement en cas de défaillance, ceci afin de repartir sur une configuration strictement identique. Ça ne veut pas dire que je suis bloqué mais ça demande quelques aménagements.

Mon réseau actuel n'est que l'évolution d'un réseau à plat. Si mon parefeu ou l'un de mes switchs manageable venait à dysfonctionner, j'ai la possibilité de basculer rapidement vers une architecture réseau plus simple. Je dispose d'un switch de secours et mon modem ADSL étant un modem/routeur en mode bridge, je n'ai qu'à en modifier la configuration si besoin pour le repasser en routeur. Reste ensuite simplement à revoir l'adressage IP. Ces manipulations ne sont pas longues à réaliser et me permettent de passer facilement dans un mode dégradé.

Les données importantes sur le NAS ou le serveur public sont aussi stockées ailleurs.

Globalement donc, je sais quoi faire si un élément de mon réseau tombe et mes données sont protégées contre une défaillance isolée de matériel.

Les trous dans la raquette :

Bien que le NAS soit en mesure d'assurer mon hébergement web et mail, tout comme il est possible au serveur public d'assurer le stockage des données actuellement sur le NAS, je préfère si possible éviter de rassembler l'ensemble de ces usages sur une même machine. Une défaillance du NAS n'est pas dramatique mais une défaillance du serveur public l'est plus dans la mesure où je ne peux m'en passer et parce que je ne dispose pas de solution à déployer rapidement s'il venait à me lâcher.

Le problème le plus important pourrait se produire en cas d'incendie ou de vol de matériel. Je ne dispose pas aujourd'hui de moyen de repartir même en mode fortement dégradé après ce type de problème. Pire, je perds toutes mes données puisque je ne dispose que de sauvegardes locales.

Actions à mener afin de combler ces faiblesses :

Je vais prévoir assez rapidement une machine supplémentaire que je serai en mesure de configurer rapidement en cas de défaillance de mon serveur public ou de mon parefeu.

Je vais prévoir de placer une sauvegarde récente de mes données sur un autre lieu, de sorte que les pertes de données soient minimes même en cas de problème grave.

Dernier point, je vais aussi réfléchir à une solution permettant de poursuivre mon activité ailleurs en cas de problème grave chez moi.

Conclusion

Tant que ça marche, on ne se pose pas de question mais dès que ça ne marche plus, il peut être trop tard pour chercher des réponses. Cette petite analyse me montre quels sont les points à travailler sur mon installation. Chaque installation auto-hébergée est différente mais je pense qu'elles méritent toutes une petite réflexion de ce type.

Mise à jour blog vers PluXml 5.5

Rédigé par -Fred- / 06 avril 2016 / 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- / 06 octobre 2015 / 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.