Parfois il y a des choses qu’on ne soupçonne pas du tout, comme par exemple la saturation progressive de votre serveur par un mal invisible… du trafic indésirable, qui saturent les ressources de votre boutique Prestashop.
Avoir un bon serveur est important
Oui ça c’est forcément le 1er élément à prendre en compte, l’hébergement n’est pas un endroit sur lequel il faut économiser, car c’est lui qui va être le « socle » de votre boutique. Si l’hébergement n’est pas performant ou que vous avez une offre « discounter au rabais », il sera difficile d’obtenir de bonnes performances (temps de chargement, rapidité de réponse du serveur). Si vous devez investir à un endroit en priorité, c’est bien sur ce point… ne l’oubliez pas !
Des serveurs VPS au bord de la saturation
C’est ce que j’ai commencé à observer chez certains clients, c’est que la boutique Prestashop avait tendance à être lente… comme si la base de données MySQL était au bord de la saturation. Parfois ces boutiques étaient rapides et parfois très lentes… et on en revient à dire que cela doit être la faute de l’hébergeur (ce qui n’est pas tout à fait faux). On commence aussi à voir dans les logs du serveur des mentions « Too many connections » et là c’est l’inquiétude qui commence à monter…
Les robots tuent votre shop
En fait ces « bots » sont assez intelligents pour duper le serveur, ils ne spamment pas vos pages à 1000 affichages par secondes, mais viennent interroger votre serveur, chaque 30 ou 60 secondes… Quand il y’en a qu’un seul cela reste viable, mais si cela se démultiplie le serveur peut être grandement sollicité et les pages de votre Prestashop vont continuer à se charger… mais très lentement pour vos visiteurs. Cela crée un sentiment de frustration, car on se demande d’où vient la lenteur… alors qu’il semble qu’on a fait les choses en ordre.
Cloudflare
Pour certains clients j’ai déjà utilisé la solution Cloudflare qui permet de filtrer déjà en amont le trafic « déchet » et les tentatives intrusives / à risques. Le problème c’est que même Cloudflare laisse passer ces robots indésirables et se révèle donc impuissant face à ce type d’attaque… Par exemple pour moi « AhrefsBot » pour moi c’est clairement du SPAM… le site ahrefs n’a pas de raison de commencer à scanner n’importe quel autre site dans le but de l’analyser.
Et les hébergeurs dans tout ça ?
Bien souvent la réponse obtenue c’est que le problème se trouve plutôt du côté de la boutique en ligne… et cela est forcément agaçant pour le commerçant qui se trouve une fois de plus impuissant face à la situation. Ce que je peine à comprendre c’est que les hébergeurs ne proposent pas un filtre « automatique » sur tous ces robots connus comme « malsains » avec une liste automatiquement tenue à jour. Ce problème est récurrent et fait saturer beaucoup de serveurs… pourquoi ne pas proposer un tel filtrage de base… on serait tous gagnant non ?
Ressources
Pour ce tutoriel vous avez à disposition :
- 1 x fichier de règles à ajouter à votre .htaccess
- 1 x fichier « index.php » pour bloquer tous les types de robots
Résumé de la vidéo : bloquer les robots améliore la vitesse de Prestashop
- Analyse d’un fichier de logs Apache avec les pages vues et type de bots. Chaque hébergement dispose de ce fichier de logs (vous pouvez y avoir accès via votre panel de gestion).
- Utilisation de l’agent switcher chrome pour simuler la visite d’un robot.
- Mise en place de règles dans le fichier « .htaccess » pour bloquer les robots connus (voir liste recommandée par Infomaniak).
- Utilisation du fichier « index.php » et compréhension du code avec l’intégration de règles personnalisées pour bloquer tous les types de robots indésirables.
- Je conseille de laisser tourner le fichier des logs pendant 1 ou 2 jours, puis ensuite vous pouvez faire une analyse pour voir s’il y a des indésirables / parasites permanents.
Bonsoir Germain
Vraiment top comme astuce ! Testé et approuvé et en effet on sent de suite une différence.
Merci
Hello,
C’est vraiment super si cela fait une différence, cela prouve donc bien que beaucoup de site Prestashop sont pénalisés par ce fléau.
A bientôt !
Salut Germain
C’est quand même dingue de voir tout ce qui se fait à notre insu …
J’ai vu que certains, préconise de modifier le robot.txt pour bloquer les « bot » du style:
User-agent: SemrushBot
Disallow: /
User-agent: SemrushBot-SA
Disallow: /
Mais ta méthode est intéressante, surtout pour ceux qui auraient tendance à régénérer le robot.txt via presta.
Par contre, je me dis que de nouveaux robots ne manquerons pas d’apparaitre et qu’ils nous faut rester à l’affut de ces indésirables pour les ajouter à notre liste. Ne serait il pas possible d’autoriser les « bot » de notre choix et d’interdire tous les autres, ce serait plus simple.
Mais bon je ne suis pas codeur …
Merci pour ta perspicacité et le partage de connaissance.
Hello,
Il y a trop de risques d’autoriser « QUE » les bons bots, mon conseil c’est par exemple de se dire 1 x par mois on laisse tourner le script durant 24h et on regarde ce qui se passe (à noter dans l’agenda). La méthode avec l’index.php reste ma préférée, car elle est très efficace et on comprend facilement ce qui se passe.
A bientôt !
Bonjour,
Une fois de plus, superbe tuto.
J’ai 2 choses qui reviennent très souvent dans mon fichier log:
bingbot et AppleWebKit. Puis-je les ajouter à la liste ou est-ce-que cela risque d’avoir un impact sur le référencement ?
Bien cordialement.
Salut Fabrice,
A mon avis, non.
Bingbot est le robot du moteur de recherche Bing de Microsoft
AppleWebkit est, sauf erreur, un User Agent dont ce sert Google pour simuler un mobile qui parcours ton site…
En espérant que cela aide
Fajy
Bonjour,
Merci beaucoup pour votre réponse. Je vais donc les laisser.
Bien cordialement.
Hello,
Rien à ajouter c’est exactement ça 😉
A bientôt !
Bonjour,
Ces deux-là vous pouvez les laisser… donc « bingbot » c’est le bot de Microsoft (même si c’est quelques % du marché, mieux vaut le laisser).
A bientôt & merci !
Rien à dire, tirs aussi efficace!!!
Bien que je sois pas fan de la 1.7, et que le 80% des prestaUser sont en 1.6, il serai intéressant si cette méthode fonctionne aussi avec cette version.
De plus, ils semble que l’hébergement est aussi voir autant important !!!
Mais ce n’est que mon avis
Hello,
Oui alors la méthode du fichier « index.php » va fonctionner aussi pour Prestashop 1.6… donc tu peux l’appliquer sans problème pour réduire les attaques.
A bientôt !
Merci pour le tuto, mais la méthode ne fonctionne bizarrement pas pour prestashop 1.7…C’est étrange, une idée?
Si cela ne fonctionne pas, vous pouvez commencer par activer le debug de Prestashop pour voir si une erreur est générée en arrière-plan.
En fait, on dirait que le fait d’insérer les commandes dans le htaccess exactement comme indiqué, cela fait planter le site et dans ce cas évidement je n’ai plus accès au debug.
Pourtant j’ai inséré scrupuleusement et juste après le rewrite engine on…
Par contre en insérant le code dans le htaccess à la racine de l’hébergement, je n’ai pas d’erreur mais je ne sais pas si ça fonctionne. Je n’arrive pas à tester avec le user switch agent.
Pourrais tu tester stp?
J’ai normalement bloqué ahrefs, dotbot, semrushbot, sinon je vérifierai les logs demain.
Merci
Pour donner un petit retour, la methode qui a fonctionné pour moi est celle d’injecter le code suivant dans l’entête du htaccess (dans le repertoire de prestashop)
#Anti-bots
SetEnvIfNoCase User-Agent MJ12bot bad_bot
SetEnvIfNoCase User-Agent AhrefsBot bad_bot
SetEnvIfNoCase User-Agent YandexBot bad_bot
SetEnvIfNoCase User-Agent SemrushBot bad_bot
SetEnvIfNoCase User-Agent DotBot bad_bot
SetEnvIfNoCase User-Agent Baiduspider bad_bot
SetEnvIfNoCase User-Agent BLEXBot bad_bot
Order Allow,Deny
Allow from all
Deny from env=bad_bot
#ENDAnti-bots
Je pense aussi que c’est le script qui consomme le moins de ressources dans un htaccess.
Bon WE
Hello,
Oui c’est effectivement plus « rapide » niveau exécution (préserve aussi encore plus de ressource).
Merci pour le retour d’expérience !
Bonjour,
ça fait 2 mois que j’ai mis en place le srcipt, au début j’utilise la méthode de germain, puis quand c’est des bots qui reviennent tout le temps, je met en place la méthode de youssef citée plus haut, ce qui me permet de laisser en place le script de germain sans avoir un fichier robotsDEBUG.txt de 50Go.
Mais dans mes logs je vois ces robots revenir quand même exemple:
[25/Jan/2020:11:27:16 +0100] « GET /robots.txt HTTP/1.1 » 403 360 « – » « Mozilla/5.0 (compatible; SemrushBot/6~bl; +http://www.semrush.com/bot.html) » « 20200125112716 »
juste pour être sur, dans cet exemple le bot s’est bien pris une page 403, mais est ce que c’est normal que je le vois encore dans mes logs?
Bien cordialement.
Bonjour,
Oui le BOT peut quand même toujours tenter d’accéder à votre hébergement, par contre dans le fichier de log, vous devriez avoir la mention « BLOCKED » pour le bot « SemrushBot ».
A bientôt !
Bonjour,
oui dans le fichier de Log qui est créé avec le script, ça marquait bien BLOCKED, et comme j’ain dit plus haut pour faire moins gaspiler de ressources, après je met dans le htaccess deny from lenomdubot bad_bot
du coup il ne s’écrit plus dans le fichier robotDEBUG.txt
mais je le vois dans les vrais logs avec apparemment une page 403
Salut Germain,
Merci pour ce tuto que j’ai mis en place avec plaisir sur mon site.
Une information sur les dates dont tu parles dans le tuto, peut-être que ça t’intéresse et que cela peut être utile à tes lecteurs.
L’écriture des dates années-mois-jours permet simplement de classer facilement des dates par ordre chronologique en utilisant le tri alphabétique qui existe partout.
Je l’utilise toujours pour mes fichiers, cela permet de s’y retrouver plus rapidement ;o).
A+, Ruben
Hello,
Super, oui je l’ai mis en place aussi pour des clients et ça semble assez efficace le serveur sature beaucoup moins (en tout cas chez les clients où j’ai fait le test). Très juste, j’ai pas précisé mais dans les bases de données le format utilisé est effectivement YYYY-MM-DD ce qui permet de faire un classement croissant / décroissant facilement.
A bientôt !
Bonjour Germain,
Encore une fois merci pour cet excellent billet.
En complément, j’ajoute au htacces le « referrer spam blocker » de Stevie Ray. Il est disponible sur GitHub et régulièrement mis à jour :
https://github.com/Stevie-Ray/referrer-spam-blocker
Si ça peut intéresser tes lecteurs…
A+
Hello,
Merci pour la contribution, voilà une ressource intéressante qui peut faire gagner du temps plutôt que de faire par « déduction » et tester chaque robot… A garder en tête pour un futur potentiel TUTO Prestashop 😉
A bientôt !
Sympa Merci pour l’astuce
mais je trouve dommage de bloquer les bot SEO comme « SemrushBot »
pourquoi ne pas faire une règle ou ont les bloques par exemple uniquement la journée de 05H30 à 00H30
/* Webbax - TUTO 69 - Sécurité antibots */ $logs = true; $heure = date('Hi'); if($logs){ $filename = "BOT.log"; $log_file = fopen($filename, "a+") or die("Unable to open file!"); } $bad_bots = array('AhrefsBot','SEOkicks','SemrushBot'); $user_agent = $_SERVER['HTTP_USER_AGENT']."\n"; if($logs){ fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent ); fclose($log_file); } foreach($bad_bots as $bad_bot){ if ($heure >= 0530 && $heure <= 0030){ if(strpos($user_agent,$bad_bot)!==false){ if($logs){ $log_file = fopen($filename,"a+") or die("Unable to open file!"); fwrite($log_file,date('Y-m-d H:i:s').' - '."BLOCKED : ".$bad_bot."\n"); fclose($log_file); } die('blocked bot'); } } } /* --- */Hello,
C’est une très bonne remarque… pourquoi ? Et bien parce que je n’y ai pas pensé ahaha… Un grand merci d’avoir contribué à ce tutoriel Prestashop !
A bientôt !
Bonjour, merci pour ces infos. Je viens de voir que j’ai beaucoup de visiteur et d’ajout au panier, mais avec des robot. Cela doit jouer énormément sur le taux de rebond, non?
Je suis avec la 1.6.1, la solution suivante fonctionne t-elle?
#Anti-bots
SetEnvIfNoCase User-Agent MJ12bot bad_bot
SetEnvIfNoCase User-Agent AhrefsBot bad_bot
SetEnvIfNoCase User-Agent YandexBot bad_bot
SetEnvIfNoCase User-Agent SemrushBot bad_bot
SetEnvIfNoCase User-Agent DotBot bad_bot
SetEnvIfNoCase User-Agent Baiduspider bad_bot
SetEnvIfNoCase User-Agent BLEXBot bad_bot
Order Allow,Deny
Allow from all
Deny from env=bad_bot
#ENDAnti-bots
Je vois aussi le passage de semruch, aref, des robot de lituanie et taiwan. Y a du monde quand même!
Merci pour toutes vos informations qui pourrons m’aider à balayer ces robot nuisant mais en gardant les bons pur le référencement 😉
Merci pour vos informations
Bonjour,
Normalement vous pouvez utiliser la même méthode sous un Prestashop 1.6 en ajoutant le code en début de fichier d’index.php (le tracking est plus facile à comprendre).
Pour assurer la qualité des statistiques de Google Analytics, voir peut-être ce billet : https://sharingcross.fr/data-driven/comment-identifier-et-supprimer-le-trafic-provenant-de-robots-dans-google-analytics/
A bientôt…
Bonjour Germain,
Il y a quelques semaines j’ai installé le code et je me suis aperçu que ma page d’accueil était « blocked bot » ainsi que des onglets, j’ai donc supprimé le code mais « blocked bot » est têtu et s’affiche de temps à autre, il faut que je rafraîchisse plusieurs fois la page pour qu’elle s’affiche enfin, j’ai supprimé tous les caches des navigateurs que j’utilise ainsi que le cache de Prestashop, j’ai même supprimé dans le répertoire var/cache/ le dossier Prod.
Si tu as une explication ou solution je suis preneur…
Merci d’avance pour ton aide… à bientôt
Hello,
Hum, délicat… je commencerais par retirer « intégralement » le code concernant le blocage des bots pour voir comment Prestashop réagit. Ensuite, dans la variable $bad_bots essaie de mettre uniquement un seul nom de bot pour commencer (afin de pouvoir identifier d’où vient le problème).
A bientôt !
Bonjour Germain,
Merci pour la réponse, je test.
A bientôt…
Bonjour Germain,
j’ai testé, mais rien n’y fait, j’ai donc supprimé absolument tout le code dans le .htaccess et le fichier index.php, mais rien n’y fait j’ai toujours des pages « blocked bot » sur la page d’accueil et les onglets qui ramènent à ma page d’accueil… Au secours !!!
Merci d’avance pour ton aide… à bientôt
efface le cache de ton navigateur et celui de prestashop dans parametres avancés > Performances > vider le cache
😉
Bonjour zstof,
j’ai déjà tout fait cache navigateur, Prestashop j’ai même supprimé les deux dossiers cache dans var, rien n’y fait ???
Bonjour,
Difficile d’en dire plus, si le code n’est plus présent il ne peut pas continuer à s’exécuter (ou alors le code n’a pas été retiré correctement). Ce que vous pouvez faire éventuellement c’est de vérifier à nouveau en contrôlant ce fichier (l’index.php Prestashop situé à la racine) le télécharger avec Filezilla, l’ouvrir et vérifier que le code antibot pour n’est plus présent.
A bientôt !
Bonjour Germain,
j’ai tout simplement retiré le code et tout est rentré dans l’ordre, je pense…
Jusqu’à aujourd’hui je n’ai plus de pages « blocked bot », croisons les doigts.
Merci pour ton aide et à bientôt !
Salut Webbax.
J’ai souhaité te demander une petite chose parce que j’en suis techniquement incapable. Je l’aurais bien fais par mail, mais je me suis dit que la réponse à ma question pourrait intéresser du monde.
Je m’explique (oui, je suis bavard, mais j’aime bien expliquer le contexte afin que ceux qui passent derrière et qui lisent la réponse saches si ce qui est dit peut les concerner aussi).
Voici donc le truc…
J’utilise ta technique sur tout mes sites, et ça marche du tonnerre. Ca marche tellement bien que grâce à elle j’ai pu repérer des tentative de piratage de mon site que je n’aurai pas vu autrement.
Dans le fichier RobotDebug.txt j’ai trouvé des « Python-request »… et j’ai trouvé celà bizarre. Je suis donc allé jeter un oeil dans les fichiers logs et j’ai pu trouvé un « modus-operendi » qui se répète à intervalles totalement aléatoire (soit c’est le même hacker qui fait celà à des moments différents, soit plusieurs hackers utilisent la même technique, je ne sais pas).
Et ça se reproduit à chaque fois selon le même procédé et à chaque fois avec deux adresses IP différentes, mais c’est le mode opératoire qui a attiré mon attention.
Tout d’abord, j’ai des requêtes avec python-request, et ensuite, avec une autre adresse IP la tentative de hack (je ne sais pas si les deux sont vraiment liés, mais la répétition du schéma et statistiquement faible).
J’illustre ça avec les extrait des logs :
Etape 1 : Python-request
Etape 2 : Tentative de hack avec une autre adresse IP
Et ca se reproduit
Alors… tu vas surement te demander en quoi tu peux m’aider, surtout que la plupart des requêtes sont bloquées par le module SecurityPro qu’on a installé.
Mais c’est que j’aimerai essayer de pousser un peu plus loin les investigations, et même si, je sais très bien que les hacker passent par des proxy ou des VPN ou ne sais quoi encore pour masquer leur IP, la loi française interdit au fournisseur d’accès de nous fournir les adresse IP précises. Elles sont toutes anonymisées en se terminant par un .0
Ma question serait donc juste de savoir quel code ou quelle modification il faudrait apporter à ton script pour qu’il nous fournisse l’adresse IP précise en plus des informations qu’on à déjà (un peu comme dans les fichiers logs … mais avec la précision qui leur manque).
Penses tu que ce soit quelque chose de réalisable?
Et dans le même temps, si tu pouvais m’expliquer exactement ce que signifient ces requêtes python-request, ca pourrait être sympa d’avoir cette info, parce qu’avec ton script on peut bloquer plein de choses (j’ai pu bloquer un spammeur qui utilisait un très vieux site que j’avais fait en html sans captcha (à l’époque c’était inutile) et le gars utilisait supersendme… que j’ai rajouté dans ton script et maintenant quand ça se produit il est marqué comme « blocked ».
Donc, du coup, j’ai également rajouté « python-request » depuis aujourd’hui dans la liste sur le site prestashop, mais en même temps, je me demande si je ne vais pas bloquer d’autres choses indispensables… vois tu mon soucis?
Je te remercie pour le temps que tu pourras consacrer à ma question.
Jérôme
Hello,
A vrai dire je ne sais pas exactement à quoi ça correspond ces « python-request », mais on va dire que ce n’est pas vraiment standard… Certainement qu’un système extérieur interroge le shop, mais dans quel but… (bonne question). Tu as bien fait de tester le blocage avec la règle, pour afficher aussi l’IP il faut utiliser « REMOTE_ADDR » voir ici : https://www.codexworld.com/how-to/get-user-ip-address-php/
A bientôt !
Salut,
Je suis un utilisateur comme toi du script mis à disposition par Webbax, ton message ma interpelais car je trouve également des requêtes de type python:
etc..
une simple recherche sur google aurait pu de donner la réponse:
« Cette chaîne d’agent utilisateur appartient à python-requests, qui est une bibliothèque utilisée pour effectuer des requêtes HTTP (le plus souvent, en mode automatique en tant que robot d’indexation Web ou bot) »
J’ai fais les recherches. Et si j’ai bien trouvé les informations que tu mentionnes (merci beaucoup pour d’avoir pris le temps de me rédiger une réponse), j’ai aussi trouvé des informations contradictoires ou du moins incomplètes, puisque le premier lien que m’a fourni google menait sur un outils qui permettait de tester les failles (PenTest il me semble), et que par conséquent n’étant sûr de rien, et ayant, suite à ces potentiel Pentest, les tentatives de piratages, j’avais besoin d’avoir confirmation si c’était dangereux ou non, et quelles seraient les conséquences de rajouter python-request dans la liste des éléments à bloquer.
Et d’autre part, j’ai toujours besoin de savoir comment récupérer les adresse IP dans le script de Webbax pour qu’elles apparaissent en tête de ligne dans le fichier robotdebug.txt.
Mais encore une fois, merci de m’avoir apporter cette première réponse.
Concernant les python-request je sais que si tu les bloques tu risque d’empêcher tous les site comme semrush , majestic, etc.. qui eux utilise ce genre de bot et certaine API aussi
sinon Tu peux récupérer l’adresse ip d’un visiteur en ajoutant cette ligne:
echo ‘adresse IP : ‘.$_SERVER[‘REMOTE_ADDR’];
Je confirme c’est bien ça qu’il faut faire 😉
Hello,
Merci d’avoir fait ce retour je pense que c’est très intéressant pour ceux qui liront ce billet par la suite 😉
A bientôt !
C’est bon, j’y suis arrivé. En croisant avec un autre extrait d’un script que j’ai trouvé en ligne.
En fait, après
Je remplace :
if($logs){ fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent ); fclose($log_file);Par :
$ip = $_SERVER["REMOTE_ADDR"]; if ($deep_detect) { if (filter_var(@$_SERVER['HTTP_X_FORWARDED_FOR'], FILTER_VALIDATE_IP)) $ip = $_SERVER['HTTP_X_FORWARDED_FOR']; if (filter_var(@$_SERVER['HTTP_CLIENT_IP'], FILTER_VALIDATE_IP)) $ip = $_SERVER['HTTP_CLIENT_IP']; } if($logs){ fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent. $ip.' - '); fclose($log_file); }Et dans le fichier Robotdebug.txt j’obtiens ceci :
Donc, pour ceux qui voulaient m’aider, ce n’est plus la peine de chercher (si vous le faisiez encore) et ZStof, merci pour ta suggestion qui m’a mis sur la voie.
Et pour ceux que ca intéresse, eh bien vous avez, vous aussi la solution.
Bonjour,
Je viens à vous pour recueillir aide et conseil, à cause de mon niveau trop faible en php.
Une nouvelle faille de sécurité dans Prestashop. Malgré la présence et l’activation de toutes les fonctionnalités d’un module de sécurité que nous avons acheté suite aux attaques de XadooXamBot (module payant sur Prestashop addons, complet : je ne peux pas lister toutes les fonctionnalités tellement il y en a), notre module paiement a été modifié (heureusement, nous nous en sommes aperçu avant la moindre tentative de paiement, mais du coup, le problème est là et ne s’arrête pas) j’ai trouvé une requête dans les logs du site (que je peux éventuellement fournir, mais quand j’essaye de la transmettre, elle est bloquée généralement, or, j’ai besoin que ce message puisse être visible) et qui a fait que j’ai dû retirer le site complètement (pour le placer dans un dossier sécurisé, hors du Nom de domaine, parce qu’à chaque restauration, la base de donnée était attaquée en moins de trois minutes.
J’ai donc téléchargé la tournère version de Prestashop 1.7.8.4, puis, passé les fichiers du site dans à WinMerge pour les omparer à la dernière release de Prestashop afin de mettre à jour manuellement et modifier tous les fichiers qui ne sont pas conformes à l’origine – normalement, j’ai donc notre site, mis à jour selon la dernière version de Prestashop).
Cependant, reste le problème de la faille, qui visiblement n’a pas été corrigée.
J’ai eu l’idée d’utiliser ce script, parce que j’ai remarqué qu’il ne fait pas que bloquer des bad_bots. En fait, il permet de bloquer n’importe quelle chaine de caractère qui figure dans une ligne de log apache et que l’on mentionne dans $bad_bots. On peut bloquer l’appel d’un fichier, une expression, ou n’importe quoi… comme une adresse IP. Par exemple, si je mets $bad_bots = array(‘wp’), tous les appels contenant wp seront bloqués. Ce script permet donc bien plus de choses, et c’est cet aspect qui m’intéresse ici, parce qu’on pourrait donc bloquer une IP (j’ai déjà essayé d’en mettre une manuellement, ça fonctionne bien), mais ce que je voudrais tenter de faire, c’est que l’IP réelle de celui qui tenterait la moindre requête interdite soit dynamiquement ajoutée à $bad_bots afin que même si, par la suite, il parvienne à lancer une requête qui devrait avoir un résultat 200 se retrouve toujours avec un 404.
L’attaque que nous avons subie faisait qu’un robot testait toutes une série de failles connues de lui visiblement (puisqu’il lançait des séries complètes d’appels d’url diverses dont des url WordPress). Par exemple, il essayait d’appeler wp-login qui est typiquement wordpress. donc, toute personne qui tenterait une telle requête sur un site Prestashop devrait automatiquement être bannie, puisqu’aucun « bon » utilisateur ne pourrait lancer une telle requête.
Mais, quoi que je fasse, il parvenait toujours à effectuer un certain nombre de requêtes, et finissait par trouver quelque chose qui lui permettait de passer.
J’ai donc parcouru le web à la recherche de scripts qui pourraient compléter ce fichier index php pour obtenir ce que je souhaite faire, et je souhaiterais donc savoir si ce que j’envisage à une chance de fonctionner – j’ai peur que non, mais, mon faible niveau en php – m’amène à solliciter votre aide pour solutionner ce problème, et voici donc, ce que j’ai tenté de faire :
1 – Déclarations supplémentaires :
(ici, IP proxy relève l’IP affichée donc, l’ip réelle sans proxy, ou l’ip du proxy s’il y en a un)
2 – Récupérer l’ip réelle :
function getUserIpAddr(){ if (!empty($_SERVER['HTTP_CLIENT_IP'])){ $real_ip_user = $_SERVER['HTTP_CLIENT_IP']; } elseif ( !empty($_SERVER['HTTP_X_FORWARDED_FOR'])){ $real_ip_user = $_SERVER['HTTP_X_FORWARDED_FOR']; array_unshift($bad_bots,"'".'.$user_agent.'."',"); } else { $real_ip_user = $_SERVER['REMOTE_ADDR']; } return $real_ip_user; }3 – Petite modification de $logs :
$logs = true; if($logs){ $filename = ".loggedOut"; $log_file = fopen($filename, "a+") or die("Connexion refusée!"); fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent. $real_ip_user.' - '); fclose($log_file); }4 – Modification du script de blocage des bots (chaines de caractères interdites) :
foreach($bad_bots as $bad_bot){ if(strpos($user_agent,$bad_bot)!==false){ if($logs){ array_unshift($bad_bots,$real_ip_user); $log_file = fopen($filename,"a+") or die("Connexion refusée."); fwrite($log_file,"\n"."\\".'BADACCESS BLOCKED: '.$bad_bot.' / '.date('Y-m-d H:i:s').'/USERAGENT: '.$user_agent.'/IPlogged: '.$real_ip_user.' /IPReal Or Proxy/IPReal If Proxy:'.$ip_proxy.'/'.$real_ip_user."//"."\n"."\n"); fclose($log_file); } die('blocked bot'); } }Et donc, ce que je pensais faire se voit avec cette ligne :
qui, pour moi, voudrait dire que l’on ajoute $real_ip_user dans le tableau $bad_bots.
Est-ce que je suis dans l’erreur? est-ce que mon script à une chance de fonctionner?
Merci Germain, si tu peux m’aider sur ce point, ainsi qu’à tou(te)s celles et ceux qui pourraient/voudraient bien me conseiller pour atteindre mon objectif.
Bonjour,
Si vous avez été infecté par la faille de sécurité PrestaShop XsamXadoo essayez de consulter ce billet pour voir s’il peut vous aider : https://www.webbax.ch/2020/01/09/corriger-la-faille-de-securite-xsamxadoo-sur-prestashop-ep-92/
À bientôt !