gabier (Créer un compte)

Bonjour Luciole,
Merci pour ces avis.
Je vais peut-être dire de grosses bêtises, les spécialistes me corrigeront, mais j’aime bien comprendre ce que je fais, or ce qu’on me dit, les uns et les autres, ne me parait pas vraiment clair.

Concernant les parades par fermetures à certaines requêtes, je suis d’accord avec l’intention, mais je ne comprend guère les expressions régulières, donc je vais investir un peu de temps pour comprendre ces formules magiques.

Concernant les parades par htaccess, là je suis perplexe (sauf pour le « options all -indexes » dont l’utilité est évidente). En effet, le deny sur un fichier Fichier1.php interdit l’accès à ce fichier par l’entrée normale du navigateur, c’est à dire que si on entre dans la barre d’adresse http://siteXXX/Fichier1.php on se ramassera une erreur 403.
Mais ce moyen d’accès à un fichier n’est pas le seul, et il est même improbable qu’un attaquant choisisse ce mode d’accès. je connais au moins deux autres manières
– l’accès par ftp
– l’accès à partir d’un autre fichier de l’espace WordPress. J’ai fait l’expérience avec deux fichiers php, l’un couvert par un deny dans le htaccess, l’autre écrivant du code dans le premier. Cela passe comme une lettre à la poste.

Si le premier moyen peut être traité par un mot de passe renforcé et changé fréquemment, le deuxième ouvre tout un champ d’action à nos attaquants. Quand on dit que WordPress a une faille de sécurité, il me semble que ça veut dire qu’un internaute peut accéder à un fichier en tant que propriétaire et écrire dedans. Et à partir de là, il peut mettre du code mal intentionné dans toute autre page de WordPress ou d’un thème, notamment dans les pages les plus visitées, par exemple les index. C’est ce qui m’est arrivé.
Je ne connais qu’un seul moyen d’empêcher radicalement la modification d’un fichier, c’est de le mettre en 404 (les fichiers WordPress semblent être en 604). Mais je suppose que ce n’est pas possible pour tous les fichiers.

D’autres actions me paraissent plus pertinente pour égarer nos attaquant robots, qui sont probablement les plus nombreux (changements de noms de fichiers, limitation du nombre de tentatives de connexion, pas de compte admin de nom « admin », etc …) et retarder l’intrusion.

Bon ça suffit pour aujourd’hui.

🙂 gabier

Bonjour à tous,

Suite aux échanges précédents, j’ai entrepris 2 démarches parallèles., nettoyer mon blog et le sécuriser.

1. Côté nettoyage, j’ai commencé par revenir à la version du blog 15 jours en arrière (fonctionnalité OVH), mais il y a toujours des alertes virus. Pour aller plus loin je ne vois pas d’autre solution que l’écrasement total du blog et sa réinstallation. L’objectif est de procéder comme je l’ai trouvé sur ce site
– exportation des articles etc via l’outil exporter
– sauvegarde base de données
– suppression du blog via ftp chez l’hébergeur (un clic)
– suppression de mes tables sur ma base de données chez l’hébergeur, je reste connecté à MySQL
– installation nouveau blog via ftp chez l’hébergeur (plus rapide on peut uploader compressé)
– suppression en un clic des articles par défaut via mysql
– réglages de mon blog via mysql ou WP
– analyse via antivirus et à l’oeil nu de mon fichiers d’exportation
– idem pour la base
– importation de base ou du fichier d’importation

L’auteur dit qu’il peut faire tout ça en moins de 30 mn.

Mais j’ai fait d’abord des essais et j’ai de gros problèmes.
a) L’exportation des articles se fait sans problème mais le fichier fait 3,6 Mo. A la réimportation sur mon WordPress local, il y a une erreur. Le php limite les « upload » à 2Mo. Après enquête il semble qu’il en soit de même chez OVH. Je leur ai demandé s’ils peuvent changer le paramètre de php.ini qui fixe la limite, mais je n’anticipe pas une réponse positive. J’ai aussi cherché si WordPress peut n’exporter qu’une partie des articles mais ça ne semble pas possible de procéder ainsi en plusieurs fois.
b) L’exportation de la base se fait chez ovh sous la forme d’une sauvegarde qui est mise à disposition sous forme de fichier « texte » qui s’affiche dans une énorme page html dont on ne sait pas quoi faire. J’ai là aussi posé une question au support et j’attends la réponse, mais là aussi je risque fort de ne pas avoir de réponse satisfaisante.

Moralité : pas possible pour l’instant de décharger le contenu et le recharger après passage à l’antivirus.

Je risque donc de me restreindre pour l’instant à une désinstallation réinstallation du code de WordPress seulement, en espérant que ça résolve mon problème actuel.

Mais puis-je faire ça ? Si je supprime tous les fichiers WordPress, plugin et thèmes, et que je réinstalle WordPress au même endroit avec une base pleine, va-t-il accepter ? Sur mon WordPress local, à l’exécution de wp-admin/install.php il a accepté en disant « il semble que WordPress soit déjà installé. » Mais je n’ose pas écraser le WordPress de mon blog distant sans être sûr que je vais pas être bloqué

2) Sur la protection je me suis contenté pour l’instant de renforcer les mots de passe, car pour la suite j’ai des problèmes de compréhension quand j’essaie d’appliquer le manuel http://lashon.fr/wordpress-antispam-securite-site-web/ .
La partie mots de passe c’est clair. La partie de refuser les requêtes de certaines provenance, c’est clair aussi, bien que les expressions « rationnelles » soient assez incompréhensibles.
Par contre la protection de wp-login et wp-admin me pose problème. Pourquoi ceux là et pas d’autres ? Est-ce à dire que les hackers doivent passer par là pour aller plus loin ?
Si la réponse est oui, il est en effet vital de les protéger, mais la seule méthode proposée est de restreindre l’accès à l’ip de l’administrateur. Mais il est bien précisé qu’il faut un ip fixe, ce qui est loin d’être la situation de tous.
Si c’est si important, serait-il possible d’employer les systèmes « no-ip » ou « dyndns » pour restreindre cet accès ?
Mais si la réponse est non, quel est l’intérêt réel de cette protection ?

Ca fait beaucoup de questions mais comme je me les pose sans pouvoir vraiment y répondre, je compte sur un peu d’aide pour progresser.

🙂 Gabier

Bon conseil Luciole !! J’ai carrément désinstallé XAMPP et réinstallé en suivant le tuto indiqué (enfin presque …) et ça marche nickel!
Merci
🙂 Gabier

Bonsoir à tous,
Voilà, je suis en 3.5.1, problème résolu, j’espère …
🙂 Gabier

Bonsoir,

Il faut que je fasse quelque chose. J’ai essayé d’accéder à la mise à jour automatique en allant directement à wp-admin/update-core.php, mais apparemment je ne peux pas y accéder non plus. je me prépare donc à faire une mise à jour manuelle, ce qui aura l’avantage de remettre à neuf tous les fichiers de WordPress.
Si je fais bien attention (ne pas écraser wp-content ni wp-config), je devrais laisser intact le fonctionnement de mon site.
Je vais d’abord essayer sur XAMPP.
Ai-je dit des bêtises ?

🙂 Gabier

Bonjour,

J’en suis toujours au même point. Le détecteur de malware sitecheck.sucuri.net est tout de même douteux. Si je lui fais scanner tout le site, il ne trouve rien, sauf que la version de WordPress est périmée, et si je lui fait scanner seulement http://monsite/wp-login.php alors là il me dit qu’il y a un malware ! et me propose un nettoyage en abonnement annuel pour minimum 89$! Ca coûterait moins cher de chercher un fichier wp-login.php propre
J’ai télédéchargé wp-login.php et je l’ai passé à l’antivirus, puis dans « malwarebite » (MBAM) mais rien n’a été trouvé, et la page d’admin ne peut toujours pas être atteinte.
Je crois que je vais essayer de mettre à jour WordPress. Un certain nombre de fichiers devraient être remis à neuf. Est-ce que ça n’est pas un peu dangereux de passer de ma vieille version 2.x à la version actuelle 3.5.1 ?

🙂 Gabier

J’ai beau chercher à comprendre, je n’y arrive pas. S’il y avait un virus sur le site, ou plutôt des redirections parasites, ou des fichiers remplacés, pourquoi ça m’empêcherait d’y accéder et pas toi ?
Nous sommes bien d’accord que tu es allé à http://www.chomage-et-monnaie.org/wp-login.php et que tu as bien obtenu la page de login de l’admin ?

🙂 Gabier

Bonjour,

N’ayant trouvé aucune piste, j’ai essayé la méthode par essai et erreur.
J’ai supprimé toutes les lignes de ma sidebar sauf la recherche, et j’ai constaté qu’alors l’anomalie avait disparu. J’ai donc rajouté les lignes une par une, pour constater que les lignes fautives étaient les lignes « items de catégories ».
Elles étaient enfermées dans une DIV qui (ne me demandez pas pourquoi) provoquait le problème. Une fois cette DIV supprimée (elle n’est pas vraimant nécessaire), le problème disparaît.

Les mystères du CSS sont insondables …

En tout cas, ✅

🙂 Gabier