[RÉGLÉ] Site accessible en direct mais pas via des moteurs de recherche classiques

[sam68140]

Bonjour,

J’ai un problème très particulier qui me fait tomber les derniers cheveux qui me restent et met aux abois un collègue informaticien et spécialiste web pourtant très calé (mais non spécialiste de joomla). Je précise que, contrairement à lui, je suis un simple amateur.

Le site en question (www.amisdelemm.fr) fonctionne sous Joomla 4.4.3, PHP 8.3

Le site est parfaitement accessible en direct et tout semble fonctionner correctement. Plusieurs scans ont montré qu’il semblait clean.
Pourtant… lorsqu’on passe par un moteur de recherche comme google ou bing par exemple, ces derniers renvoient le site vers des pages de spams ou d’erreurs. J’ai mis le site en "Rapport d'erreurs : maximum"… pour voir s’afficher les erreurs.
Autre étrangeté avec Qwant, il n’y a aucun souci.
Mon ami informaticien pense qu’il s’agit d’un script malicieux qui n’agit que dans certains conditions, par exemple via un moteur de recherche connu (Qwant l’est moins).

Qu’en pensez-vous ?
Que faudrait-il faire ?

Avec mes remerciement,
Cordialement,

[pmleconte]

Bonsoir,

Il y a effectivement un problème avec la recherche Google.

En vérifiant les entêtes http de votre site avec https://securityheaders.com/ , il manque quelques blocages afin d'empêcher ce type de problème : Strict-Transport-Security , Content-Security-Policy

Cela se fait à partir du plugin "en-tête http" dans votre admin.

Au niveau de Google, utilisez vous la console Google Search ? https://search.google.com/

Pascal

[sam68140]

Bonjour,
Merci pour votre prompte réponse. Je viens à l'instant de faire les modifications dans "Système - En-têtes HTTP". J'ai activé les deux éléments. Pour le moment, cela n'a pas eu d'effet. Je suppose qu'il faut attendre un peu ?
J'ai effectivement la Google search. Il m'indique "aucun problème critique".

Merci par avance pour vos lumières,
Samuel

[pmleconte]

Bonsoir Samuel,

Le but du Strict-Transport-Security est d'empêcher les attaques de type "homme du milieu" (qui arrive à passer entre votre site et l'utilisateur).

Concernant le délai, il s'agit du monde google où le temps ne passe pas de la même manière.

D'autre part, j'ai vu que votre site est aussi accessible en http, ce qui n'est pas normal et doit être bloqué par votre fichier .htaccess.

Cela peut être fait par l'ajout des lignes :

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}​

De plus, au niveau de la config. Joomla, il faut mettre le site https uniquement : Configuration globale, onglet Serveur, paramètre Forcer HTTPS.

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Cela permettra d'enregistrer votre site sur https://hstspreload.org/ qui permet d'avoir un niveau de sécurité complémentaire.

Pascal

[daneel]

Bonsoir Samuel,

On a déjà évoqué ce cas qui consiste à un hacker de détourner le référencement plutôt que de supprimer le site.
Cela veut dire qu'il a potentiellement piraté votre site.

Pas de panique, il suffit en premier de vérifier les dates de modifications des fichiers.
Bien souvent, il insère son code dans le fichier htaccess.

Son code malicieux permet de détecter la provenance donc la page affiché précédemment. Si c'est Google, il détournera vers un site de pub ce qui lui permet de monétiser ses efforts. Si la page n'est pas google mais le fait d'avoir utilisé un autre moteur de recherche ou d'avoir tapé directement l'adresse donnera accès au site afin que l'administrateur ne voit pas immédiatement son action.

Donc dans un premier temps, vérifier les dates des fichiers et dossiers, examinez le htaccess.
Si ce n'est pas dans le fichier .htaccess, il aura été encore plus malin en encodant dans les fichiers du site ( index.php ou dans le index du template) voir d'une extension.

Une fois le hack repéré, il s'agira bien evidemment de faire le nettoyage complet en écrasant les fichiers "core" par la version officielle (voir la fonction dans mise à jour de joomla).

N'hésitez pas à vérifier les mises à jour et les extensions tierces notamment la gestion de formulaire.

ce que propose pmleconte est bien évidemment un plus mais globalement, il faudra revoir la sécurisation sans oublier les sauvegardes.

[sam68140]

Bonsoir Samuel,

Le but du Strict-Transport-Security est d'empêcher les attaques de type "homme du milieu" (qui arrive à passer entre votre site et l'utilisateur).

Concernant le délai, il s'agit du monde google où le temps ne passe pas de la même manière.

D'autre part, j'ai vu que votre site est aussi accessible en http, ce qui n'est pas normal et doit être bloqué par votre fichier .htaccess.

Cela peut être fait par l'ajout des lignes :

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}​

De plus, au niveau de la config. Joomla, il faut mettre le site https uniquement : Configuration globale, onglet Serveur, paramètre Forcer HTTPS.

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Cela permettra d'enregistrer votre site sur https://hstspreload.org/ qui permet d'avoir un niveau de sécurité complémentaire.

Pascal

Bonsoir Pascal,

J'ai réalisé tout ce que vous préconisez à part l'enregistrement sur https://hstspreload.org car cela me dit :
Error: Invalid Certificate Chainhttps://amisdelemm.fr uses an incomplete or invalid certificate chain. Check out your site at https://www.ssllabs.com/ssltest/

Le code dans le .htaccess peut être placé n'importe où ? Je l'ai mis tout haut.

Est-ce qu'un plan sitemap (OSmap) envoyé à Google peut avoir une utilité dans le cas de mon problème ?

Merci beaucoup,
Samuel

[sam68140]

Bonsoir Samuel,

On a déjà évoqué ce cas qui consiste à un hacker de détourner le référencement plutôt que de supprimer le site.
Cela veut dire qu'il a potentiellement piraté votre site.

Pas de panique, il suffit en premier de vérifier les dates de modifications des fichiers.
Bien souvent, il insère son code dans le fichier htaccess.

Son code malicieux permet de détecter la provenance donc la page affiché précédemment. Si c'est Google, il détournera vers un site de pub ce qui lui permet de monétiser ses efforts. Si la page n'est pas google mais le fait d'avoir utilisé un autre moteur de recherche ou d'avoir tapé directement l'adresse donnera accès au site afin que l'administrateur ne voit pas immédiatement son action.

Donc dans un premier temps, vérifier les dates des fichiers et dossiers, examinez le htaccess.
Si ce n'est pas dans le fichier .htaccess, il aura été encore plus malin en encodant dans les fichiers du site ( index.php ou dans le index du template) voir d'une extension.

Une fois le hack repéré, il s'agira bien evidemment de faire le nettoyage complet en écrasant les fichiers "core" par la version officielle (voir la fonction dans mise à jour de joomla).

N'hésitez pas à vérifier les mises à jour et les extensions tierces notamment la gestion de formulaire.

ce que propose pmleconte est bien évidemment un plus mais globalement, il faudra revoir la sécurisation sans oublier les sauvegardes.

Merci beaucoup pour cette réponse,
Cela va bien au-delà de mes connaissances. Je vais voir si mon ami peut jeter un coup d'oeil à ces fichiers...

Merci encore,
Bonne soirée,

Samuel

[sam68140]

Bonsoir Samuel,

Le but du Strict-Transport-Security est d'empêcher les attaques de type "homme du milieu" (qui arrive à passer entre votre site et l'utilisateur).

Concernant le délai, il s'agit du monde google où le temps ne passe pas de la même manière.

D'autre part, j'ai vu que votre site est aussi accessible en http, ce qui n'est pas normal et doit être bloqué par votre fichier .htaccess.

Cela peut être fait par l'ajout des lignes :

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}​

De plus, au niveau de la config. Joomla, il faut mettre le site https uniquement : Configuration globale, onglet Serveur, paramètre Forcer HTTPS.

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Cela permettra d'enregistrer votre site sur https://hstspreload.org/ qui permet d'avoir un niveau de sécurité complémentaire.

Pascal

Bonsoir Pascal,

J'ai réalisé tout ce que vous préconisez à part l'enregistrement sur https://hstspreload.org car cela me dit :
Error: Invalid Certificate Chainhttps://amisdelemm.fr uses an incomplete or invalid certificate chain. Check out your site at https://www.ssllabs.com/ssltest/

Le code dans le .htaccess peut être placé n'importe où ? Je l'ai mis tout haut.

Est-ce qu'un plan sitemap (OSmap) envoyé à Google peut avoir une utilité dans le cas de mon problème ?

Merci beaucoup,
Samuel

[pmleconte]

Bonjour Samuel,

En lançant le site à partir de la recherche google dans Edge, j'ai une erreur :



Cela montre la présence d'un fichier CSS suspect dans administrator/components/com_akeebabackup.

Donc, comme suggéré par Daneel, un recherche de virus sur votre site est nécessaire. Essayez avec https://github.com/cavo789/aesecure_quickscan

D'autre part, votre site est en mode debug. Il faut éviter de le laisser car cela peut donner des informations aux hackers et, pendant un temps, c'était une porte ouverte.

Pascal

[sam68140]

Bonjour,

Merci pour votre réponse !
J'ai retiré le mode debug et surtout voyant dans votre message qu'il y avait un souci avec Akeeba je l'ai désinstallé et là... tout semble de nouveau OK. ! En tout cas de mon côté.
Mais c'est tout de même gênant car c'est un composant pour la sauvegarde du site...

J'hésite du coup à le réinstaller...

Un composant aussi connu peut-il être infecté nativement ou très rapidement après son installation ?
Pour info, pour l'installer j'étais passé par l'administration de joomla via système > Extension >Installer à partir du web

En tout cas merci, en attendant, pour votre aide

Samuel

[pmleconte]

Bonjour,

OK, votre akeeba backup est infecté dans votre environnement, mais le composant d'akeeba n'a pas de virus à son installation.

Vous devez avoir un virus sur votre site qui copie ses fichiers dans les répertoires connus de Joomla, dont akeebabackup.

Donc, il faut chercher l'intrus et sécuriser l'accès à votre site.

On doit considérer que votre site a été "visité", donc, de base, il faut changer les mots de passe de la base de données, de l'administration, de FTP, vérifier les utilisateurs (si vous en avez un qui serait admin alors qu'il ne devrait pas).

A partir de votre dernière sauvegarde akeeba, il faut la passer à la moulinette aesecure_quickscan sur un environnement en local, à condition d'avoir un bonne antivirus sur votre PC.

Pascal

[sam68140]

Bonjour Pascal,

Mon ami informaticien a repris la main et est en train de voir tout cela (quick scan, mots de passe)...
On va bientôt en savoir plus...

Merci Pascal,

Samuel

[RobertG]

Bonjour,

Attention au fait que quickscan trouve de nombreux fichiers suspects dans Akeeba, fichiers pourtant sains, rendant le repérage d'éventuels fichiers réellement infectés difficile.

[Easyone]

Bonjour,

Je suis la personne qui essaye d'aider Samuel avec le site mais je dois avouer que je ne m'y connais plus guère avec Joomla et l'administration d'un serveur web. Dans tous les cas, voici les étapes que nous avons passés :

- Il y a environ un mois, mise à jour de l'ancien Joomla 3 (un ancien site créé avec Joomla 1 ou 2 déjà à l'époque) vers Joomla 4. Le même type d'erreur apparaît après quelques jours. Il y avait beaucoup de composants de Joomla 3 ou plus ancien qu'on a pas pu désinstaller car cela crashait.
- Samedi 6 avril, on installe un nouveau Joomla 4 sur le même hébergement mais dans un répertoire différent, avec nouveau mot de passe administrateur Joomla et une base de donnée différente. On récrée le contenu et on migre le nom de domaine vers le nouveau site. Après quelques jours, les messages d'erreurs apparaissent.
- Aujourd’hui, j'ai lancé aesecure_quickscan mais il y a des centaines de matchs, étant donné qu'il y a tout un tas de base64_encode, cookie, shell dans les fichiers de Joomla. Je pense qu'il s'agit de faux positifs mais comment être sûr ? Je n'ai pas les connaissances suffisantes pour changer cas par cas. Je viens de changer le mot de passe (S)FTP au cas où. Le mot de passe de la base de donnée et le mot de passe administrateur Joomla ont été créé il y a une semaine.

Je ne sais pas trop quoi faire maintenant. Comment trouvé ce qui pose problème et le nettoyer ?

[pmleconte]

Bonjour,

Comme écrit par Robert, il y a des faux positifs. Cela dépend du nombre d'extensions/modules/plugins que vous avez installés.

Cela prend un peu de temps, mais, en général, on finit par trouver des fichiers ne faisant pas partie des extensions (nom bizarre), ou contenant, comme dans votre cas, des commandes eval.

Pascal