Détecter les aspirateurs rapidement

OTP · 1 Novembre 2010

Bonsoir,

Je cherche un bout de script pour détecter les aspirateursen direct (par exemple plus de n requêtes depuis une IP dans l'heure passée) et interdire l'accès.

Savez-vous où je peux trouver un truc rapide et simple à mettre en oeuvre ? (pas de temps à perdre sur une usine à gaz) ?

Merci d'avance,

OTP

Julia41 · 1 Novembre 2010

ça pourrait se faire à l'aide de fail2ban en parsant les logs.
Par contre différencier un aspirateur d'un vrai visiteur qui fouine beaucoup peut être "bizarre".

Si par contre tu as énormément de page, tu devrais pouvoir définir sans trop de problèmes au bout de 1000 pages affichés dans un interval de *** secondes, alors on banni pendant *** temps.

OTP · 1 Novembre 2010

Il 'y a rien de plus facile que parser les logs ?

Là, j'ai une IP qui a fait 50k accès depuis ce matin. A partir de 10000 jours, je peux bannir sans hésiter.

Julia41 · 1 Novembre 2010

Comment tu sais qu'elle a fait 50K d'accès ? A partir de logs non ?

Code:

cat adminserv.log|cut -d " " -f 1| sort | uniq -c | sort -n

Ca m'indique le nombre d'accès par IP.

Si tu veux bannir en auto (à l'aide d'un .htaccess par exemple) :

Code:

for i in `cat adminserv.log|cut -d " " -f 1| sort | uniq -c | sort -n | awk {'if ($1 > 10000) print $2'}`;
do 
echo "deny from je ne connais plus trop apache $i" >> ton.htaccess.htaccess;
done;

En cron, avec un petit check de si déjà présent dans le .htaccess et le tour est joué je pense.

M&B Multimédia · 1 Novembre 2010

OTP a dit:
Il 'y a rien de plus facile que parser les logs ?

Là, j'ai une IP qui a fait 50k accès depuis ce matin. A partir de 10000 jours, je peux bannir sans hésiter.

Petite idée du jour : Avec une variable $_SESSION qui s'auto-incrémente au nombre de pages vues... au bout d'un certain nombre, tu engages une action quelconque...

OTP · 1 Novembre 2010

@Julia41 : c'est Awstat qui me le dit. Et je ne vais pas le voir tous les jours, malheureusement. Je suis sur un mutu OVH, je ne sais pas si je peux utiliser tes instructions.
@M&B Multimédia : facile à mettre en place ?

M&B Multimédia · 1 Novembre 2010

OTP a dit:
@M&B Multimédia : facile à mettre en place ?

Tout dépends de la façon dont ton site est construit aujourd'hui... En 5 minutes et quelques lignes simplistes de code plus tard tout peut être fonctionnel...

OTP · 1 Novembre 2010

Oui...
Et tu as ces quelques lignes ?

M&B Multimédia · 1 Novembre 2010

Bouarf comme ça "on the fly"

Code:

if ( !isset($_SESSION['nbrpgimp']) ) {
	$_SESSION['nbrpgimp'] = 1;
} else {
	$_SESSION['nbrpgimp'] = $_SESSION['nbrpgimp'] + 1;
}

if ( $_SESSION['nbrpgimp'] >= 10000 ) {
	echo 'Accès interdit ! Vous avez dépassé le nombre maximum de pages vues par jour sur le site';
	exit;
}

A mettre du côté de ton session_start(); dans un fichier commun à tout le site...
C'est à adapter et à peaufiner bien sûr...

Julia41 · 1 Novembre 2010

Ah j'étais sur du dédié

Donc oui, ce sera système de compteur (sinon, tu pourrais récupérer tes logs par le logs.ovh mais bon, ça sera moins efficace).

Donc système de compteur sur IP pourrait être bien (mais un peu lourd), dans ton header faudrait un :

Code:

INSERT INTO ip_log (ip, number) VALUES ('ip de l utilisateur', 1) ON DUPLICATE KEY UPDATE ... WHERE ip = 'ip de l utilisateur';

Dans ton header il faudra faire un SELECT number WHERE ip = 'ip de l utilisateur';
if $arr['number'] > 10000 {
die('bad bot');

Bon, ça fait 2 requêtes par page, donc mauvais et encore j'ai pas pris en compte la gestion du temps que tu demandais

Donc en clair ça me semble mort pour un truc léger, tu n'as qu'une solution usine

OTP · 1 Novembre 2010

Ok, je vois, merci.
Je ne dois pas être le seul pourtant à me poser ce genre de question. J'ai visohotlink sur le site, ça tourne bien, il y a peut-être des équivalents ?

Leonick · 1 Novembre 2010

M&B Multimédia a dit:
Petite idée du jour : Avec une variable $_SESSION qui s'auto-incrémente au nombre de pages vues... au bout d'un certain nombre, tu engages une action quelconque...

sauf à vouloir mettre l'id de session dans l'url, mais sinon, les aspirateurs n'utilisant pas les cookies, il n'y aura donc pas de suivi dans les variables $_SESSION :wink:

Julia41 · 1 Novembre 2010

Comme Leonick : l'aspirateur se moquera de ta session. Si tu la forces, pas mal de robots indexeur ne fonctionneront plus.

M&B Multimédia · 1 Novembre 2010

@Julia41 et @Leonick:

Soit j'ai du mal à accepter le changement d'horaire, soit je dois prendre des vacances... :lol: Je ne comprends pas pourquoi une variable de session PHP ne fonctionnerait pas dans ce cas la... Les cookies ?? les robots indexeurs ??... une petite explication serait bienvenue pour me dire à quel endroit je suis tombé dans l'erreur... car là, je ne vois pas...

Leonick · 1 Novembre 2010

le s_id a 2 possibilité de se transmettre : soit via cookie, soit via l'url.
les moteurs (bons ou mauvais) ne récupèrant pas les cookies, le seul moyen serait alors via l'url, mais se pose alors le problème de duplicate content (car le sid changeant selon la connexion, on va se retrouver avec beaucoup d'url différentes pour la même page).
exemple.com/mapage?sid=isdud8746D ou exemple.com/mapage?sid=5874746D etc...

M&B Multimédia · 1 Novembre 2010

@Leonick:

Ah bah je ne suis pas d'accord avec toi !

Il est possible de faire une session PHP sans passer par l'URL ou par un cookie en local.

D'ailleurs qui a parlé de SID ?

Dans mon exemple ci-dessus (et rappelé plus bas ci-contre), ou est le problème ?

Code:

if ( !isset($_SESSION['nbrpgimp']) ) {
   $_SESSION['nbrpgimp'] = 1;
} else {
   $_SESSION['nbrpgimp'] = $_SESSION['nbrpgimp'] + 1;
}

if ( $_SESSION['nbrpgimp'] >= 10000 ) {
   echo 'Accès interdit ! Vous avez dépassé le nombre maximum de pages vues par jour sur le site';
   exit;
}

Faites le test avec test.php

Code:

<?php
session_start();
if ( !isset($_SESSION['nbrpgimp']) ) {
   $_SESSION['nbrpgimp'] = 1;
} else {
   $_SESSION['nbrpgimp'] = $_SESSION['nbrpgimp'] + 1;
}

if ( $_SESSION['nbrpgimp'] >= 5 ) {
   echo 'Accès interdit ! Vous avez dépassé le nombre maximum de pages vues par jour sur le site';
   exit;
}
?>
<html>
<head>
</head>
<body>
<p>Contenu du site...</p>
</body>
</html>

Pas de variables dans l'url, pas de SID, pas de cookies... tout est géré par le serveur... pourquoi l'aspirateur ne suivrait-il pas les règles du serveur alors que c'est lui qui les impose ?

Leonick · 1 Novembre 2010

[quote="M&B Multimédia"Pas de variables dans l'url, pas de SID, pas de cookies... tout est géré par le serveur... pourquoi l'aspirateur ne suivrait-il pas les règles du serveur alors que c'est lui qui les impose ?[/quote]essaie ton script en bloquant les cookies de ton navigateur, très facile si tu as la webdevelopper toolbar sur FF
Et dis-nous si ton script arrive bien à bloquer le crawl.
PS : pour voir plus rapidement si ça fonctionne, passe la valeur de blocage à 2 pages vues max, par exemple :wink:

forummp3 · 1 Novembre 2010

M&B Multimédia a dit:
@Leonick:

Ah bah je ne suis pas d'accord avec toi ! Il est possible de faire une session PHP sans passer par l'URL ou par un cookie en local.

D'ailleurs qui a parlé de SID ?

Faites le test avec test.php

[...]

Pas de variables dans l'url, pas de SID, pas de cookies... tout est géré par le serveur... pourquoi l'aspirateur ne suivrait-il pas les règles du serveur alors que c'est lui qui les impose ?

quand tu utiliser les sessions, le serveur envoie soit un cookie, soit une variable dans l'url, a toi de regler cela.

M&B Multimédia · 1 Novembre 2010

J'ai désactivé sous IE... d'ailleurs la page Hotmail de démarrage me le signale "Les cookies doivent être autorisés"...

Et le script fonctionne toujours...

forummp3 · 1 Novembre 2010

[...]

forummp3 · 1 Novembre 2010

M&B Multimédia a dit:
J'ai désactivé sous IE... d'ailleurs la page Hotmail de démarrage me le signale "Les cookies doivent être autorisés"...

Et le script fonctionne toujours...

le script te bloque ?

si tu fait echo $_SESSION['nbrpgimp']; ca s'incremente ?

M&B Multimédia · 1 Novembre 2010

oui... au bout de 1 affichage + 4 refreshs...

forummp3 · 1 Novembre 2010

tu peux mettre le script en ligne pour qu'on puisse verifié? Si tu as testé en local, t'as vérifié que le navigateur desactive aussi en local? car certains navigateur ont des regles a par pour le reseau local.

finstreet · 1 Novembre 2010

et des logs persos ? Par exemple chaque accès au site, je l'inscris en base avec l'IP. C'est un fichier de log limité à 24h. Si y'a plus de x pages sur la même IP je peux bloquer si je veux automatiquement.

OTP · 1 Novembre 2010

Comment tu fais pour récupérer l'adresse IP (par .htaccess (si ça peut se faire) ou par un script sur chaque page) ?

finstreet · 1 Novembre 2010

un script sur chaque page...

OTP · 1 Novembre 2010

Et pour chaque page tu interroges la table des IPs pour voir si l'IP en question est indésirable ? On ne peut pas changer le .htaccess en dynamique via un script qui par exemple analyserait la table des IPs toutes les 10 minutes ?

Leonick · 1 Novembre 2010

forummp3 a dit:
tu peux mettre le script en ligne pour qu'on puisse vérifier?

+1 8O
j'aimerais bien voir ça, en effet. rajoute un

Code:

echo $_SESSION['nbrpgimp']." pages vues";

pour qu'on puisse bien visualiser l'incrémentation (ou non) de la valeur

Chaque visiteur accédant à votre page web se voit assigner un identifiant unique, appelé "identifiant de session". Il peut être stocké soit dans un cookie, soit propagé dans l'URL.

http://www.php.net/manual/fr/intro.session.php

finstreet · 1 Novembre 2010

OTP a dit:
Et pour chaque page tu interroges la table des IPs pour voir si l'IP en question est indésirable ? On ne peut pas changer le .htaccess en dynamique via un script qui par exemple analyserait la table des IPs toutes les 10 minutes ?

en pratique je le fais pas, mais tu peux simplement faire un auto increment pour que tu n'aies qu'une seule ligne par IP, et tu bloques toutes les IP qui ont plus de x visualisations en x heures

Leonick · 1 Novembre 2010

OTP a dit:
On ne peut pas changer le .htaccess en dynamique via un script qui par exemple analyserait la table des IPs toutes les 10 minutes ?

le problème des logs en mutu chez ovh, c'est que la mise à jour est assez aléatoire. Si tu regardes bien, l'ordre chronologique n'est pas toujours respecté et des fois, certains accès n'apparaissent pas dedans

OTP · 1 Novembre 2010

Ok, merci.
Yapluka...

(bientôt 14k !

)

M&B Multimédia · 1 Novembre 2010

forummp3 a dit:
tu peux mettre le script en ligne pour qu'on puisse verifié? Si tu as testé en local, t'as vérifié que le navigateur desactive aussi en local? car certains navigateur ont des regles a par pour le reseau local.

Script mis en ligne et effectivement à ce moment là cela ne fonctionne plus... Méa Culpa, j'ai encore appris quelque chose ici que je ne soupçonnais pas...

Merci à vous pour cet échange courtois et constructif !

Je passe donc mon tour pour trouver une solution à OTP... j'aurais quand même essayé !

OTP · 1 Novembre 2010

Je reste pour l'instant sur la méthode de finstreet.
Mais je demeure à l'écoute.

Leonick · 1 Novembre 2010

M&B Multimédia a dit:
Script mis en ligne et effectivement à ce moment là cela ne fonctionne plus...

par contre, ça serait bien de voir pourquoi en local il fonctionnait. Car pour que ton serveur de développement soit vraiment efficient, il faut qu'il ait la même config que celui de prod. Et au niveau des _session, il ne devrait pas fonctionner

Julia41 · 2 Novembre 2010

Il n'y a pas de solution miracle, soit le gouffre mysql (ou dans des fichiers), soit sur un dédié et là en pas longtemps c'est réglé.
Il faut que tu comptes, donc un compteur, soit tu regardes les logs.
Le compteur sera plus réactif mais boufera un peu toutes tes pages, les logs seront moins réactif mais ça passera inaperçu.

OTP · 2 Novembre 2010

Ok.
Tite question à deux balles : on a accès à ses logs en direct (je veux dire en lecture par un script php) sur un mutu OVH ?

forummp3 · 2 Novembre 2010

OTP a dit:
Ok.
Tite question à deux balles : on a accès à ses logs en direct (je veux dire en lecture par un script php) sur un mutu OVH ?

Les logs peuvent faire des Go et c'est de simples fichiers text sans index, donc mieux vaut utiliser mysql que des fichiers log (tu log chaque ip dans une table mysql avec un index sur l'ip, et a chaque visite, tu fait un count(*) sur l'ip).

edit: sinon, pour detecter un robot rapidement et facilement, tu met un lien sur une image transparante de 1 pixel, a part les robots, personne ne cliquera dessus, et sur la page de destination, tu log l'ip et tu verifie ensuite si c'est un robot connu ou pas.

OTP · 2 Novembre 2010

Ok, merci pour les conseils.

ricosound · 2 Novembre 2010

Salut Michael.

Je vais te faire la même recommandation qu'a milkyway, crawlprotect ; il traite plein d'aspirateurs de sites directement au niveau htaccess.

http://www.crawltrack.net/crawlprotect/fr/

Je sait, j'en fait une bonne promo, mais ça m'a sorti d'un beau pétrin et visiblement je ne suis pas le seul.

A +, Éric.

OTP · 2 Novembre 2010

Ca parait bien répondre au problème, en effet.

Zecat · 2 Novembre 2010

forummp3 a dit:
edit: sinon, pour detecter un robot rapidement et facilement, tu met un lien sur une image transparante de 1 pixel, a part les robots, personne ne cliquera dessus, et sur la page de destination, tu log l'ip et tu verifie ensuite si c'est un robot connu ou pas.

Perso je fais l inverse :

1 - j identifie si le visisteur est un bot autorisé
2 - je ne presente les pixels pieges (en fait ils sont 4 ou 5 par page ...) qu'aux autres visiteurs ...
3 - Le pixel piege chnage de place dans le spages toutes les minutes ainsi que le nom du script executé
4 - le script "clic sur pixel piege" : inscrit l'ip comme ban, m'envoie un mail avec le detail et redirige via header vers une page "Vous etes banni".

J'ai couplé ca avec un ban auto si plus de nn pages vues par minute pour une meme ip (apres mouletes test j ai réglé à 15) et par ailleur j'ai mis en place un dispositif anti aspi via proxy et multipleS ip : une stat temps réel du nombre de visu par série de pages (c'est souvent un peu con les bots) et cette stat triés par nb ... et du coup juste a jeter un oeil une fois par jour pour couper la tete aux 2 ou 3 en tete de liste ...

Au final y a plus grand chose qui passe : j'ai pu comparer avec un site que j'ai laissé 'open bar' --> je vois des goinfrage de bot par centaines et milliers de pages ... Sur mon site 'bar sur invitation', c'est rarissime qu'un aspi arrive a depasser 20 ou 30 pages avant de se faire couper la tete ...

Interet : aucune intervention htaccess ... une fois une ip ban, c'est header direct vers page "vous etes banni". Au pire, si un bot insiste vraiment trop alors je me fends d'un deny dans htaccess (en 6 mois j'ai du mettre 4 ou 5 IP en deby pour un millier abnnies)

zeb · 2 Novembre 2010

Leonick a dit:
par contre, ça serait bien de voir pourquoi en local il fonctionnait.

Je pense que le cache du navigateur n'avait pas été vidé (coockies purgés)

Sinon par rapport au problème visé et pour éviter les requêtes sql de fou il y a la solution fichier.

Un script qui créé un fichier du genre ip-visiteur.php avec le timestamp de la visite dedans genre :

Code:

<?php $visiteTime=123456789; ?>

avec un algo du style en tête de page :
- si le fichier existe pas on le crée et on affiche la page.
- sinon on l'inclus
- si timestampActuel - tempsMiniParPage < $visiteTime -> ban

Le système se base sur un interval moyen entre chaque page consulté
Une petite purge par CRON est a prévoir pour vide le dossier de temps en temps et il faut faire attention aux IP google etc ... (mais bon tous les système doivent prendre en compte une IP de bot valide)

forummp3 · 2 Novembre 2010

Zecat a dit:
forummp3 a dit:

edit: sinon, pour detecter un robot rapidement et facilement, tu met un lien sur une image transparante de 1 pixel, a part les robots, personne ne cliquera dessus, et sur la page de destination, tu log l'ip et tu verifie ensuite si c'est un robot connu ou pas.

Cliquez pour agrandir...

Perso je fais l inverse :

1 - j identifie si le visisteur est un bot autorisé
2 - je ne presente les pixels pieges (en fait ils sont 4 ou 5 par page ...) qu'aux autres visiteurs ...
3 - Le pixel piege chnage de place dans le spages toutes les minutes ainsi que le nom du script executé
4 - le script "clic sur pixel piege" : inscrit l'ip comme ban, m'envoie un mail avec le detail et redirige via header vers une page "Vous etes banni".

J'ai couplé ca avec un ban auto si plus de nn pages vues par minute pour une meme ip (apres mouletes test j ai réglé à 15) et par ailleur j'ai mis en place un dispositif anti aspi via proxy et multipleS ip : une stat temps réel du nombre de visu par série de pages (c'est souvent un peu con les bots) et cette stat triés par nb ... et du coup juste a jeter un oeil une fois par jour pour couper la tete aux 2 ou 3 en tete de liste ...

Au final y a plus grand chose qui passe : j'ai pu comparer avec un site que j'ai laissé 'open bar' --> je vois des goinfrage de bot par centaines et milliers de pages ... Sur mon site 'bar sur invitation', c'est rarissime qu'un aspi arrive a depasser 20 ou 30 pages avant de se faire couper la tete ...

Interet : aucune intervention htaccess ... une fois une ip ban, c'est header direct vers page "vous etes banni". Au pire, si un bot insiste vraiment trop alors je me fends d'un deny dans htaccess (en 6 mois j'ai du mettre 4 ou 5 IP en deby pour un millier abnnies)

ton systeme inverse est un peu dangereux en cas de mauvaise reconnaissance du google bot par exemple (changement de header du bot ou aucun). Il se peut aussi qu'un visiteur cliquement par hazard sur l'image (si t'as des milliers de visiteurs, ya des chances pour que l'un clique au hazard sur la page en la lisant).

Mais ta methode de plusieurs nom de pages pieges differentes est pas mal, suffit alors de bloquer les visiteurs qui cliquent plusieurs fois sur ces pages pieges et pour ceux qui cliquent souvent, verifier le header pour voir si c'est un bot de moteur de recherche ou aspirateur, comme ca, impossible de bloquer un membre qui clique une seul fois sur ce lien piege. (ou alors mettre un catpcha sur la page piege pour qu'un simple visiteur puisse se desactiver le ban).

Leonick · 2 Novembre 2010

zeb a dit:
si timestampActuel - tempsMiniParPage < $visiteTime -> ban

j'avais, un moment, procédé avec ce genre de timming, mais même moi je me faisais bloquer :mrgreen: dès qu'on fait un clic centre, sur plusieurs liens ou bien qu'on ouvre un bloc de pages avec FF (option "tout ouvrir dans des onglets") on se retrouve largement en dehors de l'utilisation autorisée

Julia41 · 2 Novembre 2010

ricosound a dit:
Salut Michael.

Je vais te faire la même recommandation qu'a milkyway, crawlprotect ; il traite plein d'aspirateurs de sites directement au niveau htaccess.

http://www.crawltrack.net/crawlprotect/fr/

Je sait, j'en fait une bonne promo, mais ça m'a sorti d'un beau pétrin et visiblement je ne suis pas le seul.

A +, Éric.

Si c'est de l'aspiration "parce que c'est toi", un user agent se change très simplement. Donc bon...

Sinon, au niveau des logs mutu non accessible "automatiquement", perso je créé souvent (bon j'utilise plus trop le mutu) un dossier "logs" et je créé mes logs en PHP avec la fonction "error_log":

Code:

error_log($ip . ' GET ' . page demandé en php....');

le tout dans un dossier /logs/ protégé par .htaccess.
Ca m'évite d'avoir à aller sur le truc de log d'OVH, et surtout je les ai en temps réel.

OTP · 2 Novembre 2010

Tu veux dire qu'un aspi fait sur mesure ne sera pas vu ?

Pas trop envie de coder, mais bon, si je dois le faire...

Julia41 · 2 Novembre 2010

(j'arrive pas à te quoter depuis hier (enfin t'es pas le seul)).

Je prends l'exemple de wget (qui permet de faire un aspirateur en une seule ligne de commande) :

Code:

wget tapage.html

je la récupère, dans tes logs, tu vois "wget"

Maintenant :

Code:

wget --user-agent=GoogleBot tapage.html

tu verras "google bot".

OTP · 2 Novembre 2010

Ok, je vois...

Pour la quote, c'est nouveau : on ne peut plus quoter le dernier message.

forummp3 · 2 Novembre 2010

c'est un peu de la merde de ne pas pouvoir quoter le dernier message, car sur un gros forum comme wri, il peut y avoir plusieurs messages entre le debut de la redaction et de la reponse et l'envoye de la reponse, ce qui fait que les gens ne savent plus a qui l'on repond...

OTP · 2 Novembre 2010

finstreet a dit:
en pratique je le fais pas, mais tu peux simplement faire un auto increment pour que tu n'aies qu'une seule ligne par IP, et tu bloques toutes les IP qui ont plus de x visualisations en x heures

Tu fais comment avec cette méthode pour déterminer le nombre de visu en x heures ???

OTP · 2 Novembre 2010

forummp3 a dit:
c'est un peu de la merde de ne pas pouvoir quoter le dernier message, car sur un gros forum comme wri, il peut y avoir plusieurs messages entre le debut de la redaction et de la reponse et l'envoye de la reponse, ce qui fait que les gens ne savent plus a qui l'on repond...

Pas faux...
Faut taper vite !

forummp3 · 2 Novembre 2010

oui, mais si on tape vite, les autres aussi vont taper vite, donc il risque d'y avoir encore plus de message entre temps, c'est le serpent qui se mort la queue, un cercle vicieux

OTP · 2 Novembre 2010

En effet.
Je te conseille d'ouvrir un topic spécifique dans le forum des suggestions.

Pour revenir à mes moutons, je viens de trouver ça : http://www.php-astux.info/traceip-anti-aspirateur-site-web.php
Ca vous cause ?

Julia41 · 2 Novembre 2010

ça en revient à ce que j'avais dit sur le stockage et comptage des IPs, ça devient alors une usine.
Tu peux le mettre en place mais bon, ça va vite être énorme.

OTP · 2 Novembre 2010

Booooooooooouuuuuuuuuuhhhhhhhhhh !!! :cry: :cry: :cry:

forummp3 · 2 Novembre 2010

Julia41 a dit:
ça en revient à ce que j'avais dit sur le stockage et comptage des IPs, ça devient alors une usine.
Tu peux le mettre en place mais bon, ça va vite être énorme.

avec une base de donnée et des index bien placé, c'est trés leger, meme avec des millions d'enregistrements. tu peux aussi supprimer au fur a mesure les logs vieux de plus de 24h ou 48h, donc si t'as quelques milliers d'ip par jour, ca te fera seulement quelques milliers de ligne dans ta tables, donc presque negigleable pour mysql.

OTP · 2 Novembre 2010

Je vais essayer, je verrai bien.

forummp3 · 2 Novembre 2010

test sur un site peu important, car s'il y a un bug, ca risque de te bloquer tous les moteurs de recherche.

OTP · 2 Novembre 2010

Mais je n'ai pas de site peu important !!!

finstreet · 2 Novembre 2010

le problème des gens riches ca

OTP · 2 Novembre 2010

Si seulement...

Tiens : https://www.webrankinfo.com/forum/detecter-les-aspirateurs-rapidement-t1356 ... l#p1237495 !

Leonick · 2 Novembre 2010

forummp3 a dit:
test sur un site peu important, car s'il y a un bug, ca risque de te bloquer tous les moteurs de recherche.

sinon, solution que j'utilise à certains moments : tu enregistres les crawls que tu estimes devoir bloquer mais que tu laisses quand même (en plaçant la barre un peu plus basses) et tu vérifies si dans tes logs il n'y a pas de faux positifs. Dans ce cas, tu mets en fonctionnement le blocage

zeb · 7 Novembre 2010

De toute façon il faut se rendre a l'évidence, il n'y a pas d'anti-aspirateur parfait.

Le userAgent ça se bidouille donc faut pas compter que la dessus, une IP peut se bloquer mais avoir des retombées négatives (imaginons par exemple un enseignant qui pompe un site via un réseau du gouvernement et tu bloque tout le monde)

Donc la solution ne peut être que quelque chose de semi-automatique qui est modéré en aval.

OTP · 7 Novembre 2010

C'est à ça que je suis arrivé.
Ban auto des IPs, rétablissement éventuel à la main par la suite.

talcan · 13 Novembre 2010

Les variables de session ne sont pas fiable si le visiteur malveillant n'accepte pas les cookies
J'ai crée une fonction en vb.net qui stocke à chaque requête, l'ip, l'user agent et la date au format jj/mm/aaaa hh:mn:ss dans un fichier texte.
A chaque requête, je calcule le temps passé par tranche de 20 ip stockées. On peut dire que si 20 requêtes sont effectuées en moins de 40 secondes c'est probablement un aspirateur.
Ces valeurs peuvent changer en fonction de la configuration du site. Pour les aspirateurs que j'ai pu bloquer c'était de l'ordre de 1 à 3 requêtes par secondes donc impossible pour un humain.

Leonick · 13 Novembre 2010

enregistre plutôt la valeur en microtime plutôt que jj/mm/aaaa hh:mn:ss ça évitera de devoir convertir la date à chaque calcul

talcan · 15 Novembre 2010

pas besoin en vb, la fonction DateDiff("s", d1, d2) renvoi l'écart en seconde entre 2 dates aux formats jj/mm/aaaa hh:mn:ss

finstreet · 15 Novembre 2010

en même temps il utilise pas VB.