Génération de pages malveillantes sans fin...

Nouveau WRInaute
Bonjour,

Depuis juin, je suis maintenant la cible d'une attaque massive.

Les urls ont ces formats (entre autres):
/jwxxb/b1227289.html
/tag/qeifz

Il semble s'agir de liens cloacking à priori. Sur mon site, il y a 21 pages et actuellement, GSC me donne 1'280 liens indexés (et la totalité mes 21 pages n'y figurent même pas) et 155'000 liens non indexés (2000 crées en l'espace de 2 jours...). Le trend de ces dernière est toujours en hausse pour les erreurs 404 (dernier crawl 29 octobre). Par contre, des pages réellement indexées, les dernières malveillante datent du 26 juin.

Afin de contrer la problème, j'ai filtrés les pages qui posent problème dans mon htaccess de cette manière:

RewriteEngine On
RewriteRule ^[a-zA-Z]{5}/[a-zA-Z0-9]{7}\.html$ - [G]
RewriteRule ^[a-zA-Z]{5}/[a-zA-Z0-9]{8}\.html$ - [G]
RewriteRule ^tag/[a-z]{5}$ - [G]
RewriteRule ^[a-zA-Z]{5}\.html$ - [G]
RewriteRule ^config/entry/review/add/product_id/ - [G]
RewriteRule ^a2f6product/product_id/ - [G]

J'ai également fournis un sitemap pour le français et l'anglais dont google semble ne pas tenir compte car depuis le 7 octobre, il n'a toujours pas indexés mes véritables pages. D'après mon access.log, google semble bien passer ces pages en 410:

66.249.72.232 - - [01/Nov/2024:00:35:05 +0100] "GET /kyewj/z1799181.html HTTP/1.1" 410 1104 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)

Comme l'attaque semble continuer, j'aimerai savoir si c'est la une bonne méthode ? Est-ce mieux d'ajouter une règle de ce type pour ajouter noindex à ces pages ?

<IfModule mod_headers.c>
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}/[a-zA-Z0-9]{7}\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}/[a-zA-Z0-9]{8}\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/tag/[a-z]{5}$ [OR]
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}\.html$
Header set X-Robots-Tag "noindex"
</IfModule>

J'ai un peu de peine à trouver une solution pérenne, car j'imagine qu'avec ce code, google ne reviendra pas effacer toutes ces pages frauduleuses déjà indexées.

De plus, cela ne permet pas de trouver la source de spamming et de l'éliminer et il en arrive sans arrêt (2000 en 2 jours...)! Qu'elles ne soient pas indexées n'enlève rien au fait que google les détectes comme des 404 dans le gsc (non 410).

Quel intérêt de continuer cette attaque sachant que les liens ne sont plus indexés et que mon site est déjà aux pâquerettes ?

Merci pour votre aide,
Sylvain
 
Dernière édition par un modérateur:
WRInaute impliqué
Afin de contrer la problème, j'ai filtrés les pages qui posent problème dans mon htaccess
Il faut que tu identifies ce qui créée ces pages, leur exploration et indexation par Google n'est qu'un problème secondaire.

D'abord parce que tu as une faille de sécurité sur ton site, et qu'il ne faut pas la laisser béante et exploitée.

Mais ensuite parce que tu ne fais qu'envoyer un code d'erreur à qui viendra explorer la page. Ça implique que la page est consultée (donc potentiellement de la ressource consommée). Ça donne le site que le site est rempli d'URL abandonnées.

D'après mon access.log, google semble bien passer ces pages en 410
Le log te dit ce qui est envoyé au robot d'exploration, il ne t'assure pas de la façon dont Google appréhende ces pages. Il est toutefois probable que Google interprète bien l'URL en 410 (si c'est ce que lui dit le serveur), mais le log en lui-même ne permet pas de t'en assurer.

Quel intérêt de continuer cette attaque
La plupart des attaques reposent sur le nombre plutôt que sur la qualité. Rechercher comment ton site contourne la création de page supposerait d'y consacrer des ressources (checker le code HTTP de l'URL), ils n'y consacrent probablement pas de moyens.
 
Nouveau WRInaute
Bonsoir,

Merci à vous pour votre retour. Il m'est difficile de juger de l'efficacité de wordfence, malcare, ainsi qu'un antivirus de mon hébergeur; infomaniak, mais tous me disent que le site est propre et qu'il n'y a rien de suspect. Comment aller plus loin pour découvrir cette faille ?

C'est exactement du japanese-keyword.hack. Mais si les liens sont générés à la volée, comment identifier la source. Lorsque je check mon access.log, c'est quasiment toujours les googlebot qui tentent de crawler ces pages frauduleuses mais d'où lui proviennent elles ?

Dans la GSC, les back links sont propres également.
 
WRInaute occasionnel
Bonjour,
Quelque chose que je ne comprends pas : si le log indique que le bot crawle la page, c'est donc qu'elle existe bien sur le serveur ?
Si on appelle une de ces URL bidons (non filtrées par .htaccess) elles répondent ?
 
WRInaute occasionnel
Bonsoir,

Lis cela : https://web.dev/articles/fix-the-japanese-keyword-hack?hl=en - tu peux essayer avec hl=fr mais c'est traduit très approximativement.

Et suis les étapes une à une : je pense que tu n'y coupes pas. C'est fastidieux ... Voir également "additional ressources" en bas de page.

Pour ma part, si c'est possible, j'essaierai de bloquer l'accès au serveur/site avec une simple demande de mot de passe d'abord - genre mot de passe apache ou - carrément un "deny from all" sauf ta propre ip - pour être sur - voir avec ton hebergeur ou te faire aider. Parce que là, tu peux très bien nettoyer, et, te faire "hacker" de nouveau dans la foulée - sans idée du procédé utilisé tu peux tourner en rond longtemps.

Un simple :

```
require ip tonipv4 tonipv6
```

Placé au début de ton .htaccess devrait suffire - tout en haut - https://ip.lafibre.info/ - pour te protèger le temps d'éliminer les causes.

Si cela continu ... c'est que tu n'as pas trouvé ...

C'est peut-être un peu radical ? Qu'en pensez vous ?

Cordialement,

Eric

PS : tu peux aussi autoriser les bots Google à crawler : une liste figure ici : https://github.com/mitchellkrogza/a...pache_2.4/custom.d/globalblacklist.conf#L8445 ou leurs envoyer une 503.
 
Dernière édition:
Nouveau WRInaute
Bonjour à vous et merci pour votre aide!

Pour pomination, a vrai dire, c'est un des soucis de ce hack. Lorsque je check mon site avec screaming frog par exemple, il ne voit aucun erreurs 404 (ou 410).

Ces pages donnent, lorsque je les check, des erreurs 404 mais en réalité, c'est du cloaking (contenu caché) avec des produits généralement illégaux ou autres... Du coup, ces pages sont surement ailleurs, sur d'autres sites, peut-être des milliers... hyper complexe en fait!

Pour Eric, est-ce que ces pages sont générées par mon site ou d'autres ? C'est le gros point flou, je n'arrive pas à comprendre l'origine de cela. Donc, si je mets en place ta méthode, tu penses que ça permettra à 100% d'assurer que cela ne vient pas de mon site ? Je peux le faire en mutualisé et il me suffit de mettre "require ip monipv4 monipv6" au début de mon htaccess ?

Pour les nouvelles:

Je suis passé de 155'000 à 158'000 pages non indexées (grises) / de 1280 à 137 pages indexées (vert) ce weekend. Que dois-je en conclure ? L'infestation continue mais mes règles ont tendance à permettre la désindexation de pages frauduleuses...

Sinon question (bête), mes DNS étant gérés pas Cloudflare, j'ai plus vite fait d'étudier leurs logs que ceux de mon hébérgeur non ?

Merci et bonne journée à vous!
Sylvain
 
WRInaute impliqué
est-ce que ces pages sont générées par mon site ou d'autres ?
Ce sont des pages de ton site, elles proviennent nécessairement de ton site (même si ton site peut appeler du contenu distant, ça reste produit par ton site).

Voici comment peut fonctionner ce type d'attaque : les fichiers de ton site sont modifiés de sorte à générer du contenu lorsqu'ils sont appelés avec une certaine URL. Derrière, ces URL sont diffusées sur d'autres site.

Mais le problème ce n'est pas la diffusion de ces URL, mais bien le fait que des fichiers aient été modifiés sur ton serveur pour permettre de répondre à ces URL.
 
WRInaute accro
C'est en effet ce que je lui ai dit plus haut avec le lien concernant le japanese keyword hack. Le plus simple est de faire le tour de tous les répertoires, fichiers, dossiers et voir ceux qui ont une date de modification/création qui date du début de ton hack. Voir aussi si des fichiers n'ont pas du code qui commence, par exemple, par : 'base6'.'4'.'_de'.'code'; (il y a bien longtemps qu'ils ne mettent plus base64_decode lol). Tu peux aussi faire un check avec Sucuri, même si ce n'est pas fiable à 100%.
 
WRInaute impliqué
qui ont une date de modification/création qui date du début de ton hack
Regarder les dates de fichier suspectes oui, mais pas nécessairement à l'apparition du hack, ça peut rester dormant quelques temps, justement pour éviter qu'une restauration soit efficace : le site est piraté le 1er du mois, les pages apparaissent uniquement à partir du 15, on tente une récupération le 30 en rétablissant la version du 14 (que l'on croit antérieure au hack), mais en fait il s'agit déjà d'une version vérolée. Je donne les dates en jour mais ça peut rester dormant plus longtemps.
 
Nouveau WRInaute
Merci pour vos éclaircissements!

Thierry, je pense qu'effectivement, si je n'arrive pas à trouver les failles, il faudra m'y résigner. Par contre, la réinstallation de fichiers par défaut sur un site, le mien tourne avec avada, autant refaire le site à zéro car j'imagine le nombre de bugs à régler par la suite...

Mais avant, j'essaie de fermer le plus de portes possibles pour tenter d'enrailler l'infestation. Le scan manuel... par ou commencer, j'ai des masses de résultats impossibles à traiter avec un base64_decode classique (la tienne est malheureusement introuvable), faire le tri dans tout ca... que pourrais je chercher de bien spécifique et avec quelles restrictions pour éviter de scanner la ou il n'y a pas besoin ?

Sinon, hier, j'avais des pics d'activités sur mon site. 3 ips chinoises que généraient du trafic anormal (mon site étant mort cliniquement depuis le hack). Ce trafic, parmi celui de mon hébergeur et de cloudflare, donnait un code de réponse NOERROR. Est-ce qu'on peut en déduire qu'elles avaient accès à mon site ?

Merci encore!
 
WRInaute accro
Tu as essayé de scanner tout le site avec Sucuri pour commencer ? Il y a sans doute d'autres plugins disponibles je pense.
 
WRInaute impliqué
C'est là que je suis content d'avoir créé mon propre CMS, c'est tout simple, j'ai peu de fonctions, mais je sais au moins que s'il y a un problème, je saurais l'identifier. J'ai ainsi un répertoire d'administration que je peux effacer sur le serveur, et remplacer par les fichiers propres de mon ordinateur. Il n'y a pas cela, là ? Je peux aussi faire cela avec l'intégralité du site. Il n'y a que s'il y avait un code malicieux dans ma BDD que je serais vraiment ennuyé.
 
WRInaute impliqué
le mien tourne avec avada
Avada, c'est du WP. Alors, c'est forcément un peu l'enfer de réinstaller WP avec tous ses plugins, mais ça peut se faire, sans perdre sa config. Enfin, en théorie du moins, après je ne suis pas connaisseur de WP.

que pourrais je chercher de bien spécifique et avec quelles restrictions pour éviter de scanner la ou il n'y a pas besoin
@cthierry a fourni de bonnes pistes.

Si tu as accès aux fichiers avec un ftp (j'espère que c'est la cas, c'est le minimum sur un hébergement sérieux), tu peux voir la date de modification des fichiers. Il faut se concentrer sur les fichiers PHP. En principe, les fichiers d'un même dossier devraient avoir la même date. Un fichier avec une date isolée devrait attirer l'attention (ce n'est toutefois qu'un indice, il a pu être modifié de façon légitime).
Si tu as accès à un terminal sur ton serveur, tu peux lister les fichiers php avec leur date de modif avec (ça peut prendre un peu de temps à s'exécuter, c'est normal) :
Bash:
find $1 -type f -name "*.php" -exec stat --format '%Y :%y %n' "{}" \; | sort -nr | cut -d: -f2-

je suis content d'avoir créé mon propre CMS
C'est à double tranchant. D'un côté on évite les failles utilisées en série. Plus de 99,9 % des tentatives d'attaque que je vois sont des tentatives à l'aveugle sur /wp-login.php, /wp-2020.php, /wp-admin/setup-config.php, /google.php, /default.php, /admin/controller/extension/extension/Not_Found.php, /modules/mod_simplefileuploadv1.3/elements/udd.php, /mad.php, /clen.php, /wp-admin/dropdown.php, /.well-known/pki-validation/about.php, /webadmin.php, /atomlib.php, bref un nombre considérable de tentatives, beaucoup sur du wordpress ou des plugin wordpress, y compris pour des URL qui n'ont jamais eu de WP installé.

D'un autre côté, on s'expose à des failles béantes, d'injection en tout genre, ou d'autres maladresses, parce que tout vigilant que l'on puisse être, quelque simple que le site soit, je m'estime toujours moins compétent que les type de chez WP.

Bref, potentiellement plus de failles, mais dont l'exploitation est moins probable.

Je dis ça, mais je suis de la team "fait maison". Faut quand même avoir en tête les inconvénients, et être scrupuleux sur les bases de la sécu.
 
WRInaute impliqué
Je n'utilise pas WP, mais j'ai tous les jours des requêtes vers des pages /wp-admin... wp-login, je suis content qu'ils ne trouvent rien.
 
WRInaute occasionnel
Pour Eric, est-ce que ces pages sont générées par mon site ou d'autres ? C'est le gros point flou, je n'arrive pas à comprendre l'origine de cela. Donc, si je mets en place ta méthode, tu penses que ça permettra à 100% d'assurer que cela ne vient pas de mon site ? Je peux le faire en mutualisé et il me suffit de mettre "require ip monipv4 monipv6" au début de mon htaccess ?

Bonsoir,

Cela va bloquer l'accès au site à tous, sauf à/aux IPS autorisées.

Cela suppose que tu puisses modifier ton .htaccess par FTP ou autre - pour tes IP publiques https://ip.lafibre.info/ - si tu es chez free ou que tu as une ip fixe, pas besoin de changer.

Je pense que tu peux faire comme cela dans ton .htaccess - à placer au tout début :

```
<RequireAny>
Require ip TonIPV4
Require ip TonIPV6
</RequireAny>
```
Une fois en place, tu enverras des 403 à tout le monde, pour toutes requêtes, sauf à toi (à/aux ip autorisées).

C'est très radical.

Si tu veux whitelister les bots Google/Bing - Là, c'est à toi de juger/décider - mais je bloquerai tout - tu ajoutes les lignes que tu trouveras ici : https://github.com/mitchellkrogza/a...pache_2.4/custom.d/globalblacklist.conf#L8445 entre les balises <RequireAny> . Ils ne seront pas bloqués.

Cela te permettra au moins de figer les choses, pour te donner le temps d'examiner fichiers, base ... avec l'un des outils suggérés : https://web.dev/articles/fix-the-japanese-keyword-hack?hl=en .

Ici les ip à whitelister pour Sucuri (Require ip ...) :

https://wordpress.org/support/topic...e-to-properly-scan-your-site-timeout-reached/

A priori tu peux les demander là : info@sucuri[.]net (https://wordpress.org/support/topic...e-to-properly-scan-your-site-403-forbidden-2/)

Je ne connais pas cet outil. Mais il semble populaire.

Tu as essayé de scanner tout le site avec Sucuri pour commencer ? Il y a sans doute d'autres plugins disponibles je pense.

C'est la suite minimum logique, je pense.

Bon courage,

Eric
 
Nouveau WRInaute
Bonjour a tous,

Merci encore pour vos retours, c'est très agréable d'avoir de l'aide dans des moments aussi compliqués! ;)

Eric, malheureusement, je ne peux pas bloquer complétement le site. Déjà, j'hésite a mettre le "under attack" sous cloudflare pour ne pas perdre de visites...

D'un autre coté, l'infestation continue, je suis maintenant a 70'000 pages (404 alors que ce sont maintenant des 410) et 88'000 crawled - currently not indexed soit 160'000 pages frauduleuses. Une partie a encore été crawlées hier... donc je n'arrive rien a bloquer...

Tout ça, ce sont des pages non indexées pas google car le seul point positif, c'est que j'ai pu désindexer les pages frauduleuses de mon site. Mais il manque toujours des pages valides malgré mes sitemaps...

Sinon, que ce soit avec sucuri, malecare, wordfence, quttera... aucun ne me trouve de backdoors, tous m'annoncent un site clean. Plus ça avance, plus j'ai envie de tout ré-installer car ça me semble la seule option possible et je n'arrive vraiment pas a voir ou ils entrent sur mon site pour créer leur urls foireuses...
 
Dernière édition:
WRInaute impliqué
Mais comment sont créées ces pages ?
Est-ce que n'importe quel visiteur peut créer des pages ? Je suppose qu'il faut avoir un statut d'administrateur ? Il doit y avoir quelque chose qui distingue ces mauvaises pages des bonnes dans la BDD, pour ensuite sous phpmyadmin faire une requête SQL pour désactiver les droits de leur auteur (si c'est possible), et ensuite effacer les entrées de cet auteur. Il restera à trouver comment il a pu faire cela, et comment l'empêcher de recommencer, mais cela nettoiera le site.
 
WRInaute occasionnel
Bonsoir,

Peut-être que si ton site est clean, c'est parce que ces pages "fake" sont créées avec une méthode clean ?

As tu pensé à changer mot de passe, clef api ...

As tu un cache ? Pour voir si tu trouves ces fameuses pages ...

As tu des logs ? si Google crawle, en principe tu as des traces pour chaque demande de page.

Pour les logs, si tu n'y a pas accès, voir avec ton hebergeur : demande lui si possible les logs d'accès à ton serveur ou de chercher si tu as bien les urls "fake" crawlées ...
 
Nouveau WRInaute
Bonjour,

Alors, je n'ai aucun processus qui permet la création de pages sur mon site, c'est un site de photographies avec des galeries. Je suis le seul utilisateur et je serai averti par wordfence ou sucuri si quelqu'un se logguait. Donc, de ce côté, ça semble sûr.

Le firewall de wordfence tourne a plein régime mais il semble bien faire son job en plus du WAF chez Cloudflare.

Comme l'a expliqué emualliug, ce doit être un fichier d'installation qui à été modifié et qui doit permettre la connection à des ordis distants qui créer ces pages. Quoi qu'il en soit, elles ne sont absolument pas présente physiquement sur mon hébergement et invisibles également avec screaming frog.

eldk, je pense également que c'est le souci, rien d'apparent mais ce maudit code fait le job. J'ai rajouté le 2FA pour mon site et cloudflare, j'ai changé toutes les clés de sécurité avec sucuri hier.

Quand tu parle de trouver les pages dans le cache, peux-tu m'en dire plus ?

Sinon, j'ai accès à tous les logs possibles et innimaginables mais je pense que je ne sais pas les lires correctement. Déjà, j'imagine que c'est Cloudflare qui aura le plus d'infos a me remonter car c'est lui qui gère mes DNS (ou c'est juste une idée?), mais par ou commencer et comment m'y prendre sachant que je ne peux pas remonter au début de l'attque.

En fait, mon site original qui était en ligne depuis 14 ans à disparu du jour au landemain en juin (page blanche et irrecuperable d'après infomaniak). C'était une usine à gaz non protégée et portes ouvertes aux hackers. Le 1 juillet je mets en ligne le nouveau site en urgence, sans protéction (et oui, je ne me savais par être la cible d'une attaque a ce moment). Je reviens de vacances, mon site se retrouve à la 11ème page et c'est à ce moment (fin août) que j'ai vu l'étendue des dégats dans la GSC. Et impossible de remonter avant juin alors que l'attaque à demarré bien avant...

Bon, voilà, si quelqu'un a un peu de patience pour m'aiguiller dans les logs, c'est avec plaisir! Typiquement, si je me refère au traffic, le 10.10 semble être une date à vérifier... mais, cela semble trop évident, est-ce que ce type de hack génère beaucoup de trafic ?

1730966500694.png

Merci de m'avoir lu et bonne journée,
Sylvain
 
Dernière édition:
Nouveau WRInaute
Pour info, voici mon indexing chez gsc, on peut voir que le 10 octobre, il n'y a pas un pic spécifique mais par la suite, on a l'apparition de nouvelles pages de manière plus soutenue (plus de 10'000 pages en moins d'un mois). Est-ce que le hack permettrait de faire apparaitre des pages petit-à-petit au lieu d'un coup ?

1730969316661.png
 
WRInaute impliqué
ce doit être un fichier d'installation qui à été modifié et qui doit permettre la connection à des ordis distants qui créer ces pages
oui et non.

La plupart des sites sont dynamiques : les pages sont faites à la volée.

Prenons ce forum, il n'y a pas dans le dossier "forum", un sous dossier "t" qui contienne la page "generation-de-pages-malveillantes-sans-fin.202342", et pourtant l'URL "/forum/t/generation-de-pages-malveillantes-sans-fin.202342" de ce site pointe bien vers cette discussion.

Le site a une page qui va "analyser" l'URL, comprend qu'il s'agit d'un post du forum, va chercher en base de donnée les messages publiés dans la discussion, les noms des utilisateurs, etc. et "fabriquer" à la volée du code HTML qui est renvoyé à l'internaute.

Revenons à ton cas, sans connaître la faille, difficile d'être tout à fait affirmatif, mais voici ce qui est possible. Une page du site a été modifiée pour traiter certaines URL et alors générer des pages HTML à foison.

Tout ça pour dire que personne n'accède à ton site pour "créer" des pages, ou du moins ce n'est pas nécessaire. Les fichiers existent déjà sur ton site.

Il ne sert donc à rien de renforcer la sécurité sur la connexion, le pare-feu ou que sais-je.

elles ne sont absolument pas présente physiquement sur mon hébergement et invisibles également avec screaming frog.

Oui, et c'est normal, j'ai expliqué ci-dessus pourquoi.

Est-ce que le hack permettrait de faire apparaitre des pages petit-à-petit au lieu d'un coup

Une fois encore, sans en savoir plus, je ne peux pas être affirmatif, mais dans l'idée, oui, les pages peuvent être créées à l'infini.

La proposition de @eldk n'est pas superflue. En cas de piratage, changer le mot de passe est un sain réflexe, d'une part parce que peut être que quelqu'un s'est connecté en ayant récupéré / deviner ton mdp. Ce n'est pas le plus probable, le plus souvent c'est une faille au sein d'un fichier qui est exploitée. Mais, du fait de cette intrusion, il est possible que certains "secrets" de ton site aient pu être compromis, typiquement l'identifiant / mot de passe de connexion à la base de donnée.

Je ne me savais par être la cible d'une attaque a ce moment

Sur internet, tout ce qui est connecté est une cible potentielle.

L'essentiel des pirates n'identifient pas une cible en fonction de ce qui est derrière, mais de la faille qui existe. C'est ce que je disais avec mes logs qui montrent des tentatives d'accès à des certaines pages (parfois propres à certains plugin WP) dans l'espoir d'exploiter une faille déjà connue. Ce sont clairement des tentatives de robot, personne n'a cherché à "me" cibler, sinon ils se seraient rendus compte que le site ne tournait pas sur WP et qu'il était vain d'exploiter les failles connues de WP.
 
WRInaute discret
Hello,

D'après mon expérience, je trouve Wordfence très efficace! Par défaut il ne scanne pas les fichiers en dehors de l'installation Wordpress, mais tu peux l'activer ainsi que le scan des images et des exécutables.. essayes de relancer un scan en activant ces options, si elles ne le sont pas déjà ^^
 

Fichiers joints

  • Screenshot_20241107_161110_Chrome.jpg
    Screenshot_20241107_161110_Chrome.jpg
    88.2 KB · Affichages: 4
WRInaute occasionnel
As tu un cache ? Pour voir si tu trouves ces fameuses pages ...

As tu des logs ? si Google crawle, en principe tu as des traces pour chaque demande de page.

Ici, ceux sont des logs Apache, ceux sont ceux qui sont créés à chaque demande d'url :

Code:
66.249.79.36 - - [07/Nov/2024:02:12:39 +0100] "GET /urlpage HTTP/1.1" 200 31470 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.69 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 568 32067

Là c'est une visite de robot Google. Essaies de voir si Googlebot effectue des requetes sur les url "fake". A priori oui. Mais vérifie ...

Si tout ce que tu as mis en place : WAF cloudflare, wordfence (voir la suggestion de LEUF ci-dessus) ... ne repére rien, n'empeche rien ... cela vient forcement de l'intérieur.

Tu es bien en hebergement mutualisé ?

Essaies de voir si l'un de tes plugins wordpress est concerné : https://github.com/advisories?query=wordpress - https://www.cvedetails.com/vulnerab...2337/product_id-4096/Wordpress-Wordpress.html

Ton CMS précédent était bien wordpress ?

https://www.seroundtable.com/google-search-console-404-error-report-1000-urls-36728.html

https://search.brave.com/search?q=wordpress+thousand+urls+generated&source=web
 
Dernière édition:
Nouveau WRInaute
Bonjour,

Pour emualliug, merci pour ces compléments, le fonctionnement de ces hacks et définitivement un sacré casse-tête...

Pour Leuf, j'ai effectivement scanné mon site avec plusieurs plugins dont wordfence (free) et sucuri (free). As-tu la version payante, ça vaut la peine ?

Pour eldk, le nombre de vulnérabilité dans avada fait peur. Le fait que j'aille laissé le site sans protection cet été à probablement permit aux hackers de véroler mon site de l'intérieur car effectivement, je n'arrive rien à trouver avec des scans.

Sinon, oui, google bot essaie bien d'accéder a ces pages foireuses, la dernière fois c'était il y a 4 jours.

J'ai mis depuis hier le site sous under attack pour voir si la création de page prend fin mais si mon site créer de lui-même les pages, il n'y aurait même pas besoin de s'y connecter...

Pour les logs, sachant que je dois trouver un ou des IP qui arrivent à se connecter à mon site, il vaut mieux vérifier les access.log de mon hébergeur plutôt que cloudflare non ? Si vous avez des conseils pour la recherche dans ces logs, je suis bien partant...

Merci et belle journée!
 
Nouveau WRInaute
Je suis actuellement dans les accès du jour et j'ai encore 500 entrées de ce type: 66.249.72.224 - - [08/Nov/2024:13:18:14 +0100] "GET /dsqix/x1400495.html HTTP/1.1" 410 1104 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X

D'un autre coté, voici les utilisateurs qui sont venus sur mon site depuis début novembre:

URL Hits Données
2a01:e0a:472:a70:3979:f392:3dfa:aa6b 403 439 138663066
crawl-66-249-66-168.googlebot.com 10 95 4330834
crawl-66-249-79-36.googlebot.com 7 78 1893039
ec2-35-180-54-117.eu-west-3.compute.amazonaws.com 3 43 1733676
ec2-3-92-128-229.compute-1.amazonaws.com 12 14 348325
hzas98.bvserver.net 11 11 275
hzas88.bvserver.net 3 4 1014
hzas95.bvserver.net 3 3 75
hzas86.bvserver.net 3 3 75
ec2-54-205-142-92.compute-1.amazonaws.com 1 2 44157
ec2-35-159-22-118.eu-central-1.compute.amazonaws.com 0 1 249

Le premier est clairement suspect, il a fait beaucoup de hits 403 sur 439 et beaucoup de volume de données.

Maintenant la question est de savoir ce qu'il est venu voir exactement, comment m'y prendre ?
 
Dernière édition:
Nouveau WRInaute
Pardon, dans mes dernière stats, le premier chiffre (403 par ex pour la première adresse) correspond au nombre de fichiers accédés et le second 439, au nombre de hits...
 
WRInaute discret
À un moment donné c'est bien beau de blablater, mais sans agir concrètement tu vas jamais avancer...

Déjà primo, ton site est compromis mais il est toujours en ligne, t'attends quoi ? Que tes visiteurs se fassent phisher ou pire ?

La première chose à faire c'est de bloquer tout le trafic, comme eldk l'a suggéré.
 
Nouveau WRInaute
Mon site est en mode under attack (cloudflare) depuis hier soir, il affiche une page durant quelques secondes pour checker s'il s'agit d'un humain ou non.

Malheureusement, je ne peux bloquer completement l'accès car il doit rester visible pour mes clients potentiels (il reste trouvable dans les adresse locales de google), je suis indépendant et c'est ma seule visibilité. De plus, cela finirait de me faire tomber dans les abysses du réferencement naturel a priori.

Après, je ne suis pas un spécialiste du domaine, du coup je marche sur des oeufs.

Tu as la version payante de wordfence ?
 
WRInaute impliqué
en mode under attack (cloudflare)

Oui, mais ça sert à rien. Extrait de la doc cloudflare :

Cloudflare’s I’m Under Attack Mode performs additional security checks to help mitigate layer 7 DDoS attacks. Validated users access your website and suspicious traffic is blocked.
Bref de la protection anti DDoS, c'est à dire une attaque par déni de service (des millions de requêtes sont adressées en même temps à un serveur pour le saturer).

Tu ne fais pas l'objet d'une attaque DDoS.

Pareil, toutes les analyses de log ne servent à rien. Oui tes pages sont consultées, sans doute par des robots, peut-être des robots malveillants, et alors ?

Même si tu identifiais les IP malveillantes et que tu les bloquais (ça n'a plus beaucoup de sens aujourd'hui avec les VPN et le cloud computing, mais passons), ton site resterait vérolé.

Tu as, à mon sens, quatre alternatives :

1. Repérer la ou les pages modifiées (je t'ai indiqué comment les trier par date et potentiellement repérer une modification étrange) et les rectifier

2. Restaurer une version du site dans une version antérieure, si possible les fichiers "techniques" uniquement (pas la BDD, pas le contenu)

3. Réinstaller le site, en important le contenu de l'ancien (mais pas ses modules, réinstalle-les plutôt), fais-toi un sous-domaine temporaire protégé par htaccess / htpasswd pour éviter toute indexation / consultation, comme si c'était en pré-prod, et vérifie que tout est en ordre, puis bascule ton nom de domaine vers ce nouveau site

4. Tout reprendre de zéro
 
Nouveau WRInaute
Oui, c'est un sacré casse-tête!!! Je pensais naïvement trouver les ip malveillantes et dans la foulée, savoir quels fichiers elles atteignent pour pouvoir mettre fin à ce problème.

Pour tes alernatives emualliug, que ce soit sur GSC ou chez mon hébérgeur, impossible de remonter plus en arrière que le 29 juin et le hack était déjà en place, je n'ai donc malheureusement pas la date précise de la production de ces pages. Pas de backup sains non plus, ça serait tellement plus simple de faire "récurer" a fond mon hébergement et re-installer.

En gros, il me reste l'alternative 4 que j'essaie d'éviter au max bien évidemment et sinon, payer sucuri ou wordfence pour un nettoyage professionel manuel...

Est-ce qu'un spécialiste wordpress pourrait me confirmer les dires de chat gpt, c'est à dire que sur un site sain les répertoires wp-admin et wp-includes ne devrait être strictement pareils (taille et texte) entre mon site en production et les fichier d'installation de base wordpress. Ca me semble bizarre mais bon...

Car en plus de sucuri, quttera, malcare, wordfence, j'ai vérifié les modifications avec winmerge et il y a énormement de fichier php qui différes entre ceux de mon site et l'origine.

Une piste possible ?
 
WRInaute discret
Il peut aussi s'agir de dns cache poisoning, dans ce cas là tu verras rien sur ton FTP ni sur ta BDD.. et même une réinstallation n'y fera rien! https://fr.wikipedia.org/wiki/Empoisonnement_du_cache_DNS

Tu dois vérifier les entrées dns et activer DNSSEC si ce n'est pas déjà fait ainsi que vérifier si ton compte chez ton registrar n'est pas compromis, tu t'es peut-être fait phishé sans t'en apercevoir, perso je reçois régulièrement des faux mails d'OVH.

J'utilise la version gratuite de Wordfence, mais à mon humble avis acheter la version payante ne va pas t'avancer à grand chose.
 
WRInaute accro
Est-ce qu'un spécialiste wordpress pourrait me confirmer les dires de chat gpt, c'est à dire que sur un site sain les répertoires wp-admin et wp-includes ne devrait être strictement pareils (taille et texte) entre mon site en production et les fichier d'installation de base wordpress. Ca me semble bizarre mais bon...
Oui.
 
WRInaute occasionnel
Bonsoir,

Les bots de Google viennent vraiment chercher ces "mauvaises" url. - (logs serveur)

Donc quelqu'un les leurs fournis vraiment. Pas sur que ce soit ton site. Pose la question à partir de l'interface de la Search Console.

Pour la vérification des fichiers, demande à ton hébergeur. Si tu es en mutualisé, surtout sur une offre avec CMS, c'est de sa responsabilité. En principe, il a les outils pour contrôler et devrait te prévenir en cas de "contamination", ou tout au moins, y remedier.

Cordialement,

Eric
 
Nouveau WRInaute
Leuf, comme tu me l'as suggéré, je suis actuellement en train d'activer DNSSEC. Ce sera déjà une bonne chose.

Maintenant, quand je lis ton lien, je me dis que bosser dans la sécurité internet, ça à de l'avenir. Dans mes entrées DNS, j'avais ces fameuses 3 IP chinoises que j'ai bloqué sous cloudflare, le reste de l'activité c'est des IP de mon hébergeur et de cloudflare et je n'ai rien constaté de bizarre. Maintenant, si ce n'est même pas moi qui génère ces URL, que faire ?

Marie-Aude, merci. Après verification, ils sont bien identiques, mauvaise pioche.

eldk, je ne sais pas comment trouver cela sur la GSC, tu peux me dire comment m'y prendre stp ? Pour ce qui est de mon hébergeur; Infomaniak, leur support s'est limité a me proposer ses partenaires...
 
WRInaute occasionnel
eldk, je ne sais pas comment trouver cela sur la GSC
En bas, dans les menus : "envoyer des commentaires". Puis tu suis la procédure.

Maintenant, si ce n'est même pas moi qui génère ces URL, que faire ?
Rien. Si ces urls aboutissent à des 404.

Quel cache utilises tu de base pour wordpress ?
 
Dernière édition:
Nouveau WRInaute
J'utilise WP Fastest Cache. Si elles aboutissent à du 404, ça reste problèmatique pour mon SEO, non ?

Sinon, j'ai pu voir qu'en date du 11.10 ma page contact à été scannée 1237x par ma propre IP pour tenter d'injecter du sql...

  • "GET /contact/ HTTP/1.1" - "-6051) OR 2619=5164--"
  • "GET /contact/ HTTP/1.1" - "-7446') OR 6573=3642--"
  • "GET /contact/ HTTP/1.1" - "-6527\" OR 1573=6502--"
On voit clairement sur le graphe du GSC que les pages malveillantes s'étaient stabilisées puis on repris de plus belle après cette date.

1731343411758.png

Bon, je pense que la mise en ligne d'un nouveau site est de plus en plus obligatoire car je ne vois pas le bout de ce problème. En plus de Sucuri, Wordfence et WPScan (et afin de ne plus revivre cette désagréable expérience d'avoir bossé des mois sur un site que personne n'aura finalement vu), si vous avez des bons plans ou best practices pour sécuriser WP, je suis partant.

Merci encore pour votre aide !
 
WRInaute impliqué
Pour tes alernatives emualliug, que ce soit sur GSC ou chez mon hébérgeur, impossible de remonter plus en arrière que le 29 juin
Le premier point peut néanmoins se tenter, il se base sur la date système du fichier. Mais si tu n'as pas de sauvegarde pour récupérer, il perd une partie de son utilité. Et vu l'ampleur de l'attaque (cf. infra), ça a pu être maquillé.
si vous avez des bons plans ou best practices pour sécuriser WP,
Éviter de multiplier les plugin, chaque composant supplémentaire est une source d'insécurité.
Dans tous les cas, chercher des plugin maintenus et largement adoptés.
Conserver un système à jour.

ma page contact à été scannée 1237x par ma propre IP pour tenter d'injecter du sql.
Quand tu dis, ta "propre IP", c'est celle de ton ordi ou de ton serveur ?

Si c'est celle de ton serveur, il faut vraiment corriger en fond le problème, parce que ça voudrait dire que ton site (à moins que ce soit un autre sur le même serveur) fait des requêtes HTTP, qu'il peut donc servir de tête de pont pour faire d'autres attaques, et que potentiellement certaines attaques peuvent êtres menées plus en profondeur sur ton site ou poursuivies.
 
WRInaute occasionnel
Dans un premier temps, je changerai le mot de passe du compte admin qui a accès au ftp. (le compte admin chez l'hébergeur)
Ensuite, je changerai également le mot de passe du compte de la base de données.
Et le mot de passe du compte admin dans WordPress.

Dans les 3 cas, mettre un mot de passe très complexe.
Pour cela on peut s'aider de KeePass par exemple, pour générer et stocker les mots de passe.
Si malgré ça, la génération de pages malsaines continue, c'est que le ver est dans le fruit, à savoir un process qui tourne dans le contexte WordPress.
 
WRInaute occasionnel
J'utilise WP Fastest Cache. Si elles aboutissent à du 404, ça reste problèmatique pour mon SEO, non ?

Pour les 404 :

- si les urls fournies proviennent de ton site cela peut être problèmatique. Je ne sais pas s'il y a d'autres avis, expériences ???
- si les urls fournies proviennent de domaines "alac.n", avec lesquels tu n'as rien à voir, pas de liens de ton domaine vers ceux des producteurs de "faux" liens, je ne pense pas que cela pose problème ...

Pour Fastest Cache : il y a quelques failles pas glop qui ont été corrigées - tout dépend de quelle version tu es parti pour ton site :

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wp-fastest-cache

Tu peux verifier pour tes autres plugins (verifie pour ton plugin de formulaire de contact si tu en as un) - plusieurs failles ont pu être exploitées :

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins

----

Si tu as moyen de repartir sur une base propre (d'avant la/les failles exploitées) : bdd + fichiers ... + mises à jour wordpress + mises à jour des plugins ... et déploiement quand tout est prêt (à jour ...) sur un nouvel hebergement.

Tu peux également tenter cela avec une version locale de ton site(il y a quelques controles pour wordpress) :

https://git.spip.net/spip-contrib-outils/spip_cleaner/-/blob/main/clean_spip.sh?ref_type=heads

Ce qui m'étonne, c'est le manque de coopération et de réaction de ton hébergeur. C'est bien un hébergement mutualisé ?

Cordialement,

Eric
 
Nouveau WRInaute
Pour moi, tu as un cron ou autre qui fait tourner en boucle un script qui fait de l'injection à la volée.
J'ai vérifié les cron jobs et a priori, rien de mauvais. Après, je l'ai fait dans wordpress, je ne sais pas si des crons peuvent être cachés. Mais ça semble pourtant une bonne piste...

Quand tu dis, ta "propre IP", c'est celle de ton ordi ou de ton serveur ?
C'est l'IP de mon ordi

Dans un premier temps, je changerai le mot de passe du compte admin qui a accès au ftp. (le compte admin chez l'hébergeur)
Ensuite, je changerai également le mot de passe du compte de la base de données.
Et le mot de passe du compte admin dans WordPress.
C'est fait, j'ai tout modifié accès hébérgeur, mot de passe FTP et BDD. Pour l'admin wordpress, je l'ai changé il a peu et il semble bien sécurisé. De plus, sucuri m'informe du dernier login, cela me permet de savoir si c'est bien moi. Mais effectivement, le ver semble dans la pomme. Ce qui est étonnant, c'est que je devrais trouver quelque chose dans les crons...

Pour Eric, effectivement WP Fastest Cache à été compromis et ce matin, j'ai aussi trouvé aussi Ninja Forms Styler Lite (que je servais juste pour le design de mon bouton...). Question: même si j'ai une faille dans un plugin, ce qui malgré les mises-à-jour auto est largement possible le temps qu'on s'en apérçoivent, normalement le firewall de wordfence devrait gérer la menace, non ?

Bon, sinon, j'ai également fait un feedback a la GSC de mon problème. Est-ce que d'après votre expérience ils répondent ?

Est-ce que tu peux me dire en 2 mots ce qu'est Spip et comment ça fonctionne ?

Merci pour votre aide!
 
Dernière édition:
WRInaute accro
C'est l'IP de mon ordi ??? Et tu as fait un scan de ton PC avec un soft comme Zhpcleaner ou autre ? Car si c'est ton IP qui frappe à la porte de ton site alors le vers n'est plus dans la pomme mais le cheval dans Troie ^^
 
WRInaute impliqué
C'est en effet inquiétant, et bizarre en même temps, pourquoi ça irait pile de son ordi à son site…

Peut-être un mauvais script JS, mais ça m'étonne qu'il n'ait pas été détecté.

Regarder ce qu'il se passe avec les outils de développements et pointer les requêtes faites en filtrant par "GET /contact/ HTTP/1.1", et voir ce qui en est l'initiateur.

Est-ce que l'user-agent qui a fait les tentatives d'injection SQL correspond à ton navigateur, @Sly74 ?
 
Nouveau WRInaute
J'ai testé mon ordi avec Zhpcleaner, pas mal ce programme. Rien trouvé. Peut-être du ip spoofing ?

Voilà un petit florilège de requetes que j'ai eues, il ne pourrait pas s'agir d'un test d'un plugin de sécurité ? Impossible de voir le navigateur pour le coup.

[11/Oct/2024:00:07:51 +0200] "GET /contact/ HTTP/1.1" 200 20592 "mon site" "-6002'))) OR 5437=3009 AND ((('fMHk' LIKE 'fMHk"
[11/Oct/2024:00:09:27 +0200] "GET /contact/ HTTP/1.1" 200 20592 "mon site" "-5245) OR MAKE_SET(3150=3150,3822)-- vvgE"
[11/Oct/2024:00:08:27 +0200] "GET /contact/ HTTP/1.1" 200 20592 "mon site" "-1271) WHERE 4840=4840 OR 3973=(SELECT (CASE WHEN (3973=7294) THEN 3973 ELSE (SELECT 7294 UNION SELECT 8323) END))-- uukX"
[11/Oct/2024:00:08:51 +0200] "GET /contact/ HTTP/1.1" 200 20592 "mon site" "-2444') AS lOGO WHERE 4905=4905 OR 2083=8749#"

Regarder ce qu'il se passe avec les outils de développements et pointer les requêtes faites en filtrant par "GET /contact/ HTTP/1.1", et voir ce qui en est l'initiateur.
Comment faire cela ?

Petite question en passant, on est bien d'accords que le DNSSEC devrait être initialement activé chez mon registar (BlueHost) avec les enregistrements DS fournis par CloudFlare qui lui gère mes nameservers ? Car le gars de BlueHost me soutient qu'ils ne peuvent rien activer et c'est CloudFlare qui doit le faire.
 
WRInaute occasionnel
Est-ce que tu peux me dire en 2 mots ce qu'est Spip et comment ça fonctionne ?
Le lien que je t'ai donné est un script bash à l'origine destiné au CMS SPIP, mais qui permet de faire également quelques vérifications de fichiers pour les sites WordPress. A utiliser avec prudence.

Regarder ce qu'il se passe avec les outils de développements et pointer les requêtes faites en filtrant par "GET /contact/ HTTP/1.1", et voir ce qui en est l'initiateur.
Comment faire cela ?

Allez dans la console dev de ton navigateur (CTRL+shift+i ou F12) : onglet network/reseau : colonne "initiator" ou "initiateur?" : ici la 8 eme colonne :

Capture d’écran du 2024-11-13 18-40-18.png

Mais tout cela me semble bizarre ???

1 - aucune alerte/blocage de ton hebergeur
2 - du SQL "bidon?" dans la colonne "use agent" - si je ne me trompe pas - des logs APACHE (si c'est apache)
3 - Personne, CloudFlare ... Antivirus ... Personne ne detecte rien.

4 - Google qui collecte des urls non déclarées ... D'ailleurs quand tu sélectionnes "Toutes les pages envoyées" dans "Indexation des pages" de GSC, cela donne quoi ?


Pour ma part, je mettrai le site en 403 temporairement.
Mettrai en pause le PC/MAC temporairement. En utiliserai un autre durant cette même période.

Et attendrai de voir ... ce que Google remonte.

Là, je sèche un peu ... Ils manquent pas mal de clefs.
 
WRInaute occasionnel
1 - aucune alerte/blocage de ton hebergeur
2 - du SQL "bidon?" dans la colonne "use agent" - si je ne me trompe pas - des logs APACHE (si c'est apache)
3 - Personne, CloudFlare ... Antivirus ... Personne ne detecte rien.

4 - Google qui collecte des urls non déclarées ... D'ailleurs quand tu sélectionnes "Toutes les pages envoyées" dans "Indexation des pages" de GSC, cela donne quoi ?


Pour le 2, je viens de trouver un site sur Google (une boutique) sur lequel les "related search terms" affichés quand tu utilises sa recherche : affiche des liens qui mélangent SQL (à peu prés identique à celui contenu dans tes logs) et termes en langue asiatique dans le texte de chaque lien pour la page de résultat.


domain.tld_index.php_catalogsearch_result__q=iso%27%29%29+ORDER+BY+1--+CacH.png

Pour ma part, je mettrai le site en 403 temporairement.
Mettrai en pause le PC/MAC temporairement. En utiliserai un autre durant cette même période et verifierai base, fichiers ...

Et attendrai de voir ... ce que Google remonte.

Là, je sèche un peu ... Ils manquent pas mal de clefs.
 
Nouveau WRInaute
Pour eldk, mettre le site en 403, c'est le risque d'une desindexation totale de google et cela fait maintenant 15 ans que j'utilise mon nom de domaine et que j'ai obtenu plus de 180 avis clients, si je perds ça, je laisse tout tomber... Après, c'est vrai que la on serait vraiment sûrs!

Sinon, j'ai vérifié ce que tu m'as dit (les initiateurs), mais que devrais-je trouver si la page est vérolée ?

Effectivement, personne ne detecte rien... Dernier essai réalisé sur un bakcup offline de l'entierté du site avec ClamAV de Cisco... la encore, rien de rien.

Mon ordi a été testé aujourd'hui avec Malwarebyte et il y a quelques jours avec le programme que m'a conseillé cthierry et il est propre. Je suis sous Win11.

J'en perds mon latin et je pense transmettre le bébé à malcare pour une analyse manuelle. Quelqu'un à déjà testé leurs services ? Ces boites ayant généralement leurs agents en Inde, j'ai un peu peur. Sucuri à par exemple très mauvaise presse...

Sinon, après check avec la commu Google, 2 experts diamant m'ont expliqué que les 404, tant qu'elles ne viennent pas directement de mon site (sitemap foireux ou liens internes cassés par ex) ne sont pas négatifs pour le placement de mon site. Ca me rassure un peu...
 

➡️ Offre MyRankingMetrics ⬅️

pré-audit SEO gratuit avec RM Tech (+ avis d'expert)
coaching offert aux clients (avec Olivier Duffez ou Fabien Faceries)

Voir les détails ici

coaching SEO
Discussions similaires
Haut