This lives as a docker container at: docker hub
The Greenbone Source code can be found at: Greenbone Source Code
The advantages of the Immauss container image vs the Greenbone images:
The latest image is based on GVM 22.5.x In single container mode, it runs all the components needed to create a scanner in a single container including:
In multi-container mode, it creates individual containers for each of the components. Since most of the Greenbone components utilize unix sockets for communication, the containers share a volume (the default name is: ovasrun) solely for the sharing of the sockets.`
Install docker
If you have Kali or Ubuntu you can use the docker.io package.
apt install docker.io
For other distros, please check with docker for the latest on installation options. https://docs.docker.com/engine/install/
Run the container
These commands will pull, create, and start the container:
Without persistent volume:
docker run --detach --publish 8080:9392 -e PASSWORD="Your admin password here" --name openvas immauss/openvas
To create a volume to store persistent data.
docker volume create openvas
Start the container with a persistent volume:
docker run --detach --publish 8080:9392 -e PASSWORD="Your admin password here" --volume openvas:/data --name openvas immauss/openvas
You can use whatever --name
you’d like but for the sake of this guide we’re using openvas.
The --publish 8080:9392
option will port forward 8080
on the host to 9392
(the container web interface port) in the docker container. Port 8080
was chosen only to avoid conflicts with any existing OpenVAS/GVM installation. You can change 8080
to any available port that you`d like.
Depending on your hardware, it can take anywhere from a few seconds to 30 minutes while the NVTs are scanned and the database is rebuilt.
The NVTs will update every time the container starts. Even if you leave your container running 24/7, the easiest way to update your NVTs is to restart the container.
docker restart openvas
There is also a script in the container that will initiate the sync.
/scripts/sync.sh
You can run the sync at any time on a running container with:
docker exec -it <container-name> /scripts/sync.sh
The git repo has two docker-compose.yml files.
- /compose/docker-compose.yml
- /multi-container/docker-compose.yml
The ‘yml’ in /compose is a single container implementation. The ‘yml’ in /multi-container is for …. multiple containers. Both utilize a ‘.env” file. You can set the docker tag in the “.env” file.
To utilize the docker-compose.yml files, change to the desired directory and run: ``` docker-compose up -d ```
For upgrades, edit the ".env" file and change the version, then execute: ``` docker-compose up -d ```
If you are running the container on a continuing basis, it is a good idea to make a backup of the database at regular intervals. The container is setup to properly shutdown the database to prevent corruption, but if the process is killed unexpectedly, or the host machine loses power, then it is still possible for the database to become corrupt. To make a backup of the current database in the container:
docker exec -it <container name> su -c "/usr/lib/postgresql/13/bin/pg_dumpall" -U postgres -f db-backup-file.sql
Restoral is a bit more difficult. This assumes you are using a volume named “openvas”. No other container should be accessing this volume at the time of restoral. This could be an empty volume or a previously used volume. The below command will:
docker run -it -e RESTORE=true -v <path to backupfile>:/usr/lib/db-backup.sql --rm -v openvas:/data immauss/openvas
There are a number of crucial items not stored in the database such as encryption keys for credentials, SSL certificates etc. All of these will however be stored on the persistent volume located in /data of the container filesystem. The easiest way to backup the entirety of volume is shutdown the openvas container and use a new container to create the backup. This is the safest way to create the backup to ensure no files are changed during the backup process. The below commands assume a container name of openvas-prod and a volume name of openvas.
Stop the running container
docker stop openvas-prod
Start a temporary container to create the backup.
docker run -it --rm -v openvas:/opt -v $(pwd):/mnt alpine /bin/sh -c "cd /opt; tar -cjvf /mnt/openvas.full.tar.gz *"
Restart the production container
docker start openvas-prod
The restoral is similar to the backup process in that we use the alpine container to perform this function. The restoral should be to an empty volume, so start by creating that new volume.
docker volume create new-openvas-volume
Then extract the backup into the volume with alpine.
docker run --rm -it -v <path to backup file>:/backup.tar.gz -v openvas:/mnt alpine /bin/sh -c "cd /mnt; tar xvf /backup.tar.gz"
It’s possible to interact with gvmd via custom scripts and scripts provided by Greenbone. If you are running openvas/gvmd on a single machine, then the scripts will usually communicate with gvmd via socket. With it running in the container, you would need to copy the scripts into the container to run them. Alternatively, your scripts can communicate with gvmd via tcp on port 9390. The easiest way to do this is to tell docker to expose the port by adding ‘’’ -p 9390:9390 ‘’’ to the start command. This forwards port 9390 on your host machine to port 9390 on the container. Now you should be able to send the connection to the IP of your host computer and and script will connect to the container.
Alternatively, you could start a new container with the scripts installed on the same docker network, and have the script connect to the container IP on port 9390.
The following options can be set as environment variables when starting the container. To set an environment variable use “-e”:
-e USERNAME=<username>
-e PASSWORD='<password>'
You should only use these for the initial setup of the container. Always change the password afterward. If you start the container from the command line with the PASSWORD env set, then the password is readily readable in your command history and in /proc etc …. **If you choose to create a new user at startup, the “admin” user will still exist with the default admin password. The admin user is needed as it is the owner of the “feed import process” and gvmd will not let it be deleted. Make sure you change the password for admin in this scenario. you have been warned. :)
-e RELAYHOST=mail.example.com
-e SMTPPORT=25
-e REDISDBS=512
-e QUIET=true
-e SKIPSYNC=true
-e RESTORE=true
-e GVMD_ARGS="--max-ips-per-target=65534 --schedule-timeout=-1 --auth-timeout=1440"
-e GSA_ARGS="--ssl-private-key=<file location> --ssl-certificate=<file location> "
-e REPORT_LINES=10000