Ensemble luttons contre les pirates
- Auteur de la discussion orvinfait
- Date de début
il me semble que c'est la 1ere fois que tu es la victime d'un scanbot, bon courage, car ce n'est pas la dernière,
vois ici
https://www.webrankinfo.com/forum/t/logs-bizarre-libwww-perl-sur-gp60ovh-hier-et-avant-hier.76007/
https://www.webrankinfo.com/forum/t/attention-probleme-de-securite-avec-spip-eva.76189/
ces deux topics concernaient un site sous spip, ça peut concerner du joomla également. il est inutile de porter l'affaire devant les tribunaux à chaque fois, tu y passerais ta vie, bloque l'accès et passe à autre chose.
P.S. il ne s'agit pas d'un piratage à chaque fois que tu as un .404
vois ici
https://www.webrankinfo.com/forum/t/logs-bizarre-libwww-perl-sur-gp60ovh-hier-et-avant-hier.76007/
https://www.webrankinfo.com/forum/t/attention-probleme-de-securite-avec-spip-eva.76189/
ces deux topics concernaient un site sous spip, ça peut concerner du joomla également. il est inutile de porter l'affaire devant les tribunaux à chaque fois, tu y passerais ta vie, bloque l'accès et passe à autre chose.
P.S. il ne s'agit pas d'un piratage à chaque fois que tu as un .404
orvinfait a dit:
c'est ce que je pensais moi aussi il y a quelque temps (http://www.meme-anna.com/spip.php?article23), mais désolé de te décevoir, tout le monde s'en fout, et puis, tu te rendras compte vite que tu auras vite autre chose à penser.
Le type de problème auquel tu fais référence est souvent le fait d'un PC vérolé, donc son 'auteur' ne s'en rend même pas compte.
WRInaute occasionnel
Si tu remarque souvent une tentative de scan sur la même page, tu peux créér la page en question :
/components/com_cpg/cpg.php?mosConfig_absolute_path
Et récuperer l'ip du robot, et lui interdire l'accès à ton site.
C'est pas toujours possible, car les répertoires et fichiers auquels ils tentent d'accèder changent souvent (ils ont pas la même manière de travailler :mrgreen
, et qu'il est pas toujours possible de simplement "bloquer" leur ip (ce serrait trop facile), mais ça peut toujours te permettre de bloquer l'internaute du dimanche qui tente manuellement des trucs avec son ip fixe.
Ou alors tu peux définir une page vers laquel les 404 redirige, et au bout d'un certain nombre d'erreurs 404 dans un intervalle trop court, tu bloque tout.
une centaine de 404 en une minute par la même connexion, c'est pas normal, et c'est à bloquer temporairement.
/components/com_cpg/cpg.php?mosConfig_absolute_path
Et récuperer l'ip du robot, et lui interdire l'accès à ton site.
C'est pas toujours possible, car les répertoires et fichiers auquels ils tentent d'accèder changent souvent (ils ont pas la même manière de travailler :mrgreen
, et qu'il est pas toujours possible de simplement "bloquer" leur ip (ce serrait trop facile), mais ça peut toujours te permettre de bloquer l'internaute du dimanche qui tente manuellement des trucs avec son ip fixe.Ou alors tu peux définir une page vers laquel les 404 redirige, et au bout d'un certain nombre d'erreurs 404 dans un intervalle trop court, tu bloque tout.
une centaine de 404 en une minute par la même connexion, c'est pas normal, et c'est à bloquer temporairement.
ManiaGames a dit:
Dans le cas qui me concernait, avec le site sous spip, cela multipliait le traffic total par 5, rien que pour des redirections, voir les threads WRI ci dessus. T'imagines si j'avais du écrire à tous les FAI concernés ?? Je serais encore à coller les timbres.
WRInaute occasionnel
tofm2 a dit:
Je ne parle pas d'écrire, mais juste de bloquer les IPs concernées quand cela est possible. Le faire toi même, car c'est pas la peine d'attendre que le FAI le fasse.
WRInaute impliqué
Ceci dit, une centaine de pages vus en une minute (même des pages valides), ce n'est pas beaucoup plus normal.ManiaGames a dit:
Euh juste comme ça, PHP ne PEUT PAS lire les mots de passe du systeme (/etc/shadow), puisque seul l'utilisateur "root" peut le faire
Donc à moins de faire tourner PHP sous root, je vois pas trop comment il peut faire.
J'ai fait une petite recherche sur google et en fait le code en question (enfin, l'occurence la plus frequente) ne fait que rajouter aux fichiers php & html existants un iframe vers un site argentin ! Bon j'ai aussi trouvé du c99shell (qui est plus un gestionnaire de fichiers php qu'autre chose d'ailleurs) et d'autres bouts de code plus ou moins complets.
Donc rien de bien mechant en somme, surtout si son hebergeur connait son metier et a un PHP correctement configuré, ce qui evite de voir tous les clients d'un serveur impactés par la faille d'une seule appli.
Avant de crier au loup faudrait se document un minimum, sinon ça fait comme dans la fable ...
MADdanny
Donc à moins de faire tourner PHP sous root, je vois pas trop comment il peut faire.
J'ai fait une petite recherche sur google et en fait le code en question (enfin, l'occurence la plus frequente) ne fait que rajouter aux fichiers php & html existants un iframe vers un site argentin ! Bon j'ai aussi trouvé du c99shell (qui est plus un gestionnaire de fichiers php qu'autre chose d'ailleurs
) et d'autres bouts de code plus ou moins complets.Donc rien de bien mechant en somme, surtout si son hebergeur connait son metier et a un PHP correctement configuré, ce qui evite de voir tous les clients d'un serveur impactés par la faille d'une seule appli.
Avant de crier au loup faudrait se document un minimum, sinon ça fait comme dans la fable ...
MADdanny
WRInaute accro
Du coté obscure de la force... Pssshhh.. Pssshhh... Luke je suis ton PR... Psshhh...
c'est ce qu'on trouvait aussi sur certains sites qui se sont retrouvés avec des spywares les iframemaddanny a dit:
Sinon, selon la typologie des url, un htaccess contenant
Code:
RewriteRule (_vti_bin|blogs|http|shell|scanner|open|command|MSOffice|sav|cmd\.|phpa|rpc|portal|drupal|blog|wordpress|phpgroupware|awstats|web|chat|mysql|db\/|horde|mail/|/main|/read|cacti) - [NC,F,L]
Discussions similaires
