Greenbone Vulnerability Management

Resources

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.

Installation

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

USE flags for net-analyzer/gvm Greenbone Vulnerability Management, previously named OpenVAS

`cli`	Command Line Interface for OpenVAS Scanner
`doc`	Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
`gsa`	Greenbone Security Assistant (WebUI)
`ldap`	Add LDAP support (Lightweight Directory Access Protocol)
`ospd`	Enable support for scanner wrappers
`radius`	Add support for RADIUS authentication

Data provided by the Gentoo Package Database · Last update: 2022-06-22 07:05 More information about USE flags

Emerge

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:

root #emerge --ask net-analyzer/gvm

Additional software

Additional support for extra scanning checks can be gained from emerging the following software:

Package	Description
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.

Configuration

Redis

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:

FILE /etc/redis.conf

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:

OpenRC

root #rc-update add redis

root #rc-service redis start

systemd

Note that the systemd service of Redis may require setting RuntimeDirectory=redis so that /run/redis, under which the socket configured, is created.

root #systemctl enable --now redis.service

PostgreSQL backend

Keep in mind that GVM is run under user and group 'gvm'. So create a database-user named 'gvm' and database named 'gvmd'.

root #sudo -u postgres psql

CODE PostgreSQL setup

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:

CODE If using PostgreSQL 15 or higher

grant ALL on SCHEMA public TO gvm;

Network Vulnerability Tests (NVTs)

Upgrade the NVT (Network Vulnerability Tests) archives:

Note
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.

root #gvm-sync-all

Be patient...it will take a while.

Synchronization errors

If experiencing the following error:

user $greenbone-nvt-sync

rsync: failed to connect to feed.openvas.org (89.146.224.58): 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 --rsync or --curl options, like:

Warning
The following commands must be executed sequentially as the gvm user.

user $

greenbone-nvt-sync --curl

user $

greenbone-scapdata-sync --rsync

user $

greenbone-certdata-sync --rsync

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:

user $gvm-manage-certs -a

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.

OpenVAS Scanner

As noted earlier, OpenVAS requires access to the Redis socket. Furthermore, the shipped ospd-openvas.service file assumes the existence of a redis@openvas.service, 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

root #systemctl edit ospd-openvas

and add

FILE /etc/systemd/system/ospd-openvas.service.d/override.confsystemd

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

OpenRC

root #rc-service ospd-openvas start

root #rc-update add ospd-openvas

systemd

root #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:

root #ps aux | grep openvassd

openvassd: Waiting for incoming connections
openvassd: Serving /var/run/openvassd.sock

Greenbone Vulnerability Manager (gvmd)

Start Greenbone Vulnerability Manager daemon:

OpenRC

root #rc-service gvmd start

root #rc-update add gvmd

systemd

root #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:

root #sudo -u gvm bash

user $gvmd --create-user=admin --role=Admin

User created with password '18664575-7101-4ceb-8a94-429a376824e6

Tip
To change the password, substitute MyNewVeryStrongPassword with a new password:

user $gvmd --user=admin --new-password=MyNewVeryStrongPassword

Set the Feed Import Owner

Now obtain the UUID of the created admin user via

user $gvmd --get-users --verbose

and set it as feed owner

user $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.

FILE /etc/conf.d/gsadOpenRC

GSAD_LISTEN_ADDRESS="--listen=0.0.0.0"

FILE /etc/gvm/sysconfig/gsad-daemon.confsystemd

GSAD_LISTEN_ADDRESS="--listen=0.0.0.0"

Or, in one shot:

CODE OpenRC

sed -i -e "s/127\.0\.0\.1/0\.0\.0\.0/g" /etc/conf.d/gsad

CODE systemd

sed -i -e "s/127\.0\.0\.1/0\.0\.0\.0/g" /etc/gvm/sysconfig/gsad-daemon.conf

Tip
If you prefer reverse proxying with NGINX check out the following file: /etc/openvas/gsa.nginx.reverse.proxy.example.

Start greenbone vulnerability assistant daemon:

OpenRC

root #rc-service gsad start

root #rc-update add gsad

systemd

root #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!

Misc

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.

root #mv /etc/openvas/pwpolicy.conf /etc/gvm/

root #mv /etc/openvas/openvasmd_log.conf /etc/gvm/gvmd_log.conf

root #cp /etc/openvas/gsf-access-key /etc/gvm/

root #mv /var/lib/openvas/scap-data /var/lib/gvm/scap-data

root #mv /var/lib/openvas/cert-data /var/lib/gvm/cert-data

root #mv /var/lib/openvas/openvasmd /var/lib/gvm/gvmd

root #mv /var/lib/openvas/CA /var/lib/gvm/CA

root #mv /var/lib/openvas/private /var/lib/gvm/private

SQLite

root #mv /var/lib/openvas/mgr/tasks.db /var/lib/gvm/gvmd/gvmd.db

PostgreSQL

root #sudo -u postgres bash

root #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:

root #gvmd --migrate

Configure trusted NVTs

Sum-up: https://community.greenbone.net/t/gcf-managing-the-digital-signatures/101 :

Trusted NVTs

"Signed NVTs are usually provided by NVT Feed Services. For example, the NVTs contained in the OpenVAS NVT Feed are signed by the "OpenVAS Transfer Integrity" key which you can find at the bottom of this page. If you have already installed OpenVAS, you can use the "greenbone-nvt-sync" command to synchronize your NVT collection with the OpenVAS NVT Feed and receive signatures for all NVTs."

Create key

You need to choose Realname, Email and a Password. Example:

root #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:

root #

wget https://www.greenbone.net/GBCommunitySigningKey.asc

root #

gpg --homedir=/etc/openvas/gnupg --import GBCommunitySigningKey.asc

Set trust

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:

root #

gpg --homedir=/etc/openvas/gnupg --list-keys

root #

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:

root #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:

CODE enable NVT signing

sed -i -e "s/nasl_no_signature_check.*/nasl_no_signature_check = no/g" /etc/openvas/openvassd.conf

As last step, restart openvassd service:

root #rc-service openvassd restart

Troubleshooting

If you encounter a problem on fresh installation , first stop greenbone daemons (openvassd,gvmd and gsad) and clear redis cache:

root #redis-cli -s /tmp/redis.sock FLUSHDB

root #redis-cli -s /tmp/redis.sock FLUSHALL

Clean pre-generated NVTs and database;

root #rm -rf /var/lib/gvm/*

Then follow the instructions again.

Greenbone Vulnerability Management

Contents

Installation

USE flags

USE flags for net-analyzer/gvm Greenbone Vulnerability Management, previously named OpenVAS

Emerge

Additional software

Configuration

Redis

OpenRC

systemd

PostgreSQL backend

Network Vulnerability Tests (NVTs)

Synchronization errors

gvmd certificate generation

Starting Greenbone daemons

OpenVAS Scanner

OpenRC

systemd

Greenbone Vulnerability Manager (gvmd)

OpenRC

systemd

Set the Feed Import Owner

Greenbone Vulnerability Assistant WebUI (gsad)

OpenRC

systemd

Misc

Migrating version OpenVAS 9.0 to GVM-10.0

SQLite

PostgreSQL

Migrating the database

Configure trusted NVTs

Create key

Add a certificate to OpenVAS Scanner keyring

Set trust

Troubleshooting

See Also