Vulnerability Detection in Wazuh 4.14

The vulnerability detection module in Wazuh identifies known CVEs (Common Vulnerabilities and Exposures) in software installed on monitored endpoints. The module operates in two stages: the syscollector component on the agent collects an inventory of installed packages, and the vulnerability-detector module on the server correlates this inventory against vulnerability databases.

How It Works

Vulnerability detection in Wazuh relies on correlating two data sources:

1. Software inventory (Syscollector) - the agent collects a list of installed packages, their versions, and architectures
2. Vulnerability databases - the server downloads and updates feeds from NVD, CISA KEV, and vendor-specific sources
3. Correlation - the server matches installed package versions against CPE/CVE records and generates alerts

Agent (syscollector) -> Package inventory ->
-> Server (vulnerability-detector) -> CVE correlation ->
-> Alert -> Indexer -> Dashboard

The Matching Process

The vulnerability-detector module performs the following operations:

1. Receives inventory data from the agent through syscollector
2. Downloads feed updates on schedule
3. Checks each package against corresponding CPE (Common Platform Enumeration) records
4. Matches CPE entries against CVE records in the vulnerability database
5. Compares the installed package version against the range of vulnerable versions
6. Generates an alert with vulnerability details (CVE ID, CVSS, description, affected package)

Configuring vulnerability-detector

Server Configuration

The module is configured in /var/ossec/etc/ossec.conf on the Wazuh server:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Configuration Parameters

Indexer Connection

The module requires an indexer connection for storing results:

<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://127.0.0.1:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/filebeat/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
    <key>/etc/filebeat/certs/filebeat-key.pem</key>
  </ssl>
</indexer>

Offline Mode

For air-gapped environments, Wazuh supports an offline mode with a local repository:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
  <offline-url>file:///var/ossec/var/vuln-feed/</offline-url>
</vulnerability-detection>

The offline repository must be downloaded in advance and placed on the Wazuh server.

Feed Providers

Wazuh uses the Wazuh CTI platform to obtain vulnerability data. The data is aggregated from several primary sources.

Data Sources

Prioritization

When data is available from multiple sources, Wazuh prioritizes the vendor-specific feed. For instance, for a package on Ubuntu, Canonical data takes precedence over NVD because it contains exact fixed-package version information from the distribution repository.

Syscollector Configuration

Syscollector is the agent module responsible for inventory data collection. It is configured in /var/ossec/etc/ossec.conf on the agent side:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <hardware>yes</hardware>
  <os>yes</os>
  <network>yes</network>
  <packages>yes</packages>
  <ports all="no">yes</ports>
  <processes>yes</processes>
  <hotfixes>yes</hotfixes>
</wodle>

Syscollector Parameters

Collected Package Data

For each package, syscollector collects:

• Package name
• Version
• Architecture
• Source (package manager)
• Description
• Installation date

On Linux, data is extracted from dpkg (Debian/Ubuntu), rpm (RHEL/CentOS), and pacman (Arch). On Windows, it is sourced from the registry (installed programs) and the update database.

Severity Levels

Wazuh uses the CVSS (Common Vulnerability Scoring System) to classify vulnerabilities:

Alerts at level 12 and above trigger email notifications when the email notifier is configured.

Alert Examples

High-Severity Vulnerability

{
  "timestamp": "2024-11-20T14:30:00.000+0000",
  "rule": {
    "level": 10,
    "description": "CVE-2024-6387 affects openssh-server",
    "id": "23505",
    "groups": ["vulnerability-detector"]
  },
  "agent": {
    "id": "003",
    "name": "web-server-prod"
  },
  "data": {
    "vulnerability": {
      "cve": "CVE-2024-6387",
      "title": "RegreSSHion: Remote Code Execution in OpenSSH",
      "severity": "High",
      "cvss": {
        "cvss3": {
          "base_score": "8.1",
          "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
        }
      },
      "package": {
        "name": "openssh-server",
        "version": "1:8.9p1-3ubuntu0.6",
        "architecture": "amd64",
        "condition": "Package less than 1:8.9p1-3ubuntu0.10"
      },
      "reference": "https://nvd.nist.gov/vuln/detail/CVE-2024-6387",
      "published": "2024-07-01",
      "status": "Active"
    }
  }
}

Critical Vulnerability

{
  "rule": {
    "level": 13,
    "description": "CVE-2021-44228 affects log4j2",
    "id": "23505"
  },
  "data": {
    "vulnerability": {
      "cve": "CVE-2021-44228",
      "title": "Apache Log4j2 Remote Code Execution",
      "severity": "Critical",
      "cvss": {
        "cvss3": {
          "base_score": "10.0"
        }
      },
      "package": {
        "name": "liblog4j2-java",
        "version": "2.14.1-1",
        "condition": "Package less than 2.17.1"
      },
      "status": "Active"
    }
  }
}

Vulnerability with Available Fix

{
  "data": {
    "vulnerability": {
      "cve": "CVE-2024-1234",
      "severity": "Medium",
      "package": {
        "name": "nginx",
        "version": "1.22.0-1",
        "condition": "Package less than 1.22.0-3"
      },
      "status": "Active",
      "remediation": "Upgrade nginx to version 1.22.0-3 or later"
    }
  }
}

Scan Scheduling

Feed Update Interval

The feed-update-interval parameter determines how frequently vulnerability databases are refreshed. The minimum value is 60 minutes.

<vulnerability-detection>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Accepted time units: s (seconds), m (minutes), h (hours), d (days).

Syscollector Interval

The inventory collection interval is configured independently on the agent:

<wodle name="syscollector">
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
</wodle>

Recommended values:

Vulnerability Dashboard

The Vulnerability Detection dashboard in Wazuh Dashboard provides:

• Summary - total vulnerability count by severity level
• Top vulnerable agents - systems with the highest vulnerability count
• Top CVEs - most common vulnerabilities across the infrastructure
• Severity distribution - chart by CVSS score
• Timeline - vulnerability discovery trends over time
• Per-agent detail - vulnerability list for a specific system
• Filtering - by agent, CVE ID, severity, package, and status

Access the dashboard at: Wazuh Dashboard - Modules - Vulnerability Detection.

False Positive Management

Exclusion Rules

To suppress known false positives, create rules with level 0:

<rule id="100400" level="0">
  <if_sid>23505</if_sid>
  <field name="data.vulnerability.cve">CVE-2023-12345</field>
  <description>False positive: CVE-2023-12345 not applicable in this configuration.</description>
</rule>

Exclude by Package

<rule id="100401" level="0">
  <if_sid>23505</if_sid>
  <field name="data.vulnerability.package.name">^libexample$</field>
  <description>Suppress vulnerability alerts for libexample (internal package).</description>
</rule>

Exclude by Agent

<rule id="100402" level="0">
  <if_sid>23505</if_sid>
  <field name="agent.name">^test-server-</field>
  <description>Suppress vulnerability alerts for test servers.</description>
</rule>

Best Practices for False Positive Management

1. Do not suppress alerts for critical CVEs without documented justification
2. Review the exclusion list periodically (quarterly review is recommended)
3. Use the description field to document the reason for each exclusion
4. Consider implementing compensating controls rather than suppressing alerts

Comparison with Alternative Solutions

Wazuh stands out through its agent-based approach that requires no network scanning, its built-in SIEM integration, and its open-source license. Limitations include the absence of web application scanning and dependence on public CVE databases.

Troubleshooting

Vulnerabilities Not Being Detected

1. Verify that the vulnerability-detection module is enabled on the server:

<vulnerability-detection>
  <enabled>yes</enabled>
</vulnerability-detection>

2. Confirm that syscollector is enabled on the agent:

<wodle name="syscollector">
  <disabled>no</disabled>
  <packages>yes</packages>
</wodle>

3. Check the feed update status:

grep vulnerability /var/ossec/logs/ossec.log | tail -20

4. Verify that inventory data is available:

curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-inventory-*/_search?size=1" \
  -H "Content-Type: application/json"

Feeds Not Updating

1. Check network connectivity to the update server:

curl -s https://cti.wazuh.com/api/v1/ping

2. Verify DNS resolution:

nslookup cti.wazuh.com

3. For offline mode, confirm the feed files are accessible:

ls -la /var/ossec/var/vuln-feed/

Too Many Vulnerability Alerts

1. Create exclusion rules for known false positives (see section above)

2. Configure prioritization - focus on critical and high-severity vulnerabilities:

curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"size":0,"aggs":{"severity":{"terms":{"field":"vulnerability.severity"}}}}'

3. Update packages regularly to resolve vulnerabilities at their source.

Syscollector Not Collecting Data

1. Check the module status:

/var/ossec/bin/wazuh-control status | grep modulesd

2. Verify that the package manager is accessible:

# Debian/Ubuntu
dpkg -l | head -5

# RHEL/CentOS
rpm -qa | head -5

3. Review the agent logs:

grep syscollector /var/ossec/logs/ossec.log | tail -20

High Scan Load

1. Increase the syscollector interval:

<wodle name="syscollector">
  <interval>12h</interval>
</wodle>

2. Disable unnecessary collection modules:

<wodle name="syscollector">
  <hardware>no</hardware>
  <processes>no</processes>
  <ports>no</ports>
</wodle>

3. Keep only the essential data collectors: packages and hotfixes.

Related Sections

• File Integrity Monitoring - FIM detects file changes while vulnerability detection identifies CVEs in installed software
• Security Configuration Assessment - SCA verifies configurations, complementing vulnerability data
• Wazuh Components - agent and server roles in the vulnerability detection process