Greenbone Vulnerability Management
Greenbone Vulnerability Management (GVM) is a network security scanner with associated tools like a graphical user front-end. The core component is a server with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications. It is used by both offensive and defensive security experts to determine attack surfaces.
GVM was previously known as Open Vulnerability Assessment System (OpenVAS). OpenVAS was a fork of Nessus, the popular corporate security scanner maintained by Tenable. Both OpenVAS and Nessus were originally built from the nmap port scanner.
This guide provides instructions on installing a complete server solution for vulnerability scanning and vulnerability management.
net-analyzer/gvm is the resolver package of core GVM components and has several USE flags that may be desired for certain bigger setups. As this article aims at installing and configuring a basic GVM setup.
USE flags for net-analyzer/gvm Greenbone Vulnerability Management, previously named OpenVAS
||Command Line Interface for OpenVAS Scanner|
||Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally|
||Greenbone Security Assistant (WebUI)|
||Add LDAP support (Lightweight Directory Access Protocol)|
||Enable support for scanner wrappers|
||Add support for RADIUS authentication|
The net-analyzer/gvm is a meta-package in essence. It depends upon the command-line interface, libraries, manager, scanner, and tools. Do not be surprised if the dependency list is a little long:
emerge --ask net-analyzer/gvm
Additional support for extra scanning checks can be gained from emerging the following software:
|app-forensics/ovaldi||For ovaldi (OVAL) — an OVAL Interpreter.|
|net-analyzer/ike-scan||For ike-scan - an IPsec VPN scanning, fingerprinting and testing tool.|
|net-analyzer/nikto||For Nikto — a web server scanning and testing tool.|
Openvas-scanner relies on Redis, which is an in-memory data structure storage system. Redis should be configured to listen to a socket. Modify /etc/redis.conf by setting:
unixsocket /run/redis/redis.sock unixsocketperm 700 port 0
Note that this configuration will only allow the 'redis' user to access the socket. We will later fix that by setting a filesystem ACL on the socket, allowing the 'gvm' user, i.e., the user OpenVAS runs under, to access it.
Then enable and start the redis service:
rc-update add redis
rc-service redis start
Note that the systemd service of Redis may require setting RuntimeDirectory=redis so that /run/redis, under which the socket configured, is created.
systemctl enable --now redis.service
Keep in mind that GVM is run under user and group 'gvm'. So create a database-user named 'gvm' and database named 'gvmd'.
sudo -u postgres psql
create database gvmd; create role dba with superuser noinherit; create user gvm; grant all privileges on database gvmd to gvm; grant dba to gvm;
Note the last command, where we grant the 'gvm' user the 'dba' role, which is essentially 'superuser', the highest privileged role of postgres. This means that the 'gvm' user has access to all database in postgres. You may do not want to use the postgres databse with other applications besides GVM due to this. The 'dba' role is required, as it is used, and hence expected by gvmd to install GVM-specific postgres plugins.
Workaround for PostgreSQL version 15 (released October, 2022), give the gvm user permission to modify the public schema:
grant ALL on SCHEMA public TO gvm;
Network Vulnerability Tests (NVTs)
Upgrade the NVT (Network Vulnerability Tests) archives:
Verify RSYNC (TCP/873) has been enabled without NAT and Proxy to greenbone IPv6/IPv4 feed server [feed.community.greenbone.net]. SSH port 24 or 443 is only supported through the GSF (Paying Greenbone Customer) service level. Troubleshoot by checking the firewall for active connections. Due note systems sharing an external IP address many encounter issues, since one feed-sync per IP is the limit for the GCF. This can be verified by telneting to the Port 873 to test communication.
Be patient...it will take a while.
If experiencing the following error:
rsync: failed to connect to feed.openvas.org (22.214.171.124): Connection refused (111) rsync: failed to connect to feed.openvas.org (2a01:130:2000:127::d1): Network unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3]
Try to append
--curl options, like:
The following commands must be executed sequentially as the gvm user.
gvmd certificate generation
Now, generate the certificate for gvmd.
The certificate infrastructure enables GVM daemons to communicate in a secure manner and is used for authentication and authorization before establishing TLS connections between the daemons.
Setup the certificate automatically by running:
Starting Greenbone daemons
After redis configuration and GVM feed rsync tasks are completed, the daemons will need to be started in the following order.
- Start services sequentially -> ospd-openvas > gvmd > gsad
- Greenbone daemons ignores SIGHUP. So restart and reload commands do not work as expected.
As noted earlier, OpenVAS requires access to the Redis socket. Furthermore, the shipped ospd-openvas.service file assumes the existence of a firstname.lastname@example.org, which will likely not exist on your system. To allow access to the socket and to adjust the systemd unit dependencies, create a systemd service override
systemctl edit ospd-openvas
[Unit] After=network.target networking.service redis.service Wants=redis.service [Service] ExecStartPre=+setfacl -m u:gvm:rw /run/redis/redis.sock
Start OSDP OpenVAS scanner daemon:
rc-service ospd-openvas start
rc-update add ospd-openvas
systemctl enable --now ospd-openvas.service
This will take a while, since OpenVAS here is loading all NVT definition downloaded. Check the status of openvassd that completed loading NVTs before starting gvmd:
ps aux | grep openvassd
openvassd: Waiting for incoming connections openvassd: Serving /var/run/openvassd.sock
Greenbone Vulnerability Manager (gvmd)
Start Greenbone Vulnerability Manager daemon:
rc-service gvmd start
rc-update add gvmd
systemctl enable --now gvmd.service
This will take a while, since 'gvmd' here is rebuilding his database with all NVT definition downloaded. You will see with ```ps aux``` the gvmd process in "Syncing SCAP" state. Don't worry, after a while gvmd will load scapdata. This is normal to take long time.
Create a new user with Admin role, and take note of the generated password under user gvm:
sudo -u gvm bash
gvmd --create-user=admin --role=Admin
User created with password '18664575-7101-4ceb-8a94-429a376824e6
To change the password, substitute
MyNewVeryStrongPasswordwith a new password:
gvmd --user=admin --new-password=MyNewVeryStrongPassword
Set the Feed Import Owner
Now obtain the UUID of the created admin user via
gvmd --get-users --verbose
and set it as feed owner
gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value <uuid_of_user>
Greenbone Vulnerability Assistant WebUI (gsad)
Greenbone Security Assistant (GSA) WebUI listens port 9392 default on localhost. If you wish you can configure Greenbone Security Assistant (GSAD) to listen to other interfaces rather than localhost only, so it is reachable from other hosts.
Or, in one shot:
sed -i -e "s/127\.0\.0\.1/0\.0\.0\.0/g" /etc/conf.d/gsad
sed -i -e "s/127\.0\.0\.1/0\.0\.0\.0/g" /etc/gvm/sysconfig/gsad-daemon.conf
If you prefer reverse proxying with NGINX check out the following file: /etc/openvas/gsa.nginx.reverse.proxy.example.
Start greenbone vulnerability assistant daemon:
rc-service gsad start
rc-update add gsad
systemctl enable --now gsad.service
Open the browser at the IP address or domain name where GSAD is running, on port 9392, and login with the credentials previously created.
Happy vulnerability assessment!
Migrating version OpenVAS 9.0 to GVM-10.0
GVM-10 is a major update so updating from OpenVAS-9 is not possible but we are still able to migrate old database. If you are upgrading from OpenVAS-9 to GVM-10 before starting gvmd 8.0.1 for the first time you need to move some files to the new locations where they are expected now. If you do not do this, the files are freshly initialized and it gets more complicated to transfer the old data properly.
mv /etc/openvas/pwpolicy.conf /etc/gvm/
mv /etc/openvas/openvasmd_log.conf /etc/gvm/gvmd_log.conf
cp /etc/openvas/gsf-access-key /etc/gvm/
mv /var/lib/openvas/scap-data /var/lib/gvm/scap-data
mv /var/lib/openvas/cert-data /var/lib/gvm/cert-data
mv /var/lib/openvas/openvasmd /var/lib/gvm/gvmd
mv /var/lib/openvas/CA /var/lib/gvm/CA
mv /var/lib/openvas/private /var/lib/gvm/private
mv /var/lib/openvas/mgr/tasks.db /var/lib/gvm/gvmd/gvmd.db
sudo -u postgres bash
psql --command='ALTER DATABASE tasks RENAME TO gvmd;'
Migrating the database
If you have used Manager before, you might need to migrate the database to the current data model. Use this command to run the migration:
Configure trusted NVTs
You need to choose Realname, Email and a Password. Example:
gpg --homedir=/etc/openvas/gnupg --gen-key
Realname: openvas Email: openvas@localhost Password: admin
Add a certificate to OpenVAS Scanner keyring
Add the OpenVAS scanner Integrity Key:
gpg --homedir=/etc/openvas/gnupg --import GBCommunitySigningKey.asc
To mark a certificate as trusted for your purpose, you have to sign it. The preferred way is to use local signatures that remain only in the keyring of your OpenVAS Scanner installation.
To finally sign a certificate you need to know its KEY_ID. You either get it from the table at the bottom or via a "list-keys" command.
Then you can locally sign:
gpg --homedir=/etc/openvas/gnupg --list-keys
gpg --homedir=/etc/openvas/gnupg --lsign-key KEY_ID
For example, to express your trust in the OpenVAS Transfer Integrity you imported above, you could use the following command:
gpg --homedir=/etc/openvas/gnupg --lsign-key 0ED1E580
Before signing you should be absolutely sure that you are signing the correct certificate. You may use its fingerprint and other methods to convince yourself.
To enable NVT signing on openvassd:
sed -i -e "s/nasl_no_signature_check.*/nasl_no_signature_check = no/g" /etc/openvas/openvassd.conf
As last step, restart openvassd service:
rc-service openvassd restart
If you encounter a problem on fresh installation , first stop greenbone daemons (openvassd,gvmd and gsad) and clear redis cache:
redis-cli -s /tmp/redis.sock FLUSHDB
redis-cli -s /tmp/redis.sock FLUSHALL
Clean pre-generated NVTs and database;
rm -rf /var/lib/gvm/*
Then follow the instructions again.
- PostgreSQL — a free and open source relational database management system (RDBMS).
- Nmap — an open source recon tool used to check for open ports, what is running on those ports, and metadata about the daemons servicing those ports.
- Security Handbook — a step-by-step hardening guide for Gentoo Linux.