DÉTECTEUR DE VULNERABILITY SCANNER

Arto_8000 Messages postés 1044 Date d'inscription lundi 7 mars 2005 Statut Membre Dernière intervention 13 juillet 2010 - 19 nov. 2009 à 18:37
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 - 23 nov. 2009 à 13:34
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/50873-detecteur-de-vulnerability-scanner

TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
23 nov. 2009 à 13:34
Bonjour,

Vu que la question de la protection (et non de la détection) revient régulièrement dans les commentaires, je me permet de laisser quelques liens vers des articles traitant du sujet :
(en) http://johannburkard.de/blog/www/spam/introduction-to-blocking-spambots-and-bad-bots.html
(en) http://johannburkard.de/blog/www/spam/updated-spam-bot-and-bad-bot-list.html
(en) http://johannburkard.de/blog/www/spam/effective-spam-bot-blocking.html
(fr) http://tycho.dyn-o-saur.com/index.php?post/2009/10/18/%C3%89viter-les-vulnerability-scanners-sur-un-serveur-web

Bien entendu, utiliser cette source permet d'aider à évaluer les meilleurs moyens à mettre en place mais égalent à vérifier leur efficacité.
LeFauve42 Messages postés 239 Date d'inscription vendredi 20 octobre 2006 Statut Membre Dernière intervention 20 avril 2009
23 nov. 2009 à 11:45
Salut,

Se proteger de ce genre de desagrements est toujours galere, et il est dur d'avoir une solution 100% efficace, mais dans tous les cas il est toujours instructif de jeter un oeil a ce genre de source.

Donc, merci de partager ton experience avec nous !

Sinon, j'ai decouvert ce matin une solution qui a l'air assez complete, bien que recente : CrawlProtect (http://www.crawlprotect.com/fr/)

C'est principalement base sur du .htaccess (et je ne suis donc pas sur que ca filtre les tentatives d'injection par methode POST).

J'aime aussi moyen le fait de ne pas pouvoir changer le path d'installation (encore qu'on peut certainement, en editant les .htaccess, mais je n'ai pas eu le temps de regarder en details) mais je serais curieux de savoir ce que vous pensez de cette approche.

Eric
35201 Messages postés 1 Date d'inscription samedi 2 décembre 2000 Statut Membre Dernière intervention 23 novembre 2009
23 nov. 2009 à 11:33
Bien utile dans certains cas. Merci
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
20 nov. 2009 à 09:19
"Je met sur un forum très visité un image dans ma signature qui a pour lien http://tonsite.com/pathbanni/include/admin.php et en quelques jours tes logs font se faire spammer de IP qui ne sont pas des bots."
Il en est de même pour le access_log et le error_log, tu devrais aller donner des cours à des gros noobs de la fondation Apache qui visiblement n'ont pas eu vent de ta trouvaille révolutionnaire. D'accord je n'ai pas mis de gzipage automatique du fichier de log mais quand même.

"Encore pire, je roule ton script sur une page qui a comme chemin /shop.php et ton script va faire un die dessus juste parce que le path contient "shop"."
Encore une preuve que tu n'as pas lu et compris ce que j'ai écrit. C'est fait pour être placé sur la page servie en cas d'erreur 404, si la page est atteinte le script ne sera pas appelé.

"tu ne les empêche d'aucune façon à scanner ton site et tout ce que ça fait"
"elle n'empêche en rien l'accès à des applis ayant des failles de sécurité"
Je n'ai jamais eu l'intention de le faire.

"c'est te remplir un log qui te sert à rien. Tu comptes faire quoi avec les logs ?"
Tout le monde n'a pas la même vision des choses, ce n'est pas parce que toi tu ne vois aucune utilité que ça n'en a aucune. Le but ici est de fournir un log qui permette d'évaluer les besoin d'un serveur afin d'essayer de luter contre ces bots qui pourrissent le web afin de mettre en place les solutions adaptée. D'un point de vue personnel je ne souhaite pas prendre des solutions de protection à l'aveuglette et ici j'ai un moyen de simplifier la visualisation des robots afin de ne pas perdre de temps à passer en revue error_log et access_log.

"Si je peux me permettre, sans méchanceté aucune, tu as une certaine tendance à cela toi aussi :)"
J'avoue, mais là sur le coup je n'ai pas apprécié ce que j'ai perçu comme une agression gratuite sans fondement contre moi et me suis un peu emporté.

"elle consomme des ressources pour des logs improbables."
La consommation de ressource de ce script est minime, surtout si l'on utilise un serveur dédié. Comme dit ce script à la base je l'ai fait pour moi afin de répondre à mes besoins, et contrairement à la plupart des personnes je n'utilise aucun hébergement mutualisé ou tout autre chose de ce genre. Pour moi, que ce soit pour l'entreprise dans laquelle je suis actuellement ou pour mon cas personnel, le contrôle total et l'accès physique à la machine sont des éléments très importants.

"Tant qu'à faire je préfère encore utiliser un htaccess basé sur une liste d'adresses IP / domaines reconnus et mis à jour très fréquemment. Au moins on se préserve des risques."
Pour ma part je préfère utiliser les virtualhost pour balancer un RedirectPermanent sur toutes les requêtes n'utilisant pas les noms de domaines que j'ai prévu, et donc les bots qui scannent des plages d'adresses et ne connaissent que l'IP du serveur pour y accéder.

"tu as bien de la chance, car moi j'en rencontre un paquet qui n'ont pas de user-agent."
C'est fort possible, mais peut-être confond-tu avec ce qui semble être un bug d'IE6 ? J'ai constaté que certains IE (qui ne sont pas des bots) font régulièrement des requêtes à l'insue de l'utilisateur sur certains éléments visiblement mis en cache et que, dans le cas d'IE6, lors de ces requêtes aucun user-agent n'est transmis. Ceci dit je ne connais pas ton cas et ça très bien ne pas être ça, je ne fait ici qu'une supposition.

"Pour le code lui même, forcément, je n'ai pas grand chose à dire (mais il y en a quand même quelques unes :o))"
Si tu as des remarques n'hésites pas, il est toujours préférable de montrer les erreurs des autres (les miennes dans le cas présent) afin de faire progresser dans le bon sens.

"Disont que j'ai une tendance (peut-être trop) forte à critiquer les solutions sécurités qui ne fonctionnent pas vraiment. Je m'en excuse."
Je n'ai jamais prétendu avoir fait une solution de sécurisation, c'est une solution permettant l'évaluation des risques.

"J'ai souligné qu'une des principales problématiques des bots et scanners étaient la fréquence souvent élevées des requêtes ce qui bouffent de la bandwidth et du processeur pour les autres connexions et qu'une protection contre ceux-ci devrait avant tout intégrer ce genre de protection."
On est bien d'accord sur les troubles causés par ces bots cependant, pour être d'une efficacité optimale, ta solution doit s'adapter au cas de ton serveur.
Arto_8000 Messages postés 1044 Date d'inscription lundi 7 mars 2005 Statut Membre Dernière intervention 13 juillet 2010 7
20 nov. 2009 à 02:31
Disont que j'ai une tendance (peut-être trop) forte à critiquer les solutions sécurités qui ne fonctionnent pas vraiment. Je m'en excuse.

Petite remarque sur la citation de "tu devrais t'attarder surtout sur la fréquence des requêtes". Tu aurais du citer ceci au lieu "tu devrais t'attarder surtout sur la fréquence des requêtes qui sont souvent presque du spam (et c'est surtout ça qui peut être problématique avec les bot et les scanners)." J'ai souligné qu'une des principales problématiques des bots et scanners étaient la fréquence souvent élevées des requêtes ce qui bouffent de la bandwidth et du processeur pour les autres connexions et qu'une protection contre ceux-ci devrait avant tout intégrer ce genre de protection. Ça déroge un peu du but de la source, mais je tenais à mentionner cela.
kohntark Messages postés 3705 Date d'inscription lundi 5 juillet 2004 Statut Membre Dernière intervention 27 avril 2012 30
19 nov. 2009 à 23:42
Ralala ça flingue ici !!

[mode coup de gueule]
J'en profites pour donner mon avis sur la partie "codes" de CS :
J'en ai marre de voir des sources descendues systématiquement. C'est tout de même hallucinant qu'il ait toujours des remarques du style "ça sert à rien", "ton code est nul", j'en passe et des meilleures ... Certes certaines sources le méritent, mais ça reste rare.
En tous cas ça ne motive vraiment pas les gens à partager.
Moi même je m'y refuse "de peur" de ces commentaires stupides postés par des soit disant "experts" qui pour nombre d'entre eux ne valent pas grand chose lorsque l'on gratte un peu. Pour les autres ce n'est pas parce que l'on est "balèze" que l'on peut se permettre certaines impolitesses.
Je changerai peut être d'avis en me décidant à poster, et je me ferai un plaisir de descendre ces blaireaux.
coup de gueule

Je n'ai fait que parcourir brièvement le code, mais j'approfondirai lorsque j'aurai le temps.
@Arto :
Je n'aime pas trop ton "Ta méthode de détection est vraiment inutile" qui se rapproche de ce que j'évoquais avant.
Cela étant je suis d'accord avec toi sur :
- le fait que ce soir un peu juste en terme de détection pour être réellement efficace.
- le fait que les filtres puissent bloquer des utilisateurs légitimes

Il y a beaucoup de choses à dire, je ne ferai que rebondir sur ce qui a déjà été énoncé :
"tu devrais t'attarder surtout sur la fréquence des requêtes"
La plupart des bots ne font que passer en testant, comme le dit TychoBrahe, l'existence de certains dossiers / fichiers, ils ne s'attardent pas, contrairement à des attaques brute force. Tester la fréquence est à mon avis bien moins efficace que la présente class et le risque d'impacter des utilisateurs légitimes est grand.

"merci de ne pas me prendre pour le premier crétin venu."
Si je peux me permettre, sans méchanceté aucune, tu as une certaine tendance à cela toi aussi :)

"un seul n'a pas un useragent à la con"
tu as bien de la chance, car moi j'en rencontre un paquet qui n'ont pas de user-agent.

"Donc contrairement à totu ce que tu dit, non ma méthode de détection n'est pas inefficace"
Au final je pense qu'elle l'est car elle n'empêche en rien l'accès à des applis ayant des failles de sécurité et elle consomme des ressources pour des logs improbables. Tant qu'à faire je préfère encore utiliser un htaccess basé sur une liste d'adresses IP / domaines reconnus et mis à jour très fréquemment. Au moins on se préserve des risques.
Rien n'interdit dans ce cas de faire un script qui parse les logs du serveur afin d'en retirer les bizarreries et de les ajouter.

Pour le code lui même, forcément, je n'ai pas grand chose à dire (mais il y en a quand même quelques unes :o))

Cordialement,

Kohntark-
Arto_8000 Messages postés 1044 Date d'inscription lundi 7 mars 2005 Statut Membre Dernière intervention 13 juillet 2010 7
19 nov. 2009 à 23:35
La détection par "keywork" dans le path est aussi assez douteux comme efficacité et peut même se retourner contre toi par un hacker habile qui veut vraiment te faire chier.

Voici pourquoi :

Je met sur un forum très visité un image dans ma signature qui a pour lien http://tonsite.com/pathbanni/include/admin.php et en quelques jours tes logs font se faire spammer de IP qui ne sont pas des bots.

Aussi les keyworks sont trop générique et moindrement que ton site en utilise dans l'URL et qu'un lien est brisé du genre : http://tonsite.com/shop/images/imageInexistante.gif ton script va aussi rajouter un entré qui est complètement inutile. Encore pire, je roule ton script sur une page qui a comme chemin /shop.php et ton script va faire un die dessus juste parce que le path contient "shop".

Pour le concept, je persiste quand je dis que ça n'a aucune efficacité et utilité, car tu ne les empêche d'aucune façon à scanner ton site et tout ce que ça fait, c'est te remplir un log qui te sert à rien. Tu comptes faire quoi avec les logs ? Une fois qu'ils sont passés et qu'ils ont testé tous ce qu'ils voulaient, il s'en foute complètement de tout ce que tu peux faire après. Ils sont venus, ils ont faits ce qu'ils voulaient et ils sont partis.
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
19 nov. 2009 à 19:06
Ce qui est inutile est ton commentaire bourré de bêtises :
1. La détection se base en premier lieux sur le contenu de l'url, l'analyse du useragent n'est là que pour rattraper les éventuels cas oubliés si possible.
2. Je sais pertinemment qu'un useragent n'est pas fiable, merci de ne pas me prendre pour le premier crétin venu. Le seul truc que tu ignore c'est que la très grande majorité des vulnerability scanners ont un useragent qui permet de les différencier d'un navigateur ordinaire, flemmardise oblige. Et là je parle par expérience, j'ai en charge des serveurs qui s'en prennent plusieurs par jour, habituellement je m'en rend compte quand je consulte (très régulièrement) les log d'erreur du httpd et constate une flopée de 404. Et là je t'affirme que dans les bots dont je constate le passage de cette manière un seul n'a pas un useragent à la con tel que Morfeus Fucking Scanner, Morfeus Strikes Again, Toata dragostea mea pentru etc, et il s'agit de celui qui se fait passer pour IE6 sur un windows 98.

Donc contrairement à totu ce que tu dit, non ma méthode de détection n'est pas inefficace.
Arto_8000 Messages postés 1044 Date d'inscription lundi 7 mars 2005 Statut Membre Dernière intervention 13 juillet 2010 7
19 nov. 2009 à 18:37
Ta méthode de détection est vraiment inutile, parce que changer le user-agent des requêtes n'est pas pas vraiment compliqué et la plupart des bots qui veulent passer anonymes vont tous simplement utiliser un user-agent d'un navigateur courant comme Firefox ou Internet Explorer. Aussi, tes filtres peuvent aussi bloquer des personnes qui ne sont pas des robots, s'ils utilisent des navigateurs exotiques ou avec des user-agent particuliers.

Si tu veux vraiment t'attaquer au bot, tu devrais t'attarder surtout sur la fréquence des requêtes qui sont souvent presque du spam (et c'est surtout ça qui peut être problématique avec les bot et les scanners).
Rejoignez-nous