SPIP hacké, que faire ?

Quand un site est hacké, on ne sait pas forcément comment réagir. Le but de cet article est de donner quelques pistes de réflexion aux personnes qui sont confrontées à ce cas.

Pour les gens pressés, vous pouvez consulter la version allégée de cet article

Hacké, ou non ?

Avant de se lancer dans les grandes opérations de nettoyage, il vaut mieux être sûr de son fait. Si vous êtes arrivés sur cette page, c’est probablement le cas, vous pouvez donc passer directement au paragraphe suivant… Si vous vous posez toujours des questions, voici une petite liste de points qui devraient éveiller vos soupçons quand à l’intégrité de votre site.

Tout changement de comportement brutal du site est suspect. Ainsi, une augmentation subite du trafic, de la charge du système ou du temps de réponse des pages peut résulter d’un piratage ou d’une tentative de piratage. Bien sûr, cela peut également être dû à un trafic légitime (après un spot TV traitant de votre site par exemple), ou à une difficulté technique de votre hébergeur.

Dans tous les cas, mieux vaut se poser des questions et rechercher l’origine de cette lenteur/charge en se rapprochant notamment de l’hébergeur pour vérifier que son infrastructure est en bon état de fonctionnement. Il est également possible de consulter les logs du serveur web pour voir quelles pages sont demandées, si les url sont bonnes, et les ip sources diversifiées.

Vous pouvez également être averti par google, soit directement si vous êtes inscrits à leurs divers programmes, ou indirectement en constatant que votre site ressort sur des recherches « étranges ». Enfin, vous pouvez également être averti par votre antivirus ou celui d’un de vos internautes lors de la navigation sur votre site.

Si vos soupçons sont aiguisés par les points ci dessus ou par d’autres, il va falloir aller rechercher sur votre site les traces du méchant pirate. Généralement certains fichiers sont visés en priorité :
-  fichier .htaccess pour les utilisateurs d’apache
-  fichier index.php
-  fichiers javascript (.js)

Pour repérer l’activité du pirate, vous pouvez vous baser sur la date de modification ou de création des fichiers. Potentiellement, vous avez chargé les fichiers de SPIP en une seule séance, si certains fichiers sont modifiés récemment, il peut être intéressant de les comparer avec une version de référence (la même que la vôtre !) fraichement récupérée sur spip.net.

Vous pouvez également récupérer les fichiers du site en ligne, et les scanner sur votre machine avec un antivirus : certains réagissent aux scripts malicieux.

Quelques éléments sont particulièrement suspects lors d’une vérification « à la main » :
-  l’inclusion d’une iframe avec une URL inconnue dans un fichier php, appel à un fichier javascript externe au site inconnu etc.
-  la présence dans un fichier js de code camouflé (function(p,a,c,k,e,d)[...], eval([...])).
-  la présence dans un fichier php de code camouflé : (eval(base64_decode("[...]"), eval(gzuncompress([...]) etc.)
-  la présence dans les articles directement de code bizarre (en base donc).

Si vous vous sentez dépassé par les évènements, pensez à aller chercher de l’aide. Un proche avec des compétences en informatique peut vous aider. De la même manière, les listes d’utilisateurs SPIP (mailing-list et IRC) peuvent vous permettre d’obtenir des conseils [1].

Parer au plus pressé

Quand un site est hacké, la première chose à faire est de sauvegarder l’intégralité des fichiers du site et des logs (base de donnée, SPIP lui même, images, logs SPIP, et logs serveur) dans un répertoire hors ligne pour analyse ultérieure. On note ensuite la liste des fichiers touchés et leur date de création et/ou de modification. Enfin, on passe le site hors ligne et on fait le ménage : réinstallation d’un SPIP propre + plugins neufs et à jour et remise en place de la base et des images. Enfin, à titre de précaution, on change également les mots de passe des comptes admin (sur SPIP) et ces accès via FTP.

Cette étape est généralement faite à l’arrache pour remettre le site en production au plus vite. Elle ne garantit pas qu’il soit pleinement propre… Après analyse à froid, il sera donc peut être nécessaire d’y revenir pour un nettoyage définitif.

Qui, où, quand, comment ?

Pour déterminer la cause d’un hack, il faut déterminer par où le hacker est rentré. Cela parait bête, mais c’est la base… Pour cela, il faut bien séparer les portes d’entrées possibles.

On peut regrouper les entrées possibles par familles :

  1. hébergement
    -> failles sur le serveur (apache, mysql etc.) -> Peu probable dans le cas d’un hébergeur sérieux qui met à jour ses serveurs.
  2. autre script
    -> faille sur un script indépendant de SPIP mais situé sur le même hébergement (script perso, autre CMS etc.) -> Probabilité très variable…
  3. SPIP et son écosystème
    -> faille sur SPIP lui même -> Peu probable s’il est régulièrement mis à jour.
    -> faille sur l’un des plugins -> Assez peu probable s’ils sont régulièrement mis à jour. Attention toutefois aux plugins qui ne sont plus maintenus ou qui sont encore dans les premières phases de leur développement…
  4. poste client
    -> infection par un virus d’une ou des machines ayant un accès au site (FTP en particulier) -> Cas le plus probable/courant.

Inspection

Le site étant de nouveau en ligne, on peut donc ensuite s’intéresser à la manière dont le pirate est entré. Pour cela, la date de création des fichiers infectés est précieuse : elle permet d’aller voir dans les logs ce qui a pu se passer aux environs de cette période. Pour chaque élément de la liste, on ne trouvera pas forcément les informations au même endroit.

Hébergement
Pour le premier point, c’est l’hébergeur qui fait le nécessaire : pas moyen de faire quoi que ce soit dans le cas d’un mutualisé. Dans le cas d’un dédié, si vous avez les droits root/admin sur le serveur, le présent article ne vous apprendra probablement pas grand chose…

Autre script
Pour le second point, il est nécessaire d’adapter selon les cas… S’il s’agit d’un CMS, il faudra veiller à ce qu’il soit mis à jour, au même titre que SPIP. Dans le cas d’un script « maison », il faudra éventuellement en relire le code à la recherche de failles potentielles (eval() exploitable, injection SQL, possibilités de chargement de fichiers php, traitement des variables des formulaires…). La lecture des fichiers de logs du serveur web peuvent bien aider pour cette étape. Plus généralement, se documenter sur les bonnes pratiques de codage avant de se lancer peut limiter sensiblement les risques de failles dans le code.

En cas de problème, tous les fichiers accessibles par l’utilisateur exécutant les scripts vulnérables peuvent être potentiellement touchés. Dans le pire des cas, si le hacker parvient à exploiter une faille connue sur le système d’exploitation, il peut arriver à compromettre l’intégralité de la machine. Ce dernier cas est cependant de la responsabilité de l’administrateur de la machine, son traitement sort donc du cadre de cet article.

SPIP et son écosystème

Pour les points trois et quatre, les logs de SPIP et des plugins peuvent être intéressants. Les requêtes en POST dans les fichiers de log du serveur http sont également potentiellement instructifs, ainsi que des appels à des fichiers cachés (dont le nom commence par un point). Le problème avec cette étape est que les fichiers de logs apache ou autre ne sont pas forcément aisés à lire. Les listes de diffusion de SPIP peuvent éventuellement fournir de l’aide à ce niveau.

Poste client

Si les accès FTP sont logués sur le serveur, ces informations peuvent s’avérer fort précieuses. En effet, dans ce cas, il est possible d’y trouver l’historique de chaque accès aux fichiers du site via ce protocole.

Jeter un coup d’œil dedans peut permettre de repérer des accès à des heures improbables pour l’utilisateur concerné. On peut ainsi déterminer quelle machine / quel compte FTP compromis si le pirate est entré par ce biais.

NB : ceci est aussi valable si le pirate a simplement trouvé le mot de passe du compte FTP via une attaque par force brute ou par dictionnaire. Dans ce cas, les fichiers de logs seront kilométriques et on y trouvera les différentes tentatives du pirate avant succès.

Dans tous les cas, un bon contrôle antivirus sur le ou les ordinateurs pouvant accéder au site s’impose, ceci afin de limiter les portes d’entrée possibles.

Cette étape n’est pas à négliger car un ordinateur compromis peut permettre à un pirate de récupérer la liste des mots de passe s’ils sont stockés en clair ou tapés sur le clavier. Accessoirement, si votre ordinateur est infecté, SPIP ne sera pas le seul concerné : si vous avez payé récemment en ligne, pensez à contrôler votre relevé de compte, et à changer de carte également. Idem pour les autres sites ou accès que vous auriez pu effectuer sur la machine… Dans ce cas, la seule méthode 100% fiable pour s’assurer que vous êtes venu à bout de l’infection est de réinstaller votre système d’exploitation (et de scanner vos fichiers sauvegardés avant réutilisation + suppression de tous les exécutables).

Ménage de printemps

Quand on a déterminé où est la faille, la fermer est aisé : mise à jour, désinfection, modification du code etc. Quand elle n’est pas déterminée par contre, on ne peut que tout mettre à jour et tendre le dos. Dans ce cas, il faut surveiller le site comme le lait sur le feu pour voir si le hack se reproduit…

Dans tous les cas le changement des mots de passe s’impose :
-  mot de passe des comptes SPIP (admins en particulier, mais pas uniquement).
-  accès FTP.
-  accès SQL.

On s’assure ainsi que le hacker ne peut plus rentrer sur le site avec les informations récupérées avant le grand nettoyage.

Mieux vaut prévenir que guérir

Là aussi, cela parait assez évident. Cependant lister les différents points à vérifier ne peut pas faire de mal.

Les mises à jour
Comme indiqué de manière lourde et répétitive tout au long du présent article, il est important de maintenir ses logiciels et ses applications web à jour.

Pour reprendre les différents points cités au dessus, on pourra donc citer :

-  hébergement : Le serveur et tous les logiciels fonctionnant dessus doivent être à jour.
-  autre script : Si vous n’êtes pas l’auteur d’un script exécuté sur votre hébergement, il est bon de veiller régulièrement à consulter le site de l’auteur pour se prémunir de failles éventuelles.
-  SPIP et son écosystème : trois éléments distincts sont à surveiller pour SPIP et son écosystème.

-  poste client : tout poste client possédant un accès FTP / admin devrait être sécurisé. Pour cela, un navigateur récent, un antivirus à jour et un logiciel de transfert n’enregistrant pas les mots de passe ou les chiffrant sont une bonne base.

Les mots de passe
Encore une évidence… Mais pour rappel/information, il existe deux grandes familles d’attaques sur les mots de passe sans exploiter de failles :
- l’attaque par force brute.
- l’attaque par dictionnaire.

La première attaque peut facilement se contourner en augmentant à la fois la complexité des mots de passe, et leur longueur. En effet, cette méthode étant très longue, les attaquants partent généralement du principe que les utilisateurs n’emploient pas de mots de passe trop complexes. Ils se basent donc sur un jeu de caractères restreints (de a à z et de 0 à 9 par exemple) pour attaquer.

Si un mot de passe fait six chiffres, il ne faudra donc « que » (10)^6 = 1 000 000 essais pour couvrir tous les cas. Si par contre il est composé de chiffres, de lettres minuscules et de lettres majuscules, il faudra : ( 10 + 26 + 26 )^6 = 56 800 235 584 essais pour traiter tous les cas.
Par conséquent, un mot de passe composé de combinaisons de caractères divers avec une longueur de huit caractères commence à devenir vraiment difficile à compromettre par cette méthode.

La seconde attaque (par dictionnaire) part du principe que les attaques par force brute sont très vite irréalisables. Par conséquent, mieux vaut se concentrer sur les faiblesses de l’homme plutôt que sur celles de la machine. En effet, nous sommes entourés de mots de passe et avons couramment une foule de comptes divers : carte bleue, sites internet, messagerie, réseaux sociaux, codes PIN… La tentation est donc forte de se simplifier la vie en utilisant des mots de passe que l’on retient aisément : le nom de sa ville, de ses enfants ou proches, de son groupe de musique favori… Mauvaise idée ! En effet, le français comporte environ 30 000 mots courants, à comparer avec les 1 000 000 essais nécessaires pour faire tomber un mot de passe composé uniquement de chiffres de 6 caractères. Ajoutons maintenant à cela un petit raffinements ou deux :
-  classement des mots du dictionnaires par fréquence d’apparition sur internet plutôt que par ordre alphabétique (et constitution également du dictionnaire par navigation sur internet).
-  test systématique du mot suivi de tous les chiffres entre 0 et 2100 précédé ou non d’un espace ou d’un tiret.

On voit qu’il est ainsi relativement aisé de faire tomber des mots de passe comme « loloute23 » « Sophie » « Lebogoss » « andré1960 » « Marseillais13 »…

Par conséquent, un bon mot de passe ne doit pas pouvoir s’attaquer par dictionnaire et doit comporter un mélange de caractères. Cela complique un peu les méthodes mnémotechniques, mais ne les empêche pas complètement. Ainsi Marseillais13 tombe très facilement. Par contre ma !13-RSEILLAIS sera nettement moins vulnérable.

Autre fausse bonne idée tentante : utiliser le même mot de passe pour tous ses comptes. Le jour où l’un est compromis, ils le sont tous…

L’humain

Plus vous avez de personnes qui interviennent sur un site, plus il sera difficile de déterminer qui fait quoi, et plus le risque de compromission augmentera. Par conséquent, mieux vaut limiter le nombre de personnes ayant des accès administrateurs ou FTP. Il est également souhaitable de ne pas partager de comptes à plusieurs car le jour où un problème survient, on ne peut pas facilement savoir qui en est responsable. Sans verser dans la paranoïa, il faut simplement être sûr de la personne à qui l’on passe les clefs.

  • un fichier PHP ne doit contenir qu’une seule balise <?php. Si vous en avez plusieurs ce n’est pas normal

Notes

[1Les développeurs de SPIP prennent toujours au sérieux les alertes de sécurité, et disposent pour cela d’une adresse dédiée : spip-team @ rezo.net. N’hésitez pas à exposer le problème rencontré, en donnant un maximum de détails techniques.

Discussion

10 discussions

  • Bonjour,

    Je ne sais pas trop ou poser la question, mais comment faire pour tester la fiabilité des documents transférés par un utilisateur, lors de l’ajout via le bouton « Parcourir ... » ?

    Merci.

    Répondre à ce message

  • 1

    Bonjour,

    mon site a été hacké la semaine dernière. La base php semble ne pas avoir été touchée mais tous les dossiers de mon serveur ont été supprimés.

    Je cherche donc à réinstaller un site propre. J’imagine qu’il faut installer la version initiale de spip puis faire une MAJ. Je suis donc allé dans la table slip_meta voir la variable version_installee qui est égale à 15828.

    J’ai donc refait une installation propre de spip 2.1.10 et ai tenté de charger ma base comme pour un déménagement. J’ai le message d’erreur suivant :

    Attention ! Le fichier .. / tmp / dump / localhost-4.xml ( ) correspond à une autre version de SPIP que celle que vous avez installée. Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation.

    Quelqu’un pourrait-il m’aider ?

    Merci beaucoup

    Répondre à ce message

  • Kristian

    Bonjour,

    Un des sites que je gère a été hacké. Le principe était de remplacer le titre de toutes les rubriques et de certains articles par un lien vers un iFrame du type <iFrame src=....> </iFrame>.

    Sur la page d’accueil, tout allait bien, mais dès que l’on cliquait sur un lien de rubrique, la page d’un autre site apparaissait. Le site utilisait la version 2.1.10 de SPIP. J’ignore si ce problème a été réglé depuis (empêcher un titre de rubrique d’ouvrir un lien...).

    Cordialement,

    Kristian.

    Répondre à ce message

  • 11
    valcanigou

    Bonsoir,

    J’ai un site sous SPIP depuis quelques années qui présente la cerisaie de mon beau-père.
    Le site a été hacké suite aux événements « Je suis Charlie ».

    Voici l’adresse du site hacké : www.fruitconflent.com
    On peut voir la page d’accueil sur le site archive.org à partir de ce lien :
    https://web.archive.org/web/2014121...

    Sur la page« index.html » qui se trouve dans le dossier /www/IMG/html, on trouve des traces du hacker.
    Toujours dans ce dossier, se trouve une page "index-2.html avec également des traces du hacker.

    Que faire, une fois ces indices repérés ?

    • valcanigou

      Bonsoir,

      Je rajoute à mon message précédent la page « index.html » que j’ai trouvée à la racine du site.

      Je renouvelle ma question : comment enlever cette page ?
      Peut-on récupérer l’ancienne page d’accueil ? Si c’est possible, comment faire ?

      Cordialement
      Valcanigou

    • change les mot de passe FTP,supprime l’ensemble des fichiers (en gardant une copie de tes squelette et dossier IMG) réinstalle un SPIP neuf...

    • Bonjour,

      Il peut aussi y avoir eu des modifications dans la base de données, des trucs du genre :

      "

      <meta http-equiv=« refresh » content=« 1 ;url=... »

      Dans la rubrique n°1
      Dans le dernier article

      Il peut aussi y avoir des redirections dans la description du site.

      Bon courage.

    • valcanigou

      Bonjour,

      Je vais suivre vos conseils. Mettre un SPIP neuf et refaire le site.

      Pour la copie du squelette, pourquoi faut-il garder une copie ?

      Pour les mots de passe, vous me conseillez de modifier les mots de passe FTP.
      Faut-il aussi changer le mot de passe pour accéder au manager OVH en tant qu’admin ?
      Faut-il aussi changer le mot de passe de la base de données SQL ?

      Merci bien Maïeul et Fred !

      Valcanigou

    • Bonjour,

      pourquoi faut-il garder une copie ?

      Pour analyse ultérieure, ou pour pouvoir s’en inspirer au besoin pour une nouvelle version.

      Faut-il aussi changer le mot de passe pour accéder au manager OVH en tant qu’admin ?

      En toute logique, non. Ceci dit, ça ne mange pas de pain de le faire de temps à autres, ce moment en vaut un autre.

      Faut-il aussi changer le mot de passe de la base de données SQL ?

      Oui, le fichier de configuration du site est potentiellement compromis, ce mot de passe est donc à changer.

    • Bonjour,

      J’ajoute qu’il faut aussi vérifier que les hackers ne se soient pas créé de comptes administrateurs. Si c’est le cas, il faudra les supprimer puis changer tous les mots de passe des autres utilisateurs et vérifier la véracité de leurs adresses emails.

      Faire aussi un tour du côté des plugins, histoire de voir si ils n’ont pas ajouté leurs hacks perso.

      Et en conclusion, faites un upgrade réguler de tous vos sites pour éviter les failles trop connus.

      Cdlt

      Fred

    • valcanigou

      Bonsoir,

      J’ai supprimé tous les fichiers du site et modifié les mots de passe. Je vais donc reconstituer les pages avec la dernière version de SPIP.
      Sur le moteur de recherche Google, lorsque je tape le mot clé « cerisaie durand » ( mot clé qui correspond à la cerisaie de mon beau-père) le premier site proposé dirige vers une page d’accueil du genre de celle qui avait remplacé la page d’index de mon site.

      Quel conseil pourriez-vous me soumettre pour éliminer cette page malveillante qui s’affiche avec le mot clé « cerisaie Durand » ?

      Cordialement
      Valcanigou

    • cette page d’accueil est-elle sur votre serveur ou pas ? si oui, effacez là. Sinon, attendez que votre site soit réinstallé, cela devrait laisser google refaire une indexation correcte.

    • valcanigou

      La page d’accueil malveillante n’existe plus sur mon site puisque j’ai tout effacé.
      En espérant que Google fasse une indexation correcte lorsque je remettrai le site en ligne...

    • valcanigou

      Bonjour,

      J’ai mis sur le net un début de site.

      Si je tape par exemple : www.monsite.com/IMG/pdf/ j’obtiens la page d’arborescence (que vous avez en fichier joint).

      Comment peut-on éviter la visibilité de l’arborescence de son site avec SPIP ?

      Merci bien !
      Valcanigou

    • cela n’a pas grand chose à voir ni avec le sujet de ce forum, ni même avec celui de l’article.

      Cela n’a a vrai dire aucune importance en terme de sécurité, les repertoires à protéger étant tmp et config, et SPIP les protèges par défaut.

      Cependant vous pouvez mettre dans le dossier IMG un fichier .htaccess contenant cette seule option Options -Indexes, ou vous pouvez demandez à votre hébergeur de ne pas lister le contenu des repertoires.

    Répondre à ce message

  • 7

    Bonjour,
    Mon site http://citoyendemaville.fr, s’est fait hacké, une redirection vers http://citoyendemaville.fr/IMG/html/ se met en place systématiquement ( j’ai giclé l’image qui y était, une revendication sahraoui ).
    J’ai fait plusieurs essais infructueux, pourriez-vous m’aider ou m’indiquer comment on obtient un identifiant pour se connecter sur Irc.
    Ce que j’ai fait :
    -  j’arrive à rentrer sur mon site par /ecrire, j’ai sauvegardé la base de données, je l’ai réinstallée dans un spip tout neuf, et visiblement le bug est dans la base car j’ai le même problème. Pire, depuis mon site local je me retrouve sur mon site de production.
    -  j’ai trouvé un rédacteur avec des droits webmaster inconnu ( qui s’appelait loush en plus ), je l’ai supprimé
    -  dans les documents, une page html que je ne connaissais pas, avec une date qui correspond à la survenue du pb, je l’ai giclée
    On dirait que le bug se ’propage’ par exemple, je ne peux plus accéder à la page ’articles’ dans l’espace de rédaction alors qu’avant j’y arrivais
    J’ai une restore en .gz de mon hébergeur, mais elle a une semaine, le bug est antérieur ( et je suppose qu’il faut des outils spéciaux ).
    Mon site est sous spip ( version de 2013 ), avec un habillage beespip et pas de personnalisations. J’ai voulu faire un site contributif ( possibilité de s’inscrire pour commenter et pour devenir rédacteur ), peut-être que je maitrisais mal cette partie.
    Merci pour votre aide

    • Bonjour,

      Tu as regarder l’url du site dans la base ? pas de modification du htaccess de spip ?

    • Bonjour,

      se connecter sur IRC ne nécessite pas d’identifiant : c’est une connexion libre. Sinon, il peut être intéressant également de faire un saut sur les listes de diffusion : http://listes.rezo.net/mailman/listinfo/spip ( par exemple ).

      Accessoirement, dans le sommaire, il y a des :
      meta http-equiv=« refresh » content="0 ; url=http://citoyendemaville.fr/IMG/html/"
      Faudrait voir d’où ils sortent. Ce pourrait être par exemple une injection SQL sur la table des URLs. Mais je ne me vois pas poursuivre ce genre de discussions ici : IRC et les listes de diffusion sont plus appropriées pour ça :)

      Et sinon : conseil usuel : tout sauvegarder, mettre ensuite à jour ... Composed-By : SPIP 3.0.5

    • Bonjour,
      Merci beaucoup pour vos conseils. Je suis obligée de différer la mise en pratique, mes activités de grand’mère m’occupent jusque jeudi.

    • Il doit y avoir une modification du htaccess car les autres pages fonctionnent.
      http://citoyendemaville.fr/spip.php?rubrique1

    • tu as regardé dans les derniers articles que tu as sur ta page d’accueil.
      Il doit y avoir un lien a supprimer qui pointe vers html/img

      par contre j’aimerais savoir comment ce monsieur a accès au site pour le modifier

    • Bonjour,
      J’ai réussi à remettre mon site d’aplomb en allant dans la base. L’article 1 ( affiché sur la page principale du site ) avait comme titre et comme contenu le lien de redirection. J’ai perdu le contenu de l’article 1, ce n’est pas grave, il fallait que je le réactualise.
      Par contre, aucune idée sur la façon dont ça s’est produit, je vais actualiser mon site ( je n’avais pas mis les plugins à la bonne place ).
      Pour le fichier .htaccess, la différence est là :
      # bloquer les acces aux fichiers caches (.svn, .git, etc) # bloquer les acces aux repertoires .svn/ (SPIP, plugins, squelettes...)
      RewriteRule /\..*(/.*|$) - [F] RewriteRule ^(.*/) ?\.svn/ - [F]
      Je ne sais interpréter cette différence.

    • Bonjour,

      donc il s’agit très certainement d’une injection SQL comme je le subodorais... Il faut impérativement mettre à jour SPIP et les plugins dans la dernière version de leur branche pour éviter de nouveaux ennuis.

      Concernant le fichier .htaccess, les lignes en question n’ont rien de méchant à priori. En tout cas, je ne vois pas de lien direct avec une redirection en page d’accueil.

    Répondre à ce message

  • 1

    Merci pour ces indications.
    J’aimerais modifier le mot de passe SQL, mais comment savoir dans quel fichier spip il est enregistré ?
    Merci d’avance pour l’aide.

    Répondre à ce message

  • A noter, certains hébergeurs proposent aussi de restaurer votre espace à une date précédente (un jour, une semaine précédente). (un « snapshot »)
    Cela peut être utile si votre piratage est récent ou si certains fichiers ont été perdus ou endommagés.
    Par exemple, chez OVH accéder à un snapshot

    Répondre à ce message

  • 1

    Salut,

    merci pour cet article et cette méthode...

    Est-ce qu’il ne serait pas intéressant d’ajouter des outils en ligne permettant de scanner un site à la recherche de fichiers infectés ?
    Il existe des site, mais il est difficile de connaitre leur efficacité...

    jean marie

    • Bonjour,

      le problème est que ces sites sont tous plus ou moins spécialisés/commerciaux. Pas évident donc de faire quelque chose de neutre et de pérenne dans le temps ... Enfin, comme je n’utilise pas ces solutions, j’aurais du mal à en parler ^^

    Répondre à ce message

  • Bonsoir :-)
    Cet article ne devrait pas également (ou au moins un lien qui renvoi vers ici) être sur spip.net ?
    Après concernant l’endroit exacte, je ne sais pas trop, car il faut que cela soit « simple » à trouver comme info ( dans la FAQ technique, dans télécharger ????)

    Répondre à ce message

  • Pour la gestion de mots de passe complexes il existe des solutions comme Keepass ou Lastpass qui permettent d’avoir des mots de passe complexes et unique pour chaque site.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom