I would like to get some advice from the community about a few things regarding installing OpenVAS on a supported software level and scale the performance to scan a large network.
I want to scan a large network (~20.000 hosts). In order to do this efficiently I plan to make use of the primary/secondary construction. Please share experiences about this, does it really help with scaling? Are there some neat tweaks to improve scaling or designing the cluster?
Furthermore, I have some other questions. Debian 10 is recommended to use. Debian 10 has the following versions available:
ii libopenvas9:i386 9.0.3-1+b1 i386 remote network security auditor - shared libraries
ii openvas 9.0.3 all remote network security auditor - dummy package
ii openvas-cli 1.4.5-2 i386 Command Line Tools for OpenVAS
ii openvas-manager 7.0.3-1 i386 Manager Module of OpenVAS
ii openvas-manager-common 7.0.3-1 all architecture independent files for openvas-manager
ii openvas-scanner 5.1.3-2 i386 remote network security auditor - scanner
And when I check blogs about this installation, many people need to change system level systemd unit files to make OpenVAS listen to all IPs. Which seems quite wrong to me. Or perhaps the Debian maintainer is making poor packaging decisions of course. A better way would be to copy the OpenVAS files in /usr/lib/systemd/system/
to /etc/systemd/system
to prevent package updates overriding the changes. But even then, this seems wrong that on systemd level these --listen
command arguments are statically configured to localhost. Is there not a ânormalâ way to override these --listen
switches in systemd? Normally these things are defined in e.g. /etc/openvas
, /etc/default
or /etc/sysconfig
. Like in /etc/default/openvas-manager
, which seems the correct place to do this. However⌠The packager seems to disagree:
# NOTE: This file is not used if you are using systemd. The options are
# hardcoded in the openvas-manager.service file. If you want to change
# them you should override the service file by creating a file
# /etc/systemd/system/openvas-manager.service.d/local.conf like this:
# [Service]
# ExecStart=
# ExecStart=/usr/sbin/openvasmd <your desired options>
Anyway, these OpenVAS packages in Debian are already outdated according to the OpenVAS local scan:
Summary
This script checks and reports an outdated or end-of-life scan engine for the following environments:
- Greenbone Source Edition (GSE)
- Greenbone Community Edition (GCE)
used for this scan.
NOTE: While this is not, in and of itself, a security vulnerability, a severity is reported to make you aware of a possible decreased scan coverage or missing detection of vulnerabilities on the target due to e.g.:
- missing functionalities
- missing bugfixes
- incompatibilities within the feed.
Vulnerability Detection Result
Installed GVM Libraries (gvm-libs) version: 9.0.3
Latest available GVM Libraries (gvm-libs) version: 10.0.2
Reference URL(s) for the latest available version: https://community.greenbone.net/t/gvm-11-stable-initial-release-2019-10-14/3674 / https://community.greenbone.net/t/gvm-10-old-stable-initial-release-2019-04-05/208
So I guess installing from source is highly recommended? Maintaining your own software is usually something to be frowned upon. Because upgrade paths may not be possible due to outdated libraries or upgrade paths in general might break compatibility with Redis (or whatever DB is used). Containers would also be a valid consideration of course. Which would make these upgrades more manageable. Anyone that would like to share some experience about that? There are no official containers as far as I spotted. Building one myself is of course possible.
How do you scale and install OpenVAS? Do you keep OpenVAS up-to-date by compiling each update yourself? Are major upgrades painless (e.g. gvm-libs 9 --> gvm-libs 10). How do you make sure everything stays fast and scalable?