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.
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.
- 1 Introduction
- 2 Installation
- 3 Configuration
- 4 Starting Greenbone daemons
- 5 Misc
- 6 Troubleshooting
- 7 See Also
As mentioned above, OpenVAS with version 10 has been renamed in Greenbone Vulnerability Management (GVM-10). Also OpenVAS component's name has been renamed. The recent package naming schema can be referenced in the below table.
|GVM10-RESOLVER PACKAGE NAME||GVM10-CORE COMPONENTS PACKAGE NAMES|
|Old package name||New package name||Old package name||New package name|
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|
||A cron job to update GVM's vulnerability feeds daily|
||Extra fonts, pdf-results! and html docs support|
||Greenbone Security Assistant (WebUI)|
||Add LDAP support (Lightweight Directory Access Protocol)|
||Enable support for scanner wrappers|
||Add support for RADIUS authentication|
emerge --ask net-analyzer/gvm
Openvas-scanner relies on Redis. Redis should be configured to listen to a socket.
Modify /etc/redis.conf by setting :
unixsocket /tmp/redis.sock unixsocketperm 700 port 0 #save 900 1 #save 300 10 #save 60 10000 #maxmemory 64mb
Then start redis and enable it:
rc-service redis start
rc-update add redis
systemctl start redis.service
systemctl enable redis.service
SQLite support will be dropped in next version of Greenbone Vulnerability Manager (gvmd-9). Therefore, the use of PostgreSQL is highly recommended.
Keep in mind that we run GVM under user and group 'gvm'. So we create a database-user named 'gvm' and database named 'gvmd'.
For creating "uuid-ossp" extension you need to compile PostgreSQL with 'uuid' use flag!. Otherwise you will get error.
Readers preferring PostgreSQL (recommended) instead of SQLite need to create user and database first then give a necessary permission to user:
sudo -u postgres bash
createuser -DRS gvm createdb -O gvm gvmd psql gvmd create role dba with superuser noinherit; grant dba to gvm; create extension "uuid-ossp"; \q exit
Network Vulnerability Tests (NVTs)
Upgrade the NVT (Network Vulnerability Tests) archives:
The following commands must be executed sequentially as the gvm user.
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.
sudo -u gvm bash
Be patient...it will take a while.
If experiencing the following error:
rsync: failed to connect to feed.openvas.org (18.104.22.168): 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:
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 Greenbone Vulnerability Feed rsync tasks completed we will start daemons.
- Start services sequentially -> openvassd > gvmd > gsad
- Greenbone daemons ignores SIGHUP. So restart and reload commands not work as expected.
Since Version 11 openvassd is replaced by ospd-openvas. It's an extra python tool which runs the openvas scanner.
Openvas Scanner (openvassd)
Start openvas scanner daemon:
rc-service openvassd start
rc-update add openvassd
systemctl start openvassd.service
systemctl enable openvassd.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 start gvmd.service
systemctl enable 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
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 start gsad.service
systemctl enable 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.