Journal Satanées bots

Posté par  (site Web personnel) .
Étiquettes : aucune
0
27
nov.
2007
J'ai trois trois site ([http://www.linuxcertif.com],[http://iverb.ikipou.com],[http://www.magellan.fpms.ac.be]) hébergé sur le même serveur. Des trois, Linux Certif est le plus populaire, et mon problème est que sa charge venant de bots vient handicaper les deux autres sites.

Cela est vraiment devenu un problème ce week-end car quelqu'un a commencé à télécharger agressivement toute les pages de Linux Certif à l'aide de HTTrack.

Pour résoudre le problème, j'ai envisagé d'utiliser des limites sur le nombre de paquets par IP par seconde. Néanmoins, cela ralentirait tout le monde alors que le problème ne vient clairement pas de la bande passante.

Je suis à la recherche d'une solution qui me permettrait de limiter les visites abusive (comprendre, ralentir les bots un peu trop agressifs), sans pour autant ralentir le trafic normal.

Je pourrais évidemment bloquer les clients en fonction de l'en tête User-Agent, mais il existe peut être une solution plus intelligente basé sur le comportement du client? De plus je ne cherche pas à bloquer complètement les bots mais à les ralentir.

Bref, tout vos conseils et retour d'expérience pour ralentir les bots trop agressif sont les bienvenus.
  • # Limiter le nombre de requête par IP

    Posté par  . Évalué à 3.

    Pourquoi ne pas limiter le nombre de requête par minutes par IP ?
    Ça pourrait être une piste.
    Pour la réalisation: un firewall entrant qui loggue tout les paquets TCP syn. Un script qui parcours le fichier log, et qui calcule le nombre de fois qu'une IP est présente (en bash, uniq peut aider, ainsi que wc). Si ce nombre est trop élevé, tu injectes une règle iptable qui limite le nombre d'accès pour cette/ces IPs. Au bout de x minutes, tu enlèves la limitation.

    Voilà, si ça peut t'aider
    • [^] # Re: Limiter le nombre de requête par IP

      Posté par  (site Web personnel) . Évalué à 4.

      Il suffit d'estimer effectivement ce qu'un homme est capable de faire à la minute, par exemple max 20 cliques et de mettre cela dans iptables au niveau du parametre limit. J'ai ce genre de règle en permanence et aucune injection de règle à chaud et cela marche très bien.

      Je met surtout cela sur un serveur ssh. Je n'autorise par exemple que 2 ou 3 nouvelles connections par minutes et du coup, je n'ai quasiment plus d'attaque sur ce port...
    • [^] # Re: Limiter le nombre de requête par IP

      Posté par  (site Web personnel) . Évalué à 5.

      Attention la grande limite de ce système ce sont les grandes structures (entreprises, écoles, etc ...), en effet ton site peut devenir rapidement inaccessible pour des dizaines voire des milliers de personnes derrière une NAT (c'est du vécu)
  • # if (bot) then sleep(10); avant de continuer

    Posté par  . Évalué à 2.

    puisque plusieurs bots dont celui de Google ne respectent pas le Crawl-Delay

    en PHP il existe une fonction idéale pour ce cas : auto_prepend_file, qu'on peut limiter à un seul virtual host si nécessaire (avec php_value auto_prepend_file /tonchemin/calmos_les_bots.php dans le virtual host ou le .htaccess du site)

    mais visiblement ton site est en Python.
  • # Google?search=apache+limit+ip

    Posté par  . Évalué à 2.

    • [^] # Re: Google?search=apache+limit+ip

      Posté par  (site Web personnel) . Évalué à 1.

      J'ai envisagés les limites par IP mais j'imagine qu'il existe des heuristiques plus intéressante (peut être le nombre de burst par seconde par connexion?).

      La remarque de Frederic Bourgeois est aussi très pertinente pour les limites par IP.
  • # Belnet

    Posté par  (site Web personnel) . Évalué à 1.

    D'un autre côté, tes trois sites web sont hébergés dans ton université (gratuitement je suppose). Je doute que le service informatique de l'Université de Mons-Hainaut ait l'accès aux sites web hébergés comme priorité absolue (ni que Belnet, fournisseur de la connection filtre ce qui passe).

    Ma suggestion serait de passer chez un vrai hébergeur (pas nécessairement commercial : il y en a des bons en associatif aussi).
  • # Bad Behavior

    Posté par  (site Web personnel) . Évalué à 3.

    Essaye déjà de voir si tu ne peux pas utiliser Bad Behavior :
    http://www.bad-behavior.ioerror.us/

    C'est un script qui en fonction de l'User-Agent et des actions d'un visiteur décide si oui ou non il peut la laisser passer. Il renvoie un simple 403 ou 412 si l'utilisateur est "à bloquer".

    Il existe des plugins pour la majorité des CMS mais tu peux adapter à ta façon.

    Perso, il me bloque des dizaines et des dizaines de bots "aspirateurs" tous les jours. Je n'ai jamais eu de plaintes de visiteurs normaux bloqués même si il est possible que ça puisse arriver.

    Dans ton cas, c'est la première chose que j'essaierai.
    • [^] # Re: Bad Behavior

      Posté par  . Évalué à 3.

      Les visiteurs normaux qui sont bloqués ne peuvent pas se plaindre, car ils ne trouvent pas comment te contacter ;-)
      • [^] # Re: Bad Behavior

        Posté par  (site Web personnel) . Évalué à 3.

        Non parce que la page d'erreur contient une adresse de contact (du moins en théorie, moi je ne l'ai jamais vue, j'ai jamais réussi à me faire bloquer)
  • # Alternative : partager

    Posté par  (site Web personnel) . Évalué à 2.

    Une solution alternative est de partager le contenu de linux certif (avec licence, etc).

    Par exemple faire un export dans une archive, ou mieux générer un fichier pdf ou autre de documentation, que l'on met en ftp et que les visiteurs peuvent télécharger.
    • [^] # Re: Alternative : partager

      Posté par  (site Web personnel) . Évalué à 2.

      Je ne demande pas mieux mais c'est gênant pour tenir l'archive à jour avec les mises à jour du site.

      En fait ce genre de fonctionnalité est sur la TODO list mais la priorité actuelle est de faire de nouveaux articles.
  • # User-Agent

    Posté par  (site Web personnel) . Évalué à 3.

    Inutile de chercher de ce coté, 99% des aspirateurs web se faisant passer pour IE...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.