Skip to content

Latest commit

 

History

History
126 lines (89 loc) · 4.03 KB

README.md

File metadata and controls

126 lines (89 loc) · 4.03 KB
Raw

gvm-docker

GitHub Super-Linter

Introduction

This deployment sets up a GVM (Greenbone Vulnerability Management) installation in a container.

After it is set up, the system will

  • be accessible by browsing to https://localhost:4443,
  • be configured with a weekly running task targeting the container itself,
  • allow connection to additional scanner containers,
  • update GVM feeds daily between noon and 2 PM UTC, and
  • update the underlying Debian installation daily.

The following diagram shows a rough overview of the components and interactions involved: Architecture

Quickstart

The following commands will start a single main node:

./prepare.sh
podman-compose -f docker-compose.yml -f docker-compose-gvm.yml up -d --build

After some time, you can browse to https://localhost:4443 and login:

  • user: gvm
  • password: (see content of .gvm_pass)

Hint: The initialization phase takes some minutes (more than 15 minutes). You can check that it finished by checking that one task was created.

Connect additional scanner/s

To connect an additional scanner to the main node, checkout the repository on another host and run the following commands:

./prepare.sh
podman-compose -f docker-compose.yml -f docker-compose-ospd.yml up -d --build

# Wait until the following command shows that all services are running.
podman-compose exec openvas systemctl status

Thereafter, run the following commands on the host of the main node and follow the instructions:

podman-compose exec openvas /bin/bash
> /opt/gvm/sbin/add-scanner.sh <some name> <IP address of additional scanner> [SSH port]

The scanner will now be shown at https://localhost:4443/scanners and can be used within tasks.

Configuration as code

Tasks, schedules, and overrides can be configured automatically with the csv files located at opt/gvm/etc. Those files will be parsed at startup time. Furthermore, overrides can be changed at runtime as follows:

  1. Enter container: podman-compose exec openvas /bin/bash
  2. Change /opt/gvm/etc/overrides.csv as required.
  3. Configure overrides: systemctl start set-overrides

Update version numbers

To set all (sub-)products in their latest stable version, please run the following command:

./stable-version-numbers.py > opt/gvm/src/versions.csv

Issues

cgroups v2

In case of (A) running many scans in parallel and (B) using podman in combination with cgroups v2 (which limits the number of container processes to 2048 by default), you might need to increase this limit since fork() syscalls by the scanner could return with the message Resource temporarily unavailable. Therefore, you need to increase this limit in /etc/containers/containers.conf (for a system-wide setting) or in $HOME/.config/containers/containers.conf (for a user-specific setting) like this:

[containers]
pids_limit = 10240

Rootless podman

While not strictly necessary, it's highly recommended to NOT use rootless podman for running in production.

Background: rootless podman uses slirp4netns to forward network traffic from/to a container. This is a single process and with GVM possibly scanning a whole network at once, this service is heavily overloaded and scans are slowed down and might eventually show timeouts.

Retrieve initial feed file from already running system

To speed up startups of the system at a later point by decreasing the time for the initial feed sync, the file feeds.tar.gz can be retrieved from a running system. Therefore, just look into feeds/feeds.tar.gz, which is updated once a day.

Skip initial feed synchronization

To skip the - potentially very long running - initial feed synchronization, you can execute the below command before starting the container. Please be aware that this will only work if feeds.tar.gz has been initialized properly beforehand.

echo NO >feeds/initial_feed_sync