Re: Nessus scripts and Moore's Law

On Fri, Nov 12, 2004 at 12:02:48PM +0100, Michel Arboi wrote:
> Optimization is always a matter of compromise: CPU vs RAM, CPU vs
> network. 
> Generic tests eat more resources on the network & target machines and
> less on the scanner. Currently (and for a loooong time ahead), local
> CPU is more abundant and cheaper, I admit.

Generic tests don't produce a *helpful* output. If the output if fuzzy,
most users will think it's a false positive  - trust me on that.

> > - 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
> > can't. If you run Nessus without safe checks _today_, most of the
> > false positives come from such plugins ;
> 
> IIRC, we have made many improvements on them.

Sure, but they are still less reliable than other tests. And their
output is less useful than other tests in the sense that they don't
point to an exact flaw description, nor to a solution. 

> > - They are destructive. Crashing the remote service is not an option
> 
> It depends on what are your "security objectives". If reliability is
[...]
> As I said in my previous message, I'm quite sure that most users don't
> need 99.99% reliability.

Crashing a service is _NOT_ acceptable, except if your objective really
is to throw everything you can to the remote host. In other words, while
generic tests are useful, they can not replace dedicated and less
intrusive tests. Ergo, they do not solve the initial problem you
attempted to raise on the list.

> > - 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.
> 
> Maybe we might enhance the message and give more data so that the user
> can investigate?

You have a "single host" vision. The truth is that there are big
networks out there being scanned by Nessus, and Nessus already reports
hundreds of thousands of _known_ flaws in them. Who wants / can
investigate unknown/possible flaws when dealing with big networks ?

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

The slowest ones should be in the "through tests" section. John Lampe
wrote several fuzzers that I want to include in the future, but they are
way to slow for a generic scan.

> >> 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.
> 
> *If* the VM really speeds things up. Does anybody know how I could

Not "speed things up". Lower the CPU usage.

> > This is also important. I introduced a very crude HTTP caching mecanism
> > a while ago (now disabled)
> 
> IIRC, it did not really improved speed and ate much CPU and RAM :-]
> However, we fixed a terrible memory leak since (I plead guilty for
> this horror)

The problem of the original HTTP caching mecanism is that it would grow
the KB, which would in turn make forking way too slow on Linux/FreeBSD
systems (where the fork() time is proportional to the process size).

> > and I want to re-do it (mostly, to only cache static pages)
> 
> Maybe in C?

Of course, and in a separate process.


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