Monitoring OpenVAS / GVM with Vigilmon

OpenVAS and Greenbone Vulnerability Management (GVM) are the backbone of open source vulnerability scanning programs. They continuously assess your infrastructure for security weaknesses — but who's watching the watchers? Scanner daemons crash after large scans, feed synchronization jobs stall on network issues, and the web interface goes down while GVM processes keep running, giving a false sense of health. Vigilmon fills the gap: monitoring the Greenbone Security Assistant web UI, OpenVAS scanner daemon, GVM services, and the scheduled feed sync jobs that keep your vulnerability data current.

What You'll Set Up

• HTTP availability monitor for the Greenbone Security Assistant web UI (port 9392)
• TCP health check for the GVM daemon (port 9390)
• Feed synchronization job heartbeat
• Scan task execution health monitoring
• Database connectivity check for result storage
• Alert notification service monitoring

Prerequisites

• GVM/OpenVAS installed (Greenbone Community Edition, Docker, or package-based)
• gvmd and gsad daemons running
• Feed data synchronized at least once
• A free Vigilmon account

Why Monitoring Your Vulnerability Scanner Matters

There's a painful irony in unmonitored vulnerability management infrastructure: your security scanning platform can fail silently while you believe your environment is being continuously assessed. Common failure modes include:

• openvassd crashes mid-scan after encountering a malformed response from a target host
• Feed sync stalls because the rsync connection to Greenbone's servers times out — leaving you scanning with weeks-old NVT definitions
• gvmd socket exhaustion during concurrent scans of large IP ranges
• Result database disk space filling up, causing new scan results to be silently discarded

Each of these looks fine from the GSA web UI if you're not actively running a scan. Vigilmon catches them between your manual check-ins.

Step 1: Monitor the Greenbone Security Assistant Web UI

GSA is the web interface for GVM, running on port 9392 by default.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your GSA URL: https://your-gvm-host:9392.
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200 (or 302 if GSA redirects to /login).
6. Click Save.

If GSA is behind a reverse proxy with a proper certificate, enable SSL monitoring:

1. Open the monitor.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.

GSA going down doesn't mean scans have stopped — gvmd runs independently — but operators can't see scan results, schedule tasks, or respond to findings when the UI is unavailable.

Step 2: Monitor the GVM Daemon TCP Port

The GVM daemon (gvmd) listens on the GMP (Greenbone Management Protocol) port, 9390 by default. Probe it directly with a TCP monitor:

1. Click Add Monitor → TCP Port.
2. Host: your-gvm-host.
3. Port: 9390.
4. Set Check interval to 2 minutes.
5. Click Save.

For Unix socket installations where gvmd listens on a socket file instead of a TCP port, wrap the check in a script and expose it as an HTTP endpoint:

#!/bin/bash
# /usr/local/bin/gvmd-health-check.sh
if gvm-cli --gmp-username admin --gmp-password "$GMP_PASSWORD" \
   socket --socketpath /run/gvmd/gvmd.sock \
   --xml "<get_version/>" 2>/dev/null | grep -q "version"; then
  echo '{"gvmd": "ok"}'
  exit 0
else
  echo '{"gvmd": "unreachable"}'
  exit 1
fi

Expose this with a minimal HTTP wrapper and monitor the endpoint.

Step 3: Monitor the OpenVAS Scanner Daemon

The openvassd (or ospd-openvas) process does the actual vulnerability scanning. It can crash during aggressive scans or when probing hosts with unusual network stacks.

Check that the OSP daemon is listening:

1. Click Add Monitor → TCP Port.
2. Host: your-gvm-host.
3. Port: 9390 (or the OSP port, typically 9390 or 9391 depending on version).
4. Set Check interval to 5 minutes.
5. Click Save.

For a process-level check, wrap a process list check in a health endpoint:

#!/bin/bash
# /usr/local/bin/ospd-health.sh
if pgrep -x "ospd-openvas" > /dev/null || pgrep -x "openvassd" > /dev/null; then
  echo -e 'HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n{"ospd": "running"}'
else
  echo -e 'HTTP/1.1 503 Service Unavailable\r\nContent-Type: application/json\r\n\r\n{"ospd": "dead"}'
fi

Run with ncat -l -k -p 8080 -e /usr/local/bin/ospd-health.sh and monitor port 8080.

Step 4: Heartbeat for Feed Synchronization Jobs

GVM's NVT (Network Vulnerability Tests) feed must be synchronized regularly — typically daily — to keep vulnerability definitions current. Feed sync failures mean you're scanning with outdated signatures.

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 1440 minutes (24 hours).
3. Copy the heartbeat URL.
4. Wrap your feed sync cron job with the heartbeat ping:

#!/bin/bash
# /etc/cron.daily/gvm-feed-sync
set -e

# Sync NVT feed
/usr/local/bin/greenbone-nvt-sync

# Sync SCAP data
/usr/local/bin/greenbone-scapdata-sync

# Sync CERT data
/usr/local/bin/greenbone-certdata-sync

# Signal success to Vigilmon — only reached if all syncs succeeded
curl -s https://vigilmon.online/heartbeat/your-id

The set -e ensures curl is only reached if all three sync commands succeed. A failed rsync or network timeout leaves the heartbeat un-pinged, triggering a Vigilmon alert after 24 hours.

Step 5: Monitor the Result Storage Database

GVM stores scan results in a PostgreSQL database (gvmd database). When disk fills up or the database host becomes unreachable, new results are silently discarded.

Add a health check script that validates database connectivity:

#!/bin/bash
# /usr/local/bin/gvm-db-health.sh
if sudo -u gvmd psql -d gvmd -c "SELECT COUNT(*) FROM results LIMIT 1;" > /dev/null 2>&1; then
  echo -e 'HTTP/1.1 200 OK\r\n\r\n{"database": "ok"}'
else
  echo -e 'HTTP/1.1 503 Service Unavailable\r\n\r\n{"database": "unreachable"}'
fi

Expose it on a local port and add a Vigilmon HTTP monitor:

1. Type: HTTP / HTTPS
2. URL: http://localhost:8081/
3. Expected status: 200
4. Check interval: 5 minutes

Also monitor disk space indirectly: set up a Vigilmon cron heartbeat for a disk-check script that only pings if free space on the GVM data partition is above 10%.

Step 6: Monitor the Alert Notification Service

GVM can send email, syslog, or HTTP alerts when scans complete or vulnerabilities are found. If the alert service is misconfigured or the SMTP relay is down, critical findings go unreported.

Add an HTTP endpoint that validates your alert channel:

#!/usr/bin/env python3
# /usr/local/bin/gvm-alert-health.py
import smtplib
from http.server import HTTPServer, BaseHTTPRequestHandler

class AlertHealthHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        try:
            smtp = smtplib.SMTP('localhost', 25, timeout=5)
            smtp.quit()
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b'{"smtp": "ok"}')
        except Exception as e:
            self.send_response(503)
            self.end_headers()
            self.wfile.write(f'{{"smtp": "error", "detail": "{str(e)}"}}'.encode())
    def log_message(self, *args):
        pass

HTTPServer(('localhost', 8082), AlertHealthHandler).serve_forever()

Monitor http://localhost:8082/ with Vigilmon expecting status 200.

Step 7: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or PagerDuty.
2. Recommended thresholds:

| Monitor | Failures before alert | Urgency | |---|---|---| | GSA web UI down | 2 | Medium | | GVM daemon TCP | 1 | High | | OpenVAS scanner dead | 1 | Critical | | Feed sync missed | 1 | High | | Database unreachable | 1 | Critical | | SMTP alert failure | 2 | Medium |

Security infrastructure failures warrant lower thresholds than typical web apps — a dead scanner means your attack surface is unmonitored.

Summary

| Monitor | Target | What It Catches | |---|---|---| | GSA web UI | :9392 | Interface down, proxy failure | | GVM daemon | :9390 TCP | gvmd crash, socket exhaustion | | OpenVAS scanner | Process check | ospd-openvas crash | | Feed sync heartbeat | Cron heartbeat | Stale NVT definitions | | Result database | Local health endpoint | Disk full, DB unreachable | | SMTP alert service | SMTP probe | Silent finding suppression |

Your vulnerability scanner protects your entire infrastructure — so it deserves the same monitoring rigor you'd apply to a production database or API gateway. With Vigilmon watching every GVM component, you'll know within minutes if your security scanning platform has silently stopped protecting you.