Comprehensive Engineering Guide to OpenVAS Deployment and Troubleshooting via Docker

The deployment of OpenVAS (Open Vulnerability Assessment System) within a containerized environment represents a sophisticated intersection of vulnerability management and DevOps orchestration. By utilizing Docker, security professionals can abstract the complex dependencies of the Greenbone Vulnerability Management (GVM) ecosystem, ensuring that the scanner, the manager, and the database layers operate in a consistent, isolated environment. This architectural approach mitigates the "dependency hell" often associated with installing OpenVAS directly on a host operating system, such as Ubuntu, where library conflicts and kernel requirements can lead to unstable installations.

The OpenVAS ecosystem is not a single entity but a collection of interconnected services. In a standard Docker deployment, this involves the Greenbone Vulnerability Manager (gvmd), the OpenVAS Scanner (ospd-openvas), and the Greenbone Security Assistant (GSA) for the web interface. The integration of these components requires precise synchronization of SCAP (Security Content Automation Protocol) data, CERT (Computer Emergency Response Team) data, and NVTs (Network Vulnerability Tests). When these data layers are missing or corrupted, the system fails to initiate scans or provide the GUI, resulting in the "No SCAP database found" errors frequently encountered during initial setup on modern distributions like Ubuntu 24.04.

Architectural Analysis of OpenVAS Docker Distributions

There are two primary paths for deploying OpenVAS via Docker: the official Greenbone Community Edition containers and community-maintained images such as those provided by mikesplain. Each approach offers different trade-offs in terms of stability, ease of use, and granularity of control.

The Greenbone Community Edition Framework

The official Greenbone deployment utilizes a microservices architecture, typically orchestrated via docker-compose. This method separates the components into distinct containers to allow for independent scaling and updates.

The following table details the core components found in the Greenbone Community Edition ecosystem:

Community-Maintained Distributions (mikesplain/openvas)

For users seeking a more monolithic, "all-in-one" experience, the mikesplain/openvas image provides a streamlined alternative. This distribution has evolved through different versions of the OpenVAS core, with a significant shift from version 8 to version 9.

The transition to version 9 was necessitated by the fact that version 8 exhibited numerous instabilities and failures within the Docker runtime environment. Version 9 is designated as the standard, offering a more stable build and a smaller image footprint by removing unnecessary extras.

Detailed Deployment Strategies and Configuration

Deploying OpenVAS requires careful attention to port mapping and environment variables to ensure the web interface is accessible and the internal services can communicate.

Execution Commands for mikesplain/openvas

The basic deployment of the version 9 image can be achieved with a simple docker run command:

docker run -d -p 443:443 --name openvas mikesplain/openvas

Alternatively, to specifically target the version 9 tag:

docker run -d -p 443:443 --name openvas mikesplain/openvas:9

Advanced Configuration and Customization

To move beyond a basic installation, administrators must leverage environment variables to define network identity and security credentials.

• Custom Hostname Access: By default, the system only allows connections for the hostname "openvas". To enable access via a specific DNS name, the PUBLIC_HOSTNAME variable must be used:
  docker run -d -p 443:443 -e PUBLIC_HOSTNAME=myopenvas.example.org --name openvas mikesplain/openvas

• Manager Port Access: To utilize the OpenVAS Manager specifically, port 9390 must be exposed:
  docker run -d -p 443:443 -p 9390:9390 --name openvas mikesplain/openvas

• Persistence via Volumes: To prevent data loss during container restarts, the manager data directory must be mounted to a local host directory:
  mkdir data
docker run -d -p 443:443 -v $(pwd)/data:/var/lib/openvas/mgr/ --name openvas mikesplain/openvas

• Administrative Credentials: The default password can be overridden at runtime using the OV_PASSWORD variable:
  docker run -d -p 443:443 -e OV_PASSWORD=securepassword41 --name openvas mikesplain/openvas

Enterprise Integration: LDAP and SMTP Configuration

For professional environments, manual user management is inefficient. While OpenVAS does not support full LDAP integration natively, a workaround exists to synchronize LDAP admin users with OpenVAS admin users during the application startup sequence.

LDAP Synchronization Implementation

The synchronization process relies on the LDAP_ADMIN_FILTER to identify authorized users. A full deployment command integrating LDAP would look as follows:

docker run -d -p 443:443 -p 9390:9390 --name openvas -e LDAP_HOST=your.ldap.host -e LDAP_BIND_DN=uid=binduid,dc=company,dc=com -e LDAP_BASE_DN=cn=accounts,dc=company,dc=com -e LDAP_AUTH_DN=uid=%s,cn=users,cn=accounts,dc=company,dc=com -e LDAP_ADMIN_FILTER=memberOf=cn=admins,cn=groups,cn=accounts,dc=company,dc=com -e LDAP_PASSWORD=password -e OV_PASSWORD=admin mikesplain/openvas

SMTP Notification Setup

To enable automated reporting and alerts via email, the Postfix server within the container must be configured using the following environment variables:

• OV_SMTP_HOSTNAME: The address of the mail server.
• OV_SMTP_PORT: The port for SMTP communication.
• OV_SMTP_USERNAME: The authentication username.
• OV_SMTP_KEY: The authentication key or password.

Example implementation:

docker run -d -p 443:443 -e OV_SMTP_HOSTNAME=smtp.example.com -e OV_SMTP_PORT=587 -e [email protected] -e OV_SMTP_KEY=g0bBl3de3Go0k --name openvas mikesplain/openvas

Troubleshooting and Maintenance Operations

OpenVAS is a data-heavy application. The most common failure points involve the synchronization of feed data and the subsequent rebuilding of the vulnerability databases.

Solving the "No SCAP Database Found" Error

In Greenbone Community Edition deployments on Ubuntu 24.04, users often encounter logs in the gvmd container stating "No SCAP database found for migration" and "No CERT database found for migration." This occurs when the data-sync containers fail to populate the shared volumes before the manager starts.

When the gvmd logs show that databases are at the supported version but the GUI remains inaccessible, it is often linked to a failure in the ospd-openvas service. A common error is the non-zero exit status 1 when executing the command openvas --update-vt-info. This indicates that the Vulnerability Test (VT) info update failed, preventing the scanner from communicating with the manager.

Manual Feed Updates and Database Rebuilds

To resolve data inconsistencies or to update the vulnerability signatures, administrators must enter the container's interactive shell.

First, access the container:

docker exec -it openvas bash

Once inside the container, execute the following sequence of commands to ensure all feeds are current and the database is optimized:

• Update NVTs:
  greenbone-nvt-sync
• Rebuild the OpenVAS database with progress tracking:
  openvasmd --rebuild --progress
• Sync CERT data:
  greenbone-certdata-sync
• Sync SCAP data:
  greenbone-scapdata-sync
• Final update of the scanner:
  openvasmd --update --verbose --progress

After updating the feeds, the internal services must be restarted to apply the changes:

/etc/init.d/openvas-manager restart
/etc/init.d/openvas-scanner restart

Monitoring Startup Progress

OpenVAS startup is not instantaneous. The process of scanning CERT data and rebuilding databases can take between 4 and 5 minutes. Users should not assume the system has crashed if the GUI is not immediately available.

To verify the progress of the database build, use the docker top command:

docker top openvas

In the resulting output, look for the process responsible for scanning cert data. This process will display a percentage of completion. The system is fully operational only after the logs explicitly state: "It seems like your OpenVAS-9 installation is OK."

Analysis of Container State and Connectivity

Analyzing the state of the Docker containers is critical for diagnosing "Exited" status codes. In a failing Greenbone deployment, a docker ps -a command might reveal a mix of statuses.

For instance, if the greenbone-community-edition-scap-data-1 container shows "Exited (0)", it means the container performed its task of downloading data and then shut down normally. However, if the greenbone-community-edition-ospd-openvas-1 is "Up" but the GUI is unreachable, the issue typically lies in the failure of the openvas --update-vt-info command within the ospd-openvas bash environment.

The connectivity between the gvmd (Manager) and ospd-openvas (Scanner) is the most fragile link in the chain. If the gvmd logs indicate that migration is complete but the scanner cannot connect, the administrative action required is usually a manual trigger of the VT update or a verification of the network bridge between the containers.

Conclusion

The deployment of OpenVAS via Docker transforms a notoriously difficult installation process into a manageable orchestration of services. Whether using the modular Greenbone Community Edition or the consolidated mikesplain/openvas image, the primary challenge remains the synchronization of the SCAP and CERT databases. The interdependence of the gvmd and ospd-openvas components means that a failure in the data-sync layer directly results in a failure of the Web UI.

For a successful production-grade installation, administrators must prioritize the use of persistent volumes to avoid repeated 5-minute database rebuilds upon container restart. Furthermore, the implementation of LDAP synchronization and SMTP integration is essential for moving the system from a standalone lab tool to an enterprise vulnerability management platform. The critical path to stability involves monitoring the docker top output during the initial boot and ensuring that the openvasmd rebuild process completes without non-zero exit statuses.

Sources

1. Greenbone Forum - Unable to start OpenVAS using Docker
2. Docker Hub - mikesplain/openvas
3. Docker Hub - Greenbone Organization