Trafic entrant analysé avec un honeypot checker : que faire des scores de risque obtenus ?

Vous ne pouvez pas venir à bout des bots avec un blocage d'IP statique, car les réseaux de bots changent constamment d'IP. Configurez du rate limiting sur votre serveur web. Ralentissez temporairement ou redirigez vers une vérification navigateur ceux qui font plus de cinq requêtes par seconde sur les points d'accès panier et recherche.

Ces sites de requêtes gratuits sont généralement très lents à mettre à jour leurs bases de données. Une adresse IP de datacenter nettoyée il y a trois mois peut encore apparaître comme attaquante dans le système. Si vous bloquez directement en vous basant sur la liste, vous faites fuir des clients potentiels connectés via le réseau mobile.

La solution la plus pratique que vous pouvez appliquer immédiatement est d'augmenter d'un cran le niveau de sécurité dans l'interface où vous gérez votre nom de domaine et de mettre une vérification navigateur automatique (challenge) pour les requêtes de scan venant de pays suspects. Le vrai utilisateur ouvre la page, tandis que les bots de scan basiques restent bloqués.

L'ordre à suivre devrait être à peu près celui-ci : 1) Cherchez un motif de user-agent commun dans les logs du serveur. 2) Ajoutez un lien piège caché sur les pages auxquelles les moteurs de recherche ne doivent pas accéder et isolez pendant 24 heures les adresses IP qui y entrent. 3) Mettez une limitation de requêtes sur les pages de paiement et de panier.

nous aussi une fois on a bloqué cinquante IP en panique en fait c'était le réseau du bureau d'un client qui passait des commandes en gros et les mecs ont passé la commande ailleurs pcq le site s'ouvrait pas le blocage statique c'est vraiment risqué.

Le mois dernier, lors d'un scan similaire, nous avons détecté 3 000 adresses IP différentes frappant notre serveur. Dans les outils externes, 1 200 semblaient risquées, mais en examinant, il s'est avéré que seulement 75 faisaient réellement du scraping. Agir sur la base de l'IP sans regarder le comportement fait perdre du temps.

Ces requêtes entrantes sont-elles à un niveau qui bloque le processeur du serveur ou font-elles juste du monde dans les logs d'accès ? Et aussi, les plages horaires des requêtes suivent-elles un rythme précis ou sont-elles complètement réparties sur la journée ?

C'est globalement vrai, mais il manque un point. Le temps que vous mettez à détecter un problème détermine directement son coût.

Je le note au cas où.

Cette approche a un coût, dont on ne parle pas. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé. Corrigez-moi si je me trompe.

Ma question va paraître un peu novice, désolé d'avance. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion. Corrigez-moi si je me trompe.

Je suis entièrement d'accord. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Mes doutes sont levés, merci.

Sujet très actuel. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Je le note au cas où.

Je n'ai aucune expérience en honeypot checker, c'est pourquoi je pose la question. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Si c'est une première, commencez petit, l'échelle viendra plus tard.

Je vous conseille de ne pas vous presser. Une sauvegarde non testée n'est pas une sauvegarde.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup. J'espère que cela vous sera utile.

Chez nous, ça s'est passé comme ça. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Je suis d'accord. Si vous grondez les fausses alertes, plus personne ne signalera rien.

J'espère que cela vous sera utile.

Chez nous, ça s'est passé comme ça. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

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