Re: Nessus scripts and Moore's Law

On Fri Nov 12 2004 at 00:43, Renaud Deraison wrote:

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

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.

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

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

It depends on what are your "security objectives". If reliability is
your priority, you certainly don't want to crash a service to verify
if it is vulnerable to a known DoS that might be exploited one day.
If confidentiality is your priority, then you don't care. That's the
case with many military systems that protect secret data: better dead
than caught.
I was told that a French defence "network cutter" was vulnerable to
the old ping o' death. I'm not sure that this is not a legend spread
by competitors, but anyway, the goal of the devise is to prevent
information leak, at *any* price. 

As I said in my previous message, I'm quite sure that most users don't
need 99.99% reliability.

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

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

>> 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
benchmark it without full rewriting the interpretor? I don't want to
code during a month to discover that I save 3% of CPU time!

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

I am more looking for enhancement than "fearing" anything. As I said,
the "sluggish Nessus" scenario is good for scifi.
<troll>
This is different with some other scanners that have sacrificed
completeness or reliability to get a reasonable speed.
</troll>


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

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

Maybe in C?

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