Executing a professional OpenVAS Vulnerability Scan represents the cornerstone of proactive cyber defense within modern network infrastructure. In high stakes environments such as energy grids, water treatment facilities, or distributed cloud architectures, the presence of unpatched services creates significant operational risk. OpenVAS, as part of the Greenbone Vulnerability Management (GVM) ecosystem, provides a comprehensive framework for identifying, multi-indexing, and remediating security defects. The primary challenge in enterprise environments involves managing the overhead of frequent scans while maintaining low latency for critical path services. Without a structured scanning protocol, technical debt accumulates: outdated firmware on logic-controllers or misconfigured encryption protocols on edge gateways become easy points of entry. This manual provides a systematic approach to implementing an idempotent scanning architecture designed to scale with infrastructure complexity while ensuring data integrity across the technical stack.
Technical Specifications
| Requirement | Default Port / Operating Range | Protocol / Standard | Impact Level (1-10) | Recommended Resources |
| :— | :— | :— | :— | :— |
| OS: Debian 11/12 or Kali | Port 9392 (Web UI) | HTTPS / TLS 1.3 | 8 (High) | 4 vCPU / 8GB RAM |
| Database: PostgreSQL 13+ | Port 5432 (Internal) | SQL / Local Socket | 7 (High) | 50GB NVMe SSD |
| Feed Sync: GCF/GVMD | Port 873 or 443 | RSYNC / HTTP | 5 (Medium) | 100 Mbps Throughput |
| Terminal Management | Port 22 | SSHv2 | 9 (Critical) | Latency < 50ms |
| Scanner Daemon | Port 9390 (Internal) | GMP / XML | 8 (High) | 2GB Dedicated RAM |
The Configuration Protocol
Environment Prerequisites:
Successful deployment of an OpenVAS Vulnerability Scan requires a host environment configured for high throughput and stability. The underlying operating system must support systemd for service orchestration and PostgreSQL for relational data persistence. Ensure that the system has administrative access via sudo or root to modify kernel parameters. Network-level permissions must allow outbound requests to feed.community.greenbone.net for signature updates. Furthermore, the local firewall must be configured to allow traffic on the management port (9392) and any ephemeral ports required for active scanning.
Section A: Implementation Logic:
The engineering design of OpenVAS relies on a decoupled architecture where the scanner engine, the management daemon, and the database operate as distinct but interconnected entities. This design ensures that a failure in the web interface does not interrupt an active scan payload. By isolating the ospd-openvas daemon from the gvmd manager, the system achieves higher concurrency: multiple scan tasks can run in parallel without blocking the main event bus. This encapsulation allows for modular scaling; architects can deploy remote sensors across different network segments while centralizing the data analysis on a single hardened management server. This approach minimizes signal-attenuation in distributed environments and ensures scan accuracy regardless of geographic distribution.
Step-By-Step Execution
1. Repository Synchronization and System Update
Execute sudo apt update && sudo apt full-upgrade -y to ensure all system libraries are current.
System Note: This command ensures the Linux kernel and its associated OpenSSL libraries are compatible with the latest encryption standards. Updating the base system prevents library conflicts during the GVM installation process and reduces the risk of scan-time crashes due to outdated binary dependencies.
2. Implementation of GVM Framework
Run the command sudo apt install gvm -y to pull the core packages from the repository.
System Note: The package manager installs the gvmd (Greenbone Vulnerability Manager Daemon), gsad (Greenbone Security Assistant Daemon), and the ospd-openvas scanner. This action creates the directory structure at /var/lib/gvm and installs the necessary python3 dependencies required for vulnerability script execution.
3. Automated Setup and Database Initialization
Execute the command sudo gvm-setup to begin the automated configuration routine.
System Note: This utility performs several critical tasks: it initializes the PostgreSQL database schema, generates unique SSL certificates for secure internal communication via openssl, and creates the initial administrative user. It also triggers the first download of the Network Vulnerability Tests (NVT), which can increase disk I/O and CPU utilization significantly during the decompression phase.
4. Feed Synchronization and Signature Verification
Run sudo gvm-feed-update to synchronize the local signature database with the Greenbone Community Feed.
System Note: This process is essential for the scanner to recognize the latest Common Vulnerabilities and Exposures (CVEs). The integrity of the feed is verified using GPG signatures: this step ensures that the scan payloads downloaded to the scanner are authentic and have not been tampered with during transit across the public internet.
5. Service Status Authentication
Verify the operational state of all daemons using sudo gvm-check-setup.
System Note: This diagnostic script audits the entire installation. It checks for the existence of the gvmd.sock file, verifies that the redis-server is listening on the correct socket at /run/redis/redis.sock, and ensures that the scanner is properly integrated with the manager. If any component fails to respond, the script provides a specific error pointer to the relevant configuration file.
6. Adjusting User Permissions and Access Control
Modify the admin password using sudo gvmd –user=admin –new-password=[YOUR_STRONG_PASSWORD].
System Note: Correcting the default credentials is a mandatory security hardening step. The gvmd process manages the user database; changing the password here updates the encrypted hash stored in the PostgreSQL backend, preventing unauthorized access through the web interface on port 9392.
Section B: Dependency Fault-Lines:
Installation failures often stem from a mismatch between the PostgreSQL version and the GVM expectations. If the database cluster is not properly configured for UTF-8 encoding, the gvmd service will fail to start. Another common bottleneck is the Redis server configuration. OpenVAS uses Redis as a temporary key-value store for scan results during active execution: if the redis.conf is not set to listen on the correct unix socket, or if permissions on /run/redis/redis.sock are too restrictive, the scanner will enter a permanent “Waiting for Scanner” state. Always verify that the systemctl status for redis-server shows “active (running)” before attempting to initiate a scan.
THE TROUBLESHOOTING MATRIX
Section C: Logs & Debugging:
When a scan hangs or fails to produce results, the primary point of investigation is the log directory located at /var/log/gvm/. Each component generates its own log file: access gvmd.log for manager errors, gsad.log for web interface issues, and ospd-openvas.log for scanner-level faults.
- Error String: “Failed to find config”: This indicates the NVT feed has not been fully indexed. Solve this by running gvmd –rebuild-gvmd-data.
- Error String: “Communication with scanner failed”: This usually points to a permission issue with the ospd.sock. Ensure the user running the service has chmod 660 access to the socket file.
- Physical Fault Cue: If the CPU thermal-inertia is exceeded and the host throttles, look for “Scanner stalled” messages in the log. This suggests the concurrency settings are too high for the available hardware.
- Path Verification: Always check /opt/gvm/bin/ to ensure binary paths are correctly exported to the environment variables of the scanning user.
OPTIMIZATION & HARDENING
Performance Tuning:
To maximize throughput without inducing significant packet-loss or latency on the target network, adjust the max_hosts and max_checks parameters within the scan configuration settings. For enterprise-grade hardware, increasing max_hosts to 20 allows for parallel processing of multiple assets, while keeping max_checks at 4-5 ensures that each individual host is not overwhelmed by too many simultaneous probes. Optimizing the PostgreSQL memory allocation (shared_buffers) also reduces the overhead of data ingestion during large-scale scans.
Security Hardening:
Hardening the OpenVAS host is critical since it contains sensitive data about network weaknesses. Implement iptables rules to restrict access to port 9392 to specific administrative IP addresses. Use fail2ban to monitor gsad.log and block IPs that attempt brute-force attacks on the management console. Ensure that the scanner uses “Credentialed Scans” via SSH keys rather than passwords; this minimizes the risk of credential interception and provides a more thorough analysis of the target’s internal library state.
Scaling Logic:
As the infrastructure expands, transition from a single-node setup to a Master-Sensor architecture. The Master node manages the reporting and scheduling, while multiple Sensors (OpenVAS Scanners) are deployed in different VLANs. This design minimizes the impact of signal-attenuation across routers and firewalls. Sensors communicate back to the Master via an encrypted tunnel, ensuring that scan traffic remains encapsulated and protected from internal sniffers.
THE ADMIN DESK
1. How do I fix a “Scanner not found” error?
Verify the ospd-openvas service is active with systemctl status ospd-openvas. If active, check that the scanner path in the Web UI matches the output of which openvas. Ensure the unix socket at /run/ospd/ospd-openvas.sock exists.
2. Can OpenVAS scan IoT devices in energy grids?
Yes, but use the “Discovery” scan config first to avoid crashing sensitive logic-controllers. Standard vulnerability scans can high-load small CPUs. Once identified, use specific NVT tags to target known PLC or RTU vulnerabilities without impacting operational throughput.
3. Why is the feed sync taking so long?
The initial sync involves downloading several gigabytes of data and updating the SQL indices. High latency or low bandwidth slows the process. Use rsync over a stable connection and ensure the disk has high write throughput for decompression.
4. How do I export scan results for auditing?
Navigate to the “Reports” tab in the Greenbone Security Assistant. Select your scan task and click the date. From the “Download” icon, select “PDF” or “CSV”. This provides an authoritative document for compliance evidence or remediation tracking.
