{"id":4658,"date":"2026-09-20T23:01:05","date_gmt":"2026-09-20T17:31:05","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/automating-linux-vulnerability-scanning-with-openvas-and-wazuh-siem-integration\/"},"modified":"2026-09-20T23:01:05","modified_gmt":"2026-09-20T17:31:05","slug":"automating-linux-vulnerability-scanning-with-openvas-and-wazuh-siem-integration","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/automating-linux-vulnerability-scanning-with-openvas-and-wazuh-siem-integration\/","title":{"rendered":"Automating Linux Vulnerability Scanning with OpenVAS and Wazuh SIEM Integration"},"content":{"rendered":"

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<\/a>, 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\u2019s 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.<\/p>\n

<\/p>\n

Unified Security Architecture: Integrating Network Scans with Host Telemetry<\/h2>\n
\n Direct Answer:<\/strong> Integrating OpenVAS with Wazuh SIEM unifies external network attack surface discovery with internal kernel-level host telemetry. OpenVAS identifies network-accessible software flaws, unpatched daemons, and misconfigurations, while Wazuh correlates these Common Vulnerabilities and Exposures (CVEs) with active process logs, system calls, and integrity monitoring, triggering automated mitigation rules directly through the Wazuh agent framework.\n<\/div>\n

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.<\/p>\n

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\u2014such as an unpatched OpenSSH daemon or an exploitable web service\u2014it 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.<\/p>\n

Comparative Matrix: Standalone Auditing vs. Integrated SIEM Pipeline<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default (Manual OpenVAS)<\/th>\nTuned \/ Production (Wazuh Integrated)<\/th>\n<\/tr>\n<\/thead>\n
Scan-to-Detection Latency<\/td>\nHours to days (manual PDF export)<\/td>\nSub-second event correlation (< 850ms)<\/td>\n<\/tr>\n
False Positive Filtration<\/td>\nManual analyst review required<\/td>\nAutomated cross-check with active process table<\/td>\n<\/tr>\n
Remediation Workflow (MTTR)<\/td>\nManual ticket creation & patch cycles<\/td>\nAutomated Wazuh Active Response isolation<\/td>\n<\/tr>\n
Host CPU \/ RAM Overhead<\/td>\nSpikes during unthrottled port sweeps<\/td>\nRate-limited, sysctl-tuned socket handling<\/td>\n<\/tr>\n
Audit & Compliance Trail<\/td>\nFragmented CSV\/XML files<\/td>\nCentralized, tamper-evident OpenSearch logs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Kernel and Network Stack Tuning for High-Concurrency Vulnerability Scans<\/h2>\n

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<\/code>), TCP socket exhaustion, and dropped SYN packets that distort scan accuracy.<\/p>\n

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<\/code>:<\/p>\n

# \/etc\/sysctl.d\/99-vulnerability-scanner.conf\n# Production Kernel Tuning for High-Concurrency OpenVAS & Wazuh Telemetry\n\n# Expand TCP connection backlog and maximum connection capacity\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.tcp_max_syn_backlog = 3240000\n\n# Optimize ephemeral port range for rapid socket recycling\nnet.ipv4.ip_local_port_range = 1024 65535\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\n\n# Increase connection tracking table capacity to prevent dropped probes\nnet.netfilter.nf_conntrack_max = 1048576\nnet.netfilter.nf_conntrack_tcp_timeout_established = 600\nnet.netfilter.nf_conntrack_tcp_timeout_time_wait = 30\nnet.netfilter.nf_conntrack_tcp_timeout_close_wait = 30\n\n# TCP Window Scaling and Memory Buffers (Min, Default, Max in bytes)\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\n\n# Prevent SYN Flood false detections on scanning engines\nnet.ipv4.tcp_syncookies = 1\nnet.ipv4.tcp_synack_retries = 2\nnet.ipv4.tcp_syn_retries = 3\n\n# Virtual memory management under high scanning load\nvm.swappiness = 10\nvm.dirty_ratio = 15\nvm.dirty_background_ratio = 5\nfs.file-max = 2097152<\/code><\/pre>\n
Apply the parameters dynamically without rebooting by executing:<\/p>\n
sudo sysctl --system<\/code><\/pre>\n
\n  Architecture Note:<\/strong> When performing vulnerability scans against containers or high-density virtualization nodes, ensure that net.netfilter.nf_conntrack_max<\/code> is tuned on the host hypervisor. If the host conntrack table fills up, even lightweight TCP checks will fail silently, leading to false negatives where OpenVAS reports closed ports on active services.\n<\/div>\n
Automating OpenVAS Scans via Python GVM and Systemd<\/h2>\n
To eliminate manual interaction with the Greenbone Security Assistant web interface, we implement an autonomous scanning daemon using the official python-gvm<\/code> 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.<\/p>\n
Create the automation script at \/usr\/local\/bin\/openvas_wazuh_bridge.py<\/code>:<\/p>\n
#!\/usr\/bin\/env python3\n\"\"\"\nOpenVAS to Wazuh SIEM Pipeline Bridge\nAutomates scheduled vulnerability scans and exports JSON events for Wazuh ingestion.\n\"\"\"\n\nimport os\nimport sys\nimport json\nimport time\nimport logging\nfrom gvm.connections import UnixSocketConnection\nfrom gvm.protocols.gmp import Gmp\nfrom gvm.transforms import EtreeTransform\nimport xml.etree.ElementTree as ET\n\nSOCKET_PATH = \"\/run\/gvmd\/gvmd.sock\"\nOUTPUT_LOG = \"\/var\/log\/openvas_wazuh_feed.log\"\nGVMD_USER = \"admin\"\nGVMD_PASS = os.getenv(\"GVMD_PASSWORD\", \"EnterpriseSecurePass2026\")\n\nlogging.basicConfig(\n    level=logging.INFO,\n    format=\"%(asctime)s [%(levelname)s] %(message)s\",\n    handlers=[logging.StreamHandler(sys.stdout)]\n)\n\ndef run_pipeline():\n    connection = UnixSocketConnection(path=SOCKET_PATH)\n    transform = EtreeTransform()\n\n    logging.info(\"Connecting to OpenVAS gvmd socket...\")\n    with Gmp(connection=connection, transform=transform) as gmp:\n        gmp.authenticate(username=GVMD_USER, password=GVMD_PASS)\n        logging.info(\"Authenticated successfully with OpenVAS GMP daemon.\")\n\n        # Retrieve existing tasks\n        tasks = gmp.get_tasks()\n        root = tasks\n\n        for task in root.xpath(\"\/\/task\"):\n            task_id = task.get(\"id\")\n            task_name = task.find(\"name\").text\n            status = task.find(\"status\").text\n\n            logging.info(f\"Evaluating Task: {task_name} (ID: {task_id}, Status: {status})\")\n\n            # Fetch latest report for completed tasks\n            last_report = task.find(\"last_report\")\n            if last_report is not None:\n                report_id = last_report.find(\"report\").get(\"id\")\n                logging.info(f\"Extracting report ID: {report_id}\")\n                \n                report_xml = gmp.get_report(\n                    report_id=report_id,\n                    filter_string=\"rows=-1 min_qod=70 apply_overrides=0\"\n                )\n                parse_and_export_report(report_xml)\n\ndef parse_and_export_report(report_tree):\n    events = []\n    for result in report_tree.xpath(\"\/\/result\"):\n        host_node = result.find(\"host\")\n        host_ip = host_node.text.strip() if host_node is not None else \"unknown\"\n        \n        nvt = result.find(\"nvt\")\n        name = nvt.find(\"name\").text if nvt is not None and nvt.find(\"name\") is not None else \"Unknown NVT\"\n        cve = nvt.find(\"cve\").text if nvt is not None and nvt.find(\"cve\") is not None else \"None\"\n        cvss = result.find(\"severity\").text if result.find(\"severity\") is not None else \"0.0\"\n        port = result.find(\"port\").text if result.find(\"port\") is not None else \"0\/tcp\"\n        description = result.find(\"description\").text if result.find(\"description\") is not None else \"\"\n\n        severity_float = float(cvss)\n        if severity_float = 9.0 else \"HIGH\" if severity_float >= 7.0 else \"MEDIUM\",\n            \"summary\": description[:250].replace(\"\\n\", \" \")\n        }\n        events.append(event)\n\n    # Write NDJSON to target log\n    with open(OUTPUT_LOG, \"a\", encoding=\"utf-8\") as f:\n        for ev in events:\n            f.write(json.dumps(ev) + \"\\n\")\n    \n    logging.info(f\"Exported {len(events)} vulnerability events to {OUTPUT_LOG}\")\n\nif __name__ == \"__main__\":\n    run_pipeline()<\/code><\/pre>\n
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<\/code> and \/etc\/systemd\/system\/openvas-wazuh-bridge.timer<\/code>:<\/p>\n
# \/etc\/systemd\/system\/openvas-wazuh-bridge.service\n[Unit]\nDescription=OpenVAS to Wazuh Vulnerability Feed Bridge\nAfter=gvmd.service network-online.target\nWants=network-online.target\n\n[Service]\nType=oneshot\nUser=gvm\nGroup=gvm\nEnvironment=\"GVMD_PASSWORD=EnterpriseSecurePass2026\"\nExecStart=\/usr\/bin\/python3 \/usr\/local\/bin\/openvas_wazuh_bridge.py\nStandardOutput=journal\nStandardError=journal\nProtectSystem=strict\nReadWritePaths=\/var\/log\/openvas_wazuh_feed.log\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n
# \/etc\/systemd\/system\/openvas-wazuh-bridge.timer\n[Unit]\nDescription=Trigger OpenVAS to Wazuh Bridge Daily\nRefuseManualStart=no\nRefuseManualStop=no\n\n[Timer]\nOnCalendar=*-*-* 02:00:00\nPersistent=true\nRandomizedDelaySec=600\n\n[Install]\nWantedBy=timers.target<\/code><\/pre>\n
Enable and start the timer using standard systemctl commands:<\/p>\n
sudo systemctl daemon-reload\nsudo systemctl enable --now openvas-wazuh-bridge.timer<\/code><\/pre>\n
Wazuh SIEM Ingestion: Custom Decoders and Correlation Rules<\/h2>\n
Once OpenVAS generates structured NDJSON events in \/var\/log\/openvas_wazuh_feed.log<\/code>, configure the Wazuh Agent to monitor the file and forward the log entries to the Wazuh Manager. Add the following localfile<\/code> block inside \/var\/ossec\/etc\/ossec.conf<\/code> on the scanner host:<\/p>\n
<ossec_config>\n  <localfile>\n    <log_format>json<\/log_format>\n    <location>\/var\/log\/openvas_wazuh_feed.log<\/location>\n  <\/localfile>\n<\/ossec_config><\/code><\/pre>\n
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<\/code>:<\/p>\n
<!-- \/var\/ossec\/etc\/decoders\/local_decoder.xml -->\n<decoder name=\"openvas-json\">\n  <prematch>^\\{\"timestamp\":.*\"scanner\": \"OpenVAS-GMP\"<\/prematch>\n<\/decoder>\n\n<decoder name=\"openvas-json-fields\">\n  <parent>openvas-json<\/parent>\n  <plugin_decoder>JSON_Decoder<\/plugin_decoder>\n<\/decoder><\/code><\/pre>\n
Next, define production correlation rules inside \/var\/ossec\/etc\/rules\/local_rules.xml<\/code>. These rules evaluate the vulnerability severity and trigger high-priority alerts whenever an exploitable CVSS score is reported:<\/p>\n
<!-- \/var\/ossec\/etc\/rules\/local_rules.xml -->\n<group name=\"openvas,vulnerability,\">\n  <!-- Base rule for all ingested OpenVAS reports -->\n  <rule id=\"100500\" level=\"3\">\n    <decoded_as>openvas-json<\/decoded_as>\n    <description>OpenVAS: Vulnerability scan event detected on $(target_ip)<\/description>\n    <mitre>\n      <id>T1595.002<\/id>\n    <\/mitre>\n  <\/rule>\n\n  <!-- Medium Severity Vulnerabilities (CVSS 4.0 - 6.9) -->\n  <rule id=\"100501\" level=\"7\">\n    <if_sid>100500<\/if_sid>\n    <field name=\"severity_level\">^MEDIUM$<\/field>\n    <description>OpenVAS: Medium severity flaw on $(target_ip) [CVE: $(cve)] - $(vulnerability_name)<\/description>\n  <\/rule>\n\n  <!-- High Severity Vulnerabilities (CVSS 7.0 - 8.9) -->\n  <rule id=\"100502\" level=\"10\">\n    <if_sid>100500<\/if_sid>\n    <field name=\"severity_level\">^HIGH$<\/field>\n    <description>OpenVAS: High severity vulnerability on $(target_ip) Port $(port) [CVE: $(cve)]<\/description>\n  <\/rule>\n\n  <!-- Critical Severity Vulnerabilities (CVSS 9.0+) with Active Response -->\n  <rule id=\"100503\" level=\"14\">\n    <if_sid>100500<\/if_sid>\n    <field name=\"severity_level\">^CRITICAL$<\/field>\n    <description>OpenVAS: CRITICAL remotely exploitable flaw on $(target_ip):$(port) [CVE: $(cve)] - Action Required<\/description>\n    <mitre>\n      <id>T1190<\/id>\n    <\/mitre>\n  <\/rule>\n<\/group><\/code><\/pre>\n
After updating the configuration, validate rule syntax and restart the Wazuh Manager:<\/p>\n
\/var\/ossec\/bin\/wazuh-logtest < \/dev\/null\nsudo systemctl restart wazuh-manager<\/code><\/pre>\n
Production Hardening and Operational Remediation<\/h2>\n
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:<\/p>\n