Hello Thomas, > -----Original Message----- > From: openvas-devel-boun...@wald.intevation.org > [mailto:openvas-devel-boun...@wald.intevation.org] On Behalf > Of Thomas Reinke > Sent: Thursday, February 25, 2010 8:31 PM > To: openvas-devel@wald.intevation.org > Subject: Re: [Openvas-devel] CR #43 - NMAP based service detection > > Hi, > > I'm not sure I understand the actual rationale for removing > the existing find_service.c plugin.
The idea is to make use of tools or libraries that are designed for the purpose, as also discussed during DevCon. Similar exercises were planned for SSH and SMB libraries. > > a) It's a non-trivial excercise, so there needs to be actual > gains seen out of doing it (which I don't see). I agree, the exercise is non-trivial. As of now find_service.c is not being updated and it detects only about 90 services whereas NMAP service db is being maintained well and it has huge number of probes. Why have a module that is not going to be maintained? So, a careful review exercise has to be carried out to see if NMAP really is a full replacement, if not, wherever find_service.c does better, we either retain or see if the required changes can be incorporated to NMAP. > b) We already get dynamic update of plugin capability if we want > it if we include the nmap database in the feed (which I agree > _should_ be done (but beware of ensuring that the config files > we distribute in the feed match the version of nmap that is > out there and might be installed on the scanning system). I agree. > c) find_service.c almost _never_ gets updated anyways, so we > don't need to change it, only complement it (the capability > which already exists with item b) above Yes, that's the idea. But, the difference is to make NMAP the default service detection and use find_service wherever it does better than NMAP, if at all it does. > c) Reliability of the tool chain (in a minor way) moves out of > our control into the nmap arena for a critical component of > any scan (break service detection, the whole scan is broken). > I can see situations easily developing where distro X has > a version of nmap incompatible with the nmap db we distribute. > Thought the other way around :) we get better service detection. I believe, NMAP should ideally take over complete host/port scanning and service detection. I am not sure if the service probes are bound to a particular version of NMAP. I thought they are loosely-coupled. I'll evaluate this. > I am a firm believer of "if it ain't broke, don't fix it". > Given that find_service.c essentially is not updated and we > have the ability to complement it with nmap, I do not see an > upside to removing find_service.c and changing it to an > external dependency using code that may not be in sync with > the version of OpenVAS installed. > > Am I missing something here? > > Thomas Thanks, Chandra. _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
