Automating Linux Vulnerability Scanning with OpenVAS and Wazuh SIEM Integration

Enterprise Linux fleet security demands continuous, automated vulnerability discovery paired with real-time host-level telemetry to prevent zero-day exploitation and configuration drift. When managing high-density environments on platforms like CpanelFree, running manual vulnerability scans creates operational blind spots, unmanageable alert fatigue, and delayed patching cycles. By bridging the Greenbone Vulnerability Management (OpenVAS) network scanner with Wazuh SIEM’s centralized log aggregation and active response framework, security engineers can establish a closed-loop vulnerability management lifecycle that automatically discovers, correlates, and mitigates Linux vulnerabilities without manual human triage.

Unified Security Architecture: Integrating Network Scans with Host Telemetry

Traditional Linux infrastructure security frequently suffers from functional silos. Network scanners evaluate systems purely from the outside in, probing open ports, listening sockets, and banner versions over TCP/UDP. Conversely, host-based intrusion detection systems (HIDS) like Wazuh monitor processes, file integrity (FIM), system log streams, and kernel auditing records from the inside out. When these platforms operate independently, an engineer must manually cross-reference an OpenVAS vulnerability report against live system processes to determine whether an identified CVE is actively exploitable or merely dormant code.

By automating the ingestion of OpenVAS Greenbone Management Protocol (GMP) scan outputs directly into the Wazuh SIEM pipeline, security teams transform point-in-time vulnerability reports into dynamic, real-time threat intelligence. When OpenVAS detects a critical vulnerability—such as an unpatched OpenSSH daemon or an exploitable web service—it pushes structured JSON reports into a dedicated Wazuh ingestion socket or log channel. Wazuh decodes the CVE identifier, checks active socket bindings on the host via the Wazuh agent, and can automatically execute targeted containment scripts, adjust local firewall policies, or quarantine vulnerable services before an external adversary achieves remote code execution.

Comparative Matrix: Standalone Auditing vs. Integrated SIEM Pipeline

Deploying automated vulnerability scanning alongside centralized SIEM integration dramatically reduces Mean Time to Detection (MTTD) and Mean Time to Remediation (MTTR). The matrix below illustrates the performance and operational differences between isolated periodic scanning and a synchronized Wazuh-OpenVAS architecture.

Kernel and Network Stack Tuning for High-Concurrency Vulnerability Scans

Running comprehensive vulnerability assessments against modern cloud infrastructure generates significant network socket churn. A full OpenVAS scan launches thousands of concurrent stateful TCP probes, syn-scans, and TLS handshakes. Under stock Linux kernel configurations, this volume of traffic causes connection tracking table saturation (nf_conntrack: table full, dropping packet), TCP socket exhaustion, and dropped SYN packets that distort scan accuracy.

To prepare your dedicated scanning nodes and target Linux hosts for automated, high-throughput scanning without false positives or network degradation, deploy the following production sysctl configuration file at /etc/sysctl.d/99-vulnerability-scanner.conf:

# /etc/sysctl.d/99-vulnerability-scanner.conf
# Production Kernel Tuning for High-Concurrency OpenVAS & Wazuh Telemetry

# Expand TCP connection backlog and maximum connection capacity
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_syn_backlog = 3240000

# Optimize ephemeral port range for rapid socket recycling
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Increase connection tracking table capacity to prevent dropped probes
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 30

# TCP Window Scaling and Memory Buffers (Min, Default, Max in bytes)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# Prevent SYN Flood false detections on scanning engines
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# Virtual memory management under high scanning load
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
fs.file-max = 2097152

Apply the parameters dynamically without rebooting by executing:

sudo sysctl --system

Automating OpenVAS Scans via Python GVM and Systemd

To eliminate manual interaction with the Greenbone Security Assistant web interface, we implement an autonomous scanning daemon using the official python-gvm API library. This script authenticates with the OpenVAS daemon (gvmd) over a local Unix domain socket, triggers targeted vulnerability scans against your Linux server subnets, extracts structured XML results, transforms findings into standardized JSON, and appends them to a dedicated log monitored by the local Wazuh agent.

Create the automation script at /usr/local/bin/openvas_wazuh_bridge.py:

#!/usr/bin/env python3
"""
OpenVAS to Wazuh SIEM Pipeline Bridge
Automates scheduled vulnerability scans and exports JSON events for Wazuh ingestion.
"""

import os
import sys
import json
import time
import logging
from gvm.connections import UnixSocketConnection
from gvm.protocols.gmp import Gmp
from gvm.transforms import EtreeTransform
import xml.etree.ElementTree as ET

SOCKET_PATH = "/run/gvmd/gvmd.sock"
OUTPUT_LOG = "/var/log/openvas_wazuh_feed.log"
GVMD_USER = "admin"
GVMD_PASS = os.getenv("GVMD_PASSWORD", "EnterpriseSecurePass2026")

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    handlers=[logging.StreamHandler(sys.stdout)]
)

def run_pipeline():
    connection = UnixSocketConnection(path=SOCKET_PATH)
    transform = EtreeTransform()

    logging.info("Connecting to OpenVAS gvmd socket...")
    with Gmp(connection=connection, transform=transform) as gmp:
        gmp.authenticate(username=GVMD_USER, password=GVMD_PASS)
        logging.info("Authenticated successfully with OpenVAS GMP daemon.")

        # Retrieve existing tasks
        tasks = gmp.get_tasks()
        root = tasks

        for task in root.xpath("//task"):
            task_id = task.get("id")
            task_name = task.find("name").text
            status = task.find("status").text

            logging.info(f"Evaluating Task: {task_name} (ID: {task_id}, Status: {status})")

            # Fetch latest report for completed tasks
            last_report = task.find("last_report")
            if last_report is not None:
                report_id = last_report.find("report").get("id")
                logging.info(f"Extracting report ID: {report_id}")
                
                report_xml = gmp.get_report(
                    report_id=report_id,
                    filter_string="rows=-1 min_qod=70 apply_overrides=0"
                )
                parse_and_export_report(report_xml)

def parse_and_export_report(report_tree):
    events = []
    for result in report_tree.xpath("//result"):
        host_node = result.find("host")
        host_ip = host_node.text.strip() if host_node is not None else "unknown"
        
        nvt = result.find("nvt")
        name = nvt.find("name").text if nvt is not None and nvt.find("name") is not None else "Unknown NVT"
        cve = nvt.find("cve").text if nvt is not None and nvt.find("cve") is not None else "None"
        cvss = result.find("severity").text if result.find("severity") is not None else "0.0"
        port = result.find("port").text if result.find("port") is not None else "0/tcp"
        description = result.find("description").text if result.find("description") is not None else ""

        severity_float = float(cvss)
        if severity_float = 9.0 else "HIGH" if severity_float >= 7.0 else "MEDIUM",
            "summary": description[:250].replace("\n", " ")
        }
        events.append(event)

    # Write NDJSON to target log
    with open(OUTPUT_LOG, "a", encoding="utf-8") as f:
        for ev in events:
            f.write(json.dumps(ev) + "\n")
    
    logging.info(f"Exported {len(events)} vulnerability events to {OUTPUT_LOG}")

if __name__ == "__main__":
    run_pipeline()

To execute this bridge reliably as a system service, create the corresponding systemd service and timer units at /etc/systemd/system/openvas-wazuh-bridge.service and /etc/systemd/system/openvas-wazuh-bridge.timer:

# /etc/systemd/system/openvas-wazuh-bridge.service
[Unit]
Description=OpenVAS to Wazuh Vulnerability Feed Bridge
After=gvmd.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=gvm
Group=gvm
Environment="GVMD_PASSWORD=EnterpriseSecurePass2026"
ExecStart=/usr/bin/python3 /usr/local/bin/openvas_wazuh_bridge.py
StandardOutput=journal
StandardError=journal
ProtectSystem=strict
ReadWritePaths=/var/log/openvas_wazuh_feed.log

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/openvas-wazuh-bridge.timer
[Unit]
Description=Trigger OpenVAS to Wazuh Bridge Daily
RefuseManualStart=no
RefuseManualStop=no

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Enable and start the timer using standard systemctl commands:

sudo systemctl daemon-reload
sudo systemctl enable --now openvas-wazuh-bridge.timer

Wazuh SIEM Ingestion: Custom Decoders and Correlation Rules

Once OpenVAS generates structured NDJSON events in /var/log/openvas_wazuh_feed.log, configure the Wazuh Agent to monitor the file and forward the log entries to the Wazuh Manager. Add the following localfile block inside /var/ossec/etc/ossec.conf on the scanner host:

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/openvas_wazuh_feed.log</location>
  </localfile>
</ossec_config>

On the Wazuh Manager node, define custom decoders to parse the JSON fields and extract the CVE ID, CVSS score, and affected port. Append the decoder definition to /var/ossec/etc/decoders/local_decoder.xml:

<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<decoder name="openvas-json">
  <prematch>^\{"timestamp":.*"scanner": "OpenVAS-GMP"</prematch>
</decoder>

<decoder name="openvas-json-fields">
  <parent>openvas-json</parent>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

Next, define production correlation rules inside /var/ossec/etc/rules/local_rules.xml. These rules evaluate the vulnerability severity and trigger high-priority alerts whenever an exploitable CVSS score is reported:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="openvas,vulnerability,">
  <!-- Base rule for all ingested OpenVAS reports -->
  <rule id="100500" level="3">
    <decoded_as>openvas-json</decoded_as>
    <description>OpenVAS: Vulnerability scan event detected on $(target_ip)</description>
    <mitre>
      <id>T1595.002</id>
    </mitre>
  </rule>

  <!-- Medium Severity Vulnerabilities (CVSS 4.0 - 6.9) -->
  <rule id="100501" level="7">
    <if_sid>100500</if_sid>
    <field name="severity_level">^MEDIUM$</field>
    <description>OpenVAS: Medium severity flaw on $(target_ip) [CVE: $(cve)] - $(vulnerability_name)</description>
  </rule>

  <!-- High Severity Vulnerabilities (CVSS 7.0 - 8.9) -->
  <rule id="100502" level="10">
    <if_sid>100500</if_sid>
    <field name="severity_level">^HIGH$</field>
    <description>OpenVAS: High severity vulnerability on $(target_ip) Port $(port) [CVE: $(cve)]</description>
  </rule>

  <!-- Critical Severity Vulnerabilities (CVSS 9.0+) with Active Response -->
  <rule id="100503" level="14">
    <if_sid>100500</if_sid>
    <field name="severity_level">^CRITICAL$</field>
    <description>OpenVAS: CRITICAL remotely exploitable flaw on $(target_ip):$(port) [CVE: $(cve)] - Action Required</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

After updating the configuration, validate rule syntax and restart the Wazuh Manager:

/var/ossec/bin/wazuh-logtest < /dev/null
sudo systemctl restart wazuh-manager

Production Hardening and Operational Remediation

Integrating OpenVAS and Wazuh provides automated threat intelligence, but security engineers must avoid the trap of unconstrained automated remediation. Automatically severing network connections or stopping system services based solely on external scan data can inadvertently trigger service outages. Follow these battle-tested architectural guidelines:

• Correlate with Wazuh SCA (Security Configuration Assessment): Before executing remediation, use Wazuh’s built-in CIS benchmark checks to verify whether compensating controls (such as SELinux enforcing mode or AppArmor profiles) mitigate the vulnerability in the running environment.
• Enforce Scan Windows: Restrict high-intensity OpenVAS network scans to off-peak operational maintenance windows to prevent CPU starvation on production database and caching instances.
• Isolate Management Networks: Never expose the Greenbone Management Protocol socket or the Wazuh cluster API over public Internet interfaces. Enforce strict TLS mutual authentication (mTLS) or restrict traffic to isolated WireGuard/VPC management tunnels.
• Log Rotation and Retention: Ensure /var/log/openvas_wazuh_feed.log is managed by logrotate with compression enabled to prevent disk exhaustion on scanning nodes.

Frequently Asked Questions