Hébergement mutualisé en erreur 504

Hello @PhilippeG1

Depuis [2016 Oct 22 17:49:24] il y à une augmentation de requête "TCP Out".
Je t'invite à vérifier les logs > Espace client > Hébergement > 1bretagne.frbretagne.fr > Onglet Plus + > Statistiques et logs > Lien "Logs"

Ce sont des requêtes qui sont envoyées depuis ton hébergement vers une IP:3306 > Donc un serveur MySQL.

ps : la tâche travaux n'a pas de lien avec le cluster006 :)

Merci pour la réponse rapide.

Je viens de regarder les logs, mais je ne suis pas sûr de les interpréter correctement.

Je vois bien ces requêtes ":3306" dans le log "out".

Dans le log "web" je ne vois rien de particulier autour de l'apparition de ces requêtes, rien que des successions de "get".

Dans le log "err", il semble (sous réserve, je ne suis pas spécialiste) y avoir des choses plus louches, qui commencent plus tôt dans la journée du 22/10 (dès 06h40), et qui ressemblent furieusement à une attaque : on voit passer des messages _[msg "System Command Injection"]_ ou _[tag "WEB_ATTACK/COMMAND_INJECTION"]_ ...

Cela semble viser (?) des fichiers de configuration apache comme _"/usr/local/apache2/conf/modsecurity/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"_ ...

À partir de 17h54, les erreurs se répètent, principalement de type : _Script timed out before returning headers: index.php_ ...

J'ai contrôlé le fichier "index.php", il n'a pourtant pas été modifié.

Au moins, j'ai toujours la main en FTP. J'ai donc renommé ce fichier "index.php", et mis en place un "index.html" statique, qui s'affiche correctement.

Je crois que je n'ai plus qu'à tenter une restauration de ma précédente sauvegarde ...

Mais ce qui m'inquiète, c'est que si une attaque a réussi à modifier des fichiers locaux dans "/usr/...", la restauration ne va pas forcément suffire ...

[msg "System Command Injection"] ou [tag "WEBATTACK/COMMAND_INJECTION"]_ ...

Cela semble viser (?) des fichiers de configuration apache comme "/usr/local/apache2/conf/modsecurity/baserules/modsecurity_crs_41_sql_injection_attacks.conf"_ ...

Cela provient du firewall OVH qui est activé sur tes multi-sites.

À partir de 17h54, les erreurs se répètent, principalement de type : Script timed out before returning headers: index.php ...

c'est que le serveur web n'a pas pu exécuter le scripts index.php, dû probablement à la surcharge des connexions sortantes.

D'où peuvent provenir ces surcharges des connexions sortantes ?

Un script php du CMS qui a été modifié ?

Le site est un simple Joomla (à jour, sauf la toute dernière de cette semaine) ...

Il y à de fortes chances oui, depuis que tu as mis en place la page index.html > Plus de connexion sortante.
Donc l'index.php appelait une ressource qui cause ces envoi "tcp out", reste à trouver lequel maintenant.

Site en maintenance.

Bon, j'ai restauré et cela semble être reparti.
Dans la foulée, j'ai installé la toute dernière mise à jour, et activé le "https:".

Je vais tâcher de récupérer le site corrompu en local avant de le supprimer, histoire d'essayer de repérer quels fichiers ont été modifiés ...

Merci encore pour le coup de main ...

:slight_smile:

PS : À noter tout de même : sur mon hébergement, j'ai deux bases de données, et j'ai changé de base lors de la restauration. La première base semble avoir un soucis, puisque phpMyAdmin m'en refuse l'accès : _"Connexion au serveur MySQL non permise"_

phpMyAdmin m'en refuse l'accès : "Connexion au serveur MySQL non permise"

Généralement soucis de mot de passe. Je te conseil quand même de faire une vérification des plugins/thèmes afin que cela ne se reproduise plus ;)

Si ton soucis est résolu, n'hésite pas à cliquer sur le bouton du **message offrant la solution**:

Finalement ce n'était pas un soucis de mot de passe, mais de nom de serveur (mysql).

J'utilisais pour mes bases de données les noms de serveurs tels qu'ils m'avaient été précisés lors de la création de l'hébergement (de la forme "mysql*.pro") au lieu de la forme "*.mysql.db" :

* avec la première forme, j'accède à une seule des bases ;
* avec la seconde forme, j'accède bien à mes deux bases.

Merci encore ...