Re: Nessus scripts and Moore's Law

Michel Arboi <[email protected]> Thu, 11 Nov 2004 22:53:47 +0100
Newsgroups gmane.comp.security.nessus.devel
Message-ID <[email protected]>
On Thu Nov 11 2004 at 21:59, George Theall wrote:

> What are people's feelings about combining related plugins, especially
> those that rely on simple version strings? For example, I count 9
> plugins named apache_2_0_*.nasl, most of which do nothing more than
> check the banner.

The philosophy of Nessus is to have one plugin for each flaw (whenever
possible). As the different Apache versions are vulnerable to
different flaws, it makes sense to have different scripts. 
There might be one rare case when we can (and should) remove old
plugins. If Gizmo 1.23 is vulnerable to a web directory traversal for
example, which is fixed in 1.24, and if sometimes later, somebody
finds a new way to exploit the directory traversal, which is fixed in
1.45, than we don't need two plugins.
But I'm afraid that this situation is rare :-\

Over optimizing might be dangerous too: if the web server banner is
not in the KB because of a network glitch, the plugin should try to
grab it again (that's what get_http_banner does)
Maybe we should spend a little more time on service identification and
banner grabbing to be able to run at full speed once the KB is filled
with information. As I had some incomplete reports sometimes, I wrote 
doublecheck_std_services.nasl which tries hard to identify common
services: I'd rather lose some time during the first phase than run
the whole scan again.
The service identification system is split in several scripts 1) to
make it more flexible (as find_service is in C), and 2) to make it
more reliable (let's hope!)

> It seems to me that they could be replaced by a single plugin that
> checks the banner against the latest version and is updated as new
> versions and vulnerabilities are announced.

We don't want to just read: "upgrade to the latest versions". We need
to know if the flaws are dangerous or not, considering the
environment. 

Another point before we try to enhance anything: profiling Nessus is
not easy. Some time ago, I wrote a quick & dirty patch which printed
at the end of each plugin the used resources (real time, CPU
time...). It is still in exec.c (but commented out of course). We may
enable it and look at the results...

-- 
[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