[RÉGLÉ] perte d'accès à mon interface aeSecure

[FlodAriege]

Bonsoir,

Ne sachant trop où poster ça, je le pose là dans la catégorie générale.
Je précise que j'ai d'abord essayé le forum aeSecure, mais sans réponse depuis ... pfiou, je dirais des lustres* , je me tourne vers la communauté :

Depuis samedi, j'ai perdu l'accès à ma console aeSecure.
Erreur 500.

J'ai de suite pensé que j'avais fait une bourde avec le htaccess, et ai donc tenté de contrôler le htaccess avec une version que j'avais sauvegardée alors que tout fonctionnait parfaitement, mais le plugin Compare de Notepad++ ne voit pas d'autres différences que quelques redirections que j'ai ajoutées depuis.

Je ne peux pas "juste" désactiver le htaccess pour voir si le problème vient de là car dans ce cas je perdrais carrément l'accès à mon admin (ça m'est déjà arrivé par le passé).

Je voudrais savoir UNE chose:
Dans la mesure où mon front-end et mon back-end fonctionnent tous deux normalement, est-il possible que l'erreur 500 sur l'interface aeSecure puisse ne PAS être de mon fait ?
Que pourrais-je faire pour le vérifier ?

Si SimonG passe par là, ça serait super sympa de me donner un petit coup de main.

Merci d'avance !

Flo


* pour être précise, seulement deux jours sur ce problème, mais vu que ma précédente question, également posée dans le forum privé et s’intitulant quand même 'site attaqué' n'a pas reçu la moindre réponse depuis le 12/04, je n'ai pas beaucoup d'espoir d'en recevoir sur celle-ci avant le mois prochain (cool ! c'est demain le mois prochain )

[cavo789]

Bonjour Flo

... Erreur 500. J'ai de suite pensé que j'avais fait une bourde avec le htaccess,

En effet, c'est un excellent réflexe puisqu'une erreur 500 est la plupart du temps lié à la configuration serveur du site (donc très probablement liée au .htaccess).

le plugin Compare de Notepad++ ne voit pas d'autres différences que quelques redirections que j'ai ajoutées depuis.,

Attention car je pense que ce n'est pas complet : le type d'encodage est crucial pour le fichier .htaccess. Sous Notepadd++ il faut choisir "UTF-8" (pas celui mentionnant "BOM"); cela se fait dans le menu Encodage.

Pas sûr que le plugin Compare vérifie, aussi, le type d'encodage.

Dans la mesure où mon front-end et mon back-end fonctionnent tous deux normalement, est-il possible que l'erreur 500 sur l'interface aeSecure puisse ne PAS être de mon fait ?,

J'imagine que tu parles de ton fichier .htaccess se trouvant à la racine de ton site (front-end); du coup s'il était mauvais ton front-end ne serait plus accessible ainsi que, probablement, ton back-end.

Tu mentionnes que tu as accès aussi aeSecure devrait l'être aussi.

As-tu ajouté / modifié un fichier .htaccess dans le dossier /aesecure ?

En cet instant, je ne vois pas trop pourquoi l'interface aeSecure retournerait une erreur 500 et pas ton site. Si tu as toujours cette erreur, une seule chose à faire : puisque 500 est une erreur serveur, va dans ton fichier error.log càd le fichier des erreurs de ton hébergement. Tu as sûrement une icône "Erreur" dans ton cpanel pour consulter ce fichier. (je parle du fichier des erreurs et pas celui des accès).

Bonne journée.

[FlodAriege]

Bonsoir Christophe,

En effet, c'est un excellent réflexe puisqu'une erreur 500 est la plupart du temps lié à la configuration serveur du site (donc très probablement liée au .htaccess).

A force d'échanger avec toi et quelques autres ici

Attention car je pense que ce n'est pas complet : le type d'encodage est crucial pour le fichier .htaccess. Sous Notepadd++ il faut choisir "UTF-8" (pas celui mentionnant "BOM"); cela se fait dans le menu Encodage.

Quand j'ouvre mon htaccess avec Notepad++, si je clique sur le menu Encodage, je vois bien un point en face de Encoder en UTF-8, et non en face de Encoder en UTF-8 (avec BOM), donc je pense que de ce côté-là c'est bon.

Pas sûr que le plugin Compare vérifie, aussi, le type d'encodage.

Non en effet, il ne compare que le contenu texte.

J'imagine que tu parles de ton fichier .htaccess se trouvant à la racine de ton site (front-end); du coup s'il était mauvais ton front-end ne serait plus accessible ainsi que, probablement, ton back-end.

Oui, je parle bien de celui qui est à la racine.
Et en effet, chaque fois que j'ai eu une erreur de syntaxe ou autre dans ce htaccess, j'ai perdu l'accès, au minimum, au front-end.
ce qui n'est pas le cas.

Tu mentionnes que tu as accès aussi aeSecure devrait l'être aussi.

???
Si c'est ce que tu voulais dire : j'accède normalement à mon back-end.
Mais si je clique sur Aesecure, la page qui s'ouvre n'affiche rien d'autre qu'une erreur 500:

Error 500 - Internal server error

Un problème inattendu est survenu.
Veuillez réessayer ultérieurement.

As-tu ajouté / modifié un fichier .htaccess dans le dossier /aesecure ?

Non, je ne touche jamais au contenu de ce dossier.

En cet instant, je ne vois pas trop pourquoi l'interface aeSecure retournerait une erreur 500 et pas ton site. Si tu as toujours cette erreur, une seule chose à faire : puisque 500 est une erreur serveur, va dans ton fichier error.log càd le fichier des erreurs de ton hébergement. Tu as sûrement une icône "Erreur" dans ton cpanel pour consulter ce fichier. (je parle du fichier des erreurs et pas celui des accès).

Aaah... euuuuh... je n'ai rien de tel (je suis chez 1&1).
Dans le dossier logs, j'ai :
- une série de access.log.xx.gz (ou xx représente des chiffres genre 11 12 ou encore 11.2 12.1)
- une série de dav.log.xx.gz
- info.php
- info.php5
info.pl
- info.py
- last_traffic
- mail.log et une série de mail.log.xx.gz
- sftp.log et une série de sftp.log.xx.gz
- traffic.db

J'ai aussi un dossier forensic contenant un lock-12345679.log
Qu'est-ce que tu appelles le cpanel ? le panneau d'administration chez mon hébergeur ?

Bonne soirée, et merci d'avoir pris du temps pour me répondre, je sais que rien ne t'y oblige.

[cavo789]

Bonsoir

Aaah... euuuuh... je n'ai rien de tel (je suis chez 1&1).

Cela me semble impossible. 1&1 ne te donne pas accès à une icône / fonction pour consulter le log des erreurs ? Cela me semble impossible car c'est quand même sacrément basique.

Pose-leur la question ;-)

- info.php
- info.php5
info.pl
- info.py

Pas très logique de trouver des scripts (=fichiers exécutables) dans un dossier /log; pas logique du tout.

(bon, recherche Google et je vois https://www.webrankinfo.com/forum/t/...ur-1-1.178579/; donc oui 1&1 semble faire ça; ils sont comiques les gars chez eux :-D)

Je dirais bien "ce sont des virus" mais vu la répétition du nom "info" cela pourrait être un phpinfo (il faudrait éditer les fichiers pour savoir).

Mais pas logique; ça, c'est certain : /log ... c'est pour les logs, jamais pour des scripts.

Question: est-ce que ce soir tu as encore ton erreur 500 sur la page /aesecure/setup.php?xxxx (ta clef) ?

[FlodAriege]

Bonjour Christophe cavo789

Oui, j'ai toujours mon erreur 500 quand j'essaie d'ouvrir l'interface aesecure en cliquant sur le lien présent en haut de l'admin, qui ouvre le lien : mondomaine.fr/aesecure/setup.php?xxxxxxxxx

Pour ce qui est de l'absence du fichier error.log, j'ai consulté l'aide 1&1 et trouvé une méthode, mais jusqu'ici elle ne donne aucun résultat (pas de fichier error.log généré après que j'ai tenté d'ouvrir aeSecure et donc obtenu une erreur 500). Pour ce qui touche à ce fichier error.log, j'ai ouvert un post et j'en suis là de mes essais :

https://forum.joomla.fr/forum/ressources-pour-le-logiciel/h%C3%A9bergement-web-et-noms-de-domaine/2000114-comment-activer-les-logs-d-erreur-chez-1-1?p=2000124#post2000124

Merci .

PS: juste au cas où, je tente à nouveau d'appeler à l'aide SimonG : es-tu là ?

[FlodAriege]

Bonsoir Christophe cavo789

Alors, comme me l'a appris RobertG, dans le fichier access.log.18.6 j'ai tous les accès de la journée, dont mes tentatives d'accéder à aesecure.
Je ne sais pas si ce fichier te donne les infos qu'aurait donné le error.log que tu souhaitais, mais voici ce que j'y lis :

99.999.999.9 - - [04/May/2019:14:56:13 +0200]
"GET /aesecure/setup.php?xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx HTTP/1.1"
500 421
www.mondomaine.fr "https://www.mondomaine.fr/administrator/index.php"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.108 Safari/537.36" "-"

Est-ce que ça aide ?

EDIT du 05/05 16:00:
Je n'accède plus non plus à mon robots.txt
Chrome renvoie une erreur 500, mais Firefox renvoie lui une erreur 401 (enfin, Firefox me demande mon mot de passe - celui que j'ai mis en place dans aeSecure - puis affiche une erreur 401 si je refuse de répondre).
Or, je me souviens maintenant que lorsque j'ai réinstallé mon site après le changement de template, j'ai activé l'option aesecure (dont j'ai oublié le n° et le nom exact) qui vise à empêcher les curieux de farfouiner dans le robots.txt... mais je ne pensais pas que "les curieux" ça incluait Google

[FlodAriege]

Bonjour,

J'ai fini par résoudre mon problème toute seule.
Le support aesecure, c'est plus ce que c'était....

Si ça arrive à quelqu'un d'autre, voici la solution :

Je me suis aperçue que l'adresse du fichier .htpasswd indiquée dans le .htaccess du dossier aesecure était incorrecte (obsolète depuis le 16/12/2018, soit depuis plus de 4 mois).
Le 16/12, c'est la date à laquelle j'ai restauré une sauvegarde sur un sous-domaine sur lequel j'ai mené des tests jusqu'au 7 avril dernier, date à laquelle j'ai passé ce sous-domaine en production en faisant pointer mon domaine sur le dossier qui le contient.

Ce qui est très étrange, c'est que je sais que j'ai accédé sans aucun problème à aesecure pendant toute la période entre le 16/12 et jusqu'au 07/04 inclus (je prends beaucoup de notes sur ce que je fais, quand je le fais et quel résultat j'obtiens, et j'ai réglé pas mal d'options aesecure le 7 avril)

J'ai donc corrigé, dans le .htaccess du dossier aesecure, le nom du dossier qui contient mon site en production (chez 1&1, le site est déployé dans un dossier, pas directement à la racine de hébergement), et tout est rentré dans l'ordre.

Problème réglé.

[cavo789]

Cool ! Et bien vu car en effet c'était l'une des seules possibilités puisque le code PHP de l'application n'a pas été modifiée et qu'excepté une action destructrice d'un potentiel virus il fallait "aller chercher ailleurs".

J'ai lu ton explication dans l'autre post : le fichier .htaccess relève de la sensibilité du serveur Web; c'est Apache qui le lit et le traite.

Si, comme tu l'expliques, le chemin vers le fichier .htpasswd était devenu obsolète (et du coup pointait vers un dossier n'existant plus); c'est Apache qui à la main : est-ce qu'Apache va juste ignorer le fichier et continuer son chemin ou va-t-il planter et refuser l'accès (c'est ce que tu as rencontré comme mésaventure).

Apache est en principe hyper rigoureux et si le fichier .htaccess contient la moindre broutille, il va générer une erreur 500. Dans nos échanges ci-dessus, l'analyse du fichier /aesecure/.htaccess ne m'était pas passé à l'esprit; dommage; cela aurait fait gagné du temps.

Bonne journée.

[FlodAriege]

Dans nos échanges ci-dessus, l'analyse du fichier /aesecure/.htaccess ne m'était pas passé à l'esprit; dommage; cela aurait fait gagné du temps.

Moi je dirais plutôt que comme j'avais répondu non à la question "as-tu changé quelque chose dans le dossier aesecure", tu es passé à autre chose comme hypothèse. Logique.
Ni toi ni moi ne pouvions deviné qu'un truc avait changé "à l'insu de mon plein gré"
Ou alors il n'a jamais changé (il a conservé l'adresse obsolète sans se mettre à jour lors de la restauration) et Apache est devenu subitement plus susceptible le 7 avril.
Va savoir...

En tout cas, merci de ton aide : même si tu ne m'as pas indiqué la solution (cette fois), tu m'as aidée à réfléchir et à donc à finir par la trouver.

Bonne soirée !