Augmentation anormale de la taille de la BDD et attaque bot "Bytespider"

[sebwvs]

Bonjour à tous,

Depuis quelques jours je reçois un avertissement de la part d'OVH pour dépassements de la mémoire vive "RAM" du serveur SQL

 

Mail : Abus avec votre CloudDB

"125 OOM kills detected during the last 24 hours.

To avoid data corruption, please optimize your queries or upgrade to a bigger offer."

 

Après quelques vérifications je vois que la taille de la BDD est passée de +/- 70mo à 580 mo

je vérifie mes logs et je trouves des milliers d'entrées de ce type : plusieurs par minutes

47.128.46.122 photoflameng.com - [18/Feb/2024:09:00:56 +0100] "GET /img/m/76-small_default.jpg HTTP/1.1" 200 2306 "https://photoflameng.com/7-accessoires?page=3&q=Marque-Cullmann-GODOX-LEOFOTO-Lastolite-Lexar-Panasonic-SONY-SMALLRIG" "Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; Bytespider; [email protected])"

 

Je suppose donc que ce bot augmente d'une façon ou d'une autre massivement la taille de la BDD et ralentis également l’accès au site web.

un avis ? une aide? 

*****************************edit*****************************

je pense avoir compris l'augmentation de la taille de la BDD de 70m à 580m , en faite le bot Bytespider passe en revue toutes mes urls et notamment via le filtre à facette  "Navigation à facettes" qui était configuré avec "Activer le système de cache" du coup ce cache grandit à vue d'oeil !

J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m !

Pour bloquer le bot Bytespider j'ai éditer mon htacces et ajouté un bout de code php dans l'index php à la racine en suivant la méthode de webbax>  https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/ 

pour ceux qui aurait le même problème ...

j'attend encore 2-3 jours et si ok j'éditerai ce post à résolut 

*****************************edit*****************************

 

*****************************

Version de PrestaShop : 1.7.8.3

Informations du serveur : Linux #1 SMP Wed Nov 30 08:49:06 UTC 2022 x86_64

Version du logiciel serveur : Apache

Version de PHP : 7.3.33

Limite de mémoire : 512M

Temps maximal d'exécution : 165

Taille max. pour envoi de fichiers : 128M

Version de MySQL : 5.7.42-log

Moteur MySQL : InnoDB

Connecteur MySQL : DbPDO

****************************

Edited February 19 by sebwvs (see edit history)

[magicbel]

Bonjour,

Pour comprendre déjà ce message, "OOM" veut dire "Out Of Memory"

Il s'active pour tuer des process afin de garder le système en ligne car sans, c'est d'office la saturation complète.

Dans votre cas, l'IP de l'exemple dans votre log est bien connue pour spammer le trafic comme un gros cochon

En savoir plus ici sur l'origine de l'IP : https://www.crawl-tools.com/fr/whois-client/60ef49a3c8c37efac580e83402ab6505

Optez pour la manière radicale, un beau ban de la totalité de ce range et adieu les problèmes

47.128.0.0/16

Vous n'êtes pas le premier ni le dernier à rencontrer ce problème.

Un client dernièrement avait le même souci (voir la charge avant le ban du range)

Voyez si vous pouvez via l'interface d'OVH mettre en place un firewall ou autres (comme une règle iptables par exemple) afin de ban ce range d'ip.

 

 

Edited February 18 by magicbel (see edit history)

[sebwvs]

il y a 2 minutes, magicbel a dit :

Bonjour,

Pour comprendre déjà ce message, "OOM" veut dire "Out Of Memory"

Il s'active pour tuer des process afin de garder le système en ligne car sans, c'est d'office la saturation complète.

Dans votre cas, l'IP de l'exemple dans votre log est bien connue pour spammer le trafic comme un gros cochon

En savoir plus ici sur l'origine de l'IP : https://www.crawl-tools.com/fr/whois-client/60ef49a3c8c37efac580e83402ab6505

Optez pour la manière radicale, un beau ban de la totalité de ce range et adieu les problème

47.128.0.0/16

Vous n'êtes pas le premier ni le dernier à rencontrer ce problème.

Un client dernièrement avait le même souci (voir la charge avant le ban du range)

Voyez si vous pouvez via l'interface d'OVH mettre en place un firewall ou autres (comme une règle iptables par exemple) afin de ban ce range d'ip.

 

 

Bonjour magicbel,

 

et merci pour la confirmation ...

le plus étrange est que sur mon serveur OVH j'ai bien un firewall (non paramétrable)activé !

depuis mon post ici, j'ai fait plusieurs recherches et je pense avoir trouver une solution ...

j'ai trouvé chez webbax >  https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/

j'ai édité le htacces pour bloquer les robots connus et j'ai édité également le fichier « index.php » à la racine avec un bout de code pour le blocage de certain user agent ainsi que l’écriture d'un fichier log simplifié qui me confirme le blocage du ou des bots ...

je viens juste de terminer ... j'ai nettoyé ma BDD avec le module Prestashop Optimizer 

tout à l'air de fonctionner pour le moment...

j'éditerais mon post à résolu dans 2-3 jours quand ça serra confirmé !

 

merci 

 

 

 

 

[sebwvs]

*****************************edit*****************************

je pense avoir compris l'augmentation de la taille de la BDD de 70m à 580m , en faite le bot Bytespider passe en revue toutes mes urls et notamment via le filtre à facette  "Navigation à facettes" qui était configuré avec "Activer le système de cache" du coup ce cache grandit à vue d'oeil !

J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m !

Pour bloquer le bot Bytespider j'ai éditer mon htacces et ajouté un bout de code php dans l'index php à la racine en suivant la méthode de webbax>  https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/ 

pour ceux qui aurait le même problème ...

j'attend encore 2-3 jours et si ok j'éditerai ce post à résolut 

*****************************edit*****************************

[Mediacom87]

il y a 51 minutes, sebwvs a dit :

J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m !

Vous pouvez programmer une tâche cron pour vider automatiquement le cache de ce module, ce qui peut éviter ce genre de problème de saturation de base.