Re: families

"Yeomans, Andrew" <[email protected]> writes:

> a) Enabling or disabling a whole group of tests because of potential side
> effects.

Not the role of families, IMHO.

> I'm really looking for a finer classification than "dangerous plugins", as
> the "big switch" isn't always good enough. For example, "will cause DoS on
> vulnerable systems", "might kill service if running on early xyz operating
> system", "might send output to vulnerable printers" are options that I might
> select or deselect depending on purpose of tests. 

We already have "safe_checks", and I sggest that we add another level
that will launch dangerous attacks but not DoS or floods.

> b) Disabling tests not relevant to the type of system

This is supposed to be the role of "optimize".

> The main objective is to get more accurate reports, e.g. don't report Tomcat
> web problems on an IIS box.

This is a _false positive_ and the plugin should be fixed.
Currently, we do not use the result of www_fingerprinting_hmap as we
consider it as experimental, but this may change in the near future.

> The second objective is to speed up the testing, by not applying router
> tests to windows systems, etc.

Why not? A windows system may act as a router.

> c) Making the plugin selection options manageable
> Fundamentally having sufficient number of categories - not so few categories
> that the plugin lists are too long, not so many that they only contain a
> small number of items (like current NIS category). I seem to remember
> usability studies for menu systems (remember Prestel/Viewdata?) concluded
> that around 10 items at each hierarchy level was about right - maybe p to 20
> with modern screen sizes.

That's the main problem for me: when I want to disable a specific
script, it is easier to remove it from the directory than play with
the GUI.

> d) Selecting vulnerability severity
> I'd sometimes like to filter out the inconsequential informational items.
> Things like "traceroute info", "digital cert info". So an "Info only"
> category would be nice. 

However, some plugins depends upon such information.
Maybe you should post-process your report?

> e) Selecting by service
> On occasion I'd like to select by the TCP service. So far, I've only needed
> this when trying to find which plugins test which services - in other words
> I don't need to select "all HTTP" for an actual test

A month ago, I needed to just fire the Windows tests on a class B, to
speed the test up, and I realized that the current family structure
was not great. 
I only scanned 135-139+445 but it was not as quick as I'd hope. And
probably more intrusive.

-- 
[email protected]	http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel