On a essayé de piéger le trafic bot sur notre site avec un honeypot — peut-on se fier aux résultats et qu'est-ce qu'on doit faire ?

Si côté CSS vous avez caché avec juste display: none ou visibility: hidden, les bots modernes le comprennent déjà en lisant le fichier de style et passent outre. Il ne reste alors que des bots très primitifs ou des logiciels d'accessibilité. Pousser le champ caché hors écran (avec text-indent ou position absolute) et ajouter l'attribut aria-hidden réduit nettement les faux positifs.

On avait installé un honeypot sur une structure similaire l'an dernier. En examinant une par une les 800 premières IP capturées, on a vu que 120 d'entre elles étaient l'IP de sortie internet commune de nos gros clients entreprise. Si on avait banni en masse ce jour-là, on aurait complètement coupé du site nos trois revendeurs qui commandent le plus.

edit : j'ai écrit depuis mon téléphone, désolé pour les fautes.

La méthode honeypot ne peut plus arrêter à elle seule les scrapers de contenu. Les outils de scraping pro qui récupèrent les prix font tourner des navigateurs headless complets et ne cliquent que sur les boutons réellement visibles à l'écran. Les 1 400 IP que vous avez capturées sont probablement du bruit inoffensif qui scanne internet au hasard, les bots qui pompent vraiment vos données n'ont peut-être même jamais touché ce piège.

Au lieu de renvoyer directement un 403 Forbidden, affichez un challenge Javascript au niveau serveur aux IP qui tombent dans le piège. Si c'est un vrai humain, le navigateur le résout en un dixième de seconde et entre sur le site. Si c'est un scraper basique en python ou curl, il ne peut pas exécuter le Javascript, se casse les dents et arrête de fatiguer votre serveur.

Calmez-vous et n'allez surtout pas bannir en masse au niveau IP. L'usage du CGNAT est très répandu en Turquie, quand vous bannissez une seule IP de bot issue d'un pool dynamique, vous pouvez exclure en même temps des centaines d'utilisateurs innocents chez eux ou au bureau. Évaluez le comportement suspect selon le comportement de session, pas selon l'IP.

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

nous aussi on a eu un bot de moteur de recherche qui s'est coincé nos index ont failli être supprimés ne mettez jamais de règle de blocage sur le serveur sans vérif rdns obligatoire

Le lien caché que vous avez mis en bas de page avait-il l'attribut rel="nofollow" et avez-vous défini cette adresse en disallowed dans le fichier robots.txt ? Si vous ne l'avez pas ajoutée au robots.txt, il est tout à fait normal que les crawlers des moteurs de recherche suivent ce lien.

Au lieu d'ajouter un champ invisible au formulaire honeypot, mettez un contrôle d'horodatage ; les requêtes qui remplissent le formulaire en moins de 2 secondes se distinguent beaucoup plus clairement comme bots.

Je suis entièrement d'accord. Quand on essaie de tout changer en même temps rien ne prend.

Bon courage.

Merci, c'était exactement la réponse que je cherchais.

Nous avons vécu presque la même chose l'année dernière. Les décisions hâtives finissent par être corrigées six mois plus tard.

Ne comptez pas sur une seule mesure de sécurité ; allez par couches. Bon courage.

Vous avez raison.

Je suis d'accord, j'aimerais même souligner ce point. Avant de décider regardez quelles données vous avez en main.

Corrigez-moi si je me trompe.

enregistré.

Beau travail. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement. Corrigez-moi si je me trompe.

Je me pose aussi la question.

Pensez-vous que cela fonctionne à toutes les échelles ? Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Bien sûr cela change si votre situation est différente.

Beau travail.