OpenVAS Change Request #16: OpenVAS-Client: Do not automatically enable new NVTsStatus: Voted +4. Implemented with SVN 1639. Released with openvas-client 2.0-beta2.
To make the behavior of OpenVAS-Client more flexible and more useful for periodic scanning with fixed NVT sets.
To make a first step towards family-based scan scenarios. In the future it should be possible to define a family (like Debian local security checks) and automatically enable all new NVTs of this family, while new NVTs from other families stay disabled.
Mail from Kenneth Ng to openvas-discuss regarding this feature.
The present version of OpenVAS-Client automatically enables new NVT; this means that NVTs received from the server which are not yet in the NVT cache will be enable and thus run when the next scan is executed.
This behavior might be useful in cases where all NVTs are enabled, but is undesirable when only a specific subset of NVTs is enabled as new NVTs will be added to the subset. A user wishing to keep scanning with only this subset enabled has to manually disable all new NVTs after connecting to the server.
As stated under Purpose, this scheme is intended to allow for family-specific settings at a later date; there are cases where new NVTs of a specific family should be enabled, but other new NVTs should not.
The present version also makes it very difficult for an user to identify new NVTs and new families. This change should also include an option that informs the user when new NVTs or families have been found when enabled.
This change will introduce a configurable setting in the client that controls whether new NVTs should be automatically enabled or not and an setting that informs the user when new NVTs or families have been found when enabled.
Design and Implementation
The configurable setting controlling this behavior will be implemented in the plugin selection section of OpenVAS-Client and will be scope-specific.
The automatic enabling of NVTs happens in nessus/context.c (context_add_plugin). This would probably a good place to check for the value of the new preference.
- 2008-12-03 Felix Wolfsteller <firstname.lastname@example.org>:
Updated status, implemented and released.
- 2008-10-14 Michael Wiegand <email@example.com>:
- 2008-10-13 Michael Wiegand <firstname.lastname@example.org>:
Updated voting result.
- 2008-10-09 Michael Wiegand <email@example.com>:
- 2008-10-08 Michael Wiegand <firstname.lastname@example.org>: