Re: families

Robert Rich <[email protected]> writes:

> I think ultimately a flat one-to-one grouping mechanism for plugins is
> going to be prone to the same ambiguities and overlap that you're
> seeing now.

Keywords may be an answer, but we should define precisely what the
question is :)

> If the changes would be significant, would it be possible to introduce
> Erik's idea as something new and maintain the existing families as a
> legacy holdover for backwards compatibility?

Is this really necessary?

> I think the answer to this question will make the development of a new
> list of families much easier.  However, because of the technical
> limitations of families, you can really only have one purpose.  Any
> more than that, and it becomes complicated.  What if you have a plugin
> that uses default account credentials to execute an HTTP query against
> a sample application to enumerate EJBs in a remote container through
> JNDI, possibly killing it in the process?  Obviously a rediculous
> example, but this plugin works over HTTP, exploits default passwords,
> uses a sample application, tests JNDI security and ultimately just
> gathers information in a manner that could potentially kill the
> service(s).

Well, I'd say that it is mainly an attack against a Java based HTTP
service, so maybe a "HTTP - Java" family?

> - Plugins that work over HTTP. (PROTO == (HTTP || HTTPS))
> - Plugins that attack IIS. (APP == ".*IIS.*")
> - Plugins that address a SANS Top 20 issue (SANS20 == TRUE )
> - Plugins that could kill the service. ( DANGEROUS == TRUE )
> - Plugins that are designed to kill the service. ( DOS == TRUE )
> - Plugins that are really only useful if you have credentials. (
> REQCREDS == TRUE )
> - Plugins that have a CVE associated with them ( #CVEID > 0 )
> - Plugins that check for HIGH severity issues ( SEVERITY == HIGH )
> - Plugins that are stable (DEVSTATUS == STABLE)

This would be very flexible, but would need much rework in the GUI,
wouldn't it?

> This whole generic properties thing could be bunk, and is probably a
> lot of effort for minimal return, but i think if we're considering
> going back through and touching each of the nearly 2100 plugins that
> are out there now, it'd be good to get the most bang for the buck.

Good point.

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