Plugin DotClear 2 anti-flood et anti-aspirateur

Ce blog utilise DotClear 2, comme les lecteurs avertis l'auront peut-être remarqué. Comme tout blog, et d'une manière générale comme tout site web, ce blog est visité par des robots afin de trouver et d'utiliser des failles potentielles pour spammer les commentaires, repomper le contenu, trouver des problèmes de sécurité. Des prefetchers ou proxys peu scrupuleux peuvent visiter votre site.

Pourquoi est ce un problème ?

En l'absence de problème de sécurité, ces robots s'ils sollicitent trop le serveur, peuvent l'écrouler et le rendre indisponible aux vrais utilisateurs. Donc vous devez sur-dimensionner votre serveur car ces robots demandent trop de ressources à votre serveur.

Un serveur bien configuré doit pouvoir supporter cela, grâce à des systèmes de cache côté serveur et la surveillance des connexions grâce aux pare-feu, routeurs, modules apache. Ces outils se basent sur les connexions faites au serveur Apache. Or, fournir une image ou une page php ne demande pas les mêmes ressources, et ces robots demandent que des pages php pour passer sous les seuils des outils serveurs

Côté applicatif, en l'occurrence ici DotClear, un système de cache est nécessaire mais parfois non suffisant. J'ai donc développé un plugin qui fait office de disjoncteur.
Si le blog est floodé, inondé de requêtes sur les pages php, le plugin retourne une erreur 503 (Service indisponible). Le système de notation peut également bloquer les aspirateurs de site, basé sur leurs comportements (et pas leur user-agent).

On ne peut plus déposer d'extension sur le site DotClear depuis quelques temps, aussi je propose cette extension ici, en espérant qu'elle soit utile à la communauté DotClear.

N'hésitez pas à me faire part de vos commentaires et avis sur ce plugin pour aider à l'améliorer !

Mise à jour le 30/06/09Voici la version 0.4, qui permet d'affiner le scoring et éventuellement recevoir un email d'alerte. Cela se configure la section du plugin dans "about:config".
Le plugin n'utilise plus les sessions pour stocker les informations, mais la base de données. Ainsi, le plugin fonctionne même avec les "vrais" robots ou proxies qui n'acceptent pas les cookies.
Mise à jour le 01/07/09Suite à quelques retours, le projet est désormais publié sur Google Code pour une maintenance plus facile, et pourquoi pas participative.
C'est l'occasion de mettre en ligne une nouvelle version (0.5) permettant aux sites peu fréquenté de toute de même purger la table MySQL stockant les IP.

Téléchargement du plugin

Tags: 

Commentaires

 salut,J'ai repéré le meme pobleme sur mon site, j'ai installé le public, mais j'ai des warnings:62Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/clearbricks/common/lib.http.php on line 211Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/clearbricks/common/lib.http.php on line 213Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/clearbricks/common/lib.http.php on line 213Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/clearbricks/common/lib.http.php on line 213Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/public/lib.urlhandlers.php on line 59Warning: Cannot modify header information - headers already sent by (output started at /xxx/xxx/xxx/plugins/anti-aspirateur/_prepend.php:54) in /xxx/xxx/xxx/inc/clearbricks/common/lib.http.php on line 236Je fais quoi, je commente les lignes en questions ???

 Il restait une sortie pour le débogage quand j'ai repackagé le plugin. J'ai corrigé cela dans le fichier en téléchargement.Désinstalle le plugin et ré-installe cette nouvelle version. Cela devrait rentrer dans l'ordre.Merci du retour.

Effectivement c'est bon.Merci beaucoup

 A l'usage, certains outils responsables des pics de charge n'acceptent pas les cookies de session. Je suppose que les outils intégrés au navigateur doivent gérer ces cookies, mais pas les proxys d'entreprise.Le filtrage par session est donc inopérant dans ce cas. Je vais étendre le plugin afin de prendre en compte les "vrais bots" qui n'ouvrent pas de sessions.

 Bonjour,Je viens d'installer et d'activer le plugin sur mon blog (en lien) .En effet de temps à autre j'ai des visites de proxies d'entreprises qui viennent lire des 10aines , voire centaines de pages en 3 minutes.Par exemple ce matin , le proxy de carrefour est venu lire 1394 pages en 3 minutes. Oui, vous avez bien lu.Dans ce cas APC Cache, StaticCache et même la limitation de connexion par adresse IP ( possible dans Lighttpd avec mod_evasive) ne servent a rien.Le proxy étrangle tout: il va par exemple demander a StaticCache de cacher des pages par centaines en quelques minutes. Dans ce cas, PHP est étranglé et occupé à créer des fichiers statiques .. depuis MySQL qui s'étrangle un peu aussi.Je vous propose donc de servir de béta testeur. Par ce que des proxies comme ça, le lundi matin ou après midi j'en ai quelques uns qui viennent chercher la bonne soupe. Et d'autres dans la semaine.Mon adresse mail est renseignée .

 @dagrouikLe plugin marche bien quand mod_evasive passe au travers.Je m'explique, si on a 1 page php avec 25 images, un client adsl va faire 26 requetes en 2 secondes on va dire, soit 13 requêtes / seconde.Il y a 25 images donc peu de ressources consommées.Si on fait la même chose avec des pages php, à 13 pages php / seconde, la charge est tout autre !C'est là la limite de mod_evasive. Je suppose que c'est la même chose avec lighttp qu'Apache.Il ne bloque que les accès à la même url, et non le nombre de requêtes par seconde.Je suis en train de tester mod_cband (qui lui permet des limites par ip en requets/seconde) en comparaison/complément du plugin.

 Mon probleme: les proxies qui lisent 360 pages en 40 secondes (celui d'alcatel) , ou 1400 en 80 secondes ... dans ce cas mod_evasive bloque dès que 20 connex sont ouvertes par la même IP, ça donne alors une erreur 403 qui va bloquer l'@IP après en gros 1/3 des pages servies avec un résultat 200 ( donc OK).Et dans ce cas, avec ou sans cache statique, avec ou sans APC ça ne change rien.Le proxy réclame en effet des pages qui datent de quelques mois, voire de l'année dernière. Mysql va donc travailler pour sortir le billet, les commentaires, PHP génère le truc, le cache la version statique.Certains proxies sont même sur plusieurs @IP : ils font du load balancing ces saloperies.J'ai pu comparer deux comportements :1/ le proxie de carrouf , qui se fait 403 au bout de 200 pages pour 1400 demandes. En moyenne 5 connexion/seconde à ce niveau là. il provoque les troubles cité ci-dessus , load du CPU à 100%, PHP qui consomme 90% du CPU, MySQL qui répond lentement. Tout ça pour en gros 5 Minutes. Le temps que ça se vide.2/ un système de test charge http://loadimpact.com/ qui simule un usage normal : il va cliquer sur les liens de la home par exemple, mais de manière aléatoire pour simuler le client ordinaire. Là il grimpe à 100 connex/secondes SANS que ça ne crée de trouble dans PHP/MYSQL : par ce que ce type de test va lire les billets les plus récents vus depuis la home page, donc ceux qui sont déjà dans le cache statique !Et lors de ce 2e test, je n'ai eu aucun souci, la visite du blog était aussi fluide. Je suis alors monté à 70 connexions sans pépins.C'est bien le comportement des proxies les plus dangereux : ça fait 2 ans que je le vis. Et malheureusement, par exemple, je ne peux pas bloquer le parlement Européen.Et je n'ai qu'une pauvre Kimsufi avec un céléron à 1,2 Ghz et 1Go de RAM.

 du progrès ! finalement, comme j'ai du temps à perdre.. J'ai regardé comment les proxies venaient. En gros quel est le comportement du truc au début.Et là c'est simple , depuis l'@IP du proxy vient une lecteur de billet, commentaire. C'est logique : c'est un être humain avec un user agent complet, du genre "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11". Les plus fous sont en IE XXXX ...Donc leur USER AGENT est rempli.Puis le proxy utilisé par l'entreprise, se dit "oh mais que je suis bête allons réclamer les billets que j'ai stocké dans mon cache", et se met à les réclamer. Mais lui est un gros truc et dans 99% des cas, son USER AGENT est simple du genre "Mozilla/4.0 (compatible;)".La solution est alors de filtre ces saloperies, via une règle dans Apache ou Lighttpd ce qui est mon cas :$HTTP["useragent"] =~ "^Mozilla/4\.0\ \(compatible\;\)$" {url.access-deny = ( "" )}Du coup, la connexion de mon lecteur passe, et le proxy qui réclame son dû se prend des 403 directement.Bien sûr si ce vil engin prenait un USER AGENT plus complet, je serai obligé de m'adapter. Mais au vu de quelques tonnes de logs, c'est assez sûr.

 Je viens de mettre en place le plugin sur mon blog. J'ai attendu une attaque (j'en ai une ou deux par jour, où tous les articles de mon blog sont demandés par une même IP en une ou deux secondes, mettant à genou apache et mysql). J'ai reçu 60 mails du plugin qui me signale le blocage, mais cela n'a eu aucun effet : apache et mysql à fond et serveur au taquet.J'ai vérifié le code, et j'ai vu un truc bizarre qui me semble être un vrai bug, ligne 100 de _prepend.php :DELETE FROM dc_anti_aspi WHERE date < (NOW() - ' . (int)$core->blog->settings->score_page_vueOn soustrait un score à une date ?J'ai remplacé score_page_vue par duree_blacklist et ça a tout de suite marché beaucoup mieux !Si ça peut aider d'autres blogueurs...

Ajouter une réponse