Re: Nessus scripts and Moore's Law

On Thu, 11 Nov 2004, Michel Arboi wrote:

> Last year, we had less than 2000 Nessus scripts if I remember well. 
> Today we have 5570. Although some of them are related to a brand new
> feature (local tests) and are automatically generated, it seems that
> the number of "classical" plugins increase quicker than Moore's Law
> (double every 18 months).

BTW: The sheer number of plugins in one directory makes CVSweb
(as well as grep ... *.nasl) unusable.

> 3. Try other "simple" NASL optimizations. I have implemented a cache
> for include files (they are only parsed once for all plugins) in the
> CVS head branch. [...]

I got a feeling there was a plan to preparse all scripts and save them in
a parsed form?


On Thu, 11 Nov 2004, Michel Arboi wrote:

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

This is silly. Rather than ending with a completely and obviously bogus
report (no information about the service), you end with a partially bogus
report (some plugins got the banner, some plugin did not). The latter is
worse IMHO.


On Fri, 12 Nov 2004, Renaud Deraison wrote:

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

MS Windows kill TCP connection with RST when the task dies (GPF etc.).

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

As far as I can tell, Nessus has always been more memory (*) and network
bandwith hungry than CPU hungry. I had to reduce parallelism in order to
prevent thrashing and network congestion on several occasions but I don't
recall I have ever had to reduce it because CPU was overloaded. YMMV.

(*) Memory leaks might have played some role here...


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."


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