Installing Greenbone OpenVAS on Ubuntu 24.04

| | 0 Comments| 12:33 PM
Categories:

Ubuntu 24.04 LTS, the “Noble Numbat”, has arrived, and I wanted to get Greenbone OpenVAS up and running on it. OpenVAS is a powerful, but complex, collection of software, used by many to perform vulnerability scans against their IT infrastructure. With more than a half-dozen components and use of external data feeds, Redis, Postgres, and an MQTT broker, installing and running it successfully can be a challenge.

The overview below, and resulting Github repository, is based upon following the source build instructions. I also recommend reading the OpenVAS glossary to familiarize yourself with the terms.

First, a warning! I’ve personally executed these steps a half-dozen times and tested the outcome (a running OpenVAS installation). However, you should understand the basics of the commands and be up to the challenge of troubleshooting in case you run in trouble.

Another couple of warnings. My scripts do not use GPG to verify the tar signatures of Greenbone’s packages. You will also be running these commands as root. There are some that might object to that, and insist on using sudo. I can assure you that doing so will cause heartburn.

Alright, with that out of the way, I recommend you start with a VM with a fresh install of Ubuntu 24.04. If you can, configure the VM with 4 to 8 cores, at least 8GB of RAM, and 64GB of disk space. Then:

Make note of the two top-level scripts exports.sh and install.sh. exports.sh is sourced by individual scripts in scripts/, primarily to allow you to run scripts independently.

Quick Start

So, this won’t necessarily be quick, as it does take some time to build OpenVAS and bootstrap the feeds. For a VM running on an M3 Max (8 cores, 16GB of RAM), it took 44 minutes total, but again, much of that was downloading the feed.

One by One

If you prefer, you can execute each script one at a time. I, in fact, recommend this, if you want to get a feel for how OpenVAS is built from the ground up.

Setting Up

The first three scripts set the stage for the build by creating the gvm user and group, making the source, build, and install directories, and then installing all of the primary dependencies (and there are a lot). There is one nuance you’ll find and that is python3-packaging has been explicitly removed from the install list, and when building osp-openvas it is removed. For whatever reason having it present causes problems.

Building

Scripts 10 through 18 download, build, and install everything. These should be executed in order, and that order matches the canonical build instructions here.

Architecture Configuration

Scripts 90 through 95 cobble together “the architecture”. redis, postgres, and mosquitto are all installed and configured. Interestingly mosquitto was omitted as a dependency in the installation instructions, but it is most definitely required as the MQTT broker (“aka MQTT message bus”).

Bootstrapping

The longest part of the installation and configuration of OpenVAS is greenbone-feed-sync, which is responsible for downloading Notus, NASL, and SCAP files.

Start!

Finally, start everything up!

If you look at the logs you should see lines like:


Finished loading VTs. The VT cache has been updated from version 0 to 202405270604.
Updated NVT cache from version 0 to 202405270604

Pay particular attention to the gvmd.log as it is the best indicator of when things “are ready.”

First Scan

The scripts created a default admin password and left it in adminpass.txt. In a browser, go to http://YOUR_MACHINE:9392 and you should see:

A Quick Scan

A quick scan starts with going to the Tasks menu item under Scans. From here, click on the “wand” icon to bring up the Task Wizard.

Enter the IP address of the host you want to scan (or, if DNS is configured, the FQDN). In our case we’ll scan a Proxmox hypervisor.

Click Start Scan and be patient as OpenVAS performs the scan.

As with any “percent complete” UI, you’ll get to 99% complete quickly, only to wait a bit for it to finish.

Next Steps

You will want to secure your connection with HTTPS. The most straightforward way to do so is to change the the ExecStart for GSAD (/etc/systemd/system/gsad.service) from

to

where CERT_PATH and PRIVKEY_PATH are full paths to your certificate and private key. I typically use Let’s Encrypt to obtain these.

After updating the GSAD unit file, make sure and issue systemctl daemon-reload and then restart GSAD with systemctl restart gsad.