Re: Re: Nessus scripts and Moore's Law

On Thu Nov 18 2004 at 07:02, Don Kitchen wrote:

> In regard to banner collection it seems like a good idea to collect the
> banners first, reliably

I have written a new TCP scanner that is quick and also grab
banners. It saves time in find_service.nes

> I'm in agreement that this is a bad idea to distribute collection
> into scripts.

We need a collection part to debug the scripts: it is easier with the
command line NASL. Maybe we should this kind of code so that it
behaves differently when COMMAND_LINE is set.
This kind of thing could be changed too, from:
port = get_kb_item("Services/www");
if (! port) port = 80;
into:
port get_kb_item("Services/www");
if (! port) if (COMMAND_LINE) port = 80; else exit(0);

> Further on that topic, it seems to me that the current plugins are producing
> a lot of conflicting results from scripts.

You should report them so that we can fix them.
Be sure that you are using up to date plugins before you do: the bug
might be already fixed.

> Or IIS findings on a platform another script figured out was a
> Unice.

This can happend with load balancers or port redirectors. This might
be more common than we think. So we cannot rely upon os_fingerpriting
to remove false alerts on services.

> The kb/optimization could do a better job of not running
> scripts that don't apply.

Usually, they do. Some script_require_keys instructions might be
missing, however.

> Among those scripts whose job it is to figure out
> what kind of platform is, the kb can collect results. The first script to
> submit a result (i.e. asserts platform like windows/unice or application
> like apache/iis) is presumed to be correct. Any conflicting results (i.e.
> unice+iis, iis+apache, apache+other, etc) can be dealt with before the
> "worker bee" scripts are launched.

Services fingerprinting is the answer: the experimental
www_fingerprinting_hmap (too much verbose currently) has never mixed
an Apache with an IIS, or a Compaq WM with a VNC.

> The way to deal with it could range
> from logging a security_hole of "Not sure what platform" and setting both
> kbs

The idea is interesting anyway. This could be a way to detect a
service behing a load balancer, which means that DoS plugins will be
unreliable and should not be launched, among other things.

> Fundamentally, you can't have two different services listening
> the same port of the same ip address

Yes you can, with Pound for example: this reverse proxy can redirect
different URL to different machines. I suspect that this is common on
huge web sites behing load balancers, when they have both a "static"
part (only HTML and JPG) and an "application" part (CGI...).

But unless the load balancer is seriously broken, this should not
trigger on out simple service identification plugins.

> I agree that old scripts shouldn't be removed, but one possible input into
> the optimization decision could be whether to trust version numbers. There
> are two ways to look at version numbers. If version 1.14 is vulnerable and
> 1.15 is fixed, nessus can trust that if you see 1.14 it's vulnerable
> (although frequently wrong because vendors do not see fit to alter the
> version numbers in any way to so indicate.) However, it can also trust that
> if it sees 1.15, that it's not vulnerable and there's no point in running
> the script to test a vulnerability that went away (unless it comes back in
> a later version).

This means that we should have to put version numbers in the KB, and
maybe add a new kind of optimization. Something like script_require_version
I'm afraid this is not a simple modification.

And now for something completely new!

I have played with oprofile, and I may have found a good way to save
CPU. I will not tell more until I am sure this works, because the
profiler output looks a little strange and inconsistent from one run
to another.

-- 
[email protected]	http://arboi.da.ru
NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel