OVH Community, votre nouvel espace communautaire.

Blocage - HTTP


juliergs
05/09/2014, 18h10
Bonjour bonjour,

Pfiouuuu c'est bien compliqué tout ça :-(
J'avoue avoir parcouru toutes les pages, mais j'ai commencé à décrocher à la deuxième.
Bon, du coup je vais tenter de sauvegarder tous mes fichiers et puis de tout réinstaller...

AIexis
12/08/2014, 22h49
Sur filezilla il faut aller sur le menu "serveur", puis "saisir une commande personnalisée" et taper SITE CHMOD 705 /

Florian_Kaplar
12/08/2014, 21h10
Je viens de remettre les droits en CHMOD705 et toujours impossible d'accéder au blog.

Kézaco ?

fritz2cat
12/08/2014, 17h36
A méditer:
Note that the malware's that took over our machine also inserted a user record with a blank login name and gave it administrator capabilities so they have a back door for future attacks even if you clean up the code.

Pattern is that the new user has a user ID of "1001001". You need to go through every database and remove this user and its capability in usermeta. Just one wp instance on a shared server can let them back in to ruin all of them.

fritz2cat
12/08/2014, 17h34
Effectivement, plugin Mailpoet
Lire http://blog.sucuri.net/2014/07/remot...wsletters.html

Florian_Kaplar
12/08/2014, 16h32
J'ai fait toutes les mises à jour proposées depuis l'interface WordPress.
Citation Envoyé par fritz2cat
Le problème dans ce cas d'espèce, c'est que OVH a proposé un truc tout fait, installé en deux-trois clics-clics-clics, et puis plus personne ne se soucie de maintenir l'installation Wordpress à jour.

C'est comme si on vous vendait une voiture mais qu'on zappe complètement les entretiens. Et surtout que ceux-ci ne sont même pas proposés par OVH, gratuitement ou contre rétribution.

Maintenant dans le cas de Wordpress il y a une console d'administration qui permet de faire toutes les mises à jour très facilement moyennant fourniture du mot de passe ftp ; j'ignore si cela fonctionne bien ou mal dans le cas des WP livrés via modules préinstallés OVH.

Florian_Kaplar
12/08/2014, 16h30
OK Julien, c'est ce que j'essaie de faire.
Comme indiqué dans le guide, jJ'ai scanné la sauvegarde sanp4 et c'est WYSIJA le "coupable".
AVAST a détecté une menace PHP:WebShell A-[Trj] sur le fichier qwerty.php dans wp-content/uploads/wysija/themes/default/

fritz2cat
12/08/2014, 15h45
@Aiexis: non il te confisque les clés car des boulons se détachent, l'huile coule sur la route et ça gêne un peu les autres...

AIexis
12/08/2014, 15h35
Citation Envoyé par fritz2cat
C'est comme si on vous vendait une voiture mais qu'on zappe complètement les entretiens. Et surtout que ceux-ci ne sont même pas proposés par OVH, gratuitement ou contre rétribution.
Et en plus le concessionnaire vient chez toi vérifier si ta vidange est faite, et si c'est pas le cas il te confisque les clés.

fritz2cat
12/08/2014, 15h11
Citation Envoyé par Florian_Kaplar
...
WordPress a été installé via OVH Manager V3
...
Le problème dans ce cas d'espèce, c'est que OVH a proposé un truc tout fait, installé en deux-trois clics-clics-clics, et puis plus personne ne se soucie de maintenir l'installation Wordpress à jour.

C'est comme si on vous vendait une voiture mais qu'on zappe complètement les entretiens. Et surtout que ceux-ci ne sont même pas proposés par OVH, gratuitement ou contre rétribution.

Maintenant dans le cas de Wordpress il y a une console d'administration qui permet de faire toutes les mises à jour très facilement moyennant fourniture du mot de passe ftp ; j'ignore si cela fonctionne bien ou mal dans le cas des WP livrés via modules préinstallés OVH.

JuGU
12/08/2014, 14h13
Bonjour,

Tu ne pourras pas accéder au script car comme l'indique le message que tu as reçu, il s'agit d'un script qui s'efface après s'être exécuté.

Je t'inviterai à vérifier ton site en uploadant une version saine, puis en le mettant à jour pour éviter les failles de sécurité.

Florian_Kaplar
12/08/2014, 00h13
Je n'arrive même pas à accéder au script incriminé : (...)www/wp-includes/Text/Diff/Engine/.nfs0000000001d226480000364e.
Est-ce que cela tient au fait que WordPress a été installé via OVH Manager V3 ?
Il m'est impossible d'accéder à ce fichier via SSH ?
Du coup, ne serait-ce pas au support d'OVH de remédier à cela ?
Que faire ?

Citation Envoyé par fritz2cat
@Florian, sujet déjà exposé plusieurs fois récemment.
Vois http://forum.ovh.com/showthread.php?100212

fritz2cat
11/08/2014, 15h18
@Florian, sujet déjà exposé plusieurs fois récemment.
Vois http://forum.ovh.com/showthread.php?100212

Florian_Kaplar
11/08/2014, 14h51
Bonjour à tous,

J'ai reçu un message d'OVH m'informant du blocage HTTP de mon blog.

Voici les explications reçues par OVH :

"Notre système de surveillance (Okillerd) a détecté une opération
irrégulière au niveau de votre site.

Les détails de cette opération sont les suivants :

naturo-passion.com

Problème rencontré : Executing deleted program
Commande apparente : ././ps
Exécutable utilisé : /home/naturopabw/www/wp-includes/Text/Diff/Engine/.nfs0000000001d226480000364e
Horodatage: Fri Aug 8 14:32:03 CEST 2014

Ceci n'est pas autorisé sur nos installations,
car c'est une tentative potentielle de piratage.

Si ce n'est pas vous qui avez lancé ce script, cela signifie
qu'il y a une faille sur votre site et qu'un hacker s'en
est servi pour réaliser cette opération.

Nous avons désactivé l'accès web temporairement pour éviter tout
risque de nouveau piratage.

Vous pouvez vous connecter via ftp, pour modifier les scripts qui
peuvent poser problème. Pensez également à mettre à jour les
logiciels que vous utilisez comme phpnuke, phpbb, etc.

Comment faire ?
Consultez ces guides :
- http://guides.ovh.com/AlerteHackMutu
- http://guides.ovh.com/SecuriteSite

Une fois le problème résolu, vous pouvez rouvrir votre site
en remettant les bons droits sur le répertoire racine (chmod 705 .)."

N'étant pas un spécialiste, je ne comprends pas grand chose et je me demande combien cela coûte de réparer cette faille (OVH demande 20€ pour un quart d'heure, mais peut-être faut-il 2heures ?).

Après, il semblerait qu'un blog piraté soit très fragile et qu'il vaudrait mieux tout réinstaller.

Par avance, merci de vos conseils.

Florian

ChristianM
26/07/2014, 10h08
Citation Envoyé par ddtddt
Si la galerie génère la taille d'affichage à chaque demande cela utilise beaucoup de ressource serveur ...
Mais je ne connais pas ce script donc je ne porte pas de jugement je te posais juste la question ;-)
Pas de soucis ddtddt.
Je sais que ce plugin est assez lourd niveau ressources.
Mais comme dit je n'ai rien trouvé de comparable aussi performant.

Je suis cependant ouvert à toute proposition, idée, suggestion.

ddtddt
26/07/2014, 06h26
Citation Envoyé par ChristianM
Pourquoi cette question ?
Si la galerie génère la taille d'affichage à chaque demande cela utilise beaucoup de ressource serveur ...
Mais je ne connais pas ce script donc je ne porte pas de jugement je te posais juste la question ;-)

AIexis
26/07/2014, 00h00
Citation Envoyé par Nowwhat
Et bien, sans le savoir, t'as du commencer à comprendre que CHAQUE visite sur ton site débute par l'exécution de ce /index.php - même si tu l'appelle pas directement.
Ouvre ce fichier "index.php" pour voir ce qu'il a à dire:
Code:
/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
Il a défini une variable "WP_USE_THEMES" puis il va lire/inclure/exécuter wp-blog-header.php:
Code:
if ( !isset($wp_did_header) ) {

        $wp_did_header = true;

        require_once( dirname(__FILE__) . '/wp-load.php' );

        wp();

        require_once( ABSPATH . WPINC . '/template-loader.php' );

}
Pareil ici. "wp_did_header" n'a pas encore de valeur (il est donc sur 'false') donc "wp-load.php" va être lu/inclus/exécuté, puis la fête commence avec
wp();
....

Et la tout le cirque de WP démarre.
(va voir dans "wp-load" - c'est encore supportable)
Oui, j'avais effectivement pigé le truc, mais merci pour le détail des explications

Nowwhat
25/07/2014, 23h47
Citation Envoyé par AIexis
En même temps, je n'ai mis le tag que sur le fichier index.php à la racine, et je vois indiqué "CrawlProtect surveille 794 répertoires et 7 268 fichiers." dans l'admin de crawlprotect. Bon, je pige pas bien comment, mais en étant optimiste c'est peut-être suffisant
Et bien, sans le savoir, t'as du commencer à comprendre que CHAQUE visite sur ton site débute par l'exécution de ce /index.php - même si tu l'appelle pas directement.
Ouvre ce fichier "index.php" pour voir ce qu'il a à dire:
Code:
/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
Il a défini une variable "WP_USE_THEMES" puis il va lire/inclure/exécuter wp-blog-header.php:
Code:
if ( !isset($wp_did_header) ) {

        $wp_did_header = true;

        require_once( dirname(__FILE__) . '/wp-load.php' );

        wp();

        require_once( ABSPATH . WPINC . '/template-loader.php' );

}
Pareil ici. "wp_did_header" n'a pas encore de valeur (il est donc sur 'false') donc "wp-load.php" va être lu/inclus/exécuté, puis la fête commence avec
wp();
....

Et la tout le cirque de WP démarre.
(va voir dans "wp-load" - c'est encore supportable)

AIexis
25/07/2014, 22h54
Oui, maître.

Gaston_Phone
25/07/2014, 21h30
Cela s'appelle du bricolage avec tous les risques associés.

AIexis
25/07/2014, 21h29
Non, j'ai pas cherché à comprendre, parce que je déteste ça... c'est pas mon site, et j'ai mis les mains dedans uniquement par pure gentillesse

Gaston_Phone
25/07/2014, 20h43
Et as-tu chercher à comprendre comment fonctionne ton CMS Wordpress ?

AIexis
25/07/2014, 18h58
En même temps, je n'ai mis le tag que sur le fichier index.php à la racine, et je vois indiqué "CrawlProtect surveille 794 répertoires et 7 268 fichiers." dans l'admin de crawlprotect. Bon, je pige pas bien comment, mais en étant optimiste c'est peut-être suffisant

AIexis
25/07/2014, 18h54
Y'a une quantité astronomique de fichiers php avec wordpress :'(

Gaston_Phone
25/07/2014, 18h49
Pour que "crawlprotect" fonctionne efficacement il doit être appelé au tout début de chaque script. Et ... ce n'est pas une blague. ;D

AIexis
25/07/2014, 18h42
Bonjour,
j'ai un souci qui ressemble exactement à ceux décrits sur ce fil ( wordpress + plugins = blocage d'ovh).
Ce n'est pas moi qui suis responsable de ce site, je file juste un coup de main, mais peu importe.

Comment installer crawlprotect ? il n'est pas dispo dans la liste des plugins wordpress, et pour l'installer "à la main" ils proposent de modifier chaque fichier php avec un en-tête.... euh, c'est une blague ?

Merci

ChristianM
25/07/2014, 15h23
Bonjour,

Bien honnêtement je ne sais pas.
Nextgen est assez facile dans son utilisation mais plutôt complexe dans sa paramétrisation.
(et puis en anglais et c'est pas toujours franchement évident)

Donc au final la galerie tourne et me convient ainsi.
Pourquoi cette question ?

ddtddt
25/07/2014, 07h06
Bonjour,

Ton script de galerie ne te propose pas de forcer la génération de taille multiple pour le cache ?

ChristianM
19/07/2014, 21h51
Hello les gars !

Content que tout revienne dans l'ordre pour vous aussi !!

Le lien vers Crawlprotect => http://www.crawltrack.fr/crawlprotect/

N'ai reçu aucun MP zeejow =(

otovon
19/07/2014, 20h44
Moi aussi blog rétabli.

J'ai ensuite suivi les conseils explicité ici :
http://www.responsive-mind.fr/securi...-en-15-points/

zeejow
19/07/2014, 18h51
C'est bon pour moi aussi, le blog est de nouveau en ligne. Je dois maintenant réinstaller tous les plugins et surtout envoyer plusieurs Giga de photos en FTP à un débit médiocre.

Christian je t'envoi l'adresse en MP

Peux-tu m'envoyer un lien vers Crawlprotect ? Je ne suis pas sûr de tomber sur le bon fichier ...

ChristianM
19/07/2014, 08h18
Merci Zeejow !

Yess mon site est toujours bien là .... ouf !

Heureusement que les Snap étaient bien disponibles et utilisables.
Sans ça je serais à l'heure qu'il est dans le même état que vous !

J'espère que ta nuit fut malgré tout bonne et pas trop courte !!

Perso j'ai laissé Crawlprotect faire le .htaccess à ma place (de plus il propose de le mettre à jour au fur et à mesure des attaque, ce qui fut le cas cette nuit. 2 tentatives de hack ou de spam avortée !!

En passant tu penseras à me donner l'url de ton site (photo si j'ai bien capté), je me ferai un joie de te renseigner sur ma page de lien.

Continue de nous tenir informé.

@Otovon : où en es-tu de ton côté ?

A plus !

zeejow
19/07/2014, 00h28
Je suis content pour toi !
Bravo ! Comme quoi fallait pas baisser les bras.

De mon côté les choses s'arrangent. Je n'ai pas pu appliquer ma propre méthode car je n'ai pas accès au snapshot4 et 5 ... je dois donc faire comme Otovon et tout réinstaller.

J'ai réinstallé Wordpress dans sa dernière version et sans les plugins que j'ajouterai plus tard.
Par contre j'ai sauvegardé tout mon contenu en local (des photos) mais à aucun moment j'ai pensé au fait que mon débit montant était pourri .. AHAHA voilà j'en ai pour une nuit d'upload de photos !

Choses prévues ensuite :
-réinstaller mes plugins dans leurs dernières versions.
-installer Crawlprotect
-protéger le fichier .htaccess en m'inspirant de cet article : http://www.paperblog.fr/2511536/word...hier-htaccess/
etc...

ChristianM
18/07/2014, 21h55
Salut tout le monde !

Problème résolu !
J'ai simplement appliqué ta méthode zeejow ! (snap 4)
En ajoutant deux plugins sécurité : login lockdown et Wordfence
En virant le plugin WP-super-cache
En ajoutant Crawlprotect.
En changeant tous les mots de passe (admin WP - SQL et FTP.
J'attends encore un moment et je fais un BU complet !
Merci encore pour le soutein Zeejow !
J'espère que tu arriveras aux mêmes fins.

zeejow
18/07/2014, 20h46
Bravo Christian, je vois que ton blog est de nouveau en ligne ! Quelle méthode as-tu utilisé alors ?

Moi aussi je viens de rentrer du boulot j'espère remettre le miens en ligne dans la soirée (nuit ?)

Merci pour ta contribution Otovon, je suis contenant que notre conclusion sur le problème est similaire

otovon
18/07/2014, 16h19
Bonjour à tous...

j'arrive sur le tard... et je compatis à vos soucis... car j'ai les mêmes

Je viens de lire vos échanges et en arrive à la même analyse que zeejow.

J'ai dans mes logs des choses similaires. J'ai donc suivi ton conseil zeejow, j'ai renommé mon fichier en xmlrpc_php.old. Ce fichier ne sert à priori que pour des modules externes, pour injecter des contenus (articles..) à partir d'application externer ou d'extensions de navigateurs. Donc pas besoin.

Ensuite, après 3 nuits perturbées pas ces soucis (j'ai aussi eu il y a qq jours une alerte au SPAM depuis mon site par OVH, qui a précédé cette attaque, j'ai tenté d'y aller moi aussi petit à petit.)
Au départ j'ai cru que la faille venait d'un PhpBB installé en sous dossier /forum, car l'attaque venait d'un sous dossier :
/www/forum/language/en/.nfs00000000001a453f0000281a
> > Horodatage: Wed Jul 16 13:15:50 CEST 2014
J'ai supprimé le forum dont je n'avais pas l'utilité, incrimant ce #~[{|`de PhpBB
Puis une deuxième du dossier wp-includes de wordpress :
/www/wp-includes/ID3/.nfs00000000027a16c2000028ac
Horodatage: Wed Jul 16 21:23:25 CEST 2014
J'ai supprimé et remplacé par du neuf...
Puis une autre du dossier wp-plugin :
/www/wp-content/plugins/.nfs00000000023355240000291f
> Horodatage: Thu Jul 17 01:39:19 CEST 2014
Pareil.. :-/
Bref... de la vermine partout...

J'ai donc pris le parti de réinstaller le site en entier en priant pour que la base SQL ne soit pas atteinte.

J'ai sauvegardé la partie "médias" de mon dossier 'wp-content/upload', et mon fichier wp-config.php et les préférences de mon thème, et je suis parti pour une installation complète à neuf.

J'ai rapidement scanné le dossier upload, rien vu d'anormal.

Là j'y suis... A suivre. Je vous tiens au courant.. :-)

ChristianM
18/07/2014, 13h44
Re,

Ben écoute là je suis au bureau mais j'attaque ça ce soir !

Je te devrai une fière chandelle parce que je commençais grave à désespérer.

Je pense que sans ton intervention je laissais tomber.





zeejow
18/07/2014, 13h27
Salut Christian,

J'espère que tu t'en sors et que tu arrives à remettre ton site sur pied !

Je te confirme que je suis bien sous Wordpress et que j'ai également le plugin Wysija sur le blog. Merci pour l'info !!

De mon côté je me suis "amusé" à traiter tous les logs WEB OVH entre le 11/07 et le 16/07. Je n'ai gardé que les méthodes "POST"

En un petit coup de notepad++ et d'excel voici ce que j'obtiens pour la journée du 14/07 (date à laquelle mon s'est écroulé :

POST /wp-content/plugins/jetpack/class.jetpack-post-images.php HTTP/1.1 NB d'occurence sur la journée => 3
POST /wp-content/plugins/tinymce-advanced/mce/advhr/xml.php HTTP/1.1 NB d'occurence sur la journée => 790
POST /wp-content/uploads/wysija/proxy.php HTTP/1.1 NB d'occurence sur la journée => 1
POST /xmlrpc.php HTTP/1.1 NB d'occurence sur la journée => 7313
On retrouve bien le plugin WYSIJA mais également le plugin TINYMCE-ADVANCED. Je ne parle pas du XMLRPC.php

Je te tiens également au courant de mes découvertes et de mon avancée dans la remise en ligne du blog.

ChristianM
18/07/2014, 12h15
@Zeejow : je suppose que tu tournes sous Wordpress ??

Si oui utilises-tu Wysija Newsletter ?

Je suis en contact avec quelqu'un qui gère qq sites dont un sous wordpress vient d'être attaqué aussi !!

Edit moi-même : je viens de tomber sur ceci => http://reseau.dumac.free.fr/dumacien...id_article=171

ChristianM
18/07/2014, 09h23
Bonjour et merci Gaston

Gaston_Phone
18/07/2014, 09h14
Citation Envoyé par ChristianM
Je vais voir pour sécuriser le site. Il m'a été conseillé Crawlprotect par quelqu'un ayant subi la même mésaventure.
J'ai déjà utilisé Crawlprotect sur un site professionnel. C'est bien conçu.

ChristianM
18/07/2014, 08h24
Bonjour,

Nous dirons que sur pas mal de forum d'entraide on te dirige souvent vers des tutos fait pour des développeurs chevronnés (que je ne suis pas)
Mais là aussi je fais ma mauvaise langue ....

Bon bref tout ça pour une fois encore te remercier.

Je vais appliquer ta solution à la lettre (sauf que la sauvegarde de mon site "infecté" est déjà faite)

Je vais voir pour sécuriser le site. Il m'a été conseillé Crawlprotect par quelqu'un ayant subi la même mésaventure.

Je te tiens au jus et j'espère que tu trouveras rapidement la solution à ton problème aussi.


zeejow
17/07/2014, 20h54
Pas de soucis. C'est là le principe d'un forum. J'essai également de trouver des pistes pour résoudre mon problème.

Tout le monde n'a pas forcément les moyens de faire débugger son site par un expert OVH à 20 euros le quart d'heure (mais je suis mauvaise langue car des gens du staff OVH à l'instar d'Edouard sont présents sur le forum pour nous aider)

Pour répondre à ta question je te conseillerais de :

- Suivre ce guide http://guides.ovh.com/BackupsSurPlanWeb
- Utiliser la méthode n°2
- Récupérer ta sauvegarde via FTP
- Renommer le fichier xmlrpc.php
- Editer le fichier .htaccess comme le conseil Edouard pour n'autoriser l'accès à ton site qu'à ton @IP
- Faire une sauvegarde complète de ton site (on sait jamais ça pourrait servir)
- Vider de ton FTP toute trace de ton ancien site
- Pousser ton snapshot5 sur ton hébergement OVH via FTP.

Je pense que ça devrait le faire en procédant de cette façon.

ChristianM
17/07/2014, 20h31
Bonsoir à tous,

Merci beaucoup pour toutes tes précisions zeejow !!

J'aimerais effectivement tenter la restauration du Snap5 (qui remonte au 30 juin et devrait être clean) mais comment sécuriser le site durant cette opération ?

zeejow
17/07/2014, 20h13
Bonsoir Edouard,

Merci pour ces précisions. Mon CMS n'était effectivement pas à jour mais ce n'est vraisemblablement pas le cas pour Christian.

Penses-tu que ma démarche est viable ? A savoir tenter de supprimer les scripts apparus suite à mon dernier backup.

Ai-je un espoir de pouvoir récupérer mon snapshot4 voire 5 en envoyant une requête à vos services ? (actuellement je ne peux récupérer que le snap3 mais le site était déjà vérolé à ce moment là)

J'ajoute également d'autres informations récupérées tout à l'heure dans les logs d'hier (16 Juillet)

En fait j'ai eu un premier avertissement OVH le 11/07 (SPAM de mail) et le 16/07 mon site n'était plus accessible.

voici ce que je trouve dans les logs à l'heure à laquelle le site a été bloqué :

Mail d'OVH reçu à 13h26min21sec

50.87.144.20 MON_SITE - [16/Jul/2014:13:24:50 +0200] "POST /wp-content/plugins/tinymce-advanced/mce/advhr/xml.php HTTP/1.1" 200 42 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)"
62.76.191.131 MON_SITE - [16/Jul/2014:13:26:06 +0200] "POST /wp-includes/js/jcrop/press.php HTTP/1.1" 200 93 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/24.0"
Voilà les traces du hack. Reste à tenter de nettoyer pour que tout refonctionne comme avant.

Edouard
17/07/2014, 19h45
@zeejow : "le fichier est introuvable", c'est la première chose que fait le script du hacker (s'éxécute tout en disparaissant)

concernant le XMLRPC:

Il faut s'assurer que ton CMS est bien installé à la dernière version
Très souvent les failles proviennent des plugins ajoutés

astuce: tu peux mettre .htaccess durant les installation, ce qui t'assure que seul toi est connecté au site

Edouard
17/07/2014, 19h45
@zeejow : "le fichier est introuvable", c'est la première chose que fait le script du hacker (s'éxécute tout en disparaissant)

concernant le XMLRPC:

Il faut s'assurer que ton CMS est bien installé à la dernière version
Très souvent les failles proviennent des plugins ajoutés

astuce: tu peux mettre .htaccess durant les installation, ce qui t'assure que seul toi est connecté au site

zeejow
17/07/2014, 19h29
Bonjour Christian,

Je rencontre le même problème que toi

Problème rencontré : Executing deleted program
Commande apparente : ././ps
Je vais t'expliquer ma démarche pour apporter ma contribution à la résolution de ce problème.

1ère essai :
OVH m'indique que l’exécutable utilisé se nomme : /home/MON_SITE/www/wp-content/plugins/MON_PLUGIN/.nfs000000000242b25e000005d9.
Forcément (oui sinon c'est pas drôle) ce fichier (si c'est un fichier) est introuvable sur le FTP.
Après avoir sauvegardé le dossier censé héberger l’exécutable, je l'ai carrément supprimé .

Je relance la navigation WEB en suivant la procédure OVH via le FTP ("SITE CHMOD 705 /")

Tout content mon site est de nouveau joignable ! Problème, au bout d'environ 1 heure, OVH bloque de nouveau l'accès en m'indiquant la même erreur mais pas le même exécutable : /home/MON_SITE/www/wp-includes/js/jcrop/.nfs000000000431134b000005b9

=> J'ai compris, la tâche ne sera pas aussi simple que prévue ...

2ième essai:

Je décide de consulter les logs en date du premier blocage d'OVH.
J'ai cru comprendre (je suis novice dans ce domaine) que les requêtes de type POST étaient celles à surveiller. Les requêtes de type GET sont normales et son en fait la navigation des utilisateurs à travers ton site.

Voici un ligne que je retrouve TRES souvent à partir du moment du hack (et carrément moins souvent avant que les choses partent en sucette)

49.144.114.144 MON_SITE - [11/Jul/2014:04:51:11 +0200] "POST /xmlrpc.php HTTP/1.1" 200 410 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
L'adresse IP 49.144.114.144 est l'IP publique du poste ayant lancé la requête.
En utilisant un site de géolocalisation (comme http://www.dnsfrog.com/fr) je me rend compte que mon visiteur de la nuit (il est quand même 2 heures du mat' !!!) est situé aux Philippines ! Le lectorat de mon site est principalement situé en FRANCE.

Avant de me faire reprendre par d'autres, il est relativement facile de cacher la vrai localisation de son IP. Les résultats de géolocalisation sont donc à prendre avec des pincettes.
Tu multiplies ce genre de requête plusieurs centaines de fois avec des adresses IP qui proviennent de tout le globe et tu obtiens mon log de la nuit du 11/07 entre 2 heures et 3 heures du matin.

Je commence fortement à incriminer le fichier XMLRPC.php !
Après quelques recherches sur le net je m'aperçois que ce fichier est exploitable par les hackers (http://digwp.com/2009/06/xmlrpc-php-security/). Le post date de 2009 mais la faille est vraisemblablement toujours d'actualité.

Le fichier n'est pas vitale au bon fonctionnement de mon site (le gars explique dans son article à quoi il sert).

Je décide donc de le supprimer et de réactiver l'accès à mon site !

=> Ce coup ci ça a tenu un peu moins de deux heures avant de me faire bloquer de nouveau raaaaaaaaah ....

3ième essai (en cours) :

Je pense que tout plein de petit fichier à la con ont été mis en place et il faut donc que je les trouvent et les supprime ...

Ma méthode va consister à prendre une sauvegarde "propre" du site est de faire un diff entre les fichiers (uniquement les scripts pour commencer) présents sur le site actuellement vérolé et les fichiers présents dans la copie "propre" du site.

Je pourrais restaurer depuis cette sauvegarde mais pas de bol elle date du mois de Janvier 2014 ...

OVH fait des sauvegardes pour les fous comme moi qui ne pensent pas à mettre en place un backup régulier du contenu et de la BDD de leurs sites. http://guides.ovh.com/BackupsSurPlanWeb . Comme j'ai VRAIMENT pas de bol, j'ai besoin du snapshot n°4 et FORCEMENT OVH ne me propose que les snapshot 1 2 et 3 ...
Dans tous les cas, pour le moment je suis quasi certains qu'ils sont passés par le fichier XMLRPC.php pour veroler mon site (et peut être le tiens et ceux des autres personnes qui ont des soucis depuis quelques jours).
Supprimer le fichier sur un site déjà "cassé" ne change rien car le mal est déjà fait.
En revanche si tu repars d'une fresh install et que tu supprimes ou renomme le fichier que j'incrimine, y a des chances que tu sois à l'abris (jusqu'au prochain exploit bien entendu )

ChristianM
17/07/2014, 09h58
Citation Envoyé par fritz2cat
J A M A I S !!!

c'est dur à dire (et à entendre)

mais un site hacké, on ne peut plus y faire confiance.

Des portions du site peuvent avoir été contaminées, et même le contenu de la database peut être considéré comme suspect.

Sauver le contenu (sauf que tu as déjà un bon backup chez toi, n'est-ce pas ?)
Réinstaller à partir de zéro
Republier le contenu.

Eventuellement si on a la certitude que le hack est survenu le 11 juillet:
Restaurer une version d'avant le 11 juillet
Trouver rapidement par quelle faille les pirates sont entrés (puisqu'il y en a forcément une)
Fermer cette faille
OK OK je sens bien la réinstallation complète depuis zéro .... c'est pas trop ça le problème.

Mon vrai problème est que même en réinstallant complètement mon site il sera dans le même état qu'avant piratage donc vulnérable.

Comment donc trouver la faille ??
Et ensuite nous verrons comment la fermer (ou la supprimer)

gierschv
16/07/2014, 19h53
Citation Envoyé par uc76
Mon repertoire "www" de ce domaine est resté en CHMOD 705, ducoup je ne vois pas comment faire.
Bonjour,

C'est ton $HOME qu'il faut chmod en 705, les détails sont ici: https://www.ovh.com/fr/g1392.mutuali..._via_filezilla

uc76
16/07/2014, 17h19
Bonjour,

Même message que toi aujourd'hui (avec moins de traca de mon coté car c'est de la revente, je ne suis donc pas en charge du site).

La ou j'ai une question, c'est comment as tu réussi à réactiver ton site ?

Mon repertoire "www" de ce domaine est resté en CHMOD 705, ducoup je ne vois pas comment faire.

Merci

fritz2cat
16/07/2014, 13h43
Citation Envoyé par ChristianM
Question 1 : puis-je supprimer les fichiers suspects les yeux fermés ?
J A M A I S !!!

c'est dur à dire (et à entendre)

mais un site hacké, on ne peut plus y faire confiance.

Des portions du site peuvent avoir été contaminées, et même le contenu de la database peut être considéré comme suspect.

Sauver le contenu (sauf que tu as déjà un bon backup chez toi, n'est-ce pas ?)
Réinstaller à partir de zéro
Republier le contenu.

Eventuellement si on a la certitude que le hack est survenu le 11 juillet:
Restaurer une version d'avant le 11 juillet
Trouver rapidement par quelle faille les pirates sont entrés (puisqu'il y en a forcément une)
Fermer cette faille

ChristianM
16/07/2014, 12h49
Re,

Alors dans l'ordre ....

@ Fritz,
OVH a bien bloqué mon site. Une première fois hier matin. Je l'ai débloqué au soir mais ici je vais attendre d'avoir résolu la question une bonne fois pour toute.

@ Alex et Edouard,

De fait, je suis également mon site via Google analytics et j'ai constaté une forte augmentation du trafic (origine USA)

Question 1 : puis-je supprimer les fichiers suspects les yeux fermés ?
Questoin 2 : comment éviter que cela ne se reproduise (avant de débloquer l'accès au site)

La faille peut également provenir de ton theme, ou d'un plugin qui est à jour. Tu peux éventuellement logger tous les envois de fichier via formulaire, ca devrait te donner une bonne indication.
Hem hem désolé Alex mais en clair, comment faire pour "logger tous les envois de fichiers via formulaire" ???

Merci, merci et merci encore à tous pour votre bonne volonté.

Edouard
16/07/2014, 12h25
@ChristianM , tu peux voir la consommation CPU depuis la nouvelle interface client:

https://www.ovh.com/manager/web/login.html

La consommation est basse sauf depuis le 11 juillet,
où on constate une forte augmentation du nombre de connections sortantes ainsi l'augementation du temps de réponse du site.

ça correspond au hack que okiller à détecté.

Edouard
16/07/2014, 12h25
@ChristianM , tu peux voir la consommation CPU depuis la nouvelle interface client:

https://www.ovh.com/manager/web/login.html

La consommation est basse sauf depuis le 11 juillet,
où on constate une forte augmentation du nombre de connections sortantes ainsi l'augementation du temps de réponse du site.

ça correspond au hack que okiller à détecté.

fritz2cat
16/07/2014, 12h20
Apparemment ton site a été fermé:
Forbidden
You don't have permission to access / on this server.
Ca ressemble à un détection de site hacké, ça :-(

Alex.P
16/07/2014, 12h20
Voici la liste des fichiers suspects :

./uploads/i0edba.php
./themes/8z1ri0.php
./wppa-depot/ya.php
./languages/yv.php

La faille peut également provenir de ton theme, ou d'un plugin qui est à jour. Tu peux éventuellement logger tous les envois de fichier via formulaire, ca devrait te donner une bonne indication.

Alex.P

ChristianM
16/07/2014, 11h57
Bonjour Edouard,

Merci pour la réponse rapide.
Comme précisé dans mon message d'origine, j'utilise Wordpress et différents Plugins.
Wordpress, tout comme l'entièreté des Plugins sont régulièrement mis à jour.
Quand je dis régulièrement, je n'attends pas plusieurs mises à jour avant de bouger.
Je me connecte plusieurs fois par semaine, ne fut-ce que pour contrôler mon tableau de bord.

La réponse est donc oui le CMS tout comme les plugins étaient absolument tous à jour avant les incidents.

Bonjour Fritz2cat,

Et merci aussi d'avoir pris la peine de répondre.
Je sais que les galeries photos sont assez lourdes (c'est le principal défaut de Nextgen).
Le nombre de photos est volontairement limité et j'en réduis fortement la résolution et donc le poids.
Mon blog étant un blog photo, la galerie en est donc la raison d'être.
Passer sur un autre hébergement me coûterait d'avantage et mes photos ne me rapportent rien.
Quelle autre solution proposerais-tu ?
Le blocage de mon site, et sa faiblesse viendraient de là ?

Merci encore pour vos messages.

Citation Envoyé par Edouard
Bonjour, c'est l'éxécutable utilisé (la ligne en dessous de "commande apparente" dans ton mail) qui te donne le binaire en cause.
Les crackers utilisent des failles pour déposer un binaire, le lancer et le supprimer immédiatement.

Souvent cela signifie que ton site est faillible: si tu utilise un CMS, tu es bien sur la dernière version ?

Edouard
16/07/2014, 11h38
Bonjour, c'est l'éxécutable utilisé (la ligne en dessous de "commande apparente" dans ton mail) qui te donne le binaire en cause.
Les crackers utilisent des failles pour déposer un binaire, le lancer et le supprimer immédiatement.

Souvent cela signifie que ton site est faillible: si tu utilise un CMS, tu es bien sur la dernière version ?

Edouard
16/07/2014, 11h38
Bonjour, c'est l'éxécutable utilisé (la ligne en dessous de "commande apparente" dans ton mail) qui te donne le binaire en cause.
Les crackers utilisent des failles pour déposer un binaire, le lancer et le supprimer immédiatement.

Souvent cela signifie que ton site est faillible: si tu utilise un CMS, tu es bien sur la dernière version ?

fritz2cat
16/07/2014, 11h37
Attention, les galeries photos pompent énormément de temps CPU , par exemple lorsqu'on on ouvre une galerie et que le serveur doit générer les miniatures ou des photos 800x600 à partir d'un répertoire plein d'originaux en 24 mégapixels.
Dans un environnement mutualisé c'est très moyen de mettre le serveur à genoux quand il faut partager équitablement les ressources.

ChristianM
16/07/2014, 08h54
Bonjour,

Voici deux fois que mon site est bloqué par Okillerd, certainement pour une très bonne raison.

Hébergement : Perso2014

Site perso qui tourne sous le CMS - Wordpress avec différents plugins dont le plus important est Nextgen Gallery Pro

WP ainsi que tous les plugins sont mis à jour plus que régulièrement.

J'ai supprimé hier soir un fichier qui me paraissait douteux, j'ai activé hier soir le firewall. Et ce matin le site est à nouveau bloqué.

Je sais qu'on ne badine pas avec la sécurité j'aimerais dès lors résoudre le problème.

Merci pour votre aide.

Les deux blocages semblent avoir la même raison mais pas au même endroit.

Problème rencontré : Executing deleted program
Commande apparente : ././ps