Mailing List Archive: TODO List

TODO List

Sep 5, 2002, 12:26 AM

Post #1 of 5 (657 views)

Michel Arboi wrote:

>Following the discussions on the risk factor and the translation
>problems, maybe we should launch a TODO list for NASL enhancements in
>the next major version?
>Renaud?
>
I continued thinking about the plugin families. IMHO it is inevitable to
introduce nested structures as the number of plugins increases
constantly. How about the following simple solution:

- All family information are removed from the NASL script
(this can be done automatically within one hour)
- The family structure is expressed by the directory structure in
the plugin directory, i.e. for each family there is a separate
subdirectory.
- The nessus-update-plugin script and the nessus demon must be
adapted such that they are able to traverse all directories recursively.
(This should also be a minor problem that can be fixed within a day
or two, right?).

What do you think? We would not have to wait until the next major
version because the changes to NASL are trivial (code removal) and the
re-arrangement of the plugins could happen step by step. Nothing would
be broken in the meantime.

Regards, Michael

--
=======================================================================
Michael Schmitt Telefon: +49 651 97551-40
Institut für Telematik Telefax: +49 651 97551-12
Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de
D-54292 Trier E-Mail: mailto:schmitt@ti.fhg.de
=======================================================================

Re: TODO List [ In reply to ]

ktk at enterprise

Sep 5, 2002, 12:07 PM

Post #2 of 5 (647 views)

Permalink

On Thu, 2002-09-05 at 03:26, Michael Schmitt wrote:
> - The family structure is expressed by the directory structure in
> the plugin directory, i.e. for each family there is a separate
> subdirectory.
> What do you think?

Are we sure that that a single NASL script cannot exist in more than one
family simultaneously? Currently they do, of course. But what if one
wishes to have a single NASL script dealing with some particular
server/service, a script that tailors its behavior depending upon which
of potentially several families it has been selected in?

That is, the script might enumerate users if it exists in "General" and
has been selected, and might test for buffer overflow if it also exists
in "Gain Root Remotely" and has been selected, and so on. I suppose the
only advantage here would be code sharing between what are now several
independent scripts dealing with the same server/service. Just
musing...

Kris

Re: TODO List [ In reply to ]

MBown at safecoms

Sep 5, 2002, 3:07 PM

Post #3 of 5 (645 views)

Permalink

Only problem I can see with removing the information in the scripts is with
people who are using their own tools for reporting. Currently getting the
information about the structure of a script is simple whereas if it were
more of a file system issue it would be complicated somewhat.

Why not simply introduce a hierarchical structure in the scripts? The nasl
code may change from being:

script_family(english:"FTP");

To being something like script_family(english:"FTP->PROBLEM TYPE1->PROBLEM
TYPE 2");

Naturally a complete change over of the nasls to be an xml format would be
ideal.

Just my 2 c.

Marc

--
Marc Bown
Lead Developer
SafeComs Pty. Ltd.
Web: http://www.safecoms.com/
Email: mbown@safecoms.com
Phone: (02) 9884 9801
Fax: (02) 9884 9802
On 5/9/02 5:26 PM, "Michael Schmitt" <schmitt@TI.FhG.DE> wrote:
> Michel Arboi wrote:
>
>> Following the discussions on the risk factor and the translation
>> problems, maybe we should launch a TODO list for NASL enhancements in
>> the next major version?
>> Renaud?
>>
> I continued thinking about the plugin families. IMHO it is inevitable to
> introduce nested structures as the number of plugins increases
> constantly. How about the following simple solution:
>
> - All family information are removed from the NASL script
> (this can be done automatically within one hour)
> - The family structure is expressed by the directory structure in
> the plugin directory, i.e. for each family there is a separate
> subdirectory.
> - The nessus-update-plugin script and the nessus demon must be
> adapted such that they are able to traverse all directories recursively.
> (This should also be a minor problem that can be fixed within a day
> or two, right?).
>
> What do you think? We would not have to wait until the next major
> version because the changes to NASL are trivial (code removal) and the
> re-arrangement of the plugins could happen step by step. Nothing would
> be broken in the meantime.
>
> Regards, Michael

Re: TODO List [ In reply to ]

schmitt at TI

Sep 10, 2002, 3:35 AM

Post #4 of 5 (646 views)

Permalink

Renaud Deraison wrote:

>I'm not too keen on that for various reasons (the "family"
>classification makes no sense anyway, I'd prefer to use keywords in the
>future, to users will be able to view things the way the prefer).
>
That's a very good idea. Let's get rid of the families at all! In the
frontend, the user may be able to define his own kind of "families"
based on keywords. But we must define a reasonable set of keywords that
are used in a uniform manner.

Michael

--
=======================================================================
Michael Schmitt Telefon: +49 651 97551-40
Institut für Telematik Telefax: +49 651 97551-12
Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de
D-54292 Trier E-Mail: mailto:schmitt@ti.fhg.de
=======================================================================

Re: TODO List [ In reply to ]

ktk at enterprise

Sep 10, 2002, 12:42 PM

Post #5 of 5 (641 views)

Permalink

On Tue, 2002-09-10 at 06:35, Michael Schmitt wrote:
> That's a very good idea. Let's get rid of the families at all! In the
> frontend, the user may be able to define his own kind of "families"
> based on keywords.

That's essentially what I was saying when I wrote,
> Are we sure that that a single NASL script cannot exist in more than
> one family simultaneously?

I was using "family" as a synonym for "keyword" but it amounts to the
same. Let's assume I want to test a Windoze IIS web server running in a
production (don't crash it) data center for both OS and web server
vulnerabilities. If we provide "enable" and "disable" buttons for each
type of keyword, then I could click the following:
Disable Script: [X] All, [ ] Dangerous
Enable Architecture: [X] Windows, [ ] Unix, [ ] Misc.
Disable Web Servers: [X] All, [ ] IIS, [ ] Apache, [ ] Misc.
Enable Web Servers: [ ] All, [X] IIS, [ ] Apache, [ ] Misc.
Disable Script: [ ] All, [X] Dangerous
Start Scan: [X]
This would work much better than the current setup, which spreads checks
onto multiple pages that you have to look for tediously.

Kris