À l'époque où je travaillais à hébergement d'une modeste forge pour un chaton (à usage essentiellement interne), j'avais fait face à ce genre de robot indélicat. Je suppose aussi que le gittea de l'époque était assez sensible au crawling ; certains liens remontant pas mal d'info longues à consolider, comme les blames par exemple.
J'avais été amené à durcir les limites de navigation, notamment sur les blames (1 max par secondes), vérifier la bonne mise en relation du serveur web et du fail2ban (pour bannir les indélicats). Mais ça n'avait pas suffit. J'ai opté pour une solution radicale : un honeypot (pour bot) suivi d'un ban pur et simple. C'était efficace de mémoire.
Dans le même ordre d’idée, j’avais hésité à poster ce lien fin janvier (j’ai finalement estimé que peu de gens étaient concernés par l’objet du site/forum en question mais la problématique demeure finalement) : outre les bots qui cherchent des failles, ce sont maintenant les entrainements d’intelligence artificielle qui pourrissent le web en aspirant sauvagement les sites…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Il faut être un peu large sur les bans. Pour ma part j'ai fini par exclure toutes les IP de Meta, de Alibaba Cloud, et de Huawei par exemple.
Cela ne va probablement pas perturber les utilisateurs normaux de mon site.
En complément, j'ai aussi un système de ban à partir du user agent:
Le robot fait une ou plusieurs requêtes sur le serveur HTTP
Le serveur répond avec une erreur spécifique (erreur 403 indiquant un accès refusé) pour les user agent que j'ai bloqués (principalement ceux qui ne respectent pas le Crawl-Delay du robots.txt et génèrent plus de traffic que tous les visiteurs non-robotiques combinés).
Fail2ban surveille les logs du serveur HTTP, toute IP qui déclenche des erreurs 403 va assez rapidement être bannie au niveau du pare-feu.
Cette deuxième protection prend un peu de temps à faire effet, mais déjà le fait de retourner une erreur 403 au lieu d'une vraie page au niveau du serveur web, ça réduit considérablement la charge CPU.
Ensuite on peut consulter la liste d'IP bannies par fail2ban, trouver les plages d'IP correspondantes à l'aide d'un whois IP, et décider s'il s'agit d'un range à bloquer manuellement ou pas.
# .
Posté par Pol' uX (site web personnel) . Évalué à 10 (+8/-0).
À l'époque où je travaillais à hébergement d'une modeste forge pour un chaton (à usage essentiellement interne), j'avais fait face à ce genre de robot indélicat. Je suppose aussi que le gittea de l'époque était assez sensible au crawling ; certains liens remontant pas mal d'info longues à consolider, comme les blames par exemple.
J'avais été amené à durcir les limites de navigation, notamment sur les blames (1 max par secondes), vérifier la bonne mise en relation du serveur web et du fail2ban (pour bannir les indélicats). Mais ça n'avait pas suffit. J'ai opté pour une solution radicale : un honeypot (pour bot) suivi d'un ban pur et simple. C'était efficace de mémoire.
Adhérer à l'April, ça vous tente ?
[^] # ia crawl
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Dans le même ordre d’idée, j’avais hésité à poster ce lien fin janvier (j’ai finalement estimé que peu de gens étaient concernés par l’objet du site/forum en question mais la problématique demeure finalement) : outre les bots qui cherchent des failles, ce sont maintenant les entrainements d’intelligence artificielle qui pourrissent le web en aspirant sauvagement les sites…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: .
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
Le ban ne fonctionne pas, il change d'IP.
"La première sécurité est la liberté"
[^] # Re: .
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Il faut être un peu large sur les bans. Pour ma part j'ai fini par exclure toutes les IP de Meta, de Alibaba Cloud, et de Huawei par exemple.
Cela ne va probablement pas perturber les utilisateurs normaux de mon site.
En complément, j'ai aussi un système de ban à partir du user agent:
Cette deuxième protection prend un peu de temps à faire effet, mais déjà le fait de retourner une erreur 403 au lieu d'une vraie page au niveau du serveur web, ça réduit considérablement la charge CPU.
Ensuite on peut consulter la liste d'IP bannies par fail2ban, trouver les plages d'IP correspondantes à l'aide d'un whois IP, et décider s'il s'agit d'un range à bloquer manuellement ou pas.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.