Comment bien paramétrer Cloudflare pour bloquer les AI crawlers?

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

  • #16
    Bonjour Yann,

    je viens de réactiver le paramètre Under Attack. 1 000 crédits ont été utilisés dans IP2location en 50 minutes.

    Je ne sais pas où trouver les IPs. EN voici quelques uns :
    37.174.235.204
    34.169.31.233
    83.243.240.77

    Merci pour votre aide,
    Sincèrement,
    A. Guillen

    Commentaire


    • #17
      37.174.235.204 Orange France
      Probablement un visiteur français.

      34.169.31.233 Google Cloud États-Unis
      Un service automatisé (ex. : crawler, robot IA, proxy, test automatique) ou un outil lancé de chez Google.

      83.243.240.77 : Online SAS / Scaleway (anciennement Iliad/Free)France
      Serveur dédié ou VPS (datacenter) probablement utilisé pour :
      crawler des sites (ex. : SEO tool), exécuter des scripts automatisés ou héberger une IA ou un service web.

      Si vous observez un trafic répété, rapide ou suspect dans les logs (ex. : tentatives de connexion répétées, etc.),
      vous pouvez imposer le challenge JS via Cloudflare mais sur les trois ip, aucune n'est à bloquer par défaut.
      (voir message précédent)

      Une autre solution — probablement la plus simple à long terme — serait de traiter le problème directement à la racine :
      c’est-à-dire désactiver l’appel à IP2Location.io pour les user-agents identifiés comme des bots.

      Cela éviterait de consommer inutilement des crédits pour des visites sans valeur commerciale réelle, tout en laissant les crawlers faire leur travail.

      Voici un exemple très simple de filtre à ajouter dans le code (ou à intégrer en surcharge) :

      $userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
      if (preg_match('/(bot|crawl|spider|slurp|wget|curl|python|libwww-perl|httpclient)/i', $userAgent)) {
      define('HIKASHOP_DISABLE_IP2LOCATION', true);
      }
      Cette constante pourrait ensuite être utilisée dans le code HikaShop :
      • On ne bloque pas ces bots, ce qui permet à des services comme Google Merchant, Bing Shopping, Facebook Catalog, ou même des IA, de lire et indexer vos produits.
      • Cela réduit considérablement la consommation de crédits IP2Location.
      • Cela évite d’utiliser des règles de sécurité trop strictes, qui risquent de bloquer des services utiles.
      Pour ma part, sur les sites e-commerce que je gère, je ne bloque pas les crawlers. Google passe régulièrement, y compris pour le Merchant Center, parfois de façon un peu agressive, mais ça se stabilise toujours au bout de quelques heures. Si tu confirmes, via le support d'hikashop, qu’un filtre de ce type peut être proprement intégré, ça permettrait de soulager pas mal d’utilisateurs, tout en conservant la géolocalisation pour les visiteurs réels.​
      Dernière édition par daneel à 12/05/2025, 09h33
      Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

      Commentaire


      • #18
        explication du code :

        1. $userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
        Cette ligne récupère le User-Agent du visiteur.
        • Le User-Agent est une chaîne envoyée par le navigateur ou le robot pour s'identifier (par exemple : Chrome, Firefox, Googlebot, GPTBot…).
        • Si la clé 'HTTP_USER_AGENT' n'existe pas (cas très rare), on utilise une chaîne vide par défaut ('')
        2. preg_match('/(bot|crawl|spider|slurp|wget|curl|python|libwww-perl|httpclient)/i', $userAgent)
        Cette ligne analyse le contenu du User-Agent.
        • Elle utilise une expression régulière (regex) pour vérifier s’il contient l’un des mots suivants :
          • bot, crawl, spider, slurp → bots des moteurs de recherche ou crawlers classiques
          • wget, curl, python, libwww-perl, httpclient → outils ou langages utilisés par des scripts automatisés
        • Le i signifie que la recherche est insensible à la casse (majuscules/minuscules).

        Si l’un de ces mots est trouvé dans la chaîne, cela signifie probablement que le visiteur n’est pas un humain, mais un robot ou un outil automatisé.



        Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

        Commentaire


        • #19
          daneel
          guillenphoto
          A Guillem : La dernière solution proposée par Yann (alias daneel) si vous savez le faire est la meilleure. Mettre un script dans le htaccess est le meilleur moyen de stopper un robot.
          Yann : Concernant CloudFlare dans sa version gratuite, c'est une passoire en ce qui concerne les bots. Quand je regarde les logs de PlanetHoster c'est lui qui arrête la majorité des badbots. Environ 10 blocages qualifiés de critique concernent des attaques chaque jour (injection de fichiers, copie de fichier sensibles, passage par des plugins, etc. ) .

          Commentaire


          • #20
            L' (les) user_agent pourrait se faire botter les fesses avec une regex fail2ban qui le bloquerait définitivement avant même qu'il passe le .htaccess, banni des la première connexion.
            Je pense que notre membre, guillenphoto a travers son expérience et son business mondial devrait passer a une solution d’hébergement plus robuste (infogérée).
            Dernière édition par Fred2FR3 à 13/05/2025, 18h30
            daneel aime ceci.

            Commentaire


            • #21
              Envoyé par Fred2FR3 Voir le message
              L' (les) user_agent pourrait se faire botter les fesses avec une regex fail2ban qui le bloquerait définitivement avant même qu'il passe le .htaccess, banni des la première connexion.
              Je pense que notre membre, guillenphoto a travers son expérience et son business mondial devrait passer a une solution d’hébergement plus robuste (infogérée).
              En fait, dans le cas présent, il ne s'agit pas de renforcer la sécurité du site à tout prix, mais d’optimiser la consommation des crédits liés à l’API IP2Location.io, qui sert ici à détecter la localisation de l’utilisateur pour ajuster dynamiquement la devise affichée. Le problème vient du fait que certains bots ou crawlers – y compris ceux des moteurs de recherche – déclenchent des appels à cette API inutilement. Cela épuise rapidement le quota de crédits, surtout quand le site est visité par des robots automatisés ou mal identifiés.

              D'où l'idée de mettre en place une filtration très en amont pour désactiver temporairement IP2Location selon le user_agent. Par exemple, on peut détecter les agents connus de bots (crawl, spider, etc.) et éviter d’appeler l’API dans ces cas-là. Ce n’est donc ni un blocage de sécurité définitif, ni un bannissement automatique, mais simplement une stratégie d’économie de ressources, en adaptant le comportement du site selon le type de visiteur.

              Par ailleurs, la remarque sur l’hébergement infogéré est pertinente dans un autre contexte, notamment pour assurer une surveillance continue et des optimisations proactives.
              Mais ici, le besoin immédiat est surtout de rationaliser les appels API selon le type de trafic.


              Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

              Commentaire


              • #22
                Bonjour à tous,

                je vous remercie pour votre aide et votre message. J'y vois plus clair grâce à tous vos conseils.

                Je vais mettre ce post en réglé car je ne peux aller plus loin concernant Cloudflare qui d'après Yann fait ce qu'on lui demande.

                Merci encore pour votre valeur ajoutée et pour le partage de vos compétences.

                A. Guillen

                Commentaire

                Annonce

                Réduire
                Aucune annonce pour le moment.

                Partenaire de l'association

                Réduire

                Hébergeur Web PlanetHoster
                Travaille ...
                X