Site Joomla fou...

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Site Joomla fou...

    Bonjour à tous,

    Voici plusieurs années que je travaille avec Joomla et OVH mais aujourd'hui je n'ai pas trouvé de réponse à ce problème.

    J'ai un site Joomla qui sature la base de données avec l'erreur max_user_connexion.

    De plus, dans le panel OVH les statistiques du site montre que de nombreuses requêtes SQL sont effectuées. (statements à + 1million !!)

    J'ai contacté plusieurs fois l'hébergeur, il n'a pas pu m'aider à résoudre le problème.

    Dans le PhpMyAdmin, les statistiques sont également folles, 1.6To de transfert de données en 48h.

    C'est un site simple, avec docman installé dessus. Le site est en version 3.8.13.

    J'ai désactivé tous les plugins.

    Avez-vous une idée ?

    Savez-vous comment je peux visualiser les requêtes qui sont émises depuis le site Joomla ?

    Merci d'avance !



  • #2
    Bienvenue !

    Pour moi, ça ressemble fort à des attaques sur ton site, par des robots. Tu peux voir dans les logs, depuis ton Manager, quelles sont les IP en cause et les bloquer ensuite par un deny dans ton .htaccess
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

    Commentaire


    • #3
      Merci RobertG pour la réponse.

      C'est très difficile à dire car en effet, l'analytics me prouve que beaucoup de visiteurs accèdent au site.

      Les logs pour autant n'ont rien d'alarmant.

      La seule hypothèse qu'il me reste c'est le log error (surement du à cause d'une offre business 2010 qui ne possède pas le PHP/FPM) :

      AH10157: FastCGI: An error happend on Fastcgi processing, fallback to CGI
      [Thu Oct 18 01:54:23 2018] [error] [client 178.255.215.91] [host www.monsite.com] Script timed out before returning headers: index.php
      [Thu Oct 18 02:41:53 2018] [error] [client 178.255.215.91] [host www.monsite.com] AH10141: FastCGI: comm with server "/homez.650/site/www/index.php" aborted: idle timeout (300 sec)

      En boucle !!!!

      Existe t-il un moyen de récupérer sur un mutualisé les logs mysql ?

      De nombreuse lignes (statements) sont retournées chaque jour sans pouvoir comprendre ce qui est fait.

      C'est relativement frustrant !

      Commentaire


      • #4
        Ce sont les logs de connexion qui te donneront les infos dont je parle, avec les adresses des pages qu'ils tentent d'ouvrir.
        Dans ton Manager, tu as plusieurs types de logs accessibles. Je n'ai jamais fait attention à d'éventuels logs mysql.
        "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

        Commentaire


        • #5
          Merci une nouvelle fois RobertG.

          Je viens de revérifier, il semblerait que ce ne soit pas la cause de mon problème.

          En effet, ces ip sont les miennes, il n'y a pas d'autres ip (massives).

          Cependant FastCGI ne semble pas activé sur cet ancien hébergement OVH.

          Ces timeout font ralentir le serveur et les requêtes restent actives, ce qui entraîne un ralentissement, puis parfois, une chute du serveur.

          Le fameux passage de FastCGI à CGI rend les performances du site Joomla 3 médiocres.

          De plus, ce même site était hébergé sur un autre serveur OVH (récent) avant sa mise en place du son NDD officiel. il n'y avait aucune erreur de ce type pendant sa phase de développement.

          Au passage, RobertG, si vous êtes le développeur de MoovJla alors je vous offre ma femme.

          Commentaire


          • #6
            Merci, mais j'en ai une ! Je ne suis que le successeur des auteurs de Moovla.

            Il me paraît curieux que ce ne soient pas des attaques de robots qui fassent tant d'appels. Quant au timeout d'OVH, plus d'un s'en est plaint depuis un bon moment...
            "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

            Commentaire


            • #7
              Bonjour,

              1. Merci de tester avec l'activation du mode debug afin de déterminer le nombre de requêtes.
              N'oubliez pas de desactiver le cache au préalable.



              Je vous conseille d'éditer le plugin Système - Débogage (ou system debug )
              pour afficher les erreurs uniquement pour les super admin en selectionnant superadmin dans "groupe autorisés" ou dans accès type.
              Pour activer la fonctionnalité, c'est dans le menu système / configuration/ onglet système, débogage système à "oui"

              Si votre site génère un bon nombre de requêtes par page, ce sera fortement ralenti (encore plus que d'habitudes) mais vous aurez une idée un peu plus précise. Vérifiez chaque plugin pouvant générer un nombre important de requêtes. Désactivez un par un ceux qui ne sont pas essentiel puis tester à nouveau. N'oubliez pas de desactiver temporairement le cache !

              Les problèmes de requêtes sont parfois provoqué par de mauvais réglages. Par exemple, l'utilisation de ReReplacer de Regular Labs dans chaque page et à tous le contenu (modules et articles) a donné des ralentissement au chargement et des blocages de la part d'un hebergeur qui n'hésitait pas à brider l'accès (pour ne pas impacter les ressources pour les autres clients du même serveur).

              2. La gestion du cache peut jouer également. Même inactive dans la configuration du site, elle peut être utilisé par certaines extensions pour éviter de générer de nombreuses requêtes. C'est le cas par exemple de virtuemart, de cck et autres extensions très appréciés. Si le cache joomla ne pose pas trop de problème, l'usage de cache alternatif serveur (memcached par exemple) peut provoquer des perturbations si la compatibilité n'est pas complète. C'était le cas par exemple sur ovh mutu (je n'ai plus testé depuis quelques années).

              Donc je conseille de desactiver le cache, le temps de faire les tests nécessaire et de le vider même désactivé.

              3. https : Parfois le certificat peut créer une boucle qui bloque le site comme c'est le cas avec l'utilisation de cloudflare ou cdn.

              4. Dans le cas d'attaque par brute force, on aurai logiquement les traces dans le journal d'activité ( les log http du serveur).
              La solution dans ce cas, c'est de bloquer les ip malveillants, d'instaurer une politique stricte sur les formulaires (recapcha, antispam, honeypot)
              et de bloquer l'admin par un htpasswd ou d'une autre protection similaire. Depuis des années, j'utiliser cloudflare pour cacher l'adresse ip du serveur et bloquer ce type d'attaque avec succès. Tous les sites sont régulièrement scannés et subissent des attaques pouvant durer plusieurs heures/jours d'où la nécessité d'adopter de bonne règles de sécurité.

              5. Un mauvais réglage du htaccess peut également ralentir ou bloquer le site notamment sur la réécriture, la redirection...
              de préférence, utiliser le htaccess d'origine pour comparer.

              6. Dans le cas d'un piratage, utiliser des outils d'analyse, vérifiez les logs et date de modification des fichiers et procéder au nettoyage.

              Voilà, je pense avoir fait le tour des possibilités. Bon courage dans la résolution du problème.

              Yann




              Dernière édition par daneel à 21/10/2018, 10h08
              Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

              Commentaire


              • #8
                Bonjour,
                J'avais également eu à gérer ce souci sur un site bridgé à forum via le plugin Fusion : cela provoquait le même type de souci.
                Il n'y a pas ce type de plugin installé sur le site ?

                Cordialement,
                Chabi01 - http://www.xlformation.com

                Commentaire

                Annonce

                Réduire
                1 sur 2 < >

                C'est [Réglé] et on n'en parle plus ?

                A quoi ça sert ?
                La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                Comment ajouter la mention [Réglé] à votre discussion ?
                1 - Aller sur votre discussion et éditer votre premier message :


                2 - Cliquer sur la liste déroulante Préfixe.

                3 - Choisir le préfixe [Réglé].


                4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                2 sur 2 < >

                Assistance au forum - Outil de publication d'infos de votre site

                Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                UTILISER À VOS PROPRES RISQUES :
                L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                Problèmes connus :
                FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                Installation :

                1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                Archive zip : https://github.com/AFUJ/FPA/zipball/master

                2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                et remplacer www. votresite .com par votre nom de domaine


                Exemples:
                Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                Télécharger le script fpa-fr.php dans: /public_html/
                Pour executer le script: http://www..com/fpa-fr.php

                Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                Télécharger le script fpa-fr.php dans: /public_html/cms/
                Pour executer le script: http://www..com/cms/fpa-fr.php

                En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                Voir plus
                Voir moins
                Travaille ...
                X