Re: Nessus scripts and Moore's Law

Michel,

On Thu, Nov 11, 2004 at 06:06:29PM +0100, Michel Arboi wrote:
> 1. Cut down the number of banner matching plugins and replace them
> with generic tests. Thus, we might even find unpublished flaws.

This is actually a _slower_ alternative to the current banner matching
plugins we have today - it's _way_ faster to write one plugin which
connects to port N on the remote host, store the result in the KB, and
run hundreds (if not thousands) of egrep() on it, than it is to test all
the permutations of a given protocol like a generic plugin would.

There are tons of drawbacks to generic plugins :

- They are very slow and most of the time unreliable. So you send
"USER XXXX[...]XXXX" to a remote FTP server, and it cuts the connection
down. How do you distinguish a segfault from an exit() ? You simply
can't. If you run Nessus without safe checks _today_, most of the false
positives come from such plugins ;

- They are destructive. Crashing the remote service is not an option

- They are too fuzzy. When most users read that the remote server
_might_ be vulnerable to a buffer overflow, without any reference to
any BID or CVE, they just assume it's a false positive. And even if your
plugins had references to hundreds of BIDs, don't expect anyone to click
on every of them to determine wether their product is listed or not.

In short, generic plugins are useful BUT unreliable, and I want to move
most of them in the "thorough checks" section.


 
> 2. Rewrite the NASL interpretor using a VM. According to gforth /
> vmgen developers, such an interpretor might be 10 to 100 times quicker

That would be good. The issue today is not really speed, but CPU usage.
If you are testing 3 hosts in parallel, you don't care about such a VM.
However, if you intend to scan your class B, you want a high level of
optimization, which can be achieved if each process has a very little
CPU footprint. 

So this one would not be a waste of time.

> 3. Try other "simple" NASL optimizations. I have implemented a cache
[...]

I don't think they will attenuate your current fears. 


> 4. Make sure that all plugins do not perform redundant operations. 

This is also important. I introduced a very crude HTTP caching mecanism
a while ago (now disabled) and I want to re-do it (mostly, to only cache static
pages), this would speed up the checks a lot. What slows down the Nessus
scans today are all the dumb cross-site-scriptings/SQL injections in
nearly unknown PHP scripts, as it's tough to optimize using the KB and
each script has to look into a lot of places. However, a lot of the
"banner grabbing" plugins already use this mecanism, and Nessus 2.2
paves the way for an ever increased usage of the KB since the cost of
accessing it is now nearly null.


				-- Renaud
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel