RE: Nessus scripts and Moore's Law

dictionary idea won't work:
too many s's
../lib/nessus/plugins/a
../lib/nessus/plugins/b

oh, maybe we can put this in nessus-tools:

#!/bin/sh
# ngrep (nessus grep)
plugins="/usr/local/lib/nessus/plugins"

grep $1 $plugins/*.inc $plugins/[0-c]*.nasl
grep $1 $plugins/d*.nasl        # debian
grep $1 $plugins/[e-l]*.nasl    # linux
grep $1 $plugins/m*.nasl        # mandrake
grep $1 $plugins/[n-r]*.nasl
grep $1 $plugins/s[0-n]*.nasl
grep $1 $plugins/so*.nasl       # solaris
grep $1 $plugins/s[p-z]*.nasl
grep $1 $plugins/[t-z]*.nasl

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Michel Arboi
Sent: Friday, November 12, 2004 6:50 AM
To: Pavel Kankovsky
Cc: [email protected]
Subject: Re: [Nessus-devel] Nessus scripts and Moore's Law


On Fri Nov 12 2004 at 12:25, Pavel Kankovsky wrote:

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

I guess that we could create sub-directories. Somebody suggested one
directory for each family. Why not? We just have to change the install
script.

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

I've tried to save the syntax tree in a simple binary format but
loading this is not quicker than parsing the file. Bison is really
good!
Another trick: we could parse all the .nasl, and keep all the syntax
tree in memory. But this might be too expensive (in MB).

>> 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 will get information about other services, so you might miss the
untested service.
The service detection system tries to warn you anyway:
e.g. find_service will say "an unknown service is running on this
port, it is usually reserved for HTTP" and then find_service2 ou
doublecheck_std_services will detect a web server. You will know that
you have a problem, that you should increase the timeout or fix the
network.

> you end with a partially bogus report

The report will be "partially" bogus in both cases.

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

Excellent idea! We just have to enhance the API to get the last error
code - I guess that nessusd will get ECONNRESET, no?

> As far as I can tell, Nessus has always been more memory (*) and
network
> bandwith hungry than CPU hungry.
> (*) Memory leaks might have played some role here...

I think so.

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

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