Nettoyer et protéger mon blog wordpress (Créer un compte)

  • Statut : non résolu
8 sujets de 1 à 8 (sur un total de 8)
  • Auteur
    Messages
  • #525369
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    Bonjour,

    Ma configuration WP actuelle
    – Version de WordPress : 3.5.1
    – Version de PHP/MySQL : 5
    – Thème utilisé : perso
    – Extensions en place : akismet, cforms, broken links checker, antivirus
    – Nom de l’hebergeur : OVH
    – Adresse du site : http://www.chomage-et-monnaie.org

    Problème(s) rencontré(s) :
    C’est la deuxième fois que j’ai une infection de malware sur mon site. La première fois, je m’en suis tiré en mettant WordPress à jour (j’avais beaucoup de retard).
    Mais cette fois-ci, je suis à jour pour WordPress et les plugins et un ami qui a AVG me dit que cet antivirus (et apparemment seulement lui) détecte « Blackhole Exploit Kit ».
    Que faire maintenant ? J’ai cherché sur ce forum et n’ai trouvé que 2 pistes
    1. les plugins antivirus : j’ai installé Antivirus. Lors du premier scan quotidien il m’a envoyé un mail pour me dire « suggests alarm ». Et alors ? Ca ne me dit pas quoi faire.
    2. La réinstallation intégrale, du genre (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
    Mais outre que je ne suis pas sûr de maîtriser toutes ces actions, faut-il vraiment en venir là? N’a-t-on rien trouvé depuis pour WordPress qui permette une détection et un nettoyage « online » ?
    Bref je suis perplexe quant à la meilleure conduite à tenir. Tout avis serait bienvenu.
    🙂 Gabier

    #898544
    Li-An
    Modérateur
    Maître WordPress
    26654 contributions

    Non, il n’y a pas de « nettoyage » en ligne. Il faut savoir que l’espace chez un hébergeur n’est pas du tout mais alors pas du tout géré comme votre disque dur. Il faudrait aussi être sûr que AVG ne fasse pas un « faux positif ». C’est un peu embêtant qu’il soit le seul à trouver un problème. Il faut aussi vérifier que ce n’est pas votre ordi qui est infecté.
    Et pour éviter les problèmes, regardez les tutos genre celui là: http://lashon.fr/wordpress-antispam-securite-site-web/

    #898545
    gabier
    Participant
    Chevalier WordPress
    110 contributions
    Li-An wrote:
    Non, il n’y a pas de « nettoyage » en ligne. Il faut savoir que l’espace chez un hébergeur n’est pas du tout mais alors pas du tout géré comme votre disque dur. Il faudrait aussi être sûr que AVG ne fasse pas un « faux positif ». C’est un peu embêtant qu’il soit le seul à trouver un problème. Il faut aussi vérifier que ce n’est pas votre ordi qui est infecté.
    Et pour éviter les problèmes, regardez les tutos genre celui là: http://lashon.fr/wordpress-antispam-securite-site-web/

    Merci Li-An. S’il n’y a pas de voie facile, alors tant pis. Le tutoriel a l’air compréhensible et bien fait. Je vais m’y mettre.
    Pour le faux positif noter que le plugin antivirus m’a tout de même envoyé une alerte. Je suis déçu par ce plugin, s’il ne fait qu’envoyer une alerte sans dire où est le fichier louche ça ne sert pas à grand-chose.
    Mon ordi apparemment n’est pas infecté en tout cas mon antivirus Avast et mon anti malware MBAR n’ont rien trouvé.
    🙂 gabier

    #898546
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    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

    #898547
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    Bonjour,
    Ce sujet n’a pas semblé inspirer grand monde, ou peut-être me suis-je mal exprimé. J’espère en tout cas que ce n’est pas un manque d’intérêt. Car j’ai résolu mon problème direct (l’infection de mon site) mais j’en ai appris beaucoup sur les attaques de ce genre et il y a de quoi s’organiser entre nous pour partager les moyens de résistance.
    Il faut savoir que les outils du genre Blackhole Exploit Kit sont en vente libre 1500$ sur Internet, et que ce sont des outils complets, avec tableau de bord impressionnant sur les sites et utilisateurs infectés, assistance technique et forum pour échanger sur les nouvelles barrières des antivirus pour les contourner. Et qui est visé ? Nous, les webmestres semi-pro.
    La technique est souvent d’insérer du code quelque part dans WordPress ou dans le code du thème, de sorte qu’il soit exécuté lorsqu’un utilisateur consulte le site. Ce code, bien camouflé (passer le code à l’antivirus ne donne aucun résultat), redirige l’utilisateur vers un site pirate, qui peut comporter tous les outils nécessaires pour chercher les failles de l’utilisateur et entrer chez lui, le plus souvent par une faille de sécurité dans le navigateur ou un de ses add-in (Flash Player, adobe reader, java, etc ..😉
    Combattre ces attaquants comporte deux faces.
    1. Empêcher au maximum l’intrusion, parce que pour insérer le code il faut se faire passer pour le propriétaire du fichier.
    2. En cas d’intrusion, pouvoir éradiquer rapidement l’intrus.
    Je consulte un peu partout pour établir une démarche, mais on a beaucoup de conseils différents et parfois contradictoires. Ce qui manque, c’est un tri de toutes ces mesures pour privilégier celles qui sont importantes et faciles à mettre en œuvre.
    Tout avis sur ce sujet est donc bienvenu.
    🙂 gabier

    #898548
    luciole135
    Participant
    Maître WordPress
    13735 contributions
    gabier wrote:
    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.

    Si vous importez en local avec phpMyAdmin alors vous aurez un message d’erreur qui vous indique la marche à suivre.
    Il y a 3 valeurs à modifier dans php.ini qui sont les suivantes, memory_limit, post_max_size et upload_max_filesize qui doit être plus petite que les deux autres.
    En local, pour pouvoir exporter et importer des tables de données très grandes (plus de 300Mo, en fait au max 1000Mo), j’ai mis les valeurs suivantes :
    memory_limit = 1024M
    post_max_size = 1024M
    upload_max_filesize = 1000M

    #898549
    luciole135
    Participant
    Maître WordPress
    13735 contributions
    gabier wrote:
    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 première des protections à prendre est de bien configurer le fichier .htaccess à la racine du site comme il est dit dans le tuto qui vous a été donné par Li-An :
    Au minimum, vous devez mettre dans ce fichier les instructions suivantes :

    # Protection du fichier .htaccess

    Order Allow,Deny
    Deny from all

    # Protection du fichier wp-config.php

    order allow,deny
    deny from all

    # Désactivation de l’affichage des répertoires
    Options All -Indexes

    Faites avec minutie les points 8, 9 et 10 du tuto : http://lashon.fr/wordpress-antispam-securite-site-web/#8-configurer-un-htaccess-en-bton-

    #898550
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    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

8 sujets de 1 à 8 (sur un total de 8)
  • Vous devez être connecté pour répondre à ce sujet.