[Openvas-devel] OpenVAS plugins standardization

Vlatko Kosturjak kost at linux.hr
Mon Sep 1 09:37:12 CEST 2008


> IMHO information like that a tool was not found to execute
> should *always* be reported. Because the has requested to execute
> the respective NVT, he *must* be informed what is the result
> of the execution. I really hate the way Nessus handles it: don't report
> anything if nothing is found. I am confident that many many people
> are scanning networks and think all is OK allthough the
> server side logs nessusd  would show that many plugins
> failed to execute.

That means if you have e.g. 25000 plugins selected and each of them
should report it's status(failed/success) and why it failed?
That would be report of at least 12500 pages!

> I guess the daemon will just through an error in the log file as long
> as the new NASL methods are not implemented.
> Once the server is extended, we can report it to the client
> and once this one has extended the information will be available to the
> user.
> Hm, as I think about it, we can also simply introduce a better
> and consistent naming. How about
> report_hole() (perhaps better report_vulnerability)
> report_warning()
> report_note()
> report_debug()
> report_log()
> The old functions can stay for backward compatibility for a while.
> Just sketched my ideas. What do you think?

Sounds good. But when we're discussing this report verbosity option.
It's important to note and discuss Report paranoia option also as it is
tightly connected and should be discussed together (because to clearly
differ those two options).

Kost



More information about the Openvas-devel mailing list