On Freitag, 26. Februar 2010, Thomas Reinke wrote:
> >> 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
>
> Nmap 5.00 has 58 probes. That being said, it identifies 511 services.
> But even that count is suspect. Check how many ways http based services
> are identified with labels that are NOT "http" (3dm-http,http-proxy,
> http-proxy-ctrl,kazaa-http,ncacn_http,ntop-http,vnc-http).
one big difference I see is that Nmap has a process to moderate
service detections. Ie, people send bug reports, improvements, additions
to the Nmap team and they improve the service detection.
OpenVAS does not have such a process.
We only add new stuff as part of doing new tests.
This is even done by adding some *detect*.nasl scripts.
In fact the find_services1/2 were only modified
once in the history of OpenVAS (Kost fixed a subversion detection).
Hm so there is another aspect in the discussion, bulk dectection vs.
per-case detection ?
> >> 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.
Perhaps the distribution of nmap db files via the feed and
consideration in the nmap NASL scripts deserves a CR of its own?
The version dependencies Thomas mentioned are solveable easily
IMHO. Worst case is to fall back the current behaviour.
> >> 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.
>
> Why make nmap the default? I'll ask again - what advantage are you
> getting that we do not already have?
The question is: What should we do for service xyz for which we
have a detection method in find_services and also in nmap?
Which one should dominate?
The easy answer could be (?): we introduce a setting that
defined which detection to give higher priority.
> >> 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.
>
> How is it better? More services? No (we already have nmap included.)
> More reliable? No. Fewer mistakes? No.
There is the phaenonemon of the so-called "software rot".
I suspect the number of mistakes in find_services increases
over time without changing a single line in the code.
(For example, in known_ssl_port() there is
case 19201: /* SilkPerformer agent (secure connection) */
which I do no find in www.iana.org/assignments/port-numbers
> We've seen find_service.c
> in action for nearly a decade. It does things very well.
Do we have a measure for how well it works?
> When we did the previous CR to implement nmap probes, we _did_ do
> very careful thinking about the ramifications of removing it entirely
> in favour of nmap. We decided against it. Reasons:
>
> 1) A critical component moves out of the sphere of control of
> OpenVAS. A minor point given the collaborative nature OSS
> Will nmap avoid changing service names to avoid breaking
> scripts that depend on a service name? If they don't lock
> down the names, an updated nmap database will break things.
> E.g. Port #113 - what's the service name? Well, most
> people would say it's "auth". Run an nmap scan without
> service detection, and it will say "auth". Run it with service
> detection, it will say "ident". Port 993? "imaps" by most
> people's standards. "ssl/imap" when nmap does service detection.
>
> Any name change to any of these services will result in
> a broken dependency.
I would call this a technical problem that is solvable.
> 2) We get NO improvements by replacing find_service.c
>
> We don't get improved detection. We already have
> nmap's service detection. (Unless you are arguing
> that nmap does it better than find_service.c for the
> set of services they overlap on, in which case I will
> dispute and ask you to cite even one example where
> find_service.c gets it wrong).
My first thought is that by reviewing each single detection
we might identify issues. After all, its also a review process and
this I think of as helpful in general.
> 3) We get uncertainty on the dependency chain. Not for
> a single script that might break if nmap ceases to do
> its job or isn't installed properly. The ENTIRE scanner
> will break.
>
> a) If users don't have nmap installed, the scanner
> is broken in many cases.
> b) If users have a mismatched nmap and probe db that
> we distribute, should the formats change, the
> scanner is now broken.
>
> In addition, individual scripts that rely on service
> names given by nmap will cease to function if nmap
> changes the name of the service at any point in time.
Indeed this could cause breaking.
Questions I do not have an answer for:
How often do the Nmap people break the names?
How often did it happen e.g. for /etc/services?
How many people use OpenVAS without Nmap installed?
> 4) We replace a proven, solid, working bit of code that has
> been proven in a production environment for more than a
> decade, with something that we've never relied on before.
>
> In short, there were in our opinion 4 solid reasons to not do
> this work, and not a single reason to actually do it.
>
> I'm sorry, but no-one has provided a single reason yet why
> we should do this. If you want to say its "better", then
> please say how it is better.
>
> If we had to build from scratch, I'd support it. But as it
> stands right now, I see too many downsides with no upside
> to doing this work.
I tried to read the code of find_services.c. Its a mess.
Almost no comments. No structure. References (just numbers)
to the unavailable Nessus issue tracker.
Just lots of magic without rationale, references etc.
Apart from working since 10 years, it virtually fails any quality measure.
However, Thomas raised a very good question:
Do we have a proof of a single service detection done wrong
by find_services.c?
(this one goes out to everyone here :-)
Best
Jan
--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
